linux-kernel - Re: [PATCH 0/3] NVIDIA Tegra210 NVJPG support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4cibh66elviiatataa45lsfcyeovkqyxe4fjvfh7uqddhsbe6z@svt2dgeafrdh>
Date: Wed, 11 Jun 2025 17:06:47 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Diogo Ivo <diogo.ivo@...nico.ulisboa.pt>
Cc: Mikko Perttunen <cyndis@...si.fi>, 
	Mikko Perttunen <mperttunen@...dia.com>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Jonathan Hunter <jonathanh@...dia.com>, 
	Philipp Zabel <p.zabel@...gutronix.de>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-kernel@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, linux-tegra@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/3] NVIDIA Tegra210 NVJPG support

On Wed, Jun 11, 2025 at 01:05:40PM +0100, Diogo Ivo wrote:
> 
> 
> On 6/10/25 10:52 AM, Mikko Perttunen wrote:
> > On 6/10/25 6:05 PM, Thierry Reding wrote:
> > > On Fri, Jun 06, 2025 at 11:45:33AM +0100, Diogo Ivo wrote:
> > > > Hello,
> > > > 
> > > > This series adds support for the NVJPG hardware accelerator found in the
> > > > Tegra210 SoC.
> > > > 
> > > > The kernel driver is essentially a copy of the NVDEC driver as both
> > > > engines are Falcon-based.
> > > > 
> > > > For the userspace part I have written a Mesa Gallium backend [1] that,
> > > > while still very much experimental, works in decoding images
> > > > with VA- API.
> > > > 
> > > > I have been using ffmpeg to call VA-API with the following command:
> > > > 
> > > > ffmpeg -v verbose -hwaccel vaapi -hwaccel_device
> > > > /dev/dri/renderD129 -i <input.jpg> -pix_fmt bgra -f fbdev
> > > > /dev/fb0
> > > > 
> > > > which decodes <input.jpg> and shows the result in the framebuffer.
> > > > 
> > > > The firmware for the engine can be obtained from a Linux for Tegra
> > > > distribution.
> > > 
> > > By the way, have you tried running this on anything newer than Tegra210?
> > > Given your progress on this, we can probably start thinking about
> > > submitting the binaries to linux-firmware.
> > 
> > FWIW, the impression I have is that NVJPG is basically unchanged all the
> > way to Tegra234. So if we add stream ID support and the firmwares, it'll
> > probably just work. Tegra234 has the quirk that it has two instances of
> > NVJPG -- these have to be distinguished by their different class IDs.
> > But we should go ahead with the T210 support first.
> 
> I have a question here, what exactly are the stream IDs? While working
> on the driver this came up and I didn't manage to figure it out.

Stream IDs are a way to identify memory transactions as belonging to a
certain device. This comes into play when working with the IOMMU (which
is a Tegra SMMU on Tegra210 and earlier, and an ARM SMMU on Tegra) and
is used to isolate DMA capable devices. Basically for every stream ID
you get a separate I/O address space. NVJPG will have its own address
space, and so will VIC. Each device can only access whatever has been
mapped to it's I/O address space. That means NVJPG can't interfere with
VIC and vice-versa. And neither can any of these engines read from or
write to random system memory if badly programmed.

For Tegra SMMU there's no such thing as programmable stream IDs, so the
stream ID is fixed for the given device.

On newer chips (Tegra186 and later, or maybe it wasn't until Tegra194),
certain IP blocks have special registers that can be used to override
the stream ID. There's also a way to set the stream ID via command
streams, which means that you can have different I/O address spaces (I
think we call them memory context) per engine, which means that you can
isolate different processes using the same engine from each other.

Again, for Tegra210 that's nothing we need to worry about. For newer
chips it's probably just a matter of adding .get_streamid_offset() and
.can_use_memory_ctx() implementations.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)