[v4,00/17] Venus QoL / maintainability fixes

  v3 -> v4:
- Rebase on Stanimir's venus-for-next-v6.5
- Collapse 2 identical if-statements in "Sanitize venus_boot_core()
  per-VPU-version"
- Reword "Assign registers based on VPU version"
- Check for IS_IRIS2_1() instead of wrongly checking for core->use_tz,
  update commit msg in "media: venus: firmware: Correct IS_V6() checks"
- Access correct struct fields in "Use newly-introduced
  hfi_buffer_requirements accessors", drop Bryan's r-b

v3: https://lore.kernel.org/r/20230228-topic-venus-v3-0-6092ae43b58f@linaro.org

v2 -> v3:
- Rephrase "Write to VIDC_CTRL_INIT after unmasking interrupts" commit msg
- Drop "Remap bufreq fields on HFI6XX"
- Rephrase "Introduce VPU version distinction" commit msg
- Better explain "Leave a clue for homegrown porters"
- Drop incorrect fixes tags/rephrase version check alternations
- Drop AR50L/IRIS1 from if-conditions, they'll be introduced separately
- pick up tags
- rebase on next-20230517 (no effective changes)

v2: https://lore.kernel.org/r/20230228-topic-venus-v2-0-d95d14949c79@linaro.org

v1 -> v2:
- Move "Write to VIDC_CTRL_INIT after unmasking interrupts" up and add
  a Fixes tag & Cc stable
- Reword the comment in "Correct IS_V6() checks"
- Move up "media: venus: Remap bufreq fields on HFI6XX", add Fixes and
  Cc stable
- Use better English in "Use newly-introduced hfi_buffer_requirements
  accessors" commit message
- Mention "Restrict writing SCIACMDARG3 to Venus V1/V2" doesn't seem to
  regress SM8250 in the commit message
