Letux Kernel

Issue 449: PVR/SGX DDK 1.17 issues

Reported by Nikolaus Schaller, Jul 2, 2013

latest version is Graphics_SDK_setuplinux_4_09_00_01.bin (14 May 


Main change appears to be Linux 3.8 compatibility so that we don't 
need some patches to make it compile on 3.7 (which may be wrong).

Comment 1 by Nikolaus Schaller, Jul 25, 2013

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



-   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 

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):

Summary: Upgrade PVR/SGX package to latest version - and fix /procfs issues in Kernel 3.10+

Comment 2 by Nikolaus Schaller, Jul 28, 2013

Labels: Milestone:3.10

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
Owner: hns

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 


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 



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

Comment 8 by Nikolaus Schaller, Aug 11, 2013

Correct link:


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:


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:


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

error: implicit declaration of function 'reset_control_clear_reset'
Labels: Milestone:3.12 Milestone:3.10

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 


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:


Comment 15 by Nikolaus Schaller, Apr 19, 2014

Latest gfxsdk release (Feb 2014):


Comment 16 by Nikolaus Schaller, Jun 1, 2015


shows aslatest version

gfxsdk 5_01_01_02 Product Download Page
Build date: 01292015

According to release notes

it has 3.14 kernel support

Comment 17 by Nikolaus Schaller, Jun 1, 2015

For an overview of all release notes try:


Comment 18 by Nikolaus Schaller, Jun 2, 2015

Here is a branch that compiles 5_01_01_02 within 4.1-rc6:

* 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/ 

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 
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 
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 = 
drivers/gpu/pvr/omap3//services4/srvkm/env/linux/module.c:	ret = 
     ret = reset_control_is_reset(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 <

Comment 26 by Nikolaus Schaller, Nov 13, 2016

Interestinly there is a similar approach for n900:


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.
Relations: is related to 907

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
Labels: Milestone:5.6 Milestone:3.12

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
Labels: Milestone:5.7 Milestone:5.6

Comment 31 by Nikolaus Schaller, Apr 10, 2020

Summary: PVR/SGX DDK 1.17 issues

Created: 10 years 11 months ago by Nikolaus Schaller

Updated: 4 years 2 months ago

Status: New

Owner: Nikolaus Schaller

Followed by: 1 person


This issue is related to
475 - PVR/SGX: enable DRM support
907 - PVR...tely working for a while