mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Mike Turquette <mturquette@linaro.org>,
	Jin Yao <yao.jin@linux.intel.com>,
	Li Aubrey <aubrey.li@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 2/4] ACPI / LPSS: custom power domain for LPSS
Date: Wed, 21 May 2014 13:01:31 +0200	[thread overview]
Message-ID: <4546817.Xm9e491t74@vostro.rjw.lan> (raw)
In-Reply-To: <20140521100511.GA29349@xps8300>

On Wednesday, May 21, 2014 01:05:11 PM Heikki Krogerus wrote:
> Hi Rafael,
> 
> On Tue, May 20, 2014 at 11:33:09PM +0200, Rafael J. Wysocki wrote:
> > > +#ifdef CONFIG_PM
> > 
> > It would be good to add a kerneldoc explaining what's being saved here and why.
> 
> OK.
> 
> > > +static void acpi_lpss_save_ctx(struct device *dev)
> > > +{
> > > +	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> > > +	int i;
> > > +
> > > +	for (i = 0; i < LPSS_PRV_REG_COUNT; i++) {
> > > +		pdata->prv_reg_ctx[i] = __lpss_reg_read(pdata, i * sizeof(u32));
> > > +		dev_dbg(dev, "saving 0x%08x from LPSS reg at offset 0x%02x\n",
> > > +			pdata->prv_reg_ctx[i], (unsigned int)(i * sizeof(u32)));
> > > +	}
> > > +}
> > > +
> > > +static void acpi_lpss_restore_ctx(struct device *dev)
> > > +{
> > > +	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> > > +	int i;
> > > +
> > > +	/* PCI spec expects 10ms delay when resuming from D3 to D0 */
> > > +	msleep(10);
> > 
> > Two questions here.
> > 
> > First, is the 10 ms sleep really necessary?  I'd expect the AML to take care of
> > such delays (this is not a PCI device formally).
> 
> Unfortunately that is not the case. There is nothing in the AML for
> this. Mika, correct me if I'm wrong.
> 
> > And because this is not a PCI device formally, why is the comment talking about
> > the PCI spec?  Why is PCI relevant in any way here?
> 
> Under the hood the devices are still PCI devices, even if they
> formally aren't. Maybe I should point that out in the comment..
> 
> We put the sleep there because without it there was no guarantee if
> the device was properly resumed by the time the drivers resume hooks
> were called. The symptom in case of a failure was simply that the
> registers could not be written, which leads into timeouts at least in
> case of the I2C and UART and making them unusable until the next
> suspend followed by resume.

OK, so the msleep() is functionally necessary.  Instead of talking about the
PCI in the comment, which will make a casual reader think "What the heck?",
please say something like "the delay is necessary for the subsequent register
writes to succeed on <example system>".

Rafael


  reply	other threads:[~2014-05-21 10:44 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15 13:40 [PATCHv2 0/4] ACPI / LPSS: Solution for two issues seen on Asus T100 Heikki Krogerus
2014-05-15 13:40 ` [PATCHv2 1/4] ACPI / PM: Export rest of the subsys functions Heikki Krogerus
2014-05-15 13:40 ` [PATCHv2 2/4] ACPI / LPSS: custom power domain for LPSS Heikki Krogerus
2014-05-20 21:33   ` Rafael J. Wysocki
2014-05-21 10:05     ` Heikki Krogerus
2014-05-21 11:01       ` Rafael J. Wysocki [this message]
2014-05-21 10:52         ` Heikki Krogerus
2014-05-21 23:28           ` Rafael J. Wysocki
2014-05-23 12:30             ` Heikki Krogerus
2014-05-23 13:10               ` Rafael J. Wysocki
2014-05-23 13:02                 ` Heikki Krogerus
2014-05-23 13:15                   ` [PATCHv3 " Heikki Krogerus
2014-05-26 13:03                     ` Rafael J. Wysocki
2014-05-26 13:42                       ` Heikki Krogerus
2014-05-26 21:30                         ` Rafael J. Wysocki
2014-05-15 13:40 ` [PATCHv2 3/4] clk: new basic clk type for fractional divider Heikki Krogerus
2014-05-15 16:53   ` Mike Turquette
2014-05-16 22:38     ` Rafael J. Wysocki
     [not found]       ` <20140516230905.9521.88763@quantum>
2014-05-17  0:15         ` Rafael J. Wysocki
     [not found]           ` <20140517013403.9521.86191@quantum>
2014-05-19  0:15             ` Rafael J. Wysocki
2014-05-15 13:40 ` [PATCHv2 4/4] ACPI / LPSS: support for fractional divider clock Heikki Krogerus
2014-05-19 11:42   ` [PATCHv3 " Heikki Krogerus
2014-05-15 14:35 ` [PATCHv2 0/4] ACPI / LPSS: Solution for two issues seen on Asus T100 Li, Aubrey
2014-05-15 14:53   ` Andy Shevchenko
2014-05-15 15:59     ` Li, Aubrey
2014-05-15 16:11       ` Mika Westerberg
2014-05-15 23:29         ` Li, Aubrey
2014-05-16  7:04           ` Andy Shevchenko
2014-05-16 13:37             ` Li, Aubrey
2014-05-16 14:45               ` Andy Shevchenko
2014-05-20 11:17                 ` Li, Aubrey

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=4546817.Xm9e491t74@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=aubrey.li@linux.intel.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mturquette@linaro.org \
    --cc=yao.jin@linux.intel.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

all inboxes | Powered by JetHome®