From: John Watts <contact@jookia.org>
To: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: dri-devel@lists.freedesktop.org,
Neil Armstrong <neil.armstrong@linaro.org>,
Sam Ravnborg <sam@ravnborg.org>, David Airlie <airlied@gmail.com>,
Daniel Vetter <daniel@ffwll.ch>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Shawn Guo <shawnguo@kernel.org>, Heiko Stuebner <heiko@sntech.de>,
Chris Morgan <macromorgan@hotmail.com>,
Jagan Teki <jagan@edgeble.ai>,
Paul Cercueil <paul@crapouillou.net>,
Christophe Branchereau <cbranchereau@gmail.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 3/9] drm/panel: nv3052c: Sleep for 150ms after reset
Date: Tue, 19 Sep 2023 06:52:12 +1000 [thread overview]
Message-ID: <ZQi4fFZ0VnsUIiXO@titan> (raw)
In-Reply-To: <7fc1ca68-ca7c-59b2-0b70-27bc34d83cee@quicinc.com>
On Mon, Sep 18, 2023 at 01:19:03PM -0700, Jessica Zhang wrote:
> Hi John,
>
> Just wondering, is there some context to this change? I.e., was this made to
> fix a specific issue?
>
> This seems like a pretty significant increase in wait time so, if it's not a
> fix, I'm not sure if this would be an improvement on the current behavior.
>
> Thanks,
>
> Jessica Zhang
Hi Jessica,
Thank you for the feedback.
This patch here is required by the data sheet if the screen was already running
and was reset. This is necessary if for example the bootloader set up and had
the screen running. However I have not tested this, it's possible the specific
panels have shorter tolerances for resets. This is purely precautionary at
this stage based on what the data sheet says.
That said I will be investigating this specific use case with this panel over
the next few months. I am okay separating out this patch until I have proof it's
needed for my particular display. I don't know anything about the ltk display.
The second sleep patch can probably be omitted as I don't think the panel being
prepared then unprepared in rapid succession is a realistic situation, but I
figured I might as well propose it to see if it's the right thing to do.
Thanks for your time and review,
John.
next prev parent reply other threads:[~2023-09-18 20:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 12:58 [RFC PATCH v2 0/9] Add FS035VG158 panel John Watts
2023-09-18 12:58 ` [RFC PATCH v2 1/9] drm/panel: nv3052c: Document known register names John Watts
2023-09-18 12:58 ` [RFC PATCH v2 2/9] drm/panel: nv3052c: Add SPI device IDs John Watts
2023-09-18 12:58 ` [RFC PATCH v2 3/9] drm/panel: nv3052c: Sleep for 150ms after reset John Watts
2023-09-18 20:19 ` Jessica Zhang
2023-09-18 20:52 ` John Watts [this message]
2023-09-18 21:01 ` Paul Cercueil
2023-09-18 21:08 ` John Watts
2023-09-18 21:34 ` Paul Cercueil
2023-09-18 21:40 ` John Watts
2023-09-18 12:58 ` [RFC PATCH v2 4/9] drm/panel: nv3052c: Wait before entering sleep mode John Watts
2023-09-18 20:27 ` Jessica Zhang
2023-09-18 12:58 ` [RFC PATCH v2 5/9] drm/panel: nv3052c: Allow specifying registers per panel John Watts
2023-09-18 12:58 ` [RFC PATCH v2 6/9] drm/panel: nv3052c: Add Fascontek FS035VG158 LCD display John Watts
2023-09-18 20:35 ` Jessica Zhang
2023-09-18 12:58 ` [RFC PATCH v2 7/9] dt-bindings: display: panel: Clean up leadtek,ltk035c5444t properties John Watts
2023-09-18 22:28 ` Rob Herring
2023-09-18 12:58 ` [RFC PATCH v2 8/9] dt-bindings: vendor-prefixes: Add fascontek John Watts
2023-09-18 12:58 ` [RFC PATCH v2 9/9] dt-bindings: display: panel: add Fascontek FS035VG158 panel John Watts
2023-09-18 22:29 ` Rob Herring
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=ZQi4fFZ0VnsUIiXO@titan \
--to=contact@jookia.org \
--cc=airlied@gmail.com \
--cc=cbranchereau@gmail.com \
--cc=conor+dt@kernel.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=jagan@edgeble.ai \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macromorgan@hotmail.com \
--cc=neil.armstrong@linaro.org \
--cc=paul@crapouillou.net \
--cc=quic_jesszhan@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=sam@ravnborg.org \
--cc=shawnguo@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).