Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753129AbdDJWxm (ORCPT ); Mon, 10 Apr 2017 18:53:42 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:35749 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751564AbdDJWxk (ORCPT ); Mon, 10 Apr 2017 18:53:40 -0400 To: linux-media@vger.kernel.org Subject: [media] vimc: API proposal, configuring the topology from user space Cc: Laurent Pinchart , Mauro Carvalho Chehab , Sakari Ailus , Hans Verkuil , Jeremy Gebben , linux-kernel@vger.kernel.org From: Helen Koike Message-ID: Date: Mon, 10 Apr 2017 19:53:30 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5449 Lines: 149 Hi, Continuing the discussion about the API of the vimc driver, I made some changes based on the previous comments, please see below and let me know your opinion about it. Helen /*********************** Configfs considerations: ************************/ Informal definitions: subsystem: the root driver folder in user space (/configfs/vimc) item: aka a folder in user space attributes: aka files in the folder group: aka a folder that can contain subfolders (parent and child relation) default group: aka a subfolder that is created automatically when the "parent" folder is created it is not considered a child in terms of rmdir * Performing rmdir in a group will fail if it contain children that are not default groups, i.e, if the folder contain subfolders that are default group, then it can be removed with rmdir, if the subfolders were created with mkdir, then rmdir in the parent will fail. * Configfs has the notion of committable item but it is not implemented yet. A committable item is an item that can be in one of two parent folders called: live and pending. The idea is to create and modify the item in the pending directory and then to move the item through a rename to the live directory where it can't be modified. This seems to be a nice feature for vimc, but as it is not available yet the proposal below won't be based on this. * Groups can be dynamically created/destroyed by the driver whenever it wants. Afaik attributes can only be created when the group or item is created and symlinks can only be create from user space, i.e, the driver don't know how to create/destroy attributes or symlinks in anytime. /*********************** The API: ************************/ In short, a topology like this one: http://goo.gl/Y7eUfu Would look like this filesystem tree: https://goo.gl/mEOmOf v3 core changes: - I removed the use of symlinks as I wans't able to see how to do it nicely. - I use the names of the folders created by user space to retrieve information at mkdir time - hotplug file in each entity - hotplug file in each device - reset file in each device * The /configfs/vimc subsystem empty when the driver is loaded * Create a device Userspace can create a new vimc device with: $ mkdir /configfs/vimc/any_name Example: $ mkdir /configfs/vimc/vimc0 $ ls -l /configfs/vimc/vimc0 hotplug reset entities/ links/ entities/ and links/ folder are default groups, thus they don't prevent rmdir vimc0/, but rmdir will fail if it has any child inside entities/ or links/. hotplug is used to plug and unplug the device, it can read "plugged" or "unplugged" and user can write "plug" or "unplug" to change its state. Changing hotplug state will never fail as the configfs tree will always be in a valid state. reset is used to easily destroy all the topology without the need to walk through all the children to perform rmdir, writing 1 to reset file will set hotplug to "unplugged" and erase all folders under entities/ and links/. * Create an entity Userspace can create a new entity with: $ mkdir /configfs/vimc/vimc0/entities/: Example: $ mkdir /configfs/vimc/vimc0/entities/sensor:SensorA $ ls -l /configfs/vimc/vimc0/entities/sensor:SensorA hotplug pad:source:0/ The name of the folder needs to be in the format : or it will be rejected, this allows the creation of the right pads according to its role at mkdir time, eliminating the previously proposed role and name files. hotplug is used to plug and unplug the hw block, it can read "plugged" or "unplugged" and user can write "plug" or "unplug" to change its state. As we don't support this yet in the media core, changing it will only be allowed if /configfs/vimc/vimc0/hotplug is "unplugged". hotplug file is "unplugged" by default. Pads will be created as default groups with the name in the format pad:: and it will be an empty folder. If the hw block supports different number of pads, we could expose two files: sinks sources where the user space can write the desired number of sink and source pads and the driver will dynamically create the folders pad:: * Create a link User space can create a link between two entities with: $ mkdir /configfs/vimc/vimc0/links/:->: Example: $ mkdir /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0 $ ls -l /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0 flags mkdir will be rejected if folder is not on the format :->:. mkdir will be rejected if either or are not found in /configfs/vimc/vimc0/entities/ The link will only be created if both entities are in "plugged" state. When an entity is removed from /configfs/vimc/vimc0/entities/ with rmdir, its corresponding link folders at /configfs/vimc/vimc0/links will be automatically removed. If one of the entities changes from "plugged" to "unplugged", the link is only removed from the media representation, the link folder won't be removed. flags can be one of "", "enabled", "immutable", "dynamic", "dynamic,enabled". flags cannot be changed if the link was already created in the media controller, to alter it unplug the device through /configfs/vimc/vimc0/hotplug or unplug one of the source or sink entities connected to the link through its hotplug file. flags are of type "" by default.