On Wed, May 20, 2020 at 05:19:27AM +0300, Dmitry Osipenko wrote:
> 19.05.2020 19:08, Thierry Reding пишет:
> > On Sat, May 16, 2020 at 10:45:32AM +0300, Dmitry Osipenko wrote:
> >> 15.05.2020 17:39, Thierry Reding пишет:
> >>> Hi,
> >>>
> >>> The following changes since commit 0e698dfa282211e414076f9dc7e83c1c288314fd:
> >>>
> >>>   Linux 5.7-rc4 (2020-05-03 14:56:04 -0700)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/for-5.8-i2c
> >>>
> >>> for you to fetch changes up to c73178b93754edd8449dccd3faf05baafd4d3f0e:
> >>>
> >>>   i2c: tegra: Add support for the VI I2C on Tegra210 (2020-05-12 22:47:52 +0200)
> >>>
> >>> Thanks,
> >>> Thierry
> >>>
> >>> ----------------------------------------------------------------
> >>> i2c: tegra: Changes for v5.8-rc1
> >>>
> >>> This includes a few improvements to make the Tegra I2C controller behave
> >>> properly on suspend/resume, does a bit of cleanup and adds support for
> >>> the VI-variant of the I2C controller that is used primarily for video
> >>> capture purposes.
> >>>
> >>> ----------------------------------------------------------------
> >>> Dmitry Osipenko (2):
> >>>       i2c: tegra: Better handle case where CPU0 is busy for a long time
> >>>       i2c: tegra: Synchronize DMA before termination
> >>>
> >>> Thierry Reding (5):
> >>>       Revert "i2c: tegra: Fix suspending in active runtime PM state"
> >>
> >>>       i2c: tegra: Restore pinmux on system resume
> >>
> >> In general this series is good to me, although I have some concerns
> >> about this patch. Could you please answer the review comments?
> > 
> > Sorry, those had been burried under too much email. I've answered your
> > questions now.
> 
> Hello Thierry,
> 
> Thank you for the answers, I'd also want to see the answer to the
> question about how RPM works, i.e. why I2C is RPM-resumed during
> system's suspend in some cases and not the others.

I don't think I've seen a question regarding that, so let me answer
here: the way I understand how this works is that for each device the PM
core will grab a runtime PM reference during the suspend/resume
transition, which is done as a way of preventing any of the resumed
devices from unexpectedly going to runtime suspend.

This code is in drivers/base/power/main.c, device_prepare(). Note that
this will only increment the runtime PM usage counter (and therefore
block the device from entering runtime suspend) but it won't resume the
device if it is already suspended.

So far any devices that are already runtime suspended, there isn't
really anything we have to do during suspend. For those who are not yet
suspended, we need to force them into suspend so that their clocks are
disabled and the pinmux state set properly (to "idle").

On resume we first need to runtime resume the device undconditionally so
that context can be restored. Runtime resume will take care of enabling
the clock and setting the pinmux state to "default". Then we restore the
context and if the device had been runtime suspended, we manually call
the runtime suspend callback again so that the state matches what the PM
core thinks it is. However, if the device had not been runtime suspended
during system suspend, then we must not manually put it back into
suspend because it would no longer match the PM core's state.

Does that answer your question?

Thierry