lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z7hmq9YO43383WQO@ryzen>
Date: Fri, 21 Feb 2025 12:42:35 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Devendra K Verma <devverma@....com>, vkoul@...nel.org,
	dmaengine@...r.kernel.org, michal.simek@....com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dmaengine: dw-edma: Add simple mode support

On Fri, Feb 21, 2025 at 01:16:12PM +0530, Manivannan Sadhasivam wrote:
> On Wed, Feb 19, 2025 at 04:38:47PM +0530, Devendra K Verma wrote:
> 
> + Niklas (who also looked into the MEMCPY for eDMA)
> 
> > Added the simple or non-linked list DMA mode of transfer.
> > 
> 
> Patch subject and description are also simple :) You completely forgot to
> mention that you are adding the DMA_MEMCPY support to this driver. That too only
> for HDMA.
> 
> > Signed-off-by: Devendra K Verma <devverma@....com>
> > ---
> >  drivers/dma/dw-edma/dw-edma-core.c    | 38 +++++++++++++++++
> >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 59 ++++++++++++++++++++++++++-
> >  3 files changed, 97 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> > index 68236247059d..bd975e6d419a 100644
> > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > @@ -595,6 +595,43 @@ dw_edma_device_prep_interleaved_dma(struct dma_chan *dchan,
> >  	return dw_edma_device_transfer(&xfer);
> >  }
> >  
> > +static struct dma_async_tx_descriptor *
> > +dw_edma_device_prep_dma_memcpy(struct dma_chan *dchan,
> > +			       dma_addr_t dst,
> > +			       dma_addr_t src, size_t len,
> > +			       unsigned long flags)
> > +{
> > +	struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> > +	struct dw_edma_chunk *chunk;
> > +	struct dw_edma_burst *burst;
> > +	struct dw_edma_desc *desc;
> > +
> > +	desc = dw_edma_alloc_desc(chan);
> > +	if (unlikely(!desc))
> > +		return NULL;
> > +
> > +	chunk = dw_edma_alloc_chunk(desc);
> > +	if (unlikely(!chunk))
> > +		goto err_alloc;
> > +
> > +	burst = dw_edma_alloc_burst(chunk);
> > +	if (unlikely(!burst))
> > +		goto err_alloc;
> > +
> > +	burst->sar = src;
> > +	burst->dar = dst;
> 
> Niklas looked into adding MEMCPY support but blocked by the fact that the
> device_prep_dma_memcpy() assumes that the direction is always MEM_TO_MEM. But
> the eDMA driver (HDMA also?) only support transfers between remote and local
> DDR. So only MEM_TO_DEV and DEV_TO_MEM are valid directions (assuming that we
> call the remote DDR as DEV).

In rk3588 TRM:

MAP_FORMAT
0x0 (EDMA_LEGACY_PL): Legacy DMA register map accessed by the port-logic
    registers
0x1 (EDMA_LEGACY_UNROLL): Legacy DMA register map, mapped to a PF/BAR
0x5 (HDMA_COMPATIBILITY_MODE): HDMA compatibility mode (CC_LEGACY_DMA_MAP =1)
    register map, mapped to a PF/BAR
0x7 (HDMA_NATIVE): HDMA native (CC_LEGACY_DMA_MAP =0) register map, mapped to
    a PF/BAR

Read-only register. Value After Reset: 0x1.

So eDMA in rk3588 is EDMA_LEGACY_UNROLL.


I don't know if this limitation that you correctly described applies to all
the other formats as well.


Kind regards,
Niklas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