Hi Jani,
On 16/09/26 07:38, Jani Nikula wrote:
On Tue, 15 Sep 2026, Maíra Canal <[email protected]> wrote:
drm_timeout_abs_to_jiffies() covers the drivers whose wait UAPI takes an
absolute deadline, but there is no equivalent for the drivers that
express a wait as a duration. Drivers such as i915 and v3d convert the
value themselves.
Converting a nanosecond duration to jiffies needs some care.
nsecs_to_jiffies() returns unsigned long, so on 32-bit a large
userspace-supplied timeout overflows its range and is silently truncated.
i915 already handles both cases in a local helper, which v3d has a copy
of. Add the same conversion to the core, so that it is available to any
driver and both copies can be dropped.
Signed-off-by: Maíra Canal <[email protected]>
---
drivers/gpu/drm/drm_timeout.c | 45 +++++++++++++++++++++++++++++++++++++++++++
include/drm/drm_timeout.h | 1 +
2 files changed, 46 insertions(+)
[...]
diff --git a/include/drm/drm_timeout.h b/include/drm/drm_timeout.h
index cd9621c52062..6ee222a3e97c 100644
--- a/include/drm/drm_timeout.h
+++ b/include/drm/drm_timeout.h
@@ -12,5 +12,6 @@
#include <linux/types.h>
signed long drm_timeout_abs_to_jiffies(s64 timeout_nsec);
+unsigned long drm_timeout_rel_to_jiffies(u64 timeout_nsec);
The signed/unsigned differences here bug me a little. Maybe explain why
in the commit message if there's a rationale?
Answering both your e-mails, the rational behind this change was: don't
make any changes to drm_timeout_abs_to_jiffies(); only move it as it is.
As I'm the one introducing drm_timeout_rel_to_jiffies(), I took the
liberty to implement it in a way that makes more sense to me, which is
using `unsigned long`, considering that a timeout in jiffies should
always be positive. Also, i915 and v3d implement the function returning
an unsigned long.
I believe that drm_timeout_abs_to_jiffies() historically returned a
signed long because dma_fence_wait_timeout() takes a signed long timeout
parameter (I'm not sure why).
Best regards,
- Maíra
I note that drm_timeout_rel_to_jiffies() return value is assigned to
unsigned long variables half the time. I guess its kernel-doc could say
it never returns negative values?
BR,
Jani.
