dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH v2 0/7] Add support to the mmsys driver to be a reset controller
by Enric Balletbo i Serra 06 Aug '21

06 Aug '21

Dear all, The following patchset is a reimplementation of the patch sent by Jitao Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the reset is done using the reset API, where the mmsys driver is the reset controller and the mtk_dsi driver is the reset consumer. Note that the first patch is kind of unrelated change, it's just a cleanup but is needed if you want to apply all the following patches cleanly. This patchset is important in order to have the DSI panel working on some kukui MT8183 Chromebooks (i.e Lenovo IdeaPad Duet). Without it, you just get a black screen. Best regards, Enric [1] https://lore.kernel.org/linux-arm-kernel/20210420132614.150242-4-jitao.shi@… Changes in v2: - Fix build test ERROR Reported-by: kernel test robot <lkp(a)intel.com> - Added a new patch to describe the dsi reset optional property. Enric Balletbo i Serra (7): arm64: dts: mediatek: Move reset controller constants into common location dt-bindings: mediatek: Add #reset-cells to mmsys system controller dt-bindings: display: mediatek: add dsi reset optional property arm64: dts: mt8173: Add the mmsys reset bit to reset the dsi0 arm64: dts: mt8183: Add the mmsys reset bit to reset the dsi0 soc: mediatek: mmsys: Add reset controller support drm/mediatek: mtk_dsi: Reset the dsi0 hardware .../bindings/arm/mediatek/mediatek,mmsys.txt | 2 + .../display/mediatek/mediatek,dsi.txt | 6 ++ arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 5 +- drivers/gpu/drm/mediatek/mtk_dsi.c | 5 +- drivers/soc/mediatek/mtk-mmsys.c | 69 +++++++++++++++++++ drivers/soc/mediatek/mtk-mmsys.h | 2 + drivers/watchdog/mtk_wdt.c | 6 +- .../mt2712-resets.h | 0 include/dt-bindings/reset/mt8173-resets.h | 2 + .../mt8183-resets.h | 3 + .../mt8192-resets.h | 0 12 files changed, 96 insertions(+), 6 deletions(-) rename include/dt-bindings/{reset-controller => reset}/mt2712-resets.h (100%) rename include/dt-bindings/{reset-controller => reset}/mt8183-resets.h (98%) rename include/dt-bindings/{reset-controller => reset}/mt8192-resets.h (100%) -- 2.30.2

4 5

[V2][PATCH] drm: xlnx: zynqmp: release reset to DP controller before accessing DP registers
by quanyang.wang＠windriver.com 06 Aug '21

06 Aug '21

From: Quanyang Wang <quanyang.wang(a)windriver.com> When insmod zynqmp-dpsub.ko after rmmod it, system will hang with the error log as below: root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko [ 88.391289] [drm] Initialized zynqmp-dpsub 1.0.0 20130509 for fd4a0000.display on minor 0 [ 88.529906] Console: switching to colour frame buffer device 128x48 [ 88.549402] zynqmp-dpsub fd4a0000.display: [drm] fb0: zynqmp-dpsubdrm frame buffer device [ 88.571624] zynqmp-dpsub fd4a0000.display: ZynqMP DisplayPort Subsystem driver probed root@xilinx-zynqmp:~# rmmod zynqmp_dpsub [ 94.023404] Console: switching to colour dummy device 80x25 root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko <hang here> This is because that in zynqmp_dp_probe it tries to access some DP registers while the DP controller is still in the reset state. When running "rmmod zynqmp_dpsub", zynqmp_dp_reset(dp, true) in zynqmp_dp_phy_exit is called to force the DP controller into the reset state. Then insmod will call zynqmp_dp_probe to program the DP registers, but at this moment the DP controller hasn't been brought out of the reset state yet since the function zynqmp_dp_reset(dp, false) is called later and this will result the system hang. Releasing the reset to DP controller before any read/write operation to it will fix this issue. And for symmetry, move zynqmp_dp_reset() call from zynqmp_dp_phy_exit() to zynqmp_dp_remove(). Signed-off-by: Quanyang Wang <quanyang.wang(a)windriver.com> --- V2: According to Laurent's comments: - add zynqmp_dp_reset(dp, true) in error path in zynqmp_dp_probe - move the zynqmp_dp_reset() call from zynqmp_dp_phy_exit() to zynqmp_dp_remove() --- drivers/gpu/drm/xlnx/zynqmp_dp.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c index 99158ee67d02..337adf0769ad 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c @@ -402,10 +402,6 @@ static int zynqmp_dp_phy_init(struct zynqmp_dp *dp) } } - ret = zynqmp_dp_reset(dp, false); - if (ret < 0) - return ret; - zynqmp_dp_clr(dp, ZYNQMP_DP_PHY_RESET, ZYNQMP_DP_PHY_RESET_ALL_RESET); /* @@ -441,8 +437,6 @@ static void zynqmp_dp_phy_exit(struct zynqmp_dp *dp) ret); } - zynqmp_dp_reset(dp, true); - for (i = 0; i < dp->num_lanes; i++) { ret = phy_exit(dp->phy[i]); if (ret) @@ -1682,9 +1676,13 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct drm_device *drm) return PTR_ERR(dp->reset); } + ret = zynqmp_dp_reset(dp, false); + if (ret < 0) + return ret; + ret = zynqmp_dp_phy_probe(dp); if (ret) - return ret; + goto err_reset; /* Initialize the hardware. */ zynqmp_dp_write(dp, ZYNQMP_DP_TX_PHY_POWER_DOWN, @@ -1696,7 +1694,7 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct drm_device *drm) ret = zynqmp_dp_phy_init(dp); if (ret) - return ret; + goto err_reset; zynqmp_dp_write(dp, ZYNQMP_DP_TRANSMITTER_ENABLE, 1); @@ -1708,15 +1706,18 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct drm_device *drm) zynqmp_dp_irq_handler, IRQF_ONESHOT, dev_name(dp->dev), dp); if (ret < 0) - goto error; + goto err_phy_exit; dev_dbg(dp->dev, "ZynqMP DisplayPort Tx probed with %u lanes\n", dp->num_lanes); return 0; -error: +err_phy_exit: zynqmp_dp_phy_exit(dp); +err_reset: + zynqmp_dp_reset(dp, true); + return ret; } @@ -1734,4 +1735,5 @@ void zynqmp_dp_remove(struct zynqmp_dpsub *dpsub) zynqmp_dp_write(dp, ZYNQMP_DP_INT_DS, 0xffffffff); zynqmp_dp_phy_exit(dp); + zynqmp_dp_reset(dp, true); } -- 2.25.1

