Morjens!
I am now working with that suspend/resume/power-management, as I got LNA
issues resolved.
On 07/03/2012 08:21 PM, Marko Ristola wrote:
Moikka Antti.
On 07/01/2012 02:11 PM, Antti Palosaari wrote:
Moikka Marko,
-- snip --
Hmm, I did some initial suspend / resume changes for DVB USB when I
rewrote it recently. On suspend, it just kills all ongoing urbs used
for streaming. And on resume it resubmit those urbs in order to resume
streaming. It just works as it doesn't hang computer anymore. What I
tested applications continued to show same television channels on resume.
The problem for that solution is that it does not have any power
management as power management is DVB-core responsibility. So it
continues eating current because chips are not put sleep and due to
that those DVB-core changes are required.
I think that runtime (RT) frontend power saving is a different thing.
It isn't necessarily suspend/resume thing.
Yes it is different thing (DVB-core runtime power-management). But as
there is currently implemented .init() and .sleep() callbacks both
frontend and tuner for power management I don't see why not to use those
for suspend and resume too.
I implemented runtime Frontend power saving in 2007 on that patch I
referenced.
I used dvb-core's existing functionality. Maybe this concept is
applicable for you too.
I added into Mantis bridge device initialization following functions:
+ mantis->fe->ops.tuner_ops.sleep =
mantis_dvb_tuner_sleep;
+ mantis->fe->ops.tuner_ops.init =
mantis_dvb_tuner_init;
tuner_ops.{sleep,init} modification had to be the last one.
I maintained in mantis->has_power the frontend's power status.
Maybe I could have read the active status from PCI context too.
The concept was something like:
- dvb-core has responsibility to call tuner_ops.sleep() and
tuner_ops.init() when applicable.
- Mantis PCI Bridge driver (or specific USB driver) has responsibility
to provide sleep and init implementations for the specific device.
- Mantis bridge device will do the whole task of frontend power
management, by calling Frontend's
tear down / initialization functions when necessary.
I looked it and reads your discussion too. That code seem never ended up
for Mantis.
But the idea is just basically same: use existing sleep() calls to put
device sleep on suspend and on resume use init() to wake-up again. You
stored existing parameters inside driver state and retuned using those
when set_frontend() get NULL as a parameter. Things has changed a little
after that and now those parameters are stored already in dvb-frontend
cache - which means a little less work for driver.
- What changes encrypted channels need?
I think none?
So after all, what I think currently, is:
* bridge sets and forwards .suspend() callback to dvb-core
* bridge sets and forwards .resume() callback to dvb-core
* on suspend, dvb-core puts device sleep
* on resume, dvb-core wake-ups device and inits tune (parameters are in
cache already)
Clearly, put hardware sleep similarly as in case frontend is in sleep,
but keep userland interface alive (frontend, demux, etc).
There is a quite lot of documentation to learn and overall whole Kernel
power-managent is very complex. Fortunately driver implementation is
very simple most cases. Also as changing DVB-core is needed it should be
extremely care not make any regressions.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
