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: <36898d74-d9f7-4c5a-b6f2-d9652c674b84@kapsi.fi>
Date: Tue, 17 Jun 2025 13:40:58 +0900
From: Mikko Perttunen <cyndis@...si.fi>
To: Diogo Ivo <diogo.ivo@...nico.ulisboa.pt>,
 Thierry Reding <thierry.reding@...il.com>
Cc: 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 6/16/25 7:21 PM, Diogo Ivo wrote:
> 
> 
> On 6/11/25 4:06 PM, Thierry Reding wrote:
>> 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.
> 
> So if I understand this correctly a Stream ID corresponds to an IOMMU
> domain right?

Technically not necessarily, but in practice that's the case, as the 
IOMMU driver creates IOMMU domains for each stream ID in the device 
tree. They are similar to the SWGROUPs on Tegra210.

> 
>> 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.
> 
> Ok, then in that case I'll keep the driver in its current state without
> these implementations if that's ok. Connected with this I wanted to know
> your thoughts on the best way to upstream this, is it better to wait for
> testing on different platforms first and then if things work merge a
> driver that works for all of them or go with Tegra210 first and then add
> more platforms later on?

Personally, I'd say to go for Tegra210 first.

> 
> Thanks,
> Diogo
> 

Cheers
Mikko