There are a set of values in the drm_display_info structure for each
connector which hold information derived from EDID. These are computed
in drm_add_display_info. Before this patch, that was only called in
drm_add_edid_modes. This meant that they were only set when EDID was
present and never reset when EDID was not, as happened when the
display was disconnected.

One of these fields, non_desktop, is used from
drm_mode_connector_update_edid_property, the function responsible for
assigning the new edid value to the application-visible property.

Various drivers call these two functions (drm_add_edid_modes and
drm_mode_connector_update_edid_property) in different orders. This
means that even when EDID is present, the drm_display_info fields may
not have been computed at the time that
drm_mode_connector_update_edid_property used the non_desktop value to
set the non_desktop property.

I've added a public function (drm_reset_display_info) that resets the
drm_display_info field values to default values and then made the
drm_add_display_info function public. These two functions are now
called directly from drm_mode_connector_update_edid_property so that
the drm_display_info fields are always computed from the current EDID
information before being used in that function.

This means that the drm_display_info values are often computed twice,
once when the EDID property it set and a second time when EDID is used
to compute modes for the device. The alternative would be to uniformly
ensure that the values were computed once before being used, which
would require that all drivers reliably invoke the two paths in the
same order. The computation is inexpensive enough that it seems more
maintainable in the long term to simply compute them in both paths.

The API to drm_add_display_info has been changed so that it no longer
takes the set of edid-based quirks as a parameter. Rather, it now
computes those quirks itself and returns them for further use by
drm_add_edid_modes.

This patch also includes a number of 'const' additions caused by
drm_mode_connector_update_edid_property taking a 'const struct edid *'
parameter and wanting to pass that along to drm_add_display_info.

v2: after review by Daniel Vetter <daniel.vetter@ffwll.ch>

	Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and
	drm_add_display_info.

	Added FIXME in drm_mode_connector_update_edid_property about
	potentially merging that with drm_add_edid_modes to avoid
	the need for two driver calls.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171213084427.31199-1-keithp@keithp.com
(danvet: cherry picked from commit 12a889bf4bca ("drm: rework delayed
connector cleanup in connector_iter") from drm-misc-next since
functional conflict with changes in -next and we need to make sure
both have the right version and nothing gets lost.)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Apparently some sinks look at the YQ bits even when receiving RGB,
and they get somehow confused when they see a non-zero YQ value.
So we can't just blindly follow CEA-861-F and set YQ to match the
RGB range.

Unfortunately there is no good way to tell whether the sink
designer claims to have read CEA-861-F. The CEA extension block
revision number has generally been stuck at 3 since forever,
and even a very recently manufactured sink might be based on
an old design so the manufacturing date doesn't seem like
something we can use. In lieu of better information let's
follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.

The alternative would of course be to always set YQ=0. And if
we ever encounter a HDMI 2.0+ sink with this bug that's what
we'll probably have to do.

Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Neil Kownacki <njkkow@gmail.com>
Reported-by: NNeil Kownacki <njkkow@gmail.com>
Tested-by: NNeil Kownacki <njkkow@gmail.com>
Fixes: fcc8a22c ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108152504.12596-1-ville.syrjala@linux.intel.comAcked-by: NEric Anholt <eric@anholt.net>

Add drm_kms_helper.edid_firmware module parameter with param ops hooks
to set drm.edid_firmware instead, for backwards compatibility.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170918182003.22238-2-jani.nikula@intel.com

CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.

V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc_modes into this patch, where its used
    (Ville)
V5: Optimize function, if(conditions) not reqd (Ville)
V6: Rebase
V7: Rebase

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-8-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix sparse indentation warn]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
	- VIC for 4K modes for HDMI 1.4 sinks
	- S3D information for S3D modes
  As CEA-861-F has already defined VICs for 4K videomodes, this
  patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
  until the mode is 3D.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
	- Do not send VICs in both AVI-IF and HDMI-IF
	  send only one of it.
V4: Rebase
V5: Added r-b from Neil.
    Addressed review comments from Ville
    - Do not block HDMI vendor IF, instead check for VIC while
      handling AVI infoframes
V6: Rebase
V7: Rebase
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
  This structure will be used to save and indicate if sink
  supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
  reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
  in scdc structure
- If SCDC is present, checks if sink is capable of generating
  SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
  Thierry:
  - Fix typos in commit message and make abbreviation consistent
    across the commit message.
  - Change structure object name from hdmi_info -> hdmi
  - Fix typos and abbreviations in description of structure drm_hdmi_info
    end the description with a full stop.
  - Create a structure drm_scdc, and keep all information related to SCDC
    register set (supported, read request supported) etc in it.

  Ville:
  - Change rr -> read_request
  - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
    of HF-VSDB parsing can be kept in same function, in incremental
    patches.

V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Addressed review comments from Ville
  - Add clock rate calculations for 1/10 and 1/40 ratios
  - Remove leftovers from old patchset
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NJose Abreu <joabreu@synopsys.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com

Make the firmware loader more generic and generally useful.
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/1487344854-18777-2-git-send-email-jani.nikula@intel.com

HDMI 2.0 recommends that we set the Q bits in the AVI infoframe
even when the sink does not support quantization range selection (QS=0).
According to CEA-861 we can do that as long as the Q we send matches
the default quantization range for the mode.

