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: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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
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 ` 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 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®