From: Matthias Kaehlcke <mka@chromium.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
swboyd@chromium.org, linux-arm-msm@vger.kernel.org,
linux-input@vger.kernel.org,
Yunlong Jia <ecs.beijing2022@gmail.com>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Andy Gross <agross@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] arm64: dts: qcom: sc7180: Add trogdor eDP/touchscreen regulator off-on-time
Date: Thu, 8 Dec 2022 23:31:23 +0000 [thread overview]
Message-ID: <Y5Jzy4hL2x4qcATT@google.com> (raw)
In-Reply-To: <20221208111910.2.I65ac577411b017eff50e7a4fda254e5583ccdc48@changeid>
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@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
next prev parent reply other threads:[~2022-12-08 23:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 19:20 [PATCH 0/5] arm64: dts: qcom: sc7180: Make pazquel360's touchscreen work Douglas Anderson
2022-12-08 19:20 ` [PATCH 1/5] arm64: dts: qcom: sc7180: Bump up trogdor ts_reset_l drive strength Douglas Anderson
2022-12-08 23:22 ` Matthias Kaehlcke
2022-12-08 19:20 ` [PATCH 2/5] arm64: dts: qcom: sc7180: Add trogdor eDP/touchscreen regulator off-on-time Douglas Anderson
2022-12-08 23:31 ` Matthias Kaehlcke [this message]
2022-12-08 19:20 ` [PATCH 3/5] arm64: dts: qcom: sc7180: Start the trogdor eDP/touchscreen regulator on Douglas Anderson
2022-12-08 23:33 ` Matthias Kaehlcke
2022-12-08 19:20 ` [PATCH 4/5] arm64: dts: qcom: sc7180: Add pazquel360 touschreen Douglas Anderson
2022-12-08 23:36 ` Matthias Kaehlcke
2022-12-08 19:20 ` [PATCH 5/5] Input: elants_i2c: Delay longer with reset asserted Douglas Anderson
2022-12-08 23:39 ` Matthias Kaehlcke
2022-12-09 1:38 ` Dmitry Torokhov
2022-12-09 1:48 ` Dmitry Torokhov
2022-12-09 1:49 ` Doug Anderson
2022-12-09 1:41 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y5Jzy4hL2x4qcATT@google.com \
--to=mka@chromium.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=ecs.beijing2022@gmail.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.