[v1,3/3] staging: media: ipu3: Stop streaming in inverse order of starting

  imgu_vb2_stop_streaming() did not order shutdown items in the inverse
order and count of what imgu_vb2_start_streaming() does. Consequently,
v6.7's new WARN_ON in call_s_stream() started screaming because it was
called multiple times on the entire pipe, yet it should only be called
when the pipe is interrupted by any first node being taken offline.

This reorders streamoff to be the inverse of streamon, and uses
analogous conditions to decide when and how often to call additional
teardown functions.

v4l2_subdev_call(s_stream, 0) remains outside the streaming_lock,
analogously to imgu_vb2_start_streaming().

Signed-off-by: Max Staudt <mstaudt@chromium.org>
---
 drivers/staging/media/ipu3/ipu3-v4l2.c | 36 +++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 7 deletions(-)
  

Max,

Thanks for your patch.

On 6/20/24 10:45 PM, Max Staudt wrote:
> imgu_vb2_stop_streaming() did not order shutdown items in the inverse
> order and count of what imgu_vb2_start_streaming() does. Consequently,
> v6.7's new WARN_ON in call_s_stream() started screaming because it was
> called multiple times on the entire pipe, yet it should only be called
> when the pipe is interrupted by any first node being taken offline.
> 
> This reorders streamoff to be the inverse of streamon, and uses
> analogous conditions to decide when and how often to call additional
> teardown functions.
> 
> v4l2_subdev_call(s_stream, 0) remains outside the streaming_lock,
> analogously to imgu_vb2_start_streaming().
> 
> Signed-off-by: Max Staudt <mstaudt@chromium.org>
> ---
>  drivers/staging/media/ipu3/ipu3-v4l2.c | 36 +++++++++++++++++++++-----
>  1 file changed, 29 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/media/ipu3/ipu3-v4l2.c b/drivers/staging/media/ipu3/ipu3-v4l2.c
> index 3ff390b04e1a..e7aee7e3db5b 100644
> --- a/drivers/staging/media/ipu3/ipu3-v4l2.c
> +++ b/drivers/staging/media/ipu3/ipu3-v4l2.c
> @@ -535,29 +535,51 @@ static void imgu_vb2_stop_streaming(struct vb2_queue *vq)
>  		container_of(vq, struct imgu_video_device, vbq);
>  	int r;
>  	unsigned int pipe;
> +	bool stop_streaming = false;
>  
> +	/* Verify that the node had been setup with imgu_v4l2_node_setup() */
>  	WARN_ON(!node->enabled);
>  
>  	pipe = node->pipe;
>  	dev_dbg(dev, "Try to stream off node [%u][%u]", pipe, node->id);
> -	imgu_pipe = &imgu->imgu_pipe[pipe];
> -	r = v4l2_subdev_call(&imgu_pipe->imgu_sd.subdev, video, s_stream, 0);
> -	if (r)
> -		dev_err(&imgu->pci_dev->dev,
> -			"failed to stop subdev streaming\n");

I guess the subdev streams API can help us on this, but current fix
looks fine for me.

>  
> +	/*
> +	 * When the first node of a streaming setup is stopped, the entire
> +	 * pipeline needs to stop before individual nodes are disabled.
> +	 * Perform the inverse of the initial setup.
> +	 *
> +	 * Part 1 - s_stream on the entire pipeline

stream on or off? it is a little confusing.

> +	 */
>  	mutex_lock(&imgu->streaming_lock);
> -	/* Was this the first node with streaming disabled? */
>  	if (imgu->streaming) {
>  		/* Yes, really stop streaming now */
>  		dev_dbg(dev, "IMGU streaming is ready to stop");
>  		r = imgu_s_stream(imgu, false);
>  		if (!r)
>  			imgu->streaming = false;
> +		stop_streaming = true;
>  	}
> -
>  	mutex_unlock(&imgu->streaming_lock);
>  
> +	/* Part 2 - s_stream on subdevs
> +	 *
> +	 * If we call s_stream multiple times, Linux v6.7's call_s_stream()
> +	 * WARNs and aborts. Thus, disable all pipes at once, and only once.
> +	 */
> +	if (stop_streaming) {

> +		for_each_set_bit(pipe, imgu->css.enabled_pipes,
> +				 IMGU_MAX_PIPE_NUM) {
> +			imgu_pipe = &imgu->imgu_pipe[pipe];
> +
> +			r = v4l2_subdev_call(&imgu_pipe->imgu_sd.subdev,
> +					     video, s_stream, 0);
> +			if (r)
> +				dev_err(&imgu->pci_dev->dev,
> +					"failed to stop subdev streaming\n");
> +		}

Is it possible to move this loop into 'if (imgu->streaming)' above?

> +	}
> +
> +	/* Part 3 - individual node teardown */
>  	video_device_pipeline_stop(&node->vdev);
>  	imgu_return_all_buffers(imgu, node, VB2_BUF_STATE_ERROR);
>  }
>
  

