Hi Manu, I have done more testing to simplify the code. Manu Abraham wrote: > Hi Marko, > > On 8/7/07, Marko Ristola <marko.ristola@xxxxxxxxxxx> wrote: > >> Hi Manu, >> >> ... > > Ok. i will have to port the tree again. Some other changes as well, I > need to add in support for the DVB-S2 cards as well. But it needs a > bit of time from my side on it. I will club it alongwith the DVB-S2 > changes. > > Take your time. It would be nice to get remote control stuff some day in also. That's not my code you know, but it works at least. > >> This patch doesn't include remote control support, >> because mantis_rc.c is not yet in the version control. >> >> cu1216.c: many small adjustments. >> - Fixes rmmod/insmod "lost frontend" problem. >> - Fixes inversion=1 support requirement for Finland DVB-C. >> - dvb_core is able to reset cu1216 module if it fails. >> >> dvb/mantis: many suspend related adjustments. >> - Suspend/resume support for S2DISK: it works for cu1216. See >> mantis_dvb.c if you >> like to add support for other frontend. >> - mantis_dvb.c: will not load all Mantis frontend modules, but just the >> ones that are needed. >> - mantis_dvb.c: will turn off tuner (tuner_ops.sleep) , and turn it on >> again for cu1216.c (tuner_ops.init). >> - mantis_dvb.c: suspend/resume support takes advantage of the tuner >> power functions and fe->ops.set_frontend(fe,NULL) if tuner_ops.init is >> defined. >> - mantis_pci.c: share code with probe and resume and with exit and suspend. >> - mantis_i2c.c: suspend/resume support. >> - mantis_i2c.c: mantis_i2c_init and mantis_i2c_exit altered a lot, but >> those changes aren't necessary anymore. >> Maybe remove those unnecessary changes? >> - mantis_dma.c: suspend/resume support. mantis_start_dma and >> mantis_stop_dma calls are enough though. >> > > > You wouldn't need to touch I2C/DMA for that. It will Resume as soon as > the PCI device is enabled back. What you will have in the RISC FIFO > will be garbage after you Resume, the only disadvantage is on Resume, > you initially have a few blocks of garbage, but considering the DVB > stream, that's nothing an extremely short period, which might not be > noticeable even in some cases. > I commented out all PCI stuff for these tests. So no pci_save_state()/pci_restore_state() was done in mantis_pci.c and no bus_master settings, and no "turn PCI irq off" on suspend. I removed I2C and DMA changes for existing functions. I removed all changes from mantis_dma.c. - get_frontend was needed because it does the tuning. - turning on tuner power was necessary. - fe->opt.init (cu1216_init) was not needed, because get_frontend(fe,NULL) calls it internally. - DMA stop/start seems to be necessary, I don't remember exactly. - I2C suspend/resume is necessary in this test, because otherwise tuning takes 8 seconds, although it should complete in less than 1s. It seemed on this test, that if I2C Mantis IRQs are not restored, I2C will timeout and thus the tuning succeeds, but in 8 seconds. So I think that if I do pci_save_state() in .suspend in mantis_pci.c and pci_restore_state() in .resume in mantis_pci.c and other PCI stuff there, it might be that I2C IRQ restore is not necessary. > What _really_ that's need to be done is: > > In the suspend call back > * Switch off tuner power, the function already is there. > I agree. > * disable the device, this is achieved by the "Suspend code in kernel" > by writing to the PCI config space directly. You don't need to > manually toggle it. Already handled by the PCI Subsystem, AFAIK. > I read the latest Kernel Suspend and Hibernation status report from http://lwn.net/Articles/243404/ included in over week old Linux Weekly News. I also took a fresh clone of Linus's GIT tree to see current Suspend/Hibernation PCI code. I found the code from drivers/pci/pci-driver.c. On both suspend and resume, it saves PCI state and restores it later, if and only if the PCI driver hasn't implemented .suspend or .resume callbacks. So I see now still that if I implement suspend/resume into mantis_pci.c, I have to do full PCI suspend/resume as well. > In the resume in the case of the 2033, you just need to tune back, > that's all. in the current code all initialization is by code, rather > than values from an init table. That's the only difference, but that > doesn't make any difference. > > So I will try to test with pci_save_state() and pci_restore_state() calls. Then I will se if it holds that I need just to retune. I remember something from my tests, that doing retune without turning DMA off, resume locked up. >> Maybe just remove all suspend/resume code from mantis_start/stop_dma? >> - mantis_common.h: suspend/resume support. Some suspend status support >> added and introduced some functions. >> - mantis_core.h: suspend/resume support: Introduced some functions. >> - mantis/Makefile: Use += for flags: this is the way in current v4l-dvb >> main branch. >> >> > > *Poff* > > :) > > Do you need to do so much ? AFAICS, for suspend/resume you need to do > just very little. > Julian has a tested patch for the KNC1 cards, which makes it look > quite neat. Would appreciate, if you would take a look at it as well. > > If you have any comments or need any suggestions/help, please do let me know. > > > Julian's patch just calls ciintf_deinit() + ciintf_init() functions. That's the most brutal way but it's not my target: I want to have Kaffeine/VDR to continue with just seeing some garbage or finding a shortage of packets at most. I remember that while testing with VDR, suspend locked up with me. So I decided to implement suspend/resume as adviced in linux/Documentation/power/pci.txt. VDR and Kaffeine would just find a data gap and they don't need to stop dma + retune + start dma to be able to continue. > Thanks, > Manu > > Best regards, Marko _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
