Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab: - some V4L2 API updates needed by embedded devices - DVB API extensions for ATSC-MH delivery system, used in US for mobile TV - new tuners for fc0011/0012/0013 and tua9001 - a new dvb driver for af9033/9035 - a new ATSC-MH frontend (lg2160) - new remote controller keymaps - Removal of a few legacy webcam driver that got replaced by gspca on several kernel versions ago - a new driver for Exynos 4/5 webcams(s5pp fimc-lite) - a new webcam sensor driver (smiapp) - a new video input driver for embedded (sta2x1xx) - several improvements, fixes, cleanups, etc inside the drivers. Manually fix up conflicts due to err() -> dev_err() conversion in drivers/staging/media/easycap/easycap_main.c * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (484 commits) [media] saa7134-cards: Remove a PCI entry added by mistake [media] radio-sf16fmi: add support for SF16-FMD [media] rc-loopback: remove duplicate line [media] patch for Asus My Cinema PS3-100 (1043:48cd) [media] au0828: Move the Kconfig knob under V4L_USB_DRIVERS [media] em28xx: simple comment fix [media] [resend] radio-sf16fmr2: add PnP support for SF16-FMD2 [media] smiapp: Use v4l2_ctrl_new_int_menu() instead of v4l2_ctrl_new_custom() [media] smiapp: Add support for 8-bit uncompressed formats [media] smiapp: Allow generic quirk registers [media] smiapp: Use non-binning limits if the binning limit is zero [media] smiapp: Initialise rval in smiapp_read_nvm() [media] smiapp: Round minimum pre_pll up rather than down in ip_clk_freq check [media] smiapp: Use 8-bit reads only before identifying the sensor [media] smiapp: Quirk for sensors that only do 8-bit reads [media] smiapp: Pass struct sensor to register writing commands instead of i2c_client [media] smiapp: Allow using external clock from the clock framework [media] zl10353: change .read_snr() to report SNR as a 0.1 dB [media] media: add support to gspca/pac7302.c for 093a:2627 (Genius FaceCam 300) [media] m88rs2000 - only flip bit 2 on reg 0x70 on 16th try ...
This commit is contained in:
Linus Torvalds
commit
ab11ca34ee
463 changed files with 39311 additions and 16893 deletions
32
Documentation/video4linux/4CCs.txt
Normal file
32
Documentation/video4linux/4CCs.txt
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
Guidelines for Linux4Linux pixel format 4CCs
|
||||
============================================
|
||||
|
||||
Guidelines for Video4Linux 4CC codes defined using v4l2_fourcc() are
|
||||
specified in this document. First of the characters defines the nature of
|
||||
the pixel format, compression and colour space. The interpretation of the
|
||||
other three characters depends on the first one.
|
||||
|
||||
Existing 4CCs may not obey these guidelines.
|
||||
|
||||
Formats
|
||||
=======
|
||||
|
||||
Raw bayer
|
||||
---------
|
||||
|
||||
The following first characters are used by raw bayer formats:
|
||||
|
||||
B: raw bayer, uncompressed
|
||||
b: raw bayer, DPCM compressed
|
||||
a: A-law compressed
|
||||
u: u-law compressed
|
||||
|
||||
2nd character: pixel order
|
||||
B: BGGR
|
||||
G: GBRG
|
||||
g: GRBG
|
||||
R: RGGB
|
||||
|
||||
3rd character: uncompressed bits-per-pixel 0--9, A--
|
||||
|
||||
4th character: compressed bits-per-pixel 0--9, A--
|
||||
|
|
@ -276,6 +276,7 @@ pac7302 093a:2622 Genius Eye 312
|
|||
pac7302 093a:2624 PAC7302
|
||||
pac7302 093a:2625 Genius iSlim 310
|
||||
pac7302 093a:2626 Labtec 2200
|
||||
pac7302 093a:2627 Genius FaceCam 300
|
||||
pac7302 093a:2628 Genius iLook 300
|
||||
pac7302 093a:2629 Genious iSlim 300
|
||||
pac7302 093a:262a Webcam 300k
|
||||
|
|
|
|||
|
|
@ -130,8 +130,18 @@ Menu controls are added by calling v4l2_ctrl_new_std_menu:
|
|||
const struct v4l2_ctrl_ops *ops,
|
||||
u32 id, s32 max, s32 skip_mask, s32 def);
|
||||
|
||||
Or alternatively for integer menu controls, by calling v4l2_ctrl_new_int_menu:
|
||||
|
||||
struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl,
|
||||
const struct v4l2_ctrl_ops *ops,
|
||||
u32 id, s32 max, s32 def, const s64 *qmenu_int);
|
||||
|
||||
These functions are typically called right after the v4l2_ctrl_handler_init:
|
||||
|
||||
static const s64 exp_bias_qmenu[] = {
|
||||
-2, -1, 0, 1, 2
|
||||
};
|
||||
|
||||
v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
|
||||
v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops,
|
||||
V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
|
||||
|
|
@ -141,6 +151,11 @@ These functions are typically called right after the v4l2_ctrl_handler_init:
|
|||
V4L2_CID_POWER_LINE_FREQUENCY,
|
||||
V4L2_CID_POWER_LINE_FREQUENCY_60HZ, 0,
|
||||
V4L2_CID_POWER_LINE_FREQUENCY_DISABLED);
|
||||
v4l2_ctrl_new_int_menu(&foo->ctrl_handler, &foo_ctrl_ops,
|
||||
V4L2_CID_EXPOSURE_BIAS,
|
||||
ARRAY_SIZE(exp_bias_qmenu) - 1,
|
||||
ARRAY_SIZE(exp_bias_qmenu) / 2 - 1,
|
||||
exp_bias_qmenu);
|
||||
...
|
||||
if (foo->ctrl_handler.error) {
|
||||
int err = foo->ctrl_handler.error;
|
||||
|
|
@ -164,6 +179,12 @@ controls. There is no min argument since that is always 0 for menu controls,
|
|||
and instead of a step there is a skip_mask argument: if bit X is 1, then menu
|
||||
item X is skipped.
|
||||
|
||||
The v4l2_ctrl_new_int_menu function creates a new standard integer menu
|
||||
control with driver-specific items in the menu. It differs from
|
||||
v4l2_ctrl_new_std_menu in that it doesn't have the mask argument and takes
|
||||
as the last argument an array of signed 64-bit integers that form an exact
|
||||
menu item list.
|
||||
|
||||
Note that if something fails, the function will return NULL or an error and
|
||||
set ctrl_handler->error to the error code. If ctrl_handler->error was already
|
||||
set, then it will just return and do nothing. This is also true for
|
||||
|
|
|
|||
|
|
@ -182,11 +182,11 @@ static int __devinit drv_probe(struct pci_dev *pdev,
|
|||
}
|
||||
|
||||
If you have multiple device nodes then it can be difficult to know when it is
|
||||
safe to unregister v4l2_device. For this purpose v4l2_device has refcounting
|
||||
support. The refcount is increased whenever video_register_device is called and
|
||||
it is decreased whenever that device node is released. When the refcount reaches
|
||||
zero, then the v4l2_device release() callback is called. You can do your final
|
||||
cleanup there.
|
||||
safe to unregister v4l2_device for hotpluggable devices. For this purpose
|
||||
v4l2_device has refcounting support. The refcount is increased whenever
|
||||
video_register_device is called and it is decreased whenever that device node
|
||||
is released. When the refcount reaches zero, then the v4l2_device release()
|
||||
callback is called. You can do your final cleanup there.
|
||||
|
||||
If other device nodes (e.g. ALSA) are created, then you can increase and
|
||||
decrease the refcount manually as well by calling:
|
||||
|
|
@ -197,6 +197,10 @@ or:
|
|||
|
||||
int v4l2_device_put(struct v4l2_device *v4l2_dev);
|
||||
|
||||
Since the initial refcount is 1 you also need to call v4l2_device_put in the
|
||||
disconnect() callback (for USB devices) or in the remove() callback (for e.g.
|
||||
PCI devices), otherwise the refcount will never reach 0.
|
||||
|
||||
struct v4l2_subdev
|
||||
------------------
|
||||
|
||||
|
|
@ -262,11 +266,16 @@ struct v4l2_subdev_video_ops {
|
|||
...
|
||||
};
|
||||
|
||||
struct v4l2_subdev_pad_ops {
|
||||
...
|
||||
};
|
||||
|
||||
struct v4l2_subdev_ops {
|
||||
const struct v4l2_subdev_core_ops *core;
|
||||
const struct v4l2_subdev_tuner_ops *tuner;
|
||||
const struct v4l2_subdev_audio_ops *audio;
|
||||
const struct v4l2_subdev_video_ops *video;
|
||||
const struct v4l2_subdev_pad_ops *video;
|
||||
};
|
||||
|
||||
The core ops are common to all subdevs, the other categories are implemented
|
||||
|
|
@ -303,6 +312,22 @@ Don't forget to cleanup the media entity before the sub-device is destroyed:
|
|||
|
||||
media_entity_cleanup(&sd->entity);
|
||||
|
||||
If the subdev driver intends to process video and integrate with the media
|
||||
framework, it must implement format related functionality using
|
||||
v4l2_subdev_pad_ops instead of v4l2_subdev_video_ops.
|
||||
|
||||
In that case, the subdev driver may set the link_validate field to provide
|
||||
its own link validation function. The link validation function is called for
|
||||
every link in the pipeline where both of the ends of the links are V4L2
|
||||
sub-devices. The driver is still responsible for validating the correctness
|
||||
of the format configuration between sub-devices and video nodes.
|
||||
|
||||
If link_validate op is not set, the default function
|
||||
v4l2_subdev_link_validate_default() is used instead. This function ensures
|
||||
that width, height and the media bus pixel code are equal on both source and
|
||||
sink of the link. Subdev drivers are also free to use this function to
|
||||
perform the checks mentioned above in addition to their own checks.
|
||||
|
||||
A device (bridge) driver needs to register the v4l2_subdev with the
|
||||
v4l2_device:
|
||||
|
||||
|
|
@ -555,19 +580,25 @@ allocated memory.
|
|||
You should also set these fields:
|
||||
|
||||
- v4l2_dev: set to the v4l2_device parent device.
|
||||
|
||||
- name: set to something descriptive and unique.
|
||||
|
||||
- fops: set to the v4l2_file_operations struct.
|
||||
|
||||
- ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance
|
||||
(highly recommended to use this and it might become compulsory in the
|
||||
future!), then set this to your v4l2_ioctl_ops struct.
|
||||
|
||||
- lock: leave to NULL if you want to do all the locking in the driver.
|
||||
Otherwise you give it a pointer to a struct mutex_lock and before any
|
||||
of the v4l2_file_operations is called this lock will be taken by the
|
||||
core and released afterwards.
|
||||
Otherwise you give it a pointer to a struct mutex_lock and before the
|
||||
unlocked_ioctl file operation is called this lock will be taken by the
|
||||
core and released afterwards. See the next section for more details.
|
||||
|
||||
- prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY.
|
||||
If left to NULL, then it will use the struct v4l2_prio_state in v4l2_device.
|
||||
If you want to have a separate priority state per (group of) device node(s),
|
||||
then you can point it to your own struct v4l2_prio_state.
|
||||
|
||||
- parent: you only set this if v4l2_device was registered with NULL as
|
||||
the parent device struct. This only happens in cases where one hardware
|
||||
device has multiple PCI devices that all share the same v4l2_device core.
|
||||
|
|
@ -577,6 +608,7 @@ You should also set these fields:
|
|||
(cx8802). Since the v4l2_device cannot be associated with a particular
|
||||
PCI device it is setup without a parent device. But when the struct
|
||||
video_device is setup you do know which parent PCI device to use.
|
||||
|
||||
- flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework
|
||||
handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct
|
||||
v4l2_fh. Eventually this flag will disappear once all drivers use the core
|
||||
|
|
@ -587,6 +619,16 @@ in your v4l2_file_operations struct.
|
|||
|
||||
Do not use .ioctl! This is deprecated and will go away in the future.
|
||||
|
||||
In some cases you want to tell the core that a function you had specified in
|
||||
your v4l2_ioctl_ops should be ignored. You can mark such ioctls by calling this
|
||||
function before video_device_register is called:
|
||||
|
||||
void v4l2_disable_ioctl(struct video_device *vdev, unsigned int cmd);
|
||||
|
||||
This tends to be needed if based on external factors (e.g. which card is
|
||||
being used) you want to turns off certain features in v4l2_ioctl_ops without
|
||||
having to make a new struct.
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -609,8 +651,22 @@ 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.
|
||||
will be either a top-level mutex or a mutex per device node. By default this
|
||||
lock will be used for unlocked_ioctl, but you can disable locking for
|
||||
selected ioctls by calling:
|
||||
|
||||
void v4l2_disable_ioctl_locking(struct video_device *vdev, unsigned int cmd);
|
||||
|
||||
E.g.: v4l2_disable_ioctl_locking(vdev, VIDIOC_DQBUF);
|
||||
|
||||
You have to call this before you register the video_device.
|
||||
|
||||
Particularly with USB drivers where certain commands such as setting controls
|
||||
can take a long time you may want to do your own locking for the buffer queuing
|
||||
ioctls.
|
||||
|
||||
If you want still finer-grained locking then you have to set mutex_lock to NULL
|
||||
and do you own locking completely.
|
||||
|
||||
It is up to the driver developer to decide which method to use. However, if
|
||||
your driver has high-latency operations (for example, changing the exposure
|
||||
|
|
@ -618,7 +674,7 @@ of a USB webcam might take a long time), then you might be better off with
|
|||
doing your own locking if you want to allow the user to do other things with
|
||||
the device while waiting for the high-latency command to finish.
|
||||
|
||||
If a lock is specified then all file operations will be serialized on that
|
||||
If a lock is specified then all ioctl commands 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
|
||||
|
|
@ -941,21 +997,35 @@ fast.
|
|||
|
||||
Useful functions:
|
||||
|
||||
- v4l2_event_queue()
|
||||
void v4l2_event_queue(struct video_device *vdev, const struct v4l2_event *ev)
|
||||
|
||||
Queue events to video device. The driver's only responsibility is to fill
|
||||
in the type and the data fields. The other fields will be filled in by
|
||||
V4L2.
|
||||
|
||||
- v4l2_event_subscribe()
|
||||
int v4l2_event_subscribe(struct v4l2_fh *fh,
|
||||
struct v4l2_event_subscription *sub, unsigned elems,
|
||||
const struct v4l2_subscribed_event_ops *ops)
|
||||
|
||||
The video_device->ioctl_ops->vidioc_subscribe_event must check the driver
|
||||
is able to produce events with specified event id. Then it calls
|
||||
v4l2_event_subscribe() to subscribe the event. The last argument is the
|
||||
size of the event queue for this event. If it is 0, then the framework
|
||||
will fill in a default value (this depends on the event type).
|
||||
v4l2_event_subscribe() to subscribe the event.
|
||||
|
||||
- v4l2_event_unsubscribe()
|
||||
The elems argument is the size of the event queue for this event. If it is 0,
|
||||
then the framework will fill in a default value (this depends on the event
|
||||
type).
|
||||
|
||||
The ops argument allows the driver to specify a number of callbacks:
|
||||
* add: called when a new listener gets added (subscribing to the same
|
||||
event twice will only cause this callback to get called once)
|
||||
* del: called when a listener stops listening
|
||||
* replace: replace event 'old' with event 'new'.
|
||||
* merge: merge event 'old' into event 'new'.
|
||||
All 4 callbacks are optional, if you don't want to specify any callbacks
|
||||
the ops argument itself maybe NULL.
|
||||
|
||||
int v4l2_event_unsubscribe(struct v4l2_fh *fh,
|
||||
struct v4l2_event_subscription *sub)
|
||||
|
||||
vidioc_unsubscribe_event in struct v4l2_ioctl_ops. A driver may use
|
||||
v4l2_event_unsubscribe() directly unless it wants to be involved in
|
||||
|
|
@ -964,7 +1034,7 @@ Useful functions:
|
|||
The special type V4L2_EVENT_ALL may be used to unsubscribe all events. The
|
||||
drivers may want to handle this in a special way.
|
||||
|
||||
- v4l2_event_pending()
|
||||
int v4l2_event_pending(struct v4l2_fh *fh)
|
||||
|
||||
Returns the number of pending events. Useful when implementing poll.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue