Re: [DE] Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
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 | Result | > | 640x368 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | > | 640x368 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS| > | 320x192 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS | > | 320x192 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | > | 1280x720 | 25 |16 | Waving hands | macroblock artifacts and lots of DEC_PIC_SUCCESS messages | > | 1280x720 | 25 |0 | Waving hands | Surprisingly smooth, no artifacts, time shifts nor DEC_PIC_SUCCESS| > > * The issues always happens in the first stream, the other 2 streams are fine. > * With GopSize = 0 I can even decode 4 720p streams with no artifacts > > It looks like for small resolutions it suffers from time shifts when multi-streaming, always affecting the first stream for some reason. In this case gop size doesn't seem to make any difference. > > For higher resolutions like 720p using GopSize = 0 seems to improve things a lot. > Philipp, you mentioned some possible issue with context switches in a previous e-mail: > I fear this may be some interaction between coda context switches and > bitstream reader unit state. Philipp, do these results confirm your theory? Are there any more tests I could prepare to help get to the bottom of this or this is something that belongs entirely to the coda firmware domain? Does anyone know if the official BSP from NXP is able to decode 4 flows without issues?
Re: [DE] Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
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 updating the system in the encoder to kernel 4.15 too and see if that makes any difference? I don't think that should matter. It'd be more interesting if GOP size has a significant influence. Does the Problem also appear in I-frame only streams? 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 | Result | | 640x368 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 640x368 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 320x192 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 320x192 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 1280x720 | 25 |16 | Waving hands | macroblock artifacts and lots of DEC_PIC_SUCCESS messages | | 1280x720 | 25 |0 | Waving hands | Surprisingly smooth, no artifacts, time shifts nor DEC_PIC_SUCCESS| * The issues always happens in the first stream, the other 2 streams are fine. * With GopSize = 0 I can even decode 4 720p streams with no artifacts It looks like for small resolutions it suffers from time shifts when multi-streaming, always affecting the first stream for some reason. In this case gop size doesn't seem to make any difference. For higher resolutions like 720p using GopSize = 0 seems to improve things a lot. Regards, Javier.
Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
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:
> Hi Javier,
>
> On Mon, 2018-03-12 at 17:54 +0100, Javier Martin wrote:
>> 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 another i.MX6 coda encoder
>> configured with fixed qp = 25 and gopsize = 16.
Those are the defaults. Is the encoder running on the same system, at
the same time? Or are you decoding a previously encoded stream (multiple
previously encoded streams)?
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 updating the system in the encoder to kernel
4.15 too and see if that makes any difference?
[...]
I'm currently using 3.1.1 both for encoding and decoding. I think I got
it from the latest BSP provided by NXP. Now that you mention it the
driver is printing these messages at probe time which I had ignored so far:
coda 204.vpu: Firmware code revision: 46056
coda 204.vpu: Initialized CODA960.
coda 204.vpu: Unsupported firmware version: 3.1.1
coda 204.vpu: codec registered as /dev/video[3-4]
That is strange, commit be7f1ab26f42 ("media: coda: mark CODA960
firmware versions 2.3.10 and 3.1.1 as supported") was merged
in v4.14.
You are right, those messages where taken from an old 4.1 kernel and not
from the latest 4.15 where they don't appear any longer. Sorry for the
noise.
Do you think I should use an older version instead?
Unfortunately I have no indication that this would help.
Also, do you think it would be worth trying different parameters in the
encoder to see how the decoder responds in those cases?
Possibly. It would be interesting to know if this happens more often for
low resolutions / low quality / static frames than high resolutions /
high quality / high movement.
I can easily prepare a test matrix with several resolutions, QPs and
content and let you know the results. Although first I'd like to know
your opinion on whether I should update the encoder to kernel 4.15 too.
Regards,
Javier.
Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
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 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 another i.MX6 coda encoder >> configured with fixed qp = 25 and gopsize = 16. >> >> For 1-2 streams it works smoothly. However, when adding the 3rd stream >> the first decoder instance starts to output these kind of errors: >> >> DEC_PIC_SUCCESS = 2097153 -> 0x21 >> DEC_PIC_SUCCESS = 2621441 -> 0x280001 > I think these might be (recoverable?) error flags, but so far I have > never seen them myself. > I've had reports of those occurring occasionally with certain streams > (not encoded by coda, regardless of the number of running decoder > instances) though. > > What is the coda firmware version you are using? I'm currently using 3.1.1 both for encoding and decoding. I think I got it from the latest BSP provided by NXP. Now that you mention it the driver is printing these messages at probe time which I had ignored so far: coda 204.vpu: Firmware code revision: 46056 coda 204.vpu: Initialized CODA960. coda 204.vpu: Unsupported firmware version: 3.1.1 coda 204.vpu: codec registered as /dev/video[3-4] Do you think I should use an older version instead? Also, do you think it would be worth trying different parameters in the encoder to see how the decoder responds in those cases? Regards, Javier.
coda: i.MX6 decoding performance issues for multi-streaming
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 another i.MX6 coda encoder configured with fixed qp = 25 and gopsize = 16. For 1-2 streams it works smoothly. However, when adding the 3rd stream the first decoder instance starts to output these kind of errors: DEC_PIC_SUCCESS = 2097153 -> 0x21 DEC_PIC_SUCCESS = 2621441 -> 0x280001 Every time one of these errors appears we can observe a weird artifact in the decoded video (pixelated macroblocks and/or jumps back in time). I tried looking at the original VPU lib implementation by Freescale [1] but they don't seem to handle these errors either. As I don't have access to any kind of Coda IP documentation it's quite hard to me to perform any additional debugging. Has anyone experienced these kind of performance issues too? I'm open to any suggestions and willing to perform extra tests to get to the bottom of this. Regards, Javier. [1] https://github.com/genesi/imx-lib/blob/master/vpu/vpu_lib.c#L2926
[PATCH] media: Add a driver for the ov5640 sensor.
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/ov5640.txt | 47 +
arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts | 50 -
arch/arm/boot/dts/imx6qdl-var-som.dtsi | 422 ++
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5640.c | 1403
drivers/media/i2c/ov5642.c | 129 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 30 +-
8 files changed, 1702 insertions(+), 391 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 drivers/media/i2c/ov5640.c
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..2e93e97
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,47 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5640 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1932V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be "ovti,ov5640"
+- clocks: reference to the xclk clock
+- clock-names: should be "xclk"
+- clock-rates: the xclk clock frequency
+
+Optional Properties:
+- reset-gpio: Chip reset GPIO
+- pwdn-gpio: Chip power down GPIO
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+ ...
+
+ ov5640: ov5640@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <_ov5640 _csi0>;
+ reg = <0x3c>;
+
+ clocks = < 200>;
+ clock-names = "xclk";
+ clock-rates = <2400>;
+
+ reset-gpio = < 20 GPIO_ACTIVE_LOW>;
+ pwdn-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5640_to_csi0: endpoint {
+ remote-endpoint = <_from_ov5640>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
index 5431e90..f92f68c 100644
--- a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
+++ b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
@@ -23,53 +23,3 @@
};
- {
- status = "okay";
-
- lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di0";
- status = "okay";
-
- display-timings {
- native-mode = <>;
- timingr0: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vback-porch = <6>;
- vfront-porch = <6>;
- hsync-len = <60>;
- vsync-len = <11>;
- };
- };
- };
-
- lvds-channel@1 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di1";
- primary;
- status = "okay";
-
- display-timings {
- native-mode = <>;
- timing1: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vback-porch = <6>;
- vfront-porch = <6>;
- h
Re: [PATCH] media: Add a driver for the ov5640 sensor.
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.
Signed-off-by: Javier Martin <javiermar...@by.com.es>
---
.../devicetree/bindings/media/i2c/ov5640.txt | 47 +
arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts | 50 -
arch/arm/boot/dts/imx6qdl-var-som.dtsi | 422 ++
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5640.c | 1403
drivers/media/i2c/ov5642.c | 129 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 30 +-
8 files changed, 1702 insertions(+), 391 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 drivers/media/i2c/ov5640.c
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..2e93e97
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,47 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5640 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1932V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be "ovti,ov5640"
+- clocks: reference to the xclk clock
+- clock-names: should be "xclk"
+- clock-rates: the xclk clock frequency
+
+Optional Properties:
+- reset-gpio: Chip reset GPIO
+- pwdn-gpio: Chip power down GPIO
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+ ...
+
+ ov5640: ov5640@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <_ov5640 _csi0>;
+ reg = <0x3c>;
+
+ clocks = < 200>;
+ clock-names = "xclk";
+ clock-rates = <2400>;
+
+ reset-gpio = < 20 GPIO_ACTIVE_LOW>;
+ pwdn-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5640_to_csi0: endpoint {
+ remote-endpoint = <_from_ov5640>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
index 5431e90..f92f68c 100644
--- a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
+++ b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
@@ -23,53 +23,3 @@
};
- {
- status = "okay";
-
- lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di0";
- status = "okay";
-
- display-timings {
- native-mode = <>;
- timingr0: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vback-porch = <6>;
- vfront-porch = <6>;
- hsync-len = <60>;
- vsync-len = <11>;
- };
- };
- };
-
- lvds-channel@1 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di1";
- primary;
- status = "okay";
-
- display-timings {
- native-mode = <>;
- timing1: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vb
[PATCH v2] media: Add a driver for the ov5640 sensor.
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/ov5640.txt | 47 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5640.c | 1403
4 files changed, 1462 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 drivers/media/i2c/ov5640.c
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..2e93e97
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,47 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5640 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1932V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be "ovti,ov5640"
+- clocks: reference to the xclk clock
+- clock-names: should be "xclk"
+- clock-rates: the xclk clock frequency
+
+Optional Properties:
+- reset-gpio: Chip reset GPIO
+- pwdn-gpio: Chip power down GPIO
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+ ...
+
+ ov5640: ov5640@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <_ov5640 _csi0>;
+ reg = <0x3c>;
+
+ clocks = < 200>;
+ clock-names = "xclk";
+ clock-rates = <2400>;
+
+ reset-gpio = < 20 GPIO_ACTIVE_LOW>;
+ pwdn-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5640_to_csi0: endpoint {
+ remote-endpoint = <_from_ov5640>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 6f30ea7..8c6689b 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -488,6 +488,17 @@ config VIDEO_OV7640
To compile this driver as a module, choose M here: the
module will be called ov7640.
+config VIDEO_OV5640
+ tristate "OmniVision OV5640 sensor support"
+ depends on I2C && VIDEO_V4L2
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5640 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5640.
+
config VIDEO_OV7670
tristate "OmniVision OV7670 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 34e7da2..65b224f 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
new file mode 100644
index 000..e06b812
--- /dev/null
+++ b/drivers/media/i2c/ov5640.c
@@ -0,0 +1,1403 @@
+/*
+ * Driver for the OV5640 sensor from Omnivision CSI interface only.
+ *
+ * Copyright (C) 2015 By Tech Design S.L. All Rights Reserved.
+ * Copyright (C) 2012-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Based on the MT9P031 driver and an out of tree ov5640 driver by Freescale:
+ * https://github.com/varigit/linux-2.6-imx/blob/imx_3.14.38_6qp_beta-var02/
+ * drivers/media/platform/mxc/capture/ov5640.c
+ *
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be us
RFC: ov5640 kernel driver.
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 that similar so that it's worth a common driver. The approach we had in mind so far was creating a new, independent, v4l2-subdev driver for the ov5640 with mbus support. I've found several sources out there with code for the ov5640 but, surprisingly, few attempts to mainline it. I would whether it is just people didn't take the effort or there was something wrong with the code. Has anyone got some comments/advices on this before we start coding? Is anyone already working on this and maybe we can collaborate instead of having two forks of the same driver? Regards, Javier. [1] https://lwn.net/Articles/470643/ [2] http://www.spinics.net/lists/linux-omap/msg69611.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
imx-drm: Color issues scanning out YUV420 frames through the overlay plane.
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 following patches to make the U and V components be scanned out properly: http://lists.freedesktop.org/archives/dri-devel/2014-October/071052.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071025.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071048.html The thing is that, even after applying the 3 patches above, colors are a bit strange. They seem about right but there are some artifacts, like a saturation effect that spoils the image. You can see some snapshots here to see what I am talking about: https://imageshack.com/i/f0nAM5Xbj https://imageshack.com/i/hl7bZMNjj https://imageshack.com/i/eyRjURxRj And the original video is the first one in this page: http://media.xiph.org/video/derf/ On the other hand, colors in the primary plane using the fbdev interface and RGB look correct. Has anyone seen something similar or is YUV420 working fine for you? Regards, Javier. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: imx-drm: Color issues scanning out YUV420 frames through the overlay plane.
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 first issue I noticed is that the image was green so I had to apply the following patches to make the U and V components be scanned out properly: http://lists.freedesktop.org/archives/dri-devel/2014-October/071052.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071025.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071048.html The thing is that, even after applying the 3 patches above, colors are a bit strange. They seem about right but there are some artifacts, like a saturation effect that spoils the image. You can see some snapshots here to see what I am talking about: https://imageshack.com/i/f0nAM5Xbj https://imageshack.com/i/hl7bZMNjj https://imageshack.com/i/eyRjURxRj And the original video is the first one in this page: http://media.xiph.org/video/derf/ On the other hand, colors in the primary plane using the fbdev interface and RGB look correct. Has anyone seen something similar or is YUV420 working fine for you? Regards, Javier. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: coda: Problems with encoding in i.MX6DL.
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 get the following error: coda 204.vpu: coda is not initialized. ... but then suddenly it's not. (coda_is_initialized just checks whether PC != 0) Could this have something to do with the PU power domain? Do all coda registers read 0x0 ? Do you have CONFIG_PM disabled? Check if d438462c20a3 (ARM: imx6: gpc: always enable PU domain if CONFIG_PM is not set) makes a difference. I think that patch hasn't made it into stable yet. Indeed, I was having problems with the runtime PM from the beginning and hacked up the code in the gpmc a bit to make sure the coda was always enabled but somehow I forgot to comment the poweroff callback and the codas was being powered off and never turned on again. Just in case it is useful for someone else these are the functions in arch/arm/mach-imx/gpc.c whose code I completely commented out: _imx6q_pm_pu_power_off imx6q_pm_pu_power_off Anyway, it looks like power management for the coda is a bit broken in the i.MX6D. I'll leave it disabled for now so that I continue with my development but I plan to have a look at it later on to see if I can fix it properly. [ cut here ] WARNING: CPU: 0 PID: 91 at drivers/media/v4l2-core/videobuf2-core.c:1792 vb2_start_streaming+0xe0/0x15c() That is because after copying buffers to the bitstream, the driver currently marks them as done. When start_streaming fails, videobuf2 expects drivers to re-queue them. So we'd have to flush the bitstream and re-queue the buffers so they can be copied to the bitstream all over during the next try. This warning is a result of incomplete error handling in the coda start_streaming implementation. I see, I might look into this if I manage to get some spare time. Regards, Javier. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
coda: Problems with encoding in i.MX6DL.
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 registered as /dev/video[0-1] 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 get the following error: coda 204.vpu: coda is not initialized. [ cut here ] WARNING: CPU: 0 PID: 91 at drivers/media/v4l2-core/videobuf2-core.c:1792 vb2_start_streaming+0xe0/0x15c() Modules linked in: CPU: 0 PID: 91 Comm: wmip_bsp_tests Tainted: GW 4.1.0-4-g192a113-dirty #96 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [c0012cb4] (dump_backtrace) from [c0012ecc] (show_stack+0x18/0x1c) r6:c0815888 r5: r4:c08d3764 r3: [c0012eb4] (show_stack) from [c061ab8c] (dump_stack+0x8c/0x9c) [c061ab00] (dump_stack) from [c002775c] (warn_slowpath_common+0x88/0xb8) r5:0700 r4: [c00276d4] (warn_slowpath_common) from [c0027830] (warn_slowpath_null+0x24/0x2c) r8:edc35000 r7: r6:ee1ee408 r5:ee1ee4d8 r4:fff2 [c002780c] (warn_slowpath_null) from [c0489734] (vb2_start_streaming+0xe0/0x15c) [c0489654] (vb2_start_streaming) from [c048bc50] (vb2_internal_streamon+0x118/0x164) r7: r6:edc1614c r5:ee1ee400 r4:ee1ee408 [c048bb38] (vb2_internal_streamon) from [c048bcd4] (vb2_streamon+0x38/0x58) r5:ee1ee400 r4:0001 [c048bc9c] (vb2_streamon) from [c0485670] (v4l2_m2m_streamon+0x38/0x54) [c0485638] (v4l2_m2m_streamon) from [c04856a4] (v4l2_m2m_ioctl_streamon+0x18/0x1c) r5:ee82f068 r4:40045612 [c048568c] (v4l2_m2m_ioctl_streamon) from [c0474ea0] (v4l_streamon+0x20/0x24) [c0474e80] (v4l_streamon) from [c0477810] (__video_do_ioctl+0x264/0x2cc) [c04775ac] (__video_do_ioctl) from [c0477294] (video_usercopy+0x190/0x48c) r10:ee1ebe20 r9:0001 r8:be916b74 r7: r6: r5:c04775ac r4:40045612 [c0477104] (video_usercopy) from [c04775a8] (video_ioctl2+0x18/0x1c) r10:eea7dd88 r9:be916b74 r8:ee82fcf0 r7:40045612 r6:be916b74 r5:edc35000 r4:ee82f068 [c0477590] (video_ioctl2) from [c0473a4c] (v4l2_ioctl+0xac/0xc8) [c04739a0] (v4l2_ioctl) from [c00f8334] (do_vfs_ioctl+0x430/0x624) r8:0003 r7:be916b74 r6:0003 r5:edc35000 r4:edc35000 r3:c04739a0 [c00f7f04] (do_vfs_ioctl) from [c00f8564] (SyS_ioctl+0x3c/0x64) r10: r9:ee1ea000 r8:0003 r7:be916b74 r6:40045612 r5:edc35000 r4:edc35000 [c00f8528] (SyS_ioctl) from [c000f720] (ret_fast_syscall+0x0/0x3c) r8:c000f8c4 r7:0036 r6:8aa8 r5: r4: r3:be916b74 ---[ end trace 2b0ba71bfb12fec4 ]--- As anyone seen the same issue? Could be related to the Unsupported firmware version complaint? Do you know where to get the 2.1.5 firmware for the i.MX6D? Regards, Javier. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
i.MX6 video capture support in mainline
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 like the media controller API, stability, etc... Furthermore, we need to use the mainline kernel because some of the drivers that we need to use are not available in the Freescale kernel. The biggest problem that we have found so far for switching to the mainline kernel is the video capture support in the I.MX6 IPU. I've been following some old e-mail threads (from 2014) and I eventually found Philipp Zabel's repository branch 'nitrogen6x-ipu-media' which has what seems to be an early version of an i.MX6 IPU capture driver via the CSI interface. We've got here the same setup with an ov5642 sensor connected to the CSI interface and we have been giving a try to the driver. This is what we have tried so far: cat /dev/video0 # This is needed so that open gets called and the csi links are created media-ctl -l 'ov5642 1-003c:0-mipi_ipu1_mux:1[1], /soc/ipu@0240/port@0:1-IPU0 SMFC0:0[1]' media-ctl -l 'IPU0 SMFC0:1-imx-ipuv3-camera.2:0[1]' The last command will fail like this: imx-ipuv3 240.ipu: invalid link 'IPU0 SMFC0'(5):1 - 'imx-ipuv3-camera.2'(2):0 Unable to parse link: Invalid argument (22) The reason it fails, apparently, is that the links that have been created when opening /dev/video0 are not included in the ipu_links[] static table defined in drivers/gpio/ipu-v3/ipu-media.c which is where the ipu_smfc_link_setup() function tries to find a valid link. I've got some questions regarding this driver and iMX6 video capture support in general that someone here may gladly answer: a) Is anyone currently working on mainlining iMX6 video capture support? I know about Steve's and Philipp's work but I haven't seen any progress since September 2014. b) Does anyone know whether it's possible to capture YUV420P video using the driver in Philipp's repository? If so could you please provide the pipeline setup that you used with media-ctl? c) If we were willing to help with mainline submission of this driver what issues should we focus on? Regards, Javier. [1] git://git.pengutronix.de/git/pza/linux.git -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] mt9m131/mt9m111 manual exposure control.
Hi,
the attached patch, adds support for manual exposure control for
sensor mt9m111.
For this purpose, the register 0x009 (Shutter width) is written with
values from 0x to 0x.
In order to test this, an mt9m131 sensor was connected to a DM3730
(omap3isp). Using yavta to capture some frames, the results are quite
surprising. Only the second frame read from the sensor has the desired
exposure time, the other frames just keep the default exposure time.
Moreover, it seems this behaviour does not change no matter I
enable/disable autoexposure.
I just wanted to make it public just in case anyone feels like giving
a try to the patch.
Regards.
---
diff --git a/drivers/media/i2c/soc_camera/mt9m111.c
b/drivers/media/i2c/soc_camera/mt9m111.c
index 9a4b8b0..a752be5 100644
--- a/drivers/media/i2c/soc_camera/mt9m111.c
+++ b/drivers/media/i2c/soc_camera/mt9m111.c
@@ -710,6 +710,13 @@ static int mt9m111_set_autoexposure(struct
mt9m111 *mt9m111, int on)
return reg_clear(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOEXPO_EN);
}
+static int mt9m111_set_exposure(struct mt9m111 *mt9m111, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
+
+ return reg_write(SHUTTER_WIDTH, val);
+}
+
static int mt9m111_set_autowhitebalance(struct mt9m111 *mt9m111, int on)
{
struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
@@ -735,6 +742,8 @@ static int mt9m111_s_ctrl(struct v4l2_ctrl *ctrl)
return mt9m111_set_global_gain(mt9m111, ctrl-val);
case V4L2_CID_EXPOSURE_AUTO:
return mt9m111_set_autoexposure(mt9m111, ctrl-val);
+ case V4L2_CID_EXPOSURE:
+ return mt9m111_set_exposure(mt9m111, ctrl-val);
case V4L2_CID_AUTO_WHITE_BALANCE:
return mt9m111_set_autowhitebalance(mt9m111, ctrl-val);
}
@@ -1080,6 +1089,8 @@ static int mt9m111_probe(struct i2c_client *client,
v4l2_i2c_subdev_init(mt9m111-subdev, client, mt9m111_subdev_ops);
v4l2_ctrl_handler_init(mt9m111-hdl, 5);
+v4l2_ctrl_new_std(mt9m111-hdl, mt9m111_ctrl_ops, V4L2_CID_EXPOSURE,
+ 1, 0x, 1, 0x219);
v4l2_ctrl_new_std(mt9m111-hdl, mt9m111_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
v4l2_ctrl_new_std(mt9m111-hdl, mt9m111_ctrl_ops,
--
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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: iommu register problem.
Hi Laurent, Guennadi, On 11 March 2013 21:51, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, [2.706939] omap3isp omap3isp: Revision 15.0 found [2.712402] omap_iommu_attach: 1 [2.715942] omap_iommu_attach: 2 [2.719329] omap_iommu_attach: 3 [2.722778] omap_iommu_attach: 4 [2.726135] omap_iommu_attach: 5 [2.729553] iommu_enable: 1 [2.732482] iommu_enable: 2, arch_iommu = c0599adc [2.737548] iommu_enable: 3 [2.740478] iommu_enable: 5 [2.743652] omap-iommu omap-iommu.0: mmu_isp: version 1.1 [2.749389] omap_iommu_attach: 6 [2.752807] omap_iommu_attach: 7 [2.756195] omap_iommu_attach: 8 [2.759613] omap_iommu_attach: 9 [2.763977] omap3isp omap3isp: hist: DMA channel = 2 [2.770904] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [2.778839] ALSA device list: [2.781982] No soundcards found. [2.799285] mt9m111 2-0048: mt9m111: driver needs platform data [2.805603] mt9m111: probe of 2-0048 failed with error -22 [2.814849] omap3isp omap3isp: isp_register_subdev_group: Unable to register subdev mt9m111 The error I get now seems more related to the fact that I am trying to use a soc-camera sensor (mt9m111) with a non-soc-camera host (omap3isp) and I probably need some extra platform code. Do you know any board in mainline in a similar situation? There's none yet I'm afraid. We don't have the necessary infrastructure in place yet to allow this. Guennadi might be able to give you a bit more information about the current status. So what kind of changes are required to make this work? Are we talking about migrating each soc-camera sensor separately, soc-camera framework changes, both of them? -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: i.MX27 camera: fix picture source width
Hi Guernnadi, Christoph, On 12 March 2013 09:25, Christoph Fritz chf.fr...@googlemail.com wrote: On Tue, 2013-03-12 at 08:58 +0100, Guennadi Liakhovetski wrote: On Thu, 7 Mar 2013, javier Martin wrote: What mbus format are you using? Could you please check if the s_width value that your sensor mt9m001 returns is correct? Remember it should be in pixels, not in bytes. Thanks for looking at this. But here's my question: for a pass-through mode mx2_camera uses a 16-bpp (RGB565) format. But what if it's actually an 8-bpp format, don't you then have to adjust line-width register settings? If you don't do that, the camera interface would expect a double number of bytes per line, so, it could get confused by HSYNC coming after half-line? You are right. To emphasize this: I'm using here a mt9m001 (monochrome) camera with an 8-bpp format. Ok, now that makes sense. Then, what you should do is apply your patch conditionally so that you don't break other working cases: - Channel 1 is being used. - Channel 1 is in pass-through mode. - The sensor uses an 8-bpp format. 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: i.MX27 camera: fix picture source width
On 12 March 2013 10:39, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 12 Mar 2013, javier Martin wrote: Hi Guernnadi, Christoph, On 12 March 2013 09:25, Christoph Fritz chf.fr...@googlemail.com wrote: On Tue, 2013-03-12 at 08:58 +0100, Guennadi Liakhovetski wrote: On Thu, 7 Mar 2013, javier Martin wrote: What mbus format are you using? Could you please check if the s_width value that your sensor mt9m001 returns is correct? Remember it should be in pixels, not in bytes. Thanks for looking at this. But here's my question: for a pass-through mode mx2_camera uses a 16-bpp (RGB565) format. But what if it's actually an 8-bpp format, don't you then have to adjust line-width register settings? If you don't do that, the camera interface would expect a double number of bytes per line, so, it could get confused by HSYNC coming after half-line? You are right. To emphasize this: I'm using here a mt9m001 (monochrome) camera with an 8-bpp format. Ok, now that makes sense. Then, what you should do is apply your patch conditionally so that you don't break other working cases: - Channel 1 is being used. - Channel 1 is in pass-through mode. which would be if (!prp-in_fmt !prp-out_fmt) Yes, that would do. - The sensor uses an 8-bpp format. No, the format in unimportant - you pretend to use a 16-bit format, so, your simulated line is always bytesperline / 2 pseudo-pixels long. OK. Christoph, in your next comment please add a comment something like /* * In pass-through we configure EMMA with a 16-bpp format, * set the line-width accordingly. */ -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
omap3isp: iommu register problem.
Hi,
I'm trying to make omap3isp work with our DM3730 based board.
When I try to boot the kernel I get the following message:
[2.064239] omap3isp omap3isp: Revision 15.0 found
[2.070220] omap_iommu_attach: 1
[2.073669] omap_iommu_attach: 2
[2.077056] omap_iommu_attach: 3
[2.080627] omap_iommu_attach: 4
[2.084014] omap_iommu_attach: 5
[2.087432] iommu_enable: 1
[2.090362] iommu_enable: 2, arch_iommu = (null)
[2.095428] omap_iommu_attach: 6
[2.098815] omap3isp omap3isp: can't get omap iommu: -19
[2.104431] omap3isp omap3isp: can't attach iommu device: -19
[2.110504] Unable to handle kernel NULL pointer dereference at
virtual address 0034
[2.119018] pgd = c0004000
[2.121856] [0034] *pgd=
[2.125671] Internal error: Oops: 5 [#1] ARM
[2.130157] Modules linked in:
[2.133361] CPU: 0Not tainted (3.8.0-2-g07e6459-dirty #741)
[2.140045] PC is at omap_iommu_save_ctx+0x18/0x24
[2.145050] LR is at omap3isp_put+0x98/0xd8
[2.149444] pc : [c0432cdc]lr : [c03e3654]psr: 6113
[2.149444] sp : cf831e50 ip : fp : c0670184
[2.161437] r10: 0010 r9 : bfff r8 : ffed
[2.166931] r7 : 0001 r6 : c077b9a8 r5 : cf010530 r4 : cf01
[2.173736] r3 : r2 : c077bc00 r1 : r0 :
[2.180572] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[2.188232] Control: 10c5387d Table: 80004019 DAC: 0015
[2.194244] Process swapper (pid: 1, stack limit = 0xcf830230)
[2.200347] Stack: (0xcf831e50 to 0xcf832000)
[2.204925] 1e40: cf01
c03e3654 cf01 c077b9b8
[2.213470] 1e60: c077b9a8 c03e3c70 0001
cf010530 cf01 c0058e84
[2.222045] 1e80: c07606c8 cf8e6a40 c077b9b8
c077b9b8 c0d16db4 c077b9ec
[2.230590] 1ea0: c07bba98 c0736360 00b0 c07606c8
c02f822c c077b9b8 c02f6f2c
[2.239166] 1ec0: c077b9b8 c07bba98 c077b9ec c0736360
c02f7154 c07bba98 cf831ee8
[2.247711] 1ee0: c02f70c0 c02f5888 cf81e4a8 cf8de510
c07bba98 c07ac1d0 cfbed240
[2.256286] 1f00: c02f6004 c066b5c0 c07bba98
c07606c0 c07bba98
[2.264831] 1f20: c07562d8 c02f7748 c07606c0 c07cddc0
c07562d8 c0736360 c000864c
[2.273406] 1f40: c06bdb3c c070fd04 0006 0006
c07606c0 c076dcd4 c07cddc0
[2.281951] 1f60: 0007 c0736360 00b0 c07606c8
c073628c 0006 0006
[2.290527] 1f80: c0736360 cf83 c052ecb8
[2.299072] 1fa0: c052ecc0 c000e0b0
[2.307647] 1fc0:
[2.316223] 1fe0: 0013
60402140 4b080520
[2.324798] [c0432cdc] (omap_iommu_save_ctx+0x18/0x24) from
[c03e3654] (omap3isp_put+0x98/0xd8)
[2.334259] [c03e3654] (omap3isp_put+0x98/0xd8) from [c03e3c70]
(isp_probe+0x1d0/0xaf0)
[2.343017] [c03e3c70] (isp_probe+0x1d0/0xaf0) from [c02f822c]
(platform_drv_probe+0x18/0x1c)
[2.352325] [c02f822c] (platform_drv_probe+0x18/0x1c) from
[c02f6f2c] (driver_probe_device+0x80/0x214)
[2.362426] [c02f6f2c] (driver_probe_device+0x80/0x214) from
[c02f7154] (__driver_attach+0x94/0x98)
[2.372283] [c02f7154] (__driver_attach+0x94/0x98) from
[c02f5888] (bus_for_each_dev+0x60/0x8c)
[2.381744] [c02f5888] (bus_for_each_dev+0x60/0x8c) from
[c02f6004] (bus_add_driver+0xa4/0x238)
[2.391235] [c02f6004] (bus_add_driver+0xa4/0x238) from
[c02f7748] (driver_register+0x78/0x140)
[2.400695] [c02f7748] (driver_register+0x78/0x140) from
[c000864c] (do_one_initcall+0x30/0x170)
[2.410278] [c000864c] (do_one_initcall+0x30/0x170) from
[c073628c] (kernel_init_freeable+0xdc/0x1b0)
[2.420318] [c073628c] (kernel_init_freeable+0xdc/0x1b0) from
[c052ecc0] (kernel_init+0x8/0xe4)
[2.429809] [c052ecc0] (kernel_init+0x8/0xe4) from [c000e0b0]
(ret_from_fork+0x14/0x24)
[2.438568] Code: e92d4010 e59021d4 e5933000 e5920004 (e5933034)
[2.445129] ---[ end trace ce0d24c569f5d702 ]---
[2.450012] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
This is due to the following function not being executed at startup:
static int __init omap2_iommu_init(void)
{
printk(%s\n, __func__);
return omap_install_iommu_arch(omap2_iommu_ops);
}
module_init(omap2_iommu_init);
Does anyone know what could be the reason?
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 this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mt9m111/mt9m131: kernel 3.8 issues.
Hi Guennadi, I just tested my mt9m131 camera on a i.MX31 board, if not this your email I don't think I'd be alarmed by the image quality it's producing, maybe I'm just less picky:-) And yes, in general I agree, I think, this level of image quality tuning is difficult to achieve on modern cameras with 100s of fine-tuning knobs. I'll try to re-test this camera in day light conditions and post my best shot :) http://download.open-technology.de/mt9m131/ .ppm is taken with mt9m131. Note, that I shot 10 frames and took the 3rd one - the first two are much darker, #3 is where autoexposure has kicked in, I suppose. Also note, that the comparison shot has been fired from a much smaller distance to cover a similar area due to obviously different lenses. I'll leave any colour-quality judgement to the reader(s) :-) Thank you for your feedback. It seems that we all have a similar colour quality. If Aptina comes up with better settings or I find them I'll post a patch for you to test. 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: iommu register problem.
I've just found the following thread where te problem is explained: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086364.html The problem is related with the order iommu and omap3isp are probed when both are built-in. If I load omap3isp as a module the problem is gone. However, according to the previous thread, omap3isp register should return error but an oops should not be generated. So I think there is a bug here anyway. -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: iommu register problem.
Hi Laurent,
thank you for your answer.
On 11 March 2013 16:01, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Javier,
On Monday 11 March 2013 13:18:12 javier Martin wrote:
I've just found the following thread where te problem is explained:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086364.h
tml
The problem is related with the order iommu and omap3isp are probed
when both are built-in. If I load omap3isp as a module the problem is
gone.
However, according to the previous thread, omap3isp register should
return error but an oops should not be generated. So I think there is
a bug here anyway.
Does the following patch (compile-tested only) fix the issue ?
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 6e5ad8e..4d889be 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2123,6 +2123,7 @@ static int isp_probe(struct platform_device *pdev)
ret = iommu_attach_device(isp-domain, pdev-dev);
if (ret) {
dev_err(pdev-dev, can't attach iommu device: %d\n, ret);
+ ret = -EPROBE_DEFER;
goto free_domain;
}
@@ -2161,6 +2162,7 @@ detach_dev:
iommu_detach_device(isp-domain, pdev-dev);
free_domain:
iommu_domain_free(isp-domain);
+ isp-domain = NULL;
error_isp:
omap3isp_put(isp);
error:
Yes,
that solves the problems.
[2.706939] omap3isp omap3isp: Revision 15.0 found
[2.712402] omap_iommu_attach: 1
[2.715942] omap_iommu_attach: 2
[2.719329] omap_iommu_attach: 3
[2.722778] omap_iommu_attach: 4
[2.726135] omap_iommu_attach: 5
[2.729553] iommu_enable: 1
[2.732482] iommu_enable: 2, arch_iommu = c0599adc
[2.737548] iommu_enable: 3
[2.740478] iommu_enable: 5
[2.743652] omap-iommu omap-iommu.0: mmu_isp: version 1.1
[2.749389] omap_iommu_attach: 6
[2.752807] omap_iommu_attach: 7
[2.756195] omap_iommu_attach: 8
[2.759613] omap_iommu_attach: 9
[2.763977] omap3isp omap3isp: hist: DMA channel = 2
[2.770904] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[2.778839] ALSA device list:
[2.781982] No soundcards found.
[2.799285] mt9m111 2-0048: mt9m111: driver needs platform data
[2.805603] mt9m111: probe of 2-0048 failed with error -22
[2.814849] omap3isp omap3isp: isp_register_subdev_group: Unable to
register subdev mt9m111
The error I get now seems more related to the fact that I am trying to
use a soc-camera sensor (mt9m111) with a non-soc-camera host
(omap3isp) and I probably need some extra platform code.
Do you know any board in mainline in a similar situation?
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 this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mt9m111/mt9m131: kernel 3.8 issues.
Hi Benoît, On 8 March 2013 12:53, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Regarding 3, you say it works nicely for you in kernel 3.4.5. I've migrated my code to that version but I still get colours that lack enough intensity. This is a snapshot a taken with my mobile which is much more similar to what I can really see with my eyes: http://img96.imageshack.us/img96/1451/20130307171334.jpg This is a similar snapshot b taken with mt9m131 in my board. It shows that colours tend to be dull and darker, specially green: http://img703.imageshack.us/img703/6025/testgo.jpg Are the snapshots you take with your HW more similar to a or to b? Perhaps I am being too picky with the image quality and this is all what mt9m131 can do? I fear that my captures are closer to b. Your description of 3 was giving the impression of flashy colors. But the impression that this sensor gives me is rather a superimposed gray film. This effect is more or less visible depending on the lighting conditions, but it never seems to produce high quality colors. Yes, yours is probably is the best description for the image quality this sensor provides with the current settings. Well, this is a bit disappointing. Let's see if some other user has a similar experience with it or comes up with a way to improve it. I've tested several things such as disabling auto white balance and auto exposure and try to manually change colour gains but it seems the sensor simply ignores the latter. There is an evaluation board from Aptina (http://www.digikey.com/product-detail/es/MT9M131C12STCH%20ES/557-1251-ND/1643271) but, unfortunately, I don't have one of these available. It could be very useful to test the sensor with this board with the configuration Aptina recommends and see whether the grey layer effect still persists. I will try to contact Aptina's technical support but, according to my previous experience, there is no guarantee we get a clarifying answer. I'll keep you updated nevertheless. 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
mt9m111/mt9m131: kernel 3.8 issues.
Hi,
I am testing mt9m131 sensor (which is supported in mt9m111.c) in
mainline kernel 3.8 with my Visstrim M10, which is an i.MX27 board.
Since both mx2_camera.c and mt9m111.c are soc_camera drivers making it
work was quite straightforward. However, I've found several issues
regarding mt9m111.c:
1. mt9m111 probe is broken. It will give an oops since it tries to use
a context before it's been assigned.
2. mt9m111 auto exposure control is broken too (see the patch below).
3. After I've fixed 1 and 2 the colours in the pictures I grab are
dull and not vibrant, green is very dark and red seems like pink, blue
and yellow look fine though. I have both auto exposure and auto white
balance enabled.
I can see in the list that you have tried this sensor before. Have you
also noticed these problems (specially 3)?
This patch is just to provide a quick fix for points 1 and 2 just in
case you feel like testing this in kernel 3.8. If you consider these
fix are valid I'll send a proper patch later:
diff --git a/drivers/media/i2c/soc_camera/mt9m111.c
b/drivers/media/i2c/soc_camera/mt9m111.c
index 62fd94a..7d99655 100644
--- a/drivers/media/i2c/soc_camera/mt9m111.c
+++ b/drivers/media/i2c/soc_camera/mt9m111.c
@@ -704,7 +704,7 @@ static int mt9m111_set_autoexposure(struct mt9m111
*mt9m111, int on)
{
struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
- if (on)
+ if (on == V4L2_EXPOSURE_AUTO)
return reg_set(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOEXPO_EN);
return reg_clear(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOEXPO_EN);
}
@@ -916,6 +916,9 @@ static int mt9m111_video_probe(struct i2c_client *client)
s32 data;
int ret;
+ /* Assign context to avoid oops */
+ mt9m111-ctx = context_a;
+
ret = mt9m111_s_power(mt9m111-subdev, 1);
if (ret 0)
return ret;
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 this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: i.MX27 camera: fix picture source width
Hi,
sorry for the long delay. I missed this one.
On 5 March 2013 18:56, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
(Javier's opinion requested)
I'm no expert in i.MX27 hardware, would be great to have an ack from
someone, intensively working in this area. Javier, what do you think? Is
this really correct always for channel 1, or should this calculation
depend on the pixel format?
Thanks
Guennadi
On Sat, 16 Feb 2013, Christoph Fritz wrote:
While using a mt9m001 (monochrome) camera the final output falsely gets
horizontally divided into two pictures.
The issue was git bisected to commit f410991dcf1f
| [media] i.MX27 camera: add support for YUV420 format
|
| 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.
It sets PICTURE_X_SIZE in register PRP_SRC_FRAME_SIZE to its full width
while before that commit it was divided by two:
- writel(((bytesperline 1) 16) | icd-user_height,
+ writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_SRC_FRAME_SIZE);
i.mx27 reference manual (41.6.12 PrP Source Frame Size Register) says:
PICTURE_X_SIZE. These bits set the frame width to be
processed in number of pixels. In YUV 4:2:0 mode, Cb and
Cr widths are taken as PICTURE_X_SIZE/2 pixels. In YUV
4:2:0 mode, this value should be a multiple of 8-pixels.
In other modes (RGB, YUV 4:2:2 and YUV 4:4:4) it should
be a multiple of 4 pixels.
Note that, according to the description in the datasheet,
PICTURE_X_SIZE is specified in pixels, not bytes. So, it is not
dependant on the format used.
This patch reverts to PICTURE_X_SIZE/2 for channel 1.
Tested on Kernel 3.4, merged to 3.8rc.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
drivers/media/platform/soc_camera/mx2_camera.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 8bda2c9..795bd3f 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -778,11 +778,11 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
struct mx2_camera_dev *pcdev = ici-priv;
struct mx2_fmt_cfg *prp = pcdev-emma_prp;
- writel((pcdev-s_width 16) | pcdev-s_height,
-pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel(prp-cfg.src_pixel,
pcdev-base_emma + PRP_SRC_PIXEL_FORMAT_CNTL);
if (prp-cfg.channel == 1) {
+ writel(((bytesperline 1) 16) | pcdev-s_height,
+ pcdev-base_emma + PRP_SRC_FRAME_SIZE);
If you use bytesperline here you are making this operation dependant
on the mbus format.
You should use s_width instead and there is no reason to divide it by
2 since it is already in pixels, as well as PRP_SRC_FRAME_SIZE.
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_CH1_OUT_IMAGE_SIZE);
writel(bytesperline,
@@ -790,6 +790,8 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
writel(prp-cfg.ch1_pixel,
pcdev-base_emma + PRP_CH1_PIXEL_FORMAT_CNTL);
} else { /* channel 2 */
+ writel((pcdev-s_width 16) | pcdev-s_height,
+ pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_CH2_OUT_IMAGE_SIZE);
}
--
1.7.10.4
We are using channel 1 here daily for capturing YUV422 and have not
experience the problem you point out.
What mbus format are you using? Could you please check if the s_width
value that your sensor mt9m001 returns is correct? Remember it should
be in pixels, not in bytes.
--
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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc-camera: mt9m111: Fix auto-exposure control
Hi,
On 26 February 2013 19:32, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
Commit f9bd5843658e18a7097fc7258c60fb840109eaa8 changed V4L2_CID_EXPOSURE_AUTO
from boolean to enum, and commit af8425c54beb3c32cbb503a379132b3975535289
changed the creation of this control into a menu for the mt9m111. However,
mt9m111_set_autoexposure() is still interpreting the value set for this
control
as a boolean, which also conflicts with the default value of this control set
to
V4L2_EXPOSURE_AUTO (0).
This patch makes mt9m111_set_autoexposure() interpret the value set for
V4L2_CID_EXPOSURE_AUTO as defined by enum v4l2_exposure_auto_type.
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Mickaël Guivarc'h mickael.guiva...@advansee.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
drivers/media/i2c/soc_camera/mt9m111.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/mt9m111.c
b/drivers/media/i2c/soc_camera/mt9m111.c
index bbc4ff9..0b0ebaa 100644
--- a/drivers/media/i2c/soc_camera/mt9m111.c
+++ b/drivers/media/i2c/soc_camera/mt9m111.c
@@ -701,11 +701,11 @@ static int mt9m111_set_global_gain(struct mt9m111
*mt9m111, int gain)
return reg_write(GLOBAL_GAIN, val);
}
-static int mt9m111_set_autoexposure(struct mt9m111 *mt9m111, int on)
+static int mt9m111_set_autoexposure(struct mt9m111 *mt9m111, int val)
{
struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
- if (on)
+ if (val == V4L2_EXPOSURE_AUTO)
return reg_set(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOEXPO_EN);
return reg_clear(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOEXPO_EN);
}
--
1.7.10.4
This solves a real issue.
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 unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mt9m111/mt9m131: kernel 3.8 issues.
Hi Benoît,
thank you for your answer.
On 7 March 2013 13:13, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote:
Dear Javier Martin,
On Thursday, March 7, 2013 10:43:42 AM, Javier Martin wrote:
Hi,
I am testing mt9m131 sensor (which is supported in mt9m111.c) in
mainline kernel 3.8 with my Visstrim M10, which is an i.MX27 board.
Since both mx2_camera.c and mt9m111.c are soc_camera drivers making it
work was quite straightforward. However, I've found several issues
regarding mt9m111.c:
1. mt9m111 probe is broken. It will give an oops since it tries to use
a context before it's been assigned.
2. mt9m111 auto exposure control is broken too (see the patch below).
3. After I've fixed 1 and 2 the colours in the pictures I grab are
dull and not vibrant, green is very dark and red seems like pink, blue
and yellow look fine though. I have both auto exposure and auto white
balance enabled.
I can see in the list that you have tried this sensor before. Have you
also noticed these problems (specially 3)?
I am using the MT9M131 with an i.MX35 board and Linux 3.4.5. It works nicely.
I
have not noticed 1 and 3. However, I have noticed 2, for which I already have
posted a patch (here: https://patchwork.kernel.org/patch/2187291/), but I have
not yet received any feedback.
I've just added my Tested-By to your patch, and it seems Guennadi will
merge it. So, we don't have to worry about 2 any more.
Regarding 3, you say it works nicely for you in kernel 3.4.5. I've
migrated my code to that version but I still get colours that lack
enough intensity.
This is a snapshot a taken with my mobile which is much more similar
to what I can really see with my eyes:
http://img96.imageshack.us/img96/1451/20130307171334.jpg
This is a similar snapshot b taken with mt9m131 in my board. It
shows that colours tend to be dull and darker, specially green:
http://img703.imageshack.us/img703/6025/testgo.jpg
Are the snapshots you take with your HW more similar to a or to
b? Perhaps I am being too picky with the image quality and this is
all what mt9m131 can do?
This patch is just to provide a quick fix for points 1 and 2 just in
case you feel like testing this in kernel 3.8. If you consider these
fix are valid I'll send a proper patch later:
It's not straightforward to port my board to 3.8, but I've just reviewed the
code in linux-next (see below).
diff --git a/drivers/media/i2c/soc_camera/mt9m111.c
b/drivers/media/i2c/soc_camera/mt9m111.c
index 62fd94a..7d99655 100644
--- a/drivers/media/i2c/soc_camera/mt9m111.c
+++ b/drivers/media/i2c/soc_camera/mt9m111.c
@@ -704,7 +704,7 @@ static int mt9m111_set_autoexposure(struct mt9m111
*mt9m111, int on)
{
struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
- if (on)
+ if (on == V4L2_EXPOSURE_AUTO)
return reg_set(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOEXPO_EN);
return reg_clear(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOEXPO_EN);
}
This hunk does the same thing as my patch mentioned above, so please don't
send
anything for that.
Sure.
@@ -916,6 +916,9 @@ static int mt9m111_video_probe(struct i2c_client *client)
s32 data;
int ret;
+ /* Assign context to avoid oops */
+ mt9m111-ctx = context_a;
+
ret = mt9m111_s_power(mt9m111-subdev, 1);
if (ret 0)
return ret;
There is indeed a bug, introduced by commit 4bbc6d5. The issue is:
mt9m111_set_context(mt9m111, mt9m111-ctx);
in mt9m111_restore_state() called (indirectly) from mt9m111_s_power() from
mt9m111_video_probe() with ctx still NULL, before mt9m111_init() has been
called
to initialize ctx to context_b.
So the fix would not be what you did, but rather to reorganize things a little
bit to avoid this out-of-order init and use of ctx.
Thanks, I will take a look at the offending commit and try to
reorganize the code properly.
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 this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] video_visstrim ov7670_for_v3.9.
Hi Mauro, this is the pull request I sent to you two months ago. I've applied the patches on your 'for_v3.9' branch and everything is still working fine. Furthermore, I've added the SoB line. I hope everything is OK this time. If not please let me know. The following changes since commit 8672c8509e1155a3bc712060bd948ba98a1f283a: [media] coda: Fix build due to iram.h rename. (2013-01-29 11:06:53 +0100) are available in the git repository at: https://github.com/jmartinc/video_visstrim.git ov7670_for_v3.9 for you to fetch changes up to 2dc110e020327ad5bbf4cfb2e6717b4d2914d096: ov7670: remove legacy ctrl callbacks. (2013-01-29 12:21:40 +0100) Javier Martin (9): media: ov7670: add support for ov7675. media: ov7670: make try_fmt() consistent with 'min_height' and 'min_width'. media: ov7670: calculate framerate properly for ov7675. media: ov7670: add possibility to bypass pll for ov7675. media: ov7670: Add possibility to disable pixclk during hblank. ov7670: use the control framework. mcam-core: implement the control framework. via-camera: implement the control framework. ov7670: remove legacy ctrl callbacks. drivers/media/i2c/ov7670.c | 587 +-- drivers/media/platform/marvell-ccic/mcam-core.c | 54 +-- drivers/media/platform/marvell-ccic/mcam-core.h |2 + drivers/media/platform/via-camera.c | 60 +-- include/media/ov7670.h |2 + 5 files changed, 369 insertions(+), 336 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Q] Querying Y/Gb Average Level in a sensor.
Hi, ov7670 and ov7675 sensors have the possibility of querying the average value of the Y/Cb components of the image reading a register. This could be useful for applications such as calise [1]. This program grabs frames from a video camera, calculates the average brightness and then adjusts screen's backlight accordingly. If the user could query the value of this register t in cameras that support it we could save a lot of processing effort. The first idea that came into my mind was to define a new v4l2-ctrl for this but I'm not sure if it is a common feature in other sensors. Is it worth it to define a new v4l2-ctrl for this or should I use a private ctrl instead? Regards. [1] http://calise.sourceforge.net/wordpress/ -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] media: mx2_camera: Remove i.mx25 support.
Hi Fabio, Guennadi, sorry for the long delay but I've been out of the office for a month and without internet access. On 27 November 2012 14:05, Fabio Estevam feste...@gmail.com wrote: I just added the camera support to mach-mx25_3ds.c (which I will submit it soon to arm kernel list) and it works fine: soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 mx2-camera imx25-camera.0: Camera driver attached to camera 0 ov2640 0-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2 i2c i2c-0: OV2640 Probed mx2-camera imx25-camera.0: Camera driver detached from camera 0 mx2-camera imx25-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 2216 Could we please keep the mx25 support? That's great. Did you need to change anything in the mx2 camera driver for mx25 to work? Have you already submitted the patches? 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] media: mx2_camera: Remove i.mx25 support.
Hi Fabio, On 2 January 2013 13:25, Fabio Estevam feste...@gmail.com wrote: Hi Javier, On Wed, Jan 2, 2013 at 10:18 AM, javier Martin javier.mar...@vista-silicon.com wrote: That's great. Did you need to change anything in the mx2 camera driver for mx25 to work? Have you already submitted the patches? I only touched board file code: http://www.spinics.net/lists/arm-kernel/msg210216.html ,and have only verified that camera probe worked on mx25pdk. Sorry Fabio but IMHO that's not enough. The probe() callback may work properly but it doesn't mean that buffer and HW handling for i.MX25 are functional. The condition to keep i.MX25 support in this file was that you were going to fix it but instead you have just added board support for a broken driver. I'd like to hear Guennadi's view on the matter but I think we've given plenty of time for this. 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: i.MX27: Add platform support for IRAM.
On 16 November 2012 13:48, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Nov 05, 2012 at 04:59:44PM +0100, Javier Martin wrote:
Add support for IRAM to i.MX27 non-DT platforms using
iram_init() function.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-imx/mm-imx27.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-imx/mm-imx27.c b/arch/arm/mach-imx/mm-imx27.c
index e7e24af..fd2416d 100644
--- a/arch/arm/mach-imx/mm-imx27.c
+++ b/arch/arm/mach-imx/mm-imx27.c
@@ -27,6 +27,7 @@
#include asm/pgtable.h
#include asm/mach/map.h
#include mach/iomux-v1.h
+#include mach/iram.h
/* MX27 memory map definition */
static struct map_desc imx27_io_desc[] __initdata = {
@@ -94,4 +95,6 @@ void __init imx27_soc_init(void)
/* imx27 has the imx21 type audmux */
platform_device_register_simple(imx21-audmux, 0, imx27_audmux_res,
ARRAY_SIZE(imx27_audmux_res));
+ /* imx27 has an iram of 46080 bytes size */
+ iram_init(MX27_IRAM_BASE_ADDR, 46080);
For this rather Philipps sram allocater patches should be used. This
would also solve the problem that mach/iram.h cannot be accessed anymore
in current -next. Fabio already sent a patch addressing this, but I
think we should go for a proper fix rather than just moving iram.h
to include/linux/
Fine, I'll take a look at Philipps' patches.
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 this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: i.MX27: Add platform support for IRAM.
Add support for IRAM to i.MX27 non-DT platforms using
iram_init() function.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-imx/mm-imx27.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-imx/mm-imx27.c b/arch/arm/mach-imx/mm-imx27.c
index e7e24af..fd2416d 100644
--- a/arch/arm/mach-imx/mm-imx27.c
+++ b/arch/arm/mach-imx/mm-imx27.c
@@ -27,6 +27,7 @@
#include asm/pgtable.h
#include asm/mach/map.h
#include mach/iomux-v1.h
+#include mach/iram.h
/* MX27 memory map definition */
static struct map_desc imx27_io_desc[] __initdata = {
@@ -94,4 +95,6 @@ void __init imx27_soc_init(void)
/* imx27 has the imx21 type audmux */
platform_device_register_simple(imx21-audmux, 0, imx27_audmux_res,
ARRAY_SIZE(imx27_audmux_res));
+ /* imx27 has an iram of 46080 bytes size */
+ iram_init(MX27_IRAM_BASE_ADDR, 46080);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] media: coda: Use iram_alloc() for codadx6 too.
Use this helper function instead of hardcoding the
physical address of the IRAM in the i.MX27.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/coda.c | 18 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index ecab6ef..0b5f785 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1229,7 +1229,7 @@ config VIDEO_CODA
depends on VIDEO_DEV VIDEO_V4L2 ARCH_MXC
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
- select IRAM_ALLOC if SOC_IMX53
+ select IRAM_ALLOC
---help---
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
diff --git a/drivers/media/video/coda.c b/drivers/media/video/coda.c
index 7febcd9..96ecb3f 100644
--- a/drivers/media/video/coda.c
+++ b/drivers/media/video/coda.c
@@ -43,6 +43,7 @@
#define CODA_PARA_BUF_SIZE (10 * 1024)
#define CODA_ISRAM_SIZE(2048 * 2)
#define CODA7_IRAM_SIZE0x14000 /* 81920 bytes */
+#define CODADX6_IRAM_SIZE 45056
#define CODA_MAX_FRAMEBUFFERS 2
@@ -1919,6 +1920,8 @@ static int __devinit coda_probe(struct platform_device
*pdev)
const struct of_device_id *of_id =
of_match_device(of_match_ptr(coda_dt_ids), pdev-dev);
const struct platform_device_id *pdev_id;
+ void __iomem *iram_vaddr;
+ unsigned long iram_size;
struct coda_dev *dev;
struct resource *res;
int ret, irq;
@@ -2016,16 +2019,15 @@ static int __devinit coda_probe(struct platform_device
*pdev)
}
if (dev-devtype-product == CODA_DX6) {
- dev-iram_paddr = 0x4c00;
+ iram_size = CODADX6_IRAM_SIZE;
} else {
- void __iomem *iram_vaddr;
+ iram_size = CODA7_IRAM_SIZE;
+ }
- iram_vaddr = iram_alloc(CODA7_IRAM_SIZE,
- dev-iram_paddr);
- if (!iram_vaddr) {
- dev_err(pdev-dev, unable to alloc iram\n);
- return -ENOMEM;
- }
+ iram_vaddr = iram_alloc(iram_size, dev-iram_paddr);
+ if (!iram_vaddr) {
+ dev_err(pdev-dev, unable to alloc iram\n);
+ return -ENOMEM;
}
platform_set_drvdata(pdev, dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] media: mx2_camera: Remove i.mx25 and clean up.
[PATCH 1/4] media: mx2_camera: Remove i.mx25 support. [PATCH 2/4] media: mx2_camera: Add image size HW limits. [PATCH 3/4] media: mx2_camera: Remove 'buf_cleanup' callback. [PATCH 4/4] media: mx2_camera: Remove buffer states. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] media: mx2_camera: Remove i.mx25 support.
i.MX25 support has been broken for several releases
now and nobody seems to care about it.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/soc_camera/mx2_camera.c | 405 ++--
1 file changed, 100 insertions(+), 305 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 9fd9d1c..e1b44b1 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -1,5 +1,5 @@
/*
- * V4L2 Driver for i.MX27/i.MX25 camera host
+ * V4L2 Driver for i.MX27 camera host
*
* Copyright (C) 2008, Sascha Hauer, Pengutronix
* Copyright (C) 2010, Baruch Siach, Orex Computed Radiography
@@ -65,9 +65,7 @@
#define CSICR1_RF_OR_INTEN (1 24)
#define CSICR1_STATFF_LEVEL(3 22)
#define CSICR1_STATFF_INTEN(1 21)
-#define CSICR1_RXFF_LEVEL(l) (((l) 3) 19) /* MX27 */
-#define CSICR1_FB2_DMA_INTEN (1 20) /* MX25 */
-#define CSICR1_FB1_DMA_INTEN (1 19) /* MX25 */
+#define CSICR1_RXFF_LEVEL(l) (((l) 3) 19)
#define CSICR1_RXFF_INTEN (1 18)
#define CSICR1_SOF_POL (1 17)
#define CSICR1_SOF_INTEN (1 16)
@@ -92,11 +90,6 @@
/* control reg 3 */
#define CSICR3_FRMCNT (0x 16)
#define CSICR3_FRMCNT_RST (1 15)
-#define CSICR3_DMA_REFLASH_RFF (1 14)
-#define CSICR3_DMA_REFLASH_SFF (1 13)
-#define CSICR3_DMA_REQ_EN_RFF (1 12)
-#define CSICR3_DMA_REQ_EN_SFF (1 11)
-#define CSICR3_RXFF_LEVEL(l) (((l) 7) 4)/* MX25 */
#define CSICR3_CSI_SUP (1 3)
#define CSICR3_ZERO_PACK_EN(1 2)
#define CSICR3_ECC_INT_EN (1 1)
@@ -108,8 +101,6 @@
#define CSISR_SFF_OR_INT (1 25)
#define CSISR_RFF_OR_INT (1 24)
#define CSISR_STATFF_INT (1 21)
-#define CSISR_DMA_TSF_FB2_INT (1 20) /* MX25 */
-#define CSISR_DMA_TSF_FB1_INT (1 19) /* MX25 */
#define CSISR_RXFF_INT (1 18)
#define CSISR_EOF_INT (1 17)
#define CSISR_SOF_INT (1 16)
@@ -121,17 +112,11 @@
#define CSICR1 0x00
#define CSICR2 0x04
-#define CSISR (cpu_is_mx27() ? 0x08 : 0x18)
+#define CSISR 0x08
#define CSISTATFIFO0x0c
#define CSIRFIFO 0x10
#define CSIRXCNT 0x14
-#define CSICR3 (cpu_is_mx27() ? 0x1C : 0x08)
-#define CSIDMASA_STATFIFO 0x20
-#define CSIDMATA_STATFIFO 0x24
-#define CSIDMASA_FB1 0x28
-#define CSIDMASA_FB2 0x2c
-#define CSIFBUF_PARA 0x30
-#define CSIIMAG_PARA 0x34
+#define CSICR3 0x1C
/* EMMA PrP */
#define PRP_CNTL 0x00
@@ -430,20 +415,9 @@ static void mx27_update_emma_buf(struct mx2_camera_dev
*pcdev,
static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
{
- unsigned long flags;
-
clk_disable_unprepare(pcdev-clk_csi);
writel(0, pcdev-base_csi + CSICR1);
- if (cpu_is_mx27()) {
- writel(0, pcdev-base_emma + PRP_CNTL);
- } else if (cpu_is_mx25()) {
- spin_lock_irqsave(pcdev-lock, flags);
- pcdev-fb1_active = NULL;
- pcdev-fb2_active = NULL;
- writel(0, pcdev-base_csi + CSIDMASA_FB1);
- writel(0, pcdev-base_csi + CSIDMASA_FB2);
- spin_unlock_irqrestore(pcdev-lock, flags);
- }
+ writel(0, pcdev-base_emma + PRP_CNTL);
}
/*
@@ -464,10 +438,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
if (ret 0)
return ret;
- csicr1 = CSICR1_MCLKEN;
-
- if (cpu_is_mx27())
- csicr1 |= CSICR1_PRP_IF_EN | CSICR1_FCC |
+ csicr1 = CSICR1_MCLKEN | CSICR1_PRP_IF_EN | CSICR1_FCC |
CSICR1_RXFF_LEVEL(0);
pcdev-csicr1 = csicr1;
@@ -497,65 +468,6 @@ static void mx2_camera_remove_device(struct
soc_camera_device *icd)
pcdev-icd = NULL;
}
-static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb,
- int state)
-{
- struct vb2_buffer *vb;
- struct mx2_buffer *buf;
- struct mx2_buffer **fb_active = fb == 1 ? pcdev-fb1_active :
- pcdev-fb2_active;
- u32 fb_reg = fb == 1 ? CSIDMASA_FB1 : CSIDMASA_FB2;
- unsigned long flags;
-
- spin_lock_irqsave(pcdev-lock, flags);
-
- if (*fb_active == NULL)
- goto out;
-
- vb = (*fb_active)-vb;
- dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%p %lu\n, __func__,
- vb, vb2_plane_vaddr(vb, 0), vb2_get_plane_payload(vb, 0));
-
- do_gettimeofday(vb-v4l2_buf.timestamp);
- vb-v4l2_buf.sequence++;
- vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
-
- if (list_empty(pcdev-capture)) {
- buf = NULL;
- writel(0, pcdev-base_csi + fb_reg);
- } else
[PATCH 2/4] media: mx2_camera: Add image size HW limits.
The CSI has some constraints regarding image with. This patch makes sure those requirements are met in try_fmt(). Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/platform/soc_camera/mx2_camera.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/mx2_camera.c b/drivers/media/platform/soc_camera/mx2_camera.c index e1b44b1..bf1178c 100644 --- a/drivers/media/platform/soc_camera/mx2_camera.c +++ b/drivers/media/platform/soc_camera/mx2_camera.c @@ -1234,7 +1234,11 @@ static int mx2_camera_try_fmt(struct soc_camera_device *icd, return -EINVAL; } - /* FIXME: implement MX27 limits */ + /* +* With must be multiple of 8 as requested by the CSI. +* (Table 39-2 in the i.MX27 Reference Manual). +*/ + pix-width = ~0x7; /* limit to sensor capabilities */ mf.width= pix-width; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] media: mx2_camera: Remove 'buf_cleanup' callback.
All necessary tasks to end the streaming properly are
already implemented in mx2_stop_streaming() and nothing
remains to be done in this callback.
Furthermore, it only included debug messages so it can
be removed.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/soc_camera/mx2_camera.c | 34
1 file changed, 34 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index bf1178c..8202cb9 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -551,39 +551,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(pcdev-lock, flags);
}
-static void mx2_videobuf_release(struct vb2_buffer *vb)
-{
-#ifdef DEBUG
- struct soc_camera_device *icd = soc_camera_from_vb2q(vb-vb2_queue);
- struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
- struct mx2_camera_dev *pcdev = ici-priv;
- struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
-
- dev_dbg(icd-parent, %s (vb=0x%p) 0x%p %lu\n, __func__,
- vb, vb2_plane_vaddr(vb, 0), vb2_get_plane_payload(vb, 0));
-
- switch (buf-state) {
- case MX2_STATE_ACTIVE:
- dev_info(icd-parent, %s (active)\n, __func__);
- break;
- case MX2_STATE_QUEUED:
- dev_info(icd-parent, %s (queued)\n, __func__);
- break;
- default:
- dev_info(icd-parent, %s (unknown) %d\n, __func__,
- buf-state);
- break;
- }
-#endif
-
- /*
-* FIXME: implement forced termination of active buffers for mx27 and
-* mx27 eMMA, so that the user won't get stuck in an uninterruptible
-* state. This requires a specific handling for each of the these DMA
-* types.
-*/
-}
-
static void mx27_camera_emma_buf_init(struct soc_camera_device *icd,
int bytesperline)
{
@@ -814,7 +781,6 @@ static struct vb2_ops mx2_videobuf_ops = {
.queue_setup = mx2_videobuf_setup,
.buf_prepare = mx2_videobuf_prepare,
.buf_queue = mx2_videobuf_queue,
- .buf_cleanup = mx2_videobuf_release,
.start_streaming = mx2_start_streaming,
.stop_streaming = mx2_stop_streaming,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] media: mx2_camera: Remove buffer states.
After removing i.mx25 support and buf_cleanup() callback,
buffer states are not used in the code any longer.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/soc_camera/mx2_camera.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 8202cb9..a672475 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -233,12 +233,6 @@ struct mx2_fmt_cfg {
struct mx2_prp_cfg cfg;
};
-enum mx2_buffer_state {
- MX2_STATE_QUEUED,
- MX2_STATE_ACTIVE,
- MX2_STATE_DONE,
-};
-
struct mx2_buf_internal {
struct list_headqueue;
int bufnum;
@@ -249,7 +243,6 @@ struct mx2_buf_internal {
struct mx2_buffer {
/* common v4l buffer stuff -- must be first */
struct vb2_buffer vb;
- enum mx2_buffer_state state;
struct mx2_buf_internal internal;
};
@@ -545,7 +538,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
spin_lock_irqsave(pcdev-lock, flags);
- buf-state = MX2_STATE_QUEUED;
list_add_tail(buf-internal.queue, pcdev-capture);
spin_unlock_irqrestore(pcdev-lock, flags);
@@ -669,7 +661,6 @@ static int mx2_start_streaming(struct vb2_queue *q,
unsigned int count)
internal.queue);
buf-internal.bufnum = 0;
vb = buf-vb;
- buf-state = MX2_STATE_ACTIVE;
phys = vb2_dma_contig_plane_dma_addr(vb, 0);
mx27_update_emma_buf(pcdev, phys, buf-internal.bufnum);
@@ -679,7 +670,6 @@ static int mx2_start_streaming(struct vb2_queue *q,
unsigned int count)
internal.queue);
buf-internal.bufnum = 1;
vb = buf-vb;
- buf-state = MX2_STATE_ACTIVE;
phys = vb2_dma_contig_plane_dma_addr(vb, 0);
mx27_update_emma_buf(pcdev, phys, buf-internal.bufnum);
@@ -1368,7 +1358,6 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_move_tail(pcdev-capture.next, pcdev-active_bufs);
vb = buf-vb;
- buf-state = MX2_STATE_ACTIVE;
phys = vb2_dma_contig_plane_dma_addr(vb, 0);
mx27_update_emma_buf(pcdev, phys, bufnum);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] media: mx2_camera: Remove i.mx25 support.
Hi Guennadi, Fabio, On 30 October 2012 13:29, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 30 Oct 2012, Fabio Estevam wrote: Javier, On Tue, Oct 30, 2012 at 10:16 AM, Javier Martin javier.mar...@vista-silicon.com wrote: i.MX25 support has been broken for several releases now and nobody seems to care about it. I will work on fixing camera support for mx25. Please do not remove its support. This is good to hear, thanks for doing this! But we also don't want to slow down Javier's work, if he works on features, only available on i.MX27 or that he can only test there. How about separating parts of code, specific to each platform more cleanly? Maybe add an mx27_camera.c file to build the final driver from both files and mx27 and only from one on mx25? Or something similar? Would this be difficult or make sense at all? It's pretty good that you want to provide proper support for video capture on mx25 but I am still in favour of applying this patch for several reasons: 1. i.mx25 support is so broken now that it would be better to start from scratch IMHO. 2. AFAIK mx25 is not provided with an eMMa-PrP module. The current mx2_camera driver relies on this module to perform DMA transfers. If we added support for i.MX25 in this file, we'd have to use generic DMAs again, which is something we already removed in the past. 3. CSI provided in i.mx25 has more features than the one in the i.MX27, so the code they possibly share is even more reduced. By the way, removal of all i.mx25 traces in this file was announced several times in the past: 9 Jul 2012 [PATCH] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c 26 Jul 2012 [PATCH 2/4] media: mx2_camera: Mark i.MX25 support as BROKEN. [PATCH 3/4] Schedule removal of i.MX25 support in mx2_camera.c In my opinion. i.mx25 video capture support should be added in a separate file later. Though some CSI features are common, the lack of eMMa-PrP in i.mx25 will make the driver be very different. Please, expect a v2 of this patch soon. I've just remembered that I missed removing i.MX25 traces from the Kconfig file too. 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] media: mx2_camera: Remove i.mx25 and clean up.
Changes since v1: - Remove i.MX25 support in the Kconfig file too in patch 1. [PATCH v2 1/4] media: mx2_camera: Remove i.mx25 support. [PATCH v2 2/4] media: mx2_camera: Add image size HW limits. [PATCH v2 3/4] media: mx2_camera: Remove 'buf_cleanup' callback. [PATCH v2 4/4] media: mx2_camera: Remove buffer states. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] media: mx2_camera: Remove i.mx25 support.
i.MX25 support has been broken for several releases
now and nobody seems to care about it.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/soc_camera/Kconfig |7 +-
drivers/media/platform/soc_camera/mx2_camera.c | 405 ++--
2 files changed, 103 insertions(+), 309 deletions(-)
diff --git a/drivers/media/platform/soc_camera/Kconfig
b/drivers/media/platform/soc_camera/Kconfig
index 9afe1e7..9e006e0 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -69,13 +69,12 @@ config VIDEO_MX2_HOSTSUPPORT
bool
config VIDEO_MX2
- tristate i.MX27/i.MX25 Camera Sensor Interface driver
- depends on VIDEO_DEV SOC_CAMERA (MACH_MX27 || (ARCH_MX25
BROKEN))
+ tristate i.MX27 Camera Sensor Interface driver
+ depends on VIDEO_DEV SOC_CAMERA MACH_MX27
select VIDEOBUF2_DMA_CONTIG
select VIDEO_MX2_HOSTSUPPORT
---help---
- This is a v4l2 driver for the i.MX27 and the i.MX25 Camera Sensor
- Interface
+ This is a v4l2 driver for the i.MX27 Camera Sensor Interface
config VIDEO_ATMEL_ISI
tristate ATMEL Image Sensor Interface (ISI) support
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 9fd9d1c..e1b44b1 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -1,5 +1,5 @@
/*
- * V4L2 Driver for i.MX27/i.MX25 camera host
+ * V4L2 Driver for i.MX27 camera host
*
* Copyright (C) 2008, Sascha Hauer, Pengutronix
* Copyright (C) 2010, Baruch Siach, Orex Computed Radiography
@@ -65,9 +65,7 @@
#define CSICR1_RF_OR_INTEN (1 24)
#define CSICR1_STATFF_LEVEL(3 22)
#define CSICR1_STATFF_INTEN(1 21)
-#define CSICR1_RXFF_LEVEL(l) (((l) 3) 19) /* MX27 */
-#define CSICR1_FB2_DMA_INTEN (1 20) /* MX25 */
-#define CSICR1_FB1_DMA_INTEN (1 19) /* MX25 */
+#define CSICR1_RXFF_LEVEL(l) (((l) 3) 19)
#define CSICR1_RXFF_INTEN (1 18)
#define CSICR1_SOF_POL (1 17)
#define CSICR1_SOF_INTEN (1 16)
@@ -92,11 +90,6 @@
/* control reg 3 */
#define CSICR3_FRMCNT (0x 16)
#define CSICR3_FRMCNT_RST (1 15)
-#define CSICR3_DMA_REFLASH_RFF (1 14)
-#define CSICR3_DMA_REFLASH_SFF (1 13)
-#define CSICR3_DMA_REQ_EN_RFF (1 12)
-#define CSICR3_DMA_REQ_EN_SFF (1 11)
-#define CSICR3_RXFF_LEVEL(l) (((l) 7) 4)/* MX25 */
#define CSICR3_CSI_SUP (1 3)
#define CSICR3_ZERO_PACK_EN(1 2)
#define CSICR3_ECC_INT_EN (1 1)
@@ -108,8 +101,6 @@
#define CSISR_SFF_OR_INT (1 25)
#define CSISR_RFF_OR_INT (1 24)
#define CSISR_STATFF_INT (1 21)
-#define CSISR_DMA_TSF_FB2_INT (1 20) /* MX25 */
-#define CSISR_DMA_TSF_FB1_INT (1 19) /* MX25 */
#define CSISR_RXFF_INT (1 18)
#define CSISR_EOF_INT (1 17)
#define CSISR_SOF_INT (1 16)
@@ -121,17 +112,11 @@
#define CSICR1 0x00
#define CSICR2 0x04
-#define CSISR (cpu_is_mx27() ? 0x08 : 0x18)
+#define CSISR 0x08
#define CSISTATFIFO0x0c
#define CSIRFIFO 0x10
#define CSIRXCNT 0x14
-#define CSICR3 (cpu_is_mx27() ? 0x1C : 0x08)
-#define CSIDMASA_STATFIFO 0x20
-#define CSIDMATA_STATFIFO 0x24
-#define CSIDMASA_FB1 0x28
-#define CSIDMASA_FB2 0x2c
-#define CSIFBUF_PARA 0x30
-#define CSIIMAG_PARA 0x34
+#define CSICR3 0x1C
/* EMMA PrP */
#define PRP_CNTL 0x00
@@ -430,20 +415,9 @@ static void mx27_update_emma_buf(struct mx2_camera_dev
*pcdev,
static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
{
- unsigned long flags;
-
clk_disable_unprepare(pcdev-clk_csi);
writel(0, pcdev-base_csi + CSICR1);
- if (cpu_is_mx27()) {
- writel(0, pcdev-base_emma + PRP_CNTL);
- } else if (cpu_is_mx25()) {
- spin_lock_irqsave(pcdev-lock, flags);
- pcdev-fb1_active = NULL;
- pcdev-fb2_active = NULL;
- writel(0, pcdev-base_csi + CSIDMASA_FB1);
- writel(0, pcdev-base_csi + CSIDMASA_FB2);
- spin_unlock_irqrestore(pcdev-lock, flags);
- }
+ writel(0, pcdev-base_emma + PRP_CNTL);
}
/*
@@ -464,10 +438,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
if (ret 0)
return ret;
- csicr1 = CSICR1_MCLKEN;
-
- if (cpu_is_mx27())
- csicr1 |= CSICR1_PRP_IF_EN | CSICR1_FCC |
+ csicr1 = CSICR1_MCLKEN | CSICR1_PRP_IF_EN | CSICR1_FCC |
CSICR1_RXFF_LEVEL(0);
pcdev-csicr1 = csicr1;
@@ -497,65 +468,6 @@ static void mx2_camera_remove_device(struct
[PATCH v2 2/4] media: mx2_camera: Add image size HW limits.
The CSI has some constraints regarding image with. This patch makes sure those requirements are met in try_fmt(). Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/platform/soc_camera/mx2_camera.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/mx2_camera.c b/drivers/media/platform/soc_camera/mx2_camera.c index e1b44b1..bf1178c 100644 --- a/drivers/media/platform/soc_camera/mx2_camera.c +++ b/drivers/media/platform/soc_camera/mx2_camera.c @@ -1234,7 +1234,11 @@ static int mx2_camera_try_fmt(struct soc_camera_device *icd, return -EINVAL; } - /* FIXME: implement MX27 limits */ + /* +* With must be multiple of 8 as requested by the CSI. +* (Table 39-2 in the i.MX27 Reference Manual). +*/ + pix-width = ~0x7; /* limit to sensor capabilities */ mf.width= pix-width; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] media: mx2_camera: Remove 'buf_cleanup' callback.
All necessary tasks to end the streaming properly are
already implemented in mx2_stop_streaming() and nothing
remains to be done in this callback.
Furthermore, it only included debug messages so it can
be removed.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/soc_camera/mx2_camera.c | 34
1 file changed, 34 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index bf1178c..8202cb9 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -551,39 +551,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(pcdev-lock, flags);
}
-static void mx2_videobuf_release(struct vb2_buffer *vb)
-{
-#ifdef DEBUG
- struct soc_camera_device *icd = soc_camera_from_vb2q(vb-vb2_queue);
- struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
- struct mx2_camera_dev *pcdev = ici-priv;
- struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
-
- dev_dbg(icd-parent, %s (vb=0x%p) 0x%p %lu\n, __func__,
- vb, vb2_plane_vaddr(vb, 0), vb2_get_plane_payload(vb, 0));
-
- switch (buf-state) {
- case MX2_STATE_ACTIVE:
- dev_info(icd-parent, %s (active)\n, __func__);
- break;
- case MX2_STATE_QUEUED:
- dev_info(icd-parent, %s (queued)\n, __func__);
- break;
- default:
- dev_info(icd-parent, %s (unknown) %d\n, __func__,
- buf-state);
- break;
- }
-#endif
-
- /*
-* FIXME: implement forced termination of active buffers for mx27 and
-* mx27 eMMA, so that the user won't get stuck in an uninterruptible
-* state. This requires a specific handling for each of the these DMA
-* types.
-*/
-}
-
static void mx27_camera_emma_buf_init(struct soc_camera_device *icd,
int bytesperline)
{
@@ -814,7 +781,6 @@ static struct vb2_ops mx2_videobuf_ops = {
.queue_setup = mx2_videobuf_setup,
.buf_prepare = mx2_videobuf_prepare,
.buf_queue = mx2_videobuf_queue,
- .buf_cleanup = mx2_videobuf_release,
.start_streaming = mx2_start_streaming,
.stop_streaming = mx2_stop_streaming,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] media: mx2_camera: Remove buffer states.
After removing i.mx25 support and buf_cleanup() callback,
buffer states are not used in the code any longer.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/soc_camera/mx2_camera.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 8202cb9..a672475 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -233,12 +233,6 @@ struct mx2_fmt_cfg {
struct mx2_prp_cfg cfg;
};
-enum mx2_buffer_state {
- MX2_STATE_QUEUED,
- MX2_STATE_ACTIVE,
- MX2_STATE_DONE,
-};
-
struct mx2_buf_internal {
struct list_headqueue;
int bufnum;
@@ -249,7 +243,6 @@ struct mx2_buf_internal {
struct mx2_buffer {
/* common v4l buffer stuff -- must be first */
struct vb2_buffer vb;
- enum mx2_buffer_state state;
struct mx2_buf_internal internal;
};
@@ -545,7 +538,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
spin_lock_irqsave(pcdev-lock, flags);
- buf-state = MX2_STATE_QUEUED;
list_add_tail(buf-internal.queue, pcdev-capture);
spin_unlock_irqrestore(pcdev-lock, flags);
@@ -669,7 +661,6 @@ static int mx2_start_streaming(struct vb2_queue *q,
unsigned int count)
internal.queue);
buf-internal.bufnum = 0;
vb = buf-vb;
- buf-state = MX2_STATE_ACTIVE;
phys = vb2_dma_contig_plane_dma_addr(vb, 0);
mx27_update_emma_buf(pcdev, phys, buf-internal.bufnum);
@@ -679,7 +670,6 @@ static int mx2_start_streaming(struct vb2_queue *q,
unsigned int count)
internal.queue);
buf-internal.bufnum = 1;
vb = buf-vb;
- buf-state = MX2_STATE_ACTIVE;
phys = vb2_dma_contig_plane_dma_addr(vb, 0);
mx27_update_emma_buf(pcdev, phys, buf-internal.bufnum);
@@ -1368,7 +1358,6 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_move_tail(pcdev-capture.next, pcdev-active_bufs);
vb = buf-vb;
- buf-state = MX2_STATE_ACTIVE;
phys = vb2_dma_contig_plane_dma_addr(vb, 0);
mx27_update_emma_buf(pcdev, phys, bufnum);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: m2m-deinterlace: Do not set debugging flag to true.
Default value should be 'debugging disabled'. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/platform/m2m-deinterlace.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/m2m-deinterlace.c b/drivers/media/platform/m2m-deinterlace.c index 1107167..931d580 100644 --- a/drivers/media/platform/m2m-deinterlace.c +++ b/drivers/media/platform/m2m-deinterlace.c @@ -28,7 +28,7 @@ MODULE_AUTHOR(Javier Martin javier.mar...@vista-silicon.com); MODULE_LICENSE(GPL); MODULE_VERSION(0.0.1); -static bool debug = true; +static bool debug; module_param(debug, bool, 0644); /* Flags that indicate a format can be used for capture/output */ -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] media: mx2_camera: Remove i.mx25 support.
On 30 October 2012 15:57, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 30 Oct 2012, javier Martin wrote: Hi Guennadi, Fabio, On 30 October 2012 13:29, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 30 Oct 2012, Fabio Estevam wrote: Javier, On Tue, Oct 30, 2012 at 10:16 AM, Javier Martin javier.mar...@vista-silicon.com wrote: i.MX25 support has been broken for several releases now and nobody seems to care about it. I will work on fixing camera support for mx25. Please do not remove its support. This is good to hear, thanks for doing this! But we also don't want to slow down Javier's work, if he works on features, only available on i.MX27 or that he can only test there. How about separating parts of code, specific to each platform more cleanly? Maybe add an mx27_camera.c file to build the final driver from both files and mx27 and only from one on mx25? Or something similar? Would this be difficult or make sense at all? It's pretty good that you want to provide proper support for video capture on mx25 but I am still in favour of applying this patch for several reasons: Fabio, I wasn't in favour of removing mx25 support initially and I still don't quite fancy it, but the delta is getting too large. If we remove it now you still have the git history, so, you'll be able to restore the latest state before removal. OTOH, it would be easier for me to review a 50-line fix patch, than a 400-line revert-and-fix patch, so, this has an adbantage too. Let's try the following: I'm away the whole next week, so, I'll wait for your patches for almost 2 weeks until around 10.11. If you don't manage to fix the driver until then, we remove mx25 support to have it re-added later. What do you think? Please, consider adding support for i.MX25 in a separate file. Just take a look at the mess we had in 3.1: http://lxr.linux.no/#linux+v3.1/drivers/media/video/mx2_camera.c Regards. Thanks Guennadi 1. i.mx25 support is so broken now that it would be better to start from scratch IMHO. 2. AFAIK mx25 is not provided with an eMMa-PrP module. The current mx2_camera driver relies on this module to perform DMA transfers. If we added support for i.MX25 in this file, we'd have to use generic DMAs again, which is something we already removed in the past. 3. CSI provided in i.mx25 has more features than the one in the i.MX27, so the code they possibly share is even more reduced. By the way, removal of all i.mx25 traces in this file was announced several times in the past: 9 Jul 2012 [PATCH] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c 26 Jul 2012 [PATCH 2/4] media: mx2_camera: Mark i.MX25 support as BROKEN. [PATCH 3/4] Schedule removal of i.MX25 support in mx2_camera.c In my opinion. i.mx25 video capture support should be added in a separate file later. Though some CSI features are common, the lack of eMMa-PrP in i.mx25 will make the driver be very different. Please, expect a v2 of this patch soon. I've just remembered that I missed removing i.MX25 traces from the Kconfig file too. 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: ov7670: Allow 32x maximum gain for yuv422.
4x gain ceiling is not enough to capture a decent image in conditions
of total darkness and only a LED light source. Allow a maximum gain
of 32x instead.
This doesn't have any drawback since the image quality in 'normal'
light conditions is the same.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/ov7670.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 5faa3d8..2ea9c51 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -366,7 +366,7 @@ static struct regval_list ov7670_fmt_yuv422[] = {
{ REG_RGB444, 0 }, /* No RGB444 please */
{ REG_COM1, 0 },/* CCIR601 */
{ REG_COM15, COM15_R00FF },
- { REG_COM9, 0x18 }, /* 4x gain ceiling; 0x8 is reserved bit */
+ { REG_COM9, 0x48 }, /* 32x gain ceiling; 0x8 is reserved bit */
{ 0x4f, 0x80 }, /* matrix coefficient 1 */
{ 0x50, 0x80 }, /* matrix coefficient 2 */
{ 0x51, 0}, /* vb */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: coda: Fix H.264 header alignment.
From: Javier Martin javier.mar...@vista-silicon.com
Length of H.264 headers is variable and thus it might not be
aligned for the coda to append the encoded frame. This causes
the first frame to overwrite part of the H.264 PPS.
In order to solve that, a filler NAL must be added between
the headers and the first frame to preserve alignment.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/coda.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index a8c7a94..4cdb4f4 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -177,6 +177,8 @@ struct coda_ctx {
int idx;
};
+static u8 coda_filler_nal[] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff, 0xff,
0xff, 0xff, 0xff};
+
static inline void coda_write(struct coda_dev *dev, u32 data, u32 reg)
{
v4l2_dbg(1, coda_debug, dev-v4l2_dev,
@@ -938,6 +940,29 @@ static int coda_alloc_framebuffers(struct coda_ctx *ctx,
struct coda_q_data *q_d
return 0;
}
+static int coda_h264_padding(int size, char *p)
+{
+ int size_align = size ~0x3;
+ int filler_size = ARRAY_SIZE(coda_filler_nal);
+ int nal_size;
+ int diff;
+
+ diff = size - size_align;
+ if (diff == 0)
+ return 0;
+
+ nal_size = filler_size + 2 - diff;
+ if (nal_size filler_size)
+ nal_size -= 4;
+
+ memcpy(p, coda_filler_nal, nal_size);
+
+ /* Add rbsp stop bit and trailing at the end */
+ *(p + nal_size - 1) = 0x80;
+
+ return nal_size;
+}
+
static int coda_start_streaming(struct vb2_queue *q, unsigned int count)
{
struct coda_ctx *ctx = vb2_get_drv_priv(q);
@@ -1165,7 +1190,13 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
coda_read(dev, CODA_CMD_ENC_HEADER_BB_START);
memcpy(ctx-vpu_header[1][0], vb2_plane_vaddr(buf, 0),
ctx-vpu_header_size[1]);
- ctx-vpu_header_size[2] = 0;
+ /*
+* Length of H.264 headers is variable and thus it might not be
+* aligned for the coda to append the encoded frame. In that is
+* the case a filler NAL must be added to header 2.
+*/
+ ctx-vpu_header_size[2] =
coda_h264_padding((ctx-vpu_header_size[0] +
+ ctx-vpu_header_size[1]),
ctx-vpu_header[2]);
break;
case V4L2_PIX_FMT_MPEG4:
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: coda: Fix H.264 header alignment.
From: Javier Martin javier.mar...@vista-silicon.com
Length of H.264 headers is variable and thus it might not be
aligned for the coda to append the encoded frame. This causes
the first frame to overwrite part of the H.264 PPS.
In order to solve that, a filler NAL must be added between
the headers and the first frame to preserve alignment.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Align to 64bits as requested by Philipp.
---
drivers/media/platform/coda.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index a8c7a94..7febcd9 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -177,6 +177,10 @@ struct coda_ctx {
int idx;
};
+static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x80 };
+static const u8 coda_filler_size[8] = { 0, 7, 14, 13, 12, 11, 10, 9 };
+
static inline void coda_write(struct coda_dev *dev, u32 data, u32 reg)
{
v4l2_dbg(1, coda_debug, dev-v4l2_dev,
@@ -938,6 +942,24 @@ static int coda_alloc_framebuffers(struct coda_ctx *ctx,
struct coda_q_data *q_d
return 0;
}
+static int coda_h264_padding(int size, char *p)
+{
+ int nal_size;
+ int diff;
+
+ diff = size - (size ~0x7);
+ if (diff == 0)
+ return 0;
+
+ nal_size = coda_filler_size[diff];
+ memcpy(p, coda_filler_nal, nal_size);
+
+ /* Add rbsp stop bit and trailing at the end */
+ *(p + nal_size - 1) = 0x80;
+
+ return nal_size;
+}
+
static int coda_start_streaming(struct vb2_queue *q, unsigned int count)
{
struct coda_ctx *ctx = vb2_get_drv_priv(q);
@@ -1165,7 +1187,13 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
coda_read(dev, CODA_CMD_ENC_HEADER_BB_START);
memcpy(ctx-vpu_header[1][0], vb2_plane_vaddr(buf, 0),
ctx-vpu_header_size[1]);
- ctx-vpu_header_size[2] = 0;
+ /*
+* Length of H.264 headers is variable and thus it might not be
+* aligned for the coda to append the encoded frame. In that is
+* the case a filler NAL must be added to header 2.
+*/
+ ctx-vpu_header_size[2] =
coda_h264_padding((ctx-vpu_header_size[0] +
+ ctx-vpu_header_size[1]),
ctx-vpu_header[2]);
break;
case V4L2_PIX_FMT_MPEG4:
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] video_visstrim staging/ov7670_for_v3.7
Hi Mauro, since there was some confusion regarding my two last series for the ov7670 I've decided to send this pull request to make things more clear and avoid merging order issues. It should apply properly in your current tree. The following changes since commit 1534e55974c7e2f57623457c0f6b4108c6ef4776: media: coda: Add Philipp's patches. (2012-09-24 17:30:53 +0200) are available in the git repository at: https://github.com/jmartinc/video_visstrim.git staging/ov7670_for_v3.7 for you to fetch changes up to 5a594e1b96d3363aedf74d9bd37a2d669beab0bc: ov7670: remove legacy ctrl callbacks. (2012-09-28 13:18:23 +0200) Javier Martin (9): media: ov7670: add support for ov7675. media: ov7670: make try_fmt() consistent with 'min_height' and 'min_width'. media: ov7670: calculate framerate properly for ov7675. media: ov7670: add possibility to bypass pll for ov7675. media: ov7670: Add possibility to disable pixclk during hblank. ov7670: use the control framework mcam-core: implement the control framework. via-camera: implement the control framework. ov7670: remove legacy ctrl callbacks. drivers/media/i2c/ov7670.c | 587 +-- drivers/media/platform/marvell-ccic/mcam-core.c | 54 +-- drivers/media/platform/marvell-ccic/mcam-core.h |2 + drivers/media/platform/via-camera.c | 60 +-- include/media/ov7670.h |2 + 5 files changed, 369 insertions(+), 336 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674.
Hi Mauro, On 25 October 2012 18:18, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 25 Oct 2012 15:24:49 +0200 javier Martin javier.mar...@vista-silicon.com escreveu: Hi Mauro, do you have any problems with this series? It didn't apply here, maybe due to its dependency from your previous ov7670 (v3) series. You have to apply this series first. Then the other one. From my side, feel free to rebase them and re-submit. -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] ov7670: migrate this sensor and its users to ctrl framework.
Hi Mauro, On 25 October 2012 17:50, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Javier, Em Thu, 25 Oct 2012 15:27:08 +0200 javier Martin javier.mar...@vista-silicon.com escreveu: Hi Mauro, Jon, any more issues related with this series? Patch doesn't apply anymore: patching file drivers/media/i2c/ov7670.c Hunk #2 succeeded at 191 (offset -32 lines). Hunk #3 succeeded at 220 (offset -35 lines). Hunk #4 succeeded at 1062 (offset -153 lines). Hunk #5 succeeded at 1091 (offset -153 lines). Hunk #6 succeeded at 1127 (offset -153 lines). Hunk #7 succeeded at 1147 (offset -153 lines). Hunk #8 succeeded at 1195 (offset -153 lines). Hunk #9 succeeded at 1211 (offset -153 lines). Hunk #10 succeeded at 1237 (offset -153 lines). Hunk #11 succeeded at 1255 (offset -153 lines). Hunk #12 succeeded at 1351 (offset -153 lines). Hunk #13 FAILED at 1605. Hunk #14 FAILED at 1616. Hunk #15 succeeded at 1434 (offset -189 lines). 2 out of 15 hunks FAILED -- rejects in file drivers/media/i2c/ov7670.c Could you please rebase it? I tried to force its merge, but it seemed that the conflicts are not that trivial, so I prefer if you could do it and test if everything still applies. You need to apply the series in the following order: Firstly: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674. Secondly: [PATCH v3 0/4] ov7670: migrate this sensor and its users to ctrl framework. This shouldn't cause any troubles. Otherwise, please let me know. 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674.
Hi Mauro, do you have any problems with this series? Regards. On 29 September 2012 21:20, Jonathan Corbet cor...@lwn.net wrote: On Thu, 27 Sep 2012 17:38:20 +0200 Javier Martin javier.mar...@vista-silicon.com wrote: 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 in [1]. I'd have preferred to avoid the unrelated white space changes in #1, but so be it; you can put my Acked-by on the whole set. Thanks, jon -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] ov7670: migrate this sensor and its users to ctrl framework.
Hi Mauro, Jon, any more issues related with this series? Regards. On 29 September 2012 21:25, Jonathan Corbet cor...@lwn.net wrote: On Fri, 28 Sep 2012 13:26:39 +0200 Javier Martin javier.mar...@vista-silicon.com wrote: 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. Looking over the code, I can't really find much to get grumpy about. Certainly I like how it removes more code than it adds. I'm not really up on the control framework, though. What's really needed is to see this code actually work on the relevant systems. I will *try* to do that testing, but it's going to take a little while; I don't think I can do it by the 3.7 merge window. Mauro willing, perhaps it can go in this time around anyway with the idea that we can sort out any little difficulties after -rc1. jon -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
On 23 October 2012 00:17, Fabio Estevam feste...@gmail.com wrote: Hi Guennadi On Mon, Oct 22, 2012 at 7:07 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ? I don't find a clock named per and associated with mx2-camera.0 in arch/arm/mach-imx/clk-imx27.c. I only find it in clk-imx25.c. 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 - 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] coda: Do not use __cancel_delayed_work()
On 10 October 2012 05:43, Tejun Heo t...@kernel.org wrote: On Wed, Oct 10, 2012 at 12:33:29AM -0300, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com commit 136b5721d (workqueue: deprecate __cancel_delayed_work()) made __cancel_delayed_work deprecated. Use cancel_delayed_work instead and get rid of the following warning: drivers/media/platform/coda.c:1543: warning: '__cancel_delayed_work' is deprecated (declared at include/linux/workqueue.h:437) Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Tejun Heo t...@kernel.org Thanks! -- 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 unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
*pdev) clk_disable_unprepare(pcdev-clk_emma_ahb); } + clk_disable_unprepare(pcdev-clk_csi_per); + clk_disable_unprepare(pcdev-clk_csi_ahb); + dev_info(pdev-dev, MX2 Camera driver unloaded\n); return 0; -- 1.7.9.5 This patch doesn't fix the BUG it claims to, since I have it working properly in our Visstrim M10 platform without it. Look: soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 mx2-camera mx2-camera.0: Camera driver attached to camera 0 ov7670 0-0021: chip found @ 0x42 (imx-i2c) [..] mx2-camera mx2-camera.0: Camera driver detached from camera 0 mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 6650 Furthermore, it's not correct, since there isn't such per clock for the CSI in 3.5 [1], 3.6 [2], linux-next-20121008[3], or next-20121009[4]. [1] http://lxr.linux.no/#linux+v3.5/arch/arm/mach-imx/clk-imx27.c#L226 [2] http://lxr.linux.no/#linux+v3.6/arch/arm/mach-imx/clk-imx27.c#L226 [3] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=arch/arm/mach-imx/clk-imx27.c;h=3b6b640eed247ea1b7848c7a7fa01801f0190cde;hb=cc925138a0dd9ae388135bb3cf11ee1729f9c4e9#l226 [4] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=arch/arm/mach-imx/clk-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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
__devexit mx2_camera_remove(struct platform_device *pdev) clk_disable_unprepare(pcdev-clk_emma_ahb); } + clk_disable_unprepare(pcdev-clk_csi_per); + clk_disable_unprepare(pcdev-clk_csi_ahb); + dev_info(pdev-dev, MX2 Camera driver unloaded\n); return 0; I only test detection at kernel boot not streaming using Gstreamer due to lack of time. On imx27_3ds board with ov2640 sensor: ov2640 0-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2 mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 4433 On clone imx27_3ds board with mt9v111 sensor (draft driver): mt9v111 0-0048: Detected a MT9V111 chip ID 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 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
On 5 October 2012 23:53, Fabio Estevam fabio.este...@freescale.com wrote: During the clock conversion for mx27 the per4_gate clock was missed to get registered as a dependency of mx2-camera driver. In the old mx27 clock driver we used to have: DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, csi_clk1, per4_clk); ,so does the same in the new clock driver. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- arch/arm/mach-imx/clk-imx27.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c index 3b6b640..5ef0f08 100644 --- a/arch/arm/mach-imx/clk-imx27.c +++ b/arch/arm/mach-imx/clk-imx27.c @@ -224,6 +224,7 @@ int __init mx27_clocks_init(unsigned long fref) clk_register_clkdev(clk[lcdc_ipg_gate], ipg, imx-fb.0); clk_register_clkdev(clk[lcdc_ahb_gate], ahb, imx-fb.0); clk_register_clkdev(clk[csi_ahb_gate], ahb, mx2-camera.0); + clk_register_clkdev(clk[per4_gate], per, mx2-camera.0); clk_register_clkdev(clk[usb_div], per, fsl-usb2-udc); clk_register_clkdev(clk[usb_ipg_gate], ipg, fsl-usb2-udc); clk_register_clkdev(clk[usb_ahb_gate], ahb, fsl-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 unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] media: ov7670: add support for ov7675.
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 to have to be quick, sorry...
On Wed, 26 Sep 2012 11:47:53 +0200
Javier Martin javier.mar...@vista-silicon.com wrote:
+static struct ov7670_win_size ov7670_win_sizes[2][4] = {
+ /* ov7670 */
I must confess I don't like this; now we've got constants in an array that
was automatically sized before and ov7670_win_sizes[info-model]
everywhere. I'd suggest a separate array for each device and an
ov7670_get_wsizes(model) function.
+ /* CIF - WARNING: not tested for ov7675 */
+ {
...and this is part of why I don't like it. My experience with this
particular sensor says that, if it's not tested, it hasn't yet seen the
magic-number tweaking required to actually make it work. Please don't
claim to support formats that you don't know actually work, or I'll get
stuck with the bug reports :)
Your concern makes a lot of sense. In fact, that was one of my doubts
whether to 'support' not tested formats or not.
Let me fix that in a new version.
Hi Javier,
I'm assuming that you'll be sending a new version of this entire changeset.
So, I'll just mark this entire series as changes_requested.
Hi Mauro,
v2 of this changeset has already been sent with Jon Corbet's ack:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg52767.html
https://patchwork.kernel.org/patch/1515001/
https://patchwork.kernel.org/patch/1515021/
https://patchwork.kernel.org/patch/1515011/
https://patchwork.kernel.org/patch/1515031/
https://patchwork.kernel.org/patch/1515041/
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 this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
On 8 October 2012 11:09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Fabio On Fri, 5 Oct 2012, Fabio Estevam wrote: Since mx27 transitioned to the commmon clock framework in 3.5, the correct way to acquire the csi clock is to get csi_ahb and csi_per clocks separately. By not doing so the camera sensor does not probe correctly: soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 mx2-camera mx2-camera.0: Camera driver attached to camera 0 ov2640 0-0030: Product ID error fb:fb mx2-camera mx2-camera.0: Camera driver detached from camera 0 mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 6650 Adapt the mx2_camera driver to the new clock framework and make it functional again. Do I understand it right, that since the driver is currently broken, it doesn't matter any more in which order these two patches get applied, so, we can push them via different trees - ARM and media? Thanks Guennadi Please, hold on a couple of days before merging this one. This driver is currently working in our Visstrim M10 platform without this patch and I need to test it to confirm whether it breaks something or not. 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ov7670: migrate this sensor and its users to ctrl framework.
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 series: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674. All submitted patches have been obtained from Hans' tree and slightly modified to apply on current media_tree for-v3.7 branch: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl [PATCH 1/3] ov7670: use the control framework [PATCH 2/3] mcam-core: implement the control framework. [PATCH 3/3] via-camera: implement the control framework. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] mcam-core: implement the control framework.
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(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..568f8a5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -22,6 +22,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
#include media/v4l2-chip-ident.h
#include media/ov7670.h
#include media/videobuf2-vmalloc.h
@@ -1232,47 +1233,6 @@ static int mcam_vidioc_dqbuf(struct file *filp, void
*priv,
return ret;
}
-
-
-static int mcam_vidioc_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
static int mcam_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
@@ -1520,9 +1480,6 @@ static const struct v4l2_ioctl_ops mcam_v4l_ioctl_ops = {
.vidioc_dqbuf = mcam_vidioc_dqbuf,
.vidioc_streamon= mcam_vidioc_streamon,
.vidioc_streamoff = mcam_vidioc_streamoff,
- .vidioc_queryctrl = mcam_vidioc_queryctrl,
- .vidioc_g_ctrl = mcam_vidioc_g_ctrl,
- .vidioc_s_ctrl = mcam_vidioc_s_ctrl,
.vidioc_g_parm = mcam_vidioc_g_parm,
.vidioc_s_parm = mcam_vidioc_s_parm,
.vidioc_enum_framesizes = mcam_vidioc_enum_framesizes,
@@ -1786,14 +1743,19 @@ int mccic_register(struct mcam_camera *cam)
/*
* Get the v4l2 setup done.
*/
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
+
mutex_lock(cam-s_mutex);
cam-vdev = mcam_v4l_template;
cam-vdev.debug = 0;
cam-vdev.v4l2_dev = cam-v4l2_dev;
+ video_set_drvdata(cam-vdev, cam);
ret = video_register_device(cam-vdev, VFL_TYPE_GRABBER, -1);
if (ret)
goto out;
- video_set_drvdata(cam-vdev, cam);
/*
* If so requested, try to get our DMA buffers now.
@@ -1805,6 +1767,7 @@ int mccic_register(struct mcam_camera *cam)
}
out:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
mutex_unlock(cam-s_mutex);
return ret;
out_unregister:
@@ -1829,6 +1792,7 @@ void mccic_shutdown(struct mcam_camera *cam)
if (cam-buffer_mode == B_vmalloc)
mcam_free_dma_bufs(cam);
video_unregister_device(cam-vdev);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
v4l2_device_unregister(cam-v4l2_dev);
}
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index bd6acba..f7c34ab 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -8,6 +8,7 @@
#include linux/list.h
#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
#include media/videobuf2-core.h
@@ -104,6 +105,7 @@ struct mcam_camera {
* should not be touched by the platform code.
*/
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
enum mcam_state state;
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users; /* How many open FDs */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] via-camera: implement the control framework.
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 deletions(-)
diff --git a/drivers/media/platform/via-camera.c
b/drivers/media/platform/via-camera.c
index eb404c2..1b5f97d 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -18,6 +18,7 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/ov7670.h
#include media/videobuf-dma-sg.h
#include linux/delay.h
@@ -63,6 +64,7 @@ enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
struct via_camera {
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
struct video_device vdev;
struct v4l2_subdev *sensor;
struct platform_device *platdev;
@@ -818,47 +820,6 @@ static int viacam_g_chip_ident(struct file *file, void
*priv,
}
/*
- * Control ops are passed through to the sensor.
- */
-static int viacam_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-/*
* Only one input.
*/
static int viacam_enum_input(struct file *filp, void *priv,
@@ -1214,9 +1175,6 @@ static int viacam_enum_frameintervals(struct file *filp,
void *priv,
static const struct v4l2_ioctl_ops viacam_ioctl_ops = {
.vidioc_g_chip_ident= viacam_g_chip_ident,
- .vidioc_queryctrl = viacam_queryctrl,
- .vidioc_g_ctrl = viacam_g_ctrl,
- .vidioc_s_ctrl = viacam_s_ctrl,
.vidioc_enum_input = viacam_enum_input,
.vidioc_g_input = viacam_g_input,
.vidioc_s_input = viacam_s_input,
@@ -1418,8 +1376,12 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
ret = v4l2_device_register(pdev-dev, cam-v4l2_dev);
if (ret) {
dev_err(pdev-dev, Unable to register v4l2 device\n);
- return ret;
+ goto out_free;
}
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
/*
* Convince the system that we can do DMA.
*/
@@ -1436,7 +1398,7 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
*/
ret = via_sensor_power_setup(cam);
if (ret)
- goto out_unregister;
+ goto out_ctrl_hdl_free;
via_sensor_power_up(cam);
/*
@@ -1485,8 +1447,12 @@ out_irq:
free_irq(viadev-pdev-irq, cam);
out_power_down:
via_sensor_power_release(cam);
+out_ctrl_hdl_free:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
out_unregister:
v4l2_device_unregister(cam-v4l2_dev);
+out_free:
+ kfree(cam);
return ret;
}
@@ -1499,6 +1465,8 @@ static __devexit int viacam_remove(struct platform_device
*pdev)
v4l2_device_unregister(cam-v4l2_dev);
free_irq(viadev-pdev-irq, cam);
via_sensor_power_release(cam);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
+ kfree(cam);
via_cam_info = NULL;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ov7670: use the control framework
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/media/i2c/ov7670.c
index 9d7a92e..eead1b4 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev *sd,
int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret = ov7670_read(sd, REG_BRIGHT, v);
-
- *value = ov7670_sm_to_abs(v);
- return ret;
-}
-
static int ov7670_s_contrast(struct v4l2_subdev *sd, int value)
{
return ov7670_write(sd
Re: [PATCH 1/3] ov7670: use the control framework
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 = ov7670_s_ctrl,
- .queryctrl = ov7670_queryctrl,
+ .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
+ .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
+ .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
+ .g_ctrl = v4l2_subdev_g_ctrl,
+ .s_ctrl = v4l2_subdev_s_ctrl,
+ .queryctrl = v4l2_subdev_queryctrl,
+ .querymenu = v4l2_subdev_querymenu,
Can you make a fourth patch removing these lines again after mcam-core and
via-camera are converted to the control framework? These control ops are
only needed if there are bridge drivers using this sensor driver that are
not yet converted to the control framework. Since that limitation is now
lifted, these ops can be removed as well.
Fine, I will do that.
.reset = ov7670_reset,
.init = ov7670_init,
#ifdef CONFIG_VIDEO_ADV_DEBUG
@@ -1732,7 +1630,6 @@ static int ov7670_probe(struct i2c_client *client,
info-devtype = ov7670_devdata[id-driver_data];
info-fmt = ov7670_formats[0];
- info-sat = 128;/* Review this */
info-clkrc = 0;
/* Set default frame rate to 30 fps */
@@ -1743,6 +1640,42 @@ static int ov7670_probe(struct i2c_client *client,
if (info-pclk_hb_disable)
ov7670_write(sd, REG_COM10, COM10_PCLK_HB);
+ v4l2_ctrl_handler_init(info-hdl, 10);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_CONTRAST, 0, 127, 1, 64);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_VFLIP, 0, 1, 1, 0);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_HFLIP, 0, 1, 1, 0);
+ info-saturation = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_SATURATION, 0, 256, 1, 128);
+ info-hue = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_HUE, -180, 180, 5, 0);
+ info-gain = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_GAIN, 0, 255, 1, 128);
+ info-auto_gain = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
+ info-exposure = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_EXPOSURE, 0, 65535, 1, 500);
+ info-auto_exposure = v4l2_ctrl_new_std_menu(info-hdl,
ov7670_ctrl_ops,
+ V4L2_CID_EXPOSURE_AUTO, 1, 0, 0);
+ sd-ctrl_handler = info-hdl;
+ if (info-hdl.error) {
+ int err = info-hdl.error;
+
+ v4l2_ctrl_handler_free(info-hdl);
+ kfree(info);
+ return err;
+ }
+ info-gain-flags |= V4L2_CTRL_FLAG_VOLATILE;
+ info-exposure-flags |= V4L2_CTRL_FLAG_VOLATILE;
+ v4l2_ctrl_cluster(2, info-auto_gain);
+ v4l2_ctrl_cluster(2, info-auto_exposure);
You need to use v4l2_ctrl_auto_cluster for these two. Not having that function
at the time was the reason my work on this driver stalled. The auto cluster
functionality takes care of most of the nitty gritty details of handling
these situations.
OK, let me take a look.
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 this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] ov7670: migrate this sensor and its users to ctrl framework.
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 series: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674. All submitted patches have been obtained from Hans' tree and slightly modified to apply on current media_tree for-v3.7 branch: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl Changes since v1: - A 4th patch has been added as requested by Hans. - See changelog in patch 1. [PATCH v2 1/4] ov7670: use the control framework [PATCH v2 2/4] mcam-core: implement the control framework. [PATCH v2 3/4] via-camera: implement the control framework. [PATCH v2 4/4] ov7670: remove legacy ctrl callbacks. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] ov7670: use the control framework
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 insertions(+), 198 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..babd55c 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev *sd,
int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret = ov7670_read(sd, REG_BRIGHT, v);
-
- *value = ov7670_sm_to_abs(v);
- return ret;
-}
-
static int
[PATCH v2 2/4] mcam-core: implement the control framework.
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(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..568f8a5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -22,6 +22,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
#include media/v4l2-chip-ident.h
#include media/ov7670.h
#include media/videobuf2-vmalloc.h
@@ -1232,47 +1233,6 @@ static int mcam_vidioc_dqbuf(struct file *filp, void
*priv,
return ret;
}
-
-
-static int mcam_vidioc_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
static int mcam_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
@@ -1520,9 +1480,6 @@ static const struct v4l2_ioctl_ops mcam_v4l_ioctl_ops = {
.vidioc_dqbuf = mcam_vidioc_dqbuf,
.vidioc_streamon= mcam_vidioc_streamon,
.vidioc_streamoff = mcam_vidioc_streamoff,
- .vidioc_queryctrl = mcam_vidioc_queryctrl,
- .vidioc_g_ctrl = mcam_vidioc_g_ctrl,
- .vidioc_s_ctrl = mcam_vidioc_s_ctrl,
.vidioc_g_parm = mcam_vidioc_g_parm,
.vidioc_s_parm = mcam_vidioc_s_parm,
.vidioc_enum_framesizes = mcam_vidioc_enum_framesizes,
@@ -1786,14 +1743,19 @@ int mccic_register(struct mcam_camera *cam)
/*
* Get the v4l2 setup done.
*/
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
+
mutex_lock(cam-s_mutex);
cam-vdev = mcam_v4l_template;
cam-vdev.debug = 0;
cam-vdev.v4l2_dev = cam-v4l2_dev;
+ video_set_drvdata(cam-vdev, cam);
ret = video_register_device(cam-vdev, VFL_TYPE_GRABBER, -1);
if (ret)
goto out;
- video_set_drvdata(cam-vdev, cam);
/*
* If so requested, try to get our DMA buffers now.
@@ -1805,6 +1767,7 @@ int mccic_register(struct mcam_camera *cam)
}
out:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
mutex_unlock(cam-s_mutex);
return ret;
out_unregister:
@@ -1829,6 +1792,7 @@ void mccic_shutdown(struct mcam_camera *cam)
if (cam-buffer_mode == B_vmalloc)
mcam_free_dma_bufs(cam);
video_unregister_device(cam-vdev);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
v4l2_device_unregister(cam-v4l2_dev);
}
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index bd6acba..f7c34ab 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -8,6 +8,7 @@
#include linux/list.h
#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
#include media/videobuf2-core.h
@@ -104,6 +105,7 @@ struct mcam_camera {
* should not be touched by the platform code.
*/
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
enum mcam_state state;
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users; /* How many open FDs */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] via-camera: implement the control framework.
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 deletions(-)
diff --git a/drivers/media/platform/via-camera.c
b/drivers/media/platform/via-camera.c
index eb404c2..1b5f97d 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -18,6 +18,7 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/ov7670.h
#include media/videobuf-dma-sg.h
#include linux/delay.h
@@ -63,6 +64,7 @@ enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
struct via_camera {
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
struct video_device vdev;
struct v4l2_subdev *sensor;
struct platform_device *platdev;
@@ -818,47 +820,6 @@ static int viacam_g_chip_ident(struct file *file, void
*priv,
}
/*
- * Control ops are passed through to the sensor.
- */
-static int viacam_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-/*
* Only one input.
*/
static int viacam_enum_input(struct file *filp, void *priv,
@@ -1214,9 +1175,6 @@ static int viacam_enum_frameintervals(struct file *filp,
void *priv,
static const struct v4l2_ioctl_ops viacam_ioctl_ops = {
.vidioc_g_chip_ident= viacam_g_chip_ident,
- .vidioc_queryctrl = viacam_queryctrl,
- .vidioc_g_ctrl = viacam_g_ctrl,
- .vidioc_s_ctrl = viacam_s_ctrl,
.vidioc_enum_input = viacam_enum_input,
.vidioc_g_input = viacam_g_input,
.vidioc_s_input = viacam_s_input,
@@ -1418,8 +1376,12 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
ret = v4l2_device_register(pdev-dev, cam-v4l2_dev);
if (ret) {
dev_err(pdev-dev, Unable to register v4l2 device\n);
- return ret;
+ goto out_free;
}
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
/*
* Convince the system that we can do DMA.
*/
@@ -1436,7 +1398,7 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
*/
ret = via_sensor_power_setup(cam);
if (ret)
- goto out_unregister;
+ goto out_ctrl_hdl_free;
via_sensor_power_up(cam);
/*
@@ -1485,8 +1447,12 @@ out_irq:
free_irq(viadev-pdev-irq, cam);
out_power_down:
via_sensor_power_release(cam);
+out_ctrl_hdl_free:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
out_unregister:
v4l2_device_unregister(cam-v4l2_dev);
+out_free:
+ kfree(cam);
return ret;
}
@@ -1499,6 +1465,8 @@ static __devexit int viacam_remove(struct platform_device
*pdev)
v4l2_device_unregister(cam-v4l2_dev);
free_irq(viadev-pdev-irq, cam);
via_sensor_power_release(cam);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
+ kfree(cam);
via_cam_info = NULL;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ov7670: remove legacy ctrl callbacks.
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 file changed, 7 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index babd55c..113a4f3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1504,13 +1504,6 @@ static int ov7670_s_register(struct v4l2_subdev *sd,
struct v4l2_dbg_register *r
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
- .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
- .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
- .g_ctrl = v4l2_subdev_g_ctrl,
- .s_ctrl = v4l2_subdev_s_ctrl,
- .queryctrl = v4l2_subdev_queryctrl,
- .querymenu = v4l2_subdev_querymenu,
.reset = ov7670_reset,
.init = ov7670_init,
#ifdef CONFIG_VIDEO_ADV_DEBUG
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ov7670: use the control framework
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() for auto_gain and auto_exp.
---
drivers/media/i2c/ov7670.c | 310
1 file changed, 112 insertions(+), 198 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..babd55c 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev
*sd, int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret
[PATCH v3 0/4] ov7670: migrate this sensor and its users to ctrl framework.
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 series: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674. All submitted patches have been obtained from Hans' tree and slightly modified to apply on current media_tree for-v3.7 branch: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl Changes since v2: - See changelog in patch 1. [PATCH v3 1/4] ov7670: use the control framework [PATCH v3 2/4] mcam-core: implement the control framework. [PATCH v3 3/4] via-camera: implement the control framework. [PATCH v3 4/4] ov7670: remove legacy ctrl callbacks. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] ov7670: use the control framework
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(+), 198 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..2f6470a 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev *sd,
int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret = ov7670_read(sd, REG_BRIGHT, v);
-
- *value = ov7670_sm_to_abs(v);
- return ret;
-}
-
static int ov7670_s_contrast(struct
[PATCH v3 4/4] ov7670: remove legacy ctrl callbacks.
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
---
drivers/media/i2c/ov7670.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 2f6470a..361b101 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1504,13 +1504,6 @@ static int ov7670_s_register(struct v4l2_subdev *sd,
struct v4l2_dbg_register *r
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
- .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
- .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
- .g_ctrl = v4l2_subdev_g_ctrl,
- .s_ctrl = v4l2_subdev_s_ctrl,
- .queryctrl = v4l2_subdev_queryctrl,
- .querymenu = v4l2_subdev_querymenu,
.reset = ov7670_reset,
.init = ov7670_init,
#ifdef CONFIG_VIDEO_ADV_DEBUG
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] via-camera: implement the control framework.
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 ---
1 file changed, 14 insertions(+), 46 deletions(-)
diff --git a/drivers/media/platform/via-camera.c
b/drivers/media/platform/via-camera.c
index eb404c2..1b5f97d 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -18,6 +18,7 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/ov7670.h
#include media/videobuf-dma-sg.h
#include linux/delay.h
@@ -63,6 +64,7 @@ enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
struct via_camera {
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
struct video_device vdev;
struct v4l2_subdev *sensor;
struct platform_device *platdev;
@@ -818,47 +820,6 @@ static int viacam_g_chip_ident(struct file *file, void
*priv,
}
/*
- * Control ops are passed through to the sensor.
- */
-static int viacam_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-/*
* Only one input.
*/
static int viacam_enum_input(struct file *filp, void *priv,
@@ -1214,9 +1175,6 @@ static int viacam_enum_frameintervals(struct file *filp,
void *priv,
static const struct v4l2_ioctl_ops viacam_ioctl_ops = {
.vidioc_g_chip_ident= viacam_g_chip_ident,
- .vidioc_queryctrl = viacam_queryctrl,
- .vidioc_g_ctrl = viacam_g_ctrl,
- .vidioc_s_ctrl = viacam_s_ctrl,
.vidioc_enum_input = viacam_enum_input,
.vidioc_g_input = viacam_g_input,
.vidioc_s_input = viacam_s_input,
@@ -1418,8 +1376,12 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
ret = v4l2_device_register(pdev-dev, cam-v4l2_dev);
if (ret) {
dev_err(pdev-dev, Unable to register v4l2 device\n);
- return ret;
+ goto out_free;
}
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
/*
* Convince the system that we can do DMA.
*/
@@ -1436,7 +1398,7 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
*/
ret = via_sensor_power_setup(cam);
if (ret)
- goto out_unregister;
+ goto out_ctrl_hdl_free;
via_sensor_power_up(cam);
/*
@@ -1485,8 +1447,12 @@ out_irq:
free_irq(viadev-pdev-irq, cam);
out_power_down:
via_sensor_power_release(cam);
+out_ctrl_hdl_free:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
out_unregister:
v4l2_device_unregister(cam-v4l2_dev);
+out_free:
+ kfree(cam);
return ret;
}
@@ -1499,6 +1465,8 @@ static __devexit int viacam_remove(struct platform_device
*pdev)
v4l2_device_unregister(cam-v4l2_dev);
free_irq(viadev-pdev-irq, cam);
via_sensor_power_release(cam);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
+ kfree(cam);
via_cam_info = NULL;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] mcam-core: implement the control framework.
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 +
2 files changed, 11 insertions(+), 45 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..568f8a5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -22,6 +22,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
#include media/v4l2-chip-ident.h
#include media/ov7670.h
#include media/videobuf2-vmalloc.h
@@ -1232,47 +1233,6 @@ static int mcam_vidioc_dqbuf(struct file *filp, void
*priv,
return ret;
}
-
-
-static int mcam_vidioc_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
static int mcam_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
@@ -1520,9 +1480,6 @@ static const struct v4l2_ioctl_ops mcam_v4l_ioctl_ops = {
.vidioc_dqbuf = mcam_vidioc_dqbuf,
.vidioc_streamon= mcam_vidioc_streamon,
.vidioc_streamoff = mcam_vidioc_streamoff,
- .vidioc_queryctrl = mcam_vidioc_queryctrl,
- .vidioc_g_ctrl = mcam_vidioc_g_ctrl,
- .vidioc_s_ctrl = mcam_vidioc_s_ctrl,
.vidioc_g_parm = mcam_vidioc_g_parm,
.vidioc_s_parm = mcam_vidioc_s_parm,
.vidioc_enum_framesizes = mcam_vidioc_enum_framesizes,
@@ -1786,14 +1743,19 @@ int mccic_register(struct mcam_camera *cam)
/*
* Get the v4l2 setup done.
*/
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
+
mutex_lock(cam-s_mutex);
cam-vdev = mcam_v4l_template;
cam-vdev.debug = 0;
cam-vdev.v4l2_dev = cam-v4l2_dev;
+ video_set_drvdata(cam-vdev, cam);
ret = video_register_device(cam-vdev, VFL_TYPE_GRABBER, -1);
if (ret)
goto out;
- video_set_drvdata(cam-vdev, cam);
/*
* If so requested, try to get our DMA buffers now.
@@ -1805,6 +1767,7 @@ int mccic_register(struct mcam_camera *cam)
}
out:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
mutex_unlock(cam-s_mutex);
return ret;
out_unregister:
@@ -1829,6 +1792,7 @@ void mccic_shutdown(struct mcam_camera *cam)
if (cam-buffer_mode == B_vmalloc)
mcam_free_dma_bufs(cam);
video_unregister_device(cam-vdev);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
v4l2_device_unregister(cam-v4l2_dev);
}
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index bd6acba..f7c34ab 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -8,6 +8,7 @@
#include linux/list.h
#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
#include media/videobuf2-core.h
@@ -104,6 +105,7 @@ struct mcam_camera {
* should not be touched by the platform code.
*/
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
enum mcam_state state;
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users; /* How many open FDs */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] media: ov7670: add support for ov7675.
Hi Jonathan,
thank you for your time.
On 26 September 2012 18:40, Jonathan Corbet cor...@lwn.net wrote:
This is going to have to be quick, sorry...
On Wed, 26 Sep 2012 11:47:53 +0200
Javier Martin javier.mar...@vista-silicon.com wrote:
+static struct ov7670_win_size ov7670_win_sizes[2][4] = {
+ /* ov7670 */
I must confess I don't like this; now we've got constants in an array that
was automatically sized before and ov7670_win_sizes[info-model]
everywhere. I'd suggest a separate array for each device and an
ov7670_get_wsizes(model) function.
+ /* CIF - WARNING: not tested for ov7675 */
+ {
...and this is part of why I don't like it. My experience with this
particular sensor says that, if it's not tested, it hasn't yet seen the
magic-number tweaking required to actually make it work. Please don't
claim to support formats that you don't know actually work, or I'll get
stuck with the bug reports :)
Your concern makes a lot of sense. In fact, that was one of my doubts
whether to 'support' not tested formats or not.
Let me fix that in a new version.
--
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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] media: ov7670: make try_fmt() consistent with 'min_height' and 'min_width'.
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 fmt callbacks consider this parameters in order to return valid data to user space. I'd have preferred to do this differently, perhaps backing toward larger sizes if the minimum turns out to be violated. But so be it... Acked-by: Jonathan Corbet cor...@lwn.net jon Thank you. I will have to modify this patch slightly when I fix the previous one though. -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] media: ov7670: calculate framerate properly for ov7675.
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 in the current code. In fact, this formula should apply to ov7670 too. This would mean that current code is wrong but, in order to preserve compatibility, the new formula will be used for ov7675 only. At this point I couldn't tell you what the real situation is; it's been a while and there's always a fair amount of black magic involved with ov7670 configuration. I do appreciate attention to not breaking existing users. Indeed, this sensor is the quirkier I've dealt with, with those magic values in non documented registers... +static void ov7670_get_framerate(struct v4l2_subdev *sd, + struct v4l2_fract *tpf) This bugs me, though. It's called ov7670_get_framerate() but it's getting the rate for the ov7675 - confusing. Meanwhile the real ov7670 code remains inline while ov7675 has its own function. Actually, I did this on purpose because I wanted to remark that this function should be valid for both models and because I expected that the old behaviour was removed sometime in the future. Please make two functions, one of which is ov7675_get_framerate(), and call the right one for the model. Same for the set functions, obviously. Maybe what's really needed is a structure full of sensor-specific operations? The get_wsizes() function could go there too. That would take a lot of if statements out of the code. The idea of a structure of sensor-specific operations seems reasonable. Furthermore, I think we should encourage users to use the right formula in the future. For this reason we could define 4 functions ov7670_set_framerate_legacy() ov7670_get_framerate_legacy() ov7675_set_framerate() ov7675_get_framerate() + /* + * The datasheet claims that clkrc = 0 will divide the input clock by 1 + * but we've checked with an oscilloscope that it divides by 2 instead. + * So, if clkrc = 0 just bypass the divider. + */ Thanks for documenting this kind of thing. You are welcome. -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] media: ov7670: add possibility to bypass pll for ov7675.
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 you want to do it? Otherwise: As I stated in a previous patch, frame rate depends on the pixclk. Moreover: pixclk = xvclk / clkrc * PLLfactor Bypassing the PLL means that the PLL gets out of the way so, in practice, PLLfactor = 1 pixclk = xvclk / clkrc For a frame rate of 30 fps a pixclk of 24MHz is needed. Since we have a clean clock signal we want pixclk = xvclk. If one applies the formula in ov7670_set_framerate() with PLLfactor = 1 and clock_speed = 24 MHz the resulting clkrc = 1 which means that: pixclk = xvclk which is what we want Acked-by: Jonathan Corbet cor...@lwn.net Thank you. I will add a changelog when I send v2 of the series. 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] media: ov7670: Add possibility to disable pixclk during hblank.
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 |1 + 2 files changed, 9 insertions(+) Again, needs a changelog. Otherwise Our soc-camera host driver captures pixels during blanking periods if pixclk is enabled. In order to avoid capturing bogus data we need to disable pixclk during those blanking periods I'll add it to v2. Acked-by: Jonathan Corbet cor...@lwn.net Thank you. -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674.
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 in [1]. This v2 include changes requested by Jonathan Corbet. See each separate patch. [PATCH v2 1/5] media: ov7670: add support for ov7675. [PATCH v2 2/5] media: ov7670: make try_fmt() consistent with [PATCH v2 3/5] media: ov7670: calculate framerate properly for ov7675. [PATCH v2 4/5] media: ov7670: add possibility to bypass pll for ov7675. [PATCH v2 5/5] media: ov7670: Add possibility to disable pixclk during -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] media: ov7670: add support for ov7675.
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-silicon.com
---
Changes since v1:
- Use separate arrays for supported resolutions.
- Don't support not tested resolutions in ov7675.
---
drivers/media/i2c/ov7670.c | 101 +++-
1 file changed, 72 insertions(+), 29 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e7c82b2..17eb5d7 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -183,6 +183,27 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
#define REG_HAECC7 0xaa/* Hist AEC/AGC control 7 */
#define REG_BD60MAX0xab/* 60hz banding step limit */
+enum ov7670_model {
+ MODEL_OV7670 = 0,
+ MODEL_OV7675,
+};
+
+struct ov7670_win_size {
+ int width;
+ int height;
+ unsigned char com7_bit;
+ int hstart; /* Start/stop values for the camera. Note */
+ int hstop; /* that they do not always make complete */
+ int vstart; /* sense to humans, but evidently the sensor */
+ int vstop; /* will do the right thing... */
+ struct regval_list *regs; /* Regs to tweak */
+};
+
+struct ov7670_devtype {
+ /* formats supported for each model */
+ struct ov7670_win_size *win_sizes;
+ unsigned int n_win_sizes;
+};
/*
* Information we maintain about a known sensor.
@@ -198,6 +219,7 @@ struct ov7670_info {
int clock_speed;/* External clock speed (MHz) */
u8 clkrc; /* Clock divider value */
bool use_smbus; /* Use smbus I/O instead of I2C */
+ const struct ov7670_devtype *devtype; /* Device specifics */
};
static inline struct ov7670_info *to_state(struct v4l2_subdev *sd)
@@ -652,65 +674,70 @@ static struct regval_list ov7670_qcif_regs[] = {
{ 0xff, 0xff },
};
-static struct ov7670_win_size {
- int width;
- int height;
- unsigned char com7_bit;
- int hstart; /* Start/stop values for the camera. Note */
- int hstop; /* that they do not always make complete */
- int vstart; /* sense to humans, but evidently the sensor */
- int vstop; /* will do the right thing... */
- struct regval_list *regs; /* Regs to tweak */
-/* h/vref stuff */
-} ov7670_win_sizes[] = {
+static struct ov7670_win_size ov7670_win_sizes[] = {
/* VGA */
{
.width = VGA_WIDTH,
.height = VGA_HEIGHT,
.com7_bit = COM7_FMT_VGA,
- .hstart = 158, /* These values from */
- .hstop = 14, /* Omnivision */
+ .hstart = 158, /* These values from */
+ .hstop = 14, /* Omnivision */
.vstart = 10,
.vstop = 490,
- .regs = NULL,
+ .regs = NULL,
},
/* CIF */
{
.width = CIF_WIDTH,
.height = CIF_HEIGHT,
.com7_bit = COM7_FMT_CIF,
- .hstart = 170, /* Empirically determined */
+ .hstart = 170, /* Empirically determined */
.hstop = 90,
.vstart = 14,
.vstop = 494,
- .regs = NULL,
+ .regs = NULL,
},
/* QVGA */
{
.width = QVGA_WIDTH,
.height = QVGA_HEIGHT,
.com7_bit = COM7_FMT_QVGA,
- .hstart = 168, /* Empirically determined */
+ .hstart = 168, /* Empirically determined */
.hstop = 24,
.vstart = 12,
.vstop = 492,
- .regs = NULL,
+ .regs = NULL,
},
/* QCIF */
{
.width = QCIF_WIDTH,
.height = QCIF_HEIGHT,
.com7_bit = COM7_FMT_VGA, /* see comment above */
- .hstart = 456, /* Empirically determined */
+ .hstart = 456, /* Empirically determined */
.hstop = 24,
.vstart = 14,
.vstop = 494,
- .regs = ov7670_qcif_regs,
- },
+ .regs = ov7670_qcif_regs,
+ }
};
-#define N_WIN_SIZES (ARRAY_SIZE
[PATCH v2 3/5] media: ov7670: calculate framerate properly for ov7675.
According to the datasheet ov7675 uses a formula to achieve
the desired framerate that is different from the operations
done in the current code.
In fact, this formula should apply to ov7670 too. This would
mean that current code is wrong but, in order to preserve
compatibility, the new formula 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(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 3eaa06c..cb62d08 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -47,6 +47,8 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
*/
#define OV7670_I2C_ADDR 0x42
+#define PLL_FACTOR 4
+
/* Registers */
#define REG_GAIN 0x00/* Gain lower 8 bits (rest in vref) */
#define REG_BLUE 0x01/* blue gain */
@@ -164,6 +166,12 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
#define REG_GFIX 0x69/* Fix gain control */
+#define REG_DBLV 0x6b/* PLL control an debugging */
+#define DBLV_BYPASS0x00/* Bypass PLL */
+#define DBLV_X40x01/* clock x4 */
+#define DBLV_X60x10/* clock x6 */
+#define DBLV_X80x11/* clock x8 */
+
#define REG_REG76 0x76/* OV's name */
#define R76_BLKPCOR0x80/* Black pixel correction enable */
#define R76_WHTPCOR0x40/* White pixel correction enable */
@@ -203,6 +211,9 @@ struct ov7670_devtype {
/* formats supported for each model */
struct ov7670_win_size *win_sizes;
unsigned int n_win_sizes;
+ /* callbacks for frame rate control */
+ int (*set_framerate)(struct v4l2_subdev *, struct v4l2_fract *);
+ void (*get_framerate)(struct v4l2_subdev *, struct v4l2_fract *);
};
/*
@@ -739,6 +750,98 @@ static struct ov7670_win_size ov7675_win_sizes[] = {
}
};
+static void ov7675_get_framerate(struct v4l2_subdev *sd,
+struct v4l2_fract *tpf)
+{
+ struct ov7670_info *info = to_state(sd);
+ u32 clkrc = info-clkrc;
+ u32 pll_factor = PLL_FACTOR;
+
+ clkrc++;
+ if (info-fmt-mbus_code == V4L2_MBUS_FMT_SBGGR8_1X8)
+ clkrc = (clkrc 1);
+
+ tpf-numerator = 1;
+ tpf-denominator = (5 * pll_factor * info-clock_speed) /
+ (4 * clkrc);
+}
+
+static int ov7675_set_framerate(struct v4l2_subdev *sd,
+struct v4l2_fract *tpf)
+{
+ struct ov7670_info *info = to_state(sd);
+ u32 clkrc;
+ u32 pll_factor = PLL_FACTOR;
+ int ret;
+
+ /*
+* The formula is fps = 5/4*pixclk for YUV/RGB and
+* fps = 5/2*pixclk for RAW.
+*
+* pixclk = clock_speed / (clkrc + 1) * PLLfactor
+*
+*/
+ if (tpf-numerator == 0 || tpf-denominator == 0) {
+ clkrc = 0;
+ } else {
+ clkrc = (5 * pll_factor * info-clock_speed * tpf-numerator) /
+ (4 * tpf-denominator);
+ if (info-fmt-mbus_code == V4L2_MBUS_FMT_SBGGR8_1X8)
+ clkrc = (clkrc 1);
+ clkrc--;
+ }
+
+ /*
+* The datasheet claims that clkrc = 0 will divide the input clock by 1
+* but we've checked with an oscilloscope that it divides by 2 instead.
+* So, if clkrc = 0 just bypass the divider.
+*/
+ if (clkrc = 0)
+ clkrc = CLK_EXT;
+ else if (clkrc CLK_SCALE)
+ clkrc = CLK_SCALE;
+ info-clkrc = clkrc;
+
+ /* Recalculate frame rate */
+ ov7675_get_framerate(sd, tpf);
+
+ ret = ov7670_write(sd, REG_CLKRC, info-clkrc);
+ if (ret 0)
+ return ret;
+ return ov7670_write(sd, REG_DBLV, DBLV_X4);
+}
+
+static void ov7670_get_framerate_legacy(struct v4l2_subdev *sd,
+struct v4l2_fract *tpf)
+{
+ struct ov7670_info *info = to_state(sd);
+
+ tpf-numerator = 1;
+ tpf-denominator = info-clock_speed;
+ if ((info-clkrc CLK_EXT) == 0 (info-clkrc CLK_SCALE) 1)
+ tpf-denominator /= (info-clkrc CLK_SCALE);
+}
+
+static int ov7670_set_framerate_legacy(struct v4l2_subdev *sd,
+ struct v4l2_fract *tpf)
+{
+ struct ov7670_info *info = to_state(sd);
+ int div;
+
+ if (tpf-numerator == 0 || tpf-denominator == 0)
+ div = 1; /* Reset to full rate */
+ else
+ div = (tpf-numerator * info-clock_speed) / tpf-denominator;
+ if (div == 0)
+ div = 1;
+ else if (div CLK_SCALE)
+ div = CLK_SCALE;
+ info-clkrc = (info-clkrc 0x80) | div;
+ tpf-numerator = 1;
+ tpf-denominator = info
[PATCH v2 2/5] media: ov7670: make try_fmt() consistent with 'min_height' and 'min_width'.
'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 javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 17eb5d7..3eaa06c 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -786,10 +786,11 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
struct ov7670_format_struct **ret_fmt,
struct ov7670_win_size **ret_wsize)
{
- int index;
+ int index, i;
struct ov7670_win_size *wsize;
struct ov7670_info *info = to_state(sd);
unsigned int n_win_sizes = info-devtype-n_win_sizes;
+ unsigned int win_sizes_limit = n_win_sizes;
for (index = 0; index N_OV7670_FMTS; index++)
if (ov7670_formats[index].mbus_code == fmt-code)
@@ -805,15 +806,30 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
* Fields: the OV devices claim to be progressive.
*/
fmt-field = V4L2_FIELD_NONE;
+
+ /*
+* Don't consider values that don't match min_height and min_width
+* constraints.
+*/
+ if (info-min_width || info-min_height)
+ for (i = 0; i n_win_sizes; i++) {
+ wsize = info-devtype-win_sizes + i;
+
+ if (wsize-width info-min_width ||
+ wsize-height info-min_height) {
+ win_sizes_limit = i;
+ break;
+ }
+ }
/*
* Round requested image size down to the nearest
* we support, but not below the smallest.
*/
for (wsize = info-devtype-win_sizes;
-wsize info-devtype-win_sizes + n_win_sizes; wsize++)
+wsize info-devtype-win_sizes + win_sizes_limit; wsize++)
if (fmt-width = wsize-width fmt-height = wsize-height)
break;
- if (wsize = info-devtype-win_sizes + n_win_sizes)
+ if (wsize = info-devtype-win_sizes + win_sizes_limit)
wsize--; /* Take the smallest one */
if (ret_wsize != NULL)
*ret_wsize = wsize;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] media: ov7670: add possibility to bypass pll for ov7675.
For a frame rate of 30 fps a pixclk of 24MHz is needed. For those
cases where the ov7670 has a clean 24MHz input (xvclk) the PLL
can be bypassed.
This will result in a value of clkrc of 1, which means that in practice
pixclk = xvclk (input clock)
Acked-by: Jonathan Corbet cor...@lwn.net
Signed-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/drivers/media/i2c/ov7670.c
index cb62d08..559c23e 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -230,6 +230,7 @@ struct ov7670_info {
int clock_speed;/* External clock speed (MHz) */
u8 clkrc; /* Clock divider value */
bool use_smbus; /* Use smbus I/O instead of I2C */
+ bool pll_bypass;
const struct ov7670_devtype *devtype; /* Device specifics */
};
@@ -755,7 +756,12 @@ static void ov7675_get_framerate(struct v4l2_subdev *sd,
{
struct ov7670_info *info = to_state(sd);
u32 clkrc = info-clkrc;
- u32 pll_factor = PLL_FACTOR;
+ int pll_factor;
+
+ if (info-pll_bypass)
+ pll_factor = 1;
+ else
+ pll_factor = PLL_FACTOR;
clkrc++;
if (info-fmt-mbus_code == V4L2_MBUS_FMT_SBGGR8_1X8)
@@ -771,7 +777,7 @@ static int ov7675_set_framerate(struct v4l2_subdev *sd,
{
struct ov7670_info *info = to_state(sd);
u32 clkrc;
- u32 pll_factor = PLL_FACTOR;
+ int pll_factor;
int ret;
/*
@@ -781,6 +787,16 @@ static int ov7675_set_framerate(struct v4l2_subdev *sd,
* pixclk = clock_speed / (clkrc + 1) * PLLfactor
*
*/
+ if (info-pll_bypass) {
+ pll_factor = 1;
+ ret = ov7670_write(sd, REG_DBLV, DBLV_BYPASS);
+ } else {
+ pll_factor = PLL_FACTOR;
+ ret = ov7670_write(sd, REG_DBLV, DBLV_X4);
+ }
+ if (ret 0)
+ return ret;
+
if (tpf-numerator == 0 || tpf-denominator == 0) {
clkrc = 0;
} else {
@@ -808,6 +824,7 @@ static int ov7675_set_framerate(struct v4l2_subdev *sd,
ret = ov7670_write(sd, REG_CLKRC, info-clkrc);
if (ret 0)
return ret;
+
return ov7670_write(sd, REG_DBLV, DBLV_X4);
}
@@ -1688,6 +1705,13 @@ static int ov7670_probe(struct i2c_client *client,
if (config-clock_speed)
info-clock_speed = config-clock_speed;
+
+ /*
+* It should be allowed for ov7670 too when it is migrated to
+* the new frame rate formula.
+*/
+ if (config-pll_bypass id-driver_data != MODEL_OV7670)
+ info-pll_bypass = true;
}
/* Make sure it's an ov7670 */
diff --git a/include/media/ov7670.h b/include/media/ov7670.h
index b133bc1..a68c8bb 100644
--- a/include/media/ov7670.h
+++ b/include/media/ov7670.h
@@ -15,6 +15,7 @@ struct ov7670_config {
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
bool use_smbus; /* Use smbus I/O instead of I2C */
+ bool pll_bypass;/* Choose whether to bypass the PLL */
};
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] media: ov7670: Add possibility to disable pixclk during hblank.
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
---
Changes since v1:
- Added changelog.
---
drivers/media/i2c/ov7670.c |7 +++
include/media/ov7670.h |1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 559c23e..9d7a92e 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -231,6 +231,7 @@ struct ov7670_info {
u8 clkrc; /* Clock divider value */
bool use_smbus; /* Use smbus I/O instead of I2C */
bool pll_bypass;
+ bool pclk_hb_disable;
const struct ov7670_devtype *devtype; /* Device specifics */
};
@@ -1712,6 +1713,9 @@ static int ov7670_probe(struct i2c_client *client,
*/
if (config-pll_bypass id-driver_data != MODEL_OV7670)
info-pll_bypass = true;
+
+ if (config-pclk_hb_disable)
+ info-pclk_hb_disable = true;
}
/* Make sure it's an ov7670 */
@@ -1736,6 +1740,9 @@ static int ov7670_probe(struct i2c_client *client,
tpf.denominator = 30;
info-devtype-set_framerate(sd, tpf);
+ if (info-pclk_hb_disable)
+ ov7670_write(sd, REG_COM10, COM10_PCLK_HB);
+
return 0;
}
diff --git a/include/media/ov7670.h b/include/media/ov7670.h
index a68c8bb..1913d51 100644
--- a/include/media/ov7670.h
+++ b/include/media/ov7670.h
@@ -16,6 +16,7 @@ struct ov7670_config {
int clock_speed;/* External clock speed (MHz) */
bool use_smbus; /* Use smbus I/O instead of I2C */
bool pll_bypass;/* Choose whether to bypass the PLL */
+ bool pclk_hb_disable; /* Disable toggling pixclk during
horizontal blanking */
};
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] media: ov7670: driver cleanup and support for ov7674.
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 in [1]. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] media: ov7670: add support for ov7675.
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-silicon.com
---
drivers/media/i2c/ov7670.c | 164 ++--
1 file changed, 111 insertions(+), 53 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e7c82b2..0478a7b 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -183,6 +183,10 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
#define REG_HAECC7 0xaa/* Hist AEC/AGC control 7 */
#define REG_BD60MAX0xab/* 60hz banding step limit */
+enum ov7670_model {
+ MODEL_OV7670 = 0,
+ MODEL_OV7675,
+};
/*
* Information we maintain about a known sensor.
@@ -198,6 +202,7 @@ struct ov7670_info {
int clock_speed;/* External clock speed (MHz) */
u8 clkrc; /* Clock divider value */
bool use_smbus; /* Use smbus I/O instead of I2C */
+ enum ov7670_model model;
};
static inline struct ov7670_info *to_state(struct v4l2_subdev *sd)
@@ -652,7 +657,7 @@ static struct regval_list ov7670_qcif_regs[] = {
{ 0xff, 0xff },
};
-static struct ov7670_win_size {
+struct ov7670_win_size {
int width;
int height;
unsigned char com7_bit;
@@ -661,57 +666,105 @@ static struct ov7670_win_size {
int vstart; /* sense to humans, but evidently the sensor */
int vstop; /* will do the right thing... */
struct regval_list *regs; /* Regs to tweak */
-/* h/vref stuff */
-} ov7670_win_sizes[] = {
- /* VGA */
- {
- .width = VGA_WIDTH,
- .height = VGA_HEIGHT,
- .com7_bit = COM7_FMT_VGA,
- .hstart = 158, /* These values from */
- .hstop = 14, /* Omnivision */
- .vstart = 10,
- .vstop = 490,
- .regs = NULL,
- },
- /* CIF */
- {
- .width = CIF_WIDTH,
- .height = CIF_HEIGHT,
- .com7_bit = COM7_FMT_CIF,
- .hstart = 170, /* Empirically determined */
- .hstop = 90,
- .vstart = 14,
- .vstop = 494,
- .regs = NULL,
- },
- /* QVGA */
+};
+
+static struct ov7670_win_size ov7670_win_sizes[2][4] = {
+ /* ov7670 */
{
- .width = QVGA_WIDTH,
- .height = QVGA_HEIGHT,
- .com7_bit = COM7_FMT_QVGA,
- .hstart = 168, /* Empirically determined */
- .hstop = 24,
- .vstart = 12,
- .vstop = 492,
- .regs = NULL,
+ /* VGA */
+ {
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
+ .com7_bit = COM7_FMT_VGA,
+ .hstart = 158, /* These values from */
+ .hstop = 14, /* Omnivision */
+ .vstart = 10,
+ .vstop = 490,
+ .regs = NULL,
+ },
+ /* CIF */
+ {
+ .width = CIF_WIDTH,
+ .height = CIF_HEIGHT,
+ .com7_bit = COM7_FMT_CIF,
+ .hstart = 170, /* Empirically determined */
+ .hstop = 90,
+ .vstart = 14,
+ .vstop = 494,
+ .regs = NULL,
+ },
+ /* QVGA */
+ {
+ .width = QVGA_WIDTH,
+ .height = QVGA_HEIGHT,
+ .com7_bit = COM7_FMT_QVGA,
+ .hstart = 168, /* Empirically determined */
+ .hstop = 24,
+ .vstart = 12,
+ .vstop = 492,
+ .regs = NULL,
+ },
+ /* QCIF */
+ {
+ .width = QCIF_WIDTH,
+ .height = QCIF_HEIGHT,
+ .com7_bit = COM7_FMT_VGA, /* see comment above */
+ .hstart = 456, /* Empirically determined */
+ .hstop
[PATCH 2/5] media: ov7670: make try_fmt() consistent with 'min_height' and 'min_width'.
'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.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 0478a7b..627fe5f 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -812,10 +812,11 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
struct ov7670_format_struct **ret_fmt,
struct ov7670_win_size **ret_wsize)
{
- int index;
+ int index, i;
struct ov7670_win_size *wsize;
struct ov7670_info *info = to_state(sd);
int n_win_sizes = ARRAY_SIZE(ov7670_win_sizes[info-model]);
+ int win_sizes_limit = n_win_sizes;
for (index = 0; index N_OV7670_FMTS; index++)
if (ov7670_formats[index].mbus_code == fmt-code)
@@ -831,15 +832,30 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
* Fields: the OV devices claim to be progressive.
*/
fmt-field = V4L2_FIELD_NONE;
+
+ /*
+* Don't consider values that don't match min_height and min_width
+* constraints.
+*/
+ if (info-min_width || info-min_height)
+ for (i = 0; i n_win_sizes; i++) {
+ wsize = ov7670_win_sizes[info-model] + i;
+
+ if (wsize-width info-min_width ||
+ wsize-height info-min_height) {
+ win_sizes_limit = i;
+ break;
+ }
+ }
/*
* Round requested image size down to the nearest
* we support, but not below the smallest.
*/
for (wsize = ov7670_win_sizes[info-model];
-wsize ov7670_win_sizes[info-model] + n_win_sizes; wsize++)
+wsize ov7670_win_sizes[info-model] + win_sizes_limit; wsize++)
if (fmt-width = wsize-width fmt-height = wsize-height)
break;
- if (wsize = ov7670_win_sizes[info-model] + n_win_sizes)
+ if (wsize = ov7670_win_sizes[info-model] + win_sizes_limit)
wsize--; /* Take the smallest one */
if (ret_wsize != NULL)
*ret_wsize = wsize;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] media: ov7670: add possibility to bypass pll for ov7675.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c | 24 ++--
include/media/ov7670.h |1 +
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 175fbfc..54fb535 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -210,6 +210,7 @@ struct ov7670_info {
int clock_speed;/* External clock speed (MHz) */
u8 clkrc; /* Clock divider value */
bool use_smbus; /* Use smbus I/O instead of I2C */
+ bool pll_bypass;
enum ov7670_model model;
};
@@ -778,7 +779,12 @@ static void ov7670_get_framerate(struct v4l2_subdev *sd,
{
struct ov7670_info *info = to_state(sd);
u32 clkrc = info-clkrc;
- u32 pll_factor = PLL_FACTOR;
+ int pll_factor;
+
+ if (info-pll_bypass)
+ pll_factor = 1;
+ else
+ pll_factor = PLL_FACTOR;
clkrc++;
if (info-fmt-mbus_code == V4L2_MBUS_FMT_SBGGR8_1X8)
@@ -794,7 +800,7 @@ static int ov7670_set_framerate(struct v4l2_subdev *sd,
{
struct ov7670_info *info = to_state(sd);
u32 clkrc;
- u32 pll_factor = PLL_FACTOR;
+ int pll_factor;
int ret;
/*
@@ -804,6 +810,16 @@ static int ov7670_set_framerate(struct v4l2_subdev *sd,
* pixclk = clock_speed / (clkrc + 1) * PLLfactor
*
*/
+ if (info-pll_bypass) {
+ pll_factor = 1;
+ ret = ov7670_write(sd, REG_DBLV, DBLV_BYPASS);
+ } else {
+ pll_factor = PLL_FACTOR;
+ ret = ov7670_write(sd, REG_DBLV, DBLV_X4);
+ }
+ if (ret 0)
+ return ret;
+
if (tpf-numerator == 0 || tpf-denominator == 0) {
clkrc = 0;
} else {
@@ -831,6 +847,7 @@ static int ov7670_set_framerate(struct v4l2_subdev *sd,
ret = ov7670_write(sd, REG_CLKRC, info-clkrc);
if (ret 0)
return ret;
+
return ov7670_write(sd, REG_DBLV, DBLV_X4);
}
@@ -1689,6 +1706,9 @@ static int ov7670_probe(struct i2c_client *client,
if (config-clock_speed)
info-clock_speed = config-clock_speed;
+
+ if (config-pll_bypass id-driver_data != MODEL_OV7670)
+ info-pll_bypass = true;
}
/* Make sure it's an ov7670 */
diff --git a/include/media/ov7670.h b/include/media/ov7670.h
index b133bc1..a68c8bb 100644
--- a/include/media/ov7670.h
+++ b/include/media/ov7670.h
@@ -15,6 +15,7 @@ struct ov7670_config {
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
bool use_smbus; /* Use smbus I/O instead of I2C */
+ bool pll_bypass;/* Choose whether to bypass the PLL */
};
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] media: ov7670: calculate framerate properly for ov7675.
According to the datasheet ov7675 uses a formula to achieve
the desired framerate that is different from the operations
done in the current code.
In fact, this formula should apply to ov7670 too. This would
mean that current code is wrong but, in order to preserve
compatibility, the new formula will be used for ov7675 only.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c | 122 ++--
1 file changed, 105 insertions(+), 17 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 627fe5f..175fbfc 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -47,6 +47,8 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
*/
#define OV7670_I2C_ADDR 0x42
+#define PLL_FACTOR 4
+
/* Registers */
#define REG_GAIN 0x00/* Gain lower 8 bits (rest in vref) */
#define REG_BLUE 0x01/* blue gain */
@@ -164,6 +166,12 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
#define REG_GFIX 0x69/* Fix gain control */
+#define REG_DBLV 0x6b/* PLL control an debugging */
+#define DBLV_BYPASS0x00/* Bypass PLL */
+#define DBLV_X40x01/* clock x4 */
+#define DBLV_X60x10/* clock x6 */
+#define DBLV_X80x11/* clock x8 */
+
#define REG_REG76 0x76/* OV's name */
#define R76_BLKPCOR0x80/* Black pixel correction enable */
#define R76_WHTPCOR0x40/* White pixel correction enable */
@@ -765,6 +773,67 @@ static struct ov7670_win_size ov7670_win_sizes[2][4] = {
}
};
+static void ov7670_get_framerate(struct v4l2_subdev *sd,
+struct v4l2_fract *tpf)
+{
+ struct ov7670_info *info = to_state(sd);
+ u32 clkrc = info-clkrc;
+ u32 pll_factor = PLL_FACTOR;
+
+ clkrc++;
+ if (info-fmt-mbus_code == V4L2_MBUS_FMT_SBGGR8_1X8)
+ clkrc = (clkrc 1);
+
+ tpf-numerator = 1;
+ tpf-denominator = (5 * pll_factor * info-clock_speed) /
+ (4 * clkrc);
+}
+
+static int ov7670_set_framerate(struct v4l2_subdev *sd,
+struct v4l2_fract *tpf)
+{
+ struct ov7670_info *info = to_state(sd);
+ u32 clkrc;
+ u32 pll_factor = PLL_FACTOR;
+ int ret;
+
+ /*
+* The formula is fps = 5/4*pixclk for YUV/RGB and
+* fps = 5/2*pixclk for RAW.
+*
+* pixclk = clock_speed / (clkrc + 1) * PLLfactor
+*
+*/
+ if (tpf-numerator == 0 || tpf-denominator == 0) {
+ clkrc = 0;
+ } else {
+ clkrc = (5 * pll_factor * info-clock_speed * tpf-numerator) /
+ (4 * tpf-denominator);
+ if (info-fmt-mbus_code == V4L2_MBUS_FMT_SBGGR8_1X8)
+ clkrc = (clkrc 1);
+ clkrc--;
+ }
+
+ /*
+* The datasheet claims that clkrc = 0 will divide the input clock by 1
+* but we've checked with an oscilloscope that it divides by 2 instead.
+* So, if clkrc = 0 just bypass the divider.
+*/
+ if (clkrc = 0)
+ clkrc = CLK_EXT;
+ else if (clkrc CLK_SCALE)
+ clkrc = CLK_SCALE;
+ info-clkrc = clkrc;
+
+ /* Recalculate frame rate */
+ ov7670_get_framerate(sd, tpf);
+
+ ret = ov7670_write(sd, REG_CLKRC, info-clkrc);
+ if (ret 0)
+ return ret;
+ return ov7670_write(sd, REG_DBLV, DBLV_X4);
+}
+
/*
* Store a set of start/stop values into the camera.
*/
@@ -939,10 +1008,15 @@ static int ov7670_g_parm(struct v4l2_subdev *sd, struct
v4l2_streamparm *parms)
memset(cp, 0, sizeof(struct v4l2_captureparm));
cp-capability = V4L2_CAP_TIMEPERFRAME;
- cp-timeperframe.numerator = 1;
- cp-timeperframe.denominator = info-clock_speed;
- if ((info-clkrc CLK_EXT) == 0 (info-clkrc CLK_SCALE) 1)
- cp-timeperframe.denominator /= (info-clkrc CLK_SCALE);
+ if (info-model == MODEL_OV7670) {
+ /* legacy */
+ cp-timeperframe.numerator = 1;
+ cp-timeperframe.denominator = info-clock_speed;
+ if ((info-clkrc CLK_EXT) == 0 (info-clkrc CLK_SCALE)
1)
+ cp-timeperframe.denominator /= (info-clkrc
CLK_SCALE);
+ } else {
+ ov7670_get_framerate(sd, cp-timeperframe);
+ }
return 0;
}
@@ -958,18 +1032,23 @@ static int ov7670_s_parm(struct v4l2_subdev *sd, struct
v4l2_streamparm *parms)
if (cp-extendedmode != 0)
return -EINVAL;
- if (tpf-numerator == 0 || tpf-denominator == 0)
- div = 1; /* Reset to full rate */
- else
- div = (tpf-numerator * info-clock_speed) / tpf-denominator;
- if (div == 0)
- div = 1;
- else if (div CLK_SCALE)
- div = CLK_SCALE
[PATCH 5/5] media: ov7670: Add possibility to disable pixclk during hblank.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c |8
include/media/ov7670.h |1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 54fb535..f7e4341 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -211,6 +211,7 @@ struct ov7670_info {
u8 clkrc; /* Clock divider value */
bool use_smbus; /* Use smbus I/O instead of I2C */
bool pll_bypass;
+ bool pclk_hb_disable;
enum ov7670_model model;
};
@@ -1709,6 +1710,9 @@ static int ov7670_probe(struct i2c_client *client,
if (config-pll_bypass id-driver_data != MODEL_OV7670)
info-pll_bypass = true;
+
+ if (config-pclk_hb_disable)
+ info-pclk_hb_disable = true;
}
/* Make sure it's an ov7670 */
@@ -1735,6 +1739,10 @@ static int ov7670_probe(struct i2c_client *client,
tpf.denominator = 30;
ov7670_set_framerate(sd, tpf);
}
+
+ if (info-pclk_hb_disable)
+ ov7670_write(sd, REG_COM10, COM10_PCLK_HB);
+
return 0;
}
diff --git a/include/media/ov7670.h b/include/media/ov7670.h
index a68c8bb..1913d51 100644
--- a/include/media/ov7670.h
+++ b/include/media/ov7670.h
@@ -16,6 +16,7 @@ struct ov7670_config {
int clock_speed;/* External clock speed (MHz) */
bool use_smbus; /* Use smbus I/O instead of I2C */
bool pll_bypass;/* Choose whether to bypass the PLL */
+ bool pclk_hb_disable; /* Disable toggling pixclk during
horizontal blanking */
};
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] media: ov7670: driver cleanup and support for ov7674.
On 26 September 2012 11:47, Javier Martin javier.mar...@vista-silicon.com wrote: 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 in [1]. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.html Support is for ov7675, not ov7674, sorry for the typo. -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver
Hi Richard, On 20 September 2012 05:32, Richard Zhao richard.z...@freescale.com wrote: why is it a request-pull? After 5 version of Philipp's patches we have agreed they are good enough to be merged; they don't break anything related to the old codadx6 while provide support for the new coda7: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/53627 The pull request is a way to tell Mauro this is ready to be merged in his linux-media tree and making things easier for him. 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver
On 20 September 2012 10:03, Richard Zhao richard.z...@freescale.com wrote: On Thu, Sep 20, 2012 at 09:10:46AM +0200, javier Martin wrote: Hi Richard, On 20 September 2012 05:32, Richard Zhao richard.z...@freescale.com wrote: why is it a request-pull? After 5 version of Philipp's patches we have agreed they are good enough to be merged; they don't break anything related to the old codadx6 while provide support for the new coda7: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/53627 The pull request is a way to tell Mauro this is ready to be merged in his linux-media tree and making things easier for him. I know the meaning. I just feel strange. Pull request is normally sent by maintainer to up level maintainer who agreed to receive pull request. This was discussed some time ago here: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/078862.html 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 27/34] media: mx2_camera: use managed functions to clean up code
Hi Shawn, On 18 September 2012 09:43, Shawn Guo shawn@linaro.org wrote: On Mon, Sep 17, 2012 at 03:36:07PM +0200, javier Martin wrote: This patch breaks the driver: Javier, Can you please apply the following change to see if it fixes the problem? Shawn @@ -1783,6 +1783,8 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev) goto exit; } + platform_set_drvdata(pdev, NULL); + pcdev-soc_host.drv_name= MX2_CAM_DRV_NAME, pcdev-soc_host.ops = mx2_soc_camera_host_ops, pcdev-soc_host.priv= pcdev; Yes. That fixes the problem. With this fix: Tested-by: Javier Martin javier.mar...@vista-silicon.com 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 this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 28/34] media: mx2_camera: remove mach/hardware.h inclusion
On 17 September 2012 15:59, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Mon, 17 Sep 2012, javier Martin wrote:
Hi Shawn,
On 17 September 2012 11:21, Guennadi Liakhovetski g.liakhovet...@gmx.de
wrote:
On Mon, 17 Sep 2012, Shawn Guo wrote:
It changes the driver to use platform_device_id rather than cpu_is_xxx
to determine the controller type, and updates the platform code
accordingly.
As the result, mach/hardware.h inclusion gets removed from the driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: linux-media@vger.kernel.org
Tested-by: Javier Martin javier.mar...@vista-silicon.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
i.MX25 support is broken and is scheduled for removal.
It is not yet, I haven't pushed those your patches yet.
Thanks
Guennadi
I think we should not keep on trying to maintain it. Couldn't we just
drop it? It only makes maintenance tasks more difficult.
Thanks
Guennadi
---
arch/arm/mach-imx/clk-imx25.c |6 +-
arch/arm/mach-imx/clk-imx27.c |6 +-
arch/arm/mach-imx/devices/devices-common.h |1 +
arch/arm/mach-imx/devices/platform-mx2-camera.c | 12 +--
drivers/media/video/mx2_camera.c| 95
+--
5 files changed, 85 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index 1aea073..71fe521 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -231,9 +231,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[esdhc2_ipg_per], per,
sdhci-esdhc-imx25.1);
clk_register_clkdev(clk[esdhc2_ipg], ipg, sdhci-esdhc-imx25.1);
clk_register_clkdev(clk[esdhc2_ahb], ahb, sdhci-esdhc-imx25.1);
- clk_register_clkdev(clk[csi_ipg_per], per, mx2-camera.0);
- clk_register_clkdev(clk[csi_ipg], ipg, mx2-camera.0);
- clk_register_clkdev(clk[csi_ahb], ahb, mx2-camera.0);
+ clk_register_clkdev(clk[csi_ipg_per], per, imx25-camera.0);
+ clk_register_clkdev(clk[csi_ipg], ipg, imx25-camera.0);
+ clk_register_clkdev(clk[csi_ahb], ahb, imx25-camera.0);
clk_register_clkdev(clk[dummy], audmux, NULL);
clk_register_clkdev(clk[can1_ipg], NULL, flexcan.0);
clk_register_clkdev(clk[can2_ipg], NULL, flexcan.1);
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 5ff5cf0..e26de52 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -224,7 +224,7 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[per3_gate], per, imx-fb.0);
clk_register_clkdev(clk[lcdc_ipg_gate], ipg, imx-fb.0);
clk_register_clkdev(clk[lcdc_ahb_gate], ahb, imx-fb.0);
- clk_register_clkdev(clk[csi_ahb_gate], ahb, mx2-camera.0);
+ clk_register_clkdev(clk[csi_ahb_gate], ahb, imx27-camera.0);
clk_register_clkdev(clk[usb_div], per, fsl-usb2-udc);
clk_register_clkdev(clk[usb_ipg_gate], ipg, fsl-usb2-udc);
clk_register_clkdev(clk[usb_ahb_gate], ahb, fsl-usb2-udc);
@@ -251,8 +251,8 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[i2c2_ipg_gate], NULL, imx21-i2c.1);
clk_register_clkdev(clk[owire_ipg_gate], NULL, mxc_w1.0);
clk_register_clkdev(clk[kpp_ipg_gate], NULL, imx-keypad);
- clk_register_clkdev(clk[emma_ahb_gate], emma-ahb, mx2-camera.0);
- clk_register_clkdev(clk[emma_ipg_gate], emma-ipg, mx2-camera.0);
+ clk_register_clkdev(clk[emma_ahb_gate], emma-ahb,
imx27-camera.0);
+ clk_register_clkdev(clk[emma_ipg_gate], emma-ipg,
imx27-camera.0);
clk_register_clkdev(clk[emma_ahb_gate], ahb, m2m-emmaprp.0);
clk_register_clkdev(clk[emma_ipg_gate], ipg, m2m-emmaprp.0);
clk_register_clkdev(clk[iim_ipg_gate], iim, NULL);
diff --git a/arch/arm/mach-imx/devices/devices-common.h
b/arch/arm/mach-imx/devices/devices-common.h
index 7f2698c..8112a1a 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -202,6 +202,7 @@ struct platform_device *__init imx_add_mx3_sdc_fb(
#include linux/platform_data/camera-mx2.h
struct imx_mx2_camera_data {
+ const char *devid;
resource_size_t iobasecsi;
resource_size_t iosizecsi;
resource_size_t irqcsi;
diff --git a/arch/arm/mach-imx/devices/platform-mx2-camera.c
b/arch/arm/mach-imx/devices/platform-mx2-camera.c
index 9ad5b2d..b88877d 100644
--- a/arch/arm/mach-imx/devices/platform-mx2-camera.c
+++ b/arch/arm/mach-imx/devices/platform-mx2-camera.c
@@ -9,14 +9,16 @@
#include mach/hardware.h
#include devices-common.h
-#define imx_mx2_camera_data_entry_single(soc)
\
+#define imx_mx2_camera_data_entry_single(soc, _devid
