Tom Cooksey explained in a mailing list message this morning that the Mali T6xx approach is nearly identical to how the Texas Instruments OMAP graphics are handled. They're using a kernel DRM driver to manage the display controller via kernel mode-setting, the KMS driver handles the basic buffers with GEM support, etc. The client also uses the new PRIME ioctls for exporting the GEM buffer.
For the ARM Mali T6xx Linux enablement, they are only using a DRM driver for driving the display controller while they have their own separate kernel driver for poking and handling the GPU itself. ARM though isn't being too open-source friendly in terms of a fully open stack or providing proper documentation.
With most ARM SoC vendors sharing common designs (except for Qualcomm and NVIDIA), the ARM Mali developers ended up hacking the xf86-video-omap DDX driver into a new xf86-video-armsoc driver. This new driver works with the ARM Mali. This new driver is meant to be universal (similar to xf86-video-modesetting) with the device-specific bits being in the respective DRM driver and OpenGLES/EGL library. ARM's trying to make this new driver universal for most of these ARM SoCs and they intend to make it work on some Samsung Exynos hardware and other development platforms going forward.
ARM says, "We are actively developing this driver and will be doing so in a public git repository hosted by Linaro. We will not be maintaining any private repository behind ARM's firewall or anything like that - you'll see what we see."
Originally they were looking to base this universal ARM SoC driver on the KMS-universal xf86-video-modesetting DDX driver, but in the end they ended up basing it upon the OMAP DDX driver. They are working towards 2D hardware support with the X.Org driver but initially that won't be too unified. Some of the ways they are thinking about handling the 2D operations have also been criticized already by upstream X.Org developers.
Find out more in this mailing list post or by looking through the Linaro Git repository.