Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp780425ybl; Fri, 10 Jan 2020 06:37:20 -0800 (PST) X-Google-Smtp-Source: APXvYqxCn1ALjwO0XQri37D4FKIREqfQAzNxnN+Ygb3t2XSET4Y/x6DEII20+cXUVU+niNYOssbd X-Received: by 2002:a9d:811:: with SMTP id 17mr2930411oty.369.1578667039931; Fri, 10 Jan 2020 06:37:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578667039; cv=none; d=google.com; s=arc-20160816; b=UfF727aR2Zo0s8YUL7sUufkU0JG6dc+DBNA3xMd0PwRO+di8ufguhhqprnMiE7/dAQ ZxJSBuNbwTG96thAxuSAN0QhoAd4obiN5DemXXUjDDZzoqb3fNb23rtmgUx2QVufscOc xKv0S4CgxvLyQgwCpoP1dIU+Pni/kPm5yVlGVvr3h8SYy+wqGStpeHjAZ4Ol0IG6SbCt dfXnpuQpip1O9NUerPYMvaKz+kGQ/yDa8A6LimnGP3qKT0er/dC951QcqEsqJbxeIBVP DGqzwqTy5SrEhFQ2NSElWkJyckeIMzFjra2brIAk3v1vDE57sOMBQXbVBhthkEL0jCFi RG2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=fR6lP1zgvDKu/Vk7f95tLyKjHNECmLy4ZODwU6XXvRk=; b=ayMqsPIK2pFltfht8wL1sttg7GELjSxXeheT2QMIpEa/0RcWSYx1ditIHm84001mdA 33jH+8m3eNKbSyeZOsdC2ijrgd/2Ju8bG210fE7QTL9BrGccq2U0aHD66qb8aMbiFG/s G/Hp8ZLn0RyE11+qBjWyYj58sujTZ1qRUZtFObg9Tb1WAAfjIz1o7nf79sCv6MrUUANg Rh1JvuhWu/L11fOAhzwPXcrDg3XwFd9le41GNASc1KvX4X1SFZf+fQbw1hbw9JTqHXa8 Lh5e9Z/p1BDeLskzDRdS715Bzso5dhvC1rJ84QyNPGHqfBj1eg1gdRrHKxd3lftD5Ov+ 8/uQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@raspberrypi.com header.s=google header.b=oMKyFTUn; 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=raspberrypi.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 25si1117229oix.178.2020.01.10.06.37.07; Fri, 10 Jan 2020 06:37:19 -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=@raspberrypi.com header.s=google header.b=oMKyFTUn; 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=raspberrypi.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727892AbgAJOf7 (ORCPT + 99 others); Fri, 10 Jan 2020 09:35:59 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:39194 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727581AbgAJOf6 (ORCPT ); Fri, 10 Jan 2020 09:35:58 -0500 Received: by mail-wr1-f67.google.com with SMTP id y11so2026771wrt.6 for ; Fri, 10 Jan 2020 06:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fR6lP1zgvDKu/Vk7f95tLyKjHNECmLy4ZODwU6XXvRk=; b=oMKyFTUnPn8RNJpLhn1q02KOjxZJlZZ9VPykA25mq7Qu2JP+ihwHk0gSWGLtpxMDz2 /AQfwwbC0TD/nXTTKi57chkFmPcoxO7vB8UkXx8YLSu1qkSDKVXKAIQHE4L4mtNkUK6B EEQjSgImvLDw8OhHqbgHe4K+SgwLMVLzgxRjolX/wSuQyynOf587dS5kGTkkrmHUIHlM /B/MDdLk0zENjZMUh1aBEDzP1Bbb2VgndUwbPqka0QYTdhNNZNEaKohUSiUYK8Bwh1uh hZTG7FonKTzkOi85mDmfoak7tBoRe7uxQ/W+MYnSKt+ABcPjCvy048Uy1gZbt/SUVS7z OCZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fR6lP1zgvDKu/Vk7f95tLyKjHNECmLy4ZODwU6XXvRk=; b=XmSzAGdB/s9T/wyOxrsgnTjZJhr0PoUD9AKNRRz4BuvjAgmwQqDEI2YIexb80Ibbgm Wr+RqDOI9+VVvTkSFzcPL1sArclEotekKjxIqunCZado8PDFYfOl8ymINcfBSMcqbl7x DrWANHKEcumBL2Mp26YXoqlceWg5vnnOtiqYcjz/Na6Ns7YRiFQuykYdlSqxRlTvkxtN HP24hJ8Ngva12rom4i2YcwRIdio8Oqr5EFQpDzoXVALwnHT3nhqEQ4xXO+R5mXs3B4ee vjxQEfVvf0aJFJ38HkyUzqtumaL7URckg62I5tBsen6olT6meCpB9KadSKfsFh4KVa+e vn3w== X-Gm-Message-State: APjAAAUQtJ6KX0I5qO6tstOyluDwgGPeIUa6cYrrzbZjcOSy8fStIipN H6KvKBDRYjSUVVkui9FiDw4L2JUT3wdUmMcXMCYi3LFJKLSAtg== X-Received: by 2002:adf:fc4b:: with SMTP id e11mr3904527wrs.326.1578666956616; Fri, 10 Jan 2020 06:35:56 -0800 (PST) MIME-Version: 1.0 References: <20191206085432.19962-1-michael.kupfer@fau.de> <3db2350b-0a6d-0693-258c-9d47f71c0627@xs4all.nl> In-Reply-To: <3db2350b-0a6d-0693-258c-9d47f71c0627@xs4all.nl> From: Dave Stevenson Date: Fri, 10 Jan 2020 14:35:38 +0000 Message-ID: Subject: Re: [PATCH] staging/vc04_services/bcm2835-camera: distinct numeration and names for devices To: Hans Verkuil Cc: Michael Kupfer , eric@anholt.net, wahrenst@gmx.net, bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, mchehab+samsung@kernel.org, linux-media@vger.kernel.org, gregkh@linuxfoundation.org, f.fainelli@gmail.com, rjui@broadcom.com, sbranden@broadcom.com, Dave Stevenson , daniela.mormocea@gmail.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, linux-kernel@i4.cs.fau.de, Kay Friedrich Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hans On Fri, 10 Jan 2020 at 13:25, Hans Verkuil wrote: > > Hi Michael, Kay, > > On 12/6/19 9:54 AM, Michael Kupfer wrote: > > Create a static atomic counter for numerating cameras. > > Use the Media Subsystem Kernel Internal API to create distinct > > device-names, so that the camera-number (given by the counter) > > matches the camera-name. > > > > Co-developed-by: Kay Friedrich > > Signed-off-by: Kay Friedrich > > Signed-off-by: Michael Kupfer > > --- > > .../vc04_services/bcm2835-camera/bcm2835-camera.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c > > index beb6a0063bb8..be5f90a8b49d 100644 > > --- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c > > +++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c > > @@ -60,6 +60,9 @@ MODULE_PARM_DESC(max_video_width, "Threshold for video mode"); > > module_param(max_video_height, int, 0644); > > MODULE_PARM_DESC(max_video_height, "Threshold for video mode"); > > > > +/* camera instance counter */ > > +static atomic_t camera_instance = ATOMIC_INIT(0); > > + > > /* global device data array */ > > static struct bm2835_mmal_dev *gdev[MAX_BCM2835_CAMERAS]; > > > > @@ -1870,7 +1873,6 @@ static int bcm2835_mmal_probe(struct platform_device *pdev) > > > > /* v4l2 core mutex used to protect all fops and v4l2 ioctls. */ > > mutex_init(&dev->mutex); > > - dev->camera_num = camera; > > dev->max_width = resolutions[camera][0]; > > dev->max_height = resolutions[camera][1]; > > > > @@ -1886,8 +1888,9 @@ static int bcm2835_mmal_probe(struct platform_device *pdev) > > dev->capture.fmt = &formats[3]; /* JPEG */ > > > > /* v4l device registration */ > > - snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name), > > - "%s", BM2835_MMAL_MODULE_NAME); > > + dev->camera_num = v4l2_device_set_name(&dev->v4l2_dev, > > + BM2835_MMAL_MODULE_NAME, > > + &camera_instance); > > ret = v4l2_device_register(NULL, &dev->v4l2_dev); > > if (ret) { > > dev_err(&pdev->dev, "%s: could not register V4L2 device: %d\n", > > > > Actually, in this specific case I would not use v4l2_device_set_name(). > > Instead just use: > > snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name), > "%s-%u", BM2835_MMAL_MODULE_NAME, camera); > > It would be even better if there would be just one top-level v4l2_device used > for all the camera instances. After all, there really is just one platform > device for all of the cameras, and I would expect to see just a single > v4l2_device as well. > > It doesn't hurt to have multiple v4l2_device structs, but it introduces a > slight memory overhead since one would have been sufficient. Doesn't that make all controls for all cameras common? The struct v4l2_ctrl_handler is part of struct v4l2_device. Or do we: - ditch the use of ctrl_handler in struct v4l2_device - create and initialise a ctrl_handler per camera on an internal structure so we retain the control state - assign ctrl_handler in struct v4l2_fh to it every time a file handle on the device is opened? And if we only have one struct v4l2_device then is there the possibility of the unique names that Michael and Kay are trying to introduce? I'm a little confused as to whether there really is a gain in having a single v4l2_device. In this case the two cameras are independent devices, even if they are loaded by a single platform driver. Dave > v4l2_device_set_name() is meant for pci-like devices. And it really > is a bit overkill to have it as a helper function. > > Regards, > > Hans