Re: [Xenomai] Porting xenomai 2.6.3 and ipipe to 3.12 kernel

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 03/31/2014 09:37 PM, Lennart Sorensen wrote:
> On Mon, Mar 31, 2014 at 03:18:49PM -0400, Lennart Sorensen wrote:
>> On Mon, Mar 31, 2014 at 09:17:16PM +0200, Gilles Chanteperdrix wrote:
>>> Are you sure you are loking at the right tree? I am talking about the
>>> raw/for-ipipe-3.12.0 tree in ipipe-gch.git, not the raw/ipipe-3.12.0
>>> tree in ipipe.git
>>
>> Oh, then no, wrong tree.
>>
>> Let me check the other one.
> 
> Ok that looks better.
> 
> Couple of things:
> 
> I think this is wrong:
> 
>   @@ -268,13 +298,22 @@ extern void flush_cache_page(struct vm_area_struct *vma, unsigned long user_addr                               
>     * Harvard caches are synchronised for the user space address range.                                                                
>     * This is used for the ARM private sys_cacheflush system call.
>     */
>   -#define flush_cache_user_range(s,e)    __cpuc_coherent_user_range(s,e)
>   +#define flush_cache_user_range(s, e)                                   \                                                            
>   +       ({                                                              \                                                            
>   +               struct mm_struct *_mm = current->mm;                    \
>   +               unsigned long _s, _e;                                   \
>   +               _s = fcse_va_to_mva(_mm, s) & PAGE_MASK;                \
>   +               _e = PAGE_ALIGN(fcse_va_to_mva(_mm, e));                \
>   +               __cpuc_coherent_user_range(_s, _e);                     \                                                            
>   +       })                                                                                                                           
>    
>    /* 
>     * Perform necessary cache operations to ensure that data previously                                                                
> 
> The kernel specificly did NOT want the PAGE_MASK and PAGE_ALIGN and got
> rid of it.  At last that's what the commit that changed it said.  So I
> think the ipipe patch should follow that change too.  ie:
> 
>   @@ -268,13 +298,22 @@ extern void flush_cache_page(struct vm_area_struct *vma, unsigned long user_addr                               
>     * Harvard caches are synchronised for the user space address range.                                                                
>     * This is used for the ARM private sys_cacheflush system call.
>     */
>   -#define flush_cache_user_range(s,e)    __cpuc_coherent_user_range(s,e)
>   +#define flush_cache_user_range(s, e)                                   \                                                            
>   +       ({                                                              \                                                            
>   +               struct mm_struct *_mm = current->mm;                    \
>   +               unsigned long _s, _e;                                   \
>   +               _s = fcse_va_to_mva(_mm, s);                            \
>   +               _e = fcse_va_to_mva(_mm, e);                            \
>   +               __cpuc_coherent_user_range(_s, _e);                     \                                                            
>   +       })                                                                                                                           
>    
>    /* 
>     * Perform necessary cache operations to ensure that data previously                                                                

Ok, thanks, will fix in 3.14 patch.

> 
> Also my version of arch/arm/include/asm/barrier.h turned out a bit
> different (I was trying to avoid changing the kernel code as much as
> possible).  Diff versus yours is:

I do not really see differences...



> +#define dmb(option) __asm__ __volatile__("" #option : : : "memory")

...except this which is wrong (ish, shst are probably not valid
instructions, and only make sense as suffixes after dmb). It should not
even compile.



-- 
                                                                Gilles.