mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bingbu Cao <bingbu.cao@linux.intel.com>
To: Max Staudt <mstaudt@chromium.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Bingbu Cao <bingbu.cao@intel.com>,
	Tianshu Qiu <tian.shu.qiu@intel.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ricardo Ribalda <ribalda@chromium.org>
Subject: Re: [PATCH v1 3/3] staging: media: ipu3: Stop streaming in inverse order of starting
Date: Fri, 5 Jul 2024 12:03:49 +0800	[thread overview]
Message-ID: <594c28e3-67f6-bb80-4751-ae6dc9f34c7c@linux.intel.com> (raw)
In-Reply-To: <4e01aa78-497e-477e-a5c1-951cfb1df907@chromium.org>

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

-- 
Best regards,
Bingbu Cao

  reply	other threads:[~2024-07-05  4:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-20 14:45 Fixing IPU3 IMGU warnings due to extraneous calls to s_stream() Max Staudt
2024-06-20 14:45 ` [PATCH v1 1/3] staging: media: ipu3: Drop superfluous check in imgu_vb2_stop_streaming() Max Staudt
2024-06-20 14:45 ` [PATCH v1 2/3] staging: media: ipu3: Return buffers outside of needless locking Max Staudt
2024-06-20 14:45 ` [PATCH v1 3/3] staging: media: ipu3: Stop streaming in inverse order of starting Max Staudt
2024-07-04  7:03   ` Bingbu Cao
2024-07-05  1:54     ` Max Staudt
2024-07-05  4:03       ` Bingbu Cao [this message]
2024-07-05  5:27         ` Max Staudt
2024-08-26 13:25 ` Fixing IPU3 IMGU warnings due to extraneous calls to s_stream() Ricardo Ribalda
2024-08-27  6:56 ` Sakari Ailus
2025-06-18  7:14   ` Max Staudt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=594c28e3-67f6-bb80-4751-ae6dc9f34c7c@linux.intel.com \
    --to=bingbu.cao@linux.intel.com \
    --cc=bingbu.cao@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mstaudt@chromium.org \
    --cc=ribalda@chromium.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tian.shu.qiu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®