> 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. 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) With that behaviour proper use can be made of video RAM and out of use objects can still be paged. For other cases it looks right as is. Alan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
