On Sat, Jan 11, 2014 at 5:12 PM, Tim Mester <tmes...@ieee.org> wrote: > My device is the 950q, so it uses the AU8522_DEMODLOCKING method.
No devices do tuner locking for digital (it's always the demodulator). That code should really just be ripped out. > It does not appear to be an xc5000 issue on the surface. When I > originally put the patch together, I removed the return if the > frequency was the same, and added the reset_demodulator() call at the > end of the set_frontend() function. It seemed to work the same as the > patch that I submitted. I'm pretty sure that we accomplish the same thing through the patch I have which reworks the clock management. except for removing the part where the set_frontend() call returns if the freq/modulation are already set. > I have not been able to tell that it keeps the au8522 from losing > lock, but it allows it to come back. I see this issue about once a > every 2-3 weeks on average, which is less frequent than the other > issues. > > If you believe that this issue could result in a xc5000 and au8522 > interaction, then I should be able to try out the updated firmware. It > will just take some time to know the results. My instinct would be to get you to try that patch series I have in git. I suspect that it will address your issue with no further patches required (we might need the one additional patch to remove the early return in set_frontend, but let's see). The testing of the new firmware can be done in a separate series (the issue it addresses is completely unrelated to the behavior you are seeing). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
