Applied with updated commit message to drm-misc-fixes

On 4/1/2025 5:58 PM, Maciej Falkowski wrote:
> From: Karol Wachowski <karol.wachow...@intel.com>
> 
> This commit bumps FW Boot API to 3.28.3.
> 
> Use new preemption buffer size fields from FW header added to
> firmware boot API for preemption buffers allocations,
> if those new fields are zeroed use old values instead.
> 
> Signed-off-by: Karol Wachowski <karol.wachow...@intel.com>
> Signed-off-by: Maciej Falkowski <maciej.falkow...@linux.intel.com>
> ---
>  drivers/accel/ivpu/ivpu_fw.c      | 14 ++++++--
>  drivers/accel/ivpu/vpu_boot_api.h | 13 ++++++--
>  drivers/accel/ivpu/vpu_jsm_api.h  | 53 +++++++++++++++++++++----------
>  3 files changed, 58 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
> index 7a1bb92d8c81..3799231b39e7 100644
> --- a/drivers/accel/ivpu/ivpu_fw.c
> +++ b/drivers/accel/ivpu/ivpu_fw.c
> @@ -233,10 +233,20 @@ static int ivpu_fw_parse(struct ivpu_device *vdev)
>       fw->dvfs_mode = 0;
>  
>       fw->sched_mode = ivpu_fw_sched_mode_select(vdev, fw_hdr);
> -     fw->primary_preempt_buf_size = fw_hdr->preemption_buffer_1_size;
> -     fw->secondary_preempt_buf_size = fw_hdr->preemption_buffer_2_size;
>       ivpu_info(vdev, "Scheduler mode: %s\n", fw->sched_mode ? "HW" : "OS");
>  
> +     if (fw_hdr->preemption_buffer_1_max_size)
> +             fw->primary_preempt_buf_size = 
> fw_hdr->preemption_buffer_1_max_size;
> +     else
> +             fw->primary_preempt_buf_size = fw_hdr->preemption_buffer_1_size;
> +
> +     if (fw_hdr->preemption_buffer_2_max_size)
> +             fw->secondary_preempt_buf_size = 
> fw_hdr->preemption_buffer_2_max_size;
> +     else
> +             fw->secondary_preempt_buf_size = 
> fw_hdr->preemption_buffer_2_size;
> +     ivpu_dbg(vdev, FW_BOOT, "Preemption buffer sizes: primary %u, secondary 
> %u\n",
> +              fw->primary_preempt_buf_size, fw->secondary_preempt_buf_size);
> +
>       if (fw_hdr->ro_section_start_address && 
> !is_within_range(fw_hdr->ro_section_start_address,
>                                                                
> fw_hdr->ro_section_size,
>                                                                
> fw_hdr->image_load_address,
> diff --git a/drivers/accel/ivpu/vpu_boot_api.h 
> b/drivers/accel/ivpu/vpu_boot_api.h
> index 908e68ea1c39..218468bbbcad 100644
> --- a/drivers/accel/ivpu/vpu_boot_api.h
> +++ b/drivers/accel/ivpu/vpu_boot_api.h
> @@ -26,7 +26,7 @@
>   * Minor version changes when API backward compatibility is preserved.
>   * Resets to 0 if Major version is incremented.
>   */
> -#define VPU_BOOT_API_VER_MINOR 26
> +#define VPU_BOOT_API_VER_MINOR 28
>  
>  /*
>   * API header changed (field names, documentation, formatting) but API 
> itself has not been changed
> @@ -76,8 +76,15 @@ struct vpu_firmware_header {
>        * submission queue size and device capabilities.
>        */
>       u32 preemption_buffer_2_size;
> +     /*
> +      * Maximum preemption buffer size that the FW can use: no need for the 
> host
> +      * driver to allocate more space than that specified by these fields.
> +      * A value of 0 means no declared limit.
> +      */
> +     u32 preemption_buffer_1_max_size;
> +     u32 preemption_buffer_2_max_size;
>       /* Space reserved for future preemption-related fields. */
> -     u32 preemption_reserved[6];
> +     u32 preemption_reserved[4];
>       /* FW image read only section start address, 4KB aligned */
>       u64 ro_section_start_address;
>       /* FW image read only section size, 4KB aligned */
> @@ -134,7 +141,7 @@ enum vpu_trace_destination {
>  /*
>   * Processor bit shifts (for loggable HW components).
>   */
> -#define VPU_TRACE_PROC_BIT_ARM            0
> +#define VPU_TRACE_PROC_BIT_RESERVED  0
>  #define VPU_TRACE_PROC_BIT_LRT            1
>  #define VPU_TRACE_PROC_BIT_LNN            2
>  #define VPU_TRACE_PROC_BIT_SHV_0     3
> diff --git a/drivers/accel/ivpu/vpu_jsm_api.h 
> b/drivers/accel/ivpu/vpu_jsm_api.h
> index 7215c144158c..4b6b2b3d2583 100644
> --- a/drivers/accel/ivpu/vpu_jsm_api.h
> +++ b/drivers/accel/ivpu/vpu_jsm_api.h
> @@ -22,7 +22,7 @@
>  /*
>   * Minor version changes when API backward compatibility is preserved.
>   */
> -#define VPU_JSM_API_VER_MINOR 25
> +#define VPU_JSM_API_VER_MINOR 29
>  
>  /*
>   * API header changed (field names, documentation, formatting) but API 
> itself has not been changed
> @@ -53,8 +53,7 @@
>   * Engine indexes.
>   */
>  #define VPU_ENGINE_COMPUTE 0
> -#define VPU_ENGINE_COPY         1
> -#define VPU_ENGINE_NB           2
> +#define VPU_ENGINE_NB           1
>  
>  /*
>   * VPU status values.
> @@ -126,11 +125,13 @@ enum {
>        * When set, indicates that job queue uses native fences (as inline 
> commands
>        * in job queue). Such queues may also use legacy fences (as commands 
> in batch buffers).
>        * When cleared, indicates the job queue only uses legacy fences.
> -      * NOTE: For queues using native fences, VPU expects that all jobs in 
> the queue
> -      * are immediately followed by an inline command object. This object is 
> expected
> -      * to be a fence signal command in most cases, but can also be a NOP in 
> case the host
> -      * does not need per-job fence signalling. Other inline commands 
> objects can be
> -      * inserted between "job and inline command" pairs.
> +      * NOTES:
> +      *   1. For queues using native fences, VPU expects that all jobs in 
> the queue
> +      *      are immediately followed by an inline command object. This 
> object is expected
> +      *      to be a fence signal command in most cases, but can also be a 
> NOP in case the host
> +      *      does not need per-job fence signalling. Other inline commands 
> objects can be
> +      *      inserted between "job and inline command" pairs.
> +      *  2. Native fence queues are only supported on VPU 40xx onwards.
>        */
>       VPU_JOB_QUEUE_FLAGS_USE_NATIVE_FENCE_MASK = (1 << 1U),
>  
> @@ -275,6 +276,8 @@ struct vpu_inline_cmd {
>                       u64 value;
>                       /* User VA of the log buffer in which to add log entry 
> on completion. */
>                       u64 log_buffer_va;
> +                     /* NPU private data. */
> +                     u64 npu_private_data;
>               } fence;
>               /* Other commands do not have a payload. */
>               /* Payload definition for future inline commands can be 
> inserted here. */
> @@ -791,12 +794,22 @@ struct vpu_jsm_metric_streamer_update {
>       /** Metric group mask that identifies metric streamer instance. */
>       u64 metric_group_mask;
>       /**
> -      * Address and size of the buffer where the VPU will write metric data. 
> If
> -      * the buffer address is 0 or same as the currently used buffer the VPU 
> will
> -      * continue writing metric data to the current buffer. In this case the
> -      * buffer size is ignored and the size of the current buffer is 
> unchanged.
> -      * If the address is non-zero and differs from the current buffer 
> address the
> -      * VPU will immediately switch data collection to the new buffer.
> +      * Address and size of the buffer where the VPU will write metric data.
> +      * This member dictates how the update operation should perform:
> +      * 1. client needs information about the number of collected samples 
> and the
> +      *   amount of data written to the current buffer
> +      * 2. client wants to switch to a new buffer
> +      *
> +      * Case 1. is identified by the buffer address being 0 or the same as 
> the
> +      * currently used buffer address. In this case the buffer size is 
> ignored and
> +      * the size of the current buffer is unchanged. The VPU will return an 
> update
> +      * in the vpu_jsm_metric_streamer_done structure. The internal writing 
> position
> +      * into the buffer is not changed.
> +      *
> +      * Case 2. is identified by the address being non-zero and differs from 
> the
> +      * current buffer address. The VPU will immediately switch data 
> collection to
> +      * the new buffer. Then the VPU will return an update in the
> +      * vpu_jsm_metric_streamer_done structure.
>        */
>       u64 buffer_addr;
>       u64 buffer_size;
> @@ -934,6 +947,7 @@ struct vpu_ipc_msg_payload_hws_priority_band_setup {
>       /*
>        * Default quantum in 100ns units for scheduling across processes
>        * within a priority band
> +      * Minimum value supported by NPU is 1ms (10000 in 100ns units).
>        */
>       u32 process_quantum[VPU_HWS_NUM_PRIORITY_BANDS];
>       /*
> @@ -946,8 +960,10 @@ struct vpu_ipc_msg_payload_hws_priority_band_setup {
>        * in situations when it's starved by the focus band.
>        */
>       u32 normal_band_percentage;
> -     /* Reserved */
> -     u32 reserved_0;
> +     /*
> +      * TDR timeout value in milliseconds. Default value of 0 meaning no 
> timeout.
> +      */
> +     u32 tdr_timeout;
>  };
>  
>  /*
> @@ -1024,7 +1040,10 @@ struct 
> vpu_ipc_msg_payload_hws_set_context_sched_properties {
>       s32 in_process_priority;
>       /* Zero padding / Reserved */
>       u32 reserved_1;
> -     /* Context quantum relative to other contexts of same priority in the 
> same process */
> +     /*
> +      * Context quantum relative to other contexts of same priority in the 
> same process
> +      * Minimum value supported by NPU is 1ms (10000 in 100ns units).
> +      */
>       u64 context_quantum;
>       /* Grace period when preempting context of the same priority within the 
> same process */
>       u64 grace_period_same_priority;

Reply via email to