dri-devel March 2022

dri-devel@lists.freedesktop.org

370 participants
780 discussions

Question regarding using Driver Component Framework (crashing kernel)
by Won Chung 23 Mar '22

23 Mar '22

Hi, I am not sure if this is the correct mailing list to ask about Driver Component Framework, so if I am mistaken, I would appreciate it if anyone can correct me to the right direction. I have a quick question on using driver component framework and a strange crash I am seeing when I use component framework. There is then component framework currently being used for typec connector, as below https://elixir.bootlin.com/linux/latest/source/drivers/usb/typec/port-mappe… We add component for usb port to link it with typec connector, as below https://elixir.bootlin.com/linux/latest/source/drivers/usb/core/port.c#L622 https://elixir.bootlin.com/linux/latest/source/drivers/usb/core/port.c#L568 We are trying to do something similar for usb4 port, add component to link to typec connector. I have attached a patch to this email for reference. However, this change causes a crash in kernel for some devices. The crash is too early in the kernel that it is not giving any logs at all. This crash is somehow fixed when we change usb4 config from =y (built-in) to =m (loadable module). So, I am curious if there are some aspects in the component framework that depends on whether the device with a component added is a built-in or loadable module. If anyone has seen a similar issue or have an idea on what is happening, can you share your thoughts on what might be the issue and how the crash can be avoided? Thank you very much! Won

2 1

[PATCH] gpu: drm: Fix duplicate included linux/module.h
by Haowen Bai 23 Mar '22

23 Mar '22

Clean up the following includecheck warning: drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. No functional change. Signed-off-by: Haowen Bai <baihaowen(a)meizu.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 62192411..7915047 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include <linux/shmem_fs.h> #include <linux/slab.h> #include <linux/vmalloc.h> -#include <linux/module.h> #ifdef CONFIG_X86 #include <asm/set_memory.h> -- 2.7.4

1 0

[PATCH] drm: drm_bufs: Error out if 'dev->agp' is a null pointer
by Zheyu Ma 23 Mar '22

23 Mar '22

The user program can control the 'drm_buf_desc::flags' via ioctl system call and enter the function drm_legacy_addbufs_agp(). If the driver doesn't initialize the agp resources, the driver will cause a null pointer dereference. The following log reveals it: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] Call Trace: <TASK> drm_ioctl_kernel+0x342/0x450 drivers/gpu/drm/drm_ioctl.c:785 drm_ioctl+0x592/0x940 drivers/gpu/drm/drm_ioctl.c:885 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl+0xaa/0xf0 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x43/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fix this bug by adding a check. Signed-off-by: Zheyu Ma <zheyuma97(a)gmail.com> --- drivers/gpu/drm/drm_bufs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index fcca21e8efac..4fe2363b1e34 100644 --- a/drivers/gpu/drm/drm_bufs.c +++ b/drivers/gpu/drm/drm_bufs.c @@ -734,7 +734,7 @@ int drm_legacy_addbufs_agp(struct drm_device *dev, int i, valid; struct drm_buf **temp_buflist; - if (!dma) + if (!dma || !dev->agp) return -EINVAL; count = request->count; -- 2.25.1

2 4

[PATCH 1/7] drm/gma500: Use managed drmm_mode_config_init()
by Patrik Jakobsson 22 Mar '22

22 Mar '22

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> --- drivers/gpu/drm/gma500/framebuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c index 45df9de22007..2b99c996fdc2 100644 --- a/drivers/gpu/drm/gma500/framebuffer.c +++ b/drivers/gpu/drm/gma500/framebuffer.c @@ -514,7 +514,8 @@ void psb_modeset_init(struct drm_device *dev) struct pci_dev *pdev = to_pci_dev(dev->dev); int i; - drm_mode_config_init(dev); + if (drmm_mode_config_init(dev)) + return; dev->mode_config.min_width = 0; dev->mode_config.min_height = 0; @@ -546,6 +547,5 @@ void psb_modeset_cleanup(struct drm_device *dev) if (dev_priv->modeset) { drm_kms_helper_poll_fini(dev); psb_fbdev_fini(dev); - drm_mode_config_cleanup(dev); } } -- 2.35.1

3 14

[PATCH 0/2] drm/imx/lcdc: drm driver for imx21/25/27
by Uwe Kleine-König 22 Mar '22

22 Mar '22

Hello, this patchset was created mostly by Marian Cichy, who in the meantime left Pengutronix. I still kept his name and email address as author, but note that the email address doesn't reach Marian any more. There is already a maintainer entry for imx DRM drivers that matches good enough. This was tested on an i.MX25 based customer machine. Best regards Uwe Marian Cichy (2): dt-bindings: display: imx: Add fsl,imx21-lcdc docs drm/imx/lcdc: Implement DRM driver for imx21 .../bindings/display/imx/fsl,imx21-lcdc.yaml | 79 +++ drivers/gpu/drm/imx/Kconfig | 9 + drivers/gpu/drm/imx/Makefile | 2 + drivers/gpu/drm/imx/imx21-lcdc/imx21-lcdc.c | 631 ++++++++++++++++++ 4 files changed, 721 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx21-lcdc.yaml create mode 100644 drivers/gpu/drm/imx/imx21-lcdc/imx21-lcdc.c -- 2.34.1

5 12

[PATCH] drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities
by Imre Deak 22 Mar '22

22 Mar '22

At least some DELL monitors (P2715Q) with DPCD_REV 1.2 return corrupted DPCD register values when reading from the 0xF0000- LTTPR range with an AUX transaction block size bigger than 1. The DP standard requires 0 to be returned - as for any other reserved/invalid addresses - but these monitors return the DPCD_REV register value repeated in each byte of the read buffer. This will in turn corrupt the values returned by the LTTPRs between the source and the monitor: LTTPRs must adjust the values they read from the downstream DPRX, for instance left-shift/init the downstream DP_PHY_REPEATER_CNT value. Since the value returned by the monitor's DPRX is non-zero the adjusted values will be corrupt. Reading the LTTPR registers one-by-one instead of reading all of them with a single AUX transfer works around the issue. According to the DP standard's 0xF0000 register description: "LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for DPCD r1.4 (or higher)." While it's unclear if DPCD r1.4 refers to the DPCD_REV or to the LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV register (tickets filed at the VESA site to clarify this haven't been addressed), one possibility is that it's a restriction due to non-compliant monitors described above. Disabling the non-transparent LTTPR mode for all such monitors is not a viable solution: the transparent LTTPR mode has its own issue causing link training failures and this would affect a lot of monitors in use with DPCD_REV < 1.4. Instead this patch works around the problem by reading the LTTPR common and PHY cap registers one-by-one for any monitor with a DPCD_REV < 1.4. The standard requires the DPCD capabilites to be read after the LTTPR common capabilities are read, so re-read the DPCD capabilities after the LTTPR common and PHY caps were read out. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4531 Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/dp/drm_dp.c | 58 ++++++++++++------- .../drm/i915/display/intel_dp_link_training.c | 30 +++++++--- include/drm/dp/drm_dp_helper.h | 2 + 3 files changed, 59 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/dp/drm_dp.c b/drivers/gpu/drm/dp/drm_dp.c index 703972ae14c64..f3950d42980f9 100644 --- a/drivers/gpu/drm/dp/drm_dp.c +++ b/drivers/gpu/drm/dp/drm_dp.c @@ -2390,9 +2390,36 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_S } EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs); +static int drm_dp_read_lttpr_regs(struct drm_dp_aux *aux, const u8 dpcd[DP_RECEIVER_CAP_SIZE], int address, + u8 *buf, int buf_size) +{ + /* + * Some monitors with a DPCD_REV < 0x14 return corrupted values when + * reading from the 0xF0000- range with a block size bigger than 1. + */ + int block_size = dpcd[DP_DPCD_REV] < 0x14 ? 1 : buf_size; + int offset = 0; + int ret; + + while (offset < buf_size) { + ret = drm_dp_dpcd_read(aux, + address + offset, + &buf[offset], block_size); + if (ret < 0) + return ret; + + WARN_ON(ret != block_size); + + offset += block_size; + } + + return 0; +} + /** * drm_dp_read_lttpr_common_caps - read the LTTPR common capabilities * @aux: DisplayPort AUX channel + * @dpcd: DisplayPort configuration data * @caps: buffer to return the capability info in * * Read capabilities common to all LTTPRs. @@ -2400,25 +2427,19 @@ EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs); * Returns 0 on success or a negative error code on failure. */ int drm_dp_read_lttpr_common_caps(struct drm_dp_aux *aux, + const u8 dpcd[DP_RECEIVER_CAP_SIZE], u8 caps[DP_LTTPR_COMMON_CAP_SIZE]) { - int ret; - - ret = drm_dp_dpcd_read(aux, - DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV, - caps, DP_LTTPR_COMMON_CAP_SIZE); - if (ret < 0) - return ret; - - WARN_ON(ret != DP_LTTPR_COMMON_CAP_SIZE); - - return 0; + return drm_dp_read_lttpr_regs(aux, dpcd, + DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV, + caps, DP_LTTPR_COMMON_CAP_SIZE); } EXPORT_SYMBOL(drm_dp_read_lttpr_common_caps); /** * drm_dp_read_lttpr_phy_caps - read the capabilities for a given LTTPR PHY * @aux: DisplayPort AUX channel + * @dpcd: DisplayPort configuration data * @dp_phy: LTTPR PHY to read the capabilities for * @caps: buffer to return the capability info in * @@ -2427,20 +2448,13 @@ EXPORT_SYMBOL(drm_dp_read_lttpr_common_caps); * Returns 0 on success or a negative error code on failure. */ int drm_dp_read_lttpr_phy_caps(struct drm_dp_aux *aux, + const u8 dpcd[DP_RECEIVER_CAP_SIZE], enum drm_dp_phy dp_phy, u8 caps[DP_LTTPR_PHY_CAP_SIZE]) { - int ret; - - ret = drm_dp_dpcd_read(aux, - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER(dp_phy), - caps, DP_LTTPR_PHY_CAP_SIZE); - if (ret < 0) - return ret; - - WARN_ON(ret != DP_LTTPR_PHY_CAP_SIZE); - - return 0; + return drm_dp_read_lttpr_regs(aux, dpcd, + DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER(dp_phy), + caps, DP_LTTPR_PHY_CAP_SIZE); } EXPORT_SYMBOL(drm_dp_read_lttpr_phy_caps); diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 5d98773efd1b3..fbee20a76cf44 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -55,6 +55,7 @@ static u8 *intel_dp_lttpr_phy_caps(struct intel_dp *intel_dp, } static void intel_dp_read_lttpr_phy_caps(struct intel_dp *intel_dp, + const u8 dpcd[DP_RECEIVER_CAP_SIZE], enum drm_dp_phy dp_phy) { struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base; @@ -63,7 +64,7 @@ static void intel_dp_read_lttpr_phy_caps(struct intel_dp *intel_dp, intel_dp_phy_name(dp_phy, phy_name, sizeof(phy_name)); - if (drm_dp_read_lttpr_phy_caps(&intel_dp->aux, dp_phy, phy_caps) < 0) { + if (drm_dp_read_lttpr_phy_caps(&intel_dp->aux, dpcd, dp_phy, phy_caps) < 0) { drm_dbg_kms(&dp_to_i915(intel_dp)->drm, "[ENCODER:%d:%s][%s] failed to read the PHY caps\n", encoder->base.base.id, encoder->base.name, phy_name); @@ -77,10 +78,11 @@ static void intel_dp_read_lttpr_phy_caps(struct intel_dp *intel_dp, phy_caps); } -static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp) +static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp, const u8 dpcd[DP_RECEIVER_CAP_SIZE]) { struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base; struct drm_i915_private *i915 = to_i915(encoder->base.dev); + int ret; if (intel_dp_is_edp(intel_dp)) return false; @@ -92,8 +94,9 @@ static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp) if (DISPLAY_VER(i915) < 10 || IS_GEMINILAKE(i915)) return false; - if (drm_dp_read_lttpr_common_caps(&intel_dp->aux, - intel_dp->lttpr_common_caps) < 0) + ret = drm_dp_read_lttpr_common_caps(&intel_dp->aux, dpcd, + intel_dp->lttpr_common_caps); + if (ret < 0) goto reset_caps; drm_dbg_kms(&dp_to_i915(intel_dp)->drm, @@ -122,14 +125,14 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp *intel_dp, bool enable) return drm_dp_dpcd_write(&intel_dp->aux, DP_PHY_REPEATER_MODE, &val, 1) == 1; } -static int intel_dp_init_lttpr(struct intel_dp *intel_dp) +static int intel_dp_init_lttpr(struct intel_dp *intel_dp, const u8 dpcd[DP_RECEIVER_CAP_SIZE]) { struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base; struct drm_i915_private *i915 = to_i915(encoder->base.dev); int lttpr_count; int i; - if (!intel_dp_read_lttpr_common_caps(intel_dp)) + if (!intel_dp_read_lttpr_common_caps(intel_dp, dpcd)) return 0; lttpr_count = drm_dp_lttpr_count(intel_dp->lttpr_common_caps); @@ -168,7 +171,7 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp) } for (i = 0; i < lttpr_count; i++) - intel_dp_read_lttpr_phy_caps(intel_dp, DP_PHY_LTTPR(i)); + intel_dp_read_lttpr_phy_caps(intel_dp, dpcd, DP_PHY_LTTPR(i)); return lttpr_count; } @@ -193,9 +196,18 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp) */ int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp) { - int lttpr_count = intel_dp_init_lttpr(intel_dp); + u8 dpcd[DP_RECEIVER_CAP_SIZE]; + int lttpr_count; - /* The DPTX shall read the DPRX caps after LTTPR detection. */ + if (drm_dp_read_dpcd_caps(&intel_dp->aux, dpcd)) + return -EIO; + + lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd); + + /* + * The DPTX shall read the DPRX caps after LTTPR detection, so re-read + * it here. + */ if (drm_dp_read_dpcd_caps(&intel_dp->aux, intel_dp->dpcd)) { intel_dp_reset_lttpr_common_caps(intel_dp); return -EIO; diff --git a/include/drm/dp/drm_dp_helper.h b/include/drm/dp/drm_dp_helper.h index 51e02cf75277e..1eccd97419436 100644 --- a/include/drm/dp/drm_dp_helper.h +++ b/include/drm/dp/drm_dp_helper.h @@ -2148,8 +2148,10 @@ bool drm_dp_read_sink_count_cap(struct drm_connector *connector, int drm_dp_read_sink_count(struct drm_dp_aux *aux); int drm_dp_read_lttpr_common_caps(struct drm_dp_aux *aux, + const u8 dpcd[DP_RECEIVER_CAP_SIZE], u8 caps[DP_LTTPR_COMMON_CAP_SIZE]); int drm_dp_read_lttpr_phy_caps(struct drm_dp_aux *aux, + const u8 dpcd[DP_RECEIVER_CAP_SIZE], enum drm_dp_phy dp_phy, u8 caps[DP_LTTPR_PHY_CAP_SIZE]); int drm_dp_lttpr_count(const u8 cap[DP_LTTPR_COMMON_CAP_SIZE]); -- 2.27.0

