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: <CAKMK7uFy=Hkqqqom=yOZ8dgSGjRT4JCJuJK7coJ+i=OyovKcYQ@mail.gmail.com>
Date:	Wed, 5 Dec 2012 13:31:54 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Thierry Reding <thierry.reding@...onic-design.de>
Cc:	Terje Bergström <tbergstrom@...dia.com>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Arto Merilainen <amerilainen@...dia.com>
Subject: Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
<thierry.reding@...onic-design.de> wrote:
> Maybe something more elaborate could help, though. Suppose we add
> functionality to DRM to instantiate a DRM device. We could call such a
> function from the host1x driver to add a device which the tegra-drm
> driver could bind to. This would entail something like a small bus
> implementation for DRM that would allow matching DRM devices to DRM
> drivers much like the platform or PCI busses. This could automatically
> take care of registering the DRM device with the proper parent so that
> host1x clients can lookup the host1x via dev->parent.
>
> Perhaps something as simple as
>
>         int drm_device_register(struct device *parent, const char *name, int id);
>
> could work. Or something more elaborate such as allocating a device with
>
>         struct drm_device *drm_device_alloc(const char *name, int id);
>
> paired with
>
>         int drm_device_register(struct drm_device *dev);
>
> would be more flexible in that drivers could modify the DRM device in
> between the two calls.

Imo that's worse, since now drm manages even more of the driver->hw
binding process. In my dream world the drm driver just registers a
normal driver at module load time directly with whatever bus it's
interested in, and then, from it the bus' ->probe callback setups up
the entire driver, calling down into drm to setup up interfaces to
userspace (dev node, sysfs, and whatever is required to implement the
ioctls) and uses the various helper libraries provided. So host1x
providing a virtual device that tegradrm can match sounds much better
(if that helps in decoupling from host1x).

Or simply call the tegradrm setup from host1x directly, creating a
depency on the tegradrm module. When trying to unload host1x it can
then also call down into tegradrm to tear down the drm device.
Afterwards you should be able to unload tegradrm without fuzz. And if
the hard dependcy is an issue for other host1x clients this
setup/teardown could be wrapped into an #ifdef CONFIG_TEGRADRM.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/