Please add drm.debug=0xe to your kernel command line and attach a new dmesg. Created attachment 115803 [details]
dmesg of 3.19.8.6 with drm.debug=0xe as requested
by the way, if I start with drm.debug=0xe I got a visible screen now and can login into gnome (wayland not tested yet)
ok info with drm.debug (dmesg) added. will test other branches later... with drm.debug the issue does NOT occur, that's nice to know... Created attachment 115865 [details]
dmesg of 4.1.0-rc4 with drm.debug=0xe
here the issue occurs with drm debug enabled
Created attachment 115870 [details]
dmesg of kernel v4.0.4.6 where I have also only a black screen with KMS enabled
Created attachment 115904 [details]
dmesg of 3.19.8 with drm debug and vblank issue (blank screen)
(In reply to Ander Conselvan de Oliveira from comment #1) > Please add drm.debug=0xe to your kernel command line and attach a new dmesg. added dmesg as you requested, do you need more infos ?? Looks like we're failing to parse some MIPI DSI related fields. Adding Shobhit for feedback. Yes. Looks like this device has newer sequence version which the current parser is not identifying. You can use intel-gpu-tools to dump the whole VBT. There is also a DSI sequence parser in igt which can dump the sequence block. Can you attach the two dumps. Also can you try the patches which are currently under review in intel-gfx for version 3 sequence to see if it fixes the problem - http://lists.freedesktop.org/archives/intel-gfx/2015-July/072463.html (In reply to Shobhit from comment #9) > Yes. Looks like this device has newer sequence version which the current > parser is not identifying. To clarify, unfortunately the DSI sequence format is not specified in a way that allows forward compatible parsing. (In reply to Jani Nikula from comment #10) > (In reply to Shobhit from comment #9) > > Yes. Looks like this device has newer sequence version which the current > > parser is not identifying. > > To clarify, unfortunately the DSI sequence format is not specified in a way > that allows forward compatible parsing. Yes, but the v3 sequence has some sort of TLV structure so that we can skip unknown ones rather than aborting the whole parsing. (In reply to Shobhit from comment #11) > (In reply to Jani Nikula from comment #10) > > (In reply to Shobhit from comment #9) > > > Yes. Looks like this device has newer sequence version which the current > > > parser is not identifying. > > > > To clarify, unfortunately the DSI sequence format is not specified in a way > > that allows forward compatible parsing. > > Yes, but the v3 sequence has some sort of TLV structure so that we can skip > unknown ones rather than aborting the whole parsing. \o/ (In reply to Shobhit from comment #9) > Yes. Looks like this device has newer sequence version which the current > parser is not identifying. You can use intel-gpu-tools to dump the whole > VBT. There is also a DSI sequence parser in igt which can dump the sequence > block. Can you attach the two dumps. > > Also can you try the patches which are currently under review in intel-gfx > for version 3 sequence to see if it fixes the problem - > http://lists.freedesktop.org/archives/intel-gfx/2015-July/072463.html thanks for the info, I tried today (I am back at this device) to dump the VBT with $ intel_bios_dump vbt.dump but all I got is: Couldn't read graphics card ROM: Input/output error I am logged in via ssh, cause with the enabled drm I got locally o display yet. What can I do to get the dump anyway?? intel_bios_reader /sys/kernel/debug/dri/0/i915_opregion > vbt.dump run as root and ensure that you are using latest version of i-g-t which has support for DSI sequence parsing. Please provide the resulting vbt.dump file Created attachment 117558 [details]
vbt.dump
Did you try applying the patches I pointed to - http://lists.freedesktop.org/archives/intel-gfx/2015-July/072463.html Sorry to ask again, but can you simply give me the opregion dump - cat /sys/kernel/debug/dri/0/i915_opregion >> opregion.bin Created attachment 117643 [details]
pregion of yoga 851f with kernel 4.2.0-rc6 + local changes on mfd/arizona
I just did not have tried the patch you mentioned, but I will do so today.
Can you give me the url of the git repo, where I can find these patch(es) ?
Thank you
Created attachment 117648 [details]
Seq 3 patches
Seq3 patches from ML
(In reply to Shobhit from comment #18) > Created attachment 117648 [details] > Seq 3 patches > > Seq3 patches from ML Uploaded the patches from ML. Don't think there are available in any public repo (In reply to Christian Hartmann from comment #17) > Created attachment 117643 [details] > pregion of yoga 851f with kernel 4.2.0-rc6 + local changes on mfd/arizona Thanks. After analysing it seems this is Sequence Ver 2 and not 3. In this version I2C has been added as a new element which is not there in existing code which is version1 today. Perhaps out of all the seq3 patches that I uploaded, patch 1 should be sufficient for you as I can see parsing failing at element type '4' which is i2c and not available. Just try patch 1. That should also work for you. > > I just did not have tried the patch you mentioned, but I will do so today. > Can you give me the url of the git repo, where I can find these patch(es) ? > > Thank you Created attachment 117665 [details]
full dmesg of 4.2.0-rc6 with patch 001 applied of the seq3-patch-series
hi,
I have applied the first patch (1.patch) and recompiled, here is an actual dmesg
of the current torvalds/master + your patch (and some others regarding arizona)
please, can you have a look into it again, actual I have still the blackscreen issue with i915.modeset=1
This time the error is slightly different. Last time it was one element within a sequence and now it is showing unknown sequence itself. Looks like the differences between ver2 vs ver3 are not matching with this VBT. Can you go ahead and apply all the patches that I gave and test again. (In reply to Shobhit from comment #22) > This time the error is slightly different. Last time it was one element > within a sequence and now it is showing unknown sequence itself. Looks like > the differences between ver2 vs ver3 are not matching with this VBT. Can you > go ahead and apply all the patches that I gave and test again. Ok, I applied all nine patches of Seqv3 patchseries. If I try to compile I got CHK include/config/kernel.release make KBUILD_SRC= CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/config_data.h CC drivers/gpu/drm/i915/i915_drv.o In file included from drivers/gpu/drm/i915/i915_drv.c:34:0: drivers/gpu/drm/i915/i915_drv.h:1706:23: error: field 'hotplug' has incomplete type struct i915_hotplug hotplug; ^ make[6]: *** [drivers/gpu/drm/i915/i915_drv.o] Error 1 So I commented this field out at the moment. After reboot of this patched kernel, I have another error [ 2.576428] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 [ 2.586600] Loading compiled-in X.509 certificates [ 2.588326] [drm:mipi_exec_i2c] *ERROR* i2c transfer failed -6 [ 2.588329] [drm:generic_exec_sequence] Starting MIPI sequence - MIPI_SEQ_INIT_OTP so black screen still exists here also with all patches applied. I attach the whole dmesg Created attachment 117753 [details]
dmesg of 4.2.0.79-rc7 with Seq3 patchseries (9 patches) included
the Seq3 patchseries does indeed resolve the unknown mipi sequence block error which occured before this kernel and currently in all vanilla kernels.
Created attachment 117757 [details]
dmesg of 4.2.0.79-rc7 with Seq3 patchseries (9 patches) included, but this time I have a visible screen
ups, I have to retest and do some reboots to be sure, seems to work now as expected and I have a normal screen output.
Tested serveral reboots and I discovered the following:
sometimes I got a normal screen output, sometimes not. I can not reproduce this behaviour.
At first it seems I have to reboot three times until I got a visible screen, but as said before, it is not reproduceable. At the next reboot it can work again or fail as usually.
Can you confirm that whenever it fails you get I2C ERROR and in normal scenario you do not get this error. Adding Deepak M who is owning these patches right now. These patches are under review and might have issues as well. (In reply to Shobhit from comment #26) > Can you confirm that whenever it fails you get I2C ERROR and in normal > scenario you do not get this error. Adding Deepak M who is owning these > patches right now. These patches are under review and might have issues as > well. I got also i2c errors if the screen is normal and visible. I have bootet today about 3 dozen times, and about 4 till 8 times it bootet with screen enabled. In the other cases I have to login via ssh but seeing also the i2c error (if I did not messed things up today) All what I can say additionally, that the screen flickers shortly and remains darkgrey/black with backlight seen in background. Can you please try the below changes in the mipi_exec_i2c() ?
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -485,22 +485,23 @@
msg.addr = slave_add;
msg.flags = 0;
- msg.len = 2;
+ msg.len = payload_size + 1;
msg.buf = &transmit_buffer[0];
do {
ret = i2c_transfer(adapter, &msg, 1);
- if (ret == -EAGAIN)
+ if (ret == 1)
+ break;
+ else if (ret == -EAGAIN)
usleep_range(1000, 2500);
- else if (ret != 1) {
- DRM_ERROR("i2c transfer failed %d\n", ret);
+ else {
+ DRM_ERROR("i2c transfer failed, error code:%d", ret);
break;
}
} while (retries--);
if (retries == 0)
- DRM_ERROR("i2c transfer failed");
-
+ DRM_ERROR("i2c transfer failed, error code:%d", ret);
out:
kfree(transmit_buffer);
Regards,
Deepak
Hi, I have applied this patch above with the comment #28 here is the error message + errorcode : sorry, I entered in the wrong window and posted too early... [ 2.445753] [drm:mipi_exec_i2c] *ERROR* i2c transfer failed, error code:-6 [ 2.445757] [drm:generic_exec_sequence] Starting MIPI sequence - MIPI_SEQ_INIT_OTP [ 2.452018] [drm:intel_dsi_enable] Do you need the whole dmesg again? Created attachment 117780 [details] dmesg 4.2.0.80-rc7 with latest patch from comment 28 (screen visible) Created attachment 117781 [details] dmesg 4.2.0.80-rc7 with latest patch from comment 28 (screen is black) this was the next reboot Can you please try to read the bus number and slave address by adding prints in the mipi_exec_i2c(). ok, here they are: non visible screen: [ 2.349477] usbhid: USB HID core driver [ 2.349541] PCCT header not found. [ 2.349871] [drm:mipi_exec_i2c] *ERROR* i2c transfer failed (retry), error code:-6 , bus_number:2 ,slave_address:44 [ 2.349876] [drm:generic_exec_sequence] Starting MIPI sequence - MIPI_SEQ_INIT_OTP for the case of a visible screen I will report again later i2c errors exists both in working and non working logs. As far as i remember the i2c elements were used for backlight on/off sequence in BYT. So can you please confirm when the display is blank are you able to see the backlight ? Also the bus number what we were using was 3, can you please try to hardcode the value of 3 for the bus number in the mipi_exec_i2c() and give a try. Created attachment 117801 [details] [review] patch Oops wait from the logs looks like the i2c elements are in the MIPI_SEQ_ASSERT_RESET sequence, and also looks like MIPI_SEQ_ASSERT_RESET and MIPI_SEQ_INIT_OTP are executed together, but device ready has to be set between these sequence execution. Can you please try to apply the attached patch and give a try. for all versions since 3.18/3.19 ( as fredlet started with an install image for uefi32 bit systems) I can always see backlight. Its the only indication for me to see that the system is running. It has no power led. It has only one microusb port for loading the battery or to attach an usb hub for using a keyboard + mouse etc. So, the question if I see backlight: yes I see always backlight. On power on (pressing 3sec the power button), the device itself flickers to indicate that it has been powered up. If I start with drm, yes the screen shows a little bit of initramfs (some lines at the tp of the screen showing just some ioremap errors and switches or flickers shortly ( I think it would be the starting plymouth). If I start w/o drm I see also the ioremap errors mentioned above, but than it goes on with the syslog from systemd printing all message (too fast to read it by the way) until the splashscreen is seen. at gdm works but without drm as said. I have applied the last patch and the first two boots are black. I have now hardcoded the bus_number to 3 as said in your preprevoius comment, the result of this change will be known at the next reboot (this was build of kernel 4.2.0-83) here the result of the 4.2.0.84-rc7 (with the hardcoded bus_number = 3 ) I have a visible screen after two boots in sequence !!! :) so far, I will make some more reboots today, but at first it seems we got it. Do yo need again a debug for this case? The patches from Seq3 (1.patch till 9.patch) and the two additional patches ( I call them a.patch and b.patch) are now applied and in testing on a local branch derived and rebased often on torvalds/master. Thank you by the way for your help. oops, I was to fast with my reply. The next 3 boots started without the visible screen, the 4th boot is again visible. I started gnome under wayland, the system got hard freezed like yesterday after using it for some seconds. So drm is working from time to time. and it seems to freeze (wayland is here an older version v1.6.90), on the other box I have 1.8.90 and later from git and its stable AFAIK). I try to get the errors next time and save the logs. Created attachment 117889 [details]
4.2.0.93-rc8 (+local patches of SeqV3 applied)
hi,
today I just compiled rc8 with the seq3 patches enabled,
and starting the device 3 times, where one time the display is visible,
in the other two cases like in this dmesg, the screen is black (with backlights seen at the borders like everytime).
I have no idea what, but I think its an timing issue, because of the statistics that of rebooting the device often, that sometimes I got a screen and most of the time it does not get attached or whatever.
The bit banging message was also one of my possible issue canidates, but I cannot prove it yet.
the next attachment is again with full visible screen (KMS working as expected and running an older weston version)
thank you so far for the help by the way
Created attachment 117890 [details]
4.2.0.93-rc8 (+local patches of SeqV3 applied) screeen is visible and local login via GDM/weston session also
I do not have compared each dmesg in detail, but this dmesg is with visble screen. should be fine, if this happens all the time :)
additional note: in all cases of KMS without a visible screen, the machine does not reboot or shutdown ordinary. If its only black, I always send an init 0|6 but I have to always use the powerbutton to really reset / reboot the machine. With no KMS enabled, all is fine with reboots etc, also if the screen is visible with KMS enabled. Hope that helps too I have tested with latest 4.3.0-rc1 from torvalds with the SeqV3 patches applied too. So far not fixed yet. What I also noticed a while is the message seen below the ioremap errors <snip of dmesg 4.3.0-rc0 / local branch yoga851f> [ 0.256169] usbcore: registered new device driver usb [ 0.256495] ioremap error for 0x78789000-0x7878a000, requested 0x2, got 0x0 [ 0.256514] dmi: Firmware registration failed. [ 0.256834] Advanced Linux Sound Architecture Driver Initialized. [ 0.256845] PCI: Using ACPI for IRQ routing ... ... [ 2.416855] mmc2: SDHCI controller on ACPI [80860F14:01] using ADMA [ 2.416942] ioremap error for 0x78789000-0x7878a000, requested 0x2, got 0x0 [ 2.417089] EFI Variables Facility v0.08 2004-May-17 [ 2.443708] ioremap error for 0x78620000-0x78621000, requested 0x2, got 0x0 [ 2.443841] esrt: ioremap(0x78620510, 56) failed. [ 2.443972] hidraw: raw HID events driver (C) Jiri Kosina </snip> It is also a new feature since kernel release 4.2 AFAIK. But like with the BGRT from the ACPI tables, there seems to be something else wrong. Do not really know yet, if this is the core of this issue here... hi again, I have another note here for this issue: EVERYTIME the device is fully charged, I boot with KMS enabled and it shows the display as expected. If I would boot again (second time), it fails to enable the screen (blacklight yes, but it still shows nothing, only a black screen). It flickers shortly like everytime, I saw a red screen for less than a second (some miliseconds), than it goes black and stays black. So it fails to enable the display at the second boot. Created attachment 118310 [details]
4.3.0-rc1 with Seqv3 Patches (WORKING example)
after fully charge its working as expected
Created attachment 118311 [details]
4.3.0-rc1 with Seqv3 Patches (FAILING example)
the second boot fails like most of the time.
I've the same blank screen problem on a different baytrail tablet. I've a bug open for it. (#93799) Christian: If you are still interested in this, you can try compiling and running linux-next-20151012, as it works on my tablet without any further patches. I haven't tried if the screen works for the 2nd time even after a reboot. Later kernels I tried do not work, but I try only 1 linux-next each month. So there's tons of DSI related fixes in drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel. Please try that and report back. Created attachment 123725 [details]
dmesg of 4.6.0-rc7-intel-drm-nightly dsi display not working
I've retried with the intel-drm-nightly but the dsi display is still not working. I know it works correctly with linux-next-20151012, and linux-next-20151019. I will try to find the last linux-next it works with, and check the commits that broke it. Also I've checked the working and failing dmesg, and there are a few differences leading up to the WARNING in the failing example.
I found the commit that makes my DSI display go blank (and causes the WARNING) when the KMS loads with kernels newer than linux-next-20151119: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/i915?id=7383123647566a813692bb37a1389c767ed89158 Revert "drm/i915: skip modeset if compatible for everyone." This commit brings back the i915.fastboot parameter in disabled state, and with that the DSI screen goes blank when KMS loads. Adding i915.fastboot=1 kernel bootline parameter to a recent v4.6 RC4 kernel enables my Teclast X80h tablet to boot with the DSI screen enabled. *** Bug 93799 has been marked as a duplicate of this bug. *** (In reply to Laszlo Fiat from comment #51) > I found the commit that makes my DSI display go blank (and causes the > WARNING) when the KMS loads with kernels newer than linux-next-20151119: > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/ > drivers/gpu/drm/i915?id=7383123647566a813692bb37a1389c767ed89158 > > Revert "drm/i915: skip modeset if compatible for everyone." > > This commit brings back the i915.fastboot parameter in disabled state, and > with that the DSI screen goes blank when KMS loads. > > Adding i915.fastboot=1 kernel bootline parameter to a recent v4.6 RC4 kernel > enables my Teclast X80h tablet to boot with the DSI screen enabled. Sorry, the earlier regressions trumps the later one, so we'll have to keep the revert, for now. Also, i915.fastboot=1 tries to skip modeset at module load, so presumably our DSI modeset for your panel doesn't work. I suspect a modeset might fail if you tried it after booting with i915.fastboot=1. Please also attach /sys/kernel/debug/dri/0/i915_vbt Might also be interesting to see the dmesg running drm-intel-nightly plus this series of patches https://patchwork.freedesktop.org/series/7234/ Created attachment 123787 [details] i915_vbt of Teclast X80h tablet This was requested in comment 53. Created attachment 123788 [details]
dmesg of intel drm nightly 20160512 with fastboot=1 dsi display not working
This is getting interesting. While fastboot=1 makes the dsi display working on 4.6rc4, it doesn't help with the intel-drm-nightly 20160512, where the screen goes blank when the modesetting happens. However fastboot=1 makes the WARNING go away.
Created attachment 123789 [details] dmesg of 4.6.0-rc4 with fastboot=1 dsi display works This is for reference, the v4.6 rc4 with fastboot=1, where the dsi display is working. I think the drm activates correctly. I'll compile a new intel-drm-nightly with the patches from comment 54, and report back. Created attachment 123840 [details] dmesg of intel-drm-nightly 20160516 plus patches Requested in comment 54, a dmesg with debug of kernel intel-drm-nightly 20160516 plus patches. The DSI display goes blank when KMS happens. fastboot=1 doesn't make any difference with this intel-drm-nightly version. Tested with Asus-T1000, latest nightly kernel, not able to reproduce the issue, commit dd7de1cfa8bdf1878399474b92ff14f89fc18c69 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu May 12 14:30:01 2016 +0300 drm-intel-nightly: 2016y-05m-12d-11h-29m-40s UTC integration manifest Kernel version : 4.6.0-rc7 Architecture : source amd64 all Homepage : http://www.kernel.org/ GRUB_CMDLINE_LINUX="linux (hd1,gpt2)/boot/4.6.0-rc7-dd7de1c root=/dev/mmcblk0p2 quiet reboot=pci,force i915.modeset=1 drm.debug=0xe" Is there something else missing in the configuration? i915.fastboot=1 worked on ubuntu 16.04 offical kernel. Great job ! |
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.
Created attachment 115800 [details] whole dmesg of 3.19.8.6 kernel boot on lenovo yoga 2 851f with i915 modeset=1 tested with vanilla kernels on the lenovo yoga 851f * 3.19.1 till 3.19.8 (currently the EOF) * 4.0.0 till 4.0.2 * 4.1.0-rc1 till 4.1.0-rc3 with i915.modeset=1 I got only a black screen in the dmesg I saw also a previous error message [ 1.212294] [drm:intel_parse_bios] *ERROR* Unknown element [ 1.212306] [drm:intel_parse_bios] *ERROR* Sequence elements going beyond block itself. Sequence block parsing failed but I do not know if that is the root cause of the bug reported by the kernel. If I boot without KMS, I can use the machine with Xorg but without acceleration etc. I need KMS for the Wayland / weston setup. I attach the whole dmesg and if more debugs or infos are needed, I will provide them too