Problem in the usage of mmap command(in directFB)

Problem in the usage of mmap command(in directFB)

[kaka]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

>
> Hi All,
>
> void *mmap(void *start, size_t length, int prot, int flags,           int
> fd, off_t offset);
>
> I am providing 1.6MB as length parameter in mmap command.
> It is giving me error as Can't mmap region with error number EINVAL. I
> searched for the probable causes for EINVAL error number, and cheked it that
> i am satisfying all of them
>
> on the other hand when i am providing 1.384MB as length parameter in mmap
> command.
> It is successful.
> This mmap command is being issued from User space(from the DIrectFB code
> in systems/fbdev.c)
>
> The exact command which i am writing is
> addr = mmap(NULL, dfb_fbdev->shared->fix.mmio_len, PROT_READ | PROT_WRITE,
> MAO_SHARED, dfb_fbdev->fd, 0);
>
> Can anybody provide any clue on it?
> I want to access the mmio regs at offset (0.9MB to 1.6MB offset).
> Also in my system MIPS board(broadcom chip), the framebuffer driver
> contains support for MMIO length as 1.6MB.
>
> --
> Thanks & Regards,
> kaka
>

[-- Attachment #2: Type: text/html, Size: 1382 bytes --]

RE: Problem in the usage of mmap command(in directFB)

[Kaz Kylheku]

Dear Aptly-Named User, 

The first clue you need to get is that you shouldn't send MIME-encoded,
HTML crap to open source mailing lists. 

Repeatedly sending the same question to half a dozen mailing lists won't
solve your problem. (Everyone heard you the first N times already, and
it's unlikely that anyone new signed up within the last week who can
magically fix the failing mmap cll for you.

You have a 100% reproducible problem: no timing dependencies or race
conditions. Everytime you make the call with more than a certain size,
you nicely get this predictable EINVAL result. 

You have the source code to everything; you can add debug printk calls
anywhere you want and rebuild the kernel. If there are multiple places
that can produce an -EINVAL return value, you can precisely identify
which one is doing it.

Golly, gee, lucky you! This is like the software equivalent of taking a
shot against a wide-open net: just kick the ball!

What is missing?

RE: Problem in the usage of mmap command(in directFB)

[Kaz Kylheku]

Dear Aptly-Named User, 

The first clue you need to get is that you shouldn't send MIME-encoded,
HTML crap to open source mailing lists. 

Repeatedly sending the same question to half a dozen mailing lists won't
solve your problem. (Everyone heard you the first N times already, and
it's unlikely that anyone new signed up within the last week who can
magically fix the failing mmap cll for you.

You have a 100% reproducible problem: no timing dependencies or race
conditions. Everytime you make the call with more than a certain size,
you nicely get this predictable EINVAL result. 

You have the source code to everything; you can add debug printk calls
anywhere you want and rebuild the kernel. If there are multiple places
that can produce an -EINVAL return value, you can precisely identify
which one is doing it.

Golly, gee, lucky you! This is like the software equivalent of taking a
shot against a wide-open net: just kick the ball!

What is missing?

Re: Problem in the usage of mmap command(in directFB)

[Ralf Baechle]

On Thu, Nov 29, 2007 at 05:51:26PM -0800, Kaz Kylheku wrote:

> Dear Aptly-Named User, 
> 
> The first clue you need to get is that you shouldn't send MIME-encoded,
> HTML crap to open source mailing lists. 

Linux-mips is configured to bin HTML email.  No prisoners.  It's been
amazingly effective at more than just the spam problem, also zero
maintenance unlike the other approaches to the HTML plague.

  Ralf