Hi Bingbu,

Thanks for your review! Replies inline...


On 7/4/24 4:03 PM, Bingbu Cao wrote:
>> diff --git a/drivers/staging/media/ipu3/ipu3-v4l2.c b/drivers/staging/media/ipu3/ipu3-v4l2.c
>> index 3ff390b04e1a..e7aee7e3db5b 100644
>> --- a/drivers/staging/media/ipu3/ipu3-v4l2.c
>> +++ b/drivers/staging/media/ipu3/ipu3-v4l2.c
>> @@ -535,29 +535,51 @@ static void imgu_vb2_stop_streaming(struct vb2_queue *vq)
>>   		container_of(vq, struct imgu_video_device, vbq);
>>   	int r;
>>   	unsigned int pipe;
>> +	bool stop_streaming = false;
>>   
>> +	/* Verify that the node had been setup with imgu_v4l2_node_setup() */
>>   	WARN_ON(!node->enabled);
>>   
>>   	pipe = node->pipe;
>>   	dev_dbg(dev, "Try to stream off node [%u][%u]", pipe, node->id);
>> -	imgu_pipe = &imgu->imgu_pipe[pipe];
>> -	r = v4l2_subdev_call(&imgu_pipe->imgu_sd.subdev, video, s_stream, 0);
>> -	if (r)
>> -		dev_err(&imgu->pci_dev->dev,
>> -			"failed to stop subdev streaming\n");
> 
> I guess the subdev streams API can help us on this, but current fix
> looks fine for me.

I don't understand what you're referring to, since your comment is in 
relation to a block of existing code that I have merely shuffled around. 
Could you please elaborate?


>>   
>> +	/*
>> +	 * When the first node of a streaming setup is stopped, the entire
>> +	 * pipeline needs to stop before individual nodes are disabled.
>> +	 * Perform the inverse of the initial setup.
>> +	 *
>> +	 * Part 1 - s_stream on the entire pipeline
> 
> stream on or off? it is a little confusing.

I meant that s_stream(off) is called "on the entire pipeline".

Thanks, I'll rephrase this in v2 :)


>> +	 */
>>   	mutex_lock(&imgu->streaming_lock);
>> -	/* Was this the first node with streaming disabled? */
>>   	if (imgu->streaming) {
>>   		/* Yes, really stop streaming now */
>>   		dev_dbg(dev, "IMGU streaming is ready to stop");
>>   		r = imgu_s_stream(imgu, false);
>>   		if (!r)
>>   			imgu->streaming = false;
>> +		stop_streaming = true;
>>   	}
>> -
>>   	mutex_unlock(&imgu->streaming_lock);
>>   
>> +	/* Part 2 - s_stream on subdevs
>> +	 *
>> +	 * If we call s_stream multiple times, Linux v6.7's call_s_stream()
>> +	 * WARNs and aborts. Thus, disable all pipes at once, and only once.
>> +	 */
>> +	if (stop_streaming) {
> 
>> +		for_each_set_bit(pipe, imgu->css.enabled_pipes,
>> +				 IMGU_MAX_PIPE_NUM) {
>> +			imgu_pipe = &imgu->imgu_pipe[pipe];
>> +
>> +			r = v4l2_subdev_call(&imgu_pipe->imgu_sd.subdev,
>> +					     video, s_stream, 0);
>> +			if (r)
>> +				dev_err(&imgu->pci_dev->dev,
>> +					"failed to stop subdev streaming\n");
>> +		}
> 
> Is it possible to move this loop into 'if (imgu->streaming)' above?

The point of separating the loop from 'if (imgu->streaming)', and why 
the stop_streaming variable exists, is to keep the loop out of the 
mutex's hot path. This follows the code in imgu_vb2_start_streaming(), 
as mentioned in the commit message.

Is it safe to do this work with the mutex taken?

Is there any need to do this work with the mutex taken?

Should the streamoff path really be different from the streamon path?

Does this mean that the streamon path should also have this happen with 
the mutex taken?



Thanks,

Max
  

Max,

On 7/5/24 9:54 AM, Max Staudt wrote:
> Hi Bingbu,
> 
> Thanks for your review! Replies inline...
> 
> 
> On 7/4/24 4:03 PM, Bingbu Cao wrote:
>>> diff --git a/drivers/staging/media/ipu3/ipu3-v4l2.c b/drivers/staging/media/ipu3/ipu3-v4l2.c
>>> index 3ff390b04e1a..e7aee7e3db5b 100644
>>> --- a/drivers/staging/media/ipu3/ipu3-v4l2.c
>>> +++ b/drivers/staging/media/ipu3/ipu3-v4l2.c
>>> @@ -535,29 +535,51 @@ static void imgu_vb2_stop_streaming(struct vb2_queue *vq)
>>>           container_of(vq, struct imgu_video_device, vbq);
>>>       int r;
>>>       unsigned int pipe;
>>> +    bool stop_streaming = false;
>>>   +    /* Verify that the node had been setup with imgu_v4l2_node_setup() */
>>>       WARN_ON(!node->enabled);
>>>         pipe = node->pipe;
>>>       dev_dbg(dev, "Try to stream off node [%u][%u]", pipe, node->id);
>>> -    imgu_pipe = &imgu->imgu_pipe[pipe];
>>> -    r = v4l2_subdev_call(&imgu_pipe->imgu_sd.subdev, video, s_stream, 0);
>>> -    if (r)
>>> -        dev_err(&imgu->pci_dev->dev,
>>> -            "failed to stop subdev streaming\n");
>>
>> I guess the subdev streams API can help us on this, but current fix
>> looks fine for me.
> 
> I don't understand what you're referring to, since your comment is in relation to a block of existing code that I have merely shuffled around. Could you please elaborate?

I guess the real problem is the subdev s_stream cannot be called multiple
times, please correct me if I am wrong as I have not touch IPU3 for long
time. :)

