Thread (14 messages) 14 messages, 5 authors, 2004-12-02

Re: [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: [Linux-fbdev-devel] why does radeonfb work fine in 2.6, but not in 2.4.29-pre1?]

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2004-12-01 21:27:36
Also in: lkml

On Wed, 1 Dec 2004, Kronos wrote:
Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: 
quoted
quoted
Make fb layer aware of the difference between the ioremap()'ed VRAM and
total available VRAM.
smem_len in struct fb_fix_screeninfo still contains the amount of
physical VRAM (reported to userspace via FBIOGET_FSCREENINFO ioctl) and
the new field mapped_vram contains the amount of VRAM actually
ioremap()'ed by drivers (used in read/write/mmap operations).
Since there was unused padding at the end of struct fb_fix_screeninfo
binary compatibility with userspace utilities is retained.
If mapped_vram is not set it's assumed that the entire framebuffer is
mapped, thus other drivers are unaffected by this patch.

The patch has been tested by Jurriaan [off-list ref].

Signed-off-by: Luca Tettamanti <redacted>
--- a/include/linux/fb.h	2004-11-30 18:30:08.000000000 +0100
+++ b/include/linux/fb.h	2004-11-30 18:33:00.000000000 +0100
@@ -126,7 +126,8 @@
 					/* (physical address) */
 	__u32 mmio_len;			/* Length of Memory Mapped I/O  */
 	__u32 accel;			/* Type of acceleration available */
-	__u16 reserved[3];		/* Reserved for future compatibility */
+	__u32 mapped_vram;		/* Amount of ioremap()'ed VRAM */
+	__u16 reserved[1];		/* Reserved for future compatibility */
 };
I don't really like this patch. mapped_vram doesn't matter for user space at
all, so it does not belong to fb_fix_screeninfo.
Hmm, it looked sensible to me since it's the max amount of data that
userspace can read (or write) from /dev/fb%d.
That's not really a user space limitation, but a kernel `bug'.

I.e. it could be solved in the kernel if larger ioremap()s would be allowed, or
if some sliding window mapping would be used. User space shouldn't need to know
about this.
Putting mapped_vram in fb_info would be acceptable?
That would make sure this stays in-kernel, but my other reasoning stays the
same: it's some kind of kernel bug.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help