Comment # 7
on bug 69675
from Anssi Hannula
(In reply to comment #6) > I just meant to patch the table so that you end up using the pre-defined > values for CTS and N rather than calculating them from the formula. > > { xxx, 11648, 210937, 17836, 234375, 11648, 140625 }, /* 74.25/1.001 MHz */ > > Replace xxx with whatever clock value the drm edid code gives you for > 74.25/1.001 MHz. Ah, OK. > The's presumably a reason the predefined values are there rather just using > the formula for everything. Well my guess is that the table could be there just because the HDMI spec has that table. Note how everything in the table except the three /1.001 rates (that have differing N) just have the same N/CTS value that the manual calculation would result in anyway. The reason the table is in the spec is because using the "default" N for the (exact, relative to audio) /1.001 rates results in a non-constant CTS - which is not preferred though should still work. > The actual clock generated by the PLL will not always be exact either. It's > limited by reference clock and the divider ranges. Hence my preference for HW counted CTS if at all possible. If HW CTS will not work and it is confirmed that the CTS value is indeed the issue here, it might get a bit tricky to figure out the proper values in all cases... Of course it could be this is not CTS/N related at all and something else in HDMI audio programming is wrong for these "unusual" pixel clocks. Better not get too much ahead of ourselves until we know if the HW measured CTS patch makes any difference, though... :)
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
