On 1/3/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
Does that mean with ASoC V2 you can instantiate it with the board specific platform code instead?
I don't know. I haven't really looked at V2 yet. You'll have to ask Liam Girdwood.
This is one of the examples of where the compatible properties are trying to be far to generic about what they are. How do you define what "fsl,ssi" is?
The SSI is a specific Freescale device, so I think it's pretty well defined.
What happens when Freescale produces another peripheral that can do ssi but isn't register level compatible?
It won't be called the SSI. It will be called something else.
Heh, I've seen enough to know that it's virtually impossible for a company to maintain a consistent naming scheme all the time. Better to be specific now and add generic names sometime in the future rather than the other way around.
In my opinion, it is far better to be specific in the device tree and teach the driver about what versions it is able to bind against. In this case, I would use "fsl,mpc8610-ssi" or maybe better yet: "fsl,mpc8610-ssi,i2s" (MPC8610 SSI device in I2S mode).
I can work with that, but the SSI could be placed into any future 83xx, 85xx, or 86xx SOC, and the driver will still work with it as-is.
The have the device trees claim compatibility with the older fsl,mpc8610-ssi device specifically. ie: compatible = "fsl,mpc83<whatever>-ssi,ac97", "fsl,mpc8610-ssi,ac97";
I don't like the idea of a separate fsl,mode property to describe the behaviour of multifunction peripherals. It makes probing more difficult when there is a different driver for each mode.
Can you propose an alternative? The driver needs to know what mode to use when communicating with its codec. How am I supposed to know if I have an I2S codec or an AC97 codec?
Make the compatible property tell you! :-) If it's connected to an I2S codec, then it could be compatible = "fsl,mpc8610-ssi,i2s". Or for AC7, compatible = "fsl,mpc8610-ssi,ac97"
Cheers, g.