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>
