[alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

[Timur Tabi]

On Tue, Apr 27, 2010 at 5:29 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:

>>               codec1 :codec at 4f {
>>                       compatible = "cirrus,cs4270";
>>                       reg = <0x4f>;
>>                       /* MCLK source is a stand-alone oscillator */
>>                       clock-frequency = <12288000>;
>>               };
>
> You also want to be representing unused pins here.

If they're unused, how do I represent them?  Can you give me an example?

>>       [...]
>>       ssi1: ssi at 16000 {
>>               compatible = "fsl,mpc8610-ssi";
>>               [...]
>>               fsl,mode = "i2s-slave";
>
> I'd not include the master/slave decision; it's either implied by the
> fact that the CODEC has a standalone clock, a property of the link/card,
> or a policy decision that the running software can change on a whim.

I know it's redundant, but at the time, it seemed a lot simpler than
walking the device tree.

Frankly, I'd rather not consider minor device tree changes at this
point.  I'm hoping I don't need to change the device tree at all.

>>       sound {
>>               compatible = "fsl,mpc8610-hpcd-sound";
>>               /* maybe something like (totally off the top of my head) */
>>               dai-links = <&ssi1 0 &codec 0
>>                            &ssi1 1 &codec 1>;
>
> I'm having a hard time loving this.  I'd be looking for a lot more
> semantics on the links (things like information about separate clocks
> for the two directions, for example) which makes me think that that
> simple list format is far too simple and you want a list of more complex
> objects.

Yeah, I don't like it either.  It seems arbitrary.

> I think the ideal is something that's purely descriptive of the hardware
> and doesn't include any policy decisions.

I like to think that this is what we have today.

-- 
Timur Tabi
Linux kernel developer at Freescale