I noticed that the PCI power management document file had fallen a
little behind the times, so I fixed it up.
jon
Update the documentation of PCI power management functions.
Signed-off-by: Jonathan Corbet <[EMAIL PROTECTED]>
diff --git a/Documentation/power/pci.txt b/Documentation
Return early from pci_set_power_state() if hardware does not support
power management. This way, we do not generate noise in the logs.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 206c834..6158497 100644
--- a/drivers/pci/pci.c
+++ b/d
I've rewritten the PCI Power Management documentation that I was going to
submit to Linus. I figured I would submit it here to get some proactive
feedback on it.
My thought was to create a Documentation/power/ directory with various
documents describing the way that the kernel implements
Linus Torvalds wrote:
>
> In article <[EMAIL PROTECTED]>,
> David T Eger <[EMAIL PROTECTED]> wrote:
> >
> >So I'm writing some code for a PCI card that is a framebuffer device, and
> >happily filling in the functions for the probe() and remove() functions
> >when I read documentation (Documentat
In article <[EMAIL PROTECTED]>,
David T Eger <[EMAIL PROTECTED]> wrote:
>
>So I'm writing some code for a PCI card that is a framebuffer device, and
>happily filling in the functions for the probe() and remove() functions
>when I read documentation (Documentation/pci.txt) which mentions that
>rem
> if someone yanks the card, how is it going to deliver an interrupt to
> the CPU?
It can happen actually. There is also a window where you can disable an IRQ
on a card and then take an IRQ. The ne2k driver has to jump through a couple
of hoops because of this
-
To unsubscribe from this list: sen
> when I read documentation (Documentation/pci.txt) which mentions that
> remove() can be called from interrupt context.
This I believe is in fact a documentation error
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
David T Eger wrote:
> when I read documentation (Documentation/pci.txt) which mentions that
> remove() can be called from interrupt context.
ignore that. You can sleep in remove, and it will not be called from
interrupt context.
> Reading code in my sister frame buffer devices, I see that
> un
So I'm writing some code for a PCI card that is a framebuffer device, and
happily filling in the functions for the probe() and remove() functions
when I read documentation (Documentation/pci.txt) which mentions that
remove() can be called from interrupt context.
Now in order to properly tear dow
On Fri, Apr 20, 2001 at 02:56:15PM +0200, Benjamin Herrenschmidt wrote:
> 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
>
>> 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 suc
Benjamin Herrenschmidt wrote:
> >When a device comes out of D3[hot], the equivalent of a soft reset is
> >performed. From D3[cold], PCI RST# is asserted, and the device must be
> >completely reinitialized.
>
> Some devices (bad bad HW designers ;) just can't do it themselves. The
> Rage M3 requir
>All devices should handle having power removed from them. And, all of the
>drivers should as well, since that is the only way we're going to get
>power management out of legacy devices and other things on the board. This
>involves saving the current context on suspend, and reinitializing the
>dev
down function. For example, some
> drivers may improve power management by powering down the device when
> it's /dev node is not opened (or when the device have been idle for some
> time). However, those power up/down functions have to be arch-dependant,
> you can't rely on t
> > - On SMP, we need some way to stop other CPUs in the scheduler
> > while running the last round of sleep (putting devices to sleep) at least
> > until all IO layers in Linux can properly handle blocking of IO queues
> > while the device sleeps.
>
> I think either Rusty or Anton wrote code t
>null = 'do absolutely nothing'
>generic = 'do D3 as per the specification'
>
>The idea being the PM layer would go around calling
>
> dev->power_off(dev);
>
>as a default notifier for PCI devices.
Ok, I see. I didn't understand that the functions you were talking about
would be defaults to
Benjamin Herrenschmidt wrote:
> - On SMP, we need some way to stop other CPUs in the scheduler
> while running the last round of sleep (putting devices to sleep) at least
> until all IO layers in Linux can properly handle blocking of IO queues
> while the device sleeps.
I think either Rusty or A
_NOCLOCK = 0x0008
PCI_POWER_MASK_NOPOWER = 0x0010
The driver sets the mask to whatever state it supports getting the card
from. We can #define a PCI_POWER_MASK_STD (that would be a D1+D2+D3) for
"generic" drivers that don't really know anything but to follow the HW
PCI power
> - Some devices just can't be brought back to life from D3 state without
> a PCI reset (ATI Rage M3 for example) and that require some arch specific
> support (when it's possible at all).
Putting on a driver author hat what I want is
pci_power_on_generic
pci_power_off_generic
>On Thu, Apr 19, 2001 at 11:19:31AM +0100, Benjamin Herrenschmidt wrote:
>> Hi ! Glad to see things moving around Power Management ;)
>>
>> >This was originally a private reply to Patrick Mochel, but the e-mail
>> >kept getting longer and longer :)
>>
>> Note: we have setup a list for PM issues
On Thu, Apr 19, 2001 at 11:19:31AM +0100, Benjamin Herrenschmidt wrote:
> Hi ! Glad to see things moving around Power Management ;)
>
> >This was originally a private reply to Patrick Mochel, but the e-mail
> >kept getting longer and longer :)
>
> Note: we have setup a list for PM issues
>
> ht
Right. And we need a equivalent power down function. For example, some
drivers may improve power management by powering down the device when
it's /dev node is not opened (or when the device have been idle for some
time). However, those power up/down functions have to be arch-depen
Right. And we need a equivalent power down function. For example, some
drivers may improve power management by powering down the device when
it's /dev node is not opened (or when the device have been idle for some
time). However, those power up/down functions have to be arch-depen
This was originally a private reply to Patrick Mochel, but the e-mail
kept getting longer and longer :)
The current state of PCI PM is this:
pci_enable_device (1) enables IO and mem decoding, (2) assigns/routes
the PCI IRQ, and (3) brings the device to D0 using pci_set_power_state.
Linus belie
24 matches
Mail list logo
