[pvrusb2] speedup mythtv frequency changes

[Mike Isely]

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)...

   -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
                         |                             |