3 3

[PATCH v3 00/14] Provide core infrastructure for managing open/release
by Jason Gunthorpe 05 Aug '21

05 Aug '21

This is in support of Max's series to split vfio-pci. For that to work the reflck concept embedded in vfio-pci needs to be sharable across all of the new VFIO PCI drivers which motivated re-examining how this is implemented. Another significant issue is how the VFIO PCI core includes code like: if (pci_dev_driver(pdev) != &vfio_pci_driver) Which is not scalable if there are going to be multiple different driver types. This series takes the approach of moving the "reflck" mechanism into the core code as a "device set". Each vfio_device driver can specify how vfio_devices are grouped into the set using a key and the set comes along with a set-global mutex. The core code manages creating per-device set memory and associating it with each vfio_device. In turn this allows the core code to provide an open/close_device() operation that is called only for the first/last FD, and is called under the global device set lock. Review of all the drivers show that they are either already open coding the first/last semantic or are buggy and missing it. All drivers are migrated/fixed to the new open/close_device ops and the unused per-FD open()/release() ops are deleted. The special behavior of PCI around the bus/slot "reset group" is recast in terms of the device set which conslidates the reflck, eliminates two touches of pci_dev_driver(), and allows the reset mechanism to share across all VFIO PCI drivers. PCI is changed to acquire devices directly from the device set instead of trying to work backwards from the struct pci_device. Overall a few minor bugs are squashed and quite a bit of code is removed through consolidation. v3: - Atomic conversion of mbochs_used_mbytes - Add missing vfio_uninit_group_dev in error unwind of mbochs - Reorganize vfio_assign_device_set() - Move the dev_set_list hunks to the introduction of the dev_set - Use if instead of ?: in fsl - Add a comment about the whole bus reset in vfio_pci_probe() - Rename vfio_pci_check_all_devices_bound() to vfio_pci_is_device_in_set() - Move logic from vfio_pci_try_bus_reset() into vfio_pci_find_reset_target() v2: https://lore.kernel.org/r/0-v2-b6a5582525c9+ff96-vfio_reflck_jgg@nvidia.com - Reorder fsl and mbochs vfio_uninit_group_dev - Fix missing error unwind in mbochs - Return 0 from mdev open_device if there is no op - Fix style for else {} - Spelling fix for singleton - Acquire cur_mem under lock - Always use error unwind flow for vfio_pci_check_all_devices_bound() v1: https://lore.kernel.org/r/0-v1-eaf3ccbba33c+1add0-vfio_reflck_jgg@nvidia.com Jason Gunthorpe (12): vfio/samples: Remove module get/put vfio/mbochs: Fix missing error unwind of mbochs_used_mbytes vfio: Provide better generic support for open/release vfio_device_ops vfio/samples: Delete useless open/close vfio/fsl: Move to the device set infrastructure vfio/platform: Use open_device() instead of open coding a refcnt scheme vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set vfio/pci: Reorganize VFIO_DEVICE_PCI_HOT_RESET to use the device set vfio/mbochs: Fix close when multiple device FDs are open vfio/ap,ccw: Fix open/close when multiple device FDs are open vfio/gvt: Fix open/close when multiple device FDs are open vfio: Remove struct vfio_device_ops open/release Max Gurtovoy (1): vfio: Introduce a vfio_uninit_group_dev() API call Yishai Hadas (1): vfio/pci: Move to the device set infrastructure Documentation/driver-api/vfio.rst | 4 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 8 +- drivers/s390/cio/vfio_ccw_ops.c | 8 +- drivers/s390/crypto/vfio_ap_ops.c | 8 +- drivers/vfio/fsl-mc/vfio_fsl_mc.c | 159 +----- drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c | 6 +- drivers/vfio/fsl-mc/vfio_fsl_mc_private.h | 7 - drivers/vfio/mdev/vfio_mdev.c | 31 +- drivers/vfio/pci/vfio_pci.c | 487 +++++++----------- drivers/vfio/pci/vfio_pci_private.h | 7 - drivers/vfio/platform/vfio_platform_common.c | 86 ++-- drivers/vfio/platform/vfio_platform_private.h | 1 - drivers/vfio/vfio.c | 144 +++++- include/linux/mdev.h | 9 +- include/linux/vfio.h | 26 +- samples/vfio-mdev/mbochs.c | 40 +- samples/vfio-mdev/mdpy.c | 40 +- samples/vfio-mdev/mtty.c | 40 +- 18 files changed, 468 insertions(+), 643 deletions(-) -- 2.32.0

4 23

[PATCH v5 0/6] Add Mediatek Soc DRM (vdosys0) support for mt8195
by jason-jh.lin 05 Aug '21

05 Aug '21

The hardware path of vdosys0 with eDP panel output need to go through by several modules, such as, OVL, RDMA, COLOR, CCORR, AAL, GAMMA, DITHER, DSC and MERGE. Change in v5: - add power-domain property into vdosys0 and vdosys1 dts node. - add MT8195 prifix and remove unused VDO1 define in mt8195-mmsys.h Change in v4: - extract dt-binding patches to another patch series https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597 - squash DSC module into mtk_drm_ddp_comp.c - add coment and simplify MERGE config function Change in v3: - change mmsys and display dt-bindings document from txt to yaml - add MERGE additional description in display dt-bindings document - fix mboxes-cells number of vdosys0 node in dts - drop mutex eof convert define - remove pm_runtime apis in DSC and MERGE - change DSC and MERGE enum to alphabetic order Change in v2: - add DSC yaml file - add mt8195 drm driver porting parts in to one patch - remove useless define, variable, structure member and function - simplify DSC and MERGE file and switch threre order jason-jh.lin (6): arm64: dts: mt8195: add display node for vdosys0 soc: mediatek: add mtk-mmsys support for mt8195 vdosys0 soc: mediatek: add mtk-mutex support for mt8195 vdosys0 drm/mediatek: add mediatek-drm of vdosys0 support for mt8195 drm/mediatek: add DSC support for mt8195 drm/mediatek: add MERGE support for mt8195 arch/arm64/boot/dts/mediatek/mt8195.dtsi | 112 ++++++++ drivers/gpu/drm/mediatek/Makefile | 1 + drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 + drivers/gpu/drm/mediatek/mtk_disp_merge.c | 277 ++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 62 +++++ drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 ++- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + drivers/soc/mediatek/mt8195-mmsys.h | 96 +++++++ drivers/soc/mediatek/mtk-mmsys.c | 11 + drivers/soc/mediatek/mtk-mutex.c | 93 ++++++- include/linux/soc/mediatek/mtk-mmsys.h | 9 + 13 files changed, 706 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_merge.c create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h -- 2.18.0

4 16

[PATCH] drm/aperture: Pass DRM driver structure instead of driver name
by Thomas Zimmermann 05 Aug '21

05 Aug '21

