On 21.05.2012 14:05, Thierry Reding wrote: > I agree. It's really just a "simple-bus" kind of bus. Except that it'll need > another compatible value to make the host1x driver bind to it. But we should > be able to make it work without creating a completely new bus. I guess the > "ranges" property could specify 0x54000000 as the base address and child > nodes could use offsets relative to that. Maybe even that is overkill, > though. Hi, In the phase where we are just getting display up, yes, the bus is a really simple bus. For that, all you need to know about host1x is that it needs to be turned on whenever you talk to the display. Having a bus seems overkill. At a latest stage, we're going to need support for host1x channels and related infrastructure. In that phase, we need to find good homes for channel allocation, job tracking, push buffer management, and other code common to all host1x drivers. In the current nvhost driver, it's the job of the bus_type and related utilities, and that seems like a good enough fit. I have a bit of hard time understanding the significance of a bus_type in the Linux driver model. On one hand, bus_type allows grouping a set of devices and drivers according to the APIs they implement. In nvhost, we have struct nvhost_device and struct nvhost_driver, and each host1x client driver needs to use them. It's natural to put them in the same bus_type. As a bonus, we can assign further common tasks to the bus_type. On the other hand, implementing a bus_type introduces code almost duplicate to platform bus. This is the part that I have hard time with. The device tree should reflect the target state, as it's going to be an API between kernel and boot loader. I believe it'd be best to introduce host1x as a bus and put all host1x clients as nodes inside host1x. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
