dri-devel June 2019

dri-devel@lists.freedesktop.org

350 participants
2370 discussions

[PATCH] of/device: add blacklist for iommu dma_ops
by Rob Clark 05 Jun '19

05 Jun '19

This solves a problem we see with drm/msm, caused by getting iommu_dma_ops while we attach our own domain and manage it directly at the iommu API level: [0000000000000038] user address but active_mm is swapper Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: G W 4.19.3 #90 Hardware name: xxx (DT) Workqueue: events deferred_probe_work_func pstate: 80c00009 (Nzcv daif +PAN +UAO) pc : iommu_dma_map_sg+0x7c/0x2c8 lr : iommu_dma_map_sg+0x40/0x2c8 sp : ffffff80095eb4f0 x29: ffffff80095eb4f0 x28: 0000000000000000 x27: ffffffc0f9431578 x26: 0000000000000000 x25: 00000000ffffffff x24: 0000000000000003 x23: 0000000000000001 x22: ffffffc0fa9ac010 x21: 0000000000000000 x20: ffffffc0fab40980 x19: ffffffc0fab40980 x18: 0000000000000003 x17: 00000000000001c4 x16: 0000000000000007 x15: 000000000000000e x14: ffffffffffffffff x13: ffff000000000000 x12: 0000000000000028 x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : 0000000000000000 x8 : ffffffc0fab409a0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000100000000 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000002 x1 : ffffffc0f9431578 x0 : 0000000000000000 Process kworker/7:1 (pid: 70, stack limit = 0x0000000017d08ffb) Call trace: iommu_dma_map_sg+0x7c/0x2c8 __iommu_map_sg_attrs+0x70/0x84 get_pages+0x170/0x1e8 msm_gem_get_iova+0x8c/0x128 _msm_gem_kernel_new+0x6c/0xc8 msm_gem_kernel_new+0x4c/0x58 dsi_tx_buf_alloc_6g+0x4c/0x8c msm_dsi_host_modeset_init+0xc8/0x108 msm_dsi_modeset_init+0x54/0x18c _dpu_kms_drm_obj_init+0x430/0x474 dpu_kms_hw_init+0x5f8/0x6b4 msm_drm_bind+0x360/0x6c8 try_to_bring_up_master.part.7+0x28/0x70 component_master_add_with_match+0xe8/0x124 msm_pdev_probe+0x294/0x2b4 platform_drv_probe+0x58/0xa4 really_probe+0x150/0x294 driver_probe_device+0xac/0xe8 __device_attach_driver+0xa4/0xb4 bus_for_each_drv+0x98/0xc8 __device_attach+0xac/0x12c device_initial_probe+0x24/0x30 bus_probe_device+0x38/0x98 deferred_probe_work_func+0x78/0xa4 process_one_work+0x24c/0x3dc worker_thread+0x280/0x360 kthread+0x134/0x13c ret_from_fork+0x10/0x18 Code: d2800004 91000725 6b17039f 5400048a (f9401f40) ---[ end trace f22dda57f3648e2c ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0,22802a18 Memory Limit: none The problem is that when drm/msm does it's own iommu_attach_device(), now the domain returned by iommu_get_domain_for_dev() is drm/msm's domain, and it doesn't have domain->iova_cookie. We kind of avoided this problem prior to sdm845/dpu because the iommu was attached to the mdp node in dt, which is a child of the toplevel mdss node (which corresponds to the dev passed in dma_map_sg()). But with sdm845, now the iommu is attached at the mdss level so we hit the iommu_dma_ops in dma_map_sg(). But auto allocating/attaching a domain before the driver is probed was already a blocking problem for enabling per-context pagetables for the GPU. This problem is also now solved with this patch. Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in of_dma_configure Tested-by: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Rob Clark <robdclark(a)gmail.com> --- This is an alternative/replacement for [1]. What it lacks in elegance it makes up for in practicality ;-) [1] https://patchwork.freedesktop.org/patch/264930/ drivers/of/device.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/of/device.c b/drivers/of/device.c index 5957cd4fa262..15ffee00fb22 100644 --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -72,6 +72,14 @@ int of_device_add(struct platform_device *ofdev) return device_add(&ofdev->dev); } +static const struct of_device_id iommu_blacklist[] = { + { .compatible = "qcom,mdp4" }, + { .compatible = "qcom,mdss" }, + { .compatible = "qcom,sdm845-mdss" }, + { .compatible = "qcom,adreno" }, + {} +}; + /** * of_dma_configure - Setup DMA configuration * @dev: Device to apply DMA configuration @@ -164,6 +172,20 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma) dev_dbg(dev, "device is%sbehind an iommu\n", iommu ? " " : " not "); + /* + * There is at least one case where the driver wants to directly + * manage the IOMMU, but if we end up with iommu dma_ops, that + * interferes with the drivers ability to use dma_map_sg() for + * cache operations. Since we don't currently have a better + * solution, and this code runs before the driver is probed and + * has a chance to intervene, use a simple blacklist to avoid + * ending up with iommu dma_ops: + */ + if (of_match_device(iommu_blacklist, dev)) { + dev_dbg(dev, "skipping iommu hookup\n"); + iommu = NULL; + } + arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent); return 0; -- 2.19.2

