On 21.12.2012 23:19, Stephen Warren wrote:
There's host1x hardware.
There's a low-level driver just for host1x itself; the host1x driver.
There's a high-level driver for the entire host1x complex of devices.
That is tegradrm. There may be more high-level drivers in the future (e.g. v4l2 camera driver if it needs to aggregate a bunch of host1x sub-devices liek tegradrm does).
tegradrm is a driver for a couple of the host1x clients, namely DC and HDMI, and now adding 2D.
- The presence of the host1x DT node logically implies that both the two
drivers in the previous two points should be instantiated.
Linux instantiates a single device per DT node.
So, it's host1x's responsibility to instantiate the other device(s). I
think it's reasonable for the host1x driver to know exactly what features the host1x HW complex supports; raw host1x access being one, and the higher level concept of a tegradrm being another. So, it's reasonable for host1x to trigger the instantiation of tegradrm.
tegradrm has drivers for each device that it controls, so tegradrm via kernel device-driver model instantiates them. host1x driver doesn't need to do that.
- If DRM core didn't stomp on the device object's drvdata (or whichever
field it is), I would recommend not creating a dummy device at all, but rather having the host1x driver directly implement multiple driver interfaces. There are many examples like this already in the kernel, e.g. combined GPIO+IRQ driver, combined GPIO+IRQ+pinctrl driver, etc.
This is the architecture that would imply host1x instantiating everything, and DRM being a subcomponent of host1x driver. But we didn't choose to go there. We agreed to have tegradrm and host1x drivers separate.
Terje