On Tue, Jul 18, 2017 at 5:58 PM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
> On Mon, Jul 10, 2017 at 01:53:43PM -0700, John Stultz wrote:
>> From: Antonio Borneo <borneo.antonio@xxxxxxxxx>
>>
>> Commit 36387a2b1f62b5c087c5fe6f0f7b23b94f722ad7 ("k3dma: Fix
>> memory handling in preparation for cyclic mode") broke the
>> logic around ds_run/ds_done in case of non-cyclic DMA.
>>
>> This went unnoticed as the only user of k3dma was the i2s
>> audio driver, but with a patch set to enable dma on SPI,
>> the issue cropped up.
>>
>> This patch resolves the issue by reverting part of the
>> problematic commit.
>
> Can you explain the fix here, how reverting helps around with that?
> Right now am not able to comprehend the fix on this..
>
Hi Vinod,
thanks for your review.
The structure of the driver k3dma seams inspired to zx_dma that uses
the same ds_run/ds_done method.
This driver k3dma was already working fine for non-cyclic use cases, like SPI.
While preparing support for cyclic mode, the commit above removed some
assignment to NULL for ds_run/ds_done at the end of the non-cyclic DMA
transfer. As result, only the first non-cyclic DMA transfer completes
successfully, the following non-cyclic DMA transfer hangs (plus it
triggers one WARN_ON() because of the missing NULL initialization).
The main target of this patch is to re-add the NULL assignments.
>> This patch has been tested to ensure both audio playback and SPI
>> works fine using DMA and that no memory leak is present.
>>
>> Cc: Vinod Koul <vinod.koul@xxxxxxxxx>
>> Cc: Dan Williams <dan.j.williams@xxxxxxxxx>
>> Cc: Zhangfei Gao <zhangfei.gao@xxxxxxxxxx>
>> Cc: dmaengine@xxxxxxxxxxxxxxx
>> Signed-off-by: Antonio Borneo <borneo.antonio@xxxxxxxxx>
>> [jstultz: Expanded commit message a bit]
>> Signed-off-by: John Stultz <john.stultz@xxxxxxxxxx>
>> ---
>> drivers/dma/k3dma.c | 12 ++++--------
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
>> index 01e25c6..01d2a75 100644
>> --- a/drivers/dma/k3dma.c
>> +++ b/drivers/dma/k3dma.c
>> @@ -223,7 +223,6 @@ static irqreturn_t k3_dma_int_handler(int irq, void *dev_id)
>> if (c && (tc1 & BIT(i))) {
>> spin_lock_irqsave(&c->vc.lock, flags);
>> vchan_cookie_complete(&p->ds_run->vd);
>> - WARN_ON_ONCE(p->ds_done);
>> p->ds_done = p->ds_run;
>> p->ds_run = NULL;
>> spin_unlock_irqrestore(&c->vc.lock, flags);
>> @@ -274,13 +273,14 @@ static int k3_dma_start_txd(struct k3_dma_chan *c)
>> */
>> list_del(&ds->vd.node);
>>
>> - WARN_ON_ONCE(c->phy->ds_run);
>> - WARN_ON_ONCE(c->phy->ds_done);
>
> Not sure why WARN_ON should be removed?
The commit above added them. Now that the logic on ds_run/ds_done is
fixed, I do not see reason for them anymore.
Best Regards
Antonio
>
>> c->phy->ds_run = ds;
>> + c->phy->ds_done = NULL;
>> /* start dma */
>> k3_dma_set_desc(c->phy, &ds->desc_hw[0]);
>> return 0;
>> }
>> + c->phy->ds_run = NULL;
>> + c->phy->ds_done = NULL;
>> return -EAGAIN;
>> }
>>
>> @@ -722,11 +722,7 @@ static int k3_dma_terminate_all(struct dma_chan *chan)
>> k3_dma_free_desc(&p->ds_run->vd);
>> p->ds_run = NULL;
>> }
>> - if (p->ds_done) {
>> - k3_dma_free_desc(&p->ds_done->vd);
>> - p->ds_done = NULL;
>> - }
>> -
>> + p->ds_done = NULL;
>> }
>> spin_unlock_irqrestore(&c->vc.lock, flags);
>> vchan_dma_desc_free_list(&c->vc, &head);
>> --
>> 2.7.4
>>
>
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
