Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ https://git.shady.money/linux/atom?h=v3.18 2014-11-22T00:24:27Z 2014-11-22T00:24:27Z Linus Torvalds torvalds@linux-foundation.org 2014-11-22T00:24:27Z urn:sha1:4ec69c7ebc2cb8df1f33b26f4492481c452fef66 Pull dmaengine fixes from Vinod Koul: "We have couple of fixes for dmaengine queued up: - dma mempcy fix for dma configuration of sun6i by Maxime - pl330 fixes: First the fixing allocation for data buffers by Liviu and then Jon's fixe for fifo width and usage" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: Fix allocation size for PL330 data buffer depth. dmaengine: pl330: Limit MFIFO usage for memcpy to avoid exhausting entries dmaengine: pl330: Align DMA memcpy operations to MFIFO width dmaengine: sun6i: Fix memcpy operation 2014-11-17T07:31:22Z Liviu Dudau Liviu.Dudau@arm.com 2014-11-06T17:20:12Z urn:sha1:1f0a5cbf61a54504236bbbe2c98b58e85f90e650 The datasheet for PL330 says that the data buffer value in the CRD register is 10bits wide. However, the value stored is "minus one", which the driver corrects for. Maximum value that the data buffer depth can have is 1024 lines, which requires 11 bits for storage. While making updates I found printing the peripheral ID as a hex value to be more useful as the datasheet shows the values that way. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 2014-11-17T07:31:20Z Jon Medhurst tixy@linaro.org 2014-11-07T18:05:18Z urn:sha1:c27f95568d1ed2573fc9c8848d741da63ca9a34e The MFIFO is shared by all channels so restrict each memcpy to it's fair share. This is being over cautious, but without a global view of DMA channel usage on a system it's not possible to come up with a more optimum safe limit. Signed-off-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 2014-11-17T07:31:09Z Jon Medhurst tixy@linaro.org 2014-11-07T18:05:17Z urn:sha1:137bd11090d89b3a3ef4bdb7a6cf964ffc797517 The algorithm used for programming the DMA Controller doesn't take into consideration the requirements of transfers that are not aligned to the bus width. This failure may result in DMA transferring one too few MFIFO entries (so too few bytes are copied) or the DMA trying to write one too many MFIFO entries and hanging because this is never provided. See "MFIFO Usage Overview" chapter in the the TRM for "CoreLink DMA Controller DMA-330", Revision r1p1. We work around these shortcomings by making sure we pick a burst size and length which ensures no bursts straddle an MFIFO entry. Signed-off-by: Jon Medhurst <tixy@linaro.org> [squashed linker error "undefined reference to `__aeabi_uldivmod] Reported-by: kbuild test robot <fengguang.wu@intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 2014-11-12T09:24:09Z Maxime Ripard maxime.ripard@free-electrons.com 2014-11-11T18:35:52Z urn:sha1:1f9cd915b64bb95f7b41667b4bf8b22f0a0a557b The prep_memcpy call was not setting any meaningful burst and width because it was relying on the dma_slave_config was not set already. Rework the needed conversion functions, and hardcode the width and burst to use. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com> 2014-11-06T02:26:10Z Arnd Bergmann arnd@arndb.de 2014-10-24T16:14:01Z urn:sha1:5305e4d674ed5ec9bebd11d948affd411594d4cf The horrible split between the low-level part of the edma support and the dmaengine front-end driver causes problems on multiplatform kernels. This is an attempt to improve the situation slightly by only registering the dmaengine devices that are actually present. Signed-off-by: Arnd Bergmann <arnd@arndb.de> [olof: add missing include of linux/dma-mapping.h] Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Olof Johansson <olof@lixom.net> 2014-10-19T01:11:04Z Linus Torvalds torvalds@linux-foundation.org 2014-10-19T01:11:04Z urn:sha1:52d589a01d4545ce1dc5c3892bb8c7b55edfe714 Pull slave-dmaengine updates from Vinod Koul: "For dmaengine contributions we have: - designware cleanup by Andy - my series moving device_control users to dmanegine_xxx APIs for later removal of device_control API - minor fixes spread over drivers mainly mv_xor, pl330, mmp, imx-sdma etc" * 'for-linus' of git://git.infradead.org/users/vkoul/slave-dma: (60 commits) serial: atmel: add missing dmaengine header dmaengine: remove FSLDMA_EXTERNAL_START dmaengine: freescale: remove FSLDMA_EXTERNAL_START control method carma-fpga: move to fsl_dma_external_start() carma-fpga: use dmaengine_xxx() API dmaengine: freescale: add and export fsl_dma_external_start() dmaengine: add dmaengine_prep_dma_sg() helper video: mx3fb: use dmaengine_terminate_all() API serial: sh-sci: use dmaengine_terminate_all() API net: ks8842: use dmaengine_terminate_all() API mtd: sh_flctl: use dmaengine_terminate_all() API mtd: fsmc_nand: use dmaengine_terminate_all() API V4L2: mx3_camer: use dmaengine_pause() API dmaengine: coh901318: use dmaengine_terminate_all() API pata_arasan_cf: use dmaengine_terminate_all() API dmaengine: edma: check for echan->edesc => NULL in edma_dma_pause() dmaengine: dw: export probe()/remove() and Co to users dmaengine: dw: enable and disable controller when needed dmaengine: dw: always export dw_dma_{en,dis}able dmaengine: dw: introduce dw_dma_on() helper ... 2014-10-15T16:09:09Z Vinod Koul vinod.koul@intel.com 2014-10-15T16:09:09Z urn:sha1:cf6c0ab54daeb614ae79bdd0168e8b7ec2650134 2014-10-15T16:08:49Z Vinod Koul vinod.koul@intel.com 2014-10-15T16:08:49Z urn:sha1:2856fcdc1f7b6dc237afc2dbec6fbd21fe88dd4e 2014-10-15T16:01:28Z Vinod Koul vinod.koul@intel.com 2014-10-11T15:46:47Z urn:sha1:01c6ad660cb4a388d15d0e7ba9744c5ffc583a61 since users have been move to fsl_dma_external_start() API, so remove this now Signed-off-by: Vinod Koul <vinod.koul@intel.com>