RE: [RFC/PATCH 2/4] [media] s5p-fimc: Porting to videobuf 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jonghun,

> -----Original Message-----
> From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Jonghun Han
> Sent: Tuesday, December 07, 2010 7:12 AM
> To: 'Sylwester Nawrocki'; linux-media@xxxxxxxxxxxxxxx; linux-samsung-
> soc@xxxxxxxxxxxxxxx
> Cc: m.szyprowski@xxxxxxxxxxx; kyungmin.park@xxxxxxxxxxx
> Subject: RE: [RFC/PATCH 2/4] [media] s5p-fimc: Porting to videobuf 2
> 
> 
> Sylwester Nawrocki wrote:
> 
> > -----Original Message-----
> > From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media-
> > owner@xxxxxxxxxxxxxxx] On Behalf Of Sylwester Nawrocki
> > Sent: Wednesday, December 01, 2010 11:36 PM
> > To: linux-media@xxxxxxxxxxxxxxx; linux-samsung-soc@xxxxxxxxxxxxxxx
> > Cc: m.szyprowski@xxxxxxxxxxx; kyungmin.park@xxxxxxxxxxx;
> > s.nawrocki@xxxxxxxxxxx
> > Subject: [RFC/PATCH 2/4] [media] s5p-fimc: Porting to videobuf 2
> >
> > Porting to videobuf 2 and minor cleanup.
> > Separate videobuf_queue_ops are are created for m2m
> > and capture video nodes.
> >
> > Signed-off-by: Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx>
> > Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> > Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
> > ---
> 
> 
> <snip>
> 
> Hi,
> 
> > @@ -968,6 +934,11 @@ static int fimc_m2m_streamon(struct file *file,
> void
> *priv,
> >  			   enum v4l2_buf_type type)
> >  {
> >  	struct fimc_ctx *ctx = priv;
> > +
> > +	/* The source and target color format need to be set */
> > +	if (~ctx->state & (FIMC_DST_FMT | FIMC_SRC_FMT))
> > +		return -EINVAL;
> > +
> >  	return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
> >  }
> 
> You had better divide a state checking according to v4l2_buf_type to
> make
> easier
> for application to use it. For example application can have two threads
> for handling m2m device. The one is for source control(OUTPUT) and
> the other is for destination control(CAPTURE). If state checking is not
> divided,
> application should consider other thread's state whether VIDIOC_S_FMT
> was
> called or not
> before VIDIOC_STREAMON.
> 
> BRs,

I would rather expect having separate threads for video buffer
queueing/dequeing only and formats configured in main thread. Anyway your
use case can be easily supported as you pointed out, since device_run
callback is called only after VIDIOC_STREAMON was called on both m2m
streams. I will incorporate your comments in the next patch set version.

Thank you,
Sylwester

--
Sylwester Nawrocki
Samsung Poland R&D Center

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux