Comment 1 by Nikolaus Schaller, Jul 25, 2013

Kernel 3.10 did change the procfs API. Some references, examples and 
material:

https://lwn.net/Articles/557009/
http://lkml.indiana.edu/hypermail/linux/kernel/1305.1/02390.html
http://communities.vmware.com/thread/446113?start=0&tstart=0
http://stackoverflow.com/questions/17770678/read-proc-t-and-file-oper
ations-in-procfs/17771665#17771665

e.g.

-   ent = create_proc_entry(name, mode, parent);
+   ent = proc_create_data(name, mode, base, fops, data);

-      remove_proc_entry(node->name, parent);
+		proc_remove(node);

Another change is the lack of read_proc_t being replaced by file 
operations.

Here is a description of the old API (as used by the PVR/SGX drivers 
we have access to and which is working with the 3.7 kernel):

http://www.compsoc.man.ac.uk/~moz/kernelnewbies/documents/kdoc/2.5/pr
ocfs-guide.pdf

Comment 2 by Nikolaus Schaller, Jul 28, 2013

Comment 3 by Nikolaus Schaller, Jul 28, 2013

We also need to adapt the macros to detect the CPU variant:

cpu_is_omap3530() has changed
#include <plat/cpu.h> missing

Needs to be adapted to the latest Kernel API.

Comment 4 by Nikolaus Schaller, Aug 1, 2013

The best sequence appears to be
1. upgrade to latest version (so that "official" 3.7/3.8 
fixes are included)
2. fix /proc intertface

Comment 5 by Nikolaus Schaller, Aug 5, 2013

There is again an upgrade available:
gfxsdk 4_10_00_01 Build date: 07162013

Comment 6 by Nikolaus Schaller, Aug 8, 2013

Upgrade to 4_10_00_01 is done.

Added some fixes, but linux/proc.c needs rework for the new /proc 
API.

See: 
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/
wip-gpupvrsgx

Comment 7 by Nikolaus Schaller, Aug 11, 2013

The new /proc API appears to work (at least basically).
It was necessesary to fix an issue with SysInit() not being called 
for the omaplfb component and another with clk_prepare() not being 
called.

See: 
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/

wip-gpupvrsgx

With these fixes the kernel boots.
But initialization of the SGX system still fails.

Comment 8 by Nikolaus Schaller, Aug 11, 2013

Correct link:

http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/
wip-gpupvrsgx

Comment 9 by Nikolaus Schaller, Aug 11, 2013

Major lacking functions:
* /proc driver is not completely tested
* unclear if the patches for SysInit and clk_prepare are correct and 
at the right place
* there is no suspend management (or is it?) and the SGX may be in 
operation even during suspend
* pvrsrvinit reports error

Comment 10 by Nikolaus Schaller, Nov 20, 2013

The new TI SDK appears to be available:

http://tigraphics.blogspot.in/2013/11/4q-2013-linux-graphics-sdk-rele
ase.html

Comment 11 by Nikolaus Schaller, Nov 20, 2013

Ok, extracting and patching our tree worked fine.

First issue: the driver apparently assumes that this patch:

https://lkml.org/lkml/2013/9/2/279

is applied to the kernel or we get a compile error:

drivers/gpu/pvr/omap3/services4/srvkm/env/linux/module.c:402:2: 
error: implicit declaration of function 'reset_control_clear_reset'

Comment 12 by Nikolaus Schaller, Dec 10, 2013

Unfortunately this 'reset_control_clear_reset' is also not yet 
available in 3.13-rc3.

So we have to wait for an update of the graphics sdk.

Comment 13 by Nikolaus Schaller, Dec 11, 2013

For a honest description: they say that the RESET framework is 
required:

http://processors.wiki.ti.com/index.php/RN_5_00_00_01_alpha#Kernel.28
Linux_PSP.29_versions_supported_or_used_for_validation

So we should try to add that to our kernel.

Comment 14 by Nikolaus Schaller, Feb 9, 2014

A non-alpha release for 3.12 appears to be available:

http://processors.wiki.ti.com/index.php/RN_5_01_00_01

Comment 15 by Nikolaus Schaller, Apr 19, 2014

Latest gfxsdk release (Feb 2014):

http://software-dl.ti.com/dsps/dsps_public_sw/gfxsdk/5_01_01_01/index
_FDS.html

Comment 16 by Nikolaus Schaller, Jun 1, 2015

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gf
xsdk/latest/index_FDS.html

shows aslatest version

gfxsdk 5_01_01_02 Product Download Page
Build date: 01292015

According to release notes
http://processors.wiki.ti.com/index.php/RN_5_01_01_02

it has 3.14 kernel support

Comment 17 by Nikolaus Schaller, Jun 1, 2015

For an overview of all release notes try:

http://processors.wiki.ti.com/index.php?title=Special%3AAllPages&
from=RN+&to=RO&namespace=0

Comment 18 by Nikolaus Schaller, Jun 2, 2015

Here is a branch that compiles 5_01_01_02 within 4.1-rc6:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/
work/hns/gpu/pvr

