On 10/08/2015 05:44 AM, Ville Syrjälä wrote:
On Thu, Oct 08, 2015 at 03:39:26PM +0300, Jani Nikula wrote:
On Thu, 08 Oct 2015, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
On Wed, Oct 07, 2015 at 02:38:29PM -0700, clinton.a.taylor@xxxxxxxxx wrote:
From: Clint Taylor <clinton.a.taylor@xxxxxxxxx>
The TMDS_296M define was computing as 296704 but the mode->clock is
296700 as defined by EDID. Adjusted define to allow correct detection
of the need to program the correct N value for 29.97 and 23.98 refresh
rate.
Signed-off-by: Clint Taylor <clinton.a.taylor@xxxxxxxxx>
---
drivers/gpu/drm/i915/intel_audio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c
index 56c2f54..419c979 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -75,7 +75,7 @@ static const struct {
/* HDMI N/CTS table */
#define TMDS_297M 297000
-#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
+#define TMDS_296M 296700
Hmm. I think we might want to fix up the mode instead. Let me post a few
patches, and let's see what people think...
We might actually want to queue this up for v4.3 as the immediate fix,
as I feel it's doubtful your other patches will make it to v4.3.
If Someone(tm) provided their r-b that is.
Except this is wrong if the mode came from the CEA/HDMI mode list as
opposed from the EDID detailed timings.
The original patch was generated from a monitor with 296700 in the DTD.
Ville's approach is more sane for the long term. We could also just add
a third check in the 4K audio fixup for the DTD based pixel clock.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
