13.07.2019 8:31, 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. > Okay!