2 5

[PATCH 0/4] Drop wbinvd_on_all_cpus usage
by Michael Cheng 22 Mar '22

22 Mar '22

To align with the discussion in [1][2], this patch series drops all usage of wbvind_on_all_cpus within i915 by either replacing the call with certain drm clflush helpers, or reverting to a previous logic. [1]. https://lists.freedesktop.org/archives/dri-devel/2021-November/330928.html [2]. https://patchwork.freedesktop.org/patch/475752/?series=99991&rev=5 Michael Cheng (4): i915/gem: drop wbinvd_on_all_cpus usage Revert "drm/i915/gem: Almagamate clflushes on suspend" i915/gem: Revert i915_gem_freeze to previous logic drm/i915/gt: Revert ggtt_resume to previous logic drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 +--- drivers/gpu/drm/i915/gem/i915_gem_pm.c | 56 ++++++++++++++-------- drivers/gpu/drm/i915/gt/intel_ggtt.c | 17 +++---- drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +- 4 files changed, 46 insertions(+), 38 deletions(-) -- 2.25.1

4 27

[PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)
by Jason Ekstrand 22 Mar '22

22 Mar '22

Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we can control whether or not i915 synchronizes on the buffer and whether or not it's considered written. The harder part is the compositor -> client synchronization when we get the buffer back from the compositor. We're required to be able to provide the client with a VkSemaphore and VkFence representing the point in time where the window system (compositor and/or display) finished using the buffer. With current APIs, it's very hard to do this in such a way that we don't get confused by the Vulkan driver's access of the buffer. In particular, once we tell the kernel that we're rendering to the buffer again, any CPU waits on the buffer or GPU dependencies will wait on some of the client rendering and not just the compositor. This new IOCTL solves this problem by allowing us to get a snapshot of the implicit synchronization state of a given dma-buf in the form of a sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, instead of CPU waiting directly, it encapsulates the wait operation, at the current moment in time, in a sync_file so we can check/wait on it later. As long as the Vulkan driver does the sync_file export from the dma-buf before we re-introduce it for rendering, it will only contain fences from the compositor or display. This allows to accurately turn it into a VkFence or VkSemaphore without any over- synchronization. This patch series actually contains two new ioctls. There is the export one mentioned above as well as an RFC for an import ioctl which provides the other half. The intention is to land the export ioctl since it seems like there's no real disagreement on that one. The import ioctl, however, has a lot of debate around it so it's intended to be RFC-only for now. Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 IGT tests: https://patchwork.freedesktop.org/series/90490/ v10 (Jason Ekstrand, Daniel Vetter): - Add reviews/acks - Add a patch to rename _rcu to _unlocked - Split things better so import is clearly RFC status v11 (Daniel Vetter): - Add more CCs to try and get maintainers - Add a patch to document DMA_BUF_IOCTL_SYNC - Generally better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch v12 (Daniel Vetter): - Better docs for DMA_BUF_IOCTL_SYNC v12 (Christian König): - Drop the rename patch in favor of Christian's series - Add a comment to the commit message for the dma-buf sync_file export ioctl saying why we made it an ioctl on dma-buf Cc: Christian König <christian.koenig(a)amd.com> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Cc: Daniel Stone <daniels(a)collabora.com> Cc: mesa-dev(a)lists.freedesktop.org Cc: wayland-devel(a)lists.freedesktop.org Test-with: 20210524205225.872316-1-jason(a)jlekstrand.net Christian König (1): dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand (5): dma-buf: Add dma_resv_get_singleton (v6) dma-buf: Document DMA_BUF_IOCTL_SYNC (v2) dma-buf: Add an API for exporting sync files (v12) RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked RFC: dma-buf: Add an API for importing sync files (v7) Documentation/driver-api/dma-buf.rst | 8 ++ drivers/dma-buf/dma-buf.c | 103 +++++++++++++++++++++++++ drivers/dma-buf/dma-fence-array.c | 27 +++++++ drivers/dma-buf/dma-resv.c | 110 +++++++++++++++++++++++++++ include/linux/dma-fence-array.h | 17 +++++ include/linux/dma-resv.h | 2 + include/uapi/linux/dma-buf.h | 103 ++++++++++++++++++++++++- 7 files changed, 369 insertions(+), 1 deletion(-) -- 2.31.1

8 31

[PATCH] drm/nouveau/pmu: Add missing callbacks for Tegra devices
by Karol Herbst 22 Mar '22

22 Mar '22

Fixes a crash booting on those platforms with nouveau. Fixes: 4cdd2450bf73 ("drm/nouveau/pmu/gm200-: use alternate falcon reset sequence") Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: Karol Herbst <kherbst(a)redhat.com> Cc: dri-devel(a)lists.freedesktop.org Cc: nouveau(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.17+ Signed-off-by: Karol Herbst <kherbst(a)redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h | 1 + 4 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c index e1772211b0a4..612310d5d481 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c @@ -216,6 +216,7 @@ gm20b_pmu = { .intr = gt215_pmu_intr, .recv = gm20b_pmu_recv, .initmsg = gm20b_pmu_initmsg, + .reset = gf100_pmu_reset, }; #if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c index 6bf7fc1bd1e3..1a6f9c3af5ec 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c @@ -23,7 +23,7 @@ */ #include "priv.h" -static void +void gp102_pmu_reset(struct nvkm_pmu *pmu) { struct nvkm_device *device = pmu->subdev.device; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c index ba1583bb618b..94cfb1791af6 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c @@ -83,6 +83,7 @@ gp10b_pmu = { .intr = gt215_pmu_intr, .recv = gm20b_pmu_recv, .initmsg = gm20b_pmu_initmsg, + .reset = gp102_pmu_reset, }; #if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h index bcaade758ff7..21abf31f4442 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h @@ -41,6 +41,7 @@ int gt215_pmu_send(struct nvkm_pmu *, u32[2], u32, u32, u32, u32); bool gf100_pmu_enabled(struct nvkm_pmu *); void gf100_pmu_reset(struct nvkm_pmu *); +void gp102_pmu_reset(struct nvkm_pmu *pmu); void gk110_pmu_pgob(struct nvkm_pmu *, bool); -- 2.35.1

1 0

[PATCH] drm/amd/display: use NULL instead of using plain integer as pointer
by Haowen Bai 22 Mar '22

22 Mar '22

This fixes the following sparse warnings: drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:865:16: warning: Using plain integer as NULL pointer Signed-off-by: Haowen Bai <baihaowen(a)meizu.com> --- drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c index ee55cda..560da6c 100644 --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c @@ -862,7 +862,7 @@ static struct clock_source *find_matching_pll( return NULL; } - return 0; + return NULL; } static enum dc_status build_mapped_resource( -- 2.7.4

1 0

← Newer
1
...
32
33
34
35
36
37
38
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2022