[Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

Hi,

> Am 24.01.2018 um 08:45 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
> 
> On 23/01/18 19:56, Tony Lindgren wrote:
> 
>> We really need some coordinated effort to get the driver kernel parts
>> to usable state though. And considering the number of people involved
>> I think staging is the best place to do it. Then what happens after that
>> is of course up in the air as always. In the worst case it will get just
>> dropped lik the TI dsp stuff based on zero effort :)
> 
> Yes, I have nothing against the idea. My fear is that it'll be difficult
> to have a single SGX kernel driver which works for all the SGX userspace
> binaries. As the kernel and userspace parts are always shipped as a
> pair,

This seems to have different reasons. As far as I can deduce from the code
IMG provided a core (everyhing using the camel-case functions) matching
different SGX versions. Newer versions seem to include more SGX support than
older ones. I.e. SGX544 is only in the latest ones.

Now, TI did augment that with proper glue code for the SoC. This sits mainly
in services4/system/$SOC_VERSION

This has been updated from time to time and more and more kernel API changes
have been covered by conditional compiles.

This means that basically the latest code should still compile for/run
for 2.6.32.

It may just have been far too much work to test every potential combination
and therefore sgx user-space and kernel versions seem to be synced.

> my guess is that there has never been any attempt to keep the UAPI
> stable. But I'm basing my guess on no actual knowledge, so I'm happy to
> be proven wrong =).

The other question is why this should depend on any other API?

As far as I understand there is a /proc/pvr device and a handful of ioctls
for it. And mmap() is used to give the user-space libs access to the SGX.
There is also some DMA stuff.

This basic principle seems not to have changed between all version. What
must match is the microkernel version running on the SGX and the user-space
library blob.

Because they define an IMG internal protocol to send images and shader commands
around. But AFAIK the mechanism to communicate hasn't changed fundamentally.

But this microkernel is also part of user-spacecode (compiled into pvrsrvctl)
and not any kernel code. Kernel only provides a communication mechanism like
e.g. Ethernet. It is independent on which data you copy from one user-space
to some "remote" device.

Well, I may have overlooked the one counter-example.

> 
>> And there finally seems to some effort going on by the chromeos guys.
>> 
>> FYI again if it was not mentioned earlier, here's the thread for
>> upstreaming Roque support?
>> 
>> "[POC 00/16] Chromebook R13 GPU driver port":
>> 
>> https://lists.freedesktop.org/archives/dri-devel/2017-November/157737.html
>> 
>> No idea how much of that will be usable for SGX though.
> 
> If I understood right, it's not about upstreaming. It was about getting
> the Rogue userspace binaries work on top of mainline, i.e. porting the
> kernel driver on top of mainline.
> 
> And, again, my understanding of the "DRM philosophy" is that having
> kernel drivers like these is explicitly forbidden in the mainline. Which
> is why e.g. there's no nvidia kernel driver.

Well, if the "DRM philosophy" requires to modify the communication protocols
between the sgx libs and the sgx microkernel, then we have a problem.

BR,
Nikolaus