bug in cmem driver at cache functions

Hi, I have the same problem. CMEM_cacheWb is not working with linux utils 2.25.

I had to install linux utils 2.24.03, and it is working. The changelog for 2.25 says:

"the biggest change is with the ioctl() command IDs - they have changed to incorporate a module-specific "magic" code so as to not conflict with other device driver ioctl() command IDs. This fact means that it is critical that the user update the sub-module user libraries in conjunction with their associated kernel modules, although a mismatch between kernel module and user library will be reported during the module's "init" function (and the "init" will fail)."

But I don't understand what to do with the "sub-module user libraries" ....

Regards,

Guillaume.

Hello Sanahuja,

>> But I don't understand what to do with the "sub-module user libraries" ....

I assume you ask how to fix this... From my point of view you can use codec engine 2.24 and wait till TI releases a working 2.25 codec engine or you patch/edit the 2.25 cmem kernel driver (cmemk.c file). The problem of the 2.25 cmem driver is that the ioctl-function of the kernel module doesn't handle the magic number correctly, so you have to adapt it a bit to make it work in conjunction with the 2.25 user library.

The problem can be found in file cmemk.c: in a switch-case-structure kernel functions like dmac_clean_range() are called. They don't get called because the "case" - condition doesn't match the new magic number, which is passed by the user library. To match it you can use:

case CMEM_IOCCACHEWB | CMEM_IOCMAGIC: ....

case CMEM_IOCCACHEINV | CMEM_IOCMAGIC: ....

case CMEM_IOCCACHEWBINV | CMEM_IOCMAGIC: ....

Alternatively you can edit the switch-instruction and mask the magic number to zero.

Cheers,

Sebastian

I don't think there's a problem with CE or LinuxUtils here.  It appears that your issue is with a mismatch between the CMEM user library and the CMEM kernel module.  Yes, ioctl() command codes have changed (for the better), so you need to link with the CMEM user library from the same release as the kernel driver.

I expect that you would get a version mismatch during CMEM_init(), where the returned kernel module version wouldn't match with the CMEM user library version.  Do you see any warning of this type during your app init?

The answer would appear to be that you need to link your app with the Linux Utils 2.25 CMEM user library if you're insmod'ing the kernel module from 2.25.  There is a CodecEngine 2.25 release out now, and it's best to use that with LinuxUtils 2.25 (and, as we're discovering, might be required).

Regards,

- Rob

FYI, here's a direct link to CE 2.25 [and newer]:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ce/index.html

Chris

Hello TI Engineers,

thanks for your fast reaction. Could you please check the cmem-code of codec engine 2.25.01.06 or 2.25.00.05 to reproduce my description? According to my opinion it cannot work and checking won't take too long ;-). The following things are essential for (theoretical) reproduction:

• the CMEM library function CMEM_cacheWb() passes (CMEM_IOCCACHEWB | CMEM_IOCMAGIC) as ioctl command ( = 0x0001fe07)  (cmem.c file)

• in the kernel module's ioctl function the first command evaluation masks out the magic number (0x00ff mask) and reaches the case statement CMEM_IOCCACHE (0x00000007)  (cmemk.c file). So far everything is ok

• in order to reach the assembler cache functions ( dmac_clean_range() ) the cmd is evaluated by a switch statement again - here  the case statement expects CMEM_IOCCACHEWB (0x00010007, no masking) although 0x0001fe07 was passed. That's why dmac_clean_range() is not reached and the ioctl returns quite normally.

Hi,

Thanks for your answers. As Sebastian pointed I also think it cannot work. To answer you, yes I'm using the same version for user library and kernel.

Regards,

Guillaume

Sebastian,

Thanks for the detailed description.  You are correct in your analysis (but I'm sure you knew that :).  I will file a bug for this and it will be fixed in upcoming releases.

Guillaume, thanks for your help here.

Regards,

- Rob

This is tracked as SDOCM00067560, and the fix is now available in Linux Utils 2.25.02.08, available here:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/index.html

Thanks for the clear bug report!

Chris