The NV16M description contained some copy-and-paste text from NV12M,
suggesting that this format is a 4:2:0 format when it really is a
4:2:2 format.
Fixed the text.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 9 -
1 file
Hi Hans,
Thank you for the patch.
On Sunday 02 March 2014 10:43:12 Hans Verkuil wrote:
The NV16M description contained some copy-and-paste text from NV12M,
suggesting that this format is a 4:2:0 format when it really is a
4:2:2 format.
Fixed the text.
Signed-off-by: Hans Verkuil
On 02/12/2014 11:08 AM, Paul Bolle wrote:
The Kconfig symbol S5P_SETUP_MIPIPHY was removed in v3.13. Remove a
reference to its macro from a list of Kconfig options.
Signed-off-by: Paul Bollepebo...@tiscali.nl
---
See commit e66f233dc7f7 (ARM: Samsung: Remove the MIPI PHY setup
code). Should one
Remove one quotation mark. This fixes DocBook documentation build.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Documentation/DocBook/media/v4l/controls.xml |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
Hi Mauro,
Here's the long overdue timestamp flag patchset. Buffers are stamped at
frame end now by default, and a new timestamp source buffer flag mask is
introduced. Some fixes to a few mem2mem drivers are also included.
Changes since the review: fix documentation build in io.xml in the last
Hi Mauro,
Here's a trivial fix for the DocBook build. Please pull.
The following changes since commit a06b429df49bb50ec1e671123a45147a1d1a6186:
[media] au0828: rework GPIO management for HVR-950q (2014-02-28 15:21:31
-0300)
are available in the git repository at:
Em Sat, 01 Mar 2014 07:57:42 -0300
Mauro Carvalho Chehab m.che...@samsung.com escreveu:
Hi Devin,
Em Fri, 28 Feb 2014 19:13:16 -0500
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:
Seems kind of strange that I wasn't on the CC for this, since I was the
original author of all
Am 27.02.2014 02:47, schrieb Keith Lawson:
On Mon, Feb 24, 2014 at 06:38:59PM +0100, Frank Schäfer wrote:
Am 06.02.2014 13:57, schrieb Keith Lawson:
On Mon, Jan 20, 2014 at 09:08:25PM +0100, Frank Schäfer wrote:
On 17.01.2014 01:11, Keith Lawson wrote:
On Wed, Jan 15, 2014 at 10:37:44PM
Am 01.03.2014 10:32, schrieb Jacob Korf:
Hi there,
I'm trying this video capture stick from Conceptronic, the Home Video
Creator, but I'm not getting it to work with Linux. I'm using kernel
version 3.13.5 and I'm on Arch Linux. More information and specs here:
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Mon Mar 3 04:00:26 CET 2014
git branch: test
git hash: a06b429df49bb50ec1e671123a45147a1d1a6186
gcc
On Sat, Mar 1, 2014 at 2:41 AM, Hans Verkuil hverk...@xs4all.nl wrote:
From: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
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
On Sat, Mar 1, 2014 at 2:42 AM, Hans Verkuil hverk...@xs4all.nl wrote:
Fix an incorrect test in vb2_internal_qbuf() where only DEQUEUED buffers
are allowed. But PREPARED buffers are also OK.
Introduced by commit 4138111a27859dcc56a5592c804dd16bb12a23d1
(vb2: simplify qbuf/prepare_buf by
No idea what's going wrong here, but this dmesg output is definitely
incomplete.
Or maybe you modifed the driver and messed things up ? ;-)
My guess is that it's not actually an em28xx device at all (and the
doc the user is referring to refers to some device by the manufacturer
with the same
On Fri, Feb 28, 2014 at 06:42:04PM +0100, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
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,
On Fri, Feb 28, 2014 at 06:42:10PM +0100, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
If __reqbufs was called then existing buffers are freed. However, if that
happens without ever having started STREAMON, but if buffers have been queued,
then the buf_finish op is never
On Mon, Mar 03, 2014 at 08:28:05AM +0200, Sakari Ailus wrote:
On Fri, Feb 28, 2014 at 06:42:04PM +0100, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
If a queue was canceled, then the buf_finish op was never called for the
pending buffers. So add this call to
On Fri, Feb 28, 2014 at 06:42:11PM +0100, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
No need to oops for this, WARN_ON is good enough.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
I agree; BUG() is better for something that's always (or almost so)
executed.
On Fri, Feb 28, 2014 at 06:42:13PM +0100, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Don't call buf_finish unless we know that the buffer is in a valid state.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
--
The video_device struct is currently embedded in the driver data struct vpe_dev.
A vpe_dev instance is allocated by the driver, and the memory for the vfd is a
part of this struct.
The v4l2 core, however, manages the removal of the vfd region, through the
video_device's .release() op, which
VPE has a ctrl parameter which decides how many mem to mem transactions the
active job from the job queue can perform.
The driver's job_ready() made sure that the number of ready source buffers are
sufficient for the job to execute successfully. But it didn't make sure if
there are sufficient
For OMAP and DRA7x, we generally allocate video and graphics buffers through
omapdrm since the corresponding omap-gem driver provides DMM-Tiler backed
contiguous buffers. omapdrm is a dma-buf exporter. These buffers are used by
other drivers in the video pipeline.
Add VB2_DMABUF flag to the
The minimum width and height for VPE input/output was kept as 128 pixels. VPE
doesn't have a constraint on the image height, it requires the image width to
be atleast 16 bytes.
Change the minimum supported dimensions to 32x32. This allows us to de-interlace
qcif content. A smaller image size than
Some parameters of the VPE descriptors were understood incorrectly. They are now
fixed. The fixes are explained as follows:
- When adding an inbound data descriptor to the VPDMA descriptor list, we intend
to use c_rect as the cropped region fetched by VPDMA. Therefore, c_rect-width
shouldn't
vpe fops(vpe_open in particular) should be called only when VPDMA firmware
is loaded. File operations on the video device are possible the moment it is
registered.
Currently, we register the video device for VPE at driver probe, after calling
a vpdma helper to initialize VPDMA and load firmware.
Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or
the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.
For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
whole image itself, hence making crop dimensions same as the pix dimensions.
Setting
This patch set mainly consists of minor fixes for the VPE driver. These fixes
ensure the following:
- The VPE module can be inserted and removed successively.
- Make sure that smaller resolutions like qcif work correctly.
- Prevent race condition between firmware loading and an open call to the
Hi Archit!
On 03/03/2014 08:33 AM, Archit Taneja wrote:
Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE,
or
the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.
For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
whole image itself,
27 matches
Mail list logo
