On Wed, Jun 27, 2012 at 09:13:52AM +0300, Terje Bergström wrote: > On 26.06.2012 20:46, Stephen Warren wrote: > > > 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. > > Yes, the code is largely a copy of platform bus. One big difference is > type safety - all the nvhost_bus APIs take in and give out nvhost_device > or nvhost_driver pointers. At the registration time I also enforce > parent-child relationship to host1x and bus clients. I don't know where NVIDIA wants to go with respect to device trees in their downstream kernels, but at least for mainline (with DT-only support on Tegra) the parent-child relationship will be rooted in the DT anyway. > Another is that I am able to enumerate all host1x related devices. The > latter could of course be done via listing the children of host1x. > > And third is that I was able to add version field to device to > distinguish between Tegra2 and Tegra3 3D (for example) and make the bus > use that information for binding driver and device. As the sysfs entry > path is determined by the device name, this allows keeping the old sysfs > APIs. Again this can easily be represented by the DT compatible property. Thierry
Attachment:
pgpHI2zj76NDj.pgp
Description: PGP signature
