On Wed, Aug 03, 2011 at 07:54:24PM +0100, Alan Cox wrote:
if so, I am aware of it but his patch isn't applied to drm-next yet and so my drm driver doesn't include his patch. of course I will reuse it and remove the samsung_ namespace as you pointed out if the patch is applied to drm-next.
It would be nice it was as its also the same as the code being carried in the GEM glue for the gma500 driver so we now have 3 users (plus i915 can use it).
I agree with Sascha Hauer that a lot more could be shared with other (particularly future 'dumb') drivers. I think however it would be better to see what wants moving *after* such drivers are merged rather than guess in advance and do unneeded work and get it wrong anyway.
Forking is much easier than merging, so I really want to share as much as possible from the start. I'm not aware of any SoC having dedicated graphics memory, they all use system memory and the only difference I know is that some systems have a iommu and others don't.
Also, don't forget that we do not talk about three major graphic card vendors, but about dozens of SoC vendors with different graphic cores.
It's a nice reference driver for anyone else writing a DRM driver too.
Architecturally it's actually not quite as neat a fit for PC dumb devices as it might first seem though - in the PC world framebuffer case for a lot of cards I suspect you actually want to use real GEM objects.
In the PC case you do get multiple framebuffers allocated not all of which are in use so for cards with limited memory a true GEM object is useful. This would then be 'pinned' and 'unpinned' by copying it to/from video RAM and invalidating the mappings so mmap users fault with the new address next access)
/me has just learned something about GEM ;)
Sascha