dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

[PATCH] gpu: drm: exynos: Remove set but unused value
by "hariprasad Kelam hariprasad.kelam"＠gmail.com 21 Aug '19

21 Aug '19

From: Hariprasad Kelam <hariprasad.kelam(a)gmail.com> fix below defect reported by coverity In exynos_dsi_read_from_fifo: A value assigned to a variable is never used. fix Defect:1451826 Signed-off-by: Hariprasad Kelam <hariprasad.kelam(a)gmail.com> --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c index 6926cee..5310879 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c @@ -1051,12 +1051,11 @@ static void exynos_dsi_read_from_fifo(struct exynos_dsi *dsi, } length = (reg >> 8) & 0xffff; - if (length > xfer->rx_len) { + if (length > xfer->rx_len) dev_err(dev, "response too long (%u > %u bytes), stripping\n", xfer->rx_len, length); - length = xfer->rx_len; - } else if (length < xfer->rx_len) + else if (length < xfer->rx_len) xfer->rx_len = length; } -- 2.7.4

1 0

[PATCH v2 0/9] Add dual-LVDS panel support to EK874
by Fabrizio Castro 21 Aug '19

21 Aug '19

Dear All, this series adds support for dual-LVDS panel IDK-2121WR from Advantech: https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-I… Dual link support is very recent for R-Car Gen3, and I couldn't find much on dual link panels in the kernel either, therefore comments are very welcome to get this right. The panel doesn't come with the EK874 kit, but it's advertised as supported, therefore this series adds a new dts file to support the configuration of the EK874 + IDK-2121WR. Laurent, it appears that Rob has been busy converting the dt-bindings relevant to this series, and his changes are now found in linux-next. Most notably Documentation/devicetree/bindings/display/panel/panel-lvds.txt has now become Documentation/devicetree/bindings/display/panel/lvds.yaml You have already taken patch: https://patchwork.kernel.org/patch/11072749/ as such the patch I am sending you is still related to: Documentation/devicetree/bindings/display/panel/panel-lvds.txt Patch "dt-bindings: display: Add bindings for Advantech IDK-2121WR" is still assuming the format is .txt, as I am not too sure about what the protocol is in this case? Shall we take this patch and convert it later to .yaml or shall I convert it to .yaml straight away? Please, let me know what's the best course of action. v1->v2: * dt-bindings: display: renesas: lvds: Document renesas,swap-data - dropped * drm: rcar-du: lvds: Add data swap support - dropped * drm: rcar-du: lvds: Do not look at ports for identifying bridges - dropped * drm: rcar-du: lvds: Add support for dual link panels - dropped * dt-bindings: display: renesas: lvds: RZ/G2E needs renesas,companion too - taken * drm: rcar-du: lvds: Fix bridge_to_rcar_lvds - taken * arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1 - taken * arm64: dts: renesas: cat874: Add definition for 12V regulator -taken * dt-bindings: panel: lvds: Add dual-link LVDS display support - reworked according to Laurent's feedback * dt-bindings: display: Add bindings for Advantech IDK-2121WR - reworked according to Laurent's feedback * drm: Rename drm_bridge_timings to drm_timings - new patch * drm/timings: Add link flags - new patch * drm/panel: Add timings field to drm_panel - new patch * drm: rcar-du: lvds: Fix companion's mode - reworked according to Laurent's feedback * drm: rcar-du: lvds: Add dual-LVDS panels support - new patch * drm/panel: lvds: Add support for the IDK-2121WR - new patch * arm64: dts: renesas: Add EK874 board with idk-2121wr display support - Made some changes Thanks, Fab Fabrizio Castro (9): dt-bindings: panel: lvds: Add dual-link LVDS display support dt-bindings: display: Add bindings for Advantech IDK-2121WR drm: Rename drm_bridge_timings to drm_timings drm/timings: Add link flags drm/panel: Add timings field to drm_panel drm: rcar-du: lvds: Fix companion's mode drm: rcar-du: lvds: Add dual-LVDS panels support drm/panel: lvds: Add support for the IDK-2121WR arm64: dts: renesas: Add EK874 board with idk-2121wr display support .../display/panel/advantech,idk-2121wr.txt | 56 +++++++++ .../bindings/display/panel/panel-lvds.txt | 95 ++++++++++++---- arch/arm64/boot/dts/renesas/Makefile | 3 +- .../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 +++++++++++++++++++ drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/thc63lvd1024.c | 2 +- drivers/gpu/drm/bridge/ti-tfp410.c | 6 +- drivers/gpu/drm/panel/panel-lvds.c | 8 ++ drivers/gpu/drm/pl111/pl111_display.c | 2 +- drivers/gpu/drm/rcar-du/rcar_lvds.c | 126 ++++++++++++++------- include/drm/drm_bridge.h | 40 +------ include/drm/drm_panel.h | 3 + include/drm/drm_timings.h | 86 ++++++++++++++ 14 files changed, 439 insertions(+), 112 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts create mode 100644 include/drm/drm_timings.h -- 2.7.4

4 36

[PATCH] drm/i915: add port info to debugfs
by Simon Ser 21 Aug '19

21 Aug '19

This patch adds a line with the port name to connectors in debugfs/i916_display_info. A hint is printed if the port is type-C. Signed-off-by: Simon Ser <simon.ser(a)intel.com> Cc: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index b39226d7f8d2..718a337c8f0a 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2557,9 +2557,11 @@ static void intel_lvds_info(struct seq_file *m, static void intel_connector_info(struct seq_file *m, struct drm_connector *connector) { + struct drm_i915_private *i915 = to_i915(connector->dev); struct intel_connector *intel_connector = to_intel_connector(connector); struct intel_encoder *intel_encoder = intel_connector->encoder; struct drm_display_mode *mode; + enum tc_port tc_port; seq_printf(m, "connector %d: type %s, status: %s\n", connector->base.id, connector->name, @@ -2578,6 +2580,13 @@ static void intel_connector_info(struct seq_file *m, if (!intel_encoder) return; + if (intel_encoder->port != PORT_NONE) { + tc_port = intel_port_to_tc(i915, intel_encoder->port); + seq_printf(m, "\tport: %c%s\n", + port_name(intel_encoder->port), + tc_port != PORT_TC_NONE ? " (type-C)" : ""); + } + switch (connector->connector_type) { case DRM_MODE_CONNECTOR_DisplayPort: case DRM_MODE_CONNECTOR_eDP: -- 2.22.1

3 2

[PATCH] drm/msm/dpu: fix "frame done" timeouts
by Rob Clark 21 Aug '19

21 Aug '19

From: Rob Clark <robdclark(a)chromium.org> Previously, dpu_crtc_frame_event_work() would try to aquire all the modeset locks in order to check whether it can release bandwidth. (If we only have cmd-mode display, bandwidth can be released at frame-done time.) The problem with this is that it is also responsible for signalling frame_done_comp, which dpu_crtc_commit_kickoff() waits on if there is already a frame pending. This is called in the msm_atomic_commit_tail() path.. which means that for non-nonblock commits, at least some of the modeset locks are already held. Re-work this scheme to use a reference count to track our need to have clocks enabled. It is incremented for each atomic commit, and decremented in the corresponding frame-done. Additionally, any crtc used in video mode hold an extra reference while they are enabled. The net effect is that we can determine in frame-done whether it is safe to drop bandwidth without needing to aquire any modeset locks. Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 16 +------ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 45 +++++++++++-------- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 8 ++++ 4 files changed, 38 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c index 5cda96875e03..09a49b59bb5b 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c @@ -214,7 +214,6 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms, */ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc) { - struct drm_crtc *tmp_crtc; struct dpu_crtc *dpu_crtc; struct dpu_crtc_state *dpu_cstate; struct dpu_kms *kms; @@ -233,22 +232,9 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc) dpu_crtc = to_dpu_crtc(crtc); dpu_cstate = to_dpu_crtc_state(crtc->state); - /* only do this for command mode rt client */ - if (dpu_crtc_get_intf_mode(crtc) != INTF_MODE_CMD) + if (atomic_dec_return(&kms->bandwidth_ref) > 0) return; - /* - * If video interface present, cmd panel bandwidth cannot be - * released. - */ - if (dpu_crtc_get_intf_mode(crtc) == INTF_MODE_CMD) - drm_for_each_crtc(tmp_crtc, crtc->dev) { - if (tmp_crtc->enabled && - dpu_crtc_get_intf_mode(tmp_crtc) == - INTF_MODE_VIDEO) - return; - } - /* Release the bandwidth */ if (kms->perf.enable_bw_release) { trace_dpu_cmd_release_bw(crtc->base.id); diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c index b3417d56032d..4e54550c4a80 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c @@ -292,19 +292,6 @@ void dpu_crtc_vblank_callback(struct drm_crtc *crtc) trace_dpu_crtc_vblank_cb(DRMID(crtc)); } -static void dpu_crtc_release_bw_unlocked(struct drm_crtc *crtc) -{ - int ret = 0; - struct drm_modeset_acquire_ctx ctx; - - DRM_MODESET_LOCK_ALL_BEGIN(crtc->dev, ctx, 0, ret); - dpu_core_perf_crtc_release_bw(crtc); - DRM_MODESET_LOCK_ALL_END(ctx, ret); - if (ret) - DRM_ERROR("Failed to acquire modeset locks to release bw, %d\n", - ret); -} - static void dpu_crtc_frame_event_work(struct kthread_work *work) { struct dpu_crtc_frame_event *fevent = container_of(work, @@ -334,7 +321,7 @@ static void dpu_crtc_frame_event_work(struct kthread_work *work) /* release bandwidth and other resources */ trace_dpu_crtc_frame_event_done(DRMID(crtc), fevent->event); - dpu_crtc_release_bw_unlocked(crtc); + dpu_core_perf_crtc_release_bw(crtc); } else { trace_dpu_crtc_frame_event_more_pending(DRMID(crtc), fevent->event); @@ -650,7 +637,7 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc, bool async) dpu_encoder_prepare_for_kickoff(encoder, async); if (!async) { - /* wait for frame_event_done completion */ + /* wait for previous frame_event_done completion */ DPU_ATRACE_BEGIN("wait_for_frame_done_event"); ret = _dpu_crtc_wait_for_frame_done(crtc); DPU_ATRACE_END("wait_for_frame_done_event"); @@ -729,6 +716,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc, struct drm_encoder *encoder; struct msm_drm_private *priv; unsigned long flags; + bool release_bandwidth = false; if (!crtc || !crtc->dev || !crtc->dev->dev_private || !crtc->state) { DPU_ERROR("invalid crtc\n"); @@ -745,8 +733,15 @@ static void dpu_crtc_disable(struct drm_crtc *crtc, drm_crtc_vblank_off(crtc); drm_for_each_encoder_mask(encoder, crtc->dev, - old_crtc_state->encoder_mask) + old_crtc_state->encoder_mask) { + /* in video mode, we hold an extra bandwidth reference + * as we cannot drop bandwidth at frame-done if any + * crtc is being used in video mode. + */ + if (dpu_encoder_get_intf_mode(encoder) == INTF_MODE_VIDEO) + release_bandwidth = true; dpu_encoder_assign_crtc(encoder, NULL); + } /* wait for frame_event_done completion */ if (_dpu_crtc_wait_for_frame_done(crtc)) @@ -760,7 +755,8 @@ static void dpu_crtc_disable(struct drm_crtc *crtc, if (atomic_read(&dpu_crtc->frame_pending)) { trace_dpu_crtc_disable_frame_pending(DRMID(crtc), atomic_read(&dpu_crtc->frame_pending)); - dpu_core_perf_crtc_release_bw(crtc); + if (release_bandwidth) + dpu_core_perf_crtc_release_bw(crtc); atomic_set(&dpu_crtc->frame_pending, 0); } @@ -792,6 +788,7 @@ static void dpu_crtc_enable(struct drm_crtc *crtc, struct dpu_crtc *dpu_crtc; struct drm_encoder *encoder; struct msm_drm_private *priv; + bool request_bandwidth; if (!crtc || !crtc->dev || !crtc->dev->dev_private) { DPU_ERROR("invalid crtc\n"); @@ -804,9 +801,19 @@ static void dpu_crtc_enable(struct drm_crtc *crtc, DRM_DEBUG_KMS("crtc%d\n", crtc->base.id); dpu_crtc = to_dpu_crtc(crtc); - drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state->encoder_mask) + drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state->encoder_mask) { + /* in video mode, we hold an extra bandwidth reference + * as we cannot drop bandwidth at frame-done if any + * crtc is being used in video mode. + */ + if (dpu_encoder_get_intf_mode(encoder) == INTF_MODE_VIDEO) + request_bandwidth = true; dpu_encoder_register_frame_event_callback(encoder, dpu_crtc_frame_event_cb, (void *)crtc); + } + + if (request_bandwidth) + atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref); trace_dpu_crtc_enable(DRMID(crtc), true, dpu_crtc); dpu_crtc->enabled = true; @@ -981,6 +988,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc, } } + atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref); + rc = dpu_core_perf_crtc_check(crtc, state); if (rc) { DPU_ERROR("crtc%d failed performance check %d\n", diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index 99d0bd569c38..681955eb286f 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -800,6 +800,8 @@ static int dpu_kms_hw_init(struct msm_kms *kms) return rc; } + atomic_set(&dpu_kms->bandwidth_ref, 0); + dpu_kms->mmio = msm_ioremap(dpu_kms->pdev, "mdp", "mdp"); if (IS_ERR(dpu_kms->mmio)) { rc = PTR_ERR(dpu_kms->mmio); diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h index 9e40f559c51f..fdef016f5ca3 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h @@ -120,6 +120,14 @@ struct dpu_kms { struct platform_device *pdev; bool rpm_enabled; struct dss_module_power mp; + + /* reference count bandwidth requests, so we know when we can + * release bandwidth. Each atomic update increments, and frame- + * done event decrements. Additionally, for video mode, the + * reference is incremented when crtc is enabled, and decremented + * when disabled. + */ + atomic_t bandwidth_ref; }; struct vsync_info { -- 2.21.0

2 1

Re: linux-next: Tree for Aug 19 (amdgpu)
by Randy Dunlap 21 Aug '19

21 Aug '19

On 8/19/19 2:18 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20190816: > on x86_64: ../drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c: In function ‘amdgpu_exit’: ../drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:1471:2: error: implicit declaration of function ‘mmu_notifier_synchronize’; did you mean ‘__sync_synchronize’? [-Werror=implicit-function-declaration] mmu_notifier_synchronize(); ^~~~~~~~~~~~~~~~~~~~~~~~ __sync_synchronize Full randconfig file is attached. -- ~Randy

4 4

Re: linux-next: Tree for Aug 21 (gpu/drm/i915/)
by Randy Dunlap 21 Aug '19

21 Aug '19

On 8/21/19 1:49 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20190820: > on x86_64: ../drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘ggtt_restore_mappings’: ../drivers/gpu/drm/i915/i915_gem_gtt.c:3333:3: error: implicit declaration of function ‘wbinvd_on_all_cpus’; did you mean ‘wrmsr_on_cpus’? [-Werror=implicit-function-declaration] wbinvd_on_all_cpus(); ^~~~~~~~~~~~~~~~~~ wrmsr_on_cpus Full randconfig file is attached. -- ~Randy

1 0

Weird behaviour (GLX extension missing) in X11 forwarding since xorg-server 1.20 ...
by Stefan Dirsch 21 Aug '19

21 Aug '19

Hi I'm wondering, whether this happens to everybody using xorg-server 1.20 (1.20.3 in my case). When using X11 forwarding via ssh ssh -X <remotemachine> (DISPLAY=localhost:10.0) the list of available extensions when running xdpyinfo is limited to [...] number of extensions: 2 BIG-REQUESTS XC-MISC default screen number: 0 When running xdpyinfo local (DISPLAY=:0) it's complete: [...] number of extensions: 29 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 DRI3 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM Present RANDR RECORD RENDER SECURITY SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo XVideo-MotionCompensation default screen number: 0 [...] This happens even if you ssh to the same local machine. Can anybody reproduce this? Is this a known issue. Since now GLX extension is missing I can't run any GL application any longer via ssh ... This still works with xorg-server 1.19 for me. Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ----------------------------------------------------------------

1 0

Re: Linux Kernel 5.2.8 (uvc or i915?)
by Randy Dunlap 21 Aug '19

21 Aug '19

On 8/15/19 6:15 PM, Nathaniel Russell wrote: > I would really like help with the kernel error with my uvcvideo driver. > Hi again. What makes you think that the problem is related to the uvcvideo driver? Does some previous kernel version work correctly? If so, what version(s)? Does this warning message only happen when the uvcvideo driver is being loaded? Can you suppress loading of the uvcvideo driver to find out? Most of the problems/errors/warnings that I see are related to the i915 driver: [ 13.032341] timed out waiting for port C ready: got 0x20, expected 0xe0 [ 13.032872] WARNING: CPU: 1 PID: 239 at drivers/gpu/drm/i915/intel_display.c:1597 vlv_wait_port_ready+0x99/0xe0 [i915] [ 13.033632] RIP: 0010:vlv_wait_port_ready+0x99/0xe0 [i915] although there are a few uvcvideo warnings: [ 13.039305] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not initialized! [ 13.039318] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not initialized! [ 13.039330] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not initialized! [ 13.039339] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not initialized! Laurent, do you see any uvc issues here? Any ideas/suggestions? @intel-gfx: any ideas about what is going on here with the i915 driver? Original message to lkml: https://lore.kernel.org/lkml/CAONH+Jm-O6=DQ+K2n5pNTNMg2Sq1KcVNFLuweVh6W82OP… Previous message for 5.1.21 kernel: https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6… thanks. -- ~Randy

3 3

[Bug 111446] hello hello hello
by bugzilla-daemon＠freedesktop.org 21 Aug '19

21 Aug '19

1 0

[Bug 111445] hello hello
by bugzilla-daemon＠freedesktop.org 21 Aug '19

21 Aug '19

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019