Received: by 10.223.185.116 with SMTP id b49csp217738wrg; Mon, 19 Feb 2018 20:46:27 -0800 (PST) X-Google-Smtp-Source: AH8x227rQbgIGeD+kuyGleeZcwn6c4q7OWGDpQe5yYCXMRF+E0Bodn0GbTUiXnoF0TqmUxN7VVOA X-Received: by 2002:a17:902:d20a:: with SMTP id t10-v6mr16426894ply.257.1519101987356; Mon, 19 Feb 2018 20:46:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519101987; cv=none; d=google.com; s=arc-20160816; b=ycGWIH+OWrPvORpQu+R8zFrVumYgP4Y+eQWSBc7x/xBQ/n6ei8NuLXKKdOLlG001N2 4t/jTuezNF1t5UvVhvaeK9o9eSFiZhfx2z1oYIiOfuvZxDq+Mmf80CCn5Uf5N7oBuqGV PeXsXwdwWvjPeGq7Rlzg7WEzdL/dp27rximND3eCPNQ+KTNZzVznxkYTMcCl9W/2+wOf YlhJIW7UoqjjzNzyWlavPA9VN0lgCN57LBPDvJYbvT8fyJZLOoTjvyz+FOji0kkhARyy YLw7jLVQtoDf783+YCo3j7sp8o7/rffDNgUkKqDc5SsBWo+D9ESj554E1TrPV7a2Kl1v UwxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=cujUOofQs3FywqOLI+9HiTYUB3Pag5x3VtAjCf0+PVA=; b=D3MCvQYaL346A79XvUYg7e10Gp20ErOPVLzHpJDoyuj+O52WzKhzdlt4cQxCN0ukGg wBGd8a5VFNuaEELtMdlZXJLbw8MOJMGTfpbzZnqDqmIA+iBVrZc10k+NKH4DGrUCcCLc PP6qnc074vrpCWb3Ttyl7keEbbbF3pdNfB+9RHbZpCgvw69iR7WUaq4rWzwRaP2lZRa8 hLDD7Vndo8nivWcAmExCBw8LGuguTSnsKWvnLlJ0cnKZ7ZM02/kCOYXALsXYcAxPKjxd eVmN0KFwC1C66Ly9blCFEo9IyQNNDTYuf+ke/dV5TNuxieqtWHAwMfHgo+Cq87KClw7B mRVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Pa0PxMUH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m11-v6si5161493pla.639.2018.02.19.20.46.01; Mon, 19 Feb 2018 20:46:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Pa0PxMUH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751039AbeBTEoo (ORCPT + 99 others); Mon, 19 Feb 2018 23:44:44 -0500 Received: from mail-pl0-f49.google.com ([209.85.160.49]:37893 "EHLO mail-pl0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750829AbeBTEol (ORCPT ); Mon, 19 Feb 2018 23:44:41 -0500 Received: by mail-pl0-f49.google.com with SMTP id d4so583352pll.5 for ; Mon, 19 Feb 2018 20:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id; bh=cujUOofQs3FywqOLI+9HiTYUB3Pag5x3VtAjCf0+PVA=; b=Pa0PxMUHrIb4sRtVTdH2Wcj8IGDO5GNlxyAAAoCJqXW8vWtVjJZRMkJmBFkYt0GFJR lmJrjjlyTPptl+567DezT3p8/03dIAUx77w2IqYgVIOdQeVpAMROq4idGJqFYKnmABEl zpxhqLsqjn+MWc0Y7wuh1QTBuEQmC4bGC3G/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=cujUOofQs3FywqOLI+9HiTYUB3Pag5x3VtAjCf0+PVA=; b=p+dhpNCFSHOwFZkvjDp0CdvZ05ujN9BCI+456SzrqwKEHTsc9UqT+Boa1kQi/DNe8x 7gf2/W6q+R0ja41rBM9NPpZ0MEnj8fMKl6ehU0feSUfHPtDXyZl3wXRYvF3yWGuU7QdU 0wDSk6qbhxeTQm5BhP5JDif1FtukEZMMfLAPzAPFzWSCTrgN3yPLhkaNzP53lcAzAOao N0j3PIQs+F/rbx6RSwA8lKNgmyHZ2NvY6nhDx+Xw6MsRBFB95fY/XcW8h6tWrwSUVxdk ACi766nfwXCfy++3SDLqwZjo8VP46wB48azZw7z3bQZrME8tmjs2H5o6MJaQ7yU3CyFH Jy+Q== X-Gm-Message-State: APf1xPCMi7b/6y59MAbz3xB5sjaZE/wfcdGer1vuuYMM7iYJTrxNGnR6 24pQVe5NH1mp4vX8Hg7iQlpsmpBgFKc= X-Received: by 2002:a17:902:ba84:: with SMTP id k4-v6mr16084260pls.116.1519101881129; Mon, 19 Feb 2018 20:44:41 -0800 (PST) Received: from acourbot.tok.corp.google.com ([2401:fa00:4:1002:a6cd:a898:e07b:a331]) by smtp.gmail.com with ESMTPSA id q9sm783397pgs.28.2018.02.19.20.44.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 20:44:40 -0800 (PST) From: Alexandre Courbot To: Mauro Carvalho Chehab , Hans Verkuil , Laurent Pinchart , Pawel Osciak , Marek Szyprowski , Tomasz Figa , Sakari Ailus Cc: Gustavo Padovan , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Alexandre Courbot Subject: [RFCv4 00/21] Request API Date: Tue, 20 Feb 2018 13:44:04 +0900 Message-Id: <20180220044425.169493-1-acourbot@chromium.org> X-Mailer: git-send-email 2.16.1.291.g4437f3f132-goog Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi everyone, And thanks for all the feedback on the previous version! I have tried to address as much as possible, which results in (another) almost rewrite. But I think the behavior and structure are converging to something satisfying and usable. Besides the buffer queuing behavior that has been fixed, some of the big design changes undertaken are that the media controller framework is not a requirement anymore (although it can still be used in exactly the same way as before), and that ioctls related to requests are now performed directly on the request FD. As discussed with Sakari, the fact that request entities were in fact media entities was a bit limiting, so I created a request_entity type that can be embedded into any structure we want to control with requests. This is what allows drivers to support requests without the media controller: simple V4L2 drivers can use the V4L2 implementation that allows to control a single video device (as opposed to the whole pipeline under a media controller). Media controllers can still, of course, use a more complex implementation and control their whole pipeline, but bringing that complexity to simple drivers seemed overreached to me. Independently of the request implementation, request entities can store their own data, in a way that makes sense regarding their type (that would be v4l2_request_entity_data for V4L2 devices, but can be another data type for media controllers topology). The entity data lookup is also performed on these request_entities, working effectively like the data store Sakari proposed, but retaining a base type for data lookup. Patches are organized as follows: Patch 1 provides the base request support, not tied to either media or v4l2. Patches 2 to 8 are the control rework done by Hans, with an extra workaround for a bug discovered while working on vivid (see commit message for details). Patch 9 adds request support to V4L2 in the form of entity data for v4l2 devices to be used in requests, and a request manager capable of producing simple requests for video devices. Maybe this should be split into different files, but since the code is not that big I have kept it under the same file. Patches 10 to 13 add request support to vb2-core and vb2-v4l2. Patches 14 and 15 add support for the request_fd field in G/S/TRY_EXT_CTRLS ioctls. Patch 16 allows requests to be allocated from a supporting V4L2 video device node. Patches 17 and 19 add request support to mem2mem and vim2m. Patch 18 documents usage of requests with V4L2 devices. Patch 20 adds support to the vivid capture device. Finally, 21 is a WIP patch implementing request support for media controller nodes. Requests allocated that way are of a different, broader nature than V4L2 requests, and will be able to control any device managed by the controller. To allow this, request_entity is embedded into media_entity, so that media entities can be upcasted as in the previous version. Phew! That was quite long, sorry about that. As usual, simple programs demonstrating requests on vim2m and vivid are available: https://gist.github.com/Gnurou/34c35f1f8e278dad454b51578d239a42 https://gist.github.com/Gnurou/5052e6ab41e7c55164b75d2970bc5a04 If things are starting to look ok, I would like to move on to the next step and implement support in v4l2-ctl. Maybe also start submitting an actual codec driver once the control work is completed. And of course, it may be good time to think about how pipeline configuration would work. The current design should make this question orthogonal to getting support in for simple V4L2 devices. Looking forward to your feedback! Changes since RFC v3: * Buffer queuing is now performed as soon as the request is queued, allowing drivers to see them early. * Request refcounting is done using the file * structure instead of a kref * Requests can now be used independently of a media controller, to avoid having to pull it for simple codec drivers. For such drivers, the device node can allocate requests that are exclusive to this device only. Media controller nodes can still allocate requests that control their topology as well as the devices under them. * Consequently, media_request is now its own module since it can be used independently of media.ko. * SUBMIT/REINIT request ioctls are now performed on the request FD instead of the media device. This means that device/media controller node's business with requests is limited to allocating them. * Got rid of request IDs. * Only allow one buffer to be queued to each queue of request entities. * The request FD that produced a CAPTURE buffer is not returned to user-space anymore. * Added requests support for the Vivid video capture device. * Let drivers decide individually whether their entities should be per file handle or global to the device, solving the question we had about this in previous RFCs. Vim2m provides an example of per-context entities, while vivid gives an example of a global request entity. * Improved documentation. Issues remaining with this version: * Vivid support exposed what seems to be a limitation in the current controls cloning implementation. See patch 8 (which works the issue around) for details. * Media controller implementation of requests is still incomplete. I plan to complete and exert it on an actual camera driver sometime soon. Alexandre Courbot (14): media: add request API core and UAPI [WAR] v4l2-ctrls: do not clone non-standard controls v4l2: add request API support media: v4l2_fh: add request entity field media: videobuf2: add support for requests media: videobuf2-v4l2: support for requests videodev2.h: add request_fd field to v4l2_ext_controls v4l2-ctrls: support requests in EXT_CTRLS ioctls v4l2: video_device: support for creating requests media: mem2mem: support for requests Documentation: v4l: document request API media: vim2m: add request support media: vivid: add request support for the video capture device [WIP] media: media-device: support for creating requests Hans Verkuil (7): v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev v4l2-ctrls: prepare internal structs for request API v4l2-ctrls: add core request API v4l2-ctrls: use ref in helper instead of ctrl v4l2-ctrls: support g/s_ext_ctrls for requests v4l2-ctrls: add v4l2_ctrl_request_setup videodev2.h: Add request_fd field to v4l2_buffer Documentation/ioctl/ioctl-number.txt | 1 + Documentation/media/uapi/v4l/buffer.rst | 9 +- Documentation/media/uapi/v4l/common.rst | 1 + Documentation/media/uapi/v4l/request-api.rst | 199 ++++++++++ Documentation/media/uapi/v4l/user-func.rst | 1 + .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 16 +- .../media/uapi/v4l/vidioc-new-request.rst | 64 ++++ Documentation/media/uapi/v4l/vidioc-qbuf.rst | 7 + drivers/media/Kconfig | 3 + drivers/media/Makefile | 6 + .../media/common/videobuf2/videobuf2-core.c | 3 + .../media/common/videobuf2/videobuf2-v4l2.c | 131 ++++++- drivers/media/dvb-frontends/rtl2832_sdr.c | 5 +- drivers/media/media-device.c | 11 + drivers/media/media-request.c | 341 +++++++++++++++++ drivers/media/pci/bt8xx/bttv-driver.c | 2 +- drivers/media/pci/cx23885/cx23885-417.c | 2 +- drivers/media/pci/cx88/cx88-blackbird.c | 2 +- drivers/media/pci/cx88/cx88-video.c | 2 +- drivers/media/pci/saa7134/saa7134-empress.c | 4 +- drivers/media/pci/saa7134/saa7134-video.c | 2 +- drivers/media/platform/Kconfig | 1 + .../media/platform/exynos4-is/fimc-capture.c | 2 +- drivers/media/platform/omap3isp/ispvideo.c | 2 +- drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 +- drivers/media/platform/rcar_drif.c | 2 +- .../media/platform/soc_camera/soc_camera.c | 3 +- drivers/media/platform/vim2m.c | 75 ++++ drivers/media/platform/vivid/Kconfig | 1 + drivers/media/platform/vivid/vivid-core.c | 63 +++- drivers/media/platform/vivid/vivid-core.h | 3 + drivers/media/platform/vivid/vivid-ctrls.c | 46 +-- .../media/platform/vivid/vivid-kthread-cap.c | 17 + drivers/media/usb/cpia2/cpia2_v4l.c | 2 +- drivers/media/usb/cx231xx/cx231xx-417.c | 2 +- drivers/media/usb/cx231xx/cx231xx-video.c | 4 +- drivers/media/usb/msi2500/msi2500.c | 2 +- drivers/media/usb/tm6000/tm6000-video.c | 2 +- drivers/media/v4l2-core/Makefile | 1 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 9 +- drivers/media/v4l2-core/v4l2-ctrls.c | 341 +++++++++++++++-- drivers/media/v4l2-core/v4l2-dev.c | 2 + drivers/media/v4l2-core/v4l2-device.c | 3 +- drivers/media/v4l2-core/v4l2-ioctl.c | 37 +- drivers/media/v4l2-core/v4l2-mem2mem.c | 3 +- drivers/media/v4l2-core/v4l2-request.c | 178 +++++++++ drivers/media/v4l2-core/v4l2-subdev.c | 2 +- drivers/staging/media/imx/imx-media-dev.c | 2 +- drivers/staging/media/imx/imx-media-fim.c | 2 +- include/media/mc-request.h | 33 ++ include/media/media-device.h | 1 + include/media/media-entity.h | 5 + include/media/media-request.h | 349 ++++++++++++++++++ include/media/v4l2-ctrls.h | 20 +- include/media/v4l2-dev.h | 2 + include/media/v4l2-fh.h | 3 + include/media/v4l2-request.h | 159 ++++++++ include/media/videobuf2-core.h | 4 + include/media/videobuf2-v4l2.h | 59 +++ include/uapi/linux/media-request.h | 37 ++ include/uapi/linux/media.h | 2 + include/uapi/linux/videodev2.h | 9 +- 62 files changed, 2217 insertions(+), 88 deletions(-) create mode 100644 Documentation/media/uapi/v4l/request-api.rst create mode 100644 Documentation/media/uapi/v4l/vidioc-new-request.rst create mode 100644 drivers/media/media-request.c create mode 100644 drivers/media/v4l2-core/v4l2-request.c create mode 100644 include/media/mc-request.h create mode 100644 include/media/media-request.h create mode 100644 include/media/v4l2-request.h create mode 100644 include/uapi/linux/media-request.h -- 2.16.1.291.g4437f3f132-goog