On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote: > Grant Likely wrote: > > > You probably mean "don't use the of_platform bus to load the fabric > > driver". > > Yes, that is what I meant. > > > He still needs to use the data in the device tree to decide > > what fabric drivers to use. > > I'm not sure about that. The fabric driver is tied to the platform itself, > mostly because the fabric driver isn't really a device driver. It's a > platform driver, in that its job is to initialize the other device drivers, or > make sure the kernel initializes them. It's also responsible for telling ALSA > which driver does what and how they're connected. >
Even it it's just based on the board "model" property; that's still deciding what the ALSA fabric is based on data in the device tree. :-) > > Another option is to explicitly call of_platform_device_create in the > > platform code on the fabric node (which should be a child of the root > > node) so that you can have an of_platform_bus fabric driver. > > I don't fully understand platform drivers. Do we really need a full-blown OF > platform driver for this? Both the platform bus and the of_platform bus do exactly the same thing in a simple manner. They allow devices to be matched with drivers. It is a low overhead mechanism. In both cases, devices carry with them some metadata to describe the devices. For platform devices, that meta data is a resource structure and a device specific pdata structure. For of_platform devices, the metadata is a pointer to a device tree node. That's it. Using either mechanism allows the platform code to say "these devices are present" without having to explicitly call routines into the driver. In other words; it can provide late binding of drivers to devices. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
