About a month ago, I received a new ARM dev board, a IFC6410! Which despite the boring sounding name is quite an impressive bit of kit. About $150, quad-core krait, 2G DDR, SATA, gigabit ethernet.. and adreno a320. It is basically the same SoC that is in the nexus4 (or the new nexus7). But in more convenient form factor for development.
And with this board that I've been developing a new msm drm/kms driver. For a while now, freedreno has been limping along with the msm fbdev and kgsl drivers from their android kernel tree, while I focused on the userspace gallium driver and ddx (xf86-video-freedreno). But that was always a short-term solution.. with the qcom android drivers, I can't really handle synchronization between processes, which gets really crazy w/ x11 and compositing window manager where you have sharing in both directions (as texture and/or render target), I can't handle page flipping (let alone page flipping synchronized with the GPU), and have general robustness issues.
Unfortunately, the msm android fbdev driver code is a real mess (at least the mdp4 parts). Even by android / vendor kernel standards, which are pretty low to begin with. And I don't have any docs on the display controller. In the end, I ended up instrumenting the code to trace all the register reads/writes, etc, wrote a small parser tool using envytools/librnn, and starting writing rnndb register database for the display controller registers. It was a lot easier to get a general picture of how the hardware works that way! Plus I can generate register level headers from rnndb in the same way I do for the gallium driver.
So, earlier in the month, I sent first round of RFC patches, with just basic KMS support. A couple weeks ago I send the 2nd round which added a3xx gpu support and basic kmscube working. Since then I've fixed a few things, added HW cursor support and more gpu debugfs bits to help when things go wrong. And added kms support in xf86-video-freedreno. And so 3rd (and hopefully final-RFC round) of patches will go out soon. But now, time for some eye candy:
gnome-shell running on freedreno + msm drm/kms:
and, now that we have drm/kms support, we can use wayland/weston drm compositor:
so, as gnome-shell as-a wayland compositor work progresses, freedreno should be in good shape for the next generation of linux desktop :-)
-----
NOTE: If you look on the msm-drm branches in libdrm and xf86-video-freedreno trees, you'll notice that I've structured things to work on either current android drivers (with a couple small patches), or on msm drm/kms driver. This is mainly because it is unlikely that I'll be able to support every random lcd panel on every snapdragon phone/tablet that someone might want to try out freedreno on. Time permitting, I'll eventually add support for the LCD panels on devices I have (HP touchpad, nexus4), and support for some of the older generation adreno gpus.. although patches certainly welcome ;-)
And with this board that I've been developing a new msm drm/kms driver. For a while now, freedreno has been limping along with the msm fbdev and kgsl drivers from their android kernel tree, while I focused on the userspace gallium driver and ddx (xf86-video-freedreno). But that was always a short-term solution.. with the qcom android drivers, I can't really handle synchronization between processes, which gets really crazy w/ x11 and compositing window manager where you have sharing in both directions (as texture and/or render target), I can't handle page flipping (let alone page flipping synchronized with the GPU), and have general robustness issues.
Unfortunately, the msm android fbdev driver code is a real mess (at least the mdp4 parts). Even by android / vendor kernel standards, which are pretty low to begin with. And I don't have any docs on the display controller. In the end, I ended up instrumenting the code to trace all the register reads/writes, etc, wrote a small parser tool using envytools/librnn, and starting writing rnndb register database for the display controller registers. It was a lot easier to get a general picture of how the hardware works that way! Plus I can generate register level headers from rnndb in the same way I do for the gallium driver.
So, earlier in the month, I sent first round of RFC patches, with just basic KMS support. A couple weeks ago I send the 2nd round which added a3xx gpu support and basic kmscube working. Since then I've fixed a few things, added HW cursor support and more gpu debugfs bits to help when things go wrong. And added kms support in xf86-video-freedreno. And so 3rd (and hopefully final-RFC round) of patches will go out soon. But now, time for some eye candy:
gnome-shell running on freedreno + msm drm/kms:
and, now that we have drm/kms support, we can use wayland/weston drm compositor:
so, as gnome-shell as-a wayland compositor work progresses, freedreno should be in good shape for the next generation of linux desktop :-)
-----
NOTE: If you look on the msm-drm branches in libdrm and xf86-video-freedreno trees, you'll notice that I've structured things to work on either current android drivers (with a couple small patches), or on msm drm/kms driver. This is mainly because it is unlikely that I'll be able to support every random lcd panel on every snapdragon phone/tablet that someone might want to try out freedreno on. Time permitting, I'll eventually add support for the LCD panels on devices I have (HP touchpad, nexus4), and support for some of the older generation adreno gpus.. although patches certainly welcome ;-)