13 Feb, 2014

1 commit

  • Enabling some of the mvebu platforms in the multiplatform config for ARM
    enabled these drivers, which also triggered a bunch of warnings when LPAE
    is enabled (thus making phys_addr_t 64-bit).

    Most changes are switching printk formats, but also a bit of changes to what
    used to be array-based pointer arithmetic that could just be done with the
    address types instead.

    The warnings were:

    drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
    drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
    'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
    drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
    drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
    different size [-Wint-to-pointer-cast]
    drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
    different size [-Wpointer-to-int-cast]
    drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
    drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
    'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
    drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
    'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
    drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
    drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
    'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]

    Acked-by: Vinod Koul
    Acked-by: Jason Cooper
    Signed-off-by: Olof Johansson

    Olof Johansson
     

13 Dec, 2013

3 commits

  • When a channel fails to initialise, we error out and clean up any
    previously unregistered channels by walking the entire xordev->channels
    array. Unfortunately, there are paths which end up storing an error
    pointer in this array, which we then try and dereference in the cleanup
    code, which causes an oops.

    Fix this by avoiding writing invalid pointers to this array in the first
    place.

    Tested-by: Aaro Koskinen
    Signed-off-by: Russell King
    Signed-off-by: Dan Williams

    Russell King
     
  • The driver-specific unmap code was removed in:

    commit 54f8d501e842879143e867e70996574a54d1e130
    Author: Bartlomiej Zolnierkiewicz
    Date: Fri Oct 18 19:35:32 2013 +0200

    dmaengine: remove DMA unmap from drivers

    which had the side-effect of not unmapping the self-test mappings.
    Fix this by using dmaengine_unmap_data in the self-test routines.

    In addition, since dmaengine_unmap() assumes that all mappings were created
    with dma_map_page, this commit changes the single mapping to a page mapping
    to avoid an incorrect unmapping of the memcpy self-test.

    The allocation could be changed to be alloc_page(), but sticking to kmalloc
    results in a less intrusive patch. The size of the test buffer is increased,
    since dma_map_page() seem to fail when the source and destination pages are
    the same page.

    Signed-off-by: Ezequiel Garcia
    Signed-off-by: Dan Williams

    Ezequiel Garcia
     
  • The following commit:

    54f8d501e842 dmaengine: remove DMA unmap from drivers

    removed the last caller to mv_desc_get_dest_addr(), creating the
    warning:

    drivers/dma/mv_xor.c:57:12: warning: mv_desc_get_dest_addr defined
    but not used [-Wunused-function]

    Remove it.

    Signed-off-by: Jason Cooper
    Acked-by: Vinod Koul
    Signed-off-by: Dan Williams

    Jason Cooper
     

16 Nov, 2013

1 commit

  • Pull dmaengine changes from Dan

    1/ Bartlomiej and Dan finalized a rework of the dma address unmap
    implementation.

    2/ In the course of testing 1/ a collection of enhancements to dmatest
    fell out. Notably basic performance statistics, and fixed / enhanced
    test control through new module parameters 'run', 'wait', 'noverify',
    and 'verbose'. Thanks to Andriy and Linus for their review.

    3/ Testing the raid related corner cases of 1/ triggered bugs in the
    recently added 16-source operation support in the ioatdma driver.

    4/ Some minor fixes / cleanups to mv_xor and ioatdma.

    Conflicts:
    drivers/dma/dmatest.c

    Signed-off-by: Vinod Koul

    Vinod Koul
     

15 Nov, 2013

