On Tue, Apr 27, 2010 at 5:29 PM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> codec1 :codec@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@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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
