dri-devel March 2021

dri-devel@lists.freedesktop.org

326 participants
867 discussions

[PATCH v7 0/8] Add support for SVM atomics in Nouveau
by Alistair Popple 01 Apr '21

01 Apr '21

This is the seventh version of a series to add support to Nouveau for atomic memory operations on OpenCL shared virtual memory (SVM) regions. This version primarily improves readability of the Nouveau fault priority calculation code along with other minor functional and cosmetic improvements listed in the changelogs. Exclusive device access is implemented by adding a new swap entry type (SWAP_DEVICE_EXCLUSIVE) which is similar to a migration entry. The main difference is that on fault the original entry is immediately restored by the fault handler instead of waiting. Restoring the entry triggers calls to MMU notifers which allows a device driver to revoke the atomic access permission from the GPU prior to the CPU finalising the entry. Patches 1 & 2 refactor existing migration and device private entry functions. Patches 3 & 4 rework try_to_unmap_one() by splitting out unrelated functionality into separate functions - try_to_migrate_one() and try_to_munlock_one(). These should not change any functionality, but any help testing would be much appreciated as I have not been able to test every usage of try_to_unmap_one(). Patch 5 contains the bulk of the implementation for device exclusive memory. Patch 6 contains some additions to the HMM selftests to ensure everything works as expected. Patch 7 is a cleanup for the Nouveau SVM implementation. Patch 8 contains the implementation of atomic access for the Nouveau driver. This has been tested using the latest upstream Mesa userspace with a simple OpenCL test program which checks the results of atomic GPU operations on a SVM buffer whilst also writing to the same buffer from the CPU. Alistair Popple (8): mm: Remove special swap entry functions mm/swapops: Rework swap entry manipulation code mm/rmap: Split try_to_munlock from try_to_unmap mm/rmap: Split migration into its own function mm: Device exclusive memory access mm: Selftests for exclusive device memory nouveau/svm: Refactor nouveau_range_fault nouveau/svm: Implement atomic SVM access Documentation/vm/hmm.rst | 19 +- arch/s390/mm/pgtable.c | 2 +- drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + drivers/gpu/drm/nouveau/nouveau_svm.c | 156 ++++- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 6 + fs/proc/task_mmu.c | 23 +- include/linux/mmu_notifier.h | 26 +- include/linux/rmap.h | 9 +- include/linux/swap.h | 8 +- include/linux/swapops.h | 123 ++-- lib/test_hmm.c | 126 +++- lib/test_hmm_uapi.h | 2 + mm/debug_vm_pgtable.c | 12 +- mm/hmm.c | 12 +- mm/huge_memory.c | 45 +- mm/hugetlb.c | 10 +- mm/memcontrol.c | 2 +- mm/memory.c | 128 +++- mm/migrate.c | 51 +- mm/mprotect.c | 18 +- mm/page_vma_mapped.c | 15 +- mm/rmap.c | 604 +++++++++++++++--- tools/testing/selftests/vm/hmm-tests.c | 158 +++++ 24 files changed, 1282 insertions(+), 275 deletions(-) -- 2.20.1

4 30

[PATCH] drm/msm: a6xx: fix version check for the A650 SQE microcode
by Dmitry Baryshkov 01 Apr '21

01 Apr '21

