Marko,
On 07/21/2012 07:36 PM, Antti Palosaari wrote:
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).
I ended-up still quite much DVB USB driven implementation. DVB-core
(frontend) is asked only to do retune on resume.
http://git.linuxtv.org/anttip/media_tree.git/commit/4829b70d8acf8c815e783e55e13f57beb3609602
http://git.linuxtv.org/anttip/media_tree.git/commit/ec99a11dc0c92df3c7f2b0b1f02fcddb23636391
It still lacks LNB voltage and tone and LNA handling. But as those are
quite rare I decided to left those out for now. For LNB there is already
some logic inside dvb frontend which could be used...
DVB frontend seems to be quite complex currently and due to that I don't
want to touch it much. There is all kind of quirks including APIv3 /
APIv5 conversions. I am almost sure half of frontend code could be
reduced if written from the scratch.
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
