dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[PATCH RESEND] drm/meson: vclk: use the correct G12A frac max value
by Neil Armstrong 30 Sep '19

30 Sep '19

When calculating the HDMI PLL settings for a DMT mode PHY frequency, use the correct max fractional PLL value for G12A VPU. With this fix, we can finally setup the 1024x768-60 mode. Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup") Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- Fixed typo in commit log, 1024x76 => 1024x768 drivers/gpu/drm/meson/meson_vclk.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/meson/meson_vclk.c b/drivers/gpu/drm/meson/meson_vclk.c index ac491a781952..f690793ae2d5 100644 --- a/drivers/gpu/drm/meson/meson_vclk.c +++ b/drivers/gpu/drm/meson/meson_vclk.c @@ -638,13 +638,18 @@ static bool meson_hdmi_pll_validate_params(struct meson_drm *priv, if (frac >= HDMI_FRAC_MAX_GXBB) return false; } else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM) || - meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXL) || - meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) { + meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXL)) { /* Empiric supported min/max dividers */ if (m < 106 || m > 247) return false; if (frac >= HDMI_FRAC_MAX_GXL) return false; + } else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) { + /* Empiric supported min/max dividers */ + if (m < 106 || m > 247) + return false; + if (frac >= HDMI_FRAC_MAX_G12A) + return false; } return true; -- 2.22.0

2 3

[PATCH v5] drm: two planes with the same zpos have undefined ordering
by Simon Ser 30 Sep '19

30 Sep '19

