From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 69675] audio broken in 24Hz/24p since 3.11 (regression) Date: Thu, 31 Oct 2013 20:38:10 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1895815606==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id AADCBEFF73 for ; Thu, 31 Oct 2013 13:38:10 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1895815606== Content-Type: multipart/alternative; boundary="1383251890.e4252.9177"; charset="us-ascii" --1383251890.e4252.9177 Date: Thu, 31 Oct 2013 20:38:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #29 from Anssi Hannula --- > Use the driver calculated CTS and N values rather than > having hardware generate them. This allows us to use > the modeline pixel clock rather than the actual pll clock > when setting up the dto for audio. Fixes problems with > audio playback rate on certain asics if the pll clock > does not match the pixel clock exactly. Hm, so actual problems were confirmed fixed with this? That seems rather strange, since that would mean the hardware counted the clock cycles wrong for the CTS value... Maybe the HW doesn't do it per-spec, instead calculating CTS in some other way? -- You are receiving this mail because: You are the assignee for the bug. --1383251890.e4252.9177 Date: Thu, 31 Oct 2013 20:38:10 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 29 on bug 69675 from 
> Use the driver calculated CTS and N values rather than
> having hardware generate them.  This allows us to use
> the modeline pixel clock rather than the actual pll clock
> when setting up the dto for audio.  Fixes problems with
> audio playback rate on certain asics if the pll clock
> does not match the pixel clock exactly.

Hm, so actual problems were confirmed fixed with this? That seems rather
strange, since that would mean the hardware counted the clock cycles wrong for
the CTS value... Maybe the HW doesn't do it per-spec, instead calculating CTS
in some other way?

You are receiving this mail because:
  • You are the assignee for the bug.
--1383251890.e4252.9177-- --===============1895815606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1895815606==--