Skip to contentSkip to conversation

Fix and add more zx dt nodes

PATCH New Jun Nie 6 participants 21 messages Oct 13, 2016 – Dec 7, 2016

Subsystems (2)
Device tree bindings Tegra architecture support
lore
Share & tools
lore

Jun Nie

author
#0 lore raw

v2 cover Fix and add more zx dt nodes

Changes vs V1:
- Add more background information for the GIC fix.
- Fix minor coding style issue.

Jun Nie (2):
arm64: dts: zx: Fix gic GICR property
arm64: dts: zx: Add clock controller nodes

 arch/arm64/boot/dts/zte/zx296718.dtsi | 35 +++++++++++++++++++++++++++--------
 1 file changed, 27 insertions(+), 8 deletions(-)
Signature · 1 line
1.9.1
author
#1 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Signed-off-by Jun Nie <[email protected]>
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)
arch/arm64/boot/dts/zte/zx296718.dtsi +3 -8
index a223066..6b239a3 100644
@@ -239,16 +239,11 @@
 		compatible = "arm,gic-v3";
 		#interrupt-cells = <3>;
 		#address-cells = <0>;
-		#redistributor-regions = <6>;
-		redistributor-stride = <0x0 0x40000>;
+		#redistributor-regions = <1>;
+		redistributor-stride = <0x20000>;
 		interrupt-controller;
 		reg = <0x02a00000 0x10000>,
-		      <0x02b00000 0x20000>,
-		      <0x02b20000 0x20000>,
-		      <0x02b40000 0x20000>,
-		      <0x02b60000 0x20000>,
-		      <0x02b80000 0x20000>,
-		      <0x02ba0000 0x20000>;
+		      <0x02b00000 0xc0000>;
 		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
 	};
Signature · 1 line
1.9.1
Applied
#2 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 17 lines · Jun Nie

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Quoted 1 line
Signed-off-by Jun Nie <[email protected]>

A Fixes: tag would be useful on a patch like this, to tell what patch introduced the problem. Please consider using them in the future.

I've applied this one to fixes now.

-Olof

#3 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 18 lines · CET Olof Johansson
Quoted 17 lines · Jun Nie

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Quoted 6 lines
Quoted 1 line
Signed-off-by Jun Nie <[email protected]>

A Fixes: tag would be useful on a patch like this, to tell what patch introduced the problem. Please consider using them in the future.

I've applied this one to fixes now.

Hi Olof,

I happened to still have this one in my todo folder as I must have missed your reply, and I stumbled over it while looking for things that may have gone missing.

I don't see it in v4.9-rc6, did it get dropped accidentally?

Arnd

#4 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 26 lines · Arnd Bergmann
Quoted 18 lines · CET Olof Johansson
Quoted 17 lines · Jun Nie

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Quoted 6 lines
Quoted 1 line
Signed-off-by Jun Nie <[email protected]>

A Fixes: tag would be useful on a patch like this, to tell what patch introduced the problem. Please consider using them in the future.

I've applied this one to fixes now.

Quoted 7 lines

Hi Olof,

I happened to still have this one in my todo folder as I must have missed your reply, and I stumbled over it while looking for things that may have gone missing.

I don't see it in v4.9-rc6, did it get dropped accidentally?

Please help get this into v4.9 if possible, as it is required to get v4.9 kernel boot up on ZTE ZX296718 SoC. Thanks.

Shawn

#5 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 33 lines · CET Shawn Guo
Quoted 32 lines · Arnd Bergmann
Quoted 18 lines · CET Olof Johansson
Quoted 17 lines · Jun Nie

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Quoted 6 lines
Quoted 1 line
Signed-off-by Jun Nie <[email protected]>

A Fixes: tag would be useful on a patch like this, to tell what patch introduced the problem. Please consider using them in the future.

I've applied this one to fixes now.

Hi Olof,

I happened to still have this one in my todo folder as I must have missed your reply, and I stumbled over it while looking for things that may have gone missing.

Quoted 7 lines
Quoted 1 line

I don't see it in v4.9-rc6, did it get dropped accidentally?

Please help get this into v4.9 if possible, as it is required to get v4.9 kernel boot up on ZTE ZX296718 SoC. Thanks.

Shawn

Ok, applied both. Thanks,

Arnd

