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]

Date:	Thu, 13 Dec 2012 21:32:24 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Terje Bergström <tbergstrom@...dia.com>,
	"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>,
	Arto Merilainen <amerilainen@...dia.com>
Subject: Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

On Thu, Dec 13, 2012 at 10:58:55AM -0700, Stephen Warren wrote:
> On 12/13/2012 01:57 AM, Thierry Reding wrote:
> > On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:
> >> On 12.12.2012 18:08, Thierry Reding wrote:
> >>> I've briefly discussed this with Stephen on IRC because I
> >>> thought I had remembered him objecting to the idea of adding a
> >>> dummy device just for this purpose. It turns out, however, that
> >>> what he didn't like was to add a dummy node to the DT just to
> >>> make this happen, but he has no (strong) objections to a dummy
> >>> platform device.
> >>> 
> >>> While I'm not very happy about that solution, I've been going
> >>> over it for a week now and haven't come up with any better
> >>> alternative that doesn't have its own disadvantages. So perhaps
> >>> we should go ahead and implement that. For the host1x driver
> >>> this really just means creating a platform device and adding it
> >>> to the system, with some of the fields tweaked to make things
> >>> work.
> >> 
> >> Even the virtual device is not too beautiful. The problem is that
> >> the virtual device is not physical parent for DC, HDMI, etc, so 
> >> dev_get_drvdata(pdev->dev.parent) returns the data from host1x
> >> device, not the virtual device.
> >> 
> >> We'll post with something that goes around this, but it's not
> >> going to be too pretty. Let's try to find the solution once we
> >> get the code out.
> > 
> > After some more discussion with Stephen on IRC we came to the
> > conclusion that the easiest might be to have tegra-drm call into
> > host1x with something like:
> > 
> > void host1x_set_drm_device(struct host1x *host1x, struct device
> > *dev);
> 
> If host1x is registering the dummy device that causes tegradrm to be
> instantiated, then presumably there's no need for the API above, since
> host1x will already have the struct device * for tegradrm, since it
> created it?

Right, that won't be necessary of course. As long as the driver-private
data of the device stays NULL until tegra-drm is ready (has finished
probing) just getting the struct device from the clients and looking at
that should be enough.

Thierry

Content of type "application/pgp-signature" skipped