Print the name of the DRM driver when taking over fbdev devices. Makes the output to dmesg more consistent. Note that the driver name is only used for printing a string to the kernel log. No UAPI is affected by this change. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 2 +- drivers/gpu/drm/ast/ast_drv.c | 2 +- drivers/gpu/drm/bochs/bochs_drv.c | 2 +- drivers/gpu/drm/drm_aperture.c | 19 ++++++++++++------- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/meson/meson_drv.c | 2 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +- drivers/gpu/drm/msm/msm_fbdev.c | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- drivers/gpu/drm/qxl/qxl_drv.c | 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +- drivers/gpu/drm/tegra/drm.c | 2 +- drivers/gpu/drm/tiny/cirrus.c | 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +- drivers/gpu/drm/vc4/vc4_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- include/drm/drm_aperture.h | 14 +++++++++----- 23 files changed, 43 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 6f30c525caac..accf9c1b967a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -1278,7 +1278,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, #endif /* Get rid of things like offb */ - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "amdgpudrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &amdgpu_kms_driver); if (ret) return ret; diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c index dab0a1f0983b..31925ae3ab72 100644 --- a/drivers/gpu/drm/armada/armada_drv.c +++ b/drivers/gpu/drm/armada/armada_drv.c @@ -95,7 +95,7 @@ static int armada_drm_bind(struct device *dev) } /* Remove early framebuffers */ - ret = drm_aperture_remove_framebuffers(false, "armada-drm-fb"); + ret = drm_aperture_remove_framebuffers(false, &armada_drm_driver); if (ret) { dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n", __func__, ret); diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 5aa452b4efe6..86d5cd7b6318 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast/ast_drv.c @@ -100,7 +100,7 @@ static int ast_remove_conflicting_framebuffers(struct pci_dev *pdev) primary = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW; #endif - return drm_aperture_remove_conflicting_framebuffers(base, size, primary, "astdrmfb"); + return drm_aperture_remove_conflicting_framebuffers(base, size, primary, &ast_driver); } static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) diff --git a/drivers/gpu/drm/bochs/bochs_drv.c b/drivers/gpu/drm/bochs/bochs_drv.c index c828cadbabff..0d232b44ecd7 100644 --- a/drivers/gpu/drm/bochs/bochs_drv.c +++ b/drivers/gpu/drm/bochs/bochs_drv.c @@ -110,7 +110,7 @@ static int bochs_pci_probe(struct pci_dev *pdev, return -ENOMEM; } - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "bochsdrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &bochs_driver); if (ret) return ret; diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c index 9335d9d6cf9a..9ac39cf11694 100644 --- a/drivers/gpu/drm/drm_aperture.c +++ b/drivers/gpu/drm/drm_aperture.c @@ -33,6 +33,10 @@ * * .. code-block:: c * + * static const struct drm_driver example_driver = { + * ... + * }; + * * static int remove_conflicting_framebuffers(struct pci_dev *pdev) * { * bool primary = false; @@ -46,7 +50,7 @@ * #endif * * return drm_aperture_remove_conflicting_framebuffers(base, size, primary, - * "example driver"); + * &example_driver); * } * * static int probe(struct pci_dev *pdev) @@ -274,7 +278,7 @@ static void drm_aperture_detach_drivers(resource_size_t base, resource_size_t si * @base: the aperture's base address in physical memory * @size: aperture size in bytes * @primary: also kick vga16fb if present - * @name: requesting driver name + * @req_driver: requesting DRM driver * * This function removes graphics device drivers which use memory range described by * @base and @size. @@ -283,7 +287,7 @@ static void drm_aperture_detach_drivers(resource_size_t base, resource_size_t si * 0 on success, or a negative errno code otherwise */ int drm_aperture_remove_conflicting_framebuffers(resource_size_t base, resource_size_t size, - bool primary, const char *name) + bool primary, const struct drm_driver *req_driver) { #if IS_REACHABLE(CONFIG_FB) struct apertures_struct *a; @@ -296,7 +300,7 @@ int drm_aperture_remove_conflicting_framebuffers(resource_size_t base, resource_ a->ranges[0].base = base; a->ranges[0].size = size; - ret = remove_conflicting_framebuffers(a, name, primary); + ret = remove_conflicting_framebuffers(a, req_driver->name, primary); kfree(a); if (ret) @@ -312,7 +316,7 @@ EXPORT_SYMBOL(drm_aperture_remove_conflicting_framebuffers); /** * drm_aperture_remove_conflicting_pci_framebuffers - remove existing framebuffers for PCI devices * @pdev: PCI device - * @name: requesting driver name + * @req_driver: requesting DRM driver * * This function removes graphics device drivers using memory range configured * for any of @pdev's memory bars. The function assumes that PCI device with @@ -321,7 +325,8 @@ EXPORT_SYMBOL(drm_aperture_remove_conflicting_framebuffers); * Returns: * 0 on success, or a negative errno code otherwise */ -int drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const char *name) +int drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev, + const struct drm_driver *req_driver) { resource_size_t base, size; int bar, ret = 0; @@ -339,7 +344,7 @@ int drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const * otherwise the vga fbdev driver falls over. */ #if IS_REACHABLE(CONFIG_FB) - ret = remove_conflicting_pci_framebuffers(pdev, name); + ret = remove_conflicting_pci_framebuffers(pdev, req_driver->name); #endif if (ret == 0) ret = vga_remove_vgacon(pdev); diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c index f4bc5386574a..6f0297b854f2 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c @@ -314,7 +314,7 @@ static int hibmc_pci_probe(struct pci_dev *pdev, struct drm_device *dev; int ret; - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "hibmcdrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &hibmc_driver); if (ret) return ret; diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c index eb06c92c4bfd..cd818a629183 100644 --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c @@ -82,7 +82,7 @@ static int hyperv_setup_gen1(struct hyperv_drm_device *hv) return -ENODEV; } - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "hypervdrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &hyperv_driver); if (ret) { drm_err(dev, "Not able to remove boot fb\n"); return ret; @@ -127,7 +127,7 @@ static int hyperv_setup_gen2(struct hyperv_drm_device *hv, drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base, screen_info.lfb_size, false, - "hypervdrmfb"); + &hyperv_driver); hv->fb_size = (unsigned long)hv->mmio_megabytes * 1024 * 1024; diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 850b499c71c8..62327c15f457 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -562,7 +562,7 @@ static int i915_driver_hw_probe(struct drm_i915_private *dev_priv) if (ret) goto err_perf; - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "inteldrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, dev_priv->drm.driver); if (ret) goto err_ggtt; diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c index a7388bf7c838..3d0ccc7eef1b 100644 --- a/drivers/gpu/drm/meson/meson_drv.c +++ b/drivers/gpu/drm/meson/meson_drv.c @@ -285,7 +285,7 @@ static int meson_drv_bind_master(struct device *dev, bool has_components) * Remove early framebuffers (ie. simplefb). The framebuffer can be * located anywhere in RAM */ - ret = drm_aperture_remove_framebuffers(false, "meson-drm-fb"); + ret = drm_aperture_remove_framebuffers(false, &meson_driver); if (ret) goto free_drm; diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c index a701d9563257..36d1bfb3213f 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.c +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c @@ -342,7 +342,7 @@ mgag200_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) struct drm_device *dev; int ret; - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "mgag200drmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &mgag200_driver); if (ret) return ret; diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c index 227404077e39..67fae60f2fa5 100644 --- a/drivers/gpu/drm/msm/msm_fbdev.c +++ b/drivers/gpu/drm/msm/msm_fbdev.c @@ -169,7 +169,7 @@ struct drm_fb_helper *msm_fbdev_init(struct drm_device *dev) } /* the fw fb could be anywhere in memory */ - ret = drm_aperture_remove_framebuffers(false, "msm"); + ret = drm_aperture_remove_framebuffers(false, dev->driver); if (ret) goto fini; diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index a616cf4573b8..df8a2d92f473 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -738,7 +738,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev, nvkm_device_del(&device); /* Remove conflicting drivers (vesafb, efifb etc). */ - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "nouveaufb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver_pci); if (ret) return ret; diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c index 854e6c5a563f..31f4c86ceb99 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.c +++ b/drivers/gpu/drm/qxl/qxl_drv.c @@ -95,7 +95,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) return ret; - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "qxl"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &qxl_driver); if (ret) goto disable_pci; diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 8cd135fa6dcd..82ee8244c9b3 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -330,7 +330,7 @@ static int radeon_pci_probe(struct pci_dev *pdev, return -EPROBE_DEFER; /* Get rid of things like offb */ - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "radeondrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &kms_driver); if (ret) return ret; diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index b730b8d5d949..17a189bb6bbc 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -116,7 +116,7 @@ static int rockchip_drm_bind(struct device *dev) int ret; /* Remove existing drivers that may own the framebuffer memory. */ - ret = drm_aperture_remove_framebuffers(false, "rockchip-drm-fb"); + ret = drm_aperture_remove_framebuffers(false, &rockchip_drm_driver); if (ret) { DRM_DEV_ERROR(dev, "Failed to remove existing framebuffers - %d.\n", diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c index af335f58bdfc..6bc1c8d6d43b 100644 --- a/drivers/gpu/drm/sun4i/sun4i_drv.c +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c @@ -100,7 +100,7 @@ static int sun4i_drv_bind(struct device *dev) drm->irq_enabled = true; /* Remove early framebuffers (ie. simplefb) */ - ret = drm_aperture_remove_framebuffers(false, "sun4i-drm-fb"); + ret = drm_aperture_remove_framebuffers(false, &sun4i_drv_driver); if (ret) goto cleanup_mode_config; diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index f96c237b2242..2c8fc14bba1f 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -1204,7 +1204,7 @@ static int host1x_drm_probe(struct host1x_device *dev) drm_mode_config_reset(drm); - err = drm_aperture_remove_framebuffers(false, "tegradrmfb"); + err = drm_aperture_remove_framebuffers(false, &tegra_drm_driver); if (err < 0) goto hub; diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c index 42611dacde88..a8b476a59c0d 100644 --- a/drivers/gpu/drm/tiny/cirrus.c +++ b/drivers/gpu/drm/tiny/cirrus.c @@ -550,7 +550,7 @@ static int cirrus_pci_probe(struct pci_dev *pdev, struct cirrus_device *cirrus; int ret; - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "cirrusdrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &cirrus_driver); if (ret) return ret; diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c b/drivers/gpu/drm/vboxvideo/vbox_drv.c index 6d4b32da9866..879a2445cc44 100644 --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c @@ -43,7 +43,7 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (!vbox_check_supported(VBE_DISPI_ID_HGSMI)) return -ENODEV; - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "vboxvideodrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver); if (ret) return ret; diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 8a60fb8ad370..73335feb712f 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -265,7 +265,7 @@ static int vc4_drm_bind(struct device *dev) if (ret) goto unbind_all; - ret = drm_aperture_remove_framebuffers(false, "vc4drmfb"); + ret = drm_aperture_remove_framebuffers(false, &vc4_drm_driver); if (ret) goto unbind_all; diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index ca77edbc5ea0..ed85a7863256 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -57,7 +57,7 @@ static int virtio_gpu_pci_quirk(struct drm_device *dev, struct virtio_device *vd vga ? "virtio-vga" : "virtio-gpu-pci", pname); if (vga) { - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "virtiodrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver); if (ret) return ret; } diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 086dc75e7b42..40864ce19ae1 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -1574,7 +1574,7 @@ static int vmw_probe(struct pci_dev *pdev, const struct pci_device_id *ent) struct vmw_private *vmw; int ret; - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "svgadrmfb"); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver); if (ret) return ret; diff --git a/include/drm/drm_aperture.h b/include/drm/drm_aperture.h index 6c148078780c..7096703c3949 100644 --- a/include/drm/drm_aperture.h +++ b/include/drm/drm_aperture.h @@ -6,20 +6,22 @@ #include <linux/types.h> struct drm_device; +struct drm_driver; struct pci_dev; int devm_aperture_acquire_from_firmware(struct drm_device *dev, resource_size_t base, resource_size_t size); int drm_aperture_remove_conflicting_framebuffers(resource_size_t base, resource_size_t size, - bool primary, const char *name); + bool primary, const struct drm_driver *req_driver); -int drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const char *name); +int drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev, + const struct drm_driver *req_driver); /** * drm_aperture_remove_framebuffers - remove all existing framebuffers * @primary: also kick vga16fb if present - * @name: requesting driver name + * @req_driver: requesting DRM driver * * This function removes all graphics device drivers. Use this function on systems * that can have their framebuffer located anywhere in memory. @@ -27,9 +29,11 @@ int drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const * Returns: * 0 on success, or a negative errno code otherwise */ -static inline int drm_aperture_remove_framebuffers(bool primary, const char *name) +static inline int +drm_aperture_remove_framebuffers(bool primary, const struct drm_driver *req_driver) { - return drm_aperture_remove_conflicting_framebuffers(0, (resource_size_t)-1, primary, name); + return drm_aperture_remove_conflicting_framebuffers(0, (resource_size_t)-1, primary, + req_driver); } #endif -- 2.32.0

