[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061117143658.GB5158@shaftnet.org>
Date: Fri, 17 Nov 2006 09:36:58 -0500
From: Stuffed Crust <pizza@...ftnet.org>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: linux-fbdev-devel@...ts.sourceforge.net,
Christian Hoffmann <chrmhoffmann@...il.com>,
Andrew Morton <akpm@...l.org>,
Christian Hoffmann <Christian.Hoffmann@...lstreetsystems.com>,
LKML <linux-kernel@...r.kernel.org>, Pavel Machek <pavel@....cz>
Subject: Re: [Linux-fbdev-devel] Fwd: [Suspend-devel] resume not working on acer ferrari 4005 with radeonfb enabled
On Fri, Nov 17, 2006 at 05:17:00PM +1100, Benjamin Herrenschmidt wrote:
> > radeonfb is still using its own code for saving and restoring PCI
> > registers; I'm in the process of fixing it up to use proper PCI
> > subsystem calls. That will hopefully work better.
> >
> > It's possible there's a good reason (other than "nobody's ported it over
> > yet") that the radeonfb driver is doing it manually, but I don't know
> > why that would be the case.
>
> Well, radeonfb has code to bring back some cards from D2 or D3 cold (or
> hard reset). It differenciates those states by checking if the config
> space has been trashed. We should try to find out some better way.
The d2 vs d3 is determined by chipset in advance -- powermacs and some
thinkpads use d2, and everyone else uses d3.
On resume, we check that same flag, and restore differently. We only
checked the config space on D3 resume, and restored everything if the
first byte was trashed..
If I understand what you're saying correctly, if we re-write a valid set
of pci registers, we'll trash the radeon state? Why _wouldn't_ a D3
resume be trashed?
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur. ICQ: 1318344
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists