Hello Krzysztof, thanks for the fast feedback. Am Freitag, 9. Dezember 2022, 09:39:49 CET schrieb Krzysztof Kozlowski: > On 09/12/2022 09:33, Alexander Stein wrote: > > It takes some time until the enable GPIO has settled when turning on. > > This delay is platform specific and may be caused by e.g. voltage > > shifts, capacitors etc. > > > > Signed-off-by: Alexander Stein <alexander.stein@xxxxxxxxxxxxxxx> > > --- > > > > .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > index 48a97bb3e2e0d..3f50d497cf8ac 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > > > @@ -32,6 +32,10 @@ properties: > > maxItems: 1 > > description: GPIO specifier for bridge_en pin (active high). > > > > + ti,enable-delay-us: > > + default: 10000 > > + description: Enable time delay for enable-gpios > > Aren't you now mixing two separate delays? One for entire block on (I > would assume mostly fixed delay) and one depending on regulators > (regulator-ramp-delay, regulator-enable-ramp-delay). Maybe you miss the > second delays in your power supply? If so, the first one might be fixed > and hard-coded in the driver? Apparently there are two different delays: reset time (t_reset) of 10ms as specified by datasheet. This is already ensured by a following delay after requesting enable_gpio as low and switching the GPIO to low in disable path. When enabling this GPIO it takes some time until it is valid on the chip, this is what this series is about. It's highly platform specific. Unfortunately this is completely unrelated to the vcc-supply regulator. This one has to be enabled before the enable GPIO can be enabled. So there is no regulator-ramp-delay. Best regards, Alexander
