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. > > > > If Gustavo isn't available or willing to merge it, it looks like Vinod > > (maintainer of drivers/dma) would be the next logical candidate. > > I think the last patch should not block other patches from merging. > The last patch about pci-epf-test.c is totally independent from other patches. > > I prefer to merge all the dma patches first. Absolutely. Given an ack from Kishon, it would make sense for Vinod to merge them all together since they're logically related, but I have no objection to merging any of the drivers/dma patches separately. Bjorn
