search for: drm_format_rgb565

Update the cirrus driver to follow current best practices. While the driver's hardware is obsolete, the cirrus driver is still one of the go-to modules to learn about writing a DRM driver. So keep it in good shape. Patches 1 to 3 simplify blitting and convert it to the DRM's current helpers. Patches 4 to 8 replace simple-KMS helpers with DRM's regular atomic helpers. The former are

...us/cirrus_mode.c index a830e70fc0..2e966a22c5 100644 --- a/drivers/gpu/drm/cirrus/cirrus_mode.c +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c @@ -360,10 +360,67 @@ static const struct drm_crtc_helper_funcs cirrus_helper_funcs = { }; /* CRTC setup */ +static const uint32_t cirrus_formats_16[] = { + DRM_FORMAT_RGB565, +}; + +static const uint32_t cirrus_formats_24[] = { + DRM_FORMAT_RGB888, +}; + +static const uint32_t cirrus_formats_32[] = { + DRM_FORMAT_XRGB8888, + DRM_FORMAT_ARGB8888, +}; + +static struct drm_plane *cirrus_primary_plane(struct drm_device *dev) +{ + const uint32_t *formats; + uint32_t nformat...

...er to video memory. Does it get any slower, with TTM I just wrote it to migrate just the frontbuffer in/out of VRAM on modeset, won't we end up with more copies now? > - All gem objects are stored in main memory and are manged using the > new shmem helpers. ttm is out. > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does > that too by default. There was a module parameter which enables 24/32 > bpp support and disables higher resolutions (due to cirrus hardware > constrains). That parameter wasn't reimplemented. This might be the big sticking poin...

...ut of video memory (4 MB) the cirrus device has the rewritten driver doesn't try to manage buffers there. Instead it will blit (memcpy) the active framebuffer to video memory. - All gem objects are stored in main memory and are manged using the new shmem helpers. ttm is out. - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does that too by default. There was a module parameter which enables 24/32 bpp support and disables higher resolutions (due to cirrus hardware constrains). That parameter wasn't reimplemented. - The simple display pipeline is used. - The gen...

...ut of video memory (4 MB) the cirrus device has the rewritten driver doesn't try to manage buffers there. Instead it will blit (memcpy) the active framebuffer to video memory. - All gem objects are stored in main memory and are manged using the new shmem helpers. ttm is out. - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does that too by default. There was a module parameter which enables 24/32 bpp support and disables higher resolutions (due to cirrus hardware constrains). That parameter wasn't reimplemented. - The simple display pipeline is used. - The gen...

On Wed, 3 Apr 2019 at 16:12, Adam Jackson <ajax at redhat.com> wrote: > On Wed, 2019-04-03 at 09:23 +0200, Gerd Hoffmann wrote: > > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does > > that too by default. There was a module parameter which enables 24/32 > > bpp support and disables higher resolutions (due to cirrus hardware > > constrains). That parameter wasn't reimplemented. > > One slight...

...tes with page flips (i.e wayland) should end up with less copying, because you have one copy (blit) instead of two copies (migrate old frontbuffer out of vram, migrate new frontbuffer into vram) on pageflip. Speaking of wayland: Seems at least gnome-shell insists on using XR24. > > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does > > that too by default. There was a module parameter which enables 24/32 > > bpp support and disables higher resolutions (due to cirrus hardware > > constrains). That parameter wasn't reimplemented. > This might be...

...the cirrus device has > the rewritten driver doesn't try to manage buffers there. Instead > it will blit (memcpy) the active framebuffer to video memory. > - All gem objects are stored in main memory and are manged using the > new shmem helpers. ttm is out. > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does > that too by default. There was a module parameter which enables 24/32 > bpp support and disables higher resolutions (due to cirrus hardware > constrains). That parameter wasn't reimplemented. > - The simple display pipeline...

...uffer > into vram) on pageflip. > > Speaking of wayland: Seems at least gnome-shell insists on using XR24. Yeah XR24 is pretty much mandatory. Noralf added a few helpers to convert XR24 to other formats, for display not supporting anything else. Because userspace. > > > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does > > > that too by default. There was a module parameter which enables 24/32 > > > bpp support and disables higher resolutions (due to cirrus hardware > > > constrains). That parameter wasn't reimplemented. >...

...uffer > into vram) on pageflip. > > Speaking of wayland: Seems at least gnome-shell insists on using XR24. Yeah XR24 is pretty much mandatory. Noralf added a few helpers to convert XR24 to other formats, for display not supporting anything else. Because userspace. > > > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does > > > that too by default. There was a module parameter which enables 24/32 > > > bpp support and disables higher resolutions (due to cirrus hardware > > > constrains). That parameter wasn't reimplemented. >...

...ev->event_lock); + } +} + +static const struct drm_simple_display_pipe_funcs cirrus_pipe_funcs = { + .mode_valid = cirrus_pipe_mode_valid, + .check = cirrus_pipe_check, + .enable = cirrus_pipe_enable, + .update = cirrus_pipe_update, +}; + +static const uint32_t cirrus_formats[] = { + DRM_FORMAT_RGB565, + DRM_FORMAT_RGB888, + DRM_FORMAT_XRGB8888, +}; + +static const uint64_t cirrus_modifiers[] = { + DRM_FORMAT_MOD_LINEAR, + DRM_FORMAT_MOD_INVALID +}; + +static int cirrus_pipe_init(struct cirrus_device *cirrus) +{ + return drm_simple_display_pipe_init(&cirrus->dev, + &cirrus-&gt...

...e->event = NULL; + } +} + +static const struct drm_simple_display_pipe_funcs cirrus_pipe_funcs = { + .mode_valid = cirrus_pipe_mode_valid, + .check = cirrus_pipe_check, + .enable = cirrus_pipe_enable, + .update = cirrus_pipe_update, +}; + +static const uint32_t cirrus_formats[] = { + DRM_FORMAT_RGB565, + DRM_FORMAT_RGB888, + DRM_FORMAT_XRGB8888, +}; + +static const uint64_t cirrus_modifiers[] = { + DRM_FORMAT_MOD_LINEAR, + DRM_FORMAT_MOD_INVALID +}; + +static int cirrus_pipe_init(struct cirrus_device *cirrus) +{ + return drm_simple_display_pipe_init(&cirrus->dev, + &cirrus-&gt...

This came out of some debugging I was doing to figure out how BE mode works on this hardware. Among other things, it came out that we're not exposing 16-bpp mode support and that the ARGB8888 mode that we do expose is broken. Also the overlay logic was pretty broken, I must have only tested with very "normal" overlay buffer sizes with modetest before. That said, this code has only

This was all kicked off by me figuring out how the PPC byteswap thing worked. In the end, we're keeping the implicit byteswap based on architecture, but also expose the correctly supported formats, and fix some overlay details. Overlay framebuffers have various funky requirements that should be enforced at framebuffer creation time (these are set apart by their YUV formats). Further, I

This came out of some debugging I was doing to figure out how BE mode works on this hardware. Among other things, it came out that we're not exposing 16-bpp mode support and that the ARGB8888 mode that we do expose is broken. Also the overlay logic was pretty broken, I must have only tested with very "normal" overlay buffer sizes with modetest before. That said, this code has only