# Re: Board level compatibility matching - List: linuxppc-dev - 3 messages, 3 authors - Page: https://ratatoskr.run/linuxppc-dev/2008/08/8049054/t ## Re: Board level compatibility matching - From: David Gibson \ - Date: 2008-08-01 04:25:05 - Message: https://ratatoskr.run/linuxppc-dev/2008/08/8049054.md ```text On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote: > On 7/31/08, David Gibson [ref] wrote: > > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote: > > > On 7/31/08, David Gibson [ref] 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 ``` ## Re: Board level compatibility matching - From: Jon Smirl \ - Date: 2008-08-01 04:37:25 - Message: https://ratatoskr.run/linuxppc-dev/2008/08/8049056.md ```text On 8/1/08, David Gibson [ref] wrote: > On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote: > > On 7/31/08, David Gibson [ref] wrote: > > > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote: > > > > On 7/31/08, David Gibson [ref] 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 ``` ## Re: Board level compatibility matching - From: David Gibson \ - Date: 2008-08-01 06:22:59 - Message: https://ratatoskr.run/linuxppc-dev/2008/08/8049057.md ```text On Fri, Aug 01, 2008 at 12:37:25AM -0400, Jon Smirl wrote: > On 8/1/08, David Gibson [ref] wrote: > > On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote: > > > On 7/31/08, David Gibson [ref] wrote: > > > > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote: > > > > > On 7/31/08, David Gibson [ref] wrote: [snip] > > > 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. If you need a board-specific fabric driver, the board platform code shouldn't be instantiating the generic fabric driver. Given the board specific driver a different name... -- 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 ```