This adds a struct pci_mmcfg_region with a little more information
than the struct acpi_mcfg_allocation used previously.  The acpi_mcfg
structure is defined by the spec, so we can't change it.

To begin with, struct pci_mmcfg_region is basically the same as the
ACPI MCFG version, but future patches will add more information.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This factors out the common "bus << 20" expression used when computing the
MMCONFIG address.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Since all MMCONFIG regions go through pci_mmconfig_add(), we can test the
address once there.  If the caller supplies an address of zero, we never
insert it in the pci_mmcfg_config[] table, so no need to test it elsewhere.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

We never set pci_mmcfg_config unless we increment pci_mmcfg_config_num,
so there's no need to test both pci_mmcfg_config_num and pci_mmcfg_config.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch encapsulate pci_mmcfg_config[] updates.  All alloc/free is now
done in pci_mmconfig_add() and free_all_mcfg(), so all updates to
pci_mmcfg_config[] and pci_mmcfg_config_num are in those two functions.

This replaces the previous sequence of extend_mmcfg(), fill_one_mmcfg()
with the single pci_mmconfig_add() interface.  This interface is currently
static but will eventually be used in the host bridge hot-add path.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Step through the ACPI MCFG table, not pci_mmcfg_config[].  No functional
change, but simplifies future patches that encapsulate pci_mmcfg_config[].
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Use a local variable, not pci_mmcfg_config_num, to count MCFG entries.
No functional change, but simplifies future changes.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Those functions are used by intel_bus.c so seperate them to another file. and
make amd_bus a bit smaller.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NAndré Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

commit db635adc turned -DDEBUG for x86/pci on when CONFIG_PCI_DEBUG
is set. In general, I agree with that change.

However, it exposes a bunch of very low level PCI debugging in the
early x86 path, such as:

	0 reading 2 from a: ffff
	1 reading 2 from a: ffff
	2 reading 2 from a: ffff
	3 reading 2 from a: 300
	3 reading 2 from 0: 1002
	3 reading 2 from 2: 515e

These statements add a lot of noise to the boot and aren't likely to
be necessary even when handling random upstream bug reports.

