Hi all,
I'm using an OMAP3530 board and a monochrome 12-bit grey sensor.
Can anyone enlighten me why is the 12-bit grey formats at the CCDC
input (Y12) is truncated to Y10 at the CCDC output?
I need to read the entire RAW 12-bit grey value from the CCDC to
memory and the data does not pass throu
On a 32bit system the multiplication here could overflow. p->count is
used in some of the V4L drivers.
Signed-off-by: Dan Carpenter
---
This is a patch against the 2.6.32-longterm kernel. In the stock
kernel, this code was totally rewritten and fixed in 2010 by d14e6d76ebf
"[media] v4l: Add mul
From: David Fries
dvb_register calls videobuf_dvb_register_bus, but if that returns
a failure the module will be unloaded without clearing the
value of core->gate_ctrl which will cause an oops in macros
called from video_open in cx88-video.c
Signed-off-by: David Fries
Cc: Mauro Carvalho Chehab
module_param_array(), unlike its non-array cousins, didn't check the type
of the variable. Fixing this found two bugs.
Cc: Luca Risolia
Cc: Mauro Carvalho Chehab
Cc: Eric Piel
Cc: linux-media@vger.kernel.org
Signed-off-by: Rusty Russell
---
drivers/media/video/et61x251/et61x251_core.c |4
Mauro,
Please PULL that new driver to the Kernel 3.3!
Antti
The following changes since commit 6dbc13e364ad49deb9dd93c4ab84af53ffb52435:
mxl5007t: implement .get_if_frequency() (2011-10-10 00:57:07 +0300)
are available in the git repository at:
git://linuxtv.org/anttip/media_tree.git hdic
Hi Martin,
On Wed, Dec 14, 2011 at 07:58:45PM +0100, mar...@neutronstar.dyndns.org wrote:
...
> > > > > +static int mt9m032_setup_pll(struct mt9m032 *sensor)
> > > > > +{
> > > > > + struct mt9m032_platform_data* pdata = sensor->pdata;
> > > > > + u16 reg_pll1;
> > > > > + unsigned int
Hi Sylwester,
On Sat, Dec 10, 2011 at 02:55:19PM +0100, Sylwester Nawrocki wrote:
> Hi Sakari,
>
> On 12/05/2011 11:41 PM, Sakari Ailus wrote:
> > On Mon, Dec 05, 2011 at 08:56:46PM +0100, Sylwester Nawrocki wrote:
> >> The V4L2_CID_FLASH_HW_STROBE_MODE mode control is intended
> >> for devices t
On Wed, 14 Dec 2011, Marek Vasut wrote:
> Dear Martin Hostettler,
>
> > The MT9M032 is a parallel 1.6MP sensor from Micron controlled through I2C.
> >
> > The driver creates a V4L2 subdevice. It currently supports cropping, gain,
> > exposure and v/h flipping controls in monochrome mode with an
On Wed, 2011-12-14 at 06:13 +, Adeq wrote:
> Malcolm Priestley gmail.com> writes:
>
> >
> > Support for IT1935 9006 devices.
> >
> > 9006 have version 2 type chip.
> >
> > 9006 devices should use dvb-usb-it9135-02.fw firmware.
> >
> > On the device tested the tuner id was set to 0 which m
Hello,
I have Sabayon K 7 64bit and a Hauppauge 930C-HD.
I've cried for months that I can't make it work under linux.
I intend to watch dvb-c channels.
What should I do to make it work with the newly added support?
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-medi
On Wed, Dec 14, 2011 at 02:49:05PM +0100, Laurent Pinchart wrote:
> Hi Martin,
>
> On Wednesday 14 December 2011 08:14:01 mar...@neutronstar.dyndns.org wrote:
> > On Wed, Dec 14, 2011 at 02:55:31AM +0100, Marek Vasut wrote:
> > > > The MT9M032 is a parallel 1.6MP sensor from Micron controlled thro
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:Wed Dec 14 19:00:17 CET 2011
git hash:bcc072756e4467dc30e502a311b1c3adec96a0e4
gcc version: i686-linux-gcc (GCC
Malcolm Priestley gmail.com> writes:
>
> Support for IT1935 9006 devices.
>
> 9006 have version 2 type chip.
>
> 9006 devices should use dvb-usb-it9135-02.fw firmware.
>
> On the device tested the tuner id was set to 0 which meant
> the driver used tuner id 0x38. The device functioned normall
13.12.2011 22:56, Marko Ristola:
> Here is another patch that I wrote for my DVB HDTV network delivery glitches
> problem.
> It might help you a bit also:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=38e009aac9e02d2c30fd9a5e979ab31433e7d578
I started seeing glitches ag
On Wed, Dec 14, 2011 at 02:15:22PM +0100, Laurent Pinchart wrote:
> Hi Igor,
>
> On Wednesday 14 December 2011 10:31:35 Igor Grinberg wrote:
> > On 12/14/11 03:25, Martin Hostettler wrote:
> > > Adds board support for an MT9M032 based camera to omap3evm.
> > >
> > > Signed-off-by: Martin Hostettl
On Wed, Dec 14, 2011 at 11:31:35AM +0200, Igor Grinberg wrote:
> Hi Martin,
>
> On 12/14/11 03:25, Martin Hostettler wrote:
> > Adds board support for an MT9M032 based camera to omap3evm.
> >
> > Signed-off-by: Martin Hostettler
> > ---
> > arch/arm/mach-omap2/Makefile|3 +-
This patch uses channel 2 of the eMMa-PrP to convert
format provided by the sensor to YUV420.
This format is very useful since it is used by the
internal H.264 encoder.
Signed-off-by: Javier Martin
---
drivers/media/video/mx2_camera.c | 291 +++---
1 files chang
Hi,
On Wed, Dec 14, 2011 at 11:34 PM, Sakari Ailus wrote:
>> + case VIDIOC_G_FD_RESULT:
>> + {
>> + struct v4l2_fd_result *fr = arg;
>> +
>> + if (!ops->vidioc_g_fd_result)
>> + break;
>> +
>> + ret = ops->vidioc_g_fd_result(file, f
Hi Ming,
Thanks for the patchset.
(Dropped a lot of folks from cc --- I doubt Alan Cox or Greg
Kroah-Hartman have immediate interest towards this.)
On Fri, Dec 02, 2011 at 11:02:50PM +0800, Ming Lei wrote:
> This patch introduces two new IOCTLs and related data
> structure defination which will
Add image source control class. This control class is intended to contain
low level controls which deal with control of the image capture process ---
the A/D converter in image sensors, for example.
Signed-off-by: Sakari Ailus
---
Documentation/DocBook/media/v4l/controls.xml | 101 +++
Pixel clock is an essential part of the image data parameters. Add this.
Together, the current parameters also define the frame rate.
Sensors do not have a concept of frame rate; pixel clock is much more
meaningful in this context. Also, it is best to combine the pixel clock with
the other format
smiapp_pad_ops.validate_pipeline is intended to validate the full pipeline
which is implemented by the driver to which the subdev implementing this op
belongs to. The validate_pipeline op must also call validate_pipeline on
any external entity which is linked to its sink pads.
Signed-off-by: Sakar
Signed-off-by: Sakari Ailus
---
Documentation/DocBook/media/v4l/dev-subdev.xml | 95 +++--
Documentation/DocBook/media/v4l/v4l2.xml |1 +
.../media/v4l/vidioc-subdev-g-selection.xml| 226
3 files changed, 302 insertions(+), 20 deletions(-)
cr
Revert to s_selection if s_crop isn't implemented by a driver. Same for
g_selection / g_crop.
Signed-off-by: Sakari Ailus
---
drivers/media/video/v4l2-subdev.c | 37 +++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-s
Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.
Signed-of
Hi all,
This RFC discusses the SUBDEV_S_SELECTION/SUBDEV_G_SELECTION API which is
intended to amend and replace the existing SUBDEV_[SG]_CROP API. These
IOCTLs have previously been discussed in the Cambridge V4L2 brainstorming
meeting [0] and their intent is to provide more configurability for sub
On Wednesday, December 14, 2011 14:34:14 Sylwester Nawrocki wrote:
> Hi Hans,
>
> On 12/13/2011 01:18 PM, Hans Verkuil wrote:
> >> are you going to carry on with the control range update patches ?
> >> I'd like to push the alpha colour control for v3.3 but it depends
> >> on the controls framework
On Exynos SoCs the FIMC IP allows to configure globally the alpha
component of all pixels for V4L2_PIX_FMT_RGB32, V4L2_PIX_FMT_RGB555
and V4L2_PIX_FMT_RGB444 image formats. This patch adds a v4l2 control
in order to let the applications control the alpha component value.
The alpha value range depe
The V4L2_CID_ALPHA_COMPONENT control is intended for the video capture
or memory-to-memory devices that are capable of setting up the per-pixel
alpha component to some arbitrary value. It allows to set the alpha
component for all pixels to an arbitrary value.
Signed-off-by: Sylwester Nawrocki
Sig
Hello,
This changeset adds new V4L2_CID_ALPHA_COMPONENT control allowing to configure
an alpha component of all pixels on the video capture device or on capture
queue
of a mem-to-mem device. This is meant for devices that allow to set a per-pixel
alpha at the pipeline output to a desired value
The patch introduces one face detection device driver for
driving face detection hardware on omap4[1].
Most things of the driver are dealing with omap4 face detection
hardware.
This driver is platform independent, so in theory it can
be used to drive same IP module on other platforms.
[1], Ch9 o
This patch introduces object detection generic driver.
The driver is responsible for all v4l2 stuff, buffer management
and other general things, and doesn't touch object detection hardware
directly. Several interfaces are exported to low level drivers
(such as the coming omap4 FD driver) which wil
This patch introduces two new IOCTLs and related data
structure which will be used by the coming video device
with object detect capability.
The two IOCTLs and related data structure will be used by
user space application to retrieve the results of object
detection.
The utility fdif[1] is useing
This patch supports to handle 64/32 compatible array parameter,
such as below:
struct v4l2_fd_result {
__u32 buf_index;
__u32 face_cnt;
__u32 reserved[6];
struct v4l2_fd_detection fd[];
};
With this patch, the point
DMA contig memory resource is very limited and precious, also
accessing to it from CPU is very slow on some platform.
For some cases(such as the comming face detection driver), DMA Streaming
buffer is enough, so introduce VIDEOBUF2_PAGE to allocate continuous
physical memory but letting video devi
So that we can reuse vb2_mmap_pfn_range for the coming videobuf2_page
memops.
Signed-off-by: Ming Lei
---
drivers/media/video/videobuf2-dma-contig.c |1 +
drivers/media/video/videobuf2-memops.c |1 -
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v
Signed-off-by: Ming Lei
---
arch/arm/mach-omap2/devices.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1166bdc..bd7f9b3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b
Hi,
These v2 patches(against -next tree) introduce v4l2 based object
detection(OD) device driver, and enable face detection hardware[1]
on omap4 SoC.. The idea of implementing it on v4l2 is from from
Alan Cox, Sylwester and Greg-Kh.
For verification purpose, I write one user space utility[2] to
t
Signed-off-by: Ming Lei
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 81
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6cf21ee..30db754 100644
--- a/
Hi Martin,
On Wednesday 14 December 2011 08:14:01 mar...@neutronstar.dyndns.org wrote:
> On Wed, Dec 14, 2011 at 02:55:31AM +0100, Marek Vasut wrote:
> > > The MT9M032 is a parallel 1.6MP sensor from Micron controlled through
> > > I2C.
> > >
> > > The driver creates a V4L2 subdevice. It currentl
Hi Hans,
On 12/13/2011 01:18 PM, Hans Verkuil wrote:
>> are you going to carry on with the control range update patches ?
>> I'd like to push the alpha colour control for v3.3 but it depends
>> on the controls framework updates now.
>
> Good question. I am not sure whether this is something we ac
Hi Igor,
On Wednesday 14 December 2011 10:31:35 Igor Grinberg wrote:
> On 12/14/11 03:25, Martin Hostettler wrote:
> > Adds board support for an MT9M032 based camera to omap3evm.
> >
> > Signed-off-by: Martin Hostettler
[snip]
> > diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
> > b/
Update the sub-device drivers having a devnode enabled so they properly
handle the new framesamples field of struct v4l2_mbus_framefmt.
These drivers don't support compressed (entropy encoded) formats so the
framesamples field is simply initialized to 0, altogether with the
reserved field.
There i
The purpose of the new field is to allow the video pipeline elements
to negotiate memory buffer size for compressed data frames, where
the buffer size cannot be derived from pixel width and height and
the pixel code.
For VIDIOC_SUBDEV_S_FMT and VIDIOC_SUBDEV_G_FMT ioctls, the
framesamples paramete
Hello,
this is an updated version of the changeset extending struct v4l2_mbus_framefmt
with new framesamples field.
Changes since v1:
- Docbook documentation improvements
- drivers that are exposing a sub-device node are modified to initialize
the new struct v4l2_mbus_framefmt member to 0 if
From: Tomasz Stanislawski
Adjusting of Video Processor's scaling factors was flawed. It bounded scaling
to range 1/16 to 1/1. The correct range should be 1/4 to 4/1. This patch fixes
this bug.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
---
From: Tomasz Stanislawski
Pixels were preferred units for selection rectangles over driver-dependent
units for almost all use cases. Therefore the units were fixed to pixels.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
---
Documentation/Doc
Mantis and Hopper drivers: Fix CAM hangup problem,
where interrupt handler clears GPIF status, even though
GPIF interrupt isn't active.
Manuel reported that this patch fixes his problem:
http://www.spinics.net/lists/linux-media/msg41473.html
(CAM hangs up about once per 20 minutes, each hangup
Hi Martin,
On 12/14/11 03:25, Martin Hostettler wrote:
> Adds board support for an MT9M032 based camera to omap3evm.
>
> Signed-off-by: Martin Hostettler
> ---
> arch/arm/mach-omap2/Makefile|3 +-
> arch/arm/mach-omap2/board-omap3evm-camera.c | 155
> ++
49 matches
Mail list logo