A Slew Of Patches For The Intel "GMA500" Driver

At the beginning of the month I mentioned Intel's Alan Cox was working on GMA500 driver improvements, namely to add support for the next-generation Intel Atom processors that will carry PowerVR-derived graphics capabilities, similar to the notorious "Poulsbo" hardware. In the past week, Alan has now published more than 50 patches against the open-source "GMA500" driver that provides basic KMS support for the Intel hardware with graphics IP originating from Imagination Technologies.

A patch series of 49 patches (here on the Linux kernel mailing list) add support for Intel's Cedarview hardware and also modularizes the GMA500 driver. Cedarview isn't being released until the fourth quarter of this year, but will be Intel's new high-performing Atom as part of the Cedar Trail nettop/netbook platform. These patches offer initial kernel mode-setting support for Cedarview. but in an un-accelerated manner.

Intel hasn't been able to provide 2D/3D/video accelerated open-source Linux support for PowerVR-based hardware due to IP restrictions from Imagination Technologies. However, it appears something is coming up and that PowerVR may have their own Linux play later in the year. There's also a high-priority Free Software Foundation-approved reverse-engineering effort for PowerVR SGX hardware, but so far it's been unsuccessful. Alan Cox also has some "crazy ideas" about using the GTT to do 2D console acceleration, but that won't do any good in the X land.

For the Cedarview upbringing, there's also basic HDMI support in the GMA500 driver. One of the HDMI support limitations is that right now there isn't any HDMI audio support with this driver, but Alan Cox is working on fixing that and for Intel Oaktrail (Atom Z760/GMA600) too.

The GMA500 driver modularization comes as Alan feels that the Poulsbo and Cedarview code can be moved out of staging and into the mainline DRM tree, but the MID platforms still need additional cleaning-up work.

Aside from that set of 49 patches, Alan has also sent another set of 12 patches (LKML message) with more driver cleaning work.

Last but not least, yesterday were another four patches (LKML message) to further clean up the driver and get all of the non-Medfield code cleaned up and ready for mainline inclusion, hopefully in the Linux 3.1 kernel. The Intel Medfield support in this driver is still in a state of churn.

Now if Intel can only manage to provide some level of open-source acceleration support for this hardware...