On Thu, May 24, 2018 at 5:44 PM Hans Verkuil <hverk...@xs4all.nl> wrote:
> Memory-to-memory devices have one video node, one internal control handler > but two vb2_queues (DMA engines). While often there is one buffer produced > for every buffer consumed, but this is by no means standard. E.g. deinterlacers > will produce on buffer for every two buffers consumed. Codecs that receive > a bit stream and can parse it to discover the framing may have no relation > between the number of buffers consumed and the number of buffers produced. > This poses a few problems for the Request API. Requiring that a request > contains the buffers for both output and capture queue will be difficult > to implement, especially in the latter case where there is no relationship > between the number of consumed and produced buffers. > In addition, userspace can make two requests: one for the capture queue, > one for the output queue, each with associated controls. But since the > controls are shared between capture and output there is an issue of > what to do when the same control is set in both requests. > I propose to restrict the usage of requests for m2m drivers to the output > queue only. This keeps things simple for both kernel and userspace and > avoids complex solutions. > Requests only make sense if there is actually configuration you can apply > for each buffer, and while that's true for the output queue, on the capture > queue you just capture the result of whatever the device delivers. I don't > believe there is much if anything you can or want to control per-buffer. > Am I missing something? Comments? That sounds fair to me, should make kernel code simpler (no 2 requests per job, as we saw in vim2m in some earlier RFC) and shouldn't complicate userspace (it has to dequeue requests and buffers anyway, so it always knows which buffer belongs to which request for the real 1:1 M2M cases). Best regards, Tomasz