#6 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 36 lines · Arnd Bergmann
Quoted 35 lines · CET Shawn Guo
Quoted 33 lines · Arnd Bergmann
Quoted 18 lines · CET Olof Johansson
Quoted 17 lines · Jun Nie

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Quoted 6 lines
Quoted 1 line
Signed-off-by Jun Nie <[email protected]>

A Fixes: tag would be useful on a patch like this, to tell what patch introduced the problem. Please consider using them in the future.

I've applied this one to fixes now.

Hi Olof,

I happened to still have this one in my todo folder as I must have missed your reply, and I stumbled over it while looking for things that may have gone missing.

I don't see it in v4.9-rc6, did it get dropped accidentally?

Quoted 7 lines
Quoted 5 lines

Please help get this into v4.9 if possible, as it is required to get v4.9 kernel boot up on ZTE ZX296718 SoC. Thanks.

Shawn

Ok, applied both. Thanks,

Patch 2/2 already went to you in the pull request[1]:

[GIT PULL] ZTE arm64 device tree updates for 4.10

Shawn

[1] http://www.spinics.net/lists/arm-kernel/msg545640.html

#7 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

In reply to Jun Nie

Just noticed this.

Quoted 27 lines · Jun Nie

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Signed-off-by Jun Nie <[email protected]>
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)
arch/arm64/boot/dts/zte/zx296718.dtsi +0 -0
index a223066..6b239a3 100644

arch/arm64/boot/dts/zte/zx296718.dtsi line 243

Quoted 7 lines
arch/arm64/boot/dts/zte/zx296718.dtsi +2 -2
@@ -239,16 +239,11 @@
 		compatible = "arm,gic-v3";
 		#interrupt-cells = <3>;
 		#address-cells = <0>;
-		#redistributor-regions = <6>;
-		redistributor-stride = <0x0 0x40000>;
+		#redistributor-regions = <1>;
+		redistributor-stride = <0x20000>;

Why is that stride specified? Is the GIC implementation so busted that the GICR_TYPER do not report a GICv3 redistributor, which implies a 128kB stride?

Thanks,

	M.
Signature · 1 line
Jazz is not dead. It just smells funny...
#8 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 23 lines · CET Marc Zyngier
Quoted 22 lines · Jun Nie

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Signed-off-by Jun Nie <[email protected]>
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)
Quoted 16 lines

arch/arm64/boot/dts/zte/zx296718.dtsi line 243

Quoted 12 lines
arch/arm64/boot/dts/zte/zx296718.dtsi +2 -2
index a223066..6b239a3 100644
@@ -239,16 +239,11 @@
              compatible = "arm,gic-v3";
              #interrupt-cells = <3>;
              #address-cells = <0>;
-             #redistributor-regions = <6>;
-             redistributor-stride = <0x0 0x40000>;
+             #redistributor-regions = <1>;
+             redistributor-stride = <0x20000>;

Why is that stride specified? Is the GIC implementation so busted that the GICR_TYPER do not report a GICv3 redistributor, which implies a 128kB stride?

Given that there is any concern about the patch now, and the merge window is almost open, I'm moving both patches to the next/fixes-non-critical branch and will merge it for v4.10 instead of sending it for v4.9.

If you end up deciding that the patch is wrong, please follow up with a fix on top. Once the situation is resolved and the patch merged upstream, feel free to ask stable at vger.kernel.org for a backport to stable kernels to get it into v4.9.x.

Arnd

#9 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Hi Arnd,

Quoted 9 lines · Arnd Bergmann

Given that there is any concern about the patch now, and the merge window is almost open, I'm moving both patches to the next/fixes-non-critical branch and will merge it for v4.10 instead of sending it for v4.9.

If you end up deciding that the patch is wrong, please follow up with a fix on top. Once the situation is resolved and the patch merged upstream, feel free to ask stable at vger.kernel.org for a backport to stable kernels to get it into v4.9.x.

The patch is correct, though it can be cleaned up a bit further per Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can still get this into 4.9 to save the stable kernel backport.

I sent you a cleanup patch on top of this one yesterday. If you like, I can quickly resend the patch with the cleanup squashed.

Thanks,
Shawn

#10 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Hi Shawn,

Quoted 13 lines · Shawn Guo

Hi Arnd,

