Preface

Last Updated: 20/07/2017

Hello World

As part of cleaning up, items relating to the Venue 8 that are not part of the currently tested Kernel or just really old are archived here.

Demo Time

Kernel 4.8.0, OpenBox, Tint2, Onboard.
"I'd just like to interject for a moment."
- Full Size, 1280x800, 199KB -
Kernel 4.7.0, OpenBox, Tint2 and more.
Exploring a minimalistic setup.
- Full Size, 1280x800, 233KB -
Kernel 4.4rc8, XFCE4, Audacious,
qjackctl and more.
- Full Size, 1280x800, 321KB -
OpenTTD with 2 CPU cores enabled
and power monitoring.
- Full Size, 1280x800, 423KB -
Enlightenment 20, Gkrellm, Archey,
Baka MPlayer, Amigaaaaaaaah!
- Full Size, 1280x800, 151KB -

Device Status

Dell Venue 8 Pro, on older kernels.

Unsorted Material

Kernel Patches & Others

Kept for historical reference, have a look amongst the following three if you still experiment with older Kernels.

Adam's GitHub Repo may be relevant to your interest.
John's Github Repo also has interesting things.
Bastien's GitHub Repo has gathered all SDHCI PM patches.

This repo is definitely worth a visit if you want working sound. (4.7.0+)

Pierre's GitHub Repo to get the correct audio state working.

ALSA

Manual Initialisation

If you still have no sound after deploying the UCM data, consider the following script which is a much nicer iteration from what I had up previously but thought no longer necessary. Thanks Parker! 

#Via: burzumishi's Github, alsa_cr_spk.sh

#!/bin/sh
# Enable Speakers
amixer -c0 sset 'DAC MIXL INF1' on
amixer -c0 sset 'DAC MIXR INF1' on
amixer -c0 sset 'Stereo DAC MIXL DAC L1' on
amixer -c0 sset 'Stereo DAC MIXR DAC R1' on
amixer -c0 sset 'SPK MIXL DAC L1' on
amixer -c0 sset 'SPK MIXR DAC R1' on
amixer -c0 sset 'SPOL MIX SPKVOL L' on
amixer -c0 sset 'SPOR MIX SPKVOL R' on
amixer -c0 sset 'Speaker' on
amixer -c0 sset 'Speaker Channel' on
amixer -c0 sset 'Speaker L' on
amixer -c0 sset 'Speaker R' on
amixer -c0 sset 'Speaker' 29

# Disable Headphones
amixer -c0 sset 'Headphone' off
amixer -c0 sset 'HP Channel' off
amixer -c0 sset 'HP L' off
amixer -c0 sset 'HP R' off
amixer -c0 sset 'HP' 0

Speaker output works sufficiently. Headphones are in good shape but there's still a little noise. I suspect this is because of how the DSP mixer routes. This issue has been fixed in newer Kernels.

On 4.7.0, to minimize the amount of background noise on headphones turn the "HP" slider control all the way down.

Jack Audio Connection Kit 

pacman -s jack2 qjackctl

Worked on 4.4.x, Setting the buffer lower then 1024 is not appreciated on a stock configuration. 2048 tends to be the default. Having JACK force 48Khz means nothing can waste CPU time on resampling unless explicity configured.

The following with a single core active, this scales linearly depending on number of active cores.

On 4.7.0+ JACK refuses to start correctly and angry messages appear... 

[   25.418115] intel_sst_acpi 80860F28:00: Alloc for str 1 pipe 0x90
[   25.733604] intel_sst_acpi 80860F28:00: Free for str 1 pipe 0x90
[   41.954987] intel_sst_acpi 80860F28:00: Alloc for str 3 pipe 0xe
[   42.482764] intel_sst_acpi 80860F28:00: Alloc for str 1 pipe 0x90
[   50.424469] intel_sst_acpi 80860F28:00: sst: Busy wait failed, cant send this msg
[   58.692697] intel_sst_acpi 80860F28:00: sst: Busy wait failed, cant send this msg
[   73.797857] intel_sst_acpi 80860F28:00: sst: Busy wait failed, cant send this msg

Part IV: A New Mixer

