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 controllers.
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[1] 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.
BR, -R
[1] https://github.com/robclark/kernel-omap4/commit/4ddca26866350c4442aa2b8c5ccd... (although that is just quick/dirty to make it so I could work on the mode-setting parts)
On Thu, Apr 21, 2011 at 12:48 PM, Jordan Crouse jcrouse@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)?
Jordan
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig