On Thu, Jun 7, 2018 at 4:22 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > On 06/05/2018 03:10 PM, Dave Stevenson wrote: > > Hi Tomasz. > > > > Thanks for formalising this. > > I'm working on a stateful V4L2 codec driver on the Raspberry Pi and > > was having to deduce various implementation details from other > > drivers. I know how much we all tend to hate having to write > > documentation, but it is useful to have. > > > > On 5 June 2018 at 11:33, Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: > >> Due to complexity of the video decoding process, the V4L2 drivers of > >> stateful decoder hardware require specific sequencies of V4L2 API calls > >> to be followed. These include capability enumeration, initialization, > >> decoding, seek, pause, dynamic resolution change, flush and end of > >> stream. > >> > >> Specifics of the above have been discussed during Media Workshops at > >> LinuxCon Europe 2012 in Barcelona and then later Embedded Linux > >> Conference Europe 2014 in Düsseldorf. The de facto Codec API that > >> originated at those events was later implemented by the drivers we already > >> have merged in mainline, such as s5p-mfc or mtk-vcodec. > >> > >> The only thing missing was the real specification included as a part of > >> Linux Media documentation. Fix it now and document the decoder part of > >> the Codec API. > >> > >> Signed-off-by: Tomasz Figa <tfiga@xxxxxxxxxxxx> > >> --- > >> Documentation/media/uapi/v4l/dev-codec.rst | 771 +++++++++++++++++++++ > >> Documentation/media/uapi/v4l/v4l2.rst | 14 +- > >> 2 files changed, 784 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/media/uapi/v4l/dev-codec.rst b/Documentation/media/uapi/v4l/dev-codec.rst > >> index c61e938bd8dc..0483b10c205e 100644 > >> --- a/Documentation/media/uapi/v4l/dev-codec.rst > >> +++ b/Documentation/media/uapi/v4l/dev-codec.rst > >> @@ -34,3 +34,774 @@ the codec and reprogram it whenever another file handler gets access. > >> This is different from the usual video node behavior where the video > >> properties are global to the device (i.e. changing something through one > >> file handle is visible through another file handle). > > > > I know this isn't part of the changes, but raises a question in > > v4l2-compliance (so probably one for Hans). > > testUnlimitedOpens tries opening the device 100 times. On a normal > > device this isn't a significant overhead, but when you're allocating > > resources on a per instance basis it quickly adds up. > > Internally I have state that has a limit of 64 codec instances (either > > encode or decode), so either I allocate at start_streaming and fail on > > the 65th one, or I fail on open. I generally take the view that > > failing early is a good thing. > > Opinions? Is 100 instances of an M2M device really sensible? > > Resources should not be allocated by the driver until needed (i.e. the > queue_setup op is a good place for that). > > It is perfectly legal to open a video node just to call QUERYCAP to > see what it is, and I don't expect that to allocate any hardware resources. > And if I want to open it 100 times, then that should just work. > > It is *always* wrong to limit the number of open arbitrarily. That's a valid point indeed. Besides the querying use case, userspace might just want to pre-open a bigger number of instances, but it doesn't mean that they would be streaming all at the same time indeed. Best regards, Tomasz
