date:20110531

Re: v4l2 device property framework in userspace

2011-05-31 Thread Kim, HeungJun

Hi Martin,

I'm not an expert of V4L2 and this camera sensor, too.
But, if you don't mind, I want to leave some comments about the registers,
and I hope that it helps you.

2011-05-30 오후 9:07, Martin Strubel 쓴 글:
 Hi Hans,
 

 Can you give examples of the sort of things that are in those registers?
 Is that XML file available somewhere? Are there public datasheets?

 
 If you mean the sensor datasheets, many of them are buried behind NDAs,
 but people are writing opensourced headers too...let's leave this to the
 lawyers.
 
 Here's an example: http://section5.ch/downloads/mt9d111.xml
 The XSLT sheets to generate code from it are found in the netpp
 distribution, see http://www.section5.ch/netpp. You might have to read
 some of the documentation to get to the actual clues.
As you said, obviously this camera has a lot of registers.
But, IMHO, even it can be expressed by one subdev driver like any other ones.
Almost registers can be absorbed and adapted at the start(or booting) time.
And the most others also can be defined at the current V4L2 APIs.
(like controls, croppings, buffers, powers, etc)

The matter is to find which factor can vary, when the camera setting is varied
by the board as you said. And in just my short thinking, this is not much to
catch. If there are such things, not expressed using current V4L2 APIs, but
needed for your works or your board, you can submit this APIs to ML.

The best thing is, you collect such things(it can be express current V4L2 APIs),
and submit new V4L2 APIs, because there are many other people handling camera
driver like you, and they can think similary like you.
For sure, they can welcome to birth new APIs.


Cheers,
Heungjun Kim
--
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: [linux-dvb] XC4000 patches for kernel 2.6.37.2

2011-05-31 Thread Dmitri Belimov

Hi Devin

 On Mon, May 30, 2011 at 10:48 PM, Dmitri Belimov
 d.beli...@gmail.com wrote:
  Hi
 
  Hi Istvan
 
        I am sending you modified patches for kernel 2.6.37.2, they
  works as expected.
 
  First apply kernel_xc4000.diff (your patch) then
  kernel_dtv3200h.diff for Leadtek DTV3200 XC4000 support.
 
  Can you resend your patches with right Signed-Off string for commit
  into kernel?
 
  With my best regards, Dmitry.
 
 He cannot offer a Signed-off-by for the entire patch - it's not his
 code.  The patches are based on the work that Davide Ferri and I did
 about 17 months ago:
 
 http://kernellabs.com/hg/~dheitmueller/pctv-340e-2/shortlog
 
 I'm not against seeing the xc4000 support going in, but the history
 needs to be preserved, which means it needs to be broken in to a patch
 series that properly credits my and Davide's work.

Is it possible make some patches and add support xc4000 into kernel?

With my best regards, Dmitry.
 
 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

[PATCH v2 0/4] Fix micellaneous issues for M-5MOLS driver

2011-05-31 Thread HeungJun, Kim

Hello,

This is second verion of patch series to handle some issues about M-5MOLS
driver.

The difference against first patch series is as follows:

1) Add contents for 1/5.
It should be the contents in the each patches, but I've missed it.
So, I added the contents in the patch.

2) Discard 4/5 about changing m5mols_capture_error_handler()'s name.
When I saw the comments about timeout variable, I agreed to Sakari's
comments, and I would remove this. But, after thiking about that,
It's better not to remove the timeout, and to add more comments
about this functions's role for making more clearly.

But, it occurs more confuseness and looks like inconsistent and
impolite. If this patch gives confuseness to you, I apologize for
that. It was not my inttention.

So, my conclusion is to discard 4/5 patch for keeping the previous one.

Thanks, and any comments welcome.

Regards,
Heungjun Kim

--
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/4] m5mols: add m5mols_read_u8/u16/u32() according to I2C byte width

2011-05-31 Thread HeungJun, Kim

For now, the m5mols_read() share in case of I2C packet 1, 2, 4 byte(s) width.
So, this commit adds 3 functions - m5mols_read_u8/u16/u32() according to byte
width of I2C packet. And, the u32 variables in spite of u8 or u16 for fitting
to m5mols_read() having no choice, is replaced to have original byte width
like u8, u16, u32 as same reason.

Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols.h  |   52 +++---
 drivers/media/video/m5mols/m5mols_capture.c  |   18 +++---
 drivers/media/video/m5mols/m5mols_controls.c |2 +-
 drivers/media/video/m5mols/m5mols_core.c |   96 ++
 4 files changed, 104 insertions(+), 64 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols.h 
