1. 09 12月, 2014 3 次提交
    • S
      dma: cppi41: add a delay while setting the TD bit · 754416e1
      Sebastian Andrzej Siewior 提交于
      The manual says that we need to (repeatedly) set the TearDown-bit for
      the endpoint in order to get the active transfer descriptor released.
      Doing this "real" quick over and over again seems to work but it also
      seems that the hardware might not have enough time to breathe. So I
      though, hey lets add a udelay() between between the individual sets
      of the bit.
      This change with the g_zero testcase resulted in a warning about missing
      transfer descriptor (we got the tear-down one). It seems that if the
      hardware has some time it manages to release the transfer-descriptor on
      the completion queue after the teaddown descriptor.
      With this change, I observe that the transfer descriptor is released
      after 20-30 retry loops.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      754416e1
    • S
      dma: cppi41: wait longer for the HW to return the descriptor · 6f9d7056
      Sebastian Andrzej Siewior 提交于
      For a "complete" teardown we have to wait until the teardown descriptor
      is returned by the hardware. The g_zero testcase "testusb -a -t 9" triggers
      the following warning quite reliable:
      
      |------------[ cut here ]------------
      |WARNING: CPU: 0 PID: 0 at drivers/dma/cppi41.c:609 cppi41_dma_control+0x198/0x304()
      |[<c003f84c>] (warn_slowpath_null) from [<c02be8d8>]
      |[<c02be8d8>] (cppi41_dma_control) from [<bf08d25c>]
      |[<bf08d25c>] (cppi41_dma_channel_abort [musb_hdrc])
      |[<bf08bc38>] (nuke.constprop.10 [musb_hdrc])
      |[<bf08bd08>] (musb_gadget_disable [musb_hdrc])
      |[<bf252524>] (disable_endpoints [usb_f_ss_lb])
      |[<bf2525d8>] (disable_source_sink [usb_f_ss_lb])
      |[<bf25260c>] (sourcesink_set_alt [usb_f_ss_lb])
      |[<bf23ad24>] (composite_setup [libcomposite])
      |[<bf08a2f4>] (musb_g_ep0_irq [musb_hdrc])
      |[<bf085ec4>] (musb_interrupt [musb_hdrc])
      |[<bf0aeaf4>] (dsps_interrupt [musb_dsps])
      |[<c0080ea8>] (handle_irq_event_percpu)
      |[<c008112c>] (handle_irq_event)
      |[<c008348c>] (handle_level_irq)
      |[<c00807a8>] (generic_handle_irq)
      |[<c000ee80>] (handle_IRQ)
      |[<c00085f0>] (omap3_intc_handle_irq)
      
      and complains about a TD descriptor which is not returned. I've been
      looking at several things and haven't noticed anything unusual that
      might lead to this.
      The manual says "to try again" until the descriptor comes out. I limited
      the amount of retries to 100 retries in order to avoid an infinite number
      of retries and so a busy-loop. Back then testing revealed that the
      number of retries were around 20-30 so 100 seemed a good upper limit.
      This g_zero test reaches without a problem 98 retries and it jumps
      sometimes to 101 on am335x-evm and so the WARN_ON() triggers. Same test
      run on beaglebone black and the retries start at 122 and my max value so
      far was at 128.
      So lets rise the limit to 500.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      6f9d7056
    • J
      dmaengine: fsl-edma: fixup reg offset and hw S/G support in big-endian model · 1e2dbdef
      Jingchang Lu 提交于
      The offset of all 8-/16-bit registers in big-endian eDMA model are
      swapped in a 32-bit size opposite those in the little-endian model.
      
      The hardware Scatter/Gather requires the subsequent TCDs stored in memory
      in little endian independent of the register endian model, the eDMA engine
      will do the swap if need.
      
      This patch also use regular assignment for tcd variables r/w
      instead of with io function previously that may not always be true.
      Signed-off-by: NJingchang Lu <jingchang.lu@freescale.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      1e2dbdef
  2. 08 12月, 2014 1 次提交
  3. 06 12月, 2014 3 次提交
  4. 05 12月, 2014 1 次提交
  5. 17 11月, 2014 20 次提交
    • L
      dmaengine: at_xdmac: Add DMA_PRIVATE · fef4cbf2
      Ludovic Desroches 提交于
      same issue as commit 7f5ae355:
      "Without DMA_PRIVATE the driver is not able to allocate more than one channel.
      Since it uses dma_get_any_slave_channel that calls private_candidate, the
      second allocation fails at
      /* some channels are already publicly allocated */
      "
      Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      fef4cbf2
    • L
      dmaengine: at_xdmac: fix missing spin_unlock · 87809839
      Ludovic Desroches 提交于
      Lock taken when entering the function but unlock missing before it
      returns.
      Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      87809839
    • C
      dmaengine: at_xdmac: fix a bug in transfer residue computation · 57819276
      Cyrille Pitchen 提交于
      The total size of the transfer was wrong in at_xdmac_prep_slave_sg()
      resulting in bad computation of the transfer residue by
      at_xdmac_tx_status().
      Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
      Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      57819276
    • C
      dmaengine: at_xdmac: fix software lockup at_xdmac_tx_status() · 4e097820
      Cyrille Pitchen 提交于
      According to the Atmel eXtended DMA controller datasheet, requesting a
      DMA transfer flush for a channel is only revelant when this transfer is
      source peripheral synchronized.
      
      So we have to check this condition before requesting a channel flush by
      writing the channel bit into the Global channel SoftWare Flush (GSWF)
      register then waiting for flush to complete by monitoring the end of
      Flush Interrupt Status (FIS) bit in the Channel Interrupt Status (CIS)
      register.
      
      Indeed, for non source peripheral synchronized transfer, writing the
      channel bit into the GSWF register does nothing. Especially, the FIS bit
      is never set into the CIS register. The former code looped forever
      waiting for this bit to be set.
      Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
      Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      4e097820
    • L
      dmaengine: at_xdmac: remove chancnt affectation · 77e6c9bf
      Ludovic Desroches 提交于
      Remove chancnt affectation since it is done in dma_async_device_regiser.
      Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      77e6c9bf
    • L
      dmaengine: at_xdmac: prefer usage of readl/writel_relaxed · 6e5ae29b
      Ludovic Desroches 提交于
      _relaxed version of readl and writel are not implemented on all
      architecture so COMPILE_TEST has to be removed in order to not cause
      some build failures.
      Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      6e5ae29b
    • V
      dmaengine: xdmac: fix print warning on dma_addr_t variable · 82e24246
      Vinod Koul 提交于
      As documented in printk-formats.txt the dma_addr_t should be printed with
      %pad specfiers. This way it works on all archs.
      
       make.cross ARCH=s390
      
      All warnings:
      
         drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_slave_sg':
      >> drivers/dma/at_xdmac.c:621:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
            dev_dbg(chan2dev(chan),
            ^
      >> drivers/dma/at_xdmac.c:621:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
      >> drivers/dma/at_xdmac.c:628:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
             dev_dbg(chan2dev(chan),
             ^
         drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_cyclic':
      >> drivers/dma/at_xdmac.c:663:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
           dev_dbg(chan2dev(chan), "%s: buf_addr=0x%08x, buf_len=%d, period_len=%d, dir=%s, flags=0x%lx\n",
           ^
      >> drivers/dma/at_xdmac.c:690:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
            dev_dbg(chan2dev(chan),
            ^
      >> drivers/dma/at_xdmac.c:709:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
            dev_dbg(chan2dev(chan),
            ^
      >> drivers/dma/at_xdmac.c:709:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
      >> drivers/dma/at_xdmac.c:716:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
             dev_dbg(chan2dev(chan),
      
      >> drivers/dma/at_xdmac.c:731:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
           dev_dbg(chan2dev(chan),
           ^
         drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_memcpy':
      >> drivers/dma/at_xdmac.c:765:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
           dev_dbg(chan2dev(chan), "%s: src=0x%08x, dest=0x%08x, len=%d, flags=0x%lx\n",
           ^
      >> drivers/dma/at_xdmac.c:765:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
            dev_dbg(chan2dev(chan), "%s: remaining_size=%u\n", __func__, remaining_size);
                                    ^
      >> drivers/dma/at_xdmac.c:845:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
            dev_dbg(chan2dev(chan),
            ^
      >> drivers/dma/at_xdmac.c:845:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
      >> drivers/dma/at_xdmac.c:852:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
             dev_dbg(chan2dev(chan),
             ^
         drivers/dma/at_xdmac.c: In function 'at_xdmac_tx_status':
      >> drivers/dma/at_xdmac.c:929:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
           dev_dbg(chan2dev(chan),
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      82e24246
    • V
      dmaengine: xdmac: fix print warning on size_t variable · c66ec04e
      Vinod Koul 提交于
      As documented in printk-formats.txt the size_t should be printed with
      %zu/%zd specfiers. This way it works on all archs.
      
      make.cross ARCH=avr32
      
      All warnings:
      
         drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_cyclic':
      >> drivers/dma/at_xdmac.c:663: warning: format '%d' expects type 'int', but argument 6 has type 'size_t'
      >> drivers/dma/at_xdmac.c:663: warning: format '%d' expects type 'int', but argument 7 has type 'size_t'
         drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_memcpy':
      >> drivers/dma/at_xdmac.c:765: warning: format '%d' expects type 'int', but argument 7 has type 'size_t'
      >> drivers/dma/at_xdmac.c:794: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'size_t'
      >> drivers/dma/at_xdmac.c:815: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'size_t'
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      c66ec04e
    • V
      dmaengine: at_xdmac: fix usage of read, write wrappers · 2abd4198
      Vinod Koul 提交于
      This driver uses read_relaxed and writel_relaxed to read, write to IO
      memory. the config defines COMPILE_TEST so gets compiled on different archs.
      This causes issue as few archs like x86 etc don't define it.
      So use readl/writel which is defined in all archs
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      2abd4198
    • K
      dmaengine: at_xdmac: fix semicolon.cocci warnings · 5ac7d582
      kbuild test robot 提交于
      drivers/dma/at_xdmac.c:702:3-4: Unneeded semicolon
      
       Removes unneeded semicolon.
      
      Generated by: scripts/coccinelle/misc/semicolon.cocci
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      5ac7d582
    • J
      dmaengine: k3dma: Add CONFIG_PM_SLEEP to suspend/resume functions · af2d3139
      Jingoo Han 提交于
      Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
      build warning when CONFIG_PM_SLEEP is not selected. This is because
      sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
      the CONFIG_PM_SLEEP is enabled.
      
      drivers/dma/k3dma.c:790:12: warning: 'k3_dma_suspend' defined but not used [-Wunused-function]
      drivers/dma/k3dma.c:806:12: warning: 'k3_dma_resume' defined but not used [-Wunused-function]
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Acked-by: NZhangfei Gao <zhangfei.gao@linaro.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      af2d3139
    • J
      dmaengine: sirf: Add CONFIG_PM_SLEEP to suspend/resume functions · 33339684
      Jingoo Han 提交于
      Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
      build warning when CONFIG_PM_SLEEP is not selected. This is because
      sleep PM callbacks defined by SET_SYSTEM_SLEEP_PM_OPS are only used
      when the CONFIG_PM_SLEEP is enabled.
      
      drivers/dma/sirf-dma.c:838:12: warning: 'sirfsoc_dma_pm_suspend' defined but not used [-Wunused-function]
      drivers/dma/sirf-dma.c:879:12: warning: 'sirfsoc_dma_pm_resume' defined but not used [-Wunused-function]
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      33339684
    • N
      dmaengine: imx-sdma: Add a new DMATYPE for SAI · 29aebfde
      Nicolin Chen 提交于
      This patch simply adds a new DMATYPE for SAI which's included
      in i.MX6 Solo X.
      Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      29aebfde
    • Y
      dmaengine: shdma: fix a race condition in __ld_cleanup() · 26fd830a
      Yoshihiro Shimoda 提交于
      This patch fixes a race condition about a list of shdma-base driver.
      If we don't apply this patch, a dma slave driver (especially a usb
      peripheral driver) may not be able to start the transfer.
      
      If a dma slave driver has a callback, __ld_cleanup() will call
      the callback before this driver removes the list. After the callback,
      since the return value of __ld_cleanup() is not zero,
      shdma_chan_ld_cleanup() calls __ld_cleanup() again. And, __ld_clean()
      will removes the list.
      
      At this time, if a dma slave driver calls dmaengine_submit() before
      this driver removes the list, this driver will set schan->pm_state
      to SHDMA_PM_PENDING in shdma_tx_submit(). And then, even if a dma
      slave driver calls dma_async_issue_pending(), this driver don't
      start the transfer because the schan->pm_state is SHDMA_PM_PENDING
      in shdma_issue_pending().
      
      So, this patch adds a new condition in __ld_clean() to check if the
      schan->pm_state is SHDMA_PM_PENDING or not.
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      26fd830a
    • A
      dmaengine: qcom_bam_dma: Add BAM v1.3.0 support · f43669de
      Archit Taneja 提交于
      We currently have register offset information only for BAM IPs with revision
      1.4.0. We add register offset table entries for the legacy (v1.3.0) version
      of BAM IPs found on SoCs like APQ8064 and MSM8960.
      
      The register offset table pointers are stored in DT data corresponding to the
      BAM IP version specified in the compatible string.
      Reviewed-by: NKumar Gala <galak@codeaurora.org>
      Reviewed-by: NAndy Gross <agross@codeaurora.org>
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      f43669de
    • A
      dmaengine: qcom_bam_dma: Generalize BAM register offset calculations · fb93f520
      Archit Taneja 提交于
      The BAM DMA IP comes in different versions. The register offset layout varies
      among these versions. The layouts depend on which generation/family of SoCs they
      belong to.
      
      The current SoCs(like 8084, 8074) have a layout where the Top level registers
      come in the beginning of the address range, followed by pipe and event
      registers. The BAM revision numbers fall above 1.4.0.
      
      The older SoCs (like 8064, 8960) have a layout where the pipe registers come
      first, and the top level come later. These have BAM revision numbers lesser than
      1.4.0.
      
      It isn't suitable to have macros provide the register offsets with the layouts
      changed. Future BAM revisions may have different register layouts too. The
      register addresses are now calculated by referring a table which contains a base
      offset and multipliers for pipe/evnt/ee registers.
      
      We have a common function bam_addr() which computes addresses for all the
      registers. When computing address of top level/ee registers, we pass 0 to the
      pipe argument in addr() since they don't have any multiple instances.
      
      Some of the unused register definitions are removed. We can add new registers as
      we need them.
      Reviewed-by: NKumar Gala <galak@codeaurora.org>
      Reviewed-by: NAndy Gross <agross@codeaurora.org>
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      fb93f520
    • C
      dmaengine: sun6i: Add support for Allwinner A23 (sun8i) variant · 0b04ddf8
      Chen-Yu Tsai 提交于
      The A23 SoC has the same dma engine as the A31 (sun6i), with a
      reduced amount of endpoints and physical channels. Add the proper
      config data and compatible string to support it.
      
      A slight difference in sun8i is an undocumented register needs
      to be toggled for dma to function.
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      0b04ddf8
    • C
      dmaengine: sun6i: support parameterized compatible strings · 25a37c2f
      Chen-Yu Tsai 提交于
      This patch adds support for hardware parameters tied to compatible
      strings, so similar hardware can reuse the driver.
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      25a37c2f
    • J
      dma: imx-sdma: remove incorrect __init annotation from sdma_init() · 19bfc772
      Jingoo Han 提交于
      When platform_driver_probe() is not used, sdma_probe() can be called
      by bind/unbind via sysfs. In addition, sdma_init() can be called by
      sdma_probe(). Thus, __init annotation should be removed from sdma_init(),
      Also, this patch fixes section mismatch warning.
      
      WARNING: drivers/dma/built-in.o(.text+0xd6e4): Section mismatch in reference from the function sdma_probe() to the function
      .init.text:sdma_init()
      The function sdma_probe() references
      the function __init sdma_init().
      This is often because sdma_probe lacks a __init
      annotation or the annotation of sdma_init is wrong.
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      19bfc772
    • A
      dmaengine: pl330: Correct device assignment. · cee42392
      Andrew Jackson 提交于
      Commit f6f2421c removed pl330_info structure by embedding it into
      pl330_dmac structure, but did not ensure that the dmac->ddma.dev
      pointer gets initialised before use. When dma_alloc_coherent() gets
      called on arm64 a WARN() gets triggered due to dev being NULL.
      
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 1 at arch/arm64/mm/dma-mapping.c:49 __dma_alloc_coherent+0xd0/0xe0()
      Use an actual device structure for DMA allocation
      Modules linked in:
      CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0+ #5
      Call trace:
      [<ffffffc000087f24>] dump_backtrace+0x0/0x130
      [<ffffffc000088064>] show_stack+0x10/0x1c
      [<ffffffc0004e8af8>] dump_stack+0x74/0xb8
      [<ffffffc0000aa444>] warn_slowpath_common+0x8c/0xb4
      [<ffffffc0000aa4b8>] warn_slowpath_fmt+0x4c/0x58
      [<ffffffc000092580>] __dma_alloc_coherent+0xcc/0xe0
      [<ffffffc000092734>] __dma_alloc_noncoherent+0x64/0x158
      [<ffffffc000312cd8>] pl330_probe+0x650/0x8f0
      [<ffffffc00030e1d4>] amba_probe+0xa0/0xc8
      [<ffffffc000350240>] really_probe+0xc4/0x22c
      [<ffffffc0003504b4>] __driver_attach+0xa0/0xa8
      [<ffffffc00034e5fc>] bus_for_each_dev+0x54/0x98
      [<ffffffc00034fd8c>] driver_attach+0x1c/0x28
      [<ffffffc00034fa08>] bus_add_driver+0x14c/0x204
      [<ffffffc000350b84>] driver_register+0x64/0x130
      [<ffffffc00030dcf8>] amba_driver_register+0x50/0x5c
      [<ffffffc0006a60d0>] pl330_driver_init+0x10/0x1c
      [<ffffffc0000814ac>] do_one_initcall+0x88/0x19c
      [<ffffffc00068dab8>] kernel_init_freeable+0x140/0x1e0
      [<ffffffc0004e5e18>] kernel_init+0x10/0xd4
      ---[ end trace 76f2d47a444e523e ]---
      (NULL device *): dmac_alloc_resources:1821 Can't allocate memory!
      (NULL device *): Unable to create channels for DMAC
      
      This patch will also ensure that any dev_err messages are printed
      with the appropriate device name.
      Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: NAndrew Jackson <Andrew.Jackson@arm.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      cee42392
  6. 06 11月, 2014 12 次提交