[PATCH] mt9p031: Do not use PLL if external frequency is the same as target frequency.
This patch adds a check to see whether ext_freq and target_freq are equal and,
if true, PLL won't be used.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mt9p031.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
index 5cfa39f..42b5d18 100644
--- a/drivers/media/video/mt9p031.c
+++ b/drivers/media/video/mt9p031.c
@@ -117,6 +117,7 @@ struct mt9p031 {
u16 xskip;
u16 yskip;
+ bool use_pll;
const struct mt9p031_pll_divs *pll;
/* Registers cache */
@@ -201,10 +202,16 @@ static int mt9p031_pll_get_divs(struct mt9p031 *mt9p031)
struct i2c_client *client = v4l2_get_subdevdata(mt9p031-subdev);
int i;
+ if (mt9p031-pdata-ext_freq == mt9p031-pdata-target_freq) {
+ mt9p031-use_pll = false;
+ return 0;
+ }
+
for (i = 0; i ARRAY_SIZE(mt9p031_divs); i++) {
if (mt9p031_divs[i].ext_freq == mt9p031-pdata-ext_freq
mt9p031_divs[i].target_freq == mt9p031-pdata-target_freq) {
mt9p031-pll = mt9p031_divs[i];
+ mt9p031-use_pll = true;
return 0;
}
}
@@ -385,8 +392,10 @@ static int mt9p031_s_stream(struct v4l2_subdev *subdev,
int enable)
MT9P031_OUTPUT_CONTROL_CEN, 0);
if (ret 0)
return ret;
-
- return mt9p031_pll_disable(mt9p031);
+ if (mt9p031-use_pll)
+ return mt9p031_pll_disable(mt9p031);
+ else
+ return 0;
}
ret = mt9p031_set_params(mt9p031);
@@ -399,7 +408,10 @@ static int mt9p031_s_stream(struct v4l2_subdev *subdev,
int enable)
if (ret 0)
return ret;
- return mt9p031_pll_enable(mt9p031);
+ if (mt9p031-use_pll)
+ return mt9p031_pll_enable(mt9p031);
+ else
+ return 0;
}
static int mt9p031_enum_mbus_code(struct v4l2_subdev *subdev,
--
1.7.0.4
--
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] mt9p031: Do not use PLL if external frequency is the same as target frequency.
On 6 September 2011 12:27, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, On Tuesday 06 September 2011 12:03:00 Javier Martin wrote: This patch adds a check to see whether ext_freq and target_freq are equal and, if true, PLL won't be used. Thanks for the patch. As you're touching PLL code, what about fixing PLL setup by computing parameters dynamically instead of using a table of hardcoded values ? :-) Hi Laurent, I'm not exactly struggling with PLL code right now. I've just get a new prototype which provides an external 48MHz oscillator for the clock. So, no need to use PLL there and thus the purpose of this patch. However, as you said, dynamic configuration of PLL is one of the pending issues on the driver and I might address it myself in the future, but it depends on requirements of the project. 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
[RFC] Support for H.264/MPEG4 encoder (VPU) in i.MX27.
Hi, we are planning to add support to H.264/MPEG4 encoder inside the i.MX27 to v4l2. It is mainly a hardware module that has the following features: - It needs two input buffers (current frame and previous frame). - It produces a third buffer as output, containing the encoded frame, and generates an IRQ when that happens. - Previous three buffers need contiguous physical memory addresses and probably some alignment requirements. - It needs an external firmware to be loaded in another contiguous memory buffer. I would like to know what is your opinion on this, what v4l2 framework should we use to deal with it, etc... I guess Multi Format Codec 5.1 driver for s5pv210 and exynos4 SoC is the most similar piece of HW I've found so far but it has not yet entered mainline [1] Note that mx2_camera driver is still using soc-camera framework and soc-camera doesn't seem to be ready for integration with pad level API [2]. For that reason we think we could develop this VPU driver separately. [1] http://www.spinics.net/lists/linux-media/msg35040.html [2] http://www.open-technology.de/index.php?/categories/2-SoC-camera -- 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: How to handle different media bus format and actual video output format in soc camera?
On 14 September 2011 12:34, javier Martin javier.mar...@vista-silicon.com wrote: Hi, I'm trying to add support for YUV420 format to mx2_camera.c soc-camera host driver. In my system, an imx27_visstrim_m10 board, this host is connected to a tvp5151 chip which is only able to transfer pixels in this format through the media bus: V4L2_MBUS_FMT_YUYV8_2X8. However, imx27 eMMa has the possibility to get this data from the bus and convert it to a YUV420 format on the fly. What is the right way to handle this properly in soc-camera? I've been analyzing some code related to the matter and it seems soc_camera_xlate_by_fourcc() [1] only supports raw formats from the sensor [2]. OK, I think I found a good example of this in the pxa driver. I post it here just in case someone has the same problem in a future: http://lxr.linux.no/#linux+v3.0.4/drivers/media/video/pxa_camera.c#L1246 -- 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: [RFC] Support for H.264/MPEG4 encoder (VPU) in i.MX27.
OK, thank you for your interest, it seems quite clear to me now. However, I'll wait to see what Sascha has to say about this to avoid duplication of work. -- 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
UVC with continuous video buffers.
Hi, we have a system with a UVC camera connected to USB to acquire video images and a hardware processor which needs continuous memory buffers to process them. I've been looking at the current version of UVC drivers and it seems it allocates buffers using vmalloc_32() call: http://lxr.linux.no/#linux+v3.1/drivers/media/video/uvc/uvc_queue.c#L135 I am interested to extend the driver to support contiguous memory buffers and send it to mainline. What is the right way to achieve this? Can anyone please point me to a video driver example where continuous memory allocation is used? 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
Re: UVC with continuous video buffers.
Hi Devin, thank you for your answer. On 2 November 2011 17:12, Devin Heitmueller dheitmuel...@kernellabs.com wrote: I've actually got a very similar issue and have been looking into it (an em28xx device on OMAP requiring contiguous physical memory for the hardware H.264 encoder). One thing you may definitely want to check out is the patch sent earlier today with subject: My case is a i.MX27 SoC with its internal H.264 encoder. [PATCH] media: vb2: vmalloc-based allocator user pointer handling While that patch is intended for videobuf2, you might be able to copy the core logic into videobuf-vmalloc. I've seen a recent patch by Laurent Pinchart which provides vb2 support for UVC driver. It might also help: [PATCH 2/2] uvcvideo: Use videobuf2-vmalloc There are other drivers which use USERPTR provided buffers (which are allocated as contiguous memory from userland [i.e. vfpe_capture accepting buffers from cmemk on the OMAP platform]), but they typically do DMA so it's not really useful as an example where you have a USB based device. If you get it working, by all means send the code to the ML so others can benefit. Sure, though I will need some help because it seems some related frameworks are not ready for what we want to achieve. -- 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
Current soc-camera status.
Hi, does currently soc-camera support using soc-camera host drivers with non soc-camera sensors? For instance, I would like to use soc-camera host driver mx2_camera.c with non soc-camera sensor tvp5150.c. How much effort would it take to accomplish this goal? Does it depends on conversion to v4l2-device API? (http://www.open-technology.de/index.php?/pages/soc-camera.html) 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
mt9p031 support for Beagleboard.
Hi, we are going to receive a Beagleaboard xM board in a couple of days. One of the things we would like to test is video capture. When it comes to the DM3730 SoC, it seems the support is given through these two files: http://lxr.linux.no/#linux+v2.6.37.3/drivers/media/video/davinci/vpfe_capture.c -- to capture from sensor http://lxr.linux.no/#linux+v2.6.37.3/drivers/media/video/davinci/dm644x_ccdc.c -- to convert from Bayer RGB to YUV On the other hand, the sensor we would like to test is mt9p031 which comes with LI-5M03, a module that can be attached to Beagleboard xM directly: https://www.leopardimaging.com/Beagle_Board_xM_Camera.html By a lot of googling I found this version of a driver for mt9p031 which is developed by Guennadi Liakhovetski. It is located in a 2.6.32 based branch: http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/media/video/mt9p031.c;h=66b5e54d0368052bf76796aa846e9464e42204bb;hb=HEAD The question is, what does this driver lack for not entering into mainline? We would be very interested on helping it make it. -- 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: mt9p031 support for Beagleboard.
[Hiremath, Vaibhav] Martin, All above driver files are not applicable for AM/DM37x ISP camera module, you should be looking at driver/media/video/omap3isp/ Hi, Which git repository are you referring to? Because, in last stable version there is no such folder: http://lxr.linux.no/#linux+v2.6.37.3/drivers/media/video -- 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: mt9p031 support for Beagleboard.
By a lot of googling I found this version of a driver for mt9p031 which is developed by Guennadi Liakhovetski. It is located in a 2.6.32 based branch: That's a back-port of my patches by a third party;) Probably, never actually tested. http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/media/video/mt9p031.c;h=66b5e54d0368052bf76796aa846e9464e42204bb;hb=HEAD So, you mean there is a cleaner, more recent version of this code? Could you please point me to it? I prefer to start developing on a more reliable source. 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
mt9t111 sensor on Beagleboard xM
Hi, I've just received a LI-LBCM3M1 camera module from Leopard Imaging and I want to test it with my Beagleboard xM. This module has a mt9t111 sensor. At first glance, this driver (http://lxr.linux.no/#linux+v2.6.38/drivers/media/video/mt9t112.c) supports mt9t111 sensor and uses both soc-camera and v4l2-subdev frameworks. I am trying to somehow connect this sensor with the omap3isp driver recently merged (I'm working with latest mainline kernel), however, I found an issue when trying to pass mt9t112_camera_info data to the sensor driver in my board specific file. It seems that this data is passed through soc-camera but omap3isp doesn't use soc-camera. Do you know what kind of changes are required to adapt this driver so that it can be used with omap3isp? 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
Re: mt9t111 sensor on Beagleboard xM
On 8 April 2011 17:07, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, On Friday 08 April 2011 17:02:48 javier Martin wrote: Hi, I've just received a LI-LBCM3M1 camera module from Leopard Imaging and I want to test it with my Beagleboard xM. This module has a mt9t111 sensor. At first glance, this driver (http://lxr.linux.no/#linux+v2.6.38/drivers/media/video/mt9t112.c) supports mt9t111 sensor and uses both soc-camera and v4l2-subdev frameworks. I am trying to somehow connect this sensor with the omap3isp driver recently merged (I'm working with latest mainline kernel), however, I found an issue when trying to pass mt9t112_camera_info data to the sensor driver in my board specific file. It seems that this data is passed through soc-camera but omap3isp doesn't use soc-camera. Do you know what kind of changes are required to adapt this driver so that it can be used with omap3isp? The OMAP3 ISP driver isn't compatible with the soc-camera framework, as you correctly noticed. You will need to port the MT9T111 driver to pad-level subdev operations. You can find a sensor driver (MT9V032) implementing pad-level subdev operations at http://git.linuxtv.org/pinchartl/media.git?a=commit;h=940b87a5cb7ea3f3cff16454e9085e33ab340064 -- Regards, Laurent Pinchart Hi Laurent, thank you for your quick answer. Does the fact of adding pad-level subdev operations for the sensor break old way of doing things? I mean, if I port MT9T111 driver to pad-level subdev operations would it be accepted for mainline or would it be rejected since it breaks something older? 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
Re: mt9t111 sensor on Beagleboard xM
Hi Laurent, Adding pad-level operations will not break any existing driver, as long as you keep the existing operations functional. Is it really possible to have a sensor driver supporting soc-camera, v4l2-subdev and pad-level operations? I've been reviewing the code of mt9t112 and I'm not very sure soc-camera code can be easily isolated. What is the future of soc-camera anyway? Since it seems v4l2-subdev and media-controller clearly make it deprecated. Wouldn't it be more suitable to just develop a separate mt9t112 driver which includes v4l2-subdev and pad-level operations without soc-camera? Thanks. -- 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
Let's submit mt9p031 to mainline.
Hi, I finally received my LI-5M03 for the Beagleboard which includes mt9p031 sensor. I know Guennadi has somewhere an outdated version of a driver for it. I would like to help you out on updating the driver so that it can be submitted to mainline. Guennadi please, if you could point me out to that code I could start the job myself. Just one question: what GIT repository + branch should I choose to work on, so that we can seamlessly integrate the changes later? 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
Re: Let's submit mt9p031 to mainline.
On 19 April 2011 11:19, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 19 Apr 2011, javier Martin wrote: Hi, I finally received my LI-5M03 for the Beagleboard which includes mt9p031 sensor. I know Guennadi has somewhere an outdated version of a driver for it. I would like to help you out on updating the driver so that it can be submitted to mainline. Guennadi please, if you could point me out to that code I could start the job myself. Just one question: what GIT repository + branch should I choose to work on, so that we can seamlessly integrate the changes later? I wanted to update the code, but usb is currently broken on beagle-board, so, I cannot work with it. I'm waiting for it to be fixed to continue with that. Thanks Guennadi So you are planning to do it yourself. Is there anything I can do to help? What kernel are you using? In 2.6.38 usb works fine for me in the Beagleboard xM. -- 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: Let's submit mt9p031 to mainline.
Sure, feel free to grab this http://download.open-technology.de/BeagleBoard_xM-MT9P031/ follow instructions in the text file and update the sources. I'll be happy, if you manage to mainline it yourself, since I'm currently under a pretty severe time-pressure. Thanks, I'll do my best. What kernel are you using? In 2.6.38 usb works fine for me in the Beagleboard xM. No, 2.6.38 is no good, it doesn't have MC / omap3isp in it. What GIT repository + branch should I use for developing then? -- 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: Let's submit mt9p031 to mainline.
All right, just one more question, does this patch for mt9p031 apply in any repository out there out of the box so that I can test my hardware first? 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
Problems with omap3isp + mt9p031 in Beagleboard xM.
:0xde00fc00 *pte:0x [ 81.958038] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x 4 (0) [-] 4294967295 76800 bytes 81.999073 1303817703.103504 9.050 fps [ 82.055755] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x [ 82.069396] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x 5 (1) [-] 4294967295 76800 bytes 82.110380 1303817703.215391 8.984 fps [ 82.167114] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x [ 82.180755] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x 6 (2) [-] 4294967295 76800 bytes 82.221743 1303817703.326723 8.980 fps [ 82.278442] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x [ 82.292114] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x 7 (3) [-] 4294967295 76800 bytes 82.333128 1303817703.437529 8.978 fps [ 82.389801] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x [ 82.403442] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x 8 (0) [-] 4294967295 76800 bytes 82.57 1303817703.549407 8.982 fps [ 82.501159] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x [ 82.514801] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x 9 (1) [-] 4294967295 76800 bytes 82.555816 1303817703.660736 8.980 fps [ 82.612518] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x [ 82.626159] omap-iommu omap-iommu.0: isp: errs:0x da:0x pgd:0xdedb *pgd:0x9e00fc01 pte:0xde00fc00 *pte:0x Captured 10 frames in 1.377928 seconds (7.257273 fps, 557358.584774 B/s). 4 buffers released. And the image files I get are filled with instead of useful data. Does anybody know whether those iommu errors are harmless? Do I need to enable CAM mux inside arch/arm/mach-omap2/board-omap3beagle.c which are currently disabled using an ifdef? 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
Re: Problems with omap3isp + mt9p031 in Beagleboard xM.
Please try the patch at http://thread.gmane.org/gmane.linux.ports.arm.omap/56662 That fixed it, 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
Current status report of mt9p031.
Hi,
for those interested on mt9p031 working on the Beagleboard xM. I
attach 2 patches here that must be applied to kernel-2.6.39-rc commit
e8dad69408a9812d6bb42d03e74d2c314534a4fa
These patches include a fix for the USB ethernet.
What currently works:
- Test suggested by Guennadi
(http://download.open-technology.de/BeagleBoard_xM-MT9P031/).
Known problems:
1. You might be required to create device node for the sensor manually:
mknod /dev/v4l-subdev8 c 81 15
chown root:video /dev/v4l-subdev8
2. Images captured seem to be too dull and dark. Values of pixels seem
always to low, it seems to me like MSB of each pixel were stuck at 0.
I hope someone can help here.
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
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a45cd64..c437391 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -178,7 +178,7 @@ obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o
-obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \
+obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..eba2235 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -52,6 +52,7 @@
#include hsmmc.h
#include timer-gp.h
#include pm.h
+#include control.h
#define NAND_BLOCK_SIZE SZ_128K
@@ -273,6 +274,44 @@ static struct regulator_consumer_supply beagle_vsim_supply = {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct regulator_init_data beagle_vaux3 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux3_supply,
+};
+
+/* VAUX4 for CAM_2V8 */
+static struct regulator_init_data beagle_vaux4 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux4_supply,
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -309,6 +348,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+ * Power on camera interface - only on pre-production, not
+ * needed on production boards
+ */
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +499,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -472,6 +522,7 @@ static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+// omap_register_i2c_bus(2, 100, NULL, 0);
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom, ARRAY_SIZE(beagle_i2c_eeprom));
@@ -598,6 +649,34 @@ static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+// #if 0
+ /* Camera - Parallel Data */
+ OMAP3_MUX(CAM_D0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D8, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D9, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D10
omap3isp clock problems on Beagleboard xM.
Hi, as you know I'm currently working on submitting mt9p031 driver to mainline, testing it with my Beagleboard xM. While I was trying to clean Guennadi's patches I ran into the attached patch which changes a call to omap3isp_get(isp); into isp_enable_clocks(isp);. I don't think this is clean since it would unbalance the number of omap3isp_get() vs omap3isp_put() and we probably don't want that. What seems clear is if we don't apply this patch the clock is not actually enabled. According to my debugging results isp_disable_clocks() is never called, so, after the first call to isp_enable_clocks() there shouldn't be any need to enable the clocks again. Guennadi, do you know what is the cause of the problem? -- 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 diff --git a/drivers/media/video/omap3isp/isp.c b/drivers/media/video/omap3isp/isp.c index 472a693..6a6ea86 100644 --- a/drivers/media/video/omap3isp/isp.c +++ b/drivers/media/video/omap3isp/isp.c @@ -177,6 +177,8 @@ static void isp_disable_interrupts(struct isp_device *isp) isp_reg_writel(isp, 0, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0ENABLE); } +static int isp_enable_clocks(struct isp_device *isp); + /** * isp_set_xclk - Configures the specified cam_xclk to the desired frequency. * @isp: OMAP3 ISP device @@ -239,7 +241,7 @@ static u32 isp_set_xclk(struct isp_device *isp, u32 xclk, u8 xclksel) /* Do we go from stable whatever to clock? */ if (divisor = 2 isp-xclk_divisor[xclksel - 1] 2) - omap3isp_get(isp); + isp_enable_clocks(isp); /* Stopping the clock. */ else if (divisor 2 isp-xclk_divisor[xclksel - 1] = 2) omap3isp_put(isp);
Re: omap3isp clock problems on Beagleboard xM.
Thank you two guys for your answer. I don't remember exactly, but it didn't work without this patch. I know it is not clean and shouldn't be needed, so, if now it works also without it - perfect! You can start, stop, and restart streaming without this patch and it all works? Then certainly it should be dropped. No, sorry, what I meant is although, according to my debugging results the patch shouldn't be needed, it still does not work without it. I'll try to track down the issue and I'll work on a fix myself. -- 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] OMAP3: ISP: Fix unbalanced use of omap3isp_get().
Hi Laurent, This won't work. Let's assume the following sequence of events: - Userspace opens the sensor subdev device node - The sensor driver calls to board code to turn the sensor clock on - Board code calls to the ISP driver to turn XCLK on - The ISP driver calls isp_enable_clocks() ... - Userspace opens an ISP video device node - The ISP driver calls isp_get(), incrementing the reference count - Userspace closes the ISP video device node - The ISP driver calls isp_put(), decrementing the reference count - The reference count reaches 0, the ISP driver calls isp_disable_clocks() The sensor will then loose its clock, even though the sensor subdev device node is still opened. Of course, you are right, I hadn't thought of it this way. Could you please explain why the existing code doesn't work on your hardware ? Apparently, it is a mistake related to the sensor driver. Sorry about that. Just one question. As I can see from mt9v032 driver, open callback is used to enable clock and close callback is used to disable clock. Does this mean that if sensor device node is not held open video won't work? i.e, the following wouldn't work since (2) opens the sensor (enables clock) and closes it again (disables clock) and (3) only opens CCDC device node (enables clock with a wrong setting, since it was previously set to 0 by (2) ) : (1) ./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' (2) ./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' (3) ./yavta -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F `./media-ctl -e OMAP3 ISP CCDC output -- 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: Current status report of mt9p031.
On 5 May 2011 18:55, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
Hi Javier,
Here's the review of 0002-mt9p031.patch.
[snip]
+static int mt9p031_probe(struct i2c_client *client,
+ const struct i2c_device_id *did)
+{
+ struct mt9p031 *mt9p031;
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct mt9p031_platform_data *pdata = client-dev.platform_data;
+ struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ int ret;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
+ dev_warn(adapter-dev,
+ I2C-Adapter doesn't support I2C_FUNC_SMBUS_WORD\n);
+ return -EIO;
+ }
+
+ mt9p031 = kzalloc(sizeof(struct mt9p031), GFP_KERNEL);
+ if (!mt9p031)
+ return -ENOMEM;
+
+ v4l2_i2c_subdev_init(mt9p031-subdev, client, mt9p031_subdev_ops);
+
+// struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+// isp_set_xclk(isp, 16*1000*1000, ISP_XCLK_A);
+
+ mt9p031-rect.left = 0/*MT9P031_COLUMN_SKIP*/;
+ mt9p031-rect.top = 0/*MT9P031_ROW_SKIP*/;
+ mt9p031-rect.width = MT9P031_MAX_WIDTH;
+ mt9p031-rect.height = MT9P031_MAX_HEIGHT;
+
+ switch (pdata-data_shift) {
+ case 2:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG8_1X8;
+ break;
+ case 1:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG10_1X10;
+ break;
+ case 0:
+ mt9p031-format.code = V4L2_MBUS_FMT_SBGGR12_1X12;
+ }
Why ? The sensor produces 12-bit data, you shouldn't fake other data widths.
Hi Laurent,
I was fixing all the issues you have pointed out when I ran into this.
It is true that mt9p031 produces 12-bit data only. However, when
connected to omap3isp it is possible to discard 4 least significant
bits (i.e. changing V4L2_MBUS_FMT_SGRBG12_1X12 into
V4L2_MBUS_FMT_SGRBG8_1X8).
The point is, if I just force mt9p031-format.code =
V4L2_MBUS_FMT_SGRBG12_1X12; then the following test will fail:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
Unable to set format: Invalid argument (-22) ---
v4l2_subdev_set_format() fails which is quite logical since that
format is now not defined in mt9p031.c
And this test will fail too:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F
`./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000
Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
Video format set: width: 320 height: 240 buffer size: 76800
Video format: GRBG (47425247) 320x240
4 buffers requested.
length: 76800 offset: 0
Buffer 0 mapped at address 0x40133000.
length: 76800 offset: 77824
Buffer 1 mapped at address 0x401e3000.
length: 76800 offset: 155648
Buffer 2 mapped at address 0x4021e000.
length: 76800 offset: 233472
Buffer 3 mapped at address 0x40368000.
Unable to start streaming: 22. --- ioctl(VIDIOC_STREAMON) fails
What is the clean way of doing this?
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
Re: Current status report of mt9p031.
Please try replacing the media-ctl -f line with ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \ OMAP3 ISP CCDC:0[SGRBG8 320x240], \ OMAP3 ISP CCDC:1[SGRBG8 320x240]' -- Regards, Laurent Pinchart Hi Laurent, that didn't work either (Unable to start streaming: 32.) -- 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: Current status report of mt9p031.
On 10 May 2011 11:53, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Tuesday 10 May 2011 11:49:10 javier Martin wrote: Please try replacing the media-ctl -f line with ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \ OMAP3 ISP CCDC:0[SGRBG8 320x240], \ OMAP3 ISP CCDC:1[SGRBG8 320x240]' -- Regards, Laurent Pinchart Hi Laurent, that didn't work either (Unable to start streaming: 32.) With the latest 2.6.39-rc ? Lane-shifter support has been introduced very recently. Can you post the output of media-ctl -p after configuring formats on your pipeline ? -- Regards, Laurent Pinchart Sure, this is the output you requested: root@beagleboard:~# ./media-ctl -p Opening media device /dev/media0 Enumerating entities Found 16 entities Enume rating pads and links Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCP2 input':pad0 [] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Output - 'OMAP3 ISP CCP2':pad0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Input [SGRBG10 4096x4096] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CSI2a output':pad0 [] - 'OMAP3 ISP CCDC':pad0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Input - 'OMAP3 ISP CSI2a':pad1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG8 320x240] - 'OMAP3 ISP CCP2':pad1 [] - 'OMAP3 ISP CSI2a':pad1 [] - 'mt9p031 2-0048':pad0 [ACTIVE] pad1: Output [SGRBG8 320x240] - 'OMAP3 ISP CCDC output':pad0 [ACTIVE] - 'OMAP3 ISP resizer':pad0 [] pad2: Output [SGRBG8 320x239] - 'OMAP3 ISP preview':pad0 [] - 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Input - 'OMAP3 ISP CCDC':pad1 [ACTIVE] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad2 [] - 'OMAP3 ISP preview input':pad0 [] pad1: Output [YUYV 4082x4088] - 'OMAP3 ISP preview output':pad0 [] - 'OMAP3 ISP resizer':pad0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Output - 'OMAP3 ISP preview':pad0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Input - 'OMAP3 ISP preview':pad1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Input [YUYV 4095x4095 (4,6)/4086x4082] - 'OMAP3 ISP CCDC':pad1 [] - 'OMAP3 ISP preview':pad1 [] - 'OMAP3 ISP resizer input':pad0 [] pad1: Output [YUYV 4096x4095] - 'OMAP3 ISP resizer output':pad0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Output - 'OMAP3 ISP resizer':pad0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Input - 'OMAP3 ISP resizer':pad1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Input
Re: Current status report of mt9p031.
I almost forget, I am using 2.6.39-rc commit bd99337e95b6bba976e41a5f3cf65c1f04069156 -- 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: Current status report of mt9p031.
On 10 May 2011 14:25, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, On Tuesday 10 May 2011 13:05:35 javier Martin wrote: I almost forget, I am using 2.6.39-rc commit bd99337e95b6bba976e41a5f3cf65c1f04069156 There's no such commit in mainline. -- Regards, Laurent Pinchart Sorry Laurent, the commit is 5895198c56d131cc696556a45f7ff0ea99ac297b -- 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: Current status report of mt9p031.
Hi Laurent,
information for data lane shifter is passed through platform data:
/**
* struct isp_parallel_platform_data - Parallel interface platform data
* @data_lane_shift: Data lane shifter
* 0 - CAMEXT[13:0] - CAM[13:0]
* 1 - CAMEXT[13:2] - CAM[11:0]
* 2 - CAMEXT[13:4] - CAM[9:0]
* 3 - CAMEXT[13:6] - CAM[7:0]
* @clk_pol: Pixel clock polarity
* 0 - Non Inverted, 1 - Inverted
* @bridge: CCDC Bridge input control
* ISPCTRL_PAR_BRIDGE_DISABLE - Disable
* ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
* ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
*/
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
This way I am able to convert from 12bpp to 8bpp:
data_lane_shift = 2 and bridge = ISPCTRL_PAR_BRIDGE_DISABLE
--
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
[no subject]
This series of patches provides support for Aptina mt9p031 sensor on Beagleboard xM. It has been tested using media-ctl and yavta. -- 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] mt9p031: Add mt9p031 sensor driver.
It has been tested in beagleboard xM, using LI-5M03 module.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile|1 +
drivers/media/video/mt9p031.c | 773 +++
include/media/mt9p031.h | 11 +
include/media/v4l2-chip-ident.h |1 +
5 files changed, 794 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..32df8bd 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,14 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate Micron MT9P031 support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This driver supports MT9P031 cameras from Micron
+ This is a Video4Linux2 sensor-level driver for the Micron
+ mt0p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..850cfec
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,773 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_SKIP 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_SKIP 16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RESET 0x0d
+#defineMT9P031_RESET_ENABLE1
+#defineMT9P031_RESET_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+#define MT9P031_MAX_HEIGHT 1944
+#define MT9P031_MAX_WIDTH 2592
+#define MT9P031_MIN_HEIGHT 2
+#define MT9P031_MIN_WIDTH 18
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct mt9p031_platform_data *pdata;
+ int model; /* V4L2_IDENT_MT9P031* codes from v4l2-chip-ident.h
[PATCH 2/2] OMAP3BEAGLE: Add support for mt9p031 sensor (LI-5M03 module).
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 130 ++-
arch/arm/mach-omap2/devices.c |2 +-
2 files changed, 127 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..ccd72dc 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,15 +24,20 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
-
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include media/mt9p031.h
+
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -47,12 +52,18 @@
#include plat/nand.h
#include plat/usb.h
#include plat/omap_device.h
+#include plat/i2c.h
#include mux.h
#include hsmmc.h
#include timer-gp.h
#include pm.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+#include ../../../drivers/media/video/omap3isp/ispreg.h
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
#define NAND_BLOCK_SIZESZ_128K
/*
@@ -273,6 +284,44 @@ static struct regulator_consumer_supply beagle_vsim_supply
= {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct regulator_init_data beagle_vaux3 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux3_supply,
+};
+
+/* VAUX4 for CAM_2V8 */
+static struct regulator_init_data beagle_vaux4 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux4_supply,
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -309,6 +358,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+* Power on camera interface - only on pre-production, not
+* needed on production boards
+*/
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +509,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -463,15 +523,16 @@ static struct i2c_board_info __initdata
beagle_i2c_boardinfo[] = {
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
- {
- I2C_BOARD_INFO(eeprom, 0x50),
- },
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
};
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0); /* Enable I2C2 for camera */
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
@@ -654,6 +715,62 @@ static void __init beagle_opp_init(void)
return;
}
+extern struct platform_device omap3isp_device;
+
+static int beagle_cam_set_xclk(struct
Re: [PATCH 1/2] mt9p031: Add mt9p031 sensor driver.
On 17 May 2011 13:47, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Laurent Thanks for your review! Javier, if you like, you can wait a couple of days until I find some time to review the driver, or you can submit a version, addressing Laurent's points, but be prepared to have to do another one;) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ OK, I think I'll wait to have Guennadi's review too. Thank you both. -- 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] mt9p031: Add mt9p031 sensor driver.
Hi Laurent,
I've already fixed almost every issue you pointed out.
However, I still have got some doubts that I hope you can clarify.
On 17 May 2011 13:33, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Javier,
Thanks for the patch.
On Tuesday 17 May 2011 11:28:47 Javier Martin wrote:
It has been tested in beagleboard xM, using LI-5M03 module.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
+
+static int mt9p031_power_on(struct mt9p031 *mt9p031)
+{
+ int ret;
+
+ if (mt9p031-pdata-set_xclk)
+ mt9p031-pdata-set_xclk(mt9p031-subdev, 5400);
+ /* turn on VDD_IO */
+ ret = regulator_enable(mt9p031-reg_2v8);
+ if (ret) {
+ pr_err(Failed to enable 2.8v regulator: %d\n, ret);
+ return -1;
+ }
I would enable the regulator first. As a general rule, chips should be powered
up before their I/Os are actively driven.
You need to restore registers here, otherwise all controls set by the user
will not be applied to the device.
It's my mistake. This driver uses two regulators: 1,8 and 2,8 V
respectively. 2,8V regulator powers analog part and I/O whereas 1,8V
one powers the core. What I failed to do was keeping 1,8V regulator
always powered on, so that register configuration was not lost, and
power 2,8V regulator on and off as needed since it does not affect
register values. However, I messed it all up.
Ideally I would have to power 1,8V regulator on and off too. However,
as you wisely pointed out, registers should be restored in that case.
How am I supposed to keep track of register values? Are there any
helper functions I can use for that purpose or must I create a custom
register cache? Do you know any driver that uses this technique?
[snip]
+static int mt9p031_set_params(struct i2c_client *client,
+ struct v4l2_rect *rect, u16 xskip, u16 yskip)
set_params should apply the parameters, not change them. They should have
already been validated by the callers.
mt9p031_set_params() function is used by mt9p031_set_crop() and
mt9p031_set_format(), as you have correctly stated, these functions
shouldn' apply parameters but only change them.
I've checked mt9v032 driver and it is as you said. The question is,
where should these parameters get applied then?
+static int mt9p031_registered(struct v4l2_subdev *sd)
+{
+ struct mt9p031 *mt9p031;
+ mt9p031 = container_of(sd, struct mt9p031, subdev);
+
+ mt9p031_power_off(mt9p031);
What's that for ?
+ return 0;
+}
Since mt9p031_power_off() and mt9p031_power_on() functions
disable/enable the 2,8V regulator which powers I/O, it must be powered
on during probe and after registering, it can be safely powered off.
You have a set_xclk callback to board code, so I assume the chip can be driven
by one of the OMAP3 ISP XCLK signals. To call back to the OMAP3 ISP from board
code, you need to get hold of the OMAP3 ISP device pointer. Your next patch
exports omap3isp_device, but I'm not sure that's the way to go. One option is
struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
but that requires the subdev to be registered before the function can be
called. In that case you would need to move the probe code to the registered
subdev internal function.
Yes, I tried using that function but it didn't work because subdev
hadn't been registeret yet.
A clean solution is needed in the long run, preferably not involving board
code at all. It would be nice if the OMAP3 ISP driver could export XCLKA/XCLKB
as generic clock objects.
So, what should I do in order to submit the driver to mainline?
Do you want me to move the probe code to registered callback?
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
Re: [PATCH 1/2] mt9p031: Add mt9p031 sensor driver.
Hi Ivan, On 17 May 2011 19:14, Ivan Nazarenko ivan.nazare...@gmail.com wrote: Javier, I have been using the aptina patch (https://github.com/Aptina/BeagleBoard-xM) on beagleboard while waiting linux-media solve this mt9p031 issue. Now that you have something working, I would like to try it - but I would like to know what is the clock rate you actually drove the sensor. Reviewing your path, I suppose it is 54MHz, so you would be achieving some 10 full 5MPix frames/s from the sensor. Is that correct? (the aptina patch delivers less than 4 fps). Yes, you are right. Whereas clock rate is set to 54MHz, with my oscilloscope I have measured 57 MHz. -- 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 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
This driver adds basic support for Aptina mt9p031 sensor.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 751 +
include/media/mt9p031.h | 11 +
4 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..5c96b89 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,14 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate Aptina MT9P031 support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This driver supports MT9P031 cameras from Micron
+ This is a Video4Linux2 sensor-level driver for the Micron
+ mt0p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..e406b64
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,751 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_SKIP 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_SKIP 16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RST0x0d
+#defineMT9P031_RST_ENABLE 1
+#defineMT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+#define MT9P031_MAX_HEIGHT 1944
+#define MT9P031_MAX_WIDTH 2592
+#define MT9P031_MIN_HEIGHT 2
+#define MT9P031_MIN_WIDTH 18
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct mt9p031_platform_data *pdata;
+ struct mutex power_lock;
+ int power_count;
+ u16 xskip;
+ u16 yskip;
+ u16 output_control
[PATCH v2 2/2] OMAP3BEAGLE: Add support for mt9p031 sensor driver.
isp.h file has to be included as a temporal measure
since clocks of the isp are not exposed yet.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 127 ++-
1 files changed, 123 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..f52e6ae 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,15 +24,20 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
-
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include media/mt9p031.h
+
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -47,12 +52,17 @@
#include plat/nand.h
#include plat/usb.h
#include plat/omap_device.h
+#include plat/i2c.h
#include mux.h
#include hsmmc.h
#include timer-gp.h
#include pm.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
#define NAND_BLOCK_SIZESZ_128K
/*
@@ -273,6 +283,44 @@ static struct regulator_consumer_supply beagle_vsim_supply
= {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct regulator_init_data beagle_vaux3 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux3_supply,
+};
+
+/* VAUX4 for CAM_2V8 */
+static struct regulator_init_data beagle_vaux4 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux4_supply,
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -309,6 +357,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+* Power on camera interface - only on pre-production, not
+* needed on production boards
+*/
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +508,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -463,15 +522,16 @@ static struct i2c_board_info __initdata
beagle_i2c_boardinfo[] = {
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
- {
- I2C_BOARD_INFO(eeprom, 0x50),
- },
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
};
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0); /* Enable I2C2 for camera */
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
@@ -654,6 +714,60 @@ static void __init beagle_opp_init(void)
return;
}
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp
Re: [PATCH v2 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
On 23 May 2011 05:01, Chris Rodley carlight...@yahoo.co.nz wrote: Error when using media-ctl as below with v2 mt9p031 driver from Javier and latest media-ctl version. Is there a patch I missed to add different formats - or maybe my command is wrong? # ./media-ctl -v -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] # ./media-ctl -v -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Setting up format SGRBG8 320x240 on pad mt9p031 2-0048/0 Unable to set format: Invalid argument (-22) I also tried: ./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-0048:0[SGRBG10 752x480 (1,5)/752x480], OMAP3 ISP CCDC:0[SGRBG8 752x480], OMAP3 ISP CCDC:1[SGRBG8 752x480]' With the same result. Cheers, Chris -- 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 Please, try the following: ./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' Thanks. -- 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] OMAP3BEAGLE: Add support for mt9p031 sensor driver.
On 22 May 2011 15:49, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Javier,
linux-omap should be CC'ed - added.
In addition to Koen's comments, some comments below.
On 05/20/11 16:47, Javier Martin wrote:
isp.h file has to be included as a temporal measure
since clocks of the isp are not exposed yet.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 127
++-
1 files changed, 123 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..f52e6ae 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,15 +24,20 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
-
+#include linux/gpio.h
Why include this for second time?
Good catch, I'll fix it.
[snip]
@@ -309,6 +357,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+ * Power on camera interface - only on pre-production, not
+ * needed on production boards
+ */
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
Why not gpio_request_one()?
Just to follow the same approach as in the rest of the code.
Maybe a further patch could change all gpio_request() uses to
gpio_request_one().
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +508,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -463,15 +522,16 @@ static struct i2c_board_info __initdata
beagle_i2c_boardinfo[] = {
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
- {
- I2C_BOARD_INFO(eeprom, 0x50),
- },
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
};
This part of the hunk is not related to the patch
and should be in a separate (cleanup) patch.
Sure, I'll fix it.
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0); /* Enable I2C2 for camera */
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
@@ -654,6 +714,60 @@ static void __init beagle_opp_init(void)
return;
}
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+ int ret;
+
+ ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+ return 0;
+}
Why do you need ret variable here, if you always return zero?
You are right, it's not needed any longer.
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
static void __init omap3_beagle_init(void
Re: [PATCH v2 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
On 21 May 2011 17:29, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 20 May 2011, Javier Martin wrote: This driver adds basic support for Aptina mt9p031 sensor. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig | 8 + drivers/media/video/Makefile | 1 + drivers/media/video/mt9p031.c | 751 + include/media/mt9p031.h | 11 + 4 files changed, 771 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..5c96b89 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -329,6 +329,14 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- + This driver supports MT9P031 cameras from Micron + This is a Video4Linux2 sensor-level driver for the Micron + mt0p031 5 Mpixel camera. Two sentences seem to repeat the same with other words, and it's better to stay consistent: just use Aptina everywhere, maybe put Micron in brackets at one location. OK, I will fix it. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..912b29b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..e406b64 --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,751 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/regulator/consumer.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-subdev.h +#include media/v4l2-device.h + +/* mt9p031 selected register addresses */ +#define MT9P031_CHIP_VERSION 0x00 +#define MT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START 0x01 Don't mix spaces and TABs between #define and the macro - just use one space everywhere. I've done this in order to follow Laurent's directions. He does the same in mt9v032 driver. So, unless Laurent and you agree I think I won't change it. +#define MT9P031_ROW_START_SKIP 54 +#define MT9P031_COLUMN_START 0x02 +#define MT9P031_COLUMN_START_SKIP 16 +#define MT9P031_WINDOW_HEIGHT 0x03 +#define MT9P031_WINDOW_WIDTH 0x04 +#define MT9P031_H_BLANKING 0x05 +#define MT9P031_H_BLANKING_VALUE 0 +#define MT9P031_V_BLANKING 0x06 +#define MT9P031_V_BLANKING_VALUE 25 +#define MT9P031_OUTPUT_CONTROL 0x07 +#define MT9P031_OUTPUT_CONTROL_CEN 2 +#define MT9P031_OUTPUT_CONTROL_SYN 1 +#define MT9P031_SHUTTER_WIDTH_UPPER 0x08 +#define MT9P031_SHUTTER_WIDTH 0x09 +#define MT9P031_PIXEL_CLOCK_CONTROL 0x0a +#define MT9P031_FRAME_RESTART 0x0b +#define MT9P031_SHUTTER_DELAY 0x0c +#define MT9P031_RST 0x0d +#define MT9P031_RST_ENABLE 1 +#define MT9P031_RST_DISABLE 0 +#define MT9P031_READ_MODE_1 0x1e +#define MT9P031_READ_MODE_2 0x20 +#define MT9P031_READ_MODE_2_ROW_MIR 0x8000 +#define MT9P031_READ_MODE_2_COL_MIR 0x4000 +#define MT9P031_ROW_ADDRESS_MODE 0x22 +#define MT9P031_COLUMN_ADDRESS_MODE
Re: [PATCH v2 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
Hi, Laurent, Guennadi,
thank you for your review. I've already fixed most of the issues.
On 23 May 2011 11:03, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Guennadi and Javier,
On Saturday 21 May 2011 17:29:18 Guennadi Liakhovetski wrote:
On Fri, 20 May 2011, Javier Martin wrote:
[snip]
diff --git a/drivers/media/video/mt9p031.c
b/drivers/media/video/mt9p031.c new file mode 100644
index 000..e406b64
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
[snip]
+}
+
+static int mt9p031_power_on(struct mt9p031 *mt9p031)
+{
+ int ret;
+
+ /* turn on VDD_IO */
+ ret = regulator_enable(mt9p031-reg_2v8);
+ if (ret) {
+ pr_err(Failed to enable 2.8v regulator: %d\n, ret);
dev_err()
+ return ret;
+ }
+ if (mt9p031-pdata-set_xclk)
+ mt9p031-pdata-set_xclk(mt9p031-subdev, 5400);
Can you make 5400 a #define at the beginning of the file ?
You should soft-reset the chip here by calling mt9p031_reset().
If I do this, I would be force to cache some registers and restart
them. I've tried to do this but I don't know what is failing that
there are some artifacts consisting on horizontal black lines in the
image.
Please, let me push this to mainline without this feature as a first
step, since I'll have to spend some assigned to another project.
[snip]
+ */
+static int mt9p031_video_probe(struct i2c_client *client)
+{
+ s32 data;
+ int ret;
+
+ /* Read out the chip version register */
+ data = reg_read(client, MT9P031_CHIP_VERSION);
+ if (data != MT9P031_CHIP_VERSION_VALUE) {
+ dev_err(client-dev,
+ No MT9P031 chip detected, register read %x\n, data);
+ return -ENODEV;
+ }
+
+ dev_info(client-dev, Detected a MT9P031 chip ID %x\n, data);
+
+ ret = mt9p031_reset(client);
+ if (ret 0)
+ dev_err(client-dev, Failed to initialise the camera\n);
If you move the soft-reset operation to mt9p031_power_on(), you don't need to
call it here.
The reason for this is the same as before. I haven't still been able
to success on restarting registers and getting everything to work
fine.
It would be great if you allowed me to push this as it is as an
intermediate step.
[snip]
+ mt9p031-rect.width = MT9P031_MAX_WIDTH;
+ mt9p031-rect.height = MT9P031_MAX_HEIGHT;
+
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG12_1X12;
+
+ mt9p031-format.width = MT9P031_MAX_WIDTH;
+ mt9p031-format.height = MT9P031_MAX_HEIGHT;
+ mt9p031-format.field = V4L2_FIELD_NONE;
+ mt9p031-format.colorspace = V4L2_COLORSPACE_SRGB;
+
+ mt9p031-xskip = 1;
+ mt9p031-yskip = 1;
+
+ mt9p031-reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(mt9p031-reg_1v8)) {
+ ret = PTR_ERR(mt9p031-reg_1v8);
+ pr_err(Failed 1.8v regulator: %d\n, ret);
dev_err()
+ goto e1v8;
+ }
The driver can be used with boards where either or both of the 1.8V and 2.8V
supplies are always on, thus not connected to any regulator. I'm not sure how
that's usually handled, if board code should define an always-on power
supply, or if the driver shouldn't fail when no regulator is present. In any
case, this must be handled.
I think board code should define an always-on power supply.
+
+ mt9p031-reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(mt9p031-reg_2v8)) {
+ ret = PTR_ERR(mt9p031-reg_2v8);
+ pr_err(Failed 2.8v regulator: %d\n, ret);
ditto
+ goto e2v8;
+ }
+ /* turn on core */
+ ret = regulator_enable(mt9p031-reg_1v8);
+ if (ret) {
+ pr_err(Failed to enable 1.8v regulator: %d\n, ret);
ditto
+ goto e1v8en;
+ }
+ return 0;
Why do you leave core power on at the end of probe() ? You should only turn it
on when needed.
Just as I said, because restarting registers does not work yet.
--
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][RFC] Add mt9p031 sensor support.
This RFC includes a power management implementation that causes
the sensor to show images with horizontal artifacts (usually
monochrome lines that appear on the image randomly).
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 841 +
include/media/mt9p031.h | 11 +
4 files changed, 860 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..8a596cc 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,13 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate Aptina MT9P031 support
+ depends on I2C VIDEO_V4L2
+ ---help---
+This is a Video4Linux2 sensor-level driver for the Aptina
+(Micron) mt9p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..04d8812
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,841 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+#define MT9P031_PIXCLK_FREQ5400
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_DEF 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_DEF16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RST0x0d
+#defineMT9P031_RST_ENABLE 1
+#defineMT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+#define MT9P031_WINDOW_HEIGHT_MAX 1944
+#define MT9P031_WINDOW_WIDTH_MAX 2592
+#define MT9P031_WINDOW_HEIGHT_MIN 2
+#define MT9P031_WINDOW_WIDTH_MIN 18
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct mt9p031_platform_data *pdata
Re: [PATCH v2 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
Please, do not remove anyone from the CC list. On 25 May 2011 05:45, Chris Rodley carlight...@yahoo.co.nz wrote: Hi, Have upgraded the driver to Javier's latest RFC driver. Still having problems viewing output. Setting up with: # media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] # media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0 Format set: SGRB Setting up format SGRBG12 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG12 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG8 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1 Format set: SGRBG8 320x240 Then: # yavta -f SGRBG8 -s 320x240 -n 4 --capture=100 -F /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: width: 320 height: 240 buffer size: 76800 Video format: GRBG (47425247) 320x240 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x4006c000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x40222000. length: 76800 offset: 155648 Buffer 2 mapped at address 0x4025e000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x402f. After this it hangs and will exit on 'ctrl c': omap3isp omap3isp: CCDC stop timeout! Any ideas what is causing this problem? No idea, it works for me. Note you have to apply RFC + PATCH v2 2/2. Please, double check. Also, if you have problems with last RFC patch you should answer RFC mail. Not this one. 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
Re: [PATCH][RFC] Add mt9p031 sensor support.
Hi, thank you for the review, I agree with you on all the suggested changes except on this one: On 25 May 2011 10:05, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, Thanks for the patch. Here's a review of the power handling code. On Tuesday 24 May 2011 16:30:43 Javier Martin wrote: This RFC includes a power management implementation that causes the sensor to show images with horizontal artifacts (usually monochrome lines that appear on the image randomly). Signed-off-by: Javier Martin javier.mar...@vista-silicon.com [snip] diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..04d8812 --- /dev/null +++ b/drivers/media/video/mt9p031.c [snip] +#define MT9P031_WINDOW_HEIGHT_MAX 1944 +#define MT9P031_WINDOW_WIDTH_MAX 2592 +#define MT9P031_WINDOW_HEIGHT_MIN 2 +#define MT9P031_WINDOW_WIDTH_MIN 18 Can you move those 4 constants right below MT9P031_WINDOW_HEIGHT and MT9P031_WINDOW_WIDTH ? The max values are not correct, according to the datasheet they should be 2005 and 2751. In figure 4, it says active image size is 2592 x 1944 Why should I include active boundary and dark pixels? -- 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] Second RFC version of mt9p031 sensor with power managament.
It includes several fixes pointed out by Laurent Pinchart. However,
the BUG which shows artifacts in the image (horizontal lines) still
persists. It won't happen if 1v8 regulator is not disabled (i.e.
comment line where it is disabled in function mt9p031_power_off).
I know there can be some other details to fix but I would like someone
could help in the power management issue.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 752 +
include/media/mt9p031.h | 11 +
4 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..8a596cc 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,13 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate Aptina MT9P031 support
+ depends on I2C VIDEO_V4L2
+ ---help---
+This is a Video4Linux2 sensor-level driver for the Aptina
+(Micron) mt9p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..39579de
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,752 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+#define MT9P031_PIXCLK_FREQ5400
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_DEF 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_DEF16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#defineMT9P031_WINDOW_HEIGHT_MAX 1944
+#defineMT9P031_WINDOW_HEIGHT_MIN 2
+#define MT9P031_WINDOW_WIDTH 0x04
+#defineMT9P031_WINDOW_WIDTH_MAX2592
+#defineMT9P031_WINDOW_WIDTH_MIN18
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RST0x0d
+#defineMT9P031_RST_ENABLE 1
+#defineMT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+struct mt9p031 {
+ struct v4l2_subdev subdev
[RFC v3 1/2] Add mt9p031 sensor driver.
This patch applies on 2.6.39 (commit 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf).
It has some power management issue which causes horizontal random lines on
the image. If we do not disable 1v8 regulator, the problem disappears.
I would like to get some help on fixing whatever the problem with power
management is.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 841 +
include/media/mt9p031.h | 11 +
4 files changed, 860 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..cb87e35 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,13 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate Aptina MT9P031 support
+ depends on I2C VIDEO_V4L2
+ ---help---
+This is a Video4Linux2 sensor-level driver for the Aptina
+(Micron) mt9p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..242bea9
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,841 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+#define MT9P031_PIXCLK_FREQ5400
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_DEF 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_DEF16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RST0x0d
+#defineMT9P031_RST_ENABLE 1
+#defineMT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+#define MT9P031_WINDOW_HEIGHT_MAX 1944
+#define MT9P031_WINDOW_WIDTH_MAX 2592
+#define MT9P031_WINDOW_HEIGHT_MIN 2
+#define MT9P031_WINDOW_WIDTH_MIN 18
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad
[RFC v3 2/2] Add platform code to support mt9p031 (LI-5M03 module) in Beagleboard xM.
This patch is not ready to be submitted to mainline since it still
has some issues (code belonging to mt9p031 must be moved to a separate
file, etc...). However it is useful for you to test mt9p031 sensor
driver in kernel 2.6.39 (commit 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf).
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 121 +++
1 files changed, 121 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..3b55666 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,15 +24,21 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include media/mt9p031.h
+
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -47,12 +53,17 @@
#include plat/nand.h
#include plat/usb.h
#include plat/omap_device.h
+#include plat/i2c.h
#include mux.h
#include hsmmc.h
#include timer-gp.h
#include pm.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
#define NAND_BLOCK_SIZESZ_128K
/*
@@ -273,6 +284,44 @@ static struct regulator_consumer_supply beagle_vsim_supply
= {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct regulator_init_data beagle_vaux3 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux3_supply,
+};
+
+/* VAUX4 for CAM_2V8 */
+static struct regulator_init_data beagle_vaux4 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux4_supply,
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -309,6 +358,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+* Power on camera interface - only on pre-production, not
+* needed on production boards
+*/
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +509,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -472,6 +532,7 @@ static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0); /* Enable I2C2 for camera */
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
@@ -654,6 +715,61 @@ static void __init beagle_opp_init(void)
return;
}
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+ int ret;
+
+ ret = isp
Re: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On 26 May 2011 10:51, Koen Kooi k...@beagleboard.org wrote: Op 26 mei 2011, om 09:24 heeft Javier Martin het volgende geschreven: Hi Koen, On 25 May 2011 15:38, Koen Kooi k...@beagleboard.org wrote: Op 25 mei 2011, om 13:16 heeft Javier Martin het volgende geschreven: It includes several fixes pointed out by Laurent Pinchart. However, the BUG which shows artifacts in the image (horizontal lines) still persists. It won't happen if 1v8 regulator is not disabled (i.e. comment line where it is disabled in function mt9p031_power_off). I know there can be some other details to fix but I would like someone could help in the power management issue. I tried this + your beagle patch on 2.6.39 and both ISP and sensor being builtin to the kernel, I get the following: root@beagleboardxMC:~# media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1 ], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] root@beagleboardxMC:~# media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0 Format set: SGRBG12 320x240 Setting up format SGRBG12 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG12 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG8 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1 Format set: SGRBG8 320x240 oot@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 -F `media-ctl -e OMAP3 ISP CCDC output` Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 320x240 buffer size 76800 Video format: SGRBG8 (47425247) 320x240 buffer size 76800 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x4030d000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x4033. length: 76800 offset: 155648 Buffer 2 mapped at address 0x4042d000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x40502000. [ 4131.459930] omap3isp omap3isp: CCDC won't become idle! Please, test it again using new RFC v3 I've just submitted. Slightly better: Video format: SGRBG8 (47425247) 320x240 buffer size 76800 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x401d1000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x40266000. length: 76800 offset: 155648 Buffer 2 mapped at address 0x402c6000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x4036e000. 0 (0) [-] 4294967295 76800 bytes 110.899139 1306398890.364593 0.001 fps 1 (1) [-] 4294967295 76800 bytes 111.128997 1306398890.594421 4.351 fps [ 111.214019] omap3isp omap3isp: CCDC won't become idle! I have personally tested it against kernel 2.6.39 with the following .config file: And with that config: [ 4.250244] VFS: Cannot open root device mmcblk0p2 or unknown-block(179,2) [ 4.257720] Please append a correct root= boot option; here are the available partitions: [ 4.266540] b300 7977472 mmcblk0 driver: mmcblk [ 4.272125] b301 72261 mmcblk0p1 ----0mmcblk0p1 [ 4.280578] b302 7903980 mmcblk0p2 ----0mmcblk0p2 [ 4.289031] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) Which is the good old kernel-mux-is-broken problem again, after turning off kernel-mux: 0 (0) [-] 4294967295 76800 bytes 29.186920 1306399517.283752 0.001 fps 1 (1) [-] 4294967295 76800 bytes 29.416778 1306399517.513580 4.351 fps 2 (2) [-] 4294967295 76800 bytes 29.528137 1306399517.624938 8.980 fps [ 29.616943] omap3isp omap3isp: CCDC won't become idle! Are you using a LI-5M03 module? (https://www.leopardimaging.com/Beagle_Board_xM_Camera.html) I also added pull ups to the I2C2 line so that I could communicate with mt9p031. So that seems to be the same as with my config. How do I view the files yavta dumps? I use a patched version of yavta and Mplayer to see video (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) Then in my PC: nc -l 3000 | ./mplayer - -demuxer rawvideo -rawvideo w=320:h=240:format=ba81:size=76800 -vf ba81 -vo x11 In the Beagleboard: ./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' ./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F `./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000 -- 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
Re: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
OK, I think I've found the problem with the power management. As it is stated in mt9p031 datasheet [3] p 59, a sequence involving [VAA,VAA_PIX,VDD_PLL], [VDD,VDD_IO], [Reset] and [Ext Clk] must be followed in order to properly power up or down the sensor. If we take a look to the LI-5M031 schematic[1] and Beagleboard xM schematic [2] we'll notice that voltages are connected as follows: [VDD] (1,8V) --- V2.8 --- CAM_CORE --- VAUX3 TPS65950 [VDD_IO (VDDQ)] (1,8V) --- V1.8 --- CAM_IO --- VAUX4 TPS65950 [VAA, VAA_PIX, VDD_PLL] (2,8V) ---| U6 |-- V3.3VD -- HUB_3V3 --| U16 | enabled by USBHOST_PWR_EN -- LEDA TPS65950 VAUX3 (VDD) and VAUX4 (VDD_IO) are fine, they are only used for powering our camera sensor. However, when it comes to the analog part (VAA, VAA_PIX...), it is got from HUB_3V3 which is also used for powering USB and ethernet. If we really want to activate/deactivate regulators that power mt9p031 we need to follow [3] p59. However, for that purpose we need to ensure that a call to regulator_enable() or regulator_disable() will really power on/off that supply, otherwise the sequence won't be matched and the chip will have problems. Beagleboard xM is a good example of platform where this happens since HUB_3V3 and thus (VAA, VAA_PIX, etc...) cannot be deactivated since it is being used by other devices. But there could be others. So, as a conclusion, and in order to unblock my work, my purpose for power management in mt9p031 would be the following: - Drop regulator handling as we cannot guarantee that power on sequence will be accomplished. - Keep on asserting/de-asserting reset which saves a lot of power. - Also activate/deactivate clock when necessary to save some power. I'm looking forward to read your comments on this. [1] https://www.leopardimaging.com/uploads/li-5m03_camera_board_v2.pdf [2] http://beagle.s3.amazonaws.com/design/xM-A3/BB-xM_Schematic_REVA3.pdf [3] http://www.aptina.com/products/image_sensors/mt9p031i12stc/ -- 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][RFC] Add mt9p031 sensor support.
On 25 May 2011 11:43, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, On Wednesday 25 May 2011 11:41:42 javier Martin wrote: Hi, thank you for the review, I agree with you on all the suggested changes except on this one: On 25 May 2011 10:05, Laurent Pinchart wrote: On Tuesday 24 May 2011 16:30:43 Javier Martin wrote: This RFC includes a power management implementation that causes the sensor to show images with horizontal artifacts (usually monochrome lines that appear on the image randomly). Signed-off-by: Javier Martin javier.mar...@vista-silicon.com [snip] diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..04d8812 --- /dev/null +++ b/drivers/media/video/mt9p031.c [snip] +#define MT9P031_WINDOW_HEIGHT_MAX 1944 +#define MT9P031_WINDOW_WIDTH_MAX 2592 +#define MT9P031_WINDOW_HEIGHT_MIN 2 +#define MT9P031_WINDOW_WIDTH_MIN 18 Can you move those 4 constants right below MT9P031_WINDOW_HEIGHT and MT9P031_WINDOW_WIDTH ? The max values are not correct, according to the datasheet they should be 2005 and 2751. In figure 4, it says active image size is 2592 x 1944 Why should I include active boundary and dark pixels? Users might want to get the dark pixels for black level compensation purpose. As the chip allows for that, it should be supported. The default should of course be the active area of 2592 x 1944 pixels. OK, that sounds reasonable. However, that would include black pixels that are located at the beginning of the array (0,0) to (16, 54), which means that users would have to specify a crop value of (15,54) to eliminate those initial black level pixels. Which seems quite unnatural to me. Another option could be setting (16,54) as default values and allowing to introduce negative cropping values. Is this possible? And finally, the most sensible idea IMHO could be not letting the user to see pixels from (0,0) to (15,54) (setting 15,54 as minimum and default )and, for black level compensation, ending pixels could be used (2608,1998) to (2751, 2003). What do you think? -- 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On 27 May 2011 16:31, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, On Thursday 26 May 2011 13:31:37 javier Martin wrote: OK, I think I've found the problem with the power management. As it is stated in mt9p031 datasheet [3] p 59, a sequence involving [VAA,VAA_PIX,VDD_PLL], [VDD,VDD_IO], [Reset] and [Ext Clk] must be followed in order to properly power up or down the sensor. If we take a look to the LI-5M031 schematic[1] and Beagleboard xM schematic [2] we'll notice that voltages are connected as follows: [VDD] (1,8V) --- V2.8 --- CAM_CORE --- VAUX3 TPS65950 [VDD_IO (VDDQ)] (1,8V) --- V1.8 --- CAM_IO --- VAUX4 TPS65950 [VAA, VAA_PIX, VDD_PLL] (2,8V) ---| U6 |-- V3.3VD -- HUB_3V3 --| U16 | enabled by USBHOST_PWR_EN -- LEDA TPS65950 VAUX3 (VDD) and VAUX4 (VDD_IO) are fine, they are only used for powering our camera sensor. However, when it comes to the analog part (VAA, VAA_PIX...), it is got from HUB_3V3 which is also used for powering USB and ethernet. *sigh* Why do hardware designers do things like that, really ? If we really want to activate/deactivate regulators that power mt9p031 we need to follow [3] p59. However, for that purpose we need to ensure that a call to regulator_enable() or regulator_disable() will really power on/off that supply, otherwise the sequence won't be matched and the chip will have problems. Beagleboard xM is a good example of platform where this happens since HUB_3V3 and thus (VAA, VAA_PIX, etc...) cannot be deactivated since it is being used by other devices. But there could be others. So, as a conclusion, and in order to unblock my work, my purpose for power management in mt9p031 would be the following: - Drop regulator handling as we cannot guarantee that power on sequence will be accomplished. - Keep on asserting/de-asserting reset which saves a lot of power. - Also activate/deactivate clock when necessary to save some power. I'm looking forward to read your comments on this. Even if you keep the sensor powered all the time, how do you ensure that VAUX3 is available before HUB_3V3 when the system is powered up ? You can't. And in fact what happens its the opposite. But it works. On the other hand, not being able to disable/enable HUB_3V3 can make, as a hardware guy has told me, power on reset internal circuit not to work [1] and thus the power down / power up fails. [1] http://en.wikipedia.org/wiki/Power-on_reset -- 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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
On 30 May 2011 08:48, Koen Kooi k...@beagleboard.org wrote: Op 30 mei 2011, om 04:13 heeft Chris Rodley het volgende geschreven: On 29/05/11 03:04, Guennadi Liakhovetski wrote: On Sat, 28 May 2011, Guennadi Liakhovetski wrote: Hi Javier On Thu, 26 May 2011, javier Martin wrote: I use a patched version of yavta and Mplayer to see video (http://download.open-technology.de/BeagleBoard_xM-MT9P031/) Are you really using those versions and patches, as described in BBxM-MT9P031.txt? I don't think those versions still work with 2.6.39, they don't even compile for me. Whereas if I take current HEAD, it builds and media-ctl seems to run error-free, but yavta produces no output. Ok, sorry for the noise. It works with current media-ctl with no patches, so, we better don't try to confuse our users / testers:) Thanks Guennadi Hi, Still no luck getting the v3 patch working. I did go back and re-test the first v1 patch that Javier released. This works fine with the same version of media-ctl and yavta. So it isn't either of those programs that is causing the problem. Must be something else. Will wait and see how Koen goes. I'm still stuck in isp did no go idle land, so even if yavta works, I can't get any output. It did output 3 frames to disk a few days ago, but that got deleted on reboot :( I don't know guys what to tell you. I use kernel 2.6.39 + last version of my patches + old patched yavta version (http://download.open-technology.de/BeagleBoard_xM-MT9P031/). Guennadi, did you manage to get it working? I'm preparing new patches for kernel 2.6.39 which I think should be ready for submission. I'll send them during the morning. 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 v4 1/2] Add support for mt9p031 Aptina (Micron) sensor.
This patch adds basic support (no controls) for mt9p031 sensor. It applies on kernel 2.6.39. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 699 + include/media/mt9p031.h | 11 + 4 files changed, 718 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..cb87e35 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -329,6 +329,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- +This is a Video4Linux2 sensor-level driver for the Aptina +(Micron) mt9p031 5 Mpixel camera. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..912b29b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..61b46a0 --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,699 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-subdev.h +#include media/v4l2-device.h + +#define MT9P031_PIXCLK_FREQ5400 + +#define MT9P031_CHIP_VERSION 0x00 +#defineMT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START 0x01 +#defineMT9P031_ROW_START_MIN 1 +#defineMT9P031_ROW_START_MAX 2004 +#defineMT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#defineMT9P031_COLUMN_START_MIN1 +#defineMT9P031_COLUMN_START_MAX2750 +#defineMT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT 0x03 +#defineMT9P031_WINDOW_HEIGHT_MIN 2 +#defineMT9P031_WINDOW_HEIGHT_MAX 2003 +#defineMT9P031_WINDOW_HEIGHT_DEF 2003 +#define MT9P031_WINDOW_WIDTH 0x04 +#defineMT9P031_WINDOW_WIDTH_MIN18 +#defineMT9P031_WINDOW_WIDTH_MAX2751 +#defineMT9P031_WINDOW_WIDTH_DEF2751 +#define MT9P031_H_BLANKING 0x05 +#defineMT9P031_H_BLANKING_VALUE0 +#define MT9P031_V_BLANKING 0x06 +#defineMT9P031_V_BLANKING_VALUE25 +#define MT9P031_OUTPUT_CONTROL 0x07 +#defineMT9P031_OUTPUT_CONTROL_CEN 2 +#defineMT9P031_OUTPUT_CONTROL_SYN 1 +#define MT9P031_SHUTTER_WIDTH_UPPER0x08 +#define MT9P031_SHUTTER_WIDTH 0x09 +#define MT9P031_PIXEL_CLOCK_CONTROL0x0a +#define MT9P031_FRAME_RESTART 0x0b +#define MT9P031_SHUTTER_DELAY 0x0c +#define MT9P031_RST0x0d +#defineMT9P031_RST_ENABLE 1 +#defineMT9P031_RST_DISABLE 0 +#define MT9P031_READ_MODE_10x1e +#define MT9P031_READ_MODE_20x20 +#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000 +#defineMT9P031_READ_MODE_2_COL_MIR 0x4000 +#define MT9P031_ROW_ADDRESS_MODE 0x22 +#define MT9P031_COLUMN_ADDRESS_MODE0x23 +#define MT9P031_GLOBAL_GAIN0x35
[PATCH v4 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.
Since isp clocks have not been exposed yet, this patch
includes a temporal solution for testing mt9p031 driver
in Beagleboard xM.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3beagle-camera.c | 88
arch/arm/mach-omap2/board-omap3beagle.c| 58
3 files changed, 147 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..05cd983 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) +=
board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
+ board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..840f8f3
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,88 @@
+#include linux/gpio.h
+#include linux/regulator/machine.h
+
+#include plat/i2c.h
+
+#include media/mt9p031.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
+
+static struct regulator *reg_1v8, *reg_2v8;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+ int ret;
+
+ ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+ return 0;
+}
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
+void __init beagle_camera_init(void)
+{
+ reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(reg_1v8))
+ pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_1v8);
+
+ reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(reg_2v8))
+ pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_2v8);
+
+ omap_register_i2c_bus(2, 100, NULL, 0);
+ gpio_request(MT9P031_RESET_GPIO, cam_rst);
+ gpio_direction_output(MT9P031_RESET_GPIO, 0);
+ omap3_init_camera(beagle_isp_platform_data);
+}
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..0bdc522 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,12 +24,16 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
@@ -47,6 +51,7 @@
#include plat/nand.h
#include plat/usb.h
#include plat/omap_device.h
+#include plat/i2c.h
#include mux.h
#include hsmmc.h
@@ -273,6 +278,44 @@ static struct regulator_consumer_supply beagle_vsim_supply
= {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply
Re: [beagleboard] [PATCH v4 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.
On 31 May 2011 09:59, Koen Kooi k...@dominion.thruhere.net wrote: Op 31 mei 2011, om 09:52 heeft Koen Kooi het volgende geschreven: Op 30 mei 2011, om 10:37 heeft Javier Martin het volgende geschreven: Since isp clocks have not been exposed yet, this patch includes a temporal solution for testing mt9p031 driver in Beagleboard xM. When compiling both as Y I get: [ 4.231628] mt9p031 2-0048: Failed to reset the camera [ 4.237030] omap3isp omap3isp: Failed to power on: -121 [ 4.242523] mt9p031 2-0048: Failed to power on device: -121 [ 4.248474] isp_register_subdev_group: Unable to register subdev mt9p031 I tried on an xM rev A2 and xM rev C, same error on both Crap, I get the same error here. Sorry for the inconvenience. I'll send a new version in some minutes. -- 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 v5 1/2] Add support for mt9p031 Aptina (Micron) sensor.
This patch adds basic support (no controls) for mt9p031 sensor. It applies on kernel 2.6.39. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 699 + include/media/mt9p031.h | 11 + 4 files changed, 718 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..cb87e35 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -329,6 +329,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- +This is a Video4Linux2 sensor-level driver for the Aptina +(Micron) mt9p031 5 Mpixel camera. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..912b29b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..61b46a0 --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,699 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-subdev.h +#include media/v4l2-device.h + +#define MT9P031_PIXCLK_FREQ5400 + +#define MT9P031_CHIP_VERSION 0x00 +#defineMT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START 0x01 +#defineMT9P031_ROW_START_MIN 1 +#defineMT9P031_ROW_START_MAX 2004 +#defineMT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#defineMT9P031_COLUMN_START_MIN1 +#defineMT9P031_COLUMN_START_MAX2750 +#defineMT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT 0x03 +#defineMT9P031_WINDOW_HEIGHT_MIN 2 +#defineMT9P031_WINDOW_HEIGHT_MAX 2003 +#defineMT9P031_WINDOW_HEIGHT_DEF 2003 +#define MT9P031_WINDOW_WIDTH 0x04 +#defineMT9P031_WINDOW_WIDTH_MIN18 +#defineMT9P031_WINDOW_WIDTH_MAX2751 +#defineMT9P031_WINDOW_WIDTH_DEF2751 +#define MT9P031_H_BLANKING 0x05 +#defineMT9P031_H_BLANKING_VALUE0 +#define MT9P031_V_BLANKING 0x06 +#defineMT9P031_V_BLANKING_VALUE25 +#define MT9P031_OUTPUT_CONTROL 0x07 +#defineMT9P031_OUTPUT_CONTROL_CEN 2 +#defineMT9P031_OUTPUT_CONTROL_SYN 1 +#define MT9P031_SHUTTER_WIDTH_UPPER0x08 +#define MT9P031_SHUTTER_WIDTH 0x09 +#define MT9P031_PIXEL_CLOCK_CONTROL0x0a +#define MT9P031_FRAME_RESTART 0x0b +#define MT9P031_SHUTTER_DELAY 0x0c +#define MT9P031_RST0x0d +#defineMT9P031_RST_ENABLE 1 +#defineMT9P031_RST_DISABLE 0 +#define MT9P031_READ_MODE_10x1e +#define MT9P031_READ_MODE_20x20 +#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000 +#defineMT9P031_READ_MODE_2_COL_MIR 0x4000 +#define MT9P031_ROW_ADDRESS_MODE 0x22 +#define MT9P031_COLUMN_ADDRESS_MODE0x23 +#define MT9P031_GLOBAL_GAIN0x35
[PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.
Since isp clocks have not been exposed yet, this patch
includes a temporal solution for testing mt9p031 driver
in Beagleboard xM.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3beagle-camera.c | 90
arch/arm/mach-omap2/board-omap3beagle.c| 55 ++
3 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..05cd983 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) +=
board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
+ board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..04365b2
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,90 @@
+#include linux/gpio.h
+#include linux/regulator/machine.h
+
+#include plat/i2c.h
+
+#include media/mt9p031.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
+
+static struct regulator *reg_1v8, *reg_2v8;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+ int ret;
+
+ ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+ return 0;
+}
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
+static int __init beagle_camera_init(void)
+{
+ reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(reg_1v8))
+ pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_1v8);
+
+ reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(reg_2v8))
+ pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_2v8);
+
+ omap_register_i2c_bus(2, 100, NULL, 0);
+ gpio_request(MT9P031_RESET_GPIO, cam_rst);
+ gpio_direction_output(MT9P031_RESET_GPIO, 0);
+ omap3_init_camera(beagle_isp_platform_data);
+ return 0;
+}
+late_initcall(beagle_camera_init);
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..c18d21c 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,12 +24,16 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
@@ -47,6 +51,7 @@
#include plat/nand.h
#include plat/usb.h
#include plat/omap_device.h
+#include plat/i2c.h
#include mux.h
#include hsmmc.h
@@ -273,6 +278,44 @@ static struct regulator_consumer_supply beagle_vsim_supply
= {
static struct gpio_led gpio_leds[];
+static struct
Re: [beagleboard] [PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.
On 31 May 2011 15:34, Koen Kooi k...@beagleboard.org wrote: root@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 -F `media-ctl -e OMAP3 ISP CCDC output` Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 320x240 buffer size 76800 Video format: SGRBG8 (47425247) 320x240 buffer size 76800 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x402cf000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x402fe000. length: 76800 offset: 155648 Buffer 2 mapped at address 0x40362000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x40416000. 0 (0) [-] 4294967295 76800 bytes 167.403289 1306829219.931121 0.002 fps 1 (1) [-] 4294967295 76800 bytes 167.633148 1306829220.160980 4.350 fps 2 (2) [-] 4294967295 76800 bytes 167.744506 1306829220.272308 8.980 fps 3 (3) [-] 4294967295 76800 bytes 167.855865 1306829220.383667 8.980 fps 4 (0) [-] 4294967295 76800 bytes 167.967193 1306829220.495025 8.982 fps 5 (1) [-] 4294967295 76800 bytes 168.078552 1306829220.606384 8.980 fps 6 (2) [-] 4294967295 76800 bytes 168.189910 1306829220.717742 8.980 fps 7 (3) [-] 4294967295 76800 bytes 168.301269 1306829220.829071 8.980 fps 8 (0) [-] 4294967295 76800 bytes 168.412597 1306829220.940429 8.982 fps 9 (1) [-] 4294967295 76800 bytes 168.523956 1306829221.051788 8.980 fps Captured 10 frames in 1.254212 seconds (7.973134 fps, 612336.670356 B/s). 4 buffers released. So that seems to be working! I haven't checked the frames yet, but is isn't throwing ISP errors anymore. Great! Do you have a monochrome version of the same sensor? -- 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 v6 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
Clock frequency of 57MHz used in previous version was wrong since when VDD_IO is 1.8V it can only support 48MHz. Two new platform flags have been added: - vdd_io: indicates whether the chip is powered with 1.8 or 2.8 VDD_IO. So that it can use the maximum allowed frequency. - version: monochrome and color versions of the chip have exactly the same ID, so the only way to select one of them is through platform data. Internal PLL is now used to generate PIXCLK depending on VDD_IO. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 763 + include/media/mt9p031.h | 23 ++ 4 files changed, 794 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..cb87e35 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -329,6 +329,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- +This is a Video4Linux2 sensor-level driver for the Aptina +(Micron) mt9p031 5 Mpixel camera. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..912b29b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..cd830b1 --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,763 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-subdev.h +#include media/v4l2-device.h + +#define MT9P031_EXTCLK_FREQ2000 + +#define MT9P031_CHIP_VERSION 0x00 +#defineMT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START 0x01 +#defineMT9P031_ROW_START_MIN 1 +#defineMT9P031_ROW_START_MAX 2004 +#defineMT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#defineMT9P031_COLUMN_START_MIN1 +#defineMT9P031_COLUMN_START_MAX2750 +#defineMT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT 0x03 +#defineMT9P031_WINDOW_HEIGHT_MIN 2 +#defineMT9P031_WINDOW_HEIGHT_MAX 2003 +#defineMT9P031_WINDOW_HEIGHT_DEF 2003 +#define MT9P031_WINDOW_WIDTH 0x04 +#defineMT9P031_WINDOW_WIDTH_MIN18 +#defineMT9P031_WINDOW_WIDTH_MAX2751 +#defineMT9P031_WINDOW_WIDTH_DEF2751 +#define MT9P031_H_BLANKING 0x05 +#defineMT9P031_H_BLANKING_VALUE0 +#define MT9P031_V_BLANKING 0x06 +#defineMT9P031_V_BLANKING_VALUE25 +#define MT9P031_OUTPUT_CONTROL 0x07 +#defineMT9P031_OUTPUT_CONTROL_CEN 2 +#defineMT9P031_OUTPUT_CONTROL_SYN 1 +#define MT9P031_SHUTTER_WIDTH_UPPER0x08 +#define MT9P031_SHUTTER_WIDTH 0x09 +#defineMT9P031_PLL_CONTROL 0x10 +#defineMT9P031_PLL_CONTROL_PWROFF 0x0050 +#defineMT9P031_PLL_CONTROL_PWRON 0x0051 +#defineMT9P031_PLL_CONTROL_USEPLL 0x0052 +#defineMT9P031_PLL_CONFIG_10x11 +#define
[PATCH v6 2/2] Add support for mt9p031 sensor in Beagleboard XM.
New version and vdd_io flags have been added.
A subtle change now prevents camera from being registered
in the wrong platform.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3beagle-camera.c | 95
arch/arm/mach-omap2/board-omap3beagle.c| 55 ++
3 files changed, 151 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..05cd983 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) +=
board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
+ board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..2632557
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,95 @@
+#include linux/gpio.h
+#include linux/regulator/machine.h
+
+#include plat/i2c.h
+
+#include media/mt9p031.h
+#include asm/mach-types.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
+
+static struct regulator *reg_1v8, *reg_2v8;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+ int ret;
+
+ ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+ return 0;
+}
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+ .vdd_io = MT9P031_VDD_IO_1V8,
+ .version= MT9P031_COLOR_VERSION,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
+static int __init beagle_camera_init(void)
+{
+ if (!machine_is_omap3_beagle() || !cpu_is_omap3630())
+ return 0;
+
+ reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(reg_1v8))
+ pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_1v8);
+
+ reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(reg_2v8))
+ pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_2v8);
+
+ omap_register_i2c_bus(2, 100, NULL, 0);
+ gpio_request(MT9P031_RESET_GPIO, cam_rst);
+ gpio_direction_output(MT9P031_RESET_GPIO, 0);
+ omap3_init_camera(beagle_isp_platform_data);
+ return 0;
+}
+late_initcall(beagle_camera_init);
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..c18d21c 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,12 +24,16 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
@@ -47,6 +51,7 @@
#include plat/nand.h
#include plat/usb.h
Re: [beagleboard] [PATCH v6 2/2] Add support for mt9p031 sensor in Beagleboard XM.
Hi Koen, On 1 June 2011 20:08, Koen Kooi k...@beagleboard.org wrote: Op 1 jun 2011, om 17:36 heeft Javier Martin het volgende geschreven: New version and vdd_io flags have been added. A subtle change now prevents camera from being registered in the wrong platform. I get a decent picture now with the following: media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' yavta-nc --stdout -f SGRBG8 -s 320x240 -n 4 --capture=1 --skip 3 -F $(media-ctl -e OMAP3 ISP CCDC output) | mplayer-bayer - -demuxer rawvideo -rawvideo w=320:h=240:format=ba81:size=76800 -vo fbdev2 -vf ba81 720p also seems to work. It is really, really dark though. Is this due to missing controls or due to the laneshifting? I suspect it is due to the patched mplayer. I know this because I have enabled some custom patterns in the sensor, thus generating pure red, blue and green pictures and they didn't seem so when played through mplayer-bayer. You could try the same if you want. Just to confirm. -- 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 v6 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
OK Guennadi, I'll fix those cosmetics issues in my next version where I will add VFLIP and HFLIP control support (which I removed previously to make the code less complex). Now we talk about controls I have a question regarding controls defined in video subdevices like mt9p031 or mt9v032: What device node should I use to set these controls through an ioctl() ? For instance, with mt9p031 + Beagleboard xM we have: ./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' ./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F `./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000 Where root@beagleboard:~# ./media-ctl -e OMAP3 ISP CCDC output /dev/video2 However, if I try to set sensor controls using /dev/video2 I get an error (invalid argument). -- 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 v6 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
On 2 June 2011 12:36, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 2 Jun 2011, javier Martin wrote: OK Guennadi, I'll fix those cosmetics issues in my next version where I will add VFLIP and HFLIP control support (which I removed previously to make the code less complex). Please, don't. Let's first get the simple version of your driver in the mainline, then it can be extended. Just, please, make sure to address all remaining issues without changing anything else:) Ok, thanks. -- 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 v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
This version fixes some cosmetic issues pointed out by Guennadi. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 763 + include/media/mt9p031.h | 23 ++ 4 files changed, 794 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..5f851f0 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -329,6 +329,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- + This is a Video4Linux2 sensor-level driver for the Aptina + (Micron) mt9p031 5 Mpixel camera. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..912b29b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..36c47df --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,763 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-subdev.h +#include media/v4l2-device.h + +#define MT9P031_EXTCLK_FREQ2000 + +#define MT9P031_CHIP_VERSION 0x00 +#defineMT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START 0x01 +#defineMT9P031_ROW_START_MIN 1 +#defineMT9P031_ROW_START_MAX 2004 +#defineMT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#defineMT9P031_COLUMN_START_MIN1 +#defineMT9P031_COLUMN_START_MAX2750 +#defineMT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT 0x03 +#defineMT9P031_WINDOW_HEIGHT_MIN 2 +#defineMT9P031_WINDOW_HEIGHT_MAX 2003 +#defineMT9P031_WINDOW_HEIGHT_DEF 2003 +#define MT9P031_WINDOW_WIDTH 0x04 +#defineMT9P031_WINDOW_WIDTH_MIN18 +#defineMT9P031_WINDOW_WIDTH_MAX2751 +#defineMT9P031_WINDOW_WIDTH_DEF2751 +#define MT9P031_H_BLANKING 0x05 +#defineMT9P031_H_BLANKING_VALUE0 +#define MT9P031_V_BLANKING 0x06 +#defineMT9P031_V_BLANKING_VALUE25 +#define MT9P031_OUTPUT_CONTROL 0x07 +#defineMT9P031_OUTPUT_CONTROL_CEN 2 +#defineMT9P031_OUTPUT_CONTROL_SYN 1 +#define MT9P031_SHUTTER_WIDTH_UPPER0x08 +#define MT9P031_SHUTTER_WIDTH 0x09 +#defineMT9P031_PLL_CONTROL 0x10 +#defineMT9P031_PLL_CONTROL_PWROFF 0x0050 +#defineMT9P031_PLL_CONTROL_PWRON 0x0051 +#defineMT9P031_PLL_CONTROL_USEPLL 0x0052 +#defineMT9P031_PLL_CONFIG_10x11 +#defineMT9P031_PLL_CONFIG_1_M_48MHZ0x5000 +#defineMT9P031_PLL_CONFIG_1_N_48MHZ0x05 +#defineMT9P031_PLL_CONFIG_1_M_96MHZ0x3600 +#defineMT9P031_PLL_CONFIG_1_N_96MHZ0x05 +#defineMT9P031_PLL_CONFIG_20x12 +#defineMT9P031_PLL_CONFIG_2_P1_48MHZ 5 +#defineMT9P031_PLL_CONFIG_2_P1_96MHZ 2 +#define
Does omap3isp driver inherit controls of attached sensors?
Hi, I'm trying to add VFLIP control to the mt9p031 driver (don't worry Guennadi, I won't send the patch yet). For that purpose I've followed the code in mt9v032 sensor. When I try to query available controls using yavta I get the following: root@beagleboard:~# ./media-ctl -e OMAP3 ISP CCDC output /dev/video2 root@beagleboard:~# ./yavta -l /dev/video2 Device /dev/video2 opened: OMAP3 ISP CCDC output (media). No control found. As I have read here [1], drivers using subdevices should inherit their controls. Is this the case with omap3isp? [1] http://lxr.linux.no/#linux+v2.6.39/Documentation/video4linux/v4l2-controls.txt -- 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: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
On 8 June 2011 14:39, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Wed, 8 Jun 2011, Koen Kooi wrote: Op 8 jun 2011, om 13:57 heeft Laurent Pinchart het volgende geschreven: Hi Javier, I'm testing your patch on a 2.6.39 kernel. Here's what I get when loading the omap3-isp module. root@arago:~# modprobe omap3-isp [ 159.523681] omap3isp omap3isp: Revision 15.0 found [ 159.528991] omap-iommu omap-iommu.0: isp: version 1.1 [ 159.875701] omap_i2c omap_i2c.2: Arbitration lost [ 159.881622] mt9p031 2-0048: Failed to reset the camera [ 159.887054] omap3isp omap3isp: Failed to power on: -5 [ 159.892425] mt9p031 2-0048: Failed to power on device: -5 [ 159.898956] isp_register_subdev_group: Unable to register subdev mt9p031 Have you (or anyone else) seen that issue ? I build in both statically to avoid that problem. I used modules and it worked for me. Maybe u-boot version Laurent uses does not enable internal pull-up resistors for i2c2 interface. You could either use a different u-boot version or attach external pull-up resistors to that interface. -- 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: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
On 8 June 2011 18:24, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: That works much better, thank you. -- Regards, Laurent Pinchart So, how is it going? Are you finally accepting the patches for mainline? 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
Re: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
Laurent, have you been able to successfully test the driver? I've found some issues and I don't know whether I should send a new version or just wait for you to mainline the last one and send a patch later. -- 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 v8 1/2] Add driver for Aptina Micron mt9p031 sensor.
Fix BUG with output_control register and frequency calculation problems. - Output control register was being smashed, thus causing pixclk to have a high slew rate. - We cannot assume that we will always have a 20MHz input freq, so a table has been added so that the user can specify input freq and desired freq. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 928 + include/media/mt9p031.h | 19 + 4 files changed, 955 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..5f851f0 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -329,6 +329,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- + This is a Video4Linux2 sensor-level driver for the Aptina + (Micron) mt9p031 5 Mpixel camera. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..912b29b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..6b25a1b --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,928 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h + +#define MT9P031_CHIP_VERSION 0x00 +#defineMT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START 0x01 +#defineMT9P031_ROW_START_MIN 1 +#defineMT9P031_ROW_START_MAX 2004 +#defineMT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#defineMT9P031_COLUMN_START_MIN1 +#defineMT9P031_COLUMN_START_MAX2750 +#defineMT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT 0x03 +#defineMT9P031_WINDOW_HEIGHT_MIN 2 +#defineMT9P031_WINDOW_HEIGHT_MAX 2003 +#defineMT9P031_WINDOW_HEIGHT_DEF 2003 +#define MT9P031_WINDOW_WIDTH 0x04 +#defineMT9P031_WINDOW_WIDTH_MIN18 +#defineMT9P031_WINDOW_WIDTH_MAX2751 +#defineMT9P031_WINDOW_WIDTH_DEF2751 +#define MT9P031_H_BLANKING 0x05 +#defineMT9P031_H_BLANKING_VALUE0 +#define MT9P031_V_BLANKING 0x06 +#defineMT9P031_V_BLANKING_VALUE25 +#define MT9P031_OUTPUT_CONTROL 0x07 +#defineMT9P031_OUTPUT_CONTROL_CEN 2 +#defineMT9P031_OUTPUT_CONTROL_SYN 1 +#defineMT9P031_OUTPUT_CONTROL_DEF 0x1f82 +#define MT9P031_SHUTTER_WIDTH_UPPER0x08 +#define MT9P031_SHUTTER_WIDTH_LOWER0x09 +#defineMT9P031_SHUTTER_WIDTH_MIN 0x0001 +#defineMT9P031_SHUTTER_WIDTH_MAX 0x7ff +#defineMT9P031_SHUTTER_WIDTH_DEF 0x0797 +#defineMT9P031_PLL_CONTROL 0x10 +#defineMT9P031_PLL_CONTROL_PWROFF 0x0050 +#defineMT9P031_PLL_CONTROL_PWRON 0x0051 +#defineMT9P031_PLL_CONTROL_USEPLL 0x0052 +#define
[PATCH v8 2/2] Add support for mt9p031 sensor in Beagleboard XM.
Use new platform data ext_freq and target_freq.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3beagle-camera.c | 95
arch/arm/mach-omap2/board-omap3beagle.c| 50
3 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..05cd983 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) +=
board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
+ board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..96b4f95
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,95 @@
+#include linux/gpio.h
+#include linux/regulator/machine.h
+
+#include plat/i2c.h
+
+#include media/mt9p031.h
+#include asm/mach-types.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
+#define MT9P031_EXT_FREQ 2100
+
+static struct regulator *reg_1v8, *reg_2v8;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+
+ return isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+}
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+ .ext_freq = MT9P031_EXT_FREQ,
+ .target_freq= 4800,
+ .version= MT9P031_COLOR_VERSION,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
+static int __init beagle_camera_init(void)
+{
+ if (!machine_is_omap3_beagle() || !cpu_is_omap3630())
+ return 0;
+
+ reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(reg_1v8))
+ pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_1v8);
+
+ reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(reg_2v8))
+ pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_2v8);
+
+ omap_register_i2c_bus(2, 100, NULL, 0);
+ gpio_request(MT9P031_RESET_GPIO, cam_rst);
+ gpio_direction_output(MT9P031_RESET_GPIO, 0);
+ omap3_init_camera(beagle_isp_platform_data);
+ return 0;
+}
+late_initcall(beagle_camera_init);
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..c14e9d6 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -30,6 +30,7 @@
#include linux/mtd/nand.h
#include linux/mmc/host.h
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
@@ -273,6 +274,44 @@ static struct regulator_consumer_supply beagle_vsim_supply
= {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct
Re: [PATCH v8 1/2] Add driver for Aptina Micron mt9p031 sensor.
Hi, Laurent. How is it going? Is there any chance these changes to be included for next release? We are afraid that changes in the framework may turn the patches useless. 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
Re: [PATCH v8 1/2] Add driver for Aptina Micron mt9p031 sensor.
On 7 July 2011 01:22, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, On Monday 04 July 2011 13:25:10 javier Martin wrote: Hi, Laurent. How is it going? Is there any chance these changes to be included for next release? We are afraid that changes in the framework may turn the patches useless. I've applied the patch to my tree and I'm working on a couple of fixes. I'll try to finish that ASAP, but I'm quite busy at the moment :-S Ok, thank you Laurent. I feel more comfortable now you have it applied to your tree. 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: Add driver for Aptina Micron mt9p031 sensor.
On 26 July 2011 22:22, Clayton Shotwell shotty...@gmail.com wrote: Javier, I was wondering what the status was of your patches and when you thought they might get added into the mainstream kernel. I am working on integrating the mt9p031 into a little project I am doing. Please let me know when you get a chance. Hi, they are currently sitting in Laurent's tree. According to him, there are a couple of things that must be fixed before submitting them to mainline. But I don't know anything else. Maybe Laurent himself could clarify what is the status right now. -- 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] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
Hi Laurent, I really was looking forward to your patch. Tomorrow i have the day off, so I will look at this on Friday. I will review and test your patch and send you my comments. -- 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] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
Hi Laurent,
I've been reviewing and testing your patch as promised.
On 27 July 2011 19:51, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
+static int mt9p031_pll_enable(struct mt9p031 *mt9p031)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9p031-subdev);
+ int ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONTROL,
+ MT9P031_PLL_CONTROL_PWRON);
+ if (ret 0)
+ return ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONFIG_1,
+ (mt9p031-m 8) | (mt9p031-n - 1));
+ if (ret 0)
+ return ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONFIG_2, mt9p031-p1 - 1);
+ if (ret 0)
+ return ret;
+
+ mdelay(1);
mdelay() is a busyloop. Either msleep(), if the timing isn't critical, and
if it is, then usleep_range().
Timing isn't critical, but that's a stream-on delay, so I'll use
usleep_range().
+ ret = mt9p031_write(client, MT9P031_PLL_CONTROL,
+ MT9P031_PLL_CONTROL_PWRON |
+ MT9P031_PLL_CONTROL_USEPLL);
+ mdelay(1);
Javier, is this second mdelay() needed ?
No, sorry, I included it because I was having problems with PLLs and
wanted to be very cautious. You can safely remove it. It is not
specified in the datasheet and I've just tested it myself.
Apart from the minor issues mentioned by Sakari, I think dynamic
calculation of PLL dividers should be postponed for a next version
thus not delaying this one to enter mainline.
However I'm having problems for testing your version with linux-3.0
and my old test yavta + mplayer:
On my PC:
nc -l 3000 | ./mplayer - -demuxer rawvideo -rawvideo
w=320:h=240:format=ba81:size=76800 -vf ba81 -vo x11
On my Beagleboard:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
Setting up link 16:0 - 5:0 [1]
Setting up link 5:1 - 6:0 [1]
./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP
CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]'
Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0
Format set: SGRBG12 370x243
Setting up format SGRBG12 370x243 on pad OMAP3 ISP CCDC/0
Format set: SGRBG12 370x243
Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0
Format set: SGRBG8 320x240
Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1
Format set: SGRBG8 320x240
./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F
`./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000
Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
Video format set: width: 320 height: 240 buffer size: 76800
Video format: GRBG (47425247) 320x240
4 buffers requested.
length: 76800 offset: 0
Buffer 0 mapped at address 0x40082000.
length: 76800 offset: 77824
Buffer 1 mapped at address 0x400a8000.
length: 76800 offset: 155648
Buffer 2 mapped at address 0x4016a000.
length: 76800 offset: 233472
Buffer 3 mapped at address 0x402be000.
Unable to start streaming: 32.
What are you using for testing?
By the way, this is my last day in the office till August the 14th.
Furthermore, I've got no intention to be the maintainer of the driver,
since probably the main contributor to the patch was Guennadi.
However, as we'll be using this driver for a project that will last
for a year, count on me for testing, reviewing patches, etc... Because
out interest on this patch going into mainline is high.
--
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] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
All right, it works like a charm for me. It took me a bit to figure out that binning and skipping is controlled through ratio between cropping window size and actual format size but it is clear now. Just one thing; both VFLIP (this one is my fault) and HFLIP controls change the pixel format of the image and it no longer is GRBG. Given the following example image: G R G R B G B G If we apply VFLIP we'll have: B G B G G R G R And if we apply HFLIP we'll have: R G R G G B G B I am not sure how we could solve this issue, maybe through adjusting row and column start... In any case the driver is OK for me and the issue with VFLIP and HFLIP could be solved later on. 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] media: tvp5150: Add mbus_fmt callbacks.
These callbacks allow a host video driver
to poll video formats supported by tvp5150.
---
Changes since v1:
Fix standard handling in tvp5150_mbus_fmt()
---
drivers/media/video/tvp5150.c | 67 +
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index 26cc75b..c58c8d5 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -778,6 +778,70 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
+static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
+{
+ int val = tvp5150_read(sd, TVP5150_STATUS_REG_5);
+
+ switch (val 0x0F) {
+ case 0x01:
+ return V4L2_STD_NTSC;
+ case 0x03:
+ return V4L2_STD_PAL;
+ case 0x05:
+ return V4L2_STD_PAL_M;
+ case 0x07:
+ return V4L2_STD_PAL_N | V4L2_STD_PAL_Nc;
+ case 0x09:
+ return V4L2_STD_NTSC_443;
+ case 0xb:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned index,
+ enum v4l2_mbus_pixelcode *code)
+{
+ if (index)
+ return -EINVAL;
+
+ *code = V4L2_MBUS_FMT_YUYV8_2X8;
+ return 0;
+}
+
+static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *f)
+{
+ struct tvp5150 *decoder = to_tvp5150(sd);
+ v4l2_std_id std;
+
+ if (f == NULL)
+ return -EINVAL;
+
+ tvp5150_reset(sd, 0);
+
+ /* Calculate height and width based on current standard */
+ if (decoder-norm == V4L2_STD_ALL)
+ std = tvp5150_read_std(sd);
+ else
+ std = decoder-norm;
+
+ f-width = 720;
+ if (std V4L2_STD_525_60)
+ f-height = 480;
+ else
+ f-height = 576;
+
+ f-code = V4L2_MBUS_FMT_YUYV8_2X8;
+ f-field = V4L2_FIELD_SEQ_TB;
+ f-colorspace = V4L2_COLORSPACE_SMPTE170M;
+
+ v4l2_dbg(1, debug, sd, width = %d, height = %d\n, f-width,
+ f-height);
+ return 0;
+}
+
/
I2C Command
/
@@ -930,6 +994,9 @@ static const struct v4l2_subdev_tuner_ops tvp5150_tuner_ops
= {
static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_routing = tvp5150_s_routing,
+ .enum_mbus_fmt = tvp5150_enum_mbus_fmt,
+ .s_mbus_fmt = tvp5150_mbus_fmt,
+ .try_mbus_fmt = tvp5150_mbus_fmt,
};
static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
--
1.7.0.4
--
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 v4] media: vb2: support userptr for PFN mappings.
Hi Marek, On 9 January 2012 11:14, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On Wednesday, January 04, 2012 5:19 PM Javier Martin wrote: Some video devices need to use contiguous memory which is not backed by pages as it happens with vmalloc. This patch provides userptr handling for those devices. --- Changes since v3: - Remove vma_res variable. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com Acked-by: Marek Szyprowski m.szyprow...@samsung.com Do you plan to put a git tree with all your patches and send a pull request to Mauro? If not I will take this patch and put it on my vb2 branch. Is this mandatory for Mauro to merge one's patches? Because I've sent several patches in the patch and haven't received response yet. Anyway, I prefer you to take this patch. 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
Re: [PATCH] media i.MX27 camera: properly detect frame loss.
Hi Guennadi, this is the patch I mentioned that fixes sequence count so that it complies with v4l2 API. Will you please merge? 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
Re: [PATCH] media i.MX27 camera: properly detect frame loss.
Hi Guennadi,
thank you for your review.
On 10 January 2012 12:00, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
Hi Javier
On Mon, 2 Jan 2012, Javier Martin wrote:
As V4L2 specification states, frame_count must also
regard lost frames so that the user can handle that
case properly.
This patch adds a mechanism to increment the frame
counter even when a video buffer is not available
and a discard buffer is used.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 54
--
1 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index ca76dd2..b244714 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -256,6 +256,7 @@ struct mx2_camera_dev {
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
u32 frame_count;
+ unsigned int firstirq;
_if_ we indeed end up using this field, it seems it can be just a bool.
};
/* buffer for one video frame */
@@ -370,6 +371,7 @@ static int mx2_camera_add_device(struct
soc_camera_device *icd)
pcdev-icd = icd;
pcdev-frame_count = 0;
+ pcdev-firstirq = 1;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -572,6 +574,7 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
struct soc_camera_host *ici =
to_soc_camera_host(icd-parent);
struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
unsigned long flags;
@@ -584,6 +587,26 @@ static void mx2_videobuf_queue(struct videobuf_queue
*vq,
list_add_tail(vb-queue, pcdev-capture);
if (mx27_camera_emma(pcdev)) {
+ if (prp-cfg.channel == 1) {
+ writel(PRP_CNTL_CH1EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH1_LEN |
+ PRP_CNTL_CH1BYP |
+ PRP_CNTL_CH1_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ } else {
+ writel(PRP_CNTL_CH2EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH2_LEN |
+ PRP_CNTL_CH2_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ }
Is this related and why is this needed?
This is needed to make sure PrP only starts capturing frames when at
least one buffer is available in the queue. This guarantees the first
video buffer will be written to the discard buffer and the second will
be stored to the free buffer.
goto out;
} else { /* cpu_is_mx25() */
u32 csicr3, dma_inten = 0;
@@ -747,16 +770,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
writel(pcdev-discard_buffer_dma,
pcdev-base_emma + PRP_DEST_RGB2_PTR);
- writel(PRP_CNTL_CH1EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH1_LEN |
- PRP_CNTL_CH1BYP |
- PRP_CNTL_CH1_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
-
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel((icd-user_width 16) | icd-user_height,
@@ -784,15 +797,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
pcdev-base_emma + PRP_SOURCE_CR_PTR);
}
- writel(PRP_CNTL_CH2EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH2_LEN |
- PRP_CNTL_CH2_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
-
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_SRC_FRAME_SIZE);
@@ -1214,7 +1218,6 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
vb-state = state;
do_gettimeofday(vb-ts);
vb
Re: [PATCH 2/2] uvcvideo: Allow userptr IO mode.
Hi Laurent, FYI Marek has already merged 1/2 into his vb2-fixes branch. -- 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
[GIT PATCHES FOR 3.3] mx2 emma-prp mem2mem driver
Hi Mauro, The following changes since commit 240ab508aa9fb7a294b0ecb563b19ead000b2463: Mauro Carvalho Chehab (1): [media] [PATCH] don't reset the delivery system on DTV_CLEAR are available in the git repository at: git://github.com/jmartinc/video_visstrim.git for_v3.3 Javier Martin (2): MEM2MEM: Add support for eMMa-PrP mem2mem operations. MX2: Add platform definitions for eMMa-PrP device. arch/arm/mach-imx/clock-imx27.c |2 +- arch/arm/mach-imx/devices-imx27.h |2 + arch/arm/plat-mxc/devices/platform-mx2-camera.c | 18 + arch/arm/plat-mxc/include/mach/devices-common.h |2 + drivers/media/video/Kconfig | 10 + drivers/media/video/Makefile|2 + drivers/media/video/mx2_emmaprp.c | 1008 +++ 7 files changed, 1043 insertions(+), 1 deletions(-) create mode 100644 drivers/media/video/mx2_emmaprp.c -- 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 i.MX27 camera: fix buffer handling and videobuf2 support.
The way video buffer handling is programmed for i.MX27 leads to buffers being written when they are not ready. It can be easily checked enabling DEBUG features of the driver. This series migrate the driver to videobuf2 and provide an additional discard queue to make sure all the events are handled in the right order. I've only tested the series with an i.MX27 device and so I've tried not to touch code scpecific for mx25. However, any mx25 tester would be more than welcome. [PATCH 1/4] media i.MX27 camera: migrate driver to videobuf2 [PATCH 2/4] media i.MX27 camera: add start_stream and stop_stream callbacks. [PATCH 3/4] media i.MX27 camera: improve discard buffer handling. [PATCH 4/4] media i.MX27 camera: handle overflows properly. -- 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 i.MX27 camera: migrate driver to videobuf2
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 277 ++
1 files changed, 128 insertions(+), 149 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 68038e7..290ac9d 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2008, Sascha Hauer, Pengutronix
* Copyright (C) 2010, Baruch Siach, Orex Computed Radiography
+ * Copyright (C) 2012, Javier Martin, Vista Silicon S.L.
*
* 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
@@ -30,8 +31,8 @@
#include media/v4l2-common.h
#include media/v4l2-dev.h
-#include media/videobuf-core.h
-#include media/videobuf-dma-contig.h
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-contig.h
#include media/soc_camera.h
#include media/soc_mediabus.h
@@ -256,13 +257,25 @@ struct mx2_camera_dev {
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
u32 frame_count;
+ struct vb2_alloc_ctx*alloc_ctx;
+};
+
+enum mx2_buffer_state {
+ MX2_STATE_NEEDS_INIT = 0,
+ MX2_STATE_PREPARED = 1,
+ MX2_STATE_QUEUED = 2,
+ MX2_STATE_ACTIVE = 3,
+ MX2_STATE_DONE = 4,
+ MX2_STATE_ERROR = 5,
+ MX2_STATE_IDLE = 6,
};
/* buffer for one video frame */
struct mx2_buffer {
/* common v4l buffer stuff -- must be first */
- struct videobuf_buffer vb;
-
+ struct vb2_buffer vb;
+ struct list_headqueue;
+ enum mx2_buffer_state state;
enum v4l2_mbus_pixelcodecode;
int bufnum;
@@ -407,7 +420,7 @@ static irqreturn_t mx27_camera_irq(int irq_csi, void *data)
static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb,
int state)
{
- struct videobuf_buffer *vb;
+ struct vb2_buffer *vb;
struct mx2_buffer *buf;
struct mx2_buffer **fb_active = fb == 1 ? pcdev-fb1_active :
pcdev-fb2_active;
@@ -420,25 +433,24 @@ static void mx25_camera_frame_done(struct mx2_camera_dev
*pcdev, int fb,
goto out;
vb = (*fb_active)-vb;
- dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%08lx %d\n, __func__,
- vb, vb-baddr, vb-bsize);
+ 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));
- vb-state = state;
- do_gettimeofday(vb-ts);
- vb-field_count++;
-
- wake_up(vb-done);
+ 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 {
buf = list_entry(pcdev-capture.next, struct mx2_buffer,
- vb.queue);
+ queue);
vb = buf-vb;
- list_del(vb-queue);
- vb-state = VIDEOBUF_ACTIVE;
- writel(videobuf_to_dma_contig(vb), pcdev-base_csi + fb_reg);
+ list_del(buf-queue);
+ buf-state = MX2_STATE_ACTIVE;
+ writel(vb2_dma_contig_plane_dma_addr(vb, 0),
+ pcdev-base_csi + fb_reg);
}
*fb_active = buf;
@@ -453,9 +465,9 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void *data)
u32 status = readl(pcdev-base_csi + CSISR);
if (status CSISR_DMA_TSF_FB1_INT)
- mx25_camera_frame_done(pcdev, 1, VIDEOBUF_DONE);
+ mx25_camera_frame_done(pcdev, 1, MX2_STATE_DONE);
else if (status CSISR_DMA_TSF_FB2_INT)
- mx25_camera_frame_done(pcdev, 2, VIDEOBUF_DONE);
+ mx25_camera_frame_done(pcdev, 2, MX2_STATE_DONE);
/* FIXME: handle CSISR_RFF_OR_INT */
@@ -467,59 +479,47 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void
*data)
/*
* Videobuf operations
*/
-static int mx2_videobuf_setup(struct videobuf_queue *vq, unsigned int *count,
- unsigned int *size)
+static int mx2_videobuf_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt,
+ unsigned int *count, unsigned int *num_planes,
+ unsigned int sizes[], void *alloc_ctxs[])
{
- struct soc_camera_device *icd = vq-priv_data;
+ struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
icd-current_fmt-host_fmt
[PATCH 2/4] media i.MX27 camera: add start_stream and stop_stream callbacks.
Add start_stream and stop_stream callback in order to enable
and disable the eMMa-PrP properly and save CPU usage avoiding
IRQs when the device is not streaming.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 107 +++---
1 files changed, 77 insertions(+), 30 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 290ac9d..4816da6 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -560,7 +560,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
struct soc_camera_host *ici =
to_soc_camera_host(icd-parent);
struct mx2_camera_dev *pcdev = ici-priv;
- struct mx2_fmt_cfg *prp = pcdev-emma_prp;
struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
unsigned long flags;
@@ -572,29 +571,7 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
buf-state = MX2_STATE_QUEUED;
list_add_tail(buf-queue, pcdev-capture);
- if (mx27_camera_emma(pcdev)) {
- if (prp-cfg.channel == 1) {
- writel(PRP_CNTL_CH1EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH1_LEN |
- PRP_CNTL_CH1BYP |
- PRP_CNTL_CH1_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
- } else {
- writel(PRP_CNTL_CH2EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH2_LEN |
- PRP_CNTL_CH2_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
- }
- goto out;
- } else { /* cpu_is_mx25() */
+ if (!mx27_camera_emma(pcdev)) { /* cpu_is_mx25() */
u32 csicr3, dma_inten = 0;
if (pcdev-fb1_active == NULL) {
@@ -629,8 +606,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
writel(csicr3, pcdev-base_csi + CSICR3);
}
}
-
-out:
spin_unlock_irqrestore(pcdev-lock, flags);
}
@@ -692,11 +667,83 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
spin_unlock_irqrestore(pcdev-lock, flags);
}
+static int mx2_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct soc_camera_device *icd = soc_camera_from_vb2q(q);
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+ if (mx27_camera_emma(pcdev)) {
+ if (count 2) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (prp-cfg.channel == 1) {
+ writel(PRP_CNTL_CH1EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH1_LEN |
+ PRP_CNTL_CH1BYP |
+ PRP_CNTL_CH1_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ } else {
+ writel(PRP_CNTL_CH2EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH2_LEN |
+ PRP_CNTL_CH2_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ }
+ }
+err:
+ spin_unlock_irqrestore(pcdev-lock, flags);
+
+ return ret;
+}
+
+static int mx2_stop_streaming(struct vb2_queue *q)
+{
+ struct soc_camera_device *icd = soc_camera_from_vb2q(q);
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+ unsigned long flags;
+ u32 cntl;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+ if (mx27_camera_emma(pcdev)) {
+ cntl = readl(pcdev-base_emma + PRP_CNTL);
+ if (prp-cfg.channel == 1) {
+ writel(cntl ~PRP_CNTL_CH1EN,
+ pcdev-base_emma + PRP_CNTL
[PATCH 3/4] media i.MX27 camera: improve discard buffer handling.
The way discard buffer was previously handled lead
to possible races that made a buffer that was not
yet ready to be overwritten by new video data. This
is easily detected at 25fps just adding #define DEBUG
to enable the memset check and seeing how the image
is corrupted.
A new discard queue and two discard buffers have
been added to make them flow trough the pipeline
of queues and thus provide suitable event ordering.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 215 +-
1 files changed, 117 insertions(+), 98 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 4816da6..e0c5dd4 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -224,6 +224,28 @@ struct mx2_fmt_cfg {
struct mx2_prp_cfg cfg;
};
+enum mx2_buffer_state {
+ MX2_STATE_NEEDS_INIT = 0,
+ MX2_STATE_PREPARED = 1,
+ MX2_STATE_QUEUED = 2,
+ MX2_STATE_ACTIVE = 3,
+ MX2_STATE_DONE = 4,
+ MX2_STATE_ERROR = 5,
+ MX2_STATE_IDLE = 6,
+};
+
+/* buffer for one video frame */
+struct mx2_buffer {
+ /* common v4l buffer stuff -- must be first */
+ struct vb2_buffer vb;
+ struct list_headqueue;
+ enum mx2_buffer_state state;
+ enum v4l2_mbus_pixelcodecode;
+
+ int bufnum;
+ booldiscard;
+};
+
struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
@@ -240,6 +262,7 @@ struct mx2_camera_dev {
struct list_headcapture;
struct list_headactive_bufs;
+ struct list_headdiscard;
spinlock_t lock;
@@ -252,6 +275,7 @@ struct mx2_camera_dev {
u32 csicr1;
+ struct mx2_buffer buf_discard[2];
void*discard_buffer;
dma_addr_t discard_buffer_dma;
size_t discard_size;
@@ -260,27 +284,6 @@ struct mx2_camera_dev {
struct vb2_alloc_ctx*alloc_ctx;
};
-enum mx2_buffer_state {
- MX2_STATE_NEEDS_INIT = 0,
- MX2_STATE_PREPARED = 1,
- MX2_STATE_QUEUED = 2,
- MX2_STATE_ACTIVE = 3,
- MX2_STATE_DONE = 4,
- MX2_STATE_ERROR = 5,
- MX2_STATE_IDLE = 6,
-};
-
-/* buffer for one video frame */
-struct mx2_buffer {
- /* common v4l buffer stuff -- must be first */
- struct vb2_buffer vb;
- struct list_headqueue;
- enum mx2_buffer_state state;
- enum v4l2_mbus_pixelcodecode;
-
- int bufnum;
-};
-
static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
/*
* This is a generic configuration which is valid for most
@@ -334,6 +337,29 @@ static struct mx2_fmt_cfg *mx27_emma_prp_get_format(
return mx27_emma_prp_table[0];
};
+static void mx27_update_emma_buf(struct mx2_camera_dev *pcdev,
+unsigned long phys, int bufnum)
+{
+ u32 imgsize = pcdev-icd-user_height * pcdev-icd-user_width;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+
+ if (prp-cfg.channel == 1) {
+ writel(phys, pcdev-base_emma +
+ PRP_DEST_RGB1_PTR + 4 * bufnum);
+ } else {
+ writel(phys, pcdev-base_emma +
+ PRP_DEST_Y_PTR -
+ 0x14 * bufnum);
+ if (prp-out_fmt == V4L2_PIX_FMT_YUV420) {
+ writel(phys + imgsize,
+ pcdev-base_emma + PRP_DEST_CB_PTR -
+ 0x14 * bufnum);
+ writel(phys + ((5 * imgsize) / 4), pcdev-base_emma +
+ PRP_DEST_CR_PTR - 0x14 * bufnum);
+ }
+ }
+}
+
static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
{
unsigned long flags;
@@ -382,7 +408,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
- pcdev-frame_count = -1;
+ pcdev-frame_count = 0;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -648,10 +674,9 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
* types.
*/
spin_lock_irqsave(pcdev-lock, flags);
- if (buf-state == MX2_STATE_QUEUED || buf-state == MX2_STATE_ACTIVE) {
- list_del_init(buf-queue);
- buf-state = MX2_STATE_NEEDS_INIT;
- } else if (cpu_is_mx25() buf-state == MX2_STATE_ACTIVE) {
+ INIT_LIST_HEAD(buf-queue);
+ buf-state = MX2_STATE_NEEDS_INIT;
+ if (cpu_is_mx25() buf-state
[PATCH 4/4] media i.MX27 camera: handle overflows properly.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index e0c5dd4..cdc614f 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1274,7 +1274,10 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
buf-state = state;
do_gettimeofday(vb-v4l2_buf.timestamp);
vb-v4l2_buf.sequence = pcdev-frame_count;
- vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+ if (state == MX2_STATE_ERROR)
+ vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+ else
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
}
pcdev-frame_count++;
@@ -1309,19 +1312,11 @@ static irqreturn_t mx27_camera_emma_irq(int irq_emma,
void *data)
struct mx2_buffer *buf;
if (status (1 7)) { /* overflow */
- u32 cntl;
- /*
-* We only disable channel 1 here since this is the only
-* enabled channel
-*
-* FIXME: the correct DMA overflow handling should be resetting
-* the buffer, returning an error frame, and continuing with
-* the next one.
-*/
- cntl = readl(pcdev-base_emma + PRP_CNTL);
- writel(cntl ~(PRP_CNTL_CH1EN | PRP_CNTL_CH2EN),
- pcdev-base_emma + PRP_CNTL);
- writel(cntl, pcdev-base_emma + PRP_CNTL);
+ buf = list_entry(pcdev-active_bufs.next,
+ struct mx2_buffer, queue);
+ mx27_camera_frame_done_emma(pcdev,
+ buf-bufnum, MX2_STATE_ERROR);
+ status = ~(1 7);
}
if status (3 5)) == (3 5)) ||
((status (3 3)) == (3 3)))
--
1.7.0.4
--
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: properly detect frame loss.
Hi Guennadi, thank you for your attention. I've recently sent a new patch series on top of this patch: [PATCH 0/4] media i.MX27 camera: fix buffer handling and videobuf2 support. (http://www.mail-archive.com/linux-media@vger.kernel.org/msg42255.html) Among other things, it adds videobuf2 support and adds stream_stop and stream_start callbacks which allow to enable/disable capturing of buffers at the right moment. This also makes the sequence number trick disappear and a much cleaner approach is used instead. I suggest you hold on this patch until the new series is accepted and then merge both at the same time. What do you think? -- 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: properly detect frame loss.
Hi Guennadi, I suggest you hold on this patch until the new series is accepted and then merge both at the same time. What do you think? Ok, I'll be reviewing that patch series hopefully soon, and in principle it is good, that the buffer counting will really be fixed in it, but in an ideal world it would be better to have this your patch merged into patch 2/4 of the series, agree? Would I be asking too much of you if I suggest that? Feel free to explain why this wouldn't work or just reject if you're just too tight on schedule. I'll see ifI can swallow it that way or maybe merge myself :-) If you, Sascha, or someone else comes up with some requests or fixes to the new series I don't mind to rebase it so you can just ignore this patch, since I would have to sent a v2 version of the series anyway. 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 i.MX27 camera: migrate driver to videobuf2
Hi Guennadi,
thank you for your review.
u32 frame_count;
+ struct vb2_alloc_ctx *alloc_ctx;
+};
+
+enum mx2_buffer_state {
+ MX2_STATE_NEEDS_INIT = 0,
+ MX2_STATE_PREPARED = 1,
+ MX2_STATE_QUEUED = 2,
+ MX2_STATE_ACTIVE = 3,
+ MX2_STATE_DONE = 4,
+ MX2_STATE_ERROR = 5,
+ MX2_STATE_IDLE = 6,
Are the numerical values important? If not - please, drop. And actually,
you don't need most of these states, I wouldn't be surprised, if you
didn't need them at all. You might want to revise them in a future patch.
Yes, you are right, I might have been too cautious here. I will make
mx27 not to depend on these states and will try to reduce them.
However, those ones used by mx25 I can't eliminate since I don't have
the possibility to test it.
[snip]
@@ -467,59 +479,47 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void
*data)
/*
* Videobuf operations
*/
-static int mx2_videobuf_setup(struct videobuf_queue *vq, unsigned int
*count,
- unsigned int *size)
+static int mx2_videobuf_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt,
+ unsigned int *count, unsigned int *num_planes,
+ unsigned int sizes[], void *alloc_ctxs[])
{
- struct soc_camera_device *icd = vq-priv_data;
+ struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
icd-current_fmt-host_fmt);
You choose not to support VIDIOC_CREATE_BUFS? You have to at least return
an error if fmt != NULL. Or consider supporting it - look at mx3_camera.c
or sh_mobile_ceu_camera.c (btw, atmel-isi.c has to be fixed with this
respect too). If you decide to support it, you'll also have to drop
.buf_prepare() (see, e.g., 07f92448045a23d27dbc3ece3abcb6bafc618d43)
I'm a bit tight on schedule and would prefer just returning NULL by
now and add this in a further patch if you are so kind.
[snip]
@@ -529,46 +529,34 @@ static int mx2_videobuf_prepare(struct videobuf_queue
*vq,
* This can be useful if you want to see if we actually fill
* the buffer with something
*/
- memset((void *)vb-baddr, 0xaa, vb-bsize);
+ memset((void *)vb2_plane_vaddr(vb, 0),
+ 0xaa, vb2_get_plane_payload(vb, 0));
#endif
- if (buf-code != icd-current_fmt-code ||
- vb-width != icd-user_width ||
- vb-height != icd-user_height ||
- vb-field != field) {
+ if (buf-code != icd-current_fmt-code) {
buf-code = icd-current_fmt-code;
- vb-width = icd-user_width;
- vb-height = icd-user_height;
- vb-field = field;
- vb-state = VIDEOBUF_NEEDS_INIT;
+ buf-state = MX2_STATE_NEEDS_INIT;
This looks broken or most likely redundant to me. The check for a changed
code was there to reallocate the buffer, doesn't seem to make much sense
now.
Yes, this will definitely go away and will take MX2_STATE_NEEDS_INIT with it.
[snip]
@@ -686,10 +673,10 @@ static void mx2_videobuf_release(struct videobuf_queue
*vq,
* types.
*/
spin_lock_irqsave(pcdev-lock, flags);
- if (vb-state == VIDEOBUF_QUEUED) {
- list_del(vb-queue);
- vb-state = VIDEOBUF_ERROR;
- } else if (cpu_is_mx25() vb-state == VIDEOBUF_ACTIVE) {
+ if (buf-state == MX2_STATE_QUEUED || buf-state == MX2_STATE_ACTIVE) {
+ list_del_init(buf-queue);
+ buf-state = MX2_STATE_NEEDS_INIT;
+ } else if (cpu_is_mx25() buf-state == MX2_STATE_ACTIVE) {
This doesn't look right. You already have || buf-state ==
MX2_STATE_ACTIVE above, so, this latter condition is never entered?
Yeah, I'm probably breaking m25 support here. This will be fixed in
the following version of my 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 2/4] media i.MX27 camera: add start_stream and stop_stream callbacks.
Hi Guennadi,
On 25 January 2012 11:26, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
As discussed before, please, merge this patch with
media i.MX27 camera: properly detect frame loss.
Yes. You can drop that patch already.
One more cosmetic note:
On Fri, 20 Jan 2012, Javier Martin wrote:
Add start_stream and stop_stream callback in order to enable
and disable the eMMa-PrP properly and save CPU usage avoiding
IRQs when the device is not streaming.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 107
+++---
1 files changed, 77 insertions(+), 30 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index 290ac9d..4816da6 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -560,7 +560,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
struct soc_camera_host *ici =
to_soc_camera_host(icd-parent);
struct mx2_camera_dev *pcdev = ici-priv;
- struct mx2_fmt_cfg *prp = pcdev-emma_prp;
struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
unsigned long flags;
@@ -572,29 +571,7 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
buf-state = MX2_STATE_QUEUED;
list_add_tail(buf-queue, pcdev-capture);
- if (mx27_camera_emma(pcdev)) {
- if (prp-cfg.channel == 1) {
- writel(PRP_CNTL_CH1EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH1_LEN |
- PRP_CNTL_CH1BYP |
- PRP_CNTL_CH1_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
- } else {
- writel(PRP_CNTL_CH2EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH2_LEN |
- PRP_CNTL_CH2_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
- }
- goto out;
- } else { /* cpu_is_mx25() */
+ if (!mx27_camera_emma(pcdev)) { /* cpu_is_mx25() */
u32 csicr3, dma_inten = 0;
if (pcdev-fb1_active == NULL) {
@@ -629,8 +606,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
writel(csicr3, pcdev-base_csi + CSICR3);
}
}
-
-out:
To my taste you're a bit too aggressive on blank lines;-) This also holds
for the previous patch. Unless you absolutely have to edit your sources in
a 24-line terminal, keeping those empty lines would be appreciated:-)
OK. I'll try to overcome my anger ^^
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 4/4] media i.MX27 camera: handle overflows properly.
Hi Guennadi,
On 25 January 2012 13:17, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Fri, 20 Jan 2012, Javier Martin wrote:
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index e0c5dd4..cdc614f 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1274,7 +1274,10 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
buf-state = state;
do_gettimeofday(vb-v4l2_buf.timestamp);
vb-v4l2_buf.sequence = pcdev-frame_count;
- vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+ if (state == MX2_STATE_ERROR)
+ vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+ else
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
}
pcdev-frame_count++;
@@ -1309,19 +1312,11 @@ static irqreturn_t mx27_camera_emma_irq(int
irq_emma, void *data)
struct mx2_buffer *buf;
if (status (1 7)) { /* overflow */
- u32 cntl;
- /*
- * We only disable channel 1 here since this is the only
- * enabled channel
- *
- * FIXME: the correct DMA overflow handling should be resetting
- * the buffer, returning an error frame, and continuing with
- * the next one.
- */
- cntl = readl(pcdev-base_emma + PRP_CNTL);
- writel(cntl ~(PRP_CNTL_CH1EN | PRP_CNTL_CH2EN),
- pcdev-base_emma + PRP_CNTL);
- writel(cntl, pcdev-base_emma + PRP_CNTL);
+ buf = list_entry(pcdev-active_bufs.next,
+ struct mx2_buffer, queue);
+ mx27_camera_frame_done_emma(pcdev,
+ buf-bufnum, MX2_STATE_ERROR);
+ status = ~(1 7);
}
if status (3 5)) == (3 5)) ||
Does it make sense continuing processing here, if an error occurred? To me
all the four if statements in this function seem mutually-exclusive and
should be handled by a
if () {
} else if () {
...
chain.
((status (3 3)) == (3 3)))
Yes, as you point out, everything is mutually exclusive.
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 1/4] media i.MX27 camera: migrate driver to videobuf2
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- mx27 code doesn't use states.
- number of states reduced to the ones used by mx25.
- Fix incorrect if which broke mx25 support.
- Minor fixes.
---
drivers/media/video/mx2_camera.c | 298 --
1 files changed, 127 insertions(+), 171 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ca76dd2..898f98f 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2008, Sascha Hauer, Pengutronix
* Copyright (C) 2010, Baruch Siach, Orex Computed Radiography
+ * Copyright (C) 2012, Javier Martin, Vista Silicon S.L.
*
* 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
@@ -30,8 +31,8 @@
#include media/v4l2-common.h
#include media/v4l2-dev.h
-#include media/videobuf-core.h
-#include media/videobuf-dma-contig.h
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-contig.h
#include media/soc_camera.h
#include media/soc_mediabus.h
@@ -223,6 +224,22 @@ struct mx2_fmt_cfg {
struct mx2_prp_cfg cfg;
};
+enum mx2_buffer_state {
+ MX2_STATE_QUEUED,
+ MX2_STATE_ACTIVE,
+ MX2_STATE_DONE,
+};
+
+/* buffer for one video frame */
+struct mx2_buffer {
+ /* common v4l buffer stuff -- must be first */
+ struct vb2_buffer vb;
+ struct list_headqueue;
+ enum mx2_buffer_state state;
+
+ int bufnum;
+};
+
struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
@@ -256,16 +273,7 @@ struct mx2_camera_dev {
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
u32 frame_count;
-};
-
-/* buffer for one video frame */
-struct mx2_buffer {
- /* common v4l buffer stuff -- must be first */
- struct videobuf_buffer vb;
-
- enum v4l2_mbus_pixelcodecode;
-
- int bufnum;
+ struct vb2_alloc_ctx*alloc_ctx;
};
static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
@@ -407,7 +415,7 @@ static irqreturn_t mx27_camera_irq(int irq_csi, void *data)
static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb,
int state)
{
- struct videobuf_buffer *vb;
+ struct vb2_buffer *vb;
struct mx2_buffer *buf;
struct mx2_buffer **fb_active = fb == 1 ? pcdev-fb1_active :
pcdev-fb2_active;
@@ -420,25 +428,24 @@ static void mx25_camera_frame_done(struct mx2_camera_dev
*pcdev, int fb,
goto out;
vb = (*fb_active)-vb;
- dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%08lx %d\n, __func__,
- vb, vb-baddr, vb-bsize);
+ 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));
- vb-state = state;
- do_gettimeofday(vb-ts);
- vb-field_count++;
-
- wake_up(vb-done);
+ 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 {
buf = list_entry(pcdev-capture.next, struct mx2_buffer,
- vb.queue);
+ queue);
vb = buf-vb;
- list_del(vb-queue);
- vb-state = VIDEOBUF_ACTIVE;
- writel(videobuf_to_dma_contig(vb), pcdev-base_csi + fb_reg);
+ list_del(buf-queue);
+ buf-state = MX2_STATE_ACTIVE;
+ writel(vb2_dma_contig_plane_dma_addr(vb, 0),
+ pcdev-base_csi + fb_reg);
}
*fb_active = buf;
@@ -453,9 +460,9 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void *data)
u32 status = readl(pcdev-base_csi + CSISR);
if (status CSISR_DMA_TSF_FB1_INT)
- mx25_camera_frame_done(pcdev, 1, VIDEOBUF_DONE);
+ mx25_camera_frame_done(pcdev, 1, MX2_STATE_DONE);
else if (status CSISR_DMA_TSF_FB2_INT)
- mx25_camera_frame_done(pcdev, 2, VIDEOBUF_DONE);
+ mx25_camera_frame_done(pcdev, 2, MX2_STATE_DONE);
/* FIXME: handle CSISR_RFF_OR_INT */
@@ -467,59 +474,50 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void
*data)
/*
* Videobuf operations
*/
-static int mx2_videobuf_setup(struct videobuf_queue *vq, unsigned int *count,
- unsigned int *size)
+static int mx2_videobuf_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt,
+ unsigned int *count, unsigned int *num_planes
[PATCH v2 2/4] media i.MX27 camera: add start_stream and stop_stream callbacks.
Add start_stream and stop_stream callback in order to enable
and disable the eMMa-PrP properly and save CPU usage avoiding
IRQs when the device is not streaming. This also makes the driver
return 0 as the sequence number of the first frame.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Merge media i.MX27 camera: properly detect frame loss
---
drivers/media/video/mx2_camera.c | 104 +-
1 files changed, 79 insertions(+), 25 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 898f98f..045c018 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -377,7 +377,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
- pcdev-frame_count = 0;
+ pcdev-frame_count = -1;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -647,11 +647,83 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
spin_unlock_irqrestore(pcdev-lock, flags);
}
+static int mx2_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct soc_camera_device *icd = soc_camera_from_vb2q(q);
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+ if (mx27_camera_emma(pcdev)) {
+ if (count 2) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (prp-cfg.channel == 1) {
+ writel(PRP_CNTL_CH1EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH1_LEN |
+ PRP_CNTL_CH1BYP |
+ PRP_CNTL_CH1_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ } else {
+ writel(PRP_CNTL_CH2EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH2_LEN |
+ PRP_CNTL_CH2_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ }
+ }
+err:
+ spin_unlock_irqrestore(pcdev-lock, flags);
+
+ return ret;
+}
+
+static int mx2_stop_streaming(struct vb2_queue *q)
+{
+ struct soc_camera_device *icd = soc_camera_from_vb2q(q);
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+ unsigned long flags;
+ u32 cntl;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+ if (mx27_camera_emma(pcdev)) {
+ cntl = readl(pcdev-base_emma + PRP_CNTL);
+ if (prp-cfg.channel == 1) {
+ writel(cntl ~PRP_CNTL_CH1EN,
+ pcdev-base_emma + PRP_CNTL);
+ } else {
+ writel(cntl ~PRP_CNTL_CH2EN,
+ pcdev-base_emma + PRP_CNTL);
+ }
+ }
+ spin_unlock_irqrestore(pcdev-lock, flags);
+
+ return 0;
+}
+
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,
+ .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,
};
static int mx2_camera_init_videobuf(struct vb2_queue *q,
@@ -709,16 +781,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
writel(pcdev-discard_buffer_dma,
pcdev-base_emma + PRP_DEST_RGB2_PTR);
- writel(PRP_CNTL_CH1EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH1_LEN |
- PRP_CNTL_CH1BYP |
- PRP_CNTL_CH1_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
-
writel((icd
[PATCH v2 3/4] media i.MX27 camera: improve discard buffer handling.
The way discard buffer was previously handled lead
to possible races that made a buffer that was not
yet ready to be overwritten by new video data. This
is easily detected at 25fps just adding #define DEBUG
to enable the memset check and seeing how the image
is corrupted.
A new discard queue and two discard buffers have
been added to make them flow trough the pipeline
of queues and thus provide suitable event ordering.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Don't allocate discard buffer on every set_fmt.
---
drivers/media/video/mx2_camera.c | 261 +-
1 files changed, 144 insertions(+), 117 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 045c018..71054ab 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -237,7 +237,8 @@ struct mx2_buffer {
struct list_headqueue;
enum mx2_buffer_state state;
- int bufnum;
+ int bufnum;
+ booldiscard;
};
struct mx2_camera_dev {
@@ -256,6 +257,7 @@ struct mx2_camera_dev {
struct list_headcapture;
struct list_headactive_bufs;
+ struct list_headdiscard;
spinlock_t lock;
@@ -268,6 +270,7 @@ struct mx2_camera_dev {
u32 csicr1;
+ struct mx2_buffer buf_discard[2];
void*discard_buffer;
dma_addr_t discard_buffer_dma;
size_t discard_size;
@@ -329,6 +332,30 @@ static struct mx2_fmt_cfg *mx27_emma_prp_get_format(
return mx27_emma_prp_table[0];
};
+static void mx27_update_emma_buf(struct mx2_camera_dev *pcdev,
+unsigned long phys, int bufnum)
+{
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+
+ if (prp-cfg.channel == 1) {
+ writel(phys, pcdev-base_emma +
+ PRP_DEST_RGB1_PTR + 4 * bufnum);
+ } else {
+ writel(phys, pcdev-base_emma +
+ PRP_DEST_Y_PTR - 0x14 * bufnum);
+ if (prp-out_fmt == V4L2_PIX_FMT_YUV420) {
+ u32 imgsize = pcdev-icd-user_height *
+ pcdev-icd-user_width;
+
+ writel(phys + imgsize,
+ pcdev-base_emma + PRP_DEST_CB_PTR -
+ 0x14 * bufnum);
+ writel(phys + ((5 * imgsize) / 4), pcdev-base_emma +
+ PRP_DEST_CR_PTR - 0x14 * bufnum);
+ }
+ }
+}
+
static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
{
unsigned long flags;
@@ -377,7 +404,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
- pcdev-frame_count = -1;
+ pcdev-frame_count = 0;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -631,7 +658,7 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
spin_lock_irqsave(pcdev-lock, flags);
if (mx27_camera_emma(pcdev)) {
- list_del_init(buf-queue);
+ INIT_LIST_HEAD(buf-queue);
} else if (cpu_is_mx25() buf-state == MX2_STATE_ACTIVE) {
if (pcdev-fb1_active == buf) {
pcdev-csicr1 = ~CSICR1_FB1_DMA_INTEN;
@@ -647,6 +674,34 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
spin_unlock_irqrestore(pcdev-lock, flags);
}
+static void mx27_camera_emma_buf_init(struct soc_camera_device *icd,
+ int bytesperline)
+{
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+
+ writel((icd-user_width 16) | icd-user_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((icd-user_width 16) | icd-user_height,
+ pcdev-base_emma + PRP_CH1_OUT_IMAGE_SIZE);
+ writel(bytesperline,
+ pcdev-base_emma + PRP_DEST_CH1_LINE_STRIDE);
+ writel(prp-cfg.ch1_pixel,
+ pcdev-base_emma + PRP_CH1_PIXEL_FORMAT_CNTL);
+ } else { /* channel 2 */
+ writel((icd-user_width 16) | icd-user_height,
+ pcdev-base_emma + PRP_CH2_OUT_IMAGE_SIZE);
+ }
+
+ /* Enable interrupts */
+ writel(prp-cfg.irq_flags, pcdev-base_emma + PRP_INTR_CNTL);
+}
+
static int mx2_start_streaming(struct vb2_queue *q, unsigned int count)
{
struct soc_camera_device
[PATCH v2 4/4] media i.MX27 camera: handle overflows properly.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Make ifs in irq callback mutually exclusive.
- Add new argument to mx27_camera_frame_done_emma() to handle errors.
---
drivers/media/video/mx2_camera.c | 38 --
1 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 71054ab..1759673 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1213,7 +1213,7 @@ static struct soc_camera_host_ops mx2_soc_camera_host_ops
= {
};
static void mx27_camera_frame_done_emma(struct mx2_camera_dev *pcdev,
- int bufnum)
+ int bufnum, bool err)
{
struct mx2_buffer *buf;
struct vb2_buffer *vb;
@@ -1262,7 +1262,10 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_del_init(buf-queue);
do_gettimeofday(vb-v4l2_buf.timestamp);
vb-v4l2_buf.sequence = pcdev-frame_count;
- vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+ if (err)
+ vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+ else
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
}
pcdev-frame_count++;
@@ -1297,21 +1300,12 @@ static irqreturn_t mx27_camera_emma_irq(int irq_emma,
void *data)
struct mx2_buffer *buf;
if (status (1 7)) { /* overflow */
- u32 cntl;
- /*
-* We only disable channel 1 here since this is the only
-* enabled channel
-*
-* FIXME: the correct DMA overflow handling should be resetting
-* the buffer, returning an error frame, and continuing with
-* the next one.
-*/
- cntl = readl(pcdev-base_emma + PRP_CNTL);
- writel(cntl ~(PRP_CNTL_CH1EN | PRP_CNTL_CH2EN),
- pcdev-base_emma + PRP_CNTL);
- writel(cntl, pcdev-base_emma + PRP_CNTL);
- }
- if status (3 5)) == (3 5)) ||
+ buf = list_entry(pcdev-active_bufs.next,
+ struct mx2_buffer, queue);
+ mx27_camera_frame_done_emma(pcdev,
+ buf-bufnum, 1);
+ status = ~(1 7);
+ } else if status (3 5)) == (3 5)) ||
((status (3 3)) == (3 3)))
!list_empty(pcdev-active_bufs)) {
/*
@@ -1320,13 +1314,13 @@ static irqreturn_t mx27_camera_emma_irq(int irq_emma,
void *data)
*/
buf = list_entry(pcdev-active_bufs.next,
struct mx2_buffer, queue);
- mx27_camera_frame_done_emma(pcdev, buf-bufnum);
+ mx27_camera_frame_done_emma(pcdev, buf-bufnum, 0);
status = ~(1 (6 - buf-bufnum)); /* mark processed */
+ } else if ((status (1 6)) || (status (1 4))) {
+ mx27_camera_frame_done_emma(pcdev, 0, 0);
+ } else if ((status (1 5)) || (status (1 3))) {
+ mx27_camera_frame_done_emma(pcdev, 1, 0);
}
- if ((status (1 6)) || (status (1 4)))
- mx27_camera_frame_done_emma(pcdev, 0);
- if ((status (1 5)) || (status (1 3)))
- mx27_camera_frame_done_emma(pcdev, 1);
writel(status, pcdev-base_emma + PRP_INTRSTATUS);
--
1.7.0.4
--
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] media i.MX27 camera: migrate driver to videobuf2
Hi Guennadi, thank you for your time. On 27 January 2012 16:25, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: A general question for mx2-camera: does it now after removal of legacy i.MX27 support only support i.MX25 (state: unknown) and i.MX27 in eMMA mode? I understand so. I'll send a v3 of this patch fixing what you've pointed out. 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/4] media i.MX27 camera: add start_stream and stop_stream callbacks.
Hi,
On 27 January 2012 16:53, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Thu, 26 Jan 2012, Javier Martin wrote:
Add start_stream and stop_stream callback in order to enable
and disable the eMMa-PrP properly and save CPU usage avoiding
IRQs when the device is not streaming. This also makes the driver
return 0 as the sequence number of the first frame.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Merge media i.MX27 camera: properly detect frame loss
---
drivers/media/video/mx2_camera.c | 104
+-
1 files changed, 79 insertions(+), 25 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index 898f98f..045c018 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -377,7 +377,7 @@ static int mx2_camera_add_device(struct
soc_camera_device *icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
- pcdev-frame_count = 0;
+ pcdev-frame_count = -1;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -647,11 +647,83 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
spin_unlock_irqrestore(pcdev-lock, flags);
}
+static int mx2_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct soc_camera_device *icd = soc_camera_from_vb2q(q);
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+ if (mx27_camera_emma(pcdev)) {
+ if (count 2) {
+ ret = -EINVAL;
+ goto err;
+ }
How about:
if (mx27_camera_emma(pcdev)) {
unsigned long flags;
if (count 2)
return -EINVAL;
spin_lock_irqsave(pcdev-lock, flags);
...
spin_unlock_irqrestore(pcdev-lock, flags);
}
return 0;
OK, this is definitely cleaner. I'll do it for v3.
Another point: in v1 of this patch you also removed goto out from
mx2_videobuf_queue(). I understand this is probably unrelated to this
patch now. Anyway, if you don't find a patch out of your 4 now, where it
logically would fit, you could either make an additional patch, or I could
do it myself, if I don't forget:-)
Don't worry,
I'll send a new series including that patch after this one gets merged.
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 3/4] media i.MX27 camera: improve discard buffer handling.
Hi Guennadi,
On 27 January 2012 19:02, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
(removing bar...@tkos.co.il - it bounces)
On Thu, 26 Jan 2012, javier Martin wrote:
Hi Guennadi,
On 25 January 2012 13:12, Guennadi Liakhovetski g.liakhovet...@gmx.de
wrote:
On Fri, 20 Jan 2012, Javier Martin wrote:
The way discard buffer was previously handled lead
to possible races that made a buffer that was not
yet ready to be overwritten by new video data. This
is easily detected at 25fps just adding #define DEBUG
to enable the memset check and seeing how the image
is corrupted.
A new discard queue and two discard buffers have
been added to make them flow trough the pipeline
of queues and thus provide suitable event ordering.
Hmm, do I understand it right, that the problem is, that while the first
frame went to the discard buffer, the second one went already to a user
buffer, while it wasn't ready yet?
The problem is not only related to the discard buffer but also the way
valid buffers were handled in an unsafe basis.
For instance, the buf-bufnum = !bufnum issue. If you receive and
IRQ from bufnum = 0 you have to update buffer 0, not buffer 1.
And you solve this by adding one more
discard buffer? Wouldn't it be possible to either not start capture until
.start_streaming() is issued, which should also be the case after your
patch 2/4, or, at least, just reuse one discard buffer multiple times
until user buffers are available?
If I understand right, you don't really introduce two discard buffers,
there's still only one data buffer, but you add two discard data objects
and a list to keep them on. TBH, this seems severely over-engineered to
me. What's wrong with just keeping one DMA data buffer and using it as
long, as needed, and checking in your ISR, whether a proper buffer is
present, by looking for list_empty(active)?
I added a couple of comments below, but my biggest question really is -
why are these two buffer objects needed? Please, consider getting rid of
them. So, this is not a full review, if the objects get removed, most of
this patch will change anyway.
1. Why a discard buffer is needed?
When I first took a look at the code it only supported CH1 of the PrP
(i.e. RGB formats) and a discard buffer was used. My first reaction
was trying to get rid of that trick. Both CH1 and CH2 of the PrP have
two pointers that the engine uses to write video frames in a ping-pong
basis. However, there is a big difference between both channels: if
you want to detect frame loss in CH1 you have to continually feed the
two pointers with valid memory areas because the engine is always
writing and you can't stop it, and this is where the discard buffer
function is required, but CH2 has a mechanism to stop capturing and
keep counting loss frames, thus a discard buffer wouldn't be needed.
To sum up: the driver would be much cleaner without this discard
buffer trick but we would have to drop support for CH1 (RGB format).
Being respectful to CH1 support I decided to add CH2 by extending the
discard buffer strategy to both channels, since the code is cleaner
this way and doesn't make sense to manage both channels differently.
2. Why two discard buffer objects are needed?
After enabling the DEBUG functionality that writes the buffers with
0xaa before they are filled with video data, I discovered some of them
were being corrupted. When I tried to find the reason I found that we
really have a pipeline here:
--- ---
capture (n) | active_bufs (2)|
---
where
capture has buffers that are queued and ready to be written into
active_bufs represents those buffers that are assigned to a pointer
in the PrP and has a maximum of 2 since there are two pointers that
are written in a ping-pong fashion
Ok, I understand what the discard memory is used for and why you need to
write it twice to the hardware - to those two pointers. And I can kindof
agree, that using them uniformly with user buffers on the active list
simplifies handling. I just don't think it's a good idea to keep two
struct vb2_buffer instances around with no use. Maybe you could use
something like
struct mx2_buf_internal {
struct list_head queue;
int bufnum;
bool discard;
};
struct mx2_buffer {
struct vb2_buffer vb;
enum mx2_buffer_state state;
struct mx2_buf_internal internal;
};
and only use struct mx2_buf_internal for your discard buffers.
You are right, the approach you suggest is more efficient.
What I purpose is that you accept my following v3 patch series and
allow me to send a further cleanup series with the following changes:
1. Remove goto out from mx2_videobuf_queue.
2. Use
