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: <1ee42017-63e1-4b01-ba1f-8f548cba8733@tecnico.ulisboa.pt>
Date: Mon, 16 Jun 2025 11:26:34 +0100
From: Diogo Ivo <diogo.ivo@...nico.ulisboa.pt>
To: 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/11/25 4:10 PM, Thierry Reding wrote:
> On Wed, Jun 11, 2025 at 01:04:14PM +0100, Diogo Ivo wrote:
>>
>>
>> On 6/10/25 10:05 AM, 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.
>>
>> Since I don't have access to other Tegra platforms I haven't been able
>> to test this driver there. For this I need help from someone with access
>> to more hardware, I can send a version that just adds the extra compatibles
>> and we could see if it works.
>>
>> As for the firmwares that would be great!
> 
> I think both of these are things that Mikko and I can help with.

That would be great (as I imagine you have access to the hardware :) ).
Let me know if you have any questions!

>>>> Due to the way the Gallium implementation works for Tegra
>>>> the GPU also needs to be enabled.
>>>
>>> I wonder if maybe we can get rid of this requirement. While it's
>>> certainly nice to have the GPU enabled, there may be cases where using
>>> only the other engines may be advantageous. Originally when I had worked
>>> on VIC, I was looking at how it could be used for compositing without
>>> getting the GPU involved. That's something that Android devices tend(ed)
>>> to do because of the power savings that come with it.
>>
>> Yes I think this is possible to do, it mainly has involves properly
>> handling the Gallium driver initialization. I'll take a look at it
>> before submitting the MR for the Gallium driver.
> 
> Okay, great. But I think it's definitely something that we can defer if
> it's non-trivial.

Perfect then, in that case I'll skip it for now and open a Mesa MR after
taking care of some final details.

Thanks,
Diogo