Problem with framebuffer mmap on platforms with large addressing
benh at kernel.crashing.org
Tue Mar 20 16:40:08 EST 2012
> >> 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
> >> > 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
> > Cheers,
> > Ben.
More information about the Linuxppc-dev