lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <qij3fk3psujfazigjt56hrpj2celdeyvsz3uzioo5aorbzzwql@kbglyrbkd6g6>
Date: Tue, 4 Jun 2024 00:47:02 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: noralf@...nnes.org
Cc: Neil Armstrong <neil.armstrong@...aro.org>, 
	Jessica Zhang <quic_jesszhan@...cinc.com>, Sam Ravnborg <sam@...nborg.org>, 
	David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	David Lechner <david@...hnology.com>, dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Kamlesh Gurudasani <kamlesh.gurudasani@...il.com>, 
	Tommaso Merciai <tommaso.merciai@...rulasolutions.com>
Subject: Re: [PATCH v3 4/5] drm/mipi-dbi: Add support for DRM_FORMAT_RGB888

On Mon, Jun 03, 2024 at 01:21:35PM +0200, Noralf Trønnes via B4 Relay wrote:
> From: Noralf Trønnes <noralf@...nnes.org>
> 
> DRM_FORMAT_RGB888 is 24 bits per pixel and it would be natural to send it
> on the SPI bus using a 24 bits per word transfer. The problem with this
> is that not all SPI controllers support 24 bpw.
> 
> Since DRM_FORMAT_RGB888 is stored in memory as little endian and the SPI
> bus is big endian we use 8 bpw to always get the same pixel format on the
> bus: b8g8r8.
> 
> The MIPI DCS specification lists the standard commands that can be sent
> over the MIPI DBI interface. The set_address_mode (36h) command has one
> bit in the parameter that controls RGB/BGR order. This means that the
> controller can be configured to receive the pixel as BGR.
> 
> RGB888 is rarely supported on these controllers but RGB666 is very common.
> All datasheets I have seen do at least support the pixel format option
> where each color is sent as one byte and the 6 MSB's are used.
> 
> All this put together means that we can send each pixel as b8g8r8 and an
> RGB666 capable controller sees this as b6x2g6x2r6x2.
> 
> Signed-off-by: Noralf Trønnes <noralf@...nnes.org>
> ---
>  drivers/gpu/drm/drm_mipi_dbi.c | 29 +++++++++++++++++++++++++----
>  include/drm/drm_mipi_dbi.h     |  5 +++++
>  2 files changed, 30 insertions(+), 4 deletions(-)

The patch generally LGTM. The only nit is the name of
'emulation_format'. My first impression was that it is a format that the
driver is emulating to userspace, however it looks like this is
over-the-wire format (with the RGB666 vs RGB888 note kept in mind).

If my understanding is correct, I'd suggest renaming emulation_format
to something like 'raw_format' or 'panel_format'.

> 
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 77f8a828d6e0..eb330676857c 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -206,6 +206,7 @@ int mipi_dbi_buf_copy(void *dst, struct iosys_map *src, struct drm_framebuffer *
>  		      struct drm_rect *clip, bool swap,
>  		      struct drm_format_conv_state *fmtcnv_state)
>  {
> +	struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
>  	struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
>  	struct iosys_map dst_map = IOSYS_MAP_INIT_VADDR(dst);
>  	int ret;
> @@ -222,8 +223,18 @@ int mipi_dbi_buf_copy(void *dst, struct iosys_map *src, struct drm_framebuffer *
>  		else
>  			drm_fb_memcpy(&dst_map, NULL, src, fb, clip);
>  		break;
> +	case DRM_FORMAT_RGB888:
> +		drm_fb_memcpy(&dst_map, NULL, src, fb, clip);
> +		break;
>  	case DRM_FORMAT_XRGB8888:
> -		drm_fb_xrgb8888_to_rgb565(&dst_map, NULL, src, fb, clip, fmtcnv_state, swap);
> +		switch (dbidev->emulation_format) {
> +		case DRM_FORMAT_RGB565:
> +			drm_fb_xrgb8888_to_rgb565(&dst_map, NULL, src, fb, clip, fmtcnv_state, swap);
> +			break;
> +		case DRM_FORMAT_RGB888:
> +			drm_fb_xrgb8888_to_rgb888(&dst_map, NULL, src, fb, clip, fmtcnv_state);
> +			break;
> +		}
>  		break;
>  	default:
>  		drm_err_once(fb->dev, "Format is not supported: %p4cc\n",

[skipped]

> diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
> index b36596efdcc3..85bf19b98cee 100644
> --- a/include/drm/drm_mipi_dbi.h
> +++ b/include/drm/drm_mipi_dbi.h
> @@ -101,6 +101,11 @@ struct mipi_dbi_dev {
>  	 */
>  	struct drm_display_mode mode;
>  
> +	/**
> +	 * @emulation_format: Pixel format to use when emulating XRGB8888
> +	 */
> +	u32 emulation_format;
> +
>  	/**
>  	 * @tx_buf: Buffer used for transfer (copy clip rect area)
>  	 */
> 
> -- 
> 2.45.1
> 
> 

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