[PATCH v4 2/2] DW DMAC: add multi-block property to device tree
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
---
Also:
Update DT documentation.
Update existing platform data.
Documentation/devicetree/bindings/dma/snps-dma.txt | 3 +++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 5 +
drivers/tty/serial/8250/8250_lpss.c| 2 +-
include/linux/platform_data/dma-dw.h | 4 ++--
5 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f55832..0c6256d 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -27,6 +27,9 @@ 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 per AHB master.
+ Array property with one cell per master. 0 (default): not supported,
+ 1: supported.
Example:
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..b262fd3 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -152,6 +152,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", arr, nr_masters)) {
+ for (tmp = 0; tmp < nr_masters; tmp++)
+ pdata->multi_block[tmp] = arr[tmp];
+ }
+
return pdata;
}
#else
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..0773bb4 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -40,19 +40,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 AHB master.
*/
struct dw_dma_platform_data {
unsigned intnr_channels;
boolis_private;
boolis_memcpy;
- boolis_nollp;
#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
unsigned char chan_allocation_order;
@@ -62,6 +61,7 @@ struct dw_dma_platform_data {
unsigned intblock_size;
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
+ unsigned char multi_block[DW_DMA_MAX_NR
[PATCH v4 1/2] DW DMAC: enable memory-to-memory transfers support
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 Signed-off-by: Eugeniy Paltsev --- 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 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v4 0/2] DW DMAC: update device tree
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 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 | 3 +++ drivers/dma/dw/core.c | 2 +- drivers/dma/dw/platform.c | 11 +++ drivers/tty/serial/8250/8250_lpss.c| 2 +- include/linux/platform_data/dma-dw.h | 4 ++-- 5 files changed, 18 insertions(+), 4 deletions(-) -- 2.5.5 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 3/6] arc: Use full path in KBUILD_IMAGE definition
Hi Michal, On Tue, 2016-11-22 at 22:34 +0100, Michal Marek wrote: > The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which > expect it to point to the image file in the build directory. The > builddeb script has a workaround for architectures which only provide > the basename, but let's provide a clean interface for packaging tools. > > Cc: Vineet Gupta > Cc: linux-snps-arc@lists.infradead.org > Signed-off-by: Michal Marek > --- > arch/arc/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arc/Makefile b/arch/arc/Makefile > index 19cce226d1a8..44ef35d33956 100644 > --- a/arch/arc/Makefile > +++ b/arch/arc/Makefile > @@ -123,9 +123,9 @@ libs-y+= arch/arc/lib/ $(LIBGCC) > boot := arch/arc/boot > > #default target for make without any arguments. > -KBUILD_IMAGE := bootpImage > +KBUILD_IMAGE := $(boot)/bootpImage > > -all: $(KBUILD_IMAGE) > +all: bootpImage > bootpImage: vmlinux > > boot_targets += uImage uImage.bin uImage.gz I tried to find any examples on how that KBUILD_IMAGE thingy is used but to no avail. It looks like for ARC "bootpImage" makes not much sense and if you really want to get something useful in .deb/.rpm most probably something like below may work much better: >8-- KBUILD_IMAGE:= $(boot)/uImage >8-- And I don't know context of KBUILD_IMAGE usage but in case of ARC our default target is "vmlinux" so I'm not sure then if KBUILD_IMAGE may point to non-default target. For example in "arch/avr32/Makefile" I see more complicated construction: >8-- KBUILD_IMAGE := $(boot)/uImage vmlinux.elf: KBUILD_IMAGE := $(boot)/vmlinux.elf vmlinux.cso: KBUILD_IMAGE := $(boot)/vmlinux.cso uImage.srec: KBUILD_IMAGE := $(boot)/uImage.srec uImage: KBUILD_IMAGE := $(boot)/uImage >8-- and may imagine that we need something similar for ARC obviously with default being "$(boot)/vmlinux". -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device Tree
On 11/22/2016 03:22 AM, Marc Zyngier wrote:
>> 2. The kernel will not call idu_irq_set_affinity() for IDU interrupt
>> > controller in some cases. It happens when the top interrupt
>> > controller does not support setting of the affinity and does not even
>> > support propagating of it (e.g. a GPIO interrupt controller on top of
>> > IDU which funnels all interrupts in one line). However
>> > idu_irq_set_affinity() must be called to unmask common interrupts in
>> > IDU. And if I want to make an affinity in irq_desc to match a real
>> > affinity I must call irq_set_affinity() instead of just
>> > idu_irq_set_affinity() .
>
> My brain has just melted. Can you describe this a bit more, possibly
> using some ASCII diagrams? I really don't understand what the affinity
> settings have to do with unmasking the interrupt... It is that you mask
> an interrupt by routing it to a dummy CPU?
The AXS SDP board has an "interesting" cascade of interrupt controllers.
Exact setup in arch/arc/boot/dts/{axc003_idu,axs10x_mb}.dtsi
/*
* Peripherals on CPU Card and Mother Board are wired to cpu intc via
* intermediate DW APB GPIO blocks (mainly for debouncing)
*
*
*| snps,archs-intc |
*
* | #24 |#25
*
*| snps,archs-intc |
*
* | #0 | #1
* --- ---
* | snps,dw-apb-gpio | | snps,dw-apb-gpio |
* | (pass thru)| | |
* --- ---
*| #12 |
*| [ Debug UART on cpu card ]
*|
*
* | snps,dw-apb-intc (MB)|
*
* | | | |
* [eth] [uart][... other perip on Main Board]
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
