History log of /linux-master/drivers/gpu/drm/drm_edid.c
Revision Date Author Comments
# cbe7cea7 10-Jan-2024 chenxuebing <chenxb_99091@126.com>

drm/edid: Clean up errors in drm_edid.c

Fix the following errors reported by checkpatch:

ERROR: do not use assignment in if condition

Signed-off-by: chenxuebing <chenxb_99091@126.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240111063921.8701-1-chenxb_99091@126.com


# 5343f29b 02-Jan-2024 Javier Martinez Canillas <javierm@redhat.com>

drm: Move drm_set_preferred_mode() helper from drm_edid to drm_modes

The helper is generic, it doesn't use the opaque EDID type struct drm_edid
and is also used by drivers that only support non-probeable displays such
as fixed panels.

These drivers add a list of modes using drm_mode_probed_add() and then set
a preferred mode using the drm_set_preferred_mode() helper.

It seems more logical to have the helper definition in drm_modes.o instead
of drm_edid.o, since the former contains modes helper while the latter has
helpers to manage the EDID information.

Since both drm_edid.o and drm_modes.o object files are built-in the drm.o
object, there are no functional changes. But besides being a more logical
place for this helper, it could also allow to eventually make drm_edid.o
optional and not included in drm.o if only fixed panels must be supported
in a given system.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240102122208.3103597-1-javierm@redhat.com


# 8af46811 30-Oct-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: add helpers to get/set struct cea_sad from/to 3-byte sad

Add helpers to pack/unpack SADs. Both ways and non-static, as follow-up
work needs them.

v2: Add include to get the declarations

Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/21d657ca854ce26423b461c0bb71e7a0727ba437.1698747331.git.jani.nikula@intel.com


# e8d0b2c0 30-Oct-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: use a temp variable for sads to drop one level of dereferences

Use a temporary variable struct cea_sad *, instead of using struct
cea_sad ** directly with the double dereferences. It's arguably easier
on the eyes, and drops a set of parenthesis too.

Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b6e2f295ae5491c2bb0f528508f0f5fca921dc77.1698747331.git.jani.nikula@intel.com


# 439590ac 30-Oct-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: include drm_eld.h only where required

Reduce the dependencies on drm_eld.h. Some files might be able to drop
the dependency on drm_edid.h too with the direct inclusion of drm_eld.h.

Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9f5963ce900d747f3279312c0cd1da599fd83f94.1698747331.git.jani.nikula@intel.com


# 759f14e2 07-Dec-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: also call add modes in EDID connector update fallback

When the separate add modes call was added back in commit c533b5167c7e
("drm/edid: add separate drm_edid_connector_add_modes()"), it failed to
address drm_edid_override_connector_update(). Also call add modes there.

Reported-by: bbaa <bbaa@bbaa.fun>
Closes: https://lore.kernel.org/r/930E9B4C7D91FDFF+29b34d89-8658-4910-966a-c772f320ea03@bbaa.fun
Fixes: c533b5167c7e ("drm/edid: add separate drm_edid_connector_add_modes()")
Cc: <stable@vger.kernel.org> # v6.3+
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231207093821.2654267-1-jani.nikula@intel.com


# 2682768b 20-Sep-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fixup h/vsync_end instead of h/vtotal

There are some weird EDIDs floating around that have the sync
pulse extending beyond the end of the blanking period.

On the currently problemtic machine (HP Omni 120) EDID reports
the following mode:
"1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5
which is then "corrected" to have htotal=1861 by the current drm_edid.c
code.

The fixup code was originally added in commit 7064fef56369 ("drm: work
around EDIDs with bad htotal/vtotal values"). Googling around we end up in
https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/297245
where we find an EDID for a Dell Studio 15, which reports:
(II) VESA(0): clock: 65.0 MHz Image Size: 331 x 207 mm
(II) VESA(0): h_active: 1280 h_sync: 1328 h_sync_end 1360 h_blank_end 1337 h_border: 0
(II) VESA(0): v_active: 800 v_sync: 803 v_sync_end 809 v_blanking: 810 v_border: 0

Note that if we use the hblank size (as opposed of the hsync_end)
from the DTD to determine htotal we get exactly 60Hz refresh rate in
both cases, whereas using hsync_end to determine htotal we get a
slightly lower refresh rates. This makes me believe the using the
hblank size is what was intended even in those cases.

Also note that in case of the HP Onmi 120 the VBIOS boots with these:
crtc timings: 108000 1600 1780 1860 1800 900 910 913 1000, type: 0x40 flags: 0x5
ie. it just blindly stuffs the bogus hsync_end and htotal from the DTD
into the transcoder timing registers, and the display works. I believe
the (at least more modern) hardware will automagically terminate the hsync
pulse when the timing generator reaches htotal, which again points that we
should use the hblank size to determine htotal. Unfortunatley the old bug
reports for the Dell machines are extremely lacking in useful details so
we have no idea what kind of timings the VBIOS programmed into the
hardware :(

Let's just flip this quirk around and reduce the length of the sync
pulse instead of extending the blanking period. This at least seems
to be the correct thing to do on more modern hardware. And if any
issues crop up on older hardware we need to debug them properly.

v2: Add debug message breadcrumbs (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8895
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230920211934.14920-1-ville.syrjala@linux.intel.com


# 82b599ec 24-Aug-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: parse source physical address

CEC needs the source physical address. Parsing it is trivial with the
existing EDID CEA DB infrastructure.

Default to CEC_PHYS_ADDR_INVALID (0xffff) instead of 0 to cater for
easier CEC usage.

Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: linux-media@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/8c6b6403932536b6849e0b44e1ee6e7ebdbe4a69.1692884619.git.jani.nikula@intel.com


# 7218779e 24-Aug-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid_is_digital()

Checking edid->input & DRM_EDID_INPUT_DIGITAL is common enough to
deserve a helper that also lets us abstract the raw EDID a bit better.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/4bdb407bf189fd922be022eb2f9564692377c81d.1692884619.git.jani.nikula@intel.com


# 88630e91 12-Oct-2023 Hamza Mahfooz <hamza.mahfooz@amd.com>

drm/edid: add 8 bpc quirk to the BenQ GW2765

The BenQ GW2765 reports that it supports higher (> 8) bpc modes, but
when trying to set them we end up with a black screen. So, limit it to 8
bpc modes.

Cc: stable@vger.kernel.org # 6.5+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2610
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231012184927.133137-1-hamza.mahfooz@amd.com


# 98d4cb70 21-Jun-2023 Ralph Campbell <rcampbell@nvidia.com>

drm/edid: Add quirk for OSVR HDK 2.0

The OSVR virtual reality headset HDK 2.0 uses a different EDID
vendor and device identifier than the HDK 1.1 - 1.4 headsets.
Add the HDK 2.0 vendor and device identifier to the quirks table so
that window managers do not try to display the desktop screen on the
headset display.

Closes: https://gitlab.freedesktop.org/drm/misc/-/issues/30
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
Tested-by: Ralph Campbell <rcampbell@nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230621061903.3422648-1-rcampbell@nvidia.com


# bce1eb50 27-Jun-2023 Colin Ian King <colin.i.king@gmail.com>

drm/edid: make read-only const array static

Don't populate the const array on the stack, instead make it static.

Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230627170109.751829-1-colin.i.king@gmail.com


# 50b6f2c8 15-Aug-2023 Jani Nikula <jani.nikula@intel.com>

Revert "drm/edid: Fix csync detailed mode parsing"

This reverts commit ca62297b2085b5b3168bd891ca24862242c635a1.

Commit ca62297b2085 ("drm/edid: Fix csync detailed mode parsing") fixed
EDID detailed mode sync parsing. Unfortunately, there are quite a few
displays out there that have bogus (zero) sync field that are broken by
the change. Zero means analog composite sync, which is not right for
digital displays, and the modes get rejected. Regardless, it used to
work, and it needs to continue to work. Revert the change.

Rejecting modes with analog composite sync was the part that fixed the
gitlab issue 8146 [1]. We'll need to get back to the drawing board with
that.

[1] https://gitlab.freedesktop.org/drm/intel/-/issues/8146

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8789
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8930
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9044
Fixes: ca62297b2085 ("drm/edid: Fix csync detailed mode parsing")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.4+
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230815101907.2900768-1-jani.nikula@intel.com


# d60d2bcc 29-May-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: make drm_edid_duplicate() safe to call with NULL parameter

It's a bit tedious to check for NULL before calling
drm_edid_duplicate(). Make it handle NULL parameter graciously.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1ae8923d39a5abd0260fdf7f9cc54c5e046e70d3.1685437501.git.jani.nikula@intel.com


# 6c46f644 29-May-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid_read_switcheroo()

Add a switcheroo variant to the struct drm_edid based EDID read
functions.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4ab5ec994670ea50f95c8079c1f1ae915940b00f.1685437501.git.jani.nikula@intel.com


# 0374ffa5 29-May-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: parse display info has_audio similar to is_hdmi

Since we already iterate everything that's needed for determining audio,
reduce the need to call drm_detect_monitor_audio() by storing has_audio
to connector info.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/391a93b25c6bcbb39854aaa2813570cfb1580ed9.1685437500.git.jani.nikula@intel.com


# ca62297b 28-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fix csync detailed mode parsing

Remove the bogus csync check and replace it with something that:
- triggers for all forms of csync, not just the basic analog variant
- actually populates the mode csync flags so that drivers can
decide what to do with the mode

Originally the code tried to outright reject csync, but that
apparently broke some bogus LCD monitor that claimed to have
a detailed mode that uses analog csync, despite also claiming
the monitor only support separate sync:
https://bugzilla.redhat.com/show_bug.cgi?id=540024
Potentially that monitor should just be quirked or something.

Anyways, what we are dealing with now is some kind of funny i915
JSL machine with eDP where the panel claims to support a sensible
60Hz separate sync mode, and a 50Hz mode with bipolar analog
csync. The 50Hz mode does not work so we want to not use it.
Easiest way is to just correctly flag it as csync and the driver
will reject it.

TODO: or should we just reject any form of csync (or at least
the analog variants) for digital display interfaces?

v2: Grab digital csync polarity from hsync polarity bit (Jani)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8146
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230228213610.26283-1-ville.syrjala@linux.intel.com


# c5a486af 16-Feb-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: parse Tiled Display Topology Data Block for DisplayID 2.0

Currently we only parse the Tiled Display Topology Data Block for
DisplayID structure version 1.2, but not 2.0. The contents seem to be
the same for both, so expand the parsing to structure version 2.0.

Note that DisplayID spec version is not the same as DisplayID structure
version; DisplayID 1.3 uses structure version 1.2, and DisplayID 2.0-2.1
use structure version 2.0. Lovely.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230217104627.1360015-1-jani.nikula@intel.com


# 217a8c63 16-Feb-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: update non-desktop use also from DisplayID

Use the DisplayID 2.0 primary use case information to deduce whether
this is a head-mounted display, and should not be used for desktop.

Cc: Iaroslav Boliukin <iam@lach.pw>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # HTC VIVE Pro 2
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/de75b2edddd7d30216e4dd5699a064dc737688f5.1676580180.git.jani.nikula@intel.com


# 4d8457fe 02-Mar-2023 Johan Hovold <johan+linaro@kernel.org>

drm/edid: fix info leak when failing to get panel id

Make sure to clear the transfer buffer before fetching the EDID to
avoid leaking slab data to the logs on errors that leave the buffer
unchanged.

Fixes: 69c7717c20cc ("drm/edid: Dump the EDID when drm_edid_get_panel_id() has an error")
Cc: stable@vger.kernel.org # 6.2
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230302074704.11371-1-johan+linaro@kernel.org


# b494d628 19-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: remove redundant _drm_connector_update_edid_property()

Realize that drm_edid_connector_update() and
_drm_connector_update_edid_property() are now the same thing. Drop the
latter.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/712cc299afe33d8f6279a15d5b0117aeeab88bb4.1674144945.git.jani.nikula@intel.com


# c533b516 19-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: add separate drm_edid_connector_add_modes()

The original goal with drm_edid_connector_update() was to have a single
call for updating the connector and adding probed modes, in this order,
but that turned out to be problematic. Drivers that need to update the
connector in the .detect() callback would end up updating the probed
modes as well. Turns out the callback may be called so many times that
the probed mode list fills up without bounds, and this is amplified by
add_alternate_cea_modes() duplicating the CEA modes on every call,
actually running out of memory on some machines.

Kudos to Imre Deak <imre.deak@intel.com> for explaining this to me.

Go back to having separate drm_edid_connector_update() and
drm_edid_connector_add_modes() calls. The former may be called from
.detect(), .force(), or .get_modes(), but the latter only from
.get_modes().

Unlike drm_add_edid_modes(), have drm_edid_connector_add_modes() update
the probed modes from the EDID property instead of the passed in
EDID. This is mainly to enforce two things:

1) drm_edid_connector_update() must be called before
drm_edid_connector_add_modes().

Display info and quirks are needed for parsing the modes, and we
don't want to call update_display_info() again to ensure the info is
available, like drm_add_edid_modes() does.

2) The same EDID is used for both updating the connector and adding the
probed modes.

Fortunately, the change is easy, because no driver has actually adopted
drm_edid_connector_update(). Not even i915, and that's mainly because of
the problem described above.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e86fff1579f14ebf6334692526c8f6831cd02cac.1674144945.git.jani.nikula@intel.com


# e8b1f0d4 19-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: refactor _drm_edid_connector_update() and rename

By moving update_display_info() out of _drm_edid_connector_update() we
make the function purely about adding modes. Rename accordingly.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e9880bbb2b5724d9aac88a90a31ba3ba9af9da3f.1674144945.git.jani.nikula@intel.com


# 919d320f 19-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: split HDMI VSDB info and mode parsing

Separate the parsing of display info and modes from the HDMI VSDB. This
is prerequisite work for overall better separation of the two parsing
steps.

The info parsing is about figuring out whether the sink supports HDMI
infoframes. Since they were added in HDMI 1.4, assume the sink supports
HDMI infoframes if it has the HDMI_Video_present bit set (introduced in
HDMI 1.4). For details, see commit f1781e9bb2dd ("drm/edid: Allow HDMI
infoframe without VIC or S3D").

The logic is not exactly the same, but since it was somewhat heuristic
to begin with, assume this is close enough.

v2:
- Simplify to only check HDMI_Video_present bit (Ville)
- Drop cea_db_raw_size() helper (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/238e15f7ab15a86f7fd1812271dcaec9bc6e1506.1674144945.git.jani.nikula@intel.com


# 43bde505 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: move EDID BPC quirk application to update_display_info()

The BPC quirks are closer to home in update_display_info().

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8997e0fa3b0fd03c920e72d1dff24c0d96ff4dd0.1672826282.git.jani.nikula@intel.com


# 45ea02d1 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: merge ELD handling to update_display_info()

Simplify display info update by merging ELD handling as well as clearing
of the data in update_display_info().

The connector->eld really should be moved under display_info altogether,
but that's for another time.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1f2e7424b998fbcdd9cea488e7d6d7cbb26c460f.1672826282.git.jani.nikula@intel.com


# 4959b693 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: stop passing quirks around

Now that quirks are stored in display info, we can just look them up
using the connector instead of having to pass them around.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d55049dd9b2e48e63103f2dfa49bc9b25dd57f82.1672826282.git.jani.nikula@intel.com


# 783dedc5 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: store quirks in display info

Although the quirks are internal to EDID parsing, it'll be helpful to
store them in display info to avoid having to pass them around.

This will also help separate adding probed modes (which needs the
quirks) from updating display info.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/819b908f64ad2d158245917f436f24d33a65b95d.1672826282.git.jani.nikula@intel.com


# cba83c1f 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: add helper for HDMI VSDB audio latency field length

Add a helper for skipping the HDMI VSDB audio latency fields.

There's a functional change for HDMI VSDB blocks that do not respect the
spec: "I_Latency_Fields_Present shall be zero if Latency_Fields_Present
is zero". We assume this to hold when skipping the latency fields, and
ignore non-zero I_Latency_Fields_Present if Latency_Fields_Present is
zero.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/da4293203ef2ddeb0bf66a2bfdbc129ab609c543.1672826282.git.jani.nikula@intel.com


# 1ee3e217 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: fix and clarify HDMI VSDB audio latency parsing

Add helpers for Latency_Fields_Present and I_Latency_Fields_Present
bits, and fix the parsing:

- Respect specification regarding "I_Latency_Fields_Present shall be
zero if Latency_Fields_Present is zero".

- Don't claim latency fields are present if the data block isn't big
enough to hold them.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/80426772a2d2e17bebf6f58d99b7d0cf6260c2d6.1672826282.git.jani.nikula@intel.com


# c54e2e23 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: split CTA Y420VDB info and mode parsing

Separate the parsing of display info and modes from the CTA
Y420VDB. This is prerequisite work for overall better separation of the
two parsing steps.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3bc5fe6650a6ce4249803f7192096764ea724e05.1672826282.git.jani.nikula@intel.com


# 61e05fdc 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: refactor CTA Y420CMDB parsing

Now that we have pre-parsed CTA VDB VICs stored in info->vics, leverage
that to simplify CTA Y420CMDB parsing. Move updating the y420_cmdb_modes
bitmap to the display info parsing stage, instead of updating it during
add modes. This allows us to drop the intermediate y420_cmdb_map from
display info, and replace it with a local variable.

This is prerequisite work for overall better separation of the two
parsing steps (updating display info and adding modes).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7a0e5e99a83f203b6a8981d263b89b2bb7d2fe15.1672826282.git.jani.nikula@intel.com


# 26c2ff77 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: rename struct drm_display_info *display to *info

Rename the local variable to info for consistency.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d35a50c714e21869afcabfafd5c5e590936b791a.1672826282.git.jani.nikula@intel.com


# 4ed29f39 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: use VIC in AVI infoframe if sink lists it in CTA VDB

Apparently there are HDMI 1.4 compatible displays out there that support
VICs from specs later than CTA-861-D, i.e. VIC > 64, although HDMI 1.4
references CTA-861-D only.

We try to avoid using VICs from the later specs in the AVI infoframes to
avoid upsetting sinks that conform to earlier specs.

However, it seems reasonable to do this when the sink claims it supports
the VIC. With the pre-parsed list of VICs handy, this is now trivial.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/6153
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: William Tseng <william.tseng@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/775124fd07a5b7892e869becc3dd8dadb328ae5f.1672826282.git.jani.nikula@intel.com


# 6a40a75f 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: Use the pre-parsed VICs

Now that we have all the VICs in info->vics, use them to simplify access
based on VIC index, i.e. on the order of VICs in the EDID, and avoid
passing CTA VDB pointers around.

This also fixes the highly unlikely scenarios of a) multiple HDMI VSDBs,
and b) HDMI VSDB 3D modes using VIC indexes that span across multiple
CTA VDBs, and the combination of the two.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/30f1a97193171e70ec1c26c4b685d8930799b9a6.1672826282.git.jani.nikula@intel.com


# c3292ab5 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: parse VICs from CTA VDB early

A number of places need access to the VICs. Just parse them early for
easy access. Gracefully handle multiple CTA VDBs. It's unlikely to have
more than one, but the CTA-861 references "Video Data Block(s)", so err
on the safe side.

Start parsing them now, convert users in follow-up to have fewer moving
parts in one go.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7989b2b37837be68953c5d20afd3e93762bfd626.1672826282.git.jani.nikula@intel.com


# 72794d16 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: fix parsing of 3D modes from HDMI VSDB

Commit 537d9ed2f6c1 ("drm/edid: convert add_cea_modes() to use cea db
iter") inadvertently moved the do_hdmi_vsdb_modes() call within the db
iteration loop, always passing NULL as the CTA VDB to
do_hdmi_vsdb_modes(), skipping a lot of stereo modes.

Move the call back outside of the loop.

This does mean only one CTA VDB and HDMI VSDB combination will be
handled, but it's an unlikely scenario to have more than one of either
block, and it was not accounted for before the regression either.

Fixes: 537d9ed2f6c1 ("drm/edid: convert add_cea_modes() to use cea db iter")
Cc: <stable@vger.kernel.org> # v6.0+
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cf159b8816191ed595a3cb954acaf189c4528cc7.1672826282.git.jani.nikula@intel.com


# 1cbc1f0d 03-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/edid: fix AVI infoframe aspect ratio handling

We try to avoid sending VICs defined in the later specs in AVI
infoframes to sinks that conform to the earlier specs, to not upset
them, and use 0 for the VIC instead. However, we do this detection and
conversion to 0 too early, as we'll need the actual VIC to figure out
the aspect ratio.

In particular, for a mode with 64:27 aspect ratio, 0 for VIC fails the
AVI infoframe generation altogether with -EINVAL.

Separate the VIC lookup from the "filtering", and postpone the
filtering, to use the proper VIC for aspect ratio handling, and the 0
VIC for the infoframe video code as needed.

Reported-by: William Tseng <william.tseng@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6153
References: https://lore.kernel.org/r/20220920062316.43162-1-william.tseng@intel.com
Cc: <stable@vger.kernel.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c3e78cc6d01ed237f71ad0038826b08d83d75eef.1672826282.git.jani.nikula@intel.com


# 69c7717c 21-Oct-2022 Douglas Anderson <dianders@chromium.org>

drm/edid: Dump the EDID when drm_edid_get_panel_id() has an error

If we fail to get a valid panel ID in drm_edid_get_panel_id() we'd
like to see the EDID that was read so we have a chance of
understanding what's wrong. There's already a function for that, so
let's call it in the error case.

NOTE: edid_block_read() has a retry loop in it, so actually we'll only
print the block read back from the final attempt. This still seems
better than nothing.

Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221021130637.1.I8c2de0954a4e54e0c59a72938268e2ead91daa98@changeid


# aa193f7e 21-Oct-2022 Hamza Mahfooz <hamza.mahfooz@amd.com>

drm/edid: add a quirk for two LG monitors to get them to work on 10bpc

The LG 27GP950 and LG 27GN950 have visible display corruption when
trying to use 10bpc modes. So, to fix this, cap their maximum DSC
target bitrate to 15bpp.

Suggested-by: Roman Li <roman.li@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# e1e7bc48 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert to device specific logging

Convert to drm_kms_dbg/drm_err where possible, and reference the
connector using [CONNECTOR:%d:%s]. Pass connectors around a bit more to
enable this. Where this is not possible, unify the rest of the debugs to
DRM_DEBUG_KMS.

Rewrite tile debug logging to one line while at it.

v2:
- Use [CONNECTOR:%d:%s] throughout (Ville)
- Tile debug logging revamp
- Pass connector around a bit more

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e48346bfe09a632d5a5faa55e3c161b196cf21e8.1666614699.git.jani.nikula@intel.com


# 66d17ecd 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add [CONNECTOR:%d:%s] to debug logging

Reference the connector using [CONNECTOR:%d:%s] in existing device based
debug logging.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/5884410682bcbc032de4d3af8562c0b271edaa7f.1666614699.git.jani.nikula@intel.com


# 794aca0e 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: use struct drm_edid for override/firmware EDID

There's a lot going on here, but the main thing is switching the
firmware EDID loader to use struct drm_edid. Unfortunately, it's
difficult to reasonably split to smaller pieces.

Convert the EDID loader to struct drm_edid. There's a functional change
in validation; it no longer tries to fix errors or filter invalid
blocks. It's stricter in this sense. Hopefully this will not be an
issue.

As a by-product, this change also allows HF-EEODB extended EDIDs to be
passed via override/firmware EDID.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e64267c28eca483e83c802bc06ddd149bdcdfc66.1666614699.git.jani.nikula@intel.com


# a05992d5 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid/firmware: rename drm_load_edid_firmware() to drm_edid_load_firmware()

Follow the usual naming convention by file name.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d6714ae737d789764bd2bdb6e7c9a5f56c99eef3.1666614699.git.jani.nikula@intel.com


# 90b575f5 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: detach debugfs EDID override from EDID property update

Having the EDID override debugfs directly update the EDID property is
problematic. The update is partial only. The driver has no way of
knowing it's been updated. Mode list is not updated. It's an
inconsistent state.

Detach debugfs EDID override from the property update completely. Only
set and reset a separate override EDID copy from debugfs, and have it
take effect only at detect (via EDID read). The copy is at
connector->edid_override, protected by connector->edid_override_mutex.

This also brings override EDID closer to firmware EDID in behaviour.

Add validation of the override EDID which we completely lacked.

Note that IGT already forces a detect whenever tests update the override
EDID.

v2: Add locking (Ville)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4c875f8e06c4499f498fcf876e1233cbb155ec8a.1666614699.git.jani.nikula@intel.com


# 6c9b3db7 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add function for checking drm_edid validity

We've lacked a function for immutable validity check on drm_edid. Add
one.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f96188f64e9f7f3deff348d08296609353b12316.1666614699.git.jani.nikula@intel.com


# b16c9e6c 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: split drm_edid block count helper

Split the drm_edid block count helper to a base version that reports the
block count indicated by EDID contents, and another on top that limits
the block count based on size allocated for the EDID.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a7d63878c7fb3dd6f3b987f5257897113797b94f.1666614699.git.jani.nikula@intel.com


# 019b9387 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: rename drm_add_override_edid_modes() to drm_edid_override_connector_update()

Follow the naming of both EDID override functions as well as
drm_edid_connector_update(). This also matches better what the function
does; a combination of EDID property update and add modes. Indeed it
should later be converted to call drm_edid_connector_update().

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ba12957e0488654e8db010a3ff1534079caec972.1666614699.git.jani.nikula@intel.com


# 91ec9ab4 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: abstract debugfs override EDID show better

Add a function to dump the override EDID in debugfs. This hides the
override EDID management better in drm_edid.c.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/74defa7b595f51e6c1f2eacd9c799d567d29f053.1666614699.git.jani.nikula@intel.com


# 2c9332de 24-Oct-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: debug log EDID override set/reset

It's useful debugging information to know if and when an override EDID
was set or reset.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ae352f542b4d69398c0965e33fb2e6e34156cbfb.1666614699.git.jani.nikula@intel.com


# dd3abfe4 27-Sep-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Make version checks less convoluted

Get rid of the confusing version_greater() stuff and
simply compare edid->revision directly everwhere. Half
the places already did it this way, and since we actually
reject any EDID with edid->version!=1 it's a perfectly
sane thing to do.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-9-ville.syrjala@linux.intel.com


# f72f9529 27-Sep-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Unconfuse preferred timing stuff a bit

For EDID 1.4 the first detailed timing is always preferred,
for older EDIDs there was a feature flag to indicate the same.
While correct, the code setting that up is rather confusing.
Restate it in a slightly more straightforward manner.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-8-ville.syrjala@linux.intel.com


# bf72b5ef 27-Sep-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Use the correct formula for standard timings

Prefer the timing formula indicated by the range
descriptor for generating the non-DMT standard timings.

Previously we just used CVT for all EDID 1.4 continuous
frequency displays without even checking if the range
descriptor indicates otherwise. Now we check the range
descriptor first, and fall back to CVT if nothing else
was indicated. EDID 1.4 more or less deprecates GTF/GTF2
but there are still a lot of 1.4 EDIDs out there that
don't advertise CVT support, so seems safer to use the
formula the EDID actually reports as supported.

For EDID 1.3 we use GTF2 if indicated (as before), and for
EDID 1.2+ we now just use GTF without even checking the
feature flag. There seem to be quite a few EDIDs out there that
don't set the GTF feature flag but still include a GTF range
descriptor and non-DMT standard timings.

This to me seems to be roughly what appendix B of EDID 1.4
suggests should be done.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-7-ville.syrjala@linux.intel.com


# 9ed15f91 27-Sep-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Use GTF2 for inferred modes

For some reason we only use the secondary GTF curve for the
standard timings. Use it for inferred modes as well.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-6-ville.syrjala@linux.intel.com


# 86101bb7 27-Sep-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Extract drm_gtf2_mode()

Extract the GTF vs. GTF2 logic into a separate function.
We'll have a second user soon.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-5-ville.syrjala@linux.intel.com


# ca2582c6 27-Sep-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Only parse VRR range for continuous frequency displays

Since we only use the parsed vrefresh range to determine
if VRR should be supported we should only accept continuous
frequency displays here.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-4-ville.syrjala@linux.intel.com


# afd4429e 27-Sep-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Define more flags

Replace a bunch of hex constants with proper definitions.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-3-ville.syrjala@linux.intel.com


# 67d7469a 27-Sep-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Clarify why we only accept the "range limits only" descriptor

The current comment fails to clarify why we only accept
the "range limits only" variant of the range descriptor.
Reword it to make some actual sense.

Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-2-ville.syrjala@linux.intel.com


# 5e931c88 16-Sep-2022 Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/edid: Avoid multiple log lines for HFVSDB parsing

Replace multiple log lines with a single log line at the end of
parsing HF-VSDB. Also use drm_dbg_kms instead of DRM_DBG_KMS, and
add log for DSC1.2 support.

v2: Fixed the formatting issues in the logging (Jani).

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916100551.2531750-5-ankit.k.nautiyal@intel.com


# a07e6f56 16-Sep-2022 Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/edid: Refactor HFVSDB parsing for DSC1.2

DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
SCDS). Since minimum length of Data block is 7, all bytes greater than 7
must be read only after checking the length of the data block.

This patch adds check for data block length before reading relavant DSC
bytes.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916100551.2531750-4-ankit.k.nautiyal@intel.com


# 5e706c4d 16-Sep-2022 Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/edid: Split DSC parsing into separate function

Move the DSC parsing logic into separate function.

v2: Rebase.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916100551.2531750-3-ankit.k.nautiyal@intel.com


# 18feaf6d 16-Sep-2022 Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/edid: Fix minimum bpc supported with DSC1.2 for HDMI sink

HF-VSDB/SCDB has bits to advertise support for 16, 12 and 10 bpc.
If none of the bits are set, the minimum bpc supported with DSC is 8.

This patch corrects the min bpc supported to be 8, instead of 0.

Fixes: 76ee7b905678 ("drm/edid: Parse DSC1.2 cap fields from HFVSDB block")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

v2: s/DSC1.2/DSC 1.2

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916100551.2531750-2-ankit.k.nautiyal@intel.com


# 96c92551 07-Sep-2022 Jilin Yuan <yuanjilin@cdjrlc.com>

drm/edid: fix repeated words in comments

Delete the redundant word 'on'.

Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220907113644.32831-1-yuanjilin@cdjrlc.com


# 82068ede 18-Jul-2022 Jouni Högander <jouni.hogander@intel.com>

drm: New function to get luminance range based on static hdr metadata

Split luminance min/max calculation using static hdr metadata from
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:update_connector_ext_caps
into drm/drm_edid.c and use it during edid parsing. Calculated range is
stored into connector->display_info->luminance_range.

Add new data structure (drm_luminance_range_inf) to store luminance range
calculated using data from EDID's static hdr metadata block. Add this new
struct as a part of drm_display_info struct.

v3: Squashed adding drm_luminance_range_info patch here
v2: Calculate range during edid parsing

Cc: Roman Li <roman.li@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220719095700.14923-2-jouni.hogander@intel.com


# c7943bb3 26-Aug-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsets

EDID 1.4 introduced some extra flags in the range
descriptor to support min/max h/vfreq >= 255. Consult them
to correctly parse the vfreq limits.

Note that some combinations of the flags are documented
as "reserved" (as are some other values in the descriptor)
but explicitly checking for those doesn't seem particularly
worthwile since we end up with bogus results whether we
decode them or not.

v2: Increase the storage to u16 to make it work (Jani)
Note the "reserved" values situation (Jani)
v3: Document the EDID version number in the defines
Drop some bogus (u8) casts

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6519
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6484
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220826213501.31490-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>


# b1dee952 28-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: take HF-EEODB extension count into account

Take the HF-EEODB extension count override into account.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c31b5796feb05c3ebac067600be2e88e098d7592.1656494768.git.jani.nikula@intel.com


# 18e3c1d5 28-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add HF-EEODB support to EDID read and allocation

HDMI 2.1 section 10.3.6 defines an HDMI Forum EDID Extension Override
Data Block, which may contain a different extension count than the base
block claims. Add support for reading more EDID data if available. The
extra blocks aren't parsed yet, though.

Hard-coding the EEODB parsing instead of using the iterators we have is
a bit of a bummer, but we have to be able to do this on a partially
allocated EDID while reading it.

v2:
- Check for CEA Data Block Collection size (Ville)
- Amend commit message and comment about hard-coded parsing

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/57b57a355d62eb91ad1e3cf555978576f2bd9fdd.1656494768.git.jani.nikula@intel.com


# 89f4b4c5 28-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: do invalid block filtering in-place

Rewrite edid_filter_invalid_blocks() to filter invalid blocks
in-place. The main motivation is to not rely on passed in information on
invalid block count or the allocation size, which will be helpful in
follow-up work on HF-EEODB.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a6ad5e4e7b91338c0d19d7be189af31094e65555.1656494768.git.jani.nikula@intel.com


# 3d1ab66e 28-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid_raw() to access the raw EDID data

Unfortunately, there are still plenty of interfaces around that require
a struct edid pointer, and it's impossible to change them all at
once. Add an accessor to the raw EDID data to help the transition.

While there are no such cases now, be defensive against raw EDID
extension count indicating bigger EDID than is actually allocated.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fb55d0b580d556bf2b8e58070239657ac9cb4b2f.1656494768.git.jani.nikula@intel.com


# b71c0aaa 28-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid_connector_update()

Add a new function drm_edid_connector_update() to replace the
combination of calls drm_connector_update_edid_property() and
drm_add_edid_modes(). Usually they are called in the drivers in this
order, however the former needs information from the latter.

Since the new drm_edid_read*() functions no longer call the connector
updates directly, and the read and update are separated, we'll need this
new function for the connector update.

This is all in drm_edid.c simply to keep struct drm_edid opaque.

v2:
- Share code with drm_connector_update_edid_property() (Ville)
- Add comment about override EDID handling

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/75aa3dbc8c9aa26ebbcdeacd98a466ef8d8827f4.1656494768.git.jani.nikula@intel.com


# 6aa145bc 28-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: abstract debugfs override EDID set/reset

Add functions drm_edid_override_set() and drm_edid_override_reset() to
support "edid_override" connector debugfs, and to hide the details about
it in drm_edid.c. No functional changes at this time.

Also note in the connector.override_edid flag kernel-doc that this is
only supposed to be modified by the code doing debugfs EDID override
handling. Currently, it is still being modified by amdgpu in
create_eml_sink() and handle_edid_mgmt() for reasons unknown. This was
added in commit 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
and later moved to amdgpu_dm.c in commit e7b07ceef2a6 ("drm/amd/display:
Merge amdgpu_dm_types and amdgpu_dm").

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8f6b4001630cafac5f44aa5913429ac9979743d2.1656494768.git.jani.nikula@intel.com


# f999b37e 28-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: clean up connector update error handling and debug logging

Bail out on all errors, debug log all errors, and convert to drm device
based debug logging.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/de4270b3d2e61fe42b9248490376594d472d19aa.1656494768.git.jani.nikula@intel.com


# a819451e 28-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_connector_update_edid_property() to struct drm_edid

Make drm_connector_update_edid_property() a thin wrapper around a struct
drm_edid based version of the same.

This lets us remove the legacy drm_update_tile_info() and
drm_add_display_info() functions altogether.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4bfe87ae392554ffb41d725353c4265ae56700bb.1656494768.git.jani.nikula@intel.com


# 02b16fbc 28-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: move drm_connector_update_edid_property() to drm_edid.c

The function needs access to drm_edid.c internals more than
drm_connector.c. We can make drm_reset_display_info(),
drm_add_display_info() and drm_update_tile_info() static. There will be
more benefits with follow-up struct drm_edid refactoring.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cbabce6ffb41fdc903533f21d946e8cae0667be5.1656494768.git.jani.nikula@intel.com


# 6537f79a 08-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add new interfaces around struct drm_edid

Add new functions drm_edid_read(), drm_edid_read_ddc(), and
drm_edid_read_custom() to replace drm_get_edid() and drm_do_get_edid()
for reading the EDID. The transition is expected to happen over a fairly
long time.

Note that the new drm_edid_read*() functions do not do any of the
connector updates anymore. The reading and parsing will be completely
separated from each other.

Add new functions drm_edid_alloc(), drm_edid_dup(), and drm_edid_free()
for allocating and freeing drm_edid containers.

Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5a6532a94cad6a79424f6d1918dbe7b7d607ac03.1654674560.git.jani.nikula@intel.com


# 407d63b3 08-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: keep track of alloc size in drm_do_get_edid()

We'll want to return the allocated buffer size in the future. Keep track
of it.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8e4261d8c2947ea99240ea929f09a04878235f4e.1654674560.git.jani.nikula@intel.com


# d9307f27 08-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add block count and data helper functions for drm_edid

Add drm_edid based block count and data access helper functions that
take the EDID allocated size into account.

At the moment, the allocated size should always match the EDID size
indicated by the extension count, but this will change in the future.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1a68c8667a88e7c451b001ad8bd86c8badb57fb8.1654674560.git.jani.nikula@intel.com


# 11a8d095 08-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: abstract cea data block collection size

Add a function to get the cea data block collection size.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5339ab3249400a3c41001967e7ff2611b58e0425.1654674560.git.jani.nikula@intel.com


# fc67615f 08-Jun-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: fix CTA data block collection size for CTA version 3

The CTA Data Block Collection is valid only for CTA extension version
3. In versions 1 and 2, it is a reserved block, which we ignore.

The DTD start offset (byte 2, or d in CTA-861 spec), which determines
the CTA Data Block Collection size, is specified slightly differently
for different versions:

Version 1:
d = offset for the byte following the reserved data block. If no
data is provided in the reserved data block, then d=4. If no DTDs
are provided, then d=0

Version 2:
d = offset for the byte following the reserved data block. If no
data is provided in the reserved data block, then d=4. If d=0, then
no detailed timing descriptors are provided, and no data is provided
in the reserved data block.

Version 3:
d = offset for the byte following the data block collection. If no
data is provided in the data block collection, then d=4. If d=0,
then no detailed timing descriptors are provided, and no data is
provided in the data block collection.

Ever since commit 9e50b9d55e9c ("drm: edid: Add some bounds checking"),
we've interpreted 0 to mean there are no DTDs but it's all Data
Blocks. Per the spec, Data Blocks are only valid for version 3, where we
should interpret 0 to mean there are no data blocks.

Follow the spec (and hope the EDIDs follow it too).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2a4c94417f024cbafc5d4ca0a74e4617fc4325d1.1654674560.git.jani.nikula@intel.com


# d0edd3c1 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert version_greater() to drm_edid

We'll need to propagate drm_edid everywhere. Also make version_greater()
a function for type safety.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f1835a86294b392d075570001ed9009a48352670.1652097712.git.jani.nikula@intel.com


# d9ba1b4c 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/displayid: convert to drm_edid

We'll need to propagate drm_edid everywhere.

v2: Rebase

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a52a6882e87a4bb6b1670918f3aba13f9b52f6de.1652097712.git.jani.nikula@intel.com


# c7b2dee4 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid helper for drm_update_tile_info()

We'll need to propagate drm_edid everywhere.

v2: Handle NULL EDID pointer (Ville, CI)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5b36683b656446a4d9a172d4dca1cf9aca08a48b.1652097712.git.jani.nikula@intel.com


# bbded689 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_edid_iter_begin() to drm_edid

We'll need to propagate drm_edid everywhere.

v2: Rebase

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/24dfb5fd9026ebef573bb55b368b94e56cae5cec.1652097712.git.jani.nikula@intel.com


# 5e87b2e5 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert cea_db_iter_edid_begin() to drm_edid

We'll need to propagate drm_edid everywhere.

v2: Handle NULL drm_edid

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7d9f060815086e1e4ea037dbfb9fd8ad54d1f25e.1652097712.git.jani.nikula@intel.com


# 0c057877 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid helper for drm_detect_monitor_audio()

We'll need to propagate drm_edid everywhere.

v2: Handle NULL EDID pointer (Ville, CI)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ea33244c473ace1bc72a7e87f97580f00705a683.1652097712.git.jani.nikula@intel.com


# 3176d092 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid helper for drm_detect_hdmi_monitor()

We'll need to propagate drm_edid everywhere.

v2: Handle NULL EDID pointer (Ville, CI)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2fbee0d7b544b44ef0866bb154beefac5d260bec.1652097712.git.jani.nikula@intel.com


# 02703451 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid helper for drm_edid_to_speaker_allocation()

We'll need to propagate drm_edid everywhere.'

v2: Handle NULL EDID pointer (Ville, CI)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/770d095c93274969c4b86480e07044e16a7b5760.1652097712.git.jani.nikula@intel.com


# bba4b647 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid helper for drm_edid_to_sad()

We'll need to propagate drm_edid everywhere.

v2: Handle NULL EDID pointer (Ville, CI)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/14aa1e44caa2e9c1b54c2f2a471d2fd7d3f62d5d.1652097712.git.jani.nikula@intel.com


# 45aa2336 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_for_each_detailed_block() to drm_edid

We'll need to propagate drm_edid everywhere.

v2: Fix checkpatch warning on superfluous parens

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bfd06d64235393012b2f3626d5764350de5f5321.1652097712.git.jani.nikula@intel.com


# 2c54f87c 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert get_monitor_name() to drm_edid

We'll need to propagate drm_edid everywhere.

v2: Drop incorrect NULL name check (Dan Carpenter)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c940aad14f323ef3a7907a0fb534011deb1589a9.1652097712.git.jani.nikula@intel.com


# 874d98ee 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert mode_in_range() and drm_monitor_supports_rb() to drm_edid

We'll need to propagate drm_edid everywhere.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/aac7dd14ce8c266491e9dfae12cad00fecdcd2e3.1652097712.git.jani.nikula@intel.com


# 67d87fac 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_mode_std() and children to drm_edid

We'll need to propagate drm_edid everywhere.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9fb970d108a8bb666b87a590c74f480e0fd81cc8.1652097712.git.jani.nikula@intel.com


# 7428bfbd 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_cvt_modes_for_range() to drm_edid

We'll need to propagate drm_edid everywhere.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c2c251a504933debacf78e1382ae665ae490ed40.1652097712.git.jani.nikula@intel.com


# a77f7c89 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_gtf_modes_for_range() to drm_edid

We'll need to propagate drm_edid everywhere.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b50377ce67fd3cee6628ea5865c80fa0fa7da990.1652097712.git.jani.nikula@intel.com


# 084c7a7c 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_dmt_modes_for_range() to drm_edid

We'll need to propagate drm_edid everywhere.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a8f393263225321e74f1e2884e81b3346d1adf20.1652097712.git.jani.nikula@intel.com


# f0d080ff 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_mode_detailed() to drm_edid

We'll need to propagate drm_edid everywhere.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6e4625d529ee4bfb2f6ebbfef5fb707d65a0554d.1652097712.git.jani.nikula@intel.com


# dd0f4470 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert struct detailed_mode_closure to drm_edid

We'll need to propagate drm_edid everywhere.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/da4c927cd973766568a79ef044254fff20317e7f.1652097712.git.jani.nikula@intel.com


# 40f71f5b 10-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_edid_connector_update() to drm_edid fully

We'll need to propagate drm_edid everywhere.

v3: s/edid/drm_edid/ in comment too (Ankit)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511092650.4193330-1-jani.nikula@intel.com


# a2f9790d 10-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: propagate drm_edid to drm_edid_to_eld()

We'll need to propagate drm_edid everywhere.

v3: Rebase

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511092349.4186498-1-jani.nikula@intel.com


# e42192b4 10-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: keep propagating drm_edid to display info

We'll need to propagate drm_edid everywhere.

v3: Update comment to refer to update_display_info() (Ankit)

v2: Use drm_edid_legacy_init()

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511092104.4179637-1-jani.nikula@intel.com


# 22a27e05 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: start propagating drm_edid to lower levels

We'll need to propagate drm_edid everywhere. This is a clunky start, but
a start nonetheless. We'll eventually convert all of the EDID parsing to
struct drm_edid.

Initially, we'll just create the struct drm_edid in stack. This will be
the compat layer for legacy struct edid code. In the future, we'll have
EDID read return drm_edid objects.

v2: Add legacy init helper.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/000452fddedbaf7f473ac25d4dde2502e60b8e39.1652097712.git.jani.nikula@intel.com


# e4ccf9a7 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add struct drm_edid container

Introduce new opaque type struct drm_edid to encapsulate the EDID data
and the size allocated for it. The contents will be private to
drm_edid.c.

There are a number of reasons for adding a container around struct edid:

* struct edid is a raw blob pointer to data that usually originates
outside of the kernel. Its size is contained within the structure.

* There's no way to attach meta information (such as allocated memory
size) to struct edid.

* Validation of the EDID blob and its size become crucial, and it's
spread all over the subsystem, with varying levels of accuracy.

* HDMI Forum has introduced an HF-EEODB extension that defines an
override EDID size within an EDID extension. The size allocated for an
EDID depends on whether the allocator understands the HF-EEODB
extension. Given a struct edid *, it's impossible to know how much
memory was actually allocated for it.

There are also some reasons for making the container type struct
drm_edid opaque and private to drm_edid.c:

* Have only one place for creating and parsing the EDID, to avoid
duplicating bugs.

* Prepare for reading a pure DisplayID 2.0 from its own DDC address, and
adding it within the same struct drm_edid container, transparently,
and for all drivers.

* With the idea that the drm_edid objects are immutable during their
lifetimes, it will be possible to refcount them and reduce EDID
copying everywhere (this is left for future work).

Initially, just add the type. In follow-up, we'll start converting the
guts of drm_edid.c to use it, and finally add interfaces around it.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f3ecabd8a219aea678ad00f7bcdecf77b27b3c78.1652097712.git.jani.nikula@intel.com


# ab1747cc 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_for_each_detailed_block() to edid iter

We have an iterator for this, use it. It does include the base block,
but its tag is 0 and will be skipped.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a68718819a3dbfbdaaaddca7f73afa5ac6b33d07.1652097712.git.jani.nikula@intel.com


# be982415 09-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: use else-if in CTA extension parsing

Only one of the conditions can be true.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3a7ba2217134b0ab4c4c72e4333231a4e0616e88.1652097712.git.jani.nikula@intel.com


# 6ff1c19f 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: sunset drm_find_cea_extension()

Convert drm_find_cea_extension() to a predicate function to check if the
EDID has a CTA extension or a DisplayID CTA data block. This is mainly
to avoid adding new users that only find the first CTA extension.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a5bf228942e6bd0fc70d5cf7a14c249a14a7afcd.1651569697.git.jani.nikula@intel.com


# 58304630 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: skip CTA extension scan in drm_edid_to_eld() just for CTA rev

The DisplayID CTA data block version does not necessarily match the CTA
revision. Simplify by postponing drm_edid_to_eld() slightly, and reusing
the CTA revision extracted by drm_parse_cea_ext().

By not bailing out early in drm_edid_to_eld() we may end up filling
meaningless data to the ELD. However, the main decision for audio is not
the ELD, but rather drm_detect_monitor_audio() called by drivers.

(Arguably a future cleanup could do that in drm_add_edid_modes() and
cache the result in the connector.)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/163ebbfd765066acbfc267256fb3b67fc711a78d.1651569697.git.jani.nikula@intel.com


# 8db73897 05-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: detect color formats and CTA revision in all CTA extensions

Convert drm_find_cea_extension() to EDID block iterator in color format
and CTA revision detection. Detect them in all CTA extensions.

Also parse CTA Data Blocks in DisplayID even if there's no CTA EDID
extension.

v2:
- Don't assume DRM_COLOR_FORMAT_RGB444 support if there's only DisplayID
CTA Data Blocks (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220505105242.1198521-1-jani.nikula@intel.com


# 705bec3e 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: detect basic audio in all CEA extensions

Convert drm_find_cea_extension() to EDID block iterator in basic audio
detection. Detect basic audio in all CEA extensions.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/59481d0397de4b91b3e6ea665882334e92538f40.1651569697.git.jani.nikula@intel.com


# 49a62a29 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: restore some type safety to cea_db_*() functions

During the transition, we accepted a void pointer for a poor C
programmer's version of polymorphism. Switch the functions to use struct
cea_db * to regain some more type safety.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c6ad496cdadea1bb598711a65ef536f4a43b74a7.1651569697.git.jani.nikula@intel.com


# 2af24344 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: sunset the old unused cea data block iterators

All CTA data block iteration has now been converted to the new cea db
iterators.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a5b35ed0e711bd874f76ae87ee0b70150d0a77c4.1651569697.git.jani.nikula@intel.com


# 37852141 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_edid_to_eld() to use cea db iter

Iterate through all CTA data blocks across all CTA extensions and
DisplayID data blocks. This may gather more data than before, and if
there's duplicated data, some is overwritten by whichever comes last.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8bdc67aa731857111eddd08a9c192d41d40b5f5a.1651569697.git.jani.nikula@intel.com


# dfc03125 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_parse_cea_ext() to use cea db iter

Iterate through all CTA data blocks across all CTA Extensions and
DisplayID data blocks.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7400792525c13f58652f288b891d6057637ed4c8.1651569697.git.jani.nikula@intel.com


# 9975af04 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_detect_monitor_audio() to use cea db iter

Iterate through all CEA data blocks.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a7f0c380da9526f8dd6f758d7a748bca7b4da6ce.1651569697.git.jani.nikula@intel.com


# 4ce08703 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_detect_hdmi_monitor() to use cea db iter

Iterate through all CTA data blocks, not just the first CTA extension.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b867e7b628189d2f8fa7eac5b9aa701892724711.1651569697.git.jani.nikula@intel.com


# b07debc2 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_edid_to_sad() to use cea db iter

Use the cea db iterator for short audio descriptors. We'll still stop at
the first audio data block, but not at the first CTA Extension if that
doesn't have the info.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/237e4b1de1567903d37ce1d1bb830020b8fd6690.1651569697.git.jani.nikula@intel.com


# ed317307 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert drm_edid_to_speaker_allocation() to use cea db iter

Use the cea db iterator for speaker allocation. We'll still stop at the
first speaker data block, but not at the first CTA extension if that
doesn't have the info.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0b9e7f136854055a14b826097160fe0b43b9f3d1.1651569697.git.jani.nikula@intel.com


# 537d9ed2 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert add_cea_modes() to use cea db iter

Iterate through all CTA EDID extension blocks and DisplayID CTA data
blocks to add CEA modes.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/dfa2d79db61d5eea543bef7aca7d80da3e71f99d.1651569697.git.jani.nikula@intel.com


# a9ec4fd0 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: clean up cea_db_is_*() functions

Abstract helpers for matching vendor data blocks and extended tags, and
use them to simplify all the cea_db_is_*() functions.

Take void pointer as parameter to allow transitional use for both u8 *
and struct cea_db *.

v2: Remove superfluous parens (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b6bb813afc35c763e744c6cdb4a787da3adf910b.1651569697.git.jani.nikula@intel.com


# aba58254 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add iterator for CTA data blocks

Add an iterator for CTA Data Blocks across EDID CTA Extensions and
DisplayID CTA Data Blocks.

v2: Update references, note why we can trust displayid ranges (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/37fdd2d9eabc73aaa9f95c56246dc47aea0e8e4e.1651569697.git.jani.nikula@intel.com


# 94afc538 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add iterator for EDID base and extension blocks

Add an iterator abstraction for going through all the EDID blocks.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ce02778b353b906c928268de9d7569d493a9be5d.1651569697.git.jani.nikula@intel.com


# 9d72b7e2 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: clean up CTA data block tag definitions

Add prefixed names, group, sort, add references.

v2:
- Updated references to CTA-861-H
- s/CEA/CTA/ in data block macros

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c66cc3adeb375f5e60d1a8f91b41580d8ab67442.1651569697.git.jani.nikula@intel.com


# d8cb49d2 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: rename HDMI Forum VSDB to SCDS

The HDMI spec talks about SCDS, Sink Capability Data Structure, exposed
via HF-VSDB or HF-SCDB. Rename VSDB to SCDS.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f8230e1893400e9a9c5829041a8ab36349182a54.1651569697.git.jani.nikula@intel.com


# 115fcf58 02-May-2022 Lee Shawn C <shawn.c.lee@intel.com>

drm/edid: check for HF-SCDB block

Find HF-SCDB information in CEA extensions block. And retrieve
Max_TMDS_Character_Rate that support by sink device.

v2: HF-SCDB and HF-VSDBS carry the same SCDS data. Reuse
drm_parse_hdmi_forum_vsdb() to parse this packet.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2bf7110cdb56d5dda311480787faf472c9802de4.1651569697.git.jani.nikula@intel.com


# d10f7117 02-May-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: reset display info in drm_add_edid_modes() for NULL edid

If a NULL edid gets passed to drm_add_edid_modes(), we should probably
also reset the display info.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2ac1c55f94a08d5e72c0b518d956a11002ec85c1.1651569697.git.jani.nikula@intel.com


# 17edb8e1 25-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: drop kernel-doc for static functions

Drop the kernel-doc for static functions, it's excessive, but retain the
info in plain comments.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220426091913.1339941-2-jani.nikula@intel.com


# 5d96fc9c 25-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: fix kernel-doc parameter name mismatches

Fix the below drm/edid kernel-doc warnings:

drivers/gpu/drm/drm_edid.c:1589: warning: Function parameter or member '_edid' not described in 'drm_edid_header_is_valid'
drivers/gpu/drm/drm_edid.c:1589: warning: Excess function parameter 'raw_edid' description in 'drm_edid_header_is_valid'
drivers/gpu/drm/drm_edid.c:1737: warning: Function parameter or member '_block' not described in 'drm_edid_block_valid'
drivers/gpu/drm/drm_edid.c:1737: warning: Excess function parameter 'raw_edid' description in 'drm_edid_block_valid'
drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member 'read_block' not described in 'drm_do_get_edid'
drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member 'context' not described in 'drm_do_get_edid'
drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter 'get_edid_block' description in 'drm_do_get_edid'
drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter 'data' description in 'drm_do_get_edid'

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
References: https://lore.kernel.org/r/20220406154431.567414c3@canb.auug.org.au
References: https://lore.kernel.org/r/20220420162431.2b28ddea@canb.auug.org.au
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220426091913.1339941-1-jani.nikula@intel.com


# 644edf52 21-Apr-2022 Thomas Zimmermann <tzimmermann@suse.de>

drm/display: Move SCDC helpers into display-helper library

SCDC is the Status and Control Data Channel for HDMI. Move the SCDC
helpers into display/ and split the header into files for core and
helpers. Update all affected drivers. No functional changes.

To avoid the proliferation of Kconfig options, SCDC is part of DRM's
support for HDMI. If necessary, a new option could make SCDC an
independent feature.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-9-tzimmermann@suse.de


# 4fc8cb47 21-Apr-2022 Thomas Zimmermann <tzimmermann@suse.de>

drm/display: Move HDMI helpers into display-helper module

Move DRM's HMDI helpers into the display/ subdirectoy and add it
to DRM's display helpers. Update all affected drivers. No functional
changes.

The HDMI helpers were implemented in the EDID and connector code, but
are actually unrelated. With the move to the display-helper library, we
can remove the dependency on drm_edid.{c,h} in some driver's HDMI source
files.

Several of the HDMI helpers remain in EDID code because both share parts
of their implementation internally. With better refractoring of the EDID
code, those HDMI helpers could be moved into the display-helper library
as well.

v3:
* fix Kconfig dependencies (Javier)
v2:
* reduce HDMI helpers to avoid exporting functions (Jani)
* fix include statements (Jani, Javier)
* update Kconfig symbols

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-8-tzimmermann@suse.de


# f1e4c916 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add EDID block count and size helpers

Add some helpers to figure out the EDID extension block count, block
count, size, pointers to blocks.

Unfortunately, we'll need to cast away the const in a few places where
we actually need to access the data.

v3: fix (!edid_extension_block_count(edid) == 0) (kernel test robot)

v2: fix s/j/i/ introduced in a rebase

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/dc7b0850293d837439fb3914c8a9d81e39018b4b.1649685475.git.jani.nikula@intel.com


# 1c788f69 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add single point of return to drm_do_get_edid()

This will be useful in the future. Use fail label for fail exit.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8e564e9415baa4dc9dc3127e4200b2618a8a3ba0.1649685475.git.jani.nikula@intel.com


# b3eb97b6 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: drop extra local var

We don't need override as a variable for anything.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4d249173b34758e1d6c4a74eb98518d180f0a8ae.1649685475.git.jani.nikula@intel.com


# d3da3f40 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert extension block read to EDID block read helper

Use the EDID block read helper also for extension block reads, making
edid_block_read() the only place with the read retry logic.

Note: We observe that drm_do_get_edid() does not use invalid extension
blocks to flag the EDID as corrupt.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a6328b898db40235b85ad4635374bc0768b5a970.1649685475.git.jani.nikula@intel.com


# c12561ce 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: use EDID block read helper in drm_do_get_edid()

Convert drm_do_get_edit() from the base block read helper to the generic
block read helper. There's quite a bit going on here, as the corrupt and
null EDID information is moved back to the caller. As we see, they were
not all that clear to begin with, and this change underlines that.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3bcf98453770757ee93386da0cfbc6552d42a312.1649685475.git.jani.nikula@intel.com


# 2deaf1c2 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: abstract an EDID block read helper

We have an abstraction for the EDID base block read, yet duplicating the
retries and error handling for extension block reads. Introduce a more
generic EDID block read helper.

Switch to the helper piecemeal, starting with drm_edid_get_panel_id(),
which doesn't need or have access to the connector anyway.

The subtle change is switching from drm_edid_block_valid() to
edid_block_check(). We also status print once, not for every attempt.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/47560f7530e4a7b32b56cb9038178244fe30a4af.1649685475.git.jani.nikula@intel.com


# 89fb7536 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add typedef for block read function

Make the callback a bit easier on the eye.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/10b8721bb7ea8c7df1fd0c1d97c5d446905abbf4.1649685475.git.jani.nikula@intel.com


# 63cae081 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: pass struct edid to connector_bad_edid()

Avoid casting here and there, and make it const.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4f9fdc961dfd9b36f4649e8ba57d05e43375fc92.1649685475.git.jani.nikula@intel.com


# 9c7345de 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add a helper to log dump an EDID block

Unify debug log dumping. There's duplication in the error paths for EDID
block validity checks, but this should be neglible.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b56f120a26f54b0defc43faa6d49e26f072d4d8f.1649685475.git.jani.nikula@intel.com


# cee2ce1a 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: refactor EDID block status printing

Split out a function to log EDID block status. The printouts get changed
slightly.

Unfortunately, not all users will have struct drm_device available, so
we convert to pr_* debug logging instead of drm device based logging.

v2: Complain more loudly about unknown status codes (Ville)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/98d12db95e55e2e18548822078ec3b16ae006732.1649685475.git.jani.nikula@intel.com


# 49dc0558 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: have edid_block_check() detect blocks that are all zero

We have the check function, have it also detect blocks that are all zero
instead of leaving that to callers.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f9ad302e6b7dbcd1dff98d94ec5500ce27bebe10.1649685475.git.jani.nikula@intel.com


# 8baccb27 11-Apr-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: convert edid_is_zero() to edid_block_is_zero() for blocks

As edid_is_zero() is only ever used on EDID blocks, convert it to
edid_block_is_zero() with implicit block size.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5cc9387e22b4a61243df4053d1ebcc14b0007dc8.1649685475.git.jani.nikula@intel.com


# 563c4a75 17-Feb-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Use drm_mode_init() for on-stack modes

Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.

Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;

@@
identifier decl.M;
expression decl.E;
statement S, S1;
@@
struct drm_display_mode M;
... when != S
+ drm_mode_init(&M, &E);
+
S1

@@
expression decl.E;
@@
- &*E
+ E

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-22-ville.syrjala@linux.intel.com
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>


# ab0609a5 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: reduce magic when updating the EDID block checksum

The code modifying the EDID block should not need to do tricks to fix
the checksum. We have a function for computing the checksum, use it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5a11435419d804a58ef356c0b9acf445cffc1354.1648752228.git.jani.nikula@intel.com


# ccc97def 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: track invalid blocks in drm_do_get_edid()

Track invalid blocks instead of valid extensions to minimize impact on
the happy day scenario, and hide the details in the separate function.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6215f85b01c579a44c66129d2b5f41e1ab9294de.1648752228.git.jani.nikula@intel.com


# 4ec53461 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: split out invalid block filtering to a separate function

It's such a special case there's no point in keeping it inline in the
happy day scenario, confusing matters.

v2: Rebase on the invalid block filtering fix

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ea8ccd654b5beca6ccf99666754aea09c836b6a5.1648752228.git.jani.nikula@intel.com


# 23e38d7b 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: simplify block check when filtering invalid blocks

There's no need to handle complicated scenarios or debug log when
filtering blocks that have already been identified as invalid. Simplify
by adding an edid_block_valid() helper that operates on const data and
prints nothing.

(Finally, here's the justification for the previously added separate
edid_block_status_valid() function!)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/aa25131c3454c7dbc1e8fdb46549f3787bdf6354.1648752228.git.jani.nikula@intel.com


# 18d83450 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: use a better variable name for EDID block read retries

Just i is a bit terse, clarify what it's about.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9c95c01445f5735332cbbd9eae6cd078e152050f.1648752228.git.jani.nikula@intel.com


# 1f221284 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: split drm_edid_block_valid() to check and act parts

Add edid_block_check() that only checks the EDID block validity, without
any actions. Turns out it's simple and crystal clear.

Rewrite drm_edid_block_valid() around it, keeping all the functionality
fairly closely the same, warts and all. Turns out it's incredibly
complicated for a function you'd expect to be simple, with all the
fixing and printing and special casing. (Maybe we'll want to simplify it
in the future.)

To slightly simplify, drop the warning for EDID minor revisions > 4.

v2:
- Fix edid_fixup clamp (Ville)
- s/base/is_base_block/ (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b7d108b69acccb7dccbdecc0ca06c2b3ca2e33ca.1648752228.git.jani.nikula@intel.com


# 0a612bbd 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: split out edid_header_fix()

Give a name to the EDID header fixup instead of having an inline memcpy.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c10c24b179e942548cd5d693d159bb0d12be4d26.1648752228.git.jani.nikula@intel.com


# aa6292a3 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: clean up edid_is_zero()

Simplify, rename, take void pointer. No need for the drm_ prefix for
internal helpers.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/15220580f07b63c92a3e448347cf59b297990407.1648752228.git.jani.nikula@intel.com


# 6d987ddd 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: make drm_edid_header_is_valid() accept void pointer

It will be useful to accept a struct edid *, but for compatibility with
existing usage accept void *.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/33fbe1615a3bd82112eaf4077bbb521793cbb91a.1648752228.git.jani.nikula@intel.com


# 4ba0f53c 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add edid_block_tag() helper to get the EDID extension tag

The extension tag at offset 0 is not present in struct edid, add a
helper for it to reduce the need to use u8 *.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3f27c67db63c186a48e83fdee2d1ac8a17714e78.1648752228.git.jani.nikula@intel.com


# 70e49ebe 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: clean up EDID block checksum functions

Have two clear functions, one to compute the checksum over the EDID, and
another to get the checksum from the EDID. Throw away the diff function.

Ditch the drm_ prefix for static functions, and accept const void * to
help transition to struct edid * usage.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/36641401c8eb0e403c0e33365ff4ad9a28f9fd4a.1648752228.git.jani.nikula@intel.com


# e9a9e076 31-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: use struct edid * in drm_do_get_edid()

Mixing u8 * and struct edid * is confusing, switch to the latter.

v2:
- Rebase on the invalid block filtering fix
- Rename struct edid *base to *dest_block for clarity (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/18bf820c1d20e616076b3275627e7ebf01bce7a3.1648752228.git.jani.nikula@intel.com


# 3aefc722 30-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: fix invalid EDID extension block filtering

The invalid EDID block filtering uses the number of valid EDID
extensions instead of all EDID extensions for looping the extensions in
the copy. This is fine, by coincidence, if all the invalid blocks are at
the end of the EDID. However, it's completely broken if there are
invalid extensions in the middle; the invalid blocks are included and
valid blocks are excluded.

Fix it by modifying the base block after, not before, the copy.

Fixes: 14544d0937bf ("drm/edid: Only print the bad edid when aborting")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220330170426.349248-1-jani.nikula@intel.com


# f40ab034 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: split drm_add_edid_modes() to two

Reduce the size of the function that actually modifies the EDID.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/437c3c79f68d1144444fb2dd18a678f3aa97272c.1648477901.git.jani.nikula@intel.com


# f4e558ec 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: add more general struct edid constness in the interfaces

With this, the remaining non-const parts are the ones that actually
modify the EDID, for example to fix corrupt EDID.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c7156f22494b585c55a00a6732462bde0cc19dbf.1648477901.git.jani.nikula@intel.com


# c14e7241 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: constify struct edid passed around in callbacks and closure

Finalize detailed timing parsing constness by making struct edid also
const in callbacks and closure.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8229be49b5a7686856c17428aa9291b4c4cf1bd5.1648477901.git.jani.nikula@intel.com


# eed628f1 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: constify struct edid passed to detailed blocks

Constify the first level of struct edid in detailed timing parsing. Also
switch to struct edid instead of u8.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ec7acb8a9ee0e2868bbb2afdfdd7db114ae180e1.1648477901.git.jani.nikula@intel.com


# 4194442d 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: constify struct detailed_timing in parsing callbacks

Moving one level higher, constify struct detailed_timing pointers in
callbacks.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9b617068d2349a574a837ad6207b1d45c4d79eb5.1648477901.git.jani.nikula@intel.com


# fcfb2ea1 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: constify struct detailed_timing in lower level parsing

Start constifying the struct detailed_timing pointers being passed
around from bottom up.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0b7fafcc7784db0003e454544916c273a9eb1250.1648477901.git.jani.nikula@intel.com


# c8a4beba 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: use struct detailed_timing member access in gtf2 functions

Use struct detailed_timing member access instead of direct offsets to
avoid casting.

Use BUILD_BUG_ON() for sanity check.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9fe5f5c39039e585fecfffb390297d49262e5fd3.1648477901.git.jani.nikula@intel.com


# 90fd588f 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: use struct detailed_timing member access in is_rb()

Use struct detailed_timing member access instead of direct offsets to
avoid casting.

Use BUILD_BUG_ON() for sanity check.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c069669c2fe8f9c3061c7d1a413c75a33ec48813.1648477901.git.jani.nikula@intel.com


# a9b1f15f 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: pass a timing pointer to is_detailed_timing_descriptor()

Use struct member access instead of direct offsets to avoid a cast.

Use BUILD_BUG_ON() for sanity check.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0b5213383e14f11c6a505b10a7342fb2ff4f2a11.1648477901.git.jani.nikula@intel.com


# e379814b 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: pass a timing pointer to is_display_descriptor()

Use struct member access instead of direct offsets to avoid lots of
casts all over the place.

Use BUILD_BUG_ON() for sanity check.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ccc54b45ea628874c0290dd64114da6cefff1819.1648477901.git.jani.nikula@intel.com


# 73091e4f 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: fix reduced blanking support check

The reduced blanking bit is valid only for CVT, indicated by display
range limits flags 0x04.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5dea5ee24065450716bbc177dd6850d3193dbeec.1648477901.git.jani.nikula@intel.com


# faacff8e 28-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: don't modify EDID while parsing

We'll want to keep the EDID immutable while parsing. Stop modifying the
EDID because of the quirks.

In theory, this does have userspace implications, but the userspace is
supposed to use the modes exposed via KMS API, not by parsing the EDID
directly.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/45d5cf067eaad49b321ac82836090d9de524374e.1648477901.git.jani.nikula@intel.com


# 7344bad7 22-Mar-2022 Jani Nikula <jani.nikula@intel.com>

drm/edid: fix CEA extension byte #3 parsing

Only an EDID CEA extension has byte #3, while the CTA DisplayID Data
Block does not. Don't interpret bogus data for color formats.

For most displays it's probably an unlikely scenario you'd have a CTA
DisplayID Data Block without a CEA extension, but they do exist.

Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID")
Cc: <stable@vger.kernel.org>
Cc: Shawn C Lee <shawn.c.lee@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323100438.1757295-1-jani.nikula@intel.com


# 5662abf6 24-Mar-2022 Cooper Chiou <cooper.chiou@intel.com>

drm/edid: check basic audio support on CEA extension block

Tag code stored in bit7:5 for CTA block byte[3] is not the same as
CEA extension block definition. Only check CEA block has
basic audio support.

v3: update commit message.

Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Shawn C Lee <shawn.c.lee@intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Signed-off-by: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220324061218.32739-1-shawn.c.lee@intel.com


# 70c0b80d 25-Jan-2022 Maxime Ripard <maxime@cerno.tech>

drm/edid: Clear EDID Deep Color Modes in drm_reset_display_info()

Even though we have the other drm_display_info fields reset, the DC
modes are missing.

This shouldn't be an issue since it's explicitly reset every time a new
EDID is parsed.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220125093251.594772-1-maxime@cerno.tech


# 80ecb5d7 23-Jan-2022 Yaroslav Bolyukin <iam@lach.pw>

drm/edid: Support type 7 timings

Per VESA DisplayID Standard v2.0: Type VII Timing – Detailed Timing Data

Definitions were already provided as type I, but not used

Signed-off-by: Yaroslav Bolyukin <iam@lach.pw>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220123191955.57994-1-iam@lach.pw


# c03d0b52 20-Jan-2022 Maxime Ripard <maxime@cerno.tech>

drm/connector: Fix typo in output format

The HDMI specification mentions YCbCr everywhere, but our enums have
YCrCb. Let's rename it to match.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-5-maxime@cerno.tech


# 4adc33f3 20-Jan-2022 Maxime Ripard <maxime@cerno.tech>

drm/edid: Split deep color modes between RGB and YUV444

The current code assumes that the RGB444 and YUV444 formats are the
same, but the HDMI 2.0 specification states that:

The three DC_XXbit bits above only indicate support for RGB 4:4:4 at
that pixel size. Support for YCBCR 4:4:4 in Deep Color modes is
indicated with the DC_Y444 bit. If DC_Y444 is set, then YCBCR 4:4:4
is supported for all modes indicated by the DC_XXbit flags.

So if we have YUV444 support and any DC_XXbit flag set but the DC_Y444
flag isn't, we'll assume that we support that deep colour mode for
YUV444 which breaks the specification.

In order to fix this, let's split the edid_hdmi_dc_modes field in struct
drm_display_info into two fields, one for RGB444 and one for YUV444.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-4-maxime@cerno.tech


# 75478b3b 20-Jan-2022 Maxime Ripard <maxime@cerno.tech>

drm/edid: Don't clear formats if using deep color

The current code, when parsing the EDID Deep Color depths, that the
YUV422 cannot be used, referring to the HDMI 1.3 Specification.

This specification, in its section 6.2.4, indeed states:

For each supported Deep Color mode, RGB 4:4:4 shall be supported and
optionally YCBCR 4:4:4 may be supported.

YCBCR 4:2:2 is not permitted for any Deep Color mode.

This indeed can be interpreted like the code does, but the HDMI 1.4
specification further clarifies that statement in its section 6.2.4:

For each supported Deep Color mode, RGB 4:4:4 shall be supported and
optionally YCBCR 4:4:4 may be supported.

YCBCR 4:2:2 is also 36-bit mode but does not require the further use
of the Deep Color modes described in section 6.5.2 and 6.5.3.

This means that, even though YUV422 can be used with 12 bit per color,
it shouldn't be treated as a deep color mode.

This is also broken with YUV444 if it's supported by the display, but
DRM_EDID_HDMI_DC_Y444 isn't set. In such a case, the code will clear
color_formats of the YUV444 support set previously in
drm_parse_cea_ext(), but will not set it back.

Since the formats supported are already setup properly in
drm_parse_cea_ext(), let's just remove the code modifying the formats in
drm_parse_hdmi_deep_color_info()

Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-3-maxime@cerno.tech


# 4a46e5d2 20-Jan-2022 Maxime Ripard <maxime@cerno.tech>

drm/edid: Rename drm_hdmi_avi_infoframe_colorspace to _colorimetry

The drm_hdmi_avi_infoframe_colorspace() function actually sets the
colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe
structure with DRM_MODE_COLORIMETRY_* values.

To make things worse, the hdmi_avi_infoframe structure also has a
colorspace field used to signal whether an RGB or YUV output is being
used.

Let's remove the inconsistency and allow for the colorspace usage by
renaming the function.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-2-maxime@cerno.tech


# ce99534e 27-Dec-2021 Jani Nikula <jani.nikula@intel.com>

drm/edid: improve non-desktop quirk logging

Improve non-desktop quirk logging if the EDID indicates non-desktop. If
both are set, note about redundant quirk. If there's no quirk but the
EDID indicates non-desktop, don't log non-desktop is set to 0.

Cc: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com>
Tested-by: Philipp Zabel <philipp.zabel@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211228101051.317989-1-jani.nikula@intel.com


# 50dc95d5 23-Jan-2022 Philipp Zabel <philipp.zabel@gmail.com>

drm/edid: remove non_desktop quirk for HPN-3515 and LEN-B800.

Now that there is support for the Microsoft VSDB for HMDs, remove the
non-desktop quirk for two devices that are verified to contain it in
their EDID: HPN-3515 and LEN-B800.
Presumably most of the other Windows Mixed Reality headsets contain it
as well, but there are ACR-7FCE and SEC-5194 devices without it.

Tested with LEN-B800.

Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220123101653.147333-2-philipp.zabel@gmail.com


# 2869f599 23-Jan-2022 Philipp Zabel <philipp.zabel@gmail.com>

drm/edid: support Microsoft extension for HMDs and specialized monitors

Add minimal support for parsing VSDBs documented in Microsoft's "EDID
extension for head-mounted and specialized monitors" [1]. The version
field and the desktop usage flag can be used to set the non_desktop
connector property.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specialized-monitors-edid-extension

Tested with HPN-36C1 and LEN-B800.

Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220123101653.147333-1-philipp.zabel@gmail.com


# ecbd4912 02-Feb-2022 Maxime Ripard <maxime@cerno.tech>

drm/edid: Always set RGB444

In order to fill the drm_display_info structure each time an EDID is
read, the code currently will call drm_add_display_info with the parsed
EDID.

drm_add_display_info will then call drm_reset_display_info to reset all
the fields to 0, and then set them to the proper value depending on the
EDID.

In the color_formats case, we will thus report that we don't support any
color format, and then fill it back with RGB444 plus the additional
formats described in the EDID Feature Support byte.

However, since that byte only contains format-related bits since the 1.4
specification, this doesn't happen if the EDID is following an earlier
specification. In turn, it means that for one of these EDID, we end up
with color_formats set to 0.

The EDID 1.3 specification never really specifies what it means by RGB
exactly, but since both HDMI and DVI will use RGB444, it's fairly safe
to assume it's supposed to be RGB444.

Let's move the addition of RGB444 to color_formats earlier in
drm_add_display_info() so that it's always set for a digital display.

Fixes: da05a5a71ad8 ("drm: parse color format support for digital displays")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203115416.1137308-1-maxime@cerno.tech


# e7bd95a7 04-Oct-2021 Douglas Anderson <dianders@chromium.org>

drm/edid: Fix crash with zero/invalid EDID

In the commit bac9c2948224 ("drm/edid: Break out reading block 0 of
the EDID") I broke out reading the base block of the EDID to its own
function. Unfortunately, when I did that I messed up the handling when
drm_edid_is_zero() indicated that we had an EDID that was all 0x00 or
when we went through 4 loops and didn't get a valid EDID. Specifically
I needed to pass the broken EDID to connector_bad_edid() but now I was
passing an error-pointer.

Let's re-jigger things so we can pass the bad EDID in properly.

Fixes: bac9c2948224 ("drm/edid: Break out reading block 0 of the EDID")
Reported-by: kernel test robot <oliver.sang@intel.com>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patchwork.freedesktop.org/patch/msgid/20211004092100.1.Ic90a5ebd44c75db963112be167a03cc96f9fb249@changeid


# 7d1be0a0 24-Sep-2021 Douglas Anderson <dianders@chromium.org>

drm/edid: Fix EDID quirk compile error on older compilers

Apparently some compilers [1] cannot handle doing math on dereferenced
string constants at compile time. This has led to reports [2] of
compile errors like:

In file included from drivers/gpu/drm/drm_edid.c:42:0:
./include/drm/drm_edid.h:525:2: error: initializer element is not constant
((((u32)((vend)[0]) - '@') & 0x1f) << 26 | \

Go back to the syntax I used in v4 of the patch series [3] that added
this code instead of what landed (v5). This syntax is slightly uglier
but should be much more compatible with varied compilers.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c18
[2] https://lore.kernel.org/r/874kaabdt5.fsf@intel.com/
[3] https://lore.kernel.org/r/20210909135838.v4.4.I6103ce2b16e5e5a842b14c7022a034712b434609@changeid/

Fixes: d9f91a10c3e8 ("drm/edid: Allow querying/working with the panel ID from the EDID")
Reported-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reported-by: Srikanth Myakam <smyakam@microsoft.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924075317.1.I1e58d74d501613f1fe7585958f451160d11b8a98@changeid


# e8de4d55 14-Sep-2021 Douglas Anderson <dianders@chromium.org>

drm/edid: Use new encoded panel id style for quirks matching

In the patch ("drm/edid: Allow the querying/working with the panel ID
from the EDID") we introduced a different way of working with the
panel ID stored in the EDID. Let's use this new way for the quirks
code.

Advantages of the new style:
* Smaller data structure size. Saves 4 bytes per panel.
* Iterate through quirks structure with just "==" instead of strncmp()
* In-kernel storage is more similar to what's stored in the EDID
itself making it easier to grok that they are referring to the same
value.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.4.I6103ce2b16e5e5a842b14c7022a034712b434609@changeid


# d9f91a10 14-Sep-2021 Douglas Anderson <dianders@chromium.org>

drm/edid: Allow querying/working with the panel ID from the EDID

EDIDs have 32-bits worth of data which is intended to be used to
uniquely identify the make/model of a panel. This has historically
been used only internally in the EDID processing code to identify
quirks with panels.

We'd like to use this panel ID in panel drivers to identify which
panel is hooked up and from that information figure out power sequence
timings. Let's expose this information from the EDID code and also
allow it to be accessed early, before a connector has been created.

To make matching in the panel drivers code easier, we'll return the
panel ID as a 32-bit value. We'll provide some functions for
converting this value back and forth to something more human readable.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.3.I4a672175ba1894294d91d3dbd51da11a8239cf4a@changeid


# bac9c294 14-Sep-2021 Douglas Anderson <dianders@chromium.org>

drm/edid: Break out reading block 0 of the EDID

A future change wants to be able to read just block 0 of the EDID, so
break it out of drm_do_get_edid() into a sub-function.

This is intended to be a no-op change--just code movement.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.2.I62e76a034ac78c994d40a23cd4ec5aeee56fa77c@changeid


# 18a9cbbe 31-Aug-2021 Jani Nikula <jani.nikula@intel.com>

drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

The VESA Organization Vendor-Specific Data Block, defined in VESA
DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
stream count and segment pixel overlap.

DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
describing how DisplayID sections may be embedded in EDID extension
blocks. DisplayID v2.0 does not have such a section, perhaps implying
that DisplayID v2.0 data should not be included in EDID extensions, but
rather in a "pure" DisplayID structure at its own DDC address pair
A4h/A5h, as described in VESA E-DDC Standard v1.3 chapter 3.

However, in practice, displays out in the field have embedded DisplayID
v2.0 data blocks in EDID extensions, including, in particular, some eDP
MSO displays, where a pure DisplayID structure is not available at all.

Parse the MSO data from the DisplayID data block. Do it as part of
drm_add_display_info(), extending it to parse also DisplayID data to
avoid requiring extra calls to update the information.

v2: Check for VESA OUI (Ville)

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/73ca2887e7b37880690f5c9ba4594c9cd1170669.1630419362.git.jani.nikula@intel.com


# 37eab1fe 31-Aug-2021 Jani Nikula <jani.nikula@intel.com>

drm/edid: abstract OUI conversion to 24-bit int

Replace the open coded OUI conversion from three bytes to a 24-bit int,
as we'll be adding one more user shortly. No functional changes.

Side note: CTA-861 format has the OUI bytes in reverse order.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2f43032d5f001510c7eed059321ceeb76d07a606.1630419362.git.jani.nikula@intel.com


# 97794170 05-Oct-2021 Douglas Anderson <dianders@chromium.org>

drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read

In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.

Let's fix this by adding a bounds check.

This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() without having re-allocated memory based on
`edid[0x7e]`.

Fixes: e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005192905.v2.1.Ib059f9c23c2611cb5a9d760e7d0a700c1295928d@changeid
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 0ae865ef 30-Jul-2021 Cai Huoqing <caihuoqing@baidu.com>

drm: Fix typo in comments

fix typo for drm

v1->v2:
respin with the change "iff ==> implies that"

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210730132729.376-1-caihuoqing@baidu.com


# bfd4e192 29-Mar-2021 Jani Nikula <jani.nikula@intel.com>

drm/edid: use the new displayid iterator for tile info

Neatly reduce displayid boilerplate in code. Remove excessive debug
logging while at it, no other functional changes.

The old displayid iterator becomes unused; remove it as well as make
drm_find_displayid_extension() static.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fa4b5c790b5bdd82063545a6f209f8e9d78a63a7.1617024940.git.jani.nikula@intel.com


# 1ba63caf 29-Mar-2021 Jani Nikula <jani.nikula@intel.com>

drm/edid: use the new displayid iterator for finding CEA extension

Neatly reduce displayid boilerplate in code. No functional changes.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e50f876cecbfee369da887ad19350eee0d89b87f.1617024940.git.jani.nikula@intel.com


# 5ef88dc5 29-Mar-2021 Jani Nikula <jani.nikula@intel.com>

drm/edid: use the new displayid iterator for detailed modes

Neatly reduce displayid boilerplate in code. No functional changes.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f6c69c545c553c4a616887540660a4b8aecf0f7f.1617024940.git.jani.nikula@intel.com


# 4cc4f09e 29-Mar-2021 Jani Nikula <jani.nikula@intel.com>

drm/displayid: add separate drm_displayid.c

We'll be adding more DisplayID specific functions going forward, so
start off by splitting out a few functions to a separate file.

We don't bother with exporting the functions; at least for now they
should be needed solely within drm.ko.

No functional changes.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/07942d5011891b8e8f77245c78b34f4af97a9315.1617024940.git.jani.nikula@intel.com


# 43d16d84 29-Mar-2021 Jani Nikula <jani.nikula@intel.com>

drm/edid: make a number of functions, parameters and variables const

If there's no need to change it, it should be const. There's more to be
done, but start off with changes that make follow-up work easier. No
functional changes.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/41722f92ef81cd6adf65f936fcc5301418e1f94b.1617024940.git.jani.nikula@intel.com


# 36b73b05 18-Jan-2021 Thomas Zimmermann <tzimmermann@suse.de>

drm: Upcast struct drm_device.dev to struct pci_device; replace pdev

We have DRM drivers based on USB, SPI and platform devices. All of them
are fine with storing their device reference in struct drm_device.dev.
PCI devices should be no exception. Therefore struct drm_device.pdev is
deprecated.

Instead upcast from struct drm_device.dev with to_pci_dev(). PCI-specific
code can use dev_is_pci() to test for a PCI device. This patch changes
the DRM core code and documentation accordingly.

v4:
* split-off pdev deprecation into separate patch

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Andy Lavr <andy.lavr@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210118131420.15874-2-tzimmermann@suse.de


# 76ee7b90 18-Dec-2020 Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/edid: Parse DSC1.2 cap fields from HFVSDB block

This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.

v2: Addressed following issues as suggested by Uma Shankar:
-Added a new struct for hdmi dsc cap
-Fixed bugs in macros usage.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
[Jani: Fixed checkpatch PARENTHESIS_ALIGNMENT.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-4-ankit.k.nautiyal@intel.com


# 4499d488 18-Dec-2020 Swati Sharma <swati2.sharma@intel.com>

drm/edid: Parse MAX_FRL field from HFVSDB block

This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.

v2: Fixed minor bugs, and removed extra wrapper function (Uma Shankar)

Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
[Jani: Fixed checkpatch FROM_SIGN_OFF_MISMATCH, PARENTHESIS_ALIGNMENT.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-3-ankit.k.nautiyal@intel.com


# d652d5f1 17-Dec-2020 Linus Torvalds <torvalds@linux-foundation.org>

drm/edid: fix objtool warning in drm_cvt_modes()

Commit 991fcb77f490 ("drm/edid: Fix uninitialized variable in
drm_cvt_modes()") just replaced one warning with another.

The original warning about a possibly uninitialized variable was due to
the compiler not being smart enough to see that the case statement
actually enumerated all possible cases. And the initial fix was just to
add a "default" case that had a single "unreachable()", just to tell the
compiler that that situation cannot happen.

However, that doesn't actually fix the fundamental reason for the
problem: the compiler still doesn't see that the existing case
statements enumerate all possibilities, so the compiler will still
generate code to jump to that unreachable case statement. It just won't
complain about an uninitialized variable any more.

So now the compiler generates code to our inline asm marker that we told
it would not fall through, and end end result is basically random. We
have created a bridge to nowhere.

And then, depending on the random details of just exactly what the
compiler ends up doing, 'objtool' might end up complaining about the
conditional branches (for conditions that cannot happen, and that thus
will never be taken - but if the compiler was not smart enough to figure
that out, we can't expect objtool to do so) going off in the weeds.

So depending on how the compiler has laid out the result, you might see
something like this:

drivers/gpu/drm/drm_edid.o: warning: objtool: do_cvt_mode() falls through to next function drm_mode_detailed.isra.0()

and now you have a truly inscrutable warning that makes no sense at all
unless you start looking at whatever random code the compiler happened
to generate for our bare "unreachable()" statement.

IOW, don't use "unreachable()" unless you have an _active_ operation
that generates code that actually makes it obvious that something is not
reachable (ie an UD instruction or similar).

Solve the "compiler isn't smart enough" problem by just marking one of
the cases as "default", so that even when the compiler doesn't otherwise
see that we've enumerated all cases, the compiler will feel happy and
safe about there always being a valid case that initializes the 'width'
variable.

This also generates better code, since now the compiler doesn't generate
comparisons for five different possibilities (the four real ones and the
one that can't happen), but just for the three real ones and "the rest"
(which is that last one).

A smart enough compiler that sees that we cover all the cases won't care.

Cc: Lyude Paul <lyude@redhat.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 991fcb77 05-Nov-2020 Lyude Paul <lyude@redhat.com>

drm/edid: Fix uninitialized variable in drm_cvt_modes()

Noticed this when trying to compile with -Wall on a kernel fork. We
potentially don't set width here, which causes the compiler to complain
about width potentially being uninitialized in drm_cvt_modes(). So, let's
fix that.

Changes since v1:
* Don't emit an error as this code isn't reachable, just mark it as such
Changes since v2:
* Remove now unused variable

Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage")
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Link: https://patchwork.freedesktop.org/patch/msgid/20201105235703.1328115-1-lyude@redhat.com


# fa3bfa35 29-Oct-2020 Chris Wilson <chris@chris-wilson.co.uk>

drm: Quieten [zero] EDID carping

We have a few displays in CI that always report their EDID as a bunch of
zeroes. This is consistent behaviour, so one assumes intentional
indication of an "absent" EDID. Flagging these consistent warnings
detracts from CI.

One option would be to ignore the zero EDIDs as intentional behaviour,
but Ville would like to keep the information available for debugging.
The simple alternative then is to reduce the loglevel for all the EDID
dumping from WARN to DEBUG so the information is present but not annoy
CI. Note that the bad EDID dumping is already only shown if
drm.debug=KMS, it's just the loglevel chosen was set to be caught by CI
if it ever occurred as it was expected to be an internal error not
external.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2203
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029213042.11672-1-chris@chris-wilson.co.uk


# 8d7d8c0a 27-Oct-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

drm/dp: fix a kernel-doc issue at drm_edid.c

The name of the argument is different, causing those warnings:

./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member 'video_code' not described in 'drm_display_mode_from_cea_vic'
./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter 'vic' description in 'drm_display_mode_from_cea_vic'

Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/7f4d6c3ff6df63ebd006eb90a5108006c23e2168.1603791716.git.mchehab+huawei@kernel.org


# 94a4fb8a 22-Sep-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

drm/dp: fix a kernel-doc issue at drm_edid.c

The name of the argument is different, causing those warnings:

./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member 'video_code' not described in 'drm_display_mode_from_cea_vic'
./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter 'vic' description in 'drm_display_mode_from_cea_vic'

Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200922175357.42998-3-lyude@redhat.com


# 7af655bc 04-Sep-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/dp: Add drm_dp_downstream_mode()

The downstream facing port caps in the DPCD can give us a hint
as to what kind of display mode the sink can use if it doesn't
have an EDID. Use that information to pick a suitable mode.

v2: Use Returns: for kdoc (Lyude)
Add kdocs for drm_display_mode_from_cea_vic() (Lyude)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-14-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 6d45fff5 18-Jul-2020 Suraj Upadhyay <usuraj35@gmail.com>

drm: core: Convert device logging to drm_* functions.

Convert device logging with dev_* functions into drm_* functions.

The patch has been generated with the coccinelle script below.
The script focuses on instances of dev_* functions where the drm device
context is clearly visible in its arguments.

@@expression E1; expression list E2; @@
-dev_warn(E1->dev, E2)
+drm_warn(E1, E2)

@@expression E1; expression list E2; @@
-dev_info(E1->dev, E2)
+drm_info(E1, E2)

@@expression E1; expression list E2; @@
-dev_err(E1->dev, E2)
+drm_err(E1, E2)

@@expression E1; expression list E2; @@
-dev_info_once(E1->dev, E2)
+drm_info_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_notice_once(E1->dev, E2)
+drm_notice_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_warn_once(E1->dev, E2)
+drm_warn_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_err_once(E1->dev, E2)
+drm_err_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_err_ratelimited(E1->dev, E2)
+drm_err_ratelimited(E1, E2)

@@expression E1; expression list E2; @@
-dev_dbg(E1->dev, E2)
+drm_dbg(E1, E2)

Signed-off-by: Suraj Upadhyay <usuraj35@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200718150955.GA23103@blackclown


# 3f649ab7 03-Jun-2020 Kees Cook <keescook@chromium.org>

treewide: Remove uninitialized_var() usage

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.

In preparation for removing[2] the[3] macro[4], remove all remaining
needless uses with the following script:

git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
xargs perl -pi -e \
's/\buninitialized_var\(([^\)]+)\)/\1/g;
s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'

drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
pathological white-space.

No outstanding warnings were found building allmodconfig with GCC 9.3.0
for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
alpha, and m68k.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/
[2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/
[3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/

Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5
Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB
Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers
Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs
Signed-off-by: Kees Cook <keescook@chromium.org>


# 392f9fcb 27-May-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Clean up some curly braces

Drop some pointless curly braces, and add some across the
else when the if has them too.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200527130310.27099-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>


# 7f261afd 27-May-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Iterate through all DispID ext blocks

Apparently there are EDIDs in the wild with multiple DispID extension
blocks. Iterate through them all.

In one particular case the tile information is specicied in the
second DispID ext block, and since the current parser only looks
at the first DispID ext block we don't notice that we're dealing
with a tiled display.

While at it change a few functions to return void since we have
no use for the errno.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/27
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200527130310.27099-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>


# 8873cfa3 27-May-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Allow looking for ext blocks starting from a specified index

Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
for iterating through multiple ext blocks of the same type by
passing the starting ext block index to drm_find_edid_extension(). Well
also have drm_find_edid_extension() update the index to point to the
next ext block on success. Thus we should be able to call
drm_find_edid_extension() in loop.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200527130310.27099-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>


# 948de842 02-Jul-2020 Suraj Upadhyay <usuraj35@gmail.com>

drm : Insert blank lines after declarations.

Resolve checkpatch issues for missing blank lines after declarations.
Issues found in multiple files with checkpatch.pl.

Signed-off-by: Suraj Upadhyay <usuraj35@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200702131749.GA25710@blackclown


# 5186421c 29-Jun-2020 Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm: Introduce epoch counter to drm_connector

This counter will be used by drm_helper_probe_detect caller to determine
if anything had changed(including edid, connection status and etc).
Hardware specific driver detect hooks are responsible for updating this
counter when some change is detected to notify the drm part,
which can trigger for example hotplug event.

Also now call drm_connector_update_edid_property
right after we get edid always to make sure there is a
unified way to handle edid change, without having to
change tons of source code as currently
drm_connector_update_edid_property is called only in
certain cases like reprobing and not right after edid is
actually updated.

v2: Added documentation for the new counter. Rename change_counter to
epoch_counter.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105540

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630002700.5451-3-kunal1.joshi@intel.com


# 536faa45 29-Jun-2020 Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm: Add helper to compare edids.

Many drivers would benefit from using
drm helper to compare edid, rather
than bothering with own implementation.

v2: Added documentation for this function.

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630002700.5451-2-kunal1.joshi@intel.com


# 192a3aa0 25-May-2020 Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: edid: Constify connector argument to infoframe functions

The drm_hdmi_avi_infoframe_from_display_mode(),
drm_hdmi_vendor_infoframe_from_display_mode() and
drm_hdmi_avi_infoframe_quant_range() functions take a drm_connector that
they don't modify. Mark it as const.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200526011505.31884-10-laurent.pinchart+renesas@ideasonboard.com


# 0425662f 28-Apr-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Nuke mode->vrefresh

Get rid of mode->vrefresh and just calculate it on demand. Saves
a bit of space and avoids the cached value getting out of sync
with reality.

Mostly done with cocci, with the following manual fixups:
- Remove the now empty loop in drm_helper_probe_single_connector_modes()
- Fix __MODE() macro in ch7006_mode.c
- Fix DRM_MODE_ARG() macro in drm_modes.h
- Remove leftover comment from samsung_s6d16d0_mode
- Drop the TODO

@@
@@
struct drm_display_mode {
...
- int vrefresh;
...
};

@@
identifier N;
expression E;
@@
struct drm_display_mode N = {
- .vrefresh = E
};

@@
identifier N;
expression E;
@@
struct drm_display_mode N[...] = {
...,
{
- .vrefresh = E
}
,...
};

@@
expression E;
@@
{
DRM_MODE(...),
- .vrefresh = E,
}

@@
identifier M, R;
@@
int drm_mode_vrefresh(const struct drm_display_mode *M)
{
...
- if (M->vrefresh > 0)
- R = M->vrefresh;
- else
if (...) {
...
}
...
}

@@
struct drm_display_mode *p;
expression E;
@@
(
- p->vrefresh = E;
|
- p->vrefresh
+ drm_mode_vrefresh(p)
)

@@
struct drm_display_mode s;
expression E;
@@
(
- s.vrefresh = E;
|
- s.vrefresh
+ drm_mode_vrefresh(&s)
)

@@
expression E;
@@
- drm_mode_vrefresh(E) ? drm_mode_vrefresh(E) : drm_mode_vrefresh(E)
+ drm_mode_vrefresh(E)

@find_substruct@
identifier X;
identifier S;
@@
struct X {
...
struct drm_display_mode S;
...
};

@@
identifier find_substruct.S;
expression E;
identifier I;
@@
{
.S = {
- .vrefresh = E
}
}

@@
identifier find_substruct.S;
identifier find_substruct.X;
expression E;
identifier I;
@@
struct X I[...] = {
...,
.S = {
- .vrefresh = E
}
,...
};

v2: Drop TODO
v3: Rebase
v4: Rebase

Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jerry Han <hanxu5@huaqin.corp-partner.google.com>
Cc: Icenowy Zheng <icenowy@aosc.io>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Stefan Mavrodiev <stefan@olimex.com>
Cc: Robert Chiras <robert.chiras@nxp.com>
Cc: "Guido Günther" <agx@sigxcpu.org>
Cc: Purism Kernel Team <kernel@puri.sm>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: linux-amlogic@lists.infradead.org
Cc: nouveau@lists.freedesktop.org
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-4-ville.syrjala@linux.intel.com


# 5a3f6108 07-May-2020 Jan Schmidt <jan@centricular.com>

drm/edid: Add Oculus Rift S to non-desktop list

Add a quirk for the Oculus Rift S OVR0012 display so
it shows up as a non-desktop display.

Signed-off-by: Jan Schmidt <jan@centricular.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507180628.740936-1-jan@centricular.com


# 58911c24 28-Apr-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Nuke mode->hsync

Let's just calculate the hsync rate on demand. No point in wasting
space storing it and risking the cached value getting out of sync
with reality.

v2: Move drm_mode_hsync() next to its only users
Drop the TODO

Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-2-ville.syrjala@linux.intel.com


# 6292b8ef 23-Apr-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fix off-by-one in DispID DTD pixel clock

The DispID DTD pixel clock is documented as:
"00 00 00 h → FF FF FF h | Pixel clock ÷ 10,000 0.01 → 167,772.16 Mega Pixels per Sec"
Which seems to imply that we to add one to the raw value.

Reality seems to agree as there are tiled displays in the wild
which currently show a 10kHz difference in the pixel clock
between the tiles (one tile gets its mode from the base EDID,
the other from the DispID block).

Cc: stable@vger.kernel.org
References: https://gitlab.freedesktop.org/drm/intel/-/issues/27
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200423151743.18767-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>


# 092c367a 13-Mar-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fix DispID tile parsing for override EDID

Currently the DispID tile block gets parsed in drm_get_edid(), which
is an odd place for it considering we parse nothing else there. Also
this doesn't work for override EDIDs since
drm_connector_update_edid_property() refuses to do its job twice
in such cases. Thus we never update the tile property with results
of the DispID tile block parsing during drm_get_edid().

To fix this let's just move the tile block parsing to happen during
drm_connector_update_edid_property(), which is where we parse a bunch
of other stuff as well (and where we update both the EDID and tile
properties).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-10-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# bd1f64df 13-Mar-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Clarify validate_displayid()

Throw out the magic '5' from validate_displayid() and replace with
the actual thing we mean sizeof(header)+checksum. Also rewrite the
checksum loop to be less hard to parse for mere mortals.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-9-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# 5f706b4a 13-Mar-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Don't include ext block csum in DispID size

The EDID extension block checksum byte is not part of the
actual DispID data, so don't use it in validate_displayid().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-8-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# 8e88c752 13-Mar-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Don't parse garbage as DispID blocks

Currently the code assumes that the entire EDID extesion block
can be taken up by the DispID blocks. That is not true. There
is at least always the DispID checksum, and potentially fill
bytes if the extension block uses the interior fill scheme
to pad out to fill EDID block size.

So let's not parse the checksum or the fill bytes as DispID
blocks by having drm_find_displayid_extension() return the
actual length of the DispID data to the caller.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-7-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# ea0aa608 13-Mar-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Move validate_displayid() drm_find_displayid_extension()

Instead of everyone having to call validate_displayid() let's just
have drm_find_displayid_extension() do it for them.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-6-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# 23b03867 13-Mar-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Return DispID length from drm_find_displayid_extension()

As with the byte offset (idx) drm_find_displayid_extension() is
the only one who actually knows how much data the resulting DispID
block can contain. So return the length from therein instead of
assuming it's the EDID block length all over.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-5-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# 36881184 13-Mar-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Remove idx==1 assumptions from all over the DispID parsing

The fact that the DispID starts at byte offset 1 is due to
the DispID coming from and EDID extension block (the first byte
being the extesion block tag). Instead of hadrdocoding that idx==1
assumptions all over let's just have drm_find_displayid_extension()
return it since it actually knows what it's talking about.

If at some point someone comes across a DispID which is not embedded
inside an EDID the function that returns the new type of DispID
can return it's own byte offset without having to updated all the
code.

TODO: should probably just get rid of that idx thing altogether
and just return the thing we want directly.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-4-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# deec222e 06-Mar-2020 Kees Cook <keescook@chromium.org>

drm/edid: Distribute switch variables for initialization

Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get initialized). Clang's automatic stack variable initialization
(via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
doesn't initialize such variables[1]. Note that these warnings (or silent
skipping) happen before the dead-store elimination optimization phase,
so even when the automatic initializations are later elided in favor of
direct initializations, the warnings remain.

To avoid these problems, lift such variables up into the next code
block.

drivers/gpu/drm/drm_edid.c: In function ‘drm_edid_to_eld’:
drivers/gpu/drm/drm_edid.c:4395:9: warning: statement will never be
executed [-Wswitch-unreachable]
4395 | int sad_count;
| ^~~~~~~~~

[1] https://bugs.llvm.org/show_bug.cgi?id=44916

v2: move into function block instead being switch-local (Ville Syrjälä)

Signed-off-by: Kees Cook <keescook@chromium.org>
[danvet: keep the changelog]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/202003060930.DDCCB6659@keescook


# a1d11d1e 10-Mar-2020 Manasi Navare <manasi.d.navare@intel.com>

drm/edid: Add function to parse EDID descriptors for monitor range

Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_freesync_caps() to make it generic and be used
across all DRM drivers

v6:
* Call it monitor_range (Ville)
v5:
* Use the renamed flags
v4:
* Use is_display_descriptor() (Ville)
* Name the monitor range flags (Ville)
v3:
* Remove the edid parsing restriction for just DP (Nicholas)
* Use drm_for_each_detailed_block (Ville)
* Make the drm_get_adaptive_sync_range function static (Harry, Jani)
v2:
* Change vmin and vmax to use u8 (Ville)
* Dont store pixel clock since that is just a max dotclock
and not related to VRR mode (Manasi)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310231651.13841-2-manasi.d.navare@intel.com


# a92d083d 26-Feb-2020 Laurent Pinchart <laurent.pinchart@ideasonboard.com>

drm/edid: Add flag to drm_display_info to identify HDMI sinks

The drm_display_info structure contains many fields related to HDMI
sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
populate it according to section 8.3.3 ("DVI/HDMI Device
Discrimination") of the HDMI v1.3 specification.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-4-laurent.pinchart@ideasonboard.com


# 5ee0caf1 26-Feb-2020 Laurent Pinchart <laurent.pinchart@ideasonboard.com>

video: hdmi: Change return type of hdmi_avi_infoframe_init() to void

The hdmi_avi_infoframe_init() never needs to return an error, change its
return type to void.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-2-laurent.pinchart@ideasonboard.com


# 5036c0d0 24-Jan-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add a FIXME about DispID CEA data block revision

I don't understand what the DispID CEA data block revision
means. The spec doesn't say. I guess some DispID must have
a value of >= 3 in there or else we generally wouldn't
even parse the CEA data blocks. Or does all this code
actually not do anything?

Cc: Andres Rodriguez <andresx7@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124200231.10517-6-ville.syrjala@linux.intel.com
Reviewed-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>


# 6e8a942b 24-Jan-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Document why we don't bounds check the DispID CEA block start/end

After much head scratching I managed to convince myself that
for_each_displayid_db() has already done the bounds checks for
the DispID CEA data block. Which is why we don't need to repeat
them in cea_db_offsets(). To avoid having to go through that
pain again in the future add a comment which explains this fact.

Cc: Andres Rodriguez <andresx7@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124200231.10517-5-ville.syrjala@linux.intel.com
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>


# 4d23f484 24-Jan-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Clear out spurious whitespace

Nuke some whitespace that shouldn't be there.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124200231.10517-4-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>


# f447dd1f 24-Jan-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Introduce is_detailed_timing_descritor()

Let's introduce is_detailed_timing_descritor() as the opposite
counterpart of is_display_descriptor().

Cc: Allen Chen <allen.chen@ite.com.tw>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124200231.10517-3-ville.syrjala@linux.intel.com
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>


# a7a131ac 24-Jan-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Don't accept any old garbage as a display descriptor

Currently we assume any 18 byte descriptor to be a display descritor
if only the tag byte matches the expected value. But for detailed
timing descriptors that same byte is just the lower 8 bits of
hblank, and as such can match any display descriptor tag. To
properly validate that the 18 byte descriptor is in fact a
display descriptor we must also examine bytes 0-2 (just byte 1
should actually suffice but the spec does say that bytes 0 and
2 must also always be zero for display descriptors so we check
those too).

Unlike Allen's original proposed patch to just fix is_rb() we
roll this out across the board to fix everything.

Cc: Allen Chen <allen.chen@ite.com.tw>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124200231.10517-2-ville.syrjala@linux.intel.com
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>


# 7304b981 24-Jan-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Check the number of detailed timing descriptors in the CEA ext block

CEA-861 says :
"d = offset for the byte following the reserved data block.
If no data is provided in the reserved data block, then d=4.
If no DTDs are provided, then d=0."

So let's not look for DTDs when d==0. In fact let's just make that
<4 since those values would just mean that he DTDs overlap the block
header. And let's also check that d isn't so big as to declare
the descriptors to live past the block end, although the code
does already survive that case as we'd just end up with a negative
number of descriptors and the loop would not do anything.

Cc: Allen Chen <allen.chen@ite.com.tw>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124200231.10517-1-ville.syrjala@linux.intel.com
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>


# e11f5bd8 11-Feb-2020 Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>

drm: Add support for DP 1.4 Compliance edid corruption test

Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
real CRC value of the last edid data block, and write it back.
Current edid CRC calculates routine adds the last CRC byte,
and check if non-zero.

This behavior is not accurate; actually, we need to return
the actual CRC value when corruption is detected.
This commit changes this issue by returning the calculated CRC,
and initiate the required sequence.

Change since v7
- Fix for CI.CHECKPATCH

Change since v6
- Add return check

Change since v5
- Obtain real CRC value before dumping bad edid

Change since v4
- Fix for CI.CHECKPATCH

Change since v3
- Fix a minor typo.

Change since v2
- Rewrite checksum computation routine to avoid duplicated code.
- Rename to avoid confusion.

Change since v1
- Have separate routine for returning real CRC.

Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211160832.24259-1-Jerry.Zuo@amd.com


# e1cf35b9 03-Feb-2020 Mauro Rossi <issor.oruam@gmail.com>

drm/edid: fix building error

Fixes the following building error:

CC [M]  drivers/gpu/drm/drm_edid.o
~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c: In function 'cea_mode_alternate_timings':
~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c:3275:2: error: call to '__compiletime_assert_3282'
declared with attribute error: BUILD_BUG_ON failed: cea_mode_for_vic(8)->vtotal != 262 || cea_mode_for_vic(9)->vtotal != 262 || cea_mode_for_vic(12)->vtotal != 262 || cea_mode_for_vic(13)->vtotal != 262 || cea_mode_for_vic(23)->vtotal != 312 || cea_mode_for_vic(24)->vtotal != 312 || cea_mode_for_vic(27)->vtotal != 312 || cea_mode_for_vic(28)->vtotal != 312
make[4]: *** [~/pie-x86_kernel/kernel/scripts/Makefile.build:265: drivers/gpu/drm/drm_edid.o] Error 1

Fixes: 7befe621ff81 ("drm/edid: Abstract away cea_edid_modes[]")
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200203213113.28183-1-issor.oruam@gmail.com


# dbe2d2bf 06-Dec-2019 Thierry Reding <treding@nvidia.com>

drm: Fix a couple of typos, punctation and whitespace issues

These are just a couple of things that I came across as I was reading
through the code and comments.

v2: added one more hunk that ended up in the wrong patch

Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206135336.2084564-1-thierry.reding@gmail.com


# 9212f8ee 13-Dec-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Make sure the CEA mode arrays have the correct amount of modes

We depend on a specific relationship between the VIC number and the
index in the CEA mode arrays. Assert that the arrays have the expected
size to make sure we've not accidentally left holes in them.

v2: Pimp the BUILD_BUG_ON()s
v3: Fix typos (Manasi)

Cc: Hans Verkuil <hansverk@cisco.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Thomas Anderson <thomasanderson@google.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213174348.27261-5-ville.syrjala@linux.intel.com


# 8c1b2bd9 13-Dec-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Throw away the dummy VIC 0 cea mode

Now that the cea mode handling is not 100% tied to the single
array the dummy VIC 0 mode is pretty much pointles. Throw it
out.

v2: Rebase

Cc: Tom Anderson <thomasanderson@google.com>
Cc: Hans Verkuil <hansverk@cisco.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213174348.27261-4-ville.syrjala@linux.intel.com
Reviewed-by: Thomas Anderson <thomasanderson@google.com>


# f7655d42 13-Dec-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add CTA-861-G modes with VIC >= 193

Add a second table to the cea modes with VIC >= 193.

v2: Improve the comment for cea_modes_*[] to indicate
that one should always use cea_mode_for_vic() (Tom)

Cc: Hans Verkuil <hansverk@cisco.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Thomas Anderson <thomasanderson@google.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213174348.27261-3-ville.syrjala@linux.intel.com


# 7befe621 13-Dec-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Abstract away cea_edid_modes[]

We're going to need two cea mode tables (one for VICs < 128,
another one for VICs >= 193). To that end replace the direct
edid_cea_modes[] lookups with a function call. And we'll rename
the array to edid_cea_modes_0[] to indicate how it's to be
indexed.

v2: Fix typos (Tom)
Drop the pointless NULL checks in the loops (Tom)
Assign when declaring (Tom)
Improve the comment for cea_modes_*[] to indicate
that one should always use cea_mode_for_vic() (Tom)

Cc: Tom Anderson <thomasanderson@google.com>
Cc: Hans Verkuil <hansverk@cisco.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213174348.27261-2-ville.syrjala@linux.intel.com
Reviewed-by: Thomas Anderson <thomasanderson@google.com>


# 304a94a2 18-Nov-2019 Wayne Lin <Wayne.Lin@amd.com>

drm/edid: Add alternate clock for SMPTE 4K

[Why]
In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
mode (4096x2160@24) due to there is no alternate clock defined for
that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.

[How]
Remove the exception

v2: Adjust the comment description of hdmi_mode_alternate_clock()
due to there is no more exception for VIC 4 mode.

Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118101832.15487-2-Wayne.Lin@amd.com


# d2b43473 18-Nov-2019 Wayne Lin <Wayne.Lin@amd.com>

drm/edid: Add aspect ratios to HDMI 4K modes

[Why]
HDMI 2.0 adds aspect ratio attribute to distinguish different
4k modes. According to Appendix E of HDMI 2.0 spec, source should
use VSIF to indicate video mode only when the mode is one defined
in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC.

Current code doesn't take aspect ratio into consideration while
constructing avi infoframe. Should modify that.

[How]
Inherit Ville Syrjälä's work
"drm/edid: Prep for HDMI VIC aspect ratio" at
https://patchwork.kernel.org/patch/11174639/

Add picture_aspect_ratio attributes to edid_4k_modes[] and
construct VIC and HDMI_VIC by taking aspect ratio into
consideration.

v2: Correct missing initializer error at adding aspect ratio of
SMPTE mode.

Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118101832.15487-1-Wayne.Lin@amd.com


# 42908007 15-Nov-2019 Jean Delvare <jdelvare@suse.de>

drm/edid: no CEA v3 extension is not an error

It is fine for displays without audio functionality to not implement
CEA v3 extension in their EDID. Do not return an error in that case,
instead return 0 as if there was a CEA v3 extension with no audio or
speaker block.

This fixes the second half of bug fdo#107825:
https://bugs.freedesktop.org/show_bug.cgi?id=107825

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115170736.7d88593d@endymion


# 076d9a5d 08-Oct-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add drm_hdmi_avi_infoframe_bars()

Add a function to fill the AVI infoframe bar information from
the standard tv margin properties.

Cc: Eric Anholt <eric@anholt.net>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008164814.5894-1-ville.syrjala@linux.intel.com
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>


# 949561eb 04-Oct-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fix HDMI VIC handling

Extract drm_mode_hdmi_vic() to correctly calculate the final HDMI
VIC for us. Currently this is being done a bit differently between
the AVI and HDMI infoframes. Let's get both to agree on this.

We need to allow the case where a mode is both 3D and has a HDMI
VIC. Currently we'll just refuse to generate the HDMI infoframe when
we really should be setting HDMI VIC to 0 and instead enabling 3D
stereo signalling.

If the sink doesn't even support the HDMI infoframe we should
not be picking the HDMI VIC in favor of the CEA VIC, because then
we'll end up not sending either VIC in the end.

Cc: Wayne Lin <waynelin@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004141914.20600-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>


# cfd6f8c3 04-Oct-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Extract drm_mode_cea_vic()

Extract the logic to compute the final CEA VIC to a small helper.
We'll reorder it a bit to make future modifications more
straightforward. No function changes.

Cc: Wayne Lin <waynelin@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004141914.20600-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>


# 28c03a44 04-Oct-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Make drm_get_cea_aspect_ratio() static

drm_get_cea_aspect_ratio() is not used outside drm_edid.c.
Make it static.

Cc: Wayne Lin <waynelin@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004141914.20600-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>


# 11bcf5f7 01-Apr-2019 Kai-Heng Feng <kai.heng.feng@canonical.com>

drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50

Another panel that needs 6BPC quirk.

BugLink: https://bugs.launchpad.net/bugs/1819968
Cc: <stable@vger.kernel.org> # v4.8+
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190402033037.21877-1-kai.heng.feng@canonical.com


# bfef04ad 07-Oct-2019 Lee Shawn C <shawn.c.lee@intel.com>

drm/edid: Select DMT timing if EDID's display feature not support GTF

Refer to EDID 1.3 spec, display FEATURE (byte 18h) bit #0 said
"If this bit is set to 1, the display supports timings based on the
GTF standard using default GTF parameter values".

And EDID 1.4 spec shows "If bit 0 is set to 0, then the display
is noncontinuous frequency (multi-mode) and is only specified to accept
the video timing formats that are listed in BASE EDID and certain
EXTENSION Blocks.

When display feature did not support CVT or GFT2 and monitor's EDID version
greater than or equal to "1.2". DRM driver would select GTF as default
for standard timing calculation. It may generated some video timing
that can't display properly by external monitor.

For example. When driver retrieved "0xD1 0xFC" (FHD, 120Hz) and
"0xD1 0xE8" (FHD, 100Hz) from "Standard Timings". GTF formula
would generate video timing like below. It already over monitor's
spec to cause black screen issue.
"1920x1080" 120 368881 1920 2072 2288 2656 1080 1081 1084 1157 0x0 0x6
"1920x1080" 100 301992 1920 2072 2280 2640 1080 1081 1084 1144 0x0 0x6

v2: Just confirm GTF flag and omit the revision check.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191007135127.9538-1-shawn.c.lee@intel.com


# f0a8f533 01-Oct-2019 Jani Nikula <jani.nikula@intel.com>

drm/print: add drm_debug_enabled()

Add helper to check if a drm debug category is enabled. Convert drm core
to use it. No functional changes.

v2: Move unlikely() to drm_debug_enabled() (Eric)

v3: Keep unlikely() when combined with other conditions (Eric)

Cc: Eric Engestrom <eric@engestrom.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191001140614.26909-1-jani.nikula@intel.com


# 978f6b06 11-Jul-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add CTA-861-G modes with VIC < 128

Fill out our list of cea modes with the new stuff from CTA-861-G.
We only do the modes with VIC < 128 here. Adding the higher
numbered VICs will need some slight code refactoring first.

Cc: Hans Verkuil <hansverk@cisco.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190711103234.6294-2-ville.syrjala@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>


# c7581a41 04-Sep-2019 Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Use EOPNOTSUPP, not ENOTSUPP

- it's what we recommend in our docs:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values

- it's the overwhelmingly used error code for "operation not
supported", at least in drm core (slightly less so in drivers):

$ git grep EOPNOTSUPP -- drivers/gpu/drm/*c | wc -l
83
$ git grep ENOTSUPP -- drivers/gpu/drm/*c | wc -l
5

- include/linux/errno.h makes it fairly clear that these are for nfsv3
(plus they also have error codes above 512, which is the block with
some special behaviour ...)

/* Defined for the NFSv3 protocol */

If the above isn't reflecting current practice, then I guess we should
at least update the docs.

Noralf commented:

Ben Hutchings made this comment[1] in a thread about use of ENOTSUPP in
drivers:

glibc's strerror() returns these strings for ENOTSUPP and EOPNOTSUPP
respectively:

"Unknown error 524"
"Operation not supported"

So at least for errors returned to userspace EOPNOTSUPP makes sense.

José asked:

> Hopefully this will not break any userspace

None of the functions in drm_edid.c affected by this reach userspace,
it's all driver internal.

Same for the mipi function, that error code should be handled by
drivers. Drivers are supposed to remap "the hw is on fire" to EIO when
reporting up to userspace, but I think if a driver sees this it would
be a driver bug.
v2: Augment commit message with comments from Noralf and José

Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Sean Paul <sean@poorly.run>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Andres Rodriguez <andresx7@gmail.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190904143942.31756-1-daniel.vetter@ffwll.ch


# 80d42db0 19-Jun-2019 Andres Rodriguez <andresx7@gmail.com>

drm/edid: use for_each_displayid_db where applicable

Replace the duplicated versions of the while loop with the new macro.

Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190619183033.6922-1-andresx7@gmail.com


# e28ad544 19-Jun-2019 Andres Rodriguez <andresx7@gmail.com>

drm/edid: parse CEA blocks embedded in DisplayID

DisplayID blocks allow embedding of CEA blocks. The payloads are
identical to traditional top level CEA extension blocks, but the header
is slightly different.

This change allows the CEA parser to find a CEA block inside a DisplayID
block. Additionally, it adds support for parsing the embedded CTA
header. No further changes are necessary due to payload parity.

This change fixes audio support for the Valve Index HMD.

Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.15
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190619180901.17901-1-andresx7@gmail.com


# 48eaeb76 09-Jun-2019 Jani Nikula <jani.nikula@intel.com>

drm: add fallback override/firmware EDID modes workaround

We've moved the override and firmware EDID (simply "override EDID" from
now on) handling to the low level drm_do_get_edid() function in order to
transparently use the override throughout the stack. The idea is that
you get the override EDID via the ->get_modes() hook.

Unfortunately, there are scenarios where the DDC probe in drm_get_edid()
called via ->get_modes() fails, although the preceding ->detect()
succeeds.

In the case reported by Paul Wise, the ->detect() hook,
intel_crt_detect(), relies on hotplug detect, bypassing the DDC. In the
case reported by Ilpo Järvinen, there is no ->detect() hook, which is
interpreted as connected. The subsequent DDC probe reached via
->get_modes() fails, and we don't even look at the override EDID,
resulting in no modes being added.

Because drm_get_edid() is used via ->detect() all over the place, we
can't trivially remove the DDC probe, as it leads to override EDID
effectively meaning connector forcing. The goal is that connector
forcing and override EDID remain orthogonal.

Generally, the underlying problem here is the conflation of ->detect()
and ->get_modes() via drm_get_edid(). The former should just detect, and
the latter should just get the modes, typically via reading the EDID. As
long as drm_get_edid() is used in ->detect(), it needs to retain the DDC
probe. Or such users need to have a separate DDC probe step first.

The EDID caching between ->detect() and ->get_modes() done by some
drivers is a further complication that prevents us from making
drm_do_get_edid() adapt to the two cases.

Work around the regression by falling back to a separate attempt at
getting the override EDID at drm_helper_probe_single_connector_modes()
level. With a working DDC and override EDID, it'll never be called; the
override EDID will come via ->get_modes(). There will still be a failing
DDC probe attempt in the cases that require the fallback.

v2:
- Call drm_connector_update_edid_property (Paul)
- Update commit message about EDID caching (Daniel)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107583
Reported-by: Paul Wise <pabs3@bonedaddy.net>
Cc: Paul Wise <pabs3@bonedaddy.net>
References: http://mid.mail-archive.com/alpine.DEB.2.20.1905262211270.24390@whs-18.cs.helsinki.fi
Reported-by: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
Cc: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
References: 15f080f08d48 ("drm/edid: respect connector force for drm_get_edid ddc probe")
Fixes: 53fd40a90f3c ("drm: handle override and firmware EDID at drm_do_get_edid() level")
Cc: <stable@vger.kernel.org> # v4.15+ 56a2b7f2a39a drm/edid: abstract override/firmware EDID retrieval
Cc: <stable@vger.kernel.org> # v4.15+
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harish Chegondi <harish.chegondi@intel.com>
Tested-by: Paul Wise <pabs3@bonedaddy.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610093054.28445-1-jani.nikula@intel.com


# 56a2b7f2 07-Jun-2019 Jani Nikula <jani.nikula@intel.com>

drm/edid: abstract override/firmware EDID retrieval

Abstract the debugfs override and the firmware EDID retrieval
function. We'll be needing it in the follow-up. No functional changes.

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Harish Chegondi <harish.chegondi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Tested-by: Paul Wise <pabs3@bonedaddy.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607110513.12072-1-jani.nikula@intel.com


# 3bde449f 29-May-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Ignore "DFP 1.x" bit for EDID 1.2 and earlier

From VESA EDID implementation guide v1.0:
"For EDID version 1 revision 2 or earlier data structures when offset 14h
bit 7 is set to one, the value of bits 6-0 are undefined, and therefore
cannot be interpreted to mean anything."

And since EDID 1.4 redefines that bit let's consult it only for
EDID 1.3.

Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190529110204.2384-2-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>


# 382d2af6 29-May-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Clean up DRM_EDID_DIGITAL_* flags

Give the "DFP 1.x" bit a proper name, and clean up the rest
of the bits defines as well.

Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190529110204.2384-1-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>


# 6ac98829 23-May-2019 Sean Paul <seanpaul@chromium.org>

drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()

Fixes the following warnings:
../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member 'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata'
../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter 'hdr_metadata' description in 'drm_hdmi_infoframe_set_hdr_metadata'

Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Hans Verkuil <hansverk@cisco.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190523135504.184354-1-sean@poorly.run


# b5e3eed1 16-May-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Add HLG EOTF

ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a logarithmic curve.

v2: Rebase

v3: Fixed a warning message

v4: Addressed Shashank's review comments

v5: Addressed Jonas Karlman's review comment and dropped the i915
tag from header.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1558015817-12025-8-git-send-email-uma.shankar@intel.com


# 2cdbfd66 16-May-2019 Uma Shankar <uma.shankar@intel.com>

drm: Enable HDR infoframe support

Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.

The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.

Added the const version of infoframe for DRM metadata
for HDR.

v2: Rebase and added Ville's POC changes.

v3: No Change

v4: Addressed Shashank's review comments and merged the
patch making drm infoframe function arguments as constant.

v5: Rebase

v6: Fixed checkpatch warnings with --strict option. Addressed
Shashank's review comments and added his RB.

v7: Addressed Brian Starkey's review comments. Merged 2 patches
into one.

v8: Addressed Jonas Karlman review comments.

v9: Addressed Jonas Karlman review comments.

v10: Addressed Ville's review comments.

v11: Added BUILD_BUG_ON and sizeof instead of magic numbers as
per Ville's comments.

Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1558015817-12025-5-git-send-email-uma.shankar@intel.com


# e85959d6 16-May-2019 Uma Shankar <uma.shankar@intel.com>

drm: Parse HDR metadata info from EDID

HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.

v2: Rebase and added Ville's POC changes to the patch.

v3: No Change

v4: Addressed Shashank's review comments

v5: Addressed Shashank's comment and added his RB.

v6: Addressed Jonas Karlman review comments.

v7: Adressed Ville's review comments and fixed the issue
with length handling.

v8: Put the length check as per the convention followed in
existing code, as suggested by Ville.

Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1558015817-12025-4-git-send-email-uma.shankar@intel.com


# 30d62d44 02-May-2019 Andres Rodriguez <andresx7@gmail.com>

drm: add non-desktop quirk for Valve HMDs

Add vendor/product pairs for the Valve Index HMDs.

Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: <stable@vger.kernel.org> # v4.15
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190502193157.15692-1-andresx7@gmail.com


# 9c79edec 05-May-2019 Jani Nikula <jani.nikula@intel.com>

drm/edid: drmP.h include removal

Continue to get rid of drmP.h. Add minimal includes to build. Sort
includes while at it.

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190506095248.20874-2-jani.nikula@intel.com


# 9d5549d8 22-Mar-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.

The concensus seems to be that this quirk is a bit misguided
anyway so let's nuke the leftovers.

For posterity here are some links to known cases:
* Proview AY765C
https://bugs.freedesktop.org/show_bug.cgi?id=15160
* Unknown Acer
https://bugzilla.redhat.com/show_bug.cgi?id=284231 (got the
reference from xf86EdidModes.c)
* Peacock Ergovision 19 (only in xf86EdidModes.c)
https://bugzilla.redhat.com/show_bug.cgi?id=492359
* Philips 107p5 CRT
"Reported on xorg@ with pastebin", didn't find the mail(s)

Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190322174244.23945-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>


# 29054230 03-Dec-2018 Ryan Pavlik <ryan.pavlik@collabora.com>

drm: add non-desktop quirks to Sensics and OSVR headsets.

Add two EDID vendor/product pairs used across a variety of
Sensics products, as well as the OSVR HDK and HDK 2.

Signed-off-by: Ryan Pavlik <ryan.pavlik@collabora.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203164644.13974-1-ryan.pavlik@collabora.com
Cc: <stable@vger.kernel.org> # v4.15+


# 0d68b887 19-Feb-2019 Uma Shankar <uma.shankar@intel.com>

drm: Add colorspace info to AVI Infoframe

This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.

v2: Moved this to drm core instead of i915 driver.

v3: Exported the helper function.

v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values. This is
as per Ville's suggestion.

v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.

v6: Added bit wise macro for various fields of colorimetry for easier
understanding and review as per Ville's comments. Moved the same out of
header file to avoid any namespace issues.

v7: Undef some macros to avoid any namespace collision as suggested by
Ville. Added Ville's RB.

Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-3-git-send-email-uma.shankar@intel.com


# 1581b2df 08-Jan-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add display_info.rgb_quant_range_selectable

Move the CEA-861 QS bit handling entirely into the edid code. No
need to bother the drivers with this.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Cc: Eric Anholt <eric@anholt.net> (supporter:DRM DRIVERS FOR VC4)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-4-ville.syrjala@linux.intel.com


# 13d0add3 08-Jan-2019 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Pass connector to AVI infoframe functions

Make life easier for drivers by simply passing the connector
to drm_hdmi_avi_infoframe_from_display_mode() and
drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
need to worry about is_hdmi2_sink mess.

v2: Make is_hdmi2_sink() return true for sil-sii8620
Adapt to omap/vc4 changes

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-1-ville.syrjala@linux.intel.com


# 922dceff 28-Oct-2018 Lee, Shawn C <shawn.c.lee@intel.com>

drm/edid: Add 6 bpc quirk for BOE panel.

BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS".
But it's 6bpc panel only instead of 8 bpc.

Add panel ID to edid quirk list and set 6 bpc as default to
work around this issue.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: Lee, Shawn C <shawn.c.lee@intel.com>>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c.lee@intel.com


# 9068e02f 05-Oct-2018 Clint Taylor <clinton.a.taylor@intel.com>

drm/edid: VSDB yCBCr420 Deep Color mode bit definitions

HDMI Forum VSDB YCBCR420 deep color capability bits are 2:0. Correct
definitions in the header for the mask to work correctly.

Fixes: e6a9a2c3dc43 ("drm/edid: parse ycbcr 420 deep color information")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107893
Cc: <stable@vger.kernel.org> # v4.14+
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1538776335-12569-1-git-send-email-clinton.a.taylor@intel.com


# 0711a43b 02-Oct-2018 Kai-Heng Feng <kai.heng.feng@canonical.com>

drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl

There's another panel that reports "DFP 1.x compliant TMDS" but it
supports 6bpc instead of 8 bpc.

Apply 6 bpc quirk for the panel to fix it.

BugLink: https://bugs.launchpad.net/bugs/1794387
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181002152911.4370-1-kai.heng.feng@canonical.com


# 25da7504 22-Aug-2018 Kai-Heng Feng <kai.heng.feng@canonical.com>

drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80

Another panel that reports "DFP 1.x compliant TMDS" but it supports 6bpc
instead of 8 bpc.

Apply 6 bpc quirk for the panel to fix it.

BugLink: https://bugs.launchpad.net/bugs/1788308
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180823055332.7723-1-kai.heng.feng@canonical.com


# 6da2ec56 12-Jun-2018 Kees Cook <keescook@chromium.org>

treewide: kmalloc() -> kmalloc_array()

The kmalloc() function has a 2-factor argument form, kmalloc_array(). This
patch replaces cases of:

kmalloc(a * b, gfp)

with:
kmalloc_array(a * b, gfp)

as well as handling cases of:

kmalloc(a * b * c, gfp)

with:

kmalloc(array3_size(a, b, c), gfp)

as it's slightly less ugly than:

kmalloc_array(array_size(a, b), c, gfp)

This does, however, attempt to ignore constant size factors like:

kmalloc(4 * 1024, gfp)

though any constants defined via macros get caught up in the conversion.

Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.

The tools/ directory was manually excluded, since it has its own
implementation of kmalloc().

The Coccinelle script used for this was:

// Fix redundant parens around sizeof().
@@
type TYPE;
expression THING, E;
@@

(
kmalloc(
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
kmalloc(
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)

// Drop single-byte sizes and redundant parens.
@@
expression COUNT;
typedef u8;
typedef __u8;
@@

(
kmalloc(
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(char) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)

// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@

(
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)

// 2-factor product, only identifiers.
@@
identifier SIZE, COUNT;
@@

- kmalloc
+ kmalloc_array
(
- SIZE * COUNT
+ COUNT, SIZE
, ...)

// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@

(
kmalloc(
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)

// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@

(
kmalloc(
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kmalloc(
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)

// 3-factor product, only identifiers, with redundant parens removed.
@@
identifier STRIDE, SIZE, COUNT;
@@

(
kmalloc(
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)

// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression E1, E2, E3;
constant C1, C2, C3;
@@

(
kmalloc(C1 * C2 * C3, ...)
|
kmalloc(
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)

// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@

(
kmalloc(sizeof(THING) * C2, ...)
|
kmalloc(sizeof(TYPE) * C2, ...)
|
kmalloc(C1 * C2 * C3, ...)
|
kmalloc(C1 * C2, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- (E1) * E2
+ E1, E2
, ...)
|
- kmalloc
+ kmalloc_array
(
- (E1) * (E2)
+ E1, E2
, ...)
|
- kmalloc
+ kmalloc_array
(
- E1 * E2
+ E1, E2
, ...)
)

Signed-off-by: Kees Cook <keescook@chromium.org>


# 6931317c 29-May-2018 Lubosz Sarnecki <lubosz.sarnecki@collabora.com>

drm/edid: Quirk Vive Pro VR headset non-desktop.

This adds the Vive Pro's EDID information and
sets EDID_QUIRK_NON_DESKTOP.

Signed-off-by: Lubosz Sarnecki <lubosz.sarnecki@collabora.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: <stable@vger.kernel.org> # v4.15+
Link: https://patchwork.freedesktop.org/patch/msgid/20180529115215.4526-1-lubosz.sarnecki@collabora.com


# 78691960 24-May-2018 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fix up edid_cea_modes[] formatting

Fix up a bunch of bad indentation and insconsistent comments
in edid_cea_modes[].

v2: Instead of stripping the aspect ratio comments let's
add them to all modes

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524192035.9776-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>


# 50525c33 15-May-2018 Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm: content-type property for HDMI connector

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.

v3:
* Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.

v4:
* Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.

v5:
* Moved patch revision's description to commit messages.

v6:
* Minor naming fix for the content type enumeration string.

v7:
* Fix parameter name for documentation and parameter alignment
in order not to get warning. Added Content Type description to
new HDMI connector properties section.

v8:
* Thrown away unneeded numbers from HDMI content-type property
description. Switch to strings desription instead of plain
definitions.

v9:
* Moved away hdmi specific content-type enum from
drm_connector_state. Content type property should probably not
be bound to any specific connector interface in
drm_connector_state.
Same probably should be done to hdmi_picture_aspect_ration enum
which is also contained in drm_connector_state. Added special
helper function to get derive hdmi specific relevant infoframe
fields.

v10:
* Added usage description to HDMI properties kernel doc.

v11:
* Created centralized function for filling HDMI AVI infoframe, based
on correspondent DRM property value.

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com
[vsyrjala: clean up checkpatch multiple blank lines warnings]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>


# a9c266c2 08-May-2018 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Don't send bogus aspect ratios in AVI infoframes

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-5-git-send-email-ankit.k.nautiyal@intel.com


# 357768cc 08-May-2018 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fix cea mode aspect ratio handling

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: "Lin, Jia" <lin.a.jia@intel.com>
Cc: Akashdeep Sharma <akashdeep.sharma@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-4-git-send-email-ankit.k.nautiyal@intel.com


# a2328fd6 08-May-2018 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-3-git-send-email-ankit.k.nautiyal@intel.com


# 1f6b8eef 24-Apr-2018 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Reset more of the display info

We're currently failing to reset everything in display_info.hdmi
which will potentially cause us to use stale information when
swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor
with a HDMI 1.x monitor we will continue to think that the monitor
supports scrambling. That will lead to a black screen since the
HDMI 1.x monitor won't understand the scrambled signal.

Fix the problem by clearing display_info.hdmi fully. And while at
eliminate some duplicated code by calling drm_reset_display_info()
in drm_add_display_info().

Cc: stable@vger.kernel.org
Cc: Antony Chen <antonychen@qnap.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180424130250.7028-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Antony Chen <antonychen@qnap.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>


# 6e35fed9 24-Apr-2018 Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Don't EXPORT drm_add/reset_display_info

Only used within drm.ko, no need to tempt drivers.

Cc: Keith Packard <keithp@keithp.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180424142242.12093-1-daniel.vetter@ffwll.ch


# 11b83e3f 23-Feb-2018 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Remove now pointelss blob->data casts

Now that blob->data is void* again we don't need the casts anymore.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180223192506.29992-2-ville.syrjala@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# ccffc9eb 19-Feb-2018 Philipp Zabel <philipp.zabel@gmail.com>

drm/edid: quirk Sony PlayStation VR headset as non-desktop

This uses the EDID info from the Sony PlayStation VR headset,
when connected directly, to mark it as non-desktop.
Since the connection box (product id b403) defaults to HDMI
pass-through to the TV, it is not marked as non-desktop.

Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 90eda8fc 19-Feb-2018 Philipp Zabel <philipp.zabel@gmail.com>

drm/edid: quirk Windows Mixed Reality headsets as non-desktop

This uses the EDID info from Lenovo Explorer (LEN-b800), Acer AH100
(ACR-7fce), and Samsung Odyssey (SEC-144a) to mark them as non-desktop.

The other entries are for the HP Windows Mixed Reality Headset (HPN-3515),
the Fujitsu Windows Mixed Reality headset (FUJ-1970), the Dell Visor
(DEL-7fce), and the ASUS HC102 (AUS-c102). They are not tested with real
hardware, but listed as HMD monitors alongside the tested headsets in the
Microsoft HololensSensors driver package.

Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# b3b12ea3 19-Feb-2018 Philipp Zabel <philipp.zabel@gmail.com>

drm/edid: quirk Oculus Rift headsets as non-desktop

This uses the EDID info from Oculus Rift DK1 (OVR-0001), DK2 (OVR-0003),
and CV1 (OVR-0004) to mark them as non-desktop.

Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 06998a75 18-Feb-2018 Kai-Heng Feng <kai.heng.feng@canonical.com>

drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA

Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display
AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
6bpc instead of 8 bpc.

Hence, use 6 bpc quirk for this panel.

Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"")
BugLink: https://bugs.launchpad.net/bugs/1749420
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180218085359.7817-1-kai.heng.feng@canonical.com


# a5ef6567 12-Feb-2018 Joe Moriarty <joe.moriarty@oracle.com>

drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.

- drivers/gpu/drm/drm_edid.c
The call to drm_cvt_mode() in function drm_mode_std() for the
HDTV hack resulted in the possibility of accessing a NULL pointer
if drm_mode_std() returned NULL. A check for this added right after
the call to drm_cvt_mode() in this particular area of code.

Signed-off-by: Joe Moriarty <joe.moriarty@oracle.com>
Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-4-joe.moriarty@oracle.com


# c2925bde 30-Jan-2018 Gustavo A. R. Silva <gustavo@embeddedor.com>

drm/edid: use true and false for boolean values

Assign true or false to boolean variables instead of an integer value.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130100528.GA7154@training


# 7cdeb37c 14-Dec-2017 Daniel Vetter <daniel.vetter@ffwll.ch>

drm/edid: kerneldoc for is_hdmi2_sink

Also some breadcrumbs for how exactly to find this. Probably should
pass drm_connector * or at least drm_display_info * to that function
instead. But drm_hdmi_avi_infoframe_quant_range probably also wants
drm_connector_state (and the hdmi stuff moved into that), so this is a
bit more work.

v2: Fix typo (Alex).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 9271c0ca573e ("drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks")
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-2-daniel.vetter@ffwll.ch


# 4b4df570 13-Dec-2017 Keith Packard <keithp@keithp.com>

drm: Update edid-derived drm_display_info fields at edid property set [v2]

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: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel 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: Daniel Vetter <daniel.vetter@ffwll.ch>


# 170178fe 13-Dec-2017 Keith Packard <keithp@keithp.com>

drm: Update edid-derived drm_display_info fields at edid property set [v2]

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: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171213084427.31199-1-keithp@keithp.com


# acb1d8ee 15-Oct-2017 Dave Airlie <airlied@redhat.com>

drm/edid: quirk HTC vive headset as non-desktop. [v2]

This uses the EDID info from my HTC Vive to mark it as
non-desktop.

v2: Change description from non-standard to non-desktop

Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 66660d4c 15-Oct-2017 Dave Airlie <airlied@redhat.com>

drm: add connector info/property for non-desktop displays [v2]

This adds the infrastructure needed to quirk displays
using edid and to mark them a non-desktop.

A non-desktop display is one which shouldn't normally be included
as a part of a desktop environment.

This is meant to cover head mounted devices like HTC Vive.

v2: Change description from non-standard to non-desktop, add docs

Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

fixup docs


# f1781e9b 13-Nov-2017 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Allow HDMI infoframe without VIC or S3D

Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
3D to 2D mode in a timely fashion if the source simply stops sending the
HDMI infoframe. The suggested workaround is to keep sending the
infoframe even when strictly not necessary (ie. no VIC and no S3D).
HDMI 1.4 does allow for this behaviour, stating that sending the
infoframe is optional in this case.

The infoframe was first specified in HDMI 1.4, so in theory sinks
predating that may not appreciate us sending an uknown infoframe
their way. To avoid regressions let's try to determine if the sink
supports the infoframe or not. Unfortunately there's no direct way
to do that, so instead we'll just check if we managed to parse any
HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
sink will accept the infoframe. Also if the EDID contains the HDMI
2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
the infoframe.

v2: Fix getting has_hdmi_infoframe from display_info
Always fail constructing the infoframe if the display
possibly can't handle it

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-3-ville.syrjala@linux.intel.com


# 9271c0ca 08-Nov-2017 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

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: Neil Kownacki <njkkow@gmail.com>
Tested-by: Neil Kownacki <njkkow@gmail.com>
Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108152504.12596-1-ville.syrjala@linux.intel.com
Acked-by: Eric Anholt <eric@anholt.net>


# 79436a1c 01-Nov-2017 Jani Nikula <jani.nikula@intel.com>

drm/edid: make drm_edid_to_eld() static

This is no longer needed outside of drm_edid.c.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9c0be7b97d0144ed0419c87ac42b30f5835ca7e6.1509545641.git.jani.nikula@intel.com


# c945b8c1 01-Nov-2017 Jani Nikula <jani.nikula@intel.com>

drm/edid: build ELD in drm_add_edid_modes()

Call drm_edid_to_eld() from drm_add_edid_modes() to fill in the ELD
automatically. There's no harm in doing this for connectors that do not
support audio.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/551b2e1cf19be04c510e7865d7539cfc2f54ea89.1509545641.git.jani.nikula@intel.com


# 42750d39 01-Nov-2017 Jani Nikula <jani.nikula@intel.com>

drm/edid: abstract connector ELD clearing

Preparation for future work. No functional changes.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/95e83e7a62566b65a56c8cb5038ddf0c6b8e5e95.1509545641.git.jani.nikula@intel.com


# 1d1c3665 01-Nov-2017 Jani Nikula <jani.nikula@intel.com>

drm/edid: set ELD connector type in drm_edid_to_eld()

Since drm_edid_to_eld() knows the connector type, we can set the type in
ELD while at it. Most connectors this gets called on are not DP
encoders, and with the HDMI type being 0, this does not change behaviour
for non-DP.

For i915 having this in place earlier would have saved a considerable
amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always
update ELD connector type after get modes"). I don't see other drivers,
even the ones calling drm_edid_to_eld() on DP connectors, setting the
connector type in ELD.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf118bc0cfc1d.1509545641.git.jani.nikula@intel.com


# f7da7785 01-Nov-2017 Jani Nikula <jani.nikula@intel.com>

drm/edid: use macros for ELD offsets and values

We have the macros, use them. No functional changes.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/36f00f018280a04d2db806574d337f7512986c86.1509545641.git.jani.nikula@intel.com


# 53fd40a9 12-Sep-2017 Jani Nikula <jani.nikula@intel.com>

drm: handle override and firmware EDID at drm_do_get_edid() level

Handle debugfs override edid and firmware edid at the low level to
transparently and completely replace the real edid. Previously, we
practically only used the modes from the override EDID, and none of the
other data, such as audio parameters.

This change also prevents actual EDID reads when the EDID is to be
overridden, but retains the DDC probe. This is useful if the reason for
preferring override EDID are problems with reading the data, or
corruption of the data.

Move firmware EDID loading from helper to core, as the functionality
moves to lower level as well. This will result in a change of module
parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
arguably makes more sense anyway.

Some future work remains related to override and firmware EDID
validation. Like before, no validation is done for override EDID. The
firmware EDID is validated separately in the loader. Some unification
and deduplication would be in order, to validate all of them at the
drm_do_get_edid() level, like "real" EDIDs.

v2: move firmware loading to core

v3: rebase, commit message refresh

Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1e8a710bcac46e5136c1a7b430074893c81f364a.1505203831.git.jani.nikula@intel.com


# e6a9a2c3 13-Jul-2017 Shashank Sharma <shashank.sharma@intel.com>

drm/edid: parse ycbcr 420 deep color information

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: Shashank 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: Ville Syrjälä <ville.syrjala@linux.intel.com>


# 832d4f2f 14-Jul-2017 Shashank Sharma <shashank.sharma@intel.com>

drm/edid: parse YCBCR420 videomodes from EDID

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.

These blocks are:

- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.

- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.

This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>

V2: Addressed
Review comments from Emil:
- Use 1ULL<<i instead of 1<<i to make sure the output is 64bit.
- Use the suggested method for updating dbmap.
- Add documentation for YCBCR420_vcb_map to fix kbuild warning.

Review comments from Ville:
- Do not expose the YCBCR420 flags in uabi layer, keep it internal.
- Save a map of YCBCR420 modes for future reference.
- Check db length before trying to parse extended tag.
- Add a warning if there are > 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.

V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.

V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()

V5: Addressed review comments from Ville:
- Add the patch which cleans up the current EXTENDED_TAG usage
- Make y420_cmdb_map u64
- Do not block ycbcr420 modes while parsing the EDID, rather
add a separate helper function to prune ycbcr420-only modes from
connector's probed modes.

V6: Rebase
V7: Move this patch after the 420_only validation patch (Ville)
V8: Addressed review comments from Ville
- use cea_vic_valid check before adding cmdb/vdb modes
- add check for i < 64 while adding cmdb modes
- use 1ULL while checking bitmap

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix checkpatch complaints and indentation]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>


# 87563fc0 13-Jul-2017 Shashank Sharma <shashank.sharma@intel.com>

drm/edid: cleanup patch for CEA extended-tag macro

CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"

This patch renames the macro and usages from "VIDEO_CAPABILITY_BLOCK"
to "USE_EXTENDED_TAG"

V2: Add extended tag code check for video capabilitiy block (ville)
V3: Ville:
- Use suggested names for macros
- Check the block length first, before checking the extended tag
V4: Fix commit message (David)
V5: Introduced this patch into HDMI-YCBCR-output series
V6: Rebase
V7: Rebase

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-5-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>


# 0f0f8708 13-Jul-2017 Shashank Sharma <shashank.sharma@intel.com>

drm/edid: parse sink information before CEA blocks

CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.

This patch moves the call to drm_add_display_info function, before the
mode parsing block.

V4: Introduced new patch in the series
V5: Move this patch before 4:2:0 parsing patch (ville)
Added r-b from Ville
V6: Rebase
V7: Rebase

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-4-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>


# 8ec6e075 13-Jul-2017 Shashank Sharma <shashank.sharma@intel.com>

drm/edid: complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/

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: Harry Wentland <harry.wentland@amd.com>

V2: Rebase
V3: Rebase
V4: Added native bit handling as per CEA-861-F spec (Ville)
V5: Fix timings for VIC 77:1920x1080 and 104:3840x2160p (Ville)
Remove unnecessary paranthesis from function svd_to_vic (Ville)
Added r-b (Neil)
V6: Rebase
V7: Fix indentation for modes from VIC 80

Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-3-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix up remaining formatting/indentation issues]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>


# 0c1f528c 13-Jul-2017 Shashank Sharma <shashank.sharma@intel.com>

drm: handle HDMI 2.0 VICs in AVI info-frames

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: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>


# e345da82 21-Apr-2017 Mario Kleiner <mario.kleiner.de@gmail.com>

drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2

The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.

Add a quirk to get the full 10 bpc.

Cc: stable@vger.kernel.org
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1492787108-23959-1-git-send-email-mario.kleiner.de@gmail.com


# 62c58af3 13-Mar-2017 Shashank Sharma <shashank.sharma@intel.com>

drm/edid: detect SCDC support in HF-VSDB

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: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com


# afa1c763 13-Mar-2017 Shashank Sharma <shashank.sharma@intel.com>

drm/edid: detect SCDC support in HF-VSDB

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: Rebase.
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com


# 50dd1bd1 13-Mar-2017 Thierry Reding <treding@nvidia.com>

drm/edid: check for HF-VSDB block

This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.

V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: Rebase

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-3-git-send-email-shashank.sharma@intel.com


# 36fc5797 20-Feb-2017 Tomeu Vizoso <tomeu.vizoso@collabora.com>

drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
1.1.

When a sink that supports deep color is connected to the output, the
receiver will send EDIDs that advertise this capability, even if it
isn't possible with HDMI versions earlier than 1.3.

Currently the kernel is assuming that deep color is possible and the
sink displays an error.

This quirk will make sure that deep color isn't used with this
particular receiver.

Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170220152545.13153-1-tomeu.vizoso@collabora.com
Cc: stable@vger.kernel.org
Cc: Matt Horan <matt@matthoran.com>
Tested-by: Matt Horan <matt@matthoran.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>


# 499447db 28-Feb-2017 Joe Perches <joe@perches.com>

gpu: drm: core: Convert printk(KERN_<LEVEL> to pr_<level>

Use a more common logging style.

Miscellanea:

o Coalesce formats and realign arguments

Signed-off-by: Joe Perches <joe@perches.com>
[danvet: Resolve minor conflict in drm_edid.c]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 15f080f0 17-Feb-2017 Jani Nikula <jani.nikula@intel.com>

drm/edid: respect connector force for drm_get_edid ddc probe

Skip DDC probe for forced connector status. Don't try to read the EDID
if the connector is forced off. Skipping probe for forced on connectors
will make more sense when drm_do_get_edid() will handle override and
firmware EDIDs.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487344854-18777-4-git-send-email-jani.nikula@intel.com


# e9bd0b84 17-Feb-2017 Jani Nikula <jani.nikula@intel.com>

drm: do not debug log about missing CEA extensions on NULL edid

Make the drm_edid_to_eld() function useful for resetting, not just
setting, the ELD and HDMI VSDB data, without debug warnings about
missing CEA extensions.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487344854-18777-3-git-send-email-jani.nikula@intel.com


# 813a7878 10-Feb-2017 Chris Wilson <chris@chris-wilson.co.uk>

drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

The warnings from parsing the EDID are not driver errors, but the
"normal but significant" conditions from the external device. As such,
they do not need the ferocity of an *ERROR*, but can use the less harsh
DRM_NOTE instead.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170210195913.9878-1-chris@chris-wilson.co.uk


# 82d75356 08-Dec-2016 Tomeu Vizoso <tomeu.vizoso@collabora.com>

drm/edid: Don't print an error if the checksum of a CEA block is wrong

It's common to share screens within CI labs, and it's also common for
KVM switches to alter the contents of the CEA block but leave the
checksum outdated.

So in this case, print a debug message instead of an error.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Tested-by: Jari Tahvanainen <jari.tahvanainen@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1481202716-31317-1-git-send-email-tomeu.vizoso@collabora.com


# 969218fe 17-Jan-2017 Takashi Iwai <tiwai@suse.de>

drm: Clean up the 1366x768 fixup codes

This is just a cleanup, no functional change.

The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is
basically a copy of the existing code in drm_edid.c. Make the latter
code public so that it can be called from the former function.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170117164329.10551-1-tiwai@suse.de
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[vsyrjala: include drm_crtc_internal.h to make sparse happy]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>


# fcc8a22c 11-Jan-2017 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F

CEA-861-F tells us:
"When transmitting any RGB colorimetry, the Source should set the
YQ-field to match the RGB Quantization Range being transmitted
(e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
set YQ=1) and the Sink shall ignore the YQ-field."

So let's go ahead and do that. Perhaps there are sinks that don't
ignore the YQ as they should for RGB?

I wasn't able to find similar text in CEA-861-E, so it would seem
to be a fairly "recent" addition.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Eric Anholt <eric@anholt.net>


# 779c4c28 11-Jan-2017 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Set AVI infoframe Q even when QS=0

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Eric Anholt <eric@anholt.net>


# a2ce26f8 11-Jan-2017 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range()

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Eric Anholt <eric@anholt.net>


# c8127cf0 11-Jan-2017 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Introduce drm_default_rgb_quant_range()

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111141835.25369-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Eric Anholt <eric@anholt.net>


# 23c4cfbd 28-Dec-2016 Jani Nikula <jani.nikula@intel.com>

drm/edid: constify edid quirk list

No reason not to be const.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1482923186-22430-1-git-send-email-jani.nikula@intel.com


# 9338203c 28-Nov-2016 Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: Don't include <drm/drm_encoder.h> in <drm/drm_crtc.h>

<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: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sinclair Yeh <syeh@vmware.com> # For vmwgfx
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com


# c45a4e46 03-Nov-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Consider alternate cea timings to be the same VIC

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>


# 1f4faefe 08-Nov-2016 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/edid: Remove drm_select_eld

The only user was i915, which is now gone.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville 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


# e587803c 03-Nov-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add the missing "Hz" to VIC 58,59 comment

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-1-git-send-email-ville.syrjala@linux.intel.com


# 14544d09 23-Oct-2016 Chris Wilson <chris@chris-wilson.co.uk>

drm/edid: Only print the bad edid when aborting

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=98228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161024113821.26263-1-chris@chris-wilson.co.uk


# a28187cc 17-Oct-2016 Chris Wilson <chris@chris-wilson.co.uk>

drm/edid: Use block local to refer to the block

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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161017083514.21772-2-chris@chris-wilson.co.uk


# f14f3686 17-Oct-2016 Chris Wilson <chris@chris-wilson.co.uk>

drm/edid: Rename local variable block to edid

The "block" variable points to the entire edid, not individual blocks
despite it being named such.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161017083514.21772-1-chris@chris-wilson.co.uk


# 23ebf8b9 28-Sep-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-9-git-send-email-ville.syrjala@linux.intel.com


# 011acce2 28-Sep-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-8-git-send-email-ville.syrjala@linux.intel.com


# 1cea146a 28-Sep-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Reduce the number of times we parse the CEA extension block

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-7-git-send-email-ville.syrjala@linux.intel.com


# 1826750f 28-Sep-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Don't pass around drm_display_info needlessly

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-6-git-send-email-ville.syrjala@linux.intel.com


# 2a272ca9 28-Sep-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info

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


# ab5603c4 28-Sep-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Make max_tmds_clock kHz instead of MHz

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


# 75d7e542 28-Sep-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-3-git-send-email-ville.syrjala@linux.intel.com


# 85c91580 28-Sep-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Clear old audio latency values before parsing the new EDID

Clear out stale audio latency information (potentially from a previous
EDID) before constructing the ELD from the EDID.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-2-git-send-email-ville.syrjala@linux.intel.com


# 8f0e4907 15-Aug-2016 Clint Taylor <clinton.a.taylor@intel.com>

drm/edid: CEA mode 64 1080p100 vsync pulse width incorrect

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: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1471282288-30909-1-git-send-email-clinton.a.taylor@intel.com


# b3c6c8bf 12-Aug-2016 Daniel Vetter <daniel.vetter@ffwll.ch>

drm: document drm_display_info

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: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-19-git-send-email-daniel.vetter@ffwll.ch


# 210a021d 05-Jul-2016 Mario Kleiner <mario.kleiner.de@gmail.com>

drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant TMDS".

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: Mario 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: Dave Airlie <airlied@redhat.com>


# e10aec65 05-Jul-2016 Mario Kleiner <mario.kleiner.de@gmail.com>

drm/edid: Add 6 bpc quirk for display AEO model 0.

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 013dd9e03872
("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: Mario 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: Dave Airlie <airlied@redhat.com>


# a39ed680 01-May-2016 Dave Airlie <airlied@redhat.com>

drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)

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=95207
Signed-off-by: Dave Airlie <airlied@redhat.com>


# c9729177 02-May-2016 Dave Airlie <airlied@redhat.com>

drm/edid: move displayid validation to it's own function.

We need to use this for validating modeline additions.

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


# 3a4a2ea3 01-May-2016 Tomas Bzatek <tomas@bzatek.net>

drm/displayid: Iterate over all DisplayID blocks

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=95207

Signed-off-by: Tomas Bzatek <tomas@bzatek.net>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 5e546cd5 02-May-2016 Dave Airlie <airlied@redhat.com>

drm/edid: move displayid tiled block parsing into separate function.

This just makes the code easier to follow.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 59f7c0fa 14-Apr-2016 Jim Bride <jim.bride@linux.intel.com>

drm/edid: Add drm_edid_get_monitor_name()

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: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-1-git-send-email-jim.bride@linux.intel.com


# 735b100f 04-Apr-2016 Paul Parsons <lost.distance@yahoo.com>

drm/edid: Fix DMT 1024x768@43Hz (interlaced) timings

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: Paul Parsons <lost.distance@yahoo.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160404193639.8631D6E66B@gabe.freedesktop.org


# f3a32d74 26-Mar-2016 Paul Parsons <lost.distance@yahoo.com>

drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptor

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: Paul Parsons <lost.distance@yahoo.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160328002258.E75DF6E35D@gabe.freedesktop.org


# 87707cfd 02-Apr-2016 Paul Parsons <lost.distance@yahoo.com>

drm/edid: Fix EDID Established Timings I and II

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: Paul Parsons <lost.distance@yahoo.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160402100817.B60776E23A@gabe.freedesktop.org


# 7c018782 09-Mar-2016 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Extract SADs properly from multiple audio data blocks

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: Arturo Pérez <artur999555@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94197
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457554066-8739-1-git-send-email-ville.syrjala@linux.intel.com


# 5cb8eaa2 11-Jan-2016 Lukas Wunner <lukas@wunner.de>

drm/edid: Switch DDC when reading the EDID

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=61115
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
[MBP 5,3 2009 nvidia MCP79 + G96 pre-retina 15"]
Tested-by: William Brown <william@blackhats.net.au>
[MBP 8,2 2011 intel SNB + amd turks pre-retina 15"]
Tested-by: Lukas 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: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/b898d0da4c134f2642d0122479006863e1830723.1452525860.git.lukas@wunner.de


# d9278b4c 08-Jan-2016 Jani Nikula <jani.nikula@intel.com>

drm/edid: index CEA/HDMI mode tables using the VIC

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: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452252111-6439-1-git-send-email-jani.nikula@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 4c6bcf44 16-Nov-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to 5kHz clock difference

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: fa3a7340eaa1 ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 9afd808c 08-Oct-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Round to closest when computing the CEA/HDMI alternate clock

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# fa3a7340 08-Oct-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 3a818d35 07-Sep-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Make drm_av_sync_delay() 'mode' argument const

drm_av_sync_delay() doesn't change the passed in mode, so make it const.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 9e5a3b52 07-Sep-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Remove the 'mode' argument from drm_select_eld()

drm_select_eld() doesn't look at the passed in mode, so don't pass it
in.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 85f8fcd6 07-Sep-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Make some modes const when iterating through them

valid_inferred_mode() don't change the modes over which it iterates,
so make the iterator const.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# fbb40b28 10-Aug-2015 Daniel Vetter <daniel.vetter@ffwll.ch>

drm/edid: Use ARRAY_SIZE in drm_add_modes_noedid

Spotted while reading code for random reasons.

Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>


# 9a9f5ce8 09-Jul-2015 Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Roll out drm_for_each_connector more

Now that we also grab the connection_mutex and so fixed the race with
atomic modeset we can use the iterator there too.

The other special case is drm_connector_unplug_all which would have a
locking inversion with the sysfs store/show functions if we'd grab the
mode_config.mutex around the unplug. We could just grab
connection_mutex instead, but that's a bit too much a dirty trick for
my taste. Also it's only used by udl, which doesn't do any other kind
of connector hotplugging, so should be race-free. Hence just stick
with a comment for now.

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>


# 4d53dc0c 08-May-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add CEA modes before inferred modes

Currently we're adding CEA modes after the inferred modes, which means
we might get multiple modes that are very close to each other, but
slightly different, which seems a bit silly. That's because duplicate
mode check that occurs when adding inferred modes would not consider
CEA modes as potential duplicates. Reverse the order so that CEA
modes get added before inferred modes, and are thus considered potential
duplicates.

Or as ajax put it on irc:
"< ajax> the point of the "pick a timing formula" heuristic was to
generate something the sink could _likely_ sink. if it tells us
timings it can sink explicitly then second-guessing seems dumb."

Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# ac6f2e29 08-May-2015 Daniel Vetter <daniel.vetter@ffwll.ch>

drm/edid: Kerneldoc for newly added edid_corrupt

Also treat it as a proper boolean.

Cc: Todd Previte <tprevite@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>


# 6ba2bd3d 21-Apr-2015 Todd Previte <tprevite@gmail.com>

drm: Add edid_corrupt flag for Displayport Link CTS 4.2.2.6

Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the checksum and
compare it to the value stored in the last byte of the block data.

Unfortunately, the DRM EDID reading and parsing functions are actually too good
in this case; the header is fixed before the checksum is computed and thus the
test never sees the invalid checksum. This results in a failure to pass the
compliance test.

To correct this issue, when the EDID code detects that the header is invalid,
a flag is set to indicate that the EDID is corrupted. In this case, it sets
edid_corrupt flag and continues with its fix-up code. This flag is also set in
the case of a more seriously damaged header (fixup score less than the
threshold). For consistency, the edid_corrupt flag is also set when the
checksum is invalid as well.

V2:
- Removed the static bool global
- Added a bool to the drm_connector struct to reaplce the static one for
holding the status of raw edid header corruption detection
- Modified the function signature of the is_valid function to take an
additional parameter to store the corruption detected value
- Fixed the other callers of the above is_valid function
V3:
- Updated the commit message to be more clear about what and why this
patch does what it does.
- Added comment in code to clarify the operations there
- Removed compliance variable and check_link_status update; those
have been moved to a later patch
- Removed variable assignment from the bottom of the test handler
V4:
- Removed i915 tag from subject line as the patch is not i915-specific
V5:
- Moved code causing a compilation error to this patch where the variable
is actually declared
- Maintained blank lines / spacing so as to not contaminate the patch
V6:
- Removed extra debug messages
- Added documentation to for the added parameter on drm_edid_block_valid
- Fixed more whitespace issues in check_link_status
- Added a clear of the header_corrupt flag to the end of the test handler
in intel_dp.c
- Changed the usage of the new function prototype in several places to use
NULL where it is not needed by compliance testing
V7:
- Updated to account for long_pulse flag propagation
V8:
- Removed clearing of header_corrupt flag from the test handler in intel_dp.c
- Added clearing of header_corrupt flag in the drm_edid_block_valid function
V9:
- Renamed header_corrupt flag to edid_corrupt to more accurately reflect its
value and purpose
- Updated commit message
V10:
- Updated for versioning and patch swizzle
- Revised the title to more accurately reflect the nature and contents of
the patch
- Fixed formatting/whitespace problems
- Added set flag when computed checksum is invalid

Signed-off-by: Todd Previte <tprevite@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# bfcd74d2 02-Apr-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add DMT modes with ID > 0x50

DMT Version 1.0, Rev. 13 lists a bunch of new modes we don't currently
have in our dmt mode table. So add them.

The order may look a bit weird since it's not sorted based on the DMT
ID, but this is the order they appear in the standard. I suppose they
are ordered by the resolution, pixel clock, or some such factor. I
decided that it's perhaps best to keep the same order as the spec.

Cc: "liu,lei" <lei.a.liu@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 24b856b1 02-Apr-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add the DMT ID in the comments

To help with matching things to spec, include the DMT ID in the comments
in out DMT mode table.

Cc: "liu,lei" <lei.a.liu@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# fcf22d05 02-Apr-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fix up DMT modes

Liu Lei noticed that our 1856x1392@75Hz DMT mode doesn't match the spec.
Fix that up, and also fix up a few other inconsistencies I discovered
by parsing the spec (DMT version 1.0, revision 13) and comparing the
results to our current DMT mode table.

Also clean up the indentation mess for the 1024x768i mode.

Cc: "liu,lei" <lei.a.liu@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 40d9b043 20-Oct-2014 Dave Airlie <airlied@redhat.com>

drm/connector: store tile information from displayid (v3)

This creates a tile group from DisplayID block, and
stores the pieces of parsed info from the DisplayID block
into the connector.

v2: add missing signoff, add new connector bits to docs.

v3: remove some debugging.

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


# 7c58e87e 03-Dec-2014 Thierry Reding <treding@nvidia.com>

drm/edid: Restore kerneldoc consistency

Commit 18df89fef2d5 ("drm: Decouple EDID parsing from I2C adapter")
renamed the adapter parameter of the drm_do_probe_ddc_edid function
to data but didn't update the kerneldoc accordingly.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# c465bbc8 30-Nov-2014 Stefan Brüns <stefan.bruens@rwth-aachen.de>

drm/edid: new drm_edid_block_checksum helper function V3

The function will also be used by a later patch, so factor it out.

V2: make raw_edid const, define/declare before first use
V3: fix erroneuos removal of csum variable

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# da4c07b7 30-Nov-2014 Stefan Brüns <stefan.bruens@rwth-aachen.de>

drm/edid: shorten log output in case of all zeroes edid block

There is no need to dump the whole EDID block in case it contains no
information. Just print a single line stating the block is empty instead
of 8 lines containing only zeroes.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# d6885d65 30-Nov-2014 Stefan Brüns <stefan.bruens@rwth-aachen.de>

drm/edid: move drm_edid_is_zero to top, make edid argument const

drm_edid_is_zero will be used by drm_edid_block valid, move it up.
raw_edid argument can be const.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 18df89fe 27-Apr-2012 Lars-Peter Clausen <lars@metafoo.de>

drm: Decouple EDID parsing from I2C adapter

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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 938fd8aa 28-Oct-2014 Jani Nikula <jani.nikula@intel.com>

drm/edid: fix Baseline_ELD_Len field in drm_edid_to_eld()

The Baseline_ELD_Len field does not include ELD Header Block size.

From High Definition Audio Specification, Revision 1.0a:

The header block is a fixed size of 4 bytes. The baseline block
is variable size in multiple of 4 bytes, and its size is defined
in the header block Baseline_ELD_Len field (in number of
DWords).

Do not include the header size in Baseline_ELD_Len field. Fix all known
users of eld[2].

While at it, switch to DIV_ROUND_UP instead of open coding it.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
[danvet: Fix compile fail in nouveau.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 5a11f7f8 26-Sep-2014 Clint Taylor <clinton.a.taylor@intel.com>

drm/edid: Add missing interlaced flag to 576i@100 modes.

CEA VICs 44 and 45 were missing DRM_MODE_FLAG_INTERLACE.

Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# fb01d280 02-Sep-2014 Clint Taylor <clinton.a.taylor@intel.com>

drm/edid: Reduce horizontal timings for pixel replicated modes

Pixel replicated modes should be non-2x horizontal timings and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently fails for all pixel replicated modes. This change will
allow HDMI certification with 480i/576i modes once pixel replication
is turned on.

Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# d456ea2e 23-Aug-2014 Julia Lawall <Julia.Lawall@lip6.fr>

drm: use c99 initializers in structures

Use c99 initializers for structures.

Drop 0 initializers in drivers/gpu/drm/sti/sti_vtac.c. A 0x0 initializer
is left in vtac_mode_aux in drivers/gpu/drm/sti/sti_vtac.c to highlight the
relation to vtac_mode_main.

A simplified version of the semantic match that finds the first problem is
as follows: (http://coccinelle.lip6.fr/)

// <smpl>
@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@

struct i1 {
fs
T fld;
...};

@bad@
identifier decl.i1,i2;
expression e;
initializer list[decl.n] is;
@@

struct i1 i2 = { is,
+ .fld = e
- e
,...};
// </smpl>

v2: Drop 0 initializers and add trailing commas at the suggestions of Josh
Triplett.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 295ee853 30-Jul-2014 Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Docbook fixes

Bunch of small leftovers spotted by looking at the make htmldocs output.

I've left out dp mst, there's too much amiss there.

v2: Also add the missing parameter docbook in the dp mst code - Dave
Airlie correctly pointed out that we don't actually want kerneldoc for
the missing structure members in header files.

Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 69ab6d35 05-Jun-2014 Vandana Kannan <vandana.kannan@intel.com>

drm/edid: Check for user aspect ratio input

In case user has specified an input for aspect ratio through the property,
then the user space value for PAR would take preference over the value from
CEA mode list.

v2: Thierry's review comments.
- Modified the comment "Populate..." as per review comments

v3: Thierry's review comments.
- Modified the comment to block comment format.

Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 008f4045 17-Jul-2014 Sean Paul <seanpaul@chromium.org>

drm: Check for connection_mutex in drm_select_eld

drm_select_eld should check for mode_config.connection_mutex as
well as mode_config.mutex: We need that since this function checks
conector->encoder links.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
[danvet: Pimp commit message slightly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 5d02626d 05-Jun-2014 Mario Kleiner <mario.kleiner.de@gmail.com>

drm/edid: Store all supported hdmi deep color modes in drm_display_info

HDMI deep color setup must know which modes are supported if
it needs to degrade gracefully, as only 12 bpc / dc_36 is
guaranteed, but 10 bpc / dc_30 is optional. The maximum bpc
is not sufficient for this.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 6e9f798d 29-May-2014 Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Split connection_mutex out of mode_config.mutex (v3)

After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
modeset-relevant connector state (e.g. properties which control the
panel fitter).

The later is used by modeset operations. But they don't really care
about the former since it's allowed to e.g. enable a disconnected VGA
output or with a mode not in the probed list.

Thus far this hasn't been a problem, but for the atomic modeset
conversion Rob Clark needs to convert all modeset relevant locks into
w/w locks. This is required because the order of acquisition is
determined by how userspace supplies the atomic modeset data. This has
run into troubles in the detect path since the i915 load detect code
needs _both_ protections offered by the mode_config.mutex: It updates
probe state and it needs to change the modeset configuration to enable
the temporary load detect pipe.

The big deal here is that for the probe/detect users of this lock a
plain mutex fits best, but for atomic modesets we really want a w/w
mutex. To fix this lets split out a new connection_mutex lock for the
modeset relevant parts.

For simplicity I've decided to only add one additional lock for all
connector/encoder links and modeset configuration states. We have
piles of different modeset objects in addition to those (like bridges
or panels), so adding per-object locks would be much more effort.

Also, we're guaranteed (at least for now) to do a full modeset if we
need to acquire this lock. Which means that fine-grained locking is
fairly irrelevant compared to the amount of time the full modeset will
take.

I've done a full audit, and there's just a few things that justify
special focus:
- Locking in drm_sysfs.c is almost completely absent. We should
sprinkle mode_config.connection_mutex over this file a bit, but
since it already lacks mode_config.mutex this patch wont make the
situation any worse. This is material for a follow-up patch.

- omap has a omap_framebuffer_flush function which walks the
connector->encoder->crtc links and is called from many contexts.
Some look like they don't acquire mode_config.mutex, so this is
already racy. Again fixing this is material for a separate patch.

- The radeon hot_plug function to retrain DP links looks at
connector->dpms. Currently this happens without any locking, so is
already racy. I think radeon_hotplug_work_func should gain
mutex_lock/unlock calls for the mode_config.connection_mutex.

- Same applies to i915's intel_dp_hot_plug. But again, this is already
racy.

- i915 load_detect code needs to acquire this lock. Which means the
w/w dance due to Rob's work will be nicely contained to _just_ this
function.

I've added fixme comments everywhere where it looks suspicious but in
the sysfs code. After a quick irc discussion with Dave Airlie it
sounds like the lack of locking in there is due to sysfs cleanup fun
at module unload.

v1: original (only compile tested)

v2: missing mutex_init(), etc (from Rob Clark)

v3: i915 needs more care in the conversion:
- Protect the edp pp logic with the connection_mutex.
- Use connection_mutex in the backlight code due to
get_pipe_from_connector.
- Use drm_modeset_lock_all in suspend/resume paths.
- Update lock checks in the overlay code.

Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>


# 25933820 03-Jun-2014 Jani Nikula <jani.nikula@intel.com>

drm: replace drm_get_connector_name() with direct name field use

Generated using semantic patch:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E->name

[airlied: regenerated]

Acked-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# bc5b9641 23-May-2014 Mario Kleiner <mario.kleiner.de@gmail.com>

drm/edid: Add quirk for Sony PVM-2541A to get 12 bpc hdmi deep color.

The Sony PVM-2541A OLED high precision color display supports
both 10 bpc and 12 bpc hdmi deep color input, but its edid
does not signal any deep color support.

Add a quirk to force it being treated as a 12 bpc panel.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# d0c94692 27-Mar-2014 Mario Kleiner <mario.kleiner.de@gmail.com>

drm/edid: Parse and handle HDMI deep color modes.

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: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 89086bca 26-May-2014 Benoit Taine <benoit.taine@lip6.fr>

drm/edid: Use kmemdup instead of kmalloc + memcpy

This issue was reported by coccicheck using the semantic patch
at scripts/coccinelle/api/memdup.cocci

Signed-off-by: Benoit Taine <benoit.taine@lip6.fr>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# db6cf833 29-Apr-2014 Thierry Reding <treding@nvidia.com>

drm/edid: Cleanup kerneldoc

This fixes up a couple of inconsistencies with kerneldoc comments for
the EDID related functions. Functions that return a value now use the
"Return" section consistently. For some exported symbols the kernel-doc
comments were not in the appropriate format and therefore not included
in the generated documentation. Others had no kernel-doc at all.

While at it, fix a couple of whitespace issues and capitalize common
abbreviations (i2c -> I2C, edid -> EDID, ...).

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 464fdeca 29-Apr-2014 Thierry Reding <treding@nvidia.com>

drm/edid: Drop revision argument for drm_mode_std()

This argument is used to pass in the revision of the EDID, but since the
EDID is passed in as well, we can just as well get the revision from the
EDID structure directly.

While at it, update the kerneldoc comment.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 0967e6a5 01-Apr-2014 Vandana Kannan <vandana.kannan@intel.com>

drm/edid: Fill PAR in AVI infoframe based on CEA mode list

Populate PAR in infoframe structure. If there is a user setting for PAR, then
that value is set. Else, value is taken from CEA mode list if VIC is found.
Else, PAR is calculated from resolution. If none of these conditions are
satisfied, PAR is NONE as per initialization.

v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.

A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.

v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.

v3: Removed calculation of PAR for non-CEA modes as per discussion with
Ville.

A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.

Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Cc: Jesse Barnes <jesse.barnes@intel.com>
Cc: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Squash in fixup for htmldocs.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 409bbf1e 03-Mar-2014 Damien Lespiau <damien.lespiau@intel.com>

drm: Check if the allocation has succeeded before dereferencing newmode

We allocate memory in drm_display_mode_from_vic_index() and use it
without checking the pointer is valid. Fix that.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 9d3de138 23-Jan-2014 Daniel Vetter <daniel.vetter@ffwll.ch>

drm/modes: remove drm_mode_height/width

There's a neat FIXME asking whether this is really need. I'd
say really no.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# fc66811c 20-Jan-2014 Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Fix up kerneldoc in drm_edid.c

v2: Also do s/RETURNS/Returns/, less yelling in docs is always good.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 24d01805 27-Feb-2014 Daniel Drake <drake@endlessm.com>

drm/edid: request HDMI underscan by default

Working with HDMI TVs is a real pain as they tend to overscan by
default, meaning that the pixels around the edge of the framebuffer
are not displayed. This is well explained here:
http://mjg59.dreamwidth.org/8705.html

There is a bit in the HDMI info frame that can request that the
remote display shows the full pixel data ("underscan"). For the
remote display, the HDMI spec states that this is optional - it
doesn't have to listen. That means that most TVs will probably ignore
this.

But, maybe there are a handful of TVs for which this would help
the situation. As we live in a digital world, ask the remote
display not to overscan by default.

Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 985e5dc2 19-Dec-2013 Vandana Kannan <vandana.kannan@intel.com>

drm/edid: Populate picture aspect ratio for CEA modes

Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
CEA-861E Table 4. This is useful for filling up the detail in AVI
infoframe.

v2: Ville's review comments incorporated
Added picture aspect ratio as part of edid_cea_modes instead of DRM_MODE

Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 0e5083aa 29-Nov-2013 Thomas Wood <thomas.wood@intel.com>

drm/edid: parse the list of additional 3D modes

Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Data Block.

v2: Use an offset value depending on 3D_Multi_present and add
detail_present. (Ville Syrjälä)
v3: Make sure the list is parsed even if 3D_Structure_ALL/MASK is not
present. (Ville Syrjälä)
Fix one length check and remove another. (Ville Syrjälä)

Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# aff04ace 29-Nov-2013 Thomas Wood <thomas.wood@intel.com>

drm/edid: split VIC display mode lookup into a separate function

Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 49d45a31 07-Dec-2013 Rafał Miłecki <zajec5@gmail.com>

drm/edid: add quirk for BPC in Samsung NP700G7A-S01PL notebook

This bug in EDID was exposed by:

commit eccea7920cfb009c2fa40e9ecdce8c36f61cab66
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Mon Mar 26 15:12:54 2012 -0400

drm/radeon/kms: improve bpc handling (v2)

Which resulted in kind of regression in 3.5. This fixes
https://bugs.freedesktop.org/show_bug.cgi?id=70934

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 89570eeb 28-Nov-2013 Thomas Wood <thomas.wood@intel.com>

drm: fix the addition of the side-by-side (half) flag for extra 3D modes

Ensure the side-by-side (half) flag is added to any existing flags when
adding modes from 3D_Structure_ALL.

Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 7d14b95f 29-Nov-2013 Thomas Wood <thomas.wood@intel.com>

drm/edid: fix length check when adding extra 3D modes

Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 339d202c 15-Aug-2013 Alex Deucher <alexander.deucher@amd.com>

drm/edid: compare actual vrefresh for all modes for quirks

The vrefresh field of the mode is 0 for most modes
fetched from the EDID (e.g., established timings).
When dealing with monitors that have a bogus preferred
mode, we may not always select the mode we want because
we compare the target refresh to the mode's vrefresh which
is 0 in a lot of cases.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>


# 3cf70daf 11-Oct-2013 Gerd Hoffmann <kraxel@redhat.com>

drm: add drm_set_preferred_mode

New helper function to set the preferred video mode. Can be called
after drm_add_modes_noedid if you don't want the largest supported
video mode be used by default.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# e7bfa5c4 14-Oct-2013 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Yank a helpful comment about EST modes from xf86EdidModes.c

I got very confused when I tried to compare the EST modes with the spec.
Bring over a comment from xf86EdidModes.c that actually describes some
of history where these things came from.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 891a7469 14-Oct-2013 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Don't skip every eighth EST III mode

Also check the est3 modes whose presence is indicated by bit 0.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# c068b32a 14-Oct-2013 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Fix the 1792x1344-75 EST III mode

The correct refresh rate for this mode is 75, not 85.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# fbf46025 16-Oct-2013 Thomas Wood <thomas.wood@intel.com>

drm: add support for additional stereo 3D modes

Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.

v2: Use (1 << 0) for consistency. (Ville Syrjälä)
Skip adding any modes if 3D_MASK is indicated as being present but
the length only includes 3D_Structure_ALL. (Ville Syrjälä)
Check that the value of HDMI_3D_LEN is large enough to include
3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä)
v3: Increment offset before the length checks. (Ville Syrjälä)

Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# aaed41ec 27-Sep-2013 Alex Deucher <alexander.deucher@amd.com>

drm/edid: catch kmalloc failure in drm_edid_to_speaker_allocation

Return -ENOMEM if the allocation fails.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>


# f7e121b7 26-Sep-2013 Damien Lespiau <damien.lespiau@intel.com>

drm: Code stereo layouts as an enum rather than a bit field

This allows us to use fewer bits in the mode structure, leaving room for
future work while allowing more stereo layouts types than we could have
ever dreamt of.

I also exposed the previously private DRM_MODE_FLAG_3D_MASK to set in
stone that we are using 5 bits for the stereo layout enum, reserving 32
values.

Even with that reservation, we gain 3 bits from the previous encoding.

The code adding the mandatory stereo modes needeed to be adapted as it was
relying or being able to or stereo layouts together.

Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 27130212 25-Sep-2013 Damien Lespiau <damien.lespiau@intel.com>

drm: Carry over the stereo flags when adding the alternate mode

This allows to expose the alternate clock versions of the stereo modes.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# f2ecf2e3 25-Sep-2013 Damien Lespiau <damien.lespiau@intel.com>

drm: Make drm_match_cea_mode() return the underlying 2D VIC for 3d modes

When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 4eed4a0a 25-Sep-2013 Damien Lespiau <damien.lespiau@intel.com>

drm: Set the relevant infoframe field when scanning out a 3D mode

When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.

v2: Make s3d_structure_from_display_mode() less subtle (Ville Syrjälä)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 1deee8d7 25-Sep-2013 Damien Lespiau <damien.lespiau@intel.com>

drm: Extract add_hdmi_mode() out of do_hdmi_vsdb_modes()

So we respect a nice design of having similar functions at the same
level, in this case:

do_hdmi_vsdb_modes()
- add_hdmi_mandatory_stereo_modes()
- add_hdmi_mode()

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# c858cfca 25-Sep-2013 Damien Lespiau <damien.lespiau@intel.com>

drm/edid: Expose mandatory stereo modes for HDMI sinks

For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.

See the HDMI 1.4a 3D extraction for detail:
http://www.hdmi.org/manufacturer/specification.aspx

v2: Rename freq to vrefresh, make the mandatory structure a bit more
compact, fix some white space issues and add a couple of const
(Ville Syrjälä)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 618e3776 27-Sep-2013 Alex Deucher <alexdeucher@gmail.com>

drm/edid: catch kmalloc failure in drm_edid_to_speaker_allocation

Return -ENOMEM if the allocation fails.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 51f8da59 27-Sep-2013 Jani Nikula <jani.nikula@intel.com>

drm/edid: add drm_edid_duplicate

We have some code duplication related to EDID duplication. Add a helper.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# d105f476 25-Jul-2013 Alex Deucher <alexander.deucher@amd.com>

drm/edid: add a helper function to extract the speaker allocation data block (v3)

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: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>


# 118bdbd8 12-Aug-2013 Alex Deucher <alexander.deucher@amd.com>

drm/edid: add quirk for Medion MD30217PG

This LCD monitor (1280x1024 native) has a completely
bogus detailed timing (640x350@70hz). User reports that
1280x1024@60 has waves so prefer 1280x1024@75.

Manufacturer: MED Model: 7b8 Serial#: 99188
Year: 2005 Week: 5
EDID Version: 1.3
Analog Display Input, Input Voltage Level: 0.700/0.700 V
Sync: Separate
Max Image Size [cm]: horiz.: 34 vert.: 27
Gamma: 2.50
DPMS capabilities: Off; RGB/Color Display
First detailed timing is preferred mode
redX: 0.645 redY: 0.348 greenX: 0.280 greenY: 0.605
blueX: 0.142 blueY: 0.071 whiteX: 0.313 whiteY: 0.329
Supported established timings:
720x400@70Hz
640x480@60Hz
640x480@72Hz
640x480@75Hz
800x600@56Hz
800x600@60Hz
800x600@72Hz
800x600@75Hz
1024x768@60Hz
1024x768@70Hz
1024x768@75Hz
1280x1024@75Hz
Manufacturer's mask: 0
Supported standard timings:
Supported detailed timing:
clock: 25.2 MHz Image Size: 337 x 270 mm
h_active: 640 h_sync: 688 h_sync_end 784 h_blank_end 800 h_border: 0
v_active: 350 v_sync: 350 v_sync_end 352 v_blanking: 449 v_border: 0
Monitor name: MD30217PG
Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
Serial No: 501099188
EDID (in hex):
00ffffffffffff0034a4b80774830100
050f010368221b962a0c55a559479b24
125054afcf00310a0101010101018180
000000000000d60980a0205e63103060
0200510e1100001e000000fc004d4433
3032313750470a202020000000fd0038
4c1e530e000a202020202020000000ff
003530313039393138380a2020200078

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reported-by: friedrich@mailstation.de
Cc: stable@vger.kernel.org


# 6cb3b7f1 19-Aug-2013 Lespiau, Damien <damien.lespiau@intel.com>

video/hdmi: Rename HDMI_IDENTIFIER to HDMI_IEEE_OUI

HDMI_IDENTIFIER was felt too generic, rename it to what it is, the IEEE
OUI corresponding to HDMI Licensing, LLC.

http://standards.ieee.org/develop/regauth/oui/oui.txt

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>


# 83dd0008 19-Aug-2013 Lespiau, Damien <damien.lespiau@intel.com>

drm: Add a helper to forge HDMI vendor infoframes

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: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>


# c782d2e7 19-Aug-2013 Lespiau, Damien <damien.lespiau@intel.com>

drm/edid: Move HDMI_IDENTIFIER to hdmi.h

We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.

(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
details..)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>


# a5ad3dcf 19-Aug-2013 Lespiau, Damien <damien.lespiau@intel.com>

video/hdmi: Don't let the user of this API create invalid infoframes

To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:

Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Tue Aug 6 20:32:17 2013 +0100

drm: Don't generate invalid AVI infoframes for CEA modes

We can do better and derive the _valid bit from the user wanting to set
the active aspect ratio.

v2: Fix multi-lines comment style (Thierry Reding)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>


# 3f2f6533 19-Aug-2013 Lespiau, Damien <damien.lespiau@intel.com>

drm: Add support for alternate clocks of 4k modes

v2: Fix hmdi typo (Simon Farnsworth, Ville Syrjälä)

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>


# 7ebe1963 19-Aug-2013 Lespiau, Damien <damien.lespiau@intel.com>

drm/edid: Parse the HDMI CEA block and look for 4k modes

HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.

With this commit, we now parse this block and expose the 4k modes that
we find there.

v2: Fix the "4096x2160" string (nice catch!), add comments about
do_hdmi_vsdb_modes() arguments and make it clearer that offset is
relative to the end of the required fields of the HDMI VSDB
(Ville Syrjälä)

v3: Fix 'Unknow' typo (Simon Farnsworth)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Tested-by: Cancan Feng <cancan.feng@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>


# 13ac3f55 19-Aug-2013 Lespiau, Damien <damien.lespiau@intel.com>

drm/edid: Fix add_cea_modes() style issues

A few styles issues have crept in here, fix them before touching this
code again.

v2: constify arguments that can be (Ville Syrjälä)
v3: constify, but better (Ville Syrjälä)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>


# d4e4a31d 19-Aug-2013 Lespiau, Damien <damien.lespiau@intel.com>

drm: Don't export drm_find_cea_extension() any more

This function is only used inside drm_edid.c.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>


# 15747638 06-Aug-2013 Damien Lespiau <damien.lespiau@intel.com>

drm: Set aspect ratio fields in the AVI infoframe even for non CEA modes

I cannot find any evidence what we shouldn't try to set those fields
when setting a non-CEA mode on an HDMI sink. So just kill that return.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# bf02db99 06-Aug-2013 Damien Lespiau <damien.lespiau@intel.com>

drm: Handle the DBLCLK flag in the common infoframe helper

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 03a7a189 06-Aug-2013 Damien Lespiau <damien.lespiau@intel.com>

drm: Don't generate invalid AVI infoframes for CEA modes

From CEA-861:

Data Byte 1, bit A0 indicates whether Active Format Data is present in
Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
any of the AFD bits are set.

ie. if we want to set active_aspect, we need to set the
active_info_valid bit to 1 as well.

Cc: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# fe2ef780 02-Jul-2013 Seung-Woo Kim <sw0312.kim@samsung.com>

drm: add assertion for checking null edid to drm_edid_block_valid

If raw_edid of drm_edid_block_vaild() is null, it will crash, so
checking in bad label is removed and instead assertion is added at
the top of the function.
The type of return for the function is bool, so it fixes to return
true and false instead of 1 and 0.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# c7d015f3 13-Jun-2013 Egbert Eich <eich@suse.com>

drm/edid: Don't print messages regarding stereo or csync by default

drm_mode_detailed() is called quite often, therefore when a monitor
that has a detailed timing mode marked DRM_EDID_PT_STEREO or requiring
composite sync, warning messages will clutter up the kernel log.
Like we already do for incorrect hsync/vsync pluse widths, print these
messages only when KMS debugging is enabled.

Signed-off-by: Egbert Eich <eich@suse.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# e6e79209 31-May-2013 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.

Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# a90b590e 24-Apr-2013 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Check both 60Hz and 59.94Hz when looking for a CEA mode

drm_match_cea_mode() should be able to match both the 60Hz version,
and the 59.94Hz version of modes.

We only store one pixel clock value per mode in edid_cea_modes, so the
other value must be calculated. Depending on the mode, edid_cea_modes
contains the pixel clock for either the 60Hz version or the 59.94Hz
version, so a bit of care is needed so that the calculation produces
the correct result.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# ee7925bb 24-Apr-2013 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Populate vrefresh for CEA modes

Well have use for the vrefresh information of CEA modes later. Just
populate the information into the table to avoid having to calculate
it.

I'm too lazy to check if someone relies on newly allocated CEA
modes having 0 vrefresh, so just clear vrefresh back to 0 when
adding the mode to the connector's modelist.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# fe214163 19-Apr-2013 Rafał Miłecki <zajec5@gmail.com>

drm: add drm_edid_to_eld helper extracting SADs from EDID (v2)

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: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# c19b3b0f 23-Mar-2013 Torsten Duwe <torsten@lst.de>

KMS: fix EDID detailed timing frame rate

When KMS has parsed an EDID "detailed timing", it leaves the frame rate
zeroed. Consecutive (debug-) output of that mode thus yields 0 for
vsync. This simple fix also speeds up future invocations of
drm_mode_vrefresh().

While it is debatable whether this qualifies as a -stable fix I'd apply
it for consistency's sake; drm_helper_probe_single_connector_modes()
does the same thing already for all probed modes.

Cc: stable@vger.kernel.org
Signed-off-by: Torsten Duwe <duwe@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 16dad1d7 23-Mar-2013 Torsten Duwe <torsten@lst.de>

KMS: fix EDID detailed timing vsync parsing

EDID spreads some values across multiple bytes; bit-fiddling is needed
to retrieve these. The current code to parse "detailed timings" has a
cut&paste error that results in a vsync offset of at most 15 lines
instead of 63.

See

http://en.wikipedia.org/wiki/EDID

and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why
that needs to be a left shift.

Cc: stable@vger.kernel.org
Signed-off-by: Torsten Duwe <duwe@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 10a85120 21-Nov-2012 Thierry Reding <thierry.reding@avionic-design.de>

drm: Add HDMI infoframe helpers

Add a generic helper to fill in an HDMI AVI infoframe with data
extracted from a DRM display mode.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# a6b21831 23-Nov-2012 Thierry Reding <thierry.reding@avionic-design.de>

drm: Move mode tables to drm_edid.c

The modes are only used from within drm_edid.c so we move them there to
avoid creating duplicates by multiple inclusion of drm_edid_modes.h. As
a side-effect we can also get rid of a few variables that keep track of
the number of entries in the tables and use ARRAY_SIZE() instead.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# 18316c8c 20-Dec-2012 Thierry Reding <thierry.reding@avionic-design.de>

drm: Remove duplicate drm_mode_cea_vic()

The same function had already been merged with a different name. Remove
the duplicate one but reuse some of its kerneldoc fragments for the
existing implementation.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>


# 196e077d 15-Feb-2013 Paulo Zanoni <paulo.r.zanoni@intel.com>

drm: don't add inferred modes for monitors that don't support them

If bit 0 of the features byte (0x18) is set to 0, then, according to
the EDID spec, "the display is non-continuous frequency (multi-mode)
and is only specified to accept the video timing formats that are
listed in Base EDID and certain Extension Blocks".

For more information, please see the EDID spec, check the notes of the
table that explains the "Feature Support" byte (18h) and also the
notes on the tables of the section that explains "Display Range Limits
& Additional Timing Description Definition (tag #FDh)".

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# f934ec8c 29-Jan-2013 Maarten Lankhorst <maarten.lankhorst@canonical.com>

drm: shut up invalid edid messages

My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam every few seconds.

I get it the first time that the entire block is all 0xff..

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org [v3.7]
Signed-off-by: Dave Airlie <airlied@redhat.com>


# db3985e5 13-Feb-2013 Daniel Vetter <daniel.vetter@ffwll.ch>

Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"

This reverts commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b.

The quirk cause a regression, and it looks like the original bug was
simply a lack of FIFO bandwidth on the i915G of the reporter. Which
should eventually be fixed as soon as we get around to implemented
DSPARB FIFO reassignment on gen 3.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# b1edd6a6 17-Jan-2013 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/edid: Add drm_rgb_quant_range_selectable()

drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.

The information can be found in the CEA Video capability block.

v2: s/quantzation/quantization/ in the comment

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: David Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 374a868a 22-Nov-2012 Paulo Zanoni <paulo.r.zanoni@intel.com>

drm: add drm_mode_cea_vic

This function returns the VIC of the mode. This value can be used when
creating AVI InfoFrames.

Cc: Thierry Reding <thierry.reding@avionic-design.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 670c1ef6 22-Nov-2012 Daniel Vetter <daniel.vetter@ffwll.ch>

drm/edid: tune down debug message in parse_hdmi_vsdb

Those tend to be totally not interesting for end-users, and for
debugging we tend to dump the entire noise anyway by enabling all
debug messages.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57388
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 6311803b 08-Nov-2012 Akinobu Mita <akinobu.mita@gmail.com>

drm: use memchr_inv()

Use memchr_inv() to check the specified memory region is filled with zero.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>


# a4799037 09-Nov-2012 Stephane Marchesin <marcheu@chromium.org>

drm: get cea video id code for a given display mode

This patch adds support for getting CEA Video ID Code for a given
display mode after matching with edid_cea_modes list. Its index in
the list added with one, gives the desired code.

This exported function will be used by hdmi drivers for composing
AVI info frame data.

Signed-off-by: Stephane Marchesin <marcheu@chromium.org>
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 760285e7 02-Oct-2012 David Howells <dhowells@redhat.com>

UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/

Convert #include "..." to #include <path/...> in drivers/gpu/.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>


# fbff4690 18-Sep-2012 Adam Jackson <ajax@redhat.com>

drm: Export drm_probe_ddc()

Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 015b85a0 18-Sep-2012 Adam Jackson <ajax@redhat.com>

drm: Export drm_probe_ddc()

Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 0b2443ed 09-Aug-2012 Jerome Glisse <jglisse@redhat.com>

drm/edid: limit printk when facing bad edid

Limit printing bad edid information at one time per connector.
Connector that are connected to a bad monitor/kvm will likely
stay connected to the same bad monitor/kvm and it makes no
sense to keep printing the bad edid message.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# cd004b3f 30-Aug-2012 Shirish S <s.shirish@samsung.com>

drm: edid: add support for E-DDC

The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.

To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.

Signed-off-by: Shirish S <s.shirish@samsung.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 14f77fdd 16-Aug-2012 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: edid: Refactor HDMI VSDB detection

There are two slightly different pieces of code for HDMI VSDB
detection. Unify the code into a single helper function.

Also fix a bug where drm_detect_hdmi_monitor() would stop looking
for the HDMI VSDB after the first vendor specific block is found,
whether or not that block happened to be the HDMI VSDB. The
standard allows for any number of vendor specific blocks to be
present.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 8504072a 16-Aug-2012 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: edid: Add bounds checking to HDMI VSDB parsing

The length of HDMI VSDB must be at least 5 bytes. Other than the minimum,
nothing else about the length is specified. Check the length before
accessing any additional field beyond the minimum length.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 9e50b9d5 16-Aug-2012 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: edid: Add some bounds checking

Make sure drm_detect_hdmi_monitor() and drm_detect_monitor_audio() don't
access beyond the extension block.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 6f33814b 08-Aug-2012 Paul Menzel <paulepanter@users.sourceforge.net>

drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.

In commit bc42aabc [2]

commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
Author: Adam Jackson <ajax@redhat.com>
Date: Wed May 23 16:26:54 2012 -0400

drm/edid/quirks: ViewSonic VA2026w

Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.

All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.

Please note that this monitor only has a VGA (D-Sub) connector [1].

[1] http://www.asus.com/Display/LCD_Monitors/VW222S/
[2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Cc: <dri-devel@lists.freedesktop.org>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Ian Pilcher <arequipeno@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 451023dc 15-Aug-2012 Jani Nikula <jani.nikula@intel.com>

drm: remove the raw_edid field from struct drm_display_info

Neither the drm core nor any of the drivers really need the raw_edid field
of struct drm_display_info for anything. Instead of being useful, it
creates confusion about who is responsible for freeing the memory it points
to and setting the field to NULL afterwards, leading to memory leaks and
dangling pointers.

Remove the raw_edid field, and fix drivers as necessary.

Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 7b668ebe 03-Jul-2012 Takashi Iwai <tiwai@suse.de>

drm: edid: Don't add inferred modes with higher resolution

When a monitor EDID doesn't give the preferred bit, driver assumes
that the mode with the higest resolution and rate is the preferred
mode. Meanwhile the recent changes for allowing more modes in the
GFT/CVT ranges give actually more modes, and some modes may be over
the native size. Thus such a mode would be picked up as the preferred
mode although it's no native resolution.

For avoiding such a problem, this patch limits the addition of
inferred modes by checking not to be greater than other modes.
Also, it checks the duplicated mode entry at the same time.

Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# b196a498 19-Jun-2012 Daniel Vetter <daniel.vetter@ffwll.ch>

drm/edid: don't return stack garbage from supports_rb

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: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 47819ba2 30-May-2012 Adam Jackson <ajax@redhat.com>

drm/edid: Make the header fixup threshold tunable

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/582559
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# bc42aabc 23-May-2012 Adam Jackson <ajax@redhat.com>

drm/edid/quirks: ViewSonic VA2026w

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/516471
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# c51a3fd6 22-Apr-2012 Ian Pilcher <arequipeno@gmail.com>

drm: Store vendor IDs directly in the EDID quirk structure

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: Ian Pilcher <arequipeno@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# f89ec8a4 16-Apr-2012 Adam Jackson <ajax@redhat.com>

drm/edid: Try harder to fix up base EDID blocks

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/812890
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# c09dedb7 23-Apr-2012 Takashi Iwai <tiwai@suse.de>

drm/edid: Add a workaround for 1366x768 HD panel

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: Takashi Iwai <tiwai@suse.de>
Acked-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# fc48f169 19-Apr-2012 Takashi Iwai <tiwai@suse.de>

drm/edid: add missing NULL checks.

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


# b309bd37 13-Apr-2012 Adam Jackson <ajax@redhat.com>

drm/edid: Generate modes from extra_modes for range descriptors

Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# cb21aafe 13-Apr-2012 Adam Jackson <ajax@redhat.com>

drm/edid: Do drm_dmt_modes_for_range() for all range descriptor types

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: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# cd4cd3de 13-Apr-2012 Adam Jackson <ajax@redhat.com>

drm/edid: s/drm_gtf_modes_for_range/drm_dmt_modes_for_range/

Slightly more honest naming.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 9a225c9c 13-Apr-2012 Adam Jackson <ajax@redhat.com>

drm/edid: Remove a misleading comment

mode_in_range() handles what this was warning about.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# f6e252ba 13-Apr-2012 Adam Jackson <ajax@redhat.com>

drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modes

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: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# f8b46a05 13-Apr-2012 Adam Jackson <ajax@redhat.com>

drm/edid: Rewrite drm_mode_find_dmt search loop

No functional change, but will make an upcoming change clearer.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 33c7531d 13-Apr-2012 Adam Jackson <ajax@redhat.com>

drm/edid: Document drm_mode_find_dmt

Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# a988bc72 16-Apr-2012 Lars-Peter Clausen <lars@metafoo.de>

drm: Parse color format information in CEA blocks

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: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# ee58808d 16-Apr-2012 Lars-Peter Clausen <lars@metafoo.de>

drm: Fix EDID color format parsing

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: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# ef61d3d8 23-Sep-2011 Matt Turner <mattst88@gmail.com>

drm: remove unneeded redefinition of DDC_ADDR

It's already defined in drm_edid.h.

Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# da0df92b 18-Mar-2012 Carsten Emde <C.Emde@osadl.org>

drm: allow loading an EDID as firmware to override broken monitor

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: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# aefd330e 01-Feb-2012 Sascha Hauer <s.hauer@pengutronix.de>

drm/edid: drm modes have to be free with drm_mode_destroy

to add the missing drm_mode_object_put for that mode.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 9292f37e 05-Jan-2012 Eugeni Dodonov <eugeni.dodonov@intel.com>

drm: give up on edid retries when i2c bus is not responding

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: Chris Wilson <chris@hchris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Sean Finney <seanius@seanius.net>
Tested-by: Soren Hansen <soren@linux2go.dk>
Tested-by: Hernando Torque <sirius@sonnenkinder.org>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 4966b2a9 19-Dec-2011 Christian Schmidt <schmidt@digadd.de>

Fix wrong assumptions in cea_for_each_detailed_block v2

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: Christian Schmidt <schmidt@digadd.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# a0ab734d 19-Dec-2011 Christian Schmidt <schmidt@digadd.de>

drm_edid_to_eld: check for CEA data blocks only from structure revision 3 on

CEA datablocks are only defined from revision 3 onwards. Only check for
them if the revision says so.

Signed-of-by: Christian Schmidt <schmidt@digadd.de>
Tested-by: James Cloos <cloos@jhcloos.com>

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


# 54ac76f8 19-Dec-2011 Christian Schmidt <schmidt@digadd.de>

drm/edid: support CEA video modes.

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: Christian Schmidt <schmidt@digadd.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 2d1a8a48 30-Aug-2011 Paul Gortmaker <paul.gortmaker@windriver.com>

gpu: Add export.h as required to drivers/gpu files.

They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>


# 76adaa34 05-Sep-2011 Wu Fengguang <fengguang.wu@intel.com>

drm: support routines for HDMI/DP ELD

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: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>


# 051963d4 29-Jul-2011 Thomas Reim <reimth@gmail.com>

drm: Separate EDID Header Check from EDID Block Check

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: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# ebec9a7b 03-Aug-2011 Jesse Barnes <jbarnes@virtuousgeek.org>

drm: track CEA version number if present

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: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>


# 0aff47f2 05-Jul-2011 Tormod Volden <debian.tormod@gmail.com>

drm: really make debug levels match in edid failure code

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: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 4a9a8b71 14-Jun-2011 Dave Airlie <airlied@linux.ie>

drm/radeon: workaround a hw bug on some radeon chipsets with all-0 EDIDs.

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: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>


# f49dadb8 14-Jun-2011 Dave Airlie <airlied@linux.ie>

drm: make debug levels match in edid failure code.

this puts the header and followup at the same loglevel as the
hex dump code.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>


# da05a5a7 15-Apr-2011 Jesse Barnes <jbarnes@virtuousgeek.org>

drm: parse color format support for digital displays

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: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 3b11228b 15-Apr-2011 Jesse Barnes <jbarnes@virtuousgeek.org>

drm: add bit depth parsing

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: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# eccaca28 29-Mar-2011 Ben Skeggs <bskeggs@redhat.com>

drm: export drm_find_cea_extension to drivers

Nouveau needs access to this structure to build an ELD block for use
by the HDA audio codec.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 4819d2e4 15-Mar-2011 Chris Wilson <chris@chris-wilson.co.uk>

drm: Retry i2c transfer of EDID block after failure

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: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# b1f559ec 26-Jan-2011 Chris Wilson <chris@chris-wilson.co.uk>

drm: Mark constant arrays of drm_display_mode const

... 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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 0ea75e23 23-Sep-2010 Sam Tygier <samtygier@yahoo.co.uk>

DRM: ignore invalid EDID extensions

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: Sam Tygier <samtygier@yahoo.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 8fe9790d 19-Sep-2010 Zhenyu Wang <zhenyuw@linux.intel.com>

drm/edid: add helper function to detect monitor audio capability

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: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>


# f899fc64 20-Jul-2010 Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: use GMBUS to manage i2c links

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: Chris Wilson <chris@chris-wilson.co.uk>


# 38fcbb67 03-Aug-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Split mode lists out to their own header for readability

... of the code, not of the mode lists.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 13931579 03-Aug-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Rewrite mode parse to use the generic detailed block walk

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: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# cbba98f8 03-Aug-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Add detailed block walk for VTB extensions

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 4d76a221 03-Aug-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Add detailed block walk for CEA extensions

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# fb439640 03-Aug-2010 Adam Jackson <ajax@redhat.com>

drm: Remove unused fields from drm_display_info

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# a4967de6 27-Jul-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Fix the HDTV hack sync adjustment

We're adjusting horizontal timings only here, moving vsync was just a
slavish translation of a typo in the X server.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 3c581411 28-Jun-2010 Kulikov Vasiliy <segooon@gmail.com>

drm: drm_edid: use ARRAY_SIZE

Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).

Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>


# dcdb1674 27-May-2010 Jordan Crouse <jcrouse@codeaurora.org>

drm: Add support for platform devices to register as DRM devices

Allow platform devices without PCI resources to be DRM devices.

[airlied: fixup warnings with dev pointers]

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 4a638b4e 25-May-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Allow non-fatal checksum errors in CEA blocks

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

https://bugs.freedesktop.org/28229

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# c43ae476 19-May-2010 Alex Deucher <alexdeucher@gmail.com>

drm/edid: fix typo in 1600x1200@75 mode

Spotted by Scott Bertilson.
Fixes fdo bug 28146.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Mark Marshall <mark.marshall@csr.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 1d42bbc8 06-May-2010 Dave Airlie <airlied@redhat.com>

drm/fbdev: fix cloning on fbcon

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: Dave Airlie <airlied@redhat.com>


# 0ddfa7d5 07-May-2010 Dan Carpenter <error27@gmail.com>

drm: off by one in drm_edid.c

m == num_est3_modes is one past the end of the est3_modes[].

Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 61dd98fa 13-May-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Fix 1024x768@85Hz

Having hsync both start and end on pixel 1072 ain't gonna work very
well. Matches the X server's list.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-By: Michael Tokarev <mjt@tls.msk.ru>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 0bcad4c9 16-May-2010 Dan Carpenter <error27@gmail.com>

drm/edid: remove an unneeded variable

We don't use timing_level any more after: 9cf00977da0 "drm/edid: Unify
detailed block parsing between base and extension blocks".

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 522032da 09-Apr-2010 Adam Jackson <ajax@redhat.com>

drm/edid: When checking duplicate standard modes, walked the probed list

... and not the global list.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# ba1163de 06-Apr-2010 Adam Jackson <ajax@redhat.com>

drm/edid/quirks: Envision EN2028

Claims 1280x1024 preferred, physically 1600x1200

cf. http://bugzilla.redhat.com/530399

Signed-off-by: Adam Jackson <ajax@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 171fdd89 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/modes: Fix interlaced mode names

Height in frame size, not field size, and trailed with an 'i'. Matches
the X server behaviour.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 7a374350 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Add secondary GTF curve support

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: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 7ca6adb3 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Strengthen the algorithm for standard mode codes

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: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# a0910c8e 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Fix the HDTV hack.

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: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# b17e52ef 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Extend range-based mode addition for EDID 1.4

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: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# d1ff6409 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Add test for monitor reduced blanking support.

The generic block walk callback looks like overkill, but we'll need it
for other detailed block walks in the future.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# a327f6b8 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Fix preferred mode parse for EDID 1.4

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: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 59d8aff6 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Remove some silly comments

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 7466f4cc 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Remove arbitrary EDID extension limit

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 2255be14 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Add modes for Established Timings III section

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# c867df70 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Reshuffle mode list construction to closer match the spec

Also, document what the spec says to do.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 2b470ab0 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Remove a redundant check

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# fbcc06b6 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Remove some misleading comments

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 61e57a8d 29-Mar-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Fix secondary block fetch.

This makes fetching the second EDID block on HDMI monitors actually
work. DDC can't transfer more than 128 bytes at a time. Also,
rearrange the code so the pure DDC bits are separate from block parse.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 5a0e3ad6 24-Mar-2010 Tejun Heo <tj@kernel.org>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>


# 44fef224 17-Feb-2010 Ben Skeggs <bskeggs@redhat.com>

drm/edid: allow certain bogus edids to hit a fixup path rather than fail

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>


# b58db2c6 15-Feb-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Fix interlaced detailed timings to be frame size, not field.

cf. https://bugzilla.redhat.com/show_bug.cgi?id=533561

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 3c537889 05-Feb-2010 Alex Deucher <alexdeucher@gmail.com>

drm/radeon/kms: add support for hardcoded edids in rom (v2)

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: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 79b7dcb2 14-Jan-2010 Jerome Glisse <jglisse@redhat.com>

drm: EDID accept separate sync video mode

X is accepting such video mode, do the same. Pointed out by Joshua Roys
on IRC. Fix https://bugzilla.redhat.com/show_bug.cgi?id=540024

[fix printf to use composite not integrated :- airlied]

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 8e10ee9a 04-Jan-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Fix CVT width/height decode

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 69da3015 04-Jan-2010 Adam Jackson <ajax@redhat.com>

drm/edid: Skip empty CVT codepoints

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 29ebdf92 20-Dec-2009 Marin Mitov <mitov@issp.bas.bg>

drm/kms: silencing a false positive warning.

warning: 'width' may be used uninitialized in this function
drivers/gpu/drm/drm_edid.c

Signed-off-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 9340d8cf 03-Dec-2009 Adam Jackson <ajax@redhat.com>

drm/edid: Decode 3-byte CVT codes from EDID 1.4

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 07a5e632 03-Dec-2009 Adam Jackson <ajax@redhat.com>

drm/edid: Add DMT modes to the pool if the monitor is GTF-capable

See also: http://bugzilla.redhat.com/539785

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 9cf00977 03-Dec-2009 Adam Jackson <ajax@redhat.com>

drm/edid: Unify detailed block parsing between base and extension blocks

Also fix an embarassing bug in standard timing subblock parsing that
would result in an infinite loop.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 7064fef5 05-Nov-2009 Jesse Barnes <jbarnes@virtuousgeek.org>

drm: work around EDIDs with bad htotal/vtotal values

We did this on the userspace side, but we need a similar fix for the
kernel.

Fixes LP #460664.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 862b89c0 23-Nov-2009 Adam Jackson <ajax@redhat.com>

drm/edid: Fix up partially corrupted headers

We'll still fail the block if it fails the EDID checksum though.

See also: http://bugzilla.redhat.com/534120

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 47ee4ccf 23-Nov-2009 Adam Jackson <ajax@redhat.com>

drm/edid: Retry EDID fetch up to four times

This matches the X server's retry logic. Note that we'll only retry if
we get a DDC response but fail validation; legitimately disconnected
outputs will bomb out early.

See also: http://bugzilla.redhat.com/532957

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# f985dedb 23-Nov-2009 Adam Jackson <ajax@redhat.com>

drm/modes: Limit fallback modes to 60Hz

See also: http://bugzilla.redhat.com/514600

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# fcb45611 13-Oct-2009 Zhao Yakui <yakui.zhao@intel.com>

drm: Add the basic check for the detailed timing in EDID

Sometimes we will get the incorrect display modeline when parsing the detailed
timing in EDID. For example:
>hsync/vsync width is zero
>sync is beyond the blank.

So add the basic check for the detailed timing in EDID to avoid the incorrect
display modeline.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# f059d2ad 13-Oct-2009 Zhao Yakui <yakui.zhao@intel.com>

drm: Add the basic check for the detailed timing in EDID

Sometimes we will get the incorrect display modeline when parsing the detailed
timing in EDID. For example:
>hsync/vsync width is zero
>sync is beyond the blank.

So add the basic check for the detailed timing in EDID to avoid the incorrect
display modeline.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# d50ba256 22-Sep-2009 Dave Airlie <airlied@linux.ie>

drm/kms: start adding command line interface using fb.

[note this requires an fb patch posted to linux-fbdev-devel already]

This uses the normal video= command line option to control the kms
output setup at boot time. It is used to override the autodetection
done by kms.

video= normally takes a framebuffer as the first parameter, in kms
it will take a connector name, DVI-I-1, or LVDS-1 etc. If no output
connector is specified the mode string will apply to all connectors.

The mode specification used will match down the probed modes, and if
no mode is found it will add a CVT mode that matches.

video=1024x768 - all connectors match a 1024x768 mode or add a CVT on
video=VGA-1:1024x768, VGA-1 connector gets mode only.

The same strings as used in current fb modedb.c are used, except I've
added three more letters, e, D, d, e = enable, D = enable Digital,
d = disable, which allow a connector to be forced into a certain state.

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


# f066a17d 23-Sep-2009 Adam Jackson <ajax@redhat.com>

drm/edid: Fix standard timing parse for EDID <= 1.2

Aspect ratio code of 0 means 1:1 before EDID 1.3.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 93dc6c2b 23-Sep-2009 Adam Jackson <ajax@redhat.com>

drm/edid: Detailed standard timing blocks have six timings, not five.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 23425cae 23-Sep-2009 Adam Jackson <ajax@redhat.com>

drm/edid: Ignore bad standard timings.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 083ae056 23-Sep-2009 Adam Jackson <ajax@redhat.com>

drm/edid: const cleanup

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 1ecff1eb 07-Sep-2009 Adam Jackson <ajax@redhat.com>

drm: shut the EDID warnings up.

These really aren't all that useful.

taken from Fedora kernel.

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


# f0fda0a4 02-Sep-2009 Zhao Yakui <yakui.zhao@intel.com>

drm/kms: add a function that can add the mode for the output device without EDID

Add a function that can be used to add the default mode for the output device
without EDID.
It will add the default mode that meets with the requirements of given
hdisplay/vdisplay limit.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 559ee21d 02-Sep-2009 Zhao Yakui <yakui.zhao@intel.com>

drm/kms: try to find the std mode in DMT table

When we need to add the standard timing mode, we will firstly check whether it
can be found in DMT table by comparing the hdisplay/vdisplay/vfresh_rate.
If it can't be found, then we will use the cvt/gtf to add the required mode.
If it can be found, it will be returned.

At the same time the function of drm_mode_vrefresh is also fixed. It will
return the result of actual refresh_rate plus 0.5.
For example:
When the calculated value is 84.9, then the fresh_rate is 85.
When the calculated value is 70.02, then the fresh_rate is 70.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# aa9eaa1f 02-Sep-2009 Zhao Yakui <yakui.zhao@intel.com>

drm/kms: Add the default mode table

When we add a standard timing mode in UMS, we will first check whether it can
be found in default mode table. If it can't be found, then we will use cvt/gtf
to add the standard timing mode.
Add the default mode table so that we can check whether the given mode
can be found in the default mode table as what we have done in UMS mode.

If the status of one output device is connected but there is no EDID, it will
have no correct mode. In such case we can add some default modes for it. Of
course we only add the modes in the default modes list that visible part is not
greater than 1024x768.

The default mode is autogenerated from the DMT spec. And it is copied from
xserver/hw/xfree86/modes/xf86EdidModes.c. But the mode with reduced blank
feature is removed.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 882f0219 26-Aug-2009 Zhao Yakui <yakui.zhao@intel.com>

drm/kms: Parse the detailed time info in CEA-EDID

Sometimes we can obtain the EDID with multiple blocks from the display device.
For example: HDMI monitor.
When the CEA-EDID block is detected, we should also parse the detailed timing
info from it. Otherwise we will lose some modes for the display device.

The first step is check whether the CEA EDID block is found. If it exists,
it will skip the CEA-data block and parse the detailed timing info.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# ebb177d2 14-Aug-2009 Dave Airlie <airlied@redhat.com>

drm/edid: fixup detailed timings like the X server.

this syncs the versioning check with the code the X server uses.

Reported-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 5c61259e 21-Jun-2009 Zhao Yakui <yakui.zhao@intel.com>

drm/mode: get the modeline for standard timing in EDID by using CVT/GTF

Create the standard timing modeline by using CVT/GFT algorithm while
interpreting the EDID.

In course of interpreting the EDID, the timing level will be obtained,
which is used to determine whether the CVT/GTF algorithm is selected to
generate the modeline for the given hdisplay/vdisplay/vrefresh_rate.
In the UMS mode firstly it will check whether it can be found in
the DMT table. If it can be found, then the modeline is returned. Then the
timing_level is used to choose CVT/GTF.
As there is no DMT table, no modeline is returned when timing level
is DMT. For the other two timing levels, the CVT/GTF will be called to
generate the required standard timing modeline.

[airlied: fixed up conflicts since EDID rework]

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>


# e14cbee4 22-Jun-2009 Michel Dänzer <michel@daenzer.net>

drm: Fix shifts which were miscalculated when converting from bitfields.

Looks like I managed to mess up most shifts when converting from bitfields. :(

The patch below works on my Thinkpad T500 (as well as on my PowerBook,
where the previous change worked as well, maybe out of luck...). I'd
appreciate more testing and eyes looking over it though.

Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Tested-by: Michael Pyne <mpyne@kde.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>


# 0454beab 15-Jun-2009 Michel Dänzer <daenzer@vmware.com>

drm: EDID endianness fixes.

Mostly replacing bitfields with explicit masks and shifts.

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


# 61f11699 30-May-2009 Keith Packard <keithp@keithp.com>

drm: Eliminate magic I2C frobbing when reading EDID

This code depends on the underlying I2C adapter using the bit-banging algo,
which may not be the case. If specific encoders require this mechanism, they
should build a custom I2C algo that implements this workaround, rather than
having it in the general path.

Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# fc438966 03-Jun-2009 Adam Jackson <ajax@redhat.com>

drm: ignore EDID with really tiny modes.

Some EDIDs lie and report tiny modes that aren't possible. Ignore
these modes.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# b94ee652 02-Apr-2009 Jesse Barnes <jbarnes@virtuousgeek.org>

drm: fix EDID backward compat check

EDIDs should be backward compatible, so don't bail if we see a version
of 3 (which is out there now) and print a message if we see something
newer, but allow it to be parsed.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 16456c87 02-Apr-2009 Dave Airlie <airlied@redhat.com>

drm: fix typo in edid vendor parsing.

Should be,

edid_vendor[2] = (edid->mfg_id[1] & 0x1f) + '@';

Since vendor ID has only two bytes only, I am somewhat surprised why gcc
doesn't complain this.

Reported-by: Guo, Chaohong <chaohong.guo@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# f23c20c8 26-Mar-2009 Ma Ling <ling.ma@intel.com>

drm: detect hdmi monitor by hdmi identifier (v3)

Sometime we need to communicate with HDMI monitor by sending audio or video
info frame, so we have to know monitor type. However if user utilize HDMI-DVI adapter to connect DVI monitor, hardware detection will incorrectly show the monitor is HDMI. HDMI spec tell us that any device containing IEEE registration Identifier will be treated as HDMI device. The patch intends to detect HDMI monitor by this rule.

Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# 167f3a04 20-Mar-2009 Ma Ling <ling.ma@intel.com>

drm: read EDID extensions from monitor

Usually drm read basic EDID, that is enough for us, but since igital display
were introduced i.e. HDMI monitor, sometime we need to interact with monitor by
EDID extension information,

EDID extensions include audio/video data block, speaker allocation and vendor specific data blocks.

This patch intends to read EDID extensions from digital monitor for users.

Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# d61e7380 24-Feb-2009 Kyle McMartin <kyle@redhat.com>

drm: edid revision 0 is valid

edid->revision == 0 should be valid (at least, so the error message
indicates. :) and wikipedia seems to indicate that EDID 1.0 existed.

We can dump the entire check, since edid->revision is a u8, so
it can't ever be less than 0.

Marko reports in RH bz#476735 that his monitor claims to be
EDID 1.0, and therefore hits the check and is stuck at 800x600 because
of it.

Reported-by: Marko Ristola <marko.ristola@kolumbus.fi>
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>


# c8766ac5 23-Feb-2009 Linus Torvalds <torvalds@linux-foundation.org>

drm: Fix shifts of EDID vsync offset/width fields.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>


# 4942f8b2 22-Jan-2009 Jesse Barnes <jbarnes@virtuousgeek.org>

drm: don't whine about not reading EDID data

Make this message a little quieter, since it's common and not necessarily
indicative of a problem.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# f890607b 17-Dec-2008 Dave Airlie <airlied@redhat.com>

drm: fix useless gcc unused variable warning

the calling function doesn't call this function unless one of the two
states that sets the value is true.

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


# f453ba04 07-Nov-2008 Dave Airlie <airlied@redhat.com>

DRM: add mode setting support

Add mode setting support to the DRM layer.

This is a fairly big chunk of work that allows DRM drivers to provide
full output control and configuration capabilities to userspace. It was
motivated by several factors:
- the fb layer's APIs aren't suited for anything but simple
configurations
- coordination between the fb layer, DRM layer, and various userspace
drivers is poor to non-existent (radeonfb excepted)
- user level mode setting drivers makes displaying panic & oops
messages more difficult
- suspend/resume of graphics state is possible in many more
configurations with kernel level support

This commit just adds the core DRM part of the mode setting APIs.
Driver specific commits using these new structure and APIs will follow.

Co-authors: Jesse Barnes <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com>
Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.com>

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>