The purpose of this page is to describe how the ARM MALI driver is integrated into Xilinx

Overview

Xilinx ZynqMPSoC has the MALI 400MP GPU from ARM. The ARM MALI 400MP is an OpenGLES 2.0 capable GPU.

Driver access and license

The driver for MALI 400MP consists of Linux kernel driver and user library. The user space library is proprietary licensed and will have to be distributed as binaries. The user space library will be provided through Xilinx PetaLinux release. The Linux kernel driver is GPL licensed, and downloadable from http://malideveloper.arm.com/. Till 2016.4, the kernel driver was hosted on Xilinx github.. From 2017.1, the kernel driver hosted on Xilinx github is deprecated,. This will now be downloaded from ARM website and bundled into the PetaLinux BSP.. .

Release version

The driver is released periodically by ARM. Thus there can be multiple versions available. The default version in Kconfig points to the latest working release.

Configs

The following configs need to be enabled: CONFIG_MALI_DT=y, CONFIG_MALI_DMA_BUF_MAP_ON_ATTACH=y, CONFIG_MALI_SHARED_INTERRUPTS=y. Some additional configs such as profiling can be enabled if needed.

Device tree binding

The DT binding documentation is included in the driver release. Download the kernel driver tarball from http://malideveloper.arm.com/., unzip it and the DT binding documentation is available at the folder path.
"driver/documentation/devicetree/bindings/arm/mali-utgard.txt"

Runtime power management

The MALI driver supports fine grained runtime power management based on Linux runtime PM APIs, with its own scheduler. This section describes the flow of specific driver version, r7p0-00rel0, to give an overview.

First the driver implements the Linux runtime PM callbacks (in mali_kernel_linux.c), and the runtime pm is enabled in device initialization (arm.c)
static const struct dev_pm_ops mali_dev_pm_ops = {
#ifdef CONFIG_PM_RUNTIME
        .runtime_suspend = mali_driver_runtime_suspend,
        .runtime_resume = mali_driver_runtime_resume,
        .runtime_idle = mali_driver_runtime_idle,
#endif
        .suspend = mali_driver_suspend_scheduler,
        .resume = mali_driver_resume_scheduler,
        .freeze = mali_driver_suspend_scheduler,
        .thaw = mali_driver_resume_scheduler,
        .poweroff = mali_driver_suspend_scheduler,
};
#endif
mali_platform_device_register()
{
        ...
        pm_runtime_set_autosuspend_delay(&(mali_gpu_device.dev), 1000);
        pm_runtime_use_autosuspend(&(mali_gpu_device.dev));
#endif
        pm_runtime_enable(&(mali_gpu_device.dev));
        ...
}


Then, the driver has its own scheduler (mali_scheduler.c) that tracks any activities of all GPU processors (GP: geometry processor, PP: pixel processor). All activities on those processors are created as a job (ex, gp job / pp job) and scheduled through this scheduler. The scheduler tracks the completion of the job as well. Based on the status, the scheduler sets the runtime pm reference count accordingly (mali_scheduler.c). Below is an example for GP. Equivalent functions exist for PP.
mali_scheduler_queue_gp_job()
{
        ...
        _mali_osk_pm_dev_ref_get_async()
        ...
}
 
mali_scheduler_complete_gp_job()
{
        ...
        _mali_osk_pm_dev_ref_pet_async()
        ...
}

When the reference count reaches to 0, the runtime_suspend callback will be triggered: runtime_suspend callback -> mali_driver_runtime_suspend() -> mali_pm_runtime_suspend() -> mali_pm_common_suspend(). mali_pm_common_suspend() performs a series of operations to put all relevant modules, ex, l2 cache and mmu, in idle state. Reverse operations is performed when resuming.
mali_pm_common_suspend()
{
        ...
        if (0 < num_groups_down) {
                mali_executor_group_power_down(groups_down, num_groups_down);
                }
 
        for (i = 0; i < num_l2_down; i++) {
                mali_l2_cache_power_down(l2_down[i]);
        }
 
        ...
}
The driver level handling eventually triggers the platform level power domain management. Underlying runtime pm and genpd implementation triggers the firmware APIs at the end. It's not scope of this documentation.

Changelog


Related Links