Re: [PATCH 1/7] dmaengine: dw-edma: Fix HDMA channel status register access

[Koichiro Den]

On Fri, Jul 10, 2026 at 04:26:08PM -0500, Frank Li wrote:
> On Fri, Jul 10, 2026 at 05:08:57PM +0900, Koichiro Den wrote:
> > GET_CH_32() takes the direction before the channel ID, but
> > dw_hdma_v0_core_ch_status() passed them in the opposite order. This can
> > make the status callback read another HDMA channel status register.
> >
> > Use the same argument order as the other HDMA register accesses.
> >
> > Fixes: e74c39573d35 ("dmaengine: dw-edma: Add support for native HDMA")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Reviewed-by: Frank Li <Frank.Li@xxxxxxx>
> > Signed-off-by: Koichiro Den <den@xxxxxxxxxxxxx>
> > ---
> 
> Do you miss version number at subject?

Hi Frank,

Thanks for pointing it out. Technically there is no v1 for this split-out
series, but you're right, I left each patch with an added "Changes in v2" note
so it must be confusing. Some of them came from the "dynamic append" v1, and
some are new. You seem to have already left some comments, thanks for reviewing.
Since some of what Sashiko pointed out seems real and I should re-spin anyway, I
think I'll just bump it to v3.

P.S.
Let me just tell you here that the "dynamic append" attempt seems to have opened
a can of worms. What you observed previously as a missed doorbell (written in
your RFT series) seems to me just the tip of the iceberg. (Of course you
might've already sensed that, I'm just going by what the RFT described.) At
least for legacy eDMA, ringing a doorbell while the channel has not been
completely stopped internally led to various issues, even if it looks as if
already stopped from software point of view. When I put heavy load across
multiple channels [1], the issue starts to be observable in a reasonable time.
The details are really complicated and my solution made the "dynamic append" v2
series expand to 26 commits in the end, which is too large for one series.

That's why I split 7 patches out of it and sent them as "dmaengine: dw-edma:
Fixes and interrupt-path groundwork" series.

My plan was to submit in order:

  1. [PATCH 0/7] dmaengine: dw-edma: Fixes and interrupt-path groundwork
     # This series. Should've added "v2" in its subject.

  2. [PATCH v2 0/19] dmaengine: dw-edma: Support dynamic LL appends
     # Will send shortly.

[1]: as you know, the goal of my relevant works is speeding up the ntb_netdev
     EP<->RC traffic, and now it reaches 18.7Gbps/15.7Gbps in each direction on
     PCIe Gen4 x2 R-Car S4, DWC PCIe v5.20a eDMA. eDMA use saves us from CPU (or
     DMA) MEMCPY in NTB transport layer as well. That is a significant speed-up
     since it was originally 500Mbps ~ 1.2Gbps. "dynamic append" is a
     fundamentally important piece to unleash the eDMA performance.

Best regards,
Koichiro

> 
> Frank
> 
> > Changes in v2:
> >   - Split out into this preparation series (was patch 02/17 of the
> >     dynamic LL appends v1); no changes to the patch itself.
> >   - Collect Frank's Reviewed-by.
> >
> >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> > index 632abb8b481c..2beec876b184 100644
> > --- a/drivers/dma/dw-edma/dw-hdma-v0-core.c
> > +++ b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> > @@ -79,7 +79,7 @@ static enum dma_status dw_hdma_v0_core_ch_status(struct dw_edma_chan *chan)
> >  	u32 tmp;
> >
> >  	tmp = FIELD_GET(HDMA_V0_CH_STATUS_MASK,
> > -			GET_CH_32(dw, chan->id, chan->dir, ch_stat));
> > +			GET_CH_32(dw, chan->dir, chan->id, ch_stat));
> >
> >  	if (tmp == 1)
> >  		return DMA_IN_PROGRESS;
> > --
> > 2.51.0
> >