dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: geert+renesas@glider.be, airlied@linux.ie,
	emil.l.velikov@gmail.com, dri-devel@lists.freedesktop.org,
	lgirdwood@gmail.com, hdegoede@redhat.com, broonie@kernel.org,
	kraxel@redhat.com, sam@ravnborg.org
Subject: Re: [PATCH 2/9] drm/format-helper: Add blitter functions
Date: Mon, 29 Jun 2020 10:46:58 +0200	[thread overview]
Message-ID: <20200629084658.GM3278063@phenom.ffwll.local> (raw)
In-Reply-To: <20200625120011.16168-3-tzimmermann@suse.de>

On Thu, Jun 25, 2020 at 02:00:04PM +0200, Thomas Zimmermann wrote:
> The blitter functions copy a framebuffer to I/O memory using one of
> the existing conversion functions.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Hm I guess reason for adding dst_pitch in the previous patch is so that
there wouldn't be a special case here. Makes sense.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> ---
>  drivers/gpu/drm/drm_format_helper.c | 87 +++++++++++++++++++++++++++++
>  include/drm/drm_format_helper.h     |  8 +++
>  2 files changed, 95 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_format_helper.c b/drivers/gpu/drm/drm_format_helper.c
> index 8d5a683afea7..0e885cd34107 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -344,3 +344,90 @@ void drm_fb_xrgb8888_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
>  }
>  EXPORT_SYMBOL(drm_fb_xrgb8888_to_gray8);
>  
> +/**
> + * drm_fb_blit_rect_dstclip - Copy parts of a framebuffer to display memory
> + * @dst:	The display memory to copy to
> + * @dst_pitch:	Number of bytes between two consecutive scanlines within dst
> + * @dst_format:	FOURCC code of the display's color format
> + * @vmap:	The framebuffer memory to copy from
> + * @fb:		The framebuffer to copy from
> + * @clip:	Clip rectangle area to copy
> + *
> + * This function copies parts of a framebuffer to display memory. If the
> + * formats of the display and the framebuffer mismatch, the blit function
> + * will attempt to convert between them.
> + *
> + * Use drm_fb_blit_dstclip() to copy the full framebuffer.
> + *
> + * Returns:
> + * 0 on success, or
> + * -EINVAL if the color-format conversion failed, or
> + * a negative error code otherwise.
> + */
> +int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
> +			     uint32_t dst_format, void *vmap,
> +			     struct drm_framebuffer *fb,
> +			     struct drm_rect *clip)
> +{
> +	uint32_t fb_format = fb->format->format;
> +
> +	/* treat alpha channel like filler bits */
> +	if (fb_format == DRM_FORMAT_ARGB8888)
> +		fb_format = DRM_FORMAT_XRGB8888;
> +	if (dst_format == DRM_FORMAT_ARGB8888)
> +		dst_format = DRM_FORMAT_XRGB8888;
> +
> +	if (dst_format == fb_format) {
> +		drm_fb_memcpy_dstclip(dst, dst_pitch, vmap, fb, clip);
> +		return 0;
> +
> +	} else if (dst_format == DRM_FORMAT_RGB565) {
> +		if (fb_format == DRM_FORMAT_XRGB8888) {
> +			drm_fb_xrgb8888_to_rgb565_dstclip(dst, dst_pitch,
> +							  vmap, fb, clip,
> +							  false);
> +			return 0;
> +		}
> +	} else if (dst_format == DRM_FORMAT_RGB888) {
> +		if (fb_format == DRM_FORMAT_XRGB8888) {
> +			drm_fb_xrgb8888_to_rgb888_dstclip(dst, dst_pitch,
> +							  vmap, fb, clip);
> +			return 0;
> +		}
> +	}
> +
> +	return -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_fb_blit_rect_dstclip);
> +
> +/**
> + * drm_fb_blit_dstclip - Copy framebuffer to display memory
> + * @dst:	The display memory to copy to
> + * @dst_pitch:	Number of bytes between two consecutive scanlines within dst
> + * @dst_format:	FOURCC code of the display's color format
> + * @vmap:	The framebuffer memory to copy from
> + * @fb:		The framebuffer to copy from
> + *
> + * This function copies a full framebuffer to display memory. If the formats
> + * of the display and the framebuffer mismatch, the copy function will
> + * attempt to convert between them.
> + *
> + * See drm_fb_blit_rect_dstclip() for more inforamtion.
> + *
> + * Returns:
> + * 0 on success, or a negative error code otherwise.
> + */
> +int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
> +			uint32_t dst_format, void *vmap,
> +			struct drm_framebuffer *fb)

I do wonder whether we shouldn't have to some safety checks for this
stuff, like maybe something like:

struct dst_info {
	void __iomem *dst;
	unsigned int size;
	unsigned int dst_pitch;
	uint32_t dst_format;
};

And then the helpers would splat a WARNING if a driver ever gets this
wrong. Thinking about this because syzkaller has found tons of little
off-by-a-bit bugs in the vt/fbcon/fbdev code, and maybe we should try to
be better :-)

But that's material for another patch, and maybe once we have a few more
helpers in this library we can figure out a nice struct to package up
these long&confusing argument lists a bit.

