On 1/2/08, Timur Tabi timur@freescale.com wrote:
That's the best plan I came up with. This is apparently fixed in ASoC V2. From ASoC V1's perspective, the fabric driver must be the master. However, it doesn't make sense to have a node in the device tree for the fabric driver, because there is no such "device". The fabric driver is an abstraction. So I need to chose some other node to probe the fabric driver with. I chose the SSI, since each SSI can have only one codec.
Does that mean with ASoC V2 you can instantiate it with the board specific platform code instead? I think that is the consensus we were leaning towards in the last discussion about this issue.
But that doesn't work in my environment. My generic channel is "fsl,i2s". I have four different systems booting off from a shared network drive. Each of these systems needs the common "fsl,i2s" driver but they all four need different fabric drivers.
That, I don't understand. fsl,ssi is pretty much the same thing as fsl,i2s, since the SSI *is* an I2S device. It's also an AC97 device, which is why I added the fsl,mode property.
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? What happens when Freescale produces another peripheral that can do ssi but isn't register level compatible?
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 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.
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.
Are you saying that you want to use the same kernel on four different systems? If so, then you need to find a way to compile all fabric drivers together, and at boot time each fabric driver will decide whether it will do anything.
Yes! That is exactly what we want to support in arch/powerpc. Use platform code to select the correct fabric driver.
Cheers, g.