[Xenomai] rtdm_iomap_to_user caching followup

[Xenomai] rtdm_iomap_to_user caching followup

[Jeffrey Melville]

All,

There was a patch applied back in January 2013 to disable caching with 
memory areas mapped with rtdm_iomap_to_user. 
(http://www.xenomai.org/pipermail/xenomai/2013-January/027370.html)

Henri Roosen followed up in September 2013 to say that he still saw 
caching behavior with rtdm_iomap_to_user. The original patch didn't 
cover the ifdef LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16) && 
defined(CONFIG_MMU). He submitted two patch options but I didn't see any 
responses. 
(http://www.xenomai.org/pipermail/xenomai/2013-September/029211.html)

I'm currently working with a Zynq ZC706, using Xenomai 2.6.3 on top of 
the Xilinx fork of the 3.8 kernel, as described in the README. The FPGA 
guys gave me a test FPGA image with a (dumb) AXI slave that has a very 
small register space. Pulling a cache line actually overflows the 
register space and causes the bus to lock up. I added a logic analyzer 
block to the FPGA to confirm the access addresses.

More importantly, I don't want any of that address space cached even 
when the register space gets bigger. I was able to fix my problems by 
changing this line:

- remap_pfn_range(vma,from,(to) >> PAGE_SHIFT,size,prot); \
+ remap_pfn_range(vma,from,(to) >> 
PAGE_SHIFT,size,pgprot_noncached(prot)); \

Can we apply the patch? I can provide a new one if it is lost. Or is 
there a better way to use rtdm_iomap_to_user that lets the caller 
specify caching behavior? I couldn't find one.

As a side note, has anyone successfully used Xenomai with Zynq on 
kernels newer than 3.8? I haven't found any newer pre/post patches and 
haven't had time to play around with manually merging it yet. I'd be 
willing to help if this is an area of need.

Cheers,
Jeff

Re: [Xenomai] rtdm_iomap_to_user caching followup

[Gilles Chanteperdrix]

On 08/20/2014 04:46 PM, Jeffrey Melville wrote:
> All,
> 
> There was a patch applied back in January 2013 to disable caching with 
> memory areas mapped with rtdm_iomap_to_user. 
> (http://www.xenomai.org/pipermail/xenomai/2013-January/027370.html)
> 
> Henri Roosen followed up in September 2013 to say that he still saw 
> caching behavior with rtdm_iomap_to_user. The original patch didn't 
> cover the ifdef LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16) && 
> defined(CONFIG_MMU). He submitted two patch options but I didn't see any 
> responses. 
> (http://www.xenomai.org/pipermail/xenomai/2013-September/029211.html)


I believe this has been merged with commit
http://git.xenomai.org/xenomai-2.6.git/commit/?id=1b8fb14e486ac0604e44067a0f1f89dc14153e95

Could you try xenomai 2.6 git to see if you still have the issue?

-- 
                                                                Gilles.

Re: [Xenomai] rtdm_iomap_to_user caching followup

[Jeffrey Melville]

On 8/20/2014 3:09 PM, Gilles Chanteperdrix wrote:
> On 08/20/2014 04:46 PM, Jeffrey Melville wrote:
>> All,
>>
>> There was a patch applied back in January 2013 to disable caching with
>> memory areas mapped with rtdm_iomap_to_user.
>> (http://www.xenomai.org/pipermail/xenomai/2013-January/027370.html)
>>
>> Henri Roosen followed up in September 2013 to say that he still saw
>> caching behavior with rtdm_iomap_to_user. The original patch didn't
>> cover the ifdef LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16) &&
>> defined(CONFIG_MMU). He submitted two patch options but I didn't see any
>> responses.
>> (http://www.xenomai.org/pipermail/xenomai/2013-September/029211.html)
>
>
> I believe this has been merged with commit
> http://git.xenomai.org/xenomai-2.6.git/commit/?id=1b8fb14e486ac0604e44067a0f1f89dc14153e95
>
> Could you try xenomai 2.6 git to see if you still have the issue?
>
Gilles,

Thanks for your response. My mistake, I thought I had already looked at 
the 2.6 git head. The commit you mentioned is the right one. I tested 
the 2.6 git on my hardware and didn't have any lockup issues. Yocto 
actually still mistakenly applied my old patch against the kmem wrapper 
(which I'm not using anywhere). I need to remove that from my build but 
otherwise everything looks good for now.

Cheers,
Jeff