Problem with framebuffer mmap on platforms with large addressing

[Benjamin Herrenschmidt]

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

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