* Re: possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast"
2015-06-17 2:48 possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast" Simon Horman
@ 2015-06-17 6:52 ` Magnus Damm
2015-06-17 7:45 ` Geert Uytterhoeven
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Magnus Damm @ 2015-06-17 6:52 UTC (permalink / raw)
To: linux-sh
Hi Simon,
On Wed, Jun 17, 2015 at 11:48 AM, Simon Horman <horms@verge.net.au> wrote:
> cpu_possible_mask to fix SMP broadcast
> Reply-To:
> Organisation: Horms Solutions Ltd.
>
> Hi Magnus, Hi All,
>
> I have observed what appears to be a regression caused by
> f2a5473861cf ("clocksource: sh_tmu: Set cpu_possible_mask to fix SMP
> broadcast"), which was included in v3.19.
>
> The problem I see is that with a kernel compiled using marzen_defconfig on
> the r8a7779/marzen board: i.e. a "legacy" kernel.
>
> The problem does not manifest when booting the same board using
> a kernel built with shmobile_defconfig: i.e. a multiplatform kernel.
>
> It does not appear to affect other boards I have access to:
> emev2/kzm9d, r7s72100/genmai, r8a73a4/ape6evm, r8a7740/armadillo900eva,
> r8a77798/bockw r8a7790/lager r8a7791/koelsch, r8a7794/alt, sh73a0/kzm9g.
>
> I have observed this problem on the renesas-devel-20150617-v4.1-rc8
> tag of my renesas tree. But I do not believe it is exclusive to that tag.
>
> The problem appears to be that there is no clocksource available during
> early boot. The boot log at the end of the email was obtained by
> enabling DEBUG_LL and earlyprintk.
Thanks for reporting this. I suspect that the reason why this triggers
on legacy is that we i such case most likely don't have TWD together
with CCF. Since this is just old legacy code and the multiplatform
version should be equivalent I suggest that the correct approach is to
use multiplatform support instead of legacy. And legacy r8a7779
support should be removed right away if it hasn't already.
Cheers,
/ magnus
> Linux version 4.1.0-rc8-dirty (horms@ayumi.isobedori.kobe.vergenet.net) (gcc version 4.6.3 (GCC) ) #311 SMP Wed Jun 17 10:53:11 JST 2015
> CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr\x10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: marzen
> bootconsole [earlycon0] enabled
> debug: ignoring loglevel setting.
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat c049bec0, node_mem_map eeff8000
> Normal zone: 1520 pages used for memmap
> Normal zone: 0 pages reserved
> Normal zone: 194560 pages, LIFO batch:31
> HighMem zone: 67584 pages, LIFO batch:15
> PERCPU: Embedded 9 pages/cpu @eefc4000 s14976 r0 d21888 u36864
> pcpu-alloc: s14976 r0 d21888 u36864 alloc=9*4096
> pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260624
> Kernel command line: earlyprintk console=ttySC2,115200 ignore_loglevel root=/dev/nfs ip=on
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1034480K/1048576K available (3533K kernel code, 138K rwdata, 812K rodata, 200K init, 167K bss, 14096K reserved, 0K cma-reserved, 270336K highmem)
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
> lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
> pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
> .text : 0xc0008000 - 0xc0447490 (4350 kB)
> .init : 0xc0448000 - 0xc047a000 ( 200 kB)
> .data : 0xc047a000 - 0xc049cbe0 ( 139 kB)
> .bss : 0xc049cbe0 - 0xc04c6960 ( 168 kB)
> Hierarchical RCU implementation.
> Additional per-CPU info printed with stalls.
> NR_IRQS:16 nr_irqs:16 16
> smp_twd: clock not found -2
> sched_clock: 32 bits at 1kHz, resolution 976562ns, wraps every 2097151999511718ns
> sh-tmu.0: ch0: used for clock events
> sh-tmu.0: ch1: used as clock source
> clocksource sh-tmu.0: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000000 ns
> Calibrating delay loop...
>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast"
2015-06-17 2:48 possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast" Simon Horman
2015-06-17 6:52 ` Magnus Damm
@ 2015-06-17 7:45 ` Geert Uytterhoeven
2015-06-17 7:51 ` Magnus Damm
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Geert Uytterhoeven @ 2015-06-17 7:45 UTC (permalink / raw)
To: linux-sh
On Wed, Jun 17, 2015 at 8:52 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Wed, Jun 17, 2015 at 11:48 AM, Simon Horman <horms@verge.net.au> wrote:
>> I have observed what appears to be a regression caused by
>> f2a5473861cf ("clocksource: sh_tmu: Set cpu_possible_mask to fix SMP
>> broadcast"), which was included in v3.19.
>>
>> The problem I see is that with a kernel compiled using marzen_defconfig on
>> the r8a7779/marzen board: i.e. a "legacy" kernel.
>>
>> The problem does not manifest when booting the same board using
>> a kernel built with shmobile_defconfig: i.e. a multiplatform kernel.
>>
>> It does not appear to affect other boards I have access to:
>> emev2/kzm9d, r7s72100/genmai, r8a73a4/ape6evm, r8a7740/armadillo900eva,
>> r8a77798/bockw r8a7790/lager r8a7791/koelsch, r8a7794/alt, sh73a0/kzm9g.
>>
>> I have observed this problem on the renesas-devel-20150617-v4.1-rc8
>> tag of my renesas tree. But I do not believe it is exclusive to that tag.
>>
>> The problem appears to be that there is no clocksource available during
>> early boot. The boot log at the end of the email was obtained by
>> enabling DEBUG_LL and earlyprintk.
>
> Thanks for reporting this. I suspect that the reason why this triggers
> on legacy is that we i such case most likely don't have TWD together
> with CCF. Since this is just old legacy code and the multiplatform
We do have other A9 SMP SoCs (sh73a0, r8a7778).
r8a7779.dtsi has an "arm,cortex-a9-twd-timer" node. r8a7778 hasn't.
sh73a0 also has it, but see http://www.spinics.net/lists/linux-sh/msg39128.html
As bockw and marzen still have -reference variants, it may be more
difficult to fix.
> version should be equivalent I suggest that the correct approach is to
> use multiplatform support instead of legacy. And legacy r8a7779
> support should be removed right away if it hasn't already.
Please wait, so I don't have to rebase the sh73a0/r8a7740 patches I'm
about to send out ;-)
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast"
2015-06-17 2:48 possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast" Simon Horman
2015-06-17 6:52 ` Magnus Damm
2015-06-17 7:45 ` Geert Uytterhoeven
@ 2015-06-17 7:51 ` Magnus Damm
2015-06-17 8:42 ` Simon Horman
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Magnus Damm @ 2015-06-17 7:51 UTC (permalink / raw)
To: linux-sh
Hi Geert,
On Wed, Jun 17, 2015 at 4:45 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Wed, Jun 17, 2015 at 8:52 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> On Wed, Jun 17, 2015 at 11:48 AM, Simon Horman <horms@verge.net.au> wrote:
>>> I have observed what appears to be a regression caused by
>>> f2a5473861cf ("clocksource: sh_tmu: Set cpu_possible_mask to fix SMP
>>> broadcast"), which was included in v3.19.
>>>
>>> The problem I see is that with a kernel compiled using marzen_defconfig on
>>> the r8a7779/marzen board: i.e. a "legacy" kernel.
>>>
>>> The problem does not manifest when booting the same board using
>>> a kernel built with shmobile_defconfig: i.e. a multiplatform kernel.
>>>
>>> It does not appear to affect other boards I have access to:
>>> emev2/kzm9d, r7s72100/genmai, r8a73a4/ape6evm, r8a7740/armadillo900eva,
>>> r8a77798/bockw r8a7790/lager r8a7791/koelsch, r8a7794/alt, sh73a0/kzm9g.
>>>
>>> I have observed this problem on the renesas-devel-20150617-v4.1-rc8
>>> tag of my renesas tree. But I do not believe it is exclusive to that tag.
>>>
>>> The problem appears to be that there is no clocksource available during
>>> early boot. The boot log at the end of the email was obtained by
>>> enabling DEBUG_LL and earlyprintk.
>>
>> Thanks for reporting this. I suspect that the reason why this triggers
>> on legacy is that we i such case most likely don't have TWD together
>> with CCF. Since this is just old legacy code and the multiplatform
>
> We do have other A9 SMP SoCs (sh73a0, r8a7778).
>
> r8a7779.dtsi has an "arm,cortex-a9-twd-timer" node. r8a7778 hasn't.
Right, r8a7778 is not SMP so I don't think there is any TWD there. Or
at least the Linux driver did not use to support running in UP mode.
> sh73a0 also has it, but see http://www.spinics.net/lists/linux-sh/msg39128.html
> As bockw and marzen still have -reference variants, it may be more
> difficult to fix.
Your TWD DT node is nicely pointing out the clock via CCF. On legacy
this is most likely not possible, so we end up with trying to
automatically determining the clock by assuming another clock is
running. At least it used to be like that.
>> version should be equivalent I suggest that the correct approach is to
>> use multiplatform support instead of legacy. And legacy r8a7779
>> support should be removed right away if it hasn't already.
>
> Please wait, so I don't have to rebase the sh73a0/r8a7740 patches I'm
> about to send out ;-)
Sure, please push out so we can clean up. =)
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast"
2015-06-17 2:48 possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast" Simon Horman
` (2 preceding siblings ...)
2015-06-17 7:51 ` Magnus Damm
@ 2015-06-17 8:42 ` Simon Horman
2015-06-17 23:50 ` Magnus Damm
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Simon Horman @ 2015-06-17 8:42 UTC (permalink / raw)
To: linux-sh
On Wed, Jun 17, 2015 at 04:51:07PM +0900, Magnus Damm wrote:
> Hi Geert,
>
> On Wed, Jun 17, 2015 at 4:45 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Wed, Jun 17, 2015 at 8:52 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> >> On Wed, Jun 17, 2015 at 11:48 AM, Simon Horman <horms@verge.net.au> wrote:
> >>> I have observed what appears to be a regression caused by
> >>> f2a5473861cf ("clocksource: sh_tmu: Set cpu_possible_mask to fix SMP
> >>> broadcast"), which was included in v3.19.
> >>>
> >>> The problem I see is that with a kernel compiled using marzen_defconfig on
> >>> the r8a7779/marzen board: i.e. a "legacy" kernel.
> >>>
> >>> The problem does not manifest when booting the same board using
> >>> a kernel built with shmobile_defconfig: i.e. a multiplatform kernel.
> >>>
> >>> It does not appear to affect other boards I have access to:
> >>> emev2/kzm9d, r7s72100/genmai, r8a73a4/ape6evm, r8a7740/armadillo900eva,
> >>> r8a77798/bockw r8a7790/lager r8a7791/koelsch, r8a7794/alt, sh73a0/kzm9g.
> >>>
> >>> I have observed this problem on the renesas-devel-20150617-v4.1-rc8
> >>> tag of my renesas tree. But I do not believe it is exclusive to that tag.
> >>>
> >>> The problem appears to be that there is no clocksource available during
> >>> early boot. The boot log at the end of the email was obtained by
> >>> enabling DEBUG_LL and earlyprintk.
> >>
> >> Thanks for reporting this. I suspect that the reason why this triggers
> >> on legacy is that we i such case most likely don't have TWD together
> >> with CCF. Since this is just old legacy code and the multiplatform
> >
> > We do have other A9 SMP SoCs (sh73a0, r8a7778).
> >
> > r8a7779.dtsi has an "arm,cortex-a9-twd-timer" node. r8a7778 hasn't.
>
> Right, r8a7778 is not SMP so I don't think there is any TWD there. Or
> at least the Linux driver did not use to support running in UP mode.
>
> > sh73a0 also has it, but see http://www.spinics.net/lists/linux-sh/msg39128.html
> > As bockw and marzen still have -reference variants, it may be more
> > difficult to fix.
>
> Your TWD DT node is nicely pointing out the clock via CCF. On legacy
> this is most likely not possible, so we end up with trying to
> automatically determining the clock by assuming another clock is
> running. At least it used to be like that.
>
> >> version should be equivalent I suggest that the correct approach is to
> >> use multiplatform support instead of legacy. And legacy r8a7779
> >> support should be removed right away if it hasn't already.
> >
> > Please wait, so I don't have to rebase the sh73a0/r8a7740 patches I'm
> > about to send out ;-)
>
> Sure, please push out so we can clean up. =)
I'm happy to proceed with an orderly removal of marzen legacy
as a resolution to this problem.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast"
2015-06-17 2:48 possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast" Simon Horman
` (3 preceding siblings ...)
2015-06-17 8:42 ` Simon Horman
@ 2015-06-17 23:50 ` Magnus Damm
2015-06-18 0:51 ` Simon Horman
2015-06-18 5:07 ` Magnus Damm
6 siblings, 0 replies; 8+ messages in thread
From: Magnus Damm @ 2015-06-17 23:50 UTC (permalink / raw)
To: linux-sh
Hi Simon,
On Wed, Jun 17, 2015 at 5:42 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Jun 17, 2015 at 04:51:07PM +0900, Magnus Damm wrote:
>> Hi Geert,
>>
>> On Wed, Jun 17, 2015 at 4:45 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > On Wed, Jun 17, 2015 at 8:52 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> >> On Wed, Jun 17, 2015 at 11:48 AM, Simon Horman <horms@verge.net.au> wrote:
>> >>> I have observed what appears to be a regression caused by
>> >>> f2a5473861cf ("clocksource: sh_tmu: Set cpu_possible_mask to fix SMP
>> >>> broadcast"), which was included in v3.19.
>> >>>
>> >>> The problem I see is that with a kernel compiled using marzen_defconfig on
>> >>> the r8a7779/marzen board: i.e. a "legacy" kernel.
>> >>>
>> >>> The problem does not manifest when booting the same board using
>> >>> a kernel built with shmobile_defconfig: i.e. a multiplatform kernel.
>> >>>
>> >>> It does not appear to affect other boards I have access to:
>> >>> emev2/kzm9d, r7s72100/genmai, r8a73a4/ape6evm, r8a7740/armadillo900eva,
>> >>> r8a77798/bockw r8a7790/lager r8a7791/koelsch, r8a7794/alt, sh73a0/kzm9g.
>> >>>
>> >>> I have observed this problem on the renesas-devel-20150617-v4.1-rc8
>> >>> tag of my renesas tree. But I do not believe it is exclusive to that tag.
>> >>>
>> >>> The problem appears to be that there is no clocksource available during
>> >>> early boot. The boot log at the end of the email was obtained by
>> >>> enabling DEBUG_LL and earlyprintk.
>> >>
>> >> Thanks for reporting this. I suspect that the reason why this triggers
>> >> on legacy is that we i such case most likely don't have TWD together
>> >> with CCF. Since this is just old legacy code and the multiplatform
>> >
>> > We do have other A9 SMP SoCs (sh73a0, r8a7778).
>> >
>> > r8a7779.dtsi has an "arm,cortex-a9-twd-timer" node. r8a7778 hasn't.
>>
>> Right, r8a7778 is not SMP so I don't think there is any TWD there. Or
>> at least the Linux driver did not use to support running in UP mode.
>>
>> > sh73a0 also has it, but see http://www.spinics.net/lists/linux-sh/msg39128.html
>> > As bockw and marzen still have -reference variants, it may be more
>> > difficult to fix.
>>
>> Your TWD DT node is nicely pointing out the clock via CCF. On legacy
>> this is most likely not possible, so we end up with trying to
>> automatically determining the clock by assuming another clock is
>> running. At least it used to be like that.
>>
>> >> version should be equivalent I suggest that the correct approach is to
>> >> use multiplatform support instead of legacy. And legacy r8a7779
>> >> support should be removed right away if it hasn't already.
>> >
>> > Please wait, so I don't have to rebase the sh73a0/r8a7740 patches I'm
>> > about to send out ;-)
>>
>> Sure, please push out so we can clean up. =)
>
> I'm happy to proceed with an orderly removal of marzen legacy
> as a resolution to this problem.
I agree about removing the marzen legacy code. For anyone wanting to
use the legacy code then the following mangled patch can be used to
work around the "calibrating delay" issue:
From: Magnus Damm <damm+renesas@opensource.se>
Rely on CPU frequency information provided by the r8a7779 DTB for
delay calculation.
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---
arch/arm/mach-shmobile/setup-r8a7779.c | 2 ++
1 file changed, 2 insertions(+)
--- 0001/arch/arm/mach-shmobile/setup-r8a7779.c
+++ work/arch/arm/mach-shmobile/setup-r8a7779.c 2015-06-18
08:46:21.062366518 +0900
@@ -675,6 +675,8 @@ void __init r8a7779_add_standard_devices
void __init r8a7779_add_early_devices(void)
{
+ shmobile_init_delay();
+
early_platform_add_devices(r8a7779_early_devices,
ARRAY_SIZE(r8a7779_early_devices));
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast"
2015-06-17 2:48 possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast" Simon Horman
` (4 preceding siblings ...)
2015-06-17 23:50 ` Magnus Damm
@ 2015-06-18 0:51 ` Simon Horman
2015-06-18 5:07 ` Magnus Damm
6 siblings, 0 replies; 8+ messages in thread
From: Simon Horman @ 2015-06-18 0:51 UTC (permalink / raw)
To: linux-sh
On Thu, Jun 18, 2015 at 08:50:11AM +0900, Magnus Damm wrote:
> Hi Simon,
>
> On Wed, Jun 17, 2015 at 5:42 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Jun 17, 2015 at 04:51:07PM +0900, Magnus Damm wrote:
> >> Hi Geert,
> >>
> >> On Wed, Jun 17, 2015 at 4:45 PM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> > On Wed, Jun 17, 2015 at 8:52 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> >> >> On Wed, Jun 17, 2015 at 11:48 AM, Simon Horman <horms@verge.net.au> wrote:
> >> >>> I have observed what appears to be a regression caused by
> >> >>> f2a5473861cf ("clocksource: sh_tmu: Set cpu_possible_mask to fix SMP
> >> >>> broadcast"), which was included in v3.19.
> >> >>>
> >> >>> The problem I see is that with a kernel compiled using marzen_defconfig on
> >> >>> the r8a7779/marzen board: i.e. a "legacy" kernel.
> >> >>>
> >> >>> The problem does not manifest when booting the same board using
> >> >>> a kernel built with shmobile_defconfig: i.e. a multiplatform kernel.
> >> >>>
> >> >>> It does not appear to affect other boards I have access to:
> >> >>> emev2/kzm9d, r7s72100/genmai, r8a73a4/ape6evm, r8a7740/armadillo900eva,
> >> >>> r8a77798/bockw r8a7790/lager r8a7791/koelsch, r8a7794/alt, sh73a0/kzm9g.
> >> >>>
> >> >>> I have observed this problem on the renesas-devel-20150617-v4.1-rc8
> >> >>> tag of my renesas tree. But I do not believe it is exclusive to that tag.
> >> >>>
> >> >>> The problem appears to be that there is no clocksource available during
> >> >>> early boot. The boot log at the end of the email was obtained by
> >> >>> enabling DEBUG_LL and earlyprintk.
> >> >>
> >> >> Thanks for reporting this. I suspect that the reason why this triggers
> >> >> on legacy is that we i such case most likely don't have TWD together
> >> >> with CCF. Since this is just old legacy code and the multiplatform
> >> >
> >> > We do have other A9 SMP SoCs (sh73a0, r8a7778).
> >> >
> >> > r8a7779.dtsi has an "arm,cortex-a9-twd-timer" node. r8a7778 hasn't.
> >>
> >> Right, r8a7778 is not SMP so I don't think there is any TWD there. Or
> >> at least the Linux driver did not use to support running in UP mode.
> >>
> >> > sh73a0 also has it, but see http://www.spinics.net/lists/linux-sh/msg39128.html
> >> > As bockw and marzen still have -reference variants, it may be more
> >> > difficult to fix.
> >>
> >> Your TWD DT node is nicely pointing out the clock via CCF. On legacy
> >> this is most likely not possible, so we end up with trying to
> >> automatically determining the clock by assuming another clock is
> >> running. At least it used to be like that.
> >>
> >> >> version should be equivalent I suggest that the correct approach is to
> >> >> use multiplatform support instead of legacy. And legacy r8a7779
> >> >> support should be removed right away if it hasn't already.
> >> >
> >> > Please wait, so I don't have to rebase the sh73a0/r8a7740 patches I'm
> >> > about to send out ;-)
> >>
> >> Sure, please push out so we can clean up. =)
> >
> > I'm happy to proceed with an orderly removal of marzen legacy
> > as a resolution to this problem.
>
> I agree about removing the marzen legacy code. For anyone wanting to
> use the legacy code then the following mangled patch can be used to
> work around the "calibrating delay" issue:
As it is small I wonder if we we should consider applying the patch below
as a fix and then treating the removal of r8a7779 legacy as a separate
issue.
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Rely on CPU frequency information provided by the r8a7779 DTB for
> delay calculation.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>
> ---
>
>
> arch/arm/mach-shmobile/setup-r8a7779.c | 2 ++
>
> 1 file changed, 2 insertions(+)
>
>
> --- 0001/arch/arm/mach-shmobile/setup-r8a7779.c
>
> +++ work/arch/arm/mach-shmobile/setup-r8a7779.c 2015-06-18
> 08:46:21.062366518 +0900
>
> @@ -675,6 +675,8 @@ void __init r8a7779_add_standard_devices
>
>
>
> void __init r8a7779_add_early_devices(void)
>
> {
>
> + shmobile_init_delay();
>
> +
>
> early_platform_add_devices(r8a7779_early_devices,
>
> ARRAY_SIZE(r8a7779_early_devices));
>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast"
2015-06-17 2:48 possible regression caused by "clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast" Simon Horman
` (5 preceding siblings ...)
2015-06-18 0:51 ` Simon Horman
@ 2015-06-18 5:07 ` Magnus Damm
6 siblings, 0 replies; 8+ messages in thread
From: Magnus Damm @ 2015-06-18 5:07 UTC (permalink / raw)
To: linux-sh
Hi Simon,
On Thu, Jun 18, 2015 at 9:51 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Jun 18, 2015 at 08:50:11AM +0900, Magnus Damm wrote:
>> Hi Simon,
>>
>> On Wed, Jun 17, 2015 at 5:42 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Wed, Jun 17, 2015 at 04:51:07PM +0900, Magnus Damm wrote:
>> >> Hi Geert,
>> >>
>> >> On Wed, Jun 17, 2015 at 4:45 PM, Geert Uytterhoeven
>> >> <geert@linux-m68k.org> wrote:
>> >> > On Wed, Jun 17, 2015 at 8:52 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> >> >> On Wed, Jun 17, 2015 at 11:48 AM, Simon Horman <horms@verge.net.au> wrote:
>> >> >>> I have observed what appears to be a regression caused by
>> >> >>> f2a5473861cf ("clocksource: sh_tmu: Set cpu_possible_mask to fix SMP
>> >> >>> broadcast"), which was included in v3.19.
>> >> >>>
>> >> >>> The problem I see is that with a kernel compiled using marzen_defconfig on
>> >> >>> the r8a7779/marzen board: i.e. a "legacy" kernel.
>> >> >>>
>> >> >>> The problem does not manifest when booting the same board using
>> >> >>> a kernel built with shmobile_defconfig: i.e. a multiplatform kernel.
>> >> >>>
>> >> >>> It does not appear to affect other boards I have access to:
>> >> >>> emev2/kzm9d, r7s72100/genmai, r8a73a4/ape6evm, r8a7740/armadillo900eva,
>> >> >>> r8a77798/bockw r8a7790/lager r8a7791/koelsch, r8a7794/alt, sh73a0/kzm9g.
>> >> >>>
>> >> >>> I have observed this problem on the renesas-devel-20150617-v4.1-rc8
>> >> >>> tag of my renesas tree. But I do not believe it is exclusive to that tag.
>> >> >>>
>> >> >>> The problem appears to be that there is no clocksource available during
>> >> >>> early boot. The boot log at the end of the email was obtained by
>> >> >>> enabling DEBUG_LL and earlyprintk.
>> >> >>
>> >> >> Thanks for reporting this. I suspect that the reason why this triggers
>> >> >> on legacy is that we i such case most likely don't have TWD together
>> >> >> with CCF. Since this is just old legacy code and the multiplatform
>> >> >
>> >> > We do have other A9 SMP SoCs (sh73a0, r8a7778).
>> >> >
>> >> > r8a7779.dtsi has an "arm,cortex-a9-twd-timer" node. r8a7778 hasn't.
>> >>
>> >> Right, r8a7778 is not SMP so I don't think there is any TWD there. Or
>> >> at least the Linux driver did not use to support running in UP mode.
>> >>
>> >> > sh73a0 also has it, but see http://www.spinics.net/lists/linux-sh/msg39128.html
>> >> > As bockw and marzen still have -reference variants, it may be more
>> >> > difficult to fix.
>> >>
>> >> Your TWD DT node is nicely pointing out the clock via CCF. On legacy
>> >> this is most likely not possible, so we end up with trying to
>> >> automatically determining the clock by assuming another clock is
>> >> running. At least it used to be like that.
>> >>
>> >> >> version should be equivalent I suggest that the correct approach is to
>> >> >> use multiplatform support instead of legacy. And legacy r8a7779
>> >> >> support should be removed right away if it hasn't already.
>> >> >
>> >> > Please wait, so I don't have to rebase the sh73a0/r8a7740 patches I'm
>> >> > about to send out ;-)
>> >>
>> >> Sure, please push out so we can clean up. =)
>> >
>> > I'm happy to proceed with an orderly removal of marzen legacy
>> > as a resolution to this problem.
>>
>> I agree about removing the marzen legacy code. For anyone wanting to
>> use the legacy code then the following mangled patch can be used to
>> work around the "calibrating delay" issue:
>
> As it is small I wonder if we we should consider applying the patch below
> as a fix and then treating the removal of r8a7779 legacy as a separate
> issue.
Anything is possible, so feel free to fix it yourself if you'd like.
Focus-wise it seems too much a thing of the past to really spend time
on from my side. I think keeping it as-is and removing legacy some
time soonish is more than good enough.
Cheers,
/ magnus
^ permalink raw reply [flat|nested] 8+ messages in thread