1. 23 7月, 2008 3 次提交
  2. 18 7月, 2008 2 次提交
  3. 09 7月, 2008 11 次提交
    • H
      dmaengine: Driver for the Synopsys DesignWare DMA controller · 3bfb1d20
      Haavard Skinnemoen 提交于
      This adds a driver for the Synopsys DesignWare DMA controller (aka
      DMACA on AVR32 systems.) This DMA controller can be found integrated
      on the AT32AP7000 chip and is primarily meant for peripheral DMA
      transfer, but can also be used for memory-to-memory transfers.
      
      This patch is based on a driver from David Brownell which was based on
      an older version of the DMA Engine framework. It also implements the
      proposed extensions to the DMA Engine API for slave DMA operations.
      
      The dmatest client shows no problems, but there may still be room for
      improvement performance-wise. DMA slave transfer performance is
      definitely "good enough"; reading 100 MiB from an SD card running at ~20
      MHz yields ~7.2 MiB/s average transfer rate.
      
      Full documentation for this controller can be found in the Synopsys
      DW AHB DMAC Databook:
      
      http://www.synopsys.com/designware/docs/iip/DW_ahb_dmac/latest/doc/dw_ahb_dmac_db.pdf
      
      The controller has lots of implementation options, so it's usually a
      good idea to check the data sheet of the chip it's intergrated on as
      well. The AT32AP7000 data sheet can be found here:
      
      http://www.atmel.com/dyn/products/datasheets.asp?family_id=682
      
      
      Changes since v4:
        * Use client_count instead of dma_chan_is_in_use()
        * Add missing include
        * Unmap buffers unless client told us not to
      
      Changes since v3:
        * Update to latest DMA engine and DMA slave APIs
        * Embed the hw descriptor into the sw descriptor
        * Clean up and update MODULE_DESCRIPTION, copyright date, etc.
      
      Changes since v2:
        * Dequeue all pending transfers in terminate_all()
        * Rename dw_dmac.h -> dw_dmac_regs.h
        * Define and use controller-specific dma_slave data
        * Fix up a few outdated comments
        * Define hardware registers as structs (doesn't generate better
          code, unfortunately, but it looks nicer.)
        * Get number of channels from platform_data instead of hardcoding it
          based on CONFIG_WHATEVER_CPU.
        * Give slave clients exclusive access to the channel
      
      Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com>,
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3bfb1d20
    • H
      dmaengine: Add slave DMA interface · dc0ee643
      Haavard Skinnemoen 提交于
      This patch adds the necessary interfaces to the DMA Engine framework
      to use functionality found on most embedded DMA controllers: DMA from
      and to I/O registers with hardware handshaking.
      
      In this context, hardware hanshaking means that the peripheral that
      owns the I/O registers in question is able to tell the DMA controller
      when more data is available for reading, or when there is room for
      more data to be written. This usually happens internally on the chip,
      but these signals may also be exported outside the chip for things
      like IDE DMA, etc.
      
      A new struct dma_slave is introduced. This contains information that
      the DMA engine driver needs to set up slave transfers to and from a
      slave device. Most engines supporting DMA slave transfers will want to
      extend this structure with controller-specific parameters.  This
      additional information is usually passed from the platform/board code
      through the client driver.
      
      A "slave" pointer is added to the dma_client struct. This must point
      to a valid dma_slave structure iff the DMA_SLAVE capability is
      requested.  The DMA engine driver may use this information in its
      device_alloc_chan_resources hook to configure the DMA controller for
      slave transfers from and to the given slave device.
      
      A new operation for preparing slave DMA transfers is added to struct
      dma_device. This takes a scatterlist and returns a single descriptor
      representing the whole transfer.
      
      Another new operation for terminating all pending transfers is added as
      well. The latter is needed because there may be errors outside the scope
      of the DMA Engine framework that may require DMA operations to be
      terminated prematurely.
      
      DMA Engine drivers may extend the dma_device, dma_chan and/or
      dma_slave_descriptor structures to allow controller-specific
      operations. The client driver can detect such extensions by looking at
      the DMA Engine's struct device, or it can request a specific DMA
      Engine device by setting the dma_dev field in struct dma_slave.
      
      dmaslave interface changes since v4:
        * Fix checkpatch errors
        * Fix changelog (there are no slave descriptors anymore)
      
      dmaslave interface changes since v3:
        * Use dma_data_direction instead of a new enum
        * Submit slave transfers as scatterlists
        * Remove the DMA slave descriptor struct
      
      dmaslave interface changes since v2:
        * Add a dma_dev field to struct dma_slave. If set, the client can
          only be bound to the DMA controller that corresponds to this
          device.  This allows controller-specific extensions of the
          dma_slave structure; if the device matches, the controller may
          safely assume its extensions are present.
        * Move reg_width into struct dma_slave as there are currently no
          users that need to be able to set the width on a per-transfer
          basis.
      
      dmaslave interface changes since v1:
        * Drop the set_direction and set_width descriptor hooks. Pass the
          direction and width to the prep function instead.
        * Declare a dma_slave struct with fixed information about a slave,
          i.e. register addresses, handshake interfaces and such.
        * Add pointer to a dma_slave struct to dma_client. Can be NULL if
          the DMA_SLAVE capability isn't requested.
        * Drop the set_slave device hook since the alloc_chan_resources hook
          now has enough information to set up the channel for slave
          transfers.
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      dc0ee643
    • D
      dmaengine: add DMA_COMPL_SKIP_{SRC,DEST}_UNMAP flags to control dma unmap · e1d181ef
      Dan Williams 提交于
      In some cases client code may need the dma-driver to skip the unmap of source
      and/or destination buffers.  Setting these flags indicates to the driver to
      skip the unmap step.  In this regard async_xor is currently broken in that it
      allows the destination buffer to be unmapped while an operation is still in
      progress, i.e. when the number of sources exceeds the hardware channel's
      maximum (fixed in a subsequent patch).
      Acked-by: NSaeed Bishara <saeed@marvell.com>
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Acked-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      e1d181ef
    • H
      dmaengine: Add dma_client parameter to device_alloc_chan_resources · 848c536a
      Haavard Skinnemoen 提交于
      A DMA controller capable of doing slave transfers may need to know a
      few things about the slave when preparing the channel. We don't want
      to add this information to struct dma_channel since the channel hasn't
      yet been bound to a client at this point.
      
      Instead, pass a reference to the client requesting the channel to the
      driver's device_alloc_chan_resources hook so that it can pick the
      necessary information from the dma_client struct by itself.
      
      [dan.j.williams@intel.com: fixed up fsldma and mv_xor]
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      848c536a
    • H
      dmatest: Simple DMA memcpy test client · 4a776f0a
      Haavard Skinnemoen 提交于
      This client tests DMA memcpy using various lengths and various offsets
      into the source and destination buffers. It will initialize both
      buffers with a repeatable pattern and verify that the DMA engine copies
      the requested region and nothing more. It will also verify that the
      bytes aren't swapped around, and that the source buffer isn't modified.
      
      The dmatest module can be configured to test a specific device, a
      specific channel. It can also test multiple channels at the same time,
      and it can start multiple threads competing for the same channel.
      
      Changes since v2:
        * Support testing multiple channels at the same time
        * Support testing with multiple threads competing for the same channel
        * Use counting test patterns in order to catch byte ordering issues
      
      Changes since v1:
        * Remove extra dashes around "help"
        * Remove "default n" from Kconfig
        * Turn TEST_BUF_SIZE into a module parameter
        * Return DMA_NAK instead of DMA_DUP
        * Print unhandled events
        * Support testing specific channels and devices
        * Move to the end of the Makefile
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      4a776f0a
    • S
      dmaengine: DMA engine driver for Marvell XOR engine · ff7b0479
      Saeed Bishara 提交于
      The XOR engine found in Marvell's SoCs and system controllers
      provides XOR and DMA operation, iSCSI CRC32C calculation, memory
      initialization, and memory ECC error cleanup operation support.
      
      This driver implements the DMA engine API and supports the following
      capabilities:
      - memcpy
      - xor
      - memset
      
      The XOR engine can be used by DMA engine clients implemented in the
      kernel, one of those clients is the RAID module.  In that case, I
      observed 20% improvement in the raid5 write throughput, and 40%
      decrease in the CPU utilization when doing array construction, those
      results obtained on an 5182 running at 500Mhz.
      
      When enabling the NET DMA client, the performance decreased, so
      meanwhile it is recommended to keep this client off.
      Signed-off-by: NSaeed Bishara <saeed@marvell.com>
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      ff7b0479
    • K
      iop-adma: fix platform driver hotplug/coldplug · ebabe276
      Kay Sievers 提交于
      Since 43cc71ee, the platform
      modalias is prefixed with "platform:". Add MODULE_ALIAS() to most
      of the hotpluggable platform drivers, to re-enable auto loading.
      
      Cc: <stable@kernel.org>
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      ebabe276
    • D
      dmaengine: track the number of clients using a channel · 7cc5bf9a
      Dan Williams 提交于
      Haavard's dma-slave interface would like to test for exclusive access to a
      channel.  The standard channel refcounting is not sufficient in that it
      tracks more than just client references, it is also inaccurate as reference
      counts are percpu until the channel is removed.
      
      This change also enables a future fix to deallocate resources when a client
      declines to use a capable channel.
      Acked-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      7cc5bf9a
    • D
      dmaengine: remove arch dependency from DMADEVICES · 9c402f4e
      Dan Williams 提交于
      The dependency is redundant since all drivers set their specific arch
      dependencies.  The NET_DMA option is modified to be enabled only on platforms
      where it is known to have a positive effect.  HAS_DMA is added as an explicit
      dependency for the DMADEVICES menu.
      Acked-by: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      9c402f4e
    • H
      dmaengine: Couple DMA channels to their physical DMA device · 1099dc79
      Haavard Skinnemoen 提交于
      Set the 'parent' field of channel class devices to point to the
      physical DMA device initialized by the DMA engine driver.
      
      This allows drivers to use chan->dev.parent for syncing DMA buffers
      and adds a 'device' symlink to the real device in
      /sys/class/dma/dmaXchanY.
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      1099dc79
    • L
      51ee87f2
  4. 21 5月, 2008 1 次提交
  5. 22 4月, 2008 1 次提交
  6. 18 4月, 2008 6 次提交
  7. 01 4月, 2008 1 次提交
  8. 31 3月, 2008 2 次提交
  9. 19 3月, 2008 1 次提交
  10. 14 3月, 2008 5 次提交
  11. 05 3月, 2008 3 次提交
  12. 07 2月, 2008 3 次提交
  13. 25 1月, 2008 1 次提交