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

Belisko Marek marek.belisko at gmail.com
Thu Aug 8 23:08:21 CEST 2013

Hi Nikolaus,

On Thu, Aug 8, 2013 at 6:39 PM, Dr. H. Nikolaus Schaller
<hns at goldelico.com> wrote:
> 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.
Just quick look to other code and compare it before [1] and after [2]
/proc changes gives me function:
remove_proc_subtree() which should do the job by walking tree.
> 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
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
> http://lists.goldelico.com/mailman/listinfo/gta04-owner

[1] : http://lxr.linux.no/linux+v3.9.11/drivers/net/wireless/airo.c#L4500
[2] : http://lxr.linux.no/linux+v3.10.5/drivers/net/wireless/airo.c#L4500


as simple and primitive as possible
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

More information about the Gta04-owner mailing list