dri-devel May 2018

dri-devel@lists.freedesktop.org

268 participants
1833 discussions

[Bug 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set
by bugzilla-daemon＠freedesktop.org 07 May '18

07 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=105971 Bug ID: 105971 Summary: DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: sass.joel(a)gmail.com Created attachment 138731 --> https://bugs.freedesktop.org/attachment.cgi?id=138731&action=edit dmesg output from amdgpu.dc=0 switch Hello. I'm trying to get 4 monitors working on the same desktop. Video card is a Radeon RX560. root@nope:/tmp# lsb_release -a LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch Distributor ID: Ubuntu Description: Ubuntu 16.04.4 LTS Release: 16.04 Codename: xenial root@nope:/tmp# uname -a Linux nope 4.16.0+ #1 SMP Mon Apr 2 15:52:14 CEST 2018 x86_64 x86_64 x86_64 GNU/Linux With kernel switch amdgpu.dc=1, DVI port doesn't detected connected monitor, but displayport MST is detected and utilized properly, allowing me to output video to three monitors from a single displayport. With kernel switch amdgpu.dc=0, DVI port properly detects connected monitor, but displayport MST is not detected. Instead, displayport MST acts as a single output, and video output is mirrored to all three connected monitors. This appears to be a kernel issue. Kernel was retrieved from git repo github.com/M-Bab/linux-kernel-amdgpu-binaries I'm running the AMDGPU.UBUNTU kernel on that repo. I'll attach dmesg, xrandr and Xorg.0.log output from both kernel switches. I'm running amdgpu.dc_log=1 kernel switch for verbose logging. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)
by bugzilla-daemon＠freedesktop.org 07 May '18

07 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=104001 Bug ID: 104001 Summary: GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: mikhail.v.gavrilov(a)gmail.com Created attachment 135839 --> https://bugs.freedesktop.org/attachment.cgi?id=135839&action=edit dmesg * Fedora 27 - https://download.fedoraproject.org/pub/fedora/linux/releases/27/Workstation… * staging kernel - git://people.freedesktop.org/~agd5f/linux branch amd-staging-drm-next * mesa 17.4 and llvm 6.0 - https://copr.fedorainfracloud.org/coprs/che/mesa/ For reproduction issue: 1) Start playback video on Youtube in browser (Firefox ot Opera it's not matter) 2) Launch Steam client After few seconds GPU driver will hung... Demonstration: https://youtu.be/2LuWI47oCFg If we wait after it more than two minutes we got follow backtrace: [ 492.840627] INFO: task kworker/u16:5:147 blocked for more than 120 seconds. [ 492.840641] Not tainted 4.14.0-rc3-amd-vega+ #5 [ 492.840644] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 492.840648] kworker/u16:5 D11392 147 2 0x80000000 [ 492.840662] Workqueue: events_unbound commit_work [drm_kms_helper] [ 492.840666] Call Trace: [ 492.840674] __schedule+0x2dc/0xbb0 [ 492.840681] schedule+0x33/0x90 [ 492.840694] schedule_timeout+0x288/0x5c0 [ 492.840701] ? mark_held_locks+0x57/0x80 [ 492.840704] ? _raw_spin_unlock_irqrestore+0x36/0x60 [ 492.840713] dma_fence_default_wait+0x22a/0x380 [ 492.840716] ? dma_fence_default_wait+0x22a/0x380 [ 492.840720] ? dma_fence_release+0x170/0x170 [ 492.840725] dma_fence_wait_timeout+0x4f/0x270 [ 492.840729] reservation_object_wait_timeout_rcu+0x18d/0x510 [ 492.840768] amdgpu_dm_do_flip+0x12b/0x390 [amdgpu] [ 492.840801] amdgpu_dm_atomic_commit_tail+0xbe1/0xe80 [amdgpu] [ 492.840815] commit_tail+0x3f/0x70 [drm_kms_helper] [ 492.840820] commit_work+0x12/0x20 [drm_kms_helper] [ 492.840824] process_one_work+0x26b/0x6c0 [ 492.840832] worker_thread+0x35/0x3b0 [ 492.840837] kthread+0x171/0x190 [ 492.840840] ? process_one_work+0x6c0/0x6c0 [ 492.840843] ? kthread_create_on_node+0x70/0x70 [ 492.840847] ? kthread_create_on_node+0x70/0x70 [ 492.840850] ret_from_fork+0x2a/0x40 [ 492.840906] INFO: task amdgpu_cs:0:2013 blocked for more than 120 seconds. [ 492.840909] Not tainted 4.14.0-rc3-amd-vega+ #5 [ 492.840912] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 492.840915] amdgpu_cs:0 D13312 2013 1981 0x00000000 [ 492.840921] Call Trace: [ 492.840926] __schedule+0x2dc/0xbb0 [ 492.840931] ? save_stack_trace+0x1b/0x20 [ 492.840936] schedule+0x33/0x90 [ 492.840939] schedule_timeout+0x288/0x5c0 [ 492.840944] ? mark_held_locks+0x57/0x80 [ 492.840947] ? _raw_spin_unlock_irqrestore+0x36/0x60 [ 492.840951] ? trace_hardirqs_on_caller+0xf4/0x190 [ 492.840957] dma_fence_default_wait+0x22a/0x380 [ 492.840960] ? dma_fence_default_wait+0x22a/0x380 [ 492.840964] ? dma_fence_release+0x170/0x170 [ 492.840969] dma_fence_wait_timeout+0x4f/0x270 [ 492.840987] amdgpu_ctx_wait_prev_fence+0x4a/0x80 [amdgpu] [ 492.841003] amdgpu_cs_ioctl+0xaf/0x1eb0 [amdgpu] [ 492.841038] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [ 492.841051] drm_ioctl_kernel+0x5d/0xb0 [drm] [ 492.841060] drm_ioctl+0x31b/0x3d0 [drm] [ 492.841074] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [ 492.841081] ? trace_hardirqs_on_caller+0xf4/0x190 [ 492.841085] ? trace_hardirqs_on+0xd/0x10 [ 492.841101] amdgpu_drm_ioctl+0x4f/0x90 [amdgpu] [ 492.841107] do_vfs_ioctl+0xa6/0x6c0 [ 492.841115] SyS_ioctl+0x79/0x90 [ 492.841120] entry_SYSCALL_64_fastpath+0x1f/0xbe [ 492.841123] RIP: 0033:0x7f7eb9078dc7 [ 492.841125] RSP: 002b:00007f7eb0c479b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 492.841130] RAX: ffffffffffffffda RBX: 00000000025f5ab8 RCX: 00007f7eb9078dc7 [ 492.841132] RDX: 00007f7eb0c47a20 RSI: 00000000c0186444 RDI: 000000000000000b [ 492.841134] RBP: 000000000266f860 R08: 00007f7eb0c47ad0 R09: 00007f7eb0c47a00 [ 492.841136] R10: 00007f7eb0c47ad0 R11: 0000000000000246 R12: 0000000000000007 [ 492.841138] R13: 0000000000000001 R14: 00000000025f5ab8 R15: 0000000000000000 [ 492.841171] INFO: task kworker/3:3:2263 blocked for more than 120 seconds. [ 492.841174] Not tainted 4.14.0-rc3-amd-vega+ #5 [ 492.841177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 492.841180] kworker/3:3 D13448 2263 2 0x80000000 [ 492.841190] Workqueue: events ttm_bo_delayed_workqueue [ttm] [ 492.841194] Call Trace: [ 492.841199] __schedule+0x2dc/0xbb0 [ 492.841206] schedule+0x33/0x90 [ 492.841209] schedule_preempt_disabled+0x15/0x20 [ 492.841212] __ww_mutex_lock.constprop.9+0xa6f/0x10a0 [ 492.841216] ? __lock_is_held+0x59/0xa0 [ 492.841220] ? ttm_bo_delayed_delete+0x108/0x1b0 [ttm] [ 492.841228] ww_mutex_lock+0x5e/0x70 [ 492.841231] ? ww_mutex_lock+0x5e/0x70 [ 492.841235] ttm_bo_delayed_delete+0x108/0x1b0 [ttm] [ 492.841243] ttm_bo_delayed_workqueue+0x1b/0x40 [ttm] [ 492.841246] process_one_work+0x26b/0x6c0 [ 492.841253] worker_thread+0x35/0x3b0 [ 492.841259] kthread+0x171/0x190 [ 492.841262] ? process_one_work+0x6c0/0x6c0 [ 492.841264] ? kthread_create_on_node+0x70/0x70 [ 492.841269] ret_from_fork+0x2a/0x40 [ 492.841323] Showing all locks held in the system: [ 492.841332] 1 lock held by khungtaskd/62: [ 492.841336] #0: (tasklist_lock){.+.+}, at: [<ffffffffba1116ed>] debug_show_all_locks+0x3d/0x1a0 [ 492.841353] 3 locks held by kworker/u16:5/147: [ 492.841355] #0: ("events_unbound"){+.+.}, at: [<ffffffffba0ceb41>] process_one_work+0x1e1/0x6c0 [ 492.841365] #1: ((&state->commit_work)){+.+.}, at: [<ffffffffba0ceb41>] process_one_work+0x1e1/0x6c0 [ 492.841376] #2: (reservation_ww_class_mutex){+.+.}, at: [<ffffffffc03bbbea>] amdgpu_dm_do_flip+0xea/0x390 [amdgpu] [ 492.841451] 1 lock held by gnome-shell/1981: [ 492.841453] #0: (reservation_ww_class_mutex){+.+.}, at: [<ffffffffc0273626>] ttm_bo_vm_fault+0x66/0x5d0 [ttm] [ 492.841468] 1 lock held by amdgpu_cs:0/2013: [ 492.841470] #0: (&ctx->lock){+.+.}, at: [<ffffffffc02e4d4e>] amdgpu_cs_ioctl+0x59e/0x1eb0 [amdgpu] [ 492.841513] 3 locks held by kworker/3:3/2263: [ 492.841515] #0: ("events"){+.+.}, at: [<ffffffffba0ceb41>] process_one_work+0x1e1/0x6c0 [ 492.841526] #1: ((&(&bdev->wq)->work)){+.+.}, at: [<ffffffffba0ceb41>] process_one_work+0x1e1/0x6c0 [ 492.841536] #2: (reservation_ww_class_mutex){+.+.}, at: [<ffffffffc026f948>] ttm_bo_delayed_delete+0x108/0x1b0 [ttm] [ 492.841623] 1 lock held by steamerrorrepor/4598: [ 492.841625] #0: (drm_global_mutex){+.+.}, at: [<ffffffffc01f86ab>] drm_release+0x3b/0x3b0 [drm] [ 492.841644] ============================================= -- You are receiving this mail because: You are the assignee for the bug.

1 42

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'
by Randy Dunlap 07 May '18

07 May '18

On 05/05/2018 04:22 PM, kbuild test robot wrote: > Hi Maciej, > > FYI, the error/warning still remains. Hi M. Robot, I am cc-ing dri-devel(a)lists.freedesktop.org so that they are aware of the multiple times that you have posted this kbuild error (I have 3 different posts in my Inbox with the same errors; I may have missed some). I hope that someone there will have some insights into this problem. I have looked at the issues and concluded that the correct fix for this IMO is: config DRM_SIL_SII8620 ... depends on EXTCON || !EXTCON However, that causes some unhappy errors from scripts/kconfig/ concerning Kconfig recursive dependencies detected. Alternatively, using select EXTCON does not cause any kconfig recursive dependency issues and solves the build errors. thanks! > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > head: c1c07416cdd47161a359286021d483f449ad8c4f > commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL > date: 8 weeks ago > config: i386-randconfig-c0-05060527 (attached as .config) > compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 > reproduce: > git checkout 688838442147d9dd94c2ef7c2c31a35cf150c5fa > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > > drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove': > drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier' > drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_init': >>> drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node' >>> drivers/gpu/drm/bridge/sil-sii8620.c:2241: undefined reference to `extcon_register_notifier' > drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_work': > drivers/gpu/drm/bridge/sil-sii8620.c:2189: undefined reference to `extcon_get_state' > > vim +2229 drivers/gpu/drm/bridge/sil-sii8620.c > > 2212 > 2213 static int sii8620_extcon_init(struct sii8620 *ctx) > 2214 { > 2215 struct extcon_dev *edev; > 2216 struct device_node *musb, *muic; > 2217 int ret; > 2218 > 2219 /* get micro-USB connector node */ > 2220 musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1); > 2221 /* next get micro-USB Interface Controller node */ > 2222 muic = of_get_next_parent(musb); > 2223 > 2224 if (!muic) { > 2225 dev_info(ctx->dev, "no extcon found, switching to 'always on' mode\n"); > 2226 return 0; > 2227 } > 2228 >> 2229 edev = extcon_find_edev_by_node(muic); > 2230 of_node_put(muic); > 2231 if (IS_ERR(edev)) { > 2232 if (PTR_ERR(edev) == -EPROBE_DEFER) > 2233 return -EPROBE_DEFER; > 2234 dev_err(ctx->dev, "Invalid or missing extcon\n"); > 2235 return PTR_ERR(edev); > 2236 } > 2237 > 2238 ctx->extcon = edev; > 2239 ctx->extcon_nb.notifier_call = sii8620_extcon_notifier; > 2240 INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work); >> 2241 ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb); > 2242 if (ret) { > 2243 dev_err(ctx->dev, "failed to register notifier for MHL\n"); > 2244 return ret; > 2245 } > 2246 > 2247 return 0; > 2248 } > 2249 > 2250 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge) > 2251 { > 2252 return container_of(bridge, struct sii8620, bridge); > 2253 } > 2254 > 2255 static int sii8620_attach(struct drm_bridge *bridge) > 2256 { > 2257 struct sii8620 *ctx = bridge_to_sii8620(bridge); > 2258 > 2259 sii8620_init_rcp_input_dev(ctx); > 2260 > 2261 return sii8620_clear_error(ctx); > 2262 } > 2263 > 2264 static void sii8620_detach(struct drm_bridge *bridge) > 2265 { > 2266 struct sii8620 *ctx = bridge_to_sii8620(bridge); > 2267 > 2268 rc_unregister_device(ctx->rc_dev); > 2269 } > 2270 > 2271 static enum drm_mode_status sii8620_mode_valid(struct drm_bridge *bridge, > 2272 const struct drm_display_mode *mode) > 2273 { > 2274 struct sii8620 *ctx = bridge_to_sii8620(bridge); > 2275 bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] & > 2276 MHL_DCAP_VID_LINK_PPIXEL; > 2277 unsigned int max_pclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : > 2278 MHL1_MAX_LCLK; > 2279 max_pclk /= can_pack ? 2 : 3; > 2280 > 2281 return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH : MODE_OK; > 2282 } > 2283 > 2284 static bool sii8620_mode_fixup(struct drm_bridge *bridge, > 2285 const struct drm_display_mode *mode, > 2286 struct drm_display_mode *adjusted_mode) > 2287 { > 2288 struct sii8620 *ctx = bridge_to_sii8620(bridge); > 2289 int max_lclk; > 2290 bool ret = true; > 2291 > 2292 mutex_lock(&ctx->lock); > 2293 > 2294 max_lclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : MHL1_MAX_LCLK; > 2295 if (max_lclk > 3 * adjusted_mode->clock) { > 2296 ctx->use_packed_pixel = 0; > 2297 goto end; > 2298 } > 2299 if ((ctx->devcap[MHL_DCAP_VID_LINK_MODE] & MHL_DCAP_VID_LINK_PPIXEL) && > 2300 max_lclk > 2 * adjusted_mode->clock) { > 2301 ctx->use_packed_pixel = 1; > 2302 goto end; > 2303 } > 2304 ret = false; > 2305 end: > 2306 if (ret) { > 2307 u8 vic = drm_match_cea_mode(adjusted_mode); > 2308 > 2309 if (!vic) { > 2310 union hdmi_infoframe frm; > 2311 u8 mhl_vic[] = { 0, 95, 94, 93, 98 }; > 2312 > 2313 /* FIXME: We need the connector here */ > 2314 drm_hdmi_vendor_infoframe_from_display_mode( > 2315 &frm.vendor.hdmi, NULL, adjusted_mode); > 2316 vic = frm.vendor.hdmi.vic; > 2317 if (vic >= ARRAY_SIZE(mhl_vic)) > 2318 vic = 0; > 2319 vic = mhl_vic[vic]; > 2320 } > 2321 ctx->video_code = vic; > 2322 ctx->pixel_clock = adjusted_mode->clock; > 2323 } > 2324 mutex_unlock(&ctx->lock); > 2325 return ret; > 2326 } > 2327 > 2328 static const struct drm_bridge_funcs sii8620_bridge_funcs = { > 2329 .attach = sii8620_attach, > 2330 .detach = sii8620_detach, > 2331 .mode_fixup = sii8620_mode_fixup, > 2332 .mode_valid = sii8620_mode_valid, > 2333 }; > 2334 > 2335 static int sii8620_probe(struct i2c_client *client, > 2336 const struct i2c_device_id *id) > 2337 { > 2338 struct device *dev = &client->dev; > 2339 struct sii8620 *ctx; > 2340 int ret; > 2341 > 2342 ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); > 2343 if (!ctx) > 2344 return -ENOMEM; > 2345 > 2346 ctx->dev = dev; > 2347 mutex_init(&ctx->lock); > 2348 INIT_LIST_HEAD(&ctx->mt_queue); > 2349 > 2350 ctx->clk_xtal = devm_clk_get(dev, "xtal"); > 2351 if (IS_ERR(ctx->clk_xtal)) { > 2352 dev_err(dev, "failed to get xtal clock from DT\n"); > 2353 return PTR_ERR(ctx->clk_xtal); > 2354 } > 2355 > 2356 if (!client->irq) { > 2357 dev_err(dev, "no irq provided\n"); > 2358 return -EINVAL; > 2359 } > 2360 irq_set_status_flags(client->irq, IRQ_NOAUTOEN); > 2361 ret = devm_request_threaded_irq(dev, client->irq, NULL, > 2362 sii8620_irq_thread, > 2363 IRQF_TRIGGER_HIGH | IRQF_ONESHOT, > 2364 "sii8620", ctx); > 2365 if (ret < 0) { > 2366 dev_err(dev, "failed to install IRQ handler\n"); > 2367 return ret; > 2368 } > 2369 > 2370 ctx->gpio_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH); > 2371 if (IS_ERR(ctx->gpio_reset)) { > 2372 dev_err(dev, "failed to get reset gpio from DT\n"); > 2373 return PTR_ERR(ctx->gpio_reset); > 2374 } > 2375 > 2376 ctx->supplies[0].supply = "cvcc10"; > 2377 ctx->supplies[1].supply = "iovcc18"; > 2378 ret = devm_regulator_bulk_get(dev, 2, ctx->supplies); > 2379 if (ret) > 2380 return ret; > 2381 > 2382 ret = sii8620_extcon_init(ctx); > 2383 if (ret < 0) { > 2384 dev_err(ctx->dev, "failed to initialize EXTCON\n"); > 2385 return ret; > 2386 } > 2387 > 2388 i2c_set_clientdata(client, ctx); > 2389 > 2390 ctx->bridge.funcs = &sii8620_bridge_funcs; > 2391 ctx->bridge.of_node = dev->of_node; > 2392 drm_bridge_add(&ctx->bridge); > 2393 > 2394 if (!ctx->extcon) > 2395 sii8620_cable_in(ctx); > 2396 > 2397 return 0; > 2398 } > 2399 > 2400 static int sii8620_remove(struct i2c_client *client) > 2401 { > 2402 struct sii8620 *ctx = i2c_get_clientdata(client); > 2403 > 2404 if (ctx->extcon) { >> 2405 extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL, > 2406 &ctx->extcon_nb); > 2407 flush_work(&ctx->extcon_wq); > 2408 if (ctx->cable_state > 0) > 2409 sii8620_cable_out(ctx); > 2410 } else { > 2411 sii8620_cable_out(ctx); > 2412 } > 2413 drm_bridge_remove(&ctx->bridge); > 2414 > 2415 return 0; > 2416 } > 2417 > > --- > 0-DAY kernel test infrastructure Open Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation -- ~Randy

2 3

[PATCH 1/2] staging: android: ion: Fix license identifier comment format
by Nathan Chancellor 07 May '18

07 May '18

checkpatch.pl complains these are invalid because the rules in Documentation/process/license-rules.rst state that C headers should have "/* */" style comments. Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> --- drivers/staging/android/ion/ion.h | 2 +- drivers/staging/android/uapi/ion.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/android/ion/ion.h b/drivers/staging/android/ion/ion.h index ea0897812780..16cbd38a7160 100644 --- a/drivers/staging/android/ion/ion.h +++ b/drivers/staging/android/ion/ion.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License-Identifier: GPL-2.0 */ /* * drivers/staging/android/ion/ion.h * diff --git a/drivers/staging/android/uapi/ion.h b/drivers/staging/android/uapi/ion.h index 825d3e95ccd3..5d7009884c13 100644 --- a/drivers/staging/android/uapi/ion.h +++ b/drivers/staging/android/uapi/ion.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License-Identifier: GPL-2.0 */ /* * drivers/staging/android/uapi/ion.h * -- 2.17.0

2 5

[PATCH] drm/msm/gpu: Add submit queue queries
by Jordan Crouse 07 May '18

07 May '18

Add the capability to query information from a submit queue. The first available parameter is for querying the number of GPU faults (hangs) that can be attributed to the queue. This is useful for implementing context robustness. A UMD context can regularly query the number of faults to see if it is responsible for any. If so it can invalidate itself. This is also helpful for testing by confirming to the user mode driver if a particular command stream caused a fault (or not as the case may be). Signed-off-by: Jordan Crouse <jcrouse(a)codeaurora.org> --- drivers/gpu/drm/msm/msm_drv.c | 12 +++++++++++- drivers/gpu/drm/msm/msm_drv.h | 2 ++ drivers/gpu/drm/msm/msm_gpu.c | 3 +++ drivers/gpu/drm/msm/msm_submitqueue.c | 21 +++++++++++++++++++++ include/uapi/drm/msm_drm.h | 12 ++++++++++++ 5 files changed, 49 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index 30cd514d8f7c..d01fb101d5ff 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -32,9 +32,10 @@ * - 1.3.0 - adds GMEM_BASE + NR_RINGS params, SUBMITQUEUE_NEW + * SUBMITQUEUE_CLOSE ioctls, and MSM_INFO_IOVA flag for * MSM_GEM_INFO ioctl. + * - 1.4.0 - Add SUBMITQUERY_QUERY ioctl. */ #define MSM_VERSION_MAJOR 1 -#define MSM_VERSION_MINOR 3 +#define MSM_VERSION_MINOR 4 #define MSM_VERSION_PATCHLEVEL 0 static const struct drm_mode_config_funcs mode_config_funcs = { @@ -803,6 +804,14 @@ static int msm_ioctl_submitqueue_new(struct drm_device *dev, void *data, args->flags, &args->id); } +static int msm_ioctl_submitqueue_query(struct drm_device *dev, void *data, + struct drm_file *file) +{ + struct drm_msm_submitqueue_query *args = data; + + return msm_submitqueue_query(dev, file->driver_priv, args->id, + args->param, args->data, args->len); +} static int msm_ioctl_submitqueue_close(struct drm_device *dev, void *data, struct drm_file *file) @@ -823,6 +832,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = { DRM_IOCTL_DEF_DRV(MSM_GEM_MADVISE, msm_ioctl_gem_madvise, DRM_AUTH|DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW, msm_ioctl_submitqueue_new, DRM_AUTH|DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close, DRM_AUTH|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query, DRM_AUTH|DRM_RENDER_ALLOW), }; static const struct vm_operations_struct vm_ops = { diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h index 48ed5b9a8580..56c666f25aa1 100644 --- a/drivers/gpu/drm/msm/msm_drv.h +++ b/drivers/gpu/drm/msm/msm_drv.h @@ -320,6 +320,8 @@ struct msm_gpu_submitqueue *msm_submitqueue_get(struct msm_file_private *ctx, u32 id); int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private *ctx, u32 prio, u32 flags, u32 *id); +int msm_submitqueue_query(struct drm_device *drm, struct msm_file_private *ctx, + u32 id, u32 param, u64 data, u32 len); int msm_submitqueue_remove(struct msm_file_private *ctx, u32 id); void msm_submitqueue_close(struct msm_file_private *ctx); diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index 1c09acfb4028..925532197584 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -324,6 +324,9 @@ static void recover_worker(struct work_struct *work) if (submit) { struct task_struct *task; + /* Increment the submitqueue fault count */ + submit->queue->faults++; + rcu_read_lock(); task = pid_task(submit->pid, PIDTYPE_PID); if (task) { diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c b/drivers/gpu/drm/msm/msm_submitqueue.c index 5115f75b5b7f..e12f2bd0347d 100644 --- a/drivers/gpu/drm/msm/msm_submitqueue.c +++ b/drivers/gpu/drm/msm/msm_submitqueue.c @@ -120,6 +120,27 @@ int msm_submitqueue_init(struct drm_device *drm, struct msm_file_private *ctx) return msm_submitqueue_create(drm, ctx, default_prio, 0, NULL); } +int msm_submitqueue_query(struct drm_device *drm, struct msm_file_private *ctx, + u32 id, u32 param, u64 data, u32 len) +{ + struct msm_gpu_submitqueue *queue = msm_submitqueue_get(ctx, id); + int ret = -EINVAL; + + if (!queue) + return -ENOENT; + + if (param == MSM_SUBMITQUEUE_PARAM_FAULTS) { + size_t size = min_t(size_t, len, sizeof(queue->faults)); + + if (copy_to_user(u64_to_user_ptr(data), &queue->faults, size)) + ret = -EFAULT; + } + + msm_submitqueue_put(queue); + + return ret; +} + int msm_submitqueue_remove(struct msm_file_private *ctx, u32 id) { struct msm_gpu_submitqueue *entry; diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h index c06d0a5bdd80..0f01ba60fcf7 100644 --- a/include/uapi/drm/msm_drm.h +++ b/include/uapi/drm/msm_drm.h @@ -273,6 +273,16 @@ struct drm_msm_submitqueue { __u32 id; /* out, identifier */ }; +#define MSM_SUBMITQUEUE_PARAM_FAULTS 0 + +struct drm_msm_submitqueue_query { + __u64 data; + __u32 id; + __u32 param; + __u32 len; + __u32 pad; +}; + #define DRM_MSM_GET_PARAM 0x00 /* placeholder: #define DRM_MSM_SET_PARAM 0x01 @@ -289,6 +299,7 @@ struct drm_msm_submitqueue { */ #define DRM_MSM_SUBMITQUEUE_NEW 0x0A #define DRM_MSM_SUBMITQUEUE_CLOSE 0x0B +#define DRM_MSM_SUBMITQUEUE_QUERY 0x0C #define DRM_IOCTL_MSM_GET_PARAM DRM_IOWR(DRM_COMMAND_BASE + DRM_MSM_GET_PARAM, struct drm_msm_param) #define DRM_IOCTL_MSM_GEM_NEW DRM_IOWR(DRM_COMMAND_BASE + DRM_MSM_GEM_NEW, struct drm_msm_gem_new) @@ -300,6 +311,7 @@ struct drm_msm_submitqueue { #define DRM_IOCTL_MSM_GEM_MADVISE DRM_IOWR(DRM_COMMAND_BASE + DRM_MSM_GEM_MADVISE, struct drm_msm_gem_madvise) #define DRM_IOCTL_MSM_SUBMITQUEUE_NEW DRM_IOWR(DRM_COMMAND_BASE + DRM_MSM_SUBMITQUEUE_NEW, struct drm_msm_submitqueue) #define DRM_IOCTL_MSM_SUBMITQUEUE_CLOSE DRM_IOW (DRM_COMMAND_BASE + DRM_MSM_SUBMITQUEUE_CLOSE, __u32) +#define DRM_IOCTL_MSM_SUBMITQUEUE_QUERY DRM_IOW (DRM_COMMAND_BASE + DRM_MSM_SUBMITQUEUE_QUERY, struct drm_msm_submitqueue_query) #if defined(__cplusplus) } -- 2.17.0

1 1

[PATCH] dma-buf: Remove unneeded stubs around sync_debug interfaces
by Ezequiel Garcia 07 May '18

07 May '18

The sync_debug.h header is internal, and only used by sw_sync.c. Therefore, SW_SYNC is always defined and there is no need for the stubs. Remove them and make the code simpler. Signed-off-by: Ezequiel Garcia <ezequiel(a)collabora.com> --- drivers/dma-buf/sync_debug.h | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h index d615a89f774c..05e33f937ad0 100644 --- a/drivers/dma-buf/sync_debug.h +++ b/drivers/dma-buf/sync_debug.h @@ -62,8 +62,6 @@ struct sync_pt { struct rb_node node; }; -#ifdef CONFIG_SW_SYNC - extern const struct file_operations sw_sync_debugfs_fops; void sync_timeline_debug_add(struct sync_timeline *obj); @@ -72,12 +70,4 @@ void sync_file_debug_add(struct sync_file *fence); void sync_file_debug_remove(struct sync_file *fence); void sync_dump(void); -#else -# define sync_timeline_debug_add(obj) -# define sync_timeline_debug_remove(obj) -# define sync_file_debug_add(fence) -# define sync_file_debug_remove(fence) -# define sync_dump() -#endif - #endif /* _LINUX_SYNC_H */ -- 2.16.3

2 1

[PATCH v13 00/10] Aspect ratio support in DRM layer
by Nautiyal, Ankit K 07 May '18

07 May '18

From: Ankit Nautiyal <ankit.k.nautiyal(a)intel.com> This patch series is a re-attempt to enable aspect ratio support in DRM layer. Currently the aspect ratio information gets lost in translation during a user->kernel mode or vice versa. The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had 4 patches, out of which 2 patches were reverted due to lack of drm client protection while loading the aspect information. This patch series also includes 5 patches from Ville Syrjälä's series for 'Info-frame cleanup and fixes': https://patchwork.freedesktop.org/series/33730/ which fixes the mode matching mechanism via flags, and also ensures that no bogus aspect-ratios are sent in the AVI infoframes. This patch series, adds a DRM client option for aspect ratio, and loads aspect ratio flags, only when the client sets this cap. To test this patch, the testdiplay IGT test is modified to have an option to do a modeset with only aspect ratio modes. Also, there is a userspace implementation in Wayland/weston layer: https://patchwork.freedesktop.org/patch/188125/ (Which is already ACK'ed by wayland community.) This, helps us in passing HDMI compliance test cases like 7-27, where the test equipment applies a CEA mode, and expects the exact VIC in the AVI infoframes. Ankit Nautiyal (3): drm: Add DRM client cap for aspect-ratio drm: Handle aspect ratio info in legacy modeset path drm: Expose modes with aspect ratio, only if requested Sharma, Shashank (2): drm: Add aspect ratio parsing in DRM layer drm: Add and handle new aspect ratios in DRM layer Ville Syrjälä (5): drm/modes: Introduce drm_mode_match() drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy drm/edid: Fix cea mode aspect ratio handling drm/edid: Don't send bogus aspect ratios in AVI infoframes video/hdmi: Reject illegal picture aspect ratios drivers/gpu/drm/drm_connector.c | 45 +++++-- drivers/gpu/drm/drm_crtc.c | 8 ++ drivers/gpu/drm/drm_crtc_internal.h | 6 + drivers/gpu/drm/drm_edid.c | 41 +++++-- drivers/gpu/drm/drm_fb_helper.c | 12 +- drivers/gpu/drm/drm_ioctl.c | 9 ++ drivers/gpu/drm/drm_modes.c | 226 +++++++++++++++++++++++++++++++----- drivers/video/hdmi.c | 3 + include/drm/drm_file.h | 8 ++ include/drm/drm_modes.h | 22 ++++ include/uapi/drm/drm.h | 7 ++ include/uapi/drm/drm_mode.h | 6 + 12 files changed, 343 insertions(+), 50 deletions(-) -- 2.7.4

