Hi Pawel,

> Am 13.02.2019 um 08:36 schrieb Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>:
>
>> śr., 13 lut 2019 o 08:25 H. Nikolaus Schaller <hns@goldelico.com> napisał(a):
>> Hi Pawel,
>>
>>> Am 13.02.2019 um 08:14 schrieb Paweł Chmiel <pawel.mikolaj.chmiel@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.
> I'm also using something similar to omaplfb (on my soc it is s3c_lcd code - https://github.com/PabloPL/linux/tree/powervr/drivers/gpu/drm/powervr/s3c_lcd - it's dirrectly writing to framebuffer) and i'm able to pass after this.
> I wanted to get running something which was working on old kernel (rather than trying to take driver from omap/etc and add support for my soc there) and then see how it works etc.
> Do You have strace of pvrsrvinit run ? They should be almost identical to one which i have.

Yes, I can make a test setup (I still have to check on which kernel versions it works since I am not sure if 5.0-rc is broken or not) and run an strace in the next days.

> We could also write something like it was done for lima (https://github.com/limadriver/lima/tree/master/wrap or https://github.com/yuq/mali-syscall-tracker), to capture ioctl and dump content of it.
> But first it would be nice to have some sample codes (there was some from img with their sdk for ti. need to search for it), which we could run and then compare logs.
>> 
>>> 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.
>>
>> 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/pvr, because it would be eliminate the need to rebase every week...
>>
>> But what would be other options?
> Is DDK 1.14 for omap5 the same like for omap4 ? I have some copy of https://github.com/rcn-ee/ti-omap5-sgx-ddk-linux which i've fixed to build under 4.20 (should be also easy to build it under 5.0).

In my understanding DDK 1.14 is not only for omap4 or 5 but supports a collection of devices (and a long list of SGX variants).
See

http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1.14.3699939/eurasia_km/services4/system

There one finds
* cedarview (some Intel Atom)
* omap (probably means am335x/omap3/4/5)
* poulsbo
* jz4780
* pc_i686_tc3
* sunxi

And the list of supported SGX variants is inside this file:

http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=drivers/staging/pvr/1.14.3699939/eurasia_km/services4/srvkm/hwdefs/sgxerrata.h

So this tree appears to be already very broad and easy to modify to serve everybody.

BTW: I found that Android kernels usually use a reduced and flattened sgx source tree compared to the DDK trees.

BR,
Nikolaus



>
> BR,
> Nikolaus
>
>
>>
>> śr., 13 lut 2019 o 07:36 H. Nikolaus Schaller <hns@goldelico.com> napisał(a):
>> Hi Tony,
>>
>> > Am 13.02.2019 um 01:41 schrieb Tony Lindgren <tony@atomide.com>:
>> >
>> > Hi,
>> >
>> > * Philipp Rossak <embed3d@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
>>
>