public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


      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