dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Frazin <frazinjonathan@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	Maxime Ripard <mripard@kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>,
	Alex Lanzano <lanzano.alex@gmail.com>,
	linux-kernel@vger.kernel.org,
	Jonathan Frazin <frazinjonathan@gmail.com>
Subject: [PATCH v1 0/2] drm/mipi-dbi: display a cropped region of an oversized framebuffer
Date: Thu, 10 Sep 2026 13:48:55 -0500	[thread overview]
Message-ID: <20260910185030.870-1-frazinjonathan@gmail.com> (raw)

A drm/tiny MIPI DBI panel can currently only scan out a framebuffer that
is exactly panel-sized, always from the origin. This series lets a client
allocate a larger framebuffer and choose the displayed region via the
plane source rectangle - a crop / pan with no scaling.

Motivation: feeding hardware-decoded video to a small SPI panel. The
video decoder emits a fixed frame size; being able to point the panel at
a panel-sized window of that buffer avoids a full-frame CPU copy on every
flush and lets userspace pan/centre the image.

Patch 1 is the actual fix - mipi_dbi_fb_dirty() addressed the controller
in framebuffer coordinates, which is only correct while src_x/src_y are
zero. It now subtracts the plane source origin.

Patch 2 raises mode_config.max_width/height (pinned to the panel size) on
the six drm/tiny drivers that flush through the shared
drm_mipi_dbi_plane_helper_atomic_update(). ili9225 is excluded - it has
its own flush path that does not carry the source offset.

Open question for patch 2: the six drivers each set the limits identically
in their probe. This could instead be a shared helper (or folded into
drm_mipi_dbi_dev_init / the DRM_MIPI_DBI_MODE_CONFIG_* macros) so future
drivers get it for free. Happy to respin that way if preferred - the
per-driver form is what is shown here because it is the smaller diff and
easier to review a first pass.

The min_width/min_height, the fixed mode, the connector and the
mode-sized transfer buffer are all unchanged, and
drm_mipi_dbi_plane_helper_atomic_check() still enforces DRM_PLANE_NO_SCALING
and no repositioning, so the flushed rectangle stays bounded by the panel
regardless of the framebuffer dimensions.

Tested on hardware: ILI9341 and ST7789V (through panel-mipi-dbi), both
240x320 - an oversized framebuffer is accepted and a non-zero-offset
panel-sized window scans out correctly; a panel-sized framebuffer is
unchanged. HX8357D was tested during the downstream review by Dave
Stevenson (Cc'd). ili9486, mi0283qt and ili9163 are build-tested only.

Both patches have been carried in the Raspberry Pi kernel (rpi-7.2.y) and
in use there:
https://github.com/raspberrypi/linux/pull/7589

Applies to current mainline / drm-misc-next; the touched files are
identical there.

Jonathan Frazin (2):
  drm/mipi-dbi: honour the plane source offset when flushing
  drm/tiny: allow a framebuffer larger than the panel on MIPI DBI
    drivers

 drivers/gpu/drm/drm_mipi_dbi.c        | 14 +++++++++++---
 drivers/gpu/drm/tiny/hx8357d.c        |  8 ++++++--
 drivers/gpu/drm/tiny/ili9163.c        |  8 ++++++--
 drivers/gpu/drm/tiny/ili9341.c        |  8 ++++++--
 drivers/gpu/drm/tiny/ili9486.c        |  8 ++++++--
 drivers/gpu/drm/tiny/mi0283qt.c       |  8 ++++++--
 drivers/gpu/drm/tiny/panel-mipi-dbi.c |  8 ++++++--
 7 files changed, 47 insertions(+), 15 deletions(-)

-- 
2.53.0


             reply	other threads:[~2026-09-11  7:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 18:48 Jonathan Frazin [this message]
2026-09-10 18:48 ` [PATCH v1 1/2] drm/mipi-dbi: honour the plane source offset when flushing Jonathan Frazin
2026-09-10 19:07   ` sashiko-bot
2026-09-10 18:48 ` [PATCH v1 2/2] drm/tiny: allow a framebuffer larger than the panel on MIPI DBI drivers Jonathan Frazin
2026-09-10 19:05   ` sashiko-bot
2026-09-11  0:19     ` Jonathan Frazin

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=20260910185030.870-1-frazinjonathan@gmail.com \
    --to=frazinjonathan@gmail.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kamlesh.gurudasani@gmail.com \
    --cc=lanzano.alex@gmail.com \
    --cc=linux-kernel@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