From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mailout1.w2.samsung.com ([211.189.100.11]:18052 "EHLO usmailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751624AbaAMRX7 (ORCPT ); Mon, 13 Jan 2014 12:23:59 -0500 Received: from uscpsbgm1.samsung.com (u114.gpu85.samsung.co.kr [203.254.195.114]) by mailout1.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MZC00GFSOBX5N70@mailout1.w2.samsung.com> for linux-media@vger.kernel.org; Mon, 13 Jan 2014 12:23:58 -0500 (EST) Date: Mon, 13 Jan 2014 15:23:50 -0200 From: Mauro Carvalho Chehab To: Hans Verkuil Cc: linux-media@vger.kernel.org, Hans Verkuil Subject: Re: [RFC PATCH 3/6] DocBook media: partial rewrite of "Opening and Closing Devices" Message-id: <20140113152350.1ab23491@samsung.com> In-reply-to: <52D4112C.5040902@xs4all.nl> References: <1389100017-42855-1-git-send-email-hverkuil@xs4all.nl> <1389100017-42855-4-git-send-email-hverkuil@xs4all.nl> <20140113132013.06f558a0@samsung.com> <52D4112C.5040902@xs4all.nl> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: Em Mon, 13 Jan 2014 17:15:40 +0100 Hans Verkuil escreveu: > On 01/13/2014 04:20 PM, Mauro Carvalho Chehab wrote: > > Em Tue, 7 Jan 2014 14:06:54 +0100 > > Hans Verkuil escreveu: > > > >> From: Hans Verkuil > >> > >> This section was horribly out of date. A lot of references to old and > >> obsolete behavior have been dropped. Forgot to mention, put patches 1 and 2 are ok. I'll review the patches 4-6 later this week. > >> > >> Signed-off-by: Hans Verkuil > >> --- > >> Documentation/DocBook/media/v4l/common.xml | 188 ++++++++++------------------- > >> 1 file changed, 67 insertions(+), 121 deletions(-) > >> > >> diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml > >> index 1ddf354..da08df9 100644 > >> --- a/Documentation/DocBook/media/v4l/common.xml > >> +++ b/Documentation/DocBook/media/v4l/common.xml > >> @@ -38,70 +38,41 @@ the basic concepts applicable to all devices. > >> > >> V4L2 drivers are implemented as kernel modules, loaded > >> manually by the system administrator or automatically when a device is > >> -first opened. The driver modules plug into the "videodev" kernel > >> +first discovered. The driver modules plug into the "videodev" kernel > >> module. It provides helper functions and a common application > >> interface specified in this document. > >> > >> Each driver thus loaded registers one or more device nodes > >> -with major number 81 and a minor number between 0 and 255. Assigning > >> -minor numbers to V4L2 devices is entirely up to the system administrator, > >> -this is primarily intended to solve conflicts between devices. > >> - Access permissions are associated with character > >> -device special files, hence we must ensure device numbers cannot > >> -change with the module load order. To this end minor numbers are no > >> -longer automatically assigned by the "videodev" module as in V4L but > >> -requested by the driver. The defaults will suffice for most people > >> -unless two drivers compete for the same minor numbers. > >> - The module options to select minor numbers are named > >> -after the device special file with a "_nr" suffix. For example "video_nr" > >> -for /dev/video video capture devices. The number is > >> -an offset to the base minor number associated with the device type. > >> - > >> - In earlier versions of the V4L2 API the module options > >> -where named after the device special file with a "unit_" prefix, expressing > >> -the minor number itself, not an offset. Rationale for this change is unknown. > >> -Lastly the naming and semantics are just a convention among driver writers, > >> -the point to note is that minor numbers are not supposed to be hardcoded > >> -into drivers. > >> - When the driver supports multiple devices of the same > >> -type more than one minor number can be assigned, separated by commas: > >> - > >> +with major number 81 and a minor number between 0 and 255. Minor numbers > >> +are allocated dynamically unless the kernel is compiled with the kernel > >> +option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are > >> +allocated in ranges depending on the device node type (video, radio, etc.). > >> + > >> + Many drivers support "video_nr", "radio_nr" or "vbi_nr" > >> +module options to select specific video/radio/vbi node numbers. This allows > >> +the user to request that the device node is named e.g. /dev/video5 instead > >> +of leaving it to chance. When the driver supports multiple devices of the same > >> +type more than one device node number can be assigned, separated by commas: > >> + > >> > >> -> insmod mydriver.o video_nr=0,1 radio_nr=0,1 > >> +> modprobe mydriver video_nr=0,1 radio_nr=0,1 > >> > >> > >> In /etc/modules.conf this may be > >> written as: > >> > >> -alias char-major-81-0 mydriver > >> -alias char-major-81-1 mydriver > >> -alias char-major-81-64 mydriver > >> -options mydriver video_nr=0,1 radio_nr=0,1 > >> +options mydriver video_nr=0,1 radio_nr=0,1 > >> > >> - > >> - > >> - When an application attempts to open a device > >> -special file with major number 81 and minor number 0, 1, or 64, load > >> -"mydriver" (and the "videodev" module it depends upon). > >> - > >> - > >> - Register the first two video capture devices with > >> -minor number 0 and 1 (base number is 0), the first two radio device > >> -with minor number 64 and 65 (base 64). > >> - > >> - > >> - When no minor number is given as module > >> -option the driver supplies a default. > >> -recommends the base minor numbers to be used for the various device > >> -types. Obviously minor numbers must be unique. When the number is > >> -already in use the offending device will not be > >> -registered. > >> - > >> - By convention system administrators create various > >> -character device special files with these major and minor numbers in > >> -the /dev directory. The names recommended for the > >> -different V4L2 device types are listed in . > >> + When no device node number is given as module > >> +option the driver supplies a default. > >> + > >> + Normally udev will create the device nodes in /dev automatically > >> +for you. If udev is not installed, then you need to enable the > >> +CONFIG_VIDEO_FIXED_MINOR_RANGES kernel option in order to be able to correctly > >> +relate a minor number to a device node number. I.e., you need to be certain > >> +that minor number 5 maps to device node name video5. With this kernel option > >> +different device types have different minor number ranges. These ranges are > >> +listed in . > >> > >> > >> The creation of character special files (with > >> @@ -110,63 +81,40 @@ devices cannot be opened by major and minor number. That means > >> applications cannot reliable scan for loaded or > >> installed drivers. The user must enter a device name, or the > >> application can try the conventional device names. > >> - > >> - Under the device filesystem (devfs) the minor number > >> -options are ignored. V4L2 drivers (or by proxy the "videodev" module) > >> -automatically create the required device files in the > >> -/dev/v4l directory using the conventional device > >> -names above. > >> > >> > >> > >> > >>
> >> @@ -176,19 +124,22 @@ mailing list: &v4l-ml;. > >> When this is supported by the driver, users can for example start a > >> "panel" application to change controls like brightness or audio > >> volume, while another application captures video and audio. In other words, panel > >> -applications are comparable to an OSS or ALSA audio mixer application. > >> -When a device supports multiple functions like capturing and overlay > >> -simultaneously, multiple opens allow concurrent > >> -use of the device by forked processes or specialized applications. > >> - > >> - Multiple opens are optional, although drivers should > >> -permit at least concurrent accesses without data exchange, &ie; panel > >> -applications. This implies &func-open; can return an &EBUSY; when the > >> -device is already in use, as well as &func-ioctl; functions initiating > >> -data exchange (namely the &VIDIOC-S-FMT; ioctl), and the &func-read; > >> -and &func-write; functions. > >> - > >> - Mere opening a V4L2 device does not grant exclusive > >> +applications are comparable to an ALSA audio mixer application. > >> +Just opening a V4L2 device should not change the state of the device. > >> +Unfortunately, opening a radio device often switches the state of the > >> +device to radio mode in many drivers. > > > > This is an API spec document. It should say what is the expected behavior, > > and not mention non-compliant stuff. > > How about putting this in a footnote? I do agree with you, but the fact is > that most if not all drivers that support both radio and video behave this > way. So one could argue that it is the spec that is non-compliant :-) If so, let's then fix the API to reflect that opening a radio device will change the behavior. > > That said, at some point this should be fixed. Yes. one way or the other. > > > >> + > >> + Almost all drivers allow multiple opens although there are > >> +still some old drivers that have not been updated to allow this. > >> +This implies &func-open; can return an &EBUSY; when the > >> +device is already in use. > > > > What drivers? We should fix the driver, not the API doc. > > vino.c (I do have fixes for this in an old branch), timblogiw.c, fsl-viu.c. > There are probably a few more. Generally such drivers are old and/or obscure. Maybe in this specific case, a footnote could be added, although the better would be to simply fix or remove/move to staging those drivers. > Since I am still working (slowly) on converting drivers to the modern frameworks > I'll come across these eventually. > > > Also, we need more discussions. It could make sense to return EBUSY > > even on new drivers, for example, if they're already in usage by some > > other broadcast type? > > You are not using it until you actually start streaming (or allocating buffers, > or whatever). There is no reason within the current framework to return EBUSY > for just opening a device node. > > Not being able to open a device node a second time makes it impossible to > create e.g. monitoring applications that do something when an event happens. Agreed. > > > >> + > >> + It is never possible to start streaming when > >> +streaming is already in progress. So &func-ioctl; functions initiating > >> +data exchange (e.g. the &VIDIOC-STREAMON; ioctl), and the &func-read; > >> +and &func-write; functions can return an &EBUSY;. > > > > Here, the Overlay is a somewhat an exception, not in the sense that > > they'll call streamon latter, but in the sense that overlay ioctls > > can happen after streaming. > > I'll make a note of that. > > > I don't remember well how DMA buf works, > > but I think you can also start to use a mmaped copy of the dma buffers > > after start streaming. > > Possibly, but that has nothing to do with this paragraph. Once a file > handle calls STREAMON, then no other file handle of the same device node > can call STREAMON, unless the owner stops streaming and releases all > resources (REQBUFS(0)). Well, then the paragraph text is not quite right, as it mentions "initiating data exchange". If one mmaps memory latter to use it on an already started DMA buffer, it is initiating the "memory copy" data exchange with the mmap. STREAMON is just one of the ways to initiate a data exchange. > > > >> + > >> + Merely opening a V4L2 device does not grant exclusive > >> access. > >> Drivers could recognize the > >> O_EXCL open flag. Presently this is not required, > >> @@ -206,12 +157,7 @@ additional access privileges using the priority mechanism described in > >> V4L2 drivers should not support multiple applications > >> reading or writing the same data stream on a device by copying > >> buffers, time multiplexing or similar means. This is better handled by > >> -a proxy application in user space. When the driver supports stream > >> -sharing anyway it must be implemented transparently. The V4L2 API does > >> -not specify how conflicts are solved. > >> +a proxy application in user space. > >>
> >> > >>
> > > > > > Thanks! > > Hans -- Cheers, Mauro