3 18

[PATCH v2 0/8] R-Car DU: Support CRC calculation
by Laurent Pinchart 07 May '18

07 May '18

Hello, This patch series adds support for CRC calculation to the rcar-du-drm driver. CRC calculation is supported starting at the Renesas R-Car Gen3 SoCs, as earlier versions don't have the necessary hardware. On Gen3 SoCs, the CRC is computed by the DISCOM module part of the VSP-D and VSP-DL. The DISCOM is interfaced to the VSP through the UIF glue and appears as a VSP entity with a sink pad and a source pad. The series starts with a switch to SPDX license headers in patch 1/8, prompted by a checkpatch.pl warning for a later patch that complained about missing SPDX license headers. It then continues with cleanup and refactoring. Patches 2/8 and 3/8 prepare for DISCOM and UIF support by extending generic code to make it usable for the UIF. Patch 4/8 documents a structure that will receive new fields. Patch 5/8 then extends the API exposed by the VSP driver to the DU driver to support CRC computation configuration and reporting. The patch unfortunately needs to touch both the VSP and DU drivers, so the whole series will need to be merged through a single tree. Patch 5/8 adds support for the DISCOM and UIF in the VSP driver, patch 7/8 integrates it in the DRM pipeline, and patch 8/8 finally implements the CRC API in the DU driver to expose CRC computation to userspace. The hardware supports computing the CRC at any arbitrary point in the pipeline on a configurable window of the frame. This patch series supports CRC computation on input planes or pipeline output, but on the full frame only. Support for CRC window configuration can be added later if needed but will require extending the userspace API, as the DRM/KMS CRC API doesn't support this feature. Compared to v1, the CRC source names for plane inputs are now constructed from plane IDs instead of plane indices. This allows userspace to match CRC sources with planes. Note that exposing the DISCOM and UIF though the V4L2 API isn't supported as the module is only found in VSP-D and VSP-DL instances that are not exposed through V4L2. It is possible to expose those instances through V4L2 with a small modification to the driver for testing purpose. If the need arises to test DISCOM and UIF with such an out-of-tree patch, support for CRC reporting through a V4L2 control can be added later without affecting how CRC is exposed through the DRM/KMS API. The patches are based on top of the "[PATCH v2 00/15] R-Car VSP1: Dynamically assign blend units to display pipelines" patch series, itself based on top of the Linux media master branch and scheduled for merge in v4.18. The new base caused heavy conflicts, requiring this series to be merged through the V4L2 tree. Once the patches receive the necessary review I will ask Dave to ack the merge plan. For convenience the patches are available at git://linuxtv.org/pinchartl/media.git vsp1-discom-v2-20180423 The code has been tested through the kms-test-crc.py script part of the DU test suite available at git://git.ideasonboard.com/renesas/kms-tests.git discom Laurent Pinchart (8): v4l: vsp1: Use SPDX license headers v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper v4l: vsp1: Document the vsp1_du_atomic_config structure v4l: vsp1: Extend the DU API to support CRC computation v4l: vsp1: Add support for the DISCOM entity v4l: vsp1: Integrate DISCOM in display pipeline drm: rcar-du: Add support for CRC computation drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 156 ++++++++++++++++- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 19 +++ drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 13 +- drivers/media/platform/vsp1/Makefile | 2 +- drivers/media/platform/vsp1/vsp1.h | 10 +- drivers/media/platform/vsp1/vsp1_brx.c | 6 +- drivers/media/platform/vsp1/vsp1_brx.h | 6 +- drivers/media/platform/vsp1/vsp1_clu.c | 71 ++------ drivers/media/platform/vsp1/vsp1_clu.h | 6 +- drivers/media/platform/vsp1/vsp1_dl.c | 8 +- drivers/media/platform/vsp1/vsp1_dl.h | 6 +- drivers/media/platform/vsp1/vsp1_drm.c | 127 ++++++++++++-- drivers/media/platform/vsp1/vsp1_drm.h | 20 ++- drivers/media/platform/vsp1/vsp1_drv.c | 26 ++- drivers/media/platform/vsp1/vsp1_entity.c | 103 +++++++++++- drivers/media/platform/vsp1/vsp1_entity.h | 13 +- drivers/media/platform/vsp1/vsp1_hgo.c | 6 +- drivers/media/platform/vsp1/vsp1_hgo.h | 6 +- drivers/media/platform/vsp1/vsp1_hgt.c | 6 +- drivers/media/platform/vsp1/vsp1_hgt.h | 6 +- drivers/media/platform/vsp1/vsp1_histo.c | 65 +------ drivers/media/platform/vsp1/vsp1_histo.h | 6 +- drivers/media/platform/vsp1/vsp1_hsit.c | 6 +- drivers/media/platform/vsp1/vsp1_hsit.h | 6 +- drivers/media/platform/vsp1/vsp1_lif.c | 71 ++------ drivers/media/platform/vsp1/vsp1_lif.h | 6 +- drivers/media/platform/vsp1/vsp1_lut.c | 71 ++------ drivers/media/platform/vsp1/vsp1_lut.h | 6 +- drivers/media/platform/vsp1/vsp1_pipe.c | 6 +- drivers/media/platform/vsp1/vsp1_pipe.h | 6 +- drivers/media/platform/vsp1/vsp1_regs.h | 46 ++++- drivers/media/platform/vsp1/vsp1_rpf.c | 6 +- drivers/media/platform/vsp1/vsp1_rwpf.c | 6 +- drivers/media/platform/vsp1/vsp1_rwpf.h | 6 +- drivers/media/platform/vsp1/vsp1_sru.c | 6 +- drivers/media/platform/vsp1/vsp1_sru.h | 6 +- drivers/media/platform/vsp1/vsp1_uds.c | 6 +- drivers/media/platform/vsp1/vsp1_uds.h | 6 +- drivers/media/platform/vsp1/vsp1_uif.c | 271 ++++++++++++++++++++++++++++++ drivers/media/platform/vsp1/vsp1_uif.h | 32 ++++ drivers/media/platform/vsp1/vsp1_video.c | 6 +- drivers/media/platform/vsp1/vsp1_video.h | 6 +- drivers/media/platform/vsp1/vsp1_wpf.c | 6 +- include/media/vsp1.h | 39 ++++- 44 files changed, 896 insertions(+), 417 deletions(-) create mode 100644 drivers/media/platform/vsp1/vsp1_uif.c create mode 100644 drivers/media/platform/vsp1/vsp1_uif.h -- Regards, Laurent Pinchart

