20 messages, 6 authors, 2016-12-07 · open the first message on its own page
From: Jun Nie <hidden>
Date: 2016-10-13 12:31:19
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(-) -- 1.9.1
From: Jun Nie <hidden>
Date: 2016-10-13 12:31:20
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 <redacted> --- arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index a223066..6b239a3 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi@@ -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>; };
--
1.9.1
From: Jun Nie <hidden>
Date: 2016-10-13 12:31:21
Add clock controller nodes, including one top controller two low speed controllers and one audio controller. Signed-off-by: Jun Nie <redacted> --- arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a3..e419eff 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi@@ -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>; + }; }; };
--
1.9.1
From: Olof Johansson <hidden>
Date: 2016-10-17 20:48:41
On Thu, Oct 13, 2016 at 08:31:21PM +0800, Jun Nie wrote:
Add clock controller nodes, including one top controller two low speed controllers and one audio controller. Signed-off-by: Jun Nie <redacted> --- 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
From: Olof Johansson <hidden>
Date: 2016-10-17 20:49:19
On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
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 <redacted>
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
From: shawnguo@kernel.org (Shawn Guo)
Date: 2016-10-24 08:56:21
On Mon, Oct 17, 2016 at 01:48:41PM -0700, Olof Johansson wrote:
On Thu, Oct 13, 2016 at 08:31:21PM +0800, Jun Nie wrote:quoted
Add clock controller nodes, including one top controller two low speed controllers and one audio controller. Signed-off-by: Jun Nie <redacted> --- 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
From: arnd@arndb.de (Arnd Bergmann)
Date: 2016-11-25 22:03:35
On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:quoted
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 <redacted>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
From: Shawn Guo <hidden>
Date: 2016-11-28 14:08:18
On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann [off-list ref] wrote:
On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:quoted
On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:quoted
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 <redacted>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?
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
From: arnd@arndb.de (Arnd Bergmann)
Date: 2016-12-02 16:38:01
On Monday, November 28, 2016 10:08:18 PM CET Shawn Guo wrote:
On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann [off-list ref] wrote:quoted
On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:quoted
On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:quoted
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 <redacted>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?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
From: Marc Zyngier <hidden>
Date: 2016-12-02 17:02:28
Just noticed this. On 13/10/16 13:31, Jun Nie wrote:
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 <redacted> --- arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi index a223066..6b239a3 100644 --- a/arch/arm64/boot/dts/zte/zx296718.dtsi +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi@@ -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. -- Jazz is not dead. It just smells funny...
From: arnd@arndb.de (Arnd Bergmann)
Date: 2016-12-02 20:28:58
On Friday, December 2, 2016 5:02:28 PM CET Marc Zyngier wrote:
On 13/10/16 13:31, Jun Nie wrote:quoted
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 <redacted> --- arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi index a223066..6b239a3 100644 --- a/arch/arm64/boot/dts/zte/zx296718.dtsi +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi@@ -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
From: shawnguo@kernel.org (Shawn Guo)
Date: 2016-12-03 09:22:55
On Fri, Dec 02, 2016 at 05:02:28PM +0000, Marc Zyngier wrote:
Just noticed this. On 13/10/16 13:31, Jun Nie wrote:quoted
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 <redacted> --- arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi index a223066..6b239a3 100644 --- a/arch/arm64/boot/dts/zte/zx296718.dtsi +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi@@ -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
From: shawnguo@kernel.org (Shawn Guo)
Date: 2016-12-03 10:55:37
On Fri, Dec 02, 2016 at 05:38:01PM +0100, Arnd Bergmann wrote:
On Monday, November 28, 2016 10:08:18 PM CET Shawn Guo wrote:quoted
On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann [off-list ref] wrote:quoted
On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:quoted
On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:quoted
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 <redacted>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?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. ShawnOk, 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
From: shawnguo@kernel.org (Shawn Guo)
Date: 2016-12-05 02:24:53
Hi Arnd, On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:
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
From: Olof Johansson <hidden>
Date: 2016-12-06 00:55:02
Hi Shawn, On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo [off-list ref] wrote:
Hi Arnd, On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:quoted
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.
Since the patches have already been applied, an incremental patch to apply on top would work best here. Thanks! -Olof
From: shawnguo@kernel.org (Shawn Guo)
Date: 2016-12-06 01:12:46
Hi Olof, On Mon, Dec 05, 2016 at 04:55:02PM -0800, Olof Johansson wrote:
Hi Shawn, On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo [off-list ref] wrote:quoted
Hi Arnd, On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:quoted
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.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
From: Olof Johansson <hidden>
Date: 2016-12-07 20:34:12
On Tue, Dec 06, 2016 at 09:12:46AM +0800, Shawn Guo wrote:
Hi Olof, On Mon, Dec 05, 2016 at 04:55:02PM -0800, Olof Johansson wrote:quoted
Hi Shawn, On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo [off-list ref] wrote:quoted
Hi Arnd, On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:quoted
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.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
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
From: arnd@arndb.de (Arnd Bergmann)
Date: 2016-12-07 21:44:17
On Wednesday, December 7, 2016 12:34:12 PM CET Olof Johansson wrote:
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<---------
From 4d0a00060c1cec86f5aab57c814afbfb3e152578 Mon Sep 17 00:00:00 2001
From: Alexandre Courbot <acourbot@nvidia.com>
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 <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <redacted>
[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 <arnd@arndb.de>
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi b/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi
index 5fda583..906fb83 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi@@ -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>; + }; + }; };
From: Olof Johansson <hidden>
Date: 2016-12-07 22:12:23
Hi, On Wed, Dec 7, 2016 at 1:44 PM, Arnd Bergmann [off-list ref] wrote:
On Wednesday, December 7, 2016 12:34:12 PM CET Olof Johansson wrote:quoted
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.
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.
I'm done touching the tree for today so you can rebase and push your versions if you want -- probably easiest all around. -Olof
From: arnd@arndb.de (Arnd Bergmann)
Date: 2016-12-07 23:25:45
On Wednesday, December 7, 2016 2:12:23 PM CET Olof Johansson wrote:
quoted
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.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