linux-toradex.git/arch/x86/kernel/pci-calgary_64.c, branch v3.2.8

treewide: Convert uses of struct resource to resource_size(ptr)

2011-06-10T12:55:36+00:00

Several fixes as well where the +1 was missing.

Done via coccinelle scripts like:

@@
struct resource *ptr;
@@

- ptr->end - ptr->start + 1
+ resource_size(ptr)

and some grep and typing.

Mostly uncompiled, no cross-compilers.

Signed-off-by: Joe Perches 
Signed-off-by: Jiri Kosina

x86: Fix common misspellings

2011-03-18T09:39:30+00:00

They were generated by 'codespell' and then manually reviewed.

Signed-off-by: Lucas De Marchi 
Cc: trivial@kernel.org
LKML-Reference: <1300389856-1099-3-git-send-email-lucas.demarchi@profusion.mobi>
Signed-off-by: Ingo Molnar

x86, calgary: Make Calgary IOMMU use IOMMU_INIT_* macros.

2010-08-26T22:14:15+00:00

We utilize the IOMMU_INIT macros to create this dependency:

     [pci_xen_swiotlb_detect]
         |
     [pci_swiotlb_detect_override]
         |
     [pci_swiotlb_detect_4gb]
         |
      [detect_calgary]

Meaning that 'detect_calgary' is going to be called after
'pci_swiotlb_detect'.

Signed-off-by: Konrad Rzeszutek Wilk 
LKML-Reference: <1282845485-8991-8-git-send-email-konrad.wilk@oracle.com>
CC: Muli Ben-Yehuda 
CC: "Jon D. Mason" 
CC: "Darrick J. Wong" 
CC: Fujita Tomonori 
Signed-off-by: H. Peter Anvin

x86, iommu: Make all IOMMU's detection routines return a value.

2010-08-26T22:13:13+00:00

We return 1 if the IOMMU has been detected. Zero or an error number
if we failed to find it. This is in preperation of using the IOMMU_INIT
so that we can detect whether an IOMMU is present. I have not
tested this for regression on Calgary, nor on AMD Vi chipsets as
I don't have that hardware.

CC: Muli Ben-Yehuda 
CC: "Jon D. Mason" 
CC: "Darrick J. Wong" 
CC: Jesse Barnes 
CC: David Woodhouse 
CC: Chris Wright 
CC: Yinghai Lu 
CC: Joerg Roedel 
CC: H. Peter Anvin 
CC: Fujita Tomonori 
Signed-off-by: Konrad Rzeszutek Wilk 
LKML-Reference: <1282845485-8991-3-git-send-email-konrad.wilk@oracle.com>
Signed-off-by: H. Peter Anvin

x86, Calgary: Limit the max PHB number to 256

2010-07-01T05:41:42+00:00

The x3950 family can have as many as 256 PCI buses in a single system, so
change the limits to the maximum.  Since there can only be 256 PCI buses in one
domain, we no longer need the BUG_ON check.

Signed-off-by: Darrick J. Wong 
LKML-Reference: <20100701004519.GQ15515@tux1.beaverton.ibm.com>
Signed-off-by: H. Peter Anvin

x86, Calgary: Increase max PHB number

2010-06-25T14:14:58+00:00

Newer systems (x3950M2) can have 48 PHBs per chassis and 8
chassis, so bump the limits up and provide an explanation
of the requirements for each class.

Signed-off-by: Darrick J. Wong 
Acked-by: Muli Ben-Yehuda 
Cc: Corinna Schultz 
Cc: 
LKML-Reference: <20100624212647.GI15515@tux1.beaverton.ibm.com>
[ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ]
Signed-off-by: Ingo Molnar

tree-wide: Assorted spelling fixes

2010-02-09T10:13:56+00:00

In particular, several occurances of funny versions of 'success',
'unknown', 'therefore', 'acknowledge', 'argument', 'achieve', 'address',
'beginning', 'desirable', 'separate' and 'necessary' are fixed.

Signed-off-by: Daniel Mack 
Cc: Joe Perches 
Cc: Junio C Hamano 
Signed-off-by: Jiri Kosina

iommu-helper: use bitmap library

2009-12-16T15:20:18+00:00

Use bitmap library and kill some unused iommu helper functions.

1. s/iommu_area_free/bitmap_clear/

2. s/iommu_area_reserve/bitmap_set/

3. Use bitmap_find_next_zero_area instead of find_next_zero_area

  This cannot be simple substitution because find_next_zero_area
  doesn't check the last bit of the limit in bitmap

4. Remove iommu_area_free, iommu_area_reserve, and find_next_zero_area

Signed-off-by: Akinobu Mita 
Cc: "David S. Miller" 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: FUJITA Tomonori 
Cc: Joerg Roedel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking up the PCI tree

2009-12-03T10:44:05+00:00

On a multi-node x3950M2 system, there's a slight oddity in the
PCI device tree for all secondary nodes:

 30:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
  \-33:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
     \-34:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)

...as compared to the primary node:

 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
  \-01:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
 03:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
  \-04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)

In both nodes, the LSI RAID controller hangs off a CalIOC2
device, but on the secondary nodes, the BIOS hides the VGA
device and substitutes the device tree ending with the disk
controller.

It would seem that Calgary devices don't necessarily appear at
the top of the PCI tree, which means that the current code to
find the Calgary IOMMU that goes with a particular device is
buggy.

Rather than walk all the way to the top of the PCI
device tree and try to match bus number with Calgary descriptor,
the code needs to examine each parent of the particular device;
if it encounters a Calgary with a matching bus number, simply
use that.

Otherwise, we BUG() when the bus number of the Calgary doesn't
match the bus number of whatever's at the top of the device tree.

Extra note: This patch appears to work correctly for the x3950
that came before the x3950 M2.

Signed-off-by: Darrick J. Wong 
Acked-by: Muli Ben-Yehuda 
Cc: FUJITA Tomonori 
Cc: Joerg Roedel 
Cc: Yinghai Lu 
Cc: Jon D. Mason 
Cc: Corinna Schultz 
Cc: 
LKML-Reference: <20091202230556.GG10295@tux1.beaverton.ibm.com>
Signed-off-by: Ingo Molnar

x86: Calgary: Remove unnecessary DMA_ERROR_CODE usage

2009-11-17T06:53:21+00:00

This cleans up iommu_alloc() a bit and removes unnecessary
DMA_ERROR_CODE usage.

Signed-off-by: FUJITA Tomonori 
Acked-by: Jesse Barnes 
Cc: muli@il.ibm.com
Cc: joerg.roedel@amd.com
LKML-Reference: <1258287594-8777-4-git-send-email-fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Ingo Molnar