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 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
