* [PATCH 2/2] drm: zte: add initial vou drm driver
From: Shawn Guo @ 2016-09-24 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKMK7uEqrGCRwC-M5daTbrqVjs54C6jC=uYshXa_ciiN7Ftmqg@mail.gmail.com>
On Fri, Sep 23, 2016 at 01:54:59PM +0200, Daniel Vetter wrote:
> Please resubmit with dri-devel on cc.
My bad. Will do shortly.
Shawn
^ permalink raw reply
* [PATCH v6 2/4] arm64: dts: Add timer erratum property for LS2080A and LS1043A
From: Shawn Guo @ 2016-09-24 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E53FBB.9090208@arm.com>
On Fri, Sep 23, 2016 at 03:44:11PM +0100, Marc Zyngier wrote:
> With a commit message along the lines of:
>
> Both the LS1043A and LS2080A platforms are affected by the Freescale
> A008585 erratum. Advertise it in their respective device trees.
<snip>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Thanks, Marc. I queued up the patch with the suggested commit log
added.
Shawn
^ permalink raw reply
* [PATCH v6 2/4] arm64: dts: Add timer erratum property for LS2080A and LS1043A
From: Shawn Guo @ 2016-09-24 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923162755.GG6397@arm.com>
On Fri, Sep 23, 2016 at 05:27:56PM +0100, Will Deacon wrote:
> On Thu, Sep 22, 2016 at 03:35:16AM -0500, Scott Wood wrote:
> > Signed-off-by: Scott Wood <oss@buserror.net>
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
> > 2 files changed, 2 insertions(+)
>
> This patch conflicts with mainline,
Thanks for the heads-up.
> but I've queued the other three
> patches in the series in the arm64 tree.
>
> Please send the updated .dts changes via arm-soc.
I will send this to arm-soc when v4.9-rc1 comes out with driver changes
in place.
Shawn
^ permalink raw reply
* [PATCH v2 0/2] BQL support and fix for a regression issue
From: David Miller @ 2016-09-24 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474621948-9172-1-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Fri, 23 Sep 2016 14:42:26 +0530
> From: Sunil Goutham <sgoutham@cavium.com>
>
> These patches add byte queue limit support and also fixes a regression
> issue introduced by commit
> 'net: thunderx: Use netdev's name for naming VF's interrupts'
>
> Changes from v1:
> - As suggested added 'Fixes' tag with commit id of previous commit
> which cuased issue.
> - Also fixed the missing netdev_tx_reset_queue() function call in
> byte queue limits support patch.
Series applied to net-next, thanks.
^ permalink raw reply
* [PATCH 1/1] ARM: add printf format attribute to early_print()
From: Nicolas Iooss @ 2016-09-24 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160828165815.25647-1-nicolas.iooss_linux@m4x.org>
On 28/08/16 18:58, Nicolas Iooss wrote:
> Adding such an attribute is helpful to detect errors related to printf
> formats at compile-time.
>
> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
> ---
> arch/arm/include/asm/setup.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> index 3613d7e9fc40..797b8505b49a 100644
> --- a/arch/arm/include/asm/setup.h
> +++ b/arch/arm/include/asm/setup.h
> @@ -22,7 +22,7 @@
> static const struct tagtable __tagtable_##fn __tag = { tag, fn }
>
> extern int arm_add_memory(u64 start, u64 size);
> -extern void early_print(const char *str, ...);
> +extern __printf(1, 2) void early_print(const char *str, ...);
> extern void dump_machine_table(void);
>
> #ifdef CONFIG_ATAGS_PROC
Hello,
I sent this patch a few weeks ago and got no reply (and nothing showed
up on https://patchwork.kernel.org/patch/9302825/). Could you please
consider it for 4.9?
Thanks,
Nicolas
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-24 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923.224305.942077200829435690.davem@davemloft.net>
Hi David,
On 09/23/2016 07:43 PM, David Miller wrote:
> From: Eric Nelson <eric@nelint.com>
> Date: Fri, 23 Sep 2016 10:33:29 -0700
>
>> Since the hardware requires longword alignment for its' DMA transfers,
>> aligning the IP header will require a memcpy, right?
>
> I wish hardware designers didn't do this.
>
> There is no conflict between DMA alignment and properly offseting
> the packet data by two bytes.
>
> All hardware designers have to do is allow 2 padding bytes to be
> emitted by the chip before the actual packet data.
>
Andrew Lunn pointed out that the hardware does support this,
and I just pushed a patch for the vendor kernel to the meta-freescale
mailing list:
https://lists.yoctoproject.org/pipermail/meta-freescale/2016-September/019228.html
> Then the longword or whatever DMA transfer alignment is met
> whilst still giving the necessary flexibility for where the
> packet data lands.
>
Right. A relatively small change fixes things right up.
Many thanks to Andrew for pointing this out and Russell for providing
the basis for my patch.
I'll re-work this for the up-stream kernel when I get out from
under a couple of unrelated things.
^ permalink raw reply
* [PATCH v2] i2c: uniphier-f: fix misdetection of incomplete STOP condition
From: Wolfram Sang @ 2016-09-24 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474637681-9589-1-git-send-email-yamada.masahiro@socionext.com>
On Fri, Sep 23, 2016 at 10:34:41PM +0900, Masahiro Yamada wrote:
> Currently, the status register FI2C_SR is checked immediately after
> a STOP condition is issued in case of the deferred STOP condition.
> It takes typically 5-10 usec until the corresponding bits in the
> register are set, so the error check for "stop condition was not
> completed" is very likely to be false positive.
>
> Add wait code to relax the status register check.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/977ad2d7/attachment.sig>
^ permalink raw reply
* UBSAN: Undefined behaviour in ./arch/arm/include/asm/bitops.h
From: Russell King - ARM Linux @ 2016-09-24 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E604ED.6000408@samsung.com>
On Sat, Sep 24, 2016 at 01:45:33PM +0900, Seung-Woo Kim wrote:
> With the patch "arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL", I got
> following UBSAN warning on Exynos5422 SoC board.
Well, the simple solution is to have fls() and ffs() take unsigned int
arguments rather than ints - but the question that brings up is: why
do both of these take signed ints? It seems at least to me that it
would be more sensible for these to take unsigned int, or even
unsigned long like the other bitops do.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 5/5] tty: amba-pl011: Add earlycon support for SBSA UART
From: Kefeng Wang @ 2016-09-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474708465-38958-1-git-send-email-wangkefeng.wang@huawei.com>
Declare an OF early console for SBSA UART so that the early console device
can be specified via the "stdout-path" property in device-tree.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/tty/serial/amba-pl011.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7d9b291..3688d3b 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2330,6 +2330,7 @@ static int __init pl011_early_console_setup(struct earlycon_device *device,
return 0;
}
OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
+OF_EARLYCON_DECLARE(pl011, "arm,sbsa-uart", pl011_early_console_setup);
#else
#define AMBA_CONSOLE NULL
--
1.7.12.4
^ permalink raw reply related
* [PATCH 4/5] tty: amba-pl011: Don't complain on -EPROBE_DEFER when no irq
From: Kefeng Wang @ 2016-09-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474708465-38958-1-git-send-email-wangkefeng.wang@huawei.com>
Don't complain on -EPROBE_DEFER when attempting to get the irq.
the driver probe will be retried later.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/tty/serial/amba-pl011.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 8a9e213..7d9b291 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2555,7 +2555,8 @@ static int sbsa_uart_probe(struct platform_device *pdev)
ret = platform_get_irq(pdev, 0);
if (ret < 0) {
- dev_err(&pdev->dev, "cannot obtain irq\n");
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "cannot obtain irq\n");
return ret;
}
uap->port.irq = ret;
--
1.7.12.4
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: hisilicon: Add initial dts for Hip07 D05 board
From: Kefeng Wang @ 2016-09-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474708465-38958-1-git-send-email-wangkefeng.wang@huawei.com>
Adding initial dt file for Hip07 D05 board, it is with dual socket
and each socket has two SCCLs(supper cpu cluster), one SCCL contains
four clusters and each cluster has quard Cortex-A72.
Since each SCCL has their own DDR controller, it could be treated as
a separate numa node. Thus, there are four numa nodes(one node with
sixteen core) on Hip07 SoC.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/arm64/boot/dts/hisilicon/Makefile | 1 +
arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 66 ++
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 1059 +++++++++++++++++++++++++++
3 files changed, 1126 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/hip07-d05.dts
create mode 100644 arch/arm64/boot/dts/hisilicon/hip07.dtsi
diff --git a/arch/arm64/boot/dts/hisilicon/Makefile b/arch/arm64/boot/dts/hisilicon/Makefile
index d5f43a0..c8b8f80 100644
--- a/arch/arm64/boot/dts/hisilicon/Makefile
+++ b/arch/arm64/boot/dts/hisilicon/Makefile
@@ -1,6 +1,7 @@
dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
dtb-$(CONFIG_ARCH_HISI) += hip05-d02.dtb
dtb-$(CONFIG_ARCH_HISI) += hip06-d03.dtb
+dtb-$(CONFIG_ARCH_HISI) += hip07-d05.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07-d05.dts b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
new file mode 100644
index 0000000..e058442
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
@@ -0,0 +1,66 @@
+/**
+ * dts file for Hisilicon D05 Development Board
+ *
+ * Copyright (C) 2016 Hisilicon Ltd.
+ *
+ * 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
+ * publishhed by the Free Software Foundation.
+ *
+ */
+
+/dts-v1/;
+
+#include "hip07.dtsi"
+
+/ {
+ model = "Hisilicon Hip07 D05 Development Board";
+ compatible = "hisilicon,hip07-d05";
+
+ /* the mem node will be updated by UEFI. */
+ memory at 0 {
+ device_type = "memory";
+ reg = <0x0 0x00000000 0x0 0x40000000>;
+ numa-node-id = <0>;
+ };
+
+ distance-map {
+ compatible = "numa-distance-map-v1";
+ distance-matrix = <0 0 10>,
+ <0 1 15>,
+ <0 2 20>,
+ <0 3 25>,
+ <1 0 15>,
+ <1 1 10>,
+ <1 2 25>,
+ <1 3 30>,
+ <2 0 20>,
+ <2 1 25>,
+ <2 2 10>,
+ <2 3 15>,
+ <3 0 25>,
+ <3 1 30>,
+ <3 2 15>,
+ <3 3 10>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart0 {
+ status = "ok";
+};
+
+&usb_ohci {
+ status = "ok";
+};
+
+&usb_ehci {
+ status = "ok";
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
new file mode 100644
index 0000000..5144eb1
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -0,0 +1,1059 @@
+/**
+ * dts file for Hisilicon D05 Development Board
+ *
+ * Copyright (C) 2016 Hisilicon Ltd.
+ *
+ * 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
+ * publishhed by the Free Software Foundation.
+ *
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ compatible = "hisilicon,hip07-d05";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+ core1 {
+ cpu = <&cpu5>;
+ };
+ core2 {
+ cpu = <&cpu6>;
+ };
+ core3 {
+ cpu = <&cpu7>;
+ };
+ };
+
+ cluster2 {
+ core0 {
+ cpu = <&cpu8>;
+ };
+ core1 {
+ cpu = <&cpu9>;
+ };
+ core2 {
+ cpu = <&cpu10>;
+ };
+ core3 {
+ cpu = <&cpu11>;
+ };
+ };
+
+ cluster3 {
+ core0 {
+ cpu = <&cpu12>;
+ };
+ core1 {
+ cpu = <&cpu13>;
+ };
+ core2 {
+ cpu = <&cpu14>;
+ };
+ core3 {
+ cpu = <&cpu15>;
+ };
+ };
+
+ cluster4 {
+ core0 {
+ cpu = <&cpu16>;
+ };
+ core1 {
+ cpu = <&cpu17>;
+ };
+ core2 {
+ cpu = <&cpu18>;
+ };
+ core3 {
+ cpu = <&cpu19>;
+ };
+ };
+
+ cluster5 {
+ core0 {
+ cpu = <&cpu20>;
+ };
+ core1 {
+ cpu = <&cpu21>;
+ };
+ core2 {
+ cpu = <&cpu22>;
+ };
+ core3 {
+ cpu = <&cpu23>;
+ };
+ };
+
+ cluster6 {
+ core0 {
+ cpu = <&cpu24>;
+ };
+ core1 {
+ cpu = <&cpu25>;
+ };
+ core2 {
+ cpu = <&cpu26>;
+ };
+ core3 {
+ cpu = <&cpu27>;
+ };
+ };
+
+ cluster7 {
+ core0 {
+ cpu = <&cpu28>;
+ };
+ core1 {
+ cpu = <&cpu29>;
+ };
+ core2 {
+ cpu = <&cpu30>;
+ };
+ core3 {
+ cpu = <&cpu31>;
+ };
+ };
+
+ cluster8 {
+ core0 {
+ cpu = <&cpu32>;
+ };
+ core1 {
+ cpu = <&cpu33>;
+ };
+ core2 {
+ cpu = <&cpu34>;
+ };
+ core3 {
+ cpu = <&cpu35>;
+ };
+ };
+
+ cluster9 {
+ core0 {
+ cpu = <&cpu36>;
+ };
+ core1 {
+ cpu = <&cpu37>;
+ };
+ core2 {
+ cpu = <&cpu38>;
+ };
+ core3 {
+ cpu = <&cpu39>;
+ };
+ };
+
+ cluster10 {
+ core0 {
+ cpu = <&cpu40>;
+ };
+ core1 {
+ cpu = <&cpu41>;
+ };
+ core2 {
+ cpu = <&cpu42>;
+ };
+ core3 {
+ cpu = <&cpu43>;
+ };
+ };
+
+ cluster11 {
+ core0 {
+ cpu = <&cpu44>;
+ };
+ core1 {
+ cpu = <&cpu45>;
+ };
+ core2 {
+ cpu = <&cpu46>;
+ };
+ core3 {
+ cpu = <&cpu47>;
+ };
+ };
+
+ cluster12 {
+ core0 {
+ cpu = <&cpu48>;
+ };
+ core1 {
+ cpu = <&cpu49>;
+ };
+ core2 {
+ cpu = <&cpu50>;
+ };
+ core3 {
+ cpu = <&cpu51>;
+ };
+ };
+
+ cluster13 {
+ core0 {
+ cpu = <&cpu52>;
+ };
+ core1 {
+ cpu = <&cpu53>;
+ };
+ core2 {
+ cpu = <&cpu54>;
+ };
+ core3 {
+ cpu = <&cpu55>;
+ };
+ };
+
+ cluster14 {
+ core0 {
+ cpu = <&cpu56>;
+ };
+ core1 {
+ cpu = <&cpu57>;
+ };
+ core2 {
+ cpu = <&cpu58>;
+ };
+ core3 {
+ cpu = <&cpu59>;
+ };
+ };
+
+ cluster15 {
+ core0 {
+ cpu = <&cpu60>;
+ };
+ core1 {
+ cpu = <&cpu61>;
+ };
+ core2 {
+ cpu = <&cpu62>;
+ };
+ core3 {
+ cpu = <&cpu63>;
+ };
+ };
+ };
+
+ cpu0: cpu at 10000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10000>;
+ enable-method = "psci";
+ next-level-cache = <&cluster0_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu1: cpu at 10001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10001>;
+ enable-method = "psci";
+ next-level-cache = <&cluster0_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu2: cpu at 10002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10002>;
+ enable-method = "psci";
+ next-level-cache = <&cluster0_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu3: cpu at 10003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10003>;
+ enable-method = "psci";
+ next-level-cache = <&cluster0_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu4: cpu at 10100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10100>;
+ enable-method = "psci";
+ next-level-cache = <&cluster1_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu5: cpu at 10101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10101>;
+ enable-method = "psci";
+ next-level-cache = <&cluster1_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu6: cpu at 10102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10102>;
+ enable-method = "psci";
+ next-level-cache = <&cluster1_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu7: cpu at 10103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10103>;
+ enable-method = "psci";
+ next-level-cache = <&cluster1_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu8: cpu at 10200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10200>;
+ enable-method = "psci";
+ next-level-cache = <&cluster2_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu9: cpu at 10201 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10201>;
+ enable-method = "psci";
+ next-level-cache = <&cluster2_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu10: cpu at 10202 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10202>;
+ enable-method = "psci";
+ next-level-cache = <&cluster2_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu11: cpu at 10203 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10203>;
+ enable-method = "psci";
+ next-level-cache = <&cluster2_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu12: cpu at 10300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10300>;
+ enable-method = "psci";
+ next-level-cache = <&cluster3_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu13: cpu at 10301 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10301>;
+ enable-method = "psci";
+ next-level-cache = <&cluster3_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu14: cpu at 10302 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10302>;
+ enable-method = "psci";
+ next-level-cache = <&cluster3_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu15: cpu at 10303 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x10303>;
+ enable-method = "psci";
+ next-level-cache = <&cluster3_l2>;
+ numa-node-id = <0>;
+ };
+
+ cpu16: cpu at 30000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30000>;
+ enable-method = "psci";
+ next-level-cache = <&cluster4_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu17: cpu at 30001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30001>;
+ enable-method = "psci";
+ next-level-cache = <&cluster4_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu18: cpu at 30002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30002>;
+ enable-method = "psci";
+ next-level-cache = <&cluster4_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu19: cpu at 30003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30003>;
+ enable-method = "psci";
+ next-level-cache = <&cluster4_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu20: cpu at 30100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30100>;
+ enable-method = "psci";
+ next-level-cache = <&cluster5_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu21: cpu at 30101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30101>;
+ enable-method = "psci";
+ next-level-cache = <&cluster5_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu22: cpu at 30102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30102>;
+ enable-method = "psci";
+ next-level-cache = <&cluster5_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu23: cpu at 30103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30103>;
+ enable-method = "psci";
+ next-level-cache = <&cluster5_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu24: cpu at 30200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30200>;
+ enable-method = "psci";
+ next-level-cache = <&cluster6_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu25: cpu at 30201 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30201>;
+ enable-method = "psci";
+ next-level-cache = <&cluster6_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu26: cpu at 30202 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30202>;
+ enable-method = "psci";
+ next-level-cache = <&cluster6_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu27: cpu at 30203 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30203>;
+ enable-method = "psci";
+ next-level-cache = <&cluster6_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu28: cpu at 30300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30300>;
+ enable-method = "psci";
+ next-level-cache = <&cluster7_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu29: cpu at 30301 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30301>;
+ enable-method = "psci";
+ next-level-cache = <&cluster7_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu30: cpu at 30302 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30302>;
+ enable-method = "psci";
+ next-level-cache = <&cluster7_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu31: cpu at 30303 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x30303>;
+ enable-method = "psci";
+ next-level-cache = <&cluster7_l2>;
+ numa-node-id = <1>;
+ };
+
+ cpu32: cpu at 50000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50000>;
+ enable-method = "psci";
+ next-level-cache = <&cluster8_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu33: cpu at 50001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50001>;
+ enable-method = "psci";
+ next-level-cache = <&cluster8_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu34: cpu at 50002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50002>;
+ enable-method = "psci";
+ next-level-cache = <&cluster8_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu35: cpu at 50003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50003>;
+ enable-method = "psci";
+ next-level-cache = <&cluster8_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu36: cpu at 50100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50100>;
+ enable-method = "psci";
+ next-level-cache = <&cluster9_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu37: cpu at 50101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50101>;
+ enable-method = "psci";
+ next-level-cache = <&cluster9_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu38: cpu at 50102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50102>;
+ enable-method = "psci";
+ next-level-cache = <&cluster9_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu39: cpu at 50103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50103>;
+ enable-method = "psci";
+ next-level-cache = <&cluster9_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu40: cpu at 50200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50200>;
+ enable-method = "psci";
+ next-level-cache = <&cluster10_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu41: cpu at 50201 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50201>;
+ enable-method = "psci";
+ next-level-cache = <&cluster10_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu42: cpu at 50202 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50202>;
+ enable-method = "psci";
+ next-level-cache = <&cluster10_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu43: cpu at 50203 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50203>;
+ enable-method = "psci";
+ next-level-cache = <&cluster10_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu44: cpu at 50300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50300>;
+ enable-method = "psci";
+ next-level-cache = <&cluster11_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu45: cpu at 50301 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50301>;
+ enable-method = "psci";
+ next-level-cache = <&cluster11_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu46: cpu at 50302 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50302>;
+ enable-method = "psci";
+ next-level-cache = <&cluster11_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu47: cpu at 50303 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x50303>;
+ enable-method = "psci";
+ next-level-cache = <&cluster11_l2>;
+ numa-node-id = <2>;
+ };
+
+ cpu48: cpu at 70000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70000>;
+ enable-method = "psci";
+ next-level-cache = <&cluster12_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu49: cpu at 70001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70001>;
+ enable-method = "psci";
+ next-level-cache = <&cluster12_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu50: cpu at 70002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70002>;
+ enable-method = "psci";
+ next-level-cache = <&cluster12_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu51: cpu at 70003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70003>;
+ enable-method = "psci";
+ next-level-cache = <&cluster12_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu52: cpu at 70100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70100>;
+ enable-method = "psci";
+ next-level-cache = <&cluster13_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu53: cpu at 70101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70101>;
+ enable-method = "psci";
+ next-level-cache = <&cluster13_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu54: cpu at 70102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70102>;
+ enable-method = "psci";
+ next-level-cache = <&cluster13_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu55: cpu at 70103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70103>;
+ enable-method = "psci";
+ next-level-cache = <&cluster13_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu56: cpu at 70200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70200>;
+ enable-method = "psci";
+ next-level-cache = <&cluster14_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu57: cpu at 70201 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70201>;
+ enable-method = "psci";
+ next-level-cache = <&cluster14_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu58: cpu at 70202 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70202>;
+ enable-method = "psci";
+ next-level-cache = <&cluster14_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu59: cpu at 70203 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70203>;
+ enable-method = "psci";
+ next-level-cache = <&cluster14_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu60: cpu at 70300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70300>;
+ enable-method = "psci";
+ next-level-cache = <&cluster15_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu61: cpu at 70301 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70301>;
+ enable-method = "psci";
+ next-level-cache = <&cluster15_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu62: cpu at 70302 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70302>;
+ enable-method = "psci";
+ next-level-cache = <&cluster15_l2>;
+ numa-node-id = <3>;
+ };
+
+ cpu63: cpu at 70303 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x70303>;
+ enable-method = "psci";
+ next-level-cache = <&cluster15_l2>;
+ numa-node-id = <3>;
+ };
+
+ cluster0_l2: l2-cache0 {
+ compatible = "cache";
+ };
+
+ cluster1_l2: l2-cache1 {
+ compatible = "cache";
+ };
+
+ cluster2_l2: l2-cache2 {
+ compatible = "cache";
+ };
+
+ cluster3_l2: l2-cache3 {
+ compatible = "cache";
+ };
+
+ cluster4_l2: l2-cache4 {
+ compatible = "cache";
+ };
+
+ cluster5_l2: l2-cache5 {
+ compatible = "cache";
+ };
+
+ cluster6_l2: l2-cache6 {
+ compatible = "cache";
+ };
+
+ cluster7_l2: l2-cache7 {
+ compatible = "cache";
+ };
+
+ cluster8_l2: l2-cache8 {
+ compatible = "cache";
+ };
+
+ cluster9_l2: l2-cache9 {
+ compatible = "cache";
+ };
+
+ cluster10_l2: l2-cache10 {
+ compatible = "cache";
+ };
+
+ cluster11_l2: l2-cache11 {
+ compatible = "cache";
+ };
+
+ cluster12_l2: l2-cache12 {
+ compatible = "cache";
+ };
+
+ cluster13_l2: l2-cache13 {
+ compatible = "cache";
+ };
+
+ cluster14_l2: l2-cache14 {
+ compatible = "cache";
+ };
+
+ cluster15_l2: l2-cache15 {
+ compatible = "cache";
+ };
+ };
+
+ gic: interrupt-controller at 4d000000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ interrupt-controller;
+ #redistributor-regions = <4>;
+ redistributor-stride = <0x0 0x40000>;
+ reg = <0x0 0x4d000000 0x0 0x10000>, /* GICD */
+ <0x0 0x4d100000 0x0 0x400000>, /* p0 GICR node 0 */
+ <0x0 0x6d100000 0x0 0x400000>, /* p0 GICR node 1 */
+ <0x400 0x4d100000 0x0 0x400000>, /* p1 GICR node 2 */
+ <0x400 0x6d100000 0x0 0x400000>, /* p1 GICR node 3 */
+ <0x0 0xfe000000 0x0 0x10000>, /* GICC */
+ <0x0 0xfe010000 0x0 0x10000>, /* GICH */
+ <0x0 0xfe020000 0x0 0x10000>; /* GICV */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ p0_its_peri_a: interrupt-controller at 4c000000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ #msi-cells = <1>;
+ reg = <0x0 0x4c000000 0x0 0x40000>;
+ };
+
+ p0_its_peri_b: interrupt-controller at 6c000000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ #msi-cells = <1>;
+ reg = <0x0 0x6c000000 0x0 0x40000>;
+ };
+
+ p0_its_dsa_a: interrupt-controller at c6000000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ #msi-cells = <1>;
+ reg = <0x0 0xc6000000 0x0 0x40000>;
+ };
+
+ p0_its_dsa_b: interrupt-controller at 8,c6000000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ #msi-cells = <1>;
+ reg = <0x8 0xc6000000 0x0 0x40000>;
+ };
+
+ p1_its_peri_a: interrupt-controller at 400,4c000000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ #msi-cells = <1>;
+ reg = <0x400 0x4c000000 0x0 0x40000>;
+ };
+
+ p1_its_peri_b: interrupt-controller at 400,6c000000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ #msi-cells = <1>;
+ reg = <0x400 0x6c000000 0x0 0x40000>;
+ };
+
+ p1_its_dsa_a: interrupt-controller at 400,c6000000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ #msi-cells = <1>;
+ reg = <0x400 0xc6000000 0x0 0x40000>;
+ };
+
+ p1_its_dsa_b: interrupt-controller at 408,c6000000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ #msi-cells = <1>;
+ reg = <0x408 0xc6000000 0x0 0x40000>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a72-pmu";
+ interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ p0_mbigen_peri_b: interrupt-controller at 60080000 {
+ compatible = "hisilicon,mbigen-v2";
+ reg = <0x0 0x60080000 0x0 0x10000>;
+
+ mbigen_uart: uart_intc {
+ msi-parent = <&p0_its_peri_b 0x120c7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <1>;
+ };
+ };
+
+ p0_mbigen_pcie_a: interrupt-controller at a0080000 {
+ compatible = "hisilicon,mbigen-v2";
+ reg = <0x0 0xa0080000 0x0 0x10000>;
+
+ mbigen_usb: intc_usb {
+ msi-parent = <&p0_its_dsa_a 0x40080>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <2>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ uart0: uart at 602b0000 {
+ compatible = "arm,sbsa-uart";
+ reg = <0x0 0x602b0000 0x0 0x1000>;
+ interrupt-parent = <&mbigen_uart>;
+ interrupts = <807 4>;
+ current-speed = <115200>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ usb_ohci: ohci at a7030000 {
+ compatible = "generic-ohci";
+ reg = <0x0 0xa7030000 0x0 0x10000>;
+ interrupt-parent = <&mbigen_usb>;
+ interrupts = <640 4>;
+ dma-coherent;
+ status = "disabled";
+ };
+
+ usb_ehci: ehci at a7020000 {
+ compatible = "generic-ehci";
+ reg = <0x0 0xa7020000 0x0 0x10000>;
+ interrupt-parent = <&mbigen_usb>;
+ interrupts = <641 4>;
+ dma-coherent;
+ status = "disabled";
+ };
+ };
+};
--
1.7.12.4
^ permalink raw reply related
* [PATCH 2/5] Documentation: arm64: Add Hisilicon Hip07 D05 dts binding
From: Kefeng Wang @ 2016-09-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474708465-38958-1-git-send-email-wangkefeng.wang@huawei.com>
This patch adds documentation for the devicetree bindings used by
the DT files of Hisilicon Hip07 D05 board.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 3f81575..7df79a7 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -28,6 +28,10 @@ HiP06 D03 Board
Required root node properties:
- compatible = "hisilicon,hip06-d03";
+HiP07 D05 Board
+Required root node properties:
+ - compatible = "hisilicon,hip07-d05";
+
Hisilicon system controller
Required properties:
--
1.7.12.4
^ permalink raw reply related
* [PATCH 1/5] arm64: dts: hip06: Correct hardware pin number of usb node
From: Kefeng Wang @ 2016-09-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474708465-38958-1-git-send-email-wangkefeng.wang@huawei.com>
The ohci/ehci hardware pin number should be 640/641, correct them.
Fixes: commit aa8d3e74f54d ("arm64: dts: Add initial dts for Hisilicon Hip06 D03 board")
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index 66b1bbf..be76f7d 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -322,7 +322,7 @@
compatible = "generic-ohci";
reg = <0x0 0xa7030000 0x0 0x10000>;
interrupt-parent = <&mbigen_usb>;
- interrupts = <64 4>;
+ interrupts = <640 4>;
dma-coherent;
status = "disabled";
};
@@ -331,7 +331,7 @@
compatible = "generic-ehci";
reg = <0x0 0xa7020000 0x0 0x10000>;
interrupt-parent = <&mbigen_usb>;
- interrupts = <65 4>;
+ interrupts = <641 4>;
dma-coherent;
status = "disabled";
};
--
1.7.12.4
^ permalink raw reply related
* [PATCH 0/5] arm64: dts: hisilicon: Hip06 fix and support Hip07 D05 board
From: Kefeng Wang @ 2016-09-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
1) DTs
- Fix Hip06 ehci/ohci interrupt pin number.
- Add initial support for Hip07 D05 board.
2) PL011
- The sbsa uart is used on Hip07 SoC, the interrupt is connected to mbigen,
but the uart probe(arch_init) is earlier than mbigen(module_init), so
don't complain on -EPROBE_DEFER when no irq.
- Add earlycon support for SBSA UART.
Kefeng Wang (5):
arm64: dts: hip06: Correct hardware pin number of usb node
Documentation: arm64: Add Hisilicon Hip07 D05 dts binding
arm64: dts: hisilicon: Add initial dts for Hip07 D05 board
tty: amba-pl011: Don't complain on -EPROBE_DEFER when no irq
tty: amba-pl011: Add earlycon support for SBSA UART
.../bindings/arm/hisilicon/hisilicon.txt | 4 +
arch/arm64/boot/dts/hisilicon/Makefile | 1 +
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 4 +-
arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 66 ++
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 1059 ++++++++++++++++++++
drivers/tty/serial/amba-pl011.c | 4 +-
6 files changed, 1135 insertions(+), 3 deletions(-)
create mode 100644 arch/arm64/boot/dts/hisilicon/hip07-d05.dts
create mode 100644 arch/arm64/boot/dts/hisilicon/hip07.dtsi
--
1.7.12.4
^ permalink raw reply
* [PATCH v3 0/4] regulator: axp20x: support AXP803/AXP813 variants
From: Jean-Francois Moine @ 2016-09-24 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65LjjB_vM46yurKOcw6mMaxW3pXTHwbxQO6L1BTOnTUmw@mail.gmail.com>
On Sat, 24 Sep 2016 16:35:05 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> On Fri, Sep 23, 2016 at 4:58 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > This patch series adds support for the X-Powers AXP803 and AXP813 PMICs.
> > It is based on the previous patch series
> > regulator: axp20x: Simplify various code
> >
> > v3:
> > - put the code of the new devices in new files instead of in the common
> > axp20x file.
> > - fix errors about the regulators and interrupts
> > v2:
> > - fix lack of support of dcdc frequency
> > - notice that the AXP803 is also handled
> > - send the patch to the DT maintainers
> >
> > Jean-Francois Moine (4):
> > regulator: axp20x: move device independant parts to new files
> > regulator: axp20x: duplicate the MFD axp20x-rsb code
> > regulator: axp20x: add the AXP803
> > regulator: axp20x: add the AXP813
>
> NAK. Please follow the axp20x mfd and sub-device driver design we
> already have.
Sorry, I will not: installing a lot of useless code and tables in
permanent system memory for just one regulator is not the way I think
about a good kernel.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 3/3] regulator: axp20x: simplify device access
From: Jean-Francois Moine @ 2016-09-24 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64ZpQ=9KUH39cFoRxU6n03cgDoUbHegjFfDWaTLQAZ2wg@mail.gmail.com>
On Sat, 24 Sep 2016 16:29:11 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
[snip]
> > static int axp20x_regulator_probe(struct platform_device *pdev)
> > {
> > + struct device *dev = pdev->dev.parent;
>
> There are 2 struct device's in play in this function, 1 from the parent,
> and 1 for the platform device for this regulator sub-device.
>
> > struct regulator_dev *rdev;
> > - struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> > + struct axp20x_dev *axp20x = dev_get_drvdata(dev);
> > const struct regulator_desc *regulators;
> > struct regulator_config config = {
> > - .dev = pdev->dev.parent,
> > + .dev = dev,
> > .regmap = axp20x->regmap,
> > .driver_data = axp20x,
> > };
> > @@ -532,7 +533,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> > dcdc5_ix = AXP22X_DCDC5;
> > dc1sw_ix = AXP22X_DC1SW;
> > dc5ldo_ix = AXP22X_DC5LDO;
> > - drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
> > + drivevbus = of_property_read_bool(dev->of_node,
> > "x-powers,drive-vbus-en");
> > break;
> > case AXP806_ID:
> > @@ -555,13 +556,13 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> > dc5ldo_ix = AXP809_DC5LDO;
> > break;
> > default:
> > - dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
> > + dev_err(dev, "Unsupported AXP variant: %ld\n",
>
> So this one is incorrect. You should use this device's struct,
> not the parent. It's possible the mfd driver supports a PMIC,
> but the regulator driver is still missing.
Why do you need a regulator driver? The 'regulator' node in the DT is
not a real device. It is just a container and it could be removed
without any problem.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Wolfram Sang @ 2016-09-24 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJGQ2az=eO0PbfcTrAPxUsym=UaDOOy1Rsw0-AbzMjnXg@mail.gmail.com>
> I did state some reasons previously. Consistent rules for submitters
> of DT bindings and being able to trace history beyond git. Now, I
> guess you aren't changing the rules, but you probably aren't
> requesting people to split DT bindings either? You might not be aware,
> but we also generate a DT only tree with git-filter-branch[1] for
> non-kernel projects to use bindings and dts files. For that, sure they
> will only get the DT binding part of it, but what commit text do they
> get? Finally, DT maintainer acks (which from me is a review really)
> apply to the bindings only. Sometimes I review the drivers, but not
> often. So I would like the git history of my reviews to be accurate in
> terms of what I actually reviewed.
Points taken. Will keep them seperate from now on.
Thanks,
Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/b82a4946/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 0/4] regulator: axp20x: support AXP803/AXP813 variants
From: Chen-Yu Tsai @ 2016-09-24 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1474621107.git.moinejf@free.fr>
On Fri, Sep 23, 2016 at 4:58 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> This patch series adds support for the X-Powers AXP803 and AXP813 PMICs.
> It is based on the previous patch series
> regulator: axp20x: Simplify various code
>
> v3:
> - put the code of the new devices in new files instead of in the common
> axp20x file.
> - fix errors about the regulators and interrupts
> v2:
> - fix lack of support of dcdc frequency
> - notice that the AXP803 is also handled
> - send the patch to the DT maintainers
>
> Jean-Francois Moine (4):
> regulator: axp20x: move device independant parts to new files
> regulator: axp20x: duplicate the MFD axp20x-rsb code
> regulator: axp20x: add the AXP803
> regulator: axp20x: add the AXP813
NAK. Please follow the axp20x mfd and sub-device driver design we
already have.
ChenYu
> Documentation/devicetree/bindings/mfd/axp20x.txt | 29 ++-
> drivers/mfd/axp20x.c | 15 +
> drivers/regulator/Makefile | 3 +-
> drivers/regulator/axp-regulator.c | 347 +++++++++++++++++++
> drivers/regulator/axp-regulator.h | 133 ++++++++
> drivers/regulator/axp20x-regulator.c | 415 ++---------------------
> drivers/regulator/axp803.c | 225 ++++++++++++
> drivers/regulator/axp813.c | 229 +++++++++++++
> include/linux/mfd/axp20x.h | 2 +
> 9 files changed, 1012 insertions(+), 388 deletions(-)
> create mode 100644 drivers/regulator/axp-regulator.c
> create mode 100644 drivers/regulator/axp-regulator.h
> create mode 100644 drivers/regulator/axp803.c
> create mode 100644 drivers/regulator/axp813.c
>
> --
> 2.10.0
>
^ permalink raw reply
* [PATCH 3/3] regulator: axp20x: simplify device access
From: Chen-Yu Tsai @ 2016-09-24 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d3078ed4eefd4de48e4b5666a64f6123f8d72483.1474616699.git.moinejf@free.fr>
Hi,
On Thu, Sep 22, 2016 at 2:20 AM, Jean-Francois Moine <moinejf@free.fr> wrote:
> Use the pointer to the main regulator device instead of the pointer
> to the child platform device.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> drivers/regulator/axp20x-regulator.c | 45 ++++++++++++++++++------------------
> 1 file changed, 23 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
> index 7405f5b..244ddc3 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -347,9 +347,9 @@ static const struct regulator_desc axp809_regulators[] = {
> AXP_DESC_SW(AXP809, SW, "sw", "swin", AXP22X_PWR_OUT_CTRL2, BIT(6)),
> };
>
> -static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
> +static int axp20x_set_dcdc_freq(struct device *dev, u32 dcdcfreq)
> {
> - struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> + struct axp20x_dev *axp20x = dev_get_drvdata(dev);
> unsigned int reg = AXP20X_DCDC_FREQ;
> u32 min, max, def, step;
>
> @@ -378,7 +378,7 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
> step = 150;
> break;
> default:
> - dev_err(&pdev->dev,
> + dev_err(dev,
> "Setting DCDC frequency for unsupported AXP variant\n");
> return -EINVAL;
> }
> @@ -388,13 +388,13 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
>
> if (dcdcfreq < min) {
> dcdcfreq = min;
> - dev_warn(&pdev->dev, "DCDC frequency too low. Set to %ukHz\n",
> + dev_warn(dev, "DCDC frequency too low. Set to %ukHz\n",
> min);
> }
>
> if (dcdcfreq > max) {
> dcdcfreq = max;
> - dev_warn(&pdev->dev, "DCDC frequency too high. Set to %ukHz\n",
> + dev_warn(dev, "DCDC frequency too high. Set to %ukHz\n",
> max);
> }
>
> @@ -404,24 +404,24 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
> AXP20X_FREQ_DCDC_MASK, dcdcfreq);
> }
>
> -static int axp20x_regulator_parse_dt(struct platform_device *pdev)
> +static int axp20x_regulator_parse_dt(struct device *dev)
> {
> struct device_node *np, *regulators;
> int ret;
> u32 dcdcfreq = 0;
>
> - np = of_node_get(pdev->dev.parent->of_node);
> + np = of_node_get(dev->of_node);
> if (!np)
> return 0;
>
> regulators = of_get_child_by_name(np, "regulators");
> if (!regulators) {
> - dev_warn(&pdev->dev, "regulators node not found\n");
> + dev_warn(dev, "regulators node not found\n");
> } else {
> of_property_read_u32(regulators, "x-powers,dcdc-freq", &dcdcfreq);
> - ret = axp20x_set_dcdc_freq(pdev, dcdcfreq);
> + ret = axp20x_set_dcdc_freq(dev, dcdcfreq);
> if (ret < 0) {
> - dev_err(&pdev->dev, "Error setting dcdc frequency: %d\n", ret);
> + dev_err(dev, "Error setting dcdc frequency: %d\n", ret);
> return ret;
> }
>
> @@ -499,11 +499,12 @@ static u32 axp20x_polyphase_slave(struct axp20x_dev *axp20x)
>
> static int axp20x_regulator_probe(struct platform_device *pdev)
> {
> + struct device *dev = pdev->dev.parent;
There are 2 struct device's in play in this function, 1 from the parent,
and 1 for the platform device for this regulator sub-device.
> struct regulator_dev *rdev;
> - struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> + struct axp20x_dev *axp20x = dev_get_drvdata(dev);
> const struct regulator_desc *regulators;
> struct regulator_config config = {
> - .dev = pdev->dev.parent,
> + .dev = dev,
> .regmap = axp20x->regmap,
> .driver_data = axp20x,
> };
> @@ -532,7 +533,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> dcdc5_ix = AXP22X_DCDC5;
> dc1sw_ix = AXP22X_DC1SW;
> dc5ldo_ix = AXP22X_DC5LDO;
> - drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
> + drivevbus = of_property_read_bool(dev->of_node,
> "x-powers,drive-vbus-en");
> break;
> case AXP806_ID:
> @@ -555,13 +556,13 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> dc5ldo_ix = AXP809_DC5LDO;
> break;
> default:
> - dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
> + dev_err(dev, "Unsupported AXP variant: %ld\n",
So this one is incorrect. You should use this device's struct,
not the parent. It's possible the mfd driver supports a PMIC,
but the regulator driver is still missing.
> axp20x->variant);
> return -EINVAL;
> }
>
> /* This only sets the dcdc freq. Ignore any errors */
> - axp20x_regulator_parse_dt(pdev);
> + axp20x_regulator_parse_dt(dev);
>
> for (i = 0; i < nregulators; i++) {
> const struct regulator_desc *desc = ®ulators[i];
> @@ -580,7 +581,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> * name.
> */
> if (i == dc1sw_ix && dcdc1_name) {
> - new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
> + new_desc = devm_kzalloc(dev, sizeof(*desc),
> GFP_KERNEL);
> *new_desc = regulators[i];
> new_desc->supply_name = dcdc1_name;
> @@ -588,16 +589,16 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> }
>
> if (i == dc5ldo_ix && dcdc5_name) {
> - new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
> + new_desc = devm_kzalloc(dev, sizeof(*desc),
> GFP_KERNEL);
Same here. The devres lifetime should be bound to this driver, not the parent.
> *new_desc = regulators[i];
> new_desc->supply_name = dcdc5_name;
> desc = new_desc;
> }
>
> - rdev = devm_regulator_register(&pdev->dev, desc, &config);
> + rdev = devm_regulator_register(dev, desc, &config);
Same here.
> if (IS_ERR(rdev)) {
> - dev_err(&pdev->dev, "Failed to register %s\n",
> + dev_err(dev, "Failed to register %s\n",
Same here.
> regulators[i].name);
>
> return PTR_ERR(rdev);
> @@ -608,7 +609,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> &workmode);
> if (!ret) {
> if (axp20x_set_dcdc_workmode(rdev, i, workmode))
> - dev_err(&pdev->dev, "Failed to set workmode on %s\n",
> + dev_err(dev, "Failed to set workmode on %s\n",
Same here.
> rdev->desc->name);
> }
>
> @@ -630,11 +631,11 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> /* Change N_VBUSEN sense pin to DRIVEVBUS output pin */
> regmap_update_bits(axp20x->regmap, AXP20X_OVER_TMP,
> AXP22X_MISC_N_VBUSEN_FUNC, 0);
> - rdev = devm_regulator_register(&pdev->dev,
> + rdev = devm_regulator_register(dev,
Same here.
> &axp22x_drivevbus_regulator,
> &config);
> if (IS_ERR(rdev)) {
> - dev_err(&pdev->dev, "Failed to register drivevbus\n");
> + dev_err(dev, "Failed to register drivevbus\n");
Same here.
Regards
ChenYu
> return PTR_ERR(rdev);
> }
> }
> --
> 2.10.0
>
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang @ 2016-09-24 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1849232.KJrfRPHGN6@wuerfel>
Hi, Arnd,
On 2016?09?23? 23:55, Arnd Bergmann wrote:
> On Friday, September 23, 2016 2:59:55 PM CEST Gabriele Paoloni wrote:
>>
>>>> From the perspective of the indirect IO function the input parameter
>>>> is an unsigned long addr that (now) can be either:
>>>> 1) an IO token coming from a legacy pci device
>>>> 2) a phys address that lives on the LPC bus
>>>>
>>>> These are conceptually two separate address spaces (and actually they
>>>> both start from 0).
>>>
>>> Why? Any IORESOURCE_IO address always refers to the logical I/O port
>>> range in Linux, not the physical address that is used on a bus.
>>
>> If I read the code correctly when you get an I/O token you just add it
>> to PCI_IOBASE.
>> This is enough since pci_remap_iospace set the virtual address to
>> PCI_IOBASE + the I/O token offset; so we can read/write to
>> vaddr = PCI_IOBASE + token as pci_remap_iospace has mapped it correctly
>> to the respective PCI cpu address (that is set in the I/O range property
>> of the host controller)
>>
>> In the patchset accessors LPC operates directly on the cpu addresses
>> and the input parameter of the accessors can be either an IO token or
>> a cpu address
>>
>> +static inline void outb(u8 value, unsigned long addr)
>> +{
>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>> + if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
>> + addr <= arm64_extio_ops->end)
>>
>> Here below we operate on cpu address
>>
>> + extio_outb(value, addr);
>> + else
>> +#endif
>
> I missed this bug earlier, this obviously needs to be
>
> arm64_extio_ops->outb(value, addr - arm64_extio_ops->start);
>
> or possibly
>
> arm64_extio_ops->outb(arm64_extio_ops, value, addr);
>
> as the outb function won't know what the offset is, but
> that needed to be fixed regardless.
In V3, the outb is :
void outb(u8 value, unsigned long addr)
{
if (!arm64_extio_ops || arm64_extio_ops->start > addr ||
arm64_extio_ops->end < addr)
writeb(value, PCI_IOBASE + addr);
else
if (arm64_extio_ops->pfout)
arm64_extio_ops->pfout(arm64_extio_ops->devpara,
addr + arm64_extio_ops->ptoffset, &value,
sizeof(u8), 1);
}
here, arm64_extio_ops->ptoffset is the offset between the real legacy IO address
and the logical IO address, similar to the offset of primary address and
secondary address in PCI bridge.
But in V3, LPC driver call pci_address_to_pio to request the logical IO as PCI
host bridge during its probing.
cheers,
Zhichang
>
> Arnd
>
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang @ 2016-09-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1760643.vMTR5o5E9g@wuerfel>
Hi, Arnd,
On 2016?09?23? 17:51, Arnd Bergmann wrote:
> On Friday, September 23, 2016 12:27:17 AM CEST zhichang.yuan wrote:
>> For this patch sketch, I have a question.
>> Do we call pci_address_to_pio in arch_of_address_to_pio to get the
>> corresponding logical IO port
>> for LPC??
>
>
> No, of course not, that would be silly:
>
> The argument to pci_address_to_pio() is a phys_addr_t, and we we don't
> have one because there is no address associated with your PIO, that
> is the entire point of your driver!
>
ok. I think I know you points. The physical addresses of LPC are only the LPC
domain addresses, not the really CPU physical addresses. That is just why you
don't support the ranges property usage in patch V3. Consequently, It is not so
reasonable to call pci_address_to_pio() with LPC address because that function
is only suitable for cpu physical address.
But just as you said in the next email reply to Gabriele, "Any IORESOURCE_IO
address always refers to the logical I/O port range in Linux, not the physical
address that is used on a bus.", Any devices which support IO accesses should
have their own unique logical IO range to drive the corresponding hardware. It
means that the drivers should know the mapping between physical port/memory
address and logical IO depend on the device specific I/O mode. At this moment,
only PCI host bridge setup a logical IO range allocation mechanism to manipulate
this logical IO range, and this way applies cpu physical address(memory) as the
input. Now, our LPC also need subrange from this common logical IO range, but
with legacy I/O port rather than CPU memory address. Ok, it break the
precondition of pci_register_io_range/pci_pio_to_address, we should not use them
directly for LPC although the calling of pci_pio_to_address is simple and less
change on the relevant code. We had done like that in V3...
So, the key issue is how to get a logical IO subrange which is not conflicted
with others, such as pci host bridges??
I list several ideas for discussion:
1. reserve a specific logical IO subrange for LPC
I describe this in "Note 1" below. Please check it.
This way seems simple without much changes, but it is not generic.
2. setup a separate logical IO subrange allocation mechanism specific for LPC/ISA
Just as your suggestion before, add the arch_of_address_to_pio() for the devices
which operate I/O with legacy I/O port address rather than memory address in
MMIO mode. That arch_of_address_to_pio() will return non-conflict logical IO
with PCI host bridge at last. But the logical IO range is global, those
functions for LPC/ISA specific logical IO subrange allocation must be
synchronized with pci_register_io_range/pci_pio_to_address to know what logical
ranges had been populated. It is not good for the implement dispersion on same
issue.
3. setup a new underlying method to control the logical IO range management
Based on the existing resource management, add a simplified logical IO range
management support which only request the logical IO ranges according the IO
range size ( similar to IORESOURCE_SIZEALIGN mode ), no matter what type the
physical address is. Then revise the current pci_register_io_range to adopt this
new method. Of-course, LPC/ISA request the logical IO with this new method too.
This is just a proposition. It is more workload compared with other solutions.
What do you think about these? Any more ideas?
> Also, we already know the mapping because this is what the inb/outb
> workaround is looking at, so there is absolutely no reason to call it
> either.
>
>> If we don't, it seems the LPC specific IO address will conflict with PCI
>> host bridges' logical IO.
>>
>> Supposed our LPC populated the IO range from 0x100 to 0x3FF( this is
>> normal for ISA similar
>> devices), after arch_of_address_to_pio(), the r->start will be set as
>> 0x100, r->end will be set as
>> 0x3FF. And if there is one PCI host bridge who request a IO window size
>> over 0x400 at the same
>> time, the corresponding r->start and r->end will be set as 0x0, 0x3FF
>> after of_address_to_resource
>> for this host bridge. Then the IO conflict happens.
>
> You would still need to reserve some space in the io_range_list
> to avoid possible conflicts, which is a bit ugly with the current
> definition of pci_register_io_range, but I'm sure can be done.
>
Note 1) Do you remember patch V2? There, I modified the pci.c like that to
reserve 0 - PCIBIOS_MIN_IO (it is 0x1000) :
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index aab9d51..ac2e569 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3221,7 +3221,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resourc
#ifdef PCI_IOBASE
struct io_range *range;
- resource_size_t allocated_size = 0;
+ resource_size_t allocated_size = PCIBIOS_MIN_IO;
/* check if the range hasn't been previously recorded */
spin_lock(&io_range_lock);
@@ -3270,7 +3270,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
#ifdef PCI_IOBASE
struct io_range *range;
- resource_size_t allocated_size = 0;
+ resource_size_t allocated_size = PCIBIOS_MIN_IO;
if (pio > IO_SPACE_LIMIT)
return address;
@@ -3293,7 +3293,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t addres
{
#ifdef PCI_IOBASE
struct io_range *res;
- resource_size_t offset = 0;
+ resource_size_t offset = PCIBIOS_MIN_IO;
unsigned long addr = -1;
spin_lock(&io_range_lock);
Based on this, a exclusive logical IO subrange is for LPC now. Then we certainly
can add some special handling in __of_address_to_resource or
__of_translate_address --> of_translate_one to return the untranslated LPC/ISA
IO address. But to be honest, I think we don't need this special handling in
address.c anymore. We had known the LPC/ISA IO is 1:1 to logical IO, just think
any logical IO port among 0 - 0x1000 should call the LPC registered I/O hooks in
the new in/out().
Furthermore, we can make the reservation is not fixed as PCIBIOS_MIN_IO. If the
LPC/ISA probing is run before PCI host bridge probing, we can reserve a
non-fixed logcial IO subrange what LPC/ISA ask for.
This solution is based on an assumption that no any other devices have to
request the specific logical IO subrange for LPC/ISA. Probably this assumption
is ok on arm64, you known, there is no real IO space as X86. But anyway, this
reservation is not so generic, depended on some special handling.
Does this idea match your comments??
> One way I can think of would be to change pci_register_io_range()
> to just return the logical port number directly (it already
> knows it!), and pass an invalid physical address (e.g.
> #define ISA_WORKAROUND_IO_PORT_WINDOW -0x10000) into it for
> invalid translations.
>
I am not so clear know your idea here. Do you want to select an unpopulated CPU
address as the parent address in range property?? or anything else???
> Another alternative that just occurred to me would be to move
> the pci_address_to_pio() call from __of_address_to_resource()
> into of_bus_pci_translate() and then do the special handling
> for the ISA/LPC bus in of_bus_isa_translate().
As for this idea, do you mean that of_translate_address will directly return the
final logical IO start address?? It seems to extend the definition of
of_translate_address.
Thanks,
Zhichang
>
> Arnd
>
^ permalink raw reply related
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Eric Anholt @ 2016-09-24 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbJoM-RbcuoC=7xJyrT3v7p2n9HiidRp1GUw=o43_Fkwg@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> On Fri, Sep 23, 2016 at 3:15 PM, Eric Anholt <eric@anholt.net> wrote:
>> Linus Walleij <linus.walleij@linaro.org> writes:
>>>> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
>>>> index 3fb357193f09..671ccd00aea2 100644
>>>> --- a/include/soc/bcm2835/raspberrypi-firmware.h
>>>> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
>>>> @@ -73,11 +73,13 @@ enum rpi_firmware_property_tag {
>>>> RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE = 0x00030014,
>>>> RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
>>>> RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
>>>> + RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
>>>> RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
>>>> RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
>>>> RPI_FIRMWARE_SET_VOLTAGE = 0x00038003,
>>>> RPI_FIRMWARE_SET_TURBO = 0x00038009,
>>>> RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
>>>> + RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
>>>
>>> Can you please merge this orthogonally into the rpi tree to ARM SoC?
>>
>> This driver would appear in the rpi downstream tree once we settle the
>> driver here. Or are you asking me to delay this series until I can get
>> them to pull just a patch extending the set of packets?
>
> Sorry I am not familiar with your development model. I don't know
> about any RPI downstream tree... What I mean is that the patch to
> include/soc/bcm2835/raspberrypi-firmware.h should be merged by
> whoever is maintaining that file, it is not a GPIO file.
>
> If I get an ACK from the maintainer I can take it into the GPIO
> tree.
Oh, people often say "the rpi tree" to mean downstream (currently 4.4).
The maintainer of that file upstream is me, and I was hoping you could
merge through your tree.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/7d45838e/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] mfd: ab8500-debugfs: remove unused function
From: Baoyou Xie @ 2016-09-24 5:36 UTC (permalink / raw)
To: linux-arm-kernel
We get 1 warning when building kernel with W=1:
drivers/mfd/ab8500-debugfs.c:1395:6: warning: no previous prototype for 'ab8500_dump_all_banks_to_mem' [-Wmissing-prototypes]
In fact, this function is called by no one and not exported,
so this patch removes it.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/mfd/ab8500-debugfs.c | 54 --------------------------------------------
1 file changed, 54 deletions(-)
diff --git a/drivers/mfd/ab8500-debugfs.c b/drivers/mfd/ab8500-debugfs.c
index 0aecd7b..9f04a25 100644
--- a/drivers/mfd/ab8500-debugfs.c
+++ b/drivers/mfd/ab8500-debugfs.c
@@ -1382,60 +1382,6 @@ void ab8500_dump_all_banks(struct device *dev)
}
}
-/* Space for 500 registers. */
-#define DUMP_MAX_REGS 700
-static struct ab8500_register_dump
-{
- u8 bank;
- u8 reg;
- u8 value;
-} ab8500_complete_register_dump[DUMP_MAX_REGS];
-
-/* This shall only be called upon kernel panic! */
-void ab8500_dump_all_banks_to_mem(void)
-{
- int i, r = 0;
- u8 bank;
- int err = 0;
-
- pr_info("Saving all ABB registers for crash analysis.\n");
-
- for (bank = 0; bank < AB8500_NUM_BANKS; bank++) {
- for (i = 0; i < debug_ranges[bank].num_ranges; i++) {
- u8 reg;
-
- for (reg = debug_ranges[bank].range[i].first;
- reg <= debug_ranges[bank].range[i].last;
- reg++) {
- u8 value;
-
- err = prcmu_abb_read(bank, reg, &value, 1);
-
- if (err < 0)
- goto out;
-
- ab8500_complete_register_dump[r].bank = bank;
- ab8500_complete_register_dump[r].reg = reg;
- ab8500_complete_register_dump[r].value = value;
-
- r++;
-
- if (r >= DUMP_MAX_REGS) {
- pr_err("%s: too many register to dump!\n",
- __func__);
- err = -EINVAL;
- goto out;
- }
- }
- }
- }
-out:
- if (err >= 0)
- pr_info("Saved all ABB registers.\n");
- else
- pr_info("Failed to save all ABB registers.\n");
-}
-
static int ab8500_all_banks_open(struct inode *inode, struct file *file)
{
struct seq_file *s;
--
2.7.4
^ permalink raw reply related
* Alignment issues with freescale FEC driver
From: Andy Duan @ 2016-09-24 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923.224553.1824171056324385383.davem@davemloft.net>
From: David Miller <davem@davemloft.net> Sent: Saturday, September 24, 2016 10:46 AM
> To: eric at nelint.com
> Cc: andrew at lunn.ch; edumazet at google.com; Andy Duan
> <fugang.duan@nxp.com>; otavio at ossystems.com.br;
> netdev at vger.kernel.org; troy.kisky at boundarydevices.com;
> rmk+kernel at arm.linux.org.uk; cjb.sw.nospam at gmail.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: Alignment issues with freescale FEC driver
>
> From: Eric Nelson <eric@nelint.com>
> Date: Fri, 23 Sep 2016 11:35:17 -0700
>
> > From the i.MX6DQ reference manual, bit 7 of ENET_RACC says this:
> >
> > "RX FIFO Shift-16
> >
> > When this field is set, the actual frame data starts at bit 16 of the
> > first word read from the RX FIFO aligning the Ethernet payload on a
> > 32-bit boundary."
> >
> > Same for the i.MX6UL.
> >
> > I'm not sure what it will take to use this, but it seems to be exactly
> > what we're looking for.
>
> +1
RACC[SHIFT16] just instructs the MAC to write two additional bytes in front of each frame received into the RX FIFO to align
the Ethernet payload on a 32-bit boundary.
Eric's patch "net: fec: support RRACC_SHIFT16 to align IP header" works fine.
For the alignment issues, that is introduced by commit 1b7bde6d6 and c259c132a in net-next tree. Before these commits, no alignment issue.
How to fix the issue:
Solution1: to enable HW RRACC_SHIFT16 feature (test pass):
Eric's patch "net: fec: support RRACC_SHIFT16 to align IP header".
Solution2: include the correct prefetch() header (test pass):
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -59,7 +59,7 @@
#include <linux/pinctrl/consumer.h>
#include <linux/pm_runtime.h>
#include <linux/busfreq-imx.h>
-#include <linux/prefetch.h>
+#include <asm/processor.h>
Solution3: use __netdev_alloc_skb_ip_align() instead of netdev_alloc_skb().
Or: still use the previous method before commit 1b7bde6d6:
skb = netdev_alloc_skb(ndev, pkt_len - 4 + NET_IP_ALIGN);
skb_reserve(skb, NET_IP_ALIGN);
Comparing these solutions:
From sw effort and performance, I think these are the similar. Enable RRACC_SHIFT16 doesn't take extra advantage.
Correct my if I am wrong. Thanks.
Regards,
Andy
^ permalink raw reply
* [PATCH] crypto: sunxi-ss: mark sun4i_hash() static
From: Baoyou Xie @ 2016-09-24 4:28 UTC (permalink / raw)
To: linux-arm-kernel
We get 1 warning when building kernel with W=1:
drivers/crypto/sunxi-ss/sun4i-ss-hash.c:168:5: warning: no previous prototype for 'sun4i_hash' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index 1afeb8e..0de2f62 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -165,7 +165,7 @@ int sun4i_hash_import_sha1(struct ahash_request *areq, const void *in)
* write remaining data in op->buf
* final state op->len=56
*/
-int sun4i_hash(struct ahash_request *areq)
+static int sun4i_hash(struct ahash_request *areq)
{
u32 v, ivmode = 0;
unsigned int i = 0;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox