The Okaya LCDs must have a dependency on the lcd regulator

[markfeathers]

linux-lts/arch/arm/boot/dts/nxp/imx/imx6qdl-ts4900-ts8390.dtsi

Line 122 in cdeeb32

reg_lcd3v3: regulator-lcd {

This regulator exists, but must somehow be referenced in this node:

	lcd_display: disp0 {
		compatible = "fsl,imx-parallel-display";
		#address-cells = <1>;
		#size-cells = <0>;
		interface-pix-fmt = "rgb24";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_lcd>;

Without this, we may violate the startup sequence for the okaya screen causing it to rarely fail into test patterns on startup.

[ts-kris]

This unfortunately may not be that straightforward. e.g. if we have to control the RGB data lines and put them in a logic 0 state before applying power, we would need to verify the display system would handle that. Otherwise, the best bet would probably be to move that logic to the bootloader (where we have more direct control of pin states as part of the platform startup) and then hide the LCD regulator from the kernel entirely.

I'm thinking back to similar issues with ethernet PHYs that are mode strapped by the data pins. We have to actively remove power control from the network driver stack as it would attempt to cut power (correctly) if the interface was closed. However, on startup, the driver didn't do the right thing with the data pins and would cause the PHY to re-strap in to a different mode.

[markfeathers]

Under the older NXP/freescale kernel fork we fixed this with a patch to the legacy LCD controller driver to support a display regulator:
embeddedTS/linux-tsimx@8d0332f#diff-8b421b99244ac735ebed7c9218d8a4f64f703f918af13e7d2fb1a7ea68cc5767R202

In the display then, we added a regulator for the LCD 3.3v:
https://github.com/embeddedTS/linux-tsimx/blob/9c4c55a97e7784fa6f50519ad1595e6c8402564a/arch/arm/boot/dts/imx6qdl-ts4900-ts8390.dtsi#L51

I unfortunately forget the details now, but presumably the LCD pins must be low until after LCD interface initializes with a valid mode. I expect newer kernels should have this support for regulators these days on panels in the dts. My only concern with these new kernels would then be if something like "blanking" the LCD turns off the regulator and the second time its enabled might glitch out. We likely need to test for that. The supply we attached before to mxcfb would never turn off.

This was a relatively common issue when we have a problematic startup sequence, and I suspect what we have by chance has the correct timing to not reproduce the issue or we would have seen it by now in the lts kernels. I'm just hoping we could describe this regulator so it doesn't come back in the future.

[ts-kris]

Sure, but the fix we applied previously doesn't seem to have guaranteed a startup state and just turns the regulator on. If the panel is sensitive to pin states at regulator turn on, then it is completely coincidence that it was able to turn on.

It is entirely possible that recent drivers will do the right thing but we would need to sit down and verify that through driver startup/PM wakeup/unblank/etc. But if we are in a position where we need to re-add the regulator like we have in the past, then it is very likely not going to be guaranteeing the pin states at regulator enable (and even then, going back to my PHY example, the driver happily accepted a regulator but had no concept of the strapping pins which is why we had to remove the regulator from the devicetree node). At that point, the correct thing would be to modify U-Boot to set up the LCD and turn it on under the proper conditions and then never let the kernel know about the LCD regulator, or, drastically expand the driver to control the pin states when the regulator is turned on. Allowing for panel PM and proper re-enabling.