dri-devel July 2020

dri-devel@lists.freedesktop.org

336 participants
772 discussions

[XDC 2020] Virtual conference + Call for Proposals extended 2 weeks more
by Samuel Iglesias Gonsálvez 20 Jul '20

20 Jul '20

Hi, In the last meeting, X.Org Foundation board has decided that XDC 2020 will be a virtual conference, given the uncertain COVID-19 situation in Europe by September, including the possibility of a second wave, outbreaks and travel restrictions, either in Poland or in other countries. XDC 2020 organization team agrees on this decision and it volunteered to organize our first virtual XDC! We would like to announce as well that the new CFP deadline is Sunday July 19th 2020. Don't forget to submit your talk, demo and workshop proposals! Thanks, Sam

1 2

[PATCH for v5.9] video: fbdev: Replace HTTP links with HTTPS ones
by Alexander A. Klimov 20 Jul '20

20 Jul '20

Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster(a)al2klimov.de> --- Continuing my work started at 93431e0607e5. See also: git log --oneline '--author=Alexander A. Klimov <grandmaster(a)al2klimov.de>' v5.7..master (Actually letting a shell for loop submit all this stuff for me.) If there are any URLs to be removed completely or at least not (just) HTTPSified: Just clearly say so and I'll *undo my change*. See also: https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See: https://lkml.org/lkml/2020/6/26/837 If you apply the patch, please let me know. Sorry again to all maintainers who complained about subject lines. Now I realized that you want an actually perfect prefixes, not just subsystem ones. I tried my best... And yes, *I could* (at least half-)automate it. Impossible is nothing! :) Documentation/fb/ep93xx-fb.rst | 2 +- drivers/video/fbdev/Kconfig | 8 ++++---- drivers/video/fbdev/core/fbmon.c | 4 ++-- drivers/video/fbdev/ep93xx-fb.c | 2 +- drivers/video/fbdev/grvga.c | 2 +- drivers/video/fbdev/macfb.c | 2 +- drivers/video/fbdev/metronomefb.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/Kconfig | 4 ++-- drivers/video/fbdev/omap2/omapfb/dss/hdmi.h | 2 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h | 2 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h | 2 +- drivers/video/fbdev/sa1100fb.c | 2 +- 14 files changed, 19 insertions(+), 19 deletions(-) diff --git a/Documentation/fb/ep93xx-fb.rst b/Documentation/fb/ep93xx-fb.rst index 6f7767926d1a..1dd67f4688c7 100644 --- a/Documentation/fb/ep93xx-fb.rst +++ b/Documentation/fb/ep93xx-fb.rst @@ -127,7 +127,7 @@ At least on the EP9315 there is a silicon bug which causes bit 27 of the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is an unofficial errata for this bug at:: - http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 + https://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 By default the EP93xx framebuffer driver checks if the allocated physical address has bit 27 set. If it does, then the memory is freed and an diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 0f559aeaf469..f12e390941b8 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -844,7 +844,7 @@ config FB_OPENCORES systems (e.g. Altera socfpga or Xilinx Zynq) on FPGAs. The source code and specification for the core is available at - <http://opencores.org/project,vga_lcd> + <https://opencores.org/project,vga_lcd> config FB_S1D13XXX tristate "Epson S1D13XXX framebuffer support" @@ -855,7 +855,7 @@ config FB_S1D13XXX help Support for S1D13XXX framebuffer device family (currently only working with S1D13806). Product specs at - <http://vdc.epson.com/> + <https://vdc.epson.com/> config FB_ATMEL tristate "AT91 LCD Controller support" @@ -1213,7 +1213,7 @@ config FB_RADEON don't need to choose this to run the Radeon in plain VGA mode. There is a product page at - http://products.amd.com/en-us/GraphicCardResult.aspx + https://products.amd.com/en-us/GraphicCardResult.aspx config FB_RADEON_I2C bool "DDC/I2C for ATI Radeon support" @@ -1381,7 +1381,7 @@ config FB_SIS help This is the frame buffer device driver for the SiS 300, 315, 330 and 340 series as well as XGI V3XT, V5, V8, Z7 graphics chipsets. - Specs available at <http://www.sis.com> and <http://www.xgitech.com>. + Specs available at <https://www.sis.com> and <http://www.xgitech.com>. To compile this driver as a module, choose M here; the module will be called sisfb. diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c index d62a1e43864e..1bf82dbc9e3c 100644 --- a/drivers/video/fbdev/core/fbmon.c +++ b/drivers/video/fbdev/core/fbmon.c @@ -19,7 +19,7 @@ * Generalized Timing Formula is derived from: * * GTF Spreadsheet by Andy Morrish (1/5/97) - * available at http://www.vesa.org + * available at https://www.vesa.org * * This file is subject to the terms and conditions of the GNU General Public * License. See the file COPYING in the main directory of this archive @@ -1201,7 +1201,7 @@ static void fb_timings_dclk(struct __fb_timings *timings) * ignored and @var will be filled with the calculated timings. * * All calculations are based on the VESA GTF Spreadsheet - * available at VESA's public ftp (http://www.vesa.org). + * available at VESA's public ftp (https://www.vesa.org). * * NOTES: * The timings generated by the GTF will be different from VESA diff --git a/drivers/video/fbdev/ep93xx-fb.c b/drivers/video/fbdev/ep93xx-fb.c index cda2ef337423..ba33b4dce0df 100644 --- a/drivers/video/fbdev/ep93xx-fb.c +++ b/drivers/video/fbdev/ep93xx-fb.c @@ -430,7 +430,7 @@ static int ep93xxfb_alloc_videomem(struct fb_info *info) /* * There is a bug in the ep93xx framebuffer which causes problems * if bit 27 of the physical address is set. - * See: http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 + * See: https://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 * There does not seem to be any official errata for this, but I * have confirmed the problem exists on my hardware (ep9315) at * least. diff --git a/drivers/video/fbdev/grvga.c b/drivers/video/fbdev/grvga.c index 07dda03e0957..24818b276241 100644 --- a/drivers/video/fbdev/grvga.c +++ b/drivers/video/fbdev/grvga.c @@ -5,7 +5,7 @@ * 2011 (c) Aeroflex Gaisler AB * * Full documentation of the core can be found here: - * http://www.gaisler.com/products/grlib/grip.pdf + * https://www.gaisler.com/products/grlib/grip.pdf * * Contributors: Kristoffer Glembo <kristoffer(a)gaisler.com> */ diff --git a/drivers/video/fbdev/macfb.c b/drivers/video/fbdev/macfb.c index e05a97662ca8..312e35c9aa6c 100644 --- a/drivers/video/fbdev/macfb.c +++ b/drivers/video/fbdev/macfb.c @@ -478,7 +478,7 @@ static int macfb_setcolreg(unsigned regno, unsigned red, unsigned green, break; /* * 24-bit colour almost doesn't exist on 68k Macs -- - * http://support.apple.com/kb/TA28634 (Old Article: 10992) + * https://support.apple.com/kb/TA28634 (Old Article: 10992) */ case 24: case 32: diff --git a/drivers/video/fbdev/metronomefb.c b/drivers/video/fbdev/metronomefb.c index a42e2eceee48..952826557a0c 100644 --- a/drivers/video/fbdev/metronomefb.c +++ b/drivers/video/fbdev/metronomefb.c @@ -10,7 +10,7 @@ * Layout is based on skeletonfb.c by James Simmons and Geert Uytterhoeven. * * This work was made possible by help and equipment support from E-Ink - * Corporation. http://www.eink.com/ + * Corporation. https://www.eink.com/ * * This driver is written to be used with the Metronome display controller. * It is intended to be architecture independent. A board specific driver diff --git a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig index 36b97fee2d57..cc81a19537d2 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig +++ b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig @@ -60,7 +60,7 @@ config FB_OMAP5_DSS_HDMI select FB_OMAP2_DSS_HDMI_COMMON help HDMI Interface for OMAP5 and similar cores. This adds the High - Definition Multimedia Interface. See http://www.hdmi.org/ for HDMI + Definition Multimedia Interface. See https://www.hdmi.org/ for HDMI specification. config FB_OMAP2_DSS_SDI @@ -79,7 +79,7 @@ config FB_OMAP2_DSS_DSI DSI is a high speed half-duplex serial interface between the host processor and a peripheral, such as a display or a framebuffer chip. - See http://www.mipi.org/ for DSI specifications. + See https://www.mipi.org/ for DSI specifications. config FB_OMAP2_DSS_MIN_FCK_PER_PCK int "Minimum FCK/PCK ratio (for scaling)" diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi.h b/drivers/video/fbdev/omap2/omapfb/dss/hdmi.h index b9d4480ecfad..9a7253355f6d 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi.h @@ -2,7 +2,7 @@ /* * HDMI driver definition for TI OMAP4 Processor. * - * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/ + * Copyright (C) 2010-2011 Texas Instruments Incorporated - https://www.ti.com/ */ #ifndef _HDMI_H diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c index 7060ae56c062..63262ec06921 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-only /* * HDMI interface DSS driver for TI's OMAP4 family of SoCs. - * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/ + * Copyright (C) 2010-2011 Texas Instruments Incorporated - https://www.ti.com/ * Authors: Yong Zhi * Mythri pk <mythripk(a)ti.com> */ diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c index 6b79b52d5fad..7ca1803bf161 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c @@ -3,7 +3,7 @@ * ti_hdmi_4xxx_ip.c * * HDMI TI81xx, TI38xx, TI OMAP4 etc IP driver Library - * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/ + * Copyright (C) 2010-2011 Texas Instruments Incorporated - https://www.ti.com/ * Authors: Yong Zhi * Mythri pk <mythripk(a)ti.com> */ diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h index f066d1f69132..b5c35277f06e 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h @@ -2,7 +2,7 @@ /* * HDMI header definition for OMAP4 HDMI core IP * - * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/ + * Copyright (C) 2010-2011 Texas Instruments Incorporated - https://www.ti.com/ */ #ifndef _HDMI4_CORE_H_ diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h index f10b8a283011..192c9b6e2f7b 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h @@ -2,7 +2,7 @@ /* * HDMI driver definition for TI OMAP5 processors. * - * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * Copyright (C) 2011-2012 Texas Instruments Incorporated - https://www.ti.com/ */ #ifndef _HDMI5_CORE_H_ diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c index 3e6e13f7a831..bda6cc313c8b 100644 --- a/drivers/video/fbdev/sa1100fb.c +++ b/drivers/video/fbdev/sa1100fb.c @@ -18,7 +18,7 @@ * Clean patches should be sent to the ARM Linux Patch System. Please see the * following web page for more information: * - * http://www.arm.linux.org.uk/developer/patches/info.shtml + * https://www.arm.linux.org.uk/developer/patches/info.shtml * * Thank you. * -- 2.27.0

2 1

[PATCH v2] drm: core: Convert device logging to drm_* functions.
by Suraj Upadhyay 20 Jul '20

20 Jul '20

Convert device logging with dev_* functions into drm_* functions. The patch has been generated with the coccinelle script below. The script focuses on instances of dev_* functions where the drm device context is clearly visible in its arguments. @@expression E1; expression list E2; @@ -dev_warn(E1->dev, E2) +drm_warn(E1, E2) @@expression E1; expression list E2; @@ -dev_info(E1->dev, E2) +drm_info(E1, E2) @@expression E1; expression list E2; @@ -dev_err(E1->dev, E2) +drm_err(E1, E2) @@expression E1; expression list E2; @@ -dev_info_once(E1->dev, E2) +drm_info_once(E1, E2) @@expression E1; expression list E2; @@ -dev_notice_once(E1->dev, E2) +drm_notice_once(E1, E2) @@expression E1; expression list E2; @@ -dev_warn_once(E1->dev, E2) +drm_warn_once(E1, E2) @@expression E1; expression list E2; @@ -dev_err_once(E1->dev, E2) +drm_err_once(E1, E2) @@expression E1; expression list E2; @@ -dev_err_ratelimited(E1->dev, E2) +drm_err_ratelimited(E1, E2) @@expression E1; expression list E2; @@ -dev_dbg(E1->dev, E2) +drm_dbg(E1, E2) Signed-off-by: Suraj Upadhyay <usuraj35(a)gmail.com> --- Changes: v2: Fixed error in coccinelle script and diff, i.e. removed the underscore. drv_dbg_ -> drm_dbg drivers/gpu/drm/drm_edid.c | 6 ++---- drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++-- drivers/gpu/drm/drm_mipi_dbi.c | 7 +++---- 3 files changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 52b357e75c3d..6840f0530a38 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1844,9 +1844,7 @@ static void connector_bad_edid(struct drm_connector *connector, if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS)) return; - dev_warn(connector->dev->dev, - "%s: EDID is invalid:\n", - connector->name); + drm_warn(connector->dev, "%s: EDID is invalid:\n", connector->name); for (i = 0; i < num_blocks; i++) { u8 *block = edid + i * EDID_LENGTH; char prefix[20]; @@ -5298,7 +5296,7 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) } if (!drm_edid_is_valid(edid)) { clear_eld(connector); - dev_warn(connector->dev->dev, "%s: EDID invalid.\n", + drm_warn(connector->dev, "%s: EDID invalid.\n", connector->name); return 0; } diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index 06a5b9ee1fe0..822edeadbab3 100644 --- a/drivers/gpu/drm/drm_gem_cma_helper.c +++ b/drivers/gpu/drm/drm_gem_cma_helper.c @@ -105,8 +105,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm, cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN); if (!cma_obj->vaddr) { - dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n", - size); + drm_dbg(drm, "failed to allocate buffer with size %zu\n", + size); ret = -ENOMEM; goto error; } diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c index 0e55d8716e3d..a7a611894243 100644 --- a/drivers/gpu/drm/drm_mipi_dbi.c +++ b/drivers/gpu/drm/drm_mipi_dbi.c @@ -225,9 +225,8 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb, drm_fb_xrgb8888_to_rgb565(dst, src, fb, clip, swap); break; default: - dev_err_once(fb->dev->dev, "Format is not supported: %s\n", - drm_get_format_name(fb->format->format, - &format_name)); + drm_err_once(fb->dev, "Format is not supported: %s\n", + drm_get_format_name(fb->format->format, &format_name)); return -EINVAL; } @@ -295,7 +294,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, struct drm_rect *rect) width * height * 2); err_msg: if (ret) - dev_err_once(fb->dev->dev, "Failed to update display %d\n", ret); + drm_err_once(fb->dev, "Failed to update display %d\n", ret); drm_dev_exit(idx); } -- 2.17.1

2 1

[PATCH v2 0/6] drm/ast: Managed MM
by Thomas Zimmermann 20 Jul '20

20 Jul '20

This is the second patchset for converting ast to managed DRM interfaces. This one addresses memory management. There will be another, final round of patches for converting DRM device structures as well. Patch #1 introduces managed initialization for VRAM MM. Other drivers using the VRAM helpers should be converted to this at some point. Patches #2 to #4 do some preparation that make ast look slightly nicer. Patch #5 fixes a long-standing bug that I found as part of the rework. Posting the GPU requires information about the installed DRAM. So the DRAM detection has to run before the GPU-posting code. This got reversed by a fix in v4.11. The patch restores the original correct order of these operations. As the GPU is usually posted by the VGA BIOS, the problem might not have shown up in practice. With all the cleanups in place, patch #6 switches memory management to mnaged interfaces. Tested on AST2100 HW. v2: * reworked managed VRAM MM; new interface name, returns errno code, improved documentation (Sam) Thomas Zimmermann (6): drm/vram-helper: Managed vram helpers drm/ast: Rename ast_ttm.c to ast_mm.c drm/ast: Use managed VRAM-helper initialization drm/ast: Move VRAM size detection to ast_mm.c drm/ast: Initialize DRAM type before posting GPU drm/ast: Use managed MM initialization drivers/gpu/drm/ast/Makefile | 2 +- drivers/gpu/drm/ast/ast_drv.h | 2 - drivers/gpu/drm/ast/ast_main.c | 45 ++--------- drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} | 77 ++++++++++++++----- drivers/gpu/drm/drm_gem_vram_helper.c | 84 ++++++++++++--------- include/drm/drm_gem_vram_helper.h | 3 + 6 files changed, 115 insertions(+), 98 deletions(-) rename drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} (63%) -- 2.27.0

2 8

[PATCH] drm/i810: switch from 'pci_' to 'dma_' API
by Christophe JAILLET 20 Jul '20

20 Jul '20

The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'i810_dma_initialize()' GFP_KERNEL can be used because its only caller, 'i810_dma_init()', already use it and no lock is taken in the between. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- If needed, see post from Christoph Hellwig on the kernel-janitors ML: https://marc.info/?l=kernel-janitors&m=158745678307186&w=4 --- drivers/gpu/drm/i810/i810_dma.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c index b88c3d5f92b4..303c2d483c6e 100644 --- a/drivers/gpu/drm/i810/i810_dma.c +++ b/drivers/gpu/drm/i810/i810_dma.c @@ -220,9 +220,9 @@ static int i810_dma_cleanup(struct drm_device *dev) if (dev_priv->ring.virtual_start) drm_legacy_ioremapfree(&dev_priv->ring.map, dev); if (dev_priv->hw_status_page) { - pci_free_consistent(dev->pdev, PAGE_SIZE, - dev_priv->hw_status_page, - dev_priv->dma_status_page); + dma_free_coherent(&dev->pdev->dev, PAGE_SIZE, + dev_priv->hw_status_page, + dev_priv->dma_status_page); } kfree(dev->dev_private); dev->dev_private = NULL; @@ -398,8 +398,8 @@ static int i810_dma_initialize(struct drm_device *dev, /* Program Hardware Status Page */ dev_priv->hw_status_page = - pci_zalloc_consistent(dev->pdev, PAGE_SIZE, - &dev_priv->dma_status_page); + dma_alloc_coherent(&dev->pdev->dev, PAGE_SIZE, + &dev_priv->dma_status_page, GFP_KERNEL); if (!dev_priv->hw_status_page) { dev->dev_private = (void *)dev_priv; i810_dma_cleanup(dev); -- 2.25.1

2 1

[PATCH] drm/lima: fix wait pp reset timeout
by Qiang Yu 20 Jul '20

20 Jul '20

PP bcast is marked as doing async reset after job is done. When resume after suspend, each PP is reset individually, so no need to reset in PP bcast resume. But I forgot to clear the PP bcast async reset mark so call into async wait before job run and gets timeout. Fixes: 3446d7e9883d ("drm/lima: add resume/suspend callback for each ip") Signed-off-by: Qiang Yu <yuq825(a)gmail.com> --- drivers/gpu/drm/lima/lima_pp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/lima/lima_pp.c b/drivers/gpu/drm/lima/lima_pp.c index 33f01383409c..a5c95bed08c0 100644 --- a/drivers/gpu/drm/lima/lima_pp.c +++ b/drivers/gpu/drm/lima/lima_pp.c @@ -271,6 +271,8 @@ void lima_pp_fini(struct lima_ip *ip) int lima_pp_bcast_resume(struct lima_ip *ip) { + /* PP has been reset by individual PP resume */ + ip->data.async_reset = false; return 0; } -- 2.25.1

2 2

[PATCH] drm/nouveau: Accept 'legacy' format modifiers
by James Jones 19 Jul '20

19 Jul '20

Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Tested with Xorg 1.20 modesetting driver, weston@c46c70dac84a4b3030cd05b380f9f410536690fc, gnome & KDE wayland desktops from Ubuntu 18.04, and sway 1.5 Signed-off-by: James Jones <jajones(a)nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 26 +++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 496c4621cc78..31543086254b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm, uint32_t *tile_mode, uint8_t *kind) { + struct nouveau_display *disp = nouveau_display(drm->dev); BUG_ON(!tile_mode || !kind); + if ((modifier & (0xffull << 12)) == 0ull) { + /* Legacy modifier. Translate to this device's 'kind.' */ + modifier |= disp->format_modifiers[0] & (0xffull << 12); + } + if (modifier == DRM_FORMAT_MOD_LINEAR) { /* tile_mode will not be used in this case */ *tile_mode = 0; @@ -227,6 +233,16 @@ nouveau_framebuffer_get_layout(struct drm_framebuffer *fb, } } +static const u64 legacy_modifiers[] = { + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0), + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1), + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2), + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3), + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4), + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5), + DRM_FORMAT_MOD_INVALID +}; + static int nouveau_validate_decode_mod(struct nouveau_drm *drm, uint64_t modifier, @@ -247,8 +263,14 @@ nouveau_validate_decode_mod(struct nouveau_drm *drm, (disp->format_modifiers[mod] != modifier); mod++); - if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID) - return -EINVAL; + if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID) { + for (mod = 0; + (legacy_modifiers[mod] != DRM_FORMAT_MOD_INVALID) && + (legacy_modifiers[mod] != modifier); + mod++); + if (legacy_modifiers[mod] == DRM_FORMAT_MOD_INVALID) + return -EINVAL; + } nouveau_decode_mod(drm, modifier, tile_mode, kind); -- 2.17.1