3 commits

  • Despite requesting two memory resources, called 'base' and 'high_base', the
    driver uses explicitly only the former. The latter is being used implicitly
    by addressing at offset +0x200, which in practice accesses high_base.

    In other words, the current driver breaks if the second memory resource
    is ever place at an offset different from +0x200.

    This patch fixes the above by defining the registers with the offset from
    high_base, and use high_base explicitly where appropriate.

    Signed-off-by: Ezequiel Garcia
    Acked-by: Thomas Petazzoni
    Signed-off-by: Dan Williams

    Ezequiel Garcia
     
  • This mmio address is checked at probe-time, which makes this test
    redundant. Let's just remove it.

    Acked-by: Thomas Petazzoni
    Signed-off-by: Ezequiel Garcia
    Signed-off-by: Dan Williams

    Ezequiel Garcia
     
  • Remove support for DMA unmapping from drivers as it is no longer
    needed (DMA core code is now handling it).

    Cc: Vinod Koul
    Cc: Tomasz Figa
    Cc: Dave Jiang
    Signed-off-by: Bartlomiej Zolnierkiewicz
    Signed-off-by: Kyungmin Park
    [djbw: fix up chan2parent() unused warning in drivers/dma/dw/core.c]
    Signed-off-by: Dan Williams

    Bartlomiej Zolnierkiewicz
     

14 Nov, 2013

1 commit

  • Add a hook for a common dma unmap implementation to enable removal of
    the per driver custom unmap code. (A reworked version of Bartlomiej
    Zolnierkiewicz's patches to remove the custom callbacks and the size
    increase of dma_async_tx_descriptor for drivers that don't care about
    raid).

    Cc: Vinod Koul
    Cc: Tomasz Figa
    Cc: Dave Jiang
    [bzolnier: prepare pl330 driver for adding missing unmap while at it]
    Signed-off-by: Bartlomiej Zolnierkiewicz
    Signed-off-by: Kyungmin Park
    Signed-off-by: Dan Williams

    Dan Williams
     

25 Oct, 2013

1 commit


11 Sep, 2013

1 commit

  • Pull slave-dmaengine updates from Vinod Koul:
    "This pull brings:
    - Andy's DW driver updates
    - Guennadi's sh driver updates
    - Pl08x driver fixes from Tomasz & Alban
    - Improvements to mmp_pdma by Daniel
    - TI EDMA fixes by Joel
    - New drivers:
    - Hisilicon k3dma driver
    - Renesas rcar dma driver
    - New API for publishing slave driver capablities
    - Various fixes across the subsystem by Andy, Jingoo, Sachin etc..."

    * 'for-linus' of git://git.infradead.org/users/vkoul/slave-dma: (94 commits)
    dma: edma: Remove limits on number of slots
    dma: edma: Leave linked to Null slot instead of DUMMY slot
    dma: edma: Find missed events and issue them
    ARM: edma: Add function to manually trigger an EDMA channel
    dma: edma: Write out and handle MAX_NR_SG at a given time
    dma: edma: Setup parameters to DMA MAX_NR_SG at a time
    dmaengine: pl330: use dma_set_max_seg_size to set the sg limit
    dmaengine: dma_slave_caps: remove sg entries
    dma: replace devm_request_and_ioremap by devm_ioremap_resource
    dma: ste_dma40: Fix potential null pointer dereference
    dma: ste_dma40: Remove duplicate const
    dma: imx-dma: Remove redundant NULL check
    dma: dmagengine: fix function names in comments
    dma: add driver for R-Car HPB-DMAC
    dma: k3dma: use devm_ioremap_resource() instead of devm_request_and_ioremap()
    dma: imx-sdma: Staticize sdma_driver_data structures
    pch_dma: Add MODULE_DEVICE_TABLE
    dmaengine: PL08x: Add cyclic transfer support
    dmaengine: PL08x: Fix reading the byte count in cctl
    dmaengine: PL08x: Add support for different maximum transfer size
    ...

    Linus Torvalds
     

10 Sep, 2013

1 commit


23 Aug, 2013

2 commits

  • The mv_xor driver had never been used in a big-endian context, and
    therefore was not using the hardware features to support such an
    execution environment. The hardware provides a "descriptor swap" bit
    that automatically swaps the bytes of the DMA descriptors, within
    blocks of 8 bytes. This requires a different DMA descriptor layout on
    big-endian systems, as well as enabling this "descriptor swap" bit.

    This mechanism is exactly identical to the one already used in the
    mv643xx_eth network driver and the mvneta network driver.

    Signed-off-by: Thomas Petazzoni
    Signed-off-by: Dan Williams

    Thomas Petazzoni
     
  • In order to support big-endian execution, the mv_xor driver is changed
    to use the readl_relaxed() and writel_relaxed() accessors that
    properly convert from the CPU endianess to the device endianess (which
    in the case of Marvell XOR hardware is always little-endian).

    Signed-off-by: Thomas Petazzoni
    Signed-off-by: Dan Williams

    Thomas Petazzoni
     

