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.