[PATCH] clockevents: don't suspend/resume if unused

[PATCH] clockevents: don't suspend/resume if unused

[Alexandre Belloni]

There is no point in calling suspend/resume for unused
clockevents as they are already stopped and disabled.

Furthermore, it can take some time to wait for some IPs to stop counting.

Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Reported-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
---
 kernel/time/clockevents.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 55449909f114..0eff982c1c11 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -525,7 +525,7 @@ void clockevents_suspend(void)
 	struct clock_event_device *dev;
 
 	list_for_each_entry_reverse(dev, &clockevent_devices, list)
-		if (dev->suspend)
+		if (dev->suspend && dev->mode != CLOCK_EVT_MODE_UNUSED)
 			dev->suspend(dev);
 }
 
@@ -537,7 +537,7 @@ void clockevents_resume(void)
 	struct clock_event_device *dev;
 
 	list_for_each_entry(dev, &clockevent_devices, list)
-		if (dev->resume)
+		if (dev->resume && dev->mode != CLOCK_EVT_MODE_UNUSED)
 			dev->resume(dev);
 }
 
-- 
2.1.0

[PATCH] clockevents: don't suspend/resume if unused

[Sylvain Rochet]

Hello Alexandre,


On Fri, Jan 16, 2015 at 10:05:51AM +0100, Alexandre Belloni wrote:
> There is no point in calling suspend/resume for unused
> clockevents as they are already stopped and disabled.
> 
> Furthermore, it can take some time to wait for some IPs to stop counting.
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Reported-by: Sylvain Rochet <sylvain.rochet@finsecur.com>

Indeed, this is way better from what I did.


> +		if (dev->suspend && dev->mode != CLOCK_EVT_MODE_UNUSED)

I wonder if we should use > CLOCK_EVT_MODE_SHUTDOWN
(or CLOCK_EVT_MODE_UNUSED || CLOCK_EVT_MODE_SHUTDOWN) instead of 
!CLOCK_EVT_MODE_UNUSED.


Sylvain

[PATCH] clockevents: don't suspend/resume if unused

[Russell King - ARM Linux]

On Fri, Jan 16, 2015 at 10:20:14AM +0100, Sylvain Rochet wrote:
> Hello Alexandre,
> 
> 
> On Fri, Jan 16, 2015 at 10:05:51AM +0100, Alexandre Belloni wrote:
> > There is no point in calling suspend/resume for unused
> > clockevents as they are already stopped and disabled.
> > 
> > Furthermore, it can take some time to wait for some IPs to stop counting.
> > 
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > Reported-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
> 
> Indeed, this is way better from what I did.
> 
> 
> > +		if (dev->suspend && dev->mode != CLOCK_EVT_MODE_UNUSED)
> 
> I wonder if we should use > CLOCK_EVT_MODE_SHUTDOWN
> (or CLOCK_EVT_MODE_UNUSED || CLOCK_EVT_MODE_SHUTDOWN) instead of 
> !CLOCK_EVT_MODE_UNUSED.

Definitely - consider the effect of the original patch set on a clock
source which is being used, has PM support, but does not have an
->enable callback.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] clockevents: don't suspend/resume if unused

[Russell King - ARM Linux]

On Fri, Jan 16, 2015 at 11:17:06AM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 16, 2015 at 10:20:14AM +0100, Sylvain Rochet wrote:
> > Hello Alexandre,
> > 
> > 
> > On Fri, Jan 16, 2015 at 10:05:51AM +0100, Alexandre Belloni wrote:
> > > There is no point in calling suspend/resume for unused
> > > clockevents as they are already stopped and disabled.
> > > 
> > > Furthermore, it can take some time to wait for some IPs to stop counting.
> > > 
> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > > Reported-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
> > 
> > Indeed, this is way better from what I did.
> > 
> > 
> > > +		if (dev->suspend && dev->mode != CLOCK_EVT_MODE_UNUSED)
> > 
> > I wonder if we should use > CLOCK_EVT_MODE_SHUTDOWN
> > (or CLOCK_EVT_MODE_UNUSED || CLOCK_EVT_MODE_SHUTDOWN) instead of 
> > !CLOCK_EVT_MODE_UNUSED.
> 
> Definitely - consider the effect of the original patch set on a clock
> source which is being used, has PM support, but does not have an
> ->enable callback.

