Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames
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
Reviewed-by: Kieran Bingham
> ---
>
> 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
> }
>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames
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
> >>
> >> Reviewed-by: Kieran Bingham
> >>
> >>> ---
> >>>
> >>> 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
> >>> }
--
Regards,
Laurent Pinchart
Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames
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
>>
>> Reviewed-by: Kieran Bingham
>>
>>> ---
>>>
>>> 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() {
>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames
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
>
> Reviewed-by: Kieran Bingham
>
> > ---
> >
> > 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() {
--
Regards,
Laurent Pinchart
Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames
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
Reviewed-by: Kieran Bingham
> ---
> 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() {
>
signature.asc
Description: OpenPGP digital signature
[PATCH 2/2] tests: suspend/resume: Increase number of processed frames
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
---
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))
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() {
--
Regards,
Laurent Pinchart
