| Message ID | 20141216094854.22639.69181.sendpatchset@w520 (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
On 12/16/2014 10:48 AM, Magnus Damm wrote: > From: Magnus Damm <damm+renesas@opensource.se> > > Update the TMU driver to use cpu_possible_mask as cpumask to make > r8a7779 SMP work as expected with or without the ARM TWD timer. > > Signed-off-by: Magnus Damm <damm+renesas@opensource.se> Applied as a 3.18 fix. Thanks ! -- Daniel ps: May I suggest to use the CLOCK_EVT_FEAT_DYNIRQ flag for this driver ? > --- > > drivers/clocksource/sh_tmu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- 0001/drivers/clocksource/sh_tmu.c > +++ work/drivers/clocksource/sh_tmu.c 2014-12-16 17:49:49.000000000 +0900 > @@ -428,7 +428,7 @@ static void sh_tmu_register_clockevent(s > ced->features = CLOCK_EVT_FEAT_PERIODIC; > ced->features |= CLOCK_EVT_FEAT_ONESHOT; > ced->rating = 200; > - ced->cpumask = cpumask_of(0); > + ced->cpumask = cpu_possible_mask; > ced->set_next_event = sh_tmu_clock_event_next; > ced->set_mode = sh_tmu_clock_event_mode; > ced->suspend = sh_tmu_clock_event_suspend; >
Hi Daniel, On Tuesday 16 December 2014 12:14:40 Daniel Lezcano wrote: > On 12/16/2014 10:48 AM, Magnus Damm wrote: > > From: Magnus Damm <damm+renesas@opensource.se> > > > > Update the TMU driver to use cpu_possible_mask as cpumask to make > > r8a7779 SMP work as expected with or without the ARM TWD timer. > > > > Signed-off-by: Magnus Damm <damm+renesas@opensource.se> > > Applied as a 3.18 fix. You're a bit too fast, I haven't had time to review the patch yet. > ps: May I suggest to use the CLOCK_EVT_FEAT_DYNIRQ flag for this driver ? > > > --- > > > > drivers/clocksource/sh_tmu.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- 0001/drivers/clocksource/sh_tmu.c > > +++ work/drivers/clocksource/sh_tmu.c 2014-12-16 17:49:49.000000000 +0900 > > @@ -428,7 +428,7 @@ static void sh_tmu_register_clockevent(s > > > > ced->features = CLOCK_EVT_FEAT_PERIODIC; > > ced->features |= CLOCK_EVT_FEAT_ONESHOT; > > ced->rating = 200; > > - ced->cpumask = cpumask_of(0); > > + ced->cpumask = cpu_possible_mask; Magnus, how thoroughly have you tested this ? The TMU is indeed usable by all CPUs, so setting the CPU mask to cpu_possible_mask makes sense, but last time I've tried that it broke the broadcast timer due to the heuristics used by the clock events core code. Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and CONFIG_PREEMPT with and without the ARM TWD times, and that you've booted to userspace and tested timer broadcast on all CPUs ? > > ced->set_next_event = sh_tmu_clock_event_next; > > ced->set_mode = sh_tmu_clock_event_mode; > > ced->suspend = sh_tmu_clock_event_suspend;
Hi Magnus, On Tuesday 16 December 2014 13:20:56 Laurent Pinchart wrote: > On Tuesday 16 December 2014 12:14:40 Daniel Lezcano wrote: > > On 12/16/2014 10:48 AM, Magnus Damm wrote: > > > From: Magnus Damm <damm+renesas@opensource.se> > > > > > > Update the TMU driver to use cpu_possible_mask as cpumask to make > > > r8a7779 SMP work as expected with or without the ARM TWD timer. > > > > > > Signed-off-by: Magnus Damm <damm+renesas@opensource.se> > > > > Applied as a 3.18 fix. > > You're a bit too fast, I haven't had time to review the patch yet. > > > ps: May I suggest to use the CLOCK_EVT_FEAT_DYNIRQ flag for this driver ? > > > > > --- > > > > > > drivers/clocksource/sh_tmu.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > --- 0001/drivers/clocksource/sh_tmu.c > > > +++ work/drivers/clocksource/sh_tmu.c 2014-12-16 17:49:49.000000000 > > > +0900 > > > @@ -428,7 +428,7 @@ static void sh_tmu_register_clockevent(s > > > > > > ced->features = CLOCK_EVT_FEAT_PERIODIC; > > > ced->features |= CLOCK_EVT_FEAT_ONESHOT; > > > ced->rating = 200; > > > > > > - ced->cpumask = cpumask_of(0); > > > + ced->cpumask = cpu_possible_mask; > > Magnus, how thoroughly have you tested this ? The TMU is indeed usable by > all CPUs, so setting the CPU mask to cpu_possible_mask makes sense, but > last time I've tried that it broke the broadcast timer due to the > heuristics used by the clock events core code. > > Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and > CONFIG_PREEMPT with and without the ARM TWD times, and that you've booted to > userspace and tested timer broadcast on all CPUs ? I forgot to mention that this should be tested on R8A7740 with TMU only and both TMU and CMT, and on r8A7779 with TMU only both TMU and TWD. Without getting test results I'm afraid I must NACK the patch. > > > ced->set_next_event = sh_tmu_clock_event_next; > > > ced->set_mode = sh_tmu_clock_event_mode; > > > ced->suspend = sh_tmu_clock_event_suspend;
On 12/16/2014 12:20 PM, Laurent Pinchart wrote: > Hi Daniel, > > On Tuesday 16 December 2014 12:14:40 Daniel Lezcano wrote: >> On 12/16/2014 10:48 AM, Magnus Damm wrote: >>> From: Magnus Damm <damm+renesas@opensource.se> >>> >>> Update the TMU driver to use cpu_possible_mask as cpumask to make >>> r8a7779 SMP work as expected with or without the ARM TWD timer. >>> >>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se> >> >> Applied as a 3.18 fix. > > You're a bit too fast, I haven't had time to review the patch yet. Ah, ok. Hanging on then :) > >> ps: May I suggest to use the CLOCK_EVT_FEAT_DYNIRQ flag for this driver ? >> >>> --- >>> >>> drivers/clocksource/sh_tmu.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> --- 0001/drivers/clocksource/sh_tmu.c >>> +++ work/drivers/clocksource/sh_tmu.c 2014-12-16 17:49:49.000000000 +0900 >>> @@ -428,7 +428,7 @@ static void sh_tmu_register_clockevent(s >>> >>> ced->features = CLOCK_EVT_FEAT_PERIODIC; >>> ced->features |= CLOCK_EVT_FEAT_ONESHOT; >>> ced->rating = 200; >>> - ced->cpumask = cpumask_of(0); >>> + ced->cpumask = cpu_possible_mask; > > Magnus, how thoroughly have you tested this ? The TMU is indeed usable by all > CPUs, so setting the CPU mask to cpu_possible_mask makes sense, but last time > I've tried that it broke the broadcast timer due to the heuristics used by the > clock events core code. > > Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and > CONFIG_PREEMPT with and without the ARM TWD times, and that you've booted to > userspace and tested timer broadcast on all CPUs ? > >>> ced->set_next_event = sh_tmu_clock_event_next; >>> ced->set_mode = sh_tmu_clock_event_mode; >>> ced->suspend = sh_tmu_clock_event_suspend; >
Hi Laurent, On Tue, Dec 16, 2014 at 8:20 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Daniel, > > On Tuesday 16 December 2014 12:14:40 Daniel Lezcano wrote: >> On 12/16/2014 10:48 AM, Magnus Damm wrote: >> > From: Magnus Damm <damm+renesas@opensource.se> >> > >> > Update the TMU driver to use cpu_possible_mask as cpumask to make >> > r8a7779 SMP work as expected with or without the ARM TWD timer. >> > >> > Signed-off-by: Magnus Damm <damm+renesas@opensource.se> >> >> Applied as a 3.18 fix. > > You're a bit too fast, I haven't had time to review the patch yet. > >> ps: May I suggest to use the CLOCK_EVT_FEAT_DYNIRQ flag for this driver ? >> >> > --- >> > >> > drivers/clocksource/sh_tmu.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > --- 0001/drivers/clocksource/sh_tmu.c >> > +++ work/drivers/clocksource/sh_tmu.c 2014-12-16 17:49:49.000000000 +0900 >> > @@ -428,7 +428,7 @@ static void sh_tmu_register_clockevent(s >> > >> > ced->features = CLOCK_EVT_FEAT_PERIODIC; >> > ced->features |= CLOCK_EVT_FEAT_ONESHOT; >> > ced->rating = 200; >> > - ced->cpumask = cpumask_of(0); >> > + ced->cpumask = cpu_possible_mask; > > Magnus, how thoroughly have you tested this ? The TMU is indeed usable by all > CPUs, so setting the CPU mask to cpu_possible_mask makes sense, but last time > I've tried that it broke the broadcast timer due to the heuristics used by the > clock events core code. Uhm, so I've tested this particular patch on r8a7779 but I do agree that the TMU is used on a bunch of SoCs if that's what you mean. I don't see how it is different from any other of our timers though, and those got fixed like this earlier. I wonder if you may recall an earlier issue with incorrect clock event priorities and code somehow working-by-accident without the mask set as expected? > Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and > CONFIG_PREEMPT with and without the ARM TWD times, and that you've booted to > userspace and tested timer broadcast on all CPUs ? No I have not. I've booted to user space in initramfs with DT-based TWD on Multiplatform for r8a7779. Without this fix (and other r8a7779 TWD bits) I see a lot of breakage. For instance, TWD and SMP boot is broken on r8a7779 - both legacy and non-legacy. I have not gotten to sh73a0 yet, but I assume it is busted too. Can you please explain to me how the TMU is any different compared to the CMT, MTU2 or STI? =) And no, I don't have any r8a7740 board anymore. Can anyone else test? Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/16/2014 12:46 PM, Magnus Damm wrote: > Hi Laurent, > > On Tue, Dec 16, 2014 at 8:20 PM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >> Hi Daniel, >> >> On Tuesday 16 December 2014 12:14:40 Daniel Lezcano wrote: >>> On 12/16/2014 10:48 AM, Magnus Damm wrote: >>>> From: Magnus Damm <damm+renesas@opensource.se> >>>> >>>> Update the TMU driver to use cpu_possible_mask as cpumask to make >>>> r8a7779 SMP work as expected with or without the ARM TWD timer. >>>> >>>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se> >>> >>> Applied as a 3.18 fix. >> >> You're a bit too fast, I haven't had time to review the patch yet. >> >>> ps: May I suggest to use the CLOCK_EVT_FEAT_DYNIRQ flag for this driver ? >>> >>>> --- >>>> >>>> drivers/clocksource/sh_tmu.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> --- 0001/drivers/clocksource/sh_tmu.c >>>> +++ work/drivers/clocksource/sh_tmu.c 2014-12-16 17:49:49.000000000 +0900 >>>> @@ -428,7 +428,7 @@ static void sh_tmu_register_clockevent(s >>>> >>>> ced->features = CLOCK_EVT_FEAT_PERIODIC; >>>> ced->features |= CLOCK_EVT_FEAT_ONESHOT; >>>> ced->rating = 200; >>>> - ced->cpumask = cpumask_of(0); >>>> + ced->cpumask = cpu_possible_mask; >> >> Magnus, how thoroughly have you tested this ? The TMU is indeed usable by all >> CPUs, so setting the CPU mask to cpu_possible_mask makes sense, but last time >> I've tried that it broke the broadcast timer due to the heuristics used by the >> clock events core code. > > Uhm, so I've tested this particular patch on r8a7779 but I do agree > that the TMU is used on a bunch of SoCs if that's what you mean. I > don't see how it is different from any other of our timers though, and > those got fixed like this earlier. > > I wonder if you may recall an earlier issue with incorrect clock event > priorities and code somehow working-by-accident without the mask set > as expected? Could have been fixed with : ? commit 70e5975d3a04be5479a28eec4a2fb10f98ad2785 Author: Stephen Boyd <sboyd@codeaurora.org> Date: Thu Jun 13 11:39:50 2013 -0700 clockevents: Prefer CPU local devices over global devices On an SMP system with only one global clockevent and a dummy clockevent per CPU we run into problems. We want the dummy clockevents to be registered as the per CPU tick devices, but we can only achieve that if we register the dummy clockevents before the global clockevent or if we artificially inflate the rating of the dummy clockevents to be higher than the rating of the global clockevent. Failure to do so leads to boot hangs when the dummy timers are registered on all other CPUs besides the CPU that accepted the global clockevent as its tick device and there is no broadcast timer to poke the dummy devices. If we're registering multiple clockevents and one clockevent is global and the other is local to a particular CPU we should choose to use the local clockevent regardless of the rating of the device. This way, if the clockevent is a dummy it will take the tick device duty as long as there isn't a higher rated tick device and any global clockevent will be bumped out into broadcast mode, fixing the problem described above. >> Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and >> CONFIG_PREEMPT with and without the ARM TWD times, and that you've booted to >> userspace and tested timer broadcast on all CPUs ? > > No I have not. I've booted to user space in initramfs with DT-based > TWD on Multiplatform for r8a7779. Without this fix (and other r8a7779 > TWD bits) I see a lot of breakage. For instance, TWD and SMP boot is > broken on r8a7779 - both legacy and non-legacy. I have not gotten to > sh73a0 yet, but I assume it is busted too. > > Can you please explain to me how the TMU is any different compared to > the CMT, MTU2 or STI? =) > > And no, I don't have any r8a7740 board anymore. Can anyone else test? > > Cheers, > > / magnus >
Hi Magnus, On Tue, Dec 16, 2014 at 12:46 PM, Magnus Damm <magnus.damm@gmail.com> wrote: >> Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and >> CONFIG_PREEMPT with and without the ARM TWD times, and that you've booted to >> userspace and tested timer broadcast on all CPUs ? > > No I have not. I've booted to user space in initramfs with DT-based > TWD on Multiplatform for r8a7779. Without this fix (and other r8a7779 > TWD bits) I see a lot of breakage. For instance, TWD and SMP boot is > broken on r8a7779 - both legacy and non-legacy. I have not gotten to > sh73a0 yet, but I assume it is busted too. FWIW, I applied this patch, and booted the result successfully and without any user-visible changes on: - koelsch - armadillo-multiplatform - kzm9g-legacy - kzm9g-multiplatform Armadillo-legacy is broken, and probably won't come back (cfr. https://lkml.org/lkml/2014/12/2/339). Kzm9g-reference still hangs at "Calibrating local timer..." (it did work at some point in the past). Note that my local tree is based on renesas-drivers-2014-12-08-v3.18, renesas-devel-20141212-v3.18, and yesterday's upstream, with CCF, PM domain, TWD, and lots of WIP patches from the kitchen sink applied. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Magnus, On Tuesday 16 December 2014 20:46:33 Magnus Damm wrote: > On Tue, Dec 16, 2014 at 8:20 PM, Laurent Pinchart wrote: > > On Tuesday 16 December 2014 12:14:40 Daniel Lezcano wrote: > >> On 12/16/2014 10:48 AM, Magnus Damm wrote: > >> > From: Magnus Damm <damm+renesas@opensource.se> > >> > > >> > Update the TMU driver to use cpu_possible_mask as cpumask to make > >> > r8a7779 SMP work as expected with or without the ARM TWD timer. > >> > > >> > Signed-off-by: Magnus Damm <damm+renesas@opensource.se> > >> > >> Applied as a 3.18 fix. > > > > You're a bit too fast, I haven't had time to review the patch yet. > > > >> ps: May I suggest to use the CLOCK_EVT_FEAT_DYNIRQ flag for this driver ? > >> > >> > --- > >> > > >> > drivers/clocksource/sh_tmu.c | 2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > >> > --- 0001/drivers/clocksource/sh_tmu.c > >> > +++ work/drivers/clocksource/sh_tmu.c 2014-12-16 > >> > 17:49:49.000000000 +0900 @@ -428,7 +428,7 @@ static void > >> > sh_tmu_register_clockevent(s > >> > ced->features = CLOCK_EVT_FEAT_PERIODIC; > >> > ced->features |= CLOCK_EVT_FEAT_ONESHOT; > >> > ced->rating = 200; > >> > - ced->cpumask = cpumask_of(0); > >> > + ced->cpumask = cpu_possible_mask; > > > > Magnus, how thoroughly have you tested this ? The TMU is indeed usable by > > all CPUs, so setting the CPU mask to cpu_possible_mask makes sense, but > > last time I've tried that it broke the broadcast timer due to the > > heuristics used by the clock events core code. > > Uhm, so I've tested this particular patch on r8a7779 but I do agree > that the TMU is used on a bunch of SoCs if that's what you mean. I > don't see how it is different from any other of our timers though, and > those got fixed like this earlier. > > I wonder if you may recall an earlier issue with incorrect clock event > priorities and code somehow working-by-accident without the mask set > as expected? As discussed privately today, I've had this exact same patch in one of my private branches, and I haven't pushed it upstream at the same time as the similar cmt and mtu2 patches due to a regression. Unfortunately I don't remember the details :-/ I'll test the patch on Marzen and KZM9G. I unfortunately can't test it on Armadillo as I don't have access to that board anymore. > > Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and > > CONFIG_PREEMPT with and without the ARM TWD times, and that you've booted > > to userspace and tested timer broadcast on all CPUs ? > > No I have not. I've booted to user space in initramfs with DT-based > TWD on Multiplatform for r8a7779. Without this fix (and other r8a7779 > TWD bits) I see a lot of breakage. For instance, TWD and SMP boot is > broken on r8a7779 - both legacy and non-legacy. I have not gotten to > sh73a0 yet, but I assume it is busted too. > > Can you please explain to me how the TMU is any different compared to > the CMT, MTU2 or STI? =) I don't know yet :-) I'll hopefully have more information after testing on KZM9G. > And no, I don't have any r8a7740 board anymore. Can anyone else test?
Hi Daniel, On Tuesday 16 December 2014 12:54:56 Daniel Lezcano wrote: > On 12/16/2014 12:46 PM, Magnus Damm wrote: > > On Tue, Dec 16, 2014 at 8:20 PM, Laurent Pinchart wrote: > >> On Tuesday 16 December 2014 12:14:40 Daniel Lezcano wrote: > >>> On 12/16/2014 10:48 AM, Magnus Damm wrote: > >>>> From: Magnus Damm <damm+renesas@opensource.se> > >>>> > >>>> Update the TMU driver to use cpu_possible_mask as cpumask to make > >>>> r8a7779 SMP work as expected with or without the ARM TWD timer. > >>>> > >>>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se> > >>> > >>> Applied as a 3.18 fix. > >> > >> You're a bit too fast, I haven't had time to review the patch yet. > >> > >>> ps: May I suggest to use the CLOCK_EVT_FEAT_DYNIRQ flag for this driver > >>> ? > >>> > >>>> --- > >>>> drivers/clocksource/sh_tmu.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> --- 0001/drivers/clocksource/sh_tmu.c > >>>> +++ work/drivers/clocksource/sh_tmu.c 2014-12-16 > >>>> 17:49:49.000000000 +0900 @@ -428,7 +428,7 @@ static void > >>>> sh_tmu_register_clockevent(s > >>>> ced->features = CLOCK_EVT_FEAT_PERIODIC; > >>>> ced->features |= CLOCK_EVT_FEAT_ONESHOT; > >>>> ced->rating = 200; > >>>> - ced->cpumask = cpumask_of(0); > >>>> + ced->cpumask = cpu_possible_mask; > >> > >> Magnus, how thoroughly have you tested this ? The TMU is indeed usable by > >> all CPUs, so setting the CPU mask to cpu_possible_mask makes sense, but > >> last time I've tried that it broke the broadcast timer due to the > >> heuristics used by the clock events core code. > > > > Uhm, so I've tested this particular patch on r8a7779 but I do agree > > that the TMU is used on a bunch of SoCs if that's what you mean. I > > don't see how it is different from any other of our timers though, and > > those got fixed like this earlier. > > > > I wonder if you may recall an earlier issue with incorrect clock event > > priorities and code somehow working-by-accident without the mask set > > as expected? > > Could have been fixed with : ? > > commit 70e5975d3a04be5479a28eec4a2fb10f98ad2785 > Author: Stephen Boyd <sboyd@codeaurora.org> > Date: Thu Jun 13 11:39:50 2013 -0700 > > clockevents: Prefer CPU local devices over global devices > > On an SMP system with only one global clockevent and a dummy > clockevent per CPU we run into problems. We want the dummy > clockevents to be registered as the per CPU tick devices, but > we can only achieve that if we register the dummy clockevents > before the global clockevent or if we artificially inflate the > rating of the dummy clockevents to be higher than the rating > of the global clockevent. Failure to do so leads to boot > hangs when the dummy timers are registered on all other CPUs > besides the CPU that accepted the global clockevent as its tick > device and there is no broadcast timer to poke the dummy > devices. > > If we're registering multiple clockevents and one clockevent is > global and the other is local to a particular CPU we should > choose to use the local clockevent regardless of the rating of > the device. This way, if the clockevent is a dummy it will take > the tick device duty as long as there isn't a higher rated tick > device and any global clockevent will be bumped out into > broadcast mode, fixing the problem described above. I think I had that patch in my tree when I noticed the breakage, since my own tmu patch dates from February 2014. I'll retest it though and will let you know. > >> Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and > >> CONFIG_PREEMPT with and without the ARM TWD times, and that you've booted > >> to userspace and tested timer broadcast on all CPUs ? > > > > No I have not. I've booted to user space in initramfs with DT-based > > TWD on Multiplatform for r8a7779. Without this fix (and other r8a7779 > > TWD bits) I see a lot of breakage. For instance, TWD and SMP boot is > > broken on r8a7779 - both legacy and non-legacy. I have not gotten to > > sh73a0 yet, but I assume it is busted too. > > > > Can you please explain to me how the TMU is any different compared to > > the CMT, MTU2 or STI? =) > > > > And no, I don't have any r8a7740 board anymore. Can anyone else test?
Hi Geert, On Tue, Dec 16, 2014 at 9:40 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Magnus, > > On Tue, Dec 16, 2014 at 12:46 PM, Magnus Damm <magnus.damm@gmail.com> wrote: >>> Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and >>> CONFIG_PREEMPT with and without the ARM TWD times, and that you've booted to >>> userspace and tested timer broadcast on all CPUs ? >> >> No I have not. I've booted to user space in initramfs with DT-based >> TWD on Multiplatform for r8a7779. Without this fix (and other r8a7779 >> TWD bits) I see a lot of breakage. For instance, TWD and SMP boot is >> broken on r8a7779 - both legacy and non-legacy. I have not gotten to >> sh73a0 yet, but I assume it is busted too. > > FWIW, I applied this patch, and booted the result successfully and without > any user-visible changes on: > - koelsch > - armadillo-multiplatform > - kzm9g-legacy > - kzm9g-multiplatform Thanks for testing - now let us wait and see what Laurent says. > Armadillo-legacy is broken, and probably won't come back (cfr. > https://lkml.org/lkml/2014/12/2/339). > > Kzm9g-reference still hangs at "Calibrating local timer..." (it did work > at some point in the past). When the time allows I'd like us to try to fix up these somehow. At least I'll give it a go - I guess Armadillo is difficult without any board. > Note that my local tree is based on renesas-drivers-2014-12-08-v3.18, > renesas-devel-20141212-v3.18, and yesterday's upstream, with CCF, > PM domain, TWD, and lots of WIP patches from the kitchen sink applied. The TWD portion above - is it driver code or integration stuff? If the latter - is there any reason why these can't be picked up by Simon and merged right away. My plan is to dig into sh73a0 (maybe including TWD) later today. Thanks for your help! / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Magnus and Geert, On Wednesday 17 December 2014 10:30:33 Magnus Damm wrote: > On Tue, Dec 16, 2014 at 9:40 PM, Geert Uytterhoeven wrote: > > On Tue, Dec 16, 2014 at 12:46 PM, Magnus Damm wrote: > >>> Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and > >>> CONFIG_PREEMPT with and without the ARM TWD times, and that you've > >>> booted to userspace and tested timer broadcast on all CPUs ? > >> > >> No I have not. I've booted to user space in initramfs with DT-based > >> TWD on Multiplatform for r8a7779. Without this fix (and other r8a7779 > >> TWD bits) I see a lot of breakage. For instance, TWD and SMP boot is > >> broken on r8a7779 - both legacy and non-legacy. I have not gotten to > >> sh73a0 yet, but I assume it is busted too. > > > > FWIW, I applied this patch, and booted the result successfully and without > > > > any user-visible changes on: > > - koelsch > > - armadillo-multiplatform > > - kzm9g-legacy > > - kzm9g-multiplatform > > Thanks for testing - now let us wait and see what Laurent says. > > > Armadillo-legacy is broken, and probably won't come back (cfr. > > https://lkml.org/lkml/2014/12/2/339). > > > > Kzm9g-reference still hangs at "Calibrating local timer..." (it did work > > at some point in the past). kzm9g-reference boots for me with kzm9g_defconfig on Simon's devel branch with CONFIG_PREEMPT_NONE but fails to boot with CONFIG_PREEMPT. The platform doesn't instantiate the TMU at the moment anyway, so it's unrelated to this patch. Given that kzm9g-legacy works for me regardless of the preempt configuration and on the TMU cpumask, that kzm9g-reference doesn't use TMU, and that you've tested kzm9g-multiplaform successfully, I think we can consider that this patch is safe from a kzm9g point of view. (By the way, how have you tested kzm9g-multiplatform given that none of renesas-drivers-2014-12-08-v3.18, renesas-devel-20141212-v3.18 or today's upstream support multiplatform kernels for sh73a0 ?) Magnus, you have told me that you've performed tests on Marzen with CONFIG_PREEMPT_NONE and with both TWD enabled and disabled. If you could perform the same tests with CONFIG_PREEMPT instead without noticing any regression I think we can merge your patch. Whatever breakage it has caused in the past is likely hidden somewhere beyond eyesight. > When the time allows I'd like us to try to fix up these somehow. At > least I'll give it a go - I guess Armadillo is difficult without any > board. I'd like that very much. Let's get rid of r8a73a4 legacy (Ulrich's patches should be ready) first, and possible sh73a0 and r8a7740 as well, and then retest our various timers configurations. We should test both CONFIG_PREEMPT and CONFIG_PREEMPT none, with all combination of the CMT, TMU, MTU2, TWD and ARM architected timer enabled. > > Note that my local tree is based on renesas-drivers-2014-12-08-v3.18, > > renesas-devel-20141212-v3.18, and yesterday's upstream, with CCF, > > PM domain, TWD, and lots of WIP patches from the kitchen sink applied. > > The TWD portion above - is it driver code or integration stuff? If the > latter - is there any reason why these can't be picked up by Simon and > merged right away. > > My plan is to dig into sh73a0 (maybe including TWD) later today.
Hi Magnus, On Wed, Dec 17, 2014 at 2:30 AM, Magnus Damm <magnus.damm@gmail.com> wrote: >> Armadillo-legacy is broken, and probably won't come back (cfr. >> https://lkml.org/lkml/2014/12/2/339). >> >> Kzm9g-reference still hangs at "Calibrating local timer..." (it did work >> at some point in the past). > > When the time allows I'd like us to try to fix up these somehow. At > least I'll give it a go - I guess Armadillo is difficult without any > board. To fix Armadillo, we have to instantiate the GIC from C code, which is a step backwards. >> Note that my local tree is based on renesas-drivers-2014-12-08-v3.18, >> renesas-devel-20141212-v3.18, and yesterday's upstream, with CCF, >> PM domain, TWD, and lots of WIP patches from the kitchen sink applied. > > The TWD portion above - is it driver code or integration stuff? If the > latter - is there any reason why these can't be picked up by Simon and > merged right away. Integration stuff. Basically it's http://www.spinics.net/lists/arm-kernel/msg383413.html In the mean time, I found the right clock, but I still have to repost that (sorry, recovering from being ill --- merge windows don't help much ;-) > My plan is to dig into sh73a0 (maybe including TWD) later today. Okay, thanks! 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Laurent, On Wed, Dec 17, 2014 at 3:08 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >> > Kzm9g-reference still hangs at "Calibrating local timer..." (it did work >> > at some point in the past). > > kzm9g-reference boots for me with kzm9g_defconfig on Simon's devel branch with OK. I had expected the breakage to be something in my tree, either an issue in a -next branch I'm using, an interaction with the CCF patches or so, or a config issue (e.g. CONFIG_CPU_IDLE became broken lately if the TWD is not in DT). > (By the way, how have you tested kzm9g-multiplatform given that none of > renesas-drivers-2014-12-08-v3.18, renesas-devel-20141212-v3.18 or today's > upstream support multiplatform kernels for sh73a0 ?) As I said, my local tree contains lots of extra patches (erhm... 233). > Magnus, you have told me that you've performed tests on Marzen with > CONFIG_PREEMPT_NONE and with both TWD enabled and disabled. If you could > perform the same tests with CONFIG_PREEMPT instead without noticing any > regression I think we can merge your patch. Whatever breakage it has caused in > the past is likely hidden somewhere beyond eyesight. > >> When the time allows I'd like us to try to fix up these somehow. At >> least I'll give it a go - I guess Armadillo is difficult without any >> board. I do have an Armadillo. > I'd like that very much. Let's get rid of r8a73a4 legacy (Ulrich's patches > should be ready) first, and possible sh73a0 and r8a7740 as well, and then > retest our various timers configurations. We should test both CONFIG_PREEMPT > and CONFIG_PREEMPT none, with all combination of the CMT, TMU, MTU2, TWD and > ARM architected timer enabled. Yes, getting rid of more legacy is good. It's just a pity for the Penguin on the Armadillo's LCD, which doesn't want to visit armadillo-multiplatform. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Laurent, Magnus, On Wed, Dec 17, 2014 at 9:30 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Wed, Dec 17, 2014 at 3:08 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >>> > Kzm9g-reference still hangs at "Calibrating local timer..." (it did work >>> > at some point in the past). >> >> kzm9g-reference boots for me with kzm9g_defconfig on Simon's devel branch with > > OK. > > I had expected the breakage to be something in my tree, either an issue in > a -next branch I'm using, an interaction with the CCF patches or so, or a > config issue (e.g. CONFIG_CPU_IDLE became broken lately if the TWD is > not in DT). Kzm9g-reference hangs at "Calibrating local timer..." because I added the TWD to sh73a0.dtsi (http://www.spinics.net/lists/arm-kernel/msg383413.html). As twd_get_clock() does if (np) twd_clk = of_clk_get(np, 0); else twd_clk = clk_get_sys("smp_twd", NULL); it's not DT-without-CCF proof, and kzm9g-reference cannot get its clock :-( So the TWD node should be in sh73a0-kzm9g-multiplatform.dts, and we need more dts files instead of less... Note that I added the TWD node to DT to fix a hang on kzm9g-multiplatform with CONFIG_CPU_IDLE=y (recently introduced "regression" in core code) after: DMA: preallocated 256 KiB pool for atomic coherent allocations On kzm9g-legacy the TWD is instantiated from C board code (machine_desc.init_time = sh73a0_earlytimer_init), so CONFIG_CPU_IDLE=y does not hang. Despite https://lkml.org/lkml/2014/12/2/339. On kzm9g-reference, the TWD is not instantiated, causing the same hang. If I instantiate the TWD from C board code there, it fails with twd: can't register interrupt 29 (-22) which looks like a symptom of https://lkml.org/lkml/2014/12/2/339 So no cookies for users of several -legacy and -reference platforms in v3.19-rc1 this Monday... 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On Wednesday 17 December 2014 09:30:57 Geert Uytterhoeven wrote: > On Wed, Dec 17, 2014 at 3:08 AM, Laurent Pinchart wrote: > >> > Kzm9g-reference still hangs at "Calibrating local timer..." (it did > >> > work at some point in the past). > > > > kzm9g-reference boots for me with kzm9g_defconfig on Simon's devel branch > > with > > OK. > > I had expected the breakage to be something in my tree, either an issue in > a -next branch I'm using, an interaction with the CCF patches or so, or a > config issue (e.g. CONFIG_CPU_IDLE became broken lately if the TWD is > not in DT). > > > (By the way, how have you tested kzm9g-multiplatform given that none of > > renesas-drivers-2014-12-08-v3.18, renesas-devel-20141212-v3.18 or today's > > upstream support multiplatform kernels for sh73a0 ?) > > As I said, my local tree contains lots of extra patches (erhm... 233). We should probably synchronize at some point and get pending patches merged, or you'll loose sanity :-) What multiplatform support patches do you plan to submit for v3.20 ? > > Magnus, you have told me that you've performed tests on Marzen with > > CONFIG_PREEMPT_NONE and with both TWD enabled and disabled. If you could > > perform the same tests with CONFIG_PREEMPT instead without noticing any > > regression I think we can merge your patch. Whatever breakage it has > > caused in the past is likely hidden somewhere beyond eyesight. > > > >> When the time allows I'd like us to try to fix up these somehow. At > >> least I'll give it a go - I guess Armadillo is difficult without any > >> board. > > I do have an Armadillo. > > > I'd like that very much. Let's get rid of r8a73a4 legacy (Ulrich's patches > > should be ready) first, and possible sh73a0 and r8a7740 as well, and then > > retest our various timers configurations. We should test both > > CONFIG_PREEMPT and CONFIG_PREEMPT none, with all combination of the CMT, > > TMU, MTU2, TWD and ARM architected timer enabled. > > Yes, getting rid of more legacy is good. It's just a pity for the Penguin on > the Armadillo's LCD, which doesn't want to visit armadillo-multiplatform.
Hi Geert, On Wednesday 17 December 2014 10:42:52 Geert Uytterhoeven wrote: > On Wed, Dec 17, 2014 at 9:30 AM, Geert Uytterhoeven wrote: > > On Wed, Dec 17, 2014 at 3:08 AM, Laurent Pinchart wrote: > >>>> Kzm9g-reference still hangs at "Calibrating local timer..." (it did > >>>> work at some point in the past). > >> > >> kzm9g-reference boots for me with kzm9g_defconfig on Simon's devel branch > >> with > >> > > OK. > > > > I had expected the breakage to be something in my tree, either an issue in > > a -next branch I'm using, an interaction with the CCF patches or so, or a > > config issue (e.g. CONFIG_CPU_IDLE became broken lately if the TWD is > > not in DT). > > Kzm9g-reference hangs at "Calibrating local timer..." because I added the > TWD to sh73a0.dtsi (http://www.spinics.net/lists/arm-kernel/msg383413.html). > > As twd_get_clock() does > > if (np) > twd_clk = of_clk_get(np, 0); > else > twd_clk = clk_get_sys("smp_twd", NULL); > > it's not DT-without-CCF proof, and kzm9g-reference cannot get its clock :-( > > So the TWD node should be in sh73a0-kzm9g-multiplatform.dts, and we need > more dts files instead of less... > > Note that I added the TWD node to DT to fix a hang on kzm9g-multiplatform > with CONFIG_CPU_IDLE=y (recently introduced "regression" in core code) > after: > > DMA: preallocated 256 KiB pool for atomic coherent allocations > > On kzm9g-legacy the TWD is instantiated from C board code > (machine_desc.init_time = sh73a0_earlytimer_init), so CONFIG_CPU_IDLE=y > does not hang. Despite https://lkml.org/lkml/2014/12/2/339. > > On kzm9g-reference, the TWD is not instantiated, causing the same hang. > If I instantiate the TWD from C board code there, it fails with > > twd: can't register interrupt 29 (-22) > > which looks like a symptom of https://lkml.org/lkml/2014/12/2/339 > > So no cookies for users of several -legacy and -reference platforms in > v3.19-rc1 this Monday... I'm not sure if fixing that would be worth it. Should we instead try to replace kzm9g-legacy and kzm9g-reference by kzm9g-multiplatform in v3.20 ? What are we missing ? - The DIV6 multiparent series has been merged by Mike, and the sh73a0 CCF is nearly ready. - We need proper BSC support to get LAN working, although it could be worked around temporarily by specifying the BSC clock in the LAN node if I recall correctly. - MMCIF and SDHI are present. - Sound support is there as far as I can tell, but possibly without DMA. - Touchscreen and magnetometer have DT bindings but are not instantiated in the dts at the moment. That should be easy to fix. - Accelerometer and RTC have no DT bindings, but they should work with the I2C core OF match support. - We're loosing USBHS (driver supports OF but doesn't cover sh73a0), USB host (no OF support in driver) and LCDC (no OF support in driver). All but USBHS, USB host and LCDC should be possible to support in v3.20 without too much issues, depending on the effort we can put in this.
Hi Laurent, On Wed, Dec 17, 2014 at 1:04 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Wednesday 17 December 2014 10:42:52 Geert Uytterhoeven wrote: >> On Wed, Dec 17, 2014 at 9:30 AM, Geert Uytterhoeven wrote: >> > On Wed, Dec 17, 2014 at 3:08 AM, Laurent Pinchart wrote: >> >>>> Kzm9g-reference still hangs at "Calibrating local timer..." (it did >> >>>> work at some point in the past). >> >> >> >> kzm9g-reference boots for me with kzm9g_defconfig on Simon's devel branch >> >> with >> >> >> > OK. >> > >> > I had expected the breakage to be something in my tree, either an issue in >> > a -next branch I'm using, an interaction with the CCF patches or so, or a >> > config issue (e.g. CONFIG_CPU_IDLE became broken lately if the TWD is >> > not in DT). >> >> Kzm9g-reference hangs at "Calibrating local timer..." because I added the >> TWD to sh73a0.dtsi (http://www.spinics.net/lists/arm-kernel/msg383413.html). >> >> As twd_get_clock() does >> >> if (np) >> twd_clk = of_clk_get(np, 0); >> else >> twd_clk = clk_get_sys("smp_twd", NULL); >> >> it's not DT-without-CCF proof, and kzm9g-reference cannot get its clock :-( >> >> So the TWD node should be in sh73a0-kzm9g-multiplatform.dts, and we need >> more dts files instead of less... >> >> Note that I added the TWD node to DT to fix a hang on kzm9g-multiplatform >> with CONFIG_CPU_IDLE=y (recently introduced "regression" in core code) >> after: >> >> DMA: preallocated 256 KiB pool for atomic coherent allocations >> >> On kzm9g-legacy the TWD is instantiated from C board code >> (machine_desc.init_time = sh73a0_earlytimer_init), so CONFIG_CPU_IDLE=y >> does not hang. Despite https://lkml.org/lkml/2014/12/2/339. >> >> On kzm9g-reference, the TWD is not instantiated, causing the same hang. >> If I instantiate the TWD from C board code there, it fails with >> >> twd: can't register interrupt 29 (-22) >> >> which looks like a symptom of https://lkml.org/lkml/2014/12/2/339 >> >> So no cookies for users of several -legacy and -reference platforms in >> v3.19-rc1 this Monday... > > I'm not sure if fixing that would be worth it. Should we instead try to > replace kzm9g-legacy and kzm9g-reference by kzm9g-multiplatform in v3.20 ? v3.20 is reasonable. Except that some breakage will arrive in v3.19-rc1. So there will be a brokenness window for the kzm9g platform between v3.18 and v3.20. > What are we missing ? > > - The DIV6 multiparent series has been merged by Mike, and the sh73a0 CCF is > nearly ready. Yep. > - We need proper BSC support to get LAN working, although it could be worked > around temporarily by specifying the BSC clock in the LAN node if I recall > correctly. Working on that. I hope to send out v2 later today... > - Accelerometer and RTC have no DT bindings, but they should work with the I2C > core OF match support. I have RTC in my DTS, and it works. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On Wednesday 17 December 2014 13:11:05 Geert Uytterhoeven wrote: > On Wed, Dec 17, 2014 at 1:04 PM, Laurent Pinchart wrote: > > On Wednesday 17 December 2014 10:42:52 Geert Uytterhoeven wrote: > >> On Wed, Dec 17, 2014 at 9:30 AM, Geert Uytterhoeven wrote: > >> > On Wed, Dec 17, 2014 at 3:08 AM, Laurent Pinchart wrote: > >> >>>> Kzm9g-reference still hangs at "Calibrating local timer..." (it did > >> >>>> work at some point in the past). > >> >> > >> >> kzm9g-reference boots for me with kzm9g_defconfig on Simon's devel > >> >> branch with > >> > > >> > OK. > >> > > >> > I had expected the breakage to be something in my tree, either an issue > >> > in a -next branch I'm using, an interaction with the CCF patches or so, > >> > or a config issue (e.g. CONFIG_CPU_IDLE became broken lately if the TWD > >> > is not in DT). > >> > >> Kzm9g-reference hangs at "Calibrating local timer..." because I added the > >> TWD to sh73a0.dtsi > >> (http://www.spinics.net/lists/arm-kernel/msg383413.html). > >> > >> As twd_get_clock() does > >> > >> if (np) > >> twd_clk = of_clk_get(np, 0); > >> else > >> twd_clk = clk_get_sys("smp_twd", NULL); > >> > >> it's not DT-without-CCF proof, and kzm9g-reference cannot get its clock > >> :-( > >> > >> So the TWD node should be in sh73a0-kzm9g-multiplatform.dts, and we need > >> more dts files instead of less... > >> > >> Note that I added the TWD node to DT to fix a hang on kzm9g-multiplatform > >> with CONFIG_CPU_IDLE=y (recently introduced "regression" in core code) > >> after: > >> > >> DMA: preallocated 256 KiB pool for atomic coherent allocations > >> > >> On kzm9g-legacy the TWD is instantiated from C board code > >> (machine_desc.init_time = sh73a0_earlytimer_init), so CONFIG_CPU_IDLE=y > >> does not hang. Despite https://lkml.org/lkml/2014/12/2/339. > >> > >> On kzm9g-reference, the TWD is not instantiated, causing the same hang. > >> If I instantiate the TWD from C board code there, it fails with > >> > >> twd: can't register interrupt 29 (-22) > >> > >> which looks like a symptom of https://lkml.org/lkml/2014/12/2/339 > >> > >> So no cookies for users of several -legacy and -reference platforms in > >> v3.19-rc1 this Monday... > > > > I'm not sure if fixing that would be worth it. Should we instead try to > > replace kzm9g-legacy and kzm9g-reference by kzm9g-multiplatform in v3.20 ? > > v3.20 is reasonable. Except that some breakage will arrive in v3.19-rc1. > So there will be a brokenness window for the kzm9g platform between > v3.18 and v3.20. I know, and that's unfortunate, but I wonder if we should really spend time on fixing that if we can get multiplatform support merged in v3.20. We could consider multiplatform to be a regression fix and get it merged in v3.19, but that might be a bit far-fetched :-) > > What are we missing ? > > > > - The DIV6 multiparent series has been merged by Mike, and the sh73a0 CCF > > is nearly ready. > > Yep. > > > - We need proper BSC support to get LAN working, although it could be > > worked around temporarily by specifying the BSC clock in the LAN node if > > I recall correctly. > > Working on that. I hope to send out v2 later today... > > > - Accelerometer and RTC have no DT bindings, but they should work with the > > I2C core OF match support. > > I have RTC in my DTS, and it works. Great. I can help with at least some of the remaining pieces if you share your working branch.
Hi Laurent, On Wed, Dec 17, 2014 at 11:08 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Magnus and Geert, > > On Wednesday 17 December 2014 10:30:33 Magnus Damm wrote: >> On Tue, Dec 16, 2014 at 9:40 PM, Geert Uytterhoeven wrote: >> > On Tue, Dec 16, 2014 at 12:46 PM, Magnus Damm wrote: >> >>> Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and >> >>> CONFIG_PREEMPT with and without the ARM TWD times, and that you've >> >>> booted to userspace and tested timer broadcast on all CPUs ? >> >> >> >> No I have not. I've booted to user space in initramfs with DT-based >> >> TWD on Multiplatform for r8a7779. Without this fix (and other r8a7779 >> >> TWD bits) I see a lot of breakage. For instance, TWD and SMP boot is >> >> broken on r8a7779 - both legacy and non-legacy. I have not gotten to >> >> sh73a0 yet, but I assume it is busted too. >> > >> > FWIW, I applied this patch, and booted the result successfully and without >> > >> > any user-visible changes on: >> > - koelsch >> > - armadillo-multiplatform >> > - kzm9g-legacy >> > - kzm9g-multiplatform >> >> Thanks for testing - now let us wait and see what Laurent says. >> >> > Armadillo-legacy is broken, and probably won't come back (cfr. >> > https://lkml.org/lkml/2014/12/2/339). >> > >> > Kzm9g-reference still hangs at "Calibrating local timer..." (it did work >> > at some point in the past). > > kzm9g-reference boots for me with kzm9g_defconfig on Simon's devel branch with > CONFIG_PREEMPT_NONE but fails to boot with CONFIG_PREEMPT. The platform > doesn't instantiate the TMU at the moment anyway, so it's unrelated to this > patch. Ok, thanks for testing. That makes sense. > Given that kzm9g-legacy works for me regardless of the preempt configuration > and on the TMU cpumask, that kzm9g-reference doesn't use TMU, and that you've > tested kzm9g-multiplaform successfully, I think we can consider that this > patch is safe from a kzm9g point of view. I think so too. > (By the way, how have you tested kzm9g-multiplatform given that none of > renesas-drivers-2014-12-08-v3.18, renesas-devel-20141212-v3.18 or today's > upstream support multiplatform kernels for sh73a0 ?) My recently posted patch set: [PATCH v2 00/05] ARM: shmobile: sh73a0 and kzm9g Multiplatform revisit > Magnus, you have told me that you've performed tests on Marzen with > CONFIG_PREEMPT_NONE and with both TWD enabled and disabled. If you could > perform the same tests with CONFIG_PREEMPT instead without noticing any > regression I think we can merge your patch. Whatever breakage it has caused in > the past is likely hidden somewhere beyond eyesight. Sorry, but I have not had any time to test this today. What I can tell from yesterday is that legacy Marzen seemed busted and without my patch(es) (including this one) multiplatform Marzen was busted as well. I'll most likely be buried in paper work tomorrow, but I'll see if I can find time dealing with Marzen legacy tomorrow. In general I find legacy upkeep rather time consuming since it seems to degrade rather quickly, so I much rather spend time fixing up multiplatform. >> When the time allows I'd like us to try to fix up these somehow. At >> least I'll give it a go - I guess Armadillo is difficult without any >> board. > > I'd like that very much. Let's get rid of r8a73a4 legacy (Ulrich's patches > should be ready) first, and possible sh73a0 and r8a7740 as well, and then > retest our various timers configurations. We should test both CONFIG_PREEMPT > and CONFIG_PREEMPT none, with all combination of the CMT, TMU, MTU2, TWD and > ARM architected timer enabled. Sure, those are the ones I usually care about. From my side I find the TWD and arch timer upkeep to be heavy enough as-is without considering the preempt case. But you're right - we should cover all of them. Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Laurent, [reduced cc-list] On Wed, Dec 17, 2014 at 1:14 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >> > What are we missing ? >> > >> > - The DIV6 multiparent series has been merged by Mike, and the sh73a0 CCF >> > is nearly ready. >> >> Yep. >> >> > - We need proper BSC support to get LAN working, although it could be >> > worked around temporarily by specifying the BSC clock in the LAN node if >> > I recall correctly. >> >> Working on that. I hope to send out v2 later today... >> >> > - Accelerometer and RTC have no DT bindings, but they should work with the >> > I2C core OF match support. >> >> I have RTC in my DTS, and it works. > > Great. > > I can help with at least some of the remaining pieces if you share your > working branch. I pushed my local working branch to https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=wip Please wear sun glasses, and keep the kbuild test robot away ;-) 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On Wednesday 17 December 2014 14:59:21 Geert Uytterhoeven wrote: > On Wed, Dec 17, 2014 at 1:14 PM, Laurent Pinchart wrote: > >>> What are we missing ? > >>> > >>> - The DIV6 multiparent series has been merged by Mike, and the sh73a0 > >>> CCF is nearly ready. > >> > >> Yep. > >> > >>> - We need proper BSC support to get LAN working, although it could be > >>> worked around temporarily by specifying the BSC clock in the LAN node > >>> if I recall correctly. > >> > >> Working on that. I hope to send out v2 later today... > >> > >>> - Accelerometer and RTC have no DT bindings, but they should work with > >>> the I2C core OF match support. > >> > >> I have RTC in my DTS, and it works. > > > > Great. > > > > I can help with at least some of the remaining pieces if you share your > > working branch. > > I pushed my local working branch to > https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/? > h=wip > > Please wear sun glasses, and keep the kbuild test robot away ;-) I will :-) Thank you. Is there a way to selectively keep kbuild away from branches by the way ? Do avoid duplicating work, what do you plan to work on in the context of multiplatform kzm9g ? Magnus, how much time do you think would be worth spending on DT support for the lcdc drm driver ?
Hi Geert, On Wednesday 17 December 2014 16:43:09 Laurent Pinchart wrote: > On Wednesday 17 December 2014 14:59:21 Geert Uytterhoeven wrote: > > On Wed, Dec 17, 2014 at 1:14 PM, Laurent Pinchart wrote: > > >>> What are we missing ? > > >>> > > >>> - The DIV6 multiparent series has been merged by Mike, and the sh73a0 > > >>> CCF is nearly ready. > > >> > > >> Yep. > > >> > > >>> - We need proper BSC support to get LAN working, although it could be > > >>> worked around temporarily by specifying the BSC clock in the LAN node > > >>> if I recall correctly. > > >> > > >> Working on that. I hope to send out v2 later today... > > >> > > >>> - Accelerometer and RTC have no DT bindings, but they should work with > > >>> the I2C core OF match support. > > >> > > >> I have RTC in my DTS, and it works. I'll test compass, touch screen and accelerometer. > > > Great. > > > > > > I can help with at least some of the remaining pieces if you share your > > > working branch. > > > > I pushed my local working branch to > > https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log > > /? h=wip > > > > Please wear sun glasses, and keep the kbuild test robot away ;-) > > I will :-) Thank you. Is there a way to selectively keep kbuild away from > branches by the way ? > > Do avoid duplicating work, what do you plan to work on in the context of > multiplatform kzm9g ? > > Magnus, how much time do you think would be worth spending on DT support for > the lcdc drm driver ?
Hi Laurent, On Wed, Dec 17, 2014 at 4:34 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >> > >>> - Accelerometer and RTC have no DT bindings, but they should work with >> > >>> the I2C core OF match support. >> > >> >> > >> I have RTC in my DTS, and it works. > > I'll test compass, touch screen and accelerometer. Thanks! Getting the accelerometer to work probably needs some changes to the driver. On both legacy and multi-platform, reading from /dev/input/event1 causes an interrupt storm, which can only be stopped by power-cycling the board (the adxl345 doesn't have a reset line). 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Laurent, On Wed, Dec 17, 2014 at 11:43 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Geert, > > On Wednesday 17 December 2014 14:59:21 Geert Uytterhoeven wrote: >> On Wed, Dec 17, 2014 at 1:14 PM, Laurent Pinchart wrote: >> >>> What are we missing ? >> >>> >> >>> - The DIV6 multiparent series has been merged by Mike, and the sh73a0 >> >>> CCF is nearly ready. >> >> >> >> Yep. >> >> >> >>> - We need proper BSC support to get LAN working, although it could be >> >>> worked around temporarily by specifying the BSC clock in the LAN node >> >>> if I recall correctly. >> >> >> >> Working on that. I hope to send out v2 later today... >> >> >> >>> - Accelerometer and RTC have no DT bindings, but they should work with >> >>> the I2C core OF match support. >> >> >> >> I have RTC in my DTS, and it works. >> > >> > Great. >> > >> > I can help with at least some of the remaining pieces if you share your >> > working branch. >> >> I pushed my local working branch to >> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/? >> h=wip >> >> Please wear sun glasses, and keep the kbuild test robot away ;-) > > I will :-) Thank you. Is there a way to selectively keep kbuild away from > branches by the way ? > > Do avoid duplicating work, what do you plan to work on in the context of > multiplatform kzm9g ? > > Magnus, how much time do you think would be worth spending on DT support for > the lcdc drm driver ? Not much, but perhaps it is good to have a working separate reference implementation if it can be done with little effort. I guess if you can re-use the LCDC driver between sh73a0 and r8a7740 then there may be _some_ point, but unless I'm mistaken the sh73a0 has the LCDC interrupt only routed to INTCS which in turn lacks DT support. Not sure if r8a7740 is any better - at least it has the GIC together with the Cortex-A9. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Magnus, On Thursday 18 December 2014 00:46:59 Magnus Damm wrote: > On Wed, Dec 17, 2014 at 11:43 PM, Laurent Pinchart wrote: > > On Wednesday 17 December 2014 14:59:21 Geert Uytterhoeven wrote: > >> On Wed, Dec 17, 2014 at 1:14 PM, Laurent Pinchart wrote: > >> >>> What are we missing ? > >> >>> > >> >>> - The DIV6 multiparent series has been merged by Mike, and the sh73a0 > >> >>> CCF is nearly ready. > >> >> > >> >> Yep. > >> >> > >> >>> - We need proper BSC support to get LAN working, although it could be > >> >>> worked around temporarily by specifying the BSC clock in the LAN node > >> >>> if I recall correctly. > >> >> > >> >> Working on that. I hope to send out v2 later today... > >> >> > >> >>> - Accelerometer and RTC have no DT bindings, but they should work > >> >>> with the I2C core OF match support. > >> >> > >> >> I have RTC in my DTS, and it works. > >> > > >> > Great. > >> > > >> > I can help with at least some of the remaining pieces if you share your > >> > working branch. > >> > >> I pushed my local working branch to > >> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/lo > >> g/? h=wip > >> > >> Please wear sun glasses, and keep the kbuild test robot away ;-) > > > > I will :-) Thank you. Is there a way to selectively keep kbuild away from > > branches by the way ? > > > > Do avoid duplicating work, what do you plan to work on in the context of > > multiplatform kzm9g ? > > > > Magnus, how much time do you think would be worth spending on DT support > > for the lcdc drm driver ? > > Not much, but perhaps it is good to have a working separate reference > implementation if it can be done with little effort. > > I guess if you can re-use the LCDC driver between sh73a0 and r8a7740 > then there may be _some_ point, The driver should be usable on both platforms, yes. > but unless I'm mistaken the sh73a0 has the LCDC interrupt only routed to > INTCS which in turn lacks DT support. You're correct :-( It shouldn't be difficult to implement a proper INTCS irqchip driver. As usual, it's a matter of time. I'm afraid I won't be able to tackle that in the very near future. > Not sure if r8a7740 is any better - at least it has the GIC together with > the Cortex-A9.
Hi Laurent, On Wed, Dec 17, 2014 at 11:08 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Magnus, you have told me that you've performed tests on Marzen with > CONFIG_PREEMPT_NONE and with both TWD enabled and disabled. If you could > perform the same tests with CONFIG_PREEMPT instead without noticing any > regression I think we can merge your patch. Whatever breakage it has caused in > the past is likely hidden somewhere beyond eyesight. I've now successfully boot tested the different PREEMPT settings on r8a7779 Marzen multiplatform. Everything seems to work as expected. Compared to before I've been a bit more lazy, so I've kept the timer config to default which means TWD and TMU enabled. The kernel tree is renesas-devel-20141218-v3.18 which is v3.18 plus local integration stuff including TWD DT. I've applied this patch too. Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Magnus, On Friday 19 December 2014 09:03:00 Magnus Damm wrote: > On Wed, Dec 17, 2014 at 11:08 AM, Laurent Pinchart wrote: > > Magnus, you have told me that you've performed tests on Marzen with > > CONFIG_PREEMPT_NONE and with both TWD enabled and disabled. If you could > > perform the same tests with CONFIG_PREEMPT instead without noticing any > > regression I think we can merge your patch. Whatever breakage it has > > caused in the past is likely hidden somewhere beyond eyesight. > > I've now successfully boot tested the different PREEMPT settings on > r8a7779 Marzen multiplatform. Everything seems to work as expected. > > Compared to before I've been a bit more lazy, so I've kept the timer > config to default which means TWD and TMU enabled. If your test setup is still around could you quickly test PREEMPT + TMU without TWD ? > The kernel tree is renesas-devel-20141218-v3.18 which is v3.18 plus local > integration stuff including TWD DT. I've applied this patch too.
--- 0001/drivers/clocksource/sh_tmu.c +++ work/drivers/clocksource/sh_tmu.c 2014-12-16 17:49:49.000000000 +0900 @@ -428,7 +428,7 @@ static void sh_tmu_register_clockevent(s ced->features = CLOCK_EVT_FEAT_PERIODIC; ced->features |= CLOCK_EVT_FEAT_ONESHOT; ced->rating = 200; - ced->cpumask = cpumask_of(0); + ced->cpumask = cpu_possible_mask; ced->set_next_event = sh_tmu_clock_event_next; ced->set_mode = sh_tmu_clock_event_mode; ced->suspend = sh_tmu_clock_event_suspend;