OMAP, Radeon, Valley View Linux DRM Updates
First of all, libdrm 2.4.33 was released today (announcement). What makes this DRM library update noteworthy is that it integrates OMAP support and adds Trinity surface support on the Radeon DRM side. AMD published the open-source Trinity code (alongside the Radeon HD 7000 series DRM code) last week. The enablement code for the upcoming AMD Fusion "Trinity" APUs wasn't too bad -- compared to GCN / Southern Islands -- since it's based upon an existing GPU, but the support is available. The R600 Mesa Gallium3D driver was also updated to handle AMD Trinity.
With today's libdrm update, there is now released support in the DRM library for Trinity. This support though isn't too exciting, it's just dropping in seven PCI IDs for the "ARUBA" graphics. The PCI IDs are 0x9900, 0x9901, 0x9903, 0x9904, 0x990F, 0x9990, and 0x9991.
The libdrm 2.4.33 release also has in the initial PCI IDs for Intel's 2013 platform, Haswell. Intel began publishing open-source Haswell graphics code earlier this month for Mesa and the DRM driver. Within libdrm they have added in the PCI IDs for the GT1/GT2 desktop parts (0x0402 and 0x0412), two mobile GT1/GT2 (0x0406 and 0x0416), and mobile ULT GT2 (0x0A16). The Haswell graphics are being identified as an Intel "Gen7" part, like Ivy Bridge. The first Haswell hardware isn't expected until the first half of 2013 while by the end of April there should be the first shipping Ivy Bridge processors.
What's more exciting about libdrm 2.4.33 than sprinkling in some new PCI IDs is that the OMAP support has finally landed. Rob Clark of Texas Instruments is the one that's been working on the OMAP DRM/KMS driver for this ARM-based Texas Instruments platform, with the open-source DRM driver being merged into staging for Linux 3.3. Texas Instruments also has an xf86-video-omap DDX driver that relies upon the OMAP DRM and there's also an omapdrmtest user-space testing utility, etc.
OMAP for libdrm in this version is a ~550 line libdrm_omap helper implementation for these user-space OMAP interfaces. Unfortunately there is no open-source 3D user-space for Texas Instruments' OMAP platform at this time. This is the first ARM-based DRM driver to have mainline libdrm support. One of the popular OMAP4460 platforms is the dual-core PandaBoard ES.
Aside from the libdrm, within the kernel DRM side there's also exciting developments.
Published today were updated Intel Valley View patches. Last week I exclusively broke the news about Valleyview as a next-generation Atom SoC with Ivy Bridge graphics rather than the graphics core being derived from Imagination PowerVR SGX IP. This is huge news, but for Linux users it's especially great since it means mainline open-source Intel Linux graphics support rather than dealing with a number of binary blobs. Intel Valleyview Atom chips won't be out until probably the end of 2012 or early 2013, but the open-source support for the Ivy Bridge-derived graphics is already materializing.
On the mailing list are updated patches for the Valley View DRM support to address comments by the other graphics driver developers over the past week. Expect more news in this space soon.
On a related note for those Intel Atom users stuck with current PowerVR-based graphics (e.g. Poulsbo, Moorestown, etc) there's some potential good news. Last November I mentioned the state of the open-source GMA500/Poulsbo DRM driver that's still basic and lacks 2D/3D acceleration support, but Intel's Alan Cox mentioned at that point that video acceleration might be possible on open-source.
There's enough code already out there concerning the Intel PowerVR with the DRM driver and then the VA-API driver found in MeeGo/Tizen and now in a separate Git repository, that the DRM driver might be able to be worked up to handle video acceleration. Nothing solid has been done in this area yet, but Alan Cox mentioned today on the kernel mailing list, "The one for the 3D/2D non-free user space driver. I've been working on Cedartrail primarily at the moment so not had time to dig further into the video playback logic. I did get the decoder detected and mapped happily but haven't yet had time to persuade the firmware to upload. It'll also need the driver extending to support the overlay planes feature in the DRI/DRM layer."
Lastly, Alex Deucher of AMD published some new register definitions today for HDMI/DisplayPort audio for the Radeon DRM driver. See this mailing list post. DCE2 was introduced on the R600 series (Radeon HD 2000), DCE3 was on the RV620/RV635/RS780/RS880 (Radeon HD 3000 series), DCE3.1 for the RV770, DCE3.2 for the RV710/730/740, DCE4 for the Radeon HD 5000 series, and DCE5 is the Radeon HD 6000 series. (The new Radeon HD 7000 series is on DCE6.)
This patch simply drops in all of these new defines for the Radeon HD 2000/3000/4000/5000/6000 series audio, but no actual code implementation. Since last year open-source Radeon users were waiting for Evergreen-era HDMI audio support, but the code was tied up in legal/technical review at AMD. In the meantime, the HDMI audio support was reverse-engineered with basic support in place and the code was already merged to mainline. It looks like AMD's more extensive audio code is finally clearing the review process and making it out several months later.
4 Comments
