public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: LKML <linux-kernel@vger.kernel.org>,
	andi@rhlx01.fht-esslingen.de, Keith Packard <keithp@keithp.com>
Subject: Re: [RFC][AGPGART]intel-agp: save whole config space in suspend/resume
Date: Mon, 11 Jun 2007 23:59:14 -0400	[thread overview]
Message-ID: <20070612035914.GA23169@redhat.com> (raw)
In-Reply-To: <20070612033424.GA30200@zhen-devel.sh.intel.com>

On Tue, Jun 12, 2007 at 11:34:25AM +0800, Wang Zhenyu wrote:

 > I understand. Before James reported his problem on i915, I have thought
 > the basic restore on that chip should already be enough, but he proved I was
 > wrong and I'm not sure if this also happens on other i915 board with different
 > BIOS. 
 > 
 > And with my patch it has already removed the restore cases for 440BX like type,
 > coz it's gmch_chip_id == 0 and intel_private.pcidev is NULL, so it won't save
 > extra space on those chips.

The 440BX was one example, for all we know there are similar ordering
issues with other chipsets.  We hit this problem with the code that
restores the first 64 bytes first of all. Then we found out we had
to restore them in reverse order to be safe.  We were able to do
this generically, because those bytes are standardised across devices.

The upper config space isn't standardised, so we have to obey the
per-device rules as to what order we read/write things.
Writing back an "enable" bit somewhere before we've written back
addresses in later registers for example may result in really
bizarre things happening.  These are the kind of bugs that aren't
obvious, and turn out to be "that weird reboot that happens
every 3rd tuesday" six months after we've merged the changes
and everyones forgotten all about the potential problems.

The AGP code has had more than its fair share of really nasty
bugs like this to track down, so I'm strongly opposed to introducing
hacks that may trip us up later.

Whilst I'm not a huge fan of the 815 patch in -mm as it stands,
I think it's a better direction to go in to have per-chipset
save/restore routines.

	Dave

-- 
http://www.codemonkey.org.uk

  reply	other threads:[~2007-06-12  3:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-12  1:54 [RFC][AGPGART]intel-agp: save whole config space in suspend/resume Wang Zhenyu
2007-06-12  2:23 ` Dave Jones
2007-06-12  3:34   ` Wang Zhenyu
2007-06-12  3:59     ` Dave Jones [this message]
2007-06-12 17:24       ` Jesse Barnes
2007-06-12  9:14 ` Matthew Garrett

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=20070612035914.GA23169@redhat.com \
    --to=davej@redhat.com \
    --cc=andi@rhlx01.fht-esslingen.de \
    --cc=keithp@keithp.com \
    --cc=linux-kernel@vger.kernel.org \
    /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