Damn it, that comment should've been on the clocksource patches...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] clockevents: don't suspend/resume if unused

[Alexandre Belloni]

Hi,

On 16/01/2015 at 10:20:14 +0100, Sylvain Rochet wrote :
> > +		if (dev->suspend && dev->mode != CLOCK_EVT_MODE_UNUSED)
> 
> I wonder if we should use > CLOCK_EVT_MODE_SHUTDOWN
> (or CLOCK_EVT_MODE_UNUSED || CLOCK_EVT_MODE_SHUTDOWN) instead of 
> !CLOCK_EVT_MODE_UNUSED.
> 

I'll let Thomas or Daniel decide :) But I'm open to that.

>-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH] clockevents: don't suspend/resume if unused

[Alexandre Belloni]

Ping?

On 16/01/2015 at 17:59:14 +0100, Alexandre Belloni wrote :
> Hi,
> 
> On 16/01/2015 at 10:20:14 +0100, Sylvain Rochet wrote :
> > > +		if (dev->suspend && dev->mode != CLOCK_EVT_MODE_UNUSED)
> > 
> > I wonder if we should use > CLOCK_EVT_MODE_SHUTDOWN
> > (or CLOCK_EVT_MODE_UNUSED || CLOCK_EVT_MODE_SHUTDOWN) instead of 
> > !CLOCK_EVT_MODE_UNUSED.
> > 
> 
> I'll let Thomas or Daniel decide :) But I'm open to that.
> 
> >-- 
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH] clockevents: don't suspend/resume if unused

[Alexandre Belloni]

Thomas, Daniel,

Any opinion on that?
Maybe this patch could go in as is?


On 16/01/2015 at 17:59:14 +0100, Alexandre Belloni wrote :
> Hi,
> 
> On 16/01/2015 at 10:20:14 +0100, Sylvain Rochet wrote :
> > > +		if (dev->suspend && dev->mode != CLOCK_EVT_MODE_UNUSED)
> > 
> > I wonder if we should use > CLOCK_EVT_MODE_SHUTDOWN
> > (or CLOCK_EVT_MODE_UNUSED || CLOCK_EVT_MODE_SHUTDOWN) instead of 
> > !CLOCK_EVT_MODE_UNUSED.
> > 
> 
> I'll let Thomas or Daniel decide :) But I'm open to that.
> 
> >-- 
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] clockevents: don't suspend/resume if unused

[Thomas Gleixner]

On Fri, 16 Jan 2015, Alexandre Belloni wrote:
> Hi,
> 
> On 16/01/2015 at 10:20:14 +0100, Sylvain Rochet wrote :
> > > +		if (dev->suspend && dev->mode != CLOCK_EVT_MODE_UNUSED)
> > 
> > I wonder if we should use > CLOCK_EVT_MODE_SHUTDOWN
> > (or CLOCK_EVT_MODE_UNUSED || CLOCK_EVT_MODE_SHUTDOWN) instead of 
> > !CLOCK_EVT_MODE_UNUSED.
> > 
> 
> I'll let Thomas or Daniel decide :) But I'm open to that.

I'm unsure about the shutdown part. shutdown can be an intermediate
state where its not a given, that the clocks are disabled. I pick it
up as is.

Thanks,

	tglx

[PATCH] clockevents: don't suspend/resume if unused

[Thomas Gleixner]

On Fri, 16 Jan 2015, Alexandre Belloni wrote:

> There is no point in calling suspend/resume for unused
> clockevents as they are already stopped and disabled.
> 
> Furthermore, it can take some time to wait for some IPs to stop counting.

While I agree with the patch itself, I really can't understand that
last sentence.

If stuff is stopped and disabled, what takes time to stop counting?
 
Thanks,

	tglx

[PATCH] clockevents: don't suspend/resume if unused

