Re: [RFC v2 5/5] drm: Add NVIDIA Tegra support

["Terje Bergström" <tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

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