On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
> On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
> > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
> > > On 7/31/08, David Gibson <[EMAIL PROTECTED]> 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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
