Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Chen-Yu Tsai <wenst@chromium.org>, Liu Ying <victor.liu@nxp.com>,
	Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Chen-Yu Tsai <wens@kernel.org>,
	Jernej Skrabec <jernej@kernel.org>,
	Samuel Holland <samuel@sholland.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	linux-sunxi@lists.linux.dev, imx@lists.linux.dev,
	dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/4] drm/fb-dma-helper: Add drm_fb_dma_get_gem_clipped_addr()
Date: Tue, 8 Sep 2026 11:41:56 +0200	[thread overview]
Message-ID: <d3e13d97-72c4-4a14-8de2-b509ef3e8759@suse.de> (raw)
In-Reply-To: <20260908090745.1089143-2-wenst@chromium.org>

Hi

Am 08.09.26 um 11:07 schrieb Chen-Yu Tsai:
> drm_fb_dma_get_gem_addr() returns the DMA address to the "unclipped"
> framebuffer. However some display drivers want the "clipped" framebuffer
> instead, as they are also using the clipped coordinates to program the
> hardware.
>
> Some of these drivers are open-coding drm_fb_dma_get_gem_addr() with
> the source coordinates replaced, while others have been incorrectly
> converted to using drm_fb_dma_get_gem_addr(), which would end up
> causing incorrect parts of the framebuffer to be displayed if it were
> somehow clipped.
>
> Add drm_fb_dma_get_gem_clipped_addr(), a "clipped" version of
> drm_fb_dma_get_gem_addr() for these drivers to use.
>
> Cc: <stable@vger.kernel.org> # dependency for next patch
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
>   drivers/gpu/drm/drm_fb_dma_helper.c | 63 +++++++++++++++++++++--------
>   include/drm/drm_fb_dma_helper.h     |  4 ++
>   2 files changed, 51 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c b/drivers/gpu/drm/drm_fb_dma_helper.c
> index fd71969d2fb1..a260e7cd5667 100644
> --- a/drivers/gpu/drm/drm_fb_dma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_dma_helper.c
> @@ -59,20 +59,10 @@ struct drm_gem_dma_object *drm_fb_dma_get_gem_obj(struct drm_framebuffer *fb,
>   }
>   EXPORT_SYMBOL_GPL(drm_fb_dma_get_gem_obj);
>   
> -/**
> - * drm_fb_dma_get_gem_addr() - Get DMA (bus) address for framebuffer, for pixel
> - * formats where values are grouped in blocks this will get you the beginning of
> - * the block
> - * @fb: The framebuffer
> - * @state: Which state of drm plane
> - * @plane: Which plane
> - * Return the DMA GEM address for given framebuffer.
> - *
> - * This function will usually be called from the PLANE callback functions.
> - */
> -dma_addr_t drm_fb_dma_get_gem_addr(struct drm_framebuffer *fb,
> -				   struct drm_plane_state *state,
> -				   unsigned int plane)
> +static dma_addr_t _drm_fb_dma_get_gem_addr(struct drm_framebuffer *fb,
> +					   unsigned int plane,
> +					   unsigned int x,
> +					   unsigned int y)
>   {
>   	struct drm_gem_dma_object *obj;
>   	dma_addr_t dma_addr;
> @@ -96,8 +86,8 @@ dma_addr_t drm_fb_dma_get_gem_addr(struct drm_framebuffer *fb,
>   		v_div = fb->format->vsub;
>   	}
>   
> -	sample_x = (state->src_x >> 16) / h_div;
> -	sample_y = (state->src_y >> 16) / v_div;
> +	sample_x = x / h_div;
> +	sample_y = y / v_div;
>   	block_start_y = (sample_y / block_h) * block_h;
>   	num_hblocks = sample_x / block_w;

The current code already mixes up responsibilities of the involved 
modules. It's a good opportunity to improve that. I think there should 
be a block-offset helper for the framebuffer. That function will return 
the byte offset of a pixel's block from the beginning of the framebuffer 
plane.

/* in drm_framebuffer.{c,h} */
u32 drm_framebuffer_get_block_offset(struct drm_framebuffer *fb, plane, 
x, y)
{
     /* here goes the current offset calculation from the gem-dma code */
}

In the GEM-DMA code, you can then write your helpers like this

drm_fb_dma_get_gem_addr(...)
{
     obj = drm_fb_dma_get_gem_ob(fb)

     offset = drm_framebuffer_get_block_offset(obj->base, state->src_x, 
state->src_y)

     dma_addr = obj->dma_addr + offset;

     return dma_addr
}

_get_clipped_gem_addr()
{
     /* likewise */
}

This better structures the responsibility. It also works for other GEM 
code besides GEM-DMA.

Best regards
Thomas


>   
> @@ -106,8 +96,49 @@ dma_addr_t drm_fb_dma_get_gem_addr(struct drm_framebuffer *fb,
>   
>   	return dma_addr;
>   }
> +
> +/**
> + * drm_fb_dma_get_gem_addr() - Get DMA (bus) address for unclipped framebuffer,
> + * for pixel formats where values are grouped in blocks this will get you the
> + * beginning of the block
> + * @fb: The framebuffer
> + * @state: Which state of drm plane
> + * @plane: Which plane
> + *
> + * This function will usually be called from the PLANE callback functions.
> + *
> + * Return: GEM DMA address for given framebuffer, unclipped.
> + */
> +dma_addr_t drm_fb_dma_get_gem_addr(struct drm_framebuffer *fb,
> +				   struct drm_plane_state *state,
> +				   unsigned int plane)
> +{
> +	return _drm_fb_dma_get_gem_addr(fb, plane, state->src_x >> 16,
> +					state->src_y >> 16);
> +}
>   EXPORT_SYMBOL_GPL(drm_fb_dma_get_gem_addr);
>   
> +/**
> + * drm_fb_dma_get_gem_clipped_addr() - Get DMA (bus) address for clipped
> + * framebuffer, for pixel formats where values are grouped in blocks this
> + * will get you the beginning of the block
> + * @fb: The framebuffer
> + * @state: Which state of drm plane
> + * @plane: Which plane
> + *
> + * This function will usually be called from the PLANE callback functions.
> + *
> + * Return: GEM DMA address for given framebuffer, clipped.
> + */
> +dma_addr_t drm_fb_dma_get_gem_clipped_addr(struct drm_framebuffer *fb,
> +					   struct drm_plane_state *state,
> +					   unsigned int plane)
> +{
> +	return _drm_fb_dma_get_gem_addr(fb, plane, state->src.x1 >> 16,
> +					state->src.y1 >> 16);
> +}
> +EXPORT_SYMBOL_GPL(drm_fb_dma_get_gem_clipped_addr);
> +
>   /**
>    * drm_fb_dma_sync_non_coherent - Sync GEM object to non-coherent backing
>    *	memory
> diff --git a/include/drm/drm_fb_dma_helper.h b/include/drm/drm_fb_dma_helper.h
> index c950732c6d36..b2a0bd7ef9d0 100644
> --- a/include/drm/drm_fb_dma_helper.h
> +++ b/include/drm/drm_fb_dma_helper.h
> @@ -17,6 +17,10 @@ dma_addr_t drm_fb_dma_get_gem_addr(struct drm_framebuffer *fb,
>   				   struct drm_plane_state *state,
>   				   unsigned int plane);
>   
> +dma_addr_t drm_fb_dma_get_gem_clipped_addr(struct drm_framebuffer *fb,
> +					   struct drm_plane_state *state,
> +					   unsigned int plane);
> +
>   void drm_fb_dma_sync_non_coherent(struct drm_device *drm,
>   				  struct drm_plane_state *old_state,
>   				  struct drm_plane_state *state);

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)




  reply	other threads:[~2026-09-08  9:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08  9:07 [PATCH 0/4] drm: Add and use drm_fb_dma_get_gem_clipped_addr() helper Chen-Yu Tsai
2026-09-08  9:07 ` [PATCH 1/4] drm/fb-dma-helper: Add drm_fb_dma_get_gem_clipped_addr() Chen-Yu Tsai
2026-09-08  9:41   ` Thomas Zimmermann [this message]
2026-09-08  9:07 ` [PATCH 2/4] drm/sun4i: layers: Fix VI buffer address for clipped offsets Chen-Yu Tsai
2026-09-08  9:07 ` [PATCH 3/4] drm/imx/dc: plane: Switch to drm_fb_dma_get_gem_clipped_addr() Chen-Yu Tsai
2026-09-08  9:07 ` [PATCH 4/4] drm/imx/dcss: " Chen-Yu Tsai

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=d3e13d97-72c4-4a14-8de2-b509ef3e8759@suse.de \
    --to=tzimmermann@suse.de \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imx@lists.linux.dev \
    --cc=jernej@kernel.org \
    --cc=l.stach@pengutronix.de \
    --cc=laurentiu.palcu@oss.nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=samuel@sholland.org \
    --cc=simona@ffwll.ch \
    --cc=stable@vger.kernel.org \
    --cc=victor.liu@nxp.com \
    --cc=wens@kernel.org \
    --cc=wenst@chromium.org \
    /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