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

H. Nikolaus Schaller hns at goldelico.com
Sat Oct 5 18:58:24 CEST 2019


Hi all,
with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived
upstream, so we do no longer need them here.

Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some
more issues:
* omap4 build only needs to distinguish between omap4420/30/60 and omap4470,
  because the latter has an sgx544 inside and the other sgx540
  This is solved by creating a new omap4470.dts
* I have added proper reg values and interrupts to the omap4 device
  tree node of the sgx (child node of the target-module)
* some updates to my sgxdump and sgxdemo scripts (assuming simple
  Debian Stretch rootfs)
* James Hilliard has contributed a fix for osfunc.c
* omap2plus also needs to be configured for STAGING and PREEMPT
  to be able to compile the driver
* I have added the __always_inline fix [2] which is needed for v5.4 with
  CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which I are enabled on the Letux builds)

Unfortunately Tero's rstctrl patches did not yet make it upstream (or even
linux-next) so I also have a copy in this branch.

Results of first testing are:
* OMAP3530 (OpenPandora, BeagleBoard C): fails with
[  559.247558] PVR_K:(Error): SysLocateDevices: platform_get_resource failed

* DM3730 (GTA04, BeagleBoard XM): kernel module loads

* OMAP4460 (Pandaboard ES): kernel module loads

* AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert:
[  204.246706] omap_reset_deassert: timedout waiting for gfx:0

* OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[  304.140363] clock-controller:clk:0000:0: failed to enable
[  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)

* OMAP5 with omap2plus_defconfig:
root at letux:~# echo on > $(find /sys -name control | grep \/5600)
[  213.490926] clock-controller:clk:0000:0: failed to enable
root at letux:~# 

* pvrsrvctl --start --no-module:
  reports (where the kernel module loads) that the uKernel does not run

So I have several ideas what the reasons for the problems on the non-omap5
devices could be:
* initial code may have some omap5 specific hack inside
* or has omap5 specific magic constants
* uKernel may "know" on which platform it runs and
  we would need differently patched user-space code
  for each one
* omap5 has a dual core sgx544 while the other
  have single core
* the register address translation is not yet correct and
  this inhibits communicating of the user-space libs
  with the uKernel

Maybe, if someone can point me to a complete and working BeagleBone source
tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare
code and address setup to find what makes the difference.

BR and thanks,
Nikolaus

[1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux-pvr
[2]: https://lkml.org/lkml/2019/10/2/201



More information about the Letux-kernel mailing list