#
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>
|