Hi,
Am 24.01.2018 um 08:45 schrieb Tomi Valkeinen tomi.valkeinen@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