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 (18): 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: Remap bufreq fields on HFI6XX media: venus: Introduce VPU version distinction media: venus: Add vpu_version to most SoCs media: venus: firmware: Leave a clue for homegrown porters media: venus: hfi_venus: Sanitize venus_boot_core() per-VPU-version media: venus: core: Assign registers based on VPU version media: venus: hfi_venus: Fix version checks in venus_halt_axi() media: venus: hfi_venus: Fix version checks in venus_isr() media: venus: hfi_venus: Fix version check in venus_cpu_and_video_core_idle() media: venus: hfi_venus: Fix version check in venus_cpu_idle_and_pc_ready() media: venus: firmware: Correct IS_V6() checks media: venus: hfi_platform: Check vpu_version instead of device compatible media: venus: vdec: Fix version check in vdec_set_work_route() 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 | 11 ++-- drivers/media/platform/qcom/venus/core.h | 15 ++++++ drivers/media/platform/qcom/venus/firmware.c | 19 +++++-- 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 | 45 ++++++++-------- 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, 138 insertions(+), 64 deletions(-) --- base-commit: 92e815cf07ed24ee1c51b122f24ffcf2964b4b13 change-id: 20230228-topic-venus-70ea3bc76688
Best regards,
The downstream driver signals the hardware to be enabled only after the interrupts are unmasked, which... makes sense. Follow suit.
Cc: stable@vger.kernel.org # v4.12+ Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Signed-off-by: Konrad Dybcio konrad.dybcio@linaro.org --- drivers/media/platform/qcom/venus/hfi_venus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c index bff435abd59b..8fc8f46dc390 100644 --- a/drivers/media/platform/qcom/venus/hfi_venus.c +++ b/drivers/media/platform/qcom/venus/hfi_venus.c @@ -453,7 +453,6 @@ static int venus_boot_core(struct venus_hfi_device *hdev) void __iomem *wrapper_base = hdev->core->wrapper_base; int ret = 0;
- writel(BIT(VIDC_CTRL_INIT_CTRL_SHIFT), cpu_cs_base + VIDC_CTRL_INIT); if (IS_V6(hdev->core)) { mask_val = readl(wrapper_base + WRAPPER_INTR_MASK); mask_val &= ~(WRAPPER_INTR_MASK_A2HWD_BASK_V6 | @@ -464,6 +463,7 @@ static int venus_boot_core(struct venus_hfi_device *hdev) writel(mask_val, wrapper_base + WRAPPER_INTR_MASK); writel(1, cpu_cs_base + CPU_CS_SCIACMDARG3);
+ writel(BIT(VIDC_CTRL_INIT_CTRL_SHIFT), cpu_cs_base + VIDC_CTRL_INIT); while (!ctrl_status && count < max_tries) { ctrl_status = readl(cpu_cs_base + CPU_CS_SCIACMDARG0); if ((ctrl_status & CPU_CS_SCIACMDARG0_ERROR_STATUS_MASK) == 4) {
On 5/4/2023 1:30 PM, Konrad Dybcio wrote:
The downstream driver signals the hardware to be enabled only after the interrupts are unmasked, which... makes sense. Follow suit.
Rephrase the commit text,
1. No need to mention downstream driver, if something is buggy, fix it.
2. Avoid "..." and lets make it more formal.
Cc: stable@vger.kernel.org # v4.12+ Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Signed-off-by: Konrad Dybcio konrad.dybcio@linaro.org
drivers/media/platform/qcom/venus/hfi_venus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c index bff435abd59b..8fc8f46dc390 100644 --- a/drivers/media/platform/qcom/venus/hfi_venus.c +++ b/drivers/media/platform/qcom/venus/hfi_venus.c @@ -453,7 +453,6 @@ static int venus_boot_core(struct venus_hfi_device *hdev) void __iomem *wrapper_base = hdev->core->wrapper_base; int ret = 0;
- writel(BIT(VIDC_CTRL_INIT_CTRL_SHIFT), cpu_cs_base + VIDC_CTRL_INIT); if (IS_V6(hdev->core)) { mask_val = readl(wrapper_base + WRAPPER_INTR_MASK); mask_val &= ~(WRAPPER_INTR_MASK_A2HWD_BASK_V6 |
@@ -464,6 +463,7 @@ static int venus_boot_core(struct venus_hfi_device *hdev) writel(mask_val, wrapper_base + WRAPPER_INTR_MASK); writel(1, cpu_cs_base + CPU_CS_SCIACMDARG3);
- writel(BIT(VIDC_CTRL_INIT_CTRL_SHIFT), cpu_cs_base + VIDC_CTRL_INIT); while (!ctrl_status && count < max_tries) { ctrl_status = readl(cpu_cs_base + CPU_CS_SCIACMDARG0); if ((ctrl_status & CPU_CS_SCIACMDARG0_ERROR_STATUS_MASK) == 4) {
Above code looks good.
-Vikash
On 5.05.2023 14:33, Vikash Garodia wrote:
On 5/4/2023 1:30 PM, Konrad Dybcio wrote:
The downstream driver signals the hardware to be enabled only after the interrupts are unmasked, which... makes sense. Follow suit.
Rephrase the commit text,
- No need to mention downstream driver, if something is buggy, fix it.
Generally I'd agree, however in this specific case the downstream driver is the only available source of knowledge about what the correct (or at least working) initialization sequence of this hw block is.
- Avoid "..." and lets make it more formal.
Ack
Konrad
Cc: stable@vger.kernel.org # v4.12+ Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Signed-off-by: Konrad Dybcio konrad.dybcio@linaro.org
drivers/media/platform/qcom/venus/hfi_venus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c index bff435abd59b..8fc8f46dc390 100644 --- a/drivers/media/platform/qcom/venus/hfi_venus.c +++ b/drivers/media/platform/qcom/venus/hfi_venus.c @@ -453,7 +453,6 @@ static int venus_boot_core(struct venus_hfi_device *hdev) void __iomem *wrapper_base = hdev->core->wrapper_base; int ret = 0; - writel(BIT(VIDC_CTRL_INIT_CTRL_SHIFT), cpu_cs_base + VIDC_CTRL_INIT); if (IS_V6(hdev->core)) { mask_val = readl(wrapper_base + WRAPPER_INTR_MASK); mask_val &= ~(WRAPPER_INTR_MASK_A2HWD_BASK_V6 | @@ -464,6 +463,7 @@ static int venus_boot_core(struct venus_hfi_device *hdev) writel(mask_val, wrapper_base + WRAPPER_INTR_MASK); writel(1, cpu_cs_base + CPU_CS_SCIACMDARG3); + writel(BIT(VIDC_CTRL_INIT_CTRL_SHIFT), cpu_cs_base + VIDC_CTRL_INIT); while (!ctrl_status && count < max_tries) { ctrl_status = readl(cpu_cs_base + CPU_CS_SCIACMDARG0); if ((ctrl_status & CPU_CS_SCIACMDARG0_ERROR_STATUS_MASK) == 4) {
Above code looks good.
-Vikash
On 5/6/2023 12:18 AM, Konrad Dybcio wrote:
On 5.05.2023 14:33, Vikash Garodia wrote:
On 5/4/2023 1:30 PM, Konrad Dybcio wrote:
The downstream driver signals the hardware to be enabled only after the interrupts are unmasked, which... makes sense. Follow suit.
Rephrase the commit text,
- No need to mention downstream driver, if something is buggy, fix it.
Generally I'd agree, however in this specific case the downstream driver is the only available source of knowledge about what the correct (or at least working) initialization sequence of this hw block is.
Ideal way would be to refer the sequence of register programming from hardware programming guide (HPG). In this case, the commit can describe the change which is being done and reviewer/maintainer can certify the sequence from the HPG. Also downstream driver can be buggy too, so IMO, it is not the right reference.
-Vikash
- Avoid "..." and lets make it more formal.
Ack
Konrad
Cc: stable@vger.kernel.org # v4.12+ Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Signed-off-by: Konrad Dybcio konrad.dybcio@linaro.org
drivers/media/platform/qcom/venus/hfi_venus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c index bff435abd59b..8fc8f46dc390 100644 --- a/drivers/media/platform/qcom/venus/hfi_venus.c +++ b/drivers/media/platform/qcom/venus/hfi_venus.c @@ -453,7 +453,6 @@ static int venus_boot_core(struct venus_hfi_device *hdev) void __iomem *wrapper_base = hdev->core->wrapper_base; int ret = 0; - writel(BIT(VIDC_CTRL_INIT_CTRL_SHIFT), cpu_cs_base + VIDC_CTRL_INIT); if (IS_V6(hdev->core)) { mask_val = readl(wrapper_base + WRAPPER_INTR_MASK); mask_val &= ~(WRAPPER_INTR_MASK_A2HWD_BASK_V6 | @@ -464,6 +463,7 @@ static int venus_boot_core(struct venus_hfi_device *hdev) writel(mask_val, wrapper_base + WRAPPER_INTR_MASK); writel(1, cpu_cs_base + CPU_CS_SCIACMDARG3); + writel(BIT(VIDC_CTRL_INIT_CTRL_SHIFT), cpu_cs_base + VIDC_CTRL_INIT); while (!ctrl_status && count < max_tries) { ctrl_status = readl(cpu_cs_base + CPU_CS_SCIACMDARG0); if ((ctrl_status & CPU_CS_SCIACMDARG0_ERROR_STATUS_MASK) == 4) {
Above code looks good.
-Vikash
Similarly to HFI4XX, the fields are remapped on 6XX as well. Fix it.
Cc: stable@vger.kernel.org # v5.12+ Fixes: 7ed9e0b3393c ("media: venus: hfi, vdec: v6 Add IS_V6() to existing IS_V4() if locations") Signed-off-by: Konrad Dybcio konrad.dybcio@linaro.org --- drivers/media/platform/qcom/venus/hfi_helper.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h b/drivers/media/platform/qcom/venus/hfi_helper.h index 105792a68060..e0c8f15644df 100644 --- a/drivers/media/platform/qcom/venus/hfi_helper.h +++ b/drivers/media/platform/qcom/venus/hfi_helper.h @@ -1170,11 +1170,14 @@ struct hfi_buffer_display_hold_count_actual {
/* HFI 4XX reorder the fields, use these macros */ #define HFI_BUFREQ_HOLD_COUNT(bufreq, ver) \ - ((ver) == HFI_VERSION_4XX ? 0 : (bufreq)->hold_count) + ((ver) == HFI_VERSION_4XX || (ver) == HFI_VERSION_6XX \ + ? 0 : (bufreq)->hold_count) #define HFI_BUFREQ_COUNT_MIN(bufreq, ver) \ - ((ver) == HFI_VERSION_4XX ? (bufreq)->hold_count : (bufreq)->count_min) + ((ver) == HFI_VERSION_4XX || (ver) == HFI_VERSION_6XX \ + ? (bufreq)->hold_count : (bufreq)->count_min) #define HFI_BUFREQ_COUNT_MIN_HOST(bufreq, ver) \ - ((ver) == HFI_VERSION_4XX ? (bufreq)->count_min : 0) + ((ver) == HFI_VERSION_4XX || (ver) == HFI_VERSION_6XX \ + ? (bufreq)->count_min : 0)
struct hfi_buffer_requirements { u32 type;
On 5/4/2023 1:30 PM, Konrad Dybcio wrote:
Similarly to HFI4XX, the fields are remapped on 6XX as well. Fix it.
Cc: stable@vger.kernel.org # v5.12+ Fixes: 7ed9e0b3393c ("media: venus: hfi, vdec: v6 Add IS_V6() to existing IS_V4() if locations") Signed-off-by: Konrad Dybcio konrad.dybcio@linaro.org
drivers/media/platform/qcom/venus/hfi_helper.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h b/drivers/media/platform/qcom/venus/hfi_helper.h index 105792a68060..e0c8f15644df 100644 --- a/drivers/media/platform/qcom/venus/hfi_helper.h +++ b/drivers/media/platform/qcom/venus/hfi_helper.h @@ -1170,11 +1170,14 @@ struct hfi_buffer_display_hold_count_actual { /* HFI 4XX reorder the fields, use these macros */ #define HFI_BUFREQ_HOLD_COUNT(bufreq, ver) \
- ((ver) == HFI_VERSION_4XX ? 0 : (bufreq)->hold_count)
- ((ver) == HFI_VERSION_4XX || (ver) == HFI_VERSION_6XX \
- ? 0 : (bufreq)->hold_count) #define HFI_BUFREQ_COUNT_MIN(bufreq, ver) \
- ((ver) == HFI_VERSION_4XX ? (bufreq)->hold_count : (bufreq)->count_min)
- ((ver) == HFI_VERSION_4XX || (ver) == HFI_VERSION_6XX \
- ? (bufreq)->hold_count : (bufreq)->count_min) #define HFI_BUFREQ_COUNT_MIN_HOST(bufreq, ver) \
- ((ver) == HFI_VERSION_4XX ? (bufreq)->count_min : 0)
- ((ver) == HFI_VERSION_4XX || (ver) == HFI_VERSION_6XX \
- ? (bufreq)->count_min : 0)
This patch is not correct. The existing code handles the disparity of buffer requirement payload received from firmware.
Its applicable only for V4.
For V6, driver does not rely on firmware to get the buffer requirement. Refer the buffer platform code for more details.
-Vikash
struct hfi_buffer_requirements { u32 type;
On 5.05.2023 14:38, Vikash Garodia wrote:
On 5/4/2023 1:30 PM, Konrad Dybcio wrote:
Similarly to HFI4XX, the fields are remapped on 6XX as well. Fix it.
Cc: stable@vger.kernel.org # v5.12+ Fixes: 7ed9e0b3393c ("media: venus: hfi, vdec: v6 Add IS_V6() to existing IS_V4() if locations") Signed-off-by: Konrad Dybcio konrad.dybcio@linaro.org
drivers/media/platform/qcom/venus/hfi_helper.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h b/drivers/media/platform/qcom/venus/hfi_helper.h index 105792a68060..e0c8f15644df 100644 --- a/drivers/media/platform/qcom/venus/hfi_helper.h +++ b/drivers/media/platform/qcom/venus/hfi_helper.h @@ -1170,11 +1170,14 @@ struct hfi_buffer_display_hold_count_actual { /* HFI 4XX reorder the fields, use these macros */ #define HFI_BUFREQ_HOLD_COUNT(bufreq, ver) \ - ((ver) == HFI_VERSION_4XX ? 0 : (bufreq)->hold_count) + ((ver) == HFI_VERSION_4XX || (ver) == HFI_VERSION_6XX \ + ? 0 : (bufreq)->hold_count) #define HFI_BUFREQ_COUNT_MIN(bufreq, ver) \ - ((ver) == HFI_VERSION_4XX ? (bufreq)->hold_count : (bufreq)->count_min) + ((ver) == HFI_VERSION_4XX || (ver) == HFI_VERSION_6XX \ + ? (bufreq)->hold_count : (bufreq)->count_min) #define HFI_BUFREQ_COUNT_MIN_HOST(bufreq, ver) \ - ((ver) == HFI_VERSION_4XX ? (bufreq)->count_min : 0) + ((ver) == HFI_VERSION_4XX || (ver) == HFI_VERSION_6XX \ + ? (bufreq)->count_min : 0)
This patch is not correct. The existing code handles the disparity of buffer requirement payload received from firmware.
Its applicable only for V4.
For V6, driver does not rely on firmware to get the buffer requirement. Refer the buffer platform code for more details.
OK right I can see, downstream has a condition for IRIS2/IRIS2_1, thanks for pointing this out!
Konrad
-Vikash
struct hfi_buffer_requirements { u32 type;
On 04/05/2023 09:00, Konrad Dybcio wrote:
Tested on 8250, but pretty please test it on your boards too!
What's the definition of test here ?
I ran this
ffplay -codec:video h264_v4l2m2m FantasticFour-ROTSS.mp4
and this
ffplay -codec:video vp8_v4l2m2m /mnt/big-buck-bunny_trailer.webm
on db410c with no errors. Then again I applied and disapplied the 8x8 264 fix to that branch and saw no discernable difference so I'm not very confident we have good coverage.
@Stan @Vikash could you give some suggested tests for coverage here ?
@Konrad - get a db410c !
My superficial first-pass on this series looks good but, before giving a Tested-by here, I think we should define a set of coverage tests, run them - the upper end on sm8250 and lower end msm8916 "makes sense to me"
20? different gstreamer tests at different formats and different sizes on our selected platforms db410c, rb5, rb3 I have - also an 820 I haven't booted and an enforce sdm660.
Which tests will we use to validate this series and subsequent series to ensure we don't have more regressions ?
--- bod
On 5/12/2023 8:31 AM, Bryan O'Donoghue wrote:
On 04/05/2023 09:00, Konrad Dybcio wrote:
Tested on 8250, but pretty please test it on your boards too!
What's the definition of test here ?
I ran this
ffplay -codec:video h264_v4l2m2m FantasticFour-ROTSS.mp4
and this
ffplay -codec:video vp8_v4l2m2m /mnt/big-buck-bunny_trailer.webm
on db410c with no errors. Then again I applied and disapplied the 8x8 264 fix to that branch and saw no discernable difference so I'm not very confident we have good coverage.
@Stan @Vikash could you give some suggested tests for coverage here ?
I could think of below test aspects for this series 1. Suspend Resume 2. Concurrency test 3. Module load -> video usecase -> module unload -> module load -> video usecase. This would ensure video firmware is reloaded and functional. 4. Video playback and encode for all supported resolution and codecs. 5. In general, video playback with more test content.
I would be testing the series with stability test suite on CrOS. That would be either on sc7180 or sc7280 setup.
Konrad, you can post the new version as one patch needs to be dropped. Test can be done on the new version. There are few patches in the series pending review, which can be done in parallel.
-Vikash
@Konrad - get a db410c !
My superficial first-pass on this series looks good but, before giving a Tested-by here, I think we should define a set of coverage tests, run them - the upper end on sm8250 and lower end msm8916 "makes sense to me"
20? different gstreamer tests at different formats and different sizes on our selected platforms db410c, rb5, rb3 I have - also an 820 I haven't booted and an enforce sdm660.
Which tests will we use to validate this series and subsequent series to ensure we don't have more regressions ?
bod
On 16.05.2023 14:57, Vikash Garodia wrote:
On 5/12/2023 8:31 AM, Bryan O'Donoghue wrote:
On 04/05/2023 09:00, Konrad Dybcio wrote:
Tested on 8250, but pretty please test it on your boards too!
What's the definition of test here ?
I ran this
ffplay -codec:video h264_v4l2m2m FantasticFour-ROTSS.mp4
and this
ffplay -codec:video vp8_v4l2m2m /mnt/big-buck-bunny_trailer.webm
on db410c with no errors. Then again I applied and disapplied the 8x8 264 fix to that branch and saw no discernable difference so I'm not very confident we have good coverage.
@Stan @Vikash could you give some suggested tests for coverage here ?
I could think of below test aspects for this series
- Suspend Resume
- Concurrency test
- Module load -> video usecase -> module unload -> module load -> video
usecase. This would ensure video firmware is reloaded and functional. 4. Video playback and encode for all supported resolution and codecs. 5. In general, video playback with more test content.
I would be testing the series with stability test suite on CrOS. That would be either on sc7180 or sc7280 setup.
Konrad, you can post the new version as one patch needs to be dropped. Test can be done on the new version. There are few patches in the series pending review, which can be done in parallel.
Sure, working on it!
Konrad
-Vikash
@Konrad - get a db410c !
My superficial first-pass on this series looks good but, before giving a Tested-by here, I think we should define a set of coverage tests, run them - the upper end on sm8250 and lower end msm8916 "makes sense to me"
20? different gstreamer tests at different formats and different sizes on our selected platforms db410c, rb5, rb3 I have - also an 820 I haven't booted and an enforce sdm660.
Which tests will we use to validate this series and subsequent series to ensure we don't have more regressions ?
bod
On 12.05.2023 05:01, Bryan O'Donoghue wrote:
On 04/05/2023 09:00, Konrad Dybcio wrote:
Tested on 8250, but pretty please test it on your boards too!
What's the definition of test here ?
I ran this
ffplay -codec:video h264_v4l2m2m FantasticFour-ROTSS.mp4
and this
ffplay -codec:video vp8_v4l2m2m /mnt/big-buck-bunny_trailer.webm
on db410c with no errors. Then again I applied and disapplied the 8x8 264 fix to that branch and saw no discernable difference so I'm not very confident we have good coverage.
I don't think we have any coverage at all, especially considering there were 1 or 2 patches fixing vdec not working at all in the past few months.. Maybe CrOS has some internal pipelines for this.
@Stan @Vikash could you give some suggested tests for coverage here ?
@Konrad - get a db410c !
Don't think they're even made anymore!
My superficial first-pass on this series looks good but, before giving a Tested-by here, I think we should define a set of coverage tests, run them - the upper end on sm8250 and lower end msm8916 "makes sense to me"
20? different gstreamer tests at different formats and different sizes on our selected platforms db410c, rb5, rb3 I have - also an 820 I haven't booted and an enforce sdm660.
Which tests will we use to validate this series and subsequent series to ensure we don't have more regressions ?
Personally I've done:
- boot and check if venus still probes and doesn't shout in dmesg - decode and re-encode a H264 file
which is far from perfect..
Konrad
bod
linux-stable-mirror@lists.linaro.org
-
Bryan O'Donoghue -
Konrad Dybcio -
Vikash Garodia