* Re: [PATCH] dmaengine: sudmac: remove unused driver
From: Sergei Shtylyov @ 2019-05-09 16:20 UTC (permalink / raw)
To: Simon Horman, Vinod Koul
Cc: dmaengine, linux-renesas-soc, Magnus Damm, Yoshihiro Shimoda
In-Reply-To: <20190509125211.324-1-horms+renesas@verge.net.au>
On 05/09/2019 03:52 PM, Simon Horman wrote:
> SUDMAC driver was introduced in v3.10 but was never integrated for use
> by any platform. As it unused remove it.
"It's unused" perhaps? :-)
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] dmaengine: rcar-dmac: Update copyright information
From: Simon Horman @ 2019-05-09 12:55 UTC (permalink / raw)
To: Vinod Koul
Cc: Yoshihiro Shimoda, Geert Uytterhoeven, Niklas Söderlund,
dmaengine@vger.kernel.org, Linux-Renesas, HIROYUKI YOKOYAMA
In-Reply-To: <20190426115343.GY28103@vkoul-mobl>
On Fri, Apr 26, 2019 at 05:23:43PM +0530, Vinod Koul wrote:
> On 25-04-19, 03:52, Yoshihiro Shimoda wrote:
> > Hi Geert-san,
> >
> > > From: Geert Uytterhoeven, Sent: Wednesday, April 24, 2019 9:22 PM
> > >
> > > Hi Niklas, Shimoda-san,
> > >
> > > On Thu, Apr 11, 2019 at 5:18 PM Niklas Söderlund
> > > <niklas.soderlund@ragnatech.se> wrote:
> > > > On 2019-04-11 10:49:37 +0200, Simon Horman wrote:
> > > > > On Wed, Apr 10, 2019 at 08:26:57PM +0200, Niklas Söderlund wrote:
> > > > > Not strictly related, but is it appropriate to:
> > > > >
> > > > > 1. Move this driver and drivers/dma/sh/usb-dmac.c to drivers/dma/renesas/
> > >
> > > That may make sense...
> > >
> > > > > 2. Remove drivers/dma/sh/sudmac.c which appears unused
> > > >
> > > > I let someone with a better grasp of history answer this one. From my
> > > > side removing drivers which are unused seems like a good idea :-)
> > >
> > > There seem to be some (half-baked?) interaction between sudmac.c and
> > > drivers/usb/gadget/udc/r8a66597-udc.c and drivers/usb/renesas_usbhs/fifo.c.
> > > These don't seem to be used at all on Renesas ARM platforms, but
> > > CONFIG_USB_R8A66597_HCD is enabled in shmobile_defconfig and
> > > multi_v7_defconfig?
> > >
> > > Shimoda-san: can you please enlighten us?
> > > Thanks!
> >
> > Sure.
> >
> > - SH4A / sh7757 has SUDMAC. (any other Renesas ARM platforms don't have it).
> > # sh7757 is not public product though...
> > - At first, I added this SUDMAC support into r8a66597-udc.
> > - But, our direction is changed by some reason. So, we use renesas_usbhs driver anyway.
> > - The renesas_usbhs supports dmaengine, so I added dma/sh/sudmac driver.
> > - However, for some reasons (maybe I'm busy for other projects?),
> > I didn't add using the sudmac support into arch/sh/kernel/cpu/sh4a/setup-sh7757.c.
> > - So, no one uses both r8a66597-udc and sudmac now.
> >
> > From 2013 (added the sudmac driver) to now, since no one integrated the sudmac for sh7757,
> > I think we can remove the driver.
>
> And where is the removal patch :)
Sorry for the delay, I have just posted
[PATCH] dmaengine: sudmac: remove unused driver
Shimoda-san, can we go further and also:
1. Remove the r8a66597-udc driver, which also seems unused
2. Remove (minimal) sudmac integration from usbhs ?
^ permalink raw reply
* [PATCH] dmaengine: sudmac: remove unused driver
From: Simon Horman @ 2019-05-09 12:52 UTC (permalink / raw)
To: Vinod Koul
Cc: dmaengine, linux-renesas-soc, Magnus Damm, Yoshihiro Shimoda,
Simon Horman
SUDMAC driver was introduced in v3.10 but was never integrated for use
by any platform. As it unused remove it.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
drivers/dma/sh/Kconfig | 6 -
drivers/dma/sh/Makefile | 1 -
drivers/dma/sh/sudmac.c | 414 ------------------------------------------------
include/linux/sudmac.h | 52 ------
4 files changed, 473 deletions(-)
delete mode 100644 drivers/dma/sh/sudmac.c
delete mode 100644 include/linux/sudmac.h
diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
index 4d6b02b3b1f1..54d5d0369d3c 100644
--- a/drivers/dma/sh/Kconfig
+++ b/drivers/dma/sh/Kconfig
@@ -47,9 +47,3 @@ config RENESAS_USB_DMAC
help
This driver supports the USB-DMA controller found in the Renesas
SoCs.
-
-config SUDMAC
- tristate "Renesas SUDMAC support"
- depends on SH_DMAE_BASE
- help
- Enable support for the Renesas SUDMAC controllers.
diff --git a/drivers/dma/sh/Makefile b/drivers/dma/sh/Makefile
index 42110dd57a56..112fbd22bb3f 100644
--- a/drivers/dma/sh/Makefile
+++ b/drivers/dma/sh/Makefile
@@ -15,4 +15,3 @@ obj-$(CONFIG_SH_DMAE) += shdma.o
obj-$(CONFIG_RCAR_DMAC) += rcar-dmac.o
obj-$(CONFIG_RENESAS_USB_DMAC) += usb-dmac.o
-obj-$(CONFIG_SUDMAC) += sudmac.o
diff --git a/drivers/dma/sh/sudmac.c b/drivers/dma/sh/sudmac.c
deleted file mode 100644
index 30cc3553cb8b..000000000000
--- a/drivers/dma/sh/sudmac.c
+++ /dev/null
@@ -1,414 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Renesas SUDMAC support
- *
- * Copyright (C) 2013 Renesas Solutions Corp.
- *
- * based on drivers/dma/sh/shdma.c:
- * Copyright (C) 2011-2012 Guennadi Liakhovetski <g.liakhovetski@gmx.de>
- * Copyright (C) 2009 Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
- * Copyright (C) 2009 Renesas Solutions, Inc. All rights reserved.
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
- */
-
-#include <linux/dmaengine.h>
-#include <linux/err.h>
-#include <linux/init.h>
-#include <linux/interrupt.h>
-#include <linux/module.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include <linux/sudmac.h>
-
-struct sudmac_chan {
- struct shdma_chan shdma_chan;
- void __iomem *base;
- char dev_id[16]; /* unique name per DMAC of channel */
-
- u32 offset; /* for CFG, BA, BBC, CA, CBC, DEN */
- u32 cfg;
- u32 dint_end_bit;
-};
-
-struct sudmac_device {
- struct shdma_dev shdma_dev;
- struct sudmac_pdata *pdata;
- void __iomem *chan_reg;
-};
-
-struct sudmac_regs {
- u32 base_addr;
- u32 base_byte_count;
-};
-
-struct sudmac_desc {
- struct sudmac_regs hw;
- struct shdma_desc shdma_desc;
-};
-
-#define to_chan(schan) container_of(schan, struct sudmac_chan, shdma_chan)
-#define to_desc(sdesc) container_of(sdesc, struct sudmac_desc, shdma_desc)
-#define to_sdev(sc) container_of(sc->shdma_chan.dma_chan.device, \
- struct sudmac_device, shdma_dev.dma_dev)
-
-/* SUDMAC register */
-#define SUDMAC_CH0CFG 0x00
-#define SUDMAC_CH0BA 0x10
-#define SUDMAC_CH0BBC 0x18
-#define SUDMAC_CH0CA 0x20
-#define SUDMAC_CH0CBC 0x28
-#define SUDMAC_CH0DEN 0x30
-#define SUDMAC_DSTSCLR 0x38
-#define SUDMAC_DBUFCTRL 0x3C
-#define SUDMAC_DINTCTRL 0x40
-#define SUDMAC_DINTSTS 0x44
-#define SUDMAC_DINTSTSCLR 0x48
-#define SUDMAC_CH0SHCTRL 0x50
-
-/* Definitions for the sudmac_channel.config */
-#define SUDMAC_SENDBUFM 0x1000 /* b12: Transmit Buffer Mode */
-#define SUDMAC_RCVENDM 0x0100 /* b8: Receive Data Transfer End Mode */
-#define SUDMAC_LBA_WAIT 0x0030 /* b5-4: Local Bus Access Wait */
-
-/* Definitions for the sudmac_channel.dint_end_bit */
-#define SUDMAC_CH1ENDE 0x0002 /* b1: Ch1 DMA Transfer End Int Enable */
-#define SUDMAC_CH0ENDE 0x0001 /* b0: Ch0 DMA Transfer End Int Enable */
-
-#define SUDMAC_DRV_NAME "sudmac"
-
-static void sudmac_writel(struct sudmac_chan *sc, u32 data, u32 reg)
-{
- iowrite32(data, sc->base + reg);
-}
-
-static u32 sudmac_readl(struct sudmac_chan *sc, u32 reg)
-{
- return ioread32(sc->base + reg);
-}
-
-static bool sudmac_is_busy(struct sudmac_chan *sc)
-{
- u32 den = sudmac_readl(sc, SUDMAC_CH0DEN + sc->offset);
-
- if (den)
- return true; /* working */
-
- return false; /* waiting */
-}
-
-static void sudmac_set_reg(struct sudmac_chan *sc, struct sudmac_regs *hw,
- struct shdma_desc *sdesc)
-{
- sudmac_writel(sc, sc->cfg, SUDMAC_CH0CFG + sc->offset);
- sudmac_writel(sc, hw->base_addr, SUDMAC_CH0BA + sc->offset);
- sudmac_writel(sc, hw->base_byte_count, SUDMAC_CH0BBC + sc->offset);
-}
-
-static void sudmac_start(struct sudmac_chan *sc)
-{
- u32 dintctrl = sudmac_readl(sc, SUDMAC_DINTCTRL);
-
- sudmac_writel(sc, dintctrl | sc->dint_end_bit, SUDMAC_DINTCTRL);
- sudmac_writel(sc, 1, SUDMAC_CH0DEN + sc->offset);
-}
-
-static void sudmac_start_xfer(struct shdma_chan *schan,
- struct shdma_desc *sdesc)
-{
- struct sudmac_chan *sc = to_chan(schan);
- struct sudmac_desc *sd = to_desc(sdesc);
-
- sudmac_set_reg(sc, &sd->hw, sdesc);
- sudmac_start(sc);
-}
-
-static bool sudmac_channel_busy(struct shdma_chan *schan)
-{
- struct sudmac_chan *sc = to_chan(schan);
-
- return sudmac_is_busy(sc);
-}
-
-static void sudmac_setup_xfer(struct shdma_chan *schan, int slave_id)
-{
-}
-
-static const struct sudmac_slave_config *sudmac_find_slave(
- struct sudmac_chan *sc, int slave_id)
-{
- struct sudmac_device *sdev = to_sdev(sc);
- struct sudmac_pdata *pdata = sdev->pdata;
- const struct sudmac_slave_config *cfg;
- int i;
-
- for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
- if (cfg->slave_id == slave_id)
- return cfg;
-
- return NULL;
-}
-
-static int sudmac_set_slave(struct shdma_chan *schan, int slave_id,
- dma_addr_t slave_addr, bool try)
-{
- struct sudmac_chan *sc = to_chan(schan);
- const struct sudmac_slave_config *cfg = sudmac_find_slave(sc, slave_id);
-
- if (!cfg)
- return -ENODEV;
-
- return 0;
-}
-
-static inline void sudmac_dma_halt(struct sudmac_chan *sc)
-{
- u32 dintctrl = sudmac_readl(sc, SUDMAC_DINTCTRL);
-
- sudmac_writel(sc, 0, SUDMAC_CH0DEN + sc->offset);
- sudmac_writel(sc, dintctrl & ~sc->dint_end_bit, SUDMAC_DINTCTRL);
- sudmac_writel(sc, sc->dint_end_bit, SUDMAC_DINTSTSCLR);
-}
-
-static int sudmac_desc_setup(struct shdma_chan *schan,
- struct shdma_desc *sdesc,
- dma_addr_t src, dma_addr_t dst, size_t *len)
-{
- struct sudmac_chan *sc = to_chan(schan);
- struct sudmac_desc *sd = to_desc(sdesc);
-
- dev_dbg(sc->shdma_chan.dev, "%s: src=%pad, dst=%pad, len=%zu\n",
- __func__, &src, &dst, *len);
-
- if (*len > schan->max_xfer_len)
- *len = schan->max_xfer_len;
-
- if (dst)
- sd->hw.base_addr = dst;
- else if (src)
- sd->hw.base_addr = src;
- sd->hw.base_byte_count = *len;
-
- return 0;
-}
-
-static void sudmac_halt(struct shdma_chan *schan)
-{
- struct sudmac_chan *sc = to_chan(schan);
-
- sudmac_dma_halt(sc);
-}
-
-static bool sudmac_chan_irq(struct shdma_chan *schan, int irq)
-{
- struct sudmac_chan *sc = to_chan(schan);
- u32 dintsts = sudmac_readl(sc, SUDMAC_DINTSTS);
-
- if (!(dintsts & sc->dint_end_bit))
- return false;
-
- /* DMA stop */
- sudmac_dma_halt(sc);
-
- return true;
-}
-
-static size_t sudmac_get_partial(struct shdma_chan *schan,
- struct shdma_desc *sdesc)
-{
- struct sudmac_chan *sc = to_chan(schan);
- struct sudmac_desc *sd = to_desc(sdesc);
- u32 current_byte_count = sudmac_readl(sc, SUDMAC_CH0CBC + sc->offset);
-
- return sd->hw.base_byte_count - current_byte_count;
-}
-
-static bool sudmac_desc_completed(struct shdma_chan *schan,
- struct shdma_desc *sdesc)
-{
- struct sudmac_chan *sc = to_chan(schan);
- struct sudmac_desc *sd = to_desc(sdesc);
- u32 current_addr = sudmac_readl(sc, SUDMAC_CH0CA + sc->offset);
-
- return sd->hw.base_addr + sd->hw.base_byte_count == current_addr;
-}
-
-static int sudmac_chan_probe(struct sudmac_device *su_dev, int id, int irq,
- unsigned long flags)
-{
- struct shdma_dev *sdev = &su_dev->shdma_dev;
- struct platform_device *pdev = to_platform_device(sdev->dma_dev.dev);
- struct sudmac_chan *sc;
- struct shdma_chan *schan;
- int err;
-
- sc = devm_kzalloc(&pdev->dev, sizeof(struct sudmac_chan), GFP_KERNEL);
- if (!sc)
- return -ENOMEM;
-
- schan = &sc->shdma_chan;
- schan->max_xfer_len = 64 * 1024 * 1024 - 1;
-
- shdma_chan_probe(sdev, schan, id);
-
- sc->base = su_dev->chan_reg;
-
- /* get platform_data */
- sc->offset = su_dev->pdata->channel->offset;
- if (su_dev->pdata->channel->config & SUDMAC_TX_BUFFER_MODE)
- sc->cfg |= SUDMAC_SENDBUFM;
- if (su_dev->pdata->channel->config & SUDMAC_RX_END_MODE)
- sc->cfg |= SUDMAC_RCVENDM;
- sc->cfg |= (su_dev->pdata->channel->wait << 4) & SUDMAC_LBA_WAIT;
-
- if (su_dev->pdata->channel->dint_end_bit & SUDMAC_DMA_BIT_CH0)
- sc->dint_end_bit |= SUDMAC_CH0ENDE;
- if (su_dev->pdata->channel->dint_end_bit & SUDMAC_DMA_BIT_CH1)
- sc->dint_end_bit |= SUDMAC_CH1ENDE;
-
- /* set up channel irq */
- if (pdev->id >= 0)
- snprintf(sc->dev_id, sizeof(sc->dev_id), "sudmac%d.%d",
- pdev->id, id);
- else
- snprintf(sc->dev_id, sizeof(sc->dev_id), "sudmac%d", id);
-
- err = shdma_request_irq(schan, irq, flags, sc->dev_id);
- if (err) {
- dev_err(sdev->dma_dev.dev,
- "DMA channel %d request_irq failed %d\n", id, err);
- goto err_no_irq;
- }
-
- return 0;
-
-err_no_irq:
- /* remove from dmaengine device node */
- shdma_chan_remove(schan);
- return err;
-}
-
-static void sudmac_chan_remove(struct sudmac_device *su_dev)
-{
- struct shdma_chan *schan;
- int i;
-
- shdma_for_each_chan(schan, &su_dev->shdma_dev, i) {
- BUG_ON(!schan);
-
- shdma_chan_remove(schan);
- }
-}
-
-static dma_addr_t sudmac_slave_addr(struct shdma_chan *schan)
-{
- /* SUDMAC doesn't need the address */
- return 0;
-}
-
-static struct shdma_desc *sudmac_embedded_desc(void *buf, int i)
-{
- return &((struct sudmac_desc *)buf)[i].shdma_desc;
-}
-
-static const struct shdma_ops sudmac_shdma_ops = {
- .desc_completed = sudmac_desc_completed,
- .halt_channel = sudmac_halt,
- .channel_busy = sudmac_channel_busy,
- .slave_addr = sudmac_slave_addr,
- .desc_setup = sudmac_desc_setup,
- .set_slave = sudmac_set_slave,
- .setup_xfer = sudmac_setup_xfer,
- .start_xfer = sudmac_start_xfer,
- .embedded_desc = sudmac_embedded_desc,
- .chan_irq = sudmac_chan_irq,
- .get_partial = sudmac_get_partial,
-};
-
-static int sudmac_probe(struct platform_device *pdev)
-{
- struct sudmac_pdata *pdata = dev_get_platdata(&pdev->dev);
- int err, i;
- struct sudmac_device *su_dev;
- struct dma_device *dma_dev;
- struct resource *chan, *irq_res;
-
- /* get platform data */
- if (!pdata)
- return -ENODEV;
-
- irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq_res)
- return -ENODEV;
-
- err = -ENOMEM;
- su_dev = devm_kzalloc(&pdev->dev, sizeof(struct sudmac_device),
- GFP_KERNEL);
- if (!su_dev)
- return err;
-
- dma_dev = &su_dev->shdma_dev.dma_dev;
-
- chan = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- su_dev->chan_reg = devm_ioremap_resource(&pdev->dev, chan);
- if (IS_ERR(su_dev->chan_reg))
- return PTR_ERR(su_dev->chan_reg);
-
- dma_cap_set(DMA_SLAVE, dma_dev->cap_mask);
-
- su_dev->shdma_dev.ops = &sudmac_shdma_ops;
- su_dev->shdma_dev.desc_size = sizeof(struct sudmac_desc);
- err = shdma_init(&pdev->dev, &su_dev->shdma_dev, pdata->channel_num);
- if (err < 0)
- return err;
-
- /* platform data */
- su_dev->pdata = dev_get_platdata(&pdev->dev);
-
- platform_set_drvdata(pdev, su_dev);
-
- /* Create DMA Channel */
- for (i = 0; i < pdata->channel_num; i++) {
- err = sudmac_chan_probe(su_dev, i, irq_res->start, IRQF_SHARED);
- if (err)
- goto chan_probe_err;
- }
-
- err = dma_async_device_register(&su_dev->shdma_dev.dma_dev);
- if (err < 0)
- goto chan_probe_err;
-
- return err;
-
-chan_probe_err:
- sudmac_chan_remove(su_dev);
-
- shdma_cleanup(&su_dev->shdma_dev);
-
- return err;
-}
-
-static int sudmac_remove(struct platform_device *pdev)
-{
- struct sudmac_device *su_dev = platform_get_drvdata(pdev);
- struct dma_device *dma_dev = &su_dev->shdma_dev.dma_dev;
-
- dma_async_device_unregister(dma_dev);
- sudmac_chan_remove(su_dev);
- shdma_cleanup(&su_dev->shdma_dev);
-
- return 0;
-}
-
-static struct platform_driver sudmac_driver = {
- .driver = {
- .name = SUDMAC_DRV_NAME,
- },
- .probe = sudmac_probe,
- .remove = sudmac_remove,
-};
-module_platform_driver(sudmac_driver);
-
-MODULE_AUTHOR("Yoshihiro Shimoda");
-MODULE_DESCRIPTION("Renesas SUDMAC driver");
-MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:" SUDMAC_DRV_NAME);
diff --git a/include/linux/sudmac.h b/include/linux/sudmac.h
deleted file mode 100644
index 377b8a5788fa..000000000000
--- a/include/linux/sudmac.h
+++ /dev/null
@@ -1,52 +0,0 @@
-/*
- * Header for the SUDMAC driver
- *
- * Copyright (C) 2013 Renesas Solutions Corp.
- *
- * This is free software; you can redistribute it and/or modify
- * it under the terms of version 2 of the GNU General Public License as
- * published by the Free Software Foundation.
- */
-#ifndef SUDMAC_H
-#define SUDMAC_H
-
-#include <linux/dmaengine.h>
-#include <linux/shdma-base.h>
-#include <linux/types.h>
-
-/* Used by slave DMA clients to request DMA to/from a specific peripheral */
-struct sudmac_slave {
- struct shdma_slave shdma_slave; /* Set by the platform */
-};
-
-/*
- * Supplied by platforms to specify, how a DMA channel has to be configured for
- * a certain peripheral
- */
-struct sudmac_slave_config {
- int slave_id;
-};
-
-struct sudmac_channel {
- unsigned long offset;
- unsigned long config;
- unsigned long wait; /* The configuable range is 0 to 3 */
- unsigned long dint_end_bit;
-};
-
-struct sudmac_pdata {
- const struct sudmac_slave_config *slave;
- int slave_num;
- const struct sudmac_channel *channel;
- int channel_num;
-};
-
-/* Definitions for the sudmac_channel.config */
-#define SUDMAC_TX_BUFFER_MODE BIT(0)
-#define SUDMAC_RX_END_MODE BIT(1)
-
-/* Definitions for the sudmac_channel.dint_end_bit */
-#define SUDMAC_DMA_BIT_CH0 BIT(0)
-#define SUDMAC_DMA_BIT_CH1 BIT(1)
-
-#endif
--
2.11.0
^ permalink raw reply related
* [PATCH] dmaengine: mediatek-cqdma: sleeping in atomic context
From: Dan Carpenter @ 2019-05-09 10:09 UTC (permalink / raw)
To: Shun-Chih Yu, Sean Wang
Cc: Dan Williams, Vinod Koul, Matthias Brugger, dmaengine,
linux-mediatek, kernel-janitors
The mtk_cqdma_poll_engine_done() function takes a true/false parameter
where true means it's called from atomic context. There are a couple
places where it was set to false but it's actually in atomic context
so it should be true.
All the callers for mtk_cqdma_hard_reset() are holding a spin_lock and
in mtk_cqdma_free_chan_resources() we take a spin_lock before calling
the mtk_cqdma_poll_engine_done() function.
Fixes: b1f01e48df5a ("dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
The "atomic" parameter is always true so the temptation was to just
remove it entirely.
drivers/dma/mediatek/mtk-cqdma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c
index 814853842e29..723b11c190b3 100644
--- a/drivers/dma/mediatek/mtk-cqdma.c
+++ b/drivers/dma/mediatek/mtk-cqdma.c
@@ -225,7 +225,7 @@ static int mtk_cqdma_hard_reset(struct mtk_cqdma_pchan *pc)
mtk_dma_set(pc, MTK_CQDMA_RESET, MTK_CQDMA_HARD_RST_BIT);
mtk_dma_clr(pc, MTK_CQDMA_RESET, MTK_CQDMA_HARD_RST_BIT);
- return mtk_cqdma_poll_engine_done(pc, false);
+ return mtk_cqdma_poll_engine_done(pc, true);
}
static void mtk_cqdma_start(struct mtk_cqdma_pchan *pc,
@@ -671,7 +671,7 @@ static void mtk_cqdma_free_chan_resources(struct dma_chan *c)
mtk_dma_set(cvc->pc, MTK_CQDMA_FLUSH, MTK_CQDMA_FLUSH_BIT);
/* wait for the completion of flush operation */
- if (mtk_cqdma_poll_engine_done(cvc->pc, false) < 0)
+ if (mtk_cqdma_poll_engine_done(cvc->pc, true) < 0)
dev_err(cqdma2dev(to_cqdma_dev(c)), "cqdma flush timeout\n");
/* clear the flush bit and interrupt flag */
--
2.18.0
^ permalink raw reply related
* [GIT PULL]: dmaengine updates for v5.2-rc1
From: Vinod Koul @ 2019-05-09 7:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: dma, LKML
[-- Attachment #1: Type: text/plain, Size: 5325 bytes --]
Hi Linus,
Here is the updates to dmaengine subsystem for v5.2-rc1. Please pull to
get following updates:
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
are available in the Git repository at:
git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-5.2-rc1
for you to fetch changes up to f33e7bb3eb922618612a90f0a828c790e8880773:
dmaengine: tegra210-adma: restore channel status (2019-05-04 16:13:42 +0530)
----------------------------------------------------------------
dmaengine updates for v5.2-rc1
- Updates to stm32 dma residue calculations
- Interleave dma capability to axi-dmac and
support for ZynqMP arch
- Rework of channel assignment for rcar dma
- Debugfs for pl330 driver
- Support for Tegra186/Tegra194, refactoring for new chips
and support for pause/resume
- Updates to axi-dmac, bcm2835, fsl-edma, idma64, imx-sdma,
rcar-dmac, stm32-dma etc
- dev_get_drvdata() updates on few drivers
----------------------------------------------------------------
Alexandru Ardelean (1):
dmaengine: axi-dmac: Don't check the number of frames for alignment
Andy Shevchenko (2):
dmaengine: idma64: Use actual device for DMA transfers
dmaengine: idma64: Move driver name to the header
Angus Ainslie (Purism) (1):
dmaengine: imx-sdma: Only check ratio on parts that support 1:1
Arnaud Pouliquen (1):
dmaengine: stm32-dma: fix residue calculation in stm32-dma
Colin Ian King (1):
dmaengine: xgene-dma: fix spelling mistake "descripto" -> "descriptor"
Dan Carpenter (1):
dmaengine: at_xdmac: remove a stray bottom half unlock
Dragos Bogdan (1):
dmaengine: axi-dmac: Enable DMA_INTERLEAVE capability
Fabien Dessenne (1):
dmaengine: stm32-dma: use platform_get_irq()
Hiroyuki Yokoyama (1):
dmaengine: rcar-dmac: Update copyright information
Jean-Nicolas Graux (1):
dmaengine: pl08x: be fair when re-assigning physical channel
Jeff Xie (1):
dmaengine: xgene-dma: move spin_lock_bh to spin_lock in tasklet
Katsuhiro Suzuki (1):
dmaengine: pl330: introduce debugfs interface
Kefeng Wang (2):
dmaengine: bcm-sba-raid: Use dev_get_drvdata()
dmaengine: nbpfaxi: Use dev_get_drvdata()
Krzysztof Kozlowski (2):
dmaengine: fsl-edma: Fix typo in Vybrid name
dmaengine: fsl-edma: Adjust indentation
Lars-Peter Clausen (2):
dmaengine: axi-dmac: Split too large segments
dmaengine: axi-dmac: Infer synthesis configuration parameters hardware
Michael Hennerich (1):
dmaengine: axi-dmac: extend support for ZynqMP arch
Michal Suchanek (1):
dmaengine: bcm2835: Drop duplicate capability setting.
Nicolas Ferre (3):
dmaengine: at_xdmac: remove BUG_ON macro in tasklet
dmaengine: at_xdmac: enhance channel errors handling in tasklet
dmaengine: at_xdmac: only monitor overflow errors for peripheral xfer
Sameer Pujar (8):
dmaengine: tegra210-adma: use devm_clk_*() helpers
dmaengine: tegra210-adma: update system sleep callbacks
dmaengine: tegra210-adma: prepare for supporting newer Tegra chips
Documentation: DT: Add compatibility binding for Tegra186
dmaengine: tegra210-adma: add support for Tegra186/Tegra194
dmaengine: tegra210-adma: add pause/resume support
dmaengine: tegra210-dma: free dma controller in remove()
dmaengine: tegra210-adma: restore channel status
Sugar Zhang (1):
dmaengine: pl330: _stop: clear interrupt status
Vinod Koul (1):
dmaengine: stm32-dma: Fix unsigned variable compared with zero
.../devicetree/bindings/dma/adi,axi-dmac.txt | 4 +-
.../bindings/dma/nvidia,tegra210-adma.txt | 4 +-
drivers/dma/Kconfig | 2 +-
drivers/dma/amba-pl08x.c | 22 +-
drivers/dma/at_xdmac.c | 67 ++++-
drivers/dma/bcm-sba-raid.c | 3 +-
drivers/dma/bcm2835-dma.c | 1 -
drivers/dma/dma-axi-dmac.c | 116 ++++++---
drivers/dma/fsl-edma-common.h | 2 +-
drivers/dma/fsl-edma.c | 6 +-
drivers/dma/idma64.c | 15 +-
drivers/dma/idma64.h | 2 +
drivers/dma/imx-sdma.c | 15 +-
drivers/dma/nbpfaxi.c | 4 +-
drivers/dma/pl330.c | 61 ++++-
drivers/dma/sh/rcar-dmac.c | 4 +-
drivers/dma/stm32-dma.c | 103 ++++++--
drivers/dma/tegra210-adma.c | 269 ++++++++++++++++-----
drivers/dma/xgene-dma.c | 6 +-
drivers/mfd/intel-lpss.c | 4 +-
drivers/spi/spi-pxa2xx.c | 7 +-
drivers/tty/serial/8250/8250_dw.c | 4 +-
include/linux/dma/idma64.h | 14 ++
23 files changed, 566 insertions(+), 169 deletions(-)
create mode 100644 include/linux/dma/idma64.h
Thanks
--
~Vinod
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/8] soc: tegra: fuse: Change to the correct __dma_request_channel() prototype
From: Baolin Wang @ 2019-05-09 1:44 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Dan Williams, Vinod Koul, Thierry Reding, Jon Hunter, linux-tegra,
Shawn Guo, s.hauer, kernel, festevam, linux-imx, Zubair.Kakakhel,
Wolfram Sang, jroedel, Vincent Guittot, dmaengine, LKML,
Linux ARM
In-Reply-To: <8746a913-0014-7036-7fab-4e0dfab04e1b@gmail.com>
On Wed, 8 May 2019 at 23:15, Dmitry Osipenko <digetx@gmail.com> wrote:
>
> 07.05.2019 9:09, Baolin Wang пишет:
> > Since we've introduced one device node parameter for __dma_request_channel(),
> > thus change to the correct function prototype.
> >
> > Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> > ---
> > drivers/soc/tegra/fuse/fuse-tegra20.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/tegra/fuse/fuse-tegra20.c b/drivers/soc/tegra/fuse/fuse-tegra20.c
> > index 49ff017..e2571b6 100644
> > --- a/drivers/soc/tegra/fuse/fuse-tegra20.c
> > +++ b/drivers/soc/tegra/fuse/fuse-tegra20.c
> > @@ -110,7 +110,7 @@ static int tegra20_fuse_probe(struct tegra_fuse *fuse)
> > dma_cap_zero(mask);
> > dma_cap_set(DMA_SLAVE, mask);
> >
> > - fuse->apbdma.chan = __dma_request_channel(&mask, dma_filter, NULL);
> > + fuse->apbdma.chan = __dma_request_channel(&mask, dma_filter, NULL, NULL);
> > if (!fuse->apbdma.chan)
> > return -EPROBE_DEFER;
> >
> >
>
> 1) Kernel should be kept bisect'able by not having intermediate patches
> that break compilation. Hence you should squash the changes into a
> single patch.
>
> 2) Better to replace __dma_request_channel() with dma_request_channel()
> since they are equal.
Good point. I'll change to use dma_request_channel() in next version
if no other objections. Thanks.
--
Baolin Wang
Best Regards
^ permalink raw reply
* [PATCH] dma: dw-axi-dmac: fix null dereference when pointer first is null
From: Colin King @ 2019-05-08 22:33 UTC (permalink / raw)
To: Dan Williams, Vinod Koul, Huang Shijie, dmaengine
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
In the unlikely event that axi_desc_get returns a null desc in the
very first iteration of the while-loop the error exit path ends
up calling axi_desc_put on a null pointer 'first' and this causes
a null pointer dereference. Fix this by adding a null check on
pointer 'first' before calling axi_desc_put.
Addresses-Coverity: ("Explicit null dereference")
fixes: 1fe20f1b8454 ("dmaengine: Introduce DW AXI DMAC driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index b2ac1d2c5b86..a1ce307c502f 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -512,7 +512,8 @@ dma_chan_prep_dma_memcpy(struct dma_chan *dchan, dma_addr_t dst_adr,
return vchan_tx_prep(&chan->vc, &first->vd, flags);
err_desc_get:
- axi_desc_put(first);
+ if (first)
+ axi_desc_put(first);
return NULL;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 2/8] soc: tegra: fuse: Change to the correct __dma_request_channel() prototype
From: Dmitry Osipenko @ 2019-05-08 15:15 UTC (permalink / raw)
To: Baolin Wang, dan.j.williams, vkoul
Cc: thierry.reding, jonathanh, linux-tegra, shawnguo, s.hauer, kernel,
festevam, linux-imx, Zubair.Kakakhel, wsa+renesas, jroedel,
vincent.guittot, dmaengine, linux-kernel, linux-arm-kernel
In-Reply-To: <1ddb1abe8722154dd546d265d5c4536480a24a87.1557206859.git.baolin.wang@linaro.org>
07.05.2019 9:09, Baolin Wang пишет:
> Since we've introduced one device node parameter for __dma_request_channel(),
> thus change to the correct function prototype.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> ---
> drivers/soc/tegra/fuse/fuse-tegra20.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/tegra/fuse/fuse-tegra20.c b/drivers/soc/tegra/fuse/fuse-tegra20.c
> index 49ff017..e2571b6 100644
> --- a/drivers/soc/tegra/fuse/fuse-tegra20.c
> +++ b/drivers/soc/tegra/fuse/fuse-tegra20.c
> @@ -110,7 +110,7 @@ static int tegra20_fuse_probe(struct tegra_fuse *fuse)
> dma_cap_zero(mask);
> dma_cap_set(DMA_SLAVE, mask);
>
> - fuse->apbdma.chan = __dma_request_channel(&mask, dma_filter, NULL);
> + fuse->apbdma.chan = __dma_request_channel(&mask, dma_filter, NULL, NULL);
> if (!fuse->apbdma.chan)
> return -EPROBE_DEFER;
>
>
1) Kernel should be kept bisect'able by not having intermediate patches
that break compilation. Hence you should squash the changes into a
single patch.
2) Better to replace __dma_request_channel() with dma_request_channel()
since they are equal.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1] dmaengine: tegra-apb: Handle DMA_PREP_INTERRUPT flag properly
From: Dmitry Osipenko @ 2019-05-08 12:37 UTC (permalink / raw)
To: Jon Hunter, Laxman Dewangan, Vinod Koul, Thierry Reding,
Ben Dooks
Cc: dmaengine, linux-tegra, linux-kernel
In-Reply-To: <287d7e67-1572-b4f2-d4bb-b1f02f534d47@nvidia.com>
08.05.2019 12:24, Jon Hunter пишет:
>
> On 05/05/2019 19:12, Dmitry Osipenko wrote:
>> The DMA_PREP_INTERRUPT flag means that descriptor's callback should be
>> invoked upon transfer completion and that's it. For some reason driver
>> completely disables the hardware interrupt handling, leaving channel in
>> unusable state if transfer is issued with the flag being unset. Note
>> that there are no occurrences in the relevant drivers that do not set
>> the flag, hence this patch doesn't fix any actual bug and merely fixes
>> potential problem.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>
> From having a look at this, I am guessing that we have never really
> tested the case where DMA_PREP_INTERRUPT flag is not set because as you
> mentioned it does not look like this will work at all!
>
> Is there are use-case you are looking at where you don't set the
> DMA_PREP_INTERRUPT flag?
No. I just noticed it while was checking whether we really need to
handle the BUSY bit state for the Ben's "accurate reporting" patch.
> If not I am wondering if we should even bother supporting this and warn
> if it is not set. AFAICT it does not appear to be mandatory, but maybe
> Vinod can comment more on this.
The warning message will be also okay if it's not mandatory.
^ permalink raw reply
* RE: [EXT] Re: [PATCH v3 10/14] dt-bindings: dma: imx-sdma: add i.mx6ul/6sx compatible name
From: Robin Gong @ 2019-05-08 9:47 UTC (permalink / raw)
To: Rob Herring
Cc: broonie@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de, dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <20190507165601.GA17194@bogus>
> On Wed, 8 May 2019 09:16:38 +0000, Rob Herring wrote:
> On Tue, 7 May 2019 09:16:38 +0000, Robin Gong wrote:
> > Add i.mx6ul and i.mx6sx compatible name.
> >
> > Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> > ---
> > Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
Sorry, no tags and no comments get from V2 for this patch. Just resend the whole
patch set for v3 since other comments addressed from other patch.
>
> If a tag was not added on purpose, please state why and what changed.
^ permalink raw reply
* Re: [PATCH v1] dmaengine: tegra-apb: Handle DMA_PREP_INTERRUPT flag properly
From: Jon Hunter @ 2019-05-08 9:24 UTC (permalink / raw)
To: Dmitry Osipenko, Laxman Dewangan, Vinod Koul, Thierry Reding,
Ben Dooks
Cc: dmaengine, linux-tegra, linux-kernel
In-Reply-To: <20190505181235.14798-1-digetx@gmail.com>
On 05/05/2019 19:12, Dmitry Osipenko wrote:
> The DMA_PREP_INTERRUPT flag means that descriptor's callback should be
> invoked upon transfer completion and that's it. For some reason driver
> completely disables the hardware interrupt handling, leaving channel in
> unusable state if transfer is issued with the flag being unset. Note
> that there are no occurrences in the relevant drivers that do not set
> the flag, hence this patch doesn't fix any actual bug and merely fixes
> potential problem.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
From having a look at this, I am guessing that we have never really
tested the case where DMA_PREP_INTERRUPT flag is not set because as you
mentioned it does not look like this will work at all!
Is there are use-case you are looking at where you don't set the
DMA_PREP_INTERRUPT flag?
If not I am wondering if we should even bother supporting this and warn
if it is not set. AFAICT it does not appear to be mandatory, but maybe
Vinod can comment more on this.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2] mfd: intel-lpss: Set the device in reset state when init
From: Lee Jones @ 2019-05-08 8:23 UTC (permalink / raw)
To: Binbin Wu
Cc: rjw, linux-pm, gregkh, mika.westerberg, linux-kernel, dmaengine,
andriy.shevchenko
In-Reply-To: <1554710950-21212-1-git-send-email-binbin.wu@intel.com>
On Mon, 08 Apr 2019, Binbin Wu wrote:
> In virtualized setup, when system reboots due to warm
> reset interrupt storm is seen.
>
> Call Trace:
> <IRQ>
> dump_stack+0x70/0xa5
> __report_bad_irq+0x2e/0xc0
> note_interrupt+0x248/0x290
> ? add_interrupt_randomness+0x30/0x220
> handle_irq_event_percpu+0x54/0x80
> handle_irq_event+0x39/0x60
> handle_fasteoi_irq+0x91/0x150
> handle_irq+0x108/0x180
> do_IRQ+0x52/0xf0
> common_interrupt+0xf/0xf
> </IRQ>
> RIP: 0033:0x76fc2cfabc1d
> Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
> 94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
> <48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
> 24
> RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
> RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
> RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
> RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
> R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
> R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
> handlers:
> [<000000000d3fa913>] idma64_irq
> Disabling IRQ #27
>
> To avoid interrupt storm, set the device in reset state
> before bringing out the device from reset state.
>
> Changelog v2:
> - correct the subject line by adding "mfd: "
>
> Signed-off-by: Binbin Wu <binbin.wu@intel.com>
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
> drivers/mfd/intel-lpss.c | 3 +++
> 1 file changed, 3 insertions(+)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 2/2] dmaengine: milbeaut: Add Milbeaut AXI DMA controller
From: Kazuhiro Kasai @ 2019-05-07 23:37 UTC (permalink / raw)
To: Vinod Koul
Cc: robh+dt, mark.rutland, dmaengine, devicetree, orito.takao,
sugaya.taichi, kanematsu.shinji, jaswinder.singh,
masami.hiramatsu, linux-kernel
In-Reply-To: <20190507171042.GS16052@vkoul-mobl>
Thank you very much for quick response!
I appreciate your comments.
Maybe it takes long time, but I will try to write v2 patch with virt-dma.
On Tue, May 07, 2019 at 22:40 +0530, Vinod Koul wrote:
> On 07-05-19, 14:39, Kazuhiro Kasai wrote:
> > On Fri, Apr 26, 2019 at 17:16 +0530, Vinod Koul wrote:
> > > On 25-03-19, 13:15, Kazuhiro Kasai wrote:
>
> > > > +struct m10v_dma_chan {
> > > > + struct dma_chan chan;
> > > > + struct m10v_dma_device *mdmac;
> > > > + void __iomem *regs;
> > > > + int irq;
> > > > + struct m10v_dma_desc mdesc;
> > >
> > > So there is a *single* descriptor? Not a list??
> >
> > Yes, single descriptor.
>
> And why is that, you can create a list and keep getting descriptors and
> issue them to hardware and get better pref!
I understand, thank you.
>
> > > > +static dma_cookie_t m10v_xdmac_tx_submit(struct dma_async_tx_descriptor *txd)
> > > > +{
> > > > + struct m10v_dma_chan *mchan = to_m10v_dma_chan(txd->chan);
> > > > + dma_cookie_t cookie;
> > > > + unsigned long flags;
> > > > +
> > > > + spin_lock_irqsave(&mchan->lock, flags);
> > > > + cookie = dma_cookie_assign(txd);
> > > > + spin_unlock_irqrestore(&mchan->lock, flags);
> > > > +
> > > > + return cookie;
> > >
> > > sounds like vchan_tx_submit() i think you can use virt-dma layer and then
> > > get rid of artificial limit in driver and be able to queue up the txn on
> > > dmaengine.
> >
> > OK, I will try to use virt-dma layer in next version.
>
> And you will get lists to manage descriptor for free! so you can use
> that to support multiple txns as well!
It sounds great! I start to study virt-dma layer for next version.
>
> > > > +static struct dma_async_tx_descriptor *
> > > > +m10v_xdmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
> > > > + dma_addr_t src, size_t len, unsigned long flags)
> > > > +{
> > > > + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> > > > +
> > > > + dma_async_tx_descriptor_init(&mchan->mdesc.txd, chan);
> > > > + mchan->mdesc.txd.tx_submit = m10v_xdmac_tx_submit;
> > > > + mchan->mdesc.txd.callback = NULL;
> > > > + mchan->mdesc.txd.flags = flags;
> > > > + mchan->mdesc.txd.cookie = -EBUSY;
> > > > +
> > > > + mchan->mdesc.len = len;
> > > > + mchan->mdesc.src = src;
> > > > + mchan->mdesc.dst = dst;
> > > > +
> > > > + return &mchan->mdesc.txd;
> > >
> > > So you support single descriptor and dont check if this has been already
> > > configured. So I guess this has been tested by doing txn one at a time
> > > and not submitted bunch of txn and wait for them to complete. Please fix
> > > that to really enable dmaengine capabilities.
> >
> > Thank you for advice. I want to fix it and I have 2 questions.
> >
> > 1. Does virt-dma layer help to fix this?
>
> Yes
It sounds very good news for me. Thank you.
>
> > 2. Can dmatest test that dmaengine capabilities?
>
> Yes for memcpy operations, see Documentation/driver-api/dmaengine/dmatest.rst
>
OK, I will read the document.
Thanks,
Kasai
^ permalink raw reply
* Re: [PATCH 2/2] dmaengine: milbeaut: Add Milbeaut AXI DMA controller
From: Vinod Koul @ 2019-05-07 17:10 UTC (permalink / raw)
To: Kazuhiro Kasai
Cc: robh+dt, mark.rutland, dmaengine, devicetree, orito.takao,
sugaya.taichi, kanematsu.shinji, jaswinder.singh,
masami.hiramatsu, linux-kernel
In-Reply-To: <20190507053924.GA3359@ubuntu>
On 07-05-19, 14:39, Kazuhiro Kasai wrote:
> On Fri, Apr 26, 2019 at 17:16 +0530, Vinod Koul wrote:
> > On 25-03-19, 13:15, Kazuhiro Kasai wrote:
> > > +struct m10v_dma_chan {
> > > + struct dma_chan chan;
> > > + struct m10v_dma_device *mdmac;
> > > + void __iomem *regs;
> > > + int irq;
> > > + struct m10v_dma_desc mdesc;
> >
> > So there is a *single* descriptor? Not a list??
>
> Yes, single descriptor.
And why is that, you can create a list and keep getting descriptors and
issue them to hardware and get better pref!
> > > +static dma_cookie_t m10v_xdmac_tx_submit(struct dma_async_tx_descriptor *txd)
> > > +{
> > > + struct m10v_dma_chan *mchan = to_m10v_dma_chan(txd->chan);
> > > + dma_cookie_t cookie;
> > > + unsigned long flags;
> > > +
> > > + spin_lock_irqsave(&mchan->lock, flags);
> > > + cookie = dma_cookie_assign(txd);
> > > + spin_unlock_irqrestore(&mchan->lock, flags);
> > > +
> > > + return cookie;
> >
> > sounds like vchan_tx_submit() i think you can use virt-dma layer and then
> > get rid of artificial limit in driver and be able to queue up the txn on
> > dmaengine.
>
> OK, I will try to use virt-dma layer in next version.
And you will get lists to manage descriptor for free! so you can use
that to support multiple txns as well!
> > > +static struct dma_async_tx_descriptor *
> > > +m10v_xdmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
> > > + dma_addr_t src, size_t len, unsigned long flags)
> > > +{
> > > + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> > > +
> > > + dma_async_tx_descriptor_init(&mchan->mdesc.txd, chan);
> > > + mchan->mdesc.txd.tx_submit = m10v_xdmac_tx_submit;
> > > + mchan->mdesc.txd.callback = NULL;
> > > + mchan->mdesc.txd.flags = flags;
> > > + mchan->mdesc.txd.cookie = -EBUSY;
> > > +
> > > + mchan->mdesc.len = len;
> > > + mchan->mdesc.src = src;
> > > + mchan->mdesc.dst = dst;
> > > +
> > > + return &mchan->mdesc.txd;
> >
> > So you support single descriptor and dont check if this has been already
> > configured. So I guess this has been tested by doing txn one at a time
> > and not submitted bunch of txn and wait for them to complete. Please fix
> > that to really enable dmaengine capabilities.
>
> Thank you for advice. I want to fix it and I have 2 questions.
>
> 1. Does virt-dma layer help to fix this?
Yes
> 2. Can dmatest test that dmaengine capabilities?
Yes for memcpy operations, see Documentation/driver-api/dmaengine/dmatest.rst
--
~Vinod
^ permalink raw reply
* Re: [PATCH v3 10/14] dt-bindings: dma: imx-sdma: add i.mx6ul/6sx compatible name
From: Rob Herring @ 2019-05-07 16:56 UTC (permalink / raw)
To: Robin Gong
Cc: robh@kernel.org, broonie@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de, dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1557249513-4903-11-git-send-email-yibin.gong@nxp.com>
On Tue, 7 May 2019 09:16:38 +0000, Robin Gong wrote:
> Add i.mx6ul and i.mx6sx compatible name.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.
If a tag was not added on purpose, please state why and what changed.
^ permalink raw reply
* Re: [RFC v6 1/6] dmaengine: Add Synopsys eDMA IP core driver
From: Vinod Koul @ 2019-05-07 9:56 UTC (permalink / raw)
To: Gustavo Pimentel
Cc: linux-pci@vger.kernel.org, dmaengine@vger.kernel.org,
Dan Williams, Andy Shevchenko, Russell King, Joao Pinto
In-Reply-To: <305100E33629484CBB767107E4246BBB0A238D2C@de02wembxa.internal.synopsys.com>
On 07-05-19, 09:08, Gustavo Pimentel wrote:
> On Tue, May 7, 2019 at 6:3:10, Vinod Koul <vkoul@kernel.org> wrote:
> > On 06-05-19, 16:42, Gustavo Pimentel wrote:
> > > > > +static struct dma_async_tx_descriptor *
> > > > > +dw_edma_device_transfer(struct dw_edma_transfer *xfer)
> > > > > +{
> > > > > + struct dw_edma_chan *chan = dchan2dw_edma_chan(xfer->dchan);
> > > > > + enum dma_transfer_direction direction = xfer->direction;
> > > > > + phys_addr_t src_addr, dst_addr;
> > > > > + struct scatterlist *sg = NULL;
> > > > > + struct dw_edma_chunk *chunk;
> > > > > + struct dw_edma_burst *burst;
> > > > > + struct dw_edma_desc *desc;
> > > > > + u32 cnt;
> > > > > + int i;
> > > > > +
> > > > > + if ((direction == DMA_MEM_TO_DEV && chan->dir == EDMA_DIR_WRITE) ||
> > > > > + (direction == DMA_DEV_TO_MEM && chan->dir == EDMA_DIR_READ))
> > > > > + return NULL;
> > > > > +
> > > > > + if (xfer->cyclic) {
> > > > > + if (!xfer->xfer.cyclic.len || !xfer->xfer.cyclic.cnt)
> > > > > + return NULL;
> > > > > + } else {
> > > > > + if (xfer->xfer.sg.len < 1)
> > > > > + return NULL;
> > > > > + }
> > > > > +
> > > > > + if (!chan->configured)
> > > > > + return NULL;
> > > > > +
> > > > > + desc = dw_edma_alloc_desc(chan);
> > > > > + if (unlikely(!desc))
> > > > > + goto err_alloc;
> > > > > +
> > > > > + chunk = dw_edma_alloc_chunk(desc);
> > > > > + if (unlikely(!chunk))
> > > > > + goto err_alloc;
> > > > > +
> > > > > + src_addr = chan->config.src_addr;
> > > > > + dst_addr = chan->config.dst_addr;
> > > > > +
> > > > > + if (xfer->cyclic) {
> > > > > + cnt = xfer->xfer.cyclic.cnt;
> > > > > + } else {
> > > > > + cnt = xfer->xfer.sg.len;
> > > > > + sg = xfer->xfer.sg.sgl;
> > > > > + }
> > > > > +
> > > > > + for (i = 0; i < cnt; i++) {
> > > > > + if (!xfer->cyclic && !sg)
> > > > > + break;
> > > > > +
> > > > > + if (chunk->bursts_alloc == chan->ll_max) {
> > > > > + chunk = dw_edma_alloc_chunk(desc);
> > > > > + if (unlikely(!chunk))
> > > > > + goto err_alloc;
> > > > > + }
> > > > > +
> > > > > + burst = dw_edma_alloc_burst(chunk);
> > > > > + if (unlikely(!burst))
> > > > > + goto err_alloc;
> > > > > +
> > > > > + if (xfer->cyclic)
> > > > > + burst->sz = xfer->xfer.cyclic.len;
> > > > > + else
> > > > > + burst->sz = sg_dma_len(sg);
> > > > > +
> > > > > + chunk->ll_region.sz += burst->sz;
> > > > > + desc->alloc_sz += burst->sz;
> > > > > +
> > > > > + if (direction == DMA_DEV_TO_MEM) {
> > > > > + burst->sar = src_addr;
> > > >
> > > > We are device to mem, so src is peripheral.. okay
> > > >
> > > > > + if (xfer->cyclic) {
> > > > > + burst->dar = xfer->xfer.cyclic.paddr;
> > > > > + } else {
> > > > > + burst->dar = sg_dma_address(sg);
> > > > > + src_addr += sg_dma_len(sg);
> > > >
> > > > and we increment the src, doesn't make sense to me!
> > > >
> > > > > + }
> > > > > + } else {
> > > > > + burst->dar = dst_addr;
> > > > > + if (xfer->cyclic) {
> > > > > + burst->sar = xfer->xfer.cyclic.paddr;
> > > > > + } else {
> > > > > + burst->sar = sg_dma_address(sg);
> > > > > + dst_addr += sg_dma_len(sg);
> > > >
> > > > same here as well
> > >
> > > This is hard to explain in words...
> > > Well, in my perspective I want to transfer a piece of memory from the
> > > peripheral into local RAM
> >
> > Right and most of the case RAM address (sg) needs to increment whereas
> > peripheral is a constant one
> >
> > > Through the DMA client API I'll break this piece of memory in several
> > > small parts and add all into a list (scatter-gather), right?
> > > Each element of the scatter-gather has the sg_dma_address (in the
> > > DMA_DEV_TO_MEM case will be the destination address) and the
> > > corresponding size.
> >
> > Correct
> >
> > > However, I still need the other address (in the DMA_DEV_TO_MEM case will
> > > be the source address) for that small part of memory.
> > > Since I get that address from the config, I still need to increment the
> > > source address in the same proportion of the destination address, in
> > > other words, the increment will be the part size.
> >
> > I don't think so. Typically the device address is a FIFO, which does not
> > increment and you keep pushing data at same address. It is not a memory
>
> In my use case, it's a memory, perhaps that is what is causing this
> confusing.
> I'm copying "plain and flat" data from point A to B, with the
> particularity that the peripheral memory is always continuous and the CPU
> memory can be constituted by scatter-gather chunks of contiguous memory
Then why should it be slave transfer, it should be treated as memcpy
with src and dst sg lists..
--
~Vinod
^ permalink raw reply
* RE: [RFC v6 3/6] dmaengine: Add Synopsys eDMA IP version 0 debugfs support
From: Gustavo Pimentel @ 2019-05-07 9:48 UTC (permalink / raw)
To: Vinod Koul, Gustavo Pimentel
Cc: linux-pci@vger.kernel.org, dmaengine@vger.kernel.org,
Dan Williams, Andy Shevchenko, Russell King, Joao Pinto
In-Reply-To: <20190507051136.GB16052@vkoul-mobl>
On Tue, May 7, 2019 at 6:11:36, Vinod Koul <vkoul@kernel.org> wrote:
> On 06-05-19, 17:09, Gustavo Pimentel wrote:
> > Hi Vinod,
> >
> > On Mon, May 6, 2019 at 13:7:10, Vinod Koul <vkoul@kernel.org> wrote:
> >
> > > On 23-04-19, 20:30, Gustavo Pimentel wrote:
> > >
> > > > int dw_edma_v0_core_debugfs_on(struct dw_edma_chip *chip)
> > > > {
> > > > - return 0;
> > > > + return dw_edma_v0_debugfs_on(chip);
> > >
> > > who calls this?
> >
> > The main driver. This was done like this for 2 reasons:
> > 1) To not break the patch #1 compilation
> > 2) Since the code it's to extensive, I decided to break it in another
> > patch.
>
> Hmm I guess I missed that one. I was actually looking at usage and not
> questioning split :)
>
> > > > +static int dw_edma_debugfs_u32_get(void *data, u64 *val)
> > > > +{
> > > > + if (dw->mode == EDMA_MODE_LEGACY &&
> > > > + data >= (void *)®s->type.legacy.ch) {
> > > > + void *ptr = (void *)®s->type.legacy.ch;
> > > > + u32 viewport_sel = 0;
> > > > + unsigned long flags;
> > > > + u16 ch;
> > > > +
> > > > + for (ch = 0; ch < dw->wr_ch_cnt; ch++)
> > > > + if (lim[0][ch].start >= data && data < lim[0][ch].end) {
> > > > + ptr += (data - lim[0][ch].start);
> > > > + goto legacy_sel_wr;
> > > > + }
> > > > +
> > > > + for (ch = 0; ch < dw->rd_ch_cnt; ch++)
> > > > + if (lim[1][ch].start >= data && data < lim[1][ch].end) {
> > > > + ptr += (data - lim[1][ch].start);
> > > > + goto legacy_sel_rd;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +legacy_sel_rd:
> > > > + viewport_sel = BIT(31);
> > > > +legacy_sel_wr:
> > > > + viewport_sel |= FIELD_PREP(EDMA_V0_VIEWPORT_MASK, ch);
> > > > +
> > > > + raw_spin_lock_irqsave(&dw->lock, flags);
> > > > +
> > > > + writel(viewport_sel, ®s->type.legacy.viewport_sel);
> > > > + *val = readl((u32 *)ptr);
> > >
> > > why do you need the cast?
> >
> > I can't tell from my head, but I think checkpatch or some code analysis
> > tool was complaining about not having that.
>
> ptr is void, so there is no need for casts to or away from void.
>
> > > > +static int dw_edma_debugfs_regs(void)
> > > > +{
> > > > + const struct debugfs_entries debugfs_regs[] = {
> > > > + REGISTER(ctrl_data_arb_prior),
> > > > + REGISTER(ctrl),
> > > > + };
> > > > + struct dentry *regs_dir;
> > > > + int nr_entries, err;
> > > > +
> > > > + regs_dir = debugfs_create_dir(REGISTERS_STR, base_dir);
> > > > + if (!regs_dir)
> > > > + return -EPERM;
> > > > +
> > > > + nr_entries = ARRAY_SIZE(debugfs_regs);
> > > > + err = dw_edma_debugfs_create_x32(debugfs_regs, nr_entries, regs_dir);
> > > > + if (err)
> > > > + return err;
> > > > +
> > > > + err = dw_edma_debugfs_regs_wr(regs_dir);
> > > > + if (err)
> > > > + return err;
> > > > +
> > > > + err = dw_edma_debugfs_regs_rd(regs_dir);
> > > > + if (err)
> > > > + return err;
> > > > +
> > > > + return 0;
> > >
> > > single return err would suffice right?
> >
> > By looking now to this code, I decided to remove the err variable and
> > perform the if immediately on the function, if the result is different
> > from 0 it goes directly to a return -EPERM.
>
> And one more things, we do not need to check errors on debugfs calls,
> and if it fails it fails...
Ok, makes sense. I'll remove all return validation relatively to debugfs
calls.
>
> --
> ~Vinod
^ permalink raw reply
* [PATCH v3 10/14] dt-bindings: dma: imx-sdma: add i.mx6ul/6sx compatible name
From: Robin Gong @ 2019-05-07 9:16 UTC (permalink / raw)
To: robh@kernel.org, broonie@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de
Cc: dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1557249513-4903-1-git-send-email-yibin.gong@nxp.com>
Add i.mx6ul and i.mx6sx compatible name.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index 9d8bbac..d024a83 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -9,6 +9,8 @@ Required properties:
"fsl,imx53-sdma"
"fsl,imx6q-sdma"
"fsl,imx7d-sdma"
+ "fsl,imx6sx-sdma"
+ "fsl,imx6ul-sdma"
"fsl,imx8mq-sdma"
The -to variants should be preferred since they allow to determine the
correct ROM script addresses needed for the driver to work without additional
--
2.7.4
^ permalink raw reply related
* [PATCH v3 07/14] spi: imx: remove ERR009165 workaround on i.mx6ul
From: Robin Gong @ 2019-05-07 9:16 UTC (permalink / raw)
To: robh@kernel.org, broonie@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de
Cc: dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1557249513-4903-1-git-send-email-yibin.gong@nxp.com>
ERR009165 fixed on i.mx6ul/6ull/6sll. All other i.mx6/7 and
i.mx8m/8mm still need this errata. Please refer to nxp official
errata document from https://www.nxp.com/ .
For removing workaround on those chips. Add new i.mx6ul type.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/spi/spi-imx.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 45 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6795910..91660dc 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -57,6 +57,7 @@ enum spi_imx_devtype {
IMX35_CSPI, /* CSPI on all i.mx except above */
IMX51_ECSPI, /* ECSPI on i.mx51 */
IMX53_ECSPI, /* ECSPI on i.mx53 and later */
+ IMX6UL_ECSPI, /* ERR009165 fix from i.mx6ul */
};
struct spi_imx_data;
@@ -75,6 +76,11 @@ struct spi_imx_devtype_data {
bool has_slavemode;
unsigned int fifo_size;
bool dynamic_burst;
+ /*
+ * ERR009165 fixed or not:
+ * https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
+ */
+ bool tx_glitch_fixed;
enum spi_imx_devtype devtype;
};
@@ -128,7 +134,8 @@ static inline int is_imx35_cspi(struct spi_imx_data *d)
static inline int is_imx51_ecspi(struct spi_imx_data *d)
{
- return d->devtype_data->devtype == IMX51_ECSPI;
+ return d->devtype_data->devtype == IMX51_ECSPI ||
+ d->devtype_data->devtype == IMX6UL_ECSPI;
}
static inline int is_imx53_ecspi(struct spi_imx_data *d)
@@ -585,9 +592,16 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
spi_imx->spi_bus_clk = clk;
- /* ERR009165: work in XHC mode as PIO */
- if (spi_imx->usedma)
- ctrl &= ~MX51_ECSPI_CTRL_SMC;
+ /*
+ * ERR009165: work in XHC mode instead of SMC as PIO on the chips
+ * before i.mx6ul.
+ */
+ if (spi_imx->usedma) {
+ if (spi_imx->devtype_data->tx_glitch_fixed)
+ ctrl |= MX51_ECSPI_CTRL_SMC;
+ else
+ ctrl &= ~MX51_ECSPI_CTRL_SMC;
+ }
writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
@@ -615,6 +629,8 @@ static void mx51_setup_wml(struct spi_imx_data *spi_imx)
{
u32 tx_wml = 0;
+ if (spi_imx->devtype_data->tx_glitch_fixed)
+ tx_wml = spi_imx->wml;
/*
* Configure the DMA register: setup the watermark
* and enable DMA request.
@@ -1012,6 +1028,23 @@ static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
.devtype = IMX53_ECSPI,
};
+static struct spi_imx_devtype_data imx6ul_ecspi_devtype_data = {
+ .intctrl = mx51_ecspi_intctrl,
+ .prepare_message = mx51_ecspi_prepare_message,
+ .prepare_transfer = mx51_ecspi_prepare_transfer,
+ .trigger = mx51_ecspi_trigger,
+ .rx_available = mx51_ecspi_rx_available,
+ .reset = mx51_ecspi_reset,
+ .setup_wml = mx51_setup_wml,
+ .fifo_size = 64,
+ .has_dmamode = true,
+ .dynamic_burst = true,
+ .has_slavemode = true,
+ .tx_glitch_fixed = true,
+ .disable = mx51_ecspi_disable,
+ .devtype = IMX6UL_ECSPI,
+};
+
static const struct platform_device_id spi_imx_devtype[] = {
{
.name = "imx1-cspi",
@@ -1035,6 +1068,9 @@ static const struct platform_device_id spi_imx_devtype[] = {
.name = "imx53-ecspi",
.driver_data = (kernel_ulong_t) &imx53_ecspi_devtype_data,
}, {
+ .name = "imx6ul-ecspi",
+ .driver_data = (kernel_ulong_t) &imx6ul_ecspi_devtype_data,
+ }, {
/* sentinel */
}
};
@@ -1047,6 +1083,7 @@ static const struct of_device_id spi_imx_dt_ids[] = {
{ .compatible = "fsl,imx35-cspi", .data = &imx35_cspi_devtype_data, },
{ .compatible = "fsl,imx51-ecspi", .data = &imx51_ecspi_devtype_data, },
{ .compatible = "fsl,imx53-ecspi", .data = &imx53_ecspi_devtype_data, },
+ { .compatible = "fsl,imx6ul-ecspi", .data = &imx6ul_ecspi_devtype_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, spi_imx_dt_ids);
@@ -1178,7 +1215,10 @@ static int spi_imx_dma_configure(struct spi_master *master)
* For ERR009165 with tx_wml = 0 could enlarge burst size to fifo size
* to speed up fifo filling as possible.
*/
- tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
+ if (spi_imx->devtype_data->tx_glitch_fixed)
+ tx.dst_maxburst = spi_imx->wml;
+ else
+ tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
ret = dmaengine_slave_config(master->dma_tx, &tx);
if (ret) {
dev_err(spi_imx->dev, "TX dma configuration failed with %d\n", ret);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 11/14] dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm
From: Robin Gong @ 2019-05-07 9:16 UTC (permalink / raw)
To: robh@kernel.org, broonie@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de
Cc: dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1557249513-4903-1-git-send-email-yibin.gong@nxp.com>
Because the number of ecspi1 rx event on i.mx8mm is 0, the condition
check ignore such special case without dma channel enabled, which caused
ecspi1 rx works failed. Actually, no need to check event_id0, checking
event_id1 is enough for DEV_2_DEV case because it's so lucky that event_id1
never be 0.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/dma/imx-sdma.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index a495c7f..86594fc 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1370,8 +1370,8 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
sdma_channel_synchronize(chan);
- if (sdmac->event_id0)
- sdma_event_disable(sdmac, sdmac->event_id0);
+ sdma_event_disable(sdmac, sdmac->event_id0);
+
if (sdmac->event_id1)
sdma_event_disable(sdmac, sdmac->event_id1);
@@ -1670,11 +1670,9 @@ static int sdma_config(struct dma_chan *chan,
memcpy(&sdmac->slave_config, dmaengine_cfg, sizeof(*dmaengine_cfg));
/* Set ENBLn earlier to make sure dma request triggered after that */
- if (sdmac->event_id0) {
- if (sdmac->event_id0 >= sdmac->sdma->drvdata->num_events)
- return -EINVAL;
- sdma_event_enable(sdmac, sdmac->event_id0);
- }
+ if (sdmac->event_id0 >= sdmac->sdma->drvdata->num_events)
+ return -EINVAL;
+ sdma_event_enable(sdmac, sdmac->event_id0);
if (sdmac->event_id1) {
if (sdmac->event_id1 >= sdmac->sdma->drvdata->num_events)
--
2.7.4
^ permalink raw reply related
* [PATCH v3 12/14] ARM: dts: imx6ul: add dma support on ecspi
From: Robin Gong @ 2019-05-07 9:16 UTC (permalink / raw)
To: robh@kernel.org, broonie@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de
Cc: dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1557249513-4903-1-git-send-email-yibin.gong@nxp.com>
Add dma support on ecspi.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
arch/arm/boot/dts/imx6ul.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index bbf010c..880b9ee 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -226,6 +226,8 @@
clocks = <&clks IMX6UL_CLK_ECSPI1>,
<&clks IMX6UL_CLK_ECSPI1>;
clock-names = "ipg", "per";
+ dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -238,6 +240,8 @@
clocks = <&clks IMX6UL_CLK_ECSPI2>,
<&clks IMX6UL_CLK_ECSPI2>;
clock-names = "ipg", "per";
+ dmas = <&sdma 5 7 1>, <&sdma 6 7 2>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -250,6 +254,8 @@
clocks = <&clks IMX6UL_CLK_ECSPI3>,
<&clks IMX6UL_CLK_ECSPI3>;
clock-names = "ipg", "per";
+ dmas = <&sdma 7 7 1>, <&sdma 8 7 2>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -262,6 +268,8 @@
clocks = <&clks IMX6UL_CLK_ECSPI4>,
<&clks IMX6UL_CLK_ECSPI4>;
clock-names = "ipg", "per";
+ dmas = <&sdma 9 7 1>, <&sdma 10 7 2>;
+ dma-names = "rx", "tx";
status = "disabled";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 14/14] arm64: defconfig: Enable SDMA on i.mx8mq/8mm
From: Robin Gong @ 2019-05-07 9:17 UTC (permalink / raw)
To: robh@kernel.org, broonie@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de
Cc: dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1557249513-4903-1-git-send-email-yibin.gong@nxp.com>
Enable SDMA support on i.mx8mq/8mm chips, including enabling
CONFIG_FW_LOADER_USER_HELPER/CONFIG_FW_LOADER_USER_HELPER_FALLBACK
for firmware loaded by udev.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 17daa97..7081817 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -203,6 +203,8 @@ CONFIG_NET_9P_VIRTIO=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_FW_LOADER_USER_HELPER=y
+CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=32
CONFIG_HISILICON_LPC=y
@@ -635,6 +637,7 @@ CONFIG_RTC_DRV_IMX_SC=m
CONFIG_RTC_DRV_XGENE=y
CONFIG_DMADEVICES=y
CONFIG_DMA_BCM2835=m
+CONFIG_IMX_SDMA=y
CONFIG_K3_DMA=y
CONFIG_MV_XOR_V2=y
CONFIG_PL330_DMA=y
--
2.7.4
^ permalink raw reply related
* [PATCH v3 13/14] ARM: dts: imx6sll: correct sdma compatible
From: Robin Gong @ 2019-05-07 9:16 UTC (permalink / raw)
To: robh@kernel.org, broonie@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de
Cc: dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1557249513-4903-1-git-send-email-yibin.gong@nxp.com>
Correct sdma compatible since ecspi errata ERR009165 has been fixed
on i.mx6sll as i.mx6ul.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
arch/arm/boot/dts/imx6sll.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
index 1b4899f..d810e10 100644
--- a/arch/arm/boot/dts/imx6sll.dtsi
+++ b/arch/arm/boot/dts/imx6sll.dtsi
@@ -619,7 +619,7 @@
};
sdma: dma-controller@20ec000 {
- compatible = "fsl,imx6sll-sdma", "fsl,imx35-sdma";
+ compatible = "fsl,imx6sll-sdma", "fsl,imx6ul-sdma";
reg = <0x020ec000 0x4000>;
interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SLL_CLK_IPG>,
--
2.7.4
^ permalink raw reply related
* [PATCH v3 06/14] spi: imx: fix ERR009165
From: Robin Gong @ 2019-05-07 9:16 UTC (permalink / raw)
To: robh@kernel.org, broonie@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de
Cc: dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1557249513-4903-1-git-send-email-yibin.gong@nxp.com>
Change to XCH mode even in dma mode, please refer to the below
errata:
https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/spi/spi-imx.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 09c9a1e..6795910 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -585,8 +585,9 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
spi_imx->spi_bus_clk = clk;
+ /* ERR009165: work in XHC mode as PIO */
if (spi_imx->usedma)
- ctrl |= MX51_ECSPI_CTRL_SMC;
+ ctrl &= ~MX51_ECSPI_CTRL_SMC;
writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
@@ -612,12 +613,14 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
static void mx51_setup_wml(struct spi_imx_data *spi_imx)
{
+ u32 tx_wml = 0;
+
/*
* Configure the DMA register: setup the watermark
* and enable DMA request.
*/
writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml - 1) |
- MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
+ MX51_ECSPI_DMA_TX_WML(tx_wml) |
MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
@@ -1171,7 +1174,11 @@ static int spi_imx_dma_configure(struct spi_master *master)
tx.direction = DMA_MEM_TO_DEV;
tx.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
tx.dst_addr_width = buswidth;
- tx.dst_maxburst = spi_imx->wml;
+ /*
+ * For ERR009165 with tx_wml = 0 could enlarge burst size to fifo size
+ * to speed up fifo filling as possible.
+ */
+ tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
ret = dmaengine_slave_config(master->dma_tx, &tx);
if (ret) {
dev_err(spi_imx->dev, "TX dma configuration failed with %d\n", ret);
@@ -1265,10 +1272,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
{
int ret;
- /* use pio mode for i.mx6dl chip TKT238285 */
- if (of_machine_is_compatible("fsl,imx6dl"))
- return 0;
-
spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
/* Prepare for TX DMA: */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 09/14] dmaengine: imx-sdma: remove ERR009165 on i.mx6ul
From: Robin Gong @ 2019-05-07 9:16 UTC (permalink / raw)
To: robh@kernel.org, broonie@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, mark.rutland@arm.com,
u.kleine-koenig@pengutronix.de, plyatov@gmail.com,
vkoul@kernel.org, dan.j.williams@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com,
l.stach@pengutronix.de
Cc: dl-linux-imx, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1557249513-4903-1-git-send-email-yibin.gong@nxp.com>
ECSPI issue fixed from i.mx6ul at hardware level, no need
ERR009165 anymore on those chips such as i.mx8mq. Add i.mx6sx
from where i.mx6ul source.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/dma/imx-sdma.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 352b0d5..a495c7f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -419,6 +419,13 @@ struct sdma_driver_data {
int num_events;
struct sdma_script_start_addrs *script_addrs;
bool check_ratio;
+ /*
+ * ecspi ERR009165 fixed should be done in sdma script
+ * and it has been fixed in soc from i.mx6ul.
+ * please get more information from the below link:
+ * https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
+ */
+ bool ecspi_fixed;
};
struct sdma_engine {
@@ -539,6 +546,31 @@ static struct sdma_driver_data sdma_imx6q = {
.script_addrs = &sdma_script_imx6q,
};
+static struct sdma_script_start_addrs sdma_script_imx6sx = {
+ .ap_2_ap_addr = 642,
+ .uart_2_mcu_addr = 817,
+ .mcu_2_app_addr = 747,
+ .uartsh_2_mcu_addr = 1032,
+ .mcu_2_shp_addr = 960,
+ .app_2_mcu_addr = 683,
+ .shp_2_mcu_addr = 891,
+ .spdif_2_mcu_addr = 1100,
+ .mcu_2_spdif_addr = 1134,
+};
+
+static struct sdma_driver_data sdma_imx6sx = {
+ .chnenbl0 = SDMA_CHNENBL0_IMX35,
+ .num_events = 48,
+ .script_addrs = &sdma_script_imx6sx,
+};
+
+static struct sdma_driver_data sdma_imx6ul = {
+ .chnenbl0 = SDMA_CHNENBL0_IMX35,
+ .num_events = 48,
+ .script_addrs = &sdma_script_imx6sx,
+ .ecspi_fixed = true,
+};
+
static struct sdma_script_start_addrs sdma_script_imx7d = {
.ap_2_ap_addr = 644,
.uart_2_mcu_addr = 819,
@@ -584,9 +616,15 @@ static const struct platform_device_id sdma_devtypes[] = {
.name = "imx6q-sdma",
.driver_data = (unsigned long)&sdma_imx6q,
}, {
+ .name = "imx6sx-sdma",
+ .driver_data = (unsigned long)&sdma_imx6sx,
+ }, {
.name = "imx7d-sdma",
.driver_data = (unsigned long)&sdma_imx7d,
}, {
+ .name = "imx6ul-sdma",
+ .driver_data = (unsigned long)&sdma_imx6ul,
+ }, {
.name = "imx8mq-sdma",
.driver_data = (unsigned long)&sdma_imx8mq,
}, {
@@ -602,7 +640,9 @@ static const struct of_device_id sdma_dt_ids[] = {
{ .compatible = "fsl,imx35-sdma", .data = &sdma_imx35, },
{ .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
{ .compatible = "fsl,imx25-sdma", .data = &sdma_imx25, },
+ { .compatible = "fsl,imx6sx-sdma", .data = &sdma_imx6sx, },
{ .compatible = "fsl,imx7d-sdma", .data = &sdma_imx7d, },
+ { .compatible = "fsl,imx6ul-sdma", .data = &sdma_imx6ul, },
{ .compatible = "fsl,imx8mq-sdma", .data = &sdma_imx8mq, },
{ /* sentinel */ }
};
@@ -1166,8 +1206,17 @@ static int sdma_config_channel(struct dma_chan *chan)
if (sdmac->peripheral_type == IMX_DMATYPE_ASRC_SP ||
sdmac->peripheral_type == IMX_DMATYPE_ASRC)
sdma_set_watermarklevel_for_p2p(sdmac);
- } else
+ } else {
+ /*
+ * ERR009165 fixed from i.mx6ul, no errata need,
+ * set bit31 to let sdma script skip the errata.
+ */
+ if (sdmac->peripheral_type == IMX_DMATYPE_CSPI &&
+ sdmac->direction == DMA_MEM_TO_DEV &&
+ sdmac->sdma->drvdata->ecspi_fixed)
+ __set_bit(31, &sdmac->watermark_level);
__set_bit(sdmac->event_id0, sdmac->event_mask);
+ }
/* Address */
sdmac->shp_addr = sdmac->per_address;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox