Date: Thu, 27 Jan 2011 10:21:58 +0100 From: Philip Soeberg <philip-freebsd1@soeberg.net> To: freebsd-hackers@freebsd.org Subject: Re: pci_suspend/pci_resume of custom pcie board Message-ID: <4D413936.8070301@soeberg.net> In-Reply-To: <201101251355.53944.jhb@freebsd.org> References: <4D3EE287.3010203@soeberg.net> <201101251355.53944.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25-01-2011 19:55, John Baldwin wrote: > Use this: > > pci_cfg_save(dev, dinfo, 0); > pci_set_powerstate(dev, PCI_POWERSTATE_D3); > > /* do stuff */ > > /* Will set state to D0. */ > pci_cfg_restore(dev, dinfo); > > We probably should create some wrapper routines (pci_save_state() and > pci_restore_state() would be fine) that hide the 'dinfo' detail as that isn't > something device drivers should have to know. Excellent, Thank you.. I must have been half asleep as couldn't for the love of god get that config space restore to work when I tried it yesterday, but now all is peachy. Must have forgotten a crucial step in that.. 3 step list you provided.. sighh.. :) No need to wrap dinfo.. It's actually quite nice to have the cache at hand -if- the device should "choose" to change a parameter, say its device id. I'd rather we'd focus on extending the PCI_POWERSTATE_D3 to include a specific Hot version. D3 can mean both Cold and Hot, and there's a distinct difference between the two (whether to remove power from the device or not).. Not that I know of any PM implementation who actually differentiates as of yet, but I wouldn't be surprised if all this green energy wave thing we see in the server segment push towards powering off a slot once its device has entered d3cold. Anyway, Many thanks for your help. /Phil
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D413936.8070301>