dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

[PATCH 25/37] video: handle HAS_IOPORT dependencies
by Niklas Schnelle 29 Apr '22

29 Apr '22

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them and guard inline code in headers. Co-developed-by: Arnd Bergmann <arnd(a)kernel.org> Signed-off-by: Niklas Schnelle <schnelle(a)linux.ibm.com> --- drivers/video/fbdev/Kconfig | 25 +++++++++++++------------ include/video/vga.h | 8 ++++++++ 2 files changed, 21 insertions(+), 12 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 93b8d84c34cf..e7d27c0602d5 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -343,7 +343,7 @@ config FB_IMX config FB_CYBER2000 tristate "CyberPro 2000/2010/5000 support" - depends on FB && PCI && (BROKEN || !SPARC64) + depends on FB && PCI && HAS_IOPORT && (BROKEN || !SPARC64) select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -436,6 +436,7 @@ config FB_FM2 config FB_ARC tristate "Arc Monochrome LCD board support" depends on FB && (X86 || COMPILE_TEST) + depends on HAS_IOPORT select FB_SYS_FILLRECT select FB_SYS_COPYAREA select FB_SYS_IMAGEBLIT @@ -1242,7 +1243,7 @@ config FB_RADEON_DEBUG config FB_ATY128 tristate "ATI Rage128 display support" - depends on FB && PCI + depends on FB && PCI && HAS_IOPORT select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -1265,7 +1266,7 @@ config FB_ATY128_BACKLIGHT config FB_ATY tristate "ATI Mach64 display support" if PCI || ATARI - depends on FB && !SPARC32 + depends on FB && HAS_IOPORT && !SPARC32 select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -1315,7 +1316,7 @@ config FB_ATY_BACKLIGHT config FB_S3 tristate "S3 Trio/Virge support" - depends on FB && PCI + depends on FB && PCI && HAS_IOPORT select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -1374,7 +1375,7 @@ config FB_SAVAGE_ACCEL config FB_SIS tristate "SiS/XGI display support" - depends on FB && PCI + depends on FB && PCI && HAS_IOPORT select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -1404,7 +1405,7 @@ config FB_SIS_315 config FB_VIA tristate "VIA UniChrome (Pro) and Chrome9 display support" - depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST) + depends on FB && PCI && GPIOLIB && I2C && HAS_IOPORT && (X86 || COMPILE_TEST) select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -1442,7 +1443,7 @@ endif config FB_NEOMAGIC tristate "NeoMagic display support" - depends on FB && PCI + depends on FB && PCI && HAS_IOPORT select FB_MODE_HELPERS select FB_CFB_FILLRECT select FB_CFB_COPYAREA @@ -1470,7 +1471,7 @@ config FB_KYRO config FB_3DFX tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support" - depends on FB && PCI + depends on FB && PCI && HAS_IOPORT select FB_CFB_IMAGEBLIT select FB_CFB_FILLRECT select FB_CFB_COPYAREA @@ -1518,7 +1519,7 @@ config FB_VOODOO1 config FB_VT8623 tristate "VIA VT8623 support" - depends on FB && PCI + depends on FB && PCI && HAS_IOPORT select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -1532,7 +1533,7 @@ config FB_VT8623 config FB_TRIDENT tristate "Trident/CyberXXX/CyberBlade support" - depends on FB && PCI + depends on FB && PCI && HAS_IOPORT select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -1554,7 +1555,7 @@ config FB_TRIDENT config FB_ARK tristate "ARK 2000PV support" - depends on FB && PCI + depends on FB && PCI && HAS_IOPORT select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -2226,7 +2227,7 @@ config FB_SSD1307 config FB_SM712 tristate "Silicon Motion SM712 framebuffer support" - depends on FB && PCI + depends on FB && PCI && HAS_IOPORT select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT diff --git a/include/video/vga.h b/include/video/vga.h index d334e64c1c19..53cb52c0fddb 100644 --- a/include/video/vga.h +++ b/include/video/vga.h @@ -201,18 +201,26 @@ extern int restore_vga(struct vgastate *state); static inline unsigned char vga_io_r (unsigned short port) { +#ifdef CONFIG_HAS_IOPORT return inb_p(port); +#else + return 0xff; +#endif } static inline void vga_io_w (unsigned short port, unsigned char val) { +#ifdef CONFIG_HAS_IOPORT outb_p(val, port); +#endif } static inline void vga_io_w_fast (unsigned short port, unsigned char reg, unsigned char val) { +#ifdef CONFIG_HAS_IOPORT outw(VGA_OUT16VAL (val, reg), port); +#endif } static inline unsigned char vga_mm_r (void __iomem *regbase, unsigned short port) -- 2.32.0

1 1

[CI] drm/i915: Fix assert in i915_ggtt_pin
by Tvrtko Ursulin 29 Apr '22

29 Apr '22

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Use lockdep_assert_not_held to simplify and correct the code. Otherwise false positive are hit if lock state is uknown like after a previous taint. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Reported-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- It's not pretty but it fired again and it's distracting so it will have to do for now. --- drivers/gpu/drm/i915/i915_vma.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index 162e8d83691b..e782ebfcc0ca 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -1565,9 +1565,7 @@ int i915_ggtt_pin(struct i915_vma *vma, struct i915_gem_ww_ctx *ww, if (ww) return __i915_ggtt_pin(vma, ww, align, flags); -#ifdef CONFIG_LOCKDEP - WARN_ON(dma_resv_held(vma->obj->base.resv)); -#endif + lockdep_assert_not_held(&vma->obj->base.resv->lock.base); for_i915_gem_ww(&_ww, err, true) { err = i915_gem_object_lock(vma->obj, &_ww); -- 2.32.0

1 0

[RFC v2 36/39] video: handle HAS_IOPORT dependencies
by Niklas Schnelle 29 Apr '22

29 Apr '22

1 0

[RFC v2 08/39] drm: handle HAS_IOPORT dependencies
by Niklas Schnelle 29 Apr '22

29 Apr '22

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. In the bochs driver there is optional MMIO support detected at runtime, warn if this isn't taken when HAS_IOPORT is not defined. There is also a direct and hard coded use in cirrus.c which according to the comment is only necessary during resume. Let's just skip this as for example s390 which doesn't have I/O port support also doesen't support suspend/resume. Co-developed-by: Arnd Bergmann <arnd(a)kernel.org> Signed-off-by: Niklas Schnelle <schnelle(a)linux.ibm.com> --- drivers/gpu/drm/qxl/Kconfig | 1 + drivers/gpu/drm/tiny/bochs.c | 19 +++++++++++++++++++ drivers/gpu/drm/tiny/cirrus.c | 2 ++ 3 files changed, 22 insertions(+) diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig index ca3f51c2a8fe..d0e0d440c8d9 100644 --- a/drivers/gpu/drm/qxl/Kconfig +++ b/drivers/gpu/drm/qxl/Kconfig @@ -2,6 +2,7 @@ config DRM_QXL tristate "QXL virtual GPU" depends on DRM && PCI && MMU + depends on HAS_IOPORT select DRM_KMS_HELPER select DRM_TTM select DRM_TTM_HELPER diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c index ed971c8bb446..9acc726d99ec 100644 --- a/drivers/gpu/drm/tiny/bochs.c +++ b/drivers/gpu/drm/tiny/bochs.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-or-later +#include <asm/bug.h> #include <linux/pci.h> #include <drm/drm_aperture.h> @@ -102,7 +103,11 @@ static void bochs_vga_writeb(struct bochs_device *bochs, u16 ioport, u8 val) writeb(val, bochs->mmio + offset); } else { +#ifdef HAS_IOPORT outb(val, ioport); +#else + WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT"); +#endif } } @@ -116,7 +121,12 @@ static u8 bochs_vga_readb(struct bochs_device *bochs, u16 ioport) return readb(bochs->mmio + offset); } else { +#ifdef HAS_IOPORT return inb(ioport); +#else + WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT"); + return 0xff; +#endif } } @@ -129,8 +139,13 @@ static u16 bochs_dispi_read(struct bochs_device *bochs, u16 reg) ret = readw(bochs->mmio + offset); } else { +#ifdef HAS_IOPORT outw(reg, VBE_DISPI_IOPORT_INDEX); ret = inw(VBE_DISPI_IOPORT_DATA); +#else + WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT"); + ret = 0xffff; +#endif } return ret; } @@ -142,8 +157,12 @@ static void bochs_dispi_write(struct bochs_device *bochs, u16 reg, u16 val) writew(val, bochs->mmio + offset); } else { +#ifdef HAS_IOPORT outw(reg, VBE_DISPI_IOPORT_INDEX); outw(val, VBE_DISPI_IOPORT_DATA); +#else + WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT"); +#endif } } diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c index c8e791840862..0dc4788c5399 100644 --- a/drivers/gpu/drm/tiny/cirrus.c +++ b/drivers/gpu/drm/tiny/cirrus.c @@ -306,8 +306,10 @@ static int cirrus_mode_set(struct cirrus_device *cirrus, cirrus_set_start_address(cirrus, 0); +#ifdef CONFIG_HAS_IOPORT /* Unblank (needed on S3 resume, vgabios doesn't do it then) */ outb(0x20, 0x3c0); +#endif drm_dev_exit(idx); return 0; -- 2.32.0

1 0

[Bug 201991] New: amdgpu: clock management is disabled for the 4K resolution with polaris 10
by bugzilla-daemon＠bugzilla.kernel.org 29 Apr '22

29 Apr '22

https://bugzilla.kernel.org/show_bug.cgi?id=201991 Bug ID: 201991 Summary: amdgpu: clock management is disabled for the 4K resolution with polaris 10 Product: Drivers Version: 2.5 Kernel Version: 4.18.0,4.20.0-rc6, drm-next-4.21-wip Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: enhancement Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: fin4478(a)hotmail.com Regression: No Created attachment 280019 --> https://bugzilla.kernel.org/attachment.cgi?id=280019&action=edit simple app for the amdgpu sys interface When the Xfce desktop is visible at 4K and idling, the engine clock is fixed at level 6: 1220MHz and you can not change that. The temperature is 38 C. When the monitor is sleeping, then the engine clock is 300Mhz. The automatic power management works with 2560x1600 and lower resolutions as espected. I tested with my python app and I have latest drivers, including firmware files. My monitor is ASUS VP28UQG and I use the display port. System: Host: ryzenpc Kernel: 4.20.0-rc6 x86_64 bits: 64 Desktop: Xfce 4.12.4 Distro: Debian GNU/Linux buster/sid Machine: Type: Desktop Mobo: ASUSTeK model: PRIME B350M-K v: Rev X.0x serial: <root required> UEFI [Legacy]: American Megatrends v: 4023 date: 08/20/2018 CPU: 6-Core: AMD Ryzen 5 1600 type: MT MCP speed: 2851 MHz Graphics: Device-1: AMD Ellesmere [Radeon RX 470/480] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.3 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa resolution: 3840x2160~60Hz OpenGL: renderer: Radeon RX 570 Series (POLARIS10 DRM 3.27.0 4.20.0-rc6 LLVM 7.0.1) v: 4.5 Mesa 19.0.0-devel (git-9ebc00f 2018-12-13 bionic-oibaf-ppa) -- You are receiving this mail because: You are watching the assignee of the bug.

2 6

[PATCH 1/2] drm/edid: fix kernel-doc parameter name mismatches
by Jani Nikula 29 Apr '22

29 Apr '22

Fix the below drm/edid kernel-doc warnings: drivers/gpu/drm/drm_edid.c:1589: warning: Function parameter or member '_edid' not described in 'drm_edid_header_is_valid' drivers/gpu/drm/drm_edid.c:1589: warning: Excess function parameter 'raw_edid' description in 'drm_edid_header_is_valid' drivers/gpu/drm/drm_edid.c:1737: warning: Function parameter or member '_block' not described in 'drm_edid_block_valid' drivers/gpu/drm/drm_edid.c:1737: warning: Excess function parameter 'raw_edid' description in 'drm_edid_block_valid' drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member 'read_block' not described in 'drm_do_get_edid' drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member 'context' not described in 'drm_do_get_edid' drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter 'get_edid_block' description in 'drm_do_get_edid' drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter 'data' description in 'drm_do_get_edid' Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> References: https://lore.kernel.org/r/20220406154431.567414c3@canb.auug.org.au References: https://lore.kernel.org/r/20220420162431.2b28ddea@canb.auug.org.au Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- drivers/gpu/drm/drm_edid.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7a8482b75071..6446f5d3944b 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1610,7 +1610,7 @@ static void edid_header_fix(void *edid) /** * drm_edid_header_is_valid - sanity check the header of the base EDID block - * @raw_edid: pointer to raw base EDID block + * @_edid: pointer to raw base EDID block * * Sanity check the header of the base EDID block. * @@ -1827,7 +1827,7 @@ static void edid_block_dump(const char *level, const void *block, int block_num) /** * drm_edid_block_valid - Sanity check the EDID block (base or extension) - * @raw_edid: pointer to raw EDID block + * @_block: pointer to raw EDID block * @block_num: type of block to validate (0 for base, extension otherwise) * @print_bad_edid: if true, dump bad EDID blocks to the console * @edid_corrupt: if true, the header or checksum is invalid @@ -2112,8 +2112,8 @@ static enum edid_block_status edid_block_read(void *block, unsigned int block_nu /** * drm_do_get_edid - get EDID data using a custom EDID block read function * @connector: connector we're probing - * @get_edid_block: EDID block read function - * @data: private data passed to the block read function + * @read_block: EDID block read function + * @context: private data passed to the block read function * * When the I2C adapter connected to the DDC bus is hidden behind a device that * exposes a different interface to read EDID blocks this function can be used -- 2.30.2

1 2

[RFC PATCH v4 00/11] Fix some race between sysfb device registration and drivers probe
by Javier Martinez Canillas 29 Apr '22

29 Apr '22

Hello, The patches in this series contain mostly changes suggested by Daniel Vetter Thomas Zimmermann. They aim to fix existing races between the Generic System Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration. For example, it is currently possible for sysfb to register a platform device after a real DRM driver was registered and requested to remove the conflicting framebuffers. Or is possible for a simple{fb,drm} to match with a device previously registered by sysfb, even after a real driver is present. A symptom of this issue, was worked around with by commit fb561bf9abde ("fbdev: Prevent probing generic drivers if a FB is already registered") but that's really a hack and should be reverted. This series attempt to fix it more correctly and revert the mentioned hack. That will also allow to make the num_registered_fb variable not visible to drivers anymore, since that's internal to fbdev core. Even though the series is a v4, I've marked it as RFC again since some of the patches are controversial and the approach will need more discussion. Patches 1-3 add a new DRIVER_FIRMWARE capability to denote that a DRM driver uses a firmware provided framebuffer, to mark the emulated fbdev registered also as a firmware provided framebuffer. Pach 4 is just a simple cleanup in preparation for later patches. Patch 5 add a sysfb_disable() and sysfb_try_unregister() helpers to allow disabling sysfb and attempt to unregister registered devices respectively. Patch 6 changes how is dealt with conflicting framebuffers unregistering, rather than having a variable to determine if a lock should be take, it just drops the lock before unregistering the platform device. Patch 7 changes the fbdev core to not attempt to unregister devices that were registered by sysfb, let the same code doing the registration to also handle the unregistration. Patch 8 fixes the race that exists between sysfb devices registration and fbdev framebuffer devices registration. Patch 9 does the same but to fix the race that exists between sysfb and the DRM subsystem. Patch 10 is the revert patch that was posted by Daniel before but dropped from his set and finally patch 11 is the one that makes num_registered_fb private to fbmem.c and not allow drivers to use it anymore. The patches were tested on a rpi4 with the vc4, simpledrm and simplefb drivers, using different combinations of built-in and as a module. But being an RFC, I didn't test all possible cases. Best regards, Javier Changes in v4: - Make sysfb_disable() to also attempt to unregister a device. - Drop call to sysfb_disable() in fbmem since is done in other places now. - Add patch to make registered_fb[] private. - Add patches that introduce the DRM_FIRMWARE capability and usage. Changes in v3: - Add Thomas Zimmermann's Reviewed-by tag to patch #1. - Call sysfb_disable() when a fbdev framebuffer is registered rather than when conflicting framebuffers are removed (Thomas Zimmermann). - Drop Daniel Vetter's Reviewed-by tag since patch changed a lot. - Call sysfb_disable() when a DRM device is registered rather than when conflicting framebuffers are removed (Thomas Zimmermann). - Rebase on top of latest drm-misc-next branch. Changes in v2: - Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter). - Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter). - Explain in the commit message that fbmem has to unregister the device as fallback if a driver registered the device itself (Daniel Vetter). - Also explain that fallback in a comment in the code (Daniel Vetter). - Don't encode in fbmem the assumption that sysfb will always register platform devices (Daniel Vetter). - Add a FIXME comment about drivers registering devices (Daniel Vetter). - Explain in the commit message that fbmem has to unregister the device as fallback if a driver registered the device itself (Daniel Vetter). - Also explain that fallback in a comment in the code (Daniel Vetter). - Don't encode in fbmem the assumption that sysfb will always register platform devices (Daniel Vetter). - Add a FIXME comment about drivers registering devices (Daniel Vetter). - Drop RFC prefix since patches were already reviewed by Daniel Vetter. - Add Daniel Reviewed-by tags to the patches. Daniel Vetter (2): Revert "fbdev: Prevent probing generic drivers if a FB is already registered" fbdev: Make registered_fb[] private to fbmem.c Javier Martinez Canillas (9): drm: Add a capability flag for simple framebuffer drivers drm/fb-helper: Set FBINFO_MISC_FIRMWARE flag for DRIVER_FIRMWARE fb drm/simpledrm: Set the DRM_FIRMWARE capability firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer firmware: sysfb: Add helpers to unregister a pdev and disable registration fbdev: Restart conflicting fb removal loop when unregistering devices fbdev: Make sysfb to unregister its own registered devices fbdev: Fix race between sysfb and framebuffer devices registration drm: Fix race between sysfb and DRM devices registration .../driver-api/firmware/other_interfaces.rst | 6 ++ drivers/firmware/sysfb.c | 91 +++++++++++++++++-- drivers/firmware/sysfb_simplefb.c | 16 ++-- drivers/gpu/drm/drm_drv.c | 12 +++ drivers/gpu/drm/drm_fb_helper.c | 4 + drivers/gpu/drm/tiny/simpledrm.c | 2 +- drivers/video/fbdev/core/fbmem.c | 67 +++++++++++--- drivers/video/fbdev/efifb.c | 11 --- drivers/video/fbdev/simplefb.c | 11 --- include/drm/drm_drv.h | 6 ++ include/linux/fb.h | 8 +- include/linux/sysfb.h | 29 +++++- 12 files changed, 201 insertions(+), 62 deletions(-) -- 2.35.1

