Provides function drm_edid_header_is_valid() for EDID header check
    and replaces EDID header check part of function drm_edid_block_valid()
    by a call of drm_edid_header_is_valid().
    This is a prerequisite to extend DDC probing, e. g. in function
    radeon_ddc_probe() for Radeon devices, by a central EDID header check.

    Tested for kernel 2.6.35, 2.6.38 and 3.0

Cc: <stable@kernel.org>
Signed-off-by: NThomas Reim <reimth@gmail.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Acked-by: NStephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Drivers need to know the CEA version number in addition to other display
info (like whether the display is an HDMI sink) before enabling certain
features.  So track the CEA version number in the display info
structure.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Also disable the ascii dump and remove the literal printing of the
KERN_ERR macro in the log:

   [drm:drm_edid_block_valid] *ERROR* Raw EDID:
   <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

v2: Remove the trailing empty line as well.
Signed-off-by: NTormod Volden <debian.tormod@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some RS690 chipsets seem to end up with floating connectors, either
a DVI connector isn't actually populated, or an add-in HDMI card
is available but not installed. In this case we seem to get a NULL byte
response for each byte of the i2c transaction, so we detect this
case and if we see it we don't do anymore DDC transactions on this
connector.

I've tested this on my RS690 without the HDMI card installed and
it seems to work fine.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>

this puts the header and followup at the same loglevel as the
hex dump code.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>

EDID 1.4 digital displays report the color spaces they support in the
features block.  Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

EDID 1.4 digital monitors report the bit depth supported in the input
field.  Add support for parsing this out and storing the info in the
display_info structure for use by drivers.

[airlied: tweaked to fix inter-patch dependency]
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Nouveau needs access to this structure to build an ELD block for use
by the HDA audio codec.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Usually EDID retrieval is fine. However, sometimes, especially when the
machine is loaded, it fails, but succeeds after a few retries.

Based on a patch by Michael Buesch.
Reported-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

... and fixup some methods to accept the constant argument.

Now that constant module arrays are loaded into read-only memory, using
const appropriately has some benefits beyond warning the programmer
about likely mistakes.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently an invalid EDID extension will cause the whole EDID to be considered invalid. Instead just drop the invalid extensions, and return the valid ones. The base block is modified to claim to have the number valid extensions, and the check sum is updated.

For my EIZO S2242W the base block is fine, but the extension block is all zeros. Without this patch I get no X and no VTs.
Signed-off-by: NSam Tygier <samtygier@yahoo.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.
Tested-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC (and for other forms of auxiliary communication with external
display controllers). The hope is that this method will be much faster
and more reliable than bit banging for fetching EDIDs from buggy monitors
or through switches, though we still preserve the bit banging as a
fallback in case GMBUS fails.

Based on an original patch by Jesse Barnes.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... of the code, not of the mode lists.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This brings us in line with the EDID spec recommendation for mode
priority sorting.  We still don't extract all the modes we could from
VTB, but VTB is so rare in the wild that I'm not really concerned.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We're adjusting horizontal timings only here, moving vsync was just a
slavish translation of a typo in the X server.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Allow platform devices without PCI resources to be DRM devices.

[airlied: fixup warnings with dev pointers]
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Switches will try to update the topology address and not correctly fix
up the checksum, so just let it slide.

https://bugs.freedesktop.org/28229Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Spotted by Scott Bertilson.
Fixes fdo bug 28146.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NMark Marshall <mark.marshall@csr.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Simple cloning rules compared to server:
(a) single crtc
(b) > 1 connector active
(c) check command line mode
(d) try and find 1024x768 DMT mode if no command line.
(e) fail to clone
Signed-off-by: NDave Airlie <airlied@redhat.com>

m == num_est3_modes is one past the end of the est3_modes[].
Signed-off-by: NDan Carpenter <error27@gmail.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Having hsync both start and end on pixel 1072 ain't gonna work very
well.  Matches the X server's list.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-By: NMichael Tokarev <mjt@tls.msk.ru>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

We don't use timing_level any more after: 9cf00977 "drm/edid: Unify
detailed block parsing between base and extension blocks".
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

... and not the global list.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Claims 1280x1024 preferred, physically 1600x1200

cf. http://bugzilla.redhat.com/530399Signed-off-by: NAdam Jackson <ajax@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Height in frame size, not field size, and trailed with an 'i'.  Matches
the X server behaviour.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Before CVT-R, some monitors would advertise support for an alternative
GTF formula with lower blanking intervals.  Correctly identify such
monitors, and use the alternative formula when generating modes for
them.

Note that we only do this for "standard" timing descriptors (tuples of
hsize in characters / aspect ratio / vertical refresh).  Range-based
mode lists still only refer to the primary GTF curve.  It would be
possible to do better for the latter case, but monitors are required to
support the primary curve over the entire advertised range, so all it
would win you is a lower pixel clock and therefore possibly better image
quality on analog links.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If you have 1920x1200 in both detailed (probably RB) and standard
variants, you probably only want the RB version.  But we have no way of
guessing that from standard mode parse.  So, if a mode already exists
for a given w/h/r, skip adding it.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Standard timings don't let you say 1366.  Both 1360 and 1368 have been
seen in the wild.  So invent a CVT timing for it.  CVT will round 1366 up
to 1368; we'll then manually underscan it.

Split this into two parts, since we need to do something sneaky between
them in the future.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

1.4 adds better pixel clock precision, explicit reduced blanking
awareness, and extended sync ranges.  It's almost like a real spec.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The generic block walk callback looks like overkill, but we'll need it
for other detailed block walks in the future.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In 1.4, the first detailed mode is always the preferred mode.  The bit
that used to mean that, now means "this mode is the physical size in
pixels".
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Also, document what the spec says to do.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>