linux-kernel - Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50D4D25B.7030506@wwwdotorg.org>
Date:	Fri, 21 Dec 2012 14:19:23 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Arto Merilainen <amerilainen@...dia.com>
CC:	Terje Bergstrom <tbergstrom@...dia.com>,
	Thierry Reding <thierry.reding@...onic-design.de>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/