On Fri, 2010-03-12 at 21:34 +1100, Vincent McIntyre wrote: > On 2/20/10, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > > Robert Lowery wrote: > >> Mauro, > >> > >> I had to make 2 changes to get the patch to work for me > > > > Ok. Please test this (hopefully) final revision. > > > > -- > > > > commit bd8bb8798bb96136b6898186d505c9e154334b5d > > Author: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> > > Date: Fri Feb 19 02:45:00 2010 -0200 > > I finally found time to test carefully and if anyone still cares, the > patch works fine for me too. > I pulled it in from the hg tree, by the time it got there it had > morphed a little... > Many thanks for your (and Rob's) patient work on this. > > I've attached a test log that shows what happens with signaltest.pl, > on each tuner. > The first two adapters are the Dual Digital 4 rev1, the next two > belong to a FusionHDTV Dual Digital Express. > > The errors are nice and small now, compared with the values I got > before the patch. > I noticed something a little odd - the UNC error value always > increases, even though > signaltest.pl does a fresh invocation for each station in the sequence. This is proper behavior for the frontend. The UNC count should not be reset when it is read (think of what would happen when more than one app was trying to monitor the frontend status). What matters is the slope of the UNC curve over a measurement interval: == 0 is good, > 0 is bad. > Switching to a different tuner seems to reset the UNC error counters. The zl10353 driver will maintain the UNC block count for each paticular ZL10353 chip in the system. It will only go back to 0 for a particular ZL10353 chip when the the driver's 32 bit "state->ucblocks" variable for that chip rolls over. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
