[Gta04-owner] New Graphics SDK (was: Latest neil-plus kernel status)

[Dr. H. Nikolaus Schaller]

Am 08.08.2013 um 14:30 schrieb Dr. H. Nikolaus Schaller:

> 
> Am 04.08.2013 um 15:09 schrieb Josua Mayer:
> 
>> Am 30.07.2013 21:30, schrieb Dr. H. Nikolaus Schaller:
>>> Hi all,
>>> I have done some more fixes and updates:
>>> 
>>> * reboot is now working
>>> * workaround for framebuffer alloc problem
>>> * upgraded to 3.11-rc3
>>> * added patch from Replicant to fix touch screen issues (not tested on Replicant yet - but appears to work elsewhere)
>>> * PVR is still disabled (needs more work to make /proc working) [1]
>> I have found that there is a new graphicssdk by TI at:
>> http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html
>> It is done for linux 3.8 so maybe it has better chances of working fully(that is with DRI) in the future.
>> Just wanted to throw this in since I found the code in neil-3.1x-plus still has the driver code of the old SDK.
> 
> I did take another look into the code and it turns out that integrating the latest SDK into a 3.10++
> kernel is more than fixing make files and #include paths.
> 
> The main change is from 3.9 to 3.10 that the /proc API has changed at two fundamental positions:
> 1. the struct proc_dir_entry has become private
> 2. there are no longer read_proc and write_procs defined by the driver
> 
> Since there is some code that uses direct access to struct proc_dir_entry this means some
> changes - which can be done, but we risk introducing severe bugs we can't debug.
> 
> The second point appears to be worse - the linux adaptation code is based around these
> and they are replaced by the standard file_operations for read and write. This means that
> the way strings and data is passed from the driver to user space has changed.
> 
> And, a read/write proc callback assumes that it gets access to the data passed on creation
> of the node. I don't see how this is done by the standard file_operations:
> 
> int (read_proc_t)(char *page, char **start, off_t off, int count, int *eof, void *data);
> 
> ->
> 
> ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
> 
> Reading from some comments in the drivers/gpu/pvr/omap3/services4/srvkm/env/linux/proc.c
> it also looks as if they use some special properties of the old procfs API (e.g. how EOF is notified).
> 
> So this is a major change and I don't see how I can do it with my limited experience faster
> than TI will fix it.
> 
> So maybe it is better to wait for the next one or two releases of the gfx sdk. If TI keeps pace,
> I would expect that for November 2013.
> 
> Can we wait that long? Or does anbody know about a "migration guide" for the /procfs API?
> Or anybody willing to look into the details of drivers/gpu/pvr/omap3/services4/srvkm/env/linux/proc.c?

I have some good news after investing 3 more hours...

Adding a lot of

	#if (LINUX_VERSION_CODE > KERNEL_VERSION(3,10,0))

to

	drivers/gpu/pvr/omap3/services4/srvkm/env/linux/proc.c and ../proc.h

makes the whole kernel compile with only some warnings in linux/proc.c and two harmless
ones in

	drivers/gpu/pvr/omap3/services4/3rdparty/dc_omapfb3_linux/omaplfb_displayclass.c

So the situation is not as worse as I had thought some hours ago.

We only have to fix a single file!

The main problem appears to be that /proc is now handled by normal file_operations
and although it is possible to pass some private data to proc_create_data() I have
not found some official way to access it. The driver uses this private-data mechanism
intensively so we need a way to come from a struct file * to the struct proc_dir_entry *
and from there to the kmalloc'ed data passed initially.

And, I have not found a mechanism to walk through a /proc directory and process all
subnodes in a while loop.

Since the code now compiles, I have pushed it to a WIP (work in progress) branch so
that you can take a look and help:

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

Please note that the code most likely does panic the kernel.

-- hns

[1]: http://projects.goldelico.com/p/gta04-kernel/issues/449