RG350M panel glitch fix proposal

[citral23]

When this panel is reset twice in a row, in very rapid succession like it's the case when starting/closing an app, the official specification of 5ms after releasing RESX isn't enough to ensure proper function.

Increasing usleep_range(5000, 20000) to (13000, 20000) is not enough to keep the glitch away, but (15000, 20000) is.

Given this time spent since pin release can be deduced from the msleep() that follows (also 7ms are spent writing regs) my suggestion is to go large (and account for possible chipsets tolerances variations)
and use usleep_range(20000, 30000), then 7ms of regs write follow, then we can use msleep(95) and all works fine.

To be in line with what the documentation recommends, I have replaced msleep(100) with msleep(95) placed before the sleep_out call, as the manual stipulates that
"It is necessary to wait 5msec after releasing RESX before sending commands. Also Sleep Out command cannot be sent for 120 msec."

Signed-off-by: Christophe Branchereau cbranchereau@gmail.com

[jezze]

Have confirmed this works fairly well on a real RG350M. The bootup looks almost flawless. The issues I've noticed is that when you start an app you can briefly see what looks almost like scanlines but it is when you close an app and return to gmenu2x that you notice that the problem isn't entirely gone. I would suggest continued tweaking to get it perfect.

[pcercuei]

I'm not convinced with the fix, for three reasons:

• If it only happens when the panel is reset twice in a row, then the sleep may actually be required elsewhere. Maybe right before the mipi_dsi_dcs_enter_sleep_mode?
• usleep_range is not for values > 20000, use msleep(20) in that case.
• The code assumes that it will take at least 7ms to set the registers, which is very wrong. For what we know, it might take as little as 225us.

[citral23]

The 7ms are actually from kernel timestamps, but I agree it's not great practice to hard code such a value.

A few remarks :

Commenting out "mipi_dsi_dcs_enter_sleep_mode" does not help
Commenting out "regulator_disable" does not help
Commenting out "mipi_dsi_dcs_set_display_off" does not help
Commenting out all 3 doesn't help

doing gpio reset sleep time values x25 only delays the problem

introducing a 5ms sleep value between registers settings, we get a bad delay but when the picture finally appears it's clean

[citral23]

Hello, this is the best I can do, I don't see any remaining hint of glitch with those settings :

https://github.com/citral23/linux/commit/4bb412c41c62935253fd4ce4857bf86835798c89

[citral23]

Proposed a better version. Root cause still vague tho but definitely seems related to the registers.