| Message ID | 20180519203426.25711-3-laurent.pinchart@ideasonboard.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
Hi Laurent, Thank you for the patch, On 19/05/18 21:34, Laurent Pinchart wrote: > The suspend/resume test starts a run of 300 frames and suspends the > system one second later. On some SoCs (namely H3 ES2.0) the VSP > bandwidth is high enough to complete processing of 300 frames in less > than a second. The test thus suspends and resumes the system with the > VSP idle instead of running, defeating the purpose of the test. > > Fix this by increasing the number of frames to process to 1000. The > frame count is now passed as an argument to the > test_extended_wpf_packing function to ease future changes. Great idea, to make it easy to update and re-use. > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> > --- > tests/vsp-unit-test-0020.sh | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/tests/vsp-unit-test-0020.sh b/tests/vsp-unit-test-0020.sh > index 91f6b167f22e..950c1bebbf2f 100755 > --- a/tests/vsp-unit-test-0020.sh > +++ b/tests/vsp-unit-test-0020.sh > @@ -15,25 +15,26 @@ features="rpf.0 wpf.0" > # These can be extracted from /sys/power/pm_test > suspend_modes="freezer devices platform processors core" > > -# This extended function performs the same > -# as it's non-extended name-sake - but runs the pipeline > -# for 300 frames. The suspend action occurs between frame #150~#200 > - > +# This extended function performs the same as it's non-extended name-sake, but > +# runs the pipeline for a configurable number of frames. > test_extended_wpf_packing() { > local format=$1 > + local num_frames=$2 > > pipe_configure rpf-wpf 0 0 > format_configure rpf-wpf 0 0 ARGB32 1024x768 $format > > - vsp_runner rpf.0 --count=300 & > - vsp_runner wpf.0 --count=300 --skip=297 > + vsp_runner rpf.0 --count=$num_frames & > + vsp_runner wpf.0 --count=$num_frames --skip=$((num_frames-1)) The original test compared up to 3 frames... But I guess as long as one frame matches we're good on this test. We just need to know the pipeline was still running... and 3 frames doesn't provide much more information than one. > > local result=$(compare_frames) > [ x$result == xpass ] && return 0 || return 1 > } > > test_hw_pipe() { > - test_extended_wpf_packing RGB24 > + # Run the pipeline for 1000 frames. The suspend action occurs between > + # frame #500~#600 I'm not sure it's worth stating when the suspend action occurs, as it's variable depending upon the performance of the SoC ... but I'll not object to this. > + test_extended_wpf_packing RGB24 1000 > } > > test_suspend_resume() { >
Hi Kieran, On Monday, 21 May 2018 11:16:05 EEST Kieran Bingham wrote: > Hi Laurent, > > Thank you for the patch, > > On 19/05/18 21:34, Laurent Pinchart wrote: > > The suspend/resume test starts a run of 300 frames and suspends the > > system one second later. On some SoCs (namely H3 ES2.0) the VSP > > bandwidth is high enough to complete processing of 300 frames in less > > than a second. The test thus suspends and resumes the system with the > > VSP idle instead of running, defeating the purpose of the test. > > > > Fix this by increasing the number of frames to process to 1000. The > > frame count is now passed as an argument to the > > test_extended_wpf_packing function to ease future changes. > > Great idea, to make it easy to update and re-use. > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> > > > --- > > > > tests/vsp-unit-test-0020.sh | 15 ++++++++------- > > 1 file changed, 8 insertions(+), 7 deletions(-) > > > > diff --git a/tests/vsp-unit-test-0020.sh b/tests/vsp-unit-test-0020.sh > > index 91f6b167f22e..950c1bebbf2f 100755 > > --- a/tests/vsp-unit-test-0020.sh > > +++ b/tests/vsp-unit-test-0020.sh > > @@ -15,25 +15,26 @@ features="rpf.0 wpf.0" > > > > # These can be extracted from /sys/power/pm_test > > suspend_modes="freezer devices platform processors core" > > > > -# This extended function performs the same > > -# as it's non-extended name-sake - but runs the pipeline > > -# for 300 frames. The suspend action occurs between frame #150~#200 > > - > > +# This extended function performs the same as it's non-extended > > name-sake, but > > +# runs the pipeline for a configurable number of frames. > > > > test_extended_wpf_packing() { > > local format=$1 > > + local num_frames=$2 > > > > pipe_configure rpf-wpf 0 0 > > format_configure rpf-wpf 0 0 ARGB32 1024x768 $format > > > > - vsp_runner rpf.0 --count=300 & > > - vsp_runner wpf.0 --count=300 --skip=297 > > + vsp_runner rpf.0 --count=$num_frames & > > + vsp_runner wpf.0 --count=$num_frames --skip=$((num_frames-1)) > > The original test compared up to 3 frames... But I guess as long as one > frame matches we're good on this test. We just need to know the pipeline > was still running... and 3 frames doesn't provide much more information > than one. That's an oversight. num_frames-3 is what I meant. > > local result=$(compare_frames) > > [ x$result == xpass ] && return 0 || return 1 > > > > } > > > > test_hw_pipe() { > > > > - test_extended_wpf_packing RGB24 > > + # Run the pipeline for 1000 frames. The suspend action occurs between > > + # frame #500~#600 > > I'm not sure it's worth stating when the suspend action occurs, as it's > variable depending upon the performance of the SoC ... but I'll not object > to this. I agree with you, I'll remove that. I think it would make sense to run the pipeline without a limit in the frame count, and stop streaming after resume. Feel free to give it a try if you want :-) > > + test_extended_wpf_packing RGB24 1000 > > } > > > > test_suspend_resume() {
On 21/05/18 09:51, Laurent Pinchart wrote: > Hi Kieran, > > On Monday, 21 May 2018 11:16:05 EEST Kieran Bingham wrote: >> Hi Laurent, >> >> Thank you for the patch, >> >> On 19/05/18 21:34, Laurent Pinchart wrote: >>> The suspend/resume test starts a run of 300 frames and suspends the >>> system one second later. On some SoCs (namely H3 ES2.0) the VSP >>> bandwidth is high enough to complete processing of 300 frames in less >>> than a second. The test thus suspends and resumes the system with the >>> VSP idle instead of running, defeating the purpose of the test. >>> >>> Fix this by increasing the number of frames to process to 1000. The >>> frame count is now passed as an argument to the >>> test_extended_wpf_packing function to ease future changes. >> >> Great idea, to make it easy to update and re-use. >> >>> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> >> >> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> >> >>> --- >>> >>> tests/vsp-unit-test-0020.sh | 15 ++++++++------- >>> 1 file changed, 8 insertions(+), 7 deletions(-) >>> >>> diff --git a/tests/vsp-unit-test-0020.sh b/tests/vsp-unit-test-0020.sh >>> index 91f6b167f22e..950c1bebbf2f 100755 >>> --- a/tests/vsp-unit-test-0020.sh >>> +++ b/tests/vsp-unit-test-0020.sh >>> @@ -15,25 +15,26 @@ features="rpf.0 wpf.0" >>> >>> # These can be extracted from /sys/power/pm_test >>> suspend_modes="freezer devices platform processors core" >>> >>> -# This extended function performs the same >>> -# as it's non-extended name-sake - but runs the pipeline >>> -# for 300 frames. The suspend action occurs between frame #150~#200 >>> - >>> +# This extended function performs the same as it's non-extended >>> name-sake, but >>> +# runs the pipeline for a configurable number of frames. >>> >>> test_extended_wpf_packing() { >>> local format=$1 >>> + local num_frames=$2 >>> >>> pipe_configure rpf-wpf 0 0 >>> format_configure rpf-wpf 0 0 ARGB32 1024x768 $format >>> >>> - vsp_runner rpf.0 --count=300 & >>> - vsp_runner wpf.0 --count=300 --skip=297 >>> + vsp_runner rpf.0 --count=$num_frames & >>> + vsp_runner wpf.0 --count=$num_frames --skip=$((num_frames-1)) >> >> The original test compared up to 3 frames... But I guess as long as one >> frame matches we're good on this test. We just need to know the pipeline >> was still running... and 3 frames doesn't provide much more information >> than one. > > That's an oversight. num_frames-3 is what I meant. > >>> local result=$(compare_frames) >>> [ x$result == xpass ] && return 0 || return 1 >>> >>> } >>> >>> test_hw_pipe() { >>> >>> - test_extended_wpf_packing RGB24 >>> + # Run the pipeline for 1000 frames. The suspend action occurs between >>> + # frame #500~#600 >> >> I'm not sure it's worth stating when the suspend action occurs, as it's >> variable depending upon the performance of the SoC ... but I'll not object >> to this. > > I agree with you, I'll remove that. > > I think it would make sense to run the pipeline without a limit in the frame > count, and stop streaming after resume. Feel free to give it a try if you want > :-) The question here will be how to we get the frame verification to occur on the 'last N frames' For this, wouldn't we need to extend yavta to support some kind of signal to perform a stream validation at an earlier point and shutdown the stream (probably leaving the count/skip, as maximum durations to run...) And then making sure we knew which frames were actually written out ... I'll leave this ticking in the back of my mind for now :D > >>> + test_extended_wpf_packing RGB24 1000 >>> } >>> >>> test_suspend_resume() { >
Hi Kieran, On Monday, 21 May 2018 11:58:44 EEST Kieran Bingham wrote: > On 21/05/18 09:51, Laurent Pinchart wrote: > > On Monday, 21 May 2018 11:16:05 EEST Kieran Bingham wrote: > >> On 19/05/18 21:34, Laurent Pinchart wrote: > >>> The suspend/resume test starts a run of 300 frames and suspends the > >>> system one second later. On some SoCs (namely H3 ES2.0) the VSP > >>> bandwidth is high enough to complete processing of 300 frames in less > >>> than a second. The test thus suspends and resumes the system with the > >>> VSP idle instead of running, defeating the purpose of the test. > >>> > >>> Fix this by increasing the number of frames to process to 1000. The > >>> frame count is now passed as an argument to the > >>> test_extended_wpf_packing function to ease future changes. > >> > >> Great idea, to make it easy to update and re-use. > >> > >>> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > >> > >> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> > >> > >>> --- > >>> > >>> tests/vsp-unit-test-0020.sh | 15 ++++++++------- > >>> 1 file changed, 8 insertions(+), 7 deletions(-) > >>> > >>> diff --git a/tests/vsp-unit-test-0020.sh b/tests/vsp-unit-test-0020.sh > >>> index 91f6b167f22e..950c1bebbf2f 100755 > >>> --- a/tests/vsp-unit-test-0020.sh > >>> +++ b/tests/vsp-unit-test-0020.sh [snip] > >>> test_hw_pipe() { > >>> - test_extended_wpf_packing RGB24 > >>> + # Run the pipeline for 1000 frames. The suspend action occurs > >>> between > >>> + # frame #500~#600 > >> > >> I'm not sure it's worth stating when the suspend action occurs, as it's > >> variable depending upon the performance of the SoC ... but I'll not > >> object to this. > > > > I agree with you, I'll remove that. > > > > I think it would make sense to run the pipeline without a limit in the > > frame count, and stop streaming after resume. Feel free to give it a try > > if you want :-) > > The question here will be how to we get the frame verification to occur on > the 'last N frames' > > For this, wouldn't we need to extend yavta to support some kind of signal to > perform a stream validation at an earlier point and shutdown the stream > (probably leaving the count/skip, as maximum durations to run...) And then > making sure we knew which frames were actually written out ... > > I'll leave this ticking in the back of my mind for now :D Maybe it will be easier to address when we'll rewrite the tests in Python ? :-) > >>> + test_extended_wpf_packing RGB24 1000 > >>> }
On 21/05/18 10:09, Laurent Pinchart wrote: > Hi Kieran, > > On Monday, 21 May 2018 11:58:44 EEST Kieran Bingham wrote: >> On 21/05/18 09:51, Laurent Pinchart wrote: >>> On Monday, 21 May 2018 11:16:05 EEST Kieran Bingham wrote: >>>> On 19/05/18 21:34, Laurent Pinchart wrote: >>>>> The suspend/resume test starts a run of 300 frames and suspends the >>>>> system one second later. On some SoCs (namely H3 ES2.0) the VSP >>>>> bandwidth is high enough to complete processing of 300 frames in less >>>>> than a second. The test thus suspends and resumes the system with the >>>>> VSP idle instead of running, defeating the purpose of the test. >>>>> >>>>> Fix this by increasing the number of frames to process to 1000. The >>>>> frame count is now passed as an argument to the >>>>> test_extended_wpf_packing function to ease future changes. >>>> >>>> Great idea, to make it easy to update and re-use. >>>> >>>>> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> >>>> >>>> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> >>>> >>>>> --- >>>>> >>>>> tests/vsp-unit-test-0020.sh | 15 ++++++++------- >>>>> 1 file changed, 8 insertions(+), 7 deletions(-) >>>>> >>>>> diff --git a/tests/vsp-unit-test-0020.sh b/tests/vsp-unit-test-0020.sh >>>>> index 91f6b167f22e..950c1bebbf2f 100755 >>>>> --- a/tests/vsp-unit-test-0020.sh >>>>> +++ b/tests/vsp-unit-test-0020.sh > > [snip] > >>>>> test_hw_pipe() { >>>>> - test_extended_wpf_packing RGB24 >>>>> + # Run the pipeline for 1000 frames. The suspend action occurs >>>>> between >>>>> + # frame #500~#600 >>>> >>>> I'm not sure it's worth stating when the suspend action occurs, as it's >>>> variable depending upon the performance of the SoC ... but I'll not >>>> object to this. >>> >>> I agree with you, I'll remove that. >>> >>> I think it would make sense to run the pipeline without a limit in the >>> frame count, and stop streaming after resume. Feel free to give it a try >>> if you want :-) >> >> The question here will be how to we get the frame verification to occur on >> the 'last N frames' >> >> For this, wouldn't we need to extend yavta to support some kind of signal to >> perform a stream validation at an earlier point and shutdown the stream >> (probably leaving the count/skip, as maximum durations to run...) And then >> making sure we knew which frames were actually written out ... >> >> I'll leave this ticking in the back of my mind for now :D > > Maybe it will be easier to address when we'll rewrite the tests in Python ? > :-) Possibly - I need to look at Niklas' updates to his vin-tests. I'm sure there is a lot of potential code - reuse between testing the VIN and the VSP!. -- Kieran >>>>> + test_extended_wpf_packing RGB24 1000 >>>>> } >
diff --git a/tests/vsp-unit-test-0020.sh b/tests/vsp-unit-test-0020.sh index 91f6b167f22e..950c1bebbf2f 100755 --- a/tests/vsp-unit-test-0020.sh +++ b/tests/vsp-unit-test-0020.sh @@ -15,25 +15,26 @@ features="rpf.0 wpf.0" # These can be extracted from /sys/power/pm_test suspend_modes="freezer devices platform processors core" -# This extended function performs the same -# as it's non-extended name-sake - but runs the pipeline -# for 300 frames. The suspend action occurs between frame #150~#200 - +# This extended function performs the same as it's non-extended name-sake, but +# runs the pipeline for a configurable number of frames. test_extended_wpf_packing() { local format=$1 + local num_frames=$2 pipe_configure rpf-wpf 0 0 format_configure rpf-wpf 0 0 ARGB32 1024x768 $format - vsp_runner rpf.0 --count=300 & - vsp_runner wpf.0 --count=300 --skip=297 + vsp_runner rpf.0 --count=$num_frames & + vsp_runner wpf.0 --count=$num_frames --skip=$((num_frames-1)) local result=$(compare_frames) [ x$result == xpass ] && return 0 || return 1 } test_hw_pipe() { - test_extended_wpf_packing RGB24 + # Run the pipeline for 1000 frames. The suspend action occurs between + # frame #500~#600 + test_extended_wpf_packing RGB24 1000 } test_suspend_resume() {
The suspend/resume test starts a run of 300 frames and suspends the system one second later. On some SoCs (namely H3 ES2.0) the VSP bandwidth is high enough to complete processing of 300 frames in less than a second. The test thus suspends and resumes the system with the VSP idle instead of running, defeating the purpose of the test. Fix this by increasing the number of frames to process to 1000. The frame count is now passed as an argument to the test_extended_wpf_packing function to ease future changes. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> --- tests/vsp-unit-test-0020.sh | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)