8 25

dpms mode change with wayland on iMX.6
by Pintu Agarwal 05 Jun '19

05 Jun '19

Dear All, I have a iMX.6 (arm 32) board with Linux Kernel 3.10 and debian platform running. The board is connected to one LCD screen and one HDMI monitor. It have DRM + Wayland setup for display. Also, I noticed that it have two dri interface: /dev/dri/card0 /dev/dri/card1 I am not very familiar with Linux Graphics/Display subsystem, so I am looking for some help here. My requirement is that I have turn off HDMI display screen using a command line utility or test program. I learn that for X-server we can use xset : xset dpms force off (and it works on my ubuntu desktop with 16.04). However this command does not exists on my board. So, my question is: Is there any equivalent DPMS commands for Wayland/Wetson? --------- Further, in order to explore more, I cloned libdrm code from here: url = https://gitlab.freedesktop.org/mesa/drm Then I found some test utility under: drm/tests folder. After exploring more, and few modification, somehow I could able to cross-compile "proptest" for my board using below: arm-linux-gnueabi-gcc -o proptest.out proptest.c -I./target/libdrm_include/ -L./target/libdrm_lib/ -ldrm I found that "/dev/dri/card0" is not working with this test. So, I changed the test utility like this: fd = drmOpen("imx-drm", NULL); OR fd = open("/dev/dri/card1", O_RDWR); When I default run it on my board, I see that "Connector_id: 29" is showing for the HDMI display and it can support DPMS property. {{{ Connector 29 (11-1) 1 EDID: flags: immutable blob blobs: value: XXXXXXX 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 CRTC 24 CRTC 27 }}} Then, when I try to run it using below command: # ./proptest.out 29 connector 2 3 The program just returns successfully without any errors, but nothing happens. The display does not turns off. I saw that in my kernel 3.10 the ioctl(DRM_IOCTL_MODE_SETPROPERTY) is already supported under DRM. So, I am wondering what is the right way to verify DPMS mode property on wayland ? If anybody have any suggestions, please help me. Thanks, Pintu

3 4

[PATCH] gpu: host1x: Do not output error message for deferred probe
by Thierry Reding 05 Jun '19

05 Jun '19

From: Thierry Reding <treding(a)nvidia.com> When deferring probe, avoid logging a confusing error message. While at it, make the error message more informational. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/gpu/host1x/dev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c index c55e2d634887..5a3f797240d4 100644 --- a/drivers/gpu/host1x/dev.c +++ b/drivers/gpu/host1x/dev.c @@ -247,8 +247,11 @@ static int host1x_probe(struct platform_device *pdev) host->clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(host->clk)) { - dev_err(&pdev->dev, "failed to get clock\n"); err = PTR_ERR(host->clk); + + if (err != -EPROBE_DEFER) + dev_err(&pdev->dev, "failed to get clock: %d\n", err); + return err; } -- 2.21.0

3 9

[PATCH V2] drm/vkms: Avoid extra discount in the timestamp value
by Rodrigo Siqueira 05 Jun '19

05 Jun '19

