Oliver Endriss wrote: > Marko Ristola wrote: > >> I did for the Mantis branch a working solution for mem and disk cases. >> I haven't tested standby yet, but I think that it should be easy to >> extend if it doesn't work yet. >> >> I used linux/Documentation/power/*.txt while >> trying to understand how to implement suspend/resume. >> >> On my opinion, the easiest way to make standby+mem+disk work, is to >> implement suspend() so, that you >> assume that you might lose the power if the source transition is D0. >> If the source transition state is another one, you just turn some power >> off, but don't touch >> the saved state that resume() needs. >> (My implementation doesn't handle source transition at all now, because >> of my limited time.) >> >> Then you must implement resume() so, that it assumes, that you are >> recovering from a power loss. >> You might try to optimize resume() by checking from the device or from >> some previous kernel state, >> whether the device has actually lost it's power or not. >> >> My Mantis suspend/resume altered too many files, and thus it isn't final >> yet, >> but it is a working although not perfect version. >> >> In Linux code, there is a more simple PCI suspend/resume implementation >> in linux/drivers/pci/pci-driver.c. >> >> pci_device_suspend(): this does a very simple and basic PCI suspend >> operation. >> pci_default_resume(): this does a very simple and basic PCI resume >> operation. >> So I will try to learn from them some day to lessen changes in mantis_pci.c. >> >> My personal idea for the responsibilities is that: >> pci_save_state() and pci_restore_state() and other function calls found >> in pci-driver.c >> will handle saving and restoring PCI state, although I absolute must >> copy them into mantis_pci.c. >> Then on resume, I have to restore non-pci states, I mean those that >> aren't restored by >> pci_restore_state(), pci_set_master() and such. In Mantis there is >> according to Manu at least >> tuner power setting and retuning. I don't know the working and optimally >> small solution yet that >> Manu requires: there is still testing to be done for me in Mantis. >> >> With a very small understanding, I have been able to implement a working >> patch though. >> >> So I'd suggest for you to check out drivers/pci/pci-driver.c first to >> implement similar PCI >> functionality into budget-av. That might fix S2MEM and S2DISK. Or then >> there is still something >> more that has to be done. >> >> With my implementation I can use Kaffeine so, that after S2DISK, >> Kaffeine will continue showing >> the channel that it showed before. Kaffeine doesn't have to retune or >> restart DMA transfer. >> So only some frames were lost. >> Kaffeine didn't work properly with USB based sound output, and thus I needed >> motherboard internal sound output for the tests. >> > > Thanks for your response. > > Meanwhile I had a look at Documentation/power and did more tests. > Great. > For a proper suspend/restore implementation there is much more to be > done. The state of the saa7146 must be saved/restored, which requires > more than a few hours of work (and testing!). I put it on my todo list. > > Is there any way to find out the power state the system tries to enter > (standby/mem/disk)? > > static int mantis_pci_suspend(struct pci_dev *pdev, pm_message_t mesg); Here mesg.event (defined in linux/pm.h) contains the state transition message on suspend() function. mesg.event suspend states (PM_EVENT_SUSPEND, PM_EVENT_FREEZE and PM_EVENT_PRETHAW) are documented in (latest Linus) kernel sources in Documentation/power/devices.txt. (I understood devices.txt better than the documentation in linux/pm.h). It seems to me that if mesg.event is PM_EVENT_PRETHAW, the computer is doing suspend() to disk and in that case the hardware state will be invalid on resume(). suspend() to mem: hardware state will not be invalid on resume. It seems that with these messages, it isn't easy to distinguish standby and suspend to mem target states. Maybe they are thought to behave similarily. > For now, I could add support for standby mode and deny any attempt to > enter mem or disk supend mode. Better than nothing... > > So maybe it suffices to deny the PM_EVENT_PRETHAW case and quiesce the driver in PM_EVENT_SUSPEND? > CU > Oliver > > CU Marko _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
