Kernel 3.10 will be release soon, so it’s time for our regular look at what the next kernel will bring. Purely on statistics the drm-intel-next pull for 3.11  is one of the biggest pull request with 314 patches thus far. Read on after the break for the details.

The big item is surely that ValleyView (now called Baytrail) support is now solid enough that we’ve lifted the preliminary hardware support tag for it and enabled it by default. Support for this SoC platform should be fairly complete now with rc6, render turbo and all outputs (with the exception of MIPI/DSI panels all nicely working now. Most of the code is from Jesse Barnes with a bunch of patches from Ville Syrjälä and also from the Bangalore display guys.

For Haswell there’s a big effort to enable power saving features: Paulo Zanoni fixed up our watermark code and enabled the intermediate pixel storage feature. Rodrigo Vivi enabled framebuffer compression. Both changes greatly increase deep package C state residency and hence power consumption on idle systems when the display is enabled. Furthermore the audio guys around Haihao Xiang fixed up the interaction of the intel alsa driver with our driver when the manual display power well is shut down, further improving power consumption figures.

On the Haswell render side there’s finally support for the VECS engine. This engine is used by libva for some post-processing steps.

There are also some further hotplug improvements from Egbert Eich. Chris Wilson has some further ideas to cut down on needless reprobing (and so speed up boot and resume times), but I’ve decided that we should test the current changes (especially the hotplug storm detection code merged in 3.10) a bit more - hardware is simply too broken in this area to play fast&loose.

Mika Kuoppala worked a lot on our hangcheck & reset code and improved our context support to enable the GL_ARB_robustness extension. Unfortunately the new ioctl wasn’t merged for 3.11 since one of the last prep patches blew up in a bad way and so had to be dropped. But Mika also fixed our long-standing out-of-memory issues with dumping the gpu error state - finally no bug report should be blocked any more because the reporter can’t grab the error dump!

Some of the context work also prepares for real per-process gpu address space. Ben Widawsky is working on that and also submitted quite a few patches for our GTT code to prepare for this. Hopefully 3.12 will have the first cut of that code, and if Daniel Herrman’s rendernode GSOC project also lands we’d finally have much improved security between different gpu clients.

Another improvement which probably fewer people will notice is that we’ve revamped and improved our code to handle non-24bpp modes - we can finally drive DP screens at 30bpp (although there’s still work to do, as always), and also fixed up a few other corner cases. This is all part of the larger effort to reorganize our modesetting code. The big change in 3.11 though is the addition of the pipe config structure to track the per-crtc modesetting state. We now also have code to cross-check the hardware state with the software state after each modeset (similarly to how we already cross-check the output routing). This will help greatly to catch regression earlier, especially for some of the big upcoming features like fastboot or atomic modeset.

In 3.11 though we’ve just merged preparatory patches to convert as much as possible of our crtc state to the new infrastructure: Panel fitter state, pipe bpp and dithering modes, display pll sharing (and some of the dpll hw state) and the basic output mode properties are now all tracked in the pipe configuration structure. For those curious about what’s the design behind this new code framework and how it’ll work out eventually: Stay tuned to this blog, I’m working on a more in-depth coverage.

And of course there’s been tons of little fixes, improvements and code refactoring all over the place.