Eric Lee / smarc-fsl-linux-kernel

11 Aug, 2010

1 commit

  • 3b9c6c11f   dma-mapping: remove dma_is_consistent API ... Browse Code »

    Architectures implement dma_is_consistent() in different ways (some
    misinterpret the definition of API in DMA-API.txt). So it hasn't been so
    useful for drivers. We have only one user of the API in tree. Unlikely
    out-of-tree drivers use the API.

    Even if we fix dma_is_consistent() in some architectures, it doesn't look
    useful at all. It was invented long ago for some old systems that can't
    allocate coherent memory at all. It's better to export only APIs that are
    definitely necessary for drivers.

    Let's remove this API.

    Signed-off-by: FUJITA Tomonori
    Cc: James Bottomley
    Reviewed-by: Konrad Rzeszutek Wilk
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     

27 Jul, 2008

1 commit

  • 8d8bb39b9   dma-mapping: add the device argument to dma_mapping_error() ... Browse Code »

    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: FUJITA Tomonori
    Cc: Muli Ben-Yehuda
    Cc: Andi Kleen
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Avi Kivity
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     

17 Jul, 2007

1 commit

  • 1b0fac458   dma-mapping: prevent dma dependent code from linking on !HAS_DMA archs ... Browse Code »

    Continuing the work started in 411f0f3edc141a582190d3605cadd1d993abb6df ...

    This enables code with a dma path, that compiles away, to build without
    requiring additional code factoring. It also prevents code that calls
    dma_alloc_coherent and dma_free_coherent from linking whereas previously
    the code would hit a BUG() at run time. Finally, it allows archs that set
    !HAS_DMA to delete their asm/dma-mapping.h file.

    Cc: Cornelia Huck
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Cc: John W. Linville
    Cc: Kyle McMartin
    Cc: James Bottomley
    Cc: Tejun Heo
    Cc: Jeff Garzik
    Cc:
    Cc:
    Cc:
    Cc:
    Signed-off-by: Dan Williams
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dan Williams
     

12 Feb, 2007

1 commit

  • 509cb37e1   [PATCH] one more iomap s390 build fix ... Browse Code »

    Commit 9ac7849e35f705830f7b016ff272b0ff1f7ff759 causes this on S390:

    drivers/built-in.o: In function `dmam_noncoherent_release':
    dma-mapping.c:(.text+0x1515c): undefined reference to `dma_free_noncoherent'
    drivers/built-in.o: In function `dmam_free_noncoherent':
    undefined reference to `dma_free_noncoherent'
    drivers/built-in.o: In function `dmam_alloc_noncoherent':
    undefined reference to `dma_alloc_noncoherent'
    make: *** [.tmp_vmlinux1] Error 1

    Cc: Tejun Heo
    Acked-by: Jeff Garzik
    Cc: Martin Schwidefsky
    Signed-off-by: Heiko Carstens
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     

28 Oct, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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!

    Linus Torvalds