Comment # 27
on bug 77009
from Garrett
(In reply to comment #24) > (In reply to comment #22) > > I am trying to understand the plls. > > Well how deep are you interested in getting into this? PLLs can be > complicated, but are also one of the very basic building blocks of > electronics. > No need to dig too deep. I work with embedded firmware. PLL clocks/timing are fine (I understand basics). In reference to video this is new stuff. I sincerely appreciate your time educating me. > > I read the org. bug report 76564. I > > assumed increasing the max would allow higher pll vals. But it does go down > > with some. Does that make sense? > > More or less yes. See your numbers for example, without the limit patch you > had the params like this: > > 148340 - 14834, pll dividers - fb: 741.7 ref: 50, post 10 > > This means with a feedback divider of 741.7, a referenz divider of 50 and a > post divider of 10 you have an exact match for the frequency. > > There is just the little problem that as the divider numbers get higher the > signal gets more unstable. So in reality you don't get 148.340 MHz, but > instead something that fluctuates between 148.339 MHz and 148.341 MHz (for > example). "the signal gets more unstable" So it is the gpu that varies its freq. at higher divs (multipliers) and my set is not tolerant of signal freq. fluctuations to keep data in sync? If I understand this correctly- This is like in a micro-controller where deviations in baud rate (a pll generated clock) leads to serial transmission errors when > 5% deviation, for example. In micro-controllers: high multipliers * internal pll = less stable freq >> less stable baud rate. > > The overall match for the average frequency is still better than with lower > numbers, but your TV/Monitor can't deal with such high fluctuations in it. > > > Your patch does wonders for this A4-3400. I am trying to understand it > > better. > > > > Here your max is 100. ref: 10, post 10 >>>> 10 * 10 = 100 max. > > Yes correct. Thanks for explaining this so clearly. Garrett
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