[Sylvain Rochet]

Hello Thomas,

On Mon, May 25, 2015 at 08:48:06PM +0200, Thomas Gleixner wrote:
> On Fri, 16 Jan 2015, Alexandre Belloni wrote:
> 
> > There is no point in calling suspend/resume for unused
> > clockevents as they are already stopped and disabled.
> > 
> > Furthermore, it can take some time to wait for some IPs to stop counting.
> 
> While I agree with the patch itself, I really can't understand that
> last sentence.
> 
> If stuff is stopped and disabled, what takes time to stop counting?

Atmel PIT is a bit weird, writing to AT91_PIT_MR restarts the timer even 
if you just want to stop it and then the only way to stop the timer is 
to wait for a complete timer cycle.

The problem is not when suspending, restarting the timer just before 
suspending is not such a problem because is will eventually stop at 
some point in the future.

However it can takes a very long time if the system switchs to slow 
clock, therefore when resuming the timer is still running and we have to 
wait for the PIT to stop counting because we re-enabled it for one cycle 
when suspending, which is weird, it adds about ~128ms resumt time for 
Atmel SoC.

The previous proposed patch was to do nothing in PIT suspend and resume 
callbacks if PIT is unused[1], which fixed the PIT problem, but we 
decided to put the condition in the upper level because other drivers 
might be interested too.

Sylvain

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311496.html

[PATCH] clockevents: don't suspend/resume if unused

[Thomas Gleixner]

On Mon, 25 May 2015, Sylvain Rochet wrote:
> On Mon, May 25, 2015 at 08:48:06PM +0200, Thomas Gleixner wrote:
> > On Fri, 16 Jan 2015, Alexandre Belloni wrote:
> > 
> > > There is no point in calling suspend/resume for unused
> > > clockevents as they are already stopped and disabled.
> > > 
> > > Furthermore, it can take some time to wait for some IPs to stop counting.
> > 
> > While I agree with the patch itself, I really can't understand that
> > last sentence.
> > 
> > If stuff is stopped and disabled, what takes time to stop counting?
> 
> Atmel PIT is a bit weird, writing to AT91_PIT_MR restarts the timer even 
> if you just want to stop it and then the only way to stop the timer is 
> to wait for a complete timer cycle.
> 
> The problem is not when suspending, restarting the timer just before 
> suspending is not such a problem because is will eventually stop at 
> some point in the future.
> 
> However it can takes a very long time if the system switchs to slow 
> clock, therefore when resuming the timer is still running and we have to 
> wait for the PIT to stop counting because we re-enabled it for one cycle 
> when suspending, which is weird, it adds about ~128ms resumt time for 
> Atmel SoC.
 
That's a reasonable explanation.

While timer IPs seem to be designed by janitors in general, this one
has an extraordinary level of stupidity.

Thanks,

	tglx

[PATCH] clockevents: don't suspend/resume if unused

[Sylvain Rochet]

Hello Thomas,

On Mon, May 25, 2015 at 10:11:15PM +0200, Thomas Gleixner wrote:
>  
> That's a reasonable explanation.
> 
> While timer IPs seem to be designed by janitors in general, this one
> has an extraordinary level of stupidity.

Yes, that's quite a stupid design, however I wasn't totally right from 
looking at the datasheet again, the timer does not restart when asked to 
stop while it is already stopped, my bad. But it doesn't change 
anything, the issue is still that this timer cannot be stopped right 
now, you have to ask for it to stop then wait the overflow.

1. suspend PIT[1] -> ask to stop

2. suspended, timer is still counting and will eventually reaches the 
overflow condition then stop, that's probably not going to happen if 
system switched to slow clock

3. resume PIT[2] -> wait for PIT to stop counting (up to 126ms) because 
we need it to be synched back if we want to use it at some point in the 
future, that's also the only way to clear pending interrupts.

Sylvain


[1] http://lxr.free-electrons.com/source/drivers/clocksource/timer-atmel-pit.c#L122
[2] http://lxr.free-electrons.com/source/drivers/clocksource/timer-atmel-pit.c#L130