The main goal of this series is to fix the data disappearance in case of
the DW UART handled by the DW AHB DMA engine. The problem happens on a
portion of the data received when the pre-initialized DEV_TO_MEM
DMA-transfer is paused and then disabled. The data just hangs up in the
DMA-engine FIFO and isn't flushed out to the memory on the DMA-channel
suspension (see the second commit log for details). On a way to find the
denoted problem fix it was discovered that the driver doesn't verify the
peripheral device address width specified by a client driver, which in its
turn if unsupported or undefined value passed may cause DMA-transfer being
misconfigured. It's fixed in the first patch of the series.

In addition to that two cleanup patch follow the fixes described above in
order to make the DWC-engine configuration procedure more coherent. First
one simplifies the CTL_LO register setup methods. Second one simplifies
the max-burst calculation procedure and unifies it with the rest of the
verification methods. Please see the patches log for more details.

Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: dmaengine@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Serge Semin (4):
  dmaengine: dw: Add peripheral bus width verification
  dmaengine: dw: Add memory bus width verification
  dmaengine: dw: Simplify prepare CTL_LO methods
  dmaengine: dw: Simplify max-burst calculation procedure

 drivers/dma/dw/core.c   | 97 ++++++++++++++++++++++++++++++++++++-----
 drivers/dma/dw/dw.c     | 43 +++++++++++-------
 drivers/dma/dw/idma32.c | 25 +++++++----
 drivers/dma/dw/regs.h   |  1 -
 4 files changed, 129 insertions(+), 37 deletions(-)

-- 
2.43.0

On Tue, Apr 16, 2024 at 07:28:54PM +0300, Serge Semin wrote:
> The main goal of this series is to fix the data disappearance in case of
> the DW UART handled by the DW AHB DMA engine. The problem happens on a
> portion of the data received when the pre-initialized DEV_TO_MEM
> DMA-transfer is paused and then disabled. The data just hangs up in the
> DMA-engine FIFO and isn't flushed out to the memory on the DMA-channel
> suspension (see the second commit log for details). On a way to find the
> denoted problem fix it was discovered that the driver doesn't verify the
> peripheral device address width specified by a client driver, which in its
> turn if unsupported or undefined value passed may cause DMA-transfer being
> misconfigured. It's fixed in the first patch of the series.
> 
> In addition to that two cleanup patch follow the fixes described above in
> order to make the DWC-engine configuration procedure more coherent. First
> one simplifies the CTL_LO register setup methods. Second one simplifies
> the max-burst calculation procedure and unifies it with the rest of the
> verification methods. Please see the patches log for more details.

Thank you for this.
I have looked into all of them and most worrying (relatively to the rest) to me
is the second patch that does some tricks. The rest are the cosmetics that can
be easily addressed.

-- 
With Best Regards,
Andy Shevchenko

On Tue, Apr 16, 2024 at 10:13:23PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 16, 2024 at 07:28:54PM +0300, Serge Semin wrote:
> > The main goal of this series is to fix the data disappearance in case of
> > the DW UART handled by the DW AHB DMA engine. The problem happens on a
> > portion of the data received when the pre-initialized DEV_TO_MEM
> > DMA-transfer is paused and then disabled. The data just hangs up in the
> > DMA-engine FIFO and isn't flushed out to the memory on the DMA-channel
> > suspension (see the second commit log for details). On a way to find the
> > denoted problem fix it was discovered that the driver doesn't verify the
> > peripheral device address width specified by a client driver, which in its
> > turn if unsupported or undefined value passed may cause DMA-transfer being
> > misconfigured. It's fixed in the first patch of the series.
> > 
> > In addition to that two cleanup patch follow the fixes described above in
> > order to make the DWC-engine configuration procedure more coherent. First
> > one simplifies the CTL_LO register setup methods. Second one simplifies
> > the max-burst calculation procedure and unifies it with the rest of the
> > verification methods. Please see the patches log for more details.
> 
> Thank you for this.

> I have looked into all of them and most worrying (relatively to the rest) to me
> is the second patch that does some tricks.

That's a crucial patch for which the series has been intended. The
rest of the patches were created to align the code around the fix.

> The rest are the cosmetics that can
> be easily addressed.

Right. I'll have a look at the rest of your comments shortly.

-Serge(y)

> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>