[PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

[Inki Dae]

> -----Original Message-----
> From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk]
> Sent: Thursday, August 04, 2011 3:54 AM
> To: daeinki
> Cc: Sascha Hauer; kyungmin.park at samsung.com; dri-
> devel at 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