All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-fbdev-devel@lists.sourceforge.net, linuxppc-dev@ozlabs.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, adaplas@gmail.com,
	Hollis Blanchard <hollisb@us.ibm.com>, Wolfgang Denk <wd@denx.de>,
	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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2008-04-22 15:55 UTC|newest]

Thread overview: 27+ 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  1:26 ` Benjamin Herrenschmidt
2008-04-22  1:26 ` Benjamin Herrenschmidt
2008-04-22 15:55 ` Christian Ehrhardt [this message]
2008-04-22 15:55   ` Christian Ehrhardt
2008-04-22 16:04   ` Michel Dänzer
2008-04-22 16:04     ` Michel Dänzer
2008-04-22 16:04     ` Michel Dänzer
2008-04-22 22:21   ` Benjamin Herrenschmidt
2008-04-22 22:21     ` Benjamin Herrenschmidt
2008-04-22 22:21     ` Benjamin Herrenschmidt
2008-04-23  9:32     ` Michel Dänzer
2008-04-23  9:32       ` [Linux-fbdev-devel] " Michel Dänzer
2008-04-23  9:32       ` Michel Dänzer
2008-04-23  9:40       ` Benjamin Herrenschmidt
2008-04-23  9:40         ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2008-04-23  9:40         ` Benjamin Herrenschmidt
2008-04-23  9:57       ` David Miller
2008-04-23  9:57         ` [Linux-fbdev-devel] " David Miller
2008-04-23  9:57         ` David Miller
2008-04-23 10:34         ` Benjamin Herrenschmidt
2008-04-23 10:34           ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2008-04-23 10:34           ` Benjamin Herrenschmidt
2009-01-08 10:20 ` Sergei Shtylyov
2009-01-08 10:20   ` Sergei Shtylyov
2009-01-08 10:26 ` 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 \
    --cc=wd@denx.de \
    /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.