All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: linux-sunxi@lists.linux.dev, dri-devel@lists.freedesktop.org,
	linux-gpio@vger.kernel.org
Subject: Re: [PATCH 3/3] drm/panel-mipi-dbi: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE
Date: Tue, 03 Nov 2026 13:42:47 +0000	[thread overview]
Message-ID: <sashiko-outbox-195387@kernel.org> (raw)
In-Reply-To: <20261103-panel-mipi-non-exclusive-gpios-v1-3-aa862c1d71e3@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/panel-mipi-dbi: broken shared dc GPIO in panel_mipi_dbi_spi_probe()
--

commit 90b279985dbeced362ebac928f364d9afff9972e
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

drm/panel-mipi-dbi: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE

This commit removes the deprecated GPIOD_FLAGS_BIT_NONEXCLUSIVE flag when
requesting the dc GPIO in panel_mipi_dbi_spi_probe(), relying on the GPIOLIB
shared GPIO proxy instead.

> diff --git a/drivers/gpu/drm/tiny/panel-mipi-dbi.c b/drivers/gpu/drm/tiny/panel-mipi-dbi.c
> index 60cd65cae41d8..6f09b723cd7c3 100644
> --- a/drivers/gpu/drm/tiny/panel-mipi-dbi.c
> +++ b/drivers/gpu/drm/tiny/panel-mipi-dbi.c
> @@ -418,8 +418,7 @@ static int panel_mipi_dbi_spi_probe(struct spi_device *spi)
>  	if (IS_ERR(dbi->reset))
>  		return dev_err_probe(dev, PTR_ERR(dbi->reset), "Failed to get GPIO 'reset'\n");
>  
> -	/* Multiple panels can share the "dc" GPIO, but only if they are on the same SPI bus! */
> -	dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW | GPIOD_FLAGS_BIT_NONEXCLUSIVE);
> +	dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);

[Severity: High]
Can gpio-shared-proxy work for a shared MIPI DBI D/C line across multiple
panels on the same SPI bus?

Unlike a shared reset or enable pin, the D/C GPIO in MIPI DBI Type C Option 3
is a bus control signal (0 for commands, 1 for parameters and pixel data)
multiplexed under spi_bus_lock(). In drivers/gpu/drm/drm_mipi_dbi.c,
mipi_dbi_typec3_command() leaves dbi->dc asserted at 1 after transferring
command parameters or pixel data:

drivers/gpu/drm/drm_mipi_dbi.c:mipi_dbi_typec3_command() {
	...
	spi_bus_lock(spi->controller);
	gpiod_set_value_cansleep(dbi->dc, 0);
	speed_hz = mipi_dbi_spi_cmd_max_speed(spi, 1);
	ret = mipi_dbi_spi_transfer(spi, speed_hz, 8, &cmd, 1);
	spi_bus_unlock(spi->controller);
	if (ret || !num)
		return ret;

	...
	spi_bus_lock(spi->controller);
	gpiod_set_value_cansleep(dbi->dc, 1);
	speed_hz = mipi_dbi_spi_cmd_max_speed(spi, num);
	ret = mipi_dbi_spi_transfer(spi, speed_hz, bpw, par, num);
	spi_bus_unlock(spi->controller);

	return ret;
}

When panel_mipi_dbi_spi_probe() requests dc with GPIOD_OUT_LOW,
shared_desc->def_val is 0. Once panel A sends a command with parameters and
sets dbi->dc to 1, gpio_shared_proxy_set_unlocked() sets panel A's
proxy->voted_change = true and increments shared_desc->votecnt to 1. Because
mipi_dbi_typec3_command() returns with dbi->dc still at 1, panel A retains its
vote after releasing spi_bus_lock().

When panel B on the same SPI bus then calls gpiod_set_value_cansleep(dbi->dc, 0)
in mipi_dbi_typec3_command() or mipi_dbi_typec3_command_read() to send a
command byte, gpio_shared_proxy_set_unlocked() checks whether any other proxy
still holds a vote for 1:

drivers/gpio/gpio-shared-proxy.c:gpio_shared_proxy_set_unlocked() {
	...
	/* Desired value is the default. */
	if (!proxy->voted_change) {
		if (!shared_desc->votecnt)
			ret = gpiod_set_value_cansleep(desc, shared_desc->def_val);
		goto out;
	}

	/* We previously voted for change. */
	if (shared_desc->votecnt == 1) {
		/* This is the last remaining vote for change, set value to default. */
		ret = gpiod_set_value_cansleep(desc, shared_desc->def_val);
		if (ret)
			goto out;
	}
	...
}

Because panel A's vote keeps shared_desc->votecnt >= 1, gpio-shared-proxy will
not drive the physical D/C GPIO back to 0 when panel B requests 0, leaving the
physical D/C line stuck high in data mode during panel B's command transfers
(and vice versa once panel B also sets dc to 1).

Also, the two in-tree DT users mentioned in the commit message only define a
single panel each and do not share dc-gpios, whereas DRM_PANEL_MIPI_DBI itself
does not select HAVE_SHARED_GPIOS and can be used on any platform or via DT
overlays where shared dc-gpios configurations (added in commits 3a63ef6e4b9e
and 8cc8ccbaa5d8) would now either fail probe with -EBUSY or fail to toggle
the physical D/C line.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103-panel-mipi-non-exclusive-gpios-v1-0-aa862c1d71e3@oss.qualcomm.com?part=3

      reply	other threads:[~2026-11-03 13:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 13:33 [PATCH 0/3] drm/panel-mipi-dbi: stop requesting GPIOs explicitly as non-exclusive Bartosz Golaszewski
2026-11-03 13:33 ` [PATCH 1/3] ARM: stm32: select HAVE_SHARED_GPIOS Bartosz Golaszewski
2026-11-03 13:33 ` [PATCH 2/3] ARM: sunxi: " Bartosz Golaszewski
2026-11-03 13:43   ` sashiko-bot
2026-11-03 13:33 ` [PATCH 3/3] drm/panel-mipi-dbi: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE Bartosz Golaszewski
2026-11-03 13:42   ` sashiko-bot [this message]

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=sashiko-outbox-195387@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.