Linux and STM32MP15x: Retain GPIO state between U-Boot and Kernel

[AGamb.5]

Hi everyone,

I'm working on a custom STM32MP157 based board running custom Linux with Kernel v5.10.116. A LCD panel is connected using the LTDC display controller.

I want to implement a splash-screen as soon as the power supply is on.

I managed to add my panel interface in U-Boot and display my splash-screen but when the kernel is initialized the GPIOs connected to the LCD panel (reset-pin and power supplies commands) are reset and re-initialized so the LCD display is switched off and on.

The final sequence is :

1. U-Boot displays the splash screen
2. the kernel is launched
3. the LCD display is re-initialized
4. the splash-screen is re-displayed

So there's a black screen for 2 seconds and I would like the splash-screen to remain displayed until the main application is launched.

Is it possible in the kernel DTS files to add an option so the GPIO (maybe PMIC) drivers won't re-initializes the pins tied to the display ?

I know it is possible with the TI drivers by adding "ti,no-reset-on-init" in the GPIO description but I didn't find something similar with the STM drivers.

Will I have to patch the drivers ?

Thanks.

[Erwan SZYMANSKI]

Hello @AGamb.5​,

First of all, thank you for your contribution.

I investigated on your point using an stm32mp157f-dk2 board.

It seems that the splash screen initially displayed thanx to u-boot is cleaned as you said with a gpio reset sequence. In my case, this is with the panel-orisetech-otm8009a.c driver at the following lines:

/* Reset the panel to avoid visual artifacts */
 
	if (ctx->reset_gpio) {
		gpiod_set_value_cansleep(ctx->reset_gpio, 0);
		gpiod_set_value_cansleep(ctx->reset_gpio, 1);
		msleep(20);
		gpiod_set_value_cansleep(ctx->reset_gpio, 0);
	}

I tried to comment it and it worked, so of course we could imagine to patch the driver to add a kind of property such as "no-reset" in device-tree and reset the gpios only if the property is at false or something like this.

However, I think that this GPIO reset step is here to respect the initialization sequence of the panel, and it should be the same for your custom board I guess. Regarding at the comment "Reset the panel to avoid visual artifacts", it seems that this gpio-reset step is useful, or at least recommended to avoid some issues in different kind of situation.

So to summarize, i think that you can patch the driver for your specific case (should not be too complex), if you do not see any blocker from your side. From ST side, it will be difficult to upstream this kind of modification if we move away the recommended initialization sequence of the panel.

I hope my explanations are clear and will help you.

Kind regards,

Erwan.

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[AGamb.5]

Hello Erwan,

Thanks for your reply and your investigation.

I really helps.

I managed to get some improvements.

First:

In U-Boot I enabled CONFIG_FDT_SIMPLEFB so ft_board_setup() calls fdt_simplefb_add_node_and_mem_rsv() to reserve the memory used by the framebuffer. It really helps.

The only issue is that it tries to reserve the memory range 0xcff00000 to 0xcfff0000 and then the kernel is stuck at boot. So I manually added the reserved memory range in the kernel DTS but I added 0xcff00000 to 0xcfffffff (1MB) and then the kernel boots. If I add the same values as the ones calculated by U-Boot the kernel freezes.

Second:

I managed to get the regulator ON at boot by added regulator-boot-on in my regulator definition.

Third:

Even If I don't drive the reset pin there's a really short black screen, I suspect the fbcon to "generate" when creating the framebuffer.

maybe there's something wrong with my kernel config. I attach it to this message.

Best regards,

Alex

[Erwan SZYMANSKI]

Hello @AGamb.5​,

Concerning your U-boot config CONFIG_FDT_SIMPLEFB, note that the default U-boot configuration proposed by ST enable it, so I think you should have it too for your use case purpose.

Concerning the remaining little black screen, I would advice you to "play" a little bit at the kernel boot time, with some delays and sleep time in different drivers to target precisely what is its root cause.

It is also possible that this last one is caused at runtime when services are launched .. Do you have psplash-drm-start service enable ? I think that this service launched too early can increase the black screen time.

Once again, I hope that this little information can help you to go forward.

Kind regards,

Erwan.

[AGamb.5]

Hello Erwan,

Thanks for these new information.

I figured out what driver makes the display black. The backlight is being switched off during the related driver initialization.

I can't finish this topic now but when I'll be done with I'll post a new message to explain the fix so it can help somebody else.

Thanks again, I'll you updated with this topic.

Best regards.