[PATCH 0/8] Host1x IOMMU support + VIC support

[Mikko Perttunen]

On 12/06/2016 09:14 AM, Daniel Vetter wrote:
> On Mon, Dec 05, 2016 at 08:51:31PM +0100, Thierry Reding wrote:
>> On Thu, Nov 10, 2016 at 08:23:37PM +0200, Mikko Perttunen wrote:
>>> This series adds IOMMU support to Host1x and TegraDRM
>>> and adds support for the VIC host1x client so that
>>> host1x can be tested on modern Tegra platforms.
>>> It depends on the previous fix series. The whole thing
>>> (modulo patch order) is available as a git repository at
>>> git://github.com/cyndis/linux.git; branch vic-v1.
>>>
>>> IO memory management is organized such that there are
>>> two domains: the host1x domain and the tegradrm domain.
>>> The host1x domain is used by the host1x engine and
>>> contains the host1x CDMA and pushbuffers for submitted
>>> jobs.
>>>
>>> The tegradrm domain is shared by all host1x units and
>>> contains GEM objects and memory allocated by the
>>> separate tegra_drm_alloc function. This function is
>>> currently used to allocate space for firmware blobs
>>> in the tegradrm domain.
>>>
>>> A userspace test case for VIC can be found at
>>> https://github.com/cyndis/drm/tree/work/tegra.
>>> The testcase is in tests/tegra and is called submit_vic.
>>> The in-kernel firewall is not implemented for VIC;
>>> therefore, IOMMU must be enabled for the test to pass.
>>>
>>> Tested with Jetson TX1 (T210). Probably works also
>>> with Jetson TK1 (T124). Note that due to hardware changes
>>> the testcase also needs to be changed to run properly
>>> on T124.
>>
>> What's the scope of the changes required for Tegra124? If we add the
>> kernel bits for Tegra124 we should also have a userspace test program to
>> exercise it.
>
> Please note that just a test program is not really enough to add more uabi
> (and VIC support here maybe classifies at that, no idea how this all
> works). Aka does mesa run, and for the vic stuff, does some libva/libvdpau
> open source implementation run on this?
> -Daniel
>

VIC is just an image compositor so if we wanted to use it alone we would 
probably need to implement X11 2D acceleration (at least nothing else 
comes to mind), which isn't that useful nowadays, since nouveau works 
too. I'm internally working on NVDEC (the video decoder) at the moment - 
if/when I'm allowed to upstream that, I'll provide more extensive 
userspace for decoding video. This would most likely be a libva or 
libvdpau backend; I have already prototyped these. This will also most 
likely use VIC for image format conversions.

As for the "more UABI" question; the UABI used here already exists in 
the kernel and libdrm. The same UABI can be used for any Host1x unit 
without modifications; we have previously exercised it on older Tegra 
revisions with different units. The only thing that changes is a new 
enumeration value is added for the new unit.

Is that reasonable?

Thanks,
Mikko.