08 Jul, 2013

1 commit

  • Pull slave-dmaengine updates from Vinod Koul:
    "Once you have some time from extended weekend celebrations please
    consider pulling the following to get:
    - Various fixes and PCI driver for dw_dmac by Andy
    - DT binding for imx-dma by Markus & imx-sdma by Shawn
    - DT fixes for dmaengine by Lars
    - jz4740 dmac driver by Lars
    - and various fixes across the drivers"

    What "extended weekend celebrations"? I'm in the merge window, who has
    time for extended celebrations..

    * 'for-linus' of git://git.infradead.org/users/vkoul/slave-dma: (40 commits)
    DMA: shdma: add DT support
    DMA: shdma: shdma_chan_filter() has to be in shdma-base.h
    DMA: shdma: (cosmetic) don't re-calculate a pointer
    dmaengine: at_hdmac: prepare clk before calling enable
    dmaengine/trivial: at_hdmac: add curly brackets to if/else expressions
    dmaengine: at_hdmac: remove unsuded atc_cleanup_descriptors()
    dmaengine: at_hdmac: add FIFO configuration parameter to DMA DT binding
    ARM: at91: dt: add header to define at_hdmac configuration
    MIPS: jz4740: Correct clock gate bit for DMA controller
    MIPS: jz4740: Remove custom DMA API
    MIPS: jz4740: Register jz4740 DMA device
    dma: Add a jz4740 dmaengine driver
    MIPS: jz4740: Acquire and enable DMA controller clock
    dma: mmp_tdma: disable irq when disabling dma channel
    dmaengine: PL08x: Avoid collisions with get_signal() macro
    dmaengine: dw: select DW_DMAC_BIG_ENDIAN_IO automagically
    dma: dw: add PCI part of the driver
    dma: dw: split driver to library part and platform code
    dma: move dw_dmac driver to an own directory
    dw_dmac: don't check resource with devm_ioremap_resource
    ...

    Linus Torvalds
     

05 Jul, 2013

1 commit

  • Use the wrapper functions for getting and setting the driver data using
    platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
    so we can directly pass a struct platform_device.

    Also, unnecessary dev_set_drvdata() is removed, because the driver core
    clears the driver data to NULL after device_release or on probe failure.

    Signed-off-by: Jingoo Han
    Signed-off-by: Vinod Koul

    Jingoo Han
     

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
     

04 Jan, 2013

1 commit

  • CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
    markings need to be removed.

    This change removes the use of __devinit, __devexit_p, __devinitconst,
    and __devexit from these drivers.

    Based on patches originally written by Bill Pemberton, but redone by me
    in order to handle some of the coding style issues better, by hand.

    Cc: Bill Pemberton
    Cc: Viresh Kumar
    Cc: Dan Williams
    Cc: Vinod Koul
    Cc: Barry Song
    Cc: Jeff Kirsher
    Cc: Alexander Duyck
    Cc: Russell King
    Cc: Linus Walleij
    Cc: Jassi Brar
    Cc: Dave Jiang
    Cc: Bill Pemberton
    Cc: Guennadi Liakhovetski
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

29 Nov, 2012

2 commits


01 Sep, 2012

1 commit


13 Mar, 2012

