-----Original Message----- From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] Sent: Thursday, August 04, 2011 3:54 AM To: daeinki Cc: Sascha Hauer; kyungmin.park@samsung.com; dri- devel@lists.freedesktop.org Subject: Re: [PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
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)
In fact, the FIMD and HDMI hardware on Samsung SoC EXYNOS4210 have no any their own video ram(maybe most of embedded systems) so that they use only system memory. Thank you for your explanation about pin/unpin. I could understand pin/unpin feature through you.
If so, I think the feature(that physical memory mapping is done at page fault handler of specific gem module) doesn't need for embedded systems without their own video memory and so they would need only the mapping way that user space would be mapped to physical memory directly not at the page fault handler once user requests specific mmap ioctl(not mmap system call). you can refer to i915_gem_mmap_ioctl() of i915/i915_gem.c for that.
Thank you for your comments.
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