From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 85E893F4124; Wed, 13 May 2026 13:35:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778679303; cv=none; b=MsGJT8G1jUJz/h7vZiOOgqXy3IntPv2jBoZPNk5xAO4bpYWk0BXc6FsCa9vN3qqWcrhlVIaMBIOC84jZ5EjlrjHEVbRRNNdDRf+vdxWchwRLzDYTuLHgUV0fBAUp09zMNnUuXN6QF/N+0ykYyr3BOidsUMLURRqnjoKXM+VqE/o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778679303; c=relaxed/simple; bh=3VeMbMY1AOL2o82Oo+2ts6NUi06EqjZABaZifMYNeus=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mTayC5bPHpifwpNtLJ9odz3Y58SC+VzkZkjDfb3L+N1qYAvV7gy39B0YJriCXxJKJNOLqoJXMpGqUm25WzPSpwFd9pVaRml2mlTM3bmhsS6HTtGNFy0w9Qj5p++CsemC4olZMh3MyqlanYEU+SWjDFKTMvmfdfUl3EnSSuJVkd0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TQyRCV17; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TQyRCV17" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6264C2BCB7; Wed, 13 May 2026 13:34:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778679303; bh=3VeMbMY1AOL2o82Oo+2ts6NUi06EqjZABaZifMYNeus=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=TQyRCV17bWYM1kxOmLl0tJgguCbJyBIpzFU4ROVvnK00j1RMpOL7nn0hI6PRtSFBW yGnCYlrEKjrjdYseV3H/TAYBrUIw9V8meu8noDxd+0/h1wBggD5maDTNy9bSuUpGVF M9RS1v9AOrBhSdcVXdtui7RkShsQ41egS1wMZJVdnrWudMg3YL7CcjLf5+bwROfueL n1DvBPym3qmmo1jiqV0gshxuEAjafEhTaeOxoy3hAnSMqcFpAC07oNqub6AcqIKt85 QAel9avNPuyGcxqDkjWSLUNJFGiYU3dr+9TdVVTg6nlFRgn7p1CZZApKCbeC3EOoZ9 0rPBUMGYwPMhg== Message-ID: Date: Wed, 13 May 2026 16:34:57 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 09/17] dmaengine: sh: rz-dmac: Use virt-dma APIs for channel descriptor processing To: Frank Li , Claudiu Beznea Cc: vkoul@kernel.org, Frank.Li@kernel.org, lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz, tiwai@suse.com, biju.das.jz@bp.renesas.com, prabhakar.mahadev-lad.rj@bp.renesas.com, p.zabel@pengutronix.de, geert+renesas@glider.be, fabrizio.castro.jz@renesas.com, kuninori.morimoto.gx@renesas.com, long.luu.ur@renesas.com, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sound@vger.kernel.org, linux-renesas-soc@vger.kernel.org References: <20260512121219.216159-1-claudiu.beznea.uj@bp.renesas.com> <20260512121219.216159-10-claudiu.beznea.uj@bp.renesas.com> Content-Language: en-US From: Claudiu Beznea In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Frank, On 5/13/26 00:38, Frank Li wrote: > On Tue, May 12, 2026 at 03:12:10PM +0300, Claudiu Beznea wrote: >> The driver used a mix of virt-dma APIs and driver specific logic to >> process descriptors. It maintained three internal queues: ld_free, >> ld_queue, and ld_active as follows: >> - ld_free: stores the descriptors pre-allocated at probe time >> - ld_queue: stores descriptors after they are taken from ld_free and >> prepared. At the same time, vchan_tx_prep() queues them to >> vc->desc_allocated. The vc->desc_allocated list is then checked in >> rz_dmac_issue_pending() and rz_dmac_irq_handler_thread() before >> starting a new transfer via rz_dmac_xfer_desc(). In turn, >> rz_dmac_xfer_desc() grabs the next descriptor from vc->desc_issued and >> submits it for transfer >> - ld_active: stores the descriptors currently being transferred >> >> The interrupt handler moved a completed descriptor to ld_free before >> invoking its completion callback. Once returned to ld_free, the >> descriptor can be reused to prepare a new transfer. In theory, this >> means the descriptor could be re-prepared before its completion >> callback is called. >> >> Commit fully back the driver by the virt-dma APIs. With this, only ld_free >> need to be kept to track how many free descriptors are available. This >> is now done as follows: >> - the prepare stage removes the first descriptor from the ld_free and >> prepares it >> - the completion calls for it vc->desc_free() (rz_dmac_virt_desc_free()) >> which re-adds the descriptor at the end of ld_free >> >> With this, the critical areas in prepare callbacks were minimized to only >> getting the descriptor from the ld_free list. > > Do you plan remove ld_free also? I thought about it. But I prefer to keep it aside from this set as it is already big enough and I haven't notice any possible issue with it. > >> >> This change introduces struct rz_dmac_chan::desc to keep track of the > > Remove "this change", just Introduce ... OK -- Thank you, Claudiu