kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/dma/edma.c

2560 lines
66 KiB
Raw Permalink Normal View History

dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaenegine: edma: fix sparse warnings this patch fixes following sparse warnings: edma.c:537:32: warning: symbol 'edma_prep_dma_memcpy' was not declared. Should it be static? edma.c:1070:6: warning: symbol 'edma_filter_fn' was not declared. Should it be static? Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-02-04 13:03:27 +00:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Do not register second device when booted with DT DT boot does not yet support more than one edma device. To avoid issues at runtime we should not register the second device when the kernel is booted with DT. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-07-31 13:12:38 +03:00
ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine driver If the of_dma_controller is registered in the non dmaengine driver we could have race condition: the of_dma_controller has been registered, but the dmaengine driver is not yet probed. Drivers requesting DMA channels during this window will fail since we do not yet have dmaengine drivers registered. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:47 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM: davinci: move private EDMA API to arm/common Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. Signed-off-by: Matt Porter <mporter@ti.com> Acked-by: Chris Ball <cjb@laptop.org> # davinci_mmc.c Acked-by: Mark Brown <broonie@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> [nsekhar@ti.com: dropped davinci sffsdr changes] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-06 11:15:31 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: predecence bug in GET_NUM_QDMACH() The current code uses bits 0-2 instead of 4-6 as the comment says. Fixes: 633e42b8c546 ('dmaengine: edma: Get qDMA channel information from HW also') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-11-04 16:38:31 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: fix residue race for cyclic When retrieving the residue value, the SRC/DST fields of the active PaRAM are read to determine the current position of the DMA engine. However, the AM335x Technical Reference Manual states: 11.3.3.6 Parameter Set Updates After the TR is read from the PaRAM (and is in the process of being submitted to the EDMA3TC), the following fields are updated as needed: ... SRC DST This means SRC/DST is incremented even though the DMA transfer may not have started yet or is in progress. Thus if the reader of the residue accesses the DMA buffer too quickly, the CPU is misinformed about the data that has been successfully processed. The CCSTAT.ACTV register is a boolean that is set if any TR is being processed by either the EMDA3CC or EDMA3TC. By polling this register it is possible to ensure that the residue value returned is valid for immediate processing. However, since the DMA engine may be active, polling may never hit a moment where no TR is being processed. To handle this, the SRC/DST is also polled to see if it changes. And as a last resort, a max loop count for the busy waiting exists to avoid an infinite loop. Signed-off-by: John Ogness <john.ogness@linutronix.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-01-28 11:29:08 +01:00
dma: edma: Increase maximum SG limit to 20 davinci-pcm uses 16 as the no.of periods. With this, in EDMA we have to allocate atleast 17 slots: 1 slot for channel, and 16 slots the periods. Due to this, the MAX_NR_SG limitation causes problems, set it to 20 to make cyclic DMA work when davinci-pcm is converted to use DMA Engine. Also add a comment clarifying this. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:15 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dmaengine: edma: Store transfer data in edma_desc and edma_pset For granular accounting we need to store the direction and the information for the individual psets: - source or destination address, depending on direction - length Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:29:57 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Store transfer data in edma_desc and edma_pset For granular accounting we need to store the direction and the information for the individual psets: - source or destination address, depending on direction - length Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:29:57 -05:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: edma: Document variables used for residue accounting The granular residue accounting code uses certain variables specifically for residue accounting. Document these in the structure declaration. Also move around some elements and group them together. Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 15:19:31 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Find missed events and issue them In an effort to move to using Scatter gather lists of any size with EDMA as discussed at [1] instead of placing limitations on the driver, we work through the limitations of the EDMAC hardware to find missed events and issue them. The sequence of events that require this are: For the scenario where MAX slots for an EDMA channel is 3: SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> Null The above SG list will have to be DMA'd in 2 sets: (1) SG1 -> SG2 -> SG3 -> Null (2) SG4 -> SG5 -> SG6 -> Null After (1) is succesfully transferred, the events from the MMC controller donot stop coming and are missed by the time we have setup the transfer for (2). So here, we catch the events missed as an error condition and issue them manually. In the second part of the patch, we make handle the NULL slot cases: For crypto IP, we continue to receive events even continuously in NULL slot, the setup of the next set of SG elements happens after the error handler executes. This is results in some recursion problems. Due to this, we continously receive error interrupts when we manually trigger an event from the error handler. We fix this, by first detecting if the Channel is currently transferring from a NULL slot or not, that's where the edma_read_slot in the error callback from interrupt handler comes in. With this we can determine if the set up of the next SG list has completed, and we manually trigger only in this case. If the setup has _not_ completed, we are still in NULL so we just set a missed flag and allow the manual triggerring to happen in edma_execute which will be eventually called. This fixes the above mentioned race conditions seen with the crypto drivers. [1] http://marc.info/?l=linux-omap&m=137416733628831&w=2 Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-08-29 18:05:43 -05:00
dma: edma: fix slave config dependency on direction The edma_slave_config() implementation depends on the direction field such that it will not properly configure a slave channel when called without direction set. This fixes the implementation so that the slave config is copied as is and prep_slave_sg() handles the direction dependent handling. spi-omap2-mcspi and omap_hsmmc both expose this bug as they configure the slave channel config from a common path with an unconfigured direction field. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-01-10 13:41:04 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Get qDMA channel information from HW also Query the number of qDMA channels from CCCFG register. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:04 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Read channel mapping support only once from HW Instead of directly reading it from CCCFG register take the information out once when we set up the configuration from the HW. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:04 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: explicitly freeup irq dmaengine device should explicitly call devm_free_irq() when using devm_request_irq(). The irq is still ON when devices remove is executed and irq should be quiesced before remove is completed. Signed-off-by: Vinod Koul <vinod.koul@intel.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
2016-07-01 11:34:35 +05:30
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Rename bitfields for slot and channel usage tracking The names chosen for the bitfields were quite confusing and given no real information on what they are used for... edma_inuse -> slot_inuse: tracks the slot usage/availability edma_unused -> channel_unused: tracks the channel usage/availability Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:05 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Allocate memory dynamically for bitmaps and structures Instead of using defines to specify the size of different arrays and bitmaps, allocate the memory for them based on the information we get from the HW itself. Since these defines are set based on the worst case, there are devices where they are not valid. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:54 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Fix of_device_id data parameter usage (legacy vs TPCC) Use pointers to static constant variables for eDMA binding type (legacy vs TPCC). Fixes the following warning when compiling the driver for 64bit architectures (x86_64 for example): drivers/dma/edma.c:2185:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] if (match && (u32)match->data == EDMA_BINDING_TPCC) ^ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-21 15:41:28 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Fix of_device_id data parameter usage (legacy vs TPCC) Use pointers to static constant variables for eDMA binding type (legacy vs TPCC). Fixes the following warning when compiling the driver for 64bit architectures (x86_64 for example): drivers/dma/edma.c:2185:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] if (match && (u32)match->data == EDMA_BINDING_TPCC) ^ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-21 15:41:28 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Fix of_device_id data parameter usage (legacy vs TPCC) Use pointers to static constant variables for eDMA binding type (legacy vs TPCC). Fixes the following warning when compiling the driver for 64bit architectures (x86_64 for example): drivers/dma/edma.c:2185:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] if (match && (u32)match->data == EDMA_BINDING_TPCC) ^ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-21 15:41:28 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id structs The MODULE_DEVICE_TABLE() were missing from the driver for the of_device_id structures. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-21 15:41:27 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Add dummy driver skeleton for edma3-tptc The eDMA3 TPTC does not need any software configuration, but it is a separate IP block in the SoC. In order the omap hwmod core to be able to handle the TPTC resources correctly in regards of PM we need to have a driver loaded for it. This patch will add a dummy driver skeleton without probe or remove callbacks provided. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-11-02 15:21:40 +02:00
dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id structs The MODULE_DEVICE_TABLE() were missing from the driver for the of_device_id structures. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-21 15:41:27 +03:00
dmaengine: edma: Add dummy driver skeleton for edma3-tptc The eDMA3 TPTC does not need any software configuration, but it is a separate IP block in the SoC. In order the omap hwmod core to be able to handle the TPTC resources correctly in regards of PM we need to have a driver loaded for it. This patch will add a dummy driver skeleton without probe or remove callbacks provided. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-11-02 15:21:40 +02:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_) These inline functions are designed to modify parts of the PaRAM in eDMA. Change the names accordingly. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:02 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_) These inline functions are designed to modify parts of the PaRAM in eDMA. Change the names accordingly. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:02 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_) These inline functions are designed to modify parts of the PaRAM in eDMA. Change the names accordingly. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:02 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_) These inline functions are designed to modify parts of the PaRAM in eDMA. Change the names accordingly. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:02 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_) These inline functions are designed to modify parts of the PaRAM in eDMA. Change the names accordingly. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:02 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Rename set_bits and remove unused clear_bits helper The clear_bits() helper is not used by the driver so it can be removed. powerpc architecture defines the set_bits() in arch/powerpc/include/asm/bitops.h which results failed compile testing on powerpc architecture: >> drivers/dma/edma.c:415:20: error: conflicting types for 'set_bits' static inline void set_bits(int offset, int len, unsigned long *p) ^~~~~~~~ In file included from include/linux/bitops.h:36:0, from include/linux/kernel.h:10, from include/linux/list.h:8, from include/linux/kobject.h:20, from include/linux/device.h:17, from include/linux/dmaengine.h:20, from drivers/dma/edma.c:16: arch/powerpc/include/asm/bitops.h:75:14: note: previous definition of 'set_bits' was here DEFINE_BITOP(set_bits, or, "") ^ arch/powerpc/include/asm/bitops.h:58:24: note: in definition of macro 'DEFINE_BITOP' static __inline__ void fn(unsigned long mask, \ ^~ >> drivers/dma/edma.c:421:20: error: conflicting types for 'clear_bits' static inline void clear_bits(int offset, int len, unsigned long *p) ^~~~~~~~~~ In file included from include/linux/bitops.h:36:0, from include/linux/kernel.h:10, from include/linux/list.h:8, from include/linux/kobject.h:20, from include/linux/device.h:17, from include/linux/dmaengine.h:20, from drivers/dma/edma.c:16: arch/powerpc/include/asm/bitops.h:76:14: note: previous definition of 'clear_bits' was here DEFINE_BITOP(clear_bits, andc, "") ^ arch/powerpc/include/asm/bitops.h:58:24: note: in definition of macro 'DEFINE_BITOP' static __inline__ void fn(unsigned long mask, \ ^~ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-22 09:31:04 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Consolidate the comments for functions Remove or rewrite the comments for the internal functions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:00 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: avoid uninitialized variable use If edma_read_slot() gets an invalid argument, it does not set a result, as found by "gcc -Wmaybe-uninitialized" drivers/dma/edma.c: In function 'dma_ccerr_handler': drivers/dma/edma.c:1499:21: error: 'p.a_b_cnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/dma/edma.c:1499:21: error: 'p.ccnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (p.a_b_cnt == 0 && p.ccnt == 0) { If we change the function to return an error in this case, we can handle the failure more gracefully and treat this the same way as a null slot that we already catch. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-30 18:19:01 +02:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: avoid uninitialized variable use If edma_read_slot() gets an invalid argument, it does not set a result, as found by "gcc -Wmaybe-uninitialized" drivers/dma/edma.c: In function 'dma_ccerr_handler': drivers/dma/edma.c:1499:21: error: 'p.a_b_cnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/dma/edma.c:1499:21: error: 'p.ccnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (p.a_b_cnt == 0 && p.ccnt == 0) { If we change the function to return an error in this case, we can handle the failure more gracefully and treat this the same way as a null slot that we already catch. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-30 18:19:01 +02:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: avoid uninitialized variable use If edma_read_slot() gets an invalid argument, it does not set a result, as found by "gcc -Wmaybe-uninitialized" drivers/dma/edma.c: In function 'dma_ccerr_handler': drivers/dma/edma.c:1499:21: error: 'p.a_b_cnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/dma/edma.c:1499:21: error: 'p.ccnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (p.a_b_cnt == 0 && p.ccnt == 0) { If we change the function to return an error in this case, we can handle the failure more gracefully and treat this the same way as a null slot that we already catch. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-30 18:19:01 +02:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Fix paRAM slot allocation for entry channel 0 edma_alloc_slot was not checking the channel mapping support existence when slot 0 has been requested (used as entry slot for channel/event 0). Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-01-11 10:38:01 +02:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Rename bitfields for slot and channel usage tracking The names chosen for the bitfields were quite confusing and given no real information on what they are used for... edma_inuse -> slot_inuse: tracks the slot usage/availability edma_unused -> channel_unused: tracks the channel usage/availability Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:05 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Rename bitfields for slot and channel usage tracking The names chosen for the bitfields were quite confusing and given no real information on what they are used for... edma_inuse -> slot_inuse: tracks the slot usage/availability edma_unused -> channel_unused: tracks the channel usage/availability Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:05 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Rename bitfields for slot and channel usage tracking The names chosen for the bitfields were quite confusing and given no real information on what they are used for... edma_inuse -> slot_inuse: tracks the slot usage/availability edma_unused -> channel_unused: tracks the channel usage/availability Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:05 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Rename bitfields for slot and channel usage tracking The names chosen for the bitfields were quite confusing and given no real information on what they are used for... edma_inuse -> slot_inuse: tracks the slot usage/availability edma_unused -> channel_unused: tracks the channel usage/availability Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:05 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Print warning when linking slots from different eDMA Warning message in case of linking between paRAM slots in different eDMA controllers. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:59 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_) These inline functions are designed to modify parts of the PaRAM in eDMA. Change the names accordingly. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:02 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Use dev_dbg instead pr_debug We have access to dev, so it is better to use the dev_dbg for debug prints. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:57 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Use dev_dbg instead pr_debug We have access to dev, so it is better to use the dev_dbg for debug prints. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:57 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Consolidate the comments for functions Remove or rewrite the comments for the internal functions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:00 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Consolidate the comments for functions Remove or rewrite the comments for the internal functions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:00 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Use dev_dbg instead pr_debug We have access to dev, so it is better to use the dev_dbg for debug prints. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:57 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Merge map_dmach_to_queue into assign_channel_eventq edma_assign_channel_eventq() is a wrapper around edma_map_dmach_to_queue() We can merge the content of the later so we will have only one function to be used for mapping channels to given eventq Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:03 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Merge map_dmach_to_queue into assign_channel_eventq edma_assign_channel_eventq() is a wrapper around edma_map_dmach_to_queue() We can merge the content of the later so we will have only one function to be used for mapping channels to given eventq Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:03 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Simplify and optimize the edma_execute path The code path in edma_execute() and edma_callback() can be simplified and make it more optimal. There is not need to call in to edma_execute() when the transfer has been finished for example. Also the handling of missed/first or next batch of paRAMs can be done in a more optimal way. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:45 +03:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
dmaengine: edma: Simplify and optimize the edma_execute path The code path in edma_execute() and edma_callback() can be simplified and make it more optimal. There is not need to call in to edma_execute() when the transfer has been finished for example. Also the handling of missed/first or next batch of paRAMs can be done in a more optimal way. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:45 +03:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: edma: Cleanup regarding the use of dev around the code Be consistent and do not mix the use of dev, &pdev->dev, etc in the functions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:56 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
dma: edma: Leave linked to Null slot instead of DUMMY slot Dummy slot has been used as a way for missed-events not to be reported as missing. This has been particularly troublesome for cases where we might want to temporarily pause all incoming events. For EDMA DMAC, there is no way to do any such pausing of events as the occurence of the "next" event is not software controlled. Using "edma_pause" in IRQ handlers doesn't help as by then the event in concern from the slave is already missed. Linking a dummy slot, is seen to absorb these events which we didn't want to miss. So we don't link to dummy, but instead leave it linked to NULL set, allow an error condition and detect the channel that missed it. Consider the case where we have a scatter-list like: SG1->SG2->SG3->SG4->SG5->SG6->Null For ex, for a MAX_NR_SG of 2, earlier we were splitting this as: SG1->SG2->Null SG3->SG4->Null SG5->SG6->Null Now we split it as SG1->SG2->Null SG3->SG4->Null SG5->SG6->Dummy This approach results in lesser unwanted interrupts that occur for the last list split. The Dummy slot has the property of not raising an error condition if events are missed unlike the Null slot. We are OK with this as we're done with processing the whole list once we reach Dummy. Signed-off-by: Joel Fernandes <joelf@ti.com> [modifed duplicate s-o-b & patch title] Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-08-29 18:05:44 -05:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dma: edma: Leave linked to Null slot instead of DUMMY slot Dummy slot has been used as a way for missed-events not to be reported as missing. This has been particularly troublesome for cases where we might want to temporarily pause all incoming events. For EDMA DMAC, there is no way to do any such pausing of events as the occurence of the "next" event is not software controlled. Using "edma_pause" in IRQ handlers doesn't help as by then the event in concern from the slave is already missed. Linking a dummy slot, is seen to absorb these events which we didn't want to miss. So we don't link to dummy, but instead leave it linked to NULL set, allow an error condition and detect the channel that missed it. Consider the case where we have a scatter-list like: SG1->SG2->SG3->SG4->SG5->SG6->Null For ex, for a MAX_NR_SG of 2, earlier we were splitting this as: SG1->SG2->Null SG3->SG4->Null SG5->SG6->Null Now we split it as SG1->SG2->Null SG3->SG4->Null SG5->SG6->Dummy This approach results in lesser unwanted interrupts that occur for the last list split. The Dummy slot has the property of not raising an error condition if events are missed unlike the Null slot. We are OK with this as we're done with processing the whole list once we reach Dummy. Signed-off-by: Joel Fernandes <joelf@ti.com> [modifed duplicate s-o-b & patch title] Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-08-29 18:05:44 -05:00
dmaengine: edma: Simplify and optimize the edma_execute path The code path in edma_execute() and edma_callback() can be simplified and make it more optimal. There is not need to call in to edma_execute() when the transfer has been finished for example. Also the handling of missed/first or next batch of paRAMs can be done in a more optimal way. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:45 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Simplify and optimize the edma_execute path The code path in edma_execute() and edma_callback() can be simplified and make it more optimal. There is not need to call in to edma_execute() when the transfer has been finished for example. Also the handling of missed/first or next batch of paRAMs can be done in a more optimal way. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:45 +03:00
dmaengine: edma: Add channel number to debug prints It helps to identify issues if we have some information regarding to the channel which the event is associated. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-24 10:29:50 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dma: edma: fix incorrect SG list handling The code to handle any length SG lists calls edma_resume() even before edma_start() is called. This is incorrect because edma_resume() enables edma events on the channel after which CPU (in edma_start) cannot clear posted events by writing to ECR (per the EDMA user's guide). Because of this EDMA transfers fail to start if due to some reason there is a pending EDMA event registered even before EDMA transfers are started. This can happen if an EDMA event is a byproduct of device initialization. Fix this by calling edma_resume() only if it is not the first batch of MAX_NR_SG elements. Without this patch, MMC/SD fails to function on DA850 EVM with DMA. The behaviour is triggered by specific IP and this can explain why the issue was not reported before (example with MMC/SD on AM335x). Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card. Cc: stable@vger.kernel.org # v3.12.x+ Cc: Joel Fernandes <joelf@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Tested-by: Jon Ringle <jringle@gridpoint.com> Tested-by: Alexander Holler <holler@ahsoftware.de> Reported-by: Jon Ringle <jringle@gridpoint.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-03-19 11:25:50 +05:30
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dma: edma: Write out and handle MAX_NR_SG at a given time Process SG-elements in batches of MAX_NR_SG if they are greater than MAX_NR_SG. Due to this, at any given time only those many slots will be used in the given channel no matter how long the scatter list is. We keep track of how much has been written inorder to process the next batch of elements in the scatter-list and detect completion. For such intermediate transfer completions (one batch of MAX_NR_SG), make use of pause and resume functions instead of start and stop when such intermediate transfer is in progress or completed as we donot want to clear any pending events. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-03 10:02:46 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Split device_control Split the device_control callback of the TI EDMA driver to make use of the newly introduced callbacks, that will eventually be used to retrieve slave capabilities. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:13 +01:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Split device_control Split the device_control callback of the TI EDMA driver to make use of the newly introduced callbacks, that will eventually be used to retrieve slave capabilities. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:13 +01:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Simplify and optimize the edma_execute path The code path in edma_execute() and edma_callback() can be simplified and make it more optimal. There is not need to call in to edma_execute() when the transfer has been finished for example. Also the handling of missed/first or next batch of paRAMs can be done in a more optimal way. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:45 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: fix memory leak when terminating running transfers If edma_terminate_all() was called while a transfer was running (i.e. after edma_execute() but before edma_callback()) the echan->edesc was not freed. This was due to the fact that a running transfer is on none of the vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute() removes it from the desc_issued list), so the vchan_dma_desc_free_list() called at the end of edma_terminate_all() didn't find it and didn't free it. This bug was found on an AM1808 based hardware (very similar to da850evm, however using the second MMC/SD controller), where intense operations on the SD card wasted the device 128MB RAM within a couple of days. Peter Ujfalusi: The issue is even more severe since it affects cyclic (audio) transfers as well. In this case starting/stopping audio will results memory leak. Signed-off-by: Petr Kulhavy <petr@barix.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: <stable@vger.kernel.org> CC: <linux-omap@vger.kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-03-27 13:35:51 +02:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Implement device_synchronize callback We need the callback to support the dmaengine_terminate_sync(). Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-02-11 11:08:42 +02:00
dmaengine: edma: Split device_control Split the device_control callback of the TI EDMA driver to make use of the newly introduced callbacks, that will eventually be used to retrieve slave capabilities. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:13 +01:00
dma: edma: fix slave config dependency on direction The edma_slave_config() implementation depends on the direction field such that it will not properly configure a slave channel when called without direction set. This fixes the implementation so that the slave config is copied as is and prep_slave_sg() handles the direction dependent handling. spi-omap2-mcspi and omap_hsmmc both expose this bug as they configure the slave channel config from a common path with an unconfigured direction field. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-01-10 13:41:04 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Split device_control Split the device_control callback of the TI EDMA driver to make use of the newly introduced callbacks, that will eventually be used to retrieve slave capabilities. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:13 +01:00
dma: edma: fix slave config dependency on direction The edma_slave_config() implementation depends on the direction field such that it will not properly configure a slave channel when called without direction set. This fixes the implementation so that the slave config is copied as is and prep_slave_sg() handles the direction dependent handling. spi-omap2-mcspi and omap_hsmmc both expose this bug as they configure the slave channel config from a common path with an unconfigured direction field. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-01-10 13:41:04 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: fix slave config dependency on direction The edma_slave_config() implementation depends on the direction field such that it will not properly configure a slave channel when called without direction set. This fixes the implementation so that the slave config is copied as is and prep_slave_sg() handles the direction dependent handling. spi-omap2-mcspi and omap_hsmmc both expose this bug as they configure the slave channel config from a common path with an unconfigured direction field. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-01-10 13:41:04 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Split device_control Split the device_control callback of the TI EDMA driver to make use of the newly introduced callbacks, that will eventually be used to retrieve slave capabilities. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:13 +01:00
dmaengine: edma: Add support for DMA_PAUSE/RESUME operation Pause/Resume can be used by the audio stack when the stream is paused/resumed The edma platform code has support for this and the legacy audio stack used this. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:41:59 +03:00
dmaengine: edma: Split device_control Split the device_control callback of the TI EDMA driver to make use of the newly introduced callbacks, that will eventually be used to retrieve slave capabilities. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:13 +01:00
dmaenegine: edma: allow pause/resume for non-cyclic mode The 8250_omap serial driver relies on dmaengine_pause() actually pausing the DMA transfer. Before this patch dmaengine_pause() is a NOP for non-cylic DMA transfers. This allowed the 8250_omap driver to read DMA buffers while the DMA was still active, resulting in lost serial data. Signed-off-by: John Ogness <john.ogness@linutronix.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-27 13:52:25 +02:00
dmaengine: edma: Add support for DMA_PAUSE/RESUME operation Pause/Resume can be used by the audio stack when the stream is paused/resumed The edma platform code has support for this and the legacy audio stack used this. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:41:59 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Add support for DMA_PAUSE/RESUME operation Pause/Resume can be used by the audio stack when the stream is paused/resumed The edma platform code has support for this and the legacy audio stack used this. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:41:59 +03:00
dmaengine: edma: Split device_control Split the device_control callback of the TI EDMA driver to make use of the newly introduced callbacks, that will eventually be used to retrieve slave capabilities. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:13 +01:00
dmaengine: edma: Add support for DMA_PAUSE/RESUME operation Pause/Resume can be used by the audio stack when the stream is paused/resumed The edma platform code has support for this and the legacy audio stack used this. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:41:59 +03:00
dmaengine: edma: Split device_control Split the device_control callback of the TI EDMA driver to make use of the newly introduced callbacks, that will eventually be used to retrieve slave capabilities. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:13 +01:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Add support for DMA_PAUSE/RESUME operation Pause/Resume can be used by the audio stack when the stream is paused/resumed The edma platform code has support for this and the legacy audio stack used this. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:41:59 +03:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Correct the handling of src/dst_maxburst == 0 When clients asks for maxburst = 0 it is basically the same case as if they were asking for maxburst = 1 since in both case ASYNC need to be used and the eDMA is expected to write/read one word per DMA request. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:41:58 +03:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Store transfer data in edma_desc and edma_pset For granular accounting we need to store the direction and the information for the individual psets: - source or destination address, depending on direction - length Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:29:57 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Store transfer data in edma_desc and edma_pset For granular accounting we need to store the direction and the information for the individual psets: - source or destination address, depending on direction - length Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:29:57 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Store transfer data in edma_desc and edma_pset For granular accounting we need to store the direction and the information for the individual psets: - source or destination address, depending on direction - length Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:29:57 -05:00
dmaengine: edma: Add DMA memcpy support We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-18 21:50:33 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dma: edma: fix slave config dependency on direction The edma_slave_config() implementation depends on the direction field such that it will not properly configure a slave channel when called without direction set. This fixes the implementation so that the slave config is copied as is and prep_slave_sg() handles the direction dependent handling. spi-omap2-mcspi and omap_hsmmc both expose this bug as they configure the slave channel config from a common path with an unconfigured direction field. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-01-10 13:41:04 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: fix slave config dependency on direction The edma_slave_config() implementation depends on the direction field such that it will not properly configure a slave channel when called without direction set. This fixes the implementation so that the slave config is copied as is and prep_slave_sg() handles the direction dependent handling. spi-omap2-mcspi and omap_hsmmc both expose this bug as they configure the slave channel config from a common path with an unconfigured direction field. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-01-10 13:41:04 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dma: edma: fix slave config dependency on direction The edma_slave_config() implementation depends on the direction field such that it will not properly configure a slave channel when called without direction set. This fixes the implementation so that the slave config is copied as is and prep_slave_sg() handles the direction dependent handling. spi-omap2-mcspi and omap_hsmmc both expose this bug as they configure the slave channel config from a common path with an unconfigured direction field. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-01-10 13:41:04 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dma: edma: fix slave config dependency on direction The edma_slave_config() implementation depends on the direction field such that it will not properly configure a slave channel when called without direction set. This fixes the implementation so that the slave config is copied as is and prep_slave_sg() handles the direction dependent handling. spi-omap2-mcspi and omap_hsmmc both expose this bug as they configure the slave channel config from a common path with an unconfigured direction field. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-01-10 13:41:04 -05:00
dmaengine: edma: Print the direction value as well when it is not supported In case of not supported direction it is better to print the direction also. It is unlikely, but in such an event it helps with the debugging. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:05 +03:00
dma: edma: fix slave config dependency on direction The edma_slave_config() implementation depends on the direction field such that it will not properly configure a slave channel when called without direction set. This fixes the implementation so that the slave config is copied as is and prep_slave_sg() handles the direction dependent handling. spi-omap2-mcspi and omap_hsmmc both expose this bug as they configure the slave channel config from a common path with an unconfigured direction field. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-01-10 13:41:04 -05:00
dmaengine: edma: Prefix debug prints where the text were identical in prep callbacks prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases with the same texts printed in case we hit them. It helps when debugging if we know exactly which callback generated the errors. At the same time change the debug level for descriptor allocation failure from dbg to err since all other error cases are dev_err and this failure is similarly fatal as the other ones. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:03 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: Remove site specific OOM error messages on kzalloc If kzalloc() fails it will issue it's own error message including a dump_stack(). So remove the site specific error messages. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-06-07 18:38:41 +01:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Sanitize residue reporting The residue reporting in edma_tx_status() is just broken. It blindly walks the psets and recalculates the lenght of the transfer from the hardware parameters. For cyclic transfers it adds the link pset, which results in interestingly large residues. For non-cyclic it adds the dummy pset, which is stupid as well. Aside of that it's silly to walk through the pset params when the per descriptor residue is known at the point of creating it. Store the information in edma_desc and use it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:18:45 -05:00
dmaengine: edma: Store transfer data in edma_desc and edma_pset For granular accounting we need to store the direction and the information for the individual psets: - source or destination address, depending on direction - length Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:29:57 -05:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Setup parameters to DMA MAX_NR_SG at a time Changes are made here for configuring existing parameters to support DMA'ing them out in batches as needed. Also allocate as many as slots as needed by the SG list, but not more than MAX_NR_SG. Then these slots will be reused accordingly. For ex, if MAX_NR_SG=10, and number of SG entries is 40, still only 10 slots will be allocated to DMA the entire SG list of size 40. Also enable TC interrupts for slots that are a last in a current iteration, or that fall on a MAX_NR_SG boundary. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-08-29 18:05:40 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Fix memory leak When it fails to allocate a slot, edesc should be free'd before return; Signed-off-by: Valentin Ilie <valentin.ilie@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-24 16:14:22 +03:00
dmaengine: edma: Prefix debug prints where the text were identical in prep callbacks prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases with the same texts printed in case we hit them. It helps when debugging if we know exactly which callback generated the errors. At the same time change the debug level for descriptor allocation failure from dbg to err since all other error cases are dev_err and this failure is similarly fatal as the other ones. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:03 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Setup parameters to DMA MAX_NR_SG at a time Changes are made here for configuring existing parameters to support DMA'ing them out in batches as needed. Also allocate as many as slots as needed by the SG list, but not more than MAX_NR_SG. Then these slots will be reused accordingly. For ex, if MAX_NR_SG=10, and number of SG entries is 40, still only 10 slots will be allocated to DMA the entire SG list of size 40. Also enable TC interrupts for slots that are a last in a current iteration, or that fall on a MAX_NR_SG boundary. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-08-29 18:05:40 -05:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
Merge branch 'for-linus' into next Conflicts: drivers/dma/edma.c Moved the memory leak fix post merge Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-30 13:07:18 +05:30
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Split out PaRAM set calculations into its own function PaRAM set calculation is abstracted into its own function to enable better reuse for other DMA cases such as cyclic. We adapt the Slave SG case to use the new function. This provides a much cleaner abstraction to the internals of the PaRAM set. However, any PaRAM attributes that are not common to all DMA types must be set separately such as setting of interrupts. This function takes care of the most-common attributes. Also added comments clarifying A-sync case calculations. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-23 18:05:13 -05:00
dmaengine: edma: Sanitize residue reporting The residue reporting in edma_tx_status() is just broken. It blindly walks the psets and recalculates the lenght of the transfer from the hardware parameters. For cyclic transfers it adds the link pset, which results in interestingly large residues. For non-cyclic it adds the dummy pset, which is stupid as well. Aside of that it's silly to walk through the pset params when the per descriptor residue is known at the point of creating it. Store the information in edma_desc and use it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:18:45 -05:00
dma: edma: Setup parameters to DMA MAX_NR_SG at a time Changes are made here for configuring existing parameters to support DMA'ing them out in batches as needed. Also allocate as many as slots as needed by the SG list, but not more than MAX_NR_SG. Then these slots will be reused accordingly. For ex, if MAX_NR_SG=10, and number of SG entries is 40, still only 10 slots will be allocated to DMA the entire SG list of size 40. Also enable TC interrupts for slots that are a last in a current iteration, or that fall on a MAX_NR_SG boundary. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-08-29 18:05:40 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Use early completion for intermediate paRAM set in slave_sg The driver limits the physical number of paRAM slots to be used by channels. If the transfer needs more slots (more SGs) then the transfer is broken up to smaller chunks. When the chunk is finished the driver will rewrite the physical slots and continues the transfer. This set up time can take some time and we might miss DMA events. If the intermediate set completion is using early completion (the interrupt will happen when the last slot is issued to the TPTC and not when the transfer is finished by the TPTC) we will have a bit more time to update the paRAM slots and less likely to have missed events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-06-07 11:19:44 +03:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dmaengine: edma: Use early completion for intermediate paRAM set in slave_sg The driver limits the physical number of paRAM slots to be used by channels. If the transfer needs more slots (more SGs) then the transfer is broken up to smaller chunks. When the chunk is finished the driver will rewrite the physical slots and continues the transfer. This set up time can take some time and we might miss DMA events. If the intermediate set completion is using early completion (the interrupt will happen when the last slot is issued to the TPTC and not when the transfer is finished by the TPTC) we will have a bit more time to update the paRAM slots and less likely to have missed events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-06-07 11:19:44 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaenegine: edma: fix sparse warnings this patch fixes following sparse warnings: edma.c:537:32: warning: symbol 'edma_prep_dma_memcpy' was not declared. Should it be static? edma.c:1070:6: warning: symbol 'edma_filter_fn' was not declared. Should it be static? Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-02-04 13:03:27 +00:00
dmaengine: edma: Add DMA memcpy support We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-18 21:50:33 -05:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
dmaengine: edma: Add DMA memcpy support We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-18 21:50:33 -05:00
dmaengine: edma: Align the memcpy acnt array size with the transfer Memory to Memory transfers does not have any special alignment needs regarding to acnt array size, but if one of the areas are in memory mapped regions (like PCIe memory), we need to make sure that the acnt array size is aligned with the mem copy parameters. Before "dmaengine: edma: Optimize memcpy operation" change the memcpy was set up in a different way: acnt == number of bytes in a word based on __ffs((src | dest | len), bcnt and ccnt for looping the necessary number of words to comlete the trasnfer. Instead of reverting the commit we can fix it to make sure that the ACNT size is aligned to the traswnfer. Fixes: df6694f80365a (dmaengine: edma: Optimize memcpy operation) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-09-18 11:16:26 +03:00
dmaengine: edma: Add DMA memcpy support We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-18 21:50:33 -05:00
dmaengine: edma: Align the memcpy acnt array size with the transfer Memory to Memory transfers does not have any special alignment needs regarding to acnt array size, but if one of the areas are in memory mapped regions (like PCIe memory), we need to make sure that the acnt array size is aligned with the mem copy parameters. Before "dmaengine: edma: Optimize memcpy operation" change the memcpy was set up in a different way: acnt == number of bytes in a word based on __ffs((src | dest | len), bcnt and ccnt for looping the necessary number of words to comlete the trasnfer. Instead of reverting the commit we can fix it to make sure that the ACNT size is aligned to the traswnfer. Fixes: df6694f80365a (dmaengine: edma: Optimize memcpy operation) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-09-18 11:16:26 +03:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
dmaengine: edma: Align the memcpy acnt array size with the transfer Memory to Memory transfers does not have any special alignment needs regarding to acnt array size, but if one of the areas are in memory mapped regions (like PCIe memory), we need to make sure that the acnt array size is aligned with the mem copy parameters. Before "dmaengine: edma: Optimize memcpy operation" change the memcpy was set up in a different way: acnt == number of bytes in a word based on __ffs((src | dest | len), bcnt and ccnt for looping the necessary number of words to comlete the trasnfer. Instead of reverting the commit we can fix it to make sure that the ACNT size is aligned to the traswnfer. Fixes: df6694f80365a (dmaengine: edma: Optimize memcpy operation) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-09-18 11:16:26 +03:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
dmaengine: Remove site specific OOM error messages on kzalloc If kzalloc() fails it will issue it's own error message including a dump_stack(). So remove the site specific error messages. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-06-07 18:38:41 +01:00
dmaengine: edma: Add DMA memcpy support We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-18 21:50:33 -05:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
dmaengine: edma: Remove alignment constraint for memcpy Despite the claim by the original commit adding the memcpy support, eDMA does not have constraint on the alignment of src, dst or length in increment mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:17:59 +03:00
dmaengine: edma: Add DMA memcpy support We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-18 21:50:33 -05:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
dmaengine: edma: Add DMA memcpy support We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-18 21:50:33 -05:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
dmaengine: edma: Add DMA memcpy support We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-18 21:50:33 -05:00
dmaengine: edma: update DMA memcpy to use new param element edma param struct is now within an edma_pset struct introduced in Thomas Gleixner's edma tx status series. Update memcpy function for the same. Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 15:30:32 -05:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
dmaengine: edma: Align the memcpy acnt array size with the transfer Memory to Memory transfers does not have any special alignment needs regarding to acnt array size, but if one of the areas are in memory mapped regions (like PCIe memory), we need to make sure that the acnt array size is aligned with the mem copy parameters. Before "dmaengine: edma: Optimize memcpy operation" change the memcpy was set up in a different way: acnt == number of bytes in a word based on __ffs((src | dest | len), bcnt and ccnt for looping the necessary number of words to comlete the trasnfer. Instead of reverting the commit we can fix it to make sure that the ACNT size is aligned to the traswnfer. Fixes: df6694f80365a (dmaengine: edma: Optimize memcpy operation) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-09-18 11:16:26 +03:00
dmaengine: edma: Optimize memcpy operation If the transfer is shorted then 64K we can complete it with one ACNT burst by configuring ACNT to the length of the copy, this require one paRAM slot. Otherwise we use two paRAM slots for the copy: slot1: will copy (length / 32767) number of 32767 byte long blocks slot2: will be configured to copy the remaining data. According to tests this patch increases the throughput of memcpy from ~3MB/s to 15MB/s Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:00 +03:00
dmaengine: edma: Add DMA memcpy support We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-18 21:50:33 -05:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: Remove the context argument to the prep_dma_cyclic operation The argument is always set to NULL and never used. Remove it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-08-01 12:20:10 +02:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: special case slot limit workaround Currently drivers are limited to 19 slots for cyclic transfers. However, if the DMA burst size is the same as the period size, the period size can be changed to the full buffer size and intermediate interrupts activated. Since intermediate interrupts will trigger for each burst and the burst size is the same as the period size, the driver will get interrupts each period as expected. This has the benefit of allowing the functionality of many more slots, but only uses 2 slots. This workaround is only active if more than 19 slots are needed and the burst size matches the period size. Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-04-06 13:01:47 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: Print the direction value as well when it is not supported In case of not supported direction it is better to print the direction also. It is unlikely, but in such an event it helps with the debugging. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:05 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: Prefix debug prints where the text were identical in prep callbacks prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases with the same texts printed in case we hit them. It helps when debugging if we know exactly which callback generated the errors. At the same time change the debug level for descriptor allocation failure from dbg to err since all other error cases are dev_err and this failure is similarly fatal as the other ones. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:03 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: special case slot limit workaround Currently drivers are limited to 19 slots for cyclic transfers. However, if the DMA burst size is the same as the period size, the period size can be changed to the full buffer size and intermediate interrupts activated. Since intermediate interrupts will trigger for each burst and the burst size is the same as the period size, the driver will get interrupts each period as expected. This has the benefit of allowing the functionality of many more slots, but only uses 2 slots. This workaround is only active if more than 19 slots are needed and the burst size matches the period size. Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-04-06 13:01:47 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: Remove site specific OOM error messages on kzalloc If kzalloc() fails it will issue it's own error message including a dump_stack(). So remove the site specific error messages. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-06-07 18:38:41 +01:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: edma: Store transfer data in edma_desc and edma_pset For granular accounting we need to store the direction and the information for the individual psets: - source or destination address, depending on direction - length Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:29:57 -05:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: Reduce debug print verbosity for non verbose debugging Do not print the paRAM information when verbose debugging is not asked and also reduce the number of lines printed in edma_prep_dma_cyclic() Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:02 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dma: edma: Fix memory leak in edma_prep_dma_cyclic() Fix a memory leak in the edma_prep_dma_cyclic() error handling path. Signed-off-by: Christian Engelmayer <cengelma@gmx.at> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-12-30 20:48:39 +01:00
dmaengine: edma: Prefix debug prints where the text were identical in prep callbacks prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases with the same texts printed in case we hit them. It helps when debugging if we know exactly which callback generated the errors. At the same time change the debug level for descriptor allocation failure from dbg to err since all other error cases are dev_err and this failure is similarly fatal as the other ones. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:03 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dma: edma: Fix memory leak in edma_prep_dma_cyclic() Fix a memory leak in the edma_prep_dma_cyclic() error handling path. Signed-off-by: Christian Engelmayer <cengelma@gmx.at> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-12-30 20:48:39 +01:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dma: edma: Fix memory leak in edma_prep_dma_cyclic() Fix a memory leak in the edma_prep_dma_cyclic() error handling path. Signed-off-by: Christian Engelmayer <cengelma@gmx.at> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-12-30 20:48:39 +01:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: Reduce debug print verbosity for non verbose debugging Do not print the paRAM information when verbose debugging is not asked and also reduce the number of lines printed in edma_prep_dma_cyclic() Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:02 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: Create private pset struct Preparatory patch to support finer grained accounting. Move the edma_params array out of edma_desc so we can add further per pset data to it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Fixed up hunk #3 in original patch to apply] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:23:55 -05:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: Support to suppress the period interrupts in cyclic mode If the client (audio) does not request interrupts for every period we can disable them. With updated audio driver stack we can play audio w/o the need to process any edma interrupts. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-07-16 15:29:21 +03:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: special case slot limit workaround Currently drivers are limited to 19 slots for cyclic transfers. However, if the DMA burst size is the same as the period size, the period size can be changed to the full buffer size and intermediate interrupts activated. Since intermediate interrupts will trigger for each burst and the burst size is the same as the period size, the driver will get interrupts each period as expected. This has the benefit of allowing the functionality of many more slots, but only uses 2 slots. This workaround is only active if more than 19 slots are needed and the burst size matches the period size. Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-04-06 13:01:47 +03:00
dmaengine: edma: Support to suppress the period interrupts in cyclic mode If the client (audio) does not request interrupts for every period we can disable them. With updated audio driver stack we can play audio w/o the need to process any edma interrupts. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-07-16 15:29:21 +03:00
dmaengine: edma: special case slot limit workaround Currently drivers are limited to 19 slots for cyclic transfers. However, if the DMA burst size is the same as the period size, the period size can be changed to the full buffer size and intermediate interrupts activated. Since intermediate interrupts will trigger for each burst and the burst size is the same as the period size, the driver will get interrupts each period as expected. This has the benefit of allowing the functionality of many more slots, but only uses 2 slots. This workaround is only active if more than 19 slots are needed and the burst size matches the period size. Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-04-06 13:01:47 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Serve cyclic (audio) channels with high priority queue Move the DMA channel used in cyclic mode (audio) to the highest priority event queue which helps to reduce audio problems. When the channel is terminated, move it back to the default queue. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-07-08 13:46:38 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Serve cyclic (audio) channels with high priority queue Move the DMA channel used in cyclic mode (audio) to the highest priority event queue which helps to reduce audio problems. When the channel is terminated, move it back to the default queue. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-07-08 13:46:38 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Fetch echan->edesc while holding lock in edma_comletion_handler In order to avoid possible race condition when client drivers are using dmaengine_terminate_sync() call to disable the channel. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-02-11 15:17:48 +02:00
dma: edma: Add support for Cyclic DMA Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-31 16:31:23 -05:00
dmaengine: edma: Simplify and optimize the edma_execute path The code path in edma_execute() and edma_callback() can be simplified and make it more optimal. There is not need to call in to edma_execute() when the transfer has been finished for example. Also the handling of missed/first or next batch of paRAMs can be done in a more optimal way. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:45 +03:00
dmaengine: edma: Fetch echan->edesc while holding lock in edma_comletion_handler In order to avoid possible race condition when client drivers are using dmaengine_terminate_sync() call to disable the channel. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-02-11 15:17:48 +02:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: edma: Fetch echan->edesc while holding lock in edma_comletion_handler In order to avoid possible race condition when client drivers are using dmaengine_terminate_sync() call to disable the channel. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-02-11 15:17:48 +02:00
dmaengine: edma: Simplify and optimize the edma_execute path The code path in edma_execute() and edma_callback() can be simplified and make it more optimal. There is not need to call in to edma_execute() when the transfer has been finished for example. Also the handling of missed/first or next batch of paRAMs can be done in a more optimal way. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:45 +03:00
dmaengine: edma: Fetch echan->edesc while holding lock in edma_comletion_handler In order to avoid possible race condition when client drivers are using dmaengine_terminate_sync() call to disable the channel. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-02-11 15:17:48 +02:00
dma: edma: Find missed events and issue them In an effort to move to using Scatter gather lists of any size with EDMA as discussed at [1] instead of placing limitations on the driver, we work through the limitations of the EDMAC hardware to find missed events and issue them. The sequence of events that require this are: For the scenario where MAX slots for an EDMA channel is 3: SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> Null The above SG list will have to be DMA'd in 2 sets: (1) SG1 -> SG2 -> SG3 -> Null (2) SG4 -> SG5 -> SG6 -> Null After (1) is succesfully transferred, the events from the MMC controller donot stop coming and are missed by the time we have setup the transfer for (2). So here, we catch the events missed as an error condition and issue them manually. In the second part of the patch, we make handle the NULL slot cases: For crypto IP, we continue to receive events even continuously in NULL slot, the setup of the next set of SG elements happens after the error handler executes. This is results in some recursion problems. Due to this, we continously receive error interrupts when we manually trigger an event from the error handler. We fix this, by first detecting if the Channel is currently transferring from a NULL slot or not, that's where the edma_read_slot in the error callback from interrupt handler comes in. With this we can determine if the set up of the next SG list has completed, and we manually trigger only in this case. If the setup has _not_ completed, we are still in NULL so we just set a missed flag and allow the manual triggerring to happen in edma_execute which will be eventually called. This fixes the above mentioned race conditions seen with the crypto drivers. [1] http://marc.info/?l=linux-omap&m=137416733628831&w=2 Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-08-29 18:05:43 -05:00
dmaengine: edma: Fetch echan->edesc while holding lock in edma_comletion_handler In order to avoid possible race condition when client drivers are using dmaengine_terminate_sync() call to disable the channel. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-02-11 15:17:48 +02:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify and optimize the edma_execute path The code path in edma_execute() and edma_callback() can be simplified and make it more optimal. There is not need to call in to edma_execute() when the transfer has been finished for example. Also the handling of missed/first or next batch of paRAMs can be done in a more optimal way. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:45 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: avoid uninitialized variable use If edma_read_slot() gets an invalid argument, it does not set a result, as found by "gcc -Wmaybe-uninitialized" drivers/dma/edma.c: In function 'dma_ccerr_handler': drivers/dma/edma.c:1499:21: error: 'p.a_b_cnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/dma/edma.c:1499:21: error: 'p.ccnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (p.a_b_cnt == 0 && p.ccnt == 0) { If we change the function to return an error in this case, we can handle the failure more gracefully and treat this the same way as a null slot that we already catch. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-30 18:19:01 +02:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: avoid uninitialized variable use If edma_read_slot() gets an invalid argument, it does not set a result, as found by "gcc -Wmaybe-uninitialized" drivers/dma/edma.c: In function 'dma_ccerr_handler': drivers/dma/edma.c:1499:21: error: 'p.a_b_cnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/dma/edma.c:1499:21: error: 'p.ccnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (p.a_b_cnt == 0 && p.ccnt == 0) { If we change the function to return an error in this case, we can handle the failure more gracefully and treat this the same way as a null slot that we already catch. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-30 18:19:01 +02:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: avoid uninitialized variable use If edma_read_slot() gets an invalid argument, it does not set a result, as found by "gcc -Wmaybe-uninitialized" drivers/dma/edma.c: In function 'dma_ccerr_handler': drivers/dma/edma.c:1499:21: error: 'p.a_b_cnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/dma/edma.c:1499:21: error: 'p.ccnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (p.a_b_cnt == 0 && p.ccnt == 0) { If we change the function to return an error in this case, we can handle the failure more gracefully and treat this the same way as a null slot that we already catch. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-30 18:19:01 +02:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Move the pending error check into helper function In the ccerr interrupt handler the code checks for pending errors in the error status registers in two different places. Move the check out to a helper function. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:02 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify and optimize ccerr interrupt handler No need to run through the bits in QEMR and CCERR events since they will not trigger any action, so just clearing the errors there is fine. In case of the missed event the loop can be optimized so we spend less time to handle the event. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:03 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify and optimize ccerr interrupt handler No need to run through the bits in QEMR and CCERR events since they will not trigger any action, so just clearing the errors there is fine. In case of the missed event the loop can be optimized so we spend less time to handle the event. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:03 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Re-evaluate errors when ccerr is triggered w/o error event When the ccerr handler is called but the error registers indicate no error events we need to command eDMA to re-evaluate the errors. Otherwise we can receive flood of error interrupts. Reported-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-05-10 13:40:54 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Re-evaluate errors when ccerr is triggered w/o error event When the ccerr handler is called but the error registers indicate no error events we need to command eDMA to re-evaluate the errors. Otherwise we can receive flood of error interrupts. Reported-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-05-10 13:40:54 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify and optimize ccerr interrupt handler No need to run through the bits in QEMR and CCERR events since they will not trigger any action, so just clearing the errors there is fine. In case of the missed event the loop can be optimized so we spend less time to handle the event. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:03 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify and optimize ccerr interrupt handler No need to run through the bits in QEMR and CCERR events since they will not trigger any action, so just clearing the errors there is fine. In case of the missed event the loop can be optimized so we spend less time to handle the event. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:03 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify and optimize ccerr interrupt handler No need to run through the bits in QEMR and CCERR events since they will not trigger any action, so just clearing the errors there is fine. In case of the missed event the loop can be optimized so we spend less time to handle the event. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:03 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify and optimize ccerr interrupt handler No need to run through the bits in QEMR and CCERR events since they will not trigger any action, so just clearing the errors there is fine. In case of the missed event the loop can be optimized so we spend less time to handle the event. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:03 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: edma: Simplify and optimize ccerr interrupt handler No need to run through the bits in QEMR and CCERR events since they will not trigger any action, so just clearing the errors there is fine. In case of the missed event the loop can be optimized so we spend less time to handle the event. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:03 +03:00
dmaengine: edma: Move the pending error check into helper function In the ccerr interrupt handler the code checks for pending errors in the error status registers in two different places. Move the check out to a helper function. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:02 +03:00
dmaengine: edma: Simplify the interrupt handling With the merger of the arch/arm/common/edma.c code into the dmaengine driver, there is no longer need to have per channel callback/data storage for interrupt events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:01 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
dmaengine: edma: Fix error return code in edma_alloc_chan_resources() Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-17 15:16:35 +00:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: fix residue race for cyclic When retrieving the residue value, the SRC/DST fields of the active PaRAM are read to determine the current position of the DMA engine. However, the AM335x Technical Reference Manual states: 11.3.3.6 Parameter Set Updates After the TR is read from the PaRAM (and is in the process of being submitted to the EDMA3TC), the following fields are updated as needed: ... SRC DST This means SRC/DST is incremented even though the DMA transfer may not have started yet or is in progress. Thus if the reader of the residue accesses the DMA buffer too quickly, the CPU is misinformed about the data that has been successfully processed. The CCSTAT.ACTV register is a boolean that is set if any TR is being processed by either the EMDA3CC or EDMA3TC. By polling this register it is possible to ensure that the residue value returned is valid for immediate processing. However, since the DMA engine may be active, polling may never hit a moment where no TR is being processed. To handle this, the SRC/DST is also polled to see if it changes. And as a last resort, a max loop count for the busy waiting exists to avoid an infinite loop. Signed-off-by: John Ogness <john.ogness@linutronix.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-01-28 11:29:08 +01:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: edma: fix residue race for cyclic When retrieving the residue value, the SRC/DST fields of the active PaRAM are read to determine the current position of the DMA engine. However, the AM335x Technical Reference Manual states: 11.3.3.6 Parameter Set Updates After the TR is read from the PaRAM (and is in the process of being submitted to the EDMA3TC), the following fields are updated as needed: ... SRC DST This means SRC/DST is incremented even though the DMA transfer may not have started yet or is in progress. Thus if the reader of the residue accesses the DMA buffer too quickly, the CPU is misinformed about the data that has been successfully processed. The CCSTAT.ACTV register is a boolean that is set if any TR is being processed by either the EMDA3CC or EDMA3TC. By polling this register it is possible to ensure that the residue value returned is valid for immediate processing. However, since the DMA engine may be active, polling may never hit a moment where no TR is being processed. To handle this, the SRC/DST is also polled to see if it changes. And as a last resort, a max loop count for the busy waiting exists to avoid an infinite loop. Signed-off-by: John Ogness <john.ogness@linutronix.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-01-28 11:29:08 +01:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: edma: fix residue race for cyclic When retrieving the residue value, the SRC/DST fields of the active PaRAM are read to determine the current position of the DMA engine. However, the AM335x Technical Reference Manual states: 11.3.3.6 Parameter Set Updates After the TR is read from the PaRAM (and is in the process of being submitted to the EDMA3TC), the following fields are updated as needed: ... SRC DST This means SRC/DST is incremented even though the DMA transfer may not have started yet or is in progress. Thus if the reader of the residue accesses the DMA buffer too quickly, the CPU is misinformed about the data that has been successfully processed. The CCSTAT.ACTV register is a boolean that is set if any TR is being processed by either the EMDA3CC or EDMA3TC. By polling this register it is possible to ensure that the residue value returned is valid for immediate processing. However, since the DMA engine may be active, polling may never hit a moment where no TR is being processed. To handle this, the SRC/DST is also polled to see if it changes. And as a last resort, a max loop count for the busy waiting exists to avoid an infinite loop. Signed-off-by: John Ogness <john.ogness@linutronix.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-01-28 11:29:08 +01:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: use DMA_COMPLETE for dma completion status Tested-by: Joel Fernandes <joelf@ti.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-10-16 13:42:15 +05:30
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Check the current decriptor first in tx_status() It's likely that the caller investigates the status of a currently active descriptor. Make that simple check first and only rumage in the vchan list if that fails. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:19:51 -05:00
dmaengine: edma: Provide granular accounting The first slot in the ParamRAM of EDMA holds the current active subtransfer. Depending on the direction we read either the source or the destination address from there. In the internal psets we have the address of the buffer(s). In the cyclic case we only use the internal pset[0] which holds the start address of the circular buffer and calculate the remaining room to the end of the buffer. In the SG case we read the current address and compare it to the internal psets address and length. - If the current address is outside of this range, the pset has been processed already and we mark it done, update the residue_stat value and process the next set. That avoids that we need to walk all processed psets for every invocation of tx_status. - If its inside the range we know that we look at the current active set and stop the walk. - In case of intermediate transfers we update the stats in the interrupt callback function before starting the next batch of transfers. The tx_status callback and the interrupt callback are serialized via vchan.lock. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [joelf@ti.com: Hunk #2 in original patch manually applied] Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:34:11 -05:00
dmaengine: edma: Check the current decriptor first in tx_status() It's likely that the caller investigates the status of a currently active descriptor. Make that simple check first and only rumage in the vchan list if that fails. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-28 14:19:51 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type This change makes the DT file to be easier to read since the memcpy channels array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:10 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type This change makes the DT file to be easier to read since the memcpy channels array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:10 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type This change makes the DT file to be easier to read since the memcpy channels array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:10 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Implement device_slave_caps callback With the callback implemented omap-dma can provide information to client drivers regarding to supported address widths, directions, residue granularity, etc. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:01 +03:00
dma: edma: Declare DMA_SLAVE_BUSWIDTH_3_BYTES as supported buswidth eDMA can be configured for 3bytes word size for source and destination. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-07-03 07:51:56 +03:00
dmaengine: edma: Implement device_slave_caps callback With the callback implemented omap-dma can provide information to client drivers regarding to supported address widths, directions, residue granularity, etc. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Joel Fernandes <joelf@ti.com> Reviewed-and-Tested-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-04-14 14:42:01 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type This change makes the DT file to be easier to read since the memcpy channels array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:10 +02:00
dmaengine: edma: Refactor the dma device and channel struct initialization Move all code under one function to do the dma device and eDMA channel related setup so they are not scattered around the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:05 +03:00
dmaengine: edma: Declare slave capabilities for the generic code Now that the generic slave caps code can make use of the device assigned capabilities, instead of relying on a callback to be implemented. Make use of this code. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:47 +01:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Declare slave capabilities for the generic code Now that the generic slave caps code can make use of the device assigned capabilities, instead of relying on a callback to be implemented. Make use of this code. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-17 14:42:47 +01:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Implement device_synchronize callback We need the callback to support the dmaengine_terminate_sync(). Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-02-11 11:08:42 +02:00
dmaengine: edma: Refactor the dma device and channel struct initialization Move all code under one function to do the dma device and eDMA channel related setup so they are not scattered around the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:05 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Refactor the dma device and channel struct initialization Move all code under one function to do the dma device and eDMA channel related setup so they are not scattered around the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:05 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Implement device_synchronize callback We need the callback to support the dmaengine_terminate_sync(). Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-02-11 11:08:42 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Refactor the dma device and channel struct initialization Move all code under one function to do the dma device and eDMA channel related setup so they are not scattered around the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:05 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Refactor the dma device and channel struct initialization Move all code under one function to do the dma device and eDMA channel related setup so they are not scattered around the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:05 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Get qDMA channel information from HW also Query the number of qDMA channels from CCCFG register. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:04 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Read channel mapping support only once from HW Instead of directly reading it from CCCFG register take the information out once when we set up the configuration from the HW. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:04 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Get qDMA channel information from HW also Query the number of qDMA channels from CCCFG register. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:04 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Read channel mapping support only once from HW Instead of directly reading it from CCCFG register take the information out once when we set up the configuration from the HW. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:04 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Use devm_kcalloc when possible When allocating a memory for number of items it is better (looks better) to use devm_kcalloc. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:55 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Use devm_kcalloc when possible When allocating a memory for number of items it is better (looks better) to use devm_kcalloc. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:55 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Merge the of parsing functions Instead of nesting functions just merge them since the resulting function is still small and readable. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:07 +03:00
dmaengine: edma: Use correct type for of_find_property() third parameter The correct type is int and not for the third parameter of of_find_property(). Fixes compilation for 64bit architectures (x86_64, aarch64). Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-21 15:41:29 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Merge the of parsing functions Instead of nesting functions just merge them since the resulting function is still small and readable. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:07 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type This change makes the DT file to be easier to read since the memcpy channels array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:10 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type This change makes the DT file to be easier to read since the memcpy channels array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:10 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type This change makes the DT file to be easier to read since the memcpy channels array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:10 +02:00
dmaengine: edma: Merge the of parsing functions Instead of nesting functions just merge them since the resulting function is still small and readable. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:07 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 10:18:11 +02:00
dmaengine: edma: Merge the of parsing functions Instead of nesting functions just merge them since the resulting function is still small and readable. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:07 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dma: remove use of __devinit CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Li Yang <leoli@freescale.com> Cc: Zhang Wei <zw@zh-kernel.org> Cc: Barry Song <baohua.song@csr.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-19 13:22:55 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Fix of_device_id data parameter usage (legacy vs TPCC) Use pointers to static constant variables for eDMA binding type (legacy vs TPCC). Fixes the following warning when compiling the driver for 64bit architectures (x86_64 for example): drivers/dma/edma.c:2185:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] if (match && (u32)match->data == EDMA_BINDING_TPCC) ^ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-21 15:41:28 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Cleanup regarding the use of dev around the code Be consistent and do not mix the use of dev, &pdev->dev, etc in the functions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:56 +03:00
DMA-API: dma: edma.c: no need to explicitly initialize DMA masks register_platform_device_full() can setup the DMA mask provided the appropriate member is set in struct platform_device_info. So lets make that be the case. This avoids a direct reference to the DMA masks by this driver. While here, add the dma_set_mask_and_coherent() call which the DMA API requires DMA-using drivers to call. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-27 13:45:16 +01:00
dmaengine: edma: Cleanup regarding the use of dev around the code Be consistent and do not mix the use of dev, &pdev->dev, etc in the functions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:56 +03:00
dmaengine: Remove site specific OOM error messages on kzalloc If kzalloc() fails it will issue it's own error message including a dump_stack(). So remove the site specific error messages. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-06-07 18:38:41 +01:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
ARM/dmaengine: edma: Public API to use private struct pointer Instead of relying on indexes pointing to edma private date in the global pointer array, pass the private data pointer via the public API. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:49 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers Since the driver stack no longer depends on lookup with id number in a global array of pointers, the limitation for the number of eDMAs are no longer needed. We can handle as many eDMAs in legacy and DT boot as we have memory for them to allocate the needed structures. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:50 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Allocate memory dynamically for bitmaps and structures Instead of using defines to specify the size of different arrays and bitmaps, allocate the memory for them based on the information we get from the HW itself. Since these defines are set based on the worst case, there are devices where they are not valid. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:54 +03:00
dmaengine: edma: Rename bitfields for slot and channel usage tracking The names chosen for the bitfields were quite confusing and given no real information on what they are used for... edma_inuse -> slot_inuse: tracks the slot usage/availability edma_unused -> channel_unused: tracks the channel usage/availability Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:05 +03:00
dmaengine: edma: Allocate memory dynamically for bitmaps and structures Instead of using defines to specify the size of different arrays and bitmaps, allocate the memory for them based on the information we get from the HW itself. Since these defines are set based on the worst case, there are devices where they are not valid. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:54 +03:00
dmaengine: edma: Rename bitfields for slot and channel usage tracking The names chosen for the bitfields were quite confusing and given no real information on what they are used for... edma_inuse -> slot_inuse: tracks the slot usage/availability edma_unused -> channel_unused: tracks the channel usage/availability Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:05 +03:00
dmaengine: edma: Allocate memory dynamically for bitmaps and structures Instead of using defines to specify the size of different arrays and bitmaps, allocate the memory for them based on the information we get from the HW itself. Since these defines are set based on the worst case, there are devices where they are not valid. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:54 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Rename set_bits and remove unused clear_bits helper The clear_bits() helper is not used by the driver so it can be removed. powerpc architecture defines the set_bits() in arch/powerpc/include/asm/bitops.h which results failed compile testing on powerpc architecture: >> drivers/dma/edma.c:415:20: error: conflicting types for 'set_bits' static inline void set_bits(int offset, int len, unsigned long *p) ^~~~~~~~ In file included from include/linux/bitops.h:36:0, from include/linux/kernel.h:10, from include/linux/list.h:8, from include/linux/kobject.h:20, from include/linux/device.h:17, from include/linux/dmaengine.h:20, from drivers/dma/edma.c:16: arch/powerpc/include/asm/bitops.h:75:14: note: previous definition of 'set_bits' was here DEFINE_BITOP(set_bits, or, "") ^ arch/powerpc/include/asm/bitops.h:58:24: note: in definition of macro 'DEFINE_BITOP' static __inline__ void fn(unsigned long mask, \ ^~ >> drivers/dma/edma.c:421:20: error: conflicting types for 'clear_bits' static inline void clear_bits(int offset, int len, unsigned long *p) ^~~~~~~~~~ In file included from include/linux/bitops.h:36:0, from include/linux/kernel.h:10, from include/linux/list.h:8, from include/linux/kobject.h:20, from include/linux/device.h:17, from include/linux/dmaengine.h:20, from drivers/dma/edma.c:16: arch/powerpc/include/asm/bitops.h:76:14: note: previous definition of 'clear_bits' was here DEFINE_BITOP(clear_bits, andc, "") ^ arch/powerpc/include/asm/bitops.h:58:24: note: in definition of macro 'DEFINE_BITOP' static __inline__ void fn(unsigned long mask, \ ^~ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-22 09:31:04 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: explicitly freeup irq dmaengine device should explicitly call devm_free_irq() when using devm_request_irq(). The irq is still ON when devices remove is executed and irq should be quiesced before remove is completed. Signed-off-by: Vinod Koul <vinod.koul@intel.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
2016-07-01 11:34:35 +05:30
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: explicitly freeup irq dmaengine device should explicitly call devm_free_irq() when using devm_request_irq(). The irq is still ON when devices remove is executed and irq should be quiesced before remove is completed. Signed-off-by: Vinod Koul <vinod.koul@intel.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
2016-07-01 11:34:35 +05:30
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Refactor the dma device and channel struct initialization Move all code under one function to do the dma device and eDMA channel related setup so they are not scattered around the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:05 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Merge map_dmach_to_queue into assign_channel_eventq edma_assign_channel_eventq() is a wrapper around edma_map_dmach_to_queue() We can merge the content of the later so we will have only one function to be used for mapping channels to given eventq Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:03 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Add support for DMA filter mapping to slave devices Add support for providing device to filter_fn mapping so client drivers can switch to use the dma_request_chan() API. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-14 22:47:41 +02:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine driver If the of_dma_controller is registered in the non dmaengine driver we could have race condition: the of_dma_controller has been registered, but the dmaengine driver is not yet probed. Drivers requesting DMA channels during this window will fail since we do not yet have dmaengine drivers registered. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:47 +03:00
dmaengine: edma: Cleanup regarding the use of dev around the code Be consistent and do not mix the use of dev, &pdev->dev, etc in the functions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:56 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: kill the tasklets upon exit drivers should ensure that tasklets are killed, so that they can't be executed after driver remove is executed, so ensure they are killed. This driver used vchan tasklets, so those need to be killed. Signed-off-by: Vinod Koul <vinod.koul@intel.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
2016-07-01 13:51:41 +05:30
Drivers: dma: remove __dev* attributes. 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 <wfp5p@virginia.edu> Cc: Viresh Kumar <viresh.linux@gmail.com> Cc: Dan Williams <djbw@fb.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Barry Song <baohua.song@csr.com> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Alexander Duyck <alexander.h.duyck@intel.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Jassi Brar <jassisinghbrar@gmail.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Bill Pemberton <wfp5p@virginia.edu> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-21 15:09:59 -08:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: explicitly freeup irq dmaengine device should explicitly call devm_free_irq() when using devm_request_irq(). The irq is still ON when devices remove is executed and irq should be quiesced before remove is completed. Signed-off-by: Vinod Koul <vinod.koul@intel.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
2016-07-01 11:34:35 +05:30
dmaengine: edma: kill the tasklets upon exit drivers should ensure that tasklets are killed, so that they can't be executed after driver remove is executed, so ensure they are killed. This driver used vchan tasklets, so those need to be killed. Signed-off-by: Vinod Koul <vinod.koul@intel.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
2016-07-01 13:51:41 +05:30
dmaengine: edma: Cleanup regarding the use of dev around the code Be consistent and do not mix the use of dev, &pdev->dev, etc in the functions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:56 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: edma: Remove dynamic TPTC power management feature The dynamic or on demand pm_runtime does not work correctly on am335x and am437x due to interference with hwmod. Fall back using the pm_runtime usage as it was in the old driver stack, meaning that at probe time call pm_runtime_enable() and pm_runtime_get_sync() for the TPTCs as well. Fixes: 1be5336bc7ba ("dmaengine: edma: New device tree binding") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-04-06 13:01:46 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: re-initialize dummy slot during system resume The last param set in a transfer should always be pointing to dummy param set in non-cyclic mode. When system wakes from low power state EDMA PARAM slots may be reset to random values. Hence, re-initialize dummy slot to dummy param set on system resume. Signed-off-by: Vignesh R <vigneshr@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-11-23 14:57:55 +05:30
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
dmaengine: edma: Dynamic paRAM slot handling if HW supports it If the eDMA3 has support for channel paRAM slot mapping we can utilize it to allocate slots on demand and save precious slots for real transfers. On am335x the eDMA has 64 channels which means we can unlock 64 paRAM slots out from the available 256. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:43:06 +03:00
dmaengine: edma: Simplify function parameter list for channel operations Instead of passing a pointer to struct edma_cc and the channel number, pass only the pointer to the edma_chan structure for the given channel. This struct contains all the information needed by the functions and the use of this makes it obvious that most of the sanity checks can be removed from the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:01 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dma: remove use of __devexit_p CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Acked-by: Barry Song <baohua.song@csr.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-19 13:20:04 -05:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ Move the code out from arch/arm/common and merge it inside of the dmaengine driver. This change is done with as minimal (if eny) functional change to the code as possible to avoid introducing regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 14:42:53 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Add probe callback to edma_tptc_driver Due to changes in device and platform code drivers w/o probe will fail to load. This means that the devices for eDMA TPTCs are goign to be without driver and omap hwmod code will turn them off after the kernel finished loading: [ 3.015900] platform 49800000.tptc: omap_device_late_idle: enabled but no driver. Idling [ 3.024671] platform 49a00000.tptc: omap_device_late_idle: enabled but no driver. Idling This will prevent eDMA to work since the TPTCs are not enabled. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Fixes: 34635b1accb9 ("dmaengine: edma: Add dummy driver skeleton for edma3-tptc") Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-16 15:19:05 +02:00
dmaengine: edma: Remove dynamic TPTC power management feature The dynamic or on demand pm_runtime does not work correctly on am335x and am437x due to interference with hwmod. Fall back using the pm_runtime usage as it was in the old driver stack, meaning that at probe time call pm_runtime_enable() and pm_runtime_get_sync() for the TPTCs as well. Fixes: 1be5336bc7ba ("dmaengine: edma: New device tree binding") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-04-06 13:01:46 +03:00
dmaengine: edma: Add probe callback to edma_tptc_driver Due to changes in device and platform code drivers w/o probe will fail to load. This means that the devices for eDMA TPTCs are goign to be without driver and omap hwmod code will turn them off after the kernel finished loading: [ 3.015900] platform 49800000.tptc: omap_device_late_idle: enabled but no driver. Idling [ 3.024671] platform 49a00000.tptc: omap_device_late_idle: enabled but no driver. Idling This will prevent eDMA to work since the TPTCs are not enabled. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Fixes: 34635b1accb9 ("dmaengine: edma: Add dummy driver skeleton for edma3-tptc") Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-16 15:19:05 +02:00
dmaengine: edma: Add dummy driver skeleton for edma3-tptc The eDMA3 TPTC does not need any software configuration, but it is a separate IP block in the SoC. In order the omap hwmod core to be able to handle the TPTC resources correctly in regards of PM we need to have a driver loaded for it. This patch will add a dummy driver skeleton without probe or remove callbacks provided. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-11-02 15:21:40 +02:00
dmaengine: edma: Add probe callback to edma_tptc_driver Due to changes in device and platform code drivers w/o probe will fail to load. This means that the devices for eDMA TPTCs are goign to be without driver and omap hwmod code will turn them off after the kernel finished loading: [ 3.015900] platform 49800000.tptc: omap_device_late_idle: enabled but no driver. Idling [ 3.024671] platform 49a00000.tptc: omap_device_late_idle: enabled but no driver. Idling This will prevent eDMA to work since the TPTCs are not enabled. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Fixes: 34635b1accb9 ("dmaengine: edma: Add dummy driver skeleton for edma3-tptc") Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-16 15:19:05 +02:00
dmaengine: edma: Add dummy driver skeleton for edma3-tptc The eDMA3 TPTC does not need any software configuration, but it is a separate IP block in the SoC. In order the omap hwmod core to be able to handle the TPTC resources correctly in regards of PM we need to have a driver loaded for it. This patch will add a dummy driver skeleton without probe or remove callbacks provided. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-11-02 15:21:40 +02:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 10:18:10 +03:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Add dummy driver skeleton for edma3-tptc The eDMA3 TPTC does not need any software configuration, but it is a separate IP block in the SoC. In order the omap hwmod core to be able to handle the TPTC resources correctly in regards of PM we need to have a driver loaded for it. This patch will add a dummy driver skeleton without probe or remove callbacks provided. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-11-02 15:21:40 +02:00
dma: edma: move device registration to platform code 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-24 18:14:01 +02:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
dmaengine: edma: Add dummy driver skeleton for edma3-tptc The eDMA3 TPTC does not need any software configuration, but it is a separate IP block in the SoC. In order the omap hwmod core to be able to handle the TPTC resources correctly in regards of PM we need to have a driver loaded for it. This patch will add a dummy driver skeleton without probe or remove callbacks provided. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-11-02 15:21:40 +02:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00
edma: Update author email address Matt's @ti.com address bounces. Update the MODULE_AUTHOR information in edma.c to his Linaro address. Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Acked-by: Matt Porter <matt.porter@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-09-04 10:32:50 -04:00
dmaengine: add TI EDMA DMA engine driver Add a DMA engine driver for the TI EDMA controller. This driver is implemented as a wrapper around the existing DaVinci private DMA implementation. This approach allows for incremental conversion of each peripheral driver to the DMA engine API. The EDMA driver supports slave transfers but does not yet support cyclic transfers. Signed-off-by: Matt Porter <mporter@ti.com> Tested-by: Tom Rini <trini@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-08-22 21:09:34 -04:00