mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH RFC 0/2] Uninterruptible host1x syncpoint wait for Tegra video capture
@ 2026-11-08  5:21 DelaySystem via B4 Relay
  2026-11-08  5:21 ` [PATCH RFC 1/2] gpu: host1x: add uninterruptible syncpoint wait variant DelaySystem via B4 Relay
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: DelaySystem via B4 Relay @ 2026-11-08  5:21 UTC (permalink / raw)
  To: mperttunen, thierry.reding
  Cc: DelaySystem, dri-devel, luca.ceresoli, gregkh, mchehab,
	linux-staging, linux-kernel, clamor95, jonathanh, linux-tegra,
	skomatineni, linux-media

Signed-off-by: DelaySystem <DelaySystem@tubot.lat>
The Tegra20 video capture path runs in a kernel thread and waits on
host1x syncpoints with host1x_syncpt_wait(), which is unconditionally
interruptible: any signal aborts the wait with -ERESTARTSYS. At high
resolutions and framerates these spurious failures are common, so the
driver wraps both waits in do/while retry loops, with a TODO asking
for an uninterruptible variant of the wait.

This series proposes one: patch 1 refactors host1x_syncpt_wait() so
the interruptible behavior is preserved exactly for existing callers
(including two DRM ioctls that are userspace ABI and must stay
interruptible) and adds host1x_syncpt_wait_uninterruptible() for
in-kernel users. Patch 2 converts the Tegra20 capture waits and drops
the retry loops and the TODO.

This is sent as an RFC because the API shape and the scope need
agreement before a final series:

1. Is a separate _uninterruptible() variant the shape host1x wants,
   or would the maintainers prefer something else (for example an
   internal helper with a flag, or a different name)?
2. Tegra210's two waits (tegra210.c) have no retry loop: a spurious
   -ERESTARTSYS currently fails the buffer. Should they convert to
   the uninterruptible wait as well, or is failing on signal
   intentional there?
3. drivers/crypto/tegra/tegra-se-main.c also waits with
   MAX_SCHEDULE_TIMEOUT; left out of scope here, but flagging in
   case its maintainer wants the same treatment.

drivers/staging/media/tegra-video with VIDEO_TEGRA=m, zero warnings).
The tegra20.c change itself has no compile coverage here: that object
builds only for 32-bit ARM (ARCH_TEGRA_2x_SOC/_3x_SOC) and no ARM
toolchain is available, and there is no Tegra hardware for runtime
testing. Hardware testing help is needed before any final series.

Testing: compile-tested only (arm64: drivers/gpu/host1x and
---
DelaySystem (2):
      gpu: host1x: add uninterruptible syncpoint wait variant
      staging: media: tegra-video: uninterruptible syncpt wait for tegra20

 drivers/gpu/host1x/syncpt.c                 | 46 ++++++++++++++++++++++-------
 drivers/staging/media/tegra-video/tegra20.c | 37 +++++++----------------
 include/linux/host1x.h                      |  2 ++
 3 files changed, 48 insertions(+), 37 deletions(-)
---
base-commit: fa4ad798f6f681031775266044ba1b0cf3c670bd
change-id: 20261107-batch1-b1-host1x-wait-3cb3b92e9199

Best regards,
--  
DelaySystem <DelaySystem@tubot.lat>



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-11-09  3:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-08  5:21 [PATCH RFC 0/2] Uninterruptible host1x syncpoint wait for Tegra video capture DelaySystem via B4 Relay
2026-11-08  5:21 ` [PATCH RFC 1/2] gpu: host1x: add uninterruptible syncpoint wait variant DelaySystem via B4 Relay
2026-11-08  5:21 ` [PATCH RFC 2/2] staging: media: tegra-video: uninterruptible syncpt wait for tegra20 DelaySystem via B4 Relay
2026-11-09  3:27 ` [PATCH RFC 0/2] Uninterruptible host1x syncpoint wait for Tegra video capture Mikko Perttunen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®