From patchwork Fri Sep 28 10:07:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans Verkuil X-Patchwork-Id: 10619339 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E6225180E for ; Fri, 28 Sep 2018 10:07:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DA5582AFF8 for ; Fri, 28 Sep 2018 10:07:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CE2AF2B251; Fri, 28 Sep 2018 10:07:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4D21E2AFF8 for ; Fri, 28 Sep 2018 10:07:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729251AbeI1Qat (ORCPT ); Fri, 28 Sep 2018 12:30:49 -0400 Received: from lb1-smtp-cloud9.xs4all.net ([194.109.24.22]:38133 "EHLO lb1-smtp-cloud9.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729141AbeI1Qat (ORCPT ); Fri, 28 Sep 2018 12:30:49 -0400 Received: from test-nl.fritz.box ([80.101.105.217]) by smtp-cloud9.xs4all.net with ESMTPA id 5pgXgEDPBS9Y35pgYg1M6k; Fri, 28 Sep 2018 12:07:46 +0200 From: Hans Verkuil To: linux-media@vger.kernel.org Subject: [RFCv3 PATCH 0/3] Media Controller Properties Date: Fri, 28 Sep 2018 12:07:42 +0200 Message-Id: <20180928100745.4946-1-hverkuil@xs4all.nl> X-Mailer: git-send-email 2.19.0 MIME-Version: 1.0 X-CMAE-Envelope: MS4wfHGSTjKKaR3xexiTxg8vafTDIpWIvQzWwkMfOuxz1G4bFSNG185WfOJsPHJJvk0sgLV3g3KRr4UrTYyS95PQr3iZWKFFJ5bM4NsG7XVryevgjrVYQU9/ 66NCWF+WNki16P3ZqVG4EC4du0iZMSS8uzjuuaPP4CSuPREuKP9q7AllT/SAgzz4GkAicTwIaJR2kQ== Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Hans Verkuil This RFC patch series implements properties for the media controller. The main changes since RFCv2 are: - Properties can be nested. - G_TOPOLOGY sets flags to indicate if there are pads/links/properties for the objects. And it adds index fields to provide a quick lookup. Effectively the topology arrays now represent a flattened tree. An updated v4l2-ctl and v4l2-compliance that can report properties is available here: https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=props Currently I support u64, s64 and const char * property types. And also a 'group' type that groups sub-properties. But it can be extended to any type including binary data if needed. No array support (as we have for controls), but there are enough reserved fields in media_v2_prop to add this if needed. I added properties for entities and pads to vimc, so I could test this. Note that the changes to media_device_get_topology() are hard to read from the patch. It is easier to just look at the source code: https://git.linuxtv.org/hverkuil/media_tree.git/tree/drivers/media/media-device.c?h=mc-props I have some ideas to improve this some more: 1) Add the properties directly to media_gobj. This would simplify some of the code, but it would require a media_gobj_init function to initialize the property list. In general I am a bit unhappy about media_gobj_create: it doesn't really create the graph object, instead it just adds it to the media_device. It's confusing and it is something I would like to change. 2) The links between pads are stored in media_entity instead of in media_pad. This is a bit unexpected and makes it harder to traverse the data structures since to find the links for a pad you need to walk the entity links and find the links for that pad. Putting all links in the entity also mixes up pad and interface links, and it would be much cleaner if those are separated. 3) While it is easy to find the pads and links for an entity through the new pad and link index fields, the reverse is not true: i.e. media_v2_pad refers to the entity by entity ID, and that would require walking through all entities to find which one it is. I propose adding an entity_idx field as well (and similar to media_v2_links and media_v2_prop) to make it easy to look up the parent object. It's trivial to add in the kernel and makes life much easier for userspace. 4) I still think adding support for backlinks to G_TOPOLOGY is a good idea. Since the current data structure represents a flattened tree that is easy to navigate the only thing missing for userspace is backlink support. This is still something that userspace needs to figure out when the kernel has this readily available. I think that with this in place applications can just do all the lookups directly on the topology data structure. Regards, Hans Hans Verkuil (3): uapi/linux/media.h: add property support media controller: add properties support vimc: add property test code drivers/media/media-device.c | 324 +++++++++++++++++----- drivers/media/media-entity.c | 107 ++++++- drivers/media/platform/vimc/vimc-common.c | 50 ++++ include/media/media-device.h | 6 + include/media/media-entity.h | 315 +++++++++++++++++++++ include/uapi/linux/media.h | 71 ++++- 6 files changed, 790 insertions(+), 83 deletions(-)