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

Dr. H. Nikolaus Schaller hns at goldelico.com
Thu Aug 8 14:30:39 CEST 2013


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

BR,
Nikolaus





More information about the Gta04-owner mailing list