2 15

linux-next: manual merge of the amdgpu tree with the drm-misc tree
by Stephen Rothwell 29 Apr '22

29 Apr '22

Hi all, Today's linux-next merge of the amdgpu tree got a conflict in: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c between commit: fee2ede15542 ("drm/ttm: rework bulk move handling v5") from the drm-misc tree and commit: 184a69ca4d41 ("drm/amdgpu: separate VM PT handling into amdgpu_vm_pt.c") from the amdgpu tree. I fixed it up (I used this file from the latter and added the following patch) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. From: Stephen Rothwell <sfr(a)canb.auug.org.au> Date: Wed, 6 Apr 2022 10:28:53 +1000 Subject: [PATCH] fix up for "drm/ttm: rework bulk move handling v5" Signed-off-by: Stephen Rothwell <sfr(a)canb.auug.org.au> --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c index 958d7ed97882..a29933fa001f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c @@ -630,7 +630,14 @@ static void amdgpu_vm_pt_free(struct amdgpu_vm_bo_base *entry) if (!entry->bo) return; + shadow = amdgpu_bo_shadowed(entry->bo); + if (shadow) { + ttm_bo_set_bulk_move(&shadow->tbo, NULL); + amdgpu_bo_unref(&shadow); + } + + ttm_bo_set_bulk_move(&entry->bo->tbo, NULL); entry->bo->vm_bo = NULL; list_del(&entry->vm_status); amdgpu_bo_unref(&shadow); @@ -653,8 +660,6 @@ static void amdgpu_vm_pt_free_dfs(struct amdgpu_device *adev, struct amdgpu_vm_pt_cursor cursor; struct amdgpu_vm_bo_base *entry; - vm->bulk_moveable = false; - for_each_amdgpu_vm_pt_dfs_safe(adev, vm, start, cursor, entry) amdgpu_vm_pt_free(entry); -- 2.35.1 -- Cheers, Stephen Rothwell

2 3

[PULL] gvt-next-2022-04-29
by Wang, Zhi A 29 Apr '22

29 Apr '22

Hi folks: Here is the pull of gvt-next which fixes the compilation error and warnings for the the GVT-g refactor patches: - Fix a compiling warning of non-static function only having one caller. - Fix a potential NULL pointer reference in the code re-factor. - Fix a compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n I also tried to apply this pull on the latest drm-inte-next and it succeeded without error and warnings. The following changes since commit 5e9ae5c47052e28a31fb4f55a6e735c28d4c3948: drm/i915/gvt: Add missing symbol export. (2022-04-26 04:18:43 -0400) are available in the Git repository at: https://github.com/intel/gvt-linux tags/gvt-next-2022-04-29 for you to fetch changes up to 419f8299ddad6070a6c95aaedf78e50265871f36: i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers (2022-04-28 17:06:02 -0400) ---------------------------------------------------------------- gvt-next-2022-04-29 Introduce fixes from previous pull. - Fix a compiling warning of non-static funtion only having one caller. - Fix a potential NULL pointer reference in the code re-factor. - Fix a compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n ---------------------------------------------------------------- Wan Jiabing (1): i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers Zhi Wang (2): drm/i915/gvt: Make intel_gvt_match_device() static drm/i915/gvt: Fix the compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n drivers/gpu/drm/i915/gvt/handlers.c | 4 ++-- drivers/gpu/drm/i915/intel_gvt.c | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-)

2 1

[PATCH] omapdss: HDMI: simplify the return expression of hdmi_init_pll_data()
by cgel.zte＠gmail.com 29 Apr '22

29 Apr '22

From: Minghao Chi <chi.minghao(a)zte.com.cn> Simplify the return expression. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao(a)zte.com.cn> --- drivers/gpu/drm/omapdrm/dss/hdmi_pll.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c b/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c index eea719243eaf..10c6b3e492d3 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c @@ -131,7 +131,6 @@ static int hdmi_init_pll_data(struct dss_device *dss, { struct dss_pll *pll = &hpll->pll; struct clk *clk; - int r; clk = devm_clk_get(&pdev->dev, "sys_clk"); if (IS_ERR(clk)) { @@ -151,11 +150,7 @@ static int hdmi_init_pll_data(struct dss_device *dss, pll->ops = &hdmi_pll_ops; - r = dss_pll_register(dss, pll); - if (r) - return r; - - return 0; + return dss_pll_register(dss, pll); } int hdmi_pll_init(struct dss_device *dss, struct platform_device *pdev, -- 2.25.1

2 1

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022