6 commits

  • Ensure all DMA engine drivers initialize their cookies in the same way,
    so that they all behave in a similar fashion. This means their first
    issued cookie will be 2 rather than 1, and will increment to INT_MAX
    before returning 1 and starting over.

    In connection with this, Dan Williams said:
    > Russell King wrote:
    > > Secondly, some DMA engine drivers initialize the dma_chan cookie to 0,
    > > others to 1.  Is there a reason for this, or are these all buggy?
    >
    > I know that ioat and iop-adma expect 0 to mean "I have cleaned up this
    > descriptor and it is idle", and would break if zero was an in-flight
    > cookie value. The reserved usage of zero is an driver internal
    > concern, but I have no problem formalizing it as a reserved value.

    Signed-off-by: Russell King
    Tested-by: Linus Walleij
    Reviewed-by: Linus Walleij
    Acked-by: Jassi Brar
    [imx-sdma.c & mxs-dma.c]
    Tested-by: Shawn Guo
    Signed-off-by: Vinod Koul

    Russell King - ARM Linux
     
  • Dan Williams said:
    > > Russell King wrote:
    > > Firstly, we have DMA_MIN_COOKIE which has value 1 - so any cookies below
    > > that aren't valid.  That seems sane.
    > >
    > > We seem to have different behaviours:
    > >
    > > -       cookie = c->cookie;
    > > -       cookie++;
    > > -       if (cookie < 0)
    > > -               cookie = 1;
    > > -       c->cookie = cookie;
    > > -       tx->cookie = cookie;
    > >
    > > c->cookie here is initialized to zero, so the first cookie given out will
    > > be 1.  This is how most DMA engine drivers implement this.
    > >
    > > Then we have this:
    > >
    > >                cookie = chan->common.cookie;
    > >                cookie++;
    > >                if (cookie >                        cookie = 2;
    > >
    > >                /* initialize the completed cookie to be less than
    > >                 * the most recently used cookie
    > >                 */
    > >                chan->common.completed_cookie = cookie - 1;
    > >                chan->common.cookie = sw_desc->async_tx.cookie = cookie;
    > >
    > > Again, chan->common.cookie starts off at 0.  The first cookie given out
    > > will be 2, and 1 will never be used.  There are three drivers which
    > > implement it this way.
    > >
    > > Why is there this difference, and can these three be corrected to behave
    > > the same way as the first (and therefore the assignment of cookies
    > > consolidated?)
    >
    > Yes, they should be consolidated, and I believe they have drifted only
    > because there were no good common helpers and murphy's law took over.

    So lets fix this up to use the common dma_cookie_assign() helper.

    Signed-off-by: Russell King
    Tested-by: Linus Walleij
    Reviewed-by: Linus Walleij
    Acked-by: Jassi Brar
    [imx-sdma.c & mxs-dma.c]
    Tested-by: Shawn Guo
    Signed-off-by: Vinod Koul

    Russell King - ARM Linux
     
  • Now that we have the completed cookie in the dma_chan structure, we
    can consolidate the tx_status functions by providing a function to set
    the txstate structure and returning the DMA status. We also provide
    a separate helper to set the residue for cookies which are still in
    progress.

    Signed-off-by: Russell King
    Tested-by: Linus Walleij
    Reviewed-by: Linus Walleij
    Acked-by: Jassi Brar
    [imx-sdma.c & mxs-dma.c]
    Tested-by: Shawn Guo
    Signed-off-by: Vinod Koul

    Russell King - ARM Linux
     
  • Everyone deals with assigning DMA cookies in the same way (it's part of
    the API so they should be), so lets consolidate the common code into a
    helper function to avoid this duplication.

    Signed-off-by: Russell King
    Tested-by: Linus Walleij
    Reviewed-by: Linus Walleij
    Acked-by: Jassi Brar
    [imx-sdma.c & mxs-dma.c]
    Tested-by: Shawn Guo
    Signed-off-by: Vinod Koul

    Russell King - ARM Linux
     
  • Add a local private header file to contain definitions and declarations
    which should only be used by DMA engine drivers.

    We also fix linux/dmaengine.h to use LINUX_DMAENGINE_H to guard against
    multiple inclusion.

    Signed-off-by: Russell King
    Tested-by: Linus Walleij
    Reviewed-by: Linus Walleij
    Acked-by: Jassi Brar
    [imx-sdma.c & mxs-dma.c]
    Tested-by: Shawn Guo
    Signed-off-by: Vinod Koul

    Russell King - ARM Linux
     
  • Every DMA engine implementation declares a last completed dma cookie
    in their private dma channel structures. This is pointless, and
    forces driver specific code. Move this out into the common dma_chan
    structure.

    Signed-off-by: Russell King
    Tested-by: Linus Walleij
    Reviewed-by: Linus Walleij
    Acked-by: Jassi Brar
    [imx-sdma.c & mxs-dma.c]
    Tested-by: Shawn Guo
    Signed-off-by: Vinod Koul

    Russell King - ARM Linux
     

06 Apr, 2011

1 commit


31 Mar, 2011

1 commit


28 Feb, 2011

1 commit


05 Dec, 2010

1 commit


06 Aug, 2010

1 commit

  • of_device is just an alias for platform_device, so remove it entirely. Also
    replace to_of_device() with to_platform_device() and update comment blocks.

    This patch was initially generated from the following semantic patch, and then
    edited by hand to pick up the bits that coccinelle didn't catch.

    @@
    @@
    -struct of_device
    +struct platform_device

    Signed-off-by: Grant Likely
    Reviewed-by: David S. Miller

    Grant Likely
     

03 Jul, 2010

1 commit


03 Jun, 2010

1 commit


22 May, 2010

2 commits

  • Merging in current state of Linus' tree to deal with merge conflicts and
    build failures in vio.c after merge.

    Conflicts:
    drivers/i2c/busses/i2c-cpm.c
    drivers/i2c/busses/i2c-mpc.c
    drivers/net/gianfar.c

    Also fixed up one line in arch/powerpc/kernel/vio.c to use the
    correct node pointer.

    Signed-off-by: Grant Likely

    Grant Likely
     
  • .name, .match_table and .owner are duplicated in both of_platform_driver
    and device_driver. This patch is a removes the extra copies from struct
    of_platform_driver and converts all users to the device_driver members.

    This patch is a pretty mechanical change. The usage model doesn't change
    and if any drivers have been missed, or if anything has been fixed up
    incorrectly, then it will fail with a compile time error, and the fixup
    will be trivial. This patch looks big and scary because it touches so
    many files, but it should be pretty safe.

    Signed-off-by: Grant Likely
    Acked-by: Sean MacLennan

    Grant Likely
     

18 May, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

27 Mar, 2010

2 commits

  • Simple conditional struct filler to cut out some duplicated code.

    Signed-off-by: Dan Williams

    Dan Williams
     
  • Convert the device_is_tx_complete() operation on the
    DMA engine to a generic device_tx_status()operation which
    can return three states, DMA_TX_RUNNING, DMA_TX_COMPLETE,
    DMA_TX_PAUSED.

    [dan.j.williams@intel.com: update for timberdale]
    Signed-off-by: Linus Walleij
    Acked-by: Mark Brown
    Cc: Maciej Sosnowski
    Cc: Nicolas Ferre
    Cc: Pavel Machek
    Cc: Li Yang
    Cc: Guennadi Liakhovetski
    Cc: Paul Mundt
    Cc: Ralf Baechle
    Cc: Haavard Skinnemoen
    Cc: Magnus Damm
    Cc: Liam Girdwood
    Cc: Joe Perches
    Cc: Roland Dreier
    Signed-off-by: Dan Williams

    Linus Walleij
     

03 Feb, 2010

1 commit

  • The match_table field of the struct of_device_id is constant in
    so it is worth to make the initialization data also constant.

    The semantic match that finds this kind of pattern is as follows:
    (http://coccinelle.lip6.fr/)

    //
    @r@
    disable decl_init,const_decl_init;
    identifier I1, I2, x;
    @@
    struct I1 {
    ...
    const struct I2 *x;
    ...
    };
    @s@
    identifier r.I1, y;
    identifier r.x, E;
    @@
    struct I1 y = {
    .x = E,
    };
    @c@
    identifier r.I2;
    identifier s.E;
    @@
    const struct I2 E[] = ... ;
    @depends on !c@
    identifier r.I2;
    identifier s.E;
    @@
    + const
    struct I2 E[] = ...;
    //

    Signed-off-by: Márton Németh
    Cc: Julia Lawall
    Cc: cocci@diku.dk
    [dan.j.williams@intel.com: resolved conflict with recent fsldma updates]
    Signed-off-by: Dan Williams

    Márton Németh
     

12 Dec, 2009

1 commit