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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
