[alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
timur at freescale.com
Thu Jan 3 19:14:12 CET 2008
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
> 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.
Linux Kernel Developer @ Freescale
More information about the Alsa-devel