5 4

Help needed for EVoC/GSoC/Outreachy
by Lyude Paul 05 Aug '21

05 Aug '21

Hi! As some of you might already be aware, after helping out X.org project the previous years with regards to student outreach, Trevor decided to retire from this position in hopes that someone else will be able to step up and take on these responsibilities. As such, we're trying to find people who would be willing to volunteer their time to help out with getting us involved once again in student outreach programs. In the past, X.org has been active in the GSoC program, occasionally Outreachy, and our own EVoC program. As of 2021 though, GSoC decided to shorten the amount of time allocated for a student to work on their project. This unfortunately posed some problems for X.org/freedesktop.org as a lot of the potential work that would have been good for us to have students working on wouldn't really fit within the new GSoC timeframe. While it's certainly possible that there will be projects that come up in the future which do fit into this new timeline, we think it'd be a good idea to step up our involvement again with Outreachy where the program is a good bit more flexible then GSoC. We've also had pretty good experience working with the Outreachy candidates we've had in the past. The other main topic of discussion is around the fact that our own program, EVoC, hasn't really had anyone available to volunteer to help run it for a while now. For those who aren't aware, EVoC is a program similar to Google Summer of Code that X.org started running with much more relaxed requirements then GSoC/Outreachy in order to help fill the gaps for any exceptional cases with students who would otherwise be left out by the requirements for GSoC/Outreachy. Typically though, EVoC is usually considered the last resort after a student has tried getting into GSoC/Outreachy. So, the two biggest things that we need are: * Admin volunteer(s) * Mentors, mentors, mentors! We really need these the most. So, what responsibilities would being an admin for this entail? * Fielding questions from potential GSoC/EVoC/Outreachy participants. Most of these students are just looking for simple details of how these programs work and are looking for project ideas. Responding to these inquiries is mostly just a matter of pointing students to various pages on our wiki or replying with form/stock replies. Most of the students at this phase expect to be handed a project and a mentor, and therefore end up learning that they will need to come up with their own project and mentor. * For the small handful of students that make it to the next phase and figure out a project idea, they then need to find a mentor. Usually the admin will help out by taking a look at who proposed the project idea, and/or looking through commit messages and mailing list history to try to find someone who would be a good fit and willing to mentor the student. Sometimes this happens quickly, and sometimes it requires poking a lot of people - and occasionally, there might not always be a mentor to be found. * If we have a student, project, and mentor then the next step is having the student write up a proposal. Many students start out with over-simplified proposals, so a lot of this work is just gently nudging students and getting them to refine their work items into a week-by-week synopsis. There's usually a good bit of back and forth with the student's proposal, and occasionally the mentor may be involved with this step. * The admin then works with the student to come up with a timeline for their work, taking into account any vacation time the student may have, along with coordinating the frequency/type of meetings that will happen between the student and the mentor. If the mentor is unable to attend all of these meetings, it's usually up to the admin to check in with the student to see how they are progressing and potentially provide them tips if they get stuck. As for being a mentor, it's pretty much as simple as it sounds: you work with students who have projects to help familiarize them with the project at hand, help them out wherever needed, check in on their progress, and guide them along the way towards reaching their project goal along with grading their work. Please help spread the word on this, and contact anyone you know who might be involved with this! We'll be happy to provide more information on how you can get started. Remember, folks like myself wouldn't be in this community without projects like GSoC :). -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat

1 1

[PATCH 00/10] drm/bridge: Make panel and bridge probe order consistent
by Maxime Ripard 05 Aug '21

05 Aug '21

Hi, We've encountered an issue with the RaspberryPi DSI panel that prevented the whole display driver from probing. The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi: Only register our component once a DSI device is attached"), but the basic idea is that since the panel is probed through i2c, there's no synchronization between its probe and the registration of the MIPI-DSI host it's attached to. We initially moved the component framework registration to the MIPI-DSI Host attach hook to make sure we register our component only when we have a DSI device attached to our MIPI-DSI host, and then use lookup our DSI device in our bind hook. However, all the DSI bridges controlled through i2c are only registering their associated DSI device in their bridge attach hook, meaning with our change above, we never got that far, and therefore ended up in the same situation than the one we were trying to fix for panels. Since the RaspberryPi panel is the only driver in that situation, whereas it seems like there's a consensus in bridge drivers, it makes more sense to try to mimic the bridge pattern in the panel driver. However, panels don't have an attach hook, and adding more panel hooks would lead to more path to maintain in each and every driver, while the general push is towards bridges. We also have to make sure that each and every DSI host and device driver behaves the same in order to have expectations to rely on. The solution I'm proposing is thus done in several steps: - We get rid of the initial patch to make sure we support the bridge case, and not the odd-panel one. - Add a function that returns a bridge from a DT node, reducing the amount of churn in each and every driver and making it a real incentive to not care about panels in display drivers but only bridges. - Add an attach and detach hook into the panel operations, and make it called automatically by the DRM panel bridge. - Convert the VC4 DSI host to this new bridge function, and the RaspberryPi Panel to the new attach and detach hooks. If the general approach is agreed upon, other drivers will obviously be converted to drm_of_get_next. Let me know what you think, Maxime Maxime Ripard (10): Revert "drm/vc4: dsi: Only register our component once a DSI device is attached" drm/bridge: Add a function to abstract away panels drm/bridge: Add documentation sections drm/bridge: Document the probe issue with MIPI-DSI bridges drm/panel: Create attach and detach callbacks drm/bridge: panel: Call attach and detach for the panel drm/vc4: dsi: Switch to drm_of_get_next drm/panel: raspberrypi-touchscreen: Prevent double-free drm/panel: raspberrypi-touchscreen: Use the attach hook drm/panel: raspberrypi-touchscreen: Remove MIPI-DSI driver Documentation/gpu/drm-kms-helpers.rst | 12 ++ drivers/gpu/drm/bridge/panel.c | 4 + drivers/gpu/drm/drm_bridge.c | 134 ++++++++++++++- drivers/gpu/drm/drm_of.c | 3 + drivers/gpu/drm/drm_panel.c | 20 +++ .../drm/panel/panel-raspberrypi-touchscreen.c | 159 +++++++++--------- drivers/gpu/drm/vc4/vc4_drv.c | 2 + drivers/gpu/drm/vc4/vc4_dsi.c | 53 +++--- include/drm/drm_bridge.h | 2 + include/drm/drm_panel.h | 6 + 10 files changed, 273 insertions(+), 122 deletions(-) -- 2.31.1

