linux-toradex.git/drivers/pci, branch PD13.0.0alpha

ENGR00174033-2 MX6 PCIE: add pcie RC driver

2012-02-10T06:00:02+00:00

Add PCIE RC driver on MX6 platforms.
Based on iwl4965agn pcie wifi device, verified the following
features.
* Link up is stable
* map the CFG, IO and MEM spaces, and CFG/MEM spaces can accessed

Signed-off-by: Richard Zhu

intel-iommu: fix superpage support in pfn_to_dma_pte()

2011-12-21T20:57:37+00:00

commit 4399c8bf2b9093696fa8160d79712e7346989c46 upstream.

If target_level == 0, current code breaks out of the while-loop if
SUPERPAGE bit is set. We should also break out if PTE is not present.
If we don't do this, KVM calls to iommu_iova_to_phys() will cause
pfn_to_dma_pte() to create mapping for 4KiB pages.

Signed-off-by: Allen Kay 
Signed-off-by: David Woodhouse 
Signed-off-by: Youquan Song 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: set iommu_superpage on VM domains to lowest common denominator

2011-12-21T20:57:37+00:00

commit 8140a95d228efbcd64d84150e794761a32463947 upstream.

set dmar->iommu_superpage field to the smallest common denominator
of super page sizes supported by all active VT-d engines.  Initialize
this field in intel_iommu_domain_init() API so intel_iommu_map() API
will be able to use iommu_superpage field to determine the appropriate
super page size to use.

Signed-off-by: Allen Kay 
Signed-off-by: David Woodhouse 
Signed-off-by: Youquan Song 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: fix return value of iommu_unmap() API

2011-12-21T20:57:37+00:00

commit 292827cb164ad00cc7689a21283b1261c0b6daed upstream.

iommu_unmap() API expects IOMMU drivers to return the actual page order
of the address being unmapped.  Previous code was just returning page
order passed in from the caller.  This patch fixes this problem.

Signed-off-by: Allen Kay 
Signed-off-by: David Woodhouse 
Signed-off-by: Youquan Song 
Signed-off-by: Greg Kroah-Hartman

PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs

2011-12-09T16:52:22+00:00

commit 4cac2eb158c6da0c761689345c6cc5df788a6292 upstream.

Previously we claimed device ID 0x7450, regardless of the vendor, which is
clearly wrong.  Now we'll claim that device ID only for AMD.

I suspect this was just a typo in the original code, but it's possible this
change will break shpchp on non-7450 AMD bridges.  If so, we'll have to fix
them as we find them.

Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863
Reported-by: Ralf Jung 
Cc: Joerg Roedel 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

xen-pcifront: Update warning comment to use 'e820_host' option.

2011-11-11T17:35:46+00:00

commit 917e3e65c35459d52f0d0b890aa5df0cad07a051 upstream.

With Xen changeset 23428 "libxl: Add 'e820_host' option to config file"
the E820 as seen from the host can now be passed into the guest.
This means that a PV guest can now:
 - Use the correct PCI I/O gap. Before these patches, Linux guest would
   boot up and would tell:
   [    0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:c0000000)
   while in actuality the PCI I/O gap should have been:
   [    0.000000] Allocating PCI resources starting at b0000000 (gap: b0000000:4c000000)

 - The PV domain with PCI devices was limited to 3GB. It now can be booted
   with 4GB, 8GB, or whatever number you want. The PCI devices will now _not_ conflict
   with System RAM. Meaning the drivers can load.

CC: Jesse Barnes 
CC: linux-pci@vger.kernel.org
[v2: Made the string less broken up. Suggested by Joe Perches]
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

PCI quirk: mmc: Always check for lower base frequency quirk for Ricoh 1180:e823

2011-11-11T17:35:23+00:00

commit 3e309cdf07c930f29a4e0f233e47d399bea34c68 upstream.

Commit 15bed0f2f added a quirk for the e823 Ricoh card reader to lower the
base frequency.  However, the quirk first checks to see if the proprietary
MMC controller is disabled, and returns if so.  On some devices, such as the
Lenovo X220, the MMC controller is already disabled by firmware it seems,
but the frequency change is still needed so sdhci-pci can talk to the cards.
Since the MMC controller is disabled, the frequency fixup was never being run
on these machines.

This moves the e823 check above the MMC controller check so that it always
gets run.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=722509

Signed-off-by: Josh Boyer 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

x86, iommu: Mark DMAR IRQ as non-threaded

2011-10-03T18:40:29+00:00

commit 477694e71113fd0694b6bb0bcc2d006b8ac62691 upstream.

Mark this lowlevel IRQ handler as non-threaded. This prevents a boot
crash when "threadirqs" is on the kernel commandline. Also the
interrupt handler is handling hardware critical events which should
not be delayed into a thread.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

PCI: ARI is a PCIe v2 feature

2011-08-05T04:58:38+00:00

commit 864d296cf948aef0fa32b81407541572583f7572 upstream.

The function pci_enable_ari() may mistakenly set the downstream port
of a v1 PCIe switch in ARI Forwarding mode.  This is a PCIe v2 feature,
and with an SR-IOV device on that switch port believing the switch above
is ARI capable it may attempt to use functions 8-255, translating into
invalid (non-zero) device numbers for that bus.  This has been seen
to cause Completion Timeouts and general misbehaviour including hangs
and panics.

Acked-by: Don Dutile 
Tested-by: Don Dutile 
Signed-off-by: Chris Wright 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

mmc: Added quirks for Ricoh 1180:e823 lower base clock frequency

2011-08-05T04:58:31+00:00

commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 upstream.

Ricoh 1180:e823 does not recognize certain types of SD/MMC cards,
as reported at http://launchpad.net/bugs/773524.  Lowering the SD
base clock frequency from 200Mhz to 50Mhz fixes this issue. This
solution was suggest by Koji Matsumuro, Ricoh Company, Ltd.

This change has no negative performance effect on standard SD
cards, though it's quite possible that there will be one on
UHS-1 cards.

Signed-off-by: Manoj Iyer 
Tested-by: Daniel Manrique 
Cc: Koji Matsumuro 
Acked-by: Jesse Barnes 
Signed-off-by: Chris Ball 
Signed-off-by: Greg Kroah-Hartman