On 06/26/2012 07:01 AM, Terje Bergström wrote:

On 26.06.2012 13:55, Thierry Reding wrote:

...

quoted

An alternative would be to call of_platform_populate() from the host1x

[alternative to making the host1x node contain compatible="simple-bus".]

quoted

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.