Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 06 1月, 2009 7 次提交
  3. 05 11月, 2008 1 次提交
  5. 20 10月, 2008 1 次提交
  7. 27 7月, 2008 1 次提交
    • F
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      由 FUJITA Tomonori 提交于 
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
architecture does:

This enables us to cleanly fix the Calgary IOMMU issue that some devices
are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).

I think that per-device dma_mapping_ops support would be also helpful for
KVM people to support PCI passthrough but Andi thinks that this makes it
difficult to support the PCI passthrough (see the above thread).  So I
CC'ed this to KVM camp.  Comments are appreciated.

A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
NULL, the system-wide dma_ops pointer is used as before.

If it's useful for KVM people, I plan to implement a mechanism to register
a hook called when a new pci (or dma capable) device is created (it works
with hot plugging).  It enables IOMMUs to set up an appropriate
dma_mapping_ops per device.

The major obstacle is that dma_mapping_error doesn't take a pointer to the
device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
device.  Note all the POWER IOMMUs use the same dma_mapping_error function
so this is not a problem for POWER but x86 IOMMUs use different
dma_mapping_error functions.

The first patch adds the device argument to dma_mapping_error.  The patch
is trivial but large since it touches lots of drivers and dma-mapping.h in
all the architecture.

This patch:

dma_mapping_error() doesn't take a pointer to the device unlike other DMA
operations.  So we can't have dma_mapping_ops per device.

Note that POWER already has dma_mapping_ops per device but all the POWER
IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
argument.

[akpm@linux-foundation.org: fix sge]
[akpm@linux-foundation.org: fix svc_rdma]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix bnx2x]
[akpm@linux-foundation.org: fix s2io]
[akpm@linux-foundation.org: fix pasemi_mac]
[akpm@linux-foundation.org: fix sdhci]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix sparc]
[akpm@linux-foundation.org: fix ibmvscsi]
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Avi Kivity <avi@qumranet.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  9. 29 4月, 2008 2 次提交
  11. 10 4月, 2008 1 次提交
  13. 07 3月, 2008 1 次提交
  15. 06 2月, 2008 1 次提交
  17. 05 2月, 2008 1 次提交
  19. 20 12月, 2007 1 次提交
  21. 23 10月, 2007 1 次提交
  23. 17 10月, 2007 1 次提交
  25. 16 10月, 2007 1 次提交
  27. 13 10月, 2007 1 次提交
    • B
      [IA64] add driver for ACPI methods to call native firmware · 28eda5b8
      由 Bjorn Helgaas 提交于 
      This driver for HPQ5001 devices installs a global ACPI OpRegion handler.
AML methods can use this OpRegion to call native firmware entry points.

ACPI does not define a mechanism for AML methods to call native firmware
interfaces such as PAL or SAL.  This OpRegion handler adds such a mechanism.
After the handler is installed, an AML method can call native firmware by
storing the arguments and firmware entry point to specific offsets in the
OpRegion.  When AML reads the "return value" offset from the OpRegion, this
handler loads up the arguments, makes the firmware call, and returns the
result.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      28eda5b8
  29. 28 7月, 2007 1 次提交
  31. 14 7月, 2007 1 次提交
    • T
      [IA64] use machvec=dig on hpzx1 platforms · 51b58e3e
      由 Terry Loftin 提交于 
      On HP zx1 machines, the 'machvec=dig' parameter is needed for the
kdump kernel to avoid problems with the HP sba iommu.  The problem
is that during the boot of the kdump kernel, the iommu is re-initialized,
so in-flight DMA from improperly shutdown drivers causes an IOTLB
miss which leads to an MCA.  With kdump, the idea is to get into the
kdump kernel with as little code as we can, so shutting down drivers
properly is not an option.

The workaround is to add 'machvec=dig' to the kdump kernel boot
parameters.  This makes the kdump kernel avoid using the sba iommu
altogether, leaving the IOTLB intact.  Any ongoing DMA falls
harmlessly outside the kdump kernel.  After the kdump kernel reboots,
all devices will have been shutdown properly and DMA stopped.

This patch pushes that functionality into the sba iommu
initialization code, so that users won't have to find the obscure
documentation telling them about 'machvec=dig'.

This patch only affects HP platforms.  It still includes one
extern declaration in the file, because no applicable header file
exists.
Signed-off-by: NTerry Loftin <terry.loftin@hp.com>
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      51b58e3e
  33. 11 5月, 2007 1 次提交
  35. 13 2月, 2007 1 次提交
  37. 06 2月, 2007 1 次提交
  39. 08 12月, 2006 1 次提交
  41. 30 11月, 2006 1 次提交
  43. 01 7月, 2006 1 次提交
  45. 23 6月, 2006 1 次提交
  47. 02 4月, 2006 1 次提交
    • L
      ACPI: ia64 buildfix · 144c87b4
      由 Len Brown 提交于 
      arch/ia64/hp/common/sba_iommu.c used ACPI_MEM_FREE instead of kfree()

Signed-off-by: Len Brown <len.brown@intel.com
      144c87b4
  49. 28 10月, 2005 1 次提交
  51. 15 9月, 2005 1 次提交
    • A
      [IA64] more robust zx1/sx1000 machvec support · 0b9afede
      由 Alex Williamson 提交于 
      Machine vector selection has always been a bit of a hack given how
early in system boot it needs to be done.  Services like ACPI namespace
are not available and there are non-trivial problems to moving them to
early boot.  However, there's no reason we can't change to a different
machvec later in boot when the services we need are available.  By
adding a entry point for later initialization of the swiotlb, we can add
an error path for the hpzx1 machevec initialization and fall back to the
DIG machine vector if IOMMU hardware isn't found in the system.  Since
ia64 uses 4GB for zone DMA (no ISA support), it's trivial to allocate a
contiguous range from the slab for bounce buffer usage.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      0b9afede
  53. 29 6月, 2005 1 次提交
  55. 04 5月, 2005 1 次提交
  57. 26 4月, 2005 1 次提交
    • A
      [IA64] sba_iommu bug fixes · 5f6602a1
      由 Alex Williamson 提交于 
         This fixes a couple of bugs in the zx1/sx1000 sba_iommu.  These are
all pretty low likelihood of hitting.  The first problem is a simple off
by one, deep in the sba_alloc_range() error path.  Surrounding that was
a lock ordering problem that could have potentially deadlocked with the
order the locks are grabbed in sba_unmap_single().  I moved the resource
locking into sba_search_bitmap() to prevent this.  Finally, there's a
potential race between unmapping pdir entries and marking incoming DMA
pages clean.  If you see any oddities, please let me know, but I've
tested it pretty thoroughly here.  Tony, please apply.  Thanks,

BTW, many of the options in this driver not on by default are becoming
more and more broken.  I'll be working on some patches to clean them
out, but I wanted to get this bug fix out first.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      5f6602a1
  59. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4