>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/
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:31 EST