On Thu, 31 Jul 2025, Jani Nikula <[email protected]> wrote: > On Tue, 15 Jul 2025, Ville Syrjälä <[email protected]> wrote: >> On Tue, Jul 08, 2025 at 04:16:34PM +0300, Ville Syrjala wrote: >>> From: Ville Syrjälä <[email protected]> >>> >>> 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 <[email protected]> >>> Cc: Dibin Moolakadan Subrahmanian <[email protected]> >>> Cc: Imre Deak <[email protected]> >>> Cc: David Laight <[email protected]> >>> Cc: Geert Uytterhoeven <[email protected]> >>> Cc: Matt Wagantall <[email protected]> >>> Cc: Dejin Zheng <[email protected]> >>> Cc: [email protected] >>> Cc: [email protected] >>> Cc: [email protected] >>> Reviewed-by: Jani Nikula <[email protected]> >>> Signed-off-by: Ville Syrjälä <[email protected]> >>> --- >>> 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