6 38

[PATCH v2 0/6] drm/panel: Handle the "panel is missing" case properly
by Boris Brezillon 07 May '18

07 May '18

Hello, This is a new attempt at fixing the "panel is missing" issue (described in this thread [1]). I lost track of Eric's proposal, but I recently proposed to address this problem through a new ->detect() hook in the panel_funcs interface [2], which was rejected. So here is a new version based on the feedback I had from Daniel, Thierry and Rob. The idea is to allow of_drm_find_panel() to return -ENODEV and let the DRM driver decide what to do with that (silently ignore the missing component and register the DRM device, or fail to register the DRM device). Patch 1 is just a fix for an OF node ref leak I found in the tegra driver while working on this patch series. It can be applied independently but I send it here since patch 2 depends on it. Patch 2 changes the semantic of of_drm_find_panel() so that it returns an ERR_PTR() instead of NULL when the panel is not found. This way we'll be able to differentiate the "panel is missing" from "panel has not been probed yet" errors. Patch 3 and 4 are adding new tests in of_drm_find_panel() and drm_of_find_panel_or_bridge() to return -ENODEV when the status property of the DT node is not set to "okay". Patch 5 is patching the VC4 DSI encoder driver to gracefully handle the -ENODEV case and allow the registration of the DRM device when the DSI device is disabled. And finally, patch 6 is modifying the rpi-touchscreen panel driver to update the status property of the DT node when the device is not reachable on the I2C bus. This way, the DSI encoder driver will get an -ENODEV and the DRM device will be registered even if the DSI panel is not connected. Note that the status prop update is currently done in the I2C driver instead of the I2C or device-model core because I think modifying the behavior for all I2C devices (or all devices) is too risky. Feel free to comment on this implementation Thanks, Boris Changes since v1: - Everything :-) [1]https://lists.freedesktop.org/archives/dri-devel/2017-November/157688.html [2]https://www.spinics.net/lists/dri-devel/msg174808.html Boris Brezillon (6): drm/tegra: Fix a device_node leak when the DRM panel is not found drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of NULL drm/panel: Let of_drm_find_panel() return -ENODEV when the panel is disabled drm/of: Make drm_of_find_panel_or_bridge() fail when the device is disabled drm/vc4: Support the case where the DSI device is disabled drm/panel: rpi-touchscreen: Set status to "fail" when ->probe() fails drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/lvds-encoder.c | 4 +-- drivers/gpu/drm/drm_of.c | 13 ++++++-- drivers/gpu/drm/drm_panel.c | 11 +++++-- drivers/gpu/drm/exynos/exynos_dp.c | 9 ++++-- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 9 ++++-- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++-- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 8 +++-- drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 4 +-- .../gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c | 10 +++++-- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- .../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 35 ++++++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_lvds.c | 9 ++++-- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/sti/sti_dvo.c | 7 +++-- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 +-- drivers/gpu/drm/tegra/dsi.c | 6 ++-- drivers/gpu/drm/tegra/output.c | 17 ++++++----- drivers/gpu/drm/vc4/vc4_dsi.c | 15 ++++++++-- include/drm/drm_panel.h | 2 +- 20 files changed, 131 insertions(+), 44 deletions(-) -- 2.14.1

4 30

[Bug 106355] Strange artifacts when using Chromium with hardware acceleration
by bugzilla-daemon＠freedesktop.org 07 May '18

07 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=106355 --- Comment #5 from Timothy Arceri <t_arceri(a)yahoo.com.au> --- (In reply to Norbert Klar from comment #4) > Care to tell me what's going on? 'Cause if it's duplicate of that bug, then > it wasn't fixed since then. No it's not fixed which is why the other bug is still open. It can take a while for these type of bugs are resolved. I'm not aware of anyone currently looking into the problem. -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2018