Quoted 9 lines · Arnd Bergmann

Given that there is any concern about the patch now, and the merge window is almost open, I'm moving both patches to the next/fixes-non-critical branch and will merge it for v4.10 instead of sending it for v4.9.

If you end up deciding that the patch is wrong, please follow up with a fix on top. Once the situation is resolved and the patch merged upstream, feel free to ask stable at vger.kernel.org for a backport to stable kernels to get it into v4.9.x.

Quoted 6 lines

The patch is correct, though it can be cleaned up a bit further per Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can still get this into 4.9 to save the stable kernel backport.

I sent you a cleanup patch on top of this one yesterday. If you like, I can quickly resend the patch with the cleanup squashed.

Since the patches have already been applied, an incremental patch to apply on top would work best here.

Thanks!

-Olof

#11 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Hi Olof,

Quoted 20 lines · Olof Johansson

Hi Shawn,

Quoted 17 lines · Shawn Guo

Hi Arnd,

Quoted 9 lines · Arnd Bergmann

Given that there is any concern about the patch now, and the merge window is almost open, I'm moving both patches to the next/fixes-non-critical branch and will merge it for v4.10 instead of sending it for v4.9.

If you end up deciding that the patch is wrong, please follow up with a fix on top. Once the situation is resolved and the patch merged upstream, feel free to ask stable at vger.kernel.org for a backport to stable kernels to get it into v4.9.x.

The patch is correct, though it can be cleaned up a bit further per Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can still get this into 4.9 to save the stable kernel backport.

Quoted 5 lines
Quoted 2 lines

I sent you a cleanup patch on top of this one yesterday. If you like, I can quickly resend the patch with the cleanup squashed.

Since the patches have already been applied, an incremental patch to apply on top would work best here.

No problem. So would you please apply the incremental patch [1] to the same branch? Or I can send it to you later during -rc cycles. Just let me know your preference.

Shawn

[1] https://www.spinics.net/lists/arm-kernel/msg546957.html

#12 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 29 lines · Shawn Guo

Hi Olof,

Quoted 20 lines · Olof Johansson

Hi Shawn,

Quoted 17 lines · Shawn Guo

Hi Arnd,

Quoted 9 lines · Arnd Bergmann

Given that there is any concern about the patch now, and the merge window is almost open, I'm moving both patches to the next/fixes-non-critical branch and will merge it for v4.10 instead of sending it for v4.9.

If you end up deciding that the patch is wrong, please follow up with a fix on top. Once the situation is resolved and the patch merged upstream, feel free to ask stable at vger.kernel.org for a backport to stable kernels to get it into v4.9.x.

The patch is correct, though it can be cleaned up a bit further per Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can still get this into 4.9 to save the stable kernel backport.

Quoted 5 lines
Quoted 2 lines

I sent you a cleanup patch on top of this one yesterday. If you like, I can quickly resend the patch with the cleanup squashed.

Since the patches have already been applied, an incremental patch to apply on top would work best here.

Quoted 7 lines

No problem. So would you please apply the incremental patch [1] to the same branch? Or I can send it to you later during -rc cycles. Just let me know your preference.

Shawn

[1] https://www.spinics.net/lists/arm-kernel/msg546957.html

So, it seems that Arnd didn't apply the old patch to fixes-non-critical, or at least didn't push out after doing it. So, I've done that now, as well as applied the fixup you have above.

-Olof

#13 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 5 lines · CET Olof Johansson

So, it seems that Arnd didn't apply the old patch to fixes-non-critical, or at least didn't push out after doing it. So, I've done that now, as well as applied the fixup you have above.

My mistake, I forgot to push it out.

I checked the other branches now and found two other commits missing in next/fixes-non-critical:

arm64: tegra: Add missing Smaug revision
arm64: tegra: Add VDD_GPU regulator to Jetson TX1

Both sent by Thierry Reding last Friday. I can add them back on top or you pick them up again if you are already busy doing merges.

For the first patch, I had amended the changelog text, this is the version I had.

Arnd

8<---------

Quoted 1 line

From 4d0a00060c1cec86f5aab57c814afbfb3e152578 Mon Sep 17 00:00:00 2001

From: Alexandre Courbot <[email protected]>
Date: Fri, 2 Dec 2016 20:57:55 +0100
Subject: [PATCH] arm64: tegra: Add VDD_GPU regulator to Jetson TX1

