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

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:

quoted

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131021/d8ff1dcf/attachment-0001.sig>