linux/drivers/accel/ivpu/vpu_jsm_api.h

/* SPDX-License-Identifier: MIT */
/*
 * Copyright (c) 2020-2024, Intel Corporation.
 */

/**
 * @file
 * @brief JSM shared definitions
 *
 * @ingroup Jsm
 * @brief JSM shared definitions
 * @{
 */
#ifndef VPU_JSM_API_H
#define VPU_JSM_API_H

/*
 * Major version changes that break backward compatibility
 */
#define VPU_JSM_API_VER_MAJOR

/*
 * Minor version changes when API backward compatibility is preserved.
 */
#define VPU_JSM_API_VER_MINOR

/*
 * API header changed (field names, documentation, formatting) but API itself has not been changed
 */
#define VPU_JSM_API_VER_PATCH

/*
 * Index in the API version table
 */
#define VPU_JSM_API_VER_INDEX

/*
 * Number of Priority Bands for Hardware Scheduling
 * Bands: RealTime, Focus, Normal, Idle
 */
#define VPU_HWS_NUM_PRIORITY_BANDS

/* Max number of impacted contexts that can be dealt with the engine reset command */
#define VPU_MAX_ENGINE_RESET_IMPACTED_CONTEXTS

/*
 * Pack the API structures to enforce binary compatibility
 * Align to 8 bytes for optimal performance
 */
#pragma pack(push, 8)

/*
 * Engine indexes.
 */
#define VPU_ENGINE_COMPUTE
#define VPU_ENGINE_COPY
#define VPU_ENGINE_NB

/*
 * VPU status values.
 */
#define VPU_JSM_STATUS_SUCCESS
#define VPU_JSM_STATUS_PARSING_ERR
#define VPU_JSM_STATUS_PROCESSING_ERR
#define VPU_JSM_STATUS_PREEMPTED
#define VPU_JSM_STATUS_ABORTED
#define VPU_JSM_STATUS_USER_CTX_VIOL_ERR
#define VPU_JSM_STATUS_GLOBAL_CTX_VIOL_ERR
#define VPU_JSM_STATUS_MVNCI_WRONG_INPUT_FORMAT
#define VPU_JSM_STATUS_MVNCI_UNSUPPORTED_NETWORK_ELEMENT
#define VPU_JSM_STATUS_MVNCI_INVALID_HANDLE
#define VPU_JSM_STATUS_MVNCI_OUT_OF_RESOURCES
#define VPU_JSM_STATUS_MVNCI_NOT_IMPLEMENTED
#define VPU_JSM_STATUS_MVNCI_INTERNAL_ERROR
/* Job status returned when the job was preempted mid-inference */
#define VPU_JSM_STATUS_PREEMPTED_MID_INFERENCE

/*
 * Host <-> VPU IPC channels.
 * ASYNC commands use a high priority channel, other messages use low-priority ones.
 */
#define VPU_IPC_CHAN_ASYNC_CMD
#define VPU_IPC_CHAN_GEN_CMD
#define VPU_IPC_CHAN_JOB_RET

/*
 * Job flags bit masks.
 */
#define VPU_JOB_FLAGS_NULL_SUBMISSION_MASK
#define VPU_JOB_FLAGS_PRIVATE_DATA_MASK

/*
 * Sizes of the reserved areas in jobs, in bytes.
 */
#define VPU_JOB_RESERVED_BYTES

/*
 * Sizes of the reserved areas in job queues, in bytes.
 */
#define VPU_JOB_QUEUE_RESERVED_BYTES

/*
 * Max length (including trailing NULL char) of trace entity name (e.g., the
 * name of a logging destination or a loggable HW component).
 */
#define VPU_TRACE_ENTITY_NAME_MAX_LEN

/*
 * Max length (including trailing NULL char) of a dyndbg command.
 *
 * NOTE: 96 is used so that the size of 'struct vpu_ipc_msg' in the JSM API is
 * 128 bytes (multiple of 64 bytes, the cache line size).
 */
#define VPU_DYNDBG_CMD_MAX_LEN

/*
 * For HWS command queue scheduling, we can prioritise command queues inside the
 * same process with a relative in-process priority. Valid values for relative
 * priority are given below - max and min.
 */
#define VPU_HWS_COMMAND_QUEUE_MAX_IN_PROCESS_PRIORITY
#define VPU_HWS_COMMAND_QUEUE_MIN_IN_PROCESS_PRIORITY

/*
 * For HWS priority scheduling, we can have multiple realtime priority bands.
 * They are numbered 0 to a MAX.
 */
#define VPU_HWS_MAX_REALTIME_PRIORITY_LEVEL

/*
 * vpu_jsm_engine_reset_context flag definitions
 */
