[Bug 77009] 24P playback video signal loss with latest DRI patches

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77009

--- Comment #29 from Garrett <socalfisher at gmail.com> ---
(In reply to comment #28)

> Depending on the details of their electrical implementation all PLLs behave
> more or less like this. The trick is to know how to find the right numbers
> without violating the contrains.

yup..  This is a fun one to deal with in the embedded environment (love that
scope.).  I consider this bug fixed.  I am not sure if I am supposed to mark it
ok or something.  Else I will leave it.

I thought about the pll thing.  I don't know the HDMI message layer at all.  I
am not sure it is public knowledge anyhow.

To get higher divs, I was thinking a potential algo could go (MUCH easier said
than done, I know):

1) Run a setup program each time a hardware change is detected. (EDID or GPU)
2) Test LCD/Panel at various popular refresh rates.
    a) crank up the pll with your new algo. 
         >>  *test* if tv accepted it. (requires a knowledge of protocol to
check display state, or have user answer ok with a timeout in case it is not
readable)
         >> save the new div setting (maybe the 10% lower ones to be safe) to a
config with a table for that hardware/refresh.
3) on reboot load new optimized saved PLL dividers from the table.  And on each
refresh rate change use the table.

But that said.  It does not really matter for me to make it closer.  Your new
algo with your "arbitrary" 100 limit works well on my hardware.  I tested 368
and it looked great, too.  368 vs 100 on 24P made vary little difference too
me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/afa0392f/attachment.html>