* [PATCH v4 0/8] Enable designware PCI EP EDMA locally. @ 2022-03-09 21:11 Frank Li 2022-03-09 21:11 ` [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures Frank Li ` (7 more replies) 0 siblings, 8 replies; 52+ messages in thread From: Frank Li @ 2022-03-09 21:11 UTC (permalink / raw) To: gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam 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 flags at struct dw_edma_chip 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: functions/pci-epf-test: Support PCI controller DMA 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 Frank Li (6): 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 dw_edma_chip dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt in struct dw_edma_chip dmaengine: dw-edma: add flags at struct dw_edma_chip PCI: endpoint: functions/pci-epf-test: Support PCI controller DMA Manivannan Sadhasivam (2): dmaengine: dw-edma: Fix programming the source & dest addresses for ep dmaengine: dw-edma: Don't rely on the deprecated "direction" member drivers/dma/dw-edma/dw-edma-core.c | 130 +++++++++++------- drivers/dma/dw-edma/dw-edma-core.h | 32 +---- drivers/dma/dw-edma/dw-edma-pcie.c | 83 +++++------ drivers/dma/dw-edma/dw-edma-v0-core.c | 44 +++--- drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 10 +- drivers/pci/endpoint/functions/pci-epf-test.c | 108 +++++++++++++-- include/linux/dma/edma.h | 56 +++++++- 7 files changed, 297 insertions(+), 166 deletions(-) -- 2.24.0.rc1 ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures 2022-03-09 21:11 [PATCH v4 0/8] Enable designware PCI EP EDMA locally Frank Li @ 2022-03-09 21:11 ` Frank Li 2022-03-10 12:50 ` Serge Semin ` (2 more replies) 2022-03-09 21:11 ` [PATCH v4 2/8] dmaengine: dw-edma: remove unused field irq in struct dw_edma_chip Frank Li ` (6 subsequent siblings) 7 siblings, 3 replies; 52+ messages in thread From: Frank Li @ 2022-03-09 21:11 UTC (permalink / raw) To: gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam "struct dw_edma_chip" contains an internal structure "struct dw_edma" that is used by the eDMA core internally. This structure should not be touched by the eDMA controller drivers themselves. But currently, the eDMA controller drivers like "dw-edma-pci" allocates and populates this internal structure then passes it on to eDMA core. The eDMA core further populates the structure and uses it. This is wrong! Hence, move all the "struct dw_edma" specifics from controller drivers to the eDMA core. Signed-off-by: Frank Li <Frank.Li@nxp.com> --- Change from v3 to v4 - Accept most suggestions of Serge Semin Change from v2 to v3 - none Change from v1 to v2 - rework commit message - remove duplicate field in struct dw_edma drivers/dma/dw-edma/dw-edma-core.c | 81 +++++++++++++---------- drivers/dma/dw-edma/dw-edma-core.h | 32 +-------- drivers/dma/dw-edma/dw-edma-pcie.c | 83 ++++++++++-------------- drivers/dma/dw-edma/dw-edma-v0-core.c | 24 +++---- drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 10 +-- include/linux/dma/edma.h | 44 +++++++++++++ 6 files changed, 144 insertions(+), 130 deletions(-) diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c index 53289927dd0d6..1abf41d49f75b 100644 --- a/drivers/dma/dw-edma/dw-edma-core.c +++ b/drivers/dma/dw-edma/dw-edma-core.c @@ -65,7 +65,7 @@ static struct dw_edma_burst *dw_edma_alloc_burst(struct dw_edma_chunk *chunk) static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) { struct dw_edma_chan *chan = desc->chan; - struct dw_edma *dw = chan->chip->dw; + struct dw_edma_chip *chip = chan->dw->chip; struct dw_edma_chunk *chunk; chunk = kzalloc(sizeof(*chunk), GFP_NOWAIT); @@ -82,11 +82,11 @@ static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) */ chunk->cb = !(desc->chunks_alloc % 2); if (chan->dir == EDMA_DIR_WRITE) { - chunk->ll_region.paddr = dw->ll_region_wr[chan->id].paddr; - chunk->ll_region.vaddr = dw->ll_region_wr[chan->id].vaddr; + chunk->ll_region.paddr = chip->ll_region_wr[chan->id].paddr; + chunk->ll_region.vaddr = chip->ll_region_wr[chan->id].vaddr; } else { - chunk->ll_region.paddr = dw->ll_region_rd[chan->id].paddr; - chunk->ll_region.vaddr = dw->ll_region_rd[chan->id].vaddr; + chunk->ll_region.paddr = chip->ll_region_rd[chan->id].paddr; + chunk->ll_region.vaddr = chip->ll_region_rd[chan->id].vaddr; } if (desc->chunk) { @@ -664,7 +664,7 @@ static int dw_edma_alloc_chan_resources(struct dma_chan *dchan) if (chan->status != EDMA_ST_IDLE) return -EBUSY; - pm_runtime_get(chan->chip->dev); + pm_runtime_get(chan->dw->chip->dev); return 0; } @@ -686,7 +686,7 @@ static void dw_edma_free_chan_resources(struct dma_chan *dchan) cpu_relax(); } - pm_runtime_put(chan->chip->dev); + pm_runtime_put(chan->dw->chip->dev); } static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, @@ -718,7 +718,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, } INIT_LIST_HEAD(&dma->channels); - for (j = 0; (alloc || dw->nr_irqs == 1) && j < cnt; j++, i++) { + for (j = 0; (alloc || chip->nr_irqs == 1) && j < cnt; j++, i++) { chan = &dw->chan[i]; dt_region = devm_kzalloc(dev, sizeof(*dt_region), GFP_KERNEL); @@ -727,7 +727,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, chan->vc.chan.private = dt_region; - chan->chip = chip; + chan->dw = dw; chan->id = j; chan->dir = write ? EDMA_DIR_WRITE : EDMA_DIR_READ; chan->configured = false; @@ -735,15 +735,15 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, chan->status = EDMA_ST_IDLE; if (write) - chan->ll_max = (dw->ll_region_wr[j].sz / EDMA_LL_SZ); + chan->ll_max = (chip->ll_region_wr[j].sz / EDMA_LL_SZ); else - chan->ll_max = (dw->ll_region_rd[j].sz / EDMA_LL_SZ); + chan->ll_max = (chip->ll_region_rd[j].sz / EDMA_LL_SZ); chan->ll_max -= 1; dev_vdbg(dev, "L. List:\tChannel %s[%u] max_cnt=%u\n", write ? "write" : "read", j, chan->ll_max); - if (dw->nr_irqs == 1) + if (chip->nr_irqs == 1) pos = 0; else pos = off_alloc + (j % alloc); @@ -767,13 +767,13 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, vchan_init(&chan->vc, dma); if (write) { - dt_region->paddr = dw->dt_region_wr[j].paddr; - dt_region->vaddr = dw->dt_region_wr[j].vaddr; - dt_region->sz = dw->dt_region_wr[j].sz; + dt_region->paddr = chip->dt_region_wr[j].paddr; + dt_region->vaddr = chip->dt_region_wr[j].vaddr; + dt_region->sz = chip->dt_region_wr[j].sz; } else { - dt_region->paddr = dw->dt_region_rd[j].paddr; - dt_region->vaddr = dw->dt_region_rd[j].vaddr; - dt_region->sz = dw->dt_region_rd[j].sz; + dt_region->paddr = chip->dt_region_rd[j].paddr; + dt_region->vaddr = chip->dt_region_rd[j].vaddr; + dt_region->sz = chip->dt_region_rd[j].sz; } dw_edma_v0_core_device_config(chan); @@ -840,16 +840,16 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, ch_cnt = dw->wr_ch_cnt + dw->rd_ch_cnt; - if (dw->nr_irqs < 1) + if (chip->nr_irqs < 1) return -EINVAL; - if (dw->nr_irqs == 1) { + if (chip->nr_irqs == 1) { /* Common IRQ shared among all channels */ - irq = dw->ops->irq_vector(dev, 0); + irq = chip->ops->irq_vector(dev, 0); err = request_irq(irq, dw_edma_interrupt_common, IRQF_SHARED, dw->name, &dw->irq[0]); if (err) { - dw->nr_irqs = 0; + chip->nr_irqs = 0; return err; } @@ -857,7 +857,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, get_cached_msi_msg(irq, &dw->irq[0].msi); } else { /* Distribute IRQs equally among all channels */ - int tmp = dw->nr_irqs; + int tmp = chip->nr_irqs; while (tmp && (*wr_alloc + *rd_alloc) < ch_cnt) { dw_edma_dec_irq_alloc(&tmp, wr_alloc, dw->wr_ch_cnt); @@ -868,7 +868,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, dw_edma_add_irq_mask(&rd_mask, *rd_alloc, dw->rd_ch_cnt); for (i = 0; i < (*wr_alloc + *rd_alloc); i++) { - irq = dw->ops->irq_vector(dev, i); + irq = chip->ops->irq_vector(dev, i); err = request_irq(irq, i < *wr_alloc ? dw_edma_interrupt_write : @@ -876,7 +876,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, IRQF_SHARED, dw->name, &dw->irq[i]); if (err) { - dw->nr_irqs = i; + chip->nr_irqs = i; return err; } @@ -884,7 +884,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, get_cached_msi_msg(irq, &dw->irq[i].msi); } - dw->nr_irqs = i; + chip->nr_irqs = i; } return err; @@ -905,17 +905,24 @@ int dw_edma_probe(struct dw_edma_chip *chip) if (!dev) return -EINVAL; - dw = chip->dw; - if (!dw || !dw->irq || !dw->ops || !dw->ops->irq_vector) + dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); + if (!dw) + return -ENOMEM; + + chip->dw = dw; + dw->chip = chip; + + if (!chip->nr_irqs || !chip->ops) return -EINVAL; raw_spin_lock_init(&dw->lock); - dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, + + dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); - dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, + dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); @@ -936,6 +943,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) /* Disable eDMA, only to establish the ideal initial conditions */ dw_edma_v0_core_off(dw); + dw->irq = devm_kcalloc(dev, chip->nr_irqs, sizeof(*dw->irq), GFP_KERNEL); + if (!dw->irq) + return -ENOMEM; + /* Request IRQs */ err = dw_edma_irq_request(chip, &wr_alloc, &rd_alloc); if (err) @@ -960,10 +971,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) return 0; err_irq_free: - for (i = (dw->nr_irqs - 1); i >= 0; i--) - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); + for (i = (chip->nr_irqs - 1); i >= 0; i--) + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); - dw->nr_irqs = 0; + chip->nr_irqs = 0; return err; } @@ -980,8 +991,8 @@ int dw_edma_remove(struct dw_edma_chip *chip) dw_edma_v0_core_off(dw); /* Free irqs */ - for (i = (dw->nr_irqs - 1); i >= 0; i--) - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); + for (i = (chip->nr_irqs - 1); i >= 0; i--) + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); /* Power management */ pm_runtime_disable(dev); diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h index 60316d408c3e0..e254c2fc3d9cf 100644 --- a/drivers/dma/dw-edma/dw-edma-core.h +++ b/drivers/dma/dw-edma/dw-edma-core.h @@ -15,20 +15,12 @@ #include "../virt-dma.h" #define EDMA_LL_SZ 24 -#define EDMA_MAX_WR_CH 8 -#define EDMA_MAX_RD_CH 8 enum dw_edma_dir { EDMA_DIR_WRITE = 0, EDMA_DIR_READ }; -enum dw_edma_map_format { - EDMA_MF_EDMA_LEGACY = 0x0, - EDMA_MF_EDMA_UNROLL = 0x1, - EDMA_MF_HDMA_COMPAT = 0x5 -}; - enum dw_edma_request { EDMA_REQ_NONE = 0, EDMA_REQ_STOP, @@ -57,12 +49,6 @@ struct dw_edma_burst { u32 sz; }; -struct dw_edma_region { - phys_addr_t paddr; - void __iomem *vaddr; - size_t sz; -}; - struct dw_edma_chunk { struct list_head list; struct dw_edma_chan *chan; @@ -87,7 +73,7 @@ struct dw_edma_desc { struct dw_edma_chan { struct virt_dma_chan vc; - struct dw_edma_chip *chip; + struct dw_edma *dw; int id; enum dw_edma_dir dir; @@ -109,10 +95,6 @@ struct dw_edma_irq { struct dw_edma *dw; }; -struct dw_edma_core_ops { - int (*irq_vector)(struct device *dev, unsigned int nr); -}; - struct dw_edma { char name[20]; @@ -122,21 +104,13 @@ struct dw_edma { struct dma_device rd_edma; u16 rd_ch_cnt; - struct dw_edma_region rg_region; /* Registers */ - struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; - struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; - struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; - struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; - struct dw_edma_irq *irq; - int nr_irqs; - - enum dw_edma_map_format mf; struct dw_edma_chan *chan; - const struct dw_edma_core_ops *ops; raw_spinlock_t lock; /* Only for legacy */ + + struct dw_edma_chip *chip; #ifdef CONFIG_DEBUG_FS struct dentry *debugfs; #endif /* CONFIG_DEBUG_FS */ diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c index 44f6e09bdb531..2c1c5fa4e9f28 100644 --- a/drivers/dma/dw-edma/dw-edma-pcie.c +++ b/drivers/dma/dw-edma/dw-edma-pcie.c @@ -148,7 +148,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, struct dw_edma_pcie_data vsec_data; struct device *dev = &pdev->dev; struct dw_edma_chip *chip; - struct dw_edma *dw; int err, nr_irqs; int i, mask; @@ -214,10 +213,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, if (!chip) return -ENOMEM; - dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); - if (!dw) - return -ENOMEM; - /* IRQs allocation */ nr_irqs = pci_alloc_irq_vectors(pdev, 1, vsec_data.irqs, PCI_IRQ_MSI | PCI_IRQ_MSIX); @@ -228,29 +223,23 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, } /* Data structure initialization */ - chip->dw = dw; chip->dev = dev; chip->id = pdev->devfn; - chip->irq = pdev->irq; - dw->mf = vsec_data.mf; - dw->nr_irqs = nr_irqs; - dw->ops = &dw_edma_pcie_core_ops; - dw->wr_ch_cnt = vsec_data.wr_ch_cnt; - dw->rd_ch_cnt = vsec_data.rd_ch_cnt; + chip->mf = vsec_data.mf; + chip->nr_irqs = nr_irqs; + chip->ops = &dw_edma_pcie_core_ops; - dw->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; - if (!dw->rg_region.vaddr) - return -ENOMEM; + chip->wr_ch_cnt = vsec_data.wr_ch_cnt; + chip->rd_ch_cnt = vsec_data.rd_ch_cnt; - dw->rg_region.vaddr += vsec_data.rg.off; - dw->rg_region.paddr = pdev->resource[vsec_data.rg.bar].start; - dw->rg_region.paddr += vsec_data.rg.off; - dw->rg_region.sz = vsec_data.rg.sz; + chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; + if (!chip->rg_region.vaddr) + return -ENOMEM; - for (i = 0; i < dw->wr_ch_cnt; i++) { - struct dw_edma_region *ll_region = &dw->ll_region_wr[i]; - struct dw_edma_region *dt_region = &dw->dt_region_wr[i]; + for (i = 0; i < chip->wr_ch_cnt; i++) { + struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; + struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; struct dw_edma_block *dt_block = &vsec_data.dt_wr[i]; @@ -273,9 +262,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, dt_region->sz = dt_block->sz; } - for (i = 0; i < dw->rd_ch_cnt; i++) { - struct dw_edma_region *ll_region = &dw->ll_region_rd[i]; - struct dw_edma_region *dt_region = &dw->dt_region_rd[i]; + for (i = 0; i < chip->rd_ch_cnt; i++) { + struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; + struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; struct dw_edma_block *dt_block = &vsec_data.dt_rd[i]; @@ -299,45 +288,45 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, } /* Debug info */ - if (dw->mf == EDMA_MF_EDMA_LEGACY) - pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", dw->mf); - else if (dw->mf == EDMA_MF_EDMA_UNROLL) - pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", dw->mf); - else if (dw->mf == EDMA_MF_HDMA_COMPAT) - pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", dw->mf); + if (chip->mf == EDMA_MF_EDMA_LEGACY) + pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", chip->mf); + else if (chip->mf == EDMA_MF_EDMA_UNROLL) + pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", chip->mf); + else if (chip->mf == EDMA_MF_HDMA_COMPAT) + pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", chip->mf); else - pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", dw->mf); + pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", chip->mf); - pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", + pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, - dw->rg_region.vaddr, &dw->rg_region.paddr); + chip->rg_region.vaddr); - for (i = 0; i < dw->wr_ch_cnt; i++) { + for (i = 0; i < chip->wr_ch_cnt; i++) { pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", i, vsec_data.ll_wr[i].bar, - vsec_data.ll_wr[i].off, dw->ll_region_wr[i].sz, - dw->ll_region_wr[i].vaddr, &dw->ll_region_wr[i].paddr); + vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, + chip->ll_region_wr[i].vaddr, &chip->ll_region_wr[i].paddr); pci_dbg(pdev, "Data:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", i, vsec_data.dt_wr[i].bar, - vsec_data.dt_wr[i].off, dw->dt_region_wr[i].sz, - dw->dt_region_wr[i].vaddr, &dw->dt_region_wr[i].paddr); + vsec_data.dt_wr[i].off, chip->dt_region_wr[i].sz, + chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); } - for (i = 0; i < dw->rd_ch_cnt; i++) { + for (i = 0; i < chip->rd_ch_cnt; i++) { pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", i, vsec_data.ll_rd[i].bar, - vsec_data.ll_rd[i].off, dw->ll_region_rd[i].sz, - dw->ll_region_rd[i].vaddr, &dw->ll_region_rd[i].paddr); + vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, + chip->ll_region_rd[i].vaddr, &chip->ll_region_rd[i].paddr); pci_dbg(pdev, "Data:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", i, vsec_data.dt_rd[i].bar, - vsec_data.dt_rd[i].off, dw->dt_region_rd[i].sz, - dw->dt_region_rd[i].vaddr, &dw->dt_region_rd[i].paddr); + vsec_data.dt_rd[i].off, chip->dt_region_rd[i].sz, + chip->dt_region_rd[i].vaddr, &chip->dt_region_rd[i].paddr); } - pci_dbg(pdev, "Nr. IRQs:\t%u\n", dw->nr_irqs); + pci_dbg(pdev, "Nr. IRQs:\t%u\n", chip->nr_irqs); /* Validating if PCI interrupts were enabled */ if (!pci_dev_msi_enabled(pdev)) { @@ -345,10 +334,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, return -EPERM; } - dw->irq = devm_kcalloc(dev, nr_irqs, sizeof(*dw->irq), GFP_KERNEL); - if (!dw->irq) - return -ENOMEM; - /* Starting eDMA driver */ err = dw_edma_probe(chip); if (err) { diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c index 329fc2e57b703..e507e076fad16 100644 --- a/drivers/dma/dw-edma/dw-edma-v0-core.c +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c @@ -25,7 +25,7 @@ enum dw_edma_control { static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) { - return dw->rg_region.vaddr; + return dw->chip->rg_region.vaddr; } #define SET_32(dw, name, value) \ @@ -96,7 +96,7 @@ static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) static inline struct dw_edma_v0_ch_regs __iomem * __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) { - if (dw->mf == EDMA_MF_EDMA_LEGACY) + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) return &(__dw_regs(dw)->type.legacy.ch); if (dir == EDMA_DIR_WRITE) @@ -108,7 +108,7 @@ __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) static inline void writel_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, u32 value, void __iomem *addr) { - if (dw->mf == EDMA_MF_EDMA_LEGACY) { + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { u32 viewport_sel; unsigned long flags; @@ -133,7 +133,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, { u32 value; - if (dw->mf == EDMA_MF_EDMA_LEGACY) { + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { u32 viewport_sel; unsigned long flags; @@ -169,7 +169,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, static inline void writeq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, u64 value, void __iomem *addr) { - if (dw->mf == EDMA_MF_EDMA_LEGACY) { + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { u32 viewport_sel; unsigned long flags; @@ -194,7 +194,7 @@ static inline u64 readq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, { u32 value; - if (dw->mf == EDMA_MF_EDMA_LEGACY) { + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { u32 viewport_sel; unsigned long flags; @@ -256,7 +256,7 @@ u16 dw_edma_v0_core_ch_count(struct dw_edma *dw, enum dw_edma_dir dir) enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) { - struct dw_edma *dw = chan->chip->dw; + struct dw_edma *dw = chan->dw; u32 tmp; tmp = FIELD_GET(EDMA_V0_CH_STATUS_MASK, @@ -272,7 +272,7 @@ enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) { - struct dw_edma *dw = chan->chip->dw; + struct dw_edma *dw = chan->dw; SET_RW_32(dw, chan->dir, int_clear, FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id))); @@ -280,7 +280,7 @@ void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) void dw_edma_v0_core_clear_abort_int(struct dw_edma_chan *chan) { - struct dw_edma *dw = chan->chip->dw; + struct dw_edma *dw = chan->dw; SET_RW_32(dw, chan->dir, int_clear, FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id))); @@ -357,7 +357,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) { struct dw_edma_chan *chan = chunk->chan; - struct dw_edma *dw = chan->chip->dw; + struct dw_edma *dw = chan->dw; u32 tmp; dw_edma_v0_core_write_chunk(chunk); @@ -365,7 +365,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) if (first) { /* Enable engine */ SET_RW_32(dw, chan->dir, engine_en, BIT(0)); - if (dw->mf == EDMA_MF_HDMA_COMPAT) { + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { switch (chan->id) { case 0: SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, @@ -431,7 +431,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) int dw_edma_v0_core_device_config(struct dw_edma_chan *chan) { - struct dw_edma *dw = chan->chip->dw; + struct dw_edma *dw = chan->dw; u32 tmp = 0; /* MSI done addr - low, high */ diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c index 4b3bcffd15ef1..edb7e137cb35a 100644 --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c @@ -54,7 +54,7 @@ struct debugfs_entries { static int dw_edma_debugfs_u32_get(void *data, u64 *val) { void __iomem *reg = (void __force __iomem *)data; - if (dw->mf == EDMA_MF_EDMA_LEGACY && + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY && reg >= (void __iomem *)®s->type.legacy.ch) { void __iomem *ptr = ®s->type.legacy.ch; u32 viewport_sel = 0; @@ -173,7 +173,7 @@ static void dw_edma_debugfs_regs_wr(struct dentry *dir) nr_entries = ARRAY_SIZE(debugfs_regs); dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); - if (dw->mf == EDMA_MF_HDMA_COMPAT) { + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { nr_entries = ARRAY_SIZE(debugfs_unroll_regs); dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, regs_dir); @@ -242,7 +242,7 @@ static void dw_edma_debugfs_regs_rd(struct dentry *dir) nr_entries = ARRAY_SIZE(debugfs_regs); dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); - if (dw->mf == EDMA_MF_HDMA_COMPAT) { + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { nr_entries = ARRAY_SIZE(debugfs_unroll_regs); dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, regs_dir); @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) if (!dw) return; - regs = dw->rg_region.vaddr; + regs = dw->chip->rg_region.vaddr; if (!regs) return; @@ -296,7 +296,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) if (!dw->debugfs) return; - debugfs_create_u32("mf", 0444, dw->debugfs, &dw->mf); + debugfs_create_u32("mf", 0444, dw->debugfs, &dw->chip->mf); debugfs_create_u16("wr_ch_cnt", 0444, dw->debugfs, &dw->wr_ch_cnt); debugfs_create_u16("rd_ch_cnt", 0444, dw->debugfs, &dw->rd_ch_cnt); diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h index cab6e18773dad..a9bee4aeb2eee 100644 --- a/include/linux/dma/edma.h +++ b/include/linux/dma/edma.h @@ -12,19 +12,63 @@ #include <linux/device.h> #include <linux/dmaengine.h> +#define EDMA_MAX_WR_CH 8 +#define EDMA_MAX_RD_CH 8 + struct dw_edma; +struct dw_edma_region { + phys_addr_t paddr; + void __iomem *vaddr; + size_t sz; +}; + +struct dw_edma_core_ops { + int (*irq_vector)(struct device *dev, unsigned int nr); +}; + +enum dw_edma_map_format { + EDMA_MF_EDMA_LEGACY = 0x0, + EDMA_MF_EDMA_UNROLL = 0x1, + EDMA_MF_HDMA_COMPAT = 0x5 +}; + /** * struct dw_edma_chip - representation of DesignWare eDMA controller hardware * @dev: struct device of the eDMA controller * @id: instance ID * @irq: irq line + * @nr_irqs: total dma irq number + * @ops DMA channel to IRQ number mapping + * @wr_ch_cnt DMA write channel number + * @rd_ch_cnt DMA read channel number + * @rg_region DMA register region + * @ll_region_wr DMA descriptor link list memory for write channel + * @ll_region_rd DMA descriptor link list memory for read channel + * @mf DMA register map format * @dw: struct dw_edma that is filed by dw_edma_probe() */ struct dw_edma_chip { struct device *dev; int id; int irq; + int nr_irqs; + const struct dw_edma_core_ops *ops; + + struct dw_edma_region rg_region; + + u16 wr_ch_cnt; + u16 rd_ch_cnt; + /* link list address */ + struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; + struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; + + /* data region */ + struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; + struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; + + enum dw_edma_map_format mf; + struct dw_edma *dw; }; -- 2.24.0.rc1 ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures 2022-03-09 21:11 ` [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures Frank Li @ 2022-03-10 12:50 ` Serge Semin 2022-03-10 20:20 ` Serge Semin 2022-03-12 19:54 ` Serge Semin 2 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-10 12:50 UTC (permalink / raw) To: Frank Li Cc: Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam On Wed, Mar 09, 2022 at 03:11:57PM -0600, Frank Li wrote: > "struct dw_edma_chip" contains an internal structure "struct dw_edma" that > is used by the eDMA core internally. This structure should not be touched > by the eDMA controller drivers themselves. But currently, the eDMA > controller drivers like "dw-edma-pci" allocates and populates this > internal structure then passes it on to eDMA core. The eDMA core further > populates the structure and uses it. This is wrong! > > Hence, move all the "struct dw_edma" specifics from controller drivers > to the eDMA core. > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > Change from v3 to v4 > - Accept most suggestions of Serge Semin > Change from v2 to v3 > - none > Change from v1 to v2 > - rework commit message > - remove duplicate field in struct dw_edma > > drivers/dma/dw-edma/dw-edma-core.c | 81 +++++++++++++---------- > drivers/dma/dw-edma/dw-edma-core.h | 32 +-------- > drivers/dma/dw-edma/dw-edma-pcie.c | 83 ++++++++++-------------- > drivers/dma/dw-edma/dw-edma-v0-core.c | 24 +++---- > drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 10 +-- > include/linux/dma/edma.h | 44 +++++++++++++ > 6 files changed, 144 insertions(+), 130 deletions(-) > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > index 53289927dd0d6..1abf41d49f75b 100644 > --- a/drivers/dma/dw-edma/dw-edma-core.c > +++ b/drivers/dma/dw-edma/dw-edma-core.c > @@ -65,7 +65,7 @@ static struct dw_edma_burst *dw_edma_alloc_burst(struct dw_edma_chunk *chunk) > static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > { > struct dw_edma_chan *chan = desc->chan; > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma_chip *chip = chan->dw->chip; > struct dw_edma_chunk *chunk; > > chunk = kzalloc(sizeof(*chunk), GFP_NOWAIT); > @@ -82,11 +82,11 @@ static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > */ > chunk->cb = !(desc->chunks_alloc % 2); > if (chan->dir == EDMA_DIR_WRITE) { > - chunk->ll_region.paddr = dw->ll_region_wr[chan->id].paddr; > - chunk->ll_region.vaddr = dw->ll_region_wr[chan->id].vaddr; > + chunk->ll_region.paddr = chip->ll_region_wr[chan->id].paddr; > + chunk->ll_region.vaddr = chip->ll_region_wr[chan->id].vaddr; > } else { > - chunk->ll_region.paddr = dw->ll_region_rd[chan->id].paddr; > - chunk->ll_region.vaddr = dw->ll_region_rd[chan->id].vaddr; > + chunk->ll_region.paddr = chip->ll_region_rd[chan->id].paddr; > + chunk->ll_region.vaddr = chip->ll_region_rd[chan->id].vaddr; > } > > if (desc->chunk) { > @@ -664,7 +664,7 @@ static int dw_edma_alloc_chan_resources(struct dma_chan *dchan) > if (chan->status != EDMA_ST_IDLE) > return -EBUSY; > > - pm_runtime_get(chan->chip->dev); > + pm_runtime_get(chan->dw->chip->dev); > > return 0; > } > @@ -686,7 +686,7 @@ static void dw_edma_free_chan_resources(struct dma_chan *dchan) > cpu_relax(); > } > > - pm_runtime_put(chan->chip->dev); > + pm_runtime_put(chan->dw->chip->dev); > } > > static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > @@ -718,7 +718,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > } > > INIT_LIST_HEAD(&dma->channels); > - for (j = 0; (alloc || dw->nr_irqs == 1) && j < cnt; j++, i++) { > + for (j = 0; (alloc || chip->nr_irqs == 1) && j < cnt; j++, i++) { > chan = &dw->chan[i]; > > dt_region = devm_kzalloc(dev, sizeof(*dt_region), GFP_KERNEL); > @@ -727,7 +727,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > chan->vc.chan.private = dt_region; > > - chan->chip = chip; > + chan->dw = dw; > chan->id = j; > chan->dir = write ? EDMA_DIR_WRITE : EDMA_DIR_READ; > chan->configured = false; > @@ -735,15 +735,15 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > chan->status = EDMA_ST_IDLE; > > if (write) > - chan->ll_max = (dw->ll_region_wr[j].sz / EDMA_LL_SZ); > + chan->ll_max = (chip->ll_region_wr[j].sz / EDMA_LL_SZ); > else > - chan->ll_max = (dw->ll_region_rd[j].sz / EDMA_LL_SZ); > + chan->ll_max = (chip->ll_region_rd[j].sz / EDMA_LL_SZ); > chan->ll_max -= 1; > > dev_vdbg(dev, "L. List:\tChannel %s[%u] max_cnt=%u\n", > write ? "write" : "read", j, chan->ll_max); > > - if (dw->nr_irqs == 1) > + if (chip->nr_irqs == 1) > pos = 0; > else > pos = off_alloc + (j % alloc); > @@ -767,13 +767,13 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > vchan_init(&chan->vc, dma); > > if (write) { > - dt_region->paddr = dw->dt_region_wr[j].paddr; > - dt_region->vaddr = dw->dt_region_wr[j].vaddr; > - dt_region->sz = dw->dt_region_wr[j].sz; > + dt_region->paddr = chip->dt_region_wr[j].paddr; > + dt_region->vaddr = chip->dt_region_wr[j].vaddr; > + dt_region->sz = chip->dt_region_wr[j].sz; > } else { > - dt_region->paddr = dw->dt_region_rd[j].paddr; > - dt_region->vaddr = dw->dt_region_rd[j].vaddr; > - dt_region->sz = dw->dt_region_rd[j].sz; > + dt_region->paddr = chip->dt_region_rd[j].paddr; > + dt_region->vaddr = chip->dt_region_rd[j].vaddr; > + dt_region->sz = chip->dt_region_rd[j].sz; > } > > dw_edma_v0_core_device_config(chan); > @@ -840,16 +840,16 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > ch_cnt = dw->wr_ch_cnt + dw->rd_ch_cnt; > > - if (dw->nr_irqs < 1) > + if (chip->nr_irqs < 1) > return -EINVAL; > > - if (dw->nr_irqs == 1) { > + if (chip->nr_irqs == 1) { > /* Common IRQ shared among all channels */ > - irq = dw->ops->irq_vector(dev, 0); > + irq = chip->ops->irq_vector(dev, 0); > err = request_irq(irq, dw_edma_interrupt_common, > IRQF_SHARED, dw->name, &dw->irq[0]); > if (err) { > - dw->nr_irqs = 0; > + chip->nr_irqs = 0; > return err; > } > > @@ -857,7 +857,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > get_cached_msi_msg(irq, &dw->irq[0].msi); > } else { > /* Distribute IRQs equally among all channels */ > - int tmp = dw->nr_irqs; > + int tmp = chip->nr_irqs; > > while (tmp && (*wr_alloc + *rd_alloc) < ch_cnt) { > dw_edma_dec_irq_alloc(&tmp, wr_alloc, dw->wr_ch_cnt); > @@ -868,7 +868,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > dw_edma_add_irq_mask(&rd_mask, *rd_alloc, dw->rd_ch_cnt); > > for (i = 0; i < (*wr_alloc + *rd_alloc); i++) { > - irq = dw->ops->irq_vector(dev, i); > + irq = chip->ops->irq_vector(dev, i); > err = request_irq(irq, > i < *wr_alloc ? > dw_edma_interrupt_write : > @@ -876,7 +876,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > IRQF_SHARED, dw->name, > &dw->irq[i]); > if (err) { > - dw->nr_irqs = i; > + chip->nr_irqs = i; > return err; > } > > @@ -884,7 +884,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > get_cached_msi_msg(irq, &dw->irq[i].msi); > } > > - dw->nr_irqs = i; > + chip->nr_irqs = i; > } > > return err; > @@ -905,17 +905,24 @@ int dw_edma_probe(struct dw_edma_chip *chip) > if (!dev) > return -EINVAL; ^ | See my next comment... > > - dw = chip->dw; > - if (!dw || !dw->irq || !dw->ops || !dw->ops->irq_vector) > + dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > + if (!dw) > + return -ENOMEM; > + > + chip->dw = dw; > + dw->chip = chip; > + > + if (!chip->nr_irqs || !chip->ops) Please, join this with the "if (!dev)" statement above. As I said in my comment to v3, there is no point in allocating anything if the chip info is invalid. -Sergey > return -EINVAL; > > raw_spin_lock_init(&dw->lock); > > - dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, > + > + dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > - dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, > + dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > @@ -936,6 +943,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > /* Disable eDMA, only to establish the ideal initial conditions */ > dw_edma_v0_core_off(dw); > > + dw->irq = devm_kcalloc(dev, chip->nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > + if (!dw->irq) > + return -ENOMEM; > + > /* Request IRQs */ > err = dw_edma_irq_request(chip, &wr_alloc, &rd_alloc); > if (err) > @@ -960,10 +971,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > return 0; > > err_irq_free: > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > - dw->nr_irqs = 0; > + chip->nr_irqs = 0; > > return err; > } > @@ -980,8 +991,8 @@ int dw_edma_remove(struct dw_edma_chip *chip) > dw_edma_v0_core_off(dw); > > /* Free irqs */ > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > /* Power management */ > pm_runtime_disable(dev); > diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h > index 60316d408c3e0..e254c2fc3d9cf 100644 > --- a/drivers/dma/dw-edma/dw-edma-core.h > +++ b/drivers/dma/dw-edma/dw-edma-core.h > @@ -15,20 +15,12 @@ > #include "../virt-dma.h" > > #define EDMA_LL_SZ 24 > -#define EDMA_MAX_WR_CH 8 > -#define EDMA_MAX_RD_CH 8 > > enum dw_edma_dir { > EDMA_DIR_WRITE = 0, > EDMA_DIR_READ > }; > > -enum dw_edma_map_format { > - EDMA_MF_EDMA_LEGACY = 0x0, > - EDMA_MF_EDMA_UNROLL = 0x1, > - EDMA_MF_HDMA_COMPAT = 0x5 > -}; > - > enum dw_edma_request { > EDMA_REQ_NONE = 0, > EDMA_REQ_STOP, > @@ -57,12 +49,6 @@ struct dw_edma_burst { > u32 sz; > }; > > -struct dw_edma_region { > - phys_addr_t paddr; > - void __iomem *vaddr; > - size_t sz; > -}; > - > struct dw_edma_chunk { > struct list_head list; > struct dw_edma_chan *chan; > @@ -87,7 +73,7 @@ struct dw_edma_desc { > > struct dw_edma_chan { > struct virt_dma_chan vc; > - struct dw_edma_chip *chip; > + struct dw_edma *dw; > int id; > enum dw_edma_dir dir; > > @@ -109,10 +95,6 @@ struct dw_edma_irq { > struct dw_edma *dw; > }; > > -struct dw_edma_core_ops { > - int (*irq_vector)(struct device *dev, unsigned int nr); > -}; > - > struct dw_edma { > char name[20]; > > @@ -122,21 +104,13 @@ struct dw_edma { > struct dma_device rd_edma; > u16 rd_ch_cnt; > > - struct dw_edma_region rg_region; /* Registers */ > - struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > - struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > - struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > - struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > - > struct dw_edma_irq *irq; > - int nr_irqs; > - > - enum dw_edma_map_format mf; > > struct dw_edma_chan *chan; > - const struct dw_edma_core_ops *ops; > > raw_spinlock_t lock; /* Only for legacy */ > + > + struct dw_edma_chip *chip; > #ifdef CONFIG_DEBUG_FS > struct dentry *debugfs; > #endif /* CONFIG_DEBUG_FS */ > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > index 44f6e09bdb531..2c1c5fa4e9f28 100644 > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > @@ -148,7 +148,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > struct dw_edma_pcie_data vsec_data; > struct device *dev = &pdev->dev; > struct dw_edma_chip *chip; > - struct dw_edma *dw; > int err, nr_irqs; > int i, mask; > > @@ -214,10 +213,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > if (!chip) > return -ENOMEM; > > - dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > - if (!dw) > - return -ENOMEM; > - > /* IRQs allocation */ > nr_irqs = pci_alloc_irq_vectors(pdev, 1, vsec_data.irqs, > PCI_IRQ_MSI | PCI_IRQ_MSIX); > @@ -228,29 +223,23 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > } > > /* Data structure initialization */ > - chip->dw = dw; > chip->dev = dev; > chip->id = pdev->devfn; > - chip->irq = pdev->irq; > > - dw->mf = vsec_data.mf; > - dw->nr_irqs = nr_irqs; > - dw->ops = &dw_edma_pcie_core_ops; > - dw->wr_ch_cnt = vsec_data.wr_ch_cnt; > - dw->rd_ch_cnt = vsec_data.rd_ch_cnt; > + chip->mf = vsec_data.mf; > + chip->nr_irqs = nr_irqs; > + chip->ops = &dw_edma_pcie_core_ops; > > - dw->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > - if (!dw->rg_region.vaddr) > - return -ENOMEM; > + chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > + chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > - dw->rg_region.vaddr += vsec_data.rg.off; > - dw->rg_region.paddr = pdev->resource[vsec_data.rg.bar].start; > - dw->rg_region.paddr += vsec_data.rg.off; > - dw->rg_region.sz = vsec_data.rg.sz; > + chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > + if (!chip->rg_region.vaddr) > + return -ENOMEM; > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > - struct dw_edma_region *ll_region = &dw->ll_region_wr[i]; > - struct dw_edma_region *dt_region = &dw->dt_region_wr[i]; > + for (i = 0; i < chip->wr_ch_cnt; i++) { > + struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > + struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > struct dw_edma_block *dt_block = &vsec_data.dt_wr[i]; > > @@ -273,9 +262,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > dt_region->sz = dt_block->sz; > } > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > - struct dw_edma_region *ll_region = &dw->ll_region_rd[i]; > - struct dw_edma_region *dt_region = &dw->dt_region_rd[i]; > + for (i = 0; i < chip->rd_ch_cnt; i++) { > + struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > + struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > struct dw_edma_block *dt_block = &vsec_data.dt_rd[i]; > > @@ -299,45 +288,45 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > } > > /* Debug info */ > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > - pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", dw->mf); > - else if (dw->mf == EDMA_MF_EDMA_UNROLL) > - pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", dw->mf); > - else if (dw->mf == EDMA_MF_HDMA_COMPAT) > - pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", dw->mf); > + if (chip->mf == EDMA_MF_EDMA_LEGACY) > + pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", chip->mf); > + else if (chip->mf == EDMA_MF_EDMA_UNROLL) > + pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", chip->mf); > + else if (chip->mf == EDMA_MF_HDMA_COMPAT) > + pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", chip->mf); > else > - pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", dw->mf); > + pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", chip->mf); > > - pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > + pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", > vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, > - dw->rg_region.vaddr, &dw->rg_region.paddr); > + chip->rg_region.vaddr); > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > + for (i = 0; i < chip->wr_ch_cnt; i++) { > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.ll_wr[i].bar, > - vsec_data.ll_wr[i].off, dw->ll_region_wr[i].sz, > - dw->ll_region_wr[i].vaddr, &dw->ll_region_wr[i].paddr); > + vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > + chip->ll_region_wr[i].vaddr, &chip->ll_region_wr[i].paddr); > > pci_dbg(pdev, "Data:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.dt_wr[i].bar, > - vsec_data.dt_wr[i].off, dw->dt_region_wr[i].sz, > - dw->dt_region_wr[i].vaddr, &dw->dt_region_wr[i].paddr); > + vsec_data.dt_wr[i].off, chip->dt_region_wr[i].sz, > + chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > } > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > + for (i = 0; i < chip->rd_ch_cnt; i++) { > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.ll_rd[i].bar, > - vsec_data.ll_rd[i].off, dw->ll_region_rd[i].sz, > - dw->ll_region_rd[i].vaddr, &dw->ll_region_rd[i].paddr); > + vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > + chip->ll_region_rd[i].vaddr, &chip->ll_region_rd[i].paddr); > > pci_dbg(pdev, "Data:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.dt_rd[i].bar, > - vsec_data.dt_rd[i].off, dw->dt_region_rd[i].sz, > - dw->dt_region_rd[i].vaddr, &dw->dt_region_rd[i].paddr); > + vsec_data.dt_rd[i].off, chip->dt_region_rd[i].sz, > + chip->dt_region_rd[i].vaddr, &chip->dt_region_rd[i].paddr); > } > > - pci_dbg(pdev, "Nr. IRQs:\t%u\n", dw->nr_irqs); > + pci_dbg(pdev, "Nr. IRQs:\t%u\n", chip->nr_irqs); > > /* Validating if PCI interrupts were enabled */ > if (!pci_dev_msi_enabled(pdev)) { > @@ -345,10 +334,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > return -EPERM; > } > > - dw->irq = devm_kcalloc(dev, nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > - if (!dw->irq) > - return -ENOMEM; > - > /* Starting eDMA driver */ > err = dw_edma_probe(chip); > if (err) { > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > index 329fc2e57b703..e507e076fad16 100644 > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > @@ -25,7 +25,7 @@ enum dw_edma_control { > > static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > { > - return dw->rg_region.vaddr; > + return dw->chip->rg_region.vaddr; > } > > #define SET_32(dw, name, value) \ > @@ -96,7 +96,7 @@ static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > static inline struct dw_edma_v0_ch_regs __iomem * > __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > { > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) > return &(__dw_regs(dw)->type.legacy.ch); > > if (dir == EDMA_DIR_WRITE) > @@ -108,7 +108,7 @@ __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > static inline void writel_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > u32 value, void __iomem *addr) > { > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -133,7 +133,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > { > u32 value; > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -169,7 +169,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > static inline void writeq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > u64 value, void __iomem *addr) > { > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -194,7 +194,7 @@ static inline u64 readq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > { > u32 value; > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -256,7 +256,7 @@ u16 dw_edma_v0_core_ch_count(struct dw_edma *dw, enum dw_edma_dir dir) > > enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > u32 tmp; > > tmp = FIELD_GET(EDMA_V0_CH_STATUS_MASK, > @@ -272,7 +272,7 @@ enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > > SET_RW_32(dw, chan->dir, int_clear, > FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id))); > @@ -280,7 +280,7 @@ void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > void dw_edma_v0_core_clear_abort_int(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > > SET_RW_32(dw, chan->dir, int_clear, > FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id))); > @@ -357,7 +357,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > { > struct dw_edma_chan *chan = chunk->chan; > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > u32 tmp; > > dw_edma_v0_core_write_chunk(chunk); > @@ -365,7 +365,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > if (first) { > /* Enable engine */ > SET_RW_32(dw, chan->dir, engine_en, BIT(0)); > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > switch (chan->id) { > case 0: > SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, > @@ -431,7 +431,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > int dw_edma_v0_core_device_config(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > u32 tmp = 0; > > /* MSI done addr - low, high */ > diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > index 4b3bcffd15ef1..edb7e137cb35a 100644 > --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > @@ -54,7 +54,7 @@ struct debugfs_entries { > static int dw_edma_debugfs_u32_get(void *data, u64 *val) > { > void __iomem *reg = (void __force __iomem *)data; > - if (dw->mf == EDMA_MF_EDMA_LEGACY && > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY && > reg >= (void __iomem *)®s->type.legacy.ch) { > void __iomem *ptr = ®s->type.legacy.ch; > u32 viewport_sel = 0; > @@ -173,7 +173,7 @@ static void dw_edma_debugfs_regs_wr(struct dentry *dir) > nr_entries = ARRAY_SIZE(debugfs_regs); > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > regs_dir); > @@ -242,7 +242,7 @@ static void dw_edma_debugfs_regs_rd(struct dentry *dir) > nr_entries = ARRAY_SIZE(debugfs_regs); > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > regs_dir); > @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > if (!dw) > return; > > - regs = dw->rg_region.vaddr; > + regs = dw->chip->rg_region.vaddr; > if (!regs) > return; > > @@ -296,7 +296,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > if (!dw->debugfs) > return; > > - debugfs_create_u32("mf", 0444, dw->debugfs, &dw->mf); > + debugfs_create_u32("mf", 0444, dw->debugfs, &dw->chip->mf); > debugfs_create_u16("wr_ch_cnt", 0444, dw->debugfs, &dw->wr_ch_cnt); > debugfs_create_u16("rd_ch_cnt", 0444, dw->debugfs, &dw->rd_ch_cnt); > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > index cab6e18773dad..a9bee4aeb2eee 100644 > --- a/include/linux/dma/edma.h > +++ b/include/linux/dma/edma.h > @@ -12,19 +12,63 @@ > #include <linux/device.h> > #include <linux/dmaengine.h> > > +#define EDMA_MAX_WR_CH 8 > +#define EDMA_MAX_RD_CH 8 > + > struct dw_edma; > > +struct dw_edma_region { > + phys_addr_t paddr; > + void __iomem *vaddr; > + size_t sz; > +}; > + > +struct dw_edma_core_ops { > + int (*irq_vector)(struct device *dev, unsigned int nr); > +}; > + > +enum dw_edma_map_format { > + EDMA_MF_EDMA_LEGACY = 0x0, > + EDMA_MF_EDMA_UNROLL = 0x1, > + EDMA_MF_HDMA_COMPAT = 0x5 > +}; > + > /** > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > * @dev: struct device of the eDMA controller > * @id: instance ID > * @irq: irq line > + * @nr_irqs: total dma irq number > + * @ops DMA channel to IRQ number mapping > + * @wr_ch_cnt DMA write channel number > + * @rd_ch_cnt DMA read channel number > + * @rg_region DMA register region > + * @ll_region_wr DMA descriptor link list memory for write channel > + * @ll_region_rd DMA descriptor link list memory for read channel > + * @mf DMA register map format > * @dw: struct dw_edma that is filed by dw_edma_probe() > */ > struct dw_edma_chip { > struct device *dev; > int id; > int irq; > + int nr_irqs; > + const struct dw_edma_core_ops *ops; > + > + struct dw_edma_region rg_region; > + > + u16 wr_ch_cnt; > + u16 rd_ch_cnt; > + /* link list address */ > + struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > + struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > + > + /* data region */ > + struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > + struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > + > + enum dw_edma_map_format mf; > + > struct dw_edma *dw; > }; > > -- > 2.24.0.rc1 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures 2022-03-09 21:11 ` [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures Frank Li 2022-03-10 12:50 ` Serge Semin @ 2022-03-10 20:20 ` Serge Semin 2022-03-10 20:29 ` Zhi Li 2022-03-12 19:54 ` Serge Semin 2 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-10 20:20 UTC (permalink / raw) To: Frank Li Cc: Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam On Wed, Mar 09, 2022 at 03:11:57PM -0600, Frank Li wrote: > "struct dw_edma_chip" contains an internal structure "struct dw_edma" that > is used by the eDMA core internally. This structure should not be touched > by the eDMA controller drivers themselves. But currently, the eDMA > controller drivers like "dw-edma-pci" allocates and populates this > internal structure then passes it on to eDMA core. The eDMA core further > populates the structure and uses it. This is wrong! > > Hence, move all the "struct dw_edma" specifics from controller drivers > to the eDMA core. > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > Change from v3 to v4 > - Accept most suggestions of Serge Semin > Change from v2 to v3 > - none > Change from v1 to v2 > - rework commit message > - remove duplicate field in struct dw_edma > > drivers/dma/dw-edma/dw-edma-core.c | 81 +++++++++++++---------- > drivers/dma/dw-edma/dw-edma-core.h | 32 +-------- > drivers/dma/dw-edma/dw-edma-pcie.c | 83 ++++++++++-------------- > drivers/dma/dw-edma/dw-edma-v0-core.c | 24 +++---- > drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 10 +-- > include/linux/dma/edma.h | 44 +++++++++++++ > 6 files changed, 144 insertions(+), 130 deletions(-) > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > index 53289927dd0d6..1abf41d49f75b 100644 > --- a/drivers/dma/dw-edma/dw-edma-core.c > +++ b/drivers/dma/dw-edma/dw-edma-core.c > @@ -65,7 +65,7 @@ static struct dw_edma_burst *dw_edma_alloc_burst(struct dw_edma_chunk *chunk) > static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > { > struct dw_edma_chan *chan = desc->chan; > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma_chip *chip = chan->dw->chip; > struct dw_edma_chunk *chunk; > > chunk = kzalloc(sizeof(*chunk), GFP_NOWAIT); > @@ -82,11 +82,11 @@ static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > */ > chunk->cb = !(desc->chunks_alloc % 2); > if (chan->dir == EDMA_DIR_WRITE) { > - chunk->ll_region.paddr = dw->ll_region_wr[chan->id].paddr; > - chunk->ll_region.vaddr = dw->ll_region_wr[chan->id].vaddr; > + chunk->ll_region.paddr = chip->ll_region_wr[chan->id].paddr; > + chunk->ll_region.vaddr = chip->ll_region_wr[chan->id].vaddr; > } else { > - chunk->ll_region.paddr = dw->ll_region_rd[chan->id].paddr; > - chunk->ll_region.vaddr = dw->ll_region_rd[chan->id].vaddr; > + chunk->ll_region.paddr = chip->ll_region_rd[chan->id].paddr; > + chunk->ll_region.vaddr = chip->ll_region_rd[chan->id].vaddr; > } > > if (desc->chunk) { > @@ -664,7 +664,7 @@ static int dw_edma_alloc_chan_resources(struct dma_chan *dchan) > if (chan->status != EDMA_ST_IDLE) > return -EBUSY; > > - pm_runtime_get(chan->chip->dev); > + pm_runtime_get(chan->dw->chip->dev); > > return 0; > } > @@ -686,7 +686,7 @@ static void dw_edma_free_chan_resources(struct dma_chan *dchan) > cpu_relax(); > } > > - pm_runtime_put(chan->chip->dev); > + pm_runtime_put(chan->dw->chip->dev); > } > > static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > @@ -718,7 +718,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > } > > INIT_LIST_HEAD(&dma->channels); > - for (j = 0; (alloc || dw->nr_irqs == 1) && j < cnt; j++, i++) { > + for (j = 0; (alloc || chip->nr_irqs == 1) && j < cnt; j++, i++) { > chan = &dw->chan[i]; > > dt_region = devm_kzalloc(dev, sizeof(*dt_region), GFP_KERNEL); > @@ -727,7 +727,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > chan->vc.chan.private = dt_region; > > - chan->chip = chip; > + chan->dw = dw; > chan->id = j; > chan->dir = write ? EDMA_DIR_WRITE : EDMA_DIR_READ; > chan->configured = false; > @@ -735,15 +735,15 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > chan->status = EDMA_ST_IDLE; > > if (write) > - chan->ll_max = (dw->ll_region_wr[j].sz / EDMA_LL_SZ); > + chan->ll_max = (chip->ll_region_wr[j].sz / EDMA_LL_SZ); > else > - chan->ll_max = (dw->ll_region_rd[j].sz / EDMA_LL_SZ); > + chan->ll_max = (chip->ll_region_rd[j].sz / EDMA_LL_SZ); > chan->ll_max -= 1; > > dev_vdbg(dev, "L. List:\tChannel %s[%u] max_cnt=%u\n", > write ? "write" : "read", j, chan->ll_max); > > - if (dw->nr_irqs == 1) > + if (chip->nr_irqs == 1) > pos = 0; > else > pos = off_alloc + (j % alloc); > @@ -767,13 +767,13 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > vchan_init(&chan->vc, dma); > > if (write) { > - dt_region->paddr = dw->dt_region_wr[j].paddr; > - dt_region->vaddr = dw->dt_region_wr[j].vaddr; > - dt_region->sz = dw->dt_region_wr[j].sz; > + dt_region->paddr = chip->dt_region_wr[j].paddr; > + dt_region->vaddr = chip->dt_region_wr[j].vaddr; > + dt_region->sz = chip->dt_region_wr[j].sz; > } else { > - dt_region->paddr = dw->dt_region_rd[j].paddr; > - dt_region->vaddr = dw->dt_region_rd[j].vaddr; > - dt_region->sz = dw->dt_region_rd[j].sz; > + dt_region->paddr = chip->dt_region_rd[j].paddr; > + dt_region->vaddr = chip->dt_region_rd[j].vaddr; > + dt_region->sz = chip->dt_region_rd[j].sz; > } > > dw_edma_v0_core_device_config(chan); > @@ -840,16 +840,16 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > ch_cnt = dw->wr_ch_cnt + dw->rd_ch_cnt; > > - if (dw->nr_irqs < 1) > + if (chip->nr_irqs < 1) > return -EINVAL; > > - if (dw->nr_irqs == 1) { > + if (chip->nr_irqs == 1) { > /* Common IRQ shared among all channels */ > - irq = dw->ops->irq_vector(dev, 0); > + irq = chip->ops->irq_vector(dev, 0); > err = request_irq(irq, dw_edma_interrupt_common, > IRQF_SHARED, dw->name, &dw->irq[0]); > if (err) { > - dw->nr_irqs = 0; > + chip->nr_irqs = 0; > return err; > } > > @@ -857,7 +857,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > get_cached_msi_msg(irq, &dw->irq[0].msi); > } else { > /* Distribute IRQs equally among all channels */ > - int tmp = dw->nr_irqs; > + int tmp = chip->nr_irqs; > > while (tmp && (*wr_alloc + *rd_alloc) < ch_cnt) { > dw_edma_dec_irq_alloc(&tmp, wr_alloc, dw->wr_ch_cnt); > @@ -868,7 +868,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > dw_edma_add_irq_mask(&rd_mask, *rd_alloc, dw->rd_ch_cnt); > > for (i = 0; i < (*wr_alloc + *rd_alloc); i++) { > - irq = dw->ops->irq_vector(dev, i); > + irq = chip->ops->irq_vector(dev, i); > err = request_irq(irq, > i < *wr_alloc ? > dw_edma_interrupt_write : > @@ -876,7 +876,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > IRQF_SHARED, dw->name, > &dw->irq[i]); > if (err) { > - dw->nr_irqs = i; > + chip->nr_irqs = i; > return err; > } > > @@ -884,7 +884,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > get_cached_msi_msg(irq, &dw->irq[i].msi); > } > > - dw->nr_irqs = i; > + chip->nr_irqs = i; > } > > return err; > @@ -905,17 +905,24 @@ int dw_edma_probe(struct dw_edma_chip *chip) > if (!dev) > return -EINVAL; > > - dw = chip->dw; > - if (!dw || !dw->irq || !dw->ops || !dw->ops->irq_vector) > + dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > + if (!dw) > + return -ENOMEM; > + > + chip->dw = dw; > + dw->chip = chip; > + > + if (!chip->nr_irqs || !chip->ops) > return -EINVAL; > > raw_spin_lock_init(&dw->lock); > > - dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, > + > + dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > - dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, > + dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > @@ -936,6 +943,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > /* Disable eDMA, only to establish the ideal initial conditions */ > dw_edma_v0_core_off(dw); > > + dw->irq = devm_kcalloc(dev, chip->nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > + if (!dw->irq) > + return -ENOMEM; > + > /* Request IRQs */ > err = dw_edma_irq_request(chip, &wr_alloc, &rd_alloc); > if (err) > @@ -960,10 +971,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > return 0; > > err_irq_free: > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > - dw->nr_irqs = 0; > + chip->nr_irqs = 0; > > return err; > } > @@ -980,8 +991,8 @@ int dw_edma_remove(struct dw_edma_chip *chip) > dw_edma_v0_core_off(dw); > > /* Free irqs */ > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > /* Power management */ > pm_runtime_disable(dev); > diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h > index 60316d408c3e0..e254c2fc3d9cf 100644 > --- a/drivers/dma/dw-edma/dw-edma-core.h > +++ b/drivers/dma/dw-edma/dw-edma-core.h > @@ -15,20 +15,12 @@ > #include "../virt-dma.h" > > #define EDMA_LL_SZ 24 > -#define EDMA_MAX_WR_CH 8 > -#define EDMA_MAX_RD_CH 8 > > enum dw_edma_dir { > EDMA_DIR_WRITE = 0, > EDMA_DIR_READ > }; > > -enum dw_edma_map_format { > - EDMA_MF_EDMA_LEGACY = 0x0, > - EDMA_MF_EDMA_UNROLL = 0x1, > - EDMA_MF_HDMA_COMPAT = 0x5 > -}; > - > enum dw_edma_request { > EDMA_REQ_NONE = 0, > EDMA_REQ_STOP, > @@ -57,12 +49,6 @@ struct dw_edma_burst { > u32 sz; > }; > > -struct dw_edma_region { > - phys_addr_t paddr; > - void __iomem *vaddr; > - size_t sz; > -}; > - > struct dw_edma_chunk { > struct list_head list; > struct dw_edma_chan *chan; > @@ -87,7 +73,7 @@ struct dw_edma_desc { > > struct dw_edma_chan { > struct virt_dma_chan vc; > - struct dw_edma_chip *chip; > + struct dw_edma *dw; > int id; > enum dw_edma_dir dir; > > @@ -109,10 +95,6 @@ struct dw_edma_irq { > struct dw_edma *dw; > }; > > -struct dw_edma_core_ops { > - int (*irq_vector)(struct device *dev, unsigned int nr); > -}; > - > struct dw_edma { > char name[20]; > > @@ -122,21 +104,13 @@ struct dw_edma { > struct dma_device rd_edma; > u16 rd_ch_cnt; > > - struct dw_edma_region rg_region; /* Registers */ > - struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > - struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > - struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > - struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > - > struct dw_edma_irq *irq; > - int nr_irqs; > - > - enum dw_edma_map_format mf; > > struct dw_edma_chan *chan; > - const struct dw_edma_core_ops *ops; > > raw_spinlock_t lock; /* Only for legacy */ > + > + struct dw_edma_chip *chip; > #ifdef CONFIG_DEBUG_FS > struct dentry *debugfs; > #endif /* CONFIG_DEBUG_FS */ > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > index 44f6e09bdb531..2c1c5fa4e9f28 100644 > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > @@ -148,7 +148,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > struct dw_edma_pcie_data vsec_data; > struct device *dev = &pdev->dev; > struct dw_edma_chip *chip; > - struct dw_edma *dw; > int err, nr_irqs; > int i, mask; > > @@ -214,10 +213,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > if (!chip) > return -ENOMEM; > > - dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > - if (!dw) > - return -ENOMEM; > - > /* IRQs allocation */ > nr_irqs = pci_alloc_irq_vectors(pdev, 1, vsec_data.irqs, > PCI_IRQ_MSI | PCI_IRQ_MSIX); > @@ -228,29 +223,23 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > } > > /* Data structure initialization */ > - chip->dw = dw; > chip->dev = dev; > chip->id = pdev->devfn; > - chip->irq = pdev->irq; > > - dw->mf = vsec_data.mf; > - dw->nr_irqs = nr_irqs; > - dw->ops = &dw_edma_pcie_core_ops; > - dw->wr_ch_cnt = vsec_data.wr_ch_cnt; > - dw->rd_ch_cnt = vsec_data.rd_ch_cnt; > + chip->mf = vsec_data.mf; > + chip->nr_irqs = nr_irqs; > + chip->ops = &dw_edma_pcie_core_ops; > > - dw->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > - if (!dw->rg_region.vaddr) > - return -ENOMEM; > + chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > + chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > - dw->rg_region.vaddr += vsec_data.rg.off; > - dw->rg_region.paddr = pdev->resource[vsec_data.rg.bar].start; > - dw->rg_region.paddr += vsec_data.rg.off; > - dw->rg_region.sz = vsec_data.rg.sz; > + chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > + if (!chip->rg_region.vaddr) > + return -ENOMEM; > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > - struct dw_edma_region *ll_region = &dw->ll_region_wr[i]; > - struct dw_edma_region *dt_region = &dw->dt_region_wr[i]; > + for (i = 0; i < chip->wr_ch_cnt; i++) { > + struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > + struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > struct dw_edma_block *dt_block = &vsec_data.dt_wr[i]; > > @@ -273,9 +262,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > dt_region->sz = dt_block->sz; > } > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > - struct dw_edma_region *ll_region = &dw->ll_region_rd[i]; > - struct dw_edma_region *dt_region = &dw->dt_region_rd[i]; > + for (i = 0; i < chip->rd_ch_cnt; i++) { > + struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > + struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > struct dw_edma_block *dt_block = &vsec_data.dt_rd[i]; > > @@ -299,45 +288,45 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > } > > /* Debug info */ > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > - pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", dw->mf); > - else if (dw->mf == EDMA_MF_EDMA_UNROLL) > - pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", dw->mf); > - else if (dw->mf == EDMA_MF_HDMA_COMPAT) > - pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", dw->mf); > + if (chip->mf == EDMA_MF_EDMA_LEGACY) > + pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", chip->mf); > + else if (chip->mf == EDMA_MF_EDMA_UNROLL) > + pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", chip->mf); > + else if (chip->mf == EDMA_MF_HDMA_COMPAT) > + pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", chip->mf); > else > - pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", dw->mf); > + pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", chip->mf); > > - pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > + pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", > vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, > - dw->rg_region.vaddr, &dw->rg_region.paddr); > + chip->rg_region.vaddr); > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > + for (i = 0; i < chip->wr_ch_cnt; i++) { > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.ll_wr[i].bar, > - vsec_data.ll_wr[i].off, dw->ll_region_wr[i].sz, > - dw->ll_region_wr[i].vaddr, &dw->ll_region_wr[i].paddr); > + vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > + chip->ll_region_wr[i].vaddr, &chip->ll_region_wr[i].paddr); > > pci_dbg(pdev, "Data:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.dt_wr[i].bar, > - vsec_data.dt_wr[i].off, dw->dt_region_wr[i].sz, > - dw->dt_region_wr[i].vaddr, &dw->dt_region_wr[i].paddr); > + vsec_data.dt_wr[i].off, chip->dt_region_wr[i].sz, > + chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > } > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > + for (i = 0; i < chip->rd_ch_cnt; i++) { > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.ll_rd[i].bar, > - vsec_data.ll_rd[i].off, dw->ll_region_rd[i].sz, > - dw->ll_region_rd[i].vaddr, &dw->ll_region_rd[i].paddr); > + vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > + chip->ll_region_rd[i].vaddr, &chip->ll_region_rd[i].paddr); > > pci_dbg(pdev, "Data:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.dt_rd[i].bar, > - vsec_data.dt_rd[i].off, dw->dt_region_rd[i].sz, > - dw->dt_region_rd[i].vaddr, &dw->dt_region_rd[i].paddr); > + vsec_data.dt_rd[i].off, chip->dt_region_rd[i].sz, > + chip->dt_region_rd[i].vaddr, &chip->dt_region_rd[i].paddr); > } > > - pci_dbg(pdev, "Nr. IRQs:\t%u\n", dw->nr_irqs); > + pci_dbg(pdev, "Nr. IRQs:\t%u\n", chip->nr_irqs); > > /* Validating if PCI interrupts were enabled */ > if (!pci_dev_msi_enabled(pdev)) { > @@ -345,10 +334,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > return -EPERM; > } > > - dw->irq = devm_kcalloc(dev, nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > - if (!dw->irq) > - return -ENOMEM; > - > /* Starting eDMA driver */ > err = dw_edma_probe(chip); > if (err) { > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > index 329fc2e57b703..e507e076fad16 100644 > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > @@ -25,7 +25,7 @@ enum dw_edma_control { > > static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > { > - return dw->rg_region.vaddr; > + return dw->chip->rg_region.vaddr; > } > > #define SET_32(dw, name, value) \ > @@ -96,7 +96,7 @@ static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > static inline struct dw_edma_v0_ch_regs __iomem * > __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > { > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) > return &(__dw_regs(dw)->type.legacy.ch); > > if (dir == EDMA_DIR_WRITE) > @@ -108,7 +108,7 @@ __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > static inline void writel_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > u32 value, void __iomem *addr) > { > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -133,7 +133,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > { > u32 value; > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -169,7 +169,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > static inline void writeq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > u64 value, void __iomem *addr) > { > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -194,7 +194,7 @@ static inline u64 readq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > { > u32 value; > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -256,7 +256,7 @@ u16 dw_edma_v0_core_ch_count(struct dw_edma *dw, enum dw_edma_dir dir) > > enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > u32 tmp; > > tmp = FIELD_GET(EDMA_V0_CH_STATUS_MASK, > @@ -272,7 +272,7 @@ enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > > SET_RW_32(dw, chan->dir, int_clear, > FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id))); > @@ -280,7 +280,7 @@ void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > void dw_edma_v0_core_clear_abort_int(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > > SET_RW_32(dw, chan->dir, int_clear, > FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id))); > @@ -357,7 +357,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > { > struct dw_edma_chan *chan = chunk->chan; > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > u32 tmp; > > dw_edma_v0_core_write_chunk(chunk); > @@ -365,7 +365,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > if (first) { > /* Enable engine */ > SET_RW_32(dw, chan->dir, engine_en, BIT(0)); > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > switch (chan->id) { > case 0: > SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, > @@ -431,7 +431,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > int dw_edma_v0_core_device_config(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > u32 tmp = 0; > > /* MSI done addr - low, high */ > diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > index 4b3bcffd15ef1..edb7e137cb35a 100644 > --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > @@ -54,7 +54,7 @@ struct debugfs_entries { > static int dw_edma_debugfs_u32_get(void *data, u64 *val) > { > void __iomem *reg = (void __force __iomem *)data; > - if (dw->mf == EDMA_MF_EDMA_LEGACY && > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY && > reg >= (void __iomem *)®s->type.legacy.ch) { > void __iomem *ptr = ®s->type.legacy.ch; > u32 viewport_sel = 0; > @@ -173,7 +173,7 @@ static void dw_edma_debugfs_regs_wr(struct dentry *dir) > nr_entries = ARRAY_SIZE(debugfs_regs); > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > regs_dir); > @@ -242,7 +242,7 @@ static void dw_edma_debugfs_regs_rd(struct dentry *dir) > nr_entries = ARRAY_SIZE(debugfs_regs); > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > regs_dir); > @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > if (!dw) > return; > > - regs = dw->rg_region.vaddr; > + regs = dw->chip->rg_region.vaddr; > if (!regs) > return; > > @@ -296,7 +296,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > if (!dw->debugfs) > return; > > - debugfs_create_u32("mf", 0444, dw->debugfs, &dw->mf); > + debugfs_create_u32("mf", 0444, dw->debugfs, &dw->chip->mf); > debugfs_create_u16("wr_ch_cnt", 0444, dw->debugfs, &dw->wr_ch_cnt); > debugfs_create_u16("rd_ch_cnt", 0444, dw->debugfs, &dw->rd_ch_cnt); > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > index cab6e18773dad..a9bee4aeb2eee 100644 > --- a/include/linux/dma/edma.h > +++ b/include/linux/dma/edma.h > @@ -12,19 +12,63 @@ > #include <linux/device.h> > #include <linux/dmaengine.h> > > +#define EDMA_MAX_WR_CH 8 > +#define EDMA_MAX_RD_CH 8 > + > struct dw_edma; > > +struct dw_edma_region { > + phys_addr_t paddr; > + void __iomem *vaddr; > + size_t sz; > +}; > + > +struct dw_edma_core_ops { > + int (*irq_vector)(struct device *dev, unsigned int nr); > +}; > + > +enum dw_edma_map_format { > + EDMA_MF_EDMA_LEGACY = 0x0, > + EDMA_MF_EDMA_UNROLL = 0x1, > + EDMA_MF_HDMA_COMPAT = 0x5 > +}; > + > /** > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > * @dev: struct device of the eDMA controller > * @id: instance ID > * @irq: irq line > + * @nr_irqs: total dma irq number > + * @ops DMA channel to IRQ number mapping > + * @wr_ch_cnt DMA write channel number > + * @rd_ch_cnt DMA read channel number > + * @rg_region DMA register region > + * @ll_region_wr DMA descriptor link list memory for write channel > + * @ll_region_rd DMA descriptor link list memory for read channel > + * @mf DMA register map format > * @dw: struct dw_edma that is filed by dw_edma_probe() > */ > struct dw_edma_chip { > struct device *dev; > int id; > int irq; > + int nr_irqs; > + const struct dw_edma_core_ops *ops; > + > + struct dw_edma_region rg_region; > + > + u16 wr_ch_cnt; > + u16 rd_ch_cnt; > + /* link list address */ > + struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > + struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > + > + /* data region */ > + struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > + struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > + > + enum dw_edma_map_format mf; > + > struct dw_edma *dw; Please drop this field from here and just change the dw_edma_probe() prototype to returning a pointer to the struct dw_edma structure. Like this: struct dw_edma *dw_edma_probe(const struct dw_edma_chip *chip); void dw_edma_remove(struct dw_edma *dw); By doing so we'll be able to have the chip data being const and at least statically defined. -Sergey > }; > > -- > 2.24.0.rc1 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures 2022-03-10 20:20 ` Serge Semin @ 2022-03-10 20:29 ` Zhi Li 2022-03-11 11:03 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-10 20:29 UTC (permalink / raw) To: Serge Semin Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam in On Thu, Mar 10, 2022 at 2:20 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > On Wed, Mar 09, 2022 at 03:11:57PM -0600, Frank Li wrote: > > "struct dw_edma_chip" contains an internal structure "struct dw_edma" that > > is used by the eDMA core internally. This structure should not be touched > > by the eDMA controller drivers themselves. But currently, the eDMA > > controller drivers like "dw-edma-pci" allocates and populates this > > internal structure then passes it on to eDMA core. The eDMA core further > > populates the structure and uses it. This is wrong! > > > > Hence, move all the "struct dw_edma" specifics from controller drivers > > to the eDMA core. > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > --- > > Change from v3 to v4 > > - Accept most suggestions of Serge Semin > > Change from v2 to v3 > > - none > > Change from v1 to v2 > > - rework commit message > > - remove duplicate field in struct dw_edma > > > > drivers/dma/dw-edma/dw-edma-core.c | 81 +++++++++++++---------- > > drivers/dma/dw-edma/dw-edma-core.h | 32 +-------- > > drivers/dma/dw-edma/dw-edma-pcie.c | 83 ++++++++++-------------- > > drivers/dma/dw-edma/dw-edma-v0-core.c | 24 +++---- > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 10 +-- > > include/linux/dma/edma.h | 44 +++++++++++++ > > 6 files changed, 144 insertions(+), 130 deletions(-) > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > index 53289927dd0d6..1abf41d49f75b 100644 > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > @@ -65,7 +65,7 @@ static struct dw_edma_burst *dw_edma_alloc_burst(struct dw_edma_chunk *chunk) > > static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > > { > > struct dw_edma_chan *chan = desc->chan; > > - struct dw_edma *dw = chan->chip->dw; > > + struct dw_edma_chip *chip = chan->dw->chip; > > struct dw_edma_chunk *chunk; > > > > chunk = kzalloc(sizeof(*chunk), GFP_NOWAIT); > > @@ -82,11 +82,11 @@ static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > > */ > > chunk->cb = !(desc->chunks_alloc % 2); > > if (chan->dir == EDMA_DIR_WRITE) { > > - chunk->ll_region.paddr = dw->ll_region_wr[chan->id].paddr; > > - chunk->ll_region.vaddr = dw->ll_region_wr[chan->id].vaddr; > > + chunk->ll_region.paddr = chip->ll_region_wr[chan->id].paddr; > > + chunk->ll_region.vaddr = chip->ll_region_wr[chan->id].vaddr; > > } else { > > - chunk->ll_region.paddr = dw->ll_region_rd[chan->id].paddr; > > - chunk->ll_region.vaddr = dw->ll_region_rd[chan->id].vaddr; > > + chunk->ll_region.paddr = chip->ll_region_rd[chan->id].paddr; > > + chunk->ll_region.vaddr = chip->ll_region_rd[chan->id].vaddr; > > } > > > > if (desc->chunk) { > > @@ -664,7 +664,7 @@ static int dw_edma_alloc_chan_resources(struct dma_chan *dchan) > > if (chan->status != EDMA_ST_IDLE) > > return -EBUSY; > > > > - pm_runtime_get(chan->chip->dev); > > + pm_runtime_get(chan->dw->chip->dev); > > > > return 0; > > } > > @@ -686,7 +686,7 @@ static void dw_edma_free_chan_resources(struct dma_chan *dchan) > > cpu_relax(); > > } > > > > - pm_runtime_put(chan->chip->dev); > > + pm_runtime_put(chan->dw->chip->dev); > > } > > > > static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > @@ -718,7 +718,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > } > > > > INIT_LIST_HEAD(&dma->channels); > > - for (j = 0; (alloc || dw->nr_irqs == 1) && j < cnt; j++, i++) { > > + for (j = 0; (alloc || chip->nr_irqs == 1) && j < cnt; j++, i++) { > > chan = &dw->chan[i]; > > > > dt_region = devm_kzalloc(dev, sizeof(*dt_region), GFP_KERNEL); > > @@ -727,7 +727,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > chan->vc.chan.private = dt_region; > > > > - chan->chip = chip; > > + chan->dw = dw; > > chan->id = j; > > chan->dir = write ? EDMA_DIR_WRITE : EDMA_DIR_READ; > > chan->configured = false; > > @@ -735,15 +735,15 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > chan->status = EDMA_ST_IDLE; > > > > if (write) > > - chan->ll_max = (dw->ll_region_wr[j].sz / EDMA_LL_SZ); > > + chan->ll_max = (chip->ll_region_wr[j].sz / EDMA_LL_SZ); > > else > > - chan->ll_max = (dw->ll_region_rd[j].sz / EDMA_LL_SZ); > > + chan->ll_max = (chip->ll_region_rd[j].sz / EDMA_LL_SZ); > > chan->ll_max -= 1; > > > > dev_vdbg(dev, "L. List:\tChannel %s[%u] max_cnt=%u\n", > > write ? "write" : "read", j, chan->ll_max); > > > > - if (dw->nr_irqs == 1) > > + if (chip->nr_irqs == 1) > > pos = 0; > > else > > pos = off_alloc + (j % alloc); > > @@ -767,13 +767,13 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > vchan_init(&chan->vc, dma); > > > > if (write) { > > - dt_region->paddr = dw->dt_region_wr[j].paddr; > > - dt_region->vaddr = dw->dt_region_wr[j].vaddr; > > - dt_region->sz = dw->dt_region_wr[j].sz; > > + dt_region->paddr = chip->dt_region_wr[j].paddr; > > + dt_region->vaddr = chip->dt_region_wr[j].vaddr; > > + dt_region->sz = chip->dt_region_wr[j].sz; > > } else { > > - dt_region->paddr = dw->dt_region_rd[j].paddr; > > - dt_region->vaddr = dw->dt_region_rd[j].vaddr; > > - dt_region->sz = dw->dt_region_rd[j].sz; > > + dt_region->paddr = chip->dt_region_rd[j].paddr; > > + dt_region->vaddr = chip->dt_region_rd[j].vaddr; > > + dt_region->sz = chip->dt_region_rd[j].sz; > > } > > > > dw_edma_v0_core_device_config(chan); > > @@ -840,16 +840,16 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > ch_cnt = dw->wr_ch_cnt + dw->rd_ch_cnt; > > > > - if (dw->nr_irqs < 1) > > + if (chip->nr_irqs < 1) > > return -EINVAL; > > > > - if (dw->nr_irqs == 1) { > > + if (chip->nr_irqs == 1) { > > /* Common IRQ shared among all channels */ > > - irq = dw->ops->irq_vector(dev, 0); > > + irq = chip->ops->irq_vector(dev, 0); > > err = request_irq(irq, dw_edma_interrupt_common, > > IRQF_SHARED, dw->name, &dw->irq[0]); > > if (err) { > > - dw->nr_irqs = 0; > > + chip->nr_irqs = 0; > > return err; > > } > > > > @@ -857,7 +857,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > get_cached_msi_msg(irq, &dw->irq[0].msi); > > } else { > > /* Distribute IRQs equally among all channels */ > > - int tmp = dw->nr_irqs; > > + int tmp = chip->nr_irqs; > > > > while (tmp && (*wr_alloc + *rd_alloc) < ch_cnt) { > > dw_edma_dec_irq_alloc(&tmp, wr_alloc, dw->wr_ch_cnt); > > @@ -868,7 +868,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > dw_edma_add_irq_mask(&rd_mask, *rd_alloc, dw->rd_ch_cnt); > > > > for (i = 0; i < (*wr_alloc + *rd_alloc); i++) { > > - irq = dw->ops->irq_vector(dev, i); > > + irq = chip->ops->irq_vector(dev, i); > > err = request_irq(irq, > > i < *wr_alloc ? > > dw_edma_interrupt_write : > > @@ -876,7 +876,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > IRQF_SHARED, dw->name, > > &dw->irq[i]); > > if (err) { > > - dw->nr_irqs = i; > > + chip->nr_irqs = i; > > return err; > > } > > > > @@ -884,7 +884,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > get_cached_msi_msg(irq, &dw->irq[i].msi); > > } > > > > - dw->nr_irqs = i; > > + chip->nr_irqs = i; > > } > > > > return err; > > @@ -905,17 +905,24 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > if (!dev) > > return -EINVAL; > > > > - dw = chip->dw; > > - if (!dw || !dw->irq || !dw->ops || !dw->ops->irq_vector) > > + dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > > + if (!dw) > > + return -ENOMEM; > > + > > + chip->dw = dw; > > + dw->chip = chip; > > + > > + if (!chip->nr_irqs || !chip->ops) > > return -EINVAL; > > > > raw_spin_lock_init(&dw->lock); > > > > - dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, > > + > > + dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > > > - dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, > > + dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > > > @@ -936,6 +943,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > /* Disable eDMA, only to establish the ideal initial conditions */ > > dw_edma_v0_core_off(dw); > > > > + dw->irq = devm_kcalloc(dev, chip->nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > > + if (!dw->irq) > > + return -ENOMEM; > > + > > /* Request IRQs */ > > err = dw_edma_irq_request(chip, &wr_alloc, &rd_alloc); > > if (err) > > @@ -960,10 +971,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > return 0; > > > > err_irq_free: > > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > > > - dw->nr_irqs = 0; > > + chip->nr_irqs = 0; > > > > return err; > > } > > @@ -980,8 +991,8 @@ int dw_edma_remove(struct dw_edma_chip *chip) > > dw_edma_v0_core_off(dw); > > > > /* Free irqs */ > > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > > > /* Power management */ > > pm_runtime_disable(dev); > > diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h > > index 60316d408c3e0..e254c2fc3d9cf 100644 > > --- a/drivers/dma/dw-edma/dw-edma-core.h > > +++ b/drivers/dma/dw-edma/dw-edma-core.h > > @@ -15,20 +15,12 @@ > > #include "../virt-dma.h" > > > > #define EDMA_LL_SZ 24 > > -#define EDMA_MAX_WR_CH 8 > > -#define EDMA_MAX_RD_CH 8 > > > > enum dw_edma_dir { > > EDMA_DIR_WRITE = 0, > > EDMA_DIR_READ > > }; > > > > -enum dw_edma_map_format { > > - EDMA_MF_EDMA_LEGACY = 0x0, > > - EDMA_MF_EDMA_UNROLL = 0x1, > > - EDMA_MF_HDMA_COMPAT = 0x5 > > -}; > > - > > enum dw_edma_request { > > EDMA_REQ_NONE = 0, > > EDMA_REQ_STOP, > > @@ -57,12 +49,6 @@ struct dw_edma_burst { > > u32 sz; > > }; > > > > -struct dw_edma_region { > > - phys_addr_t paddr; > > - void __iomem *vaddr; > > - size_t sz; > > -}; > > - > > struct dw_edma_chunk { > > struct list_head list; > > struct dw_edma_chan *chan; > > @@ -87,7 +73,7 @@ struct dw_edma_desc { > > > > struct dw_edma_chan { > > struct virt_dma_chan vc; > > - struct dw_edma_chip *chip; > > + struct dw_edma *dw; > > int id; > > enum dw_edma_dir dir; > > > > @@ -109,10 +95,6 @@ struct dw_edma_irq { > > struct dw_edma *dw; > > }; > > > > -struct dw_edma_core_ops { > > - int (*irq_vector)(struct device *dev, unsigned int nr); > > -}; > > - > > struct dw_edma { > > char name[20]; > > > > @@ -122,21 +104,13 @@ struct dw_edma { > > struct dma_device rd_edma; > > u16 rd_ch_cnt; > > > > - struct dw_edma_region rg_region; /* Registers */ > > - struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > - struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > - struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > > - struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > > - > > struct dw_edma_irq *irq; > > - int nr_irqs; > > - > > - enum dw_edma_map_format mf; > > > > struct dw_edma_chan *chan; > > - const struct dw_edma_core_ops *ops; > > > > raw_spinlock_t lock; /* Only for legacy */ > > + > > + struct dw_edma_chip *chip; > > #ifdef CONFIG_DEBUG_FS > > struct dentry *debugfs; > > #endif /* CONFIG_DEBUG_FS */ > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > > index 44f6e09bdb531..2c1c5fa4e9f28 100644 > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > > @@ -148,7 +148,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > struct dw_edma_pcie_data vsec_data; > > struct device *dev = &pdev->dev; > > struct dw_edma_chip *chip; > > - struct dw_edma *dw; > > int err, nr_irqs; > > int i, mask; > > > > @@ -214,10 +213,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > if (!chip) > > return -ENOMEM; > > > > - dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > > - if (!dw) > > - return -ENOMEM; > > - > > /* IRQs allocation */ > > nr_irqs = pci_alloc_irq_vectors(pdev, 1, vsec_data.irqs, > > PCI_IRQ_MSI | PCI_IRQ_MSIX); > > @@ -228,29 +223,23 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > } > > > > /* Data structure initialization */ > > - chip->dw = dw; > > chip->dev = dev; > > chip->id = pdev->devfn; > > - chip->irq = pdev->irq; > > > > - dw->mf = vsec_data.mf; > > - dw->nr_irqs = nr_irqs; > > - dw->ops = &dw_edma_pcie_core_ops; > > - dw->wr_ch_cnt = vsec_data.wr_ch_cnt; > > - dw->rd_ch_cnt = vsec_data.rd_ch_cnt; > > + chip->mf = vsec_data.mf; > > + chip->nr_irqs = nr_irqs; > > + chip->ops = &dw_edma_pcie_core_ops; > > > > - dw->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > - if (!dw->rg_region.vaddr) > > - return -ENOMEM; > > + chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > > + chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > > > - dw->rg_region.vaddr += vsec_data.rg.off; > > - dw->rg_region.paddr = pdev->resource[vsec_data.rg.bar].start; > > - dw->rg_region.paddr += vsec_data.rg.off; > > - dw->rg_region.sz = vsec_data.rg.sz; > > + chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > + if (!chip->rg_region.vaddr) > > + return -ENOMEM; > > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > > - struct dw_edma_region *ll_region = &dw->ll_region_wr[i]; > > - struct dw_edma_region *dt_region = &dw->dt_region_wr[i]; > > + for (i = 0; i < chip->wr_ch_cnt; i++) { > > + struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > > + struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > > struct dw_edma_block *dt_block = &vsec_data.dt_wr[i]; > > > > @@ -273,9 +262,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > dt_region->sz = dt_block->sz; > > } > > > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > > - struct dw_edma_region *ll_region = &dw->ll_region_rd[i]; > > - struct dw_edma_region *dt_region = &dw->dt_region_rd[i]; > > + for (i = 0; i < chip->rd_ch_cnt; i++) { > > + struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > > + struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > > struct dw_edma_block *dt_block = &vsec_data.dt_rd[i]; > > > > @@ -299,45 +288,45 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > } > > > > /* Debug info */ > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > > - pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", dw->mf); > > - else if (dw->mf == EDMA_MF_EDMA_UNROLL) > > - pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", dw->mf); > > - else if (dw->mf == EDMA_MF_HDMA_COMPAT) > > - pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", dw->mf); > > + if (chip->mf == EDMA_MF_EDMA_LEGACY) > > + pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", chip->mf); > > + else if (chip->mf == EDMA_MF_EDMA_UNROLL) > > + pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", chip->mf); > > + else if (chip->mf == EDMA_MF_HDMA_COMPAT) > > + pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", chip->mf); > > else > > - pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", dw->mf); > > + pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", chip->mf); > > > > - pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > + pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", > > vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, > > - dw->rg_region.vaddr, &dw->rg_region.paddr); > > + chip->rg_region.vaddr); > > > > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > > + for (i = 0; i < chip->wr_ch_cnt; i++) { > > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > i, vsec_data.ll_wr[i].bar, > > - vsec_data.ll_wr[i].off, dw->ll_region_wr[i].sz, > > - dw->ll_region_wr[i].vaddr, &dw->ll_region_wr[i].paddr); > > + vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > > + chip->ll_region_wr[i].vaddr, &chip->ll_region_wr[i].paddr); > > > > pci_dbg(pdev, "Data:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > i, vsec_data.dt_wr[i].bar, > > - vsec_data.dt_wr[i].off, dw->dt_region_wr[i].sz, > > - dw->dt_region_wr[i].vaddr, &dw->dt_region_wr[i].paddr); > > + vsec_data.dt_wr[i].off, chip->dt_region_wr[i].sz, > > + chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > > } > > > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > > + for (i = 0; i < chip->rd_ch_cnt; i++) { > > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > i, vsec_data.ll_rd[i].bar, > > - vsec_data.ll_rd[i].off, dw->ll_region_rd[i].sz, > > - dw->ll_region_rd[i].vaddr, &dw->ll_region_rd[i].paddr); > > + vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > > + chip->ll_region_rd[i].vaddr, &chip->ll_region_rd[i].paddr); > > > > pci_dbg(pdev, "Data:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > i, vsec_data.dt_rd[i].bar, > > - vsec_data.dt_rd[i].off, dw->dt_region_rd[i].sz, > > - dw->dt_region_rd[i].vaddr, &dw->dt_region_rd[i].paddr); > > + vsec_data.dt_rd[i].off, chip->dt_region_rd[i].sz, > > + chip->dt_region_rd[i].vaddr, &chip->dt_region_rd[i].paddr); > > } > > > > - pci_dbg(pdev, "Nr. IRQs:\t%u\n", dw->nr_irqs); > > + pci_dbg(pdev, "Nr. IRQs:\t%u\n", chip->nr_irqs); > > > > /* Validating if PCI interrupts were enabled */ > > if (!pci_dev_msi_enabled(pdev)) { > > @@ -345,10 +334,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > return -EPERM; > > } > > > > - dw->irq = devm_kcalloc(dev, nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > > - if (!dw->irq) > > - return -ENOMEM; > > - > > /* Starting eDMA driver */ > > err = dw_edma_probe(chip); > > if (err) { > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > > index 329fc2e57b703..e507e076fad16 100644 > > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > > @@ -25,7 +25,7 @@ enum dw_edma_control { > > > > static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > > { > > - return dw->rg_region.vaddr; > > + return dw->chip->rg_region.vaddr; > > } > > > > #define SET_32(dw, name, value) \ > > @@ -96,7 +96,7 @@ static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > > static inline struct dw_edma_v0_ch_regs __iomem * > > __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > > { > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) > > return &(__dw_regs(dw)->type.legacy.ch); > > > > if (dir == EDMA_DIR_WRITE) > > @@ -108,7 +108,7 @@ __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > > static inline void writel_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > u32 value, void __iomem *addr) > > { > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > u32 viewport_sel; > > unsigned long flags; > > > > @@ -133,7 +133,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > { > > u32 value; > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > u32 viewport_sel; > > unsigned long flags; > > > > @@ -169,7 +169,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > static inline void writeq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > u64 value, void __iomem *addr) > > { > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > u32 viewport_sel; > > unsigned long flags; > > > > @@ -194,7 +194,7 @@ static inline u64 readq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > { > > u32 value; > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > u32 viewport_sel; > > unsigned long flags; > > > > @@ -256,7 +256,7 @@ u16 dw_edma_v0_core_ch_count(struct dw_edma *dw, enum dw_edma_dir dir) > > > > enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > { > > - struct dw_edma *dw = chan->chip->dw; > > + struct dw_edma *dw = chan->dw; > > u32 tmp; > > > > tmp = FIELD_GET(EDMA_V0_CH_STATUS_MASK, > > @@ -272,7 +272,7 @@ enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > > > void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > { > > - struct dw_edma *dw = chan->chip->dw; > > + struct dw_edma *dw = chan->dw; > > > > SET_RW_32(dw, chan->dir, int_clear, > > FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id))); > > @@ -280,7 +280,7 @@ void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > > > void dw_edma_v0_core_clear_abort_int(struct dw_edma_chan *chan) > > { > > - struct dw_edma *dw = chan->chip->dw; > > + struct dw_edma *dw = chan->dw; > > > > SET_RW_32(dw, chan->dir, int_clear, > > FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id))); > > @@ -357,7 +357,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > > void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > { > > struct dw_edma_chan *chan = chunk->chan; > > - struct dw_edma *dw = chan->chip->dw; > > + struct dw_edma *dw = chan->dw; > > u32 tmp; > > > > dw_edma_v0_core_write_chunk(chunk); > > @@ -365,7 +365,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > if (first) { > > /* Enable engine */ > > SET_RW_32(dw, chan->dir, engine_en, BIT(0)); > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > switch (chan->id) { > > case 0: > > SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, > > @@ -431,7 +431,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > > int dw_edma_v0_core_device_config(struct dw_edma_chan *chan) > > { > > - struct dw_edma *dw = chan->chip->dw; > > + struct dw_edma *dw = chan->dw; > > u32 tmp = 0; > > > > /* MSI done addr - low, high */ > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > index 4b3bcffd15ef1..edb7e137cb35a 100644 > > --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > @@ -54,7 +54,7 @@ struct debugfs_entries { > > static int dw_edma_debugfs_u32_get(void *data, u64 *val) > > { > > void __iomem *reg = (void __force __iomem *)data; > > - if (dw->mf == EDMA_MF_EDMA_LEGACY && > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY && > > reg >= (void __iomem *)®s->type.legacy.ch) { > > void __iomem *ptr = ®s->type.legacy.ch; > > u32 viewport_sel = 0; > > @@ -173,7 +173,7 @@ static void dw_edma_debugfs_regs_wr(struct dentry *dir) > > nr_entries = ARRAY_SIZE(debugfs_regs); > > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > > regs_dir); > > @@ -242,7 +242,7 @@ static void dw_edma_debugfs_regs_rd(struct dentry *dir) > > nr_entries = ARRAY_SIZE(debugfs_regs); > > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > > regs_dir); > > @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > > if (!dw) > > return; > > > > - regs = dw->rg_region.vaddr; > > + regs = dw->chip->rg_region.vaddr; > > if (!regs) > > return; > > > > @@ -296,7 +296,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > > if (!dw->debugfs) > > return; > > > > - debugfs_create_u32("mf", 0444, dw->debugfs, &dw->mf); > > + debugfs_create_u32("mf", 0444, dw->debugfs, &dw->chip->mf); > > debugfs_create_u16("wr_ch_cnt", 0444, dw->debugfs, &dw->wr_ch_cnt); > > debugfs_create_u16("rd_ch_cnt", 0444, dw->debugfs, &dw->rd_ch_cnt); > > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > > index cab6e18773dad..a9bee4aeb2eee 100644 > > --- a/include/linux/dma/edma.h > > +++ b/include/linux/dma/edma.h > > @@ -12,19 +12,63 @@ > > #include <linux/device.h> > > #include <linux/dmaengine.h> > > > > +#define EDMA_MAX_WR_CH 8 > > +#define EDMA_MAX_RD_CH 8 > > + > > struct dw_edma; > > > > +struct dw_edma_region { > > + phys_addr_t paddr; > > + void __iomem *vaddr; > > + size_t sz; > > +}; > > + > > +struct dw_edma_core_ops { > > + int (*irq_vector)(struct device *dev, unsigned int nr); > > +}; > > + > > +enum dw_edma_map_format { > > + EDMA_MF_EDMA_LEGACY = 0x0, > > + EDMA_MF_EDMA_UNROLL = 0x1, > > + EDMA_MF_HDMA_COMPAT = 0x5 > > +}; > > + > > /** > > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > > * @dev: struct device of the eDMA controller > > * @id: instance ID > > * @irq: irq line > > + * @nr_irqs: total dma irq number > > + * @ops DMA channel to IRQ number mapping > > + * @wr_ch_cnt DMA write channel number > > + * @rd_ch_cnt DMA read channel number > > + * @rg_region DMA register region > > + * @ll_region_wr DMA descriptor link list memory for write channel > > + * @ll_region_rd DMA descriptor link list memory for read channel > > + * @mf DMA register map format > > * @dw: struct dw_edma that is filed by dw_edma_probe() > > */ > > struct dw_edma_chip { > > struct device *dev; > > int id; > > int irq; > > + int nr_irqs; > > + const struct dw_edma_core_ops *ops; > > + > > + struct dw_edma_region rg_region; > > + > > + u16 wr_ch_cnt; > > + u16 rd_ch_cnt; > > + /* link list address */ > > + struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > + struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > + > > + /* data region */ > > + struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > > + struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > > + > > + enum dw_edma_map_format mf; > > + > > > struct dw_edma *dw; > > Please drop this field from here and just change the dw_edma_probe() > prototype to returning a pointer to the struct dw_edma structure. Like > this: > struct dw_edma *dw_edma_probe(const struct dw_edma_chip *chip); > void dw_edma_remove(struct dw_edma *dw); Actually, I don't think it is good to drop it now. struct dw_edma *dw_edma_probe(const struct dw_edma_chip *chip); Users likely put struct dw_edma_chip in stack. foo() { struct dw_edma_chip chip dw = dw_edma_proble(&chip); } but now, edma_core_driver still does not save chip information to dw_edma > > By doing so we'll be able to have the chip data being const and at least > statically defined. > > -Sergey > > > }; > > > > -- > > 2.24.0.rc1 > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures 2022-03-10 20:29 ` Zhi Li @ 2022-03-11 11:03 ` Serge Semin 2022-03-11 15:29 ` Zhi Li 0 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-11 11:03 UTC (permalink / raw) To: Zhi Li Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Thu, Mar 10, 2022 at 02:29:15PM -0600, Zhi Li wrote: > in > > On Thu, Mar 10, 2022 at 2:20 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > On Wed, Mar 09, 2022 at 03:11:57PM -0600, Frank Li wrote: > > > "struct dw_edma_chip" contains an internal structure "struct dw_edma" that > > > is used by the eDMA core internally. This structure should not be touched > > > by the eDMA controller drivers themselves. But currently, the eDMA > > > controller drivers like "dw-edma-pci" allocates and populates this > > > internal structure then passes it on to eDMA core. The eDMA core further > > > populates the structure and uses it. This is wrong! > > > > > > Hence, move all the "struct dw_edma" specifics from controller drivers > > > to the eDMA core. > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > --- > > > Change from v3 to v4 > > > - Accept most suggestions of Serge Semin > > > Change from v2 to v3 > > > - none > > > Change from v1 to v2 > > > - rework commit message > > > - remove duplicate field in struct dw_edma > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 81 +++++++++++++---------- > > > drivers/dma/dw-edma/dw-edma-core.h | 32 +-------- > > > drivers/dma/dw-edma/dw-edma-pcie.c | 83 ++++++++++-------------- > > > drivers/dma/dw-edma/dw-edma-v0-core.c | 24 +++---- > > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 10 +-- > > > include/linux/dma/edma.h | 44 +++++++++++++ > > > 6 files changed, 144 insertions(+), 130 deletions(-) > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > index 53289927dd0d6..1abf41d49f75b 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > @@ -65,7 +65,7 @@ static struct dw_edma_burst *dw_edma_alloc_burst(struct dw_edma_chunk *chunk) > > > static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > > > { > > > struct dw_edma_chan *chan = desc->chan; > > > - struct dw_edma *dw = chan->chip->dw; > > > + struct dw_edma_chip *chip = chan->dw->chip; > > > struct dw_edma_chunk *chunk; > > > > > > chunk = kzalloc(sizeof(*chunk), GFP_NOWAIT); > > > @@ -82,11 +82,11 @@ static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > > > */ > > > chunk->cb = !(desc->chunks_alloc % 2); > > > if (chan->dir == EDMA_DIR_WRITE) { > > > - chunk->ll_region.paddr = dw->ll_region_wr[chan->id].paddr; > > > - chunk->ll_region.vaddr = dw->ll_region_wr[chan->id].vaddr; > > > + chunk->ll_region.paddr = chip->ll_region_wr[chan->id].paddr; > > > + chunk->ll_region.vaddr = chip->ll_region_wr[chan->id].vaddr; > > > } else { > > > - chunk->ll_region.paddr = dw->ll_region_rd[chan->id].paddr; > > > - chunk->ll_region.vaddr = dw->ll_region_rd[chan->id].vaddr; > > > + chunk->ll_region.paddr = chip->ll_region_rd[chan->id].paddr; > > > + chunk->ll_region.vaddr = chip->ll_region_rd[chan->id].vaddr; > > > } > > > > > > if (desc->chunk) { > > > @@ -664,7 +664,7 @@ static int dw_edma_alloc_chan_resources(struct dma_chan *dchan) > > > if (chan->status != EDMA_ST_IDLE) > > > return -EBUSY; > > > > > > - pm_runtime_get(chan->chip->dev); > > > + pm_runtime_get(chan->dw->chip->dev); > > > > > > return 0; > > > } > > > @@ -686,7 +686,7 @@ static void dw_edma_free_chan_resources(struct dma_chan *dchan) > > > cpu_relax(); > > > } > > > > > > - pm_runtime_put(chan->chip->dev); > > > + pm_runtime_put(chan->dw->chip->dev); > > > } > > > > > > static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > @@ -718,7 +718,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > } > > > > > > INIT_LIST_HEAD(&dma->channels); > > > - for (j = 0; (alloc || dw->nr_irqs == 1) && j < cnt; j++, i++) { > > > + for (j = 0; (alloc || chip->nr_irqs == 1) && j < cnt; j++, i++) { > > > chan = &dw->chan[i]; > > > > > > dt_region = devm_kzalloc(dev, sizeof(*dt_region), GFP_KERNEL); > > > @@ -727,7 +727,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > > > chan->vc.chan.private = dt_region; > > > > > > - chan->chip = chip; > > > + chan->dw = dw; > > > chan->id = j; > > > chan->dir = write ? EDMA_DIR_WRITE : EDMA_DIR_READ; > > > chan->configured = false; > > > @@ -735,15 +735,15 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > chan->status = EDMA_ST_IDLE; > > > > > > if (write) > > > - chan->ll_max = (dw->ll_region_wr[j].sz / EDMA_LL_SZ); > > > + chan->ll_max = (chip->ll_region_wr[j].sz / EDMA_LL_SZ); > > > else > > > - chan->ll_max = (dw->ll_region_rd[j].sz / EDMA_LL_SZ); > > > + chan->ll_max = (chip->ll_region_rd[j].sz / EDMA_LL_SZ); > > > chan->ll_max -= 1; > > > > > > dev_vdbg(dev, "L. List:\tChannel %s[%u] max_cnt=%u\n", > > > write ? "write" : "read", j, chan->ll_max); > > > > > > - if (dw->nr_irqs == 1) > > > + if (chip->nr_irqs == 1) > > > pos = 0; > > > else > > > pos = off_alloc + (j % alloc); > > > @@ -767,13 +767,13 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > vchan_init(&chan->vc, dma); > > > > > > if (write) { > > > - dt_region->paddr = dw->dt_region_wr[j].paddr; > > > - dt_region->vaddr = dw->dt_region_wr[j].vaddr; > > > - dt_region->sz = dw->dt_region_wr[j].sz; > > > + dt_region->paddr = chip->dt_region_wr[j].paddr; > > > + dt_region->vaddr = chip->dt_region_wr[j].vaddr; > > > + dt_region->sz = chip->dt_region_wr[j].sz; > > > } else { > > > - dt_region->paddr = dw->dt_region_rd[j].paddr; > > > - dt_region->vaddr = dw->dt_region_rd[j].vaddr; > > > - dt_region->sz = dw->dt_region_rd[j].sz; > > > + dt_region->paddr = chip->dt_region_rd[j].paddr; > > > + dt_region->vaddr = chip->dt_region_rd[j].vaddr; > > > + dt_region->sz = chip->dt_region_rd[j].sz; > > > } > > > > > > dw_edma_v0_core_device_config(chan); > > > @@ -840,16 +840,16 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > > > ch_cnt = dw->wr_ch_cnt + dw->rd_ch_cnt; > > > > > > - if (dw->nr_irqs < 1) > > > + if (chip->nr_irqs < 1) > > > return -EINVAL; > > > > > > - if (dw->nr_irqs == 1) { > > > + if (chip->nr_irqs == 1) { > > > /* Common IRQ shared among all channels */ > > > - irq = dw->ops->irq_vector(dev, 0); > > > + irq = chip->ops->irq_vector(dev, 0); > > > err = request_irq(irq, dw_edma_interrupt_common, > > > IRQF_SHARED, dw->name, &dw->irq[0]); > > > if (err) { > > > - dw->nr_irqs = 0; > > > + chip->nr_irqs = 0; > > > return err; > > > } > > > > > > @@ -857,7 +857,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > get_cached_msi_msg(irq, &dw->irq[0].msi); > > > } else { > > > /* Distribute IRQs equally among all channels */ > > > - int tmp = dw->nr_irqs; > > > + int tmp = chip->nr_irqs; > > > > > > while (tmp && (*wr_alloc + *rd_alloc) < ch_cnt) { > > > dw_edma_dec_irq_alloc(&tmp, wr_alloc, dw->wr_ch_cnt); > > > @@ -868,7 +868,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > dw_edma_add_irq_mask(&rd_mask, *rd_alloc, dw->rd_ch_cnt); > > > > > > for (i = 0; i < (*wr_alloc + *rd_alloc); i++) { > > > - irq = dw->ops->irq_vector(dev, i); > > > + irq = chip->ops->irq_vector(dev, i); > > > err = request_irq(irq, > > > i < *wr_alloc ? > > > dw_edma_interrupt_write : > > > @@ -876,7 +876,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > IRQF_SHARED, dw->name, > > > &dw->irq[i]); > > > if (err) { > > > - dw->nr_irqs = i; > > > + chip->nr_irqs = i; > > > return err; > > > } > > > > > > @@ -884,7 +884,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > get_cached_msi_msg(irq, &dw->irq[i].msi); > > > } > > > > > > - dw->nr_irqs = i; > > > + chip->nr_irqs = i; > > > } > > > > > > return err; > > > @@ -905,17 +905,24 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > if (!dev) > > > return -EINVAL; > > > > > > - dw = chip->dw; > > > - if (!dw || !dw->irq || !dw->ops || !dw->ops->irq_vector) > > > + dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > > > + if (!dw) > > > + return -ENOMEM; > > > + > > > + chip->dw = dw; > > > + dw->chip = chip; > > > + > > > + if (!chip->nr_irqs || !chip->ops) > > > return -EINVAL; > > > > > > raw_spin_lock_init(&dw->lock); > > > > > > - dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, > > > + > > > + dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > > > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > > > > > - dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, > > > + dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > > > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > > > > > @@ -936,6 +943,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > /* Disable eDMA, only to establish the ideal initial conditions */ > > > dw_edma_v0_core_off(dw); > > > > > > + dw->irq = devm_kcalloc(dev, chip->nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > > > + if (!dw->irq) > > > + return -ENOMEM; > > > + > > > /* Request IRQs */ > > > err = dw_edma_irq_request(chip, &wr_alloc, &rd_alloc); > > > if (err) > > > @@ -960,10 +971,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > return 0; > > > > > > err_irq_free: > > > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > > > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > > > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > > > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > > > > > - dw->nr_irqs = 0; > > > + chip->nr_irqs = 0; > > > > > > return err; > > > } > > > @@ -980,8 +991,8 @@ int dw_edma_remove(struct dw_edma_chip *chip) > > > dw_edma_v0_core_off(dw); > > > > > > /* Free irqs */ > > > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > > > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > > > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > > > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > > > > > /* Power management */ > > > pm_runtime_disable(dev); > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h > > > index 60316d408c3e0..e254c2fc3d9cf 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-core.h > > > +++ b/drivers/dma/dw-edma/dw-edma-core.h > > > @@ -15,20 +15,12 @@ > > > #include "../virt-dma.h" > > > > > > #define EDMA_LL_SZ 24 > > > -#define EDMA_MAX_WR_CH 8 > > > -#define EDMA_MAX_RD_CH 8 > > > > > > enum dw_edma_dir { > > > EDMA_DIR_WRITE = 0, > > > EDMA_DIR_READ > > > }; > > > > > > -enum dw_edma_map_format { > > > - EDMA_MF_EDMA_LEGACY = 0x0, > > > - EDMA_MF_EDMA_UNROLL = 0x1, > > > - EDMA_MF_HDMA_COMPAT = 0x5 > > > -}; > > > - > > > enum dw_edma_request { > > > EDMA_REQ_NONE = 0, > > > EDMA_REQ_STOP, > > > @@ -57,12 +49,6 @@ struct dw_edma_burst { > > > u32 sz; > > > }; > > > > > > -struct dw_edma_region { > > > - phys_addr_t paddr; > > > - void __iomem *vaddr; > > > - size_t sz; > > > -}; > > > - > > > struct dw_edma_chunk { > > > struct list_head list; > > > struct dw_edma_chan *chan; > > > @@ -87,7 +73,7 @@ struct dw_edma_desc { > > > > > > struct dw_edma_chan { > > > struct virt_dma_chan vc; > > > - struct dw_edma_chip *chip; > > > + struct dw_edma *dw; > > > int id; > > > enum dw_edma_dir dir; > > > > > > @@ -109,10 +95,6 @@ struct dw_edma_irq { > > > struct dw_edma *dw; > > > }; > > > > > > -struct dw_edma_core_ops { > > > - int (*irq_vector)(struct device *dev, unsigned int nr); > > > -}; > > > - > > > struct dw_edma { > > > char name[20]; > > > > > > @@ -122,21 +104,13 @@ struct dw_edma { > > > struct dma_device rd_edma; > > > u16 rd_ch_cnt; > > > > > > - struct dw_edma_region rg_region; /* Registers */ > > > - struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > > - struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > > - struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > > > - struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > > > - > > > struct dw_edma_irq *irq; > > > - int nr_irqs; > > > - > > > - enum dw_edma_map_format mf; > > > > > > struct dw_edma_chan *chan; > > > - const struct dw_edma_core_ops *ops; > > > > > > raw_spinlock_t lock; /* Only for legacy */ > > > + > > > + struct dw_edma_chip *chip; > > > #ifdef CONFIG_DEBUG_FS > > > struct dentry *debugfs; > > > #endif /* CONFIG_DEBUG_FS */ > > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > > > index 44f6e09bdb531..2c1c5fa4e9f28 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > > > @@ -148,7 +148,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > struct dw_edma_pcie_data vsec_data; > > > struct device *dev = &pdev->dev; > > > struct dw_edma_chip *chip; > > > - struct dw_edma *dw; > > > int err, nr_irqs; > > > int i, mask; > > > > > > @@ -214,10 +213,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > if (!chip) > > > return -ENOMEM; > > > > > > - dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > > > - if (!dw) > > > - return -ENOMEM; > > > - > > > /* IRQs allocation */ > > > nr_irqs = pci_alloc_irq_vectors(pdev, 1, vsec_data.irqs, > > > PCI_IRQ_MSI | PCI_IRQ_MSIX); > > > @@ -228,29 +223,23 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > } > > > > > > /* Data structure initialization */ > > > - chip->dw = dw; > > > chip->dev = dev; > > > chip->id = pdev->devfn; > > > - chip->irq = pdev->irq; > > > > > > - dw->mf = vsec_data.mf; > > > - dw->nr_irqs = nr_irqs; > > > - dw->ops = &dw_edma_pcie_core_ops; > > > - dw->wr_ch_cnt = vsec_data.wr_ch_cnt; > > > - dw->rd_ch_cnt = vsec_data.rd_ch_cnt; > > > + chip->mf = vsec_data.mf; > > > + chip->nr_irqs = nr_irqs; > > > + chip->ops = &dw_edma_pcie_core_ops; > > > > > > - dw->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > > - if (!dw->rg_region.vaddr) > > > - return -ENOMEM; > > > + chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > > > + chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > > > > > - dw->rg_region.vaddr += vsec_data.rg.off; > > > - dw->rg_region.paddr = pdev->resource[vsec_data.rg.bar].start; > > > - dw->rg_region.paddr += vsec_data.rg.off; > > > - dw->rg_region.sz = vsec_data.rg.sz; > > > + chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > > + if (!chip->rg_region.vaddr) > > > + return -ENOMEM; > > > > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > > > - struct dw_edma_region *ll_region = &dw->ll_region_wr[i]; > > > - struct dw_edma_region *dt_region = &dw->dt_region_wr[i]; > > > + for (i = 0; i < chip->wr_ch_cnt; i++) { > > > + struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > > > + struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > > > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > > > struct dw_edma_block *dt_block = &vsec_data.dt_wr[i]; > > > > > > @@ -273,9 +262,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > dt_region->sz = dt_block->sz; > > > } > > > > > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > > > - struct dw_edma_region *ll_region = &dw->ll_region_rd[i]; > > > - struct dw_edma_region *dt_region = &dw->dt_region_rd[i]; > > > + for (i = 0; i < chip->rd_ch_cnt; i++) { > > > + struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > > > + struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > > > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > > > struct dw_edma_block *dt_block = &vsec_data.dt_rd[i]; > > > > > > @@ -299,45 +288,45 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > } > > > > > > /* Debug info */ > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > > > - pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", dw->mf); > > > - else if (dw->mf == EDMA_MF_EDMA_UNROLL) > > > - pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", dw->mf); > > > - else if (dw->mf == EDMA_MF_HDMA_COMPAT) > > > - pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", dw->mf); > > > + if (chip->mf == EDMA_MF_EDMA_LEGACY) > > > + pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", chip->mf); > > > + else if (chip->mf == EDMA_MF_EDMA_UNROLL) > > > + pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", chip->mf); > > > + else if (chip->mf == EDMA_MF_HDMA_COMPAT) > > > + pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", chip->mf); > > > else > > > - pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", dw->mf); > > > + pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", chip->mf); > > > > > > - pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > + pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", > > > vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, > > > - dw->rg_region.vaddr, &dw->rg_region.paddr); > > > + chip->rg_region.vaddr); > > > > > > > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > > > + for (i = 0; i < chip->wr_ch_cnt; i++) { > > > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > i, vsec_data.ll_wr[i].bar, > > > - vsec_data.ll_wr[i].off, dw->ll_region_wr[i].sz, > > > - dw->ll_region_wr[i].vaddr, &dw->ll_region_wr[i].paddr); > > > + vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > > > + chip->ll_region_wr[i].vaddr, &chip->ll_region_wr[i].paddr); > > > > > > pci_dbg(pdev, "Data:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > i, vsec_data.dt_wr[i].bar, > > > - vsec_data.dt_wr[i].off, dw->dt_region_wr[i].sz, > > > - dw->dt_region_wr[i].vaddr, &dw->dt_region_wr[i].paddr); > > > + vsec_data.dt_wr[i].off, chip->dt_region_wr[i].sz, > > > + chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > > > } > > > > > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > > > + for (i = 0; i < chip->rd_ch_cnt; i++) { > > > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > i, vsec_data.ll_rd[i].bar, > > > - vsec_data.ll_rd[i].off, dw->ll_region_rd[i].sz, > > > - dw->ll_region_rd[i].vaddr, &dw->ll_region_rd[i].paddr); > > > + vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > > > + chip->ll_region_rd[i].vaddr, &chip->ll_region_rd[i].paddr); > > > > > > pci_dbg(pdev, "Data:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > i, vsec_data.dt_rd[i].bar, > > > - vsec_data.dt_rd[i].off, dw->dt_region_rd[i].sz, > > > - dw->dt_region_rd[i].vaddr, &dw->dt_region_rd[i].paddr); > > > + vsec_data.dt_rd[i].off, chip->dt_region_rd[i].sz, > > > + chip->dt_region_rd[i].vaddr, &chip->dt_region_rd[i].paddr); > > > } > > > > > > - pci_dbg(pdev, "Nr. IRQs:\t%u\n", dw->nr_irqs); > > > + pci_dbg(pdev, "Nr. IRQs:\t%u\n", chip->nr_irqs); > > > > > > /* Validating if PCI interrupts were enabled */ > > > if (!pci_dev_msi_enabled(pdev)) { > > > @@ -345,10 +334,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > return -EPERM; > > > } > > > > > > - dw->irq = devm_kcalloc(dev, nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > > > - if (!dw->irq) > > > - return -ENOMEM; > > > - > > > /* Starting eDMA driver */ > > > err = dw_edma_probe(chip); > > > if (err) { > > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > > > index 329fc2e57b703..e507e076fad16 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > > > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > > > @@ -25,7 +25,7 @@ enum dw_edma_control { > > > > > > static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > > > { > > > - return dw->rg_region.vaddr; > > > + return dw->chip->rg_region.vaddr; > > > } > > > > > > #define SET_32(dw, name, value) \ > > > @@ -96,7 +96,7 @@ static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > > > static inline struct dw_edma_v0_ch_regs __iomem * > > > __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > > > { > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) > > > return &(__dw_regs(dw)->type.legacy.ch); > > > > > > if (dir == EDMA_DIR_WRITE) > > > @@ -108,7 +108,7 @@ __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > > > static inline void writel_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > u32 value, void __iomem *addr) > > > { > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > u32 viewport_sel; > > > unsigned long flags; > > > > > > @@ -133,7 +133,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > { > > > u32 value; > > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > u32 viewport_sel; > > > unsigned long flags; > > > > > > @@ -169,7 +169,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > static inline void writeq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > u64 value, void __iomem *addr) > > > { > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > u32 viewport_sel; > > > unsigned long flags; > > > > > > @@ -194,7 +194,7 @@ static inline u64 readq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > { > > > u32 value; > > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > u32 viewport_sel; > > > unsigned long flags; > > > > > > @@ -256,7 +256,7 @@ u16 dw_edma_v0_core_ch_count(struct dw_edma *dw, enum dw_edma_dir dir) > > > > > > enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > > { > > > - struct dw_edma *dw = chan->chip->dw; > > > + struct dw_edma *dw = chan->dw; > > > u32 tmp; > > > > > > tmp = FIELD_GET(EDMA_V0_CH_STATUS_MASK, > > > @@ -272,7 +272,7 @@ enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > > > > > void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > > { > > > - struct dw_edma *dw = chan->chip->dw; > > > + struct dw_edma *dw = chan->dw; > > > > > > SET_RW_32(dw, chan->dir, int_clear, > > > FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id))); > > > @@ -280,7 +280,7 @@ void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > > > > > void dw_edma_v0_core_clear_abort_int(struct dw_edma_chan *chan) > > > { > > > - struct dw_edma *dw = chan->chip->dw; > > > + struct dw_edma *dw = chan->dw; > > > > > > SET_RW_32(dw, chan->dir, int_clear, > > > FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id))); > > > @@ -357,7 +357,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > > > void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > { > > > struct dw_edma_chan *chan = chunk->chan; > > > - struct dw_edma *dw = chan->chip->dw; > > > + struct dw_edma *dw = chan->dw; > > > u32 tmp; > > > > > > dw_edma_v0_core_write_chunk(chunk); > > > @@ -365,7 +365,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > if (first) { > > > /* Enable engine */ > > > SET_RW_32(dw, chan->dir, engine_en, BIT(0)); > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > > switch (chan->id) { > > > case 0: > > > SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, > > > @@ -431,7 +431,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > > > > int dw_edma_v0_core_device_config(struct dw_edma_chan *chan) > > > { > > > - struct dw_edma *dw = chan->chip->dw; > > > + struct dw_edma *dw = chan->dw; > > > u32 tmp = 0; > > > > > > /* MSI done addr - low, high */ > > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > > index 4b3bcffd15ef1..edb7e137cb35a 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > > +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > > @@ -54,7 +54,7 @@ struct debugfs_entries { > > > static int dw_edma_debugfs_u32_get(void *data, u64 *val) > > > { > > > void __iomem *reg = (void __force __iomem *)data; > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY && > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY && > > > reg >= (void __iomem *)®s->type.legacy.ch) { > > > void __iomem *ptr = ®s->type.legacy.ch; > > > u32 viewport_sel = 0; > > > @@ -173,7 +173,7 @@ static void dw_edma_debugfs_regs_wr(struct dentry *dir) > > > nr_entries = ARRAY_SIZE(debugfs_regs); > > > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > > > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > > > regs_dir); > > > @@ -242,7 +242,7 @@ static void dw_edma_debugfs_regs_rd(struct dentry *dir) > > > nr_entries = ARRAY_SIZE(debugfs_regs); > > > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > > > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > > > regs_dir); > > > @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > > > if (!dw) > > > return; > > > > > > - regs = dw->rg_region.vaddr; > > > + regs = dw->chip->rg_region.vaddr; > > > if (!regs) > > > return; > > > > > > @@ -296,7 +296,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > > > if (!dw->debugfs) > > > return; > > > > > > - debugfs_create_u32("mf", 0444, dw->debugfs, &dw->mf); > > > + debugfs_create_u32("mf", 0444, dw->debugfs, &dw->chip->mf); > > > debugfs_create_u16("wr_ch_cnt", 0444, dw->debugfs, &dw->wr_ch_cnt); > > > debugfs_create_u16("rd_ch_cnt", 0444, dw->debugfs, &dw->rd_ch_cnt); > > > > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > > > index cab6e18773dad..a9bee4aeb2eee 100644 > > > --- a/include/linux/dma/edma.h > > > +++ b/include/linux/dma/edma.h > > > @@ -12,19 +12,63 @@ > > > #include <linux/device.h> > > > #include <linux/dmaengine.h> > > > > > > +#define EDMA_MAX_WR_CH 8 > > > +#define EDMA_MAX_RD_CH 8 > > > + > > > struct dw_edma; > > > > > > +struct dw_edma_region { > > > + phys_addr_t paddr; > > > + void __iomem *vaddr; > > > + size_t sz; > > > +}; > > > + > > > +struct dw_edma_core_ops { > > > + int (*irq_vector)(struct device *dev, unsigned int nr); > > > +}; > > > + > > > +enum dw_edma_map_format { > > > + EDMA_MF_EDMA_LEGACY = 0x0, > > > + EDMA_MF_EDMA_UNROLL = 0x1, > > > + EDMA_MF_HDMA_COMPAT = 0x5 > > > +}; > > > + > > > /** > > > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > > > * @dev: struct device of the eDMA controller > > > * @id: instance ID > > > * @irq: irq line > > > + * @nr_irqs: total dma irq number > > > + * @ops DMA channel to IRQ number mapping > > > + * @wr_ch_cnt DMA write channel number > > > + * @rd_ch_cnt DMA read channel number > > > + * @rg_region DMA register region > > > + * @ll_region_wr DMA descriptor link list memory for write channel > > > + * @ll_region_rd DMA descriptor link list memory for read channel > > > + * @mf DMA register map format > > > * @dw: struct dw_edma that is filed by dw_edma_probe() > > > */ > > > struct dw_edma_chip { > > > struct device *dev; > > > int id; > > > int irq; > > > + int nr_irqs; > > > + const struct dw_edma_core_ops *ops; > > > + > > > + struct dw_edma_region rg_region; > > > + > > > + u16 wr_ch_cnt; > > > + u16 rd_ch_cnt; > > > + /* link list address */ > > > + struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > > + struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > > + > > > + /* data region */ > > > + struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > > > + struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > > > + > > > + enum dw_edma_map_format mf; > > > + > > > > > struct dw_edma *dw; > > > > Please drop this field from here and just change the dw_edma_probe() > > prototype to returning a pointer to the struct dw_edma structure. Like > > this: > > struct dw_edma *dw_edma_probe(const struct dw_edma_chip *chip); > > void dw_edma_remove(struct dw_edma *dw); > > Actually, I don't think it is good to drop it now. > > struct dw_edma *dw_edma_probe(const struct dw_edma_chip *chip); > > Users likely put struct dw_edma_chip in stack. > foo() > { > struct dw_edma_chip chip > dw = dw_edma_proble(&chip); > } > > but now, edma_core_driver still does not save chip information to dw_edma Neither current implementation nor implementation suggested by me permits having the struct dw_edma_chip structure instance allocated on stack, since the pointer to the structure is then preserved in the dw_edma all the way until the device/driver isn't removed (it will require some more modifications, which I can't request from you). What approach proposed by me provides is a way to statically define the struct dw_edma_chip object. Seeing the eDMA driver doesn't change the structure fields we can extend the API functionality. In this case the probe()/remote() methods semantics turns to be cleaner and looking more like the i2c-board-info design. That we'll be able to gain almost with no much efforts. Just fix the dw_edma_probe()/dw_edma_remove() method prototype as I suggested (Don't forget the const-modifier in the probe argument and in the dw_edma.dw field). -Sergey > > > > > By doing so we'll be able to have the chip data being const and at least > > statically defined. > > > > -Sergey > > > > > }; > > > > > > -- > > > 2.24.0.rc1 > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures 2022-03-11 11:03 ` Serge Semin @ 2022-03-11 15:29 ` Zhi Li 2022-03-12 19:56 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-11 15:29 UTC (permalink / raw) To: Serge Semin Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Fri, Mar 11, 2022 at 5:03 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > On Thu, Mar 10, 2022 at 02:29:15PM -0600, Zhi Li wrote: > > in > > > > On Thu, Mar 10, 2022 at 2:20 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > On Wed, Mar 09, 2022 at 03:11:57PM -0600, Frank Li wrote: > > > > "struct dw_edma_chip" contains an internal structure "struct dw_edma" that > > > > is used by the eDMA core internally. This structure should not be touched > > > > by the eDMA controller drivers themselves. But currently, the eDMA > > > > controller drivers like "dw-edma-pci" allocates and populates this > > > > internal structure then passes it on to eDMA core. The eDMA core further > > > > populates the structure and uses it. This is wrong! > > > > > > > > Hence, move all the "struct dw_edma" specifics from controller drivers > > > > to the eDMA core. > > > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > --- > > > > Change from v3 to v4 > > > > - Accept most suggestions of Serge Semin > > > > Change from v2 to v3 > > > > - none > > > > Change from v1 to v2 > > > > - rework commit message > > > > - remove duplicate field in struct dw_edma > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 81 +++++++++++++---------- > > > > drivers/dma/dw-edma/dw-edma-core.h | 32 +-------- > > > > drivers/dma/dw-edma/dw-edma-pcie.c | 83 ++++++++++-------------- > > > > drivers/dma/dw-edma/dw-edma-v0-core.c | 24 +++---- > > > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 10 +-- > > > > include/linux/dma/edma.h | 44 +++++++++++++ > > > > 6 files changed, 144 insertions(+), 130 deletions(-) > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > index 53289927dd0d6..1abf41d49f75b 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > @@ -65,7 +65,7 @@ static struct dw_edma_burst *dw_edma_alloc_burst(struct dw_edma_chunk *chunk) > > > > static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > > > > { > > > > struct dw_edma_chan *chan = desc->chan; > > > > - struct dw_edma *dw = chan->chip->dw; > > > > + struct dw_edma_chip *chip = chan->dw->chip; > > > > struct dw_edma_chunk *chunk; > > > > > > > > chunk = kzalloc(sizeof(*chunk), GFP_NOWAIT); > > > > @@ -82,11 +82,11 @@ static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > > > > */ > > > > chunk->cb = !(desc->chunks_alloc % 2); > > > > if (chan->dir == EDMA_DIR_WRITE) { > > > > - chunk->ll_region.paddr = dw->ll_region_wr[chan->id].paddr; > > > > - chunk->ll_region.vaddr = dw->ll_region_wr[chan->id].vaddr; > > > > + chunk->ll_region.paddr = chip->ll_region_wr[chan->id].paddr; > > > > + chunk->ll_region.vaddr = chip->ll_region_wr[chan->id].vaddr; > > > > } else { > > > > - chunk->ll_region.paddr = dw->ll_region_rd[chan->id].paddr; > > > > - chunk->ll_region.vaddr = dw->ll_region_rd[chan->id].vaddr; > > > > + chunk->ll_region.paddr = chip->ll_region_rd[chan->id].paddr; > > > > + chunk->ll_region.vaddr = chip->ll_region_rd[chan->id].vaddr; > > > > } > > > > > > > > if (desc->chunk) { > > > > @@ -664,7 +664,7 @@ static int dw_edma_alloc_chan_resources(struct dma_chan *dchan) > > > > if (chan->status != EDMA_ST_IDLE) > > > > return -EBUSY; > > > > > > > > - pm_runtime_get(chan->chip->dev); > > > > + pm_runtime_get(chan->dw->chip->dev); > > > > > > > > return 0; > > > > } > > > > @@ -686,7 +686,7 @@ static void dw_edma_free_chan_resources(struct dma_chan *dchan) > > > > cpu_relax(); > > > > } > > > > > > > > - pm_runtime_put(chan->chip->dev); > > > > + pm_runtime_put(chan->dw->chip->dev); > > > > } > > > > > > > > static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > @@ -718,7 +718,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > } > > > > > > > > INIT_LIST_HEAD(&dma->channels); > > > > - for (j = 0; (alloc || dw->nr_irqs == 1) && j < cnt; j++, i++) { > > > > + for (j = 0; (alloc || chip->nr_irqs == 1) && j < cnt; j++, i++) { > > > > chan = &dw->chan[i]; > > > > > > > > dt_region = devm_kzalloc(dev, sizeof(*dt_region), GFP_KERNEL); > > > > @@ -727,7 +727,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > > > > > chan->vc.chan.private = dt_region; > > > > > > > > - chan->chip = chip; > > > > + chan->dw = dw; > > > > chan->id = j; > > > > chan->dir = write ? EDMA_DIR_WRITE : EDMA_DIR_READ; > > > > chan->configured = false; > > > > @@ -735,15 +735,15 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > chan->status = EDMA_ST_IDLE; > > > > > > > > if (write) > > > > - chan->ll_max = (dw->ll_region_wr[j].sz / EDMA_LL_SZ); > > > > + chan->ll_max = (chip->ll_region_wr[j].sz / EDMA_LL_SZ); > > > > else > > > > - chan->ll_max = (dw->ll_region_rd[j].sz / EDMA_LL_SZ); > > > > + chan->ll_max = (chip->ll_region_rd[j].sz / EDMA_LL_SZ); > > > > chan->ll_max -= 1; > > > > > > > > dev_vdbg(dev, "L. List:\tChannel %s[%u] max_cnt=%u\n", > > > > write ? "write" : "read", j, chan->ll_max); > > > > > > > > - if (dw->nr_irqs == 1) > > > > + if (chip->nr_irqs == 1) > > > > pos = 0; > > > > else > > > > pos = off_alloc + (j % alloc); > > > > @@ -767,13 +767,13 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > vchan_init(&chan->vc, dma); > > > > > > > > if (write) { > > > > - dt_region->paddr = dw->dt_region_wr[j].paddr; > > > > - dt_region->vaddr = dw->dt_region_wr[j].vaddr; > > > > - dt_region->sz = dw->dt_region_wr[j].sz; > > > > + dt_region->paddr = chip->dt_region_wr[j].paddr; > > > > + dt_region->vaddr = chip->dt_region_wr[j].vaddr; > > > > + dt_region->sz = chip->dt_region_wr[j].sz; > > > > } else { > > > > - dt_region->paddr = dw->dt_region_rd[j].paddr; > > > > - dt_region->vaddr = dw->dt_region_rd[j].vaddr; > > > > - dt_region->sz = dw->dt_region_rd[j].sz; > > > > + dt_region->paddr = chip->dt_region_rd[j].paddr; > > > > + dt_region->vaddr = chip->dt_region_rd[j].vaddr; > > > > + dt_region->sz = chip->dt_region_rd[j].sz; > > > > } > > > > > > > > dw_edma_v0_core_device_config(chan); > > > > @@ -840,16 +840,16 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > > > > > ch_cnt = dw->wr_ch_cnt + dw->rd_ch_cnt; > > > > > > > > - if (dw->nr_irqs < 1) > > > > + if (chip->nr_irqs < 1) > > > > return -EINVAL; > > > > > > > > - if (dw->nr_irqs == 1) { > > > > + if (chip->nr_irqs == 1) { > > > > /* Common IRQ shared among all channels */ > > > > - irq = dw->ops->irq_vector(dev, 0); > > > > + irq = chip->ops->irq_vector(dev, 0); > > > > err = request_irq(irq, dw_edma_interrupt_common, > > > > IRQF_SHARED, dw->name, &dw->irq[0]); > > > > if (err) { > > > > - dw->nr_irqs = 0; > > > > + chip->nr_irqs = 0; > > > > return err; > > > > } > > > > > > > > @@ -857,7 +857,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > get_cached_msi_msg(irq, &dw->irq[0].msi); > > > > } else { > > > > /* Distribute IRQs equally among all channels */ > > > > - int tmp = dw->nr_irqs; > > > > + int tmp = chip->nr_irqs; > > > > > > > > while (tmp && (*wr_alloc + *rd_alloc) < ch_cnt) { > > > > dw_edma_dec_irq_alloc(&tmp, wr_alloc, dw->wr_ch_cnt); > > > > @@ -868,7 +868,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > dw_edma_add_irq_mask(&rd_mask, *rd_alloc, dw->rd_ch_cnt); > > > > > > > > for (i = 0; i < (*wr_alloc + *rd_alloc); i++) { > > > > - irq = dw->ops->irq_vector(dev, i); > > > > + irq = chip->ops->irq_vector(dev, i); > > > > err = request_irq(irq, > > > > i < *wr_alloc ? > > > > dw_edma_interrupt_write : > > > > @@ -876,7 +876,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > IRQF_SHARED, dw->name, > > > > &dw->irq[i]); > > > > if (err) { > > > > - dw->nr_irqs = i; > > > > + chip->nr_irqs = i; > > > > return err; > > > > } > > > > > > > > @@ -884,7 +884,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > get_cached_msi_msg(irq, &dw->irq[i].msi); > > > > } > > > > > > > > - dw->nr_irqs = i; > > > > + chip->nr_irqs = i; > > > > } > > > > > > > > return err; > > > > @@ -905,17 +905,24 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > > if (!dev) > > > > return -EINVAL; > > > > > > > > - dw = chip->dw; > > > > - if (!dw || !dw->irq || !dw->ops || !dw->ops->irq_vector) > > > > + dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > > > > + if (!dw) > > > > + return -ENOMEM; > > > > + > > > > + chip->dw = dw; > > > > + dw->chip = chip; > > > > + > > > > + if (!chip->nr_irqs || !chip->ops) > > > > return -EINVAL; > > > > > > > > raw_spin_lock_init(&dw->lock); > > > > > > > > - dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, > > > > + > > > > + dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > > > > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > > > > > > > - dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, > > > > + dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > > > > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > > > > > > > @@ -936,6 +943,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > > /* Disable eDMA, only to establish the ideal initial conditions */ > > > > dw_edma_v0_core_off(dw); > > > > > > > > + dw->irq = devm_kcalloc(dev, chip->nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > > > > + if (!dw->irq) > > > > + return -ENOMEM; > > > > + > > > > /* Request IRQs */ > > > > err = dw_edma_irq_request(chip, &wr_alloc, &rd_alloc); > > > > if (err) > > > > @@ -960,10 +971,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > > return 0; > > > > > > > > err_irq_free: > > > > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > > > > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > > > > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > > > > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > > > > > > > - dw->nr_irqs = 0; > > > > + chip->nr_irqs = 0; > > > > > > > > return err; > > > > } > > > > @@ -980,8 +991,8 @@ int dw_edma_remove(struct dw_edma_chip *chip) > > > > dw_edma_v0_core_off(dw); > > > > > > > > /* Free irqs */ > > > > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > > > > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > > > > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > > > > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > > > > > > > /* Power management */ > > > > pm_runtime_disable(dev); > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h > > > > index 60316d408c3e0..e254c2fc3d9cf 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-core.h > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.h > > > > @@ -15,20 +15,12 @@ > > > > #include "../virt-dma.h" > > > > > > > > #define EDMA_LL_SZ 24 > > > > -#define EDMA_MAX_WR_CH 8 > > > > -#define EDMA_MAX_RD_CH 8 > > > > > > > > enum dw_edma_dir { > > > > EDMA_DIR_WRITE = 0, > > > > EDMA_DIR_READ > > > > }; > > > > > > > > -enum dw_edma_map_format { > > > > - EDMA_MF_EDMA_LEGACY = 0x0, > > > > - EDMA_MF_EDMA_UNROLL = 0x1, > > > > - EDMA_MF_HDMA_COMPAT = 0x5 > > > > -}; > > > > - > > > > enum dw_edma_request { > > > > EDMA_REQ_NONE = 0, > > > > EDMA_REQ_STOP, > > > > @@ -57,12 +49,6 @@ struct dw_edma_burst { > > > > u32 sz; > > > > }; > > > > > > > > -struct dw_edma_region { > > > > - phys_addr_t paddr; > > > > - void __iomem *vaddr; > > > > - size_t sz; > > > > -}; > > > > - > > > > struct dw_edma_chunk { > > > > struct list_head list; > > > > struct dw_edma_chan *chan; > > > > @@ -87,7 +73,7 @@ struct dw_edma_desc { > > > > > > > > struct dw_edma_chan { > > > > struct virt_dma_chan vc; > > > > - struct dw_edma_chip *chip; > > > > + struct dw_edma *dw; > > > > int id; > > > > enum dw_edma_dir dir; > > > > > > > > @@ -109,10 +95,6 @@ struct dw_edma_irq { > > > > struct dw_edma *dw; > > > > }; > > > > > > > > -struct dw_edma_core_ops { > > > > - int (*irq_vector)(struct device *dev, unsigned int nr); > > > > -}; > > > > - > > > > struct dw_edma { > > > > char name[20]; > > > > > > > > @@ -122,21 +104,13 @@ struct dw_edma { > > > > struct dma_device rd_edma; > > > > u16 rd_ch_cnt; > > > > > > > > - struct dw_edma_region rg_region; /* Registers */ > > > > - struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > > > - struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > > > - struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > > > > - struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > > > > - > > > > struct dw_edma_irq *irq; > > > > - int nr_irqs; > > > > - > > > > - enum dw_edma_map_format mf; > > > > > > > > struct dw_edma_chan *chan; > > > > - const struct dw_edma_core_ops *ops; > > > > > > > > raw_spinlock_t lock; /* Only for legacy */ > > > > + > > > > + struct dw_edma_chip *chip; > > > > #ifdef CONFIG_DEBUG_FS > > > > struct dentry *debugfs; > > > > #endif /* CONFIG_DEBUG_FS */ > > > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > > > > index 44f6e09bdb531..2c1c5fa4e9f28 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > > > > @@ -148,7 +148,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > struct dw_edma_pcie_data vsec_data; > > > > struct device *dev = &pdev->dev; > > > > struct dw_edma_chip *chip; > > > > - struct dw_edma *dw; > > > > int err, nr_irqs; > > > > int i, mask; > > > > > > > > @@ -214,10 +213,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > if (!chip) > > > > return -ENOMEM; > > > > > > > > - dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > > > > - if (!dw) > > > > - return -ENOMEM; > > > > - > > > > /* IRQs allocation */ > > > > nr_irqs = pci_alloc_irq_vectors(pdev, 1, vsec_data.irqs, > > > > PCI_IRQ_MSI | PCI_IRQ_MSIX); > > > > @@ -228,29 +223,23 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > } > > > > > > > > /* Data structure initialization */ > > > > - chip->dw = dw; > > > > chip->dev = dev; > > > > chip->id = pdev->devfn; > > > > - chip->irq = pdev->irq; > > > > > > > > - dw->mf = vsec_data.mf; > > > > - dw->nr_irqs = nr_irqs; > > > > - dw->ops = &dw_edma_pcie_core_ops; > > > > - dw->wr_ch_cnt = vsec_data.wr_ch_cnt; > > > > - dw->rd_ch_cnt = vsec_data.rd_ch_cnt; > > > > + chip->mf = vsec_data.mf; > > > > + chip->nr_irqs = nr_irqs; > > > > + chip->ops = &dw_edma_pcie_core_ops; > > > > > > > > - dw->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > > > - if (!dw->rg_region.vaddr) > > > > - return -ENOMEM; > > > > + chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > > > > + chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > > > > > > > - dw->rg_region.vaddr += vsec_data.rg.off; > > > > - dw->rg_region.paddr = pdev->resource[vsec_data.rg.bar].start; > > > > - dw->rg_region.paddr += vsec_data.rg.off; > > > > - dw->rg_region.sz = vsec_data.rg.sz; > > > > + chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > > > + if (!chip->rg_region.vaddr) > > > > + return -ENOMEM; > > > > > > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > > > > - struct dw_edma_region *ll_region = &dw->ll_region_wr[i]; > > > > - struct dw_edma_region *dt_region = &dw->dt_region_wr[i]; > > > > + for (i = 0; i < chip->wr_ch_cnt; i++) { > > > > + struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > > > > + struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > > > > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > > > > struct dw_edma_block *dt_block = &vsec_data.dt_wr[i]; > > > > > > > > @@ -273,9 +262,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > dt_region->sz = dt_block->sz; > > > > } > > > > > > > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > > > > - struct dw_edma_region *ll_region = &dw->ll_region_rd[i]; > > > > - struct dw_edma_region *dt_region = &dw->dt_region_rd[i]; > > > > + for (i = 0; i < chip->rd_ch_cnt; i++) { > > > > + struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > > > > + struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > > > > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > > > > struct dw_edma_block *dt_block = &vsec_data.dt_rd[i]; > > > > > > > > @@ -299,45 +288,45 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > } > > > > > > > > /* Debug info */ > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > > > > - pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", dw->mf); > > > > - else if (dw->mf == EDMA_MF_EDMA_UNROLL) > > > > - pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", dw->mf); > > > > - else if (dw->mf == EDMA_MF_HDMA_COMPAT) > > > > - pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", dw->mf); > > > > + if (chip->mf == EDMA_MF_EDMA_LEGACY) > > > > + pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", chip->mf); > > > > + else if (chip->mf == EDMA_MF_EDMA_UNROLL) > > > > + pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", chip->mf); > > > > + else if (chip->mf == EDMA_MF_HDMA_COMPAT) > > > > + pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", chip->mf); > > > > else > > > > - pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", dw->mf); > > > > + pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", chip->mf); > > > > > > > > - pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > + pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", > > > > vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, > > > > - dw->rg_region.vaddr, &dw->rg_region.paddr); > > > > + chip->rg_region.vaddr); > > > > > > > > > > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > > > > + for (i = 0; i < chip->wr_ch_cnt; i++) { > > > > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > i, vsec_data.ll_wr[i].bar, > > > > - vsec_data.ll_wr[i].off, dw->ll_region_wr[i].sz, > > > > - dw->ll_region_wr[i].vaddr, &dw->ll_region_wr[i].paddr); > > > > + vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > > > > + chip->ll_region_wr[i].vaddr, &chip->ll_region_wr[i].paddr); > > > > > > > > pci_dbg(pdev, "Data:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > i, vsec_data.dt_wr[i].bar, > > > > - vsec_data.dt_wr[i].off, dw->dt_region_wr[i].sz, > > > > - dw->dt_region_wr[i].vaddr, &dw->dt_region_wr[i].paddr); > > > > + vsec_data.dt_wr[i].off, chip->dt_region_wr[i].sz, > > > > + chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > > > > } > > > > > > > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > > > > + for (i = 0; i < chip->rd_ch_cnt; i++) { > > > > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > i, vsec_data.ll_rd[i].bar, > > > > - vsec_data.ll_rd[i].off, dw->ll_region_rd[i].sz, > > > > - dw->ll_region_rd[i].vaddr, &dw->ll_region_rd[i].paddr); > > > > + vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > > > > + chip->ll_region_rd[i].vaddr, &chip->ll_region_rd[i].paddr); > > > > > > > > pci_dbg(pdev, "Data:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > i, vsec_data.dt_rd[i].bar, > > > > - vsec_data.dt_rd[i].off, dw->dt_region_rd[i].sz, > > > > - dw->dt_region_rd[i].vaddr, &dw->dt_region_rd[i].paddr); > > > > + vsec_data.dt_rd[i].off, chip->dt_region_rd[i].sz, > > > > + chip->dt_region_rd[i].vaddr, &chip->dt_region_rd[i].paddr); > > > > } > > > > > > > > - pci_dbg(pdev, "Nr. IRQs:\t%u\n", dw->nr_irqs); > > > > + pci_dbg(pdev, "Nr. IRQs:\t%u\n", chip->nr_irqs); > > > > > > > > /* Validating if PCI interrupts were enabled */ > > > > if (!pci_dev_msi_enabled(pdev)) { > > > > @@ -345,10 +334,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > return -EPERM; > > > > } > > > > > > > > - dw->irq = devm_kcalloc(dev, nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > > > > - if (!dw->irq) > > > > - return -ENOMEM; > > > > - > > > > /* Starting eDMA driver */ > > > > err = dw_edma_probe(chip); > > > > if (err) { > > > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > > > > index 329fc2e57b703..e507e076fad16 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > > > > @@ -25,7 +25,7 @@ enum dw_edma_control { > > > > > > > > static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > > > > { > > > > - return dw->rg_region.vaddr; > > > > + return dw->chip->rg_region.vaddr; > > > > } > > > > > > > > #define SET_32(dw, name, value) \ > > > > @@ -96,7 +96,7 @@ static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > > > > static inline struct dw_edma_v0_ch_regs __iomem * > > > > __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > > > > { > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) > > > > return &(__dw_regs(dw)->type.legacy.ch); > > > > > > > > if (dir == EDMA_DIR_WRITE) > > > > @@ -108,7 +108,7 @@ __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > > > > static inline void writel_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > u32 value, void __iomem *addr) > > > > { > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > > u32 viewport_sel; > > > > unsigned long flags; > > > > > > > > @@ -133,7 +133,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > { > > > > u32 value; > > > > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > > u32 viewport_sel; > > > > unsigned long flags; > > > > > > > > @@ -169,7 +169,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > static inline void writeq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > u64 value, void __iomem *addr) > > > > { > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > > u32 viewport_sel; > > > > unsigned long flags; > > > > > > > > @@ -194,7 +194,7 @@ static inline u64 readq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > { > > > > u32 value; > > > > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > > u32 viewport_sel; > > > > unsigned long flags; > > > > > > > > @@ -256,7 +256,7 @@ u16 dw_edma_v0_core_ch_count(struct dw_edma *dw, enum dw_edma_dir dir) > > > > > > > > enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > > > { > > > > - struct dw_edma *dw = chan->chip->dw; > > > > + struct dw_edma *dw = chan->dw; > > > > u32 tmp; > > > > > > > > tmp = FIELD_GET(EDMA_V0_CH_STATUS_MASK, > > > > @@ -272,7 +272,7 @@ enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > > > > > > > void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > > > { > > > > - struct dw_edma *dw = chan->chip->dw; > > > > + struct dw_edma *dw = chan->dw; > > > > > > > > SET_RW_32(dw, chan->dir, int_clear, > > > > FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id))); > > > > @@ -280,7 +280,7 @@ void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > > > > > > > void dw_edma_v0_core_clear_abort_int(struct dw_edma_chan *chan) > > > > { > > > > - struct dw_edma *dw = chan->chip->dw; > > > > + struct dw_edma *dw = chan->dw; > > > > > > > > SET_RW_32(dw, chan->dir, int_clear, > > > > FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id))); > > > > @@ -357,7 +357,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > > > > void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > > { > > > > struct dw_edma_chan *chan = chunk->chan; > > > > - struct dw_edma *dw = chan->chip->dw; > > > > + struct dw_edma *dw = chan->dw; > > > > u32 tmp; > > > > > > > > dw_edma_v0_core_write_chunk(chunk); > > > > @@ -365,7 +365,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > > if (first) { > > > > /* Enable engine */ > > > > SET_RW_32(dw, chan->dir, engine_en, BIT(0)); > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > > > switch (chan->id) { > > > > case 0: > > > > SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, > > > > @@ -431,7 +431,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > > > > > > int dw_edma_v0_core_device_config(struct dw_edma_chan *chan) > > > > { > > > > - struct dw_edma *dw = chan->chip->dw; > > > > + struct dw_edma *dw = chan->dw; > > > > u32 tmp = 0; > > > > > > > > /* MSI done addr - low, high */ > > > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > > > index 4b3bcffd15ef1..edb7e137cb35a 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > > > @@ -54,7 +54,7 @@ struct debugfs_entries { > > > > static int dw_edma_debugfs_u32_get(void *data, u64 *val) > > > > { > > > > void __iomem *reg = (void __force __iomem *)data; > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY && > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY && > > > > reg >= (void __iomem *)®s->type.legacy.ch) { > > > > void __iomem *ptr = ®s->type.legacy.ch; > > > > u32 viewport_sel = 0; > > > > @@ -173,7 +173,7 @@ static void dw_edma_debugfs_regs_wr(struct dentry *dir) > > > > nr_entries = ARRAY_SIZE(debugfs_regs); > > > > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > > > > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > > > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > > > > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > > > > regs_dir); > > > > @@ -242,7 +242,7 @@ static void dw_edma_debugfs_regs_rd(struct dentry *dir) > > > > nr_entries = ARRAY_SIZE(debugfs_regs); > > > > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > > > > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > > > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > > > > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > > > > regs_dir); > > > > @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > > > > if (!dw) > > > > return; > > > > > > > > - regs = dw->rg_region.vaddr; > > > > + regs = dw->chip->rg_region.vaddr; > > > > if (!regs) > > > > return; > > > > > > > > @@ -296,7 +296,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > > > > if (!dw->debugfs) > > > > return; > > > > > > > > - debugfs_create_u32("mf", 0444, dw->debugfs, &dw->mf); > > > > + debugfs_create_u32("mf", 0444, dw->debugfs, &dw->chip->mf); > > > > debugfs_create_u16("wr_ch_cnt", 0444, dw->debugfs, &dw->wr_ch_cnt); > > > > debugfs_create_u16("rd_ch_cnt", 0444, dw->debugfs, &dw->rd_ch_cnt); > > > > > > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > > > > index cab6e18773dad..a9bee4aeb2eee 100644 > > > > --- a/include/linux/dma/edma.h > > > > +++ b/include/linux/dma/edma.h > > > > @@ -12,19 +12,63 @@ > > > > #include <linux/device.h> > > > > #include <linux/dmaengine.h> > > > > > > > > +#define EDMA_MAX_WR_CH 8 > > > > +#define EDMA_MAX_RD_CH 8 > > > > + > > > > struct dw_edma; > > > > > > > > +struct dw_edma_region { > > > > + phys_addr_t paddr; > > > > + void __iomem *vaddr; > > > > + size_t sz; > > > > +}; > > > > + > > > > +struct dw_edma_core_ops { > > > > + int (*irq_vector)(struct device *dev, unsigned int nr); > > > > +}; > > > > + > > > > +enum dw_edma_map_format { > > > > + EDMA_MF_EDMA_LEGACY = 0x0, > > > > + EDMA_MF_EDMA_UNROLL = 0x1, > > > > + EDMA_MF_HDMA_COMPAT = 0x5 > > > > +}; > > > > + > > > > /** > > > > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > > > > * @dev: struct device of the eDMA controller > > > > * @id: instance ID > > > > * @irq: irq line > > > > + * @nr_irqs: total dma irq number > > > > + * @ops DMA channel to IRQ number mapping > > > > + * @wr_ch_cnt DMA write channel number > > > > + * @rd_ch_cnt DMA read channel number > > > > + * @rg_region DMA register region > > > > + * @ll_region_wr DMA descriptor link list memory for write channel > > > > + * @ll_region_rd DMA descriptor link list memory for read channel > > > > + * @mf DMA register map format > > > > * @dw: struct dw_edma that is filed by dw_edma_probe() > > > > */ > > > > struct dw_edma_chip { > > > > struct device *dev; > > > > int id; > > > > int irq; > > > > + int nr_irqs; > > > > + const struct dw_edma_core_ops *ops; > > > > + > > > > + struct dw_edma_region rg_region; > > > > + > > > > + u16 wr_ch_cnt; > > > > + u16 rd_ch_cnt; > > > > + /* link list address */ > > > > + struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > > > + struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > > > + > > > > + /* data region */ > > > > + struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > > > > + struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > > > > + > > > > + enum dw_edma_map_format mf; > > > > + > > > > > > > struct dw_edma *dw; > > > > > > Please drop this field from here and just change the dw_edma_probe() > > > prototype to returning a pointer to the struct dw_edma structure. Like > > > this: > > > struct dw_edma *dw_edma_probe(const struct dw_edma_chip *chip); > > > void dw_edma_remove(struct dw_edma *dw); > > > > > Actually, I don't think it is good to drop it now. > > > > struct dw_edma *dw_edma_probe(const struct dw_edma_chip *chip); > > > > Users likely put struct dw_edma_chip in stack. > > foo() > > { > > struct dw_edma_chip chip > > dw = dw_edma_proble(&chip); > > } > > > > but now, edma_core_driver still does not save chip information to dw_edma > > Neither current implementation nor implementation suggested by me > permits having the struct dw_edma_chip structure instance allocated on > stack, Yes, but original implement int dw_edma_probe(struct dw_edma_chip *chip) int dw_edma_remove (struct dw_edma_chip *chip) User knows the chip will be used at remove, so it will be saved in a safe place. struct dw_edma* dw_edma_probe(struct dw_edma_chip*chip) look like chip only use once when call dw_edma_probe, User most like use stack if he don't read dw_edma_probe's implement. > since the pointer to the structure is then preserved in the > dw_edma all the way until the device/driver isn't removed (it will > require some more modifications, which I can't request from you). > What approach proposed by me provides is a way to statically define > the struct dw_edma_chip object. Seeing the eDMA driver doesn't change > the structure fields we can extend the API functionality. In this > case the probe()/remote() methods semantics turns to be cleaner and > looking more like the i2c-board-info design. I grep probe under include/*, I found most *_probe() function return int, I think a benefit is It can return different error codes, especially EPROBE_DEFER. Of course, EPROBE_DEFER will not happen in this case. But I think it'd be better to follow common sense. > That we'll be able to > gain almost with no much efforts. Just fix the > dw_edma_probe()/dw_edma_remove() method prototype as I suggested > (Don't forget the const-modifier in the probe argument and in the > dw_edma.dw field). It is not an effort problem. Just which one is better and prevents some protiental problems and is easy to use. I suggest we can move this change to future patch, which save chip info to dw_edma and don't direct refer chip, which pass down at dw_edma_probe() > > -Sergey > > > > > > > > > By doing so we'll be able to have the chip data being const and at least > > > statically defined. > > > > > > -Sergey > > > > > > > }; > > > > > > > > -- > > > > 2.24.0.rc1 > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures 2022-03-11 15:29 ` Zhi Li @ 2022-03-12 19:56 ` Serge Semin 0 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-12 19:56 UTC (permalink / raw) To: Zhi Li Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Fri, Mar 11, 2022 at 09:29:08AM -0600, Zhi Li wrote: > On Fri, Mar 11, 2022 at 5:03 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > On Thu, Mar 10, 2022 at 02:29:15PM -0600, Zhi Li wrote: > > > in > > > > > > On Thu, Mar 10, 2022 at 2:20 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > On Wed, Mar 09, 2022 at 03:11:57PM -0600, Frank Li wrote: > > > > > "struct dw_edma_chip" contains an internal structure "struct dw_edma" that > > > > > is used by the eDMA core internally. This structure should not be touched > > > > > by the eDMA controller drivers themselves. But currently, the eDMA > > > > > controller drivers like "dw-edma-pci" allocates and populates this > > > > > internal structure then passes it on to eDMA core. The eDMA core further > > > > > populates the structure and uses it. This is wrong! > > > > > > > > > > Hence, move all the "struct dw_edma" specifics from controller drivers > > > > > to the eDMA core. > > > > > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > > --- > > > > > Change from v3 to v4 > > > > > - Accept most suggestions of Serge Semin > > > > > Change from v2 to v3 > > > > > - none > > > > > Change from v1 to v2 > > > > > - rework commit message > > > > > - remove duplicate field in struct dw_edma > > > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 81 +++++++++++++---------- > > > > > drivers/dma/dw-edma/dw-edma-core.h | 32 +-------- > > > > > drivers/dma/dw-edma/dw-edma-pcie.c | 83 ++++++++++-------------- > > > > > drivers/dma/dw-edma/dw-edma-v0-core.c | 24 +++---- > > > > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 10 +-- > > > > > include/linux/dma/edma.h | 44 +++++++++++++ > > > > > 6 files changed, 144 insertions(+), 130 deletions(-) > > > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > > index 53289927dd0d6..1abf41d49f75b 100644 > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > > @@ -65,7 +65,7 @@ static struct dw_edma_burst *dw_edma_alloc_burst(struct dw_edma_chunk *chunk) > > > > > static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > > > > > { > > > > > struct dw_edma_chan *chan = desc->chan; > > > > > - struct dw_edma *dw = chan->chip->dw; > > > > > + struct dw_edma_chip *chip = chan->dw->chip; > > > > > struct dw_edma_chunk *chunk; > > > > > > > > > > chunk = kzalloc(sizeof(*chunk), GFP_NOWAIT); > > > > > @@ -82,11 +82,11 @@ static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > > > > > */ > > > > > chunk->cb = !(desc->chunks_alloc % 2); > > > > > if (chan->dir == EDMA_DIR_WRITE) { > > > > > - chunk->ll_region.paddr = dw->ll_region_wr[chan->id].paddr; > > > > > - chunk->ll_region.vaddr = dw->ll_region_wr[chan->id].vaddr; > > > > > + chunk->ll_region.paddr = chip->ll_region_wr[chan->id].paddr; > > > > > + chunk->ll_region.vaddr = chip->ll_region_wr[chan->id].vaddr; > > > > > } else { > > > > > - chunk->ll_region.paddr = dw->ll_region_rd[chan->id].paddr; > > > > > - chunk->ll_region.vaddr = dw->ll_region_rd[chan->id].vaddr; > > > > > + chunk->ll_region.paddr = chip->ll_region_rd[chan->id].paddr; > > > > > + chunk->ll_region.vaddr = chip->ll_region_rd[chan->id].vaddr; > > > > > } > > > > > > > > > > if (desc->chunk) { > > > > > @@ -664,7 +664,7 @@ static int dw_edma_alloc_chan_resources(struct dma_chan *dchan) > > > > > if (chan->status != EDMA_ST_IDLE) > > > > > return -EBUSY; > > > > > > > > > > - pm_runtime_get(chan->chip->dev); > > > > > + pm_runtime_get(chan->dw->chip->dev); > > > > > > > > > > return 0; > > > > > } > > > > > @@ -686,7 +686,7 @@ static void dw_edma_free_chan_resources(struct dma_chan *dchan) > > > > > cpu_relax(); > > > > > } > > > > > > > > > > - pm_runtime_put(chan->chip->dev); > > > > > + pm_runtime_put(chan->dw->chip->dev); > > > > > } > > > > > > > > > > static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > > @@ -718,7 +718,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > > } > > > > > > > > > > INIT_LIST_HEAD(&dma->channels); > > > > > - for (j = 0; (alloc || dw->nr_irqs == 1) && j < cnt; j++, i++) { > > > > > + for (j = 0; (alloc || chip->nr_irqs == 1) && j < cnt; j++, i++) { > > > > > chan = &dw->chan[i]; > > > > > > > > > > dt_region = devm_kzalloc(dev, sizeof(*dt_region), GFP_KERNEL); > > > > > @@ -727,7 +727,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > > > > > > > chan->vc.chan.private = dt_region; > > > > > > > > > > - chan->chip = chip; > > > > > + chan->dw = dw; > > > > > chan->id = j; > > > > > chan->dir = write ? EDMA_DIR_WRITE : EDMA_DIR_READ; > > > > > chan->configured = false; > > > > > @@ -735,15 +735,15 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > > chan->status = EDMA_ST_IDLE; > > > > > > > > > > if (write) > > > > > - chan->ll_max = (dw->ll_region_wr[j].sz / EDMA_LL_SZ); > > > > > + chan->ll_max = (chip->ll_region_wr[j].sz / EDMA_LL_SZ); > > > > > else > > > > > - chan->ll_max = (dw->ll_region_rd[j].sz / EDMA_LL_SZ); > > > > > + chan->ll_max = (chip->ll_region_rd[j].sz / EDMA_LL_SZ); > > > > > chan->ll_max -= 1; > > > > > > > > > > dev_vdbg(dev, "L. List:\tChannel %s[%u] max_cnt=%u\n", > > > > > write ? "write" : "read", j, chan->ll_max); > > > > > > > > > > - if (dw->nr_irqs == 1) > > > > > + if (chip->nr_irqs == 1) > > > > > pos = 0; > > > > > else > > > > > pos = off_alloc + (j % alloc); > > > > > @@ -767,13 +767,13 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > > > > vchan_init(&chan->vc, dma); > > > > > > > > > > if (write) { > > > > > - dt_region->paddr = dw->dt_region_wr[j].paddr; > > > > > - dt_region->vaddr = dw->dt_region_wr[j].vaddr; > > > > > - dt_region->sz = dw->dt_region_wr[j].sz; > > > > > + dt_region->paddr = chip->dt_region_wr[j].paddr; > > > > > + dt_region->vaddr = chip->dt_region_wr[j].vaddr; > > > > > + dt_region->sz = chip->dt_region_wr[j].sz; > > > > > } else { > > > > > - dt_region->paddr = dw->dt_region_rd[j].paddr; > > > > > - dt_region->vaddr = dw->dt_region_rd[j].vaddr; > > > > > - dt_region->sz = dw->dt_region_rd[j].sz; > > > > > + dt_region->paddr = chip->dt_region_rd[j].paddr; > > > > > + dt_region->vaddr = chip->dt_region_rd[j].vaddr; > > > > > + dt_region->sz = chip->dt_region_rd[j].sz; > > > > > } > > > > > > > > > > dw_edma_v0_core_device_config(chan); > > > > > @@ -840,16 +840,16 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > > > > > > > ch_cnt = dw->wr_ch_cnt + dw->rd_ch_cnt; > > > > > > > > > > - if (dw->nr_irqs < 1) > > > > > + if (chip->nr_irqs < 1) > > > > > return -EINVAL; > > > > > > > > > > - if (dw->nr_irqs == 1) { > > > > > + if (chip->nr_irqs == 1) { > > > > > /* Common IRQ shared among all channels */ > > > > > - irq = dw->ops->irq_vector(dev, 0); > > > > > + irq = chip->ops->irq_vector(dev, 0); > > > > > err = request_irq(irq, dw_edma_interrupt_common, > > > > > IRQF_SHARED, dw->name, &dw->irq[0]); > > > > > if (err) { > > > > > - dw->nr_irqs = 0; > > > > > + chip->nr_irqs = 0; > > > > > return err; > > > > > } > > > > > > > > > > @@ -857,7 +857,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > > get_cached_msi_msg(irq, &dw->irq[0].msi); > > > > > } else { > > > > > /* Distribute IRQs equally among all channels */ > > > > > - int tmp = dw->nr_irqs; > > > > > + int tmp = chip->nr_irqs; > > > > > > > > > > while (tmp && (*wr_alloc + *rd_alloc) < ch_cnt) { > > > > > dw_edma_dec_irq_alloc(&tmp, wr_alloc, dw->wr_ch_cnt); > > > > > @@ -868,7 +868,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > > dw_edma_add_irq_mask(&rd_mask, *rd_alloc, dw->rd_ch_cnt); > > > > > > > > > > for (i = 0; i < (*wr_alloc + *rd_alloc); i++) { > > > > > - irq = dw->ops->irq_vector(dev, i); > > > > > + irq = chip->ops->irq_vector(dev, i); > > > > > err = request_irq(irq, > > > > > i < *wr_alloc ? > > > > > dw_edma_interrupt_write : > > > > > @@ -876,7 +876,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > > IRQF_SHARED, dw->name, > > > > > &dw->irq[i]); > > > > > if (err) { > > > > > - dw->nr_irqs = i; > > > > > + chip->nr_irqs = i; > > > > > return err; > > > > > } > > > > > > > > > > @@ -884,7 +884,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > > > > get_cached_msi_msg(irq, &dw->irq[i].msi); > > > > > } > > > > > > > > > > - dw->nr_irqs = i; > > > > > + chip->nr_irqs = i; > > > > > } > > > > > > > > > > return err; > > > > > @@ -905,17 +905,24 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > > > if (!dev) > > > > > return -EINVAL; > > > > > > > > > > - dw = chip->dw; > > > > > - if (!dw || !dw->irq || !dw->ops || !dw->ops->irq_vector) > > > > > + dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > > > > > + if (!dw) > > > > > + return -ENOMEM; > > > > > + > > > > > + chip->dw = dw; > > > > > + dw->chip = chip; > > > > > + > > > > > + if (!chip->nr_irqs || !chip->ops) > > > > > return -EINVAL; > > > > > > > > > > raw_spin_lock_init(&dw->lock); > > > > > > > > > > - dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, > > > > > + > > > > > + dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > > > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > > > > > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > > > > > > > > > - dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, > > > > > + dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > > > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > > > > > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > > > > > > > > > @@ -936,6 +943,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > > > /* Disable eDMA, only to establish the ideal initial conditions */ > > > > > dw_edma_v0_core_off(dw); > > > > > > > > > > + dw->irq = devm_kcalloc(dev, chip->nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > > > > > + if (!dw->irq) > > > > > + return -ENOMEM; > > > > > + > > > > > /* Request IRQs */ > > > > > err = dw_edma_irq_request(chip, &wr_alloc, &rd_alloc); > > > > > if (err) > > > > > @@ -960,10 +971,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > > > return 0; > > > > > > > > > > err_irq_free: > > > > > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > > > > > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > > > > > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > > > > > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > > > > > > > > > - dw->nr_irqs = 0; > > > > > + chip->nr_irqs = 0; > > > > > > > > > > return err; > > > > > } > > > > > @@ -980,8 +991,8 @@ int dw_edma_remove(struct dw_edma_chip *chip) > > > > > dw_edma_v0_core_off(dw); > > > > > > > > > > /* Free irqs */ > > > > > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > > > > > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > > > > > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > > > > > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > > > > > > > > > /* Power management */ > > > > > pm_runtime_disable(dev); > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h > > > > > index 60316d408c3e0..e254c2fc3d9cf 100644 > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.h > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.h > > > > > @@ -15,20 +15,12 @@ > > > > > #include "../virt-dma.h" > > > > > > > > > > #define EDMA_LL_SZ 24 > > > > > -#define EDMA_MAX_WR_CH 8 > > > > > -#define EDMA_MAX_RD_CH 8 > > > > > > > > > > enum dw_edma_dir { > > > > > EDMA_DIR_WRITE = 0, > > > > > EDMA_DIR_READ > > > > > }; > > > > > > > > > > -enum dw_edma_map_format { > > > > > - EDMA_MF_EDMA_LEGACY = 0x0, > > > > > - EDMA_MF_EDMA_UNROLL = 0x1, > > > > > - EDMA_MF_HDMA_COMPAT = 0x5 > > > > > -}; > > > > > - > > > > > enum dw_edma_request { > > > > > EDMA_REQ_NONE = 0, > > > > > EDMA_REQ_STOP, > > > > > @@ -57,12 +49,6 @@ struct dw_edma_burst { > > > > > u32 sz; > > > > > }; > > > > > > > > > > -struct dw_edma_region { > > > > > - phys_addr_t paddr; > > > > > - void __iomem *vaddr; > > > > > - size_t sz; > > > > > -}; > > > > > - > > > > > struct dw_edma_chunk { > > > > > struct list_head list; > > > > > struct dw_edma_chan *chan; > > > > > @@ -87,7 +73,7 @@ struct dw_edma_desc { > > > > > > > > > > struct dw_edma_chan { > > > > > struct virt_dma_chan vc; > > > > > - struct dw_edma_chip *chip; > > > > > + struct dw_edma *dw; > > > > > int id; > > > > > enum dw_edma_dir dir; > > > > > > > > > > @@ -109,10 +95,6 @@ struct dw_edma_irq { > > > > > struct dw_edma *dw; > > > > > }; > > > > > > > > > > -struct dw_edma_core_ops { > > > > > - int (*irq_vector)(struct device *dev, unsigned int nr); > > > > > -}; > > > > > - > > > > > struct dw_edma { > > > > > char name[20]; > > > > > > > > > > @@ -122,21 +104,13 @@ struct dw_edma { > > > > > struct dma_device rd_edma; > > > > > u16 rd_ch_cnt; > > > > > > > > > > - struct dw_edma_region rg_region; /* Registers */ > > > > > - struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > > > > - struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > > > > - struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > > > > > - struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > > > > > - > > > > > struct dw_edma_irq *irq; > > > > > - int nr_irqs; > > > > > - > > > > > - enum dw_edma_map_format mf; > > > > > > > > > > struct dw_edma_chan *chan; > > > > > - const struct dw_edma_core_ops *ops; > > > > > > > > > > raw_spinlock_t lock; /* Only for legacy */ > > > > > + > > > > > + struct dw_edma_chip *chip; > > > > > #ifdef CONFIG_DEBUG_FS > > > > > struct dentry *debugfs; > > > > > #endif /* CONFIG_DEBUG_FS */ > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > > > > > index 44f6e09bdb531..2c1c5fa4e9f28 100644 > > > > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > > > > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > > > > > @@ -148,7 +148,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > > struct dw_edma_pcie_data vsec_data; > > > > > struct device *dev = &pdev->dev; > > > > > struct dw_edma_chip *chip; > > > > > - struct dw_edma *dw; > > > > > int err, nr_irqs; > > > > > int i, mask; > > > > > > > > > > @@ -214,10 +213,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > > if (!chip) > > > > > return -ENOMEM; > > > > > > > > > > - dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > > > > > - if (!dw) > > > > > - return -ENOMEM; > > > > > - > > > > > /* IRQs allocation */ > > > > > nr_irqs = pci_alloc_irq_vectors(pdev, 1, vsec_data.irqs, > > > > > PCI_IRQ_MSI | PCI_IRQ_MSIX); > > > > > @@ -228,29 +223,23 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > > } > > > > > > > > > > /* Data structure initialization */ > > > > > - chip->dw = dw; > > > > > chip->dev = dev; > > > > > chip->id = pdev->devfn; > > > > > - chip->irq = pdev->irq; > > > > > > > > > > - dw->mf = vsec_data.mf; > > > > > - dw->nr_irqs = nr_irqs; > > > > > - dw->ops = &dw_edma_pcie_core_ops; > > > > > - dw->wr_ch_cnt = vsec_data.wr_ch_cnt; > > > > > - dw->rd_ch_cnt = vsec_data.rd_ch_cnt; > > > > > + chip->mf = vsec_data.mf; > > > > > + chip->nr_irqs = nr_irqs; > > > > > + chip->ops = &dw_edma_pcie_core_ops; > > > > > > > > > > - dw->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > > > > - if (!dw->rg_region.vaddr) > > > > > - return -ENOMEM; > > > > > + chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > > > > > + chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > > > > > > > > > - dw->rg_region.vaddr += vsec_data.rg.off; > > > > > - dw->rg_region.paddr = pdev->resource[vsec_data.rg.bar].start; > > > > > - dw->rg_region.paddr += vsec_data.rg.off; > > > > > - dw->rg_region.sz = vsec_data.rg.sz; > > > > > + chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > > > > + if (!chip->rg_region.vaddr) > > > > > + return -ENOMEM; > > > > > > > > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > > > > > - struct dw_edma_region *ll_region = &dw->ll_region_wr[i]; > > > > > - struct dw_edma_region *dt_region = &dw->dt_region_wr[i]; > > > > > + for (i = 0; i < chip->wr_ch_cnt; i++) { > > > > > + struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > > > > > + struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > > > > > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > > > > > struct dw_edma_block *dt_block = &vsec_data.dt_wr[i]; > > > > > > > > > > @@ -273,9 +262,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > > dt_region->sz = dt_block->sz; > > > > > } > > > > > > > > > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > > > > > - struct dw_edma_region *ll_region = &dw->ll_region_rd[i]; > > > > > - struct dw_edma_region *dt_region = &dw->dt_region_rd[i]; > > > > > + for (i = 0; i < chip->rd_ch_cnt; i++) { > > > > > + struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > > > > > + struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > > > > > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > > > > > struct dw_edma_block *dt_block = &vsec_data.dt_rd[i]; > > > > > > > > > > @@ -299,45 +288,45 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > > } > > > > > > > > > > /* Debug info */ > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > > > > > - pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", dw->mf); > > > > > - else if (dw->mf == EDMA_MF_EDMA_UNROLL) > > > > > - pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", dw->mf); > > > > > - else if (dw->mf == EDMA_MF_HDMA_COMPAT) > > > > > - pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", dw->mf); > > > > > + if (chip->mf == EDMA_MF_EDMA_LEGACY) > > > > > + pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", chip->mf); > > > > > + else if (chip->mf == EDMA_MF_EDMA_UNROLL) > > > > > + pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", chip->mf); > > > > > + else if (chip->mf == EDMA_MF_HDMA_COMPAT) > > > > > + pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", chip->mf); > > > > > else > > > > > - pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", dw->mf); > > > > > + pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", chip->mf); > > > > > > > > > > - pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > > + pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", > > > > > vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, > > > > > - dw->rg_region.vaddr, &dw->rg_region.paddr); > > > > > + chip->rg_region.vaddr); > > > > > > > > > > > > > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > > > > > + for (i = 0; i < chip->wr_ch_cnt; i++) { > > > > > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > > i, vsec_data.ll_wr[i].bar, > > > > > - vsec_data.ll_wr[i].off, dw->ll_region_wr[i].sz, > > > > > - dw->ll_region_wr[i].vaddr, &dw->ll_region_wr[i].paddr); > > > > > + vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > > > > > + chip->ll_region_wr[i].vaddr, &chip->ll_region_wr[i].paddr); > > > > > > > > > > pci_dbg(pdev, "Data:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > > i, vsec_data.dt_wr[i].bar, > > > > > - vsec_data.dt_wr[i].off, dw->dt_region_wr[i].sz, > > > > > - dw->dt_region_wr[i].vaddr, &dw->dt_region_wr[i].paddr); > > > > > + vsec_data.dt_wr[i].off, chip->dt_region_wr[i].sz, > > > > > + chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > > > > > } > > > > > > > > > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > > > > > + for (i = 0; i < chip->rd_ch_cnt; i++) { > > > > > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > > i, vsec_data.ll_rd[i].bar, > > > > > - vsec_data.ll_rd[i].off, dw->ll_region_rd[i].sz, > > > > > - dw->ll_region_rd[i].vaddr, &dw->ll_region_rd[i].paddr); > > > > > + vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > > > > > + chip->ll_region_rd[i].vaddr, &chip->ll_region_rd[i].paddr); > > > > > > > > > > pci_dbg(pdev, "Data:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > > i, vsec_data.dt_rd[i].bar, > > > > > - vsec_data.dt_rd[i].off, dw->dt_region_rd[i].sz, > > > > > - dw->dt_region_rd[i].vaddr, &dw->dt_region_rd[i].paddr); > > > > > + vsec_data.dt_rd[i].off, chip->dt_region_rd[i].sz, > > > > > + chip->dt_region_rd[i].vaddr, &chip->dt_region_rd[i].paddr); > > > > > } > > > > > > > > > > - pci_dbg(pdev, "Nr. IRQs:\t%u\n", dw->nr_irqs); > > > > > + pci_dbg(pdev, "Nr. IRQs:\t%u\n", chip->nr_irqs); > > > > > > > > > > /* Validating if PCI interrupts were enabled */ > > > > > if (!pci_dev_msi_enabled(pdev)) { > > > > > @@ -345,10 +334,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > > return -EPERM; > > > > > } > > > > > > > > > > - dw->irq = devm_kcalloc(dev, nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > > > > > - if (!dw->irq) > > > > > - return -ENOMEM; > > > > > - > > > > > /* Starting eDMA driver */ > > > > > err = dw_edma_probe(chip); > > > > > if (err) { > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > > > > > index 329fc2e57b703..e507e076fad16 100644 > > > > > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > > > > > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > > > > > @@ -25,7 +25,7 @@ enum dw_edma_control { > > > > > > > > > > static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > > > > > { > > > > > - return dw->rg_region.vaddr; > > > > > + return dw->chip->rg_region.vaddr; > > > > > } > > > > > > > > > > #define SET_32(dw, name, value) \ > > > > > @@ -96,7 +96,7 @@ static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > > > > > static inline struct dw_edma_v0_ch_regs __iomem * > > > > > __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > > > > > { > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) > > > > > return &(__dw_regs(dw)->type.legacy.ch); > > > > > > > > > > if (dir == EDMA_DIR_WRITE) > > > > > @@ -108,7 +108,7 @@ __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > > > > > static inline void writel_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > > u32 value, void __iomem *addr) > > > > > { > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > > > u32 viewport_sel; > > > > > unsigned long flags; > > > > > > > > > > @@ -133,7 +133,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > > { > > > > > u32 value; > > > > > > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > > > u32 viewport_sel; > > > > > unsigned long flags; > > > > > > > > > > @@ -169,7 +169,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > > static inline void writeq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > > u64 value, void __iomem *addr) > > > > > { > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > > > u32 viewport_sel; > > > > > unsigned long flags; > > > > > > > > > > @@ -194,7 +194,7 @@ static inline u64 readq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > > > > > { > > > > > u32 value; > > > > > > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > > > > > u32 viewport_sel; > > > > > unsigned long flags; > > > > > > > > > > @@ -256,7 +256,7 @@ u16 dw_edma_v0_core_ch_count(struct dw_edma *dw, enum dw_edma_dir dir) > > > > > > > > > > enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > > > > { > > > > > - struct dw_edma *dw = chan->chip->dw; > > > > > + struct dw_edma *dw = chan->dw; > > > > > u32 tmp; > > > > > > > > > > tmp = FIELD_GET(EDMA_V0_CH_STATUS_MASK, > > > > > @@ -272,7 +272,7 @@ enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > > > > > > > > > void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > > > > { > > > > > - struct dw_edma *dw = chan->chip->dw; > > > > > + struct dw_edma *dw = chan->dw; > > > > > > > > > > SET_RW_32(dw, chan->dir, int_clear, > > > > > FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id))); > > > > > @@ -280,7 +280,7 @@ void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > > > > > > > > > void dw_edma_v0_core_clear_abort_int(struct dw_edma_chan *chan) > > > > > { > > > > > - struct dw_edma *dw = chan->chip->dw; > > > > > + struct dw_edma *dw = chan->dw; > > > > > > > > > > SET_RW_32(dw, chan->dir, int_clear, > > > > > FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id))); > > > > > @@ -357,7 +357,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > > > > > void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > > > { > > > > > struct dw_edma_chan *chan = chunk->chan; > > > > > - struct dw_edma *dw = chan->chip->dw; > > > > > + struct dw_edma *dw = chan->dw; > > > > > u32 tmp; > > > > > > > > > > dw_edma_v0_core_write_chunk(chunk); > > > > > @@ -365,7 +365,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > > > if (first) { > > > > > /* Enable engine */ > > > > > SET_RW_32(dw, chan->dir, engine_en, BIT(0)); > > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > > > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > > > > switch (chan->id) { > > > > > case 0: > > > > > SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, > > > > > @@ -431,7 +431,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > > > > > > > > int dw_edma_v0_core_device_config(struct dw_edma_chan *chan) > > > > > { > > > > > - struct dw_edma *dw = chan->chip->dw; > > > > > + struct dw_edma *dw = chan->dw; > > > > > u32 tmp = 0; > > > > > > > > > > /* MSI done addr - low, high */ > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > > > > index 4b3bcffd15ef1..edb7e137cb35a 100644 > > > > > --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > > > > +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > > > > > @@ -54,7 +54,7 @@ struct debugfs_entries { > > > > > static int dw_edma_debugfs_u32_get(void *data, u64 *val) > > > > > { > > > > > void __iomem *reg = (void __force __iomem *)data; > > > > > - if (dw->mf == EDMA_MF_EDMA_LEGACY && > > > > > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY && > > > > > reg >= (void __iomem *)®s->type.legacy.ch) { > > > > > void __iomem *ptr = ®s->type.legacy.ch; > > > > > u32 viewport_sel = 0; > > > > > @@ -173,7 +173,7 @@ static void dw_edma_debugfs_regs_wr(struct dentry *dir) > > > > > nr_entries = ARRAY_SIZE(debugfs_regs); > > > > > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > > > > > > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > > > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > > > > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > > > > > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > > > > > regs_dir); > > > > > @@ -242,7 +242,7 @@ static void dw_edma_debugfs_regs_rd(struct dentry *dir) > > > > > nr_entries = ARRAY_SIZE(debugfs_regs); > > > > > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > > > > > > > > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > > > > > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > > > > > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > > > > > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > > > > > regs_dir); > > > > > @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > > > > > if (!dw) > > > > > return; > > > > > > > > > > - regs = dw->rg_region.vaddr; > > > > > + regs = dw->chip->rg_region.vaddr; > > > > > if (!regs) > > > > > return; > > > > > > > > > > @@ -296,7 +296,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > > > > > if (!dw->debugfs) > > > > > return; > > > > > > > > > > - debugfs_create_u32("mf", 0444, dw->debugfs, &dw->mf); > > > > > + debugfs_create_u32("mf", 0444, dw->debugfs, &dw->chip->mf); > > > > > debugfs_create_u16("wr_ch_cnt", 0444, dw->debugfs, &dw->wr_ch_cnt); > > > > > debugfs_create_u16("rd_ch_cnt", 0444, dw->debugfs, &dw->rd_ch_cnt); > > > > > > > > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > > > > > index cab6e18773dad..a9bee4aeb2eee 100644 > > > > > --- a/include/linux/dma/edma.h > > > > > +++ b/include/linux/dma/edma.h > > > > > @@ -12,19 +12,63 @@ > > > > > #include <linux/device.h> > > > > > #include <linux/dmaengine.h> > > > > > > > > > > +#define EDMA_MAX_WR_CH 8 > > > > > +#define EDMA_MAX_RD_CH 8 > > > > > + > > > > > struct dw_edma; > > > > > > > > > > +struct dw_edma_region { > > > > > + phys_addr_t paddr; > > > > > + void __iomem *vaddr; > > > > > + size_t sz; > > > > > +}; > > > > > + > > > > > +struct dw_edma_core_ops { > > > > > + int (*irq_vector)(struct device *dev, unsigned int nr); > > > > > +}; > > > > > + > > > > > +enum dw_edma_map_format { > > > > > + EDMA_MF_EDMA_LEGACY = 0x0, > > > > > + EDMA_MF_EDMA_UNROLL = 0x1, > > > > > + EDMA_MF_HDMA_COMPAT = 0x5 > > > > > +}; > > > > > + > > > > > /** > > > > > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > > > > > * @dev: struct device of the eDMA controller > > > > > * @id: instance ID > > > > > * @irq: irq line > > > > > + * @nr_irqs: total dma irq number > > > > > + * @ops DMA channel to IRQ number mapping > > > > > + * @wr_ch_cnt DMA write channel number > > > > > + * @rd_ch_cnt DMA read channel number > > > > > + * @rg_region DMA register region > > > > > + * @ll_region_wr DMA descriptor link list memory for write channel > > > > > + * @ll_region_rd DMA descriptor link list memory for read channel > > > > > + * @mf DMA register map format > > > > > * @dw: struct dw_edma that is filed by dw_edma_probe() > > > > > */ > > > > > struct dw_edma_chip { > > > > > struct device *dev; > > > > > int id; > > > > > int irq; > > > > > + int nr_irqs; > > > > > + const struct dw_edma_core_ops *ops; > > > > > + > > > > > + struct dw_edma_region rg_region; > > > > > + > > > > > + u16 wr_ch_cnt; > > > > > + u16 rd_ch_cnt; > > > > > + /* link list address */ > > > > > + struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > > > > + struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > > > > + > > > > > + /* data region */ > > > > > + struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > > > > > + struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > > > > > + > > > > > + enum dw_edma_map_format mf; > > > > > + > > > > > > > > > struct dw_edma *dw; > > > > > > > > Please drop this field from here and just change the dw_edma_probe() > > > > prototype to returning a pointer to the struct dw_edma structure. Like > > > > this: > > > > struct dw_edma *dw_edma_probe(const struct dw_edma_chip *chip); > > > > void dw_edma_remove(struct dw_edma *dw); > > > > > > > > Actually, I don't think it is good to drop it now. > > > > > > struct dw_edma *dw_edma_probe(const struct dw_edma_chip *chip); > > > > > > Users likely put struct dw_edma_chip in stack. > > > foo() > > > { > > > struct dw_edma_chip chip > > > dw = dw_edma_proble(&chip); > > > } > > > > > > but now, edma_core_driver still does not save chip information to dw_edma > > > > Neither current implementation nor implementation suggested by me > > permits having the struct dw_edma_chip structure instance allocated on > > stack, > > Yes, but original implement > int dw_edma_probe(struct dw_edma_chip *chip) > int dw_edma_remove (struct dw_edma_chip *chip) > > User knows the chip will be used at remove, so it will be saved in a safe place. > > struct dw_edma* dw_edma_probe(struct dw_edma_chip*chip) > look like chip only use once when call dw_edma_probe, > User most like use stack if he don't read dw_edma_probe's implement. > > > since the pointer to the structure is then preserved in the > > dw_edma all the way until the device/driver isn't removed (it will > > require some more modifications, which I can't request from you). > > What approach proposed by me provides is a way to statically define > > the struct dw_edma_chip object. Seeing the eDMA driver doesn't change > > the structure fields we can extend the API functionality. In this > > case the probe()/remote() methods semantics turns to be cleaner and > > looking more like the i2c-board-info design. > > I grep probe under include/*, I found most *_probe() function return int, > I think a benefit is It can return different error codes, especially > EPROBE_DEFER. > Of course, EPROBE_DEFER will not happen in this case. But I think > it'd be better > to follow common sense. > > > That we'll be able to > > gain almost with no much efforts. Just fix the > > dw_edma_probe()/dw_edma_remove() method prototype as I suggested > > (Don't forget the const-modifier in the probe argument and in the > > dw_edma.dw field). > > It is not an effort problem. Just which one is better and prevents > some protiental > problems and is easy to use. Seems reasonable now. Thanks for elaborating your intentions. No objections against the suggested approach then. -Serge > > I suggest we can move this change to future patch, which save chip > info to dw_edma > and don't direct refer chip, which pass down at dw_edma_probe() > > > > > -Sergey > > > > > > > > > > > > > By doing so we'll be able to have the chip data being const and at least > > > > statically defined. > > > > > > > > -Sergey > > > > > > > > > }; > > > > > > > > > > -- > > > > > 2.24.0.rc1 > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures 2022-03-09 21:11 ` [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures Frank Li 2022-03-10 12:50 ` Serge Semin 2022-03-10 20:20 ` Serge Semin @ 2022-03-12 19:54 ` Serge Semin 2 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-12 19:54 UTC (permalink / raw) To: Frank Li Cc: Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam On Wed, Mar 09, 2022 at 03:11:57PM -0600, Frank Li wrote: > "struct dw_edma_chip" contains an internal structure "struct dw_edma" that > is used by the eDMA core internally. This structure should not be touched > by the eDMA controller drivers themselves. But currently, the eDMA > controller drivers like "dw-edma-pci" allocates and populates this > internal structure then passes it on to eDMA core. The eDMA core further > populates the structure and uses it. This is wrong! > > Hence, move all the "struct dw_edma" specifics from controller drivers > to the eDMA core. > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > Change from v3 to v4 > - Accept most suggestions of Serge Semin > Change from v2 to v3 > - none > Change from v1 to v2 > - rework commit message > - remove duplicate field in struct dw_edma > > drivers/dma/dw-edma/dw-edma-core.c | 81 +++++++++++++---------- > drivers/dma/dw-edma/dw-edma-core.h | 32 +-------- > drivers/dma/dw-edma/dw-edma-pcie.c | 83 ++++++++++-------------- > drivers/dma/dw-edma/dw-edma-v0-core.c | 24 +++---- > drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 10 +-- > include/linux/dma/edma.h | 44 +++++++++++++ > 6 files changed, 144 insertions(+), 130 deletions(-) > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > index 53289927dd0d6..1abf41d49f75b 100644 > --- a/drivers/dma/dw-edma/dw-edma-core.c > +++ b/drivers/dma/dw-edma/dw-edma-core.c > @@ -65,7 +65,7 @@ static struct dw_edma_burst *dw_edma_alloc_burst(struct dw_edma_chunk *chunk) > static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > { > struct dw_edma_chan *chan = desc->chan; > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma_chip *chip = chan->dw->chip; > struct dw_edma_chunk *chunk; > > chunk = kzalloc(sizeof(*chunk), GFP_NOWAIT); > @@ -82,11 +82,11 @@ static struct dw_edma_chunk *dw_edma_alloc_chunk(struct dw_edma_desc *desc) > */ > chunk->cb = !(desc->chunks_alloc % 2); > if (chan->dir == EDMA_DIR_WRITE) { > - chunk->ll_region.paddr = dw->ll_region_wr[chan->id].paddr; > - chunk->ll_region.vaddr = dw->ll_region_wr[chan->id].vaddr; > + chunk->ll_region.paddr = chip->ll_region_wr[chan->id].paddr; > + chunk->ll_region.vaddr = chip->ll_region_wr[chan->id].vaddr; > } else { > - chunk->ll_region.paddr = dw->ll_region_rd[chan->id].paddr; > - chunk->ll_region.vaddr = dw->ll_region_rd[chan->id].vaddr; > + chunk->ll_region.paddr = chip->ll_region_rd[chan->id].paddr; > + chunk->ll_region.vaddr = chip->ll_region_rd[chan->id].vaddr; > } > > if (desc->chunk) { > @@ -664,7 +664,7 @@ static int dw_edma_alloc_chan_resources(struct dma_chan *dchan) > if (chan->status != EDMA_ST_IDLE) > return -EBUSY; > > - pm_runtime_get(chan->chip->dev); > + pm_runtime_get(chan->dw->chip->dev); > > return 0; > } > @@ -686,7 +686,7 @@ static void dw_edma_free_chan_resources(struct dma_chan *dchan) > cpu_relax(); > } > > - pm_runtime_put(chan->chip->dev); > + pm_runtime_put(chan->dw->chip->dev); > } > > static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > @@ -718,7 +718,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, Please convert the dw_edma_channel_setup() and dw_edma_irq_request() methods to accepting struct dw_edma *dw instead of struct dw_edma_chip *chip. Thus we'll have the DW eDMA private data-based internal implementation is it was originally intended. The chip-info will only be used as a part of the probe/remove interface. > } > > INIT_LIST_HEAD(&dma->channels); > - for (j = 0; (alloc || dw->nr_irqs == 1) && j < cnt; j++, i++) { > + for (j = 0; (alloc || chip->nr_irqs == 1) && j < cnt; j++, i++) { > chan = &dw->chan[i]; > > dt_region = devm_kzalloc(dev, sizeof(*dt_region), GFP_KERNEL); > @@ -727,7 +727,7 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > > chan->vc.chan.private = dt_region; > > - chan->chip = chip; > + chan->dw = dw; > chan->id = j; > chan->dir = write ? EDMA_DIR_WRITE : EDMA_DIR_READ; > chan->configured = false; > @@ -735,15 +735,15 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > chan->status = EDMA_ST_IDLE; > > if (write) > - chan->ll_max = (dw->ll_region_wr[j].sz / EDMA_LL_SZ); > + chan->ll_max = (chip->ll_region_wr[j].sz / EDMA_LL_SZ); > else > - chan->ll_max = (dw->ll_region_rd[j].sz / EDMA_LL_SZ); > + chan->ll_max = (chip->ll_region_rd[j].sz / EDMA_LL_SZ); > chan->ll_max -= 1; > > dev_vdbg(dev, "L. List:\tChannel %s[%u] max_cnt=%u\n", > write ? "write" : "read", j, chan->ll_max); > > - if (dw->nr_irqs == 1) > + if (chip->nr_irqs == 1) > pos = 0; > else > pos = off_alloc + (j % alloc); > @@ -767,13 +767,13 @@ static int dw_edma_channel_setup(struct dw_edma_chip *chip, bool write, > vchan_init(&chan->vc, dma); > > if (write) { > - dt_region->paddr = dw->dt_region_wr[j].paddr; > - dt_region->vaddr = dw->dt_region_wr[j].vaddr; > - dt_region->sz = dw->dt_region_wr[j].sz; > + dt_region->paddr = chip->dt_region_wr[j].paddr; > + dt_region->vaddr = chip->dt_region_wr[j].vaddr; > + dt_region->sz = chip->dt_region_wr[j].sz; > } else { > - dt_region->paddr = dw->dt_region_rd[j].paddr; > - dt_region->vaddr = dw->dt_region_rd[j].vaddr; > - dt_region->sz = dw->dt_region_rd[j].sz; > + dt_region->paddr = chip->dt_region_rd[j].paddr; > + dt_region->vaddr = chip->dt_region_rd[j].vaddr; > + dt_region->sz = chip->dt_region_rd[j].sz; > } > > dw_edma_v0_core_device_config(chan); > @@ -840,16 +840,16 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > > ch_cnt = dw->wr_ch_cnt + dw->rd_ch_cnt; > > - if (dw->nr_irqs < 1) > + if (chip->nr_irqs < 1) > return -EINVAL; > > - if (dw->nr_irqs == 1) { > + if (chip->nr_irqs == 1) { > /* Common IRQ shared among all channels */ > - irq = dw->ops->irq_vector(dev, 0); > + irq = chip->ops->irq_vector(dev, 0); > err = request_irq(irq, dw_edma_interrupt_common, > IRQF_SHARED, dw->name, &dw->irq[0]); > if (err) { > - dw->nr_irqs = 0; > + chip->nr_irqs = 0; > return err; > } > > @@ -857,7 +857,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > get_cached_msi_msg(irq, &dw->irq[0].msi); > } else { > /* Distribute IRQs equally among all channels */ > - int tmp = dw->nr_irqs; > + int tmp = chip->nr_irqs; > > while (tmp && (*wr_alloc + *rd_alloc) < ch_cnt) { > dw_edma_dec_irq_alloc(&tmp, wr_alloc, dw->wr_ch_cnt); > @@ -868,7 +868,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > dw_edma_add_irq_mask(&rd_mask, *rd_alloc, dw->rd_ch_cnt); > > for (i = 0; i < (*wr_alloc + *rd_alloc); i++) { > - irq = dw->ops->irq_vector(dev, i); > + irq = chip->ops->irq_vector(dev, i); > err = request_irq(irq, > i < *wr_alloc ? > dw_edma_interrupt_write : > @@ -876,7 +876,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > IRQF_SHARED, dw->name, > &dw->irq[i]); > if (err) { > - dw->nr_irqs = i; > + chip->nr_irqs = i; > return err; > } > > @@ -884,7 +884,7 @@ static int dw_edma_irq_request(struct dw_edma_chip *chip, > get_cached_msi_msg(irq, &dw->irq[i].msi); > } > > - dw->nr_irqs = i; > + chip->nr_irqs = i; > } > > return err; > @@ -905,17 +905,24 @@ int dw_edma_probe(struct dw_edma_chip *chip) > if (!dev) > return -EINVAL; > > - dw = chip->dw; > - if (!dw || !dw->irq || !dw->ops || !dw->ops->irq_vector) > + dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > + if (!dw) > + return -ENOMEM; > + > + chip->dw = dw; > + dw->chip = chip; > + > + if (!chip->nr_irqs || !chip->ops) > return -EINVAL; > > raw_spin_lock_init(&dw->lock); > > - dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, > + Redundant empty line. Please drop it. -Sergey > + dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > - dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, > + dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > @@ -936,6 +943,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > /* Disable eDMA, only to establish the ideal initial conditions */ > dw_edma_v0_core_off(dw); > > + dw->irq = devm_kcalloc(dev, chip->nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > + if (!dw->irq) > + return -ENOMEM; > + > /* Request IRQs */ > err = dw_edma_irq_request(chip, &wr_alloc, &rd_alloc); > if (err) > @@ -960,10 +971,10 @@ int dw_edma_probe(struct dw_edma_chip *chip) > return 0; > > err_irq_free: > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > - dw->nr_irqs = 0; > + chip->nr_irqs = 0; > > return err; > } > @@ -980,8 +991,8 @@ int dw_edma_remove(struct dw_edma_chip *chip) > dw_edma_v0_core_off(dw); > > /* Free irqs */ > - for (i = (dw->nr_irqs - 1); i >= 0; i--) > - free_irq(dw->ops->irq_vector(dev, i), &dw->irq[i]); > + for (i = (chip->nr_irqs - 1); i >= 0; i--) > + free_irq(chip->ops->irq_vector(dev, i), &dw->irq[i]); > > /* Power management */ > pm_runtime_disable(dev); > diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h > index 60316d408c3e0..e254c2fc3d9cf 100644 > --- a/drivers/dma/dw-edma/dw-edma-core.h > +++ b/drivers/dma/dw-edma/dw-edma-core.h > @@ -15,20 +15,12 @@ > #include "../virt-dma.h" > > #define EDMA_LL_SZ 24 > -#define EDMA_MAX_WR_CH 8 > -#define EDMA_MAX_RD_CH 8 > > enum dw_edma_dir { > EDMA_DIR_WRITE = 0, > EDMA_DIR_READ > }; > > -enum dw_edma_map_format { > - EDMA_MF_EDMA_LEGACY = 0x0, > - EDMA_MF_EDMA_UNROLL = 0x1, > - EDMA_MF_HDMA_COMPAT = 0x5 > -}; > - > enum dw_edma_request { > EDMA_REQ_NONE = 0, > EDMA_REQ_STOP, > @@ -57,12 +49,6 @@ struct dw_edma_burst { > u32 sz; > }; > > -struct dw_edma_region { > - phys_addr_t paddr; > - void __iomem *vaddr; > - size_t sz; > -}; > - > struct dw_edma_chunk { > struct list_head list; > struct dw_edma_chan *chan; > @@ -87,7 +73,7 @@ struct dw_edma_desc { > > struct dw_edma_chan { > struct virt_dma_chan vc; > - struct dw_edma_chip *chip; > + struct dw_edma *dw; > int id; > enum dw_edma_dir dir; > > @@ -109,10 +95,6 @@ struct dw_edma_irq { > struct dw_edma *dw; > }; > > -struct dw_edma_core_ops { > - int (*irq_vector)(struct device *dev, unsigned int nr); > -}; > - > struct dw_edma { > char name[20]; > > @@ -122,21 +104,13 @@ struct dw_edma { > struct dma_device rd_edma; > u16 rd_ch_cnt; > > - struct dw_edma_region rg_region; /* Registers */ > - struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > - struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > - struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > - struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > - > struct dw_edma_irq *irq; > - int nr_irqs; > - > - enum dw_edma_map_format mf; > > struct dw_edma_chan *chan; > - const struct dw_edma_core_ops *ops; > > raw_spinlock_t lock; /* Only for legacy */ > + > + struct dw_edma_chip *chip; > #ifdef CONFIG_DEBUG_FS > struct dentry *debugfs; > #endif /* CONFIG_DEBUG_FS */ > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > index 44f6e09bdb531..2c1c5fa4e9f28 100644 > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > @@ -148,7 +148,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > struct dw_edma_pcie_data vsec_data; > struct device *dev = &pdev->dev; > struct dw_edma_chip *chip; > - struct dw_edma *dw; > int err, nr_irqs; > int i, mask; > > @@ -214,10 +213,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > if (!chip) > return -ENOMEM; > > - dw = devm_kzalloc(dev, sizeof(*dw), GFP_KERNEL); > - if (!dw) > - return -ENOMEM; > - > /* IRQs allocation */ > nr_irqs = pci_alloc_irq_vectors(pdev, 1, vsec_data.irqs, > PCI_IRQ_MSI | PCI_IRQ_MSIX); > @@ -228,29 +223,23 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > } > > /* Data structure initialization */ > - chip->dw = dw; > chip->dev = dev; > chip->id = pdev->devfn; > - chip->irq = pdev->irq; > > - dw->mf = vsec_data.mf; > - dw->nr_irqs = nr_irqs; > - dw->ops = &dw_edma_pcie_core_ops; > - dw->wr_ch_cnt = vsec_data.wr_ch_cnt; > - dw->rd_ch_cnt = vsec_data.rd_ch_cnt; > + chip->mf = vsec_data.mf; > + chip->nr_irqs = nr_irqs; > + chip->ops = &dw_edma_pcie_core_ops; > > - dw->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > - if (!dw->rg_region.vaddr) > - return -ENOMEM; > + chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > + chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > - dw->rg_region.vaddr += vsec_data.rg.off; > - dw->rg_region.paddr = pdev->resource[vsec_data.rg.bar].start; > - dw->rg_region.paddr += vsec_data.rg.off; > - dw->rg_region.sz = vsec_data.rg.sz; > + chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > + if (!chip->rg_region.vaddr) > + return -ENOMEM; > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > - struct dw_edma_region *ll_region = &dw->ll_region_wr[i]; > - struct dw_edma_region *dt_region = &dw->dt_region_wr[i]; > + for (i = 0; i < chip->wr_ch_cnt; i++) { > + struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > + struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > struct dw_edma_block *dt_block = &vsec_data.dt_wr[i]; > > @@ -273,9 +262,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > dt_region->sz = dt_block->sz; > } > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > - struct dw_edma_region *ll_region = &dw->ll_region_rd[i]; > - struct dw_edma_region *dt_region = &dw->dt_region_rd[i]; > + for (i = 0; i < chip->rd_ch_cnt; i++) { > + struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > + struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > struct dw_edma_block *dt_block = &vsec_data.dt_rd[i]; > > @@ -299,45 +288,45 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > } > > /* Debug info */ > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > - pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", dw->mf); > - else if (dw->mf == EDMA_MF_EDMA_UNROLL) > - pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", dw->mf); > - else if (dw->mf == EDMA_MF_HDMA_COMPAT) > - pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", dw->mf); > + if (chip->mf == EDMA_MF_EDMA_LEGACY) > + pci_dbg(pdev, "Version:\teDMA Port Logic (0x%x)\n", chip->mf); > + else if (chip->mf == EDMA_MF_EDMA_UNROLL) > + pci_dbg(pdev, "Version:\teDMA Unroll (0x%x)\n", chip->mf); > + else if (chip->mf == EDMA_MF_HDMA_COMPAT) > + pci_dbg(pdev, "Version:\tHDMA Compatible (0x%x)\n", chip->mf); > else > - pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", dw->mf); > + pci_dbg(pdev, "Version:\tUnknown (0x%x)\n", chip->mf); > > - pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > + pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", > vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, > - dw->rg_region.vaddr, &dw->rg_region.paddr); > + chip->rg_region.vaddr); > > > - for (i = 0; i < dw->wr_ch_cnt; i++) { > + for (i = 0; i < chip->wr_ch_cnt; i++) { > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.ll_wr[i].bar, > - vsec_data.ll_wr[i].off, dw->ll_region_wr[i].sz, > - dw->ll_region_wr[i].vaddr, &dw->ll_region_wr[i].paddr); > + vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > + chip->ll_region_wr[i].vaddr, &chip->ll_region_wr[i].paddr); > > pci_dbg(pdev, "Data:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.dt_wr[i].bar, > - vsec_data.dt_wr[i].off, dw->dt_region_wr[i].sz, > - dw->dt_region_wr[i].vaddr, &dw->dt_region_wr[i].paddr); > + vsec_data.dt_wr[i].off, chip->dt_region_wr[i].sz, > + chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > } > > - for (i = 0; i < dw->rd_ch_cnt; i++) { > + for (i = 0; i < chip->rd_ch_cnt; i++) { > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.ll_rd[i].bar, > - vsec_data.ll_rd[i].off, dw->ll_region_rd[i].sz, > - dw->ll_region_rd[i].vaddr, &dw->ll_region_rd[i].paddr); > + vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > + chip->ll_region_rd[i].vaddr, &chip->ll_region_rd[i].paddr); > > pci_dbg(pdev, "Data:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.dt_rd[i].bar, > - vsec_data.dt_rd[i].off, dw->dt_region_rd[i].sz, > - dw->dt_region_rd[i].vaddr, &dw->dt_region_rd[i].paddr); > + vsec_data.dt_rd[i].off, chip->dt_region_rd[i].sz, > + chip->dt_region_rd[i].vaddr, &chip->dt_region_rd[i].paddr); > } > > - pci_dbg(pdev, "Nr. IRQs:\t%u\n", dw->nr_irqs); > + pci_dbg(pdev, "Nr. IRQs:\t%u\n", chip->nr_irqs); > > /* Validating if PCI interrupts were enabled */ > if (!pci_dev_msi_enabled(pdev)) { > @@ -345,10 +334,6 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > return -EPERM; > } > > - dw->irq = devm_kcalloc(dev, nr_irqs, sizeof(*dw->irq), GFP_KERNEL); > - if (!dw->irq) > - return -ENOMEM; > - > /* Starting eDMA driver */ > err = dw_edma_probe(chip); > if (err) { > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > index 329fc2e57b703..e507e076fad16 100644 > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > @@ -25,7 +25,7 @@ enum dw_edma_control { > > static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > { > - return dw->rg_region.vaddr; > + return dw->chip->rg_region.vaddr; > } > > #define SET_32(dw, name, value) \ > @@ -96,7 +96,7 @@ static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > static inline struct dw_edma_v0_ch_regs __iomem * > __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > { > - if (dw->mf == EDMA_MF_EDMA_LEGACY) > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) > return &(__dw_regs(dw)->type.legacy.ch); > > if (dir == EDMA_DIR_WRITE) > @@ -108,7 +108,7 @@ __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch) > static inline void writel_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > u32 value, void __iomem *addr) > { > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -133,7 +133,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > { > u32 value; > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -169,7 +169,7 @@ static inline u32 readl_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > static inline void writeq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > u64 value, void __iomem *addr) > { > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -194,7 +194,7 @@ static inline u64 readq_ch(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch, > { > u32 value; > > - if (dw->mf == EDMA_MF_EDMA_LEGACY) { > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY) { > u32 viewport_sel; > unsigned long flags; > > @@ -256,7 +256,7 @@ u16 dw_edma_v0_core_ch_count(struct dw_edma *dw, enum dw_edma_dir dir) > > enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > u32 tmp; > > tmp = FIELD_GET(EDMA_V0_CH_STATUS_MASK, > @@ -272,7 +272,7 @@ enum dma_status dw_edma_v0_core_ch_status(struct dw_edma_chan *chan) > > void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > > SET_RW_32(dw, chan->dir, int_clear, > FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id))); > @@ -280,7 +280,7 @@ void dw_edma_v0_core_clear_done_int(struct dw_edma_chan *chan) > > void dw_edma_v0_core_clear_abort_int(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > > SET_RW_32(dw, chan->dir, int_clear, > FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id))); > @@ -357,7 +357,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > { > struct dw_edma_chan *chan = chunk->chan; > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > u32 tmp; > > dw_edma_v0_core_write_chunk(chunk); > @@ -365,7 +365,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > if (first) { > /* Enable engine */ > SET_RW_32(dw, chan->dir, engine_en, BIT(0)); > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > switch (chan->id) { > case 0: > SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, > @@ -431,7 +431,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > int dw_edma_v0_core_device_config(struct dw_edma_chan *chan) > { > - struct dw_edma *dw = chan->chip->dw; > + struct dw_edma *dw = chan->dw; > u32 tmp = 0; > > /* MSI done addr - low, high */ > diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > index 4b3bcffd15ef1..edb7e137cb35a 100644 > --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > @@ -54,7 +54,7 @@ struct debugfs_entries { > static int dw_edma_debugfs_u32_get(void *data, u64 *val) > { > void __iomem *reg = (void __force __iomem *)data; > - if (dw->mf == EDMA_MF_EDMA_LEGACY && > + if (dw->chip->mf == EDMA_MF_EDMA_LEGACY && > reg >= (void __iomem *)®s->type.legacy.ch) { > void __iomem *ptr = ®s->type.legacy.ch; > u32 viewport_sel = 0; > @@ -173,7 +173,7 @@ static void dw_edma_debugfs_regs_wr(struct dentry *dir) > nr_entries = ARRAY_SIZE(debugfs_regs); > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > regs_dir); > @@ -242,7 +242,7 @@ static void dw_edma_debugfs_regs_rd(struct dentry *dir) > nr_entries = ARRAY_SIZE(debugfs_regs); > dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir); > > - if (dw->mf == EDMA_MF_HDMA_COMPAT) { > + if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { > nr_entries = ARRAY_SIZE(debugfs_unroll_regs); > dw_edma_debugfs_create_x32(debugfs_unroll_regs, nr_entries, > regs_dir); > @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > if (!dw) > return; > > - regs = dw->rg_region.vaddr; > + regs = dw->chip->rg_region.vaddr; > if (!regs) > return; > > @@ -296,7 +296,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > if (!dw->debugfs) > return; > > - debugfs_create_u32("mf", 0444, dw->debugfs, &dw->mf); > + debugfs_create_u32("mf", 0444, dw->debugfs, &dw->chip->mf); > debugfs_create_u16("wr_ch_cnt", 0444, dw->debugfs, &dw->wr_ch_cnt); > debugfs_create_u16("rd_ch_cnt", 0444, dw->debugfs, &dw->rd_ch_cnt); > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > index cab6e18773dad..a9bee4aeb2eee 100644 > --- a/include/linux/dma/edma.h > +++ b/include/linux/dma/edma.h > @@ -12,19 +12,63 @@ > #include <linux/device.h> > #include <linux/dmaengine.h> > > +#define EDMA_MAX_WR_CH 8 > +#define EDMA_MAX_RD_CH 8 > + > struct dw_edma; > > +struct dw_edma_region { > + phys_addr_t paddr; > + void __iomem *vaddr; > + size_t sz; > +}; > + > +struct dw_edma_core_ops { > + int (*irq_vector)(struct device *dev, unsigned int nr); > +}; > + > +enum dw_edma_map_format { > + EDMA_MF_EDMA_LEGACY = 0x0, > + EDMA_MF_EDMA_UNROLL = 0x1, > + EDMA_MF_HDMA_COMPAT = 0x5 > +}; > + > /** > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > * @dev: struct device of the eDMA controller > * @id: instance ID > * @irq: irq line > + * @nr_irqs: total dma irq number > + * @ops DMA channel to IRQ number mapping > + * @wr_ch_cnt DMA write channel number > + * @rd_ch_cnt DMA read channel number > + * @rg_region DMA register region > + * @ll_region_wr DMA descriptor link list memory for write channel > + * @ll_region_rd DMA descriptor link list memory for read channel > + * @mf DMA register map format > * @dw: struct dw_edma that is filed by dw_edma_probe() > */ > struct dw_edma_chip { > struct device *dev; > int id; > int irq; > + int nr_irqs; > + const struct dw_edma_core_ops *ops; > + > + struct dw_edma_region rg_region; > + > + u16 wr_ch_cnt; > + u16 rd_ch_cnt; > + /* link list address */ > + struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > + struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > + > + /* data region */ > + struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH]; > + struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH]; > + > + enum dw_edma_map_format mf; > + > struct dw_edma *dw; > }; > > -- > 2.24.0.rc1 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v4 2/8] dmaengine: dw-edma: remove unused field irq in struct dw_edma_chip 2022-03-09 21:11 [PATCH v4 0/8] Enable designware PCI EP EDMA locally Frank Li 2022-03-09 21:11 ` [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures Frank Li @ 2022-03-09 21:11 ` Frank Li 2022-03-10 12:52 ` Serge Semin 2022-03-09 21:11 ` [PATCH v4 3/8] dmaengine: dw-edma: change rg_region to reg_base " Frank Li ` (5 subsequent siblings) 7 siblings, 1 reply; 52+ messages in thread From: Frank Li @ 2022-03-09 21:11 UTC (permalink / raw) To: gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam irq of struct dw_edma_chip was never used. It can be removed safely. Signed-off-by: Frank Li <Frank.Li@nxp.com> --- new patch at v4 include/linux/dma/edma.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h index a9bee4aeb2eee..6fd374cc72c8e 100644 --- a/include/linux/dma/edma.h +++ b/include/linux/dma/edma.h @@ -37,7 +37,6 @@ enum dw_edma_map_format { * struct dw_edma_chip - representation of DesignWare eDMA controller hardware * @dev: struct device of the eDMA controller * @id: instance ID - * @irq: irq line * @nr_irqs: total dma irq number * @ops DMA channel to IRQ number mapping * @wr_ch_cnt DMA write channel number @@ -51,7 +50,6 @@ enum dw_edma_map_format { struct dw_edma_chip { struct device *dev; int id; - int irq; int nr_irqs; const struct dw_edma_core_ops *ops; -- 2.24.0.rc1 ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v4 2/8] dmaengine: dw-edma: remove unused field irq in struct dw_edma_chip 2022-03-09 21:11 ` [PATCH v4 2/8] dmaengine: dw-edma: remove unused field irq in struct dw_edma_chip Frank Li @ 2022-03-10 12:52 ` Serge Semin 0 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-10 12:52 UTC (permalink / raw) To: Frank Li Cc: Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam On Wed, Mar 09, 2022 at 03:11:58PM -0600, Frank Li wrote: > irq of struct dw_edma_chip was never used. > It can be removed safely. The patch is incomplete. See drivers/dma/dw-edma/dw-edma-pcie.c:234. The irq field is initialized there. But it's never used afterwards. So you need to fix the dw-edma-pcie.c driver too by dropping the corresponding initialization, otherwise the driver will fail to be built. -Sergey > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > new patch at v4 > > include/linux/dma/edma.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > index a9bee4aeb2eee..6fd374cc72c8e 100644 > --- a/include/linux/dma/edma.h > +++ b/include/linux/dma/edma.h > @@ -37,7 +37,6 @@ enum dw_edma_map_format { > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > * @dev: struct device of the eDMA controller > * @id: instance ID > - * @irq: irq line > * @nr_irqs: total dma irq number > * @ops DMA channel to IRQ number mapping > * @wr_ch_cnt DMA write channel number > @@ -51,7 +50,6 @@ enum dw_edma_map_format { > struct dw_edma_chip { > struct device *dev; > int id; > - int irq; > int nr_irqs; > const struct dw_edma_core_ops *ops; > > -- > 2.24.0.rc1 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v4 3/8] dmaengine: dw-edma: change rg_region to reg_base in struct dw_edma_chip 2022-03-09 21:11 [PATCH v4 0/8] Enable designware PCI EP EDMA locally Frank Li 2022-03-09 21:11 ` [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures Frank Li 2022-03-09 21:11 ` [PATCH v4 2/8] dmaengine: dw-edma: remove unused field irq in struct dw_edma_chip Frank Li @ 2022-03-09 21:11 ` Frank Li 2022-03-10 12:56 ` Serge Semin 2022-03-09 21:12 ` [PATCH v4 4/8] dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt " Frank Li ` (4 subsequent siblings) 7 siblings, 1 reply; 52+ messages in thread From: Frank Li @ 2022-03-09 21:11 UTC (permalink / raw) To: gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam struct dw_edma_region rg_region included virtual address, physical address and size informaiton. But only virtual address is used by EDMA driver. Change it to void __iomem *reg_base to clean up code. Signed-off-by: Frank Li <Frank.Li@nxp.com> --- New patch at v4 drivers/dma/dw-edma/dw-edma-pcie.c | 6 +++--- drivers/dma/dw-edma/dw-edma-v0-core.c | 2 +- drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 2 +- include/linux/dma/edma.h | 3 ++- 4 files changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c index 2c1c5fa4e9f28..ae42bad24dd5a 100644 --- a/drivers/dma/dw-edma/dw-edma-pcie.c +++ b/drivers/dma/dw-edma/dw-edma-pcie.c @@ -233,8 +233,8 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, chip->wr_ch_cnt = vsec_data.wr_ch_cnt; chip->rd_ch_cnt = vsec_data.rd_ch_cnt; - chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; - if (!chip->rg_region.vaddr) + chip->reg_base = pcim_iomap_table(pdev)[vsec_data.rg.bar]; + if (!chip->reg_base) return -ENOMEM; for (i = 0; i < chip->wr_ch_cnt; i++) { @@ -299,7 +299,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, - chip->rg_region.vaddr); + chip->reg_base); for (i = 0; i < chip->wr_ch_cnt; i++) { diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c index e507e076fad16..35f2adac93e46 100644 --- a/drivers/dma/dw-edma/dw-edma-v0-core.c +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c @@ -25,7 +25,7 @@ enum dw_edma_control { static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) { - return dw->chip->rg_region.vaddr; + return dw->chip->reg_base; } #define SET_32(dw, name, value) \ diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c index edb7e137cb35a..3a899f7f4e8d8 100644 --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) if (!dw) return; - regs = dw->chip->rg_region.vaddr; + regs = dw->chip->reg_base; if (!regs) return; diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h index 6fd374cc72c8e..e9ce652b88233 100644 --- a/include/linux/dma/edma.h +++ b/include/linux/dma/edma.h @@ -39,6 +39,7 @@ enum dw_edma_map_format { * @id: instance ID * @nr_irqs: total dma irq number * @ops DMA channel to IRQ number mapping + * @reg_base DMA register base address * @wr_ch_cnt DMA write channel number * @rd_ch_cnt DMA read channel number * @rg_region DMA register region @@ -53,7 +54,7 @@ struct dw_edma_chip { int nr_irqs; const struct dw_edma_core_ops *ops; - struct dw_edma_region rg_region; + void __iomem *reg_base; u16 wr_ch_cnt; u16 rd_ch_cnt; -- 2.24.0.rc1 ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v4 3/8] dmaengine: dw-edma: change rg_region to reg_base in struct dw_edma_chip 2022-03-09 21:11 ` [PATCH v4 3/8] dmaengine: dw-edma: change rg_region to reg_base " Frank Li @ 2022-03-10 12:56 ` Serge Semin 0 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-10 12:56 UTC (permalink / raw) To: Frank Li Cc: Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam On Wed, Mar 09, 2022 at 03:11:59PM -0600, Frank Li wrote: > struct dw_edma_region rg_region included virtual address, physical > address and size informaiton. But only virtual address is used by EDMA > driver. Change it to void __iomem *reg_base to clean up code. Right, the driver doesn't use neither physical address nor size of the CSRs MMIO region, and most likely will never start using it. They are just redundant for the CSR space. Reviewed-by: Serge Semin <fancer.lancer@gmail.com> > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > New patch at v4 > > drivers/dma/dw-edma/dw-edma-pcie.c | 6 +++--- > drivers/dma/dw-edma/dw-edma-v0-core.c | 2 +- > drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 2 +- > include/linux/dma/edma.h | 3 ++- > 4 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > index 2c1c5fa4e9f28..ae42bad24dd5a 100644 > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > @@ -233,8 +233,8 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > - chip->rg_region.vaddr = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > - if (!chip->rg_region.vaddr) > + chip->reg_base = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > + if (!chip->reg_base) > return -ENOMEM; > > for (i = 0; i < chip->wr_ch_cnt; i++) { > @@ -299,7 +299,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > pci_dbg(pdev, "Registers:\tBAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p)\n", > vsec_data.rg.bar, vsec_data.rg.off, vsec_data.rg.sz, > - chip->rg_region.vaddr); > + chip->reg_base); > > > for (i = 0; i < chip->wr_ch_cnt; i++) { > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > index e507e076fad16..35f2adac93e46 100644 > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > @@ -25,7 +25,7 @@ enum dw_edma_control { > > static inline struct dw_edma_v0_regs __iomem *__dw_regs(struct dw_edma *dw) > { > - return dw->chip->rg_region.vaddr; > + return dw->chip->reg_base; > } > > #define SET_32(dw, name, value) \ > diff --git a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > index edb7e137cb35a..3a899f7f4e8d8 100644 > --- a/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > +++ b/drivers/dma/dw-edma/dw-edma-v0-debugfs.c > @@ -288,7 +288,7 @@ void dw_edma_v0_debugfs_on(struct dw_edma_chip *chip) > if (!dw) > return; > > - regs = dw->chip->rg_region.vaddr; > + regs = dw->chip->reg_base; > if (!regs) > return; > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > index 6fd374cc72c8e..e9ce652b88233 100644 > --- a/include/linux/dma/edma.h > +++ b/include/linux/dma/edma.h > @@ -39,6 +39,7 @@ enum dw_edma_map_format { > * @id: instance ID > * @nr_irqs: total dma irq number > * @ops DMA channel to IRQ number mapping > + * @reg_base DMA register base address > * @wr_ch_cnt DMA write channel number > * @rd_ch_cnt DMA read channel number > * @rg_region DMA register region > @@ -53,7 +54,7 @@ struct dw_edma_chip { > int nr_irqs; > const struct dw_edma_core_ops *ops; > > - struct dw_edma_region rg_region; > + void __iomem *reg_base; > > u16 wr_ch_cnt; > u16 rd_ch_cnt; > -- > 2.24.0.rc1 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v4 4/8] dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt in struct dw_edma_chip 2022-03-09 21:11 [PATCH v4 0/8] Enable designware PCI EP EDMA locally Frank Li ` (2 preceding siblings ...) 2022-03-09 21:11 ` [PATCH v4 3/8] dmaengine: dw-edma: change rg_region to reg_base " Frank Li @ 2022-03-09 21:12 ` Frank Li 2022-03-10 12:37 ` Serge Semin 2022-03-09 21:12 ` [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep Frank Li ` (3 subsequent siblings) 7 siblings, 1 reply; 52+ messages in thread From: Frank Li @ 2022-03-09 21:12 UTC (permalink / raw) To: gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam There are same name wr(rd)_ch_cnt in struct dw_edma. EDMA driver get write(read) channel number from register, then save these into dw_edma. Old wr(rd)_ch_cnt in dw_edma_chip actuall means how many link list memory are avaiable in ll_region_wr(rd)[EDMA_MAX_WR_CH]. So rename it to ll_wr(rd)_cnt to indicate actual usage. Signed-off-by: Frank Li <Frank.Li@nxp.com> --- new patch at v4 drivers/dma/dw-edma/dw-edma-core.c | 4 ++-- drivers/dma/dw-edma/dw-edma-pcie.c | 12 ++++++------ include/linux/dma/edma.h | 8 ++++---- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c index 1abf41d49f75b..66dc650577919 100644 --- a/drivers/dma/dw-edma/dw-edma-core.c +++ b/drivers/dma/dw-edma/dw-edma-core.c @@ -918,11 +918,11 @@ int dw_edma_probe(struct dw_edma_chip *chip) raw_spin_lock_init(&dw->lock); - dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, + dw->wr_ch_cnt = min_t(u16, chip->ll_wr_cnt, dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); - dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, + dw->rd_ch_cnt = min_t(u16, chip->ll_rd_cnt, dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c index ae42bad24dd5a..7732537f96086 100644 --- a/drivers/dma/dw-edma/dw-edma-pcie.c +++ b/drivers/dma/dw-edma/dw-edma-pcie.c @@ -230,14 +230,14 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, chip->nr_irqs = nr_irqs; chip->ops = &dw_edma_pcie_core_ops; - chip->wr_ch_cnt = vsec_data.wr_ch_cnt; - chip->rd_ch_cnt = vsec_data.rd_ch_cnt; + chip->ll_wr_cnt = vsec_data.wr_ch_cnt; + chip->ll_rd_cnt = vsec_data.rd_ch_cnt; chip->reg_base = pcim_iomap_table(pdev)[vsec_data.rg.bar]; if (!chip->reg_base) return -ENOMEM; - for (i = 0; i < chip->wr_ch_cnt; i++) { + for (i = 0; i < chip->ll_wr_cnt; i++) { struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; @@ -262,7 +262,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, dt_region->sz = dt_block->sz; } - for (i = 0; i < chip->rd_ch_cnt; i++) { + for (i = 0; i < chip->ll_rd_cnt; i++) { struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; @@ -302,7 +302,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, chip->reg_base); - for (i = 0; i < chip->wr_ch_cnt; i++) { + for (i = 0; i < chip->ll_wr_cnt; i++) { pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", i, vsec_data.ll_wr[i].bar, vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, @@ -314,7 +314,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); } - for (i = 0; i < chip->rd_ch_cnt; i++) { + for (i = 0; i < chip->ll_rd_cnt; i++) { pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", i, vsec_data.ll_rd[i].bar, vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h index e9ce652b88233..c2039246fc08c 100644 --- a/include/linux/dma/edma.h +++ b/include/linux/dma/edma.h @@ -40,8 +40,8 @@ enum dw_edma_map_format { * @nr_irqs: total dma irq number * @ops DMA channel to IRQ number mapping * @reg_base DMA register base address - * @wr_ch_cnt DMA write channel number - * @rd_ch_cnt DMA read channel number + * @ll_wr_cnt DMA write link list number + * @ll_rd_cnt DMA read link list number * @rg_region DMA register region * @ll_region_wr DMA descriptor link list memory for write channel * @ll_region_rd DMA descriptor link list memory for read channel @@ -56,8 +56,8 @@ struct dw_edma_chip { void __iomem *reg_base; - u16 wr_ch_cnt; - u16 rd_ch_cnt; + u16 ll_wr_cnt; + u16 ll_rd_cnt; /* link list address */ struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; -- 2.24.0.rc1 ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v4 4/8] dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt in struct dw_edma_chip 2022-03-09 21:12 ` [PATCH v4 4/8] dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt " Frank Li @ 2022-03-10 12:37 ` Serge Semin 2022-03-10 16:26 ` Zhi Li 0 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-10 12:37 UTC (permalink / raw) To: Frank Li Cc: Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam On Wed, Mar 09, 2022 at 03:12:00PM -0600, Frank Li wrote: > There are same name wr(rd)_ch_cnt in struct dw_edma. EDMA driver get > write(read) channel number from register, then save these into dw_edma. > Old wr(rd)_ch_cnt in dw_edma_chip actuall means how many link list memory > are avaiable in ll_region_wr(rd)[EDMA_MAX_WR_CH]. So rename it to > ll_wr(rd)_cnt to indicate actual usage. Hmm, I am not sure you are right here. AFAICS the drivers/dma/dw-edma/dw-edma-pcie.c driver either uses a statically defined number or Rd/Wr channels or just gets the number from the specific vsec PCIe capability. Then based on that the driver just redistributes the BARs memory amongst all the detected channels in accordance with the statically defined snps_edda_data structure. Basically the BARs memory serves as the Local/CPU/Application memory for the case if the controller is embedded into the PCIe Host/EP controller. See the patches which implicitly prove that: 31fb8c1ff962 ("dmaengine: dw-edma: Improve the linked list and data blocks definition") da6e0dd54135 ("dmaengine: dw-edma: Change linked list and data blocks offset and sizes") (That's why the logic of the DEV_TO_MEM/MEM_TO_DEV is inverted for the the drivers/dma/dw-edma/dw-edma-pcie.c platform.) So basically the wr_ch_cnt/rd_ch_cnt fields have been and is used as the number of actually available channels, not linked-list. While the notation suggested by you can be confusing, since the ll-memory allocated for each channel can be split up and initialized with numerous linked lists each of which is used one after another. I don't really see a well justified reason to additionally have the @wr_ch_cnt and @rd_ch_cnt fields in the dw_edma_chip seeing the number of channels can be auto-detected from the corresponding registers, except that to workaround a bogus hardware. So we can keep it, but please no renaming. It will only cause additional confusion. -Sergey > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > new patch at v4 > > drivers/dma/dw-edma/dw-edma-core.c | 4 ++-- > drivers/dma/dw-edma/dw-edma-pcie.c | 12 ++++++------ > include/linux/dma/edma.h | 8 ++++---- > 3 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > index 1abf41d49f75b..66dc650577919 100644 > --- a/drivers/dma/dw-edma/dw-edma-core.c > +++ b/drivers/dma/dw-edma/dw-edma-core.c > @@ -918,11 +918,11 @@ int dw_edma_probe(struct dw_edma_chip *chip) > raw_spin_lock_init(&dw->lock); > > > - dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > + dw->wr_ch_cnt = min_t(u16, chip->ll_wr_cnt, > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > - dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > + dw->rd_ch_cnt = min_t(u16, chip->ll_rd_cnt, > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > index ae42bad24dd5a..7732537f96086 100644 > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > @@ -230,14 +230,14 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > chip->nr_irqs = nr_irqs; > chip->ops = &dw_edma_pcie_core_ops; > > - chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > - chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > + chip->ll_wr_cnt = vsec_data.wr_ch_cnt; > + chip->ll_rd_cnt = vsec_data.rd_ch_cnt; > > chip->reg_base = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > if (!chip->reg_base) > return -ENOMEM; > > - for (i = 0; i < chip->wr_ch_cnt; i++) { > + for (i = 0; i < chip->ll_wr_cnt; i++) { > struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > @@ -262,7 +262,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > dt_region->sz = dt_block->sz; > } > > - for (i = 0; i < chip->rd_ch_cnt; i++) { > + for (i = 0; i < chip->ll_rd_cnt; i++) { > struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > @@ -302,7 +302,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > chip->reg_base); > > > - for (i = 0; i < chip->wr_ch_cnt; i++) { > + for (i = 0; i < chip->ll_wr_cnt; i++) { > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.ll_wr[i].bar, > vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > @@ -314,7 +314,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > } > > - for (i = 0; i < chip->rd_ch_cnt; i++) { > + for (i = 0; i < chip->ll_rd_cnt; i++) { > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > i, vsec_data.ll_rd[i].bar, > vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > index e9ce652b88233..c2039246fc08c 100644 > --- a/include/linux/dma/edma.h > +++ b/include/linux/dma/edma.h > @@ -40,8 +40,8 @@ enum dw_edma_map_format { > * @nr_irqs: total dma irq number > * @ops DMA channel to IRQ number mapping > * @reg_base DMA register base address > - * @wr_ch_cnt DMA write channel number > - * @rd_ch_cnt DMA read channel number > + * @ll_wr_cnt DMA write link list number > + * @ll_rd_cnt DMA read link list number > * @rg_region DMA register region > * @ll_region_wr DMA descriptor link list memory for write channel > * @ll_region_rd DMA descriptor link list memory for read channel > @@ -56,8 +56,8 @@ struct dw_edma_chip { > > void __iomem *reg_base; > > - u16 wr_ch_cnt; > - u16 rd_ch_cnt; > + u16 ll_wr_cnt; > + u16 ll_rd_cnt; > /* link list address */ > struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > -- > 2.24.0.rc1 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 4/8] dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt in struct dw_edma_chip 2022-03-10 12:37 ` Serge Semin @ 2022-03-10 16:26 ` Zhi Li 2022-03-10 16:51 ` Zhi Li 0 siblings, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-10 16:26 UTC (permalink / raw) To: Serge Semin Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Thu, Mar 10, 2022 at 6:37 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > On Wed, Mar 09, 2022 at 03:12:00PM -0600, Frank Li wrote: > > There are same name wr(rd)_ch_cnt in struct dw_edma. EDMA driver get > > write(read) channel number from register, then save these into dw_edma. > > Old wr(rd)_ch_cnt in dw_edma_chip actuall means how many link list memory > > are avaiable in ll_region_wr(rd)[EDMA_MAX_WR_CH]. So rename it to > > ll_wr(rd)_cnt to indicate actual usage. > > Hmm, I am not sure you are right here. AFAICS the > drivers/dma/dw-edma/dw-edma-pcie.c driver either uses a statically > defined number or Rd/Wr channels or just gets the number from the > specific vsec PCIe capability. Then based on that the driver just > redistributes the BARs memory amongst all the detected channels in > accordance with the statically defined snps_edda_data structure. > Basically the BARs memory serves as the Local/CPU/Application memory > for the case if the controller is embedded into the PCIe Host/EP > controller. See the patches which implicitly prove that: > 31fb8c1ff962 ("dmaengine: dw-edma: Improve the linked list and data blocks definition") > da6e0dd54135 ("dmaengine: dw-edma: Change linked list and data blocks offset and sizes") > > (That's why the logic of the DEV_TO_MEM/MEM_TO_DEV is inverted for the > the drivers/dma/dw-edma/dw-edma-pcie.c platform.) > > So basically the wr_ch_cnt/rd_ch_cnt fields have been and is used as > the number of actually available channels, not linked-list. While the > notation suggested by you can be confusing, since the ll-memory allocated for > each channel can be split up and initialized with numerous linked lists > each of which is used one after another. > > I don't really see a well justified reason to additionally have the > @wr_ch_cnt and @rd_ch_cnt fields in the dw_edma_chip seeing the number > of channels can be auto-detected from the corresponding registers, except > that to workaround a bogus hardware. So we can keep it, but please no > renaming. It will only cause additional confusion. I agree that channel numbers can be obtained from the register. but Caller don't know the channel number before calling dw_edma_probe. Caller may not init all ll_region_wr[EDMA_MAX_WR_CH], That's the reason I need a field to indicate how many ll_region_w actually initialized. old wr_ch_cnt just plays the same role. > > -Sergey > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > --- > > new patch at v4 > > > > drivers/dma/dw-edma/dw-edma-core.c | 4 ++-- > > drivers/dma/dw-edma/dw-edma-pcie.c | 12 ++++++------ > > include/linux/dma/edma.h | 8 ++++---- > > 3 files changed, 12 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > index 1abf41d49f75b..66dc650577919 100644 > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > @@ -918,11 +918,11 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > raw_spin_lock_init(&dw->lock); > > > > > > - dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > > + dw->wr_ch_cnt = min_t(u16, chip->ll_wr_cnt, > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > > > - dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > > + dw->rd_ch_cnt = min_t(u16, chip->ll_rd_cnt, > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > > index ae42bad24dd5a..7732537f96086 100644 > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > > @@ -230,14 +230,14 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > chip->nr_irqs = nr_irqs; > > chip->ops = &dw_edma_pcie_core_ops; > > > > - chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > > - chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > + chip->ll_wr_cnt = vsec_data.wr_ch_cnt; > > + chip->ll_rd_cnt = vsec_data.rd_ch_cnt; > > > > chip->reg_base = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > if (!chip->reg_base) > > return -ENOMEM; > > > > - for (i = 0; i < chip->wr_ch_cnt; i++) { > > + for (i = 0; i < chip->ll_wr_cnt; i++) { > > struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > > struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > > @@ -262,7 +262,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > dt_region->sz = dt_block->sz; > > } > > > > - for (i = 0; i < chip->rd_ch_cnt; i++) { > > + for (i = 0; i < chip->ll_rd_cnt; i++) { > > struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > > struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > > @@ -302,7 +302,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > chip->reg_base); > > > > > > - for (i = 0; i < chip->wr_ch_cnt; i++) { > > + for (i = 0; i < chip->ll_wr_cnt; i++) { > > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > i, vsec_data.ll_wr[i].bar, > > vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > > @@ -314,7 +314,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > > } > > > > - for (i = 0; i < chip->rd_ch_cnt; i++) { > > + for (i = 0; i < chip->ll_rd_cnt; i++) { > > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > i, vsec_data.ll_rd[i].bar, > > vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > > index e9ce652b88233..c2039246fc08c 100644 > > --- a/include/linux/dma/edma.h > > +++ b/include/linux/dma/edma.h > > @@ -40,8 +40,8 @@ enum dw_edma_map_format { > > * @nr_irqs: total dma irq number > > * @ops DMA channel to IRQ number mapping > > * @reg_base DMA register base address > > - * @wr_ch_cnt DMA write channel number > > - * @rd_ch_cnt DMA read channel number > > + * @ll_wr_cnt DMA write link list number > > + * @ll_rd_cnt DMA read link list number > > * @rg_region DMA register region > > * @ll_region_wr DMA descriptor link list memory for write channel > > * @ll_region_rd DMA descriptor link list memory for read channel > > @@ -56,8 +56,8 @@ struct dw_edma_chip { > > > > void __iomem *reg_base; > > > > - u16 wr_ch_cnt; > > - u16 rd_ch_cnt; > > + u16 ll_wr_cnt; > > + u16 ll_rd_cnt; > > /* link list address */ > > struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > -- > > 2.24.0.rc1 > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 4/8] dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt in struct dw_edma_chip 2022-03-10 16:26 ` Zhi Li @ 2022-03-10 16:51 ` Zhi Li 2022-03-10 18:45 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-10 16:51 UTC (permalink / raw) To: Serge Semin Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Thu, Mar 10, 2022 at 10:26 AM Zhi Li <lznuaa@gmail.com> wrote: > > On Thu, Mar 10, 2022 at 6:37 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > On Wed, Mar 09, 2022 at 03:12:00PM -0600, Frank Li wrote: > > > There are same name wr(rd)_ch_cnt in struct dw_edma. EDMA driver get > > > write(read) channel number from register, then save these into dw_edma. > > > Old wr(rd)_ch_cnt in dw_edma_chip actuall means how many link list memory > > > are avaiable in ll_region_wr(rd)[EDMA_MAX_WR_CH]. So rename it to > > > ll_wr(rd)_cnt to indicate actual usage. > > > > Hmm, I am not sure you are right here. AFAICS the > > drivers/dma/dw-edma/dw-edma-pcie.c driver either uses a statically > > defined number or Rd/Wr channels or just gets the number from the > > specific vsec PCIe capability. Then based on that the driver just > > redistributes the BARs memory amongst all the detected channels in > > accordance with the statically defined snps_edda_data structure. > > Basically the BARs memory serves as the Local/CPU/Application memory > > for the case if the controller is embedded into the PCIe Host/EP > > controller. See the patches which implicitly prove that: > > 31fb8c1ff962 ("dmaengine: dw-edma: Improve the linked list and data blocks definition") > > da6e0dd54135 ("dmaengine: dw-edma: Change linked list and data blocks offset and sizes") > > > > (That's why the logic of the DEV_TO_MEM/MEM_TO_DEV is inverted for the > > the drivers/dma/dw-edma/dw-edma-pcie.c platform.) > > > > So basically the wr_ch_cnt/rd_ch_cnt fields have been and is used as > > the number of actually available channels, not linked-list. While the > > notation suggested by you can be confusing, since the ll-memory allocated for > > each channel can be split up and initialized with numerous linked lists > > each of which is used one after another. > > > > I don't really see a well justified reason to additionally have the > > @wr_ch_cnt and @rd_ch_cnt fields in the dw_edma_chip seeing the number > > of channels can be auto-detected from the corresponding registers, except > > that to workaround a bogus hardware. So we can keep it, but please no > > renaming. It will only cause additional confusion. > > I agree that channel numbers can be obtained from the register. > but Caller don't know the channel number before calling dw_edma_probe. > > Caller may not init all ll_region_wr[EDMA_MAX_WR_CH], > > That's the reason I need a field to indicate how many ll_region_w > actually initialized. > > old wr_ch_cnt just plays the same role. Anyway, it is not a big deal. I can skip this patch. > > > > > -Sergey > > > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > --- > > > new patch at v4 > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 4 ++-- > > > drivers/dma/dw-edma/dw-edma-pcie.c | 12 ++++++------ > > > include/linux/dma/edma.h | 8 ++++---- > > > 3 files changed, 12 insertions(+), 12 deletions(-) > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > index 1abf41d49f75b..66dc650577919 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > @@ -918,11 +918,11 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > raw_spin_lock_init(&dw->lock); > > > > > > > > > - dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > > > + dw->wr_ch_cnt = min_t(u16, chip->ll_wr_cnt, > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > > > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > > > > > - dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > > > + dw->rd_ch_cnt = min_t(u16, chip->ll_rd_cnt, > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > > > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > > > index ae42bad24dd5a..7732537f96086 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > > > @@ -230,14 +230,14 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > chip->nr_irqs = nr_irqs; > > > chip->ops = &dw_edma_pcie_core_ops; > > > > > > - chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > > > - chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > > + chip->ll_wr_cnt = vsec_data.wr_ch_cnt; > > > + chip->ll_rd_cnt = vsec_data.rd_ch_cnt; > > > > > > chip->reg_base = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > > if (!chip->reg_base) > > > return -ENOMEM; > > > > > > - for (i = 0; i < chip->wr_ch_cnt; i++) { > > > + for (i = 0; i < chip->ll_wr_cnt; i++) { > > > struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > > > struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > > > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > > > @@ -262,7 +262,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > dt_region->sz = dt_block->sz; > > > } > > > > > > - for (i = 0; i < chip->rd_ch_cnt; i++) { > > > + for (i = 0; i < chip->ll_rd_cnt; i++) { > > > struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > > > struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > > > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > > > @@ -302,7 +302,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > chip->reg_base); > > > > > > > > > - for (i = 0; i < chip->wr_ch_cnt; i++) { > > > + for (i = 0; i < chip->ll_wr_cnt; i++) { > > > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > i, vsec_data.ll_wr[i].bar, > > > vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > > > @@ -314,7 +314,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > > > } > > > > > > - for (i = 0; i < chip->rd_ch_cnt; i++) { > > > + for (i = 0; i < chip->ll_rd_cnt; i++) { > > > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > i, vsec_data.ll_rd[i].bar, > > > vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > > > index e9ce652b88233..c2039246fc08c 100644 > > > --- a/include/linux/dma/edma.h > > > +++ b/include/linux/dma/edma.h > > > @@ -40,8 +40,8 @@ enum dw_edma_map_format { > > > * @nr_irqs: total dma irq number > > > * @ops DMA channel to IRQ number mapping > > > * @reg_base DMA register base address > > > - * @wr_ch_cnt DMA write channel number > > > - * @rd_ch_cnt DMA read channel number > > > + * @ll_wr_cnt DMA write link list number > > > + * @ll_rd_cnt DMA read link list number > > > * @rg_region DMA register region > > > * @ll_region_wr DMA descriptor link list memory for write channel > > > * @ll_region_rd DMA descriptor link list memory for read channel > > > @@ -56,8 +56,8 @@ struct dw_edma_chip { > > > > > > void __iomem *reg_base; > > > > > > - u16 wr_ch_cnt; > > > - u16 rd_ch_cnt; > > > + u16 ll_wr_cnt; > > > + u16 ll_rd_cnt; > > > /* link list address */ > > > struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > > struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > > -- > > > 2.24.0.rc1 > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 4/8] dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt in struct dw_edma_chip 2022-03-10 16:51 ` Zhi Li @ 2022-03-10 18:45 ` Serge Semin 0 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-10 18:45 UTC (permalink / raw) To: Zhi Li Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Thu, Mar 10, 2022 at 10:51:51AM -0600, Zhi Li wrote: > On Thu, Mar 10, 2022 at 10:26 AM Zhi Li <lznuaa@gmail.com> wrote: > > > > On Thu, Mar 10, 2022 at 6:37 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > On Wed, Mar 09, 2022 at 03:12:00PM -0600, Frank Li wrote: > > > > There are same name wr(rd)_ch_cnt in struct dw_edma. EDMA driver get > > > > write(read) channel number from register, then save these into dw_edma. > > > > Old wr(rd)_ch_cnt in dw_edma_chip actuall means how many link list memory > > > > are avaiable in ll_region_wr(rd)[EDMA_MAX_WR_CH]. So rename it to > > > > ll_wr(rd)_cnt to indicate actual usage. > > > > > > Hmm, I am not sure you are right here. AFAICS the > > > drivers/dma/dw-edma/dw-edma-pcie.c driver either uses a statically > > > defined number or Rd/Wr channels or just gets the number from the > > > specific vsec PCIe capability. Then based on that the driver just > > > redistributes the BARs memory amongst all the detected channels in > > > accordance with the statically defined snps_edda_data structure. > > > Basically the BARs memory serves as the Local/CPU/Application memory > > > for the case if the controller is embedded into the PCIe Host/EP > > > controller. See the patches which implicitly prove that: > > > 31fb8c1ff962 ("dmaengine: dw-edma: Improve the linked list and data blocks definition") > > > da6e0dd54135 ("dmaengine: dw-edma: Change linked list and data blocks offset and sizes") > > > > > > (That's why the logic of the DEV_TO_MEM/MEM_TO_DEV is inverted for the > > > the drivers/dma/dw-edma/dw-edma-pcie.c platform.) > > > > > > So basically the wr_ch_cnt/rd_ch_cnt fields have been and is used as > > > the number of actually available channels, not linked-list. While the > > > notation suggested by you can be confusing, since the ll-memory allocated for > > > each channel can be split up and initialized with numerous linked lists > > > each of which is used one after another. > > > > > > I don't really see a well justified reason to additionally have the > > > @wr_ch_cnt and @rd_ch_cnt fields in the dw_edma_chip seeing the number > > > of channels can be auto-detected from the corresponding registers, except > > > that to workaround a bogus hardware. So we can keep it, but please no > > > renaming. It will only cause additional confusion. > > > > I agree that channel numbers can be obtained from the register. > > but Caller don't know the channel number before calling dw_edma_probe. > > > > Caller may not init all ll_region_wr[EDMA_MAX_WR_CH], > > > > That's the reason I need a field to indicate how many ll_region_w > > actually initialized. > > > > old wr_ch_cnt just plays the same role. > > Anyway, it is not a big deal. I can skip this patch. Ah, finally I see what you mean here. The patch seems reasonable now. No objection against it then. Reviewed-by: Serge Semin <fancer.lancer@gmail.com> -Sergey > > > > > > > > > -Sergey > > > > > > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > --- > > > > new patch at v4 > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 4 ++-- > > > > drivers/dma/dw-edma/dw-edma-pcie.c | 12 ++++++------ > > > > include/linux/dma/edma.h | 8 ++++---- > > > > 3 files changed, 12 insertions(+), 12 deletions(-) > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > index 1abf41d49f75b..66dc650577919 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > @@ -918,11 +918,11 @@ int dw_edma_probe(struct dw_edma_chip *chip) > > > > raw_spin_lock_init(&dw->lock); > > > > > > > > > > > > - dw->wr_ch_cnt = min_t(u16, chip->wr_ch_cnt, > > > > + dw->wr_ch_cnt = min_t(u16, chip->ll_wr_cnt, > > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_WRITE)); > > > > dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH); > > > > > > > > - dw->rd_ch_cnt = min_t(u16, chip->rd_ch_cnt, > > > > + dw->rd_ch_cnt = min_t(u16, chip->ll_rd_cnt, > > > > dw_edma_v0_core_ch_count(dw, EDMA_DIR_READ)); > > > > dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH); > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c > > > > index ae42bad24dd5a..7732537f96086 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > > > > @@ -230,14 +230,14 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > chip->nr_irqs = nr_irqs; > > > > chip->ops = &dw_edma_pcie_core_ops; > > > > > > > > - chip->wr_ch_cnt = vsec_data.wr_ch_cnt; > > > > - chip->rd_ch_cnt = vsec_data.rd_ch_cnt; > > > > + chip->ll_wr_cnt = vsec_data.wr_ch_cnt; > > > > + chip->ll_rd_cnt = vsec_data.rd_ch_cnt; > > > > > > > > chip->reg_base = pcim_iomap_table(pdev)[vsec_data.rg.bar]; > > > > if (!chip->reg_base) > > > > return -ENOMEM; > > > > > > > > - for (i = 0; i < chip->wr_ch_cnt; i++) { > > > > + for (i = 0; i < chip->ll_wr_cnt; i++) { > > > > struct dw_edma_region *ll_region = &chip->ll_region_wr[i]; > > > > struct dw_edma_region *dt_region = &chip->dt_region_wr[i]; > > > > struct dw_edma_block *ll_block = &vsec_data.ll_wr[i]; > > > > @@ -262,7 +262,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > dt_region->sz = dt_block->sz; > > > > } > > > > > > > > - for (i = 0; i < chip->rd_ch_cnt; i++) { > > > > + for (i = 0; i < chip->ll_rd_cnt; i++) { > > > > struct dw_edma_region *ll_region = &chip->ll_region_rd[i]; > > > > struct dw_edma_region *dt_region = &chip->dt_region_rd[i]; > > > > struct dw_edma_block *ll_block = &vsec_data.ll_rd[i]; > > > > @@ -302,7 +302,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > chip->reg_base); > > > > > > > > > > > > - for (i = 0; i < chip->wr_ch_cnt; i++) { > > > > + for (i = 0; i < chip->ll_wr_cnt; i++) { > > > > pci_dbg(pdev, "L. List:\tWRITE CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > i, vsec_data.ll_wr[i].bar, > > > > vsec_data.ll_wr[i].off, chip->ll_region_wr[i].sz, > > > > @@ -314,7 +314,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, > > > > chip->dt_region_wr[i].vaddr, &chip->dt_region_wr[i].paddr); > > > > } > > > > > > > > - for (i = 0; i < chip->rd_ch_cnt; i++) { > > > > + for (i = 0; i < chip->ll_rd_cnt; i++) { > > > > pci_dbg(pdev, "L. List:\tREAD CH%.2u, BAR=%u, off=0x%.8lx, sz=0x%zx bytes, addr(v=%p, p=%pa)\n", > > > > i, vsec_data.ll_rd[i].bar, > > > > vsec_data.ll_rd[i].off, chip->ll_region_rd[i].sz, > > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > > > > index e9ce652b88233..c2039246fc08c 100644 > > > > --- a/include/linux/dma/edma.h > > > > +++ b/include/linux/dma/edma.h > > > > @@ -40,8 +40,8 @@ enum dw_edma_map_format { > > > > * @nr_irqs: total dma irq number > > > > * @ops DMA channel to IRQ number mapping > > > > * @reg_base DMA register base address > > > > - * @wr_ch_cnt DMA write channel number > > > > - * @rd_ch_cnt DMA read channel number > > > > + * @ll_wr_cnt DMA write link list number > > > > + * @ll_rd_cnt DMA read link list number > > > > * @rg_region DMA register region > > > > * @ll_region_wr DMA descriptor link list memory for write channel > > > > * @ll_region_rd DMA descriptor link list memory for read channel > > > > @@ -56,8 +56,8 @@ struct dw_edma_chip { > > > > > > > > void __iomem *reg_base; > > > > > > > > - u16 wr_ch_cnt; > > > > - u16 rd_ch_cnt; > > > > + u16 ll_wr_cnt; > > > > + u16 ll_rd_cnt; > > > > /* link list address */ > > > > struct dw_edma_region ll_region_wr[EDMA_MAX_WR_CH]; > > > > struct dw_edma_region ll_region_rd[EDMA_MAX_RD_CH]; > > > > -- > > > > 2.24.0.rc1 > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-09 21:11 [PATCH v4 0/8] Enable designware PCI EP EDMA locally Frank Li ` (3 preceding siblings ...) 2022-03-09 21:12 ` [PATCH v4 4/8] dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt " Frank Li @ 2022-03-09 21:12 ` Frank Li 2022-03-10 16:31 ` Serge Semin 2022-03-09 21:12 ` [PATCH v4 6/8] dmaengine: dw-edma: Don't rely on the deprecated "direction" member Frank Li ` (2 subsequent siblings) 7 siblings, 1 reply; 52+ messages in thread From: Frank Li @ 2022-03-09 21:12 UTC (permalink / raw) To: gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> When eDMA is controlled by the Endpoint (EP), the current logic incorrectly programs the source and destination addresses for read and write. Since the Root complex and Endpoint uses the opposite channels for read/write, fix the issue by finding out the read operation first and program the eDMA accordingly. Cc: stable@vger.kernel.org Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> --- No change between v1 to v4 drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c index 66dc650577919..507f08db1aad3 100644 --- a/drivers/dma/dw-edma/dw-edma-core.c +++ b/drivers/dma/dw-edma/dw-edma-core.c @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) struct dw_edma_chunk *chunk; struct dw_edma_burst *burst; struct dw_edma_desc *desc; + bool read = false; u32 cnt = 0; int i; @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) chunk->ll_region.sz += burst->sz; desc->alloc_sz += burst->sz; - if (chan->dir == EDMA_DIR_WRITE) { + /**************************************************************** + * + * Root Complex Endpoint + * +-----------------------+ +----------------------+ + * | | TX CH | | + * | | | | + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | + * | | | | + * | | | | + * | MEM_TO_DEV +-------------> DEV_TO_MEM | + * | | | | + * | | RX CH | | + * +-----------------------+ +----------------------+ + * + * If eDMA is controlled by the Root complex, TX channel + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). + * + * If eDMA is controlled by the endpoint, RX channel + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). + * + ****************************************************************/ + + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) + read = true; + + /* Program the source and destination addresses for DMA read/write */ + if (read) { burst->sar = src_addr; if (xfer->type == EDMA_XFER_CYCLIC) { burst->dar = xfer->xfer.cyclic.paddr; -- 2.24.0.rc1 ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-09 21:12 ` [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep Frank Li @ 2022-03-10 16:31 ` Serge Semin 2022-03-10 16:50 ` Zhi Li 2022-03-11 17:41 ` Manivannan Sadhasivam 0 siblings, 2 replies; 52+ messages in thread From: Serge Semin @ 2022-03-10 16:31 UTC (permalink / raw) To: Frank Li Cc: Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > programs the source and destination addresses for read and write. Since the > Root complex and Endpoint uses the opposite channels for read/write, fix the > issue by finding out the read operation first and program the eDMA accordingly. > > Cc: stable@vger.kernel.org > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > No change between v1 to v4 > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > 1 file changed, 31 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > index 66dc650577919..507f08db1aad3 100644 > --- a/drivers/dma/dw-edma/dw-edma-core.c > +++ b/drivers/dma/dw-edma/dw-edma-core.c > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > struct dw_edma_chunk *chunk; > struct dw_edma_burst *burst; > struct dw_edma_desc *desc; > + bool read = false; > u32 cnt = 0; > int i; > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > chunk->ll_region.sz += burst->sz; > desc->alloc_sz += burst->sz; > > - if (chan->dir == EDMA_DIR_WRITE) { > + /**************************************************************** > + * > + * Root Complex Endpoint > + * +-----------------------+ +----------------------+ > + * | | TX CH | | > + * | | | | > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > + * | | | | > + * | | | | > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > + * | | | | > + * | | RX CH | | > + * +-----------------------+ +----------------------+ > + * > + * If eDMA is controlled by the Root complex, TX channel > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > + * > + * If eDMA is controlled by the endpoint, RX channel > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). Either I have some wrong notion about this issue, or something wrong with the explanation above and with this fix below. From my understanding of the possible DW eDMA IP-core setups the scatch above and the text below it are incorrect. Here is the way the DW eDMA can be used: 1) Embedded into the DW PCIe Host/EP controller. In this case CPU/Application Memory is the memory of the CPU attached to the host/EP controller, while the remote (link partner) memory is the PCIe bus memory. In this case MEM_TO_DEV operation is supposed to be performed by the Tx/Write channels, while the DEV_TO_MEM operation - by the Rx/Read channels. Note it's applicable for both Host and End-point case, when Linux is running on the CPU-side of the eDMA controller. So if it's DW PCIe end-point, then MEM_TO_DEV means copying data from the local CPU memory into the remote memory. In general the remote memory can be either some PCIe device on the bus or the Root Complex' CPU memory, each of which is some remote device anyway from the Local CPU perspective. 2) Embedded into the PCIe EP. This case is implemented in the drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log and from the driver code, that device is a Synopsys PCIe EndPoint IP prototype kit. It is a normal PCIe peripheral device with eDMA embedded, which CPU/Application interface is connected to some embedded SRAM while remote (link partner) interface is directed towards the PCIe bus. At the same time the device is setup and handled by the code running on a CPU connected to the PCIe Host controller. I think that in order to preserve the normal DMA operations semantics we still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the host CPU perspective, since that's the side the DMA controller is supposed to be setup from. In this MEM_TO_DEV is supposed to be used to copy data from the host CPU memory into the remote device memory. It means to allocate Rx/Read channel on the eDMA controller, so one would be read data from the Local CPU memory and copied it to the PCIe device SRAM. The logic of the DEV_TO_MEM direction would be just flipped. The eDMA PCIe device shall use Tx/Write channel to copy data from it's SRAM into the Host CPU memory. Please note as I understand the case 2) describes the Synopsys PCIe EndPoint IP prototype kit, which is based on some FPGA code. It's just a test setup with no real application, while the case 1) is a real setup available on our SoC and I guess on yours. So what I suggest in the framework of this patch is just to implement the case 1) only. While the case 2) as it's an artificial one can be manually handled by the DMA client drivers. BTW There aren't ones available in the kernel anyway. The only exception is an old-time attempt to get an eDMA IP test-driver mainlined into the kernel: https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ But it was long time ago. So it's unlikely to be accepted at all. What do you think? -Sergey > + * > + ****************************************************************/ > + > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > + read = true; Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems redundant. > + > + /* Program the source and destination addresses for DMA read/write */ > + if (read) { > burst->sar = src_addr; > if (xfer->type == EDMA_XFER_CYCLIC) { > burst->dar = xfer->xfer.cyclic.paddr; > -- > 2.24.0.rc1 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-10 16:31 ` Serge Semin @ 2022-03-10 16:50 ` Zhi Li 2022-03-10 19:37 ` Serge Semin 2022-03-11 17:41 ` Manivannan Sadhasivam 1 sibling, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-10 16:50 UTC (permalink / raw) To: Serge Semin Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > programs the source and destination addresses for read and write. Since the > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > issue by finding out the read operation first and program the eDMA accordingly. > > > > Cc: stable@vger.kernel.org > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > --- > > No change between v1 to v4 > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > index 66dc650577919..507f08db1aad3 100644 > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > struct dw_edma_chunk *chunk; > > struct dw_edma_burst *burst; > > struct dw_edma_desc *desc; > > + bool read = false; > > u32 cnt = 0; > > int i; > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > chunk->ll_region.sz += burst->sz; > > desc->alloc_sz += burst->sz; > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > + /**************************************************************** > > + * > > > + * Root Complex Endpoint > > + * +-----------------------+ +----------------------+ > > + * | | TX CH | | > > + * | | | | > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > + * | | | | > > + * | | | | > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > + * | | | | > > + * | | RX CH | | > > + * +-----------------------+ +----------------------+ > > + * > > + * If eDMA is controlled by the Root complex, TX channel > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > + * > > + * If eDMA is controlled by the endpoint, RX channel > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > Either I have some wrong notion about this issue, or something wrong > with the explanation above and with this fix below. > > From my understanding of the possible DW eDMA IP-core setups the > scatch above and the text below it are incorrect. Here is the way the > DW eDMA can be used: > 1) Embedded into the DW PCIe Host/EP controller. In this case > CPU/Application Memory is the memory of the CPU attached to the > host/EP controller, while the remote (link partner) memory is the PCIe > bus memory. In this case MEM_TO_DEV operation is supposed to be > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > by the Rx/Read channels. > > Note it's applicable for both Host and End-point case, when Linux is > running on the CPU-side of the eDMA controller. So if it's DW PCIe > end-point, then MEM_TO_DEV means copying data from the local CPU > memory into the remote memory. In general the remote memory can be > either some PCIe device on the bus or the Root Complex' CPU memory, > each of which is some remote device anyway from the Local CPU > perspective. > > 2) Embedded into the PCIe EP. This case is implemented in the > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > and from the driver code, that device is a Synopsys PCIe EndPoint IP > prototype kit. It is a normal PCIe peripheral device with eDMA > embedded, which CPU/Application interface is connected to some > embedded SRAM while remote (link partner) interface is directed > towards the PCIe bus. At the same time the device is setup and handled > by the code running on a CPU connected to the PCIe Host controller. I > think that in order to preserve the normal DMA operations semantics we > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > host CPU perspective, since that's the side the DMA controller is > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > to copy data from the host CPU memory into the remote device memory. > It means to allocate Rx/Read channel on the eDMA controller, so one > would be read data from the Local CPU memory and copied it to the PCIe > device SRAM. The logic of the DEV_TO_MEM direction would be just > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > from it's SRAM into the Host CPU memory. > > Please note as I understand the case 2) describes the Synopsys PCIe > EndPoint IP prototype kit, which is based on some FPGA code. It's just > a test setup with no real application, while the case 1) is a real setup > available on our SoC and I guess on yours. I think yes. But Remote EP also is a one kind of usage module. Just no one writes an EP functional driver for it yet. Even pci-epf-test was just a test function. I previously sent vNTB patches to implement a virtual network between RC and EP, you can look if you have interest. > > So what I suggest in the framework of this patch is just to implement > the case 1) only. While the case 2) as it's an artificial one can be > manually handled by the DMA client drivers. BTW There aren't ones available > in the kernel anyway. The only exception is an old-time attempt to get > an eDMA IP test-driver mainlined into the kernel: > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > But it was long time ago. So it's unlikely to be accepted at all. > > What do you think? > > -Sergey > > > + * > > + ****************************************************************/ > > + > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > + read = true; > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > redundant. > > > + > > + /* Program the source and destination addresses for DMA read/write */ > > + if (read) { > > burst->sar = src_addr; > > if (xfer->type == EDMA_XFER_CYCLIC) { > > burst->dar = xfer->xfer.cyclic.paddr; > > -- > > 2.24.0.rc1 > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-10 16:50 ` Zhi Li @ 2022-03-10 19:37 ` Serge Semin 2022-03-10 20:16 ` Zhi Li 2022-03-11 17:46 ` Manivannan Sadhasivam 0 siblings, 2 replies; 52+ messages in thread From: Serge Semin @ 2022-03-10 19:37 UTC (permalink / raw) To: Zhi Li Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Thu, Mar 10, 2022 at 10:50:14AM -0600, Zhi Li wrote: > On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > programs the source and destination addresses for read and write. Since the > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > Cc: stable@vger.kernel.org > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > --- > > > No change between v1 to v4 > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > index 66dc650577919..507f08db1aad3 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > struct dw_edma_chunk *chunk; > > > struct dw_edma_burst *burst; > > > struct dw_edma_desc *desc; > > > + bool read = false; > > > u32 cnt = 0; > > > int i; > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > chunk->ll_region.sz += burst->sz; > > > desc->alloc_sz += burst->sz; > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > + /**************************************************************** > > > + * > > > > > + * Root Complex Endpoint > > > + * +-----------------------+ +----------------------+ > > > + * | | TX CH | | > > > + * | | | | > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > + * | | | | > > > + * | | | | > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > + * | | | | > > > + * | | RX CH | | > > > + * +-----------------------+ +----------------------+ > > > + * > > > + * If eDMA is controlled by the Root complex, TX channel > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > + * > > > + * If eDMA is controlled by the endpoint, RX channel > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > Either I have some wrong notion about this issue, or something wrong > > with the explanation above and with this fix below. > > > > From my understanding of the possible DW eDMA IP-core setups the > > scatch above and the text below it are incorrect. Here is the way the > > DW eDMA can be used: > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > CPU/Application Memory is the memory of the CPU attached to the > > host/EP controller, while the remote (link partner) memory is the PCIe > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > by the Rx/Read channels. > > > > Note it's applicable for both Host and End-point case, when Linux is > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > end-point, then MEM_TO_DEV means copying data from the local CPU > > memory into the remote memory. In general the remote memory can be > > either some PCIe device on the bus or the Root Complex' CPU memory, > > each of which is some remote device anyway from the Local CPU > > perspective. > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > prototype kit. It is a normal PCIe peripheral device with eDMA > > embedded, which CPU/Application interface is connected to some > > embedded SRAM while remote (link partner) interface is directed > > towards the PCIe bus. At the same time the device is setup and handled > > by the code running on a CPU connected to the PCIe Host controller. I > > think that in order to preserve the normal DMA operations semantics we > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > host CPU perspective, since that's the side the DMA controller is > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > to copy data from the host CPU memory into the remote device memory. > > It means to allocate Rx/Read channel on the eDMA controller, so one > > would be read data from the Local CPU memory and copied it to the PCIe > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > from it's SRAM into the Host CPU memory. > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > a test setup with no real application, while the case 1) is a real setup > > available on our SoC and I guess on yours. > > I think yes. But Remote EP also is a one kind of usage module. Just no one > writes an EP functional driver for it yet. Even pci-epf-test was just > a test function. > I previously sent vNTB patches to implement a virtual network between > RC and EP, > you can look if you have interest. AFAIU the remote EP case is the same as 1) anyway. The remote EP is handled by its own CPU, which sets up the DW PCIe EP controller together with eDMA synthesized into the CPU' SoC. Am I right? While the case 2) doesn't have any CPU attached on the PCIe EP. It's just an FPGA with PCIe interface and eDMA IP-core installed. In that case all the setups are performed by the PCIe Host CPU. That's the root problem that causes having all the DEV_TO_MEM/MEM_TO_DEV complications. So to speak I would suggest for at least to have the scatch fixed in accordance with the logic explained in my message. > > > > > So what I suggest in the framework of this patch is just to implement > > the case 1) only. While the case 2) as it's an artificial one can be > > manually handled by the DMA client drivers. BTW There aren't ones available > > in the kernel anyway. The only exception is an old-time attempt to get > > an eDMA IP test-driver mainlined into the kernel: > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > But it was long time ago. So it's unlikely to be accepted at all. > > > > What do you think? > > > > -Sergey > > > > > + * > > > + ****************************************************************/ > > > + > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > + read = true; > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > redundant. Am I getting a response on this comment? In accordance with that conditional statement having dir == DMA_DEV_TO_MEM means performing read operation. If dir equals DMA_MEM_TO_DEV then a write operation will be performed. The code path doesn't depend on the chan->dir value. -Sergey > > > > > + > > > + /* Program the source and destination addresses for DMA read/write */ > > > + if (read) { > > > burst->sar = src_addr; > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > burst->dar = xfer->xfer.cyclic.paddr; > > > -- > > > 2.24.0.rc1 > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-10 19:37 ` Serge Semin @ 2022-03-10 20:16 ` Zhi Li 2022-03-11 12:38 ` Serge Semin 2022-03-11 17:46 ` Manivannan Sadhasivam 1 sibling, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-10 20:16 UTC (permalink / raw) To: Serge Semin Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Thu, Mar 10, 2022 at 1:38 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > On Thu, Mar 10, 2022 at 10:50:14AM -0600, Zhi Li wrote: > > On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > > programs the source and destination addresses for read and write. Since the > > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > > > Cc: stable@vger.kernel.org > > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > --- > > > > No change between v1 to v4 > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > index 66dc650577919..507f08db1aad3 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > struct dw_edma_chunk *chunk; > > > > struct dw_edma_burst *burst; > > > > struct dw_edma_desc *desc; > > > > + bool read = false; > > > > u32 cnt = 0; > > > > int i; > > > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > chunk->ll_region.sz += burst->sz; > > > > desc->alloc_sz += burst->sz; > > > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > > + /**************************************************************** > > > > + * > > > > > > > + * Root Complex Endpoint > > > > + * +-----------------------+ +----------------------+ > > > > + * | | TX CH | | > > > > + * | | | | > > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > > + * | | | | > > > > + * | | | | > > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > > + * | | | | > > > > + * | | RX CH | | > > > > + * +-----------------------+ +----------------------+ > > > > + * > > > > + * If eDMA is controlled by the Root complex, TX channel > > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > > + * > > > > + * If eDMA is controlled by the endpoint, RX channel > > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > > > Either I have some wrong notion about this issue, or something wrong > > > with the explanation above and with this fix below. > > > > > > From my understanding of the possible DW eDMA IP-core setups the > > > scatch above and the text below it are incorrect. Here is the way the > > > DW eDMA can be used: > > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > > CPU/Application Memory is the memory of the CPU attached to the > > > host/EP controller, while the remote (link partner) memory is the PCIe > > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > > by the Rx/Read channels. > > > > > > Note it's applicable for both Host and End-point case, when Linux is > > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > > end-point, then MEM_TO_DEV means copying data from the local CPU > > > memory into the remote memory. In general the remote memory can be > > > either some PCIe device on the bus or the Root Complex' CPU memory, > > > each of which is some remote device anyway from the Local CPU > > > perspective. > > > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > > prototype kit. It is a normal PCIe peripheral device with eDMA > > > embedded, which CPU/Application interface is connected to some > > > embedded SRAM while remote (link partner) interface is directed > > > towards the PCIe bus. At the same time the device is setup and handled > > > by the code running on a CPU connected to the PCIe Host controller. I > > > think that in order to preserve the normal DMA operations semantics we > > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > > host CPU perspective, since that's the side the DMA controller is > > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > > to copy data from the host CPU memory into the remote device memory. > > > It means to allocate Rx/Read channel on the eDMA controller, so one > > > would be read data from the Local CPU memory and copied it to the PCIe > > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > > from it's SRAM into the Host CPU memory. > > > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > > a test setup with no real application, while the case 1) is a real setup > > > available on our SoC and I guess on yours. > > > > > I think yes. But Remote EP also is a one kind of usage module. Just no one > > writes an EP functional driver for it yet. Even pci-epf-test was just > > a test function. > > I previously sent vNTB patches to implement a virtual network between > > RC and EP, > > you can look if you have interest. > > AFAIU the remote EP case is the same as 1) anyway. The remote EP is > handled by its own CPU, which sets up the DW PCIe EP controller > together with eDMA synthesized into the CPU' SoC. Am I right? While > the case 2) doesn't have any CPU attached on the PCIe EP. It's just an > FPGA with PCIe interface and eDMA IP-core installed. In that case all > the setups are performed by the PCIe Host CPU. That's the root problem > that causes having all the DEV_TO_MEM/MEM_TO_DEV complications. > > So to speak I would suggest for at least to have the scatch fixed in > accordance with the logic explained in my message. > > > > > > > > > So what I suggest in the framework of this patch is just to implement > > > the case 1) only. While the case 2) as it's an artificial one can be > > > manually handled by the DMA client drivers. BTW There aren't ones available > > > in the kernel anyway. The only exception is an old-time attempt to get > > > an eDMA IP test-driver mainlined into the kernel: > > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > > But it was long time ago. So it's unlikely to be accepted at all. > > > > > > What do you think? > > > > > > -Sergey > > > > > > > + * > > > > + ****************************************************************/ > > > > + > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > + read = true; > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > redundant. > > Am I getting a response on this comment? In accordance with that > conditional statement having dir == DMA_DEV_TO_MEM means performing > read operation. If dir equals DMA_MEM_TO_DEV then a write operation > will be performed. The code path doesn't depend on the chan->dir > value. Only dir is enough. Remote Read, DMA_DEV_TO_MEM, it is a write channel. SAR is the continual address at EP Side, DAR is a scatter list. RC side Local Read, DMA_DEV_TO_MEM, it is a reading channel. SAR is the continual address at RC side, DAR is a scatter list at EP side Actually, both sides should support a scatter list. Like device_prep_dma_memcpy_sg but it is beyond this patch series. > > -Sergey > > > > > > > > + > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > + if (read) { > > > > burst->sar = src_addr; > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > -- > > > > 2.24.0.rc1 > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-10 20:16 ` Zhi Li @ 2022-03-11 12:38 ` Serge Semin 2022-03-11 15:37 ` Zhi Li 2022-03-11 17:55 ` Manivannan Sadhasivam 0 siblings, 2 replies; 52+ messages in thread From: Serge Semin @ 2022-03-11 12:38 UTC (permalink / raw) To: Zhi Li, Manivannan Sadhasivam Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo @Manivannan could you join the discussion? On Thu, Mar 10, 2022 at 02:16:17PM -0600, Zhi Li wrote: > On Thu, Mar 10, 2022 at 1:38 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > On Thu, Mar 10, 2022 at 10:50:14AM -0600, Zhi Li wrote: > > > On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > > > programs the source and destination addresses for read and write. Since the > > > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > > > > > Cc: stable@vger.kernel.org > > > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > > --- > > > > > No change between v1 to v4 > > > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > > index 66dc650577919..507f08db1aad3 100644 > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > struct dw_edma_chunk *chunk; > > > > > struct dw_edma_burst *burst; > > > > > struct dw_edma_desc *desc; > > > > > + bool read = false; > > > > > u32 cnt = 0; > > > > > int i; > > > > > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > chunk->ll_region.sz += burst->sz; > > > > > desc->alloc_sz += burst->sz; > > > > > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > > > + /**************************************************************** > > > > > + * > > > > > > > > > + * Root Complex Endpoint > > > > > + * +-----------------------+ +----------------------+ > > > > > + * | | TX CH | | > > > > > + * | | | | > > > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > > > + * | | | | > > > > > + * | | | | > > > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > > > + * | | | | > > > > > + * | | RX CH | | > > > > > + * +-----------------------+ +----------------------+ > > > > > + * > > > > > + * If eDMA is controlled by the Root complex, TX channel > > > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > > > + * > > > > > + * If eDMA is controlled by the endpoint, RX channel > > > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > > > > > Either I have some wrong notion about this issue, or something wrong > > > > with the explanation above and with this fix below. > > > > > > > > From my understanding of the possible DW eDMA IP-core setups the > > > > scatch above and the text below it are incorrect. Here is the way the > > > > DW eDMA can be used: > > > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > > > CPU/Application Memory is the memory of the CPU attached to the > > > > host/EP controller, while the remote (link partner) memory is the PCIe > > > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > > > by the Rx/Read channels. > > > > > > > > Note it's applicable for both Host and End-point case, when Linux is > > > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > > > end-point, then MEM_TO_DEV means copying data from the local CPU > > > > memory into the remote memory. In general the remote memory can be > > > > either some PCIe device on the bus or the Root Complex' CPU memory, > > > > each of which is some remote device anyway from the Local CPU > > > > perspective. > > > > > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > > > prototype kit. It is a normal PCIe peripheral device with eDMA > > > > embedded, which CPU/Application interface is connected to some > > > > embedded SRAM while remote (link partner) interface is directed > > > > towards the PCIe bus. At the same time the device is setup and handled > > > > by the code running on a CPU connected to the PCIe Host controller. I > > > > think that in order to preserve the normal DMA operations semantics we > > > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > > > host CPU perspective, since that's the side the DMA controller is > > > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > > > to copy data from the host CPU memory into the remote device memory. > > > > It means to allocate Rx/Read channel on the eDMA controller, so one > > > > would be read data from the Local CPU memory and copied it to the PCIe > > > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > > > from it's SRAM into the Host CPU memory. > > > > > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > > > a test setup with no real application, while the case 1) is a real setup > > > > available on our SoC and I guess on yours. > > > > > > > > I think yes. But Remote EP also is a one kind of usage module. Just no one > > > writes an EP functional driver for it yet. Even pci-epf-test was just > > > a test function. > > > I previously sent vNTB patches to implement a virtual network between > > > RC and EP, > > > you can look if you have interest. > > > > AFAIU the remote EP case is the same as 1) anyway. The remote EP is > > handled by its own CPU, which sets up the DW PCIe EP controller > > together with eDMA synthesized into the CPU' SoC. Am I right? While > > the case 2) doesn't have any CPU attached on the PCIe EP. It's just an > > FPGA with PCIe interface and eDMA IP-core installed. In that case all > > the setups are performed by the PCIe Host CPU. That's the root problem > > that causes having all the DEV_TO_MEM/MEM_TO_DEV complications. > > > > So to speak I would suggest for at least to have the scatch fixed in > > accordance with the logic explained in my message. > > > > > > > > > > > > > So what I suggest in the framework of this patch is just to implement > > > > the case 1) only. While the case 2) as it's an artificial one can be > > > > manually handled by the DMA client drivers. BTW There aren't ones available > > > > in the kernel anyway. The only exception is an old-time attempt to get > > > > an eDMA IP test-driver mainlined into the kernel: > > > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > > > But it was long time ago. So it's unlikely to be accepted at all. > > > > > > > > What do you think? > > > > > > > > -Sergey > > > > > > > > > + * > > > > > + ****************************************************************/ > > > > > + > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > + read = true; > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > redundant. > > > > Am I getting a response on this comment? In accordance with that > > conditional statement having dir == DMA_DEV_TO_MEM means performing > > read operation. If dir equals DMA_MEM_TO_DEV then a write operation > > will be performed. The code path doesn't depend on the chan->dir > > value. > > Only dir is enough. Right, in this case the fix is much simpler than suggested here. There is no need in additional local variable and complex conditional statement. It's supposed to be like this: - if (chan->dir == edma_dir_write) { + if (dir == DMA_DEV_TO_MEM) { See my next comment for a detailed explanation. > Remote Read, DMA_DEV_TO_MEM, it is a write channel. > SAR is the continual address at EP Side, DAR is a scatter list. RC side > > Local Read, DMA_DEV_TO_MEM, it is a reading channel. > SAR is the continual address at RC side, DAR is a scatter list at EP side Right, it's a caller responsibility to use a right channel for the operation (by flipping the channel the caller will invert the whole logic). But As I see it what you explain and my notion don't match to what is depicted on the scatch and written in the text below it. Don't you see? - * Root Complex Endpoint + * Linux Root Port/End-point PCIe End-point * +-----------------------+ +----------------------+ - * | | TX CH | | - * | | | | - * | DEV_TO_MEM <-------------+ MEM_TO_DEV | + * | | | | + * | | | | + * | DEV_TO_MEM Rx Ch <-------------+ Tx Ch DEV_TO_MEM | * | | | | * | | | | - * | MEM_TO_DEV +-------------> DEV_TO_MEM | - * | | | | - * | | RX CH | | + * | MEM_TO_DEV Tx Ch +-------------> Rx Ch MEM_TO_DEV | + * | | | | + * | | | | * +-----------------------+ +----------------------+ * - * If eDMA is controlled by the Root complex, TX channel - * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX - * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). + * If eDMA is controlled by the RP/EP, Rx channel + * (EDMA_DIR_READ) is used for device read (DEV_TO_MEM) and Tx + * channel (EDMA_DIR_WRITE) is used for device write (MEM_TO_DEV). + * (Straightforward case.) * - * If eDMA is controlled by the endpoint, RX channel - * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX - * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). + * If eDMA is embedded into an independent PCIe EP, Tx channel + * (EDMA_DIR_WRITE) is used for device read (DEV_TO_MEM) and Rx + * channel (EDMA_DIR_READ) is used for device write (MEM_TO_DEV). I think what was suggested above explains well the semantics you are trying to implement here in the framework of this patch. > > Actually, both sides should support a scatter list. Like > device_prep_dma_memcpy_sg > but it is beyond this patch series. Right, it's beyond your series too, because that feature requires additional modifications. I am not asking about that. -Sergey > > > > > -Sergey > > > > > > > > > > > + > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > + if (read) { > > > > > burst->sar = src_addr; > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > -- > > > > > 2.24.0.rc1 > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-11 12:38 ` Serge Semin @ 2022-03-11 15:37 ` Zhi Li 2022-03-11 16:03 ` Zhi Li 2022-03-11 17:55 ` Manivannan Sadhasivam 1 sibling, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-11 15:37 UTC (permalink / raw) To: Serge Semin Cc: Manivannan Sadhasivam, Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, alan.mikhak On Fri, Mar 11, 2022 at 6:39 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > @Manivannan could you join the discussion? > > On Thu, Mar 10, 2022 at 02:16:17PM -0600, Zhi Li wrote: > > On Thu, Mar 10, 2022 at 1:38 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > On Thu, Mar 10, 2022 at 10:50:14AM -0600, Zhi Li wrote: > > > > On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > > > > programs the source and destination addresses for read and write. Since the > > > > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > > > > > > > Cc: stable@vger.kernel.org > > > > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > > > --- > > > > > > No change between v1 to v4 > > > > > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > index 66dc650577919..507f08db1aad3 100644 > > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > struct dw_edma_chunk *chunk; > > > > > > struct dw_edma_burst *burst; > > > > > > struct dw_edma_desc *desc; > > > > > > + bool read = false; > > > > > > u32 cnt = 0; > > > > > > int i; > > > > > > > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > chunk->ll_region.sz += burst->sz; > > > > > > desc->alloc_sz += burst->sz; > > > > > > > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > > > > + /**************************************************************** > > > > > > + * > > > > > > > > > > > + * Root Complex Endpoint > > > > > > + * +-----------------------+ +----------------------+ > > > > > > + * | | TX CH | | > > > > > > + * | | | | > > > > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > > > > + * | | | | > > > > > > + * | | | | > > > > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > > > > + * | | | | > > > > > > + * | | RX CH | | > > > > > > + * +-----------------------+ +----------------------+ > > > > > > + * > > > > > > + * If eDMA is controlled by the Root complex, TX channel > > > > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > > > > + * > > > > > > + * If eDMA is controlled by the endpoint, RX channel > > > > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > > > > > > > Either I have some wrong notion about this issue, or something wrong > > > > > with the explanation above and with this fix below. > > > > > > > > > > From my understanding of the possible DW eDMA IP-core setups the > > > > > scatch above and the text below it are incorrect. Here is the way the > > > > > DW eDMA can be used: > > > > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > > > > CPU/Application Memory is the memory of the CPU attached to the > > > > > host/EP controller, while the remote (link partner) memory is the PCIe > > > > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > > > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > > > > by the Rx/Read channels. > > > > > > > > > > Note it's applicable for both Host and End-point case, when Linux is > > > > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > > > > end-point, then MEM_TO_DEV means copying data from the local CPU > > > > > memory into the remote memory. In general the remote memory can be > > > > > either some PCIe device on the bus or the Root Complex' CPU memory, > > > > > each of which is some remote device anyway from the Local CPU > > > > > perspective. > > > > > > > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > > > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > > > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > > > > prototype kit. It is a normal PCIe peripheral device with eDMA > > > > > embedded, which CPU/Application interface is connected to some > > > > > embedded SRAM while remote (link partner) interface is directed > > > > > towards the PCIe bus. At the same time the device is setup and handled > > > > > by the code running on a CPU connected to the PCIe Host controller. I > > > > > think that in order to preserve the normal DMA operations semantics we > > > > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > > > > host CPU perspective, since that's the side the DMA controller is > > > > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > > > > to copy data from the host CPU memory into the remote device memory. > > > > > It means to allocate Rx/Read channel on the eDMA controller, so one > > > > > would be read data from the Local CPU memory and copied it to the PCIe > > > > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > > > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > > > > from it's SRAM into the Host CPU memory. > > > > > > > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > > > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > > > > a test setup with no real application, while the case 1) is a real setup > > > > > available on our SoC and I guess on yours. > > > > > > > > > > > I think yes. But Remote EP also is a one kind of usage module. Just no one > > > > writes an EP functional driver for it yet. Even pci-epf-test was just > > > > a test function. > > > > I previously sent vNTB patches to implement a virtual network between > > > > RC and EP, > > > > you can look if you have interest. > > > > > > AFAIU the remote EP case is the same as 1) anyway. The remote EP is > > > handled by its own CPU, which sets up the DW PCIe EP controller > > > together with eDMA synthesized into the CPU' SoC. Am I right? While > > > the case 2) doesn't have any CPU attached on the PCIe EP. It's just an > > > FPGA with PCIe interface and eDMA IP-core installed. In that case all > > > the setups are performed by the PCIe Host CPU. That's the root problem > > > that causes having all the DEV_TO_MEM/MEM_TO_DEV complications. > > > > > > So to speak I would suggest for at least to have the scatch fixed in > > > accordance with the logic explained in my message. > > > > > > > > > > > > > > > > > So what I suggest in the framework of this patch is just to implement > > > > > the case 1) only. While the case 2) as it's an artificial one can be > > > > > manually handled by the DMA client drivers. BTW There aren't ones available > > > > > in the kernel anyway. The only exception is an old-time attempt to get > > > > > an eDMA IP test-driver mainlined into the kernel: > > > > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > > > > But it was long time ago. So it's unlikely to be accepted at all. > > > > > > > > > > What do you think? > > > > > > > > > > -Sergey > > > > > > > > > > > + * > > > > > > + ****************************************************************/ > > > > > > + > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > + read = true; > > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > redundant. > > > > > > Am I getting a response on this comment? In accordance with that > > > conditional statement having dir == DMA_DEV_TO_MEM means performing > > > read operation. If dir equals DMA_MEM_TO_DEV then a write operation > > > will be performed. The code path doesn't depend on the chan->dir > > > value. > > > > > Only dir is enough. > > Right, in this case the fix is much simpler than suggested here. There > is no need in additional local variable and complex conditional > statement. It's supposed to be like this: > > - if (chan->dir == edma_dir_write) { > + if (dir == DMA_DEV_TO_MEM) > See my next comment for a detailed explanation. Actually directly revert patch commit bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 Author: Alan Mikhak <alan.mikhak@sifive.com> Date: Tue Apr 28 18:10:33 2020 -0700 @Alan Mikhak, welcome to join the discussion. We think the original code is correct for both remote DMA and local DMA. Can you help join the discussion to descript what's your test case when you upstream? Actually pci-epf-test.c have not enable local EP dma. How do you test your code? > > > Remote Read, DMA_DEV_TO_MEM, it is a write channel. > > SAR is the continual address at EP Side, DAR is a scatter list. RC side > > > > Local Read, DMA_DEV_TO_MEM, it is a reading channel. > > SAR is the continual address at RC side, DAR is a scatter list at EP side > > Right, it's a caller responsibility to use a right channel for the > operation (by flipping the channel the caller will invert the whole > logic). But As I see it what you explain and my notion don't match to what > is depicted on the scatch and written in the text below it. Don't you see? > > - * Root Complex Endpoint > + * Linux Root Port/End-point PCIe End-point > * +-----------------------+ +----------------------+ > - * | | TX CH | | > - * | | | | > - * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > + * | | | | > + * | | | | > + * | DEV_TO_MEM Rx Ch <-------------+ Tx Ch DEV_TO_MEM | > * | | | | > * | | | | > - * | MEM_TO_DEV +-------------> DEV_TO_MEM | > - * | | | | > - * | | RX CH | | > + * | MEM_TO_DEV Tx Ch +-------------> Rx Ch MEM_TO_DEV | > + * | | | | > + * | | | | > * +-----------------------+ +----------------------+ > * > - * If eDMA is controlled by the Root complex, TX channel > - * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > - * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > + * If eDMA is controlled by the RP/EP, Rx channel > + * (EDMA_DIR_READ) is used for device read (DEV_TO_MEM) and Tx > + * channel (EDMA_DIR_WRITE) is used for device write (MEM_TO_DEV). > + * (Straightforward case.) > * > - * If eDMA is controlled by the endpoint, RX channel > - * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > - * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > + * If eDMA is embedded into an independent PCIe EP, Tx channel > + * (EDMA_DIR_WRITE) is used for device read (DEV_TO_MEM) and Rx > + * channel (EDMA_DIR_READ) is used for device write (MEM_TO_DEV). > > I think what was suggested above explains well the semantics you are > trying to implement here in the framework of this patch. > > > > > Actually, both sides should support a scatter list. Like > > device_prep_dma_memcpy_sg > > but it is beyond this patch series. > > Right, it's beyond your series too, because that feature requires > additional modifications. I am not asking about that. > > -Sergey > > > > > > > > > -Sergey > > > > > > > > > > > > > > + > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > + if (read) { > > > > > > burst->sar = src_addr; > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > -- > > > > > > 2.24.0.rc1 > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-11 15:37 ` Zhi Li @ 2022-03-11 16:03 ` Zhi Li 2022-03-11 17:14 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-11 16:03 UTC (permalink / raw) To: Serge Semin Cc: Manivannan Sadhasivam, Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo On Fri, Mar 11, 2022 at 9:37 AM Zhi Li <lznuaa@gmail.com> wrote: > > On Fri, Mar 11, 2022 at 6:39 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > @Manivannan could you join the discussion? > > > > On Thu, Mar 10, 2022 at 02:16:17PM -0600, Zhi Li wrote: > > > On Thu, Mar 10, 2022 at 1:38 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > On Thu, Mar 10, 2022 at 10:50:14AM -0600, Zhi Li wrote: > > > > > On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > > > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > > > > > programs the source and destination addresses for read and write. Since the > > > > > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > > > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > > > > > > > > > Cc: stable@vger.kernel.org > > > > > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > > > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > > > > --- > > > > > > > No change between v1 to v4 > > > > > > > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > > > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > > index 66dc650577919..507f08db1aad3 100644 > > > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > > struct dw_edma_chunk *chunk; > > > > > > > struct dw_edma_burst *burst; > > > > > > > struct dw_edma_desc *desc; > > > > > > > + bool read = false; > > > > > > > u32 cnt = 0; > > > > > > > int i; > > > > > > > > > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > > chunk->ll_region.sz += burst->sz; > > > > > > > desc->alloc_sz += burst->sz; > > > > > > > > > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > > > > > + /**************************************************************** > > > > > > > + * > > > > > > > > > > > > > + * Root Complex Endpoint > > > > > > > + * +-----------------------+ +----------------------+ > > > > > > > + * | | TX CH | | > > > > > > > + * | | | | > > > > > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > > > > > + * | | | | > > > > > > > + * | | | | > > > > > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > > > > > + * | | | | > > > > > > > + * | | RX CH | | > > > > > > > + * +-----------------------+ +----------------------+ > > > > > > > + * > > > > > > > + * If eDMA is controlled by the Root complex, TX channel > > > > > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > > > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > > > > > + * > > > > > > > + * If eDMA is controlled by the endpoint, RX channel > > > > > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > > > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > > > > > > > > > Either I have some wrong notion about this issue, or something wrong > > > > > > with the explanation above and with this fix below. > > > > > > > > > > > > From my understanding of the possible DW eDMA IP-core setups the > > > > > > scatch above and the text below it are incorrect. Here is the way the > > > > > > DW eDMA can be used: > > > > > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > > > > > CPU/Application Memory is the memory of the CPU attached to the > > > > > > host/EP controller, while the remote (link partner) memory is the PCIe > > > > > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > > > > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > > > > > by the Rx/Read channels. > > > > > > > > > > > > Note it's applicable for both Host and End-point case, when Linux is > > > > > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > > > > > end-point, then MEM_TO_DEV means copying data from the local CPU > > > > > > memory into the remote memory. In general the remote memory can be > > > > > > either some PCIe device on the bus or the Root Complex' CPU memory, > > > > > > each of which is some remote device anyway from the Local CPU > > > > > > perspective. > > > > > > > > > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > > > > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > > > > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > > > > > prototype kit. It is a normal PCIe peripheral device with eDMA > > > > > > embedded, which CPU/Application interface is connected to some > > > > > > embedded SRAM while remote (link partner) interface is directed > > > > > > towards the PCIe bus. At the same time the device is setup and handled > > > > > > by the code running on a CPU connected to the PCIe Host controller. I > > > > > > think that in order to preserve the normal DMA operations semantics we > > > > > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > > > > > host CPU perspective, since that's the side the DMA controller is > > > > > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > > > > > to copy data from the host CPU memory into the remote device memory. > > > > > > It means to allocate Rx/Read channel on the eDMA controller, so one > > > > > > would be read data from the Local CPU memory and copied it to the PCIe > > > > > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > > > > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > > > > > from it's SRAM into the Host CPU memory. > > > > > > > > > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > > > > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > > > > > a test setup with no real application, while the case 1) is a real setup > > > > > > available on our SoC and I guess on yours. > > > > > > > > > > > > > > I think yes. But Remote EP also is a one kind of usage module. Just no one > > > > > writes an EP functional driver for it yet. Even pci-epf-test was just > > > > > a test function. > > > > > I previously sent vNTB patches to implement a virtual network between > > > > > RC and EP, > > > > > you can look if you have interest. > > > > > > > > AFAIU the remote EP case is the same as 1) anyway. The remote EP is > > > > handled by its own CPU, which sets up the DW PCIe EP controller > > > > together with eDMA synthesized into the CPU' SoC. Am I right? While > > > > the case 2) doesn't have any CPU attached on the PCIe EP. It's just an > > > > FPGA with PCIe interface and eDMA IP-core installed. In that case all > > > > the setups are performed by the PCIe Host CPU. That's the root problem > > > > that causes having all the DEV_TO_MEM/MEM_TO_DEV complications. > > > > > > > > So to speak I would suggest for at least to have the scatch fixed in > > > > accordance with the logic explained in my message. > > > > > > > > > > > > > > > > > > > > > So what I suggest in the framework of this patch is just to implement > > > > > > the case 1) only. While the case 2) as it's an artificial one can be > > > > > > manually handled by the DMA client drivers. BTW There aren't ones available > > > > > > in the kernel anyway. The only exception is an old-time attempt to get > > > > > > an eDMA IP test-driver mainlined into the kernel: > > > > > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > > > > > But it was long time ago. So it's unlikely to be accepted at all. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > + * > > > > > > > + ****************************************************************/ > > > > > > > + > > > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > > + read = true; > > > > > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > > redundant. > > > > > > > > Am I getting a response on this comment? In accordance with that > > > > conditional statement having dir == DMA_DEV_TO_MEM means performing > > > > read operation. If dir equals DMA_MEM_TO_DEV then a write operation > > > > will be performed. The code path doesn't depend on the chan->dir > > > > value. > > > > > > > > Only dir is enough. > > > > Right, in this case the fix is much simpler than suggested here. There > > is no need in additional local variable and complex conditional > > statement. It's supposed to be like this: > > > > - if (chan->dir == edma_dir_write) { > > > + if (dir == DMA_DEV_TO_MEM) > > See my next comment for a detailed explanation. > > Actually directly revert patch > > commit bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > Author: Alan Mikhak <alan.mikhak@sifive.com> > Date: Tue Apr 28 18:10:33 2020 -0700 > > @Alan Mikhak, welcome to join the discussion. We think the original code is > correct for both remote DMA and local DMA. Can you help join the discussion to > descript what's your test case when you upstream? Actually pci-epf-test.c have > not enable local EP dma. How do you test your code? Alan Mikhank's email address does not exist now!. @Serge Semin @Manivannan Sadhasivam , how do you think revert bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > > > > > Remote Read, DMA_DEV_TO_MEM, it is a write channel. > > > SAR is the continual address at EP Side, DAR is a scatter list. RC side > > > > > > Local Read, DMA_DEV_TO_MEM, it is a reading channel. > > > SAR is the continual address at RC side, DAR is a scatter list at EP side > > > > Right, it's a caller responsibility to use a right channel for the > > operation (by flipping the channel the caller will invert the whole > > logic). But As I see it what you explain and my notion don't match to what > > is depicted on the scatch and written in the text below it. Don't you see? > > > > - * Root Complex Endpoint > > + * Linux Root Port/End-point PCIe End-point > > * +-----------------------+ +----------------------+ > > - * | | TX CH | | > > - * | | | | > > - * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > + * | | | | > > + * | | | | > > + * | DEV_TO_MEM Rx Ch <-------------+ Tx Ch DEV_TO_MEM | > > * | | | | > > * | | | | > > - * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > - * | | | | > > - * | | RX CH | | > > + * | MEM_TO_DEV Tx Ch +-------------> Rx Ch MEM_TO_DEV | > > + * | | | | > > + * | | | | > > * +-----------------------+ +----------------------+ > > * > > - * If eDMA is controlled by the Root complex, TX channel > > - * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > - * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > + * If eDMA is controlled by the RP/EP, Rx channel > > + * (EDMA_DIR_READ) is used for device read (DEV_TO_MEM) and Tx > > + * channel (EDMA_DIR_WRITE) is used for device write (MEM_TO_DEV). > > + * (Straightforward case.) > > * > > - * If eDMA is controlled by the endpoint, RX channel > > - * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > - * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > + * If eDMA is embedded into an independent PCIe EP, Tx channel > > + * (EDMA_DIR_WRITE) is used for device read (DEV_TO_MEM) and Rx > > + * channel (EDMA_DIR_READ) is used for device write (MEM_TO_DEV). > > > > I think what was suggested above explains well the semantics you are > > trying to implement here in the framework of this patch. > > > > > > > > Actually, both sides should support a scatter list. Like > > > device_prep_dma_memcpy_sg > > > but it is beyond this patch series. > > > > Right, it's beyond your series too, because that feature requires > > additional modifications. I am not asking about that. > > > > -Sergey > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > + > > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > > + if (read) { > > > > > > > burst->sar = src_addr; > > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > > -- > > > > > > > 2.24.0.rc1 > > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-11 16:03 ` Zhi Li @ 2022-03-11 17:14 ` Serge Semin 0 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-11 17:14 UTC (permalink / raw) To: Zhi Li Cc: Serge Semin, Manivannan Sadhasivam, Frank Li, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo On Fri, Mar 11, 2022 at 10:03:48AM -0600, Zhi Li wrote: > On Fri, Mar 11, 2022 at 9:37 AM Zhi Li <lznuaa@gmail.com> wrote: > > > > On Fri, Mar 11, 2022 at 6:39 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > @Manivannan could you join the discussion? > > > > > > On Thu, Mar 10, 2022 at 02:16:17PM -0600, Zhi Li wrote: > > > > On Thu, Mar 10, 2022 at 1:38 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > > > On Thu, Mar 10, 2022 at 10:50:14AM -0600, Zhi Li wrote: > > > > > > On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > > > > > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > > > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > > > > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > > > > > > programs the source and destination addresses for read and write. Since the > > > > > > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > > > > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > > > > > > > > > > > Cc: stable@vger.kernel.org > > > > > > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > > > > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > > > > > --- > > > > > > > > No change between v1 to v4 > > > > > > > > > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > > > > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > > > index 66dc650577919..507f08db1aad3 100644 > > > > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > > > struct dw_edma_chunk *chunk; > > > > > > > > struct dw_edma_burst *burst; > > > > > > > > struct dw_edma_desc *desc; > > > > > > > > + bool read = false; > > > > > > > > u32 cnt = 0; > > > > > > > > int i; > > > > > > > > > > > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > > > chunk->ll_region.sz += burst->sz; > > > > > > > > desc->alloc_sz += burst->sz; > > > > > > > > > > > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > > > > > > + /**************************************************************** > > > > > > > > + * > > > > > > > > > > > > > > > + * Root Complex Endpoint > > > > > > > > + * +-----------------------+ +----------------------+ > > > > > > > > + * | | TX CH | | > > > > > > > > + * | | | | > > > > > > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > > > > > > + * | | | | > > > > > > > > + * | | | | > > > > > > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > > > > > > + * | | | | > > > > > > > > + * | | RX CH | | > > > > > > > > + * +-----------------------+ +----------------------+ > > > > > > > > + * > > > > > > > > + * If eDMA is controlled by the Root complex, TX channel > > > > > > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > > > > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > > > > > > + * > > > > > > > > + * If eDMA is controlled by the endpoint, RX channel > > > > > > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > > > > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > > > > > > > > > > > Either I have some wrong notion about this issue, or something wrong > > > > > > > with the explanation above and with this fix below. > > > > > > > > > > > > > > From my understanding of the possible DW eDMA IP-core setups the > > > > > > > scatch above and the text below it are incorrect. Here is the way the > > > > > > > DW eDMA can be used: > > > > > > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > > > > > > CPU/Application Memory is the memory of the CPU attached to the > > > > > > > host/EP controller, while the remote (link partner) memory is the PCIe > > > > > > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > > > > > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > > > > > > by the Rx/Read channels. > > > > > > > > > > > > > > Note it's applicable for both Host and End-point case, when Linux is > > > > > > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > > > > > > end-point, then MEM_TO_DEV means copying data from the local CPU > > > > > > > memory into the remote memory. In general the remote memory can be > > > > > > > either some PCIe device on the bus or the Root Complex' CPU memory, > > > > > > > each of which is some remote device anyway from the Local CPU > > > > > > > perspective. > > > > > > > > > > > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > > > > > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > > > > > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > > > > > > prototype kit. It is a normal PCIe peripheral device with eDMA > > > > > > > embedded, which CPU/Application interface is connected to some > > > > > > > embedded SRAM while remote (link partner) interface is directed > > > > > > > towards the PCIe bus. At the same time the device is setup and handled > > > > > > > by the code running on a CPU connected to the PCIe Host controller. I > > > > > > > think that in order to preserve the normal DMA operations semantics we > > > > > > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > > > > > > host CPU perspective, since that's the side the DMA controller is > > > > > > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > > > > > > to copy data from the host CPU memory into the remote device memory. > > > > > > > It means to allocate Rx/Read channel on the eDMA controller, so one > > > > > > > would be read data from the Local CPU memory and copied it to the PCIe > > > > > > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > > > > > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > > > > > > from it's SRAM into the Host CPU memory. > > > > > > > > > > > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > > > > > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > > > > > > a test setup with no real application, while the case 1) is a real setup > > > > > > > available on our SoC and I guess on yours. > > > > > > > > > > > > > > > > > I think yes. But Remote EP also is a one kind of usage module. Just no one > > > > > > writes an EP functional driver for it yet. Even pci-epf-test was just > > > > > > a test function. > > > > > > I previously sent vNTB patches to implement a virtual network between > > > > > > RC and EP, > > > > > > you can look if you have interest. > > > > > > > > > > AFAIU the remote EP case is the same as 1) anyway. The remote EP is > > > > > handled by its own CPU, which sets up the DW PCIe EP controller > > > > > together with eDMA synthesized into the CPU' SoC. Am I right? While > > > > > the case 2) doesn't have any CPU attached on the PCIe EP. It's just an > > > > > FPGA with PCIe interface and eDMA IP-core installed. In that case all > > > > > the setups are performed by the PCIe Host CPU. That's the root problem > > > > > that causes having all the DEV_TO_MEM/MEM_TO_DEV complications. > > > > > > > > > > So to speak I would suggest for at least to have the scatch fixed in > > > > > accordance with the logic explained in my message. > > > > > > > > > > > > > > > > > > > > > > > > > So what I suggest in the framework of this patch is just to implement > > > > > > > the case 1) only. While the case 2) as it's an artificial one can be > > > > > > > manually handled by the DMA client drivers. BTW There aren't ones available > > > > > > > in the kernel anyway. The only exception is an old-time attempt to get > > > > > > > an eDMA IP test-driver mainlined into the kernel: > > > > > > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > > > > > > But it was long time ago. So it's unlikely to be accepted at all. > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > + * > > > > > > > > + ****************************************************************/ > > > > > > > > + > > > > > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > > > + read = true; > > > > > > > > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > > > redundant. > > > > > > > > > > Am I getting a response on this comment? In accordance with that > > > > > conditional statement having dir == DMA_DEV_TO_MEM means performing > > > > > read operation. If dir equals DMA_MEM_TO_DEV then a write operation > > > > > will be performed. The code path doesn't depend on the chan->dir > > > > > value. > > > > > > > > > > > Only dir is enough. > > > > > > Right, in this case the fix is much simpler than suggested here. There > > > is no need in additional local variable and complex conditional > > > statement. It's supposed to be like this: > > > > > > - if (chan->dir == edma_dir_write) { > > > > > + if (dir == DMA_DEV_TO_MEM) > > > See my next comment for a detailed explanation. > > > > Actually directly revert patch > > > > commit bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > Author: Alan Mikhak <alan.mikhak@sifive.com> > > Date: Tue Apr 28 18:10:33 2020 -0700 > > > > @Alan Mikhak, welcome to join the discussion. We think the original code is > > correct for both remote DMA and local DMA. Can you help join the discussion to > > descript what's your test case when you upstream? Actually pci-epf-test.c have > > not enable local EP dma. How do you test your code? > > Alan Mikhank's email address does not exist now!. > @Serge Semin @Manivannan Sadhasivam , how do you think revert > bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 AFAIU reversion won't solve the problem, since it will get back the statement: - if ((direction == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_WRITE) || - (direction == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ)) return NULL; That will prevent the code from supporting the Linux Root Port/End-point case in the notation of my scatch. So we need to add a well-justified fix with clear explanation and in-line comment. Let's wait for the @Manivannan's response. -Sergey > > > > > > > > > > Remote Read, DMA_DEV_TO_MEM, it is a write channel. > > > > SAR is the continual address at EP Side, DAR is a scatter list. RC side > > > > > > > > Local Read, DMA_DEV_TO_MEM, it is a reading channel. > > > > SAR is the continual address at RC side, DAR is a scatter list at EP side > > > > > > Right, it's a caller responsibility to use a right channel for the > > > operation (by flipping the channel the caller will invert the whole > > > logic). But As I see it what you explain and my notion don't match to what > > > is depicted on the scatch and written in the text below it. Don't you see? > > > > > > - * Root Complex Endpoint > > > + * Linux Root Port/End-point PCIe End-point > > > * +-----------------------+ +----------------------+ > > > - * | | TX CH | | > > > - * | | | | > > > - * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > + * | | | | > > > + * | | | | > > > + * | DEV_TO_MEM Rx Ch <-------------+ Tx Ch DEV_TO_MEM | > > > * | | | | > > > * | | | | > > > - * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > - * | | | | > > > - * | | RX CH | | > > > + * | MEM_TO_DEV Tx Ch +-------------> Rx Ch MEM_TO_DEV | > > > + * | | | | > > > + * | | | | > > > * +-----------------------+ +----------------------+ > > > * > > > - * If eDMA is controlled by the Root complex, TX channel > > > - * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > - * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > + * If eDMA is controlled by the RP/EP, Rx channel > > > + * (EDMA_DIR_READ) is used for device read (DEV_TO_MEM) and Tx > > > + * channel (EDMA_DIR_WRITE) is used for device write (MEM_TO_DEV). > > > + * (Straightforward case.) > > > * > > > - * If eDMA is controlled by the endpoint, RX channel > > > - * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > - * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > + * If eDMA is embedded into an independent PCIe EP, Tx channel > > > + * (EDMA_DIR_WRITE) is used for device read (DEV_TO_MEM) and Rx > > > + * channel (EDMA_DIR_READ) is used for device write (MEM_TO_DEV). > > > > > > I think what was suggested above explains well the semantics you are > > > trying to implement here in the framework of this patch. > > > > > > > > > > > Actually, both sides should support a scatter list. Like > > > > device_prep_dma_memcpy_sg > > > > but it is beyond this patch series. > > > > > > Right, it's beyond your series too, because that feature requires > > > additional modifications. I am not asking about that. > > > > > > -Sergey > > > > > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > > > > + > > > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > > > + if (read) { > > > > > > > > burst->sar = src_addr; > > > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > > > -- > > > > > > > > 2.24.0.rc1 > > > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-11 12:38 ` Serge Semin 2022-03-11 15:37 ` Zhi Li @ 2022-03-11 17:55 ` Manivannan Sadhasivam 2022-03-11 19:08 ` Serge Semin 1 sibling, 1 reply; 52+ messages in thread From: Manivannan Sadhasivam @ 2022-03-11 17:55 UTC (permalink / raw) To: Serge Semin Cc: Zhi Li, Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo On Fri, Mar 11, 2022 at 03:38:57PM +0300, Serge Semin wrote: > @Manivannan could you join the discussion? > > On Thu, Mar 10, 2022 at 02:16:17PM -0600, Zhi Li wrote: > > On Thu, Mar 10, 2022 at 1:38 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > On Thu, Mar 10, 2022 at 10:50:14AM -0600, Zhi Li wrote: > > > > On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > > > > programs the source and destination addresses for read and write. Since the > > > > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > > > > > > > Cc: stable@vger.kernel.org > > > > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > > > --- > > > > > > No change between v1 to v4 > > > > > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > index 66dc650577919..507f08db1aad3 100644 > > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > struct dw_edma_chunk *chunk; > > > > > > struct dw_edma_burst *burst; > > > > > > struct dw_edma_desc *desc; > > > > > > + bool read = false; > > > > > > u32 cnt = 0; > > > > > > int i; > > > > > > > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > chunk->ll_region.sz += burst->sz; > > > > > > desc->alloc_sz += burst->sz; > > > > > > > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > > > > + /**************************************************************** > > > > > > + * > > > > > > > > > > > + * Root Complex Endpoint > > > > > > + * +-----------------------+ +----------------------+ > > > > > > + * | | TX CH | | > > > > > > + * | | | | > > > > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > > > > + * | | | | > > > > > > + * | | | | > > > > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > > > > + * | | | | > > > > > > + * | | RX CH | | > > > > > > + * +-----------------------+ +----------------------+ > > > > > > + * > > > > > > + * If eDMA is controlled by the Root complex, TX channel > > > > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > > > > + * > > > > > > + * If eDMA is controlled by the endpoint, RX channel > > > > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > > > > > > > Either I have some wrong notion about this issue, or something wrong > > > > > with the explanation above and with this fix below. > > > > > > > > > > From my understanding of the possible DW eDMA IP-core setups the > > > > > scatch above and the text below it are incorrect. Here is the way the > > > > > DW eDMA can be used: > > > > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > > > > CPU/Application Memory is the memory of the CPU attached to the > > > > > host/EP controller, while the remote (link partner) memory is the PCIe > > > > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > > > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > > > > by the Rx/Read channels. > > > > > > > > > > Note it's applicable for both Host and End-point case, when Linux is > > > > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > > > > end-point, then MEM_TO_DEV means copying data from the local CPU > > > > > memory into the remote memory. In general the remote memory can be > > > > > either some PCIe device on the bus or the Root Complex' CPU memory, > > > > > each of which is some remote device anyway from the Local CPU > > > > > perspective. > > > > > > > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > > > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > > > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > > > > prototype kit. It is a normal PCIe peripheral device with eDMA > > > > > embedded, which CPU/Application interface is connected to some > > > > > embedded SRAM while remote (link partner) interface is directed > > > > > towards the PCIe bus. At the same time the device is setup and handled > > > > > by the code running on a CPU connected to the PCIe Host controller. I > > > > > think that in order to preserve the normal DMA operations semantics we > > > > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > > > > host CPU perspective, since that's the side the DMA controller is > > > > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > > > > to copy data from the host CPU memory into the remote device memory. > > > > > It means to allocate Rx/Read channel on the eDMA controller, so one > > > > > would be read data from the Local CPU memory and copied it to the PCIe > > > > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > > > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > > > > from it's SRAM into the Host CPU memory. > > > > > > > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > > > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > > > > a test setup with no real application, while the case 1) is a real setup > > > > > available on our SoC and I guess on yours. > > > > > > > > > > > I think yes. But Remote EP also is a one kind of usage module. Just no one > > > > writes an EP functional driver for it yet. Even pci-epf-test was just > > > > a test function. > > > > I previously sent vNTB patches to implement a virtual network between > > > > RC and EP, > > > > you can look if you have interest. > > > > > > AFAIU the remote EP case is the same as 1) anyway. The remote EP is > > > handled by its own CPU, which sets up the DW PCIe EP controller > > > together with eDMA synthesized into the CPU' SoC. Am I right? While > > > the case 2) doesn't have any CPU attached on the PCIe EP. It's just an > > > FPGA with PCIe interface and eDMA IP-core installed. In that case all > > > the setups are performed by the PCIe Host CPU. That's the root problem > > > that causes having all the DEV_TO_MEM/MEM_TO_DEV complications. > > > > > > So to speak I would suggest for at least to have the scatch fixed in > > > accordance with the logic explained in my message. > > > > > > > > > > > > > > > > > So what I suggest in the framework of this patch is just to implement > > > > > the case 1) only. While the case 2) as it's an artificial one can be > > > > > manually handled by the DMA client drivers. BTW There aren't ones available > > > > > in the kernel anyway. The only exception is an old-time attempt to get > > > > > an eDMA IP test-driver mainlined into the kernel: > > > > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > > > > But it was long time ago. So it's unlikely to be accepted at all. > > > > > > > > > > What do you think? > > > > > > > > > > -Sergey > > > > > > > > > > > + * > > > > > > + ****************************************************************/ > > > > > > + > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > + read = true; > > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > redundant. > > > > > > Am I getting a response on this comment? In accordance with that > > > conditional statement having dir == DMA_DEV_TO_MEM means performing > > > read operation. If dir equals DMA_MEM_TO_DEV then a write operation > > > will be performed. The code path doesn't depend on the chan->dir > > > value. > > > > > Only dir is enough. > > Right, in this case the fix is much simpler than suggested here. There > is no need in additional local variable and complex conditional > statement. It's supposed to be like this: > > - if (chan->dir == edma_dir_write) { > + if (dir == DMA_DEV_TO_MEM) { > > See my next comment for a detailed explanation. > > > Remote Read, DMA_DEV_TO_MEM, it is a write channel. > > SAR is the continual address at EP Side, DAR is a scatter list. RC side > > > > Local Read, DMA_DEV_TO_MEM, it is a reading channel. > > SAR is the continual address at RC side, DAR is a scatter list at EP side > > Right, it's a caller responsibility to use a right channel for the > operation (by flipping the channel the caller will invert the whole > logic). But As I see it what you explain and my notion don't match to what > is depicted on the scatch and written in the text below it. Don't you see? > > - * Root Complex Endpoint > + * Linux Root Port/End-point PCIe End-point > * +-----------------------+ +----------------------+ > - * | | TX CH | | > - * | | | | > - * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > + * | | | | > + * | | | | > + * | DEV_TO_MEM Rx Ch <-------------+ Tx Ch DEV_TO_MEM | > * | | | | > * | | | | > - * | MEM_TO_DEV +-------------> DEV_TO_MEM | > - * | | | | > - * | | RX CH | | > + * | MEM_TO_DEV Tx Ch +-------------> Rx Ch MEM_TO_DEV | > + * | | | | > + * | | | | > * +-----------------------+ +----------------------+ > * > - * If eDMA is controlled by the Root complex, TX channel > - * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > - * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > + * If eDMA is controlled by the RP/EP, Rx channel > + * (EDMA_DIR_READ) is used for device read (DEV_TO_MEM) and Tx > + * channel (EDMA_DIR_WRITE) is used for device write (MEM_TO_DEV). > + * (Straightforward case.) > * > - * If eDMA is controlled by the endpoint, RX channel > - * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > - * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > + * If eDMA is embedded into an independent PCIe EP, Tx channel > + * (EDMA_DIR_WRITE) is used for device read (DEV_TO_MEM) and Rx > + * channel (EDMA_DIR_READ) is used for device write (MEM_TO_DEV). > > I think what was suggested above explains well the semantics you are > trying to implement here in the framework of this patch. > > > > > Actually, both sides should support a scatter list. Like > > device_prep_dma_memcpy_sg > > but it is beyond this patch series. > As I said in other reply, my reasoning was entirely based on the eDMA test application. Since it came from Synopsys, I went with that logic of channel configuration. But if someone from Synopsys confirms that your logic is correct, I'm fine with reworking my commit. Thanks, Mani > Right, it's beyond your series too, because that feature requires > additional modifications. I am not asking about that. > > -Sergey > > > > > > > > > -Sergey > > > > > > > > > > > > > > + > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > + if (read) { > > > > > > burst->sar = src_addr; > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > -- > > > > > > 2.24.0.rc1 > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-11 17:55 ` Manivannan Sadhasivam @ 2022-03-11 19:08 ` Serge Semin 0 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-11 19:08 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Serge Semin, Zhi Li, Frank Li, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo On Fri, Mar 11, 2022 at 11:25:56PM +0530, Manivannan Sadhasivam wrote: > On Fri, Mar 11, 2022 at 03:38:57PM +0300, Serge Semin wrote: > > @Manivannan could you join the discussion? > > > > On Thu, Mar 10, 2022 at 02:16:17PM -0600, Zhi Li wrote: > > > On Thu, Mar 10, 2022 at 1:38 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > On Thu, Mar 10, 2022 at 10:50:14AM -0600, Zhi Li wrote: > > > > > On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > > > > > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > > > > > programs the source and destination addresses for read and write. Since the > > > > > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > > > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > > > > > > > > > Cc: stable@vger.kernel.org > > > > > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > > > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > > > > --- > > > > > > > No change between v1 to v4 > > > > > > > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > > > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > > index 66dc650577919..507f08db1aad3 100644 > > > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > > struct dw_edma_chunk *chunk; > > > > > > > struct dw_edma_burst *burst; > > > > > > > struct dw_edma_desc *desc; > > > > > > > + bool read = false; > > > > > > > u32 cnt = 0; > > > > > > > int i; > > > > > > > > > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > > > > chunk->ll_region.sz += burst->sz; > > > > > > > desc->alloc_sz += burst->sz; > > > > > > > > > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > > > > > + /**************************************************************** > > > > > > > + * > > > > > > > > > > > > > + * Root Complex Endpoint > > > > > > > + * +-----------------------+ +----------------------+ > > > > > > > + * | | TX CH | | > > > > > > > + * | | | | > > > > > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > > > > > + * | | | | > > > > > > > + * | | | | > > > > > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > > > > > + * | | | | > > > > > > > + * | | RX CH | | > > > > > > > + * +-----------------------+ +----------------------+ > > > > > > > + * > > > > > > > + * If eDMA is controlled by the Root complex, TX channel > > > > > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > > > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > > > > > + * > > > > > > > + * If eDMA is controlled by the endpoint, RX channel > > > > > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > > > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > > > > > > > > > Either I have some wrong notion about this issue, or something wrong > > > > > > with the explanation above and with this fix below. > > > > > > > > > > > > From my understanding of the possible DW eDMA IP-core setups the > > > > > > scatch above and the text below it are incorrect. Here is the way the > > > > > > DW eDMA can be used: > > > > > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > > > > > CPU/Application Memory is the memory of the CPU attached to the > > > > > > host/EP controller, while the remote (link partner) memory is the PCIe > > > > > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > > > > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > > > > > by the Rx/Read channels. > > > > > > > > > > > > Note it's applicable for both Host and End-point case, when Linux is > > > > > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > > > > > end-point, then MEM_TO_DEV means copying data from the local CPU > > > > > > memory into the remote memory. In general the remote memory can be > > > > > > either some PCIe device on the bus or the Root Complex' CPU memory, > > > > > > each of which is some remote device anyway from the Local CPU > > > > > > perspective. > > > > > > > > > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > > > > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > > > > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > > > > > prototype kit. It is a normal PCIe peripheral device with eDMA > > > > > > embedded, which CPU/Application interface is connected to some > > > > > > embedded SRAM while remote (link partner) interface is directed > > > > > > towards the PCIe bus. At the same time the device is setup and handled > > > > > > by the code running on a CPU connected to the PCIe Host controller. I > > > > > > think that in order to preserve the normal DMA operations semantics we > > > > > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > > > > > host CPU perspective, since that's the side the DMA controller is > > > > > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > > > > > to copy data from the host CPU memory into the remote device memory. > > > > > > It means to allocate Rx/Read channel on the eDMA controller, so one > > > > > > would be read data from the Local CPU memory and copied it to the PCIe > > > > > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > > > > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > > > > > from it's SRAM into the Host CPU memory. > > > > > > > > > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > > > > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > > > > > a test setup with no real application, while the case 1) is a real setup > > > > > > available on our SoC and I guess on yours. > > > > > > > > > > > > > > I think yes. But Remote EP also is a one kind of usage module. Just no one > > > > > writes an EP functional driver for it yet. Even pci-epf-test was just > > > > > a test function. > > > > > I previously sent vNTB patches to implement a virtual network between > > > > > RC and EP, > > > > > you can look if you have interest. > > > > > > > > AFAIU the remote EP case is the same as 1) anyway. The remote EP is > > > > handled by its own CPU, which sets up the DW PCIe EP controller > > > > together with eDMA synthesized into the CPU' SoC. Am I right? While > > > > the case 2) doesn't have any CPU attached on the PCIe EP. It's just an > > > > FPGA with PCIe interface and eDMA IP-core installed. In that case all > > > > the setups are performed by the PCIe Host CPU. That's the root problem > > > > that causes having all the DEV_TO_MEM/MEM_TO_DEV complications. > > > > > > > > So to speak I would suggest for at least to have the scatch fixed in > > > > accordance with the logic explained in my message. > > > > > > > > > > > > > > > > > > > > > So what I suggest in the framework of this patch is just to implement > > > > > > the case 1) only. While the case 2) as it's an artificial one can be > > > > > > manually handled by the DMA client drivers. BTW There aren't ones available > > > > > > in the kernel anyway. The only exception is an old-time attempt to get > > > > > > an eDMA IP test-driver mainlined into the kernel: > > > > > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > > > > > But it was long time ago. So it's unlikely to be accepted at all. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > + * > > > > > > > + ****************************************************************/ > > > > > > > + > > > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > > + read = true; > > > > > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > > redundant. > > > > > > > > Am I getting a response on this comment? In accordance with that > > > > conditional statement having dir == DMA_DEV_TO_MEM means performing > > > > read operation. If dir equals DMA_MEM_TO_DEV then a write operation > > > > will be performed. The code path doesn't depend on the chan->dir > > > > value. > > > > > > > > Only dir is enough. > > > > Right, in this case the fix is much simpler than suggested here. There > > is no need in additional local variable and complex conditional > > statement. It's supposed to be like this: > > > > - if (chan->dir == edma_dir_write) { > > + if (dir == DMA_DEV_TO_MEM) { > > > > See my next comment for a detailed explanation. > > > > > Remote Read, DMA_DEV_TO_MEM, it is a write channel. > > > SAR is the continual address at EP Side, DAR is a scatter list. RC side > > > > > > Local Read, DMA_DEV_TO_MEM, it is a reading channel. > > > SAR is the continual address at RC side, DAR is a scatter list at EP side > > > > Right, it's a caller responsibility to use a right channel for the > > operation (by flipping the channel the caller will invert the whole > > logic). But As I see it what you explain and my notion don't match to what > > is depicted on the scatch and written in the text below it. Don't you see? > > > > - * Root Complex Endpoint > > + * Linux Root Port/End-point PCIe End-point > > * +-----------------------+ +----------------------+ > > - * | | TX CH | | > > - * | | | | > > - * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > + * | | | | > > + * | | | | > > + * | DEV_TO_MEM Rx Ch <-------------+ Tx Ch DEV_TO_MEM | > > * | | | | > > * | | | | > > - * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > - * | | | | > > - * | | RX CH | | > > + * | MEM_TO_DEV Tx Ch +-------------> Rx Ch MEM_TO_DEV | > > + * | | | | > > + * | | | | > > * +-----------------------+ +----------------------+ > > * > > - * If eDMA is controlled by the Root complex, TX channel > > - * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > - * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > + * If eDMA is controlled by the RP/EP, Rx channel > > + * (EDMA_DIR_READ) is used for device read (DEV_TO_MEM) and Tx > > + * channel (EDMA_DIR_WRITE) is used for device write (MEM_TO_DEV). > > + * (Straightforward case.) > > * > > - * If eDMA is controlled by the endpoint, RX channel > > - * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > - * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > + * If eDMA is embedded into an independent PCIe EP, Tx channel > > + * (EDMA_DIR_WRITE) is used for device read (DEV_TO_MEM) and Rx > > + * channel (EDMA_DIR_READ) is used for device write (MEM_TO_DEV). > > > > I think what was suggested above explains well the semantics you are > > trying to implement here in the framework of this patch. > > > > > > > > Actually, both sides should support a scatter list. Like > > > device_prep_dma_memcpy_sg > > > but it is beyond this patch series. > > > > As I said in other reply, my reasoning was entirely based on the eDMA test > application. Since it came from Synopsys, I went with that logic of channel > configuration. > > But if someone from Synopsys confirms that your logic is correct, I'm fine with > reworking my commit. There is no need in waiting for the Synopsys response. I've got info manuals of my own to say: 1) Your fix is correct, but the conditional statement has redundant operations. It can be simplified as I suggested. 2) Your scatch and text are incorrect and they must be fixed so not to be confusing. -Sergey > > Thanks, > Mani > > > Right, it's beyond your series too, because that feature requires > > additional modifications. I am not asking about that. > > > > -Sergey > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > + > > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > > + if (read) { > > > > > > > burst->sar = src_addr; > > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > > -- > > > > > > > 2.24.0.rc1 > > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-10 19:37 ` Serge Semin 2022-03-10 20:16 ` Zhi Li @ 2022-03-11 17:46 ` Manivannan Sadhasivam 1 sibling, 0 replies; 52+ messages in thread From: Manivannan Sadhasivam @ 2022-03-11 17:46 UTC (permalink / raw) To: Serge Semin Cc: Zhi Li, Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo On Thu, Mar 10, 2022 at 10:37:59PM +0300, Serge Semin wrote: > On Thu, Mar 10, 2022 at 10:50:14AM -0600, Zhi Li wrote: > > On Thu, Mar 10, 2022 at 10:32 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > > programs the source and destination addresses for read and write. Since the > > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > > > Cc: stable@vger.kernel.org > > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > --- > > > > No change between v1 to v4 > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > index 66dc650577919..507f08db1aad3 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > struct dw_edma_chunk *chunk; > > > > struct dw_edma_burst *burst; > > > > struct dw_edma_desc *desc; > > > > + bool read = false; > > > > u32 cnt = 0; > > > > int i; > > > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > chunk->ll_region.sz += burst->sz; > > > > desc->alloc_sz += burst->sz; > > > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > > + /**************************************************************** > > > > + * > > > > > > > + * Root Complex Endpoint > > > > + * +-----------------------+ +----------------------+ > > > > + * | | TX CH | | > > > > + * | | | | > > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > > + * | | | | > > > > + * | | | | > > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > > + * | | | | > > > > + * | | RX CH | | > > > > + * +-----------------------+ +----------------------+ > > > > + * > > > > + * If eDMA is controlled by the Root complex, TX channel > > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > > + * > > > > + * If eDMA is controlled by the endpoint, RX channel > > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > > > Either I have some wrong notion about this issue, or something wrong > > > with the explanation above and with this fix below. > > > > > > From my understanding of the possible DW eDMA IP-core setups the > > > scatch above and the text below it are incorrect. Here is the way the > > > DW eDMA can be used: > > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > > CPU/Application Memory is the memory of the CPU attached to the > > > host/EP controller, while the remote (link partner) memory is the PCIe > > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > > by the Rx/Read channels. > > > > > > Note it's applicable for both Host and End-point case, when Linux is > > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > > end-point, then MEM_TO_DEV means copying data from the local CPU > > > memory into the remote memory. In general the remote memory can be > > > either some PCIe device on the bus or the Root Complex' CPU memory, > > > each of which is some remote device anyway from the Local CPU > > > perspective. > > > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > > prototype kit. It is a normal PCIe peripheral device with eDMA > > > embedded, which CPU/Application interface is connected to some > > > embedded SRAM while remote (link partner) interface is directed > > > towards the PCIe bus. At the same time the device is setup and handled > > > by the code running on a CPU connected to the PCIe Host controller. I > > > think that in order to preserve the normal DMA operations semantics we > > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > > host CPU perspective, since that's the side the DMA controller is > > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > > to copy data from the host CPU memory into the remote device memory. > > > It means to allocate Rx/Read channel on the eDMA controller, so one > > > would be read data from the Local CPU memory and copied it to the PCIe > > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > > from it's SRAM into the Host CPU memory. > > > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > > a test setup with no real application, while the case 1) is a real setup > > > available on our SoC and I guess on yours. > > > > > I think yes. But Remote EP also is a one kind of usage module. Just no one > > writes an EP functional driver for it yet. Even pci-epf-test was just > > a test function. > > I previously sent vNTB patches to implement a virtual network between > > RC and EP, > > you can look if you have interest. > > AFAIU the remote EP case is the same as 1) anyway. The remote EP is > handled by its own CPU, which sets up the DW PCIe EP controller > together with eDMA synthesized into the CPU' SoC. Am I right? While > the case 2) doesn't have any CPU attached on the PCIe EP. It's just an > FPGA with PCIe interface and eDMA IP-core installed. In that case all > the setups are performed by the PCIe Host CPU. That's the root problem > that causes having all the DEV_TO_MEM/MEM_TO_DEV complications. > > So to speak I would suggest for at least to have the scatch fixed in > accordance with the logic explained in my message. > > > > > > > > > So what I suggest in the framework of this patch is just to implement > > > the case 1) only. While the case 2) as it's an artificial one can be > > > manually handled by the DMA client drivers. BTW There aren't ones available > > > in the kernel anyway. The only exception is an old-time attempt to get > > > an eDMA IP test-driver mainlined into the kernel: > > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > > But it was long time ago. So it's unlikely to be accepted at all. > > > > > > What do you think? > > > > > > -Sergey > > > > > > > + * > > > > + ****************************************************************/ > > > > + > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > + read = true; > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > redundant. > > Am I getting a response on this comment? In accordance with that > conditional statement having dir == DMA_DEV_TO_MEM means performing > read operation. If dir equals DMA_MEM_TO_DEV then a write operation > will be performed. The code path doesn't depend on the chan->dir > value. > As per the eDMA test application [1] submitted a while ago, my logic is correct: + if (thread->direction == DMA_DEV_TO_MEM) { + /* DMA_DEV_TO_MEM - WRITE - DMA_FROM_DEVICE */ + dev_dbg(dev, "%s: DMA_DEV_TO_MEM - WRITE - DMA_FROM_DEVICE\n", + dma_chan_name(chan)); + err = dma_map_sg(dev, sgt->sgl, sgt->nents, DMA_FROM_DEVICE); + if (!err) + goto err_descs; + + sgt->nents = err; + /* Endpoint memory */ + sconf.src_addr = dt_region->paddr; + /* CPU memory */ + sconf.dst_addr = descs[0].paddr; + } else { + /* DMA_MEM_TO_DEV - READ - DMA_TO_DEVICE */ + dev_dbg(dev, "%s: DMA_MEM_TO_DEV - READ - DMA_TO_DEVICE\n", + dma_chan_name(chan)); + err = dma_map_sg(dev, sgt->sgl, sgt->nents, DMA_TO_DEVICE); + if (!err) + goto err_descs; + + sgt->nents = err; + /* CPU memory */ + sconf.src_addr = descs[0].paddr; + /* Endpoint memory */ + sconf.dst_addr = dt_region->paddr; + } [1] https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ Thanks, Mani > -Sergey > > > > > > > > + > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > + if (read) { > > > > burst->sar = src_addr; > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > -- > > > > 2.24.0.rc1 > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-10 16:31 ` Serge Semin 2022-03-10 16:50 ` Zhi Li @ 2022-03-11 17:41 ` Manivannan Sadhasivam 2022-03-11 19:01 ` Serge Semin 1 sibling, 1 reply; 52+ messages in thread From: Manivannan Sadhasivam @ 2022-03-11 17:41 UTC (permalink / raw) To: Serge Semin Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Thu, Mar 10, 2022 at 07:31:23PM +0300, Serge Semin wrote: > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > programs the source and destination addresses for read and write. Since the > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > issue by finding out the read operation first and program the eDMA accordingly. > > > > Cc: stable@vger.kernel.org > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > --- > > No change between v1 to v4 > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > index 66dc650577919..507f08db1aad3 100644 > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > struct dw_edma_chunk *chunk; > > struct dw_edma_burst *burst; > > struct dw_edma_desc *desc; > > + bool read = false; > > u32 cnt = 0; > > int i; > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > chunk->ll_region.sz += burst->sz; > > desc->alloc_sz += burst->sz; > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > + /**************************************************************** > > + * > > > + * Root Complex Endpoint > > + * +-----------------------+ +----------------------+ > > + * | | TX CH | | > > + * | | | | > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > + * | | | | > > + * | | | | > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > + * | | | | > > + * | | RX CH | | > > + * +-----------------------+ +----------------------+ > > + * > > + * If eDMA is controlled by the Root complex, TX channel > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > + * > > + * If eDMA is controlled by the endpoint, RX channel > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > Either I have some wrong notion about this issue, or something wrong > with the explanation above and with this fix below. > > From my understanding of the possible DW eDMA IP-core setups the > scatch above and the text below it are incorrect. Here is the way the > DW eDMA can be used: > 1) Embedded into the DW PCIe Host/EP controller. In this case > CPU/Application Memory is the memory of the CPU attached to the > host/EP controller, while the remote (link partner) memory is the PCIe > bus memory. In this case MEM_TO_DEV operation is supposed to be > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > by the Rx/Read channels. > I'm not aware or even not sure about the use of eDMA in the PCIe host. If that's the case, how the endpoint can access it from remote perspective? Do you have a usecase or an example where used or even documented? > Note it's applicable for both Host and End-point case, when Linux is > running on the CPU-side of the eDMA controller. So if it's DW PCIe > end-point, then MEM_TO_DEV means copying data from the local CPU > memory into the remote memory. In general the remote memory can be > either some PCIe device on the bus or the Root Complex' CPU memory, > each of which is some remote device anyway from the Local CPU > perspective. > > 2) Embedded into the PCIe EP. This case is implemented in the > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > and from the driver code, that device is a Synopsys PCIe EndPoint IP > prototype kit. It is a normal PCIe peripheral device with eDMA > embedded, which CPU/Application interface is connected to some > embedded SRAM while remote (link partner) interface is directed > towards the PCIe bus. At the same time the device is setup and handled > by the code running on a CPU connected to the PCIe Host controller. I > think that in order to preserve the normal DMA operations semantics we > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > host CPU perspective, since that's the side the DMA controller is > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > to copy data from the host CPU memory into the remote device memory. > It means to allocate Rx/Read channel on the eDMA controller, so one > would be read data from the Local CPU memory and copied it to the PCIe > device SRAM. The logic of the DEV_TO_MEM direction would be just > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > from it's SRAM into the Host CPU memory. > > Please note as I understand the case 2) describes the Synopsys PCIe > EndPoint IP prototype kit, which is based on some FPGA code. It's just > a test setup with no real application, while the case 1) is a real setup > available on our SoC and I guess on yours. > > So what I suggest in the framework of this patch is just to implement > the case 1) only. While the case 2) as it's an artificial one can be > manually handled by the DMA client drivers. BTW There aren't ones available > in the kernel anyway. The only exception is an old-time attempt to get > an eDMA IP test-driver mainlined into the kernel: > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > But it was long time ago. So it's unlikely to be accepted at all. > > What do you think? > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the access to it happens over PCIe bus or by the local CPU. The commit from Alan Mikhak is what I took as a reference since the patch was already merged: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 Thanks, Mani > -Sergey > > > + * > > + ****************************************************************/ > > + > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > + read = true; > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > redundant. > > > + > > + /* Program the source and destination addresses for DMA read/write */ > > + if (read) { > > burst->sar = src_addr; > > if (xfer->type == EDMA_XFER_CYCLIC) { > > burst->dar = xfer->xfer.cyclic.paddr; > > -- > > 2.24.0.rc1 > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-11 17:41 ` Manivannan Sadhasivam @ 2022-03-11 19:01 ` Serge Semin 2022-03-12 5:37 ` Manivannan Sadhasivam 0 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-11 19:01 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Fri, Mar 11, 2022 at 11:11:34PM +0530, Manivannan Sadhasivam wrote: > On Thu, Mar 10, 2022 at 07:31:23PM +0300, Serge Semin wrote: > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > programs the source and destination addresses for read and write. Since the > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > Cc: stable@vger.kernel.org > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > --- > > > No change between v1 to v4 > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > index 66dc650577919..507f08db1aad3 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > struct dw_edma_chunk *chunk; > > > struct dw_edma_burst *burst; > > > struct dw_edma_desc *desc; > > > + bool read = false; > > > u32 cnt = 0; > > > int i; > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > chunk->ll_region.sz += burst->sz; > > > desc->alloc_sz += burst->sz; > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > + /**************************************************************** > > > + * > > > > > + * Root Complex Endpoint > > > + * +-----------------------+ +----------------------+ > > > + * | | TX CH | | > > > + * | | | | > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > + * | | | | > > > + * | | | | > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > + * | | | | > > > + * | | RX CH | | > > > + * +-----------------------+ +----------------------+ > > > + * > > > + * If eDMA is controlled by the Root complex, TX channel > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > + * > > > + * If eDMA is controlled by the endpoint, RX channel > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > Either I have some wrong notion about this issue, or something wrong > > with the explanation above and with this fix below. > > > > From my understanding of the possible DW eDMA IP-core setups the > > scatch above and the text below it are incorrect. Here is the way the > > DW eDMA can be used: > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > CPU/Application Memory is the memory of the CPU attached to the > > host/EP controller, while the remote (link partner) memory is the PCIe > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > by the Rx/Read channels. > > > > I'm not aware or even not sure about the use of eDMA in the PCIe host. > If that's the case, how the endpoint can access it from remote perspective? > Do you have a usecase or an example where used or even documented? I am aware. I've got SoC with DW PCIe Host v4.60/v4.70 and eDMA enabled for each of them. I also poses several manuals of the DW PCIe Host and End-points of various versions. Both Host and End-points can have eDMA enabled. But it's possible to have the eDMA accessed via the PCIe wire only for the End-points and only if the IP-core is accordingly synthesized. Other than that the eDMA is configurable from the Local CPU only. > > > Note it's applicable for both Host and End-point case, when Linux is > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > end-point, then MEM_TO_DEV means copying data from the local CPU > > memory into the remote memory. In general the remote memory can be > > either some PCIe device on the bus or the Root Complex' CPU memory, > > each of which is some remote device anyway from the Local CPU > > perspective. > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > prototype kit. It is a normal PCIe peripheral device with eDMA > > embedded, which CPU/Application interface is connected to some > > embedded SRAM while remote (link partner) interface is directed > > towards the PCIe bus. At the same time the device is setup and handled > > by the code running on a CPU connected to the PCIe Host controller. I > > think that in order to preserve the normal DMA operations semantics we > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > host CPU perspective, since that's the side the DMA controller is > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > to copy data from the host CPU memory into the remote device memory. > > It means to allocate Rx/Read channel on the eDMA controller, so one > > would be read data from the Local CPU memory and copied it to the PCIe > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > from it's SRAM into the Host CPU memory. > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > a test setup with no real application, while the case 1) is a real setup > > available on our SoC and I guess on yours. > > > > So what I suggest in the framework of this patch is just to implement > > the case 1) only. While the case 2) as it's an artificial one can be > > manually handled by the DMA client drivers. BTW There aren't ones available > > in the kernel anyway. The only exception is an old-time attempt to get > > an eDMA IP test-driver mainlined into the kernel: > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > But it was long time ago. So it's unlikely to be accepted at all. > > > > What do you think? > > > > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the > access to it happens over PCIe bus or by the local CPU. Not fully correct. Root Ports can also have eDMA embedded. In that case the eDMA can be only accessible from the local CPU. At the same time the DW PCIe End-point case is the IP-core synthesize parameters specific. It's always possible to access the eDMA CSRs from local CPU, but a particular End-point BAR can be pre-synthesize to map either Port Logic, or eDMA or iATU CSRs. Thus a PCIe root port can perform a full End-point configuration. Anyway the case if the eDMA functionality being accessible over the PCIe wire doesn't really make much sense with no info regarding the application logic hidden behind the PCIe End-point interface since SAR/DAR LLP is supposed to be initialized with an address from the local (application) memory space. So AFAICS the main usecase of the controller is 1) - when eDMA is a part of the Root Port/End-point and only local CPU is supposed to have it accessed and configured. I can resend this patch with my fix to the problem. What do you think? -Sergey > > The commit from Alan Mikhak is what I took as a reference since the patch was > already merged: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > Thanks, > Mani > > > -Sergey > > > > > + * > > > + ****************************************************************/ > > > + > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > + read = true; > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > redundant. > > > > > + > > > + /* Program the source and destination addresses for DMA read/write */ > > > + if (read) { > > > burst->sar = src_addr; > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > burst->dar = xfer->xfer.cyclic.paddr; > > > -- > > > 2.24.0.rc1 > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-11 19:01 ` Serge Semin @ 2022-03-12 5:37 ` Manivannan Sadhasivam 2022-03-14 8:33 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Manivannan Sadhasivam @ 2022-03-12 5:37 UTC (permalink / raw) To: Serge Semin Cc: Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Fri, Mar 11, 2022 at 10:01:47PM +0300, Serge Semin wrote: > On Fri, Mar 11, 2022 at 11:11:34PM +0530, Manivannan Sadhasivam wrote: > > On Thu, Mar 10, 2022 at 07:31:23PM +0300, Serge Semin wrote: > > > On Wed, Mar 09, 2022 at 03:12:01PM -0600, Frank Li wrote: > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > When eDMA is controlled by the Endpoint (EP), the current logic incorrectly > > > > programs the source and destination addresses for read and write. Since the > > > > Root complex and Endpoint uses the opposite channels for read/write, fix the > > > > issue by finding out the read operation first and program the eDMA accordingly. > > > > > > > > Cc: stable@vger.kernel.org > > > > Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") > > > > Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > --- > > > > No change between v1 to v4 > > > > > > > > drivers/dma/dw-edma/dw-edma-core.c | 32 +++++++++++++++++++++++++++++- > > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > index 66dc650577919..507f08db1aad3 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > @@ -334,6 +334,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > struct dw_edma_chunk *chunk; > > > > struct dw_edma_burst *burst; > > > > struct dw_edma_desc *desc; > > > > + bool read = false; > > > > u32 cnt = 0; > > > > int i; > > > > > > > > @@ -424,7 +425,36 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > chunk->ll_region.sz += burst->sz; > > > > desc->alloc_sz += burst->sz; > > > > > > > > - if (chan->dir == EDMA_DIR_WRITE) { > > > > + /**************************************************************** > > > > + * > > > > > > > + * Root Complex Endpoint > > > > + * +-----------------------+ +----------------------+ > > > > + * | | TX CH | | > > > > + * | | | | > > > > + * | DEV_TO_MEM <-------------+ MEM_TO_DEV | > > > > + * | | | | > > > > + * | | | | > > > > + * | MEM_TO_DEV +-------------> DEV_TO_MEM | > > > > + * | | | | > > > > + * | | RX CH | | > > > > + * +-----------------------+ +----------------------+ > > > > + * > > > > + * If eDMA is controlled by the Root complex, TX channel > > > > + * (EDMA_DIR_WRITE) is used for memory read (DEV_TO_MEM) and RX > > > > + * channel (EDMA_DIR_READ) is used for memory write (MEM_TO_DEV). > > > > + * > > > > + * If eDMA is controlled by the endpoint, RX channel > > > > + * (EDMA_DIR_READ) is used for memory read (DEV_TO_MEM) and TX > > > > + * channel (EDMA_DIR_WRITE) is used for memory write (MEM_TO_DEV). > > > > > > Either I have some wrong notion about this issue, or something wrong > > > with the explanation above and with this fix below. > > > > > > From my understanding of the possible DW eDMA IP-core setups the > > > scatch above and the text below it are incorrect. Here is the way the > > > DW eDMA can be used: > > > 1) Embedded into the DW PCIe Host/EP controller. In this case > > > CPU/Application Memory is the memory of the CPU attached to the > > > host/EP controller, while the remote (link partner) memory is the PCIe > > > bus memory. In this case MEM_TO_DEV operation is supposed to be > > > performed by the Tx/Write channels, while the DEV_TO_MEM operation - > > > by the Rx/Read channels. > > > > > > > > I'm not aware or even not sure about the use of eDMA in the PCIe host. > > If that's the case, how the endpoint can access it from remote perspective? > > Do you have a usecase or an example where used or even documented? > > I am aware. I've got SoC with DW PCIe Host v4.60/v4.70 and eDMA > enabled for each of them. I also poses several manuals of the DW PCIe > Host and End-points of various versions. Both Host and End-points can > have eDMA enabled. But it's possible to have the eDMA accessed via the > PCIe wire only for the End-points and only if the IP-core is > accordingly synthesized. Other than that the eDMA is configurable from > the Local CPU only. > Interesting! > > > > > Note it's applicable for both Host and End-point case, when Linux is > > > running on the CPU-side of the eDMA controller. So if it's DW PCIe > > > end-point, then MEM_TO_DEV means copying data from the local CPU > > > memory into the remote memory. In general the remote memory can be > > > either some PCIe device on the bus or the Root Complex' CPU memory, > > > each of which is some remote device anyway from the Local CPU > > > perspective. > > > > > > 2) Embedded into the PCIe EP. This case is implemented in the > > > drivers/dma/dw-edma/dw-edma-pcie.c driver. AFAICS from the commits log > > > and from the driver code, that device is a Synopsys PCIe EndPoint IP > > > prototype kit. It is a normal PCIe peripheral device with eDMA > > > embedded, which CPU/Application interface is connected to some > > > embedded SRAM while remote (link partner) interface is directed > > > towards the PCIe bus. At the same time the device is setup and handled > > > by the code running on a CPU connected to the PCIe Host controller. I > > > think that in order to preserve the normal DMA operations semantics we > > > still need to consider the MEM_TO_DEV/DEV_TO_MEM operations from the > > > host CPU perspective, since that's the side the DMA controller is > > > supposed to be setup from. In this MEM_TO_DEV is supposed to be used > > > to copy data from the host CPU memory into the remote device memory. > > > It means to allocate Rx/Read channel on the eDMA controller, so one > > > would be read data from the Local CPU memory and copied it to the PCIe > > > device SRAM. The logic of the DEV_TO_MEM direction would be just > > > flipped. The eDMA PCIe device shall use Tx/Write channel to copy data > > > from it's SRAM into the Host CPU memory. > > > > > > Please note as I understand the case 2) describes the Synopsys PCIe > > > EndPoint IP prototype kit, which is based on some FPGA code. It's just > > > a test setup with no real application, while the case 1) is a real setup > > > available on our SoC and I guess on yours. > > > > > > So what I suggest in the framework of this patch is just to implement > > > the case 1) only. While the case 2) as it's an artificial one can be > > > manually handled by the DMA client drivers. BTW There aren't ones available > > > in the kernel anyway. The only exception is an old-time attempt to get > > > an eDMA IP test-driver mainlined into the kernel: > > > https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@synopsys.com/ > > > But it was long time ago. So it's unlikely to be accepted at all. > > > > > > What do you think? > > > > > > > > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the > > access to it happens over PCIe bus or by the local CPU. > > Not fully correct. Root Ports can also have eDMA embedded. In that > case the eDMA can be only accessible from the local CPU. At the same > time the DW PCIe End-point case is the IP-core synthesize parameters > specific. It's always possible to access the eDMA CSRs from local > CPU, but a particular End-point BAR can be pre-synthesize to map > either Port Logic, or eDMA or iATU CSRs. Thus a PCIe root port can > perform a full End-point configuration. Anyway the case if the eDMA > functionality being accessible over the PCIe wire doesn't really make > much sense with no info regarding the application logic hidden behind > the PCIe End-point interface since SAR/DAR LLP is supposed to be > initialized with an address from the local (application) memory space. > Thanks for the explanation, it clarifies my doubt. I got misleaded by the earlier commits... > So AFAICS the main usecase of the controller is 1) - when eDMA is a > part of the Root Port/End-point and only local CPU is supposed to have > it accessed and configured. > > I can resend this patch with my fix to the problem. What do you think? > Yes, please do. Thanks, Mani > -Sergey > > > > > The commit from Alan Mikhak is what I took as a reference since the patch was > > already merged: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > > > Thanks, > > Mani > > > > > -Sergey > > > > > > > + * > > > > + ****************************************************************/ > > > > + > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > + read = true; > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > redundant. > > > > > > > + > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > + if (read) { > > > > burst->sar = src_addr; > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > -- > > > > 2.24.0.rc1 > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-12 5:37 ` Manivannan Sadhasivam @ 2022-03-14 8:33 ` Serge Semin 2022-03-18 18:06 ` Manivannan Sadhasivam 0 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-14 8:33 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Sat, Mar 12, 2022 at 11:07:20AM +0530, Manivannan Sadhasivam wrote: > On Fri, Mar 11, 2022 at 10:01:47PM +0300, Serge Semin wrote: > > On Fri, Mar 11, 2022 at 11:11:34PM +0530, Manivannan Sadhasivam wrote: [nip] > > > > > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the > > > access to it happens over PCIe bus or by the local CPU. > > > > Not fully correct. Root Ports can also have eDMA embedded. In that > > case the eDMA can be only accessible from the local CPU. At the same > > time the DW PCIe End-point case is the IP-core synthesize parameters > > specific. It's always possible to access the eDMA CSRs from local > > CPU, but a particular End-point BAR can be pre-synthesize to map > > either Port Logic, or eDMA or iATU CSRs. Thus a PCIe root port can > > perform a full End-point configuration. Anyway the case if the eDMA > > functionality being accessible over the PCIe wire doesn't really make > > much sense with no info regarding the application logic hidden behind > > the PCIe End-point interface since SAR/DAR LLP is supposed to be > > initialized with an address from the local (application) memory space. > > > > Thanks for the explanation, it clarifies my doubt. I got misleaded by the > earlier commits... > > > So AFAICS the main usecase of the controller is 1) - when eDMA is a > > part of the Root Port/End-point and only local CPU is supposed to have > > it accessed and configured. > > > > I can resend this patch with my fix to the problem. What do you think? > > > > Yes, please do. Ok. I'll be AFK today, but will send my patches tomorrow. @Frank, Could you please hold on with respinning the series for a few days? I'll send out some of my patches then with a note which one of them could be picked up by you and merged into this series. -Sergey > > Thanks, > Mani > > > -Sergey > > > > > > > > The commit from Alan Mikhak is what I took as a reference since the patch was > > > already merged: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > > > > > Thanks, > > > Mani > > > > > > > -Sergey > > > > > > > > > + * > > > > > + ****************************************************************/ > > > > > + > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > + read = true; > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > redundant. > > > > > > > > > + > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > + if (read) { > > > > > burst->sar = src_addr; > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > -- > > > > > 2.24.0.rc1 > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-14 8:33 ` Serge Semin @ 2022-03-18 18:06 ` Manivannan Sadhasivam 2022-03-18 18:19 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Manivannan Sadhasivam @ 2022-03-18 18:06 UTC (permalink / raw) To: Serge Semin Cc: Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Mon, Mar 14, 2022 at 11:33:40AM +0300, Serge Semin wrote: > On Sat, Mar 12, 2022 at 11:07:20AM +0530, Manivannan Sadhasivam wrote: > > On Fri, Mar 11, 2022 at 10:01:47PM +0300, Serge Semin wrote: > > > On Fri, Mar 11, 2022 at 11:11:34PM +0530, Manivannan Sadhasivam wrote: > > [nip] > > > > > > > > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the > > > > access to it happens over PCIe bus or by the local CPU. > > > > > > Not fully correct. Root Ports can also have eDMA embedded. In that > > > case the eDMA can be only accessible from the local CPU. At the same > > > time the DW PCIe End-point case is the IP-core synthesize parameters > > > specific. It's always possible to access the eDMA CSRs from local > > > CPU, but a particular End-point BAR can be pre-synthesize to map > > > either Port Logic, or eDMA or iATU CSRs. Thus a PCIe root port can > > > perform a full End-point configuration. Anyway the case if the eDMA > > > functionality being accessible over the PCIe wire doesn't really make > > > much sense with no info regarding the application logic hidden behind > > > the PCIe End-point interface since SAR/DAR LLP is supposed to be > > > initialized with an address from the local (application) memory space. > > > > > > > Thanks for the explanation, it clarifies my doubt. I got misleaded by the > > earlier commits... > > > > > So AFAICS the main usecase of the controller is 1) - when eDMA is a > > > part of the Root Port/End-point and only local CPU is supposed to have > > > it accessed and configured. > > > > > > I can resend this patch with my fix to the problem. What do you think? > > > > > > > > Yes, please do. > > Ok. I'll be AFK today, but will send my patches tomorrow. @Frank, > Could you please hold on with respinning the series for a few days? > I'll send out some of my patches then with a note which one of them > could be picked up by you and merged into this series. > Any update on your patches? Btw, my colleage worked on merging the two dma devices used by the eDMA core for read & write channels into one. Initially I thought that was not needed as he did that for devicetree integration, but looking deeply I think that patch is necessary irrespective of DT. One standout problem is, we can't register debugfs directory under "dmaengine" properly because, both read and write dma devices share the same parent chip->dev. Thanks, Mani > -Sergey > > > > > Thanks, > > Mani > > > > > -Sergey > > > > > > > > > > > The commit from Alan Mikhak is what I took as a reference since the patch was > > > > already merged: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > > > > > > > Thanks, > > > > Mani > > > > > > > > > -Sergey > > > > > > > > > > > + * > > > > > > + ****************************************************************/ > > > > > > + > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > + read = true; > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > redundant. > > > > > > > > > > > + > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > + if (read) { > > > > > > burst->sar = src_addr; > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > -- > > > > > > 2.24.0.rc1 > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-18 18:06 ` Manivannan Sadhasivam @ 2022-03-18 18:19 ` Serge Semin 2022-03-20 23:16 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-18 18:19 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Fri, Mar 18, 2022 at 11:36:05PM +0530, Manivannan Sadhasivam wrote: > On Mon, Mar 14, 2022 at 11:33:40AM +0300, Serge Semin wrote: > > On Sat, Mar 12, 2022 at 11:07:20AM +0530, Manivannan Sadhasivam wrote: > > > On Fri, Mar 11, 2022 at 10:01:47PM +0300, Serge Semin wrote: > > > > On Fri, Mar 11, 2022 at 11:11:34PM +0530, Manivannan Sadhasivam wrote: > > > > [nip] > > > > > > > > > > > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the > > > > > access to it happens over PCIe bus or by the local CPU. > > > > > > > > Not fully correct. Root Ports can also have eDMA embedded. In that > > > > case the eDMA can be only accessible from the local CPU. At the same > > > > time the DW PCIe End-point case is the IP-core synthesize parameters > > > > specific. It's always possible to access the eDMA CSRs from local > > > > CPU, but a particular End-point BAR can be pre-synthesize to map > > > > either Port Logic, or eDMA or iATU CSRs. Thus a PCIe root port can > > > > perform a full End-point configuration. Anyway the case if the eDMA > > > > functionality being accessible over the PCIe wire doesn't really make > > > > much sense with no info regarding the application logic hidden behind > > > > the PCIe End-point interface since SAR/DAR LLP is supposed to be > > > > initialized with an address from the local (application) memory space. > > > > > > > > > > Thanks for the explanation, it clarifies my doubt. I got misleaded by the > > > earlier commits... > > > > > > > So AFAICS the main usecase of the controller is 1) - when eDMA is a > > > > part of the Root Port/End-point and only local CPU is supposed to have > > > > it accessed and configured. > > > > > > > > I can resend this patch with my fix to the problem. What do you think? > > > > > > > > > > > > Yes, please do. > > > > Ok. I'll be AFK today, but will send my patches tomorrow. @Frank, > > Could you please hold on with respinning the series for a few days? > > I'll send out some of my patches then with a note which one of them > > could be picked up by you and merged into this series. > > > > Any update on your patches? No worries. The patches are ready. But since Frank was on vacation I decided to rebase all of my work on top of his series. I'll finish it up shortly and send out my patchset till Monday for review. Then Frank will be able to pick up two patches from there so to close up his patchset (I'll give a note which one of them is of Frank' interes). My series will be able to be merged in after Frank's series is reviewed and accepted. > > Btw, my colleage worked on merging the two dma devices used by the eDMA core > for read & write channels into one. Initially I thought that was not needed as > he did that for devicetree integration, but looking deeply I think that patch is > necessary irrespective of DT. > > One standout problem is, we can't register debugfs directory under "dmaengine" > properly because, both read and write dma devices share the same parent > chip->dev. Right, my series fixes that and some other problems too. So please be patient for a few more days. -Sergey > > Thanks, > Mani > > > -Sergey > > > > > > > > Thanks, > > > Mani > > > > > > > -Sergey > > > > > > > > > > > > > > The commit from Alan Mikhak is what I took as a reference since the patch was > > > > > already merged: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > > > > > > > > > Thanks, > > > > > Mani > > > > > > > > > > > -Sergey > > > > > > > > > > > > > + * > > > > > > > + ****************************************************************/ > > > > > > > + > > > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > > + read = true; > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > > redundant. > > > > > > > > > > > > > + > > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > > + if (read) { > > > > > > > burst->sar = src_addr; > > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > > -- > > > > > > > 2.24.0.rc1 > > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-18 18:19 ` Serge Semin @ 2022-03-20 23:16 ` Serge Semin 2022-03-22 13:55 ` Zhi Li 0 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-20 23:16 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Fri, Mar 18, 2022 at 09:19:13PM +0300, Serge Semin wrote: > On Fri, Mar 18, 2022 at 11:36:05PM +0530, Manivannan Sadhasivam wrote: > > On Mon, Mar 14, 2022 at 11:33:40AM +0300, Serge Semin wrote: > > > On Sat, Mar 12, 2022 at 11:07:20AM +0530, Manivannan Sadhasivam wrote: > > > > On Fri, Mar 11, 2022 at 10:01:47PM +0300, Serge Semin wrote: > > > > > On Fri, Mar 11, 2022 at 11:11:34PM +0530, Manivannan Sadhasivam wrote: > > > > > > [nip] > > > > > > > > > > > > > > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the > > > > > > access to it happens over PCIe bus or by the local CPU. > > > > > > > > > > Not fully correct. Root Ports can also have eDMA embedded. In that > > > > > case the eDMA can be only accessible from the local CPU. At the same > > > > > time the DW PCIe End-point case is the IP-core synthesize parameters > > > > > specific. It's always possible to access the eDMA CSRs from local > > > > > CPU, but a particular End-point BAR can be pre-synthesize to map > > > > > either Port Logic, or eDMA or iATU CSRs. Thus a PCIe root port can > > > > > perform a full End-point configuration. Anyway the case if the eDMA > > > > > functionality being accessible over the PCIe wire doesn't really make > > > > > much sense with no info regarding the application logic hidden behind > > > > > the PCIe End-point interface since SAR/DAR LLP is supposed to be > > > > > initialized with an address from the local (application) memory space. > > > > > > > > > > > > > Thanks for the explanation, it clarifies my doubt. I got misleaded by the > > > > earlier commits... > > > > > > > > > So AFAICS the main usecase of the controller is 1) - when eDMA is a > > > > > part of the Root Port/End-point and only local CPU is supposed to have > > > > > it accessed and configured. > > > > > > > > > > I can resend this patch with my fix to the problem. What do you think? > > > > > > > > > > > > > > > > Yes, please do. > > > > > > Ok. I'll be AFK today, but will send my patches tomorrow. @Frank, > > > Could you please hold on with respinning the series for a few days? > > > I'll send out some of my patches then with a note which one of them > > > could be picked up by you and merged into this series. > > > > > > > > Any update on your patches? > > No worries. The patches are ready. But since Frank was on vacation I > decided to rebase all of my work on top of his series. I'll finish it > up shortly and send out my patchset till Monday for review. Then Frank > will be able to pick up two patches from there so to close up his > patchset (I'll give a note which one of them is of Frank' interes). > My series will be able to be merged in after Frank's series is reviewed > and accepted. Folks, couldn't make it this weekend. Too much sidework to do. Terribly sorry about that. Will send out the series tomorrow or at most in a day after tomorrow. Sorry for the inconvenience. -Sergey > > > > > Btw, my colleage worked on merging the two dma devices used by the eDMA core > > for read & write channels into one. Initially I thought that was not needed as > > he did that for devicetree integration, but looking deeply I think that patch is > > necessary irrespective of DT. > > > > One standout problem is, we can't register debugfs directory under "dmaengine" > > properly because, both read and write dma devices share the same parent > > chip->dev. > > Right, my series fixes that and some other problems too. So please be > patient for a few more days. > > -Sergey > > > > > Thanks, > > Mani > > > > > -Sergey > > > > > > > > > > > Thanks, > > > > Mani > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > The commit from Alan Mikhak is what I took as a reference since the patch was > > > > > > already merged: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > > > > > > > > > > > Thanks, > > > > > > Mani > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > + * > > > > > > > > + ****************************************************************/ > > > > > > > > + > > > > > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > > > + read = true; > > > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > > > redundant. > > > > > > > > > > > > > > > + > > > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > > > + if (read) { > > > > > > > > burst->sar = src_addr; > > > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > > > -- > > > > > > > > 2.24.0.rc1 > > > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-20 23:16 ` Serge Semin @ 2022-03-22 13:55 ` Zhi Li 2022-03-22 14:03 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-22 13:55 UTC (permalink / raw) To: Serge Semin Cc: Manivannan Sadhasivam, Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo On Sun, Mar 20, 2022 at 6:16 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > On Fri, Mar 18, 2022 at 09:19:13PM +0300, Serge Semin wrote: > > On Fri, Mar 18, 2022 at 11:36:05PM +0530, Manivannan Sadhasivam wrote: > > > On Mon, Mar 14, 2022 at 11:33:40AM +0300, Serge Semin wrote: > > > > On Sat, Mar 12, 2022 at 11:07:20AM +0530, Manivannan Sadhasivam wrote: > > > > > On Fri, Mar 11, 2022 at 10:01:47PM +0300, Serge Semin wrote: > > > > > > On Fri, Mar 11, 2022 at 11:11:34PM +0530, Manivannan Sadhasivam wrote: > > > > > > > > [nip] > > > > > > > > > > > > > > > > > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the > > > > > > > access to it happens over PCIe bus or by the local CPU. > > > > > > > > > > > > Not fully correct. Root Ports can also have eDMA embedded. In that > > > > > > case the eDMA can be only accessible from the local CPU. At the same > > > > > > time the DW PCIe End-point case is the IP-core synthesize parameters > > > > > > specific. It's always possible to access the eDMA CSRs from local > > > > > > CPU, but a particular End-point BAR can be pre-synthesize to map > > > > > > either Port Logic, or eDMA or iATU CSRs. Thus a PCIe root port can > > > > > > perform a full End-point configuration. Anyway the case if the eDMA > > > > > > functionality being accessible over the PCIe wire doesn't really make > > > > > > much sense with no info regarding the application logic hidden behind > > > > > > the PCIe End-point interface since SAR/DAR LLP is supposed to be > > > > > > initialized with an address from the local (application) memory space. > > > > > > > > > > > > > > > > Thanks for the explanation, it clarifies my doubt. I got misleaded by the > > > > > earlier commits... > > > > > > > > > > > So AFAICS the main usecase of the controller is 1) - when eDMA is a > > > > > > part of the Root Port/End-point and only local CPU is supposed to have > > > > > > it accessed and configured. > > > > > > > > > > > > I can resend this patch with my fix to the problem. What do you think? > > > > > > > > > > > > > > > > > > > > Yes, please do. > > > > > > > > Ok. I'll be AFK today, but will send my patches tomorrow. @Frank, > > > > Could you please hold on with respinning the series for a few days? > > > > I'll send out some of my patches then with a note which one of them > > > > could be picked up by you and merged into this series. > > > > > > > > > > > > > Any update on your patches? > > > > No worries. The patches are ready. But since Frank was on vacation I > > decided to rebase all of my work on top of his series. I'll finish it > > up shortly and send out my patchset till Monday for review. Then Frank > > will be able to pick up two patches from there so to close up his > > patchset (I'll give a note which one of them is of Frank' interes). > > My series will be able to be merged in after Frank's series is reviewed > > and accepted. > > Folks, couldn't make it this weekend. Too much sidework to do. Terribly > sorry about that. Will send out the series tomorrow or at most in a day > after tomorrow. Sorry for the inconvenience. Any update on your patches? best regards Frank Li > > -Sergey > > > > > > > > > Btw, my colleage worked on merging the two dma devices used by the eDMA core > > > for read & write channels into one. Initially I thought that was not needed as > > > he did that for devicetree integration, but looking deeply I think that patch is > > > necessary irrespective of DT. > > > > > > One standout problem is, we can't register debugfs directory under "dmaengine" > > > properly because, both read and write dma devices share the same parent > > > chip->dev. > > > > Right, my series fixes that and some other problems too. So please be > > patient for a few more days. > > > > -Sergey > > > > > > > > Thanks, > > > Mani > > > > > > > -Sergey > > > > > > > > > > > > > > Thanks, > > > > > Mani > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > > > > The commit from Alan Mikhak is what I took as a reference since the patch was > > > > > > > already merged: > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > > > > > > > > > > > > > Thanks, > > > > > > > Mani > > > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > + * > > > > > > > > > + ****************************************************************/ > > > > > > > > > + > > > > > > > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > > > > + read = true; > > > > > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > > > > redundant. > > > > > > > > > > > > > > > > > + > > > > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > > > > + if (read) { > > > > > > > > > burst->sar = src_addr; > > > > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > > > > -- > > > > > > > > > 2.24.0.rc1 > > > > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-22 13:55 ` Zhi Li @ 2022-03-22 14:03 ` Serge Semin 2022-03-22 22:25 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-22 14:03 UTC (permalink / raw) To: Zhi Li Cc: Serge Semin, Manivannan Sadhasivam, Frank Li, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo On Tue, Mar 22, 2022 at 08:55:49AM -0500, Zhi Li wrote: > On Sun, Mar 20, 2022 at 6:16 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > On Fri, Mar 18, 2022 at 09:19:13PM +0300, Serge Semin wrote: > > > On Fri, Mar 18, 2022 at 11:36:05PM +0530, Manivannan Sadhasivam wrote: > > > > On Mon, Mar 14, 2022 at 11:33:40AM +0300, Serge Semin wrote: > > > > > On Sat, Mar 12, 2022 at 11:07:20AM +0530, Manivannan Sadhasivam wrote: > > > > > > On Fri, Mar 11, 2022 at 10:01:47PM +0300, Serge Semin wrote: > > > > > > > On Fri, Mar 11, 2022 at 11:11:34PM +0530, Manivannan Sadhasivam wrote: > > > > > > > > > > [nip] > > > > > > > > > > > > > > > > > > > > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the > > > > > > > > access to it happens over PCIe bus or by the local CPU. > > > > > > > > > > > > > > Not fully correct. Root Ports can also have eDMA embedded. In that > > > > > > > case the eDMA can be only accessible from the local CPU. At the same > > > > > > > time the DW PCIe End-point case is the IP-core synthesize parameters > > > > > > > specific. It's always possible to access the eDMA CSRs from local > > > > > > > CPU, but a particular End-point BAR can be pre-synthesize to map > > > > > > > either Port Logic, or eDMA or iATU CSRs. Thus a PCIe root port can > > > > > > > perform a full End-point configuration. Anyway the case if the eDMA > > > > > > > functionality being accessible over the PCIe wire doesn't really make > > > > > > > much sense with no info regarding the application logic hidden behind > > > > > > > the PCIe End-point interface since SAR/DAR LLP is supposed to be > > > > > > > initialized with an address from the local (application) memory space. > > > > > > > > > > > > > > > > > > > Thanks for the explanation, it clarifies my doubt. I got misleaded by the > > > > > > earlier commits... > > > > > > > > > > > > > So AFAICS the main usecase of the controller is 1) - when eDMA is a > > > > > > > part of the Root Port/End-point and only local CPU is supposed to have > > > > > > > it accessed and configured. > > > > > > > > > > > > > > I can resend this patch with my fix to the problem. What do you think? > > > > > > > > > > > > > > > > > > > > > > > > Yes, please do. > > > > > > > > > > Ok. I'll be AFK today, but will send my patches tomorrow. @Frank, > > > > > Could you please hold on with respinning the series for a few days? > > > > > I'll send out some of my patches then with a note which one of them > > > > > could be picked up by you and merged into this series. > > > > > > > > > > > > > > > > > > Any update on your patches? > > > > > > No worries. The patches are ready. But since Frank was on vacation I > > > decided to rebase all of my work on top of his series. I'll finish it > > > up shortly and send out my patchset till Monday for review. Then Frank > > > will be able to pick up two patches from there so to close up his > > > patchset (I'll give a note which one of them is of Frank' interes). > > > My series will be able to be merged in after Frank's series is reviewed > > > and accepted. > > > > Folks, couldn't make it this weekend. Too much sidework to do. Terribly > > sorry about that. Will send out the series tomorrow or at most in a day > > after tomorrow. Sorry for the inconvenience. > > Any update on your patches? The patches are ready. Writing cover-letters and sending them out this night. Sorry for the delay. -Sergey > > best regards > Frank Li > > > > > -Sergey > > > > > > > > > > > > > Btw, my colleage worked on merging the two dma devices used by the eDMA core > > > > for read & write channels into one. Initially I thought that was not needed as > > > > he did that for devicetree integration, but looking deeply I think that patch is > > > > necessary irrespective of DT. > > > > > > > > One standout problem is, we can't register debugfs directory under "dmaengine" > > > > properly because, both read and write dma devices share the same parent > > > > chip->dev. > > > > > > Right, my series fixes that and some other problems too. So please be > > > patient for a few more days. > > > > > > -Sergey > > > > > > > > > > > Thanks, > > > > Mani > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > Thanks, > > > > > > Mani > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > > > > > > > The commit from Alan Mikhak is what I took as a reference since the patch was > > > > > > > > already merged: > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Mani > > > > > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > > > + * > > > > > > > > > > + ****************************************************************/ > > > > > > > > > > + > > > > > > > > > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > > > > > + read = true; > > > > > > > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > > > > > redundant. > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > > > > > + if (read) { > > > > > > > > > > burst->sar = src_addr; > > > > > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > > > > > -- > > > > > > > > > > 2.24.0.rc1 > > > > > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep 2022-03-22 14:03 ` Serge Semin @ 2022-03-22 22:25 ` Serge Semin 0 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-22 22:25 UTC (permalink / raw) To: Zhi Li Cc: Serge Semin, Manivannan Sadhasivam, Frank Li, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo On Tue, Mar 22, 2022 at 05:03:13PM +0300, Serge Semin wrote: > On Tue, Mar 22, 2022 at 08:55:49AM -0500, Zhi Li wrote: > > On Sun, Mar 20, 2022 at 6:16 PM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > > On Fri, Mar 18, 2022 at 09:19:13PM +0300, Serge Semin wrote: > > > > On Fri, Mar 18, 2022 at 11:36:05PM +0530, Manivannan Sadhasivam wrote: > > > > > On Mon, Mar 14, 2022 at 11:33:40AM +0300, Serge Semin wrote: > > > > > > On Sat, Mar 12, 2022 at 11:07:20AM +0530, Manivannan Sadhasivam wrote: > > > > > > > On Fri, Mar 11, 2022 at 10:01:47PM +0300, Serge Semin wrote: > > > > > > > > On Fri, Mar 11, 2022 at 11:11:34PM +0530, Manivannan Sadhasivam wrote: > > > > > > > > > > > > [nip] > > > > > > > > > > > > > > > > > > > > > > > As per my understanding, the eDMA is solely used in the PCIe endpoint. And the > > > > > > > > > access to it happens over PCIe bus or by the local CPU. > > > > > > > > > > > > > > > > Not fully correct. Root Ports can also have eDMA embedded. In that > > > > > > > > case the eDMA can be only accessible from the local CPU. At the same > > > > > > > > time the DW PCIe End-point case is the IP-core synthesize parameters > > > > > > > > specific. It's always possible to access the eDMA CSRs from local > > > > > > > > CPU, but a particular End-point BAR can be pre-synthesize to map > > > > > > > > either Port Logic, or eDMA or iATU CSRs. Thus a PCIe root port can > > > > > > > > perform a full End-point configuration. Anyway the case if the eDMA > > > > > > > > functionality being accessible over the PCIe wire doesn't really make > > > > > > > > much sense with no info regarding the application logic hidden behind > > > > > > > > the PCIe End-point interface since SAR/DAR LLP is supposed to be > > > > > > > > initialized with an address from the local (application) memory space. > > > > > > > > > > > > > > > > > > > > > > Thanks for the explanation, it clarifies my doubt. I got misleaded by the > > > > > > > earlier commits... > > > > > > > > > > > > > > > So AFAICS the main usecase of the controller is 1) - when eDMA is a > > > > > > > > part of the Root Port/End-point and only local CPU is supposed to have > > > > > > > > it accessed and configured. > > > > > > > > > > > > > > > > I can resend this patch with my fix to the problem. What do you think? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, please do. > > > > > > > > > > > > Ok. I'll be AFK today, but will send my patches tomorrow. @Frank, > > > > > > Could you please hold on with respinning the series for a few days? > > > > > > I'll send out some of my patches then with a note which one of them > > > > > > could be picked up by you and merged into this series. > > > > > > > > > > > > > > > > > > > > > > > Any update on your patches? > > > > > > > > No worries. The patches are ready. But since Frank was on vacation I > > > > decided to rebase all of my work on top of his series. I'll finish it > > > > up shortly and send out my patchset till Monday for review. Then Frank > > > > will be able to pick up two patches from there so to close up his > > > > patchset (I'll give a note which one of them is of Frank' interes). > > > > My series will be able to be merged in after Frank's series is reviewed > > > > and accepted. > > > > > > Folks, couldn't make it this weekend. Too much sidework to do. Terribly > > > sorry about that. Will send out the series tomorrow or at most in a day > > > after tomorrow. Sorry for the inconvenience. > > > > > Any update on your patches? > > The patches are ready. Writing cover-letters and sending them out this > night. Sorry for the delay. Ah, couldn't finish the letters this night. Will send it tomorrow at midday. Sorry one more time. -Sergey > > -Sergey > > > > > best regards > > Frank Li > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > Btw, my colleage worked on merging the two dma devices used by the eDMA core > > > > > for read & write channels into one. Initially I thought that was not needed as > > > > > he did that for devicetree integration, but looking deeply I think that patch is > > > > > necessary irrespective of DT. > > > > > > > > > > One standout problem is, we can't register debugfs directory under "dmaengine" > > > > > properly because, both read and write dma devices share the same parent > > > > > chip->dev. > > > > > > > > Right, my series fixes that and some other problems too. So please be > > > > patient for a few more days. > > > > > > > > -Sergey > > > > > > > > > > > > > > Thanks, > > > > > Mani > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Mani > > > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > > > > > > > > > > The commit from Alan Mikhak is what I took as a reference since the patch was > > > > > > > > > already merged: > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/dw-edma?id=bd96f1b2f43a39310cc576bb4faf2ea24317a4c9 > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Mani > > > > > > > > > > > > > > > > > > > -Sergey > > > > > > > > > > > > > > > > > > > > > + * > > > > > > > > > > > + ****************************************************************/ > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > > > > + if ((dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) || > > > > > > > > > > > + (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE)) > > > > > > > > > > > + read = true; > > > > > > > > > > > > > > > > > > > > Seeing the driver support only two directions DMA_DEV_TO_MEM/DMA_DEV_TO_MEM > > > > > > > > > > and EDMA_DIR_READ/EDMA_DIR_WRITE, this conditional statement seems > > > > > > > > > > redundant. > > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > + /* Program the source and destination addresses for DMA read/write */ > > > > > > > > > > > + if (read) { > > > > > > > > > > > burst->sar = src_addr; > > > > > > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > > > > > > > > burst->dar = xfer->xfer.cyclic.paddr; > > > > > > > > > > > -- > > > > > > > > > > > 2.24.0.rc1 > > > > > > > > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v4 6/8] dmaengine: dw-edma: Don't rely on the deprecated "direction" member 2022-03-09 21:11 [PATCH v4 0/8] Enable designware PCI EP EDMA locally Frank Li ` (4 preceding siblings ...) 2022-03-09 21:12 ` [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep Frank Li @ 2022-03-09 21:12 ` Frank Li 2022-03-10 17:29 ` Serge Semin 2022-03-09 21:12 ` [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip Frank Li 2022-03-09 21:12 ` [PATCH v4 8/8] PCI: endpoint: functions/pci-epf-test: Support PCI controller DMA Frank Li 7 siblings, 1 reply; 52+ messages in thread From: Frank Li @ 2022-03-09 21:12 UTC (permalink / raw) To: gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> The "direction" member of the "dma_slave_config" structure is deprecated. The clients no longer use this field to specify the direction of the slave channel. But in the eDMA core, this field is used to differentiate between the Root complex (remote) and Endpoint (local) DMA accesses. Nevertheless, we can't differentiate between local and remote accesses without a dedicated flag. So let's get rid of the old check and add a new check for verifying the DMA operation between local and remote memory instead. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> --- no chang between v1 to v4 drivers/dma/dw-edma/dw-edma-core.c | 17 ++--------------- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c index 507f08db1aad3..47c6a52929fcd 100644 --- a/drivers/dma/dw-edma/dw-edma-core.c +++ b/drivers/dma/dw-edma/dw-edma-core.c @@ -341,22 +341,9 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) if (!chan->configured) return NULL; - switch (chan->config.direction) { - case DMA_DEV_TO_MEM: /* local DMA */ - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) - break; - return NULL; - case DMA_MEM_TO_DEV: /* local DMA */ - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_WRITE) - break; + /* eDMA supports only read and write between local and remote memory */ + if (dir != DMA_DEV_TO_MEM && dir != DMA_MEM_TO_DEV) return NULL; - default: /* remote DMA */ - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_READ) - break; - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE) - break; - return NULL; - } if (xfer->type == EDMA_XFER_CYCLIC) { if (!xfer->xfer.cyclic.len || !xfer->xfer.cyclic.cnt) -- 2.24.0.rc1 ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v4 6/8] dmaengine: dw-edma: Don't rely on the deprecated "direction" member 2022-03-09 21:12 ` [PATCH v4 6/8] dmaengine: dw-edma: Don't rely on the deprecated "direction" member Frank Li @ 2022-03-10 17:29 ` Serge Semin 2022-03-10 17:41 ` Manivannan Sadhasivam 0 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-10 17:29 UTC (permalink / raw) To: Frank Li Cc: Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam On Wed, Mar 09, 2022 at 03:12:02PM -0600, Frank Li wrote: > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > The "direction" member of the "dma_slave_config" structure is deprecated. > The clients no longer use this field to specify the direction of the slave > channel. But in the eDMA core, this field is used to differentiate between the > Root complex (remote) and Endpoint (local) DMA accesses. > > Nevertheless, we can't differentiate between local and remote accesses without > a dedicated flag. So let's get rid of the old check and add a new check for > verifying the DMA operation between local and remote memory instead. > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > no chang between v1 to v4 > drivers/dma/dw-edma/dw-edma-core.c | 17 ++--------------- > 1 file changed, 2 insertions(+), 15 deletions(-) > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > index 507f08db1aad3..47c6a52929fcd 100644 > --- a/drivers/dma/dw-edma/dw-edma-core.c > +++ b/drivers/dma/dw-edma/dw-edma-core.c > @@ -341,22 +341,9 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > if (!chan->configured) > return NULL; > > - switch (chan->config.direction) { > - case DMA_DEV_TO_MEM: /* local DMA */ > - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) > - break; > - return NULL; > - case DMA_MEM_TO_DEV: /* local DMA */ > - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_WRITE) > - break; > + /* eDMA supports only read and write between local and remote memory */ The comment is a bit confusing because both cases are named as "memory" while the permitted directions contains DEV-part, which means "device". What I would suggest to write here is something like: "DW eDMA supports transferring data from/to the CPU/Application memory to/from the PCIe link partner device by injecting the PCIe MWr/MRd TLPs." -Sergey > + if (dir != DMA_DEV_TO_MEM && dir != DMA_MEM_TO_DEV) > return NULL; > - default: /* remote DMA */ > - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_READ) > - break; > - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE) > - break; > - return NULL; > - } > > if (xfer->type == EDMA_XFER_CYCLIC) { > if (!xfer->xfer.cyclic.len || !xfer->xfer.cyclic.cnt) > -- > 2.24.0.rc1 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 6/8] dmaengine: dw-edma: Don't rely on the deprecated "direction" member 2022-03-10 17:29 ` Serge Semin @ 2022-03-10 17:41 ` Manivannan Sadhasivam 2022-03-10 17:52 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Manivannan Sadhasivam @ 2022-03-10 17:41 UTC (permalink / raw) To: Serge Semin Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Thu, Mar 10, 2022 at 08:29:30PM +0300, Serge Semin wrote: > On Wed, Mar 09, 2022 at 03:12:02PM -0600, Frank Li wrote: > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > The "direction" member of the "dma_slave_config" structure is deprecated. > > The clients no longer use this field to specify the direction of the slave > > channel. But in the eDMA core, this field is used to differentiate between the > > Root complex (remote) and Endpoint (local) DMA accesses. > > > > Nevertheless, we can't differentiate between local and remote accesses without > > a dedicated flag. So let's get rid of the old check and add a new check for > > verifying the DMA operation between local and remote memory instead. > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > --- > > no chang between v1 to v4 > > drivers/dma/dw-edma/dw-edma-core.c | 17 ++--------------- > > 1 file changed, 2 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > index 507f08db1aad3..47c6a52929fcd 100644 > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > @@ -341,22 +341,9 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > if (!chan->configured) > > return NULL; > > > > - switch (chan->config.direction) { > > - case DMA_DEV_TO_MEM: /* local DMA */ > > - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) > > - break; > > - return NULL; > > - case DMA_MEM_TO_DEV: /* local DMA */ > > - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_WRITE) > > - break; > > > + /* eDMA supports only read and write between local and remote memory */ > > The comment is a bit confusing because both cases are named as > "memory" while the permitted directions contains DEV-part, which > means "device". What I would suggest to write here is something like: > "DW eDMA supports transferring data from/to the CPU/Application memory > to/from the PCIe link partner device by injecting the PCIe MWr/MRd TLPs." > End of the day, you'd be transferring data between remote and local memory only and the terms (local and remote) are also used in the databook. So I think the comment is fine. Thanks, Mani > -Sergey > > > + if (dir != DMA_DEV_TO_MEM && dir != DMA_MEM_TO_DEV) > > return NULL; > > - default: /* remote DMA */ > > - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_READ) > > - break; > > - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE) > > - break; > > - return NULL; > > - } > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > if (!xfer->xfer.cyclic.len || !xfer->xfer.cyclic.cnt) > > -- > > 2.24.0.rc1 > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 6/8] dmaengine: dw-edma: Don't rely on the deprecated "direction" member 2022-03-10 17:41 ` Manivannan Sadhasivam @ 2022-03-10 17:52 ` Serge Semin 2022-03-11 17:58 ` Manivannan Sadhasivam 0 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-10 17:52 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Thu, Mar 10, 2022 at 11:11:59PM +0530, Manivannan Sadhasivam wrote: > On Thu, Mar 10, 2022 at 08:29:30PM +0300, Serge Semin wrote: > > On Wed, Mar 09, 2022 at 03:12:02PM -0600, Frank Li wrote: > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > The "direction" member of the "dma_slave_config" structure is deprecated. > > > The clients no longer use this field to specify the direction of the slave > > > channel. But in the eDMA core, this field is used to differentiate between the > > > Root complex (remote) and Endpoint (local) DMA accesses. > > > > > > Nevertheless, we can't differentiate between local and remote accesses without > > > a dedicated flag. So let's get rid of the old check and add a new check for > > > verifying the DMA operation between local and remote memory instead. > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > --- > > > no chang between v1 to v4 > > > drivers/dma/dw-edma/dw-edma-core.c | 17 ++--------------- > > > 1 file changed, 2 insertions(+), 15 deletions(-) > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > index 507f08db1aad3..47c6a52929fcd 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > @@ -341,22 +341,9 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > if (!chan->configured) > > > return NULL; > > > > > > - switch (chan->config.direction) { > > > - case DMA_DEV_TO_MEM: /* local DMA */ > > > - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) > > > - break; > > > - return NULL; > > > - case DMA_MEM_TO_DEV: /* local DMA */ > > > - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_WRITE) > > > - break; > > > > > + /* eDMA supports only read and write between local and remote memory */ > > > > The comment is a bit confusing because both cases are named as > > "memory" while the permitted directions contains DEV-part, which > > means "device". What I would suggest to write here is something like: > > "DW eDMA supports transferring data from/to the CPU/Application memory > > to/from the PCIe link partner device by injecting the PCIe MWr/MRd TLPs." > > > > End of the day, you'd be transferring data between remote and local memory > only and the terms (local and remote) are also used in the databook. So I think > the comment is fine. Yes, but the databook either adds a note regarding what memory it is or it can be inferred from the text context. So at least it would be appropriate to preserve the notes here two: "eDMA supports only read and write between local (CPU/application) and remote (PCIe/link partner) memory." Otherwise it's hard to understand what memory the comment states about. -Sergey > > Thanks, > Mani > > > -Sergey > > > > > + if (dir != DMA_DEV_TO_MEM && dir != DMA_MEM_TO_DEV) > > > return NULL; > > > - default: /* remote DMA */ > > > - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_READ) > > > - break; > > > - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE) > > > - break; > > > - return NULL; > > > - } > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > if (!xfer->xfer.cyclic.len || !xfer->xfer.cyclic.cnt) > > > -- > > > 2.24.0.rc1 > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 6/8] dmaengine: dw-edma: Don't rely on the deprecated "direction" member 2022-03-10 17:52 ` Serge Semin @ 2022-03-11 17:58 ` Manivannan Sadhasivam 0 siblings, 0 replies; 52+ messages in thread From: Manivannan Sadhasivam @ 2022-03-11 17:58 UTC (permalink / raw) To: Serge Semin Cc: Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo On Thu, Mar 10, 2022 at 08:52:25PM +0300, Serge Semin wrote: > On Thu, Mar 10, 2022 at 11:11:59PM +0530, Manivannan Sadhasivam wrote: > > On Thu, Mar 10, 2022 at 08:29:30PM +0300, Serge Semin wrote: > > > On Wed, Mar 09, 2022 at 03:12:02PM -0600, Frank Li wrote: > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > > > > > The "direction" member of the "dma_slave_config" structure is deprecated. > > > > The clients no longer use this field to specify the direction of the slave > > > > channel. But in the eDMA core, this field is used to differentiate between the > > > > Root complex (remote) and Endpoint (local) DMA accesses. > > > > > > > > Nevertheless, we can't differentiate between local and remote accesses without > > > > a dedicated flag. So let's get rid of the old check and add a new check for > > > > verifying the DMA operation between local and remote memory instead. > > > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > > --- > > > > no chang between v1 to v4 > > > > drivers/dma/dw-edma/dw-edma-core.c | 17 ++--------------- > > > > 1 file changed, 2 insertions(+), 15 deletions(-) > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c > > > > index 507f08db1aad3..47c6a52929fcd 100644 > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c > > > > @@ -341,22 +341,9 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) > > > > if (!chan->configured) > > > > return NULL; > > > > > > > > - switch (chan->config.direction) { > > > > - case DMA_DEV_TO_MEM: /* local DMA */ > > > > - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ) > > > > - break; > > > > - return NULL; > > > > - case DMA_MEM_TO_DEV: /* local DMA */ > > > > - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_WRITE) > > > > - break; > > > > > > > + /* eDMA supports only read and write between local and remote memory */ > > > > > > The comment is a bit confusing because both cases are named as > > > "memory" while the permitted directions contains DEV-part, which > > > means "device". What I would suggest to write here is something like: > > > "DW eDMA supports transferring data from/to the CPU/Application memory > > > to/from the PCIe link partner device by injecting the PCIe MWr/MRd TLPs." > > > > > > > > End of the day, you'd be transferring data between remote and local memory > > only and the terms (local and remote) are also used in the databook. So I think > > the comment is fine. > > Yes, but the databook either adds a note regarding what memory it is > or it can be inferred from the text context. So at least it would be > appropriate to preserve the notes here two: > "eDMA supports only read and write between local (CPU/application) and > remote (PCIe/link partner) memory." Otherwise it's hard to understand > what memory the comment states about. > Okay, I'm fine with this. "eDMA supports only read and write between local (CPU/application) and remote (PCIe/link partner) memory." Thanks, Mani > -Sergey > > > > > Thanks, > > Mani > > > > > -Sergey > > > > > > > + if (dir != DMA_DEV_TO_MEM && dir != DMA_MEM_TO_DEV) > > > > return NULL; > > > > - default: /* remote DMA */ > > > > - if (dir == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_READ) > > > > - break; > > > > - if (dir == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_WRITE) > > > > - break; > > > > - return NULL; > > > > - } > > > > > > > > if (xfer->type == EDMA_XFER_CYCLIC) { > > > > if (!xfer->xfer.cyclic.len || !xfer->xfer.cyclic.cnt) > > > > -- > > > > 2.24.0.rc1 > > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip 2022-03-09 21:11 [PATCH v4 0/8] Enable designware PCI EP EDMA locally Frank Li ` (5 preceding siblings ...) 2022-03-09 21:12 ` [PATCH v4 6/8] dmaengine: dw-edma: Don't rely on the deprecated "direction" member Frank Li @ 2022-03-09 21:12 ` Frank Li 2022-03-10 1:07 ` kernel test robot ` (2 more replies) 2022-03-09 21:12 ` [PATCH v4 8/8] PCI: endpoint: functions/pci-epf-test: Support PCI controller DMA Frank Li 7 siblings, 3 replies; 52+ messages in thread From: Frank Li @ 2022-03-09 21:12 UTC (permalink / raw) To: gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam Allow PCI EP probe DMA locally and prevent use of remote MSI to remote PCI host. Add option to force 32bit DBI register access even on 64-bit systems. i.MX8 hardware only allowed 32bit register access. Signed-off-by: Frank Li <Frank.Li@nxp.com> --- Change from v3 to v4 - None Change from v2 to v3 - rework commit message - Change to DW_EDMA_CHIP_32BIT_DBI - using DW_EDMA_CHIP_LOCAL control msi - Apply Bjorn's comments, if (!j) { control |= DW_EDMA_V0_LIE; if (!(chan->chip->flags & DW_EDMA_CHIP_LOCAL)) control |= DW_EDMA_V0_RIE; } if ((chan->chip->flags & DW_EDMA_CHIP_REG32BIT) || !IS_ENABLED(CONFIG_64BIT)) { SET_CH_32(...); SET_CH_32(...); } else { SET_CH_64(...); } Change from v1 to v2 - none drivers/dma/dw-edma/dw-edma-v0-core.c | 20 ++++++++++++-------- include/linux/dma/edma.h | 9 +++++++++ 2 files changed, 21 insertions(+), 8 deletions(-) diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c index 35f2adac93e46..00a00d68d44e7 100644 --- a/drivers/dma/dw-edma/dw-edma-v0-core.c +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c @@ -301,6 +301,7 @@ u32 dw_edma_v0_core_status_abort_int(struct dw_edma *dw, enum dw_edma_dir dir) static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) { struct dw_edma_burst *child; + struct dw_edma_chan *chan = chunk->chan; struct dw_edma_v0_lli __iomem *lli; struct dw_edma_v0_llp __iomem *llp; u32 control = 0, i = 0; @@ -314,9 +315,11 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) j = chunk->bursts_alloc; list_for_each_entry(child, &chunk->burst->list, list) { j--; - if (!j) - control |= (DW_EDMA_V0_LIE | DW_EDMA_V0_RIE); - + if (!j) { + control |= DW_EDMA_V0_LIE; + if (!(chan->dw->chip->flags & DW_EDMA_CHIP_LOCAL)) + control |= DW_EDMA_V0_RIE; + } /* Channel control */ SET_LL_32(&lli[i].control, control); /* Transfer size */ @@ -414,15 +417,16 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) SET_CH_32(dw, chan->dir, chan->id, ch_control1, (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE)); /* Linked list */ - #ifdef CONFIG_64BIT - SET_CH_64(dw, chan->dir, chan->id, llp.reg, - chunk->ll_region.paddr); - #else /* CONFIG_64BIT */ + if ((chan->dw->chip->flags & DW_EDMA_CHIP_32BIT_DBI) || + !IS_ENABLED(CONFIG_64BIT)) { SET_CH_32(dw, chan->dir, chan->id, llp.lsb, lower_32_bits(chunk->ll_region.paddr)); SET_CH_32(dw, chan->dir, chan->id, llp.msb, upper_32_bits(chunk->ll_region.paddr)); - #endif /* CONFIG_64BIT */ + } else { + SET_CH_64(dw, chan->dir, chan->id, llp.reg, + chunk->ll_region.paddr); + } } /* Doorbell */ SET_RW_32(dw, chan->dir, doorbell, diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h index c2039246fc08c..eea11b1d9e688 100644 --- a/include/linux/dma/edma.h +++ b/include/linux/dma/edma.h @@ -33,6 +33,12 @@ enum dw_edma_map_format { EDMA_MF_HDMA_COMPAT = 0x5 }; +/* Probe EDMA engine locally and prevent generate MSI to host side*/ +#define DW_EDMA_CHIP_LOCAL BIT(0) + +/* Only support 32bit DBI register access */ +#define DW_EDMA_CHIP_32BIT_DBI BIT(1) + /** * struct dw_edma_chip - representation of DesignWare eDMA controller hardware * @dev: struct device of the eDMA controller @@ -40,6 +46,8 @@ enum dw_edma_map_format { * @nr_irqs: total dma irq number * @ops DMA channel to IRQ number mapping * @reg_base DMA register base address + * @flags - DW_EDMA_CHIP_LOCAL + * - DW_EDMA_CHIP_32BIT_DBI * @ll_wr_cnt DMA write link list number * @ll_rd_cnt DMA read link list number * @rg_region DMA register region @@ -53,6 +61,7 @@ struct dw_edma_chip { int id; int nr_irqs; const struct dw_edma_core_ops *ops; + u32 flags; void __iomem *reg_base; -- 2.24.0.rc1 ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip 2022-03-09 21:12 ` [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip Frank Li @ 2022-03-10 1:07 ` kernel test robot 2022-03-10 1:07 ` kernel test robot 2022-03-10 17:46 ` Serge Semin 2 siblings, 0 replies; 52+ messages in thread From: kernel test robot @ 2022-03-10 1:07 UTC (permalink / raw) To: Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: kbuild-all, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam Hi Frank, I love your patch! Yet something to improve: [auto build test ERROR on vkoul-dmaengine/next] [also build test ERROR on helgaas-pci/next linus/master v5.17-rc7 next-20220309] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Frank-Li/Enable-designware-PCI-EP-EDMA-locally/20220310-051510 base: https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git next config: csky-buildonly-randconfig-r004-20220309 (https://download.01.org/0day-ci/archive/20220310/202203100843.qzRV56ko-lkp@intel.com/config) compiler: csky-linux-gcc (GCC) 11.2.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/f7947d784b0fe089bdaef2fee8e57f84e390d3f2 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Frank-Li/Enable-designware-PCI-EP-EDMA-locally/20220310-051510 git checkout f7947d784b0fe089bdaef2fee8e57f84e390d3f2 # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=csky SHELL=/bin/bash drivers/dma/dw-edma/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): drivers/dma/dw-edma/dw-edma-v0-core.c: In function 'dw_edma_v0_core_start': >> drivers/dma/dw-edma/dw-edma-v0-core.c:427:25: error: implicit declaration of function 'SET_CH_64'; did you mean 'SET_CH_32'? [-Werror=implicit-function-declaration] 427 | SET_CH_64(dw, chan->dir, chan->id, llp.reg, | ^~~~~~~~~ | SET_CH_32 >> drivers/dma/dw-edma/dw-edma-v0-core.c:427:60: error: 'llp' undeclared (first use in this function) 427 | SET_CH_64(dw, chan->dir, chan->id, llp.reg, | ^~~ drivers/dma/dw-edma/dw-edma-v0-core.c:427:60: note: each undeclared identifier is reported only once for each function it appears in cc1: some warnings being treated as errors vim +427 drivers/dma/dw-edma/dw-edma-v0-core.c 359 360 void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) 361 { 362 struct dw_edma_chan *chan = chunk->chan; 363 struct dw_edma *dw = chan->dw; 364 u32 tmp; 365 366 dw_edma_v0_core_write_chunk(chunk); 367 368 if (first) { 369 /* Enable engine */ 370 SET_RW_32(dw, chan->dir, engine_en, BIT(0)); 371 if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { 372 switch (chan->id) { 373 case 0: 374 SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, 375 BIT(0)); 376 break; 377 case 1: 378 SET_RW_COMPAT(dw, chan->dir, ch1_pwr_en, 379 BIT(0)); 380 break; 381 case 2: 382 SET_RW_COMPAT(dw, chan->dir, ch2_pwr_en, 383 BIT(0)); 384 break; 385 case 3: 386 SET_RW_COMPAT(dw, chan->dir, ch3_pwr_en, 387 BIT(0)); 388 break; 389 case 4: 390 SET_RW_COMPAT(dw, chan->dir, ch4_pwr_en, 391 BIT(0)); 392 break; 393 case 5: 394 SET_RW_COMPAT(dw, chan->dir, ch5_pwr_en, 395 BIT(0)); 396 break; 397 case 6: 398 SET_RW_COMPAT(dw, chan->dir, ch6_pwr_en, 399 BIT(0)); 400 break; 401 case 7: 402 SET_RW_COMPAT(dw, chan->dir, ch7_pwr_en, 403 BIT(0)); 404 break; 405 } 406 } 407 /* Interrupt unmask - done, abort */ 408 tmp = GET_RW_32(dw, chan->dir, int_mask); 409 tmp &= ~FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id)); 410 tmp &= ~FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id)); 411 SET_RW_32(dw, chan->dir, int_mask, tmp); 412 /* Linked list error */ 413 tmp = GET_RW_32(dw, chan->dir, linked_list_err_en); 414 tmp |= FIELD_PREP(EDMA_V0_LINKED_LIST_ERR_MASK, BIT(chan->id)); 415 SET_RW_32(dw, chan->dir, linked_list_err_en, tmp); 416 /* Channel control */ 417 SET_CH_32(dw, chan->dir, chan->id, ch_control1, 418 (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE)); 419 /* Linked list */ 420 if ((chan->dw->chip->flags & DW_EDMA_CHIP_32BIT_DBI) || 421 !IS_ENABLED(CONFIG_64BIT)) { 422 SET_CH_32(dw, chan->dir, chan->id, llp.lsb, 423 lower_32_bits(chunk->ll_region.paddr)); 424 SET_CH_32(dw, chan->dir, chan->id, llp.msb, 425 upper_32_bits(chunk->ll_region.paddr)); 426 } else { > 427 SET_CH_64(dw, chan->dir, chan->id, llp.reg, 428 chunk->ll_region.paddr); 429 } 430 } 431 /* Doorbell */ 432 SET_RW_32(dw, chan->dir, doorbell, 433 FIELD_PREP(EDMA_V0_DOORBELL_CH_MASK, chan->id)); 434 } 435 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip 2022-03-09 21:12 ` [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip Frank Li 2022-03-10 1:07 ` kernel test robot @ 2022-03-10 1:07 ` kernel test robot 2022-03-10 17:46 ` Serge Semin 2 siblings, 0 replies; 52+ messages in thread From: kernel test robot @ 2022-03-10 1:07 UTC (permalink / raw) To: Frank Li, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: llvm, kbuild-all, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam Hi Frank, I love your patch! Yet something to improve: [auto build test ERROR on vkoul-dmaengine/next] [also build test ERROR on helgaas-pci/next linus/master v5.17-rc7 next-20220309] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Frank-Li/Enable-designware-PCI-EP-EDMA-locally/20220310-051510 base: https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git next config: i386-randconfig-a015 (https://download.01.org/0day-ci/archive/20220310/202203100909.fpkA804r-lkp@intel.com/config) compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 276ca87382b8f16a65bddac700202924228982f6) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/f7947d784b0fe089bdaef2fee8e57f84e390d3f2 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Frank-Li/Enable-designware-PCI-EP-EDMA-locally/20220310-051510 git checkout f7947d784b0fe089bdaef2fee8e57f84e390d3f2 # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/dma/dw-edma/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): >> drivers/dma/dw-edma/dw-edma-v0-core.c:427:4: error: implicit declaration of function 'SET_CH_64' [-Werror,-Wimplicit-function-declaration] SET_CH_64(dw, chan->dir, chan->id, llp.reg, ^ >> drivers/dma/dw-edma/dw-edma-v0-core.c:427:39: error: use of undeclared identifier 'llp' SET_CH_64(dw, chan->dir, chan->id, llp.reg, ^ 2 errors generated. vim +/SET_CH_64 +427 drivers/dma/dw-edma/dw-edma-v0-core.c 359 360 void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) 361 { 362 struct dw_edma_chan *chan = chunk->chan; 363 struct dw_edma *dw = chan->dw; 364 u32 tmp; 365 366 dw_edma_v0_core_write_chunk(chunk); 367 368 if (first) { 369 /* Enable engine */ 370 SET_RW_32(dw, chan->dir, engine_en, BIT(0)); 371 if (dw->chip->mf == EDMA_MF_HDMA_COMPAT) { 372 switch (chan->id) { 373 case 0: 374 SET_RW_COMPAT(dw, chan->dir, ch0_pwr_en, 375 BIT(0)); 376 break; 377 case 1: 378 SET_RW_COMPAT(dw, chan->dir, ch1_pwr_en, 379 BIT(0)); 380 break; 381 case 2: 382 SET_RW_COMPAT(dw, chan->dir, ch2_pwr_en, 383 BIT(0)); 384 break; 385 case 3: 386 SET_RW_COMPAT(dw, chan->dir, ch3_pwr_en, 387 BIT(0)); 388 break; 389 case 4: 390 SET_RW_COMPAT(dw, chan->dir, ch4_pwr_en, 391 BIT(0)); 392 break; 393 case 5: 394 SET_RW_COMPAT(dw, chan->dir, ch5_pwr_en, 395 BIT(0)); 396 break; 397 case 6: 398 SET_RW_COMPAT(dw, chan->dir, ch6_pwr_en, 399 BIT(0)); 400 break; 401 case 7: 402 SET_RW_COMPAT(dw, chan->dir, ch7_pwr_en, 403 BIT(0)); 404 break; 405 } 406 } 407 /* Interrupt unmask - done, abort */ 408 tmp = GET_RW_32(dw, chan->dir, int_mask); 409 tmp &= ~FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id)); 410 tmp &= ~FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id)); 411 SET_RW_32(dw, chan->dir, int_mask, tmp); 412 /* Linked list error */ 413 tmp = GET_RW_32(dw, chan->dir, linked_list_err_en); 414 tmp |= FIELD_PREP(EDMA_V0_LINKED_LIST_ERR_MASK, BIT(chan->id)); 415 SET_RW_32(dw, chan->dir, linked_list_err_en, tmp); 416 /* Channel control */ 417 SET_CH_32(dw, chan->dir, chan->id, ch_control1, 418 (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE)); 419 /* Linked list */ 420 if ((chan->dw->chip->flags & DW_EDMA_CHIP_32BIT_DBI) || 421 !IS_ENABLED(CONFIG_64BIT)) { 422 SET_CH_32(dw, chan->dir, chan->id, llp.lsb, 423 lower_32_bits(chunk->ll_region.paddr)); 424 SET_CH_32(dw, chan->dir, chan->id, llp.msb, 425 upper_32_bits(chunk->ll_region.paddr)); 426 } else { > 427 SET_CH_64(dw, chan->dir, chan->id, llp.reg, 428 chunk->ll_region.paddr); 429 } 430 } 431 /* Doorbell */ 432 SET_RW_32(dw, chan->dir, doorbell, 433 FIELD_PREP(EDMA_V0_DOORBELL_CH_MASK, chan->id)); 434 } 435 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip 2022-03-09 21:12 ` [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip Frank Li 2022-03-10 1:07 ` kernel test robot 2022-03-10 1:07 ` kernel test robot @ 2022-03-10 17:46 ` Serge Semin 2022-03-10 17:54 ` Zhi Li 2 siblings, 1 reply; 52+ messages in thread From: Serge Semin @ 2022-03-10 17:46 UTC (permalink / raw) To: Frank Li Cc: Serge Semin, gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, lznuaa, vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam On Wed, Mar 09, 2022 at 03:12:03PM -0600, Frank Li wrote: > Allow PCI EP probe DMA locally and prevent use of remote MSI > to remote PCI host. > > Add option to force 32bit DBI register access even on > 64-bit systems. i.MX8 hardware only allowed 32bit register > access. Could you please split this patch up into two? These flags are unrelated thus adding them is two unrelated changes. That can be implicitly inferred from your commit log and the patch title. -Sergey > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > Change from v3 to v4 > - None > Change from v2 to v3 > - rework commit message > - Change to DW_EDMA_CHIP_32BIT_DBI > - using DW_EDMA_CHIP_LOCAL control msi > - Apply Bjorn's comments, > if (!j) { > control |= DW_EDMA_V0_LIE; > if (!(chan->chip->flags & DW_EDMA_CHIP_LOCAL)) > control |= DW_EDMA_V0_RIE; > } > > if ((chan->chip->flags & DW_EDMA_CHIP_REG32BIT) || > !IS_ENABLED(CONFIG_64BIT)) { > SET_CH_32(...); > SET_CH_32(...); > } else { > SET_CH_64(...); > } > > > Change from v1 to v2 > - none > drivers/dma/dw-edma/dw-edma-v0-core.c | 20 ++++++++++++-------- > include/linux/dma/edma.h | 9 +++++++++ > 2 files changed, 21 insertions(+), 8 deletions(-) > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > index 35f2adac93e46..00a00d68d44e7 100644 > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > @@ -301,6 +301,7 @@ u32 dw_edma_v0_core_status_abort_int(struct dw_edma *dw, enum dw_edma_dir dir) > static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > { > struct dw_edma_burst *child; > + struct dw_edma_chan *chan = chunk->chan; > struct dw_edma_v0_lli __iomem *lli; > struct dw_edma_v0_llp __iomem *llp; > u32 control = 0, i = 0; > @@ -314,9 +315,11 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > j = chunk->bursts_alloc; > list_for_each_entry(child, &chunk->burst->list, list) { > j--; > - if (!j) > - control |= (DW_EDMA_V0_LIE | DW_EDMA_V0_RIE); > - > + if (!j) { > + control |= DW_EDMA_V0_LIE; > + if (!(chan->dw->chip->flags & DW_EDMA_CHIP_LOCAL)) > + control |= DW_EDMA_V0_RIE; > + } > /* Channel control */ > SET_LL_32(&lli[i].control, control); > /* Transfer size */ > @@ -414,15 +417,16 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > SET_CH_32(dw, chan->dir, chan->id, ch_control1, > (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE)); > /* Linked list */ > - #ifdef CONFIG_64BIT > - SET_CH_64(dw, chan->dir, chan->id, llp.reg, > - chunk->ll_region.paddr); > - #else /* CONFIG_64BIT */ > + if ((chan->dw->chip->flags & DW_EDMA_CHIP_32BIT_DBI) || > + !IS_ENABLED(CONFIG_64BIT)) { > SET_CH_32(dw, chan->dir, chan->id, llp.lsb, > lower_32_bits(chunk->ll_region.paddr)); > SET_CH_32(dw, chan->dir, chan->id, llp.msb, > upper_32_bits(chunk->ll_region.paddr)); > - #endif /* CONFIG_64BIT */ > + } else { > + SET_CH_64(dw, chan->dir, chan->id, llp.reg, > + chunk->ll_region.paddr); > + } > } > /* Doorbell */ > SET_RW_32(dw, chan->dir, doorbell, > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > index c2039246fc08c..eea11b1d9e688 100644 > --- a/include/linux/dma/edma.h > +++ b/include/linux/dma/edma.h > @@ -33,6 +33,12 @@ enum dw_edma_map_format { > EDMA_MF_HDMA_COMPAT = 0x5 > }; > > +/* Probe EDMA engine locally and prevent generate MSI to host side*/ > +#define DW_EDMA_CHIP_LOCAL BIT(0) > + > +/* Only support 32bit DBI register access */ > +#define DW_EDMA_CHIP_32BIT_DBI BIT(1) > + > /** > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > * @dev: struct device of the eDMA controller > @@ -40,6 +46,8 @@ enum dw_edma_map_format { > * @nr_irqs: total dma irq number > * @ops DMA channel to IRQ number mapping > * @reg_base DMA register base address > + * @flags - DW_EDMA_CHIP_LOCAL > + * - DW_EDMA_CHIP_32BIT_DBI > * @ll_wr_cnt DMA write link list number > * @ll_rd_cnt DMA read link list number > * @rg_region DMA register region > @@ -53,6 +61,7 @@ struct dw_edma_chip { > int id; > int nr_irqs; > const struct dw_edma_core_ops *ops; > + u32 flags; > > void __iomem *reg_base; > > -- > 2.24.0.rc1 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip 2022-03-10 17:46 ` Serge Semin @ 2022-03-10 17:54 ` Zhi Li 2022-03-10 18:25 ` Serge Semin 0 siblings, 1 reply; 52+ messages in thread From: Zhi Li @ 2022-03-10 17:54 UTC (permalink / raw) To: Serge Semin Cc: Frank Li, Serge Semin, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Thu, Mar 10, 2022 at 11:47 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > On Wed, Mar 09, 2022 at 03:12:03PM -0600, Frank Li wrote: > > Allow PCI EP probe DMA locally and prevent use of remote MSI > > to remote PCI host. > > > > Add option to force 32bit DBI register access even on > > 64-bit systems. i.MX8 hardware only allowed 32bit register > > access. > > Could you please split this patch up into two? These flags are > unrelated thus adding them is two unrelated changes. That can be > implicitly inferred from your commit log and the patch title. I don't think it needs to be separated. It also show why need 32bit mask to control features and reserved futured extension capability . The two flags were descriptions for EDMA chip features. > > -Sergey > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > --- > > Change from v3 to v4 > > - None > > Change from v2 to v3 > > - rework commit message > > - Change to DW_EDMA_CHIP_32BIT_DBI > > - using DW_EDMA_CHIP_LOCAL control msi > > - Apply Bjorn's comments, > > if (!j) { > > control |= DW_EDMA_V0_LIE; > > if (!(chan->chip->flags & DW_EDMA_CHIP_LOCAL)) > > control |= DW_EDMA_V0_RIE; > > } > > > > if ((chan->chip->flags & DW_EDMA_CHIP_REG32BIT) || > > !IS_ENABLED(CONFIG_64BIT)) { > > SET_CH_32(...); > > SET_CH_32(...); > > } else { > > SET_CH_64(...); > > } > > > > > > Change from v1 to v2 > > - none > > drivers/dma/dw-edma/dw-edma-v0-core.c | 20 ++++++++++++-------- > > include/linux/dma/edma.h | 9 +++++++++ > > 2 files changed, 21 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > > index 35f2adac93e46..00a00d68d44e7 100644 > > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > > @@ -301,6 +301,7 @@ u32 dw_edma_v0_core_status_abort_int(struct dw_edma *dw, enum dw_edma_dir dir) > > static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > > { > > struct dw_edma_burst *child; > > + struct dw_edma_chan *chan = chunk->chan; > > struct dw_edma_v0_lli __iomem *lli; > > struct dw_edma_v0_llp __iomem *llp; > > u32 control = 0, i = 0; > > @@ -314,9 +315,11 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > > j = chunk->bursts_alloc; > > list_for_each_entry(child, &chunk->burst->list, list) { > > j--; > > - if (!j) > > - control |= (DW_EDMA_V0_LIE | DW_EDMA_V0_RIE); > > - > > + if (!j) { > > + control |= DW_EDMA_V0_LIE; > > + if (!(chan->dw->chip->flags & DW_EDMA_CHIP_LOCAL)) > > + control |= DW_EDMA_V0_RIE; > > + } > > /* Channel control */ > > SET_LL_32(&lli[i].control, control); > > /* Transfer size */ > > @@ -414,15 +417,16 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > SET_CH_32(dw, chan->dir, chan->id, ch_control1, > > (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE)); > > /* Linked list */ > > - #ifdef CONFIG_64BIT > > - SET_CH_64(dw, chan->dir, chan->id, llp.reg, > > - chunk->ll_region.paddr); > > - #else /* CONFIG_64BIT */ > > + if ((chan->dw->chip->flags & DW_EDMA_CHIP_32BIT_DBI) || > > + !IS_ENABLED(CONFIG_64BIT)) { > > SET_CH_32(dw, chan->dir, chan->id, llp.lsb, > > lower_32_bits(chunk->ll_region.paddr)); > > SET_CH_32(dw, chan->dir, chan->id, llp.msb, > > upper_32_bits(chunk->ll_region.paddr)); > > - #endif /* CONFIG_64BIT */ > > + } else { > > + SET_CH_64(dw, chan->dir, chan->id, llp.reg, > > + chunk->ll_region.paddr); > > + } > > } > > /* Doorbell */ > > SET_RW_32(dw, chan->dir, doorbell, > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > > index c2039246fc08c..eea11b1d9e688 100644 > > --- a/include/linux/dma/edma.h > > +++ b/include/linux/dma/edma.h > > @@ -33,6 +33,12 @@ enum dw_edma_map_format { > > EDMA_MF_HDMA_COMPAT = 0x5 > > }; > > > > +/* Probe EDMA engine locally and prevent generate MSI to host side*/ > > +#define DW_EDMA_CHIP_LOCAL BIT(0) > > + > > +/* Only support 32bit DBI register access */ > > +#define DW_EDMA_CHIP_32BIT_DBI BIT(1) > > + > > /** > > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > > * @dev: struct device of the eDMA controller > > @@ -40,6 +46,8 @@ enum dw_edma_map_format { > > * @nr_irqs: total dma irq number > > * @ops DMA channel to IRQ number mapping > > * @reg_base DMA register base address > > + * @flags - DW_EDMA_CHIP_LOCAL > > + * - DW_EDMA_CHIP_32BIT_DBI > > * @ll_wr_cnt DMA write link list number > > * @ll_rd_cnt DMA read link list number > > * @rg_region DMA register region > > @@ -53,6 +61,7 @@ struct dw_edma_chip { > > int id; > > int nr_irqs; > > const struct dw_edma_core_ops *ops; > > + u32 flags; > > > > void __iomem *reg_base; > > > > -- > > 2.24.0.rc1 > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip 2022-03-10 17:54 ` Zhi Li @ 2022-03-10 18:25 ` Serge Semin 0 siblings, 0 replies; 52+ messages in thread From: Serge Semin @ 2022-03-10 18:25 UTC (permalink / raw) To: Zhi Li Cc: Serge Semin, Frank Li, gustavo.pimentel, hongxing.zhu, Lucas Stach, dl-linux-imx, linux-pci, dmaengine, vkoul, lorenzo.pieralisi, robh, kw, Bjorn Helgaas, Shawn Guo, Manivannan Sadhasivam On Thu, Mar 10, 2022 at 11:54:30AM -0600, Zhi Li wrote: > On Thu, Mar 10, 2022 at 11:47 AM Serge Semin <fancer.lancer@gmail.com> wrote: > > > > On Wed, Mar 09, 2022 at 03:12:03PM -0600, Frank Li wrote: > > > Allow PCI EP probe DMA locally and prevent use of remote MSI > > > to remote PCI host. > > > > > > Add option to force 32bit DBI register access even on > > > 64-bit systems. i.MX8 hardware only allowed 32bit register > > > access. > > > > Could you please split this patch up into two? These flags are > > unrelated thus adding them is two unrelated changes. That can be > > implicitly inferred from your commit log and the patch title. > > I don't think it needs to be separated. It also show why need 32bit mask to > control features and reserved futured extension capability . > > The two flags were descriptions for EDMA chip features. Both of these flags define separate platform features. Each of which can be distinctively specific for a particular SoC, not only for the i.MX8. Even though your log messages does mention i.MX8 hardware the corresponding flag is defined as generic in the patch. As I said both flags are unrelated to each other and can be independently specific to one or another platform. So one SoC can be restricted to use 32bits DBI IOs and do have the Synopsys PCIe End-point IP prototype kit detected on the PCIe bus. Another SoC can have the eDMA core embedded into the DW PCIe EP/Host controller, but with no 32-bits DBI IOs requirement. Secondly since both of these flags are unrelated then having a monolithic patch as you suggest will harden the bisection procedure in case of a bug is caused by one of these modifications. Bisecting will lead straight to the bogus change if the patch is split up into two. Thirdly as I said before your commit log states two distinctive changes, which means the log can be split up into two together with the logical changes. In addition referring to a particular change in further commits will be more informative. Finally please see [1] regarding the patches splitting up, logical changes, bisection, etc. [1] Documentation/process/submitting-patches.rst: "Separate your changes" -Sergey > > > > > -Sergey > > > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > --- > > > Change from v3 to v4 > > > - None > > > Change from v2 to v3 > > > - rework commit message > > > - Change to DW_EDMA_CHIP_32BIT_DBI > > > - using DW_EDMA_CHIP_LOCAL control msi > > > - Apply Bjorn's comments, > > > if (!j) { > > > control |= DW_EDMA_V0_LIE; > > > if (!(chan->chip->flags & DW_EDMA_CHIP_LOCAL)) > > > control |= DW_EDMA_V0_RIE; > > > } > > > > > > if ((chan->chip->flags & DW_EDMA_CHIP_REG32BIT) || > > > !IS_ENABLED(CONFIG_64BIT)) { > > > SET_CH_32(...); > > > SET_CH_32(...); > > > } else { > > > SET_CH_64(...); > > > } > > > > > > > > > Change from v1 to v2 > > > - none > > > drivers/dma/dw-edma/dw-edma-v0-core.c | 20 ++++++++++++-------- > > > include/linux/dma/edma.h | 9 +++++++++ > > > 2 files changed, 21 insertions(+), 8 deletions(-) > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c > > > index 35f2adac93e46..00a00d68d44e7 100644 > > > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c > > > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c > > > @@ -301,6 +301,7 @@ u32 dw_edma_v0_core_status_abort_int(struct dw_edma *dw, enum dw_edma_dir dir) > > > static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > > > { > > > struct dw_edma_burst *child; > > > + struct dw_edma_chan *chan = chunk->chan; > > > struct dw_edma_v0_lli __iomem *lli; > > > struct dw_edma_v0_llp __iomem *llp; > > > u32 control = 0, i = 0; > > > @@ -314,9 +315,11 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk) > > > j = chunk->bursts_alloc; > > > list_for_each_entry(child, &chunk->burst->list, list) { > > > j--; > > > - if (!j) > > > - control |= (DW_EDMA_V0_LIE | DW_EDMA_V0_RIE); > > > - > > > + if (!j) { > > > + control |= DW_EDMA_V0_LIE; > > > + if (!(chan->dw->chip->flags & DW_EDMA_CHIP_LOCAL)) > > > + control |= DW_EDMA_V0_RIE; > > > + } > > > /* Channel control */ > > > SET_LL_32(&lli[i].control, control); > > > /* Transfer size */ > > > @@ -414,15 +417,16 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first) > > > SET_CH_32(dw, chan->dir, chan->id, ch_control1, > > > (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE)); > > > /* Linked list */ > > > - #ifdef CONFIG_64BIT > > > - SET_CH_64(dw, chan->dir, chan->id, llp.reg, > > > - chunk->ll_region.paddr); > > > - #else /* CONFIG_64BIT */ > > > + if ((chan->dw->chip->flags & DW_EDMA_CHIP_32BIT_DBI) || > > > + !IS_ENABLED(CONFIG_64BIT)) { > > > SET_CH_32(dw, chan->dir, chan->id, llp.lsb, > > > lower_32_bits(chunk->ll_region.paddr)); > > > SET_CH_32(dw, chan->dir, chan->id, llp.msb, > > > upper_32_bits(chunk->ll_region.paddr)); > > > - #endif /* CONFIG_64BIT */ > > > + } else { > > > + SET_CH_64(dw, chan->dir, chan->id, llp.reg, > > > + chunk->ll_region.paddr); > > > + } > > > } > > > /* Doorbell */ > > > SET_RW_32(dw, chan->dir, doorbell, > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h > > > index c2039246fc08c..eea11b1d9e688 100644 > > > --- a/include/linux/dma/edma.h > > > +++ b/include/linux/dma/edma.h > > > @@ -33,6 +33,12 @@ enum dw_edma_map_format { > > > EDMA_MF_HDMA_COMPAT = 0x5 > > > }; > > > > > > +/* Probe EDMA engine locally and prevent generate MSI to host side*/ > > > +#define DW_EDMA_CHIP_LOCAL BIT(0) > > > + > > > +/* Only support 32bit DBI register access */ > > > +#define DW_EDMA_CHIP_32BIT_DBI BIT(1) > > > + > > > /** > > > * struct dw_edma_chip - representation of DesignWare eDMA controller hardware > > > * @dev: struct device of the eDMA controller > > > @@ -40,6 +46,8 @@ enum dw_edma_map_format { > > > * @nr_irqs: total dma irq number > > > * @ops DMA channel to IRQ number mapping > > > * @reg_base DMA register base address > > > + * @flags - DW_EDMA_CHIP_LOCAL > > > + * - DW_EDMA_CHIP_32BIT_DBI > > > * @ll_wr_cnt DMA write link list number > > > * @ll_rd_cnt DMA read link list number > > > * @rg_region DMA register region > > > @@ -53,6 +61,7 @@ struct dw_edma_chip { > > > int id; > > > int nr_irqs; > > > const struct dw_edma_core_ops *ops; > > > + u32 flags; > > > > > > void __iomem *reg_base; > > > > > > -- > > > 2.24.0.rc1 > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v4 8/8] PCI: endpoint: functions/pci-epf-test: Support PCI controller DMA 2022-03-09 21:11 [PATCH v4 0/8] Enable designware PCI EP EDMA locally Frank Li ` (6 preceding siblings ...) 2022-03-09 21:12 ` [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip Frank Li @ 2022-03-09 21:12 ` Frank Li 7 siblings, 0 replies; 52+ messages in thread From: Frank Li @ 2022-03-09 21:12 UTC (permalink / raw) To: gustavo.pimentel, hongxing.zhu, l.stach, linux-imx, linux-pci, dmaengine, fancer.lancer, lznuaa Cc: vkoul, lorenzo.pieralisi, robh, kw, bhelgaas, shawnguo, manivannan.sadhasivam Designware provided eDMA support in controller. This enabled use this eDMA controller to transfer data. The whole flow align with standard DMA usage module 1. Using dma_request_channel() and filter function to find correct RX and TX Channel. 2. dmaengine_slave_config() config remote side physcial address. 3. using dmaengine_prep_slave_single() create transfer descriptor 4. tx_submit(); 5. dma_async_issue_pending(); Tested at i.MX8DXL platform. root@imx8qmmek:~# /usr/bin/pcitest -d -w WRITE ( 102400 bytes): OKAY root@imx8qmmek:~# /usr/bin/pcitest -d -r READ ( 102400 bytes): OKAY WRITE => Size: 102400 bytes DMA: YES Time: 0.000180145 seconds Rate: 555108 KB/s READ => Size: 102400 bytes DMA: YES Time: 0.000194397 seconds Rate: 514411 KB/s READ => Size: 102400 bytes DMA: NO Time: 0.013532597 seconds Rate: 7389 KB/s WRITE => Size: 102400 bytes DMA: NO Time: 0.000857090 seconds Rate: 116673 KB/s Signed-off-by: Frank Li <Frank.Li@nxp.com> --- Change from v3 to v4: - reverse Xmas tree order - local -> dma_local - change error message - IS_ERR -> IS_ERR_OR_NULL - check return value of dmaengine_slave_config() Change from v1 to v2: - none drivers/pci/endpoint/functions/pci-epf-test.c | 108 ++++++++++++++++-- 1 file changed, 98 insertions(+), 10 deletions(-) diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c index 90d84d3bc868f..f26afd02f3a86 100644 --- a/drivers/pci/endpoint/functions/pci-epf-test.c +++ b/drivers/pci/endpoint/functions/pci-epf-test.c @@ -52,9 +52,11 @@ struct pci_epf_test { enum pci_barno test_reg_bar; size_t msix_table_offset; struct delayed_work cmd_handler; - struct dma_chan *dma_chan; + struct dma_chan *dma_chan_tx; + struct dma_chan *dma_chan_rx; struct completion transfer_complete; bool dma_supported; + bool dma_private; const struct pci_epc_features *epc_features; }; @@ -105,12 +107,15 @@ static void pci_epf_test_dma_callback(void *param) */ static int pci_epf_test_data_transfer(struct pci_epf_test *epf_test, dma_addr_t dma_dst, dma_addr_t dma_src, - size_t len) + size_t len, dma_addr_t dma_remote, + enum dma_transfer_direction dir) { + struct dma_chan *chan = (dir == DMA_DEV_TO_MEM) ? epf_test->dma_chan_tx : epf_test->dma_chan_rx; + dma_addr_t dma_local = (dir == DMA_MEM_TO_DEV) ? dma_src : dma_dst; enum dma_ctrl_flags flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT; - struct dma_chan *chan = epf_test->dma_chan; struct pci_epf *epf = epf_test->epf; struct dma_async_tx_descriptor *tx; + struct dma_slave_config sconf = {}; struct device *dev = &epf->dev; dma_cookie_t cookie; int ret; @@ -120,7 +125,22 @@ static int pci_epf_test_data_transfer(struct pci_epf_test *epf_test, return -EINVAL; } - tx = dmaengine_prep_dma_memcpy(chan, dma_dst, dma_src, len, flags); + if (epf_test->dma_private) { + sconf.direction = dir; + if (dir == DMA_MEM_TO_DEV) + sconf.dst_addr = dma_remote; + else + sconf.src_addr = dma_remote; + + if (dmaengine_slave_config(chan, &sconf)) { + dev_err(dev, "DMA slave config fail\n"); + return -EIO; + } + tx = dmaengine_prep_slave_single(chan, dma_local, len, dir, flags); + } else { + tx = dmaengine_prep_dma_memcpy(chan, dma_dst, dma_src, len, flags); + } + if (!tx) { dev_err(dev, "Failed to prepare DMA memcpy\n"); return -EIO; @@ -148,6 +168,23 @@ static int pci_epf_test_data_transfer(struct pci_epf_test *epf_test, return 0; } +struct epf_dma_filter { + struct device *dev; + u32 dma_mask; +}; + +static bool epf_dma_filter_fn(struct dma_chan *chan, void *node) +{ + struct epf_dma_filter *filter = node; + struct dma_slave_caps caps; + + memset(&caps, 0, sizeof(caps)); + dma_get_slave_caps(chan, &caps); + + return chan->device->dev == filter->dev + && (filter->dma_mask & caps.directions); +} + /** * pci_epf_test_init_dma_chan() - Function to initialize EPF test DMA channel * @epf_test: the EPF test device that performs data transfer operation @@ -158,10 +195,44 @@ static int pci_epf_test_init_dma_chan(struct pci_epf_test *epf_test) { struct pci_epf *epf = epf_test->epf; struct device *dev = &epf->dev; + struct epf_dma_filter filter; struct dma_chan *dma_chan; dma_cap_mask_t mask; int ret; + filter.dev = epf->epc->dev.parent; + filter.dma_mask = BIT(DMA_DEV_TO_MEM); + + dma_cap_zero(mask); + dma_cap_set(DMA_SLAVE, mask); + dma_chan = dma_request_channel(mask, epf_dma_filter_fn, &filter); + if (IS_ERR_OR_NULL(dma_chan)) { + dev_info(dev, "Failed to get private DMA channel. Falling back to generic one\n"); + goto fail_back_tx; + } + + epf_test->dma_chan_rx = dma_chan; + + filter.dma_mask = BIT(DMA_MEM_TO_DEV); + dma_chan = dma_request_channel(mask, epf_dma_filter_fn, &filter); + + if (IS_ERR(dma_chan)) { + dev_info(dev, "Failed to get private DMA channel. Falling back to generic one\n"); + goto fail_back_rx; + } + + epf_test->dma_chan_tx = dma_chan; + epf_test->dma_private = true; + + init_completion(&epf_test->transfer_complete); + + return 0; + +fail_back_rx: + dma_release_channel(epf_test->dma_chan_rx); + epf_test->dma_chan_tx = NULL; + +fail_back_tx: dma_cap_zero(mask); dma_cap_set(DMA_MEMCPY, mask); @@ -174,7 +245,7 @@ static int pci_epf_test_init_dma_chan(struct pci_epf_test *epf_test) } init_completion(&epf_test->transfer_complete); - epf_test->dma_chan = dma_chan; + epf_test->dma_chan_tx = epf_test->dma_chan_rx = dma_chan; return 0; } @@ -190,8 +261,17 @@ static void pci_epf_test_clean_dma_chan(struct pci_epf_test *epf_test) if (!epf_test->dma_supported) return; - dma_release_channel(epf_test->dma_chan); - epf_test->dma_chan = NULL; + dma_release_channel(epf_test->dma_chan_tx); + if (epf_test->dma_chan_tx == epf_test->dma_chan_rx) { + epf_test->dma_chan_tx = NULL; + epf_test->dma_chan_rx = NULL; + return; + } + + dma_release_channel(epf_test->dma_chan_rx); + epf_test->dma_chan_rx = NULL; + + return; } static void pci_epf_test_print_rate(const char *ops, u64 size, @@ -280,8 +360,14 @@ static int pci_epf_test_copy(struct pci_epf_test *epf_test) goto err_map_addr; } + if (epf_test->dma_private) { + dev_err(dev, "Cannot transfer data using DMA\n"); + ret = -EINVAL; + goto err_map_addr; + } + ret = pci_epf_test_data_transfer(epf_test, dst_phys_addr, - src_phys_addr, reg->size); + src_phys_addr, reg->size, 0, DMA_MEM_TO_MEM); if (ret) dev_err(dev, "Data transfer failed\n"); } else { @@ -363,7 +449,8 @@ static int pci_epf_test_read(struct pci_epf_test *epf_test) ktime_get_ts64(&start); ret = pci_epf_test_data_transfer(epf_test, dst_phys_addr, - phys_addr, reg->size); + phys_addr, reg->size, + reg->src_addr, DMA_DEV_TO_MEM); if (ret) dev_err(dev, "Data transfer failed\n"); ktime_get_ts64(&end); @@ -453,8 +540,9 @@ static int pci_epf_test_write(struct pci_epf_test *epf_test) } ktime_get_ts64(&start); + ret = pci_epf_test_data_transfer(epf_test, phys_addr, - src_phys_addr, reg->size); + src_phys_addr, reg->size, reg->dst_addr, DMA_MEM_TO_DEV); if (ret) dev_err(dev, "Data transfer failed\n"); ktime_get_ts64(&end); -- 2.24.0.rc1 ^ permalink raw reply related [flat|nested] 52+ messages in thread
end of thread, other threads:[~2022-03-22 22:25 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-09 21:11 [PATCH v4 0/8] Enable designware PCI EP EDMA locally Frank Li 2022-03-09 21:11 ` [PATCH v4 1/8] dmaengine: dw-edma: Detach the private data and chip info structures Frank Li 2022-03-10 12:50 ` Serge Semin 2022-03-10 20:20 ` Serge Semin 2022-03-10 20:29 ` Zhi Li 2022-03-11 11:03 ` Serge Semin 2022-03-11 15:29 ` Zhi Li 2022-03-12 19:56 ` Serge Semin 2022-03-12 19:54 ` Serge Semin 2022-03-09 21:11 ` [PATCH v4 2/8] dmaengine: dw-edma: remove unused field irq in struct dw_edma_chip Frank Li 2022-03-10 12:52 ` Serge Semin 2022-03-09 21:11 ` [PATCH v4 3/8] dmaengine: dw-edma: change rg_region to reg_base " Frank Li 2022-03-10 12:56 ` Serge Semin 2022-03-09 21:12 ` [PATCH v4 4/8] dmaengine: dw-edma: rename wr(rd)_ch_cnt to ll_wr(rd)_cnt " Frank Li 2022-03-10 12:37 ` Serge Semin 2022-03-10 16:26 ` Zhi Li 2022-03-10 16:51 ` Zhi Li 2022-03-10 18:45 ` Serge Semin 2022-03-09 21:12 ` [PATCH v4 5/8] dmaengine: dw-edma: Fix programming the source & dest addresses for ep Frank Li 2022-03-10 16:31 ` Serge Semin 2022-03-10 16:50 ` Zhi Li 2022-03-10 19:37 ` Serge Semin 2022-03-10 20:16 ` Zhi Li 2022-03-11 12:38 ` Serge Semin 2022-03-11 15:37 ` Zhi Li 2022-03-11 16:03 ` Zhi Li 2022-03-11 17:14 ` Serge Semin 2022-03-11 17:55 ` Manivannan Sadhasivam 2022-03-11 19:08 ` Serge Semin 2022-03-11 17:46 ` Manivannan Sadhasivam 2022-03-11 17:41 ` Manivannan Sadhasivam 2022-03-11 19:01 ` Serge Semin 2022-03-12 5:37 ` Manivannan Sadhasivam 2022-03-14 8:33 ` Serge Semin 2022-03-18 18:06 ` Manivannan Sadhasivam 2022-03-18 18:19 ` Serge Semin 2022-03-20 23:16 ` Serge Semin 2022-03-22 13:55 ` Zhi Li 2022-03-22 14:03 ` Serge Semin 2022-03-22 22:25 ` Serge Semin 2022-03-09 21:12 ` [PATCH v4 6/8] dmaengine: dw-edma: Don't rely on the deprecated "direction" member Frank Li 2022-03-10 17:29 ` Serge Semin 2022-03-10 17:41 ` Manivannan Sadhasivam 2022-03-10 17:52 ` Serge Semin 2022-03-11 17:58 ` Manivannan Sadhasivam 2022-03-09 21:12 ` [PATCH v4 7/8] dmaengine: dw-edma: add flags at struct dw_edma_chip Frank Li 2022-03-10 1:07 ` kernel test robot 2022-03-10 1:07 ` kernel test robot 2022-03-10 17:46 ` Serge Semin 2022-03-10 17:54 ` Zhi Li 2022-03-10 18:25 ` Serge Semin 2022-03-09 21:12 ` [PATCH v4 8/8] PCI: endpoint: functions/pci-epf-test: Support PCI controller DMA Frank Li
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).