[PATCH] drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series

[Dave Airlie]

On Mon, Apr 23, 2012 at 1:44 PM, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:
>> This driver has a slightly different design than other KMS drivers, but
>> future server chips will probably share similiar setup. As these GPUs commonly
>> have low video RAM, it doesn't make sense to put the kms console in VRAM
>> always. This driver places the kms console into system RAM, and does dirty
>
> What happens to mmap of the framebuffer in this case ?

the framebuffer only gets mmaped from the copy in main RAM, the mmap never
ends up in the in-VRAM object. I'll have to add defio support to make this work
properly now that I think about it a bit more, but defio isn't a major
amount of work.

>
>> updates to a copy in video RAM. When userspace sets a new scanout buffer,
>> it forcefully evicts the video RAM console, and X can create a framebuffer
>> that can use all of of video RAM.
>
> If the framebuffer memory points either at the real display or a TTM
> backing object depending upon where the framebuffer in question is
> currently living then you'd get
>
> - working mmap (at the expected speed)
> - the ability to page out the console buffer rather than burn 8MB or more
>  of main memory with fixed mappings (and precious vmalloc space on 32bit
>  at that) with GEM at least.

I'm not 100% sure what you are getting at here, currently we can't move
fbdev objects once exposed to userspace or to fbcon, thanks to some wonderful
API design way back, the mmaps on the fbdev device are direct to the VRAM
physical pages. Can't tear them down and move them into system RAM pages
at all easily.

>
> It seems to me you'd just need to flip the framebuffer base and also for
> the mmap to evict the object so that it faults back at the new
> mappinging. The rest is a copy in and out.
>
>> Either way I don't quite understand why the sysram is not GEM backed so
> that you can just unpin it when not displaying the framebuffer and let
> the kernel page it out ?

Because I'm not 100% sure nothing will get written to it, and if
something gets written
to it I'd rather not have to complicate the oops printing to have to
page in memory
from disk, when it might be the disk that caused the oops.

Dave.