Pull the logic to populate the quantization range information
in the AVI infoframe into a small helper. We'll be adding a bit
more logic to it, and having it in a central place seems like a
good idea since it's based on the CEA-861 spec.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

Make the code selecting the RGB quantization range a little less magicy
by wrapping it up in a small helper.

v2: s/adjusted_mode/mode in vc4 to make it actually compile
v3: Add a comment proposed by Eric
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111141835.25369-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

No reason not to be const.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1482923186-22430-1-git-send-email-jani.nikula@intel.com

<drm/drm_crtc.h> used to define most of the in-kernel KMS API. It has
now been split into separate files for each object type, but still
includes most other KMS headers to avoid breaking driver compilation.

As a step towards fixing that problem, remove the inclusion of
<drm/drm_encoder.h> from <drm/drm_crtc.h> and include it instead where
appropriate. Also remove the forward declarations of the drm_encoder and
drm_encoder_helper_funcs structures from <drm/drm_crtc.h> as they're not
needed in the header.

<drm/drm_encoder.h> now has to include <drm/drm_mode.h> and contain a
forward declaration of struct drm_encoder in order to allow including it
as the first header in a compilation unit.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sinclair Yeh <syeh@vmware.com> # For vmwgfx
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com

CEA-861 specifies that the vertical front porch may vary by one or two
lines for specific VICs. Up to now we've only considered a mode to match
the VIC if it matched the shortest possible vertical front porch length
(as that is the variant we store in cea_modes[]). Let's allow our VIC
matching to work with the other timings variants as well so that that
we'll send out the correct VIC if the variant actually used isn't the
one with the shortest vertical front porch.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAndrzej Hajda <a.hajda@samsung.com>

The only user was i915, which is now gone.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@redhat.com> #irc
Cc: dri-devel@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/1478609742-13603-9-git-send-email-maarten.lankhorst@linux.intel.com

All the VICs apart from 58 and 59 have the word "Hz" included in the
comment. Include it for 59 and 59 as well.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-1-git-send-email-ville.syrjala@linux.intel.com

Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
intermediate edid reads. This causes transient failures in CI which
flags up the sporadic EDID read failures, which are recovered by
rereading the EDID automatically. This patch combines the reporting done
by drm_do_get_edid() itself with the bad block printing from
get_edid_block(), into a single warning associated with the connector
once all attempts to retrieve the EDID fail.

v2: Print the whole EDID, marking up the bad/zero blocks. This requires
recording the whole of the raw edid, then a second pass to reduce it to
the valid extensions.
v3: Fix invalid/valid extension fumble.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161024113821.26263-1-chris@chris-wilson.co.uk

Now that we have the name "block" free once more, we can use it to point
to the start of a block within the edid.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161017083514.21772-2-chris@chris-wilson.co.uk

The "block" variable points to the entire edid, not individual blocks
despite it being named such.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161017083514.21772-1-chris@chris-wilson.co.uk

drm_edid_to_eld() is just mean to cook up the ELD for the audio driver,
so having it parse non-audio related stuff seems just wrong, and
potentially could lead to that information not being even filled out
if the function doesn't even get called. Let's move that stuff to the
place where we parse the color formats and whatnot from the CEA ext
block.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-9-git-send-email-ville.syrjala@linux.intel.com

It's not a good idea to leave stale cea_rev in the drm_display_info. The
current EDID might not even have a CEA ext block in which case we'd end
up leaving the stale value in place.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-8-git-send-email-ville.syrjala@linux.intel.com

Instead of parsing parts of the CEA extension block in two places
to determine supported color formats and whatnot, let's just
consolidate it to one function. This also makes it possible to neatly
flatten drm_assign_hdmi_deep_color_info().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-7-git-send-email-ville.syrjala@linux.intel.com

We already pass the connector to drm_add_display_info() and
drm_assign_hdmi_deep_color_info(), so passing the
connector->display_info also is pointless.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-6-git-send-email-ville.syrjala@linux.intel.com

We have the drm_display_info for storing information about the sink, so
let's move dvi_dual and max_tmds_clock in there.

v2: Deal with superfluous code shuffling
    Document dvi_dual and max_tmds_clock too

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-5-git-send-email-ville.syrjala@linux.intel.com

We generally store clocks in kHz, so let's do that for the
HDMI max TMDS clock value as well. Less surpising.

v2: Deal with superfluous code shuffling

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-4-git-send-email-ville.syrjala@linux.intel.com

Clear out old max_tmds_clock and dvi_dual information (possibly from a
previous EDID) before parsing the current EDID. Tne current EDID might
not even have these in its HDMI VSDB, which would mean that we'd leave
the old stale values in place.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-3-git-send-email-ville.syrjala@linux.intel.com

Clear out stale audio latency information (potentially from a previous
EDID) before constructing the ELD from the EDID.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-2-git-send-email-ville.syrjala@linux.intel.com

  In the CEA-861 specification VIC 64 specifies a vsync pulse of 5 and
