2 * This confidential and proprietary software may be used only as
3 * authorised by a licensing agreement from ARM Limited
4 * (C) COPYRIGHT 2008-2013 ARM Limited
6 * The entire notice above must be reproduced on all authorised
7 * copies and copies may only be made to the extent permitted
8 * by a licensing agreement from ARM Limited.
13 * Defines the kernel-side interface of the user-kernel interface
16 #ifndef __MALI_UKK_H__
17 #define __MALI_UKK_H__
20 #include "mali_uk_types.h"
27 * @addtogroup uddapi Unified Device Driver (UDD) APIs
33 * @addtogroup u_k_api UDD User/Kernel Interface (U/K) APIs
35 * - The _mali_uk functions are an abstraction of the interface to the device
36 * driver. On certain OSs, this would be implemented via the IOCTL interface.
37 * On other OSs, it could be via extension of some Device Driver Class, or
38 * direct function call for Bare metal/RTOSs.
39 * - It is important to note that:
40 * - The Device Driver has implemented the _mali_ukk set of functions
41 * - The Base Driver calls the corresponding set of _mali_uku functions.
42 * - What requires porting is solely the calling mechanism from User-side to
43 * Kernel-side, and propagating back the results.
44 * - Each U/K function is associated with a (group, number) pair from
45 * \ref _mali_uk_functions to make it possible for a common function in the
46 * Base Driver and Device Driver to route User/Kernel calls from/to the
47 * correct _mali_uk function. For example, in an IOCTL system, the IOCTL number
48 * would be formed based on the group and number assigned to the _mali_uk
49 * function, as listed in \ref _mali_uk_functions. On the user-side, each
50 * _mali_uku function would just make an IOCTL with the IOCTL-code being an
51 * encoded form of the (group, number) pair. On the kernel-side, the Device
52 * Driver's IOCTL handler decodes the IOCTL-code back into a (group, number)
53 * pair, and uses this to determine which corresponding _mali_ukk should be
55 * - Refer to \ref _mali_uk_functions for more information about this
56 * (group, number) pairing.
57 * - In a system where there is no distinction between user and kernel-side,
58 * the U/K interface may be implemented as:@code
59 * MALI_STATIC_INLINE _mali_osk_errcode_t _mali_uku_examplefunction( _mali_uk_examplefunction_s *args )
61 * return mali_ukk_examplefunction( args );
64 * - Therefore, all U/K calls behave \em as \em though they were direct
65 * function calls (but the \b implementation \em need \em not be a direct
68 * @note Naming the _mali_uk functions the same on both User and Kernel sides
69 * on non-RTOS systems causes debugging issues when setting breakpoints. In
70 * this case, it is not clear which function the breakpoint is put on.
71 * Therefore the _mali_uk functions in user space are prefixed with \c _mali_uku
72 * and in kernel space with \c _mali_ukk. The naming for the argument
73 * structures is unaffected.
75 * - The _mali_uk functions are synchronous.
76 * - Arguments to the _mali_uk functions are passed in a structure. The only
77 * parameter passed to the _mali_uk functions is a pointer to this structure.
78 * This first member of this structure, ctx, is a pointer to a context returned
79 * by _mali_uku_open(). For example:@code
83 * u32 number_of_cores;
84 * } _mali_uk_get_gp_number_of_cores_s;
87 * - Each _mali_uk function has its own argument structure named after the
88 * function. The argument is distinguished by the _s suffix.
89 * - The argument types are defined by the base driver and user-kernel
91 * - All _mali_uk functions return a standard \ref _mali_osk_errcode_t.
92 * - Only arguments of type input or input/output need be initialized before
93 * calling a _mali_uk function.
94 * - Arguments of type output and input/output are only valid when the
95 * _mali_uk function returns \ref _MALI_OSK_ERR_OK.
96 * - The \c ctx member is always invalid after it has been used by a
97 * _mali_uk function, except for the context management functions
100 * \b Interface \b restrictions
102 * The requirements of the interface mean that an implementation of the
103 * User-kernel interface may do no 'real' work. For example, the following are
104 * illegal in the User-kernel implementation:
105 * - Calling functions necessary for operation on all systems, which would
106 * not otherwise get called on RTOS systems.
107 * - For example, a U/K interface that calls multiple _mali_ukk functions
108 * during one particular U/K call. This could not be achieved by the same code
109 * which uses direct function calls for the U/K interface.
110 * - Writing in values to the args members, when otherwise these members would
111 * not hold a useful value for a direct function call U/K interface.
112 * - For example, U/K interface implementation that take NULL members in
113 * their arguments structure from the user side, but those members are
114 * replaced with non-NULL values in the kernel-side of the U/K interface
115 * implementation. A scratch area for writing data is one such example. In this
116 * case, a direct function call U/K interface would segfault, because no code
117 * would be present to replace the NULL pointer with a meaningful pointer.
118 * - Note that we discourage the case where the U/K implementation changes
119 * a NULL argument member to non-NULL, and then the Device Driver code (outside
120 * of the U/K layer) re-checks this member for NULL, and corrects it when
121 * necessary. Whilst such code works even on direct function call U/K
122 * intefaces, it reduces the testing coverage of the Device Driver code. This
123 * is because we have no way of testing the NULL == value path on an OS
126 * A number of allowable examples exist where U/K interfaces do 'real' work:
127 * - The 'pointer switching' technique for \ref _mali_ukk_get_system_info
128 * - In this case, without the pointer switching on direct function call
129 * U/K interface, the Device Driver code still sees the same thing: a pointer
130 * to which it can write memory. This is because such a system has no
131 * distinction between a user and kernel pointer.
132 * - Writing an OS-specific value into the ukk_private member for
133 * _mali_ukk_mem_mmap().
134 * - In this case, this value is passed around by Device Driver code, but
135 * its actual value is never checked. Device Driver code simply passes it from
136 * the U/K layer to the OSK layer, where it can be acted upon. In this case,
137 * \em some OS implementations of the U/K (_mali_ukk_mem_mmap()) and OSK
138 * (_mali_osk_mem_mapregion_init()) functions will collaborate on the
139 * meaning of ukk_private member. On other OSs, it may be unused by both
141 * - Therefore, on error inside the U/K interface implementation itself,
142 * it will be as though the _mali_ukk function itself had failed, and cleaned
144 * - Compare this to a direct function call U/K implementation, where all
145 * error cleanup is handled by the _mali_ukk function itself. The direct
146 * function call U/K interface implementation is automatically atomic.
148 * The last example highlights a consequence of all U/K interface
149 * implementations: they must be atomic with respect to the Device Driver code.
150 * And therefore, should Device Driver code succeed but the U/K implementation
151 * fail afterwards (but before return to user-space), then the U/K
152 * implementation must cause appropriate cleanup actions to preserve the
153 * atomicity of the interface.
159 /** @defgroup _mali_uk_context U/K Context management
161 * These functions allow for initialisation of the user-kernel interface once per process.
163 * Generally the context will store the OS specific object to communicate with the kernel device driver and further
164 * state information required by the specific implementation. The context is shareable among all threads in the caller process.
166 * On IOCTL systems, this is likely to be a file descriptor as a result of opening the kernel device driver.
168 * On a bare-metal/RTOS system with no distinction between kernel and
169 * user-space, the U/K interface simply calls the _mali_ukk variant of the
170 * function by direct function call. In this case, the context returned is the
171 * mali_session_data from _mali_ukk_open().
173 * The kernel side implementations of the U/K interface expect the first member of the argument structure to
174 * be the context created by _mali_uku_open(). On some OS implementations, the meaning of this context
175 * will be different between user-side and kernel-side. In which case, the kernel-side will need to replace this context
176 * with the kernel-side equivalent, because user-side will not have access to kernel-side data. The context parameter
177 * in the argument structure therefore has to be of type input/output.
179 * It should be noted that the caller cannot reuse the \c ctx member of U/K
180 * argument structure after a U/K call, because it may be overwritten. Instead,
181 * the context handle must always be stored elsewhere, and copied into
182 * the appropriate U/K argument structure for each user-side call to
183 * the U/K interface. This is not usually a problem, since U/K argument
184 * structures are usually placed on the stack.
188 /** @brief Begin a new Mali Device Driver session
190 * This is used to obtain a per-process context handle for all future U/K calls.
192 * @param context pointer to storage to return a (void*)context handle.
193 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
195 _mali_osk_errcode_t _mali_ukk_open( void **context );
197 /** @brief End a Mali Device Driver session
199 * This should be called when the process no longer requires use of the Mali Device Driver.
201 * The context handle must not be used after it has been closed.
203 * @param context pointer to a stored (void*)context handle.
204 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
206 _mali_osk_errcode_t _mali_ukk_close( void **context );
208 /** @} */ /* end group _mali_uk_context */
211 /** @addtogroup _mali_uk_core U/K Core
213 * The core functions provide the following functionality:
214 * - verify that the user and kernel API are compatible
215 * - retrieve information about the cores and memory banks in the system
216 * - wait for the result of jobs started on a core
220 /** @brief Waits for a job notification.
222 * Sleeps until notified or a timeout occurs. Returns information about the notification.
224 * @param args see _mali_uk_wait_for_notification_s in "mali_utgard_uk_types.h"
225 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
227 _mali_osk_errcode_t _mali_ukk_wait_for_notification( _mali_uk_wait_for_notification_s *args );
229 /** @brief Post a notification to the notification queue of this application.
231 * @param args see _mali_uk_post_notification_s in "mali_utgard_uk_types.h"
232 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
234 _mali_osk_errcode_t _mali_ukk_post_notification( _mali_uk_post_notification_s *args );
236 /** @brief Verifies if the user and kernel side of this API are compatible.
238 * @param args see _mali_uk_get_api_version_s in "mali_utgard_uk_types.h"
239 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
241 _mali_osk_errcode_t _mali_ukk_get_api_version( _mali_uk_get_api_version_s *args );
243 /** @brief Get the user space settings applicable for calling process.
245 * @param args see _mali_uk_get_user_settings_s in "mali_utgard_uk_types.h"
246 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
248 _mali_osk_errcode_t _mali_ukk_get_user_settings(_mali_uk_get_user_settings_s *args);
250 /** @brief Get a user space setting applicable for calling process.
252 * @param args see _mali_uk_get_user_setting_s in "mali_utgard_uk_types.h"
253 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
255 _mali_osk_errcode_t _mali_ukk_get_user_setting(_mali_uk_get_user_setting_s *args);
257 /* @brief Grant or deny high priority scheduling for this session.
259 * @param args see _mali_uk_request_high_priority_s in "mali_utgard_uk_types.h"
260 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
262 _mali_osk_errcode_t _mali_ukk_request_high_priority(_mali_uk_request_high_priority_s *args);
264 /** @} */ /* end group _mali_uk_core */
267 /** @addtogroup _mali_uk_memory U/K Memory
269 * The memory functions provide functionality with and without a Mali-MMU present.
271 * For Mali-MMU based systems, the following functionality is provided:
272 * - Initialize and terminate MALI virtual address space
273 * - Allocate/deallocate physical memory to a MALI virtual address range and map into/unmap from the
274 * current process address space
275 * - Map/unmap external physical memory into the MALI virtual address range
277 * For Mali-nonMMU based systems:
278 * - Allocate/deallocate MALI memory
282 /** @brief Map Mali Memory into the current user process
284 * Maps Mali memory into the current user process in a generic way.
286 * This function is to be used for Mali-MMU mode. The function is available in both Mali-MMU and Mali-nonMMU modes,
287 * but should not be called by a user process in Mali-nonMMU mode.
289 * The implementation and operation of _mali_ukk_mem_mmap() is dependant on whether the driver is built for Mali-MMU
291 * - In the nonMMU case, _mali_ukk_mem_mmap() requires a physical address to be specified. For this reason, an OS U/K
292 * implementation should not allow this to be called from user-space. In any case, nonMMU implementations are
293 * inherently insecure, and so the overall impact is minimal. Mali-MMU mode should be used if security is desired.
294 * - In the MMU case, _mali_ukk_mem_mmap() the _mali_uk_mem_mmap_s::phys_addr
295 * member is used for the \em Mali-virtual address desired for the mapping. The
296 * implementation of _mali_ukk_mem_mmap() will allocate both the CPU-virtual
297 * and CPU-physical addresses, and can cope with mapping a contiguous virtual
298 * address range to a sequence of non-contiguous physical pages. In this case,
299 * the CPU-physical addresses are not communicated back to the user-side, as
300 * they are unnecsessary; the \em Mali-virtual address range must be used for
301 * programming Mali structures.
303 * In the second (MMU) case, _mali_ukk_mem_mmap() handles management of
304 * CPU-virtual and CPU-physical ranges, but the \em caller must manage the
305 * \em Mali-virtual address range from the user-side.
307 * @note Mali-virtual address ranges are entirely separate between processes.
308 * It is not possible for a process to accidentally corrupt another process'
309 * \em Mali-virtual address space.
311 * @param args see _mali_uk_mem_mmap_s in "mali_utgard_uk_types.h"
312 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
314 _mali_osk_errcode_t _mali_ukk_mem_mmap( _mali_uk_mem_mmap_s *args );
316 /** @brief Unmap Mali Memory from the current user process
318 * Unmaps Mali memory from the current user process in a generic way. This only operates on Mali memory supplied
319 * from _mali_ukk_mem_mmap().
321 * @param args see _mali_uk_mem_munmap_s in "mali_utgard_uk_types.h"
322 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
324 _mali_osk_errcode_t _mali_ukk_mem_munmap( _mali_uk_mem_munmap_s *args );
326 /** @brief Determine the buffer size necessary for an MMU page table dump.
327 * @param args see _mali_uk_query_mmu_page_table_dump_size_s in mali_utgard_uk_types.h
328 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
330 _mali_osk_errcode_t _mali_ukk_query_mmu_page_table_dump_size( _mali_uk_query_mmu_page_table_dump_size_s *args );
331 /** @brief Dump MMU Page tables.
332 * @param args see _mali_uk_dump_mmu_page_table_s in mali_utgard_uk_types.h
333 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
335 _mali_osk_errcode_t _mali_ukk_dump_mmu_page_table( _mali_uk_dump_mmu_page_table_s * args );
337 /** @brief Write user data to specified Mali memory without causing segfaults.
338 * @param args see _mali_uk_mem_write_safe_s in mali_utgard_uk_types.h
339 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
341 _mali_osk_errcode_t _mali_ukk_mem_write_safe( _mali_uk_mem_write_safe_s *args );
343 /** @brief Map a physically contiguous range of memory into Mali
344 * @param args see _mali_uk_map_external_mem_s in mali_utgard_uk_types.h
345 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
347 _mali_osk_errcode_t _mali_ukk_map_external_mem( _mali_uk_map_external_mem_s *args );
349 /** @brief Unmap a physically contiguous range of memory from Mali
350 * @param args see _mali_uk_unmap_external_mem_s in mali_utgard_uk_types.h
351 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
353 _mali_osk_errcode_t _mali_ukk_unmap_external_mem( _mali_uk_unmap_external_mem_s *args );
355 #if defined(CONFIG_MALI400_UMP)
356 /** @brief Map UMP memory into Mali
357 * @param args see _mali_uk_attach_ump_mem_s in mali_utgard_uk_types.h
358 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
360 _mali_osk_errcode_t _mali_ukk_attach_ump_mem( _mali_uk_attach_ump_mem_s *args );
361 /** @brief Unmap UMP memory from Mali
362 * @param args see _mali_uk_release_ump_mem_s in mali_utgard_uk_types.h
363 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
365 _mali_osk_errcode_t _mali_ukk_release_ump_mem( _mali_uk_release_ump_mem_s *args );
366 #endif /* CONFIG_MALI400_UMP */
368 /** @brief Determine virtual-to-physical mapping of a contiguous memory range
371 * This allows the user-side to do a virtual-to-physical address translation.
372 * In conjunction with _mali_uku_map_external_mem, this can be used to do
375 * This function will only succeed on a virtual range that is mapped into the
376 * current process, and that is contigious.
378 * If va is not page-aligned, then it is rounded down to the next page
379 * boundary. The remainer is added to size, such that ((u32)va)+size before
380 * rounding is equal to ((u32)va)+size after rounding. The rounded modified
381 * va and size will be written out into args on success.
383 * If the supplied size is zero, or not a multiple of the system's PAGE_SIZE,
384 * then size will be rounded up to the next multiple of PAGE_SIZE before
385 * translation occurs. The rounded up size will be written out into args on
388 * On most OSs, virtual-to-physical address translation is a priveledged
389 * function. Therefore, the implementer must validate the range supplied, to
390 * ensure they are not providing arbitrary virtual-to-physical address
391 * translations. While it is unlikely such a mechanism could be used to
392 * compromise the security of a system on its own, it is possible it could be
393 * combined with another small security risk to cause a much larger security
396 * @note This is an optional part of the interface, and is only used by certain
397 * implementations of libEGL. If the platform layer in your libEGL
398 * implementation does not require Virtual-to-Physical address translation,
399 * then this function need not be implemented. A stub implementation should not
400 * be required either, as it would only be removed by the compiler's dead code
403 * @note if implemented, this function is entirely platform-dependant, and does
404 * not exist in common code.
406 * @param args see _mali_uk_va_to_mali_pa_s in "mali_utgard_uk_types.h"
407 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
409 _mali_osk_errcode_t _mali_ukk_va_to_mali_pa( _mali_uk_va_to_mali_pa_s * args );
411 /** @} */ /* end group _mali_uk_memory */
414 /** @addtogroup _mali_uk_pp U/K Fragment Processor
416 * The Fragment Processor (aka PP (Pixel Processor)) functions provide the following functionality:
417 * - retrieving version of the fragment processors
418 * - determine number of fragment processors
419 * - starting a job on a fragment processor
423 /** @brief Issue a request to start a new job on a Fragment Processor.
425 * If the request fails args->status is set to _MALI_UK_START_JOB_NOT_STARTED_DO_REQUEUE and you can
426 * try to start the job again.
428 * An existing job could be returned for requeueing if the new job has a higher priority than a previously started job
429 * which the hardware hasn't actually started processing yet. In this case the new job will be started instead and the
430 * existing one returned, otherwise the new job is started and the status field args->status is set to
431 * _MALI_UK_START_JOB_STARTED.
433 * Job completion can be awaited with _mali_ukk_wait_for_notification().
435 * @param ctx user-kernel context (mali_session)
436 * @param uargs see _mali_uk_pp_start_job_s in "mali_utgard_uk_types.h". Use _mali_osk_copy_from_user to retrieve data!
437 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
439 _mali_osk_errcode_t _mali_ukk_pp_start_job( void *ctx, _mali_uk_pp_start_job_s *uargs );
442 * @brief Issue a request to start new jobs on both Vertex Processor and Fragment Processor.
444 * @note Will call into @ref _mali_ukk_pp_start_job and @ref _mali_ukk_gp_start_job.
446 * @param ctx user-kernel context (mali_session)
447 * @param uargs see _mali_uk_pp_and_gp_start_job_s in "mali_utgard_uk_types.h". Use _mali_osk_copy_from_user to retrieve data!
448 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
450 _mali_osk_errcode_t _mali_ukk_pp_and_gp_start_job( void *ctx, _mali_uk_pp_and_gp_start_job_s *uargs );
452 /** @brief Returns the number of Fragment Processors in the system
454 * @param args see _mali_uk_get_pp_number_of_cores_s in "mali_utgard_uk_types.h"
455 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
457 _mali_osk_errcode_t _mali_ukk_get_pp_number_of_cores( _mali_uk_get_pp_number_of_cores_s *args );
459 /** @brief Returns the version that all Fragment Processor cores are compatible with.
461 * This function may only be called when _mali_ukk_get_pp_number_of_cores() indicated at least one Fragment
462 * Processor core is available.
464 * @param args see _mali_uk_get_pp_core_version_s in "mali_utgard_uk_types.h"
465 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
467 _mali_osk_errcode_t _mali_ukk_get_pp_core_version( _mali_uk_get_pp_core_version_s *args );
469 /** @brief Disable Write-back unit(s) on specified job
471 * @param args see _mali_uk_get_pp_core_version_s in "mali_utgard_uk_types.h"
473 void _mali_ukk_pp_job_disable_wb(_mali_uk_pp_disable_wb_s *args);
476 /** @} */ /* end group _mali_uk_pp */
479 /** @addtogroup _mali_uk_gp U/K Vertex Processor
481 * The Vertex Processor (aka GP (Geometry Processor)) functions provide the following functionality:
482 * - retrieving version of the Vertex Processors
483 * - determine number of Vertex Processors available
484 * - starting a job on a Vertex Processor
488 /** @brief Issue a request to start a new job on a Vertex Processor.
490 * If the request fails args->status is set to _MALI_UK_START_JOB_NOT_STARTED_DO_REQUEUE and you can
491 * try to start the job again.
493 * An existing job could be returned for requeueing if the new job has a higher priority than a previously started job
494 * which the hardware hasn't actually started processing yet. In this case the new job will be started and the
495 * existing one returned, otherwise the new job is started and the status field args->status is set to
496 * _MALI_UK_START_JOB_STARTED.
498 * Job completion can be awaited with _mali_ukk_wait_for_notification().
500 * @param ctx user-kernel context (mali_session)
501 * @param uargs see _mali_uk_gp_start_job_s in "mali_utgard_uk_types.h". Use _mali_osk_copy_from_user to retrieve data!
502 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
504 _mali_osk_errcode_t _mali_ukk_gp_start_job( void *ctx, _mali_uk_gp_start_job_s *uargs );
506 /** @brief Returns the number of Vertex Processors in the system.
508 * @param args see _mali_uk_get_gp_number_of_cores_s in "mali_utgard_uk_types.h"
509 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
511 _mali_osk_errcode_t _mali_ukk_get_gp_number_of_cores( _mali_uk_get_gp_number_of_cores_s *args );
513 /** @brief Returns the version that all Vertex Processor cores are compatible with.
515 * This function may only be called when _mali_uk_get_gp_number_of_cores() indicated at least one Vertex
516 * Processor core is available.
518 * @param args see _mali_uk_get_gp_core_version_s in "mali_utgard_uk_types.h"
519 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
521 _mali_osk_errcode_t _mali_ukk_get_gp_core_version( _mali_uk_get_gp_core_version_s *args );
523 /** @brief Resume or abort suspended Vertex Processor jobs.
525 * After receiving notification that a Vertex Processor job was suspended from
526 * _mali_ukk_wait_for_notification() you can use this function to resume or abort the job.
528 * @param args see _mali_uk_gp_suspend_response_s in "mali_utgard_uk_types.h"
529 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure.
531 _mali_osk_errcode_t _mali_ukk_gp_suspend_response( _mali_uk_gp_suspend_response_s *args );
533 /** @} */ /* end group _mali_uk_gp */
535 #if defined(CONFIG_MALI400_PROFILING)
536 /** @addtogroup _mali_uk_profiling U/K Timeline profiling module
539 /** @brief Start recording profiling events.
541 * @param args see _mali_uk_profiling_start_s in "mali_utgard_uk_types.h"
543 _mali_osk_errcode_t _mali_ukk_profiling_start(_mali_uk_profiling_start_s *args);
545 /** @brief Add event to profiling buffer.
547 * @param args see _mali_uk_profiling_add_event_s in "mali_utgard_uk_types.h"
549 _mali_osk_errcode_t _mali_ukk_profiling_add_event(_mali_uk_profiling_add_event_s *args);
551 /** @brief Stop recording profiling events.
553 * @param args see _mali_uk_profiling_stop_s in "mali_utgard_uk_types.h"
555 _mali_osk_errcode_t _mali_ukk_profiling_stop(_mali_uk_profiling_stop_s *args);
557 /** @brief Retrieve a recorded profiling event.
559 * @param args see _mali_uk_profiling_get_event_s in "mali_utgard_uk_types.h"
561 _mali_osk_errcode_t _mali_ukk_profiling_get_event(_mali_uk_profiling_get_event_s *args);
563 /** @brief Clear recorded profiling events.
565 * @param args see _mali_uk_profiling_clear_s in "mali_utgard_uk_types.h"
567 _mali_osk_errcode_t _mali_ukk_profiling_clear(_mali_uk_profiling_clear_s *args);
569 /** @} */ /* end group _mali_uk_profiling */
572 /** @addtogroup _mali_uk_vsync U/K VSYNC reporting module
575 /** @brief Report events related to vsync.
577 * @note Events should be reported when starting to wait for vsync and when the
578 * waiting is finished. This information can then be used in kernel space to
579 * complement the GPU utilization metric.
581 * @param args see _mali_uk_vsync_event_report_s in "mali_utgard_uk_types.h"
583 _mali_osk_errcode_t _mali_ukk_vsync_event_report(_mali_uk_vsync_event_report_s *args);
585 /** @} */ /* end group _mali_uk_vsync */
587 /** @addtogroup _mali_sw_counters_report U/K Software counter reporting
590 /** @brief Report software counters.
592 * @param args see _mali_uk_sw_counters_report_s in "mali_uk_types.h"
594 _mali_osk_errcode_t _mali_ukk_sw_counters_report(_mali_uk_sw_counters_report_s *args);
596 /** @} */ /* end group _mali_sw_counters_report */
598 /** @} */ /* end group u_k_api */
600 /** @} */ /* end group uddapi */
602 u32 _mali_ukk_report_memory_usage(void);
604 u32 _mali_ukk_utilization_gp_pp(void);
606 u32 _mali_ukk_utilization_gp(void);
608 u32 _mali_ukk_utilization_pp(void);
614 #endif /* __MALI_UKK_H__ */