Your primary (master) volume control is the "DAC1" slider.
Again, on 4.7.0 pull the "HP" slider to 0 to reduce headphone rummaging.

Part V: The dMixer Strikes Back (Kernel 4.4.x)

Out of the box, straight ALSA does not seem to appreciate multiple sources playing audio at the same time on this soundcard. Now we could install PulseAudio or Jack to remedy this but what if you like to keep things ALSA only?

Fortunately ALSA has a software mixer called "dmix" which fixes this up for us. Keep in mind, application level volume control may work, may not work or control the global volume.

The following courtesy of the ALSA wiki modified for the Venue 8. 

#/etc/asound.conf

pcm.!default {
	type plug
	slave.pcm "dmixer"
}

pcm.dmixer  {
 	type dmix
 	ipc_key 1024
 	slave {
		pcm "hw:0,0"
		period_time 0
		period_size 1024
		buffer_size 4096
		rate 44100
	}
	bindings {
		0 0
		1 1
	}
}

ctl.dmixer {
	type hw
	card 0
}

Part VI: Return of the Synthesizer

If you require MIDI playback (Hint: Music in OpenTTD ;) you require a tool called Timidity++ which takes a soundfont and MIDI data to render a musical score to PCM audio.

You may find that Timidity consumes quite a bit of CPU time, by disabling a number of features the CPU load generated becomes more manageable. 

#/etc/timidity++/timidity.cfg
#Append the following to the end of config.

opt EFresamp=1
opt EFvlpf=d
opt EFreverb=d
opt EFchorus=d
opt EFdelay=d

Headphone Safety Warning

I suspect that the DSP output is always on full, the overall routing / internal volumes are also hard to control unless you put PulseAudio in the middle as softmixer / volume buffer. At the moment use headphones with diligence and care lest you blow up a pair or worse blow up your ears. The biological pair is hard to replace unlike the manufactured one.

Power Management 1.0

Suspend (Pre-4.12)

The 4.4 / 4.5 kernels showed signs of suspend doing atleast something but afterwards it never got any better. Meanwhile at 4.8.0 the Venue 8 simply hardlocked instead.

If for whichever reason you are unable to use a newer Kernel but do require suspend you can try the following. A person who goes by the name Jianlong Liu left me a post comment to come upon suggesting that if you disable "ALSA for SoC audio support" when getting ready to compile your kernel suspend operates correctly. 

Device drivers
⌞ Sound card support
⌞ Advanced Linux Sound Architecture

Disable for working suspend: ALSA for SoC audio support

CONFIG_SND_SOC [=n]

If you do not want to recompile your kernel or are unable to, try the following blacklist method. The following covers a range of Bay Trail devices and not just the Venue 8. I've updated the original list to accomodate the changes I noticed in 4.11-rc1. Thanks Nemanja! 

# /etc/modprobe.d/blacklist.conf

blacklist snd_soc_rt5670
blacklist snd_soc_r16231

blacklist snd_soc_sst_bytcr_rt5640
blacklist snd_soc_rt5645
blacklist snd_intel_sst_acpi
blacklist snd_intel_sst_core
blacklist snd_soc_rt5640
blacklist snd_soc_sst_mfld_platform
blacklist snd_soc_rl6231
blacklist snd_soc_sst_match
blacklist snd_soc_core
blacklist snd_compress
blacklist snd_seq
blacklist snd_pcm_dmaengine
blacklist snd_seq_device
blacklist ac97_bus
blacklist snd_pcm
blacklist snd_timer
blacklist snd
blacklist soundcore

# The following should return nothing if blacklist works.

lsmod | grep snd

I can confirm that on kernels 4.7.0, 4.8.0, 4.9.0, 4.10.0 and 4.11-rc1 this results in correct stable suspend behaviour at the expense of not having audio. Evaluate this option pending your use case. Reference #111481

Live removal (rmmod) of the various snd_soc_* modules either breaks things or angers the kernel so tread cautiously. It can be done and suspend worked a couple of times during experimenting but audio did not want to come back correctly after resume. Sofar I've not been able to find a reliable "live" removal and insertation sequence so it's one or the other.

We express our appreciation for these valuable clues as I was under the impression that it was the wifi module being at fault for suspend not working.

SDHCI ACPI

