This is one problem:
[    3.987505] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip
and can explain the backlight staying on.

The best workaround for that right now is to make i915 a module, and build the required i2c/gpio/pwm support into the kernel itself:
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_DESIGNWARE_PCI=y
CONFIG_INTEL_SOC_PMIC=y
CONFIG_GPIO_CRYSTAL_COVE=y
CONFIG_PWM_CRC=y
CONFIG_DRM_I915=m

For some further debug information please boot with drm.debug=0xe kernel command line option and attach the dmesg here. Also please attach a copy of /sys/kernel/debug/dri/0/i915_opregion

As far as the lockup goes, Jani had a very similar problem on a CHT tablet recently, but I think that turned out to due to wifi. Your log is also full of some audio noise as well, so I'd also try to eliminate as many non-display related drivers as possible.

To rule out GPU runtime PM do this:
'echo on > /sys/class/drm/card0/device/power/control'
before turning off the display.

To rule out display power well problems boot with i915.disable_power_well=0 kernel command line option.

(In reply to Ville Syrjala from comment #1)
> As far as the lockup goes, Jani had a very similar problem on a CHT tablet
> recently, but I think that turned out to due to wifi.

I haven't actually verified that yet; it was my best guess so far.

Created attachment 123242 [details]
opregion

Created attachment 123243 [details]
debug dmesg

> This is one problem:
> [    3.987505] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip
> and can explain the backlight staying on.
> The best workaround for that right now is to make i915 a module, and build the required i2c/gpio/pwm support into the kernel itself:
> CONFIG_I2C_DESIGNWARE_PLATFORM=y
> CONFIG_I2C_DESIGNWARE_PCI=y
> CONFIG_INTEL_SOC_PMIC=y
> CONFIG_GPIO_CRYSTAL_COVE=y
> CONFIG_PWM_CRC=y
> CONFIG_DRM_I915=m

Unfortunately, I doesn't know how to apply this to kernel, how to compile it, etc.
Not sure if this related to this particular report at all - isn't this is separate problem?

> For some further debug information please boot with drm.debug=0xe kernel command line option and attach the dmesg here.
Attached (stock kernel of Ubuntu 16.04 LiveUSB).

> Also please attach a copy of /sys/kernel/debug/dri/0/i915_opregion
Attached above.

> As far as the lockup goes, Jani had a very similar problem on a CHT tablet recently, but I think that turned out to due to wifi.
In my case this is not because of WiFi for sure, there just no drivers for WiFi of this tablet in kernel right now. So when I boot Ubuntu 16.04 LiveUSB WiFi just not working, while issue is still reproducible.

> Your log is also full of some audio noise as well, so I'd also try to eliminate as many non-display related drivers as possible.
That right, there two reports about this:
https://bugzilla.kernel.org/show_bug.cgi?id=117141
https://bugzilla.kernel.org/show_bug.cgi?id=115201

> To rule out GPU runtime PM do this:
> 'echo on > /sys/class/drm/card0/device/power/control'
> before turning off the display.
For me 'cat /sys/class/drm/card0/device/power/control' return 'on' right now. Nevertheless, I tried to 'echo on > /sys/class/drm/card0/device/power/control' and then tried to reproduce issue using steps I described above - issue is still reproducible.

> To rule out display power well problems boot with i915.disable_power_well=0 kernel command line option.
I tried to boot with this kernel option, but issue is still reproducible with disabled power well.

Hello!
I finally find how to build kernel deb packages in Ubuntu ( https://askubuntu.com/questions/729469/build-ubuntu-kernel-test-mainline-crack-v4-4-kernel-fails-to-clean )
and tried suggested workaround from Comment 1

Unfortunately, this doesn't help - tablet hang like before. 

Please let me know if there is additional info I can provide or maybe some other workaround.

This issue is on Acer One 10 (S1002)

Same issue with another BayTrail tablet DEXP Ursus 10XW (Z3735F).

I suspect this might be gnome being "helpful" and automagically suspending the machine when the display blanks.

Jani, wasn't there some kind of hidden knob for this that you found on your laptop?

Anyways, you may want to try to disable the gnome display power save thing, and just manually turn off the screen with 'DISPLAY=:0 xset dpms force off'. And to make doubly sure maybe even eliminate gnome from the equation and just fire off a bare X server, and then do the xset thing. If that doesn't hang then this doesn't look like anything to do with i915.

Well, there is still a slight chance that it might hang somewhere in i915 while suspending the machine. But it's not clear that there is even a proper hang anywhere. It's also possible the machine just refuses to wake up after being suspended.

Hi, Ville

JFYI, issue is not reproducible with this kernel https://github.com/jwrdegoede/linux-sunxi by Hans de Goede <hdegoede@redhat.com>

I doesn't know which patch fixes issue for me.

> Anyways, you may want to try to disable the gnome display power save thing, and just manually turn off the screen with 'DISPLAY=:0 xset dpms force off'.

I will check this, as soon as possible (but currently I doesn't have BayTrail devices on hands).

Gnome forcibly autosuspends tablet on screen blanking, and you can't change that setting in Gnome. What does 'hostnamectl' say?

Reference, with further links: https://bugzilla.gnome.org/show_bug.cgi?id=779300

Created attachment 131403 [details]
hostnamectl output

I re-tested this issue with Linux 4.11.1 and seems like it's no longer reproducible, nor with Gnome Powersaving Settings, not with "xset dpms force off".

hostnamectl output is attached.

If I able to reproduce it again on other BayTrail device, I will reopen this bug. For now I cannot reproduce it anymore on DEXP Ursus 10XW.