[Openpvrsgx-devgroup] Status & HW to bring
sre at kernel.org
Wed Nov 13 01:50:19 CET 2019
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. Greg with his staging maintainer
hat agreed on not merging graphics drivers via staging.
It was most likely mentioned in this talk:
> > > See also the docs for "DRM Open-Source Userspace Requirements":
> > >
> > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html
> > >
> > > AFAIK the pvr-drv driver needs to go directly to drivers/gpu/drm/pvr
> > > instead.
> > Well, moving the code around is not a big deal :)
> > "staging" is more a placeholder to get it into mainline in any shape that
> > is acceptable so that we get more visibility and can use the kernel.org
> > infrastructure which will be critical for project growth.
> Yeah sure I have no issues with that naturally :) I just wanted
> to point the drm vs staging issue out so it does not come as a
> surprise later on.
> > > Sebastian, care to clarify what you have picked up on this
> > > recently?
> > >
> > > Basically what I understand is that at this point we just need
> > > to make the current drivers/staging/pvr/pvr-drv.[ch] and related
> > > rewritten components into a standalone 2d accelerated driver for
> > > drivers/gpu/drm/pvr :)
> > I am open to anything, as long as it works :)
> > BTW: I am preparing to separate our work into even more patch sets
> > (feature branches) but which should have a better logical structure:
> > letux/omap-sysc-prm-gfx - all lowest level gear almost arrived in linux-next
> > letux/omap-pvr-soc-glue - bindings and DTS additions for gpu in SOC
> > letux/staging-pvr - this is where Kconfig, umbrella Makefile and your new pvr-drv resides
> > and where clean code should appear
> > letux/pvrsrvkm-1.9 - old omap3+4 DDK (most likely not DRM)
> > letux/pvrsrvkm-1.10 - some DDK which was said to support omap4+omap5 (most likely not DRM)
> > letux/pvrsrvkm-1.14 - DDK we are working on - for am335x and dra7 (user-space can be patched to omap5)
> > letux/pvrsrvkm-1.17 - DDK version may support am3352, am4376, dra7, am654
> > letux/pvr-demo - user-space scripts for debugging and gpu-demo
> > All this can be merged together with linus/master (well, all branches are rebased on it)
> > to give the complete letux-pvr branch.
> > The first two patch sets will become empty over time and can be omitted as soon as
> > all these things are upstream.
> > There is room for adding more patch sets, e.g. the Ingenic DDK1.14 variant or the
> > TI 1.15 I have found. And I have recently seen some Poulsbo project variant on github.
> > 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
AFAIK all non-kernel code for SGX is closed source, 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 :)
More information about the openpvrsgx-devgroup