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

[Tomi Valkeinen]

On 23/01/18 19:15, H. Nikolaus Schaller wrote:
> 
>> Am 23.01.2018 um 17:41 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
>>
>> On 23/01/18 18:18, H. Nikolaus Schaller wrote:
>>
>>>> The community cannot provide patches for the libraries as they are
>>>> closed source.
>>>
>>> That is not the goal of the project.
>>
>> Yep, I was replying to the above comment about "community providing
>> patches to the SGX library" from Adam. Or maybe I misunderstood what he
>> said.
> 
> Ah, ok. The confusion is that you see the library as the "real" driver here
> while we refer with "driver" to the kernel module only.

Well, Adam said "library", and I don't think that means the kernel
driver. Anyway, that's not important.

Yes, while kind of correct, I think it's slightly misleading to talk
about SGX driver and refer only to the kernel part. I think "driver" is
often taken to mean a piece of code that enables you to use a piece of
HW. That's not the case here, as you can't do anything without the
matching closed-source userspace libraries. You always need both,
individually they are useless.

Talking about SGX driver is fine when it's clear from the context that
it's about the kernel side, but I usually like to specify kernel or
userspace when talking about SGX to avoid any unclarities.

>>> demonstrator patch set shows. There is only one piece missing to make
>>> blobs + kernel driver work on 4.15-rc9 again.
>>>
>>> And if we don't do the first step, we will never be able to improve it.
>>
>> I'm not quite sure I understand what you're trying here. You said that
>> you want this work based on the latest SGX kernel driver from TI. That
>> driver is for the latest userspace libraries.
> 
> What is the problem of using the matching user space libraries?

Nothing, if they provide the features you need. But they only support
SoCs that TI currently support, so no OMAP3 (as far as I know). If the
latest SGX driver works for you, I very much recommend using it rather
than the old one.

>> I don't think it will ever
>> work with the old libraries.
> 
> AFAIK, nobody wants to achieve that. It is about using the latest libs for each SoC.
> Those are not the same, but it appears according to my analyses that this does
> not influence the driver code. The older and newer driver versions are not very different.
> They just add more and more #ifdefs for kernel API changes and SGX errata.

Ok, if that's the case, then it's very good. I was under the impression
that there are big differences. If we can have a single kernel driver
that supports different versions of userspace binaries, it will help
things quite a bit.

> As written in another mail, SGX firmware and user-space libs are sort of
> "application" for the SGX. Those must match of course. If you take old firmware
> and old libs they should work. If you take new libs and firmware they should
> work as well. With the same driver.
> 
> If in the future someone manages to reverse engineer the SGX and writes a
> new firmware + user-space that should also work with the same driver.

If someone manages to reverse engineer SGX, I would imagine that we
would be better off with a totally new kernel side driver =).

> The kernel driver just makes sure that the user-space can communicate with
> the SGX, i.e. can load firmware and exchange shaders, images etc.
> 
> So to summarize: the sgx530 user-space binaries already run on dm3730 and
> am335x and the sgx544 should run on omap5.

So you are using the old userspace binaries for dm3730, and the latest
ones for am335x and omap5? Or that's still on the works?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki