- 25 Jan, 2022 7 commits
-
-
Maxime Ripard authored
The CSC callbacks takes a boolean as an argument to tell whether we're using the full range or limited range RGB. However, with the upcoming YUV support, the logic will be a bit more complex. In order to address this, let's make the callbacks take the entire mode, and call our new helper to tell whether the full or limited range RGB should be used. Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-7-maxime@cerno.tech
-
Maxime Ripard authored
We're going to need to tell whether we want to run with a full or limited range RGB output in multiple places in the code, so let's create a helper that will return whether we need with full range or not. Acked-by:
-
Maxime Ripard authored
The HDMI specification mentions YCbCr everywhere, but our enums have YCrCb. Let's rename it to match. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-5-maxime@cerno.tech
-
Maxime Ripard authored
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:
-
Maxime Ripard authored
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: d0c94692 ("drm/edid: Parse and handle HDMI deep color modes.") Signed-off-by:
-
Maxime Ripard authored
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:
-
Daniel Vetter authored
Also add notes that for atomic drivers it's really somewhere else and no longer in struct drm_crtc. Maybe we should put a bigger warning here that this is confusing, since the pixel format is a plane property, but the GAMMA_LUT property is on the crtc. But I think we can fix this if/when someone finds a need for a per-plane CLUT, since I'm not sure such hw even exists. I'm also not sure whether even hardware with a CLUT and a full color correction pipeline with degamm/cgm/gamma exists. Motivated by comments from Geert that we have a gap here. v2: More names for color luts (Laurent). Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124221633.952374-1-daniel.vetter@ffwll.ch
-
- 24 Jan, 2022 6 commits
-
-
Ira Weiny authored
kmap() is being deprecated and these instances are easy to convert to kmap_local_page(). Furthermore, in gma_crtc_cursor_set() use the memcpy_from_page() helper instead of an open coded use of kmap_local_page(). Signed-off-by:
Ira Weiny <ira.weiny@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220124015409.807587-4-ira.weiny@intel.com
-
Jani Nikula authored
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 authored
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 authored
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:
-
Christian König authored
Instead of calling the debug operation directly. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124124430.20859-10-christian.koenig@amd.com
-
Christian König authored
Instead of calling the debug operation directly. Signed-off-by:
-
- 21 Jan, 2022 1 commit
-
-
Thomas Zimmermann authored
DRM's DisplayPort helpers moved into the subdirectory dp/. Change the documentation accordingly. Signed-off-by:
Jani Nikula <jani.nikula@linux.intel.com> Tested-by:
-
- 20 Jan, 2022 1 commit
-
-
Jani Nikula authored
The stack_depot member was added without kernel-doc, leading to below warning. Fix it. ./include/drm/drm_modeset_lock.h:74: warning: Function parameter or member 'stack_depot' not described in 'drm_modeset_acquire_ctx' Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: cd06ab2f ("drm/locking: add backtrace for locking contended locks without backoff") Signed-off-by:
-
- 19 Jan, 2022 20 commits
-
-
Javier Martinez Canillas authored
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
-
Javier Martinez Canillas authored
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by:
-
Javier Martinez Canillas authored
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by:
-
Javier Martinez Canillas authored
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
-
Javier Martinez Canillas authored
Provide a helper macro to register platform DRM drivers. The new macro behaves like module_platform_driver() with an additional test if DRM modesetting has been enabled. Signed-off-by:
-
Thomas Zimmermann authored
Replace module_pci_driver() with drm_module_pci_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by:
-
Thomas Zimmermann authored
Remove custom cirrus_init() and cirrus_exit() functions and initialize the module with DRM module helpers. Signed-off-by:
-
Thomas Zimmermann authored
Remove custom bochs_init() and bochs_exit() functions and initialize the module with DRM module helpers. Signed-off-by:
-
Thomas Zimmermann authored
Remove custom ast_init() and ast_exit() functions and initialize the module with DRM module helpers. Signed-off-by:
-
Thomas Zimmermann authored
Provide helper macros to register PCI-based DRM drivers. The new macros behave like module_pci_driver() with an additional test if DRM modesetting has been enabled. Signed-off-by:
-
José Expósito authored
Avoid leaking the "out" variable if it is not possible to allocate the "txmsg" variable. Fixes: 09234b88 ("drm/selftests/test-drm_dp_mst_helper: Move 'sideband_msg_req_encode_decode' onto the heap") Addresses-Coverity-ID: 1475685 ("Resource leak") Signed-off-by:
José Expósito <jose.exposito89@gmail.com> Signed-off-by:
-
José Expósito authored
The TTM acronym is defined for the first time in the documentation as "Translation Table Maps". Afterwards, "Translation Table Manager" is used as definition. Fix the first definition to avoid confusion. Signed-off-by:
-
KuoHsiang Chou authored
The threshold value is used for AST2600 only. Signed-off-by:
KuoHsiang Chou <kuohsiang_chou@aspeedtech.com> Signed-off-by:
-
Jocelyn Falempe authored
On some servers with MGA G200_SE_A (rev 42), booting with Legacy BIOS, the hardware hangs when using kdump and kexec into the kdump kernel. This happens when the uncompress code tries to write "Decompressing Linux" to the VGA Console. It can be reproduced by writing to the VGA console (0xB8000) after booting to graphic mode, it generates the following error: kernel:NMI: PCI system error (SERR) for reason a0 on CPU 0. kernel:Dazed and confused, but trying to continue The root cause is the configuration of the MGA GCTL6 register According to the GCTL6 register documentation: bit 0 is gcgrmode: 0: Enables alpha mode, and the character generator addressing system is activated. 1: Enables graphics mode, and the character addressing system is not used. bit 1 is chainodd even: 0: The A0 signal of the memory address bus is used during system memory addressing. 1: Allows A0 to be replaced by either the A16 signal of the system address (ifmemmapsl is ‘00’), or by the hpgoddev (MISC<5>, odd/even page select) field, described on page 3-294). bit 3-2 are memmapsl: Memory map select bits 1 and 0. VGA. These bits select where the video memory is mapped, as shown below: 00 => A0000h - BFFFFh 01 => A0000h - AFFFFh 10 => B0000h - B7FFFh 11 => B8000h - BFFFFh bit 7-4 are reserved. Current code set it to 0x05 => memmapsl to b01 => 0xa0000 (graphic mode) But on x86, the VGA console is at 0xb8000 (text mode) In arch/x86/boot/compressed/misc.c debug strings are written to 0xb8000 As the driver doesn't use this mapping at 0xa0000, it is safe to set it to 0xb8000 instead, to avoid kernel hang on G200_SE_A rev42, with kexec/kdump. Thus changing the value 0x05 to 0x0d Signed-off-by:Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Zhiming Liu authored
We have got the device of i2c client in probe function. So we should remove extra device acquisition method of i2c client. Signed-off-by:
Zhiming Liu <lzmlzmhh@gmail.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220117154150.5145-1-lzmlzmhh@gmail.comReviewed-by:
-
Thomas Zimmermann authored
Update the include statements for DisplayPort helpers. The header files are in the dp/ subdirectory. Signed-off-by:
kernel test robot <lkp@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220118154450.25947-1-tzimmermann@suse.de
-
Thomas Zimmermann authored
Resolve warnings about non-existing symbols by selecting DRM_DP_HELPER. Signed-off-by:
-
Christian König authored
Returning the exclusive fence separately is no longer used. Instead add a write parameter to indicate the use case. Signed-off-by:
-
Christian König authored
This was added because of the now dropped shared on excl dependency. Signed-off-by:
-
Arunpravin authored
Move the base i915 buddy allocator code into drm - Move i915_buddy.h to include/drm - Move i915_buddy.c to drm root folder - Rename "i915" string with "drm" string wherever applicable - Rename "I915" string with "DRM" string wherever applicable - Fix header file dependencies - Fix alignment issues - add Makefile support for drm buddy - export functions and write kerneldoc description - Remove i915 selftest config check condition as buddy selftest will be moved to drm selftest folder cleanup i915 buddy references in i915 driver module and replace with drm buddy v2: - include header file in alphabetical order(Thomas) - merged changes listed in the body section into a single patch to keep the build intact(Christian, Jani) v3: - make drm buddy a separate module(Thomas, Christian) v4: - Fix build error reported by kernel test robot <lkp@intel.com> - removed i915 buddy selftest from i915_mock_selftests.h to avoid build error - removed selftests/i915_buddy.c file as we create a new set of buddy test cases in drm/selftests folder v5: - Fix merge conflict issue v6: - replace drm_buddy_mm structure name as drm_buddy(Thomas, Christian) - replace drm_buddy_alloc() function name as drm_buddy_alloc_blocks() (Thomas) - replace drm_buddy_free() function name as drm_buddy_free_block() (Thomas) - export drm_buddy_free_block() function - fix multiple instances of KMEM_CACHE() entry v7: - fix warnings reported by kernel test robot <lkp@intel.com> - modify the license(Christian) v8: - fix warnings reported by kernel test robot <lkp@intel.com> Signed-off-by:Arunpravin <Arunpravin.PaneerSelvam@amd.com> Acked-by:
-
- 18 Jan, 2022 2 commits
-
-
Roberto Sassu authored
If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it happened in the bug report by syzbot), virtio_gpu_array_put_free() could be called with objs equal to NULL. Ensure that objs is not NULL in virtio_gpu_array_put_free(), or otherwise return from the function. Cc: stable@vger.kernel.org # 5.13.x Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Reported-by: syzbot+e9072e90624a31dfa85f@syzkaller.appspotmail.com Fixes: 377f8331 ("drm/virtio: fix possible leak/unlock virtio_gpu_object_array") Link: http://patchwork.freedesktop.org/patch/msgid/20211213183122.838119-1-roberto.sassu@huawei.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Pavel Skripkin authored
Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The problem was in ubuf->pages == ZERO_PTR. ubuf->pagecount is calculated from arguments passed from user-space. If user creates udmabuf with list.size == 0 then ubuf->pagecount will be also equal to zero; it causes kmalloc_array() to return ZERO_PTR. Fix it by validating ubuf->pagecount before passing it to kmalloc_array(). Fixes: fbb0de79 ("Add udmabuf misc device") Reported-and-tested-by: syzbot+2c56b725ec547fa9cb29@syzkaller.appspotmail.com Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20211230142649.23022-1-paskripkin@gmail.comSigned-off-by:
-
- 17 Jan, 2022 3 commits
-
-
owen authored
It will connect to the mipi dsi host and find the corresponding mipi dsi host node, but the node registered by the mipi dsi host has not been loaded yet. of_find_mipi_dsi_host_by_node() returns -EINVAL which causes the calling driver to fail. If the anx7625 driver is loaded afterwards the driver requesting the mipi dsi host will not notice this. Better approach is to return -EPROBE_DEFER in such case. Then when the anx7625 driver appears the driver requesting the mipi dsi host will be probed again. Signed-off-by:
owen <qwt9588@gmail.com> Signed-off-by:
-
Thomas Zimmermann authored
Move drm_dp_aux_bus.c and its header file into the DP subdirectory and update all users. No functional changes. Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220114114535.29157-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
Move all public DisplayPort headers into dp/ and update users. No functional changes. v3: * rebased onto latest drm-tip Signed-off-by:
-
