[PATCH] drivers/media/video/v4l2-compat-ioctl32.c: Check the return value of copy_to_user
This fix the following warning: drivers/media/video/v4l2-compat-ioctl32.c: In function ‘get_microcode32’: drivers/media/video/v4l2-compat-ioctl32.c:209: warning: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result Signed-off-by: Thiago Farina --- drivers/media/video/v4l2-compat-ioctl32.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/v4l2-compat-ioctl32.c b/drivers/media/video/v4l2-compat-ioctl32.c index e30e8df..55825ec 100644 --- a/drivers/media/video/v4l2-compat-ioctl32.c +++ b/drivers/media/video/v4l2-compat-ioctl32.c @@ -206,7 +206,9 @@ static struct video_code __user *get_microcode32(struct video_code32 *kp) * user address is invalid, the native ioctl will do * the error handling for us */ - (void) copy_to_user(up->loadwhat, kp->loadwhat, sizeof(up->loadwhat)); + if (copy_to_user(up->loadwhat, kp->loadwhat, sizeof(up->loadwhat))) + return NULL; + (void) put_user(kp->datasize, &up->datasize); (void) put_user(compat_ptr(kp->data), &up->data); return up; -- 1.7.3.2.343.g7d43d -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl
On Sat, Dec 18, 2010 at 6:31 AM, Hans Verkuil wrote: > Hi all, > > Now that the BKL patch series has been merged in 2.6.37 it is time to work > on replacing .ioctl by .unlocked_ioctl in all v4l drivers. > > I've made an inventory of all drivers that still use .ioctl and I am looking > for volunteers to tackle one or more drivers. > > I have CCed this email to the maintainers of the various drivers (if I know > who it is) in the hope that we can get this conversion done as quickly as > possible. > > If I have added your name to a driver, then please confirm if you are able to > work on it or not. If you can't work on it, but you know someone else, then > let me know as well. > > There is also a list of drivers where I do not know who can do the conversion. > If you can tackle one or more of those, please respond. Unfortunately, those > are among the hardest to convert :-( > > It would be great if we can tackle most of these drivers for 2.6.38. I think > we should finish all drivers for 2.6.39 at the latest. > > There are two ways of doing the conversion: one is to do all the locking > within > the driver, the other is to use core-assisted locking. How to do the > core-assisted > locking is described in Documentation/video4linux/v4l2-framework.txt, but I'll > repeat the relevant part here: > > v4l2_file_operations and locking > > > You can set a pointer to a mutex_lock in struct video_device. Usually this > will be either a top-level mutex or a mutex per device node. If you want > finer-grained locking then you have to set it to NULL and do you own locking. > > If a lock is specified then all file operations will be serialized on that > lock. If you use videobuf then you must pass the same lock to the videobuf > queue initialize function: if videobuf has to wait for a frame to arrive, then > it will temporarily unlock the lock and relock it afterwards. If your driver > also waits in the code, then you should do the same to allow other processes > to access the device node while the first process is waiting for something. > > The implementation of a hotplug disconnect should also take the lock before > calling v4l2_device_disconnect. > > > Driver list: > > saa7146 (Hans Verkuil) > mem2mem_testdev (Pawel Osciak or Marek Szyprowski) > cx23885 (Steve Toth) > cx18-alsa (Andy Walls) > omap24xxcam (Sakari Ailus or David Cohen) > au0828 (Janne Grunau) > cpia2 (Andy Walls or Hans Verkuil) > cx231xx (Mauro Carvalho Chehab) > davinci (Muralidharan Karicheri) > saa6588 (Hans Verkuil) > pvrusb2 (Mike Isely) > usbvision (Hans Verkuil) > s5p-fimc (Sylwester Nawrocki) > fsl-viu (Anatolij Gustschin) > tlg2300 (Mauro Carvalho Chehab) > zr364xx (Hans de Goede) > soc_camera (Guennadi Liakhovetski) > usbvideo/vicam (Hans de Goede) > s2255drv (Pete Eberlein) > bttv (Mauro Carvalho Chehab) > stk-webcam (Hans de Goede) > se401 (Hans de Goede) > si4713-i2c (Hans Verkuil) > dsbr100 (Hans Verkuil) There are patches for dsbr100 here: http://desource.dyndns.org/~atog/gitweb/?p=linux-media.git These patches don't use the new core-assisted locking as they were written back in MAY, but they DO remove the BKL from the driver. The patches have been compile tested only, as I do not have access to a device for this driver. > > Staging driver list: > > go7007 (Pete Eberlein) > tm6000 (Mauro Carvalho Chehab) > (stradis/cpia: will be removed in 2.6.38, so no need to do anything) > > Unassigned drivers: > > saa7134 > em28xx > cx88 > solo6x10 (staging driver) > > Regards, > > Hans > Regards, David Ellingsworth -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v2] [media] Add v4l2 subdev driver for NOON010PC30L image sensor
Hi Hans, Thanks for this quick albeit helpful review. I had no objections to your comments so they all are considered in the patch version 3. On 12/20/2010 02:01 PM, Hans Verkuil wrote: Hi Sylwester, Here is a quick review of this second patch version. Reviewed-by: Hans Verkuil On Monday, December 06, 2010 13:24:58 Sylwester Nawrocki wrote: Add I2C/V4L2 subdev driver for Siliconfile NOON010PC30 CIF camera. The driver implements basic functionality, i.e. CIF/QCIF/QQCIF resolution and color format selection, automatic/manual color balance control. Other functions like cropping, rotation/flip, exposure etc. can be easily implemented if needed. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/video/Kconfig |6 + drivers/media/video/Makefile |1 + drivers/media/video/noon010pc30.c | 805 + include/media/noon010pc30.h | 28 ++ 4 files changed, 840 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/noon010pc30.c create mode 100644 include/media/noon010pc30.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index da08267..1f4b418 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -732,6 +732,12 @@ config VIDEO_VIA_CAMERA Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems with ov7670 sensors. +config VIDEO_NOON010PC30 + tristate "NOON010PC30 CIF camera sensor support" + depends on I2C&& VIDEO_V4L2 + ---help--- + This driver supports NOON010PC30 CIF camera from Siliconfile + config SOC_CAMERA tristate "SoC camera support" depends on VIDEO_V4L2&& HAS_DMA&& I2C diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 482f14b..fcc0644 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o +obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o diff --git a/drivers/media/video/noon010pc30.c b/drivers/media/video/noon010pc30.c new file mode 100644 index 000..22eead3 --- /dev/null +++ b/drivers/media/video/noon010pc30.c @@ -0,0 +1,805 @@ +/* + * Driver for SiliconFile NOON010PC30 CIF (1/11") Image Sensor with ISP + * + * Copyright (C) 2010 Samsung Electronics + * Contact: Sylwester Nawrocki, + * + * Initial register configuration based on a driver authored by + * HeungJun Kim. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later vergsion. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, "Enable module debug trace. Set to 1 to enable."); + +#define MODULE_NAME"NOON010PC30" +#define NOON010_NUM_SUPPLIES 3 + +/* + * Register offsets within a page + * b15..b8 - page id, b7..b0 - register address + */ +#define POWER_CTRL_REG 0x0001 +#define PAGEMODE_REG 0x03 +#define DEVICE_ID_REG 0x0004 +#define NOON010PC30_ID 0x86 +#define VDO_CTL_REG(n) (0x0010 + (n)) +#define SYNC_CTL_REG 0x0012 +/* Window size and position */ +#define WIN_ROWH_REG 0x0013 +#define WIN_ROWL_REG 0x0014 +#define WIN_COLH_REG 0x0015 +#define WIN_COLL_REG 0x0016 +#define WIN_HEIGHTH_REG0x0017 +#define WIN_HEIGHTL_REG0x0018 +#define WIN_WIDTHH_REG 0x0019 +#define WIN_WIDTHL_REG 0x001A +#define HBLANKH_REG0x001B +#define HBLANKL_REG0x001C +#define VSYNCH_REG 0x001D +#define VSYNCL_REG 0x001E +/* VSYNC control */ +#define VS_CTL_REG(n) (0x00A1 + (n)) +/* page 1 */ +#define ISP_CTL_REG(n) (0x0110 + (n)) +#define YOFS_REG 0x0119 +#define DARK_YOFS_REG 0x011A +#define SAT_CTL_REG0x0120 +#define BSAT_REG 0x0121 +#define RSAT_REG 0x0122 +/* Color correction */ +#define CMC_CTL_REG0x0130 +#define CMC_OFSGH_REG 0x0133 +#define CMC_OFSGL_REG 0x0135 +#define CMC_SIGN_REG 0x0136 +#define CMC_GOFS_REG 0x0137 +#define CMC_COEF_REG(n)(0x0138 + (n)) +#define CMC_OFS_REG(n) (0x0141 + (n)) +/* Gamma correction */ +#define GMA_CTL_REG0x0160 +#define GMA_COEF_REG(n)(0x0161 + (n)) +/* Lens Shading */ +#define LENS_CTRL_REG 0x01D0 +#def
[PATCH] s2255drv: remove BKL
Remove BKL ioctl and use unlocked_ioctl with core-assisted locking instead. Signed-off-by: Pete Eberlein diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c index f5a46c4..a216d62 100644 --- a/drivers/media/video/s2255drv.c +++ b/drivers/media/video/s2255drv.c @@ -269,7 +269,7 @@ struct s2255_dev { struct v4l2_device v4l2_dev; atomic_tnum_channels; int frames; - struct mutexlock; + struct mutexlock; /* channels[].vdev.lock */ struct mutexopen_lock; struct usb_device *udev; struct usb_interface*interface; @@ -781,20 +781,14 @@ static struct videobuf_queue_ops s2255_video_qops = { static int res_get(struct s2255_fh *fh) { - struct s2255_dev *dev = fh->dev; - /* is it free? */ struct s2255_channel *channel = fh->channel; - mutex_lock(&dev->lock); - if (channel->resources) { - /* no, someone else uses it */ - mutex_unlock(&dev->lock); - return 0; - } + /* is it free? */ + if (channel->resources) + return 0; /* no, someone else uses it */ /* it's free, grab it */ channel->resources = 1; fh->resources = 1; dprintk(1, "s2255: res: get\n"); - mutex_unlock(&dev->lock); return 1; } @@ -812,11 +806,8 @@ static int res_check(struct s2255_fh *fh) static void res_free(struct s2255_fh *fh) { struct s2255_channel *channel = fh->channel; - struct s2255_dev *dev = fh->dev; - mutex_lock(&dev->lock); channel->resources = 0; fh->resources = 0; - mutex_unlock(&dev->lock); dprintk(1, "res: put\n"); } @@ -1219,7 +1210,6 @@ static int s2255_set_mode(struct s2255_channel *channel, __le32 *buffer; unsigned long chn_rev; struct s2255_dev *dev = to_s2255_dev(channel->vdev.v4l2_dev); - mutex_lock(&dev->lock); chn_rev = G_chnmap[channel->idx]; dprintk(3, "%s channel: %d\n", __func__, channel->idx); /* if JPEG, set the quality */ @@ -1236,7 +1226,6 @@ static int s2255_set_mode(struct s2255_channel *channel, buffer = kzalloc(512, GFP_KERNEL); if (buffer == NULL) { dev_err(&dev->udev->dev, "out of mem\n"); - mutex_unlock(&dev->lock); return -ENOMEM; } /* set the mode */ @@ -1261,7 +1250,6 @@ static int s2255_set_mode(struct s2255_channel *channel, } /* clear the restart flag */ channel->mode.restart = 0; - mutex_unlock(&dev->lock); dprintk(1, "%s chn %d, result: %d\n", __func__, channel->idx, res); return res; } @@ -1272,13 +1260,11 @@ static int s2255_cmd_status(struct s2255_channel *channel, u32 *pstatus) __le32 *buffer; u32 chn_rev; struct s2255_dev *dev = to_s2255_dev(channel->vdev.v4l2_dev); - mutex_lock(&dev->lock); chn_rev = G_chnmap[channel->idx]; dprintk(4, "%s chan %d\n", __func__, channel->idx); buffer = kzalloc(512, GFP_KERNEL); if (buffer == NULL) { dev_err(&dev->udev->dev, "out of mem\n"); - mutex_unlock(&dev->lock); return -ENOMEM; } /* form the get vid status command */ @@ -1298,7 +1284,6 @@ static int s2255_cmd_status(struct s2255_channel *channel, u32 *pstatus) } *pstatus = channel->vidstatus; dprintk(4, "%s, vid status %d\n", __func__, *pstatus); - mutex_unlock(&dev->lock); return res; } @@ -1817,7 +1802,8 @@ static int s2255_open(struct file *file) NULL, &dev->slock, fh->type, V4L2_FIELD_INTERLACED, - sizeof(struct s2255_buffer), fh, NULL); + sizeof(struct s2255_buffer), + fh, vdev->lock); return 0; } @@ -1900,7 +1886,7 @@ static const struct v4l2_file_operations s2255_fops_v4l = { .open = s2255_open, .release = s2255_release, .poll = s2255_poll, - .ioctl = video_ioctl2, /* V4L2 ioctl handler */ + .unlocked_ioctl = video_ioctl2, /* V4L2 ioctl handler */ .mmap = s2255_mmap_v4l, }; @@ -1970,6 +1956,7 @@ static int s2255_probe_v4l(struct s2255_dev *dev) channel->vidq.dev = dev; /* register 4 video devices */ channel->vdev = template; + channel->vdev.lock = &dev->lock; channel->vdev.v4l2_dev = &dev->v4l2_dev; video_set_drvdata(&channel->vdev, channel); if (video_nr == -1) @@ -2676,7 +2663,9 @@ static void s2255_disconnect(struct usb_interface *interface) struct s2255_dev *dev = to_s2255_dev(usb_get_intfdata(interface));
Re: problems with using the -rc kernel in the git tree
On Mon, Dec 20, 2010 at 1:54 PM, Theodore Kilgore wrote: > > > On Mon, 20 Dec 2010, Alex Deucher wrote: > >> On Sun, Dec 19, 2010 at 6:56 PM, Theodore Kilgore >> wrote: >> > >> > Hans, >> > >> > Thanks for the helpful advice about how to set up a git tree for current >> > development so that I can get back into things. >> > >> > However, there is a problem with that -rc kernel, at least as far as my >> > hardware is concerned. So if I am supposed to use it to work on camera >> > stuff there is an obstacle. >> > >> > I started by copying my .config file over to the tree, and then running >> > make oldconfig (as you said and as I would have done anyway). >> > >> > The problem seems to be centered right here (couple of lines >> > from .config follow) >> > >> > CONFIG_DRM_RADEON=m >> > # CONFIG_DRM_RADEON_KMS is not set >> > >> > I have a Radeon video card, obviously. Specifically, it is (extract from X >> > config file follows) >> > >> > # Device configured by xorgconfig: >> > >> > Section "Device" >> > Identifier "ATI Radeon HD 3200" >> > Driver "radeon" >> > >> > Now, what happens is that with the kernel configuration (see above) I >> > cannot start X in the -rc kernel. I get bumped out with an error >> > message (details below) whereas that _was_ my previous configuration >> > setting. >> > >> > But if in the config for the -rc kernel I change the second line by >> > turning on CONFIG_DRM_RADEON_KMS the situation is even worse. Namely, the >> > video cuts off during the boot process, with the monitor going blank and >> > flashing up a message that it lost signal. After that the only thing to do >> > is a hard reset, which strangely does not result in any check for a dirty >> > file system, showing that things _really_ got screwed. These problems wit >> > the video cutting off at boot are with booting into the _terminal_, BTW. I >> > do not and never have made a practice of booting into X. I start X from >> > the command line after boot. Thus, the video cutting off during boot has >> > nothing to do with X at all, AFAICT. >> > >> > So as I said there are two alternatives, both of them quite unpleasant. >> > >> > Here is what the crash message is on the screen from the attempt to start >> > up X, followed by what seem to be the relevant lines from the log file, >> > with slightly more detail. >> > >> > Markers: (--) probed, (**) from config file, (==) default setting, >> > (++) from command line, (!!) notice, (II) informational, >> > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >> > (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 19 14:32:12 2010 >> > (==) Using config file: "/etc/X11/xorg.conf" >> > (==) Using system config directory "/usr/share/X11/xorg.conf.d" >> > (II) [KMS] drm report modesetting isn't supported. >> > (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22) >> > (EE) RADEON(0): Memory map the MMIO region failed >> > (EE) Screen(s) found, but none have a usable configuration. >> > >> > Fatal server error: >> > no screens found >> > >> > Please consult the The X.Org Foundation support >> > at http://wiki.x.org >> > for help. >> > Please also check the log file at "/var/log/Xorg.0.log" for additional >> > information. >> > >> > xinit: giving up >> > xinit: unable to connect to X server: Connection refused >> > xinit: server error >> > xinit: unable to connect to X server: Connection refused >> > xinit: server error >> > kilg...@khayyam:~$ >> > >> > And the following, too, from the log file, which perhaps contains one or >> > two >> > more details: >> > >> > [ 48.050] (--) using VT number 7 >> > >> > [ 48.052] (II) [KMS] drm report modesetting isn't supported. >> > [ 48.052] (II) RADEON(0): TOTO SAYS feaf >> > [ 48.052] (II) RADEON(0): MMIO registers at 0xfeaf: size >> > 64KB >> > [ 48.052] (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument >> > (22) >> > [ 48.052] (EE) RADEON(0): Memory map the MMIO region failed >> > [ 48.052] (II) UnloadModule: "radeon" >> > [ 48.052] (EE) Screen(s) found, but none have a usable configuration. >> > [ 48.052] >> > Fatal server error: >> > [ 48.052] no screens found >> > [ 48.052] >> > >> > There are a couple of suggestions about things to try, such as compiling >> > with CONFIG_DRM_RADEON_KMS and then passing the parameter modeset=0 to the >> > radeon module. But that does not seem to help, either. >> > >> > The help screens in make menuconfig do not seem to praise the >> > CONFIG_DRM_RADEON_KMS very highly, and seem to indicate that this is still >> > a very experimental feature. >> > >> > There are no such equivalent problems with my current kernel, which is a >> > home-compiled 2.6.35.7. >> > >> > I realize that this is a done decision, but it is exactly this kind of >> > thing that I had in mind when we had the Great Debate on the linux-media >> > list about whether to use hg or git. My position was to let hardware >>
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Dec 20 19:01:11 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for 2.6.37-rc7] V4L/DVB fixes
Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus For a series of fixes at v4l2 drivers. They fix an OOPS at bttv due to BKL patches, a series of regressions that happened at gspca sonixj driver, affecting most of the sonix Jpeg cams and a duplicated symbol, noticed by enabling allyesconfig + staging/cx23821. Thanks! Mauro --- The following changes since commit cf7d7e5a1980d1116ee152d25dac382b112b9c17: Linux 2.6.37-rc5 (2010-12-06 20:09:04 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Brandon Philips (1): [media] bttv: remove unneeded locking comments Jean-Francois Moine (6): [media] gspca - sonixj: Move bridge init to sd start [media] gspca - sonixj: Fix a bad probe exchange [media] gspca - sonixj: Add a flag in the driver_info table [media] gspca - sonixj: Set the flag for some devices [media] gspca - sonixj: Add the bit definitions of the bridge reg 0x01 and 0x17 [media] gspca - sonixj: Better handling of the bridge registers 0x01 and 0x17 Mauro Carvalho Chehab (2): [media] Don't export format_by_forcc on two different drivers [media] bttv: fix mutex use before init (BZ#24602) drivers/media/common/saa7146_hlp.c |8 +- drivers/media/common/saa7146_video.c| 16 +- drivers/media/video/bt8xx/bttv-driver.c | 117 +- drivers/media/video/gspca/sonixj.c | 416 ++- drivers/staging/cx25821/cx25821-video.c |8 +- drivers/staging/cx25821/cx25821-video.h |2 +- include/media/saa7146.h |2 +- 7 files changed, 205 insertions(+), 364 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problems with using the -rc kernel in the git tree
On Mon, 20 Dec 2010, Alex Deucher wrote: > On Sun, Dec 19, 2010 at 6:56 PM, Theodore Kilgore > wrote: > > > > Hans, > > > > Thanks for the helpful advice about how to set up a git tree for current > > development so that I can get back into things. > > > > However, there is a problem with that -rc kernel, at least as far as my > > hardware is concerned. So if I am supposed to use it to work on camera > > stuff there is an obstacle. > > > > I started by copying my .config file over to the tree, and then running > > make oldconfig (as you said and as I would have done anyway). > > > > The problem seems to be centered right here (couple of lines > > from .config follow) > > > > CONFIG_DRM_RADEON=m > > # CONFIG_DRM_RADEON_KMS is not set > > > > I have a Radeon video card, obviously. Specifically, it is (extract from X > > config file follows) > > > > # Device configured by xorgconfig: > > > > Section "Device" > > Identifier "ATI Radeon HD 3200" > > Driver "radeon" > > > > Now, what happens is that with the kernel configuration (see above) I > > cannot start X in the -rc kernel. I get bumped out with an error > > message (details below) whereas that _was_ my previous configuration > > setting. > > > > But if in the config for the -rc kernel I change the second line by > > turning on CONFIG_DRM_RADEON_KMS the situation is even worse. Namely, the > > video cuts off during the boot process, with the monitor going blank and > > flashing up a message that it lost signal. After that the only thing to do > > is a hard reset, which strangely does not result in any check for a dirty > > file system, showing that things _really_ got screwed. These problems wit > > the video cutting off at boot are with booting into the _terminal_, BTW. I > > do not and never have made a practice of booting into X. I start X from > > the command line after boot. Thus, the video cutting off during boot has > > nothing to do with X at all, AFAICT. > > > > So as I said there are two alternatives, both of them quite unpleasant. > > > > Here is what the crash message is on the screen from the attempt to start > > up X, followed by what seem to be the relevant lines from the log file, > > with slightly more detail. > > > > Markers: (--) probed, (**) from config file, (==) default setting, > > (++) from command line, (!!) notice, (II) informational, > > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > > (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 19 14:32:12 2010 > > (==) Using config file: "/etc/X11/xorg.conf" > > (==) Using system config directory "/usr/share/X11/xorg.conf.d" > > (II) [KMS] drm report modesetting isn't supported. > > (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22) > > (EE) RADEON(0): Memory map the MMIO region failed > > (EE) Screen(s) found, but none have a usable configuration. > > > > Fatal server error: > > no screens found > > > > Please consult the The X.Org Foundation support > > at http://wiki.x.org > > for help. > > Please also check the log file at "/var/log/Xorg.0.log" for additional > > information. > > > > xinit: giving up > > xinit: unable to connect to X server: Connection refused > > xinit: server error > > xinit: unable to connect to X server: Connection refused > > xinit: server error > > kilg...@khayyam:~$ > > > > And the following, too, from the log file, which perhaps contains one or > > two > > more details: > > > > [ 48.050] (--) using VT number 7 > > > > [ 48.052] (II) [KMS] drm report modesetting isn't supported. > > [ 48.052] (II) RADEON(0): TOTO SAYS feaf > > [ 48.052] (II) RADEON(0): MMIO registers at 0xfeaf: size > > 64KB > > [ 48.052] (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument > > (22) > > [ 48.052] (EE) RADEON(0): Memory map the MMIO region failed > > [ 48.052] (II) UnloadModule: "radeon" > > [ 48.052] (EE) Screen(s) found, but none have a usable configuration. > > [ 48.052] > > Fatal server error: > > [ 48.052] no screens found > > [ 48.052] > > > > There are a couple of suggestions about things to try, such as compiling > > with CONFIG_DRM_RADEON_KMS and then passing the parameter modeset=0 to the > > radeon module. But that does not seem to help, either. > > > > The help screens in make menuconfig do not seem to praise the > > CONFIG_DRM_RADEON_KMS very highly, and seem to indicate that this is still > > a very experimental feature. > > > > There are no such equivalent problems with my current kernel, which is a > > home-compiled 2.6.35.7. > > > > I realize that this is a done decision, but it is exactly this kind of > > thing that I had in mind when we had the Great Debate on the linux-media > > list about whether to use hg or git. My position was to let hardware > > support people to run hg with the compatibility layer for recent kernels > > (and 2.6.35.7 is certainly recent!). Well, the people who had such a > > position did not win. So
Re: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl
On Sat, 2010-12-18 at 12:31 +0100, Hans Verkuil wrote: > Hi all, > > Now that the BKL patch series has been merged in 2.6.37 it is time to work > on replacing .ioctl by .unlocked_ioctl in all v4l drivers. > > I've made an inventory of all drivers that still use .ioctl and I am looking > for volunteers to tackle one or more drivers. > > I have CCed this email to the maintainers of the various drivers (if I know > who it is) in the hope that we can get this conversion done as quickly as > possible. > > If I have added your name to a driver, then please confirm if you are able to > work on it or not. If you can't work on it, but you know someone else, then > let me know as well. > s2255drv (Pete Eberlein) I'll work on this one. > Staging driver list: > > go7007 (Pete Eberlein) And this one. Regards, Pete Eberlein -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: General Question regarding SNR
Hello, "crope" on #linuxtv irc helped me to understand the stuff in my previous mail. So for other people who might want to understand that also: dvbsnoop reports snr without lock/antenna: If there is no Lock, unc, ber and snr _aren't_ valid. So check first whether you have a lock, if yes okay, if no ignore those values. 215 db SNR makes no sense: wdp: but most newer drivers report SNR as dB x 10 0144 -> 324 -> 32,4 dB ... :-) Jean -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l: mem2mem_testdev: remove BKL usage
Remove usage of BKL by usign per-device mutex. Signed-off-by: Marek Szyprowski CC: Pawel Osciak --- drivers/media/video/mem2mem_testdev.c | 21 + 1 files changed, 9 insertions(+), 12 deletions(-) diff --git a/drivers/media/video/mem2mem_testdev.c b/drivers/media/video/mem2mem_testdev.c index 3b19f5b..c179041 100644 --- a/drivers/media/video/mem2mem_testdev.c +++ b/drivers/media/video/mem2mem_testdev.c @@ -524,7 +524,6 @@ static int vidioc_s_fmt(struct m2mtest_ctx *ctx, struct v4l2_format *f) { struct m2mtest_q_data *q_data; struct videobuf_queue *vq; - int ret = 0; vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type); if (!vq) @@ -534,12 +533,9 @@ static int vidioc_s_fmt(struct m2mtest_ctx *ctx, struct v4l2_format *f) if (!q_data) return -EINVAL; - mutex_lock(&vq->vb_lock); - if (videobuf_queue_is_busy(vq)) { v4l2_err(&ctx->dev->v4l2_dev, "%s queue busy\n", __func__); - ret = -EBUSY; - goto out; + return -EBUSY; } q_data->fmt = find_format(f); @@ -553,9 +549,7 @@ static int vidioc_s_fmt(struct m2mtest_ctx *ctx, struct v4l2_format *f) "Setting format for type %d, wxh: %dx%d, fmt: %d\n", f->type, q_data->width, q_data->height, q_data->fmt->fourcc); -out: - mutex_unlock(&vq->vb_lock); - return ret; + return 0; } static int vidioc_s_fmt_vid_cap(struct file *file, void *priv, @@ -845,10 +839,12 @@ static void queue_init(void *priv, struct videobuf_queue *vq, enum v4l2_buf_type type) { struct m2mtest_ctx *ctx = priv; + struct m2mtest_dev *dev = ctx->dev; - videobuf_queue_vmalloc_init(vq, &m2mtest_qops, ctx->dev->v4l2_dev.dev, - &ctx->dev->irqlock, type, V4L2_FIELD_NONE, - sizeof(struct m2mtest_buffer), priv, NULL); + videobuf_queue_vmalloc_init(vq, &m2mtest_qops, dev->v4l2_dev.dev, + &dev->irqlock, type, V4L2_FIELD_NONE, + sizeof(struct m2mtest_buffer), priv, + &dev->dev_mutex); } @@ -920,7 +916,7 @@ static const struct v4l2_file_operations m2mtest_fops = { .open = m2mtest_open, .release= m2mtest_release, .poll = m2mtest_poll, - .ioctl = video_ioctl2, + .unlocked_ioctl = video_ioctl2, .mmap = m2mtest_mmap, }; @@ -965,6 +961,7 @@ static int m2mtest_probe(struct platform_device *pdev) } *vfd = m2mtest_videodev; + vfd->lock = &dev->dev_mutex; ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0); if (ret) { -- 1.7.1.569.g6f426 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v3] Add chip identity for NOON010PC30 camera sensor
Add ID for NOON010PC30 camera chip and reserve ID range for Siliconfile sensors. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- include/media/v4l2-chip-ident.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h index 51e89f2..bd6e7e4 100644 --- a/include/media/v4l2-chip-ident.h +++ b/include/media/v4l2-chip-ident.h @@ -208,6 +208,9 @@ enum { /* module sn9c20x: just ident 1 */ V4L2_IDENT_SN9C20X = 1, + /* Siliconfile sensors: reserved range 10100 - 10199 */ + V4L2_IDENT_NOON010PC30 = 10100, + /* module cx231xx and cx25840 */ V4L2_IDENT_CX2310X_AV = 23099, /* Integrated A/V decoder; not in '100 */ V4L2_IDENT_CX23100= 23100, -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 v3] Add v4l2 subdev driver for NOON010PC30L image sensor
Add I2C/V4L2 subdev driver for Siliconfile NOON010PC30 CIF camera. The driver implements basic functionality, i.e. CIF/QCIF/QQCIF resolution and color format selection, automatic/manual color balance control. Other functions like cropping, rotation/flip, exposure etc. can be easily implemented if needed. Reviewed-by: Hans Verkuil Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/video/Kconfig |6 + drivers/media/video/Makefile |1 + drivers/media/video/noon010pc30.c | 792 + include/media/noon010pc30.h | 28 ++ 4 files changed, 827 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/noon010pc30.c create mode 100644 include/media/noon010pc30.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index da08267..1f4b418 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -732,6 +732,12 @@ config VIDEO_VIA_CAMERA Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems with ov7670 sensors. +config VIDEO_NOON010PC30 + tristate "NOON010PC30 CIF camera sensor support" + depends on I2C && VIDEO_V4L2 + ---help--- + This driver supports NOON010PC30 CIF camera from Siliconfile + config SOC_CAMERA tristate "SoC camera support" depends on VIDEO_V4L2 && HAS_DMA && I2C diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 482f14b..fcc0644 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o +obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o diff --git a/drivers/media/video/noon010pc30.c b/drivers/media/video/noon010pc30.c new file mode 100644 index 000..41a6474 --- /dev/null +++ b/drivers/media/video/noon010pc30.c @@ -0,0 +1,792 @@ +/* + * Driver for SiliconFile NOON010PC30 CIF (1/11") Image Sensor with ISP + * + * Copyright (C) 2010 Samsung Electronics + * Contact: Sylwester Nawrocki, + * + * Initial register configuration based on a driver authored by + * HeungJun Kim . + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later vergsion. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, "Enable module debug trace. Set to 1 to enable."); + +#define MODULE_NAME"NOON010PC30" + +/* + * Register offsets within a page + * b15..b8 - page id, b7..b0 - register address + */ +#define POWER_CTRL_REG 0x0001 +#define PAGEMODE_REG 0x03 +#define DEVICE_ID_REG 0x0004 +#define NOON010PC30_ID 0x86 +#define VDO_CTL_REG(n) (0x0010 + (n)) +#define SYNC_CTL_REG 0x0012 +/* Window size and position */ +#define WIN_ROWH_REG 0x0013 +#define WIN_ROWL_REG 0x0014 +#define WIN_COLH_REG 0x0015 +#define WIN_COLL_REG 0x0016 +#define WIN_HEIGHTH_REG0x0017 +#define WIN_HEIGHTL_REG0x0018 +#define WIN_WIDTHH_REG 0x0019 +#define WIN_WIDTHL_REG 0x001A +#define HBLANKH_REG0x001B +#define HBLANKL_REG0x001C +#define VSYNCH_REG 0x001D +#define VSYNCL_REG 0x001E +/* VSYNC control */ +#define VS_CTL_REG(n) (0x00A1 + (n)) +/* page 1 */ +#define ISP_CTL_REG(n) (0x0110 + (n)) +#define YOFS_REG 0x0119 +#define DARK_YOFS_REG 0x011A +#define SAT_CTL_REG0x0120 +#define BSAT_REG 0x0121 +#define RSAT_REG 0x0122 +/* Color correction */ +#define CMC_CTL_REG0x0130 +#define CMC_OFSGH_REG 0x0133 +#define CMC_OFSGL_REG 0x0135 +#define CMC_SIGN_REG 0x0136 +#define CMC_GOFS_REG 0x0137 +#define CMC_COEF_REG(n)(0x0138 + (n)) +#define CMC_OFS_REG(n) (0x0141 + (n)) +/* Gamma correction */ +#define GMA_CTL_REG0x0160 +#define GMA_COEF_REG(n)(0x0161 + (n)) +/* Lens Shading */ +#define LENS_CTRL_REG 0x01D0 +#define LENS_XCEN_REG 0x01D1 +#define LENS_YCEN_REG 0x01D2 +#define LENS_RC_REG0x01D3 +#define LENS_GC_REG0x01D4 +#define LENS_BC_REG0x01D5 +#define L_AGON_REG 0x01D6 +#define L_AGOFF_REG0x01D7 +/* Page 3 - Auto Exposure */ +#define AE_CTL_REG(n) (0x0310 + (n)) +#defi
[PATCH/RFC 0/2 v3] I2C/subdev driver for NOON010PC30 camera chip
Hi all, following is a third version of patches adding the I2C/subdev driver for Siliconfile NOON010PC30 camera sensor with integrated ISP. It includes mostly corrections after the review by Hans. Hopefully it can be merged into 2.6.38 in the current form. Changes since v1: - reworked to new v4l2-controls framework (-8% LOC) Changes since v2: - removed unneeded struct v4l2_ctrl * entries, CodingStyle cleanup, fixed error paths in probe, added missing v4l2_ctrl_handler_free on driver unload - removed s_config and an empty s_stream subdev callback implementations The patch series contains: [PATCH 1/2 v3] [media] Add chip identity for NOON010PC30 camera sensor [PATCH 2/2 v3] [media] Add v4l2 subdev driver for NOON010PC30L image sensor It has been rebased onto linuxtv/staging/for_v2.6.38 branch at git://linuxtv.org/media_tree.git. Regards, Sylwester -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 8/8] davinci vpbe: Readme text for Dm6446 vpbe
Please refer to this file for detailed documentation of davinci vpbe v4l2 driver Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- Documentation/video4linux/README.davinci-vpbe | 93 + 1 files changed, 93 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe new file mode 100644 index 000..7a460b0 --- /dev/null +++ b/Documentation/video4linux/README.davinci-vpbe @@ -0,0 +1,93 @@ + +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of the following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements creation of video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up VENC, OSD and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the VENC or external sub devices. It also provides +a device object to access the services from OSD subdevice +using sub device ops. The connection of external encoders to VENC LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connected to an external encoder, vpbe controller is also responsible +for setting up the interface between VENC and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allows +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in VENC for a specific display resolution. As of this +patch series, the interconnection and enabling and setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. VENC subdevice module +Responsible for setting outputs provided through internal DACs and also +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the VENC. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry (i.e add the "LogicPD" +output name to board-xxx-evm.c). A table of timings for various LCDs +supported can be maintained in the board specific setup file to support +various LCD displays.As of this patch a basic driver is present, and this +support for external encoders and displays forms a part of the next +patch series. + + 4. OSD module +OSD module implements all OSD layer management and hardware specific +features. The VPBE module interacts with the OSD for enabling and +disabling appropriate features of the OSD. + + Current status:- + + A fully functional working version of the V4L2 driver is available. This + driver has been tested with NTSC and PAL standards and buffer streaming. + + Following are TBDs. + + vpbe display controller +- Add support for external encoders. +- add support for selecting external encoder as default at probe time. + + vpbe venc sub device +- add timings for supporting ths8200 +- add support for LogicPD LCD. + + FB drivers +- Add support for fbdev drivers.- Ready and part of subsequent patches. -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 7/8] davinci vpbe: Build infrastructure for VPBE driver
This patch adds the build infra-structure for Davinci VPBE dislay driver Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- drivers/media/video/davinci/Kconfig | 22 ++ drivers/media/video/davinci/Makefile |2 ++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..a7f11e7 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE + tristate "DM644X VPBE HW module" + select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG + help + Enables VPBE modules used for display on a DM644x + SoC. + + To compile this driver as a module, choose M here: the + module will be called vpbe. + + +config VIDEO_VPBE_DISPLAY + tristate "VPBE V4L2 Display driver" + select VIDEO_DM644X_VPBE + default y + help + Enables VPBE V4L2 Display driver on a DMXXX device + + To compile this driver as a module, choose M here: the + module will be called vpbe_display. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..ae7dafb 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o +obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 5/8] davinci vpbe: platform specific additions
This patch implements the overall device creation for the Video display driver Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- arch/arm/mach-davinci/dm644x.c | 164 ++- arch/arm/mach-davinci/include/mach/dm644x.h |4 + 2 files changed, 162 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 5e5b0a7..e8b8e94 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -640,6 +640,142 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg) vpfe_capture_dev.dev.platform_data = cfg; } +static struct resource dm644x_osd_resources[] = { + { + .start = 0x01C72600, + .end= 0x01C72600 + 0x200, + .flags = IORESOURCE_MEM, + }, +}; + +static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32); + +static struct platform_device dm644x_osd_dev = { + .name = VPBE_OSD_SUBDEV_NAME, + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_osd_resources), + .resource = dm644x_osd_resources, + .dev = { + .dma_mask = &dm644x_osd_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = (void *)DM644X_VPBE, + }, +}; + +static struct resource dm644x_venc_resources[] = { + /* venc registers io space */ + { + .start = 0x01C72400, + .end= 0x01C72400 + 0x180, + .flags = IORESOURCE_MEM, + }, +}; + +static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32); + +#define VPSS_CLKCTL 0x01C40044 +static void __iomem *vpss_clkctl_reg; + +/* TBD. Check what VENC_CLOCK_SEL settings for HDTV and EDTV */ +static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64 mode) +{ + int ret = 0; + + if (NULL == vpss_clkctl_reg) + return -EINVAL; + if (type == VPBE_ENC_STD) { + __raw_writel(0x18, vpss_clkctl_reg); + } else if (type == VPBE_ENC_DV_PRESET) { + switch ((unsigned int)mode) { + case V4L2_DV_480P59_94: + case V4L2_DV_576P50: +__raw_writel(0x19, vpss_clkctl_reg); + break; + case V4L2_DV_720P60: + case V4L2_DV_1080I60: + case V4L2_DV_1080P30: + /* + * For HD, use external clock source since HD requires higher + * clock rate + */ + __raw_writel(0xa, vpss_clkctl_reg); + break; + default: + ret = -EINVAL; + break; + } + } else + ret = -EINVAL; + + return ret; +} + + +static inline u32 dm644x_reg_modify(void *reg, u32 val, u32 mask) +{ + u32 new_val = (__raw_readl(reg) & ~mask) | (val & mask); + __raw_writel(new_val, reg); + return new_val; +} + +static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32); + +static struct resource dm644x_v4l2_disp_resources[] = { + { + .start = IRQ_VENCINT, + .end= IRQ_VENCINT, + .flags = IORESOURCE_IRQ, + }, + { + .start = 0x01C72400, + .end= 0x01C72400 + 0x180, + .flags = IORESOURCE_MEM, + }, + +}; +static struct platform_device vpbe_v4l2_display = { + .name = "vpbe-v4l2", + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources), + .resource = dm644x_v4l2_disp_resources, + .dev = { + .dma_mask = &vpbe_display_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, +}; +struct venc_platform_data dm644x_venc_pdata = { + .venc_type = DM644X_VPBE, + .setup_clock = dm644x_venc_setup_clock, +}; + +static struct platform_device dm644x_venc_dev = { + .name = VPBE_VENC_SUBDEV_NAME, + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_venc_resources), + .resource = dm644x_venc_resources, + .dev = { + .dma_mask = &dm644x_venc_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = (void *)&dm644x_venc_pdata, + }, +}; + +static u64 dm644x_vpbe_dma_mask = DMA_BIT_MASK(32); + +static struct platform_device dm644x_vpbe_dev = { + .name = "vpbe_controller", + .id = -1, + .dev = { + .dma_mask = &dm644x_vpbe_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, +}; + +void dm644x_set_vpbe_display_config(struct vpbe_display_config *cfg) +{ + dm644x_vpbe_dev.dev.platform_data = cfg; +} + /*-
[PATCH v8 6/8] davinci vpbe: board specific additions
This patch implements tables for display timings,outputs and other board related functionalities. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- arch/arm/mach-davinci/board-dm644x-evm.c | 79 +- 1 files changed, 66 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 34c8b41..e9b1243 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -166,18 +166,6 @@ static struct platform_device davinci_evm_nandflash_device = { .resource = davinci_evm_nandflash_resource, }; -static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32); - -static struct platform_device davinci_fb_device = { - .name = "davincifb", - .id = -1, - .dev = { - .dma_mask = &davinci_fb_dma_mask, - .coherent_dma_mask = DMA_BIT_MASK(32), - }, - .num_resources = 0, -}; - static struct tvp514x_platform_data tvp5146_pdata = { .clk_polarity = 0, .hs_polarity = 1, @@ -606,8 +594,71 @@ static void __init evm_init_i2c(void) i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info)); } +#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL) +/* venc standards timings */ +static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = { + {"ntsc", VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480, + {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0}, + {"pal", VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576, + {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0}, +}; + +/* venc dv preset timings */ +static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = { + {"480p59_94", VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480, + {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0}, + {"576p50", VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576, + {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0}, +}; + +/* + * The outputs available from VPBE + ecnoders. Keep the + * the order same as that of encoders. First that from venc followed by that + * from encoders. Index in the output refers to index on a particular encoder. + * Driver uses this index to pass it to encoder when it supports more than + * one output. Application uses index of the array to set an output. + */ +static struct vpbe_output dm644x_vpbe_outputs[] = { + { + .output = { + .index = 0, + .name = "Composite", + .type = V4L2_OUTPUT_TYPE_ANALOG, + .std = VENC_STD_ALL, + .capabilities = V4L2_OUT_CAP_STD, + }, + .subdev_name = VPBE_VENC_SUBDEV_NAME, + .default_mode = "ntsc", + .num_modes = ARRAY_SIZE(vbpe_enc_std_timings), + .modes = vbpe_enc_std_timings, + }, + { + .output = { + .index = 1, + .name = "Component", + .type = V4L2_OUTPUT_TYPE_ANALOG, + .capabilities = V4L2_OUT_CAP_PRESETS, + }, + .subdev_name = VPBE_VENC_SUBDEV_NAME, + .default_mode = "480p59_94", + .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings), + .modes = vbpe_enc_preset_timings, + }, +}; + +static struct vpbe_display_config vpbe_display_cfg = { + .module_name = "dm644x-vpbe-display", + .i2c_adapter_id = 1, + .osd = { + .module_name = VPBE_OSD_SUBDEV_NAME, + }, + .venc = { + .module_name = VPBE_VENC_SUBDEV_NAME, + }, + .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs), + .outputs = dm644x_vpbe_outputs, +}; static struct platform_device *davinci_evm_devices[] __initdata = { - &davinci_fb_device, &rtc_dev, }; @@ -620,6 +671,8 @@ davinci_evm_map_io(void) { /* setup input configuration for VPFE input devices */ dm644x_set_vpfe_config(&vpfe_cfg); + /* setup configuration for vpbe devices */ + dm644x_set_vpbe_display_config(&vpbe_display_cfg); dm644x_init(); } -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 4/8] davinci vpbe: VENC( Video Encoder) implementation
This patch adds the VENC or the Video encoder, whichis responsible for the blending of al source planes and timing generation for Video modes like NTSC, PAL and other digital outputs. the VENC implementation currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL resolutions through the analog DACs. The venc block is implemented as a subdevice, allowing for additional extenal and internal encoders of other kind to plug-in. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- drivers/media/video/davinci/vpbe_venc.c | 574 ++ drivers/media/video/davinci/vpbe_venc_regs.h | 189 + include/media/davinci/vpbe_venc.h| 38 ++ 3 files changed, 801 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe_venc.h diff --git a/drivers/media/video/davinci/vpbe_venc.c b/drivers/media/video/davinci/vpbe_venc.c new file mode 100644 index 000..fafb41a --- /dev/null +++ b/drivers/media/video/davinci/vpbe_venc.c @@ -0,0 +1,574 @@ +/* + * Copyright (C) 2010 Texas Instruments Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include + +#include +#include +#include +#include + +#include "vpbe_venc_regs.h" + +#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME + +static int debug = 2; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, "Debug level 0-2"); + +struct venc_state { + struct v4l2_subdev sd; + struct venc_callback *callback; + struct venc_platform_data *pdata; + struct device *pdev; + u32 output; + v4l2_std_id std; + spinlock_t lock; + void __iomem *venc_base; + void __iomem *vdaccfg_reg; +}; + +static inline struct venc_state *to_state(struct v4l2_subdev *sd) +{ + return container_of(sd, struct venc_state, sd); +} + +static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset) +{ + struct venc_state *venc = to_state(sd); + + return __raw_readl(venc->venc_base + offset); +} + +static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val) +{ + struct venc_state *venc = to_state(sd); + __raw_writel(val, (venc->venc_base + offset)); + return val; +} + +static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset, +u32 val, u32 mask) +{ + u32 new_val = (venc_read(sd, offset) & ~mask) | (val & mask); + + venc_write(sd, offset, new_val); + return new_val; +} + +static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val) +{ + struct venc_state *venc = to_state(sd); + + __raw_writel(val, venc->vdaccfg_reg); + + val = __raw_readl(venc->vdaccfg_reg); + return val; +} + +/* This function sets the dac of the VPBE for various outputs + */ +static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index) +{ + int ret = 0; + + switch (out_index) { + case 0: + v4l2_dbg(debug, 1, sd, "Setting output to Composite\n"); + venc_write(sd, VENC_DACSEL, 0); + break; + case 1: + v4l2_dbg(debug, 1, sd, "Setting output to S-Video\n"); + venc_write(sd, VENC_DACSEL, 0x210); + break; + case 2: + venc_write(sd, VENC_DACSEL, 0x543); + break; + default: + ret = -EINVAL; + } + return ret; +} + +static void enabledigitaloutput(struct v4l2_subdev *sd, int benable) +{ + v4l2_dbg(debug, 2, sd, "enabledigitaloutput\n"); + + if (benable) { + venc_write(sd, VENC_VMOD, 0); + venc_write(sd, VENC_CVBS, 0); + venc_write(sd, VENC_LCDOUT, 0); + venc_write(sd, VENC_HSPLS, 0); + venc_write(sd, VENC_HSTART, 0); + venc_write(sd, VENC_HVALID, 0); + venc_write(sd, VENC_HINT, 0); + venc_write(sd, VENC_VSPLS, 0); + venc_write(sd, VENC_VSTART, 0); + venc_write(sd, VENC_VVALID, 0);
[PATCH v8 2/8] davinci vpbe: VPBE display driver
This patch implements the coe functionality of the dislay driver, mainly controlling the VENC and other encoders, and acting as the one point interface for the man V4L2 driver.This implements the cre of each of the V4L2 IOCTLs. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- drivers/media/video/davinci/vpbe.c | 837 include/media/davinci/vpbe.h | 186 2 files changed, 1023 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 include/media/davinci/vpbe.h diff --git a/drivers/media/video/davinci/vpbe.c b/drivers/media/video/davinci/vpbe.c new file mode 100644 index 000..751370f --- /dev/null +++ b/drivers/media/video/davinci/vpbe.c @@ -0,0 +1,837 @@ +/* + * Copyright (C) 2010 Texas Instruments Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + + +#define VPBE_DEFAULT_OUTPUT"Composite" +#define VPBE_DEFAULT_MODE "ntsc" + +static char *def_output = VPBE_DEFAULT_OUTPUT; +static char *def_mode = VPBE_DEFAULT_MODE; +static struct osd_state *osd_device; +static struct venc_platform_data *venc_device; +static int debug; + +module_param(def_output, charp, S_IRUGO); +module_param(def_mode, charp, S_IRUGO); +module_param(debug, int, 0644); + +MODULE_PARM_DESC(def_output, "vpbe output name (default:Composite)"); +MODULE_PARM_DESC(ef_mode, "vpbe output mode name (default:ntsc"); +MODULE_PARM_DESC(debug, "Debug level 0-1"); + +MODULE_DESCRIPTION("TI DMXXX VPBE Display controller"); +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Texas Instruments"); + +/** + * vpbe_current_encoder_info - Get config info for current encoder + * @vpbe_dev - vpbe device ptr + * + * Return ptr to current encoder config info + */ +static struct encoder_config_info* +vpbe_current_encoder_info(struct vpbe_device *vpbe_dev) +{ + struct vpbe_display_config *vpbe_config = vpbe_dev->cfg; + int index = vpbe_dev->current_sd_index; + + return ((index == 0) ? &vpbe_config->venc : + &vpbe_config->ext_encoders[index-1]); +} + +/** + * vpbe_find_encoder_sd_index - Given a name find encoder sd index + * + * @vpbe_config - ptr to vpbe cfg + * @output_index - index used by application + * + * Return sd index of the encoder + */ +static int vpbe_find_encoder_sd_index(struct vpbe_display_config *vpbe_config, +int index) +{ + char *encoder_name = vpbe_config->outputs[index].subdev_name; + int i; + + /* Venc is always first */ + if (!strcmp(encoder_name, vpbe_config->venc.module_name)) + return 0; + + for (i = 0; i < vpbe_config->num_ext_encoders; i++) { + if (!strcmp(encoder_name, +vpbe_config->ext_encoders[i].module_name)) + return i+1; + } + return -EINVAL; +} + +/** + * vpbe_g_cropcap - Get crop capabilities of the display + * @vpbe_dev - vpbe device ptr + * @cropcap - cropcap is a ptr to struct v4l2_cropcap + * + * Update the crop capabilities in crop cap for current + * mode + */ +static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev, + struct v4l2_cropcap *cropcap) +{ + if (NULL == cropcap) + return -EINVAL; + cropcap->bounds.left = 0; + cropcap->bounds.top = 0; + cropcap->bounds.width = vpbe_dev->current_timings.xres; + cropcap->bounds.height = vpbe_dev->current_timings.yres; + cropcap->defrect = cropcap->bounds; + return 0; +} + +/** + * vpbe_enum_outputs - enumerate outputs + * @vpbe_dev - vpbe device ptr + * @output - ptr to v4l2_output structure + * + * Enumerates the outputs available at the vpbe display + * returns the status, -EINVAL if end of output list + */ +static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev, +struct v4l2_output *output) +{ + struct vpbe_display_config *vpbe_config = vpbe_dev->cfg; + int temp_index = output->index; + + if (temp_index >= vpbe_config->num_outputs) + return -EINVAL; + + *output = vpbe_config->outputs[te
[PATCH v8 3/8] davinci vpbe: OSD(On Screen Display) block
This patch implements the functionality of the OSD block of the VPBE.The OSD in total supports 4 planes or Video sources - 2 mainly RGB and 2 Video. The patch implements general handling of all the planes, with specific emphasis on the Video plane capabilities as the Video planes are supported through the V4L2 driver. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- drivers/media/video/davinci/vpbe_osd.c | 1211 +++ drivers/media/video/davinci/vpbe_osd_regs.h | 389 + include/media/davinci/vpbe_osd.h| 397 + 3 files changed, 1997 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 include/media/davinci/vpbe_osd.h diff --git a/drivers/media/video/davinci/vpbe_osd.c b/drivers/media/video/davinci/vpbe_osd.c new file mode 100644 index 000..2599c83 --- /dev/null +++ b/drivers/media/video/davinci/vpbe_osd.c @@ -0,0 +1,1211 @@ +/* + * Copyright (C) 2007-2010 Texas Instruments Inc + * Copyright (C) 2007 MontaVista Software, Inc. + * + * Andy Lowe (al...@mvista.com), MontaVista Software + * - Initial version + * Murali Karicheri (mkarich...@gmail.com), Texas Instruments Ltd. + * - ported to sub device interface + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include +#include + +#include +#include "vpbe_osd_regs.h" + +#define MODULE_NAMEVPBE_OSD_SUBDEV_NAME + +/* register access routines */ +static inline u32 osd_read(struct osd_state *sd, u32 offset) +{ + struct osd_state *osd = sd; + return __raw_readl(osd->osd_base + offset); +} + +static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset) +{ + struct osd_state *osd = sd; + __raw_writel(val, osd->osd_base + offset); + return val; +} + +static inline u32 osd_set(struct osd_state *sd, u32 mask, u32 offset) +{ + struct osd_state *osd = sd; + + u32 addr = osd->osd_base + offset; + u32 val = __raw_readl(addr) | mask; + + __raw_writel(val, addr); + return val; +} + +static inline u32 osd_clear(struct osd_state *sd, u32 mask, u32 offset) +{ + struct osd_state *osd = sd; + u32 addr = osd->osd_base + offset; + u32 val = __raw_readl(addr) & ~mask; + + __raw_writel(val, addr); + return val; +} + +static inline u32 osd_modify(struct osd_state *sd, u32 mask, u32 val, +u32 offset) +{ + struct osd_state *osd = sd; + + u32 addr = osd->osd_base + offset; + u32 new_val = (__raw_readl(addr) & ~mask) | (val & mask); + __raw_writel(new_val, addr); + return new_val; +} + +/* define some macros for layer and pixfmt classification */ +#define is_osd_win(layer) (((layer) == WIN_OSD0) || ((layer) == WIN_OSD1)) +#define is_vid_win(layer) (((layer) == WIN_VID0) || ((layer) == WIN_VID1)) +#define is_rgb_pixfmt(pixfmt) \ + (((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888)) +#define is_yc_pixfmt(pixfmt) \ + (((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \ + ((pixfmt) == PIXFMT_NV12)) +#define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X +#define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO << 5) + + +/** + * _osd_dm6446_vid0_pingpong() - field inversion fix for DM6446 + * @sd - ptr to struct osd_state + * @field_inversion - inversion flag + * @fb_base_phys - frame buffer address + * @lconfig - ptr to layer config + * + * This routine implements a workaround for the field signal inversion silicon + * erratum described in Advisory 1.3.8 for the DM6446. The fb_base_phys and + * lconfig parameters apply to the vid0 window. This routine should be called + * whenever the vid0 layer configuration or start address is modified, or when + * the OSD field inversion setting is modified. + * Returns: 1 if the ping-pong buffers need to be toggled in the vsync isr, or + * 0 otherwise + */ +static int _osd_dm6446_vid0_pingpong(struct osd_state *sd, +int field_inversion, +unsigned long fb_base_phys, +
[PATCH v8 0/8] davinci vpbe: dm6446 v4l2 driver
version8 : addressed on Sergei's comments on: 1.Interchanged platform and board specific patches due to dependencies. Manjunath Hadli (8): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: platform specific additions davinci vpbe: board specific additions davinci vpbe: Build infrastructure for VPBE driver davinci vpbe: Readme text for Dm6446 vpbe Documentation/video4linux/README.davinci-vpbe | 93 ++ arch/arm/mach-davinci/board-dm644x-evm.c | 79 +- arch/arm/mach-davinci/dm644x.c| 164 ++- arch/arm/mach-davinci/include/mach/dm644x.h |4 + drivers/media/video/davinci/Kconfig | 22 + drivers/media/video/davinci/Makefile |2 + drivers/media/video/davinci/vpbe.c| 837 ++ drivers/media/video/davinci/vpbe_display.c| 2099 + drivers/media/video/davinci/vpbe_osd.c| 1211 ++ drivers/media/video/davinci/vpbe_osd_regs.h | 389 + drivers/media/video/davinci/vpbe_venc.c | 574 +++ drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++ include/media/davinci/vpbe.h | 186 +++ include/media/davinci/vpbe_display.h | 146 ++ include/media/davinci/vpbe_osd.h | 397 + include/media/davinci/vpbe_types.h| 93 ++ include/media/davinci/vpbe_venc.h | 38 + 17 files changed, 6504 insertions(+), 19 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 5/8] davinci vpbe: board specific additions
On Fri, Dec 17, 2010 at 21:59:23, Sergei Shtylyov wrote: > Hello. > > Manjunath Hadli wrote: > > > This patch implements tables for display timings,outputs and other > > board related functionalities. > > > Signed-off-by: Manjunath Hadli > > Acked-by: Muralidharan Karicheri > > Acked-by: Hans Verkuil > [...] > > > diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c > > b/arch/arm/mach-davinci/board-dm644x-evm.c > > index 34c8b41..e9b1243 100644 > > --- a/arch/arm/mach-davinci/board-dm644x-evm.c > > +++ b/arch/arm/mach-davinci/board-dm644x-evm.c > [...] > > @@ -620,6 +671,8 @@ davinci_evm_map_io(void) { > > /* setup input configuration for VPFE input devices */ > > dm644x_set_vpfe_config(&vpfe_cfg); > > + /* setup configuration for vpbe devices */ > > + dm644x_set_vpbe_display_config(&vpbe_display_cfg); > > dm644x_init(); > > } > > This patch should *follow* the platform patch (where > dm644x_set_vpbe_display_config() is defined), not precede it. Thanks. Will update the patch series. -Manju > > WBR, Sergei > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl
Hans, I can take a look at this (DM6467)conversion unless your colleague has already started working on t. -Manju On Sun, Dec 19, 2010 at 02:48:05, Hans Verkuil wrote: > On Saturday, December 18, 2010 16:38:29 Muralidharan Karicheri wrote: > > Hans, > > > > For davinci drivers, I will be able to do this for vpfe_capture driver > > (DM355/6446/365). > > That one already uses unlocked_ioctl. You might want to consider auditing it > to see if converting it to core-assisted locking is better. It is much easier > to verify lock-correctness that way. > > > For DM6467, will someone from your company be able to take care of > > this? > > I'll see if I can do it and ask a colleague to test for me next week. > Otherwise I can do it in the first week of January. > > Regards, > > Hans > > > > > Murali > > > > On Sat, Dec 18, 2010 at 6:31 AM, Hans Verkuil wrote: > > > Hi all, > > > > > > Now that the BKL patch series has been merged in 2.6.37 it is time > > > to work on replacing .ioctl by .unlocked_ioctl in all v4l drivers. > > > > > > I've made an inventory of all drivers that still use .ioctl and I am > > > looking for volunteers to tackle one or more drivers. > > > > > > I have CCed this email to the maintainers of the various drivers (if > > > I know who it is) in the hope that we can get this conversion done > > > as quickly as possible. > > > > > > If I have added your name to a driver, then please confirm if you > > > are able to work on it or not. If you can't work on it, but you know > > > someone else, then let me know as well. > > > > > > There is also a list of drivers where I do not know who can do the > > > conversion. > > > If you can tackle one or more of those, please respond. > > > Unfortunately, those are among the hardest to convert :-( > > > > > > It would be great if we can tackle most of these drivers for 2.6.38. > > > I think we should finish all drivers for 2.6.39 at the latest. > > > > > > There are two ways of doing the conversion: one is to do all the > > > locking within the driver, the other is to use core-assisted > > > locking. How to do the core-assisted locking is described in > > > Documentation/video4linux/v4l2-framework.txt, but I'll repeat the > > > relevant part here: > > > > > > v4l2_file_operations and locking > > > > > > > > > You can set a pointer to a mutex_lock in struct video_device. > > > Usually this will be either a top-level mutex or a mutex per device > > > node. If you want finer-grained locking then you have to set it to NULL > > > and do you own locking. > > > > > > If a lock is specified then all file operations will be serialized > > > on that lock. If you use videobuf then you must pass the same lock > > > to the videobuf queue initialize function: if videobuf has to wait > > > for a frame to arrive, then it will temporarily unlock the lock and > > > relock it afterwards. If your driver also waits in the code, then > > > you should do the same to allow other processes to access the device node > > > while the first process is waiting for something. > > > > > > The implementation of a hotplug disconnect should also take the lock > > > before calling v4l2_device_disconnect. > > > > > > > > > Driver list: > > > > > > saa7146 (Hans Verkuil) > > > mem2mem_testdev (Pawel Osciak or Marek Szyprowski) > > > cx23885 (Steve Toth) > > > cx18-alsa (Andy Walls) > > > omap24xxcam (Sakari Ailus or David Cohen) > > > au0828 (Janne Grunau) > > > cpia2 (Andy Walls or Hans Verkuil) > > > cx231xx (Mauro Carvalho Chehab) > > > davinci (Muralidharan Karicheri) > > > saa6588 (Hans Verkuil) > > > pvrusb2 (Mike Isely) > > > usbvision (Hans Verkuil) > > > s5p-fimc (Sylwester Nawrocki) > > > fsl-viu (Anatolij Gustschin) > > > tlg2300 (Mauro Carvalho Chehab) > > > zr364xx (Hans de Goede) > > > soc_camera (Guennadi Liakhovetski) > > > usbvideo/vicam (Hans de Goede) > > > s2255drv (Pete Eberlein) > > > bttv (Mauro Carvalho Chehab) > > > stk-webcam (Hans de Goede) > > > se401 (Hans de Goede) > > > si4713-i2c (Hans Verkuil) > > > dsbr100 (Hans Verkuil) > > > > > > Staging driver list: > > > > > > go7007 (Pete Eberlein) > > > tm6000 (Mauro Carvalho Chehab) > > > (stradis/cpia: will be removed in 2.6.38, so no need to do anything) > > > > > > Unassigned drivers: > > > > > > saa7134 > > > em28xx > > > cx88 > > > solo6x10 (staging driver) > > > > > > Regards, > > > > > >Hans > > > > > > -- > > > Hans Verkuil - video4linux developer - sponsored by Cisco > > > -- > > > To unsubscribe from this list: send the line "unsubscribe > > > linux-media" in the body of a message to majord...@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > > > > > > > -- > Hans Verkuil - video4linux developer - sponsored by Cisco > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in the > body of a message to majord...@vger.kernel.org More majordomo i
Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal
On Monday, December 20, 2010 13:48:51 Laurent Pinchart wrote: > Hi Hans, > > On Monday 20 December 2010 13:45:45 Hans Verkuil wrote: > > On Monday, December 20, 2010 13:35:28 Laurent Pinchart wrote: > > > On Monday 20 December 2010 13:28:06 Hans Verkuil wrote: > > > > On Monday, December 20, 2010 13:10:32 Mauro Carvalho Chehab wrote: > > > > > Em 18-12-2010 08:45, Hans Verkuil escreveu: > > > > > > On Saturday, December 18, 2010 01:54:41 Laurent Pinchart wrote: > > > > > >> On Friday 17 December 2010 18:09:39 Mauro Carvalho Chehab wrote: > > > > > >>> I didn't find any regressions at the BKL removal patches, but I > > > > > >>> noticed a few issues with qv4l2, not all related to uvcvideo. The > > > > > >>> remaining of this email is an attempt to document them for later > > > > > >>> fixes. > > > > > >>> > > > > > >>> They don't seem to be regressions caused by BKL removal, but the > > > > > >>> better would be to fix them later. > > > > > >>> > > > > > >>> - with uvcvideo and two video apps, if qv4l2 is started first, > > > > > >>> the second application doesn't start/capture. I suspect that > > > > > >>> REQBUFS (used by qv4l2 to probe mmap/userptr capabilities) > > > > > >>> create some resource locking at uvcvideo. The proper way is to > > > > > >>> lock the resources only if the driver is streaming, as other > > > > > >>> drivers and videobuf do. > > > > > >> > > > > > >> I don't agree with that. The uvcvideo driver has one buffer queue > > > > > >> per device, so if an application requests buffers on one file > > > > > >> handle it will lock other applications out. If the driver didn't > > > > > >> it would be subject to race conditions. > > > > > > > > > > > > I agree with Laurent. Once an application calls REQBUFS with > > > > > > non-zero count, then it should lock the resources needed for > > > > > > streaming. The reason behind that is that REQBUFS also locks the > > > > > > current selected format in place, since the format determines the > > > > > > amount of memory needed for the buffers. > > > > > > > > > > qv4l2 calls REQBUFS(1), then REQBUFS(0). Well, this is currently > > > > > wrong, as most drivers will only release buffers at > > > > > VIDIOC_STREAMOFF. > > > > > > > > qv4l2 first calls STREAMOFF, then REQBUFS(1), then REQBUFS(0). In the > > > > hope that one of these will actually free any buffers. It's random at > > > > the moment when drivers release buffers, one of the reasons for using > > > > vb2. > > > > > > > > > Anyway, even replacing > > > > > REQBUFS(0) with VIDIOC_STREAMOFF at qv4l2 won't help with uvcvideo. > > > > > It seems that, once buffers are requested at uvcvideo, they will > > > > > release only at close(). > > > > > > That's not correct. Buffers are released when calling REQBUFS(0). > > > However, the file handle is still marked as owning the device for > > > streaming purpose, so other applications can't change the format or > > > request buffers. > > > > Why? After REQBUFS(0) any filehandle ownership should be dropped. > > What if the application wants to change the resolution during capture ? It > will have to stop capture, call REQBUFS(0), change the format, request > buffers > and restart capture. If filehandle ownership is dropped after REQBUFS(0) that > will open the door to a race condition. That's why S_PRIORITY was invented. One of the nice properties of V4L2 is the ability to allow multiple processes to access the same device at the same time and even make modifications where possible. To prevent unwanted modifications the priority scheme was created. Unfortunately, too many drivers do not support it. It really should be core functionality. I did work on it earlier in the year, but never finished it, although it shouldn't be hard to do. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v2] [media] Add v4l2 subdev driver for NOON010PC30L image sensor
Hi Sylwester, Here is a quick review of this second patch version. Reviewed-by: Hans Verkuil On Monday, December 06, 2010 13:24:58 Sylwester Nawrocki wrote: > Add I2C/V4L2 subdev driver for Siliconfile NOON010PC30 CIF camera. > The driver implements basic functionality, i.e. CIF/QCIF/QQCIF > resolution and color format selection, automatic/manual color > balance control. Other functions like cropping, rotation/flip, > exposure etc. can be easily implemented if needed. > > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Kyungmin Park > --- > drivers/media/video/Kconfig |6 + > drivers/media/video/Makefile |1 + > drivers/media/video/noon010pc30.c | 805 > + > include/media/noon010pc30.h | 28 ++ > 4 files changed, 840 insertions(+), 0 deletions(-) > create mode 100644 drivers/media/video/noon010pc30.c > create mode 100644 include/media/noon010pc30.h > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > index da08267..1f4b418 100644 > --- a/drivers/media/video/Kconfig > +++ b/drivers/media/video/Kconfig > @@ -732,6 +732,12 @@ config VIDEO_VIA_CAMERA > Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems > with ov7670 sensors. > > +config VIDEO_NOON010PC30 > + tristate "NOON010PC30 CIF camera sensor support" > + depends on I2C && VIDEO_V4L2 > + ---help--- > + This driver supports NOON010PC30 CIF camera from Siliconfile > + > config SOC_CAMERA > tristate "SoC camera support" > depends on VIDEO_V4L2 && HAS_DMA && I2C > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > index 482f14b..fcc0644 100644 > --- a/drivers/media/video/Makefile > +++ b/drivers/media/video/Makefile > @@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o > obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o > obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o > obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o > +obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o > > obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o > obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o > diff --git a/drivers/media/video/noon010pc30.c > b/drivers/media/video/noon010pc30.c > new file mode 100644 > index 000..22eead3 > --- /dev/null > +++ b/drivers/media/video/noon010pc30.c > @@ -0,0 +1,805 @@ > +/* > + * Driver for SiliconFile NOON010PC30 CIF (1/11") Image Sensor with ISP > + * > + * Copyright (C) 2010 Samsung Electronics > + * Contact: Sylwester Nawrocki, > + * > + * Initial register configuration based on a driver authored by > + * HeungJun Kim . > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later vergsion. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +static int debug; > +module_param(debug, int, 0644); > +MODULE_PARM_DESC(debug, "Enable module debug trace. Set to 1 to enable."); > + > +#define MODULE_NAME "NOON010PC30" > +#define NOON010_NUM_SUPPLIES 3 > + > +/* > + * Register offsets within a page > + * b15..b8 - page id, b7..b0 - register address > + */ > +#define POWER_CTRL_REG 0x0001 > +#define PAGEMODE_REG 0x03 > +#define DEVICE_ID_REG0x0004 > +#define NOON010PC30_ID 0x86 > +#define VDO_CTL_REG(n) (0x0010 + (n)) > +#define SYNC_CTL_REG 0x0012 > +/* Window size and position */ > +#define WIN_ROWH_REG 0x0013 > +#define WIN_ROWL_REG 0x0014 > +#define WIN_COLH_REG 0x0015 > +#define WIN_COLL_REG 0x0016 > +#define WIN_HEIGHTH_REG 0x0017 > +#define WIN_HEIGHTL_REG 0x0018 > +#define WIN_WIDTHH_REG 0x0019 > +#define WIN_WIDTHL_REG 0x001A > +#define HBLANKH_REG 0x001B > +#define HBLANKL_REG 0x001C > +#define VSYNCH_REG 0x001D > +#define VSYNCL_REG 0x001E > +/* VSYNC control */ > +#define VS_CTL_REG(n)(0x00A1 + (n)) > +/* page 1 */ > +#define ISP_CTL_REG(n) (0x0110 + (n)) > +#define YOFS_REG 0x0119 > +#define DARK_YOFS_REG0x011A > +#define SAT_CTL_REG 0x0120 > +#define BSAT_REG 0x0121 > +#define RSAT_REG 0x0122 > +/* Color correction */ > +#define CMC_CTL_REG 0x0130 > +#define CMC_OFSGH_REG0x0133 > +#define CMC_OFSGL_REG0x0135 > +#define CMC_SIGN_REG 0x0136 > +#define CMC_GOFS_REG 0x0137 > +#define CMC_COEF_REG(n) (0x0138 + (n)) > +#define CMC_OFS_REG(n) (0x0141 + (n)) > +/* Gamma correction */ > +#define GMA_CTL_REG 0x0160 > +#define GMA_COEF_REG(n)
[patch -next] [media] timblogiw: too large value for strncpy()
This is a copy and paste error. It should be using sizeof(cap->driver) instead of sizeof(cap->card). Signed-off-by: Dan Carpenter diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c index cf48aa9..ef1b7a5 100644 --- a/drivers/media/video/timblogiw.c +++ b/drivers/media/video/timblogiw.c @@ -241,7 +241,7 @@ static int timblogiw_querycap(struct file *file, void *priv, dev_dbg(&vdev->dev, "%s: Entry\n", __func__); memset(cap, 0, sizeof(*cap)); strncpy(cap->card, TIMBLOGIWIN_NAME, sizeof(cap->card)-1); - strncpy(cap->driver, DRIVER_NAME, sizeof(cap->card)-1); + strncpy(cap->driver, DRIVER_NAME, sizeof(cap->driver) - 1); strlcpy(cap->bus_info, vdev->name, sizeof(cap->bus_info)); cap->version = TIMBLOGIW_VERSION_CODE; cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal
Hi Hans, On Monday 20 December 2010 13:45:45 Hans Verkuil wrote: > On Monday, December 20, 2010 13:35:28 Laurent Pinchart wrote: > > On Monday 20 December 2010 13:28:06 Hans Verkuil wrote: > > > On Monday, December 20, 2010 13:10:32 Mauro Carvalho Chehab wrote: > > > > Em 18-12-2010 08:45, Hans Verkuil escreveu: > > > > > On Saturday, December 18, 2010 01:54:41 Laurent Pinchart wrote: > > > > >> On Friday 17 December 2010 18:09:39 Mauro Carvalho Chehab wrote: > > > > >>> I didn't find any regressions at the BKL removal patches, but I > > > > >>> noticed a few issues with qv4l2, not all related to uvcvideo. The > > > > >>> remaining of this email is an attempt to document them for later > > > > >>> fixes. > > > > >>> > > > > >>> They don't seem to be regressions caused by BKL removal, but the > > > > >>> better would be to fix them later. > > > > >>> > > > > >>> - with uvcvideo and two video apps, if qv4l2 is started first, > > > > >>> the second application doesn't start/capture. I suspect that > > > > >>> REQBUFS (used by qv4l2 to probe mmap/userptr capabilities) > > > > >>> create some resource locking at uvcvideo. The proper way is to > > > > >>> lock the resources only if the driver is streaming, as other > > > > >>> drivers and videobuf do. > > > > >> > > > > >> I don't agree with that. The uvcvideo driver has one buffer queue > > > > >> per device, so if an application requests buffers on one file > > > > >> handle it will lock other applications out. If the driver didn't > > > > >> it would be subject to race conditions. > > > > > > > > > > I agree with Laurent. Once an application calls REQBUFS with > > > > > non-zero count, then it should lock the resources needed for > > > > > streaming. The reason behind that is that REQBUFS also locks the > > > > > current selected format in place, since the format determines the > > > > > amount of memory needed for the buffers. > > > > > > > > qv4l2 calls REQBUFS(1), then REQBUFS(0). Well, this is currently > > > > wrong, as most drivers will only release buffers at > > > > VIDIOC_STREAMOFF. > > > > > > qv4l2 first calls STREAMOFF, then REQBUFS(1), then REQBUFS(0). In the > > > hope that one of these will actually free any buffers. It's random at > > > the moment when drivers release buffers, one of the reasons for using > > > vb2. > > > > > > > Anyway, even replacing > > > > REQBUFS(0) with VIDIOC_STREAMOFF at qv4l2 won't help with uvcvideo. > > > > It seems that, once buffers are requested at uvcvideo, they will > > > > release only at close(). > > > > That's not correct. Buffers are released when calling REQBUFS(0). > > However, the file handle is still marked as owning the device for > > streaming purpose, so other applications can't change the format or > > request buffers. > > Why? After REQBUFS(0) any filehandle ownership should be dropped. What if the application wants to change the resolution during capture ? It will have to stop capture, call REQBUFS(0), change the format, request buffers and restart capture. If filehandle ownership is dropped after REQBUFS(0) that will open the door to a race condition. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal
On Monday, December 20, 2010 13:35:28 Laurent Pinchart wrote: > Hi Hans, > > On Monday 20 December 2010 13:28:06 Hans Verkuil wrote: > > On Monday, December 20, 2010 13:10:32 Mauro Carvalho Chehab wrote: > > > Em 18-12-2010 08:45, Hans Verkuil escreveu: > > > > On Saturday, December 18, 2010 01:54:41 Laurent Pinchart wrote: > > > >> On Friday 17 December 2010 18:09:39 Mauro Carvalho Chehab wrote: > > > >>> > > > >>> I didn't find any regressions at the BKL removal patches, but I > > > >>> noticed a few issues with qv4l2, not all related to uvcvideo. The > > > >>> remaining of this email is an attempt to document them for later > > > >>> fixes. > > > >>> > > > >>> They don't seem to be regressions caused by BKL removal, but the > > > >>> better would be to fix them later. > > > >>> > > > >>> - with uvcvideo and two video apps, if qv4l2 is started first, the > > > >>> second application doesn't start/capture. I suspect that REQBUFS > > > >>> (used by qv4l2 to probe mmap/userptr capabilities) create some > > > >>> resource locking at uvcvideo. The proper way is to lock the > > > >>> resources only if the driver is streaming, as other drivers and > > > >>> videobuf do. > > > >> > > > >> I don't agree with that. The uvcvideo driver has one buffer queue per > > > >> device, so if an application requests buffers on one file handle it > > > >> will lock other applications out. If the driver didn't it would be > > > >> subject to race conditions. > > > > > > > > I agree with Laurent. Once an application calls REQBUFS with non-zero > > > > count, then it should lock the resources needed for streaming. The > > > > reason behind that is that REQBUFS also locks the current selected > > > > format in place, since the format determines the amount of memory > > > > needed for the buffers. > > > > > > qv4l2 calls REQBUFS(1), then REQBUFS(0). Well, this is currently wrong, > > > as most drivers will only release buffers at VIDIOC_STREAMOFF. > > > > qv4l2 first calls STREAMOFF, then REQBUFS(1), then REQBUFS(0). In the hope > > that one of these will actually free any buffers. It's random at the > > moment when drivers release buffers, one of the reasons for using vb2. > > > > > Anyway, even replacing > > > REQBUFS(0) with VIDIOC_STREAMOFF at qv4l2 won't help with uvcvideo. It > > > seems that, once buffers are requested at uvcvideo, they will release > > > only at close(). > > That's not correct. Buffers are released when calling REQBUFS(0). However, > the > file handle is still marked as owning the device for streaming purpose, so > other applications can't change the format or request buffers. Why? After REQBUFS(0) any filehandle ownership should be dropped. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading/writing controls from different classes in a single VIDIOC_[GS]_EXT_CTRLS call
Hi Hans, On Friday 17 December 2010 20:57:32 Hans Verkuil wrote: > On Friday, December 17, 2010 20:52:25 Hans Verkuil wrote: > > On Friday, December 17, 2010 17:17:05 Laurent Pinchart wrote: > > > Hi Hans, > > > > > > I've recently run into an issue when porting a sensor driver to the > > > control framework. > > > > > > A userspace application using that driver using VIDIOC_G_EXT_CTRLS to > > > retrieve the value of a bunch of controls in a single call. Those > > > controls don't belong to the same class, and the application started > > > failing. > > > > > > What's the rationale behind forbidding that ? > > > > Which driver? The control framework doesn't have that limitation anymore. > > Originally the API had that limitation, mostly to reduce driver > > complexity, but that limitation is lifted in the control framework. > > A follow-up: if the ctrl_class field of v4l2_ext_controls is set to a > specific control class by the application, then all controls in the list > must belong to that control class. This is checked by the control > framework. This matches the behavior as defined in the spec. If ctrl_class > is 0, then the control framework allows controls from any class. You're correct. Thanks for the clarification. > This doesn't seem to be documented yet. I thought I did :-( The VIDIOC_[GS]_EXT_CTRLS documentation should state that ctrl_class = 0 is a valid option. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal
Hi Hans, On Monday 20 December 2010 13:28:06 Hans Verkuil wrote: > On Monday, December 20, 2010 13:10:32 Mauro Carvalho Chehab wrote: > > Em 18-12-2010 08:45, Hans Verkuil escreveu: > > > On Saturday, December 18, 2010 01:54:41 Laurent Pinchart wrote: > > >> On Friday 17 December 2010 18:09:39 Mauro Carvalho Chehab wrote: > > >>> > > >>> I didn't find any regressions at the BKL removal patches, but I > > >>> noticed a few issues with qv4l2, not all related to uvcvideo. The > > >>> remaining of this email is an attempt to document them for later > > >>> fixes. > > >>> > > >>> They don't seem to be regressions caused by BKL removal, but the > > >>> better would be to fix them later. > > >>> > > >>> - with uvcvideo and two video apps, if qv4l2 is started first, the > > >>> second application doesn't start/capture. I suspect that REQBUFS > > >>> (used by qv4l2 to probe mmap/userptr capabilities) create some > > >>> resource locking at uvcvideo. The proper way is to lock the > > >>> resources only if the driver is streaming, as other drivers and > > >>> videobuf do. > > >> > > >> I don't agree with that. The uvcvideo driver has one buffer queue per > > >> device, so if an application requests buffers on one file handle it > > >> will lock other applications out. If the driver didn't it would be > > >> subject to race conditions. > > > > > > I agree with Laurent. Once an application calls REQBUFS with non-zero > > > count, then it should lock the resources needed for streaming. The > > > reason behind that is that REQBUFS also locks the current selected > > > format in place, since the format determines the amount of memory > > > needed for the buffers. > > > > qv4l2 calls REQBUFS(1), then REQBUFS(0). Well, this is currently wrong, > > as most drivers will only release buffers at VIDIOC_STREAMOFF. > > qv4l2 first calls STREAMOFF, then REQBUFS(1), then REQBUFS(0). In the hope > that one of these will actually free any buffers. It's random at the > moment when drivers release buffers, one of the reasons for using vb2. > > > Anyway, even replacing > > REQBUFS(0) with VIDIOC_STREAMOFF at qv4l2 won't help with uvcvideo. It > > seems that, once buffers are requested at uvcvideo, they will release > > only at close(). That's not correct. Buffers are released when calling REQBUFS(0). However, the file handle is still marked as owning the device for streaming purpose, so other applications can't change the format or request buffers. > > One consequence on the way uvcvideo is currently doing it is that, if you > > use qv4l2, it is impossible to change the video size, as it returns > > -EBUSY, if you ask it to > > > > select a different format (even without streaming): > > $ ./qv4l2 > > Set Capture Format: Device or resource busy > > > > > The reason a lot of drivers don't do this is partially because for many > > > TV capture drivers it is highly unlikely that the buffer size will > > > change after calling REQBUFS (there are basically only two formats: > > > 720x480 or 720x576 and users will normally never change between the > > > two). However, this is much more likely to happen for webcams and > > > embedded systems supporting HDTV. > > > > What applications do, when they need to change the formats, is to call > > REQBUFS again. > > > > > The other reason is probably because driver developers simple do not > > > realize they need to lock the resources on REQBUFS. I'm sure many > > > existing drivers will fail miserably if you change the format after > > > calling REQBUFS (particularly with mmap streaming mode). > > > > I didn't make any test, but I don't think they'll fail (at least, on the > > drivers that use videobuf), as streaming format will be stored at the > > videobuf handling (at buffer_prepare callback). > > > > So, if you change the format, the change will be applied only at the next > > call to REQBUFS. > > This behavior isn't according to the spec. G/S_FMT relate to the current > format, not to some future format. Most non-videobuf drivers will not > support this behavior. > > It should be simple, really: > > STREAMOFF > REQBUFS(0) > > That's all that should be needed to stop streaming and return all buffers > to the app. This is what uvc should also support (and I actually thought > it did). That's what uvcvideo does. > Attempts to change formats while buffers have been requested should be > blocked with EBUSY. It's all perfectly reasonable. Well, perhaps next year > we might succeed in having all drivers behave consistently... -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal
On Monday, December 20, 2010 13:10:32 Mauro Carvalho Chehab wrote: > Em 18-12-2010 08:45, Hans Verkuil escreveu: > > On Saturday, December 18, 2010 01:54:41 Laurent Pinchart wrote: > >> Hi Mauro, > >> > >> On Friday 17 December 2010 18:09:39 Mauro Carvalho Chehab wrote: > >>> Em 14-12-2010 08:55, Laurent Pinchart escreveu: > Hi Mauro, > > Please don't forget this pull request for 2.6.37. > >>> > >>> Pull request for upstream sent today. > >> > >> Thank you. > >> > >>> I didn't find any regressions at the BKL removal patches, but I noticed a > >>> few issues with qv4l2, not all related to uvcvideo. The remaining of this > >>> email is an attempt to document them for later fixes. > >>> > >>> They don't seem to be regressions caused by BKL removal, but the better > >>> would be to fix them later. > >>> > >>> - with uvcvideo and two video apps, if qv4l2 is started first, the second > >>> application doesn't start/capture. I suspect that REQBUFS (used by qv4l2 > >>> to probe mmap/userptr capabilities) create some resource locking at > >>> uvcvideo. The proper way is to lock the resources only if the driver is > >>> streaming, as other drivers and videobuf do. > >> > >> I don't agree with that. The uvcvideo driver has one buffer queue per > >> device, > >> so if an application requests buffers on one file handle it will lock > >> other > >> applications out. If the driver didn't it would be subject to race > >> conditions. > > > > I agree with Laurent. Once an application calls REQBUFS with non-zero count, > > then it should lock the resources needed for streaming. The reason behind > > that > > is that REQBUFS also locks the current selected format in place, since the > > format determines the amount of memory needed for the buffers. > > qv4l2 calls REQBUFS(1), then REQBUFS(0). Well, this is currently wrong, as > most > drivers will only release buffers at VIDIOC_STREAMOFF. qv4l2 first calls STREAMOFF, then REQBUFS(1), then REQBUFS(0). In the hope that one of these will actually free any buffers. It's random at the moment when drivers release buffers, one of the reasons for using vb2. > Anyway, even replacing > REQBUFS(0) with VIDIOC_STREAMOFF at qv4l2 won't help with uvcvideo. It seems > that, > once buffers are requested at uvcvideo, they will release only at close(). > > One consequence on the way uvcvideo is currently doing it is that, if you use > qv4l2, > it is impossible to change the video size, as it returns -EBUSY, if you ask > it to > select a different format (even without streaming): > $ ./qv4l2 > Set Capture Format: Device or resource busy > > > The reason a lot of drivers don't do this is partially because for many TV > > capture drivers it is highly unlikely that the buffer size will change after > > calling REQBUFS (there are basically only two formats: 720x480 or 720x576 > > and > > users will normally never change between the two). However, this is much > > more > > likely to happen for webcams and embedded systems supporting HDTV. > > What applications do, when they need to change the formats, is to call > REQBUFS again. > > > The other reason is probably because driver developers simple do not realize > > they need to lock the resources on REQBUFS. I'm sure many existing drivers > > will > > fail miserably if you change the format after calling REQBUFS (particularly > > with mmap streaming mode). > > I didn't make any test, but I don't think they'll fail (at least, on the > drivers > that use videobuf), as streaming format will be stored at the videobuf > handling > (at buffer_prepare callback). > > So, if you change the format, the change will be applied only at the next call > to REQBUFS. This behavior isn't according to the spec. G/S_FMT relate to the current format, not to some future format. Most non-videobuf drivers will not support this behavior. It should be simple, really: STREAMOFF REQBUFS(0) That's all that should be needed to stop streaming and return all buffers to the app. This is what uvc should also support (and I actually thought it did). Attempts to change formats while buffers have been requested should be blocked with EBUSY. It's all perfectly reasonable. Well, perhaps next year we might succeed in having all drivers behave consistently... Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal
Em 18-12-2010 08:45, Hans Verkuil escreveu: > On Saturday, December 18, 2010 01:54:41 Laurent Pinchart wrote: >> Hi Mauro, >> >> On Friday 17 December 2010 18:09:39 Mauro Carvalho Chehab wrote: >>> Em 14-12-2010 08:55, Laurent Pinchart escreveu: Hi Mauro, Please don't forget this pull request for 2.6.37. >>> >>> Pull request for upstream sent today. >> >> Thank you. >> >>> I didn't find any regressions at the BKL removal patches, but I noticed a >>> few issues with qv4l2, not all related to uvcvideo. The remaining of this >>> email is an attempt to document them for later fixes. >>> >>> They don't seem to be regressions caused by BKL removal, but the better >>> would be to fix them later. >>> >>> - with uvcvideo and two video apps, if qv4l2 is started first, the second >>> application doesn't start/capture. I suspect that REQBUFS (used by qv4l2 >>> to probe mmap/userptr capabilities) create some resource locking at >>> uvcvideo. The proper way is to lock the resources only if the driver is >>> streaming, as other drivers and videobuf do. >> >> I don't agree with that. The uvcvideo driver has one buffer queue per >> device, >> so if an application requests buffers on one file handle it will lock other >> applications out. If the driver didn't it would be subject to race >> conditions. > > I agree with Laurent. Once an application calls REQBUFS with non-zero count, > then it should lock the resources needed for streaming. The reason behind that > is that REQBUFS also locks the current selected format in place, since the > format determines the amount of memory needed for the buffers. qv4l2 calls REQBUFS(1), then REQBUFS(0). Well, this is currently wrong, as most drivers will only release buffers at VIDIOC_STREAMOFF. Anyway, even replacing REQBUFS(0) with VIDIOC_STREAMOFF at qv4l2 won't help with uvcvideo. It seems that, once buffers are requested at uvcvideo, they will release only at close(). One consequence on the way uvcvideo is currently doing it is that, if you use qv4l2, it is impossible to change the video size, as it returns -EBUSY, if you ask it to select a different format (even without streaming): $ ./qv4l2 Set Capture Format: Device or resource busy > The reason a lot of drivers don't do this is partially because for many TV > capture drivers it is highly unlikely that the buffer size will change after > calling REQBUFS (there are basically only two formats: 720x480 or 720x576 and > users will normally never change between the two). However, this is much more > likely to happen for webcams and embedded systems supporting HDTV. What applications do, when they need to change the formats, is to call REQBUFS again. > The other reason is probably because driver developers simple do not realize > they need to lock the resources on REQBUFS. I'm sure many existing drivers > will > fail miserably if you change the format after calling REQBUFS (particularly > with mmap streaming mode). I didn't make any test, but I don't think they'll fail (at least, on the drivers that use videobuf), as streaming format will be stored at the videobuf handling (at buffer_prepare callback). So, if you change the format, the change will be applied only at the next call to REQBUFS. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v7 01/12] media: Media device node support
The media_devnode structure provides support for registering and unregistering character devices using a dynamic major number. Reference counting is handled internally, making device drivers easier to write without having to solve the open/disconnect race condition issue over and over again. The code is based on video/v4l2-dev.c. Signed-off-by: Laurent Pinchart --- drivers/media/Kconfig | 13 ++ drivers/media/Makefile| 10 +- drivers/media/media-devnode.c | 321 + include/media/media-devnode.h | 97 + 4 files changed, 439 insertions(+), 2 deletions(-) create mode 100644 drivers/media/media-devnode.c create mode 100644 include/media/media-devnode.h diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index a28541b..6b946e6 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -14,6 +14,19 @@ if MEDIA_SUPPORT comment "Multimedia core support" # +# Media controller +# + +config MEDIA_CONTROLLER + bool "Media Controller API (EXPERIMENTAL)" + depends on EXPERIMENTAL + ---help--- + Enable the media controller API used to query media devices internal + topology and configure it dynamically. + + This API is mostly used by camera interfaces in embedded platforms. + +# # V4L core and enabled API's # diff --git a/drivers/media/Makefile b/drivers/media/Makefile index 499b081..3a08991 100644 --- a/drivers/media/Makefile +++ b/drivers/media/Makefile @@ -2,7 +2,13 @@ # Makefile for the kernel multimedia device drivers. # +media-objs := media-devnode.o + +ifeq ($(CONFIG_MEDIA_CONTROLLER),y) + obj-$(CONFIG_MEDIA_SUPPORT) += media.o +endif + obj-y += common/ IR/ video/ -obj-$(CONFIG_VIDEO_DEV) += radio/ -obj-$(CONFIG_DVB_CORE) += dvb/ +obj-$(CONFIG_VIDEO_DEV)+= radio/ +obj-$(CONFIG_DVB_CORE) += dvb/ diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c new file mode 100644 index 000..7804b70 --- /dev/null +++ b/drivers/media/media-devnode.c @@ -0,0 +1,321 @@ +/* + * Media device node + * + * Copyright (C) 2010 Nokia Corporation + * + * Based on drivers/media/video/v4l2_dev.c code authored by + * Mauro Carvalho Chehab (version 2) + * Alan Cox, (version 1) + * + * Contacts: Laurent Pinchart + * Sakari Ailus + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * -- + * + * Generic media device node infrastructure to register and unregister + * character devices using a dynamic major number and proper reference + * counting. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define MEDIA_NUM_DEVICES 256 +#define MEDIA_NAME "media" + +static dev_t media_dev_t; + +/* + * Active devices + */ +static DEFINE_MUTEX(media_devnode_lock); +static DECLARE_BITMAP(media_devnode_nums, MEDIA_NUM_DEVICES); + +/* Called when the last user of the media device exits. */ +static void media_devnode_release(struct device *cd) +{ + struct media_devnode *mdev = to_media_devnode(cd); + + mutex_lock(&media_devnode_lock); + + /* Delete the cdev on this minor as well */ + cdev_del(&mdev->cdev); + + /* Mark device node number as free */ + clear_bit(mdev->minor, media_devnode_nums); + + mutex_unlock(&media_devnode_lock); + + /* Release media_devnode and perform other cleanups as needed. */ + if (mdev->release) + mdev->release(mdev); +} + +static struct bus_type media_bus_type = { + .name = MEDIA_NAME, +}; + +static ssize_t media_read(struct file *filp, char __user *buf, + size_t sz, loff_t *off) +{ + struct media_devnode *mdev = media_devnode_data(filp); + + if (!mdev->fops->read) + return -EINVAL; + if (!media_devnode_is_registered(mdev)) + return -EIO; + return mdev->fops->read(filp, buf, sz, off); +} + +static ssize_t media_write(struct file *filp, const char __user *buf, + size_t sz, loff_t *off) +{ + struct media_devnode *mdev = media_devnode_data(filp); + + if (!mdev->fops->write) + return -EINVAL; + if (!media_devnode_is_registered(mdev)) + return -EIO; + return mdev->fops->write(filp, buf,
[RFC/PATCH v7 03/12] media: Entities, pads and links
As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. An entity is a basic media hardware building block. It can correspond to a large variety of logical blocks such as physical hardware devices (CMOS sensor for instance), logical hardware devices (a building block in a System-on-Chip image processing pipeline), DMA channels or physical connectors. A pad is a connection endpoint through which an entity can interact with other entities. Data (not restricted to video) produced by an entity flows from the entity's output to one or more entity inputs. Pads should not be confused with physical pins at chip boundaries. A link is a point-to-point oriented connection between two pads, either on the same entity or on different entities. Data flows from a source pad to a sink pad. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil initial work. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus --- Documentation/DocBook/v4l/media-controller.xml | 20 +++ Documentation/media-framework.txt | 151 drivers/media/Makefile |2 +- drivers/media/media-device.c | 56 + drivers/media/media-entity.c | 147 +++ include/media/media-device.h | 19 +++ include/media/media-entity.h | 122 +++ 7 files changed, 516 insertions(+), 1 deletions(-) create mode 100644 drivers/media/media-entity.c create mode 100644 include/media/media-entity.h diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index 253ddb4..f89228d 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -53,4 +53,24 @@ implementing policies that belong to userspace. The media controller API aims at solving those problems. + + +Media device model +Discovering a device internal topology, and configuring it at runtime, +is one of the goals of the media controller API. To achieve this, hardware +devices are modelled as an oriented graph of building blocks called entities +connected through pads. +An entity is a basic media hardware or software building block. It can +correspond to a large variety of logical blocks such as physical hardware +devices (CMOS sensor for instance), logical hardware devices (a building +block in a System-on-Chip image processing pipeline), DMA channels or +physical connectors. +A pad is a connection endpoint through which an entity can interact +with other entities. Data (not restricted to video) produced by an entity +flows from the entity's output to one or more entity inputs. Pads should not +be confused with physical pins at chip boundaries. +A link is a point-to-point oriented connection between two pads, +either on the same entity or on different entities. Data flows from a source +pad to a sink pad. + diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 84fa43a..c35b641 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -13,6 +13,30 @@ Documentation/DocBook/v4l/media-controller.xml. This document will focus on the kernel-side implementation of the media framework. +Abstract media device model +--- + +Discovering a device internal topology, and configuring it at runtime, is one +of the goals of the media framework. To achieve this, hardware devices are +modeled as an oriented graph of building blocks called entities connected +through pads. + +An entity is a basic media hardware building block. It can correspond to +a large variety of logic
[RFC/PATCH v7 09/12] media: Pipelines and media streams
Drivers often need to associate pipeline objects to entities, and to take stream state into account when configuring entities and links. The pipeline API helps drivers manage that information. When starting streaming, drivers call media_entity_pipeline_start(). The function marks all entities connected to the given entity through enabled links, either directly or indirectly, as streaming. Similarly, when stopping the stream, drivers call media_entity_pipeline_stop(). The media_entity_pipeline_start() function takes a pointer to a media pipeline and stores it in every entity in the graph. Drivers should embed the media_pipeline structure in higher-level pipeline structures and can then access the pipeline through the media_entity structure. Link configuration will fail with -EBUSY by default if either end of the link is a streaming entity, unless the link is marked with the MEDIA_LINK_FLAG_DYNAMIC flag. Signed-off-by: Laurent Pinchart --- Documentation/DocBook/v4l/media-ioc-enum-links.xml |5 ++ Documentation/DocBook/v4l/media-ioc-setup-link.xml |3 + Documentation/media-framework.txt | 38 ++ drivers/media/media-entity.c | 74 include/linux/media.h |1 + include/media/media-entity.h | 10 +++ 6 files changed, 131 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/v4l/media-ioc-enum-links.xml index bcec89b..aa164f4 100644 --- a/Documentation/DocBook/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/v4l/media-ioc-enum-links.xml @@ -179,6 +179,11 @@ The link enabled state can't be modified at runtime. An immutable link is always enabled. + + MEDIA_LINK_FLAG_DYNAMIC + The link enabled state can be modified during streaming. This + flag is set by drivers and is read-only for applications. + diff --git a/Documentation/DocBook/v4l/media-ioc-setup-link.xml b/Documentation/DocBook/v4l/media-ioc-setup-link.xml index 09ab3d2..2331e76 100644 --- a/Documentation/DocBook/v4l/media-ioc-setup-link.xml +++ b/Documentation/DocBook/v4l/media-ioc-setup-link.xml @@ -60,6 +60,9 @@ Link configuration has no side effect on other links. If an enabled link at the sink pad prevents the link from being enabled, the driver returns with an &EBUSY;. +Only links marked with the DYNAMIC link flag can +be enabled/disabled while streaming media data. Attempting to enable or +disable a streaming non-dynamic link will return an &EBUSY;. If the specified link can't be found the driver returns with an &EINVAL;. diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 4603417..7163dcb 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -343,3 +343,41 @@ link_setup calls are made with power active on the source and sink entities. In other words, enabling or disabling a link propagates reference count changes through the graph, and the final state is identical to what it would have been if the link had been enabled or disabled from the start. + + +Pipelines and media streams +--- + +When starting streaming, drivers must notify all entities in the pipeline to +prevent link states from being modified during streaming by calling + + media_entity_pipeline_start(struct media_entity *entity, + struct media_pipeline *pipe); + +The function will mark all entities connected to the given entity through +enabled links, either directly or indirectly, as streaming. + +The media_pipeline instance pointed to by the pipe argument will be stored in +every entity in the pipeline. Drivers should embed the media_pipeline structure +in higher-level pipeline structures and can then access the pipeline through +the media_entity pipe field. + +Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must +be identical for all nested calls to the function. + +When stopping the stream, drivers must notify the entities with + + media_entity_pipeline_stop(struct media_entity *entity); + +If multiple calls to media_entity_pipeline_start() have been made the same +number of media_entity_pipeline_stop() calls are required to stop streaming. The +media_entity pipe field is reset to NULL on the last nested stop call. + +Link configuration will fail with -EBUSY by default if either end of the link is +a streaming entity. Links that can be modified while streaming must be marked +with the MEDIA_LINK_FLAG_DYNAMIC flag. + +If other operations need to be disallowed on streaming entities (such as +changing entities configuration parameters) drivers can explictly check the +media_entity stream_count field to find out if an entity is streaming. This +operation must
[RFC/PATCH v7 07/12] media: Entities, pads and links enumeration
Create the following two ioctls and implement them at the media device level to enumerate entities, pads and links. - MEDIA_IOC_ENUM_ENTITIES: Enumerate entities and their properties - MEDIA_IOC_ENUM_LINKS: Enumerate all pads and links for a given entity Entity IDs can be non-contiguous. Userspace applications should enumerate entities using the MEDIA_ENTITY_ID_FLAG_NEXT flag. When the flag is set in the entity ID, the MEDIA_IOC_ENUM_ENTITIES will return the next entity with an ID bigger than the requested one. Only forward links that originate at one of the entity's source pads are returned during the enumeration process. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus --- Documentation/DocBook/media-entities.tmpl |8 + Documentation/DocBook/v4l/media-controller.xml |2 + .../DocBook/v4l/media-ioc-device-info.xml |3 +- .../DocBook/v4l/media-ioc-enum-entities.xml| 308 Documentation/DocBook/v4l/media-ioc-enum-links.xml | 202 + drivers/media/media-device.c | 123 include/linux/media.h | 85 ++ include/media/media-entity.h | 24 +-- 8 files changed, 731 insertions(+), 24 deletions(-) create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-entities.xml create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-links.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 6af3375..6e7dae4 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -92,6 +92,8 @@ VIDIOC_UNSUBSCRIBE_EVENT"> MEDIA_IOC_DEVICE_INFO"> +MEDIA_IOC_ENUM_ENTITIES"> +MEDIA_IOC_ENUM_LINKS"> v4l2_std_id"> @@ -188,6 +190,10 @@ v4l2_window"> media_device_info"> +media_entity_desc"> +media_links_enum"> +media_pad_desc"> +media_link_desc"> EACCES error code"> @@ -334,6 +340,8 @@ + + diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index a46b786..2c4fd2b 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -83,4 +83,6 @@ &sub-media-ioctl; &sub-media-ioc-device-info; + &sub-media-ioc-enum-entities; + &sub-media-ioc-enum-links; diff --git a/Documentation/DocBook/v4l/media-ioc-device-info.xml b/Documentation/DocBook/v4l/media-ioc-device-info.xml index 278a312..1f32373 100644 --- a/Documentation/DocBook/v4l/media-ioc-device-info.xml +++ b/Documentation/DocBook/v4l/media-ioc-device-info.xml @@ -27,7 +27,8 @@ fd - &fd; + File descriptor returned by + open(). diff --git a/Documentation/DocBook/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml new file mode 100644 index 000..c898aab --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml @@ -0,0 +1,308 @@ + + +ioctl MEDIA_IOC_ENUM_ENTITIES +&manvol; + + + +MEDIA_IOC_ENUM_ENTITIES +Enumerate entities and their properties + + + + + + int ioctl + int fd + int request + struct media_entity_desc *argp + + + + + +Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_ENUM_ENTITIES + + + + argp + + + + + + + + +Description +To query the attributes of an entity, applications set the id field +of a &media-entity-desc; structure and call the MEDIA_IOC_ENUM_ENTITIES +ioctl with a pointer to this structure. The driver fills the rest of the +structure or returns an &EINVAL; when the id is invalid. +Entities can be enumerated by or'ing the id with the +MEDIA_ENTITY_ID_FLAG_NEXT flag. The driver will return +information about the entity with the smallest id strictly larger than the +requested one ('next entity'), or the &EINVAL; if there is none. +Entity IDs can be non-contiguous. Applications must +not try to enumerate entities by calling +MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error. +Two or more entities that share a common non-zero +group_id value are considered as logically +grouped. Groups are used to report + + ALSA, VBI and video nodes that carry the same media + stream + lens and flash controllers associated with a sensor + + + + + struct media_entity_desc + + + + + + + + + __u32 + id + + + Entity id, set by the application. When the id is or'ed with + MEDIA_ENTITY_ID_FLAG_NEXT, the driver clears + the flag and returns t
[RFC/PATCH v7 06/12] media: Media device information query
Create the following ioctl and implement it at the media device level to query device information. - MEDIA_IOC_DEVICE_INFO: Query media device information The ioctl and its data structure are defined in the new kernel header linux/media.h available to userspace applications. Signed-off-by: Laurent Pinchart --- Documentation/DocBook/media-entities.tmpl | 12 ++ Documentation/DocBook/v4l/media-controller.xml | 10 ++ Documentation/DocBook/v4l/media-func-close.xml | 59 + Documentation/DocBook/v4l/media-func-ioctl.xml | 116 + Documentation/DocBook/v4l/media-func-open.xml | 94 ++ .../DocBook/v4l/media-ioc-device-info.xml | 132 drivers/media/media-device.c | 57 + include/linux/Kbuild |1 + include/linux/media.h | 45 +++ 9 files changed, 526 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/media-func-close.xml create mode 100644 Documentation/DocBook/v4l/media-func-ioctl.xml create mode 100644 Documentation/DocBook/v4l/media-func-open.xml create mode 100644 Documentation/DocBook/v4l/media-ioc-device-info.xml create mode 100644 include/linux/media.h diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 61d6f11..6af3375 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -11,6 +11,10 @@ select()"> write()"> +close()"> +ioctl()"> +open()"> + VIDIOC_CROPCAP"> VIDIOC_DBG_G_CHIP_IDENT"> @@ -87,6 +91,8 @@ VIDIOC_TRY_FMT"> VIDIOC_UNSUBSCRIBE_EVENT"> +MEDIA_IOC_DEVICE_INFO"> + v4l2_std_id"> @@ -181,6 +187,8 @@ v4l2_vbi_format"> v4l2_window"> +media_device_info"> + EACCES error code"> EAGAIN error code"> @@ -322,6 +330,10 @@ + + + + diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index f89228d..a46b786 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -74,3 +74,13 @@ pad to a sink pad. + + + Function Reference + + &sub-media-open; + &sub-media-close; + &sub-media-ioctl; + + &sub-media-ioc-device-info; + diff --git a/Documentation/DocBook/v4l/media-func-close.xml b/Documentation/DocBook/v4l/media-func-close.xml new file mode 100644 index 000..be149c8 --- /dev/null +++ b/Documentation/DocBook/v4l/media-func-close.xml @@ -0,0 +1,59 @@ + + +media close() +&manvol; + + + +media-close +Close a media device + + + + + #include+ + int close + int fd + + + + + +Arguments + + + + fd + + &fd; + + + + + + +Description + +Closes the media device. Resources associated with the file descriptor +are freed. The device configuration remain unchanged. + + + +Return Value + +close returns 0 on success. On error, -1 is +returned, and errno is set appropriately. Possible error +codes are: + + + + EBADF + + fd is not a valid open file descriptor. + + + + + + diff --git a/Documentation/DocBook/v4l/media-func-ioctl.xml b/Documentation/DocBook/v4l/media-func-ioctl.xml new file mode 100644 index 000..bda8604 --- /dev/null +++ b/Documentation/DocBook/v4l/media-func-ioctl.xml @@ -0,0 +1,116 @@ + + +media ioctl() +&manvol; + + + +media-ioctl +Control a media device + + + + + #include + + int ioctl + int fd + int request + void *argp + + + + + +Arguments + + + + fd + + &fd; + + + + request + + Media ioctl request code as defined in the media.h header file, + for example MEDIA_IOC_SETUP_LINK. + + + + argp + + Pointer to a request-specific structure. + + + + + + +Description +The ioctl() function manipulates media device +parameters. The argument fd must be an open file +descriptor. +The ioctl request code specifies the media +function to be called. It has encoded in it whether the argument is an +input, output or read/write parameter, and the size of the argument +argp in bytes. +Macros and structures definitions specifying media ioctl requests and +their parameters are located in the media.h header file. All media ioctl +requests, their respective function and parameters are specified in +. + + + +Return Value + +ioctl() returns 0 on +success. On failure, -1 is returned, and the +errno variable is set appropriately. Generic error codes +are listed below, and request-specific error codes are l
[RFC/PATCH v4 0/7] OMAP3 ISP driver
Hi everybody, Here's the fourth version of the OMAP3 ISP driver patches, updated to 2.6.37-rc6 and the latest changes in the media controller and sub-device APIs. You can find the patches in http://git.linuxtv.org/pinchartl/media.git as usual (media-0004-omap3isp). The "v4l: Fix a use-before-set in the control framework" and "v4l: Add subdev sensor g_skip_frames operation" patches have been discussed on the linux-media mailing list and acked. The "v4l: subdev: Generic ioctl support" will be discussed separately on the list in the near future. Laurent Pinchart (6): v4l: subdev: Generic ioctl support v4l: Add subdev sensor g_skip_frames operation v4l: Include linux/videodev2.h in media/v4l2-ctrls.h v4l: Fix a use-before-set in the control framework omap3: Add function to register omap3isp platform device structure OMAP3 ISP driver Tuukka Toivonen (1): ARM: OMAP3: Update Camera ISP definitions for OMAP3630 Documentation/video4linux/v4l2-framework.txt |5 + arch/arm/mach-omap2/devices.c| 48 +- arch/arm/mach-omap2/devices.h| 17 + arch/arm/plat-omap/include/plat/omap34xx.h | 16 +- drivers/media/video/Kconfig | 13 + drivers/media/video/Makefile |2 + drivers/media/video/isp/Makefile | 13 + drivers/media/video/isp/cfa_coef_table.h | 601 +++ drivers/media/video/isp/gamma_table.h| 90 + drivers/media/video/isp/isp.c| 1980 +++ drivers/media/video/isp/isp.h| 407 + drivers/media/video/isp/ispccdc.c| 2236 ++ drivers/media/video/isp/ispccdc.h| 221 +++ drivers/media/video/isp/ispccp2.c| 1110 + drivers/media/video/isp/ispccp2.h| 101 ++ drivers/media/video/isp/ispcsi2.c| 1278 +++ drivers/media/video/isp/ispcsi2.h| 169 ++ drivers/media/video/isp/ispcsiphy.c | 247 +++ drivers/media/video/isp/ispcsiphy.h | 74 + drivers/media/video/isp/isph3a.h | 117 ++ drivers/media/video/isp/isph3a_aewb.c| 356 drivers/media/video/isp/isph3a_af.c | 410 + drivers/media/video/isp/isphist.c| 505 ++ drivers/media/video/isp/isphist.h| 40 + drivers/media/video/isp/isppreview.c | 2112 drivers/media/video/isp/isppreview.h | 214 +++ drivers/media/video/isp/ispqueue.c | 1135 + drivers/media/video/isp/ispqueue.h | 184 +++ drivers/media/video/isp/ispreg.h | 1655 +++ drivers/media/video/isp/ispresizer.c | 1721 drivers/media/video/isp/ispresizer.h | 149 ++ drivers/media/video/isp/ispstat.c| 1093 + drivers/media/video/isp/ispstat.h| 168 ++ drivers/media/video/isp/ispvideo.c | 1200 ++ drivers/media/video/isp/ispvideo.h | 183 +++ drivers/media/video/isp/luma_enhance_table.h | 154 ++ drivers/media/video/isp/noise_filter_table.h | 90 + drivers/media/video/v4l2-ctrls.c |2 +- drivers/media/video/v4l2-subdev.c|2 +- include/linux/Kbuild |1 + include/linux/omap3isp.h | 631 include/media/v4l2-ctrls.h |1 + include/media/v4l2-subdev.h |4 + 43 files changed, 20736 insertions(+), 19 deletions(-) create mode 100644 arch/arm/mach-omap2/devices.h create mode 100644 drivers/media/video/isp/Makefile create mode 100644 drivers/media/video/isp/cfa_coef_table.h create mode 100644 drivers/media/video/isp/gamma_table.h create mode 100644 drivers/media/video/isp/isp.c create mode 100644 drivers/media/video/isp/isp.h create mode 100644 drivers/media/video/isp/ispccdc.c create mode 100644 drivers/media/video/isp/ispccdc.h create mode 100644 drivers/media/video/isp/ispccp2.c create mode 100644 drivers/media/video/isp/ispccp2.h create mode 100644 drivers/media/video/isp/ispcsi2.c create mode 100644 drivers/media/video/isp/ispcsi2.h create mode 100644 drivers/media/video/isp/ispcsiphy.c create mode 100644 drivers/media/video/isp/ispcsiphy.h create mode 100644 drivers/media/video/isp/isph3a.h create mode 100644 drivers/media/video/isp/isph3a_aewb.c create mode 100644 drivers/media/video/isp/isph3a_af.c create mode 100644 drivers/media/video/isp/isphist.c create mode 100644 drivers/media/video/isp/isphist.h create mode 100644 drivers/media/video/isp/isppreview.c create mode 100644 drivers/media/video/isp/isppreview.h create mode 100644 drivers/media/video/isp/ispqueue.c create mode 100644 drivers/media/video/isp/ispqueue.h create mode 100644 drivers/media/video/isp/ispreg.h create mode 100644 drivers/media/video/isp/ispresizer.c create mode 100644 drivers/media/video/isp/ispresizer
[RFC/PATCH v4 1/7] v4l: subdev: Generic ioctl support
Instead of returning an error when receiving an ioctl call with an unsupported command, forward the call to the subdev core::ioctl handler. Signed-off-by: Laurent Pinchart --- Documentation/video4linux/v4l2-framework.txt |5 + drivers/media/video/v4l2-subdev.c|2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index d0fb880..1bb5f22 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -407,6 +407,11 @@ VIDIOC_UNSUBSCRIBE_EVENT To properly support events, the poll() file operation is also implemented. +Private ioctls + + All ioctls not in the above list are passed directly to the sub-device + driver through the core::ioctl operation. + I2C sub-device drivers -- diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 09d1db0..2d4a6fd 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -278,7 +278,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) } #endif default: - return -ENOIOCTLCMD; + return v4l2_subdev_call(sd, core, ioctl, cmd, arg); } return 0; -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v4 3/7] v4l: Include linux/videodev2.h in media/v4l2-ctrls.h
The later makes extensive use of structures defined in the former. Signed-off-by: Laurent Pinchart --- include/media/v4l2-ctrls.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h index 9b7bea9..3b133b7 100644 --- a/include/media/v4l2-ctrls.h +++ b/include/media/v4l2-ctrls.h @@ -23,6 +23,7 @@ #include #include +#include /* forward references */ struct v4l2_ctrl_handler; -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v4 4/7] v4l: Fix a use-before-set in the control framework
v4l2_queryctrl sets the step value based on the control type. That would be fine if it used the control type stored in the V4L2 kernel control object, not the one stored in the userspace ioctl structure that has just been memset to 0. Fix this. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil --- drivers/media/video/v4l2-ctrls.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c index 9d2502c..5f74fec0 100644 --- a/drivers/media/video/v4l2-ctrls.c +++ b/drivers/media/video/v4l2-ctrls.c @@ -1338,7 +1338,7 @@ int v4l2_queryctrl(struct v4l2_ctrl_handler *hdl, struct v4l2_queryctrl *qc) qc->minimum = ctrl->minimum; qc->maximum = ctrl->maximum; qc->default_value = ctrl->default_value; - if (qc->type == V4L2_CTRL_TYPE_MENU) + if (ctrl->type == V4L2_CTRL_TYPE_MENU) qc->step = 1; else qc->step = ctrl->step; -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v4 5/7] ARM: OMAP3: Update Camera ISP definitions for OMAP3630
From: Tuukka Toivonen Add new/changed base address definitions and resources for OMAP3630 ISP. The OMAP3430 CSI2PHY block is same as the OMAP3630 CSIPHY2 block. But the later name is chosen as it gives more symmetry to the names. Signed-off-by: Tuukka Toivonen Signed-off-by: Vimarsh Zutshi Acked-by: Tony Lindgren --- arch/arm/mach-omap2/devices.c | 28 arch/arm/plat-omap/include/plat/omap34xx.h | 16 2 files changed, 36 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 5a0c148..d5da345 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -109,13 +109,33 @@ static struct resource omap3isp_resources[] = { .flags = IORESOURCE_MEM, }, { - .start = OMAP3430_ISP_CSI2A_BASE, - .end= OMAP3430_ISP_CSI2A_END, + .start = OMAP3430_ISP_CSI2A_REGS1_BASE, + .end= OMAP3430_ISP_CSI2A_REGS1_END, .flags = IORESOURCE_MEM, }, { - .start = OMAP3430_ISP_CSI2PHY_BASE, - .end= OMAP3430_ISP_CSI2PHY_END, + .start = OMAP3430_ISP_CSIPHY2_BASE, + .end= OMAP3430_ISP_CSIPHY2_END, + .flags = IORESOURCE_MEM, + }, + { + .start = OMAP3630_ISP_CSI2A_REGS2_BASE, + .end= OMAP3630_ISP_CSI2A_REGS2_END, + .flags = IORESOURCE_MEM, + }, + { + .start = OMAP3630_ISP_CSI2C_REGS1_BASE, + .end= OMAP3630_ISP_CSI2C_REGS1_END, + .flags = IORESOURCE_MEM, + }, + { + .start = OMAP3630_ISP_CSIPHY1_BASE, + .end= OMAP3630_ISP_CSIPHY1_END, + .flags = IORESOURCE_MEM, + }, + { + .start = OMAP3630_ISP_CSI2C_REGS2_BASE, + .end= OMAP3630_ISP_CSI2C_REGS2_END, .flags = IORESOURCE_MEM, }, { diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h b/arch/arm/plat-omap/include/plat/omap34xx.h index 98fc8b4..b9e8588 100644 --- a/arch/arm/plat-omap/include/plat/omap34xx.h +++ b/arch/arm/plat-omap/include/plat/omap34xx.h @@ -56,8 +56,12 @@ #define OMAP3430_ISP_RESZ_BASE (OMAP3430_ISP_BASE + 0x1000) #define OMAP3430_ISP_SBL_BASE (OMAP3430_ISP_BASE + 0x1200) #define OMAP3430_ISP_MMU_BASE (OMAP3430_ISP_BASE + 0x1400) -#define OMAP3430_ISP_CSI2A_BASE(OMAP3430_ISP_BASE + 0x1800) -#define OMAP3430_ISP_CSI2PHY_BASE (OMAP3430_ISP_BASE + 0x1970) +#define OMAP3430_ISP_CSI2A_REGS1_BASE (OMAP3430_ISP_BASE + 0x1800) +#define OMAP3430_ISP_CSIPHY2_BASE (OMAP3430_ISP_BASE + 0x1970) +#define OMAP3630_ISP_CSI2A_REGS2_BASE (OMAP3430_ISP_BASE + 0x19C0) +#define OMAP3630_ISP_CSI2C_REGS1_BASE (OMAP3430_ISP_BASE + 0x1C00) +#define OMAP3630_ISP_CSIPHY1_BASE (OMAP3430_ISP_BASE + 0x1D70) +#define OMAP3630_ISP_CSI2C_REGS2_BASE (OMAP3430_ISP_BASE + 0x1DC0) #define OMAP3430_ISP_END (OMAP3430_ISP_BASE + 0x06F) #define OMAP3430_ISP_CBUFF_END (OMAP3430_ISP_CBUFF_BASE + 0x077) @@ -69,8 +73,12 @@ #define OMAP3430_ISP_RESZ_END (OMAP3430_ISP_RESZ_BASE+ 0x0AB) #define OMAP3430_ISP_SBL_END (OMAP3430_ISP_SBL_BASE + 0x0FB) #define OMAP3430_ISP_MMU_END (OMAP3430_ISP_MMU_BASE + 0x06F) -#define OMAP3430_ISP_CSI2A_END (OMAP3430_ISP_CSI2A_BASE + 0x16F) -#define OMAP3430_ISP_CSI2PHY_END (OMAP3430_ISP_CSI2PHY_BASE + 0x007) +#define OMAP3430_ISP_CSI2A_REGS1_END (OMAP3430_ISP_CSI2A_REGS1_BASE + 0x16F) +#define OMAP3430_ISP_CSIPHY2_END (OMAP3430_ISP_CSIPHY2_BASE + 0x00B) +#define OMAP3630_ISP_CSI2A_REGS2_END (OMAP3630_ISP_CSI2A_REGS2_BASE + 0x3F) +#define OMAP3630_ISP_CSI2C_REGS1_END (OMAP3630_ISP_CSI2C_REGS1_BASE + 0x16F) +#define OMAP3630_ISP_CSIPHY1_END (OMAP3630_ISP_CSIPHY1_BASE + 0x00B) +#define OMAP3630_ISP_CSI2C_REGS2_END (OMAP3630_ISP_CSI2C_REGS2_BASE + 0x3F) #define OMAP34XX_HSUSB_OTG_BASE(L4_34XX_BASE + 0xAB000) #define OMAP34XX_USBTLL_BASE (L4_34XX_BASE + 0x62000) -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 13/13] v4l: v4l2_subdev userspace crop API
From: Antti Koskipaa This patch adds the VIDIOC_SUBDEV_S_CROP and G_CROP ioctls to the userland API. CROPCAP is not implemented because it's redundant. Signed-off-by: Antti Koskipaa Signed-off-by: Laurent Pinchart --- Documentation/DocBook/media-entities.tmpl |4 + Documentation/DocBook/v4l/dev-subdev.xml | 33 + Documentation/DocBook/v4l/v4l2.xml |1 + Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml | 143 drivers/media/video/v4l2-subdev.c | 26 include/linux/v4l2-subdev.h| 15 ++ include/media/v4l2-subdev.h|4 + 7 files changed, 226 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 4af3c2e..157d147 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -88,8 +88,10 @@ VIDIOC_S_TUNER"> VIDIOC_SUBDEV_ENUM_FRAME_SIZE"> VIDIOC_SUBDEV_ENUM_MBUS_CODE"> +VIDIOC_SUBDEV_G_CROP"> VIDIOC_SUBDEV_G_FMT"> VIDIOC_SUBDEV_G_FRAME_INTERVAL"> +VIDIOC_SUBDEV_S_CROP"> VIDIOC_SUBDEV_S_FMT"> VIDIOC_SUBDEV_S_FRAME_INTERVAL"> VIDIOC_TRY_ENCODER_CMD"> @@ -195,6 +197,7 @@ v4l2_subdev_frame_interval"> v4l2_subdev_frame_interval_enum"> v4l2_subdev_frame_size_enum"> +v4l2_subdev_crop"> v4l2_subdev_format"> v4l2_subdev_mbus_code_enum"> v4l2_standard"> @@ -333,6 +336,7 @@ + diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml index 12fdca4..a8da916 100644 --- a/Documentation/DocBook/v4l/dev-subdev.xml +++ b/Documentation/DocBook/v4l/dev-subdev.xml @@ -269,6 +269,39 @@ + + Cropping and scaling + + Many sub-devices support cropping frames on their input or output + pads (or possible even on both). Cropping is used to select the area of + interest in an image, typically on a video sensor or video decoder. It can + also be used as part of digital zoom implementations to select the area of + the image that will be scaled up. + + Crop settings are defined by a crop rectangle and represented in a + &v4l2-rect; by the coordinates of the top left corner and the rectangle + size. Both the coordinates and sizes are expressed in pixels. + + The crop rectangle is retrieved and set using the + &VIDIOC-SUBDEV-G-CROP; and &VIDIOC-SUBDEV-S-CROP; ioctls. Like for pad + formats, drivers store try and active crop rectangles. The format + negotiation mechanism applies to crop settings as well. + + On input pads, cropping is applied relatively to the current pad + format. The pad format represents the image size as received by the + sub-device from the previous block in the pipeline, and the crop rectangle + represents the sub-image that will be transmitted further inside the + sub-device for processing. The crop rectangle be entirely containted + inside the input image size. + + Input crop rectangle are reset to their default value when the input + image format is modified. Drivers should use the input image size as the + crop rectangle default value, but hardware requirements may prevent this. + + + Cropping behaviour on output pads is not defined. + + &sub-subdev-formats; diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index e6225e0..5e640ca 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -481,6 +481,7 @@ and discussions on the V4L mailing list. &sub-subdev-enum-frame-interval; &sub-subdev-enum-frame-size; &sub-subdev-enum-mbus-code; +&sub-subdev-g-crop; &sub-subdev-g-fmt; &sub-subdev-g-frame-interval; &sub-subscribe-event; diff --git a/Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml b/Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml new file mode 100644 index 000..b71c9a3 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml @@ -0,0 +1,143 @@ + + +ioctl VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP +&manvol; + + + +VIDIOC_SUBDEV_G_CROP +VIDIOC_SUBDEV_S_CROP +Get or set the crop rectangle on a subdev pad + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_crop *argp + + + + + int ioctl + int fd + int request + const struct v4l2_subdev_crop *argp + + + + + +Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP + + + + argp + + + + + + + + +Description + +To retrieve the current crop rectangle applications set the +
[RFC/PATCH v4 2/7] v4l: Add subdev sensor g_skip_frames operation
Some buggy sensors generate corrupt frames when the stream is started. This new operation return the number of corrupt frames to skip when starting the stream. Signed-off-by: Laurent Pinchart --- include/media/v4l2-subdev.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index a02663e..181de59 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -352,9 +352,13 @@ struct v4l2_subdev_vbi_ops { * This is needed for some sensors, which always corrupt * several top lines of the output image, or which send their * metadata in them. + * @g_skip_frames: number of frames to skip at stream start. This is needed for + *buggy sensors that generate faulty frames when they are + *turned on. */ struct v4l2_subdev_sensor_ops { int (*g_skip_top_lines)(struct v4l2_subdev *sd, u32 *lines); + int (*g_skip_frames)(struct v4l2_subdev *sd, u32 *frames); }; /* -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v4 6/7] omap3: Add function to register omap3isp platform device structure
The omap3isp platform device requires platform data. Instead of registering the device in omap2_init_devices(), export an omap3_init_camera() function to fill the device structure with the platform data pointer and register the device. Signed-off-by: Laurent Pinchart Acked-by: Tony Lindgren --- arch/arm/mach-omap2/devices.c | 20 +++- arch/arm/mach-omap2/devices.h | 17 + 2 files changed, 28 insertions(+), 9 deletions(-) create mode 100644 arch/arm/mach-omap2/devices.h diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index d5da345..886c01b 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -34,6 +34,8 @@ #include "mux.h" #include "control.h" +#include "devices.h" + #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE) static struct resource cam_resources[] = { @@ -59,8 +61,11 @@ static inline void omap_init_camera(void) { platform_device_register(&omap_cam_device); } - -#elif defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE) +#else +static inline void omap_init_camera(void) +{ +} +#endif static struct resource omap3isp_resources[] = { { @@ -151,15 +156,12 @@ static struct platform_device omap3isp_device = { .resource = omap3isp_resources, }; -static inline void omap_init_camera(void) -{ - platform_device_register(&omap3isp_device); -} -#else -static inline void omap_init_camera(void) +int omap3_init_camera(void *pdata) { + omap3isp_device.dev.platform_data = pdata; + return platform_device_register(&omap3isp_device); } -#endif +EXPORT_SYMBOL_GPL(omap3_init_camera); #if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE) diff --git a/arch/arm/mach-omap2/devices.h b/arch/arm/mach-omap2/devices.h new file mode 100644 index 000..12ddb8a --- /dev/null +++ b/arch/arm/mach-omap2/devices.h @@ -0,0 +1,17 @@ +/* + * arch/arm/mach-omap2/devices.h + * + * OMAP2 platform device setup/initialization + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#ifndef __ARCH_ARM_MACH_OMAP_DEVICES_H +#define __ARCH_ARM_MACH_OMAP_DEVICES_H + +int omap3_init_camera(void *pdata); + +#endif -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 03/13] v4l: Rename V4L2_MBUS_FMT_GREY8_1X8 to V4L2_MBUS_FMT_Y8_1X8
For consistency with the V4L2_MBUS_FMT_Y10_1X10 format. Signed-off-by: Laurent Pinchart --- drivers/media/video/mt9m001.c|2 +- drivers/media/video/mt9v022.c|4 ++-- drivers/media/video/ov6650.c | 10 +- drivers/media/video/sh_mobile_csi2.c |6 +++--- drivers/media/video/soc_mediabus.c |2 +- include/linux/v4l2-mediabus.h|2 +- 6 files changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c index fcb4cd9..3aaedf6 100644 --- a/drivers/media/video/mt9m001.c +++ b/drivers/media/video/mt9m001.c @@ -79,7 +79,7 @@ static const struct mt9m001_datafmt mt9m001_colour_fmts[] = { static const struct mt9m001_datafmt mt9m001_monochrome_fmts[] = { /* Order important - see above */ {V4L2_MBUS_FMT_Y10_1X10, V4L2_COLORSPACE_JPEG}, - {V4L2_MBUS_FMT_GREY8_1X8, V4L2_COLORSPACE_JPEG}, + {V4L2_MBUS_FMT_Y8_1X8, V4L2_COLORSPACE_JPEG}, }; struct mt9m001 { diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index b96171c..56dd4fc 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -95,7 +95,7 @@ static const struct mt9v022_datafmt mt9v022_colour_fmts[] = { static const struct mt9v022_datafmt mt9v022_monochrome_fmts[] = { /* Order important - see above */ {V4L2_MBUS_FMT_Y10_1X10, V4L2_COLORSPACE_JPEG}, - {V4L2_MBUS_FMT_GREY8_1X8, V4L2_COLORSPACE_JPEG}, + {V4L2_MBUS_FMT_Y8_1X8, V4L2_COLORSPACE_JPEG}, }; struct mt9v022 { @@ -392,7 +392,7 @@ static int mt9v022_s_fmt(struct v4l2_subdev *sd, * icd->try_fmt(), datawidth is from our supported format list */ switch (mf->code) { - case V4L2_MBUS_FMT_GREY8_1X8: + case V4L2_MBUS_FMT_Y8_1X8: case V4L2_MBUS_FMT_Y10_1X10: if (mt9v022->model != V4L2_IDENT_MT9V022IX7ATM) return -EINVAL; diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c index cf93de9..fe8e3eb 100644 --- a/drivers/media/video/ov6650.c +++ b/drivers/media/video/ov6650.c @@ -207,7 +207,7 @@ static enum v4l2_mbus_pixelcode ov6650_codes[] = { V4L2_MBUS_FMT_YVYU8_2X8, V4L2_MBUS_FMT_VYUY8_2X8, V4L2_MBUS_FMT_SBGGR8_1X8, - V4L2_MBUS_FMT_GREY8_1X8, + V4L2_MBUS_FMT_Y8_1X8, }; static const struct v4l2_queryctrl ov6650_controls[] = { @@ -800,7 +800,7 @@ static int ov6650_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt *mf) /* select color matrix configuration for given color encoding */ switch (code) { - case V4L2_MBUS_FMT_GREY8_1X8: + case V4L2_MBUS_FMT_Y8_1X8: dev_dbg(&client->dev, "pixel format GREY8_1X8\n"); coma_mask |= COMA_RGB | COMA_WORD_SWAP | COMA_BYTE_SWAP; coma_set |= COMA_BW; @@ -846,7 +846,7 @@ static int ov6650_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt *mf) } priv->code = code; - if (code == V4L2_MBUS_FMT_GREY8_1X8 || + if (code == V4L2_MBUS_FMT_Y8_1X8 || code == V4L2_MBUS_FMT_SBGGR8_1X8) { coml_mask = COML_ONE_CHANNEL; coml_set = 0; @@ -936,8 +936,8 @@ static int ov6650_try_fmt(struct v4l2_subdev *sd, switch (mf->code) { case V4L2_MBUS_FMT_Y10_1X10: - mf->code = V4L2_MBUS_FMT_GREY8_1X8; - case V4L2_MBUS_FMT_GREY8_1X8: + mf->code = V4L2_MBUS_FMT_Y8_1X8; + case V4L2_MBUS_FMT_Y8_1X8: case V4L2_MBUS_FMT_YVYU8_2X8: case V4L2_MBUS_FMT_YUYV8_2X8: case V4L2_MBUS_FMT_VYUY8_2X8: diff --git a/drivers/media/video/sh_mobile_csi2.c b/drivers/media/video/sh_mobile_csi2.c index 84a6468..dd1b81b 100644 --- a/drivers/media/video/sh_mobile_csi2.c +++ b/drivers/media/video/sh_mobile_csi2.c @@ -56,7 +56,7 @@ static int sh_csi2_try_fmt(struct v4l2_subdev *sd, switch (mf->code) { case V4L2_MBUS_FMT_UYVY8_2X8: /* YUV422 */ case V4L2_MBUS_FMT_YUYV8_1_5X8: /* YUV420 */ - case V4L2_MBUS_FMT_GREY8_1X8: /* RAW8 */ + case V4L2_MBUS_FMT_Y8_1X8: /* RAW8 */ case V4L2_MBUS_FMT_SBGGR8_1X8: case V4L2_MBUS_FMT_SGRBG8_1X8: break; @@ -67,7 +67,7 @@ static int sh_csi2_try_fmt(struct v4l2_subdev *sd, break; case SH_CSI2I: switch (mf->code) { - case V4L2_MBUS_FMT_GREY8_1X8: /* RAW8 */ + case V4L2_MBUS_FMT_Y8_1X8: /* RAW8 */ case V4L2_MBUS_FMT_SBGGR8_1X8: case V4L2_MBUS_FMT_SGRBG8_1X8: case V4L2_MBUS_FMT_SBGGR10_1X10:/* RAW10 */ @@ -111,7 +111,7 @@ static int sh_csi2_s_fmt(struct v4l2_subdev *sd, case V4L2_MBUS_FMT_RGB565_2X8_BE: tmp |= 0x22;/* RGB565 */ brea
[RFC/PATCH v7 11/12] v4l: Make video_device inherit from media_entity
V4L2 devices are media entities. As such they need to inherit from (include) the media_entity structure. When registering/unregistering the device, the media entity is automatically registered/unregistered. The entity is acquired on device open and released on device close. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus --- Documentation/video4linux/v4l2-framework.txt | 38 ++-- drivers/media/video/v4l2-dev.c | 49 +++--- include/media/v4l2-dev.h |7 3 files changed, 86 insertions(+), 8 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index aeb2a22..f231bc20 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -71,6 +71,10 @@ sub-device instances, the video_device struct stores V4L2 device node data and in the future a v4l2_fh struct will keep track of filehandle instances (this is not yet implemented). +The V4L2 framework also optionally integrates with the media framework. If a +driver sets the struct v4l2_device mdev field, sub-devices and video nodes +will automatically appear in the media framework as entities. + struct v4l2_device -- @@ -84,11 +88,14 @@ You must register the device instance: v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); Registration will initialize the v4l2_device struct. If the dev->driver_data -field is NULL, it will be linked to v4l2_dev. Drivers that use the media -device framework in addition to the V4L2 framework need to set +field is NULL, it will be linked to v4l2_dev. + +Drivers that want integration with the media device framework need to set dev->driver_data manually to point to the driver-specific device structure that embed the struct v4l2_device instance. This is achieved by a -dev_set_drvdata() call before registering the V4L2 device instance. +dev_set_drvdata() call before registering the V4L2 device instance. They must +also set the struct v4l2_device mdev field to point to a properly initialized +and registered media_device instance. If v4l2_dev->name is empty then it will be set to a value derived from dev (driver name followed by the bus_id, to be precise). If you set it up before @@ -532,6 +539,21 @@ If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or The v4l2_file_operations struct is a subset of file_operations. The main difference is that the inode argument is omitted since it is never used. +If integration with the media framework is needed, you must initialize the +media_entity struct embedded in the video_device struct (entity field) by +calling media_entity_init(): + + struct media_pad *pad = &my_vdev->pad; + int err; + + err = media_entity_init(&vdev->entity, 1, pad, 0); + +The pads array must have been previously initialized. There is no need to +manually set the struct media_entity type and name fields. + +A reference to the entity will be automatically acquired/released when the +video device is opened/closed. + v4l2_file_operations and locking @@ -561,6 +583,9 @@ for you. return err; } +If the v4l2_device parent device has a non-NULL mdev field, the video device +entity will be automatically registered with the media device. + Which device is registered depends on the type argument. The following types exist: @@ -636,6 +661,13 @@ release, of course) will return an error as well. When the last user of the video device node exits, then the vdev->release() callback is called and you can do the final cleanup there. +Don't forget to cleanup the media entity associated with the video device if +it has been initialized: + + media_entity_cleanup(&vdev->entity); + +This can be done from the release callback. + video_device helper functions - diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index 035db52..9088cab 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -278,6 +278,9 @@ static int v4l2_mmap(struct file *filp, struct vm_area_struct *vm) static int v4l2_open(struct inode *inode, struct file *filp) { struct video_device *vdev; +#if defined(CONFIG_MEDIA_CONTROLLER) + struct media_entity *entity = NULL; +#endif int ret = 0; /* Check if the video device is available */ @@ -291,6 +294,16 @@ static int v4l2_open(struct inode *inode, struct file *filp) /* and increase the device refcount */ video_get(vdev); mutex_unlock(&videodev_lock); +#if defined(CONFIG_MEDIA_CONTROLLER) + if (vdev->v4l2_dev && vdev->v4l2_dev->mdev) { + entity = media_entity_get(&vdev->entity); + if (!entity) { + ret = -EBUSY; + video_put(vdev); +
[RFC/PATCH v5 12/13] v4l: v4l2_subdev userspace frame interval API
The three new ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL, VIDIOC_SUBDEV_G_FRAME_INTERVAL and VIDIOC_SUBDEV_S_FRAME_INTERVAL can be used to enumerate and configure a subdev's frame rate from userspace. Two new video::g/s_frame_interval subdev operations are introduced to support those ioctls. The existing video::g/s_parm operations are deprecated and shouldn't be used anymore. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus --- Documentation/DocBook/media-entities.tmpl |6 + Documentation/DocBook/v4l/v4l2.xml |2 + .../v4l/vidioc-subdev-enum-frame-interval.xml | 146 .../DocBook/v4l/vidioc-subdev-g-frame-interval.xml | 135 ++ drivers/media/video/v4l2-subdev.c | 16 ++ include/linux/v4l2-subdev.h| 36 + include/media/v4l2-subdev.h|7 + 7 files changed, 348 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 538f8fe..4af3c2e 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -89,7 +89,9 @@ VIDIOC_SUBDEV_ENUM_FRAME_SIZE"> VIDIOC_SUBDEV_ENUM_MBUS_CODE"> VIDIOC_SUBDEV_G_FMT"> +VIDIOC_SUBDEV_G_FRAME_INTERVAL"> VIDIOC_SUBDEV_S_FMT"> +VIDIOC_SUBDEV_S_FRAME_INTERVAL"> VIDIOC_TRY_ENCODER_CMD"> VIDIOC_TRY_EXT_CTRLS"> VIDIOC_TRY_FMT"> @@ -190,6 +192,8 @@ v4l2_sliced_vbi_cap"> v4l2_sliced_vbi_data"> v4l2_sliced_vbi_format"> +v4l2_subdev_frame_interval"> +v4l2_subdev_frame_interval_enum"> v4l2_subdev_frame_size_enum"> v4l2_subdev_format"> v4l2_subdev_mbus_code_enum"> @@ -325,10 +329,12 @@ + + diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 695e3bf..e6225e0 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -478,9 +478,11 @@ and discussions on the V4L mailing list. &sub-reqbufs; &sub-s-hw-freq-seek; &sub-streamon; +&sub-subdev-enum-frame-interval; &sub-subdev-enum-frame-size; &sub-subdev-enum-mbus-code; &sub-subdev-g-fmt; +&sub-subdev-g-frame-interval; &sub-subscribe-event; &sub-mmap; diff --git a/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml new file mode 100644 index 000..bcea9d49 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml @@ -0,0 +1,146 @@ + + +ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL +&manvol; + + + +VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL +Enumerate frame intervals + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_frame_interval_enum * + argp + + + + + +Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL + + + + argp + + + + + + + + +Description + +This ioctl lets applications enumerate available frame intervals on a +given sub-device pad. Frame intervals only makes sense for sub-devices that +can control the frame period on their own. This includes, for instance, +image sensors and TV tuners. + +For the common use case of image sensors, the frame intervals +available on the sub-device output pad depend on the frame format and size +on the same pad. Applications must thus specify the desired format and size +when enumerating frame intervals. + +To enumerate frame intervals applications initialize the +index, pad, +code, width and +height fields of +&v4l2-subdev-frame-interval-enum; and call the +VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return +an &EINVAL; if one of the input fields is invalid. All frame intervals are +enumerable by beginning at index zero and incrementing by one until +EINVAL is returned. + +Available frame intervals may depend on the current 'try' formats +at other pads of the sub-device, as well as on the current active links. See +&VIDIOC-SUBDEV-G-FMT; for more information about the try formats. + +Sub-devices that support the frame interval enumeration ioctl should +implemented it on a single pad only. Its behaviour when supported on +multiple pads of the same sub-device is not defined. + + + struct v4l2_subdev_frame_interval_enum + + &cs-str; + + + __u32 + index + Number of the format in the enumeration, set by the + application.
[RFC/PATCH v5 09/13] v4l: v4l2_subdev pad-level operations
Add a v4l2_subdev_pad_ops structure for the operations that need to be performed at the pad level such as format-related operations. Pad format-related operations use v4l2_mbus_framefmt instead of v4l2_format. Signed-off-by: Laurent Pinchart --- include/media/v4l2-subdev.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index af704df..4f6ddba 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -42,6 +42,7 @@ struct v4l2_ctrl_handler; struct v4l2_event_subscription; struct v4l2_fh; struct v4l2_subdev; +struct v4l2_subdev_fh; struct tuner_setup; /* decode_vbi_line */ @@ -423,6 +424,9 @@ struct v4l2_subdev_ir_ops { struct v4l2_subdev_ir_parameters *params); }; +struct v4l2_subdev_pad_ops { +}; + struct v4l2_subdev_ops { const struct v4l2_subdev_core_ops *core; const struct v4l2_subdev_file_ops *file; @@ -432,6 +436,7 @@ struct v4l2_subdev_ops { const struct v4l2_subdev_vbi_ops*vbi; const struct v4l2_subdev_ir_ops *ir; const struct v4l2_subdev_sensor_ops *sensor; + const struct v4l2_subdev_pad_ops*pad; }; #define V4L2_SUBDEV_NAME_SIZE 32 -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 04/13] v4l: Group media bus pixel codes by types and sort them alphabetically
Adding new pixel codes at the end of the enumeration will soon create a mess, so group the pixel codes by type and sort them by bus_width, bits per component, samples per pixel and order of subsamples. As the codes are part of the kernel ABI their value can't change when a new code is inserted in the enumeration, so they are given an explicit numerical value. When inserting a new pixel code developers must use and update the next free value. Signed-off-by: Laurent Pinchart --- include/linux/v4l2-mediabus.h | 77 1 files changed, 46 insertions(+), 31 deletions(-) diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h index 1171cac..ed5ac25 100644 --- a/include/linux/v4l2-mediabus.h +++ b/include/linux/v4l2-mediabus.h @@ -24,39 +24,54 @@ * transferred first, "BE" means that the most significant bits are transferred * first, and "PADHI" and "PADLO" define which bits - low or high, in the * incomplete high byte, are filled with padding bits. + * + * The pixel codes are grouped by type, bus_width, bits per component, samples + * per pixel and order of subsamples. Numerical values are sorted using generic + * numerical sort order (8 thus comes before 10). + * + * As their value can't change when a new pixel code is inserted in the + * enumeration, the pixel codes are explicitly given a numerical value. The next + * free values for each category are listed below, update them when inserting + * new pixel codes. */ enum v4l2_mbus_pixelcode { - V4L2_MBUS_FMT_FIXED = 1, - V4L2_MBUS_FMT_YUYV8_2X8, - V4L2_MBUS_FMT_YVYU8_2X8, - V4L2_MBUS_FMT_UYVY8_2X8, - V4L2_MBUS_FMT_VYUY8_2X8, - V4L2_MBUS_FMT_YVYU10_2X10, - V4L2_MBUS_FMT_YUYV10_2X10, - V4L2_MBUS_FMT_YVYU10_1X20, - V4L2_MBUS_FMT_YUYV10_1X20, - V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE, - V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE, - V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE, - V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE, - V4L2_MBUS_FMT_RGB565_2X8_LE, - V4L2_MBUS_FMT_RGB565_2X8_BE, - V4L2_MBUS_FMT_BGR565_2X8_LE, - V4L2_MBUS_FMT_BGR565_2X8_BE, - V4L2_MBUS_FMT_SBGGR8_1X8, - V4L2_MBUS_FMT_SBGGR10_1X10, - V4L2_MBUS_FMT_Y8_1X8, - V4L2_MBUS_FMT_Y10_1X10, - V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE, - V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE, - V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE, - V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE, - V4L2_MBUS_FMT_SGRBG8_1X8, - V4L2_MBUS_FMT_SBGGR12_1X12, - V4L2_MBUS_FMT_YUYV8_1_5X8, - V4L2_MBUS_FMT_YVYU8_1_5X8, - V4L2_MBUS_FMT_UYVY8_1_5X8, - V4L2_MBUS_FMT_VYUY8_1_5X8, + V4L2_MBUS_FMT_FIXED = 0x0001, + + /* RGB - next is 0x1009 */ + V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE = 0x1001, + V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE = 0x1002, + V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1003, + V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 0x1004, + V4L2_MBUS_FMT_BGR565_2X8_BE = 0x1005, + V4L2_MBUS_FMT_BGR565_2X8_LE = 0x1006, + V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, + V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, + + /* YUV (including grey) - next is 0x200f */ + V4L2_MBUS_FMT_Y8_1X8 = 0x2001, + V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, + V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, + V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004, + V4L2_MBUS_FMT_YVYU8_1_5X8 = 0x2005, + V4L2_MBUS_FMT_UYVY8_2X8 = 0x2006, + V4L2_MBUS_FMT_VYUY8_2X8 = 0x2007, + V4L2_MBUS_FMT_YUYV8_2X8 = 0x2008, + V4L2_MBUS_FMT_YVYU8_2X8 = 0x2009, + V4L2_MBUS_FMT_Y10_1X10 = 0x200a, + V4L2_MBUS_FMT_YUYV10_2X10 = 0x200b, + V4L2_MBUS_FMT_YVYU10_2X10 = 0x200c, + V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, + V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, + + /* Bayer - next is 0x3009 */ + V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, + V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003, + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004, + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005, + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006, + V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007, + V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008, }; /** -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 07/13] v4l: Create v4l2 subdev file handle structure
From: Stanimir Varbanov Used for storing subdev information per file handle and hold V4L2 file handle. Signed-off-by: Stanimir Varbanov Signed-off-by: Antti Koskipaa Signed-off-by: Laurent Pinchart --- drivers/media/Kconfig |9 drivers/media/video/v4l2-subdev.c | 85 + include/media/v4l2-subdev.h | 29 + 3 files changed, 96 insertions(+), 27 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 6b946e6..eaf4734 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -82,6 +82,15 @@ config VIDEO_V4L1_COMPAT If you are unsure as to whether this is required, answer Y. +config VIDEO_V4L2_SUBDEV_API + bool "V4L2 sub-device userspace API (EXPERIMENTAL)" + depends on VIDEO_DEV && MEDIA_CONTROLLER && EXPERIMENTAL + ---help--- + Enables the V4L2 sub-device pad-level userspace API used to configure + video format, size and frame rate between hardware blocks. + + This API is mostly used by camera interfaces in embedded platforms. + # # DVB Core # diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 5e19136..d389b44 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -31,39 +31,69 @@ #include #include +static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd) +{ +#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API) + /* Allocate try format and crop in the same memory block */ + fh->try_fmt = kzalloc((sizeof(*fh->try_fmt) + sizeof(*fh->try_crop)) + * sd->entity.num_pads, GFP_KERNEL); + if (fh->try_fmt == NULL) + return -ENOMEM; + + fh->try_crop = (struct v4l2_rect *) + (fh->try_fmt + sd->entity.num_pads); +#endif + return 0; +} + +static void subdev_fh_free(struct v4l2_subdev_fh *fh) +{ +#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API) + kfree(fh->try_fmt); + fh->try_fmt = NULL; + fh->try_crop = NULL; +#endif +} + static int subdev_open(struct file *file) { struct video_device *vdev = video_devdata(file); struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev); + struct v4l2_subdev_fh *subdev_fh; #if defined(CONFIG_MEDIA_CONTROLLER) struct media_entity *entity; #endif - struct v4l2_fh *vfh = NULL; int ret; if (!sd->initialized) return -EAGAIN; - if (sd->flags & V4L2_SUBDEV_FL_HAS_EVENTS) { - vfh = kzalloc(sizeof(*vfh), GFP_KERNEL); - if (vfh == NULL) - return -ENOMEM; + subdev_fh = kzalloc(sizeof(*subdev_fh), GFP_KERNEL); + if (subdev_fh == NULL) + return -ENOMEM; - ret = v4l2_fh_init(vfh, vdev); - if (ret) - goto err; + ret = subdev_fh_init(subdev_fh, sd); + if (ret) { + kfree(subdev_fh); + return ret; + } + + ret = v4l2_fh_init(&subdev_fh->vfh, vdev); + if (ret) + goto err; - ret = v4l2_event_init(vfh); + if (sd->flags & V4L2_SUBDEV_FL_HAS_EVENTS) { + ret = v4l2_event_init(&subdev_fh->vfh); if (ret) goto err; - ret = v4l2_event_alloc(vfh, sd->nevents); + ret = v4l2_event_alloc(&subdev_fh->vfh, sd->nevents); if (ret) goto err; - - v4l2_fh_add(vfh); - file->private_data = vfh; } + + v4l2_fh_add(&subdev_fh->vfh); + file->private_data = &subdev_fh->vfh; #if defined(CONFIG_MEDIA_CONTROLLER) if (sd->v4l2_dev->mdev) { entity = media_entity_get(&sd->entity); @@ -73,14 +103,14 @@ static int subdev_open(struct file *file) } } #endif + return 0; err: - if (vfh != NULL) { - v4l2_fh_del(vfh); - v4l2_fh_exit(vfh); - kfree(vfh); - } + v4l2_fh_del(&subdev_fh->vfh); + v4l2_fh_exit(&subdev_fh->vfh); + subdev_fh_free(subdev_fh); + kfree(subdev_fh); return ret; } @@ -92,16 +122,17 @@ static int subdev_close(struct file *file) struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev); #endif struct v4l2_fh *vfh = file->private_data; + struct v4l2_subdev_fh *subdev_fh = to_v4l2_subdev_fh(vfh); #if defined(CONFIG_MEDIA_CONTROLLER) if (sd->v4l2_dev->mdev) media_entity_put(&sd->entity); #endif - if (vfh != NULL) { - v4l2_fh_del(vfh); - v4l2_fh_exit(vfh); - kfree(vfh); - } + v4l2_fh_del(vfh); + v4l2_fh_exit(vfh); + subdev_fh_free(subdev_fh); + kfree(subdev_fh); + file->private_data = NULL; return 0; } @@ -110,7 +141,7 @@ static long subde
[RFC/PATCH v5 06/13] v4l: Add remaining RAW10 patterns w DPCM pixel code variants
This adds following formats: - V4L2_MBUS_FMT_SRGGB10_1X10 - V4L2_MBUS_FMT_SGBRG10_1X10 - V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 - V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 - V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 Signed-off-by: Sergio Aguirre Signed-off-by: Laurent Pinchart --- include/linux/v4l2-mediabus.h |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h index b091366..99cfd38 100644 --- a/include/linux/v4l2-mediabus.h +++ b/include/linux/v4l2-mediabus.h @@ -67,16 +67,21 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, - /* Bayer - next is 0x300b */ + /* Bayer - next is 0x3010 */ V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, + V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b, + V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009, + V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 = 0x300d, V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003, V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004, V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005, V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006, V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007, + V4L2_MBUS_FMT_SGBRG10_1X10 = 0x300e, V4L2_MBUS_FMT_SGRBG10_1X10 = 0x300a, + V4L2_MBUS_FMT_SRGGB10_1X10 = 0x300f, V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008, }; -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 05/13] v4l: Add 8-bit YUYV on 16-bit bus and SGRBG10 media bus pixel codes
Add the following media bus format code definitions: - V4L2_MBUS_FMT_SGRBG10_1X10 for 10-bit GRBG Bayer - V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 for 10-bit DPCM compressed GRBG Bayer - V4L2_MBUS_FMT_YUYV16_1X16 for 8-bit YUYV on 16-bit bus - V4L2_MBUS_FMT_UYVY16_1X16 for 8-bit UYVY on 16-bit bus - V4L2_MBUS_FMT_YVYU16_1X16 for 8-bit YVYU on 16-bit bus - V4L2_MBUS_FMT_VYUY16_1X16 for 8-bit VYUY on 16-bit bus Signed-off-by: Laurent Pinchart --- include/linux/v4l2-mediabus.h | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h index ed5ac25..b091366 100644 --- a/include/linux/v4l2-mediabus.h +++ b/include/linux/v4l2-mediabus.h @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, - /* YUV (including grey) - next is 0x200f */ + /* YUV (including grey) - next is 0x2013 */ V4L2_MBUS_FMT_Y8_1X8 = 0x2001, V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, @@ -60,17 +60,23 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_Y10_1X10 = 0x200a, V4L2_MBUS_FMT_YUYV10_2X10 = 0x200b, V4L2_MBUS_FMT_YVYU10_2X10 = 0x200c, + V4L2_MBUS_FMT_UYVY8_1X16 = 0x200f, + V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010, + V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011, + V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, - /* Bayer - next is 0x3009 */ + /* Bayer - next is 0x300b */ V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, + V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009, V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003, V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004, V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005, V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006, V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007, + V4L2_MBUS_FMT_SGRBG10_1X10 = 0x300a, V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008, }; -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 08/13] v4l: subdev: Add a new file operations class
V4L2 sub-devices store pad formats and crop settings in the file handle. To let drivers initialize those settings properly, add a file::open operation that is called when the subdev is opened as well as a corresponding file::close operation. Signed-off-by: Laurent Pinchart --- drivers/media/video/v4l2-subdev.c | 11 ++- include/media/v4l2-subdev.h | 10 ++ 2 files changed, 20 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index d389b44..de10a1d 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -61,7 +61,7 @@ static int subdev_open(struct file *file) struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev); struct v4l2_subdev_fh *subdev_fh; #if defined(CONFIG_MEDIA_CONTROLLER) - struct media_entity *entity; + struct media_entity *entity = NULL; #endif int ret; @@ -104,9 +104,17 @@ static int subdev_open(struct file *file) } #endif + ret = v4l2_subdev_call(sd, file, open, subdev_fh); + if (ret < 0 && ret != -ENOIOCTLCMD) + goto err; + return 0; err: +#if defined(CONFIG_MEDIA_CONTROLLER) + if (entity) + media_entity_put(entity); +#endif v4l2_fh_del(&subdev_fh->vfh); v4l2_fh_exit(&subdev_fh->vfh); subdev_fh_free(subdev_fh); @@ -124,6 +132,7 @@ static int subdev_close(struct file *file) struct v4l2_fh *vfh = file->private_data; struct v4l2_subdev_fh *subdev_fh = to_v4l2_subdev_fh(vfh); + v4l2_subdev_call(sd, file, close, subdev_fh); #if defined(CONFIG_MEDIA_CONTROLLER) if (sd->v4l2_dev->mdev) media_entity_put(&sd->entity); diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index f8704ff..af704df 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -175,6 +175,15 @@ struct v4l2_subdev_core_ops { struct v4l2_event_subscription *sub); }; +/* open: called when the subdev device node is opened by an application. + + close: called when the subdev device node is close. + */ +struct v4l2_subdev_file_ops { + int (*open)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh); + int (*close)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh); +}; + /* s_mode: switch the tuner to a specific tuner mode. Replacement of s_radio. s_radio: v4l device was opened in Radio mode, to be replaced by s_mode. @@ -416,6 +425,7 @@ struct v4l2_subdev_ir_ops { struct v4l2_subdev_ops { const struct v4l2_subdev_core_ops *core; + const struct v4l2_subdev_file_ops *file; const struct v4l2_subdev_tuner_ops *tuner; const struct v4l2_subdev_audio_ops *audio; const struct v4l2_subdev_video_ops *video; -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 01/13] v4l: Move the media/v4l2-mediabus.h header to include/linux
The header defines the v4l2_mbus_framefmt structure which will be used by the V4L2 subdevs userspace API. Change the type of the v4l2_mbus_framefmt::code field to __u32, as enum sizes can differ between different ABIs on the same architectures. Signed-off-by: Laurent Pinchart --- include/linux/Kbuild |1 + include/linux/v4l2-mediabus.h | 78 + include/media/soc_mediabus.h |3 +- include/media/v4l2-mediabus.h | 61 +--- 4 files changed, 81 insertions(+), 62 deletions(-) create mode 100644 include/linux/v4l2-mediabus.h diff --git a/include/linux/Kbuild b/include/linux/Kbuild index 26e0a7f..796e1d8 100644 --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -366,6 +366,7 @@ header-y += unistd.h header-y += usbdevice_fs.h header-y += utime.h header-y += utsname.h +header-y += v4l2-mediabus.h header-y += veth.h header-y += vhost.h header-y += videodev.h diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h new file mode 100644 index 000..a62cd64 --- /dev/null +++ b/include/linux/v4l2-mediabus.h @@ -0,0 +1,78 @@ +/* + * Media Bus API header + * + * Copyright (C) 2009, Guennadi Liakhovetski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __LINUX_V4L2_MEDIABUS_H +#define __LINUX_V4L2_MEDIABUS_H + +#include +#include + +/* + * These pixel codes uniquely identify data formats on the media bus. Mostly + * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is + * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the + * data format is fixed. Additionally, "2X8" means that one pixel is transferred + * in two 8-bit samples, "BE" or "LE" specify in which order those samples are + * transferred over the bus: "LE" means that the least significant bits are + * transferred first, "BE" means that the most significant bits are transferred + * first, and "PADHI" and "PADLO" define which bits - low or high, in the + * incomplete high byte, are filled with padding bits. + */ +enum v4l2_mbus_pixelcode { + V4L2_MBUS_FMT_FIXED = 1, + V4L2_MBUS_FMT_YUYV8_2X8, + V4L2_MBUS_FMT_YVYU8_2X8, + V4L2_MBUS_FMT_UYVY8_2X8, + V4L2_MBUS_FMT_VYUY8_2X8, + V4L2_MBUS_FMT_YVYU10_2X10, + V4L2_MBUS_FMT_YUYV10_2X10, + V4L2_MBUS_FMT_YVYU10_1X20, + V4L2_MBUS_FMT_YUYV10_1X20, + V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE, + V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE, + V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE, + V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE, + V4L2_MBUS_FMT_RGB565_2X8_LE, + V4L2_MBUS_FMT_RGB565_2X8_BE, + V4L2_MBUS_FMT_BGR565_2X8_LE, + V4L2_MBUS_FMT_BGR565_2X8_BE, + V4L2_MBUS_FMT_SBGGR8_1X8, + V4L2_MBUS_FMT_SBGGR10_1X10, + V4L2_MBUS_FMT_GREY8_1X8, + V4L2_MBUS_FMT_Y10_1X10, + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE, + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE, + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE, + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE, + V4L2_MBUS_FMT_SGRBG8_1X8, + V4L2_MBUS_FMT_SBGGR12_1X12, + V4L2_MBUS_FMT_YUYV8_1_5X8, + V4L2_MBUS_FMT_YVYU8_1_5X8, + V4L2_MBUS_FMT_UYVY8_1_5X8, + V4L2_MBUS_FMT_VYUY8_1_5X8, +}; + +/** + * struct v4l2_mbus_framefmt - frame format on the media bus + * @width: frame width + * @height:frame height + * @code: data format code + * @field: used interlacing type + * @colorspace:colorspace of the data + */ +struct v4l2_mbus_framefmt { + __u32 width; + __u32 height; + __u32 code; + enum v4l2_field field; + enum v4l2_colorspacecolorspace; +}; + +#endif diff --git a/include/media/soc_mediabus.h b/include/media/soc_mediabus.h index 037cd7b..6243147 100644 --- a/include/media/soc_mediabus.h +++ b/include/media/soc_mediabus.h @@ -12,8 +12,7 @@ #define SOC_MEDIABUS_H #include - -#include +#include /** * enum soc_mbus_packing - data packing types on the media-bus diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 8e65598..971c7fa 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -11,66 +11,7 @@ #ifndef V4L2_MEDIABUS_H #define V4L2_MEDIABUS_H -/* - * These pixel codes uniquely identify data formats on the media bus. Mostly - * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is - * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the - * data format is fixed. Additionally, "2X8" means that one pixel is transferred - * in two 8-bit samples, "BE" or "LE" specify in which order those samples are - * transferred over the bus: "LE" means that the least significant bits are - * transferred first
[RFC/PATCH v5 02/13] v4l: Replace enums with fixed-sized fields in public structure
The v4l2_mbus_framefmt structure will be part of the public userspace API and used (albeit indirectly) as an ioctl argument. As such, its size must be fixed across userspace ABIs. Replace the v4l2_field and v4l2_colorspace enums by __u32 fields. Signed-off-by: Laurent Pinchart --- include/linux/v4l2-mediabus.h | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h index a62cd64..a25e19f 100644 --- a/include/linux/v4l2-mediabus.h +++ b/include/linux/v4l2-mediabus.h @@ -63,16 +63,16 @@ enum v4l2_mbus_pixelcode { * struct v4l2_mbus_framefmt - frame format on the media bus * @width: frame width * @height:frame height - * @code: data format code - * @field: used interlacing type - * @colorspace:colorspace of the data + * @code: data format code (from enum v4l2_mbus_pixelcode) + * @field: used interlacing type (from enum v4l2_field) + * @colorspace:colorspace of the data (from enum v4l2_colorspace) */ struct v4l2_mbus_framefmt { - __u32 width; - __u32 height; - __u32 code; - enum v4l2_field field; - enum v4l2_colorspacecolorspace; + __u32 width; + __u32 height; + __u32 code; + __u32 field; + __u32 colorspace; }; #endif -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 00/13] Sub-device pad-level operations
Hi everybody, Here's the fifth version of the sub-device pad-level operations patches. Nothing new under the sun, the patches are just rebased on top of 2.6.36-rc7 and the latest media controller API. Antti Koskipaa (1): v4l: v4l2_subdev userspace crop API Laurent Pinchart (11): v4l: Move the media/v4l2-mediabus.h header to include/linux v4l: Replace enums with fixed-sized fields in public structure v4l: Rename V4L2_MBUS_FMT_GREY8_1X8 to V4L2_MBUS_FMT_Y8_1X8 v4l: Group media bus pixel codes by types and sort them alphabetically v4l: Add 8-bit YUYV on 16-bit bus and SGRBG10 media bus pixel codes v4l: Add remaining RAW10 patterns w DPCM pixel code variants v4l: subdev: Add a new file operations class v4l: v4l2_subdev pad-level operations v4l: v4l2_subdev userspace format API - documentation binary files v4l: v4l2_subdev userspace format API v4l: v4l2_subdev userspace frame interval API Stanimir Varbanov (1): v4l: Create v4l2 subdev file handle structure Documentation/DocBook/Makefile |5 +- Documentation/DocBook/media-entities.tmpl | 26 + Documentation/DocBook/v4l/bayer.pdf| Bin 0 -> 12116 bytes Documentation/DocBook/v4l/bayer.png| Bin 0 -> 9725 bytes Documentation/DocBook/v4l/dev-subdev.xml | 307 +++ Documentation/DocBook/v4l/pipeline.pdf | Bin 0 -> 20276 bytes Documentation/DocBook/v4l/pipeline.png | Bin 0 -> 12130 bytes Documentation/DocBook/v4l/subdev-formats.xml | 2410 Documentation/DocBook/v4l/v4l2.xml |7 + Documentation/DocBook/v4l/vidioc-streamon.xml |9 + .../v4l/vidioc-subdev-enum-frame-interval.xml | 146 ++ .../DocBook/v4l/vidioc-subdev-enum-frame-size.xml | 148 ++ .../DocBook/v4l/vidioc-subdev-enum-mbus-code.xml | 113 + Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml | 143 ++ Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml | 168 ++ .../DocBook/v4l/vidioc-subdev-g-frame-interval.xml | 135 ++ drivers/media/Kconfig |9 + drivers/media/video/mt9m001.c |2 +- drivers/media/video/mt9v022.c |4 +- drivers/media/video/ov6650.c | 10 +- drivers/media/video/sh_mobile_csi2.c |6 +- drivers/media/video/soc_mediabus.c |2 +- drivers/media/video/v4l2-subdev.c | 187 ++- include/linux/Kbuild |2 + include/linux/v4l2-mediabus.h | 104 + include/linux/v4l2-subdev.h| 141 ++ include/media/soc_mediabus.h |3 +- include/media/v4l2-mediabus.h | 61 +- include/media/v4l2-subdev.h| 65 + 29 files changed, 4110 insertions(+), 103 deletions(-) create mode 100644 Documentation/DocBook/v4l/bayer.pdf create mode 100644 Documentation/DocBook/v4l/bayer.png create mode 100644 Documentation/DocBook/v4l/dev-subdev.xml create mode 100644 Documentation/DocBook/v4l/pipeline.pdf create mode 100644 Documentation/DocBook/v4l/pipeline.png create mode 100644 Documentation/DocBook/v4l/subdev-formats.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml create mode 100644 include/linux/v4l2-mediabus.h create mode 100644 include/linux/v4l2-subdev.h -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v7 10/12] v4l: Add a media_device pointer to the v4l2_device structure
The pointer will later be used to register/unregister media entities when registering/unregistering a v4l2_subdev or a video_device. With the introduction of media devices, device drivers need to store a pointer to a driver-specific structure in the device's drvdata. v4l2_device can't claim ownership of the drvdata anymore. To maintain compatibility with drivers that rely on v4l2_device storing a pointer to itself in the device's drvdata, v4l2_device_register() will keep doing so if the drvdata is NULL. Signed-off-by: Laurent Pinchart --- Documentation/video4linux/v4l2-framework.txt | 17 - drivers/media/video/v4l2-device.c| 13 +++-- include/media/v4l2-device.h |4 3 files changed, 23 insertions(+), 11 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 4db1def..aeb2a22 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -83,11 +83,17 @@ You must register the device instance: v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); -Registration will initialize the v4l2_device struct and link dev->driver_data -to v4l2_dev. If v4l2_dev->name is empty then it will be set to a value derived -from dev (driver name followed by the bus_id, to be precise). If you set it -up before calling v4l2_device_register then it will be untouched. If dev is -NULL, then you *must* setup v4l2_dev->name before calling v4l2_device_register. +Registration will initialize the v4l2_device struct. If the dev->driver_data +field is NULL, it will be linked to v4l2_dev. Drivers that use the media +device framework in addition to the V4L2 framework need to set +dev->driver_data manually to point to the driver-specific device structure +that embed the struct v4l2_device instance. This is achieved by a +dev_set_drvdata() call before registering the V4L2 device instance. + +If v4l2_dev->name is empty then it will be set to a value derived from dev +(driver name followed by the bus_id, to be precise). If you set it up before +calling v4l2_device_register then it will be untouched. If dev is NULL, then +you *must* setup v4l2_dev->name before calling v4l2_device_register. You can use v4l2_device_set_name() to set the name based on a driver name and a driver-global atomic_t instance. This will generate names like ivtv0, ivtv1, @@ -108,6 +114,7 @@ You unregister with: v4l2_device_unregister(struct v4l2_device *v4l2_dev); +If the dev->driver_data field points to v4l2_dev, it will be reset to NULL. Unregistering will also automatically unregister all subdevs from the device. If you have a hotpluggable device (e.g. a USB device), then when a disconnect diff --git a/drivers/media/video/v4l2-device.c b/drivers/media/video/v4l2-device.c index 318e911..8447466 100644 --- a/drivers/media/video/v4l2-device.c +++ b/drivers/media/video/v4l2-device.c @@ -46,9 +46,8 @@ int v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev) if (!v4l2_dev->name[0]) snprintf(v4l2_dev->name, sizeof(v4l2_dev->name), "%s %s", dev->driver->name, dev_name(dev)); - if (dev_get_drvdata(dev)) - v4l2_warn(v4l2_dev, "Non-NULL drvdata on register\n"); - dev_set_drvdata(dev, v4l2_dev); + if (!dev_get_drvdata(dev)) + dev_set_drvdata(dev, v4l2_dev); return 0; } EXPORT_SYMBOL_GPL(v4l2_device_register); @@ -71,10 +70,12 @@ EXPORT_SYMBOL_GPL(v4l2_device_set_name); void v4l2_device_disconnect(struct v4l2_device *v4l2_dev) { - if (v4l2_dev->dev) { + if (v4l2_dev->dev == NULL) + return; + + if (dev_get_drvdata(v4l2_dev->dev) == v4l2_dev) dev_set_drvdata(v4l2_dev->dev, NULL); - v4l2_dev->dev = NULL; - } + v4l2_dev->dev = NULL; } EXPORT_SYMBOL_GPL(v4l2_device_disconnect); diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h index 6648036..b649c74 100644 --- a/include/media/v4l2-device.h +++ b/include/media/v4l2-device.h @@ -21,6 +21,7 @@ #ifndef _V4L2_DEVICE_H #define _V4L2_DEVICE_H +#include #include /* Each instance of a V4L2 device should create the v4l2_device struct, @@ -39,6 +40,9 @@ struct v4l2_device { Note: dev might be NULL if there is no parent device as is the case with e.g. ISA devices. */ struct device *dev; +#if defined(CONFIG_MEDIA_CONTROLLER) + struct media_device *mdev; +#endif /* used to keep track of the registered subdevs */ struct list_head subdevs; /* lock this struct; can be used by the driver as well if this -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v7 12/12] v4l: Make v4l2_subdev inherit from media_entity
V4L2 subdevices are media entities. As such they need to inherit from (include) the media_entity structure. When registering/unregistering the subdevice, the media entity is automatically registered/unregistered. The entity is acquired on device open and released on device close. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus --- Documentation/video4linux/v4l2-framework.txt | 23 ++ drivers/media/video/v4l2-device.c| 39 drivers/media/video/v4l2-subdev.c| 41 - include/media/v4l2-subdev.h | 10 ++ 4 files changed, 104 insertions(+), 9 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index f231bc20..d0fb880 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -268,6 +268,26 @@ A sub-device driver initializes the v4l2_subdev struct using: Afterwards you need to initialize subdev->name with a unique name and set the module owner. This is done for you if you use the i2c helper functions. +If integration with the media framework is needed, you must initialize the +media_entity struct embedded in the v4l2_subdev struct (entity field) by +calling media_entity_init(): + + struct media_pad *pads = &my_sd->pads; + int err; + + err = media_entity_init(&sd->entity, npads, pads, 0); + +The pads array must have been previously initialized. There is no need to +manually set the struct media_entity type and name fields, but the revision +field must be initialized if needed. + +A reference to the entity will be automatically acquired/released when the +subdev device node (if any) is opened/closed. + +Don't forget to cleanup the media entity before the sub-device is destroyed: + + media_entity_cleanup(&sd->entity); + A device (bridge) driver needs to register the v4l2_subdev with the v4l2_device: @@ -277,6 +297,9 @@ This can fail if the subdev module disappeared before it could be registered. After this function was called successfully the subdev->dev field points to the v4l2_device. +If the v4l2_device parent device has a non-NULL mdev field, the sub-device +entity will be automatically registered with the media device. + You can unregister a sub-device using: v4l2_device_unregister_subdev(sd); diff --git a/drivers/media/video/v4l2-device.c b/drivers/media/video/v4l2-device.c index 8447466..7ac4d0f 100644 --- a/drivers/media/video/v4l2-device.c +++ b/drivers/media/video/v4l2-device.c @@ -115,8 +115,11 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev) EXPORT_SYMBOL_GPL(v4l2_device_unregister); int v4l2_device_register_subdev(struct v4l2_device *v4l2_dev, - struct v4l2_subdev *sd) + struct v4l2_subdev *sd) { +#if defined(CONFIG_MEDIA_CONTROLLER) + struct media_entity *entity = &sd->entity; +#endif struct video_device *vdev; int err; @@ -134,7 +137,16 @@ int v4l2_device_register_subdev(struct v4l2_device *v4l2_dev, err = v4l2_ctrl_add_handler(v4l2_dev->ctrl_handler, sd->ctrl_handler); if (err) return err; - +#if defined(CONFIG_MEDIA_CONTROLLER) + /* Register the entity. */ + if (v4l2_dev->mdev) { + err = media_device_register_entity(v4l2_dev->mdev, entity); + if (err < 0) { + module_put(sd->owner); + return err; + } + } +#endif sd->v4l2_dev = v4l2_dev; spin_lock(&v4l2_dev->lock); list_add_tail(&sd->list, &v4l2_dev->subdevs); @@ -149,26 +161,39 @@ int v4l2_device_register_subdev(struct v4l2_device *v4l2_dev, if (sd->flags & V4L2_SUBDEV_FL_HAS_DEVNODE) { err = __video_register_device(vdev, VFL_TYPE_SUBDEV, -1, 1, sd->owner); - if (err < 0) + if (err < 0) { v4l2_device_unregister_subdev(sd); + return err; + } } - - return err; +#if defined(CONFIG_MEDIA_CONTROLLER) + entity->v4l.major = VIDEO_MAJOR; + entity->v4l.minor = vdev->minor; +#endif + return 0; } EXPORT_SYMBOL_GPL(v4l2_device_register_subdev); void v4l2_device_unregister_subdev(struct v4l2_subdev *sd) { + struct v4l2_device *v4l2_dev; + /* return if it isn't registered */ if (sd == NULL || sd->v4l2_dev == NULL) return; - spin_lock(&sd->v4l2_dev->lock); + v4l2_dev = sd->v4l2_dev; + + spin_lock(&v4l2_dev->lock); list_del(&sd->list); - spin_unlock(&sd->v4l2_dev->lock); + spin_unlock(&v4l2_dev->lock); sd->v4l2_dev = NULL; module_put(sd->owner); +#if defined(CONFIG_MEDIA_CONTROLLER) + if (v4l2_dev->mdev)
[RFC/PATCH v7 05/12] media: Reference count and power handling
From: Sakari Ailus Basically these are the interface functions: media_entity_get() - acquire entity media_entity_put() - release entity If the entity is of node type, the power change is distributed to all connected entities. For non-nodes it only affects that very node. A mutex is used to serialise access to the entity graph. In the background there's a depth-first search algorithm that traverses the enabled links in the graph. All these functions parse the graph to implement whatever they're to do. The module counters are increased/decreased in media_entity_get/put to prevent module unloading when an entity is referenced. Signed-off-by: Sakari Ailus Signed-off-by: Laurent Pinchart Signed-off-by: Stanimir Varbanov --- Documentation/media-framework.txt | 37 + drivers/media/media-device.c |1 + drivers/media/media-entity.c | 146 + include/media/media-device.h |4 + include/media/media-entity.h | 15 5 files changed, 203 insertions(+), 0 deletions(-) diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 2cf3676..e90969e 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -259,3 +259,40 @@ When the graph traversal is complete the function will return NULL. Graph traversal can be interrupted at any moment. No cleanup function call is required and the graph structure can be freed normally. + +Reference counting and power handling +- + +Before accessing type-specific entities operations (such as the V4L2 +sub-device operations), drivers must acquire a reference to the entity. This +ensures that the entity will be powered on and ready to accept requests. +Similarly, after being done with an entity, drivers must release the +reference. + + media_entity_get(struct media_entity *entity) + +The function will increase the entity reference count. If the entity is a node +(MEDIA_ENTITY_TYPE_DEVNODE type), the reference count of all entities it is +connected to, both directly or indirectly, through enabled links is increased. +This ensures that the whole media pipeline will be ready to process + +Acquiring a reference to an entity increases the media device module reference +count to prevent module unloading when an entity is being used. + +media_entity_get will return a pointer to the entity if successful, or NULL +otherwise. + + media_entity_put(struct media_entity *entity) + +The function will decrease the entity reference count and, for node entities, +like media_entity_get, the reference count of all connected entities. Calling +media_entity_put with a NULL argument is valid and will return immediately. + +When the first reference to an entity is acquired, or the last reference +released, the entity's set_power operation is called. Entity drivers must +implement the operation if they need to perform any power management task, +such as turning powers or clocks on or off. If no power management is +required, drivers don't need to provide a set_power operation. The operation +is allowed to fail when turning power on, in which case the media_entity_get +function will return NULL. + diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index b8a3ace..e4c2157 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -73,6 +73,7 @@ int __must_check media_device_register(struct media_device *mdev) mdev->entity_id = 1; INIT_LIST_HEAD(&mdev->entities); spin_lock_init(&mdev->lock); + mutex_init(&mdev->graph_mutex); /* Register the device node. */ mdev->devnode.fops = &media_device_fops; diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c index 15f4192..c541f4a 100644 --- a/drivers/media/media-entity.c +++ b/drivers/media/media-entity.c @@ -23,6 +23,7 @@ #include #include #include +#include /** * media_entity_init - Initialize a media entity @@ -196,6 +197,151 @@ media_entity_graph_walk_next(struct media_entity_graph *graph) EXPORT_SYMBOL_GPL(media_entity_graph_walk_next); /* - + * Power state handling + */ + +/* Apply use count to an entity. */ +static void media_entity_use_apply_one(struct media_entity *entity, int change) +{ + entity->use_count += change; + WARN_ON(entity->use_count < 0); +} + +/* + * Apply use count change to an entity and change power state based on + * new use count. + */ +static int media_entity_power_apply_one(struct media_entity *entity, int change) +{ + int ret; + + if (entity->use_count == 0 && change > 0 && + entity->ops && entity->ops->set_power) { + ret = entity->ops->set_power(entity, 1); + if (ret) + return ret; + } + + media_entity_use_apply_one(entity, change); + + if (ent
[RFC/PATCH v7 08/12] media: Links setup
Create the following ioctl and implement it at the media device level to setup links. - MEDIA_IOC_SETUP_LINK: Modify the properties of a given link The only property that can currently be modified is the ENABLED link flag to enable/disable a link. Links marked with the IMMUTABLE link flag can not be enabled or disabled. Enabling or disabling a link has effects on entities' use count. Those changes are automatically propagated through the graph. Signed-off-by: Laurent Pinchart Signed-off-by: Stanimir Varbanov Signed-off-by: Sakari Ailus --- Documentation/DocBook/media-entities.tmpl |2 + Documentation/DocBook/v4l/media-controller.xml |1 + Documentation/DocBook/v4l/media-ioc-setup-link.xml | 90 + Documentation/media-framework.txt | 47 + drivers/media/media-device.c | 45 + drivers/media/media-entity.c | 208 include/linux/media.h |1 + include/media/media-entity.h |8 + 8 files changed, 402 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/media-ioc-setup-link.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 6e7dae4..679c585 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -94,6 +94,7 @@ MEDIA_IOC_DEVICE_INFO"> MEDIA_IOC_ENUM_ENTITIES"> MEDIA_IOC_ENUM_LINKS"> +MEDIA_IOC_SETUP_LINK"> v4l2_std_id"> @@ -342,6 +343,7 @@ + diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index 2c4fd2b..2dc25e1 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -85,4 +85,5 @@ &sub-media-ioc-device-info; &sub-media-ioc-enum-entities; &sub-media-ioc-enum-links; + &sub-media-ioc-setup-link; diff --git a/Documentation/DocBook/v4l/media-ioc-setup-link.xml b/Documentation/DocBook/v4l/media-ioc-setup-link.xml new file mode 100644 index 000..09ab3d2 --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-setup-link.xml @@ -0,0 +1,90 @@ + + +ioctl MEDIA_IOC_SETUP_LINK +&manvol; + + + +MEDIA_IOC_SETUP_LINK +Modify the properties of a link + + + + + + int ioctl + int fd + int request + struct media_link_desc *argp + + + + + +Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_ENUM_LINKS + + + + argp + + + + + + + + +Description + +To change link properties applications fill a &media-link-desc; with +link identification information (source and sink pad) and the new requested +link flags. They then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to +that structure. +The only configurable property is the ENABLED +link flag to enable/disable a link. Links marked with the +IMMUTABLE link flag can not be enabled or disabled. + +Link configuration has no side effect on other links. If an enabled +link at the sink pad prevents the link from being enabled, the driver +returns with an &EBUSY;. +If the specified link can't be found the driver returns with an +&EINVAL;. + + + +&return-value; + + + + EBUSY + + The link properties can't be changed because the link is + currently busy. This can be caused, for instance, by an active media + stream (audio or video) on the link. The ioctl shouldn't be retried if + no other action is performed before to fix the problem. + + + + EINVAL + + The &media-link-desc; references a non-existing link, or the + link is immutable and an attempt to modify its configuration was made. + + + + + + diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index e90969e..4603417 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -259,6 +259,16 @@ When the graph traversal is complete the function will return NULL. Graph traversal can be interrupted at any moment. No cleanup function call is required and the graph structure can be freed normally. +Helper functions can be used to find a link between two given pads, or a pad +connected to another pad through an enabled link + + media_entity_find_link(struct media_pad *source, + struct media_pad *sink); + + media_entity_remote_source(struct media_pad *pad); + +Refer to the kerneldoc documentation for more information. + Reference counting and power handling - @@ -296,3 +306,40 @@ required, d
[RFC/PATCH v7 02/12] media: Media device
The media_device structure abstracts functions common to all kind of media devices (v4l2, dvb, alsa, ...). It manages media entities and offers a userspace API to discover and configure the media device internal topology. Signed-off-by: Laurent Pinchart --- Documentation/DocBook/media-entities.tmpl |2 + Documentation/DocBook/media.tmpl |3 + Documentation/DocBook/v4l/media-controller.xml | 56 + Documentation/media-framework.txt | 68 drivers/media/Makefile |2 +- drivers/media/media-device.c | 100 include/media/media-device.h | 69 7 files changed, 299 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/v4l/media-controller.xml create mode 100644 Documentation/media-framework.txt create mode 100644 drivers/media/media-device.c create mode 100644 include/media/media-device.h diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index be34dcb..61d6f11 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -321,6 +321,8 @@ + + diff --git a/Documentation/DocBook/media.tmpl b/Documentation/DocBook/media.tmpl index f11048d..73464b0 100644 --- a/Documentation/DocBook/media.tmpl +++ b/Documentation/DocBook/media.tmpl @@ -106,6 +106,9 @@ Foundation. A copy of the license is included in the chapter entitled &sub-remote_controllers; + +&sub-media-controller; + &sub-fdl-appendix; diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml new file mode 100644 index 000..253ddb4 --- /dev/null +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -0,0 +1,56 @@ + + + + Laurent + Pinchart + laurent.pinch...@ideasonboard.com + Initial version. + + + +2010 +Laurent Pinchart + + + + + + 1.0.0 + 2010-11-10 + lp + Initial revision + + + + +Media Controller API + + + Media Controller + + +Introduction +Media devices increasingly handle multiple related functions. Many USB +cameras include microphones, video capture hardware can also output video, +or SoC camera interfaces also perform memory-to-memory operations similar to +video codecs. +Independent functions, even when implemented in the same hardware, can +be modelled as separate devices. A USB camera with a microphone will be +presented to userspace applications as V4L2 and ALSA capture devices. The +devices' relationships (when using a webcam, end-users shouldn't have to +manually select the associated USB microphone), while not made available +directly to applications by the drivers, can usually be retrieved from +sysfs. +With more and more advanced SoC devices being introduced, the current +approach will not scale. Device topologies are getting increasingly complex +and can't always be represented by a tree structure. Hardware blocks are +shared between different functions, creating dependencies between seemingly +unrelated devices. +Kernel abstraction APIs such as V4L2 and ALSA provide means for +applications to access hardware parameters. As newer hardware expose an +increasingly high number of those parameters, drivers need to guess what +applications really require based on limited information, thereby +implementing policies that belong to userspace. +The media controller API aims at solving those problems. + + diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt new file mode 100644 index 000..84fa43a --- /dev/null +++ b/Documentation/media-framework.txt @@ -0,0 +1,68 @@ +Linux kernel media framework + + +This document describes the Linux kernel media framework, its data structures, +functions and their usage. + + +Introduction + + +The media controller API is documented in DocBook format in +Documentation/DocBook/v4l/media-controller.xml. This document will focus on +the kernel-side implementation of the media framework. + + +Media device + + +A media device is represented by a struct media_device instance, defined in +include/media/media-device.h. Allocation of the structure is handled by the +media device driver, usually by embedding the media_device instance in a +larger driver-specific structure. + +Drivers register media device instances by calling + + media_device_register(struct media_device *mdev); + +The caller is responsible for initializing the media_device structure before +registration. The following fields must be set: + + - dev must point to the parent device (usually a pci_dev, usb_interface or + platform_device instance). + + - model must be filled with the device model name as a NUL-terminated UT
[RFC/PATCH v7 04/12] media: Entity graph traversal
From: Sakari Ailus Add media entity graph traversal. The traversal follows enabled links by depth first. Traversing graph backwards is prevented by comparing the next possible entity in the graph with the previous one. Multiply connected graphs are thus not supported. Signed-off-by: Sakari Ailus Signed-off-by: Laurent Pinchart Signed-off-by: Vimarsh Zutshi --- Documentation/media-framework.txt | 42 + drivers/media/media-entity.c | 115 + include/media/media-entity.h | 15 + 3 files changed, 172 insertions(+), 0 deletions(-) diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index c35b641..2cf3676 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -217,3 +217,45 @@ Links have flags that describe the link capabilities and state. MEDIA_LINK_FLAG_ENABLED must also be set since an immutable link is always enabled. + +Graph traversal +--- + +The media framework provides APIs to iterate over entities in a graph. + +To iterate over all entities belonging to a media device, drivers can use the +media_device_for_each_entity macro, defined in include/media/media-device.h. + + struct media_entity *entity; + + media_device_for_each_entity(entity, mdev) { + /* entity will point to each entity in turn */ + ... + } + +Drivers might also need to iterate over all entities in a graph that can be +reached only through enabled links starting at a given entity. The media +framework provides a depth-first graph traversal API for that purpose. + +Note that graphs with cycles (whether directed or undirected) are *NOT* +supported by the graph traversal API. To prevent infinite loops, the graph +traversal code limits the maximum depth to MEDIA_ENTITY_ENUM_MAX_DEPTH, +currently defined as 16. + +Drivers initiate a graph traversal by calling + + media_entity_graph_walk_start(struct media_entity_graph *graph, + struct media_entity *entity); + +The graph structure, provided by the caller, is initialized to start graph +traversal at the given entity. + +Drivers can then retrieve the next entity by calling + + media_entity_graph_walk_next(struct media_entity_graph *graph); + +When the graph traversal is complete the function will return NULL. + +Graph traversal can be interrupted at any moment. No cleanup function call is +required and the graph structure can be freed normally. + diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c index e4ba2bc..15f4192 100644 --- a/drivers/media/media-entity.c +++ b/drivers/media/media-entity.c @@ -84,6 +84,121 @@ media_entity_cleanup(struct media_entity *entity) } EXPORT_SYMBOL_GPL(media_entity_cleanup); +/* - + * Graph traversal + */ + +static struct media_entity * +media_entity_other(struct media_entity *entity, struct media_link *link) +{ + if (link->source->entity == entity) + return link->sink->entity; + else + return link->source->entity; +} + +/* push an entity to traversal stack */ +static void stack_push(struct media_entity_graph *graph, + struct media_entity *entity) +{ + if (graph->top == MEDIA_ENTITY_ENUM_MAX_DEPTH - 1) { + WARN_ON(1); + return; + } + graph->top++; + graph->stack[graph->top].link = 0; + graph->stack[graph->top].entity = entity; +} + +static struct media_entity *stack_pop(struct media_entity_graph *graph) +{ + struct media_entity *entity; + + entity = graph->stack[graph->top].entity; + graph->top--; + + return entity; +} + +#define stack_peek(en) ((en)->stack[(en)->top - 1].entity) +#define link_top(en) ((en)->stack[(en)->top].link) +#define stack_top(en) ((en)->stack[(en)->top].entity) + +/** + * media_entity_graph_walk_start - Start walking the media graph at a given entity + * @graph: Media graph structure that will be used to walk the graph + * @entity: Starting entity + * + * This function initializes the graph traversal structure to walk the entities + * graph starting at the given entity. The traversal structure must not be + * modified by the caller during graph traversal. When done the structure can + * safely be freed. + */ +void media_entity_graph_walk_start(struct media_entity_graph *graph, + struct media_entity *entity) +{ + graph->top = 0; + graph->stack[graph->top].entity = NULL; + stack_push(graph, entity); +} +EXPORT_SYMBOL_GPL(media_entity_graph_walk_start); + +/** + * media_entity_graph_walk_next - Get the next entity in the graph + * @graph: Media graph structure + * + * Perform a depth-first traversal of the given media entities graph. + * + * The graph structure must have been previously init
[RFC/PATCH v7 00/12] Media controller (core and V4L2)
Hi everybody, Here is the seventh version of the media controller core and V4L2 patches. the first one to be sent outside of the linux-media mailing list. Quick reminder for those who missed the previous version. let me quote the documentation (Documentation/DocBook/v4l/media-controller.xml). "Discovering a [media] device internal topology, and configuring it at runtime, is one of the goals of the media controller API. To achieve this, hardware devices are modelled as an oriented graph of building blocks called entities connected through pads." The code has been extensively reviewed by the V4L community, and this version is the first one to incorporate comments from the ALSA community (big thanks to Mark Brown and Clemens Ladisch). Two issues are not fully addressed yet, namely power management (I need to discuss this some more with the ALSA developers to really understand their requirements) and entities type names. I'm still posting this for review, as other developers have showed interest in commenting on the code. I want to emphasize once again that the media controller API does not replace the V4L, DVB or ALSA APIs. It complements them. The first user of the media controller API is the OMAP3 ISP driver. You can find it (as well as these patches and other V4L-specific patches) in a git tree at http://git.linuxtv.org/pinchartl/media.git (media-0004-omap3isp branch). The OMAP3 ISP driver patches are regularly posted for review on the linux-media list. Laurent Pinchart (10): media: Media device node support media: Media device media: Entities, pads and links media: Media device information query media: Entities, pads and links enumeration media: Links setup media: Pipelines and media streams v4l: Add a media_device pointer to the v4l2_device structure v4l: Make video_device inherit from media_entity v4l: Make v4l2_subdev inherit from media_entity Sakari Ailus (2): media: Entity graph traversal media: Reference count and power handling Documentation/DocBook/media-entities.tmpl | 24 + Documentation/DocBook/media.tmpl |3 + Documentation/DocBook/v4l/media-controller.xml | 89 +++ Documentation/DocBook/v4l/media-func-close.xml | 59 ++ Documentation/DocBook/v4l/media-func-ioctl.xml | 116 Documentation/DocBook/v4l/media-func-open.xml | 94 +++ .../DocBook/v4l/media-ioc-device-info.xml | 133 .../DocBook/v4l/media-ioc-enum-entities.xml| 308 + Documentation/DocBook/v4l/media-ioc-enum-links.xml | 207 ++ Documentation/DocBook/v4l/media-ioc-setup-link.xml | 93 +++ Documentation/media-framework.txt | 383 +++ Documentation/video4linux/v4l2-framework.txt | 72 ++- drivers/media/Kconfig | 13 + drivers/media/Makefile | 10 +- drivers/media/media-device.c | 382 +++ drivers/media/media-devnode.c | 321 + drivers/media/media-entity.c | 690 drivers/media/video/v4l2-dev.c | 49 ++- drivers/media/video/v4l2-device.c | 52 ++- drivers/media/video/v4l2-subdev.c | 41 ++- include/linux/Kbuild |1 + include/linux/media.h | 132 include/media/media-device.h | 92 +++ include/media/media-devnode.h | 97 +++ include/media/media-entity.h | 148 + include/media/v4l2-dev.h |7 + include/media/v4l2-device.h|4 + include/media/v4l2-subdev.h| 10 + 28 files changed, 3603 insertions(+), 27 deletions(-) create mode 100644 Documentation/DocBook/v4l/media-controller.xml create mode 100644 Documentation/DocBook/v4l/media-func-close.xml create mode 100644 Documentation/DocBook/v4l/media-func-ioctl.xml create mode 100644 Documentation/DocBook/v4l/media-func-open.xml create mode 100644 Documentation/DocBook/v4l/media-ioc-device-info.xml create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-entities.xml create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-links.xml create mode 100644 Documentation/DocBook/v4l/media-ioc-setup-link.xml create mode 100644 Documentation/media-framework.txt create mode 100644 drivers/media/media-device.c create mode 100644 drivers/media/media-devnode.c create mode 100644 drivers/media/media-entity.c create mode 100644 include/linux/media.h create mode 100644 include/media/media-device.h create mode 100644 include/media/media-devnode.h create mode 100644 include/media/media-entity.h -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://v
[RFC/PATCH v5 5/7] v4l: subdev: Uninline the v4l2_subdev_init function
The function isn't small or performance sensitive enough to be inlined. Signed-off-by: Laurent Pinchart --- drivers/media/video/v4l2-subdev.c | 42 +--- include/media/v4l2-subdev.h | 16 + 2 files changed, 31 insertions(+), 27 deletions(-) diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 00bd4b1..0deff78 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -1,22 +1,23 @@ /* - * V4L2 subdevice support. + * V4L2 sub-device * - * Copyright (C) 2010 Nokia Corporation + * Copyright (C) 2010 Nokia Corporation * - * Contact: Laurent Pinchart + * Contact: Laurent Pinchart + * Sakari Ailus * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation. + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include @@ -64,3 +65,18 @@ const struct v4l2_file_operations v4l2_subdev_fops = { .unlocked_ioctl = subdev_ioctl, .release = subdev_close, }; + +void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops *ops) +{ + INIT_LIST_HEAD(&sd->list); + BUG_ON(!ops); + sd->ops = ops; + sd->v4l2_dev = NULL; + sd->flags = 0; + sd->name[0] = '\0'; + sd->grp_id = 0; + sd->dev_priv = NULL; + sd->host_priv = NULL; + sd->initialized = 1; +} +EXPORT_SYMBOL(v4l2_subdev_init); diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index de181db..90022f5 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -473,20 +473,8 @@ static inline void *v4l2_get_subdev_hostdata(const struct v4l2_subdev *sd) return sd->host_priv; } -static inline void v4l2_subdev_init(struct v4l2_subdev *sd, - const struct v4l2_subdev_ops *ops) -{ - INIT_LIST_HEAD(&sd->list); - BUG_ON(!ops); - sd->ops = ops; - sd->v4l2_dev = NULL; - sd->flags = 0; - sd->name[0] = '\0'; - sd->grp_id = 0; - sd->dev_priv = NULL; - sd->host_priv = NULL; - sd->initialized = 1; -} +void v4l2_subdev_init(struct v4l2_subdev *sd, + const struct v4l2_subdev_ops *ops); /* Call an ops of a v4l2_subdev, doing the right checks against NULL pointers. -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 7/7] v4l: subdev: Events support
From: Sakari Ailus Provide v4l2_subdevs with v4l2_event support. Subdev drivers only need very little to support events. Signed-off-by: Sakari Ailus Signed-off-by: David Cohen Signed-off-by: Laurent Pinchart --- Documentation/video4linux/v4l2-framework.txt | 18 ++ drivers/media/video/v4l2-subdev.c| 75 +- include/media/v4l2-subdev.h | 10 3 files changed, 102 insertions(+), 1 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index f683f63..4db1def 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -352,6 +352,24 @@ VIDIOC_TRY_EXT_CTRLS controls can be also be accessed through one (or several) V4L2 device nodes. +VIDIOC_DQEVENT +VIDIOC_SUBSCRIBE_EVENT +VIDIOC_UNSUBSCRIBE_EVENT + + The events ioctls are identical to the ones defined in V4L2. They + behave identically, with the only exception that they deal only with + events generated by the sub-device. Depending on the driver, those + events can also be reported by one (or several) V4L2 device nodes. + + Sub-device drivers that want to use events need to set the + V4L2_SUBDEV_USES_EVENTS v4l2_subdev::flags and initialize + v4l2_subdev::nevents to events queue depth before registering the + sub-device. After registration events can be queued as usual on the + v4l2_subdev::devnode device node. + + To properly support events, the poll() file operation is also + implemented. + I2C sub-device drivers -- diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index fc57ce7..fbccefd 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -20,27 +20,69 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#include #include +#include +#include #include #include #include #include +#include +#include static int subdev_open(struct file *file) { struct video_device *vdev = video_devdata(file); struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev); + struct v4l2_fh *vfh; + int ret; if (!sd->initialized) return -EAGAIN; + if (sd->flags & V4L2_SUBDEV_FL_HAS_EVENTS) { + vfh = kzalloc(sizeof(*vfh), GFP_KERNEL); + if (vfh == NULL) + return -ENOMEM; + + ret = v4l2_fh_init(vfh, vdev); + if (ret) + goto err; + + ret = v4l2_event_init(vfh); + if (ret) + goto err; + + ret = v4l2_event_alloc(vfh, sd->nevents); + if (ret) + goto err; + + v4l2_fh_add(vfh); + file->private_data = vfh; + } + return 0; + +err: + if (vfh != NULL) { + v4l2_fh_exit(vfh); + kfree(vfh); + } + + return ret; } static int subdev_close(struct file *file) { + struct v4l2_fh *vfh = file->private_data; + + if (vfh != NULL) { + v4l2_fh_del(vfh); + v4l2_fh_exit(vfh); + kfree(vfh); + } + return 0; } @@ -48,6 +90,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) { struct video_device *vdev = video_devdata(file); struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev); + struct v4l2_fh *fh = file->private_data; switch (cmd) { case VIDIOC_QUERYCTRL: @@ -71,6 +114,18 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) case VIDIOC_TRY_EXT_CTRLS: return v4l2_subdev_try_ext_ctrls(sd, arg); + case VIDIOC_DQEVENT: + if (!(sd->flags & V4L2_SUBDEV_FL_HAS_EVENTS)) + return -ENOIOCTLCMD; + + return v4l2_event_dequeue(fh, arg, file->f_flags & O_NONBLOCK); + + case VIDIOC_SUBSCRIBE_EVENT: + return v4l2_subdev_call(sd, core, subscribe_event, fh, arg); + + case VIDIOC_UNSUBSCRIBE_EVENT: + return v4l2_subdev_call(sd, core, unsubscribe_event, fh, arg); + default: return -ENOIOCTLCMD; } @@ -84,11 +139,29 @@ static long subdev_ioctl(struct file *file, unsigned int cmd, return __video_usercopy(file, cmd, arg, subdev_do_ioctl); } +static unsigned int subdev_poll(struct file *file, poll_table *wait) +{ + struct video_device *vdev = video_devdata(file); + struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev); + struct v4l2_fh *fh = file->private_data; + + if (!(sd->flags & V4L2_SUBDEV_FL_HAS_EVENTS)) + return POLLERR; + + poll_wait(file, &fh->events->wait, wait); + + if (v4l2_event_pending(fh)) +
[RFC/PATCH v5 4/7] v4l: subdev: Add device node support
Create a device node named subdevX for every registered subdev. As the device node is registered before the subdev core::s_config function is called, return -EGAIN on open until initialization completes. Signed-off-by: Laurent Pinchart Signed-off-by: Vimarsh Zutshi --- Documentation/video4linux/v4l2-framework.txt | 18 +++ drivers/media/radio/radio-si4713.c |2 +- drivers/media/video/Makefile |2 +- drivers/media/video/cafe_ccic.c |2 +- drivers/media/video/davinci/vpfe_capture.c |2 +- drivers/media/video/davinci/vpif_capture.c |2 +- drivers/media/video/davinci/vpif_display.c |2 +- drivers/media/video/ivtv/ivtv-i2c.c |2 +- drivers/media/video/s5p-fimc/fimc-capture.c |2 +- drivers/media/video/sh_vou.c |2 +- drivers/media/video/soc_camera.c |2 +- drivers/media/video/v4l2-common.c| 15 +- drivers/media/video/v4l2-dev.c | 27 -- drivers/media/video/v4l2-device.c| 24 +- drivers/media/video/v4l2-ioctl.c |2 +- drivers/media/video/v4l2-subdev.c| 66 ++ include/media/v4l2-common.h |5 +- include/media/v4l2-dev.h | 18 ++- include/media/v4l2-ioctl.h |3 + include/media/v4l2-subdev.h | 16 ++- 20 files changed, 176 insertions(+), 38 deletions(-) create mode 100644 drivers/media/video/v4l2-subdev.c diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index f22f35c..4c9185a 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -319,6 +319,24 @@ controlled through GPIO pins. This distinction is only relevant when setting up the device, but once the subdev is registered it is completely transparent. +V4L2 sub-device userspace API +- + +Beside exposing a kernel API through the v4l2_subdev_ops structure, V4L2 +sub-devices can also be controlled directly by userspace applications. + +When a sub-device is registered, a device node named v4l-subdevX can be created +in /dev. If the sub-device supports direct userspace configuration it must set +the V4L2_SUBDEV_FL_HAS_DEVNODE flag before being registered. + +For I2C and SPI sub-devices, the v4l2_device driver can disable registration of +the device node if it wants to control the sub-device on its own. In that case +it must set the v4l2_i2c_new_subdev_board or v4l2_spi_new_subdev enable_devnode +argument to 0. Setting the argument to 1 will only enable device node +registration if the sub-device driver has set the V4L2_SUBDEV_FL_HAS_DEVNODE +flag. + + I2C sub-device drivers -- diff --git a/drivers/media/radio/radio-si4713.c b/drivers/media/radio/radio-si4713.c index 03829e6..24c9947 100644 --- a/drivers/media/radio/radio-si4713.c +++ b/drivers/media/radio/radio-si4713.c @@ -292,7 +292,7 @@ static int radio_si4713_pdriver_probe(struct platform_device *pdev) } sd = v4l2_i2c_new_subdev_board(&rsdev->v4l2_dev, adapter, - pdata->subdev_board_info, NULL); + pdata->subdev_board_info, NULL, 0); if (!sd) { dev_err(&pdev->dev, "Cannot get v4l2 subdevice\n"); rval = -ENODEV; diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index af79d47..adc1bd5 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -11,7 +11,7 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \ - v4l2-event.o v4l2-ctrls.o + v4l2-event.o v4l2-ctrls.o v4l2-subdev.o # V4L2 core modules diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c index d4ca0fa..0abebe5 100644 --- a/drivers/media/video/cafe_ccic.c +++ b/drivers/media/video/cafe_ccic.c @@ -2073,7 +2073,7 @@ static int cafe_pci_probe(struct pci_dev *pdev, info.platform_data = &sensor_cfg; cam->sensor = v4l2_i2c_new_subdev_board(&cam->v4l2_dev, - &cam->i2c_adapter, &info, NULL); + &cam->i2c_adapter, &info, NULL, 0); if (cam->sensor == NULL) { ret = -ENODEV; goto out_smbus; diff --git a/drivers/media/video/davinci/vpfe_capture.c b/drivers/media/video/davinci/vpfe_capture.c index 7333a9b..bfc2a47 100644 --- a/drivers/media/video/davinci/vpfe_capture.c +++ b/drivers/media/video/davinci/vpfe_capture.c @@ -1987,7 +1987,7 @@ static __init int vpfe_probe(struct platform_device *pdev) v4l2_i2c_new_subdev_board(&vpfe_dev->v4l2_dev,
[RFC/PATCH v5 3/7] v4l: subdev: Merge v4l2_i2c_new_subdev_cfg and v4l2_i2c_new_subdev
v4l2_i2c_new_subdev is a thin wrapper around v4l2_i2c_new_subdev_cfg, which is itself a wrapper around v4l2_i2c_new_subdev_board. The intermediate v4l2_i2c_new_subdev_cfg function is called directly by the ivtv and cafe-ccic drivers only. Merge it with v4l2_i2c_new_subdev and use v4l2_i2c_new_subdev_board in the ivtv and cafe-ccic drivers. Signed-off-by: Laurent Pinchart --- drivers/media/video/cafe_ccic.c | 11 +-- drivers/media/video/ivtv/ivtv-i2c.c | 11 +-- drivers/media/video/v4l2-common.c |7 ++- include/media/v4l2-common.h | 13 + 4 files changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c index 260c666..d4ca0fa 100644 --- a/drivers/media/video/cafe_ccic.c +++ b/drivers/media/video/cafe_ccic.c @@ -1992,6 +1992,7 @@ static int cafe_pci_probe(struct pci_dev *pdev, { int ret; struct cafe_camera *cam; + struct i2c_board_info info; struct ov7670_config sensor_cfg = { /* This controller only does SMBUS */ .use_smbus = true, @@ -2065,8 +2066,14 @@ static int cafe_pci_probe(struct pci_dev *pdev, sensor_cfg.clock_speed = 45; cam->sensor_addr = 0x42; - cam->sensor = v4l2_i2c_new_subdev_cfg(&cam->v4l2_dev, &cam->i2c_adapter, - "ov7670", 0, &sensor_cfg, cam->sensor_addr, NULL); + + memset(&info, 0, sizeof(info)); + strlcpy(info.type, "ov7670", sizeof(info.type)); + info.addr = cam->sensor_addr; + info.platform_data = &sensor_cfg; + + cam->sensor = v4l2_i2c_new_subdev_board(&cam->v4l2_dev, + &cam->i2c_adapter, &info, NULL); if (cam->sensor == NULL) { ret = -ENODEV; goto out_smbus; diff --git a/drivers/media/video/ivtv/ivtv-i2c.c b/drivers/media/video/ivtv/ivtv-i2c.c index 665191c..6651a6c 100644 --- a/drivers/media/video/ivtv/ivtv-i2c.c +++ b/drivers/media/video/ivtv/ivtv-i2c.c @@ -267,10 +267,17 @@ int ivtv_i2c_register(struct ivtv *itv, unsigned idx) adap, type, 0, I2C_ADDRS(hw_addrs[idx])); } else if (hw == IVTV_HW_CX25840) { struct cx25840_platform_data pdata; + struct i2c_board_info info; pdata.pvr150_workaround = itv->pvr150_workaround; - sd = v4l2_i2c_new_subdev_cfg(&itv->v4l2_dev, - adap, type, 0, &pdata, hw_addrs[idx], NULL); + + memset(&info, 0, sizeof(info)); + strlcpy(info.type, type, sizeof(info.type)); + info.addr = hw_addrs[idx]; + info.platform_data = &pdata; + + sd = v4l2_i2c_new_subdev_board(&itv->v4l2_dev, adap, &info, + NULL); } else { sd = v4l2_i2c_new_subdev(&itv->v4l2_dev, adap, type, hw_addrs[idx], NULL); diff --git a/drivers/media/video/v4l2-common.c b/drivers/media/video/v4l2-common.c index b5eb1f3..e007e61 100644 --- a/drivers/media/video/v4l2-common.c +++ b/drivers/media/video/v4l2-common.c @@ -428,9 +428,8 @@ error: } EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev_board); -struct v4l2_subdev *v4l2_i2c_new_subdev_cfg(struct v4l2_device *v4l2_dev, +struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev, struct i2c_adapter *adapter, const char *client_type, - int irq, void *platform_data, u8 addr, const unsigned short *probe_addrs) { struct i2c_board_info info; @@ -440,12 +439,10 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_cfg(struct v4l2_device *v4l2_dev, memset(&info, 0, sizeof(info)); strlcpy(info.type, client_type, sizeof(info.type)); info.addr = addr; - info.irq = irq; - info.platform_data = platform_data; return v4l2_i2c_new_subdev_board(v4l2_dev, adapter, &info, probe_addrs); } -EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev_cfg); +EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev); /* Return i2c client address of v4l2_subdev. */ unsigned short v4l2_i2c_subdev_addr(struct v4l2_subdev *sd) diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h index 239125a..565fb32 100644 --- a/include/media/v4l2-common.h +++ b/include/media/v4l2-common.h @@ -138,21 +138,10 @@ struct v4l2_subdev_ops; /* Load an i2c module and return an initialized v4l2_subdev struct. The client_type argument is the name of the chip that's on the adapter. */ -struct v4l2_subdev *v4l2_i2c_new_subdev_cfg(struct v4l2_device *v4l2_dev, +struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev, struct i2c_adapter *adapter, const char *client_type, - int irq, void *platform_data, u8 addr, const unsigned short *probe_addrs); -/* Load an i2c module and return an initialized v4l2_subdev struct. - The client_type ar
[RFC/PATCH v5 6/7] v4l: subdev: Control ioctls support
Pass the control-related ioctls to the subdev driver through the control framework. Signed-off-by: Laurent Pinchart --- Documentation/video4linux/v4l2-framework.txt | 16 drivers/media/video/v4l2-subdev.c| 25 + 2 files changed, 41 insertions(+), 0 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 4c9185a..f683f63 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -336,6 +336,22 @@ argument to 0. Setting the argument to 1 will only enable device node registration if the sub-device driver has set the V4L2_SUBDEV_FL_HAS_DEVNODE flag. +The device node handles a subset of the V4L2 API. + +VIDIOC_QUERYCTRL +VIDIOC_QUERYMENU +VIDIOC_G_CTRL +VIDIOC_S_CTRL +VIDIOC_G_EXT_CTRLS +VIDIOC_S_EXT_CTRLS +VIDIOC_TRY_EXT_CTRLS + + The controls ioctls are identical to the ones defined in V4L2. They + behave identically, with the only exception that they deal only with + controls implemented in the sub-device. Depending on the driver, those + controls can be also be accessed through one (or several) V4L2 device + nodes. + I2C sub-device drivers -- diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 0deff78..fc57ce7 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -24,6 +24,7 @@ #include #include +#include #include #include @@ -45,7 +46,31 @@ static int subdev_close(struct file *file) static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) { + struct video_device *vdev = video_devdata(file); + struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev); + switch (cmd) { + case VIDIOC_QUERYCTRL: + return v4l2_subdev_queryctrl(sd, arg); + + case VIDIOC_QUERYMENU: + return v4l2_subdev_querymenu(sd, arg); + + case VIDIOC_G_CTRL: + return v4l2_subdev_g_ctrl(sd, arg); + + case VIDIOC_S_CTRL: + return v4l2_subdev_s_ctrl(sd, arg); + + case VIDIOC_G_EXT_CTRLS: + return v4l2_subdev_g_ext_ctrls(sd, arg); + + case VIDIOC_S_EXT_CTRLS: + return v4l2_subdev_s_ext_ctrls(sd, arg); + + case VIDIOC_TRY_EXT_CTRLS: + return v4l2_subdev_try_ext_ctrls(sd, arg); + default: return -ENOIOCTLCMD; } -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 2/7] v4l: subdev: Don't require core operations
There's no reason to require subdevices to implement the core operations. Remove the check for non-NULL core operations when initializing the subdev. Signed-off-by: Laurent Pinchart --- include/media/v4l2-subdev.h |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index b0316a7..b636444 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -466,8 +466,7 @@ static inline void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops *ops) { INIT_LIST_HEAD(&sd->list); - /* ops->core MUST be set */ - BUG_ON(!ops || !ops->core); + BUG_ON(!ops); sd->ops = ops; sd->v4l2_dev = NULL; sd->flags = 0; -- 1.7.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 0/7] V4L2 subdev userspace API
Hi everybody, Here's the fifth version of the V4L2 subdev userspace API patches. Nothing new under the sun, the patches have just been rebased on top of 2.6.37-rc6. You can find them as usual in http://git.linuxtv.org/pinchartl/media.git (media-0001-subdev-devnode branch). Laurent Pinchart (6): v4l: Share code between video_usercopy and video_ioctl2 v4l: subdev: Don't require core operations v4l: subdev: Merge v4l2_i2c_new_subdev_cfg and v4l2_i2c_new_subdev v4l: subdev: Add device node support v4l: subdev: Uninline the v4l2_subdev_init function v4l: subdev: Control ioctls support Sakari Ailus (1): v4l: subdev: Events support Documentation/video4linux/v4l2-framework.txt | 52 ++ drivers/media/radio/radio-si4713.c |2 +- drivers/media/video/Makefile |2 +- drivers/media/video/cafe_ccic.c | 11 +- drivers/media/video/davinci/vpfe_capture.c |2 +- drivers/media/video/davinci/vpif_capture.c |2 +- drivers/media/video/davinci/vpif_display.c |2 +- drivers/media/video/ivtv/ivtv-i2c.c | 11 +- drivers/media/video/s5p-fimc/fimc-capture.c |2 +- drivers/media/video/sh_vou.c |2 +- drivers/media/video/soc_camera.c |2 +- drivers/media/video/v4l2-common.c| 22 ++- drivers/media/video/v4l2-dev.c | 27 ++-- drivers/media/video/v4l2-device.c| 24 +++- drivers/media/video/v4l2-ioctl.c | 216 +- drivers/media/video/v4l2-subdev.c| 180 + include/media/v4l2-common.h | 18 +-- include/media/v4l2-dev.h | 18 ++- include/media/v4l2-ioctl.h |3 + include/media/v4l2-subdev.h | 41 +++-- 20 files changed, 423 insertions(+), 216 deletions(-) create mode 100644 drivers/media/video/v4l2-subdev.c -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v5 1/7] v4l: Share code between video_usercopy and video_ioctl2
The two functions are mostly identical. They handle the copy_from_user and copy_to_user operations related with V4L2 ioctls and call the real ioctl handler. Create a __video_usercopy function that implements the core of video_usercopy and video_ioctl2, and call that function from both. Signed-off-by: Laurent Pinchart --- drivers/media/video/v4l2-ioctl.c | 218 - 1 files changed, 71 insertions(+), 147 deletions(-) diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index dd9283f..1e01554 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -374,35 +374,62 @@ video_fix_command(unsigned int cmd) } #endif -/* - * Obsolete usercopy function - Should be removed soon - */ -long -video_usercopy(struct file *file, unsigned int cmd, unsigned long arg, +/* In some cases, only a few fields are used as input, i.e. when the app sets + * "index" and then the driver fills in the rest of the structure for the thing + * with that index. We only need to copy up the first non-input field. */ +static unsigned long cmd_input_size(unsigned int cmd) +{ + /* Size of structure up to and including 'field' */ +#define CMDINSIZE(cmd, type, field)\ + case VIDIOC_##cmd: \ + return offsetof(struct v4l2_##type, field) +\ + sizeof(((struct v4l2_##type *)0)->field); + + switch (cmd) { + CMDINSIZE(ENUM_FMT, fmtdesc,type); + CMDINSIZE(G_FMT,format, type); + CMDINSIZE(QUERYBUF, buffer, type); + CMDINSIZE(G_PARM, streamparm, type); + CMDINSIZE(ENUMSTD, standard, index); + CMDINSIZE(ENUMINPUT,input, index); + CMDINSIZE(G_CTRL, control,id); + CMDINSIZE(G_TUNER, tuner, index); + CMDINSIZE(QUERYCTRL,queryctrl, id); + CMDINSIZE(QUERYMENU,querymenu, index); + CMDINSIZE(ENUMOUTPUT, output, index); + CMDINSIZE(G_MODULATOR, modulator, index); + CMDINSIZE(G_FREQUENCY, frequency, tuner); + CMDINSIZE(CROPCAP, cropcap,type); + CMDINSIZE(G_CROP, crop, type); + CMDINSIZE(ENUMAUDIO,audio, index); + CMDINSIZE(ENUMAUDOUT, audioout, index); + CMDINSIZE(ENCODER_CMD, encoder_cmd,flags); + CMDINSIZE(TRY_ENCODER_CMD, encoder_cmd,flags); + CMDINSIZE(G_SLICED_VBI_CAP, sliced_vbi_cap, type); + CMDINSIZE(ENUM_FRAMESIZES, frmsizeenum,pixel_format); + CMDINSIZE(ENUM_FRAMEINTERVALS, frmivalenum,height); + default: + return _IOC_SIZE(cmd); + } +} + +static long +__video_usercopy(struct file *file, unsigned int cmd, unsigned long arg, v4l2_kioctl func) { charsbuf[128]; void*mbuf = NULL; - void*parg = NULL; + void*parg = (void *)arg; longerr = -EINVAL; int is_ext_ctrl; size_t ctrls_size = 0; void __user *user_ptr = NULL; -#ifdef __OLD_VIDIOC_ - cmd = video_fix_command(cmd); -#endif is_ext_ctrl = (cmd == VIDIOC_S_EXT_CTRLS || cmd == VIDIOC_G_EXT_CTRLS || cmd == VIDIOC_TRY_EXT_CTRLS); /* Copy arguments into temp kernel buffer */ - switch (_IOC_DIR(cmd)) { - case _IOC_NONE: - parg = NULL; - break; - case _IOC_READ: - case _IOC_WRITE: - case (_IOC_WRITE | _IOC_READ): + if (_IOC_DIR(cmd) != _IOC_NONE) { if (_IOC_SIZE(cmd) <= sizeof(sbuf)) { parg = sbuf; } else { @@ -414,11 +441,21 @@ video_usercopy(struct file *file, unsigned int cmd, unsigned long arg, } err = -EFAULT; - if (_IOC_DIR(cmd) & _IOC_WRITE) - if (copy_from_user(parg, (void __user *)arg, _IOC_SIZE(cmd))) + if (_IOC_DIR(cmd) & _IOC_WRITE) { + unsigned long n = cmd_input_size(cmd); + + if (copy_from_user(parg, (void __user *)arg, n)) goto out; - break; + + /* zero out anything we don't copy from userspace */ + if (n < _IOC_SIZE(cmd)) + memset((u8 *)parg + n, 0, _IOC_SIZE(cmd) - n); + } else { + /* read-only ioctl */ + memset(parg, 0
Re: [Query][videobuf-dma-sg] Pages in Highmem handling
Hi Sergio, Em 27-08-2010 11:57, Aguirre, Sergio escreveu: > Hi, > > I see that in current videobuf library, for DMA SG code, these functions fail > when > Detecting a page in Highmem region: > > - videobuf_pages_to_sg > - videobuf_vmalloc_to_sg > > Now, what's the real reason to not allow handling of Highmem pages? > Is it an assumption that _always_ HighMem is not reachable by DMA? > > I guess my point is, OMAP platform (and maybe other platforms) can handle > Highmem pages without any problem. I commented these validations: > > 65 static struct scatterlist *videobuf_vmalloc_to_sg(unsigned char *virt, > 66 int nr_pages) > 67 { > > ... > > 77 for (i = 0; i < nr_pages; i++, virt += PAGE_SIZE) { > 78 pg = vmalloc_to_page(virt); > 79 if (NULL == pg) > 80 goto err; > 81 /* BUG_ON(PageHighMem(pg)); */ > > ... > > 96 static struct scatterlist *videobuf_pages_to_sg(struct page **pages, > 97 int nr_pages, int offset) > 98 { > > ... > > 109 /* if (PageHighMem(pages[0])) */ > 110 /* DMA to highmem pages might not work */ > 111 /* goto highmem; */ > 112 sg_set_page(&sglist[0], pages[0], PAGE_SIZE - offset, offset); > 113 for (i = 1; i < nr_pages; i++) { > 114 if (NULL == pages[i]) > 115 goto nopage; > 116 /* if (PageHighMem(pages[i])) > 117 goto highmem; */ > 118 sg_set_page(&sglist[i], pages[i], PAGE_SIZE, 0); > 119 } > > Can somebody shed any light on this? Sorry for taking so long to answer you. Basically, videobuf code were written at Linux 2.4 days, to be used by bttv driver (and later used by cx88 and saa7134). At that time, there where a hack for the usage of highmem (I think it was called bigmem or something like that). As I was not maintaining the code on that time, I'm not really sure what where the issues, but I suspect that this were an arch-implementation limit related to DMA transfers at highmem, on that time, due to x86 intrinsic limits. I'm not sure about the current limits of newer x86 chips, on 32 and on 64 bits mode, but i think that this limit doesn't exist anymore. So, I suspect that just converting it to a call to dma_capable() should be enough to fix the issue. Yet, as videobuf2 is almost ready for merge, maybe the best is to take some efforts on testing it, and to be sure that it doesn't contain any arch-specific limits inside its code. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html