Hi Baruch, Sorry, it looks like this message has been stuck somewhere in my mailbox for quite a long time. On Thu, Jul 5, 2018 at 9:14 PM Baruch Siach <baruch@xxxxxxxxxx> wrote: > > Hi Tomasz, > > On Wed, Jul 04, 2018 at 06:04:35PM +0900, Tomasz Figa wrote: > > On Wed, Jul 4, 2018 at 5:55 PM Baruch Siach <baruch@xxxxxxxxxx> wrote: > > > So to get the rockchip-vpu driver working with current kernel I need to > > > also forward-port the embryonic Request API as well. I'll look into this. > > > > > > Are you aware of any other dependencies? > > > > I think V4L2 compound controls, but that should be already in > > upstream. I'll try to look up relevant Chromium kernel patches for you > > a bit later. > > > > > The alternative for me is to back-port rkisp1 video capture driver to vendor > > > provided 4.4 kernel so I can use the MPP shim driver. I hope to not get there. > > > > > > The easiest option, of course, is to just wait for the Request API and the new > > > codec driver. I'm not sure I can afford to wait though. > > > > I think you could also try to remove the use of config stores and make > > the driver latch control values in QBUF(OUTPUT). You would also need > > to adjust the plugin code accordingly. > > I'm trying to wrap me head around the config_store implementation in the > 'chromeos-4.4' kernel branch (commit a36974eae81a). I think I get the general > idea. Still need to figure out the details. > > I'm not sure I get your QBUF(OUTPUT) suggestion, though. Does "latch" means > that the driver attaches the same controls to all buffers, essentially > behaving like a traditional V4L2 device? Something else? > > The limitation of being able to encode only one stream at a time is acceptable > for my application. The point is that userspace needs to specify a number of controls exactly for particular frame. Let's consider following sequence in user space: 1) S_CTRL(control X, 1) 2) QBUF(buffer 1, OUTPUT) 3) S_CTRL(control X, 2) 4) QBUF(buffer 2, OUTPUT) 5) S_CTRL(control X, 3) 6) QBUF(buffer 3, OUTPUT) Traditional V4L2 device would start processing buffer 1 after 2) completes, but all the further ioctls would just execute asynchronously, possibly leading to buffer 2 being processed with control X set to 3 (not 2) or even corrupting processing results of buffer 1, since control X changes during the processing. Latching would mean that rather than setting the active control value in S_CTRL, the driver would keep the last recently set value and write it to per-buffer data in QBUF. Obviously, if your user space waits for processing to end between 2) and 3) (and 4) and 5)), each buffer would be processed with correct control value even with traditional behavior. Best regards, Tomasz _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
