Re: DVB core enhancements - comments please?

[Antti Palosaari <crope@iki.fi>]

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/