Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(),
which uses bpp and depth to guess the wanted buffer format.
However, drm_client_buffer_addfb() already knows the exact buffer
format, so there is no need to convert back and forth between buffer
format and bpp/depth, and the function can just call drm_mode_addfb2()
directly instead.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 drivers/gpu/drm/drm_client.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index f6292ba0e6fc3783..de660a25ad7c6f06 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -374,19 +374,16 @@ static int drm_client_buffer_addfb(struct drm_client_buffer *buffer,
 				   u32 handle)
 {
 	struct drm_client_dev *client = buffer->client;
-	struct drm_mode_fb_cmd fb_req = { };
-	const struct drm_format_info *info;
+	struct drm_mode_fb_cmd2 fb_req = { };
 	int ret;
 
-	info = drm_format_info(format);
-	fb_req.bpp = drm_format_info_bpp(info, 0);
-	fb_req.depth = info->depth;
 	fb_req.width = width;
 	fb_req.height = height;
-	fb_req.handle = handle;
-	fb_req.pitch = buffer->pitch;
+	fb_req.pixel_format = format;
+	fb_req.handles[0] = handle;
+	fb_req.pitches[0] = buffer->pitch;
 
-	ret = drm_mode_addfb(client->dev, &fb_req, client->file);
+	ret = drm_mode_addfb2(client->dev, &fb_req, client->file);
 	if (ret)
 		return ret;
 
-- 
2.34.1

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(),
> which uses bpp and depth to guess the wanted buffer format.
> However, drm_client_buffer_addfb() already knows the exact buffer
> format, so there is no need to convert back and forth between buffer
> format and bpp/depth, and the function can just call drm_mode_addfb2()
> directly instead.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
>  drivers/gpu/drm/drm_client.c | 13 +++++--------
>  1 file changed, 5 insertions(+), 8 deletions(-)
>

Nice cleanup!

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

On Thursday, July 13th, 2023 at 15:17, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(),
> which uses bpp and depth to guess the wanted buffer format.
> However, drm_client_buffer_addfb() already knows the exact buffer
> format, so there is no need to convert back and forth between buffer
> format and bpp/depth, and the function can just call drm_mode_addfb2()
> directly instead.

By any chance, is the commit message wrong? The title refers to
drm_mode_create_dumb(), but the description and code refer to
drm_client_buffer_addfb().

Hi Simon,

On Fri, Jul 14, 2023 at 1:01 PM Simon Ser <contact@emersion.fr> wrote:
> On Thursday, July 13th, 2023 at 15:17, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(),
> > which uses bpp and depth to guess the wanted buffer format.
> > However, drm_client_buffer_addfb() already knows the exact buffer
> > format, so there is no need to convert back and forth between buffer
> > format and bpp/depth, and the function can just call drm_mode_addfb2()
> > directly instead.
>
> By any chance, is the commit message wrong? The title refers to
> drm_mode_create_dumb(), but the description and code refer to
> drm_client_buffer_addfb().

Yes it is, thanks.  Originally, I had copied-and-pasted the wrong
function name. I thought I had fixed all references, but apparently
I missed the one-line summary :-(

Will fix in v2.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds