On 09/30/2014 05:46 AM, Ville Syrjälä wrote:
On Fri, Sep 26, 2014 at 09:28:50AM -0700, Clint Taylor wrote:
On 09/26/2014 08:58 AM, Ville Syrjälä wrote:
On Wed, Sep 24, 2014 at 03:49:39PM -0700, clinton.a.taylor@xxxxxxxxx wrote:
From: Clint Taylor <clinton.a.taylor@xxxxxxxxx>
port_clock was being incorrectly computed and WRPLL was incorrectly
programmed for pixel doubled modes using a 27.027MHz pixel clock.
port_clock was set to 27.026 resulting in an output pixel clock
matching 27.000MHz.
I don't understand how this 27.000MHz clock would come about. Can you
explain further?
I didn't really drill down into the issue once I saw the WRPLL was being
computed differently for 480i@60 and the port clock was being passed as
27026.
Since there is no way to correctly half the 27.027
frequency as an integer just set port_clock to 27027 for these modes.
Signed-off-by: Clint Taylor <clinton.a.taylor@xxxxxxxxx>
---
drivers/gpu/drm/i915/intel_hdmi.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 29ec153..a0786d6 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -933,6 +933,11 @@ bool intel_hdmi_compute_config(struct intel_encoder *encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK) {
pipe_config->pixel_multiplier = 2;
+
+ /* Fix up port_clock since 27027 is not divisible by 2 */
+ if (pipe_config->adjusted_mode.crtc_clock == 13513) {
+ pipe_config->port_clock = 27027;
+ }
Ugh. Oh well I suppose we'll want to be as accurate as possible. Would
be nice if would could someone do this fixup already in drm core, but
that would probably require changing to smaller clock units all over
the place which doesn't sound fun at all. So I guess we get to leave
the kludge in the driver :(
I don't like using the 13MHz family in the mode table for this very
reason. Maybe I should revisit the pixel clock setting and computation
for pixel doubled modes in the i915 code.
That has certain appeal, but it will force userspace to adjust the
clock for double clocked modes when it wants to calculate the refresh
rate. I don't really like even exposing the DBLCLK flag to userspace
since it's basically an internal implementation detail. Some of the
modes also allow higher pixel repeat factors, and we have no way to
inform userspace about those. So I think that forcing userspace to
deal with the multiplied clock is not a good idea.
This also got me thinking about the 12bpc case as well. It's clearly
busted with double clocked modes now. Care to fix that up as well?
What's the best way to enter into 12bpc mode? I tried to force the mode
in hdmi_compute_config(), but I wasn't able to get output.
Looks like our 12bpc suppor is pretty broken. I did manage to make it
work on my IVB here but that was after I wrote several patches to fix
things. I don't have time to clean those up right now, but if anyone
else wants to work on that I can share them.
Send me the patches and I can look at the 12bpc support. My main concern
with 12bpc is we don't automatically switch to 12 bit when the HDMI
monitor supports it and nobody would take the time to manually switch to
12bpc using an x11 property every time they boot. I've never had an
issue with sending Deep Color to a TV that supports it, but I'm also not
ready to try and make it automatic in the driver.
-Clint
PS. did you ever send that separate patch to fix up the interlace
flags in some of the double clocked modes? I don't remember seeing
such a patch at least.
I had that on my TODO list and when I went to look at the modes (576i
@200Hz) they were already correct. Magic happens!!
-Clint
}
if (intel_hdmi->color_range)
--
1.7.9.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