#define VPU_ENGINE_RESET_CONTEXT_FLAG_COLLATERAL_DAMAGE_MASK
#define VPU_ENGINE_RESET_CONTEXT_HANG_PRIMARY_CAUSE
#define VPU_ENGINE_RESET_CONTEXT_COLLATERAL_DAMAGE

/*
 * Invalid command queue handle identifier. Applies to cmdq_id and cmdq_group
 * in this API.
 */
#define VPU_HWS_INVALID_CMDQ_HANDLE

/*
 * Job format.
 */
struct vpu_job_queue_entry {};

/*
 * Job queue control registers.
 */
struct vpu_job_queue_header {};

/*
 * Job queue format.
 */
struct vpu_job_queue {};

/**
 * Logging entity types.
 *
 * This enum defines the different types of entities involved in logging.
 */
enum vpu_trace_entity_type {};

/*
 * HWS specific log buffer header details.
 * Total size is 32 bytes.
 */
struct vpu_hws_log_buffer_header {};

/*
 * HWS specific log buffer entry details.
 * Total size is 32 bytes.
 */
struct vpu_hws_log_buffer_entry {};

/*
 * Host <-> VPU IPC messages types.
 */
enum vpu_ipc_msg_type {};

enum vpu_ipc_msg_status {};

/*
 * Host <-> LRT IPC message payload definitions
 */
struct vpu_ipc_msg_payload_engine_reset {};

struct vpu_ipc_msg_payload_engine_preempt {};

/*
 * @brief Register doorbell command structure.
 * This structure supports doorbell registration for only OS scheduling.
 * @see VPU_JSM_MSG_REGISTER_DB
 */
struct vpu_ipc_msg_payload_register_db {};

/**
 * @brief Unregister doorbell command structure.
 * Request structure to unregister a doorbell for both HW and OS scheduling.
 * @see VPU_JSM_MSG_UNREGISTER_DB
 */
struct vpu_ipc_msg_payload_unregister_db {};

struct vpu_ipc_msg_payload_query_engine_hb {};

struct vpu_ipc_msg_payload_power_level {};

struct vpu_ipc_msg_payload_ssid_release {};

/**
 * @brief Metric streamer start command structure.
 * This structure is also used with VPU_JSM_MSG_METRIC_STREAMER_INFO to request metric
 * groups and metric counters description from the firmware.
 * @see VPU_JSM_MSG_METRIC_STREAMER_START
 * @see VPU_JSM_MSG_METRIC_STREAMER_INFO
 */
struct vpu_jsm_metric_streamer_start {};

/**
 * @brief Metric streamer stop command structure.
 * @see VPU_JSM_MSG_METRIC_STREAMER_STOP
 */
struct vpu_jsm_metric_streamer_stop {};

/**
 * Provide VPU FW with buffers to write metric data.
 * @see VPU_JSM_MSG_METRIC_STREAMER_UPDATE
 */
struct vpu_jsm_metric_streamer_update {};

struct vpu_ipc_msg_payload_blob_deinit {};

struct vpu_ipc_msg_payload_job_done {};

struct vpu_jsm_engine_reset_context {};

struct vpu_ipc_msg_payload_engine_reset_done {};

struct vpu_ipc_msg_payload_engine_preempt_done {};

/**
 * Response structure for register doorbell command for both OS
 * and HW scheduling.
 * @see VPU_JSM_MSG_REGISTER_DB
 * @see VPU_JSM_MSG_HWS_REGISTER_DB
 */
struct vpu_ipc_msg_payload_register_db_done {};

/**
 * Response structure for unregister doorbell command for both OS
 * and HW scheduling.
 * @see VPU_JSM_MSG_UNREGISTER_DB
 */
struct vpu_ipc_msg_payload_unregister_db_done {};

struct vpu_ipc_msg_payload_query_engine_hb_done {};

struct vpu_ipc_msg_payload_get_power_level_count_done {};

struct vpu_ipc_msg_payload_blob_deinit_done {};

/* HWS priority band setup request / response */
struct vpu_ipc_msg_payload_hws_priority_band_setup {};

/*
 * @brief HWS create command queue request.
 * Host will create a command queue via this command.
 * Note: Cmdq group is a handle of an object which
 * may contain one or more command queues.
 * @see VPU_JSM_MSG_CREATE_CMD_QUEUE
 * @see VPU_JSM_MSG_CREATE_CMD_QUEUE_RSP
 */
struct vpu_ipc_msg_payload_hws_create_cmdq {};

/*
 * @brief HWS create command queue response.
 * @see VPU_JSM_MSG_CREATE_CMD_QUEUE
 * @see VPU_JSM_MSG_CREATE_CMD_QUEUE_RSP
 */