b/drivers/media/video/m5mols/m5mols.h
index 10b55c8..dbe8928 100644
--- a/drivers/media/video/m5mols/m5mols.h
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -106,23 +106,23 @@ struct m5mols_capture {
  * The each value according to each scenemode is recommended in the documents.
  */
 struct m5mols_scenemode {
-   u32 metering;
-   u32 ev_bias;
-   u32 wb_mode;
-   u32 wb_preset;
-   u32 chroma_en;
-   u32 chroma_lvl;
-   u32 edge_en;
-   u32 edge_lvl;
-   u32 af_range;
-   u32 fd_mode;
-   u32 mcc;
-   u32 light;
-   u32 flash;
-   u32 tone;
-   u32 iso;
-   u32 capt_mode;
-   u32 wdr;
+   u8 metering;
+   u8 ev_bias;
+   u8 wb_mode;
+   u8 wb_preset;
+   u8 chroma_en;
+   u8 chroma_lvl;
+   u8 edge_en;
+   u8 edge_lvl;
+   u8 af_range;
+   u8 fd_mode;
+   u8 mcc;
+   u8 light;
+   u8 flash;
+   u8 tone;
+   u8 iso;
+   u8 capt_mode;
+   u8 wdr;
 };
 
 /**
@@ -216,9 +216,9 @@ struct m5mols_info {
bool lock_ae;
bool lock_awb;
u8 resolution;
-   u32 interrupt;
-   u32 mode;
-   u32 mode_save;
+   u8 interrupt;
+   u8 mode;
+   u8 mode_save;
int (*set_power)(struct device *dev, int on);
 };
 
@@ -256,9 +256,11 @@ struct m5mols_info {
  *   +---+---+--+-+--+--+--+--+
  *   - d[0..3]: according to size1
  */
-int m5mols_read(struct v4l2_subdev *sd, u32 reg_comb, u32 *val);
+int m5mols_read_u8(struct v4l2_subdev *sd, u32 reg_comb, u8 *val);
+int m5mols_read_u16(struct v4l2_subdev *sd, u32 reg_comb, u16 *val);
+int m5mols_read_u32(struct v4l2_subdev *sd, u32 reg_comb, u32 *val);
 int m5mols_write(struct v4l2_subdev *sd, u32 reg_comb, u32 val);
-int m5mols_busy(struct v4l2_subdev *sd, u8 category, u8 cmd, u32 value);
+int m5mols_busy(struct v4l2_subdev *sd, u8 category, u8 cmd, u8 value);
 
 /*
  * Mode operation of the M-5MOLS
@@ -280,12 +282,12 @@ int m5mols_busy(struct v4l2_subdev *sd, u8 category, u8 
cmd, u32 value);
  * The available executing order between each modes are as follows:
  *   PARAMETER --- MONITOR --- CAPTURE
  */
-int m5mols_mode(struct m5mols_info *info, u32 mode);
+int m5mols_mode(struct m5mols_info *info, u8 mode);
 
-int m5mols_enable_interrupt(struct v4l2_subdev *sd, u32 reg);
+int m5mols_enable_interrupt(struct v4l2_subdev *sd, u8 reg);
 int m5mols_sync_controls(struct m5mols_info *info);
 int m5mols_start_capture(struct m5mols_info *info);
-int m5mols_do_scenemode(struct m5mols_info *info, u32 mode);
+int m5mols_do_scenemode(struct m5mols_info *info, u8 mode);
 int m5mols_lock_3a(struct m5mols_info *info, bool lock);
 int m5mols_set_ctrl(struct v4l2_ctrl *ctrl);
 
diff --git a/drivers/media/video/m5mols/m5mols_capture.c 
b/drivers/media/video/m5mols/m5mols_capture.c
index d71a390..751f459 100644
--- a/drivers/media/video/m5mols/m5mols_capture.c
+++ b/drivers/media/video/m5mols/m5mols_capture.c
@@ -58,9 +58,9 @@ static int m5mols_read_rational(struct v4l2_subdev *sd, u32 
addr_num,
 {
u32 num, den;
 
-   int ret = m5mols_read(sd, addr_num, num);
+   int ret = m5mols_read_u32(sd, addr_num, num);
if (!ret)
-   ret = m5mols_read(sd, addr_den, den);
+   ret = m5mols_read_u32(sd, addr_den, den);
if (ret)
return ret;
*val = den == 0 ? 0 : num / den;
@@ -99,20 +99,20 @@ static int m5mols_capture_info(struct m5mols_info *info)
if (ret)
return ret;
 
-   ret = m5mols_read(sd, EXIF_INFO_ISO, (u32 *)exif-iso_speed);
+   ret = m5mols_read_u16(sd, EXIF_INFO_ISO, exif-iso_speed);
if (!ret)
-   ret = m5mols_read(sd, EXIF_INFO_FLASH, (u32 *)exif-flash);
+   ret = m5mols_read_u16(sd, EXIF_INFO_FLASH, exif-flash);
if (!ret)
-   ret = m5mols_read(sd, EXIF_INFO_SDR, (u32 *)exif-sdr);
+   ret = m5mols_read_u16(sd, EXIF_INFO_SDR, exif-sdr);
if (!ret)
-   ret = m5mols_read(sd, EXIF_INFO_QVAL, (u32 *)exif-qval);
+   ret = m5mols_read_u16(sd, EXIF_INFO_QVAL, exif-qval);

[PATCH v2 3/4] m5mols: remove union in the m5mols_get_version(), and VERSION_SIZE

2011-05-31 Thread HeungJun, Kim

Remove union version in the m5mols_get_version(), and read version information
directly. Also remove VERSION_SIZE.

Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols.h  |1 -
 drivers/media/video/m5mols/m5mols_core.c |   42 +++---
 drivers/media/video/m5mols/m5mols_reg.h  |   13 -
 3 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols.h 
b/drivers/media/video/m5mols/m5mols.h
index dbe8928..9ae1709 100644
--- a/drivers/media/video/m5mols/m5mols.h
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -154,7 +154,6 @@ struct m5mols_version {
u8  str[VERSION_STRING_SIZE];
u8  af;
 };
-#define VERSION_SIZE sizeof(struct m5mols_version)
 
 /**
  * struct m5mols_info - M-5MOLS driver data structure
diff --git a/drivers/media/video/m5mols/m5mols_core.c 
b/drivers/media/video/m5mols/m5mols_core.c
index 2b1f23f..8ccab95 100644
--- a/drivers/media/video/m5mols/m5mols_core.c
+++ b/drivers/media/video/m5mols/m5mols_core.c
@@ -386,33 +386,33 @@ int m5mols_mode(struct m5mols_info *info, u8 mode)
 static int m5mols_get_version(struct v4l2_subdev *sd)
 {
struct m5mols_info *info = to_m5mols(sd);
-   union {
-   struct m5mols_version ver;
-   u8 bytes[VERSION_SIZE];
-   } version;
-   u8 cmd = CAT0_VER_CUSTOMER;
+   struct m5mols_version *ver = info-ver;
+   u8 *str = ver-str;
+   int i;
int ret;
 
-   do {
-   ret = m5mols_read_u8(sd, SYSTEM_CMD(cmd), version.bytes[cmd]);
-   if (ret)
-   return ret;
-   } while (cmd++ != CAT0_VER_AWB);
+   ret = m5mols_read_u8(sd, SYSTEM_VER_CUSTOMER, ver-customer);
+   if (!ret)
+   ret = m5mols_read_u8(sd, SYSTEM_VER_PROJECT, ver-project);
+   if (!ret)
+   ret = m5mols_read_u16(sd, SYSTEM_VER_FIRMWARE, ver-fw);
+   if (!ret)
+   ret = m5mols_read_u16(sd, SYSTEM_VER_HARDWARE, ver-hw);
+   if (!ret)
+   ret = m5mols_read_u16(sd, SYSTEM_VER_PARAMETER, ver-param);
+   if (!ret)
+   ret = m5mols_read_u16(sd, SYSTEM_VER_AWB, ver-awb);
+   if (!ret)
+   ret = m5mols_read_u8(sd, AF_VERSION, ver-af);
+   if (ret)
+   return ret;
 
-   do {
-   ret = m5mols_read_u8(sd, SYSTEM_VER_STRING, 
version.bytes[cmd]);
+   for (i = 0; i  VERSION_STRING_SIZE; i++) {
+   ret = m5mols_read_u8(sd, SYSTEM_VER_STRING, str[i]);
if (ret)
return ret;
-   if (cmd = VERSION_SIZE - 1)
-   return -EINVAL;
-   } while (version.bytes[cmd++]);
-
-   ret = m5mols_read_u8(sd, AF_VERSION, version.bytes[cmd]);
-   if (ret)
-   return ret;
+   }
 
-   /* store version information swapped for being readable */
-   info-ver   = version.ver;
info-ver.fw= be16_to_cpu(info-ver.fw);
info-ver.hw= be16_to_cpu(info-ver.hw);
info-ver.param = be16_to_cpu(info-ver.param);
diff --git a/drivers/media/video/m5mols/m5mols_reg.h 
b/drivers/media/video/m5mols/m5mols_reg.h
index 8260f50..5f5bdcf 100644
--- a/drivers/media/video/m5mols/m5mols_reg.h
+++ b/drivers/media/video/m5mols/m5mols_reg.h
@@ -56,13 +56,24 @@
  * more specific contents, see definition if file m5mols.h.
  */
 #define CAT0_VER_CUSTOMER  0x00/* customer version */
-#define CAT0_VER_AWB   0x09/* Auto WB version */
+#define CAT0_VER_PROJECT   0x01/* project version */
+#define CAT0_VER_FIRMWARE  0x02/* Firmware version */
+#define CAT0_VER_HARDWARE  0x04/* Hardware version */
+#define CAT0_VER_PARAMETER 0x06/* Parameter version */
+#define CAT0_VER_AWB   0x08/* Auto WB version */
 #define CAT0_VER_STRING0x0a/* string including M-5MOLS */
 #define CAT0_SYSMODE   0x0b/* SYSTEM mode register */
 #define CAT0_STATUS0x0c/* SYSTEM mode status register */
 #define CAT0_INT_FACTOR0x10/* interrupt pending register */
 #define CAT0_INT_ENABLE0x11/* interrupt enable register */
 
+#define SYSTEM_VER_CUSTOMERI2C_REG(CAT_SYSTEM, CAT0_VER_CUSTOMER, 1)
+#define SYSTEM_VER_PROJECT I2C_REG(CAT_SYSTEM, CAT0_VER_PROJECT, 1)
+#define SYSTEM_VER_FIRMWAREI2C_REG(CAT_SYSTEM, CAT0_VER_FIRMWARE, 2)
+#define SYSTEM_VER_HARDWAREI2C_REG(CAT_SYSTEM, CAT0_VER_HARDWARE, 2)
+#define SYSTEM_VER_PARAMETER   I2C_REG(CAT_SYSTEM, CAT0_VER_PARAMETER, 2)
+#define SYSTEM_VER_AWB I2C_REG(CAT_SYSTEM, CAT0_VER_AWB, 2)
+
 #define SYSTEM_SYSMODE I2C_REG(CAT_SYSTEM, CAT0_SYSMODE, 1)
 #define REG_SYSINIT0x00/* SYSTEM mode */
 #define REG_PARAMETER  0x01/* PARAMETER mode */
-- 
1.7.0.4

--
To unsubscribe from this list: send

[PATCH v2 4/4] m5mols: add parenthesis for the head and back of email address

2011-05-31 Thread HeungJun, Kim

Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols.h  |4 ++--
 drivers/media/video/m5mols/m5mols_capture.c  |4 ++--
 drivers/media/video/m5mols/m5mols_controls.c |4 ++--
 drivers/media/video/m5mols/m5mols_core.c |4 ++--
 drivers/media/video/m5mols/m5mols_reg.h  |4 ++--
 include/media/m5mols.h   |4 ++--
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols.h 
b/drivers/media/video/m5mols/m5mols.h
index 9ae1709..89d09a8 100644
--- a/drivers/media/video/m5mols/m5mols.h
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -2,10 +2,10 @@
  * Header for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/media/video/m5mols/m5mols_capture.c 
b/drivers/media/video/m5mols/m5mols_capture.c
index 751f459..d947192 100644
--- a/drivers/media/video/m5mols/m5mols_capture.c
+++ b/drivers/media/video/m5mols/m5mols_capture.c
@@ -2,10 +2,10 @@
  * The Capture code for Fujitsu M-5MOLS ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/media/video/m5mols/m5mols_controls.c 
b/drivers/media/video/m5mols/m5mols_controls.c
index d392c83..d135d20 100644
--- a/drivers/media/video/m5mols/m5mols_controls.c
+++ b/drivers/media/video/m5mols/m5mols_controls.c
@@ -2,10 +2,10 @@
  * Controls for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/media/video/m5mols/m5mols_core.c 
b/drivers/media/video/m5mols/m5mols_core.c
index 8ccab95..e2c8a10 100644
--- a/drivers/media/video/m5mols/m5mols_core.c
+++ b/drivers/media/video/m5mols/m5mols_core.c
@@ -2,10 +2,10 @@
  * Driver for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/media/video/m5mols/m5mols_reg.h 
b/drivers/media/video/m5mols/m5mols_reg.h
index 5f5bdcf..c755bd6 100644
--- a/drivers/media/video/m5mols/m5mols_reg.h
+++ b/drivers/media/video/m5mols/m5mols_reg.h
@@ -2,10 +2,10 @@
  * Register map for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/include/media/m5mols.h b/include/media/m5mols.h
index 2d7e7ca..aac2c0e 100644
--- a/include/media/m5mols.h
+++ b/include/media/m5mols.h
@@ -2,10 +2,10 @@
  * Driver header for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This

[PATCH v2 1/4] m5mols: Fix capture image size register definition

2011-05-31 Thread HeungJun, Kim

The main capture and the thumbnail image size registers were
erroneously defined to have 1 byte width, resulting in wrong
reported image size. Fix this by changing the registers width
to correct value.

Reported-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols_reg.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols_reg.h 
b/drivers/media/video/m5mols/m5mols_reg.h
index b83e36f..8260f50 100644
--- a/drivers/media/video/m5mols/m5mols_reg.h
+++ b/drivers/media/video/m5mols/m5mols_reg.h
@@ -382,8 +382,8 @@
 #define REG_CAP_START_MAIN 0x01
 #define REG_CAP_START_THUMB0x03
 
-#define CAPC_IMAGE_SIZEI2C_REG(CAT_CAPT_CTRL, 
CATC_CAP_IMAGE_SIZE, 1)
-#define CAPC_THUMB_SIZEI2C_REG(CAT_CAPT_CTRL, 
CATC_CAP_THUMB_SIZE, 1)
+#define CAPC_IMAGE_SIZEI2C_REG(CAT_CAPT_CTRL, 
CATC_CAP_IMAGE_SIZE, 4)
+#define CAPC_THUMB_SIZEI2C_REG(CAT_CAPT_CTRL, 
CATC_CAP_THUMB_SIZE, 4)
 
 /*
  * Category F - Flash
-- 
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: [beagleboard] [PATCH v4 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Koen Kooi


Op 30 mei 2011, om 10:37 heeft Javier Martin het volgende geschreven:

 Since isp clocks have not been exposed yet, this patch
 includes a temporal solution for testing mt9p031 driver
 in Beagleboard xM.

When compiling both as Y I get:

[4.231628] mt9p031 2-0048: Failed to reset the camera
[4.237030] omap3isp omap3isp: Failed to power on: -121
[4.242523] mt9p031 2-0048: Failed to power on device: -121
[4.248474] isp_register_subdev_group: Unable to register subdev mt9p031

regards,

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

Re: [beagleboard] [PATCH v4 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Koen Kooi


Op 31 mei 2011, om 09:52 heeft Koen Kooi het volgende geschreven:

 
 Op 30 mei 2011, om 10:37 heeft Javier Martin het volgende geschreven:
 
 Since isp clocks have not been exposed yet, this patch
 includes a temporal solution for testing mt9p031 driver
 in Beagleboard xM.
 
 When compiling both as Y I get:
 
 [4.231628] mt9p031 2-0048: Failed to reset the camera
 [4.237030] omap3isp omap3isp: Failed to power on: -121
 [4.242523] mt9p031 2-0048: Failed to power on device: -121
 [4.248474] isp_register_subdev_group: Unable to register subdev mt9p031

I tried on an xM rev A2 and xM rev C, same error on both
--
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: v4l2 device property framework in userspace

2011-05-31 Thread Hans Verkuil

On Monday, May 30, 2011 15:30:23 Martin Strubel wrote:
 Hi,
 
  
  The XML is basically just a dump of all the sensor registers, right?
  
 
 There are two sections: The register tables, and the property wrappers.
 Property wrappers don't have to necessarily link to registers, but
 that's covered in the docs.
 
  So you are not talking about 'properties', but about reading/setting
  registers directly. That's something that we do not support (or even want
  to support) except for debugging (see the VIDIOC_DBG_G/S_REGISTER ioctls
  which require root access).
  
 
 I guess I should elaborate:
 For the case, when the hardware is operation mode safe, i.e. you can
 set a value (like video format) in a register, you can wrap a property
 or ioctl directly into a register bit.
 For the case when it's not safe or more complex (i.e. you have to toggle
 a bit to actually enable the mode), you'll have to write handlers. It's
 up to you and the safety of the HW implementation, really.
 To the user, it's always just Properties. What you do internally, is
 up to you. With a non intelligent register design, you'll have to
 indeed write quite some handler code.
 Where the handler lives (userspace or kernel) is again up to you.
 
  
  But this is not a driver. This is just a mapping of symbols to registers.
  You are just moving the actual driver intelligence to userspace, making it
  very hard to reuse. It's a no-go I'm afraid.
  
 
 Actually no. IMHO, the kernel driver should not have all the
 intelligence (some might argue this contradicts the actual concept of a
 kernel).

Userspace tells the driver what it should do and the driver decides how to do 
it.
That's how it works.

 And for us it is even more reusable, because we can run the
 same thing on a standalone 'OS' (no OS really) and for example RTEMS.

That is never a consideration for linux. Hardware abstraction layers are not
allowed. Blame Linus, not me, although I completely agree with him on this.

 So for the various OS specifics, we only have one video acquisition
 driver which has no knowledge of the attached sensor. All generic v4l2
 properties again are tunneled through userspace to the sensor daemon.
 I still don't see what is (technically) wrong with that.

It's the tunneling to a sensor daemon that is wrong. You can write a sensor
driver as a V4L subdevice driver and it is reusable by any 'video acquisition;
driver (aka V4L2 bridge/platform driver) without going through userspace and
requiring userspace daemons.

 For me, it works like a driver, plus it is way more flexible as I don't
 have to go through ioctls for special sensor properties.

You still have to go through the kernel to set registers. That's just as
expensive as an ioctl.

 
  
  As mentioned a list of registers does not make a driver. Someone has to do
  the actual programming.
  
 
 Sure. This aspect is covered by the netpp getters/setters.
 
  recompile the kernel
  This is BTW a big issue for some embedded linux device vendors.
  So my question is still up, if there's room for userspace handlers for
  kernel events (ioctl requests). Our current hack is, to read events from
  a char device and push them through netpp.
  
  Well, no. The policy is to have kernel drivers and not userspace drivers.
  
  It's not just technical reasons, but also social reasons: suppose you have
  userspace drivers, who is going to maintain all those drivers? Ensure that
  they remain in sync, that new features can be added, etc.? That whole
  infrastructure already exists if you use kernel drivers.
 
 In the past we had a lot more work from each kernel release to update
 the kernel stuff because internals have been changing.

That's why you want to upstream drivers. Once it's upstream this work goes away.

 I don't see a problem maintaining the drivers, if you have lean  mean
 module interfaces. It creates a lot of work though, if you have to touch
 code over and over again (and this for each sensor implementation).
 If companies have to pay more for social reasons, they won't do it.
 But again, this is argued about elsewhere..
 
 I agree about an infrastructure, that's why I'm raising the discussion.
 
  
  Userspace drivers may be great in the short term and from the point of
  view of a single company/user, but it's a lot less attractive in the long
  term.
  
  Anyway, using subdevices and judicious use of controls it really shouldn't
  be that hard to create a kernel driver.
  
 
 I don't know. Up to now (speaking Linux v2.6.34) I couldn't be
 convinced, and none of our customers could, either.  I'm aware that
 there are some crazy requirements from the machine vision domain that
 are of no relevance to a typical Linux webcam.

Note that much of the functionality you need didn't go into the kernel
until 2.6.39.

 Anyhow, if you don't want to support a userspace layer policy, it's no
 problem to us. We can just release the dumb acquisition driver and
 everyone can register his stuff on top.

Sure, no

Re: v4l2 device property framework in userspace

2011-05-31 Thread Martin Strubel


 
 Userspace tells the driver what it should do and the driver decides how to do 
 it.
 That's how it works.

Sounds a little religious. Not sure if you've been listening..

 
 And for us it is even more reusable, because we can run the
 same thing on a standalone 'OS' (no OS really) and for example RTEMS.
 
 That is never a consideration for linux. Hardware abstraction layers are not
 allowed. Blame Linus, not me, although I completely agree with him on this.
 

This is new to me. What should be the reason not to abstract hardware?
To give people a coding job?

 So for the various OS specifics, we only have one video acquisition
 driver which has no knowledge of the attached sensor. All generic v4l2
 properties again are tunneled through userspace to the sensor daemon.
 I still don't see what is (technically) wrong with that.
 
 It's the tunneling to a sensor daemon that is wrong. You can write a sensor
 driver as a V4L subdevice driver and it is reusable by any 'video acquisition;
 driver (aka V4L2 bridge/platform driver) without going through userspace and
 requiring userspace daemons.
 

 It's the tunneling to a sensor daemon that is wrong. You can write a sensor
 driver as a V4L subdevice driver and it is reusable by any 'video acquisition;
 driver (aka V4L2 bridge/platform driver) without going through userspace and
 requiring userspace daemons.

You keep saying it is wrong, but I have so far seen no technically firm
argument. Please tell me why.

 
 For me, it works like a driver, plus it is way more flexible as I don't
 have to go through ioctls for special sensor properties.
 
 You still have to go through the kernel to set registers. That's just as
 expensive as an ioctl.
 


Not sure if you understand: I do not have to implement or generate ioctl
handlers and call them. This is definitely less expensive in terms of
coding. All the register access is handled *automatically* using the HW
description layer.

 
 Sure, no problem. It's open source after all. Just be aware that all the
 maintenance effort is for you as long as you remain out of tree.
 

We have to do this anyhow. But we'd prefer to do it the way that
requires least maintenance as described.
We need to have a *solution*. Not some academic hack that is not wrong.

I think we can end the discussion here. I was hoping for more
technically valuable input, really.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [beagleboard] [PATCH v4 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread javier Martin

On 31 May 2011 09:59, Koen Kooi k...@dominion.thruhere.net wrote:

 Op 31 mei 2011, om 09:52 heeft Koen Kooi het volgende geschreven:


 Op 30 mei 2011, om 10:37 heeft Javier Martin het volgende geschreven:

 Since isp clocks have not been exposed yet, this patch
 includes a temporal solution for testing mt9p031 driver
 in Beagleboard xM.

 When compiling both as Y I get:

 [    4.231628] mt9p031 2-0048: Failed to reset the camera
 [    4.237030] omap3isp omap3isp: Failed to power on: -121
 [    4.242523] mt9p031 2-0048: Failed to power on device: -121
 [    4.248474] isp_register_subdev_group: Unable to register subdev mt9p031

 I tried on an xM rev A2 and xM rev C, same error on both


Crap,
I get the same error here. Sorry for the inconvenience.
I'll send a new version in some minutes.

-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/2] Add support for mt9p031 Aptina (Micron) sensor.

2011-05-31 Thread Javier Martin

This patch adds basic support (no controls) for
mt9p031 sensor. It applies on kernel 2.6.39.

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 drivers/media/video/Kconfig   |7 +
 drivers/media/video/Makefile  |1 +
 drivers/media/video/mt9p031.c |  699 +
 include/media/mt9p031.h   |   11 +
 4 files changed, 718 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mt9p031.c
 create mode 100644 include/media/mt9p031.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..cb87e35 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,13 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
 
+config VIDEO_MT9P031
+   tristate Aptina MT9P031 support
+   depends on I2C  VIDEO_V4L2
+   ---help---
+This is a Video4Linux2 sensor-level driver for the Aptina
+(Micron) mt9p031 5 Mpixel camera.
+
 config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C  VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
 obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
 obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
 obj-$(CONFIG_VIDEO_SR030PC30)  += sr030pc30.o
 obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..61b46a0
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,699 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+#define MT9P031_PIXCLK_FREQ5400
+
+#define MT9P031_CHIP_VERSION   0x00
+#defineMT9P031_CHIP_VERSION_VALUE  0x1801
+#define MT9P031_ROW_START  0x01
+#defineMT9P031_ROW_START_MIN   1
+#defineMT9P031_ROW_START_MAX   2004
+#defineMT9P031_ROW_START_DEF   54
+#define MT9P031_COLUMN_START   0x02
+#defineMT9P031_COLUMN_START_MIN1
+#defineMT9P031_COLUMN_START_MAX2750
+#defineMT9P031_COLUMN_START_DEF16
+#define MT9P031_WINDOW_HEIGHT  0x03
+#defineMT9P031_WINDOW_HEIGHT_MIN   2
+#defineMT9P031_WINDOW_HEIGHT_MAX   2003
+#defineMT9P031_WINDOW_HEIGHT_DEF   2003
+#define MT9P031_WINDOW_WIDTH   0x04
+#defineMT9P031_WINDOW_WIDTH_MIN18
+#defineMT9P031_WINDOW_WIDTH_MAX2751
+#defineMT9P031_WINDOW_WIDTH_DEF2751
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN  2
+#defineMT9P031_OUTPUT_CONTROL_SYN  1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH  0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART  0x0b
+#define MT9P031_SHUTTER_DELAY  0x0c
+#define MT9P031_RST0x0d
+#defineMT9P031_RST_ENABLE  1
+#defineMT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE   0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+
+
+

[PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Javier Martin

Since isp clocks have not been exposed yet, this patch
includes a temporal solution for testing mt9p031 driver
in Beagleboard xM.

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 arch/arm/mach-omap2/Makefile   |1 +
 arch/arm/mach-omap2/board-omap3beagle-camera.c |   90 
 arch/arm/mach-omap2/board-omap3beagle.c|   55 ++
 3 files changed, 146 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..05cd983 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) += 
board-2430sdp.o \
   hsmmc.o
 obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
 obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
+  board-omap3beagle-camera.o \
   hsmmc.o
 obj-$(CONFIG_MACH_DEVKIT8000)  += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c 
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..04365b2
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,90 @@
+#include linux/gpio.h
+#include linux/regulator/machine.h
+
+#include plat/i2c.h
+
+#include media/mt9p031.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK   ISP_XCLK_A
+
+static struct regulator *reg_1v8, *reg_2v8;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+   struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+   int ret;
+
+   ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+   return 0;
+}
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+   /* Set RESET_BAR to !active */
+   gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+   return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+   .set_xclk   = beagle_cam_set_xclk,
+   .reset  = beagle_cam_reset,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+   I2C_BOARD_INFO(mt9p031, 0x48),
+   .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+   {
+   .board_info = mt9p031_camera_i2c_device,
+   .i2c_adapter_id = 2,
+   },
+   { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+   {
+   .subdevs = mt9p031_camera_subdevs,
+   .interface = ISP_INTERFACE_PARALLEL,
+   .bus = {
+   .parallel = {
+   .data_lane_shift = 0,
+   .clk_pol = 1,
+   .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+   }
+   },
+   },
+   { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+   .subdevs = beagle_camera_subdevs,
+};
+
+static int __init beagle_camera_init(void)
+{
+   reg_1v8 = regulator_get(NULL, cam_1v8);
+   if (IS_ERR(reg_1v8))
+   pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
+   else
+   regulator_enable(reg_1v8);
+
+   reg_2v8 = regulator_get(NULL, cam_2v8);
+   if (IS_ERR(reg_2v8))
+   pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
+   else
+   regulator_enable(reg_2v8);
+
+   omap_register_i2c_bus(2, 100, NULL, 0);
+   gpio_request(MT9P031_RESET_GPIO, cam_rst);
+   gpio_direction_output(MT9P031_RESET_GPIO, 0);
+   omap3_init_camera(beagle_isp_platform_data);
+   return 0;
+}
+late_initcall(beagle_camera_init);
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..c18d21c 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,12 +24,16 @@
 #include linux/input.h
 #include linux/gpio_keys.h
 #include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
 
 #include linux/mtd/mtd.h
 #include linux/mtd/partitions.h
 #include linux/mtd/nand.h
 #include linux/mmc/host.h
 
+#include linux/gpio.h
 #include linux/regulator/machine.h
 #include linux/i2c/twl.h
 
@@ -47,6 +51,7 @@
 #include plat/nand.h
 #include plat/usb.h
 #include plat/omap_device.h
+#include plat/i2c.h
 
 #include mux.h
 #include hsmmc.h
@@ -273,6 +278,44 @@ static struct regulator_consumer_supply beagle_vsim_supply 
= {
 
 static struct gpio_led gpio_leds[];
 
+static struct

[PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP

2011-05-31 Thread Amber Jain

Remove GFP_DMA from the __get_free_pages() call as ZONE_DMA is not configured
on OMAP. Earlier the page allocator used to return a page from ZONE_NORMAL
even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page allocator
returns null in such a scenario with a warning emitted to kernel log.

Signed-off-by: Amber Jain am...@ti.com
---
 drivers/media/video/omap/omap_vout.c |2 +-
 drivers/media/video/omap24xxcam.c|4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 4ada9be..8cac624 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -181,7 +181,7 @@ static unsigned long omap_vout_alloc_buffer(u32 buf_size, 
u32 *phys_addr)
 
size = PAGE_ALIGN(buf_size);
order = get_order(size);
-   virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
+   virt_addr = __get_free_pages(GFP_KERNEL , order);
addr = virt_addr;
 
if (virt_addr) {
diff --git a/drivers/media/video/omap24xxcam.c 
b/drivers/media/video/omap24xxcam.c
index f6626e8..ade9262 100644
--- a/drivers/media/video/omap24xxcam.c
+++ b/drivers/media/video/omap24xxcam.c
@@ -309,11 +309,11 @@ static int omap24xxcam_vbq_alloc_mmap_buffer(struct 
videobuf_buffer *vb)
order--;
 
/* try to allocate as many contiguous pages as possible */
-   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+   page = alloc_pages(GFP_KERNEL , order);
/* if allocation fails, try to allocate smaller amount */
while (page == NULL) {
order--;
-   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+   page = alloc_pages(GFP_KERNEL , order);
if (page == NULL  !order) {
err = -ENOMEM;
goto out;
-- 
1.7.1

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

Re: omap3isp - H3A auto white balance

2011-05-31 Thread Daniel Lundborg

Hi Laurent,

 Hi Daniel,
 
 On Thursday 26 May 2011 15:06:17 Daniel Lundborg wrote:
   On Thursday 26 May 2011 10:57:39 Daniel Lundborg wrote:
Hello,

I am developing a camera sensor driver for the Aptina MT9V034. I

am only using it in snapshot mode and I can successfully trigger

the sensor and receive pictures using the latest omap3isp driver

from git://linuxtv.org/pinchartl/media.git branch 
omap3isp-next-sensors with kernel 2.6.38.

I configure the sensor with media-ctl:

media-ctl -r -l 'mt9v034 3-0048:0-OMAP3 ISP CCDC:0[1],
OMAP3 
ISP
CCDC:1-OMAP3 ISP CCDC output:0[1]'

media-ctl -f 'mt9v034 3-0048:0[SGRBG10 752x480], OMAP3 ISP 
CCDC:1[SGRBG10 752x480]'

And take pictures with yavta:

./yavta -f SGRBG10 -s 752x480 -n 6 --capture=6 -F /dev/video2

My trouble is that I am always receiving whiter pictures when I 
wait a moment before triggering the sensor to take a picture. If
I 
take several pictures in a row with for instance 20 ms between 
them, they all look ok. But if I wait for 100 ms the picture
will get much whiter.

I have turned off auto exposure and auto gain in the sensor and 
the LED_OUT signal always have the same length (in this case 8
msec).
   
   I assume you've measured it with a scope ?
   
   Try disabling black level calibration and row noise correction as
well.
   Please also double-check that AEC and AGC are disabled. I've had a

   similar issue with an MT9V032 sensor, where a bug in the driver 
   enabled AEC/AGC instead of disabling them.
  
  The register on 0xaf (MT9V034_AGC_AEC_ENABLE) is set to 0 and is 0 
  when I read from it.
  bit 0 - AEC enable context A, bit 1 - AGC enable context A, bit 8 - 
  AEC enable context B, bit 9 - AGC enable context B
  
  The register on 0x47 (MT9V034_BL_CALIB_CTRL) is set to 0 and is 0
when 
  I read from it.
  bit 0 - (1 = override with programmed values, 0 = normal operation),

  bit
  7:5 - Frames to average over
 
 If I'm not mistaken normal operation means that automatic black
level calibration is enabled. Try to set bit 0 to 1 to override the
automatic algorithm (and program a zero value in register 0x48).

This did not work unfortunately.. :( I have solved this by always taking
2 pictures and ignoring the first of them...

 
  The register on 0x70 (MT9V034_ROW_NOISE_CORR_CONTROL) is set to 0
and 
  is 0 when I read from it.
  bit 0 - enable noise correction context A , bit 1 - Use black level 
  avg context A, bit 8 - enable noise correction context B, bit 9 -
Use 
  black level avg context B
  
  I measure the signals with a scope and the LED_OUT signal is always
8 
  msec when triggered.
  
  Code from my mt9v034.c:
 
 [snip]
 
  And from my board-overo.c file:
  
  void overo_camera_configure(struct v4l2_subdev *subdev) {
  struct isp_device *isp =
  v4l2_dev_to_isp_device(subdev-v4l2_dev);
  
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_CTRL, 
  ~0x9a1b63ff, 0x98036000); // Set CAM_GLOBAL_RESET pin as output, 
  enable shutter, set DIVC = 216
isp_reg_clr(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_SHUT_DELAY, 
  0x01ff);  // Set no shutter delay
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_SHUT_LENGTH, 
  0x01ff, 0x03e8); // Set shutter signal length to 1000 (=
1000 
  * 1/216MHz * 216 = 1 ms)
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN,
ISP_TCTRL_GRESET_LENGTH, 
  0x01ff, 0x03e8); // Set CAM_GLOBAL_RESET signal length to
1000 
  (= 1000 * 1/216MHz * 216 = 1 ms) }
  
  static void overo_camera_take_picture(struct v4l2_subdev *subdev) {
  struct isp_device *isp =
  v4l2_dev_to_isp_device(subdev-v4l2_dev);
  
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_CTRL, 0, 
  0x00e0);  // Enable shutter (SHUTEN bit = 1)
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_CTRL, 0, 
  0x2000);  // Start generation of CAM_GLOBAL_RESET signal
(GRESETEN 
  bit = 1) }
 
 I'll have to implement support for that in the OMAP3 ISP driver at
some point.
 
 [snip]
 
   Do you have a light source connected to the LED_OUT signal ? If
so, 
   can you try disabling it and using a constant light source ?
  
  No I'm not using the LED_OUT signal other than measuring the
exposure 
  time at this point.
  
Why would the pictures become whiter if I wait a moment before 
taking a picture?

If I set the sensor in streaming mode all pictures look like
they 
should.

Could there be something with the H3A auto white balance or auto

exposure?
  
   The OMAP3 ISP isn't able to apply any H3A algorithm to the images
by 
   itself. The H3A hardware support only computes statistics, and a 
   userspace application then needs to compute parameters (such as 
   exposure time and
   gains) based on the statistics, and apply them to the hardware. As

   yavta doesn't include H3A algorithms, the differences in picture 
   brightness can only come from the

Re: omap3isp - H3A auto white balance

2011-05-31 Thread Laurent Pinchart

Hi Daniel,

On Tuesday 31 May 2011 11:45:13 Daniel Lundborg wrote:
  On Thursday 26 May 2011 15:06:17 Daniel Lundborg wrote:
On Thursday 26 May 2011 10:57:39 Daniel Lundborg wrote:
 Hello,
 
 I am developing a camera sensor driver for the Aptina MT9V034. I
 am only using it in snapshot mode and I can successfully trigger
 the sensor and receive pictures using the latest omap3isp driver
 from git://linuxtv.org/pinchartl/media.git branch
 omap3isp-next-sensors with kernel 2.6.38.

[snip]

 My trouble is that I am always receiving whiter pictures when I
 wait a moment before triggering the sensor to take a picture. If I
 take several pictures in a row with for instance 20 ms between
 them, they all look ok. But if I wait for 100 ms the picture will
 get much whiter.

 I have turned off auto exposure and auto gain in the sensor and
 the LED_OUT signal always have the same length (in this case 8
 msec).
   
I assume you've measured it with a scope ?

Try disabling black level calibration and row noise correction as
well.
   
Please also double-check that AEC and AGC are disabled. I've had a
similar issue with an MT9V032 sensor, where a bug in the driver
enabled AEC/AGC instead of disabling them.
   
   The register on 0xaf (MT9V034_AGC_AEC_ENABLE) is set to 0 and is 0
   when I read from it.
   bit 0 - AEC enable context A, bit 1 - AGC enable context A, bit 8 -
   AEC enable context B, bit 9 - AGC enable context B
   
   The register on 0x47 (MT9V034_BL_CALIB_CTRL) is set to 0 and is 0
   when I read from it.
   bit 0 - (1 = override with programmed values, 0 = normal operation),
   bit 7:5 - Frames to average over
  
  If I'm not mistaken normal operation means that automatic black
  level calibration is enabled. Try to set bit 0 to 1 to override the
  automatic algorithm (and program a zero value in register 0x48).
 
 This did not work unfortunately.. :( I have solved this by always taking
 2 pictures and ignoring the first of them...

:-/

Any chance you will submit the driver for inclusion in the kernel ?

-- 
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: omap3isp - H3A auto white balance

2011-05-31 Thread Daniel Lundborg

Hi Laurent,

 Hi Daniel,
 
 On Tuesday 31 May 2011 11:45:13 Daniel Lundborg wrote:
   On Thursday 26 May 2011 15:06:17 Daniel Lundborg wrote:
 On Thursday 26 May 2011 10:57:39 Daniel Lundborg wrote:
  Hello,
  
  I am developing a camera sensor driver for the Aptina
MT9V034. 
  I am only using it in snapshot mode and I can successfully 
  trigger the sensor and receive pictures using the latest 
  omap3isp driver from git://linuxtv.org/pinchartl/media.git 
  branch omap3isp-next-sensors with kernel 2.6.38.
 
 [snip]
 
  My trouble is that I am always receiving whiter pictures
when 
  I wait a moment before triggering the sensor to take a 
  picture. If I take several pictures in a row with for
instance 
  20 ms between them, they all look ok. But if I wait for 100
ms 
  the picture will get much whiter.
 
  I have turned off auto exposure and auto gain in the sensor 
  and the LED_OUT signal always have the same length (in this 
  case 8 msec).

 I assume you've measured it with a scope ?
 
 Try disabling black level calibration and row noise correction

 as well.

 Please also double-check that AEC and AGC are disabled. I've
had 
 a similar issue with an MT9V032 sensor, where a bug in the 
 driver enabled AEC/AGC instead of disabling them.

The register on 0xaf (MT9V034_AGC_AEC_ENABLE) is set to 0 and is
0 
when I read from it.
bit 0 - AEC enable context A, bit 1 - AGC enable context A, bit
8 
- AEC enable context B, bit 9 - AGC enable context B

The register on 0x47 (MT9V034_BL_CALIB_CTRL) is set to 0 and is
0 
when I read from it.
bit 0 - (1 = override with programmed values, 0 = normal 
operation), bit 7:5 - Frames to average over
   
   If I'm not mistaken normal operation means that automatic black 
   level calibration is enabled. Try to set bit 0 to 1 to override
the 
   automatic algorithm (and program a zero value in register 0x48).
  
  This did not work unfortunately.. :( I have solved this by always 
  taking
  2 pictures and ignoring the first of them...
 
 :-/
 
 Any chance you will submit the driver for inclusion in the kernel ?
 
 --
 Regards,
 
 Laurent Pinchart

Yes if there is an interest in it. I can create a patch from your
omap3isp-next-sensors tree if you want.

Regards,

Daniel Lundborg
--
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] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP

2011-05-31 Thread JAIN, AMBER

I have tested it on OMAP4430 blaze and OMAP3430 SDP platforms.

I do not have the hardware to test omap24xxcam change. Can someone please help 
me on this?

Thanks,
Amber 

 -Original Message-
 From: JAIN, AMBER
 Sent: Tuesday, May 31, 2011 3:22 PM
 To: linux-media@vger.kernel.org
 Cc: Hiremath, Vaibhav; sakari.ai...@iki.fi; JAIN, AMBER
 Subject: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not
 configured on OMAP
 
 Remove GFP_DMA from the __get_free_pages() call as ZONE_DMA is not
 configured
 on OMAP. Earlier the page allocator used to return a page from ZONE_NORMAL
 even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
 As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page
 allocator
 returns null in such a scenario with a warning emitted to kernel log.
 
 Signed-off-by: Amber Jain am...@ti.com
 ---
  drivers/media/video/omap/omap_vout.c |2 +-
  drivers/media/video/omap24xxcam.c|4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index 4ada9be..8cac624 100644
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -181,7 +181,7 @@ static unsigned long omap_vout_alloc_buffer(u32
 buf_size, u32 *phys_addr)
 
   size = PAGE_ALIGN(buf_size);
   order = get_order(size);
 - virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
 + virt_addr = __get_free_pages(GFP_KERNEL , order);
   addr = virt_addr;
 
   if (virt_addr) {
 diff --git a/drivers/media/video/omap24xxcam.c
 b/drivers/media/video/omap24xxcam.c
 index f6626e8..ade9262 100644
 --- a/drivers/media/video/omap24xxcam.c
 +++ b/drivers/media/video/omap24xxcam.c
 @@ -309,11 +309,11 @@ static int omap24xxcam_vbq_alloc_mmap_buffer(struct
 videobuf_buffer *vb)
   order--;
 
   /* try to allocate as many contiguous pages as possible */
 - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
 + page = alloc_pages(GFP_KERNEL , order);
   /* if allocation fails, try to allocate smaller amount */
   while (page == NULL) {
   order--;
 - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
 + page = alloc_pages(GFP_KERNEL , order);
   if (page == NULL  !order) {
   err = -ENOMEM;
   goto out;
 --
 1.7.1

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

Re: v4l2 device property framework in userspace

2011-05-31 Thread Hans Verkuil

On Tuesday, May 31, 2011 10:27:38 Martin Strubel wrote:
 
  
  Userspace tells the driver what it should do and the driver decides how to 
  do it.
  That's how it works.
 
 Sounds a little religious. Not sure if you've been listening..

Not religion, it's experience. I understand what you want to do and it is
just a bad idea in the long term. Mind you, it's great for prototyping and
experimentation. But if you want to get stable sensor support in the kernel,
then it has to conform to the rules. Having some sensor drivers in the kernel
and some in userspace will be a maintenance disaster.

 
  
  And for us it is even more reusable, because we can run the
  same thing on a standalone 'OS' (no OS really) and for example RTEMS.
  
  That is never a consideration for linux. Hardware abstraction layers are not
  allowed. Blame Linus, not me, although I completely agree with him on this.
  
 
 This is new to me. What should be the reason not to abstract hardware?
 To give people a coding job?

Sorry, I used the wrong name. I meant OS abstraction layers.

 
  So for the various OS specifics, we only have one video acquisition
  driver which has no knowledge of the attached sensor. All generic v4l2
  properties again are tunneled through userspace to the sensor daemon.
  I still don't see what is (technically) wrong with that.
  
  It's the tunneling to a sensor daemon that is wrong. You can write a sensor
  driver as a V4L subdevice driver and it is reusable by any 'video 
  acquisition;
  driver (aka V4L2 bridge/platform driver) without going through userspace and
  requiring userspace daemons.
  
 
  It's the tunneling to a sensor daemon that is wrong. You can write a sensor
  driver as a V4L subdevice driver and it is reusable by any 'video 
  acquisition;
  driver (aka V4L2 bridge/platform driver) without going through userspace and
  requiring userspace daemons.
 
 You keep saying it is wrong, but I have so far seen no technically firm
 argument. Please tell me why.

Technically both are valid approaches. But doing this in userspace just adds
extra complexity. All sensor drivers are in the kernel and we are not going
to introduce userspace sensor drivers as that leads to a maintenance disaster.

Besides, how is your sensor driver supposed to work when used in a USB webcam?
Such a USB bridge driver expects a subdevice sensor driver. Since you use a
different API the two can't communicate. Hence no code reuse.


 
  
  For me, it works like a driver, plus it is way more flexible as I don't
  have to go through ioctls for special sensor properties.
  
  You still have to go through the kernel to set registers. That's just as
  expensive as an ioctl.
  
 
 
 Not sure if you understand: I do not have to implement or generate ioctl
 handlers and call them. This is definitely less expensive in terms of
 coding. All the register access is handled *automatically* using the HW
 description layer.

Using what? /dev/i2c-X? That's using ioctls (I2C_RDWR).

 
  
  Sure, no problem. It's open source after all. Just be aware that all the
  maintenance effort is for you as long as you remain out of tree.
  
 
 We have to do this anyhow. But we'd prefer to do it the way that
 requires least maintenance as described.
 We need to have a *solution*. Not some academic hack that is not wrong.
 
 I think we can end the discussion here. I was hoping for more
 technically valuable input, really.
 

Well, you clearly want *your* solution. I've been working in the v4l subsystem
for many years now ensuring that we can support the widest range of very
practical and non-academic hardware, both consumer hardware and embedded system
hardware, and working together with companies like TI, Samsung, Nokia, etc.

You (or your company/organization) designed a system without as far as I am 
aware
consulating the people responsible for the relevant kernel subsystem (V4L in 
this
case). And now you want to get your code in with a minimum of change. Sorry, 
that's
not the way it works.

Regards,

Hans
--
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: v4l2 device property framework in userspace

2011-05-31 Thread Martin Strubel

Hi,

 
 Not religion, it's experience. I understand what you want to do and it is
 just a bad idea in the long term. Mind you, it's great for prototyping and
 experimentation. But if you want to get stable sensor support in the kernel,
 then it has to conform to the rules. Having some sensor drivers in the kernel
 and some in userspace will be a maintenance disaster.

Sorry, from our perspective the current v4l2 system *has* already been a
maintenance disaster. No offense, but that is exactly the reason why we
had to internally circumvent it.
You're free to use the system for early prototyping stage as well as for
a stable release (the framework is in fact running since 2006 in medical
imaging devices). It certainly cost us less maintenance so far than
syncing up to the changing v4l2 APIs.

 
 Besides, how is your sensor driver supposed to work when used in a USB webcam?
 Such a USB bridge driver expects a subdevice sensor driver. Since you use a
 different API the two can't communicate. Hence no code reuse.
 

I don't see a problem there either. Because you just put your register
access code into the kernel. That's merely a matter of two functions.
The sensor daemon doesn't really care *how* you access registers.



 Not sure if you understand: I do not have to implement or generate ioctl
 handlers and call them. This is definitely less expensive in terms of
 coding. All the register access is handled *automatically* using the HW
 description layer.
 
 Using what? /dev/i2c-X? That's using ioctls (I2C_RDWR).
 

Yes. But I have to write exactly two wrappers for access. Not create
tables with ioctl reqcodes.

 
 Well, you clearly want *your* solution. I've been working in the v4l subsystem
 for many years now ensuring that we can support the widest range of very
 practical and non-academic hardware, both consumer hardware and embedded 
 system
 hardware, and working together with companies like TI, Samsung, Nokia, etc.

Nope. I want any solution that does the job for our requirements. So far
it hasn't been doing it. It's not just getting an image from a sensor
and supporting v4l2 modes, but I think I've been mentioning the dirty
stuff already.

 
 You (or your company/organization) designed a system without as far as I am 
 aware
 consulating the people responsible for the relevant kernel subsystem (V4L in 
 this
 case). And now you want to get your code in with a minimum of change. Sorry, 
 that's
 not the way it works.
 

Just that you understand: I'm not wanting to get our code into
somewhere. I'd rather avoid it, one reason being lengthy discussions :-)
Bottomline again: I'm trying to find a solution to avoid bloated and
potentially unstable kernel drivers. Why do you think we (and our
customers) spent the money to develop alternative solutions?


Cheers,

- Martin
--
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] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP

2011-05-31 Thread Hiremath, Vaibhav


 -Original Message-
 From: JAIN, AMBER
 Sent: Tuesday, May 31, 2011 3:59 PM
 To: linux-media@vger.kernel.org
 Cc: Hiremath, Vaibhav; sakari.ai...@iki.fi
 Subject: RE: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is
 not configured on OMAP
 
 I have tested it on OMAP4430 blaze and OMAP3430 SDP platforms.
 
 I do not have the hardware to test omap24xxcam change. Can someone please
 help me on this?
 
[Hiremath, Vaibhav] I would suggest splitting this patch into 2, it would be 
easier to handle.

I am validating the patch on OMAP3EVM as well; will update you shortly. Pulling 
in the latest commits, git-fetch is taking huge time.

Thanks,
Vaibhav

 Thanks,
 Amber
 
  -Original Message-
  From: JAIN, AMBER
  Sent: Tuesday, May 31, 2011 3:22 PM
  To: linux-media@vger.kernel.org
  Cc: Hiremath, Vaibhav; sakari.ai...@iki.fi; JAIN, AMBER
  Subject: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is
 not
  configured on OMAP
 
  Remove GFP_DMA from the __get_free_pages() call as ZONE_DMA is not
  configured
  on OMAP. Earlier the page allocator used to return a page from
 ZONE_NORMAL
  even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
  As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page
  allocator
  returns null in such a scenario with a warning emitted to kernel log.
 
  Signed-off-by: Amber Jain am...@ti.com
  ---
   drivers/media/video/omap/omap_vout.c |2 +-
   drivers/media/video/omap24xxcam.c|4 ++--
   2 files changed, 3 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/media/video/omap/omap_vout.c
  b/drivers/media/video/omap/omap_vout.c
  index 4ada9be..8cac624 100644
  --- a/drivers/media/video/omap/omap_vout.c
  +++ b/drivers/media/video/omap/omap_vout.c
  @@ -181,7 +181,7 @@ static unsigned long omap_vout_alloc_buffer(u32
  buf_size, u32 *phys_addr)
 
  size = PAGE_ALIGN(buf_size);
  order = get_order(size);
  -   virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
  +   virt_addr = __get_free_pages(GFP_KERNEL , order);
  addr = virt_addr;
 
  if (virt_addr) {
  diff --git a/drivers/media/video/omap24xxcam.c
  b/drivers/media/video/omap24xxcam.c
  index f6626e8..ade9262 100644
  --- a/drivers/media/video/omap24xxcam.c
  +++ b/drivers/media/video/omap24xxcam.c
  @@ -309,11 +309,11 @@ static int
 omap24xxcam_vbq_alloc_mmap_buffer(struct
  videobuf_buffer *vb)
  order--;
 
  /* try to allocate as many contiguous pages as possible */
  -   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
  +   page = alloc_pages(GFP_KERNEL , order);
  /* if allocation fails, try to allocate smaller amount */
  while (page == NULL) {
  order--;
  -   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
  +   page = alloc_pages(GFP_KERNEL , order);
  if (page == NULL  !order) {
  err = -ENOMEM;
  goto out;
  --
  1.7.1

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

[PATCH] update dvb-c scanfile hu-Digikabel

2011-05-31 Thread Marton Balint

# HG changeset patch
# User Marton Balint c...@fazekas.hu
# Date 1306844422 -7200
# Node ID 15083eb9eb32e906d2961597965320d328b3782e
# Parent  7ebf32ed9124c7e58049dc9f59b514a222757b7d
update dvb-c scanfile hu-Digikabel

diff -r 7ebf32ed9124 -r 15083eb9eb32 util/scan/dvb-c/hu-Digikabel
--- a/util/scan/dvb-c/hu-Digikabel  Tue May 17 08:50:08 2011 +0200
+++ b/util/scan/dvb-c/hu-Digikabel  Tue May 31 14:20:22 2011 +0200
@@ -6,6 +6,7 @@
 #  Szazhalombatta, Bekescsaba, Bekes, Eger, Komlo, Oroszlany
 # In some of the cities not all the frequencies are available.
 # freq sr fec mod
+C 12100 690 NONE QAM256
 C 35400 690 NONE QAM256
 C 36200 690 NONE QAM256
 C 37000 690 NONE QAM256
@@ -14,8 +15,11 @@
 C 39400 690 NONE QAM256
 C 40200 690 NONE QAM256
 C 41000 690 NONE QAM256
+C 74600 690 NONE QAM256
+C 75400 690 NONE QAM256
 C 76200 690 NONE QAM256
 C 77000 690 NONE QAM256
 C 77800 690 NONE QAM256
 C 78600 690 NONE QAM256
 C 79400 690 NONE QAM256
+C 85000 690 NONE QAM256
--
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: v4l2 device property framework in userspace

2011-05-31 Thread Mauro Carvalho Chehab

Hi Martin,

Em 31-05-2011 08:33, Martin Strubel escreveu:
 Hi,
 

 Not religion, it's experience. I understand what you want to do and it is
 just a bad idea in the long term. Mind you, it's great for prototyping and
 experimentation. But if you want to get stable sensor support in the kernel,
 then it has to conform to the rules. Having some sensor drivers in the kernel
 and some in userspace will be a maintenance disaster.
 
 Sorry, from our perspective the current v4l2 system *has* already been a
 maintenance disaster. No offense, but that is exactly the reason why we
 had to internally circumvent it.
 You're free to use the system for early prototyping stage as well as for
 a stable release (the framework is in fact running since 2006 in medical
 imaging devices). 

It seems that you're completely lost about why it is good for you to upstream
a driver. First of all, by using and contributing with Linux (and other open 
source 
projects), you end by not needing of doing all work by yourself: a team of
experienced developers from several different companies work together to bring
the better solutions to address a problem. This is not academic. You'll see very
few contributions from academy at the Linux Kernel. Most of the contributions 
come
from people working and solving real problems. The direction taken on Linux 
come from
those experiences.

If you take a look at the discussions at the mailing list, you'll see that 
patches
made by one company receive lots of contributions from other companies, in order
to improve it. This warrants that such driver will perform better, have less 
bug fixes
(as others pair of eyes are looking on it) and can be used by other drivers.

Also, once a driver is merged, if someone needs to change some API, the one that
made the change should also send fixes for the drivers that use that calls. That
means that there's no maintainance effort at long term. We have very good 
examples
on how this work at the V4L subsystem: you'll find there drivers written in 
1999, where
the original maintainer stopped working on it a long time ago, and they still 
work with
real hardware. Such drivers even got userspace API improvements, like porting 
from V4L1
into V4L2.

So, if you're upstreaming your drivers, you get such benefits.

On the other hand, if you're working with out-of-tree drivers, it is a 
maintainance
nightmare, as we're always bringing improvements to the Linux core API's, and 
to the
V4L core subsystem. So, it costs a lot of time and money to keep an out-of-tree
driver working at the long term.

There's one major requirement for you to upstream your code: you need to 
understand
the concepts used by the subsystem you're upstreaming and adhere to the upstream
rules.

One of such rules is that a kernel driver should provide the desired 
functionality
without needing an userspace driver. In other words, we don't want to have a 
kernel
driver wrapper for a real driver at userspace.

 It certainly cost us less maintenance so far than
 syncing up to the changing v4l2 APIs.

You're increasing your maintainance costs by not upstreaming.


 Besides, how is your sensor driver supposed to work when used in a USB 
 webcam?
 Such a USB bridge driver expects a subdevice sensor driver. Since you use a
 different API the two can't communicate. Hence no code reuse.

 
 I don't see a problem there either. Because you just put your register
 access code into the kernel. That's merely a matter of two functions.
 The sensor daemon doesn't really care *how* you access registers.

The problem is that it violates the rule of the game: to share the developed 
code
with the others. If you're using non-standard interfaces to communicate between
the sensors and the bridge driver, only you're benefiting from it. At the end, 
someone
else will write a different code for that sensor, and we'll end by having 
several
drivers to do the same thing. By having just one driver, the TCO (Total Cost of 
Ownership)
will decrease, as the costs for writing and maintaining such driver decreases.


 Not sure if you understand: I do not have to implement or generate ioctl
 handlers and call them. This is definitely less expensive in terms of
 coding. All the register access is handled *automatically* using the HW
 description layer.

 Using what? /dev/i2c-X? That's using ioctls (I2C_RDWR).

 
 Yes. But I have to write exactly two wrappers for access. Not create
 tables with ioctl reqcodes.

V4L2 controls also have just 2 ioctl's for reading/writing values on it.


 Well, you clearly want *your* solution. I've been working in the v4l 
 subsystem
 for many years now ensuring that we can support the widest range of very
 practical and non-academic hardware, both consumer hardware and embedded 
 system
 hardware, and working together with companies like TI, Samsung, Nokia, etc.
 
 Nope. I want any solution that does the job for our requirements. So far
 it hasn't been doing it. It's not just getting an image from a

Re: [beagleboard] [PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Koen Kooi

Op 31 mei 2011, om 11:46 heeft Javier Martin het volgende geschreven:

 diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c 
 b/arch/arm/mach-omap2/board-omap3beagle-camera.c
 new file mode 100644
 index 000..04365b2
 --- /dev/null
 +++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
 
 +static int __init beagle_camera_init(void)
 +{
 + reg_1v8 = regulator_get(NULL, cam_1v8);
 + if (IS_ERR(reg_1v8))
 + pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
 + else
 + regulator_enable(reg_1v8);
 +
 + reg_2v8 = regulator_get(NULL, cam_2v8);
 + if (IS_ERR(reg_2v8))
 + pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
 + else
 + regulator_enable(reg_2v8);
 +
 + omap_register_i2c_bus(2, 100, NULL, 0);
 + gpio_request(MT9P031_RESET_GPIO, cam_rst);
 + gpio_direction_output(MT9P031_RESET_GPIO, 0);
 + omap3_init_camera(beagle_isp_platform_data);
 + return 0;
 +}
 +late_initcall(beagle_camera_init);

There should probably a if (cpu_is_omap3630()) {} wrapped around that, so the 
camera doesn't get initted on a 3530 beagle.

regards,

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

Re: [beagleboard] [PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Koen Kooi

root@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 -F 
`media-ctl -e OMAP3 ISP CCDC output`
Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
Video format set: SGRBG8 (47425247) 320x240 buffer size 76800
Video format: SGRBG8 (47425247) 320x240 buffer size 76800
4 buffers requested.
length: 76800 offset: 0
Buffer 0 mapped at address 0x402cf000.
length: 76800 offset: 77824
Buffer 1 mapped at address 0x402fe000.
length: 76800 offset: 155648
Buffer 2 mapped at address 0x40362000.
length: 76800 offset: 233472
Buffer 3 mapped at address 0x40416000.
0 (0) [-] 4294967295 76800 bytes 167.403289 1306829219.931121 0.002 fps
1 (1) [-] 4294967295 76800 bytes 167.633148 1306829220.160980 4.350 fps
2 (2) [-] 4294967295 76800 bytes 167.744506 1306829220.272308 8.980 fps
3 (3) [-] 4294967295 76800 bytes 167.855865 1306829220.383667 8.980 fps
4 (0) [-] 4294967295 76800 bytes 167.967193 1306829220.495025 8.982 fps
5 (1) [-] 4294967295 76800 bytes 168.078552 1306829220.606384 8.980 fps
6 (2) [-] 4294967295 76800 bytes 168.189910 1306829220.717742 8.980 fps
7 (3) [-] 4294967295 76800 bytes 168.301269 1306829220.829071 8.980 fps
8 (0) [-] 4294967295 76800 bytes 168.412597 1306829220.940429 8.982 fps
9 (1) [-] 4294967295 76800 bytes 168.523956 1306829221.051788 8.980 fps
Captured 10 frames in 1.254212 seconds (7.973134 fps, 612336.670356 B/s).
4 buffers released.

So that seems to be working! I haven't checked the frames yet, but is isn't 
throwing ISP errors anymore.

Op 31 mei 2011, om 11:46 heeft Javier Martin het volgende geschreven:

 Since isp clocks have not been exposed yet, this patch
 includes a temporal solution for testing mt9p031 driver
 in Beagleboard xM.
 
 Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
 ---
 arch/arm/mach-omap2/Makefile   |1 +
 arch/arm/mach-omap2/board-omap3beagle-camera.c |   90 
 arch/arm/mach-omap2/board-omap3beagle.c|   55 ++
 3 files changed, 146 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c
 
 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index 512b152..05cd983 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP)   += 
 board-2430sdp.o \
  hsmmc.o
 obj-$(CONFIG_MACH_OMAP_APOLLON)   += board-apollon.o
 obj-$(CONFIG_MACH_OMAP3_BEAGLE)   += board-omap3beagle.o \
 +board-omap3beagle-camera.o \
  hsmmc.o
 obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
 diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c 
 b/arch/arm/mach-omap2/board-omap3beagle-camera.c
 new file mode 100644
 index 000..04365b2
 --- /dev/null
 +++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
 @@ -0,0 +1,90 @@
 +#include linux/gpio.h
 +#include linux/regulator/machine.h
 +
 +#include plat/i2c.h
 +
 +#include media/mt9p031.h
 +
 +#include devices.h
 +#include ../../../drivers/media/video/omap3isp/isp.h
 +
 +#define MT9P031_RESET_GPIO   98
 +#define MT9P031_XCLK ISP_XCLK_A
 +
 +static struct regulator *reg_1v8, *reg_2v8;
 +
 +static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
 +{
 + struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
 + int ret;
 +
 + ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
 + return 0;
 +}
 +
 +static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
 +{
 + /* Set RESET_BAR to !active */
 + gpio_set_value(MT9P031_RESET_GPIO, !active);
 +
 + return 0;
 +}
 +
 +static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
 + .set_xclk   = beagle_cam_set_xclk,
 + .reset  = beagle_cam_reset,
 +};
 +
 +static struct i2c_board_info mt9p031_camera_i2c_device = {
 + I2C_BOARD_INFO(mt9p031, 0x48),
 + .platform_data = beagle_mt9p031_platform_data,
 +};
 +
 +static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
 + {
 + .board_info = mt9p031_camera_i2c_device,
 + .i2c_adapter_id = 2,
 + },
 + { NULL, 0, },
 +};
 +
 +static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
 + {
 + .subdevs = mt9p031_camera_subdevs,
 + .interface = ISP_INTERFACE_PARALLEL,
 + .bus = {
 + .parallel = {
 + .data_lane_shift = 0,
 + .clk_pol = 1,
 + .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
 + }
 + },
 + },
 + { },
 +};
 +
 +static struct isp_platform_data beagle_isp_platform_data = {
 + .subdevs

Re: [beagleboard] [PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread javier Martin

On 31 May 2011 15:34, Koen Kooi k...@beagleboard.org wrote:
 root@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 
 -F `media-ctl -e OMAP3 ISP CCDC output`
 Device /dev/video2 opened.
 Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
 Video format set: SGRBG8 (47425247) 320x240 buffer size 76800
 Video format: SGRBG8 (47425247) 320x240 buffer size 76800
 4 buffers requested.
 length: 76800 offset: 0
 Buffer 0 mapped at address 0x402cf000.
 length: 76800 offset: 77824
 Buffer 1 mapped at address 0x402fe000.
 length: 76800 offset: 155648
 Buffer 2 mapped at address 0x40362000.
 length: 76800 offset: 233472
 Buffer 3 mapped at address 0x40416000.
 0 (0) [-] 4294967295 76800 bytes 167.403289 1306829219.931121 0.002 fps
 1 (1) [-] 4294967295 76800 bytes 167.633148 1306829220.160980 4.350 fps
 2 (2) [-] 4294967295 76800 bytes 167.744506 1306829220.272308 8.980 fps
 3 (3) [-] 4294967295 76800 bytes 167.855865 1306829220.383667 8.980 fps
 4 (0) [-] 4294967295 76800 bytes 167.967193 1306829220.495025 8.982 fps
 5 (1) [-] 4294967295 76800 bytes 168.078552 1306829220.606384 8.980 fps
 6 (2) [-] 4294967295 76800 bytes 168.189910 1306829220.717742 8.980 fps
 7 (3) [-] 4294967295 76800 bytes 168.301269 1306829220.829071 8.980 fps
 8 (0) [-] 4294967295 76800 bytes 168.412597 1306829220.940429 8.982 fps
 9 (1) [-] 4294967295 76800 bytes 168.523956 1306829221.051788 8.980 fps
 Captured 10 frames in 1.254212 seconds (7.973134 fps, 612336.670356 B/s).
 4 buffers released.

 So that seems to be working! I haven't checked the frames yet, but is isn't 
 throwing ISP errors anymore.

Great!
Do you have a monochrome version of the same sensor?

-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [beagleboard] [PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Koen Kooi


Op 31 mei 2011, om 15:42 heeft javier Martin het volgende geschreven:

 On 31 May 2011 15:34, Koen Kooi k...@beagleboard.org wrote:
 root@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 
 -F `media-ctl -e OMAP3 ISP CCDC output`
 Device /dev/video2 opened.
 Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
 Video format set: SGRBG8 (47425247) 320x240 buffer size 76800
 Video format: SGRBG8 (47425247) 320x240 buffer size 76800
 4 buffers requested.
 length: 76800 offset: 0
 Buffer 0 mapped at address 0x402cf000.
 length: 76800 offset: 77824
 Buffer 1 mapped at address 0x402fe000.
 length: 76800 offset: 155648
 Buffer 2 mapped at address 0x40362000.
 length: 76800 offset: 233472
 Buffer 3 mapped at address 0x40416000.
 0 (0) [-] 4294967295 76800 bytes 167.403289 1306829219.931121 0.002 fps
 1 (1) [-] 4294967295 76800 bytes 167.633148 1306829220.160980 4.350 fps
 2 (2) [-] 4294967295 76800 bytes 167.744506 1306829220.272308 8.980 fps
 3 (3) [-] 4294967295 76800 bytes 167.855865 1306829220.383667 8.980 fps
 4 (0) [-] 4294967295 76800 bytes 167.967193 1306829220.495025 8.982 fps
 5 (1) [-] 4294967295 76800 bytes 168.078552 1306829220.606384 8.980 fps
 6 (2) [-] 4294967295 76800 bytes 168.189910 1306829220.717742 8.980 fps
 7 (3) [-] 4294967295 76800 bytes 168.301269 1306829220.829071 8.980 fps
 8 (0) [-] 4294967295 76800 bytes 168.412597 1306829220.940429 8.982 fps
 9 (1) [-] 4294967295 76800 bytes 168.523956 1306829221.051788 8.980 fps
 Captured 10 frames in 1.254212 seconds (7.973134 fps, 612336.670356 B/s).
 4 buffers released.
 
 So that seems to be working! I haven't checked the frames yet, but is isn't 
 throwing ISP errors anymore.
 
 Great!
 Do you have a monochrome version of the same sensor?

I think I only have the colour version, I got it with my leopard355 board way 
back. 

So what can I do with an unpatched mediactl and unpatched yavta? Is it already 
possible to point something like mplayer or gstreamer to a v4l2 node and see 
something? I lost the track of which patch goes where :)

regards,

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

Re: [beagleboard] [PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Guennadi Liakhovetski

On Tue, 31 May 2011, Koen Kooi wrote:

 
 Op 31 mei 2011, om 15:42 heeft javier Martin het volgende geschreven:
 
  On 31 May 2011 15:34, Koen Kooi k...@beagleboard.org wrote:
  root@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 
  3 -F `media-ctl -e OMAP3 ISP CCDC output`
  Device /dev/video2 opened.
  Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
  Video format set: SGRBG8 (47425247) 320x240 buffer size 76800
  Video format: SGRBG8 (47425247) 320x240 buffer size 76800
  4 buffers requested.
  length: 76800 offset: 0
  Buffer 0 mapped at address 0x402cf000.
  length: 76800 offset: 77824
  Buffer 1 mapped at address 0x402fe000.
  length: 76800 offset: 155648
  Buffer 2 mapped at address 0x40362000.
  length: 76800 offset: 233472
  Buffer 3 mapped at address 0x40416000.
  0 (0) [-] 4294967295 76800 bytes 167.403289 1306829219.931121 0.002 fps
  1 (1) [-] 4294967295 76800 bytes 167.633148 1306829220.160980 4.350 fps
  2 (2) [-] 4294967295 76800 bytes 167.744506 1306829220.272308 8.980 fps
  3 (3) [-] 4294967295 76800 bytes 167.855865 1306829220.383667 8.980 fps
  4 (0) [-] 4294967295 76800 bytes 167.967193 1306829220.495025 8.982 fps
  5 (1) [-] 4294967295 76800 bytes 168.078552 1306829220.606384 8.980 fps
  6 (2) [-] 4294967295 76800 bytes 168.189910 1306829220.717742 8.980 fps
  7 (3) [-] 4294967295 76800 bytes 168.301269 1306829220.829071 8.980 fps
  8 (0) [-] 4294967295 76800 bytes 168.412597 1306829220.940429 8.982 fps
  9 (1) [-] 4294967295 76800 bytes 168.523956 1306829221.051788 8.980 fps
  Captured 10 frames in 1.254212 seconds (7.973134 fps, 612336.670356 B/s).
  4 buffers released.
  
  So that seems to be working! I haven't checked the frames yet, but is 
  isn't throwing ISP errors anymore.
  
  Great!
  Do you have a monochrome version of the same sensor?
 
 I think I only have the colour version, I got it with my leopard355 board way 
 back. 
 
 So what can I do with an unpatched mediactl and unpatched yavta? Is it 
 already possible to point something like mplayer or gstreamer to a v4l2 
 node and see something? I lost the track of which patch goes where :)

If you're a lucky owner of an LCD on your bb-xM;) you might be able to do 
something similar, to what's described here

http://download.open-technology.de/BeagleBoard_xM-MT9P031/BBxM-MT9P031.txt

but both yavta and mplayer on the board, while short-circuiting the 
network;) I.e., pipe yavta output directly to mplayer.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP

2011-05-31 Thread JAIN, AMBER



 -Original Message-
 From: Hiremath, Vaibhav
 Sent: Tuesday, May 31, 2011 5:07 PM
 To: JAIN, AMBER; linux-media@vger.kernel.org
 Cc: sakari.ai...@iki.fi
 Subject: RE: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is
 not configured on OMAP
 
 
  -Original Message-
  From: JAIN, AMBER
  Sent: Tuesday, May 31, 2011 3:59 PM
  To: linux-media@vger.kernel.org
  Cc: Hiremath, Vaibhav; sakari.ai...@iki.fi
  Subject: RE: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA
 is
  not configured on OMAP
 
  I have tested it on OMAP4430 blaze and OMAP3430 SDP platforms.
 
  I do not have the hardware to test omap24xxcam change. Can someone
 please
  help me on this?
 
 [Hiremath, Vaibhav] I would suggest splitting this patch into 2, it would
 be easier to handle.
 
 I am validating the patch on OMAP3EVM as well; will update you shortly.
 Pulling in the latest commits, git-fetch is taking huge time.

Do you mean I should have it as a patch-set, or 2 different patches all 
together.

~Amber
 
 Thanks,
 Vaibhav
 
  Thanks,
  Amber
 
   -Original Message-
   From: JAIN, AMBER
   Sent: Tuesday, May 31, 2011 3:22 PM
   To: linux-media@vger.kernel.org
   Cc: Hiremath, Vaibhav; sakari.ai...@iki.fi; JAIN, AMBER
   Subject: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is
  not
   configured on OMAP
  
   Remove GFP_DMA from the __get_free_pages() call as ZONE_DMA is not
   configured
   on OMAP. Earlier the page allocator used to return a page from
  ZONE_NORMAL
   even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
   As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page
   allocator
   returns null in such a scenario with a warning emitted to kernel log.
  
   Signed-off-by: Amber Jain am...@ti.com
   ---
drivers/media/video/omap/omap_vout.c |2 +-
drivers/media/video/omap24xxcam.c|4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
  
   diff --git a/drivers/media/video/omap/omap_vout.c
   b/drivers/media/video/omap/omap_vout.c
   index 4ada9be..8cac624 100644
   --- a/drivers/media/video/omap/omap_vout.c
   +++ b/drivers/media/video/omap/omap_vout.c
   @@ -181,7 +181,7 @@ static unsigned long omap_vout_alloc_buffer(u32
   buf_size, u32 *phys_addr)
  
 size = PAGE_ALIGN(buf_size);
 order = get_order(size);
   - virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
   + virt_addr = __get_free_pages(GFP_KERNEL , order);
 addr = virt_addr;
  
 if (virt_addr) {
   diff --git a/drivers/media/video/omap24xxcam.c
   b/drivers/media/video/omap24xxcam.c
   index f6626e8..ade9262 100644
   --- a/drivers/media/video/omap24xxcam.c
   +++ b/drivers/media/video/omap24xxcam.c
   @@ -309,11 +309,11 @@ static int
  omap24xxcam_vbq_alloc_mmap_buffer(struct
   videobuf_buffer *vb)
 order--;
  
 /* try to allocate as many contiguous pages as possible */
   - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
   + page = alloc_pages(GFP_KERNEL , order);
 /* if allocation fails, try to allocate smaller amount */
 while (page == NULL) {
 order--;
   - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
   + page = alloc_pages(GFP_KERNEL , order);
 if (page == NULL  !order) {
 err = -ENOMEM;
 goto out;
   --
   1.7.1

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

RE: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP

2011-05-31 Thread Hiremath, Vaibhav


 -Original Message-
 From: JAIN, AMBER
 Sent: Tuesday, May 31, 2011 7:53 PM
 To: Hiremath, Vaibhav; linux-media@vger.kernel.org
 Cc: sakari.ai...@iki.fi
 Subject: RE: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is
 not configured on OMAP
 
 
 
  -Original Message-
  From: Hiremath, Vaibhav
  Sent: Tuesday, May 31, 2011 5:07 PM
  To: JAIN, AMBER; linux-media@vger.kernel.org
  Cc: sakari.ai...@iki.fi
  Subject: RE: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA
 is
  not configured on OMAP
 
 
   -Original Message-
   From: JAIN, AMBER
   Sent: Tuesday, May 31, 2011 3:59 PM
   To: linux-media@vger.kernel.org
   Cc: Hiremath, Vaibhav; sakari.ai...@iki.fi
   Subject: RE: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA
  is
   not configured on OMAP
  
   I have tested it on OMAP4430 blaze and OMAP3430 SDP platforms.
  
   I do not have the hardware to test omap24xxcam change. Can someone
  please
   help me on this?
  
  [Hiremath, Vaibhav] I would suggest splitting this patch into 2, it
 would
  be easier to handle.
 
  I am validating the patch on OMAP3EVM as well; will update you shortly.
  Pulling in the latest commits, git-fetch is taking huge time.
 
 Do you mean I should have it as a patch-set, or 2 different patches all
 together.
 
[Hiremath, Vaibhav] 2 different patches.

Thanks,
Vaibhav

 ~Amber
 
  Thanks,
  Vaibhav
 
   Thanks,
   Amber
  
-Original Message-
From: JAIN, AMBER
Sent: Tuesday, May 31, 2011 3:22 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; sakari.ai...@iki.fi; JAIN, AMBER
Subject: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA
 is
   not
configured on OMAP
   
Remove GFP_DMA from the __get_free_pages() call as ZONE_DMA is not
configured
on OMAP. Earlier the page allocator used to return a page from
   ZONE_NORMAL
even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page
allocator
returns null in such a scenario with a warning emitted to kernel
 log.
   
Signed-off-by: Amber Jain am...@ti.com
---
 drivers/media/video/omap/omap_vout.c |2 +-
 drivers/media/video/omap24xxcam.c|4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
   
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 4ada9be..8cac624 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -181,7 +181,7 @@ static unsigned long omap_vout_alloc_buffer(u32
buf_size, u32 *phys_addr)
   
size = PAGE_ALIGN(buf_size);
order = get_order(size);
-   virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
+   virt_addr = __get_free_pages(GFP_KERNEL , order);
addr = virt_addr;
   
if (virt_addr) {
diff --git a/drivers/media/video/omap24xxcam.c
b/drivers/media/video/omap24xxcam.c
index f6626e8..ade9262 100644
--- a/drivers/media/video/omap24xxcam.c
+++ b/drivers/media/video/omap24xxcam.c
@@ -309,11 +309,11 @@ static int
   omap24xxcam_vbq_alloc_mmap_buffer(struct
videobuf_buffer *vb)
order--;
   
/* try to allocate as many contiguous pages as possible
 */
-   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+   page = alloc_pages(GFP_KERNEL , order);
/* if allocation fails, try to allocate smaller amount
 */
while (page == NULL) {
order--;
-   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+   page = alloc_pages(GFP_KERNEL , order);
if (page == NULL  !order) {
err = -ENOMEM;
goto out;
--
1.7.1

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

[PATCH] OMAP2: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP

2011-05-31 Thread Amber Jain

Remove GFP_DMA from the __get_free_pages() call from omap24xxcam as ZONE_DMA
is not configured on OMAP. Earlier the page allocator used to return a page
from ZONE_NORMAL even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page allocator
returns null in such a scenario with a warning emitted to kernel log.

Signed-off-by: Amber Jain am...@ti.com
---
 drivers/media/video/omap24xxcam.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/omap24xxcam.c 
b/drivers/media/video/omap24xxcam.c
index f6626e8..d92d4c6 100644
--- a/drivers/media/video/omap24xxcam.c
+++ b/drivers/media/video/omap24xxcam.c
@@ -309,11 +309,11 @@ static int omap24xxcam_vbq_alloc_mmap_buffer(struct 
videobuf_buffer *vb)
order--;
 
/* try to allocate as many contiguous pages as possible */
-   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+   page = alloc_pages(GFP_KERNEL, order);
/* if allocation fails, try to allocate smaller amount */
while (page == NULL) {
order--;
-   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+   page = alloc_pages(GFP_KERNEL, order);
if (page == NULL  !order) {
err = -ENOMEM;
goto out;
-- 
1.7.1

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

Re: [beagleboard] [PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Laurent Pinchart

On Tuesday 31 May 2011 15:55:04 Guennadi Liakhovetski wrote:
 On Tue, 31 May 2011, Koen Kooi wrote:
  Op 31 mei 2011, om 11:46 heeft Javier Martin het volgende geschreven:
   diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
   b/arch/arm/mach-omap2/board-omap3beagle-camera.c new file mode 100644
   index 000..04365b2
   --- /dev/null
   +++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
   
   +static int __init beagle_camera_init(void)
   +{
   + reg_1v8 = regulator_get(NULL, cam_1v8);
   + if (IS_ERR(reg_1v8))
   + pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
   + else
   + regulator_enable(reg_1v8);
   +
   + reg_2v8 = regulator_get(NULL, cam_2v8);
   + if (IS_ERR(reg_2v8))
   + pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
   + else
   + regulator_enable(reg_2v8);
   +
   + omap_register_i2c_bus(2, 100, NULL, 0);
   + gpio_request(MT9P031_RESET_GPIO, cam_rst);
   + gpio_direction_output(MT9P031_RESET_GPIO, 0);
   + omap3_init_camera(beagle_isp_platform_data);
   + return 0;
   +}
   +late_initcall(beagle_camera_init);
  
  There should probably a if (cpu_is_omap3630()) {} wrapped around that, so
  the camera doesn't get initted on a 3530 beagle.
 
 ...speaking of which - if multiarch kernels are supported by OMAP3 you
 probably want to use something like
 
   if (!machine_is_omap3_beagle() || !cpu_is_omap3630())
   return;

Shouldn't you check the Beagleboard version instead? The OMAP3530 has an ISP, 
so there's nothing wrong with it per-se.

-- 
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: omap3isp - H3A auto white balance

2011-05-31 Thread Laurent Pinchart

Hi Daniel,

On Tuesday 31 May 2011 12:07:08 Daniel Lundborg wrote:

[snip]

  Any chance you will submit the driver for inclusion in the kernel ?
 
 Yes if there is an interest in it. I can create a patch from your
 omap3isp-next-sensors tree if you want.

That would be nice, thank you.

-- 
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: [beagleboard] [PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Koen Kooi


Op 31 mei 2011, om 16:46 heeft Laurent Pinchart het volgende geschreven:

 On Tuesday 31 May 2011 15:55:04 Guennadi Liakhovetski wrote:
 On Tue, 31 May 2011, Koen Kooi wrote:
 Op 31 mei 2011, om 11:46 heeft Javier Martin het volgende geschreven:
 diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
 b/arch/arm/mach-omap2/board-omap3beagle-camera.c new file mode 100644
 index 000..04365b2
 --- /dev/null
 +++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
 
 +static int __init beagle_camera_init(void)
 +{
 +  reg_1v8 = regulator_get(NULL, cam_1v8);
 +  if (IS_ERR(reg_1v8))
 +  pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
 +  else
 +  regulator_enable(reg_1v8);
 +
 +  reg_2v8 = regulator_get(NULL, cam_2v8);
 +  if (IS_ERR(reg_2v8))
 +  pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
 +  else
 +  regulator_enable(reg_2v8);
 +
 +  omap_register_i2c_bus(2, 100, NULL, 0);
 +  gpio_request(MT9P031_RESET_GPIO, cam_rst);
 +  gpio_direction_output(MT9P031_RESET_GPIO, 0);
 +  omap3_init_camera(beagle_isp_platform_data);
 +  return 0;
 +}
 +late_initcall(beagle_camera_init);
 
 There should probably a if (cpu_is_omap3630()) {} wrapped around that, so
 the camera doesn't get initted on a 3530 beagle.
 
 ...speaking of which - if multiarch kernels are supported by OMAP3 you
 probably want to use something like
 
  if (!machine_is_omap3_beagle() || !cpu_is_omap3630())
  return;
 
 Shouldn't you check the Beagleboard version instead? The OMAP3530 has an ISP, 
 so there's nothing wrong with it per-se.

It has an ISP, but the pins aren't brought out, so you will never be able to 
use it. We could check the version, but that will look like:

if (omap3_beagle_get_rev() = OMAP3BEAGLE_BOARD_XM || omap3_beagle_get_rev() = 
OMAP3BEAGLE_BOARD_XMC || omap3_beagle_get_rev() = OMAP3BEAGLE_BOARD_XMD )

or check if you're not on OMAP3BEAGLE_BOARD_AXBX, OMAP3BEAGLE_BOARD_C1_3 or 
OMAP3BEAGLE_BOARD_C4. I find the 3630 check a lot simpler :)

regards,

Koen



regards,

Koen--
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] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP

2011-05-31 Thread Guennadi Liakhovetski

On Tue, 31 May 2011, Amber Jain wrote:

 Remove GFP_DMA from the __get_free_pages() call as ZONE_DMA is not configured
 on OMAP. Earlier the page allocator used to return a page from ZONE_NORMAL
 even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
 As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page allocator
 returns null in such a scenario with a warning emitted to kernel log.
 
 Signed-off-by: Amber Jain am...@ti.com
 ---
  drivers/media/video/omap/omap_vout.c |2 +-
  drivers/media/video/omap24xxcam.c|4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/media/video/omap/omap_vout.c 
 b/drivers/media/video/omap/omap_vout.c
 index 4ada9be..8cac624 100644
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -181,7 +181,7 @@ static unsigned long omap_vout_alloc_buffer(u32 buf_size, 
 u32 *phys_addr)
  
   size = PAGE_ALIGN(buf_size);
   order = get_order(size);
 - virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
 + virt_addr = __get_free_pages(GFP_KERNEL , order);

Superfluous space before comma on all 3 occasions

   addr = virt_addr;
  
   if (virt_addr) {
 diff --git a/drivers/media/video/omap24xxcam.c 
 b/drivers/media/video/omap24xxcam.c
 index f6626e8..ade9262 100644
 --- a/drivers/media/video/omap24xxcam.c
 +++ b/drivers/media/video/omap24xxcam.c
 @@ -309,11 +309,11 @@ static int omap24xxcam_vbq_alloc_mmap_buffer(struct 
 videobuf_buffer *vb)
   order--;
  
   /* try to allocate as many contiguous pages as possible */
 - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
 + page = alloc_pages(GFP_KERNEL , order);
   /* if allocation fails, try to allocate smaller amount */
   while (page == NULL) {
   order--;
 - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
 + page = alloc_pages(GFP_KERNEL , order);
   if (page == NULL  !order) {
   err = -ENOMEM;
   goto out;
 -- 
 1.7.1
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP

2011-05-31 Thread Hiremath, Vaibhav


 -Original Message-
 From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
 Sent: Tuesday, May 31, 2011 10:40 PM
 To: JAIN, AMBER
 Cc: linux-media@vger.kernel.org; Hiremath, Vaibhav; sakari.ai...@iki.fi
 Subject: Re: [PATCH] OMAP: V4L2: Remove GFP_DMA allocation as ZONE_DMA is
 not configured on OMAP
 
 On Tue, 31 May 2011, Amber Jain wrote:
 
  Remove GFP_DMA from the __get_free_pages() call as ZONE_DMA is not
 configured
  on OMAP. Earlier the page allocator used to return a page from
 ZONE_NORMAL
  even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
  As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page
 allocator
  returns null in such a scenario with a warning emitted to kernel log.
 
  Signed-off-by: Amber Jain am...@ti.com
  ---
   drivers/media/video/omap/omap_vout.c |2 +-
   drivers/media/video/omap24xxcam.c|4 ++--
   2 files changed, 3 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
  index 4ada9be..8cac624 100644
  --- a/drivers/media/video/omap/omap_vout.c
  +++ b/drivers/media/video/omap/omap_vout.c
  @@ -181,7 +181,7 @@ static unsigned long omap_vout_alloc_buffer(u32
 buf_size, u32 *phys_addr)
 
  size = PAGE_ALIGN(buf_size);
  order = get_order(size);
  -   virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
  +   virt_addr = __get_free_pages(GFP_KERNEL , order);
 
 Superfluous space before comma on all 3 occasions
 
[Hiremath, Vaibhav] He has submitted updated patch where it's taken care of.

Thanks,
Vaibhav

  addr = virt_addr;
 
  if (virt_addr) {
  diff --git a/drivers/media/video/omap24xxcam.c
 b/drivers/media/video/omap24xxcam.c
  index f6626e8..ade9262 100644
  --- a/drivers/media/video/omap24xxcam.c
  +++ b/drivers/media/video/omap24xxcam.c
  @@ -309,11 +309,11 @@ static int
 omap24xxcam_vbq_alloc_mmap_buffer(struct videobuf_buffer *vb)
  order--;
 
  /* try to allocate as many contiguous pages as possible */
  -   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
  +   page = alloc_pages(GFP_KERNEL , order);
  /* if allocation fails, try to allocate smaller amount */
  while (page == NULL) {
  order--;
  -   page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
  +   page = alloc_pages(GFP_KERNEL , order);
  if (page == NULL  !order) {
  err = -ENOMEM;
  goto out;
  --
  1.7.1
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-media
 in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
--
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] V4L2: omap_vout: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP

2011-05-31 Thread Hiremath, Vaibhav


 -Original Message-
 From: JAIN, AMBER
 Sent: Tuesday, May 31, 2011 8:16 PM
 To: linux-media@vger.kernel.org
 Cc: Hiremath, Vaibhav; sakari.ai...@iki.fi; JAIN, AMBER
 Subject: [PATCH] V4L2: omap_vout: Remove GFP_DMA allocation as ZONE_DMA is
 not configured on OMAP
 
 Remove GFP_DMA from the __get_free_pages() call from omap_vout as ZONE_DMA
 is not configured on OMAP. Earlier the page allocator used to return a
 page
 from ZONE_NORMAL even when GFP_DMA is passed and CONFIG_ZONE_DMA is
 disabled.
 As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page
 allocator
 returns null in such a scenario with a warning emitted to kernel log.
 
 Signed-off-by: Amber Jain am...@ti.com
 ---
[Hiremath, Vaibhav] Tested on OMAP3EVM.

Tested-by: Vaibhav Hiremath hvaib...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com

Thanks,
Vaibhav

  drivers/media/video/omap/omap_vout.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index 4ada9be..8cac624 100644
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -181,7 +181,7 @@ static unsigned long omap_vout_alloc_buffer(u32
 buf_size, u32 *phys_addr)
 
   size = PAGE_ALIGN(buf_size);
   order = get_order(size);
 - virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
 + virt_addr = __get_free_pages(GFP_KERNEL, order);
   addr = virt_addr;
 
   if (virt_addr) {
 --
 1.7.1

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

[cron job] v4l-dvb daily build: ERRORS

2011-05-31 Thread Hans Verkuil

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

Results of the daily build of v4l-dvb:

date:Tue May 31 19:00:33 CEST 2011
git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: OK
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: ERRORS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: ERRORS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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

[PATCH] V4L/DVB: radio-si470x: fix memory leak in si470x_usb_driver_probe()

2011-05-31 Thread Alexey Khoroshilov

radio-int_in_urb is not deallocated on error paths in 
si470x_usb_driver_probe().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
 drivers/media/radio/si470x/radio-si470x-usb.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c 
b/drivers/media/radio/si470x/radio-si470x-usb.c
index 392e84f..ccefdae 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -699,7 +699,7 @@ static int si470x_usb_driver_probe(struct usb_interface 
*intf,
radio-videodev = video_device_alloc();
if (!radio-videodev) {
retval = -ENOMEM;
-   goto err_intbuffer;
+   goto err_urb;
}
memcpy(radio-videodev, si470x_viddev_template,
sizeof(si470x_viddev_template));
@@ -790,6 +790,8 @@ err_all:
kfree(radio-buffer);
 err_video:
video_device_release(radio-videodev);
+err_urb:
+   usb_free_urb(radio-int_in_urb);
 err_intbuffer:
kfree(radio-int_in_buffer);
 err_radio:
-- 
1.7.4.1

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

[PATCH] [media] uvcvideo: Fix control mapping for devices with multiple chains

2011-05-31 Thread Stephan Lachowsky

The search for matching extension units fails to take account of the
current chain.  In the case where you have two distinct video chains,
both containing an XU with the same GUID but different unit ids, you
will be unable to perform a mapping on the second chain because entity
on the first chain will always be found first

Fix this by only searching the current chain when performing a control
mapping.  This is analogous to the search used by uvc_find_control(),
and is the correct behaviour.

Signed-off-by: Stephan Lachowsky stephan.lachow...@maxim-ic.com
---
 drivers/media/video/uvc/uvc_ctrl.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index 59f8a9a..a77648f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1565,8 +1565,8 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
return -EINVAL;
}
 
-   /* Search for the matching (GUID/CS) control in the given device */
-   list_for_each_entry(entity, dev-entities, list) {
+   /* Search for the matching (GUID/CS) control on the current chain */
+   list_for_each_entry(entity, chain-entities, chain) {
unsigned int i;
 
if (UVC_ENTITY_TYPE(entity) != UVC_VC_EXTENSION_UNIT ||
-- 
1.7.4.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/5 v2] [media] ov9740: Fixed some settings

2011-05-31 Thread Andrew Chew

  +   { OV9740_MIPI_CTRL00,   0x64 }, /* 0x44 for 
 continuous clock */
 
 I think, the choice between continuous and discontinuous CSI-2 clock 
 should become configurable. You can only use discontinuous clock with 
 hosts, that support it, right? Whereas all hosts must support 
 continuous 
 clock. So, I'm not sure we should unconditionally switch to 
 discontinuous 
 clock here... Maybe it's better to keep it continuous until 
 we make it 
 configurable?

Yes, that's right.  The camera host needs to support discontinuous clocks.  
I'll change it back to continuous clock by default, and change the comment to 
0x64 for discontinuous clock, so we remember for when this becomes 
configurable.--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 4/5 v2] [media] ov9740: Remove hardcoded resolution regs

2011-05-31 Thread Andrew Chew

  +   /* Width must be a multiple of 4 pixels. */
  +   *width += *width % 4;
 
 No, this doesn't make it a multiple of 4, unless it was 
 even;) Just take 5 
 as an example. What you really want here is

Geez, you're right.  Not sure what was going on in my head when I did this.  
Thanks for catching it.


  +   /*
  +* Try to use as much of the sensor area as possible 
 when supporting
  +* smaller resolutions.  Depending on the aspect ratio of the
  +* chosen resolution, we can either use the full width 
 of the sensor,
  +* or the full height of the sensor (or both if the 
 aspect ratio is
  +* the same as 1280x720.
  +*/
  +   if ((OV9740_MAX_WIDTH * height)  (OV9740_MAX_HEIGHT * width)) {
  +   scale_input_x = (OV9740_MAX_HEIGHT * width) / height;
  +   scale_input_y = OV9740_MAX_HEIGHT;
  } else {
  -   dev_err(client-dev, Failed to select resolution!\n);
  -   return -EINVAL;
  +   scale_input_x = OV9740_MAX_WIDTH;
  +   scale_input_y = (OV9740_MAX_WIDTH * height) / width;
  }
 
 I don'z know how this sensor works, but the above two divisions round 
 down. And these are input sizes. Cannot it possibly lead to 
 the output 
 window being smaller, than required? Maybe you have to round 
 up (hint: 
 use DIV_ROUND_UP())?

The intention is to do some ratio math without floating point instructions, 
which resulted in some algebraic twiddling (which is why that math looks so 
weird).  I think what's there is okay.  If there's any rounding at all (and 
there shouldn't be any rounding, if standard image dimensions are called 
for), then there's going to be some aspect ratio weirdness no matter which way 
you round that division.--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 5/5 v2] [media] ov9740: Add suspend/resume

2011-05-31 Thread Andrew Chew

  +   /* For suspend/resume. */
  +   struct v4l2_mbus_framefmt   current_mf;
  +   int current_enable;
 
 bool?

Are you sure you want this to be a bool?  This thing is trying to shadow the 
enable parameter of the s_stream() callback, and that enable parameter is int.


  +static int ov9740_suspend(struct soc_camera_device *icd, 
 pm_message_t state)
  +{
  +   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
  +   struct ov9740_priv *priv = to_ov9740(sd);
  +
  +   if (priv-current_enable) {
  +   int current_enable = priv-current_enable;
  +
  +   ov9740_s_stream(sd, 0);
  +   priv-current_enable = current_enable;
 
 You don't need the local variable, just set
 
   priv-current_enable = true;

I think I do need that local variable, the way the code is arranged now.  I'm 
trying to save the state of enablement inside of priv-current_enable, at the 
time we are suspending, so it won't necessarily be true.  And one of the side 
effects of calling ov9740_s_stream(sd, 0) is that priv-current_enable will be 
set to false, which is why I save off the value of priv-current_enable, and 
then restore it after the call to ov9740_s_stream().


   static struct soc_camera_ops ov9740_ops = {
  +   .suspend= ov9740_suspend,
  +   .resume = ov9740_resume,
 
 No, we don't want to use these, whey should disappear some 
 time... Please, 
 use .s_power() from struct v4l2_subdev_core_ops, you can check 
 http://article.gmane.org/gmane.linux.drivers.video-input-infra
 structure/33105 
 for an example. If your host is not using these ops, it has 
 to be fixed. 
 So far in the mainline only one soc-camera host driver is using these 
 callbacks: pxa_camera.c, which, looking at your email 
 address, I doubt is 
 the driver, that you're using;)

Okay, will do.  Thanks for pointing that out :)

Is the camera host driver expected to directly call the sensor driver's s_power 
(via v4l2_subdev_call(sd, core, s_power, some value)?  Or does the v4l2 
framework do this for you?  I didn't see an example of this in my last pull of 
linux-next.--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [beagleboard] [PATCH v5 2/2] Add support for mt9p031 (LI-5M03 module) in Beagleboard xM.

2011-05-31 Thread Chris Rodley

Hi Javier,

On 01/06/11 01:34, Koen Kooi wrote:
 root@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 
 -F `media-ctl -e OMAP3 ISP CCDC output`
 Device /dev/video2 opened.
 Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
 Video format set: SGRBG8 (47425247) 320x240 buffer size 76800
 Video format: SGRBG8 (47425247) 320x240 buffer size 76800
 4 buffers requested.
 length: 76800 offset: 0
 Buffer 0 mapped at address 0x402cf000.
 length: 76800 offset: 77824
 Buffer 1 mapped at address 0x402fe000.
 length: 76800 offset: 155648
 Buffer 2 mapped at address 0x40362000.
 length: 76800 offset: 233472
 Buffer 3 mapped at address 0x40416000.
 0 (0) [-] 4294967295 76800 bytes 167.403289 1306829219.931121 0.002 fps
 1 (1) [-] 4294967295 76800 bytes 167.633148 1306829220.160980 4.350 fps
 2 (2) [-] 4294967295 76800 bytes 167.744506 1306829220.272308 8.980 fps
 3 (3) [-] 4294967295 76800 bytes 167.855865 1306829220.383667 8.980 fps
 4 (0) [-] 4294967295 76800 bytes 167.967193 1306829220.495025 8.982 fps
 5 (1) [-] 4294967295 76800 bytes 168.078552 1306829220.606384 8.980 fps
 6 (2) [-] 4294967295 76800 bytes 168.189910 1306829220.717742 8.980 fps
 7 (3) [-] 4294967295 76800 bytes 168.301269 1306829220.829071 8.980 fps
 8 (0) [-] 4294967295 76800 bytes 168.412597 1306829220.940429 8.982 fps
 9 (1) [-] 4294967295 76800 bytes 168.523956 1306829221.051788 8.980 fps
 Captured 10 frames in 1.254212 seconds (7.973134 fps, 612336.670356 B/s).
 4 buffers released.

 So that seems to be working! I haven't checked the frames yet, but is isn't 
 throwing ISP errors anymore.

Unfortunately still not working for me.
My board is not the BeagleBoard XM but is similar. It is an omap3530 board and 
power to the camera (VDD and VDD_IO) is controlled by GPIO 57 and 58.

Here is my code for the board-omap3beagle-camera.c file.
Instead of triggering the regulators I set them up in the board file and then 
turn them on - This approach worked fine in v1 of your patch, but has not 
worked on any version since - Is there anything you can see as an issue?:

#include linux/gpio.h
//#include linux/regulator/machine.h

#include plat/i2c.h

#include media/mt9p031.h

#include devices.h
#include ../../../drivers/media/video/omap3isp/isp.h

#define MT9P031_RESET_GPIO  98
#define MT9P031_XCLKISP_XCLK_A

//static struct regulator *reg_1v8, *reg_2v8;

static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
{
struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
int ret;

ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
return 0;
}

static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
{
/* Set RESET_BAR to !active */
gpio_set_value(MT9P031_RESET_GPIO, !active);

return 0;
}

static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
.set_xclk   = beagle_cam_set_xclk,
.reset  = beagle_cam_reset,
};

static struct i2c_board_info mt9p031_camera_i2c_device = {
I2C_BOARD_INFO(mt9p031, 0x48),
.platform_data = beagle_mt9p031_platform_data,
};

static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
{
.board_info = mt9p031_camera_i2c_device,
.i2c_adapter_id = 2,
},
{ NULL, 0, },
};

static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
{
.subdevs = mt9p031_camera_subdevs,
.interface = ISP_INTERFACE_PARALLEL,
.bus = {
.parallel = {
.data_lane_shift = 0,
.clk_pol = 1,
.bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
}
},
},
{ },
};

static struct isp_platform_data beagle_isp_platform_data = {
.subdevs = beagle_camera_subdevs,
};

static int __init beagle_camera_init(void)
{
/* New code START */
gpio_set_value(58, 0);
printk(KERN_INFO Power on 58 1v8 init..\n);   

gpio_set_value(57, 0);
printk(KERN_INFO Power on 57 2v8 init..\n);
/* New code END */ 

/* ORIG CODE
{
reg_1v8 = regulator_get(NULL, cam_1v8);
if (IS_ERR(reg_1v8))
pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
else
regulator_enable(reg_1v8);

reg_2v8 = regulator_get(NULL, cam_2v8);
if (IS_ERR(reg_2v8))
pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
else
regulator_enable(reg_2v8);*/

omap_register_i2c_bus(2, 100, NULL, 0);
gpio_request(MT9P031_RESET_GPIO, cam_rst);
gpio_direction_output(MT9P031_RESET_GPIO, 0);
omap3_init_camera(beagle_isp_platform_data);
return 0;
}
late_initcall(beagle_camera_init);


Regards,
Chris
--
To unsubscribe from this

Re: [PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC

2011-05-31 Thread Kassey Lee

Guennadi:
 thanks for your detail review and comments.
 I updated one by one, and will send out the patch later.
thanks

2011/5/31 Guennadi Liakhovetski g.liakhovet...@gmx.de:
 On Fri, 27 May 2011, Kassey Lee wrote:

 This driver exports a video device node per each CCIC
 (CMOS Camera Interface Controller)
 device contained in Marvell Mobile PXA910 SoC
 The driver is based on v4l2-mem2mem framework, and only

 What does it have to do with mem2mem?
 [kassey] sorry, I will change it to this driver is based on soc-camera and 
 videobuf2 framework
 USERPTR is supported.

 Signed-off-by: Kassey Lee y...@marvell.com
 ---
  arch/arm/mach-mmp/include/mach/camera.h |   33 +
  drivers/media/video/Kconfig             |    7 +
  drivers/media/video/Makefile            |    1 +
  drivers/media/video/mv_camera.c         | 1120 
 +++
  4 files changed, 1161 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
  create mode 100644 drivers/media/video/mv_camera.c

 diff --git a/arch/arm/mach-mmp/include/mach/camera.h 
 b/arch/arm/mach-mmp/include/mach/camera.h
 new file mode 100644
 index 000..b008f3f
 --- /dev/null
 +++ b/arch/arm/mach-mmp/include/mach/camera.h
 @@ -0,0 +1,33 @@
 +/*
 + * Copyright (C) 2011, Marvell International Ltd.
 + *   Kassey Lee y...@marvell.com
 + *   Angela Wan j...@marvell.com
 + *   Lei Wen lei...@marvell.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + */
 +
 +#ifndef __ASM_ARCH_CAMERA_H__
 +#define __ASM_ARCH_CAMERA_H__
 +
 +#define MAX_CAM_CLK 3
 +struct mv_cam_pdata {
 +     struct clk *clk[MAX_CAM_CLK];
 +     char *name;
 +     int clk_enabled;

 None of the above fields seem to be used
 [kassey] OK, i will remove them.

 +     int dphy[3];
 +     int bus_type;

 Hm, you're running a bit ahead of time with this one;) SOCAM_MIPI is _not_
 a bus-type, but yes, I'm thinking about adding a bus_type field to struct
 soc_camera_device, in fact, I've been doing that just a couple of hours
 before reviewing this code:) So far I forsee having 3 bus-types: normal
 PARALLEL, BT656 and MIPI_CSI2, sounds reasonable? Even though I don't
 think we explicitly support BT656 anywhere in soc-camera yet.

 [kassey]appreciate your patch for the bus_type, for now, how about change it 
 to flags, where the platform will define the but attribute that this board 
 supports ?
 +     int dma_burst;
 +     int qos_req_min;

 Unused?
 [kassey] qos_req_min removed.
 +     int mclk_min;
 +     int mclk_src;
 +     int (*clk_init) (struct device *dev, int init);
 +     void (*set_clock) (struct device *dev, int on);
 +     int (*get_mclk_src) (int src);
 +};
 +
 +#endif
 diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
 index 3be180b..3b7a70e 100644
 --- a/drivers/media/video/Kconfig
 +++ b/drivers/media/video/Kconfig
 @@ -891,6 +891,13 @@ config VIDEO_MX3
       ---help---
         This is a v4l2 driver for the i.MX3x Camera Sensor Interface

 +config VIDEO_MV

 Maybe choose a more specific name? Either with CCIC or with PXA910 in it -
 whatever you feel is more appropriate. Same holds for the filename and,
 ideally, for the whole used namespace. We hope this is not the last V4L2
 driver from Marvell:-)
  [kassey] OK, how aboutVIDEO_MV_CCIC ?
 +     tristate Marvell CMOS Camera Interface Controller driver
 +     depends on VIDEO_DEV  CPU_PXA910  SOC_CAMERA
 +     select VIDEOBUF2_DMA_CONTIG
 +     ---help---
 +       This is a v4l2 driver for the Marvell CCIC Interface
 +
  config VIDEO_PXA27x
       tristate PXA27x Quick Capture Interface driver
       depends on VIDEO_DEV  PXA27x  SOC_CAMERA
 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
 index 9519160..373b706 100644
 --- a/drivers/media/video/Makefile
 +++ b/drivers/media/video/Makefile
 @@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += 
 soc_camera_platform.o
  obj-$(CONFIG_VIDEO_MX1)                      += mx1_camera.o
  obj-$(CONFIG_VIDEO_MX2)                      += mx2_camera.o
  obj-$(CONFIG_VIDEO_MX3)                      += mx3_camera.o
 +obj-$(CONFIG_VIDEO_MV)                       += mv_camera.o
  obj-$(CONFIG_VIDEO_PXA27x)           += pxa_camera.o
  obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2)   += sh_mobile_csi2.o
  obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)    += sh_mobile_ceu_camera.o
 diff --git a/drivers/media/video/mv_camera.c 
 b/drivers/media/video/mv_camera.c
 new file mode 100644
 index 000..1a8f73e
 --- /dev/null
 +++ b/drivers/media/video/mv_camera.c
 @@ -0,0 +1,1120 @@
 +/*
 + * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
 + * (CMOS Capture Interface Controller)
 + *
 + * Copyright (C) 2011, Marvell International Ltd.
 + *   Kassey Lee y...@marvell.com
 + *   Angela Wan j...@marvell.com
 + *

[PATCH V2] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC

2011-05-31 Thread Kassey Lee

This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.

Signed-off-by: Kassey Lee y...@marvell.com
---
 arch/arm/mach-mmp/include/mach/camera.h |   37 ++
 drivers/media/video/Kconfig |7 +
 drivers/media/video/Makefile|1 +
 drivers/media/video/mv_camera.c | 1067 +++
 4 files changed, 1112 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
 create mode 100644 drivers/media/video/mv_camera.c

diff --git a/arch/arm/mach-mmp/include/mach/camera.h 
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER   1
+#define MV_CAMERA_DATAWIDTH_8  8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN  0x40
+#define MV_CAMERA_MCLK_EN  0x80
+#define MV_CAMERA_PCP  0x100
+#define MV_CAMERA_HSP  0x200
+#define MV_CAMERA_VSP  0x400
+
+struct mv_cam_pdata {
+   int dphy[3];
+   unsigned long flags;
+   int dma_burst;
+   int mclk_min;
+   int mclk_src;
+   int (*init_clk) (struct device *dev, int init);
+   void (*enable_clk) (struct device *dev, int on);
+   int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
  This is a v4l2 driver for the i.MX3x Camera Sensor Interface
 
+config VIDEO_MV_CCIC
+   tristate Marvell CMOS Camera Interface Controller driver
+   depends on VIDEO_DEV  CPU_PXA910  SOC_CAMERA
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
 config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV  PXA27x  SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM)   += soc_camera_platform.o
 obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
 obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
 obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o
 obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..f19c43d
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1067 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include media/videobuf2-dma-contig.h
+
+#include mach/camera.h
+#include cafe_ccic-regs.h
+
+/* Register definition for PXA910 */
+
+#define REG_U0BAR   0x0c
+#define REG_U1BAR   0x10
+#define REG_U2BAR   0x14
+#define REG_V0BAR   0x18
+#define REG_V1BAR   0x1C
+#define REG_V2BAR   0x20
+
+/* for MIPI enable */
+#define REG_CSI2_CTRL0  0x100
+#define REG_CSI2_DPHY0  0x120
+#define

47 matches

Mail list logo