linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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.

  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).