Dave Jones wrote:
+ switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_AMD:
+ wrmsr(IA32_CR_PAT, AMD_PAT_31_0, AMD_PAT_63_32);
+ atomic_inc(&pat_cpus_enabled);
+ break;
+ case X86_VENDOR_INTEL:
+ wrmsr(IA32_CR_PAT, INTEL_PAT_31_0, INTEL_PAT_63_32);
+ atomic_inc(&pat_cpus_enabled);
+ break;
+ default:
+ printk("Unknown vendor in setup_pat()\n");
+ }
Drop the vendor check; PAT is a generic x86 feature. If AMD is not
compatible (see below), then use X86_VENDOR_AMD: and default:.
+
+ /* checks copied from arch/i386/kernel/cpu/mtrr/main.c */
+ /* do these only apply to mtrrs or pat as well? */
It would apply to both; the chipset wouldn't even know how it got invoked.
+/* Here is the PAT's default layout on ia32 cpus when we are done.
+ * PAT0: Write Back
+ * PAT1: Write Combine
+ * PAT2: Uncached
+ * PAT3: Uncacheable
+ * PAT4: Write Through
+ * PAT5: Write Protect
+ * PAT6: Uncached
+ * PAT7: Uncacheable
Bad move. Some (Intel) processors drop the top bit, so it's much better
to pick the protection methods one cares about (usually WB, WC, UC) and
stick them in the first four, then duplicate the whole thing in the
second half.
Unless you actually expect someone to use WT or WP, no need to tickle
this particular bug.
+ * Note: On Athlon cpus PAT2/PAT3 & PAT6/PAT7 are both Uncacheable since
+ * there is no uncached type.
If one sets the PAT to "uncached", does one get the same function as
"uncachable"?
-hpa
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]