Re: [PATCH V5 02/18] pinctrl: tegra: Add suspend and resume support

[Sowjanya Komatineni]

On 7/4/19 3:40 AM, Dmitry Osipenko wrote:
> 04.07.2019 10:31, Linus Walleij ÐÐÑÐÑ:
> > On Sat, Jun 29, 2019 at 5:58 PM Dmitry Osipenko <digetx@xxxxxxxxx> wrote:
> >
> > > Oh, also what about GPIO-pinctrl suspend resume ordering .. is it okay that pinctrl
> > > will be resumed after GPIO? Shouldn't a proper pin-muxing be selected at first?
> > Thierry sent some initial patches about this I think. We need to use
> > device links for this to work properly so he adds support for
> > linking the pinctrl and GPIO devices through the ranges.
> >
> > For links between pin control handles and their consumers, see also:
> > 036f394dd77f pinctrl: Enable device link creation for pin control
> > c6045b4e3cad pinctrl: stmfx: enable links creations
> > 489b64d66325 pinctrl: stm32: Add links to consumers
> >
> > I am using STM32 as guinea pig for this, consider adding links also
> > from the Tegra pinctrl. I might simply make these pinctrl consumer
> > to producer links default because I think it makes a lot sense.
> IIUC, currently the plan is to resume pinctrl *after* GPIO for Tegra210 [1]. But this
> contradicts to what was traditionally done for older Tegras where pinctrl was always
> resumed first and apparently it won't work well for the GPIO ranges as well. I think this
> and the other patchsets related to suspend-resume still need some more thought.
>
> [1] https://patchwork.kernel.org/patch/11012077/

Park bit was introduced from Tegra210 onwards and during suspend/resume, 
requirement of gpio restore prior to pinctrl restore is not required for 
prior Tegra210.

Also currently pinctrl suspend/resume implementation for prior Tegra210 
is not yet upstreamed but having gpio restore prior to pinmux during 
suspend/resume should not cause any issue for prior tegra's as well as 
gpio resume restores pins back to same gpio config as they were during 
suspend entry.