All of lore.kernel.org
 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
  0 siblings, 0 replies; 7+ messages in thread
From: DelaySystem @ 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] 7+ messages in thread

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

Thread overview: 7+ 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
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
2026-11-08  5:21   ` DelaySystem via B4 Relay
2026-11-08  5:21 ` [PATCH RFC 2/2] staging: media: tegra-video: uninterruptible syncpt wait for tegra20 DelaySystem
2026-11-08  5:21   ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.