Hi On Tue, Aug 04, 2020 at 11:24:56AM +0100, Kieran Bingham wrote: > Hi Kaaira, > > On 31/07/2020 18:22, Kaaira Gupta wrote: > > Hi everyone, > > > > On Wed, Jul 29, 2020 at 05:24:25PM +0200, Dafna Hirschfeld wrote: > >> > >> > >> On 29.07.20 15:27, Kieran Bingham wrote: > >>> Hi Dafna, Kaaira, > >>> > >>> On 29/07/2020 14:16, Dafna Hirschfeld wrote: > >>>> > >>>> > >>>> On 29.07.20 15:05, Kieran Bingham wrote: > >>>>> Hi Dafna, > >>>>> > >>>>> On 28/07/2020 15:00, Dafna Hirschfeld wrote: > >>>>>> > >>>>>> > >>>>>> On 28.07.20 14:07, Dafna Hirschfeld wrote: > >>>>>>> Hi > >>>>>>> > >>>>>>> On 28.07.20 13:39, Kaaira Gupta wrote: > >>>>>>>> On Mon, Jul 27, 2020 at 02:54:30PM -0300, Helen Koike wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> On 7/27/20 11:31 AM, Kieran Bingham wrote: > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> +Dafna for the thread discussion, as she's missed from the to/cc > >>>>>>>>>> list. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 24/07/2020 13:21, Kaaira Gupta wrote: > >>>>>>>>>>> On Fri, Jul 24, 2020 at 02:15:21PM +0200, Niklas Söderlund wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>>> Hi Kaaira, > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks for your work. > >>>>>>>>>>> > >>>>>>>>>>> Thanks for yours :D > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 2020-07-24 17:32:10 +0530, Kaaira Gupta wrote: > >>>>>>>>>>>>> This is version 2 of the patch series posted by Niklas for > >>>>>>>>>>>>> allowing > >>>>>>>>>>>>> multiple streams in VIMC. > >>>>>>>>>>>>> The original series can be found here: > >>>>>>>>>>>>> https://patchwork.kernel.org/cover/10948831/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> This series adds support for two (or more) capture devices to be > >>>>>>>>>>>>> connected to the same sensors and run simultaneously. Each > >>>>>>>>>>>>> capture device > >>>>>>>>>>>>> can be started and stopped independent of each other. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Patch 1/3 and 2/3 deals with solving the issues that arises once > >>>>>>>>>>>>> two > >>>>>>>>>>>>> capture devices can be part of the same pipeline. While 3/3 > >>>>>>>>>>>>> allows for > >>>>>>>>>>>>> two capture devices to be part of the same pipeline and thus > >>>>>>>>>>>>> allows for > >>>>>>>>>>>>> simultaneously use. > >>>>>>> > >>>>>>> I wonder if these two patches are enough, since each vimc entity also > >>>>>>> have > >>>>>>> a 'process_frame' callback, but only one allocated frame. That means > >>>>>>> that the 'process_frame' can be called concurrently by two different > >>>>>>> streams > >>>>>>> on the same frame and cause corruption. > >>>>>>> > >>>>>> > >>>>>> I think we should somehow change the vimc-stream.c code so that we have > >>>>>> only > >>>>>> one stream process per pipe. So if one capture is already streaming, > >>>>>> then the new > >>>>>> capture that wants to stream uses the same thread so we don't have two > >>>>>> threads > >>>>>> both calling 'process_frame'. > >>>>> > >>>>> > >>>>> Yes, I think it looks and sounds like there are two threads running when > >>>>> there are two streams. > >>>>> > >>>>> so in effect, although they 'share a pipe', aren't they in effect just > >>>>> sending two separate buffers through their stream-path? > >>>>> > >>>>> If that's the case, then I don't think there's any frame corruption, > >>>>> because they would both have grabbed their own frame separately. > >>>> > >>>> But each entity allocates just one buffer. So the same buffer is used for > >>>> both stream. > >>> > >>> Aha, ok, I hadn't realised there was only a single buffer available in > >>> the pipeline for each entity. Indeed there is a risk of corruption in > >>> that case. > >>> > >>>> What for example can happen is that the debayer of one stream can read the > >>>> sensor's buffer while the sensor itself writes to the buffer for the other > >>>> stream. > >>> > >>> > >>> So, In that case, we have currently got a scenario where each 'stream' > >>> really is operating it's own pipe (even though all components are reused). > >>> > >>> Two questions: > >>> > >>> Is this acceptable, and we should just use a mutex to ensure the buffers > >>> are not corrupted, but essentially each stream is a separate temporal > >>> capture? > >>> > >>> > >>> Or B: > >>> > >>> Should we refactor to make sure that there is a single thread, and the > >>> code which calls process_frame on each entity should become aware of the > >>> potential for multiple paths at the point of the sensor. > >>> > >>> > >>> I suspect option B is really the 'right' path to take, but it is more > >>> complicated of course. > >> > >> I also think option B is preferable. > >> > >> Maybe we can add a bool field 'is_streaming' to struct 'vimc_ent_device' > >> The stream thread can do a BFS scan from the sensor up to the captures > >> and call the 'process_frame' for each entity if 'is_streaming == true'. > >> When a new capture wants to stream it sets 'is_streaming = true' > >> on the entities on his streaming path. > > > > It is s_stream(enable) that initialises a streaming pipeline, ie the one with > > those components of the pipeline which are in stream path and then runs a > > thread which calls process_frame on each and passes the frame to the > > next entity in streaming pipeline. So currently, one thread is for one > > "streaming pipeline". So there are two options I can think of if a > > single thread is required, > > > > 1. Not creating a streaming pipeline, rather create a graph(?) which > > connects both say Raw capture 1 and debayer B to sensor B if two streams > > are asked for, and only one of them if one stream is asked..that will > > not be a property of streamer, so I am not sure where it should be kept. > > Then I could move creating a thread out of s_stream. Creating the thread > > should wait for entire pipeline to be created, ie s_stream(enable) to > > must be called by both the captures, and a graph made of all pipeline > > components before thread initialisation starts. I am not sure how this > > should be implemented. > > The graph already exists, and can be walked through the media controller > right? Yes, but actually, the current implementation of the thread does not walk through the entire pipeline, rather ved_pipeline, which is the portions of the pipeline which come in the streaming path of a stream which calls the thread. This also answers your doubt why the pipeline is decreamenting (which you have asked later in the mail). ved_pipeline is an array of the entities in the path of the stream starting from capture. Hence my suggestion was if I should make a data structure (a graph) which holds all the entities in one or more stream path. > > > > 2. Another option is to check if a stream already exists (by creating it > > a property of vimc to keep a track of no. of streams maybe?), if it is > > already present I could take the previous output of sensor (but > > then it will have to be stored, so i don't think this is a nice idea), > > and use it further (but thread will be different in this case). > > I don't think I understand this one... I meant that to start a thread for the driver, rather than each stream, maybe instead of creating a graph (as in the first option), maybe the druver could know the number of steams alsready running, and hence when s_stream is called for another, it knows how many and what type of streams are running, which can then /know/ which entity's output of process_frame(previous stream) to give on to the current stream. But I wasn't sure about the implementation of the /knwing/part without hardcoding it to take output from the sensor. But since that is the only topology (hardcoded)we have currently, maybe that can be a solution, hence I asked. > > > > What can be a better design for VIMC to have a single thread if two > > streams are asked (apart/of the options I mentioned)? > > How about adding a count in s_stream so that the thread only gets > started when the use count is > 0, and stopped when the usage < 1. > > That handles making sure that only one thread is available. > > All calls into s_stream() will need to take a lock/mutex to protect / > prevent any action from occurring while the thread is performing a > process of the pipeline. > > > static int vimc_streamer_thread(void *data) > { > struct vimc_stream *stream = data; > u8 *frame = NULL; > int i; > > set_freezable(); > > for (;;) { > try_to_freeze(); > if (kthread_should_stop()) > break; > > + /* take lock shared with s_stream */ > > for (i = stream->pipe_size - 1; i >= 0; i--) { > frame = stream->ved_pipeline[i]->process_frame( > stream->ved_pipeline[i], frame); > if (!frame || IS_ERR(frame)) > break; > } > > + /* Release lock/mutex shared with s_stream > > //wait for 60hz > set_current_state(TASK_UNINTERRUPTIBLE); > schedule_timeout(HZ / 60); > } > > return 0; > } > > > > And you'll need to make the code which processes the pipeline aware of > the fact that there may be two pipelines to fulfil: > > Pseudo patch/code: > > static int vimc_streamer_thread(void *data) > { > - struct vimc_stream *stream = data; > + /* Something which knows about the whole device */ > + struct xxxxx *yyy = data; > > + u8 *raw; > u8 *frame = NULL; > int i; > > set_freezable(); > > for (;;) { > try_to_freeze(); > if (kthread_should_stop()) > break; > > /* take lock shared with s_stream */ > > + /* Process the sensor first */ > + raw = stream->ved_pipeline[sensor]->process_frame(..); > + error check; > > + /* (If connected) Process stream 1 */ > + if (raw) > + frame = stream->ved_pipeline[raw]->process_frame(); > + error check; > > + /* If connected process the rest of the pipe */ > + for (i = after sensor; end_entity; i++) { > frame = stream->ved_pipeline[i]->process_frame( > stream->ved_pipeline[i], frame); > if (!frame || IS_ERR(frame)) > break; > } > > /* Release lock/mutex shared with s_stream > > //wait for 60hz > set_current_state(TASK_UNINTERRUPTIBLE); > schedule_timeout(HZ / 60); > } > > return 0; > } > > > > I may have missed something as the original loop was decrementing and > going backwards through the entities in stream->ved_pipeline. > > I guess splitting that all out so instead it starts at the sensor, and > just walks the graph (handling any running/connected fork to two > entities appropriately) in a neater way would be another option rather > than hardcoding it, but either way the thread needs to operate at the > device level rather than the stream level. > > > > > Thanks > > Kaaira > > > >> > >> Thanks, > >> Dafna > >> > >> > >>> > >>> -- > >>> Kieran > >>> > >>> > >>> > >>> > >>>> Thanks, > >>>> Dafna > >>>> > >>>>> > >>>>> > >>>>> I don't think that's a good example of the hardware though, as that > >>>>> doesn't reflect what 'should' happen where the TPG runs once to generate > >>>>> a frame at the sensor, which is then read by both the debayer entity and > >>>>> the RAW capture device when there are two streams... > >>>>> > >>>>> > >>>>> So I suspect trying to move to a single thread is desirable, but that > >>>>> might be a fair bit of work also. > >>>>> > >>>>> -- > >>>>> Kieran > >>>>> > >>>>> > >>>>> > >>>>>> The second capture that wants to stream should iterate the topology > >>>>>> downwards until > >>>>>> reaching an entity that already belong to the stream path of the other > >>>>>> streaming capture > >>>>>> and tell the streamer it wants to read the frames this entity > >>>>>> produces. > >>>>>> > >>>>>> Thanks, > >>>>>> Dafna > >>>>>> > >>>>>>> Thanks, > >>>>>>> Dafna > >>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> I'm just curious if you are aware of this series? It would > >>>>>>>>>>>> replace the > >>>>>>>>>>>> need for 1/3 and 2/3 of this series right? > >>>>>>>>>>> > >>>>>>>>>>> v3 of this series replaces the need for 1/3, but not the current > >>>>>>>>>>> version > >>>>>>>>>>> (ie v4). v4 of patch 2/5 removes the stream_counter that is > >>>>>>>>>>> needed to > >>>>>>>>>>> keep count of the calls to s_stream. Hence 1/3 becomes relevant > >>>>>>>>>>> again. > >>>>>>>>>> > >>>>>>>>>> So the question really is, how do we best make use of the two > >>>>>>>>>> current > >>>>>>>>>> series, to achieve our goal of supporting multiple streams. > >>>>>>>>>> > >>>>>>>>>> Having not parsed Dafna's series yet, do we need to combine > >>>>>>>>>> elements of > >>>>>>>>>> both ? Or should we work towards starting with this series and get > >>>>>>>>>> dafna's patches built on top ? > >>>>>>>>>> > >>>>>>>>>> Or should patch 1/3 and 3/3 of this series be on top of Dafna's v4 ? > >>>>>>>>>> > >>>>>>>>>> (It might be noteworthy to say that Kaaira has reported successful > >>>>>>>>>> multiple stream operation from /this/ series and her development > >>>>>>>>>> branch > >>>>>>>>>> on libcamera). > >>>>>>>>> > >>>>>>>>> Dafna's patch seems still under discussion, but I don't want to > >>>>>>>>> block progress in Vimc either. > >>>>>>>>> > >>>>>>>>> So I was wondering if we can move forward with Vimc support for > >>>>>>>>> multistreaming, > >>>>>>>>> without considering Dafna's patchset, and we can do the clean up > >>>>>>>>> later once we solve that. > >>>>>>>>> > >>>>>>>>> What do you think? > >>>>>>>> > >>>>>>>> I agree with supporting multiple streams with VIMC with this patchset, > >>>>>>>> and then we can refactor the counters for s_stream in VIMC later (over > >>>>>>>> this series) if dafna includes them in subsequent version of her > >>>>>>>> patchset. > >>>>>>>> > >>>>>>> > >>>>>>> I also think that adding support in the code will take much longer and > >>>>>>> should not > >>>>>>> stop us from supporting vimc independently. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Dafna > >>>>>>> > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Helen > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>> 1. > >>>>>>>>>>>> https://lore.kernel.org/linux-media/20200522075522.6190-1-dafna.hirschfeld@xxxxxxxxxxxxx/ > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Changes since v1: > >>>>>>>>>>>>> - All three patches rebased on latest media-tree. > >>>>>>>>>>>>> Patch 3: > >>>>>>>>>>>>> - Search for an entity with a non-NULL pipe instead of > >>>>>>>>>>>>> searching > >>>>>>>>>>>>> for sensor. This terminates the search at output itself. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Kaaira Gupta (3): > >>>>>>>>>>>>> media: vimc: Add usage count to subdevices > >>>>>>>>>>>>> media: vimc: Serialize vimc_streamer_s_stream() > >>>>>>>>>>>>> media: vimc: Join pipeline if one already exists > >>>>>>>>>>>>> > >>>>>>>>>>>>> .../media/test-drivers/vimc/vimc-capture.c | 35 > >>>>>>>>>>>>> ++++++++++++++++++- > >>>>>>>>>>>>> .../media/test-drivers/vimc/vimc-debayer.c | 8 +++++ > >>>>>>>>>>>>> drivers/media/test-drivers/vimc/vimc-scaler.c | 8 +++++ > >>>>>>>>>>>>> drivers/media/test-drivers/vimc/vimc-sensor.c | 9 ++++- > >>>>>>>>>>>>> .../media/test-drivers/vimc/vimc-streamer.c | 23 > >>>>>>>>>>>>> +++++++----- > >>>>>>>>>>>>> 5 files changed, 73 insertions(+), 10 deletions(-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- > >>>>>>>>>>>>> 2.17.1 > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> Niklas Söderlund > >>>>>>>>>> > >>>>> > >>> > > -- > Regards > -- > Kieran
