From: Mikko Perttunen <mperttunen@nvidia.com>
To: thierry.reding@kernel.org, linux-staging@lists.linux.dev
Cc: DelaySystem <DelaySystem@tubot.lat>,
dri-devel@lists.freedesktop.org, luca.ceresoli@bootlin.com,
gregkh@linuxfoundation.org, mchehab@kernel.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
clamor95@gmail.com, jonathanh@nvidia.com,
linux-tegra@vger.kernel.org, skomatineni@nvidia.com,
linux-media@vger.kernel.org, DelaySystem@tubot.lat
Subject: Re: [PATCH RFC 0/2] Uninterruptible host1x syncpoint wait for Tegra video capture
Date: Mon, 09 Nov 2026 12:27:29 +0900 [thread overview]
Message-ID: <L2SDRXLsTSiAzYTWAeJY9A@nvidia.com> (raw)
In-Reply-To: <20261107-batch1-b1-host1x-wait-v1-0-8c8198adf600@tubot.lat>
On Sunday, November 8, 2026 2:21 PM DelaySystem via B4 Relay wrote:
> 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.
nak
>
> 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>
>
>
>
prev parent reply other threads:[~2026-11-09 3:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` Mikko Perttunen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=L2SDRXLsTSiAzYTWAeJY9A@nvidia.com \
--to=mperttunen@nvidia.com \
--cc=DelaySystem@tubot.lat \
--cc=clamor95@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux-tegra@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=mchehab@kernel.org \
--cc=skomatineni@nvidia.com \
--cc=thierry.reding@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.