public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jesse.barnes@intel.com>
To: Dave Jones <davej@redhat.com>
Cc: 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: Tue, 12 Jun 2007 10:24:50 -0700	[thread overview]
Message-ID: <200706121024.50717.jesse.barnes@intel.com> (raw)
In-Reply-To: <20070612035914.GA23169@redhat.com>

On Monday, June 11, 2007 8:59:14 Dave Jones wrote:
> 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.

I agree.  I think saving the registers explicitly rather than as a block 
is the best long term direction.  That way we can carefully evaluate 
which ones actually need to be saved/restored, and it what order.  
Doing it as a block hides that and makes it seem chipset independent 
when it really might not be...

Jesse

  reply	other threads:[~2007-06-12 17:25 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
2007-06-12 17:24       ` Jesse Barnes [this message]
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=200706121024.50717.jesse.barnes@intel.com \
    --to=jesse.barnes@intel.com \
    --cc=andi@rhlx01.fht-esslingen.de \
    --cc=davej@redhat.com \
    --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