[Linaro-mm-sig] Split GEM from the rest of DRM
rob at ti.com
Thu Apr 21 18:09:57 UTC 2011
On related topic, one issue that comes up in the ARM SoC world is that
the display controller (mode setting stuff) might come from the SoC
vendor, and the 3d/2d/etc IP from various others. For example, SGX
(or mali) is used in a few places, each with different display
And, at least in our case, the driver for display controller may be
present, but sgx kernel module may not. To make things look "normal"
to userspace, I've taken the approach of writing a DRM driver that
handles the KMS stuff, and has a plug-in API that other drivers,
such as sgx, can register their own ioctl's and that sort of thing..
there are a few rough edges to sort out to make more than a single
plugin practical, but perhaps with an approach like this the vendor
could implement a platform specific DRM driver to handle the mode
setting and display bits, while ARM, IMG, etc (IP vendor) could each
use a standard plugin interface to write their own drivers to work
with the vendor provided display driver.
(although that is just quick/dirty to make it so I could work on the
On Thu, Apr 21, 2011 at 12:48 PM, Jordan Crouse <jcrouse at codeaurora.org> wrote:
> During the MM BoF at ELC, it seemed to me that one of the things that scared
> most ARM vendors away from GEM in the first place is that was perceived to be
> too closely married to the rest of DRM (especially KMS).
> I know that some might argue that isn't necessarily true and we can go back
> and forth on that point, but I think it is still valuable to ask this question:
> How feasible is it to break out the GEM portion of DRM (essentially drm_gem.c)
> and put it into its own subsystem or library component for use by a DRM or
> a non DRM component. What parts would a non DRM component be missing to use
> GEM effectively (authentication comes to mind)?
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
More information about the Linaro-mm-sig