- 11 Mar, 2014 8 commits
-
-
Hans Verkuil authored
If a queue was canceled, then the buf_finish op was never called for the pending buffers. So add this call to queue_cancel. Before calling buf_finish set the buffer state to PREPARED, which is the correct state. That way the states DONE and ERROR will only be seen in buf_finish if streaming is in progress. Since buf_finish can now be called from non-streaming state we need to adapt the handful of drivers that actually need to know this. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com>
-
Hans Verkuil authored
There is no point in trying to decompress a captured frame unless the buffer state is OK. It won't be used in any other state, and in fact the contents of the buffer might well be corrupt. Signed-off-by:
-
Hans Verkuil authored
The buf_finish op should always work, so change the return type to void. Update the few drivers that use it. Signed-off-by:
Pawel Osciak <pawel@osciak.com> Reviewed-by:
-
Hans Verkuil authored
When a vb2_queue is freed check if all the mem_ops and queue ops were balanced. So the number of calls to e.g. buf_finish has to match the number of calls to buf_prepare, etc. This code is only enabled if CONFIG_VIDEO_ADV_DEBUG is set. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
Fix an incorrect test in vb2_internal_qbuf() where only DEQUEUED buffers are allowed. But PREPARED buffers are also OK. Introduced by commit 4138111a ("vb2: simplify qbuf/prepare_buf by removing callback"). Signed-off-by:
-
Hans Verkuil authored
Commit 88e26870 ("vb2: Improve file I/O emulation to handle buffers in any order") broke read/write support if the size of the buffer being read/written is less than the size of the image. When the commit was tested originally I used qv4l2, which calls read() with exactly the size of the image. But if you try 'cat /dev/video0' then it will fail and typically hang after reading two buffers. This patch fixes the behavior by adding a new cur_index field that contains the index of the field currently being filled/read, or it is num_buffers in which case a new buffer needs to be dequeued. The old index field has been renamed to initial_index in order to be a bit more descriptive. This has been tested with both read and write. Signed-off-by:
-
Ricardo Ribalda Delgado authored
This patch adds a test preventing streamon() if there is no buffer ready. Without this patch, a user could call streamon() before preparing any buffer. This leads to a situation where if he calls close() before calling streamoff() the device is kept streaming. Signed-off-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Linux 3.14-rc5 * tag 'v3.14-rc5': (1117 commits) Linux 3.14-rc5 drm/vmwgfx: avoid null pointer dereference at failure paths drm/vmwgfx: Make sure backing mobs are cleared when allocated. Update driver date. drm/vmwgfx: Remove some unused surface formats MAINTAINERS: add maintainer entry for Armada DRM driver arm64: Fix !CONFIG_SMP kernel build arm64: mm: Add double logical invert to pte accessors dm cache: fix truncation bug when mapping I/O to >2TB fast device perf tools: Fix strict alias issue for find_first_bit powerpc/powernv: Fix indirect XSCOM unmangling powerpc/powernv: Fix opal_xscom_{read,write} prototype powerpc/powernv: Refactor PHB diag-data dump powerpc/powernv: Dump PHB diag-data immediately powerpc: Increase stack redzone for 64-bit userspace to 512 bytes powerpc/ftrace: bugfix for test_24bit_addr powerpc/crashdump : Fix page frame number check in copy_oldmem_page powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly kvm, vmx: Really fix lazy FPU on nested guest perf tools: fix BFD detection on opensuse drm/radeon: enable speaker allocation setup on dce3.2 ...
-
- 05 Mar, 2014 32 commits
-
-
Peter Meerwald authored
Use the correct name in the comment describing function omap3isp_module_sync_is_stopping(). isp_isr() never returned IRQ_NONE, remove the comment saying so. Signed-off-by:
Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by:
-
Lad, Prabhakar authored
This patch renames the variable in the description to match it appropriately to function definition. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Lad, Prabhakar authored
This patch removes the description of members which does not exists for ispccdc_lsc structure. Signed-off-by:
-
Lad, Prabhakar authored
Signed-off-by:
-
Edgar Thier authored
Add bayer 8-bit GUIDs to uvcvideo and associated them with the corresponding V4L2 pixel formats. Signed-off-by:
Edgar Thier <info@edgarthier.net> Signed-off-by:
-
Oleksij Rempel authored
The UVC specification uses alternate setting selection to notify devices of stream start/stop. This breaks when using bulk-based devices, as the video streaming interface has a single alternate setting in that case, making video stream start and video stream stop events to appear identical to the device. Bulk-based devices are thus not well supported by UVC. The webcam built in the Asus Zenbook UX302LA ignores the set interface request and will keep the video stream enabled when the driver tries to stop it. If USB autosuspend is enabled the device will then be suspended and will crash, requiring a cold reboot. USB trace capture showed that Windows sends a CLEAR_FEATURE(HALT) request to the bulk endpoint when stopping the stream instead of selecting alternate setting 0. The camera then behaves correctly, and thus seems to require that behaviour. Replace selection of alternate setting 0 with clearing of the endpoint halt feature at video stream stop for bulk-based devices. Let's refrain from blaming Microsoft this time, as it's not clear whether this Windows-specific but USB-compliant behaviour was specifically developed to handle bulkd-based UVC devices, or if the camera just took advantage of it. CC: stable@vger.kernel.org Signed-off-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
-
Sakari Ailus authored
Timestamp buffer flags are constant at the moment. Document them so that 1) they're always valid and 2) not changed by the drivers. This leaves room to extend the functionality later on if needed. Signed-off-by:
Sakari Ailus <sakari.ailus@iki.fi> Acked-by:
-
Sakari Ailus authored
Copy the flags containing the timestamp source from source buffer flags to the destination buffer flags on memory-to-memory devices. This is analogous to copying the timestamp field from source to destination. Signed-off-by:
Kamil Debski <k.debski@samsung.com> Signed-off-by:
-
Sakari Ailus authored
The timestamp and timecode fields were copied from destination to source, not the other way around as they should. Fix it. Signed-off-by:
-
Sakari Ailus authored
The UVC device provided timestamps are taken from the clock once the exposure of the frame has begun, not when the reception of the frame would have been finished as almost anywhere else. Show this to the user space by using V4L2_BUF_FLAG_TSTAMP_SRC_SOE buffer flag. Signed-off-by:
-
Sakari Ailus authored
For COPY timestamps, buffer timestamp source flags will traverse the queue untouched. Signed-off-by:
-
Sakari Ailus authored
Some devices do not produce timestamps that correspond to the end of the frame. The user space should be informed on the matter. This patch achieves that by adding buffer flags (and a mask) for timestamp sources since more possible timestamping points are expected than just two. A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of the eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end of frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure (next value). Signed-off-by:
-
Sakari Ailus authored
Mask out other bits when comparing timestamp types. Signed-off-by:
-
Sakari Ailus authored
The timestamp_type field used to contain only the timestamp type. Soon it will be used for timestamp source flags as well. Rename the field accordingly. [m.chehab@samsung.com: do the change also to drivers/staging/media and at s2255] Signed-off-by:
-
Sakari Ailus authored
The buffer flags field is 32 bits but the defined only used 16. This is fine, but as more than 16 bits will be used in the very near future, define them as 32-bit numbers for consistency. Signed-off-by:
-
Sakari Ailus authored
Document that monotonic timestamps are taken after the corresponding frame has been received, not when the reception has begun. This corresponds to the reality of current drivers: the timestamp is naturally taken when the hardware triggers an interrupt to tell the driver to handle the received frame. Remove the note on timestamp accuracy as it is fairly subjective what is actually an unstable timestamp. Also remove explanation that output buffer timestamps can be used to delay outputting a frame. Remove the footnote saying we always use realtime clock. Signed-off-by:
-
Hans Verkuil authored
When sending a buffer to a video output device some of the fields need to be copied so they arrive in the driver. These are the KEY/P/BFRAME flags and the TIMECODE flag, and, if that flag is set, the timecode field itself. There are a number of functions involved in this: the __fill_vb2_buffer() is called while preparing a buffer. For output buffers the buffer contains the video data, so any meta data associated with that (KEY/P/BFRAME and the field information) should be stored at that point. The timecode, timecode flag and timestamp information is not part of that, that information will have to be set when vb2_internal_qbuf() is called to actually queue the buffer to the driver. Usually VIDIOC_QBUF will do the prepare as well, but you can call PREPARE_BUF first and only later VIDIOC_QBUF. You most likely will want to set the timestamp and timecode when you actually queue the buffer, not when you prepare it. Finally, in buf_prepare() make sure the timestamp and sequence fields are actually cleared so that when you do a QUERYBUF of a prepared-but-not-yet-queued buffer you will not see stale timestamp/sequence data. Signed-off-by:
-
Antti Palosaari authored
Modern silicon RF tuners used nowadays has many controllable gain stages on signal path. Usually, but not always, there is at least 3 gain stages. Also on some cases there could be multiple gain stages within the ones specified here. However, I think that having these three controllable gain stages offers enough fine-tuning for real use cases. 1) LNA gain. That is first gain just after antenna input. 2) Mixer gain. It is located quite middle of the signal path, where RF signal is down-converted to IF/BB. 3) IF gain. That is last gain in order to adjust output signal level to optimal level for receiving party (usually demodulator ADC). Each gain stage could be set rather often both manual or automatic (AGC) mode. Due to that add separate controls for controlling operation mode. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Antti Palosaari authored
Add documentation for LNA, mixer and IF gain controls. These controls are RF tuner specific. Signed-off-by:
-
Antti Palosaari authored
It is class for RF tuner specific controls, like gain controls, filters, signal strength. Cc: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Antti Palosaari authored
Delay possible I2C gate close a little bit in order to see if there is next message coming to tuner in a sequence. Also, export private muxed I2C adapter. That is aimed only for SDR extension module as SDR belongs to same RTL2832 physical I2C bus (it is physically property of RTL2832, whilst it is own kernel module). Signed-off-by:
-
Luis Alves authored
Signed-off-by:
Luis Alves <ljalvs@gmail.com> Signed-off-by:
-
Antti Palosaari authored
There was a deadlock between master I2C adapter and muxed I2C adapter. Implement two I2C muxed I2C adapters and leave master alone, just only for offering I2C adapter for these mux adapters. Reported-by:
Benjamin Larsson <benjamin@southpole.se> Signed-off-by:
-
Antti Palosaari authored
RTL2832 provides gated / repeater I2C adapter for tuner. Implement it as a muxed I2C adapter. Signed-off-by:
-
Antti Palosaari authored
Most of those were reported by checkpatch.pl... debug module parameter is not used anywhere so remove it. Signed-off-by:
-
Antti Palosaari authored
All used tuners has get_if_frequency() callback and that parameter is not needed and will not needed as all upcoming tuner drivers should implement get_if_frequency(). Signed-off-by:
-
Antti Palosaari authored
Disable IR interrupts in order to avoid SDR sample loss. IR interrupts causes some extra load for device and it seems be one reason to loss samples when sampling rate is high. Signed-off-by:
-
Antti Palosaari authored
There is now new tuner types which are not handled on that switch-case. Print error if unknown tuner type is meet. drivers/media/tuners/tuner-xc2028.c: In function ‘generic_set_freq’: drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value ‘V4L2_TUNER_ADC’ not handled in switch [-Wswitch] switch (new_type) { ^ drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value ‘V4L2_TUNER_RF’ not handled in switch [-Wswitch] Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by: -
Mauro Carvalho Chehab authored
Some previous patch introduced this bug: /devel/v4l/patchwork/Documentation/DocBook/controls.xml:2262: parser error : attributes construct error <row id=""v4l2-mpeg-video-hor-search-range"> ^ /devel/v4l/patchwork/Documentation/DocBook/controls.xml:2262: parser error : Couldn't find end of Start Tag row line 2262 <row id=""v4l2-mpeg-video-hor-search-range"> ^ Signed-off-by: -
Mauro Carvalho Chehab authored
Add SDR to V3.15 revlist, and add the credits to Antti. Signed-off-by: -
Antti Palosaari authored
Add SDR device type to v4l2-framework.txt document. Cc: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Antti Palosaari authored
Let it be experimental still as all SDR drivers are in staging. Cc: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
