Re: [PATCH] gspca pac7302: add USB PID range based on heuristics
On Wed, 24 Feb 2010 08:09:41 +0100 Németh Márton wrote: > On the schematics in PixArt PAC7301/PAC7302 datasheet > (http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf) > pages 19, 20, 21 and 22 there is a note titled "PID IO_TRAP" which > describes the possible product ID range 0x2620..0x262f. In this range > there are some known webcams, however, there are some PIDs with > unknown or future devices. Because PixArt PAC7301/PAC7302 is a System > on a Chip (SoC) device is is probable that this driver will work > correctly independent of the used PID. Hello, I got such information from ms-win drivers. I appeared that most of the unknown/new webcams were never manufactured. Now, I wait for user requests before adding such webcams. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: Status of the patches under review (29 patches)
Hi Mauro On Wed, 24 Feb 2010, Mauro Carvalho Chehab wrote: > Hi, > > I suspect that Linus should be releasing the 2.6.33 kernel any time soon, > so the next merge window is about to open. I've handled already everything > on my pending queues. However, I missed some emails due to a crash on my > exim filter. Also, patchwork.kernel.org missed some emails due to some > trouble there. So, maybe there are still some unnoticed pending stuff. Looks like you missed about two of my pull requests. > If you still have any pending work for 2.6.34 that aren't merged nor > are under review, please submit it ASAP, as patches received after the > release of 2.6.33 will likely be postponed to 2.6.35. Namely: > == soc_camera patches - Waiting Guennadi > submission/review == > > Feb, 9 2010: mt9t031: use runtime pm support to restore ADDRESS_MODE > registers http://patchwork.kernel.org/patch/77997 This one depends on my runtime-pm patch (which is not listed here btw), which we didn't come to a consensus about, so, I think, I'll just push both of them and let you decide whether or not to pull. > Feb,19 2010: v4l: soc_camera: fix bound checking of mbus_fmt[] index > http://patchwork.kernel.org/patch/80757 This one (http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/16068/match=pull+soc+camera) and > Feb, 2 2010: [1/3] soc-camera: mt9t112: modify exiting conditions from > standby mode http://patchwork.kernel.org/patch/76212 this one are in fixes branch of http://git.linuxtv.org/gliakhovetski/soc-camera.git?a=shortlog;h=refs/heads/fixes which I asked you to pull in http://www.spinics.net/lists/linux-media/msg16281.html > Feb, 2 2010: [2/3] soc-camera: mt9t112: modify delay time after initialize > http://patchwork.kernel.org/patch/76213 > Feb, 2 2010: [3/3] soc-camera: mt9t112: The flag which control camera-init is > http://patchwork.kernel.org/patch/76214 These two have been put on hold by Morimoto-san. 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 1/2] gspca pac7302: add LED control
On Wed, 24 Feb 2010 07:52:14 +0100
Németh Márton wrote:
> On Labtec Webcam 2200 there is a feedback LED which can be controlled
> independent from the streaming. The feedback LED can be used from
> user space application to show for example detected motion or to
> distinguish between the preview and "on-air" state of the video
> stream.
[snip]
> +#define PAC7302_CID_LED (V4L2_CID_PRIVATE_BASE + 0)
[snip]
Hello,
Private controls must not be used. LED control should be generic (I
have many requests for that).
In March 2009, I proposed to add a V4L2_CID_LEDS control ("[PATCH] LED
control"), but someone told me to use the sysfs led interface instead.
After looking at this interface, I thought it was too complex for our
purpose and no easy for the users.
Maybe it is time to argue again...
Cheers.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] gspca pac7302: add USB PID range based on heuristics
From: Márton Németh
On the schematics in PixArt PAC7301/PAC7302 datasheet
(http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf)
pages 19, 20, 21 and 22 there is a note titled "PID IO_TRAP" which describes
the possible product ID range 0x2620..0x262f. In this range there are some
known webcams, however, there are some PIDs with unknown or future devices.
Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is
probable that this driver will work correctly independent of the used PID.
Signed-off-by: Márton Németh
---
diff -r dfa82cf98a85 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sat Jan 30 20:03:02 2010 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 31 11:08:21 2010 +0100
@@ -96,6 +96,7 @@
u8 flags;
#define FL_HFLIP 0x01 /* mirrored by default */
#define FL_VFLIP 0x02 /* vertical flipped by default */
+#define FL_EXPERIMENTAL 0x80 /* USB IDs based on heuristic without any known
product */
u8 sof_read;
u8 autogain_ignore_frames;
@@ -1220,17 +1221,33 @@
};
/* -- module initialisation -- */
+/* Note on FL_EXPERIMENTAL:
+ * On the schematics in PixArt PAC7301/PAC7302 datasheet
+ *
(http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf)
+ * pages 19, 20, 21 and 22 there is a note titled "PID IO_TRAP" which describes
+ * the possible product ID range 0x2620..0x262f. In this range there are some
+ * known webcams, however, there are some PIDs with unknown or future devices.
+ * Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is
+ * probable that this driver will work correctly independent of the used PID.
+ */
static const struct usb_device_id device_table[] __devinitconst = {
{USB_DEVICE(0x06f8, 0x3009)},
{USB_DEVICE(0x093a, 0x2620)},
{USB_DEVICE(0x093a, 0x2621)},
{USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP},
+ {USB_DEVICE(0x093a, 0x2623), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP},
+ {USB_DEVICE(0x093a, 0x2625), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2626)},
+ {USB_DEVICE(0x093a, 0x2627), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2628)},
{USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP},
{USB_DEVICE(0x093a, 0x262a)},
+ {USB_DEVICE(0x093a, 0x262b), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x262c)},
+ {USB_DEVICE(0x093a, 0x262d), .driver_info = FL_EXPERIMENTAL },
+ {USB_DEVICE(0x093a, 0x262e), .driver_info = FL_EXPERIMENTAL },
+ {USB_DEVICE(0x093a, 0x262f), .driver_info = FL_EXPERIMENTAL },
{}
};
MODULE_DEVICE_TABLE(usb, device_table);
@@ -1239,6 +1256,17 @@
static int __devinit sd_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
+ if ((u8)id->driver_info & FL_EXPERIMENTAL) {
+ PDEBUG(D_ERR | D_PROBE, "WARNING: USB device ID %04x:%04x is "
+ "not known, but based on some heuristics this driver "
+ "tries to handle it.",
+ id->idVendor, id->idProduct);
+ PDEBUG(D_ERR | D_PROBE, "WARNING: Plase send an email to "
+ "linux-media@vger.kernel.org with 'lsusb -v' output, "
+ "the vendor and name of the product and whether the "
+ "device is working or not.");
+ }
+
return gspca_dev_probe(intf, id, &sd_desc, sizeof(struct sd),
THIS_MODULE);
}
--
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] soc_camera: match signedness of soc_camera_limit_side()
Hi Guennadi,
Guennadi Liakhovetski wrote:
> Hi Németh
>
> On Tue, 9 Feb 2010, Guennadi Liakhovetski wrote:
>
>> Ok, I modified your patch a bit, how about the below version? If you
>> agree, I'll commit it in that form (after converting to utf-8):
>>
>> From: Márton Németh
>>
>> The first two parameters of soc_camera_limit_side() are usually pointers
>> to struct v4l2_rect elements. They are signed, so adjust the prototype
>> accordingly.
>>
>> This will remove the following sparse warning (see "make C=1"):
>>
>> * incorrect type in argument 1 (different signedness)
>>expected unsigned int *start
>>got signed int *
>>
>> as well as a couple more signedness mismatches.
>>
>> Signed-off-by: Márton Németh
>> Signed-off-by: Guennadi Liakhovetski
>
> please confirm, if you agree with my version of your patch, or I'll have
> to leave it out from my pull request.
I confirm.
Sorry about the late response, I was not able to access my emails for a while.
Regards,
Márton Németh
>> ---
>> diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
>> index 1a34d29..e5bae4c 100644
>> --- a/drivers/media/video/mt9v022.c
>> +++ b/drivers/media/video/mt9v022.c
>> @@ -325,7 +325,7 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
>> v4l2_crop *a)
>> if (ret < 0)
>> return ret;
>>
>> -dev_dbg(&client->dev, "Frame %ux%u pixel\n", rect.width, rect.height);
>> +dev_dbg(&client->dev, "Frame %dx%d pixel\n", rect.width, rect.height);
>>
>> mt9v022->rect = rect;
>>
>> diff --git a/drivers/media/video/mx3_camera.c
>> b/drivers/media/video/mx3_camera.c
>> index bd297f5..d477e30 100644
>> --- a/drivers/media/video/mx3_camera.c
>> +++ b/drivers/media/video/mx3_camera.c
>> @@ -796,7 +796,7 @@ static int acquire_dma_channel(struct mx3_camera_dev
>> *mx3_cam)
>> * FIXME: learn to use stride != width, then we can keep stride properly
>> aligned
>> * and support arbitrary (even) widths.
>> */
>> -static inline void stride_align(__s32 *width)
>> +static inline void stride_align(__u32 *width)
>> {
>> if (((*width + 7) & ~7) < 4096)
>> *width = (*width + 7) & ~7;
>> @@ -844,7 +844,7 @@ static int mx3_camera_set_crop(struct soc_camera_device
>> *icd,
>> * So far only direct camera-to-memory is supported
>> */
>> if (channel_change_requested(icd, rect)) {
>> -int ret = acquire_dma_channel(mx3_cam);
>> +ret = acquire_dma_channel(mx3_cam);
>> if (ret < 0)
>> return ret;
>> }
>> diff --git a/drivers/media/video/rj54n1cb0c.c
>> b/drivers/media/video/rj54n1cb0c.c
>> index 9277194..bbd9c11 100644
>> --- a/drivers/media/video/rj54n1cb0c.c
>> +++ b/drivers/media/video/rj54n1cb0c.c
>> @@ -555,15 +555,15 @@ static int rj54n1_commit(struct i2c_client *client)
>> return ret;
>> }
>>
>> -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
>> - u32 *out_w, u32 *out_h);
>> +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
>> + s32 *out_w, s32 *out_h);
>>
>> static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
>> {
>> struct i2c_client *client = sd->priv;
>> struct rj54n1 *rj54n1 = to_rj54n1(client);
>> struct v4l2_rect *rect = &a->c;
>> -unsigned int dummy = 0, output_w, output_h,
>> +int dummy = 0, output_w, output_h,
>> input_w = rect->width, input_h = rect->height;
>> int ret;
>>
>> @@ -577,7 +577,7 @@ static int rj54n1_s_crop(struct v4l2_subdev *sd, struct
>> v4l2_crop *a)
>> output_w = (input_w * 1024 + rj54n1->resize / 2) / rj54n1->resize;
>> output_h = (input_h * 1024 + rj54n1->resize / 2) / rj54n1->resize;
>>
>> -dev_dbg(&client->dev, "Scaling for %ux%u : %u = %ux%u\n",
>> +dev_dbg(&client->dev, "Scaling for %dx%d : %u = %dx%d\n",
>> input_w, input_h, rj54n1->resize, output_w, output_h);
>>
>> ret = rj54n1_sensor_scale(sd, &input_w, &input_h, &output_w, &output_h);
>> @@ -638,8 +638,8 @@ static int rj54n1_g_fmt(struct v4l2_subdev *sd,
>> * the output one, updates the window sizes and returns an error or the
>> resize
>> * coefficient on success. Note: we only use the "Fixed Scaling" on this
>> camera.
>> */
>> -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
>> - u32 *out_w, u32 *out_h)
>> +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
>> + s32 *out_w, s32 *out_h)
>> {
>> struct i2c_client *client = sd->priv;
>> struct rj54n1 *rj54n1 = to_rj54n1(client);
>> @@ -749,7 +749,7 @@ static int rj54n1_sensor_scale(struct v4l2_subdev *sd,
>> u32 *in_w, u32 *in_h,
>> * improve the image quality or stability for larger frames (see commen
[PATCH 2/2] gspca pac7302: remove LED blinking when switching stream on and off
From: Márton Németh
The init sequences for PAC7302 contained register settings affecting
the LED state which can result blinking of the LED when it is set to
always on or always off. The blinking happened when the stream was
switched on or off.
Remove the register changes from the init sequence and handle it with
the function set_streaming_led().
Signed-off-by: Márton Németh
---
--- a/linux/drivers/media/video/gspca/pac7302.c 2010-02-08 20:46:47.0
+0100
+++ b/linux/drivers/media/video/gspca/pac7302.c 2010-02-08 20:48:04.0
+0100
@@ -331,13 +331,6 @@ static const struct v4l2_pix_format vga_
#define END_OF_SEQUENCE0
/* pac 7302 */
-static const __u8 init_7302[] = {
-/* index,value */
- 0xff, 0x01, /* page 1 */
- 0x78, 0x00, /* deactivate */
- 0xff, 0x01,
- 0x78, 0x40, /* led off */
-};
static const __u8 start_7302[] = {
/* index, len, [value]* */
0xff, 1,0x00, /* page 0 */
@@ -373,7 +366,8 @@ static const __u8 start_7302[] = {
0xff, 1,0x01, /* page 1 */
0x12, 3,0x02, 0x00, 0x01,
0x3e, 2,0x00, 0x00,
- 0x76, 5,0x01, 0x20, 0x40, 0x00, 0xf2,
+ 0x76, 2,0x01, 0x20,
+ 0x79, 2,0x00, 0xf2,
0x7c, 1,0x00,
0x7f, 10, 0x4b, 0x0f, 0x01, 0x2c, 0x02, 0x58, 0x03, 0x20,
0x02, 0x00,
@@ -397,8 +391,6 @@ static const __u8 start_7302[] = {
0x2a, 5,0xc8, 0x00, 0x18, 0x12, 0x22,
0x64, 8,0x00, 0x00, 0xf0, 0x01, 0x14, 0x44, 0x44, 0x44,
0x6e, 1,0x08,
- 0xff, 1,0x01, /* page 1 */
- 0x78, 1,0x00,
0, END_OF_SEQUENCE /* end of sequence */
};
@@ -496,15 +488,6 @@ static void reg_w(struct gspca_dev *gspc
}
}
-static void reg_w_seq(struct gspca_dev *gspca_dev,
- const __u8 *seq, int len)
-{
- while (--len >= 0) {
- reg_w(gspca_dev, seq[0], seq[1]);
- seq += 2;
- }
-}
-
/* load the beginning of a page */
static void reg_w_page(struct gspca_dev *gspca_dev,
const __u8 *page, int len)
@@ -774,7 +757,7 @@ static void set_streaming_led(struct gsp
/* this function is called at probe and resume time for pac7302 */
static int sd_init(struct gspca_dev *gspca_dev)
{
- reg_w_seq(gspca_dev, init_7302, sizeof(init_7302)/2);
+ set_streaming_led(gspca_dev, 0);
return gspca_dev->usb_err;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] gspca pac7302: add LED control
From: Márton Németh
On Labtec Webcam 2200 there is a feedback LED which can be controlled
independent from the streaming. The feedback LED can be used from
user space application to show for example detected motion or to
distinguish between the preview and "on-air" state of the video stream.
The default value of the LED control is "Auto" which keeps the previous
behaviour: LED is off when the stream is off, LED is on if the stream is
on.
Signed-off-by: Márton Németh
---
diff -r 4f102b2f7ac1 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Thu Jan 28 20:35:40 2010 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Mon Feb 08 20:46:53 2010 +0100
@@ -6,6 +6,7 @@
*
* Separated from Pixart PAC7311 library by Márton Németh
* Camera button input handling by Márton Németh
+ * LED control by Márton Németh
* Copyright (C) 2009-2010 Márton Németh
*
* This program is free software; you can redistribute it and/or modify
@@ -62,6 +63,7 @@
0 | 0xc6 | setwhitebalance()
0 | 0xc7 | setbluebalance()
0 | 0xdc | setbrightcont(), setcolors()
+1 | 0x78 | set_streaming_led()
3 | 0x02 | setexposure()
3 | 0x10 | setgain()
3 | 0x11 | setcolors(), setgain(), setexposure(), sethvflip()
@@ -78,6 +80,11 @@
MODULE_DESCRIPTION("Pixart PAC7302");
MODULE_LICENSE("GPL");
+#define PAC7302_CID_LED (V4L2_CID_PRIVATE_BASE + 0)
+#define LED_AUTO 0
+#define LED_ON 1
+#define LED_OFF2
+
/* specific webcam descriptor for pac7302 */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
@@ -91,6 +98,7 @@
unsigned char gain;
unsigned char exposure;
unsigned char autogain;
+ unsigned char led;
__u8 hflip;
__u8 vflip;
u8 flags;
@@ -126,6 +134,8 @@
static int sd_getgain(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setexposure(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val);
+static int sd_setled(struct gspca_dev *gspca_dev, __s32 val);
+static int sd_getled(struct gspca_dev *gspca_dev, __s32 *val);
static const struct ctrl sd_ctrls[] = {
/* This control is pac7302 only */
@@ -293,6 +303,20 @@
.set = sd_setvflip,
.get = sd_getvflip,
},
+ {
+ {
+ .id = PAC7302_CID_LED,
+ .type= V4L2_CTRL_TYPE_MENU,
+ .name= "LED",
+ .minimum = 0,
+ .maximum = 2, /* 0: Auto, 1: On, 2: Off */
+ .step= 1,
+#define LED_DEF 0
+ .default_value = LED_DEF,
+ },
+ .set = sd_setled,
+ .get = sd_getled,
+ },
};
static const struct v4l2_pix_format vga_mode[] = {
@@ -572,6 +596,7 @@
sd->gain = GAIN_DEF;
sd->exposure = EXPOSURE_DEF;
sd->autogain = AUTOGAIN_DEF;
+ sd->led = LED_DEF;
sd->hflip = HFLIP_DEF;
sd->vflip = VFLIP_DEF;
sd->flags = id->driver_info;
@@ -716,6 +741,36 @@
reg_w(gspca_dev, 0x11, 0x01);
}
+static void set_streaming_led(struct gspca_dev *gspca_dev, u8 streaming)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ u8 data = 0;
+
+ switch (sd->led) {
+ case LED_AUTO:
+ if (streaming)
+ data = 0x01;
+ else
+ data = 0x40;
+ break;
+ case LED_ON:
+ if (streaming)
+ data = 0x01;
+ else
+ data = 0x00;
+ break;
+ case LED_OFF:
+ if (streaming)
+ data = 0x41;
+ else
+ data = 0x40;
+ break;
+ }
+
+ reg_w(gspca_dev, 0xff, 0x01);
+ reg_w(gspca_dev, 0x78, data);
+}
+
/* this function is called at probe and resume time for pac7302 */
static int sd_init(struct gspca_dev *gspca_dev)
{
@@ -747,18 +802,15 @@
atomic_set(&sd->avg_lum, -1);
/* start stream */
- reg_w(gspca_dev, 0xff, 0x01);
- reg_w(gspca_dev, 0x78, 0x01);
+ set_streaming_led(gspca_dev, 1);
return gspca_dev->usb_err;
}
static void sd_stopN(struct gspca_dev *gspca_dev)
{
-
/* stop stream */
- reg_w(gspca_dev, 0xff, 0x01);
- reg_w(gspca_dev, 0x78, 0x00);
+ set_streaming_led(gspca_dev, 0);
}
/* called on streamoff with alt 0 and on disconnect for pac7302 */
@@ -766,8 +818,7 @@
{
if (!gspca_dev->present)
return;
- reg_w(gspca_dev, 0xff, 0x01);
- reg_w(gspca_dev, 0x78, 0x40);
+ set_streaming_led(gspca_dev, 0);
}
/* Include pac common sof detection functions */
@@ -1121,6 +1172,44 @@
return 0;
}
+static int sd_setled(struct gspca_dev *gspca_dev, __s32 val)
+{
+ struct sd *sd
Re: [ANNOUNCE] git tree repositories & libv4l
On 16:51 Tue 23 Feb 2010, Hans de Goede wrote: > On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote: > >Hans de Goede wrote: > > > >>Ok, so this will give me a local tree, how do I get this onto > >>linuxtv.org ? > > > >I added it. In thesis, it is open for commit to you, me, hverkuil > >and dougsland. > > > > I see good, thanks! Can someone (Douglas ?) with better hg / git > powers then me please somehow import all the libv4l changes from: > http://linuxtv.org/hg/~hgoede/libv4l > > Once that is done I'll retire my own tree, and move all my userspace > work to the git tree. > > For starters I plan to create / modify Makefiles so that everything > will build out of the box, and has proper make install targets which > can be used by distro's > > So: > -proper honoring of CFLAGS > -work with standard (and possibly somewhat older kernel headers) > -honor DESTDIR, PREFIX and LIBDIR when doing make install Do you still want me to convert to autoconf? I was still planning on doing that. We discussed it a month ago when this conversation started. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009 > When I'm satisfied (and have created some proof of concept packages > for Fedora to make sure everything is reasonably usable for > distros). I'll send a mail to the list announcing my intend to > release a 0.8.0 version (building on top of existing libv4l release > scheme to make clear which libv4l version is included). If there are > then no objections / bugs found I'll do a 0.8.0 release . Ack, sounds good. Thanks, Brandon -- 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
Status of the patches under review (29 patches)
Hi, I suspect that Linus should be releasing the 2.6.33 kernel any time soon, so the next merge window is about to open. I've handled already everything on my pending queues. However, I missed some emails due to a crash on my exim filter. Also, patchwork.kernel.org missed some emails due to some trouble there. So, maybe there are still some unnoticed pending stuff. If you still have any pending work for 2.6.34 that aren't merged nor are under review, please submit it ASAP, as patches received after the release of 2.6.33 will likely be postponed to 2.6.35. Cheers, Mauro -- This is the summary of the patches that are currently under review. Each patch is represented by its submission date, the subject (up to 70 chars) and the patchwork link (if submitted via email). == Videobuf patch - Need more tests before committing it - Volunteers? == Jan,19 2010: [v1,1/1] V4L: Add sync before a hardware operation to videobuf. http://patchwork.kernel.org/patch/73896 == Waiting for Muralidharan Karicheri review == Feb,19 2010: video_device: don't free_irq() an element past array vpif_obj.dev[]http://patchwork.kernel.org/patch/80845 == Waiting for Tobias Lorenz review == Feb, 3 2010: radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner()http://patchwork.kernel.org/patch/76786 == waiting for Jean Delvare final submission after tests == Jan,30 2010: saa7134: Fix IR support of some ASUS TV-FM 7135 variants http://patchwork.kernel.org/patch/75883 == Waiting for its addition at linux-firmware and driver test by David Wong == Nov, 1 2009: lgs8gxx: remove firmware for lgs8g75 http://patchwork.kernel.org/patch/56822 == Andy Walls and Aleksandr Piskunov are discussing around the solution == Oct,11 2009: AVerTV MCE 116 Plus radio http://patchwork.kernel.org/patch/52981 == Patches waiting for Patrick Boettcher review == Jan,15 2010: remove obsolete conditionalizing on DVB_DIBCOM_DEBUG http://patchwork.kernel.org/patch/73147 Feb, 8 2010: dib7000p: reduce large stack usage http://patchwork.kernel.org/patch/77891 Feb, 8 2010: dib3000mc: reduce large stack usage http://patchwork.kernel.org/patch/77892 == IR driver for IMON - Will likely go via drivers/input tree == Dec,31 2009: [v2] input: imon driver for SoundGraph iMON/Antec Veris IR devices http://patchwork.kernel.org/patch/70348 == Waiting Helmut Auer to get the Signed-off-by from Dirk Herrendoerfer == Feb,11 2010: Add support for SMT7020 to cx88 http://patchwork.kernel.org/patch/78823 == Gspca patches - Waiting Hans de Goede submission/review == Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown packet received http://patchwork.kernel.org/patch/75837 == Gspca patches - Waiting Jean-Francois Moine submission/review == Jan,31 2010: [RFC] gspca pac7302: add USB PID range based on heuristics http://patchwork.kernel.org/patch/75960 Jan,14 2010: Problem with gspca and zc3xx http://patchwork.kernel.org/patch/72895 == soc_camera patches - Waiting Guennadi submission/review == Feb, 9 2010: mt9t031: use runtime pm support to restore ADDRESS_MODE registers http://patchwork.kernel.org/patch/77997 Feb,19 2010: v4l: soc_camera: fix bound checking of mbus_fmt[] index http://patchwork.kernel.org/patch/80757 Feb, 2 2010: [1/3] soc-camera: mt9t112: modify exiting conditions from standby mode http://patchwork.kernel.org/patch/76212 Feb, 2 2010: [2/3] soc-camera: mt9t112: modify delay time after initialize http://patchwork.kernel.org/patch/76213 Feb, 2 2010: [3/3] soc-camera: mt9t112: The flag which control camera-init is http://patchwork.kernel.org/patch/76214 == Waiting for my fixes on Docbook == Feb,17 2010: [1/4] DocBook/Makefile: Make it less verbose http://patchwork.kernel.org/patch/79981 Feb,17 2010: [2/4] DocBook: Add rules to auto-generate some media docbooks http://patchwork.kernel.org/patch/79983 Feb,17 2010: [3/4] DocBook/v4l/pixfmt.xml: Add missing formats for gspca cpia1 and http://patchwork.kernel.org/patch/79985 Feb,17 2010: [4/4] V4L/DVB: v4l: document new Bayer and monochrome pixel formatshttp://patchwork.kernel.org/patch/79987 == Waiting for Steven Toth comments on it == Feb, 6 2010: cx23885: Enable Message Signaled Interrupts(MSI). http://patchwork.kernel.org/patch/77492 == Patch(broken) Lock fixes. Patch is wrong but Siano has lock pro
RE: [PATCH 3/9] tvp514x: add YUYV format support
> -Original Message-
> From: Muralidharan Karicheri [mailto:mkarich...@gmail.com]
> Sent: Wednesday, February 24, 2010 5:15 AM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org;
> hverk...@xs4all.nl; davinci-linux-open-sou...@linux.davincidsp.com;
> Karicheri, Muralidharan
> Subject: Re: [PATCH 3/9] tvp514x: add YUYV format support
>
> Vaibhav,
>
>
> On Mon, Jan 4, 2010 at 9:02 AM, wrote:
> > From: Vaibhav Hiremath
> >
> >
> > Signed-off-by: Vaibhav Hiremath
> > ---
> > drivers/media/video/tvp514x.c | 7 +++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
> > index 4cf3593..b344b58 100644
> > --- a/drivers/media/video/tvp514x.c
> > +++ b/drivers/media/video/tvp514x.c
> > @@ -212,6 +212,13 @@ static const struct v4l2_fmtdesc tvp514x_fmt_list[] =
> {
> > .description = "8-bit UYVY 4:2:2 Format",
> > .pixelformat = V4L2_PIX_FMT_UYVY,
> > },
> > + {
> > + .index = 1,
> > + .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
> > + .flags = 0,
> > + .description = "8-bit YUYV 4:2:2 Format",
> > + .pixelformat = V4L2_PIX_FMT_YUYV,
> > + },
> > };
>
> As per data sheet I can see only CbYCrY format output from the tvp5146
> which translate to UYVY. How are you configuring tvp to output YUYV? I
> don;t see any change to the code to configure this format.
>
[Hiremath, Vaibhav] Yes you are right, actually this is dummy format created to
support YUYV.
> CCDC can switch the CbCr order and also can swap Y/C order. So if you
> are achieving
> this via ccdc configuration, there is no need to add this format to tvp5146
> IMO.
>
[Hiremath, Vaibhav] I think it makes sense to handle this is master driver,
since we are handling this in CCDC. It could possible in the future TVP5146
might get used with SoC which don't have this capability.
Thanks,
Vaibhav
> -Murali
>
> >
> > /**
> > --
> > 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
> >
>
>
>
> --
> Murali Karicheri
> mkarich...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of operation
> -Original Message-
> From: Muralidharan Karicheri [mailto:mkarich...@gmail.com]
> Sent: Wednesday, February 24, 2010 4:53 AM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org;
> hverk...@xs4all.nl; Karicheri, Muralidharan
> Subject: Re: [PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of
> operation
>
> Vaibhav,
>
> There are changes to vpfe capture on Arago tree on top of this. For
> example, vpfe_uservirt_to_phys() is removed and is replaced with
> videobuf_iolock(). So please get the latest changes to upstream.
>
[Hiremath, Vaibhav] No, the Arago version doesn't support USERPTR mode at all,
1386if (V4L2_MEMORY_USERPTR == req_buf->memory) {
1386 /* we don't support user ptr IO */
1387 v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_reqbufs:"
1388 " USERPTR IO not supported\n");
1389 return -EINVAL;
1390 }
And also, I have received important comment from Mauro, which expects some code
tobe moved to generic VideoBuf layer. I will be submitting patch for the same
separately.
Thanks,
Vaibhav
> Murali
>
> On Tue, Feb 23, 2010 at 3:34 AM, wrote:
> > From: Vaibhav Hiremath
> >
> >
> > Signed-off-by: Vaibhav Hiremath
> > Signed-off-by: Muralidharan Karicheri
> > ---
> > drivers/media/video/ti-media/vpfe_capture.c | 94
> ++
> > 1 files changed, 79 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/media/video/ti-media/vpfe_capture.c
> b/drivers/media/video/ti-media/vpfe_capture.c
> > index cece265..7d4ab44 100644
> > --- a/drivers/media/video/ti-media/vpfe_capture.c
> > +++ b/drivers/media/video/ti-media/vpfe_capture.c
> > @@ -538,7 +538,24 @@ static void vpfe_schedule_next_buffer(struct
> vpfe_device *vpfe_dev)
> > struct videobuf_buffer, queue);
> > list_del(&vpfe_dev->next_frm->queue);
> > vpfe_dev->next_frm->state = VIDEOBUF_ACTIVE;
> > - addr = videobuf_to_dma_contig(vpfe_dev->next_frm);
> > + if (V4L2_MEMORY_USERPTR == vpfe_dev->memory)
> > + addr = vpfe_dev->cur_frm->boff;
> > + else
> > + addr = videobuf_to_dma_contig(vpfe_dev->next_frm);
> > +
> > + ccdc_dev->hw_ops.setfbaddr(addr);
> > +}
> > +
> > +static void vpfe_schedule_bottom_field(struct vpfe_device *vpfe_dev)
> > +{
> > + unsigned long addr;
> > +
> > + if (V4L2_MEMORY_USERPTR == vpfe_dev->memory)
> > + addr = vpfe_dev->cur_frm->boff;
> > + else
> > + addr = videobuf_to_dma_contig(vpfe_dev->cur_frm);
> > +
> > + addr += vpfe_dev->field_off;
> > ccdc_dev->hw_ops.setfbaddr(addr);
> > }
> >
> > @@ -559,7 +576,6 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
> > {
> > struct vpfe_device *vpfe_dev = dev_id;
> > enum v4l2_field field;
> > - unsigned long addr;
> > int fid;
> >
> > v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "\nStarting
> vpfe_isr...\n");
> > @@ -604,10 +620,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
> > * the CCDC memory address
> > */
> > if (field == V4L2_FIELD_SEQ_TB) {
> > - addr =
> > - videobuf_to_dma_contig(vpfe_dev-
> >cur_frm);
> > - addr += vpfe_dev->field_off;
> > - ccdc_dev->hw_ops.setfbaddr(addr);
> > + vpfe_schedule_bottom_field(vpfe_dev);
> > }
> > goto clear_intr;
> > }
> > @@ -1234,7 +1247,10 @@ static int vpfe_videobuf_setup(struct
> videobuf_queue *vq,
> > struct vpfe_device *vpfe_dev = fh->vpfe_dev;
> >
> > v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_buffer_setup\n");
> > - *size = config_params.device_bufsize;
> > + *size = vpfe_dev->fmt.fmt.pix.sizeimage;
> > + if (vpfe_dev->memory == V4L2_MEMORY_MMAP &&
> > + vpfe_dev->fmt.fmt.pix.sizeimage >
> config_params.device_bufsize)
> > + *size = config_params.device_bufsize;
> >
> > if (*count < config_params.min_numbuffers)
> > *count = config_params.min_numbuffers;
> > @@ -1243,6 +1259,46 @@ static int vpfe_videobuf_setup(struct
> videobuf_queue *vq,
> > return 0;
> > }
> >
> > +/*
> > + * vpfe_uservirt_to_phys: This function is used to convert user
> > + * space virtual address to physical address.
> > + */
> > +static u32 vpfe_uservirt_to_phys(struct vpfe_device *vpfe_dev, u32 virtp)
> > +{
> > + struct mm_struct *mm = current->mm;
> > + unsigned long physp = 0;
> > + struct vm_area_struct *vma;
> > +
> > + vma = find_vma(mm, virtp);
> > +
> > + /* For kernel direct-mapped memory, take the easy way */
> > + if (virtp >= PAGE_OFFSET)
> > +
Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-tscheck
Abylai Ospan wrote: > Mauro, > > Please pull change: > > http://udev.netup.ru/hg/v4l-dvb-aospan-tscheck/rev/0fdeb662c7f6 > > "Allow to enable TS continuity and TEI check on loaded module". > > Current dvb_demux_tscheck processing doesn't allow to enable check on loaded > module. dvb_demux_tscheck can be enabled only when loading module ( > dvb_dmx_init should be called to enable dvb_demux_tscheck ). This patch > fix this issue. > > Thanks. NACK. It is not safe to use vmalloc at dvb_dmx_swfilter_packet(), as this function can be called during interrupt time, and vmalloc can sleep. -- Cheers, Mauro -- 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] radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner()
Tobias Lorenz wrote:
> Hello Mauro,
>
>>> no, the default value of retval makes no difference to the function.
>>>
>>> Retval is set by si470x_disconnect_check and si470x_set_register.
>>> After each call, retval is checked.
>>> There is no need to reset it passed.
>
>> You may just do then:
>>
>> int retval = si470x_disconnect_check(radio);
>
> In all other set/get functions of v4l2_ioctl_ops in the driver, I just set
> the default value of retval to 0.
> To be identical in si470x_vidioc_s_tuner, I modified the patch to the one
> below.
> I already pushed this and another cosmetic patch into mercurial:
>
> http://linuxtv.org/hg/~tlorenz/v4l-dvb/rev/72a2f38d5956
See comment bellow.
> http://linuxtv.org/hg/~tlorenz/v4l-dvb/rev/3efd5d32a618
Applied.
>
> Mauro, can you pull them?
Tobias, next time or send one patch per email or send me a pull request.
>
> Bye,
> Tobias
>
> --- a/linux/drivers/media/radio/si470x/radio-si470x-common.c Thu Feb 11
> 23:11:30 2010 -0200
> +++ b/linux/drivers/media/radio/si470x/radio-si470x-common.c Thu Feb 18
> 20:31:33 2010 +0100
> @@ -748,7 +748,7 @@
> struct v4l2_tuner *tuner)
> {
> struct si470x_device *radio = video_drvdata(file);
> - int retval = -EINVAL;
> + int retval = 0;
>
> /* safety checks */
> retval = si470x_disconnect_check(radio);
This really doesn't make any sense. Just do:
int retval = i470x_disconnect_check(radio);
or
int retval;
retval = i470x_disconnect_check(radio);
--
Cheers,
Mauro
--
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 v1] dvb_dummy_adapter
This patch implements a dvb_dummy_adapter module capable of creating up
to DVB_MAX_ADAPTERS software DVB adapters. It's probably not much good
except for testing applications. It works with femon. I have not
tested writing to the dvr0 device and reading back yet.
One can instantiate adapeters with different dummy frontends:
# modprobe dvb_dummy_adapter debug=1 fe_type=0,1,2,1
Will yield 4 adapters with dummy DVB-C, DVB-T, DVB-S, and DVB-T
frontends.
Since I stole a good bit of this from the dvb portion of the cx18
driver, I suspect I have too many items set up the device
initialization.
Comments welcome.
Signed-off-by: Andy Walls
diff -r 9d3b80c9f15a linux/drivers/media/dvb/Kconfig
--- a/linux/drivers/media/dvb/Kconfig Thu Feb 18 20:56:08 2010 -0200
+++ b/linux/drivers/media/dvb/Kconfig Tue Feb 23 23:21:23 2010 -0500
@@ -80,6 +80,10 @@
depends on DVB_CORE && PCI && I2C
source "drivers/media/dvb/ngene/Kconfig"
+comment "Supported Dummy DVB Adapters"
+ depends on DVB_CORE
+ source "drivers/media/dvb/dummy/Kconfig"
+
comment "Supported DVB Frontends"
depends on DVB_CORE
source "drivers/media/dvb/frontends/Kconfig"
diff -r 9d3b80c9f15a linux/drivers/media/dvb/Makefile
--- a/linux/drivers/media/dvb/Makefile Thu Feb 18 20:56:08 2010 -0200
+++ b/linux/drivers/media/dvb/Makefile Tue Feb 23 23:21:23 2010 -0500
@@ -15,6 +15,7 @@
dm1105/ \
pt1/\
mantis/ \
- ngene/
+ ngene/ \
+ dummy/
obj-$(CONFIG_DVB_FIREDTV) += firewire/
diff -r 9d3b80c9f15a linux/drivers/media/dvb/dummy/Kconfig
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/dummy/Kconfig Tue Feb 23 23:21:23 2010 -0500
@@ -0,0 +1,10 @@
+config DVB_DUMMY_ADAPTER
+ tristate "Dummy DVB adapter driver"
+ depends on DVB_CORE
+ select DVB_DUMMY_FE if !DVB_FE_CUSTOMISE
+ default n
+ help
+ A software only dummy DVB adapter driver. Possibly useful for
+ application test and development without using actual DVB hardware.
+
+ Most people will want to say N for this driver.
diff -r 9d3b80c9f15a linux/drivers/media/dvb/dummy/Makefile
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/dummy/MakefileTue Feb 23 23:21:23 2010 -0500
@@ -0,0 +1,3 @@
+obj-$(CONFIG_DVB_DUMMY_ADAPTER) += dvb_dummy_adapter.o
+
+EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/ -Idrivers/media/dvb/frontends/
diff -r 9d3b80c9f15a linux/drivers/media/dvb/dummy/dvb_dummy_adapter.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/dummy/dvb_dummy_adapter.c Tue Feb 23 23:21:23
2010 -0500
@@ -0,0 +1,364 @@
+/*
+ * Dummy DVB adapter driver
+ *
+ * Copyright (C) 2010 Andy Walls
+ *
+ * Partially based on cx18-dvb.c driver code
+ * Copyright (C) 2008 Steve Toth
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include "dvb_demux.h"
+#include "dvb_frontend.h"
+#include "dvb_net.h"
+#include "dvbdev.h"
+#include "dmxdev.h"
+#include "dvb_dummy_fe.h"
+
+MODULE_AUTHOR("Andy Walls");
+MODULE_DESCRIPTION("Dummy DVB adapter driver");
+MODULE_LICENSE("GPL");
+#define DVB_DUMMY_VERSION "0:0.1"
+MODULE_VERSION(DVB_DUMMY_VERSION);
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+static int debug;
+
+static int fe_type[DVB_MAX_ADAPTERS];
+static unsigned int fe_type_c = 1;
+
+module_param(debug, int, 0644);
+module_param_array(fe_type, int, &fe_type_c, 0644);
+
+MODULE_PARM_DESC(debug, "Debug level. Default: 0");
+MODULE_PARM_DESC(fe_type, "Frontend type\n"
+ "\t\t\t0: DVB-C\n"
+ "\t\t\t1: DVB-T\n"
+ "\t\t\t2: DVB-S\n"
+ "\t\t\tDefault: 0: DVB-C");
+
+struct dvb_dummy {
+ struct platform_device *plat_dev;
+ int instance;
+
+ struct dmx_frontend hw_frontend;
+ struct dmx_frontend mem_frontend;
+ struct dmxdev dmxdev;
+ struct dvb_adapter dvb_adapter;
+ struct dvb_demux demux;
+ struct dvb_frontend *fe;
+ struct dvb_net dvbnet;
+
+ int feeding;
+ struct mutex feedlock; /* protects feeding variable */
+
Re: [HG PULL] http://linuxtv.org/hg/~awalls/ivtv-changes
On Tue, 2010-02-23 at 21:20 -0300, Mauro Carvalho Chehab wrote: > Andy Walls wrote: > > On Mon, 2010-02-22 at 18:45 -0300, Mauro Carvalho Chehab wrote: > >> Andy Walls wrote: > > I'll apply the patch, but I think you should later remove the volatile from > struct ivtv_mailbox_data & friends. You might need some memory barriers > around the places this var is used (f. example, by using smp_wmb). OK. Thanks. I won't be able to clean up the volatile out of the ivtv driver until at least Sunday. Regards, Andy -- 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: [ANNOUNCE] git tree repositories & libv4l
Am Dienstag, den 23.02.2010, 13:45 +0400 schrieb Manu Abraham: > On Tue, Feb 23, 2010 at 4:41 AM, Mauro Carvalho Chehab > wrote: > > Brandon Philips wrote: > >> On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote: > >>> On Monday 22 February 2010 23:54:26 Brandon Philips wrote: > On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: > >> lib/ > >> libv4l1/ > >> libv4l2/ > >> libv4lconvert/ > >> utils/ > >> v4l2-dbg > >> v4l2-ctl > >> cx18-ctl > >> ivtv-ctl > >> contrib/ > >> test/ > >> everything else > >> > git clone git://ifup.org/philips/create-v4l-utils.git > cd create-v4l-utils/ > ./convert.sh > > You should now have v4l-utils.git which should have this directory > struture. If we need to move other things around let me know and I can > tweak name-filter.sh > > Thoughts? Let me know how we should proceed with dropping v4l2-apps > from v4l-dvb. > > Re: code style cleanup. I think we should do that once we drop > v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. > >>> Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was > >>> merged into dvb-apps, but while that tool supports dvb, it also supports > >>> v4l2. Just like we merged dvb and v4l in a single repository, so I think > >>> we > >>> should also merge the tools to a media-utils repository. > >>> > >>> It remains a fact of life that dvb and v4l are connected and trying to > >>> artificially keep them apart does not make much sense to me. > >> > >> Easy to do but who should be the maintainer of the dvb things? > >> > >> According to the wiki[1] these tools are without a maintainer. So, if > >> no one cares about them enough to make releases why merge them and > >> clutter up the git tree with dead code? > >> > >> Cheers, > >> > >> Brandon > >> > >> [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps > > > > That's weird. I've recently added support for ISDB-T on it: > >http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ > > > That's probably Michael Krufky (user: Jon2856) from what i guess, he > has been the one who has been making ground for propaganda's on the > wiki. Manu, you are actively calling the trolls back again with such accusations! It is the other way round, you own him at least one clear excuse. Cheers, Hermann > > and we've got some comments at the mailing list. Btw, the patches > > I added there also adds DVB-S2 support to szap/scan, but tests > > are needed, since I don't have any satellite dish nowadays. > > > Btw, I did spend time to review your code before it is pulled in. You > did not even provide a reply on my last mail on the subject, or did I > miss that reply of yours ? > > > Regards, > Manu -- 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 - next] MAINTAINERS: Telegent tlg2300 section fix
thanks. Acked-by: Huang Shijie linux-next commit 2ff8223957d901999bf76aaf2c6183e33a6ad14e exposes an infinite loop defect in scripts/get_maintainer.pl Fix the incorrect format of the MAINTAINERS "M:" entries. Signed-off-by: Joe Perches --- diff --git a/MAINTAINERS b/MAINTAINERS index 57305f6..e633460 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4775,13 +4775,12 @@ F: drivers/media/video/*7146* F:include/media/*7146* TLG2300 VIDEO4LINUX-2 DRIVER -M Huang Shijie -M Kang Yong -M Zhang Xiaobing +M: Huang Shijie +M: Kang Yong +M: Zhang Xiaobing S:Supported F:drivers/media/video/tlg2300 - SC1200 WDT DRIVER M:Zwane Mwaikambo S:Maintained -- 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 - next] MAINTAINERS: Telegent tlg2300 section fix
linux-next commit 2ff8223957d901999bf76aaf2c6183e33a6ad14e exposes an infinite loop defect in scripts/get_maintainer.pl Fix the incorrect format of the MAINTAINERS "M:" entries. Signed-off-by: Joe Perches thanks , acked by : Huang Shijie --- diff --git a/MAINTAINERS b/MAINTAINERS index 57305f6..e633460 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4775,13 +4775,12 @@ F: drivers/media/video/*7146* F:include/media/*7146* TLG2300 VIDEO4LINUX-2 DRIVER -M Huang Shijie -M Kang Yong -M Zhang Xiaobing +M: Huang Shijie +M: Kang Yong +M: Zhang Xiaobing S:Supported F:drivers/media/video/tlg2300 - SC1200 WDT DRIVER M:Zwane Mwaikambo S:Maintained -- 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: [ANNOUNCE] git tree repositories & libv4l
Hans de Goede wrote: > Hi, > > On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote: >> Hans de Goede wrote: >> >>> Ok, so this will give me a local tree, how do I get this onto >>> linuxtv.org ? >> >> I added it. In thesis, it is open for commit to you, me, hverkuil and >> dougsland. >> > > I see good, thanks! Can someone (Douglas ?) with better hg / git powers > then me please > somehow import all the libv4l changes from: > http://linuxtv.org/hg/~hgoede/libv4l Ok, I added there. The procedure were simple: I ran Brandon script again, but after pulling from your tree. Then, I used git format-patch to generate a quilt series, and used git quiltimport on the correct -git tree. > Once that is done I'll retire my own tree, and move all my userspace > work to > the git tree. > > For starters I plan to create / modify Makefiles so that everything will > build > out of the box, and has proper make install targets which can be used by > distro's > > So: > -proper honoring of CFLAGS > -work with standard (and possibly somewhat older kernel headers) > -honor DESTDIR, PREFIX and LIBDIR when doing make install The better here is to have the latest kernel headers copied on the tree. This way, it is possible to compile libv4l2 with an older kernel version and later upgrade the kernel, if needed, or to use a fast machine to compile it, and then use it on another machine. -- Cheers, Mauro -- 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: [HG PULL] http://linuxtv.org/hg/~awalls/ivtv-changes
Andy Walls wrote:
> On Mon, 2010-02-22 at 18:45 -0300, Mauro Carvalho Chehab wrote:
>> Andy Walls wrote:
>>> Mauro,
>>>
>>> Please pull from http://linuxtv.org/hg/~awalls/ivtv-changes
>>>
>>> for the following 4 changesets:
>>>
>>> 01/04: ivtv: Fix ivtv_api_get_data() to avoid unneeded IO during IRQ
>>> handling
>>> http://linuxtv.org/hg/~awalls/ivtv-changes?cmd=changeset;node=4090ec224ef2
>> Hmm:
>>
>> WARNING: Use of volatile is usually wrong: see
>> Documentation/volatile-considered-harmful.txt
>> #89: FILE: drivers/media/video/ivtv/ivtv-mailbox.c:375:
>> + volatile u32 __iomem *p = mbdata->mbox[mb].data;
>
> :)
>
> Take out the "volatile" and you get a gcc compiler warning, because the
> type of the mbdata->mbox variable is "volatile".
>
> struct ivtv_mailbox_data {
> volatile struct ivtv_mailbox __iomem *mbox;
> [...]
> };
>
> void ivtv_api_get_data(struct ivtv_mailbox_data *mbdata, int mb,
>int argc, u32 data[])
> {
> volatile u32 __iomem *p = mbdata->mbox[mb].data;
> int i;
> for (i = 0; i < argc; i++, p++)
> data[i] = readl(p);
> }
>
>
> Using
>
> data[i] = readl(p);
>
> in the code above is a little more efficient than
>
> data[i] = readl(mbdata->mbox[mb].data[i]);
>
> So if you *really* don't like the checkpatch.pl warning, I could change
> the code to do that.
>
> However doing that would be somewhat backwards. The checkpatch.pl
> warning is for people who do not understand that "volatile" only
> supresses optimizations and that it doesn't provide locking. I don't
> need locking here, and readl() is going to supress optimization anyway
> due to its use of "volatile" on its input argument:
>
> static inline u32 __raw_readl(const volatile void __iomem *addr)
> {
> return *(const volatile u32 __force *) addr;
> }
>
> #define readl(addr) __le32_to_cpu(__raw_readl(addr))
>
>
> So the "volatile" warning from checkpatch.pl is a false positive in this
> case.
>
>> Is the driver missing some locks?
>
> Nope. And "volatile" would not help with a locking problem anyway.
>
I'll apply the patch, but I think you should later remove the volatile from
struct ivtv_mailbox_data & friends. You might need some memory barriers
around the places this var is used (f. example, by using smp_wmb).
--
Cheers,
Mauro
--
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/9] tvp514x: add YUYV format support
Vaibhav,
On Mon, Jan 4, 2010 at 9:02 AM, wrote:
> From: Vaibhav Hiremath
>
>
> Signed-off-by: Vaibhav Hiremath
> ---
> drivers/media/video/tvp514x.c | 7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
> index 4cf3593..b344b58 100644
> --- a/drivers/media/video/tvp514x.c
> +++ b/drivers/media/video/tvp514x.c
> @@ -212,6 +212,13 @@ static const struct v4l2_fmtdesc tvp514x_fmt_list[] = {
> .description = "8-bit UYVY 4:2:2 Format",
> .pixelformat = V4L2_PIX_FMT_UYVY,
> },
> + {
> + .index = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
> + .flags = 0,
> + .description = "8-bit YUYV 4:2:2 Format",
> + .pixelformat = V4L2_PIX_FMT_YUYV,
> + },
> };
As per data sheet I can see only CbYCrY format output from the tvp5146
which translate to UYVY. How are you configuring tvp to output YUYV? I
don;t see any change to the code to configure this format.
CCDC can switch the CbCr order and also can swap Y/C order. So if you
are achieving
this via ccdc configuration, there is no need to add this format to tvp5146 IMO.
-Murali
>
> /**
> --
> 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
>
--
Murali Karicheri
mkarich...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of operation
Vaibhav,
There are changes to vpfe capture on Arago tree on top of this. For
example, vpfe_uservirt_to_phys() is removed and is replaced with
videobuf_iolock(). So please get the latest changes to upstream.
Murali
On Tue, Feb 23, 2010 at 3:34 AM, wrote:
> From: Vaibhav Hiremath
>
>
> Signed-off-by: Vaibhav Hiremath
> Signed-off-by: Muralidharan Karicheri
> ---
> drivers/media/video/ti-media/vpfe_capture.c | 94 ++
> 1 files changed, 79 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/video/ti-media/vpfe_capture.c
> b/drivers/media/video/ti-media/vpfe_capture.c
> index cece265..7d4ab44 100644
> --- a/drivers/media/video/ti-media/vpfe_capture.c
> +++ b/drivers/media/video/ti-media/vpfe_capture.c
> @@ -538,7 +538,24 @@ static void vpfe_schedule_next_buffer(struct vpfe_device
> *vpfe_dev)
> struct videobuf_buffer, queue);
> list_del(&vpfe_dev->next_frm->queue);
> vpfe_dev->next_frm->state = VIDEOBUF_ACTIVE;
> - addr = videobuf_to_dma_contig(vpfe_dev->next_frm);
> + if (V4L2_MEMORY_USERPTR == vpfe_dev->memory)
> + addr = vpfe_dev->cur_frm->boff;
> + else
> + addr = videobuf_to_dma_contig(vpfe_dev->next_frm);
> +
> + ccdc_dev->hw_ops.setfbaddr(addr);
> +}
> +
> +static void vpfe_schedule_bottom_field(struct vpfe_device *vpfe_dev)
> +{
> + unsigned long addr;
> +
> + if (V4L2_MEMORY_USERPTR == vpfe_dev->memory)
> + addr = vpfe_dev->cur_frm->boff;
> + else
> + addr = videobuf_to_dma_contig(vpfe_dev->cur_frm);
> +
> + addr += vpfe_dev->field_off;
> ccdc_dev->hw_ops.setfbaddr(addr);
> }
>
> @@ -559,7 +576,6 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
> {
> struct vpfe_device *vpfe_dev = dev_id;
> enum v4l2_field field;
> - unsigned long addr;
> int fid;
>
> v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "\nStarting vpfe_isr...\n");
> @@ -604,10 +620,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
> * the CCDC memory address
> */
> if (field == V4L2_FIELD_SEQ_TB) {
> - addr =
> - videobuf_to_dma_contig(vpfe_dev->cur_frm);
> - addr += vpfe_dev->field_off;
> - ccdc_dev->hw_ops.setfbaddr(addr);
> + vpfe_schedule_bottom_field(vpfe_dev);
> }
> goto clear_intr;
> }
> @@ -1234,7 +1247,10 @@ static int vpfe_videobuf_setup(struct videobuf_queue
> *vq,
> struct vpfe_device *vpfe_dev = fh->vpfe_dev;
>
> v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_buffer_setup\n");
> - *size = config_params.device_bufsize;
> + *size = vpfe_dev->fmt.fmt.pix.sizeimage;
> + if (vpfe_dev->memory == V4L2_MEMORY_MMAP &&
> + vpfe_dev->fmt.fmt.pix.sizeimage >
> config_params.device_bufsize)
> + *size = config_params.device_bufsize;
>
> if (*count < config_params.min_numbuffers)
> *count = config_params.min_numbuffers;
> @@ -1243,6 +1259,46 @@ static int vpfe_videobuf_setup(struct videobuf_queue
> *vq,
> return 0;
> }
>
> +/*
> + * vpfe_uservirt_to_phys: This function is used to convert user
> + * space virtual address to physical address.
> + */
> +static u32 vpfe_uservirt_to_phys(struct vpfe_device *vpfe_dev, u32 virtp)
> +{
> + struct mm_struct *mm = current->mm;
> + unsigned long physp = 0;
> + struct vm_area_struct *vma;
> +
> + vma = find_vma(mm, virtp);
> +
> + /* For kernel direct-mapped memory, take the easy way */
> + if (virtp >= PAGE_OFFSET)
> + physp = virt_to_phys((void *)virtp);
> + else if (vma && (vma->vm_flags & VM_IO) && (vma->vm_pgoff))
> + /* this will catch, kernel-allocated, mmaped-to-usermode addr
> */
> + physp = (vma->vm_pgoff << PAGE_SHIFT) + (virtp -
> vma->vm_start);
> + else {
> + /* otherwise, use get_user_pages() for general userland pages
> */
> + int res, nr_pages = 1;
> + struct page *pages;
> + down_read(¤t->mm->mmap_sem);
> +
> + res = get_user_pages(current, current->mm,
> + virtp, nr_pages, 1, 0, &pages, NULL);
> + up_read(¤t->mm->mmap_sem);
> +
> + if (res == nr_pages)
> + physp = __pa(page_address(&pages[0]) +
> + (virtp & ~PAGE_MASK));
> + else {
> + v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
> + "get_user_pages failed\n");
> + return 0;
> + }
> + }
> + return physp;
> +}
> +
> static int vpfe_vide
Re: [linux-dvb] scan-s2 and dvb-apps
Manu Abraham wrote: Please don't hijack threads. It's a basic courtesy. What's being discussed in this thread, is completely different from your patch. seemed relevant to me -- 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: eb1a:2860 eMPIA em28xx device to usb1 ??? usb hub problem?
On Tue, Feb 23, 2010 at 4:17 PM, Dean wrote: > I am receiving NTSC TV signals. I test with mplayer. Example; > > mplayer tv://9 -tv > driver=v4l2:alsa:immediatemode=0:adevice=hw.Em28xxAudio,0:norm=ntsc:chanlist=us-cable > -vf pp=ci > > The above command works fine (both audio and video) with my Hauppauge > HVR-850, but for the Kworld 305U I must change 'immediatemode=0' to > 'immediatemode=1' otherwise the video frame rate is about 1/2 normal speed > and about 1 minute later mplayer starts printing 'video buffer full - > dropping frame'. > > According to dmesg the Kworld 305U loads the same firmware as my Hauppauge > HVR-850, and (during separate test sessions) installs the same ALSA device; > > card 1: Em28xxAudio [Em28xx Audio], device 0: Em28xx Audio [Empia 28xx > Capture] > Subdevices: 0/1 > Subdevice #0: subdevice #0 Try this: open em28xx-cards.c, and change the board profile for the entry EM2880_BOARD_KWORLD_DVB_305U such that it includes the following field: .mts_firmware = 1, Then recompile and see if it starts working. 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: eb1a:2860 eMPIA em28xx device to usb1 ??? usb hub problem?
Devin Heitmueller wrote: > On Tue, Feb 23, 2010 at 1:37 AM, Dean wrote: >> Hi, >> >> I have the KWorld DVB-T 305U, an em28xx device. Only the video works for me >> under Linux, no audio. In case anyone wants to see it, I have attached the >> full dmesg text, solely from this device. >> >> Cheers, >> Dean > > Hi Dean, > > How are you testing the audio, and under what video standard are you > trying to use the device (NTSC/PAL/SECAM)? > > Devin > Devin I am receiving NTSC TV signals. I test with mplayer. Example; mplayer tv://9 -tv driver=v4l2:alsa:immediatemode=0:adevice=hw.Em28xxAudio,0:norm=ntsc:chanlist=us-cable -vf pp=ci The above command works fine (both audio and video) with my Hauppauge HVR-850, but for the Kworld 305U I must change 'immediatemode=0' to 'immediatemode=1' otherwise the video frame rate is about 1/2 normal speed and about 1 minute later mplayer starts printing 'video buffer full - dropping frame'. According to dmesg the Kworld 305U loads the same firmware as my Hauppauge HVR-850, and (during separate test sessions) installs the same ALSA device; card 1: Em28xxAudio [Em28xx Audio], device 0: Em28xx Audio [Empia 28xx Capture] Subdevices: 0/1 Subdevice #0: subdevice #0 Dean -- 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:Tue Feb 23 19:01:07 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14233:2e0444bf93a4 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-rc5-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK spec: OK sparse (v4l-dvb-git): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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
Re: DM1105: could not attach frontend 195d:1105
Ok, no problem happy to help. Nameer Igor M. Liplianin wrote: On 23 февраля 2010 15:12:05 Nameer Kazzaz wrote: Sounds cool, let me know if I can help you with anything. Thanks Nameer Hendrik Skarpeid wrote: No luck here either, still working on it. My plan is to solder som wires on strategic points on the board and debug i2c and other activity with an oscilloscope. Will probably start next week. Nameer Kazzaz wrote: Hey Igor, I'm getting the same error: dm1105 :04:0b.0: could not attach frontend Did you get your one to work. Thanks Nameer Igor M. Liplianin wrote: On 18 февраля 2010, liplia...@me.by wrote: I also got the unbranded dm1105 card. I tried the four possible i2c addresses, just i case. Noen worked of course. Then I traced the i2c pins on the tuner to pins 100 and 101 on the DM1105. These are GPIO pins, so bit-banging i2c on these pins seems to be the solution. scl = p101 = gpio14 sda = p100 = gpio13 Here is the patch to test. Use option card=4. modprobe dm1105 card=4 I didn't test patch in real hardware. But I can connect GPIO14 and GPIO13 to SCL and SDA in any dm1105 card and test whether it works. Then I will ask you to test also. -- 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
My TV's standard video controls (Re: Chroma gain configuration)
On Tue, 2010-02-23 at 10:33 -0500, Andy Walls wrote: > On Tue, 2010-02-23 at 15:41 +0100, Hans Verkuil wrote: > > > On Tue, 2010-02-23 at 08:53 +0100, Hans Verkuil wrote: > > >> On Monday 22 February 2010 23:00:32 Devin Heitmueller wrote: > > >> > On Mon, Feb 22, 2010 at 4:54 PM, Hans Verkuil > > >> wrote: > > > > > >> > Of course, if you and Mauro wanted to sign off on the creation of a > > >> > new non-private user control called V4L2_CID_CHROMA_GAIN, that would > > >> > also resolve my problem. :-) > > >> > > >> Hmm, Mauro is right: the color controls we have now are a bit of a mess. > > >> Perhaps this is a good moment to try and fix them. Suppose we had no > > >> color > > >> controls at all: how would we design them in that case? When we know > > >> what we > > >> really need, then we can compare that with what we have and figure out > > >> what > > >> we need to do to make things right again. > > > Let me rephrase my question: how would you design the user color controls? > > > E.g., the controls that are exported in GUIs to the average user. > > Look at the knobs on an old TV or look at the menu on more modern > televisions: > > 1. Hue (or Tint) (at least NTSC TVs have this control) > 2. Brightness > 3. Saturation > > These are the three parameters to which the Human Visual System > sensitive. These are the video controls exposed on the standard user menu of my Sony KDP-51WS655 TV: Name TV's Help comment Control type My comments Picture Picture white level Slider: 0 to Max (No comment) Brightness Picture black level Slider: 0 to Max (No comment) Color Color saturation Slider: 0 to Max "UV Saturation" Hue Green/Red Tones Slider: R 31 to 0 to G 31 Called "Tint" on older NTSC TV's, it doesn't give complete control over hue Sharpness Picture detail Slider: 0 to Max "Contrast" Color Temp Color Temperature Enumerated options: Cool Bluish-white like a "daylight" light bulb Neutral Neutral (No comment) Warm Reddish-White (NTSC standard) like a "soft white" light bulb Dominant color of light in the image. "Temperature" corresponds to the mean color of light from a blackbody radiator at such a temperature IIRC ClearEdge VM Edge enhancement Enumerated options: High, Medium, Low, Off (No comment) Advanced Video controls available via the normal user menu: Color Axis Adjust red color axis Enumerated values: Default Emphasize red colors (No comment) Monitor De-emphasize red colors (No comment) I have no idea what this control is good for. Noise Reduction Reduces repetative random noise Boolean: on/off I suspect this may be Luma and Chroma coring. I'm not sure. The Service mode menu is available via pushing buttons on the remote: DISPLAY, 5, VOL +, POWER ON The service control and status options are cryptic and numerous. I suppose setting these wrong and saving would be akin to writing the wrong values in the I2C EEPROM on one's video card. (I will note the QM INFO menu has a fascinating amount of status available.) Regards, Andy -- 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: DM1105: could not attach frontend 195d:1105
On 23 февраля 2010 15:12:05 Nameer Kazzaz wrote: > Sounds cool, let me know if I can help you with anything. > > Thanks > Nameer > > Hendrik Skarpeid wrote: > > No luck here either, still working on it. > > My plan is to solder som wires on strategic points on the board and > > debug i2c and other activity with an oscilloscope. Will probably start > > next week. > > > > Nameer Kazzaz wrote: > >> Hey Igor, > >> I'm getting the same error: > >> dm1105 :04:0b.0: could not attach frontend > >> > >> Did you get your one to work. > >> > >> Thanks > >> Nameer > >> > >> Igor M. Liplianin wrote: > >>> On 18 февраля 2010, liplia...@me.by wrote: > I also got the unbranded dm1105 card. I tried the four possible i2c > addresses, just i case. Noen worked of course. Then I traced the i2c > pins on the tuner to pins 100 and 101 on the DM1105. > These are GPIO pins, so bit-banging i2c on these pins seems to be the > solution. > > scl = p101 = gpio14 > sda = p100 = gpio13 > >>> > >>> Here is the patch to test. Use option card=4. > >>> modprobe dm1105 card=4 I didn't test patch in real hardware. But I can connect GPIO14 and GPIO13 to SCL and SDA in any dm1105 card and test whether it works. Then I will ask you to test also. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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] scan-s2 and dvb-apps
Hi Mauro, Please don't hijack threads. It's a basic courtesy. What's being discussed in this thread, is completely different from your patch. Best Regards, Manu -- 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 - next] MAINTAINERS: Telegent tlg2300 section fix
linux-next commit 2ff8223957d901999bf76aaf2c6183e33a6ad14e exposes an infinite loop defect in scripts/get_maintainer.pl Fix the incorrect format of the MAINTAINERS "M:" entries. Signed-off-by: Joe Perches --- diff --git a/MAINTAINERS b/MAINTAINERS index 57305f6..e633460 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4775,13 +4775,12 @@ F: drivers/media/video/*7146* F: include/media/*7146* TLG2300 VIDEO4LINUX-2 DRIVER -M Huang Shijie -M Kang Yong -M Zhang Xiaobing +M: Huang Shijie +M: Kang Yong +M: Zhang Xiaobing S: Supported F: drivers/media/video/tlg2300 - SC1200 WDT DRIVER M: Zwane Mwaikambo S: Maintained -- 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: Hauppague WinTV USB2-stick (tm6010)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 23.02.2010 17:21, schrieb Abhijit Bhopatkar: > On Tuesday 23 Feb 2010 9:45:18 pm Devin Heitmueller wrote: >> On Tue, Feb 23, 2010 at 11:12 AM, Abhijit Bhopatkar >> >> wrote: >>> Is it worth for me to test this latest tree and driver against my card by >>> just adding the device ids? >>> If the devs need some more testing / help i can certainly volunteer my >>> time/efforts. >>> I do have fare familiarity with linux driver development and would be >>> happy to help in debugging/developing support for this tuner. The only >>> thing i don't have is knowledge for making this chipset work. >> >> Don't bother. The driver is known to be broken - badly. It needs >> alot of work, although someone has finally started hacking at the >> tm6000 driver recently (see the mailing list archives for more info). >> > > Devin, thanks for the input > > I see that Stefan is doing some patching/cleanup. > > Stefan, is there anything i can do to help? > > Abhijit I think, you can help to analyse the usb data communication -> what for tuner, demodulator, gpio's etc.? And you can also ask Mauro Carvalho Chehab. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLhAfzAAoJEDX/lZlmjdJlUPYH/RnDzHGSWwC78Nc2FgKDPkYw RFnDOImVo4G+i/Mr0UtZB9JIx75lkntwPeeJVp+aal3tLBECil0eYLco6jTuxcYt V5iBuSZClycyvaWBc+VFi40rJcX3cqG6210GwIzNZMJH41/wPhAj15D4BVauiNsc 8ZhupI0HhM66w5LiO22fYq80WkgTb7dx5UMBVDzhkKNaS4f5mmcvyxWMJZrVzesN Fv36lsp/RnqdmT5GgOR6Bgc/zExyiHIiLmEVclmfKv1ExeuqrwscN8F6eASlqXlK iXQgMYmqEb3jTtKJRzLi4R/Yl0s16iOhvK0AA7AAybBj3liQOZKeh/k5HG3Hf6g= =g/SL -END PGP SIGNATURE- -- 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: eb1a:2860 eMPIA em28xx device to usb1 ??? usb hub problem?
On Tue, Feb 23, 2010 at 1:37 AM, Dean wrote: > Hi, > > I have the KWorld DVB-T 305U, an em28xx device. Only the video works for me > under Linux, no audio. In case anyone wants to see it, I have attached the > full dmesg text, solely from this device. > > Cheers, > Dean Hi Dean, How are you testing the audio, and under what video standard are you trying to use the device (NTSC/PAL/SECAM)? 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: New kernel failed suspend ro ram with m5602 camera
2010/2/8 Erik Andrén :
> 2010/2/6 Lukáš Karas :
>> Hi Erik and others.
>>
>> New kernel (2.6.33-rc*) failed suspend to ram with camera m5602 on my
>> machine.
>> At first, I thought that it's a kernel bug (see
>> http://bugzilla.kernel.org/show_bug.cgi?id=15189) - suspend failed after
>> unload gspca_m5602 module too. But it is more probably a hardware bug, that
>> we
>> can evade with simple udev rule
>>
>> ATTR{idVendor}=="0402", ATTR{idProduct}=="5602",
>> ATTR{power/wakeup}="disabled"
>>
>> I sent this rule to linux-hotplug (udev) mailing list, but answer is
>> (http://www.spinics.net/lists/hotplug/msg03353.html) that this quirk should
>> be
>> in camera driver or should be send to udev from v4l developers...
>>
>> What do you thing about it? It is a general m5602 chip problem or only my
>> hardware combination problem?
> Hi Lukas,
>
> I haven't experienced it so far, but I haven't tried the latest kernel.
> I'll see if I can manage to reproduce the problem later this week.
>
>> How we can put rule into udev userspace library?
>> What I know, in v4l repository isn't directory with general v4l rules. This
>> problem can affect many users with this hardware...
>
> We should definitely try to solve this in the camera driver if possible.
> Would it be possible for you to bisect the kernel tree to see what
> commit that caused this regression?
>
> Best regards,
> Erik
>
>>
>> Best regards,
>> Lukas
>>
>
Hi Lukas,
I cannot reproduce this issue with the linux tip kernel. AFAICT, this
issue only exists with the m5602 connected to a s5k83a sensor. I'm not
sure what the correct solution to this problem is but it would greatly
help if you could perform a git bisect and try to identify what commit
caused this issue.
Best regards,
Erik
--
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: Hauppague WinTV USB2-stick (tm6010)
On Tuesday 23 Feb 2010 9:45:18 pm Devin Heitmueller wrote: > On Tue, Feb 23, 2010 at 11:12 AM, Abhijit Bhopatkar > > wrote: > > Is it worth for me to test this latest tree and driver against my card by > > just adding the device ids? > > If the devs need some more testing / help i can certainly volunteer my > > time/efforts. > > I do have fare familiarity with linux driver development and would be > > happy to help in debugging/developing support for this tuner. The only > > thing i don't have is knowledge for making this chipset work. > > Don't bother. The driver is known to be broken - badly. It needs > alot of work, although someone has finally started hacking at the > tm6000 driver recently (see the mailing list archives for more info). > Devin, thanks for the input I see that Stefan is doing some patching/cleanup. Stefan, is there anything i can do to help? Abhijit -- 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: Hauppague WinTV USB2-stick (tm6010)
On Tue, Feb 23, 2010 at 11:12 AM, Abhijit Bhopatkar wrote: > Is it worth for me to test this latest tree and driver against my card by just > adding the device ids? > If the devs need some more testing / help i can certainly volunteer my > time/efforts. > I do have fare familiarity with linux driver development and would be happy to > help in debugging/developing support for this tuner. The only thing i don't > have is knowledge for making this chipset work. Don't bother. The driver is known to be broken - badly. It needs alot of work, although someone has finally started hacking at the tm6000 driver recently (see the mailing list archives for more info). 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: [linux-dvb] scan-s2 and dvb-apps
Mauro Carvalho Chehab wrote: > Christophe Thommeret wrote: >> Le mardi 23 février 2010 12:36:13, Manu Abraham a écrit : >>> Hi All, >>> >>> Recently, quite some people have been requesting for scan-s2 a simple >>> scan application which has been hacked on top of the scan application >>> as available in the dvb-apps tree, to be integrated/pulled in to the >>> dvb-apps tree, after it's author moved on to other arenas. >>> >>> http://www.mail-archive.com/v...@linuxtv.org/msg11125.html >>> >>> The idea initially was to have a cloned copy of scan as scan-s2. >>> Now, on the other hand scan-s2 is much more like scan and similar >>> functionality wise too. >>> >>> Considering the aspects, do you think, that it is worthwhile to have >>> >>> a) the scan-s2 application and the scan application as well integrated >>> into the repository, such that they both live together >>> >>> or >>> >>> b) scan-s2 does things almost the same as scan2. scan can be replaced >>> by scan-s2. >>> >>> >>> What are your ideas/thoughts on this ? >> I think S2 scanning should simply be added to scan. > > See http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ > > It adds support to DVB API v5 to the dvb-apps library. Originally, this were > done to add ISDB-T support, but the next patches added also DVB-T, DVB-C and > DVB-S support via APIv5. It also adds some DVB-S2 bits there. There are very > few things lacking there to fully implement DVB-S2. It shouldn't be hard to > add there also other standards like DVB-T2, ISDB-S, etc. > In time: this is a work in progress. Currently, it were tested only with ISDB-T (i tested scan/zap and gnutv, all via DVB API v5). The advantage of adding it at the library is that any application using it will also be capable of dealing with the newly produced channel lists (as more fields will be needed to represent the extra attributes of the new standards). I got already some inputs for things to be improved. I'll start handling those after the next kernel merge window. Tests are appreciated, especially with other standards. -- Cheers, Mauro -- 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
Hauppague WinTV USB2-stick (tm6010)
I am unfortunate enough to have a above mentioned tuner card. The windows driver is hcw66xxx.sys According to various posts on this (and old v4l) mailing list, the driver i need is tm6000. However the device id for this tuner is 2040:6610 Only 2040:6600 seems to be recogised by the kernel driver. I am already downloading the latest git trees and i find the driver existing in drivers/staging Is it worth for me to test this latest tree and driver against my card by just adding the device ids? If the devs need some more testing / help i can certainly volunteer my time/efforts. I do have fare familiarity with linux driver development and would be happy to help in debugging/developing support for this tuner. The only thing i don't have is knowledge for making this chipset work. Abhijit -- 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] scan-s2 and dvb-apps
Christophe Thommeret wrote: > Le mardi 23 février 2010 12:36:13, Manu Abraham a écrit : >> Hi All, >> >> Recently, quite some people have been requesting for scan-s2 a simple >> scan application which has been hacked on top of the scan application >> as available in the dvb-apps tree, to be integrated/pulled in to the >> dvb-apps tree, after it's author moved on to other arenas. >> >> http://www.mail-archive.com/v...@linuxtv.org/msg11125.html >> >> The idea initially was to have a cloned copy of scan as scan-s2. >> Now, on the other hand scan-s2 is much more like scan and similar >> functionality wise too. >> >> Considering the aspects, do you think, that it is worthwhile to have >> >> a) the scan-s2 application and the scan application as well integrated >> into the repository, such that they both live together >> >> or >> >> b) scan-s2 does things almost the same as scan2. scan can be replaced >> by scan-s2. >> >> >> What are your ideas/thoughts on this ? > > I think S2 scanning should simply be added to scan. See http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ It adds support to DVB API v5 to the dvb-apps library. Originally, this were done to add ISDB-T support, but the next patches added also DVB-T, DVB-C and DVB-S support via APIv5. It also adds some DVB-S2 bits there. There are very few things lacking there to fully implement DVB-S2. It shouldn't be hard to add there also other standards like DVB-T2, ISDB-S, etc. -- Cheers, Mauro -- 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: [ANNOUNCE] git tree repositories & libv4l
Hi, On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? I added it. In thesis, it is open for commit to you, me, hverkuil and dougsland. I see good, thanks! Can someone (Douglas ?) with better hg / git powers then me please somehow import all the libv4l changes from: http://linuxtv.org/hg/~hgoede/libv4l Once that is done I'll retire my own tree, and move all my userspace work to the git tree. For starters I plan to create / modify Makefiles so that everything will build out of the box, and has proper make install targets which can be used by distro's So: -proper honoring of CFLAGS -work with standard (and possibly somewhat older kernel headers) -honor DESTDIR, PREFIX and LIBDIR when doing make install When I'm satisfied (and have created some proof of concept packages for Fedora to make sure everything is reasonably usable for distros). I'll send a mail to the list announcing my intend to release a 0.8.0 version (building on top of existing libv4l release scheme to make clear which libv4l version is included). If there are then no objections / bugs found I'll do a 0.8.0 release . 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: Chroma gain configuration
On Tue, 2010-02-23 at 10:33 -0500, Andy Walls wrote: > On Tue, 2010-02-23 at 15:41 +0100, Hans Verkuil wrote: > > > On Tue, 2010-02-23 at 08:53 +0100, Hans Verkuil wrote: > > >> On Monday 22 February 2010 23:00:32 Devin Heitmueller wrote: > > >> > On Mon, Feb 22, 2010 at 4:54 PM, Hans Verkuil > > >> wrote: > > > > > >> > Of course, if you and Mauro wanted to sign off on the creation of a > > >> > new non-private user control called V4L2_CID_CHROMA_GAIN, that would > > >> > also resolve my problem. :-) > > >> > > >> Hmm, Mauro is right: the color controls we have now are a bit of a mess. > > >> Perhaps this is a good moment to try and fix them. Suppose we had no > > >> color > > >> controls at all: how would we design them in that case? When we know > > >> what we > > >> really need, then we can compare that with what we have and figure out > > >> what > > >> we need to do to make things right again. > > > Let me rephrase my question: how would you design the user color controls? > > > E.g., the controls that are exported in GUIs to the average user. > > Look at the knobs on an old TV or look at the menu on more modern > televisions: > > 1. Hue (or Tint) (at least NTSC TVs have this control) > 2. Brightness > 3. Saturation > > These are the three parameters to which the Human Visual System > sensitive. > > Any other controls are fixing problems that the hardware can't seem to > get right on it's own - right? Bah, I forgot contrast. Regards, Andy > > > Most of > > the controls you mentioned above are meaningless to most users. When we > > have subdev device nodes, then such controls can become accessible to > > applications to do fine-tuning, but they do not belong in a GUI in e.g. > > tvtime or xawtv. > > > > The problem is of course in that grey area between obviously user-level > > controls like brightness and obviously (to me at least) expert-level > > controls like chroma coring. > > Right, so an expert can see colors bleeding to the side in portions of > the image and guess that it's a comb filter problem. What's my recourse > at that point, when I see such a clip submitted from user and identify > it's a comb filter problem? "Tough, you're not an expert, so I can't > give you manual control over the comb filter so you can fix your > problem" ? > > Also, just because a user can't guess what to do, doesn't mean they are > incapable of "mashing buttons" until they find something that works. I > don't quite see the value in restricting controls from users, when the > only consequence of such restriction is them coming back here asking > what else they can try to solve a problem. It's frustrating to have a > setting on the chip that could fix a user problem and knowing there is > no control coded up for it. It just makes the debug cycle longer. > > > What is the benefit to us or to end users for denying controls to > non-expert users? > > > OK, I'm done ranting now. :) > > Regards, > Andy > > > -- > 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: [ANNOUNCE] git tree repositories & libv4l
Hans de Goede wrote: > Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? I added it. In thesis, it is open for commit to you, me, hverkuil and dougsland. The tree is small: just 860Kb, after properly packed. Brandon, I need an ssh public key from you to enable your access. Please send it to me in priv. Did I miss anybody? Cheers, Mauro -- 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: Chroma gain configuration
On Tue, 2010-02-23 at 15:41 +0100, Hans Verkuil wrote: > > On Tue, 2010-02-23 at 08:53 +0100, Hans Verkuil wrote: > >> On Monday 22 February 2010 23:00:32 Devin Heitmueller wrote: > >> > On Mon, Feb 22, 2010 at 4:54 PM, Hans Verkuil > >> wrote: > > > >> > Of course, if you and Mauro wanted to sign off on the creation of a > >> > new non-private user control called V4L2_CID_CHROMA_GAIN, that would > >> > also resolve my problem. :-) > >> > >> Hmm, Mauro is right: the color controls we have now are a bit of a mess. > >> Perhaps this is a good moment to try and fix them. Suppose we had no > >> color > >> controls at all: how would we design them in that case? When we know > >> what we > >> really need, then we can compare that with what we have and figure out > >> what > >> we need to do to make things right again. > Let me rephrase my question: how would you design the user color controls? > E.g., the controls that are exported in GUIs to the average user. Look at the knobs on an old TV or look at the menu on more modern televisions: 1. Hue (or Tint) (at least NTSC TVs have this control) 2. Brightness 3. Saturation These are the three parameters to which the Human Visual System sensitive. Any other controls are fixing problems that the hardware can't seem to get right on it's own - right? > Most of > the controls you mentioned above are meaningless to most users. When we > have subdev device nodes, then such controls can become accessible to > applications to do fine-tuning, but they do not belong in a GUI in e.g. > tvtime or xawtv. > > The problem is of course in that grey area between obviously user-level > controls like brightness and obviously (to me at least) expert-level > controls like chroma coring. Right, so an expert can see colors bleeding to the side in portions of the image and guess that it's a comb filter problem. What's my recourse at that point, when I see such a clip submitted from user and identify it's a comb filter problem? "Tough, you're not an expert, so I can't give you manual control over the comb filter so you can fix your problem" ? Also, just because a user can't guess what to do, doesn't mean they are incapable of "mashing buttons" until they find something that works. I don't quite see the value in restricting controls from users, when the only consequence of such restriction is them coming back here asking what else they can try to solve a problem. It's frustrating to have a setting on the chip that could fix a user problem and knowing there is no control coded up for it. It just makes the debug cycle longer. What is the benefit to us or to end users for denying controls to non-expert users? OK, I'm done ranting now. :) Regards, Andy -- 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: Chroma gain configuration
On Tue, Feb 23, 2010 at 2:53 AM, Hans Verkuil wrote: > OK. So the problem is that v4l2-ctl uses G/S_EXT_CTRLS for non-user controls, > right? Why not change v4l2-ctl: let it first try the EXT version but if that > fails with EINVAL then try the old control API. Well, that's what I'm trying to figure out. If this is a bug and I just need to fix v4l2-ctl, then I can do that. At this point, I was just trying to figure out how everybody else does private controls, since this appears to be broken out-of-the-box. > Hmm, Mauro is right: the color controls we have now are a bit of a mess. > Perhaps this is a good moment to try and fix them. Suppose we had no color > controls at all: how would we design them in that case? When we know what we > really need, then we can compare that with what we have and figure out what > we need to do to make things right again. Ok, this whole thread started because a client hit a specific quality issue, and in order to address that issue I need to expose a single slider to userland so that this advanced user can twiddle the knob with v4l2-ctl. I, perhaps naively, assumed this would be a trivial change since we already have lots of infrastructure for this and the driver in question is quite mature. So we've gone from what I thought was going to be a six line change in g_ctrl/s_ctrl to converting the whole driver over to using the extended controls interface, to now the suggestion that we redesign the way we do color controls across the entire v4l2 subsystem? I don't dispute that the way things have ended up is not ideal (and presumably got that way because of the diversity of different decoders we support and the differences in the underlying registers they provide). But at this point, I'm trying to solve what should be a rather simple problem, and I haven't been contracted to redesign the entire subsystem just to expose one advanced control. So if people agree this is a bug in v4l2-ctl, then I'll dig into that block of code and submit a patch. If the real problem is that the saa7115 driver needs to be converted to the extended control interface to expose a single private control, well I can do that instead (although I think that would be a pretty dumb limitation). At this point, I'm just trying to find the simplest change required to accomplish something that should have taken me half an hour and been done two days ago. 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: [linux-dvb] soft demux device
On Tue, Feb 23, 2010 at 6:34 PM, Andy Walls wrote: > On Tue, 2010-02-23 at 05:12 -0800, ozgur cagdas wrote: >> Hi All, >> >> I have just compiled v4l-dvb successfully. My aim is to develop some >> experimental dvb applications on top of this dvb kernel api. >> Initially, I do not want to use any hardware and would like to play >> with the recorded ts files I have. So, is there any software demux >> device available within this package or somewhere else? > > I do not know. You could write a simple dvb_dummy driver module. The > existing dvb_dummy_fe module would be helpful in such an endeavor, I > suppose. Indeed, that's the right way :-) Regards, Manu -- 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: Chroma gain configuration
> On Tue, 2010-02-23 at 08:53 +0100, Hans Verkuil wrote: >> On Monday 22 February 2010 23:00:32 Devin Heitmueller wrote: >> > On Mon, Feb 22, 2010 at 4:54 PM, Hans Verkuil >> wrote: > >> > Of course, if you and Mauro wanted to sign off on the creation of a >> > new non-private user control called V4L2_CID_CHROMA_GAIN, that would >> > also resolve my problem. :-) >> >> Hmm, Mauro is right: the color controls we have now are a bit of a mess. >> Perhaps this is a good moment to try and fix them. Suppose we had no >> color >> controls at all: how would we design them in that case? When we know >> what we >> really need, then we can compare that with what we have and figure out >> what >> we need to do to make things right again. > > Hmmm: > > 1. comb filter enable/disable > 2. chroma AGC enable/disable > 3. chroma kill threshold and enable/disable > 4. UV saturation (C vector magnitude adjustment as long as you adjust U > and V in the same way.) > 5. Hue (C vector phase adjustment) > 6. chroma coring > 7. chroma delay/advance in pixels relative to luma pixels > 8. chroma subcarrier locking algorithm: fast, slow, adaptive > 9. chroma notch filer settings (when doing Y/C separation from CVBS) > 10. additional analog signal gain > 11. anti-alias filter enable/disable > > And that's just from a quick scan of the public CX25836/7 datasheet. > > I left my handbook with all sorts of details about the Human Visual > System and the CIE and NTSC and PAL colorspaces at work. Let me rephrase my question: how would you design the user color controls? E.g., the controls that are exported in GUIs to the average user. Most of the controls you mentioned above are meaningless to most users. When we have subdev device nodes, then such controls can become accessible to applications to do fine-tuning, but they do not belong in a GUI in e.g. tvtime or xawtv. The problem is of course in that grey area between obviously user-level controls like brightness and obviously (to me at least) expert-level controls like chroma coring. Regards, Hans > > Regards, > Andy > > > > > >> Regards, >> >> Hans >> >> > >> > Devin >> > >> > >> > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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] soft demux device
On Tue, 2010-02-23 at 05:12 -0800, ozgur cagdas wrote: > Hi All, > > I have just compiled v4l-dvb successfully. My aim is to develop some > experimental dvb applications on top of this dvb kernel api. > Initially, I do not want to use any hardware and would like to play > with the recorded ts files I have. So, is there any software demux > device available within this package or somewhere else? I do not know. You could write a simple dvb_dummy driver module. The existing dvb_dummy_fe module would be helpful in such an endeavor, I suppose. > If so, how can I load this device and make it work on a given ts file > circularly? Writing the TS to the /dev/dvb/adapter0/dvr0 device would be the way to replay an existing TS file, IIRC. > On the other hand, I have no /dev/dvb node at the moment, so should > I do anything for this or would loading the driver create it > automatically? A dvb driver being loaded and registering should cause those to be created automatically. Regards, Andy -- 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: Chroma gain configuration
On Tue, 2010-02-23 at 08:53 +0100, Hans Verkuil wrote: > On Monday 22 February 2010 23:00:32 Devin Heitmueller wrote: > > On Mon, Feb 22, 2010 at 4:54 PM, Hans Verkuil wrote: > > Of course, if you and Mauro wanted to sign off on the creation of a > > new non-private user control called V4L2_CID_CHROMA_GAIN, that would > > also resolve my problem. :-) > > Hmm, Mauro is right: the color controls we have now are a bit of a mess. > Perhaps this is a good moment to try and fix them. Suppose we had no color > controls at all: how would we design them in that case? When we know what we > really need, then we can compare that with what we have and figure out what > we need to do to make things right again. Hmmm: 1. comb filter enable/disable 2. chroma AGC enable/disable 3. chroma kill threshold and enable/disable 4. UV saturation (C vector magnitude adjustment as long as you adjust U and V in the same way.) 5. Hue (C vector phase adjustment) 6. chroma coring 7. chroma delay/advance in pixels relative to luma pixels 8. chroma subcarrier locking algorithm: fast, slow, adaptive 9. chroma notch filer settings (when doing Y/C separation from CVBS) 10. additional analog signal gain 11. anti-alias filter enable/disable And that's just from a quick scan of the public CX25836/7 datasheet. I left my handbook with all sorts of details about the Human Visual System and the CIE and NTSC and PAL colorspaces at work. Regards, Andy > Regards, > > Hans > > > > > Devin > > > > > -- 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: [ANNOUNCE] git tree repositories & libv4l
On Tue, Feb 23, 2010 at 5:36 PM, Mauro Carvalho Chehab wrote: > Manu Abraham wrote: What's the advantage in merging the dvb and v4l2 utils, other than to make the download/clone bigger ? >>> There aren't any big advantages on merging, nor there are big advantages on >>> keeping >>> them alone. >>> >>> Advantages to merge: >>> - One single release control. Currently, only Hans de Goede is doing >>> a >>> good job with release names, on libv4l. By having everything into one >>> place, all other >>> v4l2-apps and dvb-apps will have a release name, making easier even for us >>> when helping >>> people with troubles (as we'll know for sure if they're using the latest >>> version or >>> a very old version; >>> - One single tree for the user to download, for IR, DVB and V4L apps; >>> - Distro packagers will have one single tarball to maintain. >>> >>> Disadvantages: >>> - More people will need access to the same git master tree; >>> - The tree will be bigger. >> >> >> It is quite noble to think of having to have everything unified in the >> world. But that doesn't seem how things are in practice. It's quite >> understood that the concept of "one-single-ring-to-rule-them-all" >> doesn't work well. >> >> The mercurial dvb-apps tree has worked quite well for me as well as >> the other few people who have been involved with it and don't have any >> problems in that arena and I am very happy with it on that front. >> >> FWIW, I am not very much interested to move to git. >> >> Are we making a mockery, switching between SCM's every now and then .. ? >> >> Maybe there are others as well, who feel that way. But that's not the >> more important point. For me, it is like simply that a simple update >> is quite fast and easy. > > I don't think moving it to git would bring any significant advantage or > disadvantage. > >> With regards to distro stuff; This is best left to distro vendors. > > Agreed. > >> With regards to release control, we have had a 1.1.1 release. Looking >> back, we haven't had a proper stable state yet, for another release. > > Hmm... > http://www.linuxtv.org/downloads/ > > May, 18 2006... > > $ hg log -d ">05/18/2006" -p|diffstat -p1|grep changed > 1402 files changed, 66559 insertions(+), 16267 deletions(-) > > Sorry, but it is really failing with release control. There were _lots_ of > change > since 2006, including several new applications, and tons of new > channel/transponders > added to it. I don't simply see how adding in a version number is going to help in moving things ahead. Anyone wishing to download the latest tip can dowload from http://linuxtv.org/hg/dvb-apps/archive/tip.tar.bz2 if one is not content with cloning the whole tree. >> Thinking of which, it is more of these discussions that hold back real >> development rather than anything else. Moving to git, or have a merged >> tree with v4l2 and dvb utils is not going to make dvb-apps development >> any faster. >> >> On the contrary, I don't think it is going to help dvb-apps in anyway >> on the development front, but rather make it worser. > > Why would it be worse? Anything that which doesn't make things better, but that brings in an overhead, is something worser. - I would need to get going on with git - It's going to be the 3rd time there is a SCM change. Changing it all the time doesn't help the users nor the people who work on it. - The additional overhead to download larger content, however small that might be initially to start up with. - mixing up things that which are not really tied to each other >> My few cents, being one of the dvb-apps maintainers and author of some >> the bits and pieces in it. > > PS.: while removing that "need maintainer" warning from the wiki, I noticed > that, > just like v4l2-apps, there's one application there for IR > (util/av7110_loadkeys). > > Even if we decide to keep the trees separate, we should really put this > utility > and the IR code at v4l2-apps at the same place. It has been there for ages, originally Holger had it there, during the time of convergence. FF card users have been using it since. Probably FF users would like to mention what they would like to have and comment on that. Regards, Manu -- 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: [ANNOUNCE] git tree repositories & libv4l
Brandon Philips wrote: > On 22:12 Mon 22 Feb 2010, Mauro Carvalho Chehab wrote: >> Mauro Carvalho Chehab wrote: >> That's said, if all the issues are the ones listed above, I can try >> to address them on the next months, to put it into a better >> shape. That's said, I don't think we should have a single maintainer >> for it: there are too many DTV standards already, and probably >> nobody with enough time has access to all of those (DVB-T, DVB-T2, >> DVB-S, DVB-S2, ISDB-T, ISDB-S, ATSC, DSS, ...). So, I think we need >> a team of volunteers that will try to help with the standards they >> have access. > > I was not suggesting a single maintainer but I wanted to make sure > there was actual interest in maintaing and fixing these dvb things. I > don't interact much at all with DVB so all I had to go on was the wiki > page. The wiki seems wrong to me. I'll update it. -- Cheers, Mauro -- 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: [ANNOUNCE] git tree repositories & libv4l
Manu Abraham wrote: >>> What's the advantage in merging the dvb and v4l2 utils, other than to >>> make the download/clone bigger ? >> There aren't any big advantages on merging, nor there are big advantages on >> keeping >> them alone. >> >> Advantages to merge: >>- One single release control. Currently, only Hans de Goede is doing a >> good job with release names, on libv4l. By having everything into one place, >> all other >> v4l2-apps and dvb-apps will have a release name, making easier even for us >> when helping >> people with troubles (as we'll know for sure if they're using the latest >> version or >> a very old version; >>- One single tree for the user to download, for IR, DVB and V4L apps; >>- Distro packagers will have one single tarball to maintain. >> >> Disadvantages: >>- More people will need access to the same git master tree; >>- The tree will be bigger. > > > It is quite noble to think of having to have everything unified in the > world. But that doesn't seem how things are in practice. It's quite > understood that the concept of "one-single-ring-to-rule-them-all" > doesn't work well. > > The mercurial dvb-apps tree has worked quite well for me as well as > the other few people who have been involved with it and don't have any > problems in that arena and I am very happy with it on that front. > > FWIW, I am not very much interested to move to git. > > Are we making a mockery, switching between SCM's every now and then .. ? > > Maybe there are others as well, who feel that way. But that's not the > more important point. For me, it is like simply that a simple update > is quite fast and easy. I don't think moving it to git would bring any significant advantage or disadvantage. > With regards to distro stuff; This is best left to distro vendors. Agreed. > With regards to release control, we have had a 1.1.1 release. Looking > back, we haven't had a proper stable state yet, for another release. Hmm... http://www.linuxtv.org/downloads/ May, 18 2006... $ hg log -d ">05/18/2006" -p|diffstat -p1|grep changed 1402 files changed, 66559 insertions(+), 16267 deletions(-) Sorry, but it is really failing with release control. There were _lots_ of change since 2006, including several new applications, and tons of new channel/transponders added to it. > Thinking of which, it is more of these discussions that hold back real > development rather than anything else. Moving to git, or have a merged > tree with v4l2 and dvb utils is not going to make dvb-apps development > any faster. > > On the contrary, I don't think it is going to help dvb-apps in anyway > on the development front, but rather make it worser. Why would it be worse? > My few cents, being one of the dvb-apps maintainers and author of some > the bits and pieces in it. PS.: while removing that "need maintainer" warning from the wiki, I noticed that, just like v4l2-apps, there's one application there for IR (util/av7110_loadkeys). Even if we decide to keep the trees separate, we should really put this utility and the IR code at v4l2-apps at the same place. -- Cheers, Mauro -- 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] scan-s2 and dvb-apps
I think its better to use one application, so i prefer option (b) -Original Message- From: linux-dvb-boun...@linuxtv.org [mailto:linux-dvb-boun...@linuxtv.org] On Behalf Of Christophe Thommeret Sent: Tuesday, February 23, 2010 4:07 PM To: linux-media@vger.kernel.org; linux-...@linuxtv.org Subject: Re: [linux-dvb] scan-s2 and dvb-apps Le mardi 23 février 2010 12:36:13, Manu Abraham a écrit : > Hi All, > > Recently, quite some people have been requesting for scan-s2 a simple > scan application which has been hacked on top of the scan application > as available in the dvb-apps tree, to be integrated/pulled in to the > dvb-apps tree, after it's author moved on to other arenas. > > http://www.mail-archive.com/v...@linuxtv.org/msg11125.html > > The idea initially was to have a cloned copy of scan as scan-s2. > Now, on the other hand scan-s2 is much more like scan and similar > functionality wise too. > > Considering the aspects, do you think, that it is worthwhile to have > > a) the scan-s2 application and the scan application as well integrated > into the repository, such that they both live together > > or > > b) scan-s2 does things almost the same as scan2. scan can be replaced > by scan-s2. > > > What are your ideas/thoughts on this ? I think S2 scanning should simply be added to scan. My 2cents. -- Christophe Thommeret ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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: DM1105: could not attach frontend 195d:1105
Sounds cool, let me know if I can help you with anything. Thanks Nameer Hendrik Skarpeid wrote: No luck here either, still working on it. My plan is to solder som wires on strategic points on the board and debug i2c and other activity with an oscilloscope. Will probably start next week. Nameer Kazzaz wrote: Hey Igor, I'm getting the same error: dm1105 :04:0b.0: could not attach frontend Did you get your one to work. Thanks Nameer Igor M. Liplianin wrote: On 18 февраля 2010, liplia...@me.by wrote: I also got the unbranded dm1105 card. I tried the four possible i2c addresses, just i case. Noen worked of course. Then I traced the i2c pins on the tuner to pins 100 and 101 on the DM1105. These are GPIO pins, so bit-banging i2c on these pins seems to be the solution. scl = p101 = gpio14 sda = p100 = gpio13 Here is the patch to test. Use option card=4. modprobe dm1105 card=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: [ANNOUNCE] git tree repositories & libv4l
On Tue, Feb 23, 2010 at 4:21 PM, Mauro Carvalho Chehab wrote: > Manu Abraham wrote: >> On Tue, Feb 23, 2010 at 1:23 PM, Hans de Goede wrote: [snip] >> >> >> What's the advantage in merging the dvb and v4l2 utils, other than to >> make the download/clone bigger ? > > There aren't any big advantages on merging, nor there are big advantages on > keeping > them alone. > > Advantages to merge: > - One single release control. Currently, only Hans de Goede is doing a > good job with release names, on libv4l. By having everything into one place, > all other > v4l2-apps and dvb-apps will have a release name, making easier even for us > when helping > people with troubles (as we'll know for sure if they're using the latest > version or > a very old version; > - One single tree for the user to download, for IR, DVB and V4L apps; > - Distro packagers will have one single tarball to maintain. > > Disadvantages: > - More people will need access to the same git master tree; > - The tree will be bigger. It is quite noble to think of having to have everything unified in the world. But that doesn't seem how things are in practice. It's quite understood that the concept of "one-single-ring-to-rule-them-all" doesn't work well. The mercurial dvb-apps tree has worked quite well for me as well as the other few people who have been involved with it and don't have any problems in that arena and I am very happy with it on that front. FWIW, I am not very much interested to move to git. Are we making a mockery, switching between SCM's every now and then .. ? Maybe there are others as well, who feel that way. But that's not the more important point. For me, it is like simply that a simple update is quite fast and easy. FWIW: dvb-apps is not about any real application development, but acts as an aid for other applications to be built. In some cases, it can aid as a quick test tools, which can isolate users issues, when carry forward issues from other applications. On the contrary we have had a few libs, which are in use by some applications. These came up as Andrew, myself and Julian wanted to have some libraries to setup things real quick. Johannes provided some directions in which how developments could proceed to make things look good. Later on, Andrew ran away from all v4l, dvb related developments, because he was irritated quite a lot too much. With regards to distro stuff; This is best left to distro vendors. I don't really appreciate this distro-speak that you make every now and then. In the light that which you speak, it would be even much nobler to think of a pakage or rpm such as distro-application-packages.foobar. But such a merging of all the applications and utilities do not really mean anything and is useless. All it does is: irritate people. With regards to release control, we have had a 1.1.1 release. Looking back, we haven't had a proper stable state yet, for another release. Thinking of which, it is more of these discussions that hold back real development rather than anything else. Moving to git, or have a merged tree with v4l2 and dvb utils is not going to make dvb-apps development any faster. On the contrary, I don't think it is going to help dvb-apps in anyway on the development front, but rather make it worser. My few cents, being one of the dvb-apps maintainers and author of some the bits and pieces in it. Regards, Manu -- 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] scan-s2 and dvb-apps
Le mardi 23 février 2010 12:36:13, Manu Abraham a écrit : > Hi All, > > Recently, quite some people have been requesting for scan-s2 a simple > scan application which has been hacked on top of the scan application > as available in the dvb-apps tree, to be integrated/pulled in to the > dvb-apps tree, after it's author moved on to other arenas. > > http://www.mail-archive.com/v...@linuxtv.org/msg11125.html > > The idea initially was to have a cloned copy of scan as scan-s2. > Now, on the other hand scan-s2 is much more like scan and similar > functionality wise too. > > Considering the aspects, do you think, that it is worthwhile to have > > a) the scan-s2 application and the scan application as well integrated > into the repository, such that they both live together > > or > > b) scan-s2 does things almost the same as scan2. scan can be replaced > by scan-s2. > > > What are your ideas/thoughts on this ? I think S2 scanning should simply be added to scan. My 2cents. -- Christophe Thommeret -- 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: More videobuf and streaming I/O questions
Hi Jean-François, On Monday 22 February 2010 10:47:41 Jean-Francois Moine wrote: > Hi Hans and Laurent, > > On Mon, 22 Feb 2010 00:12:18 +0100 > > Laurent Pinchart wrote: > > On Saturday 20 February 2010 15:00:21 Hans Verkuil wrote: > > > 1) The spec mentions that the memory field should be set for > > > VIDIOC_DQBUF. But videobuf doesn't need it and it makes no sense to > > > me either unless it is for symmetry with VIDIOC_QBUF. Strictly > > > speaking QBUF doesn't need it either, but it is a good sanity check. > > > > > > Can I remove the statement in the spec that memory should be set > > > for DQBUF? The alternative is to add a check against the memory > > > field in videobuf, but that's rather scary. > > > > In that case I would remove it for QBUF as well, and state that the > > memory field must be ignored by drivers (but should they fill it when > > returning from QBUF/DQBUF ?) > > Agree. It seems that the memory field is not useful at all in the struct > v4l2_buffer if a same process does reqbuf, qbuf, dqbuf and querybuf. > > > BTW, I had a pending question. The spec says that streamoff 'removes > all buffers from the incoming and outgoing queues' and return to 'the > same state as after calling VIDIOC_REQBUFS'. For output, there is no > problem. For capture, does this mean that the buffers previously queued > by qbuf are implicitly unqueued (i.e. that qbuf must be done again for > all buffers)? That's correct. > In this case, streamoff does not work with two processes. A first > process is streaming when a second one does streamoff and then > streamon. The first process will stay blocked on polling because no > buffer is queued anymore. It cannot know this fact and the second > process cannot requeue the buffers... I don't think this multiple process use case is valid. The V4L2 streaming API wasn't designed to be used in a multi-thread or multi-process context in the first place. > To work correctly, the spec should say that streamoff discards the > content of the filled buffers and that it requeues these buffers as > empty either in the driver's incoming queue (capture) or outgoing queue > (output). I don't agree. If we did that, buffers couldn't be released after a STREAMOFF. Queued buffers belong to the driver, so to free the buffers applications would have to call VIDIOC_STREAMOFF and then dequeue all buffers. That's not pretty. -- 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: modprobe em28xx failed for MSI Vox II USB
Just open up the USB stick and discovered that the video chip is Trident TM5600 and tuner is Xceive XC2028. Any help? On Tue, Feb 23, 2010 at 4:29 PM, Bee Hock Goh wrote: > Carlos, > > Thanks for the reply. Actually your usb stick is MSI TV VOX 8609 USB > 2.0 which look quite different from my MSI Vox II USB. > > Since there is already support for MSI VOX USB 2.0. I was hoping that > it will be a quick win to get Vox II supported. > > Hopefully someone will be able to develop a patch to make it work. I > am prepared to provide assistant in whatever way I can. > > I am probably going to dismantle the stick and post some pictures and > information. > > regards, > Hock. > > On Tue, Feb 23, 2010 at 4:19 PM, Carlos Jenkins > wrote: >> Hi, the symbol problem could get solved by restarting the system. >> >> On the other hand check this thread: >> >> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/15991/ >> >> Actually, the MSI Vox USB II device isn't working with the current tree. >> >> Cheers >> > -- 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: DM1105: could not attach frontend 195d:1105
No luck here either, still working on it. My plan is to solder som wires on strategic points on the board and debug i2c and other activity with an oscilloscope. Will probably start next week. Nameer Kazzaz wrote: Hey Igor, I'm getting the same error: dm1105 :04:0b.0: could not attach frontend Did you get your one to work. Thanks Nameer Igor M. Liplianin wrote: On 18 февраля 2010, liplia...@me.by wrote: I also got the unbranded dm1105 card. I tried the four possible i2c addresses, just i case. Noen worked of course. Then I traced the i2c pins on the tuner to pins 100 and 101 on the DM1105. These are GPIO pins, so bit-banging i2c on these pins seems to be the solution. scl = p101 = gpio14 sda = p100 = gpio13 Here is the patch to test. Use option card=4. modprobe dm1105 card=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: [ANNOUNCE] git tree repositories & libv4l
Manu Abraham wrote: > On Tue, Feb 23, 2010 at 1:23 PM, Hans de Goede wrote: >> Hi, >> >> On 02/23/2010 10:01 AM, Hans Verkuil wrote: Hi, On 02/22/2010 11:54 PM, Brandon Philips wrote: > On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: >>> lib/ >>>libv4l1/ >>>libv4l2/ >>>libv4lconvert/ >>> utils/ >>>v4l2-dbg >>>v4l2-ctl >>>cx18-ctl >>>ivtv-ctl >>> contrib/ >>>test/ >>>everything else >>> >git clone git://ifup.org/philips/create-v4l-utils.git >cd create-v4l-utils/ >./convert.sh > > You should now have v4l-utils.git which should have this directory > struture. If we need to move other things around let me know and I can > tweak name-filter.sh > Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? Also I need someone to pull: http://linuxtv.org/hg/~hgoede/libv4l (this only contains libv4l commits) Into the: http://linuxtv.org/hg/v4l-dvb Repository, I guess I can ask this directly to Douglas? > Thoughts? I've one question, I think we want to do tarbal releases from this new repo (just like I've been doing with libv4l for a while already), and then want distro's to pick up these releases, right ? Are we going to do separate tarbals for the lib and utils directories, or one combined tarbal. I personally vote for one combined tarbal. But this means we will be inflicting some pains on distro's because their libv4l packages will go away and be replaced by a new v4l-utils package. >>> I would call it media-utils. A nice name and it reflects that it contains >>> both dvb and v4l utilities. >>> >> Well, the judge is still out on also adding the dvb utils to this git repo. >> I'm neutral on that issue, but I will need a co-maintainer for those bits >> if they end up in the new v4l-utils repo too. >> >> About the name, if the dvb utils get added and we want to reflect that, lets >> call it v4l-dvb-utils. media-utils is not a very descriptive name for >> v4l-dvb >> project outsiders. > > > What's the advantage in merging the dvb and v4l2 utils, other than to > make the download/clone bigger ? There aren't any big advantages on merging, nor there are big advantages on keeping them alone. Advantages to merge: - One single release control. Currently, only Hans de Goede is doing a good job with release names, on libv4l. By having everything into one place, all other v4l2-apps and dvb-apps will have a release name, making easier even for us when helping people with troubles (as we'll know for sure if they're using the latest version or a very old version; - One single tree for the user to download, for IR, DVB and V4L apps; - Distro packagers will have one single tarball to maintain. Disadvantages: - More people will need access to the same git master tree; - The tree will be bigger. -- Cheers, Mauro -- 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: [ANNOUNCE] git tree repositories & libv4l
Hans de Goede wrote: >> I would call it media-utils. A nice name and it reflects that it contains >> both dvb and v4l utilities. >> > > Well, the judge is still out on also adding the dvb utils to this git repo. > I'm neutral on that issue, but I will need a co-maintainer for those bits > if they end up in the new v4l-utils repo too. I also don't have any strong feeling about merging dvb utils. The advantage is to share the same release control, but the code is completely separated. There will likely be some developers working on both projects. A deeper look on what we have on userspace, there are 3 categories of software: - apps that handle /dev/v4l/* devices (e. g. V4L2 API hanling); - apps that handle /dev/dvb/* devices (e. g. DVB API handling); - apps that handle /dev/input/* devices (e. g. IR API handling). The last one is, in fact just one code, plus lots of IR tables from all V4L and DVB drivers. The table is created today by the Makefile: it reads the table from the kernel source tree and generates the tables for the userspace util [*]. If we are maintaining separate trees for each class of device, it might make sense to have separate a tree for the IR stuff, but this seems overkill to me, since we'll need to handle 3 separate version controls for each tool class, and, in practice, v4l/dvb users will need to get more than one tree to get full control of his device. So, I prefer to have one tree with all 3 types of utilities. [*] Btw, how Brandon addressed it with the conversion tool? I think we'll need to add some tools there to handle the kernel driver <-> v4l2-apps interdependency, e. g. creating the *.c.xml files needed by the media-specs and importing the IR keymaps from the driver sources. -- Cheers, Mauro -- 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: [ANNOUNCE] git tree repositories & libv4l
Hans de Goede wrote: > Hi, > > On 02/22/2010 11:54 PM, Brandon Philips wrote: >> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else >> >>git clone git://ifup.org/philips/create-v4l-utils.git >>cd create-v4l-utils/ >>./convert.sh >> >> You should now have v4l-utils.git which should have this directory >> struture. If we need to move other things around let me know and I can >> tweak name-filter.sh >> > > Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? I'll answer first the next question ;) > > Also I need someone to pull: > http://linuxtv.org/hg/~hgoede/libv4l > > (this only contains libv4l commits) > > Into the: > http://linuxtv.org/hg/v4l-dvb > > Repository, I guess I can ask this directly to Douglas? Request it to Douglas. Another option is to merge it locally on your repository, convert it to git. After having it converted to git, you should create a repository there for you, with the -git procedures I've emailed to the ones with accounts there. Then, ping me and I'll move it to a better place and add permissions for the others to merge there. > >> Thoughts? > > I've one question, I think we want to do tarbal releases > from this new repo (just like I've been doing with libv4l for a while > already), and then want distro's to pick up these releases, right ? > > Are we going to do separate tarbals for the lib and utils directories, > or one combined tarbal. I personally vote for one combined tarbal. > > But this means we will be inflicting some pains on distro's because their > libv4l packages will go away and be replaced by a new v4l-utils package. > This is something distro's should be able to handle (it happens more > often, and I > know Fedora has procedures for this). > > An alternative would be to name the repo and the tarbals libv4l, either > is fine > with me (although I'm one of the distro packagers who is going to feel > the pain > of a package rename and as such wouldn't mind using libv4l as name for the > repo and the new tarbals). I think that the better is to create one single tarball. The Makefile may have multiple makefile targets for the libraries and for utils. This would help distros to create different packages if they want to. As you're the packager on Fedora, I think you should prepare it to make your life easier on the distro side. This will probably help other distros too. -- Cheers, Mauro -- 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: [ANNOUNCE] git tree repositories & libv4l
On Tue, Feb 23, 2010 at 3:26 AM, Hans Verkuil wrote: > Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was > merged into dvb-apps, but while that tool supports dvb, it also supports > v4l2. Just like we merged dvb and v4l in a single repository, so I think we > should also merge the tools to a media-utils repository. Alevt was never maintained. One of the guys who sent a patch wanted a place to hold his patch and hence it is there. If you have a better place to put it up, please do let me know. It's place is not in the dvb-apps tree. It has other dependencies, hence the build for it is disabled by default. > It remains a fact of life that dvb and v4l are connected and trying to > artificially keep them apart does not make much sense to me. In fact, I don't see anything that's what is common in the digital and analog applications. Other than that, I don't see a single line of code from you, in dvb-apps to make such assertive statements. Regards, Manu -- 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: [ANNOUNCE] git tree repositories & libv4l
Manu Abraham wrote: >> and we've got some comments at the mailing list. Btw, the patches >> I added there also adds DVB-S2 support to szap/scan, but tests >> are needed, since I don't have any satellite dish nowadays. > > > Btw, I did spend time to review your code before it is pulled in. You > did not even provide a reply on my last mail on the subject, or did I > miss that reply of yours ? It is on my todo list. My intention is to work on it after the next kernel window. -- Cheers, Mauro -- 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
tda10023.c: misplaced parentheses?
In tda10023_read_signal_strength() we have: u16 gain = ((255-tda10023_readreg(state, 0x17))) + (255-ifgain)/16; ---^ The closing parenthesis appears misplaced, should this be: u16 gain = ((255-tda10023_readreg(state, 0x17)) + (255-ifgain))/ 16; --^ Or are the double parentheses just unnecessary? Roel -- 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: [ANNOUNCE] git tree repositories & libv4l
On Tue, Feb 23, 2010 at 4:41 AM, Mauro Carvalho Chehab wrote: > Brandon Philips wrote: >> On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote: >>> On Monday 22 February 2010 23:54:26 Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: >> lib/ >> libv4l1/ >> libv4l2/ >> libv4lconvert/ >> utils/ >> v4l2-dbg >> v4l2-ctl >> cx18-ctl >> ivtv-ctl >> contrib/ >> test/ >> everything else >> git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Thoughts? Let me know how we should proceed with dropping v4l2-apps from v4l-dvb. Re: code style cleanup. I think we should do that once we drop v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. >>> Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was >>> merged into dvb-apps, but while that tool supports dvb, it also supports >>> v4l2. Just like we merged dvb and v4l in a single repository, so I think we >>> should also merge the tools to a media-utils repository. >>> >>> It remains a fact of life that dvb and v4l are connected and trying to >>> artificially keep them apart does not make much sense to me. >> >> Easy to do but who should be the maintainer of the dvb things? >> >> According to the wiki[1] these tools are without a maintainer. So, if >> no one cares about them enough to make releases why merge them and >> clutter up the git tree with dead code? >> >> Cheers, >> >> Brandon >> >> [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps > > That's weird. I've recently added support for ISDB-T on it: > http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ That's probably Michael Krufky (user: Jon2856) from what i guess, he has been the one who has been making ground for propaganda's on the wiki. > and we've got some comments at the mailing list. Btw, the patches > I added there also adds DVB-S2 support to szap/scan, but tests > are needed, since I don't have any satellite dish nowadays. Btw, I did spend time to review your code before it is pulled in. You did not even provide a reply on my last mail on the subject, or did I miss that reply of yours ? Regards, Manu -- 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 v1 0/4] Multi-plane video buffer support for V4L2 API and videobuf
Hello, thank you for your comments. >From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] >Pawel Osciak wrote: >> Only streaming I/O has been tested, read/write might not work correctly. >> vivi has been adapted for testing and demonstration purposes, but other >> drivers >> will not compile. Tests have been made on vivi and on an another driver for >> an >> embedded device (those involved dma-contig and USERPTR as well). I am not >> attaching that driver, as I expect nobody would be able to compile/test it >> anyway. > >It would be interesting if you could add userptr support for videobuf-vmalloc, >and >test all supported modes with vivi. This helps to test the changes against >existing >userspace applications before needing to touch on all drivers. Ok, I will, shouldn't be much of a problem. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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: [ANNOUNCE] git tree repositories & libv4l
On Tue, Feb 23, 2010 at 1:23 PM, Hans de Goede wrote: > Hi, > > On 02/23/2010 10:01 AM, Hans Verkuil wrote: >> >>> Hi, >>> >>> On 02/22/2010 11:54 PM, Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: >> >> lib/ >> libv4l1/ >> libv4l2/ >> libv4lconvert/ >> utils/ >> v4l2-dbg >> v4l2-ctl >> cx18-ctl >> ivtv-ctl >> contrib/ >> test/ >> everything else >> git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh >>> >>> Ok, so this will give me a local tree, how do I get this onto linuxtv.org >>> ? >>> >>> Also I need someone to pull: >>> http://linuxtv.org/hg/~hgoede/libv4l >>> >>> (this only contains libv4l commits) >>> >>> Into the: >>> http://linuxtv.org/hg/v4l-dvb >>> >>> Repository, I guess I can ask this directly to Douglas? >>> Thoughts? >>> >>> I've one question, I think we want to do tarbal releases >>> from this new repo (just like I've been doing with libv4l for a while >>> already), and then want distro's to pick up these releases, right ? >>> >>> Are we going to do separate tarbals for the lib and utils directories, >>> or one combined tarbal. I personally vote for one combined tarbal. >>> >>> But this means we will be inflicting some pains on distro's because their >>> libv4l packages will go away and be replaced by a new v4l-utils package. >> >> I would call it media-utils. A nice name and it reflects that it contains >> both dvb and v4l utilities. >> > > Well, the judge is still out on also adding the dvb utils to this git repo. > I'm neutral on that issue, but I will need a co-maintainer for those bits > if they end up in the new v4l-utils repo too. > > About the name, if the dvb utils get added and we want to reflect that, lets > call it v4l-dvb-utils. media-utils is not a very descriptive name for > v4l-dvb > project outsiders. What's the advantage in merging the dvb and v4l2 utils, other than to make the download/clone bigger ? Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V6 2/2] OMAP2/3: Add V4L2 DSS driver support in device.c
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
arch/arm/plat-omap/devices.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 30b5db7..64f2a3a 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -357,6 +357,34 @@ static void omap_init_wdt(void)
static inline void omap_init_wdt(void) {}
#endif
+/*---*/
+
+#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
+ defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
+#if defined (CONFIG_FB_OMAP2) || defined (CONFIG_FB_OMAP2_MODULE)
+static struct resource omap_vout_resource[3 - CONFIG_FB_OMAP2_NUM_FBS] = {
+};
+#else
+static struct resource omap_vout_resource[2] = {
+};
+#endif
+
+static struct platform_device omap_vout_device = {
+ .name = "omap_vout",
+ .num_resources = ARRAY_SIZE(omap_vout_resource),
+ .resource = &omap_vout_resource[0],
+ .id = -1,
+};
+static void omap_init_vout(void)
+{
+ (void) platform_device_register(&omap_vout_device);
+}
+#else
+static inline void omap_init_vout(void) {}
+#endif
+
+/*---*/
+
/*
* This gets called after board-specific INIT_MACHINE, and initializes most
* on-chip peripherals accessible on this board (except for few like USB):
@@ -387,6 +415,7 @@ static int __init omap_init_devices(void)
omap_init_rng();
omap_init_uwire();
omap_init_wdt();
+ omap_init_vout();
return 0;
}
arch_initcall(omap_init_devices);
--
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-V6 0/2] OMAP3: Add V4L2 display driver support
From: Vaibhav Hiremath This is 6th Version of patch-set, adds support for V4L2 display driver ontop of DSS2 framework. Please note that this patch is dependent on patch which add "ti-media" directory (submitted earlier to this patch series). Vaibhav Hiremath (2): OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 OMAP2/3: Add V4L2 DSS driver support in device.c arch/arm/plat-omap/devices.c| 29 + drivers/media/video/ti-media/Kconfig| 12 + drivers/media/video/ti-media/Makefile |4 + drivers/media/video/ti-media/omap_vout.c| 2655 +++ drivers/media/video/ti-media/omap_voutdef.h | 148 ++ drivers/media/video/ti-media/omap_voutlib.c | 258 +++ drivers/media/video/ti-media/omap_voutlib.h | 34 + 7 files changed, 3140 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ti-media/omap_vout.c create mode 100644 drivers/media/video/ti-media/omap_voutdef.h create mode 100644 drivers/media/video/ti-media/omap_voutlib.c create mode 100644 drivers/media/video/ti-media/omap_voutlib.h -- 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: [ANNOUNCE] git tree repositories & libv4l
Hi, On 02/23/2010 10:01 AM, Hans Verkuil wrote: Hi, On 02/22/2010 11:54 PM, Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? Also I need someone to pull: http://linuxtv.org/hg/~hgoede/libv4l (this only contains libv4l commits) Into the: http://linuxtv.org/hg/v4l-dvb Repository, I guess I can ask this directly to Douglas? Thoughts? I've one question, I think we want to do tarbal releases from this new repo (just like I've been doing with libv4l for a while already), and then want distro's to pick up these releases, right ? Are we going to do separate tarbals for the lib and utils directories, or one combined tarbal. I personally vote for one combined tarbal. But this means we will be inflicting some pains on distro's because their libv4l packages will go away and be replaced by a new v4l-utils package. I would call it media-utils. A nice name and it reflects that it contains both dvb and v4l utilities. Well, the judge is still out on also adding the dvb utils to this git repo. I'm neutral on that issue, but I will need a co-maintainer for those bits if they end up in the new v4l-utils repo too. About the name, if the dvb utils get added and we want to reflect that, lets call it v4l-dvb-utils. media-utils is not a very descriptive name for v4l-dvb project outsiders. This is something distro's should be able to handle (it happens more often, and I know Fedora has procedures for this). An alternative would be to name the repo and the tarbals libv4l, either is fine with me (although I'm one of the distro packagers who is going to feel the pain of a package rename and as such wouldn't mind using libv4l as name for the repo and the new tarbals). We never had a proper release procedure for all the utilities. It's about time that we start with that and do proper packaging. So I'd rather make a clean new start now instead of just patching things up. Well we need to do some patching up anyways as I would like to align the versioning of these new tarbals with libv4l versioning, so the first release / tarbal will most likely be something-0.8.0.tar.gz 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: [ANNOUNCE] git tree repositories & libv4l
> Hi, > > On 02/22/2010 11:54 PM, Brandon Philips wrote: >> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else >> >>git clone git://ifup.org/philips/create-v4l-utils.git >>cd create-v4l-utils/ >>./convert.sh >> >> You should now have v4l-utils.git which should have this directory >> struture. If we need to move other things around let me know and I can >> tweak name-filter.sh >> > > Ok, so this will give me a local tree, how do I get this onto linuxtv.org > ? > > Also I need someone to pull: > http://linuxtv.org/hg/~hgoede/libv4l > > (this only contains libv4l commits) > > Into the: > http://linuxtv.org/hg/v4l-dvb > > Repository, I guess I can ask this directly to Douglas? > >> Thoughts? > > I've one question, I think we want to do tarbal releases > from this new repo (just like I've been doing with libv4l for a while > already), and then want distro's to pick up these releases, right ? > > Are we going to do separate tarbals for the lib and utils directories, > or one combined tarbal. I personally vote for one combined tarbal. > > But this means we will be inflicting some pains on distro's because their > libv4l packages will go away and be replaced by a new v4l-utils package. I would call it media-utils. A nice name and it reflects that it contains both dvb and v4l utilities. > This is something distro's should be able to handle (it happens more > often, and I > know Fedora has procedures for this). > > An alternative would be to name the repo and the tarbals libv4l, either is > fine > with me (although I'm one of the distro packagers who is going to feel the > pain > of a package rename and as such wouldn't mind using libv4l as name for the > repo and the new tarbals). We never had a proper release procedure for all the utilities. It's about time that we start with that and do proper packaging. So I'd rather make a clean new start now instead of just patching things up. Just my opinions, of course. Regards. Hans > > 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 > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [ANNOUNCE] git tree repositories & libv4l
Hi, On 02/22/2010 11:54 PM, Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? Also I need someone to pull: http://linuxtv.org/hg/~hgoede/libv4l (this only contains libv4l commits) Into the: http://linuxtv.org/hg/v4l-dvb Repository, I guess I can ask this directly to Douglas? Thoughts? I've one question, I think we want to do tarbal releases from this new repo (just like I've been doing with libv4l for a while already), and then want distro's to pick up these releases, right ? Are we going to do separate tarbals for the lib and utils directories, or one combined tarbal. I personally vote for one combined tarbal. But this means we will be inflicting some pains on distro's because their libv4l packages will go away and be replaced by a new v4l-utils package. This is something distro's should be able to handle (it happens more often, and I know Fedora has procedures for this). An alternative would be to name the repo and the tarbals libv4l, either is fine with me (although I'm one of the distro packagers who is going to feel the pain of a package rename and as such wouldn't mind using libv4l as name for the repo and the new tarbals). 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
[PATCH-V1 10/10] AM3517: Add VPFE Capture driver support
From: Vaibhav Hiremath
AM3517 and DM644x uses same CCDC IP, so reusing the driver
for AM3517.
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/board-am3517evm.c | 160 +
1 files changed, 160 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 195d0ce..9411979 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,11 +30,164 @@
#include
#include
+#include
#include
#include
+#include
+#include
+
#include "mux.h"
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = "Composite",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = "S-Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = "tvp5146",
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5C),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
+ switch (vdint) {
+ /* VD0 interrrupt */
+ case INT_35XX_CCDC_VD0_IRQ:
+ vpfe_int_clr &= ~AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ break;
+ /* VD1 interrrupt */
+ case INT_35XX_CCDC_VD1_IRQ:
+ vpfe_int_clr &= ~AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ break;
+ /* VD2 interrrupt */
+ case INT_35XX_CCDC_VD2_IRQ:
+ vpfe_int_clr &= ~AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ break;
+ /* Clear all interrrupts */
+ default:
+ vpfe_int_clr &= ~(AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ vpfe_int_clr |= (AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ break;
+ }
+ omap_ctrl_writel(vpfe_int_clr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs= ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 3,
+ .sub_devs = vpfe_sub_devs,
+ .clr_intr = am3517_evm_clear_vpfe_intr,
+ .card_name = "DM6446 EVM",
+ .ccdc = "DM6446 CCDC",
+};
+
+static struct resource vpfe_resources[] = {
+ {
+ .start = INT_35XX_CCDC_VD0_IRQ,
+ .end= INT_35XX_CCDC_VD0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_CCDC_VD1_IRQ,
+ .end= INT_35XX_CCDC_VD1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device vpfe_capture_dev = {
+ .name = CAPTURE_DRV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(vpfe_resources),
+ .resource = vpfe_resources,
+ .dev = {
+ .dma_mask = &vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = &vpfe_cfg,
+ },
+};
+
+static struct resource dm64
[PATCH-V1 02/10] tvp514x: add YUYV format support
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/tvp514x.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 26b4e71..08fe579 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -212,6 +212,13 @@ static const struct v4l2_fmtdesc tvp514x_fmt_list[] = {
.description = "8-bit UYVY 4:2:2 Format",
.pixelformat = V4L2_PIX_FMT_UYVY,
},
+ {
+.index = 1,
+.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+.flags = 0,
+.description = "8-bit YUYV 4:2:2 Format",
+.pixelformat = V4L2_PIX_FMT_YUYV,
+ },
};
/**
--
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-V1 08/10] DM644x CCDC : Add Suspend/Resume Support
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/ti-media/dm644x_ccdc.c | 114 +++
drivers/media/video/ti-media/dm644x_ccdc_regs.h |2 +-
2 files changed, 115 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c
b/drivers/media/video/ti-media/dm644x_ccdc.c
index 506bbf5..3045ebc 100644
--- a/drivers/media/video/ti-media/dm644x_ccdc.c
+++ b/drivers/media/video/ti-media/dm644x_ccdc.c
@@ -100,6 +100,9 @@ static u32 ccdc_raw_bayer_pix_formats[] =
static u32 ccdc_raw_yuv_pix_formats[] =
{V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
+/* CCDC Save/Restore context */
+static u32 ccdc_ctx[CCDC_REG_END / sizeof(u32)];
+
/* register access routines */
static inline u32 regr(u32 offset)
{
@@ -845,6 +848,87 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
return 0;
}
+static void ccdc_save_context(void)
+{
+ ccdc_ctx[CCDC_PCR >> 2] = regr(CCDC_PCR);
+ ccdc_ctx[CCDC_SYN_MODE >> 2] = regr(CCDC_SYN_MODE);
+ ccdc_ctx[CCDC_HD_VD_WID >> 2] = regr(CCDC_HD_VD_WID);
+ ccdc_ctx[CCDC_PIX_LINES >> 2] = regr(CCDC_PIX_LINES);
+ ccdc_ctx[CCDC_HORZ_INFO >> 2] = regr(CCDC_HORZ_INFO);
+ ccdc_ctx[CCDC_VERT_START >> 2] = regr(CCDC_VERT_START);
+ ccdc_ctx[CCDC_VERT_LINES >> 2] = regr(CCDC_VERT_LINES);
+ ccdc_ctx[CCDC_CULLING >> 2] = regr(CCDC_CULLING);
+ ccdc_ctx[CCDC_HSIZE_OFF >> 2] = regr(CCDC_HSIZE_OFF);
+ ccdc_ctx[CCDC_SDOFST >> 2] = regr(CCDC_SDOFST);
+ ccdc_ctx[CCDC_SDR_ADDR >> 2] = regr(CCDC_SDR_ADDR);
+ ccdc_ctx[CCDC_CLAMP >> 2] = regr(CCDC_CLAMP);
+ ccdc_ctx[CCDC_DCSUB >> 2] = regr(CCDC_DCSUB);
+ ccdc_ctx[CCDC_COLPTN >> 2] = regr(CCDC_COLPTN);
+ ccdc_ctx[CCDC_BLKCMP >> 2] = regr(CCDC_BLKCMP);
+ ccdc_ctx[CCDC_FPC >> 2] = regr(CCDC_FPC);
+ ccdc_ctx[CCDC_FPC_ADDR >> 2] = regr(CCDC_FPC_ADDR);
+ ccdc_ctx[CCDC_VDINT >> 2] = regr(CCDC_VDINT);
+ ccdc_ctx[CCDC_ALAW >> 2] = regr(CCDC_ALAW);
+ ccdc_ctx[CCDC_REC656IF >> 2] = regr(CCDC_REC656IF);
+ ccdc_ctx[CCDC_CCDCFG >> 2] = regr(CCDC_CCDCFG);
+ ccdc_ctx[CCDC_FMTCFG >> 2] = regr(CCDC_FMTCFG);
+ ccdc_ctx[CCDC_FMT_HORZ >> 2] = regr(CCDC_FMT_HORZ);
+ ccdc_ctx[CCDC_FMT_VERT >> 2] = regr(CCDC_FMT_VERT);
+ ccdc_ctx[CCDC_FMT_ADDR0 >> 2] = regr(CCDC_FMT_ADDR0);
+ ccdc_ctx[CCDC_FMT_ADDR1 >> 2] = regr(CCDC_FMT_ADDR1);
+ ccdc_ctx[CCDC_FMT_ADDR2 >> 2] = regr(CCDC_FMT_ADDR2);
+ ccdc_ctx[CCDC_FMT_ADDR3 >> 2] = regr(CCDC_FMT_ADDR3);
+ ccdc_ctx[CCDC_FMT_ADDR4 >> 2] = regr(CCDC_FMT_ADDR4);
+ ccdc_ctx[CCDC_FMT_ADDR5 >> 2] = regr(CCDC_FMT_ADDR5);
+ ccdc_ctx[CCDC_FMT_ADDR6 >> 2] = regr(CCDC_FMT_ADDR6);
+ ccdc_ctx[CCDC_FMT_ADDR7 >> 2] = regr(CCDC_FMT_ADDR7);
+ ccdc_ctx[CCDC_PRGEVEN_0 >> 2] = regr(CCDC_PRGEVEN_0);
+ ccdc_ctx[CCDC_PRGEVEN_1 >> 2] = regr(CCDC_PRGEVEN_1);
+ ccdc_ctx[CCDC_PRGODD_0 >> 2] = regr(CCDC_PRGODD_0);
+ ccdc_ctx[CCDC_PRGODD_1 >> 2] = regr(CCDC_PRGODD_1);
+ ccdc_ctx[CCDC_VP_OUT >> 2] = regr(CCDC_VP_OUT);
+}
+
+static void ccdc_restore_context(void)
+{
+ regw(ccdc_ctx[CCDC_SYN_MODE >> 2], CCDC_SYN_MODE);
+ regw(ccdc_ctx[CCDC_HD_VD_WID >> 2], CCDC_HD_VD_WID);
+ regw(ccdc_ctx[CCDC_PIX_LINES >> 2], CCDC_PIX_LINES);
+ regw(ccdc_ctx[CCDC_HORZ_INFO >> 2], CCDC_HORZ_INFO);
+ regw(ccdc_ctx[CCDC_VERT_START >> 2], CCDC_VERT_START);
+ regw(ccdc_ctx[CCDC_VERT_LINES >> 2], CCDC_VERT_LINES);
+ regw(ccdc_ctx[CCDC_CULLING >> 2], CCDC_CULLING);
+ regw(ccdc_ctx[CCDC_HSIZE_OFF >> 2], CCDC_HSIZE_OFF);
+ regw(ccdc_ctx[CCDC_SDOFST >> 2], CCDC_SDOFST);
+ regw(ccdc_ctx[CCDC_SDR_ADDR >> 2], CCDC_SDR_ADDR);
+ regw(ccdc_ctx[CCDC_CLAMP >> 2], CCDC_CLAMP);
+ regw(ccdc_ctx[CCDC_DCSUB >> 2], CCDC_DCSUB);
+ regw(ccdc_ctx[CCDC_COLPTN >> 2], CCDC_COLPTN);
+ regw(ccdc_ctx[CCDC_BLKCMP >> 2], CCDC_BLKCMP);
+ regw(ccdc_ctx[CCDC_FPC >> 2], CCDC_FPC);
+ regw(ccdc_ctx[CCDC_FPC_ADDR >> 2], CCDC_FPC_ADDR);
+ regw(ccdc_ctx[CCDC_VDINT >> 2], CCDC_VDINT);
+ regw(ccdc_ctx[CCDC_ALAW >> 2], CCDC_ALAW);
+ regw(ccdc_ctx[CCDC_REC656IF >> 2], CCDC_REC656IF);
+ regw(ccdc_ctx[CCDC_CCDCFG >> 2], CCDC_CCDCFG);
+ regw(ccdc_ctx[CCDC_FMTCFG >> 2], CCDC_FMTCFG);
+ regw(ccdc_ctx[CCDC_FMT_HORZ >> 2], CCDC_FMT_HORZ);
+ regw(ccdc_ctx[CCDC_FMT_VERT >> 2], CCDC_FMT_VERT);
+ regw(ccdc_ctx[CCDC_FMT_ADDR0 >> 2], CCDC_FMT_ADDR0);
+ regw(ccdc_ctx[CCDC_FMT_ADDR1 >> 2], CCDC_FMT_ADDR1);
+ regw(ccdc_ctx[CCDC_FMT_ADDR2 >> 2], CCDC_FMT_ADDR2);
+ regw(ccdc_ctx[CCDC_FMT_ADDR3 >> 2], CCDC_FMT_ADDR3);
+ regw(ccdc_ctx[CCDC_FMT_ADDR4 >> 2], CCDC_FMT_ADDR4);
+ regw(ccdc_ctx[CCDC_FMT_ADDR5 >> 2], CCDC_FMT_ADDR5);
+ regw(ccdc_ctx[CCDC_FMT_ADDR6 >> 2], CCDC_FMT_ADDR6);
+ regw(ccdc_ctx[CCDC_FMT_ADDR7 >> 2], CCDC_FMT_ADDR7);
+ regw(ccdc_ctx
[PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of operation
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Muralidharan Karicheri
---
drivers/media/video/ti-media/vpfe_capture.c | 94 ++
1 files changed, 79 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index cece265..7d4ab44 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -538,7 +538,24 @@ static void vpfe_schedule_next_buffer(struct vpfe_device
*vpfe_dev)
struct videobuf_buffer, queue);
list_del(&vpfe_dev->next_frm->queue);
vpfe_dev->next_frm->state = VIDEOBUF_ACTIVE;
- addr = videobuf_to_dma_contig(vpfe_dev->next_frm);
+ if (V4L2_MEMORY_USERPTR == vpfe_dev->memory)
+ addr = vpfe_dev->cur_frm->boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev->next_frm);
+
+ ccdc_dev->hw_ops.setfbaddr(addr);
+}
+
+static void vpfe_schedule_bottom_field(struct vpfe_device *vpfe_dev)
+{
+ unsigned long addr;
+
+ if (V4L2_MEMORY_USERPTR == vpfe_dev->memory)
+ addr = vpfe_dev->cur_frm->boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev->cur_frm);
+
+ addr += vpfe_dev->field_off;
ccdc_dev->hw_ops.setfbaddr(addr);
}
@@ -559,7 +576,6 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
{
struct vpfe_device *vpfe_dev = dev_id;
enum v4l2_field field;
- unsigned long addr;
int fid;
v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "\nStarting vpfe_isr...\n");
@@ -604,10 +620,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
* the CCDC memory address
*/
if (field == V4L2_FIELD_SEQ_TB) {
- addr =
- videobuf_to_dma_contig(vpfe_dev->cur_frm);
- addr += vpfe_dev->field_off;
- ccdc_dev->hw_ops.setfbaddr(addr);
+ vpfe_schedule_bottom_field(vpfe_dev);
}
goto clear_intr;
}
@@ -1234,7 +1247,10 @@ static int vpfe_videobuf_setup(struct videobuf_queue *vq,
struct vpfe_device *vpfe_dev = fh->vpfe_dev;
v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_buffer_setup\n");
- *size = config_params.device_bufsize;
+ *size = vpfe_dev->fmt.fmt.pix.sizeimage;
+ if (vpfe_dev->memory == V4L2_MEMORY_MMAP &&
+ vpfe_dev->fmt.fmt.pix.sizeimage > config_params.device_bufsize)
+ *size = config_params.device_bufsize;
if (*count < config_params.min_numbuffers)
*count = config_params.min_numbuffers;
@@ -1243,6 +1259,46 @@ static int vpfe_videobuf_setup(struct videobuf_queue *vq,
return 0;
}
+/*
+ * vpfe_uservirt_to_phys: This function is used to convert user
+ * space virtual address to physical address.
+ */
+static u32 vpfe_uservirt_to_phys(struct vpfe_device *vpfe_dev, u32 virtp)
+{
+ struct mm_struct *mm = current->mm;
+ unsigned long physp = 0;
+ struct vm_area_struct *vma;
+
+ vma = find_vma(mm, virtp);
+
+ /* For kernel direct-mapped memory, take the easy way */
+ if (virtp >= PAGE_OFFSET)
+ physp = virt_to_phys((void *)virtp);
+ else if (vma && (vma->vm_flags & VM_IO) && (vma->vm_pgoff))
+ /* this will catch, kernel-allocated, mmaped-to-usermode addr */
+ physp = (vma->vm_pgoff << PAGE_SHIFT) + (virtp - vma->vm_start);
+ else {
+ /* otherwise, use get_user_pages() for general userland pages */
+ int res, nr_pages = 1;
+ struct page *pages;
+ down_read(¤t->mm->mmap_sem);
+
+ res = get_user_pages(current, current->mm,
+virtp, nr_pages, 1, 0, &pages, NULL);
+ up_read(¤t->mm->mmap_sem);
+
+ if (res == nr_pages)
+ physp = __pa(page_address(&pages[0]) +
+(virtp & ~PAGE_MASK));
+ else {
+ v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
+ "get_user_pages failed\n");
+ return 0;
+ }
+ }
+ return physp;
+}
+
static int vpfe_videobuf_prepare(struct videobuf_queue *vq,
struct videobuf_buffer *vb,
enum v4l2_field field)
@@ -1259,6 +1315,18 @@ static int vpfe_videobuf_prepare(struct videobuf_queue
*vq,
vb->size = vpfe_dev->fmt.fmt.pix.sizeimage;
vb->field = field;
}
+
+ if (V4L2_MEMORY_USERPTR == vpfe_dev->memory) {
+ if (!vb->baddr) {
+ v4l2_dbg(1, debug, &vpfe_de
[PATCH-V1 06/10] DM644x CCDC: Add 10bit BT support
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/ti-media/dm644x_ccdc.c | 16 +---
drivers/media/video/ti-media/dm644x_ccdc_regs.h |8
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c
b/drivers/media/video/ti-media/dm644x_ccdc.c
index a011d40..506bbf5 100644
--- a/drivers/media/video/ti-media/dm644x_ccdc.c
+++ b/drivers/media/video/ti-media/dm644x_ccdc.c
@@ -399,7 +399,11 @@ void ccdc_config_ycbcr(void)
* configure the FID, VD, HD pin polarity,
* fld,hd pol positive, vd negative, 8-bit data
*/
- syn_mode |= CCDC_SYN_MODE_VD_POL_NEGATIVE | CCDC_SYN_MODE_8BITS;
+ syn_mode |= CCDC_SYN_MODE_VD_POL_NEGATIVE;
+ if (ccdc_cfg.if_type == VPFE_BT656_10BIT)
+ syn_mode |= CCDC_SYN_MODE_10BITS;
+ else
+ syn_mode |= CCDC_SYN_MODE_8BITS;
} else {
/* y/c external sync mode */
syn_mode |= (((params->fid_pol & CCDC_FID_POL_MASK) <<
@@ -418,8 +422,13 @@ void ccdc_config_ycbcr(void)
* configure the order of y cb cr in SDRAM, and disable latch
* internal register on vsync
*/
- regw((params->pix_order << CCDC_CCDCFG_Y8POS_SHIFT) |
-CCDC_LATCH_ON_VSYNC_DISABLE, CCDC_CCDCFG);
+ if (ccdc_cfg.if_type == VPFE_BT656_10BIT)
+ regw((params->pix_order << CCDC_CCDCFG_Y8POS_SHIFT) |
+ CCDC_LATCH_ON_VSYNC_DISABLE | CCDC_CCDCFG_BW656_10BIT,
+ CCDC_CCDCFG);
+ else
+ regw((params->pix_order << CCDC_CCDCFG_Y8POS_SHIFT) |
+ CCDC_LATCH_ON_VSYNC_DISABLE, CCDC_CCDCFG);
/*
* configure the horizontal line offset. This should be a
@@ -825,6 +834,7 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
case VPFE_BT656:
case VPFE_YCBCR_SYNC_16:
case VPFE_YCBCR_SYNC_8:
+ case VPFE_BT656_10BIT:
ccdc_cfg.ycbcr.vd_pol = params->vdpol;
ccdc_cfg.ycbcr.hd_pol = params->hdpol;
break;
diff --git a/drivers/media/video/ti-media/dm644x_ccdc_regs.h
b/drivers/media/video/ti-media/dm644x_ccdc_regs.h
index 6e5d053..b18d166 100644
--- a/drivers/media/video/ti-media/dm644x_ccdc_regs.h
+++ b/drivers/media/video/ti-media/dm644x_ccdc_regs.h
@@ -135,11 +135,19 @@
#define CCDC_SYN_MODE_INPMOD_SHIFT 12
#define CCDC_SYN_MODE_INPMOD_MASK 3
#define CCDC_SYN_MODE_8BITS(7 << 8)
+#define CCDC_SYN_MODE_10BITS (6 << 8)
+#define CCDC_SYN_MODE_11BITS (5 << 8)
+#define CCDC_SYN_MODE_12BITS (4 << 8)
+#define CCDC_SYN_MODE_13BITS (3 << 8)
+#define CCDC_SYN_MODE_14BITS (2 << 8)
+#define CCDC_SYN_MODE_15BITS (1 << 8)
+#define CCDC_SYN_MODE_16BITS (0 << 8)
#define CCDC_SYN_FLDMODE_MASK 1
#define CCDC_SYN_FLDMODE_SHIFT 7
#define CCDC_REC656IF_BT656_EN 3
#define CCDC_SYN_MODE_VD_POL_NEGATIVE (1 << 2)
#define CCDC_CCDCFG_Y8POS_SHIFT11
+#define CCDC_CCDCFG_BW656_10BIT(1 << 5)
#define CCDC_SDOFST_FIELD_INTERLEAVED 0x249
#define CCDC_NO_CULLING0x00ff
#endif
--
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-V1 01/10] Makfile:Removed duplicate entry of davinci
From: Vaibhav Hiremath Signed-off-by: Vaibhav Hiremath --- drivers/media/video/Makefile |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index b88b617..c51c386 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -160,8 +160,6 @@ obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o -obj-$(CONFIG_ARCH_DAVINCI) += davinci/ - obj-$(CONFIG_VIDEO_AU0828) += au0828/ obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/ -- 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-V1 05/10] VPFE Capture: Add call back function for interrupt clear to vpfe_cfg
From: Vaibhav Hiremath
For the devices like AM3517, it is expected that driver clears the
interrupt in ISR. Since this is device spcific, callback function
added to the platform_data.
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/ti-media/vpfe_capture.c | 24
include/media/ti-media/vpfe_capture.h |2 ++
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index 2f9d3bb..3ffd636 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -475,6 +475,11 @@ static int vpfe_initialize_device(struct vpfe_device
*vpfe_dev)
ret = ccdc_dev->hw_ops.open(vpfe_dev->pdev);
if (!ret)
vpfe_dev->initialized = 1;
+
+ /* Clear all VPFE/CCDC interrupts */
+ if (vpfe_dev->cfg->clr_intr)
+ vpfe_dev->cfg->clr_intr(-1);
+
unlock:
mutex_unlock(&ccdc_lock);
return ret;
@@ -562,7 +567,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
/* if streaming not started, don't do anything */
if (!vpfe_dev->started)
- return IRQ_HANDLED;
+ goto clear_intr;
/* only for 6446 this will be applicable */
if (NULL != ccdc_dev->hw_ops.reset)
@@ -574,7 +579,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
"frame format is progressive...\n");
if (vpfe_dev->cur_frm != vpfe_dev->next_frm)
vpfe_process_buffer_complete(vpfe_dev);
- return IRQ_HANDLED;
+ goto clear_intr;
}
/* interlaced or TB capture check which field we are in hardware */
@@ -604,7 +609,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
addr += vpfe_dev->field_off;
ccdc_dev->hw_ops.setfbaddr(addr);
}
- return IRQ_HANDLED;
+ goto clear_intr;
}
/*
* if one field is just being captured configure
@@ -624,6 +629,10 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
*/
vpfe_dev->field_id = fid;
}
+clear_intr:
+ if (vpfe_dev->cfg->clr_intr)
+ vpfe_dev->cfg->clr_intr(irq);
+
return IRQ_HANDLED;
}
@@ -635,8 +644,11 @@ static irqreturn_t vdint1_isr(int irq, void *dev_id)
v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "\nInside vdint1_isr...\n");
/* if streaming not started, don't do anything */
- if (!vpfe_dev->started)
+ if (!vpfe_dev->started) {
+ if (vpfe_dev->cfg->clr_intr)
+ vpfe_dev->cfg->clr_intr(irq);
return IRQ_HANDLED;
+ }
spin_lock(&vpfe_dev->dma_queue_lock);
if ((vpfe_dev->fmt.fmt.pix.field == V4L2_FIELD_NONE) &&
@@ -644,6 +656,10 @@ static irqreturn_t vdint1_isr(int irq, void *dev_id)
vpfe_dev->cur_frm == vpfe_dev->next_frm)
vpfe_schedule_next_buffer(vpfe_dev);
spin_unlock(&vpfe_dev->dma_queue_lock);
+
+ if (vpfe_dev->cfg->clr_intr)
+ vpfe_dev->cfg->clr_intr(irq);
+
return IRQ_HANDLED;
}
diff --git a/include/media/ti-media/vpfe_capture.h
b/include/media/ti-media/vpfe_capture.h
index 5287368..f0a7b7a 100644
--- a/include/media/ti-media/vpfe_capture.h
+++ b/include/media/ti-media/vpfe_capture.h
@@ -94,6 +94,8 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+ /* Function for Clearing the interrupt */
+ void (*clr_intr)(int vdint);
};
struct vpfe_device {
--
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-V1 07/10] Davinci VPFE Capture:Return 0 from suspend/resume
From: Vaibhav Hiremath
Now Suspend/Resume functionality is being handled by respective CCDC
code, so return true (0) from bridge suspend/resume function.
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/ti-media/vpfe_capture.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index 3ffd636..cece265 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -2022,18 +2022,14 @@ static int __devexit vpfe_remove(struct platform_device
*pdev)
return 0;
}
-static int
-vpfe_suspend(struct device *dev)
+static int vpfe_suspend(struct device *dev)
{
- /* add suspend code here later */
- return -1;
+ return 0;
}
-static int
-vpfe_resume(struct device *dev)
+static int vpfe_resume(struct device *dev)
{
- /* add resume code here later */
- return -1;
+ return 0;
}
static const struct dev_pm_ops vpfe_dev_pm_ops = {
--
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-V1 04/10] AM3517 CCDC: Debug register read prints removed
From: Vaibhav Hiremath Signed-off-by: Vaibhav Hiremath --- drivers/media/video/ti-media/dm644x_ccdc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c b/drivers/media/video/ti-media/dm644x_ccdc.c index 727f7e1..a011d40 100644 --- a/drivers/media/video/ti-media/dm644x_ccdc.c +++ b/drivers/media/video/ti-media/dm644x_ccdc.c @@ -434,7 +434,6 @@ void ccdc_config_ycbcr(void) ccdc_sbl_reset(); dev_dbg(ccdc_cfg.dev, "\nEnd of ccdc_config_ycbcr...\n"); - ccdc_readregs(); } static void ccdc_config_black_clamp(struct ccdc_black_clamp *bclamp) -- 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-V1 00/10] VPFE Capture Bug Fixes and feature enhancement
From: Vaibhav Hiremath This is second version of patch series fixing few bugs and adds some feature enhancements - Changes: - Introduce t-media directory - Add YUYV support to tvp514x.c - Add UserPtr support to vpfe_capture - Call-back function for interrupt clear (required for AM3517) - VPFE Capture support for AM3517 - Suspend Resume support Changes from last version - - Merge board specific changes to patch "introduce ti-media directory" (comment from Hans) Vaibhav Hiremath (10): Makfile:Removed duplicate entry of davinci tvp514x: add YUYV format support Introducing ti-media directory AM3517 CCDC: Debug register read prints removed VPFE Capture: Add call back function for interrupt clear to vpfe_cfg DM644x CCDC: Add 10bit BT support Davinci VPFE Capture:Return 0 from suspend/resume DM644x CCDC : Add Suspend/Resume Support VPFE Capture: Add support for USERPTR mode of operation AM3517: Add VPFE Capture driver support arch/arm/mach-davinci/include/mach/dm355.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- arch/arm/mach-omap2/board-am3517evm.c | 160 ++ drivers/media/video/Kconfig | 84 +- drivers/media/video/Makefile|4 +- drivers/media/video/davinci/Makefile| 17 - drivers/media/video/davinci/ccdc_hw_device.h| 110 -- drivers/media/video/davinci/dm355_ccdc.c| 1082 --- drivers/media/video/davinci/dm355_ccdc_regs.h | 310 drivers/media/video/davinci/dm644x_ccdc.c | 967 -- drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 -- drivers/media/video/davinci/vpfe_capture.c | 2054 - drivers/media/video/davinci/vpif.c | 296 --- drivers/media/video/davinci/vpif.h | 642 --- drivers/media/video/davinci/vpif_capture.c | 2168 --- drivers/media/video/davinci/vpif_capture.h | 165 -- drivers/media/video/davinci/vpif_display.c | 1654 - drivers/media/video/davinci/vpif_display.h | 175 -- drivers/media/video/davinci/vpss.c | 301 drivers/media/video/ti-media/Kconfig| 88 + drivers/media/video/ti-media/Makefile | 17 + drivers/media/video/ti-media/ccdc_hw_device.h | 110 ++ drivers/media/video/ti-media/dm355_ccdc.c | 1082 +++ drivers/media/video/ti-media/dm355_ccdc_regs.h | 310 drivers/media/video/ti-media/dm644x_ccdc.c | 1090 drivers/media/video/ti-media/dm644x_ccdc_regs.h | 153 ++ drivers/media/video/ti-media/vpfe_capture.c | 2130 ++ drivers/media/video/ti-media/vpif.c | 296 +++ drivers/media/video/ti-media/vpif.h | 642 +++ drivers/media/video/ti-media/vpif_capture.c | 2168 +++ drivers/media/video/ti-media/vpif_capture.h | 165 ++ drivers/media/video/ti-media/vpif_display.c | 1654 + drivers/media/video/ti-media/vpif_display.h | 175 ++ drivers/media/video/ti-media/vpss.c | 301 drivers/media/video/tvp514x.c |7 + include/media/davinci/ccdc_types.h | 43 - include/media/davinci/dm355_ccdc.h | 321 include/media/davinci/dm644x_ccdc.h | 184 -- include/media/davinci/vpfe_capture.h| 200 --- include/media/davinci/vpfe_types.h | 51 - include/media/davinci/vpss.h| 69 - include/media/ti-media/ccdc_types.h | 43 + include/media/ti-media/dm355_ccdc.h | 321 include/media/ti-media/dm644x_ccdc.h| 184 ++ include/media/ti-media/vpfe_capture.h | 202 +++ include/media/ti-media/vpfe_types.h | 51 + include/media/ti-media/vpss.h | 69 + 47 files changed, 11423 insertions(+), 11041 deletions(-) delete mode 100644 drivers/media/video/davinci/Makefile delete mode 100644 drivers/media/video/davinci/ccdc_hw_device.h delete mode 100644 drivers/media/video/davinci/dm355_ccdc.c delete mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/dm644x_ccdc.c delete mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/vpfe_capture.c delete mode 100644 drivers/media/video/davinci/vpif.c delete mode 100644 drivers/media/video/davinci/vpif.h delete mode 100644 drivers/media/video/davinci/vpif_capture.c delete mode 100644 drivers/media/video/davinci/vpif_capture.h delete mode 100644 drivers/media/video/davinci/vpif_display.c delete mode 100644 drivers/media/video/davinci/vpif_display.h delete mode 100644 drivers/media/video/davinci/vpss.c create mode 100644 drivers/media/video/ti-media/Kconfig create mode 100644 drivers/media/video/ti-media/Makefile creat
Re: modprobe em28xx failed for MSI Vox II USB
Carlos, Thanks for the reply. Actually your usb stick is MSI TV VOX 8609 USB 2.0 which look quite different from my MSI Vox II USB. Since there is already support for MSI VOX USB 2.0. I was hoping that it will be a quick win to get Vox II supported. Hopefully someone will be able to develop a patch to make it work. I am prepared to provide assistant in whatever way I can. I am probably going to dismantle the stick and post some pictures and information. regards, Hock. On Tue, Feb 23, 2010 at 4:19 PM, Carlos Jenkins wrote: > Hi, the symbol problem could get solved by restarting the system. > > On the other hand check this thread: > > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/15991/ > > Actually, the MSI Vox USB II device isn't working with the current tree. > > Cheers > -- 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: modprobe em28xx failed for MSI Vox II USB
Hi, the symbol problem could get solved by restarting the system. On the other hand check this thread: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/15991/ Actually, the MSI Vox USB II device isn't working with the current tree. Cheers -- 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: [ANNOUNCE] git tree repositories & libv4l
On 22:12 Mon 22 Feb 2010, Mauro Carvalho Chehab wrote: > Mauro Carvalho Chehab wrote: > >> According to the wiki[1] these tools are without a maintainer. So, if > >> no one cares about them enough to make releases why merge them and > >> clutter up the git tree with dead code? > >> > >> [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps > > > > That's weird. I've recently added support for ISDB-T on it: > > http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ > > > > and we've got some comments at the mailing list. Btw, the patches > > I added there also adds DVB-S2 support to szap/scan, but tests > > are needed, since I don't have any satellite dish nowadays. > > > > That's said, if all the issues are the ones listed above, I can try > to address them on the next months, to put it into a better > shape. That's said, I don't think we should have a single maintainer > for it: there are too many DTV standards already, and probably > nobody with enough time has access to all of those (DVB-T, DVB-T2, > DVB-S, DVB-S2, ISDB-T, ISDB-S, ATSC, DSS, ...). So, I think we need > a team of volunteers that will try to help with the standards they > have access. I was not suggesting a single maintainer but I wanted to make sure there was actual interest in maintaing and fixing these dvb things. I don't interact much at all with DVB so all I had to go on was the wiki page. > That's said, I'm starting to agree with Hans: maybe the better seems > to merge it with v4l2-apps, to get synergy in terms, at least in > terms of packet management. > > Comments? Seems reasonable to me. I would be willing to be the merge point for all of the various maintainers of dvb and v4l things and release manager for making the actual tar.gz releases. I wrote up the conversion for dvb-apps too. The merge of the two trees conflict pretty trivially so it should be easy to clean up if we go this route: # unmerged: COPYING # unmerged: INSTALL # unmerged: Make.rules # unmerged: Makefile # unmerged: README # unmerged: lib/Makefile # unmerged: utils/Makefile If you want to give it a whirl. git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ git checkout -b dvb-apps-too origin/dvb-apps-too ./convert.sh The result will be in step3 with the merge conflicts. Cheers, Brandon -- 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
