Thread (47 messages) 47 messages, 6 authors, 2022-10-25

Re: [PATCH RESEND v5 00/24] dmaengine: dw-edma: Add RP/EP local DMA controllers support

From: Serge Semin <hidden>
Date: 2022-08-25 11:28:54
Also in: linux-pci, lkml

On Thu, Aug 25, 2022 at 02:14:36PM +0530, Vinod Koul wrote:
On 25-08-22, 08:04, Serge Semin wrote:
quoted
On Thu, Aug 25, 2022 at 10:12:23AM +0530, Vinod Koul wrote:
quoted
On 24-08-22, 17:07, Serge Semin wrote:
quoted
On Tue, Aug 23, 2022 at 09:15:26PM +0530, Manivannan Sadhasivam wrote:
quoted
On Mon, Aug 22, 2022 at 09:53:08PM +0300, Serge Semin wrote:
quoted
quoted
I've tested this series on Qualcomm SM8450 SoC based dev board. So,

Tested-by: Manivannan Sadhasivam <redacted>
Thanks.
quoted
Not sure what is the merging strategy for this one but this series should get
merged into a single tree. Since the PCI patch is touching the designware
driver, merging the series into dmaengine tree might result in conflict later.
Right, the series
[PATCH v5 00/20] PCI: dwc: Add generic resources and Baikal-T1 support
is supposed to be merged in first. Then this one will get to be
applied with no conflicts. That's what I imply in the head of the
cover-letter.
quoted
I dont see a dependency of dma patches with PCIe patches? I guess they
could go thru the respective trees now..?
There is a backward dependency: the PCIe patch in this series depends
on the eDMA patches and the patches in the patchset #3. So should you
What is the dependency...? Looking at the patches there does not seem to
be one...
[PATCH RESEND v5 24/24] PCI: dwc: Add DW eDMA engine support:
|
+-> depends on the modifications done in the framework DW eDMA driver
| patchset, for instance the changes introduced in the patch
| [PATCH RESEND v5 22/24] dmaengine: dw-edma: Bypass dma-ranges mapping for the local setup
| make sure the dma-ranges property isn't taken into account for the
| Local CPU/Application setup (See it makes the DW_EDMA_CHIP_LOCAL flag
| used which is enabled for the eDMA embedded into the DW PCIe EP/RP).
| All the DebugFS-related and channels join updates are also required to
| make the DW eDMA driver working in the framework of the DW PCIe RP/EP
| device.
|
+-> at the very least depends on the changes introduced in the patchset #3:
| [PATCH v5 16/20] PCI: dwc: Introduce generic controller capabilities interface
| [PATCH v5 17/20] PCI: dwc: Introduce generic resources getter
| The patch at consideration adds CSR region request procedure in the
| method created and updated in these two patches.

There might be some other dependencies, but what I cited above must be
enough not to split the patchsets up between different branches
otherwise besides not properly working DW PCIe driver you'll have merge
conflicts.

-Sergey
quoted
merge the eDMA patches via your tree, the later patch in this series
and the patchset #3 would have needed to be applied in there too. So
the patches can't be split up between different branches. Seeing all
the changes (including the DW eDMA part) concern the PCIe device (DW
eDMA is a part of either DW PCIe End-point or Root Port) and we
already agreed to merge all the changes via the PCIe tree, I would
stick to the previous settled agreement.

-Sergey
quoted
-- 
~Vinod
-- 
~Vinod
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help