Integrating and building
---------------------------
4.1 Integrating UMP with your display driver
It is required that you support the "GET_UMP_SECURE_ID" ioctl for your display
driver. This ioctl has to return a UMP secure ID for your framebuffer memory.
Such an integration typically consists of two major parts
- Mapping and UnMapping of physical blocks of memory
- Returning UMP Secure ID from within ioctl handler
A typical example of mapping the framebuffer memory would look like this:
ump_dd_handle ump_wrapped_buffer;
ump_dd_physical_block ump_memory_description;
ump_memory_description.addr = fix->smem_start;
ump_memory_description.size = buffer_size;
ump_wrapped_buffer = ump_dd_handle_create_from_phys_blocks(
&ump_memory_description, 1);
A typical example of retrieving the secure ID from this memory look like this:
u32 __user *psecureid = (u32 __user *) arg;
ump_secure_id secure_id;
secure_id = ump_dd_secure_id_get( ump_wrapped_buffer );
return put_user( (unsigned int)secure_id, psecureid );
4.2 Integrating EXA with your 2D hardware
The EXA module provides hooks for accelerating various 2D operations. Please
refer to the EXA documentation for further information regarding this.
The provided "xf86-video-mali" driver contains an EXA module which has been
integrated with the UMP system. Your 2D driver may therefore require an
integration with UMP as well. The suggestion is to pass the secure ID down to
the kernel device driver for your hardware, but it is also possible to get the
CPU-mapped address for the memory by calling ump_mapped_pointer_get.
Please refer to UMP documentation for more information regarding this.
4.3 Building the Mali DDK for X.Org
The client API libraries can be built to support X.Org by including
"linux-x11-ump" in the variant string. An example of such a variant string can
be VARIANT="mali400-gles20-gles11-linux-x11-ump"
You will also have to edit driver/Makefile_x11.mak to reflect your system. A
complete development setup for X Window System is required, including
development header files and precompiled libraries.
The process of building the Mali DDK, including client API libraries and device
drivers are otherwise the same as building for regular Linux.
Copy your libraries into the system library folder, typically /usr/lib or
/usr/local/lib. Make sure that file permissions allows read and execute.
4.4 Building the X Display Driver
As for the Mali DDK, the X Display Driver "xf86-video-mali" requires an existing
development setup for the X Windowing System for your architecture.
Modify the GET_UMP_SECURE_ID ioctl define in mali_exa.h to reflect your
integration with the display driver.
Also modify the build.sh script inside the X Display Driver package to reflect your
current include paths and library folders for X Window System.
The build.sh shell script performs the following steps:
1. make distclean
2. runs configure script to generate makefile(s)
3. runs make
The display driver can be found in xf86-video-mali-0.0.1/src/.lib/mali_drv.so.
Copy this driver into your X Server display driver path, typically
/usr/lib/xorg/modules/drivers
Make sure that the file has the correct permissions.
A reference xorg.conf file can be found under xf86-video-mali-0.0.1/xorg.conf.
Make sure that you are using "mali" as the Driver under the "Device" section.
Supported options under "Device" section for Mali are:
> fbdev Select which framebuffer device to use. Defalt: /dev/fb0
> DRI2 Enable DRI2 or not. Default: false
> DRI2_PAGE_FLIP Enable flipping for fullscreen gles apps. Default: false
> DRI2_WAIT_VSYNC Enable vsync for fullscreen gles apps. Default: false
4.5 Building the Mali DRM
The Mali DRM can be plugged into the drivers/gpu/drm folder of your kernel. It
is compatible with the latest 2.6.36 kernel where PCI and AGP bus requirements
were removed in favor of supporting a generic platform device.
Please refer to the to Mali DRM README.txt for more information on
including the Mali DRM as a platform device.