Issues
* I had to disable some calls to reset_control_clear_reset - with 
unknown side-effects
* we must still configure CONFIG_SGX530=y - compiling as module 
fails for a lot of undefined external symbols
* it compiles fine with CONFIG-DRM=y

Comment 19 by Nikolaus Schaller, Nov 26, 2015

It appears that we can simply 

sed s/reset_control_is_reset/reset_control_status/ 
drivers/gpu/pvr/omap3/services4/srvkm/env/linux/module.c

to fix the reset status check.

What I don't know yet is how to replace the call to 
reset_control_clear_reset(). Maybe simply reset_control_deassert()?

But we still have the problem that the OMAP2+ reset controller 
submitted by Sept 2015 
https://progressive-comp.com/?l=linux-omap&r=3&w=1&b=2015
09 is not accepted on linuxomap or linux-next yet.

Comment 20 by Marek Belisko, Dec 2, 2015

Can we take patches for reset controller on linux-next (as separate 
feature branch) and use prv drivers on top of that to have graphic 
acceleration working?

Comment 21 by Marek Belisko, Dec 2, 2015

Can we take patches for reset controller on linux-next (as separate 
feature branch) and use prv drivers on top of that to have graphic 
acceleration working?

Comment 22 by Nikolaus Schaller, Dec 2, 2015

I think not yet. The reset controller (in linux-next) does not yet 
support OMAP3 AFAIK. This is what the Sept 2015 patch on LKML tried 
to get in but it isn't yet.

Comment 23 by Marek Belisko, Dec 2, 2015

Sorry linux-next was typo. I mean overtake existing patches and use 
them in our letux-next tree.

Comment 24 by Nikolaus Schaller, Dec 2, 2015

Ah, now I get the idea.

We simply take the September 2015 patches from LKML into a 
work/marek/drivers/reset feature branch.

And merge this with the PVR/SGX and fix until it works.

Looks like an interesting idea.

One thing we still have to solve is that reset_control_clear_reset() 
is AFAIK not part of any API (except the TI kernel fork).

So we should look there what it is really doing.  

I remember a note that it can be "simulated" by other 
calls but there might be a timing issue.

Comment 25 by Nikolaus Schaller, Oct 29, 2016

With the latest patches to Makefile we get it compiled - except the 
missing
or not working pieces for the reset_control:

drivers/gpu/pvr/omap3//services4/srvkm/env/linux/module.c:	rstc = 
reset_control_get(&pDevice->dev, NULL);
drivers/gpu/pvr/omap3//services4/srvkm/env/linux/module.c:	ret = 
reset_control_clear_reset(rstc);
drivers/gpu/pvr/omap3//services4/srvkm/env/linux/module.c:	ret = 
reset_control_deassert(rstc);
drivers/gpu/pvr/omap3//services4/srvkm/env/linux/module.c:           
     ret = reset_control_is_reset(rstc);
drivers/gpu/pvr/omap3//services4/srvkm/env/linux/module.c:        
reset_control_put(rstc);

Of these the following are defined:

 10 int reset_control_reset(struct reset_control *rstc);
 11 int reset_control_assert(struct reset_control *rstc);
 12 int reset_control_deassert(struct reset_control *rstc);
 13 int reset_control_status(struct reset_control *rstc);
 17 void reset_control_put(struct reset_control *rstc);

Unfortunately, the omap2+ reset controller patches from Sept 2015 
did not
appear in linux-next yet (see comment 19 <
http://projects.goldelico.com/p/gta04-kernel/issues/449/#ic2216>).

Comment 26 by Nikolaus Schaller, Nov 13, 2016

Interestinly there is a similar approach for n900:

https://github.com/pali/linux-n900/tree/v4.6-rc1-n900/drivers/gpu/pvr


No idea if this is the same version of the PVR.

Comment 27 by Nikolaus Schaller, Feb 16, 2019

Code is working almost since 4.15. What we lack is backend 
integration (framebuffer).
Neither omaplfb nor DRM compile well. So we can load the kernel 
module, download and start the microkernel/firmware, but 
clipblittest complains about not finding a proper display-class.

Comment 28 by Nikolaus Schaller, Nov 23, 2019

We finally have DDK1.14 kernel and user-space running on
* DM3730 (GTA04, OpenPandora 1GHz)
* AM335x (BeagleBone)
* OMAP5 (Pyra)

Interesting to solve will be:
* OMAP3530 (OpenPandora 600MHz)
* OMAP4 (Pandaboard ES)
* upgrade to DDK1.17

Comment 29 by Nikolaus Schaller, Apr 10, 2020

In the meantime we have DDK 1.17 kernel modules for
* omap3530 (Pandora 600MHz)
* dm3730 (GTA04, Pandora 1GHz)
* omap5 (Pyra)
* jz4780 (CI20)
* am335x (BeagleBone) - doesn't work properly

Comment 30 by Nikolaus Schaller, Apr 10, 2020

So we should
* fix am335x
* upstream the sgx glue bindings.yaml and DTS fixes
* try to qemu-arm-static pvrsrvctl on jz4780