Re: Thoughts about suspending DVB C PCI device transparently
Hi.
Thank you for noticing my old email.
My observation of working suspend/resume implementation was,
that the needed amount of code for suspend and resume functions
was very small and easy. I reorganized mantis_pci.c so that both
module initialization and suspend/resume could use the same
functions for DVB device initialization.
Mantis structure needed maintenance of status before suspend
so that the status could be restored afterwards:
- power state (had feature to turn tuner off when idle).
- get_frontend(fe, param) content.
- number of feeds before suspend.
Each sub-device (C-file) needed it's own suspend() and resume() function
and these functions had to be called in the right order, starting
from mantis_pci.c's functions, some maintained IRQ states. After powering
and initializing all hardware, frontend was tuned back to state before suspend,
FE lock waited and DMA transfer turned back on.
Other kernel parts (the framework) took care that
no user space program will interfere during the resume process.
Media/dvb-core didn't need any changes for this to work.
Regards,
Marko Ristola
20.11.2010 14:57, Richard Zidlicky wrote:
Hi,
found this old email when searching for suspend issues, seems like a good idea.
Just wondering - how many eg dvb drivers are there with working
suspend/hibernate
(all buses, not just PCI)? Me thinks only a small fraction, the rest will crash
unless blacklisted by pm-utils?
I don't know any that works, but maybe there are a few of them.
Would it be worth to code a generic approach working around drivers that need
to be
blacklisted? It seems that because of eg firmware loading this might be the
only way
to get dvb drivers behave?
Sharing the approach would work, but code sharing might not be worth it.
Maybe putting some knowledge into small functions to ease up bus initialization
would help: driver developer would need as few knowledge from the bus as
possible.
A document and a reference implementation would help others to add
suspend/resume
into their simple drivers. Maybe users and developers want nicer suspend/resume
implementation now compared to the old times. Is the demand high enough now?
Richard
Once in a time I wrote into Mantis driver Suspend / resume
code. The idea was, that bridge driver (mantis_dvb.c) will
handle the suspend / resume transparently to the application.
With a PCI device this was rather easy to achieve.
With xine, there was just a glitch with video and audio
after resume.
So after suspend, frontend was tuned into the original
frequency, and the DMA transfer state was restored.
Suspend:
1. Turn off possible DMA transfer if active (feeds 0)
2. Remember tuner power on state.
3. Do tuner and fronted power off.
Resume:
1. Restore frontend and tuner power.
2. (feeds 0)? Set frequency for the tuner.
3. (feeds 0)? Restore DMA transfer into previous state.
What do you think about this?
I need some feedback: is it worth coding?
Other needed code is usual suspend / resume stuff.
Is it worth powering off the tuner, if it isn't
used?
For my current usage, powering off the unused tuner
gives more power savings than implementing suspend/resume.
Marko Ristola
--
// suspend to standby, ram or disk.
int mantis_dvb_suspend(struct mantis_pci *mantis, pm_message_t
prevState, pm_message_t mesg)
{
if (mantis-feeds 0)
mantis_dma_stop(mantis);
if (mantis-has_power)
mantis_fe_powerdown(mantis); // power off tuner.
return 0;
}
void mantis_dvb_resume(struct mantis_pci *mantis, pm_message_t prevMesg)
{
// power on frontend and tuner.
mantis_frontend_tuner_init(mantis);
if (mantis-feeds 0 mantis-fe-ops.tuner_ops.init)
(mantis-fe-ops.init)(mantis-fe);
if (mantis-feeds 0) {
(mantis-fe-ops.set_frontend)(mantis-fe, NULL);
mantis_dma_start(mantis);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Thoughts about suspending DVB C PCI device transparently
Hi,
found this old email when searching for suspend issues, seems like a good idea.
Just wondering - how many eg dvb drivers are there with working
suspend/hibernate
(all buses, not just PCI)? Me thinks only a small fraction, the rest will crash
unless blacklisted by pm-utils?
Would it be worth to code a generic approach working around drivers that need
to be
blacklisted? It seems that because of eg firmware loading this might be the
only way
to get dvb drivers behave?
Richard
Once in a time I wrote into Mantis driver Suspend / resume
code. The idea was, that bridge driver (mantis_dvb.c) will
handle the suspend / resume transparently to the application.
With a PCI device this was rather easy to achieve.
With xine, there was just a glitch with video and audio
after resume.
So after suspend, frontend was tuned into the original
frequency, and the DMA transfer state was restored.
Suspend:
1. Turn off possible DMA transfer if active (feeds 0)
2. Remember tuner power on state.
3. Do tuner and fronted power off.
Resume:
1. Restore frontend and tuner power.
2. (feeds 0)? Set frequency for the tuner.
3. (feeds 0)? Restore DMA transfer into previous state.
What do you think about this?
I need some feedback: is it worth coding?
Other needed code is usual suspend / resume stuff.
Is it worth powering off the tuner, if it isn't
used?
For my current usage, powering off the unused tuner
gives more power savings than implementing suspend/resume.
Marko Ristola
--
// suspend to standby, ram or disk.
int mantis_dvb_suspend(struct mantis_pci *mantis, pm_message_t
prevState, pm_message_t mesg)
{
if (mantis-feeds 0)
mantis_dma_stop(mantis);
if (mantis-has_power)
mantis_fe_powerdown(mantis); // power off tuner.
return 0;
}
void mantis_dvb_resume(struct mantis_pci *mantis, pm_message_t prevMesg)
{
// power on frontend and tuner.
mantis_frontend_tuner_init(mantis);
if (mantis-feeds 0 mantis-fe-ops.tuner_ops.init)
(mantis-fe-ops.init)(mantis-fe);
if (mantis-feeds 0) {
(mantis-fe-ops.set_frontend)(mantis-fe, NULL);
mantis_dma_start(mantis);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thoughts about suspending DVB C PCI device transparently
Hi all.
Once in a time I wrote into Mantis driver Suspend / resume
code. The idea was, that bridge driver (mantis_dvb.c) will
handle the suspend / resume transparently to the application.
With a PCI device this was rather easy to achieve.
With xine, there was just a glitch with video and audio
after resume.
So after suspend, frontend was tuned into the original
frequency, and the DMA transfer state was restored.
Suspend:
1. Turn off possible DMA transfer if active (feeds 0)
2. Remember tuner power on state.
3. Do tuner and fronted power off.
Resume:
1. Restore frontend and tuner power.
2. (feeds 0)? Set frequency for the tuner.
3. (feeds 0)? Restore DMA transfer into previous state.
What do you think about this?
I need some feedback: is it worth coding?
Other needed code is usual suspend / resume stuff.
Is it worth powering off the tuner, if it isn't
used?
For my current usage, powering off the unused tuner
gives more power savings than implementing suspend/resume.
Marko Ristola
--
// suspend to standby, ram or disk.
int mantis_dvb_suspend(struct mantis_pci *mantis, pm_message_t
prevState, pm_message_t mesg)
{
if (mantis-feeds 0)
mantis_dma_stop(mantis);
if (mantis-has_power)
mantis_fe_powerdown(mantis); // power off tuner.
return 0;
}
void mantis_dvb_resume(struct mantis_pci *mantis, pm_message_t prevMesg)
{
// power on frontend and tuner.
mantis_frontend_tuner_init(mantis);
if (mantis-feeds 0 mantis-fe-ops.tuner_ops.init)
(mantis-fe-ops.init)(mantis-fe);
if (mantis-feeds 0) {
(mantis-fe-ops.set_frontend)(mantis-fe, NULL);
mantis_dma_start(mantis);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