13 Aug, 2013

2 commits


04 Jul, 2013

1 commit

  • There have never been any real users of MEMSET operations since they
    have been introduced in January 2007 by commit 7405f74badf4 ("dmaengine:
    refactor dmaengine around dma_async_tx_descriptor"). Therefore remove
    support for them for now, it can be always brought back when needed.

    [sebastian.hesselbarth@gmail.com: fix drivers/dma/mv_xor]
    Signed-off-by: Bartlomiej Zolnierkiewicz
    Signed-off-by: Kyungmin Park
    Signed-off-by: Sebastian Hesselbarth
    Cc: Vinod Koul
    Acked-by: Dan Williams
    Cc: Tomasz Figa
    Cc: Herbert Xu
    Cc: Olof Johansson
    Cc: Kevin Hilman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bartlomiej Zolnierkiewicz
     

27 Feb, 2013

1 commit

  • Pull slave-dmaengine updates from Vinod Koul:
    "This is fairly big pull by my standards as I had missed last merge
    window. So we have the support for device tree for slave-dmaengine,
    large updates to dw_dmac driver from Andy for reusing on different
    architectures. Along with this we have fixes on bunch of the drivers"

    Fix up trivial conflicts, usually due to #include line movement next to
    each other.

    * 'next' of git://git.infradead.org/users/vkoul/slave-dma: (111 commits)
    Revert "ARM: SPEAr13xx: Pass DW DMAC platform data from DT"
    ARM: dts: pl330: Add #dma-cells for generic dma binding support
    DMA: PL330: Register the DMA controller with the generic DMA helpers
    DMA: PL330: Add xlate function
    DMA: PL330: Add new pl330 filter for DT case.
    dma: tegra20-apb-dma: remove unnecessary assignment
    edma: do not waste memory for dma_mask
    dma: coh901318: set residue only if dma is in progress
    dma: coh901318: avoid unbalanced locking
    dmaengine.h: remove redundant else keyword
    dma: of-dma: protect list write operation by spin_lock
    dmaengine: ste_dma40: do not remove descriptors for cyclic transfers
    dma: of-dma.c: fix memory leakage
    dw_dmac: apply default dma_mask if needed
    dmaengine: ioat - fix spare sparse complain
    dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c
    ioatdma: fix race between updating ioat->head and IOAT_COMPLETION_PENDING
    dw_dmac: add support for Lynxpoint DMA controllers
    dw_dmac: return proper residue value
    dw_dmac: fill individual length of descriptor
    ...

    Linus Torvalds
     

08 Jan, 2013

1 commit


07 Jan, 2013

2 commits

  • When a channel fails to initialize, we release all ressources,
    including clocks. However, a XOR unit is not necessarily associated to
    a clock (some variants of Marvell SoCs have a clock for XOR units,
    some don't), so we shouldn't unconditionally be releasing the clock.

    Instead, just like we do in the mv_xor_remove() function, we should
    check if one clock was found before releasing it.

    Signed-off-by: Thomas Petazzoni
    Signed-off-by: Jason Cooper

    Thomas Petazzoni
     
  • When mv_xor_channel_add() fails for one XOR channel, we jump to the
    err_channel_add label to clean up all previous channels that had been
    initialized correctly. Unfortunately, while handling this error
    condition, we were disposing the IRQ mapping before calling
    mv_xor_channel_remove() (which does the free_irq()), which is
    incorrect.

    Instead, do things properly in the reverse order of the
    initialization: first remove the XOR channel (so that free_irq() is
    done), and then dispose the IRQ mapping.

    This avoids ugly warnings when for some reason one of the XOR channel
    fails to initialize.

    Signed-off-by: Thomas Petazzoni
    Signed-off-by: Jason Cooper

    Thomas Petazzoni
     

15 Dec, 2012

1 commit

  • Pull ARM SoC updates for Marvell mvebu/kirkwood from Olof Johansson:
    "This is a branch with updates for Marvell's mvebu/kirkwood platforms.
    They came in late-ish, and were heavily interdependent such that it
    didn't make sense to split them up across the cross-platform topic
    branches. So here they are (for the second release in a row) in a
    branch on their own."

    * tag 'mvebu' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (88 commits)
    arm: l2x0: add aurora related properties to OF binding
    arm: mvebu: add Aurora L2 Cache Controller to the DT
    arm: mvebu: add L2 cache support
    dma: mv_xor: fix error handling path
    dma: mv_xor: fix error checking of irq_of_parse_and_map()
    dma: mv_xor: use request_irq() instead of devm_request_irq()
    dma: mv_xor: clear the window override control registers
    arm: mvebu: fix address decoding armada_cfg_base() function
    ARM: mvebu: update defconfig with I2C and RTC support
    ARM: mvebu: Add SATA support for OpenBlocks AX3-4
    ARM: mvebu: Add support for the RTC in OpenBlocks AX3-4
    ARM: mvebu: Add support for I2C on OpenBlocks AX3-4
    ARM: mvebu: Add support for I2C controllers in Armada 370/XP
    arm: mvebu: Add hardware I/O Coherency support
    arm: plat-orion: Add coherency attribute when setup mbus target
    arm: dma mapping: Export a dma ops function arm_dma_set_mask
    arm: mvebu: Add SMP support for Armada XP
    arm: mm: Add support for PJ4B cpu and init routines
    arm: mvebu: Add IPI support via doorbells
    arm: mvebu: Add initial support for power managmement service unit
    ...

    Linus Torvalds
     

29 Nov, 2012

2 commits


23 Nov, 2012

4 commits

  • The ->probe() function of the mv_xor function contains in its error
    handling code a loop to cleanup the XOR channels that had been
    successfully initialized if some other XOR channel fails to be
    initialized. It does that by traveling the list of XOR channels, and
    cleanup those for which the pointer is not NULL.

    However, since the mv_xor_channel_add() function return a PTR_ERR
    style value, the pointer is not NULL on error. So, when handling the
    error of a given channel initialization, we cleanup this channel
    initialization and mark this channel entry as NULL in the array. This
    allows the remaining of the cleanup (for other channels) to work
    properly.

    Signed-off-by: Thomas Petazzoni

    Thomas Petazzoni
     
  • The irq_of_parse_and_map() function returns 0 on failure, and does not
    return an error code, so we fix the calling site of
    irq_of_parse_and_map() in the mv_xor driver.

    Signed-off-by: Thomas Petazzoni

    Thomas Petazzoni
     
  • Even through the usage of devm_*() functions is generally recommended
    over their classic variants, in the case of devm_request_irq()
    combined with irq_of_parse_and_map(), it doesn't work nicely.

    We have the following scenario:

    irq_of_parse_and_map(...)
    devm_request_irq(...)

    For some reason, the driver initialization fails at a later
    point. Since irq_of_parse_and_map() is no device-managed, we do a:

    irq_dispose_mapping(...)

    Unfortunately, this doesn't work, because the free_irq() must be done
    prior to calling irq_dispose_mapping(). But with the devm mechanism,
    the automatic free_irq() would happen only after we get out of the
    ->probe() function.

    So basically, we revert to using request_irq() with traditional error
    handling, so that in case of error, free_irq() gets called before
    irq_dispose_mapping().

    Signed-off-by: Thomas Petazzoni

    Thomas Petazzoni
     
  • The XOR channels on Marvell SoCs have a Window Override Control
    register that allow to do some fancy things with addresses. Those
    features are not used by the driver, but some U-Boot versions anyway
    modify those registers.

    For some reason, the U-Boot on OpenBlocks AX3-4 was setting an invalid
    value in those registers when the addition 2 GB DRAM chip was plugged
    into the board, causing the XOR driver to fail in using the XOR
    engines.

    By setting those registers to 0 during the driver initialization, we
    ensure that the registers are configured according with the driver
    operation model.

    Thanks to Lior Amsalem for his help in debugging
    this problem.

    Signed-off-by: Thomas Petazzoni

    Thomas Petazzoni
     

20 Nov, 2012

12 commits