* [next,03/25] dmaengine: Use dev_get_drvdata()
From: Kefeng Wang @ 2019-04-23 7:49 UTC (permalink / raw)
To: linux-kernel; +Cc: Masahiro Yamada, Kefeng Wang, Vinod Koul, dmaengine
Using dev_get_drvdata directly.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: dmaengine@vger.kernel.org
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/dma/bcm-sba-raid.c | 3 +--
drivers/dma/nbpfaxi.c | 4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
index 72878ac5c78d..fa81d0177765 100644
--- a/drivers/dma/bcm-sba-raid.c
+++ b/drivers/dma/bcm-sba-raid.c
@@ -1459,8 +1459,7 @@ static void sba_receive_message(struct mbox_client *cl, void *msg)
static int sba_debugfs_stats_show(struct seq_file *file, void *offset)
{
- struct platform_device *pdev = to_platform_device(file->private);
- struct sba_device *sba = platform_get_drvdata(pdev);
+ struct sba_device *sba = dev_get_drvdata(file->private);
/* Write stats in file */
sba_write_stats_in_seqfile(sba, file);
diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c
index a67b292190f4..594409a6e975 100644
--- a/drivers/dma/nbpfaxi.c
+++ b/drivers/dma/nbpfaxi.c
@@ -1491,14 +1491,14 @@ MODULE_DEVICE_TABLE(platform, nbpf_ids);
#ifdef CONFIG_PM
static int nbpf_runtime_suspend(struct device *dev)
{
- struct nbpf_device *nbpf = platform_get_drvdata(to_platform_device(dev));
+ struct nbpf_device *nbpf = dev_get_drvdata(dev);
clk_disable_unprepare(nbpf->clk);
return 0;
}
static int nbpf_runtime_resume(struct device *dev)
{
- struct nbpf_device *nbpf = platform_get_drvdata(to_platform_device(dev));
+ struct nbpf_device *nbpf = dev_get_drvdata(dev);
return clk_prepare_enable(nbpf->clk);
}
#endif
^ permalink raw reply related
* [PATCH next 03/25] dmaengine: Use dev_get_drvdata()
From: Kefeng Wang @ 2019-04-23 7:49 UTC (permalink / raw)
To: linux-kernel; +Cc: Masahiro Yamada, Kefeng Wang, Vinod Koul, dmaengine
In-Reply-To: <20190423075020.173734-1-wangkefeng.wang@huawei.com>
Using dev_get_drvdata directly.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: dmaengine@vger.kernel.org
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/dma/bcm-sba-raid.c | 3 +--
drivers/dma/nbpfaxi.c | 4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
index 72878ac5c78d..fa81d0177765 100644
--- a/drivers/dma/bcm-sba-raid.c
+++ b/drivers/dma/bcm-sba-raid.c
@@ -1459,8 +1459,7 @@ static void sba_receive_message(struct mbox_client *cl, void *msg)
static int sba_debugfs_stats_show(struct seq_file *file, void *offset)
{
- struct platform_device *pdev = to_platform_device(file->private);
- struct sba_device *sba = platform_get_drvdata(pdev);
+ struct sba_device *sba = dev_get_drvdata(file->private);
/* Write stats in file */
sba_write_stats_in_seqfile(sba, file);
diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c
index a67b292190f4..594409a6e975 100644
--- a/drivers/dma/nbpfaxi.c
+++ b/drivers/dma/nbpfaxi.c
@@ -1491,14 +1491,14 @@ MODULE_DEVICE_TABLE(platform, nbpf_ids);
#ifdef CONFIG_PM
static int nbpf_runtime_suspend(struct device *dev)
{
- struct nbpf_device *nbpf = platform_get_drvdata(to_platform_device(dev));
+ struct nbpf_device *nbpf = dev_get_drvdata(dev);
clk_disable_unprepare(nbpf->clk);
return 0;
}
static int nbpf_runtime_resume(struct device *dev)
{
- struct nbpf_device *nbpf = platform_get_drvdata(to_platform_device(dev));
+ struct nbpf_device *nbpf = dev_get_drvdata(dev);
return clk_prepare_enable(nbpf->clk);
}
#endif
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 1/2] dmaengine: sh: rcar-dmac: With cyclic DMA residue 0 is valid
From: Vinod Koul @ 2019-04-23 5:15 UTC (permalink / raw)
To: Dirk Behme
Cc: linux-renesas-soc, dmaengine, geert+renesas,
niklas.soderlund+renesas, laurent.pinchart+renesas,
Achim.Dahlhoff, yoshihiro.shimoda.uh, ylhuajnu,
hiroyuki.yokoyama.vx, kuninori.morimoto.gx, stable
In-Reply-To: <20190412052914.16006-1-dirk.behme@de.bosch.com>
On 12-04-19, 07:29, Dirk Behme wrote:
> Having a cyclic DMA, a residue 0 is not an indication of a completed
> DMA. In case of cyclic DMA make sure that dma_set_residue() is called
> and with this a residue of 0 is forwarded correctly to the caller.
Applied both, thanks
--
~Vinod
^ permalink raw reply
* [v3,1/2] dmaengine: sh: rcar-dmac: With cyclic DMA residue 0 is valid
From: Vinod Koul @ 2019-04-23 5:15 UTC (permalink / raw)
To: Dirk Behme
Cc: linux-renesas-soc, dmaengine, geert+renesas,
niklas.soderlund+renesas, laurent.pinchart+renesas,
Achim.Dahlhoff, yoshihiro.shimoda.uh, ylhuajnu,
hiroyuki.yokoyama.vx, kuninori.morimoto.gx, stable
On 12-04-19, 07:29, Dirk Behme wrote:
> Having a cyclic DMA, a residue 0 is not an indication of a completed
> DMA. In case of cyclic DMA make sure that dma_set_residue() is called
> and with this a residue of 0 is forwarded correctly to the caller.
Applied both, thanks
^ permalink raw reply
* Re: [PATCH RFC] dmaengine: bcm2835: Avoid GFP_KERNEL in device_prep_slave_sg
From: Vinod Koul @ 2019-04-23 5:11 UTC (permalink / raw)
To: Stefan Wahren
Cc: Dan Williams, Florian Fainelli, Ray Jui, Scott Branden,
Eric Anholt, bcm-kernel-feedback-list, Aaro Koskinen,
Lukas Wunner, Florian Kauer, Martin Sperl, dmaengine,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <1554143899-4124-1-git-send-email-stefan.wahren@i2se.com>
On 01-04-19, 20:38, Stefan Wahren wrote:
> The commit af19b7ce76ba ("mmc: bcm2835: Avoid possible races on
> data requests") introduces a possible circular locking dependency,
> which is triggered by swapping to the sdhost interface.
>
> So instead of reintroduce the race condition again, we could also
> avoid this situation by using GFP_NOWAIT for the allocation of the
> DMA buffer descriptors.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [RFC] dmaengine: bcm2835: Avoid GFP_KERNEL in device_prep_slave_sg
From: Vinod Koul @ 2019-04-23 5:11 UTC (permalink / raw)
To: Stefan Wahren
Cc: Dan Williams, Florian Fainelli, Ray Jui, Scott Branden,
Eric Anholt, bcm-kernel-feedback-list, Aaro Koskinen,
Lukas Wunner, Florian Kauer, Martin Sperl, dmaengine,
linux-arm-kernel, linux-rpi-kernel
On 01-04-19, 20:38, Stefan Wahren wrote:
> The commit af19b7ce76ba ("mmc: bcm2835: Avoid possible races on
> data requests") introduces a possible circular locking dependency,
> which is triggered by swapping to the sdhost interface.
>
> So instead of reintroduce the race condition again, we could also
> avoid this situation by using GFP_NOWAIT for the allocation of the
> DMA buffer descriptors.
Applied, thanks
^ permalink raw reply
* Re: [PATCH v3 1/3] dmaengine: at_xdmac: remove BUG_ON macro in tasklet
From: Vinod Koul @ 2019-04-23 5:10 UTC (permalink / raw)
To: Nicolas Ferre
Cc: dmaengine, Ludovic Desroches, linux-arm-kernel, Alexandre Belloni,
linux-kernel
In-Reply-To: <20190403102359.27698-1-nicolas.ferre@microchip.com>
On 03-04-19, 12:23, Nicolas Ferre wrote:
> Even if this case shouldn't happen when controller is properly programmed,
> it's still better to avoid dumping a kernel Oops for this.
> As the sequence may happen only for debugging purposes, log the error and
> just finish the tasklet call.
Applied all, thanks
--
~Vinod
^ permalink raw reply
* [v3,1/3] dmaengine: at_xdmac: remove BUG_ON macro in tasklet
From: Vinod Koul @ 2019-04-23 5:10 UTC (permalink / raw)
To: Nicolas Ferre
Cc: dmaengine, Ludovic Desroches, linux-arm-kernel, Alexandre Belloni,
linux-kernel
On 03-04-19, 12:23, Nicolas Ferre wrote:
> Even if this case shouldn't happen when controller is properly programmed,
> it's still better to avoid dumping a kernel Oops for this.
> As the sequence may happen only for debugging purposes, log the error and
> just finish the tasklet call.
Applied all, thanks
^ permalink raw reply
* [PATCH] dmaengine: fsl-qdma: fixed the source/destination descriptior format
From: Peng Ma @ 2019-04-19 8:46 UTC (permalink / raw)
To: dan.j.williams, vkoul; +Cc: leoyang.li, dmaengine, linux-kernel, Peng Ma
CMD of Source/Destination descriptior format should be lower of
struct fsl_qdma_engine number data address.
Signed-off-by: Peng Ma <peng.ma@nxp.com>
---
drivers/dma/fsl-qdma.c | 29 ++++++++++++++++++-----------
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c
index aa1d0ae..542765a 100644
--- a/drivers/dma/fsl-qdma.c
+++ b/drivers/dma/fsl-qdma.c
@@ -113,6 +113,7 @@
/* Field definition for Descriptor offset */
#define QDMA_CCDF_STATUS 20
#define QDMA_CCDF_OFFSET 20
+#define QDMA_SDDF_CMD(x) (((u64)(x)) << 32)
/* Field definition for safe loop count*/
#define FSL_QDMA_HALT_COUNT 1500
@@ -214,6 +215,12 @@ struct fsl_qdma_engine {
};
+static inline void
+qdma_sddf_set_cmd(struct fsl_qdma_format *sddf, u32 val)
+{
+ sddf->data = QDMA_SDDF_CMD(val);
+}
+
static inline u64
qdma_ccdf_addr_get64(const struct fsl_qdma_format *ccdf)
{
@@ -341,6 +348,7 @@ static void fsl_qdma_free_chan_resources(struct dma_chan *chan)
static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
dma_addr_t dst, dma_addr_t src, u32 len)
{
+ u32 cmd;
struct fsl_qdma_format *sdf, *ddf;
struct fsl_qdma_format *ccdf, *csgf_desc, *csgf_src, *csgf_dest;
@@ -353,6 +361,7 @@ static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
memset(fsl_comp->virt_addr, 0, FSL_QDMA_COMMAND_BUFFER_SIZE);
memset(fsl_comp->desc_virt_addr, 0, FSL_QDMA_DESCRIPTOR_BUFFER_SIZE);
+
/* Head Command Descriptor(Frame Descriptor) */
qdma_desc_addr_set64(ccdf, fsl_comp->bus_addr + 16);
qdma_ccdf_set_format(ccdf, qdma_ccdf_get_offset(ccdf));
@@ -369,14 +378,14 @@ static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
/* This entry is the last entry. */
qdma_csgf_set_f(csgf_dest, len);
/* Descriptor Buffer */
- sdf->data =
- cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
- FSL_QDMA_CMD_RWTTYPE_OFFSET);
- ddf->data =
- cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
- FSL_QDMA_CMD_RWTTYPE_OFFSET);
- ddf->data |=
- cpu_to_le64(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
+ cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
+ FSL_QDMA_CMD_RWTTYPE_OFFSET);
+ qdma_sddf_set_cmd(sdf, cmd);
+
+ cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
+ FSL_QDMA_CMD_RWTTYPE_OFFSET);
+ cmd |= cpu_to_le32(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
+ qdma_sddf_set_cmd(ddf, cmd);
}
/*
@@ -701,10 +710,8 @@ static irqreturn_t fsl_qdma_error_handler(int irq, void *dev_id)
intr = qdma_readl(fsl_qdma, status + FSL_QDMA_DEDR);
- if (intr) {
+ if (intr)
dev_err(fsl_qdma->dma_dev.dev, "DMA transaction error!\n");
- return IRQ_NONE;
- }
qdma_writel(fsl_qdma, FSL_QDMA_DEDR_CLEAR, status + FSL_QDMA_DEDR);
return IRQ_HANDLED;
--
1.7.1
^ permalink raw reply related
* dmaengine: fsl-qdma: fixed the source/destination descriptior format
From: Peng Ma @ 2019-04-19 8:46 UTC (permalink / raw)
To: dan.j.williams, vkoul; +Cc: leoyang.li, dmaengine, linux-kernel, Peng Ma
CMD of Source/Destination descriptior format should be lower of
struct fsl_qdma_engine number data address.
Signed-off-by: Peng Ma <peng.ma@nxp.com>
---
drivers/dma/fsl-qdma.c | 29 ++++++++++++++++++-----------
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c
index aa1d0ae..542765a 100644
--- a/drivers/dma/fsl-qdma.c
+++ b/drivers/dma/fsl-qdma.c
@@ -113,6 +113,7 @@
/* Field definition for Descriptor offset */
#define QDMA_CCDF_STATUS 20
#define QDMA_CCDF_OFFSET 20
+#define QDMA_SDDF_CMD(x) (((u64)(x)) << 32)
/* Field definition for safe loop count*/
#define FSL_QDMA_HALT_COUNT 1500
@@ -214,6 +215,12 @@ struct fsl_qdma_engine {
};
+static inline void
+qdma_sddf_set_cmd(struct fsl_qdma_format *sddf, u32 val)
+{
+ sddf->data = QDMA_SDDF_CMD(val);
+}
+
static inline u64
qdma_ccdf_addr_get64(const struct fsl_qdma_format *ccdf)
{
@@ -341,6 +348,7 @@ static void fsl_qdma_free_chan_resources(struct dma_chan *chan)
static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
dma_addr_t dst, dma_addr_t src, u32 len)
{
+ u32 cmd;
struct fsl_qdma_format *sdf, *ddf;
struct fsl_qdma_format *ccdf, *csgf_desc, *csgf_src, *csgf_dest;
@@ -353,6 +361,7 @@ static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
memset(fsl_comp->virt_addr, 0, FSL_QDMA_COMMAND_BUFFER_SIZE);
memset(fsl_comp->desc_virt_addr, 0, FSL_QDMA_DESCRIPTOR_BUFFER_SIZE);
+
/* Head Command Descriptor(Frame Descriptor) */
qdma_desc_addr_set64(ccdf, fsl_comp->bus_addr + 16);
qdma_ccdf_set_format(ccdf, qdma_ccdf_get_offset(ccdf));
@@ -369,14 +378,14 @@ static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
/* This entry is the last entry. */
qdma_csgf_set_f(csgf_dest, len);
/* Descriptor Buffer */
- sdf->data =
- cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
- FSL_QDMA_CMD_RWTTYPE_OFFSET);
- ddf->data =
- cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
- FSL_QDMA_CMD_RWTTYPE_OFFSET);
- ddf->data |=
- cpu_to_le64(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
+ cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
+ FSL_QDMA_CMD_RWTTYPE_OFFSET);
+ qdma_sddf_set_cmd(sdf, cmd);
+
+ cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
+ FSL_QDMA_CMD_RWTTYPE_OFFSET);
+ cmd |= cpu_to_le32(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
+ qdma_sddf_set_cmd(ddf, cmd);
}
/*
@@ -701,10 +710,8 @@ static irqreturn_t fsl_qdma_error_handler(int irq, void *dev_id)
intr = qdma_readl(fsl_qdma, status + FSL_QDMA_DEDR);
- if (intr) {
+ if (intr)
dev_err(fsl_qdma->dma_dev.dev, "DMA transaction error!\n");
- return IRQ_NONE;
- }
qdma_writel(fsl_qdma, FSL_QDMA_DEDR_CLEAR, status + FSL_QDMA_DEDR);
return IRQ_HANDLED;
^ permalink raw reply related
* Re: [PATCH v2 2/3] dmaengine: imx-sdma: Only check ratio on parts that support 1:1
From: Robin Gong @ 2019-04-18 8:54 UTC (permalink / raw)
To: Angus Ainslie, angus@akkea.ca
Cc: dl-linux-imx, linux-kernel@vger.kernel.org, robh+dt@kernel.org,
ccaione@baylibre.com, devicetree@vger.kernel.org,
festevam@gmail.com, agx@sigxcpu.org, dan.j.williams@intel.com,
mark.rutland@arm.com, dmaengine@vger.kernel.org,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
vkoul@kernel.org, Daniel Baluta, l.stach@pengutronix.de,
kernel@pengutronix.de, s.hauer@pengutronix.de
In-Reply-To: <20190329152130.18411-3-angus@akkea.ca>
Acked-by: Robin Gong <yibin.gong@nxp.com>
On 2019-03-29 at 15:21 +0000, Angus Ainslie (Purism) wrote:
> On imx8mq B0 chip, AHB/SDMA clock ratio 2:1 can't be supported,
> since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
> to 500Mhz, so use 1:1 instead.
>
> To limit this change to the imx8mq for now this patch also adds an
> im8mq-sdma compatible string.
>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> ---
> drivers/dma/imx-sdma.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 5f3c1378b90e..99d9f431ae2c 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -419,6 +419,7 @@ struct sdma_driver_data {
> int chnenbl0;
> int num_events;
> struct sdma_script_start_addrs *script_addrs;
> + bool check_ratio;
> };
>
> struct sdma_engine {
> @@ -557,6 +558,13 @@ static struct sdma_driver_data sdma_imx7d = {
> .script_addrs = &sdma_script_imx7d,
> };
>
> +static struct sdma_driver_data sdma_imx8mq = {
> + .chnenbl0 = SDMA_CHNENBL0_IMX35,
> + .num_events = 48,
> + .script_addrs = &sdma_script_imx7d,
> + .check_ratio = 1,
> +};
> +
> static const struct platform_device_id sdma_devtypes[] = {
> {
> .name = "imx25-sdma",
> @@ -579,6 +587,9 @@ static const struct platform_device_id
> sdma_devtypes[] = {
> }, {
> .name = "imx7d-sdma",
> .driver_data = (unsigned long)&sdma_imx7d,
> + }, {
> + .name = "imx8mq-sdma",
> + .driver_data = (unsigned long)&sdma_imx8mq,
> }, {
> /* sentinel */
> }
> @@ -593,6 +604,7 @@ static const struct of_device_id sdma_dt_ids[] =
> {
> { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
> { .compatible = "fsl,imx25-sdma", .data = &sdma_imx25, },
> { .compatible = "fsl,imx7d-sdma", .data = &sdma_imx7d, },
> + { .compatible = "fsl,imx8mq-sdma", .data = &sdma_imx8mq, },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, sdma_dt_ids);
> @@ -1852,7 +1864,8 @@ static int sdma_init(struct sdma_engine *sdma)
> if (ret)
> goto disable_clk_ipg;
>
> - if (clk_get_rate(sdma->clk_ahb) == clk_get_rate(sdma-
> >clk_ipg))
> + if (sdma->drvdata->check_ratio &&
> + (clk_get_rate(sdma->clk_ahb) == clk_get_rate(sdma-
> >clk_ipg)))
> sdma->clk_ratio = 1;
>
> /* Be sure SDMA has not started yet */
^ permalink raw reply
* [v2,2/3] dmaengine: imx-sdma: Only check ratio on parts that support 1:1
From: Robin Gong @ 2019-04-18 8:54 UTC (permalink / raw)
To: Angus Ainslie, angus@akkea.ca
Cc: dl-linux-imx, linux-kernel@vger.kernel.org, robh+dt@kernel.org,
ccaione@baylibre.com, devicetree@vger.kernel.org,
festevam@gmail.com, agx@sigxcpu.org, dan.j.williams@intel.com,
mark.rutland@arm.com, dmaengine@vger.kernel.org,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
vkoul@kernel.org, Daniel Baluta, l.stach@pengutronix.de,
kernel@pengutronix.de, s.hauer@pengutronix.de
Acked-by: Robin Gong <yibin.gong@nxp.com>
On 2019-03-29 at 15:21 +0000, Angus Ainslie (Purism) wrote:
> On imx8mq B0 chip, AHB/SDMA clock ratio 2:1 can't be supported,
> since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
> to 500Mhz, so use 1:1 instead.
>
> To limit this change to the imx8mq for now this patch also adds an
> im8mq-sdma compatible string.
>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> ---
> drivers/dma/imx-sdma.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 5f3c1378b90e..99d9f431ae2c 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -419,6 +419,7 @@ struct sdma_driver_data {
> int chnenbl0;
> int num_events;
> struct sdma_script_start_addrs *script_addrs;
> + bool check_ratio;
> };
>
> struct sdma_engine {
> @@ -557,6 +558,13 @@ static struct sdma_driver_data sdma_imx7d = {
> .script_addrs = &sdma_script_imx7d,
> };
>
> +static struct sdma_driver_data sdma_imx8mq = {
> + .chnenbl0 = SDMA_CHNENBL0_IMX35,
> + .num_events = 48,
> + .script_addrs = &sdma_script_imx7d,
> + .check_ratio = 1,
> +};
> +
> static const struct platform_device_id sdma_devtypes[] = {
> {
> .name = "imx25-sdma",
> @@ -579,6 +587,9 @@ static const struct platform_device_id
> sdma_devtypes[] = {
> }, {
> .name = "imx7d-sdma",
> .driver_data = (unsigned long)&sdma_imx7d,
> + }, {
> + .name = "imx8mq-sdma",
> + .driver_data = (unsigned long)&sdma_imx8mq,
> }, {
> /* sentinel */
> }
> @@ -593,6 +604,7 @@ static const struct of_device_id sdma_dt_ids[] =
> {
> { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
> { .compatible = "fsl,imx25-sdma", .data = &sdma_imx25, },
> { .compatible = "fsl,imx7d-sdma", .data = &sdma_imx7d, },
> + { .compatible = "fsl,imx8mq-sdma", .data = &sdma_imx8mq, },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, sdma_dt_ids);
> @@ -1852,7 +1864,8 @@ static int sdma_init(struct sdma_engine *sdma)
> if (ret)
> goto disable_clk_ipg;
>
> - if (clk_get_rate(sdma->clk_ahb) == clk_get_rate(sdma-
> >clk_ipg))
> + if (sdma->drvdata->check_ratio &&
> + (clk_get_rate(sdma->clk_ahb) == clk_get_rate(sdma-
> >clk_ipg)))
> sdma->clk_ratio = 1;
>
> /* Be sure SDMA has not started yet */
^ permalink raw reply
* Re: Issues with i.MX SPI DMA transfers
From: Robin Gong @ 2019-04-18 8:05 UTC (permalink / raw)
To: plyatov@gmail.com
Cc: dl-linux-imx, linux-kernel@vger.kernel.org, Andy Duan,
u.kleine-koenig@pengutronix.de, festevam@gmail.com,
broonie@kernel.org, dan.j.williams@intel.com,
dmaengine@vger.kernel.org, linux-spi@vger.kernel.org, Han Xu,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
Clark Wang, vkoul@kernel.org, kernel@pengutronix.de,
s.hauer@pengutronix.de
In-Reply-To: <c9f24997-0112-8684-dc38-a6f8ba64c158@gmail.com>
On 2019-04-18 at 06:30 +0000, Igor Plyatov wrote:
> WARNING: This email was created outside of NXP. DO NOT CLICK links or
> attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> Dear Robin,
>
> >
> > Hi Igor,
> > Did you meet any issue with my latest patch?
> sorry, but unfortunately I have no time to test it.
>
> I have switched to PIO mode and continue other development.
>
> Maybe later I will find time to test DMA mode, but not sure when.
>
> Thank you for support!
Okay, I'll send out patch set to review, hope you could have chance to
try.
>
> --
>
> Igor Plyatov
>
> >
> > >
> > > -----Original Message-----
> > > From: Robin Gong
> > > Sent: April 9, 2019 11:26>
> > > Hi Igor,
> > > Please have a try with the attached patches, and revert
> > > 25aaa75df1e6,
> > > ad0d92d7ba6a , dd4b487b32a3, df07101e1c4a before apply. Besides
> > > XCH, tx
> > > thresh should be set to 0 , now no failure caught on ecspi5.
> > >
^ permalink raw reply
* Re: Issues with i.MX SPI DMA transfers
From: Igor Plyatov @ 2019-04-18 6:30 UTC (permalink / raw)
To: Robin Gong
Cc: Uwe Kleine-König, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org,
dl-linux-imx, Fabio Estevam, Pengutronix Kernel Team,
Sascha Hauer, Shawn Guo, Mark Brown, dmaengine@vger.kernel.org,
Vinod Koul, Dan Williams, Andy Duan, Han Xu, Clark Wang
In-Reply-To: <VI1PR04MB4543A5CA46FBB3ACC9F3B3E289260@VI1PR04MB4543.eurprd04.prod.outlook.com>
Dear Robin,
> Hi Igor,
> Did you meet any issue with my latest patch?
sorry, but unfortunately I have no time to test it.
I have switched to PIO mode and continue other development.
Maybe later I will find time to test DMA mode, but not sure when.
Thank you for support!
--
Igor Plyatov
>> -----Original Message-----
>> From: Robin Gong
>> Sent: April 9, 2019 11:26>
>> Hi Igor,
>> Please have a try with the attached patches, and revert 25aaa75df1e6,
>> ad0d92d7ba6a , dd4b487b32a3, df07101e1c4a before apply. Besides XCH, tx
>> thresh should be set to 0 , now no failure caught on ecspi5.
>>
^ permalink raw reply
* RE: Issues with i.MX SPI DMA transfers
From: Robin Gong @ 2019-04-18 1:19 UTC (permalink / raw)
To: Igor Plyatov, Uwe Kleine-König
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org,
dl-linux-imx, Fabio Estevam, Pengutronix Kernel Team,
Sascha Hauer, Shawn Guo, Mark Brown, dmaengine@vger.kernel.org,
Vinod Koul, Dan Williams, Andy Duan, Han Xu, Clark Wang
In-Reply-To: <VI1PR04MB454302BAF353124ED13747DC892D0@VI1PR04MB4543.eurprd04.prod.outlook.com>
Hi Igor,
Did you meet any issue with my latest patch?
> -----Original Message-----
> From: Robin Gong
> Sent: April 9, 2019 11:26>
> Hi Igor,
> Please have a try with the attached patches, and revert 25aaa75df1e6,
> ad0d92d7ba6a , dd4b487b32a3, df07101e1c4a before apply. Besides XCH, tx
> thresh should be set to 0 , now no failure caught on ecspi5.
>
^ permalink raw reply
* Re: [PATCH 2/2] dmaengine: milbeaut: Add Milbeaut AXI DMA controller
From: Kazuhiro Kasai @ 2019-04-16 2:06 UTC (permalink / raw)
To: vkoul@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com
Cc: dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
Orito, Takao/織戸 誉生,
Sugaya, Taichi/菅谷 太一,
Kanematsu, Shinji/兼松 伸次,
jaswinder.singh@linaro.org, masami.hiramatsu@linaro.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1553487314-9185-3-git-send-email-kasai.kazuhiro@socionext.com>
Hello,
Does anyone have any commnets on this?
On Mon, Mar 25, 2019 at 4:15 +0000, Kazuhiro Kasai wrote:
> Add Milbeaut AXI DMA controller. This DMA controller has
> only capable of memory to memory transfer.
>
> Signed-off-by: Kazuhiro Kasai <kasai.kazuhiro@socionext.com>
> ---
> drivers/dma/Kconfig | 8 +
> drivers/dma/Makefile | 1 +
> drivers/dma/xdmac-milbeaut.c | 353 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 362 insertions(+)
> create mode 100644 drivers/dma/xdmac-milbeaut.c
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 0b1dfb5..733fe5f 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -612,6 +612,14 @@ config UNIPHIER_MDMAC
> UniPhier platform. This DMA controller is used as the external
> DMA engine of the SD/eMMC controllers of the LD4, Pro4, sLD8 SoCs.
>
> +config XDMAC_MILBEAUT
> + tristate "Milbeaut AXI DMA support"
> + depends on ARCH_MILBEAUT || COMPILE_TEST
> + select DMA_ENGINE
> + help
> + Support for Milbeaut AXI DMA controller driver. The DMA controller
> + has only memory to memory capability.
> +
> config XGENE_DMA
> tristate "APM X-Gene DMA support"
> depends on ARCH_XGENE || COMPILE_TEST
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 6126e1c..4aab810 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
> obj-$(CONFIG_TEGRA210_ADMA) += tegra210-adma.o
> obj-$(CONFIG_TIMB_DMA) += timb_dma.o
> obj-$(CONFIG_UNIPHIER_MDMAC) += uniphier-mdmac.o
> +obj-$(CONFIG_XDMAC_MILBEAUT) += xdmac-milbeaut.o
> obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
> obj-$(CONFIG_ZX_DMA) += zx_dma.o
> obj-$(CONFIG_ST_FDMA) += st_fdma.o
> diff --git a/drivers/dma/xdmac-milbeaut.c b/drivers/dma/xdmac-milbeaut.c
> new file mode 100644
> index 0000000..7035c61
> --- /dev/null
> +++ b/drivers/dma/xdmac-milbeaut.c
> @@ -0,0 +1,353 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Socionext Inc.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/of_dma.h>
> +#include <linux/platform_device.h>
> +
> +#include "dmaengine.h"
> +
> +/* global register */
> +#define M10V_XDACS 0x00
> +
> +/* channel local register */
> +#define M10V_XDTBC 0x10
> +#define M10V_XDSSA 0x14
> +#define M10V_XDDSA 0x18
> +#define M10V_XDSAC 0x1C
> +#define M10V_XDDAC 0x20
> +#define M10V_XDDCC 0x24
> +#define M10V_XDDES 0x28
> +#define M10V_XDDPC 0x2C
> +#define M10V_XDDSD 0x30
> +
> +#define M10V_XDACS_XE BIT(28)
> +
> +#define M10V_XDSAC_SBS GENMASK(17, 16)
> +#define M10V_XDSAC_SBL GENMASK(11, 8)
> +
> +#define M10V_XDDAC_DBS GENMASK(17, 16)
> +#define M10V_XDDAC_DBL GENMASK(11, 8)
> +
> +#define M10V_XDDES_CE BIT(28)
> +#define M10V_XDDES_SE BIT(24)
> +#define M10V_XDDES_SA BIT(15)
> +#define M10V_XDDES_TF GENMASK(23, 20)
> +#define M10V_XDDES_EI BIT(1)
> +#define M10V_XDDES_TI BIT(0)
> +
> +#define M10V_XDDSD_IS_MASK GENMASK(3, 0)
> +#define M10V_XDDSD_IS_NORMAL 0x8
> +
> +#define M10V_XDMAC_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) | \
> + BIT(DMA_SLAVE_BUSWIDTH_8_BYTES))
> +
> +#define M10V_XDMAC_CHAN_BASE(base, i) ((base) + (i) * 0x30)
> +
> +#define to_m10v_dma_chan(c) container_of((c), struct m10v_dma_chan, chan)
> +
> +struct m10v_dma_desc {
> + struct dma_async_tx_descriptor txd;
> + size_t len;
> + dma_addr_t src;
> + dma_addr_t dst;
> +};
> +
> +struct m10v_dma_chan {
> + struct dma_chan chan;
> + struct m10v_dma_device *mdmac;
> + void __iomem *regs;
> + int irq;
> + struct m10v_dma_desc mdesc;
> + spinlock_t lock;
> +};
> +
> +struct m10v_dma_device {
> + struct dma_device dmac;
> + void __iomem *regs;
> + unsigned int channels;
> + struct m10v_dma_chan mchan[0];
> +};
> +
> +static void m10v_xdmac_enable_dma(struct m10v_dma_device *mdmac)
> +{
> + unsigned int val;
> +
> + val = readl(mdmac->regs + M10V_XDACS);
> + val &= ~M10V_XDACS_XE;
> + val |= FIELD_PREP(M10V_XDACS_XE, 1);
> + writel(val, mdmac->regs + M10V_XDACS);
> +}
> +
> +static void m10v_xdmac_disable_dma(struct m10v_dma_device *mdmac)
> +{
> + unsigned int val;
> +
> + val = readl(mdmac->regs + M10V_XDACS);
> + val &= ~M10V_XDACS_XE;
> + val |= FIELD_PREP(M10V_XDACS_XE, 0);
> + writel(val, mdmac->regs + M10V_XDACS);
> +}
> +
> +static void m10v_xdmac_config_chan(struct m10v_dma_chan *mchan)
> +{
> + u32 val;
> +
> + val = mchan->mdesc.len - 1;
> + writel(val, mchan->regs + M10V_XDTBC);
> +
> + val = mchan->mdesc.src;
> + writel(val, mchan->regs + M10V_XDSSA);
> +
> + val = mchan->mdesc.dst;
> + writel(val, mchan->regs + M10V_XDDSA);
> +
> + val = readl(mchan->regs + M10V_XDSAC);
> + val &= ~(M10V_XDSAC_SBS | M10V_XDSAC_SBL);
> + val |= FIELD_PREP(M10V_XDSAC_SBS, 0x3) |
> + FIELD_PREP(M10V_XDSAC_SBL, 0xf);
> + writel(val, mchan->regs + M10V_XDSAC);
> +
> + val = readl(mchan->regs + M10V_XDDAC);
> + val &= ~(M10V_XDDAC_DBS | M10V_XDDAC_DBL);
> + val |= FIELD_PREP(M10V_XDDAC_DBS, 0x3) |
> + FIELD_PREP(M10V_XDDAC_DBL, 0xf);
> + writel(val, mchan->regs + M10V_XDDAC);
> +}
> +
> +static void m10v_xdmac_enable_chan(struct m10v_dma_chan *mchan)
> +{
> + u32 val;
> +
> + val = readl(mchan->regs + M10V_XDDES);
> + val &= ~(M10V_XDDES_CE |
> + M10V_XDDES_SE |
> + M10V_XDDES_TF |
> + M10V_XDDES_EI |
> + M10V_XDDES_TI);
> + val |= FIELD_PREP(M10V_XDDES_CE, 1) |
> + FIELD_PREP(M10V_XDDES_SE, 1) |
> + FIELD_PREP(M10V_XDDES_TF, 1) |
> + FIELD_PREP(M10V_XDDES_EI, 1) |
> + FIELD_PREP(M10V_XDDES_TI, 1);
> + writel(val, mchan->regs + M10V_XDDES);
> +}
> +
> +static void m10v_xdmac_disable_chan(struct m10v_dma_chan *mchan)
> +{
> + u32 val;
> +
> + val = readl(mchan->regs + M10V_XDDES);
> + val &= ~M10V_XDDES_CE;
> + val |= FIELD_PREP(M10V_XDDES_CE, 0);
> + writel(val, mchan->regs + M10V_XDDES);
> +}
> +
> +static irqreturn_t m10v_xdmac_irq(int irq, void *data)
> +{
> + struct m10v_dma_chan *mchan = data;
> + unsigned long flags;
> + u32 val;
> +
> + val = readl(mchan->regs + M10V_XDDSD);
> + val = FIELD_GET(M10V_XDDSD_IS_MASK, val);
> +
> + if (val != M10V_XDDSD_IS_NORMAL)
> + dev_err(mchan->chan.device->dev, "XDMAC error with status: %x", val);
> +
> + val = FIELD_PREP(M10V_XDDSD_IS_MASK, 0x0);
> + writel(val, mchan->regs + M10V_XDDSD);
> +
> + spin_lock_irqsave(&mchan->lock, flags);
> + dma_cookie_complete(&mchan->mdesc.txd);
> + spin_unlock_irqrestore(&mchan->lock, flags);
> +
> + if (mchan->mdesc.txd.flags & DMA_PREP_INTERRUPT)
> + dmaengine_desc_get_callback_invoke(&mchan->mdesc.txd, NULL);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void m10v_xdmac_issue_pending(struct dma_chan *chan)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> +
> + m10v_xdmac_config_chan(mchan);
> +
> + m10v_xdmac_enable_chan(mchan);
> +}
> +
> +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;
> +}
> +
> +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;
> +}
> +
> +static int m10v_xdmac_device_terminate_all(struct dma_chan *chan)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> +
> + m10v_xdmac_disable_chan(mchan);
> +
> + return 0;
> +}
> +
> +static int m10v_xdmac_alloc_chan_resources(struct dma_chan *chan)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&mchan->lock, flags);
> + dma_cookie_init(chan);
> + spin_unlock_irqrestore(&mchan->lock, flags);
> +
> + return 1;
> +}
> +
> +static int m10v_xdmac_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct m10v_dma_chan *mchan;
> + struct m10v_dma_device *mdmac;
> + struct resource *res;
> + unsigned int channels;
> + int ret, i;
> +
> + ret = device_property_read_u32(&pdev->dev, "dma-channels", &channels);
> + if (ret) {
> + dev_err(&pdev->dev, "get dma-channels failed\n");
> + return ret;
> + }
> +
> + mdmac = devm_kzalloc(&pdev->dev,
> + struct_size(mdmac, mchan, channels),
> + GFP_KERNEL);
> + if (!mdmac)
> + return -ENOMEM;
> +
> + mdmac->channels = channels;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mdmac->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(mdmac->regs))
> + return PTR_ERR(mdmac->regs);
> +
> + INIT_LIST_HEAD(&mdmac->dmac.channels);
> + for (i = 0; i < mdmac->channels; i++) {
> + mchan = &mdmac->mchan[i];
> + mchan->irq = platform_get_irq(pdev, i);
> + ret = devm_request_irq(&pdev->dev, mchan->irq, m10v_xdmac_irq,
> + IRQF_SHARED, dev_name(&pdev->dev), mchan);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to request IRQ\n");
> + return ret;
> + }
> + mchan->mdmac = mdmac;
> + mchan->chan.device = &mdmac->dmac;
> + list_add_tail(&mchan->chan.device_node,
> + &mdmac->dmac.channels);
> +
> + mchan->regs = M10V_XDMAC_CHAN_BASE(mdmac->regs, i);
> + spin_lock_init(&mchan->lock);
> + }
> +
> + dma_cap_set(DMA_MEMCPY, mdmac->dmac.cap_mask);
> +
> + mdmac->dmac.device_alloc_chan_resources = m10v_xdmac_alloc_chan_resources;
> + mdmac->dmac.device_prep_dma_memcpy = m10v_xdmac_prep_dma_memcpy;
> + mdmac->dmac.device_issue_pending = m10v_xdmac_issue_pending;
> + mdmac->dmac.device_tx_status = dma_cookie_status;
> + mdmac->dmac.device_terminate_all = m10v_xdmac_device_terminate_all;
> + mdmac->dmac.src_addr_widths = M10V_XDMAC_BUSWIDTHS;
> + mdmac->dmac.dst_addr_widths = M10V_XDMAC_BUSWIDTHS;
> + mdmac->dmac.residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> + mdmac->dmac.dev = &pdev->dev;
> +
> + platform_set_drvdata(pdev, mdmac);
> +
> + m10v_xdmac_enable_dma(mdmac);
> +
> + ret = dmaenginem_async_device_register(&mdmac->dmac);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register dmaengine device\n");
> + return ret;
> + }
> +
> + ret = of_dma_controller_register(np, of_dma_simple_xlate, mdmac);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register OF DMA controller\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int m10v_xdmac_remove(struct platform_device *pdev)
> +{
> + struct m10v_dma_chan *mchan;
> + struct m10v_dma_device *mdmac = platform_get_drvdata(pdev);
> + int i;
> +
> + m10v_xdmac_disable_dma(mdmac);
> +
> + for (i = 0; i < mdmac->channels; i++) {
> + mchan = &mdmac->mchan[i];
> + devm_free_irq(&pdev->dev, mchan->irq, mchan);
> + }
> +
> + of_dma_controller_free(pdev->dev.of_node);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id m10v_xdmac_dt_ids[] = {
> + {.compatible = "socionext,milbeaut-m10v-xdmac",},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, m10v_xdmac_dt_ids);
> +
> +static struct platform_driver m10v_xdmac_driver = {
> + .driver = {
> + .name = "m10v-xdmac",
> + .of_match_table = of_match_ptr(m10v_xdmac_dt_ids),
> + },
> + .probe = m10v_xdmac_probe,
> + .remove = m10v_xdmac_remove,
> +};
> +module_platform_driver(m10v_xdmac_driver);
> +
> +MODULE_AUTHOR("Kazuhiro Kasai <kasai.kazuhiro@socionext.com>");
> +MODULE_DESCRIPTION("Socionext Milbeaut XDMAC driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.9.1
>
^ permalink raw reply
* [2/2] dmaengine: milbeaut: Add Milbeaut AXI DMA controller
From: Kazuhiro Kasai @ 2019-04-16 2:06 UTC (permalink / raw)
To: vkoul@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com
Cc: dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
Orito, Takao/織戸 誉生,
Sugaya, Taichi/菅谷 太一,
Kanematsu, Shinji/兼松 伸次,
jaswinder.singh@linaro.org, masami.hiramatsu@linaro.org,
linux-kernel@vger.kernel.org
Hello,
Does anyone have any commnets on this?
On Mon, Mar 25, 2019 at 4:15 +0000, Kazuhiro Kasai wrote:
> Add Milbeaut AXI DMA controller. This DMA controller has
> only capable of memory to memory transfer.
>
> Signed-off-by: Kazuhiro Kasai <kasai.kazuhiro@socionext.com>
> ---
> drivers/dma/Kconfig | 8 +
> drivers/dma/Makefile | 1 +
> drivers/dma/xdmac-milbeaut.c | 353 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 362 insertions(+)
> create mode 100644 drivers/dma/xdmac-milbeaut.c
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 0b1dfb5..733fe5f 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -612,6 +612,14 @@ config UNIPHIER_MDMAC
> UniPhier platform. This DMA controller is used as the external
> DMA engine of the SD/eMMC controllers of the LD4, Pro4, sLD8 SoCs.
>
> +config XDMAC_MILBEAUT
> + tristate "Milbeaut AXI DMA support"
> + depends on ARCH_MILBEAUT || COMPILE_TEST
> + select DMA_ENGINE
> + help
> + Support for Milbeaut AXI DMA controller driver. The DMA controller
> + has only memory to memory capability.
> +
> config XGENE_DMA
> tristate "APM X-Gene DMA support"
> depends on ARCH_XGENE || COMPILE_TEST
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 6126e1c..4aab810 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
> obj-$(CONFIG_TEGRA210_ADMA) += tegra210-adma.o
> obj-$(CONFIG_TIMB_DMA) += timb_dma.o
> obj-$(CONFIG_UNIPHIER_MDMAC) += uniphier-mdmac.o
> +obj-$(CONFIG_XDMAC_MILBEAUT) += xdmac-milbeaut.o
> obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
> obj-$(CONFIG_ZX_DMA) += zx_dma.o
> obj-$(CONFIG_ST_FDMA) += st_fdma.o
> diff --git a/drivers/dma/xdmac-milbeaut.c b/drivers/dma/xdmac-milbeaut.c
> new file mode 100644
> index 0000000..7035c61
> --- /dev/null
> +++ b/drivers/dma/xdmac-milbeaut.c
> @@ -0,0 +1,353 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Socionext Inc.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/of_dma.h>
> +#include <linux/platform_device.h>
> +
> +#include "dmaengine.h"
> +
> +/* global register */
> +#define M10V_XDACS 0x00
> +
> +/* channel local register */
> +#define M10V_XDTBC 0x10
> +#define M10V_XDSSA 0x14
> +#define M10V_XDDSA 0x18
> +#define M10V_XDSAC 0x1C
> +#define M10V_XDDAC 0x20
> +#define M10V_XDDCC 0x24
> +#define M10V_XDDES 0x28
> +#define M10V_XDDPC 0x2C
> +#define M10V_XDDSD 0x30
> +
> +#define M10V_XDACS_XE BIT(28)
> +
> +#define M10V_XDSAC_SBS GENMASK(17, 16)
> +#define M10V_XDSAC_SBL GENMASK(11, 8)
> +
> +#define M10V_XDDAC_DBS GENMASK(17, 16)
> +#define M10V_XDDAC_DBL GENMASK(11, 8)
> +
> +#define M10V_XDDES_CE BIT(28)
> +#define M10V_XDDES_SE BIT(24)
> +#define M10V_XDDES_SA BIT(15)
> +#define M10V_XDDES_TF GENMASK(23, 20)
> +#define M10V_XDDES_EI BIT(1)
> +#define M10V_XDDES_TI BIT(0)
> +
> +#define M10V_XDDSD_IS_MASK GENMASK(3, 0)
> +#define M10V_XDDSD_IS_NORMAL 0x8
> +
> +#define M10V_XDMAC_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) | \
> + BIT(DMA_SLAVE_BUSWIDTH_8_BYTES))
> +
> +#define M10V_XDMAC_CHAN_BASE(base, i) ((base) + (i) * 0x30)
> +
> +#define to_m10v_dma_chan(c) container_of((c), struct m10v_dma_chan, chan)
> +
> +struct m10v_dma_desc {
> + struct dma_async_tx_descriptor txd;
> + size_t len;
> + dma_addr_t src;
> + dma_addr_t dst;
> +};
> +
> +struct m10v_dma_chan {
> + struct dma_chan chan;
> + struct m10v_dma_device *mdmac;
> + void __iomem *regs;
> + int irq;
> + struct m10v_dma_desc mdesc;
> + spinlock_t lock;
> +};
> +
> +struct m10v_dma_device {
> + struct dma_device dmac;
> + void __iomem *regs;
> + unsigned int channels;
> + struct m10v_dma_chan mchan[0];
> +};
> +
> +static void m10v_xdmac_enable_dma(struct m10v_dma_device *mdmac)
> +{
> + unsigned int val;
> +
> + val = readl(mdmac->regs + M10V_XDACS);
> + val &= ~M10V_XDACS_XE;
> + val |= FIELD_PREP(M10V_XDACS_XE, 1);
> + writel(val, mdmac->regs + M10V_XDACS);
> +}
> +
> +static void m10v_xdmac_disable_dma(struct m10v_dma_device *mdmac)
> +{
> + unsigned int val;
> +
> + val = readl(mdmac->regs + M10V_XDACS);
> + val &= ~M10V_XDACS_XE;
> + val |= FIELD_PREP(M10V_XDACS_XE, 0);
> + writel(val, mdmac->regs + M10V_XDACS);
> +}
> +
> +static void m10v_xdmac_config_chan(struct m10v_dma_chan *mchan)
> +{
> + u32 val;
> +
> + val = mchan->mdesc.len - 1;
> + writel(val, mchan->regs + M10V_XDTBC);
> +
> + val = mchan->mdesc.src;
> + writel(val, mchan->regs + M10V_XDSSA);
> +
> + val = mchan->mdesc.dst;
> + writel(val, mchan->regs + M10V_XDDSA);
> +
> + val = readl(mchan->regs + M10V_XDSAC);
> + val &= ~(M10V_XDSAC_SBS | M10V_XDSAC_SBL);
> + val |= FIELD_PREP(M10V_XDSAC_SBS, 0x3) |
> + FIELD_PREP(M10V_XDSAC_SBL, 0xf);
> + writel(val, mchan->regs + M10V_XDSAC);
> +
> + val = readl(mchan->regs + M10V_XDDAC);
> + val &= ~(M10V_XDDAC_DBS | M10V_XDDAC_DBL);
> + val |= FIELD_PREP(M10V_XDDAC_DBS, 0x3) |
> + FIELD_PREP(M10V_XDDAC_DBL, 0xf);
> + writel(val, mchan->regs + M10V_XDDAC);
> +}
> +
> +static void m10v_xdmac_enable_chan(struct m10v_dma_chan *mchan)
> +{
> + u32 val;
> +
> + val = readl(mchan->regs + M10V_XDDES);
> + val &= ~(M10V_XDDES_CE |
> + M10V_XDDES_SE |
> + M10V_XDDES_TF |
> + M10V_XDDES_EI |
> + M10V_XDDES_TI);
> + val |= FIELD_PREP(M10V_XDDES_CE, 1) |
> + FIELD_PREP(M10V_XDDES_SE, 1) |
> + FIELD_PREP(M10V_XDDES_TF, 1) |
> + FIELD_PREP(M10V_XDDES_EI, 1) |
> + FIELD_PREP(M10V_XDDES_TI, 1);
> + writel(val, mchan->regs + M10V_XDDES);
> +}
> +
> +static void m10v_xdmac_disable_chan(struct m10v_dma_chan *mchan)
> +{
> + u32 val;
> +
> + val = readl(mchan->regs + M10V_XDDES);
> + val &= ~M10V_XDDES_CE;
> + val |= FIELD_PREP(M10V_XDDES_CE, 0);
> + writel(val, mchan->regs + M10V_XDDES);
> +}
> +
> +static irqreturn_t m10v_xdmac_irq(int irq, void *data)
> +{
> + struct m10v_dma_chan *mchan = data;
> + unsigned long flags;
> + u32 val;
> +
> + val = readl(mchan->regs + M10V_XDDSD);
> + val = FIELD_GET(M10V_XDDSD_IS_MASK, val);
> +
> + if (val != M10V_XDDSD_IS_NORMAL)
> + dev_err(mchan->chan.device->dev, "XDMAC error with status: %x", val);
> +
> + val = FIELD_PREP(M10V_XDDSD_IS_MASK, 0x0);
> + writel(val, mchan->regs + M10V_XDDSD);
> +
> + spin_lock_irqsave(&mchan->lock, flags);
> + dma_cookie_complete(&mchan->mdesc.txd);
> + spin_unlock_irqrestore(&mchan->lock, flags);
> +
> + if (mchan->mdesc.txd.flags & DMA_PREP_INTERRUPT)
> + dmaengine_desc_get_callback_invoke(&mchan->mdesc.txd, NULL);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void m10v_xdmac_issue_pending(struct dma_chan *chan)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> +
> + m10v_xdmac_config_chan(mchan);
> +
> + m10v_xdmac_enable_chan(mchan);
> +}
> +
> +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;
> +}
> +
> +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;
> +}
> +
> +static int m10v_xdmac_device_terminate_all(struct dma_chan *chan)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> +
> + m10v_xdmac_disable_chan(mchan);
> +
> + return 0;
> +}
> +
> +static int m10v_xdmac_alloc_chan_resources(struct dma_chan *chan)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&mchan->lock, flags);
> + dma_cookie_init(chan);
> + spin_unlock_irqrestore(&mchan->lock, flags);
> +
> + return 1;
> +}
> +
> +static int m10v_xdmac_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct m10v_dma_chan *mchan;
> + struct m10v_dma_device *mdmac;
> + struct resource *res;
> + unsigned int channels;
> + int ret, i;
> +
> + ret = device_property_read_u32(&pdev->dev, "dma-channels", &channels);
> + if (ret) {
> + dev_err(&pdev->dev, "get dma-channels failed\n");
> + return ret;
> + }
> +
> + mdmac = devm_kzalloc(&pdev->dev,
> + struct_size(mdmac, mchan, channels),
> + GFP_KERNEL);
> + if (!mdmac)
> + return -ENOMEM;
> +
> + mdmac->channels = channels;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mdmac->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(mdmac->regs))
> + return PTR_ERR(mdmac->regs);
> +
> + INIT_LIST_HEAD(&mdmac->dmac.channels);
> + for (i = 0; i < mdmac->channels; i++) {
> + mchan = &mdmac->mchan[i];
> + mchan->irq = platform_get_irq(pdev, i);
> + ret = devm_request_irq(&pdev->dev, mchan->irq, m10v_xdmac_irq,
> + IRQF_SHARED, dev_name(&pdev->dev), mchan);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to request IRQ\n");
> + return ret;
> + }
> + mchan->mdmac = mdmac;
> + mchan->chan.device = &mdmac->dmac;
> + list_add_tail(&mchan->chan.device_node,
> + &mdmac->dmac.channels);
> +
> + mchan->regs = M10V_XDMAC_CHAN_BASE(mdmac->regs, i);
> + spin_lock_init(&mchan->lock);
> + }
> +
> + dma_cap_set(DMA_MEMCPY, mdmac->dmac.cap_mask);
> +
> + mdmac->dmac.device_alloc_chan_resources = m10v_xdmac_alloc_chan_resources;
> + mdmac->dmac.device_prep_dma_memcpy = m10v_xdmac_prep_dma_memcpy;
> + mdmac->dmac.device_issue_pending = m10v_xdmac_issue_pending;
> + mdmac->dmac.device_tx_status = dma_cookie_status;
> + mdmac->dmac.device_terminate_all = m10v_xdmac_device_terminate_all;
> + mdmac->dmac.src_addr_widths = M10V_XDMAC_BUSWIDTHS;
> + mdmac->dmac.dst_addr_widths = M10V_XDMAC_BUSWIDTHS;
> + mdmac->dmac.residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> + mdmac->dmac.dev = &pdev->dev;
> +
> + platform_set_drvdata(pdev, mdmac);
> +
> + m10v_xdmac_enable_dma(mdmac);
> +
> + ret = dmaenginem_async_device_register(&mdmac->dmac);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register dmaengine device\n");
> + return ret;
> + }
> +
> + ret = of_dma_controller_register(np, of_dma_simple_xlate, mdmac);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register OF DMA controller\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int m10v_xdmac_remove(struct platform_device *pdev)
> +{
> + struct m10v_dma_chan *mchan;
> + struct m10v_dma_device *mdmac = platform_get_drvdata(pdev);
> + int i;
> +
> + m10v_xdmac_disable_dma(mdmac);
> +
> + for (i = 0; i < mdmac->channels; i++) {
> + mchan = &mdmac->mchan[i];
> + devm_free_irq(&pdev->dev, mchan->irq, mchan);
> + }
> +
> + of_dma_controller_free(pdev->dev.of_node);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id m10v_xdmac_dt_ids[] = {
> + {.compatible = "socionext,milbeaut-m10v-xdmac",},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, m10v_xdmac_dt_ids);
> +
> +static struct platform_driver m10v_xdmac_driver = {
> + .driver = {
> + .name = "m10v-xdmac",
> + .of_match_table = of_match_ptr(m10v_xdmac_dt_ids),
> + },
> + .probe = m10v_xdmac_probe,
> + .remove = m10v_xdmac_remove,
> +};
> +module_platform_driver(m10v_xdmac_driver);
> +
> +MODULE_AUTHOR("Kazuhiro Kasai <kasai.kazuhiro@socionext.com>");
> +MODULE_DESCRIPTION("Socionext Milbeaut XDMAC driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 4/6] dma: tegra: add accurate reporting of dma state
From: Dmitry Osipenko @ 2019-04-15 16:56 UTC (permalink / raw)
To: Ben Dooks; +Cc: dan.j.williams, vkoul, ldewangan, dmaengine, linux-tegra
In-Reply-To: <204824b3-40af-5fa1-1005-028153dbe83a@codethink.co.uk>
15.04.2019 18:01, Ben Dooks пишет:
> On 14/04/2019 16:20, Dmitry Osipenko wrote:
>> 22.02.2019 21:10, Dmitry Osipenko пишет:
>>> 22.02.2019 20:23, Ben Dooks пишет:
>>>> On 21/02/2019 13:02, Dmitry Osipenko wrote:
>>>>> 21.02.2019 13:06, Ben Dooks пишет:
>>>>>> On 21/02/2019 00:41, Dmitry Osipenko wrote:
>>>>>>> 31.10.2018 19:03, Ben Dooks пишет:
>>>>>>>> The tx_status callback does not report the state of the transfer
>>>>>>>> beyond complete segments. This causes problems with users such as
>>>>>>>> ALSA when applications want to know accurately how much data has
>>>>>>>> been moved.
>>>>>>>>
>>>>>>>> This patch addes a function tegra_dma_update_residual() to query
>>>>>>>> the hardware and modify the residual information accordinly. It
>>>>>>>> takes into account any hardware issues when trying to read the
>>>>>>>> state, such as delays between finishing a buffer and signalling
>>>>>>>> the interrupt.
>>>>>>>>
>>>>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>>>>>
>>>>>>> Hello Ben,
>>>>>>>
>>>>>>> Do you have any plans to submit a new version of this patch? It's really useful and fixes a real problem with the audio playback. I could help with finalizing the patch and could submit it for you if you happened to lost the interest.
>>>>>>
>>>>>> Personally I think the original version was fine. It has been tested
>>>>>> and returns fairly quickly (I am not a fan of just adding more delay in)
>>>>>>
>>>>>> My notes say the condition doesn't last for long and the loop tends
>>>>>> to terminate within 2 runs.
>>>>>>
>>>>>
>>>>> Okay, so are you going to re-send the patch? We can back to the review after, you need at least to re-send because this series has been outdated. Also please take a look and feel free to use as-is the reduced variant of yours patch that I was carrying and testing for months now [0], it works great.
>>>>>
>>>>> [0] https://github.com/grate-driver/linux/commit/ab8a67a6f47185f265f16749b55df214aaaefad4
>>>>>
>>>>
>>>> I can try rebasing, but I have not got a lot of time to do any testing
>>>> at the moment. I agree I should have remembered to chase this stuff up
>>>> earlier.
>>>
>>> No problems, thank you. I'll help with the testing. And I could rebase the patch and send it out for you if will be needed, please just let me know if you're okay with it.
>>>
>>
>> Hello Ben,
>>
>> Do you have any status update on the state of the patch? Again, I could help with sending it out for you if you're too busy or something else. Please let me know how we could proceed with getting the fix upstreamed and sorry for disturbing you again with this.
>
> I am currently re-looking at the updates for TDM audio and slave mode
> audio for the tegra, I should be able to re-test the original patch
> tomorrow.
Sounds great, thank you very much.
^ permalink raw reply
* [4/6] dma: tegra: add accurate reporting of dma state
From: Dmitry Osipenko @ 2019-04-15 16:56 UTC (permalink / raw)
To: Ben Dooks; +Cc: dan.j.williams, vkoul, ldewangan, dmaengine, linux-tegra
15.04.2019 18:01, Ben Dooks пишет:
> On 14/04/2019 16:20, Dmitry Osipenko wrote:
>> 22.02.2019 21:10, Dmitry Osipenko пишет:
>>> 22.02.2019 20:23, Ben Dooks пишет:
>>>> On 21/02/2019 13:02, Dmitry Osipenko wrote:
>>>>> 21.02.2019 13:06, Ben Dooks пишет:
>>>>>> On 21/02/2019 00:41, Dmitry Osipenko wrote:
>>>>>>> 31.10.2018 19:03, Ben Dooks пишет:
>>>>>>>> The tx_status callback does not report the state of the transfer
>>>>>>>> beyond complete segments. This causes problems with users such as
>>>>>>>> ALSA when applications want to know accurately how much data has
>>>>>>>> been moved.
>>>>>>>>
>>>>>>>> This patch addes a function tegra_dma_update_residual() to query
>>>>>>>> the hardware and modify the residual information accordinly. It
>>>>>>>> takes into account any hardware issues when trying to read the
>>>>>>>> state, such as delays between finishing a buffer and signalling
>>>>>>>> the interrupt.
>>>>>>>>
>>>>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>>>>>
>>>>>>> Hello Ben,
>>>>>>>
>>>>>>> Do you have any plans to submit a new version of this patch? It's really useful and fixes a real problem with the audio playback. I could help with finalizing the patch and could submit it for you if you happened to lost the interest.
>>>>>>
>>>>>> Personally I think the original version was fine. It has been tested
>>>>>> and returns fairly quickly (I am not a fan of just adding more delay in)
>>>>>>
>>>>>> My notes say the condition doesn't last for long and the loop tends
>>>>>> to terminate within 2 runs.
>>>>>>
>>>>>
>>>>> Okay, so are you going to re-send the patch? We can back to the review after, you need at least to re-send because this series has been outdated. Also please take a look and feel free to use as-is the reduced variant of yours patch that I was carrying and testing for months now [0], it works great.
>>>>>
>>>>> [0] https://github.com/grate-driver/linux/commit/ab8a67a6f47185f265f16749b55df214aaaefad4
>>>>>
>>>>
>>>> I can try rebasing, but I have not got a lot of time to do any testing
>>>> at the moment. I agree I should have remembered to chase this stuff up
>>>> earlier.
>>>
>>> No problems, thank you. I'll help with the testing. And I could rebase the patch and send it out for you if will be needed, please just let me know if you're okay with it.
>>>
>>
>> Hello Ben,
>>
>> Do you have any status update on the state of the patch? Again, I could help with sending it out for you if you're too busy or something else. Please let me know how we could proceed with getting the fix upstreamed and sorry for disturbing you again with this.
>
> I am currently re-looking at the updates for TDM audio and slave mode
> audio for the tegra, I should be able to re-test the original patch
> tomorrow.
Sounds great, thank you very much.
^ permalink raw reply
* [PATCH] dmaengine: xgene-dma: fix spelling mistake "descripto" -> "descriptor"
From: Colin King @ 2019-04-15 15:30 UTC (permalink / raw)
To: Dan Williams, Vinod Koul, dmaengine; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in a chan_dbg message, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/dma/xgene-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
index 002323661d07..8d174dc5dccd 100644
--- a/drivers/dma/xgene-dma.c
+++ b/drivers/dma/xgene-dma.c
@@ -797,7 +797,7 @@ static int xgene_dma_alloc_chan_resources(struct dma_chan *dchan)
return -ENOMEM;
}
- chan_dbg(chan, "Allocate descripto pool\n");
+ chan_dbg(chan, "Allocate descriptor pool\n");
return 1;
}
--
2.20.1
^ permalink raw reply related
* dmaengine: xgene-dma: fix spelling mistake "descripto" -> "descriptor"
From: Colin King @ 2019-04-15 15:30 UTC (permalink / raw)
To: Dan Williams, Vinod Koul, dmaengine; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in a chan_dbg message, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/dma/xgene-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
index 002323661d07..8d174dc5dccd 100644
--- a/drivers/dma/xgene-dma.c
+++ b/drivers/dma/xgene-dma.c
@@ -797,7 +797,7 @@ static int xgene_dma_alloc_chan_resources(struct dma_chan *dchan)
return -ENOMEM;
}
- chan_dbg(chan, "Allocate descripto pool\n");
+ chan_dbg(chan, "Allocate descriptor pool\n");
return 1;
}
^ permalink raw reply related
* Re: [PATCH 4/6] dma: tegra: add accurate reporting of dma state
From: Ben Dooks @ 2019-04-15 15:01 UTC (permalink / raw)
To: Dmitry Osipenko; +Cc: dan.j.williams, vkoul, ldewangan, dmaengine, linux-tegra
In-Reply-To: <687294f3-aeb5-f17f-bf7d-886346baf02d@gmail.com>
On 14/04/2019 16:20, Dmitry Osipenko wrote:
> 22.02.2019 21:10, Dmitry Osipenko пишет:
>> 22.02.2019 20:23, Ben Dooks пишет:
>>> On 21/02/2019 13:02, Dmitry Osipenko wrote:
>>>> 21.02.2019 13:06, Ben Dooks пишет:
>>>>> On 21/02/2019 00:41, Dmitry Osipenko wrote:
>>>>>> 31.10.2018 19:03, Ben Dooks пишет:
>>>>>>> The tx_status callback does not report the state of the transfer
>>>>>>> beyond complete segments. This causes problems with users such as
>>>>>>> ALSA when applications want to know accurately how much data has
>>>>>>> been moved.
>>>>>>>
>>>>>>> This patch addes a function tegra_dma_update_residual() to query
>>>>>>> the hardware and modify the residual information accordinly. It
>>>>>>> takes into account any hardware issues when trying to read the
>>>>>>> state, such as delays between finishing a buffer and signalling
>>>>>>> the interrupt.
>>>>>>>
>>>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>>>>
>>>>>> Hello Ben,
>>>>>>
>>>>>> Do you have any plans to submit a new version of this patch? It's really useful and fixes a real problem with the audio playback. I could help with finalizing the patch and could submit it for you if you happened to lost the interest.
>>>>>
>>>>> Personally I think the original version was fine. It has been tested
>>>>> and returns fairly quickly (I am not a fan of just adding more delay in)
>>>>>
>>>>> My notes say the condition doesn't last for long and the loop tends
>>>>> to terminate within 2 runs.
>>>>>
>>>>
>>>> Okay, so are you going to re-send the patch? We can back to the review after, you need at least to re-send because this series has been outdated. Also please take a look and feel free to use as-is the reduced variant of yours patch that I was carrying and testing for months now [0], it works great.
>>>>
>>>> [0] https://github.com/grate-driver/linux/commit/ab8a67a6f47185f265f16749b55df214aaaefad4
>>>>
>>>
>>> I can try rebasing, but I have not got a lot of time to do any testing
>>> at the moment. I agree I should have remembered to chase this stuff up
>>> earlier.
>>
>> No problems, thank you. I'll help with the testing. And I could rebase the patch and send it out for you if will be needed, please just let me know if you're okay with it.
>>
>
> Hello Ben,
>
> Do you have any status update on the state of the patch? Again, I could help with sending it out for you if you're too busy or something else. Please let me know how we could proceed with getting the fix upstreamed and sorry for disturbing you again with this.
I am currently re-looking at the updates for TDM audio and slave mode
audio for the tegra, I should be able to re-test the original patch
tomorrow.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
^ permalink raw reply
* [4/6] dma: tegra: add accurate reporting of dma state
From: Ben Dooks @ 2019-04-15 15:01 UTC (permalink / raw)
To: Dmitry Osipenko; +Cc: dan.j.williams, vkoul, ldewangan, dmaengine, linux-tegra
On 14/04/2019 16:20, Dmitry Osipenko wrote:
> 22.02.2019 21:10, Dmitry Osipenko пишет:
>> 22.02.2019 20:23, Ben Dooks пишет:
>>> On 21/02/2019 13:02, Dmitry Osipenko wrote:
>>>> 21.02.2019 13:06, Ben Dooks пишет:
>>>>> On 21/02/2019 00:41, Dmitry Osipenko wrote:
>>>>>> 31.10.2018 19:03, Ben Dooks пишет:
>>>>>>> The tx_status callback does not report the state of the transfer
>>>>>>> beyond complete segments. This causes problems with users such as
>>>>>>> ALSA when applications want to know accurately how much data has
>>>>>>> been moved.
>>>>>>>
>>>>>>> This patch addes a function tegra_dma_update_residual() to query
>>>>>>> the hardware and modify the residual information accordinly. It
>>>>>>> takes into account any hardware issues when trying to read the
>>>>>>> state, such as delays between finishing a buffer and signalling
>>>>>>> the interrupt.
>>>>>>>
>>>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>>>>
>>>>>> Hello Ben,
>>>>>>
>>>>>> Do you have any plans to submit a new version of this patch? It's really useful and fixes a real problem with the audio playback. I could help with finalizing the patch and could submit it for you if you happened to lost the interest.
>>>>>
>>>>> Personally I think the original version was fine. It has been tested
>>>>> and returns fairly quickly (I am not a fan of just adding more delay in)
>>>>>
>>>>> My notes say the condition doesn't last for long and the loop tends
>>>>> to terminate within 2 runs.
>>>>>
>>>>
>>>> Okay, so are you going to re-send the patch? We can back to the review after, you need at least to re-send because this series has been outdated. Also please take a look and feel free to use as-is the reduced variant of yours patch that I was carrying and testing for months now [0], it works great.
>>>>
>>>> [0] https://github.com/grate-driver/linux/commit/ab8a67a6f47185f265f16749b55df214aaaefad4
>>>>
>>>
>>> I can try rebasing, but I have not got a lot of time to do any testing
>>> at the moment. I agree I should have remembered to chase this stuff up
>>> earlier.
>>
>> No problems, thank you. I'll help with the testing. And I could rebase the patch and send it out for you if will be needed, please just let me know if you're okay with it.
>>
>
> Hello Ben,
>
> Do you have any status update on the state of the patch? Again, I could help with sending it out for you if you're too busy or something else. Please let me know how we could proceed with getting the fix upstreamed and sorry for disturbing you again with this.
I am currently re-looking at the updates for TDM audio and slave mode
audio for the tegra, I should be able to re-test the original patch
tomorrow.
^ permalink raw reply
* [PATCH 1/7] dmaengine: sprd: Fix the possible crash when getting engine status
From: Baolin Wang @ 2019-04-15 12:14 UTC (permalink / raw)
To: dan.j.williams, vkoul
Cc: eric.long, orsonzhai, zhang.lyra, broonie, baolin.wang, dmaengine,
linux-kernel
In-Reply-To: <cover.1555330115.git.baolin.wang@linaro.org>
We will get a NULL virtual descriptor by vchan_find_desc() when the descriptor
has been submitted, that will crash the kernel when getting the engine status.
In this case, since the descriptor has been submitted, which means the pointer
'schan->cur_desc' will point to the current descriptor, then we can use
'schan->cur_desc' to get the engine status to avoid this issue.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/dma/sprd-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 48431e2..e29342a 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -625,7 +625,7 @@ static enum dma_status sprd_dma_tx_status(struct dma_chan *chan,
else
pos = 0;
} else if (schan->cur_desc && schan->cur_desc->vd.tx.cookie == cookie) {
- struct sprd_dma_desc *sdesc = to_sprd_dma_desc(vd);
+ struct sprd_dma_desc *sdesc = schan->cur_desc;
if (sdesc->dir == DMA_DEV_TO_MEM)
pos = sprd_dma_get_dst_addr(schan);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/7] dmaengine: sprd: Add validation of current descriptor in irq handler
From: Baolin Wang @ 2019-04-15 12:14 UTC (permalink / raw)
To: dan.j.williams, vkoul
Cc: eric.long, orsonzhai, zhang.lyra, broonie, baolin.wang, dmaengine,
linux-kernel
In-Reply-To: <cover.1555330115.git.baolin.wang@linaro.org>
When user terminates one DMA channel to free all its descriptors, but
at the same time one transaction interrupt was triggered possibly, now
we should not handle this interrupt by validating if the 'schan->cur_desc'
was set as NULL to avoid crashing the kernel.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/dma/sprd-dma.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index e29342a..431e289 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -552,12 +552,17 @@ static irqreturn_t dma_irq_handle(int irq, void *dev_id)
schan = &sdev->channels[i];
spin_lock(&schan->vc.lock);
+
+ sdesc = schan->cur_desc;
+ if (!sdesc) {
+ spin_unlock(&schan->vc.lock);
+ return IRQ_HANDLED;
+ }
+
int_type = sprd_dma_get_int_type(schan);
req_type = sprd_dma_get_req_type(schan);
sprd_dma_clear_int(schan);
- sdesc = schan->cur_desc;
-
/* cyclic mode schedule callback */
cyclic = schan->linklist.phy_addr ? true : false;
if (cyclic == true) {
--
1.7.9.5
^ 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