- 27 Oct, 2015 12 commits
-
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
Since the crossbar is needed for eDMA when it is used on OMAP like platforms (am335x/am437x and later DRA7xx), select the crossbar to be built if ARCH_OMAP is set. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Peter Ujfalusi authored
The DMA event crossbar on AM33xx/AM43xx is different from the one found in DRA7x family. Instead of a single event crossbar it has 64 identical mux attached to each eDMA event line. When the 0 event mux is selected, the default mapped event is going to be routed to the corresponding eDMA event line. If different mux is selected, then the selected event is going to be routed to the given eDMA event. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
The channel/slot reservation is not supported when booted with DT so there is not need to allocate memory. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
- 14 Oct, 2015 24 commits
-
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
edma_write_slot() is for writing an entire paRAM slot. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
The upcoming change to merge the arch/arm/common/edma.c into drivers/dma/edma.c will need this change when booting daVinci devices in no DT mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Peter Ujfalusi authored
Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
Merge the iomem into the 'struct edma' and change the internal (static) functions to use pointer to the edma_cc instead of the ctlr number. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Peter Ujfalusi authored
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>
-
Peter Ujfalusi authored
We no longer have users for these functions so they can be removed. Remove also unused enums from the header file. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Peter Ujfalusi authored
In case when the interrupt happened for the second eDMA the channel number was incorrectly passed to the client driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: <stable@vger.kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
- 12 Sep, 2015 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/crisLinus Torvalds authored
Pull CRIS updates from Jesper Nilsson: "Mostly removal of old cruft of which we can use a generic version, or fixes for code not commonly run in the cris port, but also additions to enable some good debug" * tag 'cris-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris: (25 commits) CRISv10: delete unused lib/dmacopy.c CRISv10: delete unused lib/old_checksum.c CRIS: fix switch_mm() lockdep splat CRISv32: enable LOCKDEP_SUPPORT CRIS: add STACKTRACE_SUPPORT CRISv32: annotate irq enable in idle loop CRISv32: add support for irqflags tracing CRIS: UAPI: use generic types.h CRIS: UAPI: use generic shmbuf.h CRIS: UAPI: use generic msgbuf.h CRIS: UAPI: use generic socket.h CRIS: UAPI: use generic sembuf.h CRIS: UAPI: use generic sockios.h CRIS: UAPI: use generic auxvec.h CRIS: UAPI: use generic headers via Kbuild CRIS: UAPI: fix elf.h export CRIS: don't make asm/elf.h depend on asm/user.h CRIS: UAPI: fix ptrace.h CRISv32: Squash compile warnings for axisflashmap CRISv32: Add GPIO driver to the default configs ...
-
Linus Torvalds authored
rq_data_dir() returns either READ or WRITE (0 == READ, 1 == WRITE), not a boolean value. Now, admittedly the "!= 0" doesn't really change the value (0 stays as zero, 1 stays as one), but it's not only redundant, it confuses gcc, and causes gcc to warn about the construct switch (rq_data_dir(req)) { case READ: ... case WRITE: ... that we have in a few drivers. Now, the gcc warning is silly and stupid (it seems to warn not about the switch value having a different type from the case statements, but about _any_ boolean switch value), but in this case the code itself is silly and stupid too, so let's just change it, and get rid of warnings like this: drivers/block/hd.c: In function ‘hd_request’: drivers/block/hd.c:630:11: warning: switch condition has boolean value [-Wswitch-bool] switch (rq_data_dir(req)) { The odd '!= 0' came in when "cmd_flags" got turned into a "u64" in commit 5953316d ("block: make rq->cmd_flags be 64-bit") and is presumably because the old code (that just did a logical 'and' with 1) would then end up making the type of rq_data_dir() be u64 too. But if we want to retain the old regular integer type, let's just cast the result to 'int' rather than use that rather odd '!= 0'. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Fix up the writeback plugging introduced in commit d353d758 ("writeback: plug writeback at a high level") that then caused problems due to the unplug happening with a spinlock held. * writeback-plugging: writeback: plug writeback in wb_writeback() and writeback_inodes_wb() Revert "writeback: plug writeback at a high level"
-