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

[Paweł Chmiel]

Do we have:
- mailing list (now getting email that moderator needs to review each my
reply)?
- common repo (github/gitlab )? - more popular, so it should be much easier
to collaborate for anyone

śr., 13 lut 2019 o 08:56 H. Nikolaus Schaller <hns at goldelico.com>
napisał(a):

> Hi Pawel,
>
> > Am 13.02.2019 um 08:36 schrieb Paweł Chmiel <
> pawel.mikolaj.chmiel at gmail.com>:
> >
> >> śr., 13 lut 2019 o 08:25 H. Nikolaus Schaller <hns at goldelico.com>
> napisał(a):
> >> Hi Pawel,
> >>
> >>> Am 13.02.2019 um 08:14 schrieb Paweł Chmiel <
> 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.
> > 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 at goldelico.com>
> napisał(a):
> >> Hi Tony,
> >>
> >> > Am 13.02.2019 um 01:41 schrieb Tony Lindgren <tony at atomide.com>:
> >> >
> >> > Hi,
> >> >
> >> > * Philipp Rossak <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
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20190213/6714172d/attachment-0001.html>