Created attachment 140465 [details] dmesg log When 2 external monitors are connected to an Apollolake system (with one of them being a 4k monitor), the second monitor is not supported (no display on second monitor). From dmesg logs, this behaviour is because the system memory bandwidth limitations are hit in the code path. [drm:skl_compute_wm] Requested display configuration exceeds system DDB limitations This is a regression issue post the backporting DRM Modifier patchset in chromeos-4.4 kernel. Patchsets in question are as below commit 10d5f23e8e3a29e6b4f9a7bd2de20f12dcee5df6 Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Nov 10 03:16:35 2017 commit ddaa724757cec3cf443fe6285d1679c6889e7694 Author: Ben Widawsky <ben@bwidawsk.net> Date: Tue Nov 07 01:25:37 2017 Before the above patches were merged, the planes are configured with x-tiling. With x-tiling, APL was able to drive two external monitors (with atleast one of them being 4k) at their native resolutions. Post merging of above patches, the planes are configured with y-tiling. With y-tiling, the display buffer allocation calculations fail for the second external monitor. Currently, during display buffer allocation, the total display buffer blocks available for the platform are divided equally across the active crtc's. When Y-tiling is enabled and two external displays are connected, crtc count increases to 3 and the total available display buffer blocks per crtc becomes 1/3. With a 4k monitor attached to the system, the required minimum blocks to be allocated exceeds the available per crtc blocks. Thus causing the issue. Verified the issue with drm-tip kernel and observed the same behavior. uname -a output: Linux localhost 4.18.0-rc3-13760-g655f2c563a64-dirty #2 SMP PREEMPT Wed Jul 4 18:31:36 IST 2018 x86_64 Intel(R) Celeron(R) CPU N3350 @ 1.10GHz GenuineIntel GNU/Linux Attached is the drm log. Steps to reproduce: (1)Connect 4K monitor to Port1 (2)Connect 19x12 monitor to port 2 Observed behaviour: 19X12 can't display
Ok, I'm tending to close this bug to INVALID, WORKSFORME or NOTOURBUG. This is an expected behavior. If there is no bandwidth available there is no magic we could do. However since you mention a regression with 2 supposed bad patches I will give the benefit of the doubt here... but you need to be more specific, because on our side: $ git show 10d5f23e8e3a29e6b4f9a7bd2de20f12dcee5df6 fatal: bad object 10d5f23e8e3a29e6b4f9a7bd2de20f12dcee5df6 $ git show ddaa724757cec3cf443fe6285d1679c6889e7694 fatal: bad object ddaa724757cec3cf443fe6285d1679c6889e7694 So, without further information there is not much we can do. (Btw, thanks for moving the discussion from that thread to the bugzilla ;))
As you sure we cannot reallocate ddb per pipe based on need? But the regression here is userspace going "hey we can use Y-tiling now, let's do that so we utilize render compression throughout the pipeline" with no regard to a fallback. That's indeed hard to classify as our regression though, _new_ userspace behaviour is broken and needs fixing.
@ Vivi rodrigo: Sorry, my mistake. I gave the commit id's in chromeos-4.4 kernel. Here are the commit id's from drm-tip. commit 714244e280de0e4ec00ff18b641f48be3936d920 Author: Ben Widawsky <ben@bwidawsk.net> Date: Tue Aug 1 09:58:16 2017 -0700 drm/i915: Add format modifiers for Intel commit db1689aa61bd1efb5ce9b896e7aa860a85b7f1b6 Author: Ben Widawsky <ben@bwidawsk.net> Date: Sun Jul 23 20:46:39 2017 -0700 drm: Create a format/modifier blob I have chosen my words badly. I should not have called out the behavior regression. The behavior has changed post merging of the above patches. After merging format modifiers patches, y-tiling instead of x-tiling is being used resulting in this behavior. @ Chris wilson I understand that the user space is where the decision to use y-tiling is made. That means we can drive at max 1 4k display on the APL platform with y-tiling enabled without hitting the ddb limits. If that is expected behavior, we can close the bug and I will document the behavior for any future issues on APL. I went through the platform specification for display buffer programming. There are 2 suggested ways of allocating the buffer. First one, the current implementation, where we fix the buffer allocation per pipe first and then allocate buffers per plane. A second implementation is also suggested, where the buffer allocation is done per plane first and remaining buffer to be divided across pipes. I do not have enough background info on why former approach has been taken.
We did following change and got positive result for this symptom. 1. Do not apply additional latency for watermark setup on BXT/APL platform. 2. Modify min_scanlines to 4 in skl_ddb_min_alloc(). diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 2cc12b48b74d..41357b80a603 100644 — a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2935,7 +2935,7 @@ static bool skl_needs_memory_bw_wa(struct intel_atomic_state *state) { struct drm_i915_private *dev_priv = to_i915(state->base.dev); - if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) || + if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) return true; @@ -3476,7 +3476,7 @@ skl_ddb_min_alloc(const struct drm_plane_state *pstate, const int plane) struct drm_framebuffer *fb = pstate->fb; struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate); uint32_t src_w, src_h; - uint32_t min_scanlines = 8; + uint32_t min_scanlines = 4; uint8_t plane_bpp;
Connecting a single 4k@60 monitor to APL causes FIFO underrun on drm-tip. Attaching the logs drm-tip-FIFO-underrun.txt
Created attachment 140861 [details] FIFO underrun on drm-tip
Hi, Is this underrun is observed after applying changes from comment #4?
Hi, I would also like to know how reproducible this issue is. If it's easy to reproduce can you please try with IPC disabled. to disable IPC, after booting the board modify following debug-fs entry (entry will be available only if debugfs is enabled) cat /sys/kernel/debug/dri/0/i915_ipc_status above will return if IPC is enabled or not, if enabled disable it by writing "0" or "Off" to same entry. echo 0 > /sys/kernel/debug/dri/0/i915_ipc_status
Only disabling IPC - underrun detected Only applying change in comment #4 - underrun detected Disabling IPC + comment #4 - underrun detected
Azhar, We can safely ignore the code in comment #4 henceforth as reducing the min scan lines is not recommended for APL platform.
Hi, patch Series to solve original issue "failed to detect second external monitor" is merged in the drm-tip. series link is: https://patchwork.freedesktop.org/series/47428/
Raviraj, can you verify that the issue is resolved for you on latest drm-tip. I can then close the bug.
No feedback, I assume the issue got fixed, patch is available in latest drm-tip. Closing this bug as Resolved/fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.