After the commit def35e7c5926 ("drm/vkms: Bugfix extra vblank frame") some of the crc tests started to fail in the vkms with the following error: [drm:drm_crtc_add_crc_entry [drm]] *ERROR* Overflow of CRC buffer, userspace reads too slow. [drm] failed to queue vkms_crc_work_handle ... The aforementioned commit fixed the extra vblank added by `drm_crtc_arm_vblank_event()` which is invoked inside `vkms_crtc_atomic_flush()` if the vblank event count was zero, otherwise `drm_crtc_send_vblank_event()` is invoked. The fix was implemented in `vkms_get_vblank_timestamp()` by subtracting one period from the current timestamp, as the code snippet below illustrates: if (!in_vblank_irq) *vblank_time -= output->period_ns; The above fix works well when `drm_crtc_arm_vblank_event()` is invoked. However, it does not properly work when `drm_crtc_send_vblank_event()` executes since it subtracts the correct timestamp, which it shouldn't. In this case, the `drm_crtc_accurate_vblank_count()` function will returns the wrong frame number, which generates the aforementioned error. Such decrease in `get_vblank_timestamp()` produce a negative number in the following calculation within `drm_update_vblank_count()`: u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time)); After this operation, the DIV_ROUND_CLOSEST_ULL macro is invoked using diff_ns with a negative number, which generates an undefined result; therefore, the returned frame is a huge and incorrect number. Finally, the code below is part of the `vkms_crc_work_handle()`, note that the while loop depends on the returned value from `drm_crtc_accurate_vblank_count()` which may cause the loop to take a long time to finish in case of huge value. frame_end = drm_crtc_accurate_vblank_count(crtc); while (frame_start <= frame_end) drm_crtc_add_crc_entry(crtc, true, frame_start++, &crc32); This commit fixes this issue by checking if the vblank timestamp corresponding to the current software vblank counter is equal to the current vblank; if they are equal, it means that `drm_crtc_send_vblank_event()` was invoked and vkms does not need to discount the extra vblank, otherwise, `drm_crtc_arm_vblank_event()` was executed and vkms have to discount the extra vblank. This fix made the CRC tests work again whereas keep all tests from kms_flip working as well. V2: Update commit message Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Signed-off-by: Shayenne Moura <shayenneluzmoura(a)gmail.com> --- drivers/gpu/drm/vkms/vkms_crtc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c index 7508815fac11..3ce60e66673e 100644 --- a/drivers/gpu/drm/vkms/vkms_crtc.c +++ b/drivers/gpu/drm/vkms/vkms_crtc.c @@ -74,9 +74,13 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe, { struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev); struct vkms_output *output = &vkmsdev->output; + struct drm_vblank_crtc *vblank = &dev->vblank[pipe]; *vblank_time = output->vblank_hrtimer.node.expires; + if (*vblank_time == vblank->time) + return true; + if (!in_vblank_irq) *vblank_time -= output->period_ns; -- 2.21.0

2 1

[Bug 110730] [CI][RESUME] igt@kms_chamelium@hdmi-crc-single - crash - Received signal SIGSEGV.
by bugzilla-daemon＠freedesktop.org 05 Jun '19

05 Jun '19

https://bugs.freedesktop.org/show_bug.cgi?id=110730 --- Comment #6 from emersion <contact(a)emersion.fr> --- Agreed that this is an IGT bug, not a driver bug. Just sent an IGT patch that attempts to fix the issue. User impact: the user might experience corrupted frames via HDMI. In other words: we don't check anymore that HDMI is properly working since this test is broken. Other CRC/frame tests aren't run after a crash (this is the first one). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH 0/3] drm/komeda: Unify mclk/pclk/pipeline->aclk to one ACLK
by james qian wang (Arm Technology China) 05 Jun '19

05 Jun '19

Current komeda driver uses three dedicated clks for a specific purpose: - mclk: main engine clock - pclk: APB clock - pipeline->aclk: AXI clock. But per spec the komeda HW only has three input clks: - ACLK: used for AXI masters, APB slave and most pipeline processing - PXCLK for pipeline 0: output pixel clock for pipeline 0 - PXCLK for pipeline 1: output pixel clock for pipeline 1 So one ACLK is enough, no need to split it to three mclk/pclk/axiclk. Depends on: - https://patchwork.freedesktop.org/series/58710/ - https://patchwork.freedesktop.org/series/59000/ - https://patchwork.freedesktop.org/series/59002/ - https://patchwork.freedesktop.org/series/59747/ - https://patchwork.freedesktop.org/series/59915/ - https://patchwork.freedesktop.org/series/60083/ - https://patchwork.freedesktop.org/series/60698/ - https://patchwork.freedesktop.org/series/60856/ - https://patchwork.freedesktop.org/series/60893/ - https://patchwork.freedesktop.org/series/61370/ - https://patchwork.freedesktop.org/series/61379/ James Qian Wang (Arm Technology China) (3): drm/komeda: Unify mclk/pclk/pipeline->aclk to one MCLK drm/komeda: Rename main engine clk name "mclk" to "aclk" dt/bindings: drm/komeda: Unify mclk/pclk/pipeline->aclk to one ACLK .../bindings/display/arm,komeda.txt | 16 +++---- .../arm/display/komeda/d71/d71_component.c | 10 ++--- .../gpu/drm/arm/display/komeda/komeda_crtc.c | 45 +++++++------------ .../gpu/drm/arm/display/komeda/komeda_dev.c | 39 +++++----------- .../gpu/drm/arm/display/komeda/komeda_dev.h | 6 +-- .../gpu/drm/arm/display/komeda/komeda_kms.h | 6 +-- .../drm/arm/display/komeda/komeda_pipeline.c | 1 - .../drm/arm/display/komeda/komeda_pipeline.h | 6 +-- .../display/komeda/komeda_pipeline_state.c | 4 +- 9 files changed, 48 insertions(+), 85 deletions(-) -- 2.17.1

