All of lore.kernel.org
 help / color / mirror / Atom feed
From: Louis Chauvet <louis.chauvet@bootlin.com>
To: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: "Rodrigo Siqueira" <rodrigosiqueiramelo@gmail.com>,
	"Melissa Wen" <melissa.srw@gmail.com>,
	"Maíra Canal" <mairacanal@riseup.net>,
	"Haneen Mohammed" <hamohammed.sa@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	arthurgrillo@riseup.net, "Jonathan Corbet" <corbet@lwn.net>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	jeremie.dautheribes@bootlin.com, miquel.raynal@bootlin.com,
	thomas.petazzoni@bootlin.com
Subject: Re: [PATCH v2 4/9] drm/vkms: Add typedef and documentation for pixel_read and pixel_write functions
Date: Tue, 27 Feb 2024 16:02:13 +0100	[thread overview]
Message-ID: <Zd35ddrlHduMq3_Y@localhost.localdomain> (raw)
In-Reply-To: <20240226133646.174d3fb2.pekka.paalanen@collabora.com>

Le 26/02/24 - 13:36, Pekka Paalanen a écrit :
> On Fri, 23 Feb 2024 12:37:24 +0100
> Louis Chauvet <louis.chauvet@bootlin.com> wrote:
> 
> > Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the
> > compiler to check if the passed functions take the correct arguments.
> > Such typedefs will help ensuring consistency across the code base in
> > case of update of these prototypes.
> > 
> > Introduce a check around the get_pixel_*_functions to avoid using a
> > nullptr as a function.
> > 
> > Document for those typedefs.
> > 
> > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > ---
> >  drivers/gpu/drm/vkms/vkms_drv.h       | 23 +++++++++++++++++++++--
> >  drivers/gpu/drm/vkms/vkms_formats.c   |  8 ++++----
> >  drivers/gpu/drm/vkms/vkms_formats.h   |  4 ++--
> >  drivers/gpu/drm/vkms/vkms_plane.c     |  9 ++++++++-
> >  drivers/gpu/drm/vkms/vkms_writeback.c |  9 ++++++++-
> >  5 files changed, 43 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> > index 18086423a3a7..886c885c8cf5 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> > @@ -53,12 +53,31 @@ struct line_buffer {
> >  	struct pixel_argb_u16 *pixels;
> >  };
> >  
> > +/**
> > + * typedef pixel_write_t - These functions are used to read a pixel from a
> > + * `struct pixel_argb_u16*`, convert it in a specific format and write it in the @dst_pixels
> > + * buffer.
> > + *
> > + * @dst_pixel: destination address to write the pixel
> > + * @in_pixel: pixel to write
> > + */
> > +typedef void (*pixel_write_t)(u8 *dst_pixels, struct pixel_argb_u16 *in_pixel);
> 
> There are some inconsistencies in pixel_write_t and pixel_read_t. At
> this point of the series they still operate on a single pixel, but you
> use dst_pixels and src_pixels, plural. Yet the documentation correctly
> talks about processing a single pixel.

I will fix this for v4.
 
> I would also expect the source to be always const, but that's a whole
> another patch to change.

The v4 will contains a new patch "drm/vkms: Use const pointer for 
pixel_read and pixel_write functions"

[...]

> > diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c
> > index d5203f531d96..f68b1b03d632 100644
> > --- a/drivers/gpu/drm/vkms/vkms_plane.c
> > +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> > @@ -106,6 +106,13 @@ static void vkms_plane_atomic_update(struct drm_plane *plane,
> >  		return;
> >  
> >  	fmt = fb->format->format;
> > +	pixel_read_t pixel_read = get_pixel_read_function(fmt);
> > +
> > +	if (!pixel_read) {
> > +		DRM_WARN("Pixel format is not supported by VKMS planes. State is inchanged\n");
> 
> DRM_WARN() is the kernel equivalent to userspace assert(), right?

For the DRM_WARN it is just a standard prinkt(KERN_WARN, ...) (hidden 
behind drm internal macros).

> In that failing the check means an internal invariant was violated,
> which means a code bug in kernel?
>
> Maybe this could be more specific about what invariant was violated?
> E.g. atomic check should have rejected this attempt already.

I'm not an expert (yet) in DRM, so please correct me:
When atomic_update is called, the new state is always validated by 
atomic_check before? There is no way to pass something not validated by 
atomic_check to atomic_update? If this is the case, yes, it should be an 
ERROR and not a WARN as an invalid format passed the atomic_check 
verification.

If so, is this better?

	if (!pixel_read) {
		/*
		 * This is a bug as the vkms_plane_atomic_check must forbid all unsupported formats.
		 */
		DRM_ERROR("Pixel format %4cc is not supported by VKMS planes.\n", fmt);
		return;
	}

I will put the same code in vkms_writeback.c.

[...]

Kind regards,
Louis Chauvet


-- 
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2024-02-27 15:02 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 11:37 [PATCH v2 0/9] drm/vkms: Reimplement line-per-line pixel conversion for plane reading Louis Chauvet
2024-02-23 11:37 ` [PATCH v2 1/9] drm/vkms: Code formatting Louis Chauvet
2024-02-23 11:37 ` [PATCH v2 2/9] drm/vkms: Use drm_frame directly Louis Chauvet
2024-02-23 11:37 ` [PATCH v2 3/9] drm/vkms: write/update the documentation for pixel conversion and pixel write functions Louis Chauvet
2024-02-26 11:37   ` Pekka Paalanen
2024-02-27 15:02     ` Louis Chauvet
2024-02-29  8:48       ` Pekka Paalanen
2024-03-04 15:28         ` Louis Chauvet
2024-03-05  9:50           ` Pekka Paalanen
2024-03-06 17:29             ` Louis Chauvet
2024-03-07  8:42               ` Pekka Paalanen
2024-02-23 11:37 ` [PATCH v2 4/9] drm/vkms: Add typedef and documentation for pixel_read and pixel_write functions Louis Chauvet
2024-02-26 11:36   ` Pekka Paalanen
2024-02-27 15:02     ` Louis Chauvet [this message]
2024-02-29  9:07       ` Pekka Paalanen
2024-03-04 15:28         ` Louis Chauvet
2024-03-05  9:50           ` Pekka Paalanen
2024-02-23 11:37 ` [PATCH v2 5/9] drm/vkms: Re-introduce line-per-line composition algorithm Louis Chauvet
2024-02-23 11:49   ` Maíra Canal
2024-02-26 11:37   ` Pekka Paalanen
2024-02-27 15:02     ` Louis Chauvet
2024-02-29 10:21       ` Pekka Paalanen
2024-03-04 15:28         ` Louis Chauvet
2024-03-05 10:10           ` Pekka Paalanen
2024-03-06 17:29             ` Louis Chauvet
2024-02-23 11:37 ` [PATCH v2 6/9] drm/vkms: Add YUV support Louis Chauvet
2024-02-23 11:46   ` Thomas Zimmermann
2024-02-26 12:19   ` Pekka Paalanen
2024-02-27 15:02     ` Louis Chauvet
2024-02-27 20:01       ` Arthur Grillo
2024-02-29  1:52         ` Arthur Grillo
2024-02-29 12:12           ` Pekka Paalanen
2024-02-29 17:57             ` Arthur Grillo
2024-03-01 11:53               ` Pekka Paalanen
2024-03-02 14:14                 ` Arthur Grillo
2024-03-04 15:28             ` Louis Chauvet
2024-03-04 15:39               ` Arthur Grillo
2024-03-04 15:48                 ` Louis Chauvet
2024-03-04 16:51                   ` Arthur Grillo
2024-03-06 20:09                     ` Arthur Grillo
2024-03-07  0:03                       ` Louis Chauvet
2024-02-23 11:37 ` [PATCH v2 7/9] drm/vkms: Add range and encoding properties to pixel_read function Louis Chauvet
2024-02-26 12:23   ` Pekka Paalanen
2024-02-27 15:02     ` Louis Chauvet
2024-02-29 12:24       ` Pekka Paalanen
2024-03-04 15:29         ` Louis Chauvet
2024-02-23 11:37 ` [PATCH v2 8/9] drm/vkms: Drop YUV formats TODO Louis Chauvet
2024-02-23 11:37 ` [PATCH v2 9/9] drm/vkms: Create KUnit tests for YUV conversions Louis Chauvet
2024-02-26 16:39   ` Arthur Grillo
2024-02-27 15:02     ` Louis Chauvet
2024-02-23 11:52 ` [PATCH v2 0/9] drm/vkms: Reimplement line-per-line pixel conversion for plane reading Maira Canal

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=Zd35ddrlHduMq3_Y@localhost.localdomain \
    --to=louis.chauvet@bootlin.com \
    --cc=airlied@gmail.com \
    --cc=arthurgrillo@riseup.net \
    --cc=corbet@lwn.net \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=jeremie.dautheribes@bootlin.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mairacanal@riseup.net \
    --cc=melissa.srw@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=mripard@kernel.org \
    --cc=pekka.paalanen@collabora.com \
    --cc=rodrigosiqueiramelo@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    --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 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.