Problem with framebuffer mmap on platforms with large addressing

[Benjamin Herrenschmidt]

On Sun, 2012-03-18 at 18:04 +0400, Dmitry Eremin-Solenikov wrote:
> On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
> > 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).
> 
> That is interesting! Are those patches published or otherwise available
> somewhere? We are also very interested in enabling Canyonlands
> with Radeon KMS!

You will run into additional problems with 460 due to the fact that it's
not cache coherent for DMA. Tony patches don't address that part of the
problem (they were used on a 476 based platform).

> > 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.
> 
> I remember stuff about compat_ioctl, but I have never used/implemented
> that. Are there any details of requirements for the structures being passed?

In that specific case, I meant something else. IE. The old ioctl could
remain unchanged, and the new ioctl make the same as the old one on
64-bit platforms.

Cheers,
Ben.