[PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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>
---

 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;

[PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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>
---

 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;

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Daniel Lezcano]

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;
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Daniel Lezcano]

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;
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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;

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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;

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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;

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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;

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Daniel Lezcano]

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;
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Daniel Lezcano]

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;
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Daniel Lezcano]

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
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Daniel Lezcano]

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
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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 ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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 ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Geert Uytterhoeven]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Magnus Damm]

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

Re: [PATCH] clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart