From: Brian Norris <briannorris@chromium.org>
To: Kencp huang <kencp_huang@asus.corp-partner.google.com>
Cc: Laurent.pinchart@ideasonboard.com, andrzej.hajda@intel.com,
airlied@gmail.com, neil.armstrong@linaro.org, daniel@ffwll.ch,
dri-devel@lists.freedesktop.org, hoegsberg@chromium.org,
jernej.skrabec@gmail.com, jonas@kwiboo.se, kencp_huang@asus.com,
linux-kernel@vger.kernel.org, rfoss@kernel.org,
seanpaul@chromium.org, wzz@rock-chips.com, zyw@rock-chips.com
Subject: Re: [PATCH 1/1] drm/bridge: analogix_dp: add a quirk for Bob panel
Date: Tue, 14 Feb 2023 13:02:15 -0800 [thread overview]
Message-ID: <Y+v216m4Ba+tiIlt@google.com> (raw)
In-Reply-To: <20230208044406.8280-1-kencp_huang@asus.corp-partner.google.com>
Hi,
You seem to have sent this twice, perhaps to adjust the To/CC list. I
think I've picked the right one to reply to, but it's usually nice to
use a "v2" notation or otherwise put a comment somewhere in the email.
On Wed, Feb 08, 2023 at 12:44:06PM +0800, Kencp huang wrote:
> From: zain wang <wzz@rock-chips.com>
>
> Some panels' DP_PSR_STATUS (DPCD 0x2008) may be unstable when we
> enable psr. If we get the unexpected psr state, We need try the
> debounce to ensure the panel was in PSR
>
> Signed-off-by: zain wang <wzz@rock-chips.com>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Commit-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
'Commit-Ready' isn't something that makes sense for upstream Linux. The
other 'Tested-by' and 'Reviewed-by' *might* make sense to carry forward,
even though these were from the Chromium Gerrit instance, but they also
applied to a very old and different version of this patch, so probably
not.
I'd suggest starting over with only the Signed-off-by tags.
> Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
> Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
> Tested-by: Kencp huang <kencp_huang@asus.corp-partner.google.com>
> Signed-off-by: Kencp huang <kencp_huang@asus.corp-partner.google.com>
> ---
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 71 +++++++++++--------
> 1 file changed, 42 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 6a4f20fccf84..7b6e3f8f85b0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -935,25 +935,54 @@ void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp)
> writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
> }
>
> -static ssize_t analogix_dp_get_psr_status(struct analogix_dp_device *dp)
> +static int analogix_dp_get_psr_status(struct analogix_dp_device *dp,
Probably could be called 'analogix_dp_wait_psr_status()', since it's no
longer just a "getter" function.
> + int status)
This would probably make more sense as a 'bool psr_active' or some
similar naming, since it doesn't really represent a "status" field now,
but more of a "am I entering or exiting PSR?" parameter.
> {
> ssize_t val;
> - u8 status;
> + u8 reg, store = 0;
> + int cnt = 0;
> +
> + /* About 3ms for a loop */
The commit description explains why you need this polling/debounce loop,
but it's good to document such artifacts in the code too, when they're
as strange as this one. Perhaps a short explanation about the "bouncing"
behavior of some panels here? "Some panels' DP_PSR_STATUS register is
unstable when entering PSR."
Also, I already had a (pre mailing list) question about why this doesn't
use readx_poll_timeout(), so I'll repeat for the record one reason not
to: it's difficult to handle the stateful debouncing aspect with that
macro, and keep the 'store' variable around.
> + while (cnt < 100) {
> + /* Read operation would takes 900us */
> + val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, ®);
> + if (val < 0) {
> + dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
> + return val;
> + }
> +
> + /*
> + * Ensure the PSR_STATE should go to DP_PSR_SINK_ACTIVE_RFB
> + * from DP_PSR_SINK_ACTIVE_SINK_SYNCED or
> + * DP_PSR_SINK_ACTIVE_SRC_SYNCED.
> + * Otherwise, if we get DP_PSR_SINK_ACTIVE_RFB twice in
> + * succession, it show the Panel is stable PSR enabled state.
> + */
> + if (status == DP_PSR_SINK_ACTIVE_RFB) {
> + if ((reg == DP_PSR_SINK_ACTIVE_RFB) &&
> + ((store == DP_PSR_SINK_ACTIVE_SINK_SYNCED) ||
> + (store == DP_PSR_SINK_ACTIVE_SRC_SYNCED) ||
> + (store == DP_PSR_SINK_ACTIVE_RFB)))
> + return 0;
> + else
> + store = reg;
> + } else {
You dropped the ACTIVE_RESYNC and INACTIVE comments from below. Those
probably should move here.
With those fixed, I think this would be fine:
Reviewed-by: Brian Norris <briannorris@chromium.org>
> + if ((reg == DP_PSR_SINK_INACTIVE) ||
> + (reg == DP_PSR_SINK_ACTIVE_RESYNC))
> + return 0;
> + }
>
> - val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &status);
> - if (val < 0) {
> - dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
> - return val;
> + usleep_range(2100, 2200);
> + cnt++;
> }
> - return status;
> +
> + return -ETIMEDOUT;
> }
>
> int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> struct dp_sdp *vsc, bool blocking)
> {
> unsigned int val;
> - int ret;
> - ssize_t psr_status;
>
> /* don't send info frame */
> val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
> @@ -998,26 +1027,10 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> if (!blocking)
> return 0;
>
> - /*
> - * db[1]!=0: entering PSR, wait for fully active remote frame buffer.
> - * db[1]==0: exiting PSR, wait for either
> - * (a) ACTIVE_RESYNC - the sink "must display the
> - * incoming active frames from the Source device with no visible
> - * glitches and/or artifacts", even though timings may still be
> - * re-synchronizing; or
> - * (b) INACTIVE - the transition is fully complete.
> - */
> - ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
> - psr_status >= 0 &&
> - ((vsc->db[1] && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
> - (!vsc->db[1] && (psr_status == DP_PSR_SINK_ACTIVE_RESYNC ||
> - psr_status == DP_PSR_SINK_INACTIVE))),
> - 1500, DP_TIMEOUT_PSR_LOOP_MS * 1000);
> - if (ret) {
> - dev_warn(dp->dev, "Failed to apply PSR %d\n", ret);
> - return ret;
> - }
> - return 0;
> + if (vsc->db[1])
> + return analogix_dp_get_psr_status(dp, DP_PSR_SINK_ACTIVE_RFB);
> + else
> + return analogix_dp_get_psr_status(dp, 0);
> }
>
> ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
> --
> 2.34.1
>
prev parent reply other threads:[~2023-02-14 21:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 3:15 Kencp huang
2023-02-08 4:44 ` Kencp huang
2023-02-14 21:02 ` Brian Norris [this message]
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=Y+v216m4Ba+tiIlt@google.com \
--to=briannorris@chromium.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hoegsberg@chromium.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kencp_huang@asus.com \
--cc=kencp_huang@asus.corp-partner.google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=seanpaul@chromium.org \
--cc=wzz@rock-chips.com \
--cc=zyw@rock-chips.com \
/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
all inboxes | Powered by JetHome®