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

[Philipp Rossak]

On 13.02.19 08:25, H. Nikolaus Schaller wrote:
> Hi Pawel,
> 
>> Am 13.02.2019 um 08:14 schrieb Paweł Chmiel 
>> <pawel.mikolaj.chmiel at gmail.com <mailto:pawel.mikolaj.chmiel at gmail.com>>:
>>
>> Hi all, thanks for adding my to this topic.
>> I'm using Power SGX540 on my Samsung s5pv210 based device (Samsung 
>> Galaxy S - i9000 phone - i've added support for it to mainline).
> 
> Great!
> 
>> Do anyone has it (sgx540) working on mainline (5.0) kernel? Currently 
>> i've forward ported old driver, written by google 
>> (https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb-mr0/drivers/gpu/pvr)
>> to 5.0 kernel.
> 
> Unfortunately no. I have not invested time into SGX540 (although there 
> is code in my tree). Iworked on omap3/amm335x.
> 
>> I'm able to to gpu init (run pvrsrvinit), but when trying to run some 
>> sample code i'm getting 0 available egl configurations. I think i've 
>> fixed problems with framebuffer setup (by making framebuffer big like 
>> it was on old kernel - so it will allocate one framebuffer and 2 
>> backbuffers in my case).
> 
> Yes, that is almost the same state as I have for omap3. I can run 
> pvrsrvinit but it does not find framebuffers. Because it tries to use 
> omaplfb which is not DRM compatible. So I would have to rewrite that first.
> 
>> After enabling debug code in driver i'm currently getting followin logs
>> https://gist.github.com/PabloPL/c1e98f405e67d577afcf51c36228efdc (BTW 
>> it's android binaries running on ubuntu on that s5pv210 device).
> 
> So it turns out that we have several initiatives by individuals that did 
> start at different versions of the DDK&Linux-Glue and adjusted it to 
> different SGX versions and some specific SoCs.
> 
> What I would propose then is that we check if the DDK 1.14 is really the 
> latest existing one, install it in some common git repo and have us all 
> work on this
> common basis to redo the integration we have done on our individual trees.
> 
Just can agree on this. Let's use the latest available driver.

> And someone rebases this DDK every week to the latest linus/master. This 
> also reveals API changes we need to track in the glue code.
> 
> So we definitively need some common git to synchronize efforts. My 
> proposal would still be kernel.org/drivers/staging 
> <http://kernel.org/drivers/staging>/pvr, because it would be eliminate 
> the need to rebase every week...
> 
I would not do a weekly rebase. I think after -rc1 or after a stable 
relase would be better.

