Hello, On Wednesday, October 07, 2009 3:39 PM Karicheri, Muralidharan wrote:
> >> As we have seen in the discussion, this is not a streaming device, rather > >> a transaction/conversion device which operate on a given frame to get a > >desired output frame. Each > >> transaction may have it's own set of configuration context which will be > >applied to the hardware > >> before starting the operation. This is unlike a streaming device, where > >most of the configuration is > >> done prior to starting the streaming. > > > >From the application point of view an instance of such a device still is a > >streaming device. The application should not even know if > >any other apps are using the device or not (well, it may only notice the > >lower throughput or higher device latency, but this cannot > >be avoided). Application can queue input and output buffers, stream on and > >wait for the result. > > > In a typical capture or display side streaming, AFAIK, there is only one > device io instance. While > streaming is ON, if another application tries to do IO, driver returns > -EBUSY. I believe this is true > for all drivers (Correct me if this is not true).When you say the memory to > memory device is able to > allow multiple application to call STREAMON, this model is broken(Assuming > what I said above is true). > > May be I am missing something here. Is the following true? I think in your > model, each application > gets a device instance that has it's own scaling factors and other > parameters. So streaming status is > maintained for each IO instance. Each IO instance has it's own buffer queues. > If this is true then you > are right. Streaming model is not broken. This is exactly what I mean. Typical capture or display devices are single instance from the definition (I cannot imagine more than one application streaming _directly_ from the camera interface). However, a multi-instance support for mem2mem device perfectly makes sense and heavily improves the usability of it. > So following scenario holds good concurrently (api call sequence). > > App1 -> open() -> S_FMT -> STREAMON->QBUF/DQBUF(n times)->STREAMOFF->close() > App2 -> open() -> S_FMT -> STREAMON->QBUF/DQBUF(n times)->STREAMOFF->close() > .... > App3 -> open() -> S_FMT -> STREAMON->QBUF/DQBUF(n times)->STREAMOFF->close() Exactly. > So internal to driver, if there are multiple concurrent streamon requests, > and hardware is busy, > subsequent requests waits until the first one is complete and driver > schedules requests from multiple > IO queues. So this is essentially what we have in our internal implementation > (discussed during the > linux plumbers mini summit) converted to v4l2 model. Right, this is what we also have in our custom v4l2-incompatible drivers. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
