We need to initialize this to false, because the is_rb callback only
ever sets it to true.

Noticed while reading through the code.

Cc: stable@vger.kernel.org
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

6 bytes seems to be a reasonable default so far, but for the desperate
it's worth exposing this.

[airlied: change include to module.h for this]

Bugzilla: https://bugzilla.redhat.com/582559Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Entirely new class of fail for this one.  The detailed timings are for
normal CVT but the monitor really wanted CVT-R.

Bugzilla: http://bugzilla.redhat/com/516471Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

EDID vendor IDs are always 3 characters long (4 with the terminating
0).  It doesn't make any sense to have a (possibly 8-byte) pointer
to the ID string in the quirk structure.
Signed-off-by: NIan Pilcher <arequipeno@gmail.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Requiring the first byte of the EDID base block header to be 0 means we
don't fix up as many transfer errors as we could.  Instead have the
callers specify whether it's meant to be block 0 or not, and
conditionally run header fixup based on that.

Bugzilla: https://bugzilla.redhat.com/812890Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

HD panel (1366x768) found most commonly on laptops can't be represented
exactly in CVT/DMT expression, which leads to 1368x768 instead, because
1366 can't be divided by 8.

Add a hack to convert to 1366x768 manually as an exception.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Acked-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Reviewed-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
continuous frequency", and moves the set of supported timing formulas
into the range descriptor itself.  In any event, the range descriptor
can act as a filter on the DMT list without regard to a specific timing
formula.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Slightly more honest naming.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

mode_in_range() handles what this was warning about.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It won't find any, yet.  Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code.  This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

No functional change, but will make an upcoming change clearer.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The CEA extension block has a field which describes which YCbCr modes are
supported by the device, use it to fill the drm_display_info color_formats
fields. Also the existence of a CEA extension block is used as indication
that the device supports RGB.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The code should obviously check the EDID feature field for EDID feature flags
and not the color_formats field of the drm_display_info struct. Also update the
color_formats field with new modes instead of overwriting the current mode.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It's already defined in drm_edid.h.
Signed-off-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Broken monitors and/or broken graphic boards may send erroneous or no
EDID data. This also applies to broken KVM devices that are unable to
correctly forward the EDID data of the connected monitor but invent
their own fantasy data.

This patch allows to specify an EDID data set to be used instead of
probing the monitor for it. It contains built-in data sets of frequently
used screen resolutions. In addition, a particular EDID data set may be
provided in the /lib/firmware directory and loaded via the firmware
interface. The name is passed to the kernel as module parameter of the
drm_kms_helper module either when loaded
  options drm_kms_helper edid_firmware=edid/1280x1024.bin
or as kernel commandline parameter
  drm_kms_helper.edid_firmware=edid/1280x1024.bin

It is also possible to restrict the usage of a specified EDID data set
to a particular connector. This is done by prepending the name of the
connector to the name of the EDID data set using the syntax
  edid_firmware=[<connector>:]<edid>
such as, for example,
  edid_firmware=DVI-I-1:edid/1920x1080.bin
in which case no other connector will be affected.

The built-in data sets are
Resolution    Name
--------------------------------
1024x768      edid/1024x768.bin
1280x1024     edid/1280x1024.bin
1680x1050     edid/1680x1050.bin
1920x1080     edid/1920x1080.bin

They are ignored, if a file with the same name is available in the
/lib/firmware directory.

The built-in EDID data sets are based on standard timings that may not
apply to a particular monitor and even crash it. Ideally, EDID data of
the connected monitor should be used. They may be obtained through the
drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is even possible to specify the name of an EDID data set on-the-fly
via the /sys/module interface, e.g.
echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
The new screen mode is considered when the related kernel function is
called for the first time after the change. Such calls are made when the
X server is started or when the display settings dialog is opened in an
already running X server.
Signed-off-by: NCarsten Emde <C.Emde@osadl.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

to add the missing drm_mode_object_put for that mode.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.

Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.

This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
and improve overall edid detection timing by 10-30% in most cases, and by
a much larger margin in case of phantom outputs (up to 30x in one worst
case).

Timing results for i915-powered machines for 'time xrandr' command:
Machine 1: from 0.840s to 0.290s
Machine 2: from 0.315s to 0.280s
Machine 3: from +/- 4s to 0.184s

Timing results for HD5770 with 'time xrandr' command:
Machine 4: from 3.210s to 1.060s
Reviewed-by: NChris Wilson <chris@hchris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Tested-by: NSean Finney <seanius@seanius.net>
Tested-by: NSoren Hansen <soren@linux2go.dk>
Tested-by: NHernando Torque <sirius@sonnenkinder.org>
Tested-by: NMike Lothian <mike@fireburn.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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>