Messages in this thread | | | Date | Thu, 17 Jan 2008 16:38:32 -0500 | From | "H. Peter Anvin" <> | Subject | Re: [patch 0/4] x86: PAT followup - Incremental changes and bug fixes |
| |
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).
-hpa
| |