Bug 68451

Created attachment 121461 [details]
3.11 with video=VGA-1:1366x768

Created attachment 121471 [details]
Xorg.conf needed to make 3.11 X work

Created attachment 121481 [details]
Trace with drm.debug=0x6

I'm a bit confused: You need to force the VGA output to see something on the panel?

And we don't seem to detect any eDP panel according to the debug dmesg. And there also doesn't seem to be any mipi block in the vbt.

Yes.. although it is of course possible that the efi frame buffer before hand means that the VGA= is simply getting the right clocks generated so it happens to work.

No changes btw if I try drm-intel-fixes

I see nothing in windows that will tell me the panel type either

xrandr on 3.11 shows it as on vga, and turning off vga turns it off, while turning on vga turns it back on. Changing the mode messes up the display, restoring the mode gets the display back

(ports shown are VGA1, HDMI1 (not connected), DP1 (not connected), VIRTUAL1 (not connected)

If I try and add the mode to the DP port then enable it I get a crtc configure failed and a backtrace from intel_dp_max_link_bw (3.11 or drm-intel-fixes)

Interestingly while video=VGA-1:blah fails with 13-rc7(drm-intel-fixes) the following does produce output on the panel. Is the bug in fact breakage of video= handling, and the rest is just usually concealed ?

xrandr --newmode 1368x768 {blah}
xrandr --addmode VGA1 1368x768
xrandr --output VGA1 1368x768

Random thought, make sure you have CONFIG_DRM_I915_FBDEV enabled.

See https://bugs.freedesktop.org/show_bug.cgi?id=73154

I do

Hm, that's indeed funny. Both the panel connected to the vga port (never seen that) and that xrandr works better than the video= cmdline option.

Any differences between the manual xrandr frobbing and video= in
- xrandr verbose?
- the output modes dumped in intel_dump_pipe_config before doing a modeset?
- intel_reg_dumper output?

Stray bullet shooting I know, but atm no ideas really ...

The reg dumper simply reports

"Gen 2/3 Ranges are not supported. Please use unasafe access.Aborted (core dumped)

The one from git requires updating everything libdrm and other stuff which is going to mess up and invalidate all the other testing/work on it.

is there a static linked current intel_reg_dumper kept anywhere ?

Upgrading libdrm won't really hurt, we pretty much don't touch that code besides adding new kernel interface definitions. So very very unlikely to cause regressions of its own.

Latest i-g-t is 1.5, that one should have the gen2/3 bug fixed ...

Went back to the October version which worked with a tiny bit of hackery.

I'm attaching the 3.11 data. I need to do some set up and the 3.13-rc7-dri-fixes data will follow later today

Hopefully this at least makes it possible to figure out how it is all plumbed.

Created attachment 122041 [details]
3.11 with video=VGA-1:1366x768 in text mode

Created attachment 122051 [details]
3.11 with video=VGA-1:1366x768 (and Xconfig to force same) in X11

Created attachment 122061 [details]
3.13-rc7+ as it comes up (X starts but no display)

Created attachment 122071 [details]
3.13-rc7+ after adding the mode with xrandr and turning the output on

The differences are small between the 3.13 ones

-                     DPLL_A_MD: 0x04c75adf
+                     DPLL_A_MD: 0x0c875a9f


-                        DPLL_B: 0x04c75adf (disabled, non-dvo, VGA, TV B/C cloc
k, DAC/serial mode, p1 = 1, p2 = 10)
+                        DPLL_B: 0x0c875a9f (disabled, non-dvo, VGA, TV B/C cloc
k, unknown mode, p1 = 1, p2 = 0)

 pipe B dot 0 n 0 m1 0 m2 0 p1 1 p2 10
-                 FENCE START 0: 0x00c5b003
-                   FENCE END 0: 0x0105a01f
-                 FENCE START 1: 0x010e9001
-                   FENCE END 1: 0x013e801f
-                 FENCE START 2: 0x00393001
-                   FENCE END 2: 0x0069201f
+                 FENCE START 0: 0x006e1001
+                   FENCE END 0: 0x00b0002b
+                 FENCE START 1: 0x00000000
+                   FENCE END 1: 0x00000000
+                 FENCE START 2: 0x00000000
+                   FENCE END 2: 0x00000000


Comparing 3.11 with vga= with 3.13 in workig form is similar differences (DPLL and fences) but also

-                    GEN6_PMIMR: 0x00000000
-                GEN6_PMINTRMSK: 0x00000000
+                    GEN6_PMIMR: 0xffffff8f
+                GEN6_PMINTRMSK: 0x0000000a

Still no original ideas, but someone at [1] suggests reverting

commit 6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Sep 10 14:54:42 2013 -0700

    drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT

as a workaround, and indeed there too they used video= pre-3.13.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=71977#c17

I can confirm the workaround gets video= back, looks like video= is overridden by the hotplug detection ?

I believe intel_reg_dumper gives you just garbage on VLV. Try quick_dump instead.

Created attachment 123651 [details]
quickdump attachment 3 [details].13, with regression reverted

To be honest these look nonsense and the other reg dumper looks sensible 8)

