summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2022-03-02drm/edid: Always set RGB444Maxime Ripard1-1/+1
commit ecbd4912a693b862e25cba0a6990a8c95b00721e upstream. 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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-02drm/i915: Correctly populate use_sagv_wm for all pipesVille Syrjälä1-11/+11
commit afc189df6bcc6be65961deb54e15ec60e7f85337 upstream. When changing between SAGV vs. no SAGV on tgl+ we have to update the use_sagv_wm flag for all the crtcs or else an active pipe not already in the state will end up using the wrong watermarks. That is especially bad when we end up with the tighter non-SAGV watermarks with SAGV enabled. Usually ends up in underruns. Cc: stable@vger.kernel.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 7241c57d3140 ("drm/i915: Add TGL+ SAGV support") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-2-ville.syrjala@linux.intel.com (cherry picked from commit 8dd8ffb824ca7b897ce9f2082ffa7e64831c22dc) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-02drm/amdgpu: disable MMHUB PG for PicassoEvan Quan1-1/+4
commit f626dd0ff05043e5a7154770cc7cda66acee33a3 upstream. MMHUB PG needs to be disabled for Picasso for stability reasons. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23drm/rockchip: dw_hdmi: Do not leave clock enabled in error caseSascha Hauer1-7/+7
[ Upstream commit c0cfbb122275da1b726481de5a8cffeb24e6322b ] The driver returns an error when devm_phy_optional_get() fails leaving the previously enabled clock turned on. Change order and enable the clock only after the phy has been acquired. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220126145549.617165-3-s.hauer@pengutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-23drm/i915/gvt: Make DRM_I915_GVT depend on X86Siva Mullati1-0/+1
commit d72d69abfdb6e0375981cfdda8eb45143f12c77d upstream. GVT is not supported on non-x86 platforms, So add dependency of X86 on config parameter DRM_I915_GVT. Fixes: 0ad35fed618c ("drm/i915: gvt: Introduce the basic architecture of GVT-g") Signed-off-by: Siva Mullati <siva.mullati@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220107095235.243448-1-siva.mullati@intel.com Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23drm/i915/opregion: check port number bounds for SWSCI display power stateJani Nikula1-0/+15
commit ea958422291de248b9e2eaaeea36004e84b64043 upstream. The mapping from enum port to whatever port numbering scheme is used by the SWSCI Display Power State Notification is odd, and the memory of it has faded. In any case, the parameter only has space for ports numbered [0..4], and UBSAN reports bit shift beyond it when the platform has port F or more. Since the SWSCI functionality is supposed to be obsolete for new platforms (i.e. ones that might have port F or more), just bail out early if the mapped and mangled port number is beyond what the Display Power State Notification can support. Fixes: 9c4b0a683193 ("drm/i915: add opregion function to notify bios of encoder enable/disable") Cc: <stable@vger.kernel.org> # v3.13+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4800 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/cc363f42d6b5a5932b6d218fefcc8bdfb15dbbe5.1644489329.git.jani.nikula@intel.com (cherry picked from commit 24a644ebbfd3b13cda702f98907f9dd123e34bf9) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23drm/radeon: Fix backlight control on iMac 12,1Nicholas Bishop1-1/+2
commit 364438fd629f7611a84c8e6d7de91659300f1502 upstream. The iMac 12,1 does not use the gmux driver for backlight, so the radeon backlight device is needed to set the brightness. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1838 Signed-off-by: Nicholas Bishop <nicholasbishop@google.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23drm/amdgpu: fix logic inversion in checkChristian König1-1/+1
[ Upstream commit e8ae38720e1a685fd98cfa5ae118c9d07b45ca79 ] We probably never trigger this, but the logic inside the check is inverted. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-23drm/nouveau/pmu/gm200-: use alternate falcon reset sequenceBen Skeggs6-6/+41
commit 4cdd2450bf739bada353e82d27b00db9af8c3001 upstream. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-16drm/panel: simple: Assign data from panel_dpi_probe() correctlyChristoph Niedermaier1-0/+1
[ Upstream commit 6df4432a5eca101b5fd80fbee41d309f3d67928d ] In the function panel_simple_probe() the pointer panel->desc is assigned to the passed pointer desc. If function panel_dpi_probe() is called panel->desc will be updated, but further on only desc will be evaluated. So update the desc pointer to be able to use the data from the function panel_dpi_probe(). Fixes: 4a1d0dbc8332 ("drm/panel: simple: add panel-dpi support") Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Marek Vasut <marex@denx.de> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> To: dri-devel@lists.freedesktop.org Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220201110153.3479-1-cniedermaier@dh-electronics.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-16drm/vc4: hdmi: Allow DBLCLK modes even if horz timing is odd.Dave Stevenson1-0/+2
[ Upstream commit 1d118965965f89948236ebe23072bb1fca5e7832 ] The 2711 pixel valve can't produce odd horizontal timings, and checks were added to vc4_hdmi_encoder_atomic_check and vc4_hdmi_encoder_mode_valid to filter out/block selection of such modes. Modes with DRM_MODE_FLAG_DBLCLK double all the horizontal timing values before programming them into the PV. The PV values, therefore, can not be odd, and so the modes can be supported. Amend the filtering appropriately. Fixes: 57fb32e632be ("drm/vc4: hdmi: Block odd horizontal timings") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220127135116.298278-1-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-16drm/rockchip: vop: Correct RK3399 VOP register fieldsBrian Norris1-3/+5
commit 9da1e9ab82c92d0e89fe44cad2cd7c2d18d64070 upstream. Commit 7707f7227f09 ("drm/rockchip: Add support for afbc") switched up the rk3399_vop_big[] register windows, but it did so incorrectly. The biggest problem is in rk3288_win23_data[] vs. rk3368_win23_data[] .format field: RK3288's format: VOP_REG(RK3288_WIN2_CTRL0, 0x7, 1) RK3368's format: VOP_REG(RK3368_WIN2_CTRL0, 0x3, 5) Bits 5:6 (i.e., shift 5, mask 0x3) are correct for RK3399, according to the TRM. There are a few other small differences between the 3288 and 3368 definitions that were swapped in commit 7707f7227f09. I reviewed them to the best of my ability according to the RK3399 TRM and fixed them up. This fixes IOMMU issues (and display errors) when testing with BG24 color formats. Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc") Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220119161104.1.I1d01436bef35165a8cdfe9308789c0badb5ff46a@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-16drm: panel-orientation-quirks: Add quirk for the 1Netbook OneXPlayerRaymond Jay Golo1-0/+12
[ Upstream commit d3cbc6e323c9299d10c8d2e4127c77c7d05d07b1 ] The 1Netbook OneXPlayer uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Raymond Jay Golo <rjgolo@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220113000619.90988-1-rjgolo@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-16drm/amdgpu: Set a suitable dev_info.gart_page_sizeHuacai Chen1-2/+2
commit f4d3da72a76a9ce5f57bba64788931686a9dc333 upstream. In Mesa, dev_info.gart_page_size is used for alignment and it was set to AMDGPU_GPU_PAGE_SIZE(4KB). However, the page table of AMDGPU driver requires an alignment on CPU pages. So, for non-4KB page system, gart_page_size should be max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE). Signed-off-by: Rui Wang <wangr@lemote.com> Signed-off-by: Huacai Chen <chenhc@lemote.com> Link: https://github.com/loongson-community/linux-stable/commit/caa9c0a1 [Xi: rebased for drm-next, use max_t for checkpatch, and reworded commit message.] Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549 Tested-by: Dan Horák <dan@danny.cz> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> [Salvatore Bonaccorso: Backport to 5.10.y which does not contain a5a52a43eac0 ("drm/amd/amdgpu/amdgpu_kms: Remove 'struct drm_amdgpu_info_device dev_info' from the stack") which removes dev_info from the stack and places it on the heap.] Tested-by: Timothy Pearson <tpearson@raptorengineering.com> Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08drm/i915/overlay: Prevent divide by zero bugs in scalingDan Carpenter1-0/+3
commit 90a3d22ff02b196d5884e111f39271a1d4ee8e3e upstream. Smatch detected a divide by zero bug in check_overlay_scaling(). drivers/gpu/drm/i915/display/intel_overlay.c:976 check_overlay_scaling() error: potential divide by zero bug '/ rec->dst_height'. drivers/gpu/drm/i915/display/intel_overlay.c:980 check_overlay_scaling() error: potential divide by zero bug '/ rec->dst_width'. Prevent this by ensuring that the dst height and width are non-zero. Fixes: 02e792fbaadb ("drm/i915: implement drmmode overlay support v4") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124122409.GA31673@kili (cherry picked from commit cf5b64f7f10b28bebb9b7c9d25e7aee5cbe43918) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08drm/amd/display: Force link_rate as LINK_RATE_RBR2 for 2018 15" Apple Retina ↵Aun-Ali Zaidi1-0/+20
panels commit 30fbce374745a9c6af93c775a5ac49a97f822fda upstream. The eDP link rate reported by the DP_MAX_LINK_RATE dpcd register (0xa) is contradictory to the highest rate supported reported by EDID (0xc = LINK_RATE_RBR2). The effects of this compounded with commit '4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")' results in no display modes being found and a dark panel. For now, simply force the maximum supported link rate for the eDP attached 2018 15" Apple Retina panels. Additionally, we must also check the firmware revision since the device ID reported by the DPCD is identical to that of the more capable 16,1, incorrectly quirking it. We also use said firmware check to quirk the refreshed 15,1 models with Vega graphics as they use a slightly newer firmware version. Tested-by: Aun-Ali Zaidi <admin@kodeit.net> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net> Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08drm/nouveau: fix off by one in BIOS boundary checkingNick Lopez1-1/+1
commit 1b777d4d9e383d2744fc9b3a09af6ec1893c8b1a upstream. Bounds checking when parsing init scripts embedded in the BIOS reject access to the last byte. This causes driver initialization to fail on Apple eMac's with GeForce 2 MX GPUs, leaving the system with no working console. This is probably only seen on OpenFirmware machines like PowerPC Macs because the BIOS image provided by OF is only the used parts of the ROM, not a power-of-two blocks read from PCI directly so PCs always have empty bytes at the end that are never accessed. Signed-off-by: Nick Lopez <github@glowingmonkey.org> Fixes: 4d4e9907ff572 ("drm/nouveau/bios: guard against out-of-bounds accesses to image") Cc: <stable@vger.kernel.org> # v4.10+ Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220122081906.2633061-1-github@glowingmonkey.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-05Revert "drm/vc4: hdmi: Make sure the device is powered with CEC" againGreg Kroah-Hartman1-9/+1
This reverts commit 55b10b88ac8654fc2f31518aa349a2e643b37f18 which is commit 20b0dfa86bef0e80b41b0e5ac38b92f23b6f27f9 upstream. It wasn't applied correctly, something went wrong with an attempt to fix it up again, so just revert the whole thing to be back at a clean state. Reported-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220205171238.GA3073350@roeck-us.net Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Link: https://lore.kernel.org/r/Yf5lNIJnvhP4ajam@kroah.com Cc: Dave Stevenson <dave.stevenson@raspberrypi.com> Cc: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-05Revert "drm/vc4: hdmi: Make sure the device is powered with CEC"Greg Kroah-Hartman1-13/+12
This reverts commit ac4ba79bb02881ed714adaa89faee601a18bff6d which is commit 20b0dfa86bef0e80b41b0e5ac38b92f23b6f27f9 upstream. It wasn't applied correctly, something went wrong with an attempt to fix it up again, so just revert the whole thing to be back at a clean state. Reported-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220205171238.GA3073350@roeck-us.net Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Link: https://lore.kernel.org/r/Yf5lNIJnvhP4ajam@kroah.com Cc: Dave Stevenson <dave.stevenson@raspberrypi.com> Cc: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-05drm/vc4: hdmi: Make sure the device is powered with CECMaxime Ripard1-12/+13
Commit 20b0dfa86bef0e80b41b0e5ac38b92f23b6f27f9 upstream. The original commit depended on a rework commit (724fc856c09e ("drm/vc4: hdmi: Split the CEC disable / enable functions in two")) that (rightfully) didn't reach stable. However, probably because the context changed, when the patch was applied to stable the pm_runtime_put called got moved to the end of the vc4_hdmi_cec_adap_enable function (that would have become vc4_hdmi_cec_disable with the rework) to vc4_hdmi_cec_init. This means that at probe time, we now drop our reference to the clocks and power domains and thus end up with a CPU hang when the CPU tries to access registers. The call to pm_runtime_resume_and_get() is also problematic since the .adap_enable CEC hook is called both to enable and to disable the controller. That means that we'll now call pm_runtime_resume_and_get() at disable time as well, messing with the reference counting. The behaviour we should have though would be to have pm_runtime_resume_and_get() called when the CEC controller is enabled, and pm_runtime_put when it's disabled. We need to move things around a bit to behave that way, but it aligns stable with upstream. Cc: <stable@vger.kernel.org> # 5.10.x Cc: <stable@vger.kernel.org> # 5.15.x Cc: <stable@vger.kernel.org> # 5.16.x Reported-by: Michael Stapelberg <michael+drm@stapelberg.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-01drm/msm/dpu: invalid parameter check in dpu_setup_dspp_pccJosé Expósito1-2/+9
[ Upstream commit 170b22234d5495f5e0844246e23f004639ee89ba ] The function performs a check on the "ctx" input parameter, however, it is used before the check. Initialize the "base" variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 4259ff7ae509e ("drm/msm/dpu: add support for pcc color block in dpu driver") Addresses-Coverity-ID: 1493866 ("Null pointer dereference") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20220109192431.135949-1-jose.exposito89@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-01drm/msm/hdmi: Fix missing put_device() call in msm_hdmi_get_phyMiaoqian Lin1-1/+6
[ Upstream commit 774fe0cd838d1b1419d41ab4ea0613c80d4ecbd7 ] The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the error handling path. Fixes: e00012b256d4 ("drm/msm/hdmi: Make HDMI core get its PHY") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220107085026.23831-1-linmq006@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-01drm/msm/dsi: invalid parameter check in msm_dsi_phy_enableJosé Expósito1-1/+3
commit 5e761a2287234bc402ba7ef07129f5103bcd775c upstream. The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files") Addresses-Coverity-ID: 1493860 ("Null pointer dereference") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220116181844.7400-1-jose.exposito89@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-01drm/msm/dsi: Fix missing put_device() call in dsi_get_phyMiaoqian Lin1-1/+6
commit c04c3148ca12227d92f91b355b4538cc333c9922 upstream. If of_find_device_by_node() succeeds, dsi_get_phy() doesn't a corresponding put_device(). Thus add put_device() to fix the exception handling. Fixes: ec31abf ("drm/msm/dsi: Separate PHY to another platform device") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211230070943.18116-1-linmq006@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-01drm/msm: Fix wrong size calculationXianting Tian1-1/+1
commit 0a727b459ee39bd4c5ced19d6024258ac87b6b2e upstream. For example, memory-region in .dts as below, reg = <0x0 0x50000000 0x0 0x20000000> We can get below values, struct resource r; r.start = 0x50000000; r.end = 0x6fffffff; So the size should be: size = r.end - r.start + 1 = 0x20000000 Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> Fixes: 072f1f9168ed ("drm/msm: add support for "stolen" mem") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220112123334.749776-1-xianting.tian@linux.alibaba.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-01drm/etnaviv: relax submit size limitsLucas Stach1-2/+2
commit e3d26528e083e612314d4dcd713f3d5a26143ddc upstream. While all userspace tried to limit commandstreams to 64K in size, a bug in the Mesa driver lead to command streams of up to 128K being submitted. Allow those to avoid breaking existing userspace. Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes") Cc: stable@vger.kernel.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-29drm/vmwgfx: Fix stale file descriptors on failed usercopyMathias Krause4-21/+21
commit a0f90c8815706981c483a652a6aefca51a5e191c upstream. A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded. Fixes: c906965dee22 ("drm/vmwgfx: Add export fence to file descriptor support") Signed-off-by: Mathias Krause <minipli@grsecurity.net> Signed-off-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-29drm/i915: Flush TLBs before releasing backing storeTvrtko Ursulin9-4/+155
commit 7938d61591d33394a21bdd7797a245b65428f44c upstream. We need to flush TLBs before releasing backing store otherwise userspace is able to encounter stale entries if a) it is not declaring access to certain buffers and b) it races with the backing store release from a such undeclared execution already executing on the GPU in parallel. The approach taken is to mark any buffer objects which were ever bound to the GPU and to trigger a serialized TLB flush when their backing store is released. Alternatively the flushing could be done on VMA unbind, at which point we would be able to ascertain whether there is potential a parallel GPU execution (which could race), but essentially it boils down to paying the cost of TLB flushes potentially needlessly at VMA unbind time (when the backing store is not known to be going away so not needed for safety), versus potentially needlessly at backing store relase time (since we at that point cannot tell whether there is anything executing on the GPU which uses that object). Thereforce simplicity of implementation has been chosen for now with scope to benchmark and refine later as required. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27drm/vc4: hdmi: Make sure the device is powered with CECMaxime Ripard1-1/+9
commit 20b0dfa86bef0e80b41b0e5ac38b92f23b6f27f9 upstream. Similarly to what we encountered with the detect hook with DRM, nothing actually prevents any of the CEC callback from being run while the HDMI output is disabled. However, this is an issue since any register access to the controller when it's powered down will result in a silent hang. Let's make sure we run the runtime_pm hooks when the CEC adapter is opened and closed by the userspace to avoid that issue. Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support") Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210819135931.895976-6-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27drm/radeon: fix error handling in radeon_driver_open_kmsChristian König1-10/+12
commit 4722f463896cc0ef1a6f1c3cb2e171e949831249 upstream. The return value was never initialized so the cleanup code executed when it isn't even necessary. Just add proper error handling. Fixes: ab50cb9df889 ("drm/radeon/radeon_kms: Fix a NULL pointer dereference in radeon_driver_open_kms()") Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Jan Stancek <jstancek@redhat.com> Tested-by: Borislav Petkov <bp@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27drm/bridge: analogix_dp: Make PSR-exit block lessBrian Norris1-2/+12
commit c4c6ef229593366ab593d4d424addc7025b54a76 upstream. Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"), "PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor started using the blocking variant, for a variety of reasons -- quoting Sean Paul's potentially-faulty memory: """ - To avoid racing a subsequent PSR entry (if exit takes a long time) - To avoid racing disable/modeset - We're not displaying new content while exiting PSR anyways, so there is minimal utility in allowing frames to be submitted - We're lying to userspace telling them frames are on the screen when we're just dropping them on the floor """ However, I'm finding that this blocking transition is causing upwards of 60+ ms of unneeded latency on PSR-exit, to the point that initial cursor movements when leaving PSR are unbearably jumpy. It turns out that we need to meet in the middle somewhere: Sean is right that we were "lying to userspace" with a non-blocking PSR-exit, but the new blocking behavior is also waiting too long: According to the eDP specification, the sink device must support PSR entry transitions from both state 4 (ACTIVE_RESYNC) and state 0 (INACTIVE). It also states that in ACTIVE_RESYNC, "the Sink device must display the incoming active frames from the Source device with no visible glitches and/or artifacts." Thus, for our purposes, we only need to wait for ACTIVE_RESYNC before moving on; we are ready to display video, and subsequent PSR-entry is safe. Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin), where this saves about 60ms of latency, for PSR-exit that used to take about 80ms. Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR") Cc: <stable@vger.kernel.org> Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211103135112.v3.1.I67612ea073c3306c71b46a87be894f79707082df@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27drm/nouveau/kms/nv04: use vzalloc for nv04_displayIlia Mirkin1-2/+2
commit bd6e07e72f37f34535bec7eebc807e5fcfe37b43 upstream. The struct is giant, and triggers an order-7 allocation (512K). There is no reason for this to be kmalloc-type memory, so switch to vmalloc. This should help loading nouveau on low-memory and/or long-running systems. Reported-by: Nathan E. Egge <unlord@xiph.org> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27drm/etnaviv: limit submit sizesLucas Stach1-0/+6
commit 6dfa2fab8ddd46faa771a102672176bee7a065de upstream. Currently we allow rediculous amounts of kernel memory being allocated via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put some reasonable limits in to fix this. The commandstream size is limited to 64KB, which was already a soft limit on older kernels after which the kernel only took submits on a best effort base, so there is no userspace that tries to submit commandstreams larger than this. Even if the whole commandstream is a single incrementing address load, the size limit also limits the number of potential relocs and referenced buffers to slightly under 64K, so use the same limit for those arguments. The performance monitoring infrastructure currently supports less than 50 performance counter signals, so limiting them to 128 on a single submit seems like a reasonably future-proof number for now. This number can be bumped if needed without breaking the interface. Cc: stable@vger.kernel.org Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27phy: mediatek: Fix missing check in mtk_mipi_tx_probeMiaoqian Lin1-0/+2
[ Upstream commit 399c91c3f30531593e5ff6ca7b53f47092128669 ] The of_device_get_match_data() function may return NULL. Add check to prevent potential null dereference. Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20211224082103.7658-1-linmq006@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27amdgpu/pm: Make sysfs pm attributes as read-only for VFsMarina Nikolic1-0/+6
[ Upstream commit 11c9cc95f818f0f187e9b579a7f136f532b42445 ] == Description == Setting values of pm attributes through sysfs should not be allowed in SRIOV mode. These calls will not be processed by FW anyway, but error handling on sysfs level should be improved. == Changes == This patch prohibits performing of all set commands in SRIOV mode on sysfs level. It offers better error handling as calls that are not allowed will not be propagated further. == Test == Writing to any sysfs file in passthrough mode will succeed. Writing to any sysfs file in ONEVF mode will yield error: "calling process does not have sufficient permission to execute a command". Signed-off-by: Marina Nikolic <Marina.Nikolic@amd.com> Acked-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27drm/amdgpu: fixup bad vram size on gmc v8Zongmin Zhou1-3/+10
[ Upstream commit 11544d77e3974924c5a9c8a8320b996a3e9b2f8b ] Some boards(like RX550) seem to have garbage in the upper 16 bits of the vram size register. Check for this and clamp the size properly. Fixes boards reporting bogus amounts of vram. after add this patch,the maximum GPU VRAM size is 64GB, otherwise only 64GB vram size will be used. Signed-off-by: Zongmin Zhou<zhouzongmin@kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27drm/etnaviv: consider completed fence seqno in hang checkLucas Stach2-1/+4
[ Upstream commit cdd156955f946beaa5f3a00d8ccf90e5a197becc ] Some GPU heavy test programs manage to trigger the hangcheck quite often. If there are no other GPU users in the system and the test program exhibits a very regular structure in the commandstreams that are being submitted, we can end up with two distinct submits managing to trigger the hangcheck with the FE in a very similar address range. This leads the hangcheck to believe that the GPU is stuck, while in reality the GPU is already busy working on a different job. To avoid those spurious GPU resets, also remember and consider the last completed fence seqno in the hang check. Reported-by: Joerg Albert <joerg.albert@iav.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27drm: rcar-du: Fix CRTC timings when CMM is usedLaurent Pinchart1-4/+16
[ Upstream commit f0ce591dc9a97067c6e783a2eaccd22c5476144d ] When the CMM is enabled, an offset of 25 pixels must be subtracted from the HDS (horizontal display start) and HDE (horizontal display end) registers. Fix the timings calculation, and take this into account in the mode validation. This fixes a visible horizontal offset in the image with VGA monitors. HDMI monitors seem to be generally more tolerant to incorrect timings, but may be affected too. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27drm/bridge: megachips: Ensure both bridges are probed before registrationMartyn Welch1-12/+28
[ Upstream commit 11632d4aa2b3f126790e81a4415d6c23103cf8bb ] In the configuration used by the b850v3, the STDP2690 is used to read EDID data whilst it's the STDP4028 which can detect when monitors are connected. This can result in problems at boot with monitors connected when the STDP4028 is probed first, a monitor is detected and an attempt is made to read the EDID data before the STDP2690 has probed: [ 3.795721] Unable to handle kernel NULL pointer dereference at virtual address 00000018 [ 3.803845] pgd = (ptrval) [ 3.806581] [00000018] *pgd=00000000 [ 3.810180] Internal error: Oops: 5 [#1] SMP ARM [ 3.814813] Modules linked in: [ 3.817879] CPU: 0 PID: 64 Comm: kworker/u4:1 Not tainted 5.15.0 #1 [ 3.824161] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 3.830705] Workqueue: events_unbound deferred_probe_work_func [ 3.836565] PC is at stdp2690_get_edid+0x44/0x19c [ 3.841286] LR is at ge_b850v3_lvds_get_modes+0x2c/0x5c [ 3.846526] pc : [<805eae10>] lr : [<805eb138>] psr: 80000013 [ 3.852802] sp : 81c359d0 ip : 7dbb550b fp : 81c35a1c [ 3.858037] r10: 81c73840 r9 : 81c73894 r8 : 816d9800 [ 3.863270] r7 : 00000000 r6 : 81c34000 r5 : 00000000 r4 : 810c35f0 [ 3.869808] r3 : 80e3e294 r2 : 00000080 r1 : 00000cc0 r0 : 81401180 [ 3.876349] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 3.883499] Control: 10c5387d Table: 1000404a DAC: 00000051 [ 3.889254] Register r0 information: slab kmem_cache start 81401180 pointer offset 0 [ 3.897034] Register r1 information: non-paged memory [ 3.902097] Register r2 information: non-paged memory [ 3.907160] Register r3 information: non-slab/vmalloc memory [ 3.912832] Register r4 information: non-slab/vmalloc memory [ 3.918503] Register r5 information: NULL pointer [ 3.923217] Register r6 information: non-slab/vmalloc memory [ 3.928887] Register r7 information: NULL pointer [ 3.933601] Register r8 information: slab kmalloc-1k start 816d9800 pointer offset 0 size 1024 [ 3.942244] Register r9 information: slab kmalloc-2k start 81c73800 pointer offset 148 size 2048 [ 3.951058] Register r10 information: slab kmalloc-2k start 81c73800 pointer offset 64 size 2048 [ 3.959873] Register r11 information: non-slab/vmalloc memory [ 3.965632] Register r12 information: non-paged memory [ 3.970781] Process kworker/u4:1 (pid: 64, stack limit = 0x(ptrval)) [ 3.977148] Stack: (0x81c359d0 to 0x81c36000) [ 3.981517] 59c0: 80b2b668 80b2b5bc 000002e2 0000034e [ 3.989712] 59e0: 81c35a8c 816d98e8 81c35a14 7dbb550b 805bfcd0 810c35f0 81c73840 824addc0 [ 3.997906] 5a00: 00001000 816d9800 81c73894 81c73840 81c35a34 81c35a20 805eb138 805eadd8 [ 4.006099] 5a20: 810c35f0 00000045 81c35adc 81c35a38 80594188 805eb118 80d7c788 80dd1848 [ 4.014292] 5a40: 00000000 81c35a50 80dca950 811194d3 80dca7c4 80dca944 80dca91c 816d9800 [ 4.022485] 5a60: 81c34000 81c760a8 816d9800 80c58c98 810c35f0 816d98e8 00001000 00001000 [ 4.030678] 5a80: 00000000 00000000 8017712c 81c60000 00000002 00000001 00000000 00000000 [ 4.038870] 5aa0: 816d9900 816d9900 00000000 7dbb550b 805c700c 00000008 826282c8 826282c8 [ 4.047062] 5ac0: 00001000 81e1ce40 00001000 00000002 81c35bf4 81c35ae0 805d9694 80593fc0 [ 4.055255] 5ae0: 8017a970 80179ad8 00000179 00000000 81c35bcc 81c35b00 80177108 8017a950 [ 4.063447] 5b00: 00000000 81c35b10 81c34000 00000000 81004fd8 81010a38 00000000 00000059 [ 4.071639] 5b20: 816d98d4 81fbb718 00000013 826282c8 8017a940 81c35b40 81134448 00000400 [ 4.079831] 5b40: 00000178 00000000 e063b9c1 00000000 c2000049 00000040 00000000 00000008 [ 4.088024] 5b60: 82628300 82628380 00000000 00000000 81c34000 00000000 81fbb700 82628340 [ 4.096216] 5b80: 826283c0 00001000 00000000 00000010 816d9800 826282c0 801766f8 00000000 [ 4.104408] 5ba0: 00000000 81004fd8 00000049 00000000 00000000 00000001 80dcf940 80178de4 [ 4.112601] 5bc0: 81c35c0c 7dbb550b 80178de4 81fbb700 00000010 00000010 810c35f4 81e1ce40 [ 4.120793] 5be0: 81c40908 0000000c 81c35c64 81c35bf8 805a7f18 805d94a0 81c35c3c 816d9800 [ 4.128985] 5c00: 00000010 81c34000 81c35c2c 81c35c18 8012fce0 805be90c 81c35c3c 81c35c28 [ 4.137178] 5c20: 805be90c 80173210 81fbb600 81fbb6b4 81c35c5c 7dbb550b 81c35c64 81fbb700 [ 4.145370] 5c40: 816d9800 00000010 810c35f4 81e1ce40 81c40908 0000000c 81c35c84 81c35c68 [ 4.153565] 5c60: 805a8c78 805a7ed0 816d9800 81fbb700 00000010 00000000 81c35cac 81c35c88 [ 4.161758] 5c80: 805a8dc4 805a8b68 816d9800 00000000 816d9800 00000000 8179f810 810c42d0 [ 4.169950] 5ca0: 81c35ccc 81c35cb0 805e47b0 805a8d18 824aa240 81e1ea80 81c40908 81126b60 [ 4.178144] 5cc0: 81c35d14 81c35cd0 8060db1c 805e46cc 81c35d14 81c35ce0 80dd90f8 810c4d58 [ 4.186338] 5ce0: 80dd90dc 81fe9740 fffffffe 81fe9740 81e1ea80 00000000 810c4d6c 80c4b95c [ 4.194531] 5d00: 80dd9a3c 815c6810 81c35d34 81c35d18 8060dc9c 8060d8fc 8246b440 815c6800 [ 4.202724] 5d20: 815c6810 eefd8e00 81c35d44 81c35d38 8060dd80 8060dbec 81c35d6c 81c35d48 [ 4.210918] 5d40: 805e98a4 8060dd70 00000000 815c6810 810c45b0 81126e90 81126e90 80dd9a3c [ 4.219112] 5d60: 81c35d8c 81c35d70 80619574 805e9808 815c6810 00000000 810c45b0 81126e90 [ 4.227305] 5d80: 81c35db4 81c35d90 806168dc 80619514 80625df0 80623c80 815c6810 810c45b0 [ 4.235498] 5da0: 81c35e6c 815c6810 81c35dec 81c35db8 80616d04 80616800 81c35de4 81c35dc8 [ 4.243691] 5dc0: 808382b0 80b2f444 8116e310 8116e314 81c35e6c 815c6810 00000003 80dd9a3c [ 4.251884] 5de0: 81c35e14 81c35df0 80616ec8 80616c60 00000001 810c45b0 81c35e6c 815c6810 [ 4.260076] 5e00: 00000001 80dd9a3c 81c35e34 81c35e18 80617338 80616e90 00000000 81c35e6c [ 4.268269] 5e20: 80617284 81c34000 81c35e64 81c35e38 80614730 80617290 81c35e64 8171a06c [ 4.276461] 5e40: 81e220b8 7dbb550b 815c6810 81c34000 815c6854 81126e90 81c35e9c 81c35e68 [ 4.284654] 5e60: 8061673c 806146a8 8060f5e0 815c6810 00000001 7dbb550b 00000000 810c5080 [ 4.292847] 5e80: 810c5320 815c6810 81126e90 00000000 81c35eac 81c35ea0 80617554 80616650 [ 4.301040] 5ea0: 81c35ecc 81c35eb0 80615694 80617544 810c5080 810c5080 810c5094 81126e90 [ 4.309233] 5ec0: 81c35efc 81c35ed0 80615c6c 8061560c 80615bc0 810c50c0 817eeb00 81412800 [ 4.317425] 5ee0: 814c3000 00000000 814c300d 81119a60 81c35f3c 81c35f00 80141488 80615bcc [ 4.325618] 5f00: 81c60000 81c34000 81c35f24 81c35f18 80143078 817eeb00 81412800 817eeb18 [ 4.333811] 5f20: 81412818 81003d00 00000088 81412800 81c35f74 81c35f40 80141a48 80141298 [ 4.342005] 5f40: 81c35f74 81c34000 801481ac 817efa40 817efc00 801417d8 817eeb00 00000000 [ 4.350199] 5f60: 815a7e7c 81c34000 81c35fac 81c35f78 80149b1c 801417e4 817efc20 817efc20 [ 4.358391] 5f80: ffffe000 817efa40 801499a8 00000000 00000000 00000000 00000000 00000000 [ 4.366583] 5fa0: 00000000 81c35fb0 80100130 801499b4 00000000 00000000 00000000 00000000 [ 4.374774] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.382966] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.391155] Backtrace: [ 4.393613] [<805eadcc>] (stdp2690_get_edid) from [<805eb138>] (ge_b850v3_lvds_get_modes+0x2c/0x5c) [ 4.402691] r10:81c73840 r9:81c73894 r8:816d9800 r7:00001000 r6:824addc0 r5:81c73840 [ 4.410534] r4:810c35f0 [ 4.413073] [<805eb10c>] (ge_b850v3_lvds_get_modes) from [<80594188>] (drm_helper_probe_single_connector_modes+0x1d4/0x84c) [ 4.424240] r5:00000045 r4:810c35f0 [ 4.427822] [<80593fb4>] (drm_helper_probe_single_connector_modes) from [<805d9694>] (drm_client_modeset_probe+0x200/0x1384) [ 4.439074] r10:00000002 r9:00001000 r8:81e1ce40 r7:00001000 r6:826282c8 r5:826282c8 [ 4.446917] r4:00000008 [ 4.449455] [<805d9494>] (drm_client_modeset_probe) from [<805a7f18>] (__drm_fb_helper_initial_config_and_unlock+0x54/0x5b4) [ 4.460713] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:00000010 [ 4.468556] r4:81fbb700 [ 4.471095] [<805a7ec4>] (__drm_fb_helper_initial_config_and_unlock) from [<805a8c78>] (drm_fbdev_client_hotplug+0x11c/0x1b0) [ 4.482434] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:816d9800 [ 4.490276] r4:81fbb700 [ 4.492814] [<805a8b5c>] (drm_fbdev_client_hotplug) from [<805a8dc4>] (drm_fbdev_generic_setup+0xb8/0x1a4) [ 4.502494] r7:00000000 r6:00000010 r5:81fbb700 r4:816d9800 [ 4.508160] [<805a8d0c>] (drm_fbdev_generic_setup) from [<805e47b0>] (imx_drm_bind+0xf0/0x130) [ 4.516805] r7:810c42d0 r6:8179f810 r5:00000000 r4:816d9800 [ 4.522474] [<805e46c0>] (imx_drm_bind) from [<8060db1c>] (try_to_bring_up_master+0x22c/0x2f0) [ 4.531116] r7:81126b60 r6:81c40908 r5:81e1ea80 r4:824aa240 [ 4.536783] [<8060d8f0>] (try_to_bring_up_master) from [<8060dc9c>] (__component_add+0xbc/0x184) [ 4.545597] r10:815c6810 r9:80dd9a3c r8:80c4b95c r7:810c4d6c r6:00000000 r5:81e1ea80 [ 4.553440] r4:81fe9740 [ 4.555980] [<8060dbe0>] (__component_add) from [<8060dd80>] (component_add+0x1c/0x20) [ 4.563921] r7:eefd8e00 r6:815c6810 r5:815c6800 r4:8246b440 [ 4.569589] [<8060dd64>] (component_add) from [<805e98a4>] (dw_hdmi_imx_probe+0xa8/0xe8) [ 4.577702] [<805e97fc>] (dw_hdmi_imx_probe) from [<80619574>] (platform_probe+0x6c/0xc8) [ 4.585908] r9:80dd9a3c r8:81126e90 r7:81126e90 r6:810c45b0 r5:815c6810 r4:00000000 [ 4.593662] [<80619508>] (platform_probe) from [<806168dc>] (really_probe+0xe8/0x460) [ 4.601524] r7:81126e90 r6:810c45b0 r5:00000000