Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB
>-Original Message-
>From: Jan Kiszka [mailto:jan.kis...@siemens.com]
>Sent: Wednesday, November 11, 2009 9:06 AM
>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.kis...@web.de [mailto:jan.kis...@web.de]
>>> Sent: Tuesday, November 10, 2009 4:22 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: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.
>>> But there is nothing shifted, the shifting takes place in
>>> Xenomai's wrapper.
>>>
> 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?
>>> OK, now I got my mistake: Confused by the wrong argument
>names of our
>>> wrap_remap_io_page_range (and probably others) I thought that the
>>> destination is given as page number, not the source.
>>>
>>> But before adding some fancy new service for this use case,
>I'd like to
>>> understand how common it actually is (crazy embedded designs
>>> tend to pop
>>> up and deprecate faster than such APIs...).
>> I do not think this is a new service but a limitation in the design.
>> Th
Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB
Herrera-Bendezu, Luis wrote:
>
>
>> -Original Message-
>> From: jan.kis...@web.de [mailto:jan.kis...@web.de]
>> Sent: Tuesday, November 10, 2009 4:22 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: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.
>> But there is nothing shifted, the shifting takes place in
>> Xenomai's wrapper.
>>
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?
>> OK, now I got my mistake: Confused by the wrong argument names of our
>> wrap_remap_io_page_range (and probably others) I thought that the
>> destination is given as page number, not the source.
>>
>> But before adding some fancy new service for this use case, I'd like to
>> understand how common it actually is (crazy embedded designs
>> tend to pop
>> up and deprecate faster than such APIs...).
> I do not think this is a new service but a limitation in the design.
> The kernel supports it (application can mmap the device using /dev/mem)
> and the PPC (440EPx in particular) has PCI and internal peripherals
> located at addresses above 4 GB (I2C, SPI, etc.).
I think /dev/mem works by chance as it uses off_t to address the source,
and that is 64 bit even on 32 bit hosts.
But I just collected the confirmation that this extension of
Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB
>-Original Message-
>From: jan.kis...@web.de [mailto:jan.kis...@web.de]
>Sent: Tuesday, November 10, 2009 4:22 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: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.
>
>But there is nothing shifted, the shifting takes place in
>Xenomai's wrapper.
>
>>> 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?
>
>OK, now I got my mistake: Confused by the wrong argument names of our
>wrap_remap_io_page_range (and probably others) I thought that the
>destination is given as page number, not the source.
>
>But before adding some fancy new service for this use case, I'd like to
>understand how common it actually is (crazy embedded designs
>tend to pop
>up and deprecate faster than such APIs...).
I do not think this is a new service but a limitation in the design.
The kernel supports it (application can mmap the device using /dev/mem)
and the PPC (440EPx in particular) has PCI and internal peripherals
located at addresses above 4 GB (I2C, SPI, etc.).
>
>And what was the final conclusion on LKML? As far as I understood the
>UIO maintainer, the proposal was rejected. Any different follow-ups on
>this that I missed? Of course, if you have a special design you can
>always patch your kernel and Xenomai to fit these special purposes. But
>for upstream support, kernel or Xenomai, it requires a
Re: [Xenomai-core] 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: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.
But there is nothing shifted, the shifting takes place in Xenomai's wrapper.
>> 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?
OK, now I got my mistake: Confused by the wrong argument names of our
wrap_remap_io_page_range (and probably others) I thought that the
destination is given as page number, not the source.
But before adding some fancy new service for this use case, I'd like to
understand how common it actually is (crazy embedded designs tend to pop
up and deprecate faster than such APIs...).
And what was the final conclusion on LKML? As far as I understood the
UIO maintainer, the proposal was rejected. Any different follow-ups on
this that I missed? Of course, if you have a special design you can
always patch your kernel and Xenomai to fit these special purposes. But
for upstream support, kernel or Xenomai, it requires a clean and
portable model.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB
>-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
Re: [Xenomai-core] 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?
Besides this, the key is how remap_pfn_page interprets the source
address argument.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB
>-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. Luis ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] 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. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB
>-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). Luis ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
