summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorVille Syrjälä <ville.syrjala@linux.intel.com>2025-11-19 20:53:10 +0200
committerVille Syrjälä <ville.syrjala@linux.intel.com>2025-11-28 00:48:53 +0200
commit40a9f77a28faa8a0803371903c15372026e2c050 (patch)
tree10dab8897a2a3f7ad6be3346c568fb66dea47993 /include
parent1513904c46b61e483e4d61519c31078581bb6cb8 (diff)
Revert "drm/i915/dp: change aux_ctl reg read to polling read"
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. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119185310.10428-3-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions