date:20120309

RE: [PATCH] omap_vout: Set DSS overlay_info only if paddr is non zero

2012-03-09 Thread Hiremath, Vaibhav

On Fri, Mar 09, 2012 at 05:17:41, Laurent Pinchart wrote:
 Hi Archit,
 
 On Wednesday 07 March 2012 14:31:16 Archit Taneja wrote:
  The omap_vout driver tries to set the DSS overlay_info using
  set_overlay_info() when the physical address for the overlay is still not
  configured. This happens in omap_vout_probe() and vidioc_s_fmt_vid_out().
  
  The calls to omapvid_init(which internally calls set_overlay_info()) are
  removed from these functions. They don't need to be called as the
  omap_vout_device struct anyway maintains the overlay related changes made.
  Also, remove the explicit call to set_overlay_info() in vidioc_streamon(),
  this was used to set the paddr, this isn't needed as omapvid_init() does
  the same thing later.
  
  These changes are required as the DSS2 driver since 3.3 kernel doesn't let
  you set the overlay info with paddr as 0.
  
  Signed-off-by: Archit Taneja arc...@ti.com
 
 Thanks for the patch. This seems to fix memory corruption that would result
 in sysfs-related crashes such as
 
 [   31.279541] [ cut here ]
 [   31.284423] WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x70/0x1f8()
 [   31.291503] missing sysfs attribute operations for kobject: (null)
 [   31.298004] Modules linked in: mt9p031 aptina_pll omap3_isp
 [   31.303924] [c0018260] (unwind_backtrace+0x0/0xec) from [c0034488] 
 (warn_slowpath_common+0x4c/0x64)
 [   31.313812] [c0034488] (warn_slowpath_common+0x4c/0x64) from 
 [c0034520] (warn_slowpath_fmt+0x2c/0x3c)
 [   31.323913] [c0034520] (warn_slowpath_fmt+0x2c/0x3c) from [c01219bc] 
 (sysfs_open_file+0x70/0x1f8)
 [   31.333618] [c01219bc] (sysfs_open_file+0x70/0x1f8) from [c00ccc94] 
 (__dentry_open+0x1f8/0x30c)
 [   31.343139] [c00ccc94] (__dentry_open+0x1f8/0x30c) from [c00cce58] 
 (nameidata_to_filp+0x50/0x5c)
 [   31.352752] [c00cce58] (nameidata_to_filp+0x50/0x5c) from [c00db4c0] 
 (do_last+0x55c/0x6a0)
 [   31.361999] [c00db4c0] (do_last+0x55c/0x6a0) from [c00db6bc] 
 (path_openat+0xb8/0x37c)
 [   31.370605] [c00db6bc] (path_openat+0xb8/0x37c) from [c00dba60] 
 (do_filp_open+0x30/0x7c)
 [   31.379486] [c00dba60] (do_filp_open+0x30/0x7c) from [c00cc904] 
 (do_sys_open+0xd8/0x170)
 [   31.388366] [c00cc904] (do_sys_open+0xd8/0x170) from [c0012760] 
 (ret_fast_syscall+0x0/0x3c)
 [   31.397552] ---[ end trace 13639ab74f345d7e ]---
 
 Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 

Thanks Laurent for testing this patch.


 Please push it to v3.3 :-)
 

Will send a pull request today itself.

Thanks,
Vaibhav

 -- 
 Regards,
 
 Laurent Pinchart
 
 

--
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/3] wl128x: Add sysfs based support for FM features

2012-03-09 Thread Hans Verkuil

On Wednesday, March 07, 2012 22:42:05 halli manjunatha wrote:
 On Mon, Mar 5, 2012 at 10:24 AM, halli manjunatha hallima...@gmail.com 
 wrote:
  On Fri, Mar 2, 2012 at 3:22 AM, Hans Verkuil hverk...@xs4all.nl wrote:
  On Wednesday, February 29, 2012 18:19:27 halli manjunatha wrote:
  On Wed, Feb 29, 2012 at 5:25 AM, Hans Verkuil hverk...@xs4all.nl wrote:
   On Tuesday, February 28, 2012 23:52:21 halli manjunatha wrote:
   On Tue, Feb 28, 2012 at 4:05 AM, Hans Verkuil hverk...@xs4all.nl 
   wrote:
On Monday, February 27, 2012 17:29:18 halli manjunatha wrote:
Hi Hans,
   
Agreed I don't mind to create new controls for below things
   
1) FM RX Band selection (US/Europe, Japan and Russian bands)
2) FM RX RDS AF turn ON/OFF
3) FM RX RSSI level set/get
4) FM TX Alternate Frequency set/get
5) FM RX De-Emphasis mode set/get
   
However, previously you have suggested me to hide few controls (like
band selection) from the user but few of our application wanted
controls like above and that is why I have created the sysfs 
entries.
   
Please suggest me how can I move forward with new controls or with 
sysfs?
   
The first question is which of these controls are general to FM 
receivers or
transmitters, and which are specific to this chipset. The chipset 
specific
controls should be private controls (look at 
V4L2_CID_MPEG_CX2341X_BASE in
videodev2.h how those are defined). The others should be defined as 
new
controls of the FM_TX class or the FM_RX class. The FM_RX class 
should be
defined as a new class as it doesn't exist at the moment. Don't 
forget to
document these controls clearly.
   
With regards to the band selection: I remember that there was a 
discussion,
but not the details. Do you have a link to that discussion? I can't 
find it
(at least not quickly :-) ).
  
   Below features are generic to all FM receivers so we can add new CID's
   for below features
   1) FM RX RDS AF turn ON/OFF
   2) FM TX Alternate Frequency set/get
  
   About other 3 features its different issue,
   1) FM RX Band selection (US/Europe, Japan and Russian bands)
   2) FM RX RSSI level set/get
   3) FM RX De-Emphasis mode set/get
  
   All these 3 features are generic to any FM receiver, only question is
   does all FM receivers wants to expose these controls to application
   writer?
  
   Good question, and there is no good answer at the moment. See e.g. this
   IRC discussion:
  
   http://www.spinics.net/lists/linux-media/msg44023.html
  
   In the absence of a good solution to this problem I am inclined to make
   these controls driver specific but marked experimental. The experimental
   tag allows us to eventually make it a generic control without too much
   hassle.
 
  Agreed, I will make them driver specific and mark them as experimental.
 
  
   Example Band selection, every FM receiver at the minimum supports both
   Europe and Japan band, now the question is should we add a CID to
   switch between these two bands?
  
   If we decide to add a band selection control, then that would be a menu
   control (since there are up to three bands) and it would only be 
   implemented
   by drivers that need it.
  
   What I am still not clear on is *why* you would want this control. What
   is the reason your customers want this? What does it allow you to do 
   that
   can't be done today?
 
  There are 2 reasons for this,
 
  First, our chip supports weather band, unlike other bands (Europe,
  Japan and Russian) user may wants to
  switch to weather band and wants to listen to weather report and again
  switches back to normal band.
 
  OK, that makes sense. Are the RX and TX independent with regards to
  band selection?
 
  Yes - RX and TX are independent of band selection
 
  Make sure that when the band is changed the rangelow and rangehigh values
  are also changed. If the current frequency is out of that range, then the
  frequency should be clamped to the closest value frequency. Although an
  alternative strategy might be to remember the last used frequency for each
  band. That might make more sense in the case of switching between a normal
  band and the weather band. We need to define and document which strategy
  should be used here.
 
  As of now when I switch to new band I just set the frequency to lowest
  of the new band.
  In this way user can seek and tune to what ever channel he wants.
 
 Hans,
 
 Which implementation you wants? start with the lowest of the new band
 or closer to the frequency of old band? do we need to remember the
 present frequency of the band before switching to new band?
 
 Please let me know your views.

The initial frequency of each band is driver dependent. That's how drivers
act at the moment, so we keep that.

When switching bands it is best to keep the frequency closest to the old band.
This makes sense when switching from e.g. US/Europe

Re: Lockup on second streamon with omap3-isp

2012-03-09 Thread Laurent Pinchart

Hi Jean-Philippe,

On Friday 09 March 2012 08:30:10 jean-philippe francois wrote:
 Le 9 mars 2012 00:28, Laurent Pinchart a écrit :
  On Thursday 08 March 2012 19:22:53 Sakari Ailus wrote:
  On Wed, Mar 07, 2012 at 03:24:29PM +0100, jean-philippe francois wrote:
   Le 6 mars 2012 18:08, jean-philippe francois a écrit :
Hi,

I have a custom dm3730 board, running a 3.2.0 kernel.
The board is equipped with an aptina MT9J sensor on
parallel interface.

Whenever I try to run yavta twice, the second run leads to a
soft lockup in omap3isp_video_queue_streamon (see below)

What can I do / test  to debug this issue ?
   
   Examining the offset, The code is stuck in the for_each loop,
   but I fail to see why.
   
   I added list manipulation and spinlock debugging, without detecting any
   problem.
   
# get.vga
Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size
307200
Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size
307200
3 buffers requested.
length: 307200 offset: 0
Buffer 0 mapped at address 0x4023e000.
length: 307200 offset: 307200
Buffer 1 mapped at address 0x4034d000.
length: 307200 offset: 614400
Buffer 2 mapped at address 0x40444000.
0 (0) [-] 4294967295 307200 bytes 100.397705 100.397796 7.817 fps
1 (1) [-] 4294967295 307200 bytes 100.495666 100.495788 10.208 fps
2 (2) [-] 4294967295 307200 bytes 100.593658 100.593750 10.205 fps
3 (0) [-] 4294967295 307200 bytes 100.691619 100.691741 10.208 fps
4 (1) [-] 4294967295 307200 bytes 100.789611 100.789703 10.205 fps
5 (2) [-] 4294967295 307200 bytes 100.887573 100.887695 10.208 fps
6 (0) [-] 4294967295 307200 bytes 100.985565 100.985656 10.205 fps
7 (1) [-] 4294967295 307200 bytes 101.083526 101.083709 10.208 fps
8 (2) [-] 4294967295 307200 bytes 101.181488 101.181610 10.208 fps
9 (0) [-] 4294967295 307200 bytes 101.279480 101.279571 10.205 fps
Captured 10 frames in 1.009796 seconds (9.902989 fps, 3042198.137254
B/s).
3 buffers released.
[1]+  Done   httpd
# get.vga
Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size
307200
Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size
307200
3 buffers requested.
length: 307200 offset: 0
Buffer 0 mapped at address 0x40285000.
length: 307200 offset: 307200
Buffer 1 mapped at address 0x40314000.
length: 307200 offset: 614400
Buffer 2 mapped at address 0x403bb000.
BUG: soft lockup - CPU#0 stuck for 22s! [yavta:495]
Modules linked in: ks8851_mll omap3_isp fpgacam(O)

Pid: 495, comm:yavta
CPU: 0Tainted: G   O  (3.2.0 #52)
PC is at __do_softirq+0x50/0x110
LR is at __do_softirq+0x38/0x110
pc : [c003746c]lr : [c0037454]psr: 2113
sp : ce8e5c88  ip : cf406140  fp : 
r10: cee90800  r9 : 000a  r8 : ce8e4000
r7 : 0002  r6 :   r5 :   r4 : 0025
r3 : c044e580  r2 :   r1 : 0002  r0 : 
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8e858019  DAC: 0015
[c00123b0] (unwind_backtrace+0x0/0xec) from [c00646c4]
(watchdog_timer_fn+0xd8/0x128)
[c00646c4] (watchdog_timer_fn+0xd8/0x128) from [c004e640]
(__run_hrtimer+0x68/0xe4)
[c004e640] (__run_hrtimer+0x68/0xe4) from [c004e8b0]
(hrtimer_interrupt+0x11c/0x2a4)
[c004e8b0] (hrtimer_interrupt+0x11c/0x2a4) from [c0018f44]
(omap2_gp_timer_interrupt+0x24/0x34)
[c0018f44] (omap2_gp_timer_interrupt+0x24/0x34) from [c0064df8]
(handle_irq_event_percpu+0x28/0x110)
[c0064df8] (handle_irq_event_percpu+0x28/0x110) from [c0064f34]
(handle_irq_event+0x54/0x74)
[c0064f34] (handle_irq_event+0x54/0x74) from [c00676f8]
(handle_level_irq+0xb4/0x100)
[c00676f8] (handle_level_irq+0xb4/0x100) from [c0064a28]
(generic_handle_irq+0x28/0x30)
[c0064a28] (generic_handle_irq+0x28/0x30) from [c000e570]
(handle_IRQ+0x60/0x84)
[c000e570] (handle_IRQ+0x60/0x84) from [c000d874]
(__irq_svc+0x34/0x98)
[c000d874] (__irq_svc+0x34/0x98) from [c003746c]
(__do_softirq+0x50/0x110) [c003746c] (__do_softirq+0x50/0x110) from
[c00376f0]
(irq_exit+0x48/0x9c)omap3isp_video_queue_streamon
[c00376f0] (irq_exit+0x48/0x9c) from [c000e574]
(handle_IRQ+0x64/0x84)
[c000e574] (handle_IRQ+0x64/0x84) from [c000d874]
(__irq_svc+0x34/0x98)
[c000d874] (__irq_svc+0x34/0x98) from [bf007864] (+0x6c/0xa0
[omap3_isp])
  
  As it's __irq_svc(), I'd guess it's stuck executing the ISP interrupt
  handler. This shouldn't happen.
  
  Is the sensor a parallel one?
  
  There

[PATCH] V4L: Improve the selection API documentation

2012-03-09 Thread Sylwester Nawrocki

Make the VIDIOC_G/S_SELECTION ioctls documentation more consistent
with the rest of media Docbook, use capital letters where necessary
and correct few minor errors.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 Documentation/DocBook/media/v4l/selection-api.xml  |8 +-
 .../DocBook/media/v4l/vidioc-g-selection.xml   |  106 ++--
 include/linux/videodev2.h  |   30 +++---
 3 files changed, 76 insertions(+), 68 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/selection-api.xml 
b/Documentation/DocBook/media/v4l/selection-api.xml
index 2f0bdb4..b299e47 100644
--- a/Documentation/DocBook/media/v4l/selection-api.xml
+++ b/Documentation/DocBook/media/v4l/selection-api.xml
@@ -52,6 +52,10 @@ cropping and composing rectangles have the same size./para
  /textobject
/mediaobject
   /figure
+
+For complete list of the available selection targets see table xref
+linkend=v4l2-sel-target/
+
 /section
 
   section
@@ -186,7 +190,7 @@ V4L2_SEL_TGT_COMPOSE_ACTIVE /constant target./para
 
section
 
- titleScaling control./title
+ titleScaling control/title
 
 paraAn application can detect if scaling is performed by comparing the width
 and the height of rectangles obtained using constant V4L2_SEL_TGT_CROP_ACTIVE
@@ -200,7 +204,7 @@ the scaling ratios using these values./para
 
   section
 
-titleComparison with old cropping API./title
+titleComparison with old cropping API/title
 
 paraThe selection API was introduced to cope with deficiencies of previous
 link linkend=crop API /link, that was designed to control simple capture
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml 
b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml
index a9d36e0..bb04eff 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml
@@ -58,43 +58,43 @@
 
 paraThe ioctls are used to query and configure selection 
rectangles./para
 
-para To query the cropping (composing) rectangle set structfield
-v4l2-selection;::type /structfield to the respective buffer type.  Do not
-use multiplanar buffers.  Use constant V4L2_BUF_TYPE_VIDEO_CAPTURE
+para To query the cropping (composing) rectangle set v4l2-selection;
+structfield type /structfield field to the respective buffer type.
+Do not use multiplanar buffers.  Use constant V4L2_BUF_TYPE_VIDEO_CAPTURE
 /constant instead of constant V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
 /constant.  Use constant V4L2_BUF_TYPE_VIDEO_OUTPUT /constant instead of
 constant V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE /constant.  The next step is
-setting structfield v4l2-selection;::target /structfield to value
-constant V4L2_SEL_TGT_CROP_ACTIVE /constant (constant
+setting the value of v4l2-selection; structfieldtarget/structfield field
+to constant V4L2_SEL_TGT_CROP_ACTIVE /constant (constant
 V4L2_SEL_TGT_COMPOSE_ACTIVE /constant).  Please refer to table xref
 linkend=v4l2-sel-target / or xref linkend=selection-api / for additional
-targets.  Fields structfield v4l2-selection;::flags /structfield and
-structfield v4l2-selection;::reserved /structfield are ignored and they
-must be filled with zeros.  The driver fills the rest of the structure or
+targets.  The structfieldflags/structfield and structfieldreserved
+/structfield fields of v4l2-selection; are ignored and they must be filled
+with zeros.  The driver fills the rest of the structure or
 returns EINVAL; if incorrect buffer type or target was used. If cropping
 (composing) is not supported then the active rectangle is not mutable and it is
-always equal to the bounds rectangle.  Finally, structure structfield
-v4l2-selection;::r /structfield is filled with the current cropping
+always equal to the bounds rectangle.  Finally, the v4l2-rect;
+structfieldr/structfield rectangle is filled with the current cropping
 (composing) coordinates. The coordinates are expressed in driver-dependent
 units. The only exception are rectangles for images in raw formats, whose
 coordinates are always expressed in pixels.  /para
 
-para To change the cropping (composing) rectangle set structfield
-v4l2-selection;::type /structfield to the respective buffer type.  Do not
+para To change the cropping (composing) rectangle set the v4l2-selection;
+structfieldtype/structfield field to the respective buffer type.  Do not
 use multiplanar buffers.  Use constant V4L2_BUF_TYPE_VIDEO_CAPTURE
 /constant instead of constant V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
 /constant.  Use constant V4L2_BUF_TYPE_VIDEO_OUTPUT /constant instead of
 constant V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE /constant.  The next step is
-setting structfield v4l2-selection;::target /structfield to value
-constant V4L2_SEL_TGT_CROP_ACTIVE /constant (constant
+setting the value of v4l2-selection; structfieldtarget/structfield to
+constantV4L2_SEL_TGT_CROP_ACTIVE/constant (constant

[PATCH] omap_vout: Fix DMA transaction error issue when rotation is enabled

2012-03-09 Thread Vaibhav Hiremath

When rotation is enabled and driver is configured in USERPTR
buffer exchange mechanism, in specific use-case driver reports
an error,
   DMA transaction error with device 0.

In driver _buffer_prepare funtion, we were using
vout-buf_phy_addr[vb-i] for buffer physical address to
configure SDMA channel, but this variable does get updated
only during init.
And the issue will occur when driver allocates less number
of buffers during init and application requests more buffers
through REQBUF ioctl; this variable will lead to invalid
configuration of SDMA channel leading to DMA transaction error.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
Archit/Laurent,
Can you help me to validate this patch on your platform/usecase?

 drivers/media/video/omap/omap_vout_vrfb.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout_vrfb.c 
b/drivers/media/video/omap/omap_vout_vrfb.c
index 4be26ab..240d36d 100644
--- a/drivers/media/video/omap/omap_vout_vrfb.c
+++ b/drivers/media/video/omap/omap_vout_vrfb.c
@@ -225,7 +225,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
if (!is_rotation_enabled(vout))
return 0;

-   dmabuf = vout-buf_phy_addr[vb-i];
+   dmabuf = (dma_addr_t) vout-queued_buf_addr[vb-i];
/* If rotation is enabled, copy input buffer into VRFB
 * memory space using DMA. We are copying input buffer
 * into VRFB memory space of desired angle and DSS will
--
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

[PATCH] omap_vout: Fix the build warning and section miss-match warning

2012-03-09 Thread Vaibhav Hiremath

Patch fixes below build warning and section miss-match warning 
from omap_vout driver -

Build warnings:
=
drivers/media/video/omap/omap_vout.c: In function 'omapvid_setup_overlay':
drivers/media/video/omap/omap_vout.c:381:17: warning: 'mode' may be used
uninitialized in this function

Section Mis-Match warnings:
==
WARNING: drivers/media/video/omap/omap-vout.o(.data+0x0): Section mismatch in
reference from the variable
omap_vout_driver to the function .init.text:omap_vout_probe()
The variable omap_vout_driver references
the function __init omap_vout_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 drivers/media/video/omap/omap_vout.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index dffcf66..0fb0437 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -328,7 +328,7 @@ static int video_mode_to_dss_mode(struct omap_vout_device 
*vout)
struct omap_overlay *ovl;
struct omapvideo_info *ovid;
struct v4l2_pix_format *pix = vout-pix;
-   enum omap_color_mode mode;
+   enum omap_color_mode mode = -EINVAL;

ovid = vout-vid_info;
ovl = ovid-overlays[0];
@@ -2108,7 +2108,7 @@ static void omap_vout_cleanup_device(struct 
omap_vout_device *vout)
kfree(vout);
 }

-static int omap_vout_remove(struct platform_device *pdev)
+static int __devexit omap_vout_remove(struct platform_device *pdev)
 {
int k;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -2129,7 +2129,7 @@ static int omap_vout_remove(struct platform_device *pdev)
return 0;
 }

-static int __init omap_vout_probe(struct platform_device *pdev)
+static int __devinit omap_vout_probe(struct platform_device *pdev)
 {
int ret = 0, i;
struct omap_overlay *ovl;
@@ -2241,9 +2241,10 @@ probe_err0:
 static struct platform_driver omap_vout_driver = {
.driver = {
.name = VOUT_NAME,
+   .owner = THIS_MODULE,
},
.probe = omap_vout_probe,
-   .remove = omap_vout_remove,
+   .remove = __devexit_p(omap_vout_remove),
 };

 static int __init omap_vout_init(void)
--
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

[PATCH] video: Kconfig: Select VIDEOBUF2_DMA_CONTIG for VIDEO_MX2

2012-03-09 Thread Fabio Estevam

Fix the following build error:

LD  .tmp_vmlinux1
drivers/built-in.o: In function `mx2_camera_init_videobuf':
clkdev.c:(.text+0xcfaf4): undefined reference to `vb2_dma_contig_memops'
drivers/built-in.o: In function `mx2_camera_probe':
clkdev.c:(.devinit.text+0x5734): undefined reference to 
`vb2_dma_contig_init_ctx'
clkdev.c:(.devinit.text+0x5778): undefined reference to 
`vb2_dma_contig_cleanup_ctx'
drivers/built-in.o: In function `mx2_camera_remove':
clkdev.c:(.devexit.text+0x89c): undefined reference to 
`vb2_dma_contig_cleanup_ctx'

commit c6a41e3271 ([media] media i.MX27 camera: migrate driver to videobuf2)
missed to select VIDEOBUF2_DMA_CONTIG in Kconfig.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 drivers/media/video/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 6158073..5c728ec 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1087,7 +1087,7 @@ config VIDEO_MX2_HOSTSUPPORT
 config VIDEO_MX2
tristate i.MX27/i.MX25 Camera Sensor Interface driver
depends on VIDEO_DEV  SOC_CAMERA  (MACH_MX27 || ARCH_MX25)
-   select VIDEOBUF_DMA_CONTIG
+   select VIDEOBUF2_DMA_CONTIG
select VIDEO_MX2_HOSTSUPPORT
---help---
  This is a v4l2 driver for the i.MX27 and the i.MX25 Camera Sensor
-- 
1.7.1

--
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] fix backport patch v2.6.32_kfifo

2012-03-09 Thread Gianluca Gennari

The backport patch v2.6.32_kfifo-patch collides with:
http://patchwork.linuxtv.org/patch/9914/

Moreover, struct kfifo_rec_ptr_1 is not defined in 2.6.32,
so we have to stay with the old buggy implementation.

Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
 backports/v2.6.32_kfifo.patch |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/backports/v2.6.32_kfifo.patch b/backports/v2.6.32_kfifo.patch
index 10075b9..88a435a 100644
--- a/backports/v2.6.32_kfifo.patch
+++ b/backports/v2.6.32_kfifo.patch
@@ -14,7 +14,7 @@
struct list_headlist;   /* to keep track of raw 
clients */
struct task_struct  *thread;
spinlock_t  lock;
--  struct kfifokfifo;  /* fifo for the 
pulse/space durations */
+-  struct kfifo_rec_ptr_1  kfifo;  /* fifo for the 
pulse/space durations */
 +  struct kfifo*kfifo; /* fifo for the 
pulse/space durations */
ktime_t last_event; /* when last event 
occurred */
enum raw_event_type last_type;  /* last event type */
-- 
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

[PATCH] disable IR_GPIO_CIR module for kernels older than 2.6.35

2012-03-09 Thread Gianluca Gennari

The new module introduced with this patch:
http://patchwork.linuxtv.org/patch/10083/
requires request_any_context_irq() first introduced in 2.6.35

Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
 v4l/versions.txt |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/v4l/versions.txt b/v4l/versions.txt
index ff103bf..08b903a 100644
--- a/v4l/versions.txt
+++ b/v4l/versions.txt
@@ -30,6 +30,10 @@ VIDEO_VIA_CAMERA
 
 [2.6.36]
 
+[2.6.35]
+# Requires request_any_context_irq() introduced in 2.6.35
+IR_GPIO_CIR
+
 [2.6.34]
 MACH_DAVINCI_DM6467_EVM
 MFD_TIMBERDALE
-- 
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 v3 5/5] v4l: Add driver for Micron MT9M032 camera sensor

2012-03-09 Thread Laurent Pinchart

Hi Sakari,

On Thursday 08 March 2012 19:17:46 Sakari Ailus wrote:
 On Wed, Mar 07, 2012 at 12:31:34PM +0100, Laurent Pinchart wrote:

[snip]

+static int mt9m032_set_frame_interval(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_frame_interval 
*fi)
+{
+   struct mt9m032 *sensor = to_mt9m032(subdev);
+   int ret;
+
+   if (sensor-streaming)
+   return -EBUSY;
+
+   memset(fi-reserved, 0, sizeof(fi-reserved));
   
   I'm not quite sure these should be touched.
  
  Why not ? Do you think this could cause a regression in the future when
  the fields won't be reserved anymore ?
 
 The user is responsible for setting those fields to zero. If we set them to
 zero for them they will start relying on that. At some point that might not
 hold true anymore.

Thinking about it some more, applications should set the reserved fields to 0, 
or first issue a get call and modify the fields it's interested in, keeping 
the reserved fields at their default value. I'll remove the memset here.

-- 
Regards,

Laurent Pinchart

--
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] disable IR_GPIO_CIR module for kernels older than 2.6.35

2012-03-09 Thread Gianluca Gennari

Sorry, I forgot the [media_build] tag.
This patch is required to fix compilation of the media_buid tree on my
Ubuntu 10.04 system with kernel 2.6.32.

Regards,
Gianluca
--
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] fix backport patch v2.6.32_kfifo

2012-03-09 Thread Gianluca Gennari

Sorry, I forgot the [media_build] tag.
This patch is required to fix compilation of the media_build tree on my
Ubuntu 10.04 system with kernel 2.6.32.

Regards,
Gianluca
--
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] s5p-csis: Fix compilation with PM_SLEEP disabled

2012-03-09 Thread Sylwester Nawrocki

Fix following compilation error when CONFIG_PM_SLEEP is disabled:

  CC  drivers/media/video/s5p-fimc/mipi-csis.o
drivers/media/video/s5p-fimc/mipi-csis.c: In function ‘s5pcsis_remove’:
drivers/media/video/s5p-fimc/mipi-csis.c:956: error: implicit declaration of 
function ‘s5pcsis_suspend’

Reported-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/s5p-fimc/mipi-csis.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/s5p-fimc/mipi-csis.c 
b/drivers/media/video/s5p-fimc/mipi-csis.c
index a903138..f44f690 100644
--- a/drivers/media/video/s5p-fimc/mipi-csis.c
+++ b/drivers/media/video/s5p-fimc/mipi-csis.c
@@ -684,7 +684,7 @@ static int __devexit s5pcsis_remove(struct platform_device 
*pdev)
struct csis_state *state = sd_to_csis_state(sd);
 
pm_runtime_disable(pdev-dev);
-   s5pcsis_suspend(pdev-dev);
+   s5pcsis_pm_suspend(pdev-dev, false);
clk_disable(state-clock[CSIS_CLK_MUX]);
pm_runtime_set_suspended(pdev-dev);
s5pcsis_clk_put(state);
-- 
1.7.9

--
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: Lockup on second streamon with omap3-isp

2012-03-09 Thread Laurent Pinchart

Hi Michael,

On Friday 09 March 2012 13:54:31 Michael Jones wrote:
 On 03/09/2012 11:42 AM, Laurent Pinchart wrote:
  Hi Jean-Philippe,
 
 [snip]
 
   From my experience, the ISP doesn't handle free-running sensors very
   well.
  
  There are other things it doesn't handle well, such as sensors stopping in
  the middle of the frame. I would consider this as limitations.
 
 Considering choking on sensors which stop in the middle of the frame- is
 this just a limitation of the driver, or is it really a limitation of
 the ISP hardware itself?

It's a limitation of the hardware. Various OMAP3 ISP blocks can't be stopped 
before they have processed a complete frame once they have been started. The 
work around is to reset the whole ISP, which we will do in v3.4, but that 
won't solve the problem completely if one application uses the resizer in 
memory-to-memory mode and another application uses the rest of the ISP. In 
that case the driver won't be able to reset the ISP as long as the first 
application uses it.

 It is at least a limitation of the driver because we rely on the VD1 and VD0
 interrupts, so we'll of course have problems if we never get to the last
 line.  But isn't it conceivable to use HS_VS to do our end-of-frame stuff
 instead of VD0?  Maybe then the ISP would be OK with frames that ended
 early, as long as they had reached VD1.  Then of course, you could move VD1
 to an even earlier line, even to the first line.
 
 Do you think that's possible?

Unfortunately not. HS_VS could be used as a fallback to detect the end of a 
frame in case something bad occurs, but that hardware will still be stuck 
waiting for the end of the frame. The real problem here is a lack of feature 
on the hardware side, the ISP modules should either support being stopped in 
the middle of a frame, or support per-module reset.

-- 
Regards,

Laurent Pinchart

--
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: Lockup on second streamon with omap3-isp

2012-03-09 Thread Michael Jones


Hi Laurent,

On 03/09/2012 11:42 AM, Laurent Pinchart wrote:

Hi Jean-Philippe,


[snip]

 From my experience, the ISP doesn't handle free-running sensors very well.
There are other things it doesn't handle well, such as sensors stopping in the
middle of the frame. I would consider this as limitations.


Considering choking on sensors which stop in the middle of the frame- is 
this just a limitation of the driver, or is it really a limitation of 
the ISP hardware itself?  It is at least a limitation of the driver 
because we rely on the VD1 and VD0 interrupts, so we'll of course have 
problems if we never get to the last line.  But isn't it conceivable to 
use HS_VS to do our end-of-frame stuff instead of VD0?  Maybe then the 
ISP would be OK with frames that ended early, as long as they had 
reached VD1.  Then of course, you could move VD1 to an even earlier 
line, even to the first line.


Do you think that's possible?

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
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] fix backport patch v2.6.32_kfifo

2012-03-09 Thread Mauro Carvalho Chehab

Em 09-03-2012 09:26, Gianluca Gennari escreveu:
 Sorry, I forgot the [media_build] tag.
 This patch is required to fix compilation of the media_build tree on my
 Ubuntu 10.04 system with kernel 2.6.32.

Both patches applied, thanks!

Mauro.
 
 Regards,
 Gianluca

--
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 0/5] MT9M032 and MT9P031 sensor patches

2012-03-09 Thread Laurent Pinchart

Here's the fourth version of the MT9M032 and MT9P031 sensor patches for v3.4.

Compared to v3, only patch 5/5 has been changed. I've added locking to the
driver, removed the memset to 0 for the reserved fields in the frame interval
set handler, fixed a typo in a kernel log message and moved the driver to the
right location in Kconfig and Makefile.

Danny Kukawka (1):
  mt9p031: Remove duplicate media/v4l2-subdev.h include

Laurent Pinchart (3):
  mt9p031: Remove unused xskip and yskip fields in struct mt9p031
  v4l: Aptina-style sensor PLL support
  mt9p031: Use generic PLL setup code

Martin Hostettler (1):
  v4l: Add driver for Micron MT9M032 camera sensor

 drivers/media/video/Kconfig  |   12 +
 drivers/media/video/Makefile |5 +
 drivers/media/video/aptina-pll.c |  174 
 drivers/media/video/aptina-pll.h |   56 +++
 drivers/media/video/mt9m032.c|  862 ++
 drivers/media/video/mt9p031.c|   67 ++--
 include/media/mt9m032.h  |   36 ++
 7 files changed, 1172 insertions(+), 40 deletions(-)
 create mode 100644 drivers/media/video/aptina-pll.c
 create mode 100644 drivers/media/video/aptina-pll.h
 create mode 100644 drivers/media/video/mt9m032.c
 create mode 100644 include/media/mt9m032.h

-- 
Regards,

Laurent Pinchart

--
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/5] mt9p031: Remove duplicate media/v4l2-subdev.h include

2012-03-09 Thread Laurent Pinchart

From: Danny Kukawka danny.kuka...@bisect.de

drivers/media/video/mt9p031.c included 'media/v4l2-subdev.h' twice,
remove the duplicate.

Signed-off-by: Danny Kukawka danny.kuka...@bisect.de
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/mt9p031.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
index 93c3ec7..dd937df 100644
--- a/drivers/media/video/mt9p031.c
+++ b/drivers/media/video/mt9p031.c
@@ -19,7 +19,6 @@
 #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
-- 
1.7.3.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

[PATCH v4 4/5] mt9p031: Use generic PLL setup code

2012-03-09 Thread Laurent Pinchart

Compute the PLL parameters at runtime using the generic Aptina PLL
helper.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Sakari Ailus sakari.ai...@iki.fi
---
 drivers/media/video/Kconfig   |1 +
 drivers/media/video/mt9p031.c |   62 ++---
 2 files changed, 28 insertions(+), 35 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 7867b0b..666836d 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -473,6 +473,7 @@ config VIDEO_OV7670
 config VIDEO_MT9P031
tristate Aptina MT9P031 support
depends on I2C  VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
+   select VIDEO_APTINA_PLL
---help---
  This is a Video4Linux2 sensor-level driver for the Aptina
  (Micron) mt9p031 5 Mpixel camera.
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
index 52dd9f8..3bcd14b 100644
--- a/drivers/media/video/mt9p031.c
+++ b/drivers/media/video/mt9p031.c
@@ -27,6 +27,8 @@
 #include media/v4l2-device.h
 #include media/v4l2-subdev.h
 
+#include aptina-pll.h
+
 #define MT9P031_PIXEL_ARRAY_WIDTH  2752
 #define MT9P031_PIXEL_ARRAY_HEIGHT 2004
 
@@ -97,14 +99,6 @@
 #define MT9P031_TEST_PATTERN_RED   0xa2
 #define MT9P031_TEST_PATTERN_BLUE  0xa3
 
-struct mt9p031_pll_divs {
-   u32 ext_freq;
-   u32 target_freq;
-   u8 m;
-   u8 n;
-   u8 p1;
-};
-
 struct mt9p031 {
struct v4l2_subdev subdev;
struct media_pad pad;
@@ -115,7 +109,7 @@ struct mt9p031 {
struct mutex power_lock; /* lock to protect power_count */
int power_count;
 
-   const struct mt9p031_pll_divs *pll;
+   struct aptina_pll pll;
 
/* Registers cache */
u16 output_control;
@@ -183,33 +177,31 @@ static int mt9p031_reset(struct mt9p031 *mt9p031)
  0);
 }
 
-/*
- * This static table uses ext_freq and vdd_io values to select suitable
- * PLL dividers m, n and p1 which have been calculated as specifiec in p36
- * of Aptina's mt9p031 datasheet. New values should be added here.
- */
-static const struct mt9p031_pll_divs mt9p031_divs[] = {
-   /* ext_freq target_freq m   n   p1 */
-   {2100,  4800,   26, 2,  6}
-};
-
-static int mt9p031_pll_get_divs(struct mt9p031 *mt9p031)
+static int mt9p031_pll_setup(struct mt9p031 *mt9p031)
 {
+   static const struct aptina_pll_limits limits = {
+   .ext_clock_min = 600,
+   .ext_clock_max = 2700,
+   .int_clock_min = 200,
+   .int_clock_max = 1350,
+   .out_clock_min = 18000,
+   .out_clock_max = 36000,
+   .pix_clock_max = 9600,
+   .n_min = 1,
+   .n_max = 64,
+   .m_min = 16,
+   .m_max = 255,
+   .p1_min = 1,
+   .p1_max = 128,
+   };
+
struct i2c_client *client = v4l2_get_subdevdata(mt9p031-subdev);
-   int i;
+   struct mt9p031_platform_data *pdata = mt9p031-pdata;
 
-   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];
-   return 0;
-   }
-   }
+   mt9p031-pll.ext_clock = pdata-ext_freq;
+   mt9p031-pll.pix_clock = pdata-target_freq;
 
-   dev_err(client-dev, Couldn't find PLL dividers for ext_freq = %d, 
-   target_freq = %d\n, mt9p031-pdata-ext_freq,
-   mt9p031-pdata-target_freq);
-   return -EINVAL;
+   return aptina_pll_calculate(client-dev, limits, mt9p031-pll);
 }
 
 static int mt9p031_pll_enable(struct mt9p031 *mt9p031)
@@ -223,11 +215,11 @@ static int mt9p031_pll_enable(struct mt9p031 *mt9p031)
return ret;
 
ret = mt9p031_write(client, MT9P031_PLL_CONFIG_1,
-   (mt9p031-pll-m  8) | (mt9p031-pll-n - 1));
+   (mt9p031-pll.m  8) | (mt9p031-pll.n - 1));
if (ret  0)
return ret;
 
-   ret = mt9p031_write(client, MT9P031_PLL_CONFIG_2, mt9p031-pll-p1 - 1);
+   ret = mt9p031_write(client, MT9P031_PLL_CONFIG_2, mt9p031-pll.p1 - 1);
if (ret  0)
return ret;
 
@@ -900,7 +892,7 @@ static int mt9p031_probe(struct i2c_client *client,
mt9p031-format.field = V4L2_FIELD_NONE;
mt9p031-format.colorspace = V4L2_COLORSPACE_SRGB;
 
-   ret = mt9p031_pll_get_divs(mt9p031);
+   ret = mt9p031_pll_setup(mt9p031);
 
 done:
if (ret  0) {
-- 
1.7.3.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

[PATCH v4 3/5] v4l: Aptina-style sensor PLL support

2012-03-09 Thread Laurent Pinchart

Add a generic helper function to compute PLL parameters for PLL found in
several Aptina sensors.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Sakari Ailus sakari.ai...@iki.fi
---
 drivers/media/video/Kconfig  |3 +
 drivers/media/video/Makefile |4 +
 drivers/media/video/aptina-pll.c |  174 ++
 drivers/media/video/aptina-pll.h |   56 
 4 files changed, 237 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/aptina-pll.c
 create mode 100644 drivers/media/video/aptina-pll.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9495b6a..7867b0b 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -459,6 +459,9 @@ config VIDEO_AK881X
 
 comment Camera sensor devices
 
+config VIDEO_APTINA_PLL
+   tristate
+
 config VIDEO_OV7670
tristate OmniVision OV7670 sensor support
depends on I2C  VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 563443c..d1304e1 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -22,6 +22,10 @@ endif
 
 obj-$(CONFIG_VIDEO_V4L2_COMMON) += v4l2-common.o
 
+# Helper modules
+
+obj-$(CONFIG_VIDEO_APTINA_PLL) += aptina-pll.o
+
 # All i2c modules must come first:
 
 obj-$(CONFIG_VIDEO_TUNER) += tuner.o
diff --git a/drivers/media/video/aptina-pll.c b/drivers/media/video/aptina-pll.c
new file mode 100644
index 000..0bd3813
--- /dev/null
+++ b/drivers/media/video/aptina-pll.c
@@ -0,0 +1,174 @@
+/*
+ * Aptina Sensor PLL Configuration
+ *
+ * Copyright (C) 2012 Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/device.h
+#include linux/gcd.h
+#include linux/kernel.h
+#include linux/lcm.h
+#include linux/module.h
+
+#include aptina-pll.h
+
+int aptina_pll_calculate(struct device *dev,
+const struct aptina_pll_limits *limits,
+struct aptina_pll *pll)
+{
+   unsigned int mf_min;
+   unsigned int mf_max;
+   unsigned int p1_min;
+   unsigned int p1_max;
+   unsigned int p1;
+   unsigned int div;
+
+   dev_dbg(dev, PLL: ext clock %u pix clock %u\n,
+   pll-ext_clock, pll-pix_clock);
+
+   if (pll-ext_clock  limits-ext_clock_min ||
+   pll-ext_clock  limits-ext_clock_max) {
+   dev_err(dev, pll: invalid external clock frequency.\n);
+   return -EINVAL;
+   }
+
+   if (pll-pix_clock == 0 || pll-pix_clock  limits-pix_clock_max) {
+   dev_err(dev, pll: invalid pixel clock frequency.\n);
+   return -EINVAL;
+   }
+
+   /* Compute the multiplier M and combined N*P1 divisor. */
+   div = gcd(pll-pix_clock, pll-ext_clock);
+   pll-m = pll-pix_clock / div;
+   div = pll-ext_clock / div;
+
+   /* We now have the smallest M and N*P1 values that will result in the
+* desired pixel clock frequency, but they might be out of the valid
+* range. Compute the factor by which we should multiply them given the
+* following constraints:
+*
+* - minimum/maximum multiplier
+* - minimum/maximum multiplier output clock frequency assuming the
+*   minimum/maximum N value
+* - minimum/maximum combined N*P1 divisor
+*/
+   mf_min = DIV_ROUND_UP(limits-m_min, pll-m);
+   mf_min = max(mf_min, limits-out_clock_min /
+(pll-ext_clock / limits-n_min * pll-m));
+   mf_min = max(mf_min, limits-n_min * limits-p1_min / div);
+   mf_max = limits-m_max / pll-m;
+   mf_max = min(mf_max, limits-out_clock_max /
+   (pll-ext_clock / limits-n_max * pll-m));
+   mf_max = min(mf_max, DIV_ROUND_UP(limits-n_max * limits-p1_max, div));
+
+   dev_dbg(dev, pll: mf min %u max %u\n, mf_min, mf_max);
+   if (mf_min  mf_max) {
+   dev_err(dev, pll: no valid combined N*P1 divisor.\n);
+   return -EINVAL;
+   }
+
+   /*
+* We're looking for the highest acceptable P1 value for which a
+* multiplier factor MF exists that fulfills the following conditions:
+*
+* 1. p1 is in the [p1_min, p1_max] range given by the limits and is
+*even
+* 2.

[PATCH v4 5/5] v4l: Add driver for Micron MT9M032 camera sensor

2012-03-09 Thread Laurent Pinchart

From: Martin Hostettler mar...@neutronstar.dyndns.org

The MT9M032 is a parallel 1.6MP sensor from Micron controlled through I2C.

The driver creates a V4L2 subdevice. It currently supports cropping, gain,
exposure and v/h flipping controls in monochrome mode with an
external pixel clock.

Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
[Lots of clean up, fixes and enhancements]
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/Kconfig   |8 +
 drivers/media/video/Makefile  |1 +
 drivers/media/video/mt9m032.c |  862 +
 include/media/mt9m032.h   |   36 ++
 4 files changed, 907 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mt9m032.c
 create mode 100644 include/media/mt9m032.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 666836d..745e958 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -470,6 +470,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
 
+config VIDEO_MT9M032
+   tristate MT9M032 camera sensor support
+   depends on I2C  VIDEO_V4L2
+   select VIDEO_APTINA_PLL
+   ---help---
+ This driver supports MT9M032 camera sensors from Aptina, monochrome
+ models only.
+
 config VIDEO_MT9P031
tristate Aptina MT9P031 support
depends on I2C  VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index d1304e1..f6af1d3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -69,6 +69,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_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
 obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
 obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
diff --git a/drivers/media/video/mt9m032.c b/drivers/media/video/mt9m032.c
new file mode 100644
index 000..8de5276
--- /dev/null
+++ b/drivers/media/video/mt9m032.c
@@ -0,0 +1,862 @@
+/*
+ * Driver for MT9M032 CMOS Image Sensor from Micron
+ *
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/math64.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/slab.h
+#include linux/v4l2-mediabus.h
+
+#include media/media-entity.h
+#include media/mt9m032.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+
+#include aptina-pll.h
+
+/*
+ * width and height include active boundary and black parts
+ *
+ * column0-  15 active boundry
+ * column   16-1455 image
+ * column 1456-1471 active boundry
+ * column 1472-1599 black
+ *
+ * row   0-  51 black
+ * row  53-  59 active boundry
+ * row  60-1139 image
+ * row1140-1147 active boundry
+ * row1148-1151 black
+ */
+
+#define MT9M032_PIXEL_ARRAY_WIDTH  1600
+#define MT9M032_PIXEL_ARRAY_HEIGHT 1152
+
+#define MT9M032_CHIP_VERSION   0x00
+#defineMT9M032_CHIP_VERSION_VALUE  0x1402
+#define MT9M032_ROW_START  0x01
+#defineMT9M032_ROW_START_MIN   0
+#defineMT9M032_ROW_START_MAX   1152
+#defineMT9M032_ROW_START_DEF   60
+#define MT9M032_COLUMN_START   0x02
+#defineMT9M032_COLUMN_START_MIN0
+#defineMT9M032_COLUMN_START_MAX1600
+#defineMT9M032_COLUMN_START_DEF16
+#define MT9M032_ROW_SIZE   0x03
+#defineMT9M032_ROW_SIZE_MIN32
+#defineMT9M032_ROW_SIZE_MAX1152
+#defineMT9M032_ROW_SIZE_DEF1080
+#define MT9M032_COLUMN_SIZE0x04
+#define

[PATCH v4 2/5] mt9p031: Remove unused xskip and yskip fields in struct mt9p031

2012-03-09 Thread Laurent Pinchart

The fields are set but never used, remove them.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Sakari Ailus sakari.ai...@iki.fi
---
 drivers/media/video/mt9p031.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
index dd937df..52dd9f8 100644
--- a/drivers/media/video/mt9p031.c
+++ b/drivers/media/video/mt9p031.c
@@ -114,8 +114,6 @@ struct mt9p031 {
struct mt9p031_platform_data *pdata;
struct mutex power_lock; /* lock to protect power_count */
int power_count;
-   u16 xskip;
-   u16 yskip;
 
const struct mt9p031_pll_divs *pll;
 
@@ -784,8 +782,6 @@ static int mt9p031_open(struct v4l2_subdev *subdev, struct 
v4l2_subdev_fh *fh)
format-field = V4L2_FIELD_NONE;
format-colorspace = V4L2_COLORSPACE_SRGB;
 
-   mt9p031-xskip = 1;
-   mt9p031-yskip = 1;
return mt9p031_set_power(subdev, 1);
 }
 
-- 
1.7.3.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: Lockup on second streamon with omap3-isp

2012-03-09 Thread jean-philippe francois

 Thank you, I will try this and keep you posted.
 With this sensor it is possible, but that is not the case for every
 sensor out there.
 Is this an ISP bug ?

 From my experience, the ISP doesn't handle free-running sensors very well.
 There are other things it doesn't handle well, such as sensors stopping in the
 middle of the frame. I would consider this as limitations.

 This shouldn't cause any interrupt storm though, but I'd like you to check
 just in case. Floating HS/VS signals that would happen to oscillate near the
 logic threshold voltage is my main guess for your problem.

Unless there is a soldering problem, this is not the case. Oscilloscope
traces look fine. And I would not get images out of the driver if
Hsync / Vsync was
garbage. Anyway, stopping / restarting the sensor removes the bug symptom,
thanks a lot for this hint.


 It never happens on first start, ie before ccdc_configure is called
 for the first time.
 Is there a way to eventually handle this in the driver ?

 Let's first find out where the problam comes from exactly.

If it's an interrupt storm, I should be able to printk debug it,
I will keep you posted.

Jean-Philippe François
--
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 25/35] omap3isp: Collect entities that are part of the pipeline

2012-03-09 Thread Sakari Ailus

Collect entities which are part of the pipeline into a single bit mask.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 drivers/media/video/omap3isp/ispvideo.c |   61 +--
 drivers/media/video/omap3isp/ispvideo.h |2 +
 2 files changed, 35 insertions(+), 28 deletions(-)

diff --git a/drivers/media/video/omap3isp/ispvideo.c 
b/drivers/media/video/omap3isp/ispvideo.c
index d34f690..8ce3c5b 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -255,8 +255,9 @@ isp_video_remote_subdev(struct isp_video *video, u32 *pad)
 }
 
 /* Return a pointer to the ISP video instance at the far end of the pipeline. 
*/
-static struct isp_video *
-isp_video_far_end(struct isp_video *video)
+static int isp_video_get_graph_data(struct isp_video *video,
+   struct isp_pipeline *pipe,
+   enum isp_pipeline_state *state)
 {
struct media_entity_graph graph;
struct media_entity *entity = video-video.entity;
@@ -267,21 +268,40 @@ isp_video_far_end(struct isp_video *video)
media_entity_graph_walk_start(graph, entity);
 
while ((entity = media_entity_graph_walk_next(graph))) {
+   struct isp_video *__video;
+
+   pipe-entities |= 1  entity-id;
+
+   if (far_end != NULL)
+   continue;
+
if (entity == video-video.entity)
continue;
 
if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE)
continue;
 
-   far_end = to_isp_video(media_entity_to_video_device(entity));
-   if (far_end-type != video-type)
-   break;
-
-   far_end = NULL;
+   __video = to_isp_video(media_entity_to_video_device(entity));
+   if (__video-type != video-type)
+   far_end = __video;
}
 
mutex_unlock(mdev-graph_mutex);
-   return far_end;
+
+   if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+   *state = ISP_PIPELINE_STREAM_OUTPUT | ISP_PIPELINE_IDLE_OUTPUT;
+   pipe-input = far_end;
+   pipe-output = video;
+   } else {
+   if (far_end == NULL)
+   return -EPIPE;
+
+   *state = ISP_PIPELINE_STREAM_INPUT | ISP_PIPELINE_IDLE_INPUT;
+   pipe-input = video;
+   pipe-output = far_end;
+   }
+
+   return 0;
 }
 
 /*
@@ -972,7 +992,6 @@ isp_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
struct isp_video *video = video_drvdata(file);
enum isp_pipeline_state state;
struct isp_pipeline *pipe;
-   struct isp_video *far_end;
unsigned long flags;
int ret;
 
@@ -992,6 +1011,8 @@ isp_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
pipe = video-video.entity.pipe
 ? to_isp_pipeline(video-video.entity) : video-pipe;
 
+   pipe-entities = 0;
+
if (video-isp-pdata-set_constraints)
video-isp-pdata-set_constraints(video-isp, true);
pipe-l3_ick = clk_get_rate(video-isp-clock[ISP_CLK_L3_ICK]);
@@ -1011,25 +1032,9 @@ isp_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
video-bpl_padding = ret;
video-bpl_value = vfh-format.fmt.pix.bytesperline;
 
-   /* Find the ISP video node connected at the far end of the pipeline and
-* update the pipeline.
-*/
-   far_end = isp_video_far_end(video);
-
-   if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
-   state = ISP_PIPELINE_STREAM_OUTPUT | ISP_PIPELINE_IDLE_OUTPUT;
-   pipe-input = far_end;
-   pipe-output = video;
-   } else {
-   if (far_end == NULL) {
-   ret = -EPIPE;
-   goto err_check_format;
-   }
-
-   state = ISP_PIPELINE_STREAM_INPUT | ISP_PIPELINE_IDLE_INPUT;
-   pipe-input = video;
-   pipe-output = far_end;
-   }
+   ret = isp_video_get_graph_data(video, pipe, state);
+   if (ret  0)
+   goto err_check_format;
 
/* Validate the pipeline and update its state. */
ret = isp_video_validate_pipeline(pipe);
diff --git a/drivers/media/video/omap3isp/ispvideo.h 
b/drivers/media/video/omap3isp/ispvideo.h
index d91bdb9..c9187cb 100644
--- a/drivers/media/video/omap3isp/ispvideo.h
+++ b/drivers/media/video/omap3isp/ispvideo.h
@@ -88,6 +88,7 @@ enum isp_pipeline_state {
 /*
  * struct isp_pipeline - An ISP hardware pipeline
  * @error: A hardware error occurred during capture
+ * @entities: Bitmask of entities in the pipeline (indexed by entity ID)
  */
 struct isp_pipeline {
struct media_pipeline pipe;
@@ -96,6 +97,7 @@ struct isp_pipeline {
enum isp_pipeline_stream_state stream_state;
struct

cron job: media_tree daily build: ERRORS

2012-03-09 Thread Hans Verkuil

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Fri Mar  9 19:00:19 CET 2012
git hash:632fba4d012458fd5fedc678fb9b0f8bc59ceda2
gcc version:  i686-linux-gcc (GCC) 4.6.2
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-enoxys: ERRORS
linux-git-arm-eabi-omap: ERRORS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: ERRORS
linux-2.6.35.3-i686: ERRORS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2.1-i686: WARNINGS
linux-3.3-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: ERRORS
linux-2.6.35.3-x86_64: ERRORS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 5/5] v4l: Add driver for Micron MT9M032 camera sensor

2012-03-09 Thread Sakari Ailus

Hi Laurent,

Thanks for the patch. Just a few minor comments below.

Laurent Pinchart wrote:
...
 +static int mt9m032_setup_pll(struct mt9m032 *sensor)
 +{
 + static const struct aptina_pll_limits limits = {
 + .ext_clock_min = 800,
 + .ext_clock_max = 1650,
 + .int_clock_min = 200,
 + .int_clock_max = 2400,
 + .out_clock_min = 32200,
 + .out_clock_max = 69300,
 + .pix_clock_max = 9900,
 + .n_min = 1,
 + .n_max = 64,
 + .m_min = 16,
 + .m_max = 255,
 + .p1_min = 1,
 + .p1_max = 128,
 + };
 +
 + struct i2c_client *client = v4l2_get_subdevdata(sensor-subdev);
 + struct mt9m032_platform_data *pdata = sensor-pdata;
 + struct aptina_pll pll;
 + int ret;
 +
 + pll.ext_clock = pdata-ext_clock;
 + pll.pix_clock = pdata-pix_clock;
 +
 + ret = aptina_pll_calculate(client-dev, limits, pll);
 + if (ret  0)
 + return ret;
 +
 + sensor-pix_clock = pll.pix_clock;

I wouldn't expect aptina_pll_calculate() to change the supplied pixel
clock. I'd consider it a bug if it does that. So you could use the pixel
clock from platform data equally well.

 + ret = mt9m032_write(client, MT9M032_PLL_CONFIG1,
 + (pll.m  MT9M032_PLL_CONFIG1_MUL_SHIFT)
 + | (pll.p1 - 1));
 + if (!ret)
 + ret = mt9m032_write(client, MT9P031_PLL_CONFIG2, pll.n - 1);
 + if (!ret)
 + ret = mt9m032_write(client, MT9P031_PLL_CONTROL,
 + MT9P031_PLL_CONTROL_PWRON |
 + MT9P031_PLL_CONTROL_USEPLL);
 + if (!ret)   /* more reserved, Continuous, Master Mode */
 + ret = mt9m032_write(client, MT9M032_READ_MODE1, 0x8006);
 + if (!ret)   /* Set 14-bit mode, select 7 divider */
 + ret = mt9m032_write(client, MT9M032_FORMATTER1, 0x111e);
 +
 + return ret;
 +}

...
 +static int mt9m032_set_pad_format(struct v4l2_subdev *subdev,
 +   struct v4l2_subdev_fh *fh,
 +   struct v4l2_subdev_format *fmt)
 +{
 + struct mt9m032 *sensor = to_mt9m032(subdev);
 + int ret;
 +
 + mutex_lock(sensor-lock);
 +
 + if (sensor-streaming  fmt-which == V4L2_SUBDEV_FORMAT_ACTIVE) {
 + ret = -EBUSY;
 + goto done;
 + }
 +
 + /* Scaling is not supported, the format is thus fixed. */
 + ret = mt9m032_get_pad_format(subdev, fh, fmt);
 +
 +done:
 + mutex_lock(sensor-lock);
 + return ret;
 +}
 +
 +static int mt9m032_get_crop(struct v4l2_subdev *subdev,
 + struct v4l2_subdev_fh *fh,
 + struct v4l2_subdev_crop *crop)
 +{
 + struct mt9m032 *sensor = to_mt9m032(subdev);
 +
 + mutex_lock(sensor-lock);
 + crop-rect = *__mt9m032_get_pad_crop(sensor, fh, crop-which);
 + mutex_unlock(sensor-lock);
 +
 + return 0;
 +}

Shouldn't these two be renamed --- you've got pad in set/get fmt names
as well.

 +static int mt9m032_set_crop(struct v4l2_subdev *subdev,
 + struct v4l2_subdev_fh *fh,
 + struct v4l2_subdev_crop *crop)
 +{
 + struct mt9m032 *sensor = to_mt9m032(subdev);
 + struct v4l2_mbus_framefmt *format;
 + struct v4l2_rect *__crop;
 + struct v4l2_rect rect;
 + int ret = 0;
 +
 + mutex_lock(sensor-lock);
 +
 + if (sensor-streaming  crop-which == V4L2_SUBDEV_FORMAT_ACTIVE) {
 + ret = -EBUSY;
 + goto done;
 + }
 +
 + /* Clamp the crop rectangle boundaries and align them to a multiple of 2
 +  * pixels to ensure a GRBG Bayer pattern.
 +  */
 + rect.left = clamp(ALIGN(crop-rect.left, 2), MT9M032_COLUMN_START_MIN,
 +   MT9M032_COLUMN_START_MAX);
 + rect.top = clamp(ALIGN(crop-rect.top, 2), MT9M032_ROW_START_MIN,
 +  MT9M032_ROW_START_MAX);
 + rect.width = clamp(ALIGN(crop-rect.width, 2), MT9M032_COLUMN_SIZE_MIN,
 +MT9M032_COLUMN_SIZE_MAX);
 + rect.height = clamp(ALIGN(crop-rect.height, 2), MT9M032_ROW_SIZE_MIN,
 + MT9M032_ROW_SIZE_MAX);
 +
 + rect.width = min(rect.width, MT9M032_PIXEL_ARRAY_WIDTH - rect.left);
 + rect.height = min(rect.height, MT9M032_PIXEL_ARRAY_HEIGHT - rect.top);
 +
 + __crop = __mt9m032_get_pad_crop(sensor, fh, crop-which);
 +
 + if (rect.width != __crop-width || rect.height != __crop-height) {
 + /* Reset the output image size if the crop rectangle size has
 +  * been modified.
 +  */
 + format = __mt9m032_get_pad_format(sensor, fh, crop-which);
 + format-width = rect.width;
 + format-height = rect.height;
 + }
 +
 + *__crop = rect;
 + crop-rect = rect;
 +
 +

Re: [PATCH v4 5/5] v4l: Add driver for Micron MT9M032 camera sensor

2012-03-09 Thread Laurent Pinchart

Hi Sakari,

On Friday 09 March 2012 21:15:28 Sakari Ailus wrote:
 Hi Laurent,
 
 Thanks for the patch. Just a few minor comments below.

Thanks for the review.

 Laurent Pinchart wrote:
 ...
 
  +static int mt9m032_setup_pll(struct mt9m032 *sensor)
  +{
  +   static const struct aptina_pll_limits limits = {
  +   .ext_clock_min = 800,
  +   .ext_clock_max = 1650,
  +   .int_clock_min = 200,
  +   .int_clock_max = 2400,
  +   .out_clock_min = 32200,
  +   .out_clock_max = 69300,
  +   .pix_clock_max = 9900,
  +   .n_min = 1,
  +   .n_max = 64,
  +   .m_min = 16,
  +   .m_max = 255,
  +   .p1_min = 1,
  +   .p1_max = 128,
  +   };
  +
  +   struct i2c_client *client = v4l2_get_subdevdata(sensor-subdev);
  +   struct mt9m032_platform_data *pdata = sensor-pdata;
  +   struct aptina_pll pll;
  +   int ret;
  +
  +   pll.ext_clock = pdata-ext_clock;
  +   pll.pix_clock = pdata-pix_clock;
  +
  +   ret = aptina_pll_calculate(client-dev, limits, pll);
  +   if (ret  0)
  +   return ret;
  +
  +   sensor-pix_clock = pll.pix_clock;
 
 I wouldn't expect aptina_pll_calculate() to change the supplied pixel
 clock. I'd consider it a bug if it does that. So you could use the pixel
 clock from platform data equally well.

But does it make a difference ? :-) Taking the value from pll.pix_clock seems 
more logical to me.

  +   ret = mt9m032_write(client, MT9M032_PLL_CONFIG1,
  +   (pll.m  MT9M032_PLL_CONFIG1_MUL_SHIFT)
  +   | (pll.p1 - 1));
  +   if (!ret)
  +   ret = mt9m032_write(client, MT9P031_PLL_CONFIG2, pll.n - 1);
  +   if (!ret)
  +   ret = mt9m032_write(client, MT9P031_PLL_CONTROL,
  +   MT9P031_PLL_CONTROL_PWRON |
  +   MT9P031_PLL_CONTROL_USEPLL);
  +   if (!ret)   /* more reserved, Continuous, Master Mode */
  +   ret = mt9m032_write(client, MT9M032_READ_MODE1, 0x8006);
  +   if (!ret)   /* Set 14-bit mode, select 7 divider */
  +   ret = mt9m032_write(client, MT9M032_FORMATTER1, 0x111e);
  +
  +   return ret;
  +}
 
 ...
 
  +static int mt9m032_set_pad_format(struct v4l2_subdev *subdev,
  + struct v4l2_subdev_fh *fh,
  + struct v4l2_subdev_format *fmt)
  +{
  +   struct mt9m032 *sensor = to_mt9m032(subdev);
  +   int ret;
  +
  +   mutex_lock(sensor-lock);
  +
  +   if (sensor-streaming  fmt-which == V4L2_SUBDEV_FORMAT_ACTIVE) {
  +   ret = -EBUSY;
  +   goto done;
  +   }
  +
  +   /* Scaling is not supported, the format is thus fixed. */
  +   ret = mt9m032_get_pad_format(subdev, fh, fmt);
  +
  +done:
  +   mutex_lock(sensor-lock);
  +   return ret;
  +}
  +
  +static int mt9m032_get_crop(struct v4l2_subdev *subdev,
  +   struct v4l2_subdev_fh *fh,
  +   struct v4l2_subdev_crop *crop)
  +{
  +   struct mt9m032 *sensor = to_mt9m032(subdev);
  +
  +   mutex_lock(sensor-lock);
  +   crop-rect = *__mt9m032_get_pad_crop(sensor, fh, crop-which);
  +   mutex_unlock(sensor-lock);
  +
  +   return 0;
  +}
 
 Shouldn't these two be renamed --- you've got pad in set/get fmt names
 as well.

Done.

  +static int mt9m032_set_crop(struct v4l2_subdev *subdev,
  +   struct v4l2_subdev_fh *fh,
  +   struct v4l2_subdev_crop *crop)
  +{
  +   struct mt9m032 *sensor = to_mt9m032(subdev);
  +   struct v4l2_mbus_framefmt *format;
  +   struct v4l2_rect *__crop;
  +   struct v4l2_rect rect;
  +   int ret = 0;
  +
  +   mutex_lock(sensor-lock);
  +
  +   if (sensor-streaming  crop-which == V4L2_SUBDEV_FORMAT_ACTIVE) {
  +   ret = -EBUSY;
  +   goto done;
  +   }
  +
  +   /* Clamp the crop rectangle boundaries and align them to a multiple 
of 2
  +* pixels to ensure a GRBG Bayer pattern.
  +*/
  +   rect.left = clamp(ALIGN(crop-rect.left, 2), 
MT9M032_COLUMN_START_MIN,
  + MT9M032_COLUMN_START_MAX);
  +   rect.top = clamp(ALIGN(crop-rect.top, 2), MT9M032_ROW_START_MIN,
  +MT9M032_ROW_START_MAX);
  +   rect.width = clamp(ALIGN(crop-rect.width, 2), 
MT9M032_COLUMN_SIZE_MIN,
  +  MT9M032_COLUMN_SIZE_MAX);
  +   rect.height = clamp(ALIGN(crop-rect.height, 2), 
MT9M032_ROW_SIZE_MIN,
  +   MT9M032_ROW_SIZE_MAX);
  +
  +   rect.width = min(rect.width, MT9M032_PIXEL_ARRAY_WIDTH - rect.left);
  +   rect.height = min(rect.height, MT9M032_PIXEL_ARRAY_HEIGHT - 
rect.top);
  +
  +   __crop = __mt9m032_get_pad_crop(sensor, fh, crop-which);
  +
  +   if (rect.width != __crop-width || rect.height != __crop-height) {
  +   /* Reset the output image size if the crop rectangle size has
  +* been modified.
  +*/
  +   format = __mt9m032_get_pad_format(sensor, fh,

[PATCH v5 1/1] v4l: Add driver for Micron MT9M032 camera sensor

2012-03-09 Thread Laurent Pinchart

From: Martin Hostettler mar...@neutronstar.dyndns.org

The MT9M032 is a parallel 1.6MP sensor from Micron controlled through I2C.

The driver creates a V4L2 subdevice. It currently supports cropping, gain,
exposure and v/h flipping controls in monochrome mode with an
external pixel clock.

Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
[Lots of clean up, fixes and enhancements]
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/Kconfig   |8 +
 drivers/media/video/Makefile  |1 +
 drivers/media/video/mt9m032.c |  863 +
 include/media/mt9m032.h   |   36 ++
 4 files changed, 908 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mt9m032.c
 create mode 100644 include/media/mt9m032.h

Resending the MT9P032 driver only, as the other patches in the set haven't
been modified since v4.

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 666836d..745e958 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -470,6 +470,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
 
+config VIDEO_MT9M032
+   tristate MT9M032 camera sensor support
+   depends on I2C  VIDEO_V4L2
+   select VIDEO_APTINA_PLL
+   ---help---
+ This driver supports MT9M032 camera sensors from Aptina, monochrome
+ models only.
+
 config VIDEO_MT9P031
tristate Aptina MT9P031 support
depends on I2C  VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index d1304e1..f6af1d3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -69,6 +69,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_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
 obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
 obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
diff --git a/drivers/media/video/mt9m032.c b/drivers/media/video/mt9m032.c
new file mode 100644
index 000..f2f6168
--- /dev/null
+++ b/drivers/media/video/mt9m032.c
@@ -0,0 +1,863 @@
+/*
+ * Driver for MT9M032 CMOS Image Sensor from Micron
+ *
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/math64.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/slab.h
+#include linux/v4l2-mediabus.h
+
+#include media/media-entity.h
+#include media/mt9m032.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+
+#include aptina-pll.h
+
+/*
+ * width and height include active boundary and black parts
+ *
+ * column0-  15 active boundry
+ * column   16-1455 image
+ * column 1456-1471 active boundry
+ * column 1472-1599 black
+ *
+ * row   0-  51 black
+ * row  53-  59 active boundry
+ * row  60-1139 image
+ * row1140-1147 active boundry
+ * row1148-1151 black
+ */
+
+#define MT9M032_PIXEL_ARRAY_WIDTH  1600
+#define MT9M032_PIXEL_ARRAY_HEIGHT 1152
+
+#define MT9M032_CHIP_VERSION   0x00
+#defineMT9M032_CHIP_VERSION_VALUE  0x1402
+#define MT9M032_ROW_START  0x01
+#defineMT9M032_ROW_START_MIN   0
+#defineMT9M032_ROW_START_MAX   1152
+#defineMT9M032_ROW_START_DEF   60
+#define MT9M032_COLUMN_START   0x02
+#defineMT9M032_COLUMN_START_MIN0
+#defineMT9M032_COLUMN_START_MAX1600
+#defineMT9M032_COLUMN_START_DEF16
+#define MT9M032_ROW_SIZE   0x03
+#defineMT9M032_ROW_SIZE_MIN32
+#defineMT9M032_ROW_SIZE_MAX1152
+#defineMT9M032_ROW_SIZE_DEF

[PATCH v5.3 25/35] omap3isp: Collect entities that are part of the pipeline

2012-03-09 Thread Sakari Ailus

Collect entities which are part of the pipeline into a single bit mask.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
since last version:

- state is set in isp_video_streamon() rather than
  isp_video_get_graph_data().
- Get information from all entities which was broken by the previous
  version.

 drivers/media/video/omap3isp/ispvideo.c |   57 +-
 drivers/media/video/omap3isp/ispvideo.h |2 +
 2 files changed, 34 insertions(+), 25 deletions(-)

diff --git a/drivers/media/video/omap3isp/ispvideo.c 
b/drivers/media/video/omap3isp/ispvideo.c
index d34f690..d8a5250 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -255,8 +255,8 @@ isp_video_remote_subdev(struct isp_video *video, u32 *pad)
 }
 
 /* Return a pointer to the ISP video instance at the far end of the pipeline. 
*/
-static struct isp_video *
-isp_video_far_end(struct isp_video *video)
+static int isp_video_get_graph_data(struct isp_video *video,
+   struct isp_pipeline *pipe)
 {
struct media_entity_graph graph;
struct media_entity *entity = video-video.entity;
@@ -267,21 +267,38 @@ isp_video_far_end(struct isp_video *video)
media_entity_graph_walk_start(graph, entity);
 
while ((entity = media_entity_graph_walk_next(graph))) {
+   struct isp_video *__video;
+
+   pipe-entities |= 1  entity-id;
+
+   if (far_end != NULL)
+   continue;
+
if (entity == video-video.entity)
continue;
 
if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE)
continue;
 
-   far_end = to_isp_video(media_entity_to_video_device(entity));
-   if (far_end-type != video-type)
-   break;
-
-   far_end = NULL;
+   __video = to_isp_video(media_entity_to_video_device(entity));
+   if (__video-type != video-type)
+   far_end = __video;
}
 
mutex_unlock(mdev-graph_mutex);
-   return far_end;
+
+   if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+   pipe-input = far_end;
+   pipe-output = video;
+   } else {
+   if (far_end == NULL)
+   return -EPIPE;
+
+   pipe-input = video;
+   pipe-output = far_end;
+   }
+
+   return 0;
 }
 
 /*
@@ -972,7 +989,6 @@ isp_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
struct isp_video *video = video_drvdata(file);
enum isp_pipeline_state state;
struct isp_pipeline *pipe;
-   struct isp_video *far_end;
unsigned long flags;
int ret;
 
@@ -992,6 +1008,8 @@ isp_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
pipe = video-video.entity.pipe
 ? to_isp_pipeline(video-video.entity) : video-pipe;
 
+   pipe-entities = 0;
+
if (video-isp-pdata-set_constraints)
video-isp-pdata-set_constraints(video-isp, true);
pipe-l3_ick = clk_get_rate(video-isp-clock[ISP_CLK_L3_ICK]);
@@ -1011,25 +1029,14 @@ isp_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
video-bpl_padding = ret;
video-bpl_value = vfh-format.fmt.pix.bytesperline;
 
-   /* Find the ISP video node connected at the far end of the pipeline and
-* update the pipeline.
-*/
-   far_end = isp_video_far_end(video);
+   ret = isp_video_get_graph_data(video, pipe);
+   if (ret  0)
+   goto err_check_format;
 
-   if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+   if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
state = ISP_PIPELINE_STREAM_OUTPUT | ISP_PIPELINE_IDLE_OUTPUT;
-   pipe-input = far_end;
-   pipe-output = video;
-   } else {
-   if (far_end == NULL) {
-   ret = -EPIPE;
-   goto err_check_format;
-   }
-
+   else
state = ISP_PIPELINE_STREAM_INPUT | ISP_PIPELINE_IDLE_INPUT;
-   pipe-input = video;
-   pipe-output = far_end;
-   }
 
/* Validate the pipeline and update its state. */
ret = isp_video_validate_pipeline(pipe);
diff --git a/drivers/media/video/omap3isp/ispvideo.h 
b/drivers/media/video/omap3isp/ispvideo.h
index d91bdb9..c9187cb 100644
--- a/drivers/media/video/omap3isp/ispvideo.h
+++ b/drivers/media/video/omap3isp/ispvideo.h
@@ -88,6 +88,7 @@ enum isp_pipeline_state {
 /*
  * struct isp_pipeline - An ISP hardware pipeline
  * @error: A hardware error occurred during capture
+ * @entities: Bitmask of entities in the pipeline (indexed by entity ID)
  */
 struct isp_pipeline {
struct media_pipeline pipe;
@@ -96,6 +97,7 @@ struct isp_pipeline {
enum isp_pipeline_stream_state stream_state;

Re: [PATCH v5.3 25/35] omap3isp: Collect entities that are part of the pipeline

2012-03-09 Thread Laurent Pinchart

Hi Sakari,

Thanks for the patch.

On Friday 09 March 2012 22:31:25 Sakari Ailus wrote:
 Collect entities which are part of the pipeline into a single bit mask.
 
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] media_build: add module_driver and module_i2c_driver macros to compat.h

2012-03-09 Thread Gianluca Gennari

This patch eliminates a lot of warnings like this on old kernels:

media_build/v4l/au8522_decoder.c:842: warning: data definition has no type or 
storage class
media_build/v4l/au8522_decoder.c:842: warning: type defaults to 'int' in 
declaration of 'module_i2c_driver'
media_build/v4l/au8522_decoder.c:842: warning: parameter names (without types) 
in function declaration
media_build/v4l/au8522_decoder.c:832: warning: 'au8522_driver' defined but not 
used

Tested with 2.6.32 and 3.3-rc6 without problems.

Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
 v4l/compat.h |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/v4l/compat.h b/v4l/compat.h
index 62710c9..acc105c 100644
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -898,4 +898,24 @@ module_exit(plat_mod_exit);
 #define DMA_MEM_TO_DEV DMA_TO_DEVICE
 #endif
 
+#ifndef module_driver
+#define module_driver(__driver, __register, __unregister) \
+static int __init __driver##_init(void) \
+{ \
+   return __register((__driver)); \
+} \
+module_init(__driver##_init); \
+static void __exit __driver##_exit(void) \
+{ \
+   __unregister((__driver)); \
+} \
+module_exit(__driver##_exit);
+#endif
+
+#ifndef module_i2c_driver
+#define module_i2c_driver(__i2c_driver) \
+   module_driver(__i2c_driver, i2c_add_driver, \
+   i2c_del_driver)
+#endif
+
 #endif /*  _COMPAT_H */
-- 
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 3/3] wl128x: Add sysfs based support for FM features

2012-03-09 Thread halli manjunatha

On Fri, Mar 9, 2012 at 2:29 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 On Wednesday, March 07, 2012 22:42:05 halli manjunatha wrote:
 On Mon, Mar 5, 2012 at 10:24 AM, halli manjunatha hallima...@gmail.com 
 wrote:
  On Fri, Mar 2, 2012 at 3:22 AM, Hans Verkuil hverk...@xs4all.nl wrote:
  On Wednesday, February 29, 2012 18:19:27 halli manjunatha wrote:
  On Wed, Feb 29, 2012 at 5:25 AM, Hans Verkuil hverk...@xs4all.nl wrote:
   On Tuesday, February 28, 2012 23:52:21 halli manjunatha wrote:
   On Tue, Feb 28, 2012 at 4:05 AM, Hans Verkuil hverk...@xs4all.nl 
   wrote:
On Monday, February 27, 2012 17:29:18 halli manjunatha wrote:
Hi Hans,
   
Agreed I don't mind to create new controls for below things
   
1) FM RX Band selection (US/Europe, Japan and Russian bands)
2) FM RX RDS AF turn ON/OFF
3) FM RX RSSI level set/get
4) FM TX Alternate Frequency set/get
5) FM RX De-Emphasis mode set/get
   
However, previously you have suggested me to hide few controls 
(like
band selection) from the user but few of our application wanted
controls like above and that is why I have created the sysfs 
entries.
   
Please suggest me how can I move forward with new controls or with 
sysfs?
   
The first question is which of these controls are general to FM 
receivers or
transmitters, and which are specific to this chipset. The chipset 
specific
controls should be private controls (look at 
V4L2_CID_MPEG_CX2341X_BASE in
videodev2.h how those are defined). The others should be defined as 
new
controls of the FM_TX class or the FM_RX class. The FM_RX class 
should be
defined as a new class as it doesn't exist at the moment. Don't 
forget to
document these controls clearly.
   
With regards to the band selection: I remember that there was a 
discussion,
but not the details. Do you have a link to that discussion? I can't 
find it
(at least not quickly :-) ).
  
   Below features are generic to all FM receivers so we can add new CID's
   for below features
   1) FM RX RDS AF turn ON/OFF
   2) FM TX Alternate Frequency set/get
  
   About other 3 features its different issue,
       1) FM RX Band selection (US/Europe, Japan and Russian bands)
       2) FM RX RSSI level set/get
       3) FM RX De-Emphasis mode set/get
  
   All these 3 features are generic to any FM receiver, only question is
   does all FM receivers wants to expose these controls to application
   writer?
  
   Good question, and there is no good answer at the moment. See e.g. this
   IRC discussion:
  
   http://www.spinics.net/lists/linux-media/msg44023.html
  
   In the absence of a good solution to this problem I am inclined to make
   these controls driver specific but marked experimental. The 
   experimental
   tag allows us to eventually make it a generic control without too much
   hassle.
 
  Agreed, I will make them driver specific and mark them as experimental.
 
  
   Example Band selection, every FM receiver at the minimum supports both
   Europe and Japan band, now the question is should we add a CID to
   switch between these two bands?
  
   If we decide to add a band selection control, then that would be a menu
   control (since there are up to three bands) and it would only be 
   implemented
   by drivers that need it.
  
   What I am still not clear on is *why* you would want this control. What
   is the reason your customers want this? What does it allow you to do 
   that
   can't be done today?
 
  There are 2 reasons for this,
 
  First, our chip supports weather band, unlike other bands (Europe,
  Japan and Russian) user may wants to
  switch to weather band and wants to listen to weather report and again
  switches back to normal band.
 
  OK, that makes sense. Are the RX and TX independent with regards to
  band selection?
 
  Yes - RX and TX are independent of band selection
 
  Make sure that when the band is changed the rangelow and rangehigh values
  are also changed. If the current frequency is out of that range, then the
  frequency should be clamped to the closest value frequency. Although an
  alternative strategy might be to remember the last used frequency for each
  band. That might make more sense in the case of switching between a normal
  band and the weather band. We need to define and document which strategy
  should be used here.
 
  As of now when I switch to new band I just set the frequency to lowest
  of the new band.
  In this way user can seek and tune to what ever channel he wants.
 
 Hans,

 Which implementation you wants? start with the lowest of the new band
 or closer to the frequency of old band? do we need to remember the
 present frequency of the band before switching to new band?

 Please let me know your views.

 The initial frequency of each band is driver dependent. That's how drivers
 act at the moment, so we keep that.

 When switching bands it is best to keep the

Re: [PATCH v5 1/1] v4l: Add driver for Micron MT9M032 camera sensor

2012-03-09 Thread Sylwester Nawrocki

Hi Laurent,

I have a few minor comments, if you don't mind. :)

On 03/09/2012 09:21 PM, Laurent Pinchart wrote:
 From: Martin Hostettlermar...@neutronstar.dyndns.org
 
 The MT9M032 is a parallel 1.6MP sensor from Micron controlled through I2C.
 
 The driver creates a V4L2 subdevice. It currently supports cropping, gain,
 exposure and v/h flipping controls in monochrome mode with an
 external pixel clock.
 
 Signed-off-by: Martin Hostettlermar...@neutronstar.dyndns.org
 [Lots of clean up, fixes and enhancements]
 Signed-off-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com
 ---
   drivers/media/video/Kconfig   |8 +
   drivers/media/video/Makefile  |1 +
   drivers/media/video/mt9m032.c |  863 
 +
   include/media/mt9m032.h   |   36 ++
   4 files changed, 908 insertions(+), 0 deletions(-)
   create mode 100644 drivers/media/video/mt9m032.c
   create mode 100644 include/media/mt9m032.h
 
 Resending the MT9P032 driver only, as the other patches in the set haven't
 been modified since v4.
 
 diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
 index 666836d..745e958 100644
 --- a/drivers/media/video/Kconfig
 +++ b/drivers/media/video/Kconfig
 @@ -470,6 +470,14 @@ config VIDEO_OV7670
 OV7670 VGA camera.  It currently only works with the M88ALP01
 controller.
 
 +config VIDEO_MT9M032
 + tristate MT9M032 camera sensor support
 + depends on I2C  VIDEO_V4L2
 + select VIDEO_APTINA_PLL
 + ---help---
 +   This driver supports MT9M032 camera sensors from Aptina, monochrome
 +   models only.
 +
   config VIDEO_MT9P031
   tristate Aptina MT9P031 support
   depends on I2C  VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
 index d1304e1..f6af1d3 100644
 --- a/drivers/media/video/Makefile
 +++ b/drivers/media/video/Makefile
 @@ -69,6 +69,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_MT9M032) += mt9m032.o
   obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
   obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
   obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
 diff --git a/drivers/media/video/mt9m032.c b/drivers/media/video/mt9m032.c
 new file mode 100644
 index 000..f2f6168
 --- /dev/null
 +++ b/drivers/media/video/mt9m032.c
 @@ -0,0 +1,863 @@
 +/*
 + * Driver for MT9M032 CMOS Image Sensor from Micron
 + *
 + * Copyright (C) 2010-2011 Lund Engineering
 + * Contact: Gil Lundgwl...@lundeng.com
 + * Author: Martin Hostettlermar...@neutronstar.dyndns.org
 + *
 + * 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.
 + *
 + * This program is distributed in the hope that it will be useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 + * 02110-1301 USA
 + */
 +
 +#includelinux/delay.h
 +#includelinux/i2c.h
 +#includelinux/init.h
 +#includelinux/kernel.h
 +#includelinux/math64.h
 +#includelinux/module.h
 +#includelinux/mutex.h
 +#includelinux/slab.h
 +#includelinux/v4l2-mediabus.h
 +
 +#includemedia/media-entity.h
 +#includemedia/mt9m032.h
 +#includemedia/v4l2-ctrls.h
 +#includemedia/v4l2-device.h
 +#includemedia/v4l2-subdev.h
 +
 +#include aptina-pll.h
 +
 +/*
 + * width and height include active boundary and black parts
 + *
 + * column0-  15 active boundry
 + * column   16-1455 image
 + * column 1456-1471 active boundry
 + * column 1472-1599 black
 + *
 + * row   0-  51 black
 + * row  53-  59 active boundry
 + * row  60-1139 image
 + * row1140-1147 active boundry

s/boundry/boundary

 + * row1148-1151 black
 + */
 +
 +#define MT9M032_PIXEL_ARRAY_WIDTH1600
 +#define MT9M032_PIXEL_ARRAY_HEIGHT   1152
 +
 +#define MT9M032_CHIP_VERSION 0x00
 +#define  MT9M032_CHIP_VERSION_VALUE  0x1402
 +#define MT9M032_ROW_START0x01
 +#define  MT9M032_ROW_START_MIN   0
 +#define  MT9M032_ROW_START_MAX   1152
 +#define  MT9M032_ROW_START_DEF   60
 +#define MT9M032_COLUMN_START 0x02
 +#define  MT9M032_COLUMN_START_MIN0
 +#define  MT9M032_COLUMN_START_MAX1600
 +#define  MT9M032_COLUMN_START_DEF16
 +#define MT9M032_ROW_SIZE

RE: [PATCH] omap_vout: Set DSS overlay_info only if paddr is non zero

Re: [PATCH 3/3] wl128x: Add sysfs based support for FM features

Re: Lockup on second streamon with omap3-isp

[PATCH] V4L: Improve the selection API documentation

[PATCH] omap_vout: Fix DMA transaction error issue when rotation is enabled

[PATCH] omap_vout: Fix the build warning and section miss-match warning

[PATCH] video: Kconfig: Select VIDEOBUF2_DMA_CONTIG for VIDEO_MX2

[PATCH] fix backport patch v2.6.32_kfifo

[PATCH] disable IR_GPIO_CIR module for kernels older than 2.6.35

Re: [PATCH v3 5/5] v4l: Add driver for Micron MT9M032 camera sensor

Re: [PATCH] disable IR_GPIO_CIR module for kernels older than 2.6.35

Re: [PATCH] fix backport patch v2.6.32_kfifo

[PATCH] s5p-csis: Fix compilation with PM_SLEEP disabled

Re: Lockup on second streamon with omap3-isp

Re: Lockup on second streamon with omap3-isp

Re: [PATCH] fix backport patch v2.6.32_kfifo

[PATCH v4 0/5] MT9M032 and MT9P031 sensor patches

[PATCH v4 1/5] mt9p031: Remove duplicate media/v4l2-subdev.h include

[PATCH v4 4/5] mt9p031: Use generic PLL setup code

[PATCH v4 3/5] v4l: Aptina-style sensor PLL support

[PATCH v4 5/5] v4l: Add driver for Micron MT9M032 camera sensor

[PATCH v4 2/5] mt9p031: Remove unused xskip and yskip fields in struct mt9p031

Re: Lockup on second streamon with omap3-isp

[PATCH 25/35] omap3isp: Collect entities that are part of the pipeline

cron job: media_tree daily build: ERRORS

Re: [PATCH v4 5/5] v4l: Add driver for Micron MT9M032 camera sensor

Re: [PATCH v4 5/5] v4l: Add driver for Micron MT9M032 camera sensor

[PATCH v5 1/1] v4l: Add driver for Micron MT9M032 camera sensor

[PATCH v5.3 25/35] omap3isp: Collect entities that are part of the pipeline

Re: [PATCH v5.3 25/35] omap3isp: Collect entities that are part of the pipeline

[PATCH] media_build: add module_driver and module_i2c_driver macros to compat.h

Re: [PATCH 3/3] wl128x: Add sysfs based support for FM features

Re: [PATCH v5 1/1] v4l: Add driver for Micron MT9M032 camera sensor

33 matches

Site Navigation

Mail list logo

Footer information