* [4/8,v2] dma: k3dma: Delete axi_config
From: Manivannan Sadhasivam @ 2019-01-05 3:44 UTC (permalink / raw)
To: John Stultz
Cc: lkml, Li Yu, Dan Williams, Vinod Koul, Tanglei Han, Zhuangluan Su,
Ryan Grachek, dmaengine, Guodong Xu
On Fri, Jan 04, 2019 at 12:56:24PM -0800, John Stultz wrote:
> From: Li Yu <liyu65@hisilicon.com>
>
> Axi_config controls whether DMA resources can be accessed in non-secure
> mode, such as linux kernel. The register should be set by the bootloader
> stage and depends on the device.
>
> Thus, this patch removes axi_config from k3dma driver.
>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: Tanglei Han <hantanglei@huawei.com>
> Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
> Cc: Ryan Grachek <ryan@edited.us>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: dmaengine@vger.kernel.org
> Signed-off-by: Li Yu <liyu65@hisilicon.com>
> Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
> [jstultz: Minor tweaks to commit message]
> Signed-off-by: John Stultz <john.stultz@linaro.org>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Thanks,
Mani
> ---
> drivers/dma/k3dma.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
> index df61406..b2060bf 100644
> --- a/drivers/dma/k3dma.c
> +++ b/drivers/dma/k3dma.c
> @@ -52,8 +52,6 @@
> #define CX_SRC 0x814
> #define CX_DST 0x818
> #define CX_CFG 0x81c
> -#define AXI_CFG 0x820
> -#define AXI_CFG_DEFAULT 0x201201
>
> #define CX_LLI_CHAIN_EN 0x2
> #define CX_CFG_EN 0x1
> @@ -168,7 +166,6 @@ static void k3_dma_set_desc(struct k3_dma_phy *phy, struct k3_desc_hw *hw)
> writel_relaxed(hw->count, phy->base + CX_CNT0);
> writel_relaxed(hw->saddr, phy->base + CX_SRC);
> writel_relaxed(hw->daddr, phy->base + CX_DST);
> - writel_relaxed(AXI_CFG_DEFAULT, phy->base + AXI_CFG);
> writel_relaxed(hw->config, phy->base + CX_CFG);
> }
>
> --
> 2.7.4
>
^ permalink raw reply
* [3/8,v2] dma: k3dma: Upgrade k3dma driver to support hisi_asp_dma hardware
From: Manivannan Sadhasivam @ 2019-01-05 3:41 UTC (permalink / raw)
To: John Stultz
Cc: lkml, Youlin Wang, Dan Williams, Vinod Koul, Zhuangluan Su,
Ryan Grachek, dmaengine, Tanglei Han
Hi John,
On Fri, Jan 04, 2019 at 12:56:23PM -0800, John Stultz wrote:
> From: Youlin Wang <wwx575822@notesmail.huawei.com>
>
> There is an new "hisi-pcm-asp-dma-1.0" device added in
> "arch/arm64/boot/dts/hisilicon/hi3660.dtsi".
> So we have to add a matching id in the driver file:
> .compatible = "hisilicon,hisi-pcm-asp-dma-1.0"
>
> And also hisi-pcm-asp dma device needs no setting to the clock.
> So we skip this by adding and using soc data flags.
>
> After above this driver will support both k3 and hisi_asp dma hardware.
>
Small description about the hardware (ASP DMAC) would be really helpful.
Thanks,
Mani
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
> Cc: Ryan Grachek <ryan@edited.us>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: dmaengine@vger.kernel.org
> Signed-off-by: Youlin Wang <wwx575822@notesmail.huawei.com>
> Signed-off-by: Tanglei Han <hantanglei@huawei.com>
> [jstultz: Reworked to use of_match_data]
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
> v2:
> * Reworked to use of_match_data
> ---
> drivers/dma/k3dma.c | 37 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
> index fdec2b6..df61406 100644
> --- a/drivers/dma/k3dma.c
> +++ b/drivers/dma/k3dma.c
> @@ -116,6 +116,13 @@ struct k3_dma_dev {
> unsigned int irq;
> };
>
> +
> +#define K3_FLAG_NOCLK (1<<0)
> +struct k3dma_soc_data {
> + unsigned long flags;
> +};
> +
> +
> #define to_k3_dma(dmadev) container_of(dmadev, struct k3_dma_dev, slave)
>
> static int k3_dma_config_write(struct dma_chan *chan,
> @@ -790,8 +797,21 @@ static int k3_dma_transfer_resume(struct dma_chan *chan)
> return 0;
> }
>
> +static const struct k3dma_soc_data k3_v1_dma_data = {
> + .flags = 0,
> +};
> +
> +static const struct k3dma_soc_data asp_v1_dma_data = {
> + .flags = K3_FLAG_NOCLK,
> +};
> +
> static const struct of_device_id k3_pdma_dt_ids[] = {
> - { .compatible = "hisilicon,k3-dma-1.0", },
> + { .compatible = "hisilicon,k3-dma-1.0",
> + .data = &k3_v1_dma_data
> + },
> + { .compatible = "hisilicon,hisi-pcm-asp-dma-1.0",
> + .data = &asp_v1_dma_data
> + },
> {}
> };
> MODULE_DEVICE_TABLE(of, k3_pdma_dt_ids);
> @@ -810,6 +830,7 @@ static struct dma_chan *k3_of_dma_simple_xlate(struct of_phandle_args *dma_spec,
>
> static int k3_dma_probe(struct platform_device *op)
> {
> + const struct k3dma_soc_data *soc_data;
> struct k3_dma_dev *d;
> const struct of_device_id *of_id;
> struct resource *iores;
> @@ -823,6 +844,10 @@ static int k3_dma_probe(struct platform_device *op)
> if (!d)
> return -ENOMEM;
>
> + soc_data = device_get_match_data(&op->dev);
> + if (!soc_data)
> + return -EINVAL;
> +
> d->base = devm_ioremap_resource(&op->dev, iores);
> if (IS_ERR(d->base))
> return PTR_ERR(d->base);
> @@ -835,10 +860,12 @@ static int k3_dma_probe(struct platform_device *op)
> "dma-requests", &d->dma_requests);
> }
>
> - d->clk = devm_clk_get(&op->dev, NULL);
> - if (IS_ERR(d->clk)) {
> - dev_err(&op->dev, "no dma clk\n");
> - return PTR_ERR(d->clk);
> + if (!(soc_data->flags & K3_FLAG_NOCLK)) {
> + d->clk = devm_clk_get(&op->dev, NULL);
> + if (IS_ERR(d->clk)) {
> + dev_err(&op->dev, "no dma clk\n");
> + return PTR_ERR(d->clk);
> + }
> }
>
> irq = platform_get_irq(op, 0);
> --
> 2.7.4
>
^ permalink raw reply
* dmaengine: fsl-edma: use struct_size() in kzalloc()
From: Gustavo A. R. Silva @ 2019-01-04 21:25 UTC (permalink / raw)
To: Dan Williams, Vinod Koul; +Cc: dmaengine, linux-kernel, Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/dma/fsl-edma-common.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
index 8876c4c1bb2c..fe529100674f 100644
--- a/drivers/dma/fsl-edma-common.c
+++ b/drivers/dma/fsl-edma-common.c
@@ -339,9 +339,7 @@ static struct fsl_edma_desc *fsl_edma_alloc_desc(struct fsl_edma_chan *fsl_chan,
struct fsl_edma_desc *fsl_desc;
int i;
- fsl_desc = kzalloc(sizeof(*fsl_desc) +
- sizeof(struct fsl_edma_sw_tcd) *
- sg_len, GFP_NOWAIT);
+ fsl_desc = kzalloc(struct_size(fsl_desc, tcd, sg_len), GFP_NOWAIT);
if (!fsl_desc)
return NULL;
^ permalink raw reply related
* dmaengine: tegra-apb: Use struct_size() in devm_kzalloc()
From: Gustavo A. R. Silva @ 2019-01-04 21:16 UTC (permalink / raw)
To: Laxman Dewangan, Jon Hunter, Dan Williams, Vinod Koul,
Thierry Reding
Cc: dmaengine, linux-tegra, linux-kernel, Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = devm_kzalloc(dev, sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = devm_kzalloc(dev, struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/dma/tegra20-apb-dma.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 9a558e30c461..697f316055cf 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -1319,8 +1319,9 @@ static int tegra_dma_probe(struct platform_device *pdev)
return -ENODEV;
}
- tdma = devm_kzalloc(&pdev->dev, sizeof(*tdma) + cdata->nr_channels *
- sizeof(struct tegra_dma_channel), GFP_KERNEL);
+ tdma = devm_kzalloc(&pdev->dev,
+ struct_size(tdma, channels, cdata->nr_channels),
+ GFP_KERNEL);
if (!tdma)
return -ENOMEM;
^ permalink raw reply related
* [5/8,v2] dma: k3dma: Add support to dma_avail_chan
From: John Stultz @ 2019-01-04 20:56 UTC (permalink / raw)
To: lkml
Cc: Li Yu, Dan Williams, Vinod Koul, Tanglei Han, Zhuangluan Su,
Ryan Grachek, Manivannan Sadhasivam, Guodong Xu, dmaengine,
John Stultz
From: Li Yu <liyu65@hisilicon.com>
dma_avail_chan as a property for k3dma, it defines available dma
channels which a non-secure mode driver can use.
One sample usage of this is in Hi3660 SoC. DMA channel 0 is
reserved to lpm3, which is a coprocessor for power management. So
as a result, any request in kernel (which runs on main processor
and in non-secure mode) should start from at least channel 1.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Tanglei Han <hantanglei@huawei.com>
Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
Cc: Ryan Grachek <ryan@edited.us>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Guodong Xu <guodong.xu@linaro.org>
Cc: dmaengine@vger.kernel.org
Signed-off-by: Li Yu <liyu65@hisilicon.com>
[jstultz: Reworked to use a channel mask]
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
drivers/dma/k3dma.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index b2060bf..431094b 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -111,6 +111,7 @@ struct k3_dma_dev {
struct dma_pool *pool;
u32 dma_channels;
u32 dma_requests;
+ u32 dma_avail_chan;
unsigned int irq;
};
@@ -318,6 +319,9 @@ static void k3_dma_tasklet(unsigned long arg)
/* check new channel request in d->chan_pending */
spin_lock_irq(&d->lock);
for (pch = 0; pch < d->dma_channels; pch++) {
+ if (!(d->dma_avail_chan & (1<<pch)))
+ continue;
+
p = &d->phy[pch];
if (p->vchan == NULL && !list_empty(&d->chan_pending)) {
@@ -335,6 +339,9 @@ static void k3_dma_tasklet(unsigned long arg)
spin_unlock_irq(&d->lock);
for (pch = 0; pch < d->dma_channels; pch++) {
+ if (!(d->dma_avail_chan & (1<<pch)))
+ continue;
+
if (pch_alloc & (1 << pch)) {
p = &d->phy[pch];
c = p->vchan;
@@ -855,6 +862,13 @@ static int k3_dma_probe(struct platform_device *op)
"dma-channels", &d->dma_channels);
of_property_read_u32((&op->dev)->of_node,
"dma-requests", &d->dma_requests);
+ ret = of_property_read_u32((&op->dev)->of_node,
+ "dma-avail-chan", &d->dma_avail_chan);
+ if (ret) {
+ dev_warn(&op->dev,
+ "dma-avail-chan doesn't exist, considering all as available.\n");
+ d->dma_avail_chan = (u32)~0UL;
+ }
}
if (!(soc_data->flags & K3_FLAG_NOCLK)) {
@@ -886,8 +900,12 @@ static int k3_dma_probe(struct platform_device *op)
return -ENOMEM;
for (i = 0; i < d->dma_channels; i++) {
- struct k3_dma_phy *p = &d->phy[i];
+ struct k3_dma_phy *p;
+
+ if (!(d->dma_avail_chan & (1<<i)))
+ continue;
+ p = &d->phy[i];
p->idx = i;
p->base = d->base + i * 0x40;
}
^ permalink raw reply related
* [4/8,v2] dma: k3dma: Delete axi_config
From: John Stultz @ 2019-01-04 20:56 UTC (permalink / raw)
To: lkml
Cc: Li Yu, Dan Williams, Vinod Koul, Tanglei Han, Zhuangluan Su,
Ryan Grachek, Manivannan Sadhasivam, dmaengine, Guodong Xu,
John Stultz
From: Li Yu <liyu65@hisilicon.com>
Axi_config controls whether DMA resources can be accessed in non-secure
mode, such as linux kernel. The register should be set by the bootloader
stage and depends on the device.
Thus, this patch removes axi_config from k3dma driver.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Tanglei Han <hantanglei@huawei.com>
Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
Cc: Ryan Grachek <ryan@edited.us>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: dmaengine@vger.kernel.org
Signed-off-by: Li Yu <liyu65@hisilicon.com>
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
[jstultz: Minor tweaks to commit message]
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
drivers/dma/k3dma.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index df61406..b2060bf 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -52,8 +52,6 @@
#define CX_SRC 0x814
#define CX_DST 0x818
#define CX_CFG 0x81c
-#define AXI_CFG 0x820
-#define AXI_CFG_DEFAULT 0x201201
#define CX_LLI_CHAIN_EN 0x2
#define CX_CFG_EN 0x1
@@ -168,7 +166,6 @@ static void k3_dma_set_desc(struct k3_dma_phy *phy, struct k3_desc_hw *hw)
writel_relaxed(hw->count, phy->base + CX_CNT0);
writel_relaxed(hw->saddr, phy->base + CX_SRC);
writel_relaxed(hw->daddr, phy->base + CX_DST);
- writel_relaxed(AXI_CFG_DEFAULT, phy->base + AXI_CFG);
writel_relaxed(hw->config, phy->base + CX_CFG);
}
^ permalink raw reply related
* [3/8,v2] dma: k3dma: Upgrade k3dma driver to support hisi_asp_dma hardware
From: John Stultz @ 2019-01-04 20:56 UTC (permalink / raw)
To: lkml
Cc: Youlin Wang, Dan Williams, Vinod Koul, Zhuangluan Su,
Ryan Grachek, Manivannan Sadhasivam, dmaengine, Tanglei Han,
John Stultz
From: Youlin Wang <wwx575822@notesmail.huawei.com>
There is an new "hisi-pcm-asp-dma-1.0" device added in
"arch/arm64/boot/dts/hisilicon/hi3660.dtsi".
So we have to add a matching id in the driver file:
.compatible = "hisilicon,hisi-pcm-asp-dma-1.0"
And also hisi-pcm-asp dma device needs no setting to the clock.
So we skip this by adding and using soc data flags.
After above this driver will support both k3 and hisi_asp dma hardware.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
Cc: Ryan Grachek <ryan@edited.us>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: dmaengine@vger.kernel.org
Signed-off-by: Youlin Wang <wwx575822@notesmail.huawei.com>
Signed-off-by: Tanglei Han <hantanglei@huawei.com>
[jstultz: Reworked to use of_match_data]
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
v2:
* Reworked to use of_match_data
---
drivers/dma/k3dma.c | 37 ++++++++++++++++++++++++++++++++-----
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index fdec2b6..df61406 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -116,6 +116,13 @@ struct k3_dma_dev {
unsigned int irq;
};
+
+#define K3_FLAG_NOCLK (1<<0)
+struct k3dma_soc_data {
+ unsigned long flags;
+};
+
+
#define to_k3_dma(dmadev) container_of(dmadev, struct k3_dma_dev, slave)
static int k3_dma_config_write(struct dma_chan *chan,
@@ -790,8 +797,21 @@ static int k3_dma_transfer_resume(struct dma_chan *chan)
return 0;
}
+static const struct k3dma_soc_data k3_v1_dma_data = {
+ .flags = 0,
+};
+
+static const struct k3dma_soc_data asp_v1_dma_data = {
+ .flags = K3_FLAG_NOCLK,
+};
+
static const struct of_device_id k3_pdma_dt_ids[] = {
- { .compatible = "hisilicon,k3-dma-1.0", },
+ { .compatible = "hisilicon,k3-dma-1.0",
+ .data = &k3_v1_dma_data
+ },
+ { .compatible = "hisilicon,hisi-pcm-asp-dma-1.0",
+ .data = &asp_v1_dma_data
+ },
{}
};
MODULE_DEVICE_TABLE(of, k3_pdma_dt_ids);
@@ -810,6 +830,7 @@ static struct dma_chan *k3_of_dma_simple_xlate(struct of_phandle_args *dma_spec,
static int k3_dma_probe(struct platform_device *op)
{
+ const struct k3dma_soc_data *soc_data;
struct k3_dma_dev *d;
const struct of_device_id *of_id;
struct resource *iores;
@@ -823,6 +844,10 @@ static int k3_dma_probe(struct platform_device *op)
if (!d)
return -ENOMEM;
+ soc_data = device_get_match_data(&op->dev);
+ if (!soc_data)
+ return -EINVAL;
+
d->base = devm_ioremap_resource(&op->dev, iores);
if (IS_ERR(d->base))
return PTR_ERR(d->base);
@@ -835,10 +860,12 @@ static int k3_dma_probe(struct platform_device *op)
"dma-requests", &d->dma_requests);
}
- d->clk = devm_clk_get(&op->dev, NULL);
- if (IS_ERR(d->clk)) {
- dev_err(&op->dev, "no dma clk\n");
- return PTR_ERR(d->clk);
+ if (!(soc_data->flags & K3_FLAG_NOCLK)) {
+ d->clk = devm_clk_get(&op->dev, NULL);
+ if (IS_ERR(d->clk)) {
+ dev_err(&op->dev, "no dma clk\n");
+ return PTR_ERR(d->clk);
+ }
}
irq = platform_get_irq(op, 0);
^ permalink raw reply related
* [2/8,v2] Documentation: bindings: k3dma: Add binding for dma-avail-chan
From: John Stultz @ 2019-01-04 20:56 UTC (permalink / raw)
To: lkml
Cc: John Stultz, Vinod Koul, Rob Herring, Mark Rutland, Tanglei Han,
Zhuangluan Su, Ryan Grachek, Manivannan Sadhasivam, dmaengine,
devicetree
Some dma channels can be reserved for secure mode or other
hardware on the SoC, so provide a binding for a bitmask
listing the available channels for the kernel to use.
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Tanglei Han <hantanglei@huawei.com>
Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
Cc: Ryan Grachek <ryan@edited.us>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: dmaengine@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
Documentation/devicetree/bindings/dma/k3dma.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/k3dma.txt b/Documentation/devicetree/bindings/dma/k3dma.txt
index 10a2f15..1c466c1 100644
--- a/Documentation/devicetree/bindings/dma/k3dma.txt
+++ b/Documentation/devicetree/bindings/dma/k3dma.txt
@@ -14,6 +14,9 @@ Required properties:
have specific request line
- clocks: clock required
+Optional properties:
+- dma-avail-chan: Bitmask of available physical channels
+
Example:
Controller:
^ permalink raw reply related
* [1/8,v2] Documentation: bindings: k3dma: Extend the k3dma driver binding to support hisi-asp
From: John Stultz @ 2019-01-04 20:56 UTC (permalink / raw)
To: lkml
Cc: Youlin Wang, Vinod Koul, Rob Herring, Mark Rutland, Zhuangluan Su,
Tanglei Han, Ryan Grachek, Manivannan Sadhasivam, dmaengine,
devicetree, John Stultz
From: Youlin Wang <wwx575822@notesmail.huawei.com>
Extend the k3dma driver binding to support hisi-asp hardware
variants.
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
Cc: Tanglei Han <hantanglei@huawei.com>
Cc: Ryan Grachek <ryan@edited.us>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: dmaengine@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Youlin Wang <wwx575822@notesmail.huawei.com>
Signed-off-by: Tanglei Han <hantanglei@huawei.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
v2: Simplify patch, removing extranious examples
---
Documentation/devicetree/bindings/dma/k3dma.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dma/k3dma.txt b/Documentation/devicetree/bindings/dma/k3dma.txt
index 4945aea..10a2f15 100644
--- a/Documentation/devicetree/bindings/dma/k3dma.txt
+++ b/Documentation/devicetree/bindings/dma/k3dma.txt
@@ -3,7 +3,9 @@
See dma.txt first
Required properties:
-- compatible: Should be "hisilicon,k3-dma-1.0"
+- compatible: Must be one of
+- "hisilicon,k3-dma-1.0"
+- "hisilicon,hisi-pcm-asp-dma-1.0"
- reg: Should contain DMA registers location and length.
- interrupts: Should contain one interrupt shared by all channel
- #dma-cells: see dma.txt, should be 1, para number
^ permalink raw reply related
* dmaengine: st_fdma: use struct_size() in kzalloc()
From: Gustavo A. R. Silva @ 2019-01-04 18:43 UTC (permalink / raw)
To: Patrice Chotard, Vinod Koul, Dan Williams
Cc: linux-arm-kernel, dmaengine, linux-kernel, Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/dma/st_fdma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index 07c20aa2e955..df6b73028ecb 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -243,8 +243,7 @@ static struct st_fdma_desc *st_fdma_alloc_desc(struct st_fdma_chan *fchan,
struct st_fdma_desc *fdesc;
int i;
- fdesc = kzalloc(sizeof(*fdesc) +
- sizeof(struct st_fdma_sw_node) * sg_len, GFP_NOWAIT);
+ fdesc = kzalloc(struct_size(fdesc, node, sg_len), GFP_NOWAIT);
if (!fdesc)
return NULL;
^ permalink raw reply related
* dmaengine: bcm2835: Use struct_size() in kzalloc()
From: Gustavo A. R. Silva @ 2019-01-04 18:30 UTC (permalink / raw)
To: Dan Williams, Vinod Koul, Eric Anholt, Stefan Wahren,
Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list
Cc: dmaengine, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/dma/bcm2835-dma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index 1a44c8086d77..7beec403c2c9 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -312,8 +312,7 @@ static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
return NULL;
/* allocate and setup the descriptor. */
- d = kzalloc(sizeof(*d) + frames * sizeof(struct bcm2835_cb_entry),
- gfp);
+ d = kzalloc(struct_size(d, cb_list, frames), gfp);
if (!d)
return NULL;
^ permalink raw reply related
* dmaengine: qcom: bam_dma: use struct_size() in kzalloc()
From: Gustavo A. R. Silva @ 2019-01-04 17:32 UTC (permalink / raw)
To: Andy Gross, David Brown, Dan Williams, Vinod Koul
Cc: linux-arm-msm, dmaengine, linux-kernel, Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/dma/qcom/bam_dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 1617715aa6e0..cb860cb53c27 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -636,8 +636,8 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
num_alloc += DIV_ROUND_UP(sg_dma_len(sg), BAM_FIFO_SIZE);
/* allocate enough room to accomodate the number of entries */
- async_desc = kzalloc(sizeof(*async_desc) +
- (num_alloc * sizeof(struct bam_desc_hw)), GFP_NOWAIT);
+ async_desc = kzalloc(struct_size(async_desc, desc, num_alloc),
+ GFP_NOWAIT);
if (!async_desc)
goto err_out;
^ permalink raw reply related
* [1/3] k3dma: Upgrade k3dma drever to support hisi_asp_dma hardware
From: John Stultz @ 2019-01-04 17:32 UTC (permalink / raw)
To: Vinod Koul
Cc: h00249924,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Youlin Wang, hanxiaolong3, Zhuangluan Su, Hantanglei, lkml,
Kongfei, ninggaoyu, Liyuequan, dmaengine, Dan Williams,
huangli (I), wangyoulin, linux-arm-kernel, Qianli (A)
On Fri, Jan 4, 2019 at 9:25 AM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 28-12-18, 14:36, h00249924 wrote:
> > From: Youlin Wang <wwx575822@notesmail.huawei.com>
> >
> > There is an new "hisi-pcm-asp-dma-1.0" device added in
> > "arch/arm64/boot/dts/hisilicon/hi3660.dtsi".
> > So we have to add a matching id in the driver file:
> > "{ .compatible = "hisilicon,hisi-pcm-asp-dma-1.0", }"
> >
> > And also hisi-pcm-asp dma device needs no setting to the clock.
> > So we skip this by "if" sentence on id string matching:
> > "if (strcasecmp((of_id->compatible), (k3_pdma_dt_ids[0].compatible)) == 0)"
> >
> > After above this driver will support both k3 and hisi_asp dma hardware.
> >
> > Signed-off-by: Youlin Wang <wwx575822@notesmail.huawei.com>
> > Signed-off-by: Tanglei Han <hantanglei@huawei.com>
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Vinod Koul <vkoul@kernel.org>
> > ---
> > drivers/dma/k3dma.c | 11 +++++++----
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
> > index fdec2b6..10eecc2 100644
> > --- a/drivers/dma/k3dma.c
> > +++ b/drivers/dma/k3dma.c
> > @@ -792,6 +792,7 @@ static int k3_dma_transfer_resume(struct dma_chan *chan)
> >
> > static const struct of_device_id k3_pdma_dt_ids[] = {
> > { .compatible = "hisilicon,k3-dma-1.0", },
> > + { .compatible = "hisilicon,hisi-pcm-asp-dma-1.0", },
>
> The binding doc patch should precede this..
>
> > {}
> > };
> > MODULE_DEVICE_TABLE(of, k3_pdma_dt_ids);
> > @@ -835,10 +836,12 @@ static int k3_dma_probe(struct platform_device *op)
> > "dma-requests", &d->dma_requests);
> > }
> >
> > - d->clk = devm_clk_get(&op->dev, NULL);
> > - if (IS_ERR(d->clk)) {
> > - dev_err(&op->dev, "no dma clk\n");
> > - return PTR_ERR(d->clk);
> > + if (strcasecmp((of_id->compatible), (k3_pdma_dt_ids[0].compatible)) == 0) {
> > + d->clk = devm_clk_get(&op->dev, NULL);
>
> who provides clk in this case? how does this scale if you have another
> compatible in future for newer version of controller?
Yea, I've pushed a few times in internal review to use match_data() here.
Tanglei Han: If its ok, I've spent some time integrating these changes
with some other pending k3dma changes. So I'll rework and integrate
some of the review feedback on this and resend it so we can get this
moving a little faster.
I'll leave the i2s feedback to you, so please continue reworking and
resubmitting those, but I'll handle upstreaming the k3dma changes
(keeping you on cc of course).
thanks
-john
^ permalink raw reply
* [2/2] dmaengine: qcom_hidma: assign channel cookie correctly
From: Vinod Koul @ 2019-01-04 17:31 UTC (permalink / raw)
To: Shunyong Yang
Cc: okaya, andy.gross, david.brown, dan.j.williams, dmaengine,
linux-kernel, Joey Zheng
On 07-12-18, 12:29, Shunyong Yang wrote:
> When dma_cookie_complete() is called in hidma_process_completed(),
> dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then,
> hidma_txn_is_success() will be called to use channel cookie
> mchan->last_success to do additional DMA status check. Current code
> assigns mchan->last_success after dma_cookie_complete(). This causes
> a race condition of dma_cookie_status() returns DMA_COMPLETE before
> mchan->last_success is assigned correctly. The race will cause
> hidma_tx_status() return DMA_ERROR but the transaction is actually a
> success. Moreover, in async_tx case, it will cause a timeout panic
> in async_tx_quiesce().
>
> Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for
> transaction
> ...
> Call trace:
> [<ffff000008089994>] dump_backtrace+0x0/0x1f4
> [<ffff000008089bac>] show_stack+0x24/0x2c
> [<ffff00000891e198>] dump_stack+0x84/0xa8
> [<ffff0000080da544>] panic+0x12c/0x29c
> [<ffff0000045d0334>] async_tx_quiesce+0xa4/0xc8 [async_tx]
> [<ffff0000045d03c8>] async_trigger_callback+0x70/0x1c0 [async_tx]
> [<ffff0000048b7d74>] raid_run_ops+0x86c/0x1540 [raid456]
> [<ffff0000048bd084>] handle_stripe+0x5e8/0x1c7c [raid456]
> [<ffff0000048be9ec>] handle_active_stripes.isra.45+0x2d4/0x550 [raid456]
> [<ffff0000048beff4>] raid5d+0x38c/0x5d0 [raid456]
> [<ffff000008736538>] md_thread+0x108/0x168
> [<ffff0000080fb1cc>] kthread+0x10c/0x138
> [<ffff000008084d34>] ret_from_fork+0x10/0x18
>
> Cc: Joey Zheng <yu.zheng@hxt-semitech.com>
> Signed-off-by: Shunyong Yang <shunyong.yang@hxt-semitech.com>
> ---
> drivers/dma/qcom/hidma.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index 9d639ed1955a..aa88bcceda20 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -138,24 +138,24 @@ static void hidma_process_completed(struct hidma_chan *mchan)
> desc = &mdesc->desc;
> last_cookie = desc->cookie;
>
> + llstat = hidma_ll_status(mdma->lldev, mdesc->tre_ch);
> +
> spin_lock_irqsave(&mchan->lock, irqflags);
> + if (llstat == DMA_COMPLETE) {
> + mchan->last_success = last_cookie;
> + result.result = DMA_TRANS_NOERROR;
> + } else
> + result.result = DMA_TRANS_ABORTED;
Coding style mandates that else should also have braces, please fix that
^ permalink raw reply
* [1/3] k3dma: Upgrade k3dma drever to support hisi_asp_dma hardware
From: Vinod Koul @ 2019-01-04 17:24 UTC (permalink / raw)
To: h00249924
Cc: dmaengine, devicetree, linux-kernel, linux-arm-kernel,
suzhuangluan, kongfei, liyuequan, cash.qianli, huangli295,
hantanglei, wangyoulin1, ninggaoyu, hanxiaolong3, Youlin Wang,
Dan Williams
On 28-12-18, 14:36, h00249924 wrote:
> From: Youlin Wang <wwx575822@notesmail.huawei.com>
>
> There is an new "hisi-pcm-asp-dma-1.0" device added in
> "arch/arm64/boot/dts/hisilicon/hi3660.dtsi".
> So we have to add a matching id in the driver file:
> "{ .compatible = "hisilicon,hisi-pcm-asp-dma-1.0", }"
>
> And also hisi-pcm-asp dma device needs no setting to the clock.
> So we skip this by "if" sentence on id string matching:
> "if (strcasecmp((of_id->compatible), (k3_pdma_dt_ids[0].compatible)) == 0)"
>
> After above this driver will support both k3 and hisi_asp dma hardware.
>
> Signed-off-by: Youlin Wang <wwx575822@notesmail.huawei.com>
> Signed-off-by: Tanglei Han <hantanglei@huawei.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> ---
> drivers/dma/k3dma.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
> index fdec2b6..10eecc2 100644
> --- a/drivers/dma/k3dma.c
> +++ b/drivers/dma/k3dma.c
> @@ -792,6 +792,7 @@ static int k3_dma_transfer_resume(struct dma_chan *chan)
>
> static const struct of_device_id k3_pdma_dt_ids[] = {
> { .compatible = "hisilicon,k3-dma-1.0", },
> + { .compatible = "hisilicon,hisi-pcm-asp-dma-1.0", },
The binding doc patch should precede this..
> {}
> };
> MODULE_DEVICE_TABLE(of, k3_pdma_dt_ids);
> @@ -835,10 +836,12 @@ static int k3_dma_probe(struct platform_device *op)
> "dma-requests", &d->dma_requests);
> }
>
> - d->clk = devm_clk_get(&op->dev, NULL);
> - if (IS_ERR(d->clk)) {
> - dev_err(&op->dev, "no dma clk\n");
> - return PTR_ERR(d->clk);
> + if (strcasecmp((of_id->compatible), (k3_pdma_dt_ids[0].compatible)) == 0) {
> + d->clk = devm_clk_get(&op->dev, NULL);
who provides clk in this case? how does this scale if you have another
compatible in future for newer version of controller?
> + if (IS_ERR(d->clk)) {
> + dev_err(&op->dev, "no dma clk\n");
> + return PTR_ERR(d->clk);
> + }
> }
>
> irq = platform_get_irq(op, 0);
> --
> 1.9.1
^ permalink raw reply
* [v9,1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support
From: Vinod Koul @ 2019-01-04 17:19 UTC (permalink / raw)
To: Long Cheng
Cc: Randy Dunlap, Rob Herring, Mark Rutland, Ryder Lee, Sean Wang,
Nicolas Boichat, Matthias Brugger, Dan Williams,
Greg Kroah-Hartman, Jiri Slaby, Sean Wang, dmaengine, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-serial,
srv_heupstream, Yingjoe Chen, YT Shen, Zhenbao Liu
On 02-01-19, 10:12, Long Cheng wrote:
> In DMA engine framework, add 8250 uart dma to support MediaTek uart.
> If MediaTek uart enabled(SERIAL_8250_MT6577), and want to improve
> the performance, can enable the function.
Is the DMA controller UART specific, can it work with other controllers
as well, if so you should get rid of uart name in patch
> +#define MTK_UART_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2)
Why are the channels not coming from DT?
> +
> +#define VFF_EN_B BIT(0)
> +#define VFF_STOP_B BIT(0)
> +#define VFF_FLUSH_B BIT(0)
> +#define VFF_4G_SUPPORT_B BIT(0)
> +#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/
> +#define VFF_RX_INT_EN1_B BIT(1)
> +#define VFF_TX_INT_EN_B BIT(0) /*tx left size >= vff thre*/
space around /* space */ also run checkpatch to check for style errors
> +static void mtk_uart_apdma_start_tx(struct mtk_chan *c)
> +{
> + unsigned int len, send, left, wpt, d_wpt, tmp;
> + int ret;
> +
> + left = mtk_uart_apdma_read(c, VFF_LEFT_SIZE);
> + if (!left) {
> + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B);
> + return;
> + }
> +
> + /* Wait 1sec for flush, can't sleep*/
> + ret = readx_poll_timeout(readl, c->base + VFF_FLUSH, tmp,
> + tmp != VFF_FLUSH_B, 0, 1000000);
> + if (ret)
> + dev_warn(c->vc.chan.device->dev, "tx: fail, debug=0x%x\n",
> + mtk_uart_apdma_read(c, VFF_DEBUG_STATUS));
> +
> + send = min_t(unsigned int, left, c->desc->avail_len);
> + wpt = mtk_uart_apdma_read(c, VFF_WPT);
> + len = mtk_uart_apdma_read(c, VFF_LEN);
> +
> + d_wpt = wpt + send;
> + if ((d_wpt & VFF_RING_SIZE) >= len) {
> + d_wpt = d_wpt - len;
> + d_wpt = d_wpt ^ VFF_RING_WRAP;
> + }
> + mtk_uart_apdma_write(c, VFF_WPT, d_wpt);
> +
> + c->desc->avail_len -= send;
> +
> + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B);
> + if (mtk_uart_apdma_read(c, VFF_FLUSH) == 0U)
> + mtk_uart_apdma_write(c, VFF_FLUSH, VFF_FLUSH_B);
> +}
> +
> +static void mtk_uart_apdma_start_rx(struct mtk_chan *c)
> +{
> + struct mtk_uart_apdma_desc *d = c->desc;
> + unsigned int len, wg, rg, cnt;
> +
> + if ((mtk_uart_apdma_read(c, VFF_VALID_SIZE) == 0U) ||
> + !d || !vchan_next_desc(&c->vc))
> + return;
> +
> + len = mtk_uart_apdma_read(c, VFF_LEN);
> + rg = mtk_uart_apdma_read(c, VFF_RPT);
> + wg = mtk_uart_apdma_read(c, VFF_WPT);
> + if ((rg ^ wg) & VFF_RING_WRAP)
> + cnt = (wg & VFF_RING_SIZE) + len - (rg & VFF_RING_SIZE);
> + else
> + cnt = (wg & VFF_RING_SIZE) - (rg & VFF_RING_SIZE);
> +
> + c->rx_status = cnt;
> + mtk_uart_apdma_write(c, VFF_RPT, wg);
> +
> + list_del(&d->vd.node);
> + vchan_cookie_complete(&d->vd);
> +}
this looks odd, why do you have different rx and tx start routines?
> +static int mtk_uart_apdma_alloc_chan_resources(struct dma_chan *chan)
> +{
> + struct mtk_uart_apdmadev *mtkd = to_mtk_uart_apdma_dev(chan->device);
> + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
> + u32 tmp;
> + int ret;
> +
> + pm_runtime_get_sync(mtkd->ddev.dev);
> +
> + mtk_uart_apdma_write(c, VFF_ADDR, 0);
> + mtk_uart_apdma_write(c, VFF_THRE, 0);
> + mtk_uart_apdma_write(c, VFF_LEN, 0);
> + mtk_uart_apdma_write(c, VFF_RST, VFF_WARM_RST_B);
> +
> + ret = readx_poll_timeout(readl, c->base + VFF_EN, tmp,
> + tmp == 0, 10, 100);
> + if (ret) {
> + dev_err(chan->device->dev, "dma reset: fail, timeout\n");
> + return ret;
> + }
register read does reset?
> +
> + if (!c->requested) {
> + c->requested = true;
> + ret = request_irq(mtkd->dma_irq[chan->chan_id],
> + mtk_uart_apdma_irq_handler, IRQF_TRIGGER_NONE,
> + KBUILD_MODNAME, chan);
why is the irq not requested in driver probe?
> +static enum dma_status mtk_uart_apdma_tx_status(struct dma_chan *chan,
> + dma_cookie_t cookie,
> + struct dma_tx_state *txstate)
> +{
> + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
> + enum dma_status ret;
> + unsigned long flags;
> +
> + if (!txstate)
> + return DMA_ERROR;
> +
> + ret = dma_cookie_status(chan, cookie, txstate);
> + spin_lock_irqsave(&c->vc.lock, flags);
> + if (ret == DMA_IN_PROGRESS) {
> + c->rx_status = mtk_uart_apdma_read(c, VFF_RPT) & VFF_RING_SIZE;
> + dma_set_residue(txstate, c->rx_status);
> + } else if (ret == DMA_COMPLETE && c->cfg.direction == DMA_DEV_TO_MEM) {
why set reside when it is complete? also reside can be null, that should
be checked as well
> +static struct dma_async_tx_descriptor *mtk_uart_apdma_prep_slave_sg
> + (struct dma_chan *chan, struct scatterlist *sgl,
> + unsigned int sglen, enum dma_transfer_direction dir,
> + unsigned long tx_flags, void *context)
> +{
> + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
> + struct mtk_uart_apdma_desc *d;
> +
> + if ((dir != DMA_DEV_TO_MEM) &&
> + (dir != DMA_MEM_TO_DEV)) {
> + dev_err(chan->device->dev, "bad direction\n");
> + return NULL;
> + }
we have a macro for this
> +
> + /* Now allocate and setup the descriptor */
> + d = kzalloc(sizeof(*d), GFP_ATOMIC);
> + if (!d)
> + return NULL;
> +
> + /* sglen is 1 */
?
> +static int mtk_uart_apdma_slave_config(struct dma_chan *chan,
> + struct dma_slave_config *cfg)
> +{
> + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
> + struct mtk_uart_apdmadev *mtkd =
> + to_mtk_uart_apdma_dev(c->vc.chan.device);
> +
> + c->cfg = *cfg;
> +
> + if (cfg->direction == DMA_DEV_TO_MEM) {
fg->direction is deprecated, in fact I have removed all users recently,
please do not use this
> + unsigned int rx_len = cfg->src_addr_width * 1024;
> +
> + mtk_uart_apdma_write(c, VFF_ADDR, cfg->src_addr);
> + mtk_uart_apdma_write(c, VFF_LEN, rx_len);
> + mtk_uart_apdma_write(c, VFF_THRE, VFF_RX_THRE(rx_len));
> + mtk_uart_apdma_write(c, VFF_INT_EN,
> + VFF_RX_INT_EN0_B | VFF_RX_INT_EN1_B);
> + mtk_uart_apdma_write(c, VFF_RPT, 0);
> + mtk_uart_apdma_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
> + mtk_uart_apdma_write(c, VFF_EN, VFF_EN_B);
why are we writing this here, we are supposed to do that when txn
starts!
> +static int mtk_uart_apdma_device_resume(struct dma_chan *chan)
> +{
> + /* just for check caps pass */
> + return 0;
> +}
if you do not support this please remove this!
> +static void mtk_uart_apdma_free(struct mtk_uart_apdmadev *mtkd)
> +{
> + while (list_empty(&mtkd->ddev.channels) == 0) {
> + struct mtk_chan *c = list_first_entry(&mtkd->ddev.channels,
> + struct mtk_chan, vc.chan.device_node);
> +
> + list_del(&c->vc.chan.device_node);
> + tasklet_kill(&c->vc.task);
> + }
> +}
> +
> +static const struct of_device_id mtk_uart_apdma_match[] = {
> + { .compatible = "mediatek,mt6577-uart-dma", },
where is the binding document for ediatek,mt6577-uart-dma ??
^ permalink raw reply
* [RESEND,v1] dmaengine: stm32-dma: check FIFO error interrupt enable
From: Vinod Koul @ 2019-01-04 15:47 UTC (permalink / raw)
To: Pierre-Yves MORDRET
Cc: Dan Williams, Maxime Coquelin, Alexandre Torgue, dmaengine,
linux-stm32, linux-arm-kernel, linux-kernel
On 03-01-19, 11:17, Pierre-Yves MORDRET wrote:
> For avoiding false FIFO detection, check FIFO Error interrupt is
> enabled prior raising any errors.
> This will prevent having spurious FIFO error where it shouldn't.
Applied, thanks
^ permalink raw reply
* [RFC,01/10] dma-engine: sun4i: Add a quirk to support different chips
From: Vinod Koul @ 2019-01-04 15:38 UTC (permalink / raw)
To: Mesih Kilinc
Cc: dmaengine, devicetree, linux-arm-kernel, linux-kernel, alsa-devel,
linux-sunxi, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai
On 03-12-18, 00:23, Mesih Kilinc wrote:
> Allwinner suniv F1C100s has similar DMA engine to sun4i. Several
> registers has different addresses. Total dma channels, endpoint counts
> and max burst counts are also different.
So if register layout is the only diff, have you thought about using
regmap_field so that you dont care about the layout
> +struct sun4i_dma_config {
> + u32 ndma_nr_max_channels;
> + u32 ndma_nr_max_vchans;
> +
> + u32 ddma_nr_max_channels;
> + u32 ddma_nr_max_vchans;
> +
> + u32 dma_nr_max_channels;
> +
> + void (*set_dst_data_width)(u32 *p_cfg, s8 data_width);
> + void (*set_src_data_width)(u32 *p_cfg, s8 data_width);
aligned please, checkpatch should warn about this stuff
> struct sun4i_dma_dev {
> - DECLARE_BITMAP(pchans_used, SUN4I_DMA_NR_MAX_CHANNELS);
> + unsigned long *pchans_used;
why not bitmap?
> +static struct sun4i_dma_config sun4i_a10_dma_cfg = {
> + .ndma_nr_max_channels = SUN4I_NDMA_NR_MAX_CHANNELS,
> + .ndma_nr_max_vchans = SUN4I_NDMA_NR_MAX_VCHANS,
> +
> + .ddma_nr_max_channels = SUN4I_DDMA_NR_MAX_CHANNELS,
> + .ddma_nr_max_vchans = SUN4I_DDMA_NR_MAX_VCHANS,
> +
> + .dma_nr_max_channels = SUN4I_NDMA_NR_MAX_CHANNELS +
> + SUN4I_DDMA_NR_MAX_CHANNELS,
> +
> + .set_dst_data_width = set_dst_data_width_a10,
> + .set_src_data_width = set_src_data_width_a10,
> + .convert_burst = convert_burst_a10,
> +
> + .ndma_drq_sdram = SUN4I_NDMA_DRQ_TYPE_SDRAM,
> + .ddma_drq_sdram = SUN4I_DDMA_DRQ_TYPE_SDRAM,
> +
> + .max_burst = SUN4I_MAX_BURST,
> +};
> +
> static const struct of_device_id sun4i_dma_match[] = {
> - { .compatible = "allwinner,sun4i-a10-dma" },
> + { .compatible = "allwinner,sun4i-a10-dma", .data = &sun4i_a10_dma_cfg },
I would prefer this to be split into two patches, first one does the
refactoring of driver (better if we split things logically) and then
addition of new one..
^ permalink raw reply
* [5/5] dma: tegra: add tracepoints to driver
From: Vinod Koul @ 2019-01-04 15:24 UTC (permalink / raw)
To: Ben Dooks
Cc: Jon Hunter, dan.j.williams, dmaengine, ldewangan, linux-tegra,
Ingo Molnar, Steven Rostedt
On 04-01-19, 15:10, Ben Dooks wrote:
>
>
> On 2019-01-04 15:06, Vinod Koul wrote:
> > On 22-11-18, 15:15, Ben Dooks wrote:
> > > On 22/11/2018 08:55, Jon Hunter wrote:
> >
> > > > My only comment here is that apart from the ISR trace, the others could
> > > > be added to the dmaengine driver core and then these could be used for
> > > > other DMAs as well.
> > >
> > > Hmm, I will go have a look at how difficult that would be.
> >
> > Shouldn't be :) All the drivers use generic dma_chan struct and we can
> > use that to trace, but I am going to merges this and you can send a
> > patch to move it to core :)
>
> Ok, so just to check that the whole series is going to be merged?
> I was just wondering if anything needs to be re-sent as I had not
> heard anything back on this series in a while.
Yeah sorry about unusual delay, travel, vacation, work life caused a bit
of issues for me. Things should be fine now...
I have merged the entire series and it will show up in next after merge
window closes...
^ permalink raw reply
* [v2,7/7] dmaengine: dw: convert to SPDX identifiers
From: Vinod Koul @ 2019-01-04 15:20 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Viresh Kumar, dmaengine
On 05-12-18, 18:28, Andy Shevchenko wrote:
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/dma/dw/Kconfig | 2 ++
> drivers/dma/dw/core.c | 5 +----
> drivers/dma/dw/internal.h | 5 +----
> drivers/dma/dw/pci.c | 5 +----
> drivers/dma/dw/platform.c | 5 +----
> drivers/dma/dw/regs.h | 5 +----
> include/linux/dma/dw.h | 5 +----
> include/linux/platform_data/dma-dw.h | 5 +----
> 8 files changed, 9 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/dma/dw/Kconfig b/drivers/dma/dw/Kconfig
> index 04b9728c1d26..e5162690de8f 100644
> --- a/drivers/dma/dw/Kconfig
> +++ b/drivers/dma/dw/Kconfig
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> #
> # DMA engine configuration for dw
> #
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index b7e4dab28f8a..3a1ab52ffae0 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -1,13 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Core driver for the Synopsys DesignWare DMA Controller
> *
> * Copyright (C) 2007-2008 Atmel Corporation
> * Copyright (C) 2010-2011 ST Microelectronics
> * Copyright (C) 2013 Intel Corporation
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> */
>
> #include <linux/bitops.h>
> diff --git a/drivers/dma/dw/internal.h b/drivers/dma/dw/internal.h
> index fdcac21ea665..4be4c9596260 100644
> --- a/drivers/dma/dw/internal.h
> +++ b/drivers/dma/dw/internal.h
> @@ -1,11 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
That is not correct, See Documentation/process/license-rules.rst
For headers it is:
C header: /* SPDX-License-Identifier: <SPDX License Expression> */
^ permalink raw reply
* [v1] dmaengine: imx-sdma: refine to load context only once
From: Vinod Koul @ 2019-01-04 15:14 UTC (permalink / raw)
To: Robin Gong
Cc: dan.j.williams@intel.com, kernel@pengutronix.de,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
dl-linux-imx
On 06-12-18, 06:36, Robin Gong wrote:
> The context loaded only one time before channel running,but
^^
space after comma please
> currently sdma_config_channel() and dma_prep_* duplicated with
> sdma_load_context(), so refine it to load context only one time
> before channel running and reload after the channel terminated.
I was going to apply it, but it fails to apply for me, please rebase and
send
^ permalink raw reply
* [5/5] dma: tegra: add tracepoints to driver
From: Ben Dooks @ 2019-01-04 15:10 UTC (permalink / raw)
To: Vinod Koul
Cc: Jon Hunter, dan.j.williams, dmaengine, ldewangan, linux-tegra,
Ingo Molnar, Steven Rostedt
On 2019-01-04 15:06, Vinod Koul wrote:
> On 22-11-18, 15:15, Ben Dooks wrote:
>> On 22/11/2018 08:55, Jon Hunter wrote:
>
>> > My only comment here is that apart from the ISR trace, the others could
>> > be added to the dmaengine driver core and then these could be used for
>> > other DMAs as well.
>>
>> Hmm, I will go have a look at how difficult that would be.
>
> Shouldn't be :) All the drivers use generic dma_chan struct and we can
> use that to trace, but I am going to merges this and you can send a
> patch to move it to core :)
Ok, so just to check that the whole series is going to be merged?
I was just wondering if anything needs to be re-sent as I had not
heard anything back on this series in a while.
^ permalink raw reply
* [5/5] dma: tegra: add tracepoints to driver
From: Vinod Koul @ 2019-01-04 15:06 UTC (permalink / raw)
To: Ben Dooks
Cc: Jon Hunter, dan.j.williams, dmaengine, ldewangan, linux-tegra,
Ingo Molnar, Steven Rostedt
On 22-11-18, 15:15, Ben Dooks wrote:
> On 22/11/2018 08:55, Jon Hunter wrote:
> > My only comment here is that apart from the ISR trace, the others could
> > be added to the dmaengine driver core and then these could be used for
> > other DMAs as well.
>
> Hmm, I will go have a look at how difficult that would be.
Shouldn't be :) All the drivers use generic dma_chan struct and we can
use that to trace, but I am going to merges this and you can send a
patch to move it to core :)
^ permalink raw reply
* [v6,1/7] dmaengine: xilinx_dma: commonize DMA copy size calculation
From: Vinod Koul @ 2019-01-04 14:59 UTC (permalink / raw)
To: Andrea Merello
Cc: dan.j.williams, michal.simek, appana.durga.rao, dmaengine,
linux-arm-kernel, linux-kernel, robh+dt, mark.rutland, devicetree,
radhey.shyam.pandey
On 20-11-18, 16:31, Andrea Merello wrote:
> This patch removes a bit of duplicated code by introducing a new
> function that implements calculations for DMA copy size, and
> prepares for changes to the copy size calculation that will
> happen in following patches.
Applied all, thanks
^ permalink raw reply
* dmaengine: fix dmaengine_desc_callback_valid() doesn't check for callback_result
From: Vinod Koul @ 2019-01-04 14:51 UTC (permalink / raw)
To: Andrea Merello
Cc: dan.j.williams, dmaengine, linux-kernel, radhey.shyam.pandey
On 16-11-18, 14:56, Andrea Merello wrote:
> There are two flavors of DMA completion callbacks: callback() and
> callback_result(); the latter takes an additional parameter that carries
> result information.
>
> Most dmaengine helper functions that work with callbacks take care of both
> flavors i.e. dmaengine_desc_get_callback_invoke() first checks for
> callback_result() to be not NULL, and eventually it calls this one;
> otherwise it goes on checking for callback().
>
> It seems however that dmaengine_desc_callback_valid() does not care about
> callback_result(), and it returns false in case callback() is NULL but
> callback_result() is not; unless there is a (hidden to me) reason for doing
> so then I'd say this is wrong.
>
> I've hit this by using a DMA controller driver (xilinx_dma) that doesn't
> trigger any callback invocation unless dmaengine_desc_callback_valid()
> returns true, while I had only callback_result() implemented in my client
> driver (which AFAICT is always fine since dmaengine documentation says that
> callback() will be deprecated).
>
> This patch fixes this by making dmaengine_desc_callback_valid() to return
> true in the said scenario.
>
> Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
> ---
> drivers/dma/dmaengine.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
> index 501c0b063f85..0ba2c1f3c55d 100644
> --- a/drivers/dma/dmaengine.h
> +++ b/drivers/dma/dmaengine.h
> @@ -168,7 +168,7 @@ dmaengine_desc_get_callback_invoke(struct dma_async_tx_descriptor *tx,
> static inline bool
> dmaengine_desc_callback_valid(struct dmaengine_desc_callback *cb)
> {
> - return (cb->callback) ? true : false;
> + return (cb->callback || cb->callback_result);
So I do not think this one should take care of callback_result, it is
supposed to check if the callback is valid or not.. Nothing more.
Ofcourse usage of this maybe incorrect which should be fixed. We do have
dmaengine_desc_callback_invoke() which propagates the callback_result to
user
^ permalink raw reply
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