linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: Subtle semantic issue with sleep callbacks in drivers
@ 2003-04-14 21:09 Grover, Andrew
  2003-04-16 18:39 ` Patrick Mochel
  0 siblings, 1 reply; 30+ messages in thread
From: Grover, Andrew @ 2003-04-14 21:09 UTC (permalink / raw)
  To: Alan Cox
  Cc: Benjamin Herrenschmidt, Patrick Mochel, Linux Kernel Mailing List

> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] 
> On Llu, 2003-04-14 at 20:07, Grover, Andrew wrote:
> > All I am saying is that on Windows, the driver gets no help 
> from the 
> > BIOS, APM, or ACPI, but yet it restores the video to full working 
> > condition. I understand that this sounds complicated, but 
> since there 
> > is an implementation that already does this then I think we have to 
> > assume it's possible. :) Perhaps we should start with 
> older, simpler 
> > gfx hw, or maybe POST the bios, but only as an interim 
> solution until 
> > gfx drivers get better in this area.
> 
> You might be suprised how much BIOS help they get. Im not at 
> liberty to discuss details but at least two vendors jump into 
> bios space in their ACPI recovery routines.

Which strikes me as kind of silly since guess who called the ACPI resume
vector - the BIOS, so why didn't it do whatever stuff then? :) Anyways
it's not really relevant. The BIOS will never know about add-in cards,
and my contention is that even these can be woken up properly w/o bios
repost (after surmounting technical and potential lack-of-documentation
hurdles, which is why I'd think we would start with an old, ubiquitous,
thouroughly documented video card as our first guinea pig. Matrox
Millennium 2, perhaps?)

I'm not at the point where I can devote time to this yet, so please take
all this with a grain of salt.

Regards -- Andy

^ permalink raw reply	[flat|nested] 30+ messages in thread
* RE: Subtle semantic issue with sleep callbacks in drivers
@ 2003-04-14 19:07 Grover, Andrew
  2003-04-14 19:18 ` Benjamin Herrenschmidt
                   ` (2 more replies)
  0 siblings, 3 replies; 30+ messages in thread
From: Grover, Andrew @ 2003-04-14 19:07 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: Patrick Mochel, linux-kernel mailing list

> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org] 
> On Mon, 2003-04-14 at 19:09, Grover, Andrew wrote:
> > Ben obviously PPC is ahead of the pack on this stuff 
> (congrats) but I 
> > did just want to put forward the idea that when we're all done with 
> > this stuff on all archs, we will hopefully not be regularly 
> re-POSTing 
> > the video bios.
> 
> But how ? let's make clear what we call POST first ...
> 
> If the card is powered off, it must be POSTed to be brought 
> back to life. Either we do it by running the BIOS code 
> (probably what you are talking about and should be 
> deprecated), or the driver "knows" how to restore the chip 
> from power off. I don't know if APM/ACPI provides other ways, 
> I suspect the APM BIOS will re-POST the card by itself or 
> else, things wouldn't work today. I don't know about ACPI.
> 
> What I mean here is that none of our drivers know how to bring 
> back a chip as complicated as a radeon or a nvidia up from 
> power off, this requires intimate knowledge of the chip 
> internals, the way it's wired on a given board, etc...

All I am saying is that on Windows, the driver gets no help from the
BIOS, APM, or ACPI, but yet it restores the video to full working
condition. I understand that this sounds complicated, but since there is
an implementation that already does this then I think we have to assume
it's possible. :) Perhaps we should start with older, simpler gfx hw, or
maybe POST the bios, but only as an interim solution until gfx drivers
get better in this area.

Regards -- Andy

^ permalink raw reply	[flat|nested] 30+ messages in thread
* RE: Subtle semantic issue with sleep callbacks in drivers
@ 2003-04-14 17:09 Grover, Andrew
  2003-04-14 17:40 ` Benjamin Herrenschmidt
  2003-04-23 15:29 ` Pavel Machek
  0 siblings, 2 replies; 30+ messages in thread
From: Grover, Andrew @ 2003-04-14 17:09 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Patrick Mochel; +Cc: linux-kernel mailing list

> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org] 
> - On non-PPC machines, the slot will eventually go to D3, but 
> the APM BIOS or ACPI will be able to re-POST the card 
> properly on wakeup, so the driver only needs to restore the 
> current display mode, at least I guess so since I don't know 
> much about x86's. Similar will happen once I have an OF 
> emulator ready on PPC to re-POST some cards, thus changing 
> the previous example into this one. In this case, the driver 
> can put the chip to D3 and can _accept_ the sleep request 
> because it's explicitely told by the system (how ?) that the 
> card will be re-POSTED prior to the
> resume() callback.

Topic drift...

After asking around internally, it sounds like we should not be doing a
video re-POST on wakeup. Windows only used to in order to workaround
buggy video drivers, according to what I've heard.

Ben obviously PPC is ahead of the pack on this stuff (congrats) but I
did just want to put forward the idea that when we're all done with this
stuff on all archs, we will hopefully not be regularly re-POSTing the
video bios.

Regards -- Andy

^ permalink raw reply	[flat|nested] 30+ messages in thread
* Subtle semantic issue with sleep callbacks in drivers
@ 2003-04-14 10:00 Benjamin Herrenschmidt
  2003-04-14 10:11 ` Benjamin Herrenschmidt
                   ` (2 more replies)
  0 siblings, 3 replies; 30+ messages in thread
From: Benjamin Herrenschmidt @ 2003-04-14 10:00 UTC (permalink / raw)
  To: Patrick Mochel; +Cc: linux-kernel mailing list

Hi Patrick !

While implementing power management of PowerBooks based on
the new model (while porting my drivers at the same time), I
found a couple of problems that could be solved by better defining
the values of the "state" parameter passed to drivers. Or maybe it
is already, in which case, let me know :)

Basically, the driver need to know what kind of support is provided
by the motherboard for wake up and what will happen to the chip. The
typical example is the radeon driver which shows all cases:

- On mac laptops, the AGP slot is unclocked. That means the driver
has to go to D2 (for which I have full code from ATI). That is
independant from other things on the motherboard, some things are
powerd off, but not the AGP slot, so I need a way to affect the
"state" parameter on a per-slot basis.

- On non-laptops, the AGP slot is powered off. So I beleive I
basically need to tell the driver to go to D3 (or basically prepare
to re-POST the card on wakeup).
However, we can't do that. We don't have enough infos from ATI to
be able to do it right now, which is why I don't support suspend-to-RAM
on non-laptops pmacs. So here, the driver should fail the suspend
request if it's told, via the "state" parameter that the chip will be
powered off by the system

- On non-PPC machines, the slot will eventually go to D3, but the APM
BIOS or ACPI will be able to re-POST the card properly on wakeup, so the
driver only needs to restore the current display mode, at least I guess
so since I don't know much about x86's. Similar will happen once I have
an OF emulator ready on PPC to re-POST some cards, thus changing the
previous example into this one. In this case, the driver can put the
chip to D3 and can _accept_ the sleep request because it's explicitely
told by the system (how ?) that the card will be re-POSTED prior to the
resume() callback.

- On any machine, with suspend to disk, the slot is powered off (along
with the entire host machine). But the machine will be rebooted and the
device put back to "idle" state some way by the loader kernel, so this
ends up a bit like the above case.


So basically, the "state" parameter should encore not only what state
we want to go to, but rather, what will happen to the slot:

- Nothing (it's entirely up to the driver to do it's own power
management, that happens for some devices inside Apple ASIC), though in
this case at least, those driver have control over the chip power, reset
lines, etc...
- Slot will be unclocked (it's up to the driver, it the chip supports
static mode, to go to D2 or D3 if the driver can deal with it, though
the system will do nothing to help the driver)
- Slot will be powered off. This case should be broken up (via an
additional flag passed to the driver ?) into 1) the system _will_
re-POST the card before resume (BIOS/ACPI support, swsusp) or the
system will NOT re-POST the card, the driver shall fail the sleep
request if it can't do it by itself.
 - Embedded people may have even more weird cases ?

Any comments ?

I also noticed the IDE PM code is hopeless, I'll try to hack something
that works at least as good than what I had in the pmac 2.4 code, and
the fbdev PM code is almost unexisting (I need at least a way for the
driver to tell the PM layer not to mess with the framebuffer once the
driver is asleep). I'll hack something as well.

Regards
Ben.
 

^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2003-05-05 21:40 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-14 21:09 Subtle semantic issue with sleep callbacks in drivers Grover, Andrew
2003-04-16 18:39 ` Patrick Mochel
2003-04-16 19:36   ` Benjamin Herrenschmidt
2003-04-17 13:35   ` Alan Cox
2003-04-17 14:48     ` Jeff Garzik
2003-04-17 15:09       ` John Bradford
2003-04-17 15:09         ` Jeff Garzik
2003-04-17 15:47           ` John Bradford
2003-04-17 15:56             ` Jeff Garzik
2003-04-17 16:24               ` Alan Cox
2003-04-18  7:37             ` Greg KH
2003-04-18  7:51               ` John Bradford
2003-04-18  9:10               ` Russell King
2003-04-18 11:18                 ` Alan Cox
2003-04-18 11:30               ` Alan Cox
2003-04-29  8:28         ` Pavel Machek
2003-04-17 14:59     ` John Bradford
2003-04-17 15:04       ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2003-04-14 19:07 Grover, Andrew
2003-04-14 19:18 ` Benjamin Herrenschmidt
2003-04-14 19:56 ` Alan Cox
2003-04-23 15:34 ` Pavel Machek
2003-04-14 17:09 Grover, Andrew
2003-04-14 17:40 ` Benjamin Herrenschmidt
2003-04-23 15:29 ` Pavel Machek
2003-04-14 10:00 Benjamin Herrenschmidt
2003-04-14 10:11 ` Benjamin Herrenschmidt
2003-04-16 18:31 ` Patrick Mochel
2003-04-16 19:29   ` Benjamin Herrenschmidt
2003-04-23 15:32 ` Pavel Machek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).