linux-toradex.git/arch/x86/kernel/aperture_64.c, branch v4.9.76

param: convert some "on"/"off" users to strtobool

2016-03-17T22:09:34+00:00

This changes several users of manual "on"/"off" parsing to use
strtobool.

Some side-effects:
- these uses will now parse y/n/1/0 meaningfully too
- the early_param uses will now bubble up parse errors

Signed-off-by: Kees Cook 
Acked-by: Heiko Carstens 
Acked-by: Michael Ellerman 
Cc: Amitkumar Karwar 
Cc: Andy Shevchenko 
Cc: Daniel Borkmann 
Cc: Joe Perches 
Cc: Kalle Valo 
Cc: Martin Schwidefsky 
Cc: Nishant Sarmukadam 
Cc: Rasmus Villemoes 
Cc: Steve French 
Cc: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86/gart: Check for GART support before accessing GART registers

2015-05-06T09:15:53+00:00

GART registers are not present in newer AMD processors (Fam15h, Model
10h and later). So, avoid accessing those in PCI config space by
returning early in early_gart_iommu_check() and gart_iommu_hole_init()
if GART is not available.

Current code doesn't break on existing processors but there are some
side effects:

We get bogus AGP aperture messages which are simply noise on
GART-less processors:

  AGP: Node 0: aperture [bus addr 0x00000000-0x01ffffff] (32MB)
  AGP: Your BIOS doesn't leave aperture memory hole
  AGP: Please enable the IOMMU option in the BIOS setup
  AGP: This costs you 64MB of RAM
  AGP: Mapping aperture over RAM [mem 0xd4000000-0xd7ffffff]

We can avoid calling allocate_aperture() and would not have to
wastefully reserve 64MB of RAM with memblock_reserve(). Also, we can
avoid having to loop through all PCI buses and devices twice, searching
for a non-existent AGP bridge if we bail out early.

Refactor the family check used in amd_nb.c into an inline function so we
can use it here as well as in amd_nb.c

Fix some typos while at it.

Tested the patch on Fam10h and Fam15h Model 00h-fh and this code runs
fine. On Fam15h Model 60h-6fh and on Fam16h, we bail early as they don't
have GART.

Signed-off-by: Aravind Gopalakrishnan 
Signed-off-by: Borislav Petkov 
Reviewed-by: Suravee Suthikulpanit 
Cc: Bjorn Helgaas 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Joerg Rodel 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1428443197-3834-1-git-send-email-Aravind.Gopalakrishnan@amd.com
Signed-off-by: Ingo Molnar

x86/gart: Tidy messages and add bridge device info

2014-05-23T16:47:19+00:00

Print the AGP bridge info the same way as the rest of the kernel, e.g.,
"0000:00:04.0" instead of "00:04:00".

Also print the AGP aperture address range the same way we print resources,
and label it explicitly as a bus address range.

No functional change except the message changes.

Signed-off-by: Bjorn Helgaas

x86/gart: Replace printk() with pr_info()

2014-05-23T16:47:19+00:00

Replace printk() with pr_info(), pr_err(), etc.  Define pr_fmt() to prefix
output with "AGP: ".

No functional change except the addition of "AGP: " prefix in dmesg output.

Signed-off-by: Bjorn Helgaas

Revert "[PATCH] Insert GART region into resource map"

2014-03-18T20:26:12+00:00

