All of lore.kernel.org
 help / color / mirror / Atom feed
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, &reg);
> +		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
> 

WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org>
To: Kencp huang <kencp_huang@asus.corp-partner.google.com>
Cc: neil.armstrong@linaro.org, jernej.skrabec@gmail.com,
	rfoss@kernel.org, andrzej.hajda@intel.com, jonas@kwiboo.se,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	kencp_huang@asus.com, wzz@rock-chips.com, seanpaul@chromium.org,
	Laurent.pinchart@ideasonboard.com, zyw@rock-chips.com,
	hoegsberg@chromium.org
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, &reg);
> +		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
> 

  reply	other threads:[~2023-02-14 21:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08  3:15 [PATCH 1/1] drm/bridge: analogix_dp: add a quirk for Bob panel Kencp huang
2023-02-08  3:15 ` Kencp huang
2023-02-08  4:44 ` Kencp huang
2023-02-08  4:44   ` Kencp huang
2023-02-14 21:02   ` Brian Norris [this message]
2023-02-14 21:02     ` Brian Norris

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 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.