AMD Is Hoping To Upstream DAL For Linux 4.7, But A Lot Of Work Is Needed

Along with open-sourcing the next-gen Polaris GPU driver code yesterday, Alex Deucher of AMD laid out their plans for aiming to get the DAL display code into the Linux 4.7 kernel.

This Polaris driver code is dependent upon the massive AMDGPU DAL patches for display handling that amount to over 93 thousand lines of code (and the Polaris code is another 67 thousand lines of code). When that DAL code was sent out last month, it was quick to be critiqued by other upstream DRM driver developers.

With that Polaris support dependent upon DAL, AMD needs to get this massive patch series into the Linux 4.7 kernel. The Upstreaming DAL mailing list message covers their approach. Alex explained, "When we initially released the patches, there were some rough edges and quite a few things were pointed out that need to be fixed. Some are relatively easy to fix, others will take time. Our goal is to make those changes. We'd like to target 4.7 for upstreaming DAL. To that end, I think it would be easier to review and track our progress if I maintained a public DAL branch and send out patches against that branch rather than respinning giant squashed patches every time we fix something. It's much harder to track what progress has been made. DAL is currently at ~400 patches."

Among the changes aimed for Linux 4.7 to DAL include removing various malloc/free/sleep/delay wrappers, switching to Linux i2c, using the Linux DRM AUX interface, converting cursors to the planes API, and native DRM EDID fetching. Later on they will take care of other work.

However, as of yet, DRM subsystem maintainer David Airlie is still uneasy about this code. David responded to Alex with, "I think people are focusing on the minor comments and concerns and possibly deliberately ignoring the bigger concern that this code is base is pretty much unmergeable as-is. Cleaning this up won't be a matter of just removing some memset's, mallocs and moving on. This code needs redesign by someone with Linux kernel development experience. Alex if you have any other tasks in AMD, I suggest you apply to have them all scrapped and you take this on board."

Airlie went on to add, "So much of this code seems to be 'architected' design. I mean someone senior draws a bunch of powerpoint slides with nice blocks, with what are abstraction layers between them, then a bunch of other coders take that powerpoint slide and work on a box each until it all comes together. However the abstractions don't survive so well and you end up with a bunch of leaky boxes all co-dependent and joined together but still abstracted. So let's take a massive step back from the edge here and figure out what we expect a modesetting codebase for a driver in the Linux kernel to look like and write that...I'm actually nearly getting to the point of realising nobody actually
understands my concerns here and just trying to write a driver on my own. I'm still slightly open to some sort of STAGING for this, but I think I'm nearly at the level, that I'd only accept that on the understanding we'd try and evolve the driver to this level, rather than think we can clean DAL to the kernel standards."

We'll see what happens in the weeks ahead for this code that's needed for Polaris support. DAL supports AMDGPU hardware and provides reliable DisplayPort support, HDMI 2.0 support, DVI support, full integration with power management, Atomic KMS, proper 4K @ 60Hz support, and other display-related features for this code derived from AMD's internal code-base.