From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bay0-omc2-s25.bay0.hotmail.com (bay0-omc2-s25.bay0.hotmail.com [65.54.246.161]) by ozlabs.org (Postfix) with ESMTP id 03637DE17F for ; Fri, 9 May 2008 01:33:08 +1000 (EST) Message-ID: Content-Type: multipart/alternative; boundary="_85d97792-c533-49c7-9c61-1e8dda54c0d3_" From: MingLiu To: Subject: mmap problem in device driver and application program. Date: Thu, 8 May 2008 15:33:06 +0000 MIME-Version: 1.0 List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --_85d97792-c533-49c7-9c61-1e8dda54c0d3_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dear all, I had some problem when I use mmap() file operation in the device driver file operation. My situation can be described as: 1. I reserve 2MB DDR memory as a look-up-table (LUT) for my customized device. The physical start address in the memory is 0x03000000 and the size is 2MB. 2. In the device driver, I use mmap file operation to make this memory area directly accessible by application programs. In the mmap file operation, it looks like: if(remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, vma->vm_end - vma->vm_start, vma->vm_page_prot)){ return -EAGAIN; } 3. In the application program, I read from a file and initialize the LUT area. I use the following sentence to mmap the physical address into a virtual one which could be accessed by the application: // the physical address is from 0x03000000 with a size of LUT_SIZE_IN_BYTE equal to 2MB lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x03000000); Then, I initialize the LUT area with the virtual address specified by lut_mem_base. for(i=0;;i++){ fread(&buf, sizeof(unsigned int), 1, fp); *(lut_mem_base + i) = buf; if(feop(fp)){ break; } } 4. After the initialization of the LUT memory area, in the device driver, DMA transfer will be enabled using the physical address of 0x03000000 as the source address. The destination is a register in my customized device. The data is fed from the memory to my device register. HOWEVER, I found that the data fed to the device register is not the same as the one used to initialize the LUT memory. Maybe the DMA fetches wrong data from different addresses and feeds to my device. Since this is my first time to use mmap, I am not self-confident to my program, both in the device driver and in the application. Is there anything wrong with my mmap part? I will appreciate so much if some experts could give me some hints. Thanks in advance. BR Ming _________________________________________________________________ 用手机MSN聊天写邮件看空间，无限沟通，分享精彩！ http://mobile.msn.com.cn/ --_85d97792-c533-49c7-9c61-1e8dda54c0d3_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Dear all,
I had some problem when I use mmap() file operation in the device driver file operation. My situation can be described as:
 
1. I reserve 2MB DDR memory as a look-up-table (LUT) for my customized device. The physical start address in the memory is 0x03000000 and the size is 2MB.
 
2. In the device driver, I use mmap file operation to make this memory area directly accessible by application programs. In the mmap file operation, it looks like:
 
  if(remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, vma->vm_end - vma->vm_start, vma->vm_page_prot)){
     return -EAGAIN;
   }
 
3. In the application program, I read from a file and initialize the LUT area. I use the following sentence to mmap the physical address into a virtual one which could be accessed by the application:
 
  // the physical address is from 0x03000000 with a size of LUT_SIZE_IN_BYTE equal to 2MB
  lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x03000000);
 
Then, I initialize the LUT area with the virtual address specified by lut_mem_base.
 
  for(i=0;;i++){
    fread(&buf, sizeof(unsigned int), 1, fp);
    *(lut_mem_base + i) = buf;
    if(feop(fp)){
       break;
    }
  }
 
4. After the initialization of the LUT memory area, in the device driver, DMA transfer will be enabled using the physical address of 0x03000000 as the source address. The destination is a register in my customized device. The data is fed from the memory to my device register.
 
HOWEVER, I found that the data fed to the device register is not the same as the one used to initialize the LUT memory. Maybe the DMA fetches wrong data from different addresses and feeds to my device. Since this is my first time to use mmap, I am not self-confident to my program, both in the device driver and in the application. Is there anything wrong with my mmap part? I will appreciate so much if some experts could give me some hints. Thanks in advance.
 
