On Wed, Jan 8, 2014 at 1:26 PM, Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> wrote: > Hi Tim, > > On Wed, Jan 8, 2014 at 12:12 AM, Tim Mester <tmester@xxxxxxxx> wrote: >> Commit 2e68a75990011ccd looks interesting. It makes sense to me >> that if we are gating the clock, and it is possible that we are >> glitching the clock line, it could put the internal synchronous logic >> into a bad state. If that happens, it would generally require a reset >> under a stable clock to get out of that condition. I will give that >> patch a try an see if it addresses issue 1), mentioned above. > > Yeah, the whole thing about the clocks not being enabled/disabled in > the correct order relative to enabling the sub-blocks did result in > some strange cases where sub-block wouldn't reactivate properly, > requiring a reset to return it to a working state. It was > specifically this issue I was concerned about might be the "right fix" > for the problem you are hitting. > > Note: you need more than just 2e68a75990011ccd. That is actually an > add-on to the real commit that restructures the clock managment: > 39c39b0e612b5d35feb00329b527b266df8f7fd2 > >> However, I'm not sure if that will do anything about issue 2). Do you >> have any insight into that one? > > Well, I've never been a fan of how the code just does a blind "return > 0" if the target modulation and frequency are the same as it's in > theory already tuned to. Have you tried commenting out just that > block and see if it makes a difference? IIRC, the dvb-frontend kernel > thread should automatically re-issue a set_frontend() call if the > signal lock drops out. > > As for the underlying problem, I'm not sure. Generally once the > signal is locked it continues to work. If you set the xc5000 debug=1 > modprobe option, do you see lines in the log that say "xc5000: PLL not > locked"? > > How reproducible is the issue, and how often does it happen? I've got > some newer firmware that might be worth trying which isn't upstream > yet (assuming for a moment that it's an xc5000 issue). If you believe > you can repro the issue pretty regularly, you and I can work offline > to try that out. > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com Devin, My device is the 950q, so it uses the AU8522_DEMODLOCKING method. 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 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. Thanks, Tim -- 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
