[Openpvrsgx-devgroup] Status & HW to bring

H. Nikolaus Schaller hns at goldelico.com
Wed Nov 13 09:02:16 CET 2019

Hi Sebastian,

> Am 13.11.2019 um 01:50 schrieb Sebastian Reichel <sre at kernel.org>:
> Hi,
> On Sun, Nov 10, 2019 at 10:15:32AM -0800, Tony Lindgren wrote:
>> * H. Nikolaus Schaller <hns at goldelico.com> [191109 17:10]:
>>>> Am 09.11.2019 um 17:42 schrieb Tony Lindgren <tony at atomide.com>:
>>>> * H. Nikolaus Schaller <hns at goldelico.com> [191109 13:17]:
>>>>> 5. reshape the driver to be able to submit it into drivers/staging/pvr mainline
>>>> According to Sebastian this is unlikely to happen though, so
>>>> adding Sebastian to Cc.
>>> Fine!
> It was mentioned in one of the talks at Linux Plumbers Conference
> this year. IIRC the main reason is, that DRM developers like to
> refactor "their" in-kernel APIs, which is a lot simpler when you
> do not have to do it in two trees.

Understandable reason.

> Greg with his staging maintainer
> hat agreed on not merging graphics drivers via staging.

> It was most likely mentioned in this talk:
> https://linuxplumbersconf.org/event/4/contributions/549/

Ok, if that is the direction to go, it is easy (I'll just have to do
another git filter-tree in the next days and look for top level
Kconfig and Makefile).

>>> The idea behind is to pile up everything we can find first, but in a strict format. So
>>> that we have it in one place for studying and doing comparisons. And then we can merge
>>> and shrink and rework to a single driver in letux/staging-pvr (or however it will be called).
>> Yup makes sense to me.
> Apart from the "no staging" rule, there is another fundamental rule:
> There must be a FOSS userspace client for the kernel driver. It's ok
> to have a dual-stack, though. It's easy to explain with desktop
> graphics drivers examples:
> Intel (i915) - only has FOSS userspace driver - OK
> AMD (amdgpu) - has FOSS userspace driver and closed source driver - OK
> NVIDIA (nouveau) - only has FOSS userspace driver - OK
> NVIDIA (nvidia) - only has closed source userspace driver - NOT OK

Well that sounds like our case...

> AFAIK all non-kernel code for SGX is closed source,

Yes. Unless IMG changes their mind if we come up with a good kernel
upstream driver... So it might be some hen&egg situation.

> so there is some
> work to do before this can be upstreamed. Also graphics people (like
> all subsystem maintainers) don't like pointless driver specific
> abstraction layers. But AFAIK they do accept code with some abstractions
> left as long as there are people working on removing them. On the
> other hand writing an open source userspace implementation requires
> understanding the kernel code anyways and cleaning up the mess is the
> best way to understand vendor drivers :)

Well, the question is what level of functionality the FOSS userspace
driver must have. Tony is recommending 2D support which seems to be
an interesting intermediate goal.

Or alternatively we have to dig into reverse engineering (which I
wanted to avoid if possible) and at least rewrite the use-space lib
that directly interfaces with the kernel. I think it is called
lib/libsrv_um.so. Should be easy to be identified by ldd gles1test1.


More information about the openpvrsgx-devgroup mailing list