Re: Best practice device tree design for display subsystems/DRM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
> Have you also considered how suspend/resume works in such a place,
> where every driver is independent? The ChromeOS guys have bitched
> before about the exynos driver which is has lots of sub-drivers, how
> do you control the s/r ordering in a crazy system like that? I'd
> prefer a central driver, otherwise there is too many moving parts.

>From earlier in the evolution of Armada DRM, that has also been my
preferred idea - though probably not quite how people think.

My idea was to have a separate "driver" assemble all the constituent
parts, and then register the "armada-drm" platform device providing
via platform resources and/or platform data all the necessary
information (maybe not even bothering to decode the OF nodes but just
provide a collection of nodes for each consituent part.)

Such a thing could be turned into a generic solution for all the
multi-part drivers.  If we use Sebastian's idea of using phandles
(it seems there's a precident for it with the direction v4l2 is
going to solve a similar problem) then we likely have a standard
way of describing component-ized display setups in DT.

-- 
Russell King
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux