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: <20121213085750.GA14740@avionic-0098.adnet.avionic-design.de>
Date:	Thu, 13 Dec 2012 09:57:50 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Terje Bergström <tbergstrom@...dia.com>
Cc:	"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: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);

Once the dummy device has been properly set up and have each client use

	struct device *host1x_get_drm_device(struct host1x *host1x);

to obtain a pointer to the dummy device, such that it can receive the
driver-private data using dev_get_drvdata() on the returned device. As
long as tegra-drm hasn't registered with host1x yet, the above function
could return ERR_PTR(-EPROBE_DEFER), so that dependencies are
automatically handled. This is required because, tegra-drm not being the
parent of the child devices, it can be guaranteed that it is probed
before any of the children.

That way we should be able to get around any circular dependencies,
since we only call into host1x from tegra-drm but not the other way
around.

Thierry

Content of type "application/pgp-signature" skipped