[PATCH] soc-camera: ov772x: Modify buswidth control
This patch remove buswidth struct member,
and it expect that default buswidth is 10 bit.
You can select 8 bit buswidth by new flag.
This patch also modify ap325rxa/migor setup.c
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
This patch is v2 of
soc-camera: ov772x: Add buswidth selection flags for platform
v1 - v2
o remove 10BIT flag
o white space - tab on ov772x_camera_info
o ov772x_query_bus_param return is not changed
arch/sh/boards/mach-ap325rxa/setup.c |4 ++--
arch/sh/boards/mach-migor/setup.c|2 +-
drivers/media/video/ov772x.c | 22 +++---
include/media/ov772x.h | 10 +-
4 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/arch/sh/boards/mach-ap325rxa/setup.c
b/arch/sh/boards/mach-ap325rxa/setup.c
index 1f5fa5c..71f556f 100644
--- a/arch/sh/boards/mach-ap325rxa/setup.c
+++ b/arch/sh/boards/mach-ap325rxa/setup.c
@@ -471,8 +471,8 @@ static struct i2c_board_info ap325rxa_i2c_camera[] = {
};
static struct ov772x_camera_info ov7725_info = {
- .buswidth = SOCAM_DATAWIDTH_8,
- .flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP,
+ .flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP | \
+ OV772X_FLAG_8BIT,
.edgectrl = OV772X_AUTO_EDGECTRL(0xf, 0),
};
diff --git a/arch/sh/boards/mach-migor/setup.c
b/arch/sh/boards/mach-migor/setup.c
index 507c77b..9b4676f 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -431,7 +431,7 @@ static struct i2c_board_info migor_i2c_camera[] = {
};
static struct ov772x_camera_info ov7725_info = {
- .buswidth = SOCAM_DATAWIDTH_8,
+ .flags = OV772X_FLAG_8BIT,
};
static struct soc_camera_link ov7725_link = {
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 3a45e94..7f8ece3 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -547,7 +547,6 @@ static const struct v4l2_queryctrl ov772x_controls[] = {
},
};
-
/*
* general function
*/
@@ -634,7 +633,12 @@ static unsigned long ov772x_query_bus_param(struct
soc_camera_device *icd)
struct soc_camera_link *icl = to_soc_camera_link(icd);
unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH | priv-info-buswidth;
+ SOCAM_DATA_ACTIVE_HIGH;
+
+ if (priv-info-flags OV772X_FLAG_8BIT)
+ flags |= SOCAM_DATAWIDTH_8;
+ else
+ flags |= SOCAM_DATAWIDTH_10;
return soc_camera_apply_sensor_flags(icl, flags);
}
@@ -1040,15 +1044,6 @@ static int ov772x_video_probe(struct soc_camera_device
*icd,
return -ENODEV;
/*
-* ov772x only use 8 or 10 bit bus width
-*/
- if (SOCAM_DATAWIDTH_10 != priv-info-buswidth
- SOCAM_DATAWIDTH_8 != priv-info-buswidth) {
- dev_err(client-dev, bus width error\n);
- return -ENODEV;
- }
-
- /*
* check and show product ID and manufacturer ID
*/
pid = i2c_smbus_read_byte_data(client, PID);
@@ -1130,7 +1125,6 @@ static int ov772x_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
struct ov772x_priv*priv;
- struct ov772x_camera_info *info;
struct soc_camera_device *icd = client-dev.platform_data;
struct i2c_adapter*adapter = to_i2c_adapter(client-dev.parent);
struct soc_camera_link*icl;
@@ -1145,8 +1139,6 @@ static int ov772x_probe(struct i2c_client *client,
if (!icl || !icl-priv)
return -EINVAL;
- info = icl-priv;
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
dev_err(adapter-dev,
I2C-Adapter doesn't support
@@ -1158,7 +1150,7 @@ static int ov772x_probe(struct i2c_client *client,
if (!priv)
return -ENOMEM;
- priv-info = info;
+ priv-info = icl-priv;
v4l2_i2c_subdev_init(priv-subdev, client, ov772x_subdev_ops);
diff --git a/include/media/ov772x.h b/include/media/ov772x.h
index 14c77ef..548bf11 100644
--- a/include/media/ov772x.h
+++ b/include/media/ov772x.h
@@ -15,8 +15,9 @@
#include media/soc_camera.h
/* for flags */
-#define OV772X_FLAG_VFLIP 0x0001 /* Vertical flip image */
-#define OV772X_FLAG_HFLIP 0x0002 /* Horizontal flip image */
+#define OV772X_FLAG_VFLIP (1 0) /* Vertical flip image */
+#define OV772X_FLAG_HFLIP (1 1) /* Horizontal flip image */
+#define OV772X_FLAG_8BIT (1 2) /* default 10 bit */
/*
* for Edge ctrl
@@ -53,9 +54,8 @@ struct ov772x_edge_ctrl {
* ov772x camera info
*/
struct ov772x_camera_info {
- unsigned long buswidth;
- unsigned long flags;
-
How to change fps on soc-camera ?
Hi all Now I have mt9t112 / ov772x soc-camera. And it can change fps by register setting. So, I would like to add such support to driver. But I don't know how to order it from user program. Can you please teach me about it ? # in my easy search, using ioctrl with VIDIOC_S_PARM # seems good, I'm not sure though 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
Re: Call for Testers - dib0700 IR improvements
Hi, Thanks for working on improving the Nova T 500 performance, it is much appreciated, and let me know if you need further help with debugging it. I tried your dib0700-ir tree. My problems with the Nova T 500 and the 1.20 firmware have been warm reboots. Before your patch a warm reboot would give I2C errors in dmesg log with the 1.20 FW, hence I have only used my machine with cold boots since my upgrade this xmas. With the 1.10 FW and Ubuntu 7.04 + v4l tip sometime in 2008 the system have run without much problems including frequent warm reboots for 2 years. Sorry to say this patch does not solve the problem to have a working IR after a warm reboot see dmesg logs below. I have not seen any problems with high load before, so can't give any info on that matter more than it is certainly low now. The I2C errors I saw before your patch come shortly after a warm reboot (see last dmesg log included), but have not had any problems after cold boots for the past week the system have been recording. I run on: Linux hgu 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009 i686 GNU/Linux Motherboard: ABIT IL-90MV 945GT Mobile S478 HDMI mATX CPU: Intel Core 2 Duo Mobile T5600 1.83GHz 2M DVB-T cards: Hauppauge WinTV Nova-T 500 DVB-T Twinhan VisionPlus DVB-T In a bad reception area (the Twinhan can't acceptably receive all the channels the Hauppauge can) /Harald dmesg logs: Warm reboot (after ubuntu 9.10 2.6.31-16 standard modules) got non-working remote but working video [8.282314] dib0700: loaded with support for 14 different device-types [8.282568] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. [8.282615] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [8.282798] DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) [8.311479] DVB: registering new adapter (bttv0) [8.396083] DVB: registering adapter 0 frontend 0 (DiBcom 3000MC/P)... [8.509562] usbcore: registered new interface driver snd-usb-audio [8.578470] MT2060: successfully identified (IF1 = 1228) [9.107028] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [9.107285] DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) [9.113153] DVB: registering adapter 2 frontend 0 (DiBcom 3000MC/P)... [9.119744] MT2060: successfully identified (IF1 = 1235) [9.490288] dst(0) dst_get_device_id: Recognise [DTTDIG] [9.490294] DST type flags : 0x10 firmware version = 2 [9.531093] dst(0) dst_get_mac: MAC Address=[00:08:ca:30:10:39] [9.531103] DVB: registering adapter 1 frontend 0 (DST DVB-T)... [9.684982] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1e.0/:03:06.2/usb2/2-1/input/input6 [9.685059] dvb-usb: schedule remote query interval to 50 msecs. [9.685066] dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. [9.685327] dib0700: rc submit urb failed Cold boot (directly after the previous) got working remote and video [ 19.445048] dib0700: loaded with support for 14 different device-types [ 19.445747] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware [ 19.445754] usb 2-1: firmware: requesting dvb-usb-dib0700-1.20.fw [ 19.498041] usbcore: registered new interface driver snd-usb-audio [ 19.508086] HDA Intel :00:1b.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 19.508115] HDA Intel :00:1b.0: setting latency timer to 64 [ 19.547850] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [ 19.586410] hda_codec: Unknown model for ALC882, trying auto-probe from BIOS... [ 19.586598] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input5 [ 19.699301] dst(0) dst_get_device_id: Recognise [DTTDIG] [ 19.699310] DST type flags : 0x10 firmware version = 2 [ 19.741032] dst(0) dst_get_mac: MAC Address=[00:08:ca:30:10:39] [ 19.741042] DVB: registering adapter 0 frontend 0 (DST DVB-T)... [ 19.848324] e1000e :02:00.0: irq 26 for MSI/MSI-X [ 19.904203] e1000e :02:00.0: irq 26 for MSI/MSI-X [ 19.904842] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 19.917288] dib0700: firmware started successfully. [ 19.945541] kjournald starting. Commit interval 5 seconds [ 19.946387] EXT3 FS on sda1, internal journal [ 19.946397] EXT3-fs: mounted filesystem with writeback data mode. [ 20.019719] __ratelimit: 9 callbacks suppressed [ 20.019723] type=1505 audit(1262768018.239:14): operation=profile_replace pid=1011 name=/usr/share/gdm/guest-session/Xsession [ 20.021747] type=1505 audit(1262768018.243:15): operation=profile_replace pid=1013 name=/sbin/dhclient3 [ 20.022550] type=1505 audit(1262768018.243:16): operation=profile_replace pid=1013 name=/usr/lib/NetworkManager/nm-dhcp-client.action [ 20.022984] type=1505 audit(1262768018.243:17): operation=profile_replace pid=1013 name=/usr/lib/connman/scripts/dhclient-script [
Re: Call for Testers - dib0700 IR improvements
On Wed, Jan 6, 2010 at 5:00 AM, Harald Gustafsson hgu1...@gmail.com wrote: Hi, Thanks for working on improving the Nova T 500 performance, it is much appreciated, and let me know if you need further help with debugging it. I tried your dib0700-ir tree. My problems with the Nova T 500 and the 1.20 firmware have been warm reboots. Before your patch a warm reboot would give I2C errors in dmesg log with the 1.20 FW, hence I have only used my machine with cold boots since my upgrade this xmas. With the 1.10 FW and Ubuntu 7.04 + v4l tip sometime in 2008 the system have run without much problems including frequent warm reboots for 2 years. Sorry to say this patch does not solve the problem to have a working IR after a warm reboot see dmesg logs below. I have not seen any problems with high load before, so can't give any info on that matter more than it is certainly low now. The I2C errors I saw before your patch come shortly after a warm reboot (see last dmesg log included), but have not had any problems after cold boots for the past week the system have been recording. Hi Harald, Thanks for taking the time to test and provide feedback. Just to be clear, this patch does *not* address the warm reboot problem. I am continuing to work that issue, but there should be no expectation that this patch allows the device to survive a warm reboot. It should address concerns people were seeing where the system load would be between 0.50 and 1.0 just by having the device connected, and *may* help in cases where you start to see mt2060 errors after several hours of operation. 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
Re: IR device at I2C address 0x7a
Hi Darek, Adding LMML to Cc. On Wed, 23 Dec 2009 18:10:08 +0100, Daro wrote: I have the problem you described at the mailing list with Asus MyCinema-P7131/P/FM/AV/RC Analog TV Card: IR remote control is not detected and i2c-adapter i2c-3: Invalid 7-bit address 0x7a error occurs. lspci gives the following output: 04:00.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) dmesg output I enclose in the attachment. I use: Linux DOMOWY 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux I would be gratefull for the help on that. (...) subsystem: 1043:4845, board: ASUS TV-FM 7135 [card=53,autodetected] (...) i2c-adapter i2c-3: Invalid 7-bit address 0x7a saa7133[0]: P7131 analog only, using entry of ASUSTeK P7131 Analog This error message will show on virtually every SAA713x-based board with no known IR setup. It doesn't imply your board has any I2C device at address 0x7a. So chances are that the message is harmless and you can simply ignore it. -- Jean Delvare -- 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: IR device at I2C address 0x7a:
Hi Felix, On Thu, 31 Dec 2009 08:18:51 +0100, Felix Wolfsteller wrote: Sorry to bump into you by mail directly. Feel free to redirect me to other channels and/or quote me. Adding LMML to Cc. My tv card (asus digimatrix, card=62, tuner=66; i think) might exhibit the issue you discussed and apparently patched (http://osdir.com/ml/linux-media/2009-10/msg00078.html). At least I am getting the same error message as quoted. For more or less extensive hardware details, see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/481449 For the dmesg output containing the adress 0x7a line, see latest comments on that bug. I hope I can help and get helped ;) This error message will show on virtually every SAA713x-based board with no known IR setup. It doesn't imply your board has any I2C device at address 0x7a. So chances are that the message is harmless and you can simply ignore it. -- Jean Delvare -- 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 - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
CLK(NULL, rto, rto_clk),
CLK(NULL, usb, usb_clk),
+CLK(dm355_ccdc, master, vpss_master_clk),
+CLK(dm355_ccdc, slave, vpss_slave_clk),
I still don't understand why you have to add new entries here and
can't simply rename the existing CLK nodes using vpss_*_clk.
[MK] This will allow multiple drivers define their own clocks derived from
these. ccdc driver is not the only driver using these clocks. Your earlier
suggestion was to use as follows :-
- CLK(NULL, vpss_master, vpss_master_clk),
- CLK(NULL, vpss_slave, vpss_slave_clk),
+ CLK(vpfe-capture, master, vpss_master_clk),
+ CLK(vpfe-capture, slave, vpss_slave_clk),
I am not sure if the following will work so that it can be used across
multiple drivers.
+ CLK(NULL, master, vpss_master_clk),
+ CLK(NULL, slave, vpss_slave_clk),
If yes, I can re-do this patch. Please confirm.
Same comment for dm644x.c changes.
Kevin
CLK(NULL, NULL, NULL),
};
@@ -665,6 +667,17 @@ static struct platform_device dm355_asp1_device = {
.resource = dm355_asp1_resources,
};
+static void dm355_ccdc_setup_pinmux(void)
+{
+davinci_cfg_reg(DM355_VIN_PCLK);
+davinci_cfg_reg(DM355_VIN_CAM_WEN);
+davinci_cfg_reg(DM355_VIN_CAM_VD);
+davinci_cfg_reg(DM355_VIN_CAM_HD);
+davinci_cfg_reg(DM355_VIN_YIN_EN);
+davinci_cfg_reg(DM355_VIN_CINL_EN);
+davinci_cfg_reg(DM355_VIN_CINH_EN);
+}
+
static struct resource dm355_vpss_resources[] = {
{
/* VPSS BL Base address */
@@ -701,6 +714,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
@@ -708,8 +725,18 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
};
+static struct platform_device dm355_ccdc_dev = {
+.name = dm355_ccdc,
+.id = -1,
+.num_resources = ARRAY_SIZE(dm355_ccdc_resource),
+.resource = dm355_ccdc_resource,
+.dev = {
+.dma_mask = vpfe_capture_dma_mask,
+.coherent_dma_mask = DMA_BIT_MASK(32),
+.platform_data = dm355_ccdc_setup_pinmux,
+},
+};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -860,17 +887,7 @@ static int __init dm355_init_devices(void)
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(dm355_edma_device);
platform_device_register(dm355_vpss_device);
-/*
- * setup Mux configuration for vpfe input and register
- * vpfe capture platform device
- */
-davinci_cfg_reg(DM355_VIN_PCLK);
-davinci_cfg_reg(DM355_VIN_CAM_WEN);
-davinci_cfg_reg(DM355_VIN_CAM_VD);
-davinci_cfg_reg(DM355_VIN_CAM_HD);
-davinci_cfg_reg(DM355_VIN_YIN_EN);
-davinci_cfg_reg(DM355_VIN_CINL_EN);
-davinci_cfg_reg(DM355_VIN_CINH_EN);
+platform_device_register(dm355_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
davinci/dm644x.c
index e65e29e..e5f1ee9 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -315,6 +315,8 @@ struct davinci_clk dm644x_clks[] = {
CLK(NULL, timer0, timer0_clk),
CLK(NULL, timer1, timer1_clk),
CLK(watchdog, NULL, timer2_clk),
+CLK(dm644x_ccdc, master, vpss_master_clk),
+CLK(dm644x_ccdc, slave, vpss_slave_clk),
CLK(NULL, NULL, NULL),
};
@@ -612,6 +614,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+/* CCDC Base address */
{
.start = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +626,17 @@ static struct resource vpfe_resources[] = {
},
};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+.name = dm644x_ccdc,
+.id = -1,
+.num_resources = ARRAY_SIZE(dm644x_ccdc_resource),
+.resource = dm644x_ccdc_resource,
+.dev = {
+.dma_mask = vpfe_capture_dma_mask,
+.coherent_dma_mask = DMA_BIT_MASK(32),
+},
+};
+
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -772,6 +789,7 @@ static int __init dm644x_init_devices(void)
Re: em28xx: New device request and tvp5150 distortion issues when capturing from vcr
On Tue, Jan 5, 2010 at 3:40 AM, Michael Rüttgers i...@michael-ruettgers.de wrote: Hello, a year ago I bought a device named Hama Video Editor, which was not (and is not yet) supported by the em28xx driver. So I played around with the card parameter and got the device basically working with card=38. Basically working means, that I had a distortion when capturing old VHS-Tapes from my old vcr. The problem can be seen here: http://www.michael-ruettgers.de/em28xx/test.avi A few weeks ago I started tracking down the reason for this issue with the help of Devin. Wondering, that the device works perfectly in Windows, I compared the i2c commands, that programmed the register of the tvp5150 in Windows. Finally I got the device working properly, setting the TV/VCR option in the register Operation Mode Controls Register at address 02h manually to Automatic mode determined by the internal detection circuit. (default): 000109: OUT: 00 ms 107025 ms 40 02 00 00 b8 00 02 00 02 00 After programming this register, the distortion issue disappeared. So my conclusion was, that the TV/VCR detection mode is forced to TV-mode in the em28xx, which could have been verified by a look into the debug output using the parameter reg_debug=1: OUT: 40 02 00 00 b8 00 02 00 02 30 Bit 4, 5 are used for setting the TV/VCR mode: Description in the Spec: TV/VCR mode 00 = Automatic mode determined by the internal detection circuit. (default) 01 = Reserved 10 = VCR (nonstandard video) mode 11 = TV (standard video) mode With automatic detection enabled, unstable or nonstandard syncs on the input video forces the detector into the VCR mode. This turns off the comb filters and turns on the chroma trap filter. Thus far the tvp5150 distortion issues when capturing from vcr. Mauro, I have been working with Michael on this issue and I did some research into the history of this issue, and it seems like you introduced code in rev 2900 which turns off the auto mode and forces the tvp5150 into TV mode if using a composite input: http://linuxtv.org/hg/v4l-dvb/rev/e6c585a76c77 Could you provide any information on the rationale for this decision? I would think that having it in auto mode would be the appropriate default (which is what the Windows driver does), and then you would force it to either TV or VCR mode only if absolutely necessary. The comb filter only gets disabled if the auto mode actually concludes the device should be in VCR mode. Hence, there shouldn't be any downside to having it in auto mode unless you have some reason to believe the detection code is faulty or error-prone. We can add a modprobe option to allow the user to force it into one mode or the other, if someone finds a case where the detection logic has issues. But forcing it into one particular mode by default doesn't seem like the right approach. 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 - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Karicheri, Muralidharan m-kariche...@ti.com writes: CLK(NULL, rto, rto_clk), CLK(NULL, usb, usb_clk), + CLK(dm355_ccdc, master, vpss_master_clk), + CLK(dm355_ccdc, slave, vpss_slave_clk), I still don't understand why you have to add new entries here and can't simply rename the existing CLK nodes using vpss_*_clk. [MK] This will allow multiple drivers define their own clocks derived from these. ccdc driver is not the only driver using these clocks. OK, but that still doesn't answer why you need multiple CLK() nodes. Who else is using the clocks? Your earlier suggestion was to use as follows :- - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(vpfe-capture, master, vpss_master_clk), + CLK(vpfe-capture, slave, vpss_slave_clk), I am not sure if the following will work so that it can be used across multiple drivers. + CLK(NULL, master, vpss_master_clk), + CLK(NULL, slave, vpss_slave_clk), If yes, I can re-do this patch. Please confirm. No, this will not work. You need a dev_id field so that matching is done using the struct device. My original suggestion was when you had the VPFE driver doing the clk_get(). Now that it's in CCDC, maybe it should look like this. - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(ccdc, master, vpss_master_clk), + CLK(ccdc, slave, vpss_slave_clk), Kevin -- 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 - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
display, resizer drivers etc... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, January 06, 2010 11:04 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: CLK(NULL, rto, rto_clk), CLK(NULL, usb, usb_clk), + CLK(dm355_ccdc, master, vpss_master_clk), + CLK(dm355_ccdc, slave, vpss_slave_clk), I still don't understand why you have to add new entries here and can't simply rename the existing CLK nodes using vpss_*_clk. [MK] This will allow multiple drivers define their own clocks derived from these. ccdc driver is not the only driver using these clocks. OK, but that still doesn't answer why you need multiple CLK() nodes. Who else is using the clocks? Your earlier suggestion was to use as follows :- -CLK(NULL, vpss_master, vpss_master_clk), -CLK(NULL, vpss_slave, vpss_slave_clk), +CLK(vpfe-capture, master, vpss_master_clk), +CLK(vpfe-capture, slave, vpss_slave_clk), I am not sure if the following will work so that it can be used across multiple drivers. +CLK(NULL, master, vpss_master_clk), +CLK(NULL, slave, vpss_slave_clk), If yes, I can re-do this patch. Please confirm. No, this will not work. You need a dev_id field so that matching is done using the struct device. My original suggestion was when you had the VPFE driver doing the clk_get(). Now that it's in CCDC, maybe it should look like this. - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(ccdc, master, vpss_master_clk), + CLK(ccdc, slave, vpss_slave_clk), Kevin -- 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 - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
In the future, please do not top-post. Inline replies are preferred so context can be followed. I've moved your reply into context below with some more comments... Karicheri, Muralidharan m-kariche...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, January 06, 2010 11:04 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: CLK(NULL, rto, rto_clk), CLK(NULL, usb, usb_clk), + CLK(dm355_ccdc, master, vpss_master_clk), + CLK(dm355_ccdc, slave, vpss_slave_clk), I still don't understand why you have to add new entries here and can't simply rename the existing CLK nodes using vpss_*_clk. [MK] This will allow multiple drivers define their own clocks derived from these. ccdc driver is not the only driver using these clocks. OK, but that still doesn't answer why you need multiple CLK() nodes. Who else is using the clocks? display, resizer drivers etc... OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? I thought the point of moving the clocks into the CCDC driver was so that the clock management was done in a single, shared space. Kevin Your earlier suggestion was to use as follows :- - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(vpfe-capture, master, vpss_master_clk), + CLK(vpfe-capture, slave, vpss_slave_clk), I am not sure if the following will work so that it can be used across multiple drivers. + CLK(NULL, master, vpss_master_clk), + CLK(NULL, slave, vpss_slave_clk), If yes, I can re-do this patch. Please confirm. No, this will not work. You need a dev_id field so that matching is done using the struct device. My original suggestion was when you had the VPFE driver doing the clk_get(). Now that it's in CCDC, maybe it should look like this. - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(ccdc, master, vpss_master_clk), + CLK(ccdc, slave, vpss_slave_clk), Kevin -- 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] media: video/tuner-core, fix memory leak
On 01/06/2010 05:47 PM, Jiri Slaby wrote: Stanse found a memory leak in tuner_probe. t is not freed/assigned on all paths. Fix that. Oops. I generated two patches here, only the second is for PCI. Sorry Mauro, you got this one twice. -- js -- 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] media: dvb/siano, fix memory leak
Stanse found a memory leak in smscore_gpio_configure. buffer is not
freed/assigned on all paths. Fix that.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/siano/smscoreapi.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/siano/smscoreapi.c
b/drivers/media/dvb/siano/smscoreapi.c
index ca758bc..4bfd345 100644
--- a/drivers/media/dvb/siano/smscoreapi.c
+++ b/drivers/media/dvb/siano/smscoreapi.c
@@ -1459,8 +1459,10 @@ int smscore_gpio_configure(struct smscore_device_t
*coredev, u8 PinNum,
if (!(coredev-device_flags SMS_DEVICE_FAMILY2)) {
pMsg-xMsgHeader.msgType = MSG_SMS_GPIO_CONFIG_REQ;
if (GetGpioPinParams(PinNum, TranslatedPinNum, GroupNum,
- groupCfg) != 0)
- return -EINVAL;
+ groupCfg) != 0) {
+ rc = -EINVAL;
+ goto free;
+ }
pMsg-msgData[1] = TranslatedPinNum;
pMsg-msgData[2] = GroupNum;
@@ -1490,6 +1492,7 @@ int smscore_gpio_configure(struct smscore_device_t
*coredev, u8 PinNum,
else
sms_err(smscore_gpio_configure error);
}
+free:
kfree(buffer);
return rc;
--
1.6.5.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] media: video/tuner-core, fix memory leak
Stanse found a memory leak in tuner_probe. t is not freed/assigned on all paths. Fix that. Signed-off-by: Jiri Slaby jsl...@suse.cz Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org --- drivers/media/video/tuner-core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index 5b3eaa1..c4dab6c 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1078,6 +1078,7 @@ static int tuner_probe(struct i2c_client *client, goto register_client; } + kfree(t); return -ENODEV; case 0x42: case 0x43: -- 1.6.5.7 -- 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] media: video/tuner-core, fix memory leak
Stanse found a memory leak in tuner_probe. t is not freed/assigned on all paths. Fix that. Signed-off-by: Jiri Slaby jsl...@suse.cz Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org --- drivers/media/video/tuner-core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index 5b3eaa1..c4dab6c 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1078,6 +1078,7 @@ static int tuner_probe(struct i2c_client *client, goto register_client; } + kfree(t); return -ENODEV; case 0x42: case 0x43: -- 1.6.5.7 -- 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: av7110 error reporting
Oliver Endriss wrote: Hi, Johan wrote: I need some guidance on error messages.. T [ 7678.312025] dvb-ttpci: StartHWFilter error buf 0b07 0010 0803 b96a ret 0 handle These start as soon as I view or record a channel, and obviously fills up the log quickly. I believe the code that generates these messages is at the bottom of this message (part of av7110.c). This code was introduced in 2005 to improve error reporting. True. Currently I run today's v4l-dvb (using a hg update), and kernel 2.6.31-16. (Ubuntu), however the issue occurred in older combinations as well (over a year ago), so it is not introduced by the last kernels or DVB driverset. The message seems to be triggered by the variable handle being larger then 32. On my system it always reports . Handle == means that the av7110 was not able to create a new filter entry. This will happen if there are already 32 active filters. Does it happen for all channels, or only for a specific one? If the latter is true: Which channel is causing the problem? Does it have a large number of audio pids? Am I looking at faulty hardware, or can I resolve this issue more elegant than just disabling the fault report? (keep in mind that I do not have a programming/coding background) You may disable the warning, but be warned that some parts of the data will not be recorded due to missing filter entries... Oliver Think I know why this is happening. Using Mplayer I see that dvb-ttpci is used by about 4-5 processes. No errors. Using mythtv 0.22 lsmod reports dvb-ttpci being used by 31 processes. Errors. My idea is that mythtv's multirec feature is causing this, even though I have not enabled any virtual tuner. My card, an unmodified Nexus-s (from 1998) may not support multirec due to its hardware design. (took me quite a bit of googling to make this assumption). So, if my assumption is correct, the error is with Mythtv, where it is assumed that my card is multirec capable. (and how would Mythtv know, since the driver is the same ?) I have now bought an HVR4000, so I have time to mod the Nexus. (and dig out my reading glasses to find the pins) Johan -- 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: IR device at I2C address 0x7a
Hi Jean, Thank you for your answer. It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? Thanks for your help in advance. Best regards Darek W dniu 06.01.2010 15:39, Jean Delvare pisze: Hi Darek, Adding LMML to Cc. On Wed, 23 Dec 2009 18:10:08 +0100, Daro wrote: I have the problem you described at the mailing list with Asus MyCinema-P7131/P/FM/AV/RC Analog TV Card: IR remote control is not detected and i2c-adapter i2c-3: Invalid 7-bit address 0x7a error occurs. lspci gives the following output: 04:00.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) dmesg output I enclose in the attachment. I use: Linux DOMOWY 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux I would be gratefull for the help on that. (...) subsystem: 1043:4845, board: ASUS TV-FM 7135 [card=53,autodetected] (...) i2c-adapter i2c-3: Invalid 7-bit address 0x7a saa7133[0]: P7131 analog only, using entry of ASUSTeK P7131 Analog This error message will show on virtually every SAA713x-based board with no known IR setup. It doesn't imply your board has any I2C device at address 0x7a. So chances are that the message is harmless and you can simply ignore it. -- 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: IR device at I2C address 0x7a
W dniu 06.01.2010 19:40, Jean Delvare pisze: On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote: It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? Did it ever work on Linux? I have no experience on that. I bought this card just few weeks ago and tried it only on Karmic Koala. -- 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: OK
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:Wed Jan 6 19:00:02 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13879:b6b82258cf5e gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: ERRORS linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: ERRORS linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: ERRORS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK 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: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: Fwd: Compro S300 - ZL10313
2010/1/2 JD Louw jd.l...@mweb.co.za: On Sat, 2010-01-02 at 09:39 +0200, Theunis Potgieter wrote: 2010/1/1 JD Louw jd.l...@mweb.co.za: On Tue, 2009-12-29 at 23:23 +0200, Theunis Potgieter wrote: Hi mailing list, I have a problem with my Compro S300 pci card under Linux 2.6.32. I cannot tune with this card and STR/SNRA is very bad compared to my Technisat SkyStar 2 pci card, connected to the same dish. I have this card and are willing to run tests, tested drivers etc to make this work. I currently load the module saa7134 with options: card=169 I enabled some debug parameters on the saa7134, not sure what else I should enable. Please find my dmesg log attached. lsmod shows : # lsmod Module Size Used by zl10039 6268 2 mt312 12048 2 saa7134_dvb 41549 11 saa7134 195664 1 saa7134_dvb nfsd 416819 11 videobuf_dvb 8187 1 saa7134_dvb dvb_core 148140 1 videobuf_dvb ir_common 40625 1 saa7134 v4l2_common 21544 1 saa7134 videodev 58341 2 saa7134,v4l2_common v4l1_compat 24473 1 videodev videobuf_dma_sg 17830 2 saa7134_dvb,saa7134 videobuf_core 26534 3 saa7134,videobuf_dvb,videobuf_dma_sg tveeprom 12550 1 saa7134 thermal 20547 0 processor 54638 1 # uname -a Linux vbox 2.6.32-gentoo #4 Sat Dec 19 00:54:19 SAST 2009 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux Thanks, Theunis Hi, It's probably the GPIO settings that are wrong for your SAA7133 based card revision. See http://osdir.com/ml/linux-media/2009-06/msg01256.html for an explanation. For quick confirmation check if you have 12V - 20V DC going to your LNB. The relevant lines of code is in ~/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c: case SAA7134_BOARD_VIDEOMATE_S350: dev-has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000); break; Hi thanks for the hint. I changed it to the following: case SAA7134_BOARD_VIDEOMATE_S350: dev-has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 2, 0xc000, 0xc000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0xc000, 0xc000); break; I now get the same SNR as on my skystar2 card, signal is still indicating 17% where as the skystar2 would show 68%. At least I'm getting a LOCK on channels :) Thanks! Looking at your log, at least the demodulator and tuner is responding correctly. You can see this by looking at the i2c traffic addressed to 0x1c (demodulator) and 0xc0 (tuner). Attached is a dmesg trace from my working SAA7130 based card. Regards JD Hi, Just to clarify, can you now watch channels? At the moment the signal strength measurement is a bit whacked, so don't worry too much about it. I also get the 75%/17% figures you mentioned when tuning to strong signals. The figure is simply reported wrongly: even weaker signals should tune fine. If you want you can have a look in ~/v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c at mt312_read_signal_strength(). Also, if you have a multimeter handy, can you confirm that the 0xc000 GPIO fix enables LNB voltage? I'd like to issue a patch for this. I've already tested this on my older card with no ill effect. This is what happened when I started vdr. Vertical gave a Volt reading between 13.9 and 14.1, Horizontal Gave 19.4 ~ 19.5. When I stopped vdr, the Voltage went back to 14V. I thought that it would read 0V. What is suppose to happen? Theunis Regards JD -- 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: IR device at I2C address 0x7a
On Wed, 06 Jan 2010 20:10:30 +0100, Daro wrote: W dniu 06.01.2010 19:40, Jean Delvare pisze: On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote: It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? Did it ever work on Linux? I have no experience on that. I bought this card just few weeks ago and tried it only on Karmic Koala. OK. You could try loading the saa7134 driver with option card=146 and see if it helps. -- Jean Delvare -- 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: Call for Testers - dib0700 IR improvements
Hello, On Wed, 2010-01-06 at 09:36 -0500, Devin Heitmueller wrote: Just to be clear, this patch does *not* address the warm reboot problem. I am continuing to work that issue, but there should be no expectation that this patch allows the device to survive a warm reboot. That one would be cool. It should address concerns people were seeing where the system load would be between 0.50 and 1.0 just by having the device connected, and *may* help in cases where you start to see mt2060 errors after several hours of operation. hmmm... 32 days uptime, no mt2060 error from my NovaT500, outside of a failed read at startup. regarding the load, I'm not sure I am experiencing it, or it is shadowed by MythTV's frontend idling at 15% cpu... I'll stop the frontend during the night and look at the load in the morning. I may be able to provide a graph from munin, as I have multiple recordings, some concurrent, of the kids shows in the morning. If I have the load thing, I'll test the patch, otherwise I'll keep the WAF, and KAF, as I would not be a proper guinea pig anyway. Nico -- 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: IR Receiver on an Tevii S470
Andy Walls awalls at radix.net writes: please try again when you have time. # modprobe cx25840 debug=2 ir_debug=2 # modprobe cx23885 debug=7 I tried to activate my remote using the driver in http://linuxtv.org/hg/~awalls/cx23885-ir. According to the following dmesg output everything is loaded correctly and the ir interface is registered as /dev/input/event5: [9.220413] Linux video capture interface: v2.00 [9.432581] cx23885 driver version 0.0.2 loaded [9.433560] ACPI: PCI Interrupt Link [LN0A] enabled at IRQ 19 [9.433572] alloc irq_desc for 19 on node -1 [9.433577] alloc kstat_irqs on node -1 [9.433594] cx23885 :02:00.0: PCI INT A - Link[LN0A] - GSI 19 (level, low) - IRQ 19 [9.433746] CORE cx23885[0]: subsystem: d470:9022, board: TeVii S470 [card=15,autodetected] [9.720071] cx25840 3-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) [9.728397] cx25840 3-0044: firmware: requesting v4l-cx23885-avcore-01.fw [9.994115] HDA Intel :00:08.0: power state changed by ACPI to D0 [9.995038] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 22 [9.995055] HDA Intel :00:08.0: PCI INT A - Link[LAZA] - GSI 22 (level, low) - IRQ 22 [9.995139] HDA Intel :00:08.0: setting latency timer to 64 [ 10.579145] cx25840 3-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 10.586817] cx23885_dvb_register() allocating 1 frontend(s) [ 10.586830] cx23885[0]: cx23885 based dvb card [ 10.593034] hda_codec: Unknown model for ALC662 rev1, trying auto-probe from BIOS... [ 10.790592] DS3000 chip version: 0.192 attached. [ 10.790604] DVB: registering new adapter (cx23885[0]) [ 10.790613] DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)... [ 10.791219] cx23885_dev_checkrevision() Hardware revision = 0xb0 [ 10.791236] cx23885[0]/0: found at :02:00.0, rev: 2, irq: 19, latency: 0, mmio: 0xfac0 [ 10.791249] cx23885 :02:00.0: setting latency timer to 64 [ 10.791258] IRQ 19/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 10.795358] input: cx23885 IR (TeVii S470) as /devices/pci:00/:00:0c.0/:02:00.0/input/input5 But there is no signal comming from input/event5, regardless of the tools trying to access it (lircd, irw, mode2, inputlircd, plain cat, etc.). What else is needed to activate the remote with this driver? If I enable debug messages by modprobe cx25840 debug=2 ir_debug=2 modprobe cx23885 debug=7 the dmesg/syslog is flooded with: [ 75.932848] cx23885[0]/0: [f47e4840/9] wakeup reg=9514 buf=9514 [ 75.937811] cx23885[0]/0: pci_status: 0x8002 pci_mask: 0x08001f02 [ 75.937839] cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0 [ 75.937847] cx23885[0]/0: ts1_status: 0x0001 ts1_mask: 0x count: 0x252b [ 75.937856] cx23885[0]/0: ts2_status: 0x ts2_mask: 0x count: 0x2ca4d364 [ 75.937881] cx23885[0]/0: (PCI_MSK_VID_B 0x0002) [ 75.937902] cx23885[0]/0: (RISCI10x0001) [ 75.937918] cx23885[0]/0: [f47e4000/10] wakeup reg=9515 buf=9515 [ 75.937942] cx23885[0]/0: queue is not empty - append to active [ 75.937964] cx23885[0]/0: [f47e4840/9] cx23885_buf_queue - append to active [ 75.938064] cx23885[0]/0: queue is not empty - append to active [ 75.938087] cx23885[0]/0: [f47e4000/10] cx23885_buf_queue - append to active [ 75.942878] cx23885[0]/0: pci_status: 0x8002 pci_mask: 0x08001f02 [ 75.942901] cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0 [ 75.942908] cx23885[0]/0: ts1_status: 0x0001 ts1_mask: 0x count: 0x252c [ 75.942917] cx23885[0]/0: ts2_status: 0x ts2_mask: 0x count: 0x2ca4d364 [ 75.942943] cx23885[0]/0: (PCI_MSK_VID_B 0x0002) [ 75.942949] cx23885[0]/0: (RISCI10x0001) [ 75.942961] cx23885[0]/0: [f47e4480/11] wakeup reg=9516 buf=9516 [ 75.943101] cx23885[0]/0: queue is not empty - append to active [ 75.943112] cx23885[0]/0: [f47e4480/11] cx23885_buf_queue - append to active ... Any advice where to go from here, what to try? Thank you. Andreas -- 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: IR Receiver on an Tevii S470
On Wed, 2010-01-06 at 21:21 +, Andreas Tschirpke wrote: Andy Walls awalls at radix.net writes: please try again when you have time. # modprobe cx25840 debug=2 ir_debug=2 # modprobe cx23885 debug=7 I tried to activate my remote using the driver in http://linuxtv.org/hg/~awalls/cx23885-ir. According to the following dmesg output everything is loaded correctly and the ir interface is registered as /dev/input/event5: [9.220413] Linux video capture interface: v2.00 [9.432581] cx23885 driver version 0.0.2 loaded [9.433560] ACPI: PCI Interrupt Link [LN0A] enabled at IRQ 19 [9.433572] alloc irq_desc for 19 on node -1 [9.433577] alloc kstat_irqs on node -1 [9.433594] cx23885 :02:00.0: PCI INT A - Link[LN0A] - GSI 19 (level, low) - IRQ 19 [9.433746] CORE cx23885[0]: subsystem: d470:9022, board: TeVii S470 [card=15,autodetected] [9.720071] cx25840 3-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) [9.728397] cx25840 3-0044: firmware: requesting v4l-cx23885-avcore-01.fw [9.994115] HDA Intel :00:08.0: power state changed by ACPI to D0 [9.995038] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 22 [9.995055] HDA Intel :00:08.0: PCI INT A - Link[LAZA] - GSI 22 (level, low) - IRQ 22 [9.995139] HDA Intel :00:08.0: setting latency timer to 64 [ 10.579145] cx25840 3-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 10.586817] cx23885_dvb_register() allocating 1 frontend(s) [ 10.586830] cx23885[0]: cx23885 based dvb card [ 10.593034] hda_codec: Unknown model for ALC662 rev1, trying auto-probe from BIOS... [ 10.790592] DS3000 chip version: 0.192 attached. [ 10.790604] DVB: registering new adapter (cx23885[0]) [ 10.790613] DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)... [ 10.791219] cx23885_dev_checkrevision() Hardware revision = 0xb0 [ 10.791236] cx23885[0]/0: found at :02:00.0, rev: 2, irq: 19, latency: 0, mmio: 0xfac0 [ 10.791249] cx23885 :02:00.0: setting latency timer to 64 [ 10.791258] IRQ 19/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 10.795358] input: cx23885 IR (TeVii S470) as /devices/pci:00/:00:0c.0/:02:00.0/input/input5 But there is no signal comming from input/event5, regardless of the tools trying to access it (lircd, irw, mode2, inputlircd, plain cat, etc.). What else is needed to activate the remote with this driver? I admire your initiaive, however, that code is not working yet. The problem is getting AV core IR interrupts from the CX23885 without getting a constant stream of AV core interrupts that are not realted to IR. I just received a loaner HVR-1250 with a CX23885 from Devin a few days ago. It doesn't have the external IR hardware, but it has enough on-chip for me to debug my interrupt problem using the IR loopback. Once I have the interrupt problem solved, I'll ask Igor, you, and whomever else to test. Life is busy right now. I might not get to looking at it until Sunday. Regards, Andy If I enable debug messages by modprobe cx25840 debug=2 ir_debug=2 modprobe cx23885 debug=7 the dmesg/syslog is flooded with: [ 75.932848] cx23885[0]/0: [f47e4840/9] wakeup reg=9514 buf=9514 [ 75.937811] cx23885[0]/0: pci_status: 0x8002 pci_mask: 0x08001f02 [ 75.937839] cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0 [ 75.937847] cx23885[0]/0: ts1_status: 0x0001 ts1_mask: 0x count: 0x252b [ 75.937856] cx23885[0]/0: ts2_status: 0x ts2_mask: 0x count: 0x2ca4d364 [ 75.937881] cx23885[0]/0: (PCI_MSK_VID_B 0x0002) [ 75.937902] cx23885[0]/0: (RISCI10x0001) [ 75.937918] cx23885[0]/0: [f47e4000/10] wakeup reg=9515 buf=9515 [ 75.937942] cx23885[0]/0: queue is not empty - append to active [ 75.937964] cx23885[0]/0: [f47e4840/9] cx23885_buf_queue - append to active [ 75.938064] cx23885[0]/0: queue is not empty - append to active [ 75.938087] cx23885[0]/0: [f47e4000/10] cx23885_buf_queue - append to active [ 75.942878] cx23885[0]/0: pci_status: 0x8002 pci_mask: 0x08001f02 [ 75.942901] cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0 [ 75.942908] cx23885[0]/0: ts1_status: 0x0001 ts1_mask: 0x count: 0x252c [ 75.942917] cx23885[0]/0: ts2_status: 0x ts2_mask: 0x count: 0x2ca4d364 [ 75.942943] cx23885[0]/0: (PCI_MSK_VID_B 0x0002) [ 75.942949] cx23885[0]/0: (RISCI10x0001) [ 75.942961] cx23885[0]/0: [f47e4480/11] wakeup reg=9516 buf=9516 [ 75.943101] cx23885[0]/0: queue is not empty - append to active [ 75.943112] cx23885[0]/0: [f47e4480/11] cx23885_buf_queue - append to active ... Any advice where to go from here, what to try? Thank you. Andreas -- To unsubscribe from this list: send the line
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote: On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote: On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote: Mauro, I've split the revert2.diff that I sent you previously to fix the tuning regression on my DViCO Dual Digital 4 (rev 1) into three separate patches that will hopefully allow you to review more easily. The first two patches revert their respective changesets and nothing else, fixing the issue for me. 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz The third patch does what I believe is the obvious equivalent fix to e6a8672631a0 but without the cleanup that breaks tuning on my card. Please review and merge Signed-off-by: Robert Lowery rglow...@exemail.com.au Mauro, I'm yet to receive a response from you on this clear regression introduced in the 2.6.31 kernel. You attention would be appreciated Thanks -Rob Robert, The changes in question (mostly authored by me) are based on documentation on what offsets are to be used with the firmware for various DVB bandwidths and demodulators. The change was tested by Terry on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and some other cards I can't remember, using a DVB-T pattern generator for 7 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz. (Devin, Maybe you can double check on the offsets in tuner-xc2028.c with any documentation you have available to you?) I haven't been following this thread really at all as the board in the subject line was unfamiliar to me, so sorry for any late response or dumb questions by me. May I ask: 1. what are the exact problem frequencies? 2. what is the data source from which you are getting the frequency information? 3. what does tuner-xc2028 debug logging show as the firmware loaded when tune to one of the the problem frequencies? Robert, I just found that ACMA has a very nice compilation licensed DTV transmitters in Australia and their frequencies. Have a look at the Excel spreadsheet linked on this page: http://acma.gov.au/WEB/STANDARD/pc=PC_9150 The DTV tab has a list of the Area, callsign, and DTV center freq. The Glossary tab mentions that DTV broadcasters can have an offset of +/- 125 kHz from the DTV center freq. If you could verify that the frequencies you are using for the problem stations match the list, that would help eliminate commanded tuning frequency as source of the problem. Andy, I don't think this issue is frequency, it is the removal of the 500kHz offset. OK. I forgot there were two offsets at play here: one for the RF frequency and one for the SCODE/Intermediate Frequency. Right, the S-CODE offsets are somewhat of a mystery to me as I don't exactly know the mathematical basis behind them. The 500 kHz came from the best interpretation Maruo and I could make at the time, but it could very well be the wrong thing. (I was guessing it came from a relation something like this: 8 MHz - 7 MHz / 2 = 500 kHz) If it is the wrong thing, and it looks like it could be, we can back it out. As my colleauge, who used to work at CERN, says Experiment trumps theory ... *every* time. Terry had positive results, you and Vincent have negative results. So I'd like to see what Devin finds, if he can test with a DVB-T generator. The channel with the biggest problem (most stuttering) is Channel 8 in Melbourne, which looks correct at 191.625 MHz on the above site. OK. Vincent must have been the one with all the Sydney stations. DTV Channel GTV8 (Fc = 191.625 MHz at 50 kW) for Melbourne is interesting; it comes from the same towers as the adjacent analog channels HSV7 (Fr = 182.25 MHz @ 200 kW) and GTV9 (Fr = 196.25 MHz @ 200 kW). I guess if anything is off center when setting up the XC3028, the analog stations may show up as strong noise - a situation that would not be obvious with a single channel DVB-T signal generator. GTV8 is probably a good channel for you to use for testing. (BTW, given that the analog channel of where GTV8 now resides would have been Fr = 189.25 MHz, I would have expected GTV8 to really be operating at Fc = Fr + 2.25 MHz = 191.50 MHz and not 191.625 MHz) With debug enabled on the the current hg tip (stuttering case) we have divisor= 00 00 2f 58 (freq=191.625) With the patch reverted (working case) divisor= 00 00 2f 38 (freq=191.625) Have you reviewed my patch. It leaves your original DTV6 fix in place, but reverts the cleanup which broke the offset calculation for me. I don't have a copy in my email archives, I'll have to go check for them on the list archives. Regards, Andy -Rob Regards, Andy BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c: cxusb_dvico_xc3028_tuner_attach(), this
[PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Mauro, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: Fix the rates definition and move some buffer freeing code. cx18: address possible passing of NULL to snd_card_free cx18-alsa: codingstyle cleanup cx18-alsa: codingstyle cleanup cx18: codingstyle fixes cx18-alsa: codingstyle fixes cx18-alsa: fix codingstyle issue cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files This includes the codingstyle fixes Mauro reported as well as the changes Takashi Iwai suggested for the ALSA config and buffer handling. 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: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote: On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote: On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote: Mauro, I've split the revert2.diff that I sent you previously to fix the tuning regression on my DViCO Dual Digital 4 (rev 1) into three separate patches that will hopefully allow you to review more easily. The first two patches revert their respective changesets and nothing else, fixing the issue for me. 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz The third patch does what I believe is the obvious equivalent fix to e6a8672631a0 but without the cleanup that breaks tuning on my card. Please review and merge Signed-off-by: Robert Lowery rglow...@exemail.com.au Mauro, I'm yet to receive a response from you on this clear regression introduced in the 2.6.31 kernel. You attention would be appreciated Thanks -Rob Robert, The changes in question (mostly authored by me) are based on documentation on what offsets are to be used with the firmware for various DVB bandwidths and demodulators. The change was tested by Terry on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and some other cards I can't remember, using a DVB-T pattern generator for 7 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz. (Devin, Maybe you can double check on the offsets in tuner-xc2028.c with any documentation you have available to you?) I haven't been following this thread really at all as the board in the subject line was unfamiliar to me, so sorry for any late response or dumb questions by me. May I ask: 1. what are the exact problem frequencies? 2. what is the data source from which you are getting the frequency information? 3. what does tuner-xc2028 debug logging show as the firmware loaded when tune to one of the the problem frequencies? Robert, I just found that ACMA has a very nice compilation licensed DTV transmitters in Australia and their frequencies. Have a look at the Excel spreadsheet linked on this page: http://acma.gov.au/WEB/STANDARD/pc=PC_9150 The DTV tab has a list of the Area, callsign, and DTV center freq. The Glossary tab mentions that DTV broadcasters can have an offset of +/- 125 kHz from the DTV center freq. If you could verify that the frequencies you are using for the problem stations match the list, that would help eliminate commanded tuning frequency as source of the problem. Andy, I don't think this issue is frequency, it is the removal of the 500kHz offset. OK. I forgot there were two offsets at play here: one for the RF frequency and one for the SCODE/Intermediate Frequency. Right, the S-CODE offsets are somewhat of a mystery to me as I don't exactly know the mathematical basis behind them. The 500 kHz came from the best interpretation Maruo and I could make at the time, but it could very well be the wrong thing. (I was guessing it came from a relation something like this: 8 MHz - 7 MHz / 2 = 500 kHz) If it is the wrong thing, and it looks like it could be, we can back it out. As my colleauge, who used to work at CERN, says Experiment trumps theory ... *every* time. Terry had positive results, you and Vincent have negative results. So I'd like to see what Devin finds, if he can test with a DVB-T generator. Andy, Resend of my proposed patches attached. My hypothesis is that 02_revert_e6a8672631a0.diff was really meant to just change the ATSC test to DTV6 but at the same time a cleanup that was done inadvertently removed the 500kHz offset subtraction for DTV7 introducing the defect. 01_revert_966ce12c444d.diff partially fixed this regression for Terry, but not for me or Vincent. I'm having trouble convincing Mauro of this though :), so I would appreciate it if Terry could test my patch set and confirm it is ok for him. So in short, my 01 and 02 patches attached revert the changes that break tuning for me and 03 re-implements the DTV6 fix, but without the cleanup which breaks me. Please review and comment -Rob The channel with the biggest problem (most stuttering) is Channel 8 in Melbourne, which looks correct at 191.625 MHz on the above site. OK. Vincent must have been the one with all the Sydney stations. DTV Channel GTV8 (Fc = 191.625 MHz at 50 kW) for Melbourne is interesting; it comes from the same towers as the adjacent analog channels HSV7 (Fr = 182.25 MHz @ 200 kW) and GTV9 (Fr = 196.25 MHz @ 200 kW). I guess if anything is off center when setting up the XC3028, the analog stations may show up as strong noise - a situation that would not be obvious with a single channel DVB-T signal generator. GTV8 is probably a good channel for you to use for testing. (BTW, given that the analog channel of
