* [PATCH v5 02/10] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
From: Rob Herring @ 2017-04-28 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426152023.41567-3-icenowy@aosc.io>
On Wed, Apr 26, 2017 at 11:20:15PM +0800, Icenowy Zheng wrote:
> The A31 NMI driver seems to be using wrong base address.
>
> As we're going to convert to use a correct NMI base address (and
> correctly name it to R_INTC as the datasheet suggests), add a new
> compatible string for the "correct" R_INTC, which we will use for A64
> SoC.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> .../bindings/interrupt-controller/allwinner,sunxi-nmi.txt | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs
From: Jon Mason @ 2017-04-28 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6628a958-087d-1221-7717-c07eeaec3cce@broadcom.com>
On Fri, Apr 28, 2017 at 4:36 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
>
>
> On 17-04-28 01:11 PM, Jon Mason wrote:
>>
>> Tweak the Kconfig description to mention support for NSP and make the
>> default on for iProc based platforms.
>>
>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>> ---
>> drivers/thermal/broadcom/Kconfig | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/thermal/broadcom/Kconfig
>> b/drivers/thermal/broadcom/Kconfig
>> index f0dea8a..b6f4b85 100644
>> --- a/drivers/thermal/broadcom/Kconfig
>> +++ b/drivers/thermal/broadcom/Kconfig
>> @@ -1,8 +1,9 @@
>> config BCM_NS_THERMAL
>> tristate "Northstar thermal driver"
>> depends on ARCH_BCM_IPROC || COMPILE_TEST
>
> If this driver is used on these SoCs then it:
> depends on ARCH_BCM_NSP || ARCH_BCM_5301X || COMPILE_TEST
> ?
The code referenced is outside of this patch, as that code was already
existing from when the driver was submitted.
I did some checking and NS2 and Cygnus do not have the registers in
use by this driver. So, you are correct in that this driver will
never be used for them. So, this is slightly over-permissive in
allowing a driver to be selected that could not ever be used on
non-NS/NSP hardware. But barring an incorrect DT string, it would
only result in an slightly larger kernel than necessary.
I'll do a follow-on patch to correct this with your suggestion above,
and push it separately (unless a v4 is needed on this series).
Thanks,
Jon
>> + default y if ARCH_BCM_IPROC
>> help
>> - Northstar is a family of SoCs that includes e.g. BCM4708,
>> BCM47081,
>> - BCM4709 and BCM47094. It contains DMU (Device Management Unit)
>> block
>> - with a thermal sensor that allows checking CPU temperature. This
>> - driver provides support for it.
>> + Support for the Northstar and Northstar Plus family of SoCs
>> (e.g.
>> + BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU
>> (Device
>> + Management Unit) block with a thermal sensor that allows
>> checking CPU
>> + temperature.
>>
>
^ permalink raw reply
* [PATCH v2 29/30] dt-bindings: add vendor prefix for bananapi
From: Rob Herring @ 2017-04-28 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493198774-4478-30-git-send-email-sean.wang@mediatek.com>
On Wed, Apr 26, 2017 at 05:26:13PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Banana Pi team in Sinovoip Co., Limited which are dedicated to
> design and manufacture open hardware product.
>
> Website: http://www.banana-pi.org/
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index ec0bfb9..8ca0f3c 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -44,6 +44,7 @@ avia avia semiconductor
> avic Shanghai AVIC Optoelectronics Co., Ltd.
> axentia Axentia Technologies AB
> axis Axis Communications AB
> +bananapi Banana Pi SINOVOP CO., LIMITED
s/SINOVOP/SINOVOIP/
> boe BOE Technology Group Co., Ltd.
> bosch Bosch Sensortec GmbH
> boundary Boundary Devices Inc.
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs
From: Scott Branden @ 2017-04-28 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493410291-16679-3-git-send-email-jon.mason@broadcom.com>
On 17-04-28 01:11 PM, Jon Mason wrote:
> Tweak the Kconfig description to mention support for NSP and make the
> default on for iProc based platforms.
>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> drivers/thermal/broadcom/Kconfig | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
> index f0dea8a..b6f4b85 100644
> --- a/drivers/thermal/broadcom/Kconfig
> +++ b/drivers/thermal/broadcom/Kconfig
> @@ -1,8 +1,9 @@
> config BCM_NS_THERMAL
> tristate "Northstar thermal driver"
> depends on ARCH_BCM_IPROC || COMPILE_TEST
If this driver is used on these SoCs then it:
depends on ARCH_BCM_NSP || ARCH_BCM_5301X || COMPILE_TEST
?
> + default y if ARCH_BCM_IPROC
> help
> - Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
> - BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
> - with a thermal sensor that allows checking CPU temperature. This
> - driver provides support for it.
> + Support for the Northstar and Northstar Plus family of SoCs (e.g.
> + BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
> + Management Unit) block with a thermal sensor that allows checking CPU
> + temperature.
>
^ permalink raw reply
* [PATCH] [stable v3.18.y] ARM: 8383/1: nommu: avoid deprecated source register on mov
From: Stefan Agner @ 2017-04-28 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427193230.2673449-1-arnd@arndb.de>
On 2017-04-27 12:32, Arnd Bergmann wrote:
> From: Stefan Agner <stefan@agner.ch>
>
> Commit 970d96f9a81b0dd83ddd8bce0e5e1ba31881c5f5 upstream.
>
> In Thumb2 mode, the stack register r13 is deprecated if the
> destination register is the program counter (r15). Similar to
> head.S, head-nommu.S uses r13 to store the return address used
> after configuring the CPU's CP15 register. However, since we do
> not enable a MMU, there will be no address switch and it is
> possible to use branch with link instruction to call
> __after_proc_init.
>
> Avoid using r13 completely by using bl to call __after_proc_init
> and get rid of __secondary_switched.
>
> Beside removing unnecessary complexity, this also fixes a
> compiler warning when compiling a !MMU kernel:
> Warning: Use of r13 as a source register is deprecated when r15
> is the destination register.
>
> Tested-?by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ----
> I've backported this build fix to 3.18.y as the original
> patch did not apply cleanly. I rebased it one patch at a time,
> and each step was fairly straightforward, but I did not test
> it on hardware, so it would still be nice to have someone else
> look over the patch to see if I did something wrong.
Looks good to me.
--
Stefan
> ---
> arch/arm/kernel/head-nommu.S | 20 +++++++-------------
> 1 file changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index cc176b67c134..c6c66dd4be89 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -77,13 +77,12 @@ ENTRY(stext)
> orr r6, r6, #(1 << MPU_RSR_EN) @ Set region enabled bit
> bl __setup_mpu
> #endif
> - ldr r13, =__mmap_switched @ address to jump to after
> - @ initialising sctlr
> adr lr, BSYM(1f) @ return (PIC) address
> ARM( add pc, r10, #PROCINFO_INITFUNC )
> THUMB( add r12, r10, #PROCINFO_INITFUNC )
> THUMB( ret r12 )
> - 1: b __after_proc_init
> +1: bl __after_proc_init
> + b __mmap_switched
> ENDPROC(stext)
>
> #ifdef CONFIG_SMP
> @@ -106,8 +105,7 @@ ENTRY(secondary_startup)
> movs r10, r5 @ invalid processor?
> beq __error_p @ yes, error 'p'
>
> - adr r4, __secondary_data
> - ldmia r4, {r7, r12}
> + ldr r7, __secondary_data
>
> #ifdef CONFIG_ARM_MPU
> /* Use MPU region info supplied by __cpu_up */
> @@ -115,23 +113,19 @@ ENTRY(secondary_startup)
> bl __setup_mpu @ Initialize the MPU
> #endif
>
> - adr lr, BSYM(__after_proc_init) @ return address
> - mov r13, r12 @ __secondary_switched address
> + adr lr, BSYM(1f) @ return (PIC) address
> ARM( add pc, r10, #PROCINFO_INITFUNC )
> THUMB( add r12, r10, #PROCINFO_INITFUNC )
> THUMB( ret r12 )
> -ENDPROC(secondary_startup)
> -
> -ENTRY(__secondary_switched)
> +1: bl __after_proc_init
> ldr sp, [r7, #8] @ set up the stack pointer
> mov fp, #0
> b secondary_start_kernel
> -ENDPROC(__secondary_switched)
> +ENDPROC(secondary_startup)
>
> .type __secondary_data, %object
> __secondary_data:
> .long secondary_data
> - .long __secondary_switched
> #endif /* CONFIG_SMP */
>
> /*
> @@ -164,7 +158,7 @@ __after_proc_init:
> #endif
> mcr p15, 0, r0, c1, c0, 0 @ write control reg
> #endif /* CONFIG_CPU_CP15 */
> - ret r13
> + ret lr
> ENDPROC(__after_proc_init)
> .ltorg
^ permalink raw reply
* [PATCH v2 25/30] arm: dts: mt7623: rename mt7623-evb.dts to arch/arm/boot/dts/mt7623n-rfb.dtsi
From: Rob Herring @ 2017-04-28 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493198774-4478-26-git-send-email-sean.wang@mediatek.com>
On Wed, Apr 26, 2017 at 05:26:09PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> There are 2 versions of the SoC. MT7623N is almost identical to MT7623A
> but has some additional multimedia features. The reference boards are
> available as NAND or MMC and might have a different ethernet setup. In
> order to reduce the duplication of devicetree code we add an intermediate
> dtsi file for these reference boards. Additionally Mediatek pointed out,
> that the EVB is yet another board and the board in question is infact the
> RFB. Take this into account while renaming the files.
You are breaking compatibility with existing DTs. Just document which
flavor you want "mediatek,mt7623" to refer to and add the new one. Or
just add 2 new strings but keep the old one.
>
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>
> ---
> Documentation/devicetree/bindings/arm/mediatek.txt | 6 ++--
> arch/arm/boot/dts/Makefile | 2 +-
> arch/arm/boot/dts/mt7623-evb.dts | 33 ----------------------
> arch/arm/boot/dts/mt7623n-rfb-nand.dts | 21 ++++++++++++++
> arch/arm/boot/dts/mt7623n-rfb.dtsi | 29 +++++++++++++++++++
> arch/arm/mach-mediatek/mediatek.c | 4 +--
> arch/arm/mach-mediatek/platsmp.c | 2 +-
> 7 files changed, 57 insertions(+), 40 deletions(-)
> delete mode 100644 arch/arm/boot/dts/mt7623-evb.dts
> create mode 100644 arch/arm/boot/dts/mt7623n-rfb-nand.dts
> create mode 100644 arch/arm/boot/dts/mt7623n-rfb.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt
> index c860b24..7f7c804 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek.txt
> @@ -12,7 +12,7 @@ compatible: Must contain one of
> "mediatek,mt6592"
> "mediatek,mt6755"
> "mediatek,mt6795"
> - "mediatek,mt7623"
> + "mediatek,mt7623n"
> "mediatek,mt8127"
> "mediatek,mt8135"
> "mediatek,mt8173"
^ permalink raw reply
* [PATCH 3/3] arm64: dts: ns2: Add USB3 Support
From: Jon Mason @ 2017-04-28 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493411381-16833-1-git-send-email-jon.mason@broadcom.com>
From: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Add USB3 support to the Northstar2 Device tree files
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 16 +++++++++
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 8 +++++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 62 ++++++++++++++++++++++++++++++++
3 files changed, 86 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index ec19fbf..7cd2ef7 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -234,3 +234,19 @@
};
};
};
+
+&usb3_phy0 {
+ status = "okay";
+};
+
+&usb3_phy1 {
+ status = "okay";
+};
+
+&xhci0 {
+ status = "okay";
+};
+
+&xhci1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/broadcom/ns2-xmc.dts b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
index ab4ae1a..8e8feb7 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
@@ -189,3 +189,11 @@
&uart3 {
status = "okay";
};
+
+&usb3_phy0 {
+ status = "okay";
+};
+
+&xhci0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 35a309a..2360ff5 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -343,6 +343,11 @@
<0x660009b0 0x40>;
};
+ usb3_ctrl: syscon at 6501d144 {
+ compatible = "brcm,ns2-usb3-ctrl", "syscon";
+ reg = <0x6501d144 0x4>;
+ };
+
gpio_aon: gpio at 65024800 {
compatible = "brcm,iproc-gpio";
reg = <0x65024800 0x50>,
@@ -460,6 +465,11 @@
};
};
+ usb3_phy_cfg: syscon at 66000910 {
+ compatible = "brcm,ns2-usb3-phy-cfg", "syscon";
+ reg = <0x66000910 0x14>;
+ };
+
pwm: pwm at 66010000 {
compatible = "brcm,iproc-pwm";
reg = <0x66010000 0x28>;
@@ -487,6 +497,34 @@
};
};
+ mdio at 1 {
+ reg = <0x1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb3_phy: usb3_phy at 0 {
+ compatible = "brcm,ns2-usb3-phy";
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ usb3-ctrl-syscon = <&usb3_ctrl>;
+ usb3-phy-cfg-syscon = <&usb3_phy_cfg>;
+ usb3-rst-ctrl-syscon = <&usb3_rst_ctrl>;
+
+ usb3_phy0: usb3_phy at 0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ usb3_phy1: usb_phy at 1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+ };
+ };
+
mdio at 7 {
reg = <0x7>;
#address-cells = <1>;
@@ -652,6 +690,26 @@
reg = <0x66220000 0x28>;
};
+ xhci0: usb at 66300000 {
+ compatible = "generic-xhci";
+ reg = <0x66300000 0x1000>;
+ interrupts = <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb3_phy0>;
+ phy-names = "usb";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ xhci1: usb at 66310000 {
+ compatible = "generic-xhci";
+ reg = <0x66310000 0x1000>;
+ interrupts = <GIC_SPI 433 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb3_phy1>;
+ phy-names = "usb";
+ dma-coherent;
+ status = "disabled";
+ };
+
sata_phy: sata_phy at 663f0100 {
compatible = "brcm,iproc-ns2-sata-phy";
reg = <0x663f0100 0x1f00>,
@@ -747,5 +805,9 @@
#size-cells = <0>;
};
+ usb3_rst_ctrl: syscon at 67000408 {
+ compatible = "brcm,ns2-usb3-rst-ctrl", "syscon";
+ reg = <0x67000408 0x1808>;
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] phy: Add USB3 PHY support for Broadcom NS2 SoC
From: Jon Mason @ 2017-04-28 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493411381-16833-1-git-send-email-jon.mason@broadcom.com>
From: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
This patch adds support for Broadcom NS2 USB3 PHY
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
drivers/phy/Kconfig | 9 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-bcm-ns2-usb3.c | 596 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 606 insertions(+)
create mode 100644 drivers/phy/phy-bcm-ns2-usb3.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index dc5277a..c86f47c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -498,6 +498,15 @@ config PHY_NS2_PCIE
Enable this to support the Broadcom Northstar2 PCIe PHY.
If unsure, say N.
+config PHY_NS2_USB3
+ tristate "Broadcom NorthStar2 USB3 PHY driver"
+ depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GENERIC_PHY
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Northstar2 USB3 PHY.
+ If unsure, say N.
+
config PHY_MESON8B_USB2
tristate "Meson8b and GXBB USB2 PHY driver"
default ARCH_MESON
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index e7b0feb..8ad8920 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -61,5 +61,6 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
+obj-$(CONFIG_PHY_NS2_USB3) += phy-bcm-ns2-usb3.o
obj-$(CONFIG_PHY_MESON8B_USB2) += phy-meson8b-usb2.o
obj-$(CONFIG_PHY_NSP_USB3) += phy-bcm-nsp-usb3.o
diff --git a/drivers/phy/phy-bcm-ns2-usb3.c b/drivers/phy/phy-bcm-ns2-usb3.c
new file mode 100644
index 0000000..203f509
--- /dev/null
+++ b/drivers/phy/phy-bcm-ns2-usb3.c
@@ -0,0 +1,596 @@
+/*
+ * Copyright (C) 2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mdio.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/regmap.h>
+
+#define NS2_USB3_PHY_MAX 0x02
+
+#define NS2_USB3_PHY_CONFIG_CTRL_REG 0x00
+#define NS2_USB3_PHY_CONFIG_CTRL_MASK (BIT(3) | BIT(4) | BIT(5))
+#define NS2_USB3_PHY_CONFIG_CTRL_PLL_SEQ_START BIT(6)
+
+#define NS2_USB3_PHY_P0CTL_REG 0x04
+#define NS2_USB3_PHY_P1CTL_REG 0x08
+#define NS2_USB3_PHY_PXCTL_I_BIT BIT(1)
+
+#define NS2_USB3_PHY_MISC_STATUS_REG 0x10
+
+#define NS2_IDM_RST_CTRL_P0_OFFSET 0x3f8
+#define NS2_IDM_RST_CTRL_P1_OFFSET 0x13f8
+#define NS2_IDM_RESET_CONTROL_BIT BIT(0)
+
+#define NS2_IDM_IO_CTRL_P0_OFFSET 0x0
+#define NS2_IDM_IO_CTRL_P1_OFFSET 0x1000
+/* Bit 23 for PPC Polarity, Bit 24 for PPC NANDNOR select */
+#define NS2_IDM_IO_CTRL_PPC_CFG (BIT(23) | BIT(24))
+
+#define NS2_PHY_RESET_BIT BIT(5)
+#define NS2_PHY_PLL_RESET_BIT BIT(6)
+
+/* NS2 USB3 MDIO */
+#define NS2_USB3_MDIO_PLL30_ADDR 0x8000
+#define NS2_USB3_MDIO_BLK_ACCESS 0x1F
+#define NS2_USB3_MDIO_PLL30_ANAPLL_CTRL 0x14
+#define NS2_USB3_MDIO_PLL30_ANAPLL_CTRL_VAL 0x23
+#define NS2_USB3_MDIO_PLL30_GEN_PLL 0xF
+#define NS2_USB3_MDIO_PLL30_GEN_PLL_PCLK_SEL BIT(11)
+#define NS2_USB3_MDIO_P0_AFE30_ADDR 0x8080
+#define NS2_USB3_MDIO_P1_AFE30_ADDR 0x9080
+#define NS2_USB3_MDIO_AFE30_RX_SIG_DETECT 0x5
+#define NS2_USB3_MDIO_AFE30_RX_SIG_DETECT_VAL 0xAC0D
+
+#define NS2_USB3_MDIO_P0_PIPE_BLK_ADDR 0x8060
+#define NS2_USB3_MDIO_P1_PIPE_BLK_ADDR 0x9060
+#define NS2_USB3_MDIO_PIPE_BLK_REG_1_OFFSET 0x1
+#define NS2_USB3_MDIO_PIPE_BLK_REG_1_VAL 0x207
+
+#define NS2_USB3_MDIO_P0_AEQ_BLK_ADDR 0x80E0
+#define NS2_USB3_MDIO_P1_AEQ_BLK_ADDR 0x90E0
+#define NS2_USB3_MDIO_AEQ_BLK_REG_1_OFFSET 0x1
+#define NS2_USB3_MDIO_AEQ_BLK_REG_1_VAL 0x3000
+
+/* USB3 Histogram Programming */
+#define NS2_USB3_IRAADR_OFFSET 0x198
+#define NS2_USB3_IRADAT_OFFSET 0x19c
+#define USB3_HISTOGRAM_OFFSET_VAL 0xA200
+#define USB3_BYPASS_VBUS_INPUTS BIT(2)
+#define USB3_OVERRIDE_VBU_PRESENT BIT(3)
+#define USB3_OVERRIDE_CURRENT_MASK (~(BIT(4)))
+#define NS2_USB3_MDIO_RESET_BIT (BIT(12))
+
+enum ns2_phy_block {
+ PHY_RESET,
+ PHY_PLL_RESET,
+ PHY_SOFT_RESET,
+ PHY_PIPE_RESET,
+ PHY_REF_CLOCK,
+ PHY_PLL_SEQ_START,
+ PHY_PLL_STATUS,
+ PHY_VBUS_PPC,
+};
+
+enum ns2_reg_base {
+ NS2_USB3_CTRL = 1,
+ NS2_USB3_PHY_CFG,
+ NS2_USB3_RST_CTRL,
+ NS2_USB3_REG_BASE_MAX
+};
+
+struct ns2_usb3_phy {
+ void __iomem *reg_base[NS2_USB3_REG_BASE_MAX];
+ struct ns2_usb3_phy_master *mphy;
+ struct phy *phy;
+ int port_no;
+};
+
+struct ns2_usb3_phy_master {
+ struct ns2_usb3_phy iphys[NS2_USB3_PHY_MAX];
+ struct mdio_device *mdiodev;
+ struct mutex phy_mutex;
+ int init_count; /* PHY is dual port phy, so init once*/
+};
+
+static int iproc_ns2_phy_action(struct ns2_usb3_phy *iphy,
+ enum ns2_phy_block block, bool assert)
+{
+ void __iomem *addr;
+ u32 data, count;
+ u32 offset = 0;
+ int ret = 0;
+
+ switch (block) {
+ case PHY_RESET:
+ addr = iphy->reg_base[NS2_USB3_CTRL];
+
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ if (assert)
+ data &= ~NS2_PHY_RESET_BIT;
+ else
+ data |= NS2_PHY_RESET_BIT;
+
+ ret = regmap_write(addr, offset, data);
+ break;
+
+ case PHY_PLL_RESET:
+ addr = iphy->reg_base[NS2_USB3_CTRL];
+
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ if (assert)
+ data &= ~NS2_PHY_PLL_RESET_BIT;
+ else
+ data |= NS2_PHY_PLL_RESET_BIT;
+
+ ret = regmap_write(addr, offset, data);
+ break;
+
+ case PHY_SOFT_RESET:
+ addr = iphy->reg_base[NS2_USB3_PHY_CFG];
+ offset = NS2_USB3_PHY_P0CTL_REG;
+
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ if (assert)
+ data &= ~NS2_USB3_PHY_PXCTL_I_BIT;
+ else
+ data |= NS2_USB3_PHY_PXCTL_I_BIT;
+
+ ret = regmap_write(addr, offset, data);
+ if (ret != 0)
+ return ret;
+
+ offset = NS2_USB3_PHY_P1CTL_REG;
+
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ if (assert)
+ data &= ~NS2_USB3_PHY_PXCTL_I_BIT;
+ else
+ data |= NS2_USB3_PHY_PXCTL_I_BIT;
+
+ ret = regmap_write(addr, offset, data);
+ break;
+
+ case PHY_PIPE_RESET:
+ addr = iphy->reg_base[NS2_USB3_RST_CTRL];
+ offset = NS2_IDM_RST_CTRL_P0_OFFSET;
+
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ if (assert)
+ data |= NS2_IDM_RESET_CONTROL_BIT;
+ else
+ data &= ~NS2_IDM_RESET_CONTROL_BIT;
+
+ ret = regmap_write(addr, offset, data);
+ if (ret != 0)
+ return ret;
+
+ offset = NS2_IDM_RST_CTRL_P1_OFFSET;
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ if (assert)
+ data |= NS2_IDM_RESET_CONTROL_BIT;
+ else
+ data &= ~NS2_IDM_RESET_CONTROL_BIT;
+
+ ret = regmap_write(addr, offset, data);
+ break;
+
+ case PHY_VBUS_PPC:
+ addr = iphy->reg_base[NS2_USB3_RST_CTRL];
+ offset = NS2_IDM_IO_CTRL_P0_OFFSET;
+
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ if (assert)
+ data |= NS2_IDM_IO_CTRL_PPC_CFG;
+ else
+ data &= ~NS2_IDM_IO_CTRL_PPC_CFG;
+
+ ret = regmap_write(addr, offset, data);
+ if (ret != 0)
+ return ret;
+
+ offset = NS2_IDM_IO_CTRL_P1_OFFSET;
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ if (assert)
+ data |= NS2_IDM_IO_CTRL_PPC_CFG;
+ else
+ data &= ~NS2_IDM_IO_CTRL_PPC_CFG;
+
+ ret = regmap_write(addr, offset, data);
+ break;
+
+ case PHY_REF_CLOCK:
+ addr = iphy->reg_base[NS2_USB3_PHY_CFG];
+ offset = NS2_USB3_PHY_CONFIG_CTRL_REG;
+
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ data &= ~NS2_USB3_PHY_CONFIG_CTRL_MASK;
+
+ ret = regmap_write(addr, offset, data);
+ break;
+
+ case PHY_PLL_SEQ_START:
+ addr = iphy->reg_base[NS2_USB3_PHY_CFG];
+ offset = NS2_USB3_PHY_CONFIG_CTRL_REG;
+
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ data |= NS2_USB3_PHY_CONFIG_CTRL_PLL_SEQ_START;
+
+ ret = regmap_write(addr, offset, data);
+ break;
+
+ case PHY_PLL_STATUS:
+ count = 2000;
+ addr = iphy->reg_base[NS2_USB3_PHY_CFG];
+ offset = NS2_USB3_PHY_MISC_STATUS_REG;
+
+ do {
+ udelay(1);
+ ret = regmap_read(addr, offset, &data);
+ if (ret != 0)
+ return ret;
+
+ if (data == 1)
+ break;
+ } while (--count);
+
+ if (!count)
+ ret = -ETIMEDOUT;
+ break;
+
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
+static int ns2_usb3_phy_exit(struct phy *phy)
+{
+ struct ns2_usb3_phy *iphy = phy_get_drvdata(phy);
+ int rc = 0;
+
+ mutex_lock(&iphy->mphy->phy_mutex);
+
+ if (iphy->mphy->init_count <= 0) {
+ mutex_unlock(&iphy->mphy->phy_mutex);
+ return 0;
+ } else if (iphy->mphy->init_count == 1) {
+ /* Only put in to reset for last port to exit */
+ rc = iproc_ns2_phy_action(iphy, PHY_PLL_RESET, true);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_SOFT_RESET, true);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_RESET, true);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_PIPE_RESET, true);
+ if (rc)
+ goto out;
+ }
+
+out:
+ iphy->mphy->init_count--;
+ mutex_unlock(&iphy->mphy->phy_mutex);
+
+ return rc;
+}
+
+static int ns2_usb3_phy_init(struct phy *phy)
+{
+ struct ns2_usb3_phy *iphy = phy_get_drvdata(phy);
+ u16 addr;
+ u16 reg_val;
+ int rc;
+
+ mutex_lock(&iphy->mphy->phy_mutex);
+
+ if (iphy->mphy->init_count) {
+ /* Use count to identify last port to call phy_exit. */
+ iphy->mphy->init_count++;
+ mutex_unlock(&iphy->mphy->phy_mutex);
+ return 0;
+ }
+
+ rc = iproc_ns2_phy_action(iphy, PHY_RESET, false);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_SOFT_RESET, true);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_PIPE_RESET, true);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_REF_CLOCK, true);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_PLL_RESET, true);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_RESET, true);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_RESET, false);
+ if (rc)
+ goto out;
+
+ /* PLL programming */
+ /* PHY PLL30 Block */
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_BLK_ACCESS,
+ NS2_USB3_MDIO_PLL30_ADDR);
+ if (rc)
+ goto out;
+
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_PLL30_ANAPLL_CTRL,
+ NS2_USB3_MDIO_PLL30_ANAPLL_CTRL_VAL);
+ if (rc)
+ goto out;
+
+ reg_val = (u16) mdiobus_read(iphy->mphy->mdiodev->bus,
+ iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_PLL30_GEN_PLL);
+ reg_val |= NS2_USB3_MDIO_PLL30_GEN_PLL_PCLK_SEL;
+
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_PLL30_GEN_PLL, reg_val);
+ if (rc)
+ goto out;
+
+ /* PHY AFE30 Block */
+ addr = NS2_USB3_MDIO_P0_AFE30_ADDR;
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_BLK_ACCESS, addr);
+ if (rc)
+ goto out;
+
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_AFE30_RX_SIG_DETECT,
+ NS2_USB3_MDIO_AFE30_RX_SIG_DETECT_VAL);
+ if (rc)
+ goto out;
+
+ addr = NS2_USB3_MDIO_P1_AFE30_ADDR;
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_BLK_ACCESS, addr);
+ if (rc)
+ goto out;
+
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_AFE30_RX_SIG_DETECT,
+ NS2_USB3_MDIO_AFE30_RX_SIG_DETECT_VAL);
+ if (rc)
+ goto out;
+
+ /* PHY PIPE Block */
+ addr = NS2_USB3_MDIO_P0_PIPE_BLK_ADDR;
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_BLK_ACCESS, addr);
+ if (rc)
+ goto out;
+
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_PIPE_BLK_REG_1_OFFSET,
+ NS2_USB3_MDIO_PIPE_BLK_REG_1_VAL);
+ if (rc)
+ goto out;
+
+ addr = NS2_USB3_MDIO_P1_PIPE_BLK_ADDR;
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_BLK_ACCESS, addr);
+ if (rc)
+ goto out;
+
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_PIPE_BLK_REG_1_OFFSET,
+ NS2_USB3_MDIO_PIPE_BLK_REG_1_VAL);
+ if (rc)
+ goto out;
+
+ /* AEQ Block */
+ addr = NS2_USB3_MDIO_P0_AEQ_BLK_ADDR;
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_BLK_ACCESS, addr);
+ if (rc)
+ goto out;
+
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_AEQ_BLK_REG_1_OFFSET,
+ NS2_USB3_MDIO_AEQ_BLK_REG_1_VAL);
+ if (rc)
+ goto out;
+
+ /* PHY PORT_1 */
+ addr = NS2_USB3_MDIO_P1_AEQ_BLK_ADDR;
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_BLK_ACCESS, addr);
+ if (rc)
+ goto out;
+
+ rc = mdiobus_write(iphy->mphy->mdiodev->bus, iphy->mphy->mdiodev->addr,
+ NS2_USB3_MDIO_AEQ_BLK_REG_1_OFFSET,
+ NS2_USB3_MDIO_AEQ_BLK_REG_1_VAL);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_PLL_SEQ_START, true);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_PIPE_RESET, false);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_SOFT_RESET, false);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_PLL_RESET, false);
+ if (rc)
+ goto out;
+
+ rc = iproc_ns2_phy_action(iphy, PHY_PLL_STATUS, true);
+ if (rc)
+ goto out;
+
+ /* Set USB3H VBUS PPC Polarity and NandNor select */
+ rc = iproc_ns2_phy_action(iphy, PHY_VBUS_PPC, true);
+
+out:
+ iphy->mphy->init_count++;
+ mutex_unlock(&iphy->mphy->phy_mutex);
+
+ return rc;
+}
+
+static struct phy_ops ns2_usb3_phy_ops = {
+ .init = ns2_usb3_phy_init,
+ .exit = ns2_usb3_phy_exit,
+ .owner = THIS_MODULE,
+};
+
+static int ns2_usb3_phy_probe(struct mdio_device *mdiodev)
+{
+ struct device *dev = &mdiodev->dev;
+ struct device_node *dn = dev->of_node, *child;
+ struct ns2_usb3_phy_master *mphy;
+ struct phy_provider *provider;
+ int cnt;
+
+ mphy = devm_kzalloc(dev, sizeof(*mphy), GFP_KERNEL);
+ if (!mphy)
+ return -ENOMEM;
+ mphy->mdiodev = mdiodev;
+ mutex_init(&mphy->phy_mutex);
+ mphy->init_count = 0;
+
+ cnt = 0;
+ for_each_available_child_of_node(dn, child) {
+ struct ns2_usb3_phy *iphy;
+ unsigned int val;
+ struct regmap *io;
+
+ iphy = &mphy->iphys[cnt];
+ if (of_property_read_u32(child, "reg", &val)) {
+ dev_err(dev, "missing reg property in node %s\n",
+ child->name);
+ return -EINVAL;
+ }
+ iphy->port_no = val;
+ iphy->mphy = mphy;
+
+ io = syscon_regmap_lookup_by_phandle(dn, "usb3-ctrl-syscon");
+ if (IS_ERR(io))
+ return PTR_ERR(io);
+ iphy->reg_base[NS2_USB3_CTRL] = io;
+
+ io = syscon_regmap_lookup_by_phandle(dn, "usb3-phy-cfg-syscon");
+ if (IS_ERR(io))
+ return PTR_ERR(io);
+ iphy->reg_base[NS2_USB3_PHY_CFG] = io;
+
+ io = syscon_regmap_lookup_by_phandle(dn,
+ "usb3-rst-ctrl-syscon");
+ if (IS_ERR(io))
+ return PTR_ERR(io);
+ iphy->reg_base[NS2_USB3_RST_CTRL] = io;
+
+ iphy->phy = devm_phy_create(dev, child, &ns2_usb3_phy_ops);
+ if (IS_ERR(iphy->phy)) {
+ dev_err(dev, "failed to create PHY\n");
+ return PTR_ERR(iphy->phy);
+ }
+
+ phy_set_drvdata(iphy->phy, iphy);
+ cnt++;
+ }
+
+ dev_set_drvdata(dev, mphy);
+ provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ if (IS_ERR(provider)) {
+ dev_err(dev, "could not register PHY provider\n");
+ return PTR_ERR(provider);
+ }
+
+ dev_info(dev, "registered %d phy(s)\n", cnt);
+ return 0;
+}
+
+static const struct of_device_id ns2_usb3_phy_of_match[] = {
+ {.compatible = "brcm,ns2-usb3-phy",},
+ { /* sentinel */ }
+};
+
+static struct mdio_driver ns2_usb3_phy_driver = {
+ .mdiodrv = {
+ .driver = {
+ .name = "ns2-usb3-phy",
+ .of_match_table = ns2_usb3_phy_of_match,
+ },
+ },
+ .probe = ns2_usb3_phy_probe,
+};
+mdio_module_driver(ns2_usb3_phy_driver);
+
+MODULE_DESCRIPTION("Broadcom NS2 USB3 PHY driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Broadcom");
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: phy: Add documentation for NS2 USB3 PHY
From: Jon Mason @ 2017-04-28 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493411381-16833-1-git-send-email-jon.mason@broadcom.com>
From: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Add documentation for USB3 PHY available in NS2 SoC
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
.../devicetree/bindings/phy/brcm,ns2-usb3-phy.txt | 82 ++++++++++++++++++++++
1 file changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-usb3-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-usb3-phy.txt b/Documentation/devicetree/bindings/phy/brcm,ns2-usb3-phy.txt
new file mode 100644
index 0000000..5bb8d53
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,ns2-usb3-phy.txt
@@ -0,0 +1,82 @@
+Broadcom USB3 dual port phy for Northstar2 SoC
+This is a child bus node of "brcm,mdio-mux-iproc" node.
+
+Required mdio bus properties:
+- reg: MDIO Bus number for the MDIO interface
+- #address-cells: must be 1
+- #size-cells: must be 0
+
+Required PHY properties:
+- compatible: should be "brcm,ns2-usb3-phy"
+- reg: Phy address in the MDIO interface
+- usb3-ctrl-syscon: handler of syscon node defining physical address
+ of usb3 control register.
+- usb3-phy-cfg-syscon: handler of syscon node defining physical base
+ address and length of usb3 phy config region.
+- usb3-rst-ctrl-syscon: handler of syscon node defining physical base
+ address and length of idm reset control of two ports.
+- #phy-cells: must be 0
+- #address-cells: must be 1
+- #size-cells: must be 0
+
+Sub-nodes:
+ Each port's PHY should be represented as a sub-node.
+
+Sub-nodes required properties:
+ - reg: the PHY number
+ - phy-cells: from the generic PHY bindings, must be 0
+
+Required usb3 control properties:
+- compatible: should be "brcm,ns2-usb3-ctrl"
+- reg: offset and length of the control registers
+
+Required usb3 phy config properties:
+- compatible: should be "brcm,ns2-usb3-phy-cfg"
+- reg: offset and length of the phy config registers
+
+Required usb3 reset control properties:
+- compatible: should be "brcm,ns2-usb3-rst-ctrl"
+- reg: offset and length of the reset control registers
+
+Example:
+
+mdio at 1 {
+ reg = <0x1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb3phy: usb3phy at 0 {
+ compatible = "brcm,ns2-usb3-phy";
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ usb3-ctrl-syscon = <&usb3_ctrl>;
+ usb3-phy-cfg-syscon = <&usb3_phy_cfg>;
+ usb3-rst-ctrl-syscon = <&usb3_rst_ctrl>;
+
+ usb3phy0: usbphy at 0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ usb3phy1: usbphy at 1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+};
+
+usb3_ctrl: syscon at 6501d144 {
+ compatible = "brcm,ns2-usb3-ctrl", "syscon";
+ reg = <0x6501d144 0x4>;
+};
+
+usb3_phy_cfg: syscon at 66000910 {
+ compatible = "brcm,ns2-usb3-phy-cfg", "syscon";
+ reg = <0x66000910 0x14>;
+};
+
+usb3_rst_ctrl: syscon at 67000800 {
+ compatible = "brcm,ns2-usb3-rst-ctrl", "syscon";
+ reg = <0x67000800 0x1808>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] USB3 support for Broadcom NS2 SoC
From: Jon Mason @ 2017-04-28 20:29 UTC (permalink / raw)
To: linux-arm-kernel
This patch set contains the USB3 support for Broadcom NS2 SoC. The USB3
PHY is connected through the MDIO interface.
Yendapally Reddy Dhananjaya Reddy (3):
dt-bindings: phy: Add documentation for NS2 USB3 PHY
phy: Add USB3 PHY support for Broadcom NS2 SoC
arm64: dts: ns2: Add USB3 Support
.../devicetree/bindings/phy/brcm,ns2-usb3-phy.txt | 82 +++
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 16 +
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 8 +
arch/arm64/boot/dts/broadcom/ns2.dtsi | 62 +++
drivers/phy/Kconfig | 9 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-bcm-ns2-usb3.c | 596 +++++++++++++++++++++
7 files changed, 774 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-usb3-phy.txt
create mode 100644 drivers/phy/phy-bcm-ns2-usb3.c
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Rob Herring @ 2017-04-28 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425235357.7690-1-eric@anholt.net>
On Tue, Apr 25, 2017 at 04:53:56PM -0700, Eric Anholt wrote:
> Cygnus is a small family of SoCs, of which we currently have
> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
> same as 58xx, just requiring a tiny bit of setup that was previously
> missing.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>
> v2: Reorder the entry in the docs (suggestion by Scott Branden), add
> missing '"'
>
> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
> drivers/net/dsa/b53/b53_srab.c | 2 ++
> 2 files changed, 5 insertions(+)
Everyone learns the hard way that specific compatibles are needed.
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH v3 3/3] ARM: dts: NSP: Add Thermal Support
From: Jon Mason @ 2017-04-28 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493410291-16679-1-git-send-email-jon.mason@broadcom.com>
Add thermal support via the ns-thermal driver and create a single
thermal zone for the entire SoC.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 832795b..be6fcfb 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -383,6 +383,12 @@
<0x3f408 0x04>;
};
+ thermal: thermal at 3f2c0 {
+ compatible = "brcm,ns-thermal";
+ reg = <0x3f2c0 0x10>;
+ #thermal-sensor-cells = <0>;
+ };
+
sata_phy: sata_phy at 40100 {
compatible = "brcm,iproc-nsp-sata-phy";
reg = <0x40100 0x340>;
@@ -533,4 +539,24 @@
brcm,pcie-msi-inten;
};
};
+
+ thermal-zones {
+ cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ coefficients = <(-556) 418000>;
+ thermal-sensors = <&thermal>;
+
+ trips {
+ cpu-crit {
+ temperature = <125000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ };
+ };
+ };
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs
From: Jon Mason @ 2017-04-28 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493410291-16679-1-git-send-email-jon.mason@broadcom.com>
Tweak the Kconfig description to mention support for NSP and make the
default on for iProc based platforms.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
drivers/thermal/broadcom/Kconfig | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
index f0dea8a..b6f4b85 100644
--- a/drivers/thermal/broadcom/Kconfig
+++ b/drivers/thermal/broadcom/Kconfig
@@ -1,8 +1,9 @@
config BCM_NS_THERMAL
tristate "Northstar thermal driver"
depends on ARCH_BCM_IPROC || COMPILE_TEST
+ default y if ARCH_BCM_IPROC
help
- Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
- BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
- with a thermal sensor that allows checking CPU temperature. This
- driver provides support for it.
+ Support for the Northstar and Northstar Plus family of SoCs (e.g.
+ BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
+ Management Unit) block with a thermal sensor that allows checking CPU
+ temperature.
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] ARM: BCM: Enable thermal support for NSP SoCs
From: Jon Mason @ 2017-04-28 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493410291-16679-1-git-send-email-jon.mason@broadcom.com>
Change the Northstar Plus Kconfig to select THERMAL and THERMAL_OF,
which allows the ns-thermal driver to be selected via menuconfig.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm/mach-bcm/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index a0e66d8..93a61d0 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -44,6 +44,8 @@ config ARCH_BCM_NSP
select ARM_ERRATA_775420
select ARM_ERRATA_764369 if SMP
select HAVE_SMP
+ select THERMAL
+ select THERMAL_OF
help
Support for Broadcom Northstar Plus SoC.
Broadcom Northstar Plus family of SoCs are used for switching control
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/3] thermal: broadcom: Add NSP Thermal Support
From: Jon Mason @ 2017-04-28 20:11 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v3:
* Enable THERMAL on NSP, not all iProc Chips (per Scott Branden)
* Correct the Kconfig syntax in patch 2 (per Eduardo Valentin)
Changes in v2:
* Split SoC enablement into a separate patch (per Eduardo Valentin)
* Added Eduardo Valentin's Acked-by to the DTS patch
This adds support for NSP to the existing Northstar thermal driver.
This code is based on patches currently in the Linux SoC Thermal git
tree. Specfically,
https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=linus&id=a94cb7eeecc4104a6874339f90c5d0647359c102
Jon Mason (3):
ARM: BCM: Enable thermal support for NSP SoCs
thermal: broadcom: ns-thermal: default on iProc SoCs
ARM: dts: NSP: Add Thermal Support
arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++++++++++++++++++++++++++
arch/arm/mach-bcm/Kconfig | 2 ++
drivers/thermal/broadcom/Kconfig | 9 +++++----
3 files changed, 33 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Rob Herring @ 2017-04-28 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9349c8ae9091fbd93e9410f4cfae770ac850bf6b.1493125299.git.guillaume.tucker@collabora.com>
On Tue, Apr 25, 2017 at 02:16:16PM +0100, Guillaume Tucker wrote:
> The ARM Mali Midgard GPU family is present in a number of SoCs
> from many different vendors such as Samsung Exynos and Rockchip.
>
> Import the device tree bindings documentation from the r16p0
> release of the Mali Midgard GPU kernel driver:
>
> https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
>
> Remove the copyright and GPL licence header as deemed not necessary.
>
> Redesign the "compatible" property strings to list all the Mali
> Midgard GPU types and include optional vendor ones.
>
> Drop the "clock-names" property as only one clock is used by the Mali
> Midgard driver (which now needs to call clk_get with NULL).
>
> Convert the "interrupt-names" property values to lower-case: "job",
> "mmu" and "gpu".
>
> Replace the deprecated "operating-points" optional property with
> "operating-points-v2".
>
> Omit the following optional properties in this initial version as they
> are only used in very specific cases:
>
> * snoop_enable_smc
> * snoop_disable_smc
> * jm_config
> * power_model
> * system-coherency
> * ipa-model
>
> Update the example accordingly to reflect all these changes.
>
> CC: John Reitan <john.reitan@arm.com>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> ---
> .../devicetree/bindings/gpu/arm,mali-midgard.txt | 82 ++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> new file mode 100644
> index 000000000000..547ddeceb498
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -0,0 +1,82 @@
> +ARM Mali Midgard GPU
> +====================
> +
> +Required properties:
> +
> +- compatible :
> + * Must be one of the following:
> + + "arm,mali-t60x"
> + + "arm,mali-t62x"
Don't use wildcards.
> + + "arm,mali-t720"
> + + "arm,mali-t760"
> + + "arm,mali-t820"
> + + "arm,mali-t830"
> + + "arm,mali-t860"
> + + "arm,mali-t880"
> + * And, optionally, one of the vendor specific compatible:
IMO, these should not be optional.
> + + "amlogic,meson-gxm-mali"
> + + "rockchip,rk3288-mali"
^ permalink raw reply
* [PATCH v2] arm64: Add ASM modifier for xN register operands
From: Matthias Kaehlcke @ 2017-04-28 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170428143333.GA5292@leverpostej>
El Fri, Apr 28, 2017 at 03:33:33PM +0100 Mark Rutland ha dit:
> On Fri, Apr 28, 2017 at 08:18:52AM +0100, Ard Biesheuvel wrote:
> > On 27 April 2017 at 23:52, Matthias Kaehlcke <mka@chromium.org> wrote:
> > > El Thu, Apr 27, 2017 at 12:02:56PM +0100 Mark Rutland ha dit:
> > >> On Wed, Apr 26, 2017 at 02:46:16PM -0700, Matthias Kaehlcke wrote:
> > >> > Many inline assembly statements don't include the 'x' modifier when
> > >> > using xN registers as operands. This is perfectly valid, however it
> > >> > causes clang to raise warnings like this:
> > >> >
> > >> > warning: value size does not match register size specified by the
> > >> > constraint and modifier [-Wasm-operand-widths]
>
> [...]
>
> > >> > - asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
> > >> > + asm volatile("strb %w0, [%x1]" : : "rZ" (val), "r" (addr));
> > >>
> > >> In general, the '[%xN]' pattern looks *very* suspicious to me. Any
> > >> address must be 64-bit, so this would mask a legitimate warning.
> > >>
> > >> Given the prototype of this function the code if fine either way, but
> > >> were we to refactor things (e.g. making this a macro), that might not be
> > >> true.
> > >>
> > >> ... so I'm not sure it make sense to alter instances used for addresses.
> > >
> > > Good point, I'll leave instances dealing with addresses untouched for now.
> > >
> >
> > OK, I am confused now. We started this thread under the assumption
> > that all unqualified placeholders are warned about by Clang. Given
> > that this appears not to be the case, could we please first find out
> > what causes the warnings? Is it necessary at all to add the x
> > modifiers for 64-bit types?
>
> FWIW, I grabbed a clang 4.0.0 binary and had a play.
>
> It looks like clang only warns when an operand is less than 64 bits
> wide, and there is no 'x' or 'w' modifier. Pointers a 64 bits wide, so
> never produce a warning.
>
> As far as I can tell, applying to both integers and pointers:
>
> * GCC and clang always treat %N as meaning xN for an r constraint, and
> you need to use %wN to get wN.
>
> * If an operand type is 64 bits in size, clang will not produce a warning
> regarding the operand size.
>
> * If an x or w modifier is used, clang will not produce a warning
> regarding the operand size, regardless of whether it matches the
> register size. Clang is happy for %wN to be used on a pointer type.
>
> * If an operand type is less than 64 bits in size, and neither an x or
> w modifier is used, clang will produce a warning as above.
>
> * If an operand type is greater than 64 bits in size, clang encounters
> an internal error.
>
> Given that, I think we *should not* use the x modifier to suppress this
> warning, as I think for those cases we have a potential bug as outlined
> in my prior reply.
>
> Instead, we should use a temporary 64-bit variable (or cast input
> operands to 64-bit), which avoids that and makes clang happy.
>
> I've included my test below. Note that clang will produce other errors for
> invalid asm (e.g. for mov w0, x0).
Thanks for your investigation!
I apologize for the noise, my expertise with inline assembly is
extremely limited, and admittedly I need a bit of handholding in this
area. Not without reason changes like this or the prefetch code are at
the very top of my clang stack (i.e. postponed until the other less
scary issues were solved). Hopefully the discussion was still useful.
I'll prepare a short patch that only fixes the warnings encountered in
my build in the way you suggested.
Thanks
Matthias
^ permalink raw reply
* [PATCH 4/5] arm64: dts: Add ipq8074 SoC and MTP board support
From: Jonathan Neuschäfer @ 2017-04-28 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493373403-23462-5-git-send-email-varada@codeaurora.org>
Hi,
On Fri, Apr 28, 2017 at 03:26:42PM +0530, Varadarajan Narayanan wrote:
> Subject: [PATCH 4/5] arm64: dts: Add ipq8074 SoC and MTP board support
s/MTP/HK01/ ?
> Add initial device tree support for the Qualcomm IPQ8074 SoC and
> HK01 evaluation board.
>
> Signed-off-by: Manoharan Vijaya Raghavan <mraghava@codeaurora.org>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 48 ++++++++++
> arch/arm64/boot/dts/qcom/ipq8074.dtsi | 153 ++++++++++++++++++++++++++++++
> 3 files changed, 202 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
> create mode 100644 arch/arm64/boot/dts/qcom/ipq8074.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index cc0f02d..7c6963e 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8992-bullhead-rev-101.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8994-angler-rev-101.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += ipq8074-hk01.dtb
Maybe this list should be alphabetically sorted ('i' before 'm').
(I have no strong preference)
Thanks,
Jonathan Neusch?fer
-------------- 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/20170428/00469211/attachment.sig>
^ permalink raw reply
* [PATCH 4/5] arm64: dts: Add ipq8074 SoC and MTP board support
From: Stephen Boyd @ 2017-04-28 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493373403-23462-5-git-send-email-varada@codeaurora.org>
On 04/28, Varadarajan Narayanan wrote:
> diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
> new file mode 100644
> index 0000000..c150bea
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
> @@ -0,0 +1,48 @@
> +/dts-v1/;
> +/* Copyright (c) 2017, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include "ipq8074.dtsi"
> +
> +/ {
> + #address-cells = <0x2>;
> + #size-cells = <0x2>;
> + model = "Qualcomm Technologies, Inc. IPQ8074-HK01";
> + compatible = "qcom,ipq8074-hk01", "qcom,ipq8074";
> + interrupt-parent = <&intc>;
> +
> + chosen {
> + bootargs = "console=ttyMSM0,115200,n8 root=/dev/ram0 rw init=/init";
Add an aliases node for serial0 and use a chosen node with stdout-path = "serial0" instead please.
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x40000000 0x0 0x20000000>;
> + };
> +
> + soc: soc {
Do you need the soc label here? Please remove.
> + pinctrl at 1000000 {
> + serial_4_pins: serial4_pinmux {
> + mux {
> + pins = "gpio23", "gpio24";
> + function = "blsp4_uart1";
> + bias-disable;
> + };
> + };
> + };
> +
> + serial at 78b3000 {
> + pinctrl-0 = <&serial_4_pins>;
> + pinctrl-names = "default";
> + status = "ok";
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> new file mode 100644
> index 0000000..f910cc0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> @@ -0,0 +1,153 @@
> +/*
> + * Copyright (c) 2017, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/qcom,gcc-ipq8074.h>
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. IPQ8074";
> + compatible = "qcom,ipq8074";
> +
> + soc: soc {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + ranges = <0 0 0 0xffffffff>;
> + compatible = "simple-bus";
> +
> + pinctrl at 1000000 {
> + compatible = "qcom,ipq8074-pinctrl";
> + reg = <0x1000000 0x300000>;
> + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + #gpio-cells = <0x2>;
> + interrupt-controller;
> + #interrupt-cells = <0x2>;
> + };
> +
> + intc: interrupt-controller at b000000 {
> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> + #interrupt-cells = <0x3>;
> + reg = <0xb000000 0x1000>,
> + <0xb002000 0x1000>;
Please align this up with previous reg property.
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 3 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 4 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 1 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> + };
Is there an mmio timer as well? We should add it too.
> +
> + gcc: gcc at 1800000 {
> + compatible = "qcom,gcc-ipq8074";
> + reg = <0x1800000 0x80000>;
Wow that is a huge area! Is it really that large?
> + #clock-cells = <0x1>;
> + #reset-cells = <0x1>;
> + };
> +
> + serial at 78b3000 {
> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> + reg = <0x78b3000 0x200>;
> + interrupts = <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&gcc GCC_BLSP1_UART5_APPS_CLK>,
> + <&gcc GCC_BLSP1_AHB_CLK>;
> + clock-names = "core", "iface";
> + status = "disabled";
> + };
> + };
> +
> + cpus {
> + #address-cells = <0x1>;
> + #size-cells = <0x0>;
> +
> + cpu-map {
> +
> + cluster0 {
> +
> + core0 {
> + cpu = <&CPU0>;
> + };
> +
> + core1 {
> + cpu = <&CPU1>;
> + };
> +
> + core2 {
> + cpu = <&CPU2>;
> + };
> +
> + core3 {
> + cpu = <&CPU3>;
> + };
> + };
> + };
Is this needed? Looks ok, but just curious if we need to do it
for other arm64 platforms we support.
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0>;
> + next-level-cache = <&L2_0>;
> + enable-method = "psci";
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x1>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + CPU2: cpu at 2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x2>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + CPU3: cpu at 3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x3>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + L2_0: l2-cache {
> + compatible = "cache";
> + cache-level = <0x2>;
> + };
This should be inside some CPU? CPU0?
> + };
We should be able to add the performance monitor node too?
> +
> + psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> +
> + clocks {
> + sleep_clk: sleep_clk {
> + compatible = "fixed-clock";
> + clock-frequency = <32000>;
Not 32765 or 32768?
> + #clock-cells = <0>;
> + };
> +
> + xo: xo {
> + compatible = "fixed-clock";
> + clock-frequency = <19200000>;
> + #clock-cells = <0>;
> + };
> + };
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
From: Casey Leedom @ 2017-04-28 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493369471.13947.11.camel@pengutronix.de>
| From: Lucas Stach <l.stach@pengutronix.de>
| Sent: Friday, April 28, 2017 1:51 AM
|
| Am Donnerstag, den 27.04.2017, 12:19 -0500 schrieb Bjorn Helgaas:
| >
| >
| > I thought Relaxed Ordering was an optimization. Are there cases where
| > it is actually required for correct behavior?
|
| Yes, at least the Tegra 2 TRM claims that RO needs to be enabled on the
| device side for correct operation with the following language:
|
| "Tegra 2 requires relaxed ordering for responses to downstream requests
| (responses can pass writes). It is possible in some circumstances for PCIe
| transfers from an external bus masters (i.e. upstream transfers) to become
| blocked by a downstream read or non-posted write. The responses to these
| downstream requests are blocked by upstream posted writes only when PCIe
| strict ordering is imposed. It is therefore necessary to never impose strict
| ordering that would block a response to a downstream NPW/read request and
| always set the relaxed ordering bit to 1. Only devices that are capable of
| relaxed ordering may be used with Tegra 2 devices."
(woof) Reading through the above paragraph is difficult because the author
seems to shift language and terminology mid sentence and isn't following
standard PCI terminology conventions. The Root Complex is "Upstream", a
non-Root Complex Node in the PCIe Fabric is "Downstream", Requests that a
Downstream Device (End Point) send to the Root Complex are called "Upstream
Requests", responses that the Root Complex send to a Device are called
"Downstream Responses" (or, even more pedantically, "Responses sent
Downstream for an earlier Upstream Request").
Because a Root Complex is Upstream, but the Requests it sent Downstream,
and Downstream Devices send their Requests Upstream, it's very important
that we use exceedingly precise language.
So, it ~sounds like~ the nVidia Tegra 2 document is talking about the need
for Downstream Devices to echo the Relaxed Ordering Attribute in their
Responses directed Upstream to Requests sent Downstream from the Root
Complex. Moreover, there's code in drivers/pci/host/pci-tegra.c:
tegra_pcie_relax_enable() which appears to set the PCIe Capability Device
Control[Enable Relaxed Ordering] bit on all PCIe Fabric Nodes.
If my reading of the intent of the nVidia document is correct -- and
that's a Big If because of the extremely imprecise language used -- that
means that the tegra_pcie_relax_enable() is completely bogus. The PCIe 3.0
Specification states that Responses MUST reflect the Relaxed Ordering and No
Snoop Attributes of the Requests for which they are responding. Section
2.2.9 of PCI Express(r) Base Specification Revision 3.0 November 10, 2010:
"Completion headers must supply the same values for the Attribute as were
supplied in the header of the corresponding Request, except as explicitly
allowed when IDO is used."
And, specifically, the PCIe Capability Device Control[Enable Relaxed
Ordering] bit _only_ affects the ability of that Device to originate
Transaction Layer Packet Requests with the Relaxed Ordering Attribute set.
Thus, tegra_pcie_relax_enable() setting those bits on all the Downstream
Devices (and intervening Bridges) does not _cause_ those Devices to generate
Requests with Relaxed Ordering set. And, if the Devices are PCIe 3.0
compliant, it also doesn't affect the Responses that they send back Upstream
to the Root Complex.
I apologize for the incredibly detailed nature of these responses, but
it's very easy for people new to PCIe to get these things wrong and/or
misinterpret the PCIe Specifications.
Casey
^ permalink raw reply
* [PATCH 1/2] reset: Add DT bindings for the Gemini reset controller
From: Rob Herring @ 2017-04-28 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424192746.27378-1-linus.walleij@linaro.org>
On Mon, Apr 24, 2017 at 09:27:46PM +0200, Linus Walleij wrote:
> This is a simple reset controller in a single 32bit
> register.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> .../bindings/reset/cortina,gemini-reset.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> new file mode 100644
> index 000000000000..21aa12901774
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
> @@ -0,0 +1,59 @@
> +Cortina Gemini Reset Controller
> +
> +This reset controller is found in Cortina Systems CS3516 and
> +the predecessor StorLink SL3516.
> +
> +Required properties:
> +- compatible: "cortina,gemini-reset"
> +- #reset-cells: Must be 1
> +
> +The Gemini reset controller must be a child node of the
> +system controller. Apart from this it follows the standard reset
> +controller bindings.
Same comment as clocks. The parent can be the provider.
> +
> +Valid reset line values:
> +
> +0: DRAM controller
Why no header like clocks?
> +1: Flash controller
> +2: IDE controller
> +3: RAID controller
> +4: Security module
> +5: GMAC0 (ethernet)
> +6: GMAC1 (ethernet)
> +7: PCI host bridge
> +8: USB0 USB host controller
> +9: USB1 USB host controller
> +10: General DMA controller
> +11: APB bridge
> +12: LPC (Low Pin Count) controller
> +13: LCD module
> +14: Interrupt controller 0
> +15: Interrupt controller 1
> +16: RTC module
> +17: Timer module
> +18: UART controller
> +19: SSP controller
> +20: GPIO0 GPIO controller
> +21: GPIO1 GPIO controller
> +22: GPIO2 GPIO controller
> +23: Watchdog timer
> +24: External device reset
> +25: CIR module (infrared)
> +26: SATA0 SATA bridge
> +27: SATA1 SATA bridge
> +28: TVE TV Encoder module
> +29: Reserved
> +30: CPU1 reset
> +31: Global soft reset
> +
> +Example:
> +
> +syscon: syscon at 40000000 {
> + compatible = "cortina,gemini-syscon", "syscon", "simple-mfd";
> + reg = <0x40000000 0x1000>;
> +
> + reset-controller {
> + compatible = "cortina,gemini-reset";
> + #reset-cells = <1>;
> + };
> +};
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] clk: Add bindings for the Gemini Clock Controller
From: Rob Herring @ 2017-04-28 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424185545.26608-1-linus.walleij@linaro.org>
On Mon, Apr 24, 2017 at 08:55:45PM +0200, Linus Walleij wrote:
> This adds device tree bindings and a header for the Gemini SoC
> Clock Controller.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> .../clock/cortina,gemini-clock-controller.txt | 25 +++++++++++++++++++
> include/dt-bindings/clock/cortina,gemini-clock.h | 29 ++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
> create mode 100644 include/dt-bindings/clock/cortina,gemini-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
> new file mode 100644
> index 000000000000..7af84acfcbce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
> @@ -0,0 +1,25 @@
> +Clock bindings for the Cortina Systems Gemini SoC Clock Controller
> +
> +Required properties :
> +- compatible : shall contain the following:
> + "cortina,gemini-clock-controller"
> +- #clock-cells should be <1>
> +
> +The Gemini clock controller needs to be placed as a subnode of the
> +system controller.
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/cortina,gemini-clock.h header and can be used in device
> +tree sources.
> +
> +Example:
> +
> +syscon: syscon at 40000000 {
> + compatible = "cortina,gemini-syscon", "syscon", "simple-mfd";
> + reg = <0x40000000 0x1000>;
> +
> + clock-controller {
> + compatible = "cortina,gemini-clock-controller";
> + #clock-cells = <1>;
There's not really much reason to have a child node here. The parent can
be the clock provider.
Rob
^ permalink raw reply
* [PATCH v2 1/3] ARM: BCM: Enable thermal support for iProc SoCs
From: Jon Mason @ 2017-04-28 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bceb9b66-c769-faf3-9288-26581b5d5dc6@broadcom.com>
On Thu, Apr 27, 2017 at 7:10 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
>
>
> On 17-04-27 02:23 PM, Jon Mason wrote:
>>
>> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
>> the ns-thermal driver to be selected via menuconfig.
>>
>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>> ---
>> arch/arm/mach-bcm/Kconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index a0e66d8..da2bfeb 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
>> select GPIOLIB
>> select ARM_AMBA
>> select PINCTRL
>> + select THERMAL
>> + select THERMAL_OF
>
> This is NSP specific at this point. Also, If it increases code size in any
> way it shouldn't be selected for all IPROC SoCS. I'd rather this was just
> selected via defconfig
This isn't selectable via menuconfig without being in the kconfig.
I'll move it to the NSP portion of the kconfig, as to not increase the
size of other's kernels.
Thanks,
Jon
>
>> help
>> This enables support for systems based on Broadcom IPROC
>> architected SoCs.
>> The IPROC complex contains one or more ARM CPUs along with
>> common
>>
>
^ permalink raw reply
* [PATCH 1/2] thermal: broadcom: Allow for NSP to use ns-thermal driver
From: Jon Mason @ 2017-04-28 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170428130659.GA28546@localhost.localdomain>
On Fri, Apr 28, 2017 at 9:07 AM, Eduardo Valentin <edubezval@gmail.com> wrote:
> On Thu, Apr 27, 2017 at 01:42:25PM -0400, Jon Mason wrote:
>> On Thu, Apr 27, 2017 at 12:37 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
>> > Hey Jason,
>>
>> It's Jon :)
>
> Apologies. I think I either read too fast, or my fingers were faster
> than my brain. Sorry.
NP, That exact error happens more frequently that you would think :)
>>
>> >
>> > On Tue, Apr 25, 2017 at 04:49:10PM -0400, Jon Mason wrote:
>> >> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
>> >> the ns-thermal driver to be selected via menuconfig. Also, change the
>> >> ns-thermal driver to work on any iProc based SoC. Finally, tweak the
>> >> Kconfig description to mention support for NSP and make the default on
>> >> for iProc based platforms.
>> >
>> >
>> > Thanks for the patch, but..
>> >>
>> >> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>> >> ---
>> >> arch/arm/mach-bcm/Kconfig | 2 ++
>> >> drivers/thermal/broadcom/Kconfig | 9 +++++----
>> >> 2 files changed, 7 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> >> index a0e66d8..da2bfeb 100644
>> >> --- a/arch/arm/mach-bcm/Kconfig
>> >> +++ b/arch/arm/mach-bcm/Kconfig
>> >> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
>> >> select GPIOLIB
>> >> select ARM_AMBA
>> >> select PINCTRL
>> >> + select THERMAL
>> >> + select THERMAL_OF
>> >> help
>> >> This enables support for systems based on Broadcom IPROC architected SoCs.
>> >> The IPROC complex contains one or more ARM CPUs along with common
>> >
>> > It would be better if this is split and sent through your arch tree, to
>> > avoid conflicts. I could also pick it if you get an ack from one of your
>> > maintainers. Still, first option is preferable.
>>
>> Sure, I'll be happy to split this off. I should've thought to split
>> it up before sending. Thanks for the suggestion.
>
> Cool!
>
>>
>> >
>> >> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
>> >> index f0dea8a..26d706c 100644
>> >> --- a/drivers/thermal/broadcom/Kconfig
>> >> +++ b/drivers/thermal/broadcom/Kconfig
>> >> @@ -1,8 +1,9 @@
>> >> config BCM_NS_THERMAL
>> >> tristate "Northstar thermal driver"
>> >> depends on ARCH_BCM_IPROC || COMPILE_TEST
>> >> + default ARCH_BCM_IPROC
>> >
>> > Not sure if this is really what you wanted. Based on your commit log
>> > message, you meant the following, perhaps?
>> >
>> > + default y if ARCH_BCM_IPROC
>>
>> IIUC, my original default works, as we have used it frequently in
>> other places in the kernel.
>> grep -rI "default ARCH_BCM_IPROC" * | wc -l
>> 15
>
> Yeah... Are you sure they are all correct?
>
>>
>> However, if the above is preferred (or the other 15 massively broken),
>> I'll be happy to do it that way.
>
> Your construction is syntactically correct. Maybe might still work (did
> not check myself) for the purpose you describe, but the construction
> mentioned in Documentation/kbuild/kconfig-language.txt is:
> + default y if BAR
>
> So, please fix it.
Oh, thanks for the info. I was unaware of this, and we should
definitely follow the documentation.. I'll make the relevant changes
and do follow-on patches to correct the other places.
>
>>
>>
>> >> help
>> >> - Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
>> >> - BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
>> >> - with a thermal sensor that allows checking CPU temperature. This
>> >> - driver provides support for it.
>> >> + Support for the Northstar and Northstar Plus family of SoCs (e.g.
>> >> + BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
>> >
>> > Did we look BCM47094 somehow on this patch?
>>
>> Naa, just trying to be more concise, while adding the NSP products to
>> the list.. BCM47094 is a type of BCM4709. So, it is still there :)
>>
>> >
>> >> + Management Unit) block with a thermal sensor that allows checking CPU
>> >> + temperature.
>> >> --
>> >> 2.7.4
>> >>
^ permalink raw reply
* [PATCH 1/3 v2] xen: Export xen_reboot
From: Juergen Gross @ 2017-04-28 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7396d142-98b0-9554-4cbd-477bb9e2f8e5@suse.com>
On 25/04/17 06:02, Juergen Gross wrote:
> On 24/04/17 20:21, Boris Ostrovsky wrote:
>> On 04/24/2017 01:58 PM, Julien Grall wrote:
>>> The helper xen_reboot will be called by the EFI code in a later patch.
>>>
>>> Note that the ARM version does not yet exist and will be added in a
>>> later patch too.
>>>
>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>
>> I don't think these changes are worth a whole patch. They can be folded
>> into the third patch.
>
> No, the 2nd patch needs this, too.
>
> So:
>
> Reviewed-by: Juergen Gross <jgross@suse.com>
Julien, this patch no longer applies to the for-linus-4.12 branch of
xen/tip. Can you please rebase?
Juergen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox