[PATCH] drm/i915/dsi: Use owned panel/backlight GPIOs in VLV MIPI sequences

[PATCH] drm/i915/dsi: Use owned panel/backlight GPIOs in VLV MIPI sequences

[Mike Anderson via B4 Relay]

From: Mike Anderson <mwwa919@gmail.com>

On VLV with PPS_BLC_SOC, intel_dsi_vbt_gpio_init() requests the
backlight and panel enable GPIOs (INT33FC:01 pins 10 and 11) for i915
itself. Since commit 8241b55f1ded ("drm/i915/dsi: Replace poking of VLV
GPIOs behind the driver's back") the GPIO elements of the VBT MIPI
sequences also request their pin through gpiolib, so when a sequence
toggles one of these two pins the request fails and the toggle is
dropped:

  i915 0000:00:02.0: [drm] *ERROR* GPIO index 10 request failed (-EBUSY)

Before that commit the pad registers were written directly, so the
sequences could still drive the pins i915 owned.

The Toshiba Encore 2 WT8-B (Bay Trail, DSI panel) uses pin 10 as the
panel reset line: MIPI_SEQ_ASSERT_RESET drives it low and
MIPI_SEQ_DEASSERT_RESET pulses it high-low-high. With every toggle
failing, the panel is never reset after i915 sends MIPI_SEQ_DISPLAY_OFF
during takeover and stays black, even though the backlight PWM and both
enable GPIOs read back as on. The tablet only has a usable display
with nomodeset.

When a VLV MIPI sequence targets pin 10 or 11 and i915 holds the
corresponding descriptor, set it through that descriptor instead of
requesting the pin a second time.

Fixes: 8241b55f1ded ("drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back")
Cc: stable@vger.kernel.org
Assisted-by: LLM sparse
Signed-off-by: Mike Anderson <mwwa919@gmail.com>
---
This patch was developed with an AI coding assistant (Claude Code,
Claude Opus 5.5): it ran the debugging session on the tablet (drm.debug
log, gpio/pwm debugfs), traced the -EBUSY to 8241b55f1ded, and wrote the
change and the changelog; I reviewed it and tested it on the hardware.

Testing, Toshiba Encore 2 WT8-B (Atom Z3735F, BIOS 2.10, VBT MIPI
sequence block v2, PPS_BLC_SOC):
- Arch Linux v7.2.11-arch1 with this patch backported (applies as is):
  the panel lights up at i915 takeover and the Xorg login screen shows;
  no "GPIO index ... request failed" errors; gpio-10/11 stay owned as
  "backlight"/"panel". Unpatched v7.2.11 and v6.18.57 give a black
  panel with five -EBUSY errors during boot.
- drm-intel-next: built intel_dsi_vbt.o for i915 (=m and =y) and for
  xe (=m) with W=1 and sparse (C=2, sparse v0.6.5-rc1): no new
  warnings.

Not tested: other VLV machines with PPS_BLC_SOC. Their behaviour only
changes when their VBT sequences touch pin 10 or 11, which currently
fails with -EBUSY anyway.
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 32 +++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index fe12041e9..85d1cdc6e 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -54,6 +54,10 @@
 #define MIPI_VIRTUAL_CHANNEL_SHIFT	1
 #define MIPI_PORT_SHIFT			3
 
+/* VLV NC pins of the backlight and panel enable GPIOs, see soc_panel_gpio_table */
+#define VLV_GPIO_NC_BACKLIGHT		10
+#define VLV_GPIO_NC_PANEL		11
+
 struct i2c_adapter_lookup {
 	u16 target_addr;
 	struct intel_dsi *intel_dsi;
@@ -247,10 +251,12 @@ static void soc_opaque_gpio_set_value(struct intel_connector *connector,
 	kfree(lookup);
 }
 
-static void vlv_gpio_set_value(struct intel_connector *connector,
+static void vlv_gpio_set_value(struct intel_dsi *intel_dsi,
 			       u8 gpio_source, u8 gpio_index, bool value)
 {
-	struct intel_display *display = to_intel_display(connector);
+	struct intel_display *display = to_intel_display(&intel_dsi->base);
+	struct intel_connector *connector = intel_dsi->attached_connector;
+	struct gpio_desc *gpio_desc = NULL;
 
 	/* XXX: this assumes vlv_gpio_table only has NC GPIOs. */
 	if (connector->panel.vbt.dsi.seq_version < 3) {
@@ -265,6 +271,22 @@ static void vlv_gpio_set_value(struct intel_connector *connector,
 		}
 	}
 
+	/*
+	 * With PPS_BLC_SOC, intel_dsi_vbt_gpio_init() already owns these pins,
+	 * so requesting them again fails with -EBUSY. Some VBTs still toggle
+	 * them in their MIPI sequences, e.g. as the panel reset line, so drive
+	 * them through the descriptors we hold.
+	 */
+	if (gpio_index == VLV_GPIO_NC_BACKLIGHT)
+		gpio_desc = intel_dsi->gpio_backlight;
+	else if (gpio_index == VLV_GPIO_NC_PANEL)
+		gpio_desc = intel_dsi->gpio_panel;
+
+	if (gpio_desc && connector->panel.vbt.dsi.config->pwm_blc == PPS_BLC_SOC) {
+		gpiod_set_value_cansleep(gpio_desc, value);
+		return;
+	}
+
 	soc_opaque_gpio_set_value(connector, gpio_index,
 				  "INT33FC:01", "Panel N", gpio_index, value);
 }
@@ -430,7 +452,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
 	else if (DISPLAY_VER(display) >= 9)
 		bxt_gpio_set_value(connector, gpio_index, value);
 	else if (display->platform.valleyview)
-		vlv_gpio_set_value(connector, gpio_source, gpio_number, value);
+		vlv_gpio_set_value(intel_dsi, gpio_source, gpio_number, value);
 	else if (display->platform.cherryview)
 		chv_gpio_set_value(connector, gpio_source, gpio_number, value);
 
@@ -886,8 +908,8 @@ static struct gpiod_lookup_table pmic_panel_gpio_table = {
 static struct gpiod_lookup_table soc_panel_gpio_table = {
 	.dev_id = "0000:00:02.0",
 	.table = {
-		GPIO_LOOKUP("INT33FC:01", 10, "backlight", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FC:01", 11, "panel", GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP("INT33FC:01", VLV_GPIO_NC_BACKLIGHT, "backlight", GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP("INT33FC:01", VLV_GPIO_NC_PANEL, "panel", GPIO_ACTIVE_HIGH),
 		{ }
 	},
 };

---
base-commit: 0507cc5a476af0b6d037b19248bdd20dbe27487d
change-id: 20261018-vlv-dsi-owned-gpios-cd127ba137e7

Best regards,
--  
Mike Anderson <mwwa919@gmail.com>

Re: [PATCH] drm/i915/dsi: Use owned panel/backlight GPIOs in VLV MIPI sequences

[Andy Shevchenko]

On Sun, Oct 18, 2026 at 04:12:40PM -0400, Mike Anderson via B4 Relay wrote:

> On VLV with PPS_BLC_SOC, intel_dsi_vbt_gpio_init() requests the
> backlight and panel enable GPIOs (INT33FC:01 pins 10 and 11) for i915
> itself. Since commit 8241b55f1ded ("drm/i915/dsi: Replace poking of VLV
> GPIOs behind the driver's back") the GPIO elements of the VBT MIPI
> sequences also request their pin through gpiolib, so when a sequence
> toggles one of these two pins the request fails and the toggle is
> dropped:
> 
>   i915 0000:00:02.0: [drm] *ERROR* GPIO index 10 request failed (-EBUSY)
> 
> Before that commit the pad registers were written directly, so the
> sequences could still drive the pins i915 owned.
> 
> The Toshiba Encore 2 WT8-B (Bay Trail, DSI panel) uses pin 10 as the
> panel reset line: MIPI_SEQ_ASSERT_RESET drives it low and
> MIPI_SEQ_DEASSERT_RESET pulses it high-low-high. With every toggle
> failing, the panel is never reset after i915 sends MIPI_SEQ_DISPLAY_OFF
> during takeover and stays black, even though the backlight PWM and both
> enable GPIOs read back as on. The tablet only has a usable display
> with nomodeset.
> 
> When a VLV MIPI sequence targets pin 10 or 11 and i915 holds the
> corresponding descriptor, set it through that descriptor instead of
> requesting the pin a second time.

Ah, nice, this should be solved via using reset-gpio, which is exactly fixed
for the reset shared lines case.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] drm/i915/dsi: Use owned panel/backlight GPIOs in VLV MIPI sequences

[Michael Anderson]

Thanks for looking at this. I'd like to make sure I understand before
doing a v2.

Here both users of pin 10 are i915 itself: intel_dsi_vbt_gpio_init()
takes it as the "backlight" enable GPIO (soc_panel_gpio_table,
PPS_BLC_SOC), and the VBT MIPI sequences on this tablet then toggle the
same pin as the panel reset (low in ASSERT_RESET, high-low-high in
DEASSERT_RESET). Do you mean describing pin 10 with a software-node
"reset-gpios" reference and having both paths go through
reset_control_*(), or something else?

One concern: the VBT drives explicit pulses on the pin, and shared reset
controls are refcounted, so a pulse from one path wouldn't reach the line
while the other holds it deasserted. Would an exclusive reset obtained
once by i915 and used by both paths work instead, or am I missing how
reset-gpio handles this?

Thanks,
Mike


On Mon, Oct 19, 2026 at 5:58 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Sun, Oct 18, 2026 at 04:12:40PM -0400, Mike Anderson via B4 Relay wrote:
>
> > On VLV with PPS_BLC_SOC, intel_dsi_vbt_gpio_init() requests the
> > backlight and panel enable GPIOs (INT33FC:01 pins 10 and 11) for i915
> > itself. Since commit 8241b55f1ded ("drm/i915/dsi: Replace poking of VLV
> > GPIOs behind the driver's back") the GPIO elements of the VBT MIPI
> > sequences also request their pin through gpiolib, so when a sequence
> > toggles one of these two pins the request fails and the toggle is
> > dropped:
> >
> >   i915 0000:00:02.0: [drm] *ERROR* GPIO index 10 request failed (-EBUSY)
> >
> > Before that commit the pad registers were written directly, so the
> > sequences could still drive the pins i915 owned.
> >
> > The Toshiba Encore 2 WT8-B (Bay Trail, DSI panel) uses pin 10 as the
> > panel reset line: MIPI_SEQ_ASSERT_RESET drives it low and
> > MIPI_SEQ_DEASSERT_RESET pulses it high-low-high. With every toggle
> > failing, the panel is never reset after i915 sends MIPI_SEQ_DISPLAY_OFF
> > during takeover and stays black, even though the backlight PWM and both
> > enable GPIOs read back as on. The tablet only has a usable display
> > with nomodeset.
> >
> > When a VLV MIPI sequence targets pin 10 or 11 and i915 holds the
> > corresponding descriptor, set it through that descriptor instead of
> > requesting the pin a second time.
>
> Ah, nice, this should be solved via using reset-gpio, which is exactly fixed
> for the reset shared lines case.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>


-- 
Michael Anderson

Re: [PATCH] drm/i915/dsi: Use owned panel/backlight GPIOs in VLV MIPI sequences

[Andy Shevchenko]

+Cc: Bart (as GPIOLIB maintainer and author of the reset-gpio rework).

On Mon, Oct 19, 2026 at 07:03:57AM -0400, Michael Anderson wrote:
> Thanks for looking at this. I'd like to make sure I understand before
> doing a v2.
> 
> Here both users of pin 10 are i915 itself: intel_dsi_vbt_gpio_init()
> takes it as the "backlight" enable GPIO (soc_panel_gpio_table,
> PPS_BLC_SOC), and the VBT MIPI sequences on this tablet then toggle the
> same pin as the panel reset (low in ASSERT_RESET, high-low-high in
> DEASSERT_RESET). Do you mean describing pin 10 with a software-node
> "reset-gpios" reference and having both paths go through
> reset_control_*(), or something else?
> 
> One concern: the VBT drives explicit pulses on the pin, and shared reset
> controls are refcounted, so a pulse from one path wouldn't reach the line
> while the other holds it deasserted. Would an exclusive reset obtained
> once by i915 and used by both paths work instead, or am I missing how
> reset-gpio handles this?

But then it sounds like the request-by-demand?
Bart, any ideas how to address this case?

> On Mon, Oct 19, 2026 at 5:58 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Sun, Oct 18, 2026 at 04:12:40PM -0400, Mike Anderson via B4 Relay wrote:
> >
> > > On VLV with PPS_BLC_SOC, intel_dsi_vbt_gpio_init() requests the
> > > backlight and panel enable GPIOs (INT33FC:01 pins 10 and 11) for i915
> > > itself. Since commit 8241b55f1ded ("drm/i915/dsi: Replace poking of VLV
> > > GPIOs behind the driver's back") the GPIO elements of the VBT MIPI
> > > sequences also request their pin through gpiolib, so when a sequence
> > > toggles one of these two pins the request fails and the toggle is
> > > dropped:
> > >
> > >   i915 0000:00:02.0: [drm] *ERROR* GPIO index 10 request failed (-EBUSY)
> > >
> > > Before that commit the pad registers were written directly, so the
> > > sequences could still drive the pins i915 owned.
> > >
> > > The Toshiba Encore 2 WT8-B (Bay Trail, DSI panel) uses pin 10 as the
> > > panel reset line: MIPI_SEQ_ASSERT_RESET drives it low and
> > > MIPI_SEQ_DEASSERT_RESET pulses it high-low-high. With every toggle
> > > failing, the panel is never reset after i915 sends MIPI_SEQ_DISPLAY_OFF
> > > during takeover and stays black, even though the backlight PWM and both
> > > enable GPIOs read back as on. The tablet only has a usable display
> > > with nomodeset.
> > >
> > > When a VLV MIPI sequence targets pin 10 or 11 and i915 holds the
> > > corresponding descriptor, set it through that descriptor instead of
> > > requesting the pin a second time.
> >
> > Ah, nice, this should be solved via using reset-gpio, which is exactly fixed
> > for the reset shared lines case.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] drm/i915/dsi: Use owned panel/backlight GPIOs in VLV MIPI sequences

[Bartosz Golaszewski]

On Mon, 19 Oct 2026 13:18:50 +0200, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> +Cc: Bart (as GPIOLIB maintainer and author of the reset-gpio rework).
>
> On Mon, Oct 19, 2026 at 07:03:57AM -0400, Michael Anderson wrote:
>> Thanks for looking at this. I'd like to make sure I understand before
>> doing a v2.
>>
>> Here both users of pin 10 are i915 itself: intel_dsi_vbt_gpio_init()
>> takes it as the "backlight" enable GPIO (soc_panel_gpio_table,
>> PPS_BLC_SOC), and the VBT MIPI sequences on this tablet then toggle the
>> same pin as the panel reset (low in ASSERT_RESET, high-low-high in
>> DEASSERT_RESET). Do you mean describing pin 10 with a software-node
>> "reset-gpios" reference and having both paths go through
>> reset_control_*(), or something else?
>>
>> One concern: the VBT drives explicit pulses on the pin, and shared reset
>> controls are refcounted, so a pulse from one path wouldn't reach the line
>> while the other holds it deasserted. Would an exclusive reset obtained
>> once by i915 and used by both paths work instead, or am I missing how
>> reset-gpio handles this?
>
> But then it sounds like the request-by-demand?
> Bart, any ideas how to address this case?
>

Yeah. If you need a more complex sequence than what refcounted reset-gpio or
gpio-shared-proxy can provide (for instance a timed pulse) then you probably
need to look at implementing a power sequencer using drivers/power/sequencing/.

Bart

Re: [PATCH] drm/i915/dsi: Use owned panel/backlight GPIOs in VLV MIPI sequences

[Ville Syrjälä]

On Sun, Oct 18, 2026 at 04:12:40PM -0400, Mike Anderson via B4 Relay wrote:
> From: Mike Anderson <mwwa919@gmail.com>
> 
> On VLV with PPS_BLC_SOC, intel_dsi_vbt_gpio_init() requests the
> backlight and panel enable GPIOs (INT33FC:01 pins 10 and 11) for i915
> itself. Since commit 8241b55f1ded ("drm/i915/dsi: Replace poking of VLV
> GPIOs behind the driver's back") the GPIO elements of the VBT MIPI
> sequences also request their pin through gpiolib, so when a sequence
> toggles one of these two pins the request fails and the toggle is
> dropped:
> 
>   i915 0000:00:02.0: [drm] *ERROR* GPIO index 10 request failed (-EBUSY)
> 
> Before that commit the pad registers were written directly, so the
> sequences could still drive the pins i915 owned.
> 
> The Toshiba Encore 2 WT8-B (Bay Trail, DSI panel) uses pin 10 as the
> panel reset line: MIPI_SEQ_ASSERT_RESET drives it low and
> MIPI_SEQ_DEASSERT_RESET pulses it high-low-high. With every toggle
> failing, the panel is never reset after i915 sends MIPI_SEQ_DISPLAY_OFF
> during takeover and stays black, even though the backlight PWM and both
> enable GPIOs read back as on. The tablet only has a usable display
> with nomodeset.
> 
> When a VLV MIPI sequence targets pin 10 or 11 and i915 holds the
> corresponding descriptor, set it through that descriptor instead of
> requesting the pin a second time.
> 
> Fixes: 8241b55f1ded ("drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM sparse
> Signed-off-by: Mike Anderson <mwwa919@gmail.com>
> ---
> This patch was developed with an AI coding assistant (Claude Code,
> Claude Opus 5.5): it ran the debugging session on the tablet (drm.debug
> log, gpio/pwm debugfs), traced the -EBUSY to 8241b55f1ded, and wrote the
> change and the changelog; I reviewed it and tested it on the hardware.
> 
> Testing, Toshiba Encore 2 WT8-B (Atom Z3735F, BIOS 2.10, VBT MIPI
> sequence block v2, PPS_BLC_SOC):
> - Arch Linux v7.2.11-arch1 with this patch backported (applies as is):
>   the panel lights up at i915 takeover and the Xorg login screen shows;
>   no "GPIO index ... request failed" errors; gpio-10/11 stay owned as
>   "backlight"/"panel". Unpatched v7.2.11 and v6.18.57 give a black
>   panel with five -EBUSY errors during boot.
> - drm-intel-next: built intel_dsi_vbt.o for i915 (=m and =y) and for
>   xe (=m) with W=1 and sparse (C=2, sparse v0.6.5-rc1): no new
>   warnings.
> 
> Not tested: other VLV machines with PPS_BLC_SOC. Their behaviour only
> changes when their VBT sequences touch pin 10 or 11, which currently
> fails with -EBUSY anyway.
> ---
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 32 +++++++++++++++++++++++-----
>  1 file changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> index fe12041e9..85d1cdc6e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> @@ -54,6 +54,10 @@
>  #define MIPI_VIRTUAL_CHANNEL_SHIFT	1
>  #define MIPI_PORT_SHIFT			3
>  
> +/* VLV NC pins of the backlight and panel enable GPIOs, see soc_panel_gpio_table */
> +#define VLV_GPIO_NC_BACKLIGHT		10
> +#define VLV_GPIO_NC_PANEL		11
> +
>  struct i2c_adapter_lookup {
>  	u16 target_addr;
>  	struct intel_dsi *intel_dsi;
> @@ -247,10 +251,12 @@ static void soc_opaque_gpio_set_value(struct intel_connector *connector,
>  	kfree(lookup);
>  }
>  
> -static void vlv_gpio_set_value(struct intel_connector *connector,
> +static void vlv_gpio_set_value(struct intel_dsi *intel_dsi,
>  			       u8 gpio_source, u8 gpio_index, bool value)
>  {
> -	struct intel_display *display = to_intel_display(connector);
> +	struct intel_display *display = to_intel_display(&intel_dsi->base);
> +	struct intel_connector *connector = intel_dsi->attached_connector;
> +	struct gpio_desc *gpio_desc = NULL;
>  
>  	/* XXX: this assumes vlv_gpio_table only has NC GPIOs. */
>  	if (connector->panel.vbt.dsi.seq_version < 3) {
> @@ -265,6 +271,22 @@ static void vlv_gpio_set_value(struct intel_connector *connector,
>  		}
>  	}
>  
> +	/*
> +	 * With PPS_BLC_SOC, intel_dsi_vbt_gpio_init() already owns these pins,
> +	 * so requesting them again fails with -EBUSY. Some VBTs still toggle
> +	 * them in their MIPI sequences, e.g. as the panel reset line, so drive
> +	 * them through the descriptors we hold.
> +	 */
> +	if (gpio_index == VLV_GPIO_NC_BACKLIGHT)
> +		gpio_desc = intel_dsi->gpio_backlight;
> +	else if (gpio_index == VLV_GPIO_NC_PANEL)
> +		gpio_desc = intel_dsi->gpio_panel;

Please file a bug
https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items and
attach a copy of /sys/kernel/debug/dri/0/i915_vbt there so that 
we can all see what it looks like.

I think what we should do is stop using .gpio_panel and/or
.gpio_backlight when the VBT expects to control them via the
sequences.

The big question here is whether we need to keep some kind of
hybrid approach where one pin is controlled by the sequence and
the other explicitly by the driver.

For example https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/14605
has a VBT where the reset pin is controlled by the VBT but there is no
backlight stuff whatsoever in there. Well, unless some of those DCS
commands has something to do with the backlight, but IIRC DCS has no
standard stuff for backlight so it would all be panel specific. So
it's not clear if a backlight GPIO pin is needed at all there, of if
the DCS and/or the PWM alone is sufficient.

Hans, do you still have these funky VLV DSI machines around, and if so
can you check whether they would need this kind of hybrid approach?
Sadly all I have is old stuff that doesn't use the VBT sequences at
all.

If we do need the hybrid approach then it could perhaps look something like this:
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -917,8 +917,14 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on)
 
 	if (display->platform.valleyview && mipi_config->pwm_blc == PPS_BLC_SOC) {
 		gpiod_lookup_table = &soc_panel_gpio_table;
-		want_panel_gpio = true;
-		want_backlight_gpio = true;
+
+		if (!connector->panel.vbt.dsi.sequence[MIPI_SEQ_ASSERT_RESET] &&
+		    !connector->panel.vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET])
+			want_panel_gpio = true;
+
+		if (!connector->panel.vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_OFF] &&
+		    !connector->panel.vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_ON])
+			want_backlight_gpio = true;
 
 		/* Ensure PWM0 pin is muxed as PWM instead of GPIO */
 		ret = pinctrl_register_mappings(soc_pwm_pinctrl_map,

> +
> +	if (gpio_desc && connector->panel.vbt.dsi.config->pwm_blc == PPS_BLC_SOC) {
> +		gpiod_set_value_cansleep(gpio_desc, value);
> +		return;
> +	}
> +
>  	soc_opaque_gpio_set_value(connector, gpio_index,
>  				  "INT33FC:01", "Panel N", gpio_index, value);
>  }
> @@ -430,7 +452,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
>  	else if (DISPLAY_VER(display) >= 9)
>  		bxt_gpio_set_value(connector, gpio_index, value);
>  	else if (display->platform.valleyview)
> -		vlv_gpio_set_value(connector, gpio_source, gpio_number, value);
> +		vlv_gpio_set_value(intel_dsi, gpio_source, gpio_number, value);
>  	else if (display->platform.cherryview)
>  		chv_gpio_set_value(connector, gpio_source, gpio_number, value);
>  
> @@ -886,8 +908,8 @@ static struct gpiod_lookup_table pmic_panel_gpio_table = {
>  static struct gpiod_lookup_table soc_panel_gpio_table = {
>  	.dev_id = "0000:00:02.0",
>  	.table = {
> -		GPIO_LOOKUP("INT33FC:01", 10, "backlight", GPIO_ACTIVE_HIGH),
> -		GPIO_LOOKUP("INT33FC:01", 11, "panel", GPIO_ACTIVE_HIGH),
> +		GPIO_LOOKUP("INT33FC:01", VLV_GPIO_NC_BACKLIGHT, "backlight", GPIO_ACTIVE_HIGH),
> +		GPIO_LOOKUP("INT33FC:01", VLV_GPIO_NC_PANEL, "panel", GPIO_ACTIVE_HIGH),
>  		{ }
>  	},
>  };
> 
> ---
> base-commit: 0507cc5a476af0b6d037b19248bdd20dbe27487d
> change-id: 20261018-vlv-dsi-owned-gpios-cd127ba137e7
> 
> Best regards,
> --  
> Mike Anderson <mwwa919@gmail.com>
> 

-- 
Ville Syrjälä
Intel