On 12/9/22 14:38, Alexander Stein wrote:
Am Freitag, 9. Dezember 2022, 13:43:02 CET schrieb Marek Vasut:
On 12/9/22 13:21, Alexander Stein wrote:
Hi Marek,
Am Freitag, 9. Dezember 2022, 13:02:10 CET schrieb Marek Vasut:
On 12/9/22 10:36, Alexander Stein wrote:
Hello Krzysztof,
Hi,
Am Freitag, 9. Dezember 2022, 10:07:45 CET schrieb Krzysztof Kozlowski:
On 09/12/2022 09:54, Alexander Stein wrote:
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.
Your driver does one after another - regulator followed immediately by
gpio - so this as well can be a delay from regulator (maybe not ramp
but
enable delay).
The chip has two separate input pins:
VCC -- power supply that's regulator
EN -- reset line, that's GPIO
Alexander is talking about EN line here.
But this will introduce a section which must not be interrupted or
delayed.
This is impossible as the enable gpio is attached to an i2c expander in
my
case.
Given the following time chart:
vcc set EN
enable GPIO PAD
| |<-- t_raise -->|
|
| <-- t_vcc_gpio --> | |
| <-- t_enable_delay --> |
t_raise is the time from changing the GPIO output at the expander until
voltage on the EN (input) pad from the bridge has reached high voltage
level. This is an electrical characteristic I can not change and have to
take into account.
t_vcc_gpio is the time from enabling supply voltage to enabling the
bridge
(removing from reset). Minimum t_vcc_gpio is something which can be
addressed by the regulator and is no problem so far. But there is no
upper bound to it.
What exactly is your EN signal rise time (should be ns or so)? Can you
look at that with a scope , maybe even with relation to the VCC regulator
?
I checked EN rise time using a scope, it's ~110ms. I not an expert in
hardware but on the mainboard there is some capacitor attached to this
line, which increased the time, independent from the internal pull-up.
This does seem like a hardware bug right there, can you double-check
this with the hardware engineer ?
Yep, checked with hardware engineer. An 470nF is attached, together with an
open drain output and only the internal pull-up. So yes ~113ms rising time
until 0.7 x VCC.
I don't suppose you can have that capacitor reduced or better yet, some
external pull up added, can you ?
