Tegra DRM device tree bindings
Thierry Reding
thierry.reding at avionic-design.de
Tue Jun 26 23:37:30 PDT 2012
On Wed, Jun 27, 2012 at 09:13:52AM +0300, Terje Bergström wrote:
> On 26.06.2012 20:46, Stephen Warren wrote:
>
> > I'd certainly like to see some upstream discussion re: why exactly we
> > have a custom bus type here. What does it do that a regular platform bus
> > doesn't do? Are those features something that would be generally useful
> > to add to the existing platform bus? Can we instead add hooks into
> > platform bus rather than creating a new bus? I recall you saying that
> > the nvhost_bus duplicated a lot of code from the existing platform bus.
>
> Yes, the code is largely a copy of platform bus. One big difference is
> type safety - all the nvhost_bus APIs take in and give out nvhost_device
> or nvhost_driver pointers. At the registration time I also enforce
> parent-child relationship to host1x and bus clients.
I don't know where NVIDIA wants to go with respect to device trees in
their downstream kernels, but at least for mainline (with DT-only
support on Tegra) the parent-child relationship will be rooted in the
DT anyway.
> Another is that I am able to enumerate all host1x related devices. The
> latter could of course be done via listing the children of host1x.
>
> And third is that I was able to add version field to device to
> distinguish between Tegra2 and Tegra3 3D (for example) and make the bus
> use that information for binding driver and device. As the sysfs entry
> path is determined by the device name, this allows keeping the old sysfs
> APIs.
Again this can easily be represented by the DT compatible property.
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/20120627/ebdfd409/attachment.pgp>
More information about the dri-devel
mailing list