"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Siddha, Suresh B wrote: >> >> But then, this will cause an attribute conflicit. Old one was specifying >> WB in PAT (ioremap with noflags) and the new ioremap specifies UC. >> >> As Linus mentioned, main problem is to figure out the correct attribute >> for ioremap() which doesn't specify the actual attribute to be used. >> >> One mechanism to fix the issue generically (somewhat atleast) is to use >> MTRR's and figure out the default MTRR attribute for that physical address >> and use it for ioremap(). >> > > This is the matrix the CPU uses when combining MTRR and PAT behaviour. It > probably makes sense to mimic: > > | WB WT WC UC > ---+--------------- > WB | WB WT WC UC > WT | WT WT UC UC > WC | WC UC WC UC > UC | UC UC UC UC > > With the current PAT encoding: > > WB = 00 > WT = 01 > WC = 10 > UC = 11 > > ... this is simply a bitwise OR. This makes sense, since one of the bits > denies > delaying writes (WT, UC), and the other denies delaying reads (WC, UC).
Almost. There is a specific case and important where MTRR UC + page table WC == WC. But yes. For ioremap where we are WB + MTRR == MTRR we need to request the same attributes as the e820 map, to get the attribute checking correct. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
