Re: ARM topic: Is DT on ARM the solution, or is there something better?

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

 




On Mon, Oct 21, 2013 at 11:30:14AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 21, 2013 at 12:24:49PM +0200, Thierry Reding wrote:
> > Multi-driver with DRM has worked pretty well for Tegra. Essentially what
> > I created was a sort of abstraction layer between DRM and the individual
> > drivers so that each driver can register itself with that layer. Once it
> > has been determined that all drivers have been probed, that glue layer
> > can load the DRM driver and call back into the sub-drivers to register
> > their respective components with DRM.
> > 
> > That even works fairly nicely with deferred probing. Note that the code
> > currently in Linus' tree has some issues, but I've reworked it since in
> > linux-next and the final result isn't all that bad. I've even attempted
> > to make it somewhat generic so that it could potentially be reused by
> > other drivers. It's not reusable as-is, but perhaps it can be further
> > improved.
> > 
> > I agree that hotpluggability within DRM might have made things easier,
> > but it would likely also have made the core more complex. Furthermore
> > there simply was no need for DRM to provide that kind of flexibility,
> > simple because no driver has had that need so far. Quite a few ARM SoC
> > drivers have appeared lately, and hopefully that'll provide more of an
> > incentive to evolve DRM as needed, but I don't think we can hold it
> > against anyone that they haven't provided us with the ideal subsystem.
> 
> Right, so how do you feel about rewriting it again so that everyone
> can benefit from it instead of it being specific to just Tegra? :)

You are surely aware that by general concensus the responsibility for a
generic implementation falls to the third person to reimplement it from
scratch, which in this case wasn't me for a change... =)

But seriously, I have that somewhere on my TODO list, it's just not top
priority at the moment. I'm also not familiar with what the requirements
are for other SoCs, so I don't have much of an idea what specific areas
require rework.

Thierry

Attachment: pgpyha9RsqMBV.pgp
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux