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

Belisko Marek marek.belisko at gmail.com
Thu Aug 8 22:43:17 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.
I'll look at [1] and seems it's using what we probably need:
kmalloced data are passed in proc_create_data and that data can be
retrieved by PDE_DATA(inode) which is available.
>
> 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
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
> http://lists.goldelico.com/mailman/listinfo/gta04-owner

[1] - drivers/gpu/drm/drm_proc.c

BR,

marek
-- 
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