Bug 107113

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.