Re: [PATCH 2/2] Revert "drm/i915/dp: change aux_ctl reg read to polling read"

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Nov 20, 2025 at 03:08:12PM +0200, Jani Nikula wrote:
> On Thu, 20 Nov 2025, "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> >> -----Original Message-----
> >> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Ville
> >> Syrjala
> >> Sent: Thursday, November 20, 2025 12:23 AM
> >> To: intel-gfx@lists.freedesktop.org
> >> Cc: intel-xe@lists.freedesktop.org
> >> Subject: [PATCH 2/2] Revert "drm/i915/dp: change aux_ctl reg read to polling
> >> read"
> >> 
> >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> 
> >> This reverts commit 5a9b0c7418448ed3766f61ba0a71d08f259c3181.
> >> 
> >> The switch from AUX interrupts to pollign was very hand-wavy.
> >> Yes, there have been some situations in CI on a few platforms where the AUX
> >> hardware seemingly forgets to signal the timeout, but those have been
> >> happening after we switched to polling as well. So I don't think we have any
> >> conclusive evidence that polling actually helps here.
> >> 
> >> Someone really should root cause the actual problem, and see if there is a
> >> proper workaround we could implemnt (eg. disabling clock gating/etc.). In the
> >> meantime just go back to using the interrupt for AUX completion.
> >> 
> >> If the hardware fails to signal the timeout we will just hit the
> >> wait_event_timeout() software timeout instead. I suppose we could try to tune
> >> the software timeout to more closely match the expected hardware timeout.
> >> Might need to use
> >> wait_event_hrtimeout() or something to avoid jiffies granularity issues...
> >> 
> >> The AUX polling is also a hinderance towards using poll_timeout_us() because
> >> we have a very long timeout, but would need a fairly short polling interval to
> >> keep AUX transfer reasonably fast. Someone would need to come up with good
> >> numbers in a somewhat scientific way.
> >> 
> > Upon multiple rounds of validation based on the results polling had improvements when compared with the interrupt mechanism. We can optimize more by using poll_timeout, I am afraid that reverting back to interrupts may end up with more failures.

What exactly do you mean by failures? IIRC the only thing we've
seen is the software timeout firing instead of the hw timeout,
which shouldn't be a problem really. Eiter way the AUX transfer
failed.

> 
> I'm not sure the issues were root caused properly.

At least the commit message is completely useless in explaining any
of it. No explanation of what the actual issue seen was, no test
resutls, no mention of what other workarounds were attempted, 
no root cause...

-- 
Ville Syrjälä
Intel