On Tue, Jun 26, 2012 at 11:46:42AM -0600, Stephen Warren wrote: > On 06/26/2012 07:01 AM, Terje Bergström wrote: > > On 26.06.2012 13:55, Thierry Reding wrote: > ... > >> An alternative would be to call of_platform_populate() from the host1x > > [alternative to making the host1x node contain compatible="simple-bus".] > > >> driver. This has the advantage that it could integrate better with the > >> host1x bus implementation that Terje is working on, but it also needs > >> additional code to tear down the devices when the host1x driver is > >> unloaded because a module reload would try to create duplicate devices > >> otherwise. > > > > Yes, we already have a bus_type for nvhost, and we have nvhost_device > > and nvhost_driver that device from device and device_driver > > respectively. They all accommodate some host1x client device common > > behavior and data that we need to store. We use the bus_type also to > > match each device and driver together, but the matching is version > > sensitive. For example, Tegra2 3D needs different driver than Tegra3 3D. > > I'd certainly like to see some upstream discussion re: why exactly we > have a custom bus type here. What does it do that a regular platform bus > doesn't do? Are those features something that would be generally useful > to add to the existing platform bus? Can we instead add hooks into > platform bus rather than creating a new bus? I recall you saying that > the nvhost_bus duplicated a lot of code from the existing platform bus. I don't like the idea of duplicating the code either, but host1x does have some properties that might be convenient to have part of a bus abstraction (sync points and channels). This could all be implemented using a library of functions instead of a bus-type midlayer, though. I think we've also had that discussion before. Thierry
Attachment:
pgp7PrPjG1Zvc.pgp
Description: PGP signature
