3 * (C) COPYRIGHT 2011-2012 ARM Limited. All rights reserved.
5 * This program is free software and is provided to you under the terms of the GNU General Public License version 2
6 * as published by the Free Software Foundation, and any use by you of this program is subject to the terms of such GNU licence.
8 * A copy of the licence is included with the program, and can also be obtained from Free Software
9 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
16 * @file mali_kbase_js.h
23 #include <malisw/mali_malisw.h>
24 #include <osk/mali_osk.h>
26 #include "mali_kbase_js_defs.h"
27 #include "mali_kbase_js_policy.h"
28 #include "mali_kbase_defs.h"
30 #include "mali_kbase_js_ctx_attr.h"
33 * @addtogroup base_api
38 * @addtogroup base_kbase_api
43 * @addtogroup kbase_js Job Scheduler Internal APIs
46 * These APIs are Internal to KBase and are available for use by the
47 * @ref kbase_js_policy "Job Scheduler Policy APIs"
51 * @brief Initialize the Job Scheduler
53 * The kbasep_js_device_data sub-structure of \a kbdev must be zero
54 * initialized before passing to the kbasep_js_devdata_init() function. This is
55 * to give efficient error path code.
57 mali_error kbasep_js_devdata_init( kbase_device *kbdev );
60 * @brief Halt the Job Scheduler.
62 * It is safe to call this on \a kbdev even if it the kbasep_js_device_data
63 * sub-structure was never initialized/failed initialization, to give efficient
66 * For this to work, the kbasep_js_device_data sub-structure of \a kbdev must
67 * be zero initialized before passing to the kbasep_js_devdata_init()
68 * function. This is to give efficient error path code.
70 * It is a Programming Error to call this whilst there are still kbase_context
71 * structures registered with this scheduler.
74 void kbasep_js_devdata_halt( kbase_device * kbdev);
77 * @brief Terminate the Job Scheduler
79 * It is safe to call this on \a kbdev even if it the kbasep_js_device_data
80 * sub-structure was never initialized/failed initialization, to give efficient
83 * For this to work, the kbasep_js_device_data sub-structure of \a kbdev must
84 * be zero initialized before passing to the kbasep_js_devdata_init()
85 * function. This is to give efficient error path code.
87 * It is a Programming Error to call this whilst there are still kbase_context
88 * structures registered with this scheduler.
90 void kbasep_js_devdata_term( kbase_device *kbdev );
94 * @brief Initialize the Scheduling Component of a kbase_context on the Job Scheduler.
96 * This effectively registers a kbase_context with a Job Scheduler.
98 * It does not register any jobs owned by the kbase_context with the scheduler.
99 * Those must be separately registered by kbasep_js_add_job().
101 * The kbase_context must be zero intitialized before passing to the
102 * kbase_js_init() function. This is to give efficient error path code.
104 mali_error kbasep_js_kctx_init( kbase_context *kctx );
107 * @brief Terminate the Scheduling Component of a kbase_context on the Job Scheduler
109 * This effectively de-registers a kbase_context from its Job Scheduler
111 * It is safe to call this on a kbase_context that has never had or failed
112 * initialization of its jctx.sched_info member, to give efficient error-path
115 * For this to work, the kbase_context must be zero intitialized before passing
116 * to the kbase_js_init() function.
118 * It is a Programming Error to call this whilst there are still jobs
119 * registered with this context.
121 void kbasep_js_kctx_term( kbase_context *kctx );
124 * @brief Add a job chain to the Job Scheduler, and take necessary actions to
125 * schedule the context/run the job.
127 * This atomically does the following:
128 * - Update the numbers of jobs information (including NSS state changes)
129 * - Add the job to the run pool if necessary (part of init_job)
131 * Once this is done, then an appropriate action is taken:
132 * - If the ctx is scheduled, it attempts to start the next job (which might be
134 * - Otherwise, and if this is the first job on the context, it enqueues it on
137 * The Policy's Queue can be updated by this in the following ways:
138 * - In the above case that this is the first job on the context
139 * - If the job is high priority and the context is not scheduled, then it
140 * could cause the Policy to schedule out a low-priority context, allowing
141 * this context to be scheduled in.
143 * If the context is already scheduled on the RunPool, then adding a job to it
144 * is guarenteed not to update the Policy Queue. And so, the caller is
145 * guarenteed to not need to try scheduling a context from the Run Pool - it
146 * can safely assert that the result is MALI_FALSE.
148 * It is a programming error to have more than U32_MAX jobs in flight at a time.
150 * The following locking conditions are made on the caller:
151 * - it must \em not hold kbasep_js_kctx_info::ctx::jsctx_mutex.
152 * - it must \em not hold kbasep_js_device_data::runpool_irq::lock (as this will be
153 * obtained internally)
154 * - it must \em not hold kbasep_js_device_data::runpool_mutex (as this will be
155 * obtained internally)
156 * - it must \em not hold kbasep_jd_device_data::queue_mutex (again, it's used internally).
158 * @return MALI_TRUE indicates that the Policy Queue was updated, and so the
159 * caller will need to try scheduling a context onto the Run Pool.
160 * @return MALI_FALSE indicates that no updates were made to the Policy Queue,
161 * so no further action is required from the caller. This is \b always returned
162 * when the context is currently scheduled.
164 mali_bool kbasep_js_add_job( kbase_context *kctx, kbase_jd_atom *atom );
167 * @brief Remove a job chain from the Job Scheduler
169 * Removing a job from the Scheduler can cause an NSS/SS state transition. In
170 * this case, slots that previously could not have jobs submitted to might now
171 * be submittable to. For this reason, and NSS/SS state transition will cause
172 * the Scheduler to try to submit new jobs on the jm_slots.
174 * It is a programming error to call this when:
175 * - \a atom is not a job belonging to kctx.
176 * - \a atom has already been removed from the Job Scheduler.
177 * - \a atom is still in the runpool:
178 * - it has not been killed with kbasep_js_policy_kill_all_ctx_jobs()
179 * - or, it has not been removed with kbasep_js_policy_dequeue_job()
180 * - or, it has not been removed with kbasep_js_policy_dequeue_job_irq()
182 * The following locking conditions are made on the caller:
183 * - it must hold kbasep_js_kctx_info::ctx::jsctx_mutex.
184 * - it must \em not hold kbasep_js_device_data::runpool_irq::lock, (as this will be
185 * obtained internally)
186 * - it must \em not hold kbasep_js_device_data::runpool_mutex (as this could be
188 * - it must \em not hold kbdev->jm_slots[ \a js ].lock (as this could be
189 * obtained internally)
192 void kbasep_js_remove_job( kbase_context *kctx, kbase_jd_atom *atom );
195 * @brief Refcount a context as being busy, preventing it from being scheduled
198 * @note This function can safely be called from IRQ context.
200 * The following locking conditions are made on the caller:
201 * - it must \em not hold the kbasep_js_device_data::runpool_irq::lock, because
202 * it will be used internally.
204 * @return value != MALI_FALSE if the retain succeeded, and the context will not be scheduled out.
205 * @return MALI_FALSE if the retain failed (because the context is being/has been scheduled out).
207 mali_bool kbasep_js_runpool_retain_ctx( kbase_device *kbdev, kbase_context *kctx );
210 * @brief Refcount a context as being busy, preventing it from being scheduled
213 * @note This function can safely be called from IRQ context.
215 * The following locks must be held by the caller:
216 * - kbasep_js_device_data::runpool_irq::lock
218 * @return value != MALI_FALSE if the retain succeeded, and the context will not be scheduled out.
219 * @return MALI_FALSE if the retain failed (because the context is being/has been scheduled out).
221 mali_bool kbasep_js_runpool_retain_ctx_nolock( kbase_device *kbdev, kbase_context *kctx );
224 * @brief Lookup a context in the Run Pool based upon its current address space
225 * and ensure that is stays scheduled in.
227 * The context is refcounted as being busy to prevent it from scheduling
228 * out. It must be released with kbasep_js_runpool_release_ctx() when it is no
229 * longer required to stay scheduled in.
231 * @note This function can safely be called from IRQ context.
233 * The following locking conditions are made on the caller:
234 * - it must \em not hold the kbasep_js_device_data::runpoool_irq::lock, because
235 * it will be used internally.
237 * @return a valid kbase_context on success, which has been refcounted as being busy.
238 * @return NULL on failure, indicating that no context was found in \a as_nr
240 kbase_context* kbasep_js_runpool_lookup_ctx( kbase_device *kbdev, int as_nr );
243 * @brief Handling the requeuing/killing of a context that was evicted from the
244 * policy queue or runpool.
246 * This should be used whenever handing off a context that has been evicted
247 * from the policy queue or the runpool:
248 * - If the context is not dying and has jobs, it gets re-added to the policy
250 * - Otherwise, it is not added (but PM is informed that it is idle)
252 * In addition, if the context is dying the jobs are killed asynchronously.
254 * The following locking conditions are made on the caller:
255 * - it must hold kbasep_js_kctx_info::ctx::jsctx_mutex.
256 * - it must \em not hold kbasep_jd_device_data::queue_mutex (as this will be
257 * obtained internally)
259 void kbasep_js_runpool_requeue_or_kill_ctx( kbase_device *kbdev, kbase_context *kctx );
262 * @brief Release a refcount of a context being busy, allowing it to be
265 * When the refcount reaches zero and the context \em might be scheduled out
266 * (depending on whether the Scheudling Policy has deemed it so, or if it has run
269 * If the context does get scheduled out, then The following actions will be
270 * taken as part of deschduling a context:
271 * - For the context being descheduled:
272 * - If the context is in the processing of dying (all the jobs are being
273 * removed from it), then descheduling also kills off any jobs remaining in the
275 * - If the context is not dying, and any jobs remain after descheduling the
276 * context then it is re-enqueued to the Policy's Queue.
277 * - Otherwise, the context is still known to the scheduler, but remains absent
278 * from the Policy Queue until a job is next added to it.
279 * - Once the context is descheduled, this also handles scheduling in a new
280 * context (if one is available), and if necessary, running a job from that new
283 * Unlike retaining a context in the runpool, this function \b cannot be called
286 * It is a programming error to call this on a \a kctx that is not currently
287 * scheduled, or that already has a zero refcount.
289 * The following locking conditions are made on the caller:
290 * - it must \em not hold the kbasep_js_device_data::runpool_irq::lock, because
291 * it will be used internally.
292 * - it must \em not hold kbasep_js_kctx_info::ctx::jsctx_mutex.
293 * - it must \em not hold kbasep_js_device_data::runpool_mutex (as this will be
294 * obtained internally)
295 * - it must \em not hold the kbase_device::as[n].transaction_mutex (as this will be obtained internally)
296 * - it must \em not hold kbasep_jd_device_data::queue_mutex (as this will be
297 * obtained internally)
300 void kbasep_js_runpool_release_ctx( kbase_device *kbdev, kbase_context *kctx );
303 * @brief Try to submit the next job on a \b particular slot whilst in IRQ
304 * context, and whilst the caller already holds the job-slot IRQ spinlock.
306 * \a *submit_count will be checked against
307 * KBASE_JS_MAX_JOB_SUBMIT_PER_SLOT_PER_IRQ to see whether too many jobs have
308 * been submitted. This is to prevent the IRQ handler looping over lots of GPU
309 * NULL jobs, which may complete whilst the IRQ handler is still processing. \a
310 * submit_count itself should point to kbase_device::slot_submit_count_irq[ \a js ],
311 * which is initialized to zero on entry to the IRQ handler.
313 * The following locks must be held by the caller:
314 * - kbasep_js_device_data::runpool_irq::lock
315 * - kbdev->jm_slots[ \a js ].lock
317 * @return truthful (i.e. != MALI_FALSE) if there was space to submit in the
318 * GPU, but we couldn't get a job from the Run Pool. This may be because the
319 * Run Pool needs maintenence outside of IRQ context. Therefore, this indicates
320 * that submission should be retried from a work-queue, by using
321 * kbasep_js_try_run_next_job_on_slot().
322 * @return MALI_FALSE if submission had no problems: the GPU is either already
323 * full of jobs in the HEAD and NEXT registers, or we were able to get enough
324 * jobs from the Run Pool to fill the GPU's HEAD and NEXT registers.
326 mali_bool kbasep_js_try_run_next_job_on_slot_irq_nolock( kbase_device *kbdev, int js, s8 *submit_count );
329 * @brief Try to submit the next job on a particular slot, outside of IRQ context
331 * This obtains the Job Slot lock for the duration of the call only.
333 * Unlike kbasep_js_try_run_next_job_on_slot_irq_nolock(), there is no limit on
334 * submission, because eventually IRQ_THROTTLE will kick in to prevent us
335 * getting stuck in a loop of submitting GPU NULL jobs. This is because the IRQ
336 * handler will be delayed, and so this function will eventually fill up the
337 * space in our software 'submitted' slot (kbase_jm_slot::submitted).
339 * In addition, there's no return value - we'll run the maintenence functions
340 * on the Policy's Run Pool, but if there's nothing there after that, then the
341 * Run Pool is truely empty, and so no more action need be taken.
343 * The following locking conditions are made on the caller:
344 * - it must hold kbasep_js_device_data::runpool_mutex
345 * - it must \em not hold kbasep_js_device_data::runpool_irq::lock (as this will be
346 * obtained internally)
347 * - it must \em not hold kbdev->jm_slots[ \a js ].lock (as this will be
348 * obtained internally)
350 * @note The caller \em might be holding one of the
351 * kbasep_js_kctx_info::ctx::jsctx_mutex locks.
354 void kbasep_js_try_run_next_job_on_slot( kbase_device *kbdev, int js );
357 * @brief Try to submit the next job for each slot in the system, outside of IRQ context
359 * This will internally call kbasep_js_try_run_next_job_on_slot(), so the same
360 * locking conditions on the caller are required.
362 * The following locking conditions are made on the caller:
363 * - it must hold kbasep_js_device_data::runpool_mutex
364 * - it must \em not hold kbasep_js_device_data::runpool_irq::lock (as this will be
365 * obtained internally)
366 * - it must \em not hold kbdev->jm_slots[ \a js ].lock (as this will be
367 * obtained internally)
369 * @note The caller \em might be holding one of the
370 * kbasep_js_kctx_info::ctx::jsctx_mutex locks.
373 void kbasep_js_try_run_next_job( kbase_device *kbdev );
376 * @brief Try to schedule the next context onto the Run Pool
378 * This checks whether there's space in the Run Pool to accommodate a new
379 * context. If so, it attempts to dequeue a context from the Policy Queue, and
380 * submit this to the Run Pool.
382 * If the scheduling succeeds, then it also makes a call to
383 * kbasep_js_try_run_next_job(), in case the new context has jobs matching the
384 * job slot requirements, but no other currently scheduled context has such
387 * If any of these actions fail (Run Pool Full, Policy Queue empty, etc) then
388 * the function just returns normally.
390 * The following locking conditions are made on the caller:
391 * - it must \em not hold the kbasep_js_device_data::runpool_irq::lock, because
392 * it will be used internally.
393 * - it must \em not hold kbasep_js_device_data::runpool_mutex (as this will be
394 * obtained internally)
395 * - it must \em not hold the kbase_device::as[n].transaction_mutex (as this will be obtained internally)
396 * - it must \em not hold kbasep_jd_device_data::queue_mutex (again, it's used internally).
397 * - it must \em not hold kbasep_js_kctx_info::ctx::jsctx_mutex, because it will
398 * be used internally.
399 * - it must \em not hold kbdev->jm_slots[ \a js ].lock (as this will be
400 * obtained internally)
403 void kbasep_js_try_schedule_head_ctx( kbase_device *kbdev );
406 * @brief Schedule in a privileged context
408 * This schedules a context in regardless of the context priority.
409 * If the runpool is full, a context will be forced out of the runpool and the function will wait
410 * for the new context to be scheduled in.
411 * The context will be kept scheduled in (and the corresponding address space reserved) until
412 * kbasep_js_release_privileged_ctx is called).
414 * The following locking conditions are made on the caller:
415 * - it must \em not hold the kbasep_js_device_data::runpool_irq::lock, because
416 * it will be used internally.
417 * - it must \em not hold kbasep_js_device_data::runpool_mutex (as this will be
418 * obtained internally)
419 * - it must \em not hold the kbase_device::as[n].transaction_mutex (as this will be obtained internally)
420 * - it must \em not hold kbasep_jd_device_data::queue_mutex (again, it's used internally).
421 * - it must \em not hold kbasep_js_kctx_info::ctx::jsctx_mutex, because it will
422 * be used internally.
423 * - it must \em not hold kbdev->jm_slots[ \a js ].lock (as this will be
424 * obtained internally)
427 void kbasep_js_schedule_privileged_ctx( kbase_device *kbdev, kbase_context *kctx );
430 * @brief Release a privileged context, allowing it to be scheduled out.
432 * See kbasep_js_runpool_release_ctx for potential side effects.
434 * The following locking conditions are made on the caller:
435 * - it must \em not hold the kbasep_js_device_data::runpool_irq::lock, because
436 * it will be used internally.
437 * - it must \em not hold kbasep_js_kctx_info::ctx::jsctx_mutex.
438 * - it must \em not hold kbasep_js_device_data::runpool_mutex (as this will be
439 * obtained internally)
440 * - it must \em not hold the kbase_device::as[n].transaction_mutex (as this will be obtained internally)
443 void kbasep_js_release_privileged_ctx( kbase_device *kbdev, kbase_context *kctx );
446 * @brief Handle the Job Scheduler component for the IRQ of a job finishing
448 * This does the following:
449 * -# Releases resources held by the atom
450 * -# if \a end_timestamp != NULL, updates the runpool's notion of time spent by a running ctx
451 * -# determines whether a context should be marked for scheduling out
452 * -# if start_new_jobs is true, tries to submit the next job on the slot
453 * (picking from all ctxs in the runpool)
455 * In addition, if submission didn't happen (the submit-from-IRQ function
456 * failed or start_new_jobs == MALI_FALSE), then this sets a message on katom
457 * that submission needs to be retried from the worker thread.
459 * Normally, the time calculated from end_timestamp is rounded up to the
460 * minimum time precision. Therefore, to ensure the job is recorded as not
461 * spending any time, then set end_timestamp to NULL. For example, this is necessary when
462 * evicting jobs from JSn_HEAD_NEXT (because they didn't actually run).
464 * NOTE: It's possible to move the steps (2) and (3) (inc calculating job's time
465 * used) into the worker (outside of IRQ context), but this may allow a context
466 * to use up to twice as much timeslice as is allowed by the policy. For
467 * policies that order by time spent, this is not a problem for overall
468 * 'fairness', but can still increase latency between contexts.
470 * The following locking conditions are made on the caller:
471 * - it must \em not hold the kbasep_js_device_data::runpoool_irq::lock, because
472 * it will be used internally.
473 * - it must hold kbdev->jm_slots[ \a slot_nr ].lock
475 void kbasep_js_job_done_slot_irq( kbase_jd_atom *katom, int slot_nr, kbasep_js_tick *end_timestamp, mali_bool start_new_jobs );
478 * @brief Try to submit the next job on each slot
480 * The following locks may be used:
481 * - kbasep_js_device_data::runpool_mutex
482 * - kbasep_js_device_data::runpool_irq::lock
483 * - bdev->jm_slots[ \a js ].lock
485 void kbase_js_try_run_jobs( kbase_device *kbdev );
488 * @brief Handle releasing cores for power management and affinity management,
489 * ensuring that cores are powered down and affinity tracking is updated.
491 * This must only be called on an atom that is not currently running, and has
492 * not been re-queued onto the context (and so does not need locking)
494 * This function enters at the following @ref kbase_atom_coreref_state states:
495 * - NO_CORES_REQUESTED
496 * - WAITING_FOR_REQUESTED_CORES
500 * It transitions the above states back to NO_CORES_REQUESTED by the end of the
501 * function call (possibly via intermediate states).
503 * No locks need be held by the caller, since this takes the necessary Power
504 * Management locks itself. The runpool_irq.lock is not taken (the work that
505 * requires it is handled by kbase_js_affinity_submit_to_blocked_slots() ).
507 * @note The corresponding kbasep_js_job_check_ref_cores() is private to the
508 * Job Scheduler, and is called automatically when running the next job.
510 void kbasep_js_job_check_deref_cores(kbase_device *kbdev, struct kbase_jd_atom *katom);
517 * @brief Check that a context is allowed to submit jobs on this policy
519 * The purpose of this abstraction is to hide the underlying data size, and wrap up
520 * the long repeated line of code.
522 * As with any mali_bool, never test the return value with MALI_TRUE.
524 * The caller must hold kbasep_js_device_data::runpool_irq::lock.
526 static INLINE mali_bool kbasep_js_is_submit_allowed( kbasep_js_device_data *js_devdata, kbase_context *kctx )
530 /* Ensure context really is scheduled in */
531 OSK_ASSERT( kctx->as_nr != KBASEP_AS_NR_INVALID );
532 OSK_ASSERT( kctx->jctx.sched_info.ctx.is_scheduled != MALI_FALSE );
534 test_bit = (u16)(1u << kctx->as_nr);
536 return (mali_bool)(js_devdata->runpool_irq.submit_allowed & test_bit);
540 * @brief Allow a context to submit jobs on this policy
542 * The purpose of this abstraction is to hide the underlying data size, and wrap up
543 * the long repeated line of code.
545 * The caller must hold kbasep_js_device_data::runpool_irq::lock.
547 static INLINE void kbasep_js_set_submit_allowed( kbasep_js_device_data *js_devdata, kbase_context *kctx )
551 /* Ensure context really is scheduled in */
552 OSK_ASSERT( kctx->as_nr != KBASEP_AS_NR_INVALID );
553 OSK_ASSERT( kctx->jctx.sched_info.ctx.is_scheduled != MALI_FALSE );
555 set_bit = (u16)(1u << kctx->as_nr);
557 OSK_PRINT_INFO(OSK_BASE_JM, "JS: Setting Submit Allowed on %p (as=%d)", kctx, kctx->as_nr );
559 js_devdata->runpool_irq.submit_allowed |= set_bit;
563 * @brief Prevent a context from submitting more jobs on this policy
565 * The purpose of this abstraction is to hide the underlying data size, and wrap up
566 * the long repeated line of code.
568 * The caller must hold kbasep_js_device_data::runpool_irq::lock.
570 static INLINE void kbasep_js_clear_submit_allowed( kbasep_js_device_data *js_devdata, kbase_context *kctx )
575 /* Ensure context really is scheduled in */
576 OSK_ASSERT( kctx->as_nr != KBASEP_AS_NR_INVALID );
577 OSK_ASSERT( kctx->jctx.sched_info.ctx.is_scheduled != MALI_FALSE );
579 clear_bit = (u16)(1u << kctx->as_nr);
580 clear_mask = ~clear_bit;
582 OSK_PRINT_INFO(OSK_BASE_JM, "JS: Clearing Submit Allowed on %p (as=%d)", kctx, kctx->as_nr );
584 js_devdata->runpool_irq.submit_allowed &= clear_mask;
588 * @brief Manage the 'retry_submit_on_slot' part of a kbase_jd_atom
590 static INLINE void kbasep_js_clear_job_retry_submit( kbase_jd_atom *atom )
592 atom->retry_submit_on_slot = -1;
595 static INLINE mali_bool kbasep_js_get_job_retry_submit_slot( kbase_jd_atom *atom, int *res )
597 int js = atom->retry_submit_on_slot;
599 return (mali_bool)( js >= 0 );
602 static INLINE void kbasep_js_set_job_retry_submit_slot( kbase_jd_atom *atom, int js )
604 OSK_ASSERT( 0 <= js && js <= BASE_JM_MAX_NR_SLOTS );
606 atom->retry_submit_on_slot = js;
609 #if OSK_DISABLE_ASSERTS == 0
611 * Debug Check the refcount of a context. Only use within ASSERTs
613 * Obtains kbasep_js_device_data::runpool_irq::lock
615 * @return negative value if the context is not scheduled in
616 * @return current refcount of the context if it is scheduled in. The refcount
617 * is not guarenteed to be kept constant.
619 static INLINE int kbasep_js_debug_check_ctx_refcount( kbase_device *kbdev, kbase_context *kctx )
621 kbasep_js_device_data *js_devdata;
625 OSK_ASSERT( kbdev != NULL );
626 OSK_ASSERT( kctx != NULL );
627 js_devdata = &kbdev->js_data;
629 osk_spinlock_irq_lock( &js_devdata->runpool_irq.lock );
631 if ( as_nr != KBASEP_AS_NR_INVALID )
633 result = js_devdata->runpool_irq.per_as_data[as_nr].as_busy_refcount;
635 osk_spinlock_irq_unlock( &js_devdata->runpool_irq.lock );
639 #endif /* OSK_DISABLE_ASSERTS == 0 */
642 * @brief Variant of kbasep_js_runpool_lookup_ctx() that can be used when the
643 * context is guarenteed to be already previously retained.
645 * It is a programming error to supply the \a as_nr of a context that has not
646 * been previously retained/has a busy refcount of zero. The only exception is
647 * when there is no ctx in \a as_nr (NULL returned).
649 * The following locking conditions are made on the caller:
650 * - it must \em not hold the kbasep_js_device_data::runpoool_irq::lock, because
651 * it will be used internally.
653 * @return a valid kbase_context on success, with a refcount that is guarenteed
654 * to be non-zero and unmodified by this function.
655 * @return NULL on failure, indicating that no context was found in \a as_nr
657 static INLINE kbase_context* kbasep_js_runpool_lookup_ctx_noretain( kbase_device *kbdev, int as_nr )
659 kbasep_js_device_data *js_devdata;
660 kbase_context *found_kctx;
661 kbasep_js_per_as_data *js_per_as_data;
663 OSK_ASSERT( kbdev != NULL );
664 OSK_ASSERT( 0 <= as_nr && as_nr < BASE_MAX_NR_AS );
665 js_devdata = &kbdev->js_data;
666 js_per_as_data = &js_devdata->runpool_irq.per_as_data[as_nr];
668 osk_spinlock_irq_lock( &js_devdata->runpool_irq.lock );
670 found_kctx = js_per_as_data->kctx;
671 OSK_ASSERT( found_kctx == NULL || js_per_as_data->as_busy_refcount > 0 );
673 osk_spinlock_irq_unlock( &js_devdata->runpool_irq.lock );
680 * @note MIDBASE-769: OSK to add high resolution timer
682 static INLINE kbasep_js_tick kbasep_js_get_js_ticks( void )
684 return osk_time_now();
688 * Supports about an hour worth of time difference, allows the underlying
689 * clock to be more/less accurate than microseconds
691 * @note MIDBASE-769: OSK to add high resolution timer
693 static INLINE u32 kbasep_js_convert_js_ticks_to_us( kbasep_js_tick js_tick )
695 return (js_tick * 10000u) / osk_time_mstoticks(10u);
699 * Supports about an hour worth of time difference, allows the underlying
700 * clock to be more/less accurate than microseconds
702 * @note MIDBASE-769: OSK to add high resolution timer
704 static INLINE kbasep_js_tick kbasep_js_convert_js_us_to_ticks( u32 us )
706 return (us * (kbasep_js_tick)osk_time_mstoticks(1000u)) / 1000000u;
709 * Determine if ticka comes after tickb
711 * @note MIDBASE-769: OSK to add high resolution timer
713 static INLINE mali_bool kbasep_js_ticks_after( kbasep_js_tick ticka, kbasep_js_tick tickb )
715 kbasep_js_tick tick_diff = ticka - tickb;
716 const kbasep_js_tick wrapvalue = ((kbasep_js_tick)1u) << ((sizeof(kbasep_js_tick)*8)-1);
718 return (mali_bool)(tick_diff < wrapvalue);
722 * This will provide a conversion from time (us) to ticks of the gpu clock
723 * based on the minimum available gpu frequency.
724 * This is usually good to compute best/worst case (where the use of current
725 * frequency is not valid due to DVFS).
726 * e.g.: when you need the number of cycles to guarantee you won't wait for
727 * longer than 'us' time (you might have a shorter wait).
729 static INLINE kbasep_js_gpu_tick kbasep_js_convert_us_to_gpu_ticks_min_freq( kbase_device *kbdev, u32 us )
731 u32 gpu_freq = kbdev->gpu_props.props.core_props.gpu_freq_khz_min;
732 OSK_ASSERT( 0!= gpu_freq );
733 return (us * (gpu_freq / 1000));
737 * This will provide a conversion from time (us) to ticks of the gpu clock
738 * based on the maximum available gpu frequency.
739 * This is usually good to compute best/worst case (where the use of current
740 * frequency is not valid due to DVFS).
741 * e.g.: When you need the number of cycles to guarantee you'll wait at least
742 * 'us' amount of time (but you might wait longer).
744 static INLINE kbasep_js_gpu_tick kbasep_js_convert_us_to_gpu_ticks_max_freq( kbase_device *kbdev, u32 us )
746 u32 gpu_freq = kbdev->gpu_props.props.core_props.gpu_freq_khz_max;
747 OSK_ASSERT( 0!= gpu_freq );
748 return (us * (kbasep_js_gpu_tick)(gpu_freq / 1000));
752 * This will provide a conversion from ticks of the gpu clock to time (us)
753 * based on the minimum available gpu frequency.
754 * This is usually good to compute best/worst case (where the use of current
755 * frequency is not valid due to DVFS).
756 * e.g.: When you need to know the worst-case wait that 'ticks' cycles will
757 * take (you guarantee that you won't wait any longer than this, but it may
760 static INLINE u32 kbasep_js_convert_gpu_ticks_to_us_min_freq( kbase_device *kbdev, kbasep_js_gpu_tick ticks )
762 u32 gpu_freq = kbdev->gpu_props.props.core_props.gpu_freq_khz_min;
763 OSK_ASSERT( 0!= gpu_freq );
764 return (ticks / gpu_freq * 1000);
768 * This will provide a conversion from ticks of the gpu clock to time (us)
769 * based on the maximum available gpu frequency.
770 * This is usually good to compute best/worst case (where the use of current
771 * frequency is not valid due to DVFS).
772 * e.g.: When you need to know the best-case wait for 'tick' cycles (you
773 * guarantee to be waiting for at least this long, but it may be longer).
775 static INLINE u32 kbasep_js_convert_gpu_ticks_to_us_max_freq( kbase_device *kbdev, kbasep_js_gpu_tick ticks )
777 u32 gpu_freq = kbdev->gpu_props.props.core_props.gpu_freq_khz_max;
778 OSK_ASSERT( 0!= gpu_freq );
779 return (ticks / gpu_freq * 1000);
781 /** @} */ /* end group kbase_js */
782 /** @} */ /* end group base_kbase_api */
783 /** @} */ /* end group base_api */
785 #endif /* _KBASE_JS_H_ */