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.
