+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 > <[email protected]> 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
