Re: Board level compatibility matching

["Jon Smirl" <jonsmirl@gmail.com>]

On 8/1/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
>  > On 7/31/08, David Gibson <david@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@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 instantiating it from the
>  platform code does.

Platform devices are missing the compatible chain process. If we do
this with platform drivers the boot code creates a 'fabric' device
then I'll have to ensure that my board-fabric driver gets probed
before default-fabric because they both want to bind to the fabric
device.

I can do this, but building ordering dependencies like this is not the
most robust way to do things. With an OF device the ordering is
obvious via the compatible attribute.


>
>
>  --
>  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
>


-- 
Jon Smirl
jonsmirl@gmail.com