Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Hi,
>>>>>>
>>>>>> doesn't this patch [1] have some relevance for us as well? As we use
>>>>>> xnarch_remap_io_page_range also for non-IO memory, I'm hesitating to
>>>>>> suggest that we apply this unconditionally at xnarch level. Ideas 
>>>>>> welcome.
>>>>>>
>>>>> Yes, I think it makes a lot of sense on powerpc at least, since doing so 
>>>>> will
>>>>> set the PAGE_GUARDED bit as well, and we obviously want to avoid any
>>>>> out-of-order access of I/O memory.
>>>>>
>>>>> (I don't see the reason to force the VM_RESERVED and VM_IO on the vma 
>>>>> though,
>>>>> since remap_pfn_range will do it anyway.)
>>>> No, I was talking about cases where we may pass kmalloc'ed memory to
>>>> xnarch_remap_io_page_range. In that case, caching and out-of-order
>>>> access may be desired for performance reasons.
>>>>
>>> xnarch_remap_io_page_range is intended for I/O memory only, some 
>>> assumptions are
>>> made on this. rtdm_mmap_buffer() should be fixed; it would be much better to
>>> define another internal interface at xnarch level to specifically perform
>>> kmalloc mapping.
>> Yeah, probably. But I think the issue is not just limited to RTDM. The
>> xnheap can be kmalloc-hosted as well.
>>
> 
> This one is used with DMA memory. What I would suggest, is something like 
> this:
> 
> --- ksrc/skins/rtdm/drvlib.c  (revision 3590)
> +++ ksrc/skins/rtdm/drvlib.c  (working copy)
> @@ -1738,9 +1738,12 @@
>               }
>               return 0;
>       } else
> -#endif /* CONFIG_MMU */
>               return xnarch_remap_io_page_range(vma, maddr, paddr,
>                                                 size, PAGE_SHARED);
> +#else
> +     return xnarch_remap_kmem_page_range(vma, maddr, paddr,
> +                                         size, PAGE_SHARED);
> +#endif /* CONFIG_MMU */
>  }
> 
>  static struct file_operations rtdm_mmap_fops = {
> 
> 
> I.e. split the cases where MMU is absent from the one where MMU is there but 
> we
> come from rtdm_iomap_to_user.

Makes no sense to me yet. With CONFIG_MMU we have 3 cases, not just two,
no? We have to use mmap_data->src_paddr to tell kmem_page apart from
io_page.

And we do not need io_page at all in the !CONFIG_MMU case?

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to