* [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB @ 2009-11-10 16:42 Herrera-Bendezu, Luis 2009-11-10 17:02 ` Jan Kiszka 0 siblings, 1 reply; 18+ messages in thread From: Herrera-Bendezu, Luis @ 2009-11-10 16:42 UTC (permalink / raw) To: xenomai 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. Thanks, Luis G. Herrera-Bendezu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-10 16:42 [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB Herrera-Bendezu, Luis @ 2009-11-10 17:02 ` Jan Kiszka 2009-11-10 17:58 ` Herrera-Bendezu, Luis 0 siblings, 1 reply; 18+ messages in thread From: Jan Kiszka @ 2009-11-10 17:02 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-10 17:02 ` Jan Kiszka @ 2009-11-10 17:58 ` Herrera-Bendezu, Luis 2009-11-10 18:13 ` Jan Kiszka 0 siblings, 1 reply; 18+ messages in thread From: Herrera-Bendezu, Luis @ 2009-11-10 17:58 UTC (permalink / raw) To: xenomai >-----Original Message----- >From: Jan Kiszka [mailto:jan.kiszka@domain.hid >Sent: Tuesday, November 10, 2009 12:03 PM >To: Herrera-Bendezu, Luis >Cc: xenomai@xenomai.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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-10 17:58 ` Herrera-Bendezu, Luis @ 2009-11-10 18:13 ` Jan Kiszka 2009-11-10 18:29 ` Herrera-Bendezu, Luis 0 siblings, 1 reply; 18+ messages in thread From: Jan Kiszka @ 2009-11-10 18:13 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: > > >> -----Original Message----- >> From: Jan Kiszka [mailto:jan.kiszka@domain.hid] >> Sent: Tuesday, November 10, 2009 12:03 PM >> To: Herrera-Bendezu, Luis >> Cc: xenomai@xenomai.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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-10 18:13 ` Jan Kiszka @ 2009-11-10 18:29 ` Herrera-Bendezu, Luis 2009-11-10 18:54 ` Jan Kiszka 0 siblings, 1 reply; 18+ messages in thread From: Herrera-Bendezu, Luis @ 2009-11-10 18:29 UTC (permalink / raw) To: xenomai >-----Original Message----- >From: Jan Kiszka [mailto:jan.kiszka@domain.hid >Sent: Tuesday, November 10, 2009 1:13 PM >To: Herrera-Bendezu, Luis >Cc: xenomai@xenomai.org >Subject: Re: rtdm_iomap_to_user with phys addr > 4GB > > >Herrera-Bendezu, Luis wrote: >> >> >>> -----Original Message----- >>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>> Sent: Tuesday, November 10, 2009 12:03 PM >>> To: Herrera-Bendezu, Luis >>> Cc: xenomai@xenomai.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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-10 18:29 ` Herrera-Bendezu, Luis @ 2009-11-10 18:54 ` Jan Kiszka 2009-11-10 19:20 ` Herrera-Bendezu, Luis 0 siblings, 1 reply; 18+ messages in thread From: Jan Kiszka @ 2009-11-10 18:54 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: > > >> -----Original Message----- >> From: Jan Kiszka [mailto:jan.kiszka@domain.hid] >> Sent: Tuesday, November 10, 2009 1:13 PM >> To: Herrera-Bendezu, Luis >> Cc: xenomai@xenomai.org >> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >> >> >> Herrera-Bendezu, Luis wrote: >>> >>> >>>> -----Original Message----- >>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid] >>>> Sent: Tuesday, November 10, 2009 12:03 PM >>>> To: Herrera-Bendezu, Luis >>>> Cc: xenomai@xenomai.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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-10 18:54 ` Jan Kiszka @ 2009-11-10 19:20 ` Herrera-Bendezu, Luis 2009-11-10 21:21 ` Jan Kiszka 0 siblings, 1 reply; 18+ messages in thread From: Herrera-Bendezu, Luis @ 2009-11-10 19:20 UTC (permalink / raw) To: xenomai >-----Original Message----- >From: Jan Kiszka [mailto:jan.kiszka@domain.hid >Sent: Tuesday, November 10, 2009 1:55 PM >To: Herrera-Bendezu, Luis >Cc: xenomai@xenomai.org >Subject: Re: rtdm_iomap_to_user with phys addr > 4GB > > >Herrera-Bendezu, Luis wrote: >> >> >>> -----Original Message----- >>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>> Sent: Tuesday, November 10, 2009 1:13 PM >>> To: Herrera-Bendezu, Luis >>> Cc: xenomai@xenomai.org >>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >>> >>> >>> Herrera-Bendezu, Luis wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>>>> Sent: Tuesday, November 10, 2009 12:03 PM >>>>> To: Herrera-Bendezu, Luis >>>>> Cc: xenomai@xenomai.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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-10 19:20 ` Herrera-Bendezu, Luis @ 2009-11-10 21:21 ` Jan Kiszka 2009-11-11 12:38 ` Herrera-Bendezu, Luis 0 siblings, 1 reply; 18+ messages in thread From: Jan Kiszka @ 2009-11-10 21:21 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai [-- Attachment #1: Type: text/plain, Size: 4409 bytes --] Herrera-Bendezu, Luis wrote: > > >> -----Original Message----- >> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >> Sent: Tuesday, November 10, 2009 1:55 PM >> To: Herrera-Bendezu, Luis >> Cc: xenomai@xenomai.org >> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >> >> >> Herrera-Bendezu, Luis wrote: >>> >>> >>>> -----Original Message----- >>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>>> Sent: Tuesday, November 10, 2009 1:13 PM >>>> To: Herrera-Bendezu, Luis >>>> Cc: xenomai@xenomai.org >>>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >>>> >>>> >>>> Herrera-Bendezu, Luis wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>>>>> Sent: Tuesday, November 10, 2009 12:03 PM >>>>>> To: Herrera-Bendezu, Luis >>>>>> Cc: xenomai@xenomai.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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-10 21:21 ` Jan Kiszka @ 2009-11-11 12:38 ` Herrera-Bendezu, Luis 2009-11-11 14:06 ` Jan Kiszka 0 siblings, 1 reply; 18+ messages in thread From: Herrera-Bendezu, Luis @ 2009-11-11 12:38 UTC (permalink / raw) To: xenomai >-----Original Message----- >From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid >Sent: Tuesday, November 10, 2009 4:22 PM >To: Herrera-Bendezu, Luis >Cc: xenomai@xenomai.org >Subject: Re: rtdm_iomap_to_user with phys addr > 4GB > >Herrera-Bendezu, Luis wrote: >> >> >>> -----Original Message----- >>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>> Sent: Tuesday, November 10, 2009 1:55 PM >>> To: Herrera-Bendezu, Luis >>> Cc: xenomai@xenomai.org >>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >>> >>> >>> Herrera-Bendezu, Luis wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>>>> Sent: Tuesday, November 10, 2009 1:13 PM >>>>> To: Herrera-Bendezu, Luis >>>>> Cc: xenomai@xenomai.org >>>>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >>>>> >>>>> >>>>> Herrera-Bendezu, Luis wrote: >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>>>>>> Sent: Tuesday, November 10, 2009 12:03 PM >>>>>>> To: Herrera-Bendezu, Luis >>>>>>> Cc: xenomai@xenomai.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 clean and >portable model. There were no follow-ups and the reply concerning the required changes was: "I guess you'd have to look at the whole memory management stuff of each architecture to find out which kind of memory can be mapped with addresses above unsigned long. Hardware often needs more than one contigous pages. It might well be possible that a certain arch could have RAM for user virtual addresses above 4GB, but no hardware. I don't know PPC well enough to say anything about its behaviour." In the mean time, it would be helpful if you have some suggestions on how to change RTDM to handle this case. Thanks, Luis ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-11 12:38 ` Herrera-Bendezu, Luis @ 2009-11-11 14:06 ` Jan Kiszka 2009-11-11 15:40 ` Herrera-Bendezu, Luis 2009-11-18 16:00 ` [Xenomai-core] rtdm_iomap_to_user with phys addr > 4G Herrera-Bendezu, Luis 0 siblings, 2 replies; 18+ messages in thread From: Jan Kiszka @ 2009-11-11 14:06 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: > > >> -----Original Message----- >> From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid] >> Sent: Tuesday, November 10, 2009 4:22 PM >> To: Herrera-Bendezu, Luis >> Cc: xenomai@xenomai.org >> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >> >> Herrera-Bendezu, Luis wrote: >>> >>> >>>> -----Original Message----- >>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid] >>>> Sent: Tuesday, November 10, 2009 1:55 PM >>>> To: Herrera-Bendezu, Luis >>>> Cc: xenomai@xenomai.org >>>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >>>> >>>> >>>> Herrera-Bendezu, Luis wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid] >>>>>> Sent: Tuesday, November 10, 2009 1:13 PM >>>>>> To: Herrera-Bendezu, Luis >>>>>> Cc: xenomai@xenomai.org >>>>>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >>>>>> >>>>>> >>>>>> Herrera-Bendezu, Luis wrote: >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid] >>>>>>>> Sent: Tuesday, November 10, 2009 12:03 PM >>>>>>>> To: Herrera-Bendezu, Luis >>>>>>>> Cc: xenomai@xenomai.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 the PPC's physical address range is indeed an increasingly common thing. It's still a fairly new one, so the kernel is obviously also still in the conversion process. Maybe poking those people again makes some sense. >> 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. > There were no follow-ups and the reply concerning the required changes > was: > "I guess you'd have to look at the whole memory management stuff of each > architecture to find out which kind of memory can be mapped with > addresses > above unsigned long. Hardware often needs more than one contigous > pages. > It might well be possible that a certain arch could have RAM for user > virtual > addresses above 4GB, but no hardware. I don't know PPC well enough to > say > anything about its behaviour." > > In the mean time, it would be helpful if you have some suggestions on > how to > change RTDM to handle this case. > I think we can change rtdm_iomap_to_user to take src_addr as phys_addr_t and propagate this internally properly. We also need to add a wrapper for phys_addr_t for kernels that doesn't support this (<2.6.28). To my current understanding, this should be sufficient, right? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB 2009-11-11 14:06 ` Jan Kiszka @ 2009-11-11 15:40 ` Herrera-Bendezu, Luis 2009-11-18 16:00 ` [Xenomai-core] rtdm_iomap_to_user with phys addr > 4G Herrera-Bendezu, Luis 1 sibling, 0 replies; 18+ messages in thread From: Herrera-Bendezu, Luis @ 2009-11-11 15:40 UTC (permalink / raw) To: xenomai >-----Original Message----- >From: Jan Kiszka [mailto:jan.kiszka@domain.hid >Sent: Wednesday, November 11, 2009 9:06 AM >To: Herrera-Bendezu, Luis >Cc: xenomai@xenomai.org >Subject: Re: rtdm_iomap_to_user with phys addr > 4GB > > >Herrera-Bendezu, Luis wrote: >> >> >>> -----Original Message----- >>> From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid >>> Sent: Tuesday, November 10, 2009 4:22 PM >>> To: Herrera-Bendezu, Luis >>> Cc: xenomai@xenomai.org >>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >>> >>> Herrera-Bendezu, Luis wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>>>> Sent: Tuesday, November 10, 2009 1:55 PM >>>>> To: Herrera-Bendezu, Luis >>>>> Cc: xenomai@xenomai.org >>>>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >>>>> >>>>> >>>>> Herrera-Bendezu, Luis wrote: >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>>>>>> Sent: Tuesday, November 10, 2009 1:13 PM >>>>>>> To: Herrera-Bendezu, Luis >>>>>>> Cc: xenomai@xenomai.org >>>>>>> Subject: Re: rtdm_iomap_to_user with phys addr > 4GB >>>>>>> >>>>>>> >>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid >>>>>>>>> Sent: Tuesday, November 10, 2009 12:03 PM >>>>>>>>> To: Herrera-Bendezu, Luis >>>>>>>>> Cc: xenomai@xenomai.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 the PPC's >physical address range is indeed an increasingly common thing. It's >still a fairly new one, so the kernel is obviously also still in the >conversion process. Maybe poking those people again makes some sense. > >>> 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. >> There were no follow-ups and the reply concerning the >required changes >> was: >> "I guess you'd have to look at the whole memory management >stuff of each >> architecture to find out which kind of memory can be mapped with >> addresses >> above unsigned long. Hardware often needs more than one contigous >> pages. >> It might well be possible that a certain arch could have >RAM for user >> virtual >> addresses above 4GB, but no hardware. I don't know PPC well >enough to >> say >> anything about its behaviour." >> >> In the mean time, it would be helpful if you have some suggestions on >> how to >> change RTDM to handle this case. >> > >I think we can change rtdm_iomap_to_user to take src_addr as >phys_addr_t >and propagate this internally properly. We also need to add a wrapper >for phys_addr_t for kernels that doesn't support this (<2.6.28). To my >current understanding, this should be sufficient, right? Yes, I will give it a try and discuss results. Luis ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4G 2009-11-11 14:06 ` Jan Kiszka 2009-11-11 15:40 ` Herrera-Bendezu, Luis @ 2009-11-18 16:00 ` Herrera-Bendezu, Luis 2009-11-18 16:42 ` Jan Kiszka 1 sibling, 1 reply; 18+ messages in thread From: Herrera-Bendezu, Luis @ 2009-11-18 16:00 UTC (permalink / raw) To: xenomai Jan, >I think we can change rtdm_iomap_to_user to take src_addr as >phys_addr_t >and propagate this internally properly. We also need to add a wrapper >for phys_addr_t for kernels that doesn't support this (<2.6.28). To my >current understanding, this should be sufficient, right? > This is a diff against Xenomai version 2.4.8 and Linux version 2.6.28 to handle RTDM mapping to user space of devices located at addresses > 4 GB. Rather than modifying existing rtdm_iomap_to_user() API a new one is added, rtdm_iomap_to_user64() (to mimic mmap64()). Since this is a user API it can not use phys_addr_t so unsigned long long is used for the interface. I tried to use rtdm_iomap_to_user() on a kernel module initialization section of my RTDM driver and passing NULL to user_info argument. This causes an invalid memory access and system panic. How can this function be called from kernel intialization code? diff --git a/include/asm-generic/xenomai/system.h b/include/asm-generic/xenomai/system.h index 020e763..f2a9424 100644 --- a/include/asm-generic/xenomai/system.h +++ b/include/asm-generic/xenomai/system.h @@ -417,7 +417,7 @@ static inline int xnarch_remap_vm_page(struct vm_area_struct *vma, static inline int xnarch_remap_io_page_range(struct file *filp, struct vm_area_struct *vma, unsigned long from, - unsigned long to, + phys_addr_t to, unsigned long size, pgprot_t prot) { diff --git a/include/asm-generic/xenomai/wrappers.h b/include/asm-generic/xenomai/wrappers.h index 943ed34..319ac0d 100644 --- a/include/asm-generic/xenomai/wrappers.h +++ b/include/asm-generic/xenomai/wrappers.h @@ -400,4 +400,9 @@ static inline int wrap_raise_cap(int cap) } #endif /* LINUX_VERSION_CODE >= 2.6.29 */ +/* For Linux versions < 2.6.28 */ +#ifndef phys_addr_t +#define phys_addr_t unsigned long +#endif + #endif /* _XENO_ASM_GENERIC_WRAPPERS_H */ diff --git a/include/xenomai/rtdm/rtdm_driver.h b/include/xenomai/rtdm/rtdm_driver.h index 3026aff..181caef 100644 --- a/include/xenomai/rtdm/rtdm_driver.h +++ b/include/xenomai/rtdm/rtdm_driver.h @@ -1172,6 +1172,11 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, int prot, void **pptr, struct vm_operations_struct *vm_ops, void *vm_private_data); +int rtdm_iomap_to_user64(rtdm_user_info_t *user_info, + unsigned long long src_addr, size_t len, + int prot, void **pptr, + struct vm_operations_struct *vm_ops, + void *vm_private_data); int rtdm_munmap(rtdm_user_info_t *user_info, void *ptr, size_t len); static inline int rtdm_read_user_ok(rtdm_user_info_t *user_info, diff --git a/kernel/xenomai/skins/rtdm/drvlib.c b/kernel/xenomai/skins/rtdm/drvlib.c index 65c630f..0a710ee 100644 --- a/kernel/xenomai/skins/rtdm/drvlib.c +++ b/kernel/xenomai/skins/rtdm/drvlib.c @@ -1765,7 +1765,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) struct rtdm_mmap_data { void *src_vaddr; - unsigned long src_paddr; + phys_addr_t src_paddr; struct vm_operations_struct *vm_ops; void *vm_private_data; }; @@ -1773,14 +1773,15 @@ struct rtdm_mmap_data { static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma) { struct rtdm_mmap_data *mmap_data = filp->private_data; - unsigned long vaddr, paddr, maddr, size; + unsigned long vaddr, maddr, size; + phys_addr_t paddr; int ret; vma->vm_ops = mmap_data->vm_ops; vma->vm_private_data = mmap_data->vm_private_data; vaddr = (unsigned long)mmap_data->src_vaddr; - paddr = (unsigned long)mmap_data->src_paddr; + paddr = (phys_addr_t)mmap_data->src_paddr; if (!paddr) /* kmalloc memory */ paddr = virt_to_phys((void *)vaddr); @@ -1995,6 +1996,20 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, EXPORT_SYMBOL(rtdm_iomap_to_user); +int rtdm_iomap_to_user64(rtdm_user_info_t *user_info, + unsigned long long src_addr, size_t len, + int prot, void **pptr, + struct vm_operations_struct *vm_ops, + void *vm_private_data) +{ + struct rtdm_mmap_data mmap_data = + { NULL, src_addr, vm_ops, vm_private_data }; + + return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); +} + +EXPORT_SYMBOL(rtdm_iomap_to_user64); + /** * Unmap a user memory range. * Luis ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4G 2009-11-18 16:00 ` [Xenomai-core] rtdm_iomap_to_user with phys addr > 4G Herrera-Bendezu, Luis @ 2009-11-18 16:42 ` Jan Kiszka [not found] ` <6FCCA913376DD7488F4139A4D11B8F48FD187B@troe2k1.cs.myharris.net> 0 siblings, 1 reply; 18+ messages in thread From: Jan Kiszka @ 2009-11-18 16:42 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: > Jan, > >> I think we can change rtdm_iomap_to_user to take src_addr as >> phys_addr_t >> and propagate this internally properly. We also need to add a wrapper >> for phys_addr_t for kernels that doesn't support this (<2.6.28). To my >> current understanding, this should be sufficient, right? >> > > This is a diff against Xenomai version 2.4.8 and Linux version 2.6.28 to > handle RTDM mapping to user space of devices located at addresses > 4 > GB. Does it apply against git-head as well? Note that this won't make it into stable 2.4. > Rather than modifying existing rtdm_iomap_to_user() API a new one is > added, rtdm_iomap_to_user64() (to mimic mmap64()). Since this is a user > API it can not use phys_addr_t so unsigned long long is used for the > interface. 64 bit is not related to phys_addr_t. It /may/ be 64 bit, but it may also be less (or more one day...?). So let's switch the existing interface, just like the kernel does. And it is not a user API; it is used between the driver and RTDM only. How the driver deals with this in its user interface is a different story. I think there is currently no publicly available driver that maps I/O space into a user application, thus there is probably no stable RTDM profile that uses unsigned long to specify a physical address. > > I tried to use rtdm_iomap_to_user() on a kernel module initialization > section of my RTDM driver and passing NULL to user_info argument. This > causes an invalid memory access and system panic. How can this > function be called from kernel intialization code? Not at all. It is supposed to be called on behalf of a user application, asking the driver to map some area into its address space. Then you have a valid user_info at hand. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <6FCCA913376DD7488F4139A4D11B8F48FD187B@troe2k1.cs.myharris.net>]
* Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4G [not found] ` <6FCCA913376DD7488F4139A4D11B8F48FD187B@troe2k1.cs.myharris.net> @ 2009-11-20 10:35 ` Jan Kiszka 2009-11-20 16:41 ` [Xenomai-core] [PATCH] rtdm: Extend rtdm_iomap_to_user to map " Herrera-Bendezu, Luis 0 siblings, 1 reply; 18+ messages in thread From: Jan Kiszka @ 2009-11-20 10:35 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai-core Please make sure to always preserve CCs. Herrera-Bendezu, Luis wrote: >> -----Original Message----- >> From: Jan Kiszka [mailto:jan.kiszka@domain.hid] >> Sent: Wednesday, November 18, 2009 11:42 AM >> To: Herrera-Bendezu, Luis >> Cc: xenomai@xenomai.org >> Subject: Re: rtdm_iomap_to_user with phys addr > 4G >> >> >> Herrera-Bendezu, Luis wrote: >>> Jan, >>> >>>> I think we can change rtdm_iomap_to_user to take src_addr as >>>> phys_addr_t >>>> and propagate this internally properly. We also need to add >> a wrapper >>>> for phys_addr_t for kernels that doesn't support this >> (<2.6.28). To my >>>> current understanding, this should be sufficient, right? >>>> >>> This is a diff against Xenomai version 2.4.8 and Linux >> version 2.6.28 to >>> handle RTDM mapping to user space of devices located at addresses > 4 >>> GB. >> Does it apply against git-head as well? Note that this won't make it >> into stable 2.4. >> > Yes, included bellow. > >>> Rather than modifying existing rtdm_iomap_to_user() API a new one is >>> added, rtdm_iomap_to_user64() (to mimic mmap64()). Since >> this is a user >>> API it can not use phys_addr_t so unsigned long long is used for the >>> interface. >> 64 bit is not related to phys_addr_t. It /may/ be 64 bit, but it may >> also be less (or more one day...?). So let's switch the existing >> interface, just like the kernel does. >> >> And it is not a user API; it is used between the driver and RTDM only. >> How the driver deals with this in its user interface is a different >> story. I think there is currently no publicly available driver >> that maps >> I/O space into a user application, thus there is probably no >> stable RTDM >> profile that uses unsigned long to specify a physical address. >> > I was mislead by the function description on both accounts (only to > be used by drivers and should be called from user application via > driver, open, ioctl): > Environments: > > This service can be called from: > > * Kernel module initialization/cleanup code > * User-space task (non-RT) Yeah, this can be confusing on first sight. It describes on behalf of which calling context an RTDM driver can execute a service. > >>> I tried to use rtdm_iomap_to_user() on a kernel module initialization >>> section of my RTDM driver and passing NULL to user_info >> argument. This >>> causes an invalid memory access and system panic. How can this >>> function be called from kernel intialization code? >> Not at all. It is supposed to be called on behalf of a user >> application, >> asking the driver to map some area into its address space. >> Then you have >> a valid user_info at hand. >> >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT T DE IT 1 >> Corporate Competence Center Embedded Linux >> > > > diff --git a/include/asm-generic/system.h b/include/asm-generic/system.h > index 020e763..f2a9424 100644 > --- a/include/asm-generic/system.h > +++ b/include/asm-generic/system.h > @@ -417,7 +417,7 @@ static inline int xnarch_remap_vm_page(struct > vm_area_struct *vma, > static inline int xnarch_remap_io_page_range(struct file *filp, > struct vm_area_struct *vma, > unsigned long from, > - unsigned long to, > + phys_addr_t to, > unsigned long size, > pgprot_t prot) > { > diff --git a/include/asm-generic/wrappers.h > b/include/asm-generic/wrappers.h > index 943ed34..5dfef95 100644 > --- a/include/asm-generic/wrappers.h > +++ b/include/asm-generic/wrappers.h > @@ -400,4 +400,9 @@ static inline int wrap_raise_cap(int cap) > } > #endif /* LINUX_VERSION_CODE >= 2.6.29 */ > > +/* for Linux versions < 2.6.28 */ > +#ifndef CONFIG_PHYS_ADDR_T_64BIT > +typedef unsigned long phys_addr_t; > +#endif Let's make this cleanly depend on the kernel version, not some other define which may or may not be defined independent of this type. > + > #endif /* _XENO_ASM_GENERIC_WRAPPERS_H */ > diff --git a/include/rtdm/rtdm_driver.h b/include/rtdm/rtdm_driver.h > index 3026aff..0340de8 100644 > --- a/include/rtdm/rtdm_driver.h > +++ b/include/rtdm/rtdm_driver.h > @@ -1168,7 +1168,7 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, > struct vm_operations_struct *vm_ops, > void *vm_private_data); > int rtdm_iomap_to_user(rtdm_user_info_t *user_info, > - unsigned long src_addr, size_t len, > + phys_addr_t src_addr, size_t len, > int prot, void **pptr, > struct vm_operations_struct *vm_ops, > void *vm_private_data); > diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c > index 65c630f..525fe09 100644 > --- a/ksrc/skins/rtdm/drvlib.c > +++ b/ksrc/skins/rtdm/drvlib.c > @@ -1765,7 +1765,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); > #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) > struct rtdm_mmap_data { > void *src_vaddr; > - unsigned long src_paddr; > + phys_addr_t src_paddr; > struct vm_operations_struct *vm_ops; > void *vm_private_data; > }; > @@ -1773,14 +1773,15 @@ struct rtdm_mmap_data { > static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct > *vma) > { > struct rtdm_mmap_data *mmap_data = filp->private_data; > - unsigned long vaddr, paddr, maddr, size; > + unsigned long vaddr, maddr, size; > + phys_addr_t paddr; > int ret; > > vma->vm_ops = mmap_data->vm_ops; > vma->vm_private_data = mmap_data->vm_private_data; > > vaddr = (unsigned long)mmap_data->src_vaddr; > - paddr = (unsigned long)mmap_data->src_paddr; > + paddr = (phys_addr_t)mmap_data->src_paddr; A good chance to drop this typecast-nop (paddr and src_paddr are already of the same type). > if (!paddr) > /* kmalloc memory */ > paddr = virt_to_phys((void *)vaddr); > @@ -1982,7 +1983,7 @@ EXPORT_SYMBOL(rtdm_mmap_to_user); > * Rescheduling: possible. > */ > int rtdm_iomap_to_user(rtdm_user_info_t *user_info, > - unsigned long src_addr, size_t len, > + phys_addr_t src_addr, size_t len, > int prot, void **pptr, > struct vm_operations_struct *vm_ops, > void *vm_private_data) > > Luis Except for the minor remarks, I'm fine with the patch. Please repost in a proper format: patch subject, a short description, a signed-off, and then the diff. Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Xenomai-core] [PATCH] rtdm: Extend rtdm_iomap_to_user to map phys addr > 4G 2009-11-20 10:35 ` Jan Kiszka @ 2009-11-20 16:41 ` Herrera-Bendezu, Luis 2009-11-21 8:43 ` Jan Kiszka 0 siblings, 1 reply; 18+ messages in thread From: Herrera-Bendezu, Luis @ 2009-11-20 16:41 UTC (permalink / raw) To: Jan Kiszka; +Cc: xenomai-core rtdm_iomap_to_user does not handle I/O memory mapping of physical I/O address grater than 4 GB. This patch changes the src_addr argument and underlying code to handle this case. Signed-off-by: Luis Herrera-Bendezu <lherrera@domain.hid> --- diff --git a/include/asm-generic/system.h b/include/asm-generic/system.h index 020e763..f2a9424 100644 --- a/include/asm-generic/system.h +++ b/include/asm-generic/system.h @@ -417,7 +417,7 @@ static inline int xnarch_remap_vm_page(struct vm_area_struct *vma, static inline int xnarch_remap_io_page_range(struct file *filp, struct vm_area_struct *vma, unsigned long from, - unsigned long to, + phys_addr_t to, unsigned long size, pgprot_t prot) { diff --git a/include/asm-generic/wrappers.h b/include/asm-generic/wrappers.h index 943ed34..239eb93 100644 --- a/include/asm-generic/wrappers.h +++ b/include/asm-generic/wrappers.h @@ -400,4 +400,8 @@ static inline int wrap_raise_cap(int cap) } #endif /* LINUX_VERSION_CODE >= 2.6.29 */ +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) +typedef unsigned long phys_addr_t; +#endif + #endif /* _XENO_ASM_GENERIC_WRAPPERS_H */ diff --git a/include/rtdm/rtdm_driver.h b/include/rtdm/rtdm_driver.h index 3026aff..0340de8 100644 --- a/include/rtdm/rtdm_driver.h +++ b/include/rtdm/rtdm_driver.h @@ -1168,7 +1168,7 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, struct vm_operations_struct *vm_ops, void *vm_private_data); int rtdm_iomap_to_user(rtdm_user_info_t *user_info, - unsigned long src_addr, size_t len, + phys_addr_t src_addr, size_t len, int prot, void **pptr, struct vm_operations_struct *vm_ops, void *vm_private_data); diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c index 65c630f..8922689 100644 --- a/ksrc/skins/rtdm/drvlib.c +++ b/ksrc/skins/rtdm/drvlib.c @@ -1765,7 +1765,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) struct rtdm_mmap_data { void *src_vaddr; - unsigned long src_paddr; + phys_addr_t src_paddr; struct vm_operations_struct *vm_ops; void *vm_private_data; }; @@ -1773,14 +1773,15 @@ struct rtdm_mmap_data { static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma) { struct rtdm_mmap_data *mmap_data = filp->private_data; - unsigned long vaddr, paddr, maddr, size; + unsigned long vaddr, maddr, size; + phys_addr_t paddr; int ret; vma->vm_ops = mmap_data->vm_ops; vma->vm_private_data = mmap_data->vm_private_data; vaddr = (unsigned long)mmap_data->src_vaddr; - paddr = (unsigned long)mmap_data->src_paddr; + paddr = mmap_data->src_paddr; if (!paddr) /* kmalloc memory */ paddr = virt_to_phys((void *)vaddr); @@ -1982,7 +1983,7 @@ EXPORT_SYMBOL(rtdm_mmap_to_user); * Rescheduling: possible. */ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, - unsigned long src_addr, size_t len, + phys_addr_t src_addr, size_t len, int prot, void **pptr, struct vm_operations_struct *vm_ops, void *vm_private_data) --- ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] [PATCH] rtdm: Extend rtdm_iomap_to_user to map phys addr > 4G 2009-11-20 16:41 ` [Xenomai-core] [PATCH] rtdm: Extend rtdm_iomap_to_user to map " Herrera-Bendezu, Luis @ 2009-11-21 8:43 ` Jan Kiszka 2009-11-21 15:11 ` Herrera-Bendezu, Luis 0 siblings, 1 reply; 18+ messages in thread From: Jan Kiszka @ 2009-11-21 8:43 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai-core [-- Attachment #1: Type: text/plain, Size: 3997 bytes --] Herrera-Bendezu, Luis wrote: > rtdm_iomap_to_user does not handle I/O memory mapping of > physical I/O address grater than 4 GB. > > This patch changes the src_addr argument and underlying > code to handle this case. > > Signed-off-by: Luis Herrera-Bendezu <lherrera@domain.hid> ^^^^^^^^^^^ Something made your mail address unreadable. This is pointless (your address is already archived on this list). Moreover, we need a proper signature as a declaration that you are authorized to contribute this patch. One may argue that the patch is trivial and not "copyrightable", but we better avoid being sloppy even in that case. Besides this, the patch is unfortunately line wrap. Make sure that wrapping is switched off or use a different mailer. Thanks, Jan > --- > diff --git a/include/asm-generic/system.h b/include/asm-generic/system.h > index 020e763..f2a9424 100644 > --- a/include/asm-generic/system.h > +++ b/include/asm-generic/system.h > @@ -417,7 +417,7 @@ static inline int xnarch_remap_vm_page(struct > vm_area_struct *vma, > static inline int xnarch_remap_io_page_range(struct file *filp, > struct vm_area_struct *vma, > unsigned long from, > - unsigned long to, > + phys_addr_t to, > unsigned long size, > pgprot_t prot) > { > diff --git a/include/asm-generic/wrappers.h > b/include/asm-generic/wrappers.h > index 943ed34..239eb93 100644 > --- a/include/asm-generic/wrappers.h > +++ b/include/asm-generic/wrappers.h > @@ -400,4 +400,8 @@ static inline int wrap_raise_cap(int cap) > } > #endif /* LINUX_VERSION_CODE >= 2.6.29 */ > > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) > +typedef unsigned long phys_addr_t; > +#endif > + > #endif /* _XENO_ASM_GENERIC_WRAPPERS_H */ > diff --git a/include/rtdm/rtdm_driver.h b/include/rtdm/rtdm_driver.h > index 3026aff..0340de8 100644 > --- a/include/rtdm/rtdm_driver.h > +++ b/include/rtdm/rtdm_driver.h > @@ -1168,7 +1168,7 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, > struct vm_operations_struct *vm_ops, > void *vm_private_data); > int rtdm_iomap_to_user(rtdm_user_info_t *user_info, > - unsigned long src_addr, size_t len, > + phys_addr_t src_addr, size_t len, > int prot, void **pptr, > struct vm_operations_struct *vm_ops, > void *vm_private_data); > diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c > index 65c630f..8922689 100644 > --- a/ksrc/skins/rtdm/drvlib.c > +++ b/ksrc/skins/rtdm/drvlib.c > @@ -1765,7 +1765,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); > #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) > struct rtdm_mmap_data { > void *src_vaddr; > - unsigned long src_paddr; > + phys_addr_t src_paddr; > struct vm_operations_struct *vm_ops; > void *vm_private_data; > }; > @@ -1773,14 +1773,15 @@ struct rtdm_mmap_data { > static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct > *vma) > { > struct rtdm_mmap_data *mmap_data = filp->private_data; > - unsigned long vaddr, paddr, maddr, size; > + unsigned long vaddr, maddr, size; > + phys_addr_t paddr; > int ret; > > vma->vm_ops = mmap_data->vm_ops; > vma->vm_private_data = mmap_data->vm_private_data; > > vaddr = (unsigned long)mmap_data->src_vaddr; > - paddr = (unsigned long)mmap_data->src_paddr; > + paddr = mmap_data->src_paddr; > if (!paddr) > /* kmalloc memory */ > paddr = virt_to_phys((void *)vaddr); > @@ -1982,7 +1983,7 @@ EXPORT_SYMBOL(rtdm_mmap_to_user); > * Rescheduling: possible. > */ > int rtdm_iomap_to_user(rtdm_user_info_t *user_info, > - unsigned long src_addr, size_t len, > + phys_addr_t src_addr, size_t len, > int prot, void **pptr, > struct vm_operations_struct *vm_ops, > void *vm_private_data) > --- [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] [PATCH] rtdm: Extend rtdm_iomap_to_user to map phys addr > 4G 2009-11-21 8:43 ` Jan Kiszka @ 2009-11-21 15:11 ` Herrera-Bendezu, Luis 2009-11-23 18:32 ` Jan Kiszka 0 siblings, 1 reply; 18+ messages in thread From: Herrera-Bendezu, Luis @ 2009-11-21 15:11 UTC (permalink / raw) To: jan.kiszka; +Cc: xenomai-core Jan, Thanks for your feedback and help. Luis >-----Original Message----- >From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid >Sent: Saturday, November 21, 2009 3:43 AM >To: Herrera-Bendezu, Luis >Cc: xenomai-core >Subject: Re: [PATCH] rtdm: Extend rtdm_iomap_to_user to map >phys addr > 4G > >Herrera-Bendezu, Luis wrote: >> rtdm_iomap_to_user does not handle I/O memory mapping of >> physical I/O address grater than 4 GB. >> >> This patch changes the src_addr argument and underlying >> code to handle this case. >> >> Signed-off-by: Luis Herrera-Bendezu <lherrera@domain.hid> > ^^^^^^^^^^^ >Something made your mail address unreadable. This is pointless (your >address is already archived on this list). Moreover, we need a proper >signature as a declaration that you are authorized to contribute this >patch. One may argue that the patch is trivial and not "copyrightable", >but we better avoid being sloppy even in that case. > >Besides this, the patch is unfortunately line wrap. Make sure that >wrapping is switched off or use a different mailer. > >Thanks, >Jan rtdm_iomap_to_user does not handle I/O memory mapping of physical I/O address grater than 4 GB. This patch changes the src_addr argument and underlying code to handle this case. Signed-off-by: Luis Herrera-Bendezu <lherrera@domain.hid> --- diff --git a/include/asm-generic/system.h b/include/asm-generic/system.h index 020e763..f2a9424 100644 --- a/include/asm-generic/system.h +++ b/include/asm-generic/system.h @@ -417,7 +417,7 @@ static inline int xnarch_remap_vm_page(struct vm_area_struct *vma, static inline int xnarch_remap_io_page_range(struct file *filp, struct vm_area_struct *vma, unsigned long from, - unsigned long to, + phys_addr_t to, unsigned long size, pgprot_t prot) { diff --git a/include/asm-generic/wrappers.h b/include/asm-generic/wrappers.h index 943ed34..239eb93 100644 --- a/include/asm-generic/wrappers.h +++ b/include/asm-generic/wrappers.h @@ -400,4 +400,8 @@ static inline int wrap_raise_cap(int cap) } #endif /* LINUX_VERSION_CODE >= 2.6.29 */ +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) +typedef unsigned long phys_addr_t; +#endif + #endif /* _XENO_ASM_GENERIC_WRAPPERS_H */ diff --git a/include/rtdm/rtdm_driver.h b/include/rtdm/rtdm_driver.h index 3026aff..0340de8 100644 --- a/include/rtdm/rtdm_driver.h +++ b/include/rtdm/rtdm_driver.h @@ -1168,7 +1168,7 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, struct vm_operations_struct *vm_ops, void *vm_private_data); int rtdm_iomap_to_user(rtdm_user_info_t *user_info, - unsigned long src_addr, size_t len, + phys_addr_t src_addr, size_t len, int prot, void **pptr, struct vm_operations_struct *vm_ops, void *vm_private_data); diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c index 65c630f..8922689 100644 --- a/ksrc/skins/rtdm/drvlib.c +++ b/ksrc/skins/rtdm/drvlib.c @@ -1765,7 +1765,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) struct rtdm_mmap_data { void *src_vaddr; - unsigned long src_paddr; + phys_addr_t src_paddr; struct vm_operations_struct *vm_ops; void *vm_private_data; }; @@ -1773,14 +1773,15 @@ struct rtdm_mmap_data { static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma) { struct rtdm_mmap_data *mmap_data = filp->private_data; - unsigned long vaddr, paddr, maddr, size; + unsigned long vaddr, maddr, size; + phys_addr_t paddr; int ret; vma->vm_ops = mmap_data->vm_ops; vma->vm_private_data = mmap_data->vm_private_data; vaddr = (unsigned long)mmap_data->src_vaddr; - paddr = (unsigned long)mmap_data->src_paddr; + paddr = mmap_data->src_paddr; if (!paddr) /* kmalloc memory */ paddr = virt_to_phys((void *)vaddr); @@ -1982,7 +1983,7 @@ EXPORT_SYMBOL(rtdm_mmap_to_user); * Rescheduling: possible. */ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, - unsigned long src_addr, size_t len, + phys_addr_t src_addr, size_t len, int prot, void **pptr, struct vm_operations_struct *vm_ops, void *vm_private_data) --- ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Xenomai-core] [PATCH] rtdm: Extend rtdm_iomap_to_user to map phys addr > 4G 2009-11-21 15:11 ` Herrera-Bendezu, Luis @ 2009-11-23 18:32 ` Jan Kiszka 0 siblings, 0 replies; 18+ messages in thread From: Jan Kiszka @ 2009-11-23 18:32 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai-core [-- Attachment #1: Type: text/plain, Size: 4887 bytes --] Herrera-Bendezu, Luis wrote: > Jan, > > Thanks for your feedback and help. Merged your patch (and sent out a pull request), though the line wrapping issue persisted (manually fixed up). Your next patch to an open source project probably deserves the use of a better mail client. Jan >> -----Original Message----- >> From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid >> Sent: Saturday, November 21, 2009 3:43 AM >> To: Herrera-Bendezu, Luis >> Cc: xenomai-core >> Subject: Re: [PATCH] rtdm: Extend rtdm_iomap_to_user to map >> phys addr > 4G >> >> Herrera-Bendezu, Luis wrote: >>> rtdm_iomap_to_user does not handle I/O memory mapping of >>> physical I/O address grater than 4 GB. >>> >>> This patch changes the src_addr argument and underlying >>> code to handle this case. >>> >>> Signed-off-by: Luis Herrera-Bendezu <lherrera@domain.hid> >> ^^^^^^^^^^^ >> Something made your mail address unreadable. This is pointless (your >> address is already archived on this list). Moreover, we need a proper >> signature as a declaration that you are authorized to contribute this >> patch. One may argue that the patch is trivial and not "copyrightable", >> but we better avoid being sloppy even in that case. >> >> Besides this, the patch is unfortunately line wrap. Make sure that >> wrapping is switched off or use a different mailer. >> >> Thanks, >> Jan > > > rtdm_iomap_to_user does not handle I/O memory mapping of > physical I/O address grater than 4 GB. > > This patch changes the src_addr argument and underlying > code to handle this case. > > Signed-off-by: Luis Herrera-Bendezu <lherrera@domain.hid> > --- > diff --git a/include/asm-generic/system.h b/include/asm-generic/system.h > index 020e763..f2a9424 100644 > --- a/include/asm-generic/system.h > +++ b/include/asm-generic/system.h > @@ -417,7 +417,7 @@ static inline int xnarch_remap_vm_page(struct > vm_area_struct *vma, > static inline int xnarch_remap_io_page_range(struct file *filp, > struct vm_area_struct *vma, > unsigned long from, > - unsigned long to, > + phys_addr_t to, > unsigned long size, > pgprot_t prot) > { > diff --git a/include/asm-generic/wrappers.h > b/include/asm-generic/wrappers.h > index 943ed34..239eb93 100644 > --- a/include/asm-generic/wrappers.h > +++ b/include/asm-generic/wrappers.h > @@ -400,4 +400,8 @@ static inline int wrap_raise_cap(int cap) > } > #endif /* LINUX_VERSION_CODE >= 2.6.29 */ > > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) > +typedef unsigned long phys_addr_t; > +#endif > + > #endif /* _XENO_ASM_GENERIC_WRAPPERS_H */ > diff --git a/include/rtdm/rtdm_driver.h b/include/rtdm/rtdm_driver.h > index 3026aff..0340de8 100644 > --- a/include/rtdm/rtdm_driver.h > +++ b/include/rtdm/rtdm_driver.h > @@ -1168,7 +1168,7 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, > struct vm_operations_struct *vm_ops, > void *vm_private_data); > int rtdm_iomap_to_user(rtdm_user_info_t *user_info, > - unsigned long src_addr, size_t len, > + phys_addr_t src_addr, size_t len, > int prot, void **pptr, > struct vm_operations_struct *vm_ops, > void *vm_private_data); > diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c > index 65c630f..8922689 100644 > --- a/ksrc/skins/rtdm/drvlib.c > +++ b/ksrc/skins/rtdm/drvlib.c > @@ -1765,7 +1765,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); > #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) > struct rtdm_mmap_data { > void *src_vaddr; > - unsigned long src_paddr; > + phys_addr_t src_paddr; > struct vm_operations_struct *vm_ops; > void *vm_private_data; > }; > @@ -1773,14 +1773,15 @@ struct rtdm_mmap_data { > static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct > *vma) > { > struct rtdm_mmap_data *mmap_data = filp->private_data; > - unsigned long vaddr, paddr, maddr, size; > + unsigned long vaddr, maddr, size; > + phys_addr_t paddr; > int ret; > > vma->vm_ops = mmap_data->vm_ops; > vma->vm_private_data = mmap_data->vm_private_data; > > vaddr = (unsigned long)mmap_data->src_vaddr; > - paddr = (unsigned long)mmap_data->src_paddr; > + paddr = mmap_data->src_paddr; > if (!paddr) > /* kmalloc memory */ > paddr = virt_to_phys((void *)vaddr); > @@ -1982,7 +1983,7 @@ EXPORT_SYMBOL(rtdm_mmap_to_user); > * Rescheduling: possible. > */ > int rtdm_iomap_to_user(rtdm_user_info_t *user_info, > - unsigned long src_addr, size_t len, > + phys_addr_t src_addr, size_t len, > int prot, void **pptr, > struct vm_operations_struct *vm_ops, > void *vm_private_data) > --- [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-11-23 18:32 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-10 16:42 [Xenomai-core] rtdm_iomap_to_user with phys addr > 4GB Herrera-Bendezu, Luis
2009-11-10 17:02 ` Jan Kiszka
2009-11-10 17:58 ` Herrera-Bendezu, Luis
2009-11-10 18:13 ` Jan Kiszka
2009-11-10 18:29 ` Herrera-Bendezu, Luis
2009-11-10 18:54 ` Jan Kiszka
2009-11-10 19:20 ` Herrera-Bendezu, Luis
2009-11-10 21:21 ` Jan Kiszka
2009-11-11 12:38 ` Herrera-Bendezu, Luis
2009-11-11 14:06 ` Jan Kiszka
2009-11-11 15:40 ` Herrera-Bendezu, Luis
2009-11-18 16:00 ` [Xenomai-core] rtdm_iomap_to_user with phys addr > 4G Herrera-Bendezu, Luis
2009-11-18 16:42 ` Jan Kiszka
[not found] ` <6FCCA913376DD7488F4139A4D11B8F48FD187B@troe2k1.cs.myharris.net>
2009-11-20 10:35 ` Jan Kiszka
2009-11-20 16:41 ` [Xenomai-core] [PATCH] rtdm: Extend rtdm_iomap_to_user to map " Herrera-Bendezu, Luis
2009-11-21 8:43 ` Jan Kiszka
2009-11-21 15:11 ` Herrera-Bendezu, Luis
2009-11-23 18:32 ` Jan Kiszka
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.