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

[Alan Cox]

> 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 ?

> 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.

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 ?

Alan