[PATCH] ARC: Add PCIe support for ARC HSDK platform
Add PCI support to the ARC HSDK platform allowing to use the generic PCI
setup functions.
Add GPIO interrupt configuration function on ARC HSDK platform and
configures it to PCI support.
Signed-off-by: Gustavo Pimentel
---
arch/arc/plat-hsdk/Kconfig| 1 +
arch/arc/plat-hsdk/platform.c | 41 +
2 files changed, 42 insertions(+)
diff --git a/arch/arc/plat-hsdk/Kconfig b/arch/arc/plat-hsdk/Kconfig
index 19ab3cf..556bc5e 100644
--- a/arch/arc/plat-hsdk/Kconfig
+++ b/arch/arc/plat-hsdk/Kconfig
@@ -9,3 +9,4 @@ menuconfig ARC_SOC_HSDK
bool "ARC HS Development Kit SOC"
select CLK_HSDK
select RESET_HSDK
+ select MIGHT_HAVE_PCI
diff --git a/arch/arc/plat-hsdk/platform.c b/arch/arc/plat-hsdk/platform.c
index 2958aed..31adda7 100644
--- a/arch/arc/plat-hsdk/platform.c
+++ b/arch/arc/plat-hsdk/platform.c
@@ -42,6 +42,45 @@ static void __init hsdk_init_per_cpu(unsigned int cpu)
#define SDIO_UHS_REG_EXT (SDIO_BASE + 0x108)
#define SDIO_UHS_REG_EXT_DIV_2 (2 << 30)
+#define HSDK_GPIO_INTC (ARC_PERIPHERAL_BASE + 0x3000)
+#define GPIO_INTEN (HSDK_GPIO_INTC + 0x30)
+#define GPIO_INTMASK(HSDK_GPIO_INTC + 0x34)
+#define GPIO_INTTYPE_LEVEL (HSDK_GPIO_INTC + 0x38)
+#define GPIO_INT_POLARITY (HSDK_GPIO_INTC + 0x3c)
+
+#define GPIO_BLUETOOTH_INT 0x0001
+#define GPIO_HAPS_INT 0x0004
+#define GPIO_AUDIO_INT 0x0008
+/* PMOD_A header */
+#define GPIO_PIN_08_INT0x0100
+#define GPIO_PIN_09_INT0x0200
+#define GPIO_PIN_10_INT0x0400
+#define GPIO_PIN_11_INT0x0800
+/* PMOD_B header */
+#define GPIO_PIN_12_INT0x1000
+#define GPIO_PIN_13_INT0x2000
+#define GPIO_PIN_14_INT0x4000
+#define GPIO_PIN_15_INT0x8000
+/* PMOD_C header */
+#define GPIO_PIN_16_INT0x0001
+#define GPIO_PIN_17_INT0x0002
+#define GPIO_PIN_18_INT0x0004
+#define GPIO_PIN_19_INT0x0008
+#define GPIO_PIN_20_INT0x0010
+#define GPIO_PIN_21_INT0x0020
+#define GPIO_PIN_22_INT0x0040
+#define GPIO_PIN_23_INT0x0080
+static void __init hsdk_enable_gpio_intc_wire(void)
+{
+ u32 val = GPIO_HAPS_INT;
+
+ iowrite32(0x, (void __iomem *) GPIO_INTMASK);
+ iowrite32(~val, (void __iomem *) GPIO_INTMASK);
+ iowrite32(0x, (void __iomem *) GPIO_INTTYPE_LEVEL);
+ iowrite32(0x, (void __iomem *) GPIO_INT_POLARITY);
+ iowrite32(val, (void __iomem *) GPIO_INTEN);
+}
+
static void __init hsdk_init_early(void)
{
/*
@@ -62,6 +101,8 @@ static void __init hsdk_init_early(void)
* minimum possible div-by-2.
*/
iowrite32(SDIO_UHS_REG_EXT_DIV_2, (void __iomem *) SDIO_UHS_REG_EXT);
+
+ sdk_enable_gpio_intc_wire();
}
static const char *hsdk_compat[] __initconst = {
--
2.7.4
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Add PCIe support for ARC HSDK platform
Hi Gustavo,
On Mon, 2018-06-18 at 15:59 +0100, Gustavo Pimentel wrote:
> Add PCI support to the ARC HSDK platform allowing to use the generic PCI
> setup functions.
This is the first logically independent change, so put it in a separate patch.
> Add GPIO interrupt configuration function on ARC HSDK platform and
> configures it to PCI support.
That's the second change which is not directly tied to the first one
so please put it in a separate patch.
Than as compared to the first [very simple and obvious] change this
one warrants more verbose justification.
1. IMHO it worth adding more info to commit message explaining what problem
you're solving and why you do it in this particular way.
In case of HSDK we have intermediate INTC in for of DW APB GPIO controller
which is used as a de-bounce logic for interrupt wires that come from
outside the board.
We cannot use existing "irq-dw-apb-ictl" driver here because all input lines
are routed to corresponding output lines but not muxed into one line (this is
configured in RTL and we cannot change this in software). But even if we add
such
a feature to "irq-dw-apb-ictl" driver that won't benefit us as higher-level
INTC
(in case of HSDK it is IDU) anyways has per-input control so adding
fully-controller
intermediate INTC will only bring some overhead on interrupt processing but
no other
benefits.
Thus we just do one-time configuration of DW APP GPIO controller and forget
about it.
> Signed-off-by: Gustavo Pimentel
> ---
> arch/arc/plat-hsdk/Kconfig| 1 +
> arch/arc/plat-hsdk/platform.c | 41 +
> 2 files changed, 42 insertions(+)
>
> diff --git a/arch/arc/plat-hsdk/Kconfig b/arch/arc/plat-hsdk/Kconfig
> index 19ab3cf..556bc5e 100644
> --- a/arch/arc/plat-hsdk/Kconfig
> +++ b/arch/arc/plat-hsdk/Kconfig
> @@ -9,3 +9,4 @@ menuconfig ARC_SOC_HSDK
> bool "ARC HS Development Kit SOC"
> select CLK_HSDK
> select RESET_HSDK
> + select MIGHT_HAVE_PCI
> diff --git a/arch/arc/plat-hsdk/platform.c b/arch/arc/plat-hsdk/platform.c
> index 2958aed..31adda7 100644
> --- a/arch/arc/plat-hsdk/platform.c
> +++ b/arch/arc/plat-hsdk/platform.c
> @@ -42,6 +42,45 @@ static void __init hsdk_init_per_cpu(unsigned int cpu)
> #define SDIO_UHS_REG_EXT (SDIO_BASE + 0x108)
> #define SDIO_UHS_REG_EXT_DIV_2 (2 << 30)
>
> +#define HSDK_GPIO_INTC (ARC_PERIPHERAL_BASE + 0x3000)
> +#define GPIO_INTEN (HSDK_GPIO_INTC + 0x30)
> +#define GPIO_INTMASK(HSDK_GPIO_INTC + 0x34)
> +#define GPIO_INTTYPE_LEVEL (HSDK_GPIO_INTC + 0x38)
> +#define GPIO_INT_POLARITY (HSDK_GPIO_INTC + 0x3c)
> +
> +#define GPIO_BLUETOOTH_INT 0x0001
> +#define GPIO_HAPS_INT0x0004
> +#define GPIO_AUDIO_INT 0x0008
> +/* PMOD_A header */
> +#define GPIO_PIN_08_INT 0x0100
> +#define GPIO_PIN_09_INT 0x0200
> +#define GPIO_PIN_10_INT 0x0400
> +#define GPIO_PIN_11_INT 0x0800
> +/* PMOD_B header */
> +#define GPIO_PIN_12_INT 0x1000
> +#define GPIO_PIN_13_INT 0x2000
> +#define GPIO_PIN_14_INT 0x4000
> +#define GPIO_PIN_15_INT 0x8000
> +/* PMOD_C header */
> +#define GPIO_PIN_16_INT 0x0001
> +#define GPIO_PIN_17_INT 0x0002
> +#define GPIO_PIN_18_INT 0x0004
> +#define GPIO_PIN_19_INT 0x0008
> +#define GPIO_PIN_20_INT 0x0010
> +#define GPIO_PIN_21_INT 0x0020
> +#define GPIO_PIN_22_INT 0x0040
> +#define GPIO_PIN_23_INT 0x0080
Could you please run your patch through checkpatch.pl?
Here I guss newline is missing.
Also why adding those many defines if they are not really used
anywhere?
Instead maybe just add more informative pseudo-graphics as we
have in axs10x platform? See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/plat-axs10x/axs10x.c
> +static void __init hsdk_enable_gpio_intc_wire(void)
> +{
> + u32 val = GPIO_HAPS_INT;
> +
> + iowrite32(0x, (void __iomem *) GPIO_INTMASK);
> + iowrite32(~val, (void __iomem *) GPIO_INTMASK);
> + iowrite32(0x, (void __iomem *) GPIO_INTTYPE_LEVEL);
> + iowrite32(0x, (void __iomem *) GPIO_INT_POLARITY);
> + iowrite32(val, (void __iomem *) GPIO_INTEN);
> +}
I would suggest to have a map of really used lines and enable all of them
instead of adding one-by-one occasionally.
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Add PCIe support for ARC HSDK platform
On 06/18/2018 08:20 AM, Alexey Brodkin wrote:
>> +static void __init hsdk_enable_gpio_intc_wire(void)
>> +{
>> +u32 val = GPIO_HAPS_INT;
>> +
>> +iowrite32(0x, (void __iomem *) GPIO_INTMASK);
>> +iowrite32(~val, (void __iomem *) GPIO_INTMASK);
>> +iowrite32(0x, (void __iomem *) GPIO_INTTYPE_LEVEL);
>> +iowrite32(0x, (void __iomem *) GPIO_INT_POLARITY);
>> +iowrite32(val, (void __iomem *) GPIO_INTEN);
>> +}
> I would suggest to have a map of really used lines and enable all of them
> instead of adding one-by-one occasionally.
More importantly, adding any code in this file is an absolute abomination and
only
desired if this is a platform specific hack which can't be added in the generic
driver and/or specified via the Device Tree. Here it seems like we are enabling
some gpio lines which likely could be done via the gpio driver paths ?
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: dts: Remove leading 0x from node unit addresses
Remove leading 0x from all node unit addresses with a sed command:
sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g"
arch/arc/boot/dts/*.dts*
This fixes DTC warnings like:
Warning (unit_address_format): /cpu_card/dw-apb-gpio@0x2000: unit name
should not have leading "0x"
Reported-by: Joe Perches
Signed-off-by: Krzysztof Kozlowski
---
arch/arc/boot/dts/abilis_tb10x.dtsi | 4 ++--
arch/arc/boot/dts/axc001.dtsi | 6 +++---
arch/arc/boot/dts/axc003.dtsi | 6 +++---
arch/arc/boot/dts/axc003_idu.dtsi | 6 +++---
arch/arc/boot/dts/axs10x_mb.dtsi | 22 +++---
arch/arc/boot/dts/vdk_axc003.dtsi | 4 ++--
arch/arc/boot/dts/vdk_axc003_idu.dtsi | 4 ++--
arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 14 +++---
8 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi
b/arch/arc/boot/dts/abilis_tb10x.dtsi
index 3121536b25a3..593cdd96535d 100644
--- a/arch/arc/boot/dts/abilis_tb10x.dtsi
+++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
@@ -178,7 +178,7 @@
clocks = <&ahb_clk>;
};
- spi0: spi@0xFE01 {
+ spi0: spi@fe01 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
@@ -189,7 +189,7 @@
interrupts = <26 8>;
clocks = <&ahb_clk>;
};
- spi1: spi@0xFE011000 {
+ spi1: spi@fe011000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <1>;
diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
index fdc266504ada..37be3bf03ad6 100644
--- a/arch/arc/boot/dts/axc001.dtsi
+++ b/arch/arc/boot/dts/axc001.dtsi
@@ -41,7 +41,7 @@
* this GPIO block ORs all interrupts on CPU card (creg,..)
* to uplink only 1 IRQ to ARC core intc
*/
- dw-apb-gpio@0x2000 {
+ dw-apb-gpio@2000 {
compatible = "snps,dw-apb-gpio";
reg = < 0x2000 0x80 >;
#address-cells = <1>;
@@ -60,7 +60,7 @@
};
};
- debug_uart: dw-apb-uart@0x5000 {
+ debug_uart: dw-apb-uart@5000 {
compatible = "snps,dw-apb-uart";
reg = <0x5000 0x100>;
clock-frequency = <3000>;
@@ -88,7 +88,7 @@
* avoid duplicating the MB dtsi file given that IRQ from
* this intc to cpu intc are different for axs101 and axs103
*/
- mb_intc: dw-apb-ictl@0xe0012000 {
+ mb_intc: dw-apb-ictl@e0012000 {
#interrupt-cells = <1>;
compatible = "snps,dw-apb-ictl";
reg = < 0x0 0xe0012000 0x0 0x200 >;
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index dc91c663bcc0..817e2f5ee834 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -55,7 +55,7 @@
* this GPIO block ORs all interrupts on CPU card (creg,..)
* to uplink only 1 IRQ to ARC core intc
*/
- dw-apb-gpio@0x2000 {
+ dw-apb-gpio@2000 {
compatible = "snps,dw-apb-gpio";
reg = < 0x2000 0x80 >;
#address-cells = <1>;
@@ -74,7 +74,7 @@
};
};
- debug_uart: dw-apb-uart@0x5000 {
+ debug_uart: dw-apb-uart@5000 {
compatible = "snps,dw-apb-uart";
reg = <0x5000 0x100>;
clock-frequency = <3000>;
@@ -106,7 +106,7 @@
* avoid duplicating the MB dtsi file given that IRQ from
* this intc to cpu intc are different for axs101 and axs103
*/
- mb_intc: dw-apb-ictl@0xe0012000 {
+ mb_intc: dw-apb-ictl@e0012000 {
#interrupt-cells = <1>;
compatible = "snps,dw-apb-ictl";
reg = < 0x0 0xe0012000 0x0 0x200 >;
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi
b/arch/arc/boot/dts/axc003_idu.dtsi
index 69ff4895f2ba..5d912f9957fe 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -62,7 +62,7 @@
* this GPIO block ORs all interrupts on CPU card (creg,..)
* to uplink only 1 IRQ to ARC core intc
*/
- dw-apb-gpio@0x2000 {
+ dw-apb-gpio@2000 {
compatible = "snps,dw-apb-gpio";
reg = < 0x2000 0x80 >;
#address-cells = <1>;
@@ -81,7 +81,7 @@
};
};
- debug_uart: dw-apb-uart@0x5000 {
+ debug_uart: dw-apb-u
RE: [PATCH] ARC: Add PCIe support for ARC HSDK platform
Hi Vineet,
> -Original Message-
> From: Vineet Gupta
> Sent: Monday, June 18, 2018 9:11 PM
> To: Alexey Brodkin ; gustavo.pimen...@synopsys.com
> Cc: r...@kernel.org; linux-ker...@vger.kernel.org;
> eugeniy.palt...@synopsys.com; sb...@codeaurora.org; linux-snps-
> a...@lists.infradead.org
> Subject: Re: [PATCH] ARC: Add PCIe support for ARC HSDK platform
>
> On 06/18/2018 08:20 AM, Alexey Brodkin wrote:
> >> +static void __init hsdk_enable_gpio_intc_wire(void)
> >> +{
> >> + u32 val = GPIO_HAPS_INT;
> >> +
> >> + iowrite32(0x, (void __iomem *) GPIO_INTMASK);
> >> + iowrite32(~val, (void __iomem *) GPIO_INTMASK);
> >> + iowrite32(0x, (void __iomem *) GPIO_INTTYPE_LEVEL);
> >> + iowrite32(0x, (void __iomem *) GPIO_INT_POLARITY);
> >> + iowrite32(val, (void __iomem *) GPIO_INTEN);
> >> +}
> > I would suggest to have a map of really used lines and enable all of them
> > instead of adding one-by-one occasionally.
>
> More importantly, adding any code in this file is an absolute abomination and
> only
> desired if this is a platform specific hack which can't be added in the
> generic
> driver and/or specified via the Device Tree. Here it seems like we are
> enabling
> some gpio lines which likely could be done via the gpio driver paths ?
See my comment much higher - what we're doing here is pretty much the same as
With AXS10x - we implement wires which connect input interrupt lines to IDU.
Thus I'm not sure if it worth messing with DW APB GPIO INTC driver which as I
mentioned
As well won't work as it is and we'll need to patch it to support multiple
outputs mode.
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: dts: Remove leading 0x from node unit addresses
On Mon, 2018-06-18 at 21:16 +0200, Krzysztof Kozlowski wrote:
> Remove leading 0x from all node unit addresses with a sed command:
>
> sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g"
> arch/arc/boot/dts/*.dts*
>
> This fixes DTC warnings like:
>
> Warning (unit_address_format): /cpu_card/dw-apb-gpio@0x2000: unit name
> should not have leading "0x"
Do all of these need fixing?
Aren't there dozens of these in arch/arm and elsewhere too?
$ git grep -i -P "@0x([0-9a-f]+)\s*\{" -- "*.dt*"|cat
arch/arc/boot/dts/abilis_tb10x.dtsi:spi0: spi@0xFE01 {
arch/arc/boot/dts/abilis_tb10x.dtsi:spi1: spi@0xFE011000 {
arch/arc/boot/dts/axc001.dtsi: dw-apb-gpio@0x2000 {
arch/arc/boot/dts/axc001.dtsi: debug_uart: dw-apb-uart@0x5000 {
arch/arc/boot/dts/axc001.dtsi: mb_intc: dw-apb-ictl@0xe0012000 {
arch/arc/boot/dts/axc003.dtsi: dw-apb-gpio@0x2000 {
arch/arc/boot/dts/axc003.dtsi: debug_uart: dw-apb-uart@0x5000 {
arch/arc/boot/dts/axc003.dtsi: mb_intc: dw-apb-ictl@0xe0012000 {
arch/arc/boot/dts/axc003_idu.dtsi: dw-apb-gpio@0x2000 {
arch/arc/boot/dts/axc003_idu.dtsi: debug_uart: dw-apb-uart@0x5000 {
arch/arc/boot/dts/axc003_idu.dtsi: mb_intc: dw-apb-ictl@0xe0012000 {
arch/arc/boot/dts/axs10x_mb.dtsi: ethernet@0x18000 {
arch/arc/boot/dts/axs10x_mb.dtsi: ehci@0x4 {
arch/arc/boot/dts/axs10x_mb.dtsi: ohci@0x6 {
arch/arc/boot/dts/axs10x_mb.dtsi: mmc@0x15000 {
arch/arc/boot/dts/axs10x_mb.dtsi: uart@0x2 {
arch/arc/boot/dts/axs10x_mb.dtsi: uart@0x21000 {
arch/arc/boot/dts/axs10x_mb.dtsi: uart@0x22000 {
arch/arc/boot/dts/axs10x_mb.dtsi: i2c@0x1d000 {
arch/arc/boot/dts/axs10x_mb.dtsi: i2c@0x1f000 {
arch/arc/boot/dts/axs10x_mb.dtsi: eeprom@0x54{
arch/arc/boot/dts/axs10x_mb.dtsi: eeprom@0x57{
arch/arc/boot/dts/vdk_axc003.dtsi: debug_uart: dw-apb-uart@0x5000 {
arch/arc/boot/dts/vdk_axc003.dtsi: mb_intc: dw-apb-ictl@0xe0012000 {
arch/arc/boot/dts/vdk_axc003_idu.dtsi: debug_uart: dw-apb-uart@0x5000 {
arch/arc/boot/dts/vdk_axc003_idu.dtsi: mb_intc: dw-apb-ictl@0xe0012000 {
arch/arc/boot/dts/vdk_axs10x_mb.dtsi: ethernet@0x18000 {
arch/arc/boot/dts/vdk_axs10x_mb.dtsi: ehci@0x4 {
arch/arc/boot/dts/vdk_axs10x_mb.dtsi: uart@0x2 {
arch/arc/boot/dts/vdk_axs10x_mb.dtsi: uart@0x21000 {
arch/arc/boot/dts/vdk_axs10x_mb.dtsi: uart@0x22000 {
arch/arc/boot/dts/vdk_axs10x_mb.dtsi: mmc@0x15000 {
arch/arc/boot/dts/vdk_axs10x_mb.dtsi: uio_ev: uio@0xD000 {
arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts:
bootloaderenv@0x10 {
arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts:
bootloaderenvred@0x14 {
arch/arm/boot/dts/atlas7.dtsi: pmipc@0x1324 {
arch/arm/boot/dts/atlas7.dtsi: gnssmfw@0x1810 {
arch/arm/boot/dts/atlas7.dtsi: gpum@0x1300 {
arch/arm/boot/dts/atlas7.dtsi: sdr@0x1301 {
arch/arm/boot/dts/atlas7.dtsi: memory-controller@0x1080 {
arch/arm/boot/dts/atlas7.dtsi: retain@0x188D {
arch/arm/boot/dts/dm8148-evm.dts: partition@0x8 {
arch/arm/boot/dts/dm8148-evm.dts: partition@0x1c {
arch/arm/boot/dts/dm8148-evm.dts: partition@0x28 {
arch/arm/boot/dts/dm8148-evm.dts: partition@0x78 {
arch/arm/boot/dts/dm8168-evm.dts: partition@0x8 {
arch/arm/boot/dts/dm8168-evm.dts: partition@0x1c {
arch/arm/boot/dts/dm8168-evm.dts: partition@0x28 {
arch/arm/boot/dts/dm8168-evm.dts: partition@0x78 {
arch/arm/boot/dts/keystone-k2e-netcp.dtsi: pdsp0@0x2a1 {
arch/arm/boot/dts/keystone-k2hk-netcp.dtsi: pdsp0@0x2a1 {
arch/arm/boot/dts/keystone-k2l-netcp.dtsi: pdsp0@0x2a1 {
arch/arm/boot/dts/socfpga.dtsi: l3regs@0xff80 {
arch/arm/boot/dts/spear300.dtsi:shirq:
interrupt-controller@0x5000 {
arch/arm/boot/dts/spear310.dtsi:shirq:
interrupt-controller@0xb400 {
arch/arm/boot/dts/spear320.dtsi:shirq:
interrupt-controller@0xb300 {
arch/arm64/boot/dts/exynos/exynos5433.dtsi: sysmmu_scaler_0:
sysmmu@0x1504 {
arch/arm64/boot/dts/exynos/exynos5433.dtsi: sysmmu_scaler_1:
sysmmu@0x1505 {
arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi:partition@0x0 {
arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi:
partition@0x600 {
arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi:
partition@0x680 {
arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi:
par
Re: [RFC] ARC: allow to use IOC and non-IOC DMA devices simultaneously
On 06/15/2018 05:58 AM, Eugeniy Paltsev wrote:
> The ARC HS processor provides an IOC port (I/O coherency bus
> interface) that allows external devices such as DMA devices
> to access memory through the cache hierarchy, providing
> coherency between I/O transactions and the complete memory
> hierarchy.
This is really nice: having this a per device behaviour has been desirable
rather
than the current blunt system-wide behaviour.
However the patch doesn't seem to change the routing off non-coherent traffic -
everything would still go thru it - per the current default setting of
CREG_AXI_M_*_SLV[0-1] registers. Ideally you would want to disable that as well,
an addon patch is fine.
>
> Some recent SoC with ARC HS (like HSDK) allow to select bus
> port (IOC or non-IOC port) for connecting DMA devices in runtime.
>
> With this patch we can use both HW-coherent and regular DMA
> peripherals simultaneously.
>
> For example we can connect USB and SDIO controllers through IOC port
> (so we don't need to need to maintain cache coherency for these
> devices manualy. All cache sync ops will be nop)
> And we can connect Ethernet directly to RAM port (so we had to
> maintain cache coherency manualy. Cache sync ops will be real
> flush/invalidate operations)
>
> Cache ops are set per-device and depends on "dma-coherent" device
> tree property:
> "dma_noncoherent_ops" are used if no "dma-coherent" property is
> present (or IOC is disabled)
> "dma_direct_ops" are used if "dma-coherent" property is present.
I agree with Christoph that creating a new file for this seems excessive.
> NOTE 1:
> It works perfectly fine only if we don't have ZONE_HIGHMEM used
> as IOC doesn't cover all physical memory. As for today It configured
> to cover 1GiB starting from 0x8z (which is ZONE_NORMAL memory for
> us). Transactions outside this region are sent on the non-coherent
> I/O bus interface.
> We can't configure IOC to cover all physical memory as it has several
> limitations relating to aperture size and start address.
>
> And if we get DMA buffer from ZONE_HIGHMEM memory we need to
> do real flush/invalidate operations on that buffer, which is obviously
> not done by "dma_direct_ops".
>
> So I am not sure about "dma_direct_ops" using - probably we need to
> create our special cache ops like "arc_ioc_ops" which will handle
> ZONE_HIGHMEM case.
>
> (BTW: current ARC dma_noncoherent_ops implementation also has same
> problem if IOC and HIGHMEM are enabled.)
Can we highlight this fact, add error prints somewhere ?
> NOTE 2:
> In this RFC only hsdk.dts changes are shown to reduce patch size.
> AXS103 device tree changes are not shown.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> arch/arc/Kconfig | 1 +
> arch/arc/boot/dts/hsdk.dts | 4
> arch/arc/include/asm/dma-mapping.h | 14 ++
> arch/arc/mm/Makefile | 2 +-
> arch/arc/mm/cache.c| 15 +--
> arch/arc/mm/dma-mapping.c | 20
> arch/arc/mm/dma.c | 14 +-
> 7 files changed, 42 insertions(+), 28 deletions(-)
> create mode 100644 arch/arc/include/asm/dma-mapping.h
> create mode 100644 arch/arc/mm/dma-mapping.c
>
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index e81bcd271be7..0a2fcd2a8c32 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -17,6 +17,7 @@ config ARC
> select CLONE_BACKWARDS
> select COMMON_CLK
> select DMA_NONCOHERENT_OPS
> + select DMA_DIRECT_OPS
> select DMA_NONCOHERENT_MMAP
> select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
> select GENERIC_CLOCKEVENTS
> diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
> index 006aa3de5348..ebb686c21393 100644
> --- a/arch/arc/boot/dts/hsdk.dts
> +++ b/arch/arc/boot/dts/hsdk.dts
> @@ -176,6 +176,7 @@
> phy-handle = <&phy0>;
> resets = <&cgu_rst HSDK_ETH_RESET>;
> reset-names = "stmmaceth";
> + dma-coherent;
>
> mdio {
> #address-cells = <1>;
> @@ -194,12 +195,14 @@
> compatible = "snps,hsdk-v1.0-ohci", "generic-ohci";
> reg = <0x6 0x100>;
> interrupts = <15>;
> + dma-coherent;
> };
>
> ehci@4 {
> compatible = "snps,hsdk-v1.0-ehci", "generic-ehci";
> reg = <0x4 0x100>;
> interrupts = <15>;
> + dma-coherent;
> };
>
> mmc@a000 {
> @@ -212,6 +215,7 @@
> clock-names = "biu", "ciu";
> interrupts = <12>;
> bus-width = <4>;
> + dma-coherent;
> };
> };
>
> diff --git a/arch/arc/include/asm/dma-mapping.h
> b/arch/
Re: [PATCH] ARC: dts: Remove leading 0x from node unit addresses
On 18 June 2018 at 22:07, Joe Perches wrote:
> On Mon, 2018-06-18 at 21:16 +0200, Krzysztof Kozlowski wrote:
>> Remove leading 0x from all node unit addresses with a sed command:
>>
>> sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g"
>> arch/arc/boot/dts/*.dts*
>>
>> This fixes DTC warnings like:
>>
>> Warning (unit_address_format): /cpu_card/dw-apb-gpio@0x2000: unit name
>> should not have leading "0x"
>
> Do all of these need fixing?
>
> Aren't there dozens of these in arch/arm and elsewhere too?
Yeah, all of them need fixing too... and now I found patch from
Mathieu doing this for Arc:
https://patchwork.kernel.org/patch/10112715/
He also sent patches for other archs.
This patch can be ignored then.
Best regards,
Krzysztof
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