Previously I think I had misread the spec as saying that you can't
send a non-zero Q at all when QS=0. But that's not what the spec
actually says.

v2: Fix typo in commit message (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

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>

drm_edid.h depends on hdmi.h on account of enum hdmi_picture_aspect,
so let's just include hdmi.h and drop some useless struct declarations.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

Add helper to allow users to retrieve the speaker allocations without
knowledge of the ELD structure.
Signed-off-by: NArnaud Pouliquen <arnaud.pouliquen@st.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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

Some were still left in drm_crtc.h. Also include drm_edid.h in the
rst files.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160831160913.12991-4-daniel.vetter@ffwll.ch

Push the ifdef to the drm_edid.h and create a stub, for the
DRM_LOAD_EDID_FIRMWARE=n case. This removes some clutter in
the code, making it more readable.
Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1461087638-16959-1-git-send-email-ezequiel@vanguardiasur.com.ar

To fill the audio infoframe it is required to identify the
connection type as DP or HDMI. This patch adds an API which
parses ELD and returns the display type connected.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

Add a function to find the start of the SADs in the ELD.  This
complements the helper to retrieve the SAD count.

[airlied: this fixes a build problem with the alsa eld helper
which required this].
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a function to find the start of the SADs in the ELD.  This
complements the helper to retrieve the SAD count.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add ELD versions according to HDA Specification v1.0a.

2 indicates version 2, which supports CEA_Ver 861D or below. Maximum
Baseline ELD size of 80 bytes (15 SAD count).

31 indicates an ELD that has been partially populated through
implementation specific mean of default programming before an external
graphics driver is loaded. Only the field that is called out as "canned"
field will be populated, and audio driver should ignore the non "canned"
field.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These are just taken from the DisplayID v1.3 spec, and the
DDC spec.

v2: use __packed (Jani)
Signed-off-by: NDave Airlie <airlied@redhat.com>

The drm_get_edid() function performs direct I2C accesses to read EDID
blocks, assuming that the monitor DDC interface is directly connected to
the I2C bus. It can't thus be used with HDMI encoders that control the
DDC bus and expose EDID blocks through a different interface.

Refactor drm_do_get_edid() to take a block read callback function
instead of an I2C adapter, and export it for direct use by drivers.

As in the general case the DDC bus is accessible by the kernel at the
I2C level, drivers must make all reasonable efforts to expose it as an
I2C adapter and use drm_get_edid() instead of abusing this function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In the interest of reducing magic numbers and having to cross check with
the specs all the time.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Check the HDMI cea block for deep color mode bits. If available,
assign the highest supported bpc for a hdmi display, corresponding
to the given deep color modes.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This adds a helper function to extract the speaker allocation
data block from the EDID.  This data block describes what speakers
are present on the display device.

v2: update per Ville Syrjälä's comments
v3: fix copy/paste typo in memory allocation
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NRafał Miłecki <zajec5@gmail.com>

This can then be used by DRM drivers to setup their vendor infoframes.

v2: Fix hmdi typo (Simon Farnsworth)
v3: Adapt to the hdmi_vendor_infoframe rename
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

Some devices (ATI/AMD cards) don't support passing ELD struct to the
hardware but just require filling specific registers and then the
hardware/firmware does the rest. In such cases we need to read the info
from SAD blocks and put them in the correct registers.

agd5f: note that the returned pointer needs to be kfreed as per
Christian's suggestion.

v2: fix warning
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add a generic helper to fill in an HDMI AVI infoframe with data
extracted from a DRM display mode.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

The new structs added in struct detailed_data_monitor_range must be
marked with packed attribute although the outer struct itself is
already marked as packed.  Otherwise these 7-bytes structs may be
aligned, and give the wrong position and size for the data.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Acked-by: NAdam Jackson <ajax@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>

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>

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>

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>

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

Smatch complained that we initialize 6 elements in add_detailed_modes()
but the timings[] array is declared with 5 elements.  Adam Jackson
verified that 6 is the correct number of timings.

On Mon, May 10, 2010 at 12:08:24PM -0400, Adam Jackson wrote:
> > >                 struct std_timing timings[5];
> > >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This decl is wrong, should be 6.  From the 1.4 spec:
>
> "Six additional Standard Timings may be listed as a display descriptor
> (tag #FAh)."
>
> The 1.3 spec is a little less explicit about it, but does show 6
> standard timing codes in the 0xFA detailed subblock, terminated by 0x0A
> in the 18th byte.  I don't have the docs for 1.2 or earlier, but we're
> paranoid enough about not adding broken timings that we should be fine.

This patch is basically a clean up, because timings[] is declared inside
a union and increasing the number of elements here doesn't change the
overall size of the union.
Signed-off-by: NDan Carpenter <error27@gmail.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>

Some servers hardcode an edid in rom so that they will
work properly with KVMs.  This is a port of the relevant
code from the ddx.

[airlied: reworked to validate edid at boot stage - and
remove special quirk, if there is a valid EDID in the BIOS rom
we'll just try and use it.]
Signed-off-by: NAlex Deucher <alexdeucher@gmail.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>