Intel's Medfield Still A Botched Binary Mess Under Linux?

While the next-generation Ivy Bridge hardware may not be shown off this week at CES2012 (in public that is, in private that's a different story), what Intel and their partners will be promoting heavily this week in Las Vegas is their "Medfield" platform. But how well supported under Linux is this next-generation Intel mobile platform? Are there going to be more binary blobs coming out for Linux?

Medfield is Intel's fourth-generation MID platform that succeeds the two-year-old Moorestown. Medfield is a 32nm Atom SoC and is set to go head-to-head with the latest ARM hardware that's been dominating the smart-phone and tablet markets up to this point. Intel Medfield is said to be quite power efficient while its performance is also slated to surpass the latest ARM-based NVIDIA Tegra 3 platform.

With Medfield being aimed at tablets and smart-phones, Intel is obviously ensuring Android support is in place. It's been said already that there's initial Intel Medfield support within Google's Android 4.0 "Ice Cream Sandwich" release, but how well will this next-generation mobile platform work out for other upstream Linux distributions? After all Android isn't running the latest upstream Linux kernel, but instead is a few releases behind Torvald's tree at present plus with many out-of-tree patches. (Read: a real effort to mainline Android changes in the Linux kernel.)

Had Intel not been so quick to abandon MeeGo for the fucked-up Tizen vaporware, this situation could have potentially played out differently. At least then they would still be pumping out quarterly releases and using the latest upstream Linux kernel in a far more open manner than working with Google on Android support. I also haven't heard any talk of Intel engaging with Canonical over any specialized Medfield support in Ubuntu, but then again if Intel was really committed to Linux as they have so frequently expressed (and shouting open-source drivers work), they would have all of the code upstream and need not worrying about any out-of-tree dealings.

I first mentioned Intel Medfield Linux support gets going back in November of 2010 when a number of patches for this next-generation SoC began hitting the Linux kernel. These patches have long been merged and within the mainline kernel tree for a few release cycles. The support has added basic Medfield support, a new thermal driver, and other basic hardware enablement. These non-graphics-related patches for mobile platforms though isn't anything special or a surprise since all of the major vendors in this space have taken upstream Linux support seriously -- even NVIDIA.

Just a few months ago, Intel published a MSIC (Mixed Signal IC) chip driver for Medfield and patches to enable EHCI USB host function support under Linux. For proper Medfield Linux support, it's best to use the latest available kernel -- with Linux 3.2 it looks like the support should be in good shape barring any issues with the production hardware. There's also a few Medfield-related commits to be found in Linux 3.3, which is the next kernel that just entered development and will not be released for about two months and will miss Ubuntu 12.04 LTS.

Last summer I then mentioned base Medfield graphics support coming to the mainline Linux kernel. However, this Intel Medfield graphics support was added to the Intel GMA500 "Poulsbo" DRM driver, which was merged and moved out of staging in the brand-new Linux 3.2 kernel. The problem is that it's built on the open-source Poulsbo driver... Besides the hardware being notorious, this mainline Poulsbo DRM driver is the one that's stripped-down and not really useful for consumers who just care about features and not under what terms the driver is licensed.

Even for the original Intel Poulsbo hardware, the support from this driver is still crap and it will be that way for Ubuntu 12.04 LTS "Precise Pangolin". There isn't any 3D acceleration, no video acceleration (though Alan Cox has said it might be possible to add by an interesting individual), and there isn't much in the way of power management or other advanced features by modern graphics standards. The driver is just good for lighting up your outputs and pumping basic 2D if you're running some non-composited Linux desktop.

It's really a messed up situation... Perhaps it's time to turn Poulsbo-like hardware into bottle openers too?

If you're hoping to use this open-source DRM driver for anything useful on a mobile phone or tablet, guess again. It's not there yet and Intel hasn't expressed plans for such in the future -- it goes back to being blamed on Imagination Technologies and Intel licensing the closed-up PowerVR SGX intellectual property. The binary situation was such a mess though they couldn't even ship their own driver in their own OS (one of the Poulsbo drivers in MeeGo).

So the open-source Medfield Linux graphics support at this time comes down to the psb-gfx DRM/KMS driver, which really isn't useful and can't be taken seriously by mainstream consumers. This DRM/KMS driver is largely just the work of one Intel developer, Alan Cox. The level of this driver isn't anything special even for the embedded space. In the ARM space, Texas Instruments has an open-source DRM/KMS driver with an adjoining DDX driver. Samsung also has an open-source Exynos driver that's already mainline and is still being worked on by developers. There's also something else targeting other hardware coming very soon.

With this driver you then have the fbdev X.Org driver to use as the DDX and obviously with no 3D acceleration bits in the open-source kernel driver, there is no Mesa/Gallium3D driver for this hardware. Intel has invested in bringing Mesa/Galliu3D support to Android, but that's been for supporting their main open-source driver that handles Sandy Bridge & co. There are no indications at this time there's any magical open-source drop that's forthcoming for Medfield graphics.

When Medfield is shipping, Intel will likely be offering some binary-only driver just as they had done for Poulsbo (actually, they had several different binary only drivers in the completely messed-up situation). Again, the binary-only state is likely to be blamed on third-party IP restrictions. Hopefully though the binary Medfield graphics driver will be fit and work much better along with being readily available. Most owners of Medfield hardware in their tablets/phones running Android really won't care whether the GPU support is closed or open-source, as long as it works well and supports the advertised features.

In terms of Linux video encode/decode acceleration with Medfield hardware, to the Git repositories of libva and vaapi/pvr-driver (the existing PowerVR VA-API driver for IMG VXD/VXE video engines) there have not been any explicit Medfield-related commits for exposing VA-API video acceleration support.

What will be interesting with Medfield in part is that it incorporates built-in Silicon Hive image processing. Silicon Hive is the Dutch video-processing company that Intel acquired last year to ramp-up in this area. While Intel owns Silicon Hive and its IP portfolio, I haven't yet seen any open-source patches for enabling any Silicon-Hive-related processing under Linux. Medfield marks the premiere of Silicon Hive for Intel.

The upstream Linux situation for Intel Medfield should be a lot more clear once there's hardware to play with (or maybe when Intel feels like finally providing an official briefing to me), so stay tuned. It will be interesting to see what happens in the area of graphics and what other binary blobs may enter the Linux garden. It's going on four years since Intel launched Menlow with the PowerVR-based Poulsbo graphics, but the mobile graphics situation is still a mess and it looks like Intel will be building upon this tradition unless they have some major surprise in the near future -- either provide a capable open-source driver or a single and *reliable* binary graphics driver for this next-gen Atom hardware.

At least on the desktop side, Sandy Bridge graphics are now great and Ivy Bridge will hopefully be nice.