Russell King <[EMAIL PROTECTED]> 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
Russell King <[EMAIL PROTECTED]> 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
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
> 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
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 fo
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
6 matches
Mail list logo
