On 03/18/2016 04:56 PM, Jon Hunter wrote:

On 18/03/16 14:40, Jon Hunter wrote:

quoted

On 18/03/16 14:23, Grygorii Strashko wrote:

quoted

On 03/18/2016 02:27 PM, Jon Hunter wrote:

quoted

On 18/03/16 11:11, Grygorii Strashko wrote:

[snip]

quoted

quoted

oh :( That will require updating of all drivers (and if it will be taken into account that
wakeup can be configured from sysfs + devm_ - it will be painful).

Will it? I know that there are a few gpio chips that have some hacked
ways to get around the PM issue, but I wonder how many drivers this
really impacts. What sysfs entries are you referring too?

echo enabled > /sys/devices/platform/44000000.ocp/48020000.serial/tty/ttyS2/power/wakeup

Thinking about this some more, yes I guess it would impact all drivers
that use a gpio but don't use it for a wake-up. I could see that could
be a few drivers indeed.

yep. I've just tested it
- gpio was requested through sysfs and configured as IRQ
- do suspend

the same is if GPIO is requested as IRQ only and not configured as wakeup source 

[  319.669760] PM: late suspend of devices complete after 0.213 msecs
[  319.671195] irq 191 has no wakeup set and has not been freed!
[  319.673453] PM: noirq suspend of devices complete after 2.258 msecs

this is very minimal configuration - the regular one is at ~30-50 devices
most of them will use IRQ and only ~10% are used as wakeup sources.

quoted

quoted

quoted

but it would avoid every irqchip having to
handle this themselves and having a custom handler.

irqchip like TI OMAP GPIO will need custom handling any way even if it's not expected
to be Powered off during Suspend or deep CPUIdle states, simply because its state
in suspend is unknown - PM state managed automatically (and depends on many factors)
and wakeup can be handled by special HW in case if GPIO bank was really switched off.

quoted

quoted

I propose do not touch common/generic suspend code now. Any common code can be always
refactored later once there will be real drivers updated to use irqchip RPM
and which will support Suspend.

If this is strongly opposed, I would concede to making this a pr_debug()
as I think it could be useful.

Probably yes, because most of the drivers now and IRQ PM core are not ready
for this approach.

May be this calls for a new flag to not WARN if non-wakeup IRQs are not
freed when entering suspend.

Flag or pr_debug()?

Honestly, I don't know how to proceed - minimum is pr_debug.
My personal opinion is still the same - don't touch suspend core code now, within this series.


-- 
regards,
-grygorii