[patch] VRAM detection in controlfb

Michel Lanners mlan at cpu.lu
Wed Jun 7 07:52:31 EST 2000


Hi there,

On   6 Jun, this message from Michael Schmitz echoed through cyberspace:
>> > > Probably XF4 handles fix.smem_start being not on a page boundary
>> > > incorrectly.
>> >
>> > What would it have to do to handle it?
>>
>> Round down smem_start and mmap() it, and readd the offset. Cfr.
>>
>>     addr = (unsigned long)mmap(NULL, ati_smem_len, PROT_READ | PROT_WRITE,
>> 				MAP_SHARED, fb_fd, 0);
>>
>>     ati_smem = addr+ati_smem_offset;
>
> Basically what we do in fbdev.c since two years or so (first happened on
> Mac68k). But I don't think that's it: mmap would have barfed if you feed
> it a start address that isn't page aligned.

How about incorrect rounding? Here is what I see (in ASCII art ;-):

  Pixel (168,-1)                      (0,-1)(0,0)    Pixel (167,0)
  *----------------------------------------**-----------------*
  |                                        ||                 |

I _think_ it starts with line -1, and not line 0. I could be wrong...
There could be an aliased region of VRAM just below framebuffer start...

Entire diplay width is 1152 pixels à 32 bit. So there are 1152-168=984
pixels on screen that are below pixel (0,0) in memory. The offset
between fb address 0 and pixel (0,0) is 80 bytes in this mode. 984
pixels are 964*4=3936 bytes. If you look closely, offset plus
displacement is just 80 bytes (offset again...) below the next page
boundary:
		80 + 3936 = 4016 = 4096 - 80

Bug in my calculation or XF4's?

> Maybe a timing problem with the monitor?

No, because both halves of the display fit together without sync
artefacts.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan at cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/





More information about the Linuxppc-dev mailing list