> On x86 where x >=6, the MTRR's do the same job. That's why the MTRR's were
> introduced: because the P6 core can re-order accesses, you can no longer
> afford to wait until the access hits the bus to know whether it is RAM or
> not, so you have to introduce a in-core data structure to maintain that
> knowledge.
i believe this still doesnt turn off store forwarding. If two PCI commands
are written to the same register then they might get 'merged', resulting
in the first written command to be lost. This usually doesnt happen, but
can happen, and does happen in some cases.
> So note that we do NOT want to make all ioremapped accesses
> uncacheable, because then we could no longer do clever tricks with
> MTRR's.
the only MTRR stuff we do right now is mmap()-ing the frame buffer via
/dev/mem, right? In that case we are doing things outside of ioremap()'s
scope anyway.
> And we know that we want to do MTRR stuff, at least eventually.
yep, i agree that we want to do WC in drivers/video/*.c, but i think the
interface should be additive. We still have __ioremap(,,flags), and can
add an ioremap_wc() function easily, no? What i mean is that right now 99%
of ioremap()s is for ordinary shared PCI memory drivers, which use command
registers, and for those anything non-UC is potentially lethal.
actually this is how ioremap_nocache() popped up, i just didnt understand
this issue at that time. (i hope i do now :). About 2 years ago CISCO
found out when developing drivers that their driver fails mysteriously on
PPro boxes. So i sent a small patch to add ioremap_nocache(), but that's
the wrong solution now i believe.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/