From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Chris Chiu <chiu@endlessm.com>
Cc: Daniel Drake <drake@endlessm.com>,
Andy Shevchenko <andriy.shevchenko@intel.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Linus Walleij <linus.walleij@linaro.org>,
"open list:PIN CONTROL SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux Upstreaming Team <linux@endlessm.com>
Subject: Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume
Date: Mon, 1 Apr 2019 10:49:53 +0300 [thread overview]
Message-ID: <20190401074953.GQ3622@lahna.fi.intel.com> (raw)
In-Reply-To: <CAB4CAwcQTH5BiDDbzfFXTDDuYQ_fuDd_1tKkecf6vwygGQmn5w@mail.gmail.com>
On Fri, Mar 29, 2019 at 04:38:20PM +0800, Chris Chiu wrote:
> On Thu, Mar 28, 2019 at 8:34 PM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > On Thu, Mar 28, 2019 at 08:19:59PM +0800, Chris Chiu wrote:
> > > On Thu, Mar 28, 2019 at 5:38 PM Daniel Drake <drake@endlessm.com> wrote:
> > > >
> > > > On Thu, Mar 28, 2019 at 5:17 PM Andy Shevchenko
> > > > <andriy.shevchenko@intel.com> wrote:
> > > > > Hmm... Can you confirm that laptop you declared as a fixed case and the
> > > > > mentioned here is the same one?
> > > >
> > > > They are definitely not the same exact unit - originally we had a
> > > > pre-production sample, and now we briefly diagnosed a real production
> > > > unit that was sold to a customer. There could be subtle motherboard
> > > > variations as you mention.
> > > >
> > > > > If it's the case, I recommend to ping Asus again and make them check and fix.
> > > >
> > > > We'll keep an eye open for any opportunities to go deeper here.
> > > > However further investigation on both our side and theirs is blocked
> > > > by not having any of the affected hardware (since the models are now
> > > > so old), so I'm not very optimistic that we'll be able to make
> > > > progress there.
> > > >
> > > > > Meanwhile, Mika's proposal sounds feasible and not so intrusive. We may
> > > > > implement this later on.
> > > >
> > > > Chris will work on implementing this for your consideration.
> > > >
> > > > Thanks for the quick feedback!
> > > > Daniel
> > >
> > > What if I modify the patch as follows? It doesn't save HOSTSW_OWN register.
> > > It just toggles the bit specifically for the IRQ GPIO pin after resume when DMI
> > > matches.
> >
> > I don't really like having quirks like this if we can avoid it and in
> > this case I think we can. Just always save HOSTSW_OWN and then restore
> > it if there is a GPIO requested and the value differs (and log a warning
> > or something like that).
>
> You mean save the content of hostsw_own register on padgroup based ex.
> communities[i].hostown[gpp] = readl(base + gpp * 4);
>
> And then check the hostown bit for the GPIO requested pin in
> intel_pinctrl_resume(),
> differs the hostsw_own bit on pin base (like padcfg), then restore the
> hostsw_own
> value of the padgroug which the GPIO pin is belonging to?
Yes.
> I think what you mean should be a much more straightforward solution
> for this. Could
> you implement this in your way and we can try to help verification. Thanks.
Sure I can but it probably does not happen until end of the week because
I'm currently busy with something else.
next prev parent reply other threads:[~2019-04-01 7:50 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-14 10:41 [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume Chris Chiu
[not found] ` <20171115080446.GY17200@lahna.fi.intel.com>
2017-11-15 8:08 ` Chris Chiu
2017-11-15 10:13 ` Mika Westerberg
2017-11-15 10:19 ` Chris Chiu
2017-11-16 12:44 ` Mika Westerberg
2017-11-16 13:27 ` Chris Chiu
2017-11-17 6:49 ` Mika Westerberg
2017-11-17 8:11 ` Chris Chiu
2017-11-21 10:52 ` Mika Westerberg
2017-11-21 11:54 ` Chris Chiu
2017-11-21 12:04 ` Mika Westerberg
2017-11-23 12:24 ` Chris Chiu
2017-11-23 12:43 ` Mika Westerberg
2019-03-27 8:22 ` Daniel Drake
2019-03-27 17:29 ` Mika Westerberg
2019-03-28 8:28 ` Mika Westerberg
2019-03-28 9:17 ` Andy Shevchenko
2019-03-28 9:38 ` Daniel Drake
2019-03-28 12:19 ` Chris Chiu
2019-03-28 12:34 ` Mika Westerberg
2019-03-29 8:38 ` Chris Chiu
2019-04-01 7:49 ` Mika Westerberg [this message]
2019-04-01 10:41 ` Chris Chiu
2019-04-01 12:22 ` Andy Shevchenko
2019-04-02 6:16 ` Chris Chiu
2019-04-02 11:58 ` Andy Shevchenko
2019-04-03 7:06 ` Chris Chiu
2019-04-03 13:06 ` Andy Shevchenko
2019-04-04 13:06 ` Chris Chiu
2019-04-04 13:59 ` Andy Shevchenko
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=20190401074953.GQ3622@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=andriy.shevchenko@intel.com \
--cc=chiu@endlessm.com \
--cc=drake@endlessm.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@endlessm.com \
/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