From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <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, noralf@tronnes.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 1/5] drm/format-helper: Add struct drm_xfrm_buf to cache format conversion
Date: Wed, 4 Oct 2023 09:08:55 +0200 [thread overview]
Message-ID: <779d4fea-fb56-4e8d-8b01-34e13c027d30@suse.de> (raw)
In-Reply-To: <87jzs94c64.fsf@minerva.mail-host-address-is-not-set>
[-- Attachment #1.1: Type: text/plain, Size: 2446 bytes --]
Hi Javier
Am 29.09.23 um 10:27 schrieb Javier Martinez Canillas:
> Thomas Zimmermann <tzimmermann@suse.de> writes:
>
>> Hold temporary memory for format conversion in an instance of struct
>> drm_xfrm_buf. Update internal helpers of DRM's format-conversion code
>> accordingly. Drivers will later be able to keep this cache across
>> display updates.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>
> [...]
>
>> +int drmm_xfrm_buf_init(struct drm_device *dev, struct drm_xfrm_buf *buf)
>> +{
>> + buf->mem = NULL;
>> + buf->size = 0;
>> + buf->preallocated = false;
>> +
>> + return drmm_add_action_or_reset(dev, drm_xfrm_buf_init_release, buf);
>> +}
>> +EXPORT_SYMBOL(drmm_xfrm_buf_init);
>> +
>
> Can we find a better name than xfrm? I know that this is what's used in
> the internal drm_format_helper.c helpers but if we are exposing this to
> drivers, then I think that the naming is not self explanatory.
>
>> +/**
>> + * drm_xfrm_buf_reserve - Allocates storage in an xfrm buffer
>> + * @buf: The xfrm buffer
>
> At least in the kernel-doc we can say "The buffer used for pixel format
> conversion" or something along those lines.
>
> [...]
>
>> +/**
>> + * struct drm_xfrm_buf - Stores transformation and conversion state
>> + *
>> + * DRM helpers for format conversion store temporary state in
>> + * struct drm_xfrm_buf. The buffer's resources can be reused
>
> And same here. Maybe struct drm_fmt_conversion_buf ?
I find this name to be unpleasant to read. Can we use
drm_format_conv_state or drm_fmtcnv_state?
In the discussion about the panic handler, I mentioned that the struct
can be used to store more inforamtion, such as palette entries or fg/bg
colors. That would enable support for converting indexed formats, hence
the _state postfix.
In the longer term, I'd also like to replace the drm_framebuffer from
the API and then rename the functions to something like
drm_fmtcnv_<x>_to_<y>(). The framebuffer really doesn't make much sense
any longer.
Best regards
Thomas
>
> Other than this nit, the patch looks good to me.
>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>
--
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 --]
next prev parent reply other threads:[~2023-10-04 7:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 14:24 [PATCH v2 0/5] drm: Reuse temporary memory for format conversion Thomas Zimmermann
2023-09-20 14:24 ` [PATCH v2 1/5] drm/format-helper: Add struct drm_xfrm_buf to cache " Thomas Zimmermann
2023-09-29 8:27 ` Javier Martinez Canillas
2023-10-04 7:08 ` Thomas Zimmermann [this message]
2023-10-04 7:30 ` Javier Martinez Canillas
2023-09-20 14:24 ` [PATCH v2 2/5] drm/format-helper: Pass xfrm buffer to format-conversion helpers Thomas Zimmermann
2023-09-29 9:04 ` Javier Martinez Canillas
2023-09-20 14:24 ` [PATCH v2 3/5] drm/simpledrm: Store xfrm buffer in device instance Thomas Zimmermann
2023-09-26 7:31 ` Jocelyn Falempe
2023-09-28 8:15 ` Thomas Zimmermann
2023-09-20 14:24 ` [PATCH v2 4/5] drm/ofdrm: " Thomas Zimmermann
2023-09-20 14:24 ` [PATCH v2 5/5] drm/ssd130x: " Thomas Zimmermann
2023-09-29 9:16 ` Javier Martinez Canillas
2023-09-26 7:28 ` [PATCH v2 0/5] drm: Reuse temporary memory for format conversion Jocelyn Falempe
2023-09-29 12:11 ` Maxime Ripard
2023-09-29 14:58 ` Thomas Zimmermann
2023-10-02 13:24 ` Maxime Ripard
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=779d4fea-fb56-4e8d-8b01-34e13c027d30@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.