3 7

[PATCH for v5.9] drm: Replace HTTP links with HTTPS ones
by Alexander A. Klimov 19 Jul '20

19 Jul '20

1 0

[Bug 208611] New: amdgpu crash on sharing image memory between Vulkan and OpenGL
by bugzilla-daemon＠bugzilla.kernel.org 19 Jul '20

19 Jul '20

https://bugzilla.kernel.org/show_bug.cgi?id=208611 Bug ID: 208611 Summary: amdgpu crash on sharing image memory between Vulkan and OpenGL Product: Drivers Version: 2.5 Kernel Version: 5.7.8-200.fc32.x86_64 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: yalterz(a)gmail.com Regression: No Created attachment 290347 --> https://bugzilla.kernel.org/attachment.cgi?id=290347&action=edit The kernel crash part of the log. I have two programs: one (Vulkan) creates an image, allocates memory for it and exports the memory as an fd. The second program (OpenGL) receives the fd, imports it as a memory for a texture, and blits some data into the texture. The Vulkan program subsequently maps the memory and reads pixel values from it. Both programs follow the code of this ANGLE test for Vulkan-OpenGL interop very closely: https://github.com/pmatos/WebKit/blob/c42c49d3859ceb5d6e5c502373c8d3e371662… It works fine with VK_FORMAT_R8G8B8A8_UNORM, but after changing it to R8G8B8_UNORM (without the alpha) in (I'm fairly certain) all respective places, I got corrupt image data on one run and a kernel crash on another run. Here are some excerpts from the log: amdgpu 0000:01:00.0: GPU fault detected: 146 0x0f20880c for process vulkan-external pid 173502 thread vulkan-external pid 173502 amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001005E4 amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0608800C amdgpu 0000:01:00.0: VM fault (0x0c, vmid 3, pasid 32784) at page 1050084, read from 'TC6' (0x54433600) (136) amdgpu 0000:01:00.0: IH ring buffer overflow (0x0008AF70, 0x00006660, 0x0000AF80) [drm] Fence fallback timer expired on ring sdma0 gmc_v8_0_process_interrupt: 305 callbacks suppressed amdgpu 0000:01:00.0: GPU fault detected: 146 0x0e20480c for process vulkan-external pid 174193 thread vulkan-external pid 174193 amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001005C4 amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A04800C amdgpu 0000:01:00.0: VM fault (0x0c, vmid 5, pasid 32784) at page 1050052, read from 'TC4' (0x54433400) (72) [drm] Fence fallback timer expired on ring sdma0 [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:49:crtc-1] flip_done timed out Full last part of the log attached. AMD RX 580, running Fedora 32 with GNOME Wayland. -- You are receiving this mail because: You are watching the assignee of the bug.

1 2

[PATCH] drm: hold gem reference until object is no longer accessed
by Steve Cohen 19 Jul '20

19 Jul '20

BUG: KASAN: use-after-free in drm_gem_open_ioctl There is potential for use-after-free here if the GEM object handle is closed between the idr lookup and retrieving the size from the object since a local reference is not being held at that point. Hold the local reference while the object can still be accessed to resolve this. Signed-off-by: Steve Cohen <cohens(a)codeaurora.org> --- drivers/gpu/drm/drm_gem.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 7bf628e..4b2891c 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -898,14 +898,15 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data, /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */ ret = drm_gem_handle_create_tail(file_priv, obj, &handle); - drm_gem_object_put_unlocked(obj); if (ret) - return ret; + goto out; args->handle = handle; args->size = obj->size; - return 0; +out: + drm_gem_object_put_unlocked(obj); + return ret; } /** -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 2

← Newer
1
...
43
44
45
46
47
48
49
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2020