* Terje Bergström wrote: > 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. I agree that reflecting the hardware hierarchy within the device tree makes sense. I'll need to add some code to tear down child devices in the cleanup path, but that shouldn't be too difficult. However, adding a whole bus_type implementation would pretty much duplicate the platform bus code. I guess host1x could just provide struct host1x_client a set of corresponding APIs to create them, request channels, etc. Thierry
Attachment:
pgpH2_e_Pi17L.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
