[PATCH 0/3] NVIDIA Tegra210 NVJPG support

[Mikko Perttunen]

On 6/17/25 6:26 PM, Diogo Ivo wrote:
> 
> 
> 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?

I left one more comment on the v2 patch. With that fixed, if Thierry has 
no further objections, hopefully he can merge.

Cheers,
Mikko

> 
> Thanks,
> Diogo
> 
>> Cheers
>> Mikko
>