[PATCH v3 12/32] drm/exynos: Split manager/display/subdrv

[Thierry Reding]

On Fri, Nov 29, 2013 at 12:04:04AM +0100, Tomasz Figa wrote:
> On Tuesday 26 of November 2013 10:00:13 Olof Johansson wrote:
> > On Tue, Nov 12, 2013 at 10:35 AM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
[...]
> > > Sorry, this might have been a bit too harsh, but just imagine myself doing
> > > my regular patch review round, hoping (as usual) to see only code that is
> > > not less than great, while suddenly stumbling upon a line of code that
> > > I would expect at most in some vendor tree or maybe several years ago in
> > > sources of a 2.4 kernel.
> > 
> > More like code written in the same style as x86 DRM stuff, where
> > they're not used to overabstracting things from day one to make things
> > generic instead of supporting the only known chip combination to date.
> 
> No, not really. They don't have any modularity on x86. Just a graphics
> card with everything on it, so they can freely do such things, as they
> don't have to account for all we need to account for on ARM platforms.

I don't think there's such a clear difference. A particular GPU on x86
is equally modular as a specific GPU on an ARM SoC. The problem is that
on x86 there's much less mix-and-matching going on.

So theoretically they do need to account for the same craziness. That's
not done, however, because there's no need for it. It doesn't happen in
practice.

> Also, I wouldn't call making a driver usable and useful for more than
> just one fixed platform "overabstracting"...

It is if there's never more than the single fixed platform. Since none
of us can predict the future I think it's entirely reasonable if we do
concentrate on solving the problems that we have now. It doesn't mean
that we should write code in a way that makes future enhancements
unnecessarily difficult, but I very much prefer to see code merged that
supports one specific use-case that we have now rather than working on
the code for years on end in an attempt to make it generic enough to
support everything that the future can possibly hold.

Chances are pretty good that we won't be able to predict one specific
use-case and then rewrite everything anyway. Linux has been pretty
successful so far in a large part because it has evolved organically.
We're not doing ourselves any good by requiring everything to be perfect
from the beginning.

We all know what a disaster DT has been and still is. It makes it very
difficult to get new features supported because we now have a component
that we can no longer change at will and that cannot evolve organically
anymore. That impedes progress.

For this particular issue no DT is involved. There's no need for ABI
stability because it's just in-tree code and we can change it to our
heart's content. We can refactor things when an actual need arises. By
then chances are pretty good we'll have a much better understanding of
what exactly we need and therefore we can come up with a much better
solution than at this point in time.

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/20131129/f97dfc52/attachment.pgp>