Thread (10 messages) 10 messages, 3 authors, 2012-04-09

Re: Problem with framebuffer mmap on platforms with large addressing

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2012-03-20 05:40:30
Also in: linuxppc-dev

quoted
quoted
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?
Well, DMA on 46x isn't cache coherent. The DRM plays interesting games
with mapping/unmapping pages for DMA by the chip and I don't think we
have the right hooks to do the appropriate cache flushing on these guys,
but Tony might be able to comment, I don't know whether he tried or not.

On the other hand 476 has fully cache coherent DMA so the only problem
there is the >32-bit physical address space.

As for the patches, you'll have to wait for Tony to respond (I'll poke
him locally).

Cheers,
Ben.
quoted
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.
quoted
Cheers,
Ben.

  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help