All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jurriaan <thunder7@xs4all.nl>
To: Kronos <kronos@people.it>
Cc: linux-fbdev-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: why does radeonfb work fine in 2.6, but not in 2.4.29-pre1?
Date: Tue, 30 Nov 2004 07:55:55 +0100	[thread overview]
Message-ID: <20041130065555.GA20972@middle.of.nowhere> (raw)
In-Reply-To: <20041129213510.GA9551@dreamland.darkstar.lan>

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/

WARNING: multiple messages have this Message-ID (diff)
From: Jurriaan <thunder7@xs4all.nl>
To: Kronos <kronos@people.it>
Cc: linux-fbdev-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [Linux-fbdev-devel] why does radeonfb work fine in 2.6, but not in 2.4.29-pre1?
Date: Tue, 30 Nov 2004 07:55:55 +0100	[thread overview]
Message-ID: <20041130065555.GA20972@middle.of.nowhere> (raw)
In-Reply-To: <20041129213510.GA9551@dreamland.darkstar.lan>

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

  reply	other threads:[~2004-11-30  6:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2004-11-30  6:55     ` 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041130065555.GA20972@middle.of.nowhere \
    --to=thunder7@xs4all.nl \
    --cc=kronos@people.it \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.