> >> 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. > > > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
