On 26 September 2012 18:42, Jonathan Corbet cor...@lwn.net wrote:
On Wed, 26 Sep 2012 11:47:54 +0200
Javier Martin javier.mar...@vista-silicon.com wrote:
'min_height' and 'min_width' are variables that allow to specify the minimum
resolution that the sensor will achieve. This patch make v4l2
On 26 September 2012 18:50, Jonathan Corbet cor...@lwn.net wrote:
On Wed, 26 Sep 2012 11:47:55 +0200
Javier Martin javier.mar...@vista-silicon.com wrote:
According to the datasheet ov7675 uses a formula to achieve
the desired framerate that is different from the operations
done
On 26 September 2012 18:52, Jonathan Corbet cor...@lwn.net wrote:
On Wed, 26 Sep 2012 11:47:56 +0200
Javier Martin javier.mar...@vista-silicon.com wrote:
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
This one needs a changelog - what does bypassing the PLL do and why might
On 26 September 2012 18:52, Jonathan Corbet cor...@lwn.net wrote:
On Wed, 26 Sep 2012 11:47:57 +0200
Javier Martin javier.mar...@vista-silicon.com wrote:
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c |8
include/media/ov7670.h
The following series includes all the changes discussed in [1] that
don't affect either bridge drivers that use ov7670 or soc-camera framework
For this reason they are considered non controversial and sent separately.
At least 1 more series will follow in order to implement all features
described
ov7675 and ov7670 share the same registers but there is no way
to distinguish them at runtime. However, they require different
tweaks to achieve the desired resolution. For this reason this
patch adds a new ov7675 entry to the ov7670_id table.
Signed-off-by: Javier Martin javier.mar...@vista
will be used for ov7675 only.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Create separate functions for frame rate control.
---
drivers/media/i2c/ov7670.c | 136 ++--
1 file changed, 118 insertions(+), 18 deletions
'min_height' and 'min_width' are variables that allow to specify the minimum
resolution that the sensor will achieve. This patch make v4l2 fmt callbacks
consider this parameters in order to return valid data to user space.
Acked-by: Jonathan Corbet cor...@lwn.net
Signed-off-by: Javier Martin
-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Added changelog.
---
drivers/media/i2c/ov7670.c | 28 ++--
include/media/ov7670.h |1 +
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b
Some bridge drivers captures pixels during blanking periods if
pixclk is enabled. In order to avoid capturing bogus data we need to
disable pixclk in the sensor during those blanking periods.
Acked-by: Jonathan Corbet cor...@lwn.net
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
The following series migrate ov7670 sensor and current users to ctrl framework
as discussed in [1]. This has been tested against mx2_camera soc-camera bridge,
so tests or acks will be required from people using cam-core and via-camera out
there.
This will have to be applied on top of my previous
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 54 ---
drivers/media/platform/marvell-ccic/mcam-core.h |2 +
2 files changed, 11 insertions(+), 45 deletions
And added a missing kfree to clean up the via_camera struct.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/via-camera.c | 60 ---
1 file changed, 14 insertions(+), 46
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c | 295 +---
1 file changed, 115 insertions(+), 180 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers
Hi Hans,
On 28 September 2012 10:23, Hans Verkuil hverk...@xs4all.nl wrote:
On Fri September 28 2012 09:48:01 Javier Martin wrote:
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ctrl = ov7670_g_ctrl,
- .s_ctrl
The following series migrate ov7670 sensor and current users to ctrl framework
as discussed in [1]. This has been tested against mx2_camera soc-camera bridge,
so tests or acks will be required from people using cam-core and via-camera out
there.
This will have to be applied on top of my previous
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Use v4l2_ctrl_auto_cluster() for auto_gain and auto_exp.
---
drivers/media/i2c/ov7670.c | 310
1 file changed, 112
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 54 ---
drivers/media/platform/marvell-ccic/mcam-core.h |2 +
2 files changed, 11 insertions(+), 45 deletions
And added a missing kfree to clean up the via_camera struct.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/via-camera.c | 60 ---
1 file changed, 14 insertions(+), 46
via-camera and mcam-core were the only bridge drivers that used ov7670.
Since now they have been moved to use the ctrl framework, the old
legacy callbacks in the ov7670 can be removed.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c |7 ---
1
Hi Hans,
On 28 September 2012 13:05, Hans Verkuil hverk...@xs4all.nl wrote:
On Fri September 28 2012 12:50:55 Javier Martin wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Use v4l2_ctrl_auto_cluster
The following series migrate ov7670 sensor and current users to ctrl framework
as discussed in [1]. This has been tested against mx2_camera soc-camera bridge,
so tests or acks will be required from people using cam-core and via-camera out
there.
This will have to be applied on top of my previous
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v2:
- Do not use 'cur.val' to get gain value.
---
drivers/media/i2c/ov7670.c | 310
1 file changed, 112 insertions
via-camera and mcam-core were the only bridge drivers that used ov7670.
Since now they have been moved to use the ctrl framework, the old
legacy callbacks in the ov7670 can be removed.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
And added a missing kfree to clean up the via_camera struct.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/via-camera.c | 60
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 54 ---
drivers/media/platform/marvell-ccic/mcam-core.h |2
On 6 October 2012 17:19, Mauro Carvalho Chehab mche...@infradead.org wrote:
Em Thu, 27 Sep 2012 08:58:33 +0200
javier Martin javier.mar...@vista-silicon.com escreveu:
Hi Jonathan,
thank you for your time.
On 26 September 2012 18:40, Jonathan Corbet cor...@lwn.net wrote:
This is going
.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More
-imx27.c;h=3b6b640eed247ea1b7848c7a7fa01801f0190cde;hb=b066f61482c7eac44e656499426a3c56d29c32ed#l226
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from
823a
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency:
4433
Tested-by: Gaëtan Carlier gcem...@gmail.com
Sorry I missed patch 1/2. Both patches are correct:
Tested-by: Javier Martin javier.mar...@vista-silicon.com
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE
-usb2-udc);
--
1.7.9.5
Tested-by: Javier Martin javier.mar...@vista-silicon.com
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line
!
--
tejun
Thanks Fabio.
Acked-by: Javier Martin javier.mar...@vista-silicon.com
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line
. Does this
mean, that this your patch is for i.MX25? But you're saying it's for
i.MX27. Confused...
I provide this mx27 clock in the first patch of the series:
http://patchwork.linuxtv.org/patch/14915/
Yes, I made the same mistake.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C
Hello,
we have an BD-SL-i.MX6 platform (compatible with the Nitrogen6X) where
we are currently running the BSP from Freescale, which is based on
kernel 3.10 if I recall properly.
We are aware that those drivers have some issues, specially when it
comes to compliance with the V4L2 frameworks
Hi Philipp,
thanks for your fast answer.
Apparently, the firmware is being loaded properly although it complains
about that version not being supported.
After queuing some YUV420 buffers with a simple application I perform a
VIDIOC_STREAMON in both the CAPTURE and the OUTPUT interfaces but I
Hello,
I am running kernel 4.1 in a var-dvk-solo-linux evaluation board from
Variscite.
This is what I get at system start-up:
coda 204.vpu: Firmware code revision: 34588
coda 204.vpu: Initialized CODA960.
coda 204.vpu: Unsupported firmware version: 2.1.8
coda 204.vpu: codec
Hi,
I am using mainline kernel 4.1 and I was writing a small application
that uses double buffering to read YUV420 frames from a file at 30fps
and displays them using the overlay plane in the imx-drm driver.
The first issue I noticed is that the image was green so I had to apply
the
Sorry for sending this to the wrong list.
On 07/08/15 09:25, Javier Martin wrote:
Hi,
I am using mainline kernel 4.1 and I was writing a small application
that uses double buffering to read YUV420 frames from a file at 30fps
and displays them using the overlay plane in the imx-drm driver
The ov5640 sensor from Omnivision supports up to 2592x1944
and both CSI and MIPI interfaces.
The following driver adds support for the CSI interface only
and VGA, 720p resolutions at 30fps.
Signed-off-by: Javier Martin <javiermar...@by.com.es>
---
.../devicetree/bindings/media/i2c/ov56
Sorry for the unrelated patches,
I will submit this again.
On 30/09/15 09:34, Javier Martin wrote:
The ov5640 sensor from Omnivision supports up to 2592x1944
and both CSI and MIPI interfaces.
The following driver adds support for the CSI interface only
and VGA, 720p resolutions at 30fps
The ov5640 sensor from Omnivision supports up to 2592x1944
and both CSI and MIPI interfaces.
The following driver adds support for the CSI interface only
and VGA, 720p resolutions at 30fps.
Signed-off-by: Javier Martin <javiermar...@by.com.es>
---
.../devicetree/bindings/media/i2c/ov56
Hi,
we want to a v4l2 driver for the ov5640 sensor from Omnivision.
AFAIK, there was an attempt in the past to mainline that driver [1] but
it didn't make it in the end.
Some people were asking for the code for the ov5640 and the ov5642 to be
merged [2] as well but IMHO both sensors are not
Hi,
we have an i.MX6 Solo based board running the latest mainline kernel
(4.15.3).
As part of our development we were measuring the decoding performance of
the i.MX6 coda chip.
For that purpose we are feeding the decoder with 640x368 @ 30fps H.264
streams that have been generated by
Sorry everyone about my previous e-mail with all the HTML garbage. Here
is the plain text answer instead.
Hi Philipp,
thanks for your answer.
On 13/03/18 12:20, Philipp Zabel wrote:
> Hi Javier,
>
> On Mon, 2018-03-12 at 17:54 +0100, Javier Martin wrote:
>> Hi,
>> we hav
Hello,
On 14/03/18 14:57, Philipp Zabel wrote:
On Wed, 2018-03-14 at 13:05 +0100, Javier Martin wrote:
Sorry everyone about my previous e-mail with all the HTML garbage. Here
is the plain text answer instead.
Hi Philipp,
thanks for your answer.
On 13/03/18 12:20, Philipp Zabel wrote
Hello Philipp,
On 14/03/18 16:11, Philipp Zabel wrote:
Hi Javier,
On Wed, 2018-03-14 at 15:35 +0100, Javier Martin wrote:
[...]
The encoder is running on a different system with an older 4.1.0 kernel.
Altough the firmware version in the code is 3.1.1 as well.
Do you think I should try
Sorry for resurrecting this thread but I'm still quite interested on
making this scenario work:
> OK, I've performed some tests with several resolutions and gop sizes,
here is the table with the results:
>
> Always playing 3 streams
>
> | Resolution | QP | GopSize | Kind of content |
401 - 447 of 447 matches
Mail list logo