You can ignore my previous comment - 's_stream' is fine here.

> 
> 
>>>   +    /*
>>> +     * When the first node of a streaming setup is stopped, the entire
>>> +     * pipeline needs to stop before individual nodes are disabled.
>>> +     * Perform the inverse of the initial setup.
>>> +     *
>>> +     * Part 1 - s_stream on the entire pipeline
>>
>> stream on or off? it is a little confusing.
> 
> I meant that s_stream(off) is called "on the entire pipeline".
> 
> Thanks, I'll rephrase this in v2 :)

:)

> 
> 
>>> +     */
>>>       mutex_lock(&imgu->streaming_lock);
>>> -    /* Was this the first node with streaming disabled? */
>>>       if (imgu->streaming) {
>>>           /* Yes, really stop streaming now */
>>>           dev_dbg(dev, "IMGU streaming is ready to stop");
>>>           r = imgu_s_stream(imgu, false);
>>>           if (!r)
>>>               imgu->streaming = false;
>>> +        stop_streaming = true;
>>>       }
>>> -
>>>       mutex_unlock(&imgu->streaming_lock);
>>>   +    /* Part 2 - s_stream on subdevs
>>> +     *
>>> +     * If we call s_stream multiple times, Linux v6.7's call_s_stream()
>>> +     * WARNs and aborts. Thus, disable all pipes at once, and only once.
>>> +     */
>>> +    if (stop_streaming) {
>>
>>> +        for_each_set_bit(pipe, imgu->css.enabled_pipes,
>>> +                 IMGU_MAX_PIPE_NUM) {
>>> +            imgu_pipe = &imgu->imgu_pipe[pipe];
>>> +
>>> +            r = v4l2_subdev_call(&imgu_pipe->imgu_sd.subdev,
>>> +                         video, s_stream, 0);
>>> +            if (r)
>>> +                dev_err(&imgu->pci_dev->dev,
>>> +                    "failed to stop subdev streaming\n");
>>> +        }
>>
>> Is it possible to move this loop into 'if (imgu->streaming)' above?
> 
> The point of separating the loop from 'if (imgu->streaming)', and why the stop_streaming variable exists, is to keep the loop out of the mutex's hot path. This follows the code in imgu_vb2_start_streaming(), as mentioned in the commit message.
> 
> Is it safe to do this work with the mutex taken?
> 
> Is there any need to do this work with the mutex taken?
> 
> Should the streamoff path really be different from the streamon path?
> 
> Does this mean that the streamon path should also have this happen with the mutex taken?

Just a nit, stop_stream and s_stream only happen after imgu_s_stream(), so I
think they can be together and no need 'stop_streaming'. I think the mutex
is mainly for imgu_s_stream, subdev stream on/off should work without it.
It depends on you. :)

It'll be better that others who is still working on IPU3 devices can review.

Besides,
Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
> 
> 
> 
> Thanks,
> 
> Max
> 
>
  

On 7/5/24 1:03 PM, Bingbu Cao wrote:
> I guess the real problem is the subdev s_stream cannot be called multiple
> times, please correct me if I am wrong as I have not touch IPU3 for long
> time. :)
> 
> You can ignore my previous comment - 's_stream' is fine here.

Yes, indeed the multiple calls were what the newer V4L2 versions are 
screaming about, and what made me write this patch...


> Just a nit, stop_stream and s_stream only happen after imgu_s_stream(), so I
> think they can be together and no need 'stop_streaming'. I think the mutex
> is mainly for imgu_s_stream, subdev stream on/off should work without it.
> It depends on you. :)
> 
> It'll be better that others who is still working on IPU3 devices can review.

Okay, let's wait for their feedback then before I send a v2.


> Besides,
> Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>

Appreciated! Let's do a v2, when other Intel folks have had a chance to 
chime in.

Max