Subject: Re: ARM topic: Is DT on ARM the solution, or is there something better?
Date: Monday 21st October 2013 10:41:13 UTC (over 3 years ago)
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