linux-toradex.git/drivers/dma/dw-edma, branch v6.3-rc5

dmaengine: dw-edma: Depend on DW_EDMA instead of selecting it

2023-02-22T19:46:04+00:00

Kconfig "select" is discouraged for visible symbols like DW_EDMA because it
makes it possible to set DW_EDMA even if DW_EDMA depends on things that are
not set (see Documentation/kbuild/kconfig-language.txt).

Convert DW_EDMA_PCIE so it depends on DW_EDMA instead of selecting it.

There will likely be several future drivers that depend on DW_EDMA, so this
uses "if DW_EDMA" to enclose them all rather than repeating "depends on
DW_EDMA" for each.

[bhelgaas: split to separate patch, commit log]
Link: https://lore.kernel.org/r/20230113171409.30470-25-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Serge Semin 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Acked-by: Vinod Koul

dmaengine: dw-edma: Add mem-mapped LL-entries support

2023-02-22T19:45:53+00:00

Currently the DW eDMA driver only supports the linked lists memory
allocated locally with respect to the remote eDMA engine setup. It means
the linked lists will be accessible by the CPU via the MMIO space only. If
eDMA is embedded into the DW PCIe Root Ports or local Endpoints (which
support will be added in subsequent commits) the linked lists are supposed
to be allocated in the CPU memory. In that case the LL-entries can be
directly accessed, while the former case implies using the MMIO accessors
for that.

In order to have both cases supported by the driver, the dw_edma_region
descriptor should be fixed to contain the MMIO-backed and just memory-based
virtual addresses. The linked lists initialization procedure will use one
of them depending on the eDMA device nature. If the eDMA engine is embedded
into the local DW PCIe Root Port/Endpoint controllers, the list entries
will be directly accessed by referencing the corresponding structure
fields.  Otherwise the MMIO accessors usage will be preserved.

Link: https://lore.kernel.org/r/20230113171409.30470-24-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Serge Semin 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Acked-by: Vinod Koul

dmaengine: dw-edma: Skip cleanup procedure if no private data found

2023-02-10T23:15:23+00:00

DW eDMA driver private data is preserved in the passed DW eDMA chip info
structure. If the probe fails or for some reason the passed info object
doesn't have the private data pointer initialized, halt the DMA device
cleanup procedure to prevent system crashes.

Link: https://lore.kernel.org/r/20230113171409.30470-23-Sergey.Semin@baikalelectronics.ru
Tested-by: Manivannan Sadhasivam 
Signed-off-by: Serge Semin 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Acked-by: Vinod Koul

dmaengine: dw-edma: Replace chip ID number with device name

2023-02-10T23:15:23+00:00

Using an abstract number as the DW eDMA chip identifier isn't practical
because there can be more than one DW eDMA controller on the platform. Some
may be detected as the PCIe Endpoints, and others may be embedded in DW
PCIe Root Port/Endpoint controllers.  An abstract number in, for instance,
the IRQ handlers list, doesn't give a notion regarding their reference to
the particular DMA controller.

To preserve the code simplicity and support multi-eDMA platforms, use the
parental device name to create the DW eDMA controller name.

Link: https://lore.kernel.org/r/20230113171409.30470-22-Sergey.Semin@baikalelectronics.ru
Tested-by: Manivannan Sadhasivam 
Signed-off-by: Serge Semin 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Acked-by: Vinod Koul

dmaengine: dw-edma: Drop DT-region allocation

2023-02-10T23:15:23+00:00

There is no point in allocating additional memory for the data target
regions passed to the client drivers. Use the already available structures
defined in the dw_edma_chip instance.

Note: these regions are unused in normal circumstances since they are
specific to the case of eDMA being embedded into the DW PCIe Endpoint and
having its CSRs accessible via an Endpoint BAR. This case is only known to
be implemented as a part of the Synopsys PCIe Endpoint IP prototype kit.

Link: https://lore.kernel.org/r/20230113171409.30470-21-Sergey.Semin@baikalelectronics.ru
Tested-by: Manivannan Sadhasivam 
Signed-off-by: Serge Semin 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Acked-by: Vinod Koul

dmaengine: dw-edma: Use non-atomic io-64 methods

2023-02-10T23:15:23+00:00

Instead of splitting 64-bits IOs up into two 32-bits ones, use the existing
non-atomic readq()/writeq() functions. By doing so we can discard
CONFIG_64BIT #ifdefs from the code.

Tested-by: Manivannan Sadhasivam 
Signed-off-by: Serge Semin 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Acked-by: Vinod Koul

dmaengine: dw-edma: Fix readq_ch() return value truncation

2023-02-10T23:15:23+00:00

Previously, readq_ch() did a 64-bit readq(), but truncated the result by
storing it in the u32 "value".  Change "value" to u64 to avoid the
truncation.

Note: the method is currently unused, so the bug hasn't caused any problem
so far.

Fixes: 04e0a39fc10f ("dmaengine: dw-edma: Add writeq() and readq() for 64 bits architectures")
Signed-off-by: Serge Semin 
Signed-off-by: Bjorn Helgaas

dmaengine: dw-edma: Use DMA engine device debugfs subdirectory

2023-02-10T23:15:23+00:00

Since all DW eDMA read and write channels are now installed in a framework
of a single DMA engine device, move all the DW eDMA-specific debugfs nodes
into a ready-to-use DMA-engine debugfs subdirectory. It's created during
the DMA-device registration and can be found in the dma_device.dbg_dev_root
field.

Link: https://lore.kernel.org/r/20230113171409.30470-19-Sergey.Semin@baikalelectronics.ru
Tested-by: Manivannan Sadhasivam 
Signed-off-by: Serge Semin 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Acked-by: Vinod Koul

dmaengine: dw-edma: Join read/write channels into a single device

2023-02-10T23:15:23+00:00

There is no point in splitting read/write channels.  First of all, eDMA
read and write channels belong to one physical controller. Secondly,
channel differentiation can be done by filtering and dma_get_slave_caps().
Finally, having these channels handled separately needlessly complicates
the code and causes this debugfs warning:

  debugfs: Directory '1f052000.pcie' with parent 'dmaengine' already present!

Join the read/write channels into a single DMA device.  Client drivers can
choose the correct channel via the DMA slave direction setting. The default
value is overridden by the dw_edma_device_caps() callback in accordance
with the channel type.

Link: https://lore.kernel.org/r/20230113171409.30470-18-Sergey.Semin@baikalelectronics.ru
Tested-by: Manivannan Sadhasivam 
Signed-off-by: Serge Semin 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Acked-by: Vinod Koul

dmaengine: dw-edma: Move eDMA data pointer to debugfs node descriptor

2023-02-10T23:14:42+00:00

The last thing that stops the debugfs part of the eDMA driver from
supporting multi-eDMA platforms is keeping the eDMA private data pointer in
the static area of the debugfs module. Since the debugfs node descriptors
are now heap-allocated, we can freely move that pointer to being preserved
in the descriptors. After the debugfs initialization procedure, that
pointer will be used in the debugfs files getter to access the common CSRs
space and the context CSRs spinlock. So the main part of this change is
connected with the debugfs nodes descriptors initialization macros, which
aside with already defined prototypes now require to have the DW eDMA
private data pointer passed.

[bhelgaas: squash in https://lore.kernel.org/r/20230130185101.2883245-1-arnd@kernel.org]
Link: https://lore.kernel.org/r/20230113171409.30470-17-Sergey.Semin@baikalelectronics.ru
Tested-by: Manivannan Sadhasivam 
Signed-off-by: Serge Semin 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Acked-by: Vinod Koul