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
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/power/pci.txt
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
+++
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
+++
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 power
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
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
> 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:
> 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
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
remove()
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 (Documentation/pci.txt)
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 power
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
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: send
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
>
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
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
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
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
>
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
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
>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
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
device,
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 requires the
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
anagement 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 the PCI power management to be the only PM scheme.
Possibly a better term i
> > - 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
>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
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
8
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 management cap
> - 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
>
>
ample, 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 the PCI power management to be the only P
ample, 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 the PCI power management to be the only P
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
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
for some
time). However, those power up/down functions have to be arch-dependant,
you can't rely on the PCI power management to be the only PM scheme.
2) AFAICT, it is safe to turn off a PCI device's bus-mastering bit and
take the device to D3, if it exports the PCI PM capability. My
previous
for some
time). However, those power up/down functions have to be arch-dependant,
you can't rely on the PCI power management to be the only PM scheme.
2) AFAICT, it is safe to turn off a PCI device's bus-mastering bit and
take the device to D3, if it exports the PCI PM capability. My
previous
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
- 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
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 management capabilities.
This function would be routed to an arch function, that will in t
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
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 put
- 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 to enable
ight. 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-dependant,
you can't
48 matches
Mail list logo
