linux.git/drivers/dma/dw/platform.c, branch v4.9

dmaengine: dw: pass platform data via struct dw_dma_chip

2016-05-02T10:01:05+00:00

We pass struct dw_dma_chip to dw_dma_probe() anyway, thus we may use it to
pass a platform data as well.

While here, constify the source of the platform data.

Acked-by: Viresh Kumar 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: dw: keep entire platform data in struct dw_dma

2016-05-02T10:01:05+00:00

Keep the entire platform data in the struct dw_dma.
It makes the driver a bit cleaner.

Acked-by: Viresh Kumar 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: dw: revisit data_width property

2016-05-02T10:00:47+00:00

There several changes are done here:

- Convert the property to be in bytes

  Besides that this is a common practice for such property, the use of a value
  in bytes much more convenient than handling the encoded one.

- Rename data_width to data-width in the device tree bindings

  The change leaves the support for the old format as well just in case someone
  will use a newer kernel with an old device tree blob.

- While here, replace dwc_fast_ffs() by __ffs()

Signed-off-by: Andy Shevchenko 
Acked-by: Viresh Kumar 
Signed-off-by: Vinod Koul

dmaengine: dw: platform: check nr_masters to be non-zero

2016-05-02T10:00:25+00:00

The value of nr_masters equal to 0 is invalid since this DMA controller has to
have at least one master.

Check this before we proceed with the rest of properties.

Acked-by: Viresh Kumar 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: dw: rename masters to reflect actual topology

2016-04-13T16:06:09+00:00

The source and destination masters are reflecting buses or their layers to
where the different devices can be connected. The patch changes the master
names to reflect which one is related to which independently on the transfer
direction.

The outcome of the change is that the memory data width is now always limited
by a data width of the master which is dedicated to communicate to memory.

The patch will not break anything since all current users have the same data
width for all masters. Though it would be nice to revisit avr32 platforms to
check what is the actual hardware topology in use there. It seems that it has
one bus and two masters on it as stated by Table 8-2, that's why everything
works independently on the master in use. The purpose of the sequential patch
is to fix the driver for configuration of more than one bus.

The change is done in the assumption that src_master and dst_master are
reflecting a connection to the memory and peripheral correspondently on avr32
and otherwise on the rest.

Acked-by: Hans-Christian Egtvedt 
Acked-by: Mark Brown 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

Merge tag 'dmaengine-4.5-rc1' of git://git.infradead.org/users/vkoul/slave-dma

2016-01-13T18:59:52+00:00

Pull dmaengine updates from Vinod Koul:
 "This round we have few new features, new driver and updates to few
  drivers.

  The new features to dmaengine core are:
   - Synchronized transfer termination API to terminate the dmaengine
     transfers in synchronized and async fashion as required by users.
     We have its user now in ALSA dmaengine lib, img, at_xdma, axi_dmac
     drivers.
   - Universal API for channel request and start consolidation of
     request flows.  It's user is ompa-dma driver.
   - Introduce reuse of descriptors and use in pxa_dma driver

  Add/Remove:
   - New STM32 DMA driver
   - Removal of unused R-Car HPB-DMAC driver

  Updates:
   - ti-dma-crossbar updates for supporting eDMA
   - tegra-apb pm updates
   - idma64
   - mv_xor updates
   - ste_dma updates"

* tag 'dmaengine-4.5-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (54 commits)
  dmaengine: mv_xor: add suspend/resume support
  dmaengine: mv_xor: de-duplicate mv_chan_set_mode*()
  dmaengine: mv_xor: remove mv_xor_chan->current_type field
  dmaengine: omap-dma: Add support for DMA filter mapping to slave devices
  dmaengine: edma: Add support for DMA filter mapping to slave devices
  dmaengine: core: Introduce new, universal API to request a channel
  dmaengine: core: Move and merge the code paths using private_candidate
  dmaengine: core: Skip mask matching when it is not provided to private_candidate
  dmaengine: mdc: Correct terminate_all handling
  dmaengine: edma: Add probe callback to edma_tptc_driver
  dmaengine: dw: fix potential memory leak in dw_dma_parse_dt()
  dmaengine: stm32-dma: Fix unchecked deference of chan->desc
  dmaengine: sh: Remove unused R-Car HPB-DMAC driver
  dmaengine: usb-dmac: Document SoC specific compatibility strings
  ste_dma40: Delete an unnecessary variable initialisation in d40_probe()
  ste_dma40: Delete another unnecessary check in d40_probe()
  ste_dma40: Delete an unnecessary check before the function call "kmem_cache_destroy"
  dmaengine: tegra-apb: Free interrupts before killing tasklets
  dmaengine: tegra-apb: Update driver to use GFP_NOWAIT
  dmaengine: tegra-apb: Only save channel state for those in use
  ...

Revert "dmaengine: dw: platform: provide platform data for Intel"

2016-01-07T13:11:54+00:00

Since we have a work around to prevent a system hangup we don't need to provide
a platform data explicitly anymore.

This reverts commit 175267b389f781748e2bbb6c737e76b5c9bc4c88.

Signed-off-by: Andy Shevchenko 
Acked-by: Vinod Koul 
Signed-off-by: Rafael J. Wysocki

dmaengine: dw: platform: power on device on shutdown

2016-01-07T13:11:53+00:00

We have to call dw_dma_disable() to stop any ongoing transfer. On some
platforms we can't do that since DMA device is powered off. Moreover we have no
possibility at that point to check if the platform is affected or not. That's
why we call pm_runtime_get_sync() / pm_runtime_put() unconditionally. On the
other hand we can't use pm_runtime_suspended() because runtime PM framework is
not fully used by the driver.

Signed-off-by: Andy Shevchenko 
Acked-by: Vinod Koul 
Signed-off-by: Rafael J. Wysocki

dmaengine: dw: fix potential memory leak in dw_dma_parse_dt()

2015-12-18T05:29:32+00:00

If the "dma-channels" DT property is missing, the dw_dma_parse_dt()
function return NULL, but not before allocating memory for a struct
dw_dma_platform_data through devres.  If the device supports parameter
detection, the probe still succeeds and the allocated memory is not
released until the device is removed.

Fix this by deferring the allocation until after checking the
"dma-channels" property.

Signed-off-by: Mans Rullgard 
Acked-by: Viresh Kumar 
Signed-off-by: Vinod Koul

dmaengine: dw: platform: provide platform data for Intel

2015-10-31T02:02:36+00:00

Provide platform data explicitly for Intel SoCs where dw_dmac is enumerated by
ACPI.

Signed-off-by: Andy Shevchenko 
Acked-by: Viresh Kumar 
Signed-off-by: Vinod Koul