mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>
> 
> 
> 





      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®