dri-devel July 2020

dri-devel@lists.freedesktop.org

336 participants
772 discussions

[PATCH] drm: bridge: adv7511: Add missing bridge type
by Vinod Koul 24 Jul '20

24 Jul '20

Add bridge type as DRM_MODE_CONNECTOR_HDMIA Signed-off-by: Vinod Koul <vkoul(a)kernel.org> --- I found this when testing Dragon-board 410c which uses this bridge [ 6.671913] msm 1a00000.mdss: [drm:msm_dsi_manager_ext_bridge_init [msm]] *ERROR* drm_bridge_connector_init failed: -22 [ 6.678879] msm 1a00000.mdss: [drm:msm_dsi_modeset_init [msm]] *ERROR* failed to create dsi connector: -19 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index f45cdca9cce5..a0d392c338da 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -1283,6 +1283,7 @@ static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id *id) adv7511->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_HPD; adv7511->bridge.of_node = dev->of_node; + adv7511->bridge.type = DRM_MODE_CONNECTOR_HDMIA; drm_bridge_add(&adv7511->bridge); -- 2.26.2

2 2

[PATCH v2 0/2] Add support for Tianma nt36672a video mode panel
by Sumit Semwal 24 Jul '20

24 Jul '20

Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml | 104 +++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++++++++++++++++++ 5 files changed, 982 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.27.0

2 4

[PATCH] drm/amd/display: remove redundant initialization of variable result
by Colin King 23 Jul '20

23 Jul '20

