Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC

[Timur Tabi <timur@freescale.com>]

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