Created attachment 136985 [details] boot output with drm.debug=0x1e with drm enabled hello, for quite some time i'm trying to get drm working on a trekstor twin 10.1, a baytrail (Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz) tablet, but during drm initialization the screen goes blank. from the software side everything seems to work well, as the xorg process is running and i can login blindly and see the lxde session processes running - its just that the display does not show anything. i got backlight control fully working via the dracut workaround from https://bugs.freedesktop.org/show_bug.cgi?id=96571 - so the backlight is not the problem. this is neither a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=82880 - which fixed a very similar problem on my dell venue pro 8, but does not help on this trekstor tablet (i tried it with hans de goede's tree from yesterday). i'll attach a full dmesg output with drm.debug=0x1e from drm-tip as of now (git hash 59275f1cec1d31adab39ddb6ab948519ac8ddffb) - once with drm (where i get the blank screen) and once running with nomodeset (where everything is running fine - but without drm, which i would like to get running). please let me know, if you need any more information to help getting this sorted out. i can compile kernels easily, have ssh access to the machine when the screen is blank etc. and can run more commands for debugging if needed. the os is lubuntu 17.10 btw. a lot of thanks in advance and best wishes thomas
Created attachment 136986 [details] same boot output with nomodeset kernel parameter, i.e. no drm
Created attachment 136987 [details] kernel config used
some more things i already tried and which did not work: * xrandr --output DSI-1 --off ; xrandr --output DSI-1 --auto * xrandr --output DSI-1 --gamma 1:1:1 * xrandr --output DSI-1 --gamma 2.20:2.20:2.20
Hi, It looks like your kernel tree was not entirely clean when you build the kernel you used to get the drm.debug=0x1e log. These messages: [ 5.790660] [drm:intel_dsi_vbt_exec_sequence [i915]] Starting MIPI sequence 1 - MIPI_SEQ_DEASSERT_RESET [ 5.790753] [drm:intel_dsi_reset_clocks [i915]] [ 5.790853] [drm:intel_dsi_reset_clocks [i915]] [ 5.801010] [drm:intel_dsi_reset_clocks [i915]] [ 5.801113] [drm:intel_dsi_reset_clocks [i915]] [ 5.901621] [drm:intel_dsi_reset_clocks [i915]] [ 5.901723] [drm:intel_dsi_reset_clocks [i915]] Should show something else for the ntel_dsi_reset_clocks lines. This typically happens if you make some changes and try to speed things up by using make modules M=drivers/gpu/drm/i915 to speed up building. For some reason this confuses the code injecting the function names in the debug logging. Can you retry with a clean kernel build and attach a new log ? Regards, Hans
hi hans, this is really strange as this is from a clean build: git clone, make oldconfig, make bzImage modules ... but i'll rebuild from scratch to be sure and post the results here ... thanks a lot for looking into it and best wishes - thomas
does this dmesg look better? it is from drm-tip git-hash 59275f1cec1d31adab39ddb6ab948519ac8ddffb cleanly compiled. maybe the first dmesg was wrong, as i did a 'find . -type f -name '*.ko' | xargs -n 1 objcopy --strip-unneeded', which maybe is not a good idea in this debugging situation?
Created attachment 137011 [details] new dmesg with hopefullybetter debug output
Yes this is better, quoting the same bit from the log as before: [ 2.984008] [drm:intel_dsi_vbt_exec_sequence [i915]] Starting MIPI sequence 1 - MIPI_SEQ_DEASSERT_RESET [ 2.984230] [drm:mipi_exec_gpio [i915]] [ 2.984457] [drm:mipi_exec_delay [i915]] [ 2.994759] [drm:mipi_exec_gpio [i915]] [ 2.994989] [drm:mipi_exec_delay [i915]] [ So now we can actually see what the MIPI sequences are doing (to some degree) unfortunately everything looks normal and there is not really a clue there why the panel stays black.
anything else i might do or try - any patches, reg-dumps, vbt-dump,more debugging options? would ssh access to the machine be helpful for you maybe? best wishes - thomas
(In reply to hexdump from comment #9) > anything else i might do or try - any patches, reg-dumps, vbt-dump,more > debugging options? would ssh access to the machine be helpful for you maybe? > > best wishes - thomas One thing which stands out in the logs is: [ 1.960175] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip To fix this you need to make sure that the pwm-lpss modules are built into you're initrd, or just built them into your kernel, then that error should go away and that might help. If that does not help, the only other thing I can think of is looking at an ACPI dump to see if anything stands out there. So if fixing the PWM error does not help, please run acpidump and attach a dump here. Regards, Hans
p.s. Looking at your logs more, it seems that you're not building the axp20x mfd code into the kernel, as the help text for MFD_AXP20X_I2C i2c says: Note on x86 this provides an ACPI OpRegion, so this must be 'y' (builtin) and not a module, as the OpRegion must be available as soon as possible. For the same reason the I2C bus driver options I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_BAYTRAIL must be 'y' too. So please make sure you've those and that you've also enabled XPOWER_PMIC_OPREGION. Related: are you building i915 into your kernel, or is it a module. If it is builtin please make it a module, there may be probe ordering issues otherwise. This message: axp20x-i2c i2c-INT33F4:00: AXP20x variant AXP288 found Should be in your logs before any i915 drivers *and* the PWM error needs to be gone. This alone might very well be enough to fix this...
hello, i have rebuilt the kernel, keeping all your notes from above in mind, i.e. MFD_AXP20X_I2C=y I2C_DESIGNWARE_PLATFORM=y I2C_DESIGNWARE_BAYTRAIL=y XPOWER_PMIC_OPREGION=y then i rebuilt the initramfs with dracut with the i915 module removed, so that it loads later and the result is that the load order of pwm and i915 is now right (see attached new dmesg). sadly the screen still gets black as soon as the i915 module gets loaded (tested too via booting with init=/bin/sh and loading it by hand on the cmdline). its really funny: in the fully botted system i can still blindly login to the properly running lxde session and even dpms turns off the backlight after a while and pressing a key or mouse button brings it back, but all this just with an empty screen. i ran across https://bugs.freedesktop.org/show_bug.cgi?id=96923 which seems to be exactly the same problem with no real solution - my tablet has the same innolux 8x12 panel entry in the bios as mentioned in that ticket (maybe the same hardware sold under a different label). attachments coming: updated dmesg with proper pwm & i915 load order, new kernel config and acpidump as requested. a lot of thanks and best wishes - thomas
Created attachment 137026 [details] dmesg with proper load order of pwm-lpss and i915 module
Created attachment 137027 [details] adjusted kernel config
Created attachment 137028 [details] acpidump
Created attachment 137029 [details] (corrected) dmesg with proper load order of pwm-lpss and i915 module the last dmesg was not yet the proper one - this is the right one - please ignore the last one
Bummer, I was hoping getting the probe order right would fix things. I've looked at the ACPI tables, but nothing stands out, so I'm all out of clues I'm afraid.
thanks a lot - sad, but true ... in case anyone else has any more debug ideas, i'm open for more experiments to get drm finally working on this tablet ... once more lots of thanks and best wishes - thomas
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Jani, Ville any advice here?
hello, i have just double checked it with the drm-tip as of now (git commit b5665798788eb7885c48c4aea2aba42743829742) and the problem is still the same. i'll attach a current dmesg and pictures of the relevant bios screens - maybe something there is configured wrong. best wishes - thomas
Created attachment 139186 [details] dmesg of drm-tip 4.17-rc2
Created attachment 139187 [details] bios settings 01/03
Created attachment 139188 [details] bios settings 02/03
Created attachment 139189 [details] bios settings 03/03
Can you send dmesg from latest drm-tip with drm.debug=0x1e?
Reporter, I guess still missing dmesg with drm.debug=0x1e?
please give me a bit of time, as i have no access to this device right now - i'll add the requested debug output soon.
ok, thanks.
Created attachment 139460 [details] dmesg for 4.17.0-rc4 drm-tip as of today with debug 0x1e
Created attachment 139461 [details] used config for the last dmesg
i have just attached a dmesg with drm.debug 0x1e from todays drm-tip (git hash 8e1dab6e913be7d014eb9bc355ec65b6b56dcd56) and the corresponding config. the i915 module has been removed from initrd via dracut, so that it gets loaded later (this is needed to make the backlight control work on this system). the problem is still the same: the kernel boots and outputs fine until the i915 module gets loaded - then the screen goes blank. backlight control is fine (i can change the brightness of the blank screen via /sys/class/backlight/intel_backlight/brightness) - that is not the problem. it seems to be more a problem of the panel initialization, as it works perfectly well with a monitor attached to the mini-hdmi port and bootting without the external monitor attached and the blank panel it seems to work, as the x-server gets starts and initializes well and i can even login blindly at the blank screen (i can see it when logging in remotely) - somehow the rendered screen is not sent properly to the panel after the kms. with nomodeset everything is fine - but of course all the nice things of kms are missing :) a lot of thanks in advance and best wishes - hexdump
just a little update: as there was little chance of this getting fixed i have now sold the tablet and no longer can verify anything regarding this problem. but maybe someone else with the same hardware can, as it is very common hardware here in germany.
(In reply to hexdump from comment #33) > just a little update: as there was little chance of this getting fixed i > have now sold the tablet and no longer can verify anything regarding this > problem. but maybe someone else with the same hardware can, as it is very > common hardware here in germany. Thanks for the update, sorry we couldn't help you. :( Closing with arbitrary WONTFIX resolution; anyone with the hardware may reopen.
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.