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

[Daniel Vetter]

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:
> > 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 guess you didn't bother looking at x86 drivers then ... in i915 we have
different blocks spanning 7 major hw iterations, reused in funny (and
overlapping) ways. We have clock trees, nested power domains, interrupt
controllers and forwarders, different coherency domains, off-chip
functiosn in the PCH, the full shebang.

In the code itself we have piles of vtables for the different parts of the
chip, mmio base offsets (since hw engineers just love to move things
around) and otherwise neatly abstracted helpers for different parts of the
chip to be able to reuse things across generations.

The _only_ difference I see compared to an arm soc is that this entire
madness is neatly wrapped up into a fake pci device. And some of the
really remote mmio ranges are windowed into general hodgepodge mmio
register bar so that we don't have to hunt it down on different pci
devices. But occasionally we do even that.

So as per the discussion at KS about soc gfx drivers where all the ip
blocks come from the same vendor I really don't see why arm drivers need
to be so much different than more traditional x86 drivers. Since nowadays
(at least with intel) that means we _are_ talking about an soc.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch