From: Rajesh Shah <rajesh.shah@intel.com>
To: Li Shaohua <shaohua.li@intel.com>
Cc: ACPI-DEV <acpi-devel@lists.sourceforge.net>,
lkml <linux-kernel@vger.kernel.org>,
Len Brown <len.brown@intel.com>,
greg@kroah.com, Pavel Machek <pavel@suse.cz>
Subject: Re: [Proposal]Another way to save/restore PCI config space for suspend/resume
Date: Wed, 27 Oct 2004 13:14:27 -0700 [thread overview]
Message-ID: <20041027131427.C2382@unix-os.sc.intel.com> (raw)
In-Reply-To: <1098766257.8433.7.camel@sli10-desk.sh.intel.com>; from shaohua.li@intel.com on Tue, Oct 26, 2004 at 12:50:57PM +0800
On Tue, Oct 26, 2004 at 12:50:57PM +0800, Li Shaohua wrote:
> Hi,
> We suffer from PCI config space issue for a long time, which causes many
> system can't correctly resume. Current Linux mechanism isn't sufficient.
> Here is a another idea:
> Record all PCI writes in Linux kernel, and redo all the write after
> resume in order. The idea assumes Firmware will restore all PCI config
> space to the boot time state, which is true at least for IA32.
>
A large percentage of them may be irrelevant with respect to
suspend/resume (e.g. pci device tree and resource scan...). Apart
from the performance problems, generic code doing device specific
config accesses may have correctness problems. For example, you
will not be able to capture/replay config cycles or other device
specific initialization (e.g. using memory mapped IO) that BIOS may
have done before boot. This may be required for correct access to
device specific areas. The same thing is true about device specific
config accesses that may have been done by the corresponding
driver after boot. Without device specific knowledge, we may see
unpredictable behavior and non-repeatable and hard to debug problems.
I don't see how generic code can do the right thing for device
specific accesses. Devices like p2p bridges that have standard
definitions can be handled separately.
Rajesh
prev parent reply other threads:[~2004-10-27 20:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-26 4:50 [Proposal]Another way to save/restore PCI config space for suspend/resume Li Shaohua
2004-10-26 5:11 ` [ACPI] " Andi Kleen
2004-10-26 6:11 ` Len Brown
2004-10-26 8:42 ` Arjan van de Ven
2004-10-26 9:06 ` Karol Kozimor
2004-10-26 9:57 ` Matthew Garrett
2004-10-26 9:09 ` Li Shaohua
2004-10-26 9:21 ` Pavel Machek
2004-10-27 0:50 ` [ACPI] " Li Shaohua
2004-10-27 1:32 ` [ACPI] " Hiroshi 2 Itoh
2004-10-27 1:55 ` Li Shaohua
2004-10-27 2:26 ` Hiroshi 2 Itoh
2004-10-27 20:14 ` Rajesh Shah [this message]
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=20041027131427.C2382@unix-os.sc.intel.com \
--to=rajesh.shah@intel.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=greg@kroah.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=shaohua.li@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