On Thu, Nov 20, 2025 at 03:08:12PM +0200, Jani Nikula wrote: > On Thu, 20 Nov 2025, "Murthy, Arun R" <[email protected]> wrote: > >> -----Original Message----- > >> From: Intel-gfx <[email protected]> On Behalf Of > >> Ville > >> Syrjala > >> Sent: Thursday, November 20, 2025 12:23 AM > >> To: [email protected] > >> Cc: [email protected] > >> Subject: [PATCH 2/2] Revert "drm/i915/dp: change aux_ctl reg read to > >> polling > >> read" > >> > >> From: Ville Syrjälä <[email protected]> > >> > >> 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
