[PATCH 0/2] vsp-tests: Fix suspend/resume test

[PATCH 0/2] vsp-tests: Fix suspend/resume test

[Laurent Pinchart]

Hello,

This small series fixes the VSP suspend/resume test to ensure that the
VSP is running when suspending. The first patch isn't strictly required,
but was helpful when debugging the second patch, so I've included it in
the series.

Laurent Pinchart (2):
  vsp-lib: Capture the kernel log messages in test log files
  tests: suspend/resume: Increase number of processed frames

 scripts/vsp-lib.sh          |  5 +++++
 tests/vsp-unit-test-0020.sh | 15 ++++++++-------
 2 files changed, 13 insertions(+), 7 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 1/2] vsp-lib: Capture the kernel log messages in test log files

[Laurent Pinchart]

It can be useful to capture kernel log messages in test log files for
diagnostic purpose. Add a simple mechanism to do so by capturing the
full kernel log at the end of the test. The kernel log is cleared first
before starting the test to avoid capturing unrelated messages.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 scripts/vsp-lib.sh | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
index 0f3992a7827e..e672686a377e 100755
--- a/scripts/vsp-lib.sh
+++ b/scripts/vsp-lib.sh
@@ -1075,6 +1075,9 @@ test_init() {
 	echo "Using device $mdev ($dev)" | ./logger.sh config >> $logfile
 
 	vsp_runner=./vsp-runner.sh
+
+	# Clear the kernel log
+	dmesg -c > /dev/null
 }
 
 test_start() {
@@ -1086,6 +1089,8 @@ test_complete() {
 	echo "Done: $1" | ./logger.sh >> $logfile
 	echo $1 >&2
 
+	dmesg -c | ./logger.sh kernel >> $logfile
+
 	rm -f ${frames_dir}frame-*.bin
 	rm -f ${frames_dir}histo-*.bin
 	rm -f ${frames_dir}rpf.*.bin
-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] vsp-lib: Capture the kernel log messages in test log files

[Niklas Söderlund]

Hi Laurent,

Thanks for your patch.

On 2018-05-19 23:34:25 +0300, Laurent Pinchart wrote:
> It can be useful to capture kernel log messages in test log files for
> diagnostic purpose. Add a simple mechanism to do so by capturing the
> full kernel log at the end of the test. The kernel log is cleared first
> before starting the test to avoid capturing unrelated messages.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>  scripts/vsp-lib.sh | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
> index 0f3992a7827e..e672686a377e 100755
> --- a/scripts/vsp-lib.sh
> +++ b/scripts/vsp-lib.sh
> @@ -1075,6 +1075,9 @@ test_init() {
>  	echo "Using device $mdev ($dev)" | ./logger.sh config >> $logfile
>  
>  	vsp_runner=./vsp-runner.sh
> +
> +	# Clear the kernel log
> +	dmesg -c > /dev/null

I agree it's useful to capture the kernel log messages during a test, I 
did the same thing in vin-tests. What I did learn was that when 
something do go wrong you kind of want the whole kernel log from boot 
and truncating it could be annoying. Just the other day I got feed up 
with this in vin-tests and found a different way, as it's still fresh in 
my memory maybe it could be useful for you too, or not :-)

    marker=$(dmesg | tail -n 1 | sed 's/^\[\([^]]*\)\].*/\1/g')


>  }
>  
>  test_start() {
> @@ -1086,6 +1089,8 @@ test_complete() {
>  	echo "Done: $1" | ./logger.sh >> $logfile
>  	echo $1 >&2
>  
> +	dmesg -c | ./logger.sh kernel >> $logfile
> +

        dmesg | sed "1,/$marker/d" | ./logger.sh kernel >> $logfile

>  	rm -f ${frames_dir}frame-*.bin
>  	rm -f ${frames_dir}histo-*.bin
>  	rm -f ${frames_dir}rpf.*.bin
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas S�derlund

Re: [PATCH 1/2] vsp-lib: Capture the kernel log messages in test log files

[Laurent Pinchart]

Hi Niklas,

On Sunday, 20 May 2018 13:47:53 EEST Niklas Söderlund wrote:
> On 2018-05-19 23:34:25 +0300, Laurent Pinchart wrote:
> > It can be useful to capture kernel log messages in test log files for
> > diagnostic purpose. Add a simple mechanism to do so by capturing the
> > full kernel log at the end of the test. The kernel log is cleared first
> > before starting the test to avoid capturing unrelated messages.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> > 
> >  scripts/vsp-lib.sh | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
> > index 0f3992a7827e..e672686a377e 100755
> > --- a/scripts/vsp-lib.sh
> > +++ b/scripts/vsp-lib.sh
> > @@ -1075,6 +1075,9 @@ test_init() {
> > 
> >  	echo "Using device $mdev ($dev)" | ./logger.sh config >> $logfile
> >  	
> >  	vsp_runner=./vsp-runner.sh
> > 
> > +
> > +	# Clear the kernel log
> > +	dmesg -c > /dev/null
> 
> I agree it's useful to capture the kernel log messages during a test, I
> did the same thing in vin-tests. What I did learn was that when
> something do go wrong you kind of want the whole kernel log from boot
> and truncating it could be annoying. Just the other day I got feed up
> with this in vin-tests and found a different way, as it's still fresh in
> my memory maybe it could be useful for you too, or not :-)
> 
>     marker=$(dmesg | tail -n 1 | sed 's/^\[\([^]]*\)\].*/\1/g')
> 
> >  }
> >  
> >  test_start() {
> > 
> > @@ -1086,6 +1089,8 @@ test_complete() {
> > 
> >  	echo "Done: $1" | ./logger.sh >> $logfile
> >  	echo $1 >&2
> > 
> > +	dmesg -c | ./logger.sh kernel >> $logfile
> > +
> 
>         dmesg | sed "1,/$marker/d" | ./logger.sh kernel >> $logfile

That's a good idea. I gave it a try and it worked, I'll send a v2.

> >  	rm -f ${frames_dir}frame-*.bin
> >  	rm -f ${frames_dir}histo-*.bin
> >  	rm -f ${frames_dir}rpf.*.bin

-- 
Regards,

Laurent Pinchart

[PATCH 2/2] tests: suspend/resume: Increase number of processed frames

[Laurent Pinchart]

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(-)

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

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

[Kieran Bingham]

[-- Attachment #1.1: Type: text/plain, Size: 2742 bytes --]

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() {
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

[Laurent Pinchart]

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() {

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

[Kieran Bingham]

[-- Attachment #1.1: Type: text/plain, Size: 3777 bytes --]

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() {
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

[Laurent Pinchart]

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
> >>>  }

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

[Kieran Bingham]

[-- Attachment #1.1: Type: text/plain, Size: 2848 bytes --]

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
>>>>>  }
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]