On 25 April 2017 at 13:36, Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > On Tue, 2017-04-25 at 13:12 +0200, Ulf Hansson wrote: >> On 25 April 2017 at 13:08, Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxx >> m> wrote: >> > On 04/25/2017 12:24 PM, Ulf Hansson wrote: > >> > > To me, the proper solution is to use the >> > > pm_runtime_force_suspend|resume() helpers to deal with system >> > > suspend/resume. However I understand that the behavior of the ACPI >> > > PM >> > > domain currently prevents us from doing this. That said, perhaps >> > > we >> > > should instead try to make the ACPI PM domain to better >> > > collaborate >> > > with drivers using pm_runtime_force_suspend|resume()? I have been >> > > investigating that and started to cook some patches, although I >> > > have >> > > not yet been able to post something. If you think it could make >> > > sense, >> > > I can pick it up. >> > > >> > >> > That's a good idea. I didn't think about it at all. >> >> Okay, thanks! I will continue to look into this and try to submit >> something within a reasonable time frame, keep you posted. > > But please keep in mind that ACPI PM domain for BayTrail / CherryTrail > is used by several IPs including most nasty GPDMA case. If something > breaks that it would be show stopper. Thanks for pointing this out. I think I have an overall understanding of the complexity. This driver is a cross SoC driver and not only should we expect the ACPI PM domain to be used but also the generic PM domain for ARM SoCs. To me, this makes it even more interesting and a very good candidate to explore the usage of pm_runtime_force_suspend|resume(). :-) Nevertheless, I will rely and appreciate help in testing and of course also reviewing. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