- Pick up tags (note: I capitalized the R in Dikshita's 'reviewed-by'
  and removed one occurrence of random '**' to make sure review tools
  like b4 don't go crazy)
- Handle AR50_LITE in "Assign registers based on VPU version"
- Drop /* VPUn */ comments, they're invalid as explained by Vikash
- Take a different approach to the sys_idle problem in patch 1

v1: https://lore.kernel.org/r/20230228-topic-venus-v1-0-58c2c88384e9@linaro.org

Currently upstream assumes all (well, almost all - see 7280 or CrOS
specific checks) Venus implementations using the same version of the
Hardware Firmware Interface can be treated the same way. This is
however not the case.

This series tries to introduce the groundwork to start differentiating
them based on the VPU (Video Processing Unit) hardware type, fixes a
couple of issues that were an effect of that generalized assumption
and lays the foundation for supporting 8150 (IRIS1) and SM6115/QCM2290
(AR50 Lite), which will hopefully come soon.

Tested on 8250, but pretty please test it on your boards too!

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Konrad Dybcio (17):
      media: venus: hfi_venus: Only consider sys_idle_indicator on V1
      media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts
      media: venus: Introduce VPU version distinction
      media: venus: Add vpu_version to most SoCs
      media: venus: firmware: Leave a clue about obtaining CP VARs
      media: venus: hfi_venus: Sanitize venus_boot_core() per-VPU-version
      media: venus: core: Assign registers based on VPU version
      media: venus: hfi_venus: Sanitize venus_halt_axi() per-VPU-version
      media: venus: hfi_venus: Sanitize venus_isr() per-VPU-version
      media: venus: hfi_venus: Sanitize venus_cpu_and_video_core_idle() per-VPU-version
      media: venus: hfi_venus: Sanitize venus_cpu_idle_and_pc_ready() per-VPU-version
      media: venus: firmware: Sanitize per-VPU-version
      media: venus: hfi_platform: Check vpu_version instead of device compatible
      media: venus: vdec: Sanitize vdec_set_work_route() per-VPU-version
      media: venus: Introduce accessors for remapped hfi_buffer_reqs members
      media: venus: Use newly-introduced hfi_buffer_requirements accessors
      media: venus: hfi_venus: Restrict writing SCIACMDARG3 to Venus V1/V2

 drivers/media/platform/qcom/venus/core.c           |  7 ++-
 drivers/media/platform/qcom/venus/core.h           | 15 ++++++
 drivers/media/platform/qcom/venus/firmware.c       | 18 +++++--
 drivers/media/platform/qcom/venus/helpers.c        |  7 +--
 drivers/media/platform/qcom/venus/hfi_helper.h     | 61 +++++++++++++++++++---
 drivers/media/platform/qcom/venus/hfi_msgs.c       |  2 +-
 .../media/platform/qcom/venus/hfi_plat_bufs_v6.c   | 22 ++++----
 drivers/media/platform/qcom/venus/hfi_platform.c   |  2 +-
 drivers/media/platform/qcom/venus/hfi_venus.c      | 42 +++++++--------
 drivers/media/platform/qcom/venus/vdec.c           | 10 ++--
 drivers/media/platform/qcom/venus/vdec_ctrls.c     |  2 +-
 drivers/media/platform/qcom/venus/venc.c           |  4 +-
 drivers/media/platform/qcom/venus/venc_ctrls.c     |  2 +-
 13 files changed, 133 insertions(+), 61 deletions(-)
---
base-commit: 9f9f8ca6f012d25428f8605cb36369a449db8508
change-id: 20230228-topic-venus-70ea3bc76688

Best regards,
  

On 30.05.2023 14:30, Konrad Dybcio wrote:
> v3 -> v4:
> - Rebase on Stanimir's venus-for-next-v6.5
> - Collapse 2 identical if-statements in "Sanitize venus_boot_core()
>   per-VPU-version"
> - Reword "Assign registers based on VPU version"
> - Check for IS_IRIS2_1() instead of wrongly checking for core->use_tz,
>   update commit msg in "media: venus: firmware: Correct IS_V6() checks"
> - Access correct struct fields in "Use newly-introduced
>   hfi_buffer_requirements accessors", drop Bryan's r-b
Stan,

could you please pick this up?

Konrad
> 
> v3: https://lore.kernel.org/r/20230228-topic-venus-v3-0-6092ae43b58f@linaro.org
> 
> v2 -> v3:
> - Rephrase "Write to VIDC_CTRL_INIT after unmasking interrupts" commit msg
> - Drop "Remap bufreq fields on HFI6XX"
> - Rephrase "Introduce VPU version distinction" commit msg
> - Better explain "Leave a clue for homegrown porters"
> - Drop incorrect fixes tags/rephrase version check alternations
> - Drop AR50L/IRIS1 from if-conditions, they'll be introduced separately
> - pick up tags
> - rebase on next-20230517 (no effective changes)
> 
> v2: https://lore.kernel.org/r/20230228-topic-venus-v2-0-d95d14949c79@linaro.org
> 
> v1 -> v2:
> - Move "Write to VIDC_CTRL_INIT after unmasking interrupts" up and add
>   a Fixes tag & Cc stable
> - Reword the comment in "Correct IS_V6() checks"
> - Move up "media: venus: Remap bufreq fields on HFI6XX", add Fixes and
>   Cc stable
> - Use better English in "Use newly-introduced hfi_buffer_requirements
>   accessors" commit message
> - Mention "Restrict writing SCIACMDARG3 to Venus V1/V2" doesn't seem to
>   regress SM8250 in the commit message
> - Pick up tags (note: I capitalized the R in Dikshita's 'reviewed-by'
>   and removed one occurrence of random '**' to make sure review tools
>   like b4 don't go crazy)
> - Handle AR50_LITE in "Assign registers based on VPU version"
> - Drop /* VPUn */ comments, they're invalid as explained by Vikash
> - Take a different approach to the sys_idle problem in patch 1
> 
> v1: https://lore.kernel.org/r/20230228-topic-venus-v1-0-58c2c88384e9@linaro.org
> 
> Currently upstream assumes all (well, almost all - see 7280 or CrOS
> specific checks) Venus implementations using the same version of the
> Hardware Firmware Interface can be treated the same way. This is
> however not the case.
> 
> This series tries to introduce the groundwork to start differentiating
> them based on the VPU (Video Processing Unit) hardware type, fixes a
> couple of issues that were an effect of that generalized assumption
> and lays the foundation for supporting 8150 (IRIS1) and SM6115/QCM2290
> (AR50 Lite), which will hopefully come soon.
> 
> Tested on 8250, but pretty please test it on your boards too!
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
> Konrad Dybcio (17):
>       media: venus: hfi_venus: Only consider sys_idle_indicator on V1
>       media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts
>       media: venus: Introduce VPU version distinction
>       media: venus: Add vpu_version to most SoCs
>       media: venus: firmware: Leave a clue about obtaining CP VARs
>       media: venus: hfi_venus: Sanitize venus_boot_core() per-VPU-version
>       media: venus: core: Assign registers based on VPU version
>       media: venus: hfi_venus: Sanitize venus_halt_axi() per-VPU-version
>       media: venus: hfi_venus: Sanitize venus_isr() per-VPU-version
>       media: venus: hfi_venus: Sanitize venus_cpu_and_video_core_idle() per-VPU-version
>       media: venus: hfi_venus: Sanitize venus_cpu_idle_and_pc_ready() per-VPU-version
>       media: venus: firmware: Sanitize per-VPU-version
>       media: venus: hfi_platform: Check vpu_version instead of device compatible
>       media: venus: vdec: Sanitize vdec_set_work_route() per-VPU-version
>       media: venus: Introduce accessors for remapped hfi_buffer_reqs members
>       media: venus: Use newly-introduced hfi_buffer_requirements accessors
>       media: venus: hfi_venus: Restrict writing SCIACMDARG3 to Venus V1/V2
> 
>  drivers/media/platform/qcom/venus/core.c           |  7 ++-
>  drivers/media/platform/qcom/venus/core.h           | 15 ++++++
>  drivers/media/platform/qcom/venus/firmware.c       | 18 +++++--
>  drivers/media/platform/qcom/venus/helpers.c        |  7 +--
>  drivers/media/platform/qcom/venus/hfi_helper.h     | 61 +++++++++++++++++++---
>  drivers/media/platform/qcom/venus/hfi_msgs.c       |  2 +-
>  .../media/platform/qcom/venus/hfi_plat_bufs_v6.c   | 22 ++++----
>  drivers/media/platform/qcom/venus/hfi_platform.c   |  2 +-
>  drivers/media/platform/qcom/venus/hfi_venus.c      | 42 +++++++--------
>  drivers/media/platform/qcom/venus/vdec.c           | 10 ++--
>  drivers/media/platform/qcom/venus/vdec_ctrls.c     |  2 +-
>  drivers/media/platform/qcom/venus/venc.c           |  4 +-
>  drivers/media/platform/qcom/venus/venc_ctrls.c     |  2 +-
>  13 files changed, 133 insertions(+), 61 deletions(-)
> ---
> base-commit: 9f9f8ca6f012d25428f8605cb36369a449db8508
> change-id: 20230228-topic-venus-70ea3bc76688
> 
> Best regards,