Add the VDD_GPU regulator (a GPIO-enabled PWM regulator) to the Jetson TX1 board. This addition allows the GPU to be used provided the bootloader properly enabled the GPU node.

Signed-off-by Alexandre Courbot <[email protected]>
Signed-off-by Thierry Reding <[email protected]>

[as pointed out by Thierry on IRC, nobody has reported a bug
in the field, but using a new bootloader with a .dtb that has the incorrect data, it will crash on boot]

Fixes 336f79c7b6d7 ("arm64: tegra: Add NVIDIA Jetson TX1 Developer Kit support")
Cc stable at vger.kernel.org #v4.5+
Signed-off-by Arnd Bergmann <[email protected]>
arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi +18 -0
index 5fda583..906fb83 100644
@@ -21,6 +21,10 @@
 		reg = <0x0 0x80000000 0x1 0x0>;
 	};
 
+	gpu at 57000000 {
+		vdd-supply = <&vdd_gpu>;
+	};
+
 	/* debug port */
 	serial at 70006000 {
 		status = "okay";

@@ -291,4 +295,18 @@
 			clock-frequency = <32768>;
 		};
 	};
+
+	regulators {
+		vdd_gpu: regulator at 100 {
+			compatible = "pwm-regulator";
+			reg = <100>;
+			pwms = <&pwm 1 4880>;
+			regulator-name = "VDD_GPU";
+			regulator-min-microvolt = <710000>;
+			regulator-max-microvolt = <1320000>;
+			enable-gpios = <&pmic 6 GPIO_ACTIVE_HIGH>;
+			regulator-ramp-delay = <80>;
+			regulator-enable-ramp-delay = <1000>;
+		};
+	};
 };
#14 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Hi,

Quoted 8 lines · Arnd Bergmann
Quoted 5 lines · CET Olof Johansson

So, it seems that Arnd didn't apply the old patch to fixes-non-critical, or at least didn't push out after doing it. So, I've done that now, as well as applied the fixup you have above.

My mistake, I forgot to push it out.

No worries.

Quoted 4 lines

I checked the other branches now and found two other commits missing in next/fixes-non-critical:

Quoted 8 lines

arm64: tegra: Add missing Smaug revision
arm64: tegra: Add VDD_GPU regulator to Jetson TX1

Both sent by Thierry Reding last Friday. I can add them back on top or you pick them up again if you are already busy doing merges.

For the first patch, I had amended the changelog text, this is the version I had.

I'm done touching the tree for today so you can rebase and push your versions if you want -- probably easiest all around.

-Olof

#15 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 7 lines · CET Olof Johansson
Quoted 7 lines

I checked the other branches now and found two other commits missing in next/fixes-non-critical:

arm64: tegra: Add missing Smaug revision
arm64: tegra: Add VDD_GPU regulator to Jetson TX1

Quoted 9 lines
Quoted 5 lines

Both sent by Thierry Reding last Friday. I can add them back on top or you pick them up again if you are already busy doing merges.

For the first patch, I had amended the changelog text, this is the version I had.

I'm done touching the tree for today so you can rebase and push your versions if you want -- probably easiest all around.

Done.

Arnd

#16 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

In reply to Marc Zyngier
Quoted 25 lines · Marc Zyngier

Just noticed this.

Quoted 22 lines · Jun Nie

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Signed-off-by Jun Nie <[email protected]>
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)
Quoted 16 lines

arch/arm64/boot/dts/zte/zx296718.dtsi line 243

Quoted 12 lines
arch/arm64/boot/dts/zte/zx296718.dtsi +2 -2
index a223066..6b239a3 100644
@@ -239,16 +239,11 @@
 		compatible = "arm,gic-v3";
 		#interrupt-cells = <3>;
 		#address-cells = <0>;
-		#redistributor-regions = <6>;
-		redistributor-stride = <0x0 0x40000>;
+		#redistributor-regions = <1>;
+		redistributor-stride = <0x20000>;

Why is that stride specified? Is the GIC implementation so busted that the GICR_TYPER do not report a GICv3 redistributor, which implies a 128kB stride?

No, it's not required per my testing. I guess it's there for documentation purpose to make the stride setting explicit. Are you suggesting that we simply drop it?

