Messages in this thread | | | Date | Fri, 21 Dec 2012 14:19:23 -0700 | From | Stephen Warren <> | Subject | Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x |
| |
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.
| |