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
