From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: linux-fbdev-devel@lists.sourceforge.net,
Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
Tony Breeds <tbreeds@au1.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Problem with framebuffer mmap on platforms with large addressing
Date: Sun, 18 Mar 2012 11:46:25 +1100 [thread overview]
Message-ID: <1332031585.3105.197.camel@pasglop> (raw)
In-Reply-To: <CALT56yO05UBY6=KqK94=_sC4hd3ranj5J5CXOAo5hSjVAdkgkA@mail.gmail.com>
On Sat, 2012-03-17 at 20:04 +0400, Dmitry Eremin-Solenikov wrote:
> Hello,
>
> I'm trying to make framebuffer to work on PPC460EX board (canyonlands).
>
> The peculiarity of this platform is the fact that it has
> sizeof(unsigned long) = 4,
> but physical address on it is 36 bits width. It is a common to various pieces
> of the code to expect that unsigned long variable is able to contain physical
> address. Most of those places are easy to fix.
Yes. In fact, Tony (CC) has some patches to fix a lot of the DRM
infrastructure (we have radeon KMS working on a similar platform).
> The problem I'm stuck with is a fb_mmap() code. To find a right memory to map
> it uses information from struct fb_fix_screeninfo provided by the driver.
> This structure uses two unsigned long fields to hold physical addresses
> (smem_start and mmio_start). It would be easy to change that structure
> to use phys_addr_t instead of unsigned long, but this structure is a part
> of userspace ABI. It is returned to userspace on FBIOGET_FSCREENINFO ioctl.
> And now I'm stuck with it.
It's an old problem, which I think we described a while back on the
list. Back then the conclusion was to make a new version with a proper
__u64, a new ioctl to access is, and a "compatible" ioctl that blanks
the address fields (or fails) if they contain a value >32-bit.
We just never got to actually implement it.
In fact, we could make the new structure such that it doesn't break
userspace compatibility with 64-bit architectures at all, ie, the "new"
and "compat" ioctl could remain entirely equivalent on 64-bit.
> In my driver code I have just overwritten the fb_mmap function with
> driver-private
> fb_mmap callback supporting 64-bit addressing, but this doesn't look like
> a generic and correct solution.
>
> What is the best way to fix this problem? Should we break ABI with the goal
> of correctness? Should we add new FBIOGET_FSCREENINFO2, which will
> return a correct structure with phys_addr_t (or simply u64) fields and make
> FBIOGET_FSCREENINFO a wrapper returning partially bogus structure
> (with smem_start and mmio_start fields being truncated to just unsigned long)?
> What would developers recommend?
Cheers,
Ben.
next prev parent reply other threads:[~2012-03-18 0:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-17 16:04 Problem with framebuffer mmap on platforms with large addressing Dmitry Eremin-Solenikov
2012-03-18 0:46 ` Benjamin Herrenschmidt [this message]
2012-03-18 14:04 ` Dmitry Eremin-Solenikov
2012-03-18 20:49 ` Benjamin Herrenschmidt
2012-03-19 14:42 ` Dmitry Eremin-Solenikov
2012-03-20 5:40 ` Benjamin Herrenschmidt
2012-04-09 16:18 ` Dmitry Eremin-Solenikov
2012-04-09 21:37 ` Benjamin Herrenschmidt
2012-03-21 19:45 ` Florian Tobias Schandinat
2012-03-21 20:49 ` Benjamin Herrenschmidt
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=1332031585.3105.197.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=FlorianSchandinat@gmx.de \
--cc=dbaryshkov@gmail.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=tbreeds@au1.ibm.com \
/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).