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 -- 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
