Russell, On Sat, Sep 5, 2015 at 1:34 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote: >> Then perhaps you shouldn't be using a switch statement. You won't >> catch all values that are within .05% of (25.2 / 1.001). > > No. > > The clock rates you get ultimately come from the EDID via either the > detailed timing modes or from the CEA mode IDs, which are then looked > up in tables in the DRM EDID parsing code. I guess in my case the (non-upsteram) code is adjusting the clock in fixup_mode. It's no longer something based on the EDID. Perhaps the fault if there, but... > Either way, you will end up with 25175 and not 25170 or something > strange based on what the platform does. I was talking to someone else about this and I guess the question is whether you should be sending a N/CTS for audio based on the theoretical or the actual clock. If you are supposed to do calculations based on the theoretical clock then you're right. If you are supposed to do calculations based on the actual clock then I'm not so sure. Note that: * I believe that you'll get better audio if you use the actual clock. * If your actual clock is an integral number of kHz, the calculations are simpler by using the actual clock. -Doug _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