a backporch of 36. Adjust vsync pulse width to match specification.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NClint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1471282288-30909-1-git-send-email-clinton.a.taylor@intel.com

We seem to have a bit a mess in how to describe the bus formats, with
a multitude of competing ways. Might be best to consolidate it all and
use MEDIA_BUS_FMT_ also for the hdmi color formats and high color
modes.

Also move all the display_info related functions into drm_connector.c
(there's only one) to group it all together. I did decided against
also moving the edid related display info functions, they seem to fit
better in drm_edid.c. Instead sprinkle a few cross references around.
While at that reduce the kerneldoc for static functions, there's not
point in documenting internals with that much detail really.

v2: Fix typo and move misplaced hunk (Sean).

Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-19-git-send-email-daniel.vetter@ffwll.ch

According to E-EDID spec 1.3, table 3.9, a digital video sink with the
"DFP 1.x compliant TMDS" bit set is "signal compatible with VESA DFP 1.x
TMDS CRGB, 1 pixel / clock, up to 8 bits / color MSB aligned".

For such displays, the DFP spec 1.0, section 3.10 "EDID support" says:

"If the DFP monitor only supports EDID 1.X (1.1, 1.2, etc.)
 without extensions, the host will make the following assumptions:

 1. 24-bit MSB-aligned RGB TFT
 2. DE polarity is active high
 3. H and V syncs are active high
 4. Established CRT timings will be used
 5. Dithering will not be enabled on the host"

So if we don't know the bit depth of the display from additional
colorimetry info we should assume 8 bpc / 24 bpp by default.

This patch adds info->bpc = 8 assignement for that case.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
reports that the "AEO model 0" display is driven with 8 bpc
without dithering by default, which looks bad because that
panel is apparently a 6 bpc DP panel with faulty EDID.

A fix for this was made by commit 013dd9e0
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").

That commit triggers new regressions in precision for DP->DVI and
DP->VGA displays. A patch is out to revert that commit, but it will
revert video output for the AEO model 0 panel to 8 bpc without
dithering.

The EDID 1.3 of that panel, as decoded from the xrandr output
attached to that bugzilla bug report, is somewhat faulty, and beyond
other problems also sets the "DFP 1.x compliant TMDS" bit, which
according to DFP spec means to drive the panel with 8 bpc and
no dithering in absence of other colorimetry information.

Try to make the original bug reporter happy despite the
faulty EDID by adding a quirk to mark that panel as 6 bpc,
so 6 bpc output with dithering creates a nice picture.

Tested by injecting the edid from the fdo bug into a DP connector
via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
is selected.

This patch should be backported to stable.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The tiled 5K Dell monitor appears to be hiding it's tiled mode
inside the displayid timings block, this patch parses this
blocks and adds the modes to the modelist.

v1.1: add missing __packed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95207Signed-off-by: NDave Airlie <airlied@redhat.com>

We need to use this for validating modeline additions.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This will iterate over all DisplayID blocks found in the buffer.
Previously only the first block was parsed.

https://bugs.freedesktop.org/show_bug.cgi?id=95207Signed-off-by: NTomas Bzatek <tomas@bzatek.net>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This just makes the code easier to follow.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In order to include monitor name information in debugfs
output we needed to add a function that would extract the
monitor name from the EDID, and that function needed to
reside in the file  where the rest of the EDID helper
functions are implemented.

v2: Refactor to have drm_edid_get_monitor_name() and drm_edid_to_eld()
    use a common helper function to extract the monitor name from the
    edid. [Jani] + rebase.

v3: Minor changes suggested by Jani + rebase.

v4: Few more minor changes suggested by Jani + rebase.

cc: dri-devel@lists.freedesktop.org
cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJim Bride <jim.bride@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-1-git-send-email-jim.bride@linux.intel.com

One of the VESA DMT timings in drm_dmt_modes[] is slightly off.
1024x768@43Hz (interlaced) vsync_end should be 776, not 772.
This brings it into line with the identical timings in edid_est_modes[].
Signed-off-by: NPaul Parsons <lost.distance@yahoo.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160404193639.8631D6E66B@gabe.freedesktop.org

The EDID 1.4 specification section 3.10.3.9 defines an Established Timings III
descriptor (tag #F7h). The parsing of this descriptor by drm_est3_modes() is
off by one byte: the offset of the first timing bitmap is 6, not 5.
Signed-off-by: NPaul Parsons <lost.distance@yahoo.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160328002258.E75DF6E35D@gabe.freedesktop.org

Three of the VESA DMT timings in edid_est_modes[] are slightly off.
1. 640x480@72Hz vsync_end should be 492, not 491.
2. 640x480@60Hz clock should be 25175, not 25200.
3. 1024x768@75Hz clock should be 78750, not 78800.
This patch corrects those timings per the VESA DMT specification, and
thus brings them into line with the identical timings in drm_dmt_modes[].
Signed-off-by: NPaul Parsons <lost.distance@yahoo.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160402100817.B60776E23A@gabe.freedesktop.org

SADs may span multiple CEA audio data blocks in the EDID.

CEA-861-E says:
"The order of the Data Blocks is not constrained. It is also possible
to have more than one of a specific type of data block if necessary to
include all of the descriptors needed to describe the sink’s capabilities."

Each audio data block can carry up to 10 SADs, whereas the ELD SAD limit
is 15 according to HDA 1.0a spec. So we should support at least two data
blocks. And apparently some devices take a more liberal interpretation
and stuff only one SAD per data block even when they would fit into one.

So let's try to extract all the SADs we can fit into the ELD even when
they span multiple data blocks.

While at it, toss in a comment to explain the 13 byte monitor name
string limit which confused me at first.

Cc: Arturo Pérez <artur999555@gmail.com>
Tested-by: NArturo Pérez <artur999555@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94197Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457554066-8739-1-git-send-email-ville.syrjala@linux.intel.com

Originally by Seth Forshee <seth.forshee@canonical.com>, 2012-10-04:
    Some dual graphics machines support muxing the DDC separately from
    the display, so make use of this functionality when reading the EDID
    on the inactive GPU. Also serialize drm_get_edid() with a mutex to
    avoid races on the DDC mux state.

Modified by Dave Airlie <airlied@gmail.com>, 2012-12-22:
    I can't figure out why I didn't like this, but I rewrote this [...]
    to lock/unlock the ddc lines [...]. I think I'd prefer something
    like that otherwise the interface got really ugly.

Modified by Lukas Wunner <lukas@wunner.de>, 2015-04 - 2015-09:
    v3:   Move vga_switcheroo calls to a wrapper around drm_get_edid()
          which drivers can call on muxed machines. This avoids other
          drivers having to go through the vga_switcheroo motions even
          though they are never used on a muxed platform
          (Thierry Reding, Daniel Vetter, Alex Deucher)

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by: NPierre Moreau <pierre.morrow@free.fr>
    [MBP  5,3 2009  nvidia MCP79 + G96        pre-retina  15"]
Tested-by: NWilliam Brown <william@blackhats.net.au>
    [MBP  8,2 2011  intel SNB + amd turks     pre-retina  15"]
Tested-by: NLukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/b898d0da4c134f2642d0122479006863e1830723.1452525860.git.lukas@wunner.de

Add a dummy entry to CEA/HDMI mode tables so they can be indexed
directly using the VIC, avoiding a +1/-1 dance here and there. This adds
clarity to the error checking for various functions that return the VIC
on success and zero on failure; we can now explicitly check for 0
instead of just subtracting one from an unsigned type.

Also add drm_valid_cea_vic() and drm_valid_hdmi_vic() helpers for
checking valid VICs.

v2: add drm_valid_cea_vic and drm_valid_hdmi_vic helpers (Ville)
    use { } instead of { 0 } for initializing the dummy modes

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452252111-6439-1-git-send-email-jani.nikula@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rather than using drm_match_cea_mode() to see if the EDID detailed
timings are supposed to represent one of the CEA/HDMI modes, add a
special version of that function that takes in an explicit clock
tolerance value (in kHz). When looking at the detailed timings specify
the tolerance as 5kHz due to the 10kHz clock resolution limit inherent
in detailed timings.

drm_match_cea_mode() uses the normal KHZ2PICOS() matching of clocks,
which only allows smaller errors for lower clocks (eg. for 25200 it
won't allow any error) and a bigger error for higher clocks (eg. for
297000 it actually matches 296913-297000). So it doesn't really match
what we want for the fixup. Using the explicit +-5kHz is much better
for this use case.

Not sure if we should change the normal mode matching to also use
something else besides KHZ2PICOS() since it allows a different
proportion of error depending on the clock. I believe VESA CVT
allows a maximum deviation of .5%, so using that for normal mode
matching might be a good idea?

Cc: Adam Jackson <ajax@redhat.com>
Tested-by: nathan.d.ciobanu@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92217
Fixes: fa3a7340 ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rounding to the closest kHz seems like the better option that round
down or up when computing the alternate clock for CEA/HDMI modes.
It'll give us a slightly more accurate clock in some cases.

Not sure why I went for the down+up approach originally. Perhaps
I was thinking we can go back and forth betwen the two frequencies
without introducing errors, but round to closest still maintains
that property.

Cc: Adam Jackson <ajax@redhat.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Libin Yang <libin.yang@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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).

Cc: Adam Jackson <ajax@redhat.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Libin Yang <libin.yang@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_av_sync_delay() doesn't change the passed in mode, so make it const.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_select_eld() doesn't look at the passed in mode, so don't pass it
in.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

valid_inferred_mode() don't change the modes over which it iterates,
so make the iterator const.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Spotted while reading code for random reasons.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>