RE: Problems with dma_mmap_writecombine on mach-pxa

RE: Problems with dma_mmap_writecombine on mach-pxa

[Frank Buss]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> Since we map the whole lot in one go, if you get one page, there's no
> reason why you shouldn't get the lot.  This is why I'm wondering if
> it has something to do with your other modifications.

my colleage has found the bug: in the function dma_mmap in 
arch/arm/mm/consistent.c the call to remap_pfn_range uses 
user_size in PAGE_SIZE units, but looks like it is expected 
in bytes. When using (user_size << PAGE_SHIFT), it works.

I don't know, where to fix it: Should the lower level calls 
get the size in bytes (most function arguments in Linux 
kernel sources are not commented), this means fixing the 
dma_mmap, or should PAGE_SIZE be used, then the lower level 
functions needs to be fixed.

-- 
Frank Buß, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

RE: Problems with dma_mmap_writecombine on mach-pxa

[Frank Buss]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> Since we map the whole lot in one go, if you get one page, there's no
> reason why you shouldn't get the lot.  This is why I'm wondering if
> it has something to do with your other modifications.

your patch works, thanks, but only for the problem with the ignored offset, 
as expected. Now I can use the original pxafb driver, but with the same 
problem: All writes from user space in the mmap'ed region after the first 
4096 bytes are ignored.

Perhaps it is not a kernel bug, but a configuration problem with the 
platform, because it is a in-house developed platform. Now a colleague is 
working on this problem and reading a book about the Linux 2.6 kernel 
details over weekend and learning how to use the kernel debugger (until now 
we have used printk and flashing new zImages every time, which is very time 
consuming). I'll post the solution next week, if we'll found one.

-- 
Frank Buß, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Re: Problems with dma_mmap_writecombine on mach-pxa

[Russell King]

On Thu, Feb 17, 2005 at 08:14:34PM +0100, Frank Buss wrote:
> > Please try this (and revert your changes):
> 
> thanks, this could fix the bug with the vm_pgoff, but I don't think this
> will fix the problem with the ignored memory access after the first
> PAGE_SIZE from the mapped memory. I'll try it tommorow, when I'm again at my
> customers site, where I have access to the board.

Since we map the whole lot in one go, if you get one page, there's no
reason why you shouldn't get the lot.  This is why I'm wondering if
it has something to do with your other modifications.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

RE: Problems with dma_mmap_writecombine on mach-pxa

[Frank Buss]

> Please try this (and revert your changes):

thanks, this could fix the bug with the vm_pgoff, but I don't think this
will fix the problem with the ignored memory access after the first
PAGE_SIZE from the mapped memory. I'll try it tommorow, when I'm again at my
customers site, where I have access to the board.

-- 
Frank Buß, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Re: Problems with dma_mmap_writecombine on mach-pxa

[Russell King]

On Thu, Feb 17, 2005 at 06:51:49PM +0100, Frank Buss wrote:
> I'm trying to use the pxafb driver on mach-pxa, but I can't mmap the
> framebuffer memory. I can access it from the driver, filling the entire
> screen, but when I access the pointer returned from mmap from a user space
> program, the following two things happens:
> 
> - the vm_pgoff is ignored and I get the start of the internal buffer, which
> caused writing to the palette and DMA descriptors
> 
> - when I change the location of the framebuffer to the start of the internal
> buffer, I can write to the screen, but only to the first 4 k; any write
> after this address is ignored, but no segfault is generated.
> 
> Any ideas what I can do to find the reason? I don't think that it is a
> kernel bug, but perhaps a wrong configuration for my platform.

Please try this (and revert your changes):

===== arch/arm/mm/consistent.c 1.27 vs edited =====
--- 1.27/arch/arm/mm/consistent.c	2005-01-21 05:02:14 +00:00
+++ edited/arch/arm/mm/consistent.c	2005-02-17 18:11:50 +00:00
@@ -284,13 +284,15 @@
 	spin_unlock_irqrestore(&consistent_lock, flags);
 
 	if (c) {
+		unsigned long off = vma->vm_pgoff;
+
 		kern_size = (c->vm_end - c->vm_start) >> PAGE_SHIFT;
 
-		if (vma->vm_pgoff < kern_size &&
-		    user_size <= (kern_size - vma->vm_pgoff)) {
+		if (off < kern_size &&
+		    user_size <= (kern_size - off)) {
 			vma->vm_flags |= VM_RESERVED;
 			ret = remap_pfn_range(vma, vma->vm_start,
-					      page_to_pfn(c->vm_pages),
+					      page_to_pfn(c->vm_pages) + off,
 					      user_size, vma->vm_page_prot);
 		}
 	}


-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Problems with dma_mmap_writecombine on mach-pxa

[Frank Buss]

I'm trying to use the pxafb driver on mach-pxa, but I can't mmap the
framebuffer memory. I can access it from the driver, filling the entire
screen, but when I access the pointer returned from mmap from a user space
program, the following two things happens:

- the vm_pgoff is ignored and I get the start of the internal buffer, which
caused writing to the palette and DMA descriptors

- when I change the location of the framebuffer to the start of the internal
buffer, I can write to the screen, but only to the first 4 k; any write
after this address is ignored, but no segfault is generated.

Any ideas what I can do to find the reason? I don't think that it is a
kernel bug, but perhaps a wrong configuration for my platform.

-- 
Frank Buß, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de