lkml.org 
[lkml]   [2019]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* H. Nikolaus Schaller <hns@goldelico.com> [191014 09:12]:
>
> > Am 12.10.2019 um 15:09 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> > Hi,
> >
> >> Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> > I have found the following description, followed all steps, and it works:
> >
> > http://blog.0xpebbles.org/PowerVR-SGX-on-the-beaglebone-black-in-2019
> >
> > So with this, I have got a working user-space setup for BeagleBone and some working
> > pvrsrvkm.ko module (kernel 4.4.155-ti-r155) for evaluation.
>
> > What I don't have yet is the full source code or build recipe for the specific
> > 4.4.155-ti-r155 pvrsrvkm.ko from TI.
> >
> > But even without having this yet, I can start experiments by replacing
> > kernel and pvrsrvkm.ko with mine. This should allow to gain new insights.
>
> Good news:
>
> after making a Hybrid SD image of the setup described above and replacing the
> 4.4.155-ti-r155 kernel with its pvrsrvkm.ko by my own 5.4-rc2 kernel and pvrsrvkm,
> I was able to start the pvrsrv uKernel. And run the gles1test1 on beaglebone
> (without LCD but also without errors).
>
> With this knowledge I could adapt my user-space. There are indeed different
> non-free binaries for sgx530, sgx540, sgx544. And SGX needs enough coherent memory.
> So I could make a completely self-built kernel and rootfs (using the git clone from
> ti for the firmware + make install) run on BeagleBone.
>
> Here is a quickly taken video:
>
> https://youtu.be/jFCPR_EvtjY

Nice :)

> With the same setup, I can now also load the kernel driver and run pvrsrvctl on
> DM3730 without errors, but the gles1test1 reports some error and fails to run.
> Maybe something in the video subsystem or memory mapping is still wrong.
>
> Unfortunately, the same setup does not run on omap5. It looks like there are different
> releases for the non-free binaries and I have to pick the right one.
>
> On BBB the version I could make running is branch ti-img-sgx/1.14.3699939_k4.4 from
> git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git. Target ti335x works while
> target jacinto6evm fails for OMAP5. A diff on the binaries for e.g. pvrsrvctl shows
> that they are different.
>
> If you want to repeat this setup and my instructions are too imprecise, please
> ask.
>
> So in summary this means:
> * the common foundation (clock, reset, power etc.) setup is working - thanks to Tero, Tony and others
> * I have added device tree nodes for each SoC type to define sgx registers, interrupts, compatible etc.
> * compiling SoC specific kernel module variants from single source tree works
> * the work can already be demoed on BBB and OMAP5 Pyra (using different user-space binaries)
>
> Basically I am now ready to post an RFC for the sgx child device nodes together
> with a bindings document [1]. But I am not sure if I should better wait until
> really all underlaying prm+rtsctl+syscon+idlest-polling patches by Tero and Tony [2]
> have matured in linux-next and have arrived in v5.5-rc1. Would be short before Xmas.

I think you've already proven that we can have a generic binding for the
sgx using standard properties :) So AFAIK, there's nothing stopping you
from posting the binding and dts changes for review for v5.5.

> Independent of low level patches, we all have to discuss how we want to get the GPLed
> kernel driver [3] into mainline drivers/staging. This likely needs more cleanup before
> it can be proposed.

You probably need a shell script using sed or something to get rid of the
crazy directory path for the kernel driver :) Just make it something like:

drivers/staging/pvr

Then if you have a script doing the directory path conversion, you can
still convert and diff against any other prv branches you may find.

And you can get rid of all the LINUX_VERSION_CODE stuff too for the
mainline kernel.

Regards,

Tony


> [1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue-v5
> [2]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-sysc-prm-gfx
> [3]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/latest-pvr
>

\
 
 \ /
  Last update: 2019-10-17 01:04    [W:0.062 / U:5.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site