I'm not noticing any difference whether this is on or off with Kernel 4.12.

For Kernel 4.7.0 to 4.11. This ensures the WiFi module behaves better and doesn't bring down the system. eMMC and MicroSD card appear to be fine on the default "auto" setting so no need to override anything for them. 

#!/bin/sh
#$sdhci-acpi-inhibit.sh
# Wifi
echo "on" > /sys/bus/platform/drivers/sdhci-acpi/INT33BB:00/power/control

Use the following for kernels prior to 4.7.0 to gain some stability without C-state hacks. 

#!/bin/sh
#$sdhci-acpi-inhibit.sh
# Wifi
echo "on" > /sys/bus/platform/drivers/sdhci-acpi/INT33BB:00/power/control
# eMMC
echo "on" > /sys/bus/platform/drivers/sdhci-acpi/80860F14:00/power/control
# MicroSD
echo "on" > /sys/bus/platform/drivers/sdhci-acpi/80860F14:01/power/control

Roll a SystemD service. 

#/etc/systemd/system/sdhci-acpi-inhibit.service
[Unit]
Description=SDHCI ACPI Inhibit

[Service]
ExecStart=/path/to/sdhci-acpi-inhibit.sh

[Install]
WantedBy=multi-user.target

Enable said service at startup 

systemctl enable sdhci-acpi-inhibit.service

C-State Tweaking

I did C-state research but the additional heat and loss of battery life was not something I could accept. It's also not relevant anymore as C-state behaviour appears to be working (more or less) correctly now on the Venue 8 based on Kernel 4.7.0+.

It may still be of relevance for other Bay Trail folk so my notes on this matter have been preserved Here.

Optimal settings on boot

On the assumption that you're using the method as outlined in the "SDHCI ACPI" section. A friendly reminder that all the snippets of scripts can be called from here or added to.

In my particular usage case I use the inhibit hook to run additional scripts that configure system device power management as powertop recommends, disabling the intel turbo mode and have only a single CPU core enabled.

Additionally, udev rules ensure only white listed USB devices get power saving settings applied which means they'll suspend after 10 seconds.

ALSA Audio

On older kernels it can be helpful to have a properly configured ALSA as it appears to help with stability.

Kernel Compiling

Patches: 4.10.0 and Newer

No need for patches, the Kernel abides.

Patches: 4.9.0 Kernel

The following "DSI: Pipe Clock Gating" patch fixes the EFI to KMS handover which fixes the "black screen after grub" problem and makes it possible to have Grub running at native resolution. 

patch -p1 < v2-drm-i915-dsi-Do-not-clear-DPOUNIT_CLOCK_GATE_DISABLE-from-vlv_init_display_clock_gating.patch

Bay Trail Audio requires the "Atom PMC platform clocks" patch to function. Without this patch dmesg will report "bytcr_rt5640 failed with error -2" and audio won't do a thing.

patch -p1 < 13-17-clk-x86-Add-Atom-PMC-platform-clocks.patch

Patches: Pre-4.9.0 Kernels

Unless you did it by hand already then you don't need to obviously.
Grab the Dell-OEM-chipset patch from Adam's GitHub Repo for Venue 8.

#Via Adam: SDIO Device ID Patch for Wifi.
patch -p1 < support-Dell-OEM-chipset.patch

Patches: Pre-4.4.0 Kernels

Grab the other kernel patches from Bastien's GitHub Repo.

#Via Bastien: SDHCI PM set.
patch -p1 < 0001-mmc-sdhci-get-runtime-pm-when-sdio-irq-is-enabled.patch
patch -p1 < 0001-PM-QoS-Add-pm_qos_cancel_request_lazy-that-doesn-t-s.patch
patch -p1 < 0002-mmc-sdhci-Support-maximum-DMA-latency-request-via-PM.patch
patch -p1 < 0003-mmc-sdhci-acpi-Fix-device-hang-on-Intel-BayTrail.patch

#Kernel 4.4 saw "sdhci-pci.c" renamed to "sdhci-pci-core.c"
#When prompted manually provide following, or fix file name in patch.
#/path/to/kernel/source/drivers/mmc/sdhci-pci-core.c

patch -p1 < 0004-mmc-sdhci-pci-Fix-device-hang-on-Intel-BayTrail.patch

Tackling Grub

This segment needs a clean up. It mostly applies to older Kernels.

This section applies entirely to the Venue 8 Pro. Venue 11 Pro is happy with the default EFI methods Arch and Fedora use.

Boot Loader Options

rEFInd

On BIOS A04 it would correctly display itself but on BIOS A10 & A13 nothing happens anymore. Should work for 32-bit kernels, won't for 64-bit.

eLILO

Hangs immediately only showing a white cursor.

Syslinux, GummiBoot / SystemD-boot

A 32-bit kernel with 32-bit EFI stub should be a straight boot but you cannot start a 64-bit kernel with a 64-bit EFI stub from a 32-bit EFI shell.

ToDo: Revisit EFI loaders with Kernel 4.10.

Grub

Does not care despite being a 32-bit UEFI shell, and will boot anything you throw at it. So Grub is what we shall use.

Combined with Kernel 4.10 things work. For older kernels the following information segments may be relevant to your interest.

The BIOS "Boot Mode" Menu Explained

"If you must blink, do it now. Pay careful attention to everything you see and hear, no matter how unusual it may seem." - Kubo (KaTTS)

Dell Venue 8 Pro, POST Screen
Notice the ProTips in the lower right.
- Full Size, 1280x853, 101.0KB -
BIOS "Boot Mode" (Pre-Boot) Menu
Press "Volume Down" at POST to get here.
- Full Size, 1280x853, 104.8KB -
GRUB: "Safe Mode" EFI, this will boot.
Grub loaded via the Boot menu.
- Full Size, 1280x853, 124.3KB -
GRUB: "Native" EFI, things may fail.
Boot menu has not been used.
- Full Size, 1280x853, 118.2KB -

After installation and issuing the final reboot, you should be greeted by Grub having been set as the default boot loader however you'll find that when it attempts to boot Linux it will either hang on "Trying to terminate EFI services again", it can end up on a black screen, or for a brief moment you see your system boot but then the screen still turns black.

Observe the above series of images and their brief description, then continue reading the following segment.

I can confirm this behaviour happens with:

Kernel - All kernels I've tested with. (4.4 and up)
BIOS - A04, A10, A13, A14
Grub - 2.02~beta2, 2.02~beta3, 2.02~git (20161216)

I've been informed that sporadically the system may boot correctly but this is an RNG event. In fact for the first time in a year I had it boot correctly to KMS after a warm reboot but have been unable to replicate the behaviour sofar.

All the above makes me conclude that it's not about the BIOS or the version of Grub.

EFI framebuffer vs Kernel Mode Setting

I've been suspecting for a while that the problem lies in the handoff between how the BIOS leaves the EFI configured and when KMS kicks in. Still have more figuring out to do in unknown territory but "drm.debug=0xfe" provides a wealth of information that looks fun to wander through.

I wasn't far off, the patch notes explain it best. Thanks Hans!

In layman's terms, when the i915 kernel module loads it tries to initialize the display pipe that was already active during the EFI boot process. In doing so both framebuffers cancel eachother out and the display pipe ends up stuck causing the black screen.

With the patch in place it fixes the "blank / black screen" and you no longer need to go through the boot menu or have to rely on disabling modesetting.

Hat Tip to Combeynot in the Android X86 forums.

The "Practical" Fix

This "fix" is legacy, Kernel 4.9+ does native resolution all the way.

This works by courtesy of a post on the Arch forums, discussing the most minimal possible Grub configuration.

This configuration disables any form of native resolution being set in EFI mode and starts Grub in a "safe" resolution that doesn't conflict with KMS. You still CANNOT escape the need for the BIOS "Boot Mode" Menu as a default normal POST will set a native screen resolution which breaks everything as outlined.

If your Grub menu doesn't look slightly fuzzy and fills the screen, you can see the difference up above, do a reboot and press "Volume Down" on the device or "F12" / "Arrow Down" on an attached keyboard. If you did it right you get the blue "Boot Mode" menu and you can start Grub in "Safe Mode".

Not using the "Boot Mode" Menu will result in the appearance of a giant tomato filed with love, a house made of pancakes and sudden urges to dance. Atleast for now, but I digress.