Cheers, Daniel

> +{
> +	struct drm_rect fullscreen = {
> +		.x1 = 0,
> +		.x2 = fb->width,
> +		.y1 = 0,
> +		.y2 = fb->height,
> +	};
> +	return drm_fb_blit_rect_dstclip(dst, dst_pitch, dst_format, vmap, fb,
> +					&fullscreen);
> +}
> +EXPORT_SYMBOL(drm_fb_blit_dstclip);
> diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
> index 2b5036a5fbe7..4e0258a61311 100644
> --- a/include/drm/drm_format_helper.h
> +++ b/include/drm/drm_format_helper.h
> @@ -28,4 +28,12 @@ void drm_fb_xrgb8888_to_rgb888_dstclip(void __iomem *dst, unsigned int dst_pitch
>  void drm_fb_xrgb8888_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
>  			      struct drm_rect *clip);
>  
> +int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
> +			     uint32_t dst_format, void *vmap,
> +			     struct drm_framebuffer *fb,
> +			     struct drm_rect *rect);
> +int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
> +			uint32_t dst_format, void *vmap,
> +			struct drm_framebuffer *fb);
> +
>  #endif /* __LINUX_DRM_FORMAT_HELPER_H */
> -- 
> 2.27.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-06-29  8:47 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 12:00 [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs Thomas Zimmermann
2020-06-25 12:00 ` [PATCH 1/9] drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip() Thomas Zimmermann
2020-06-29  8:40   ` Daniel Vetter
2020-09-25 14:55     ` Thomas Zimmermann
2020-09-26 16:42       ` Daniel Vetter
2020-09-28  7:22         ` Thomas Zimmermann
2020-09-28  8:53           ` Daniel Vetter
2020-09-28  9:13             ` Thomas Zimmermann
2020-09-29  9:19               ` Daniel Vetter
2020-09-29  9:39                 ` Thomas Zimmermann
2020-09-29 11:32                   ` Daniel Vetter
2020-09-28 10:24             ` Gerd Hoffmann
2020-09-28 13:42               ` Pekka Paalanen
2020-06-25 12:00 ` [PATCH 2/9] drm/format-helper: Add blitter functions Thomas Zimmermann
2020-06-29  8:46   ` Daniel Vetter [this message]
2020-06-25 12:00 ` [PATCH 3/9] drm: Add simplekms driver Thomas Zimmermann
2020-06-29  9:06   ` Daniel Vetter
2020-09-25 15:01     ` Thomas Zimmermann
2020-09-25 15:14       ` Maxime Ripard
2020-09-28  7:25         ` Thomas Zimmermann
2021-02-10 16:14     ` Thomas Zimmermann
2020-06-25 12:00 ` [PATCH 4/9] drm/simplekms: Add fbdev emulation Thomas Zimmermann
2020-06-29  9:11   ` Daniel Vetter
2020-06-25 12:00 ` [PATCH 5/9] drm/simplekms: Initialize framebuffer data from device-tree node Thomas Zimmermann
2020-06-30  2:36   ` Rob Herring
2020-06-25 12:00 ` [PATCH 6/9] drm/simplekms: Acquire clocks from DT device node Thomas Zimmermann
2020-06-25 13:34   ` Geert Uytterhoeven
2020-06-29  9:07     ` Daniel Vetter
2020-06-25 12:00 ` [PATCH 7/9] drm/simplekms: Acquire regulators " Thomas Zimmermann
2020-06-25 13:36   ` Geert Uytterhoeven
2020-06-25 12:00 ` [PATCH 8/9] drm: Add infrastructure for platform devices Thomas Zimmermann
2020-06-29  9:27   ` Daniel Vetter
2020-09-28  8:40     ` Thomas Zimmermann
2020-09-28  8:50       ` Daniel Vetter
2020-09-28  9:14         ` Thomas Zimmermann
2020-09-29  8:59     ` Thomas Zimmermann
2020-09-29  9:20       ` Daniel Vetter
2020-06-30  9:11   ` Daniel Vetter
2020-06-25 12:00 ` [PATCH 9/9] drm/simplekms: Acquire memory aperture for framebuffer Thomas Zimmermann
2020-06-29  9:22   ` Daniel Vetter
2020-06-29 16:04     ` Greg KH
2020-06-29 16:23       ` Mark Brown
2020-06-29 16:57         ` Greg KH
2020-06-30  2:13       ` Rob Herring
2020-06-30  8:50         ` Greg KH
2020-06-29  9:38 ` [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs Hans de Goede
2020-06-30  9:06   ` Daniel Vetter
2020-06-30  9:13     ` Hans de Goede
2020-07-01 14:10     ` Thomas Zimmermann
2020-07-03 10:55       ` Hans de Goede
2020-07-03 11:42         ` Thomas Zimmermann
2020-07-03 12:58         ` Daniel Vetter
2020-07-03 14:11           ` Hans de Goede
2020-07-01 13:48   ` Thomas Zimmermann
2020-07-03 10:44     ` Hans de Goede

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=20200629084658.GM3278063@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@linux.ie \
    --cc=broonie@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=hdegoede@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lgirdwood@gmail.com \
    --cc=sam@ravnborg.org \
    --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