1 3

[Bug 110730] [CI][RESUME] igt@kms_chamelium@hdmi-crc-single - crash - Received signal SIGSEGV.
by bugzilla-daemon＠freedesktop.org 05 Jun '19

05 Jun '19

https://bugs.freedesktop.org/show_bug.cgi?id=110730 --- Comment #5 from Maarten Lankhorst <bugs(a)mblankhorst.nl> --- Hmm seems like an error in the chamelium wrappers. Specifically the call to pthread_cancel seems to be crashing. Need to figure out why, but shouldn't affect real users as this happens in the chamelium code. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] drm/panfrost: make devfreq optional again
by Neil Armstrong 05 Jun '19

05 Jun '19

Devfreq runtime usage was made mandatory, thus making panfrost fail to probe on Amlogic S912 SoCs missin the "operating-points-v2" property. Make it optional again, leaving PM_DEVFREQ is selected by default. Fixes: f3617b449d ("drm/panfrost: Select devfreq") Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c index 29fcffdf2d57..dc75f99ad53b 100644 --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c @@ -140,7 +140,9 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev) return 0; ret = dev_pm_opp_of_add_table(&pfdev->pdev->dev); - if (ret) + if (ret == -ENODEV) /* Optional, continue without devfreq */ + return 0; + else return ret; panfrost_devfreq_reset(pfdev); @@ -170,6 +172,9 @@ void panfrost_devfreq_resume(struct panfrost_device *pfdev) { int i; + if (!pfdev->devfreq.devfreq) + return; + panfrost_devfreq_reset(pfdev); for (i = 0; i < NUM_JOB_SLOTS; i++) pfdev->devfreq.slot[i].busy = false; @@ -179,6 +184,9 @@ void panfrost_devfreq_resume(struct panfrost_device *pfdev) void panfrost_devfreq_suspend(struct panfrost_device *pfdev) { + if (!pfdev->devfreq.devfreq) + return; + devfreq_suspend_device(pfdev->devfreq.devfreq); } @@ -188,6 +196,9 @@ static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev, i ktime_t now; ktime_t last; + if (!pfdev->devfreq.devfreq) + return; + now = ktime_get(); last = pfdev->devfreq.slot[slot].time_last_update; -- 2.21.0

2 3

[PATCH v1 0/2] drm/komeda: Add rotation support on Komeda driver
by Lowry Li (Arm Technology China) 05 Jun '19

05 Jun '19

Hi, This serie aims at adding the support for rotation on Komeda driver. For rotation, D71 doesn't support Rot90 for AFBC wide block. So this patch set also includes the limitation check. This patch series depends on: - https://patchwork.freedesktop.org/series/54449/ - https://patchwork.freedesktop.org/series/54450/ - https://patchwork.freedesktop.org/series/58710/ - https://patchwork.freedesktop.org/series/59000/ - https://patchwork.freedesktop.org/series/59002/ Regards, Lowry Lowry Li (Arm Technology China) (2): drm/komeda: Add rotation support on Komeda driver drm/komeda: Adds limitation check for AFBC wide block not support Rot90 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 15 +++++++++++++++ .../gpu/drm/arm/display/komeda/komeda_format_caps.c | 7 ++++++- .../gpu/drm/arm/display/komeda/komeda_format_caps.h | 19 ++++++++++++++++++- .../gpu/drm/arm/display/komeda/komeda_framebuffer.c | 18 +++++++++--------- .../gpu/drm/arm/display/komeda/komeda_framebuffer.h | 5 +++-- .../drm/arm/display/komeda/komeda_pipeline_state.c | 15 ++++++++++++++- drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 18 +++++++++++++++++- 7 files changed, 82 insertions(+), 15 deletions(-) -- 1.9.1

3 6

[PATCH v2 08/22] gpu: i915.rst: Fix references to renamed files
by Mauro Carvalho Chehab 05 Jun '19

05 Jun '19

WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with return code 1 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2 Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/") Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> --- Documentation/gpu/i915.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 055df45596c1..6c75380b2928 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model) Workarounds ----------- -.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c :doc: Hardware workarounds Display Hardware Handling @@ -379,10 +379,10 @@ User Batchbuffer Execution Logical Rings, Logical Ring Contexts and Execlists -------------------------------------------------- -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c :doc: Logical Rings, Logical Ring Contexts and Execlists -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c :internal: Global GTT views -- 2.21.0

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2019