This reverts commit 56dd669a138c, which makes the GART visible in
/proc/iomem.  This fixes a regression: e501b3d87f00 ("agp: Support 64-bit
APBASE") exposed an existing problem with a conflict between the GART
region and a PCI BAR region.

The GART addresses are bus addresses, not CPU addresses, and therefore
should not be inserted in iomem_resource.

On many machines, the GART region is addressable by the CPU as well as by
an AGP master, but CPU addressability is not required by the spec.  On some
of these machines, the GART is mapped by a PCI BAR, and in that case, the
PCI core automatically inserts it into iomem_resource, just as it does for
all BARs.

Inserting it here means we'll have a conflict if the PCI core later tries
to claim the GART region, so let's drop the insertion here.

The conflict indirectly causes X failures, as reported by Jouni in the
bugzilla below.  We detected the conflict even before e501b3d87f00, but
after it the AGP code (fix_northbridge()) uses the PCI resource (which is
zeroed because of the conflict) instead of reading the BAR again.

Conflicts:
	arch/x86_64/kernel/aperture.c

Fixes: e501b3d87f00 agp: Support 64-bit APBASE
Link: https://bugzilla.kernel.org/show_bug.cgi?id=72201
Reported-and-tested-by: Jouni Mettälä 
Signed-off-by: Bjorn Helgaas

x86/mm/gart: Drop unnecessary check

2013-04-16T08:54:40+00:00

The memblock_find_in_range() return value addr is guaranteed
to be within "addr + aper_size" and not beyond GART_MAX_ADDR.

Signed-off-by: Wang YanQing 
Cc: yinghai@kernel.org
Link: http://lkml.kernel.org/r/20130416013734.GA14641@udknight
Signed-off-by: Ingo Molnar

x86/gart: Fix kmemleak warning

2012-06-06T09:58:38+00:00

aperture_64.c now is using memblock, the previous
kmemleak_ignore() for alloc_bootmem() should be removed then.

Otherwise, with kmemleak enabled, kernel will throw warnings
like:

[    0.000000] kmemleak: Trying to color unknown object at 0xffff8800c4000000 as Black
[    0.000000] Pid: 0, comm: swapper/0 Not tainted 3.5.0-rc1-next-20120605+ #130
[    0.000000] Call Trace:
[    0.000000]  [] paint_ptr+0x66/0xc0
[    0.000000]  [] kmemleak_ignore+0x2b/0x60
[    0.000000]  [] kmemleak_init+0x217/0x2c1
[    0.000000]  [] start_kernel+0x32d/0x3eb
[    0.000000]  [] ? repair_env_string+0x5a/0x5a
[    0.000000]  [] x86_64_start_reservations+0x131/0x135
[    0.000000]  [] ? early_idt_handlers+0x120/0x120
[    0.000000]  [] x86_64_start_kernel+0x102/0x111
[    0.000000] kmemleak: Early log backtrace:
[    0.000000]    [] kmemleak_ignore+0x4b/0x60
[    0.000000]    [] gart_iommu_hole_init+0x3e7/0x547
[    0.000000]    [] pci_iommu_alloc+0x44/0x6f
[    0.000000]    [] mem_init+0x19/0xec
[    0.000000]    [] start_kernel+0x1ea/0x3eb
[    0.000000]    [] x86_64_start_reservations+0x131/0x135
[    0.000000]    [] x86_64_start_kernel+0x102/0x111
[    0.000000]    [] 0xffffffffffffffff

Signed-off-by: Xiaotian Feng 
Cc: Xiaotian Feng 
Cc: Tejun Heo 
Link: http://lkml.kernel.org/r/1338922831-2847-1-git-send-email-xtfeng@gmail.com
Signed-off-by: Ingo Molnar

memblock, x86: Replace memblock_x86_reserve/free_range() with generic ones

2011-07-14T18:47:53+00:00

Other than sanity check and debug message, the x86 specific version of
memblock reserve/free functions are simple wrappers around the generic
versions - memblock_reserve/free().

This patch adds debug messages with caller identification to the
generic versions and replaces x86 specific ones and kills them.
arch/x86/include/asm/memblock.h and arch/x86/mm/memblock.c are empty
after this change and removed.

Signed-off-by: Tejun Heo 
Link: http://lkml.kernel.org/r/1310462166-31469-14-git-send-email-tj@kernel.org
Cc: Yinghai Lu 
Cc: Benjamin Herrenschmidt 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Signed-off-by: H. Peter Anvin

memblock: Kill MEMBLOCK_ERROR

2011-07-13T23:36:01+00:00

25818f0f28 (memblock: Make MEMBLOCK_ERROR be 0) thankfully made
MEMBLOCK_ERROR 0 and there already are codes which expect error return
to be 0.  There's no point in keeping MEMBLOCK_ERROR around.  End its
misery.

Signed-off-by: Tejun Heo 
Link: http://lkml.kernel.org/r/1310457490-3356-6-git-send-email-tj@kernel.org
Cc: Yinghai Lu 
Cc: Benjamin Herrenschmidt 
Signed-off-by: H. Peter Anvin

x86, gart: Don't enforce GART aperture lower-bound by alignment

2011-04-18T17:31:38+00:00

This patch changes the allocation of the GART aperture to
enforce only natural alignment instead of aligning it on
512MB. This big alignment was used to force the GART
aperture to be over 512MB. This is enforced by using 512MB
as the lower-bound address in the allocation range.

[ hpa: The actual number 512 MiB needs to be revisited, too. ]

Cc: Yinghai Lu 
Signed-off-by: Joerg Roedel 
Link: http://lkml.kernel.org/r/1303134346-5805-2-git-send-email-joerg.roedel@amd.com
Signed-off-by: H. Peter Anvin