HI All: I work for AAEON an Asus company who makes embedded, long life, motherboards. I am running into a situation with a large customer of mine that wants to use a 15.6" LCD Panel, https://dl.dropboxusercontent.com/u/52392/TFT-LCD%2BPreliminary%2BSpecification%2BG156BGE-L01%2Bver%2B1.0.pdf connected to the EMB-BT1 with the n2807 SOC, I have also tried the E3825/E3845 series and have the same issue, https://dl.dropboxusercontent.com/u/52392/EMB-BT1.pdf connected via the LVDS Connector. AAEON takes the eDP port and runs it through a Chrontel CH7511, http://www.chrontel.com/media/Datasheets/CH7511B%20Brief%20Datasheet%20V1.13.pdf chip to convert it to the LVDS Signal. The issue I am having is when LVDS is only connected and the system boots up I do not get a picture on the LCD Panel. Once I kill power to the board and connect a HDMI or VGA connection the board boots up with Ubuntu 14.04. I am able to boot into the BIOS and check all the settings but once I leave the BIOS and Ubuntu tries to start up I get a white screen on the LCD Panel. Here is a video I took: https://dl.dropboxusercontent.com/u/52392/LVDS.mp4 I have been trying to load the daily and drm-intel-nightly builds of the latest kernel but this issue still comes up. I have even tried today's build of 2014-05-15. I know this is something with the Linux Kernel because when I load up Windows 8 I get a picture automatically every time without this white screen. I also have tried Timesys 18 Fedora Remix Image: https://dl.dropboxusercontent.com/u/52392/GettingStarted_Timesys18FedoraRemix.pdf and I do not experience this issue. The system still boots and I can ssh into it. I installed today's latest kernel 2014-05-16 and here is the dmesg: http://pastebin.com/F59jdUF4 Please contact me if you have any questions or things to try. My contact is in my signature below. Thank you for looking at this issue.
dmesg drm.debug=0x06 output: http://pastebin.com/yKbs8FF7
Sorry the last dmesg didn't have the drm.debug=0x06 This log below is from 2014-05-17-utopic drm-intel-nightly kernel. http://pastebin.com/2jheFu67
(In reply to comment #2) > Sorry the last dmesg didn't have the drm.debug=0x06 > > This log below is from 2014-05-17-utopic drm-intel-nightly kernel. > > http://pastebin.com/2jheFu67 Please attach to the bugzilla, pastebin gets lost.
Created attachment 99335 [details] 2014-05-16 dmesg with debug
Daniel, What other information do you need from me? I am willing to provide anything and everything to help fix this issue? I have 3 major customers using the same LCD Panel that are having this issue. Please let me know, you can email me directly at dominikr@aaeon.com or call me 872-201-0158 also anytime. I am based in Chicago.
(In reply to comment #5) > Daniel, > > What other information do you need from me? I am willing to provide anything > and everything to help fix this issue? I have 3 major customers using the > same LCD Panel that are having this issue. Please let me know, you can email > me directly at dominikr@aaeon.com or call me 872-201-0158 also anytime. I am > based in Chicago. If you need customer support you need to escalate this through intel channels. For the actual bug: Does the vbios work, i.e. when you boot with i915.modeset=0? If so please install the latest intel-gpu-tools and grab the output of intel_reg_dumper for both the working case (using vbios) and the broken case (with i915 properly loaded).
Created attachment 99359 [details] Intel_Reg_Dumper with VGA attached This is the dump from the Intel_Reg_Dumper with a VGA connection plugged.
Created attachment 99360 [details] Intel_Reg_Dumper with LVDS only connected This is the dump of the intel_reg_dumper with only the LVDS connected and no images on the screen.
I wanted the 2nd regdump with the vbios (i.e. i915.modeset=0) but otherwise the exact same config as the broken case. Not with an external screen plugged in. Ofc course that presumes the vbios works, but you didn't confirm that yet.
Created attachment 99407 [details] Intel_Reg_Dumper with LVDS only connected with i915.modeset=0 Here is the Intel_Reg_Dumper with LVDS only connected and confirmed that i915.modeset=0 boots up, with the desktop GUI with a resolution only at 800 x600 (4:3) This was booted using the 2014-05-17-utopic/drm-intel-nightly kernel. Please let me know if there is anything else you need. Thank you
Created attachment 99409 [details] Intel_Reg_Dumper with LVDS only connected with i915.modeset=0 Intel_Reg_Dumper with LVDS only connected with i915.modeset=0 Here is the Intel_Reg_Dumper with LVDS only connected and confirmed that i915.modeset=0 boots up, with the desktop GUI with a resolution only at 800 x600 (4:3) This was booted using the 2014-05-20-utopic/drm-intel-nightly kernel. Please let me know if there is anything else you need. Thank you I plan to keep uploading these with the latest drm-intel-nightly unless you tell me otherwise Daniel. Thank you
Please don't upload new register dumps until I ask for something specific. It only adds noise.
Ok, nothing interestin in there. But there's a second byt specific dumper called quick_dump in i-g-t. Can you please run that one, again both without VGA connected, one with i915 loaded (broken state) and one with modeset=0 (somewhat working state, the lower resolution doesn't matter for now).
Created attachment 99439 [details] Quick_Dump with LVDS only connection This dump is using 2014-05-20-utopic/drm-intel-nightly With LVDS only connected without adding any modeset, boots into a blank screen.
Created attachment 99440 [details] Quick_Dump with LVDS only connection i915.modeset=0 Quick_Dump with LVDS only connection and i915.modeset=0 This dump is using 2014-05-20-utopic/drm-intel-nightly With LVDS only connected with i915.modeset=0 and booted in a 800 x 600
Created attachment 99444 [details] Quick_Dump -a with LVDS only connection
Created attachment 99445 [details] Quick_Dump -a with LVDS only connection i915.modeset=0
Hm, nothing really relevant in the reg dumps for difference ... Can you please grab a new dmesg with drm.debug=0xe? The attached one is pretty badly mangled so a bit hard to read and follow. Preferrably from a recent drm-intel-nightly.
Created attachment 99446 [details] dmesg log with drm.debug=0xe
Can you try the byt-dpio-resume-reset branch from my fdo git repo? git://anongit.freedesktop.org/~jbarnes/linux
Created attachment 99984 [details] quick_dump with LCD Panel on with drm.debug=6 This is a quick_dump log with the LCD Panel on and drm.debug=6 during boot.
Created attachment 99985 [details] quick_dump with LCD Panel on with drm.debug=6 failed quick_dump with LCD Panel on with drm.debug=6 This is a quick_dump log with the LCD Panel off and drm.debug=6 during boot.
Created attachment 99986 [details] quick_dump with LCD Panel on with i915.modeset=0 quick_dump with LCD Panel on with a resolution of 800 x 600 with i915.modeset=0
Created attachment 100043 [details] [review] always set DP port to eDP type Nothing jumps out in a quick look at the regs. But on the theory that eDP panel power sequencing has something to do with it, this patch may help.
Created attachment 100401 [details] [review] dump device type at dp init time Can you try this patch on the affected system and paste the debug output it adds into the bug? It looks like we're testing more bits than the Windows driver, so it could be that we can make things work generally without a BIOS update on your side.
Would probably be easier to just grab /sys/kernel/debug/dri/0/i915_opregion from the affected machine(s) and attach it here.
We can close this bug, we have implemented a BIOS fix for it, see image: http://www.mediafire.com/view/3gd318dgw9cm99d Thanks for the help and for all that looked into this issue.
Dominik, if it's not too much trouble, can you collect the opregion dump Ville requested from your old, pre-fix BIOS? I'm hoping we can make the driver more permissive to avoid this bug on other platforms and not require a BIOS fix...
Jesse, I will provide the dump file in a week or so. I sent my board back to Taiwan for a project, and should get it back by next Friday.
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.