Also, it seems that #redistributor-regions can also be saved, since bindings doc tells that it's only required if more than one such region is present?

Shawn

#17 lore raw

PATCH v2 1/2 arm64: dts: zx: Fix gic GICR property

Quoted 43 lines · Shawn Guo
Quoted 25 lines · Marc Zyngier

Just noticed this.

Quoted 22 lines · Jun Nie

GICR for multiple CPU can be described with start address and stride, or with multiple address. Current multiple address and stride are both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:

[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Signed-off-by Jun Nie <[email protected]>
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)
Quoted 16 lines

arch/arm64/boot/dts/zte/zx296718.dtsi line 243

Quoted 12 lines
arch/arm64/boot/dts/zte/zx296718.dtsi +2 -2
index a223066..6b239a3 100644
@@ -239,16 +239,11 @@
 		compatible = "arm,gic-v3";
 		#interrupt-cells = <3>;
 		#address-cells = <0>;
-		#redistributor-regions = <6>;
-		redistributor-stride = <0x0 0x40000>;
+		#redistributor-regions = <1>;
+		redistributor-stride = <0x20000>;

Why is that stride specified? Is the GIC implementation so busted that the GICR_TYPER do not report a GICv3 redistributor, which implies a 128kB stride?

Quoted 3 lines

No, it's not required per my testing. I guess it's there for documentation purpose to make the stride setting explicit. Are you suggesting that we simply drop it?

Indeed. This is only meant as a workaround for some of the most braindead platforms out there which have a redistributor stride that deviates from what the architecture defines (128kB for GICv3, 256kB for GICv4). It is good to know that this implementation is not broken.

Quoted 3 lines

Also, it seems that #redistributor-regions can also be saved, since bindings doc tells that it's only required if more than one such region is present?

This could be removed as well.

Thanks,

        M.
Signature · 1 line
Jazz is not dead. It just smells funny.
author
#18 lore raw

PATCH v2 2/2 arm64: dts: zx: Add clock controller nodes

In reply to Jun Nie

Add clock controller nodes, including one top controller two low speed controllers and one audio controller.

Signed-off-by Jun Nie <[email protected]>
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
arch/arm64/boot/dts/zte/zx296718.dtsi +24 -0
index 6b239a3..e419eff 100644
@@ -279,9 +279,33 @@
 			dma-requests = <32>;
 		};
 
+		lsp0crm: clock-controller at 1420000 {
+			compatible = "zte,zx296718-lsp0crm";
+			reg = <0x01420000 0x1000>;
+			#clock-cells = <1>;
+		};
+
+		lsp1crm: clock-controller at 1430000 {
+			compatible = "zte,zx296718-lsp1crm";
+			reg = <0x01430000 0x1000>;
+			#clock-cells = <1>;
+		};
+
+		topcrm: clock-controller at 1461000 {
+			compatible = "zte,zx296718-topcrm";
+			reg = <0x01461000 0x1000>;
+			#clock-cells = <1>;
+		};
+
 		sysctrl: sysctrl at 1463000 {
 			compatible = "zte,zx296718-sysctrl", "syscon";
 			reg = <0x1463000 0x1000>;
 		};
+
+		audiocrm: clock-controller at 1480000 {
+			compatible = "zte,zx296718-audiocrm";
+			reg = <0x01480000 0x1000>;
+			#clock-cells = <1>;
+		};
 	};
 };
Signature · 1 line
1.9.1
#19 lore raw

PATCH v2 2/2 arm64: dts: zx: Add clock controller nodes

Quoted 7 lines · Jun Nie

Add clock controller nodes, including one top controller two low speed controllers and one audio controller.

Signed-off-by Jun Nie <[email protected]>
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

This isn't a fix for a bug, so please send this with your other updates for v4.10.

Thanks,

-Olof

#20 lore raw

PATCH v2 2/2 arm64: dts: zx: Add clock controller nodes

Quoted 11 lines · Olof Johansson
Quoted 7 lines · Jun Nie

Add clock controller nodes, including one top controller two low speed controllers and one audio controller.

Signed-off-by Jun Nie <[email protected]>
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

This isn't a fix for a bug, so please send this with your other updates for v4.10.

I queued it up for 4.10.

Shawn