4 26

[PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation
by Matthew Auld 05 Aug '21

05 Aug '21

From: Chris Wilson <chris(a)chris-wilson.co.uk> Jason Ekstrand requested a more efficient method than userptr+set-domain to determine if the userptr object was backed by a complete set of pages upon creation. To be more efficient than simply populating the userptr using get_user_pages() (as done by the call to set-domain or execbuf), we can walk the tree of vm_area_struct and check for gaps or vma not backed by struct page (VM_PFNMAP). The question is how to handle VM_MIXEDMAP which may be either struct page or pfn backed... With discrete we are going to drop support for set_domain(), so offering a way to probe the pages, without having to resort to dummy batches has been requested. v2: - add new query param for the PROBE flag, so userspace can easily check if the kernel supports it(Jason). - use mmap_read_{lock, unlock}. - add some kernel-doc. v3: - In the docs also mention that PROBE doesn't guarantee that the pages will remain valid by the time they are actually used(Tvrtko). - Add a small comment for the hole finding logic(Jason). - Move the param next to all the other params which just return true. Testcase: igt/gem_userptr_blits/probe Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com> Cc: Jordan Justen <jordan.l.justen(a)intel.com> Cc: Kenneth Graunke <kenneth(a)whitecape.org> Cc: Jason Ekstrand <jason(a)jlekstrand.net> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Ramalingam C <ramalingam.c(a)intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Acked-by: Kenneth Graunke <kenneth(a)whitecape.org> Reviewed-by: Jason Ekstrand <jason(a)jlekstrand.net> --- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 41 ++++++++++++++++++++- drivers/gpu/drm/i915/i915_getparam.c | 1 + include/uapi/drm/i915_drm.h | 20 ++++++++++ 3 files changed, 61 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c index 56edfeff8c02..468a7a617fbf 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c @@ -422,6 +422,34 @@ static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = { #endif +static int +probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len) +{ + const unsigned long end = addr + len; + struct vm_area_struct *vma; + int ret = -EFAULT; + + mmap_read_lock(mm); + for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) { + /* Check for holes, note that we also update the addr below */ + if (vma->vm_start > addr) + break; + + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) + break; + + if (vma->vm_end >= end) { + ret = 0; + break; + } + + addr = vma->vm_end; + } + mmap_read_unlock(mm); + + return ret; +} + /* * Creates a new mm object that wraps some normal memory from the process * context - user memory. @@ -477,7 +505,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev, } if (args->flags & ~(I915_USERPTR_READ_ONLY | - I915_USERPTR_UNSYNCHRONIZED)) + I915_USERPTR_UNSYNCHRONIZED | + I915_USERPTR_PROBE)) return -EINVAL; if (i915_gem_object_size_2big(args->user_size)) @@ -504,6 +533,16 @@ i915_gem_userptr_ioctl(struct drm_device *dev, return -ENODEV; } + if (args->flags & I915_USERPTR_PROBE) { + /* + * Check that the range pointed to represents real struct + * pages and not iomappings (at this moment in time!) + */ + ret = probe_range(current->mm, args->user_ptr, args->user_size); + if (ret) + return ret; + } + #ifdef CONFIG_MMU_NOTIFIER obj = i915_gem_object_alloc(); if (obj == NULL) diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c index 24e18219eb50..bbb7cac43eb4 100644 --- a/drivers/gpu/drm/i915/i915_getparam.c +++ b/drivers/gpu/drm/i915/i915_getparam.c @@ -134,6 +134,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data, case I915_PARAM_HAS_EXEC_FENCE_ARRAY: case I915_PARAM_HAS_EXEC_SUBMIT_FENCE: case I915_PARAM_HAS_EXEC_TIMELINE_FENCES: + case I915_PARAM_HAS_USERPTR_PROBE: /* For the time being all of these are always true; * if some supported hardware does not have one of these * features this value needs to be provided from diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index 975087553ea0..0d290535a6e5 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -674,6 +674,9 @@ typedef struct drm_i915_irq_wait { */ #define I915_PARAM_HAS_EXEC_TIMELINE_FENCES 55 +/* Query if the kernel supports the I915_USERPTR_PROBE flag. */ +#define I915_PARAM_HAS_USERPTR_PROBE 56 + /* Must be kept compact -- no holes and well documented */ typedef struct drm_i915_getparam { @@ -2222,12 +2225,29 @@ struct drm_i915_gem_userptr { * through the GTT. If the HW can't support readonly access, an error is * returned. * + * I915_USERPTR_PROBE: + * + * Probe the provided @user_ptr range and validate that the @user_ptr is + * indeed pointing to normal memory and that the range is also valid. + * For example if some garbage address is given to the kernel, then this + * should complain. + * + * Returns -EFAULT if the probe failed. + * + * Note that this doesn't populate the backing pages, and also doesn't + * guarantee that the object will remain valid when the object is + * eventually used. + * + * The kernel supports this feature if I915_PARAM_HAS_USERPTR_PROBE + * returns a non-zero value. + * * I915_USERPTR_UNSYNCHRONIZED: * * NOT USED. Setting this flag will result in an error. */ __u32 flags; #define I915_USERPTR_READ_ONLY 0x1 +#define I915_USERPTR_PROBE 0x2 #define I915_USERPTR_UNSYNCHRONIZED 0x80000000 /** * @handle: Returned handle for the object. -- 2.26.3

6 13

[PATCH v5 00/12] i915 TTM sync accelerated migration and clear
by Thomas Hellström 05 Aug '21

05 Aug '21

This patchset implements synchronous accelerated migration and clearing for i915 on TTM. We plan to follow up with these operations made asynchronous to the extent of TTM support for that: A couple of patches from Chris which implement pipelined migration and clears by atomically writing the PTEs in place before performing the actual blit. Some ww utilities mainly for the accompanying selftests added by Thomas, as well as modified the above patches for ww locking- and lmem support. Hooked up to our TTM backend by Ramalingam Finally, on request from Daniel, we ditch old blit code which is now obsolete. v2: - A couple of minor style fixes pointed out by Matthew Auld - Export and use intel_engine_destroy_pinned_context() to address a CI warning / failure. v3: - Acceleration hooked up to TTM - Minor fixes to review comments (Pointed out by Matthew Auld) - Fix pipelined blit handling of engine instances (Pointed out by Matthew Auld) - Ditch old blit code, (Pointed out by Daniel) v4: - Rescue a selftest that was removed with the old blit code (Pointed out by Matthew Auld) - Extended gpu waits in the TTM accel move function (Pointed out by Thomas Hellström) v5: - Minor rebase on buddy series. - Added R-Bs for the last patches. Chris Wilson (6): drm/i915/gt: Add an insert_entry for gen8_ppgtt drm/i915/gt: Add a routine to iterate over the pagetables of a GTT drm/i915/gt: Export the pinned context constructor and destructor drm/i915/gt: Pipelined page migration drm/i915/gt: Pipelined clear drm/i915/gt: Setup a default migration context on the GT Ramalingam C (1): drm/i915/ttm: accelerated move implementation Thomas Hellström (5): drm/i915: Reference objects on the ww object list drm/i915: Break out dma_resv ww locking utilities to separate files drm/i915: Introduce a ww transaction helper drm/i915/gem: Zap the client blt code drm/i915/gem: Zap the i915_gem_object_blt code drivers/gpu/drm/i915/Makefile | 5 +- .../gpu/drm/i915/gem/i915_gem_client_blt.c | 355 --------- .../gpu/drm/i915/gem/i915_gem_client_blt.h | 21 - drivers/gpu/drm/i915/gem/i915_gem_object.h | 9 +- .../gpu/drm/i915/gem/i915_gem_object_blt.c | 461 ------------ .../gpu/drm/i915/gem/i915_gem_object_blt.h | 39 - drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 88 ++- .../i915/gem/selftests/i915_gem_client_blt.c | 114 +-- .../i915/gem/selftests/i915_gem_object_blt.c | 597 --------------- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 68 ++ drivers/gpu/drm/i915/gt/intel_engine.h | 12 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 27 +- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 + drivers/gpu/drm/i915/gt/intel_gt.c | 4 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/gt/intel_gtt.h | 7 + drivers/gpu/drm/i915/gt/intel_migrate.c | 687 ++++++++++++++++++ drivers/gpu/drm/i915/gt/intel_migrate.h | 65 ++ drivers/gpu/drm/i915/gt/intel_migrate_types.h | 15 + drivers/gpu/drm/i915/gt/intel_renderstate.h | 1 + drivers/gpu/drm/i915/gt/intel_ring.h | 1 + drivers/gpu/drm/i915/gt/selftest_migrate.c | 669 +++++++++++++++++ drivers/gpu/drm/i915/i915_gem.c | 52 -- drivers/gpu/drm/i915/i915_gem.h | 12 - drivers/gpu/drm/i915/i915_gem_ww.c | 63 ++ drivers/gpu/drm/i915/i915_gem_ww.h | 50 ++ .../drm/i915/selftests/i915_live_selftests.h | 2 +- .../drm/i915/selftests/i915_perf_selftests.h | 2 +- .../drm/i915/selftests/intel_memory_region.c | 21 +- 29 files changed, 1766 insertions(+), 1686 deletions(-) delete mode 100644 drivers/gpu/drm/i915/gem/i915_gem_client_blt.c delete mode 100644 drivers/gpu/drm/i915/gem/i915_gem_client_blt.h delete mode 100644 drivers/gpu/drm/i915/gem/i915_gem_object_blt.c delete mode 100644 drivers/gpu/drm/i915/gem/i915_gem_object_blt.h delete mode 100644 drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c create mode 100644 drivers/gpu/drm/i915/gt/intel_migrate.c create mode 100644 drivers/gpu/drm/i915/gt/intel_migrate.h create mode 100644 drivers/gpu/drm/i915/gt/intel_migrate_types.h create mode 100644 drivers/gpu/drm/i915/gt/selftest_migrate.c create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.c create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.h -- 2.31.1

2 14

[PATCH -next v2] drm/msm: Use list_move_tail instead of list_del/list_add_tail in msm_gem.c
by Baokun Li 05 Aug '21

05 Aug '21

Using list_move_tail() instead of list_del() + list_add_tail() in msm_gem.c. Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- V1->V2: CC mailist drivers/gpu/drm/msm/msm_gem.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 1865919368f2..5b7d63d3750a 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -854,8 +854,7 @@ void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu) mutex_lock(&priv->mm_lock); if (msm_obj->evictable) mark_unevictable(msm_obj); - list_del(&msm_obj->mm_list); - list_add_tail(&msm_obj->mm_list, &gpu->active_list); + list_move_tail(&msm_obj->mm_list, &gpu->active_list); mutex_unlock(&priv->mm_lock); } }

2 1

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021