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 for Android: free password hash cracker in your pocket

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

Message-ID: <20121205122209.GB29943@avionic-0098.adnet.avionic-design.de>
Date:	Wed, 5 Dec 2012 13:22:12 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Daniel Vetter <daniel@...ll.ch>
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 05, 2012 at 01:03:14PM +0100, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström <tbergstrom@...dia.com> wrote:
> > You're right in that binding to a sub-device is not a nice way. DRM
> > framework just needs a "struct device" to bind to. exynos seems to solve
> > this by introducing a virtual device and bind to that. I'm not sure if
> > this is the best way, but worth considering?
> 
> Note that I'm not too happy about the fact that drm wants a struct
> device to register a drm device. This all made a lot of sense back in
> the days when drm drivers this this fancy shadow attaching to allow
> drm to use a driver for rendering cooperatively with a fbdev driver.
> Today there's not much reason for that anymore imo, and I'd welcome
> patches to allow drivers to simply register a drm device (and remove
> all the newer registration functions for usb/platform/whatever
> drivers, moving the device handling into drivers). Note that it's a
> bit work, since not-really-required abstraction (which was useful back
> when the drm drivers have been shared with *BSD, but pointless now)
> like the drm irq support needs to be moved away to a pci-dev legacy
> thing only - it doesn't really buy a kms driver anything above&beyond
> calling request_irq() itself.
> 
> So feel free to burn this down, I'll be happy to carry wood to the
> pyre in the from of reviews (not much time for more right now ...).

This wouldn't solve the problem at hand, though, since we'd still need
to instantiate the DRM driver somehow. Currently this is triggered
ultimately by the host1x's .probe().

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.

Thierry

Content of type "application/pgp-signature" skipped