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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
