mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alexey Starikovskiy <astarikovskiy@suse.de>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	Maxim Levitsky <maximlevitsky@gmail.com>,
	Alan Jenkins <sourcejedi.lkml@googlemail.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Len Brown <lenb@kernel.org>,
	pm list <linux-pm@lists.linux-foundation.org>,
	Thomas Renninger <trenn@suse.de>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][RFT][PATCH] ACPI: Protection from suspending in the middle of EC transaction
Date: Mon, 1 Feb 2010 23:42:49 +0100	[thread overview]
Message-ID: <201002012342.50074.rjw@sisk.pl> (raw)
In-Reply-To: <4B66AB7F.7050908@suse.de>

On Monday 01 February 2010, Alexey Starikovskiy wrote:
> Henrique de Moraes Holschuh пишет:
> > On Sun, 31 Jan 2010, Maxim Levitsky wrote:
> >> Unfortunately, this patch even causes regressions on my notebook (it
> >> survive 63 hibernate cycles), but now I battery driver reports 'battery
> >> absent', backlight driver reports 0 brightness, but reload helped.
> > 
> > ...
> > 
> >> I think that not only _PTS ans _WAK are problematic. What about other
> >> ACPI drivers that start accessing the EC before it is resumed?
> >> I think that these cause the problems I observe.
> > 
> > ACPI drivers might access the EC (even indirectly, through the DSDT).  And
> > platform drivers do often access the EC both at suspend and resume time.
> Actually, only SBS and thinkpad-acpi access EC directly. All others go through
> DSDT for access. Still, stopping EC in .suspend is too early, IMHO...

That's very likely the case, although that's kind of the latest we can do that
without major modifications.

Is there a possibility to have more than one EC in a system in practice?

> > This needs some sort of strong ordering, the EC must suspend last, and
> > resume first (as seen by any ACPI and ACPI-aware drivers such as libata,
> > some platform drivers, etc).  If EC interrupts are a problem, maybe it can
> > be kicked to poll mode for the suspend/resume transition?
> It's this way already for about a year now... The problem is that EC driver might be 
> stopped in middle of the transaction, thus leaving EC in unknown state for BIOS or 
> switch-over kernel.

Exactly.

In theory I can try to disable EC transactions from the ACPI platform
suspend/resume callbacks, but then there still is a problem with the global
lock, since we shouldn't try to acquire it after disabling device interrupts,
because an SCI is waited for in case we don't acquire it immediately.

So, perhaps instead we should disable the GPEs and call _PTS before the late
suspend phase (and analogously, execute _WAK after the early resume phase)
and disable the EC transacations right after that?

This leaves the problem with PCI devices that may require ACPI support during
late suspend/early resume, but well.

Rafael

  reply	other threads:[~2010-02-01 22:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-30 23:29 Rafael J. Wysocki
2010-01-31 14:11 ` Alan Jenkins
2010-01-31 17:09   ` Maxim Levitsky
2010-02-01  9:46     ` Henrique de Moraes Holschuh
2010-02-01 10:22       ` Alexey Starikovskiy
2010-02-01 22:42         ` Rafael J. Wysocki [this message]
2010-02-02 20:23           ` [PATCH] ACPI / EC: Remover race between EC driver and suspend process (was: Re: [RFC][RFT][PATCH] ACPI: Protection from suspending in the middle of EC transaction) Rafael J. Wysocki
2010-01-31 20:41 ` [RFC][RFT][PATCH] ACPI: Protection from suspending in the middle of EC transaction Maxim Levitsky
2010-01-31 21:09   ` Rafael J. Wysocki
2010-01-31 22:31     ` Rafael J. Wysocki
2010-02-03  0:32 ` [PATCH] ACPI / EC: Remove race between EC driver and suspend process (rev. 2) (was: Re: [RFC][RFT][PATCH] ACPI: Protection from suspending in the middle of EC transaction) Rafael J. Wysocki
2010-02-04  0:33   ` [PATCH] ACPI / EC: Remove race between EC driver and suspend process (rev. 3) Rafael J. Wysocki

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=201002012342.50074.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=astarikovskiy@suse.de \
    --cc=hmh@hmh.eng.br \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=maximlevitsky@gmail.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=sourcejedi.lkml@googlemail.com \
    --cc=trenn@suse.de \
    /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

Powered by JetHome