| Message ID | 1476361881-19685-2-git-send-email-jun.nie@linaro.org |
|---|---|
| State | New |
| Headers | show |
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 <jun.nie@linaro.org> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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: > > 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 <jun.nie@linaro.org> > > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote: > 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: >> > 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 <jun.nie@linaro.org> >> >> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Monday, November 28, 2016 10:08:18 PM CET Shawn Guo wrote: > On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > 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: > >> > 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 <jun.nie@linaro.org> > >> > >> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 <jun.nie@linaro.org> > --- > 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... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Friday, December 2, 2016 5:02:28 PM CET Marc Zyngier wrote: > 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 <jun.nie@linaro.org> > > --- > > 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@vger.kernel.org for a backport to stable kernels to get it into v4.9.x. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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: > > 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 <jun.nie@linaro.org> > > --- > > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Dec 03 2016 at 09:22:55 AM, Shawn Guo <shawnguo@kernel.org> wrote: > 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: >> > 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 <jun.nie@linaro.org> >> > --- >> > 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? 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. > 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. -- 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
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: > > On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > > 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: > > >> > 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 <jun.nie@linaro.org> > > >> > > >> 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, 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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@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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Shawn, On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote: > 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@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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 <shawnguo@kernel.org> wrote: > > 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@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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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: > > Hi Shawn, > > > > On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote: > > > 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@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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 <treding@nvidia.com> [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@vger.kernel.org #v4.5+ Signed-off-by: Arnd Bergmann <arnd@arndb.de> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kerneldiff --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@57000000 { + vdd-supply = <&vdd_gpu>; + }; + /* debug port */ serial@70006000 { status = "okay"; @@ -291,4 +295,18 @@ clock-frequency = <32768>; }; }; + + regulators { + vdd_gpu: regulator@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>; + }; + }; };
Hi, On Wed, Dec 7, 2016 at 1:44 PM, Arnd Bergmann <arnd@arndb.de> wrote: > 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. 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wednesday, December 7, 2016 2:12:23 PM CET Olof Johansson wrote: > > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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>; };
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 <jun.nie@linaro.org> --- arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel