Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 4 Nov 2022 18:52:31 +0530
From:   Vinod Koul <vkoul@kernel.org>
To:     Tudor Ambarus <tudor.ambarus@microchip.com>
Cc:     peda@axentia.se, du@axentia.se, maciej.sosnowski@intel.com,
        nicolas.ferre@microchip.com, mripard@kernel.org,
        torfl6749@gmail.com, linux-kernel@vger.kernel.org,
        dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 00/32] dmaengine: at_hdmac: Fix concurrency bugs and
 then convert to virt-dma
Message-ID: <Y2USF24O90/dLKz7@matsya>
References: <20221025090306.297886-1-tudor.ambarus@microchip.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221025090306.297886-1-tudor.ambarus@microchip.com>
Precedence: bulk

On 25-10-22, 12:02, Tudor Ambarus wrote:
> v2:
> - reorder patches so that fixes come first -> easier to backport to
> stable kernels.
> - drop the devm_request_irq() patch as we had to disable the irq anyway
> in remove() in order to avoid spurios IRQs. Using devm variant brings no
> palpable benefit.
> - reword pm_ptr commit message
> 
> 
> at_hdmac driver had poor list handling and concurrency bugs.
> We experienced calling of the completion call twice for the
> same descriptor. Peter Rosin encountered the same while
> reporting a different bug:
> https://lore.kernel.org/lkml/13c6c9a2-6db5-c3bf-349b-4c127ad3496a@axentia.se/
> 
> Two sets of tests were performed:
> 1/ tested just the fixes, to make sure everything is fine and the
> concurrency bugs are squashed even without the conversion to virt-dma.
> All went fine.
> 2/ tested the entire series including the conversion the virt-dma
> All went fine.
> 
> I tested NAND (prep_dma_memcpy), MMC (prep_dma_slave_sg),
> usart (cyclic mode), dmatest (memcpy, memset).
> With the conversion to virt-dma I replaced the election of a new transfer
> in the tasklet with the election of the new transfer in the interrupt
> handler. We should have a shorter idle window as we remove the scheduling
> latency of the tasklet. Using mtd_speedtest showed similar performances
> when using NAND with DMA. That could be because of using a low timming
> mode on NAND.

This does not apply on dmaengine-fixes, can you please rebase and resend

-- 
~Vinod