On 12/21/2012 01:57 AM, Arto Merilainen wrote:
On 12/20/2012 07:14 PM, Stephen Warren wrote:
What's wrong with just having each device ask the host1x (its parent) for a pointer to the (dummy) tegradrm device. That seems extremely
We are talking about creating a dummy device because:
- we need to give something for drm_platform_init(),
- drm related data should be stored somewhere,
Yes to those too, I believe.
- some data must be passed to all driver probe() functions. This is not
hw-related data, but just some lists that are used to ensure that all drivers have been initialised before calling drm_platform_init().
I haven't really thought through /when/ host1x would create the dummy device. I guess if tegradrm really must initialize after all the devices that it uses (rather than using something like deferred probe) then the above may be true.
All these issues are purely tegra-drm related and solving them elsewhere (in host1x) would be just wrong! host1x would not even use the dummy device for anything so creating it there seems bizarre.
I see the situation more like:
* 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).
* 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.
* 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.