[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Thierry Reding]

On Mon, Dec 10, 2012 at 01:42:45PM +0200, Terje Bergström wrote:
> On 05.12.2012 14:04, Thierry Reding wrote:
> > On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström 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?
> > 
> > That was discussed a few months back already and nobody seemed to like
> > the idea. In fact it was as a result of that discussion that Stephen
> > brought up the idea to register the DRM driver from a central host1x
> > driver (it may also have been part of a discussion on IRC, I don't
> > remember exactly).
> > 
> > At the time I spent some time on a patch that introduced drm_soc_init()
> > to solve this by creating a dummy struct device and registering the
> > driver on top of that. But I abandoned it in favour of fixing the DRM
> > platform support code. The approach also didn't provide for the proper
> > encapsulation.
> 
> I've managed to go through all the other feedback and implement a
> solution to most of them, so now I have some slack to actually think
> about the initialization. Sorry about this, but you (meaning all the
> reviewers) did give us a _lot_ to do. :-) Fortunately, the driver
> actually became a lot better, too.
> 
> Back to the topic of tegradrm init. The root cause of the problem is
> that DRM framework needs some device to assign itself to. The problem is
> that this device doesn't have any physical counterpart, as it's only for
> storing a pointer in DRM framework. Please correct me if this is wrong.
> 
> Moving the client registration to ping pong between DRM and host1x has
> its problems. host1x driver itself has no use for a list of client
> devices. It can just iterate its children in case it needs them. In
> tegradrm, you need a list of devices under tegradrm control, which might
> or might not be the same as list of devices under host1x hardware.
> 
> The solutions that many other DRM drivers seem to employ are the virtual
> devices. Exynos and OMAP drivers do this, as does SH Mobile DRM driver.
> So I think I'd still go this way, as it's the path of minimum
> resistance, least amount of code and most localized change. I know it's
> not ideal, but I'd also not like to get stuck in this.

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.

Is this something that you can take care of in your patch series? I
could also implement this on top of the current driver and then all your
patch series would have to do is remove host1x.c from tegra-drm and
instantiate the platform device itself.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121212/90ca2c64/attachment.pgp>