On 16/06/2020 19:56, Grygorii Strashko wrote:

On 16/06/2020 18:30, Tony Lindgren wrote:

quoted

* Tomi Valkeinen [off-list ref] [200616 13:02]:

quoted

On 11/06/2020 17:00, Grygorii Strashko wrote:

quoted

I think, suspend might be fixed if all devices, which are now child of ti-sysc, will do
pm_runtime_force_xxx() calls at noirq suspend stage by adding:

      SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
                        pm_runtime_force_resume)

Am I missing smth?

Isn't this almost exactly the same my patch does? I just used suspend_late
and resume_early. Is noirq phase better than late & early?

Well up to you as far as I'm concerned. The noirq phase comes with serious
limitations, for let's say i2c bus usage if needed. Probably also harder
to debug for suspend and resume.

Unfortunately, you can't use PM runtime force API at .suspend() stage as pm_runtime_get will still 
work and
there is no sync between suspend and pm_runtime.
The PM runtime force API can be used only during late/noirq as at this time pm_runtime is disabled.

Yes, but which one... Do you know what the diff is with late/noirq from driver's perspective? I 
guess noirq is atomic context, late is nto?

Dispc's suspend uses synchronize_irq(), so that rules out noirq. Although the call is not needed if 
using noirq version, so that could also be managed with small change. But I wonder if there's any 
benefit in using noirq versus late.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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