Created attachment 127090 [details]
xrandr --verbose

Created attachment 127092 [details]
dmesg when booting

Please try this http://patchwork.freedesktop.org/patch/msgid/1475776441-14102-1-git-send-email-rodrigo.vivi@intel.com

intel_dp_mst_compute_config() calculates tu size as 96:
[   73.890269] [drm:intel_dump_pipe_config [i915]] dp: 1, lanes: 2, gmch_m: 12425625, gmch_n: 8388608, link_m: 1035468, link_n: 1048576, tu: 96

But when we read it out we get 32 apparently:
[   79.467108] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dp_m_n (expected tu 96 gmch 12425625/8388608 link 1035468/1048576, or tu 0 gmch 0/0 link 0/0, found tu 32, gmch 12425625/8388608 link 1035468/1048576)

Bspec says
"Restriction : In DisplayPort MST mode the Virtual Channel payload size must not be programmed greater than 62 (resulting payload size of 63)."

which means our computed VC payload size would seem to be invalid. Someone should look into this.

I just applied the patch and compiled the kernel, it still failed and shows the same message ("mismatch in dp_m_n (expected tu 96 gmch 12425625/8388608 link 1035468/1048576, or tu 0 gmch 0/0 link 0/0, found tu 32, gmch 12425625/8388608 link 1035468/1048576)")

Apart from that mismatch, there are underruns when the encoder is being enabled. 

...
[   75.266521] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
[   75.266550] [drm:intel_fbc_underrun_work_fn [i915]] Disabling FBC due to FIFO underrun.
...


@Phidias Chiang 
There were watermark fixes that got merged after this bug was created. Can you retest with the latest -nightly?

As Ville pointed out, the TU size is definitely incorrect here.

Not just that, there is simply not enough bandwidth for that mode with the config that is being setup.

The stream bandwidth for 4k @60Hz, 24 bpp is 1599.75 MBps whereas with just 2 lanes and link clock at 540MHz, we can support only 1080 MBps. This configuration should have been rejected.

Can you give this a try - https://patchwork.freedesktop.org/series/15084/ ?

(In reply to Dhinakaran Pandiyan from comment #7)
> As Ville pointed out, the TU size is definitely incorrect here.
> 
> Not just that, there is simply not enough bandwidth for that mode with the
> config that is being setup.
> 
> The stream bandwidth for 4k @60Hz, 24 bpp is 1599.75 MBps whereas with just
> 2 lanes and link clock at 540MHz, we can support only 1080 MBps. This
> configuration should have been rejected.

mode should have been rejected*

Created attachment 127913 [details] [review]
testpatch to pass the dock based on intel_dp_mode_valid function

The test patch is workable based on the feedback of Canonical.com as the below:
    We applied the said patch to 4.9.x kernel and tried it with the Dell IE dock.
    With it, the Dell 4K monitor was correctly.

But, the test patch is based on DP function(intel_dp_mode_valid),so we need to wait for official DP-MST function(intel_dp_mst_mode_valid) to be delivered.

Thanks.

echo comment#10
  Some modes from sink edid should be filtered based on DPCD - Sink capability.
  In this case, 4k@60HZ is over the sink capability.

I have resubmitted the series here - https://patchwork.freedesktop.org/series/15305/ .

Hi Dell team:
   Backend team has submitted the patch(@comment 12) which is similar with my test patch.
   It should be workable and it is under review.
   Please kindly help to have test and wait for the patch to review and merge.

Thanks.

Update test result from Canonical team for this patch(https://patchwork.freedesktop.org/series/15305/):

After applied this patch set on top of current drm-intel-nightly (2016-11-14) and it works, xrandr shows correct refresh rate and the monitor using mDP works fine.

Reference to latest Dhinakaran's patchset (including the one fixing issue): https://patchwork.freedesktop.org/series/15528/

Marking as resolved+fixe based on comment 14.

(In reply to Jari Tahvanainen from comment #16)
> Marking as resolved+fixe based on comment 14.

Jari, we only resolve bugs when the patches have been pushed to our repo.

(In reply to yann from comment #15)
> Reference to latest Dhinakaran's patchset (including the one fixing issue):
> https://patchwork.freedesktop.org/series/15528/

^Not the right series.

The correct one is - https://patchwork.freedesktop.org/series/15305/ and this is the one tested in comment 14.

(In reply to Jani Nikula from comment #17)
> (In reply to Jari Tahvanainen from comment #16)
> > Marking as resolved+fixe based on comment 14.
> 
> Jari, we only resolve bugs when the patches have been pushed to our repo.


The patches (https://patchwork.freedesktop.org/series/15305/) that fix this issue are in drm-tip/drm-tip

22a2c8e drm/i915: Validate mode against max. link data rate for DP MST
fd81c44 drm/i915: Fix DP link rate math

(In reply to Dhinakaran Pandiyan from comment #19)
> (In reply to Jani Nikula from comment #17)
> > (In reply to Jari Tahvanainen from comment #16)
> > > Marking as resolved+fixe based on comment 14.
> > 
> > Jari, we only resolve bugs when the patches have been pushed to our repo.
> 
> 
> The patches (https://patchwork.freedesktop.org/series/15305/) that fix this
> issue are in drm-tip/drm-tip
> 
> 22a2c8e drm/i915: Validate mode against max. link data rate for DP MST
> fd81c44 drm/i915: Fix DP link rate math

Thanks. It would be good policy in general to reference the commits when closing the bugs, if the commit ids are known.

Created attachment 128450 [details]
attachment-22249-0.html

Hi Sender,

Many thanks for your mail, I'm OOO from WW51.2 to WW52.2
Please contact my deputy during my absence.
YunOS GFx: Rich.Chen
YunOS HDMI: Shawn C, Lee
Chrome/Ubuntu GFx: Gary C.Wang
All others: Ivan Y.Chou

If any urgent please call my cell +886 953-018-982
Sorry for the inconvenience.
Cooper