Re: [PATCH v11 0/8] Enable designware PCI EP EDMA locally

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 25, 2022 at 4:07 AM Serge Semin <fancer.lancer@xxxxxxxxx> wrote:
>
> On Tue, May 24, 2022 at 10:52:01AM -0500, Bjorn Helgaas wrote:
> > On Tue, May 24, 2022 at 08:48:50AM +0300, Serge Semin wrote:
> > > On Mon, May 23, 2022 at 05:12:56PM -0500, Bjorn Helgaas wrote:
> > > > On Mon, May 23, 2022 at 01:41:48PM -0500, Zhi Li wrote:
> > > > > On Mon, May 23, 2022 at 1:02 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> > > > > > On Mon, May 23, 2022 at 02:06:47PM +0300, Serge Semin wrote:
> > > > > > > Hello Vinod,
> > > > > > >
> > > > > > > On Tue, May 17, 2022 at 10:19:07AM -0500, Frank Li wrote:
> > > > > > > > Default Designware EDMA just probe remotely at host side.
> > > > > > > > This patch allow EDMA driver can probe at EP side.
> > > > > > > >
> > > > > > > > 1. Clean up patch
> > > > > > > >    dmaengine: dw-edma: Detach the private data and chip info structures
> > > > > > > >    dmaengine: dw-edma: Remove unused field irq in struct dw_edma_chip
> > > > > > > >    dmaengine: dw-edma: Change rg_region to reg_base in struct
> > > > > > > >    dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt in struct
> > > > > > > >
> > > > > > > > 2. Enhance EDMA driver to allow prode eDMA at EP side
> > > > > > > >    dmaengine: dw-edma: Add support for chip specific flags
> > > > > > > >    dmaengine: dw-edma: Add DW_EDMA_CHIP_32BIT_DBI for chip specific
> > > > > > > > flags (this patch removed at v11 because dma tree already have fixed
> > > > > > > > patch)
> > > > > > > >
> > > > > > > > 3. Bugs fix at EDMA driver when probe eDMA at EP side
> > > > > > > >    dmaengine: dw-edma: Fix programming the source & dest addresses for
> > > > > > > > ep
> > > > > > > >    dmaengine: dw-edma: Don't rely on the deprecated "direction" member
> > > > > > > >
> > > > > > > > 4. change pci-epf-test to use EDMA driver to transfer data.
> > > > > > > >    PCI: endpoint: Add embedded DMA controller test
> > > > > > > >
> > > > > > > > 5. Using imx8dxl to do test, but some EP functions still have not
> > > > > > > > upstream yet. So below patch show how probe eDMA driver at EP
> > > > > > > > controller driver.
> > > > > > > > https://lore.kernel.org/linux-pci/20220309120149.GB134091@thinkpad/T/#m979eb506c73ab3cfca2e7a43635ecdaec18d8097
> > > > > > >
> > > > > > > The series has been hanging out on review for over three months now.
> > > > > > > It has got to v11 and has been tested on at least two platforms. The
> > > > > > > original driver maintainer has been silent for all that time (most
> > > > > > > likely Gustavo dropped the driver maintaining role). Could you please
> > > > > > > merge it in seeing no comments have been posted for the last several
> > > > > > > weeks? The PCI Host/EP controller drivers maintainer suggested to get
> > > > > > > this series via the DMA-engine tree:
> > > > > > > https://lore.kernel.org/linux-pci/YnqlRShJzvma2SKM@lpieralisi/
> > > > > > > which is obviously right seeing it mainly concerns the DW eDMA driver.
> > > > > > > Though after that Lorenzo disappeared as quickly as popped up.)
> > > > > > >
> > > > > > > There is one more series depending on the changes in this
> > > > > > > patchset:
> > > > > > > https://lore.kernel.org/linux-pci/20220503225104.12108-1-Sergey.Semin@xxxxxxxxxxxxxxxxxxxx/
> > > > > > > Me and Frank already settled all the conflicts and inter-dependencies,
> > > > > > > so at least his series is more than ready to be merged in into the
> > > > > > > kernel repo. It would be very good to get it accepted on this merge
> > > > > > > window so to have the kernel v5.19 with all this changes available.
> > > > > >
> > >
> > > > > > Since the v5.19 merge window is already open, it seems doubtful that
> > > > > > anybody would merge this so late in the cycle.
> > >
> > > In this case it would be safer to merge this whole series through your
> > > repo. See my series:
> > > "[PATCH v2 00/26] dmaengine: dw-edma: Add RP/EP local DMA controllers support"
> > > https://lore.kernel.org/linux-pci/20220503225104.12108-1-Sergey.Semin@xxxxxxxxxxxxxxxxxxxx/
> > > depends in the Frank' patchset. Meanwhile my patchset is also based on the
> > > DW PCIe modifications introduced in the set of the series:
> > > "[PATCH v2 00/17] PCI: dwc: Add dma-ranges/YAML-schema/Baikal-T1 support"
> > > https://lore.kernel.org/linux-pci/20220503214638.1895-1-Sergey.Semin@xxxxxxxxxxxxxxxxxxxx/
> > > and
> > > "[PATCH v3 00/13] PCI: dwc: Various fixes and cleanups"
> > > https://lore.kernel.org/linux-pci/20220517125058.18488-1-Sergey.Semin@xxxxxxxxxxxxxxxxxxxx/
> > >
> > > So to speak in order to have more coherent repos with least merge,
> > > logical problems the next order of the merging would be preferable:
> > > 1) Frank's patchset (ready to be merged in):
> > > [PATCH v11 0/8] Enable designware PCI EP EDMA locally
> > > https://lore.kernel.org/linux-pci/20220517151915.2212838-1-Frank.Li@xxxxxxx
> > > 2) My series (ready to be merged in):
> > > [PATCH v3 00/13] PCI: dwc: Various fixes and cleanups
> > > https://lore.kernel.org/linux-pci/20220517125058.18488-1-Sergey.Semin@xxxxxxxxxxxxxxxxxxxx/
> > > 3) My series (still in review, I need to fix some Rob' and Manivannan' notes)
> > > [PATCH v2 00/17] PCI: dwc: Add dma-ranges/YAML-schema/Baikal-T1 support
> > > https://lore.kernel.org/linux-pci/20220503214638.1895-1-Sergey.Semin@xxxxxxxxxxxxxxxxxxxx/
> > > 4) Me series (ready to be merged in, but depends on the prev patchsets):
> > > https://lore.kernel.org/linux-pci/20220503225104.12108-1-Sergey.Semin@xxxxxxxxxxxxxxxxxxxx/
> > >
> > > Seeing the Frank patches won't make it into the mainline repo on
> > > this merge window, it would be great to collect all the changes in a
> > > single repository. Seeing Lorenzo disappeared as fast as popped up
> > > your repo is the best candidate since the DW eDMA block is a part of
> > > the DW PCIe controller.
> >
>
> > I'll be happy to merge this via the PCI tree, given acks from Gustavo
> > and/or Vinod.

@Vinod Koul
Friendly ping Vinod?

>
> Great! Thanks. I'll add my note regarding this to the v12 patchset
> thread. Alas Gustavo hasn't shown any sign of activity for more than a
> year (last commit on Feb 2021 and no more acks and rb tags afterwards).
> So we need to wait for the Vinod' ack.
>
> -Sergey
>
> >
> > Bjorn



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux