[pvrusb2] speedup mythtv frequency changes

[Mike Isely]

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