On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky <mkrufky@xxxxxxxxxxx> wrote: >>>>>> [ 812.465930] tda18271: performing RF tracking filter calibration >>>>>> [ 818.572446] tda18271: RF tracking filter calibration complete >>>>>> [ 818.953946] tda18271: performing RF tracking filter calibration >>>>>> [ 825.093211] tda18271: RF tracking filter calibration complete > > > If you see this happen more than once consecutively, and there is only 1 > silicon tuner present, then it means something very bad is happening, and > there is a chance of burning out a part. I still wouldnt not recommend any > mainline merge until you can prevent this behavior -- I suspect that a GPIO > reset is being toggled where it shouldnt be, which should be harmless ... > but until we fix it, we cant be sure what damage might get done... > > The RF tracking filter calibration is a procedure that should only happen > once while the tuner is powered on -- it should *only* be repeated if the > tuner indicated that calibration is necessary, and that would only happen > after a hardware reset. > > This still looks fishy to me... It happened at every tuning operation, and made mythfrontend unhappy (unable to tune after the first channel). I disabled the check for RF_CAL_OK which triggered the recalibration, and mythfrontend worked. The stick has been plugged in for a few months, so presumably would've caught on fire by now if it was going to. It would be nice if the tuning delay went away, though.. it still takes ~6 seconds to switch frequencies. I have not yet compiled and tested the lastest patches from Jarod. R C -- 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
