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
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
> - There need to be some arch "hooks" in this mecanism. Some machines
> have the ability (from the arch specific code, by tweaking ASIC bits)
> to remove clock and/or power from selected devices. That mean power
> management can be done even with devices not supporting PCI PM provided
> that th
> > - 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
>> - 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_gen
> - 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
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
http://lists.sourceforge.net/lists/listinfo/linux-pm-devel
Not very much used yet, but I,
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
http://lists.sourceforge.net/lists/listinfo/linux-pm-devel
Not very much used yet, but I,
19 matches
Mail list logo
