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

[Daniel Vetter]

On Tue, Dec 06, 2016 at 11:33:11AM +0200, Mikko Perttunen wrote:
> 
> 
> 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.

More uabi also includes stuff like adding more support for newer engines,
more platforms, newer chips and all that. Anything really that is a
contract between the kernel and userspace about how the hw is set up (so
e.g. fancy features that need a few bits to be set correctly, or the right
microcode to be loaded or something like that are also included.

Otherwise it'd be trivial to game by doing a basic driver for the very
first chip that no one cares about any more, open source it, and then do
all future enabling with the blob drivers only in userspace.

This open source userspace requirement isn't just to validate the bare
ioctl structs and stuff. We have it _exactly_ because gpu interfaces are
ridiculously wide (for speed and flexibility reasons), and hence it does
apply for every extension. Even if you don't change any of the uapi
headers (since those describe just a miniscule part of the overall drm
interface exported to userspace). Another example is adding more atomic
properties, which also doesn't change anything with the ioctl or structs
itself.

> Is that reasonable?

If you have the userspace (and it needs to be real, not just promised)
then yes. Otherwise imo no. E.g. Rob Clark always makes sure on msm that
his r/e'ed mesa branch _does_ work properly, before merging support for
new hw or engines or anything like that. Intel/AMD do the same, and so
should nvidia.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch