All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: "Noralf Trønnes" <noralf@tronnes.org>,
	javierm@redhat.com, jfalempe@redhat.com,
	jose.exposito89@gmail.com, arthurgrillo@riseup.net,
	mairacanal@riseup.net, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, airlied@gmail.com, daniel@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 0/7] drm: Reuse temporary memory for format conversion
Date: Mon, 9 Oct 2023 09:53:56 +0200	[thread overview]
Message-ID: <39bd4c35-8a61-42ee-8675-ccea4f5d4ac6@suse.de> (raw)
In-Reply-To: <47a54b65-168f-4188-ad5c-79ba55d7a768@tronnes.org>


[-- Attachment #1.1: Type: text/plain, Size: 4723 bytes --]

Hi Noralf

Am 07.10.23 um 14:01 schrieb Noralf Trønnes:
> 
> 
> On 10/5/23 11:04, Thomas Zimmermann wrote:
>> DRM's format-conversion helpers require temporary memory. Pass the
>> buffer from the caller and keep it allocated over several calls. Allow
>> the caller to preallocate the buffer memory.
>>
>> The motivation for this patchset is the recent work on a DRM panic
>> handler. [1] The panic handler requires format conversion to display an
>> error to the screen. But allocating memory during kernel panics is
>> fragile. The changes in this patchset enable the DRM panic handler to
>> preallocate buffer storage before the panic occurs.
>>
> 
> I've been thinking about this and afaiu this requires the display hw to
> switch to the new panic buffer for scanout, right?
> I don't think that is possible for any complex hw to do in a panic
> situation. Or are you thinking that the driver should somehow "memcpy"
> this buffer to the actual scanout buffer?

It's all of that, but depends on the situation. In the easy case, we 
have a usable scanout buffer during the panic (e.g., XRGB888). We can 
use it for the panic screen.

If there's no such scanout programmed, we can attempt to set a new 
display mode. I think, it is best to leave these exact steps to the DRM 
driver. Some drivers might not be able to reprogram the display (e.g., 
with USB or I2C hardware).

In the panic handler, we copy glyphs into the scanout buffer and 
possibly convert the color format during that process. Without a working 
scanout buffer, the panic handler does nothing.

Best regards
Thomas


> 
> Noralf.
> 
>> As an additonal benefit, drivers can now keep the temporary storage
>> across multiple updates. Avoiding memory allocation slightly reduces
>> the CPU overhead of the format helpers.
>>
>> Patch 1 adds struct drm_format_conv_state, a simple interface to pass
>> around the buffer storage. Patch 2 adds an instance of the struct to
>> the shadow-plane state. Patch 3 moves the buffer's memory management
>> from the format helpers into their callers within the DRM drivers. Most
>> of the afected drivers use the state instance stored in their shadow-
>> plane state. The shadow-plane code releases the buffer memory automatically.
>>
>> Patches 4 to 7 update three drivers to preallocate the format-conversion
>> buffer in their plane's atomic_check function. The driver thus detects OOM
>> errors before the display update begins.
>>
>> Tested with simpledrm.
>>
>> v4:
>> 	* rename struct to drm_format_conv_state (Javier)
>> 	* replace ARRAY_SIZE() with sizeof() (Jani)
>> 	* store buffer in shadow-plane state (Javier, Maxime)
>> 	* prealloc in atomic_check in several drivers
>> v3:
>> 	* no changes
>> v2:
>> 	* reserve storage during probing in the drivers
>>
>> [1] https://patchwork.freedesktop.org/series/122244/
>>
>> Thomas Zimmermann (7):
>>    drm/format-helper: Cache buffers with struct drm_format_conv_state
>>    drm/atomic-helper: Add format-conversion state to shadow-plane state
>>    drm/format-helper: Pass format-conversion state to helpers
>>    drm/ofdrm: Preallocate format-conversion buffer in atomic_check
>>    drm/simpledrm: Preallocate format-conversion buffer in atomic_check
>>    drm/ssd130x: Fix atomic_check for disabled planes
>>    drm/ssd130x: Preallocate format-conversion buffer in atomic_check
>>
>>   drivers/gpu/drm/drm_format_helper.c           | 212 +++++++++++++-----
>>   drivers/gpu/drm/drm_gem_atomic_helper.c       |   9 +
>>   drivers/gpu/drm/drm_mipi_dbi.c                |  19 +-
>>   drivers/gpu/drm/gud/gud_pipe.c                |  30 ++-
>>   drivers/gpu/drm/solomon/ssd130x.c             |  36 ++-
>>   .../gpu/drm/tests/drm_format_helper_test.c    |  72 +++---
>>   drivers/gpu/drm/tiny/cirrus.c                 |   3 +-
>>   drivers/gpu/drm/tiny/ili9225.c                |  10 +-
>>   drivers/gpu/drm/tiny/ofdrm.c                  |  16 +-
>>   drivers/gpu/drm/tiny/repaper.c                |   8 +-
>>   drivers/gpu/drm/tiny/simpledrm.c              |  43 +++-
>>   drivers/gpu/drm/tiny/st7586.c                 |  19 +-
>>   include/drm/drm_format_helper.h               |  81 +++++--
>>   include/drm/drm_gem_atomic_helper.h           |  10 +
>>   include/drm/drm_mipi_dbi.h                    |   4 +-
>>   15 files changed, 428 insertions(+), 144 deletions(-)
>>
>>
>> base-commit: 57d3b83a83c5527325efb5bcaf594da09fe4a41b

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

      reply	other threads:[~2023-10-09  7:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05  9:04 [PATCH v4 0/7] drm: Reuse temporary memory for format conversion Thomas Zimmermann
2023-10-05  9:04 ` [PATCH v4 1/7] drm/format-helper: Cache buffers with struct drm_format_conv_state Thomas Zimmermann
2023-10-05 11:01   ` Noralf Trønnes
2023-10-05 13:18   ` Javier Martinez Canillas
2023-10-05 14:55     ` Thomas Zimmermann
2023-10-05 15:26       ` Javier Martinez Canillas
2023-10-05  9:04 ` [PATCH v4 2/7] drm/atomic-helper: Add format-conversion state to shadow-plane state Thomas Zimmermann
2023-10-05 11:02   ` Noralf Trønnes
2023-10-05 13:26   ` Javier Martinez Canillas
2023-10-05  9:04 ` [PATCH v4 3/7] drm/format-helper: Pass format-conversion state to helpers Thomas Zimmermann
2023-10-05 11:06   ` kernel test robot
2023-10-05 11:06     ` kernel test robot
2023-10-05 11:10   ` Noralf Trønnes
2023-10-05 11:15     ` Thomas Zimmermann
2023-10-05 13:28   ` Javier Martinez Canillas
2023-10-05  9:04 ` [PATCH v4 4/7] drm/ofdrm: Preallocate format-conversion buffer in atomic_check Thomas Zimmermann
2023-10-05 13:35   ` Javier Martinez Canillas
2023-10-05  9:04 ` [PATCH v4 5/7] drm/simpledrm: " Thomas Zimmermann
2023-10-05 13:38   ` Javier Martinez Canillas
2023-10-09  8:42     ` Thomas Zimmermann
2023-10-09  8:58       ` Javier Martinez Canillas
2023-10-09  9:16         ` Thomas Zimmermann
2023-10-09  9:24           ` Javier Martinez Canillas
2023-10-05  9:04 ` [PATCH v4 6/7] drm/ssd130x: Fix atomic_check for disabled planes Thomas Zimmermann
2023-10-05  9:15   ` Geert Uytterhoeven
2023-10-05 11:37   ` Javier Martinez Canillas
2023-10-05 11:54     ` Thomas Zimmermann
2023-10-05 12:54       ` Javier Martinez Canillas
2023-10-05 12:58         ` Javier Martinez Canillas
2023-10-05  9:04 ` [PATCH v4 7/7] drm/ssd130x: Preallocate format-conversion buffer in atomic_check Thomas Zimmermann
2023-10-05 11:43   ` Javier Martinez Canillas
2023-10-06 14:49 ` [PATCH v4 0/7] drm: Reuse temporary memory for format conversion Maxime Ripard
2023-10-09  8:23   ` Thomas Zimmermann
2023-10-10  9:55     ` Maxime Ripard
2023-10-07 12:01 ` Noralf Trønnes
2023-10-09  7:53   ` Thomas Zimmermann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39bd4c35-8a61-42ee-8675-ccea4f5d4ac6@suse.de \
    --to=tzimmermann@suse.de \
    --cc=airlied@gmail.com \
    --cc=arthurgrillo@riseup.net \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=jfalempe@redhat.com \
    --cc=jose.exposito89@gmail.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mairacanal@riseup.net \
    --cc=mripard@kernel.org \
    --cc=noralf@tronnes.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.