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] [day] [month] [year] [list]

Message-ID: <82bfabf0-8c55-4bbd-8c81-44dc86209b15@tecnico.ulisboa.pt>
Date: Tue, 17 Jun 2025 10:26:54 +0100
From: Diogo Ivo <diogo.ivo@...nico.ulisboa.pt>
To: Mikko Perttunen <cyndis@...si.fi>,
 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/17/25 5:40 AM, Mikko Perttunen wrote:
> 
> 
> 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.

Ok that makes sense, thank you for the clarification :)

>> 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.

In that case I believe that in the v2 I sent out of the driver I addressed
both yours and Thierry's reviews and the driver should be in good condition
for Tegra210. What are the next steps in order to merge it?

Thanks,
Diogo

> Cheers
> Mikko