On Fri, Jul 06, 2012 at 01:59:13PM -0600, Stephen Warren wrote:

On 07/05/2012 06:15 AM, Thierry Reding wrote:

quoted

Here's a new proposal that should address all issues collected
during the discussion of the previous one:

From tegra20.dtsi:

...

At a quick glance, that all seems pretty reasonable now.

quoted

One problem I've come across when trying to get some rudimentary
code working with this is that there's no longer a device which the
DRM driver can bind to, because the top-level device (host1x) now
has a separate driver.

Can't you just have the host1x driver trigger the instantiation of the
DRM driver? In other words, the host1x node is both the plain host1x
driver and the DRM driver. So, after initializing anything for host1x
itself, just end host1x's probe() with something a call to
drm_platform_init(), passing in host1x's own pdev.

After all, it seems like the whole point of representing host1x in the
DT is to expose the graphics HW, so you'd need the DRM device in that
case.

The reason that I've been hesitating is that host1x isn't related only
to graphics HW but is also required to make f.e. video input work. So I
can imagine a setup where for instance you need only video input and
send captured data via the network. If host1x registered the DRM driver
it would imply that setups that don't require any output would still
have the whole DRM initialized.

I did post a proposal to solve this problem, which doesn't seem Tegra
specific, to dri-devel last week. But if nobody else thinks it's a
problem to use host1x then I'll just use that as the easy way out. If
this happens to cause problems at some point in the future we can always
address it then. If host1x is tightly coupled to DRM then I think we can
also keep the driver with the rest of the DRM code.

Thierry