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. > 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. > 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? >> The fabric driver is specific to the board. So you should be using >> Kconfig to select the fabric driver. There is no node in the device >> tree for fabric drivers. I thought that was the consensus. > > No, the desire is to go multiplatform in ppc. That means you cannot > use Kconfig to select the correct fabric driver. I don't see any way of avoiding this with ASoC V1. -- Timur Tabi Linux Kernel Developer @ Freescale _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