I suppose the microcode version check for a650 is incorrect. It checks for the version 1.95, while the firmware released have major version of 0: 0.91 (vulnerable), 0.99 (fixing the issue). Lower version requirements to accept firmware 0.99. Fixes: 8490f02a3ca4 ("drm/msm: a6xx: Make sure the SQE microcode is safe") Cc: Akhil P Oommen <akhilpo(a)codeaurora.org> Cc: Jordan Crouse <jcrouse(a)codeaurora.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index cb2df8736ca8..896b47dc9c85 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -567,17 +567,17 @@ static bool a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu, } else { /* * a650 tier targets don't need whereami but still need to be - * equal to or newer than 1.95 for other security fixes + * equal to or newer than 0.95 for other security fixes */ if (adreno_is_a650(adreno_gpu)) { - if ((buf[0] & 0xfff) >= 0x195) { + if ((buf[0] & 0xfff) >= 0x095) { ret = true; goto out; } DRM_DEV_ERROR(&gpu->pdev->dev, "a650 SQE ucode is too old. Have version %x need at least %x\n", - buf[0] & 0xfff, 0x195); + buf[0] & 0xfff, 0x095); } /* -- 2.30.2

3 2

[PATCH 0/4] drm/msm: Shrinker (and related) fixes
by Rob Clark 01 Apr '21

01 Apr '21

From: Rob Clark <robdclark(a)chromium.org> I've been spending some time looking into how things behave under high memory pressure. The first patch is a random cleanup I noticed along the way. The second improves the situation significantly when we are getting shrinker called from many threads in parallel. And the last two are $debugfs/gem fixes I needed so I could monitor the state of GEM objects (ie. how many are active/purgable/purged) while triggering high memory pressure. We could probably go a bit further with dropping the mm_lock in the shrinker->scan() loop, but this is already a pretty big improvement. The next step is probably actually to add support to unpin/evict inactive objects. (We are part way there since we have already de- coupled the iova lifetime from the pages lifetime, but there are a few sharp corners to work through.) Rob Clark (4): drm/msm: Remove unused freed llist node drm/msm: Avoid mutex in shrinker_count() drm/msm: Fix debugfs deadlock drm/msm: Improved debugfs gem stats drivers/gpu/drm/msm/msm_debugfs.c | 14 ++---- drivers/gpu/drm/msm/msm_drv.c | 4 ++ drivers/gpu/drm/msm/msm_drv.h | 10 ++++- drivers/gpu/drm/msm/msm_fb.c | 3 +- drivers/gpu/drm/msm/msm_gem.c | 61 +++++++++++++++++++++----- drivers/gpu/drm/msm/msm_gem.h | 58 +++++++++++++++++++++--- drivers/gpu/drm/msm/msm_gem_shrinker.c | 17 +------ 7 files changed, 122 insertions(+), 45 deletions(-) -- 2.30.2

2 22

[PATCH v4 0/2] add support for Waveshare 2inch LCD module
by Carlis 01 Apr '21

01 Apr '21

From: Xuezhi Zhang <zhangxuezhi1(a)yulong.com> This patch add support for Waveshare 2inch LCD module. Xuezhi Zhang (2): drm/tiny: add support for Waveshare 2inch LCD module dt-bindings: display: sitronix,st7789v-dbi: Add Waveshare 2inch LCD module .../display/sitronix,st7789v-dbi.yaml | 72 +++++ MAINTAINERS | 7 + drivers/gpu/drm/tiny/Kconfig | 14 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/st7789v.c | 269 ++++++++++++++++++ 5 files changed, 363 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/sitronix,st7789v-dbi.yaml create mode 100644 drivers/gpu/drm/tiny/st7789v.c -- 2.25.1

2 3

[PATCH v7 00/14] Add some DRM bridge drivers support for i.MX8qm/qxp SoCs
by Liu Ying 01 Apr '21

01 Apr '21

Hi, This is the v7 series to add some DRM bridge drivers support for i.MX8qm/qxp SoCs. The bridges may chain one by one to form display pipes to support LVDS displays. The relevant display controller is DPU embedded in i.MX8qm/qxp SoCs. The DPU KMS driver can be found at: https://www.spinics.net/lists/devicetree/msg414766.html This series supports the following display pipes: 1) i.MX8qxp: prefetch eng -> DPU -> pixel combiner -> pixel link -> pixel link to DPI(PXL2DPI) -> LVDS display bridge(LDB) 2) i.MX8qm: prefetch eng -> DPU -> pixel combiner -> pixel link -> LVDS display bridge(LDB) This series dropped the patch 'phy: Add LVDS configuration options', as suggested by Robert Foss, because it has already been sent with the following series to add Mixel combo PHY found in i.MX8qxp: https://www.spinics.net/lists/devicetree/msg414149.html So, this version depends on that series. Patch 1/14 and 2/14 add bus formats used by pixel combiner. Patch 7/14 adds dt-binding for Control and Status Registers module(a syscon used by PXL2DPI and LDB), which references the PXL2DPI and LDB schemas. Patch 10/14 adds a helper for LDB bridge drivers. Patch 3/14 ~ 6/14, 8/14, 9/14 and 11/14 ~ 13/14 add drm bridge drivers and dt-bindings support for the bridges. Patch 14/14 updates MAINTAINERS. I've tested this series with a koe,tx26d202vm0bwa dual link LVDS panel and a LVDS to HDMI bridge(with a downstream drm bridge driver). Marcel Ziswiler has tested v6 with two LVDS panels(single link LT170410-2WHC and dual link LP156WF1) on Toradex Colibri iMX8X. Welcome comments, thanks. v6->v7: * Fix complaints from 'checkpatch.pl --strict' on the LDB DRM bridge helper driver(patch 10/14) and some DRM bridge drivers(patch 9/14, 12/14 and 13/14). (Robert) * Fix complaints from 'checkpatch --strict' on the rest DRM bridge drivers(patch 4/14 and 6/14). * A trivial indentation fix for patch 9/14. (Robert) * Add Robert's R-b tags on patch 9/14, 10/14, 12/14, 13/14 and 14/14. * Add Marcel's T-b tags on all DRM bridge drivers. * Add Rob's R-b tag on patch 7/14 for CSR module dt-binding. v5->v6: * Fix data organizations in documentation(patch 2/14) for MEDIA_BUS_FMT_RGB{666,888}_1X30-CPADLO. (Laurent) * Add Laurent's R-b tags on patch 1/14 and 2/14. * Drop 'select' schema from the CSR dt-binding documentation(patch 7/14). (Rob) * Add Rob's R-b tag on patch 8/14. v4->v5: * Drop the patch 'phy: Add LVDS configuration options'. (Robert) * Add Robert's R-b tags on patch 1/14, 2/14, 4/14 and 6/14. * Drop the 'PC_BUF_PARA_REG' register definition from the pixel combiner bridge driver(patch 4/14). (Robert) * Make a comment occupy a line in the pixel link bridge driver(patch 6/14). (Robert) * Introduce a new patch(patch 7/14) to add dt-binding for Control and Status Registers module. (Rob) * Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge driver and i.MX8qm LDB bridge driver, instead of a module. Correspondingly, rename 'imx8{qm, qxp}-ldb.c' to 'imx8{qm, qxp}-ldb-drv.c'. (Robert) * Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'. (Robert) * s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/ for 'imx-ldb-helper.h'. v3->v4: * Use 'fsl,sc-resource' DT property to get the SCU resource ID associated with the PXL2DPI instance instead of using alias ID. (Rob) * Add Rob's R-b tag on patch 11/14. v2->v3: * Drop 'fsl,syscon' DT properties from fsl,imx8qxp-ldb.yaml and fsl,imx8qxp-pxl2dpi.yaml. (Rob) * Mention the CSR module controls LDB and PXL2DPI in fsl,imx8qxp-ldb.yaml and fsl,imx8qxp-pxl2dpi.yaml. * Call syscon_node_to_regmap() to get regmaps from LDB bridge helper driver and PXL2DPI bridger driver instead of syscon_regmap_lookup_by_phandle(). * Drop two macros from pixel link bridge driver which help define functions and define them directly. * Properly disable all pixel link controls to POR value by calling imx8qxp_pixel_link_disable_all_controls() from imx8qxp_pixel_link_bridge_probe(). * Add Rob's R-b tags on patch 4/14 and 6/14. v1->v2: * Rebase the series upon the latest drm-misc-next branch(5.11-rc2 based). * Use graph schema in the dt-bindings of the bridges. (Laurent) * Require all four pixel link output ports in fsl,imx8qxp-pixel-link.yaml. (Laurent) * Side note i.MX8qm/qxp LDB official name 'pixel mapper' in fsl,imx8qxp-ldb.yaml. (Laurent) * Mention pixel link is accessed via SCU firmware in fsl,imx8qxp-pixel-link.yaml. (Rob) * Use enum instead of oneOf + const for the reg property of pixel combiner channels in fsl,imx8qxp-pixel-combiner.yaml. (Rob) * Rewrite the function to find the next bridge in pixel link bridge driver by properly using OF APIs and dropping unnecessary DT validation. (Rob) * Drop unnecessary port availability check in i.MX8qxp pixel link to DPI bridge driver. * Drop unnecessary DT validation from i.MX8qxp LDB bridge driver. * Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to get the input remote endpoint in imx8qxp_ldb_set_di_id() of i.MX8qxp LDB bridge driver. * Avoid using companion_port OF node after putting it in imx8qxp_ldb_parse_dt_companion() of i.MX8qxp LDB bridge driver. * Drop unnecessary check for maximum available LDB channels from i.MX8qm LDB bridge driver. * Mention i.MX8qm/qxp LDB official name 'pixel mapper' in i.MX8qm/qxp LDB bridge drivers and Kconfig help messages. Liu Ying (14): media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link binding drm/bridge: imx: Add i.MX8qm/qxp display pixel link support dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding drm/bridge: imx: Add i.MX8qxp pixel link to DPI support drm/bridge: imx: Add LDB driver helper support dt-bindings: display: bridge: Add i.MX8qm/qxp LVDS display bridge binding drm/bridge: imx: Add LDB support for i.MX8qxp drm/bridge: imx: Add LDB support for i.MX8qm MAINTAINERS: add maintainer for DRM bridge drivers for i.MX SoCs .../bindings/display/bridge/fsl,imx8qxp-ldb.yaml | 173 +++++ .../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 144 ++++ .../display/bridge/fsl,imx8qxp-pixel-link.yaml | 106 +++ .../display/bridge/fsl,imx8qxp-pxl2dpi.yaml | 108 +++ .../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml | 192 ++++++ .../userspace-api/media/v4l/subdev-formats.rst | 156 +++++ MAINTAINERS | 10 + drivers/gpu/drm/bridge/Kconfig | 2 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/imx/Kconfig | 42 ++ drivers/gpu/drm/bridge/imx/Makefile | 9 + drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 232 +++++++ drivers/gpu/drm/bridge/imx/imx-ldb-helper.h | 98 +++ drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 587 +++++++++++++++++ drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 722 +++++++++++++++++++++ .../gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 448 +++++++++++++ drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 429 ++++++++++++ drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 487 ++++++++++++++ include/uapi/linux/media-bus-format.h | 6 +- 19 files changed, 3951 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml create mode 100644 Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml create mode 100644 drivers/gpu/drm/bridge/imx/Kconfig create mode 100644 drivers/gpu/drm/bridge/imx/Makefile create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c -- 2.7.4

2 17

[PATCH] drivers: gpu: drm: bridge: fix kconfig dependency on DRM_KMS_HELPER
by Julian Braha 01 Apr '21

01 Apr '21

When DRM_TOSHIBA_TC358762 is enabled and DRM_KMS_HELPER is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n] Selected by [y]: - DRM_TOSHIBA_TC358762 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=y] This is because DRM_TOSHIBA_TC358762 selects DRM_PANEL_BRIDGE, without depending on or selecting DRM_KMS_HELPER, despite that config option depending on DRM_KMS_HELPER. Signed-off-by: Julian Braha <julianbraha(a)gmail.com> --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e4110d6ca7b3..909d0a5643c2 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -183,6 +183,7 @@ config DRM_TOSHIBA_TC358762 tristate "TC358762 DSI/DPI bridge" depends on OF select DRM_MIPI_DSI + select DRM_KMS_HELPER select DRM_PANEL_BRIDGE help Toshiba TC358762 DSI/DPI bridge driver. -- 2.27.0

2 1

[PATCH v3 0/2] drm/mediatek: Don't support hdmi connector creation
by Dafna Hirschfeld 01 Apr '21

01 Apr '21

commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges") broke the display support for elm device since mtk_dpi calls drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR while mtk_hdmi does not yet support this flag. These three patches fix that by adding support for DRM_BRIDGE_ATTACH_NO_CONNECTOR in mtk_hdmi bridge attachment. changes since v2: 1. squash patch 3 with patch 2 to not break bisection 2. remove the funtion mtk_hdmi_get_edid and inline its code in mtk_hdmi_bridge_get_edid 3. small aligment changes since v1: 1. split the first patch - now the first patch only moves the bridge ops to the atomic API while the replacement of the field 'conn' with the field '*curr_conn' is done in a new third patch. 2. in the function 'get_eld' use the current conn only if 'enabled = true'. Dafna Hirschfeld (2): drm/mediatek: Switch the hdmi bridge ops to the atomic versions drm/mediatek: Don't support hdmi connector creation drivers/gpu/drm/mediatek/mtk_hdmi.c | 174 ++++++++++++---------------- 1 file changed, 71 insertions(+), 103 deletions(-) -- 2.17.1

2 3

[PATCH] drm/amd/display: Try YCbCr420 color when YCbCr444 fails
by Werner Sembach 01 Apr '21

01 Apr '21

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. On some setups, while the monitor and the gpu support display modes with pixel clocks of up to 600MHz, the link encoder might not. This prevents YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the link encoder capabilities are checked. This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. Signed-off-by: Werner Sembach <wse(a)tuxedocomputers.com> Cc: <stable(a)vger.kernel.org> --- >From c9398160caf4ff20e63b8ba3a4366d6ef95c4ac3 Mon Sep 17 00:00:00 2001 From: Werner Sembach <wse(a)tuxedocomputers.com> Date: Wed, 17 Mar 2021 12:52:22 +0100 Subject: [PATCH] Retry forcing YCbCr420 color on failed encoder validation --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 961abf1cf040..2d16389b5f1e 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -5727,6 +5727,15 @@ create_validate_stream_for_sink(struct amdgpu_dm_connector *aconnector, } while (stream == NULL && requested_bpc >= 6); + if (dc_result == DC_FAIL_ENC_VALIDATE && !aconnector->force_yuv420_output) { + DRM_DEBUG_KMS("Retry forcing YCbCr420 encoding\n"); + + aconnector->force_yuv420_output = true; + stream = create_validate_stream_for_sink(aconnector, drm_mode, + dm_state, old_stream); + aconnector->force_yuv420_output = false; + } + return stream; } -- 2.25.1

3 4

[PATCH] drm/i915/pmu: Check actual RC6 status
by Tvrtko Ursulin 01 Apr '21

01 Apr '21

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> RC6 support cannot be simply established by looking at the static device HAS_RC6() flag. There are cases which disable RC6 at driver load time so use the status of those check when deciding whether to enumerate the rc6 counter. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Reported-by: Eero T Tamminen <eero.t.tamminen(a)intel.com> --- drivers/gpu/drm/i915/i915_pmu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c index 41651ac255fa..a75cd1db320b 100644 --- a/drivers/gpu/drm/i915/i915_pmu.c +++ b/drivers/gpu/drm/i915/i915_pmu.c @@ -476,6 +476,8 @@ engine_event_status(struct intel_engine_cs *engine, static int config_status(struct drm_i915_private *i915, u64 config) { + struct intel_gt *gt = &i915->gt; + switch (config) { case I915_PMU_ACTUAL_FREQUENCY: if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) @@ -489,7 +491,7 @@ config_status(struct drm_i915_private *i915, u64 config) case I915_PMU_INTERRUPTS: break; case I915_PMU_RC6_RESIDENCY: - if (!HAS_RC6(i915)) + if (!gt->rc6.supported) return -ENODEV; break; case I915_PMU_SOFTWARE_GT_AWAKE_TIME: -- 2.27.0

3 5

[PATCH] fix NULL pointer deference crash
by Hassan Shahbazi 01 Apr '21

01 Apr '21

The patch has fixed a NULL pointer deference crash in hiding the cursor. It is verified by syzbot patch tester. Reported by: syzbot https://syzkaller.appspot.com/bug?id=defb47bf56e1c14d5687280c7bb91ce7b608b9… Signed-off-by: Hassan Shahbazi <h.shahbazi.git(a)gmail.com> --- drivers/video/fbdev/core/fbcon.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 44a5cd2f54cc..ee252d1c43c6 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -1333,8 +1333,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode) ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1; - ops->cursor(vc, info, mode, get_color(vc, info, c, 1), - get_color(vc, info, c, 0)); + if (ops && ops->cursor) + ops->cursor(vc, info, mode, get_color(vc, info, c, 1), + get_color(vc, info, c, 0)); } static int scrollback_phys_max = 0; -- 2.26.3

3 4

← Newer
1
...
16
17
18
19
20
21
22
...
87
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2021