The current logic misunderstands the spec about CEA 18byte descriptors.
First, the spec doesn't state "detailed timing descriptors" but "18 byte
descriptors", so any data record could be stored, mixed timings and
other data, just as in the standard EDID.
Second, the lower four bit of byte 3 of the CEA record do not contain
the number of descriptors, but "the total number of DTDs defining native
formats in the whole EDID [...], starting with the first DTD in the DTD
list (which starts in the base EDID block)." A device can of course
support non-native formats.

As such the number can't be used to determine n, and the existing code
will filter non-timing 18byte descriptors anyway.
Signed-off-by: NChristian Schmidt <schmidt@digadd.de>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

CEA datablocks are only defined from revision 3 onwards. Only check for
them if the revision says so.
Signed-of-by: NChristian Schmidt <schmidt@digadd.de>
Tested-by: NJames Cloos <cloos@jhcloos.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

TFT/plasma televisions and projectors have become commonplace, and so
has the use of PCs to drive them. Add the video modes specified by an
EDID's CEA extension to the mode database for a connector.

Before:
[    1.158869] [drm:drm_mode_debug_printmodeline], Modeline
19:"1920x1080i" 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15
[    1.158875] [drm:drm_mode_debug_printmodeline], Modeline
18:"1920x1080i" 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x48 0x15
[    1.158882] [drm:drm_mode_debug_printmodeline], Modeline
20:"1920x1080" 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5

After:
[    1.144175] [drm:drm_mode_debug_printmodeline], Modeline
22:"1920x1080" 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15
[    1.144179] [drm:drm_mode_debug_printmodeline], Modeline
21:"1920x1080" 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x48 0x15
[    1.144187] [drm:drm_mode_debug_printmodeline], Modeline
30:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
[    1.144190] [drm:drm_mode_debug_printmodeline], Modeline
29:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[    1.144192] [drm:drm_mode_debug_printmodeline], Modeline
25:"1920x1080" 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5
[    1.144195] [drm:drm_mode_debug_printmodeline], Modeline
24:"1280x720" 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5
[    1.144198] [drm:drm_mode_debug_printmodeline], Modeline
23:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[    1.144201] [drm:drm_mode_debug_printmodeline], Modeline 27:"720x576"
50 27000 720 732 796 864 576 581 586 625 0x40 0xa
[    1.144203] [drm:drm_mode_debug_printmodeline], Modeline 26:"720x480"
60 27000 720 736 798 858 480 489 495 525 0x40 0xa
[    1.144206] [drm:drm_mode_debug_printmodeline], Modeline 28:"640x480"
60 25175 640 656 752 800 480 490 492 525 0x40 0xa
Signed-off-by: NChristian Schmidt <schmidt@digadd.de>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor.

This adds drm_edid_to_eld() for converting EDID to ELD. The converted
ELD will be saved in a new drm_connector.eld[128] data field. This is
necessary because the graphics driver will need to fixup some of the
data fields (eg. HDMI/DP connection type, AV sync delay) before writing
to the hardware ELD buffer. drm_av_sync_delay() will help the graphics
drivers dynamically compute the AV sync delay for fixing-up the ELD.

ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be returned by drm_select_eld(). This policy may not be
suitable for all users, but let's start it simple first.

The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor.

According to James, many TVs will either refuse the display anything or
pop-up an OSD warning whenever they receive hdmi audio which they cannot
handle. Eventually we will require configurability and/or per-monitor
audio control even when the video is cloned.

CC: Zhao Yakui <yakui.zhao@intel.com>
CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
CC: Jeremy Bush <contractfrombelow@gmail.com>
CC: Christopher White <c.white@pulseforce.com>
CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
CC: Paul Menzel <paulepanter@users.sourceforge.net>
CC: James Cloos <cloos@jhcloos.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

    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>