ping for a review

Am 23.04.26 um 15:58 schrieb Thomas Zimmermann:
A client buffer holds the DRM framebuffer for an in-kernel DRM
client. Until now, omapdrm created an internal ad-hoc framebuffer for
its fbdev emulation, while by-passing the regular interfaces used by
user-space compositors.

Convert omapdrm's fbdev emulation to use client buffers. Replacing the
existing code with a client buffer allows for stream-lining omapdrm code
and later also the fbdev helpers. The new framebuffer will be registered
against the client's file and will support handles for GEM objects. It
is then just another framebuffer within the DRM ecosystem.

If all driver's fbdev-emulation helpers can be converted to use client
buffers, the emulation's framebuffer handling as a whole can possibly be
moved into shared helpers.

Patches 1 and 2 convert omapdrm's fbdev emulation to client buffers. It
still allocates a GEM object buffer tailored towards fbdev emulation,
but size calculations now use common DRM helpers.

Patch 3 cleans up symbol visibility in omapdrm's fb code.

Thomas Zimmermann (3):
   drm/omapdrm: fbdev: Calculate buffer geometry with format helpers
   drm/omapdrm: fbdev: Use a DRM client buffer
   drm/omapdrm: Make omap_framebuffer_init() an internal interface

  drivers/gpu/drm/omapdrm/omap_fb.c    | 68 +++++++++----------
  drivers/gpu/drm/omapdrm/omap_fb.h    |  3 -
  drivers/gpu/drm/omapdrm/omap_fbdev.c | 98 +++++++++++++++-------------
  3 files changed, 88 insertions(+), 81 deletions(-)


--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)


Reply via email to