On Fri, Oct 13, 2023 at 09:55:32AM +0300, Mika Kahola wrote:
> Every know and then we receive the following error when running
> for example IGT test kms_flip.
>
> [drm] *ERROR* PHY G Read 0d80 failed after 3 retries.
> [drm] *ERROR* PHY G Write 0d81 failed after 3 retries.
>
> Since the error is sporadic in nature, the patch proposes
> to reset the message bus after every successful or unsuccessful
> read or write operation. However, the testing revealed that this
> alone is not sufficient method and therefore an additional
> delay is introduced anything from 200us to 300us to let HW to
> settle down. This delay is experimental value and has no
> specification to back it up.
>
> v2: Add FIXME's to indicate the experimental nature of
> this workaround (Rodrigo)
>
> Signed-off-by: Mika Kahola <mika.kahola@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 6e6a1818071e..7c48ec5e54bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -221,6 +221,14 @@ static u8 __intel_cx0_read(struct drm_i915_private *i915, enum port port,
> for (i = 0; i < 3; i++) {
> status = __intel_cx0_read_once(i915, port, lane, addr);
>
> + /*
> + * FIXME: Workaround to let HW to settle
> + * down and let the message bus to end up
> + * in a known state
> + */
> + intel_cx0_bus_reset(i915, port, lane);
> + usleep_range(200, 300);
> +
> if (status >= 0)
> return status;
> }
> @@ -300,6 +308,14 @@ static void __intel_cx0_write(struct drm_i915_private *i915, enum port port,
> for (i = 0; i < 3; i++) {
> status = __intel_cx0_write_once(i915, port, lane, addr, data, committed);
>
> + /*
> + * FIXME: Workaround to let HW to settle
> + * down and let the message bus to end up
> + * in a known state
> + */
> + intel_cx0_bus_reset(i915, port, lane);
> + usleep_range(200, 300);
what cases trigger these paths?
and how many calls in the modset case?
what about suspend/resume cylces?
if we do a single rmw we are introducing at least 400us of delay here.
have we measured the overall final impact of these extra sleeps on the resume and modeset latencies?
> +
> if (status == 0)
> return;
> }
> --
> 2.34.1
>
