Determining MAC address or Serial Number
Hi, I'm trying to find a way to be able to uniquely identify each device in a PC and was hoping to use either serial or MAC for this purpose. I've looked at the documentation but can't find a generic way to read back serial numbers or MAC addresses from V4L devices? Does such a function exist? Thanks, Lou -- 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: Determining MAC address or Serial Number
Lou Otway wrote, On 10/30/2009 10:40 AM:
Hi,
I'm trying to find a way to be able to uniquely identify each device in
a PC and was hoping to use either serial or MAC for this purpose.
I've looked at the documentation but can't find a generic way to read
back serial numbers or MAC addresses from V4L devices? Does such a
function exist?
Hi Lou,
I'm using the mac address to identify each device and to do so I created
this script which use dvbnet to create network interface from the dvb card.
a=your adapter
n=your net device
for ex. /dev/dvb/adapter1/net0 = a=1, n=0
# get mac address
iface=$(sudo /usr/bin/dvbnet -a $a -n $n -p 0 | awk '/device/ {print $3}')
sleep 1
mac_address=$(/sbin/ifconfig $iface | awk '/HWaddr/ {print $5}' | tr -d
':' | tr A-Z a-z)
num=$(sudo /usr/bin/dvbnet -a $a -n $n -l | grep 'Found device ' | awk
'{print $3}' | tr -d ':')
sleep 1
sudo /usr/bin/dvbnet -a $a -n $n -d $num 1 /dev/null
AFAIK, mac address are known only from the kernel and are not directly
exposed to the userland. I you manage to do something cleaner, let me
know :)
Regards
pierre gr.
Thanks,
Lou
--
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: Determining MAC address or Serial Number
pierre.gronlier wrote:
Lou Otway wrote, On 10/30/2009 10:40 AM:
Hi,
I'm trying to find a way to be able to uniquely identify each device in
a PC and was hoping to use either serial or MAC for this purpose.
I've looked at the documentation but can't find a generic way to read
back serial numbers or MAC addresses from V4L devices? Does such a
function exist?
Hi Lou,
I'm using the mac address to identify each device and to do so I created
this script which use dvbnet to create network interface from the dvb card.
a=your adapter
n=your net device
for ex. /dev/dvb/adapter1/net0 = a=1, n=0
# get mac address
iface=$(sudo /usr/bin/dvbnet -a $a -n $n -p 0 | awk '/device/ {print $3}')
sleep 1
mac_address=$(/sbin/ifconfig $iface | awk '/HWaddr/ {print $5}' | tr -d
':' | tr A-Z a-z)
num=$(sudo /usr/bin/dvbnet -a $a -n $n -l | grep 'Found device ' | awk
'{print $3}' | tr -d ':')
sleep 1
sudo /usr/bin/dvbnet -a $a -n $n -d $num 1 /dev/null
AFAIK, mac address are known only from the kernel and are not directly
exposed to the userland. I you manage to do something cleaner, let me
know :)
Regards
pierre gr.
re majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks Pierre,
Unfortunately only some of my devices reported a MAC address, I guess
that not all drivers have this feature built in. I think the same
problem will hold true for serial devices so I will look at another way
to list my devices.
I was thinking to use lshw or lspci to give me a list of devices, from
that I can build my own table of devices each one with a unique value to
differentiate it from others. My worry is that the output from lshw or
lspci isn't sufficiently detailed to allow me to differentiate between
devices.
Thanks,
Lou
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/9 v2] Image-bus API and accompanying soc-camera patches
Hi all As discussed yesterday, we sant to finalise the conversion of soc-camera to v4l2-subdev. The presented 9 patches consist of a couple of clean-ups, minor additions to existing APIs, and, most importantly, the second version of the image-bus API. It hardly changed since v1, only got extended with a couple more formats and driver conversions. The last patch modifies mt9t031 sensor driver to enable its use outside of soc-camera. Muralidharan, hopefully you'd be able to test it. I'll provide more comments in the respective mail. A complete current patch-stack is available at http://download.open-technology.de/soc-camera/20091030/ based on 2.6.32-rc5. Patches, not included with these mails have either been already pushed via hg, or posted to the list earlier. 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
[PATCH 1/9] soc-camera: remove no longer needed struct members
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/media/soc_camera.h |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 3d74e60..c5afc8c 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -24,8 +24,6 @@ struct soc_camera_device {
struct device *pdev;/* Platform device */
s32 user_width;
s32 user_height;
- unsigned short width_min;
- unsigned short height_min;
unsigned short y_skip_top; /* Lines to skip at the top */
unsigned char iface;/* Host number */
unsigned char devnum; /* Device number per host */
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera
Introduce new v4l2-subdev sensor operations, move .enum_framesizes() and
.enum_frameintervals() methods to it, add a new .g_skip_top_lines() method
and switch soc-camera to use it instead of .y_skip_top soc_camera_device
member, which can now be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Reviewed-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/mt9m001.c | 30 --
drivers/media/video/mt9m111.c |1 -
drivers/media/video/mt9t031.c |8 ++
drivers/media/video/mt9v022.c | 32
drivers/media/video/pxa_camera.c |9 ++-
drivers/media/video/soc_camera_platform.c |1 -
include/media/soc_camera.h|1 -
include/media/v4l2-subdev.h | 13 +++
8 files changed, 69 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index 45388d2..17be2d4 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -82,6 +82,7 @@ struct mt9m001 {
int model; /* V4L2_IDENT_MT9M001* codes from v4l2-chip-ident.h */
unsigned int gain;
unsigned int exposure;
+ unsigned short y_skip_top; /* Lines to skip at the top */
unsigned char autoexposure;
};
@@ -222,7 +223,7 @@ static int mt9m001_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
soc_camera_limit_side(rect.top, rect.height,
MT9M001_ROW_SKIP, MT9M001_MIN_HEIGHT, MT9M001_MAX_HEIGHT);
- total_h = rect.height + icd-y_skip_top + vblank;
+ total_h = rect.height + mt9m001-y_skip_top + vblank;
/* Blanking and start values - default... */
ret = reg_write(client, MT9M001_HORIZONTAL_BLANKING, hblank);
@@ -239,7 +240,7 @@ static int mt9m001_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
ret = reg_write(client, MT9M001_WINDOW_WIDTH, rect.width - 1);
if (!ret)
ret = reg_write(client, MT9M001_WINDOW_HEIGHT,
- rect.height + icd-y_skip_top - 1);
+ rect.height + mt9m001-y_skip_top - 1);
if (!ret mt9m001-autoexposure) {
ret = reg_write(client, MT9M001_SHUTTER_WIDTH, total_h);
if (!ret) {
@@ -327,13 +328,13 @@ static int mt9m001_s_fmt(struct v4l2_subdev *sd, struct
v4l2_format *f)
static int mt9m001_try_fmt(struct v4l2_subdev *sd, struct v4l2_format *f)
{
struct i2c_client *client = sd-priv;
- struct soc_camera_device *icd = client-dev.platform_data;
+ struct mt9m001 *mt9m001 = to_mt9m001(client);
struct v4l2_pix_format *pix = f-fmt.pix;
v4l_bound_align_image(pix-width, MT9M001_MIN_WIDTH,
MT9M001_MAX_WIDTH, 1,
- pix-height, MT9M001_MIN_HEIGHT + icd-y_skip_top,
- MT9M001_MAX_HEIGHT + icd-y_skip_top, 0, 0);
+ pix-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
+ MT9M001_MAX_HEIGHT + mt9m001-y_skip_top, 0, 0);
if (pix-pixelformat == V4L2_PIX_FMT_SBGGR8 ||
pix-pixelformat == V4L2_PIX_FMT_SBGGR16)
@@ -552,7 +553,7 @@ static int mt9m001_s_ctrl(struct v4l2_subdev *sd, struct
v4l2_control *ctrl)
if (ctrl-value) {
const u16 vblank = 25;
unsigned int total_h = mt9m001-rect.height +
- icd-y_skip_top + vblank;
+ mt9m001-y_skip_top + vblank;
if (reg_write(client, MT9M001_SHUTTER_WIDTH,
total_h) 0)
return -EIO;
@@ -655,6 +656,16 @@ static void mt9m001_video_remove(struct soc_camera_device
*icd)
icl-free_bus(icl);
}
+static int mt9m001_g_skip_top_lines(struct v4l2_subdev *sd, u32 *lines)
+{
+ struct i2c_client *client = sd-priv;
+ struct mt9m001 *mt9m001 = to_mt9m001(client);
+
+ *lines = mt9m001-y_skip_top;
+
+ return 0;
+}
+
static struct v4l2_subdev_core_ops mt9m001_subdev_core_ops = {
.g_ctrl = mt9m001_g_ctrl,
.s_ctrl = mt9m001_s_ctrl,
@@ -675,9 +686,14 @@ static struct v4l2_subdev_video_ops
mt9m001_subdev_video_ops = {
.cropcap= mt9m001_cropcap,
};
+static struct v4l2_subdev_sensor_ops mt9m001_subdev_sensor_ops = {
+ .g_skip_top_lines = mt9m001_g_skip_top_lines,
+};
+
static struct v4l2_subdev_ops mt9m001_subdev_ops = {
.core = mt9m001_subdev_core_ops,
.video = mt9m001_subdev_video_ops,
+ .sensor = mt9m001_subdev_sensor_ops,
};
static int mt9m001_probe(struct i2c_client *client,
@@ -714,8 +730,8 @@ static int mt9m001_probe(struct i2c_client *client,
/* Second stage probe - when a capture adapter is there */
icd-ops
[PATCH 4/9] v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc codes
The 16-bit monochrome fourcc code has been previously abused for a 10-bit
format, add a new 10-bit code instead. Also add missing 8- and 10-bit Bayer
fourcc codes for completeness.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/linux/videodev2.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index b59e78c..9b240d5 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -294,6 +294,7 @@ struct v4l2_pix_format {
/* Grey formats */
#define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale
*/
+#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale
*/
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
/* Palette formats */
@@ -329,7 +330,11 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SBGGR8 v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG..
GRGR.. */
#define V4L2_PIX_FMT_SGBRG8 v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB..
RGRG.. */
#define V4L2_PIX_FMT_SGRBG8 v4l2_fourcc('G', 'R', 'B', 'G') /* 8 GRGR..
BGBG.. */
-#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10bit raw
bayer */
+#define V4L2_PIX_FMT_SRGGB8 v4l2_fourcc('R', 'G', 'G', 'B') /* 8 RGRG..
GBGB.. */
+#define V4L2_PIX_FMT_SBGGR10 v4l2_fourcc('B', 'G', '1', '0') /* 10 BGBG..
GRGR.. */
+#define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0') /* 10 GBGB..
RGRG.. */
+#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10 GRGR..
BGBG.. */
+#define V4L2_PIX_FMT_SRGGB10 v4l2_fourcc('R', 'G', '1', '0') /* 10 RGRG..
GBGB.. */
/* 10bit raw bayer DPCM compressed to 8 bits */
#define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
/*
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] soc-camera: fix multi-line comment coding style
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9m001.c | 36 --
drivers/media/video/mt9t031.c | 24
drivers/media/video/mt9v022.c | 48
drivers/media/video/mx1_camera.c | 36 --
drivers/media/video/mx3_camera.c | 18 ++---
drivers/media/video/pxa_camera.c | 54 ++-
drivers/media/video/sh_mobile_ceu_camera.c | 18 ++---
drivers/media/video/soc_camera.c | 24
drivers/media/video/tw9910.c |8 ++--
include/media/ov772x.h |3 +-
10 files changed, 178 insertions(+), 91 deletions(-)
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index 17be2d4..cc90660 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -17,9 +17,11 @@
#include media/v4l2-chip-ident.h
#include media/soc_camera.h
-/* mt9m001 i2c address 0x5d
+/*
+ * mt9m001 i2c address 0x5d
* The platform has to define ctruct i2c_board_info objects and link to them
- * from struct soc_camera_link */
+ * from struct soc_camera_link
+ */
/* mt9m001 selected register addresses */
#define MT9M001_CHIP_VERSION 0x00
@@ -47,8 +49,10 @@
#define MT9M001_ROW_SKIP 12
static const struct soc_camera_data_format mt9m001_colour_formats[] = {
- /* Order important: first natively supported,
-* second supported with a GPIO extender */
+ /*
+* Order important: first natively supported,
+* second supported with a GPIO extender
+*/
{
.name = Bayer (sRGB) 10 bit,
.depth = 10,
@@ -230,8 +234,10 @@ static int mt9m001_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
if (!ret)
ret = reg_write(client, MT9M001_VERTICAL_BLANKING, vblank);
- /* The caller provides a supported format, as verified per
-* call to icd-try_fmt() */
+ /*
+* The caller provides a supported format, as verified per
+* call to icd-try_fmt()
+*/
if (!ret)
ret = reg_write(client, MT9M001_COLUMN_START, rect.left);
if (!ret)
@@ -569,8 +575,10 @@ static int mt9m001_s_ctrl(struct v4l2_subdev *sd, struct
v4l2_control *ctrl)
return 0;
}
-/* Interface active, can use i2c. If it fails, it can indeed mean, that
- * this wasn't our capture interface, so, we wait for the right one */
+/*
+ * Interface active, can use i2c. If it fails, it can indeed mean, that
+ * this wasn't our capture interface, so, we wait for the right one
+ */
static int mt9m001_video_probe(struct soc_camera_device *icd,
struct i2c_client *client)
{
@@ -580,8 +588,10 @@ static int mt9m001_video_probe(struct soc_camera_device
*icd,
unsigned long flags;
int ret;
- /* We must have a parent by now. And it cannot be a wrong one.
-* So this entire test is completely redundant. */
+ /*
+* We must have a parent by now. And it cannot be a wrong one.
+* So this entire test is completely redundant.
+*/
if (!icd-dev.parent ||
to_soc_camera_host(icd-dev.parent)-nr != icd-iface)
return -ENODEV;
@@ -737,8 +747,10 @@ static int mt9m001_probe(struct i2c_client *client,
mt9m001-rect.width = MT9M001_MAX_WIDTH;
mt9m001-rect.height= MT9M001_MAX_HEIGHT;
- /* Simulated autoexposure. If enabled, we calculate shutter width
-* ourselves in the driver based on vertical blanking and frame width */
+ /*
+* Simulated autoexposure. If enabled, we calculate shutter width
+* ourselves in the driver based on vertical blanking and frame width
+*/
mt9m001-autoexposure = 1;
ret = mt9m001_video_probe(icd, client);
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index 57e04e9..0d2a8fd 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -17,9 +17,11 @@
#include media/v4l2-chip-ident.h
#include media/soc_camera.h
-/* mt9t031 i2c address 0x5d
+/*
+ * mt9t031 i2c address 0x5d
* The platform has to define i2c_board_info and link to it from
- * struct soc_camera_link */
+ * struct soc_camera_link
+ */
/* mt9t031 selected register addresses */
#define MT9T031_CHIP_VERSION 0x00
@@ -291,8 +293,10 @@ static int mt9t031_set_params(struct soc_camera_device
*icd,
dev_dbg(client-dev, new physical left %u, top %u\n,
rect-left, rect-top);
- /* The caller provides a supported format, as guaranteed by
-* icd-try_fmt_cap(), soc_camera_s_crop() and soc_camera_cropcap() */
+ /*
+* The caller provides a supported format, as guaranteed by
+* icd-try_fmt_cap(),
[PATCH 5/9] soc-camera: add a private field to struct soc_camera_link
Up to now, if a client driver needed platform data apart from those contained
in struct soc_camera_link, it had to embed the struct into its own object. This
makes the use of such a driver in configurations other than soc-camera
difficult. This patch adds a private field to struct soc_camera_link to make
the use of such private data arbitrary.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/media/soc_camera.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 218639f..831efff 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -104,6 +104,8 @@ struct soc_camera_link {
int i2c_adapter_id;
struct i2c_board_info *board_info;
const char *module_name;
+ void *priv;
+
/*
* For non-I2C devices platform platform has to provide methods to
* add a device to the system and to remove
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] soc-camera: switch drivers and platforms to use .priv in struct soc_camera_link
After this change drivers can be further extended to not fail, if they don't
get platform data, but to use defaults.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
arch/sh/boards/board-ap325rxa.c | 38 +++---
arch/sh/boards/mach-migor/setup.c | 32
drivers/media/video/ov772x.c|4 +-
drivers/media/video/tw9910.c|6 ++--
include/media/ov772x.h |1 -
include/media/soc_camera_platform.h |1 -
include/media/tw9910.h |1 -
7 files changed, 44 insertions(+), 39 deletions(-)
diff --git a/arch/sh/boards/board-ap325rxa.c b/arch/sh/boards/board-ap325rxa.c
index 2d08073..a3afe43 100644
--- a/arch/sh/boards/board-ap325rxa.c
+++ b/arch/sh/boards/board-ap325rxa.c
@@ -325,12 +325,14 @@ static struct soc_camera_platform_info camera_info = {
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8,
.set_capture = camera_set_capture,
- .link = {
- .bus_id = 0,
- .add_device = ap325rxa_camera_add,
- .del_device = ap325rxa_camera_del,
- .module_name= soc_camera_platform,
- },
+};
+
+struct soc_camera_link camera_link = {
+ .bus_id = 0,
+ .add_device = ap325rxa_camera_add,
+ .del_device = ap325rxa_camera_del,
+ .module_name= soc_camera_platform,
+ .priv = camera_info,
};
static void dummy_release(struct device *dev)
@@ -348,7 +350,7 @@ static struct platform_device camera_device = {
static int ap325rxa_camera_add(struct soc_camera_link *icl,
struct device *dev)
{
- if (icl != camera_info.link || camera_probe() = 0)
+ if (icl != camera_link || camera_probe() = 0)
return -ENODEV;
camera_info.dev = dev;
@@ -358,7 +360,7 @@ static int ap325rxa_camera_add(struct soc_camera_link *icl,
static void ap325rxa_camera_del(struct soc_camera_link *icl)
{
- if (icl != camera_info.link)
+ if (icl != camera_link)
return;
platform_device_unregister(camera_device);
@@ -439,13 +441,15 @@ static struct ov772x_camera_info ov7725_info = {
.buswidth = SOCAM_DATAWIDTH_8,
.flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP,
.edgectrl = OV772X_AUTO_EDGECTRL(0xf, 0),
- .link = {
- .bus_id = 0,
- .power = ov7725_power,
- .board_info = ap325rxa_i2c_camera[0],
- .i2c_adapter_id = 0,
- .module_name= ov772x,
- },
+};
+
+static struct soc_camera_link ov7725_link = {
+ .bus_id = 0,
+ .power = ov7725_power,
+ .board_info = ap325rxa_i2c_camera[0],
+ .i2c_adapter_id = 0,
+ .module_name= ov772x,
+ .priv = ov7725_info,
};
static struct platform_device ap325rxa_camera[] = {
@@ -453,13 +457,13 @@ static struct platform_device ap325rxa_camera[] = {
.name = soc-camera-pdrv,
.id = 0,
.dev= {
- .platform_data = ov7725_info.link,
+ .platform_data = ov7725_link,
},
}, {
.name = soc-camera-pdrv,
.id = 1,
.dev= {
- .platform_data = camera_info.link,
+ .platform_data = camera_link,
},
},
};
diff --git a/arch/sh/boards/mach-migor/setup.c
b/arch/sh/boards/mach-migor/setup.c
index 6ed1fd3..6145120 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -425,23 +425,27 @@ static struct i2c_board_info migor_i2c_camera[] = {
static struct ov772x_camera_info ov7725_info = {
.buswidth = SOCAM_DATAWIDTH_8,
- .link = {
- .power = ov7725_power,
- .board_info = migor_i2c_camera[0],
- .i2c_adapter_id = 0,
- .module_name= ov772x,
- },
+};
+
+static struct soc_camera_link ov7725_link = {
+ .power = ov7725_power,
+ .board_info = migor_i2c_camera[0],
+ .i2c_adapter_id = 0,
+ .module_name= ov772x,
+ .priv = ov7725_info,
};
static struct tw9910_video_info tw9910_info = {
.buswidth = SOCAM_DATAWIDTH_8,
.mpout = TW9910_MPO_FIELD,
- .link = {
- .power = tw9910_power,
- .board_info = migor_i2c_camera[1],
- .i2c_adapter_id = 0,
- .module_name= tw9910,
- }
+};
+
+static struct soc_camera_link tw9910_link = {
+ .power = tw9910_power,
+ .board_info = migor_i2c_camera[1],
+ .i2c_adapter_id = 0,
+
[PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats
Video subdevices, like cameras, decoders, connect to video bridges over
specialised busses. Data is being transferred over these busses in various
formats, which only loosely correspond to fourcc codes, describing how video
data is stored in RAM. This is not a one-to-one correspondence, therefore we
cannot use fourcc codes to configure subdevice output data formats. This patch
adds codes for several such on-the-bus formats and an API, similar to the
familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
codes. After all users of the old API in struct v4l2_subdev_video_ops are
converted, the API will be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/Makefile|2 +-
drivers/media/video/v4l2-imagebus.c | 218 +++
include/media/v4l2-imagebus.h | 84 ++
include/media/v4l2-subdev.h | 10 ++-
4 files changed, 312 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/v4l2-imagebus.c
create mode 100644 include/media/v4l2-imagebus.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7a2dcc3..62d8907 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,7 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o
omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
-videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o
+videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-imagebus.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-imagebus.c
b/drivers/media/video/v4l2-imagebus.c
new file mode 100644
index 000..e0a3a83
--- /dev/null
+++ b/drivers/media/video/v4l2-imagebus.c
@@ -0,0 +1,218 @@
+/*
+ * Image Bus API
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * 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/kernel.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-imagebus.h
+
+static const struct v4l2_imgbus_pixelfmt imgbus_fmt[] = {
+ [V4L2_IMGBUS_FMT_YUYV] = {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .name = YUYV,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_YVYU] = {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .name = YVYU,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_UYVY] = {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .name = UYVY,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_VYUY] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .name = VYUY,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_VYUY_SMPTE170M_8] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .colorspace = V4L2_COLORSPACE_SMPTE170M,
+ .name = VYUY in SMPTE170M,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_VYUY_SMPTE170M_16] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .colorspace = V4L2_COLORSPACE_SMPTE170M,
+ .name = VYUY in SMPTE170M, 16bit,
+ .bits_per_sample= 16,
+ .packing= V4L2_IMGBUS_PACKING_NONE,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_RGB555] = {
+ .fourcc = V4L2_PIX_FMT_RGB555,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .name = RGB555,
+ .bits_per_sample= 8,
+ .packing=
[PATCH/RFC 9/9] mt9t031: make the use of the soc-camera client API optional
Now that we have moved most of the functions over to the v4l2-subdev API, only
quering and setting bus parameters are still performed using the legacy
soc-camera client API. Make the use of this API optional for mt9t031.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Muralidharan, this one is for you to test. To differentiate between the
soc-camera case and a generic user I check i2c client's platform data
(client-dev.platform_data), so, you have to make sure your user doesn't
use that field for something else.
One more note: I'm not sure about where v4l2_device_unregister_subdev()
should be called. In soc-camera the core calls
v4l2_i2c_new_subdev_board(), which then calls
v4l2_device_register_subdev(). Logically, it's also the core that then
calls v4l2_device_unregister_subdev(). Whereas I see many other client
drivers call v4l2_device_unregister_subdev() internally. So, if your
bridge driver does not call v4l2_device_unregister_subdev() itself and
expects the client to call it, there will be a slight problem with that
too.
drivers/media/video/mt9t031.c | 146 -
1 files changed, 70 insertions(+), 76 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index c95c277..49357bd 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -204,6 +204,59 @@ static unsigned long mt9t031_query_bus_param(struct
soc_camera_device *icd)
return soc_camera_apply_sensor_flags(icl, MT9T031_BUS_PARAM);
}
+static const struct v4l2_queryctrl mt9t031_controls[] = {
+ {
+ .id = V4L2_CID_VFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Vertically,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_HFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Horizontally,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_GAIN,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Gain,
+ .minimum= 0,
+ .maximum= 127,
+ .step = 1,
+ .default_value = 64,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Exposure,
+ .minimum= 1,
+ .maximum= 255,
+ .step = 1,
+ .default_value = 255,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE_AUTO,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Automatic Exposure,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 1,
+ }
+};
+
+static struct soc_camera_ops mt9t031_ops = {
+ .set_bus_param = mt9t031_set_bus_param,
+ .query_bus_param= mt9t031_query_bus_param,
+ .controls = mt9t031_controls,
+ .num_controls = ARRAY_SIZE(mt9t031_controls),
+};
+
/* target must be _even_ */
static u16 mt9t031_skip(s32 *source, s32 target, s32 max)
{
@@ -223,10 +276,9 @@ static u16 mt9t031_skip(s32 *source, s32 target, s32 max)
}
/* rect is the sensor rectangle, the caller guarantees parameter validity */
-static int mt9t031_set_params(struct soc_camera_device *icd,
+static int mt9t031_set_params(struct i2c_client *client,
struct v4l2_rect *rect, u16 xskip, u16 yskip)
{
- struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd));
struct mt9t031 *mt9t031 = to_mt9t031(client);
int ret;
u16 xbin, ybin;
@@ -307,7 +359,7 @@ static int mt9t031_set_params(struct soc_camera_device *icd,
if (ret = 0) {
const u32 shutter_max = MT9T031_MAX_HEIGHT + vblank;
const struct v4l2_queryctrl *qctrl =
- soc_camera_find_qctrl(icd-ops,
+ soc_camera_find_qctrl(mt9t031_ops,
V4L2_CID_EXPOSURE);
mt9t031-exposure = (shutter_max / 2 + (total_h - 1) *
(qctrl-maximum - qctrl-minimum)) /
@@ -333,7 +385,6 @@ static int mt9t031_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
struct v4l2_rect rect = a-c;
struct
RE: [PATCH/RFC 0/9 v2] Image-bus API and accompanying soc-camera patches
Guennadi, Thanks for updating the driver. I will integrate it when I get a chance and let you know if I see any issues. BTW, Is there someone developing a driver for MT9P031 sensor which is very similar to MT9T031? Do you suggest a separate driver for this sensor or add the support in MT9T031? I need a driver for this and plan to add it soon. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Friday, October 30, 2009 10:01 AM To: Linux Media Mailing List Cc: Hans Verkuil; Laurent Pinchart; Sakari Ailus; Karicheri, Muralidharan Subject: [PATCH/RFC 0/9 v2] Image-bus API and accompanying soc-camera patches Hi all As discussed yesterday, we sant to finalise the conversion of soc-camera to v4l2-subdev. The presented 9 patches consist of a couple of clean-ups, minor additions to existing APIs, and, most importantly, the second version of the image-bus API. It hardly changed since v1, only got extended with a couple more formats and driver conversions. The last patch modifies mt9t031 sensor driver to enable its use outside of soc-camera. Muralidharan, hopefully you'd be able to test it. I'll provide more comments in the respective mail. A complete current patch-stack is available at http://download.open-technology.de/soc-camera/20091030/ based on 2.6.32-rc5. Patches, not included with these mails have either been already pushed via hg, or posted to the list earlier. 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 2/9] v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera
Guennadi,
mt9m111-rect.left = MT9M111_MIN_DARK_COLS;
mt9m111-rect.top = MT9M111_MIN_DARK_ROWS;
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index 6966f64..57e04e9 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -301,9 +301,9 @@ static int mt9t031_set_params(struct soc_camera_device
*icd,
ret = reg_write(client, MT9T031_WINDOW_WIDTH, rect-width - 1);
if (ret = 0)
ret = reg_write(client, MT9T031_WINDOW_HEIGHT,
- rect-height + icd-y_skip_top - 1);
+ rect-height - 1);
Why y_skip_top is removed? When I connect the sensor output to our SOC input
and do format conversion and resize on the fly (frame by frame conversion
before writing to SDRAM) I have found that the frame completion interrupt fails
to get generated with zero value for y_skip_top. I have used a value
of 10 and it worked fine for me. So I would like to have a s_skip_top_lines()
in the sensor operations which can be called to update
this value from the host/bridge driver.
if (ret = 0 mt9t031-autoexposure) {
- unsigned int total_h = rect-height + icd-y_skip_top + vblank;
+ unsigned int total_h = rect-height + vblank;
ret = set_shutter(client, total_h);
if (ret = 0) {
const u32 shutter_max = MT9T031_MAX_HEIGHT + vblank;
@@ -656,8 +656,7 @@ static int mt9t031_s_ctrl(struct v4l2_subdev *sd,
struct v4l2_control *ctrl)
if (ctrl-value) {
const u16 vblank = MT9T031_VERTICAL_BLANK;
const u32 shutter_max = MT9T031_MAX_HEIGHT + vblank;
- unsigned int total_h = mt9t031-rect.height +
- icd-y_skip_top + vblank;
+ unsigned int total_h = mt9t031-rect.height + vblank;
if (set_shutter(client, total_h) 0)
return -EIO;
@@ -773,7 +772,6 @@ static int mt9t031_probe(struct i2c_client *client,
/* Second stage probe - when a capture adapter is there */
icd-ops= mt9t031_ops;
- icd-y_skip_top = 0;
mt9t031-rect.left = MT9T031_COLUMN_SKIP;
mt9t031-rect.top = MT9T031_ROW_SKIP;
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 995607f..b71898f 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -97,6 +97,7 @@ struct mt9v022 {
__u32 fourcc;
int model; /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
u16 chip_control;
+ unsigned short y_skip_top; /* Lines to skip at the top */
};
static struct mt9v022 *to_mt9v022(const struct i2c_client *client)
@@ -265,7 +266,6 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd,
struct v4l2_crop *a)
struct i2c_client *client = sd-priv;
struct mt9v022 *mt9v022 = to_mt9v022(client);
struct v4l2_rect rect = a-c;
- struct soc_camera_device *icd = client-dev.platform_data;
int ret;
/* Bayer format - even size lengths */
@@ -287,10 +287,10 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd,
struct v4l2_crop *a)
if (ret = 0) {
if (ret 1) /* Autoexposure */
ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
- rect.height + icd-y_skip_top + 43);
+ rect.height + mt9v022-y_skip_top + 43);
else
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH,
- rect.height + icd-y_skip_top + 43);
+ rect.height + mt9v022-y_skip_top + 43);
}
/* Setup frame format: defaults apart from width and height */
if (!ret)
@@ -309,7 +309,7 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd,
struct v4l2_crop *a)
ret = reg_write(client, MT9V022_WINDOW_WIDTH, rect.width);
if (!ret)
ret = reg_write(client, MT9V022_WINDOW_HEIGHT,
- rect.height + icd-y_skip_top);
+ rect.height + mt9v022-y_skip_top);
if (ret 0)
return ret;
@@ -410,15 +410,15 @@ static int mt9v022_s_fmt(struct v4l2_subdev *sd,
struct v4l2_format *f)
static int mt9v022_try_fmt(struct v4l2_subdev *sd, struct v4l2_format *f)
{
struct i2c_client *client = sd-priv;
- struct soc_camera_device *icd = client-dev.platform_data;
+ struct mt9v022 *mt9v022 = to_mt9v022(client);
struct v4l2_pix_format *pix = f-fmt.pix;
int align = pix-pixelformat == V4L2_PIX_FMT_SBGGR8 ||
pix-pixelformat == V4L2_PIX_FMT_SBGGR16;
v4l_bound_align_image(pix-width, MT9V022_MIN_WIDTH,
MT9V022_MAX_WIDTH, align,
- pix-height,
RE: [PATCH/RFC 9/9] mt9t031: make the use of the soc-camera client API optional
Guennadi,
Thanks for your time for updating this driver. But I still don't think
it is in a state to be re-used on TI's VPFE platform. Please see
below for my comments.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Friday, October 30, 2009 10:02 AM
To: Linux Media Mailing List
Cc: Hans Verkuil; Laurent Pinchart; Sakari Ailus; Karicheri, Muralidharan
Subject: [PATCH/RFC 9/9] mt9t031: make the use of the soc-camera client API
optional
Now that we have moved most of the functions over to the v4l2-subdev API,
only
quering and setting bus parameters are still performed using the legacy
soc-camera client API. Make the use of this API optional for mt9t031.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Muralidharan, this one is for you to test. To differentiate between the
soc-camera case and a generic user I check i2c client's platform data
(client-dev.platform_data), so, you have to make sure your user doesn't
use that field for something else.
Currently I am using this field for bus parameters such as pclk polarity.
If there is an API (bus parameter) to set this after probing the sensor, that
may work too. I will check your latest driver and let you know if
I see an issue in migrating to this version.
One more note: I'm not sure about where v4l2_device_unregister_subdev()
should be called. In soc-camera the core calls
v4l2_i2c_new_subdev_board(), which then calls
v4l2_device_register_subdev(). Logically, it's also the core that then
calls v4l2_device_unregister_subdev(). Whereas I see many other client
drivers call v4l2_device_unregister_subdev() internally. So, if your
bridge driver does not call v4l2_device_unregister_subdev() itself and
expects the client to call it, there will be a slight problem with that
too.
In my bridge driver also v4l2_i2c_new_subdev_board() is called to load
up the sub device. When the bridge driver is removed (remove() call), it calls
v4l2_device_unregister() which will unregister the v4l2 device and all
sub devices (in turn calls v4l2_device_unregister_subdev()). But most
of the sub devices also calls v4l2_device_unregister_subdev() in the
remove() function of the module (so also the version of the mt9t031
that I use). So even if that call is kept in the mt9t031 sensor driver (not
sure if someone use it as a standalone driver), it would just return since the
v4l2_dev ptr in sd ptr would have been set to null as a result of the bridge
driver remove() call. What do you think?
See also some comments below..
drivers/media/video/mt9t031.c | 146 -
1 files changed, 70 insertions(+), 76 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index c95c277..49357bd 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -204,6 +204,59 @@ static unsigned long mt9t031_query_bus_param(struct
soc_camera_device *icd)
return soc_camera_apply_sensor_flags(icl, MT9T031_BUS_PARAM);
}
+static const struct v4l2_queryctrl mt9t031_controls[] = {
+ {
+ .id = V4L2_CID_VFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Vertically,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_HFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Horizontally,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_GAIN,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Gain,
+ .minimum= 0,
+ .maximum= 127,
+ .step = 1,
+ .default_value = 64,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Exposure,
+ .minimum= 1,
+ .maximum= 255,
+ .step = 1,
+ .default_value = 255,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE_AUTO,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Automatic Exposure,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 1,
+ }
+};
+
+static struct soc_camera_ops mt9t031_ops = {
+ .set_bus_param = mt9t031_set_bus_param,
+
Tunning information of Granada, Spain
The attached file es-Granada is the tunning information of my city: Granada (Spain) (Location: 37,183334 N - 3,78 W) Could someone please add this information to the dvb-apps repository? Thanks. [dvb-t/es-Granada] T 76200 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 77000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 83400 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 84200 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 85000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 85800 8MHz 2/3 NONE QAM64 8k 1/4 NONE
Re: Hauppage HVR-2250 Tuning problems
Steven, I tried adding some 2 way splitters for attenuation. Each one was -3dB, and I got up to about 5 total, with no change. I didn't get a chance to try under windows (for various reasons mostly related to time and lack of a Windows install CD), but I did get some evidence that it might be the card. I have a friend at work with the same card which he has been using without problems for a while now (in Fedora 10). He took my card home and swapped it for his working card and it didn't work. He said that he got a message saying that the card couldn't lock and that he could either try waiting longer or try another channel. He did both and he still couldn't get a lock. Unless there is some other reason that you can't just swap two working HVR-2250s in a working system and have the system still work, I'm inclined to believe I got a bad one. --dan On Wed, Oct 28, 2009 at 8:12 AM, Steven Toth st...@kernellabs.com wrote: On Wed, Oct 28, 2009 at 10:08 AM, Steven Toth st...@kernellabs.com wrote: On Wed, Oct 28, 2009 at 1:44 AM, dan danwalke...@gmail.com wrote: I do have 2 2-way splitters between the card in the wall. I tried hooking the card straight to the cable outlet on the wall and ran some more tests. It's a little difficult, because there's only one cable outlet in my whole apartment, and it means doing some re-arranging and being offline while I'm running the tests. Removing splitters proves it's probably not a weak signal issue (also the SNR or 39 on the TV). Can you apply some attenuation to reduce the overall rf strength? I'm thinking it's too hot. Something must be using your second tuner, mythtv maybe? Oh, and please try the card under windows ideally on the same PC using the same antenna feed, to rule out any card specific issues. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage HVR-2250 Tuning problems
I sort of hinted that I would like to try that and he didn't seem very excited about the idea. I think I'll just RMA the card and hope I have better luck with the replacement. Thanks again for all your help! --dan On Fri, Oct 30, 2009 at 12:09 PM, Steven Toth st...@kernellabs.com wrote: On Fri, Oct 30, 2009 at 1:43 PM, dan danwalke...@gmail.com wrote: Steven, I tried adding some 2 way splitters for attenuation. Each one was -3dB, and I got up to about 5 total, with no change. I didn't get a chance to try under windows (for various reasons mostly related to time and lack of a Windows install CD), but I did get some evidence that it might be the card. I have a friend at work with the same card which he has been using without problems for a while now (in Fedora 10). He took my card home and swapped it for his working card and it didn't work. He said that he got a message saying that the card couldn't lock and that he could either try waiting longer or try another channel. He did both and he still couldn't get a lock. Unless there is some other reason that you can't just swap two working HVR-2250s in a working system and have the system still work, I'm inclined to believe I got a bad one. --dan On Wed, Oct 28, 2009 at 8:12 AM, Steven Toth st...@kernellabs.com wrote: On Wed, Oct 28, 2009 at 10:08 AM, Steven Toth st...@kernellabs.com wrote: On Wed, Oct 28, 2009 at 1:44 AM, dan danwalke...@gmail.com wrote: I do have 2 2-way splitters between the card in the wall. I tried hooking the card straight to the cable outlet on the wall and ran some more tests. It's a little difficult, because there's only one cable outlet in my whole apartment, and it means doing some re-arranging and being offline while I'm running the tests. Removing splitters proves it's probably not a weak signal issue (also the SNR or 39 on the TV). Can you apply some attenuation to reduce the overall rf strength? I'm thinking it's too hot. Something must be using your second tuner, mythtv maybe? Oh, and please try the card under windows ideally on the same PC using the same antenna feed, to rule out any card specific issues. -- Steven Toth - Kernel Labs http://www.kernellabs.com Urgh. It sounds like a card specific problem. Of course, installing your friends card in your system to completely confirm the suspicion would be perfect. Regards, -- Steven Toth - 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/RFC 8b/9 v3] rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add platform data
It has been experimentally found out, that the sensor only supports up to
512x384 video output and also has some restrictions on minimum scale. We
disable non-working size ranges until, maybe, someone finds out how to properly
set them up. Also add cropping support, an auto white balance control, platform
data to specify master clock frequency and polarity of the IOCTL pin. Add
this data to the kfr2r09 board.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
...and part b. I also incremented the version, because I also swapped
functions to reduce the diff, but the content is exactly the same.
arch/sh/boards/mach-kfr2r09/setup.c | 13 ++-
drivers/media/video/rj54n1cb0c.c| 282 ---
include/media/rj54n1cb0c.h | 19 +++
3 files changed, 260 insertions(+), 54 deletions(-)
create mode 100644 include/media/rj54n1cb0c.h
diff --git a/arch/sh/boards/mach-kfr2r09/setup.c
b/arch/sh/boards/mach-kfr2r09/setup.c
index ce01d6a..18df641 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -18,6 +18,7 @@
#include linux/input.h
#include linux/i2c.h
#include linux/usb/r8a66597.h
+#include media/rj54n1cb0c.h
#include media/soc_camera.h
#include media/sh_mobile_ceu.h
#include video/sh_mobile_lcdc.h
@@ -254,6 +255,9 @@ static struct i2c_board_info kfr2r09_i2c_camera = {
static struct clk *camera_clk;
+/* set VIO_CKO clock to 25MHz */
+#define CEU_MCLK_FREQ 2500
+
#define DRVCRB 0xA405018C
static int camera_power(struct device *dev, int mode)
{
@@ -266,8 +270,7 @@ static int camera_power(struct device *dev, int mode)
if (IS_ERR(camera_clk))
return PTR_ERR(camera_clk);
- /* set VIO_CKO clock to 25MHz */
- rate = clk_round_rate(camera_clk, 2500);
+ rate = clk_round_rate(camera_clk, CEU_MCLK_FREQ);
ret = clk_set_rate(camera_clk, rate);
if (ret 0)
goto eclkrate;
@@ -317,11 +320,17 @@ eclkrate:
return ret;
}
+static struct rj54n1_pdata rj54n1_priv = {
+ .mclk_freq = CEU_MCLK_FREQ,
+ .ioctl_high = false,
+};
+
static struct soc_camera_link rj54n1_link = {
.power = camera_power,
.board_info = kfr2r09_i2c_camera,
.i2c_adapter_id = 1,
.module_name= rj54n1cb0c,
+ .priv = rj54n1_priv,
};
static struct platform_device kfr2r09_camera = {
diff --git a/drivers/media/video/rj54n1cb0c.c b/drivers/media/video/rj54n1cb0c.c
index 0c998e8..6c4cba2 100644
--- a/drivers/media/video/rj54n1cb0c.c
+++ b/drivers/media/video/rj54n1cb0c.c
@@ -16,6 +16,7 @@
#include media/v4l2-subdev.h
#include media/v4l2-chip-ident.h
#include media/soc_camera.h
+#include media/rj54n1cb0c.h
#define RJ54N1_DEV_CODE0x0400
#define RJ54N1_DEV_CODE2 0x0401
@@ -38,6 +39,7 @@
#define RJ54N1_H_OBEN_OFS 0x0413
#define RJ54N1_V_OBEN_OFS 0x0414
#define RJ54N1_RESIZE_CONTROL 0x0415
+#define RJ54N1_STILL_CONTROL 0x0417
#define RJ54N1_INC_USE_SEL_H 0x0425
#define RJ54N1_INC_USE_SEL_L 0x0426
#define RJ54N1_MIRROR_STILL_MODE 0x0427
@@ -49,10 +51,21 @@
#define RJ54N1_RA_SEL_UL 0x0530
#define RJ54N1_BYTE_SWAP 0x0531
#define RJ54N1_OUT_SIGPO 0x053b
+#define RJ54N1_WB_SEL_WEIGHT_I 0x054e
+#define RJ54N1_BIT8_WB 0x0569
+#define RJ54N1_HCAPS_WB0x056a
+#define RJ54N1_VCAPS_WB0x056b
+#define RJ54N1_HCAPE_WB0x056c
+#define RJ54N1_VCAPE_WB0x056d
+#define RJ54N1_EXPOSURE_CONTROL0x058c
#define RJ54N1_FRAME_LENGTH_S_H0x0595
#define RJ54N1_FRAME_LENGTH_S_L0x0596
#define RJ54N1_FRAME_LENGTH_P_H0x0597
#define RJ54N1_FRAME_LENGTH_P_L0x0598
+#define RJ54N1_PEAK_H 0x05b7
+#define RJ54N1_PEAK_50 0x05b8
+#define RJ54N1_PEAK_60 0x05b9
+#define RJ54N1_PEAK_DIFF 0x05ba
#define RJ54N1_IOC 0x05ef
#define RJ54N1_TG_BYPASS 0x0700
#define RJ54N1_PLL_L 0x0701
@@ -68,6 +81,7 @@
#define RJ54N1_OCLK_SEL_EN 0x0713
#define RJ54N1_CLK_RST 0x0717
#define RJ54N1_RESET_STANDBY 0x0718
+#define RJ54N1_FWFLG 0x07fe
#define E_EXCLK(1 7)
#define SOFT_STDBY (1 4)
@@ -78,11 +92,18 @@
#define RESIZE_HOLD_SEL(1 2)
#define RESIZE_GO (1 1)
+/*
+ * When cropping, the camera automatically centers the cropped region, there
+ * doesn't seem to be a way to specify an explicit location of the rectangle.
+ */
#define
Re: Hauppage HVR-2250 Tuning problems
On Fri, Oct 30, 2009 at 2:19 PM, dan danwalke...@gmail.com wrote: I sort of hinted that I would like to try that and he didn't seem very excited about the idea. I think I'll just RMA the card and hope I have better luck with the replacement. Fair enough. Thanks again for all your help! You're welcome. - Steve -- Steven Toth - 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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:Fri Oct 30 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13234:4ae02a41d03d gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: ERRORS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc3-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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] Possible error in firedtv-1394.o?
On Fri, Oct 30, 2009 at 3:48 PM, Andreas Breitbach andreas.breitb...@gmail.com wrote: Hello all. I subscribed to this mailing list to report a possible error in the above mentioned module. For your better understanding, some details about my situation: I upgraded yesterday from Jaunty(Ubuntu) to the new Karmic. I had a 0ccd:0069 TerraTec Electronic GmbH Cinergy T XE DVB-T Receiver(lsusb output), which worked with the drivers avaible from http://linuxtv.org/hg/~anttip/. After the upgrade, I tried to compile and install the modules necessary for the stick by entering make all. It compiles til reaching firedtv-1394.o, I attached the output, which complains about this specific module. As I'm not a programmer, but rather a normal user who clued together how to get this stick working once, I fear I can not be of much help in debugging. Nonetheless, I'd be very interested in knowing about the status of this and when my TV will be back working(or how I could circumvent this error). Hi Andy, Yeah, this is a known issue with the build process under Karmic. The iee1394 is enabled by default but Karmic's packaging of the kernel headers is missing some files that are needed by the firedtv driver. To workaround the issue, I usually just open v4l/.config and change the firedtv driver from =m to =n. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage HVR-2250 Tuning problems
Is this useful info? I've got the whole log, and haven't updated the code yet. I'm willing to do tests, compile other changesets, etc. Hi Ross, Thanks for writing. Do you have an AMD based system? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage HVR-2250 Tuning problems
Nope, Intel: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz stepping: 11 [...] Ross On Fri, Oct 30, 2009 at 03:58:28PM -0400, Steven Toth wrote: Is this useful info? I've got the whole log, and haven't updated the code yet. I'm willing to do tests, compile other changesets, etc. Hi Ross, Thanks for writing. Do you have an AMD based system? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC 0/9 v2] Image-bus API and accompanying soc-camera patches
On Fri, 30 Oct 2009, Karicheri, Muralidharan wrote: Guennadi, Thanks for updating the driver. I will integrate it when I get a chance and let you know if I see any issues. BTW, Is there someone developing a driver for MT9P031 sensor which is very similar to MT9T031? Do you suggest a separate driver for this sensor or add the support in MT9T031? I need a driver for this and plan to add it soon. It depends on the difference between mt9t031 and mt9p031, of course. I had a brief look at the mt9p031 datasheet while placing it next to mt9t031, and for my taste there are already too many differences to pack them in one driver. MT9T031 was also very similar to MT9M001, I think, but copy-pasting actually served me a bad service:-) there turned out to be too many subtle differences in the end. 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: Hauppage HVR-2250 Tuning problems
Additional info: This system is an HP 'Media Center' m9040n, came with the HVR-1800 mentioned, I also have an pcHDTV-2000 (yes, the original) in there. Motherboard is an ASUS IPIBL-LA, w/ an nVidia GeForce 8400GS. Ross MB specs at: http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01077641tmp_track_link=ot_recdoc/c01154933/en_us/c01077641/loc:1lc=endlc=encc=us On Fri, Oct 30, 2009 at 03:09:22PM -0500, Ross J. Reedstrom wrote: Nope, Intel: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz stepping: 11 [...] Ross On Fri, Oct 30, 2009 at 03:58:28PM -0400, Steven Toth wrote: Is this useful info? I've got the whole log, and haven't updated the code yet. I'm willing to do tests, compile other changesets, etc. Hi Ross, Thanks for writing. Do you have an AMD based system? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC 9/9] mt9t031: make the use of the soc-camera client API optional
On Fri, 30 Oct 2009, Karicheri, Muralidharan wrote:
Guennadi,
Thanks for your time for updating this driver. But I still don't think
it is in a state to be re-used on TI's VPFE platform. Please see
below for my comments.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Friday, October 30, 2009 10:02 AM
To: Linux Media Mailing List
Cc: Hans Verkuil; Laurent Pinchart; Sakari Ailus; Karicheri, Muralidharan
Subject: [PATCH/RFC 9/9] mt9t031: make the use of the soc-camera client API
optional
Now that we have moved most of the functions over to the v4l2-subdev API,
only
quering and setting bus parameters are still performed using the legacy
soc-camera client API. Make the use of this API optional for mt9t031.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Muralidharan, this one is for you to test. To differentiate between the
soc-camera case and a generic user I check i2c client's platform data
(client-dev.platform_data), so, you have to make sure your user doesn't
use that field for something else.
Currently I am using this field for bus parameters such as pclk polarity.
If there is an API (bus parameter) to set this after probing the sensor,
that may work too. I will check your latest driver and let you know if
I see an issue in migrating to this version.
No, that shall come with the bus-configuration API. I was already thinking
about switching to passing a pointer to struct soc_camera_link or
something similar in platform_data, because that's exactly what that
struct is for. Of course, we would have to agree on a specific object with
platform parameters there also for non soc-camera drivers.
One more note: I'm not sure about where v4l2_device_unregister_subdev()
should be called. In soc-camera the core calls
v4l2_i2c_new_subdev_board(), which then calls
v4l2_device_register_subdev(). Logically, it's also the core that then
calls v4l2_device_unregister_subdev(). Whereas I see many other client
drivers call v4l2_device_unregister_subdev() internally. So, if your
bridge driver does not call v4l2_device_unregister_subdev() itself and
expects the client to call it, there will be a slight problem with that
too.
In my bridge driver also v4l2_i2c_new_subdev_board() is called to load
up the sub device. When the bridge driver is removed (remove() call), it
calls v4l2_device_unregister() which will unregister the v4l2 device and
all sub devices (in turn calls v4l2_device_unregister_subdev()). But
most of the sub devices also calls v4l2_device_unregister_subdev() in
the remove() function of the module (so also the version of the mt9t031
that I use). So even if that call is kept in the mt9t031 sensor driver
(not sure if someone use it as a standalone driver), it would just
return since the v4l2_dev ptr in sd ptr would have been set to null as a
result of the bridge driver remove() call. What do you think?
...as long as sd has not been freed yet by then. But in case of mt9t031
the subdevice is embedded in driver-instance object, which is freed, when
the respective i2c device gets unregistered or the driver unloaded. So,
you could call it twice here, yes.
See also some comments below..
drivers/media/video/mt9t031.c | 146 -
1 files changed, 70 insertions(+), 76 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index c95c277..49357bd 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -204,6 +204,59 @@ static unsigned long mt9t031_query_bus_param(struct
soc_camera_device *icd)
return soc_camera_apply_sensor_flags(icl, MT9T031_BUS_PARAM);
}
+static const struct v4l2_queryctrl mt9t031_controls[] = {
+{
+.id = V4L2_CID_VFLIP,
+.type = V4L2_CTRL_TYPE_BOOLEAN,
+.name = Flip Vertically,
+.minimum= 0,
+.maximum= 1,
+.step = 1,
+.default_value = 0,
+}, {
+.id = V4L2_CID_HFLIP,
+.type = V4L2_CTRL_TYPE_BOOLEAN,
+.name = Flip Horizontally,
+.minimum= 0,
+.maximum= 1,
+.step = 1,
+.default_value = 0,
+}, {
+.id = V4L2_CID_GAIN,
+.type = V4L2_CTRL_TYPE_INTEGER,
+.name = Gain,
+.minimum= 0,
+.maximum= 127,
+.step = 1,
+.default_value = 64,
+.flags = V4L2_CTRL_FLAG_SLIDER,
+}, {
+.id = V4L2_CID_EXPOSURE,
+.type =
RE: [PATCH 2/9] v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera
On Fri, 30 Oct 2009, Karicheri, Muralidharan wrote: Guennadi, mt9m111-rect.left = MT9M111_MIN_DARK_COLS; mt9m111-rect.top = MT9M111_MIN_DARK_ROWS; diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c index 6966f64..57e04e9 100644 --- a/drivers/media/video/mt9t031.c +++ b/drivers/media/video/mt9t031.c @@ -301,9 +301,9 @@ static int mt9t031_set_params(struct soc_camera_device *icd, ret = reg_write(client, MT9T031_WINDOW_WIDTH, rect-width - 1); if (ret = 0) ret = reg_write(client, MT9T031_WINDOW_HEIGHT, -rect-height + icd-y_skip_top - 1); +rect-height - 1); Why y_skip_top is removed? Because noone ever said they needed it? When I connect the sensor output to our SOC input and do format conversion and resize on the fly (frame by frame conversion before writing to SDRAM) I have found that the frame completion interrupt fails to get generated with zero value for y_skip_top. I have used a value of 10 and it worked fine for me. So I would like to have a s_skip_top_lines() in the sensor operations which can be called to update this value from the host/bridge driver. Hm, strange, that's actually not the purpose of this parameter. Wouldn't it work for you just as well, if you just request 10 more lines when sending s_fmt from your bridge driver? 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: Hauppage HVR-2250 Tuning problems
Steven - Thanks for all the driver work. Do you want bug reports for the -stable branch on the list, or both to you and the list? (looked around a bit, couldn't find a community how to report a bug) I've recently installed an HVR-2250 (to replace an HVR-1800 that had some surface mount component blow a crater out, right near the bus connector!) in a Mythbuntu box, running mythtv 0.21.0+fixes18207-0ubuntu4~hardy1, kernel 2.6.24-24.61 And have the digital tuning working w/ your stable driver (cloned from kernellabs on 10/16: I don't know hg well enough to how to report a specific source set) It's been working well, until one evening my wife reported that two shows stopped recording simultaneously. Checking the logs, I see the occasional pair of i2c errors ( ~ 1 every 12-24 hours): Oct 23 22:48:04 MediaPC kernel: [679597.153063] saa7164_api_i2c_read() error, ret(2) = 0x13 Oct 23 22:48:04 MediaPC kernel: [679597.153072] tda18271_read_regs: ERROR: i2c_transfer returned: -5 Until about 20 min before it locked up, these show up: Oct 27 20:22:45 MediaPC kernel: [1015942.952099] Event timed out Oct 27 20:22:45 MediaPC kernel: [1015942.952107] saa7164_api_i2c_read() error, ret(1) = 0x32 Oct 27 20:22:45 MediaPC kernel: [1015942.952110] s5h1411_readreg: readreg error (ret == -5) and the occasional: Oct 27 20:23:06 MediaPC kernel: [1015963.906731] Event timed out Oct 27 20:23:06 MediaPC kernel: [1015963.906741] saa7164_api_i2c_write() error, ret(1) = 0x32 Oct 27 20:23:06 MediaPC kernel: [1015963.906744] s5h1411_writereg: writereg error 0x19 0xf7 0x, ret == -5) in blocks, one set a second for a few seconds, then a few second gap. Note at this point, it's still recording both shows. There are many, many more read than write errors: 232644 read errors between 20:22:45 and 20:44:10, 168 write errors. Finally, this changes to: Oct 27 20:44:10 MediaPC kernel: [1017225.901272] Event timed out Oct 27 20:44:10 MediaPC kernel: [1017225.901282] saa7164_api_i2c_read() error, ret(1) = 0x32 Oct 27 20:44:10 MediaPC kernel: [1017225.901286] s5h1411_readreg: readreg error (ret == -5) Oct 27 20:44:10 MediaPC kernel: [1017225.901301] saa7164_cmd_send() No free sequences Oct 27 20:44:10 MediaPC kernel: [1017225.901303] saa7164_api_i2c_write() error, ret(1) = 0xc Oct 27 20:44:10 MediaPC kernel: [1017225.901306] s5h1411_writereg: writereg error 0x19 0xf7 0x, ret == -5) And both recordings lock up. I rebooted to clear the error,and I'm back to the occasional read error (~1 a day) Not sure if it's been pushed that hard since (recording off both tuners simultaneously) Is this useful info? I've got the whole log, and haven't updated the code yet. I'm willing to do tests, compile other changesets, etc. Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 The Connexions Project http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE -- 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
Steven T. any chance your next 'project' could be.....
A dual tuner PCI-E DVB-S2 card? A fair few people are probably now trying to move away from legacy (PCI) kit and at the moment the DVB-S2 PCIe area is quite badly served. I realise it's dependant upon your time availability and getting hold of hardware/information to develop a driver, however if you could keep it in mind that would be great. If there's a particular card that catches your eye let me know and I'll see if I can help sourcing one. Regards -- 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 video4linux] For STLabs PCI saa7134 analog receiver card
Hello Michael, Am Freitag, den 30.10.2009, 22:03 +0700 schrieb Flink Dinky: Hello Hermann, I apologize to you and the list about the quality of my patch. I'm not really a programmer. I've been using the patch below for years now and it was cobbled together from the windows Dscaler tv program. patches are always welcome and coding style is not a problem. But especially on saa7130 devices, we have a lot of different OEMs using invalid PCI subsystem IDs derived from the original Philips PCI vendor/device IDs and they do create a mess. After reading your email I looked through the saa7134-cards.c and found what looked like an identical card which is listed in saa7134.h as: #define SAA7134_BOARD_10MOONSTVMASTER3 116 if I load the saa7134 module like this: modprobe saa7134 card=116 tuner=5 It works just the same as my patch. Yes, that is what happens in most such cases if you start to look closer. But also all three pins high in the mask turned to 0 seem to be needed to get TV sound from the tuner then. However, there are still variants of such cards, some with and some without analog radio, also with different remotes etc. In this case, to know if the remote does work too now, could help to make a decision how to further deal with it. My card is a no name brand. It's an STLabs PCI TV Tuner card with a firewire port (which is autodetected by the kernel and has always worked). There are _some_ of such ST cards and it is not more no name than others. Also for cards with old can/tin tuners per TV standard, but sold globally with different tuners, we can't detect the tuner type, and in most cases it is not even worth to think about, if the tuner type might be coded somewhere in eeprom content or placement of gpio resistors, since they already fail on proper usage of the PCI subvendor and device. In most cases they don't have any further info than this mistake in the eeprom. I'm probably the only guy still using this card but what if I'm not? Can you put something in the Documentation to let them know? Thanks for your report, seems to be around in India and China ... We should still remove that early invalid and now duplicate 10moons saa7130 from auto detection and can of course start some guide lines for how to deal with such cards in CARDLIST.saa7134 too, but we'll need links to the old bttv-gallery.de and the current wiki to really help people to identify such unpleasant cards most easily, if we have enough there. Cheers, Hermann If you need any info email me with instructions on what to do. Otherwise my problem is solved. Thanks for your help. On Fri, Oct 30, 2009 at 6:38 AM, hermann pitton hermann-pit...@arcor.de wrote: Hi Michael, Am Donnerstag, den 29.10.2009, 23:07 +0700 schrieb flinkdeldinky: The following patch provides functionality for the STLabs PCI TV receiver card. It only adds some information to saa7134.h and saa7134-cards.c The card is auto detected as a 10 MOONS card but that will not work. I still can't see how your card could make it in that way and how Mauro could make a decision in that direction, assuming you pass patchwork once. I load the saa7134 module with: saa7134 card=175 tuner=5 In that case, having the Philips reference boards 0x2001 subdevice twice now for a saa7130, remove the auto detection for the 10MOONS too and drop the one for yours. Also, the tuners are different, but not everybody has the opportunity to test them on their differences. In this case, tuner=5 and TUNER_LG_PAL_NEW_TAPC makes a big difference for the UHF switch. Likely you can't test it and sit on a clone anyway. See more inline. I have not tested the remote control or the s-video. Everything else works. Tuners 3, 5, 14, 20, 28, 29, 48 seem to work equally well. diff -r d6c09c3711b5 linux/drivers/media/video/saa7134/saa7134-cards.c --- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Sep 20 15:14:21 2009 + +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Oct 29 14:54:31 2009 +0700 Run at least make checkpatch once on recent mercurial v4l-dvb. For what I can see, you have spaces instead of tabs in front of your lines and also you are filling them up with useless spaces at the ends and for new lines. @@ -5342,7 +5342,38 @@ .amux = LINE2, } }, }, - +
