It wasn't possible to enable some features like
memory-to-memory transfers or multi block transfers via DT.
It is fixed by these patches.
Changes for v5:
* Update existing DTS. Pointed by Andy Shevchenko.
* Read multi-block per chanel instead of per master (Move
DW_DMA_MAX_NR_CHANNELS define from regs.h to dma-dw.h to
implement this) Pointed by Andy Shevchenko.
Changes for v4:
* Fix setting inverted value to "dwc->nollp". My fault - I
tested with wrong DTS, so DMAC was configured from autoconfig
instead of device tree. Pointed by Andy Shevchenko.
* Update "multi-block" diescription in documentation to be more
clear. Pointed by Arnd Bergmann.
Changes for v3:
* Update existing platform data.
We don't need to update existing DTS because default logic
wasn't change: we don't set "is_nollp" if we read
configuration from DT before. And we don't set it now if
"multi-block" property doesn't exist in DTS.
Changes for v2:
* I thought about is_memcpy DT property: all known devices, which
use DT for configuration, support memory-to-memory transfers.
So we don't need to read it from DT. So enable it by default,
if we read configuration from DT.
* Use "multi-block" instead of "hw-llp" name to be more clear.
* Move adding DT property and adding documentation for this
property to one patch.
Eugeniy Paltsev (2):
DW DMAC: enable memory-to-memory transfers support
DW DMAC: add multi-block property to device tree
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
arch/arc/boot/dts/abilis_tb10x.dtsi | 1 +
arch/arm/boot/dts/spear13xx.dtsi | 2 ++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 15 ++++++++++++++-
drivers/dma/dw/regs.h | 3 ++-
drivers/tty/serial/8250/8250_lpss.c | 2 +-
include/linux/platform_data/dma-dw.h | 5 +++--
8 files changed, 26 insertions(+), 6 deletions(-)
--
2.5.5
All known devices, which use DT for configuration, support
memory-to-memory transfers. So enable it by default, if we read
configuration from DT.
Acked-by: Andy Shevchenko <[email protected]>
Signed-off-by: Eugeniy Paltsev <[email protected]>
---
drivers/dma/dw/platform.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..aa7a5c1 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_bool(np, "is_private"))
pdata->is_private = true;
+ /*
+ * All known devices, which use DT for configuration, support
+ * memory-to-memory transfers. So enable it by default.
+ */
+ pdata->is_memcpy = true;
+
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
--
2.5.5
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.
Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.
Signed-off-by: Eugeniy Paltsev <[email protected]>
---
Also:
Update DT documentation.
Update existing platform data and DTS.
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
arch/arc/boot/dts/abilis_tb10x.dtsi | 1 +
arch/arm/boot/dts/spear13xx.dtsi | 2 ++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 9 ++++++++-
drivers/dma/dw/regs.h | 3 ++-
drivers/tty/serial/8250/8250_lpss.c | 2 +-
include/linux/platform_data/dma-dw.h | 5 +++--
8 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f55832..aeb90d1 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -27,6 +27,8 @@ Optional properties:
that services interrupts for this device
- is_private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
+- multi-block: Multi block transfers supported by hardware. Array property with
+ one cell per channel. 0 (default): not supported, 1: supported.
Example:
diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi b/arch/arc/boot/dts/abilis_tb10x.dtsi
index de53f5c..3121536 100644
--- a/arch/arc/boot/dts/abilis_tb10x.dtsi
+++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
@@ -129,6 +129,7 @@
data-width = <4>;
clocks = <&ahb_clk>;
clock-names = "hclk";
+ multi-block = <1 1 1 1 1 1>;
};
i2c0: i2c@FF120000 {
diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
index 449acf0..17ea0ab 100644
--- a/arch/arm/boot/dts/spear13xx.dtsi
+++ b/arch/arm/boot/dts/spear13xx.dtsi
@@ -118,6 +118,7 @@
block_size = <0xfff>;
dma-masters = <2>;
data-width = <8 8>;
+ multi-block = <1 1 1 1 1 1 1 1>;
};
dma@eb000000 {
@@ -134,6 +135,7 @@
chan_priority = <1>;
block_size = <0xfff>;
data-width = <8 8>;
+ multi-block = <1 1 1 1 1 1 1 1>;
};
fsmc: flash@b0000000 {
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index c2c0a61..e5adf5d 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
} else {
dwc->block_size = pdata->block_size;
- dwc->nollp = pdata->is_nollp;
+ dwc->nollp = !pdata->multi_block[i];
}
}
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index aa7a5c1..80e161f 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -102,7 +102,7 @@ dw_dma_parse_dt(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct dw_dma_platform_data *pdata;
- u32 tmp, arr[DW_DMA_MAX_NR_MASTERS];
+ u32 tmp, arr[DW_DMA_MAX_NR_MASTERS], chan[DW_DMA_MAX_NR_CHANNELS];
u32 nr_masters;
u32 nr_channels;
@@ -118,6 +118,8 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_u32(np, "dma-channels", &nr_channels))
return NULL;
+ if (nr_channels > DW_DMA_MAX_NR_CHANNELS)
+ return NULL;
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -152,6 +154,11 @@ dw_dma_parse_dt(struct platform_device *pdev)
pdata->data_width[tmp] = BIT(arr[tmp] & 0x07);
}
+ if (!of_property_read_u32_array(np, "multi-block", chan, nr_channels)) {
+ for (tmp = 0; tmp < nr_channels; tmp++)
+ pdata->multi_block[tmp] = chan[tmp];
+ }
+
return pdata;
}
#else
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index f65dd10..4e0128c 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -12,7 +12,8 @@
#include <linux/interrupt.h>
#include <linux/dmaengine.h>
-#define DW_DMA_MAX_NR_CHANNELS 8
+#include "internal.h"
+
#define DW_DMA_MAX_NR_REQUESTS 16
/* flow controller */
diff --git a/drivers/tty/serial/8250/8250_lpss.c b/drivers/tty/serial/8250/8250_lpss.c
index f607946..58cbb30 100644
--- a/drivers/tty/serial/8250/8250_lpss.c
+++ b/drivers/tty/serial/8250/8250_lpss.c
@@ -157,12 +157,12 @@ static int byt_serial_setup(struct lpss8250 *lpss, struct uart_port *port)
static const struct dw_dma_platform_data qrk_serial_dma_pdata = {
.nr_channels = 2,
.is_private = true,
- .is_nollp = true,
.chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
.chan_priority = CHAN_PRIORITY_ASCENDING,
.block_size = 4095,
.nr_masters = 1,
.data_width = {4},
+ .multi_block = {0},
};
static void qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port *port)
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 5f0e11e..e69e415 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -14,6 +14,7 @@
#include <linux/device.h>
#define DW_DMA_MAX_NR_MASTERS 4
+#define DW_DMA_MAX_NR_CHANNELS 8
/**
* struct dw_dma_slave - Controller-specific information about a slave
@@ -40,19 +41,18 @@ struct dw_dma_slave {
* @is_private: The device channels should be marked as private and not for
* by the general purpose DMA channel allocator.
* @is_memcpy: The device channels do support memory-to-memory transfers.
- * @is_nollp: The device channels does not support multi block transfers.
* @chan_allocation_order: Allocate channels starting from 0 or 7
* @chan_priority: Set channel priority increasing from 0 to 7 or 7 to 0.
* @block_size: Maximum block size supported by the controller
* @nr_masters: Number of AHB masters supported by the controller
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
+ * @multi_block: Multi block transfers supported by hardware per channel.
*/
struct dw_dma_platform_data {
unsigned int nr_channels;
bool is_private;
bool is_memcpy;
- bool is_nollp;
#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
unsigned char chan_allocation_order;
@@ -62,6 +62,7 @@ struct dw_dma_platform_data {
unsigned int block_size;
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
+ unsigned char multi_block[DW_DMA_MAX_NR_CHANNELS];
};
#endif /* _PLATFORM_DATA_DMA_DW_H */
--
2.5.5
On Thu, 2016-11-24 at 18:04 +0300, Eugeniy Paltsev wrote:
> Several versions of DW DMAC have multi block transfers hardware
> support. Hardware support of multi block transfers is disabled
> by default if we use DT to configure DMAC and software emulation
> of multi block transfers used instead.
> Add multi-block property, so it is possible to enable hardware
> multi block transfers (if present) via DT.
>
> Switch from per device is_nollp variable to multi_block array
> to be able enable/disable multi block transfers separately per
> channel.
Thanks for an update. Basically I'm fine with this one.
So, we still have question about autoconfiguration in SPEAr SoCs, and
your ARC SoC but it's a different story. I would expect once you will
clarify it.
Another one is minor listed below, otherwise
Acked-by: Andy Shevchenko <[email protected]>
> Signed-off-by: Eugeniy Paltsev <[email protected]>
> --- a/drivers/dma/dw/platform.c
> +++ b/drivers/dma/dw/platform.c
> @@ -102,7 +102,7 @@ dw_dma_parse_dt(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct dw_dma_platform_data *pdata;
> - u32 tmp, arr[DW_DMA_MAX_NR_MASTERS];
> + u32 tmp, arr[DW_DMA_MAX_NR_MASTERS],
> chan[DW_DMA_MAX_NR_CHANNELS];
chan here will confuse people...
> @@ -152,6 +154,11 @@ dw_dma_parse_dt(struct platform_device *pdev)
> pdata->data_width[tmp] = BIT(arr[tmp] &
> 0x07);
> }
>
> + if (!of_property_read_u32_array(np, "multi-block", chan,
> nr_channels)) {
> + for (tmp = 0; tmp < nr_channels; tmp++)
> + pdata->multi_block[tmp] = chan[tmp];
...mb (as short of multi-block) would suit better.
--
Andy Shevchenko <[email protected]>
Intel Finland Oy
On Thu, 2016-11-24 at 17:52 +0200, Andy Shevchenko wrote:
> On Thu, 2016-11-24 at 18:04 +0300, Eugeniy Paltsev wrote:
> > Several versions of DW DMAC have multi block transfers hardware
> > support. Hardware support of multi block transfers is disabled
> > by default if we use DT to configure DMAC and software emulation
> > of multi block transfers used instead.
> > Add multi-block property, so it is possible to enable hardware
> > multi block transfers (if present) via DT.
> >
> > Switch from per device is_nollp variable to multi_block array
> > to be able enable/disable multi block transfers separately per
> > channel.
>
> Thanks for an update. Basically I'm fine with this one.
>
> So, we still have question about autoconfiguration in SPEAr SoCs, and
> your ARC SoC but it's a different story. I would expect once you will
> clarify it.
>
> Another one is minor listed below, otherwise
>
> Acked-by: Andy Shevchenko <[email protected]>
> > @@ -152,6 +154,11 @@ dw_dma_parse_dt(struct platform_device *pdev)
> > pdata->data_width[tmp] = BIT(arr[tmp] &
> > 0x07);
> > }
> >
> > + if (!of_property_read_u32_array(np, "multi-block", chan,
> > nr_channels)) {
> > + for (tmp = 0; tmp < nr_channels; tmp++)
> > + pdata->multi_block[tmp] = chan[tmp];
>
> ...mb (as short of multi-block) would suit better.
Oh, sorry, guys, but one more important thing. If there is no such
property, keep a default to "supported". Otherwise you will break old
(working) DTBs.
--
Andy Shevchenko <[email protected]>
Intel Finland Oy
On Thu, 2016-11-24 at 17:58 +0200, Andy Shevchenko wrote:
> On Thu, 2016-11-24 at 17:52 +0200, Andy Shevchenko wrote:
> >
> > On Thu, 2016-11-24 at 18:04 +0300, Eugeniy Paltsev wrote:
> > >
> > > Several versions of DW DMAC have multi block transfers hardware
> > > support. Hardware support of multi block transfers is disabled
> > > by default if we use DT to configure DMAC and software emulation
> > > of multi block transfers used instead.
> > > Add multi-block property, so it is possible to enable hardware
> > > multi block transfers (if present) via DT.
> > >
> > > Switch from per device is_nollp variable to multi_block array
> > > to be able enable/disable multi block transfers separately per
> > > channel.
> > Thanks for an update. Basically I'm fine with this one.
> >
> > So, we still have question about autoconfiguration in SPEAr SoCs,
> > and
> > your ARC SoC but it's a different story. I would expect once you
> > will
> > clarify it.
> >
> > Another one is minor listed below, otherwise
> >
> > Acked-by: Andy Shevchenko <[email protected]>
> >
> > >
> > > @@ -152,6 +154,11 @@ dw_dma_parse_dt(struct platform_device
> > > *pdev)
> > > pdata->data_width[tmp] = BIT(arr[tmp] &
> > > 0x07);
> > > }
> > >
> > > + if (!of_property_read_u32_array(np, "multi-block", chan,
> > > nr_channels)) {
> > > + for (tmp = 0; tmp < nr_channels; tmp++)
> > > + pdata->multi_block[tmp] = chan[tmp];
> > ...mb (as short of multi-block) would suit better.
> Oh, sorry, guys, but one more important thing. If there is no such
> property, keep a default to "supported". Otherwise you will break old
> (working) DTBs.
Should I remove explicit declaration "multi-block" property from
existing DTS (which I added during v5 patch iteration)?
I mean that:
---------------------->8-----------------------
+ multi-block = <1 1 1 1 1 1 1 1>;
---------------------->8-----------------------
We don't actually need it, if we use use 1 ("supported") as "multi-
block" property default value.
--
Paltsev Eugeniy
On Fri, 2016-11-25 at 11:40 +0000, Eugeniy Paltsev wrote:
> On Thu, 2016-11-24 at 17:58 +0200, Andy Shevchenko wrote:
> > On Thu, 2016-11-24 at 17:52 +0200, Andy Shevchenko wrote:
> > >
> > > On Thu, 2016-11-24 at 18:04 +0300, Eugeniy Paltsev wrote:
> > > >
> > > > Several versions of DW DMAC have multi block transfers hardware
> > > > support. Hardware support of multi block transfers is disabled
> > > > by default if we use DT to configure DMAC and software emulation
> > > > of multi block transfers used instead.
> > > > Add multi-block property, so it is possible to enable hardware
> > > > multi block transfers (if present) via DT.
> > > >
> > > > Switch from per device is_nollp variable to multi_block array
> > > > to be able enable/disable multi block transfers separately per
> > > > channel.
> > >
> > > Thanks for an update. Basically I'm fine with this one.
> > >
> > > So, we still have question about autoconfiguration in SPEAr SoCs,
> > > and
> > > your ARC SoC but it's a different story. I would expect once you
> > > will
> > > clarify it.
> > >
> > > Another one is minor listed below, otherwise
> > >
> > > Acked-by: Andy Shevchenko <[email protected]>
> > >
> > > >
> > > > @@ -152,6 +154,11 @@ dw_dma_parse_dt(struct platform_device
> > > > *pdev)
> > > > pdata->data_width[tmp] = BIT(arr[tmp] &
> > > > 0x07);
> > > > }
> > > >
> > > > + if (!of_property_read_u32_array(np, "multi-block",
> > > > chan,
> > > > nr_channels)) {
> > > > + for (tmp = 0; tmp < nr_channels; tmp++)
> > > > + pdata->multi_block[tmp] = chan[tmp];
> > >
> > > ...mb (as short of multi-block) would suit better.
> >
> > Oh, sorry, guys, but one more important thing. If there is no such
> > property, keep a default to "supported". Otherwise you will break
> > old
> > (working) DTBs.
>
> Should I remove explicit declaration "multi-block" property from
> existing DTS (which I added during v5 patch iteration)?
>
> I mean that:
> ---------------------->8-----------------------
> + multi-block = <1 1 1 1 1 1 1 1>;
> ---------------------->8-----------------------
>
> We don't actually need it, if we use use 1 ("supported") as "multi-
> block" property default value.
My understanding is better to leave to show that the new option has been
introduced.
It would be possible to do when you confirm that your ARC platform along
with SPEAr supports auto configuration including this property.
--
Andy Shevchenko <[email protected]>
Intel Finland Oy