All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.