On Mon, 19 Oct 2015, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, Oct 09, 2015 at 01:54:58PM +0300, Jani Nikula wrote: >> On Thu, 08 Oct 2015, Daniel Vetter <daniel@xxxxxxxx> wrote: >> > On Thu, Oct 08, 2015 at 12:22:31PM -0400, Adam Jackson wrote: >> >> On Thu, 2015-10-08 at 11:43 +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote: >> >> > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >> >> > >> >> > EDID detailed timings have a resolution of 10kHz for the pixel clock, so >> >> > they can't represent certain CEA/HDMI modes accurately. If we see a mode >> >> > coming in via detailed timings which otherwise matches one of the >> >> > CEA/HDMI modes except the clock is just a bit off, let's assume that the >> >> > intention was for that mode to be one of the CEA/HDMI modes and go ahead >> >> > and fix up the clock to match the CEA/HDMI spec exactly (well, as close >> >> > as we can get with the 1 kHz resolution we use). >> >> > >> >> > This should help code that's looking for an exact clock match (eg. i915 >> >> > audio N/CTS setup). >> >> >> >> Looks like a sane set of changes. Series is: >> >> >> >> Reviewed-by: Adam Jackson <ajax@xxxxxxxxxx> >> > >> > Merged the first two patches to drm-misc (the later one has conflicts with >> > the lack of drm-intel-next, so can pull it in only after a rebase). >> >> This is needed in v4.3. > > Ok, after first dropping them I now reapplied them again for 4.4. > Hopefully we're converging on this here now wrt maintainer fumbles ;-) Yeah, apologies, my bad. I thought we needed them to fix an issue in our 4k HDMI audio, but we haven't introduced the issue to v4.3 yet. BR, Jani. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
