[pvrusb2] speedup mythtv frequency changes

[Ingo Flaschberger]

Hi Mike,

> I'll see about including it (along with the others).  One word of caution 
> though: We need to be careful about changing behavior like this.  On the 
> surface it makes sense to not change a parameter when the new value is the 
> same.  However the old behavior was different - the old value got re-pushed 
> everywhere - and I'm a little concerned that this might trip something up 
> which depended on it.  Off the top of my head, I can't think of any reason 
> why something would have depended on it, but a little voice in the back of my 
> head is telling me that I remembered thinking about this issue a long ways 
> back and for some reason I had decided not to do this sort of optimization. 
> This is not to say I won't include it, but I just want to step carefully 
> here.  I've thrashed the driver pretty good in the past week (as I'm sure 
> everyone has noticed)...

Perhaps add a module option for enabling optimization?

bye,
 	Ingo

>  -Mike
>
> On Sat, 7 Jan 2006, Ingo Flaschberger wrote:
>
>> Hey
>> 
>> I have now attached the patch. Was easy when to know where....
>> 
>> Mythtv is now a little bit faster in channel changes.
>> 
>> bye,
>> 	ingo flaschberger
>> 
>> geschaeftsleitung
>> crossip communications gmbH
>> ------------------------------
>> sebastian kneipp gasse 1
>> a-1020 wien
>> fix: +43-1-726 15 22-217
>> fax: +43-1-726 15 22-111
>> mob: +43-699-105 86 719
>> www.xip.at
>> ------------------------------
>> On Fri, 6 Jan 2006, Mike Isely wrote:
>> 
>>> 
>>> On further thought I suppose what could be done is to simply not set the 
>>> dirty flag if the new incoming value for a control isn't any different 
>>> than what is already there.  This will avoid overhead if for example the 
>>> same bcsh values keep getting sent.  The logical place to do that would be 
>>> in the function that is used to set the control in the first place (not 
>>> the commit function).
>>> 
>>> However I am also fairly certain that in the case of bcsh updates, there 
>>> should be virtually no impact on frequency changing overhead.
>>>
>>>  -Mike
>>> 
>>> 
>>> On Fri, 6 Jan 2006, Mike Isely wrote:
>>> 
>>>> On Fri, 6 Jan 2006, Ingo Flaschberger wrote:
>>>> 
>>>>> Hi Mike,
>>>>> 
>>>>> I want to speed up frequency changes with mythtv.
>>>>> Mythtv have the not really nice habit to always set Contrast, 
>>>>> Saturation, Brightness and Hue.
>>>>> 
>>>>> It should be possible from the pvrusb2 driver only to update the i2c 
>>>>> chips when really anything has changed and will speed up the changes.
>>>>> 
>>>>> As far as I have seen pvr2_hdw_commit_ctl in pvrusb2-hdw.c would be a 
>>>>> good place to implement this?
>>>>> Could pvr2_hdw_commit_ctl called with more than one thing to change??
>>>>> 
>>>>> Need some tips where to implement this.
>>>> 
>>>> It already does that.
>>>> 
>>>> Every "control" in the pvrusb2 driver has a dirty flag associated with 
>>>> it; the commit function will then handle updating of everything that is 
>>>> dirty at that point.  What happens is roughly like this:
>>>> 
>>>> 1. Application changes one or more controls, causing corresponding dirty 
>>>> flags to be set.
>>>> 
>>>> 2. The commit function is called internally by the driver to commit all 
>>>> dirty state.  It (as of the 20051231 snapshot) does three things to 
>>>> accomplish this:
>>>> 
>>>> 2a. The commit function handles some side effects, e.g. adjusting a 
>>>> control if a related control becomes dirty - that generally only applies 
>>>> to changing of the video standard or frequency vs channel table stuff.
>>>> 
>>>> 2b. The commit function will toggle subsystems in the driver which must 
>>>> be impacted by the dirty state.  For example, if the capture resolution 
>>>> gets changed, then it will cause streaming to restart if it was in 
>>>> progress.
>>>> 
>>>> 2c. (Changed for 20051231) The module controlling logic will be given a 
>>>> chance to notice dirty controls and trigger updates to corresponding 
>>>> modules. Before 20051231, this was all done more directly within the 
>>>> commit function; now that level of control is moved out to logic which is 
>>>> closer to the I2C side (however the result is the same).
>>>> 
>>>> The running theme here is that updates are only sent for things that have 
>>>> changed and for what makes sense given the change.  The driver already 
>>>> won't gratuitously update things that don't make sense, and it won't 
>>>> reset streaming as a side effect unless it knows that it has to (and for 
>>>> bcsh adjustments streaming should be unaffected).
>>>>
>>>>  -Mike
>>>> 
>>>> 
>>> 
>>> --
>>>                        |         Mike Isely          |     PGP fingerprint
>>>     Spammers Die!!     |                             | 03 54 43 4D 75 E5 
>>> CC 92
>>>                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 
>>> C1 E8
>>>                        |                             |
>>> _______________________________________________
>>> pvrusb2 mailing list
>>> pvrusb2 at isely.net
>>> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>> 
>
> --
>                        |         Mike Isely          |     PGP fingerprint
>     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 
> 92
>                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 
> E8
>                        |                             |
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>