struct vpu_ipc_msg_payload_hws_create_cmdq_rsp {};

/* HWS destroy command queue request / response */
struct vpu_ipc_msg_payload_hws_destroy_cmdq {};

/* HWS set context scheduling properties request / response */
struct vpu_ipc_msg_payload_hws_set_context_sched_properties {};

/*
 * @brief Register doorbell command structure.
 * This structure supports doorbell registration for both HW and OS scheduling.
 * Note: Queue base and size are added here so that the same structure can be used for
 * OS scheduling and HW scheduling. For OS scheduling, cmdq_id will be ignored
 * and cmdq_base and cmdq_size will be used. For HW scheduling, cmdq_base and cmdq_size will be
 * ignored and cmdq_id is used.
 * @see VPU_JSM_MSG_HWS_REGISTER_DB
 */
struct vpu_jsm_hws_register_db {};

/*
 * @brief Structure to set another buffer to be used for scheduling-related logging.
 * The size of the logging buffer and the number of entries is defined as part of the
 * buffer itself as described next.
 * The log buffer received from the host is made up of;
 *   - header:     32 bytes in size, as shown in 'struct vpu_hws_log_buffer_header'.
 *                 The header contains the number of log entries in the buffer.
 *   - log entry:  0 to n-1, each log entry is 32 bytes in size, as shown in
 *                 'struct vpu_hws_log_buffer_entry'.
 *                 The entry contains the VPU timestamp, operation type and data.
 * The host should provide the notify index value of log buffer to VPU. This is a
 * value defined within the log buffer and when written to will generate the
 * scheduling log notification.
 * The host should set engine_idx and vpu_log_buffer_va to 0 to disable logging
 * for a particular engine.
 * VPU will handle one log buffer for each of supported engines.
 * VPU should allow the logging to consume one host_ssid.
 * @see VPU_JSM_MSG_HWS_SET_SCHEDULING_LOG
 * @see VPU_JSM_MSG_HWS_SET_SCHEDULING_LOG_RSP
 * @see VPU_JSM_MSG_HWS_SCHEDULING_LOG_NOTIFICATION
 */
struct vpu_ipc_msg_payload_hws_set_scheduling_log {};

/*
 * @brief The scheduling log notification is generated by VPU when it writes
 * an event into the log buffer at the notify_index. VPU notifies host with
 * VPU_JSM_MSG_HWS_SCHEDULING_LOG_NOTIFICATION. This is an asynchronous
 * message from VPU to host.
 * @see VPU_JSM_MSG_HWS_SCHEDULING_LOG_NOTIFICATION
 * @see VPU_JSM_MSG_HWS_SET_SCHEDULING_LOG
 */
struct vpu_ipc_msg_payload_hws_scheduling_log_notification {};

/*
 * @brief HWS suspend command queue request and done structure.
 * Host will request the suspend of contexts and VPU will;
 *   - Suspend all work on this context
 *   - Preempt any running work
 *   - Asynchronously perform the above and return success immediately once
 *     all items above are started successfully
 *   - Notify the host of completion of these operations via
 *     VPU_JSM_MSG_HWS_SUSPEND_CMDQ_DONE
 *   - Reject any other context operations on a context with an in-flight
 *     suspend request running
 * Same structure used when VPU notifies host of completion of a context suspend
 * request. The ids and suspend fence value reported in this command will match
 * the one in the request from the host to suspend the context. Once suspend is
 * complete, VPU will not access any data relating to this command queue until
 * it is resumed.
 * @see VPU_JSM_MSG_HWS_SUSPEND_CMDQ
 * @see VPU_JSM_MSG_HWS_SUSPEND_CMDQ_DONE
 */
struct vpu_ipc_msg_payload_hws_suspend_cmdq {};

/*
 * @brief HWS Resume command queue request / response structure.
 * Host will request the resume of a context;
 *  - VPU will resume all work on this context
 *  - Scheduler will allow this context to be scheduled
 * @see VPU_JSM_MSG_HWS_RESUME_CMDQ
 * @see VPU_JSM_MSG_HWS_RESUME_CMDQ_RSP
 */
struct vpu_ipc_msg_payload_hws_resume_cmdq {};

/*
 * @brief HWS Resume engine request / response structure.
 * After a HWS engine reset, all scheduling is stopped on VPU until a engine resume.
 * Host shall send this command to resume scheduling of any valid queue.
 * @see VPU_JSM_MSG_HWS_RESUME_ENGINE
 * @see VPU_JSM_MSG_HWS_RESUME_ENGINE_DONE
 */
struct vpu_ipc_msg_payload_hws_resume_engine {};

