* why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? @ 2004-11-28 18:46 ` Jurriaan 0 siblings, 0 replies; 22+ messages in thread From: Jurriaan @ 2004-11-28 18:46 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: linux-kernel The same radeonfb-setup works fine in every 2.6 kernel I can remember (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' in 2.4.29-pre1. The card has 128 Mb of ram, and my system has 3 Mb of RAM. Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? I've tried searching google for hints, but nothing has turned up. Is there any way to test 2.4 with my radeonfb and all of my memory? Thanks, Jurriaan -- proof by exhaustion: An issue or two of a journal devoted to your proof is useful. Debian (Unstable) GNU/Linux 2.6.10-rc2-mm3 2x6078 bogomips load 1.67 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? @ 2004-11-28 18:46 ` Jurriaan 0 siblings, 0 replies; 22+ messages in thread From: Jurriaan @ 2004-11-28 18:46 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: linux-kernel The same radeonfb-setup works fine in every 2.6 kernel I can remember (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' in 2.4.29-pre1. The card has 128 Mb of ram, and my system has 3 Mb of RAM. Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? I've tried searching google for hints, but nothing has turned up. Is there any way to test 2.4 with my radeonfb and all of my memory? Thanks, Jurriaan -- proof by exhaustion: An issue or two of a journal devoted to your proof is useful. Debian (Unstable) GNU/Linux 2.6.10-rc2-mm3 2x6078 bogomips load 1.67 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? 2004-11-28 18:46 ` Jurriaan @ 2004-11-29 20:27 ` Jurriaan -1 siblings, 0 replies; 22+ messages in thread From: Jurriaan @ 2004-11-29 20:27 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: linux-kernel From: Jurriaan <thunder7@xs4all.nl> Date: Sun, Nov 28, 2004 at 07:46:06PM +0100 > The same radeonfb-setup works fine in every 2.6 kernel I can remember > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > in 2.4.29-pre1. > > The card has 128 Mb of ram, and my system has 3 Mb of RAM. I mean 3 Gb, of course. Sorry about that. This means I got high memory. I'd love to know what difference 2.4 and 2.6 have in this regard. Jurriaan -- The memory management on the PowerPC can be used to frighten small children. Linus Torvalds Debian (Unstable) GNU/Linux 2.6.10-rc2-mm3 2x6078 bogomips load load 0.31 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Linux-fbdev-devel] why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? @ 2004-11-29 20:27 ` Jurriaan 0 siblings, 0 replies; 22+ messages in thread From: Jurriaan @ 2004-11-29 20:27 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: linux-kernel From: Jurriaan <thunder7@xs4all.nl> Date: Sun, Nov 28, 2004 at 07:46:06PM +0100 > The same radeonfb-setup works fine in every 2.6 kernel I can remember > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > in 2.4.29-pre1. > > The card has 128 Mb of ram, and my system has 3 Mb of RAM. I mean 3 Gb, of course. Sorry about that. This means I got high memory. I'd love to know what difference 2.4 and 2.6 have in this regard. Jurriaan -- The memory management on the PowerPC can be used to frighten small children. Linus Torvalds Debian (Unstable) GNU/Linux 2.6.10-rc2-mm3 2x6078 bogomips load load 0.31 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? 2004-11-28 18:46 ` Jurriaan @ 2004-11-29 21:35 ` Kronos -1 siblings, 0 replies; 22+ messages in thread From: Kronos @ 2004-11-29 21:35 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: Jurriaan, linux-kernel Il Sun, Nov 28, 2004 at 07:46:06PM +0100, Jurriaan ha scritto: > The same radeonfb-setup works fine in every 2.6 kernel I can remember > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > in 2.4.29-pre1. > > The card has 128 Mb of ram, and my system has 3 Mb of RAM. > > Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? Driver in 2.6 only ioremap()s the memory needed for the framebuffer, while the one in 2.4 ioremap()s all the VRAM (and fails). > Is there any way to test 2.4 with my radeonfb and all of my memory? I proposed the following patch some time ago (for 2.4.28-pre2 IIRC) as a quick fix: --- a/drivers/video/radeonfb.c 2004-06-27 22:26:56.000000000 +0200 +++ b/drivers/video/radeonfb.c 2004-06-29 19:13:24.000000000 +0200 @@ -176,7 +176,8 @@ #define RTRACE if(0) printk #endif - +#define MAX_MAPPED_VRAM (2048*2048*4) +#define MIN_MAPPED_VRAM (1024*768*1) enum radeon_chips { RADEON_QD, @@ -499,7 +500,8 @@ short chipset; unsigned char arch; - int video_ram; + unsigned int video_ram; + unsigned int mapped_vram; u8 rev; int pitch, bpp, depth; int xres, yres, pixclock; @@ -1823,8 +1825,19 @@ } } - rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, - rinfo->video_ram); + if (rinfo->video_ram < rinfo->mapped_vram) + rinfo->mapped_vram = rinfo->video_ram; + else + rinfo->mapped_vram = MAX_MAPPED_VRAM; + do { + rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, + rinfo->mapped_vram); + if (rinfo->fb_base) + break; + + rinfo->mapped_vram /= 2; + } while(rinfo->mapped_vram > MIN_MAPPED_VRAM); + if (!rinfo->fb_base) { printk ("radeonfb: cannot map FB\n"); iounmap ((void*)rinfo->mmio_base); @@ -1835,6 +1848,7 @@ kfree (rinfo); return -ENODEV; } + RTRACE(KERN_INFO "radeonfb: mapped %dk videoram\n", rinfo->mapped_vram/1024); /* currcon not yet configured, will be set by first switch */ rinfo->currcon = -1; @@ -2204,7 +2218,7 @@ printk("radeonfb: using max available virtual resolution\n"); for (i=0; modes[i].xres != -1; i++) { if (modes[i].xres * nom / den * modes[i].yres < - rinfo->video_ram / 2) + rinfo->mapped_vram / 2) break; } if (modes[i].xres == -1) { @@ -2217,15 +2231,15 @@ printk("radeonfb: virtual resolution set to max of %dx%d\n", v->xres_virtual, v->yres_virtual); } else if (v->xres_virtual == -1) { - v->xres_virtual = (rinfo->video_ram * den / + v->xres_virtual = (rinfo->mapped_vram * den / (nom * v->yres_virtual * 2)) & ~15; } else if (v->yres_virtual == -1) { v->xres_virtual = (v->xres_virtual + 15) & ~15; - v->yres_virtual = rinfo->video_ram * den / + v->yres_virtual = rinfo->mapped_vram * den / (nom * v->xres_virtual *2); } else { if (v->xres_virtual * nom / den * v->yres_virtual > - rinfo->video_ram) { + rinfo->mapped_vram) { return -EINVAL; } } @@ -2261,7 +2275,7 @@ sprintf (fix->id, "ATI Radeon %s", rinfo->name); fix->smem_start = rinfo->fb_base_phys; - fix->smem_len = rinfo->video_ram; + fix->smem_len = rinfo->mapped_vram; fix->type = disp->type; fix->type_aux = disp->type_aux; @@ -2429,6 +2443,9 @@ return -EINVAL; } + if (((v.xres_virtual * v.yres_virtual * nom) / den) > rinfo->mapped_vram) + return -EINVAL; + if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) return -EINVAL; Problem is that fix->smem_len is used both by FBIOGET_FSCREENINFO to report the amount of VRAM to userspace and by read/write/mmap on fb for bounds checking. So with my patch FBIOGET_FSCREENINFO reports mapped VRAM instead of physical VRAM. smem_len should be splitted in (say) smem_mapped (for read/write/mmap) and smem_total_vram (for FBIOGET_FSCREENINFO). I'll code something tomorrow... -ENEEDSLEEP ;) Luca -- Home: http://kronoz.cjb.net E' stato a causa di una donna che ho cominciato a bere e non ho mai avuto la cortesia di ringraziarla. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Linux-fbdev-devel] why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? @ 2004-11-29 21:35 ` Kronos 0 siblings, 0 replies; 22+ messages in thread From: Kronos @ 2004-11-29 21:35 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: Jurriaan, linux-kernel Il Sun, Nov 28, 2004 at 07:46:06PM +0100, Jurriaan ha scritto: > The same radeonfb-setup works fine in every 2.6 kernel I can remember > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > in 2.4.29-pre1. > > The card has 128 Mb of ram, and my system has 3 Mb of RAM. > > Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? Driver in 2.6 only ioremap()s the memory needed for the framebuffer, while the one in 2.4 ioremap()s all the VRAM (and fails). > Is there any way to test 2.4 with my radeonfb and all of my memory? I proposed the following patch some time ago (for 2.4.28-pre2 IIRC) as a quick fix: --- a/drivers/video/radeonfb.c 2004-06-27 22:26:56.000000000 +0200 +++ b/drivers/video/radeonfb.c 2004-06-29 19:13:24.000000000 +0200 @@ -176,7 +176,8 @@ #define RTRACE if(0) printk #endif - +#define MAX_MAPPED_VRAM (2048*2048*4) +#define MIN_MAPPED_VRAM (1024*768*1) enum radeon_chips { RADEON_QD, @@ -499,7 +500,8 @@ short chipset; unsigned char arch; - int video_ram; + unsigned int video_ram; + unsigned int mapped_vram; u8 rev; int pitch, bpp, depth; int xres, yres, pixclock; @@ -1823,8 +1825,19 @@ } } - rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, - rinfo->video_ram); + if (rinfo->video_ram < rinfo->mapped_vram) + rinfo->mapped_vram = rinfo->video_ram; + else + rinfo->mapped_vram = MAX_MAPPED_VRAM; + do { + rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, + rinfo->mapped_vram); + if (rinfo->fb_base) + break; + + rinfo->mapped_vram /= 2; + } while(rinfo->mapped_vram > MIN_MAPPED_VRAM); + if (!rinfo->fb_base) { printk ("radeonfb: cannot map FB\n"); iounmap ((void*)rinfo->mmio_base); @@ -1835,6 +1848,7 @@ kfree (rinfo); return -ENODEV; } + RTRACE(KERN_INFO "radeonfb: mapped %dk videoram\n", rinfo->mapped_vram/1024); /* currcon not yet configured, will be set by first switch */ rinfo->currcon = -1; @@ -2204,7 +2218,7 @@ printk("radeonfb: using max available virtual resolution\n"); for (i=0; modes[i].xres != -1; i++) { if (modes[i].xres * nom / den * modes[i].yres < - rinfo->video_ram / 2) + rinfo->mapped_vram / 2) break; } if (modes[i].xres == -1) { @@ -2217,15 +2231,15 @@ printk("radeonfb: virtual resolution set to max of %dx%d\n", v->xres_virtual, v->yres_virtual); } else if (v->xres_virtual == -1) { - v->xres_virtual = (rinfo->video_ram * den / + v->xres_virtual = (rinfo->mapped_vram * den / (nom * v->yres_virtual * 2)) & ~15; } else if (v->yres_virtual == -1) { v->xres_virtual = (v->xres_virtual + 15) & ~15; - v->yres_virtual = rinfo->video_ram * den / + v->yres_virtual = rinfo->mapped_vram * den / (nom * v->xres_virtual *2); } else { if (v->xres_virtual * nom / den * v->yres_virtual > - rinfo->video_ram) { + rinfo->mapped_vram) { return -EINVAL; } } @@ -2261,7 +2275,7 @@ sprintf (fix->id, "ATI Radeon %s", rinfo->name); fix->smem_start = rinfo->fb_base_phys; - fix->smem_len = rinfo->video_ram; + fix->smem_len = rinfo->mapped_vram; fix->type = disp->type; fix->type_aux = disp->type_aux; @@ -2429,6 +2443,9 @@ return -EINVAL; } + if (((v.xres_virtual * v.yres_virtual * nom) / den) > rinfo->mapped_vram) + return -EINVAL; + if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) return -EINVAL; Problem is that fix->smem_len is used both by FBIOGET_FSCREENINFO to report the amount of VRAM to userspace and by read/write/mmap on fb for bounds checking. So with my patch FBIOGET_FSCREENINFO reports mapped VRAM instead of physical VRAM. smem_len should be splitted in (say) smem_mapped (for read/write/mmap) and smem_total_vram (for FBIOGET_FSCREENINFO). I'll code something tomorrow... -ENEEDSLEEP ;) Luca -- Home: http://kronoz.cjb.net E' stato a causa di una donna che ho cominciato a bere e non ho mai avuto la cortesia di ringraziarla. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? 2004-11-29 21:35 ` [Linux-fbdev-devel] " Kronos @ 2004-11-30 6:55 ` Jurriaan -1 siblings, 0 replies; 22+ messages in thread From: Jurriaan @ 2004-11-30 6:55 UTC (permalink / raw) To: Kronos; +Cc: linux-fbdev-devel, linux-kernel From: Kronos <kronos@people.it> Date: Mon, Nov 29, 2004 at 10:35:10PM +0100 > Il Sun, Nov 28, 2004 at 07:46:06PM +0100, Jurriaan ha scritto: > > The same radeonfb-setup works fine in every 2.6 kernel I can remember > > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > > in 2.4.29-pre1. > > > > The card has 128 Mb of ram, and my system has 3 Mb of RAM. > > > > Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? > > Driver in 2.6 only ioremap()s the memory needed for the framebuffer, > while the one in 2.4 ioremap()s all the VRAM (and fails). > > > Is there any way to test 2.4 with my radeonfb and all of my memory? > > I proposed the following patch some time ago (for 2.4.28-pre2 IIRC) as a > quick fix: > Thanks. I found that patch on google. Problem is: when I look through the radeonfb in 2.6, I don't see any assignments to rinfo->video_ram that indicate it maps less than the full amount. > > Problem is that fix->smem_len is used both by FBIOGET_FSCREENINFO to > report the amount of VRAM to userspace and by read/write/mmap on fb > for bounds checking. So with my patch FBIOGET_FSCREENINFO reports mapped > VRAM instead of physical VRAM. > > smem_len should be splitted in (say) smem_mapped (for read/write/mmap) > and smem_total_vram (for FBIOGET_FSCREENINFO). I'll code something > tomorrow... -ENEEDSLEEP ;) > Thanks, Jurriaan -- All wiyht. Rho sritched mg kegtops awound? Debian (Unstable) GNU/Linux 2.6.10-rc2-mm3 2x6078 bogomips load load 0.24 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Linux-fbdev-devel] why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? @ 2004-11-30 6:55 ` Jurriaan 0 siblings, 0 replies; 22+ messages in thread From: Jurriaan @ 2004-11-30 6:55 UTC (permalink / raw) To: Kronos; +Cc: linux-fbdev-devel, linux-kernel From: Kronos <kronos@people.it> Date: Mon, Nov 29, 2004 at 10:35:10PM +0100 > Il Sun, Nov 28, 2004 at 07:46:06PM +0100, Jurriaan ha scritto: > > The same radeonfb-setup works fine in every 2.6 kernel I can remember > > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > > in 2.4.29-pre1. > > > > The card has 128 Mb of ram, and my system has 3 Mb of RAM. > > > > Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? > > Driver in 2.6 only ioremap()s the memory needed for the framebuffer, > while the one in 2.4 ioremap()s all the VRAM (and fails). > > > Is there any way to test 2.4 with my radeonfb and all of my memory? > > I proposed the following patch some time ago (for 2.4.28-pre2 IIRC) as a > quick fix: > Thanks. I found that patch on google. Problem is: when I look through the radeonfb in 2.6, I don't see any assignments to rinfo->video_ram that indicate it maps less than the full amount. > > Problem is that fix->smem_len is used both by FBIOGET_FSCREENINFO to > report the amount of VRAM to userspace and by read/write/mmap on fb > for bounds checking. So with my patch FBIOGET_FSCREENINFO reports mapped > VRAM instead of physical VRAM. > > smem_len should be splitted in (say) smem_mapped (for read/write/mmap) > and smem_total_vram (for FBIOGET_FSCREENINFO). I'll code something > tomorrow... -ENEEDSLEEP ;) > Thanks, Jurriaan -- All wiyht. Rho sritched mg kegtops awound? Debian (Unstable) GNU/Linux 2.6.10-rc2-mm3 2x6078 bogomips load load 0.24 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? 2004-11-30 6:55 ` [Linux-fbdev-devel] " Jurriaan @ 2004-11-30 17:56 ` Kronos -1 siblings, 0 replies; 22+ messages in thread From: Kronos @ 2004-11-30 17:56 UTC (permalink / raw) To: Jurriaan; +Cc: linux-fbdev-devel, linux-kernel Il Tue, Nov 30, 2004 at 07:55:55AM +0100, Jurriaan ha scritto: > From: Kronos <kronos@people.it> > Date: Mon, Nov 29, 2004 at 10:35:10PM +0100 > > Il Sun, Nov 28, 2004 at 07:46:06PM +0100, Jurriaan ha scritto: > > > The same radeonfb-setup works fine in every 2.6 kernel I can remember > > > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > > > in 2.4.29-pre1. > > > > > > The card has 128 Mb of ram, and my system has 3 Mb of RAM. > > > > > > Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? > > > > Driver in 2.6 only ioremap()s the memory needed for the framebuffer, > > while the one in 2.4 ioremap()s all the VRAM (and fails). > > > > > Is there any way to test 2.4 with my radeonfb and all of my memory? > > > > I proposed the following patch some time ago (for 2.4.28-pre2 IIRC) as a > > quick fix: > > > Thanks. I found that patch on google. Problem is: when I look through > the radeonfb in 2.6, I don't see any assignments to rinfo->video_ram > that indicate it maps less than the full amount. rinfo->video_ram is the physical ram. Look at drivers/video/aty/radeon_base.c:2200 rinfo->mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM, rinfo->video_ram); and the following loop tries to shrink the mapped area in case of ioremap() failure. Can you test the following patch (against 2.2.29-pre1)? If everything is ok I'll push to Marcelo. --- 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 */ }; /* Interpretation of offset for color fields: All offsets are from the right, --- a/drivers/video/fbmem.c 2004-11-30 18:30:00.000000000 +0100 +++ b/drivers/video/fbmem.c 2004-11-30 18:43:06.000000000 +0100 @@ -410,6 +410,7 @@ struct fb_info *info = registered_fb[fbidx]; struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -418,10 +419,12 @@ return -EINVAL; fb->fb_get_fix(&fix,PROC_CONSOLE(info), info); - if (p >= fix.smem_len) + size = fix.mapped_vram ? fix.mapped_vram : fix.smem_len; + + if (p >= size) return 0; - if (count > fix.smem_len - p) - count = fix.smem_len - p; + if (count > size - p) + count = size - p; if (count) { char *base_addr; @@ -444,6 +447,7 @@ struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; int err; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -452,11 +456,13 @@ return -EINVAL; fb->fb_get_fix(&fix, PROC_CONSOLE(info), info); - if (p > fix.smem_len) + size = fix.mapped_vram ? fix.mapped_vram : fix.smem_len; + + if (p > size) return -ENOSPC; err = 0; - if (count > fix.smem_len - p) { - count = fix.smem_len - p; + if (count > size - p) { + count = size - p; err = -ENOSPC; } if (count) { @@ -619,7 +625,10 @@ /* frame buffer memory */ start = fix.smem_start; - len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.smem_len); + if (fix.mapped_vram) + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.mapped_vram); + else + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.smem_len); if (off >= len) { /* memory mapped io */ off -= len; --- a/drivers/video/radeonfb.c 2004-11-30 18:06:45.000000000 +0100 +++ b/drivers/video/radeonfb.c 2004-11-30 18:50:25.000000000 +0100 @@ -176,7 +176,8 @@ #define RTRACE if(0) printk #endif - +#define MAX_MAPPED_VRAM (2048*2048*4) +#define MIN_MAPPED_VRAM (1024*768*1) enum radeon_chips { RADEON_QD, @@ -499,7 +500,8 @@ short chipset; unsigned char arch; - int video_ram; + unsigned int video_ram; + unsigned int mapped_vram; u8 rev; int pitch, bpp, depth; int xres, yres, pixclock; @@ -1824,8 +1826,16 @@ } } - rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, - rinfo->video_ram); + rinfo->mapped_vram = min_t(unsigned int, MAX_MAPPED_VRAM, rinfo->video_ram); + do { + rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, + rinfo->mapped_vram); + if (rinfo->fb_base) + break; + + rinfo->mapped_vram /= 2; + } while(rinfo->mapped_vram > MIN_MAPPED_VRAM); + if (!rinfo->fb_base) { printk ("radeonfb: cannot map FB\n"); iounmap ((void*)rinfo->mmio_base); @@ -1836,6 +1846,7 @@ kfree (rinfo); return -ENODEV; } + RTRACE(KERN_INFO "radeonfb: mapped %dk videoram\n", rinfo->mapped_vram/1024); /* currcon not yet configured, will be set by first switch */ rinfo->currcon = -1; @@ -2205,7 +2216,7 @@ printk("radeonfb: using max available virtual resolution\n"); for (i=0; modes[i].xres != -1; i++) { if (modes[i].xres * nom / den * modes[i].yres < - rinfo->video_ram / 2) + rinfo->mapped_vram / 2) break; } if (modes[i].xres == -1) { @@ -2218,15 +2229,15 @@ printk("radeonfb: virtual resolution set to max of %dx%d\n", v->xres_virtual, v->yres_virtual); } else if (v->xres_virtual == -1) { - v->xres_virtual = (rinfo->video_ram * den / + v->xres_virtual = (rinfo->mapped_vram * den / (nom * v->yres_virtual * 2)) & ~15; } else if (v->yres_virtual == -1) { v->xres_virtual = (v->xres_virtual + 15) & ~15; - v->yres_virtual = rinfo->video_ram * den / + v->yres_virtual = rinfo->mapped_vram * den / (nom * v->xres_virtual *2); } else { if (v->xres_virtual * nom / den * v->yres_virtual > - rinfo->video_ram) { + rinfo->mapped_vram) { return -EINVAL; } } @@ -2263,6 +2274,7 @@ fix->smem_start = rinfo->fb_base_phys; fix->smem_len = rinfo->video_ram; + fix->mapped_vram = rinfo->mapped_vram; fix->type = disp->type; fix->type_aux = disp->type_aux; @@ -2430,6 +2442,9 @@ return -EINVAL; } + if (((v.xres_virtual * v.yres_virtual * nom) / den) > rinfo->mapped_vram) + return -EINVAL; + if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) return -EINVAL; Luca -- Home: http://kronoz.cjb.net Non sempre quello che viene dopo e` progresso. Alessandro Manzoni ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Linux-fbdev-devel] why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? @ 2004-11-30 17:56 ` Kronos 0 siblings, 0 replies; 22+ messages in thread From: Kronos @ 2004-11-30 17:56 UTC (permalink / raw) To: Jurriaan; +Cc: linux-fbdev-devel, linux-kernel Il Tue, Nov 30, 2004 at 07:55:55AM +0100, Jurriaan ha scritto: > From: Kronos <kronos@people.it> > Date: Mon, Nov 29, 2004 at 10:35:10PM +0100 > > Il Sun, Nov 28, 2004 at 07:46:06PM +0100, Jurriaan ha scritto: > > > The same radeonfb-setup works fine in every 2.6 kernel I can remember > > > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > > > in 2.4.29-pre1. > > > > > > The card has 128 Mb of ram, and my system has 3 Mb of RAM. > > > > > > Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? > > > > Driver in 2.6 only ioremap()s the memory needed for the framebuffer, > > while the one in 2.4 ioremap()s all the VRAM (and fails). > > > > > Is there any way to test 2.4 with my radeonfb and all of my memory? > > > > I proposed the following patch some time ago (for 2.4.28-pre2 IIRC) as a > > quick fix: > > > Thanks. I found that patch on google. Problem is: when I look through > the radeonfb in 2.6, I don't see any assignments to rinfo->video_ram > that indicate it maps less than the full amount. rinfo->video_ram is the physical ram. Look at drivers/video/aty/radeon_base.c:2200 rinfo->mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM, rinfo->video_ram); and the following loop tries to shrink the mapped area in case of ioremap() failure. Can you test the following patch (against 2.2.29-pre1)? If everything is ok I'll push to Marcelo. --- 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 */ }; /* Interpretation of offset for color fields: All offsets are from the right, --- a/drivers/video/fbmem.c 2004-11-30 18:30:00.000000000 +0100 +++ b/drivers/video/fbmem.c 2004-11-30 18:43:06.000000000 +0100 @@ -410,6 +410,7 @@ struct fb_info *info = registered_fb[fbidx]; struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -418,10 +419,12 @@ return -EINVAL; fb->fb_get_fix(&fix,PROC_CONSOLE(info), info); - if (p >= fix.smem_len) + size = fix.mapped_vram ? fix.mapped_vram : fix.smem_len; + + if (p >= size) return 0; - if (count > fix.smem_len - p) - count = fix.smem_len - p; + if (count > size - p) + count = size - p; if (count) { char *base_addr; @@ -444,6 +447,7 @@ struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; int err; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -452,11 +456,13 @@ return -EINVAL; fb->fb_get_fix(&fix, PROC_CONSOLE(info), info); - if (p > fix.smem_len) + size = fix.mapped_vram ? fix.mapped_vram : fix.smem_len; + + if (p > size) return -ENOSPC; err = 0; - if (count > fix.smem_len - p) { - count = fix.smem_len - p; + if (count > size - p) { + count = size - p; err = -ENOSPC; } if (count) { @@ -619,7 +625,10 @@ /* frame buffer memory */ start = fix.smem_start; - len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.smem_len); + if (fix.mapped_vram) + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.mapped_vram); + else + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.smem_len); if (off >= len) { /* memory mapped io */ off -= len; --- a/drivers/video/radeonfb.c 2004-11-30 18:06:45.000000000 +0100 +++ b/drivers/video/radeonfb.c 2004-11-30 18:50:25.000000000 +0100 @@ -176,7 +176,8 @@ #define RTRACE if(0) printk #endif - +#define MAX_MAPPED_VRAM (2048*2048*4) +#define MIN_MAPPED_VRAM (1024*768*1) enum radeon_chips { RADEON_QD, @@ -499,7 +500,8 @@ short chipset; unsigned char arch; - int video_ram; + unsigned int video_ram; + unsigned int mapped_vram; u8 rev; int pitch, bpp, depth; int xres, yres, pixclock; @@ -1824,8 +1826,16 @@ } } - rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, - rinfo->video_ram); + rinfo->mapped_vram = min_t(unsigned int, MAX_MAPPED_VRAM, rinfo->video_ram); + do { + rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, + rinfo->mapped_vram); + if (rinfo->fb_base) + break; + + rinfo->mapped_vram /= 2; + } while(rinfo->mapped_vram > MIN_MAPPED_VRAM); + if (!rinfo->fb_base) { printk ("radeonfb: cannot map FB\n"); iounmap ((void*)rinfo->mmio_base); @@ -1836,6 +1846,7 @@ kfree (rinfo); return -ENODEV; } + RTRACE(KERN_INFO "radeonfb: mapped %dk videoram\n", rinfo->mapped_vram/1024); /* currcon not yet configured, will be set by first switch */ rinfo->currcon = -1; @@ -2205,7 +2216,7 @@ printk("radeonfb: using max available virtual resolution\n"); for (i=0; modes[i].xres != -1; i++) { if (modes[i].xres * nom / den * modes[i].yres < - rinfo->video_ram / 2) + rinfo->mapped_vram / 2) break; } if (modes[i].xres == -1) { @@ -2218,15 +2229,15 @@ printk("radeonfb: virtual resolution set to max of %dx%d\n", v->xres_virtual, v->yres_virtual); } else if (v->xres_virtual == -1) { - v->xres_virtual = (rinfo->video_ram * den / + v->xres_virtual = (rinfo->mapped_vram * den / (nom * v->yres_virtual * 2)) & ~15; } else if (v->yres_virtual == -1) { v->xres_virtual = (v->xres_virtual + 15) & ~15; - v->yres_virtual = rinfo->video_ram * den / + v->yres_virtual = rinfo->mapped_vram * den / (nom * v->xres_virtual *2); } else { if (v->xres_virtual * nom / den * v->yres_virtual > - rinfo->video_ram) { + rinfo->mapped_vram) { return -EINVAL; } } @@ -2263,6 +2274,7 @@ fix->smem_start = rinfo->fb_base_phys; fix->smem_len = rinfo->video_ram; + fix->mapped_vram = rinfo->mapped_vram; fix->type = disp->type; fix->type_aux = disp->type_aux; @@ -2430,6 +2442,9 @@ return -EINVAL; } + if (((v.xres_virtual * v.yres_virtual * nom) / den) > rinfo->mapped_vram) + return -EINVAL; + if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) return -EINVAL; Luca -- Home: http://kronoz.cjb.net Non sempre quello che viene dopo e` progresso. Alessandro Manzoni ^ permalink raw reply [flat|nested] 22+ messages in thread
* [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?] 2004-11-28 18:46 ` Jurriaan ` (2 preceding siblings ...) (?) @ 2004-12-01 16:14 ` Kronos 2004-12-01 16:25 ` Geert Uytterhoeven -1 siblings, 1 reply; 22+ messages in thread From: Kronos @ 2004-12-01 16:14 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: linux-fbdev-devel, linux-kernel Il Sun, Nov 28, 2004 at 07:46:06PM +0100, Jurriaan ha scritto: > The same radeonfb-setup works fine in every 2.6 kernel I can remember > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > in 2.4.29-pre1. > > The card has 128 MB of ram, and my system has 3 GB of RAM. > > Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? > > I've tried searching google for hints, but nothing has turned up. > > Is there any way to test 2.4 with my radeonfb and all of my memory? Hi Marcelo, I sent you a patch a while ago but was discarded because introduced a subtle API change. This time should be ok :) 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 <thunder7@xs4all.nl>. Signed-off-by: Luca Tettamanti <kronos@people.it> --- 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 */ }; /* Interpretation of offset for color fields: All offsets are from the right, --- a/drivers/video/fbmem.c 2004-11-30 18:30:00.000000000 +0100 +++ b/drivers/video/fbmem.c 2004-11-30 18:43:06.000000000 +0100 @@ -410,6 +410,7 @@ struct fb_info *info = registered_fb[fbidx]; struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -418,10 +419,12 @@ return -EINVAL; fb->fb_get_fix(&fix,PROC_CONSOLE(info), info); - if (p >= fix.smem_len) + size = fix.mapped_vram ? fix.mapped_vram : fix.smem_len; + + if (p >= size) return 0; - if (count > fix.smem_len - p) - count = fix.smem_len - p; + if (count > size - p) + count = size - p; if (count) { char *base_addr; @@ -444,6 +447,7 @@ struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; int err; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -452,11 +456,13 @@ return -EINVAL; fb->fb_get_fix(&fix, PROC_CONSOLE(info), info); - if (p > fix.smem_len) + size = fix.mapped_vram ? fix.mapped_vram : fix.smem_len; + + if (p > size) return -ENOSPC; err = 0; - if (count > fix.smem_len - p) { - count = fix.smem_len - p; + if (count > size - p) { + count = size - p; err = -ENOSPC; } if (count) { @@ -619,7 +625,10 @@ /* frame buffer memory */ start = fix.smem_start; - len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.smem_len); + if (fix.mapped_vram) + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.mapped_vram); + else + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.smem_len); if (off >= len) { /* memory mapped io */ off -= len; --- a/drivers/video/radeonfb.c 2004-11-30 18:06:45.000000000 +0100 +++ b/drivers/video/radeonfb.c 2004-11-30 18:50:25.000000000 +0100 @@ -176,7 +176,8 @@ #define RTRACE if(0) printk #endif - +#define MAX_MAPPED_VRAM (2048*2048*4) +#define MIN_MAPPED_VRAM (1024*768*1) enum radeon_chips { RADEON_QD, @@ -499,7 +500,8 @@ short chipset; unsigned char arch; - int video_ram; + unsigned int video_ram; + unsigned int mapped_vram; u8 rev; int pitch, bpp, depth; int xres, yres, pixclock; @@ -1824,8 +1826,16 @@ } } - rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, - rinfo->video_ram); + rinfo->mapped_vram = min_t(unsigned int, MAX_MAPPED_VRAM, rinfo->video_ram); + do { + rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, + rinfo->mapped_vram); + if (rinfo->fb_base) + break; + + rinfo->mapped_vram /= 2; + } while(rinfo->mapped_vram > MIN_MAPPED_VRAM); + if (!rinfo->fb_base) { printk ("radeonfb: cannot map FB\n"); iounmap ((void*)rinfo->mmio_base); @@ -1836,6 +1846,7 @@ kfree (rinfo); return -ENODEV; } + RTRACE(KERN_INFO "radeonfb: mapped %dk videoram\n", rinfo->mapped_vram/1024); /* currcon not yet configured, will be set by first switch */ rinfo->currcon = -1; @@ -2205,7 +2216,7 @@ printk("radeonfb: using max available virtual resolution\n"); for (i=0; modes[i].xres != -1; i++) { if (modes[i].xres * nom / den * modes[i].yres < - rinfo->video_ram / 2) + rinfo->mapped_vram / 2) break; } if (modes[i].xres == -1) { @@ -2218,15 +2229,15 @@ printk("radeonfb: virtual resolution set to max of %dx%d\n", v->xres_virtual, v->yres_virtual); } else if (v->xres_virtual == -1) { - v->xres_virtual = (rinfo->video_ram * den / + v->xres_virtual = (rinfo->mapped_vram * den / (nom * v->yres_virtual * 2)) & ~15; } else if (v->yres_virtual == -1) { v->xres_virtual = (v->xres_virtual + 15) & ~15; - v->yres_virtual = rinfo->video_ram * den / + v->yres_virtual = rinfo->mapped_vram * den / (nom * v->xres_virtual *2); } else { if (v->xres_virtual * nom / den * v->yres_virtual > - rinfo->video_ram) { + rinfo->mapped_vram) { return -EINVAL; } } @@ -2263,6 +2274,7 @@ fix->smem_start = rinfo->fb_base_phys; fix->smem_len = rinfo->video_ram; + fix->mapped_vram = rinfo->mapped_vram; fix->type = disp->type; fix->type_aux = disp->type_aux; @@ -2430,6 +2442,9 @@ return -EINVAL; } + if (((v.xres_virtual * v.yres_virtual * nom) / den) > rinfo->mapped_vram) + return -EINVAL; + if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) return -EINVAL; Luca -- Home: http://kronoz.cjb.net "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925 ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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?] 2004-12-01 16:14 ` [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?] Kronos @ 2004-12-01 16:25 ` Geert Uytterhoeven 2004-12-01 20:37 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: [Linux-fbdev-devel] " Kronos 0 siblings, 1 reply; 22+ messages in thread From: Geert Uytterhoeven @ 2004-12-01 16:25 UTC (permalink / raw) To: Linux Frame Buffer Device Development Cc: Marcelo Tosatti, Linux Kernel Development On Wed, 1 Dec 2004, Kronos wrote: > Il Sun, Nov 28, 2004 at 07:46:06PM +0100, Jurriaan ha scritto: > > The same radeonfb-setup works fine in every 2.6 kernel I can remember > > (last tested with 2.6.10-rc2-mm3) but give the dreaded 'cannot map FB' > > in 2.4.29-pre1. > > > > The card has 128 MB of ram, and my system has 3 GB of RAM. > > > > Is there any reason the ioremap() call works on 2.6, but doesn't on 2.4? > > > > I've tried searching google for hints, but nothing has turned up. > > > > Is there any way to test 2.4 with my radeonfb and all of my memory? > > I sent you a patch a while ago but was discarded because introduced a > subtle API change. This time should be ok :) > > 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 <thunder7@xs4all.nl>. > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > --- 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. 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: why does radeonfb work fine in 2.6, but not in 2.4.29-pre1?] 2004-12-01 16:25 ` Geert Uytterhoeven @ 2004-12-01 20:37 ` Kronos 0 siblings, 0 replies; 22+ messages in thread From: Kronos @ 2004-12-01 20:37 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: Marcelo Tosatti, Linux Kernel Development Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: > > 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 <thunder7@xs4all.nl>. > > > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > > > --- 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. Putting mapped_vram in fb_info would be acceptable? Luca -- Home: http://kronoz.cjb.net Carpe diem, quam minimum credula postero. (Q. Horatius Flaccus) ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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?] @ 2004-12-01 20:37 ` Kronos 0 siblings, 0 replies; 22+ messages in thread From: Kronos @ 2004-12-01 20:37 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: Marcelo Tosatti, Linux Kernel Development Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: > > 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 <thunder7@xs4all.nl>. > > > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > > > --- 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. Putting mapped_vram in fb_info would be acceptable? Luca -- Home: http://kronoz.cjb.net Carpe diem, quam minimum credula postero. (Q. Horatius Flaccus) ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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?] 2004-12-01 20:37 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: [Linux-fbdev-devel] " Kronos (?) @ 2004-12-01 21:25 ` Geert Uytterhoeven 2004-12-02 15:28 ` Kronos -1 siblings, 1 reply; 22+ messages in thread From: Geert Uytterhoeven @ 2004-12-01 21:25 UTC (permalink / raw) To: Linux Frame Buffer Device Development Cc: Marcelo Tosatti, Linux Kernel Development On Wed, 1 Dec 2004, Kronos wrote: > Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: > > > 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 <thunder7@xs4all.nl>. > > > > > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > > > > > --- 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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?] 2004-12-01 21:25 ` Geert Uytterhoeven @ 2004-12-02 15:28 ` Kronos 2004-12-02 15:39 ` Geert Uytterhoeven 0 siblings, 1 reply; 22+ messages in thread From: Kronos @ 2004-12-02 15:28 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: Marcelo Tosatti, Linux Kernel Development Il Wed, Dec 01, 2004 at 10:25:38PM +0100, Geert Uytterhoeven ha scritto: > On Wed, 1 Dec 2004, Kronos wrote: > > Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: > > > > 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 <thunder7@xs4all.nl>. > > > > > > > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > > > > > > > --- 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. I see you point, but users see that their video board does not work if the system has 1GB (or more) of RAM and they aren't happy. With current VM split (ie. 1GB/3GB) and with that much RAM there's no space left to map the entire FB. And AFAIK VM hacking in 2.4 is not doable (not that I would be able to do it ;) > > 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. What about this one: Make fb layer aware of the difference between the ioremap()'ed VRAM and total available VRAM. smem_len in struct fb_fix_screeninfo contains the amount of physical VRAM (reported to userspace via FBIOGET_FSCREENINFO ioctl) while the new field mapped_vram in struct fb_info contains the amount of VRAM actually ioremap()'ed by drivers (used in read/write/mmap operations). If mapped_vram is not set it's assumed that the entire framebuffer is mapped, thus other drivers are unaffected by this patch. Signed-off-by: Luca Tettamanti <kronos@people.it> --- a/include/linux/fb.h 2004-11-30 18:30:08.000000000 +0100 +++ b/include/linux/fb.h 2004-12-02 14:20:50.000000000 +0100 @@ -323,6 +323,7 @@ struct fb_cmap cmap; /* Current cmap */ struct fb_ops *fbops; char *screen_base; /* Virtual address */ + unsigned int mapped_vram; /* ioremap()'ed VRAM */ struct display *disp; /* initial display variable */ struct vc_data *display_fg; /* Console visible on this display */ char fontname[40]; /* default font name */ --- a/drivers/video/fbmem.c 2004-11-30 18:30:00.000000000 +0100 +++ b/drivers/video/fbmem.c 2004-12-02 14:29:44.000000000 +0100 @@ -410,6 +410,7 @@ struct fb_info *info = registered_fb[fbidx]; struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -418,10 +419,12 @@ return -EINVAL; fb->fb_get_fix(&fix,PROC_CONSOLE(info), info); - if (p >= fix.smem_len) + size = info->mapped_vram ? info->mapped_vram : fix.smem_len; + + if (p >= size) return 0; - if (count > fix.smem_len - p) - count = fix.smem_len - p; + if (count > size - p) + count = size - p; if (count) { char *base_addr; @@ -444,6 +447,7 @@ struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; int err; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -452,11 +456,13 @@ return -EINVAL; fb->fb_get_fix(&fix, PROC_CONSOLE(info), info); - if (p > fix.smem_len) + size = info->mapped_vram ? info->mapped_vram : fix.smem_len; + + if (p > size) return -ENOSPC; err = 0; - if (count > fix.smem_len - p) { - count = fix.smem_len - p; + if (count > size - p) { + count = size - p; err = -ENOSPC; } if (count) { @@ -619,7 +625,10 @@ /* frame buffer memory */ start = fix.smem_start; - len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.smem_len); + if (info->mapped_vram) + len = PAGE_ALIGN((start & ~PAGE_MASK) + info->mapped_vram); + else + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.smem_len); if (off >= len) { /* memory mapped io */ off -= len; --- a/drivers/video/radeonfb.c 2004-11-30 18:06:45.000000000 +0100 +++ b/drivers/video/radeonfb.c 2004-12-02 14:28:10.000000000 +0100 @@ -176,7 +176,8 @@ #define RTRACE if(0) printk #endif - +#define MAX_MAPPED_VRAM (2048*2048*4) +#define MIN_MAPPED_VRAM (1024*768*1) enum radeon_chips { RADEON_QD, @@ -499,7 +500,7 @@ short chipset; unsigned char arch; - int video_ram; + unsigned int video_ram; u8 rev; int pitch, bpp, depth; int xres, yres, pixclock; @@ -1626,6 +1627,7 @@ const struct pci_device_id *ent) { struct radeonfb_info *rinfo; + struct fb_info *fb_info; struct radeon_chip_info *rci = &radeon_chip_info[ent->driver_data]; u32 tmp; int i, j; @@ -1640,6 +1642,7 @@ memset (rinfo, 0, sizeof (struct radeonfb_info)); + fb_info = (struct fb_info *)rinfo; rinfo->pdev = pdev; strncpy(rinfo->name, rci->name, 16); rinfo->arch = rci->arch; @@ -1824,8 +1827,16 @@ } } - rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, - rinfo->video_ram); + fb_info->mapped_vram = min_t(unsigned int, MAX_MAPPED_VRAM, rinfo->video_ram); + do { + rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, + fb_info->mapped_vram); + if (rinfo->fb_base) + break; + + fb_info->mapped_vram /= 2; + } while(fb_info->mapped_vram > MIN_MAPPED_VRAM); + if (!rinfo->fb_base) { printk ("radeonfb: cannot map FB\n"); iounmap ((void*)rinfo->mmio_base); @@ -1836,6 +1847,7 @@ kfree (rinfo); return -ENODEV; } + RTRACE(KERN_INFO "radeonfb: mapped %dk videoram\n", fb_info->mapped_vram/1024); /* currcon not yet configured, will be set by first switch */ rinfo->currcon = -1; @@ -2199,13 +2211,14 @@ {-1, -1} }; int i; + struct fb_info *fb_info = (struct fb_info *)rinfo; /* use highest possible virtual resolution */ if (v->xres_virtual == -1 && v->yres_virtual == -1) { printk("radeonfb: using max available virtual resolution\n"); for (i=0; modes[i].xres != -1; i++) { if (modes[i].xres * nom / den * modes[i].yres < - rinfo->video_ram / 2) + fb_info->mapped_vram / 2) break; } if (modes[i].xres == -1) { @@ -2218,15 +2231,15 @@ printk("radeonfb: virtual resolution set to max of %dx%d\n", v->xres_virtual, v->yres_virtual); } else if (v->xres_virtual == -1) { - v->xres_virtual = (rinfo->video_ram * den / + v->xres_virtual = (fb_info->mapped_vram * den / (nom * v->yres_virtual * 2)) & ~15; } else if (v->yres_virtual == -1) { v->xres_virtual = (v->xres_virtual + 15) & ~15; - v->yres_virtual = rinfo->video_ram * den / + v->yres_virtual = fb_info->mapped_vram * den / (nom * v->xres_virtual *2); } else { if (v->xres_virtual * nom / den * v->yres_virtual > - rinfo->video_ram) { + fb_info->mapped_vram) { return -EINVAL; } } @@ -2430,6 +2443,9 @@ return -EINVAL; } + if (((v.xres_virtual * v.yres_virtual * nom) / den) > info->mapped_vram) + return -EINVAL; + if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) return -EINVAL; Luca -- Home: http://kronoz.cjb.net Windows NT crashed. I'm the Blue Screen of Death. No one hears your screams. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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?] 2004-12-02 15:28 ` Kronos @ 2004-12-02 15:39 ` Geert Uytterhoeven 2004-12-02 15:53 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: [Linux-fbdev-devel] " Kronos 0 siblings, 1 reply; 22+ messages in thread From: Geert Uytterhoeven @ 2004-12-02 15:39 UTC (permalink / raw) To: Linux Frame Buffer Device Development Cc: Marcelo Tosatti, Linux Kernel Development On Thu, 2 Dec 2004, Kronos wrote: > Il Wed, Dec 01, 2004 at 10:25:38PM +0100, Geert Uytterhoeven ha scritto: > > On Wed, 1 Dec 2004, Kronos wrote: > > > Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: > > > > > 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 <thunder7@xs4all.nl>. > > > > > > > > > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > > > > > > > > > --- 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. > > I see you point, but users see that their video board does not work if > the system has 1GB (or more) of RAM and they aren't happy. > With current VM split (ie. 1GB/3GB) and with that much RAM there's no > space left to map the entire FB. And AFAIK VM hacking in 2.4 is not > doable (not that I would be able to do it ;) > > > > 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. > > What about this one: > > > Make fb layer aware of the difference between the ioremap()'ed VRAM and > total available VRAM. > smem_len in struct fb_fix_screeninfo contains the amount of physical > VRAM (reported to userspace via FBIOGET_FSCREENINFO ioctl) while the new > field mapped_vram in struct fb_info contains the amount of VRAM actually > ioremap()'ed by drivers (used in read/write/mmap operations). > If mapped_vram is not set it's assumed that the entire framebuffer is > mapped, thus other drivers are unaffected by this patch. Looks OK at first sight. > --- a/include/linux/fb.h 2004-11-30 18:30:08.000000000 +0100 > +++ b/include/linux/fb.h 2004-12-02 14:20:50.000000000 +0100 > @@ -323,6 +323,7 @@ > struct fb_cmap cmap; /* Current cmap */ > struct fb_ops *fbops; > char *screen_base; /* Virtual address */ > + unsigned int mapped_vram; /* ioremap()'ed VRAM */ But perhaps you want to make this unsigned long? I don't think it'll take long before we'll see graphics cards with 4 GiB or more memory, and it would be good if 64-bit platforms could take advantage of them. Oh no, we already have __u32 smem_len in struct fb_fix_screeninfo :-( So you can forget my comment about 64-bit above... Hence, you best make it `u32' (this is kernel internal) for consistency. 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: why does radeonfb work fine in 2.6, but not in 2.4.29-pre1?] 2004-12-02 15:39 ` Geert Uytterhoeven @ 2004-12-02 15:53 ` Kronos 0 siblings, 0 replies; 22+ messages in thread From: Kronos @ 2004-12-02 15:53 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: Marcelo Tosatti, Linux Kernel Development Il Thu, Dec 02, 2004 at 04:39:25PM +0100, Geert Uytterhoeven ha scritto: > On Thu, 2 Dec 2004, Kronos wrote: > > Il Wed, Dec 01, 2004 at 10:25:38PM +0100, Geert Uytterhoeven ha scritto: > > > On Wed, 1 Dec 2004, Kronos wrote: > > > > Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: > > > > > > 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 <thunder7@xs4all.nl>. > > > > > > > > > > > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > > > > > > > > > > > --- 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. > > > > I see you point, but users see that their video board does not work if > > the system has 1GB (or more) of RAM and they aren't happy. > > With current VM split (ie. 1GB/3GB) and with that much RAM there's no > > space left to map the entire FB. And AFAIK VM hacking in 2.4 is not > > doable (not that I would be able to do it ;) > > > > > > 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. > > Looks OK at first sight. > > > --- a/include/linux/fb.h 2004-11-30 18:30:08.000000000 +0100 > > +++ b/include/linux/fb.h 2004-12-02 14:20:50.000000000 +0100 > > @@ -323,6 +323,7 @@ > > struct fb_cmap cmap; /* Current cmap */ > > struct fb_ops *fbops; > > char *screen_base; /* Virtual address */ > > + unsigned int mapped_vram; /* ioremap()'ed VRAM */ > > But perhaps you want to make this unsigned long? I don't think it'll take long > before we'll see graphics cards with 4 GiB or more memory, and it would be good > if 64-bit platforms could take advantage of them. > > Oh no, we already have __u32 smem_len in struct fb_fix_screeninfo :-( > So you can forget my comment about 64-bit above... > > Hence, you best make it `u32' (this is kernel internal) for consistency. Ok, here we go: Make fb layer aware of the difference between the ioremap()'ed VRAM and total available VRAM. smem_len in struct fb_fix_screeninfo contains the amount of physical VRAM (reported to userspace via FBIOGET_FSCREENINFO ioctl) while the new field mapped_vram in struct fb_info contains the amount of VRAM actually ioremap()'ed by drivers (used in read/write/mmap operations). If mapped_vram is not set it's assumed that the entire framebuffer is mapped, thus other drivers are unaffected by this patch. Signed-off-by: Luca Tettamanti <kronos@people.it> --- a/include/linux/fb.h 2004-11-30 18:30:08.000000000 +0100 +++ b/include/linux/fb.h 2004-12-02 14:20:50.000000000 +0100 @@ -323,6 +323,7 @@ struct fb_cmap cmap; /* Current cmap */ struct fb_ops *fbops; char *screen_base; /* Virtual address */ + u32 mapped_vram; /* ioremap()'ed VRAM */ struct display *disp; /* initial display variable */ struct vc_data *display_fg; /* Console visible on this display */ char fontname[40]; /* default font name */ --- a/drivers/video/fbmem.c 2004-11-30 18:30:00.000000000 +0100 +++ b/drivers/video/fbmem.c 2004-12-02 14:29:44.000000000 +0100 @@ -410,6 +410,7 @@ struct fb_info *info = registered_fb[fbidx]; struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -418,10 +419,12 @@ return -EINVAL; fb->fb_get_fix(&fix,PROC_CONSOLE(info), info); - if (p >= fix.smem_len) + size = info->mapped_vram ? info->mapped_vram : fix.smem_len; + + if (p >= size) return 0; - if (count > fix.smem_len - p) - count = fix.smem_len - p; + if (count > size - p) + count = size - p; if (count) { char *base_addr; @@ -444,6 +447,7 @@ struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; int err; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -452,11 +456,13 @@ return -EINVAL; fb->fb_get_fix(&fix, PROC_CONSOLE(info), info); - if (p > fix.smem_len) + size = info->mapped_vram ? info->mapped_vram : fix.smem_len; + + if (p > size) return -ENOSPC; err = 0; - if (count > fix.smem_len - p) { - count = fix.smem_len - p; + if (count > size - p) { + count = size - p; err = -ENOSPC; } if (count) { @@ -619,7 +625,10 @@ /* frame buffer memory */ start = fix.smem_start; - len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.smem_len); + if (info->mapped_vram) + len = PAGE_ALIGN((start & ~PAGE_MASK) + info->mapped_vram); + else + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.smem_len); if (off >= len) { /* memory mapped io */ off -= len; --- a/drivers/video/radeonfb.c 2004-11-30 18:06:45.000000000 +0100 +++ b/drivers/video/radeonfb.c 2004-12-02 14:28:10.000000000 +0100 @@ -176,7 +176,8 @@ #define RTRACE if(0) printk #endif - +#define MAX_MAPPED_VRAM (2048*2048*4) +#define MIN_MAPPED_VRAM (1024*768*1) enum radeon_chips { RADEON_QD, @@ -499,7 +500,7 @@ short chipset; unsigned char arch; - int video_ram; + unsigned int video_ram; u8 rev; int pitch, bpp, depth; int xres, yres, pixclock; @@ -1626,6 +1627,7 @@ const struct pci_device_id *ent) { struct radeonfb_info *rinfo; + struct fb_info *fb_info; struct radeon_chip_info *rci = &radeon_chip_info[ent->driver_data]; u32 tmp; int i, j; @@ -1640,6 +1642,7 @@ memset (rinfo, 0, sizeof (struct radeonfb_info)); + fb_info = (struct fb_info *)rinfo; rinfo->pdev = pdev; strncpy(rinfo->name, rci->name, 16); rinfo->arch = rci->arch; @@ -1824,8 +1827,16 @@ } } - rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, - rinfo->video_ram); + fb_info->mapped_vram = min_t(unsigned int, MAX_MAPPED_VRAM, rinfo->video_ram); + do { + rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, + fb_info->mapped_vram); + if (rinfo->fb_base) + break; + + fb_info->mapped_vram /= 2; + } while(fb_info->mapped_vram > MIN_MAPPED_VRAM); + if (!rinfo->fb_base) { printk ("radeonfb: cannot map FB\n"); iounmap ((void*)rinfo->mmio_base); @@ -1836,6 +1847,7 @@ kfree (rinfo); return -ENODEV; } + RTRACE(KERN_INFO "radeonfb: mapped %dk videoram\n", fb_info->mapped_vram/1024); /* currcon not yet configured, will be set by first switch */ rinfo->currcon = -1; @@ -2199,13 +2211,14 @@ {-1, -1} }; int i; + struct fb_info *fb_info = (struct fb_info *)rinfo; /* use highest possible virtual resolution */ if (v->xres_virtual == -1 && v->yres_virtual == -1) { printk("radeonfb: using max available virtual resolution\n"); for (i=0; modes[i].xres != -1; i++) { if (modes[i].xres * nom / den * modes[i].yres < - rinfo->video_ram / 2) + fb_info->mapped_vram / 2) break; } if (modes[i].xres == -1) { @@ -2218,15 +2231,15 @@ printk("radeonfb: virtual resolution set to max of %dx%d\n", v->xres_virtual, v->yres_virtual); } else if (v->xres_virtual == -1) { - v->xres_virtual = (rinfo->video_ram * den / + v->xres_virtual = (fb_info->mapped_vram * den / (nom * v->yres_virtual * 2)) & ~15; } else if (v->yres_virtual == -1) { v->xres_virtual = (v->xres_virtual + 15) & ~15; - v->yres_virtual = rinfo->video_ram * den / + v->yres_virtual = fb_info->mapped_vram * den / (nom * v->xres_virtual *2); } else { if (v->xres_virtual * nom / den * v->yres_virtual > - rinfo->video_ram) { + fb_info->mapped_vram) { return -EINVAL; } } @@ -2430,6 +2443,9 @@ return -EINVAL; } + if (((v.xres_virtual * v.yres_virtual * nom) / den) > info->mapped_vram) + return -EINVAL; + if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) return -EINVAL; Luca -- Home: http://kronoz.cjb.net Una donna sposa un uomo sperando che cambi, e lui non cambiera`. Un uomo sposa una donna sperando che non cambi, e lei cambiera`. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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?] @ 2004-12-02 15:53 ` Kronos 0 siblings, 0 replies; 22+ messages in thread From: Kronos @ 2004-12-02 15:53 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: Marcelo Tosatti, Linux Kernel Development Il Thu, Dec 02, 2004 at 04:39:25PM +0100, Geert Uytterhoeven ha scritto: > On Thu, 2 Dec 2004, Kronos wrote: > > Il Wed, Dec 01, 2004 at 10:25:38PM +0100, Geert Uytterhoeven ha scritto: > > > On Wed, 1 Dec 2004, Kronos wrote: > > > > Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: > > > > > > 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 <thunder7@xs4all.nl>. > > > > > > > > > > > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > > > > > > > > > > > --- 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. > > > > I see you point, but users see that their video board does not work if > > the system has 1GB (or more) of RAM and they aren't happy. > > With current VM split (ie. 1GB/3GB) and with that much RAM there's no > > space left to map the entire FB. And AFAIK VM hacking in 2.4 is not > > doable (not that I would be able to do it ;) > > > > > > 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. > > Looks OK at first sight. > > > --- a/include/linux/fb.h 2004-11-30 18:30:08.000000000 +0100 > > +++ b/include/linux/fb.h 2004-12-02 14:20:50.000000000 +0100 > > @@ -323,6 +323,7 @@ > > struct fb_cmap cmap; /* Current cmap */ > > struct fb_ops *fbops; > > char *screen_base; /* Virtual address */ > > + unsigned int mapped_vram; /* ioremap()'ed VRAM */ > > But perhaps you want to make this unsigned long? I don't think it'll take long > before we'll see graphics cards with 4 GiB or more memory, and it would be good > if 64-bit platforms could take advantage of them. > > Oh no, we already have __u32 smem_len in struct fb_fix_screeninfo :-( > So you can forget my comment about 64-bit above... > > Hence, you best make it `u32' (this is kernel internal) for consistency. Ok, here we go: Make fb layer aware of the difference between the ioremap()'ed VRAM and total available VRAM. smem_len in struct fb_fix_screeninfo contains the amount of physical VRAM (reported to userspace via FBIOGET_FSCREENINFO ioctl) while the new field mapped_vram in struct fb_info contains the amount of VRAM actually ioremap()'ed by drivers (used in read/write/mmap operations). If mapped_vram is not set it's assumed that the entire framebuffer is mapped, thus other drivers are unaffected by this patch. Signed-off-by: Luca Tettamanti <kronos@people.it> --- a/include/linux/fb.h 2004-11-30 18:30:08.000000000 +0100 +++ b/include/linux/fb.h 2004-12-02 14:20:50.000000000 +0100 @@ -323,6 +323,7 @@ struct fb_cmap cmap; /* Current cmap */ struct fb_ops *fbops; char *screen_base; /* Virtual address */ + u32 mapped_vram; /* ioremap()'ed VRAM */ struct display *disp; /* initial display variable */ struct vc_data *display_fg; /* Console visible on this display */ char fontname[40]; /* default font name */ --- a/drivers/video/fbmem.c 2004-11-30 18:30:00.000000000 +0100 +++ b/drivers/video/fbmem.c 2004-12-02 14:29:44.000000000 +0100 @@ -410,6 +410,7 @@ struct fb_info *info = registered_fb[fbidx]; struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -418,10 +419,12 @@ return -EINVAL; fb->fb_get_fix(&fix,PROC_CONSOLE(info), info); - if (p >= fix.smem_len) + size = info->mapped_vram ? info->mapped_vram : fix.smem_len; + + if (p >= size) return 0; - if (count > fix.smem_len - p) - count = fix.smem_len - p; + if (count > size - p) + count = size - p; if (count) { char *base_addr; @@ -444,6 +447,7 @@ struct fb_ops *fb = info->fbops; struct fb_fix_screeninfo fix; int err; + unsigned int size; if (! fb || ! info->disp) return -ENODEV; @@ -452,11 +456,13 @@ return -EINVAL; fb->fb_get_fix(&fix, PROC_CONSOLE(info), info); - if (p > fix.smem_len) + size = info->mapped_vram ? info->mapped_vram : fix.smem_len; + + if (p > size) return -ENOSPC; err = 0; - if (count > fix.smem_len - p) { - count = fix.smem_len - p; + if (count > size - p) { + count = size - p; err = -ENOSPC; } if (count) { @@ -619,7 +625,10 @@ /* frame buffer memory */ start = fix.smem_start; - len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.smem_len); + if (info->mapped_vram) + len = PAGE_ALIGN((start & ~PAGE_MASK) + info->mapped_vram); + else + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.smem_len); if (off >= len) { /* memory mapped io */ off -= len; --- a/drivers/video/radeonfb.c 2004-11-30 18:06:45.000000000 +0100 +++ b/drivers/video/radeonfb.c 2004-12-02 14:28:10.000000000 +0100 @@ -176,7 +176,8 @@ #define RTRACE if(0) printk #endif - +#define MAX_MAPPED_VRAM (2048*2048*4) +#define MIN_MAPPED_VRAM (1024*768*1) enum radeon_chips { RADEON_QD, @@ -499,7 +500,7 @@ short chipset; unsigned char arch; - int video_ram; + unsigned int video_ram; u8 rev; int pitch, bpp, depth; int xres, yres, pixclock; @@ -1626,6 +1627,7 @@ const struct pci_device_id *ent) { struct radeonfb_info *rinfo; + struct fb_info *fb_info; struct radeon_chip_info *rci = &radeon_chip_info[ent->driver_data]; u32 tmp; int i, j; @@ -1640,6 +1642,7 @@ memset (rinfo, 0, sizeof (struct radeonfb_info)); + fb_info = (struct fb_info *)rinfo; rinfo->pdev = pdev; strncpy(rinfo->name, rci->name, 16); rinfo->arch = rci->arch; @@ -1824,8 +1827,16 @@ } } - rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, - rinfo->video_ram); + fb_info->mapped_vram = min_t(unsigned int, MAX_MAPPED_VRAM, rinfo->video_ram); + do { + rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, + fb_info->mapped_vram); + if (rinfo->fb_base) + break; + + fb_info->mapped_vram /= 2; + } while(fb_info->mapped_vram > MIN_MAPPED_VRAM); + if (!rinfo->fb_base) { printk ("radeonfb: cannot map FB\n"); iounmap ((void*)rinfo->mmio_base); @@ -1836,6 +1847,7 @@ kfree (rinfo); return -ENODEV; } + RTRACE(KERN_INFO "radeonfb: mapped %dk videoram\n", fb_info->mapped_vram/1024); /* currcon not yet configured, will be set by first switch */ rinfo->currcon = -1; @@ -2199,13 +2211,14 @@ {-1, -1} }; int i; + struct fb_info *fb_info = (struct fb_info *)rinfo; /* use highest possible virtual resolution */ if (v->xres_virtual == -1 && v->yres_virtual == -1) { printk("radeonfb: using max available virtual resolution\n"); for (i=0; modes[i].xres != -1; i++) { if (modes[i].xres * nom / den * modes[i].yres < - rinfo->video_ram / 2) + fb_info->mapped_vram / 2) break; } if (modes[i].xres == -1) { @@ -2218,15 +2231,15 @@ printk("radeonfb: virtual resolution set to max of %dx%d\n", v->xres_virtual, v->yres_virtual); } else if (v->xres_virtual == -1) { - v->xres_virtual = (rinfo->video_ram * den / + v->xres_virtual = (fb_info->mapped_vram * den / (nom * v->yres_virtual * 2)) & ~15; } else if (v->yres_virtual == -1) { v->xres_virtual = (v->xres_virtual + 15) & ~15; - v->yres_virtual = rinfo->video_ram * den / + v->yres_virtual = fb_info->mapped_vram * den / (nom * v->xres_virtual *2); } else { if (v->xres_virtual * nom / den * v->yres_virtual > - rinfo->video_ram) { + fb_info->mapped_vram) { return -EINVAL; } } @@ -2430,6 +2443,9 @@ return -EINVAL; } + if (((v.xres_virtual * v.yres_virtual * nom) / den) > info->mapped_vram) + return -EINVAL; + if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) return -EINVAL; Luca -- Home: http://kronoz.cjb.net Una donna sposa un uomo sperando che cambi, e lui non cambiera`. Un uomo sposa una donna sperando che non cambi, e lei cambiera`. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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?] 2004-12-02 15:53 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: [Linux-fbdev-devel] " Kronos (?) @ 2004-12-02 12:43 ` Marcelo Tosatti -1 siblings, 0 replies; 22+ messages in thread From: Marcelo Tosatti @ 2004-12-02 12:43 UTC (permalink / raw) To: Kronos; +Cc: linux-fbdev-devel, Linux Kernel Development Applied, thanks Geert for your reviewing. On Thu, Dec 02, 2004 at 04:53:43PM +0100, Kronos wrote: <snip> > Ok, here we go: > > Make fb layer aware of the difference between the ioremap()'ed VRAM and > total available VRAM. > smem_len in struct fb_fix_screeninfo contains the amount of physical > VRAM (reported to userspace via FBIOGET_FSCREENINFO ioctl) while the new > field mapped_vram in struct fb_info contains the amount of VRAM actually > ioremap()'ed by drivers (used in read/write/mmap operations). > If mapped_vram is not set it's assumed that the entire framebuffer is > mapped, thus other drivers are unaffected by this patch. > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > --- a/include/linux/fb.h 2004-11-30 18:30:08.000000000 +0100 > +++ b/include/linux/fb.h 2004-12-02 14:20:50.000000000 +0100 > @@ -323,6 +323,7 @@ > struct fb_cmap cmap; /* Current cmap */ > struct fb_ops *fbops; > char *screen_base; /* Virtual address */ > + u32 mapped_vram; /* ioremap()'ed VRAM */ > struct display *disp; /* initial display variable */ > struct vc_data *display_fg; /* Console visible on this display */ > char fontname[40]; /* default font name */ > --- a/drivers/video/fbmem.c 2004-11-30 18:30:00.000000000 +0100 > +++ b/drivers/video/fbmem.c 2004-12-02 14:29:44.000000000 +0100 > @@ -410,6 +410,7 @@ > struct fb_info *info = registered_fb[fbidx]; > struct fb_ops *fb = info->fbops; > struct fb_fix_screeninfo fix; > + unsigned int size; > > if (! fb || ! info->disp) > return -ENODEV; > @@ -418,10 +419,12 @@ > return -EINVAL; > > fb->fb_get_fix(&fix,PROC_CONSOLE(info), info); > - if (p >= fix.smem_len) > + size = info->mapped_vram ? info->mapped_vram : fix.smem_len; > + > + if (p >= size) > return 0; > - if (count > fix.smem_len - p) > - count = fix.smem_len - p; > + if (count > size - p) > + count = size - p; > if (count) { > char *base_addr; > > @@ -444,6 +447,7 @@ > struct fb_ops *fb = info->fbops; > struct fb_fix_screeninfo fix; > int err; > + unsigned int size; > > if (! fb || ! info->disp) > return -ENODEV; > @@ -452,11 +456,13 @@ > return -EINVAL; > > fb->fb_get_fix(&fix, PROC_CONSOLE(info), info); > - if (p > fix.smem_len) > + size = info->mapped_vram ? info->mapped_vram : fix.smem_len; > + > + if (p > size) > return -ENOSPC; > err = 0; > - if (count > fix.smem_len - p) { > - count = fix.smem_len - p; > + if (count > size - p) { > + count = size - p; > err = -ENOSPC; > } > if (count) { > @@ -619,7 +625,10 @@ > > /* frame buffer memory */ > start = fix.smem_start; > - len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.smem_len); > + if (info->mapped_vram) > + len = PAGE_ALIGN((start & ~PAGE_MASK) + info->mapped_vram); > + else > + len = PAGE_ALIGN((start & ~PAGE_MASK) + fix.smem_len); > if (off >= len) { > /* memory mapped io */ > off -= len; > --- a/drivers/video/radeonfb.c 2004-11-30 18:06:45.000000000 +0100 > +++ b/drivers/video/radeonfb.c 2004-12-02 14:28:10.000000000 +0100 > @@ -176,7 +176,8 @@ > #define RTRACE if(0) printk > #endif > > - > +#define MAX_MAPPED_VRAM (2048*2048*4) > +#define MIN_MAPPED_VRAM (1024*768*1) > > enum radeon_chips { > RADEON_QD, > @@ -499,7 +500,7 @@ > > short chipset; > unsigned char arch; > - int video_ram; > + unsigned int video_ram; > u8 rev; > int pitch, bpp, depth; > int xres, yres, pixclock; > @@ -1626,6 +1627,7 @@ > const struct pci_device_id *ent) > { > struct radeonfb_info *rinfo; > + struct fb_info *fb_info; > struct radeon_chip_info *rci = &radeon_chip_info[ent->driver_data]; > u32 tmp; > int i, j; > @@ -1640,6 +1642,7 @@ > > memset (rinfo, 0, sizeof (struct radeonfb_info)); > > + fb_info = (struct fb_info *)rinfo; > rinfo->pdev = pdev; > strncpy(rinfo->name, rci->name, 16); > rinfo->arch = rci->arch; > @@ -1824,8 +1827,16 @@ > } > } > > - rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, > - rinfo->video_ram); > + fb_info->mapped_vram = min_t(unsigned int, MAX_MAPPED_VRAM, rinfo->video_ram); > + do { > + rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys, > + fb_info->mapped_vram); > + if (rinfo->fb_base) > + break; > + > + fb_info->mapped_vram /= 2; > + } while(fb_info->mapped_vram > MIN_MAPPED_VRAM); > + > if (!rinfo->fb_base) { > printk ("radeonfb: cannot map FB\n"); > iounmap ((void*)rinfo->mmio_base); > @@ -1836,6 +1847,7 @@ > kfree (rinfo); > return -ENODEV; > } > + RTRACE(KERN_INFO "radeonfb: mapped %dk videoram\n", fb_info->mapped_vram/1024); > > /* currcon not yet configured, will be set by first switch */ > rinfo->currcon = -1; > @@ -2199,13 +2211,14 @@ > {-1, -1} > }; > int i; > + struct fb_info *fb_info = (struct fb_info *)rinfo; > > /* use highest possible virtual resolution */ > if (v->xres_virtual == -1 && v->yres_virtual == -1) { > printk("radeonfb: using max available virtual resolution\n"); > for (i=0; modes[i].xres != -1; i++) { > if (modes[i].xres * nom / den * modes[i].yres < > - rinfo->video_ram / 2) > + fb_info->mapped_vram / 2) > break; > } > if (modes[i].xres == -1) { > @@ -2218,15 +2231,15 @@ > printk("radeonfb: virtual resolution set to max of %dx%d\n", > v->xres_virtual, v->yres_virtual); > } else if (v->xres_virtual == -1) { > - v->xres_virtual = (rinfo->video_ram * den / > + v->xres_virtual = (fb_info->mapped_vram * den / > (nom * v->yres_virtual * 2)) & ~15; > } else if (v->yres_virtual == -1) { > v->xres_virtual = (v->xres_virtual + 15) & ~15; > - v->yres_virtual = rinfo->video_ram * den / > + v->yres_virtual = fb_info->mapped_vram * den / > (nom * v->xres_virtual *2); > } else { > if (v->xres_virtual * nom / den * v->yres_virtual > > - rinfo->video_ram) { > + fb_info->mapped_vram) { > return -EINVAL; > } > } > @@ -2430,6 +2443,9 @@ > return -EINVAL; > } > > + if (((v.xres_virtual * v.yres_virtual * nom) / den) > info->mapped_vram) > + return -EINVAL; > + > if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) > return -EINVAL; > > > Luca > -- > Home: http://kronoz.cjb.net > Una donna sposa un uomo sperando che cambi, e lui non cambiera`. Un > uomo sposa una donna sperando che non cambi, e lei cambiera`. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: why does radeonfb work fine in 2.6, but not in 2.4.29-pre1?] 2004-12-01 20:37 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: [Linux-fbdev-devel] " Kronos @ 2004-12-01 21:50 ` Antonino A. Daplas -1 siblings, 0 replies; 22+ messages in thread From: Antonino A. Daplas @ 2004-12-01 21:50 UTC (permalink / raw) To: linux-fbdev-devel, Kronos; +Cc: Marcelo Tosatti, Linux Kernel Development On Thursday 02 December 2004 04:37, Kronos wrote: > Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: > > > 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 <thunder7@xs4all.nl>. > > > > > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > > > > > --- 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. Userspace already use fix.line_length * var.yres_virtual to compute the amount it can access, which is not necessarily equal to the mapped vram. > Putting mapped_vram in fb_info would be acceptable? Yes, that is a more sensible solution. Tony ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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?] @ 2004-12-01 21:50 ` Antonino A. Daplas 0 siblings, 0 replies; 22+ messages in thread From: Antonino A. Daplas @ 2004-12-01 21:50 UTC (permalink / raw) To: linux-fbdev-devel, Kronos; +Cc: Marcelo Tosatti, Linux Kernel Development On Thursday 02 December 2004 04:37, Kronos wrote: > Il Wed, Dec 01, 2004 at 05:25:52PM +0100, Geert Uytterhoeven ha scritto: > > > 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 <thunder7@xs4all.nl>. > > > > > > Signed-off-by: Luca Tettamanti <kronos@people.it> > > > > > > --- 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. Userspace already use fix.line_length * var.yres_virtual to compute the amount it can access, which is not necessarily equal to the mapped vram. > Putting mapped_vram in fb_info would be acceptable? Yes, that is a more sensible solution. Tony ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-12-02 15:57 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-11-28 18:46 why does radeonfb work fine in 2.6, but not in 2.4.29-pre1? Jurriaan 2004-11-28 18:46 ` Jurriaan 2004-11-29 20:27 ` Jurriaan 2004-11-29 20:27 ` [Linux-fbdev-devel] " Jurriaan 2004-11-29 21:35 ` Kronos 2004-11-29 21:35 ` [Linux-fbdev-devel] " Kronos 2004-11-30 6:55 ` Jurriaan 2004-11-30 6:55 ` [Linux-fbdev-devel] " Jurriaan 2004-11-30 17:56 ` Kronos 2004-11-30 17:56 ` [Linux-fbdev-devel] " Kronos 2004-12-01 16:14 ` [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?] Kronos 2004-12-01 16:25 ` Geert Uytterhoeven 2004-12-01 20:37 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: " Kronos 2004-12-01 20:37 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: [Linux-fbdev-devel] " Kronos 2004-12-01 21:25 ` Geert Uytterhoeven 2004-12-02 15:28 ` Kronos 2004-12-02 15:39 ` Geert Uytterhoeven 2004-12-02 15:53 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: " Kronos 2004-12-02 15:53 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: [Linux-fbdev-devel] " Kronos 2004-12-02 12:43 ` Marcelo Tosatti 2004-12-01 21:50 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: " Antonino A. Daplas 2004-12-01 21:50 ` [PATCH 2.4.29-pre1] radeonfb: don't try to ioreamp the entire VRAM [was: Re: [Linux-fbdev-devel] " Antonino A. Daplas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.