From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-fbdev-devel@lists.sourceforge.net,
Hollis Blanchard <hollisb@us.ibm.com>,
adaplas@gmail.com, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org,
Andrew Morton <akpm@linux-foundation.org>,
Detlev Zundel <dzu@denx.de>
Subject: Re: [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
Date: Tue, 22 Apr 2008 17:55:00 +0200 [thread overview]
Message-ID: <480E0A54.9010203@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080422012723.BA9F2DE13F@ozlabs.org>
Benjamin Herrenschmidt wrote:
> This fixes radeonfb to not truncate 64 bits resources on 32 bits
> platforms. Unfortunately, there are still issues with addresses
> returned to userspace via struct fb_fix_screeninfo. This will
> have to be dealt with separately.
Thanks for this patch Benjamin, I use it together with what we have discussed in the "pci issue - wrong detection of pci ressources" thread.
Unfortunately I now hit exactly that issue with fb_fix_screeninfo you describe.
For everyone the fb_fix_screeninfo has two "unsigned long" vars that need to strore a IO address.
This fails in my case with a 32bit powerpc system (=sizeof(long)=4) which has paddr >4Gb and actually it should affect any 32bit platform with paddr>4Gb.
You see it e.g. when you try to initialize X11, the x11 radeon driver issues a FBIOGET_FSCREENINFO ioctl and because our address is >4Gb it get's clobbered by that unsigned long in the fb_fix_screeninfo structure (the value comes from a resource_size_t variable which has the correct 64bit).
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
unsigned long smem_start; /* Start of frame buffer mem */
[...]
unsigned long mmio_start; /* Start of Memory Mapped I/O */
[...]
I tried the stupid solution to just change the fb_fix_screeninfo structure to resource_size_t, but that changes the size ioctl transports and would require awareness in the userspace applications using that ioctl.
The X11 & Framebuffer driver work on 64bit systems, so I think it's just an issue of not cutting that data down to 32bit when transporting it (has anyone already checked the x11 drivers, I hope they don't use unsigned long too).
I wanted to ask if there are any known workarounds atm that would allow me to use my X11 for now?
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
next prev parent reply other threads:[~2008-04-22 15:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 1:26 [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs Benjamin Herrenschmidt
2008-04-22 15:55 ` Christian Ehrhardt [this message]
2008-04-22 16:04 ` Michel Dänzer
2008-04-22 22:21 ` Benjamin Herrenschmidt
2008-04-23 9:32 ` [Linux-fbdev-devel] " Michel Dänzer
2008-04-23 9:40 ` Benjamin Herrenschmidt
2008-04-23 9:57 ` David Miller
2008-04-23 10:34 ` Benjamin Herrenschmidt
2009-01-08 10:20 ` Sergei Shtylyov
2009-01-08 10:26 ` Sergei Shtylyov
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=480E0A54.9010203@linux.vnet.ibm.com \
--to=ehrhardt@linux.vnet.ibm.com \
--cc=adaplas@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=dzu@denx.de \
--cc=hollisb@us.ibm.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).