[alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

Grant Likely grant.likely at secretlab.ca
Thu Apr 29 02:47:37 EST 2010


On Wed, Apr 28, 2010 at 10:20 AM, Timur Tabi <timur at freescale.com> wrote:
> On Wed, Apr 28, 2010 at 8:57 AM, Grant Likely <grant.likely at secretlab.ca> wrote:
>
>> I'm just saying move the registration of the machine device out of
>> arch/powerpc platform code and into the ssi driver.
>
> But the SSI driver is an OF driver, and it gets probed for every SSI
> node in the device tree.  On the 8610, that means being probed twice.
> But I should only call platform_device_register_simple() once.

Didn't you just finish saying that you cannot see any situation where
you would want the SSI devices linked into a single audio device?  So
then if both SSIs are being used for audio, then do you not need a
machine driver for each ssi?

> Are you saying that I should call platform_device_register_simple()
> from the SSI's driver initialization function, fsl_ssi_init()?

No, I'm saying call it from the probe hook.

However, you should probably do a two stage platform_device_alloc() /
platform_device_add() so you can add data (node pointer) to the
platform device before it gets probed by the machine driver.

>> Then you've got a
>> reasonable place to pass shared data (either the ssi device node or
>> device instance or name.  Whatever you need) to the machine driver.
>
> The problem is that the fabric driver needs much more information from
> the device tree than the SSI driver needs.  So if the SSI driver is
> going to pass that information to the fabric driver via the platform
> data, it's going to have to know what information the fabric driver
> needs.  Then the SSI driver is not board-independent.

I'm not talking about platform_data or about the ssi driver decoding
things that the machine driver needs.  I'm talking about giving the
machine driver a pointer to the ssi device tree node so you don't need
to go through weird gymnastics to find the correct node again.

g.


More information about the Linuxppc-dev mailing list