Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-20-daniels@collabora.com
This isn't actually usable - we simply don't have the vmap space on a 32bit
system to do this stunt. Instead we will rely on the low level drivers
limiting the console resolution as before.
The real fix is for someone to write a page table aware version of the
framebuffer console blit functions. Good university student project
perhaps..
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We support 2D acceleration on some devices but we try and do tricks with
the GTT as a starting point as this is far faster. The GTT logic could be
improved further but for most display sizes it already makes a pretty good
decision.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Stone