From: Linus Walleij <linus.walleij@linaro.org>
To: Joy Chakraborty <joychakr@google.com>
Cc: andy.shevchenko@gmail.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, manugautam@google.com,
aniketmaurya@google.com
Subject: Re: [RFC PATCH] PM: runtime: Apply pinctrl settings if defined
Date: Thu, 16 Nov 2023 21:00:42 +0100 [thread overview]
Message-ID: <CACRpkdZ+UMOqatH4oOusdaX1ieeH2TtpC7VbX1wf+tzGDSfR3A@mail.gmail.com> (raw)
In-Reply-To: <CAOSNQF3QeFd857RCJE8wfJ=__-K7Bi4vfMeTVP-+O+LJ7y9SmQ@mail.gmail.com>
On Thu, Nov 16, 2023 at 4:34 PM Joy Chakraborty <joychakr@google.com> wrote:
> I tried to place the calls to set the pinctrl states after driver/user
> callback based on my understanding of runtime code so that existing
> users do get a chance to set the state with any special sequence that
> needs to be performed post which doing another call to set the state
> would be ignored in the pinctrl framework.
This makes sense. (And also is in the original commit.)
I think you should actually over-document this by also mentioning
this in the kerneldoc above each of the *_try_* callbacks so
users simply can't miss this point.
> But this only would be possible with the assumption that even in any
> special sequences executed by users they set nothing but "default"
> state in runtime_resume, "idle" state in runtime_idle and "'sleep"
> state in their runtime suspend callbacks.
> And like Andy mentions about "->prepare callback", if there are
> drivers that are setting pinctrl state "default", "sleep" or "idle"
> from any callback but
> ...
> int (*runtime_suspend)(struct device *dev);
> int (*runtime_resume)(struct device *dev);
> int (*runtime_idle)(struct device *dev);
> ...
> it could indeed be a problem.
> I'll dig into users of pinctrl_select_sleep/default/idle and see if
> there are such cases or if it could be done in some other way.
It's worth a check but I doubt much will turn up. The "idle" and
"sleep" states are simply not used much in the kernel.
Your users will likely be the first.
So which hardware target will use this?
It's immensely useful to have a good example to point at:
that device use "defaul", "sleep", "idle" the idiomatic way.
Yours,
Linus Walleij
next prev parent reply other threads:[~2023-11-16 20:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 10:20 [RFC PATCH] PM: runtime: Apply pinctrl settings if defined Joy Chakraborty
2023-11-14 13:01 ` Linus Walleij
2023-11-15 1:51 ` andy.shevchenko
2023-11-16 15:34 ` Joy Chakraborty
2023-11-16 20:00 ` Linus Walleij [this message]
2023-12-01 6:08 ` Joy Chakraborty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACRpkdZ+UMOqatH4oOusdaX1ieeH2TtpC7VbX1wf+tzGDSfR3A@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=andy.shevchenko@gmail.com \
--cc=aniketmaurya@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=joychakr@google.com \
--cc=len.brown@intel.com \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=manugautam@google.com \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).