mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>
Subject: Re: [PATCH] drm: renesas: Extend RZ/G2L supported KMS formats
Date: Sat, 22 Mar 2025 00:33:20 +0200	[thread overview]
Message-ID: <20250321223320.GC11255@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20250321172220.867165-1-kieran.bingham@ideasonboard.com>

Hi Kieran,

Thank you for the patch.

On Fri, Mar 21, 2025 at 05:22:19PM +0000, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> 
> The RZ/G2L driver utilises the VSPD to read data from input sources.
> 
> The rzg2l_du_kms component lists a restricted subset of the capabilities
> of the VSPd which prevents additional formats from being used for

s/VSPd/VSPD/

> display planes.
> 
> The supported display plane formats are mapped in rzg2l_du_vsp_formats[].
> 
> Extend the rzg2l_du_format_infos[] table with the corresponding mappings
> between the supported DRM formats and the formats exposed by the VSP in
> rzg2l_du_vsp_formats, maintaining the same ordering in both tables.

Given the other replies to this patch, you may want to extend the commit
message to explain why this is fine, and how the VSPD will convert YUV
formats to RGB.

Now this makes realize we should implement support for colorspace in the
VSPD driver... It's a separate issue.

> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> ---
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 141 ++++++++++++++++++-
>  1 file changed, 136 insertions(+), 5 deletions(-)
> 
> Prior to this patch, kmstest reports all of these formats as supported
> by the Planes, but using them fails during rzg2l_du_fb_create() as the
> corresponding format isn't found in rzg2l_du_format_info.
> 
> This patch now lets me capture and render pixelformats from the Mali-C55
> direct to an attached DSI panel on the Kakip board.
> 
> Patch tested with kms-tests:
> 
> PYTHONPATH=/usr/lib/aarch64-linux-gnu/python3.11/site-packages ./tests/kms-test-formats.py 
> Testing plane formats: SUCCESS
> 
> admin@kakip:~/kms-tests$ cat FormatsTest.log 
> U [66.967523] Testing plane formats
> U [66.975763] Testing connector DSI-1, CRTC 36, mode 720x1280
> U [66.978480] Testing format PixelFormat.RGB332
> U [70.143998] Testing format PixelFormat.ARGB4444
> U [73.357056] Testing format PixelFormat.XRGB4444
> U [76.574944] Testing format PixelFormat.ARGB1555
> U [79.805636] Testing format PixelFormat.XRGB1555
> U [83.016599] Testing format PixelFormat.RGB565
> U [86.230362] Testing format PixelFormat.BGR888
> U [89.444673] Testing format PixelFormat.RGB888
> U [92.677093] Testing format PixelFormat.BGRA8888
> U [95.904745] Testing format PixelFormat.BGRX8888
> U [99.119926] Testing format PixelFormat.ARGB8888
> U [102.350298] Testing format PixelFormat.XRGB8888
> U [105.579499] Testing format PixelFormat.UYVY
> U [108.878654] Testing format PixelFormat.YUYV
> U [112.176515] Testing format PixelFormat.YVYU
> U [115.470090] Testing format PixelFormat.NV12
> U [118.767513] Testing format PixelFormat.NV21
> U [122.065851] Testing format PixelFormat.NV16
> U [125.364001] Testing format PixelFormat.NV61
> U [128.662145] Testing format PixelFormat.YUV420
> U [131.978102] Testing format PixelFormat.YVU420
> U [135.292284] Testing format PixelFormat.YUV422
> U [138.623485] Testing format PixelFormat.YVU422
> U [141.955083] Testing format PixelFormat.YUV444
> U [145.336759] Testing format PixelFormat.YVU444
> U [148.761832] Test completed successfully
> 
> 
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> index b1266fbd9598..a5e96f863172 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> @@ -36,8 +36,61 @@
>  
>  static const struct rzg2l_du_format_info rzg2l_du_format_infos[] = {
>  	{
> -		.fourcc = DRM_FORMAT_XRGB8888,
> -		.v4l2 = V4L2_PIX_FMT_XBGR32,
> +		.fourcc = DRM_FORMAT_RGB332,
> +		.v4l2 = V4L2_PIX_FMT_RGB332,
> +		.bpp = 8,
> +		.planes = 1,
> +		.hsub = 1,

hsub isn't used in the driver, should it be removed (in a separate patch
of course) ? Or is that a sign there's a bug somewhere ?

Actually, bpp isn't used either. Biju, could you look into this, and
check if we should remove the fields or use them ?

Regardless, with the commit message expanded,

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

> +	}, {
> +		.fourcc = DRM_FORMAT_ARGB4444,
> +		.v4l2 = V4L2_PIX_FMT_ARGB444,
> +		.bpp = 16,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_XRGB4444,
> +		.v4l2 = V4L2_PIX_FMT_XRGB444,
> +		.bpp = 16,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_ARGB1555,
> +		.v4l2 = V4L2_PIX_FMT_ARGB555,
> +		.bpp = 16,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_XRGB1555,
> +		.v4l2 = V4L2_PIX_FMT_XRGB555,
> +		.bpp = 16,
> +		.planes = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_RGB565,
> +		.v4l2 = V4L2_PIX_FMT_RGB565,
> +		.bpp = 16,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_BGR888,
> +		.v4l2 = V4L2_PIX_FMT_RGB24,
> +		.bpp = 24,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_RGB888,
> +		.v4l2 = V4L2_PIX_FMT_BGR24,
> +		.bpp = 24,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_BGRA8888,
> +		.v4l2 = V4L2_PIX_FMT_ARGB32,
> +		.bpp = 32,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_BGRX8888,
> +		.v4l2 = V4L2_PIX_FMT_XRGB32,
>  		.bpp = 32,
>  		.planes = 1,
>  		.hsub = 1,
> @@ -48,11 +101,89 @@ static const struct rzg2l_du_format_info rzg2l_du_format_infos[] = {
>  		.planes = 1,
>  		.hsub = 1,
>  	}, {
> -		.fourcc = DRM_FORMAT_RGB888,
> -		.v4l2 = V4L2_PIX_FMT_BGR24,
> -		.bpp = 24,
> +		.fourcc = DRM_FORMAT_XRGB8888,
> +		.v4l2 = V4L2_PIX_FMT_XBGR32,
> +		.bpp = 32,
>  		.planes = 1,
>  		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_UYVY,
> +		.v4l2 = V4L2_PIX_FMT_UYVY,
> +		.bpp = 16,
> +		.planes = 1,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_YUYV,
> +		.v4l2 = V4L2_PIX_FMT_YUYV,
> +		.bpp = 16,
> +		.planes = 1,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_YVYU,
> +		.v4l2 = V4L2_PIX_FMT_YVYU,
> +		.bpp = 16,
> +		.planes = 1,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_NV12,
> +		.v4l2 = V4L2_PIX_FMT_NV12M,
> +		.bpp = 12,
> +		.planes = 2,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_NV21,
> +		.v4l2 = V4L2_PIX_FMT_NV21M,
> +		.bpp = 12,
> +		.planes = 2,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_NV16,
> +		.v4l2 = V4L2_PIX_FMT_NV16M,
> +		.bpp = 16,
> +		.planes = 2,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_NV61,
> +		.v4l2 = V4L2_PIX_FMT_NV61M,
> +		.bpp = 16,
> +		.planes = 2,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_YUV420,
> +		.v4l2 = V4L2_PIX_FMT_YUV420M,
> +		.bpp = 12,
> +		.planes = 3,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_YVU420,
> +		.v4l2 = V4L2_PIX_FMT_YVU420M,
> +		.bpp = 12,
> +		.planes = 3,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_YUV422,
> +		.v4l2 = V4L2_PIX_FMT_YUV422M,
> +		.bpp = 16,
> +		.planes = 3,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_YVU422,
> +		.v4l2 = V4L2_PIX_FMT_YVU422M,
> +		.bpp = 16,
> +		.planes = 3,
> +		.hsub = 2,
> +	}, {
> +		.fourcc = DRM_FORMAT_YUV444,
> +		.v4l2 = V4L2_PIX_FMT_YUV444M,
> +		.bpp = 24,
> +		.planes = 3,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_YVU444,
> +		.v4l2 = V4L2_PIX_FMT_YVU444M,
> +		.bpp = 24,
> +		.planes = 3,
> +		.hsub = 1,
>  	}
>  };
>  

-- 
Regards,

Laurent Pinchart

  parent reply	other threads:[~2025-03-21 22:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21 17:22 Kieran Bingham
2025-03-21 18:40 ` Biju Das
2025-03-21 19:06   ` Kieran Bingham
2025-03-22 10:06     ` Biju Das
2025-03-21 22:33 ` Laurent Pinchart [this message]
2025-03-22  9:29   ` Biju Das
2025-03-22 10:12     ` Biju Das
2025-03-28 19:38 ` Lad, Prabhakar

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=20250321223320.GC11255@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®