The following assumes:

Take care to remix accordingly. This config in combination with starting Grub through the "Boot Mode" menu delivers consistent working results with early KMS functioning correctly. Remember to save an extra copy of a working config in case it's overwritten by automation. 

#/boot/grub/grub.cfg

set default=0
set timeout=2

insmod efi_gop
insmod efi_uga
insmod font
terminal_output console

menuentry "Arch Linux :: Stock" {
        set root=(hd0,gpt2)
        linux   /vmlinuz-linux root=/dev/mmcblkXpY rw add_efi_memmap fbcon=rotate:1
        initrd  /intel-ucode.img /initramfs-linux.img
}

The "Manual" Fix

This "fix" is legacy, nomodeset is no longer needed on kernel 4.6+.

Get to Grub via the BIOS "Boot Mode" Menu.

Once you are in Grub edit your kernel line to disable modesetting "i915.modeset=0" as we've done before. (Optionally fbcon=rotate:1 as well for landscape mode.)

If you do not add this flag you'll be left with a blank screen when Kernel Mode Setting becomes active. In this instance the system is in fact running and you can login blindly. When in doubt hit your caps lock or num lock, if it responds you can be pretty sure you have a system ready for input.

My current theory is the the video handover from Grub in EFI mode to the kernel does not like it if Grub has initialized the framebuffer in any native like video mode. Confirmed.

The "Sorta" Fix

This "fix" is legacy too, nomodeset is longer needed on kernel 4.6+.

Fire up your favourite text editor and then make the following change: 

$editor /etc/default/grub

# In /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.modeset=0"

# Regenerate Grub config
grub-mkconfig -o /boot/grub/grub.cfg

Linux will now succesfully boot from Grub, as long as it's started via the BIOS "Boot Mode" Menu. but you'll loose out on Kernel Mode Setting which means that you won't be able to run an accelerated Xorg. FBdev works fine.

The Journey to Stability

Update: As predicted, Kernel 4.7 has now made this a footnote.

This is an overview of the various paths taken in order to get to a point where the Venue 8 Pro would actually have more then 0.5 - 1 hour of uptime under casual usage conditions with Kernel 4.4 and patching. I expect that eventually this will be nothing but a footnote. These notes may be beneficial should you have a device where you suspect power management issues may be affecting stability.

It is interesting to note that C1E support was removed from the kernel where Bay Trail is concerned.

FYI, When adjusting the various C-State and P-State options you may end up with a situation where you cannot adjust the CPU governor nor be able to (hard) control the frequency.

What follows is all the various options tried and their outcomes, more or less in order of success.

The Intel Way

intel_idle.max_cstate=2 intel_pstate=disable
Leaves CPU at 1.33Ghz, no Turbo.

Appears stable with WiFi blacklisted.

61C CPU temp recorded under moderate load.

50C CPU temp idle.

48C CPU temp idle with display off.

The Other Way

intel_pstate=disable
Leave CPU at 1.33Ghz, no Turbo.
However, Cores can enter sleep states.

Seemed promising, but still locked up.

41C CPU temp idle.

51C CPU temp under moderate load.

The following is the result of limited testing with the first couple of C-states, less then ideal results...

intel_idle.max_cstate=0, disables idle driver completely
Stable, Leaves CPU at max 1.83Ghz...

intel_idle.max_cstate=1, disables basics clocks.
Stable, Leaves CPU at max 1.83Ghz, sleeps internal CPU clocks.

intel_idle.max_cstate=2, basic frequency scaling.
Stable, Leaves CPU at 1.33Ghz baseline.
But, seems to turbo jumps to 1.83Ghz constantly.

intel_idle.max_cstate=3, full frequency scaling.
Causes MMC errors and Wifi Drop...

ToDo: Worth testing further C-states ?

acpi=off

Causes system to drop straight to emergency shell as most of the hardware cannot be detected for enumeration.

noapic

System will try to boot but eventually fails as hardware won't power up or other oddities.

nolapic

Kernel refuses to boot, optionally remains stuck on "Trying to terminate EFI services again".

Revision Log

July/2017
- Started the Archive. 

//- Rev -// v0.x // Epoch