From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>,
"Antonino A. Daplas" <adaplas@gmail.com>
Subject: deprecating fix->mmio_start and smem_start
Date: Tue, 22 Apr 2008 11:17:26 +1000 [thread overview]
Message-ID: <1208827046.9640.73.camel@pasglop> (raw)
Hi !
We currently have a problem with those two members of struct
fb_fix_screeninfo. The struct contains an "unsigned long" which means
that:
- 64 bits kernels with 32 bits userspace can't pass a complete address
- 32 bits machines with 64 bits resource_size_t can't pass a complete
address
- The structure isn't even properly padded to be 32/64 bits neutral in
the first place.
We could define new versions of the struct with new get/set ioctls,
or we could try to just deprecate those fields. What do you guys think ?
If we do the later, we need another way to convey the informations.
For smem, I'm not sure it's very useful, we should just be able to mmap
the fbdev. The problem is more with mmio_start.
Thus the idea that we could do something to allow mmap'ing mmio via
mmap of /dev/fb via some specific offset... what do you think ?
Or we can just do a fb_fix_screeninfo2, with proper padding and u64
addresses, replace the kernel one with that, have translators for the
old ioctl's, and new ioctl's.
What do you guys think ?
Cheers,
Ben.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
next reply other threads:[~2008-04-22 1:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 1:17 Benjamin Herrenschmidt [this message]
2008-04-22 8:00 ` deprecating fix->mmio_start and smem_start Geert Uytterhoeven
2008-04-22 8:48 ` Benjamin Herrenschmidt
2008-04-22 12:38 ` Geert Uytterhoeven
2008-04-23 5:21 ` Benjamin Herrenschmidt
2008-04-22 16:03 ` Scott D. Davilla
2008-04-22 18:11 ` Geert Uytterhoeven
2008-04-22 18:28 ` Scott D. Davilla
2008-04-22 18:44 ` Geert Uytterhoeven
2008-04-22 18:52 ` Scott D. Davilla
2008-04-22 18:41 ` Ville Syrjälä
2008-04-22 22:23 ` 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=1208827046.9640.73.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=adaplas@gmail.com \
--cc=jwboyer@linux.vnet.ibm.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/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).