Tegra DRM device tree bindings

[Thierry Reding]

On Fri, Jul 06, 2012 at 01:59:13PM -0600, Stephen Warren wrote:
> On 07/05/2012 06:15 AM, Thierry Reding wrote:
> > 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.
> 
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120708/eeaf54b6/attachment.sig>