Board level compatibility matching

[David Gibson]

On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
> On 7/31/08, David Gibson <david at gibson.dropbear.id.au> wrote:
> > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
> >  > On 7/31/08, David Gibson <david at gibson.dropbear.id.au> wrote:
[snip]
> >  > That is what I'm doing now. But it requires every board to add a file
> >  > to arch/powerpc/platforms.  Can we have some common code to make the
> >  > fabric device? Can it be an OF device instead of a platform one? An OF
> >  > device could be compatible with boardname-fabric, generic-fabric. That
> >  > allows a stub fabric driver to always bind.
> >
> >
> > There are several ways to do this, and which is the most sensible
> >  depends on the specific design, and whether / how many boards the
> >  design is shared amongst.
> >
> >  In some cases it's suitable to have a "fake" device node for the sound
> >  wiring, to which a fabric driver can bind.  I think I've argued
> >  against this approach in the past, but I've since been convinced that
> >  it is a reasonable approach for some situations.  There's precedent,
> >  too, a number of Apple device trees do this.
> >
> >  In other cases it may be possible to deduce the correct fabric driver
> >  from the interconnections of individual sound components.
> >
> >  In yet others, we need board-specific platform code to instantiate the
> >  fabric driver.  In some cases that's simply the most straightforward
> >  way to do things.  In others it's not ideal, but we can use it as a
> >  fallback technique because deployed device trees simply don't have
> >  sufficient information in other places to use another approach.
> >
> >  There doesn't have to be One True Method for doing this.
> 
> We're running into a need for the true method. With ALSA you need to
> have the codec driver, i2s/ac97 driver and the fabric driver all load
> and say here I am before ALSA can finish binding. ALSA won't complete
> initializing on boards without all three.
> 
> So what do you do on board that doesn't need a fabric driver? That's
> why you want the fake device with the compatible string =
> board-fabric, noop-fabric. Now you know for sure one of those two
> drivers will bind.

No... that would be exactly my example of a case where instantiating
the fabric driver from the platform code isn't ideal, but is a usable
fallback option.

> Why does the fake fabric device need to be in the device tree? Can't
> we just dynamically create it as part of the boot process?

Um.. yes.. that would be exactly what instatiating it from the
platform code does.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson