Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)
On Thursday 25 June 2009 04:40:11 Andy Walls wrote: On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote: On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote: There is already an s_gpio in the core ops. It would be simple to add a g_gpio as well if needed. Hans, As you probably know int (*s_gpio)(v4l2_subdev *sd, u32 val); is a little too simple for initial setup of GPIO pins. With the collection of chips cores supported by cx25840 module, setting the GPIO configuration also requires: direction: In or Out multiplexed pins: GPIO or some other function I could tack on direction as an argument to s_gpio(), but I think that is a bit inconvenient.. I'd rather have a int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval); but that leaves out the method for multiplexed pin/pad configuration. Perhaps explicity setting a GPIO direction to OUT could be an implicit indication that a multiplexed pin should be set to it's GPIO function. However, that doesn't help for GPIO inputs that might have their pins multiplexed with other functions. Here's an idea on how to specify multiplexed pin configuration information and it could involve pins that multiplex functions other than GPIO (the CX25843 is quite flexible in this regard): int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function); The type checking ends up pretty weak, but I figured it was better than a 'void *config' that had a subdev specific collection of pin configuration information. Comments? Hi Andy, Is there any driver that needs to setup the multiplex functions? If not, then I would not add support for this at the moment. Adding unused code is a bad idea in general. In addition, such information should only be needed at initialization time, and since we now have the new v4l2_i2c_new_subdev_cfg function I think that that is the right way to do this. The same approach can be used for setting the gpio pin directions. That too is something you setup at config time. Regards, Hans -- 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
Hauppauge WinTV-HVR 900H support on Linux, any news?
Hi all, is there any news or progress with the work for Hauppauge WinTV-HVR 900H under Linux? I read in March some emails here about this theme and I was very happy with it, because I have one of these cards. But suddenly there were no more news about it. I am still reading the linux-media mail list summary every day, but there are no more news. I can help testing, but only the digital section, cause here where I live the analogic TV is already disabled. Please.. any ray of hope? :) Thanks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)
On Thu, 2009-06-25 at 08:39 +0200, Hans Verkuil wrote: On Thursday 25 June 2009 04:40:11 Andy Walls wrote: On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote: On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote: There is already an s_gpio in the core ops. It would be simple to add a g_gpio as well if needed. Hans, As you probably know int (*s_gpio)(v4l2_subdev *sd, u32 val); is a little too simple for initial setup of GPIO pins. With the collection of chips cores supported by cx25840 module, setting the GPIO configuration also requires: direction: In or Out multiplexed pins: GPIO or some other function I could tack on direction as an argument to s_gpio(), but I think that is a bit inconvenient.. I'd rather have a int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval); but that leaves out the method for multiplexed pin/pad configuration. Perhaps explicity setting a GPIO direction to OUT could be an implicit indication that a multiplexed pin should be set to it's GPIO function. However, that doesn't help for GPIO inputs that might have their pins multiplexed with other functions. Here's an idea on how to specify multiplexed pin configuration information and it could involve pins that multiplex functions other than GPIO (the CX25843 is quite flexible in this regard): int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function); The type checking ends up pretty weak, but I figured it was better than a 'void *config' that had a subdev specific collection of pin configuration information. Comments? Hi Andy, Is there any driver that needs to setup the multiplex functions? If not, then I would not add support for this at the moment. Well, the group of GPIO pins in question for the CX23885 are all multiplexed with other functions. We could just initialize the CX23885 to have those pins set as GPIOs, but I have to check the cx23885 driver to make sure that's safe. Adding unused code is a bad idea in general. Yes. In addition, such information should only be needed at initialization time, and since we now have the new v4l2_i2c_new_subdev_cfg function I think that that is the right way to do this. The same approach can be used for setting the gpio pin directions. That too is something you setup at config time. Yup. OK, thanks. Regards, Andy 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
DVICO Fusion Dual Express DVB-T - Australian Channel Problems
I've been working to get my DVICO Fusion Express DVB-T (rev 02) PCIe tv capture card working for a few months now. I've had some success with the [1]http://linuxtv.org/hg/~stoth/v4l-dvb-cx23885 repository on linuxtv.org, managing to get the remote to work and most channels to tune reasonably reliably. Thanks to Steve for the great work on this. Im using the xc3028-v27.fw firmware file and kernel version 2.6.28-13-generic under jaunty. lspci entry is:- 04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02) After some troubleshooting, it seems that channels tune fine after a reload of the module, but otherwise the card will not re-tune to another channel. You can tune once on each of the receivers before they lock out and the module needs to be reloaded. I know my reception is fine because the WinFast DTV1000 in the same machine is rock solid on all channels. # modprobe cx23885 # tzap -a 1 -c channels.conf SC10 Canberra using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' reading channels from file '/home/daniel/.me-tv/channels.conf' tuning to 17750 Hz video pid 0x0161, audio pid 0x0162 status 00 | signal 5d6c | snr | ber | unc | status 1e | signal b844 | snr f5f5 | ber | unc | FE_HAS_LOCK status 1e | signal b834 | snr f5f5 | ber | unc | FE_HAS_LOCK status 1e | signal b834 | snr f5f5 | ber | unc | FE_HAS_LOCK status 1e | signal b840 | snr f5f5 | ber | unc | FE_HAS_LOCK # rmmod cx23885 # modprobe cx23885 # tzap -a 1 -c channels.conf ABC2 using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' reading channels from file '/home/daniel/.me-tv/channels.conf' tuning to 205625000 Hz video pid 0x0903, audio pid 0x0904 status 00 | signal ae00 | snr | ber | unc | status 1e | signal ba80 | snr f8f8 | ber | unc | FE_HAS_LOCK status 1e | signal bad4 | snr f6f6 | ber | unc | FE_HAS_LOCK status 1e | signal bacc | snr f6f6 | ber | unc | FE_HAS_LOCK I noticed on some lists that someone has claimed success with the main v4l-dvb repositorty, but this does not tune at all for me. Daniel C -- http://www.fastmail.fm - Email service worth paying for. Try it for free -- 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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 1:17 AM, George Adamsg_adam...@hotmail.com wrote: Hello! In a last ditch effort, I decided to try downloading a v4l driver snapshot from February back when I had my Pinnacle HD Pro Stick device working. To my amazement, the old drivers worked! By process of elimination (trying newer and newer drivers until my Pinnacle device was once again not recognized), it appears that changeset 11331 (http://linuxtv.org/hg/v4l-dvb/rev/00525b115901), from Mar. 31 2009, is the first one that causes my device to not be recognized. This is the changeset that updated the em28xx driver from 0.1.1 to 0.1.2. Here, again, is the dmesg output from a newer driver that does NOT work (this one from a driver set one day later, on Apr. 1, 2009): Interesting. What distro and version of the kernel are you running? Yesterday Michael Krufky pointed out to me that the v4l subdev registration is broken for the au0828 driver when using the current tip against Ubuntu Hardy (2.6.24), so it now seems likely that it's the exact same issue. Thanks for taking the time to narrow down the actual change that caused the issue. I guess somebody is going to have to build a box with Hardy and debug this issue. :-/ 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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 1:17 AM, George Adamsg_adam...@hotmail.com wrote: Hello! In a last ditch effort, I decided to try downloading a v4l driver snapshot from February back when I had my Pinnacle HD Pro Stick device working. To my amazement, the old drivers worked! By process of elimination (trying newer and newer drivers until my Pinnacle device was once again not recognized), it appears that changeset 11331 (http://linuxtv.org/hg/v4l-dvb/rev/00525b115901), from Mar. 31 2009, is the first one that causes my device to not be recognized. This is the changeset that updated the em28xx driver from 0.1.1 to 0.1.2. Here, again, is the dmesg output from a newer driver that does NOT work (this one from a driver set one day later, on Apr. 1, 2009): Interesting. What distro and version of the kernel are you running? Yesterday Michael Krufky pointed out to me that the v4l subdev registration is broken for the au0828 driver when using the current tip against Ubuntu Hardy (2.6.24), so it now seems likely that it's the exact same issue. Thanks for taking the time to narrow down the actual change that caused the issue. I guess somebody is going to have to build a box with Hardy and debug this issue. :-/ Hmm, I have Hardy on my laptop at work so I can test this tomorrow with my USB stick. It's a Hauppauge HVRsomething, but it does have a tvp5150. So it should be close enough. Regards, Hans 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L: mt9t031 - migration to sub device frame work
From: Muralidharan Karicheri m-kariche...@ti.com
Re-sending making some minor updates in the patch header
This patch migrates mt9t031 driver from SOC Camera interface to
sub device interface. This is sent to get a feedback about the
changes done since I am not sure if some of the functionality
that is removed works okay with SOC Camera bridge driver or
not. Following functions are to be discussed and added as needed:-
1) query bus parameters
2) set bus parameters
3) set crop
I have tested this with vpfe capture driver and I could capture
640x...@17fps and 2048x1...@12fps resolution frames from the sensor.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Reviewed-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/media/video/mt9t031.c | 596 -
1 files changed, 293 insertions(+), 303 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index f72aeb7..0f32ff2 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -13,9 +13,9 @@
#include linux/i2c.h
#include linux/log2.h
+#include media/v4l2-device.h
#include media/v4l2-common.h
#include media/v4l2-chip-ident.h
-#include media/soc_camera.h
/* mt9t031 i2c address 0x5d
* The platform has to define i2c_board_info
@@ -52,33 +52,108 @@
#define MT9T031_VERTICAL_BLANK 25
#define MT9T031_COLUMN_SKIP32
#define MT9T031_ROW_SKIP 20
+#define MT9T031_DEFAULT_WIDTH 640
+#define MT9T031_DEFAULT_HEIGHT 480
#define MT9T031_BUS_PARAM (SOCAM_PCLK_SAMPLE_RISING | \
SOCAM_PCLK_SAMPLE_FALLING | SOCAM_HSYNC_ACTIVE_HIGH | \
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_HIGH | \
SOCAM_MASTER | SOCAM_DATAWIDTH_10)
-static const struct soc_camera_data_format mt9t031_colour_formats[] = {
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-1));
+
+static const struct v4l2_fmtdesc mt9t031_formats[] = {
+ {
+ .index = 0,
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .description = Bayer (sRGB) 10 bit,
+ .pixelformat = V4L2_PIX_FMT_SGRBG10,
+ },
+};
+static const unsigned int mt9t031_num_formats = ARRAY_SIZE(mt9t031_formats);
+
+static const struct v4l2_queryctrl mt9t031_controls[] = {
{
- .name = Bayer (sRGB) 10 bit,
- .depth = 10,
- .fourcc = V4L2_PIX_FMT_SGRBG10,
- .colorspace = V4L2_COLORSPACE_SRGB,
+ .id = V4L2_CID_VFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Vertically,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_HFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Horizontally,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_GAIN,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Gain,
+ .minimum= 0,
+ .maximum= 127,
+ .step = 1,
+ .default_value = 64,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Exposure,
+ .minimum= 1,
+ .maximum= 255,
+ .step = 1,
+ .default_value = 255,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE_AUTO,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Automatic Exposure,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 1,
}
};
+static const unsigned int mt9t031_num_controls = ARRAY_SIZE(mt9t031_controls);
struct mt9t031 {
- struct i2c_client *client;
- struct soc_camera_device icd;
+ struct v4l2_subdev sd;
int model; /* V4L2_IDENT_MT9T031* codes from v4l2-chip-ident.h */
unsigned char autoexposure;
u16 xskip;
u16 yskip;
+ u32 width;
+ u32 height;
+ unsigned short x_min; /* Camera capabilities */
+ unsigned short y_min;
+ unsigned short x_current; /* Current window location */
+ unsigned short y_current;
+
Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 9:43 AM, Hans Verkuilhverk...@xs4all.nl wrote: Hmm, I have Hardy on my laptop at work so I can test this tomorrow with my USB stick. It's a Hauppauge HVRsomething, but it does have a tvp5150. So it should be close enough. Regards, Hans Hans, Oh thank goodness. I was really hoping you would volunteer since you are clearly the best candidate for debugging subdev issues. It took me two days to debug my last issue with v4l2_subdev registration and it required me to recompile the distro's kernel from source to debug the i2c stack. If you've got an em28xx device with the tvp5150, then it's probably an HVR-950, which is almost identical to the Pinnacle 800e. Cheers, 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
Yuan EC372S: dib7000p_i2c_enumeration failed
moikka! I just got USB-ExpressCard converter and tested one of my old sticks. Here is result. Any idea? dib0700: stk7700P2_frontend_attach: dib7000p_i2c_enumeration failed. Cannot continue regards Antti -- http://palosaari.fi/ Jun 25 17:30:56 localhost kernel: usb 1-5: new high speed USB device using ehci_hcd and address 7 Jun 25 17:30:56 localhost kernel: usb 1-5: New USB device found, idVendor=1164, idProduct=1edc Jun 25 17:30:56 localhost kernel: usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jun 25 17:30:56 localhost kernel: usb 1-5: Product: STK7700D Jun 25 17:30:56 localhost kernel: usb 1-5: Manufacturer: YUANRD Jun 25 17:30:56 localhost kernel: usb 1-5: SerialNumber: 01 Jun 25 17:30:56 localhost kernel: usb 1-5: configuration #1 chosen from 1 choice Jun 25 17:30:56 localhost kernel: dib0700: loaded with support for 9 different device-types Jun 25 17:30:56 localhost kernel: dvb-usb: found a 'Yuan EC372S' in cold state, will try to load a firmware Jun 25 17:30:56 localhost kernel: usb 1-5: firmware: requesting dvb-usb-dib0700-1.20.fw Jun 25 17:30:56 localhost kernel: dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' Jun 25 17:30:59 localhost kernel: dib0700: firmware started successfully. Jun 25 17:30:59 localhost kernel: dvb-usb: found a 'Yuan EC372S' in warm state. Jun 25 17:30:59 localhost kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jun 25 17:30:59 localhost kernel: DVB: registering new adapter (Yuan EC372S) Jun 25 17:30:59 localhost kernel: dib0700: stk7700P2_frontend_attach: dib7000p_i2c_enumeration failed. Cannot continue Jun 25 17:30:59 localhost kernel: Jun 25 17:30:59 localhost kernel: dvb-usb: no frontend was attached by 'Yuan EC372S' Jun 25 17:30:59 localhost kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:0b.1/usb1/1-5/input/input9 Jun 25 17:30:59 localhost kernel: dvb-usb: schedule remote query interval to 50 msecs. Jun 25 17:30:59 localhost kernel: dvb-usb: Yuan EC372S successfully initialized and connected. Jun 25 17:30:59 localhost kernel: usbcore: registered new interface driver dvb_usb_dib0700 ^C [r...@localhost ~]# uname -a Linux localhost 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 10:34 AM, George Adamsg_adam...@hotmail.com wrote: Y'all are very kind to help - thank you. I am indeed running Ubuntu Hardy (8.04.2 LTS), kernel on a quad-core Q9550 box. I'll be happy to provide any other system details that may assist. uname -a returns: Linux spurgeon 2.6.24-24-server #1 SMP Wed Apr 15 16:36:01 UTC 2009 i686 GNU/Linux No, if you are running Hardy then we know what the issue is. No further information is required. 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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 10:59 AM, George Adamsg_adam...@hotmail.com wrote: Surely there must be some command-line way to change the Pinnacle device to channel 3 before I launch Helix Producer? v4lctl setchannel 3 Or you might want to consider using the composite or s-video input if that's available to you (the quality will be better). 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Hi, Mauro, I am using the v4l2_i2c_new_subdev_board() API for the next set of vpfe capture driver patches. So when do you think this will be merged? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Saturday, June 20, 2009 9:11 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Hi Mauro, I've posted these changes as an RFC more than a week ago, but since there were no comments I hope you can pull from this tree for 2.6.31. I would really, really like to get this into 2.6.31. It will help anyone who is working with subdevs on embedded platforms. Regards, Hans Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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: [PATCH] adding support for setting bus parameters in sub device
Hi,
Is this ready to get merged or still require discussion before merge?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, June 17, 2009 5:17 PM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Muralidharan Karicheri;
Karicheri, Muralidharan
Subject: [PATCH] adding support for setting bus parameters in sub device
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
This patch adds support for setting bus parameters such as bus type
(Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
etc) in sub device. This allows bridge driver to configure the sub device
bus for a specific set of bus parameters through s_bus() function call.
This also can be used to define platform specific bus parameters for
host and sub-devices.
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..8532b91 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,43 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found */
};
+/*
+ * Some sub-devices are connected to the host/bridge device through a bus
that
+ * carries the clock, vsync, hsync and data. Some interfaces such as
BT.656
+ * carries the sync embedded in the data where as others have separate
line
+ * carrying the sync signals. The structure below is used to define bus
+ * configuration parameters for host as well as sub-device
+ */
+enum v4l2_bus_type {
+ /* Raw YUV image data bus */
+ V4L2_BUS_RAW_YUV,
+ /* Raw Bayer image data bus */
+ V4L2_BUS_RAW_BAYER
+};
+
+struct v4l2_bus_settings {
+ /* yuv or bayer image data bus */
+ enum v4l2_bus_type type;
+ /* subdev bus width */
+ u8 subdev_width;
+ /* host bus width */
+ u8 host_width;
+ /* embedded sync, set this when sync is embedded in the data stream
*/
+ unsigned embedded_sync:1;
+ /* master or slave */
+ unsigned host_is_master:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned edge_pclock:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders
or
sensors and webcam controllers.
@@ -199,6 +236,8 @@ struct v4l2_subdev_audio_ops {
s_routing: see s_routing in audio_ops, except this version is for video
devices.
+
+ s_bus: set bus parameters in sub device to configure the bus
*/
struct v4l2_subdev_video_ops {
int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
config);
@@ -219,6 +258,7 @@ struct v4l2_subdev_video_ops {
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct
v4l2_frmsizeenum *fsize);
int (*enum_frameintervals)(struct v4l2_subdev *sd, struct
v4l2_frmivalenum *fival);
+ int (*s_bus)(struct v4l2_subdev *sd, const struct v4l2_bus_settings
*bus);
};
struct v4l2_subdev_ops {
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Why is the old DVB ML still alive?
Why is the old dvb (linux-dvb) mailing list still alive? One of the arguments migrating all dvb related stuff to this combined ml was to reduce overhead. But in fact some information might be lost now, since not everybody will look at both ML's. Wouldn't it be a good idea to close the old ml now / is this foreseen at all? --Winfried -- 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: Why is the old DVB ML still alive?
On Thu, Jun 25, 2009 at 11:40 AM, wkhandygewinnsp...@gmx.de wrote: Why is the old dvb (linux-dvb) mailing list still alive? One of the arguments migrating all dvb related stuff to this combined ml was to reduce overhead. But in fact some information might be lost now, since not everybody will look at both ML's. Wouldn't it be a good idea to close the old ml now / is this foreseen at all? --Winfried Well, the old linux-dvb list forwards all messages to the new list, so no information is actually lost. However, this does often result in multiple posts with the same content, since the auto-reply message sent back to users posting to linux-dvb often leads them to think the message wasn't delivered. That said, I think enough time has gone by where we can finally just drop the linux-dvb mailing list. 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: [PATCH] mt9t031 - migration to sub device frame work
On Wed, 24 Jun 2009, m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
This patch migrates mt9t031 driver from SOC Camera interface to
sub device interface. This is sent to get a feedback about the
changes done since I am not sure if some of the functionality
that is removed works okay with SOC Camera bridge driver or
not. Following functions are to be discussed and added as needed:-
1) query bus parameters
2) set bus parameters
3) set crop
I have tested this with vpfe capture driver and I could capture
640x...@17fps and 2048x1...@12fps resolution frames from the sensor.
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Excuse me? This is the first time I see this patch. FYI, Reviewed-by
means that the respective person has actually reviewed the patch and
submitted that line _him_ or _her_self!
Thanks
Guennadi
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/media/video/mt9t031.c | 596
-
1 files changed, 293 insertions(+), 303 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index f72aeb7..0f32ff2 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -13,9 +13,9 @@
#include linux/i2c.h
#include linux/log2.h
+#include media/v4l2-device.h
#include media/v4l2-common.h
#include media/v4l2-chip-ident.h
-#include media/soc_camera.h
/* mt9t031 i2c address 0x5d
* The platform has to define i2c_board_info
@@ -52,33 +52,108 @@
#define MT9T031_VERTICAL_BLANK 25
#define MT9T031_COLUMN_SKIP 32
#define MT9T031_ROW_SKIP 20
+#define MT9T031_DEFAULT_WIDTH640
+#define MT9T031_DEFAULT_HEIGHT 480
#define MT9T031_BUS_PARAM(SOCAM_PCLK_SAMPLE_RISING | \
SOCAM_PCLK_SAMPLE_FALLING | SOCAM_HSYNC_ACTIVE_HIGH | \
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_HIGH | \
SOCAM_MASTER | SOCAM_DATAWIDTH_10)
-static const struct soc_camera_data_format mt9t031_colour_formats[] = {
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-1));
+
+static const struct v4l2_fmtdesc mt9t031_formats[] = {
+ {
+ .index = 0,
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .description = Bayer (sRGB) 10 bit,
+ .pixelformat = V4L2_PIX_FMT_SGRBG10,
+ },
+};
+static const unsigned int mt9t031_num_formats = ARRAY_SIZE(mt9t031_formats);
+
+static const struct v4l2_queryctrl mt9t031_controls[] = {
{
- .name = Bayer (sRGB) 10 bit,
- .depth = 10,
- .fourcc = V4L2_PIX_FMT_SGRBG10,
- .colorspace = V4L2_COLORSPACE_SRGB,
+ .id = V4L2_CID_VFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Vertically,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_HFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Horizontally,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_GAIN,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Gain,
+ .minimum= 0,
+ .maximum= 127,
+ .step = 1,
+ .default_value = 64,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Exposure,
+ .minimum= 1,
+ .maximum= 255,
+ .step = 1,
+ .default_value = 255,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE_AUTO,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Automatic Exposure,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 1,
}
};
+static const unsigned int mt9t031_num_controls =
ARRAY_SIZE(mt9t031_controls);
struct mt9t031 {
- struct i2c_client *client;
- struct soc_camera_device icd;
+ struct v4l2_subdev sd;
int model; /* V4L2_IDENT_MT9T031* codes from v4l2-chip-ident.h */
unsigned char autoexposure;
u16 xskip;
u16 yskip;
+ u32 width;
+ u32 height;
+
[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:Thu Jun 25 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12133:05e6c5c9bcb4 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-armv5: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc1-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc1-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc1-x86_64: ERRORS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Hans, I have tried to pull the latest from git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git I can't see it part of this. Which GIT tree can I use to see the sub dev api changes or latest that went into 2.6.31? Is vpfe capture part of 2.6.31? Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Thursday, June 25, 2009 11:18 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 Hi, Mauro, I am using the v4l2_i2c_new_subdev_board() API for the next set of vpfe capture driver patches. So when do you think this will be merged? This has already been merged and is also in the 2.6.31 git tree. I'm very pleased that this is in as that will make life easier for several embedded system developments. Regards, Hans Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Saturday, June 20, 2009 9:11 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Hi Mauro, I've posted these changes as an RFC more than a week ago, but since there were no comments I hope you can pull from this tree for 2.6.31. I would really, really like to get this into 2.6.31. It will help anyone who is working with subdevs on embedded platforms. Regards, Hans Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
Hans, I just spoke with mkrufky, and he confirmed the issue does occur with the HVR-950. However, the em28xx driver does not do a printk() when the subdev registration fails (I will submit a patch to fix that). Please let me know if you have any further question. Thanks for your assistance, 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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 2:25 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: Hans, I just spoke with mkrufky, and he confirmed the issue does occur with the HVR-950. However, the em28xx driver does not do a printk() when the subdev registration fails (I will submit a patch to fix that). Please let me know if you have any further question. Thanks for your assistance, I'd like to add: Testing against 2.6.24.7: v4l subdev registration fails. Testing against 2.6.25.20: v4l subdev registration fails. ... Testing against 2.6.26.8: success! Testing against 2.6.27.25: success! Testing against 2.6.28.10: success! ... (I didn't bother testing 2.6.29.y) Testing against 2.6.30: success! Regards, Mike -- 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] mt9t031 - migration to sub device frame work
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski
Sent: Thursday, June 25, 2009 1:46 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com
Subject: Re: [PATCH] mt9t031 - migration to sub device frame work
On Wed, 24 Jun 2009, m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
This patch migrates mt9t031 driver from SOC Camera interface to
sub device interface. This is sent to get a feedback about the
changes done since I am not sure if some of the functionality
that is removed works okay with SOC Camera bridge driver or
not. Following functions are to be discussed and added as needed:-
1) query bus parameters
2) set bus parameters
3) set crop
I have tested this with vpfe capture driver and I could capture
640x...@17fps and 2048x1...@12fps resolution frames from the sensor.
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Excuse me? This is the first time I see this patch. FYI, Reviewed-by
means that the respective person has actually reviewed the patch and
submitted that line _him_ or _her_self!
Thanks
Guennadi
My mistake. I was assuming that by adding this line, I can get it reviewed by
the mandatory reviewers. Is there a way to provide this information in the
patch description?
Could you please review this patch and give me the comments? I had exchanged
emails with you in the past agreeing to do this migration. I remember you had
accepted the same.
Murali
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/media/video/mt9t031.c | 596 ---
--
1 files changed, 293 insertions(+), 303 deletions(-)
diff --git a/drivers/media/video/mt9t031.c
b/drivers/media/video/mt9t031.c
index f72aeb7..0f32ff2 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -13,9 +13,9 @@
#include linux/i2c.h
#include linux/log2.h
+#include media/v4l2-device.h
#include media/v4l2-common.h
#include media/v4l2-chip-ident.h
-#include media/soc_camera.h
/* mt9t031 i2c address 0x5d
* The platform has to define i2c_board_info
@@ -52,33 +52,108 @@
#define MT9T031_VERTICAL_BLANK 25
#define MT9T031_COLUMN_SKIP 32
#define MT9T031_ROW_SKIP20
+#define MT9T031_DEFAULT_WIDTH 640
+#define MT9T031_DEFAULT_HEIGHT 480
#define MT9T031_BUS_PARAM (SOCAM_PCLK_SAMPLE_RISING | \
SOCAM_PCLK_SAMPLE_FALLING | SOCAM_HSYNC_ACTIVE_HIGH | \
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_HIGH | \
SOCAM_MASTER | SOCAM_DATAWIDTH_10)
-static const struct soc_camera_data_format mt9t031_colour_formats[] = {
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-1));
+
+static const struct v4l2_fmtdesc mt9t031_formats[] = {
+{
+.index = 0,
+.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+.description = Bayer (sRGB) 10 bit,
+.pixelformat = V4L2_PIX_FMT_SGRBG10,
+},
+};
+static const unsigned int mt9t031_num_formats =
ARRAY_SIZE(mt9t031_formats);
+
+static const struct v4l2_queryctrl mt9t031_controls[] = {
{
-.name = Bayer (sRGB) 10 bit,
-.depth = 10,
-.fourcc = V4L2_PIX_FMT_SGRBG10,
-.colorspace = V4L2_COLORSPACE_SRGB,
+.id = V4L2_CID_VFLIP,
+.type = V4L2_CTRL_TYPE_BOOLEAN,
+.name = Flip Vertically,
+.minimum= 0,
+.maximum= 1,
+.step = 1,
+.default_value = 0,
+}, {
+.id = V4L2_CID_HFLIP,
+.type = V4L2_CTRL_TYPE_BOOLEAN,
+.name = Flip Horizontally,
+.minimum= 0,
+.maximum= 1,
+.step = 1,
+.default_value = 0,
+}, {
+.id = V4L2_CID_GAIN,
+.type = V4L2_CTRL_TYPE_INTEGER,
+.name = Gain,
+.minimum= 0,
+.maximum= 127,
+.step = 1,
+.default_value = 64,
+.flags = V4L2_CTRL_FLAG_SLIDER,
+}, {
+.id = V4L2_CID_EXPOSURE,
+.type = V4L2_CTRL_TYPE_INTEGER,
+.name = Exposure,
+.minimum= 1,
+.maximum= 255,
+.step = 1,
+.default_value = 255,
+.flags = V4L2_CTRL_FLAG_SLIDER,
+}, {
+.id = V4L2_CID_EXPOSURE_AUTO,
+.type
Re: Terratec DT USB XS Diversity/DiB0070+vdr: URB status: Value too large for defined data type+USB reset
Hi, after I tried a NEC USB-Controller card now using the same 2.6.30-1 kernel and DVB hardware I can confirm that the problem is the AMD USB controller. Greetings, Marco Patrick Boettcher wrote: Hi Marco, On Tue, 2 Jun 2009, Marco Borm wrote: Definitely interesting. This is a known issue for the dib0700 device, which happens on some USB host controllers. Actually which one do you use? USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller Hmm, looks bad: http://www.google.com/search?q=dib0700+sb700 But I am wondering if this could really be some bigger linux USB-stack problem, because it runs with Linux/totem for hours (mplayer was wrong). For me it looks like vdr uses some feature the driver doesn't handle correctly. Isn't the EOVERFLOW some local error value from the usb stack generates if some given buffer was to small? :(. It is a long story for the SB700 ATI HC ... It turned out for DiBcom that ATI fixed the HC-driver for Windows to make things work correctly. At some point in time they provided a patch for Linux and it was actually included in 2.6.21 or 22 . There is some work going on on 2.6.30 for almost similar problems for another device, maybe it is worth to either: 1) try out latest 2.6.30 releases 2) do a (manual) bisect with older kernel to find out which change has made things worse (this is extremely long) Do you connect the device directly to the PC or is there an extension cable or another USB hub in between? I tried it with a longer and the short cable which was in the package, never directly and never with a hub. Knowing that you have the SB700, I can surely say, it's not the cable, but the controller. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mt9t031 - migration to sub device frame work
(dropped moderated davinci-linux-open-sou...@linux.davincidsp.com davinci-linux-open-sou...@linux.davincidsp.com ) On Thu, 25 Jun 2009, Karicheri, Muralidharan wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski Sent: Thursday, June 25, 2009 1:46 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH] mt9t031 - migration to sub device frame work On Wed, 24 Jun 2009, m-kariche...@ti.com wrote: From: Muralidharan Karicheri m-kariche...@ti.com This patch migrates mt9t031 driver from SOC Camera interface to sub device interface. This is sent to get a feedback about the changes done since I am not sure if some of the functionality that is removed works okay with SOC Camera bridge driver or not. Following functions are to be discussed and added as needed:- 1) query bus parameters 2) set bus parameters 3) set crop I have tested this with vpfe capture driver and I could capture 640x...@17fps and 2048x1...@12fps resolution frames from the sensor. Reviewed by: Hans Verkuil hverk...@xs4all.nl Reviewed by: Guennadi Liakhovetski g.liakhovet...@gmx.de Excuse me? This is the first time I see this patch. FYI, Reviewed-by means that the respective person has actually reviewed the patch and submitted that line _him_ or _her_self! Thanks Guennadi My mistake. I was assuming that by adding this line, I can get it reviewed by the mandatory reviewers. Is there a way to provide this information in the patch description? Yes, it should have been Cc: Potential Reviewer revie...@provider.com and it would be useful to actually also cc those persons. Could you please review this patch and give me the comments? I had exchanged emails with you in the past agreeing to do this migration. I remember you had accepted the same. Sure, I will. Hopefully tomorrow. 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
v4l2_int_device vs v4l2_subdev?
Still trying to wrap my head around the OMAP/34xx camera support. I need to use the TVP5150 sensor/controller, but the existing driver uses v4l_subdev. The working examples I've found (from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device Are these two totally separate beasts? If I have an infrastructure (I assume) based on v4l2_int_device, how do I use a v4l2_subdev device driver? or need I move one to the other? ... dizzy from traveling down too many twisty little passages :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 v2] soc-camera: fix missing clean up on error path
Dear Guennadi Yes, you're right. Please, try this version, but this is a bigger change, also affecting the regular (not error) path, so, I will have to test it too. Thanks. but I'm very busy now. Please wait for me. I tested this patch. And I works well for me !! Thank you Best regards -- Kuninori Morimoto -- 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
Bah! How do I change channels?
Having gotten my Pinnacle HDTV Pro Stick working again under some old v4l drivers, I'm now facing a much more mundane problem - I can't figure out how to use the command line to change the channel. The video feed (a closed-circuit feed) that's coming to the card is over a coax cable, and is on (analog) channel 3. My goal is to take the input and use Helix Encoder to produce RealVideo output that can be played using Real Player (yeah, not the ideal situation, but it's what we're using for now) Helix Producer (unlike mencoder/mplayer) doesn't have the ability to change the channel - it can only take whatever is coming over the channel that the Pinnacle device is currently tuned to. Devin pointed me to the v4lctl command, but I'm not having any luck with it yet. The following does NOT work (i.e. Helix Producer produces a feed of just static) v4lctl setchannel 3 v4lctl setfreqtab us-bcast; v4lctl setnorm NTSC; v4lctl setchannel 3 (I tried all combinations with us-cable and us-cable-hrc for the frequency tables, and NTSC-M for the norm), but nothing worked. But scantv seems to indicate that the channel is there: scantv -n NTSC -f us-bcast -a -c /dev/video0 -C /dev/null scanning freqencies... ?? 44.00 MHz (- ): | no ?? 44.25 MHz (- ): | no ?? 44.50 MHz (- ): | no ... ?? 59.00 MHz (- ): | no ?? 59.25 MHz (- ): | no ?? 59.50 MHz (- ): | no ?? 59.75 MHz (- ): \ raise ?? 60.00 MHz (- ): | yes ?? 60.25 MHz (- ): | yes ?? 60.50 MHz (- ): | yes ?? 60.75 MHz (- ): | yes ?? 61.00 MHz (- ): | yes ?? 61.25 MHz (3 ): | yes ?? 61.50 MHz (- ): | yes ?? 61.75 MHz (- ): | yes ?? 62.00 MHz (- ): | yes ?? 62.25 MHz (- ): / fall = 61.25 MHz (3 ): ??? [unknown (61.25)] channel = 3 ?? 62.50 MHz (- ): | no ?? 62.75 MHz (- ): | no ?? 63.00 MHz (- ): | no ?? 63.25 MHz (- ): | no So, there it is. Is there something wrong with my v4lctl command, then? Interestingly, after running tvtime-scanner, I note this in my ~/.tvtime/stationlist.xml file: It has also spotted channel 3, but this time at 61.50Mhz, rather than 61.25Mhz (which is where I thought it ought to be). So here is what WORKS: - run tvtime, tune to channel 3, quit the program and start Helix Producer. It will see the correct channel and show a nice clear picture. - or, run an mplayer command like the following. When it quits 5 seconds later, start Helix Producer. Again, Helix will show the picture from channel 3: mplayer -vo xv tv:// -tv driver=v4l2:alsa:immediatemode=0:adevice=hw.1,0:norm=ntsc:chanlist=us-cable:channel=3 -endpos 5 So, my horrible hack to get this working is to run the mplayer command before I start Helix Producer. But surely there must be a better way! Can I make v4lctl do the right thing? Or is there another command-line tool that I can use? Thanks again. _ Windows Live™ SkyDrive™: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_SD_25GB_062009-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_int_device vs v4l2_subdev?
Hello, On Fri, Jun 26, 2009 at 7:43 AM, Gary Thomasg...@mlbassoc.com wrote: Still trying to wrap my head around the OMAP/34xx camera support. I need to use the TVP5150 sensor/controller, but the existing driver uses v4l_subdev. The working examples I've found (from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device Are these two totally separate beasts? If I have an infrastructure (I assume) based on v4l2_int_device, how do I use a v4l2_subdev device driver? or need I move one to the other? I've been through the same case (now I'm trying to use subdev framework and writing a new device driver based on that) As far as I understand, every v4l2 drivers are moving on subdev framework. But in user space there is nothing changed having access to device and control them. As you know, subdev and int-device is all about how to bind interface(or host?) and device and make them communicated each other. But using subdev device driver with int-device supporting interface (or host) device driver? it won't make any communication. So if you are running out of time with your project, you'd better use old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if you have enough time and wanna be challenging, try to convert in-device based omap3 camera interface driver to subdev supporting one. Cheers, Nate ... dizzy from traveling down too many twisty little passages :-( -- Gary Thomas | Consulting for the MLB Associates | Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
