On Mon, 19 Oct 2026 13:18:50 +0200, Andy Shevchenko <[email protected]> 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
