Re: Using MT9P031 digital sensor

[Laurent Pinchart]

Hi Joshua,

On Sunday 25 March 2012 23:13:02 Joshua Hintze wrote:
 Alright I made some progress on this.
 
 I can access the Mt9p031 registers that are exposed using a command such as
 
 ./yavta -l /dev/v4l-subdev8 to list the available controls. Then I can
 set the exposure and analog gain with
 ./yavta --set-control '0x00980911 1500' /dev/v4l-subdev8   --- This
 seems to give the desired effect.
 
 Note that ./yavta -w (short option for --set-control) gives a seg
 fault for me. Possible bug in yavta??

That's strange, I use -w all the time and haven't noticed any segfault. Can 
you compile yavta with debugging information and provide some context ?

 Now I'm working on fixing the white balance. In my office the incandescent
 light bulbs give off a yellowish tint late at night. I've been digging
 through the omap3isp code to figure out how to enable the automatic white
 balance. I was able to find the private IOCTLs for the previewer and I was
 able to use VIDIOC_OMAP3ISP_PRV_CFG. Using this IOCTL I adjusted the
 OMAP3ISP_PREV_WB, OMAP3ISP_PREV_BLKADJ, and OMAP3ISP_PREV_RGB2RGB.

 Since I wasn't sure where to start on adjusting these values I just set them
 all to the TRM's default register values. However when I did so a strange
 thing occurred. What I saw was all the colors went to a decent color. I'm
 curious if anybody can shed some light on the best way to get a high quality
 image. Ideally if I could just set a bit for auto white balance and auto
 exposure that could be good too.

The ISP doesn't implement automatic white balance. It can apply white 
balancing (as well as other related processing), but computing values for 
those parameters needs to be performed in userspace. The ISP statistics engine 
engine can help speeding up the process, but the AEWB algorithm must be 
implemented in your application.

-- 
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

[Q] What sensor does s5K6aa driver support?

[javier Martin]

Hi,
the following driver claims to support S5K6AAFX Samsung sensor:
http://lxr.linux.no/#linux+v3.3/drivers/media/video/s5k6aa.c

However, we've been informed that this reference is marked as EOL. Has
anyone tested this driver with anothe sensor compatible with S5K6AAFX
that can be used as a replacement?

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: libv4l: add Lenovo Thinkpad Edge E325 to upside down devices table

[Marien Zwart]

Hi,

On zo, 2012-03-25 at 23:54 +0200, Gregor Jasny wrote:
 I assume you're a Debian user: libv4l-0.8.6-2 got just uploaded to
 Debian Sid. In case you're on Ubuntu, the libv4l/stable PPA will pick
 up the patch with the next nightly build.
 
 It would be great if you could test the updated package.

I can confirm libv4l-0 and libv4lconvert0 from Debian testing (0.8.6-1)
give me an upside-down image in cheese, which is fixed by installing
libv4l-0 and libv4lconvert0 from unstable (0.8.6-2) on my testing
system.

Thanks for fixing this so quickly!

-- 
Marien.


signature.asc
Description: This is a digitally signed message part

[GIT PULL]: dma-buf updates for 3.4

[Sumit Semwal]

Hi Linus,

Could you please pull the dma-buf updates for 3.4? This includes the
following key items:

- kernel cpu access support,
- flag-passing to dma_buf_fd,
- relevant Documentation updates, and
- some minor cleanups and fixes.

These changes are needed for the drm prime/dma-buf interface code that
Dave Airlie plans to submit in this merge window.

Thanks, and best regards,
~Sumit.

The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7:

  Linux 3.3 (2012-03-18 16:15:34 -0700)

are available in the git repository at:
  git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git for-linus-3.4

Daniel Vetter (3):
  dma-buf: don't hold the mutex around map/unmap calls
  dma-buf: add support for kernel cpu access
  dma_buf: Add documentation for the new cpu access support

Dave Airlie (1):
  dma-buf: pass flags into dma_buf_fd.

Laurent Pinchart (4):
  dma-buf: Constify ops argument to dma_buf_export()
  dma-buf: Remove unneeded sanity checks
  dma-buf: Return error instead of using a goto statement when possible
  dma-buf: Move code out of mutex-protected section in dma_buf_attach()

Rob Clark (2):
  dma-buf: add get_dma_buf()
  dma-buf: document fd flags and O_CLOEXEC requirement

Sumit Semwal (2):
  dma-buf: add dma_data_direction to unmap dma_buf_op
  dma-buf: correct dummy function declarations.

 Documentation/dma-buf-sharing.txt |  120 ++-
 drivers/base/dma-buf.c|  165 +++--
 include/linux/dma-buf.h   |   97 +++--
 3 files changed, 345 insertions(+), 37 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] media: tvp5150: Fix mbus format to UYUV instead of YUYV.

[Javier Martin]

[PATCH 1/3] media: tvp5150: Fix mbus format.
[PATCH 2/3] media: mx2_camera: Fix mbus format handling.
[PATCH 3/3] i.MX27: visstrim_m10: Remove use of MX2_CAMERA_SWAP16.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] media: tvp5150: Fix mbus format.

[Javier Martin]

According to p.14 fig 3-3 of the datasheet (SLES098A)
this decoder transmits data in UYVY format.

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 drivers/media/video/tvp5150.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index e292c46..30c88e0 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -821,7 +821,7 @@ static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, 
unsigned index,
if (index)
return -EINVAL;
 
-   *code = V4L2_MBUS_FMT_YUYV8_2X8;
+   *code = V4L2_MBUS_FMT_UYVY8_2X8;
return 0;
 }
 
@@ -845,7 +845,7 @@ static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
f-width = decoder-rect.width;
f-height = decoder-rect.height;
 
-   f-code = V4L2_MBUS_FMT_YUYV8_2X8;
+   f-code = V4L2_MBUS_FMT_UYVY8_2X8;
f-field = V4L2_FIELD_SEQ_TB;
f-colorspace = V4L2_COLORSPACE_SMPTE170M;
 
-- 
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 2/3] media: mx2_camera: Fix mbus format handling.

[Javier Martin]

Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags
so that the driver can negotiate with the attached sensor
whether the mbus format needs convertion from UYUV to YUYV
or not.

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 arch/arm/plat-mxc/include/mach/mx2_cam.h |2 -
 drivers/media/video/mx2_camera.c |   52 +++---
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h 
b/arch/arm/plat-mxc/include/mach/mx2_cam.h
index 3c080a3..7ded6f1 100644
--- a/arch/arm/plat-mxc/include/mach/mx2_cam.h
+++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
@@ -23,7 +23,6 @@
 #ifndef __MACH_MX2_CAM_H_
 #define __MACH_MX2_CAM_H_
 
-#define MX2_CAMERA_SWAP16  (1  0)
 #define MX2_CAMERA_EXT_VSYNC   (1  1)
 #define MX2_CAMERA_CCIR(1  2)
 #define MX2_CAMERA_CCIR_INTERLACE  (1  3)
@@ -31,7 +30,6 @@
 #define MX2_CAMERA_GATED_CLOCK (1  5)
 #define MX2_CAMERA_INV_DATA(1  6)
 #define MX2_CAMERA_PCLK_SAMPLE_RISING  (1  7)