> But what would be other options?
> 
> BR,
> Nikolaus
> 
> 
>>
>> śr., 13 lut 2019 o 07:36 H. Nikolaus Schaller <hns at goldelico.com 
>> <mailto:hns at goldelico.com>> napisał(a):
>>
>>     Hi Tony,
>>
>>     > Am 13.02.2019 um 01:41 schrieb Tony Lindgren <tony at atomide.com
>>     <mailto:tony at atomide.com>>:
>>     >
>>     > Hi,
>>     >
>>     > * Philipp Rossak <embed3d at gmail.com <mailto:embed3d at gmail.com>>
>>     [190212 22:25]:
>>     >> I'm looking now into that PVR SGX driver since a while. I
>>     already reworked
>>     >> that old "opensource" driver to work with a quite new kernel
>>     (4.16 or 4.17)
>>     >> [But that code got lost].
>>     >> For the sunxi devices this was only a short coding session to
>>     get that
>>     >> running. For OMAP this might be easier/faster since the general
>>     linux
>>     >> situation is better.
>>     >
>>     > So a git repo that works for omaps and sunxi would be a good
>>     > start then :)
>>     >
>>     >> I'm not sure if we are able to provide a generic driver since
>>     there are
>>     >> different userspace versions that are only compatible with
>>     their own kernel
>>     >> driver. Not all compile flags for the kernel driver work with
>>     all userspace
>>     >> lib versions, at least on sunxi. Be aware that there are also
>>     different
>>     >> versions of those GPU ip cores and all have different features
>>     and bug
>>     >> fixes.
>>     >
>>     > No doubt it's a mess.. I'm only suggesting a generic driver that
>>     > manages standard Linux resources like regulators, clocks and
>>     > interrupts and provides 2d acceleration for sgx540 based on what
>>     > we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea
>>     > being that it might then also make dealing with the rest of the
>>     > sgx blobs a bit easier hopefully.
>>
>>     Well, ok.
>>
>>     So you suggest that we e.g. take the omap SoC support in
>>
>>     http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1.14.3699939/eurasia_km/services4/system/omap;h=09ff9c9112dd7e8f7316ba5f1e022dcb824c2ce4;hb=1d5b6a91eca80168c37ecb66157e675d28666652
>>
>>     and make an "eurasia_km / services4 / system / generic" out of
>>     it using the 2d functions?
>>
>>     Please take a look into especially sysconfig.c and SysInitialise()
>>     which does the lion's share of initialization if it can be rewritten
>>     to become generic.
>>
>>     >
>>     >> If you reach a good state with that driver, I can try to port
>>     that to sunxi.
>>     >> Is there any good/cheap OMAP4/5 Devboard you can recommend?
>>     >
>>     > Hmm so the n900 folks have the sgx blobs working with recent
>>     > mainline kernels for sgx530 I believe, and Nikolaus is close to
>>     > having the sgx blobs working for sgx540.
>>
>>     Also for sgx530 with recent kernel. The blobs itself are working, it
>>     is just missing code to tell the SGX module where the framebuffer
>>     is located in virtual memory.
>>
>> I think setting
>> CONFIG_DRM_FBDEV_OVERALLOC=700
>> in my case (like old kernel) this will make powervr driver allocate 
>> one framebuffer + 2 backbuffers
>> and
>> CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM
>> it should make it working. On my device i had to use different "fix"
>> https://github.com/PabloPL/linux/commit/d0b1df4067a724aa0b38d11c82fd3ff0958a45a6
>> The physical address of fb is used in driver (and passed to 
>> userspace?). It's code is here for my device
>> https://github.com/PabloPL/linux/blob/powervr/drivers/gpu/drm/powervr/s3c_lcd/s3c_displayclass.c#L943
>> And here is simple devicetree entry which is read by driver (it was 
>> added by person which is also working on mainlining my device).
>> https://github.com/PabloPL/linux/blob/powervr/arch/arm/boot/dts/s5pv210-aries.dtsi#L325
>>
>> But this still didn't allowed me to run egl code with that driver. 
>> Probably i'll need to get logs from old kernel.
>>
>> All my code is currently (if someone is interested ) in 
>> https://github.com/PabloPL/linux/tree/powervr
>>
>>
>>     > I may not be aware of
>>     > the current status though.
>>     >
>>     > For a devboard with sgx540, you should be able to find one for
>>     > few tens of units for a used pandaboard-es for example or
>>     > somebody here might even have an old one to donate. If you feel
>>     > like playing with a phone, droid 4 xt894 is somewhat usable
>>     > with mainline kernels with pending patches for LCD and modem,
>>     > no idea what the sgx540 status on it might be. Pyra handheld
>>     > is not yet available except for prototypes. And then on
>>     > beagleboard-x15 there's sgx544, and beaglebone has sgx530
>>     > FYI so that might not help if you need sgx540.
>>     >
>>     >> Don't expect any support from TI or IMG. TI can't support a
>>     project like
>>     >> this, since they don't own the code and IMG is not willing to
>>     support.
>>     >
>>     > Yeah that we've seen already over past 10 or so years :)
>>
>>     >
>>     >> An other big issue is the leaked SGX source code [1]. So I
>>     think it would be
>>     >> better to start a clean room reverse engineering project. I'm
>>     already
>>     >> working on that.
>>     >
>>     > OK so we're discussing at least three projects then:
>>     >
>>     > 1. A git repo that allows sgx blobs to work for various
>>     >   SoCs with current mainline kernels
>>
>>     Yes.
>>
>>     >
>>     > 2. A generic 2d sgx540 driver based on existing mainline
>>     >   kernel drivers/gpu/drm/gma500/accel_2d.c
>>
>>     May be needed or not.
>>
>>     >
>>     > 3. Your reverse engineering project that might help
>>     >   with figuring out how things are supposed to work
>>
>>     IMHO a completely separate project.
>>
>>     Basically there is a strict layering:
>>
>>     L4      user-space libraries
>>     L3      SGX firmware
>>     L2      SGX firmware loader
>>     L1      SoC glue (clock, reset, dma, virtual memory, ...)
>>
>>     I am mainly considering L1 here and fixing L2. L1 is SoC
>>     specific of course and L2 needs Linux-release specific patches.
>>
>>     L2-L4 depend on SGX version.
>>
>>     L2 contains a lot of #ifdef that depend on SGX530/540/544 and even
>>     more.
>>
>>     Reverse engineering addresses L3 and L4.
>>
>>     Of course if will be is successful it might become possible to improve
>>     the whole L1-L4 stack, but that is another 10 years in the future :)
>>
>>     Since it is such a big task, I would propose to start with something
>>     close to working (some TI/IMG DDK) and improve on that instead of
>>     starting with parts from scratch.
>>
>>     BR,
>>     Nikolaus
>>
>