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

[Tomasz Figa <tomasz.figa@gmail.com>]

On Friday 29 of November 2013 08:52:22 Daniel Vetter wrote:
> 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.

I would mostly agree with you if we were discussing SoC-internal
components here. Mostly, because the ARM world is more complex and you
can see the same IP across completely different SoCs from different
vendors.

However, the topic here is about external devices, outside the SoC, such
as different kind of bridges, like the PTN3460 eDP to LVDS bridge, which
are likely to be reused across different platforms. Similar thing is with
using different bridges on different boards using the same SoC platform.
I don't think having an abstraction here would be any overabstraction at
all. Anything less would be a huge "underabstraction" in fact.

Best regards,
Tomasz