1 /* 2 * Copyright (C) 2010-2017 ARM Limited. All rights reserved. 3 * 4 * This program is free software and is provided to you under the terms of the GNU General Public License version 2 5 * as published by the Free Software Foundation, and any use by you of this program is subject to the terms of such GNU licence. 6 * 7 * A copy of the licence is included with the program, and can also be obtained from Free Software 8 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. 9 */ 10 11 /** 12 * @file mali_ukk.h 13 * Defines the kernel-side interface of the user-kernel interface 14 */ 15 16 #ifndef __MALI_UKK_H__ 17 #define __MALI_UKK_H__ 18 19 #include "mali_osk.h" 20 #include "mali_uk_types.h" 21 22 #ifdef __cplusplus 23 extern "C" { 24 #endif 25 26 /** 27 * @addtogroup uddapi Unified Device Driver (UDD) APIs 28 * 29 * @{ 30 */ 31 32 /** 33 * @addtogroup u_k_api UDD User/Kernel Interface (U/K) APIs 34 * 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 54 * called. 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 ) 60 * { 61 * return mali_ukk_examplefunction( args ); 62 * } 63 * @endcode 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 66 * function calls) 67 * 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. 74 * 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 80 * typedef struct 81 * { 82 * void *ctx; 83 * u32 number_of_cores; 84 * } _mali_uk_get_gp_number_of_cores_s; 85 * @endcode 86 * 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 90 * interface. 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 98 * 99 * 100 * \b Interface \b restrictions 101 * 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 124 * implementation. 125 * 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 140 * U/K and OSK layers 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 143 * up after itself. 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. 147 * 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. 154 * 155 * @{ 156 */ 157 158 159 /** @defgroup _mali_uk_context U/K Context management 160 * 161 * These functions allow for initialisation of the user-kernel interface once per process. 162 * 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. 165 * 166 * On IOCTL systems, this is likely to be a file descriptor as a result of opening the kernel device driver. 167 * 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(). 172 * 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. 178 * 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. 185 * 186 * @{ */ 187 188 /** @brief Begin a new Mali Device Driver session 189 * 190 * This is used to obtain a per-process context handle for all future U/K calls. 191 * 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. 194 */ 195 _mali_osk_errcode_t _mali_ukk_open(void **context); 196 197 /** @brief End a Mali Device Driver session 198 * 199 * This should be called when the process no longer requires use of the Mali Device Driver. 200 * 201 * The context handle must not be used after it has been closed. 202 * 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. 205 */ 206 _mali_osk_errcode_t _mali_ukk_close(void **context); 207 208 /** @} */ /* end group _mali_uk_context */ 209 210 211 /** @addtogroup _mali_uk_core U/K Core 212 * 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 217 * 218 * @{ */ 219 220 /** @brief Waits for a job notification. 221 * 222 * Sleeps until notified or a timeout occurs. Returns information about the notification. 223 * 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. 226 */ 227 _mali_osk_errcode_t _mali_ukk_wait_for_notification(_mali_uk_wait_for_notification_s *args); 228 229 /** @brief Post a notification to the notification queue of this application. 230 * 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. 233 */ 234 _mali_osk_errcode_t _mali_ukk_post_notification(_mali_uk_post_notification_s *args); 235 236 /** @brief Verifies if the user and kernel side of this API are compatible. 237 * 238 * This function is obsolete, but kept to allow old, incompatible user space 239 * clients to robustly detect the incompatibility. 240 * 241 * @param args see _mali_uk_get_api_version_s in "mali_utgard_uk_types.h" 242 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 243 */ 244 _mali_osk_errcode_t _mali_ukk_get_api_version(_mali_uk_get_api_version_s *args); 245 246 /** @brief Verifies if the user and kernel side of this API are compatible. 247 * 248 * @param args see _mali_uk_get_api_version_v2_s in "mali_utgard_uk_types.h" 249 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 250 */ 251 _mali_osk_errcode_t _mali_ukk_get_api_version_v2(_mali_uk_get_api_version_v2_s *args); 252 253 /** @brief Get the user space settings applicable for calling process. 254 * 255 * @param args see _mali_uk_get_user_settings_s in "mali_utgard_uk_types.h" 256 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 257 */ 258 _mali_osk_errcode_t _mali_ukk_get_user_settings(_mali_uk_get_user_settings_s *args); 259 260 /** @brief Get a user space setting applicable for calling process. 261 * 262 * @param args see _mali_uk_get_user_setting_s in "mali_utgard_uk_types.h" 263 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 264 */ 265 _mali_osk_errcode_t _mali_ukk_get_user_setting(_mali_uk_get_user_setting_s *args); 266 267 /* @brief Grant or deny high priority scheduling for this session. 268 * 269 * @param args see _mali_uk_request_high_priority_s in "mali_utgard_uk_types.h" 270 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 271 */ 272 _mali_osk_errcode_t _mali_ukk_request_high_priority(_mali_uk_request_high_priority_s *args); 273 274 /** @brief Make process sleep if the pending big job in kernel >= MALI_MAX_PENDING_BIG_JOB 275 * 276 */ 277 _mali_osk_errcode_t _mali_ukk_pending_submit(_mali_uk_pending_submit_s *args); 278 279 /** @} */ /* end group _mali_uk_core */ 280 281 282 /** @addtogroup _mali_uk_memory U/K Memory 283 * 284 * The memory functions provide functionality with and without a Mali-MMU present. 285 * 286 * For Mali-MMU based systems, the following functionality is provided: 287 * - Initialize and terminate MALI virtual address space 288 * - Allocate/deallocate physical memory to a MALI virtual address range and map into/unmap from the 289 * current process address space 290 * - Map/unmap external physical memory into the MALI virtual address range 291 * 292 * For Mali-nonMMU based systems: 293 * - Allocate/deallocate MALI memory 294 * 295 * @{ */ 296 297 /** @brief Map Mali Memory into the current user process 298 * 299 * Maps Mali memory into the current user process in a generic way. 300 * 301 * This function is to be used for Mali-MMU mode. The function is available in both Mali-MMU and Mali-nonMMU modes, 302 * but should not be called by a user process in Mali-nonMMU mode. 303 * 304 * The implementation and operation of _mali_ukk_mem_mmap() is dependant on whether the driver is built for Mali-MMU 305 * or Mali-nonMMU: 306 * - In the nonMMU case, _mali_ukk_mem_mmap() requires a physical address to be specified. For this reason, an OS U/K 307 * implementation should not allow this to be called from user-space. In any case, nonMMU implementations are 308 * inherently insecure, and so the overall impact is minimal. Mali-MMU mode should be used if security is desired. 309 * - In the MMU case, _mali_ukk_mem_mmap() the _mali_uk_mem_mmap_s::phys_addr 310 * member is used for the \em Mali-virtual address desired for the mapping. The 311 * implementation of _mali_ukk_mem_mmap() will allocate both the CPU-virtual 312 * and CPU-physical addresses, and can cope with mapping a contiguous virtual 313 * address range to a sequence of non-contiguous physical pages. In this case, 314 * the CPU-physical addresses are not communicated back to the user-side, as 315 * they are unnecsessary; the \em Mali-virtual address range must be used for 316 * programming Mali structures. 317 * 318 * In the second (MMU) case, _mali_ukk_mem_mmap() handles management of 319 * CPU-virtual and CPU-physical ranges, but the \em caller must manage the 320 * \em Mali-virtual address range from the user-side. 321 * 322 * @note Mali-virtual address ranges are entirely separate between processes. 323 * It is not possible for a process to accidentally corrupt another process' 324 * \em Mali-virtual address space. 325 * 326 * @param args see _mali_uk_mem_mmap_s in "mali_utgard_uk_types.h" 327 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 328 */ 329 _mali_osk_errcode_t _mali_ukk_mem_mmap(_mali_uk_mem_mmap_s *args); 330 331 /** @brief Unmap Mali Memory from the current user process 332 * 333 * Unmaps Mali memory from the current user process in a generic way. This only operates on Mali memory supplied 334 * from _mali_ukk_mem_mmap(). 335 * 336 * @param args see _mali_uk_mem_munmap_s in "mali_utgard_uk_types.h" 337 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 338 */ 339 _mali_osk_errcode_t _mali_ukk_mem_munmap(_mali_uk_mem_munmap_s *args); 340 341 /** @brief Determine the buffer size necessary for an MMU page table dump. 342 * @param args see _mali_uk_query_mmu_page_table_dump_size_s in mali_utgard_uk_types.h 343 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 344 */ 345 _mali_osk_errcode_t _mali_ukk_query_mmu_page_table_dump_size(_mali_uk_query_mmu_page_table_dump_size_s *args); 346 /** @brief Dump MMU Page tables. 347 * @param args see _mali_uk_dump_mmu_page_table_s in mali_utgard_uk_types.h 348 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 349 */ 350 _mali_osk_errcode_t _mali_ukk_dump_mmu_page_table(_mali_uk_dump_mmu_page_table_s *args); 351 352 /** @brief Write user data to specified Mali memory without causing segfaults. 353 * @param args see _mali_uk_mem_write_safe_s in mali_utgard_uk_types.h 354 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 355 */ 356 _mali_osk_errcode_t _mali_ukk_mem_write_safe(_mali_uk_mem_write_safe_s *args); 357 358 /** @} */ /* end group _mali_uk_memory */ 359 360 361 /** @addtogroup _mali_uk_pp U/K Fragment Processor 362 * 363 * The Fragment Processor (aka PP (Pixel Processor)) functions provide the following functionality: 364 * - retrieving version of the fragment processors 365 * - determine number of fragment processors 366 * - starting a job on a fragment processor 367 * 368 * @{ */ 369 370 /** @brief Issue a request to start a new job on a Fragment Processor. 371 * 372 * If the request fails args->status is set to _MALI_UK_START_JOB_NOT_STARTED_DO_REQUEUE and you can 373 * try to start the job again. 374 * 375 * An existing job could be returned for requeueing if the new job has a higher priority than a previously started job 376 * which the hardware hasn't actually started processing yet. In this case the new job will be started instead and the 377 * existing one returned, otherwise the new job is started and the status field args->status is set to 378 * _MALI_UK_START_JOB_STARTED. 379 * 380 * Job completion can be awaited with _mali_ukk_wait_for_notification(). 381 * 382 * @param ctx user-kernel context (mali_session) 383 * @param uargs see _mali_uk_pp_start_job_s in "mali_utgard_uk_types.h". Use _mali_osk_copy_from_user to retrieve data! 384 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 385 */ 386 _mali_osk_errcode_t _mali_ukk_pp_start_job(void *ctx, _mali_uk_pp_start_job_s *uargs); 387 388 /** 389 * @brief Issue a request to start new jobs on both Vertex Processor and Fragment Processor. 390 * 391 * @note Will call into @ref _mali_ukk_pp_start_job and @ref _mali_ukk_gp_start_job. 392 * 393 * @param ctx user-kernel context (mali_session) 394 * @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! 395 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 396 */ 397 _mali_osk_errcode_t _mali_ukk_pp_and_gp_start_job(void *ctx, _mali_uk_pp_and_gp_start_job_s *uargs); 398 399 /** @brief Returns the number of Fragment Processors in the system 400 * 401 * @param args see _mali_uk_get_pp_number_of_cores_s in "mali_utgard_uk_types.h" 402 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 403 */ 404 _mali_osk_errcode_t _mali_ukk_get_pp_number_of_cores(_mali_uk_get_pp_number_of_cores_s *args); 405 406 /** @brief Returns the version that all Fragment Processor cores are compatible with. 407 * 408 * This function may only be called when _mali_ukk_get_pp_number_of_cores() indicated at least one Fragment 409 * Processor core is available. 410 * 411 * @param args see _mali_uk_get_pp_core_version_s in "mali_utgard_uk_types.h" 412 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 413 */ 414 _mali_osk_errcode_t _mali_ukk_get_pp_core_version(_mali_uk_get_pp_core_version_s *args); 415 416 /** @brief Disable Write-back unit(s) on specified job 417 * 418 * @param args see _mali_uk_get_pp_core_version_s in "mali_utgard_uk_types.h" 419 */ 420 void _mali_ukk_pp_job_disable_wb(_mali_uk_pp_disable_wb_s *args); 421 422 423 /** @} */ /* end group _mali_uk_pp */ 424 425 426 /** @addtogroup _mali_uk_gp U/K Vertex Processor 427 * 428 * The Vertex Processor (aka GP (Geometry Processor)) functions provide the following functionality: 429 * - retrieving version of the Vertex Processors 430 * - determine number of Vertex Processors available 431 * - starting a job on a Vertex Processor 432 * 433 * @{ */ 434 435 /** @brief Issue a request to start a new job on a Vertex Processor. 436 * 437 * If the request fails args->status is set to _MALI_UK_START_JOB_NOT_STARTED_DO_REQUEUE and you can 438 * try to start the job again. 439 * 440 * An existing job could be returned for requeueing if the new job has a higher priority than a previously started job 441 * which the hardware hasn't actually started processing yet. In this case the new job will be started and the 442 * existing one returned, otherwise the new job is started and the status field args->status is set to 443 * _MALI_UK_START_JOB_STARTED. 444 * 445 * Job completion can be awaited with _mali_ukk_wait_for_notification(). 446 * 447 * @param ctx user-kernel context (mali_session) 448 * @param uargs see _mali_uk_gp_start_job_s in "mali_utgard_uk_types.h". Use _mali_osk_copy_from_user to retrieve data! 449 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 450 */ 451 _mali_osk_errcode_t _mali_ukk_gp_start_job(void *ctx, _mali_uk_gp_start_job_s *uargs); 452 453 /** @brief Returns the number of Vertex Processors in the system. 454 * 455 * @param args see _mali_uk_get_gp_number_of_cores_s in "mali_utgard_uk_types.h" 456 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 457 */ 458 _mali_osk_errcode_t _mali_ukk_get_gp_number_of_cores(_mali_uk_get_gp_number_of_cores_s *args); 459 460 /** @brief Returns the version that all Vertex Processor cores are compatible with. 461 * 462 * This function may only be called when _mali_uk_get_gp_number_of_cores() indicated at least one Vertex 463 * Processor core is available. 464 * 465 * @param args see _mali_uk_get_gp_core_version_s in "mali_utgard_uk_types.h" 466 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 467 */ 468 _mali_osk_errcode_t _mali_ukk_get_gp_core_version(_mali_uk_get_gp_core_version_s *args); 469 470 /** @brief Resume or abort suspended Vertex Processor jobs. 471 * 472 * After receiving notification that a Vertex Processor job was suspended from 473 * _mali_ukk_wait_for_notification() you can use this function to resume or abort the job. 474 * 475 * @param args see _mali_uk_gp_suspend_response_s in "mali_utgard_uk_types.h" 476 * @return _MALI_OSK_ERR_OK on success, otherwise a suitable _mali_osk_errcode_t on failure. 477 */ 478 _mali_osk_errcode_t _mali_ukk_gp_suspend_response(_mali_uk_gp_suspend_response_s *args); 479 480 /** @} */ /* end group _mali_uk_gp */ 481 482 #if defined(CONFIG_MALI400_PROFILING) 483 /** @addtogroup _mali_uk_profiling U/K Timeline profiling module 484 * @{ */ 485 486 /** @brief Add event to profiling buffer. 487 * 488 * @param args see _mali_uk_profiling_add_event_s in "mali_utgard_uk_types.h" 489 */ 490 _mali_osk_errcode_t _mali_ukk_profiling_add_event(_mali_uk_profiling_add_event_s *args); 491 492 /** @brief Get profiling stream fd. 493 * 494 * @param args see _mali_uk_profiling_stream_fd_get_s in "mali_utgard_uk_types.h" 495 */ 496 _mali_osk_errcode_t _mali_ukk_profiling_stream_fd_get(_mali_uk_profiling_stream_fd_get_s *args); 497 498 /** @brief Profiling control set. 499 * 500 * @param args see _mali_uk_profiling_control_set_s in "mali_utgard_uk_types.h" 501 */ 502 _mali_osk_errcode_t _mali_ukk_profiling_control_set(_mali_uk_profiling_control_set_s *args); 503 504 /** @} */ /* end group _mali_uk_profiling */ 505 #endif 506 507 /** @addtogroup _mali_uk_vsync U/K VSYNC reporting module 508 * @{ */ 509 510 /** @brief Report events related to vsync. 511 * 512 * @note Events should be reported when starting to wait for vsync and when the 513 * waiting is finished. This information can then be used in kernel space to 514 * complement the GPU utilization metric. 515 * 516 * @param args see _mali_uk_vsync_event_report_s in "mali_utgard_uk_types.h" 517 */ 518 _mali_osk_errcode_t _mali_ukk_vsync_event_report(_mali_uk_vsync_event_report_s *args); 519 520 /** @} */ /* end group _mali_uk_vsync */ 521 522 /** @addtogroup _mali_sw_counters_report U/K Software counter reporting 523 * @{ */ 524 525 /** @brief Report software counters. 526 * 527 * @param args see _mali_uk_sw_counters_report_s in "mali_uk_types.h" 528 */ 529 _mali_osk_errcode_t _mali_ukk_sw_counters_report(_mali_uk_sw_counters_report_s *args); 530 531 /** @} */ /* end group _mali_sw_counters_report */ 532 533 /** @} */ /* end group u_k_api */ 534 535 /** @} */ /* end group uddapi */ 536 537 u32 _mali_ukk_report_memory_usage(void); 538 539 u32 _mali_ukk_report_total_memory_size(void); 540 541 u32 _mali_ukk_utilization_gp_pp(void); 542 543 u32 _mali_ukk_utilization_gp(void); 544 545 u32 _mali_ukk_utilization_pp(void); 546 547 #ifdef __cplusplus 548 } 549 #endif 550 551 #endif /* __MALI_UKK_H__ */ 552