Re: [PATCH 2/5] arm64: dts: qcom: sc7180: Add trogdor eDP/touchscreen regulator off-on-time

[Matthias Kaehlcke]

On Thu, Dec 08, 2022 at 11:20:03AM -0800, Douglas Anderson wrote:
> In general, the timing diagrams for components specify a minimum time
> for power cycling the component. When we remove power from a device we
> need to let the device fully discharge and get to a quiescent state
> before applying power again. If we power a device on too soon then it
> might not have fully powered off and might be in a weird in-between /
> invalid state.
> 
> eDP panels typically have a time that's at least 500 ms here. You can
> see that in Linux's panel-edp driver that nearly every device

nit: s/that nearly/nearly/

no need to re-spin just for this.

> specifies a "unprepare" time of at least 500 ms. This is a common
> minimum and the 500 ms is even in the example in the eDP spec.
> 
> In Linux, the "panel-edp" driver enforces this delay for its own
> control of the regulator, but the "panel-edp" driver can't do anything
> about other control of the regulator (for instance, by the touchpanel
> driver).
> 
> Let's add 500 ms as a board constraint for the regulator that's used
> for eDP/touchpanel on trogdor boards. If a given trogdor board stuffs
> only panels that can use a shorter time or stuff some panels that need
> a larger time then they can manually adjust this timing.
> 
> We'll only do this minimum delay for trogdor devices with eDP (ones
> that use either bridge chip), not for devices with MIPI panels. MIPI
> panels could have similar constraints but the 500 ms isn't necessarily
> as standard and there are no known cases where this delay is needed.
> 
> For most trogdor boards, this doesn't actually seem to affect anything
> when testing against shipping Linux. However, with pazqel360 it seems
> that this does make a difference. It seems that the touchscreen on
> this board _also_ needs some time for the regulator to discharge. That
> time is much less than 500 ms, so we'll just put the eDP panel 500 ms
> in there since the board constraint should be the "max" of the
> components.
> 
> Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>

Reviewed-by: Matthias Kaehlcke <mka@xxxxxxxxxxxx>