[In contrast, statements such as these:

	pci 0000:02:04.0: found [14e4:164a] class 000200 header type 00
	pci 0000:02:04.0: reg 10: [mem 0xf8000000-0xf9ffffff 64bit]
	pci 0000:02:04.0: reg 30: [mem 0x00000000-0x0001ffff pref]

are indeed useful when remote debugging users' machines]

Remove the noisy printks and save electrons everywhere.

Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch fixes the following compilation error introduced by a PCI related
features.

The change set of 5dd1af9f84c79bedd589db89e71ca733f3bf0ebd moves some
xen related definitions from the arch header file
(x86/include/asm/xen/hypervisor.h) to the common header file
(include/xen/xen.h).  So ia64/xen also follows it.

In file included from linux-next/include/xen/grant_table.h:41,
                 from linux-next/drivers/block/xen-blkfront.c:48:
linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: nested redefinition of 'enum xen_domain_type'
linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: redeclaration of 'enum xen_domain_type'
linux-next/arch/ia64/include/asm/xen/hypervisor.h:44: error: redeclaration of enumerator 'XEN_NATIVE'
linux-next/include/xen/xen.h:5: error: previous definition of 'XEN_NATIVE' was here
linux-next/arch/ia64/include/asm/xen/hypervisor.h:45: error: redeclaration of enumerator 'XEN_PV_DOMAIN'
linux-next/include/xen/xen.h:6: error: previous definition of 'XEN_PV_DOMAIN' was here
linux-next/arch/ia64/include/asm/xen/hypervisor.h:46: error: redeclaration of enumerator 'XEN_HVM_DOMAIN'
linux-next/include/xen/xen.h:7: error: previous definition of 'XEN_HVM_DOMAIN' was here
Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The roundup() caused a build error (undefined reference to `__udivdi3').
We're aligning to power-of-two boundaries, so it's simpler to just use
ALIGN() anyway, which avoids the division.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

PCI device BARs are guaranteed to start and end on at least a four-byte
(I/O) or a sixteen-byte (MMIO) boundary because they're aligned on their
size and the low BAR bits are reserved.  PCI-to-PCI bridge apertures
have even larger alignment restrictions.

However, some BIOSes (e.g., HP DL360 BIOS P31) report host bridge windows
like "[io  0x0000-0x2cfe]".  This is wrong because it excludes the last
port at 0x2cff: it's impossible for a downstream device to claim 0x2cfe
without also claiming 0x2cff.  In fact, this BIOS configures a device
behind the bridge to "[io  0x2c00-0x2cff]", so we know the window actually
does include 0x2cff.

This patch rounds the start and end of apertures to the appropriate
boundary.  I experimentally determined that Windows contains a similar
workaround; details here:

    http://bugzilla.kernel.org/show_bug.cgi?id=14337Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

We have occasional problems with PCI resource allocation, and sometimes
they could be avoided by paying attention to what ACPI tells us about
the host bridges.  This patch doesn't change the behavior, but it prints
window information that should make debugging easier.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This makes PCI resource management messages more consistent and adds a few
new messages to aid debugging.

Whenever we assign resources to a device, update a BAR, or change a
bridge aperture, it's worth noting it.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Use the dev_printk-like "%04x:%02x" format for printing PCI bus numbers.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Jesse accidentally applied v1 [1] of the patchset instead of v2 [2].  This
is the diff between v1 and v2.

The changes in this patch are:
    - tidied vsprintf stack buffer to shrink and compute size more
      accurately
    - use %pR for decoding and %pr for "raw" (with type and flags) instead
      of adding %pRt and %pRf

[1] http://lkml.org/lkml/2009/10/6/491
[2] http://lkml.org/lkml/2009/10/13/441Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

We use dev_dbg() in arch/x86/pci, but there's no easy way to turn it
on.  Add -DDEBUG when CONFIG_PCI_DEBUG=y, just like we do in drivers/pci.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Move xen_domain and related tests out of asm-x86 to xen/xen.h so they
can be included whenever they are necessary.
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The current whitelist requires a kernel change for every machine that has
MMCONFIG regions above 4GB, even if BIOS provides a correct MCFG table.

This patch expands the whitelist to include machines with a rev 1 or newer
MCFG table and a DMI_BIOS_DATE of 2010 or later.  That way, we only need
kernel changes for new machines that provide incorrect MCFG tables.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
CC: Matthew Wilcox <willy@linux.intel.com>
CC: John Keller <jpk@sgi.com>
CC: Yinghai Lu <yhlu.kernel@gmail.com>
CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
CC: Andi Kleen <andi@firstfloor.org>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Thomas Schlichter reported:
> X.org uses libpciaccess which tries to mmap with write combining enabled via
> /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the
> kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded
> mapping with write combining enabled and does not set up suited MTRR entries.
> ;-(

Instead of silently mapping pci mmap region as UC minus in the case
of !pat_enabled and wc request, we can return error. Eric Anholt mentioned
that caller (like X) typically follows up with UC minus pci mmap request and
if there is a free mtrr slot, caller will manage adding WC mtrr.

Jesse Barnes says:
> Older versions of libpciaccess will behave better if we do it that way
> (iirc it only allocates an MTRR if the resource_wc file doesn't exist or
> fails to get mapped).
Reported-by: NThomas Schlichter <thomas.schlichter@web.de>
Signed-off-by: NThomas Schlichter <thomas.schlichter@web.de>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This uses %pRt to print additional resource information (type, size,
prefetchability, etc.) consistently.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This uses %pRt to print additional resource information (type, size,
prefetchability, etc.) consistently.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Instead of the PCI code needing to have code to determine the
cacheline size of each processor, use the data the cpu identification
code should have already determined during early boot.

(The vendor checks are also incomplete, and don't take into account
 modern CPUs)

I've been carrying a variant of this code in Fedora for a while,
that prints debug information.  There are a number of cases where we
are currently setting the PCI cacheline size to 32 bytes, when the CPU
cacheline size is 64 bytes.  With this patch, we set them both the same.
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

sparc64 is now the only user of PCI_CACHE_LINE_BYTES.  Drop it and set
pci_dfl_cache_line_size from pcibios_init() instead and drop
PCI_CACHE_LINE_BYTES handling from generic pci code.

Orignally-From: David Miller <davem@davemloft.net>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Till now, CLS has been determined either by arch code or as
L1_CACHE_BYTES.  Only x86 and ia64 set CLS explicitly and x86 doesn't
always get it right.  On most configurations, the chance is that
firmware configures the correct value during boot.

This patch makes pci_init() determine CLS by looking at what firmware
has configured.  It scans all devices and if all non-zero values
agree, the value is used.  If none is configured or there is a
disagreement, pci_dfl_cache_line_size is used.  arch can set the dfl
value (via PCI_CACHE_LINE_BYTES or pci_dfl_cache_line_size) or
override the actual one.

ia64, x86 and sparc64 updated to set the default cls instead of the
actual one.

While at it, declare pci_cache_line_size and pci_dfl_cache_line_size
in pci.h and drop private declarations from arch code.
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NDavid Miller <davem@davemloft.net>
Acked-by: NGreg KH <gregkh@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

For intel systems with multi IOH, we should read peer root resources
directly from PCI config space, and don't trust _CRS.
Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

cpu_is_xxx() macros are identifying generic at91sam9g45 chip. This patch adds
the capacity to differentiate Engineering Samples and final lots through the
inclusion of  at91_cpu_fully_identify() and the related chip IDs with chip
version field preserved.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: NHans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>

Somme common drivers will need those at91 cpu_is_xxx() definitions. As
at91sam9g10 and at91sam9g45 are on the way to linus' tree, here is the patch
that adds those chips to cpu.h in AVR32 architecture.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>

This reverts commit b94b0808.

genksyms currently cannot handle complicated types for exported
percpu variables.  Drop this patch for now as it prevents a
module from being loaded on sn2 systems:

 xpc: no symbol version for per_cpu____sn_cnodeid_to_nasid
 xpc: Unknown symbol per_cpu____sn_cnodeid_to_nasid
Signed-off-by: NTony Luck <tony.luck@intel.com>

Mapping the same memory using two different attributes (memory
type, shareability, cacheability) is unpredictable.  During boot,
we encounter a situation when we're updating the kernel's page
tables which can lead to dirty cache lines existing in the cache
which are subsequently missed.  This causes stack corruption,
and therefore a crash.

Therefore, ensure that the shared and cacheability settings
matches the configuration that will be used later; this together
with the restriction in early_cachepolicy() ensures that we won't
create a mismatch during boot.
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

ARM unwind is known to compile only with EABI and not-buggy compilers.
The problem is not the unwinding information but the -fno-frame-pointer
option added as a result of !CONFIG_FRAME_POINTER.  Now we check the
compiler and raise a #warning in case of wrong compiler.
Signed-off-by: NClaudio Scordino <claudio@evidence.eu.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

sys_ppoll syscall needs to use a compat handler on 64bit kernels with o32
user-space.
Signed-off-by: NArnaud Patard <apatard@mandriva.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Unify the naming method between kernel and the user-space oprofile tool.
Because loongson is used instead of godson in most of the places, we agreed
to use loongson instead, which will simplify future maintenance.
Signed-off-by: NWu Zhangjin <wuzhangjin@gmail.com>
Acked-by: NRobert Richter <robert.richter@amd.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The handle_edge_irq() flowhandler disables edge int sources which occur
too fast (i.e. another edge comes in before the irq handler function
had a chance to finish).  Currently, the mask_ack() callback does not
ack the edges in hardware, leading to an endless loop in the flowhandler
where it tries to shut up the irq source.

When I rewrote the alchemy IRQ code  I wrongly assumed the mask_ack()
callback was only used by the level flowhandler, hence it omitted the
(at the time pointless) edge acks.  Turned out I was wrong; so here
is a complete mask_ack implementation for Alchemy IC, which fixes
the above mentioned problem.
Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

TXx9 SPI bit rate is calculated by:
	fBR = fSPI / 2 / (n + 1)
	(fSPI is SPI master clock freq, i.e. imbusclk freq.)
So use imbus_clk / 2 as a spi-baseclk.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

For consistency with other BCM63xx SoC set the CPU name to "Broadcom
BCM6338" when actually running on that system.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Loongson 2 does not have dcache aliases when is using 16k pages. and the

And because Loongson 2 doesn't do SMP , cpu_icache_snoops_remote_store does
not matter here.
Signed-off-by: NZhang Le <r0bertz@gentoo.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

set_saved_sp reads Context register. Avoid reading stale value from
earlier incomplete write.

Issue found and fixed for head.S by Chris Dearman <chris@mips.com>.
Signed-off-by: NChris Dearman <chris@mips.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>