[Intel-gfx] [PATCH 1/3] drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings

[Jani Nikula]

On Mon, 19 Oct 2015, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Fri, Oct 09, 2015 at 01:54:58PM +0300, Jani Nikula wrote:
>> On Thu, 08 Oct 2015, Daniel Vetter <daniel at ffwll.ch> 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 at linux.intel.com wrote:
>> >> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>> >> > 
>> >> > 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 at redhat.com>
>> >
>> > 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