[PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Wed, Oct 29, 2014 at 04:51:09PM +0100, Johan Hovold wrote:
> On Wed, Oct 29, 2014 at 08:25:02AM -0700, Guenter Roeck wrote:
> > On Wed, Oct 29, 2014 at 02:22:44PM +0100, Johan Hovold wrote:
> > > On Wed, Oct 29, 2014 at 01:10:20PM +0000, Russell King - ARM Linux wrote:
> > > > On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
> > > > > On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
> > > > > > And how is that different from having a set of power-off handlers, and
> > > > > > reporting when each individual one fails?  Don't you want to know if
> > > > > > your primary high priority reboot handler fails, just as much as you
> > > > > > want to know if your final last-resort power-off handler fails?
> > > > > 
> > > > > Good point. Failed power-off should probably be logged by the power-off
> > > > > call chain implementation (which seems to makes notifier chains a bad
> > > > > fit).
> > > > > 
> > > > > And what about any power-off latencies? Should this always be dealt with
> > > > > in the power-off handler?
> > > > > 
> > > > > Again, if it's predictable and high, as in the OMAP RTC case, it should
> > > > > go in the handler. But what if it's just normal bus latencies
> > > > > (peripheral busses, i2c, or whatever people may come up with)?
> > > > > 
> > > > > Should there always be a short delay before calling the next handler?
> > > > 
> > > > If the handler has determined that it has failed, then why delay before
> > > > trying the next handler?  At the point it has decided it has failed,
> > > > surely that's after it has waited sufficient time to determine that
> > > > failure?
> > > 
> > > The current handlers we have are not expecting any other handler to be
> > > run after they return. My question was whether all these handlers should
> > > get a short mdelay added to them (e.g. to compensate for bus latencies)
> > 
> > Some of them do add a delay.
> 
> Yes, but not all.
> 
> > > or if this could be done in the power-off handler (e.g. before printing
> > > the error message).
> > > 
> > That might make sense, but it would have to be configurable, since the delay
> > is platform specific and power-off handler does not know how long to wait
> > (the longest delay I have seen is 10 seconds).
> 
> We've already concluded in this thread that such delays must be encoded
> in the actual handler (even if it's an argument to the power-off call
> chain code). The only exception should be generic handlers such as
> gpio-poweroff, which may need to define different delays depending on
> board. This could of course just be an argument of the corresponding DT
> node.

There probably should be a generic device-tree property for this, even
if some delays would be device specific (e.g. the two second delay for
omap rtc).

But on top of that, external latencies would be quite board specific.
The PMIC on the Beaglebone black adds a 50ms deglitch time, for
instance.

> My question above was if it was reasonable to add some generic short
> delay after calling each power-off handler to handle short power-off
> latencies (e.g. bus latencies) so that not every handler needs an
> explicit delay.

I just added a 500ms margin to the OMAP rtc power-off handler. That
should be more than enough, and perhaps something like that could be a
default in the power-off call chain. Consider that arch-arm has a 1s
grace period before reporting failed reboot already today.

Johan