On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: >> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>> Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx> >>>> --- >>>> >>>> This needs careful review. I don't really know what this code does, nor >>>> do I have the hardware. (I don't understand AGP and the associated >>>> caching implications.) >>> >>> This patch is wrong (I didn't update the matching mtrr_del), and I'm >>> reworking this whole series. But I may need some help on this one: >>> why is the mtrr handle of a map (whatever a map is) exported to >>> userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is >>> userspace supposed to do with it? Do I need to return a valid MTRR >>> register number? Is there any userspace code at all that sets >>> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment >>> and needs the MTRR, for which the drm driver doesn't already add the >>> MTRR? >>> >>> --Andy >> >> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We >> cover it with a write combine MTRR. The whole ioctl is use by some ddx >> or maybe even directly the XServer to do this mtrr mess in userspace. > > Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to > work fine, but almost nothing uses it. > > I'm amazed this stuff works in the current code, though. Apparently > the memory type (WC or UC) of a drm mapping is determined by the mtrr > the driver set, but if one part of the BAR is textures or the > framebuffer and another part is an outgoing command ring, won't one of > them end up with the wrong memory type? A lot of old chips used to put the registers and framebuffer in the same BAR. IIRC, the xserver and later libpciaccess had workarounds to deal with this. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
