* [PATCH 08/13] arm64: dts: rockchip: remove unused pin settings from px30
From: Heiko Stuebner @ 2019-09-17 8:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, devicetree, Heiko Stuebner, linux-kernel,
linux-rockchip, robh+dt, christoph.muellner
In-Reply-To: <20190917082659.25549-1-heiko@sntech.de>
These are unused gpio-settings for specific function pins, that
are not used by anything and only clutter up the dtsi.
They can be re-added when a relevant user is added.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 40 --------------------------
1 file changed, 40 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index f2bbdfa0e4aa..63499d27994c 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1159,11 +1159,6 @@
rockchip,pins =
<0 RK_PB5 1 &pcfg_pull_none>;
};
-
- uart0_rts_gpio: uart0-rts-gpio {
- rockchip,pins =
- <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
- };
};
uart1 {
@@ -1182,11 +1177,6 @@
rockchip,pins =
<1 RK_PC3 1 &pcfg_pull_none>;
};
-
- uart1_rts_gpio: uart1-rts-gpio {
- rockchip,pins =
- <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
- };
};
uart2-m0 {
@@ -1221,11 +1211,6 @@
rockchip,pins =
<0 RK_PC3 2 &pcfg_pull_none>;
};
-
- uart3m0_rts_gpio: uart3m0-rts-gpio {
- rockchip,pins =
- <0 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
- };
};
uart3-m1 {
@@ -1244,11 +1229,6 @@
rockchip,pins =
<1 RK_PB5 2 &pcfg_pull_none>;
};
-
- uart3m1_rts_gpio: uart3m1-rts-gpio {
- rockchip,pins =
- <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
- };
};
uart4 {
@@ -1597,16 +1577,6 @@
<1 RK_PD4 1 &pcfg_pull_up_8ma>,
<1 RK_PD5 1 &pcfg_pull_up_8ma>;
};
-
- sdmmc_gpio: sdmmc-gpio {
- rockchip,pins =
- <1 RK_PD2 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
- <1 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
- <1 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
- <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
- <1 RK_PD6 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
- <1 RK_PD7 RK_FUNC_GPIO &pcfg_pull_up_4ma>;
- };
};
sdio {
@@ -1627,16 +1597,6 @@
<1 RK_PD0 1 &pcfg_pull_up>,
<1 RK_PD1 1 &pcfg_pull_up>;
};
-
- sdio_gpio: sdio-gpio {
- rockchip,pins =
- <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>,
- <1 RK_PC7 RK_FUNC_GPIO &pcfg_pull_up>,
- <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_up>,
- <1 RK_PD1 RK_FUNC_GPIO &pcfg_pull_up>,
- <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_up>,
- <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
- };
};
emmc {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 10/13] arm64: dts: rockchip: add px30-evb i2c1 devices
From: Heiko Stuebner @ 2019-09-17 8:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, devicetree, Heiko Stuebner, linux-kernel,
linux-rockchip, robh+dt, christoph.muellner
In-Reply-To: <20190917082659.25549-1-heiko@sntech.de>
Enable i2c1 and adds the devices connected to it.
This includes a magnetometer, goodix-touchscreen and accelerometer.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/px30-evb.dts | 37 +++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30-evb.dts b/arch/arm64/boot/dts/rockchip/px30-evb.dts
index 80524afe94da..1185a314ba4a 100644
--- a/arch/arm64/boot/dts/rockchip/px30-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/px30-evb.dts
@@ -349,6 +349,43 @@
};
};
+&i2c1 {
+ status = "okay";
+
+ sensor@d {
+ compatible = "asahi-kasei,ak8963";
+ reg = <0x0d>;
+ gpios = <&gpio0 RK_PB7 GPIO_ACTIVE_HIGH>;
+ vdd-supply = <&vcc3v0_pmu>;
+ mount-matrix = "1", /* x0 */
+ "0", /* y0 */
+ "0", /* z0 */
+ "0", /* x1 */
+ "1", /* y1 */
+ "0", /* z1 */
+ "0", /* x2 */
+ "0", /* y2 */
+ "1"; /* z2 */
+ };
+
+ touchscreen@14 {
+ compatible = "goodix,gt1151";
+ reg = <0x14>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA5 IRQ_TYPE_LEVEL_LOW>;
+ irq-gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
+ VDDIO-supply = <&vcc3v3_lcd>;
+ };
+
+ sensor@4c {
+ compatible = "fsl,mma7660";
+ reg = <0x4c>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB7 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
&i2s1_2ch {
status = "okay";
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 09/13] arm64: dts: rockchip: document explicit px30 cru dependencies
From: Heiko Stuebner @ 2019-09-17 8:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, devicetree, Heiko Stuebner, linux-kernel,
linux-rockchip, robh+dt, christoph.muellner
In-Reply-To: <20190917082659.25549-1-heiko@sntech.de>
The px30 contains 2 separate clock controllers the regular cru creating
most clocks as well as the pmucru managing the GPLL and some other clocks.
The gpll of course also is needed by the cru, so while we normally do rely
on clock names to associate clocks getting probed later on (for example
xin32k coming from an i2c device in most cases) it is safer to declare the
explicit dependency between the two crus. This makes sure that for example
the clock-framework probes them in the correct order from the start.
The assigned-clocks properties were simply working by chance in the past
so split them accordingly to the 2 crus to honor the loading direction.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../bindings/clock/rockchip,px30-cru.txt | 5 ++++
arch/arm64/boot/dts/rockchip/px30.dtsi | 25 +++++++++++--------
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
index 39f0c1ac84ee..55e78cddec8c 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
+++ b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
@@ -10,6 +10,11 @@ Required Properties:
- compatible: CRU should be "rockchip,px30-cru"
- reg: physical base address of the controller and length of memory mapped
region.
+- clocks: A list of phandle + clock-specifier pairs for the clocks listed
+ in clock-names
+- clock-names: Should contain the following:
+ - "xin24m" for both PMUCRU and CRU
+ - "gpll" for CRU (sourced from PMUCRU)
- #clock-cells: should be 1.
- #reset-cells: should be 1.
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 63499d27994c..9ad1c2f04ea9 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -667,33 +667,38 @@
cru: clock-controller@ff2b0000 {
compatible = "rockchip,px30-cru";
reg = <0x0 0xff2b0000 0x0 0x1000>;
+ clocks = <&xin24m>, <&pmucru PLL_GPLL>;
+ clock-names = "xin24m", "gpll";
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
- assigned-clocks = <&cru PLL_NPLL>;
- assigned-clock-rates = <1188000000>;
+ assigned-clocks = <&cru PLL_NPLL>,
+ <&cru ACLK_BUS_PRE>, <&cru ACLK_PERI_PRE>,
+ <&cru HCLK_BUS_PRE>, <&cru HCLK_PERI_PRE>,
+ <&cru PCLK_BUS_PRE>, <&cru SCLK_GPU>;
+
+ assigned-clock-rates = <1188000000>,
+ <200000000>, <200000000>,
+ <150000000>, <150000000>,
+ <100000000>, <200000000>;
};
pmucru: clock-controller@ff2bc000 {
compatible = "rockchip,px30-pmucru";
reg = <0x0 0xff2bc000 0x0 0x1000>;
+ clocks = <&xin24m>;
+ clock-names = "xin24m";
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
assigned-clocks =
<&pmucru PLL_GPLL>, <&pmucru PCLK_PMU_PRE>,
- <&pmucru SCLK_WIFI_PMU>, <&cru ARMCLK>,
- <&cru ACLK_BUS_PRE>, <&cru ACLK_PERI_PRE>,
- <&cru HCLK_BUS_PRE>, <&cru HCLK_PERI_PRE>,
- <&cru PCLK_BUS_PRE>, <&cru SCLK_GPU>;
+ <&pmucru SCLK_WIFI_PMU>;
assigned-clock-rates =
<1200000000>, <100000000>,
- <26000000>, <600000000>,
- <200000000>, <200000000>,
- <150000000>, <150000000>,
- <100000000>, <200000000>;
+ <26000000>;
};
usb20_otg: usb@ff300000 {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put
From: Marc Zyngier @ 2019-09-17 8:35 UTC (permalink / raw)
To: Zenghui Yu, linux-arm-kernel, kvmarm, kvm; +Cc: Andre Przywara
In-Reply-To: <5ab75fec-6014-e3b4-92a3-63d5015814c1@huawei.com>
Hi Zenghui,
On 17/09/2019 09:10, Zenghui Yu wrote:
> Hi Marc,
>
> I've run this patch on my box and got the following messages:
>
> ---8<
>
> [ 2258.490030] BUG: sleeping function called from invalid context at
> kernel/irq/manage.c:138
> [ 2258.490034] in_atomic(): 1, irqs_disabled(): 0, pid: 59278, name: CPU
> 0/KVM
> [ 2258.490039] CPU: 32 PID: 59278 Comm: CPU 0/KVM Kdump: loaded Tainted:
> G W 5.3.0+ #26
> [ 2258.490041] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.58
> 10/29/2018
> [ 2258.490043] Call trace:
> [ 2258.490056] dump_backtrace+0x0/0x188
> [ 2258.490060] show_stack+0x24/0x30
> [ 2258.490066] dump_stack+0xb0/0xf4
> [ 2258.490072] ___might_sleep+0x10c/0x130
> [ 2258.490074] __might_sleep+0x58/0x90
> [ 2258.490078] synchronize_irq+0x58/0xd8
> [ 2258.490079] disable_irq+0x2c/0x38
> [ 2258.490083] vgic_v4_load+0x9c/0xc0
> [ 2258.490084] vgic_v3_load+0x94/0x170
> [ 2258.490088] kvm_vgic_load+0x3c/0x60
> [ 2258.490092] kvm_arch_vcpu_load+0xd4/0x1d0
> [ 2258.490095] vcpu_load+0x50/0x70
> [ 2258.490097] kvm_arch_vcpu_ioctl_run+0x94/0x978
> [ 2258.490098] kvm_vcpu_ioctl+0x3d8/0xa28
> [ 2258.490104] do_vfs_ioctl+0xc4/0x8e8
> [ 2258.490106] ksys_ioctl+0x8c/0xa0
> [ 2258.490108] __arm64_sys_ioctl+0x28/0x58
> [ 2258.490112] el0_svc_common.constprop.0+0x7c/0x188
> [ 2258.490114] el0_svc_handler+0x34/0xb8
> [ 2258.490117] el0_svc+0x8/0xc
> [ 2259.497070] BUG: sleeping function called from invalid context at
> kernel/irq/manage.c:138
Thanks for reporting this.
[...]
> The logic of disabling the doorbell interrupt in vgic_v4_load() might
> need a fix?
The logic itself looks OK, but doing a full blown disable_irq() is both
counter productive (if we race against a doorbell, there is not much we
can do about it and waiting for it to end is pointless) and wrong
(despite the comment that this can be called in IRQ context, it is
pretty unsafe to do so).
Can you try turning it into a disable_irq_nosync() and let me know if
that helps?
Thanks,
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: add missing #msi-cells to rk3399
From: Heiko Stuebner @ 2019-09-17 8:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, devicetree, Heiko Stuebner, linux-kernel,
linux-rockchip, robh+dt
The rk3399 gic-its was missing the #msi-cells property as found by
dt-schema checks, so add it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b5a5ef5ff449..788a7ed62e19 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -520,6 +520,7 @@
its: interrupt-controller@fee20000 {
compatible = "arm,gic-v3-its";
msi-controller;
+ #msi-cells = <1>;
reg = <0x0 0xfee20000 0x0 0x20000>;
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] coresight: etm4x: Add support for ThunderX2
From: Suzuki K Poulose @ 2019-09-17 8:39 UTC (permalink / raw)
To: mathieu.poirier, tanmay; +Cc: tnowicki, jnair, gkulkarni, linux-arm-kernel
In-Reply-To: <20190916195826.GA16787@xps15>
Hi Tanmay,
On 16/09/2019 20:58, Mathieu Poirier wrote:
> On Tue, Sep 10, 2019 at 06:25:02AM +0000, Tanmay Vilas Kumar Jagdale wrote:
>> Add ETMv4 periperhal ID for Marvell's ThunderX2 chip.
>> This chip contains ETMv4.1 version.
>>
>> Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
>
> mpoirier@xps15:~/work/coresight/kernel-maint$ ./scripts/checkpatch.pl 0001-coresight-etm4x-Add-support-for-ThunderX2.patch
> WARNING: Missing Signed-off-by: line by nominal patch author 'Tanmay Vilas Kumar Jagdale <tanmay@marvell.com>'
>
To translate that message a bit more, "Signed-off-by:" is kind of a legal
declaration. So, please use your full legal name.
Cheers
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 11/13] dt-bindings: document PX30 usb2phy General Register Files
From: Heiko Stuebner @ 2019-09-17 8:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, devicetree, Heiko Stuebner, linux-kernel,
linux-rockchip, robh+dt, christoph.muellner
In-Reply-To: <20190917082659.25549-1-heiko@sntech.de>
One of the separate General Register Files contains the registers for
controlling the usb2phy, so add the necessary binding compatible for it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
Documentation/devicetree/bindings/soc/rockchip/grf.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
index 46e27cd69f18..d7debec26ba4 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -30,6 +30,7 @@ Required Properties:
- compatible: SGRF should be one of the following
- "rockchip,rk3288-sgrf", "syscon": for rk3288
- compatible: USB2PHYGRF should be one of the followings
+ - "rockchip,px30-usb2phy-grf", "syscon": for px30
- "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
- compatible: USBGRF should be one of the following
- "rockchip,rv1108-usbgrf", "syscon": for rv1108
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 12/13] arm64: dts: rockchip: add usb2phy for px30
From: Heiko Stuebner @ 2019-09-17 8:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, devicetree, Heiko Stuebner, linux-kernel,
linux-rockchip, robh+dt, christoph.muellner
In-Reply-To: <20190917082659.25549-1-heiko@sntech.de>
Add the usb2phy node on the px30 and hook it up to the usb controllers
it supplies.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 43 ++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 9ad1c2f04ea9..837e421cc30f 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -701,6 +701,43 @@
<26000000>;
};
+ usb2phy_grf: syscon@ff2c0000 {
+ compatible = "rockchip,px30-usb2phy-grf", "syscon",
+ "simple-mfd";
+ reg = <0x0 0xff2c0000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ u2phy: usb2-phy@100 {
+ compatible = "rockchip,px30-usb2phy";
+ reg = <0x100 0x20>;
+ clocks = <&pmucru SCLK_USBPHY_REF>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ assigned-clocks = <&cru USB480M>;
+ assigned-clock-parents = <&u2phy>;
+ clock-output-names = "usb480m_phy";
+ status = "disabled";
+
+ u2phy_host: host-port {
+ #phy-cells = <0>;
+ interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "linestate";
+ status = "disabled";
+ };
+
+ u2phy_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "otg-bvalid", "otg-id",
+ "linestate";
+ status = "disabled";
+ };
+ };
+ };
+
usb20_otg: usb@ff300000 {
compatible = "rockchip,px30-usb", "rockchip,rk3066-usb",
"snps,dwc2";
@@ -713,6 +750,8 @@
g-rx-fifo-size = <280>;
g-tx-fifo-size = <256 128 128 64 32 16>;
g-use-dma;
+ phys = <&u2phy_otg>;
+ phy-names = "usb2-phy";
power-domains = <&power PX30_PD_USB>;
status = "disabled";
};
@@ -723,6 +762,8 @@
interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru HCLK_HOST>;
clock-names = "usbhost";
+ phys = <&u2phy_host>;
+ phy-names = "usb";
power-domains = <&power PX30_PD_USB>;
status = "disabled";
};
@@ -733,6 +774,8 @@
interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru HCLK_HOST>;
clock-names = "usbhost";
+ phys = <&u2phy_host>;
+ phy-names = "usb";
power-domains = <&power PX30_PD_USB>;
status = "disabled";
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 13/13] arm64: dts: rockchip: enable usb2phy on px30-evb
From: Heiko Stuebner @ 2019-09-17 8:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, devicetree, Heiko Stuebner, linux-kernel,
linux-rockchip, robh+dt, christoph.muellner
In-Reply-To: <20190917082659.25549-1-heiko@sntech.de>
Enable the phy node ion the px30 evb board.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/px30-evb.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30-evb.dts b/arch/arm64/boot/dts/rockchip/px30-evb.dts
index 1185a314ba4a..936ed7d71ffc 100644
--- a/arch/arm64/boot/dts/rockchip/px30-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/px30-evb.dts
@@ -485,6 +485,18 @@
status = "okay";
};
+&u2phy {
+ status = "okay";
+
+ u2phy_host: host-port {
+ status = "okay";
+ };
+
+ u2phy_otg: otg-port {
+ status = "okay";
+ };
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_xfer &uart1_cts>;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
From: Matthias Brugger @ 2019-09-17 9:04 UTC (permalink / raw)
To: Stefan Wahren, Matthias Brugger, robh+dt, linux-arm-kernel,
Nicolas Saenz Julienne
Cc: f.fainelli, phil, linux-rpi-kernel, linux-kernel
In-Reply-To: <c7e6ab89-aaae-debc-5f63-2e091efcf76f@gmx.net>
On 16/09/2019 21:19, Stefan Wahren wrote:
> Hi Matthias,
>
> [drop uninvolved receiver]
>
> Am 13.09.19 um 12:39 schrieb Matthias Brugger:
>>
>>>>>> If you talk about the
>>>>>> downstream kernel, I suppose you mean we should change this in the FW DT blob
>>>>>> and in the downstream kernel. That would work for me.
>>>>>>
>>>>>> Did I understand you correctly?
>>>>> Yes
>>>>>
>>>>> So i suggest to add the upstream compatibles into the repo mentioned above.
>>>>>
>>>>> Sorry, but in case you decided as a U-Boot developer to be compatible
>>>>> with a unreviewed DT, we also need to make U-Boot compatible with
>>>>> upstream and downstream DT blobs.
>>>>>
>>>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier
>>>> if we can use this DTB we can work towards one binary that can boot both RPi3
>>>> and RPi4. On the other hand we can rely on the FW to detect the amount of memory
>>>> our RPi4 has.
>>>>
>>>> That said, I agree that we should make sure that U-Boot can boot with both DTBs,
>>>> the upstream one and the downstream. Now the question is how to get to this. I'm
>>>> a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711
>>>> compatible is already reviewed and can't be changed. From what I can see none of
>>>> these compatibles got merged for now, so we are still at time to change them.
>>> Stephen Boyd was okay with clk changes except of a small nit. So i fixed
>>> this is as he suggested in a separate series. Unfortunately this hasn't
>>> be applied yet [1].
>>>
>>> The i2c, pinctrl and the sdhci changes has been applied yet.
>>>
>>> In my opinion it isn't the job of the mainline kernel to adapt to a
>>> vendor device tree. It's the vendor device tree which needs to be fixed.
>>>
>> I agree with that. But if we can make this easier by choosing a compatible which
>> fits downstream without violating upstream and it makes sense with the naming
>> scheme of the RPi, I think that's a good argument.
>
> i spend a lot of my spare time to prepare these patch series in order to
> get a clean solution.
>
> Either mixing bcm2711/bcm2838 or changing everything to bcm2838 in the
> upstream tree has the following drawbacks:
>
> - additional review time and delay of the Raspberry Pi 4 support
> - harder to understand for developer/reviewer without RPi knowledge
On the other hand it get's confusing that the SoC for RPi4 is called bcm2711
while all the others are named bcm283x. Anyway if the majority prefers bcm2711
so shall it be and let's get forward instead :)
>
> Btw currently u-boot only uses bcm2711, so it would be nice to keep that.
>
Yes that's true. We already identified the compatible we'll need to add to
U-Boot to also boot with the upstream DTS. I'll send a patch to the U-Boot
mailinglist.
> So my suggestion is to add bcm2711 compatibles in the downstream tree.
>
Ok, can you take care of it, or shall I send a pull request/open a bug?
Regards,
Matthias
> Best regards
> Stefan
>
>>
>>> Sorry, but this is my holiday. I will back after the weekend.
>>>
>> Sure, enjoy. I'll be on travel for the next two weeks but will try to keep up
>> with emails.
>>
>> Regards,
>> Matthias
>>
>>> Best regards
>>> Stefan
>>>
>>> [1] - https://www.spinics.net/lists/linux-clk/msg40534.html
>>>
>>>> Apart from the point Florian made, to stay consistent with the RPi SoC naming,
>>>> it will save us work, both in the kernel and in U-Boot, as we would need to add
>>>> both compatibles to the code-base.
>>>>
>>>> Regards,
>>>> Matthias
>>>>
>>>>>>>> Regards,
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>>> Are there any config.txt tweaks necessary?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> linux-arm-kernel mailing list
>>>>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> linux-arm-kernel mailing list
>>>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Question-GIC-v4.1] Plan on GIC-v4.1 driver development
From: Marc Zyngier @ 2019-09-17 9:23 UTC (permalink / raw)
To: Shaokun Zhang, linux-arm-kernel, kvmarm; +Cc: Tangnianyao (ICT)
In-Reply-To: <40d7276c-54a3-0cca-a207-217459850c21@hisilicon.com>
On 17/09/2019 03:15, Shaokun Zhang wrote:
> Hi Marc,
>
> This is from Nianyao Tang.
>
> I'm planning to do some verification on our GIC-v4.1 implement. I would like some
> information about linux GIC-v4.1 driver. When will linux support GIC-v4.1 or what's
> the plan on developing GIC-v4.1 driver?
The easy answer is that yes, there is a plan. There is some code, even,
just not quite in a usable state yet. I'll try to push something out
once I get a chance.
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: meson-a1: add pinctrl driver for Meson A1 Soc
From: Jerome Brunet @ 2019-09-17 9:29 UTC (permalink / raw)
To: Qianggui Song
Cc: Mark Rutland, Hanjie Lin, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, Linus Walleij, linux-kernel,
linux-gpio, Rob Herring, linux-arm-kernel, Carlo Caione,
linux-amlogic, Xingyu Chen, Jerome Brunet
In-Reply-To: <1568700442-18540-3-git-send-email-qianggui.song@amlogic.com>
On Tue 17 Sep 2019 at 08:07, Qianggui Song <qianggui.song@amlogic.com> wrote:
> Add pinctrl driver for Meson A1 Soc which share the same register layout of
> pinmux with previous Meson-G12A, however there is difference for gpio
> and pin config register in A1. The register layout is as below:
>
> /* first bank */ /* addr */
> - P_PADCTRL_GPIOP_I base + 0x00 << 2
> - P_PADCTRL_GPIOP_O base + 0x01 << 2
> - P_PADCTRL_GPIOP_OEN base + 0x02 << 2
> - P_PADCTRL_GPIOP_PULL_EN base + 0x03 << 2
> - P_PADCTRL_GPIOP_PULL_UP base + 0x04 << 2
> - P_PADCTRL_GPIOP_DS base + 0x05 << 2
>
> /* second bank */
> - P_PADCTRL_GPIOB_I base + 0x10 << 2
> - P_PADCTRL_GPIOB_O base + 0x11 << 2
> - P_PADCTRL_GPIOB_OEN base + 0x12 << 2
> - P_PADCTRL_GPIOB_PULL_EN base + 0x13 << 2
> - P_PADCTRL_GPIOB_PULL_UP base + 0x14 << 2
> - P_PADCTRL_GPIOB_DS base + 0x15 << 2
>
> Each bank contains at least 6 registers to be configured, if one bank has
> more than 16 gpios, an extra P_PADCTRL_GPIO[X]_DS_EXT is included. Between
> two adjacent P_PADCTRL_GPIO[X]_I, there is an offset 0x10, that is to say,
> for third bank, the offsets will be 0x20,0x21,0x22,0x23,0x24,0x25 according
> to above register layout.
>
> Current Meson pinctrl driver can cover such change by using base address of
> GPIO as that of drive-strength. While simply giving reg_ds = reg_pullen
> make wrong value to reg_ds for Soc that not support drive-strength like AXG
> . Here a private data used to identify register layout is introduced.
>
> Signed-off-by: Qianggui Song <qianggui.song@amlogic.com>
> Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
> ---
> drivers/pinctrl/meson/Kconfig | 6 +
> drivers/pinctrl/meson/Makefile | 1 +
> drivers/pinctrl/meson/pinctrl-meson-a1.c | 942 +++++++++++++++++++++++++++++++
> drivers/pinctrl/meson/pinctrl-meson.c | 8 +-
> drivers/pinctrl/meson/pinctrl-meson.h | 9 +
> 5 files changed, 964 insertions(+), 2 deletions(-)
> create mode 100644 drivers/pinctrl/meson/pinctrl-meson-a1.c
>
> diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
> index df55f61..3cb1191 100644
> --- a/drivers/pinctrl/meson/Kconfig
> +++ b/drivers/pinctrl/meson/Kconfig
> @@ -54,4 +54,10 @@ config PINCTRL_MESON_G12A
> select PINCTRL_MESON_AXG_PMX
> default y
>
> +config PINCTRL_MESON_A1
> + bool "Meson a1 Soc pinctrl driver"
> + depends on ARM64
> + select PINCTRL_MESON_AXG_PMX
> + default y
> +
> endif
> diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
> index a69c565..1a5bffe 100644
> --- a/drivers/pinctrl/meson/Makefile
> +++ b/drivers/pinctrl/meson/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_PINCTRL_MESON_GXL) += pinctrl-meson-gxl.o
> obj-$(CONFIG_PINCTRL_MESON_AXG_PMX) += pinctrl-meson-axg-pmx.o
> obj-$(CONFIG_PINCTRL_MESON_AXG) += pinctrl-meson-axg.o
> obj-$(CONFIG_PINCTRL_MESON_G12A) += pinctrl-meson-g12a.o
> +obj-$(CONFIG_PINCTRL_MESON_A1) += pinctrl-meson-a1.o
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-a1.c b/drivers/pinctrl/meson/pinctrl-meson-a1.c
> new file mode 100644
> index 0000000..f3a88f1
> --- /dev/null
> +++ b/drivers/pinctrl/meson/pinctrl-meson-a1.c
> @@ -0,0 +1,942 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Pin controller and GPIO driver for Amlogic Meson A1 SoC.
> + *
> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
> + * Author: Qianggui Song <qianggui.song@amlogic.com>
> + */
> +
> +#include <dt-bindings/gpio/meson-a1-gpio.h>
> +#include "pinctrl-meson.h"
> +#include "pinctrl-meson-axg-pmx.h"
> +
> +static const struct pinctrl_pin_desc meson_a1_periphs_pins[] = {
> + MESON_PIN(GPIOP_0),
> + MESON_PIN(GPIOP_1),
> + MESON_PIN(GPIOP_2),
> + MESON_PIN(GPIOP_3),
> + MESON_PIN(GPIOP_4),
> + MESON_PIN(GPIOP_5),
> + MESON_PIN(GPIOP_6),
> + MESON_PIN(GPIOP_7),
> + MESON_PIN(GPIOP_8),
> + MESON_PIN(GPIOP_9),
> + MESON_PIN(GPIOP_10),
> + MESON_PIN(GPIOP_11),
> + MESON_PIN(GPIOP_12),
> + MESON_PIN(GPIOB_0),
> + MESON_PIN(GPIOB_1),
> + MESON_PIN(GPIOB_2),
> + MESON_PIN(GPIOB_3),
> + MESON_PIN(GPIOB_4),
> + MESON_PIN(GPIOB_5),
> + MESON_PIN(GPIOB_6),
> + MESON_PIN(GPIOX_0),
> + MESON_PIN(GPIOX_1),
> + MESON_PIN(GPIOX_2),
> + MESON_PIN(GPIOX_3),
> + MESON_PIN(GPIOX_4),
> + MESON_PIN(GPIOX_5),
> + MESON_PIN(GPIOX_6),
> + MESON_PIN(GPIOX_7),
> + MESON_PIN(GPIOX_8),
> + MESON_PIN(GPIOX_9),
> + MESON_PIN(GPIOX_10),
> + MESON_PIN(GPIOX_11),
> + MESON_PIN(GPIOX_12),
> + MESON_PIN(GPIOX_13),
> + MESON_PIN(GPIOX_14),
> + MESON_PIN(GPIOX_15),
> + MESON_PIN(GPIOX_16),
> + MESON_PIN(GPIOF_0),
> + MESON_PIN(GPIOF_1),
> + MESON_PIN(GPIOF_2),
> + MESON_PIN(GPIOF_3),
> + MESON_PIN(GPIOF_4),
> + MESON_PIN(GPIOF_5),
> + MESON_PIN(GPIOF_6),
> + MESON_PIN(GPIOF_7),
> + MESON_PIN(GPIOF_8),
> + MESON_PIN(GPIOF_9),
> + MESON_PIN(GPIOF_10),
> + MESON_PIN(GPIOF_11),
> + MESON_PIN(GPIOF_12),
> + MESON_PIN(GPIOA_0),
> + MESON_PIN(GPIOA_1),
> + MESON_PIN(GPIOA_2),
> + MESON_PIN(GPIOA_3),
> + MESON_PIN(GPIOA_4),
> + MESON_PIN(GPIOA_5),
> + MESON_PIN(GPIOA_6),
> + MESON_PIN(GPIOA_7),
> + MESON_PIN(GPIOA_8),
> + MESON_PIN(GPIOA_9),
> + MESON_PIN(GPIOA_10),
> + MESON_PIN(GPIOA_11),
> +};
> +
> +/* psram */
> +static const unsigned int psram_clkn_pins[] = { GPIOP_0 };
> +static const unsigned int psram_clkp_pins[] = { GPIOP_1 };
> +static const unsigned int psram_ce_n_pins[] = { GPIOP_2 };
> +static const unsigned int psram_rst_n_pins[] = { GPIOP_3 };
> +static const unsigned int psram_adq0_pins[] = { GPIOP_4 };
> +static const unsigned int psram_adq1_pins[] = { GPIOP_5 };
> +static const unsigned int psram_adq2_pins[] = { GPIOP_6 };
> +static const unsigned int psram_adq3_pins[] = { GPIOP_7 };
> +static const unsigned int psram_adq4_pins[] = { GPIOP_8 };
> +static const unsigned int psram_adq5_pins[] = { GPIOP_9 };
> +static const unsigned int psram_adq6_pins[] = { GPIOP_10 };
> +static const unsigned int psram_adq7_pins[] = { GPIOP_11 };
> +static const unsigned int psram_dqs_dm_pins[] = { GPIOP_12 };
> +
> +/* sdcard */
> +static const unsigned int sdcard_d0_b_pins[] = { GPIOB_0 };
> +static const unsigned int sdcard_d1_b_pins[] = { GPIOB_1 };
> +static const unsigned int sdcard_d2_b_pins[] = { GPIOB_2 };
> +static const unsigned int sdcard_d3_b_pins[] = { GPIOB_3 };
> +static const unsigned int sdcard_clk_b_pins[] = { GPIOB_4 };
> +static const unsigned int sdcard_cmd_b_pins[] = { GPIOB_5 };
> +
> +static const unsigned int sdcard_d0_x_pins[] = { GPIOX_0 };
> +static const unsigned int sdcard_d1_x_pins[] = { GPIOX_1 };
> +static const unsigned int sdcard_d2_x_pins[] = { GPIOX_2 };
> +static const unsigned int sdcard_d3_x_pins[] = { GPIOX_3 };
> +static const unsigned int sdcard_clk_x_pins[] = { GPIOX_4 };
> +static const unsigned int sdcard_cmd_x_pins[] = { GPIOX_5 };
> +
> +/* spif */
> +static const unsigned int spif_mo_pins[] = { GPIOB_0 };
> +static const unsigned int spif_mi_pins[] = { GPIOB_1 };
> +static const unsigned int spif_wp_n_pins[] = { GPIOB_2 };
> +static const unsigned int spif_hold_n_pins[] = { GPIOB_3 };
> +static const unsigned int spif_clk_pins[] = { GPIOB_4 };
> +static const unsigned int spif_cs_pins[] = { GPIOB_5 };
> +
> +/* i2c0 */
> +static const unsigned int i2c0_sck_f9_pins[] = { GPIOF_9 };
> +static const unsigned int i2c0_sda_f10_pins[] = { GPIOF_10 };
> +static const unsigned int i2c0_sck_f11_pins[] = { GPIOF_11 };
> +static const unsigned int i2c0_sda_f12_pins[] = { GPIOF_12 };
> +
> +/* i2c1 */
> +static const unsigned int i2c1_sda_x_pins[] = { GPIOX_9 };
> +static const unsigned int i2c1_sck_x_pins[] = { GPIOX_10 };
> +static const unsigned int i2c1_sda_a_pins[] = { GPIOA_10 };
> +static const unsigned int i2c1_sck_a_pins[] = { GPIOA_11 };
> +
> +/* i2c2 */
> +static const unsigned int i2c2_sck_x0_pins[] = { GPIOX_0 };
> +static const unsigned int i2c2_sda_x1_pins[] = { GPIOX_1 };
> +static const unsigned int i2c2_sck_x15_pins[] = { GPIOX_15 };
> +static const unsigned int i2c2_sda_x16_pins[] = { GPIOX_16 };
> +static const unsigned int i2c2_sck_a4_pins[] = { GPIOA_4 };
> +static const unsigned int i2c2_sda_a5_pins[] = { GPIOA_5 };
> +static const unsigned int i2c2_sck_a8_pins[] = { GPIOA_8 };
> +static const unsigned int i2c2_sda_a9_pins[] = { GPIOA_9 };
> +
> +/* i2c3 */
> +static const unsigned int i2c3_sck_f_pins[] = { GPIOF_4 };
> +static const unsigned int i2c3_sda_f_pins[] = { GPIOF_5 };
> +static const unsigned int i2c3_sck_x_pins[] = { GPIOX_11 };
> +static const unsigned int i2c3_sda_x_pins[] = { GPIOX_12 };
> +
> +/* i2c slave */
> +static const unsigned int i2c_slave_sck_a_pins[] = { GPIOA_10 };
> +static const unsigned int i2c_slave_sda_a_pins[] = { GPIOA_11 };
> +static const unsigned int i2c_slave_sck_f_pins[] = { GPIOF_11 };
> +static const unsigned int i2c_slave_sda_f_pins[] = { GPIOF_12 };
> +
> +/* uart_a */
> +static const unsigned int uart_a_tx_pins[] = { GPIOX_11 };
> +static const unsigned int uart_a_rx_pins[] = { GPIOX_12 };
> +static const unsigned int uart_a_cts_pins[] = { GPIOX_13 };
> +static const unsigned int uart_a_rts_pins[] = { GPIOX_14 };
> +
> +/* uart_b */
> +static const unsigned int uart_b_tx_x_pins[] = { GPIOX_7 };
> +static const unsigned int uart_b_rx_x_pins[] = { GPIOX_8 };
> +static const unsigned int uart_b_tx_f_pins[] = { GPIOF_0 };
> +static const unsigned int uart_b_rx_f_pins[] = { GPIOF_1 };
> +
> +/* uart_c */
> +static const unsigned int uart_c_tx_x0_pins[] = { GPIOX_0 };
> +static const unsigned int uart_c_rx_x1_pins[] = { GPIOX_1 };
> +static const unsigned int uart_c_cts_pins[] = { GPIOX_2 };
> +static const unsigned int uart_c_rts_pins[] = { GPIOX_3 };
> +static const unsigned int uart_c_tx_x15_pins[] = { GPIOX_15 };
> +static const unsigned int uart_c_rx_x16_pins[] = { GPIOX_16 };
> +
> +/* pmw_a */
> +static const unsigned int pwm_a_x6_pins[] = { GPIOX_6 };
> +static const unsigned int pwm_a_x7_pins[] = { GPIOX_7 };
> +static const unsigned int pwm_a_f6_pins[] = { GPIOF_6 };
> +static const unsigned int pwm_a_f10_pins[] = { GPIOF_10 };
> +static const unsigned int pwm_a_a_pins[] = { GPIOA_5 };
> +
> +/* pmw_b */
> +static const unsigned int pwm_b_x_pins[] = { GPIOX_8 };
> +static const unsigned int pwm_b_f_pins[] = { GPIOF_7 };
> +static const unsigned int pwm_b_a_pins[] = { GPIOA_11 };
> +
> +/* pmw_c */
> +static const unsigned int pwm_c_x_pins[] = { GPIOX_9 };
> +static const unsigned int pwm_c_f3_pins[] = { GPIOF_3 };
> +static const unsigned int pwm_c_f8_pins[] = { GPIOF_8 };
> +static const unsigned int pwm_c_a_pins[] = { GPIOA_10 };
> +
> +/* pwm_d */
> +static const unsigned int pwm_d_x10_pins[] = { GPIOX_10 };
> +static const unsigned int pwm_d_x13_pins[] = { GPIOX_13 };
> +static const unsigned int pwm_d_x15_pins[] = { GPIOX_15 };
> +static const unsigned int pwm_d_f_pins[] = { GPIOF_11 };
> +
> +/* pwm_e */
> +static const unsigned int pwm_e_p_pins[] = { GPIOP_3 };
> +static const unsigned int pwm_e_x2_pins[] = { GPIOX_2 };
> +static const unsigned int pwm_e_x14_pins[] = { GPIOX_14 };
> +static const unsigned int pwm_e_x16_pins[] = { GPIOX_16 };
> +static const unsigned int pwm_e_f_pins[] = { GPIOF_3 };
> +static const unsigned int pwm_e_a_pins[] = { GPIOA_0 };
> +
> +/* pwm_f */
> +static const unsigned int pwm_f_b_pins[] = { GPIOB_6 };
> +static const unsigned int pwm_f_x_pins[] = { GPIOX_3 };
> +static const unsigned int pwm_f_f4_pins[] = { GPIOF_4 };
> +static const unsigned int pwm_f_f12_pins[] = { GPIOF_12 };
> +
> +/* pwm_a_hiz */
> +static const unsigned int pwm_a_hiz_f8_pins[] = { GPIOF_8 };
> +static const unsigned int pwm_a_hiz_f10_pins[] = { GPIOF_10 };
> +static const unsigned int pmw_a_hiz_f6_pins[] = { GPIOF_6 };
> +
> +/* pwm_b_hiz */
> +static const unsigned int pwm_b_hiz_pins[] = { GPIOF_7 };
> +
> +/* pmw_c_hiz */
> +static const unsigned int pwm_c_hiz_pins[] = { GPIOF_8 };
> +
> +/* tdm_a */
> +static const unsigned int tdm_a_dout1_pins[] = { GPIOX_7 };
> +static const unsigned int tdm_a_dout0_pins[] = { GPIOX_8 };
> +static const unsigned int tdm_a_fs_pins[] = { GPIOX_9 };
> +static const unsigned int tdm_a_sclk_pins[] = { GPIOX_10 };
> +static const unsigned int tdm_a_din1_pins[] = { GPIOX_7 };
> +static const unsigned int tdm_a_din0_pins[] = { GPIOX_8 };
> +static const unsigned int tdm_a_slv_fs_pins[] = { GPIOX_9 };
> +static const unsigned int tdm_a_slv_sclk_pins[] = { GPIOX_10 };
> +
> +/* spi_a */
> +static const unsigned int spi_a_mosi_x2_pins[] = { GPIOX_2 };
> +static const unsigned int spi_a_ss0_x3_pins[] = { GPIOX_3 };
> +static const unsigned int spi_a_sclk_x4_pins[] = { GPIOX_4 };
> +static const unsigned int spi_a_miso_x5_pins[] = { GPIOX_5 };
> +static const unsigned int spi_a_mosi_x7_pins[] = { GPIOX_7 };
> +static const unsigned int spi_a_miso_x8_pins[] = { GPIOX_8 };
> +static const unsigned int spi_a_ss0_x9_pins[] = { GPIOX_9 };
> +static const unsigned int spi_a_sclk_x10_pins[] = { GPIOX_10 };
> +
> +static const unsigned int spi_a_mosi_a_pins[] = { GPIOA_6 };
> +static const unsigned int spi_a_miso_a_pins[] = { GPIOA_7 };
> +static const unsigned int spi_a_ss0_a_pins[] = { GPIOA_8 };
> +static const unsigned int spi_a_sclk_a_pins[] = { GPIOA_9 };
> +
> +/* pdm */
> +static const unsigned int pdm_din0_x_pins[] = { GPIOX_7 };
> +static const unsigned int pdm_din1_x_pins[] = { GPIOX_8 };
> +static const unsigned int pdm_din2_x_pins[] = { GPIOX_9 };
> +static const unsigned int pdm_dclk_x_pins[] = { GPIOX_10 };
> +
> +static const unsigned int pdm_din2_a_pins[] = { GPIOA_6 };
> +static const unsigned int pdm_din1_a_pins[] = { GPIOA_7 };
> +static const unsigned int pdm_din0_a_pins[] = { GPIOA_8 };
> +static const unsigned int pdm_dclk_pins[] = { GPIOA_9 };
> +
> +/* gen_clk */
> +static const unsigned int gen_clk_x_pins[] = { GPIOX_7 };
> +static const unsigned int gen_clk_f8_pins[] = { GPIOF_8 };
> +static const unsigned int gen_clk_f10_pins[] = { GPIOF_10 };
> +static const unsigned int gen_clk_a_pins[] = { GPIOA_11 };
> +
> +/* jtag_a */
> +static const unsigned int jtag_a_clk_pins[] = { GPIOF_4 };
> +static const unsigned int jtag_a_tms_pins[] = { GPIOF_5 };
> +static const unsigned int jtag_a_tdi_pins[] = { GPIOF_6 };
> +static const unsigned int jtag_a_tdo_pins[] = { GPIOF_7 };
> +
> +/* clk_32_in */
> +static const unsigned int clk_32k_in_pins[] = { GPIOF_2 };
> +
> +/* ir in */
> +static const unsigned int remote_input_f_pins[] = { GPIOF_3 };
> +static const unsigned int remote_input_a_pins[] = { GPIOA_11 };
> +
> +/* ir out */
> +static const unsigned int remote_out_pins[] = { GPIOF_5 };
> +
> +/* spdif */
> +static const unsigned int spdif_in_f6_pins[] = { GPIOF_6 };
> +static const unsigned int spdif_in_f7_pins[] = { GPIOF_7 };
> +
> +/* sw */
> +static const unsigned int swclk_pins[] = { GPIOF_4 };
> +static const unsigned int swdio_pins[] = { GPIOF_5 };
> +
> +/* clk_25 */
> +static const unsigned int clk25_pins[] = { GPIOF_10 };
> +
> +/* cec_a */
> +static const unsigned int cec_a_pins[] = { GPIOF_2 };
> +
> +/* cec_b */
> +static const unsigned int cec_b_pins[] = { GPIOF_2 };
> +
> +/* clk12_24 */
> +static const unsigned int clk12_24_pins[] = { GPIOF_10 };
> +
> +/* mclk_0 */
> +static const unsigned int mclk_0_pins[] = { GPIOA_0 };
> +
> +/* tdm_b */
> +static const unsigned int tdm_b_sclk_pins[] = { GPIOA_1 };
> +static const unsigned int tdm_b_fs_pins[] = { GPIOA_2 };
> +static const unsigned int tdm_b_dout0_pins[] = { GPIOA_3 };
> +static const unsigned int tdm_b_dout1_pins[] = { GPIOA_4 };
> +static const unsigned int tdm_b_dout2_pins[] = { GPIOA_5 };
> +static const unsigned int tdm_b_dout3_pins[] = { GPIOA_6 };
> +static const unsigned int tdm_b_dout4_pins[] = { GPIOA_7 };
> +static const unsigned int tdm_b_dout5_pins[] = { GPIOA_8 };
> +static const unsigned int tdm_b_slv_sclk_pins[] = { GPIOA_5 };
> +static const unsigned int tdm_b_slv_fs_pins[] = { GPIOA_6 };
> +static const unsigned int tdm_b_din0_pins[] = { GPIOA_7 };
> +static const unsigned int tdm_b_din1_pins[] = { GPIOA_8 };
> +static const unsigned int tdm_b_din2_pins[] = { GPIOA_9 };
> +
> +/* mclk_vad */
> +static const unsigned int mclk_vad_pins[] = { GPIOA_0 };
> +
> +/* tdm_vad */
> +static const unsigned int tdm_vad_sclk_a1_pins[] = { GPIOA_1 };
> +static const unsigned int tdm_vad_fs_a2_pins[] = { GPIOA_2 };
> +static const unsigned int tdm_vad_sclk_a5_pins[] = { GPIOA_5 };
> +static const unsigned int tdm_vad_fs_a6_pins[] = { GPIOA_6 };
> +
> +/* tst_out */
> +static const unsigned int tst_out0_pins[] = { GPIOA_0 };
> +static const unsigned int tst_out1_pins[] = { GPIOA_1 };
> +static const unsigned int tst_out2_pins[] = { GPIOA_2 };
> +static const unsigned int tst_out3_pins[] = { GPIOA_3 };
> +static const unsigned int tst_out4_pins[] = { GPIOA_4 };
> +static const unsigned int tst_out5_pins[] = { GPIOA_5 };
> +static const unsigned int tst_out6_pins[] = { GPIOA_6 };
> +static const unsigned int tst_out7_pins[] = { GPIOA_7 };
> +static const unsigned int tst_out8_pins[] = { GPIOA_8 };
> +static const unsigned int tst_out9_pins[] = { GPIOA_9 };
> +static const unsigned int tst_out10_pins[] = { GPIOA_10 };
> +static const unsigned int tst_out11_pins[] = { GPIOA_11 };
> +
> +/* mute */
> +static const unsigned int mute_key_pins[] = { GPIOA_4 };
> +static const unsigned int mute_en_pins[] = { GPIOA_5 };
> +
> +static struct meson_pmx_group meson_a1_periphs_groups[] = {
> + GPIO_GROUP(GPIOP_0),
> + GPIO_GROUP(GPIOP_1),
> + GPIO_GROUP(GPIOP_2),
> + GPIO_GROUP(GPIOP_3),
> + GPIO_GROUP(GPIOP_4),
> + GPIO_GROUP(GPIOP_5),
> + GPIO_GROUP(GPIOP_6),
> + GPIO_GROUP(GPIOP_7),
> + GPIO_GROUP(GPIOP_8),
> + GPIO_GROUP(GPIOP_9),
> + GPIO_GROUP(GPIOP_10),
> + GPIO_GROUP(GPIOP_11),
> + GPIO_GROUP(GPIOP_12),
> + GPIO_GROUP(GPIOB_0),
> + GPIO_GROUP(GPIOB_1),
> + GPIO_GROUP(GPIOB_2),
> + GPIO_GROUP(GPIOB_3),
> + GPIO_GROUP(GPIOB_4),
> + GPIO_GROUP(GPIOB_5),
> + GPIO_GROUP(GPIOB_6),
> + GPIO_GROUP(GPIOX_0),
> + GPIO_GROUP(GPIOX_1),
> + GPIO_GROUP(GPIOX_2),
> + GPIO_GROUP(GPIOX_3),
> + GPIO_GROUP(GPIOX_4),
> + GPIO_GROUP(GPIOX_5),
> + GPIO_GROUP(GPIOX_6),
> + GPIO_GROUP(GPIOX_7),
> + GPIO_GROUP(GPIOX_8),
> + GPIO_GROUP(GPIOX_9),
> + GPIO_GROUP(GPIOX_10),
> + GPIO_GROUP(GPIOX_11),
> + GPIO_GROUP(GPIOX_12),
> + GPIO_GROUP(GPIOX_13),
> + GPIO_GROUP(GPIOX_14),
> + GPIO_GROUP(GPIOX_15),
> + GPIO_GROUP(GPIOX_16),
> + GPIO_GROUP(GPIOF_0),
> + GPIO_GROUP(GPIOF_1),
> + GPIO_GROUP(GPIOF_2),
> + GPIO_GROUP(GPIOF_3),
> + GPIO_GROUP(GPIOF_4),
> + GPIO_GROUP(GPIOF_5),
> + GPIO_GROUP(GPIOF_6),
> + GPIO_GROUP(GPIOF_7),
> + GPIO_GROUP(GPIOF_8),
> + GPIO_GROUP(GPIOF_9),
> + GPIO_GROUP(GPIOF_10),
> + GPIO_GROUP(GPIOF_11),
> + GPIO_GROUP(GPIOF_12),
> + GPIO_GROUP(GPIOA_0),
> + GPIO_GROUP(GPIOA_1),
> + GPIO_GROUP(GPIOA_2),
> + GPIO_GROUP(GPIOA_3),
> + GPIO_GROUP(GPIOA_4),
> + GPIO_GROUP(GPIOA_5),
> + GPIO_GROUP(GPIOA_6),
> + GPIO_GROUP(GPIOA_7),
> + GPIO_GROUP(GPIOA_8),
> + GPIO_GROUP(GPIOA_9),
> + GPIO_GROUP(GPIOA_10),
> + GPIO_GROUP(GPIOA_11),
> +
> + /* bank P func1 */
> + GROUP(psram_clkn, 1),
> + GROUP(psram_clkp, 1),
> + GROUP(psram_ce_n, 1),
> + GROUP(psram_rst_n, 1),
> + GROUP(psram_adq0, 1),
> + GROUP(psram_adq1, 1),
> + GROUP(psram_adq2, 1),
> + GROUP(psram_adq3, 1),
> + GROUP(psram_adq4, 1),
> + GROUP(psram_adq5, 1),
> + GROUP(psram_adq6, 1),
> + GROUP(psram_adq7, 1),
> + GROUP(psram_dqs_dm, 1),
> +
> + /*bank P func2 */
> + GROUP(pwm_e_p, 2),
> +
> + /*bank B func1 */
> + GROUP(spif_mo, 1),
> + GROUP(spif_mi, 1),
> + GROUP(spif_wp_n, 1),
> + GROUP(spif_hold_n, 1),
> + GROUP(spif_clk, 1),
> + GROUP(spif_cs, 1),
> + GROUP(pwm_f_b, 1),
> +
> + /*bank B func2 */
> + GROUP(sdcard_d0_b, 2),
> + GROUP(sdcard_d1_b, 2),
> + GROUP(sdcard_d2_b, 2),
> + GROUP(sdcard_d3_b, 2),
> + GROUP(sdcard_clk_b, 2),
> + GROUP(sdcard_cmd_b, 2),
> +
> + /*bank X func1 */
> + GROUP(sdcard_d0_x, 1),
> + GROUP(sdcard_d1_x, 1),
> + GROUP(sdcard_d2_x, 1),
> + GROUP(sdcard_d3_x, 1),
> + GROUP(sdcard_clk_x, 1),
> + GROUP(sdcard_cmd_x, 1),
> + GROUP(pwm_a_x6, 1),
> + GROUP(tdm_a_dout1, 1),
> + GROUP(tdm_a_dout0, 1),
> + GROUP(tdm_a_fs, 1),
> + GROUP(tdm_a_sclk, 1),
> + GROUP(uart_a_tx, 1),
> + GROUP(uart_a_rx, 1),
> + GROUP(uart_a_cts, 1),
> + GROUP(uart_a_rts, 1),
> + GROUP(pwm_d_x15, 1),
> + GROUP(pwm_e_x16, 1),
> +
> + /*bank X func2 */
> + GROUP(i2c2_sck_x0, 2),
> + GROUP(i2c2_sda_x1, 2),
> + GROUP(spi_a_mosi_x2, 2),
> + GROUP(spi_a_ss0_x3, 2),
> + GROUP(spi_a_sclk_x4, 2),
> + GROUP(spi_a_miso_x5, 2),
> + GROUP(tdm_a_din1, 2),
> + GROUP(tdm_a_din0, 2),
> + GROUP(tdm_a_slv_fs, 2),
> + GROUP(tdm_a_slv_sclk, 2),
> + GROUP(i2c3_sck_x, 2),
> + GROUP(i2c3_sda_x, 2),
> + GROUP(pwm_d_x13, 2),
> + GROUP(pwm_e_x14, 2),
> + GROUP(i2c2_sck_x15, 2),
> + GROUP(i2c2_sda_x16, 2),
> +
> + /*bank X func3 */
> + GROUP(uart_c_tx_x0, 3),
> + GROUP(uart_c_rx_x1, 3),
> + GROUP(uart_c_cts, 3),
> + GROUP(uart_c_rts, 3),
> + GROUP(pdm_din0_x, 3),
> + GROUP(pdm_din1_x, 3),
> + GROUP(pdm_din2_x, 3),
> + GROUP(pdm_dclk_x, 3),
> + GROUP(uart_c_tx_x15, 3),
> + GROUP(uart_c_rx_x16, 3),
> +
> + /*bank X func4 */
> + GROUP(pwm_e_x2, 4),
> + GROUP(pwm_f_x, 4),
> + GROUP(spi_a_mosi_x7, 4),
> + GROUP(spi_a_miso_x8, 4),
> + GROUP(spi_a_ss0_x9, 4),
> + GROUP(spi_a_sclk_x10, 4),
> +
> + /*bank X func5 */
> + GROUP(uart_b_tx_x, 5),
> + GROUP(uart_b_rx_x, 5),
> + GROUP(i2c1_sda_x, 5),
> + GROUP(i2c1_sck_x, 5),
> +
> + /*bank X func6 */
> + GROUP(pwm_a_x7, 6),
> + GROUP(pwm_b_x, 6),
> + GROUP(pwm_c_x, 6),
> + GROUP(pwm_d_x10, 6),
> +
> + /*bank X func7 */
> + GROUP(gen_clk_x, 7),
> +
> + /*bank F func1 */
> + GROUP(uart_b_tx_f, 1),
> + GROUP(uart_b_rx_f, 1),
> + GROUP(remote_input_f, 1),
> + GROUP(jtag_a_clk, 1),
> + GROUP(jtag_a_tms, 1),
> + GROUP(jtag_a_tdi, 1),
> + GROUP(jtag_a_tdo, 1),
> + GROUP(gen_clk_f8, 1),
> + GROUP(pwm_a_f10, 1),
> + GROUP(i2c0_sck_f11, 1),
> + GROUP(i2c0_sda_f12, 1),
> +
> + /*bank F func2 */
> + GROUP(clk_32k_in, 2),
> + GROUP(pwm_e_f, 2),
> + GROUP(pwm_f_f4, 2),
> + GROUP(remote_out, 2),
> + GROUP(spdif_in_f6, 2),
> + GROUP(spdif_in_f7, 2),
> + GROUP(pwm_a_hiz_f8, 2),
> + GROUP(pwm_a_hiz_f10, 2),
> + GROUP(pwm_d_f, 2),
> + GROUP(pwm_f_f12, 2),
> +
> + /*bank F func3 */
> + GROUP(pwm_c_f3, 3),
> + GROUP(swclk, 3),
> + GROUP(swdio, 3),
> + GROUP(pwm_a_f6, 3),
> + GROUP(pwm_b_f, 3),
> + GROUP(pwm_c_f8, 3),
> + GROUP(clk25, 3),
> + GROUP(i2c_slave_sck_f, 3),
> + GROUP(i2c_slave_sda_f, 3),
> +
> + /*bank F func4 */
> + GROUP(cec_a, 4),
> + GROUP(i2c3_sck_f, 4),
> + GROUP(i2c3_sda_f, 4),
> + GROUP(pmw_a_hiz_f6, 4),
> + GROUP(pwm_b_hiz, 4),
> + GROUP(pwm_c_hiz, 4),
> + GROUP(i2c0_sck_f9, 4),
> + GROUP(i2c0_sda_f10, 4),
> +
> + /*bank F func5 */
> + GROUP(cec_b, 5),
> + GROUP(clk12_24, 5),
> +
> + /*bank F func7 */
> + GROUP(gen_clk_f10, 7),
> +
> + /*bank A func1 */
> + GROUP(mclk_0, 1),
> + GROUP(tdm_b_sclk, 1),
> + GROUP(tdm_b_fs, 1),
> + GROUP(tdm_b_dout0, 1),
> + GROUP(tdm_b_dout1, 1),
> + GROUP(tdm_b_dout2, 1),
> + GROUP(tdm_b_dout3, 1),
> + GROUP(tdm_b_dout4, 1),
> + GROUP(tdm_b_dout5, 1),
> + GROUP(remote_input_a, 1),
> +
> + /*bank A func2 */
> + GROUP(pwm_e_a, 2),
> + GROUP(tdm_b_slv_sclk, 2),
> + GROUP(tdm_b_slv_fs, 2),
> + GROUP(tdm_b_din0, 2),
> + GROUP(tdm_b_din1, 2),
> + GROUP(tdm_b_din2, 2),
> + GROUP(i2c1_sda_a, 2),
> + GROUP(i2c1_sck_a, 2),
> +
> + /*bank A func3 */
> + GROUP(i2c2_sck_a4, 3),
> + GROUP(i2c2_sda_a5, 3),
> + GROUP(pdm_din2_a, 3),
> + GROUP(pdm_din1_a, 3),
> + GROUP(pdm_din0_a, 3),
> + GROUP(pdm_dclk, 3),
> + GROUP(pwm_c_a, 3),
> + GROUP(pwm_b_a, 3),
> +
> + /*bank A func4 */
> + GROUP(pwm_a_a, 4),
> + GROUP(spi_a_mosi_a, 4),
> + GROUP(spi_a_miso_a, 4),
> + GROUP(spi_a_ss0_a, 4),
> + GROUP(spi_a_sclk_a, 4),
> + GROUP(i2c_slave_sck_a, 4),
> + GROUP(i2c_slave_sda_a, 4),
> +
> + /*bank A func5 */
> + GROUP(mclk_vad, 5),
> + GROUP(tdm_vad_sclk_a1, 5),
> + GROUP(tdm_vad_fs_a2, 5),
> + GROUP(tdm_vad_sclk_a5, 5),
> + GROUP(tdm_vad_fs_a6, 5),
> + GROUP(i2c2_sck_a8, 5),
> + GROUP(i2c2_sda_a9, 5),
> +
> + /*bank A func6 */
> + GROUP(tst_out0, 6),
> + GROUP(tst_out1, 6),
> + GROUP(tst_out2, 6),
> + GROUP(tst_out3, 6),
> + GROUP(tst_out4, 6),
> + GROUP(tst_out5, 6),
> + GROUP(tst_out6, 6),
> + GROUP(tst_out7, 6),
> + GROUP(tst_out8, 6),
> + GROUP(tst_out9, 6),
> + GROUP(tst_out10, 6),
> + GROUP(tst_out11, 6),
> +
> + /*bank A func7 */
> + GROUP(mute_key, 7),
> + GROUP(mute_en, 7),
> + GROUP(gen_clk_a, 7),
> +};
> +
> +static const char * const gpio_periphs_groups[] = {
> + "GPIOP_0", "GPIOP_1", "GPIOP_2", "GPIOP_3", "GPIOP_4",
> + "GPIOP_5", "GPIOP_6", "GPIOP_7", "GPIOP_8", "GPIOP_9",
> + "GPIOP_10", "GPIOP_11", "GPIOP_12",
> +
> + "GPIOB_0", "GPIOB_1", "GPIOB_2", "GPIOB_3", "GPIOB_4",
> + "GPIOB_5", "GPIOB_6",
> +
> + "GPIOX_0", "GPIOX_1", "GPIOX_2", "GPIOX_3", "GPIOX_4",
> + "GPIOX_5", "GPIOX_6", "GPIOX_7", "GPIOX_8", "GPIOX_9",
> + "GPIOX_10", "GPIOX_11", "GPIOX_12", "GPIOX_13", "GPIOX_14",
> + "GPIOX_15", "GPIOX_16",
> +
> + "GPIOF_0", "GPIOF_1", "GPIOF_2", "GPIOF_3", "GPIOF_4",
> + "GPIOF_5", "GPIOF_6", "GPIOF_7", "GPIOF_8", "GPIOF_9",
> + "GPIOF_10", "GPIOF_11", "GPIOF_12",
> +
> + "GPIOA_0", "GPIOA_1", "GPIOA_2", "GPIOA_3", "GPIOA_4",
> + "GPIOA_5", "GPIOA_6", "GPIOA_7", "GPIOA_8", "GPIOA_9",
> + "GPIOA_10", "GPIOA_11",
> +};
> +
> +static const char * const psram_groups[] = {
> + "psram_clkn", "psram_clkp", "psram_ce_n", "psram_rst_n", "psram_adq0",
> + "psram_adq1", "psram_adq2", "psram_adq3", "psram_adq4", "psram_adq5",
> + "psram_adq6", "psram_adq7", "psram_dqs_dm",
> +};
> +
> +static const char * const pwm_a_groups[] = {
> + "pwm_a_x6", "pwm_a_x7", "pwm_a_f10", "pwm_a_f6", "pwm_a_a",
> +};
> +
> +static const char * const pwm_b_groups[] = {
> + "pwm_b_x", "pwm_b_f", "pwm_b_a",
> +};
> +
> +static const char * const pwm_c_groups[] = {
> + "pwm_c_x", "pwm_c_f3", "pwm_c_f8", "pwm_c_a",
> +};
> +
> +static const char * const pwm_d_groups[] = {
> + "pwm_d_x15", "pwm_d_x13", "pwm_d_x10", "pwm_d_f",
> +};
> +
> +static const char * const pwm_e_groups[] = {
> + "pwm_e_p", "pwm_e_x16", "pwm_e_x14", "pwm_e_x2", "pwm_e_f",
> + "pwm_e_a",
> +};
> +
> +static const char * const pwm_f_groups[] = {
> + "pwm_f_b", "pwm_f_x", "pwm_f_f4", "pwm_f_f12",
> +};
> +
> +static const char * const pwm_a_hiz_groups[] = {
> + "pwm_a_hiz_f8", "pwm_a_hiz_f10", "pwm_a_hiz_f6",
> +};
> +
> +static const char * const pwm_b_hiz_groups[] = {
> + "pwm_b_hiz",
> +};
> +
> +static const char * const pwm_c_hiz_groups[] = {
> + "pwm_c_hiz",
> +};
> +
> +static const char * const spif_groups[] = {
> + "spif_mo", "spif_mi", "spif_wp_n", "spif_hold_n", "spif_clk",
> + "spif_cs",
> +};
> +
> +static const char * const sdcard_groups[] = {
> + "sdcard_d0_b", "sdcard_d1_b", "sdcard_d2_b", "sdcard_d3_b",
> + "sdcard_clk_b", "sdcard_cmd_b",
> +
> + "sdcard_d0_x", "sdcard_d1_x", "sdcard_d2_x", "sdcard_d3_x",
> + "sdcard_clk_x", "sdcard_cmd_x",
> +};
> +
> +static const char * const tdm_a_groups[] = {
> + "tdm_a_din0", "tdm_a_din1", "tdm_a_fs", "tdm_a_sclk",
> + "tdm_a_slv_fs", "tdm_a_slv_sclk", "tdm_a_dout0", "tdm_a_dout1",
> +};
> +
> +static const char * const uart_a_groups[] = {
> + "uart_a_tx", "uart_a_rx", "uart_a_cts", "uart_a_rts",
> +};
> +
> +static const char * const uart_b_groups[] = {
> + "uart_b_tx_x", "uart_b_rx_x", "uart_b_tx_f", "uart_b_rx_f",
> +};
> +
> +static const char * const uart_c_groups[] = {
> + "uart_c_tx_x0", "uart_c_rx_x1", "uart_c_cts", "uart_c_rts",
> + "uart_c_tx_x15", "uart_c_rx_x16",
> +};
> +
> +static const char * const i2c0_groups[] = {
> + "i2c0_sck_f11", "i2c0_sda_f12", "i2c0_sck_f9", "i2c0_sda_f10",
> +};
> +
> +static const char * const i2c1_groups[] = {
> + "i2c1_sda_x", "i2c1_sck_x", "i2c1_sda_a", "i2c1_sck_a",
> +};
> +
> +static const char * const i2c2_groups[] = {
> + "i2c2_sck_x0", "i2c2_sda_x1", "i2c2_sck_x15", "i2c2_sda_x16",
> + "i2c2_sck_a4", "i2c2_sda_a5", "i2c2_sck_a8", "i2c2_sda_a9",
> +};
> +
> +static const char * const i2c3_groups[] = {
> + "i2c3_sck_x", "i2c3_sda_x", "i2c3_sck_f", "i2c3_sda_f",
> +};
> +
> +static const char * const i2c_slave_groups[] = {
> + "i2c_slave_sda_a", "i2c_slave_sck_a",
> + "i2c_slave_sda_f", "i2c_slave_sck_f",
> +};
> +
> +static const char * const spi_a_groups[] = {
> + "spi_a_mosi_x2", "spi_a_ss0_x3", "spi_a_sclk_x4", "spi_a_miso_x5",
> + "spi_a_mosi_x7", "spi_a_miso_x8", "spi_a_ss0_x9", "spi_a_sclk_x10",
> +
> + "spi_a_mosi_a", "spi_a_miso_a", "spi_a_ss0_a", "spi_a_sclk_a",
> +};
> +
> +static const char * const pdm_groups[] = {
> + "pdm_din0_x", "pdm_din1_x", "pdm_din2_x", "pdm_dclk_x", "pdm_din2_a",
> + "pdm_din1_a", "pdm_din0_a", "pdm_dclk",
> +};
> +
> +static const char * const gen_clk_groups[] = {
> + "gen_clk_x", "gen_clk_f8", "gen_clk_f10", "gen_clk_a",
> +};
> +
> +static const char * const remote_input_groups[] = {
> + "remote_input_f",
> + "remote_input_a",
> +};
> +
> +static const char * const jtag_a_groups[] = {
> + "jtag_a_clk", "jtag_a_tms", "jtag_a_tdi", "jtag_a_tdo",
> +};
> +
> +static const char * const clk_32k_in_groups[] = {
> + "clk_32k_in",
> +};
> +
> +static const char * const remote_out_groups[] = {
> + "remote_out",
> +};
> +
> +static const char * const spdif_in_groups[] = {
> + "spdif_in_f6", "spdif_in_f7",
> +};
> +
> +static const char * const sw_groups[] = {
> + "swclk", "swdio",
> +};
> +
> +static const char * const clk25_groups[] = {
> + "clk_25",
> +};
> +
> +static const char * const cec_a_groups[] = {
> + "cec_a",
> +};
> +
> +static const char * const cec_b_groups[] = {
> + "cec_b",
> +};
> +
> +static const char * const clk12_24_groups[] = {
> + "clk12_24",
> +};
> +
> +static const char * const mclk_0_groups[] = {
> + "mclk_0",
> +};
> +
> +static const char * const tdm_b_groups[] = {
> + "tdm_b_din0", "tdm_b_din1", "tdm_b_din2",
> + "tdm_b_sclk", "tdm_b_fs", "tdm_b_dout0", "tdm_b_dout1",
> + "tdm_b_dout2", "tdm_b_dout3", "tdm_b_dout4", "tdm_b_dout5",
> + "tdm_b_slv_sclk", "tdm_b_slv_fs",
> +};
> +
> +static const char * const mclk_vad_groups[] = {
> + "mclk_vad",
> +};
> +
> +static const char * const tdm_vad_groups[] = {
> + "tdm_vad_sclk_a1", "tdm_vad_fs_a2", "tdm_vad_sclk_a5", "tdm_vad_fs_a6",
> +};
> +
> +static const char * const tst_out_groups[] = {
> + "tst_out0", "tst_out1", "tst_out2", "tst_out3",
> + "tst_out4", "tst_out5", "tst_out6", "tst_out7",
> + "tst_out8", "tst_out9", "tst_out10", "tst_out11",
> +};
> +
> +static const char * const mute_groups[] = {
> + "mute_key", "mute_en",
> +};
> +
> +static struct meson_pmx_func meson_a1_periphs_functions[] = {
> + FUNCTION(gpio_periphs),
> + FUNCTION(psram),
> + FUNCTION(pwm_a),
> + FUNCTION(pwm_b),
> + FUNCTION(pwm_c),
> + FUNCTION(pwm_d),
> + FUNCTION(pwm_e),
> + FUNCTION(pwm_f),
> + FUNCTION(pwm_a_hiz),
> + FUNCTION(pwm_b_hiz),
> + FUNCTION(pwm_c_hiz),
> + FUNCTION(spif),
> + FUNCTION(sdcard),
> + FUNCTION(tdm_a),
> + FUNCTION(uart_a),
> + FUNCTION(uart_b),
> + FUNCTION(uart_c),
> + FUNCTION(i2c0),
> + FUNCTION(i2c1),
> + FUNCTION(i2c2),
> + FUNCTION(i2c3),
> + FUNCTION(spi_a),
> + FUNCTION(pdm),
> + FUNCTION(gen_clk),
> + FUNCTION(remote_input),
> + FUNCTION(jtag_a),
> + FUNCTION(clk_32k_in),
> + FUNCTION(remote_out),
> + FUNCTION(spdif_in),
> + FUNCTION(sw),
> + FUNCTION(clk25),
> + FUNCTION(cec_a),
> + FUNCTION(cec_b),
> + FUNCTION(clk12_24),
> + FUNCTION(mclk_0),
> + FUNCTION(tdm_b),
> + FUNCTION(mclk_vad),
> + FUNCTION(tdm_vad),
> + FUNCTION(tst_out),
> + FUNCTION(mute),
> +};
> +
> +static struct meson_bank meson_a1_periphs_banks[] = {
> + /* name first last irq pullen pull dir out in ds*/
> + BANK_DS("P", GPIOP_0, GPIOP_12, 0, 12, 0x3, 0, 0x4, 0,
> + 0x2, 0, 0x1, 0, 0x0, 0, 0x5, 0),
> + BANK_DS("B", GPIOB_0, GPIOB_6, 13, 19, 0x13, 0, 0x14, 0,
> + 0x12, 0, 0x11, 0, 0x10, 0, 0x15, 0),
> + BANK_DS("X", GPIOX_0, GPIOX_16, 20, 36, 0x23, 0, 0x24, 0,
> + 0x22, 0, 0x21, 0, 0x20, 0, 0x25, 0),
> + BANK_DS("F", GPIOF_0, GPIOF_12, 37, 49, 0x33, 0, 0x34, 0,
> + 0x32, 0, 0x31, 0, 0x30, 0, 0x35, 0),
> + BANK_DS("A", GPIOA_0, GPIOA_11, 50, 61, 0x43, 0, 0x44, 0,
> + 0x42, 0, 0x41, 0, 0x40, 0, 0x45, 0),
> +};
> +
> +static struct meson_pmx_bank meson_a1_periphs_pmx_banks[] = {
> + /* name first lask reg offset */
> + BANK_PMX("P", GPIOP_0, GPIOP_12, 0x0, 0),
> + BANK_PMX("B", GPIOB_0, GPIOB_6, 0x2, 0),
> + BANK_PMX("X", GPIOX_0, GPIOX_16, 0x3, 0),
> + BANK_PMX("F", GPIOF_0, GPIOF_12, 0x6, 0),
> + BANK_PMX("A", GPIOA_0, GPIOA_11, 0x8, 0),
> +};
> +
> +static struct meson_axg_pmx_data meson_a1_periphs_pmx_banks_data = {
> + .pmx_banks = meson_a1_periphs_pmx_banks,
> + .num_pmx_banks = ARRAY_SIZE(meson_a1_periphs_pmx_banks),
> +};
> +
> +static struct meson_pinctrl_data meson_a1_periphs_pinctrl_data = {
> + .name = "periphs-banks",
> + .pins = meson_a1_periphs_pins,
> + .groups = meson_a1_periphs_groups,
> + .funcs = meson_a1_periphs_functions,
> + .banks = meson_a1_periphs_banks,
> + .num_pins = ARRAY_SIZE(meson_a1_periphs_pins),
> + .num_groups = ARRAY_SIZE(meson_a1_periphs_groups),
> + .num_funcs = ARRAY_SIZE(meson_a1_periphs_functions),
> + .num_banks = ARRAY_SIZE(meson_a1_periphs_banks),
> + .pmx_ops = &meson_axg_pmx_ops,
> + .pmx_data = &meson_a1_periphs_pmx_banks_data,
> + .reg_layout = A1_LAYOUT,
> +};
> +
> +static const struct of_device_id meson_a1_pinctrl_dt_match[] = {
> + {
> + .compatible = "amlogic,meson-a1-periphs-pinctrl",
> + .data = &meson_a1_periphs_pinctrl_data,
> + },
> + { },
> +};
> +
> +static struct platform_driver meson_a1_pinctrl_driver = {
> + .probe = meson_pinctrl_probe,
> + .driver = {
> + .name = "meson-a1-pinctrl",
> + .of_match_table = meson_a1_pinctrl_dt_match,
> + },
> +};
> +
> +builtin_platform_driver(meson_a1_pinctrl_driver);
> diff --git a/drivers/pinctrl/meson/pinctrl-meson.c b/drivers/pinctrl/meson/pinctrl-meson.c
> index 8bba9d0..885b89d 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson.c
> @@ -688,8 +688,12 @@ static int meson_pinctrl_parse_dt(struct meson_pinctrl *pc,
>
> pc->reg_ds = meson_map_resource(pc, gpio_np, "ds");
> if (IS_ERR(pc->reg_ds)) {
> - dev_dbg(pc->dev, "ds registers not found - skipping\n");
> - pc->reg_ds = NULL;
> + if (pc->data->reg_layout == A1_LAYOUT) {
> + pc->reg_ds = pc->reg_pullen;
IMO, this kind of ID based init fixup is not going to scale and will
lead to something difficult to maintain in the end.
The way the different register sets interract with each other is already
pretty complex to follow.
You could rework this in 2 different ways:
#1 - Have the generic function parse all the register sets and have all
drivers provide a specific (as in gxbb, gxl, axg, etc ...) function to :
- Verify the expected sets have been provided
- Make assignement fixup as above if necessary
#2 - Rework the driver to have only one single register region
I think one of your colleague previously mentionned this was not
possible. It is still unclear to me why ...
> + } else {
> + dev_dbg(pc->dev, "ds registers not found - skipping\n");
> + pc->reg_ds = NULL;
> + }
> }
>
> return 0;
> diff --git a/drivers/pinctrl/meson/pinctrl-meson.h b/drivers/pinctrl/meson/pinctrl-meson.h
> index c696f32..3d0c58d 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson.h
> +++ b/drivers/pinctrl/meson/pinctrl-meson.h
> @@ -80,6 +80,14 @@ enum meson_pinconf_drv {
> };
>
> /**
> + * enum meson_reg_layout - identify two types of reg layout
> + */
> +enum meson_reg_layout {
> + LEGACY_LAYOUT,
> + A1_LAYOUT,
> +};
> +
> +/**
> * struct meson bank
> *
> * @name: bank name
> @@ -114,6 +122,7 @@ struct meson_pinctrl_data {
> unsigned int num_banks;
> const struct pinmux_ops *pmx_ops;
> void *pmx_data;
> + unsigned int reg_layout;
> };
>
> struct meson_pinctrl {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 03/11] coresight: etm4x: Add missing API to set EL match on address filters
From: Suzuki K Poulose @ 2019-09-17 9:31 UTC (permalink / raw)
To: mike.leach, mathieu.poirier, linux-arm-kernel, coresight,
linux-doc
Cc: gregkh, corbet
In-Reply-To: <20190829213321.4092-4-mike.leach@linaro.org>
Hi Mike,
On 29/08/2019 22:33, Mike Leach wrote:
> TRCACATRn registers have match bits for secure and non-secure exception
> levels which are not accessible by the sysfs API.
> This adds a new sysfs parameter to enable this - addr_exlevel_s_ns.
>
Looks good to me. Some minor nits below.
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-sysfs.c | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index cc8156318018..b520f3c1521f 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -1233,6 +1233,47 @@ static ssize_t addr_context_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(addr_context);
>
> +static ssize_t addr_exlevel_s_ns_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->addr_idx;
> + val = BMVAL(config->addr_acc[idx], 14, 8);
> + spin_unlock(&drvdata->spinlock);
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (kstrtoul(buf, 16, &val))
> + return -EINVAL;
Can this be 0 instead of 16 to accept any base ?
> +
> + if (val & ~0x7F)
minor nit: Do we need to use (GENMASK(14, 8) >> 8) here instead of
hard coding the mask ?
> + return -EINVAL;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->addr_idx;
> + /* clear Exlevel_ns & Exlevel_s bits[14:12, 11:8] */
It may be worth adding a comment that bit[15] is RES0.
> + config->addr_acc[idx] &= ~(GENMASK(14, 8));
> + config->addr_acc[idx] |= (val << 8);
> + spin_unlock(&drvdata->spinlock);
> + return size;
> +}
> +static DEVICE_ATTR_RW(addr_exlevel_s_ns);
> +
> static ssize_t seq_idx_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -2038,6 +2079,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
> &dev_attr_addr_stop.attr,
> &dev_attr_addr_ctxtype.attr,
> &dev_attr_addr_context.attr,
> + &dev_attr_addr_exlevel_s_ns.attr,
> &dev_attr_seq_idx.attr,
> &dev_attr_seq_state.attr,
> &dev_attr_seq_event.attr,
Either ways, irrespective of the above comments :
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 02/11] coresight: etm4x: Fix input validation for sysfs.
From: Suzuki K Poulose @ 2019-09-17 9:33 UTC (permalink / raw)
To: mike.leach, mathieu.poirier, linux-arm-kernel, coresight,
linux-doc
Cc: gregkh, corbet
In-Reply-To: <20190829213321.4092-3-mike.leach@linaro.org>
On 29/08/2019 22:33, Mike Leach wrote:
> A number of issues are fixed relating to sysfs input validation:-
>
> 1) bb_ctrl_store() - incorrect compare of bit select field to absolute
> value. Reworked per ETMv4 specification.
> 2) seq_event_store() - incorrect mask value - register has two
> event values.
> 3) cyc_threshold_store() - must mask with max before checking min
> otherwise wrapped values can set illegal value below min.
> 4) res_ctrl_store() - update to mask off all res0 bits.
>
> Reviewed-by: Leo Yan <leo.yan@linaro.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
Does this need to goto stable ? May be add a Fixes tag ? It fixes real
issues with the values that could be programmed into these registers.
Cheers
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put
From: Zenghui Yu @ 2019-09-17 9:31 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm; +Cc: Andre Przywara
In-Reply-To: <07ddb304-9a7a-64a3-386a-96eea4516346@kernel.org>
On 2019/9/17 16:35, Marc Zyngier wrote:
> Hi Zenghui,
>
> On 17/09/2019 09:10, Zenghui Yu wrote:
>> Hi Marc,
>>
>> I've run this patch on my box and got the following messages:
>>
>> ---8<
>>
>> [ 2258.490030] BUG: sleeping function called from invalid context at
>> kernel/irq/manage.c:138
>> [ 2258.490034] in_atomic(): 1, irqs_disabled(): 0, pid: 59278, name: CPU
>> 0/KVM
>> [ 2258.490039] CPU: 32 PID: 59278 Comm: CPU 0/KVM Kdump: loaded Tainted:
>> G W 5.3.0+ #26
>> [ 2258.490041] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.58
>> 10/29/2018
>> [ 2258.490043] Call trace:
>> [ 2258.490056] dump_backtrace+0x0/0x188
>> [ 2258.490060] show_stack+0x24/0x30
>> [ 2258.490066] dump_stack+0xb0/0xf4
>> [ 2258.490072] ___might_sleep+0x10c/0x130
>> [ 2258.490074] __might_sleep+0x58/0x90
>> [ 2258.490078] synchronize_irq+0x58/0xd8
>> [ 2258.490079] disable_irq+0x2c/0x38
>> [ 2258.490083] vgic_v4_load+0x9c/0xc0
>> [ 2258.490084] vgic_v3_load+0x94/0x170
>> [ 2258.490088] kvm_vgic_load+0x3c/0x60
>> [ 2258.490092] kvm_arch_vcpu_load+0xd4/0x1d0
>> [ 2258.490095] vcpu_load+0x50/0x70
>> [ 2258.490097] kvm_arch_vcpu_ioctl_run+0x94/0x978
>> [ 2258.490098] kvm_vcpu_ioctl+0x3d8/0xa28
>> [ 2258.490104] do_vfs_ioctl+0xc4/0x8e8
>> [ 2258.490106] ksys_ioctl+0x8c/0xa0
>> [ 2258.490108] __arm64_sys_ioctl+0x28/0x58
>> [ 2258.490112] el0_svc_common.constprop.0+0x7c/0x188
>> [ 2258.490114] el0_svc_handler+0x34/0xb8
>> [ 2258.490117] el0_svc+0x8/0xc
>> [ 2259.497070] BUG: sleeping function called from invalid context at
>> kernel/irq/manage.c:138
>
> Thanks for reporting this.
>
> [...]
>
>> The logic of disabling the doorbell interrupt in vgic_v4_load() might
>> need a fix?
>
> The logic itself looks OK, but doing a full blown disable_irq() is both
> counter productive (if we race against a doorbell, there is not much we
> can do about it and waiting for it to end is pointless) and wrong
> (despite the comment that this can be called in IRQ context, it is
> pretty unsafe to do so).
>
> Can you try turning it into a disable_irq_nosync() and let me know if
> that helps?
Yes, the above BUG messages disappear with disable_irq_nosync().
But this time I got the following WARNING:
[ 921.004322] ======================================================
[ 921.010489] WARNING: possible circular locking dependency detected
[ 921.016657] 5.3.0+ #27 Not tainted
[ 921.020132] ------------------------------------------------------
[ 921.026299] CPU 1/KVM/816 is trying to acquire lock:
[ 921.031250] ffff002fb42b35b0 (&irq_desc_lock_class){-.-.}, at:
__irq_get_desc_lock+0x60/0xa0
[ 921.039684]
but task is already holding lock:
[ 921.045503] ffff002fbbb07258 (&rq->lock){-.-.}, at: __schedule+0xd4/0x988
[ 921.052283]
which lock already depends on the new lock.
[ 921.060445]
the existing dependency chain (in reverse order) is:
[ 921.067913]
-> #3 (&rq->lock){-.-.}:
[ 921.072955] lock_acquire+0xd4/0x268
[ 921.077041] _raw_spin_lock+0x44/0x58
[ 921.081212] task_fork_fair+0x54/0x160
[ 921.085471] sched_fork+0xfc/0x238
[ 921.089383] copy_process+0x474/0x1738
[ 921.093639] _do_fork+0x70/0x6e0
[ 921.097376] kernel_thread+0x70/0x98
[ 921.101459] rest_init+0x34/0x278
[ 921.105286] arch_call_rest_init+0x14/0x1c
[ 921.109891] start_kernel+0x548/0x574
[ 921.114060]
-> #2 (&p->pi_lock){-.-.}:
[ 921.119275] lock_acquire+0xd4/0x268
[ 921.123360] _raw_spin_lock_irqsave+0x60/0x80
[ 921.128225] try_to_wake_up+0x60/0xbf0
[ 921.132483] wake_up_process+0x28/0x38
[ 921.136739] __up.isra.0+0x58/0x68
[ 921.140649] up+0x64/0x80
[ 921.143777] __up_console_sem+0x60/0xa8
[ 921.148121] console_unlock+0x31c/0x5f0
[ 921.152465] vprintk_emit+0x28c/0x438
[ 921.156637] dev_vprintk_emit+0x1d8/0x218
[ 921.161157] dev_printk_emit+0x84/0xa8
[ 921.165414] __dev_printk+0x78/0xa0
[ 921.169411] _dev_info+0x7c/0xa0
[ 921.173148] hub_port_init+0xa5c/0xb68
[ 921.177405] hub_port_connect+0x2f0/0xa08
[ 921.181923] port_event+0x548/0x828
[ 921.185920] hub_event+0x20c/0x418
[ 921.189831] process_one_work+0x24c/0x700
[ 921.194349] worker_thread+0x4c/0x448
[ 921.198519] kthread+0x130/0x138
[ 921.202256] ret_from_fork+0x10/0x18
[ 921.206338]
-> #1 ((console_sem).lock){-.-.}:
[ 921.212160] lock_acquire+0xd4/0x268
[ 921.216244] _raw_spin_lock_irqsave+0x60/0x80
[ 921.221110] down_trylock+0x20/0x50
[ 921.225106] __down_trylock_console_sem+0x50/0xe0
[ 921.230320] console_trylock+0x20/0x88
[ 921.234577] vprintk_emit+0x18c/0x438
[ 921.238747] vprintk_default+0x54/0x90
[ 921.243004] vprintk_func+0xe4/0x268
[ 921.247087] printk+0x74/0x94
[ 921.250564] show_interrupts+0x4dc/0x4f8
[ 921.254997] seq_read+0x2b4/0x4e0
[ 921.258820] proc_reg_read+0x94/0xe8
[ 921.262905] __vfs_read+0x48/0x80
[ 921.266729] vfs_read+0xa0/0x160
[ 921.270465] ksys_read+0x74/0xf8
[ 921.274202] __arm64_sys_read+0x24/0x30
[ 921.278547] el0_svc_common.constprop.0+0x80/0x1b8
[ 921.283846] el0_svc_handler+0x34/0xb8
[ 921.288102] el0_svc+0x8/0xc
[ 921.291491]
-> #0 (&irq_desc_lock_class){-.-.}:
[ 921.297486] check_prev_add+0xac/0x9f8
[ 921.301743] __lock_acquire+0x1164/0x12b8
[ 921.306260] lock_acquire+0xd4/0x268
[ 921.310344] _raw_spin_lock_irqsave+0x60/0x80
[ 921.315209] __irq_get_desc_lock+0x60/0xa0
[ 921.319814] irq_set_vcpu_affinity+0x48/0xc8
[ 921.324592] its_schedule_vpe+0x68/0xb0
[ 921.328937] vgic_v4_put+0x80/0xa8
[ 921.332846] vgic_v3_put+0x24/0xf0
[ 921.336756] kvm_vgic_put+0x3c/0x60
[ 921.340754] kvm_arch_vcpu_put+0x38/0x60
[ 921.345184] kvm_sched_out+0x38/0x48
[ 921.349267] __schedule+0x5a4/0x988
[ 921.353263] schedule+0x40/0xc8
[ 921.356912] kvm_arch_vcpu_ioctl_run+0x130/0xb08
[ 921.362037] kvm_vcpu_ioctl+0x3e0/0xb08
[ 921.366381] do_vfs_ioctl+0xc4/0x890
[ 921.370464] ksys_ioctl+0x8c/0xa0
[ 921.374287] __arm64_sys_ioctl+0x28/0x38
[ 921.378717] el0_svc_common.constprop.0+0x80/0x1b8
[ 921.384016] el0_svc_handler+0x34/0xb8
[ 921.388272] el0_svc+0x8/0xc
[ 921.391660]
other info that might help us debug this:
[ 921.399649] Chain exists of:
&irq_desc_lock_class --> &p->pi_lock --> &rq->lock
[ 921.409984] Possible unsafe locking scenario:
[ 921.415889] CPU0 CPU1
[ 921.420405] ---- ----
[ 921.424921] lock(&rq->lock);
[ 921.427962] lock(&p->pi_lock);
[ 921.433694] lock(&rq->lock);
[ 921.439253] lock(&irq_desc_lock_class);
[ 921.443249]
*** DEADLOCK ***
[ 921.449155] 2 locks held by CPU 1/KVM/816:
[ 921.453237] #0: ffff002fa3862aa8 (&vcpu->mutex){+.+.}, at:
kvm_vcpu_ioctl+0x80/0xb08
[ 921.461055] #1: ffff002fbbb07258 (&rq->lock){-.-.}, at:
__schedule+0xd4/0x988
[ 921.468265]
stack backtrace:
[ 921.472610] CPU: 24 PID: 816 Comm: CPU 1/KVM Kdump: loaded Not
tainted 5.3.0+ #27
[ 921.480165] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.58
10/29/2018
[ 921.487372] Call trace:
[ 921.489806] dump_backtrace+0x0/0x188
[ 921.493455] show_stack+0x24/0x30
[ 921.496757] dump_stack+0xcc/0x134
[ 921.500146] print_circular_bug.isra.20+0x204/0x2d8
[ 921.505011] check_noncircular+0x130/0x1c0
[ 921.509094] check_prev_add+0xac/0x9f8
[ 921.512829] __lock_acquire+0x1164/0x12b8
[ 921.516825] lock_acquire+0xd4/0x268
[ 921.520388] _raw_spin_lock_irqsave+0x60/0x80
[ 921.524732] __irq_get_desc_lock+0x60/0xa0
[ 921.528815] irq_set_vcpu_affinity+0x48/0xc8
[ 921.533071] its_schedule_vpe+0x68/0xb0
[ 921.536894] vgic_v4_put+0x80/0xa8
[ 921.540282] vgic_v3_put+0x24/0xf0
[ 921.543671] kvm_vgic_put+0x3c/0x60
[ 921.547147] kvm_arch_vcpu_put+0x38/0x60
[ 921.551057] kvm_sched_out+0x38/0x48
[ 921.554618] __schedule+0x5a4/0x988
[ 921.558094] schedule+0x40/0xc8
[ 921.561222] kvm_arch_vcpu_ioctl_run+0x130/0xb08
[ 921.565826] kvm_vcpu_ioctl+0x3e0/0xb08
[ 921.569649] do_vfs_ioctl+0xc4/0x890
[ 921.573211] ksys_ioctl+0x8c/0xa0
[ 921.576513] __arm64_sys_ioctl+0x28/0x38
[ 921.580423] el0_svc_common.constprop.0+0x80/0x1b8
[ 921.585201] el0_svc_handler+0x34/0xb8
[ 921.588937] el0_svc+0x8/0xc
Thanks,
zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/2] of: Let of_for_each_phandle fallback to non-negative cell_count
From: Geert Uytterhoeven @ 2019-09-17 9:40 UTC (permalink / raw)
To: Rob Herring, Uwe Kleine-König
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Frank Rowand, Joerg Roedel, Linux Kernel Mailing List,
Linux-Renesas, Wolfram Sang, Linux IOMMU, linux-mediatek,
Linux I2C, Sascha Hauer, Matthias Brugger, Will Deacon, Linux ARM,
Robin Murphy
In-Reply-To: <20190913215809.GA11833@bogus>
Hi Rob, Uwe,
On Fri, Sep 13, 2019 at 11:58 PM Rob Herring <robh@kernel.org> wrote:
> On Sat, 24 Aug 2019 15:28:46 +0200, =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= wrote:
> > Referencing device tree nodes from a property allows to pass arguments.
> > This is for example used for referencing gpios. This looks as follows:
> >
> > gpio_ctrl: gpio-controller {
> > #gpio-cells = <2>
> > ...
> > }
> >
> > someothernode {
> > gpios = <&gpio_ctrl 5 0 &gpio_ctrl 3 0>;
> > ...
> > }
> >
> > To know the number of arguments this must be either fixed, or the
> > referenced node is checked for a $cells_name (here: "#gpio-cells")
> > property and with this information the start of the second reference can
> > be determined.
> >
> > Currently regulators are referenced with no additional arguments. To
> > allow some optional arguments without having to change all referenced
> > nodes this change introduces a way to specify a default cell_count. So
> > when a phandle is parsed we check for the $cells_name property and use
> > it as before if present. If it is not present we fall back to
> > cells_count if non-negative and only fail if cells_count is smaller than
> > zero.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This is now commit e42ee61017f58cd9 ("of: Let of_for_each_phandle fallback
to non-negative cell_count") in robh/for-next, which causes a lock-up when
booting a shmobile_defconfig kernel on r8a7791/koelsch:
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 0-....: (2099 ticks this GP) idle=6fe/1/0x40000002
softirq=29/29 fqs=1050
(t=2100 jiffies g=-1131 q=0)
NMI backtrace for cpu 0
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.3.0-rc2-shmobile-00050-ge42ee61017f58cd9 #376
Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
[<c010f8ac>] (unwind_backtrace) from [<c010b620>] (show_stack+0x10/0x14)
[<c010b620>] (show_stack) from [<c073d038>] (dump_stack+0x7c/0x9c)
[<c073d038>] (dump_stack) from [<c0742e80>] (nmi_cpu_backtrace+0xa0/0xb8)
[<c0742e80>] (nmi_cpu_backtrace) from [<c0742f1c>]
(nmi_trigger_cpumask_backtrace+0x84/0x114)
[<c0742f1c>] (nmi_trigger_cpumask_backtrace) from [<c017d684>]
(rcu_dump_cpu_stacks+0xac/0xc8)
[<c017d684>] (rcu_dump_cpu_stacks) from [<c017a598>]
(rcu_sched_clock_irq+0x2ac/0x6b4)
[<c017a598>] (rcu_sched_clock_irq) from [<c0183980>]
(update_process_times+0x30/0x5c)
[<c0183980>] (update_process_times) from [<c01941a8>]
(tick_nohz_handler+0xcc/0x120)
[<c01941a8>] (tick_nohz_handler) from [<c05b1d40>]
(arch_timer_handler_virt+0x28/0x30)
[<c05b1d40>] (arch_timer_handler_virt) from [<c016c9e0>]
(handle_percpu_devid_irq+0xe8/0x21c)
[<c016c9e0>] (handle_percpu_devid_irq) from [<c0167a8c>]
(generic_handle_irq+0x18/0x28)
[<c0167a8c>] (generic_handle_irq) from [<c0167b3c>]
(__handle_domain_irq+0xa0/0xb4)
[<c0167b3c>] (__handle_domain_irq) from [<c03673ec>] (gic_handle_irq+0x58/0x90)
[<c03673ec>] (gic_handle_irq) from [<c0101a8c>] (__irq_svc+0x6c/0x90)
Exception stack(0xeb08dd30 to 0xeb08dd78)
dd20: c0cc7514 20000013 00000005 00003b27
dd40: eb7c4020 c0cc750c 00000051 00000051 20000013 c0c66b08 eb1cdc00 00000018
dd60: 00000000 eb08dd80 c05c1a38 c0756c00 20000013 ffffffff
[<c0101a8c>] (__irq_svc) from [<c0756c00>]
(_raw_spin_unlock_irqrestore+0x1c/0x20)
[<c0756c00>] (_raw_spin_unlock_irqrestore) from [<c05c1a38>]
(of_find_node_by_phandle+0xcc/0xf0)
[<c05c1a38>] (of_find_node_by_phandle) from [<c05c1bb8>]
(of_phandle_iterator_next+0x68/0x178)
[<c05c1bb8>] (of_phandle_iterator_next) from [<c05c22bc>]
(of_count_phandle_with_args+0x5c/0x7c)
[<c05c22bc>] (of_count_phandle_with_args) from [<c053fc38>]
(i2c_demux_pinctrl_probe+0x24/0x1fc)
[<c053fc38>] (i2c_demux_pinctrl_probe) from [<c04463c4>]
(platform_drv_probe+0x48/0x94)
[<c04463c4>] (platform_drv_probe) from [<c0444a20>] (really_probe+0x1f0/0x2b8)
[<c0444a20>] (really_probe) from [<c0444e68>] (driver_probe_device+0x140/0x158)
[<c0444e68>] (driver_probe_device) from [<c0444ff0>]
(device_driver_attach+0x44/0x5c)
[<c0444ff0>] (device_driver_attach) from [<c04450b4>]
(__driver_attach+0xac/0xb4)
[<c04450b4>] (__driver_attach) from [<c0443178>] (bus_for_each_dev+0x64/0xa0)
[<c0443178>] (bus_for_each_dev) from [<c04438a8>] (bus_add_driver+0x148/0x1a8)
[<c04438a8>] (bus_add_driver) from [<c0445ad0>] (driver_register+0xac/0xf0)
[<c0445ad0>] (driver_register) from [<c0b010b0>] (do_one_initcall+0xa8/0x1d4)
[<c0b010b0>] (do_one_initcall) from [<c0b01448>]
(kernel_init_freeable+0x26c/0x2c8)
[<c0b01448>] (kernel_init_freeable) from [<c0751c70>] (kernel_init+0x8/0x10c)
[<c0751c70>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xeb08dfb0 to 0xeb08dff8)
dfa0: 00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Presumably it loops forever, due to a conversion of -1 to unsigned
somewhere?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] net: stmmac: Fix ASSERT_RTNL() warning on suspend/resume
From: Loys Ollivier @ 2019-09-17 10:02 UTC (permalink / raw)
To: Russell King, Maxime Coquelin
Cc: Alexandre Torgue, netdev, Loys Ollivier, linux-kernel,
linux-stm32, Jose Abreu, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
rtnl_lock needs to be taken before calling phylink_start/stop to lock the
network stack.
Fix ASSERT_RTNL() warnings by protecting such calls with lock/unlock.
Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
Signed-off-by: Loys Ollivier <lollivier@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fd54c7c87485..485f33f57b43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4451,7 +4451,9 @@ int stmmac_suspend(struct device *dev)
if (!ndev || !netif_running(ndev))
return 0;
+ rtnl_lock();
phylink_stop(priv->phylink);
+ rtnl_unlock();
mutex_lock(&priv->lock);
@@ -4560,7 +4562,9 @@ int stmmac_resume(struct device *dev)
mutex_unlock(&priv->lock);
+ rtnl_lock();
phylink_start(priv->phylink);
+ rtnl_unlock();
return 0;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [GIT PULL 1/5] ARM: SoC platform updates for v5.4
From: Arnd Bergmann @ 2019-09-17 10:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: SoC Team, Linux ARM
In-Reply-To: <CAHk-=wjeGTRhpczCRRwHv=M+LCudK-x5jmu7-HP+1UHbCf=3_Q@mail.gmail.com>
On Tue, Sep 17, 2019 at 12:51 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Sep 16, 2019 at 9:32 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > ARM: SoC platform updates for v5.4
>
> Hmm.
>
> You now build iop-adma.c on other platforms, but that then causes this:
>
> drivers/dma/iop-adma.c: In function ‘__iop_adma_slot_cleanup’:
> drivers/dma/iop-adma.c:118:12: warning: format ‘%x’ expects argument
> of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ {aka
> ‘long long unsigned int’} [-Wformat=]
> 118 | pr_debug("\tcookie: %d slot: %d busy: %d "
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/dma/iop-adma.c:119:18: note: format string is defined here
> 119 | "this_desc: %#x next_desc: %#llx ack: %d\n",
> | ~~^
> | |
> | unsigned int
> | %#llx
There is a fix in the dmaengine tree, commit d17d9ea95727 ("dmaengine:
iop-adma.c: fix printk format warning") from Randy Dunlap. I fixed
some related issues in the same driver but missed this one because of
a clang bug that is now fixed.
> and the lpc32xx_udc driver has this:
>
> drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_pop_fifo’:
> drivers/usb/gadget/udc/lpc32xx_udc.c:1156:11: warning: cast from
> pointer to integer of different size [-Wpointer-to-int-cast]
> 1156 | switch (((u32) data) & 0x3) {
> | ^
> drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_stuff_fifo’:
> drivers/usb/gadget/udc/lpc32xx_udc.c:1257:11: warning: cast from
> pointer to integer of different size [-Wpointer-to-int-cast]
> 1257 | switch (((u32) data) & 0x3) {
> | ^
>
> so I will be marking them both arm-specific again because I don't want
> to see the build warnings.
I guess I may have to test with both clang and gcc in the future.
I did lots of build testing of my branches, but only with clang, which
apparently never warned about that. I found a bug report from
2010 and commented on that.
https://bugs.llvm.org/show_bug.cgi?id=8718
I'll send a fix for the warning after some more build testing.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] iio: adc: stm32-adc: fix a race when using several adcs with dma and irq
From: Jonathan Cameron @ 2019-09-17 10:11 UTC (permalink / raw)
To: Fabrice Gasnier
Cc: mcoquelin.stm32, lars, alexandre.torgue, linux-iio, linux-kernel,
linux-arm-kernel, pmeerw, knaack.h, linux-stm32, Jonathan Cameron
In-Reply-To: <6c330b1f-ef95-d9bd-3c8b-ccda03148561@st.com>
On Mon, 16 Sep 2019 13:47:34 +0200
Fabrice Gasnier <fabrice.gasnier@st.com> wrote:
> On 9/15/19 12:05 PM, Jonathan Cameron wrote:
> > On Fri, 13 Sep 2019 15:21:30 +0200
> > Fabrice Gasnier <fabrice.gasnier@st.com> wrote:
> >
> >> End of conversion may be handled by using IRQ or DMA. There may be a
> >> race when two conversions complete at the same time on several ADCs.
> >> EOC can be read as 'set' for several ADCs, with:
> >> - an ADC configured to use IRQs. EOCIE bit is set. The handler is normally
> >> called in this case.
> >> - an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA
> >> request instead. It's then automatically cleared by DMA read. But the
> >> handler gets called due to status bit is temporarily set (IRQ triggered
> >> by the other ADC).
> >> So both EOC status bit in CSR and EOCIE control bit must be checked
> >> before invoking the interrupt handler (e.g. call ISR only for
> >> IRQ-enabled ADCs).
> >>
> >> Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support")
> >>
> >> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> > Fix looks fine to me, but I'm not keen on splitting out individual bits from
> > register defines. That's a long term readability nightmare.
> >
> > See below,
> >
> > Jonathan
> >
> >> ---
> >> drivers/iio/adc/stm32-adc-core.c | 43 +++++++++++++++++++++++++++++++++++++---
> >> drivers/iio/adc/stm32-adc-core.h | 13 ++++++++++++
> >> drivers/iio/adc/stm32-adc.c | 6 ------
> >> 3 files changed, 53 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
> >> index 9b85fef..7297396 100644
> >> --- a/drivers/iio/adc/stm32-adc-core.c
> >> +++ b/drivers/iio/adc/stm32-adc-core.c
> >> @@ -71,6 +71,8 @@
> >> * @eoc1: adc1 end of conversion flag in @csr
> >> * @eoc2: adc2 end of conversion flag in @csr
> >> * @eoc3: adc3 end of conversion flag in @csr
> >> + * @ier: interrupt enable register offset for each adc
> >> + * @eocie_msk: end of conversion interrupt enable mask in @ier
> >> */
> >> struct stm32_adc_common_regs {
> >> u32 csr;
> >> @@ -78,6 +80,8 @@ struct stm32_adc_common_regs {
> >> u32 eoc1_msk;
> >> u32 eoc2_msk;
> >> u32 eoc3_msk;
> >> + u32 ier;
> >> + u32 eocie_msk;
> >> };
> >>
> >> struct stm32_adc_priv;
> >> @@ -303,6 +307,8 @@ static const struct stm32_adc_common_regs stm32f4_adc_common_regs = {
> >> .eoc1_msk = STM32F4_EOC1,
> >> .eoc2_msk = STM32F4_EOC2,
> >> .eoc3_msk = STM32F4_EOC3,
> >> + .ier = STM32F4_ADC_CR1,
> >> + .eocie_msk = STM32F4_EOCIE,
> >> };
> >>
> >> /* STM32H7 common registers definitions */
> >> @@ -311,8 +317,24 @@ static const struct stm32_adc_common_regs stm32h7_adc_common_regs = {
> >> .ccr = STM32H7_ADC_CCR,
> >> .eoc1_msk = STM32H7_EOC_MST,
> >> .eoc2_msk = STM32H7_EOC_SLV,
> >> + .ier = STM32H7_ADC_IER,
> >> + .eocie_msk = STM32H7_EOCIE,
> >> };
> >>
> >> +static const unsigned int stm32_adc_offset[STM32_ADC_MAX_ADCS] = {
> >> + 0, STM32_ADC_OFFSET, STM32_ADC_OFFSET * 2,
> >> +};
> >> +
> >> +static unsigned int stm32_adc_eoc_enabled(struct stm32_adc_priv *priv,
> >> + unsigned int adc)
> >> +{
> >> + u32 ier, offset = stm32_adc_offset[adc];
> >> +
> >> + ier = readl_relaxed(priv->common.base + offset + priv->cfg->regs->ier);
> >> +
> >> + return ier & priv->cfg->regs->eocie_msk;
> >> +}
> >> +
> >> /* ADC common interrupt for all instances */
> >> static void stm32_adc_irq_handler(struct irq_desc *desc)
> >> {
> >> @@ -323,13 +345,28 @@ static void stm32_adc_irq_handler(struct irq_desc *desc)
> >> chained_irq_enter(chip, desc);
> >> status = readl_relaxed(priv->common.base + priv->cfg->regs->csr);
> >>
> >> - if (status & priv->cfg->regs->eoc1_msk)
> >> + /*
> >> + * End of conversion may be handled by using IRQ or DMA. There may be a
> >> + * race here when two conversions complete at the same time on several
> >> + * ADCs. EOC may be read 'set' for several ADCs, with:
> >> + * - an ADC configured to use DMA (EOC triggers the DMA request, and
> >> + * is then automatically cleared by DR read in hardware)
> >> + * - an ADC configured to use IRQs (EOCIE bit is set. The handler must
> >> + * be called in this case)
> >> + * So both EOC status bit in CSR and EOCIE control bit must be checked
> >> + * before invoking the interrupt handler (e.g. call ISR only for
> >> + * IRQ-enabled ADCs).
> >> + */
> >> + if (status & priv->cfg->regs->eoc1_msk &&
> >> + stm32_adc_eoc_enabled(priv, 0))
> >> generic_handle_irq(irq_find_mapping(priv->domain, 0));
> >>
> >> - if (status & priv->cfg->regs->eoc2_msk)
> >> + if (status & priv->cfg->regs->eoc2_msk &&
> >> + stm32_adc_eoc_enabled(priv, 1))
> >> generic_handle_irq(irq_find_mapping(priv->domain, 1));
> >>
> >> - if (status & priv->cfg->regs->eoc3_msk)
> >> + if (status & priv->cfg->regs->eoc3_msk &&
> >> + stm32_adc_eoc_enabled(priv, 2))
> >> generic_handle_irq(irq_find_mapping(priv->domain, 2));
> >>
> >> chained_irq_exit(chip, desc);
> >> diff --git a/drivers/iio/adc/stm32-adc-core.h b/drivers/iio/adc/stm32-adc-core.h
> >> index 8af507b..8dc936b 100644
> >> --- a/drivers/iio/adc/stm32-adc-core.h
> >> +++ b/drivers/iio/adc/stm32-adc-core.h
> >> @@ -25,8 +25,21 @@
> >> * --------------------------------------------------------
> >> */
> >> #define STM32_ADC_MAX_ADCS 3
> >> +#define STM32_ADC_OFFSET 0x100
> >> #define STM32_ADCX_COMN_OFFSET 0x300
> >>
> >> +/* STM32F4 - registers for each ADC instance */
> >> +#define STM32F4_ADC_CR1 0x04
> >> +
> >> +/* STM32F4_ADC_CR1 - bit fields */
> >> +#define STM32F4_EOCIE BIT(5)
> >> +
> >> +/* STM32H7 - registers for each instance */
> >> +#define STM32H7_ADC_IER 0x04
> >> +
> >> +/* STM32H7_ADC_IER - bit fields */
> >> +#define STM32H7_EOCIE BIT(2)
> >> +
> >> /**
> >> * struct stm32_adc_common - stm32 ADC driver common data (for all instances)
> >> * @base: control registers base cpu addr
> >> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> >> index 6a7dd08..3c9f456 100644
> >> --- a/drivers/iio/adc/stm32-adc.c
> >> +++ b/drivers/iio/adc/stm32-adc.c
> >> @@ -30,7 +30,6 @@
> >>
> >> /* STM32F4 - Registers for each ADC instance */
> >> #define STM32F4_ADC_SR 0x00
> >> -#define STM32F4_ADC_CR1 0x04
> >> #define STM32F4_ADC_CR2 0x08
> >> #define STM32F4_ADC_SMPR1 0x0C
> >> #define STM32F4_ADC_SMPR2 0x10
> >> @@ -54,7 +53,6 @@
> >> #define STM32F4_RES_SHIFT 24
> >> #define STM32F4_RES_MASK GENMASK(25, 24)
> >> #define STM32F4_SCAN BIT(8)
> >> -#define STM32F4_EOCIE BIT(5)
> > Hmm. This is breaking up the definitions of bits in a single register.
> > That is rather nasty from a code readability point of view.
> >
> > I am as keen as the next person on only exposing definitions where
> > we need to, but in this case we either need to provide an access path
> > to it here, or we need to move the whole block to the header.
>
> Hi Jonathan,
>
> I think I'll add a precursor patch in v2 to move the whole block to the
> header file. This way, the access path is easy (e.g. readl).
> I'm only wondering about the Fixes tag... this will probably not be
> straight forward to apply the fix on the maintenance releases ?
> Or do I need to add it to the precursor patch as well ?
The precursor is a simple move of definitions. Even if it's large, I don't
think it will be a problem applying it to stable.
Just make it clear in the patch description why it is needed for the fix.
Thanks,
Jonathan
>
> Thanks for reviewing,
> Best regards,
> Fabrice
>
> >
> >>
> >> /* STM32F4_ADC_CR2 - bit fields */
> >> #define STM32F4_SWSTART BIT(30)
> >> @@ -69,7 +67,6 @@
> >>
> >> /* STM32H7 - Registers for each ADC instance */
> >> #define STM32H7_ADC_ISR 0x00
> >> -#define STM32H7_ADC_IER 0x04
> >> #define STM32H7_ADC_CR 0x08
> >> #define STM32H7_ADC_CFGR 0x0C
> >> #define STM32H7_ADC_SMPR1 0x14
> >> @@ -89,9 +86,6 @@
> >> #define STM32H7_EOC BIT(2)
> >> #define STM32H7_ADRDY BIT(0)
> >>
> >> -/* STM32H7_ADC_IER - bit fields */
> >> -#define STM32H7_EOCIE STM32H7_EOC
> >> -
> >> /* STM32H7_ADC_CR - bit fields */
> >> #define STM32H7_ADCAL BIT(31)
> >> #define STM32H7_ADCALDIF BIT(30)
> >
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] net: stmmac: Fix ASSERT_RTNL() warning on suspend/resume
From: Jose Abreu @ 2019-09-17 10:12 UTC (permalink / raw)
To: Loys Ollivier, Russell King, Maxime Coquelin
Cc: Alexandre Torgue, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, David S. Miller, Giuseppe Cavallaro,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1568714556-25024-1-git-send-email-lollivier@baylibre.com>
From: Loys Ollivier <lollivier@baylibre.com>
Date: Sep/17/2019, 11:02:36 (UTC+00:00)
> rtnl_lock needs to be taken before calling phylink_start/stop to lock the
> network stack.
> Fix ASSERT_RTNL() warnings by protecting such calls with lock/unlock.
>
> Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
> Signed-off-by: Loys Ollivier <lollivier@baylibre.com>
I already sent a fix for this. Please see in -net:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/driv
ers/net/ethernet/stmicro/stmmac?id=19e13cb27b998ff49f07e399b5871bfe5ba7e3
f0
---
Thanks,
Jose Miguel Abreu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/2] of: Let of_for_each_phandle fallback to non-negative cell_count
From: Uwe Kleine-König @ 2019-09-17 10:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Frank Rowand, Joerg Roedel, Linux Kernel Mailing List,
Linux-Renesas, Wolfram Sang, Linux IOMMU, linux-mediatek,
Linux I2C, Sascha Hauer, Matthias Brugger, Will Deacon, Linux ARM,
Robin Murphy
In-Reply-To: <CAMuHMdV+pwoAA0zH_vQf2nKqzrgHP8rcMStyJbnuu2qviFC_qg@mail.gmail.com>
Hello Geert,
On Tue, Sep 17, 2019 at 11:40:25AM +0200, Geert Uytterhoeven wrote:
> Hi Rob, Uwe,
>
> On Fri, Sep 13, 2019 at 11:58 PM Rob Herring <robh@kernel.org> wrote:
> > On Sat, 24 Aug 2019 15:28:46 +0200, =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= wrote:
> > > Referencing device tree nodes from a property allows to pass arguments.
> > > This is for example used for referencing gpios. This looks as follows:
> > >
> > > gpio_ctrl: gpio-controller {
> > > #gpio-cells = <2>
> > > ...
> > > }
> > >
> > > someothernode {
> > > gpios = <&gpio_ctrl 5 0 &gpio_ctrl 3 0>;
> > > ...
> > > }
> > >
> > > To know the number of arguments this must be either fixed, or the
> > > referenced node is checked for a $cells_name (here: "#gpio-cells")
> > > property and with this information the start of the second reference can
> > > be determined.
> > >
> > > Currently regulators are referenced with no additional arguments. To
> > > allow some optional arguments without having to change all referenced
> > > nodes this change introduces a way to specify a default cell_count. So
> > > when a phandle is parsed we check for the $cells_name property and use
> > > it as before if present. If it is not present we fall back to
> > > cells_count if non-negative and only fail if cells_count is smaller than
> > > zero.
> > >
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> This is now commit e42ee61017f58cd9 ("of: Let of_for_each_phandle fallback
> to non-negative cell_count") in robh/for-next, which causes a lock-up when
> booting a shmobile_defconfig kernel on r8a7791/koelsch:
>
> rcu: INFO: rcu_sched self-detected stall on CPU
> rcu: 0-....: (2099 ticks this GP) idle=6fe/1/0x40000002
> softirq=29/29 fqs=1050
> (t=2100 jiffies g=-1131 q=0)
> NMI backtrace for cpu 0
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 5.3.0-rc2-shmobile-00050-ge42ee61017f58cd9 #376
> Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
> [<c010f8ac>] (unwind_backtrace) from [<c010b620>] (show_stack+0x10/0x14)
> [<c010b620>] (show_stack) from [<c073d038>] (dump_stack+0x7c/0x9c)
> [<c073d038>] (dump_stack) from [<c0742e80>] (nmi_cpu_backtrace+0xa0/0xb8)
> [<c0742e80>] (nmi_cpu_backtrace) from [<c0742f1c>] (nmi_trigger_cpumask_backtrace+0x84/0x114)
> [<c0742f1c>] (nmi_trigger_cpumask_backtrace) from [<c017d684>] (rcu_dump_cpu_stacks+0xac/0xc8)
> [<c017d684>] (rcu_dump_cpu_stacks) from [<c017a598>] (rcu_sched_clock_irq+0x2ac/0x6b4)
> [<c017a598>] (rcu_sched_clock_irq) from [<c0183980>] (update_process_times+0x30/0x5c)
> [<c0183980>] (update_process_times) from [<c01941a8>] (tick_nohz_handler+0xcc/0x120)
> [<c01941a8>] (tick_nohz_handler) from [<c05b1d40>] (arch_timer_handler_virt+0x28/0x30)
> [<c05b1d40>] (arch_timer_handler_virt) from [<c016c9e0>] (handle_percpu_devid_irq+0xe8/0x21c)
> [<c016c9e0>] (handle_percpu_devid_irq) from [<c0167a8c>] (generic_handle_irq+0x18/0x28)
> [<c0167a8c>] (generic_handle_irq) from [<c0167b3c>] (__handle_domain_irq+0xa0/0xb4)
> [<c0167b3c>] (__handle_domain_irq) from [<c03673ec>] (gic_handle_irq+0x58/0x90)
> [<c03673ec>] (gic_handle_irq) from [<c0101a8c>] (__irq_svc+0x6c/0x90)
> Exception stack(0xeb08dd30 to 0xeb08dd78)
> dd20: c0cc7514 20000013 00000005 00003b27
> dd40: eb7c4020 c0cc750c 00000051 00000051 20000013 c0c66b08 eb1cdc00 00000018
> dd60: 00000000 eb08dd80 c05c1a38 c0756c00 20000013 ffffffff
> [<c0101a8c>] (__irq_svc) from [<c0756c00>] (_raw_spin_unlock_irqrestore+0x1c/0x20)
> [<c0756c00>] (_raw_spin_unlock_irqrestore) from [<c05c1a38>] (of_find_node_by_phandle+0xcc/0xf0)
> [<c05c1a38>] (of_find_node_by_phandle) from [<c05c1bb8>] (of_phandle_iterator_next+0x68/0x178)
> [<c05c1bb8>] (of_phandle_iterator_next) from [<c05c22bc>] (of_count_phandle_with_args+0x5c/0x7c)
> [<c05c22bc>] (of_count_phandle_with_args) from [<c053fc38>] (i2c_demux_pinctrl_probe+0x24/0x1fc)
> [<c053fc38>] (i2c_demux_pinctrl_probe) from [<c04463c4>] (platform_drv_probe+0x48/0x94)
> [<c04463c4>] (platform_drv_probe) from [<c0444a20>] (really_probe+0x1f0/0x2b8)
> [<c0444a20>] (really_probe) from [<c0444e68>] (driver_probe_device+0x140/0x158)
> [<c0444e68>] (driver_probe_device) from [<c0444ff0>] (device_driver_attach+0x44/0x5c)
> [<c0444ff0>] (device_driver_attach) from [<c04450b4>] (__driver_attach+0xac/0xb4)
> [<c04450b4>] (__driver_attach) from [<c0443178>] (bus_for_each_dev+0x64/0xa0)
> [<c0443178>] (bus_for_each_dev) from [<c04438a8>] (bus_add_driver+0x148/0x1a8)
> [<c04438a8>] (bus_add_driver) from [<c0445ad0>] (driver_register+0xac/0xf0)
> [<c0445ad0>] (driver_register) from [<c0b010b0>] (do_one_initcall+0xa8/0x1d4)
> [<c0b010b0>] (do_one_initcall) from [<c0b01448>] (kernel_init_freeable+0x26c/0x2c8)
> [<c0b01448>] (kernel_init_freeable) from [<c0751c70>] (kernel_init+0x8/0x10c)
> [<c0751c70>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0xeb08dfb0 to 0xeb08dff8)
> dfa0: 00000000 00000000 00000000 00000000
> dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>
> Presumably it loops forever, due to a conversion of -1 to unsigned
> somewhere?
Hmm, I fail to see the culprit. i2c_demux_pinctrl_probe calls
of_count_phandle_with_args with cells_name=NULL. With that I don't see
how my patch changes anything as the only change is in an if
(it->cells_name) block that shouldn't be relevant in your case.
Can you please verify that the loop in of_count_phandle_with_args is
indeed not terminating, e.g. with
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 2f25d2dfecfa..2425a6d26038 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1769,8 +1769,13 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
if (rc)
return rc;
- while ((rc = of_phandle_iterator_next(&it)) == 0)
+ pr_err("%s: enter loop (np=%pOF, list_name=%s, cells_name=%s)\n",
+ __func__, np, list_name, cells_name);
+ while ((rc = of_phandle_iterator_next(&it)) == 0) {
+ pr_err("%s: it.node = %pOF cur_index=%d\n", __func__, it.node, cur_index);
cur_index += 1;
+ }
+ pr_err("%s: exit loop\n", __func__);
if (rc != -ENOENT)
return rc;
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put
From: Zenghui Yu @ 2019-09-17 10:17 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm; +Cc: Andre Przywara
In-Reply-To: <dcc5a10b-c9ca-f833-4a60-e5d3726fa0b9@huawei.com>
Hi Marc,
On 2019/9/17 17:31, Zenghui Yu wrote:
>
> But this time I got the following WARNING:
Please ignore it. I think this is mostly caused by my local buggy
patch... Sorry for the noise.
Zenghui
>
> [ 921.004322] ======================================================
> [ 921.010489] WARNING: possible circular locking dependency detected
> [ 921.016657] 5.3.0+ #27 Not tainted
> [ 921.020132] ------------------------------------------------------
> [ 921.026299] CPU 1/KVM/816 is trying to acquire lock:
> [ 921.031250] ffff002fb42b35b0 (&irq_desc_lock_class){-.-.}, at:
> __irq_get_desc_lock+0x60/0xa0
> [ 921.039684]
> but task is already holding lock:
> [ 921.045503] ffff002fbbb07258 (&rq->lock){-.-.}, at:
> __schedule+0xd4/0x988
> [ 921.052283]
> which lock already depends on the new lock.
>
> [ 921.060445]
> the existing dependency chain (in reverse order) is:
> [ 921.067913]
> -> #3 (&rq->lock){-.-.}:
> [ 921.072955] lock_acquire+0xd4/0x268
> [ 921.077041] _raw_spin_lock+0x44/0x58
> [ 921.081212] task_fork_fair+0x54/0x160
> [ 921.085471] sched_fork+0xfc/0x238
> [ 921.089383] copy_process+0x474/0x1738
> [ 921.093639] _do_fork+0x70/0x6e0
> [ 921.097376] kernel_thread+0x70/0x98
> [ 921.101459] rest_init+0x34/0x278
> [ 921.105286] arch_call_rest_init+0x14/0x1c
> [ 921.109891] start_kernel+0x548/0x574
> [ 921.114060]
> -> #2 (&p->pi_lock){-.-.}:
> [ 921.119275] lock_acquire+0xd4/0x268
> [ 921.123360] _raw_spin_lock_irqsave+0x60/0x80
> [ 921.128225] try_to_wake_up+0x60/0xbf0
> [ 921.132483] wake_up_process+0x28/0x38
> [ 921.136739] __up.isra.0+0x58/0x68
> [ 921.140649] up+0x64/0x80
> [ 921.143777] __up_console_sem+0x60/0xa8
> [ 921.148121] console_unlock+0x31c/0x5f0
> [ 921.152465] vprintk_emit+0x28c/0x438
> [ 921.156637] dev_vprintk_emit+0x1d8/0x218
> [ 921.161157] dev_printk_emit+0x84/0xa8
> [ 921.165414] __dev_printk+0x78/0xa0
> [ 921.169411] _dev_info+0x7c/0xa0
> [ 921.173148] hub_port_init+0xa5c/0xb68
> [ 921.177405] hub_port_connect+0x2f0/0xa08
> [ 921.181923] port_event+0x548/0x828
> [ 921.185920] hub_event+0x20c/0x418
> [ 921.189831] process_one_work+0x24c/0x700
> [ 921.194349] worker_thread+0x4c/0x448
> [ 921.198519] kthread+0x130/0x138
> [ 921.202256] ret_from_fork+0x10/0x18
> [ 921.206338]
> -> #1 ((console_sem).lock){-.-.}:
> [ 921.212160] lock_acquire+0xd4/0x268
> [ 921.216244] _raw_spin_lock_irqsave+0x60/0x80
> [ 921.221110] down_trylock+0x20/0x50
> [ 921.225106] __down_trylock_console_sem+0x50/0xe0
> [ 921.230320] console_trylock+0x20/0x88
> [ 921.234577] vprintk_emit+0x18c/0x438
> [ 921.238747] vprintk_default+0x54/0x90
> [ 921.243004] vprintk_func+0xe4/0x268
> [ 921.247087] printk+0x74/0x94
> [ 921.250564] show_interrupts+0x4dc/0x4f8
> [ 921.254997] seq_read+0x2b4/0x4e0
> [ 921.258820] proc_reg_read+0x94/0xe8
> [ 921.262905] __vfs_read+0x48/0x80
> [ 921.266729] vfs_read+0xa0/0x160
> [ 921.270465] ksys_read+0x74/0xf8
> [ 921.274202] __arm64_sys_read+0x24/0x30
> [ 921.278547] el0_svc_common.constprop.0+0x80/0x1b8
> [ 921.283846] el0_svc_handler+0x34/0xb8
> [ 921.288102] el0_svc+0x8/0xc
> [ 921.291491]
> -> #0 (&irq_desc_lock_class){-.-.}:
> [ 921.297486] check_prev_add+0xac/0x9f8
> [ 921.301743] __lock_acquire+0x1164/0x12b8
> [ 921.306260] lock_acquire+0xd4/0x268
> [ 921.310344] _raw_spin_lock_irqsave+0x60/0x80
> [ 921.315209] __irq_get_desc_lock+0x60/0xa0
> [ 921.319814] irq_set_vcpu_affinity+0x48/0xc8
> [ 921.324592] its_schedule_vpe+0x68/0xb0
> [ 921.328937] vgic_v4_put+0x80/0xa8
> [ 921.332846] vgic_v3_put+0x24/0xf0
> [ 921.336756] kvm_vgic_put+0x3c/0x60
> [ 921.340754] kvm_arch_vcpu_put+0x38/0x60
> [ 921.345184] kvm_sched_out+0x38/0x48
> [ 921.349267] __schedule+0x5a4/0x988
> [ 921.353263] schedule+0x40/0xc8
> [ 921.356912] kvm_arch_vcpu_ioctl_run+0x130/0xb08
> [ 921.362037] kvm_vcpu_ioctl+0x3e0/0xb08
> [ 921.366381] do_vfs_ioctl+0xc4/0x890
> [ 921.370464] ksys_ioctl+0x8c/0xa0
> [ 921.374287] __arm64_sys_ioctl+0x28/0x38
> [ 921.378717] el0_svc_common.constprop.0+0x80/0x1b8
> [ 921.384016] el0_svc_handler+0x34/0xb8
> [ 921.388272] el0_svc+0x8/0xc
> [ 921.391660]
> other info that might help us debug this:
>
> [ 921.399649] Chain exists of:
> &irq_desc_lock_class --> &p->pi_lock --> &rq->lock
>
> [ 921.409984] Possible unsafe locking scenario:
>
> [ 921.415889] CPU0 CPU1
> [ 921.420405] ---- ----
> [ 921.424921] lock(&rq->lock);
> [ 921.427962] lock(&p->pi_lock);
> [ 921.433694] lock(&rq->lock);
> [ 921.439253] lock(&irq_desc_lock_class);
> [ 921.443249]
> *** DEADLOCK ***
>
> [ 921.449155] 2 locks held by CPU 1/KVM/816:
> [ 921.453237] #0: ffff002fa3862aa8 (&vcpu->mutex){+.+.}, at:
> kvm_vcpu_ioctl+0x80/0xb08
> [ 921.461055] #1: ffff002fbbb07258 (&rq->lock){-.-.}, at:
> __schedule+0xd4/0x988
> [ 921.468265]
> stack backtrace:
> [ 921.472610] CPU: 24 PID: 816 Comm: CPU 1/KVM Kdump: loaded Not
> tainted 5.3.0+ #27
> [ 921.480165] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.58
> 10/29/2018
> [ 921.487372] Call trace:
> [ 921.489806] dump_backtrace+0x0/0x188
> [ 921.493455] show_stack+0x24/0x30
> [ 921.496757] dump_stack+0xcc/0x134
> [ 921.500146] print_circular_bug.isra.20+0x204/0x2d8
> [ 921.505011] check_noncircular+0x130/0x1c0
> [ 921.509094] check_prev_add+0xac/0x9f8
> [ 921.512829] __lock_acquire+0x1164/0x12b8
> [ 921.516825] lock_acquire+0xd4/0x268
> [ 921.520388] _raw_spin_lock_irqsave+0x60/0x80
> [ 921.524732] __irq_get_desc_lock+0x60/0xa0
> [ 921.528815] irq_set_vcpu_affinity+0x48/0xc8
> [ 921.533071] its_schedule_vpe+0x68/0xb0
> [ 921.536894] vgic_v4_put+0x80/0xa8
> [ 921.540282] vgic_v3_put+0x24/0xf0
> [ 921.543671] kvm_vgic_put+0x3c/0x60
> [ 921.547147] kvm_arch_vcpu_put+0x38/0x60
> [ 921.551057] kvm_sched_out+0x38/0x48
> [ 921.554618] __schedule+0x5a4/0x988
> [ 921.558094] schedule+0x40/0xc8
> [ 921.561222] kvm_arch_vcpu_ioctl_run+0x130/0xb08
> [ 921.565826] kvm_vcpu_ioctl+0x3e0/0xb08
> [ 921.569649] do_vfs_ioctl+0xc4/0x890
> [ 921.573211] ksys_ioctl+0x8c/0xa0
> [ 921.576513] __arm64_sys_ioctl+0x28/0x38
> [ 921.580423] el0_svc_common.constprop.0+0x80/0x1b8
> [ 921.585201] el0_svc_handler+0x34/0xb8
> [ 921.588937] el0_svc+0x8/0xc
>
>
>
> Thanks,
> zenghui
>
>
> .
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: add compatible for Amlogic Meson A1 pin controller
From: Qianggui Song @ 2019-09-17 10:29 UTC (permalink / raw)
To: Neil Armstrong, Linus Walleij, linux-gpio
Cc: Mark Rutland, devicetree, Hanjie Lin, Jianxin Pan,
Martin Blumenstingl, Kevin Hilman, linux-kernel, Rob Herring,
linux-arm-kernel, Carlo Caione, linux-amlogic, Xingyu Chen,
Jerome Brunet
In-Reply-To: <131cf06f-2530-4524-9f86-3c07641bb460@baylibre.com>
Hi, Neil
Thanks for your review
On 2019/9/17 15:18, Neil Armstrong wrote:
> Hi,
>
> On 17/09/2019 08:07, Qianggui Song wrote:
>> Add new compatible name for Amlogic's Meson-A1 pin controller
>> add a dt-binding header file which document the detail pin names.
>
> Please add in the commit log that A1 doesn't need the DS bank reg,
> so when we will convert these bindings to yaml we will be aware of it.
>
OK, will add it in the next patch
>>
>> Signed-off-by: Qianggui Song <qianggui.song@amlogic.com>
>> Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
>> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
>> ---
>> .../devicetree/bindings/pinctrl/meson,pinctrl.txt | 1 +
>> include/dt-bindings/gpio/meson-a1-gpio.h | 73 ++++++++++++++++++++++
>> 2 files changed, 74 insertions(+)
>> create mode 100644 include/dt-bindings/gpio/meson-a1-gpio.h
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
>> index 10dc4f7..0aff1f2 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
>> @@ -15,6 +15,7 @@ Required properties for the root node:
>> "amlogic,meson-axg-aobus-pinctrl"
>> "amlogic,meson-g12a-periphs-pinctrl"
>> "amlogic,meson-g12a-aobus-pinctrl"
>> + "amlogic,meson-a1-periphs-pinctrl"
>> - reg: address and size of registers controlling irq functionality
>>
>> === GPIO sub-nodes ===
>> diff --git a/include/dt-bindings/gpio/meson-a1-gpio.h b/include/dt-bindings/gpio/meson-a1-gpio.h
>> new file mode 100644
>> index 0000000..40e57a5
>> --- /dev/null
>> +++ b/include/dt-bindings/gpio/meson-a1-gpio.h
>> @@ -0,0 +1,73 @@
>> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
>> +/*
>> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
>> + * Author: Qianggui Song <qianggui.song@amlogic.com>
>> + */
>> +
>> +#ifndef _DT_BINDINGS_MESON_A1_GPIO_H
>> +#define _DT_BINDINGS_MESON_A1_GPIO_H
>> +
>> +#define GPIOP_0 0
>> +#define GPIOP_1 1
>> +#define GPIOP_2 2
>> +#define GPIOP_3 3
>> +#define GPIOP_4 4
>> +#define GPIOP_5 5
>> +#define GPIOP_6 6
>> +#define GPIOP_7 7
>> +#define GPIOP_8 8
>> +#define GPIOP_9 9
>> +#define GPIOP_10 10
>> +#define GPIOP_11 11
>> +#define GPIOP_12 12
>> +#define GPIOB_0 13
>> +#define GPIOB_1 14
>> +#define GPIOB_2 15
>> +#define GPIOB_3 16
>> +#define GPIOB_4 17
>> +#define GPIOB_5 18
>> +#define GPIOB_6 19
>> +#define GPIOX_0 20
>> +#define GPIOX_1 21
>> +#define GPIOX_2 22
>> +#define GPIOX_3 23
>> +#define GPIOX_4 24
>> +#define GPIOX_5 25
>> +#define GPIOX_6 26
>> +#define GPIOX_7 27
>> +#define GPIOX_8 28
>> +#define GPIOX_9 29
>> +#define GPIOX_10 30
>> +#define GPIOX_11 31
>> +#define GPIOX_12 32
>> +#define GPIOX_13 33
>> +#define GPIOX_14 34
>> +#define GPIOX_15 35
>> +#define GPIOX_16 36
>> +#define GPIOF_0 37
>> +#define GPIOF_1 38
>> +#define GPIOF_2 39
>> +#define GPIOF_3 40
>> +#define GPIOF_4 41
>> +#define GPIOF_5 42
>> +#define GPIOF_6 43
>> +#define GPIOF_7 44
>> +#define GPIOF_8 45
>> +#define GPIOF_9 46
>> +#define GPIOF_10 47
>> +#define GPIOF_11 48
>> +#define GPIOF_12 49
>> +#define GPIOA_0 50
>> +#define GPIOA_1 51
>> +#define GPIOA_2 52
>> +#define GPIOA_3 53
>> +#define GPIOA_4 54
>> +#define GPIOA_5 55
>> +#define GPIOA_6 56
>> +#define GPIOA_7 57
>> +#define GPIOA_8 58
>> +#define GPIOA_9 59
>> +#define GPIOA_10 60
>> +#define GPIOA_11 61
>> +
>> +#endif /* _DT_BINDINGS_MESON_A1_GPIO_H */
>>
>
>
> With that fixed,
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>
> Neil
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-17 10:42 UTC (permalink / raw)
To: Adrian Hunter; +Cc: linux-mmc, Linux ARM
In-Reply-To: <20190917081931.GI25745@shell.armlinux.org.uk>
On Tue, Sep 17, 2019 at 09:19:31AM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 10:06:12AM +0200, Marc Gonzalez wrote:
> > On 16/09/2019 19:15, Russell King - ARM Linux admin wrote:
> >
> > > The platform has an iommu, which is in pass-through mode, via
> > > arm_smmu.disable_bypass=0.
> >
> > Could be 954a03be033c7cef80ddc232e7cbdb17df735663
> > "iommu/arm-smmu: Break insecure users by disabling bypass by default"
> >
> > Although it had already landed in v5.2
>
> It is not - and the two lines that you quoted above are sufficient
> to negate that as a cause. (Please read the help for the option that
> the commit referrs to.)
>
> In fact, with bypass disabled, the SoC fails due to other masters.
> That's already been discussed privately between myself and Will
> Deacon.
>
> arm_smmu.disable_bypass=0 re-enables bypass mode irrespective of
> the default setting in the Kconfig.
Adding some further debugging, and fixing the existing ADMA debugging
shows:
mmc0: ADMA error: 0x02000000
So this is an ADMA error without the transfer having completed.
mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
The block size is 8, with one block.
mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236df1d20c
The ADMA error is a descriptor error at address 0x000000236df1d20c.
The descriptor table contains (including the following entry):
mmc0: sdhci: 236df1d200: DMA 0x000000236d40e980, LEN 0x0008, Attr=0x23
mmc0: sdhci: 236df1d20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x00
The descriptor table contains one descriptor of 8 bytes, is marked
as the last (END bit set) and is at DMA address 0x236df1d200. The
following descriptor is empty, with VALID=0.
One may be tempted to blame it on the following descriptor, but having
had another example on eMMC while userspace was booting (rootfs on
eMMC):
mmc1: ADMA error: 0x02000000
mmc1: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000099
mmc1: sdhci: ADMA Err: 0x00000006 | ADMA Ptr: 0x000000236dbfa26c
mmc1: sdhci: 236dbfa200: DMA 0x000000236c25c000, LEN 0x2000, Attr=0x21
mmc1: sdhci: 236dbfa20c: DMA 0x000000236938c000, LEN 0x0000, Attr=0x21
mmc1: sdhci: 236dbfa218: DMA 0x000000236939c000, LEN 0x5000, Attr=0x21
mmc1: sdhci: 236dbfa224: DMA 0x0000002368545000, LEN 0x1000, Attr=0x21
mmc1: sdhci: 236dbfa230: DMA 0x00000023684f1000, LEN 0x1000, Attr=0x21
mmc1: sdhci: 236dbfa23c: DMA 0x0000002368504000, LEN 0x2000, Attr=0x21
mmc1: sdhci: 236dbfa248: DMA 0x0000002368546000, LEN 0x2000, Attr=0x21
mmc1: sdhci: 236dbfa254: DMA 0x00000023684f2000, LEN 0x2000, Attr=0x21
mmc1: sdhci: 236dbfa260: DMA 0x0000002368500000, LEN 0x1000, Attr=0x23
mmc1: sdhci: 236dbfa26c: DMA 0x000000236b55d000, LEN 0x1000, Attr=0x21
... which is interesting for several reasons:
- The ADMA error register indicates a length mismatch error. The
transfer was for 0x99 blocks of 0x200, which is 0x13200 bytes.
Summing the ADMA lengths up to the last descriptor (length=0 is
0x10000 bytes) gives 0x20000 bytes. So the DMA table contains more
bytes than the requested transfer.
- The ADMA error register indicates ST_CADR, which is described as
"This state is never set because do not generate ADMA error in this
state."
- The error descriptor is again after the descriptor with END=1, but
this time has VALID=1.
This _feels_ like a coherency issue, where the SDHCI engine is not
correctly seeing the descriptor table, but then I would have expected
userspace (which is basically debian stable) to fail to boot every
time given that its rootfs is on eMMC.
The other weird thing is if I wind the core MMC code back via:
$ git diff -u 7559d612dff0..v5.3 drivers/mmc/core | patch -p1 -R
and fix the lack of dma_max_pfn(), then SDHCI is more stable - not
completely stable, but way better than plain v5.3. I don't see
much in that diff which would be responsible for this - although it
does seem that hch's DMA changes do make the problem more likely.
(going from 1 in 3 boots with a problem to being not able to boot.)
Note, with v5.2, I _never_ saw any ADMA errors, except if I disabled
bypass mode on the IOMMU (but then I saw global smmu errors right
from when the IOMMU had bypass disabled before MMC was probed - the
reason being is the SoC is not currently setup to have the MMU
bypass mode disabled.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [breakage] panic() does not halt arm64 systems under certain conditions
From: Will Deacon @ 2019-09-17 10:45 UTC (permalink / raw)
To: Xogium
Cc: linux-arch, gregkh, linux-kernel, linux, mingo, bp, tglx,
linux-arm-kernel
In-Reply-To: <BX1W47JXPMR8.58IYW53H6M5N@dragonstone>
Hi,
[Expanding CC list; original message is here:
https://lore.kernel.org/linux-arm-kernel/BX1W47JXPMR8.58IYW53H6M5N@dragonstone/]
On Mon, Sep 16, 2019 at 09:35:36PM -0400, Xogium wrote:
> On arm64 in some situations userspace will continue running even after a
> panic. This means any userspace watchdog daemon will continue pinging,
> that service managers will keep running and displaying messages in certain
> cases, and that it is possible to enter via ssh in the now unstable system
> and to do almost anything except reboot/power off and etc. If
> CONFIG_PREEMPT=n is set in the kernel's configuration, the issue is fixed.
> I have reproduced the very same behavior with linux 4.19, 5.2 and 5.3. On
> x86/x86_64 the issue does not seem to be present at all.
I've managed to reproduce this under both 32-bit and 64-bit ARM kernels.
The issue is that the infinite loop at the end of panic() can run with
preemption enabled (particularly when invoking by echoing 'c' to
/proc/sysrq-trigger), so we end up rescheduling user tasks. On x86, this
doesn't happen because smp_send_stop() disables the local APIC in
native_stop_other_cpus() and so interrupts are effectively masked while
spinning.
A straightforward fix is to disable preemption explicitly on the panic()
path (diff below), but I've expanded the cc list to see both what others
think, but also in case smp_send_stop() is supposed to have the side-effect
of disabling interrupt delivery for the local CPU.
Will
--->8
diff --git a/kernel/panic.c b/kernel/panic.c
index 057540b6eee9..02d0de31c42d 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -179,6 +179,7 @@ void panic(const char *fmt, ...)
* after setting panic_cpu) from invoking panic() again.
*/
local_irq_disable();
+ preempt_disable_notrace();
/*
* It's possible to come here directly from a panic-assertion and
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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