On Fri, Jan 5, 2024 at 8:09 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Thu, Jan 4, 2024 at 9:42 AM Dario Binacchi > <dario.binacchi@xxxxxxxxxxxxxxxxxxxx> wrote: > > > The initialization commands are taken from the STMicroelectronics driver > > found at [1]. > > To ensure backward compatibility, flags have been added to enable gamma > > correction setting and display control. In other cases, registers have > > been set to their default values according to the specifications found > > in the datasheet. > > > > [1] https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/BSP/Components/nt35510/ > > Signed-off-by: Dario Binacchi <dario.binacchi@xxxxxxxxxxxxxxxxxxxx> > > > > --- > > > > (no changes since v2) > > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > (also tested to not regress my hardware) After submitting v4, I tested the driver under different conditions, i. e. without enabling display support in U-Boot (I also implemented a version for U-Boot, which I will send only after this series is merged into the Linux kernel). In that condition I encountered an issue with the reset pin. The minimal fix, would be this: diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c b/drivers/gpu/drm/panel/panel-novatek-nt35510.c index c85dd0d0829d..89ba99763468 100644 --- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c +++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c @@ -1133,7 +1133,7 @@ static int nt35510_probe(struct mipi_dsi_device *dsi) if (ret) return ret; - nt->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS); + nt->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); if (IS_ERR(nt->reset_gpio)) { dev_err(dev, "error getting RESET GPIO\n"); return PTR_ERR(nt->reset_gpio); With the doubt that this might cause a regression in your use case. I then tried modifying the device tree instead of the nt35510 driver. In the end, I arrived at this patch that leaves me with some doubts, especially regarding the strict option. diff --git a/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts b/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-m> index 014cac192375..32ed420a6cbf 100644 --- a/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts +++ b/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts @@ -13,6 +13,17 @@ &panel0 { compatible = "frida,frd400b25025", "novatek,nt35510"; vddi-supply = <&vcc_3v3>; vdd-supply = <&vcc_3v3>; + pinctrl-0 = <&panel_reset>; + pinctrl-names = "default"; /delete-property/backlight; /delete-property/power-supply; }; + +&pinctrl { + panel_reset: panel-reset { + pins1 { + pinmux = <STM32_PINMUX('J', 15, GPIO)>; + output-high; + }; + }; +}; diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c index 346a31f31bba..6f055f7f96a2 100644 --- a/drivers/pinctrl/stm32/pinctrl-stm32.c +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c @@ -895,7 +895,6 @@ static const struct pinmux_ops stm32_pmx_ops = { .set_mux = stm32_pmx_set_mux, .gpio_set_direction = stm32_pmx_gpio_set_direction, .request = stm32_pmx_request, - .strict = true, }; Another option to fix my use case without introducing regressions could be to add a new property to the device tree that suggests whether to call devm_gpiod_get_optional() with the GPIOD_ASIS or GPIOD_OUT_HIGH parameter. What is your opinion? Thanks and regards, Dario Binacchi > > Yours, > Linus Walleij -- Dario Binacchi Senior Embedded Linux Developer dario.binacchi@xxxxxxxxxxxxxxxxxxxx __________________________________ Amarula Solutions SRL Via Le Canevare 30, 31100 Treviso, Veneto, IT T. +39 042 243 5310 info@xxxxxxxxxxxxxxxxxxxx www.amarulasolutions.com
