* [V2] dmaengine: axi-dmac: assign `copy_align` property
From: Ardelean, Alexandru @ 2019-02-27 8:12 UTC (permalink / raw)
To: dmaengine@vger.kernel.org, vkoul@kernel.org
On Tue, 2019-02-26 at 10:52 +0200, Alexandru Ardelean wrote:
> The `copy_align` property is a generic property that describes alignment
> for DMA memcpy & sg ops.
> It serves mostly an informational purpose, and can be used in DMA tests,
> to
> pass the info to know what alignment to expect.
>
build bot said this doesn't compile.
I think this patch needs to come later after some more updates have been
pushed for this driver.
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
>
> Changelog v1 -> v2:
> * re-applied & moved the `copy_align` assignment; apparently it was
> conflicting with another patch from another series
>
> drivers/dma/dma-axi-dmac.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> index ffc0adc2f6ce..5ec223ff7e1a 100644
> --- a/drivers/dma/dma-axi-dmac.c
> +++ b/drivers/dma/dma-axi-dmac.c
> @@ -666,6 +666,7 @@ static int axi_dmac_probe(struct platform_device
> *pdev)
> dma_dev->dst_addr_widths = BIT(dmac->chan.dest_width);
> dma_dev->directions = BIT(dmac->chan.direction);
> dma_dev->residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> + dma_dev->copy_align = (dmac->chan.address_align_mask + 1);
> INIT_LIST_HEAD(&dma_dev->channels);
>
> dmac->chan.vchan.desc_free = axi_dmac_desc_free;
^ permalink raw reply
* [V2] dmaengine: axi-dmac: assign `copy_align` property
From: kbuild test robot @ 2019-02-26 17:43 UTC (permalink / raw)
To: Alexandru Ardelean; +Cc: kbuild-all, dmaengine, vkoul
Hi Alexandru,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc8 next-20190226]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Alexandru-Ardelean/dmaengine-axi-dmac-assign-copy_align-property/20190226-215236
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
drivers//dma/dma-axi-dmac.c: In function 'axi_dmac_probe':
>> drivers//dma/dma-axi-dmac.c:670:36: error: 'struct axi_dmac_chan' has no member named 'address_align_mask'; did you mean 'align_mask'?
dma_dev->copy_align = (dmac->chan.address_align_mask + 1);
^~~~~~~~~~~~~~~~~~
align_mask
vim +670 drivers//dma/dma-axi-dmac.c
606
607 static int axi_dmac_probe(struct platform_device *pdev)
608 {
609 struct device_node *of_channels, *of_chan;
610 struct dma_device *dma_dev;
611 struct axi_dmac *dmac;
612 struct resource *res;
613 int ret;
614
615 dmac = devm_kzalloc(&pdev->dev, sizeof(*dmac), GFP_KERNEL);
616 if (!dmac)
617 return -ENOMEM;
618
619 dmac->irq = platform_get_irq(pdev, 0);
620 if (dmac->irq < 0)
621 return dmac->irq;
622 if (dmac->irq == 0)
623 return -EINVAL;
624
625 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
626 dmac->base = devm_ioremap_resource(&pdev->dev, res);
627 if (IS_ERR(dmac->base))
628 return PTR_ERR(dmac->base);
629
630 dmac->clk = devm_clk_get(&pdev->dev, NULL);
631 if (IS_ERR(dmac->clk))
632 return PTR_ERR(dmac->clk);
633
634 INIT_LIST_HEAD(&dmac->chan.active_descs);
635
636 of_channels = of_get_child_by_name(pdev->dev.of_node, "adi,channels");
637 if (of_channels == NULL)
638 return -ENODEV;
639
640 for_each_child_of_node(of_channels, of_chan) {
641 ret = axi_dmac_parse_chan_dt(of_chan, &dmac->chan);
642 if (ret) {
643 of_node_put(of_chan);
644 of_node_put(of_channels);
645 return -EINVAL;
646 }
647 }
648 of_node_put(of_channels);
649
650 pdev->dev.dma_parms = &dmac->dma_parms;
651 dma_set_max_seg_size(&pdev->dev, dmac->chan.max_length);
652
653 dma_dev = &dmac->dma_dev;
654 dma_cap_set(DMA_SLAVE, dma_dev->cap_mask);
655 dma_cap_set(DMA_CYCLIC, dma_dev->cap_mask);
656 dma_dev->device_free_chan_resources = axi_dmac_free_chan_resources;
657 dma_dev->device_tx_status = dma_cookie_status;
658 dma_dev->device_issue_pending = axi_dmac_issue_pending;
659 dma_dev->device_prep_slave_sg = axi_dmac_prep_slave_sg;
660 dma_dev->device_prep_dma_cyclic = axi_dmac_prep_dma_cyclic;
661 dma_dev->device_prep_interleaved_dma = axi_dmac_prep_interleaved;
662 dma_dev->device_terminate_all = axi_dmac_terminate_all;
663 dma_dev->device_synchronize = axi_dmac_synchronize;
664 dma_dev->dev = &pdev->dev;
665 dma_dev->chancnt = 1;
666 dma_dev->src_addr_widths = BIT(dmac->chan.src_width);
667 dma_dev->dst_addr_widths = BIT(dmac->chan.dest_width);
668 dma_dev->directions = BIT(dmac->chan.direction);
669 dma_dev->residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> 670 dma_dev->copy_align = (dmac->chan.address_align_mask + 1);
671 INIT_LIST_HEAD(&dma_dev->channels);
672
673 dmac->chan.vchan.desc_free = axi_dmac_desc_free;
674 vchan_init(&dmac->chan.vchan, dma_dev);
675
676 ret = clk_prepare_enable(dmac->clk);
677 if (ret < 0)
678 return ret;
679
680 axi_dmac_write(dmac, AXI_DMAC_REG_IRQ_MASK, 0x00);
681
682 ret = dma_async_device_register(dma_dev);
683 if (ret)
684 goto err_clk_disable;
685
686 ret = of_dma_controller_register(pdev->dev.of_node,
687 of_dma_xlate_by_chan_id, dma_dev);
688 if (ret)
689 goto err_unregister_device;
690
691 ret = request_irq(dmac->irq, axi_dmac_interrupt_handler, IRQF_SHARED,
692 dev_name(&pdev->dev), dmac);
693 if (ret)
694 goto err_unregister_of;
695
696 platform_set_drvdata(pdev, dmac);
697
698 return 0;
699
700 err_unregister_of:
701 of_dma_controller_free(pdev->dev.of_node);
702 err_unregister_device:
703 dma_async_device_unregister(&dmac->dma_dev);
704 err_clk_disable:
705 clk_disable_unprepare(dmac->clk);
706
707 return ret;
708 }
709
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [V2] dmaengine: axi-dmac: assign `copy_align` property
From: Alexandru Ardelean @ 2019-02-26 8:52 UTC (permalink / raw)
To: dmaengine, vkoul; +Cc: Alexandru Ardelean
The `copy_align` property is a generic property that describes alignment
for DMA memcpy & sg ops.
It serves mostly an informational purpose, and can be used in DMA tests, to
pass the info to know what alignment to expect.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
Changelog v1 -> v2:
* re-applied & moved the `copy_align` assignment; apparently it was
conflicting with another patch from another series
drivers/dma/dma-axi-dmac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
index ffc0adc2f6ce..5ec223ff7e1a 100644
--- a/drivers/dma/dma-axi-dmac.c
+++ b/drivers/dma/dma-axi-dmac.c
@@ -666,6 +666,7 @@ static int axi_dmac_probe(struct platform_device *pdev)
dma_dev->dst_addr_widths = BIT(dmac->chan.dest_width);
dma_dev->directions = BIT(dmac->chan.direction);
dma_dev->residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+ dma_dev->copy_align = (dmac->chan.address_align_mask + 1);
INIT_LIST_HEAD(&dma_dev->channels);
dmac->chan.vchan.desc_free = axi_dmac_desc_free;
^ permalink raw reply related
* [V2] dmaengine: axi-dmac: don't check the number of frames for alignment
From: Alexandru Ardelean @ 2019-02-26 8:48 UTC (permalink / raw)
To: dmaengine, vkoul; +Cc: Alexandru Ardelean
In 2D transfers (for the AXI DMAC), the number of frames (numf) represents
Y_LENGTH, and the length of a frame is X_LENGTH. 2D transfers are useful
for video transfers where screen resolutions ( X * Y ) are typically
aligned for X, but not for Y.
There is no requirement for Y_LENGTH to be aligned to the bus-width (or
anything), and this is also true for AXI DMAC.
Checking the Y_LENGTH for alignment causes false errors when initiating DMA
transfers. This change fixes this by checking only that the Y_LENGTH is
non-zero.
Fixes: 0e3b67b348b8 ("maengine: Add support for the Analog Devices AXI-DMAC DMA controller")
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/dma/dma-axi-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
index ffc0adc2f6ce..2c999113b989 100644
--- a/drivers/dma/dma-axi-dmac.c
+++ b/drivers/dma/dma-axi-dmac.c
@@ -485,7 +485,7 @@ static struct dma_async_tx_descriptor *axi_dmac_prep_interleaved(
if (chan->hw_2d) {
if (!axi_dmac_check_len(chan, xt->sgl[0].size) ||
- !axi_dmac_check_len(chan, xt->numf))
+ xt->numf == 0)
return NULL;
if (xt->sgl[0].size + dst_icg > chan->max_length ||
xt->sgl[0].size + src_icg > chan->max_length)
^ permalink raw reply related
* [1/2] dma: axi-dmac: don't check the number of frames for alignment
From: Ardelean, Alexandru @ 2019-02-26 8:36 UTC (permalink / raw)
To: vkoul@kernel.org, Ardelean, Alexandru; +Cc: dmaengine@vger.kernel.org
On Tue, 2019-02-26 at 13:31 +0530, Vinod Koul wrote:
> [External]
>
>
> On 26-02-19, 07:14, Ardelean, Alexandru wrote:
> > On Mon, 2019-02-25 at 12:22 +0530, Vinod Koul wrote:
> > > [External]
> > >
> > >
> > > On 15-02-19, 11:17, Alexandru Ardelean wrote:
> > > > Fixes commit 0e3b67b348b8 ("dmaengine: Add support for the Analog
> > > > Devices
> > > > AXI-DMAC DMA controller")
> > >
> > > Do you mean to add a Fixes tag?
> >
> > Yep.
> > I'm terrible at this apparently. I'll read about how to do that
> > properly.
> > Other maintainers have complained about this as well [i.e. the fact
> > that I
> > didn't add proper Fixes tags ].
>
> So if it fixes a bug in original commit and should go immediately to
> next rc-X then fixes is mostly appropriate.. (also backporting to
> stable). In this case it doesnt seem so.
>
> Also canonical form is
>
> Fixes: abcdef : ("buggy patch")
>
> and this line should be before the s-o-b line..
I just found this in the submitting-patch-docs.
>
> > >
> > > > For 2D transfers, there is no requirement for Y_LENGTH to be
> > > > aligned
> > > > to the bus-width (or anything). X_LENGTH is required to be aligned
> > > > though.
> > > >
> > > > So, we shouldn't check that the number of frames is aligned.
> > >
> > > Does this fix a bug as indicated by Fixes tag?
> >
> > Yes
>
> well if it is aligned it shouldn't cause break right. Yes not having
> aligned helps the driver but seems to be correct the wrong
> interpretation/implementation.. right?
I'm preparing a V2 here.
2D transfers are typically used when DMA talks to video, where Y_LENGTH is
the number of rows, which don't need to be aligned.
I'll try to make the comment more helpful.
>
> --
> ~Vinod
^ permalink raw reply
* dma: axi-dmac: assign `copy_align` property
From: Vinod Koul @ 2019-02-26 8:03 UTC (permalink / raw)
To: Ardelean, Alexandru; +Cc: dmaengine@vger.kernel.org
On 26-02-19, 07:19, Ardelean, Alexandru wrote:
> On Mon, 2019-02-25 at 12:25 +0530, Vinod Koul wrote:
> > [External]
> >
> >
> > On 15-02-19, 13:02, Alexandru Ardelean wrote:
> > > The `copy_align` property is a generic property that describes
> > > alignment
> > > for DMA memcpy & sg ops.
> > > It serves mostly an informational purpose, and can be used in DMA
> > > tests, to
> > > pass the info to know what alignment to expect.
> >
> > This looks fine but fails to apply for me. When sending patches please
> > send against the tree you wish this patch to be applied to..
>
> Weird, I remember patching this into one of the brances from here:
> https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git/
>
> I forget which one [probably the `next` branch ?]
next one is typically fine.
^ permalink raw reply
* [2/2] dma: axi-dmac: report DMA_INTERLEAVE capability
From: Vinod Koul @ 2019-02-26 8:02 UTC (permalink / raw)
To: Ardelean, Alexandru; +Cc: dmaengine@vger.kernel.org, Bogdan, Dragos
On 26-02-19, 07:15, Ardelean, Alexandru wrote:
> On Mon, 2019-02-25 at 12:23 +0530, Vinod Koul wrote:
> > [External]
> >
> >
> > On 15-02-19, 11:17, Alexandru Ardelean wrote:
> > > From: Dragos Bogdan <dragos.bogdan@analog.com>
> > >
> > > Fixes commit 0e3b67b348b8 ("dmaengine: Add support for the Analog
> > > Devices
> > > AXI-DMAC DMA controller")
> >
> > Am not sire this is appropriate here..
> >
>
> Hmm, probably.
> I'm a bit vague if a device_prep_interleaved_dma() callback works fine [or
> is fine to have] without a DMA_INTERLEAVE flag in the caps. I did not dig
> too deep into the dmaengine.
>
> I can re-spin this without the Fixes stuff
Yes please and rebase on dmaengine-next
Thanks
^ permalink raw reply
* [1/2] dma: axi-dmac: don't check the number of frames for alignment
From: Vinod Koul @ 2019-02-26 8:01 UTC (permalink / raw)
To: Ardelean, Alexandru; +Cc: dmaengine@vger.kernel.org
On 26-02-19, 07:14, Ardelean, Alexandru wrote:
> On Mon, 2019-02-25 at 12:22 +0530, Vinod Koul wrote:
> > [External]
> >
> >
> > On 15-02-19, 11:17, Alexandru Ardelean wrote:
> > > Fixes commit 0e3b67b348b8 ("dmaengine: Add support for the Analog
> > > Devices
> > > AXI-DMAC DMA controller")
> >
> > Do you mean to add a Fixes tag?
>
> Yep.
> I'm terrible at this apparently. I'll read about how to do that properly.
> Other maintainers have complained about this as well [i.e. the fact that I
> didn't add proper Fixes tags ].
So if it fixes a bug in original commit and should go immediately to
next rc-X then fixes is mostly appropriate.. (also backporting to
stable). In this case it doesnt seem so.
Also canonical form is
Fixes: abcdef : ("buggy patch")
and this line should be before the s-o-b line..
> >
> > > For 2D transfers, there is no requirement for Y_LENGTH to be aligned
> > > to the bus-width (or anything). X_LENGTH is required to be aligned
> > > though.
> > >
> > > So, we shouldn't check that the number of frames is aligned.
> >
> > Does this fix a bug as indicated by Fixes tag?
>
> Yes
well if it is aligned it shouldn't cause break right. Yes not having
aligned helps the driver but seems to be correct the wrong
interpretation/implementation.. right?
^ permalink raw reply
* [V2] dmaengine: axi-dmac: report DMA_INTERLEAVE capability
From: Alexandru Ardelean @ 2019-02-26 7:35 UTC (permalink / raw)
To: dmaengine, vkoul; +Cc: Dragos Bogdan, Alexandru Ardelean
From: Dragos Bogdan <dragos.bogdan@analog.com>
The `device_prep_interleaved_dma()` callback is already present since the
driver was submitted initially.
This change adds the DMA_INTERLEAVE flag to the capability mask of AXI DMAC
driver.
Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/dma/dma-axi-dmac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
index 2c999113b989..b2039e60ae04 100644
--- a/drivers/dma/dma-axi-dmac.c
+++ b/drivers/dma/dma-axi-dmac.c
@@ -652,6 +652,7 @@ static int axi_dmac_probe(struct platform_device *pdev)
dma_dev = &dmac->dma_dev;
dma_cap_set(DMA_SLAVE, dma_dev->cap_mask);
dma_cap_set(DMA_CYCLIC, dma_dev->cap_mask);
+ dma_cap_set(DMA_INTERLEAVE, dma_dev->cap_mask);
dma_dev->device_free_chan_resources = axi_dmac_free_chan_resources;
dma_dev->device_tx_status = dma_cookie_status;
dma_dev->device_issue_pending = axi_dmac_issue_pending;
^ permalink raw reply related
* dma: axi-dmac: assign `copy_align` property
From: Ardelean, Alexandru @ 2019-02-26 7:19 UTC (permalink / raw)
To: vkoul@kernel.org; +Cc: dmaengine@vger.kernel.org
On Mon, 2019-02-25 at 12:25 +0530, Vinod Koul wrote:
> [External]
>
>
> On 15-02-19, 13:02, Alexandru Ardelean wrote:
> > The `copy_align` property is a generic property that describes
> > alignment
> > for DMA memcpy & sg ops.
> > It serves mostly an informational purpose, and can be used in DMA
> > tests, to
> > pass the info to know what alignment to expect.
>
> This looks fine but fails to apply for me. When sending patches please
> send against the tree you wish this patch to be applied to..
Weird, I remember patching this into one of the brances from here:
https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git/
I forget which one [probably the `next` branch ?]
I'll re-visit this.
>
> Also please fix the subsystem tag..
Ack
>
> --
> ~Vinod
^ permalink raw reply
* [2/2] dma: axi-dmac: report DMA_INTERLEAVE capability
From: Ardelean, Alexandru @ 2019-02-26 7:15 UTC (permalink / raw)
To: vkoul@kernel.org; +Cc: dmaengine@vger.kernel.org, Bogdan, Dragos
On Mon, 2019-02-25 at 12:23 +0530, Vinod Koul wrote:
> [External]
>
>
> On 15-02-19, 11:17, Alexandru Ardelean wrote:
> > From: Dragos Bogdan <dragos.bogdan@analog.com>
> >
> > Fixes commit 0e3b67b348b8 ("dmaengine: Add support for the Analog
> > Devices
> > AXI-DMAC DMA controller")
>
> Am not sire this is appropriate here..
>
Hmm, probably.
I'm a bit vague if a device_prep_interleaved_dma() callback works fine [or
is fine to have] without a DMA_INTERLEAVE flag in the caps. I did not dig
too deep into the dmaengine.
I can re-spin this without the Fixes stuff
> >
> > The `device_prep_interleaved_dma()` callback is already present since
> > the
> > driver was submitted initially.
> > This change adds the DMA_INTERLEAVE capability to the capability mask
> > of
> > the DMA engine.
> >
> > Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/dma/dma-axi-dmac.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> > index 2c999113b989..b2039e60ae04 100644
> > --- a/drivers/dma/dma-axi-dmac.c
> > +++ b/drivers/dma/dma-axi-dmac.c
> > @@ -652,6 +652,7 @@ static int axi_dmac_probe(struct platform_device
> > *pdev)
> > dma_dev = &dmac->dma_dev;
> > dma_cap_set(DMA_SLAVE, dma_dev->cap_mask);
> > dma_cap_set(DMA_CYCLIC, dma_dev->cap_mask);
> > + dma_cap_set(DMA_INTERLEAVE, dma_dev->cap_mask);
> > dma_dev->device_free_chan_resources =
> > axi_dmac_free_chan_resources;
> > dma_dev->device_tx_status = dma_cookie_status;
> > dma_dev->device_issue_pending = axi_dmac_issue_pending;
> > --
> > 2.17.1
>
> --
> ~Vinod
^ permalink raw reply
* [1/2] dma: axi-dmac: don't check the number of frames for alignment
From: Ardelean, Alexandru @ 2019-02-26 7:14 UTC (permalink / raw)
To: vkoul@kernel.org; +Cc: dmaengine@vger.kernel.org
On Mon, 2019-02-25 at 12:22 +0530, Vinod Koul wrote:
> [External]
>
>
> On 15-02-19, 11:17, Alexandru Ardelean wrote:
> > Fixes commit 0e3b67b348b8 ("dmaengine: Add support for the Analog
> > Devices
> > AXI-DMAC DMA controller")
>
> Do you mean to add a Fixes tag?
Yep.
I'm terrible at this apparently. I'll read about how to do that properly.
Other maintainers have complained about this as well [i.e. the fact that I
didn't add proper Fixes tags ].
>
> > For 2D transfers, there is no requirement for Y_LENGTH to be aligned
> > to the bus-width (or anything). X_LENGTH is required to be aligned
> > though.
> >
> > So, we shouldn't check that the number of frames is aligned.
>
> Does this fix a bug as indicated by Fixes tag?
Yes
>
> Lastly, it is dmaengine: xxx not dma: xxx Please fix that.
Ack
Will fix
>
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/dma/dma-axi-dmac.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> > index ffc0adc2f6ce..2c999113b989 100644
> > --- a/drivers/dma/dma-axi-dmac.c
> > +++ b/drivers/dma/dma-axi-dmac.c
> > @@ -485,7 +485,7 @@ static struct dma_async_tx_descriptor
> > *axi_dmac_prep_interleaved(
> >
> > if (chan->hw_2d) {
> > if (!axi_dmac_check_len(chan, xt->sgl[0].size) ||
> > - !axi_dmac_check_len(chan, xt->numf))
> > + xt->numf == 0)
> > return NULL;
> > if (xt->sgl[0].size + dst_icg > chan->max_length ||
> > xt->sgl[0].size + src_icg > chan->max_length)
> > --
> > 2.17.1
>
> --
> ~Vinod
^ permalink raw reply
* [V2,1/3] dmaengine: dmatest: wrap src & dst data into a struct
From: Vinod Koul @ 2019-02-25 17:44 UTC (permalink / raw)
To: Alexandru Ardelean; +Cc: dmaengine
On 12-02-19, 17:11, Alexandru Ardelean wrote:
> This change wraps the data for the source & destination buffers into a
> `struct dmatest_data`. The rename patterns are:
> * src_cnt -> src->cnt
> * dst_cnt -> dst->cnt
> * src_off -> src->off
> * dst_off -> dst->off
> * thread->srcs -> src->aligned
> * thread->usrcs -> src->raw
> * thread->dsts -> dst->aligned
> * thread->udsts -> dst->raw
>
> The intent is to make a function that moves duplicate parts of the code
> into common alloc & free functions, which will unclutter the
> `dmatest_func()` function.
Applied all 3, thanks
^ permalink raw reply
* [v6,2/3] dmaengine: imx-sdma: add a test for imx8mq multi sdma devices
From: Daniel Baluta @ 2019-02-25 13:31 UTC (permalink / raw)
To: Angus Ainslie (Purism)
Cc: angus.ainslie, Vinod Koul, dmaengine, NXP Linux Team,
Pengutronix Kernel Team, linux-arm-kernel,
Linux Kernel Mailing List, Lucas Stach
On Mon, Jan 28, 2019 at 6:04 PM Angus Ainslie (Purism) <angus@akkea.ca> wrote:
>
> On i.mx8mq, there are two sdma instances, and the common dma framework
> will get a channel dynamically from any available sdma instance whether
> it's the first sdma device or the second sdma device. Some IPs like
> SAI only work with sdma2 not sdma1. To make sure the sdma channel is from
> the correct sdma device, use the node pointer to match.
>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Thanks Angus for the patch!
Tested-by: Daniel Baluta <daniel.baluta@nxp.com>
> ---
> drivers/dma/imx-sdma.c | 6 ++++++
> include/linux/platform_data/dma-imx.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 757fad2fbfae..d2fae53be689 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -1914,11 +1914,16 @@ static int sdma_init(struct sdma_engine *sdma)
> static bool sdma_filter_fn(struct dma_chan *chan, void *fn_param)
> {
> struct sdma_channel *sdmac = to_sdma_chan(chan);
> + struct sdma_engine *sdma = sdmac->sdma;
> struct imx_dma_data *data = fn_param;
>
> if (!imx_dma_is_general_purpose(chan))
> return false;
>
> + /* return false if it's not the right device */
> + if (sdma->dev->of_node != data->of_node)
> + return false;
> +
> sdmac->data = *data;
> chan->private = &sdmac->data;
>
> @@ -1946,6 +1951,7 @@ static struct dma_chan *sdma_xlate(struct of_phandle_args *dma_spec,
> * be set to sdmac->event_id1.
> */
> data.dma_request2 = 0;
> + data.of_node = ofdma->of_node;
>
> return dma_request_channel(mask, sdma_filter_fn, &data);
> }
> diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
> index 7d964e787299..9daea8d42a10 100644
> --- a/include/linux/platform_data/dma-imx.h
> +++ b/include/linux/platform_data/dma-imx.h
> @@ -55,6 +55,7 @@ struct imx_dma_data {
> int dma_request2; /* secondary DMA request line */
> enum sdma_peripheral_type peripheral_type;
> int priority;
> + struct device_node *of_node;
> };
>
> static inline int imx_dma_is_ipu(struct dma_chan *chan)
> --
> 2.17.1
>
^ permalink raw reply
* dma: axi-dmac: Split too large segments
From: Vinod Koul @ 2019-02-25 6:56 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Ardelean, Alexandru, lkp@intel.com, kbuild-all@01.org,
dmaengine@vger.kernel.org
On 18-02-19, 08:34, Lars-Peter Clausen wrote:
> On 2/18/19 8:28 AM, Ardelean, Alexandru wrote:
> > On Sat, 2019-02-16 at 17:03 +0800, kbuild test robot wrote:
> >>
> >
> > My bad here.
> > I took this patch from our kernel tree and sent it.
> > I assumed it works, since it works in our tree.
> > I'll take a look and see about the order of patches, and which one(s)
> > need(s) to be sent before this one
>
> https://github.com/analogdevicesinc/linux/commit/414a555896b2abca3518c3c878f21e7b1ea95904#diff-b5b2fd5430b4f9aff1ae97bae60dd5c5
>
> That patch was sent upstream, not sure why it was never merged.
>
> But if necessary you can also re-write this patch to not rely on the
> other one.
Or send this patch upstream if you find it very useful :)
^ permalink raw reply
* dma: axi-dmac: assign `copy_align` property
From: Vinod Koul @ 2019-02-25 6:55 UTC (permalink / raw)
To: Alexandru Ardelean; +Cc: dmaengine
On 15-02-19, 13:02, Alexandru Ardelean wrote:
> The `copy_align` property is a generic property that describes alignment
> for DMA memcpy & sg ops.
> It serves mostly an informational purpose, and can be used in DMA tests, to
> pass the info to know what alignment to expect.
This looks fine but fails to apply for me. When sending patches please
send against the tree you wish this patch to be applied to..
Also please fix the subsystem tag..
^ permalink raw reply
* [2/2] dma: axi-dmac: report DMA_INTERLEAVE capability
From: Vinod Koul @ 2019-02-25 6:53 UTC (permalink / raw)
To: Alexandru Ardelean; +Cc: dmaengine, Dragos Bogdan
On 15-02-19, 11:17, Alexandru Ardelean wrote:
> From: Dragos Bogdan <dragos.bogdan@analog.com>
>
> Fixes commit 0e3b67b348b8 ("dmaengine: Add support for the Analog Devices
> AXI-DMAC DMA controller")
Am not sire this is appropriate here..
>
> The `device_prep_interleaved_dma()` callback is already present since the
> driver was submitted initially.
> This change adds the DMA_INTERLEAVE capability to the capability mask of
> the DMA engine.
>
> Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> drivers/dma/dma-axi-dmac.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> index 2c999113b989..b2039e60ae04 100644
> --- a/drivers/dma/dma-axi-dmac.c
> +++ b/drivers/dma/dma-axi-dmac.c
> @@ -652,6 +652,7 @@ static int axi_dmac_probe(struct platform_device *pdev)
> dma_dev = &dmac->dma_dev;
> dma_cap_set(DMA_SLAVE, dma_dev->cap_mask);
> dma_cap_set(DMA_CYCLIC, dma_dev->cap_mask);
> + dma_cap_set(DMA_INTERLEAVE, dma_dev->cap_mask);
> dma_dev->device_free_chan_resources = axi_dmac_free_chan_resources;
> dma_dev->device_tx_status = dma_cookie_status;
> dma_dev->device_issue_pending = axi_dmac_issue_pending;
> --
> 2.17.1
^ permalink raw reply
* [1/2] dma: axi-dmac: don't check the number of frames for alignment
From: Vinod Koul @ 2019-02-25 6:52 UTC (permalink / raw)
To: Alexandru Ardelean; +Cc: dmaengine
On 15-02-19, 11:17, Alexandru Ardelean wrote:
> Fixes commit 0e3b67b348b8 ("dmaengine: Add support for the Analog Devices
> AXI-DMAC DMA controller")
Do you mean to add a Fixes tag?
> For 2D transfers, there is no requirement for Y_LENGTH to be aligned
> to the bus-width (or anything). X_LENGTH is required to be aligned
> though.
>
> So, we shouldn't check that the number of frames is aligned.
Does this fix a bug as indicated by Fixes tag?
Lastly, it is dmaengine: xxx not dma: xxx Please fix that.
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> drivers/dma/dma-axi-dmac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> index ffc0adc2f6ce..2c999113b989 100644
> --- a/drivers/dma/dma-axi-dmac.c
> +++ b/drivers/dma/dma-axi-dmac.c
> @@ -485,7 +485,7 @@ static struct dma_async_tx_descriptor *axi_dmac_prep_interleaved(
>
> if (chan->hw_2d) {
> if (!axi_dmac_check_len(chan, xt->sgl[0].size) ||
> - !axi_dmac_check_len(chan, xt->numf))
> + xt->numf == 0)
> return NULL;
> if (xt->sgl[0].size + dst_icg > chan->max_length ||
> xt->sgl[0].size + src_icg > chan->max_length)
> --
> 2.17.1
^ permalink raw reply
* [v2,1/2] dt-bindings: dmaengine: sprd: Change channel id to slave id for DMA cell specifier
From: Vinod Koul @ 2019-02-25 6:41 UTC (permalink / raw)
To: Baolin Wang
Cc: robh+dt, mark.rutland, arnd, orsonzhai, zhang.lyra,
dan.j.williams, devicetree, linux-kernel, dmaengine, eric.long,
broonie
On 21-02-19, 13:34, Baolin Wang wrote:
> For Spreadtrum DMA engine, all channels are equal, which means slave can
> request any channels with setting a unique slave id to trigger this channel.
>
> Thus we can remove the channel id from device tree to assign the channel
> dynamically, moreover we should add the slave id in device tree.
Applied, thanks
^ permalink raw reply
* [v2,1/2] dt-bindings: dmaengine: sprd: Change channel id to slave id for DMA cell specifier
From: Rob Herring @ 2019-02-22 20:42 UTC (permalink / raw)
To: Baolin Wang
Cc: vkoul, robh+dt, mark.rutland, arnd, orsonzhai, zhang.lyra,
dan.j.williams, devicetree, linux-kernel, dmaengine, eric.long,
broonie
On Thu, 21 Feb 2019 13:34:40 +0800, Baolin Wang wrote:
> For Spreadtrum DMA engine, all channels are equal, which means slave can
> request any channels with setting a unique slave id to trigger this channel.
>
> Thus we can remove the channel id from device tree to assign the channel
> dynamically, moreover we should add the slave id in device tree.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> ---
> Changes from v1:
> - Remove channel id from DT.
> ---
> Documentation/devicetree/bindings/dma/sprd-dma.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [3/3] imx8mq.dtsi: add the sdma nodes
From: Daniel Baluta @ 2019-02-22 19:44 UTC (permalink / raw)
To: Angus Ainslie (Purism)
Cc: Vinod Koul, dmaengine, NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel, Linux Kernel Mailing List, Daniel Baluta,
Shawn Guo
Hi Angus,
What is the status of this patch? Most likely this should go through
Shwan's tree.
I noticed that I have also sent a similar patch to Shawn:
https://www.spinics.net/lists/arm-kernel/msg708424.html
So, lets coordinate and work better on this.
I am now preparing another series where I add SAI nodes and enable WM
codec on imx8MQ.
If you don't mind I will pick your relevant changes from this patch
and add them to my series, then send them to Shawn.
thanks,
Daniel.
On Sun, Jan 20, 2019 at 4:05 AM Angus Ainslie (Purism) <angus@akkea.ca> wrote:
>
> Add the sdma nodes to the base devicetree for the imx8mq
>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 +++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index c0402375e7c1..0b9a9b5ae7b7 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -336,6 +336,19 @@
> clocks = <&clk IMX8MQ_CLK_WDOG3_ROOT>;
> status = "disabled";
> };
> +
> + sdma2: sdma@302c0000 {
> + compatible = "fsl,imx8mq-sdma", "fsl,imx7d-sdma";
> + reg = <0x302c0000 0x10000>;
> + interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MQ_CLK_SDMA2_ROOT>,
> + <&clk IMX8MQ_CLK_SDMA2_ROOT>;
> + clock-names = "ipg", "ahb";
> + #dma-cells = <3>;
> + fsl,sdma-ram-script-name = "imx/sdma/sdma-imx7d.bin";
> + fsl,ratio-1-1;
> + status = "disabled";
> + };
> };
>
> bus@30400000 { /* AIPS2 */
> @@ -370,6 +383,8 @@
> clocks = <&clk IMX8MQ_CLK_UART3_ROOT>,
> <&clk IMX8MQ_CLK_UART3_ROOT>;
> clock-names = "ipg", "per";
> + dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
> + dma-names = "rx", "tx";
> status = "disabled";
> };
>
> @@ -381,6 +396,8 @@
> clocks = <&clk IMX8MQ_CLK_UART2_ROOT>,
> <&clk IMX8MQ_CLK_UART2_ROOT>;
> clock-names = "ipg", "per";
> + dmas = <&sdma1 24 4 0>, <&sdma1 25 4 0>;
> + dma-names = "rx", "tx";
> status = "disabled";
> };
>
> @@ -432,6 +449,8 @@
> clocks = <&clk IMX8MQ_CLK_UART4_ROOT>,
> <&clk IMX8MQ_CLK_UART4_ROOT>;
> clock-names = "ipg", "per";
> + dmas = <&sdma1 28 4 0>, <&sdma1 29 4 0>;
> + dma-names = "rx", "tx";
> status = "disabled";
> };
>
> @@ -465,6 +484,18 @@
> status = "disabled";
> };
>
> + sdma1: sdma@30bd0000 {
> + compatible = "fsl,imx8mq-sdma", "fsl,imx7d-sdma";
> + reg = <0x30bd0000 0x10000>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MQ_CLK_SDMA1_ROOT>,
> + <&clk IMX8MQ_CLK_SDMA1_ROOT>;
> + clock-names = "ipg", "ahb";
> + #dma-cells = <3>;
> + fsl,sdma-ram-script-name = "imx/sdma/sdma-imx7d.bin";
> + status = "disabled";
> + };
> +
> fec1: ethernet@30be0000 {
> compatible = "fsl,imx8mq-fec", "fsl,imx6sx-fec";
> reg = <0x30be0000 0x10000>;
> --
> 2.17.1
>
^ permalink raw reply
* [4/6] dma: tegra: add accurate reporting of dma state
From: Dmitry Osipenko @ 2019-02-22 18:10 UTC (permalink / raw)
To: Ben Dooks; +Cc: dan.j.williams, vkoul, ldewangan, dmaengine, linux-tegra
22.02.2019 20:23, Ben Dooks пишет:
> On 21/02/2019 13:02, Dmitry Osipenko wrote:
>> 21.02.2019 13:06, Ben Dooks пишет:
>>> On 21/02/2019 00:41, Dmitry Osipenko wrote:
>>>> 31.10.2018 19:03, Ben Dooks пишет:
>>>>> The tx_status callback does not report the state of the transfer
>>>>> beyond complete segments. This causes problems with users such as
>>>>> ALSA when applications want to know accurately how much data has
>>>>> been moved.
>>>>>
>>>>> This patch addes a function tegra_dma_update_residual() to query
>>>>> the hardware and modify the residual information accordinly. It
>>>>> takes into account any hardware issues when trying to read the
>>>>> state, such as delays between finishing a buffer and signalling
>>>>> the interrupt.
>>>>>
>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>>
>>>> Hello Ben,
>>>>
>>>> Do you have any plans to submit a new version of this patch? It's really useful and fixes a real problem with the audio playback. I could help with finalizing the patch and could submit it for you if you happened to lost the interest.
>>>
>>> Personally I think the original version was fine. It has been tested
>>> and returns fairly quickly (I am not a fan of just adding more delay in)
>>>
>>> My notes say the condition doesn't last for long and the loop tends
>>> to terminate within 2 runs.
>>>
>>
>> Okay, so are you going to re-send the patch? We can back to the review after, you need at least to re-send because this series has been outdated. Also please take a look and feel free to use as-is the reduced variant of yours patch that I was carrying and testing for months now [0], it works great.
>>
>> [0] https://github.com/grate-driver/linux/commit/ab8a67a6f47185f265f16749b55df214aaaefad4
>>
>
> I can try rebasing, but I have not got a lot of time to do any testing
> at the moment. I agree I should have remembered to chase this stuff up
> earlier.
No problems, thank you. I'll help with the testing. And I could rebase the patch and send it out for you if will be needed, please just let me know if you're okay with it.
^ permalink raw reply
* [4/6] dma: tegra: add accurate reporting of dma state
From: Ben Dooks @ 2019-02-22 17:23 UTC (permalink / raw)
To: Dmitry Osipenko; +Cc: dan.j.williams, vkoul, ldewangan, dmaengine, linux-tegra
On 21/02/2019 13:02, Dmitry Osipenko wrote:
> 21.02.2019 13:06, Ben Dooks пишет:
>> On 21/02/2019 00:41, Dmitry Osipenko wrote:
>>> 31.10.2018 19:03, Ben Dooks пишет:
>>>> The tx_status callback does not report the state of the transfer
>>>> beyond complete segments. This causes problems with users such as
>>>> ALSA when applications want to know accurately how much data has
>>>> been moved.
>>>>
>>>> This patch addes a function tegra_dma_update_residual() to query
>>>> the hardware and modify the residual information accordinly. It
>>>> takes into account any hardware issues when trying to read the
>>>> state, such as delays between finishing a buffer and signalling
>>>> the interrupt.
>>>>
>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>
>>> Hello Ben,
>>>
>>> Do you have any plans to submit a new version of this patch? It's really useful and fixes a real problem with the audio playback. I could help with finalizing the patch and could submit it for you if you happened to lost the interest.
>>
>> Personally I think the original version was fine. It has been tested
>> and returns fairly quickly (I am not a fan of just adding more delay in)
>>
>> My notes say the condition doesn't last for long and the loop tends
>> to terminate within 2 runs.
>>
>
> Okay, so are you going to re-send the patch? We can back to the review after, you need at least to re-send because this series has been outdated. Also please take a look and feel free to use as-is the reduced variant of yours patch that I was carrying and testing for months now [0], it works great.
>
> [0] https://github.com/grate-driver/linux/commit/ab8a67a6f47185f265f16749b55df214aaaefad4
>
I can try rebasing, but I have not got a lot of time to do any testing
at the moment. I agree I should have remembered to chase this stuff up
earlier.
^ permalink raw reply
* [4/4] dmaengine: ioatdma: support latency tolerance report (LTR) for v3.4
From: Dave Jiang @ 2019-02-22 17:00 UTC (permalink / raw)
To: vkoul; +Cc: dmaengine
IOATDMA 3.4 supports PCIe LTR mechanism. The registers are non-standard
PCIe LTR support. This needs to be setup in order to not suffer performance
impact and provide proper power management. The channel is set to active
when it is allocated, and to passive when it's freed.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
---
drivers/dma/ioat/init.c | 27 +++++++++++++++++++++++++++
drivers/dma/ioat/registers.h | 14 ++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c
index 020bcdecb3fb..d41dc9a9ff68 100644
--- a/drivers/dma/ioat/init.c
+++ b/drivers/dma/ioat/init.c
@@ -638,6 +638,11 @@ static void ioat_free_chan_resources(struct dma_chan *c)
ioat_stop(ioat_chan);
ioat_reset_hw(ioat_chan);
+ /* Put LTR to idle */
+ if (ioat_dma->version >= IOAT_VER_3_4)
+ writeb(IOAT_CHAN_LTR_SWSEL_IDLE,
+ ioat_chan->reg_base + IOAT_CHAN_LTR_SWSEL_OFFSET);
+
spin_lock_bh(&ioat_chan->cleanup_lock);
spin_lock_bh(&ioat_chan->prep_lock);
descs = ioat_ring_space(ioat_chan);
@@ -727,6 +732,28 @@ static int ioat_alloc_chan_resources(struct dma_chan *c)
spin_unlock_bh(&ioat_chan->prep_lock);
spin_unlock_bh(&ioat_chan->cleanup_lock);
+ /* Setting up LTR values for 3.4 or later */
+ if (ioat_chan->ioat_dma->version >= IOAT_VER_3_4) {
+ u32 lat_val;
+
+ lat_val = IOAT_CHAN_LTR_ACTIVE_SNVAL |
+ IOAT_CHAN_LTR_ACTIVE_SNLATSCALE |
+ IOAT_CHAN_LTR_ACTIVE_SNREQMNT;
+ writel(lat_val, ioat_chan->reg_base +
+ IOAT_CHAN_LTR_ACTIVE_OFFSET);
+
+ lat_val = IOAT_CHAN_LTR_IDLE_SNVAL |
+ IOAT_CHAN_LTR_IDLE_SNLATSCALE |
+ IOAT_CHAN_LTR_IDLE_SNREQMNT;
+ writel(lat_val, ioat_chan->reg_base +
+ IOAT_CHAN_LTR_IDLE_OFFSET);
+
+ /* Select to active */
+ writeb(IOAT_CHAN_LTR_SWSEL_ACTIVE,
+ ioat_chan->reg_base +
+ IOAT_CHAN_LTR_SWSEL_OFFSET);
+ }
+
ioat_start_null_desc(ioat_chan);
/* check that we got off the ground */
diff --git a/drivers/dma/ioat/registers.h b/drivers/dma/ioat/registers.h
index 2b517d6db5fd..99c1c24d465d 100644
--- a/drivers/dma/ioat/registers.h
+++ b/drivers/dma/ioat/registers.h
@@ -253,4 +253,18 @@
#define IOAT_CHAN_DRS_EN 0x0100
#define IOAT_CHAN_DRS_AUTOWRAP 0x0200
+#define IOAT_CHAN_LTR_SWSEL_OFFSET 0xBC
+#define IOAT_CHAN_LTR_SWSEL_ACTIVE 0x0
+#define IOAT_CHAN_LTR_SWSEL_IDLE 0x1
+
+#define IOAT_CHAN_LTR_ACTIVE_OFFSET 0xC0
+#define IOAT_CHAN_LTR_ACTIVE_SNVAL 0x0000 /* 0 us */
+#define IOAT_CHAN_LTR_ACTIVE_SNLATSCALE 0x0800 /* 1us scale */
+#define IOAT_CHAN_LTR_ACTIVE_SNREQMNT 0x8000 /* snoop req enable */
+
+#define IOAT_CHAN_LTR_IDLE_OFFSET 0xC4
+#define IOAT_CHAN_LTR_IDLE_SNVAL 0x0258 /* 600 us */
+#define IOAT_CHAN_LTR_IDLE_SNLATSCALE 0x0800 /* 1us scale */
+#define IOAT_CHAN_LTR_IDLE_SNREQMNT 0x8000 /* snoop req enable */
+
#endif /* _IOAT_REGISTERS_H_ */
^ permalink raw reply related
* [3/4] dmaengine: ioatdma: add descriptor pre-fetch support for v3.4
From: Dave Jiang @ 2019-02-22 17:00 UTC (permalink / raw)
To: vkoul; +Cc: dmaengine
Adding support for new feature on ioatdma 3.4 hardware that provides
descriptor pre-fetching in order to reduce small DMA latencies.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
---
drivers/dma/ioat/dma.c | 12 ++++++++++++
drivers/dma/ioat/init.c | 8 ++++++--
drivers/dma/ioat/registers.h | 10 ++++++++++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c
index 23fb2fa04000..f373a139e0c3 100644
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -372,6 +372,7 @@ struct ioat_ring_ent **
ioat_alloc_ring(struct dma_chan *c, int order, gfp_t flags)
{
struct ioatdma_chan *ioat_chan = to_ioat_chan(c);
+ struct ioatdma_device *ioat_dma = ioat_chan->ioat_dma;
struct ioat_ring_ent **ring;
int total_descs = 1 << order;
int i, chunks;
@@ -437,6 +438,17 @@ ioat_alloc_ring(struct dma_chan *c, int order, gfp_t flags)
}
ring[i]->hw->next = ring[0]->txd.phys;
+ /* setup descriptor pre-fetching for v3.4 */
+ if (ioat_dma->cap & IOAT_CAP_DPS) {
+ u16 drsctl = IOAT_CHAN_DRSZ_2MB | IOAT_CHAN_DRS_EN;
+
+ if (chunks == 1)
+ drsctl |= IOAT_CHAN_DRS_AUTOWRAP;
+
+ writew(drsctl, ioat_chan->reg_base + IOAT_CHAN_DRSCTL_OFFSET);
+
+ }
+
return ring;
}
diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c
index 58dd1bfd3edd..020bcdecb3fb 100644
--- a/drivers/dma/ioat/init.c
+++ b/drivers/dma/ioat/init.c
@@ -138,10 +138,10 @@ static int ioat3_dma_self_test(struct ioatdma_device *ioat_dma);
static int ioat_dca_enabled = 1;
module_param(ioat_dca_enabled, int, 0644);
MODULE_PARM_DESC(ioat_dca_enabled, "control support of dca service (default: 1)");
-int ioat_pending_level = 4;
+int ioat_pending_level = 7;
module_param(ioat_pending_level, int, 0644);
MODULE_PARM_DESC(ioat_pending_level,
- "high-water mark for pushing ioat descriptors (default: 4)");
+ "high-water mark for pushing ioat descriptors (default: 7)");
static char ioat_interrupt_style[32] = "msix";
module_param_string(ioat_interrupt_style, ioat_interrupt_style,
sizeof(ioat_interrupt_style), 0644);
@@ -1188,6 +1188,10 @@ static int ioat3_dma_probe(struct ioatdma_device *ioat_dma, int dca)
if (err)
return err;
+ if (ioat_dma->cap & IOAT_CAP_DPS)
+ writeb(ioat_pending_level + 1,
+ ioat_dma->reg_base + IOAT_PREFETCH_LIMIT_OFFSET);
+
return 0;
}
diff --git a/drivers/dma/ioat/registers.h b/drivers/dma/ioat/registers.h
index 2f3bbc88ff2a..2b517d6db5fd 100644
--- a/drivers/dma/ioat/registers.h
+++ b/drivers/dma/ioat/registers.h
@@ -84,6 +84,9 @@
#define IOAT_CAP_PQ 0x00000200
#define IOAT_CAP_DWBES 0x00002000
#define IOAT_CAP_RAID16SS 0x00020000
+#define IOAT_CAP_DPS 0x00800000
+
+#define IOAT_PREFETCH_LIMIT_OFFSET 0x4C /* CHWPREFLMT */
#define IOAT_CHANNEL_MMIO_SIZE 0x80 /* Each Channel MMIO space is this size */
@@ -243,4 +246,11 @@
#define IOAT_CHANERR_MASK_OFFSET 0x2C /* 32-bit Channel Error Register */
+#define IOAT_CHAN_DRSCTL_OFFSET 0xB6
+#define IOAT_CHAN_DRSZ_4KB 0x0000
+#define IOAT_CHAN_DRSZ_8KB 0x0001
+#define IOAT_CHAN_DRSZ_2MB 0x0009
+#define IOAT_CHAN_DRS_EN 0x0100
+#define IOAT_CHAN_DRS_AUTOWRAP 0x0200
+
#endif /* _IOAT_REGISTERS_H_ */
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox