lkml.org 
[lkml]   [2001]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: PCI power management
Date
>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 directly in the pci_dev structure.

>And in the case of the cards like that you would need a custom mask. So you'd
>do
> pci_set_power_handler(dev, atyfb_power_on, atyfb_power_off)
>
>to get a custom function. For most authors however they can call the power
>handler setup just using prerolled functions that do the right thing and know
>about any architecture horrors they dont.

Right. However, rare are the drivers that don't need at least to know
that a power management sequence is going on. All bus mastering drivers,
at least, must stop bus mastering (and clearing the bit in the command
register is not enough on a bunch of them). Most drivers have to cleanly
stop ongoing operations, refuse (or block) requests while the driver is
sleeping, etc... and finally configure things back once waking up. I
don't see much cases where a simple "default" function would work.

My current scheme on powerbook don't do half of that... it still sorta
works since I manage to stop all scheduling and shut things down in the
proper order, but it's neither a clean nor a safe way to do things.

>I'd rather
>
> pci_dev->powerstate
>
>or similar as a set of flags in the device.

Ok, agree with that one.

I sill consider, however, that the current suspend/resume callbacks in
the pci_dev structure are not the best way to do things. I would have
really prefered that each pci_dev embed a pm notifier structure. In some
cases, we want to pass more than simple suspend/resume messages (suspend
request, suspend now, suspend cancel, and resume are the 4 messages I use
on powerbooks).

Also, this can be generalized to other type of drivers (USB, IEEE1394,
..), eventually passing bus-specific messages

Ben.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:17    [from the cache]
©2003-2011 Jasper Spaans