public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jeff Garzik <jgarzik@mandrakesoft.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Patrick Mochel <mochel@transmeta.com>,
	<linux-power@phobos.fachschaften.tu-muenchen.de>
Subject: Re: PCI power management
Date: Fri, 20 Apr 2001 14:56:15 +0200	[thread overview]
Message-ID: <20010420125615.23599@mailhost.mipsys.com> (raw)
In-Reply-To: <3AE02E45.57D7BA9D@mandrakesoft.com>
In-Reply-To: <3AE02E45.57D7BA9D@mandrakesoft.com>

>> Some devices (bad bad HW designers ;) just can't do it themselves. The
>> Rage M3 requires the host to assert PCI RST#, and some motherboards
>> provide no documented facility for that (it might be possible with Apple
>> ASICs for example, it's just not documented).
>
>Why should we support such a non-spec device?  Tell ATI to fix their
>hardware, and tell users (a) not to use the hardware, or (b) use the
>hardware with the knowledge that you are screwed when it comes to Power
>Management.
>
>Unless there are more cases like this, this should not factor at all
>into the modifications to the PCI and PM code...

Well, I can tell all PowerBook and iBook users to forget about sleep...

Also, that would not be the first time we have to deal with poorly
documented hardware. I don't think we should refuse to handle any
hardware that is out of spec... it would be like saying Linux doesn't
support any x86 with a broken BIOS...

It's not so complicated to have the minimum flexibility for the driver
to tell it's maximum supported power level, and I don't see why it would
be a problem to use D2 instead of D3 when we don't support D3 for a given
device (either because the HW is broken, undocumented, or because our
driver just don't know how to bring back the chip to life).

If the motherboard _requires_ it (because it will cut power from the chip),
the we can refuse to enter sleep when one driver can't do it (instead of
letting the user crash the box badly).

In any case, I beleive you are focusing on a point of detail. All
I'm asking for (in this specific case) is a simple mask of flags set
by the driver to tell what it can handle. It's also useful for
devices that don't support PM on machines whose motherboard provide
facility to turn OFF power on selected cards. It would allow us to
turn off cards for drivers that can handle recovering. 

Also, I don't think the problem of powering back up the chip and
re-initing it from scratch is specific to those ATI chips. Look at
XFree, it has to run a BIOS emulator to soft boot video chips. On
PCs, I beleive you have the BIOS that re-init them when waking up
from an APM or ACPI suspend. On non-PCs when suspend is not handled
by the firmware but directly by the kernel, that's not the case.

Ben.




  reply	other threads:[~2001-04-20 12:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.10.10104181150530.7690-100000@nobelium.transmeta.com>
2001-04-19  8:25 ` PCI power management Jeff Garzik
2001-04-19 10:08   ` Benjamin Herrenschmidt
2001-04-19 10:38     ` CaT
2001-04-19 12:10       ` Benjamin Herrenschmidt
2001-04-19 12:57     ` Alan Cox
2001-04-19 13:14       ` Benjamin Herrenschmidt
2001-04-19 13:33         ` Alan Cox
2001-04-19 13:43           ` Benjamin Herrenschmidt
2001-04-20  0:05     ` Patrick Mochel
2001-04-20 12:06       ` Benjamin Herrenschmidt
2001-04-20 12:40         ` Jeff Garzik
2001-04-20 12:56           ` Benjamin Herrenschmidt [this message]
2001-04-21  9:09             ` Russell King
2001-04-19 10:18   ` Benjamin Herrenschmidt
2001-04-19 13:24     ` Jeff Garzik
2001-04-20  0:11       ` [Linux-pm-devel] " Patrick Mochel
2001-04-19 23:03   ` Patrick Mochel
2004-08-02 21:33 pci " Erik Rigtorp
2004-08-02 23:45 ` Brian Gerst

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=20010420125615.23599@mailhost.mipsys.com \
    --to=benh@kernel.crashing.org \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-power@phobos.fachschaften.tu-muenchen.de \
    --cc=mochel@transmeta.com \
    /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