-#define MX2_CAMERA_PACK_DIR_MSB(1  8)
 
 /**
  * struct mx2_camera_platform_data - optional platform data for mx2_camera
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 8df624f..9274a53 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -348,6 +348,19 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
PRP_INTR_CH2OVF,
}
},
+   {
+   .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+   .out_fmt= V4L2_PIX_FMT_YUV420,
+   .cfg= {
+   .channel= 2,
+   .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+   .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
+   .src_pixel  = 0x22000888, /* YUV422 (YUYV) */
+   .irq_flags  = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
+   PRP_INTR_CH2FC | PRP_INTR_LBOVF |
+   PRP_INTR_CH2OVF,
+   }
+   },
 };
 
 static struct mx2_fmt_cfg *mx27_emma_prp_get_format(
@@ -990,6 +1003,7 @@ static int mx2_camera_set_bus_param(struct 
soc_camera_device *icd,
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct mx2_camera_dev *pcdev = ici-priv;
struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+   const struct soc_camera_format_xlate *xlate;
unsigned long common_flags;
int ret;
int bytesperline;
@@ -1034,14 +1048,31 @@ static int mx2_camera_set_bus_param(struct 
soc_camera_device *icd,
return ret;
}
 
+   xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+   if (!xlate) {
+   dev_warn(icd-parent, Format %x not found\n, pixfmt);
+   return -EINVAL;
+   }
+
+   if (xlate-code == V4L2_MBUS_FMT_YUYV8_2X8) {
+   csicr1 |= CSICR1_PACK_DIR;
+   csicr1 = ~CSICR1_SWAP16_EN;
+   dev_dbg(icd-parent, already yuyv format, don't convert\n);
+   } else if (xlate-code == V4L2_MBUS_FMT_UYVY8_2X8) {
+   csicr1 = ~CSICR1_PACK_DIR;
+   csicr1 |= CSICR1_SWAP16_EN;
+   dev_dbg(icd-parent, convert uyvy mbus format into yuyv\n);
+   } else {
+   dev_warn(icd-parent, mbus format not supported\n);
+   return -EINVAL;
+   }
+
if (common_flags  V4L2_MBUS_PCLK_SAMPLE_RISING)
csicr1 |= CSICR1_REDGE;
if (common_flags  V4L2_MBUS_VSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_SOF_POL;
if (common_flags  V4L2_MBUS_HSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_HSYNC_POL;
-   if (pcdev-platform_flags  MX2_CAMERA_SWAP16)
-   csicr1 |= CSICR1_SWAP16_EN;
if (pcdev-platform_flags  MX2_CAMERA_EXT_VSYNC)
csicr1 |= CSICR1_EXT_VSYNC;
if (pcdev-platform_flags  MX2_CAMERA_CCIR)
@@ -1052,8 +1083,6 @@ static int mx2_camera_set_bus_param(struct 
soc_camera_device *icd,
csicr1 |= CSICR1_GCLK_MODE;
if (pcdev-platform_flags  MX2_CAMERA_INV_DATA)
csicr1 |= CSICR1_INV_DATA;
-   if (pcdev-platform_flags  MX2_CAMERA_PACK_DIR_MSB)
-   csicr1 |= CSICR1_PACK_DIR;
 
pcdev-csicr1 = csicr1;
 
@@ -1128,7 +1157,8 @@ static int mx2_camera_get_formats(struct 
soc_camera_device *icd,
return 0;
}
 
-   if (code == V4L2_MBUS_FMT_YUYV8_2X8) {
+   if (code == V4L2_MBUS_FMT_YUYV8_2X8 ||
+   code == V4L2_MBUS_FMT_UYVY8_2X8) {
formats++;
if (xlate) {
/*
@@ -1144,6 +1174,18 @@ static int mx2_camera_get_formats(struct 
soc_camera_device *icd,
}
}
 
+   if (code == 

[PATCH 3/3] i.MX27: visstrim_m10: Remove use of MX2_CAMERA_SWAP16.

[Javier Martin]

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 arch/arm/mach-imx/mach-imx27_visstrim_m10.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c 
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 3128cfe..4db00c6 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -164,7 +164,7 @@ static struct platform_device visstrim_tvp5150 = {
 
 
 static struct mx2_camera_platform_data visstrim_camera = {
-   .flags = MX2_CAMERA_CCIR | MX2_CAMERA_CCIR_INTERLACE | 
MX2_CAMERA_SWAP16 | MX2_CAMERA_PCLK_SAMPLE_RISING,
+   .flags = MX2_CAMERA_CCIR | MX2_CAMERA_CCIR_INTERLACE | 
MX2_CAMERA_PCLK_SAMPLE_RISING,
.clk = 10,
 };
 
-- 
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] i.MX27: visstrim_m10: Remove use of MX2_CAMERA_SWAP16.

[javier Martin]

On 26 March 2012 14:10, Baruch Siach bar...@tkos.co.il wrote:
 Hi Javier,

 On Mon, Mar 26, 2012 at 01:20:04PM +0200, Javier Martin wrote:

 Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
 ---
  arch/arm/mach-imx/mach-imx27_visstrim_m10.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c 
 b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
 index 3128cfe..4db00c6 100644
 --- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
 +++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
 @@ -164,7 +164,7 @@ static struct platform_device visstrim_tvp5150 = {


  static struct mx2_camera_platform_data visstrim_camera = {
 -     .flags = MX2_CAMERA_CCIR | MX2_CAMERA_CCIR_INTERLACE | 
 MX2_CAMERA_SWAP16 | MX2_CAMERA_PCLK_SAMPLE_RISING,
 +     .flags = MX2_CAMERA_CCIR | MX2_CAMERA_CCIR_INTERLACE | 
 MX2_CAMERA_PCLK_SAMPLE_RISING,
       .clk = 10,
  };

 The order of the last two patches in this series should be switched to
 preserve bisectability.

 baruch

You are right.
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 3/3] i.MX27: visstrim_m10: Remove use of MX2_CAMERA_SWAP16.

[Baruch Siach]

Hi Javier,

On Mon, Mar 26, 2012 at 01:20:04PM +0200, Javier Martin wrote:
 
 Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
 ---
  arch/arm/mach-imx/mach-imx27_visstrim_m10.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c 
 b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
 index 3128cfe..4db00c6 100644
 --- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
 +++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
 @@ -164,7 +164,7 @@ static struct platform_device visstrim_tvp5150 = {
  
  
  static struct mx2_camera_platform_data visstrim_camera = {
 - .flags = MX2_CAMERA_CCIR | MX2_CAMERA_CCIR_INTERLACE | 
 MX2_CAMERA_SWAP16 | MX2_CAMERA_PCLK_SAMPLE_RISING,
 + .flags = MX2_CAMERA_CCIR | MX2_CAMERA_CCIR_INTERLACE | 
 MX2_CAMERA_PCLK_SAMPLE_RISING,
   .clk = 10,
  };

The order of the last two patches in this series should be switched to 
preserve bisectability.

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] em28xx: Export em28xx_[read,write]_reg functions as SYMBOL_GPL

[Ezequiel Garcia]

Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/video/em28xx/em28xx-core.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-core.c 
b/drivers/media/video/em28xx/em28xx-core.c
index 53a9fb9..237d44f 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -139,6 +139,7 @@ int em28xx_read_reg(struct em28xx *dev, u16 reg)
 {
return em28xx_read_reg_req(dev, USB_REQ_GET_STATUS, reg);
 }
+EXPORT_SYMBOL_GPL(em28xx_read_reg);
 
 /*
  * em28xx_write_regs_req()
@@ -205,6 +206,7 @@ int em28xx_write_regs(struct em28xx *dev, u16 reg, char 
*buf, int len)
 
return rc;
 }
+EXPORT_SYMBOL_GPL(em28xx_write_regs);
 
 /* Write a single register */
 int em28xx_write_reg(struct em28xx *dev, u16 reg, u8 val)
@@ -239,6 +241,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 
val,
 
return em28xx_write_regs(dev, reg, newval, 1);
 }
+EXPORT_SYMBOL_GPL(em28xx_write_reg_bits);
 
 /*
  * em28xx_is_ac97_ready()
-- 
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 2/5] em28xx: Move ir/rc related initialization to em28xx_ir_init()

[Ezequiel Garcia]

Moving this helps isolating em28xx_input and will help
converting it into a separate module.

Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/video/em28xx/em28xx-cards.c |   10 --
 drivers/media/video/em28xx/em28xx-i2c.c   |3 ---
 drivers/media/video/em28xx/em28xx-input.c |   11 +++
 3 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-cards.c 
b/drivers/media/video/em28xx/em28xx-cards.c
index ce1b60f..ba99e22 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2770,13 +2770,6 @@ void em28xx_card_setup(struct em28xx *dev)
break;
}
 
-#if defined(CONFIG_MODULES)  defined(MODULE)
-   if (dev-board.has_ir_i2c  !disable_ir)
-   request_module(ir-kbd-i2c);
-#endif
-   if (dev-board.has_snapshot_button)
-   em28xx_register_snapshot_button(dev);
-
if (dev-board.valid == EM28XX_BOARD_NOT_VALIDATED) {
em28xx_errdev(\n\n);
em28xx_errdev(The support for this board weren't 
@@ -2893,9 +2886,6 @@ static void flush_request_modules(struct em28xx *dev)
 */
 void em28xx_release_resources(struct em28xx *dev)
 {
-   if (dev-sbutton_input_dev)
-   em28xx_deregister_snapshot_button(dev);
-
if (dev-ir)
em28xx_ir_fini(dev);
 
diff --git a/drivers/media/video/em28xx/em28xx-i2c.c 
b/drivers/media/video/em28xx/em28xx-i2c.c
index 36f5a9b..91bf163 100644
--- a/drivers/media/video/em28xx/em28xx-i2c.c
+++ b/drivers/media/video/em28xx/em28xx-i2c.c
@@ -561,9 +561,6 @@ int em28xx_i2c_register(struct em28xx *dev)
if (i2c_scan)
em28xx_do_i2c_scan(dev);
 
-   /* Instantiate the IR receiver device, if present */
-   em28xx_register_i2c_ir(dev);
-
return 0;
 }
 
diff --git a/drivers/media/video/em28xx/em28xx-input.c 
b/drivers/media/video/em28xx/em28xx-input.c
index 2630b26..dd6e3f2 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -448,6 +448,15 @@ int em28xx_ir_init(struct em28xx *dev)
if (err)
goto err_out_stop;
 
+   em28xx_register_i2c_ir(dev);
+
+#if defined(CONFIG_MODULES)  defined(MODULE)
+   if (dev-board.has_ir_i2c)
+   request_module(ir-kbd-i2c);
+#endif
+   if (dev-board.has_snapshot_button)
+   em28xx_register_snapshot_button(dev);
+
return 0;
 
  err_out_stop:
@@ -462,6 +471,8 @@ int em28xx_ir_fini(struct em28xx *dev)
 {
struct em28xx_IR *ir = dev-ir;
 
+   em28xx_deregister_snapshot_button(dev);
+
/* skip detach on non attached boards */
if (!ir)
return 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 info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] em28xx: Move em28xx_register_i2c_ir() to em28xx-input.c

[Ezequiel Garcia]

This function is only used in em28xx-input.c so it
makes no sense to have it anywhere but in em28xx-input.c.

Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/video/em28xx/em28xx-cards.c |   48 -
 drivers/media/video/em28xx/em28xx-input.c |   44 ++
 2 files changed, 44 insertions(+), 48 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-cards.c 
b/drivers/media/video/em28xx/em28xx-cards.c
index ba99e22..1cc244c 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2582,54 +2582,6 @@ static int em28xx_hint_board(struct em28xx *dev)
return -1;
 }
 
-/* --- */
-void em28xx_register_i2c_ir(struct em28xx *dev)
-{
-   /* Leadtek winfast tv USBII deluxe can find a non working IR-device */
-   /* at address 0x18, so if that address is needed for another board in */
-   /* the future, please put it after 0x1f. */
-   struct i2c_board_info info;
-   const unsigned short addr_list[] = {
-0x1f, 0x30, 0x47, I2C_CLIENT_END
-   };
-
-   if (disable_ir)
-   return;
-
-   memset(info, 0, sizeof(struct i2c_board_info));
-   memset(dev-init_data, 0, sizeof(dev-init_data));
-   strlcpy(info.type, ir_video, I2C_NAME_SIZE);
-
-   /* detect  configure */
-   switch (dev-model) {
-   case EM2800_BOARD_TERRATEC_CINERGY_200:
-   case EM2820_BOARD_TERRATEC_CINERGY_250:
-   dev-init_data.ir_codes = RC_MAP_EM_TERRATEC;
-   dev-init_data.get_key = em28xx_get_key_terratec;
-   dev-init_data.name = i2c IR (EM28XX Terratec);
-   break;
-   case EM2820_BOARD_PINNACLE_USB_2:
-   dev-init_data.ir_codes = RC_MAP_PINNACLE_GREY;
-   dev-init_data.get_key = em28xx_get_key_pinnacle_usb_grey;
-   dev-init_data.name = i2c IR (EM28XX Pinnacle PCTV);
-   break;
-   case EM2820_BOARD_HAUPPAUGE_WINTV_USB_2:
-   dev-init_data.ir_codes = RC_MAP_HAUPPAUGE;
-   dev-init_data.get_key = em28xx_get_key_em_haup;
-   dev-init_data.name = i2c IR (EM2840 Hauppauge);
-   break;
-   case EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE:
-   dev-init_data.ir_codes = RC_MAP_WINFAST_USBII_DELUXE;
-   dev-init_data.get_key = em28xx_get_key_winfast_usbii_deluxe;
-   dev-init_data.name = i2c IR (EM2820 Winfast TV USBII Deluxe);
-   break;
-   }
-
-   if (dev-init_data.name)
-   info.platform_data = dev-init_data;
-   i2c_new_probed_device(dev-i2c_adap, info, addr_list, NULL);
-}
-
 void em28xx_card_setup(struct em28xx *dev)
 {
/*
diff --git a/drivers/media/video/em28xx/em28xx-input.c 
b/drivers/media/video/em28xx/em28xx-input.c
index dd6e3f2..0a58ba8 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -387,6 +387,50 @@ int em28xx_ir_change_protocol(struct rc_dev *rc_dev, u64 
rc_type)
return rc;
 }
 
+void em28xx_register_i2c_ir(struct em28xx *dev)
+{
+   /* Leadtek winfast tv USBII deluxe can find a non working IR-device */
+   /* at address 0x18, so if that address is needed for another board in */
+   /* the future, please put it after 0x1f. */
+   struct i2c_board_info info;
+   const unsigned short addr_list[] = {
+0x1f, 0x30, 0x47, I2C_CLIENT_END
+   };
+
+   memset(info, 0, sizeof(struct i2c_board_info));
+   memset(dev-init_data, 0, sizeof(dev-init_data));
+   strlcpy(info.type, ir_video, I2C_NAME_SIZE);
+
+   /* detect  configure */
+   switch (dev-model) {
+   case EM2800_BOARD_TERRATEC_CINERGY_200:
+   case EM2820_BOARD_TERRATEC_CINERGY_250:
+   dev-init_data.ir_codes = RC_MAP_EM_TERRATEC;
+   dev-init_data.get_key = em28xx_get_key_terratec;
+   dev-init_data.name = i2c IR (EM28XX Terratec);
+   break;
+   case EM2820_BOARD_PINNACLE_USB_2:
+   dev-init_data.ir_codes = RC_MAP_PINNACLE_GREY;
+   dev-init_data.get_key = em28xx_get_key_pinnacle_usb_grey;
+   dev-init_data.name = i2c IR (EM28XX Pinnacle PCTV);
+   break;
+   case EM2820_BOARD_HAUPPAUGE_WINTV_USB_2:
+   dev-init_data.ir_codes = RC_MAP_HAUPPAUGE;
+   dev-init_data.get_key = em28xx_get_key_em_haup;
+   dev-init_data.name = i2c IR (EM2840 Hauppauge);
+   break;
+   case EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE:
+   dev-init_data.ir_codes = RC_MAP_WINFAST_USBII_DELUXE;
+   dev-init_data.get_key = em28xx_get_key_winfast_usbii_deluxe;
+   dev-init_data.name = i2c IR (EM2820 Winfast TV USBII Deluxe);
+   break;
+   }
+
+   if (dev-init_data.name)
+ 

[PATCH 0/5] Make em28xx-input.c a separate module

[Ezequiel García]

Hi,

This patchset isolates em28xx-input code and turns it
into a module, as suggested by Mauro [1].

Contrary to my initial expectations, the patch produces
code that's actually cleaner and a slightly less spaghetti.

I've tried to make the whole change as clear as possible
by splitting it into several patches.
This was done to ease the maintainer job and also
in the hope that someone cares to review and provide feeback.

As I don't have em28xx hardware, I did virtually no test at all so :(

 drivers/media/video/em28xx/Kconfig|4 +-
 drivers/media/video/em28xx/Makefile   |5 +-
 drivers/media/video/em28xx/em28xx-cards.c |   66 +
 drivers/media/video/em28xx/em28xx-core.c  |3 +
 drivers/media/video/em28xx/em28xx-i2c.c   |3 -
 drivers/media/video/em28xx/em28xx-input.c |  250 +++--
 drivers/media/video/em28xx/em28xx.h   |   32 +
 7 files changed, 175 insertions(+), 188 deletions(-)

[1] http://www.spinics.net/lists/linux-media/msg45416.html

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

[PATCH 4/5] em28xx: Change scope of em28xx-input local functions to static

[Ezequiel Garcia]

This functions are no longer used from another file,
so they should be declared as static.
Also is it necessary to move some of them before they
are used, since they are no longer header-declared.

Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/video/em28xx/em28xx-input.c |  184 +++--
 drivers/media/video/em28xx/em28xx.h   |   17 ---
 2 files changed, 93 insertions(+), 108 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-input.c 
b/drivers/media/video/em28xx/em28xx-input.c
index 0a58ba8..2496625 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -80,7 +80,7 @@ struct em28xx_IR {
  I2C IR based get keycodes - should be used with ir-kbd-i2c
  **/
 
-int em28xx_get_key_terratec(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
+static int em28xx_get_key_terratec(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 {
unsigned char b;
 
@@ -108,7 +108,7 @@ int em28xx_get_key_terratec(struct IR_i2c *ir, u32 *ir_key, 
u32 *ir_raw)
return 1;
 }
 
-int em28xx_get_key_em_haup(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
+static int em28xx_get_key_em_haup(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 {
unsigned char buf[2];
u16 code;
@@ -157,7 +157,7 @@ int em28xx_get_key_em_haup(struct IR_i2c *ir, u32 *ir_key, 
u32 *ir_raw)
return 1;
 }
 
-int em28xx_get_key_pinnacle_usb_grey(struct IR_i2c *ir, u32 *ir_key,
+static int em28xx_get_key_pinnacle_usb_grey(struct IR_i2c *ir, u32 *ir_key,
 u32 *ir_raw)
 {
unsigned char buf[3];
@@ -179,7 +179,8 @@ int em28xx_get_key_pinnacle_usb_grey(struct IR_i2c *ir, u32 
*ir_key,
return 1;
 }
 
-int em28xx_get_key_winfast_usbii_deluxe(struct IR_i2c *ir, u32 *ir_key, u32 
*ir_raw)
+static int em28xx_get_key_winfast_usbii_deluxe(struct IR_i2c *ir, u32 *ir_key,
+   u32 *ir_raw)
 {
unsigned char subaddr, keydetect, key;
 
@@ -387,7 +388,7 @@ int em28xx_ir_change_protocol(struct rc_dev *rc_dev, u64 
rc_type)
return rc;
 }
 
-void em28xx_register_i2c_ir(struct em28xx *dev)
+static void em28xx_register_i2c_ir(struct em28xx *dev)
 {
/* Leadtek winfast tv USBII deluxe can find a non working IR-device */
/* at address 0x18, so if that address is needed for another board in */
@@ -431,6 +432,93 @@ void em28xx_register_i2c_ir(struct em28xx *dev)
i2c_new_probed_device(dev-i2c_adap, info, addr_list, NULL);
 }
 
+/**
+ Handle Webcam snapshot button
+ **/
+
+static void em28xx_query_sbutton(struct work_struct *work)
+{
+   /* Poll the register and see if the button is depressed */
+   struct em28xx *dev =
+   container_of(work, struct em28xx, sbutton_query_work.work);
+   int ret;
+
+   ret = em28xx_read_reg(dev, EM28XX_R0C_USBSUSP);
+
+   if (ret  EM28XX_R0C_USBSUSP_SNAPSHOT) {
+   u8 cleared;
+   /* Button is depressed, clear the register */
+   cleared = ((u8) ret)  ~EM28XX_R0C_USBSUSP_SNAPSHOT;
+   em28xx_write_regs(dev, EM28XX_R0C_USBSUSP, cleared, 1);
+
+   /* Not emulate the keypress */
+   input_report_key(dev-sbutton_input_dev, EM28XX_SNAPSHOT_KEY,
+1);
+   /* Now unpress the key */
+   input_report_key(dev-sbutton_input_dev, EM28XX_SNAPSHOT_KEY,
+0);
+   }
+
+   /* Schedule next poll */
+   schedule_delayed_work(dev-sbutton_query_work,
+ msecs_to_jiffies(EM28XX_SBUTTON_QUERY_INTERVAL));
+}
+
+static void em28xx_register_snapshot_button(struct em28xx *dev)
+{
+   struct input_dev *input_dev;
+   int err;
+
+   em28xx_info(Registering snapshot button...\n);
+   input_dev = input_allocate_device();
+   if (!input_dev) {
+   em28xx_errdev(input_allocate_device failed\n);
+   return;
+   }
+
+   usb_make_path(dev-udev, dev-snapshot_button_path,
+ sizeof(dev-snapshot_button_path));
+   strlcat(dev-snapshot_button_path, /sbutton,
+   sizeof(dev-snapshot_button_path));
+   INIT_DELAYED_WORK(dev-sbutton_query_work, em28xx_query_sbutton);
+
+   input_dev-name = em28xx snapshot button;
+   input_dev-phys = dev-snapshot_button_path;
+   input_dev-evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
+   set_bit(EM28XX_SNAPSHOT_KEY, input_dev-keybit);
+   input_dev-keycodesize = 0;
+   input_dev-keycodemax = 0;
+   input_dev-id.bustype = BUS_USB;
+   input_dev-id.vendor = le16_to_cpu(dev-udev-descriptor.idVendor);
+   input_dev-id.product = le16_to_cpu(dev-udev-descriptor.idProduct);
+   input_dev-id.version = 1;
+

[PATCH 5/5] em28xx: Make em28xx-input.c a separate module

[Ezequiel Garcia]

Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
 drivers/media/video/em28xx/Kconfig|4 ++--
 drivers/media/video/em28xx/Makefile   |5 ++---
 drivers/media/video/em28xx/em28xx-cards.c |8 ++--
 drivers/media/video/em28xx/em28xx-input.c |   27 +--
 drivers/media/video/em28xx/em28xx.h   |   15 +--
 5 files changed, 32 insertions(+), 27 deletions(-)

diff --git a/drivers/media/video/em28xx/Kconfig 
b/drivers/media/video/em28xx/Kconfig
index f6f622e..8a1a4d0 100644
--- a/drivers/media/video/em28xx/Kconfig
+++ b/drivers/media/video/em28xx/Kconfig
@@ -49,10 +49,10 @@ config VIDEO_EM28XX_DVB
  Empiatech em28xx chips.
 
 config VIDEO_EM28XX_RC
-bool EM28XX Remote Controller support
+tristate EM28XX Remote Controller support
 depends on RC_CORE
 depends on VIDEO_EM28XX
 depends on !(RC_CORE=m  VIDEO_EM28XX=y)
-default y
+default m
 ---help---
   Enables Remote Controller support on em28xx driver.
diff --git a/drivers/media/video/em28xx/Makefile 
b/drivers/media/video/em28xx/Makefile
index 2abdf76..c8b338d 100644
--- a/drivers/media/video/em28xx/Makefile
+++ b/drivers/media/video/em28xx/Makefile
@@ -1,16 +1,15 @@
 em28xx-y :=em28xx-video.o em28xx-i2c.o em28xx-cards.o
 em28xx-y +=em28xx-core.o  em28xx-vbi.o
 
-em28xx-$(CONFIG_VIDEO_EM28XX_RC) += em28xx-input.o
-
 em28xx-alsa-objs := em28xx-audio.o
+em28xx-rc-objs := em28xx-input.o
 
 obj-$(CONFIG_VIDEO_EM28XX) += em28xx.o
 obj-$(CONFIG_VIDEO_EM28XX_ALSA) += em28xx-alsa.o
 obj-$(CONFIG_VIDEO_EM28XX_DVB) += em28xx-dvb.o
+obj-$(CONFIG_VIDEO_EM28XX_RC) += em28xx-rc.o
 
 ccflags-y += -Idrivers/media/video
 ccflags-y += -Idrivers/media/common/tuners
 ccflags-y += -Idrivers/media/dvb/dvb-core
 ccflags-y += -Idrivers/media/dvb/frontends
-
diff --git a/drivers/media/video/em28xx/em28xx-cards.c 
b/drivers/media/video/em28xx/em28xx-cards.c
index 1cc244c..89720ab 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2795,9 +2795,6 @@ void em28xx_card_setup(struct em28xx *dev)
}
 
em28xx_tuner_setup(dev);
-
-   if(!disable_ir)
-   em28xx_ir_init(dev);
 }
 
 
@@ -2814,6 +2811,8 @@ static void request_module_async(struct work_struct *work)
 
if (dev-board.has_dvb)
request_module(em28xx-dvb);
+   if (dev-board.has_ir_i2c  !disable_ir)
+   request_module(em28xx-rc);
 }
 
 static void request_modules(struct em28xx *dev)
@@ -2838,9 +2837,6 @@ static void flush_request_modules(struct em28xx *dev)
 */
 void em28xx_release_resources(struct em28xx *dev)
 {
-   if (dev-ir)
-   em28xx_ir_fini(dev);
-
/*FIXME: I2C IR should be disconnected */
 
em28xx_release_analog_resources(dev);
diff --git a/drivers/media/video/em28xx/em28xx-input.c 
b/drivers/media/video/em28xx/em28xx-input.c
index 2496625..fce5f76 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -519,7 +519,7 @@ static void em28xx_deregister_snapshot_button(struct em28xx 
*dev)
return;
 }
 
-int em28xx_ir_init(struct em28xx *dev)
+static int em28xx_ir_init(struct em28xx *dev)
 {
struct em28xx_IR *ir;
struct rc_dev *rc;
@@ -599,7 +599,7 @@ int em28xx_ir_init(struct em28xx *dev)
return err;
 }
 
-int em28xx_ir_fini(struct em28xx *dev)
+static int em28xx_ir_fini(struct em28xx *dev)
 {
struct em28xx_IR *ir = dev-ir;
 
@@ -618,3 +618,26 @@ int em28xx_ir_fini(struct em28xx *dev)
return 0;
 }
 
+static struct em28xx_ops rc_ops = {
+   .id   = EM28XX_RC,
+   .name = Em28xx Input Extension,
+   .init = em28xx_ir_init,
+   .fini = em28xx_ir_fini,
+};
+
+static int __init em28xx_rc_register(void)
+{
+   return em28xx_register_extension(rc_ops);
+}
+
+static void __exit em28xx_rc_unregister(void)
+{
+   em28xx_unregister_extension(rc_ops);
+}
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Mauro Carvalho Chehab mche...@redhat.com);
+MODULE_DESCRIPTION(Em28xx Input driver);
+
+module_init(em28xx_rc_register);
+module_exit(em28xx_rc_unregister);
diff --git a/drivers/media/video/em28xx/em28xx.h 
b/drivers/media/video/em28xx/em28xx.h
index 75630a6..e7019b0 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -464,6 +464,7 @@ enum em28xx_dev_state {
 /* em28xx extensions */
 #define EM28XX_AUDIO   0x10
 #define EM28XX_DVB 0x20
+#define EM28XX_RC  0x30
 
 /* em28xx resource types (used for res_get/res_lock etc */
 #define EM28XX_RESOURCE_VIDEO 0x01
@@ -718,20 +719,6 @@ extern const unsigned int em28xx_bcount;
 int em28xx_tuner_callback(void *ptr, int component, int command, int arg);
 void em28xx_release_resources(struct em28xx *dev);
 
-/* Provided by em28xx-input.c */
-
-#ifdef CONFIG_VIDEO_EM28XX_RC
-
-int em28xx_ir_init(struct em28xx *dev);
-int em28xx_ir_fini(struct 

[PATCH v2 0/3] media: tvp5150: Fix mbus format to UYUV instead of YUYV.

[Javier Martin]

Changes since v2:
- Swap order of patches 3 and 4 to make the series bisectable.

[PATCH v2 1/3] media: tvp5150: Fix mbus format.
[PATCH v2 2/3] i.MX27: visstrim_m10: Remove use of MX2_CAMERA_SWAP16.
[PATCH v2 3/3] media: mx2_camera: Fix mbus format handling.
--
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/3] media: tvp5150: Fix mbus format.

[Javier Martin]

According to p.14 fig 3-3 of the datasheet (SLES098A)
this decoder transmits data in UYVY format.

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 drivers/media/video/tvp5150.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index e292c46..30c88e0 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -821,7 +821,7 @@ static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, 
unsigned index,
if (index)
return -EINVAL;
 
-   *code = V4L2_MBUS_FMT_YUYV8_2X8;
+   *code = V4L2_MBUS_FMT_UYVY8_2X8;
return 0;
 }
 
@@ -845,7 +845,7 @@ static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
f-width = decoder-rect.width;
f-height = decoder-rect.height;
 
-   f-code = V4L2_MBUS_FMT_YUYV8_2X8;
+   f-code = V4L2_MBUS_FMT_UYVY8_2X8;
f-field = V4L2_FIELD_SEQ_TB;
f-colorspace = V4L2_COLORSPACE_SMPTE170M;
 
-- 
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 v2 2/3] i.MX27: visstrim_m10: Remove use of MX2_CAMERA_SWAP16.

[Javier Martin]

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 arch/arm/mach-imx/mach-imx27_visstrim_m10.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c 
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 3128cfe..4db00c6 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -164,7 +164,7 @@ static struct platform_device visstrim_tvp5150 = {
 
 
 static struct mx2_camera_platform_data visstrim_camera = {
-   .flags = MX2_CAMERA_CCIR | MX2_CAMERA_CCIR_INTERLACE | 
MX2_CAMERA_SWAP16 | MX2_CAMERA_PCLK_SAMPLE_RISING,
+   .flags = MX2_CAMERA_CCIR | MX2_CAMERA_CCIR_INTERLACE | 
MX2_CAMERA_PCLK_SAMPLE_RISING,
.clk = 10,
 };
 
-- 
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 v2 3/3] media: mx2_camera: Fix mbus format handling.

[Javier Martin]

Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags
so that the driver can negotiate with the attached sensor
whether the mbus format needs convertion from UYUV to YUYV
or not.

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 arch/arm/plat-mxc/include/mach/mx2_cam.h |2 -
 drivers/media/video/mx2_camera.c |   52 +++---
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h 
b/arch/arm/plat-mxc/include/mach/mx2_cam.h
index 3c080a3..7ded6f1 100644
--- a/arch/arm/plat-mxc/include/mach/mx2_cam.h
+++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
@@ -23,7 +23,6 @@
 #ifndef __MACH_MX2_CAM_H_
 #define __MACH_MX2_CAM_H_
 
-#define MX2_CAMERA_SWAP16  (1  0)
 #define MX2_CAMERA_EXT_VSYNC   (1  1)
 #define MX2_CAMERA_CCIR(1  2)
 #define MX2_CAMERA_CCIR_INTERLACE  (1  3)
@@ -31,7 +30,6 @@
 #define MX2_CAMERA_GATED_CLOCK (1  5)
 #define MX2_CAMERA_INV_DATA(1  6)
 #define MX2_CAMERA_PCLK_SAMPLE_RISING  (1  7)
-#define MX2_CAMERA_PACK_DIR_MSB(1  8)
 
 /**
  * struct mx2_camera_platform_data - optional platform data for mx2_camera
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 8df624f..9274a53 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -348,6 +348,19 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
PRP_INTR_CH2OVF,
}
},
+   {
+   .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+   .out_fmt= V4L2_PIX_FMT_YUV420,
+   .cfg= {
+   .channel= 2,
+   .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+   .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
+   .src_pixel  = 0x22000888, /* YUV422 (YUYV) */
+   .irq_flags  = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
+   PRP_INTR_CH2FC | PRP_INTR_LBOVF |
+   PRP_INTR_CH2OVF,
+   }
+   },
 };
 
 static struct mx2_fmt_cfg *mx27_emma_prp_get_format(
@@ -990,6 +1003,7 @@ static int mx2_camera_set_bus_param(struct 
soc_camera_device *icd,
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct mx2_camera_dev *pcdev = ici-priv;
struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+   const struct soc_camera_format_xlate *xlate;
unsigned long common_flags;
int ret;
int bytesperline;
@@ -1034,14 +1048,31 @@ static int mx2_camera_set_bus_param(struct 
soc_camera_device *icd,
return ret;
}
 
+   xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+   if (!xlate) {
+   dev_warn(icd-parent, Format %x not found\n, pixfmt);
+   return -EINVAL;
+   }
+
+   if (xlate-code == V4L2_MBUS_FMT_YUYV8_2X8) {
+   csicr1 |= CSICR1_PACK_DIR;
+   csicr1 = ~CSICR1_SWAP16_EN;
+   dev_dbg(icd-parent, already yuyv format, don't convert\n);
+   } else if (xlate-code == V4L2_MBUS_FMT_UYVY8_2X8) {
+   csicr1 = ~CSICR1_PACK_DIR;
+   csicr1 |= CSICR1_SWAP16_EN;
+   dev_dbg(icd-parent, convert uyvy mbus format into yuyv\n);
+   } else {
+   dev_warn(icd-parent, mbus format not supported\n);
+   return -EINVAL;
+   }
+
if (common_flags  V4L2_MBUS_PCLK_SAMPLE_RISING)
csicr1 |= CSICR1_REDGE;
if (common_flags  V4L2_MBUS_VSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_SOF_POL;
if (common_flags  V4L2_MBUS_HSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_HSYNC_POL;
-   if (pcdev-platform_flags  MX2_CAMERA_SWAP16)
-   csicr1 |= CSICR1_SWAP16_EN;
if (pcdev-platform_flags  MX2_CAMERA_EXT_VSYNC)
csicr1 |= CSICR1_EXT_VSYNC;
if (pcdev-platform_flags  MX2_CAMERA_CCIR)
@@ -1052,8 +1083,6 @@ static int mx2_camera_set_bus_param(struct 
soc_camera_device *icd,
csicr1 |= CSICR1_GCLK_MODE;
if (pcdev-platform_flags  MX2_CAMERA_INV_DATA)
csicr1 |= CSICR1_INV_DATA;
-   if (pcdev-platform_flags  MX2_CAMERA_PACK_DIR_MSB)
-   csicr1 |= CSICR1_PACK_DIR;
 
pcdev-csicr1 = csicr1;
 
@@ -1128,7 +1157,8 @@ static int mx2_camera_get_formats(struct 
soc_camera_device *icd,
return 0;
}
 
-   if (code == V4L2_MBUS_FMT_YUYV8_2X8) {
+   if (code == V4L2_MBUS_FMT_YUYV8_2X8 ||
+   code == V4L2_MBUS_FMT_UYVY8_2X8) {
formats++;
if (xlate) {
/*
@@ -1144,6 +1174,18 @@ static int mx2_camera_get_formats(struct 
soc_camera_device *icd,
}
}
 
+   if (code == 

Re: Hauppauge WinTV HVR 930C-HD - new USB ID 2040:b130 ?

[Ezequiel García]

Hi,

2012/3/26 Steffen Neumann sneum...@ipb-halle.de:
 sorry for bothering you directly, but I saw that

No problem.

 you kinda work on em288xx. I asked yesterday on linux-media

True about kinda, I don't own any em28xx devices :)

 about my problems with the em28xx based 930C
 on a 3.3 vanilla kernel.

Yes, I saw the mail. I think indeed you have a device
that is not supported (yet?) by em28xx.
If lsusb says 2040:b130 rather than 2040:1605 then
I guess it's a new kind of device, different chipset,
I'm not sure (not an expert, sorry).


 Is this this the correct list to ask,
 and I just need to have more patience ?
 Or should I bring the issue up somewhere else ?

Not sure wherelse you can post your question.
Just wait for a while and ping again in a few weeks,
or so. I believe we are in the middle of a merge window
so developers are a little busy right now.

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

[PATCH 0/3] OMAP3 ISP preview engine fixes

[Laurent Pinchart]

Hello,

Here are three patches for the OMAP3 ISP that improve the preview engine
configuration.

Patch 1/3 fixes in bug in the driver that shouldn't cause any misbehaviour,
but is still wrong nonetheless. Patch 2/3 speeds up interrupt handling for the
common case when no parameter has been modified, and patch 3/3 fixes a shadow
update issue that resulted in parameters never being applied in a common race
condition case.

Laurent Pinchart (3):
  omap3isp: preview: Skip brightness and contrast in configuration
ioctl
  omap3isp: preview: Optimize parameters setup for the common case
  omap3isp: preview: Shorten shadow update delay

 drivers/media/video/omap3isp/isppreview.c |  129 -
 drivers/media/video/omap3isp/isppreview.h |   19 +++--
 2 files changed, 101 insertions(+), 47 deletions(-)

-- 
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 1/3] omap3isp: preview: Skip brightness and contrast in configuration ioctl

[Laurent Pinchart]

Brightness and contrast are handled through V4L2 controls. Their
configuration bit in the preview engine update attributes table is set
to -1 to reflect that. However, the VIDIOC_OMAP3ISP_PRV_CFG ioctl
handler doesn't handle -1 correctly as a configuration bit value, and
erroneously considers that the parameter has been selected for update by
the ioctl caller. Fix this.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/omap3isp/isppreview.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/omap3isp/isppreview.c 
b/drivers/media/video/omap3isp/isppreview.c
index 6d0fb2c..cf5014f 100644
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -903,7 +903,7 @@ static int preview_config(struct isp_prev_device *prev,
attr = update_attrs[i];
bit = 0;
 
-   if (!(cfg-update  attr-cfg_bit))
+   if (attr-cfg_bit == -1 || !(cfg-update  attr-cfg_bit))
continue;
 
bit = cfg-flag  attr-cfg_bit;
-- 
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 2/3] omap3isp: preview: Optimize parameters setup for the common case

[Laurent Pinchart]

If no parameter needs to be modified, make preview_config() and
preview_setup_hw() return immediately. This speeds up interrupt handling
in the common case.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/omap3isp/isppreview.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/omap3isp/isppreview.c 
b/drivers/media/video/omap3isp/isppreview.c
index cf5014f..2b5c137 100644
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -890,6 +890,8 @@ static int preview_config(struct isp_prev_device *prev,
int i, bit, rval = 0;
 
params = prev-params;
+   if (cfg-update == 0)
+   return 0;
 
if (prev-state != ISP_PIPELINE_STREAM_STOPPED) {
unsigned long flags;
@@ -944,6 +946,9 @@ static void preview_setup_hw(struct isp_prev_device *prev)
int i, bit;
void *param_ptr;
 
+   if (params-update == 0)
+   return;
+
for (i = 0; i  ARRAY_SIZE(update_attrs); i++) {
attr = update_attrs[i];
 
-- 
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 3/3] omap3isp: preview: Shorten shadow update delay

[Laurent Pinchart]

When applications modify preview engine parameters, the new values are
applied to the hardware by the preview engine interrupt handler during
vertical blanking. If the parameters are being changed when the
interrupt handler is called, it just delays applying the parameters
until the next frame.

If an application modifies the parameters for every frame, and the
preview engine interrupt is triggerred synchronously, the parameters are
never applied to the hardware.

Fix this by storing new parameters in a shadow copy, and replace the
active parameters with the shadow values atomically.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/omap3isp/isppreview.c |  122 -
 drivers/media/video/omap3isp/isppreview.h |   19 +++--
 2 files changed, 95 insertions(+), 46 deletions(-)

diff --git a/drivers/media/video/omap3isp/isppreview.c 
b/drivers/media/video/omap3isp/isppreview.c
index 2b5c137..34fecc9 100644
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -649,12 +649,17 @@ preview_config_rgb_to_ycbcr(struct isp_prev_device *prev, 
const void *prev_csc)
 static void
 preview_update_contrast(struct isp_prev_device *prev, u8 contrast)
 {
-   struct prev_params *params = prev-params;
+   struct prev_params *params;
+   unsigned long flags;
+
+   spin_lock_irqsave(prev-params.lock, flags);
+   params = prev-params.active;
 
if (params-contrast != (contrast * ISPPRV_CONTRAST_UNITS)) {
params-contrast = contrast * ISPPRV_CONTRAST_UNITS;
-   prev-update |= PREV_CONTRAST;
+   params-update |= PREV_CONTRAST;
}
+   spin_unlock_irqrestore(prev-params.lock, flags);
 }
 
 /*
@@ -681,12 +686,17 @@ preview_config_contrast(struct isp_prev_device *prev, 
const void *params)
 static void
 preview_update_brightness(struct isp_prev_device *prev, u8 brightness)
 {
-   struct prev_params *params = prev-params;
+   struct prev_params *params;
+   unsigned long flags;
+
+   spin_lock_irqsave(prev-params.lock, flags);
+   params = prev-params.active;
 
if (params-brightness != (brightness * ISPPRV_BRIGHT_UNITS)) {
params-brightness = brightness * ISPPRV_BRIGHT_UNITS;
-   prev-update |= PREV_BRIGHTNESS;
+   params-update |= PREV_BRIGHTNESS;
}
+   spin_unlock_irqrestore(prev-params.lock, flags);
 }
 
 /*
@@ -886,20 +896,24 @@ static int preview_config(struct isp_prev_device *prev,
  struct omap3isp_prev_update_config *cfg)
 {
struct prev_params *params;
+   struct prev_params *shadow;
struct preview_update *attr;
+   unsigned long flags;
int i, bit, rval = 0;
 
-   params = prev-params;
if (cfg-update == 0)
return 0;
 
-   if (prev-state != ISP_PIPELINE_STREAM_STOPPED) {
-   unsigned long flags;
+   params = kmalloc(sizeof(*params), GFP_KERNEL);
+   if (params == NULL)
+   return -ENOMEM;
 
-   spin_lock_irqsave(prev-lock, flags);
-   prev-shadow_update = 1;
-   spin_unlock_irqrestore(prev-lock, flags);
-   }
+   spin_lock_irqsave(prev-params.lock, flags);
+   memcpy(params, prev-params.shadow ? : prev-params.active,
+  sizeof(*params));
+   spin_unlock_irqrestore(prev-params.lock, flags);
+
+   params-update = 0;
 
for (i = 0; i  ARRAY_SIZE(update_attrs); i++) {
attr = update_attrs[i];
@@ -926,11 +940,28 @@ static int preview_config(struct isp_prev_device *prev,
params-features = ~attr-feature_bit;
}
 
-   prev-update |= attr-feature_bit;
+   params-update |= attr-feature_bit;
+   }
+
+   if (rval  0) {
+   kfree(params);
+   return rval;
}
 
-   prev-shadow_update = 0;
-   return rval;
+   spin_lock_irqsave(prev-params.lock, flags);
+   /* If shadow parameters are still present, keep their update flags as
+* the hardware hasn't been updated yet. The values have been copied at
+* the beginning of the function.
+*/
+   if (prev-params.shadow)
+   params-update |= prev-params.shadow-update;
+
+   shadow = prev-params.shadow;
+   prev-params.shadow = params;
+   spin_unlock_irqrestore(prev-params.lock, flags);
+
+   kfree(shadow);
+   return 0;
 }
 
 /*
@@ -941,7 +972,7 @@ static int preview_config(struct isp_prev_device *prev,
  */
 static void preview_setup_hw(struct isp_prev_device *prev)
 {
-   struct prev_params *params = prev-params;
+   struct prev_params *params = prev-params.active;
struct preview_update *attr;
int i, bit;
void *param_ptr;
@@ -952,7 +983,7 @@ static void preview_setup_hw(struct isp_prev_device *prev)
for (i = 0; i  

Re: Hauppauge WinTV HVR 930C-HD - new USB ID 2040:b130 ?

[Devin Heitmueller]

On Sun, Mar 25, 2012 at 4:09 PM, Steffen Neumann sneum...@ipb-halle.de wrote:
 Hi,

 I am trying to get a Hauppauge WinTV HVR 930C-HD
 to work under Ubuntu 12.04 with the vanilla 3.3 kernel from [1].
 After (manually) loading the em28xx module,
 there are no additional messages in kern.log,
 only registered new interface driver em28xx.

 What is odd is that lsusb shows for this card ID 2040:b130 Hauppauge,
 while from [2] I think it should be [2040:1605],
 see below for the full lsusb -v output. The card
 was purchased this week.

 Do I have a new revision of the 930C ?
 I tried modprobe em28xx card=81, but no change.
 Did I miss anything else ?

2040:b130 isn't an em28xx based device.  It uses cx231xx.  That said,
it's not supported under Linux not because of the cx231xx driver but
because there is no driver for the demodulator (si2163).

Nobody is working on such a driver, and there is no support planned
for this device at this time.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: Hauppauge WinTV HVR 930C-HD - new USB ID 2040:b130 ?

[Devin Heitmueller]

On Mon, Mar 26, 2012 at 10:46 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 2040:b130 isn't an em28xx based device.  It uses cx231xx.  That said,
 it's not supported under Linux not because of the cx231xx driver but
 because there is no driver for the demodulator (si2163).

Correction:  it's an si2165 (not 2163).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: Using MT9P031 digital sensor

[Joshua Hintze]

Gary,

I'm using linux branch from 2.6.39

Fetch URL: git://www.sakoman.com/git/linux-omap-2.6
branch: omap-2.6.39

I'm using an overo board so I figured I should follow Steve Sakoman's
repository.

Which brings up another question, would you recommend going off of one
of Laurent's repo's and if so which one?


Thanks,

Josh



On Mon, Mar 26, 2012 at 9:25 AM, Gary Thomas g...@mlbassoc.com wrote:
 On 2012-03-25 23:13, Joshua Hintze wrote:

 Alright I made some progress on this.

 I can access the Mt9p031 registers that are exposed using a command such
 as

 ./yavta -l /dev/v4l-subdev8 to list the available controls. Then I can
 set the exposure and analog gain with
 ./yavta --set-control '0x00980911 1500' /dev/v4l-subdev8--- This
 seems to give the desired effect.

 Note that ./yavta -w (short option for --set-control) gives a seg
 fault for me. Possible bug in yavta??

 Now I'm working on fixing the white balance. In my office the
 incandescent light bulbs give off a yellowish tint late at night. I've
 been digging through the omap3isp code to figure out how to enable the
 automatic white balance. I was able to find the private IOCTLs for the
 previewer and I was able to use VIDIOC_OMAP3ISP_PRV_CFG. Using this
 IOCTL I adjusted the OMAP3ISP_PREV_WB, OMAP3ISP_PREV_BLKADJ, and
 OMAP3ISP_PREV_RGB2RGB.

 Since I wasn't sure where to start on adjusting these values I just
 set them all to the TRM's default register values. However when I did
 so a strange thing occurred. What I saw was all the colors went to a
 decent color. I'm curious if anybody can shed some light on the best
 way to get a high quality image. Ideally if I could just set a bit for
 auto white balance and auto exposure that could be good too.


 Just curious - what codebase (git URL) are you using?

 On Fri, Mar 23, 2012 at 1:01 PM, Joshua Hintzejoshua.hin...@gmail.com
  wrote:

 Sorry to bring up this old message list. I was curious when you spoke
 about the ISP preview engine being able to adjust the white balance.

 When I enumerate the previewer's available controls all I see is...

 root@overo:~# ./yavta -l /dev/v4l-subdev3
 --- User Controls (class 0x00980001) ---
 control 0x00980900 `Brightness' min 0 max 255 step 1 default 0 current 0.
 control 0x00980901 `Contrast' min 0 max 255 step 1 default 16 current 16.
 2 controls found.


 Is this what you are referring to? Are there other settings I can
 adjust to get the white balance and focus better using the  OMAP3 ISP
 AWEB/OMAP3 ISP AF?

 Thanks,

 Josh




 Hi Gary,

 On Wednesday 30 November 2011 18:00:55 Gary Thomas wrote:

 On 2011-11-30 07:57, Gary Thomas wrote:

 On 2011-11-30 07:30, Laurent Pinchart wrote:

 On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote:


 [snip]

 This sort of works(*), but I'm still having issues (at least I can
 move
 frames!) When I configure the pipeline like this:
 media-ctl -r
 media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]'
 media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'
 media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'
 media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
 media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]'
 media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]'
 media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]'
 media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]'
 media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]'
 media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]'
 the resulting frames are 24 bytes each instead of 654720

 When I tried to grab from the previewer, the frames were 9969120
 instead of 9961380

 Any ideas what resolution is actually being moved through?


 Because the OMAP3 ISP has alignment requirements. Both the preview
 engine and the resizer output line lenghts must be multiple of 32
 bytes. The driver adds padding at end of lines when the output width
 isn't a multiple of 16 pixels.


 Any guess which resolution(s) I should change and to what?


 I changed the resizer output to be 672x496 and was able to capture video
 using ffmpeg.

 I don't know what to expect with this sensor (I've never seen it in use
 before), but the image seems to have color balance issues - it's awash
 in
 a green hue.  It may be the poor lighting in my office...  I did try the
 9
 test patterns which I was able to select via
    # v4l2-ctl -d /dev/v4l-subdev8 --set-ctrl=test_pattern=N
 and these looked OK.  You can see them at
 http://www.mlbassoc.com/misc/mt9p031_images/


 Neither the sensor nor the OMAP3 ISP implement automatic white balance.
 The
 ISP preview engine can be used to modify the white balance, and the
 statistics
 engine can be used to extract data useful to compute the white balance
 parameters, but linking the two needs to be performed in userspace.

 So this means that your original problem comes from the BT656 patches.


 Yes, it does look that way. Now that I have something that moves data,
 I
 can compare how the ISP is setup between the two versions and come up
 with a 

Re: Using MT9P031 digital sensor

[Joshua Hintze]

Laurent,

On Mon, Mar 26, 2012 at 2:25 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Joshua,

 On Sunday 25 March 2012 23:13:02 Joshua Hintze wrote:
 Alright I made some progress on this.

 I can access the Mt9p031 registers that are exposed using a command such as

 ./yavta -l /dev/v4l-subdev8 to list the available controls. Then I can
 set the exposure and analog gain with
 ./yavta --set-control '0x00980911 1500' /dev/v4l-subdev8   --- This
 seems to give the desired effect.

 Note that ./yavta -w (short option for --set-control) gives a seg
 fault for me. Possible bug in yavta??

 That's strange, I use -w all the time and haven't noticed any segfault. Can
 you compile yavta with debugging information and provide some context ?


Then this must be my problem. I slightly modified yavta to output to
stdout for net cat streaming to mplayer on my desktop. I probably
didn't get the short options string correct.

 Now I'm working on fixing the white balance. In my office the incandescent
 light bulbs give off a yellowish tint late at night. I've been digging
 through the omap3isp code to figure out how to enable the automatic white
 balance. I was able to find the private IOCTLs for the previewer and I was
 able to use VIDIOC_OMAP3ISP_PRV_CFG. Using this IOCTL I adjusted the
 OMAP3ISP_PREV_WB, OMAP3ISP_PREV_BLKADJ, and OMAP3ISP_PREV_RGB2RGB.

 Since I wasn't sure where to start on adjusting these values I just set them
 all to the TRM's default register values. However when I did so a strange
 thing occurred. What I saw was all the colors went to a decent color. I'm
 curious if anybody can shed some light on the best way to get a high quality
 image. Ideally if I could just set a bit for auto white balance and auto
 exposure that could be good too.

 The ISP doesn't implement automatic white balance. It can apply white
 balancing (as well as other related processing), but computing values for
 those parameters needs to be performed in userspace. The ISP statistics engine
 engine can help speeding up the process, but the AEWB algorithm must be
 implemented in your application.


Dang, I'll have to look up some AEWB algorithms. I'm curious why TI
would have this register bit then (AEW_EN bit 15 in H3A_PCR)?

Is this the same for auto focus and auto exposure? Meaning that I'll
need to get information from the histogram/statistics to adjust focus
and exposure times?

Thanks,

Josh

 --
 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] omap3isp: preview: Shorten shadow update delay

[Sakari Ailus]

Hi Laurent,

Thanks for the patch.

On Mon, Mar 26, 2012 at 04:42:31PM +0200, Laurent Pinchart wrote:
 When applications modify preview engine parameters, the new values are
 applied to the hardware by the preview engine interrupt handler during
 vertical blanking. If the parameters are being changed when the
 interrupt handler is called, it just delays applying the parameters
 until the next frame.
 
 If an application modifies the parameters for every frame, and the
 preview engine interrupt is triggerred synchronously, the parameters are
 never applied to the hardware.
 
 Fix this by storing new parameters in a shadow copy, and replace the
 active parameters with the shadow values atomically.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/media/video/omap3isp/isppreview.c |  122 
 -
  drivers/media/video/omap3isp/isppreview.h |   19 +++--
  2 files changed, 95 insertions(+), 46 deletions(-)
 
 diff --git a/drivers/media/video/omap3isp/isppreview.c 
 b/drivers/media/video/omap3isp/isppreview.c
 index 2b5c137..34fecc9 100644
 --- a/drivers/media/video/omap3isp/isppreview.c
 +++ b/drivers/media/video/omap3isp/isppreview.c
 @@ -649,12 +649,17 @@ preview_config_rgb_to_ycbcr(struct isp_prev_device 
 *prev, const void *prev_csc)
  static void
  preview_update_contrast(struct isp_prev_device *prev, u8 contrast)
  {
 - struct prev_params *params = prev-params;
 + struct prev_params *params;
 + unsigned long flags;
 +
 + spin_lock_irqsave(prev-params.lock, flags);
 + params = prev-params.active;
  
   if (params-contrast != (contrast * ISPPRV_CONTRAST_UNITS)) {
   params-contrast = contrast * ISPPRV_CONTRAST_UNITS;
 - prev-update |= PREV_CONTRAST;
 + params-update |= PREV_CONTRAST;
   }
 + spin_unlock_irqrestore(prev-params.lock, flags);
  }
  
  /*
 @@ -681,12 +686,17 @@ preview_config_contrast(struct isp_prev_device *prev, 
 const void *params)
  static void
  preview_update_brightness(struct isp_prev_device *prev, u8 brightness)
  {
 - struct prev_params *params = prev-params;
 + struct prev_params *params;
 + unsigned long flags;
 +
 + spin_lock_irqsave(prev-params.lock, flags);
 + params = prev-params.active;
  
   if (params-brightness != (brightness * ISPPRV_BRIGHT_UNITS)) {
   params-brightness = brightness * ISPPRV_BRIGHT_UNITS;
 - prev-update |= PREV_BRIGHTNESS;
 + params-update |= PREV_BRIGHTNESS;
   }
 + spin_unlock_irqrestore(prev-params.lock, flags);
  }
  
  /*
 @@ -886,20 +896,24 @@ static int preview_config(struct isp_prev_device *prev,
 struct omap3isp_prev_update_config *cfg)
  {
   struct prev_params *params;
 + struct prev_params *shadow;
   struct preview_update *attr;
 + unsigned long flags;
   int i, bit, rval = 0;
  
 - params = prev-params;
   if (cfg-update == 0)
   return 0;
  
 - if (prev-state != ISP_PIPELINE_STREAM_STOPPED) {
 - unsigned long flags;
 + params = kmalloc(sizeof(*params), GFP_KERNEL);
 + if (params == NULL)
 + return -ENOMEM;
  
 - spin_lock_irqsave(prev-lock, flags);
 - prev-shadow_update = 1;
 - spin_unlock_irqrestore(prev-lock, flags);
 - }
 + spin_lock_irqsave(prev-params.lock, flags);
 + memcpy(params, prev-params.shadow ? : prev-params.active,
 +sizeof(*params));
 + spin_unlock_irqrestore(prev-params.lock, flags);
 +
 + params-update = 0;
  
   for (i = 0; i  ARRAY_SIZE(update_attrs); i++) {
   attr = update_attrs[i];

I think it's partly a matter of taste but --- would you think it'd make
sense to allocate the another configuration structure statically? I didn't
check the actual size of the configuration but it seems to be pretty big.
Handling allocation failures in applications is a nuisance, but also
allocating such largish chunks to just to be on the safe side doesn't sound
very appealing either.

Say, if you're capturing a photo and you allocation fails here. Should you
just retry it a few times, or fail immediately? Random allocation failures
are not unforeseen even on systems with plenty of memory. Not that it should
work this way I guess...

Have you checked what's the size of this struct btw.?

 @@ -926,11 +940,28 @@ static int preview_config(struct isp_prev_device *prev,
   params-features = ~attr-feature_bit;
   }
  
 - prev-update |= attr-feature_bit;
 + params-update |= attr-feature_bit;
 + }
 +
 + if (rval  0) {
 + kfree(params);
 + return rval;
   }
  
 - prev-shadow_update = 0;
 - return rval;
 + spin_lock_irqsave(prev-params.lock, flags);
 + /* If shadow parameters are still present, keep their update flags as
 +  * the hardware hasn't been updated yet. The 

Re: [PATCH 1/3] omap3isp: preview: Skip brightness and contrast in configuration ioctl

[Sakari Ailus]

On Mon, Mar 26, 2012 at 04:42:29PM +0200, Laurent Pinchart wrote:
 Brightness and contrast are handled through V4L2 controls. Their
 configuration bit in the preview engine update attributes table is set
 to -1 to reflect that. However, the VIDIOC_OMAP3ISP_PRV_CFG ioctl
 handler doesn't handle -1 correctly as a configuration bit value, and
 erroneously considers that the parameter has been selected for update by
 the ioctl caller. Fix this.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

Thanks!

Acked-by: Sakari Ailus sakari.ai...@iki.fi

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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/3] omap3isp: preview: Optimize parameters setup for the common case

[Sakari Ailus]

Thanks!

On Mon, Mar 26, 2012 at 04:42:30PM +0200, Laurent Pinchart wrote:
 If no parameter needs to be modified, make preview_config() and
 preview_setup_hw() return immediately. This speeds up interrupt handling
 in the common case.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

Acked-by: Sakari Ailus sakari.ai...@iki.fi

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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: [off-topic] Linux-media e-mail problems

[Enrico]

Hi,

FYI: I suddenly stopped receiving e-mails from this list last week, March
16th. Does anyone have an explanation for that?

Same here, i had to subscribe again.

Enrico
--
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: Using MT9P031 digital sensor

[Gary Thomas]

On 2012-03-26 09:37, Joshua Hintze wrote:

Gary,

I'm using linux branch from 2.6.39

Fetch URL: git://www.sakoman.com/git/linux-omap-2.6
branch: omap-2.6.39

I'm using an overo board so I figured I should follow Steve Sakoman's
repository.

Which brings up another question, would you recommend going off of one
of Laurent's repo's and if so which one?


The last time I tried Laurent's repo, it did not have the UYVY support in
the OMAP3ISP/CCDC merged in.  I don't know if that has changed recently.


On Mon, Mar 26, 2012 at 9:25 AM, Gary Thomasg...@mlbassoc.com  wrote:

On 2012-03-25 23:13, Joshua Hintze wrote:


Alright I made some progress on this.

I can access the Mt9p031 registers that are exposed using a command such
as

./yavta -l /dev/v4l-subdev8 to list the available controls. Then I can
set the exposure and analog gain with
./yavta --set-control '0x00980911 1500' /dev/v4l-subdev8--- This
seems to give the desired effect.

Note that ./yavta -w (short option for --set-control) gives a seg
fault for me. Possible bug in yavta??

Now I'm working on fixing the white balance. In my office the
incandescent light bulbs give off a yellowish tint late at night. I've
been digging through the omap3isp code to figure out how to enable the
automatic white balance. I was able to find the private IOCTLs for the
previewer and I was able to use VIDIOC_OMAP3ISP_PRV_CFG. Using this
IOCTL I adjusted the OMAP3ISP_PREV_WB, OMAP3ISP_PREV_BLKADJ, and
OMAP3ISP_PREV_RGB2RGB.

Since I wasn't sure where to start on adjusting these values I just
set them all to the TRM's default register values. However when I did
so a strange thing occurred. What I saw was all the colors went to a
decent color. I'm curious if anybody can shed some light on the best
way to get a high quality image. Ideally if I could just set a bit for
auto white balance and auto exposure that could be good too.



Just curious - what codebase (git URL) are you using?


On Fri, Mar 23, 2012 at 1:01 PM, Joshua Hintzejoshua.hin...@gmail.com
  wrote:


Sorry to bring up this old message list. I was curious when you spoke
about the ISP preview engine being able to adjust the white balance.

When I enumerate the previewer's available controls all I see is...

root@overo:~# ./yavta -l /dev/v4l-subdev3
--- User Controls (class 0x00980001) ---
control 0x00980900 `Brightness' min 0 max 255 step 1 default 0 current 0.
control 0x00980901 `Contrast' min 0 max 255 step 1 default 16 current 16.
2 controls found.


Is this what you are referring to? Are there other settings I can
adjust to get the white balance and focus better using the  OMAP3 ISP
AWEB/OMAP3 ISP AF?

Thanks,

Josh




Hi Gary,

On Wednesday 30 November 2011 18:00:55 Gary Thomas wrote:


On 2011-11-30 07:57, Gary Thomas wrote:


On 2011-11-30 07:30, Laurent Pinchart wrote:


On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote:



[snip]


This sort of works(*), but I'm still having issues (at least I can
move
frames!) When I configure the pipeline like this:
media-ctl -r
media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]'
media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'
media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'
media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]'
media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]'
media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]'
media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]'
media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]'
media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]'
the resulting frames are 24 bytes each instead of 654720

When I tried to grab from the previewer, the frames were 9969120
instead of 9961380

Any ideas what resolution is actually being moved through?



Because the OMAP3 ISP has alignment requirements. Both the preview
engine and the resizer output line lenghts must be multiple of 32
bytes. The driver adds padding at end of lines when the output width
isn't a multiple of 16 pixels.



Any guess which resolution(s) I should change and to what?



I changed the resizer output to be 672x496 and was able to capture video
using ffmpeg.

I don't know what to expect with this sensor (I've never seen it in use
before), but the image seems to have color balance issues - it's awash
in
a green hue.  It may be the poor lighting in my office...  I did try the
9
test patterns which I was able to select via
# v4l2-ctl -d /dev/v4l-subdev8 --set-ctrl=test_pattern=N
and these looked OK.  You can see them at
http://www.mlbassoc.com/misc/mt9p031_images/



Neither the sensor nor the OMAP3 ISP implement automatic white balance.
The
ISP preview engine can be used to modify the white balance, and the
statistics
engine can be used to extract data useful to compute the white balance
parameters, but linking the two needs to be performed in userspace.


So this means that your original problem comes from the BT656 patches.



Yes, it does look that way. Now that I have 

Re: Hauppauge WinTV HVR 930C-HD - new USB ID 2040:b130 ?

[Neumann, Steffen]

Hi,
Not the answer I was looking for,
But thanks everybody for the clarification.
I'll try to register for the wiki and add
That information.

Yours, Steffen


Devin Heitmueller dheitmuel...@kernellabs.com schrieb:


On Sun, Mar 25, 2012 at 4:09 PM, Steffen Neumann sneum...@ipb-halle.de wrote:
 Hi,

 I am trying to get a Hauppauge WinTV HVR 930C-HD
 to work under Ubuntu 12.04 with the vanilla 3.3 kernel from [1].
 After (manually) loading the em28xx module,
 there are no additional messages in kern.log,
 only registered new interface driver em28xx.

 What is odd is that lsusb shows for this card ID 2040:b130 Hauppauge,
 while from [2] I think it should be [2040:1605],
 see below for the full lsusb -v output. The card
 was purchased this week.

 Do I have a new revision of the 930C ?
 I tried modprobe em28xx card=81, but no change.
 Did I miss anything else ?

2040:b130 isn't an em28xx based device.  It uses cx231xx.  That said,
it's not supported under Linux not because of the cx231xx driver but
because there is no driver for the demodulator (si2163).

Nobody is working on such a driver, and there is no support planned
for this device at this time.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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
--
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

Cannot compile media_build from git sources

[Bogus Zaba]

I am trying to compile the media_build according to the instructions on 
this page:

http://git.linuxtv.org/media_build.git

Instructions are very clear and all seems to work well regarding 
download of sources and the build command initiates compilation which 
runs OK until I get to the following stage:


/root/Add_SW/other/media_build/v4l/radio-rtrack2.c: In function 
'rtrack2_alloc':
/root/Add_SW/other/media_build/v4l/radio-rtrack2.c:46:2: error: implicit 
declaration of function 'kzalloc'
/root/Add_SW/other/media_build/v4l/radio-rtrack2.c:46:2: warning: return 
makes pointer from integer without a cast

make[3]: *** [/root/Add_SW/other/media_build/v4l/radio-rtrack2.o] Error 1
make[2]: *** [_module_/root/Add_SW/other/media_build/v4l] Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.37.6'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/root/Add_SW/other/media_build/v4l'
make: *** [all] Error 2
build failed at ./build line 410.

This looks like a source code error which causes the compilation to fail.

Am I doing something obviously wrong or is there indeed a souce code 
error here?


Many thanks

Bogus N Zaba
--
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: Using MT9P031 digital sensor

[Joshua Hintze]

Gary,

On Mon, Mar 26, 2012 at 10:32 AM, Gary Thomas g...@mlbassoc.com wrote:
 On 2012-03-26 09:37, Joshua Hintze wrote:

 Gary,

 I'm using linux branch from 2.6.39

 Fetch URL: git://www.sakoman.com/git/linux-omap-2.6
 branch: omap-2.6.39

 I'm using an overo board so I figured I should follow Steve Sakoman's
 repository.

 Which brings up another question, would you recommend going off of one
 of Laurent's repo's and if so which one?


 The last time I tried Laurent's repo, it did not have the UYVY support in
 the OMAP3ISP/CCDC merged in.  I don't know if that has changed recently.



I've been able to use UYVY and YUYV with the kernel that I mentioned.
So I would assume it should be in since my kernel is an older version
of the omap3isp driver



 On Mon, Mar 26, 2012 at 9:25 AM, Gary Thomasg...@mlbassoc.com  wrote:

 On 2012-03-25 23:13, Joshua Hintze wrote:


 Alright I made some progress on this.

 I can access the Mt9p031 registers that are exposed using a command such
 as

 ./yavta -l /dev/v4l-subdev8 to list the available controls. Then I can
 set the exposure and analog gain with
 ./yavta --set-control '0x00980911 1500' /dev/v4l-subdev8--- This
 seems to give the desired effect.

 Note that ./yavta -w (short option for --set-control) gives a seg
 fault for me. Possible bug in yavta??

 Now I'm working on fixing the white balance. In my office the
 incandescent light bulbs give off a yellowish tint late at night. I've
 been digging through the omap3isp code to figure out how to enable the
 automatic white balance. I was able to find the private IOCTLs for the
 previewer and I was able to use VIDIOC_OMAP3ISP_PRV_CFG. Using this
 IOCTL I adjusted the OMAP3ISP_PREV_WB, OMAP3ISP_PREV_BLKADJ, and
 OMAP3ISP_PREV_RGB2RGB.

 Since I wasn't sure where to start on adjusting these values I just
 set them all to the TRM's default register values. However when I did
 so a strange thing occurred. What I saw was all the colors went to a
 decent color. I'm curious if anybody can shed some light on the best
 way to get a high quality image. Ideally if I could just set a bit for
 auto white balance and auto exposure that could be good too.



 Just curious - what codebase (git URL) are you using?

 On Fri, Mar 23, 2012 at 1:01 PM, Joshua Hintzejoshua.hin...@gmail.com
  wrote:


 Sorry to bring up this old message list. I was curious when you spoke
 about the ISP preview engine being able to adjust the white balance.

 When I enumerate the previewer's available controls all I see is...

 root@overo:~# ./yavta -l /dev/v4l-subdev3
 --- User Controls (class 0x00980001) ---
 control 0x00980900 `Brightness' min 0 max 255 step 1 default 0 current
 0.
 control 0x00980901 `Contrast' min 0 max 255 step 1 default 16 current
 16.
 2 controls found.


 Is this what you are referring to? Are there other settings I can
 adjust to get the white balance and focus better using the  OMAP3 ISP
 AWEB/OMAP3 ISP AF?

 Thanks,

 Josh




 Hi Gary,

 On Wednesday 30 November 2011 18:00:55 Gary Thomas wrote:


 On 2011-11-30 07:57, Gary Thomas wrote:


 On 2011-11-30 07:30, Laurent Pinchart wrote:


 On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote:



 [snip]

 This sort of works(*), but I'm still having issues (at least I can
 move
 frames!) When I configure the pipeline like this:
 media-ctl -r
 media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]'
 media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'
 media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'
 media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer
 output:0[1]'
 media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]'
 media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]'
 media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]'
 media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]'
 media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]'
 media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]'
 the resulting frames are 24 bytes each instead of 654720

 When I tried to grab from the previewer, the frames were 9969120
 instead of 9961380

 Any ideas what resolution is actually being moved through?



 Because the OMAP3 ISP has alignment requirements. Both the preview
 engine and the resizer output line lenghts must be multiple of 32
 bytes. The driver adds padding at end of lines when the output width
 isn't a multiple of 16 pixels.



 Any guess which resolution(s) I should change and to what?



 I changed the resizer output to be 672x496 and was able to capture
 video
 using ffmpeg.

 I don't know what to expect with this sensor (I've never seen it in
 use
 before), but the image seems to have color balance issues - it's awash
 in
 a green hue.  It may be the poor lighting in my office...  I did try
 the
 9
 test patterns which I was able to select via
    # v4l2-ctl -d /dev/v4l-subdev8 --set-ctrl=test_pattern=N
 and these looked OK.  You can see them at
 http://www.mlbassoc.com/misc/mt9p031_images/



 Neither the sensor nor the OMAP3 ISP implement automatic white balance.
 The
 

Re: Hauppauge WinTV HVR 930C-HD - new USB ID 2040:b130 ?

[Ezequiel García]

On 3/26/12, Neumann, Steffen sneum...@ipb-halle.de wrote:
 Not the answer I was looking for,
 But thanks everybody for the clarification.
 I'll try to register for the wiki and add

I guess as a customer you could also contact the vendors
and ask to support the device. Can't hurt, right?
--
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: Using MT9P031 digital sensor

[Laurent Pinchart]

Hi Joshua,

On Monday 26 March 2012 09:44:52 Joshua Hintze wrote:
 On Mon, Mar 26, 2012 at 2:25 AM, Laurent Pinchart wrote:
  On Sunday 25 March 2012 23:13:02 Joshua Hintze wrote:

[snip]

  Now I'm working on fixing the white balance. In my office the
  incandescent light bulbs give off a yellowish tint late at night. I've
  been digging through the omap3isp code to figure out how to enable the
  automatic white balance. I was able to find the private IOCTLs for the
  previewer and I was able to use VIDIOC_OMAP3ISP_PRV_CFG. Using this IOCTL
  I adjusted the OMAP3ISP_PREV_WB, OMAP3ISP_PREV_BLKADJ, and
  OMAP3ISP_PREV_RGB2RGB.
  
  Since I wasn't sure where to start on adjusting these values I just set
  them all to the TRM's default register values. However when I did so a
  strange thing occurred. What I saw was all the colors went to a decent
  color. I'm curious if anybody can shed some light on the best way to get
  a high quality image. Ideally if I could just set a bit for auto white
  balance and auto exposure that could be good too.
  
  The ISP doesn't implement automatic white balance. It can apply white
  balancing (as well as other related processing), but computing values for
  those parameters needs to be performed in userspace. The ISP statistics
  engine engine can help speeding up the process, but the AEWB algorithm
  must be implemented in your application.
 
 Dang, I'll have to look up some AEWB algorithms.

I will publish sample code soon (likely in a couple of weeks, could be a bit 
before).

 I'm curious why TI would have this register bit then (AEW_EN bit 15 in
 H3A_PCR)?

That bit enables the AEWB statistics collection, not an AEWB algorithm.

 Is this the same for auto focus and auto exposure? Meaning that I'll need to
 get information from the histogram/statistics to adjust focus and exposure
 times?

That's right.

-- 
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: Using MT9P031 digital sensor

[Joshua Hintze]

Laurent,

On Mon, Mar 26, 2012 at 11:38 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Joshua,

 On Monday 26 March 2012 09:44:52 Joshua Hintze wrote:
 On Mon, Mar 26, 2012 at 2:25 AM, Laurent Pinchart wrote:
  On Sunday 25 March 2012 23:13:02 Joshua Hintze wrote:

 [snip]

 Dang, I'll have to look up some AEWB algorithms.

 I will publish sample code soon (likely in a couple of weeks, could be a bit
 before).


Great! I look forward to it.

Thanks,

Josh
--
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] omap3isp: preview: Shorten shadow update delay

[Laurent Pinchart]

Hi Sakari,

On Monday 26 March 2012 19:23:23 Sakari Ailus wrote:
 On Mon, Mar 26, 2012 at 04:42:31PM +0200, Laurent Pinchart wrote:
  When applications modify preview engine parameters, the new values are
  applied to the hardware by the preview engine interrupt handler during
  vertical blanking. If the parameters are being changed when the
  interrupt handler is called, it just delays applying the parameters
  until the next frame.
  
  If an application modifies the parameters for every frame, and the
  preview engine interrupt is triggerred synchronously, the parameters are
  never applied to the hardware.
  
  Fix this by storing new parameters in a shadow copy, and replace the
  active parameters with the shadow values atomically.

[snip]

  @@-886,20 +896,24@@ static int preview_config(struct isp_prev_device*prev,
struct omap3isp_prev_update_config *cfg)
   {
  struct prev_params *params;
  +   struct prev_params *shadow;
  struct preview_update *attr;
  +   unsigned long flags;
  int i, bit, rval = 0;
  
  -   params = prev-params;
  if (cfg-update == 0)
  return 0;
  
  -   if (prev-state != ISP_PIPELINE_STREAM_STOPPED) {
  -   unsigned long flags;
  +   params = kmalloc(sizeof(*params), GFP_KERNEL);
  +   if (params == NULL)
  +   return -ENOMEM;
  
  -   spin_lock_irqsave(prev-lock, flags);
  -   prev-shadow_update = 1;
  -   spin_unlock_irqrestore(prev-lock, flags);
  -   }
  +   spin_lock_irqsave(prev-params.lock, flags);
  +   memcpy(params, prev-params.shadow ? : prev-params.active,
  +  sizeof(*params));
  +   spin_unlock_irqrestore(prev-params.lock, flags);
  +
  +   params-update = 0;
  
  for (i = 0; i  ARRAY_SIZE(update_attrs); i++) {
  
  attr = update_attrs[i];
 
 I think it's partly a matter of taste but --- would you think it'd make
 sense to allocate the another configuration structure statically? I didn't
 check the actual size of the configuration but it seems to be pretty big.
 Handling allocation failures in applications is a nuisance, but also
 allocating such largish chunks to just to be on the safe side doesn't sound
 very appealing either.

I'd like that better as well, but then we'll run into the same issue that this 
patch tries to fix. I'll try to find a better solution.

 Say, if you're capturing a photo and you allocation fails here. Should you
 just retry it a few times, or fail immediately? Random allocation failures
 are not unforeseen even on systems with plenty of memory. Not that it should
 work this way I guess...
 
 Have you checked what's the size of this struct btw.?

It's big. Around 16k if I'm not mistaken.

-- 
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

cron job: media_tree daily build: ERRORS

[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:Mon Mar 26 19:00:16 CEST 2012
git hash:f92c97c8bd77992ff8bd6ef29a23dc82dca799cb
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: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
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: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
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/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.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: dvb-c usb device for linux

[Claus Olesen]

Just a remark for anyone else interested with a hybrid device that
there now is a specific utility dvb-fe-tool as I discovered to be part
of the next release of the v4l-utils package to set the delivery
system type fx dvb-c or dvb-t. I'm having it called from
/etc/rc.d/rc.local to have the type set on bootup (overwriting the
default set by a driver/module?) until perhaps someday kaffeine can do
it based on a configuration option.
--
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: Cannot compile media_build from git sources

[Joe Henley]

Bogus,

This is the same problem I wrote about on March 21, 2012.  I have 
received no reply so far.


You can try to work around the problem as I did:
-- This assumes you don't need radio-rtrack2.
-- Look at the build command.  Near the end are two make commands. 
Comment out the last one.
-- Run the resulting build.  Then go into ../media_build/v4l/.config 
Set the radio-rtrack2 to n (from m).
-- Then go back to the directory which has the build program and just 
run make .. if all runs OK, then run make install.


Good luck!

Joe Henley
--
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] omap3isp: preview: Shorten shadow update delay

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:

On Monday 26 March 2012 19:23:23 Sakari Ailus wrote:

On Mon, Mar 26, 2012 at 04:42:31PM +0200, Laurent Pinchart wrote:

When applications modify preview engine parameters, the new values are
applied to the hardware by the preview engine interrupt handler during
vertical blanking. If the parameters are being changed when the
interrupt handler is called, it just delays applying the parameters
until the next frame.

If an application modifies the parameters for every frame, and the
preview engine interrupt is triggerred synchronously, the parameters are
never applied to the hardware.

Fix this by storing new parameters in a shadow copy, and replace the
active parameters with the shadow values atomically.


[snip]


@@-886,20 +896,24@@ static int preview_config(struct isp_prev_device*prev,
  struct omap3isp_prev_update_config *cfg)
  {
struct prev_params *params;
+   struct prev_params *shadow;
struct preview_update *attr;
+   unsigned long flags;
int i, bit, rval = 0;

-   params =prev-params;
if (cfg-update == 0)
return 0;

-   if (prev-state != ISP_PIPELINE_STREAM_STOPPED) {
-   unsigned long flags;
+   params = kmalloc(sizeof(*params), GFP_KERNEL);
+   if (params == NULL)
+   return -ENOMEM;

-   spin_lock_irqsave(prev-lock, flags);
-   prev-shadow_update = 1;
-   spin_unlock_irqrestore(prev-lock, flags);
-   }
+   spin_lock_irqsave(prev-params.lock, flags);
+   memcpy(params, prev-params.shadow ? : prev-params.active,
+  sizeof(*params));
+   spin_unlock_irqrestore(prev-params.lock, flags);
+
+   params-update = 0;

for (i = 0; i  ARRAY_SIZE(update_attrs); i++) {

attr =update_attrs[i];


I think it's partly a matter of taste but --- would you think it'd make
sense to allocate the another configuration structure statically? I didn't
check the actual size of the configuration but it seems to be pretty big.
Handling allocation failures in applications is a nuisance, but also
allocating such largish chunks to just to be on the safe side doesn't sound
very appealing either.


I'd like that better as well, but then we'll run into the same issue that this
patch tries to fix. I'll try to find a better solution.


Say, if you're capturing a photo and you allocation fails here. Should you
just retry it a few times, or fail immediately? Random allocation failures
are not unforeseen even on systems with plenty of memory. Not that it should
work this way I guess...

Have you checked what's the size of this struct btw.?


It's big. Around 16k if I'm not mistaken.


As this is only 16 kiB, I'd go with a static allocation.

In the long run such allocations should be done dynamically when the 
first user accesses the device. I guess this isn't the only struct of 
its kind so likely more than 16 kiB would be gained by making the 
allocation depend on actual users.


We could also use vmalloc() instead --- this memory doesn't have to be 
physically contiguous. It would fix in-ioctl allocation but on the 
expense on larger (I suppose) allocation time, so I still wouldn't do it 
on every ioctl.


Albeit I feel it wouldn't be much of a job. One function call to preview 
code in both isp_get() / isp_put() mostly plus a bit of error handling, 
instead of omap3isp_preview_init() / omap3isp_preview_cleanup()?


Still, I'm fine with introducing dynamic allocation later on.

Cheers,

--
Sakari Ailus
sakari.ai...@iki.fi
--
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 : AverTV Volar HD PRO : a return case.

[Sril]

Hi,

Ianswer to mysel to say that I finally have a working 07ca:a835 under 3.0.26 
kernel with xgazza_af9035 patch.
The one for 3.2.x crash part of kernel and I still have I2C regs that can not 
be read.

So, what tools must do I work on : patch for v4l (build_media) or patch for 
kernel from xgazza or af903x driver or whatever ?
Which one is under active building ?

Thanks for reply.

Best regards.
See ya.



 Hi,

 I acquire this usb stick 07ca:a835 and it's still does not work properly. 
 Now, with the af9035 patch from  
 http://openpli.git.sourceforge.net/git/gitweb.cgi?p=openpli/openembedded;a=blob_plain;f=recipes/linux/linux-etxx00/dvb-usb-af9035.patch;hb=HEAD
  the tv interface is recognize but have trouble with kaffeine, tvtime and 
 gnome-dvb-daemon. Here's a trace from gnome : af9033: I2C 

 read failed reg:0047.

 From kaffeine : kaffeine(3817) DvbDevice::frontendEvent: tuning failed. 
 From tvtime, nothing card doesn't appear : probably missing conf, it's ok. 
 This message try to follow Andrej 

 Podzimekand Gianluca Gennari's messages on 02/07/2012. Does someone got ideas 
 about what to do to correct this ? kernel : 3.2.11 with patch noticed. No 
 externe v4l at all during construct. 

 Compile fine : Mar 18 16:09:43 localhost kernel: [  305.726981] dvb-usb: 
 found a 'Avermedia AverTV Volar HD  HD PRO (A835)' in cold state, will try 
 to load a firmware
 Mar 18 16:09:43 localhost kernel: [  305.742050] dvb-usb: downloading 
 firmware from file 'dvb-usb-af9035-01.fw'
 Mar 18 16:09:43 localhost kernel: [  306.039886] dvb-usb: found a 'Avermedia 
 AverTV Volar HD  HD PRO (A835)' in warm state.
 Mar 18 16:09:43 localhost kernel: [  306.040032] dvb-usb: will pass the 
 complete MPEG2 transport stream to the software demuxer.
 Mar 18 16:09:43 localhost kernel: [  306.040406] DVB: registering new adapter 
 (Avermedia AverTV Volar HD  HD PRO (A835))
 Mar 18 16:09:43 localhost kernel: [  306.078104] af9033: firmware version: 
 LINK:11.15.10.0 OFDM:5.48.10.0
 Mar 18 16:09:43 localhost kernel: [  306.080355] DVB: registering adapter 0 
 frontend 0 (Afatech AF9033 DVB-T)...
 Mar 18 16:09:43 localhost kernel: [  306.129981] tda18218: NXP TDA18218HN 
 successfully identified.
 Mar 18 16:09:43 localhost kernel: [  306.131483] dvb-usb: Avermedia AverTV 
 Volar HD  HD PRO (A835) successfully initialized and connected.
 Mar 18 16:09:43 localhost kernel: [  306.140531] usbcore: registered new 
 interface driver dvb_usb_af9035 Best regards.
 See ya.

--
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