summaryrefslogtreecommitdiffstats
path: root/drivers/dma/dw (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'for-linus' into fixesVinod Koul2020-08-056-4/+64
|\ | | | | | | | | | | | | Signed-off-by: Vinod Koul <vkoul@kernel.org> Conflicts: drivers/dma/idxd/sysfs.c
| * dmaengine: dw: Initialize max_sg_burst capabilitySerge Semin2020-07-271-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Multi-block support provides a way to map the kernel-specific SG-table so the DW DMA device would handle it as a whole instead of handling the SG-list items or so called LLP block items one by one. So if true LLP list isn't supported by the DW DMA engine, then soft-LLP mode will be utilized to load and execute each LLP-block one by one. The soft-LLP mode of the DMA transactions execution might not work well for some DMA consumers like SPI due to its Tx and Rx buffers inter-dependency. Let's initialize the max_sg_burst DMA channels capability based on the nollp flag state. If it's true, no hardware accelerated LLP is available and max_sg_burst should be set with 1, which means that the DMA engine can handle only a single SG list entry at a time. If noLLP is set to false, then hardware accelerated LLP is supported and the DMA engine can handle infinite number of SG entries in a single DMA transaction. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200723005848.31907-11-Sergey.Semin@baikalelectronics.ru Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Introduce max burst length hw configSerge Semin2020-07-273-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IP core of the DW DMA controller may be synthesized with different max burst length of the transfers per each channel. According to Synopsis having the fixed maximum burst transactions length may provide some performance gain. At the same time setting up the source and destination multi size exceeding the max burst length limitation may cause a serious problems. In our case the DMA transaction just hangs up. In order to fix this lets introduce the max burst length platform config of the DW DMA controller device and don't let the DMA channels configuration code exceed the burst length hardware limitation. Note the maximum burst length parameter can be detected either in runtime from the DWC parameter registers or from the dedicated DT property. Depending on the IP core configuration the maximum value can vary from channel to channel so by overriding the channel slave max_burst capability we make sure a DMA consumer will get the channel-specific max burst length. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200723005848.31907-10-Sergey.Semin@baikalelectronics.ru Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Initialize min and max burst DMA device capabilitySerge Semin2020-07-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the DW APB DMAC data book the minimum burst transaction length is 1 and it's true for any version of the controller since isn't parametrised in the coreAssembler so can't be changed at the IP-core synthesis stage. The maximum burst transaction can vary from channel to channel and from controller to controller depending on a IP-core parameter the system engineer activated during the IP-core synthesis. Let's initialise both min_burst and max_burst members of the DMA controller descriptor with extreme values so the DMA clients could use them to properly optimize the DMA requests. The channels and controller-specific max_burst length initialization will be introduced by the follow-up patches. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200723005848.31907-9-Sergey.Semin@baikalelectronics.ru Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Set DMA device max segment size parameterSerge Semin2020-07-271-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Maximum block size DW DMAC configuration corresponds to the max segment size DMA parameter in the DMA core subsystem notation. Lets set it with a value specific to the probed DW DMA controller. It shall help the DMA clients to create size-optimized SG-list items for the controller. This in turn will cause less dw_desc allocations, less LLP reinitializations, better DMA device performance. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200723005848.31907-8-Sergey.Semin@baikalelectronics.ru Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Take HC_LLP flag into account for noLLP auto-configSerge Semin2020-07-272-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Full multi-block transfers functionality is enabled in DW DMA controller only if CHx_MULTI_BLK_EN is set. But LLP-based transfers can be executed only if hardcode channel x LLP register feature isn't enabled, which can be switched on at the IP core synthesis for optimization. If it's enabled then the LLP register is hardcoded to zero, so the blocks chaining based on the LLPs is unsupported. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200723005848.31907-7-Sergey.Semin@baikalelectronics.ru Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Replace 'objs' by 'y'Andy Shevchenko2020-06-161-2/+2
| | | | | | | | | | | | | | | | | | `-objs` is fitted for building host programs, change to `-y`, more straightforward for device drivers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200526182416.52805-2-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Register ACPI DMA controller for PCI that has companionAndy Shevchenko2020-06-163-1/+7
| | | | | | | | | | | | | | | | | | | | | | If PCI enumerated controller has a companion device, register it in the ACPI DMA controllers as well. Fixes: f7c799e950f9 ("dmaengine: dw: we do support Merrifield SoC in PCI mode") Depends-on: b685fe26e9af ("dmaengine: dw: platform: Split ACPI helpers to separate module") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200526182416.52805-1-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* | dmaengine: dw: Initialize channel before each transferAndy Shevchenko2020-07-061-12/+0
|/ | | | | | | | | | | | | | | | In some cases DMA can be used only with a consumer which does runtime power management and on the platforms, that have DMA auto power gating logic (see comments in the drivers/acpi/acpi_lpss.c), may result in DMA losing its context. Simple mitigation of this issue is to initialize channel each time the consumer initiates a transfer. Fixes: cfdf5b6cc598 ("dw_dmac: add support for Lynxpoint DMA controllers") Reported-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206403 Link: https://lore.kernel.org/r/20200705115620.51929-1-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: platform: Mark 'hclk' clock optionalAndy Shevchenko2019-10-141-1/+1
| | | | | | | | | | | | | | On some platforms the clock can be fixed rate, always running one and there is no need to do anything with it. In order to support those platforms, switch to use optional clock. Fixes: f8d9ddbc2851 ("dmaengine: dw: platform: Enable iDMA 32-bit on Intel Elkhart Lake") Depends-on: 60b8f0ddf1a9 ("clk: Add (devm_)clk_get_optional() functions") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20190924085116.83683-1-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: platform: Split OF helpers to separate moduleAndy Shevchenko2019-08-214-113/+149
| | | | | | | | For better maintenance split OF helpers to the separate module. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190820131546.75744-11-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: platform: Split ACPI helpers to separate moduleAndy Shevchenko2019-08-214-53/+63
| | | | | | | | For better maintenance split ACPI helpers to the separate module. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190820131546.75744-10-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: platform: Move handle check to dw_dma_acpi_controller_register()Andy Shevchenko2019-08-211-4/+8
| | | | | | | | | | Move ACPI handle check to the dw_dma_acpi_controller_register(). While here, convert it to has_acpi_companion() which is recommended way. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190820131546.75744-9-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: platform: Switch to acpi_dma_controller_register()Andy Shevchenko2019-08-211-2/+12
| | | | | | | | | | | | | There is a possibility to have registered ACPI DMA controller while it has been gone already. To avoid the potential crash, move to non-managed acpi_dma_controller_register(). Fixes: 42c91ee71d6d ("dw_dmac: add ACPI support") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190820131546.75744-8-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: platform: Use devm_platform_ioremap_resource()Andy Shevchenko2019-08-211-3/+1
| | | | | | | | | Use the new helper that wraps the calls to platform_get_resource() and devm_ioremap_resource() together. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190820131546.75744-7-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: platform: Enable iDMA 32-bit on Intel Elkhart LakeAndy Shevchenko2019-08-211-5/+11
| | | | | | | | | Intel® PSE (Programmable Services Engine) provides few DMA controllers to the host on Intel Elkhart Lake. Enable them in the ACPI glue driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190820131546.75744-6-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: platform: Use struct dw_dma_chip_pdataAndy Shevchenko2019-08-211-11/+31
| | | | | | | | | Now, when we have a generic structure for the chip and platform data, use it in the platform glue driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190820131546.75744-5-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: Export struct dw_dma_chip_pdata for wider useAndy Shevchenko2019-08-212-44/+44
| | | | | | | | | | We are expecting some devices can be enumerated either as PCI or ACPI. Nevertheless, they will share same information, thus, provide a generic struct dw_dma_chip_pdata for all glue drivers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190820131546.75744-4-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: Update Intel Elkhart Lake Service Engine acronymJarkko Nikula2019-08-201-1/+1
| | | | | | | | | | | | | Intel Elkhart Lake Offload Service Engine (OSE) will be called as Intel(R) Programmable Services Engine (Intel(R) PSE) in documentation. Update the comment here accordingly. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20190813080602.15376-1-jarkko.nikula@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: Enable iDMA 32-bit on Intel Elkhart LakeAndy Shevchenko2019-06-251-0/+5
| | | | | | | | | Intel Elkhart Lake OSE (Offload Service Engine) provides few DMA controllers to the host. Enable them in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: Distinguish ->remove() between DW and iDMA 32-bitAndy Shevchenko2019-06-251-8/+20
| | | | | | | | | | | | In the same way as done for ->probe(), call ->remove() based on the type of the hardware. While it works now due to equivalency of the two removal functions, it might be changed in the future. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org>
* Merge branch 'topic/dw' into for-linusVinod Koul2019-03-129-247/+419
|\
| * dmaengine: dw: convert to SPDX identifiersAndy Shevchenko2019-01-076-20/+7
| | | | | | | | | | | | | | | | This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Don't pollute CTL_LO on iDMA 32-bitAndy Shevchenko2019-01-074-26/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | Intel iDMA 32-bit doesn't have a concept of bus masters and thus there is no need to setup any kind of masters in the CTL_LO register. Moreover, the burst size for memory-to-memory transfer is not what is says, we need to have a corrected list of possible sizes. Note, that the size of 8 items, each of that up to 4 bytes, is chosen because of maximum of 1/2 FIFO, which is 64 bytes on Intel Merrifield. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Reset DRAIN bit when resume the channelAndy Shevchenko2019-01-074-7/+25
| | | | | | | | | | | | | | | | For Intel iDMA 32-bit the channel can be drained on a suspend. We need to reset the bit on the resume to return a status quo. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Split DW and iDMA 32-bit operationsAndy Shevchenko2019-01-078-179/+339
| | | | | | | | | | | | | | | | | | | | | | | | | | Here is a kinda big refactoring that should have been done in the first place, when Intel iDMA 32-bit support appeared. It splits operations which are different to Synopsys DesignWare and Intel iDMA 32-bit controllers. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Remove unused internal propertyAndy Shevchenko2019-01-073-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | All known devices, which use DT for configuration, support memory-to-memory transfers. So enable it by default. The rest two cases, i.e. Intel Quark and PPC460ex, instantiate DMA driver and use its channels exclusively for hardware, which means there is no available channel for any other purposes anyway. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Remove misleading is_private propertyAndy Shevchenko2019-01-073-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit a9ddb575d6d6 ("dmaengine: dw_dmac: Enhance device tree support") introduces is_private property in uncertain understanding what does it mean. First of all, documentation defines DMA_PRIVATE capability as Documentation/crypto/async-tx-api.txt: The DMA_PRIVATE capability flag is used to tag dma devices that should not be used by the general-purpose allocator. It can be set at initialization time if it is known that a channel will always be private. Alternatively, it is set when dma_request_channel() finds an unused "public" channel. A couple caveats to note when implementing a driver and consumer: 1/ Once a channel has been privately allocated it will no longer be considered by the general-purpose allocator even after a call to dma_release_channel(). 2/ Since capabilities are specified at the device level a dma_device with multiple channels will either have all channels public, or all channels private. Documentation/driver-api/dmaengine/provider.rst: - DMA_PRIVATE The devices only supports slave transfers, and as such isn't available for async transfers. The capability had been introduced by the commit 59b5ec21446b ("dmaengine: introduce dma_request_channel and private channels") and some code didn't changed from that times ever. Taking into consideration above and the fact that on all known platforms Synopsys DesignWare DMA engine is attached to serve slave transfers, the DMA_PRIVATE capability must be enabled for this device unconditionally. Otherwise, as rightfully noticed in drivers/dma/at_xdmac.c: /* * Without DMA_PRIVATE the driver is not able to allocate more than * one channel, second allocation fails in private_candidate. */ because of of a caveats mentioned in above documentation excerpts. So, remove conditional around DMA_PRIVATE followed by removal leftovers. If someone wonders, DMA_PRIVATE can be not used if and only if the all channels of the DMA controller are supposed to serve memory-to-memory like operations. For example, EP93xx has two controllers, one of which can only perform memory-to-memory transfers Note, this change doesn't affect dmatest to be able to test such controllers. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (maintainer:SERIAL DRIVERS) Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * dmaengine: dw: Add missed multi-block support for iDMA 32-bitAndy Shevchenko2019-01-071-0/+1
| | | | | | | | | | | | | | | | Intel integrated DMA 32-bit support multi-block transfers. Add missed setting to the platform data. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
* | dmaengine: dw: drop useless LIST_HEADJulia Lawall2019-01-071-1/+0
|/ | | | | | | | | | | | | | | | | | | | | | Drop LIST_HEAD where the variable it declares is never used. Commit ab703f818ac3 ("dmaengine: dw: lazy allocation of dma descriptors") removed the uses, but not the declaration. The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier x; @@ - LIST_HEAD(x); ... when != x // </smpl> Fixes: ab703f818ac3 ("dmaengine: dw: lazy allocation of dma descriptors") Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Vinod Koul <vkoul@kernel.org>
* Merge tag 'dmaengine-4.21-rc1' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds2019-01-023-0/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull dmaengine updates from Vinod Koul: "This includes a new driver, removes R-Mobile APE6 as it is no longer used, sprd cyclic dma support, last batch of dma_slave_config direction removal and random updates to bunch of drivers. Summary: - New driver for UniPhier MIO DMA controller - Remove R-Mobile APE6 support - Sprd driver updates and support for cyclic link-list - Remove dma_slave_config direction usage from rest of drivers - Minor updates to dmatest, dw-dmac, zynqmp and bcm dma drivers" * tag 'dmaengine-4.21-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (48 commits) dmaengine: qcom_hidma: convert to DEFINE_SHOW_ATTRIBUTE dmaengine: pxa: remove DBGFS_FUNC_DECL() dmaengine: mic_x100_dma: convert to DEFINE_SHOW_ATTRIBUTE dmaengine: amba-pl08x: convert to DEFINE_SHOW_ATTRIBUTE dmaengine: Documentation: Add documentation for multi chan testing dmaengine: dmatest: Add transfer_size parameter dmaengine: dmatest: Add alignment parameter dmaengine: dmatest: Use fixed point div to calculate iops dmaengine: dmatest: Add support for multi channel testing dmaengine: rcar-dmac: Document R8A774C0 bindings dt-bindings: dmaengine: usb-dmac: Add binding for r8a774c0 dmaengine: zynqmp_dma: replace spin_lock_bh with spin_lock_irqsave dmaengine: sprd: Add me as one of the module authors dmaengine: sprd: Support DMA 2-stage transfer mode dmaengine: sprd: Support DMA link-list cyclic callback dmaengine: sprd: Set cur_desc as NULL when free or terminate one dma channel dmaengine: sprd: Fix the last link-list configuration dmaengine: sprd: Get transfer residue depending on the transfer direction dmaengine: sprd: Remove direction usage from struct dma_slave_config dmaengine: dmatest: fix a small memory leak in dmatest_func() ...
| * dmaengine: dw-dmac: implement dma protection control settingChristian Lamparter2018-11-243-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new device-tree property that allows to specify the dma protection control bits for the all of the DMA controller's channel uniformly. Setting the "correct" bits can have a huge impact on the PPC460EX and APM82181 that use this DMA engine in combination with a DesignWare' SATA-II core (sata_dwc_460ex driver). In the OpenWrt Forum, the user takimata reported that: |It seems your patch unleashed the full power of the SATA port. |Where I was previously hitting a really hard limit at around |82 MB/s for reading and 27 MB/s for writing, I am now getting this: | |root@OpenWrt:/mnt# time dd if=/dev/zero of=tempfile bs=1M count=1024 |1024+0 records in |1024+0 records out |real 0m 13.65s |user 0m 0.01s |sys 0m 11.89s | |root@OpenWrt:/mnt# time dd if=tempfile of=/dev/null bs=1M count=1024 |1024+0 records in |1024+0 records out |real 0m 8.41s |user 0m 0.01s |sys 0m 4.70s | |This means: 121 MB/s reading and 75 MB/s writing! | |The drive is a WD Green WD10EARX taken from an older MBL Single. |I repeated the test a few times with even larger files to rule out |any caching, I'm still seeing the same great performance. OpenWrt is |now completely on par with the original MBL firmware's performance. Another user And.short reported: |I can report that your fix worked! Boots up fine with two |drives even with more partitions, and no more reboot on |concurrent disk access! A closer look into the sata_dwc_460ex code revealed that the driver did initally set the correct protection control bits. However, this feature was lost when the sata_dwc_460ex driver was converted to the generic DMA driver framework. BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/55 BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/50 Fixes: 8b3444852a2b ("sata_dwc_460ex: move to generic DMA driver") Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
* | dmaengine: dw: Fix FIFO size for Intel MerrifieldAndy Shevchenko2018-12-061-3/+3
|/ | | | | | | | | | | | | | | Intel Merrifield has a reduced size of FIFO used in iDMA 32-bit controller, i.e. 512 bytes instead of 1024. Fix this by partitioning it as 64 bytes per channel. Note, in the future we might switch to 'fifo-size' property instead of hard coded value. Fixes: 199244d69458 ("dmaengine: dw: add support of iDMA 32-bit hardware") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
* Merge branch 'topic/dw' into for-linusVinod Koul2018-10-241-0/+2
|\
| * dmaengine: dw: Add alternative ACPI HIDs for Cherry Trail DMA controllersHans de Goede2018-08-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bay and Cherry Trail DSTDs represent a different set of devices depending on which OS the device think it is booting. One set of decices for Windows and another set of devices for Android which targets the Android-x86 Linux kernel fork (which e.g. used to have its own display driver instead of using the i915 driver). Which set of devices we are actually going to get is out of our control, this is controlled by the ACPI OSID variable, which gets either set through an EFI setup option, or sometimes is autodetected. So we need to support both. This commit adds support for the 80862286 and 808622C0 ACPI HIDs which we get for the first resp. second DMA controller on Cherry Trail devices when OSID is set to Android. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
* | dmaengine: dw: remove dma_slave_config direction usageVinod Koul2018-10-071-5/+0
|/ | | | | | | | | dma_slave_config direction was marked as deprecated quite some time back, remove the usage from this driver so that the field can be removed Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
* dmaengine: dw: simplify getting .drvdataWolfram Sang2018-04-221-4/+2
| | | | | | | | | We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org>
* License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman2017-11-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* dmaengine: DW DMAC: Handle return value of clk_prepare_enableArvind Yadav2017-05-241-1/+5
| | | | | | | | | clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
* dmaengine: dw: Remove AVR32 bits from the driverAndy Shevchenko2017-05-153-375/+14
| | | | | | | | | AVR32 is gone. Now it's time to clean up the driver by removing leftovers that was used by AVR32 related code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge tag 'dmaengine-4.11-rc1' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds2017-02-224-67/+223
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull dmaengine updates from Vinod Koul: "This time we fairly boring and bit small update. - Support for Intel iDMA 32-bit hardware - deprecate broken support for channel switching in async_tx - bunch of updates on stm32-dma - Cyclic support for zx dma and making in generic zx dma driver - Small updates to bunch of other drivers" * tag 'dmaengine-4.11-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (29 commits) async_tx: deprecate broken support for channel switching dmaengine: rcar-dmac: Widen DMA mask to 40 bits dmaengine: sun6i: allow build on ARM64 platforms (sun50i) dmaengine: Provide a wrapper for memcpy operations dmaengine: zx: fix build warning dmaengine: dw: we do support Merrifield SoC in PCI mode dmaengine: dw: add support of iDMA 32-bit hardware dmaengine: dw: introduce register mappings for iDMA 32-bit dmaengine: dw: introduce block2bytes() and bytes2block() dmaengine: dw: extract dwc_chan_pause() for future use dmaengine: dw: replace convert_burst() with one liner dmaengine: dw: register IRQ and DMA pool with instance ID dmaengine: dw: Fix data corruption in large device to memory transfers dmaengine: ste_dma40: indicate granularity on channels dmaengine: ste_dma40: indicate directions on channels dmaengine: stm32-dma: Add error messages if xlate fails dmaengine: dw: pci: remove LPE Audio DMA ID dmaengine: stm32-dma: Add max_burst support dmaengine: stm32-dma: Add synchronization support dmaengine: stm32-dma: Fix residue computation issue in cyclic mode ...
| * dmaengine: dw: we do support Merrifield SoC in PCI modeAndy Shevchenko2017-01-251-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Intel Merrifield platform contains Intel integrated DMA (iDMA 32-bit) which has a slightly different register mapping, e.g. some bits in CTL_* and CFG_* channel registers, and has to use platform data since there is no autoconfiguration. The iDMA 32-bit specification is available in the publicly available documentation for Intel Braswell and BayTrail SoCs as LPE Audio DMA. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
| * dmaengine: dw: add support of iDMA 32-bit hardwareAndy Shevchenko2017-01-251-9/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | iDMA 32-bit is Intel designed DMA controller that behaves like Synopsys Designware DMA. This patch adds a support of the new Intel hardware. Due to iDMA 32-bit has no autoconfiguration the platform code must provide a platform data to dw_dma_probe(). By default full FIFO (1024 bytes) is assigned to channel 0. Here we slice FIFO on equal parts between channels for iDMA 32-bit case. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
| * dmaengine: dw: introduce register mappings for iDMA 32-bitAndy Shevchenko2017-01-251-3/+49
| | | | | | | | | | | | | | | | | | The integrated DMA (iDMA 32-bit) is Intel designed DMA controller which mimics Synopsys Designware DMA. This patch appends the register mappings for the parts which are slightly different to the DesignWare hardware. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
| * dmaengine: dw: introduce block2bytes() and bytes2block()Andy Shevchenko2017-01-252-23/+35
| | | | | | | | | | | | | | | | | | | | The newly introduced helpers prepare driver to support new DMA controller hardware. While here, introduce DWC_CTLH_BLOCK_TS() macro as well. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
| * dmaengine: dw: extract dwc_chan_pause() for future useAndy Shevchenko2017-01-251-5/+9
| | | | | | | | | | | | | | | | iDMA 32-bit has a special handling of the FIFO during pause() / terminate_all(). Prepare code to implement that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
| * dmaengine: dw: replace convert_burst() with one linerAndy Shevchenko2017-01-251-18/+11
| | | | | | | | | | | | | | | | | | | | Replace convert_burst() with one liner in place. The change simplifies further extension of the driver to cover new DMA controller hardware. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
| * dmaengine: dw: register IRQ and DMA pool with instance IDAndy Shevchenko2017-01-254-2/+8
| | | | | | | | | | | | | | | | | | | | | | It is really useful not only for debugging to have an IRQ line and DMA pool labeled with driver and its instance ID. Do this for DesignWare DMA driver. All current users of this IP would be enhanced later on. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
| * dmaengine: dw: Fix data corruption in large device to memory transfersJarkko Nikula2017-01-251-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When transferring more data than the maximum block size supported by the HW multiplied by source width the transfer is split into smaller chunks. Currently code calculates the memory width and thus aligment before splitting for both memory to device and device to memory transfers. For memory to device transfers this work fine since alignment is preserved through the splitting and split blocks are still memory width aligned. However in device to memory transfers aligment breaks when maximum block size multiplied by register width doesn't have the same alignment than the buffer. For instance when transferring from an 8-bit register 4100 bytes (32-bit aligned) on a DW DMA that has maximum block size of 4095 elements. An attempt to do such transfers caused data corruption. Fix this by calculating and setting the destination memory width after splitting by using the split block aligment and length. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
| * dmaengine: dw: pci: remove LPE Audio DMA IDAndy Shevchenko2017-01-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | LPE Audio driver should take care of DMA IPs by itself. Keeping an ID like this in dw_dma_pci.c is anyway wrong since that block has two DMA controllers under one ID (like MFD device). That's also why I didn't include LPE Audio ID for Intel Merrifield previously. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 20:42:02 +0100