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.