/**
 * Payload for VPU_JSM_MSG_TRACE_SET_CONFIG[_RSP] and
 * VPU_JSM_MSG_TRACE_GET_CONFIG_RSP messages.
 *
 * The payload is interpreted differently depending on the type of message:
 *
 * - For VPU_JSM_MSG_TRACE_SET_CONFIG, the payload specifies the desired
 *   logging configuration to be set.
 *
 * - For VPU_JSM_MSG_TRACE_SET_CONFIG_RSP, the payload reports the logging
 *   configuration that was set after a VPU_JSM_MSG_TRACE_SET_CONFIG request.
 *   The host can compare this payload with the one it sent in the
 *   VPU_JSM_MSG_TRACE_SET_CONFIG request to check whether or not the
 *   configuration was set as desired.
 *
 * - VPU_JSM_MSG_TRACE_GET_CONFIG_RSP, the payload reports the current logging
 *   configuration.
 */
struct vpu_ipc_msg_payload_trace_config {};

/**
 * Payload for VPU_JSM_MSG_TRACE_GET_CAPABILITY_RSP messages.
 */
struct vpu_ipc_msg_payload_trace_capability_rsp {};

/**
 * Payload for VPU_JSM_MSG_TRACE_GET_NAME requests.
 */
struct vpu_ipc_msg_payload_trace_get_name {};

/**
 * Payload for VPU_JSM_MSG_TRACE_GET_NAME_RSP responses.
 */
struct vpu_ipc_msg_payload_trace_get_name_rsp {};

/**
 * Data sent from the VPU to the host in all metric streamer response messages
 * and in asynchronous notification.
 * @see VPU_JSM_MSG_METRIC_STREAMER_START_DONE
 * @see VPU_JSM_MSG_METRIC_STREAMER_STOP_DONE
 * @see VPU_JSM_MSG_METRIC_STREAMER_UPDATE_DONE
 * @see VPU_JSM_MSG_METRIC_STREAMER_INFO_DONE
 * @see VPU_JSM_MSG_METRIC_STREAMER_NOTIFICATION
 */
struct vpu_jsm_metric_streamer_done {};

/**
 * Metric group description placed in the metric buffer after successful completion
 * of the VPU_JSM_MSG_METRIC_STREAMER_INFO command. This is followed by one or more
 * @vpu_jsm_metric_counter_descriptor records.
 * @see VPU_JSM_MSG_METRIC_STREAMER_INFO
 */
struct vpu_jsm_metric_group_descriptor {};

/**
 * Metric counter description, placed in the buffer after vpu_jsm_metric_group_descriptor.
 * @see VPU_JSM_MSG_METRIC_STREAMER_INFO
 */
struct vpu_jsm_metric_counter_descriptor {};

/**
 * Payload for VPU_JSM_MSG_DYNDBG_CONTROL requests.
 *
 * VPU_JSM_MSG_DYNDBG_CONTROL are used to control the VPU FW Dynamic Debug
 * feature, which allows developers to selectively enable / disable MVLOG_DEBUG
 * messages. This is equivalent to the Dynamic Debug functionality provided by
 * Linux
 * (https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html)
 * The host can control Dynamic Debug behavior by sending dyndbg commands, which
 * have the same syntax as Linux
 * dyndbg commands.
 *
 * NOTE: in order for MVLOG_DEBUG messages to be actually printed, the host
 * still has to set the logging level to MVLOG_DEBUG, using the
 * VPU_JSM_MSG_TRACE_SET_CONFIG command.
 *
 * The host can see the current dynamic debug configuration by executing a
 * special 'show' command. The dyndbg configuration will be printed to the
 * configured logging destination using MVLOG_INFO logging level.
 */
struct vpu_ipc_msg_payload_dyndbg_control {};

/**
 * Payload for VPU_JSM_MSG_PWR_D0I3_ENTER
 *
 * This is a bi-directional payload.
 */
struct vpu_ipc_msg_payload_pwr_d0i3_enter {};

/**
 * Payload for VPU_JSM_MSG_DCT_ENABLE message.
 *
 * Default values for DCT active/inactive times are 5.3ms and 30ms respectively,
 * corresponding to a 85% duty cycle. This payload allows the host to tune these
 * values according to application requirements.
 */
struct vpu_ipc_msg_payload_pwr_dct_control {};

/*
 * Payloads union, used to define complete message format.
 */
vpu_ipc_msg_payload;

/*
 * Host <-> LRT IPC message base structure.
 *
 * NOTE: All instances of this object must be aligned on a 64B boundary
 * to allow proper handling of VPU cache operations.
 */
struct vpu_jsm_msg {};

#pragma pack(pop)

#endif

///@}