Currently the property docs don't specify whether it's okay for two planes to have the same zpos value and what user-space should expect in this case. The unspoken, legacy rule used in the past was to make user-space figure out the zpos from object IDs. However some drivers break this rule, that's why the ordering is documented as unspecified in case the zpos property is missing. User-space should rely on the zpos property only. There are some cases in which user-space might read identical zpos values for different planes: - In case the property is mutable, user-space might set two planes' zpos to the same value. This is necessary to support user-space using the legacy DRM API where atomic commits are not possible: user-space needs to update the planes' zpos one by one. - Some drivers might expose sets of planes which can't overlap, in which case it makes sense for the driver to assign the same zpos to these planes (e.g. some Arm GPUs). For these reasons, user-space should handle multiple planes with the same zpos. While at it, remove the assumption that zpos is only for overlay planes. Additionally, update the drm_plane_state.zpos docs to clarify that zpos disambiguation via plane object IDs is a recommendation for drivers, not something user-space can rely on. In other words, when user-space sets the same zpos on two planes, drivers should rely on the plane object ID. v2: clarify drm_plane_state.zpos docs (Daniel) v3: zpos is for all planes (Marius, Daniel) v4: completely reword the drm_plane_state.zpos docs to make it clear the recommendation to use plane IDs is for drivers in case user-space uses duplicate zpos values (Pekka) v5: reword commit message (Pekka, James) Signed-off-by: Simon Ser <contact(a)emersion.fr> Reviewed-by: Pekka Paalanen <ppaalanen(a)gmail.com> Cc: Marius Vlad <marius.vlad(a)collabora.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: James Qian Wang <james.qian.wang(a)arm.com> --- drivers/gpu/drm/drm_blend.c | 8 ++++---- include/drm/drm_plane.h | 9 +++++---- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index d02709dd2d4a..121481f6aa71 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -132,10 +132,10 @@ * planes. Without this property the primary plane is always below the cursor * plane, and ordering between all other planes is undefined. The positive * Z axis points towards the user, i.e. planes with lower Z position values - * are underneath planes with higher Z position values. Note that the Z - * position value can also be immutable, to inform userspace about the - * hard-coded stacking of overlay planes, see - * drm_plane_create_zpos_immutable_property(). + * are underneath planes with higher Z position values. Two planes with the + * same Z position value have undefined ordering. Note that the Z position + * value can also be immutable, to inform userspace about the hard-coded + * stacking of planes, see drm_plane_create_zpos_immutable_property(). * * pixel blend mode: * Pixel blend mode is set up with drm_plane_create_blend_mode_property(). diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index cd5903ad33f7..328773690851 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -140,10 +140,11 @@ struct drm_plane_state { * @zpos: * Priority of the given plane on crtc (optional). * - * Note that multiple active planes on the same crtc can have an - * identical zpos value. The rule to solving the conflict is to compare - * the plane object IDs; the plane with a higher ID must be stacked on - * top of a plane with a lower ID. + * User-space may set mutable zpos properties so that multiple active + * planes on the same CRTC have identical zpos values. This is a + * user-space bug, but drivers can solve the conflict by comparing the + * plane object IDs; the plane with a higher ID is stacked on top of a + * plane with a lower ID. * * See drm_plane_create_zpos_property() and * drm_plane_create_zpos_immutable_property() for more details. -- 2.23.0

1 0

[PATCH v4 10/11] drm/amdgpu: job is secure iff CS is secure (v5)
by Huang, Ray 30 Sep '19

30 Sep '19

Mark a job as secure, if and only if the command submission flag has the secure flag set. v2: fix the null job pointer while in vmid 0 submission. v3: Context --> Command submission. v4: filling cs parser with cs->in.flags v5: move the job secure flag setting out of amdgpu_cs_submit() Signed-off-by: Huang Rui <ray.huang(a)amd.com> Co-developed-by: Luben Tuikov <luben.tuikov(a)amd.com> Signed-off-by: Luben Tuikov <luben.tuikov(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 2 ++ 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 49b767b..c18a153 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -231,6 +231,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs if (ret) goto free_all_kdata; + p->job->secure = cs->in.flags & AMDGPU_CS_FLAGS_SECURE; + if (p->ctx->vram_lost_counter != p->job->vram_lost_counter) { ret = -ECANCELED; goto free_all_kdata; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c index 9a6dbf3..6e0f97a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c @@ -213,7 +213,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs, if (job && ring->funcs->emit_cntxcntl) { status |= job->preamble_status; status |= job->preemption_status; - amdgpu_ring_emit_cntxcntl(ring, status, false); + amdgpu_ring_emit_cntxcntl(ring, status, job->secure); } for (i = 0; i < num_ibs; ++i) { @@ -232,7 +232,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs, } if (ring->funcs->emit_tmz) - amdgpu_ring_emit_tmz(ring, false, false); + amdgpu_ring_emit_tmz(ring, false, job ? job->secure : false); #ifdef CONFIG_X86_64 if (!(adev->flags & AMD_IS_APU)) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h index dc7ee93..aa0e375 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h @@ -63,6 +63,8 @@ struct amdgpu_job { uint64_t uf_addr; uint64_t uf_sequence; + /* the job is due to a secure command submission */ + bool secure; }; int amdgpu_job_alloc(struct amdgpu_device *adev, unsigned num_ibs, -- 2.7.4

2 1

[Bug 205043] New: Plugging in AC adapter after boot causes ´*ERROR* suspend of IP block <powerplay> failed -22´ error
by bugzilla-daemon＠bugzilla.kernel.org 30 Sep '19

30 Sep '19

https://bugzilla.kernel.org/show_bug.cgi?id=205043 Bug ID: 205043 Summary: Plugging in AC adapter after boot causes ´*ERROR* suspend of IP block <powerplay> failed -22´ error Product: Drivers Version: 2.5 Kernel Version: 5.3.1-050301-generic Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: proje.pdf(a)outlook.com Regression: No Created attachment 285239 --> https://bugzilla.kernel.org/attachment.cgi?id=285239&action=edit journalctl log Error doesn't happen when AC adapter is plugged in before boot First error message in log: Sep 29 15:24:19 pop-os kernel: amdgpu: [powerplay] Trying to disable SCLK DPM when DPM is disabled Sep 29 15:24:19 pop-os kernel: amdgpu: [powerplay] Trying to disable voltage DPM when DPM is disabled Sep 29 15:24:19 pop-os kernel: amdgpu: [powerplay] Failed to force to switch arbf0! Sep 29 15:24:19 pop-os kernel: amdgpu: [powerplay] [disable_dpm_tasks] Failed to disable DPM! Sep 29 15:24:19 pop-os kernel: [drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block <powerplay> failed -22 Sep 29 15:24:19 pop-os kernel: cp is busy, skip halt cp Sep 29 15:24:19 pop-os kernel: rlc is busy, skip halt rlc Sep 29 15:24:20 pop-os kernel: amdgpu 0000:03:00.0: GPU pci config reset Sep 29 15:24:20 pop-os sudo[27651]: pam_unix(sudo:session): session closed for user root Sep 29 15:24:20 pop-os kernel: amdgpu: [powerplay] last message was failed ret is 65535 Sep 29 15:24:20 pop-os kernel: amdgpu: [powerplay] failed to send message 171 ret is 65535 -- You are receiving this mail because: You are watching the assignee of the bug.

1 1

[Bug 111858] [ICL] IGT tests kms_ccs and kms_frontbuffer_tracking fail on latest drm-tip kernel
by bugzilla-daemon＠freedesktop.org 30 Sep '19

30 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111858 Bug ID: 111858 Summary: [ICL] IGT tests kms_ccs and kms_frontbuffer_tracking fail on latest drm-tip kernel Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: not set Component: IGT Assignee: dri-devel(a)lists.freedesktop.org Reporter: yue.he(a)intel.com Created attachment 145585 --> https://bugs.freedesktop.org/attachment.cgi?id=145585&action=edit kms_frontbuffer_tracking On Ubuntu 16.04 on ICL-U D0 board, replace kernel to 5.3.0-rc8: git clone https://github.com/freedesktop/drm-tip Then git clone https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Build igt test tool. Then run the igt test on console terminal as root ./kms_ccs IGT-Version: 1.24-g924e5c5 (x86_64) (Linux: 5.3.0-rc8 x86_64) Subtest pipe-A-crc-primary-basic: CRASH (0.004s) Starting subtest: pipe-A-crc-primary-rotation-180 Subtest pipe-A-crc-primary-rotation-180: CRASH (0.004s) Starting subtest: pipe-A-crc-sprite-planes-basic Starting subtest: pipe-B-crc-primary-basic Subtest pipe-B-crc-primary-basic: CRASH (0.001s) Starting subtest: pipe-B-crc-primary-rotation-180 Subtest pipe-B-crc-primary-rotation-180: CRASH (0.001s) The 4 tests are crash. Run the gem_basic, the subtests of gem_basic are all pass. Run the ./ kms_frontbuffer_tracking, there are error: Stack trace: #0 /home/hdr/igt-gpu-tools/lib/igt_core.c:1696 __igt_fail_assert() #1 /home/hdr/igt-gpu-tools/tests/kms_frontbuffer_tracking.c:1274 __real_main3273() #2 /home/hdr/igt-gpu-tools/tests/kms_frontbuffer_tracking.c:3273 main() #3 ../csu/libc-start.c:325 __libc_start_main() #4 [_start+0x29] #5 [<unknown>+0x0] And all subtest fail. -- You are receiving this mail because: You are the assignee for the bug.

1 4

X11 + console switch - how does it actually work ?
by Enrico Weigelt, metux IT consult 29 Sep '19

29 Sep '19

Hello folks, could anybody please give me some more insight, how switching from X to console (ctrl+alt+f*) actually works ? Who catches the keypress event and initiates the VT switch ? The Xserver ? Could this be done in the kernel (eg. when Xserver is hanging) ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info(a)metux.net -- +49-151-27565287

2 1

[PATCH] drm/tegra: Fix ordering of cleanup code
by Thierry Reding 29 Sep '19

29 Sep '19

From: Thierry Reding <treding(a)nvidia.com> Commit Fixes: b9f8b09ce256 ("drm/tegra: Setup shared IOMMU domain after initialization") changed the initialization order of the IOMMU related bits but didn't update the cleanup path accordingly. This asymmetry can cause failures during error recovery. Fixes: b9f8b09ce256 ("drm/tegra: Setup shared IOMMU domain after initialization") Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/gpu/drm/tegra/drm.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 6fb7d74ff553..bc7cc32140f8 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -201,19 +201,19 @@ static int tegra_drm_load(struct drm_device *drm, unsigned long flags) if (tegra->hub) tegra_display_hub_cleanup(tegra->hub); device: - host1x_device_exit(device); -fbdev: - drm_kms_helper_poll_fini(drm); - tegra_drm_fb_free(drm); -config: - drm_mode_config_cleanup(drm); - if (tegra->domain) { mutex_destroy(&tegra->mm_lock); drm_mm_takedown(&tegra->mm); put_iova_domain(&tegra->carveout.domain); iova_cache_put(); } + + host1x_device_exit(device); +fbdev: + drm_kms_helper_poll_fini(drm); + tegra_drm_fb_free(drm); +config: + drm_mode_config_cleanup(drm); domain: if (tegra->domain) iommu_domain_free(tegra->domain); -- 2.23.0

2 1

[Bug 111747] [CI][DRMTIP] igt@ - incomplete - Jenkins gives up
by bugzilla-daemon＠freedesktop.org 29 Sep '19

29 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111747 --- Comment #13 from CI Bug Log <cibuglog(a)gmail.com> --- A CI Bug Log filter associated to this bug has been updated: {- TGL: igt@* -incomplete - Abort requested by .* terminating children -} {+ TGL: igt@* -incomplete - Abort requested by .* terminating children +} New failures caught by the filter: * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_380/fi-tgl-u2/igt@kms_rotat… -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 111747] [CI][DRMTIP] igt@ - incomplete - Jenkins gives up
by bugzilla-daemon＠freedesktop.org 29 Sep '19

29 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111747 --- Comment #12 from CI Bug Log <cibuglog(a)gmail.com> --- A CI Bug Log filter associated to this bug has been updated: {- TGL: igt@* -incomplete - Abort requested by .* terminating children -} {+ TGL: igt@* -incomplete - Abort requested by .* terminating children +} New failures caught by the filter: * https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-tglb4/igt@kms_ro… -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH V2] drm/amdgpu: remove set but not used variable 'pipe'
by yu kuai 29 Sep '19

29 Sep '19

Fixes gcc '-Wunused-but-set-variable' warning: rivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c: In function ‘amdgpu_gfx_graphics_queue_acquire’: drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:234:16: warning: variable ‘pipe’ set but not used [-Wunused-but-set-variable] It is never used, so can be removed. Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: yu kuai <yukuai3(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c index f9bef31..c1035a3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c @@ -231,12 +231,10 @@ void amdgpu_gfx_compute_queue_acquire(struct amdgpu_device *adev) void amdgpu_gfx_graphics_queue_acquire(struct amdgpu_device *adev) { - int i, queue, pipe, me; + int i, queue, me; for (i = 0; i < AMDGPU_MAX_GFX_QUEUES; ++i) { queue = i % adev->gfx.me.num_queue_per_pipe; - pipe = (i / adev->gfx.me.num_queue_per_pipe) - % adev->gfx.me.num_pipe_per_me; me = (i / adev->gfx.me.num_queue_per_pipe) / adev->gfx.me.num_pipe_per_me; -- 2.7.4

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019