[pvrusb2] speedup mythtv frequency changes

[Ingo Flaschberger]

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
>
-------------- next part --------------
--- pvrusb2-mci-20060103_org/driver/pvrusb2-hdw.c	2006-01-03 05:25:00.000000000 +0100
+++ pvrusb2-mci-20060103/driver/pvrusb2-hdw.c	2006-01-07 00:22:40.000000000 +0100
@@ -1297,8 +1297,10 @@
 		   function, then treat this as a read-only value. */
 		return -EINVAL;
 	}
-	hdw->controls[ctl_id].value = value;
-	hdw->controls[ctl_id].dirty = !0;
+	if (hdw->controls[ctl_id].value != value) {
+		hdw->controls[ctl_id].value = value;
+		hdw->controls[ctl_id].dirty = !0;
+	}
 	return 0;
 }