Re: PCI power management

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

>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.