Hello Tony,
On 02/12/2016 07:40 PM, Tony Lindgren wrote:
* Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx> [160212 14:29]:
On 02/12/2016 07:13 PM, Tony Lindgren wrote:
Hmm yeah I wonder if this canned solution helps here too:
1. Check if the driver(s) are using pm_runtime_use_autosuspend()
By driver do you mean the OMAP GPIO driver or the tvp5150 I2C driver?
The latter does not have runtime PM support.
Sounds like OMAP GPIO then.
Ok.
2. If so, you must use pm_runtime_dont_use_autosuspend() before
pm_runtime_put_sync() to make sure that pm_runtime_put_sync()
works.
3. Or you can use pm_runtime_put_sync_suspend() instead of
pm_runtime_put_sync() for sections of code where the clocks
need to be stopped.
I can check if the OMAP GPIO is following these and give a try but
don't have access to the board right now so I'll do it on Monday.
It does not seem to be using pm_runtime_autosuspend(). Did you
try reverting commit de85b9d57ab ("PM / runtime: Re-init runtime
PM states at probe error and driver unbind") and see if that
helps?
Yes, that's the first thing I tried when I noticed your patch:
("i2c: omap: Fix PM regression with deferred probe for
pm_runtime_reinit")
But neither reverting commit de85b9d57ab nor your fix made a
difference.
If it does, then sounds like we may have some other regression
as well.
It seems that is not related but I hope that given you were
looking at the runtime PM core lately, maybe you can figure
out what we are missing.
I'm far from being familiar with the runtime PM framework
but I've looked and can't figure out why Wolfram's commit
make this driver to fail and reverting his commit make its
work again.
Regards,
Tony
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
