Re: [PATCH 14/17] ASoC: tegra: add tegra30-ahub driver

[Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On Mon, Apr 02, 2012 at 11:27:52AM -0600, Stephen Warren wrote:
> On 04/01/2012 04:31 AM, Mark Brown wrote:

> > Yes, exactly - allocate the resources in the platform driver probes,
> > register with ASoC and then only touch the hardware when ASoC tells you
> > the whole card is ready.

> Thinking about this more, I guess the AHUB driver should be a bus
> driver; in HW, it implements a register bus and the I2S, SPDIF, and DAM
> devices' registers are accessed through that bus. That would solve the
> probing order issues in a way that's much more directly modeled on the
> hardware. Relying on the separate pdev and ASoC probes for the child
> devices seems a little bit like relying on an implementation detail.

> Does this sound like a good idea to you?

Yeah, I'd actually written "mfd" in one of the earlier drafts of my
original mail but then deleted it as I figured it'd already be that way
if it could be supported :/

> The thing that makes me shy away from this is when our downstream
> kernels want to pick up v3.5, and perhaps don't want to use DT
> exclusively yet, how would they do the same bus/child thing with
> platform devices in board files? Perhaps they don't need to, and can
> just register the AHUB pdev first, and child devices later, and ignore
> the bus' existence.

You can happily specify parent/child relationships with static
registrations, just set the parent pointers appropriately and ensure
things get registered in the right order.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]