BR
Ming
 
 
 
 
 
 

Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！ --_85d97792-c533-49c7-9c61-1e8dda54c0d3_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from que11.charter.net (que11.charter.net [209.225.8.21]) by ozlabs.org (Postfix) with ESMTP id 8F927DDFAB for ; Fri, 9 May 2008 03:40:53 +1000 (EST) Received: from aarprv04.charter.net ([10.20.200.74]) by mta11.charter.net (InterMail vM.7.08.03.00 201-2186-126-20070710) with ESMTP id <20080508170143.IYH5653.mta11.charter.net@aarprv04.charter.net> for ; Thu, 8 May 2008 13:01:43 -0400 Received: from [192.168.1.32] (really [71.93.35.174]) by aarprv04.charter.net with ESMTP id <20080508170142.NBER4495.aarprv04.charter.net@[192.168.1.32]> for ; Thu, 8 May 2008 13:01:42 -0400 Subject: Re: mmap problem in device driver and application program. From: Dave Cogley To: linuxppc-embedded@ozlabs.org In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Date: Thu, 08 May 2008 10:01:49 -0700 Message-Id: <1210266109.3755.8.camel@localhost.localdomain> Mime-Version: 1.0 List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , The address you are passing to mmap is where the pointer will be mapped in virtual address space. You need to determine the DMA memory address page number down in the actual mmap call. int foo_mmap(struct file* filep, struct vm_area_struct* vma) { unsigned long dma_addr = 0x03000000; unsigned long dma_size = 0x00200000; unsigned long pfn; // convert the DMA address to page number pfn = virt_to_phys(dma_addr) >> PAGE_SHIFT; // remap our page frame to the vma offset remap_pfn_range(vma, vma->vm_start, pfn, dma_size, vma->vm_page_prot); } Change the address parameter from 0x03000000 to 0: lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); Dave On Thu, 2008-05-08 at 15:33 +0000, MingLiu wrote: > Dear all, > I had some problem when I use mmap() file operation in the device > driver file operation. My situation can be described as: > > 1. I reserve 2MB DDR memory as a look-up-table (LUT) for my customized > device. The physical start address in the memory is 0x03000000 and the > size is 2MB. > > 2. In the device driver, I use mmap file operation to make this memory > area directly accessible by application programs. In the mmap file > operation, it looks like: > > if(remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, vma->vm_end - > vma->vm_start, vma->vm_page_prot)){ > return -EAGAIN; > } > > 3. In the application program, I read from a file and initialize the > LUT area. I use the following sentence to mmap the physical address > into a virtual one which could be accessed by the application: > > // the physical address is from 0x03000000 with a size of > LUT_SIZE_IN_BYTE equal to 2MB > lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, PROT_READ > | PROT_WRITE, MAP_SHARED, fd, 0x03000000); > > Then, I initialize the LUT area with the virtual address specified by > lut_mem_base. > > for(i=0;;i++){ > fread(&buf, sizeof(unsigned int), 1, fp); > *(lut_mem_base + i) = buf; > if(feop(fp)){ > break; > } > } > > 4. After the initialization of the LUT memory area, in the device > driver, DMA transfer will be enabled using the physical address of > 0x03000000 as the source address. The destination is a register in my > customized device. The data is fed from the memory to my device > register. > > HOWEVER, I found that the data fed to the device register is not the > same as the one used to initialize the LUT memory. Maybe the DMA > fetches wrong data from different addresses and feeds to my device. > Since this is my first time to use mmap, I am not self-confident to my > program, both in the device driver and in the application. Is there > anything wrong with my mmap part? I will appreciate so much if some > experts could give me some hints. Thanks in advance. > > BR > Ming > > > > > > > > > ______________________________________________________________________ > Windows Live Writer锛屾敮鎸佺绾挎挵鍐欏崥瀹㈠唴瀹癸紝闅忔椂闅忓湴鎯冲啓灏卞啓銆 绔嬪嵆浣 > 鐢紒 > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bay0-omc3-s37.bay0.hotmail.com (bay0-omc3-s37.bay0.hotmail.com [65.54.246.237]) by ozlabs.org (Postfix) with ESMTP id 9A782DDE45 for ; Fri, 9 May 2008 04:42:12 +1000 (EST) Message-ID: Content-Type: multipart/alternative; boundary="_9477b6e8-e42b-4bc8-bc0d-67739e52e665_" From: MingLiu To: Dave Cogley , Subject: RE: mmap problem in device driver and application program. Date: Thu, 8 May 2008 18:42:10 +0000 In-Reply-To: <1210266109.3755.8.camel@localhost.localdomain> References: <1210266109.3755.8.camel@localhost.localdomain> MIME-Version: 1.0 List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --_9477b6e8-e42b-4bc8-bc0d-67739e52e665_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dear Dave, Thanks for your answer first. However I am very confused. It seems that I understand the memory-mapping-related functions completely wrong. Here comes more questions. > The address you are passing to mmap is where the pointer will be mapped> in virtual address space. You need to determine the DMA memory address> page number down in the actual mmap call.> > int foo_mmap(struct file* filep, struct vm_area_struct* vma)> {> unsigned long dma_addr = 0x03000000;> unsigned long dma_size = 0x00200000;> unsigned long pfn;> > // convert the DMA address to page number> pfn = virt_to_phys(dma_addr) >> PAGE_SHIFT; Shall I use virt_to_phys? dma_addr is already exactly physical address which is used to initiate DMA transfers. > // remap our page frame to the vma offset> remap_pfn_range(vma, vma->vm_start, pfn, > dma_size, vma->vm_page_prot);> }> > Change the address parameter from 0x03000000 to 0:> > lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, > PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); Previously I used "remap_page_range(vma, vma->vm_start, physical_addr, vm_size, vma->vm_page_prot)" in the device driver, where physical_addr is 0x03000000. In the application program, I used "lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);". I think it is correct but it doesn't work. I heard that in the new kernels, remap_page_range is not supported any more. However when I compile the driver, nothing was shown to complain that. I am using 2.6.10 kernel. Any hint for this? Thank you for your help to make me understand. BR Ming _________________________________________________________________ Windows Live Photo gallery 数码相机的超级伴侣，轻松管理和编辑照片，还能制作全景美图！ http://get.live.cn/product/photo.html --_9477b6e8-e42b-4bc8-bc0d-67739e52e665_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Dear Dave,
 
Thanks for your answer first. However I am very confused. It seems that I understand the memory-mapping-related functions completely wrong. Here comes more questions.


> The address you are passing to mmap is where the pointer will be mapped
> in virtual address space. You need to determine the DMA memory address
> page number down in the actual mmap call.
>
> int foo_mmap(struct file* filep, struct vm_area_struct* vma)
> {
> unsigned long dma_addr = 0x03000000;
> unsigned long dma_size = 0x00200000;
> unsigned long pfn;
>
> // convert the DMA address to page number
> pfn = virt_to_phys(dma_addr) >> PAGE_SHIFT;

Shall I use virt_to_phys? dma_addr is already exactly physical address which is used to initiate DMA transfers.
 
> // remap our page frame to the vma offset
> remap_pfn_range(vma, vma->vm_start, pfn,
> dma_size, vma->vm_page_prot);
> }
>
> Change the address parameter from 0x03000000 to 0:
>
> lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE,
> PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

Previously I used "remap_page_range(vma, vma->vm_start, physical_addr, vm_size, vma->vm_page_prot)" in the device driver, where physical_addr is 0x03000000. In the application program, I used "lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);". I think it is correct but it doesn't work. I heard that in the new kernels, remap_page_range is not supported any more. However when I compile the driver, nothing was shown to complain that. I am using 2.6.10 kernel. Any hint for this?
 
Thank you for your help to make me understand.
 
BR
Ming

使用新一代 Windows Live Messenger 轻松交流和共享！ 立即体验！ --_9477b6e8-e42b-4bc8-bc0d-67739e52e665_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta21.charter.net (mta21.charter.net [216.33.127.81]) by ozlabs.org (Postfix) with ESMTP id 40729DDF45 for ; Sat, 10 May 2008 06:55:54 +1000 (EST) Received: from aarprv04.charter.net ([10.20.200.74]) by mta21.charter.net (InterMail vM.7.08.03.00 201-2186-126-20070710) with ESMTP id <20080509205542.DOWT23078.mta21.charter.net@aarprv04.charter.net> for ; Fri, 9 May 2008 16:55:42 -0400 Received: from [192.168.1.32] (really [71.93.35.174]) by aarprv04.charter.net with ESMTP id <20080509205542.IMPC4495.aarprv04.charter.net@[192.168.1.32]> for ; Fri, 9 May 2008 16:55:42 -0400 Subject: RE: mmap problem in device driver and application program. From: Dave Cogley To: linuxppc-embedded@ozlabs.org In-Reply-To: References: <1210266109.3755.8.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Date: Fri, 09 May 2008 13:55:52 -0700 Message-Id: <1210366552.3755.21.camel@localhost.localdomain> Mime-Version: 1.0 List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > Shall I use virt_to_phys? dma_addr is already exactly physical address > which is used to initiate DMA transfers. Is the physical memory outside of the reach of the kernel? If it is under control of the kernel memory management you will need to ioremap it. This will return a kernel virtual address which will need to be converted to a physical address and further convert to a page number. remap_pfn_range only works on page numbers not physical addresses. So I guess it would look something like this: int foo_mmap(struct file* filep, struct vm_area_struct* vma) { unsigned long dma_addr = ioremap(0x03000000); unsigned long dma_size = 0x00200000; unsigned long pfn; // convert the DMA address to page number pfn = virt_to_phys(dma_addr) >> PAGE_SHIFT; ... } If you are using memory that is not under the kernel's memory management you will need to use something other than remap_pfn_range. Dave On Thu, 2008-05-08 at 18:42 +0000, MingLiu wrote: > Dear Dave, > > Thanks for your answer first. However I am very confused. It seems > that I understand the memory-mapping-related functions completely > wrong. Here comes more questions. > > > > The address you are passing to mmap is where the pointer will be > mapped > > in virtual address space. You need to determine the DMA memory > address > > page number down in the actual mmap call. > > > > int foo_mmap(struct file* filep, struct vm_area_struct* vma) > > { > > unsigned long dma_addr = 0x03000000; > > unsigned long dma_size = 0x00200000; > > unsigned long pfn; > > > > // convert the DMA address to page number > > pfn = virt_to_phys(dma_addr) >> PAGE_SHIFT; > > Shall I use virt_to_phys? dma_addr is already exactly physical address > which is used to initiate DMA transfers. > > > // remap our page frame to the vma offset > > remap_pfn_range(vma, vma->vm_start, pfn, > > dma_size, vma->vm_page_prot); > > } > > > > Change the address parameter from 0x03000000 to 0: > > > > lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, > > PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > > Previously I used "remap_page_range(vma, vma->vm_start, physical_addr, > vm_size, vma->vm_page_prot)" in the device driver, where physical_addr > is 0x03000000. In the application program, I used "lut_mem_base = > (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, PROT_READ | PROT_WRITE, > MAP_SHARED, fd, 0);". I think it is correct but it doesn't work. I > heard that in the new kernels, remap_page_range is not supported any > more. However when I compile the driver, nothing was shown to complain > that. I am using 2.6.10 kernel. Any hint for this? > > Thank you for your help to make me understand. > > BR > Ming > > > ______________________________________________________________________ > 浣跨敤鏂颁竴浠 Windows Live Messenger 杞绘澗浜ゆ祦鍜屽叡浜紒 绔嬪嵆浣撻獙锛 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bay0-omc3-s30.bay0.hotmail.com (bay0-omc3-s30.bay0.hotmail.com [65.54.246.230]) by ozlabs.org (Postfix) with ESMTP id AED44DDE11 for ; Tue, 13 May 2008 19:11:52 +1000 (EST) Message-ID: Content-Type: multipart/alternative; boundary="_427c7534-89fb-4e9b-89fd-fcb20860152c_" From: MingLiu To: Dave Cogley , Subject: RE: mmap problem in device driver and application program. Date: Tue, 13 May 2008 09:11:50 +0000 In-Reply-To: <1210366552.3755.21.camel@localhost.localdomain> References: <1210266109.3755.8.camel@localhost.localdomain> <1210366552.3755.21.camel@localhost.localdomain> MIME-Version: 1.0 List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --_427c7534-89fb-4e9b-89fd-fcb20860152c_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dear Dave, > If you are using memory that is not under the kernel's memory management> you will need to use something other than remap_pfn_range.> Happenly and unfortunately we are using the memory space out of the control from the kernel. We have 2GB memory on the board and only 64(or 32) MB is reserved for the kernel. The rest large space is for the data buffering or LUT use. In my question, the LUT memory is located in the rest part rather than the kernel memory area. Any more suggestion on how to mmap this LUT area? Any idea will be valuable for a beginner like me. Thanks in advance. BR Ming _________________________________________________________________ 新年换新颜，快来妆扮自己的MSN给心仪的TA一个惊喜！ http://im.live.cn/emoticons/?ID=18 --_427c7534-89fb-4e9b-89fd-fcb20860152c_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Dear Dave,

> If you are using memory that is not under the kernel's memory management
> you will need to use something other than remap_pfn_range.
>

Happenly and unfortunately we are using the memory space out of the control from the kernel. We have 2GB memory on the board and only 64(or 32) MB is reserved for the kernel. The rest large space is for the data buffering or LUT use. In my question, the LUT memory is located in the rest part rather than the kernel memory area.
 
Any more suggestion on how to mmap this LUT area? Any idea will be valuable for a beginner like me. Thanks in advance.
 
BR
Ming

“七件武器，七种完美” 立刻体验！ --_427c7534-89fb-4e9b-89fd-fcb20860152c_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ca1mail04.kla-tencor.com (mailout04.kla-tencor.com [192.146.1.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B4B48DE0C6 for ; Wed, 14 May 2008 04:31:38 +1000 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B521.FAD32472" Subject: RE: mmap problem in device driver and application program. Date: Tue, 13 May 2008 10:51:31 -0700 Message-ID: <921B6E79C3E18642BFFC1C8633C430DBCBDDBE@CA1EXCLV07.adcorp.kla-tencor.com> In-Reply-To: References: <1210266109.3755.8.camel@localhost.localdomain> <1210366552.3755.21.camel@localhost.localdomain> From: "Howard, Marc" To: "MingLiu" , "Dave Cogley" , List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B521.FAD32472 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable =20 Dear Dave, =09 > If you are using memory that is not under the kernel's memory = management > you will need to use something other than remap_pfn_range. >=20 =09 Happenly and unfortunately we are using the memory space out of the = control from the kernel. We have 2GB memory on the board and only 64(or = 32) MB is reserved for the kernel. The rest large space is for the data = buffering or LUT use. In my question, the LUT memory is located in the = rest part rather than the kernel memory area.=20 =20 Any more suggestion on how to mmap this LUT area? Any idea will be = valuable for a beginner like me. Thanks in advance.=20 =20 BR Ming =09 =09 ________________________________ =A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 = =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1 =20 I have a similar setup where the upper 64MB are reserved for hardware. = The mmap implementation in my device driver works just fine using = io_remap_page_range(). =20 Marc Howard =20 ------_=_NextPart_001_01C8B521.FAD32472 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
Dear Dave,

> If you are using memory that is not under = the=20 kernel's memory management
> you will need to use something = other than=20 remap_pfn_range.
>

Happenly and unfortunately we are = using the=20 memory space out of the control from the kernel. We have 2GB memory on = the=20 board and only 64(or 32) MB is reserved for the kernel. The rest large = space=20 is for the data buffering or LUT use. In my question, the LUT memory = is=20 located in the rest part rather than the kernel memory area. =
 
Any=20 more suggestion on how to mmap this LUT area? Any idea will be = valuable for a=20 beginner like me. Thanks in advance. =
 
BR
Ming

=
=A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 = =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1  
I have = a similar=20 setup where the upper 64MB are reserved for hardware.  The mmap=20 implementation in my device driver works just fine using=20 io_remap_page_range().
 
Marc=20 Howard
 
------_=_NextPart_001_01C8B521.FAD32472-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from kirk.dutchspace.nl (kirk.dutchspace.nl [193.200.147.14]) by ozlabs.org (Postfix) with ESMTP id 2A16EDDE0E for ; Wed, 14 May 2008 16:28:13 +1000 (EST) Message-ID: <482A8446.2030309@dutchspace.nl> Date: Wed, 14 May 2008 08:18:46 +0200 From: Johan Borkhuis MIME-Version: 1.0 To: MingLiu Subject: Re: mmap problem in device driver and application program. References: <1210266109.3755.8.camel@localhost.localdomain> <1210366552.3755.21.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=GB2312 Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MingLiu wrote: > Dear Dave, > >> If you are using memory that is not under the kernel's memory management> you will need to use something other than remap_pfn_range.> >> > Happenly and unfortunately we are using the memory space out of the control from the kernel. We have 2GB memory on the board and only 64(or 32) MB is reserved for the kernel. The rest large space is for the data buffering or LUT use. In my question, the LUT memory is located in the rest part rather than the kernel memory area. > > Any more suggestion on how to mmap this LUT area? Any idea will be valuable for a beginner like me. Thanks in advance. > If this is physical memory that is not controlled by the kernel you could also use the /dev/mem device. You could do something like: memFd = open("/dev/mem", O_RDWR); memBuf = mmap(0, , PROT_READ | PROT_WRITE, MAP_SHARED, memFd, Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by ozlabs.org (Postfix) with ESMTP id 81974DDFDF for ; Mon, 26 May 2008 20:08:46 +1000 (EST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1K0ZdC-00054L-1S for linuxppc-embedded@ozlabs.org; Mon, 26 May 2008 03:08:42 -0700 Message-ID: <17469128.post@talk.nabble.com> Date: Mon, 26 May 2008 03:08:42 -0700 (PDT) From: Misbah khan To: linuxppc-embedded@ozlabs.org Subject: RE: mmap problem in device driver and application program. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 References: <1210266109.3755.8.camel@localhost.localdomain> <1210366552.3755.21.camel@localhost.localdomain> List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi ... I guess you can remap the memory region outside the kernel control and then convert it into page and use it into your mmap implementation in the driver else it is easy to use the same in application by opening /dev/mmap file=20 regards=20 Misbah <>< mliu wrote: >=20 >=20 > Dear Dave, >> If you are using memory that is not under the kernel's memory management= > >> you will need to use something other than remap_pfn_range.>=20 > Happenly and unfortunately we are using the memory space out of the > control from the kernel. We have 2GB memory on the board and only 64(or > 32) MB is reserved for the kernel. The rest large space is for the data > buffering or LUT use. In my question, the LUT memory is located in the > rest part rather than the kernel memory area.=20 > =20 > Any more suggestion on how to mmap this LUT area? Any idea will be > valuable for a beginner like me. Thanks in advance.=20 > =20 > BR > Ming > _________________________________________________________________ > =E6=96=B0=E5=B9=B4=E6=8D=A2=E6=96=B0=E9=A2=9C=EF=BC=8C=E5=BF=AB=E6=9D=A5= =E5=A6=86=E6=89=AE=E8=87=AA=E5=B7=B1=E7=9A=84MSN=E7=BB=99=E5=BF=83=E4=BB=AA= =E7=9A=84TA=E4=B8=80=E4=B8=AA=E6=83=8A=E5=96=9C=EF=BC=81 > http://im.live.cn/emoticons/?ID=3D18 > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >=20 --=20 View this message in context: http://www.nabble.com/mmap-problem-in-device-= driver-and-application-program.-tp17130303p17469128.html Sent from the linuxppc-embedded mailing list archive at Nabble.com.