(In reply to Alan from comment #20)
> Created attachment 123651 [details]
> quickdump attachment 3 [details].13, with regression reverted
> 
> To be honest these look nonsense and the other reg dumper looks sensible 8)

Oh, I think you need to use the "-a" option to make it autodetect the platform. For some reason it doesn't do that by default.

Created attachment 123661 [details]
With -a

0x001f0008 | PIPEACONF                    | 0xe0000000
0x001e1190 | MIPIA_PORT_CTRL              | 0x80010000
0x0018b020 | MIPIA_DPI_RESOLUTION         | 0x03000558

So yeah looks like it comes up w/ DSI is enabled at 1368x768 resolution.

Forcing the VGA output on, just happens to enable the pipe w/ the correct resolution and things just work.

I don't really know how the pixel clock ends up working since we've now enabled both the DPLLA and DSI PLL on the same pipe. I would expect those two to conflict somehow, but I guess not.

c/o danvet

Correct workaround for now is: video=VGA-1:1366x768e

(note the e: that avoids the need to revert the 3.13 change)

(In reply to Alan from comment #24)
> c/o danvet
> 
> Correct workaround for now is: video=VGA-1:1366x768e
> 
> (note the e: that avoids the need to revert the 3.13 change)

That's a relief.

Please attach /sys/kernel/debug/dri/0/i915_opregion so we can have a look at the VBT. The dmesg says

[   34.955292] [drm:parse_mipi], No MIPI BDB found

(missing MIPI bios block) so we need to confirm whether that's correct.

The DSI displays are essentially non-discoverable, and that block is supposed to be there. I hear rumours this might not always be the case. Without it, we would have to work with just what the BIOS has set up in the relevant registers.

This is a legacy free system so has no "BIOS" just EFI. I don't know if that's relevant to opregion stuff. When I poked around in it before the mode and related bits were present but I didn't investigate in depth.

Created attachment 125711 [details]
opregion

OpRegion as requested

(In reply to Alan from comment #27)
> Created attachment 125711 [details]
> opregion
> 
> OpRegion as requested

Thanks, that confirms there's VBT block 52 which, we've just learned, supersedes block 50 which we currently check for (and fail to find, "[drm:parse_mipi], No MIPI BDB found").

This is somewhat good news, as that gives us something to work with.

The opregion from the Venue 8 Pro is attached to https://bugs.freedesktop.org/show_bug.cgi?id=74657 , in case that's of use.

Ping? Is anyone getting anywhere on these mode detection issues? I see lots of work on other Baytrail areas, but this one seems kinda stuck. We have a functional workaround, but it's kind of finicky for my Fedlet builds.

BTW, I note some discussion going on in https://bugzilla.kernel.org/show_bug.cgi?id=68291 about the graphics controller requesting an interrupt it doesn't really need.

(In reply to Adam Williamson from comment #30)
> Ping? Is anyone getting anywhere on these mode detection issues? I see lots
> of work on other Baytrail areas, but this one seems kinda stuck. We have a
> functional workaround, but it's kind of finicky for my Fedlet builds.

"mode detection issue" is an understatement.

The machines in question have a MIPI DSI [1] display instead of the more common eDP or LVDS or somesuch. Work is in progress to have the drivers for that upstream, but unfortunately I don't expect them to be merged before v3.16. And being new features rather than fixes, they will not be backported to stable kernels.

I hope that answers your question, although I'm sure this is not what you wanted to hear.

[1] http://en.wikipedia.org/wiki/Display_Serial_Interface

""mode detection issue" is an understatement."

Sure, just call it shorthand. I figured we both knew what we were talking about :)

"I hope that answers your question, although I'm sure this is not what you wanted to hear."

Nope, that's fine, just wanted to check it was actually being worked on. Though if timeframe is 3.16 I may have to do the slightly more complex patch to anaconda I was hoping not to have to need, to make fedlet installs work better on non 800x1280 systems. eh.

FWIW the patches should be fairly isolated and easily backportable.

Ok, the regression is addressed and the larger issue of our dsi support on byt being totally broken isn't really new ...

Closing this since bugzilla isn't suitable really for feature requests.

Ok where would you like the "feature request" re-opened. From my perspective this isn't a random 'feature request' it's a major support gap.  Should I take that via freedesktop or escalate it within Intel ?

(In reply to Alan from comment #35)
> Ok where would you like the "feature request" re-opened. From my perspective
> this isn't a random 'feature request' it's a major support gap.  Should I
> take that via freedesktop or escalate it within Intel ?

IIUC there's now a comparable workaround to what worked before, so adjusting the bug to reflect reality. Not a regression, but an enhancement. This is orthogonal to the question where this should be tracked.

Escalate within Intel, definitely. I can tell you the story on internal irc.

I'm seeing what I believe may be a related problem with the panel display on my ASUS T100A, running 3.15-rc1.  The system, which was working reasonably well with 3.14, and also the partly merged 3.15 code, seemed to break with the merge of the latest i915 code into the kernel on about April 8.  

The basic problem is that the panel display and an external HDMI display come up properly on boot, but if I do anything to turn off the panel display, such as "xrandr --output VGA1 --off", then nothing I do after that is able to make the panel display visible till I reboot.

After an "xrandr --output VGA1 --auto" the system seems to THINK the panel is active, as indicated by xrandr output and also the implied limits of the display when moving windows and the mouse from one display to the other, but there just isn't any visible panel output.  The HDMI is fine.  I don't see any error messages in any of the logs I've been able to check.  The system really acts like some part of the video output chain is being disabled, and never gets reenabled except by a reboot.  With versions of the kernel I comiled before the April 8 driver merge, I am able to turn off then turn on the panel.  

For your information, I am using a video=VGA-1:1368x768e parameter at boot, and also specify an edid file I created.

This is my first attempt to report a bug on bugzilla.kernel.org, and I'm also relatively new to compiling the kernel, so if I should post this in a different manner, just let me know.

It's not the same as this bug, and this one is long enough already, so best report it separately. This bug is about the reason you need to pass "video=VGA-1:1368x768e" at all - when this bug is fixed, you won't need to do that.

(In reply to Adam Williamson from comment #39)
> It's not the same as this bug, and this one is long enough already, so best
> report it separately. This bug is about the reason you need to pass
> "video=VGA-1:1368x768e" at all - when this bug is fixed, you won't need to
> do that.

Thanks for the advice.  I've posted this as a new bug:  74381.

And thanks also for all of the work you've done in helping to bring up Linux on the Baytrail tablets.

Actually its almost certainly just a side effect of the same bug, which is the fact the panel isn't properly supported. The xrandr is undoing the hack property of it working.

Alan: if that was the case, I don't think it would've broken "with the merge of the latest i915 code into the kernel on about April 8." but been working with 3.14, no?

Given the way the "video=" stuff happens to make it work - no.

The final DSI patches have been posted this week [1], not reviewed yet due to travel, but you're welcome to give them a go. Should apply on top of drm-intel-nightly of [2].

[1] http://mid.gmane.org/1397454507-10273-1-git-send-email-shobhit.kumar@intel.com

[2] http://cgit.freedesktop.org/drm-intel/

(In reply to Jani Nikula from comment #44)
> The final DSI patches have been posted this week [1], not reviewed yet due
> to travel, but you're welcome to give them a go. Should apply on top of
> drm-intel-nightly of [2].
> 
> [1]
> http://mid.gmane.org/1397454507-10273-1-git-send-email-shobhit.kumar@intel.
> com
> 
> [2] http://cgit.freedesktop.org/drm-intel/

Thanks very much for providing the patches.  I have compiled and tested a new x86_64 kernel using them, combined with the most recent 3.15 code.  That is working reasonably well on an ASUS T100TA and also a Toshiba Encore 8.  With these driver patches I can turn off and on the video on the tablet panels, and the HDMI output works fine too.  

With the new patches xrandr reports the panel as device "UNKNOWN1" rather than the former VGA1, which it now lists as unconnected.  So scripts which rely on VGA1 need to be modified slightly.  With the the patches I no longer need the kernel boot options "video=VGA-1..." and "drm_kms_helper.edid_firmware=..." and I also no longer need to specify the resolution in the /etc/X11/xorg.conf.d/50-monitor.conf file.  Although I haven't tried a system install from scratch, that should required far less hand configuration than before.

There are a few minor problems on the x86_64 systems.  For example dmesg shows a moderate number of i915 warnings about "vblank_wait_timed_out", "pipe_off wait timed out",  "pipe state doesn't match!", and a few others.  Earlier in the boot process I also see a few errors like "drm:dpi_send_cmd] *ERROR* Timeout waiting for DPI FIFO empty."  However at least on the x86_64 systems they don't seem to cause problems.

I also tried installing a 32 bit (i386) kernel with the new patches on a T100TA system and the results were quite different.  While the patches seem to restore the functionality mentioned above, the system very quickly bogs down to an unusably slow state and eventually freezes.  I think it is getting overwhelmed by a larger number of warnings like those mentioned above.  Whatever is doing it is clearly i915 related, as booting the system with nomodeset eliminates the problem.

So in summary, despite a few glitches, on x86_64 kernels, for both T100TA's and Toshiba Encore 8's, the patches work well and vastly simplify the special configuration which otherwise needs to be done.

I'm building a fedlet kernel with the patches now, will test and confirm on Venue 8 Pro. Robert, did you happen to check if suspending manages to turn off the display backlight now?

Currently the system with my latest kernel doesn't seem to support suspend, so I can't do this particular test.  As a poor substitute I tried using the "switch off screen" timer in my power settings, and while that turns off video, the backlight is clearly still on.  

On a slightly related issue, I've never been able to get the main power-off to work using the 64 bit kernels.  On my 32 bit version I had it working with some posted patches, but I haven't yet tried applying those patches to the new 3.15 based code.

Hi folks,

Really happy to see this -- have been holding off on the purchase of the BYT Venue 11 Pro until now, but pleased to see things getting fixed!

At the risk of complicating things further, a few questions:

- What's the likelihood that these changes will carry through to a hypothetical Cherry Trail refresh of these platforms? The BYT configurations only have 2GB of memory which is a little light for my tastes.

- Is there any chance at all that these fixes are being applied in a way which causes some previously unsupported BYT bus to be probed? I ask because of some discussion on http://ubuntuforums.org/showthread.php?t=2187204&page=3&p=12929454#post12929454 that indicates that the wifi, bluetooth, and optional keyboard touchpad aren't coming up at all. There's also https://bugzilla.kernel.org/show_bug.cgi?id=73081. I can understand that this may just be a matter of these modules (all relatively new, even in the case of the touchpad) not having made it into the kernel yet, but I thought I'd ask here.

axfelix: I don't think I'm giving away any trade secrets if I say that if you just follow the work currently landing in drm-intel, you'll see a whole pile of stuff related to the next-gen baytrail platforms...https://patchwork.kernel.org/project/intel-gfx/list/ , http://cgit.freedesktop.org/drm-intel/ ...

for other hardware support stuff it's best to ask in some other channel so as not to gum up bugzilla, it's best to keep bug reports strictly focused on the bug at hand. if you poke me via email or IRC I can give you some general pointers on the state of hardware support with various baytrail platforms and OSes (running a stock Ubuntu install is not really going to cut it.)

Upgrading to regression since it's a feature deficit compared to using the vbios.

*** Bug 74381 has been marked as a duplicate of this bug. ***

Please try Linus' master; this should be fixed with

commit 682b7c1c8ea8885aa681ddf530d6cf2ad4f2dc15
Merge: 16b9057804c0 bc1dfff04a5d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jun 12 11:32:30 2014 -0700

    Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

yup, I'm on it like flies on sherbet - was going to do it yesterday, but the DRM merge only hits Rawhide kernels today.

well, first try on the v8p doesn't look too promising - display goes blank right about where modesetting should kick in. I'm in a hurry right now, will look into it more later.

Still not working for me with a 3.16rc2 kernel with a few other Baytrail patches (not video-related). If I build a live image with such a kernel and try to boot it, the screen goes blank right after very early kernel boot messages. After some time (couple of minutes), it lights up again showing a few lines of intel errors:

[drm:dpi_send_cmd] *ERROR* Timeout waiting for DPI FIFO empty.
[drm:intel_dsi_clear_device_ready] *ERROR* DSI LP not going Low
[drm:intel_pipe_config_compare] *ERROR* mismatch in adjust_mode.flags(DRM_MODE_FLAG_MHSYNC] (expected 2, found 0)

those are retyped from a photo of the screen, forgive any typos.

The other patches I'm applying are https://patchwork.kernel.org/patch/3787341/ , https://lkml.org/lkml/2014/5/20/284 (only patch 4/5), and http://www.spinics.net/lists/linux-i2c/msg15201.html .

(In reply to Adam Williamson from comment #56)
> Still not working for me with a 3.16rc2 kernel with a few other Baytrail
> patches (not video-related). If I build a live image with such a kernel and
> try to boot it, the screen goes blank right after very early kernel boot
> messages. After some time (couple of minutes), it lights up again showing a
> few lines of intel errors:

Please attach the full dmesg with drm.debug=0xe.

Created attachment 140901 [details]
dmesg from 3.16 rc2 on venue 8 pro with drm.debug=0xe, display dies at modesetting initialization

(In reply to Adam Williamson from comment #58)
> Created attachment 140901 [details]
> dmesg from 3.16 rc2 on venue 8 pro with drm.debug=0xe, display dies at
> modesetting initialization

Note that the DPIO WARNs are fixed by http://www.spinics.net/lists/intel-gfx/msg48001.html , but that fix shouldn't make a difference for DSI.

note this shouldn't be NEEDINFO any more, I provided the info.

Jan Brummer says my current "Fedlet" kernel works on his v8p, which is rather odd. It definitely still doesn't work on mine. The difference could possibly be in the firmware - he updated his to the latest firmware, I have not updated mine as you can only do the firmware update through Windows :(

I've just tested 3.16 rc4 (64 bits) on both an ASUS T100TA and a Toshiba Encore 8 and the video appears to be working fine on both.  Neither requies the special EDID files or VGA1 module parameters which the previous versions of the i915 driver required.  And the panel video CAN now be turned back on with XRANDR after a previoius XRANDR has turned it off.

The only (minor) problems I've seen so far are that I can't yet control brightness, and the backlight does NOT appear to turn off when, for example the system goes into a "screen off" powersaving state after a period of inactivity.  Also, I've seen some i915 warnings/errors in the kernel log, although they don't appear to impact actual use.  Here is a short excerpt of the log.  Let me know if you need more.

[ 2391.512483] WARNING: CPU: 1 PID: 825 at drivers/gpu/drm/i915/intel_sideband.c:200 vlv_dpio_read+0x6c/0x80 [i915]()
[ 2391.512487] DPIO read pipe A reg 0x800c == 0xffffffff
...
[ 2394.047183] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags(DRM_MODE_FLAG_NHSYNC) (expected 2, found 0)
[ 2394.047189] ------------[ cut here ]------------
[ 2394.047245] WARNING: CPU: 0 PID: 825 at drivers/gpu/drm/i915/intel_display.c:10173 check_crtc_state+0x235/0x350 [i915]()
[ 2394.047248] pipe state doesn't match!

Thanks again for everyones' contributions in getting a usable Linux on the T100TA's.  During part of the long gap since I last posted here I was far off the grid, doing geology field work.  I needed a working Linux system for some of that, and the T100TA gave me one I could easily backpack in, and keep charged with backup batteries and solar panels.

well, that's pretty strange. I'll try and do a fedlet build of the latest Rawhide kernel soon and see if mine's starting working yet. if not I'll ship some new fedlet images anyway, since it seems to be working for everyone *else*...

Works for me too

Brightness control/backlight is via the PMIC which isn't as yet all merged and supported

Still doesn't work for me; screen goes blank with backlight on when modesetting kicks in, with an rc5 kernel build. Bizarre how it works for everyone else. I guess I'll file a new bug for my case since it doesn't seem to affect anyone else.

I've discovered what might be a useful clue regarding the cause of the blank screen after these tablets switch from the EFI to the the i915 console.  The problem MAY be related to "vblank wait timed out" errors.  

First, on my ASUS T100TA the tablet display always seems to come up properly, on recent kernels up to and including 3.16-rc7, as long as I do NOT have the tablet hooked up to an external HDMI monitor.  (More on HDMI later.)  I've booted with the drm.debug=0x06 parameter and, in contrast to what I describe below, the T100TA dmesg output NEVER shows "vblank wait timed out errors".

I also have a Toshiba Encore 8 and as I posted above, I originally thought its display was working OK.  However that was from just one or two (successful) boots.  Since then on almost all attempts I seem to be having the same problem that Adam describes for his Dell tablet.  The screen goes blank at the point it tries to switch from the EFI to the i915 console.  In all of those failed attempts, when I later examine the dmesg output, I see there have been "vblank wait timed out" errors while it was in the middle of some drm mode set operation.  I include a stack trace at the end.  On one occasion where it DID successfully bring up the screen and I recorded dmesg (and also used drm.debug), it did NOT show the "vblank wait timed out" error.  I've been trying MANY times to capture another successful boot to confirm these all have NO vblank timeout errors, but of course now the machine has decided to always come up with the blank screen.  Why it very occasionally initializes successfully (and did so on the first boot or two back on July 12) is something I just haven't figured out.

The one way I can make the Encore bring up the tablet screen relatively often is to rapidly press ESCAPE during the boot process.  I've long since removed the "splash=silent quiet" parameters so this isn't trying to switch back to console from a graphical screen, but quite often the escape DOES makes the screen "flash", and then the i915 console does become visible and eventually it successfully brings up the full X11 graphics.  During these boots sometimes I see the vblank wait time out error and sometimes I don't.  

The other way I've been able to investigate dmesg output even when the tablet screen is blank is that I can (with luck) log in by typing blindly.  Then using xrandr to disable then enable the tablet display does usually make it visible.  So something in the driver code called by that DOES successfully initialize the display.  Finally, the Encore (and the T100TA) have micro-hdmi ports which DO work, which gives me another way in to the system.

So to summarize, 1) the stand-alone T100 always initializes the tablet display properly and never shows the vblank timeout error, 2) the Encore almost always comes up with a blank screen and on all those failures DOES show the vblank error, and 3) on a rare occasion where the Encore did bring up an active screen, it did NOT show the vblank timeout error.

To add one final point of confusion, although I think this really is a separate problem, I've discovered that when I do have an external HDMI display connected to the T100, sometimes the tablet display comes up blank even during the very first steps where it is displaying the grub menu via the EFI driver.  Perhaps this is by design, as the HDMI screen is active, although often both screens are active.  In any case, when I do boot the machine from this tablet-display-disabled state, later xrandr calls are UNABLE to turn on the tablet display.  The only way to ensure this does not happen is to start the T100 with the HDMI disconnected, in which case the tablet display always works.  Then I can plug in the HDMI either at the grub menu prompt or later.   Although this appears to be a different "bug" since it happens even before the i915 driver loads, the fact that the i915 cannot turn on the T100 display through later xrandr commands (although xrandr reports it HAS turned on) suggests some critical display initialization step is still missing in that driver.  I know that is the opposite of what I just said regarding xrandr for the Encore, but that is what repeated tests show.

Sorry this is such a long message -- but that reflects how confusing the symptoms seem to be.

Let me know if you need more information.

Bob Howell

---------------------------
dmesg "vblank time out" text from a "bad" Encore boot:

[   14.131000] [drm:drm_mode_getconnector] [CONNECTOR:13:?]
[   14.131014] [drm:drm_mode_getconnector] [CONNECTOR:13:?]
[   14.131152] [drm:drm_mode_getconnector] [CONNECTOR:17:?]
[   14.131161] [drm:drm_mode_getconnector] [CONNECTOR:17:?]
[   14.131200] [drm:drm_mode_getconnector] [CONNECTOR:19:?]
[   14.131210] [drm:drm_mode_getconnector] [CONNECTOR:19:?]
[   14.370598] [drm:drm_mode_addfb] [FB:51]
[   14.370615] [drm:drm_mode_setcrtc] [CRTC:5]
[   14.370625] [drm:drm_mode_setcrtc] [CONNECTOR:19:DSI-1]
[   14.370630] [drm:intel_crtc_set_config] [CRTC:5] [FB:51] #connectors=1 (x y) (0 0)
[   14.370637] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:5], mode_changed=0, fb_changed=1
[   14.370641] [drm:intel_modeset_stage_output_state] [CONNECTOR:13:HDMI-A-1] to [CRTC:9]
[   14.370645] [drm:intel_modeset_stage_output_state] [CONNECTOR:19:DSI-1] to [CRTC:5]
[   14.370653] [drm:valleyview_set_rps] GPU freq request from 178 MHz (191) to 666 MHz (213)
[   14.373548] [drm:i9xx_update_primary_plane] Writing base 00DB5000 00000000 0 0 7680
[   14.425518] ------------[ cut here ]------------
[   14.425575] WARNING: CPU: 1 PID: 644 at drivers/gpu/drm/i915/intel_display.c:861 intel_wait_for_vblank+0x1f9/0x200 [i915]()
[   14.425579] vblank wait timed out
[   14.425581] Modules linked in: joydev fuse battery acpi_pad ac intel_powerclamp hid_multitouch hid_sensor_hub coretemp kvm_intel kvm gpio_keys snd_soc_sst_baytrail_pcm snd_soc_sst_dsp snd_soc_sst_byt_rt5640_mach 8250_dw snd_soc_rt5640 snd_soc_core snd_compress snd_soc_rl6231 crc32_pclmul regmap_i2c crc32c_intel snd_pcm snd_timer aesni_intel ablk_helper cryptd lrw gf128mul glue_helper pcspkr aes_x86_64 toshiba_acpi snd sparse_keymap wmi soundcore soc_button_array int3403_thermal i2c_hid snd_soc_sst_acpi i2c_designware_platform i2c_designware_core lpc_ich mfd_core iosf_mbi pwm_lpss brcmfmac brcmutil cfg80211 rfkill sg dm_mod efivarfs hid_logitech_dj i915 drm_kms_helper drm i2c_algo_bit xhci_hcd button thermal video processor scsi_dh_alua scsi_dh_emc scsi_dh_rdac scsi_dh_hp_sw scsi_dh mmc_block sdhci_acpi
[   14.425647]  sdhci mmc_core
[   14.425654] CPU: 1 PID: 644 Comm: Xorg Tainted: G        W     3.16.0-rc7-rrh-01 #1
[   14.425657] Hardware name: TOSHIBA Encore/Encore, BIOS 1.60 03/06/2014
[   14.425660]  0000000000000009 ffff8800716f3b90 ffffffff815fa786 ffff8800716f3bd8
[   14.425666]  ffff8800716f3bc8 ffffffff810508a8 ffff880033dc0000 00000000001f0040
[   14.425670]  0000000000000a1f 00000000fffba2d9 ffff8800358f5000 ffff8800716f3c28
[   14.425676] Call Trace:
[   14.425687]  [<ffffffff815fa786>] dump_stack+0x4d/0x6f
[   14.425694]  [<ffffffff810508a8>] warn_slowpath_common+0x78/0xa0
[   14.425699]  [<ffffffff81050917>] warn_slowpath_fmt+0x47/0x50
[   14.425730]  [<ffffffffa018d239>] intel_wait_for_vblank+0x1f9/0x200 [i915]
[   14.425758]  [<ffffffffa018f0f4>] intel_pipe_set_base+0x144/0x330 [i915]
[   14.425788]  [<ffffffffa01994de>] intel_crtc_set_config+0x95e/0xda0 [i915]
[   14.425811]  [<ffffffffa00ddff1>] drm_mode_set_config_internal+0x61/0xe0 [drm]
[   14.425831]  [<ffffffffa00e191f>] drm_mode_setcrtc+0xcf/0x580 [drm]
[   14.425847]  [<ffffffffa00d28fc>] drm_ioctl+0x1ec/0x660 [drm]
[   14.425856]  [<ffffffff811a14a0>] do_vfs_ioctl+0x2e0/0x4c0
[   14.425862]  [<ffffffff811aaff9>] ? __fget+0x69/0xb0
[   14.425867]  [<ffffffff811a1701>] SyS_ioctl+0x81/0xa0
[   14.425874]  [<ffffffff816013a9>] system_call_fastpath+0x16/0x1b
[   14.425877] ---[ end trace 0f148e052eb831a3 ]---
[   14.426077] [drm:drm_mode_setcrtc] [CRTC:9]
[   14.426088] [drm:drm_mode_setcrtc] [CONNECTOR:13:HDMI-A-1]
[   14.426093] [drm:intel_crtc_set_config] [CRTC:9] [FB:51] #connectors=1 (x y) (0 0)
[   14.426098] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:9], mode_changed=0, fb_changed=1
[   14.426102] [drm:intel_modeset_stage_output_state] [CONNECTOR:13:HDMI-A-1] to [CRTC:9]
[   14.426106] [drm:intel_modeset_stage_output_state] [CONNECTOR:19:DSI-1] to [CRTC:5]
[   14.426119] [drm:i9xx_update_primary_plane] Writing base 00DB5000 00000000 0 0 7680

-----------Equivalent output during boot which DID bring up Encore display ------
[   17.135744] [drm:drm_mode_getconnector] [CONNECTOR:13:?]
[   17.135758] [drm:drm_mode_getconnector] [CONNECTOR:13:?]
[   17.135810] [drm:drm_mode_getconnector] [CONNECTOR:17:?]
[   17.135819] [drm:drm_mode_getconnector] [CONNECTOR:17:?]
[   17.135857] [drm:drm_mode_getconnector] [CONNECTOR:19:?]
[   17.135867] [drm:drm_mode_getconnector] [CONNECTOR:19:?]
[   17.248502] [drm:drm_mode_addfb] [FB:51]
[   17.248519] [drm:drm_mode_setcrtc] [CRTC:5]
[   17.248528] [drm:drm_mode_setcrtc] [CONNECTOR:19:DSI-1]
[   17.248534] [drm:intel_crtc_set_config] [CRTC:5] [FB:51] #connectors=1 (x y) (0 0)
[   17.248540] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:5], mode_changed=0, fb_changed=1
[   17.248545] [drm:intel_modeset_stage_output_state] [CONNECTOR:13:HDMI-A-1] to [CRTC:9]
[   17.248548] [drm:intel_modeset_stage_output_state] [CONNECTOR:19:DSI-1] to [CRTC:5]
[   17.248557] [drm:valleyview_set_rps] GPU freq request from 178 MHz (191) to 666 MHz (213)
[   17.251673] [drm:i9xx_update_primary_plane] Writing base 00DB5000 00000000 0 0 7680
[   17.255562] [drm:drm_mode_setcrtc] [CRTC:9]
[   17.255573] [drm:drm_mode_setcrtc] [CONNECTOR:13:HDMI-A-1]
[   17.255578] [drm:intel_crtc_set_config] [CRTC:9] [FB:51] #connectors=1 (x y) (0 0)
[   17.255583] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:9], mode_changed=0, fb_changed=1
[   17.255588] [drm:intel_modeset_stage_output_state] [CONNECTOR:13:HDMI-A-1] to [CRTC:9]
[   17.255591] [drm:intel_modeset_stage_output_state] [CONNECTOR:19:DSI-1] to [CRTC:5]
[   17.255602] [drm:i9xx_update_primary_plane] Writing base 00DB5000 00000000 0 0 7680

thanks for the investigation, Robert! I've been meaning to file a new bug with the details from the V8P failure for a while now, but I keep getting sucked into other discretionary projects instead...

note I never have any kind of external display connected, I'm testing strictly with the internal panel only.

we should probably try to identify the separate issues and file new reports for each.

(In reply to Adam Williamson from comment #66)
> we should probably try to identify the separate issues and file new reports
> for each.

Agreed. This bug has grown long and hairy. Please file new bugs on the remaining issues, against latest kernels. Thanks for the report and all the testing.

Filed my V8P 3.16 fail as https://bugs.freedesktop.org/show_bug.cgi?id=82880 .