>-----Original Message-----
>From: Jan Kiszka [mailto:jan.kis...@siemens.com] 
>Sent: Tuesday, November 10, 2009 1:55 PM
>To: Herrera-Bendezu, Luis
>Cc: xenomai-core@gna.org
>Subject: Re: rtdm_iomap_to_user with phys addr > 4GB
>
>
>Herrera-Bendezu, Luis wrote:
>>  
>> 
>>> -----Original Message-----
>>> From: Jan Kiszka [mailto:jan.kis...@siemens.com] 
>>> Sent: Tuesday, November 10, 2009 1:13 PM
>>> To: Herrera-Bendezu, Luis
>>> Cc: xenomai-core@gna.org
>>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB
>>>
>>>
>>> Herrera-Bendezu, Luis wrote:
>>>>  
>>>>
>>>>> -----Original Message-----
>>>>> From: Jan Kiszka [mailto:jan.kis...@siemens.com] 
>>>>> Sent: Tuesday, November 10, 2009 12:03 PM
>>>>> To: Herrera-Bendezu, Luis
>>>>> Cc: xenomai-core@gna.org
>>>>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB
>>>>>
>>>>>
>>>>> Herrera-Bendezu, Luis wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am writing an RTDM driver to replace one that uses UIO. 
>>> The device
>>>>>> resides in a physical address > 4 GB on a PPC440EPx. The 
>UIO could
>>>>>> not handle this address so I made a proposal to address it, 
>>>>> details at:
>>> 
>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-April/070097.html
>>>>>> Function rtdm_iomap_to_user() has same issue with the 
>physical I/O
>>>>>> address
>>>>>>    unsigned long src_addr
>>>>>>
>>>>>> I am new to Xenomai and would like to get some ideas on 
>>> how to solve
>>>>>> this
>>>>>> issue.
>>>>> I think UIO as well as RTDM suffers from the same problem 
>here: The
>>>>> kernel service used to remap the physical memory (remap_pfn_range)
>>>>> accepts unsigned long, not phys_addr_t. How is this 
>>> supposed to work?
>>>>> Jan
>>>>>
>>>>> -- 
>>>>> Siemens AG, Corporate Technology, CT SE 2
>>>>> Corporate Competence Center Embedded Linux
>>>>>
>>>> Actually, remap_pfn_range() gets passed the physical address left
>>>> shifted by PAGE_SIZE in both UIO and RTDM 
>>> (xnarch_remap_io_page_range,
>>>> wrap_remap_io_page_range).
>>> No, the target address is expressed in pages, the source in bytes.
>>>
>> That is true for rtdm_mmap_to_user but not for 
>rtdm_iomap_to_user. See
>> how
>> mmap_data struct is set in both functions.
>
>        struct rtdm_mmap_data mmap_data =
>                { NULL, src_addr, vm_ops, vm_private_data };
>
>with src_addr = "physical I/O address to be mapped", setting
>mmap_data.src_paddr -- are you looking at different code?
>
No, that is the code.
>Besides this, the key is how remap_pfn_page interprets the source
>address argument.
>
I had used UIO with success (as described in link above). The equivalent
code in UIO is (uio.c):
static int uio_mmap_physical(struct vm_area_struct *vma)
{
        struct uio_device *idev = vma->vm_private_data;
        int mi = uio_find_mem_index(vma);
        if (mi < 0)
                return -EINVAL;

        vma->vm_flags |= VM_IO | VM_RESERVED;

        vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

        return remap_pfn_range(vma,
                               vma->vm_start,
                               idev->info->mem[mi].addr >> PAGE_SHIFT,
                               vma->vm_end - vma->vm_start,
                               vma->vm_page_prot);
}

where idev->info->mem[mi].addr, mem[.] is the list of mappable regions.
Note that for UIO, the user application needs to mmap these regions to
user space. This is a step that is not needed on RTDM, right?

Luis





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

Reply via email to