Avoid hardcoding the LSPCON settle timeout because it takes a longer
time on certain chips made by certain vendors. Use the function that
already exists to determine the timeout.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Giedrius Statkevičius <giedriuswork@gmail.com>
---
v2: add documentation about the parameter, apply 80 character line
    length limit.

 drivers/gpu/drm/display/drm_dp_dual_mode_helper.c | 4 ++--
 drivers/gpu/drm/i915/display/intel_lspcon.c       | 3 ++-
 include/drm/display/drm_dp_dual_mode_helper.h     | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_dual_mode_helper.c b/drivers/gpu/drm/display/drm_dp_dual_mode_helper.c
index 14a2a8473682..d14b262b2344 100644
--- a/drivers/gpu/drm/display/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_dual_mode_helper.c
@@ -486,16 +486,16 @@ EXPORT_SYMBOL(drm_lspcon_get_mode);
  * @dev: &drm_device to use
  * @adapter: I2C-over-aux adapter
  * @mode: required mode of operation
+ * @time_out: LSPCON mode change settle timeout
  *
  * Returns:
  * 0 on success, -error on failure/timeout
  */
 int drm_lspcon_set_mode(const struct drm_device *dev, struct i2c_adapter *adapter,
-			enum drm_lspcon_mode mode)
+			enum drm_lspcon_mode mode, int time_out)
 {
 	u8 data = 0;
 	int ret;
-	int time_out = 200;
 	enum drm_lspcon_mode current_mode;
 
 	if (mode == DRM_LSPCON_MODE_PCON)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c b/drivers/gpu/drm/i915/display/intel_lspcon.c
index f9db867fae89..30c31fddec99 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -211,7 +211,8 @@ static int lspcon_change_mode(struct intel_lspcon *lspcon,
 		return 0;
 	}
 
-	err = drm_lspcon_set_mode(intel_dp->aux.drm_dev, ddc, mode);
+	err = drm_lspcon_set_mode(intel_dp->aux.drm_dev, ddc, mode,
+				  lspcon_get_mode_settle_timeout(lspcon));
 	if (err < 0) {
 		drm_err(display->drm, "LSPCON mode change failed\n");
 		return err;
diff --git a/include/drm/display/drm_dp_dual_mode_helper.h b/include/drm/display/drm_dp_dual_mode_helper.h
index 7ee482265087..7ac6969db935 100644
--- a/include/drm/display/drm_dp_dual_mode_helper.h
+++ b/include/drm/display/drm_dp_dual_mode_helper.h
@@ -117,5 +117,5 @@ const char *drm_dp_get_dual_mode_type_name(enum drm_dp_dual_mode_type type);
 int drm_lspcon_get_mode(const struct drm_device *dev, struct i2c_adapter *adapter,
 			enum drm_lspcon_mode *current_mode);
 int drm_lspcon_set_mode(const struct drm_device *dev, struct i2c_adapter *adapter,
-			enum drm_lspcon_mode reqd_mode);
+			enum drm_lspcon_mode reqd_mode, int time_out);
 #endif
-- 
2.47.0

Hello,

Kind ping.


On Thu, 17 Oct 2024 at 10:57, Giedrius Statkevičius
<giedriuswork@gmail.com> wrote:
>
> Avoid hardcoding the LSPCON settle timeout because it takes a longer
> time on certain chips made by certain vendors. Use the function that
> already exists to determine the timeout.
>
> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> Signed-off-by: Giedrius Statkevičius <giedriuswork@gmail.com>

On Mon, Nov 04, 2024 at 02:09:46PM +0200, Giedrius Statkevičius wrote:
> Hello,
> 
> Kind ping.

There was a pipe underun in CI... I honestly don't believe this patch is
causing it, but anyway I decided to trigger a retest there before I push this.

Thanks for the patch and review.

> 
> 
> On Thu, 17 Oct 2024 at 10:57, Giedrius Statkevičius
> <giedriuswork@gmail.com> wrote:
> >
> > Avoid hardcoding the LSPCON settle timeout because it takes a longer
> > time on certain chips made by certain vendors. Use the function that
> > already exists to determine the timeout.
> >
> > Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> > Signed-off-by: Giedrius Statkevičius <giedriuswork@gmail.com>

Hello,

On Mon, 4 Nov 2024 at 23:28, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>
> On Mon, Nov 04, 2024 at 02:09:46PM +0200, Giedrius Statkevičius wrote:
> > Hello,
> >
> > Kind ping.
>
> There was a pipe underun in CI... I honestly don't believe this patch is
> causing it, but anyway I decided to trigger a retest there before I push this.
>
> Thanks for the patch and review.

I don't see that on my laptop. Resuming sometimes still doesn't work but
this helps a little from my testing. I will continue the investigation.

Best regards,
Giedrius