From: Colin Ian King <colin.king(a)canonical.com> The variable result is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c index 5d83e8174005..0853bc9917c7 100644 --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c @@ -1017,7 +1017,7 @@ enum dc_status dce112_add_stream_to_ctx( struct dc_state *new_ctx, struct dc_stream_state *dc_stream) { - enum dc_status result = DC_ERROR_UNEXPECTED; + enum dc_status result; result = resource_map_pool_resources(dc, new_ctx, dc_stream); -- 2.27.0

2 1

[PATCH -resend] Documentation: fb, fix path to modedb.c
by Jiri Slaby 23 Jul '20

23 Jul '20

modedb.c was moved twice since the modedb documentation was written. Update the path to the current one. Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-fbdev(a)vger.kernel.org Cc: linux-doc(a)vger.kernel.org --- Documentation/fb/modedb.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst index 624d08fd2856..4d2411e32ebb 100644 --- a/Documentation/fb/modedb.rst +++ b/Documentation/fb/modedb.rst @@ -152,7 +152,7 @@ To specify a video mode at bootup, use the following boot options:: video=<driver>:<xres>x<yres>[-<bpp>][@refresh] where <driver> is a name from the table below. Valid default modes can be -found in linux/drivers/video/modedb.c. Check your driver's documentation. +found in drivers/video/fbdev/core/modedb.c. Check your driver's documentation. There may be more modes:: Drivers that support modedb boot options -- 2.27.0

2 1

How to handle disconnection of eDP panels due to dynamic display mux switches
by Daniel Dadap 23 Jul '20

23 Jul '20

A number of hybrid GPU notebook computer designs with dual (integrated plus discrete) GPUs are equipped with multiplexers (muxes) that allow display panels to be driven by either the integrated GPU or the discrete GPU. Typically, this is a selection that can be made at boot time as a menu option in the system firmware's setup screen, and the mux selection stays fixed for as long as the system is running and persists across reboots until it is explicitly changed. However, some muxed hybrid GPU systems have dynamically switchable muxes which can be switched while the system is running. NVIDIA is exploring the possibility of taking advantage of dynamically switchable muxes to enhance the experience of using a hybrid GPU system. For example, on a system configured for PRIME render offloading, it may be possible to keep the discrete GPU powered down and use the integrated GPU for rendering and displaying the desktop when no applications are using the discrete GPU, and dynamically switch the panel to be driven directly by the discrete GPU when render-offloading a fullscreen application. We have been conducting some experiments on systems with dynamic muxes, and have found some limitations that would need to be addressed in order to support use cases like the one suggested above: * In at least the i915 DRM-KMS driver, and likely in other DRM-KMS drivers as well, eDP panels are assumed to be always connected. This assumption is broken when the panel is muxed away, which can cause problems. A typical symptom is i915 repeatedly attempting to retrain the link, severely impacting system performance and printing messages like the following every five seconds or so: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS. This symptom might occur if something causes the DRM-KMS driver to probe the display while it's muxed away, for example a modeset or DPMS state change. * When switching the mux back to a GPU that was previously driving a mode, it is necessary to at the very least retrain DP links to restore the previously displayed image. In a proof of concept I have been experimenting with, I am able to accomplish this from userspace by triggering DPMS off and then back on again; however, it would be good to have an in-kernel API to request that an output owned by a DRM-KMS driver be refreshed to resume driving a mode on a disconnected and reconnected display. This API would need to be accessible from outside of the DRM-KMS driver handling the output. One reason it would be good to do this within the kernel, rather than rely on e.g. DPMS operations in the xf86-video-modesetting driver, is that it would be useful for restoring the console if X crashes or is forcefully killed while the mux is switched to a GPU other than the one which drives the console. Basically, we'd like to be able to do the following: 1) Communicate to a DRM-KMS driver that an output is disconnected and can't be used. Ideally, DRI clients such as X should still see the output as being connected, so user applications don't need to keep track of the change. 2) Request that a mode that was previously driven on a disconnected output be driven again upon reconnection. If APIs to do the above are already available, I wasn't able to find information about them. These could be handled as separate APIs, e.g., one to set connected/disconnected state and another to restore an output, or as a single API, e.g., signal a disconnect or reconnect, leaving it up to the driver receiving the signal to set the appropriate internal state and restore the reconnected output. Another possibility would be an API to disable and enable individual outputs from outside of the DRM-KMS driver that owns them. I'm curious to hear the thoughts of the DRM subsystem maintainers and contributors on what the best approach to this would be.

6 25

linux-next: manual merge of the amdgpu tree with Linus' tree
by Stephen Rothwell 23 Jul '20

23 Jul '20

Hi all, [I can't find a previous email about this, sorry ...] There is a semantic conflict between Linus' tree and the amdgpu tree between commit d7a6634a4cfb ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir") from Linus' tree and commts fe098a5d6443 ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir") 836dab851903 ("drm/amdgpu/atomfirmware: update vram info handling for renoir") The automted git merge leaves two "case 12" labels. I have been reverting commit d7a6634a4cfb since July 3 ... This will need to be fixed up when the amdgpu tree is next merged into the drm tree, or a back merge of d7a6634a4cfb could be done into the amdgpu tree and the older "case 12" label removed in that merge. -- Cheers, Stephen Rothwell

3 2

[PATCH v5 0/4] Add LT9611 DSI to HDMI bridge
by Vinod Koul 23 Jul '20

23 Jul '20

Hi, This series adds driver and bindings for Lontium LT9611 bridge chip which takes MIPI DSI as input and HDMI as output. This chip can be found in 96boards RB3 platform [1] commonly called DB845c. [1]: https://www.96boards.org/product/rb3-platform/ Changes in v5: - make symbol static, reported by kbuild-bot Changes in v4: - Add msm/dsi patch to create connector and support DRM_BRIDGE_ATTACH_NO_CONNECTOR - Fix comments provided by Sam Changes in v3: - fix kbuild reported error - rebase on v5.8-rc1 Changes in v2: - Add acks by Rob - Fix comments reported by Emil and rename the file to lontium-lt9611.c - Fix comments reported by Laurent on binding and driver - Add HDMI audio support Vinod Koul (4): dt-bindings: vendor-prefixes: Add Lontium vendor prefix dt-bindings: display: bridge: Add documentation for LT9611 drm/bridge: Introduce LT9611 DSI to HDMI bridge drm/msm/dsi: attach external bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR .../display/bridge/lontium,lt9611.yaml | 176 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/gpu/drm/bridge/Kconfig | 13 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/lontium-lt9611.c | 1142 +++++++++++++++++ drivers/gpu/drm/msm/dsi/dsi.c | 7 +- drivers/gpu/drm/msm/dsi/dsi_manager.c | 27 +- 7 files changed, 1348 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c -- 2.26.2

3 11

[PATCH v2 0/2] Some improvements for iommu
by Baolin Wang 23 Jul '20

23 Jul '20

Hi, The first patch masks some functions as static, and the second patch changes to use the gfp parameter from iommu_ops->map() to allocate ARM page pages. Any comments are welcome. Thanks. Changes from v1: - Fix the building errors when enabling CONFIG_IOMMU_IO_PGTABLE_LPAE_SELFTEST Baolin Wang (2): iommu: Mark __iommu_map/__iommu_map_sg as static iommu: Add gfp parameter to io_pgtable_ops->map() drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +- drivers/iommu/arm-smmu-v3.c | 2 +- drivers/iommu/arm-smmu.c | 2 +- drivers/iommu/io-pgtable-arm-v7s.c | 18 +++++++++--------- drivers/iommu/io-pgtable-arm.c | 18 +++++++++--------- drivers/iommu/iommu.c | 10 +++++----- drivers/iommu/ipmmu-vmsa.c | 2 +- drivers/iommu/msm_iommu.c | 2 +- drivers/iommu/mtk_iommu.c | 2 +- drivers/iommu/qcom_iommu.c | 2 +- include/linux/io-pgtable.h | 2 +- 11 files changed, 31 insertions(+), 31 deletions(-) -- 1.8.3.1

2 5

pages pinned for BO lifetime and security
by Chia-I Wu 23 Jul '20

23 Jul '20

Hi list, virtio-gpu is moving in the direction where BO pages are pinned for the lifetime for simplicity. I am wondering if that is considered a security issue in general, especially after running into the description of the new DMABUF_MOVE_NOTIFY config option. Most drivers do not have a shrinker, or whether a BO is purgeable is entirely controlled by the userspace (madvice). They can be categorized as "a security problem where userspace is able to pin unrestricted amounts of memory". But those drivers are normally found on systems without swap. I don't think the issue applies. Of the desktop GPU drivers, i915's shrinker certainly supports purging to swap. TTM is a bit hard to follow. I can't really tell if amdgpu or nouveau supports that. virtio-gpu is more commonly found on systems with swaps so I think it should follow the desktop practices? Truth is, the emulated virtio-gpu device always supports page moves with VIRTIO_GPU_CMD_RESOURCE_{ATTACH,DETACH}_BACKING. It is just that the driver does not make use of them. That makes this less of an issue because the driver can be fixed anytime (finger crossed that the emulator won't have bugs in these untested paths). This issue becomes more urgent because we are considering adding a new HW command[1] where page moves will be disallowed. We definitely don't want a HW command that is inherently insecure, if BO pages pinned for the lifetime is considered a security issue on desktops. [1] VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB https://gitlab.freedesktop.org/virgl/drm-misc-next/-/blob/virtio-gpu-next/i…

5 11

Re: [PATCH] drm/amdkfd: Put ACPI table after using it
by Markus Elfring 23 Jul '20

23 Jul '20

… > and in kfd_create_vcrat_image_cpu(), the acpi_table is only used to > get the OEM info, so those table mappings need to be release after … 1. Please avoid a typo for this change description. 2. An imperative wording can be preferred here, can't it? 3. Will the tag “Fixes” become helpful for the commit message? Regards, Markus

1 0

← Newer
1
...
34
35
36
37
38
39
40
...
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