On Fri, Jun 10, 2016 at 12:27:16PM -0500, Andy Gross wrote:

On Fri, Jun 10, 2016 at 06:06:56PM +0100, Lorenzo Pieralisi wrote:

quoted

On Fri, Jun 10, 2016 at 11:52:48AM -0500, Andy Gross wrote:

[...]

quoted

quoted

(1) enter_freeze() hooks are not strictly necessary to enable
    suspend-to-idle (they are if we want the tick to be frozen
    on suspend-to-idle, which is different)

I'd think that you'd want the tick frozen.  Even if you are going to
just call the deepest freezable idle state in your freeze_function,
you don't want to keep getting woken up as this costs some power usage

As I said, that's a separate issue from these bindings.

I kind of see that coupled with the determination that a idle state
supports freeze.  Or are you wanting to have something else that
decides whether or not to configure the enter_freeze?

All PSCI based idle state support freeze, as long as most of the
other idle routines for ARM 32-bit, I do not even think we should
bother with defining DT bindings for it.

[...]

quoted

For 64-bit you do not have to have add any facility.

1) we should change core code to make PM_SUSPEND_FREEZE independent
   of suspend_set_ops()

So then, if cpuidle is active and you have idle states supporting
freeze, then you can always implicitly freeze the system.  This would
infer then that the system will always indicate it can do freeze.  I
am good with that.

For now, we can get away with just implementing the changes you are
suggesting.

Cracking.

quoted

2) we should define which idle states are freezable (99% of them are
   minus coupled idle states), through generic bindings

This would be in the form of a DT property?  And given this property
then we'd just assign a enter_freeze() function that calls the enter()
for that state.  Or would we have something else that we need to key
off of to decide to configure the enter_freeze?

See above, I will give it more thought. I take an action to change
core code as per discussion above.

Thanks for raising the point.

Lorenzo