On Thu, 31 Jul 2025, Jani Nikula <jani.nik...@intel.com> wrote: > On Tue, 15 Jul 2025, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: >> On Tue, Jul 08, 2025 at 04:16:34PM +0300, Ville Syrjala wrote: >>> From: Ville Syrjälä <ville.syrj...@linux.intel.com> >>> >>> While read_poll_timeout() & co. were originally introduced just >>> for simple I/O usage scenarios they have since been generalized to >>> be useful in more cases. >>> >>> However the interface is very cumbersome to use in the general case. >>> Attempt to make it more flexible by combining the 'op', 'var' and >>> 'args' parameter into just a single 'op' that the caller can fully >>> specify. >>> >>> For example i915 has one case where one might currently >>> have to write something like: >>> ret = read_poll_timeout(drm_dp_dpcd_read_byte, err, >>> err || (status & mask), >>> 0 * 1000, 200 * 1000, false, >>> aux, DP_FEC_STATUS, &status); >>> which is practically illegible, but with the adjusted macro >>> we do: >>> ret = poll_timeout_us(err = drm_dp_dpcd_read_byte(aux, DP_FEC_STATUS, >>> &status), >>> err || (status & mask), >>> 0 * 1000, 200 * 1000, false); >>> which much easier to understand. >>> >>> One could even combine the 'op' and 'cond' parameters into >>> one, but that might make the caller a bit too unwieldly with >>> assignments and checks being done on the same statement. >>> >>> This makes poll_timeout_us() closer to the i915 __wait_for() >>> macro, with the main difference being that __wait_for() uses >>> expenential backoff as opposed to the fixed polling interval >>> used by poll_timeout_us(). Eventually we might be able to switch >>> (at least most of) i915 to use poll_timeout_us(). >>> >>> v2: Fix typos (Jani) >>> Fix delay_us docs for poll_timeout_us_atomic() (Jani) >>> >>> Cc: Lucas De Marchi <lucas.demar...@intel.com> >>> Cc: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahman...@intel.com> >>> Cc: Imre Deak <imre.d...@intel.com> >>> Cc: David Laight <david.laight.li...@gmail.com> >>> Cc: Geert Uytterhoeven <geert+rene...@glider.be> >>> Cc: Matt Wagantall <ma...@codeaurora.org> >>> Cc: Dejin Zheng <zhengdej...@gmail.com> >>> Cc: intel-gfx@lists.freedesktop.org >>> Cc: intel...@lists.freedesktop.org >>> Cc: linux-ker...@vger.kernel.org >>> Reviewed-by: Jani Nikula <jani.nik...@intel.com> >>> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> >>> --- >>> include/linux/iopoll.h | 110 +++++++++++++++++++++++++++++------------ >>> 1 file changed, 78 insertions(+), 32 deletions(-) >> >> Any thoughs how we should get this stuff in? Jani will need it for >> some i915 stuff once he returns from vacation, so I could just push >> it into drm-intel-next... >> >> Are people OK with that, or is there a better tree that could pick >> this up? > > Cc: Andrew > > The iopoll.h file is not in MAINTAINERS, and previous changes to it > appear to have gone through various trees. I'd like to base follow-up > work in i915 on this, but who could ack merging the patches via > drm-intel-next? Though doesn't look like anyone's acked the earlier > changes either...
Ville, can you submit this again, please? If we don't get any feedback from anyone, I'm just going to merge this via drm-intel-next. Cc: Dave, Sima. BR, Jani. -- Jani Nikula, Intel
