Re: Problem with framebuffer mmap on platforms with large addressing

On Mon, Mar 19, 2012 at 12:49 AM, Benjamin Herrenschmidt
[off-list ref] wrote:

On Sun, 2012-03-18 at 18:04 +0400, Dmitry Eremin-Solenikov wrote:

quoted

On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
[off-list ref] wrote:

quoted

On Sat, 2012-03-17 at 20:04 +0400, Dmitry Eremin-Solenikov wrote:

quoted

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

Hmm. Could you please spill a little bit more of details? Also are those patches
for 476 merged or present somewhere?

quoted

quoted

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.

I don't think this kind of magic would be good. I'd just stick to the new
ioctl.

Cheers,
Ben.

-- 
With best wishes
Dmitry