TeVii S660 continuity errors
Is anyone else having continuity problems with the S660? causing rare glitching on SD content, and glitching on HD content very often. Turning on the `disable_rc_polling' parameter for the dvb_usb module seems to help, but it's hard to tell for sure. Turning on the `dvb_demux_tscheck' parameter for the dvb_core module shows continuity counter errors every few seconds in the syslog, along with a peculiar callback ratelimit line before each set of continuity counter errors. Interestingly, the `expected' value is one away from the `got' value, doubtful it's just by chance? Here is a sample from the syslog: [51302.316543] TEI detected. PID=0x1c79 data1=0xfc [51302.316547] TS packet counter mismatch. PID=0x1c79 expected 0xd got 0xc [51302.316550] TEI detected. PID=0x7b6 data1=0xa7 [51302.316552] TS packet counter mismatch. PID=0x7b6 expected 0x2 got 0x8 [51302.316555] TEI detected. PID=0x1e4 data1=0xe1 [51302.316558] TEI detected. PID=0x1324 data1=0xd3 [51302.316561] TS packet counter mismatch. PID=0x1324 expected 0xb got 0x0 [51302.316564] TS packet counter mismatch. PID=0x1c2c expected 0x0 got 0xf [51302.316567] TS packet counter mismatch. PID=0x1f09 expected 0xc got 0xe [51307.329040] __ratelimit: 397 callbacks suppressed [51307.329044] TS packet counter mismatch. PID=0xfaf expected 0x1 got 0x0 [51307.339404] TS packet counter mismatch. PID=0x3fe expected 0x7 got 0x6 [51307.362671] TS packet counter mismatch. PID=0xfaf expected 0x1 got 0x0 [51307.367882] TS packet counter mismatch. PID=0x3fd expected 0x4 got 0x3 The bitrate is about 40 or 50Mbps, depending on what transponder is tuned. This is reported by the dvbcore driver in the syslog when the `dvb_demux_speedcheck' parameter is turned on. I've also experienced input lag, the computer locking up for a second or few, seemed to be during tuning. This seems similar to something that was reported by someone on this list in the past. Disabling RC polling seems to have helped with that. I'm using hts-tvheadend, and it reports continuity errors sometimes as well (though not as often as the driver does in the syslog). The frontend is XBMC on another computer, connected via wired ethernet. The S660 is connected directly via USB to a MacbookPro (Nvidia MCP79 chipset). The computer is running Debian sid 32bit (2.6.32-5-686) with s2-liplianin from yesterday, and the firmware from the 100315_Beta_linux_tevii_ds3000.rar drivers from tevii.com. I've also tried running with the drivers from that rar, to no avail. Everything works well (no glitching) in Windows 7 x64 with the `DVB-HD 2020100830.rar' drivers from tevii.com Is this some sort of timing issue? an issue with the USB bus being overloaded? (I've tried removing most of the usb modules, including ohci_hcd, hid, etc). How can I troubleshoot which driver is at fault? Is this a firmware issue? Can new firmware be extracted from the 20100830 Windows driver? How? Any help/suggestions appreciated. 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: Bug in HVR1300. Found part of a patch, if reverted
Hi there in the latest kernel (and all those since when the patch was written) this patch is still required for the HVR-1300 to work, any chance of it getting incorporated? thanks Mike Hi list, there seems to be a bug in cx88 (HVR1300) that is responsible for not switching channels, and not being able to scan. Complete description can be found on launchpad: https://bugs.launchpad.net/mythtv/+bug/439163 (starting from comment #16) Anyway, i digged it down to this patch: http://www.mail-archive.com/linuxtv-commits@xxx/msg02195.html When reverting the following part of the patch it starts working again: snip-- diff -r 576096447a45 -r d2eedb425718 linux/drivers/media/video/cx88/cx88-dvb.c - --- a/linux/drivers/media/video/cx88/cx88-dvb.c Thu Dec 18 07:28:18 2008 - -0200 +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Thu Dec 18 07:28:35 2008 - -0200 @@ -1135,40 +1135,44 @@ static int cx8802_dvb_advise_acquire(str * on the bus. Take the bus from the cx23416 and enable the * cx22702 demod */ - - cx_set(MO_GP0_IO, 0x0080); /* cx22702 out of reset and enable */ + /* Toggle reset on cx22702 leaving i2c active */ + cx_set(MO_GP0_IO, 0x0080); + udelay(1000); + cx_clear(MO_GP0_IO, 0x0080); + udelay(50); + cx_set(MO_GP0_IO, 0x0080); + udelay(1000); + /* enable the cx22702 pins */ cx_clear(MO_GP0_IO, 0x0004); udelay(1000); break; - -snip Regards Frank Sagurna -- 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: Post DSO scan file for Aberdare
On Thu, 2010-04-29 at 19:48 +0200, Christoph Pfister wrote: 2010/3/9 Mike m...@redtux.org.uk: Please see attached scan file for uk-Aberdare if anyone finds it useful Hmm, I'm not sure whether you're the guy who also sent this (different) update: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17569.html Can you enlighten me please? Thanks, Christoph Yep the first file was for DSO stage 1 , and the second was for full switchover. Here Switchover was Part 1 3/3/2010 Part 2 31/3/2010 Obviously now full switchover has taken place the first file is u/s as is is the old scan file -- 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
gst-launch and locking of dvb adapter
Hi does anyone know if it is possible to use gst-launch to record two dvb streams simultaneously with dvbsrc I am trying a pipeline such as gst-launch dvbsrc pids=6881:6882 ! filesink location=ds9a.ps but I keep getting problems with freeing pipeline I know dvbstreamer can do it so it should be possible somehow any hints appreciated -- 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: DVB TS to DVD? Part 2
On Mon, 2010-03-08 at 20:04 +0200, Juhana Sadeharju wrote: I have not got any replies. Considering that in Finland the main Digital TV recording format is DVB TS and that DVD uses VOBs, I find it hard to believe that nobody knows how to convert between them. I kind of expected that GNU/Linux has a DVD burner which has button burn this video to DVD, but I could not find such a thing. Neither I could not find a video editor which can edit DVB TS files. I use head/tail/split now. Instead, the geek stuff is pouring from every corner. Here is my best attempt so far: 1. ffmpeg -i test.ts -vcodec copy -acodec copy test.vob 2. copy a commercial DVD to /tmp/dvd/ 3. overwrite test.vob to vts_01_1.vob (byte-to-byte overwrite because test.vob is smaller) 4. growisofs -speed=4 -dvd-compat -Z /dev/dvd -udf -dvd-video /tmp/dvd Problems: -First try with ffmpeg made a poor quality vob, and much smaller; every option adds to geek-meter! -ffmpeg with copy made vob which works poorly in Xine; skip forward/backward does not work -ffmpeg with copy made vob which works very poorly in LG DVD player: video skips, has noisy dropouts in audio, and eventually freezes I don't think the problem is in the way how I made the DVD, because Xine can play the commercial vobs well, but not the vob made by ffmpeg. I tested movie-to-dvd as well, but it wanted to convert the audio to WAV first. Stopped the test to that point. WAV conversion should not be necessary. I also tested other DVD burners but it looks like they could not make the required UDF disc. Check! Juhana try my app http://sourceforge.net/projects/burn360/ should do what you want -- 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
Issue with dvbsnoop
Hi I have been using dvbsnoop for quite a while to get an epg. However it has jjust started hanging when I give a -n value of more than about 300 command dvbsnoop -s sec -timeout 500-nph -n 1500 0x12 This gets run via a loop which tunes to each available frequency in turn so I dont neccessarily care if each iteration completes as long as it exits. Any way to stop the hang as I need to get more packets than 300 to get a sensible epg 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
Post DSO scan file for Aberdare
Please see attached scan file for uk-Aberdare if anyone finds it useful # UK, Aberdare # Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html # and http://www.ofcom.org.uk/static/reception_advice/index.asp.html # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 489833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE T 497833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE T 513833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE T 538167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE T 562167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE T 570167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
Re: [PATCH 2/2] media: video: pvrusb2: remove custom hex_to_bin()
Andy:
Acked-By: Mike Isely is...@pobox.com
-Mike
On Tue, 27 Jul 2010, Andy Shevchenko wrote:
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
Cc: Mike Isely is...@pobox.com
---
drivers/media/video/pvrusb2/pvrusb2-debugifc.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
b/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
index e9b11e1..4279ebb 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
@@ -94,8 +94,6 @@ static int debugifc_parse_unsigned_number(const char
*buf,unsigned int count,
u32 *num_ptr)
{
u32 result = 0;
- u32 val;
- int ch;
int radix = 10;
if ((count = 2) (buf[0] == '0')
((buf[1] == 'x') || (buf[1] == 'X'))) {
@@ -107,17 +105,9 @@ static int debugifc_parse_unsigned_number(const char
*buf,unsigned int count,
}
while (count--) {
- ch = *buf++;
- if ((ch = '0') (ch = '9')) {
- val = ch - '0';
- } else if ((ch = 'a') (ch = 'f')) {
- val = ch - 'a' + 10;
- } else if ((ch = 'A') (ch = 'F')) {
- val = ch - 'A' + 10;
- } else {
+ int val = hex_to_bin(*buf++);
+ if (val 0 || val = radix)
return -EINVAL;
- }
- if (val = radix) return -EINVAL;
result *= radix;
result += val;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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] V4L/DVB: pvrusb2: remove unneeded NULL checks
Based on the surrounding code (the unconditional dereference), I agree
that this particular bit of coding paranoia is not doing much good.
Acked-by: Mike Isely is...@pobox.com
On Thu, 19 Aug 2010, Dan Carpenter wrote:
We dereference maskptr unconditionally at the start of the function
and also inside the call to parse_tlist() towards the end of the
function. This function is called from store_val_any() and it always
passes a non-NULL pointer.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
b/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
index 1b992b8..55ea914 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-ctrl.c
@@ -513,7 +513,7 @@ int pvr2_ctrl_sym_to_value(struct pvr2_ctrl *cptr,
if (ret = 0) {
ret = pvr2_ctrl_range_check(cptr,*valptr);
}
- if (maskptr) *maskptr = ~0;
+ *maskptr = ~0;
} else if (cptr-info-type == pvr2_ctl_bool) {
ret = parse_token(ptr,len,valptr,boolNames,
ARRAY_SIZE(boolNames));
@@ -522,7 +522,7 @@ int pvr2_ctrl_sym_to_value(struct pvr2_ctrl *cptr,
} else if (ret == 0) {
*valptr = (*valptr 1) ? !0 : 0;
}
- if (maskptr) *maskptr = 1;
+ *maskptr = 1;
} else if (cptr-info-type == pvr2_ctl_enum) {
ret = parse_token(
ptr,len,valptr,
@@ -531,7 +531,7 @@ int pvr2_ctrl_sym_to_value(struct pvr2_ctrl *cptr,
if (ret = 0) {
ret = pvr2_ctrl_range_check(cptr,*valptr);
}
- if (maskptr) *maskptr = ~0;
+ *maskptr = ~0;
} else if (cptr-info-type == pvr2_ctl_bitmask) {
ret = parse_tlist(
ptr,len,maskptr,valptr,
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] [Patch] Correct Signal Strength values for STB0899
On Thu, 9 Sep 2010 03:51:06 you wrote: thx Goga and thx to dimka_9 for his great work. I hope those guys will include it in the driver regards Newsy --- Goga777 goga...@bk.ru schrieb am Mi, 8.9.2010: Von: Goga777 goga...@bk.ru Betreff: Re: [linux-dvb] [Patch] Correct Signal Strength values for STB0899 An: linux-...@linuxtv.org CC: linux-media@vger.kernel.org Datum: Mittwoch, 8. September, 2010 19:47 Uhr first of all I have to say that this patch is not from me. It's from rotor-0.1.4mh-v1.2.tar.gz Thx to the author of that patch and the modified rotor Plugin. I think he's a friend of Mike Booth I think it should be included into s2-liplianin. With this patch all dvb-s and dvb-s2 signal strength values are scaled correctly. FYI - this patch from Russian DVB VDR forum. Author is dimka_9 http://linuxdvb.org.ru/wbb/index.php?page=ThreadpostID=11883#post11883 Goga ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html We ( Mark and I) have been using dmka_9s patch for some months now haviong included it in rotor. It works fine here and should be include inthe driver. PS has anyone been able to fix BER and UNC? Refard 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 16/16] v4l: Remove module_name argument to the v4l2_i2c_new_subdev* functions
For just the pvrusb2 part of the patch series below
Acked-By: Mike Isely is...@pobox.com
On Fri, 24 Sep 2010, Laurent Pinchart wrote:
The argument isn't used anymore by the functions, remote it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/radio/radio-si4713.c|2 +-
drivers/media/video/au0828/au0828-cards.c |4 ++--
drivers/media/video/bt8xx/bttv-cards.c| 22 +++---
drivers/media/video/cafe_ccic.c |2 +-
drivers/media/video/cx18/cx18-i2c.c |8
drivers/media/video/cx231xx/cx231xx-cards.c |4 ++--
drivers/media/video/cx23885/cx23885-cards.c |2 +-
drivers/media/video/cx23885/cx23885-video.c |4 ++--
drivers/media/video/cx88/cx88-cards.c |9 -
drivers/media/video/cx88/cx88-video.c |7 +++
drivers/media/video/davinci/vpfe_capture.c|1 -
drivers/media/video/davinci/vpif_capture.c|1 -
drivers/media/video/davinci/vpif_display.c|2 +-
drivers/media/video/em28xx/em28xx-cards.c | 18 +-
drivers/media/video/fsl-viu.c |2 +-
drivers/media/video/ivtv/ivtv-i2c.c | 22 +-
drivers/media/video/mxb.c | 12 ++--
drivers/media/video/pvrusb2/pvrusb2-hdw.c |6 ++
drivers/media/video/saa7134/saa7134-cards.c |8
drivers/media/video/saa7134/saa7134-core.c|4 ++--
drivers/media/video/sh_vou.c |2 +-
drivers/media/video/soc_camera.c |2 +-
drivers/media/video/usbvision/usbvision-i2c.c |6 +++---
drivers/media/video/v4l2-common.c | 15 +--
drivers/media/video/vino.c|4 ++--
drivers/media/video/zoran/zoran_card.c|5 ++---
drivers/staging/go7007/go7007-driver.c|2 +-
drivers/staging/tm6000/tm6000-cards.c |4 ++--
include/media/v4l2-common.h | 16 ++--
29 files changed, 88 insertions(+), 108 deletions(-)
diff --git a/drivers/media/radio/radio-si4713.c
b/drivers/media/radio/radio-si4713.c
index 045b10f..d49c215 100644
--- a/drivers/media/radio/radio-si4713.c
+++ b/drivers/media/radio/radio-si4713.c
@@ -291,7 +291,7 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
goto unregister_v4l2_dev;
}
- sd = v4l2_i2c_new_subdev_board(rsdev-v4l2_dev, adapter, NULL,
+ sd = v4l2_i2c_new_subdev_board(rsdev-v4l2_dev, adapter,
pdata-subdev_board_info, NULL);
if (!sd) {
dev_err(pdev-dev, Cannot get v4l2 subdevice\n);
diff --git a/drivers/media/video/au0828/au0828-cards.c
b/drivers/media/video/au0828/au0828-cards.c
index 0453816..01be89f 100644
--- a/drivers/media/video/au0828/au0828-cards.c
+++ b/drivers/media/video/au0828/au0828-cards.c
@@ -212,7 +212,7 @@ void au0828_card_setup(struct au0828_dev *dev)
be abstracted out if we ever need to support a different
demod) */
sd = v4l2_i2c_new_subdev(dev-v4l2_dev, dev-i2c_adap,
- NULL, au8522, 0x8e 1, NULL);
+ au8522, 0x8e 1, NULL);
if (sd == NULL)
printk(KERN_ERR analog subdev registration failed\n);
}
@@ -221,7 +221,7 @@ void au0828_card_setup(struct au0828_dev *dev)
if (dev-board.tuner_type != TUNER_ABSENT) {
/* Load the tuner module, which does the attach */
sd = v4l2_i2c_new_subdev(dev-v4l2_dev, dev-i2c_adap,
- NULL, tuner, dev-board.tuner_addr, NULL);
+ tuner, dev-board.tuner_addr, NULL);
if (sd == NULL)
printk(KERN_ERR tuner subdev registration fail\n);
diff --git a/drivers/media/video/bt8xx/bttv-cards.c
b/drivers/media/video/bt8xx/bttv-cards.c
index 87d8b00..49efcf6 100644
--- a/drivers/media/video/bt8xx/bttv-cards.c
+++ b/drivers/media/video/bt8xx/bttv-cards.c
@@ -3529,7 +3529,7 @@ void __devinit bttv_init_card2(struct bttv *btv)
struct v4l2_subdev *sd;
sd = v4l2_i2c_new_subdev(btv-c.v4l2_dev,
- btv-c.i2c_adap, NULL, saa6588, 0, addrs);
+ btv-c.i2c_adap, saa6588, 0, addrs);
btv-has_saa6588 = (sd != NULL);
}
@@ -3554,7 +3554,7 @@ void __devinit bttv_init_card2(struct bttv *btv)
};
btv-sd_msp34xx = v4l2_i2c_new_subdev(btv-c.v4l2_dev,
- btv-c.i2c_adap, NULL, msp3400, 0, addrs);
+ btv-c.i2c_adap, msp3400, 0, addrs);
if (btv-sd_msp34xx)
return;
goto no_audio;
@@ -3568,7 +3568,7 @@ void __devinit bttv_init_card2
Re: [PATCH 07/16] pvrusb2: Don't use module names to load I2C modules
Acked-By: Mike Isely is...@pobox.com
On Fri, 24 Sep 2010, Laurent Pinchart wrote:
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, replace the hardcoded module name passed to those
functions by NULL.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the pvrusb2
driver uses.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/pvrusb2/pvrusb2-hdw.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
index 70ea578..bef2027 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -2082,20 +2082,13 @@ static int pvr2_hdw_load_subdev(struct pvr2_hdw *hdw,
return -EINVAL;
}
- /* Note how the 2nd and 3rd arguments are the same for
- * v4l2_i2c_new_subdev(). Why?
- * Well the 2nd argument is the module name to load, while the 3rd
- * argument is documented in the framework as being the chipid -
- * and every other place where I can find examples of this, the
- * chipid appears to just be the module name again. So here we
- * just do the same thing. */
if (i2ccnt == 1) {
pvr2_trace(PVR2_TRACE_INIT,
Module ID %u:
Setting up with specified i2c address 0x%x,
mid, i2caddr[0]);
sd = v4l2_i2c_new_subdev(hdw-v4l2_dev, hdw-i2c_adap,
- fname, fname,
+ NULL, fname,
i2caddr[0], NULL);
} else {
pvr2_trace(PVR2_TRACE_INIT,
@@ -2103,7 +2096,7 @@ static int pvr2_hdw_load_subdev(struct pvr2_hdw *hdw,
Setting up with address probe list,
mid);
sd = v4l2_i2c_new_subdev(hdw-v4l2_dev, hdw-i2c_adap,
- fname, fname,
+ NULL, fname,
0, i2caddr);
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
Problem with HVR 900 (B2C0) and USB detection
Hi I have been using this device for years using Markuses Driver. Now for some bizarre reason using both this driver and devins the wrong USB driver is being used (ohci rather than ehci), which means it is recognised as a USB 1.1 device, which makes it stop working Anyone know if there is any way to force it to use USB 2 Other usb devices use the correct usb speed 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
Problem with Compro T200 (TDA1004x) and tuning Hi
I am trying to tune channels with this card (which seems to be installed OK). However the output is Using DVB card Philips TDA10046H DVB-T tuning DVB-T (in United Kingdom) to 497833000 Hz polling Getting frontend event FE_STATUS: polling polling polling etc,etc -- 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: Problem with Compro T200 (TDA1004x) and tuning Hi
On 22 November 2010 06:08, hermann pitton hermann-pit...@arcor.de wrote: Hi Mike, Am Sonntag, den 21.11.2010, 17:58 + schrieb Mike Martin: I am trying to tune channels with this card (which seems to be installed OK). However the output is Using DVB card Philips TDA10046H DVB-T tuning DVB-T (in United Kingdom) to 497833000 Hz polling Getting frontend event FE_STATUS: polling polling polling usually, in the UK, this can be caused by the missing ability to detect some frequencies offsets by the tda10046. Since you have already a minus of 167000Hz, typically for the UK, in your initial scan/tuning file, this most common problem likely can be excluded. So there are eventually three variants causing the problem on a first idea. 1. They changed to 498 MHz. (or did change something else too, auto is your friend in the initial scan file then, except for the freq.) tried that no difference 2. Your overall signal is not good enough. well up until friday I was using a HVR900, until it decided to refuse to believe it was plugged into a USB2 bus, and it was working fine 3. You sit on some kernel with some bug. Case one and two are not hard to come through, for case three, the remedies are slipping away. You might have to install some latest .rc-git stuff, likely without support for your graphics card, coming up in vesa mode only, try to record something, and boot back into some kernel with support for displaying the record, we all have HDTV these days ... It might look like that, since the mobile devices and webcams took it all over here ;) Cheers, Hermann -- 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
Problems with using dvb_usb_rtl2832u
Hi I am using this driver with USB 1b80:s395 Modules load scandvb gets channels /dev/dvb gets created dvbtune seems to tune to transponder however none of the other dvb utilities seem to work ie: dvbdate dvbsnoop (except forfeinfo) dvbtraffic dvbstream example dvbsnoop -s feinfo dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ - FrontEnd Info... - Device: /dev/dvb/adapter0/frontend0 Basic capabilities: Name: Realtek RTL2832 DVB-T RTL2836 DTMB Frontend-type: OFDM (DVB-T) Frequency (min): 174000.000 kHz Frequency (max): 862000.000 kHz Frequency stepsiz: 166.667 kHz Frequency tolerance: 0.000 kHz Symbol rate (min): 0.00 MSym/s Symbol rate (max): 0.00 MSym/s Symbol rate tolerance: 0 ppm Notifier delay: 0 ms Frontend capabilities: auto inversion FEC 1/2 FEC 2/3 FEC 3/4 FEC 5/6 FEC 7/8 FEC AUTO QPSK QAM 16 QAM 64 QAM AUTO auto transmission mode auto guard interval auto hierarchy Current parameters: Frequency: 497833.000 kHz Inversion: OFF Bandwidth: 8 MHz Stream code rate (hi prio): FEC 2/3 Stream code rate (lo prio): FEC AUTO Modulation: QAM 64 Transmission mode: 2k mode Guard interval: 1/32 Hierarchy: none dvbdate . dvbdate: timeout - try tuning to a multiplex? dvbdate: Unable to get time from multiplex. any ideas? -- 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
Problems with using dvb_usb_rtl2832u
Hi I am using this driver with USB 1b80:s395 Modules load scandvb gets channels /dev/dvb gets created dvbtune seems to tune to transponder however none of the other dvb utilities seem to work ie: dvbdate dvbsnoop (except forfeinfo) dvbtraffic dvbstream example dvbsnoop -s feinfo dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ - FrontEnd Info... - Device: /dev/dvb/adapter0/frontend0 Basic capabilities: Name: Realtek RTL2832 DVB-T RTL2836 DTMB Frontend-type: OFDM (DVB-T) Frequency (min): 174000.000 kHz Frequency (max): 862000.000 kHz Frequency stepsiz: 166.667 kHz Frequency tolerance: 0.000 kHz Symbol rate (min): 0.00 MSym/s Symbol rate (max): 0.00 MSym/s Symbol rate tolerance: 0 ppm Notifier delay: 0 ms Frontend capabilities: auto inversion FEC 1/2 FEC 2/3 FEC 3/4 FEC 5/6 FEC 7/8 FEC AUTO QPSK QAM 16 QAM 64 QAM AUTO auto transmission mode auto guard interval auto hierarchy Current parameters: Frequency: 497833.000 kHz Inversion: OFF Bandwidth: 8 MHz Stream code rate (hi prio): FEC 2/3 Stream code rate (lo prio): FEC AUTO Modulation: QAM 64 Transmission mode: 2k mode Guard interval: 1/32 Hierarchy: none dvbdate . dvbdate: timeout - try tuning to a multiplex? dvbdate: Unable to get time from multiplex. any ideas? -- 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: Problems with using dvb_usb_rtl2832u
On 27 November 2010 16:33, Anca Emanuel anca.eman...@gmail.com wrote: On Sat, Nov 27, 2010 at 6:14 PM, Mike Martin redt...@gmail.com wrote: Hi I am using this driver with USB 1b80:s395 It's not possible to be s395, please send what lsusb prints. And if you have other info, like the product info, etc. sorry typo 1b80:d395 -- 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: Problems with using dvb_usb_rtl2832u
On 27 November 2010 17:05, Mike Martin m...@redtux.org.uk wrote: On 27 November 2010 16:33, Anca Emanuel anca.eman...@gmail.com wrote: On Sat, Nov 27, 2010 at 6:14 PM, Mike Martin redt...@gmail.com wrote: Hi I am using this driver with USB 1b80:s395 It's not possible to be s395, please send what lsusb prints. And if you have other info, like the product info, etc. sorry typo 1b80:d395 further info Dvbstreamer works but very few other dvb* utilities - confused now -- 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
rtl2832u usb dvb id 1b80:d395
hi Still have one or two probs I have tried both anttis and jan trees, both of them compile but do not load modules or create dvb device when modprobed Using the realtek driver (1.4.2) I have the following issue one (and now only one) mux fails to pick up any channels, the channels are as clear as day my digibox with the same same connection tune to: 530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: tuning failed!!! The only difference I can see is this in dvbtune mux that works dvbtune -f 482167000 Using DVB card Realtek RTL2832 DVB-T RTL2836 DTMB tuning DVB-T (in United Kingdom) to 482167000 Hz polling Getting frontend event FE_STATUS: polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 492767000 SymbolRate: 0 FEC_inner: 2 Bit error rate: 206 Signal strength: 14135 SNR: 19 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC failing mux dvbtune -f 530167000 Using DVB card Realtek RTL2832 DVB-T RTL2836 DTMB tuning DVB-T (in United Kingdom) to 530167000 Hz polling Getting frontend event FE_STATUS: polling polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 540767000 SymbolRate: 0 FEC_inner: 2 Bit error rate: 19616 Signal strength: 14135 SNR: 16 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC The only difference I can see is the SNR and ber (19616) any ideas -- 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
rtl2832u usb dvb id 1b80:d395
hi Still have one or two probs I have tried both anttis and jan trees, both of them compile but do not load modules or create dvb device when modprobed Using the realtek driver (1.4.2) I have the following issue one (and now only one) mux fails to pick up any channels, the channels are as clear as day my digibox with the same same connection tune to: 530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: tuning failed!!! The only difference I can see is this in dvbtune mux that works dvbtune -f 482167000 Using DVB card Realtek RTL2832 DVB-T RTL2836 DTMB tuning DVB-T (in United Kingdom) to 482167000 Hz polling Getting frontend event FE_STATUS: polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 492767000 SymbolRate: 0 FEC_inner: 2 Bit error rate: 206 Signal strength: 14135 SNR: 19 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC failing mux dvbtune -f 530167000 Using DVB card Realtek RTL2832 DVB-T RTL2836 DTMB tuning DVB-T (in United Kingdom) to 530167000 Hz polling Getting frontend event FE_STATUS: polling polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 540767000 SymbolRate: 0 FEC_inner: 2 Bit error rate: 19616 Signal strength: 14135 SNR: 16 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC The only difference I can see is the SNR and ber (19616) any ideas -- 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
Accessing running dvb device
Hi I am trying to run multiple recordings on my dvb device (rtl2832). However when I try to access the frontend settings when a recording is active get_frontend returns nothing. This is using the Linux::DVB::DVBT module any suggestions -- 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: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl
I'll take care of the pvrusb2 driver. How soon does this need to be completed? -Mike On Sat, 18 Dec 2010, Hans Verkuil wrote: On Saturday, December 18, 2010 12:31:26 Hans Verkuil wrote: Driver list: saa7146 (Hans Verkuil) mem2mem_testdev (Pawel Osciak or Marek Szyprowski) cx23885 (Steve Toth) cx18-alsa (Andy Walls) omap24xxcam (Sakari Ailus or David Cohen) au0828 (Janne Grunau) cpia2 (Andy Walls or Hans Verkuil) cx231xx (Mauro Carvalho Chehab) davinci (Muralidharan Karicheri) saa6588 (Hans Verkuil) pvrusb2 (Mike Isely) usbvision (Hans Verkuil) s5p-fimc (Sylwester Nawrocki) fsl-viu (Anatolij Gustschin) tlg2300 (Mauro Carvalho Chehab) zr364xx (Hans de Goede) soc_camera (Guennadi Liakhovetski) usbvideo/vicam (Hans de Goede) s2255drv (Pete Eberlein) bttv (Mauro Carvalho Chehab) stk-webcam (Hans de Goede) se401 (Hans de Goede) si4713-i2c (Hans Verkuil) dsbr100 (Hans Verkuil) Oops, si4713-i2c and saa6588 are subdevs, so those two can be removed from this list. Regards, Hans -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [uclinux-dist-devel] [PATCH 2/4] v4l2: add adv7183 decoder driver
On Tue, Sep 13, 2011 at 14:34, Scott Jiang wrote: --- /dev/null +++ b/drivers/media/video/adv7183_regs.h +#define ADV7183_IN_CTRL 0x00 /* Input control */ should be a space after the #define, not a tab --- /dev/null +++ b/include/media/adv7183.h +#define ADV7183_16BIT_OUT 1 same here -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: [uclinux-dist-devel] [PATCH 4/4] v4l2: add blackfin capture bridge driver
On Tue, Sep 13, 2011 at 14:34, Scott Jiang wrote:
--- /dev/null
+++ b/drivers/media/video/blackfin/Kconfig
@@ -0,0 +1,10 @@
+config VIDEO_BLACKFIN_CAPTURE
+ tristate Blackfin Video Capture Driver
+ depends on VIDEO_DEV BLACKFIN
+ select VIDEOBUF2_DMA_CONTIG
since the code needs i2c, this needs to list I2C under depends
--- /dev/null
+++ b/drivers/media/video/blackfin/bfin_capture.c
+#include linux/moduleparam.h
+#include linux/version.h
+#include linux/clk.h
i think at least these three are unused and should get punted
+static int __devinit bcap_probe(struct platform_device *pdev)
+{
+ struct bcap_device *bcap_dev;
+ struct video_device *vfd;
+ struct i2c_adapter *i2c_adap;
you need to include linux/i2c.h for this
+static struct platform_driver bcap_driver = {
+ .driver = {
+ .name = CAPTURE_DRV_NAME,
+ .owner = THIS_MODULE,
+ },
+ .probe = bcap_probe,
+ .remove = __devexit_p(bcap_remove),
+};
no suspend/resume ? :)
+MODULE_DESCRIPTION(Analog Devices video capture driver);
should mention the device part name in the desc
--- /dev/null
+++ b/drivers/media/video/blackfin/ppi.c
+struct ppi_if *create_ppi_instance(const struct ppi_info *info)
+void delete_ppi_instance(struct ppi_if *ppi)
should be ppi_{create,delete}_instance to match existing ppi_xxx style
-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: [uclinux-dist-devel] [PATCH 3/4] v4l2: add vs6624 sensor driver
On Tue, Sep 13, 2011 at 14:34, Scott Jiang wrote:
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
+obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
should be after vpx, not before ?
--- /dev/null
+++ b/drivers/media/video/vs6624.c
+#include asm/gpio.h
run these patches through checkpatch.pl ? this should be linux/gpio.h ...
+static const u16 vs6624_p1[] = {
+static const u16 vs6624_p2[] = {
add comments as to what these are for ?
+static inline int vs6624_read(struct v4l2_subdev *sd, u16 index)
+static inline int vs6624_write(struct v4l2_subdev *sd, u16 index,
+ u8 value)
should these be inline ? they're a little fat ... better to let the
compiler choose
+static int vs6624_writeregs(struct v4l2_subdev *sd, const u16 *regs)
+{
+ u16 reg, data;
+
+ while (*regs != 0x00) {
+ reg = *regs++;
+ data = *regs++;
+
+ vs6624_write(sd, reg, (u8)data);
what's the point of declaring data as u16 if the top 8 bits are never used ?
+static int vs6624_g_chip_ident(struct v4l2_subdev *sd,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ int rev;
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ rev = vs6624_read(sd, VS6624_FW_VSN_MAJOR) 8
+ | vs6624_read(sd, VS6624_FW_VSN_MINOR);
i'm a little surprised the compiler didnt warn about this. usually
bit shifts + bitwise operators want paren to keep things clear.
+#ifdef CONFIG_VIDEO_ADV_DEBUG
just use DEBUG ?
+ v4l_info(client, chip found @ 0x%02x (%s)\n,
+ client-addr 1, client-adapter-name);
is that 1 correct ? i dont think so ...
-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: [uclinux-dist-devel] [PATCH 3/4] v4l2: add vs6624 sensor driver
On Wed, Sep 14, 2011 at 03:28, Scott Jiang wrote: +#ifdef CONFIG_VIDEO_ADV_DEBUG just use DEBUG ? no, v4l2 use CONFIG_VIDEO_ADV_DEBUG ok, i was thinking this was something we added (since we have ADVxxx parts) + v4l_info(client, chip found @ 0x%02x (%s)\n, + client-addr 1, client-adapter-name); is that 1 correct ? i dont think so ... every driver under media I see use this, so what's wrong? meh, they're all wrong imo then :p. they're shifting the address to accommodate datasheets that incorrectly specify the i2c address with the read/write as bit 0. but it's fine for this driver to do that if it's the standard that the rest of the v4l code has adopted. -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 2/2] [media] pvrusb2: implement VIDIOC_QUERYSTD
Acked-By: Mike Isely is...@pobox.com
-Mike
On Mon, 3 Oct 2011, Mauro Carvalho Chehab wrote:
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/pvrusb2/pvrusb2-hdw.c |7 +++
drivers/media/video/pvrusb2/pvrusb2-hdw.h |3 +++
drivers/media/video/pvrusb2/pvrusb2-v4l2.c |7 +++
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
index e98d382..5a6f24d 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -2993,6 +2993,13 @@ static void pvr2_subdev_set_control(struct pvr2_hdw
*hdw, int id,
pvr2_subdev_set_control(hdw, id, #lab, (hdw)-lab##_val); \
}
+int pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw, v4l2_std_id *std)
+{
+ v4l2_device_call_all(hdw-v4l2_dev, 0,
+ video, querystd, std);
+ return 0;
+}
+
/* Execute whatever commands are required to update the state of all the
sub-devices so that they match our current control values. */
static void pvr2_subdev_update(struct pvr2_hdw *hdw)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.h
b/drivers/media/video/pvrusb2/pvrusb2-hdw.h
index d7753ae..6654658 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.h
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.h
@@ -214,6 +214,9 @@ struct pvr2_stream *pvr2_hdw_get_video_stream(struct
pvr2_hdw *);
int pvr2_hdw_get_stdenum_value(struct pvr2_hdw *hdw,struct v4l2_standard
*std,
unsigned int idx);
+/* Get the detected video standard */
+int pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw, v4l2_std_id *std);
+
/* Enable / disable retrieval of CPU firmware or prom contents. This must
be enabled before pvr2_hdw_cpufw_get() will function. Note that doing
this may prevent the device from running (and leaving this mode may
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index e27f8ab..0d029da 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -227,6 +227,13 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
break;
}
+ case VIDIOC_QUERYSTD:
+ {
+ v4l2_std_id *std = arg;
+ ret = pvr2_hdw_get_detected_std(hdw, std);
+ break;
+ }
+
case VIDIOC_G_STD:
{
int val = 0;
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: [PATCHv2 5/8] [media] pvrusb2: initialize standards mask before detecting standard
Mauro:
With the line you've just added, then the = arg assignment in the
immediate prior line is effectively dead code. Try this instead:
case VIDIOC_QUERYSTD:
{
- v4l2_std_id *std = arg;
+ v4l2_std_id *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
-Mike
On Tue, 4 Oct 2011, Mauro Carvalho Chehab wrote:
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index 0d029da..ce7ac45 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -230,6 +230,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
case VIDIOC_QUERYSTD:
{
v4l2_std_id *std = arg;
+ *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: [PATCHv2 5/8] [media] pvrusb2: initialize standards mask before detecting standard
On Wed, 5 Oct 2011, Mauro Carvalho Chehab wrote:
Em 05-10-2011 11:00, Mike Isely escreveu:
Mauro:
With the line you've just added, then the = arg assignment in the
immediate prior line is effectively dead code. Try this instead:
Look better:
v4l2_std_id *std = arg;
+ *std = V4L2_STD_ALL;
The above code is creating a pointer 'std' of the type 'v4l2_std_id', and
initializing the pointer with the void *arg.
Oh yeah, you're absolutely right. I got visually tricked by the well
known confusing C initialization syntax when dealing with pointers!
I've got to not respond to stuff like this in the morning until I've
finished waking up. Duh...
Then, it is doing an indirect reference to the pointer, filling its
contents with V4L2_STD_ALL value.
The code above is sane (and, btw, it works). After those patches, the
detection code will detect PAL/M or NTSC/M depending on the channel I
tune here (my cable operator broadcasts some channels with one format,
and others with the other one). Before this patch and the msp3400, it
would return a mask with PAL/M and PAL/60 or a mask with all NTSC/M formats.
Regarding your first version of the patch:
Acked-By: Mike Isely is...@pobox.com
-Mike
Regards,
Mauro.
case VIDIOC_QUERYSTD:
{
- v4l2_std_id *std = arg;
+ v4l2_std_id *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
-Mike
On Tue, 4 Oct 2011, Mauro Carvalho Chehab wrote:
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index 0d029da..ce7ac45 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -230,6 +230,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
case VIDIOC_QUERYSTD:
{
v4l2_std_id *std = arg;
+ *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
Problem with TeVii S-470
Hello! I have this card http://www.linuxtv.org/wiki/index.php/TeVii_S470 I try to use it under Debian Squeeze, but I can't get channel data from it. I try to use drivers from 2.6.38, 2.6.39 kernels, s2-liplianin drivers with 2.6.32 kernel, last linux-media drivers with 2.6.32 With all drivers I can scan channels, but then a I'll try to lock channel I get some error in syslog (module cx23885 loaded with debug=1) cx23885[0]/0: [f373ec80/27] cx23885_buf_queue - append to active cx23885[0]/0: [f373ebc0/28] wakeup reg=477 buf=477 cx23885[0]/0: queue is not empty - append to active and finally a lot of cx23885[0]/0: [f42c4240/6] timeout - dma=0x03c5c000 cx23885[0]/0: [f42c4180/7] timeout - dma=0x3322b000 cx23885[0]/0: [f4374440/8] timeout - dma=0x33048000 cx23885[0]/0: [f4374140/9] timeout - dma=0x03d68000 In other machine this work under Windows. Under Linux I have same effects. It's problem in drivers or in card? That addition information need to resolve this problem? -- 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: Problem with TeVii S-470
24.10.2011 15:29, Josu Lazkano пишет: 2011/10/24 Mike Mironovsubscr...@darkmike.ru: Hello! I have this card http://www.linuxtv.org/wiki/index.php/TeVii_S470 I try to use it under Debian Squeeze, but I can't get channel data from it. I try to use drivers from 2.6.38, 2.6.39 kernels, s2-liplianin drivers with 2.6.32 kernel, last linux-media drivers with 2.6.32 With all drivers I can scan channels, but then a I'll try to lock channel I get some error in syslog (module cx23885 loaded with debug=1) cx23885[0]/0: [f373ec80/27] cx23885_buf_queue - append to active cx23885[0]/0: [f373ebc0/28] wakeup reg=477 buf=477 cx23885[0]/0: queue is not empty - append to active and finally a lot of cx23885[0]/0: [f42c4240/6] timeout - dma=0x03c5c000 cx23885[0]/0: [f42c4180/7] timeout - dma=0x3322b000 cx23885[0]/0: [f4374440/8] timeout - dma=0x33048000 cx23885[0]/0: [f4374140/9] timeout - dma=0x03d68000 In other machine this work under Windows. Under Linux I have same effects. It's problem in drivers or in card? That addition information need to resolve this problem? Hello Mike, I have same device on same OS, try this: mkdir /usr/local/src/dvbcd /usr/local/src/dvbwget http://tevii.com/100315_Beta_linux_tevii_ds3000.rarunrar x 100315_Beta_linux_tevii_ds3000.rarcp dvb-fe-ds3000.fw /lib/firmware/tar xjvf linux-tevii-ds3000.tar.bz2cd linux-tevii-ds3000make make install Regards. I'll try use this drivers today, but for this devices drivers exist in kernel from 2.6.33. So it must work with in-kernel drivers. P.S. Firmware from this archive I put in /lib/firmware before all tests. $ md5sum /lib/firmware/dvb-fe-ds3000.fw a32d17910c4f370073f9346e71d34b80 /lib/firmware/dvb-fe-ds3000.fw -- 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: Problem with TeVii S-470
24.10.2011 17:32, Josu Lazkano пишет: 2011/10/24 Mike Mironovsubscr...@darkmike.ru: 24.10.2011 15:29, Josu Lazkano пишет: 2011/10/24 Mike Mironovsubscr...@darkmike.ru: Hello! I have this card http://www.linuxtv.org/wiki/index.php/TeVii_S470 I try to use it under Debian Squeeze, but I can't get channel data from it. I try to use drivers from 2.6.38, 2.6.39 kernels, s2-liplianin drivers Hello again, actually, I am using this method for Tevii S660 and S470: apt-get install linux-headers-`uname -r` build-essential mkdir /usr/local/src/dvb cd /usr/local/src/dvb wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip unzip tip.zip cd s2-liplianin-0b7d3cc65161 make CONFIG_DVB_FIREDTV:=n make install Both methods works for me on a Debian Squeeze (2.6.32). Here more info: http://linuxtv.org/wiki/index.php/TeVii_S470 As your can see in quoted text I always try to use this drivers. Result is same. I'll always read WiKi link. I know that another users use this card without problems. I have good signal quality (88% signal and 79-80% snr). But in my 2 linux systems I can't get channel data. Scan work fine(!). -- 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] [media] v4l2: punt generated pdf files
On Wed, Oct 26, 2011 at 09:24, Mike Frysinger wrote: These don't belong in the tree, and we have a .gitignore on them already (not sure how these slipped in), so punt the compiled files. hrm, i thought default git send-email/format-patch didn't include binary updates when deleting in the diff. not sure what's going on here. i can resend if people want with the -D flag. -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: [RFC PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
Andy:
Is the IR_i2c_init_data struct instance required to remain around for
the life of the driver's registration and is that why you stuffed it
into the pvr2_hdw struct? Second: If the first question is yes, then is
that struct considered to be read-only once it is set up and passed
through to the i2c device registration function? In other words, could
that structure be a const static initialized at compile time, perhaps
as part of a table definition?
I believe I follow this and it looks good. The concept looks very
simple and it's nice that the changes are really only in a single spot.
Just thinking ahead about making the setup table-driven and not
requiring data segment storage.
-Mike
Acked-By: Mike Isely is...@pobox.com
On Sun, 16 Jan 2011, Andy Walls wrote:
When registering an IR Rx device with the I2C subsystem, provide more detailed
information about the IR device and default remote configuration for the IR
driver modules.
Also explicitly register any IR Tx device with the I2C subsystem.
Signed-off-by: Andy Walls awa...@md.metrocast.net
Cc: Mike Isely is...@isely.net
--
Mike,
As discussed on IRC, this patch will enable lirc_zilog to bind to Zilog
Z8 IR units on devices supported by pvrusb2.
Please review and comment. This patch could have been written a number
of ways. The way I chose was very direct: hard-coding information in a
single function.
A git branch with this change, and the updated lirc_zilog, is here:
git://linuxtv.org/awalls/media_tree.git z8-pvrusb2
http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8-pvrusb2
Regards,
Andy
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
index ac94a8b..305e6aa 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
@@ -40,6 +40,7 @@
#include pvrusb2-io.h
#include media/v4l2-device.h
#include media/cx2341x.h
+#include media/ir-kbd-i2c.h
#include pvrusb2-devattr.h
/* Legal values for PVR2_CID_HSM */
@@ -202,6 +203,7 @@ struct pvr2_hdw {
/* IR related */
unsigned int ir_scheme_active; /* IR scheme as seen from the outside */
+ struct IR_i2c_init_data ir_init_data; /* params passed to IR modules */
/* Frequency table */
unsigned int freqTable[FREQTABLE_SIZE];
diff --git a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
index 7cbe18c..ccc8849 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
@@ -19,6 +19,7 @@
*/
#include linux/i2c.h
+#include media/ir-kbd-i2c.h
#include pvrusb2-i2c-core.h
#include pvrusb2-hdw-internal.h
#include pvrusb2-debug.h
@@ -48,13 +49,6 @@ module_param_named(disable_autoload_ir_video,
pvr2_disable_ir_video,
MODULE_PARM_DESC(disable_autoload_ir_video,
1=do not try to autoload ir_video IR receiver);
-/* Mapping of IR schemes to known I2C addresses - if any */
-static const unsigned char ir_video_addresses[] = {
- [PVR2_IR_SCHEME_ZILOG] = 0x71,
- [PVR2_IR_SCHEME_29XXX] = 0x18,
- [PVR2_IR_SCHEME_24XXX] = 0x18,
-};
-
static int pvr2_i2c_write(struct pvr2_hdw *hdw, /* Context */
u8 i2c_addr, /* I2C address we're talking to */
u8 *data, /* Data to write */
@@ -574,26 +568,56 @@ static void do_i2c_scan(struct pvr2_hdw *hdw)
static void pvr2_i2c_register_ir(struct pvr2_hdw *hdw)
{
struct i2c_board_info info;
- unsigned char addr = 0;
+ struct IR_i2c_init_data *init_data = hdw-ir_init_data;
if (pvr2_disable_ir_video) {
pvr2_trace(PVR2_TRACE_INFO,
Automatic binding of ir_video has been disabled.);
return;
}
- if (hdw-ir_scheme_active ARRAY_SIZE(ir_video_addresses)) {
- addr = ir_video_addresses[hdw-ir_scheme_active];
- }
- if (!addr) {
+ memset(info, 0, sizeof(struct i2c_board_info));
+ switch (hdw-ir_scheme_active) {
+ case PVR2_IR_SCHEME_24XXX: /* FX2-controlled IR */
+ case PVR2_IR_SCHEME_29XXX: /* Original 29xxx device */
+ init_data-ir_codes = RC_MAP_HAUPPAUGE_NEW;
+ init_data-internal_get_key_func = IR_KBD_GET_KEY_HAUP;
+ init_data-type = RC_TYPE_RC5;
+ init_data-name = hdw-hdw_desc-description;
+ init_data-polling_interval = 100; /* ms From ir-kbd-i2c */
+ /* IR Receiver */
+ info.addr = 0x18;
+ info.platform_data = init_data;
+ strlcpy(info.type, ir_video, I2C_NAME_SIZE);
+ pvr2_trace(PVR2_TRACE_INFO, Binding %s to i2c address 0x%02x.,
+info.type
Re: [RFC PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
On Sun, 16 Jan 2011, Andy Walls wrote: On Sun, 2011-01-16 at 20:27 -0600, Mike Isely wrote: [,,,] Right now, yes. In the near future, I need to use to to pass 3 non-const items though: 1. A struct mutex *transceiver_lock so that the bridge driver can pass a mutex to multiple modules accessing the Z8. That would be a per device instance mutex, instantiated and initialized by the bridge driver. The use case where this would be needed is a setup where ir-kbd-i2c handles Z8 IR Rx and lirc_zilog handles only Z8 IR Tx of the same chip. 2. A bridge driver provided void (*reset_ir_chip)(struct i2c_adapter *adap), or maybe void (*reset_ir_chip)(void *priv), callback to reset the transceiver chip when it gets hung. The original lirc_pvr150 module had some hard coded reset function names and calls in it, but they were removed with the rename to lirc_zilog and move into the kernel. I'd like to get that ability back. 3. A bridge driver provided private data structure for the void *priv argument of the aforementioned reset callback. This would also be a per device object instantiated and initialized by the bridge driver. I follow. Makes sense. Something to consider, perhaps for the future: Seems like what you have here amounts to some configuration data which will always be read-only, and other data which maps to the context in which the driver is being used (e.g. mutex instance, callback private context pointer, etc). That configuration data, if packed up into its own struct, could then be squirreled away at compile-time by the bridge driver and provided as part of a single table lookup. This only makes sense if there are a lot of configuration bits - but here I count 6 different items. I believe I follow this and it looks good. The concept looks very simple and it's nice that the changes are really only in a single spot. Just thinking ahead about making the setup table-driven and not requiring data segment storage. With the patch right now it could be constant, I think. You would have to use some generic name, like pvrusb2 IR, instead of hdw-hdw_desc-description though. For my future plans, if you don't provide a reset callback and don't wish to provide a mutex, then yes you can keep it constant. I suspect not providing a reset callback may be OK. Not providing a mutex is also OK but it imposes a limitation: only one IR module should be allowed to use the Z8 chip. That means only lirc_zilog for IR Tx/Rx with Rx through LIRC, or only ir-kbd-i2c for IR Rx through the the Linux input subsystem. For the future, I have no problem providing a reset callback. And given what you've said, I see no reason to do anything here which would constrain what you're trying to accomplish. But if down the road you do set up a separate configuration struct which this context struct might point to, then I'd like to update the pvrusb2 driver to take advantage of it. But this is no big deal for now. -Mike Acked-By: Mike Isely is...@pobox.com Thanks. I'll pull this into my Z8 branch then. You're welcome. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Andy Walls wrote: On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote: Not working with lirc_zilog yet, it fails to load, due to an -EIO ret to one of the i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't looked into it any more than that yet. Well technically lirc_zilog doesn't probe anymore. It relies on the bridge driver telling it the truth. The bridge driver (pvrusb2) still does one probe if it's a 24xxx device: It probes 0x71 in order to determine if it is dealing with an MCE variant device. Hauppauge did not change the USB ID when they released the 24xxx MCE variant (which has the IR blaster, thus the zilog device). The only way to tell the two devices apart is by discovering the existence of the zilog device - and the bridge driver needs to do this in order to properly disable its emulated I2C IR receiver which would otherwise be needed for the non-MCE device. Based on the discussion here, could that probe be a source of trouble on the 24XXX MCE device? This probing behavior does not happen for HVR-1950 (or HVR-1900) since there's only one possible IR configuration there. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Andy Walls wrote: On Wed, 2011-01-19 at 13:40 +0100, Jean Delvare wrote: On Wed, 19 Jan 2011 07:21:58 -0500, Andy Walls wrote: For debugging, you might want to hack in a probe of address 0x70 for your HVR-1950, to ensure the Tx side responds in the bridge driver. ... keeping in mind that the Z8 doesn't seem to like quick writes, so short reads should be used for probing purpose. Noted. Thanks. Actually, I think that might be due to the controller in the USB connected devices (hdpvr and pvrusb2). The PCI connected devices, like cx18 cards, don't have a problem with the Z8, the default I2C probe method, and i2c-algo-bit. (A good example of why only bridge drivers should do any required probing.) Looking at the code in pvrusb2, it appears to already use a 0 length read for a probe: http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/pvrusb2/pvrusb2-i2c-core.c;h=ccc884948f34b385563ccbf548c5f80b33cd4f08;hb=refs/heads/staging/for_2.6.38-rc1#l542 Yes but that function is used in two places: (1) If a bus scan is performed during initialization (normally it isn't), and (2) it is called once ONLY for a 24xxx device (targeting 0x71) in order to determine if it is dealing with the MCE variant. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Andy Walls wrote: [...] So the HVR-1950 only has Z8's capable of both Tx and Rx? No HVR-1950 has an Rx only Z8 unit? As far as I know, that is indeed the case - Tx and Rx always. It's the older 24xxx devices where there could be a difference, and that's why the probe only takes place there. (And in the receive-only 24xxx configuration it's not a Z8 but something wierd that is only accessible through FX2 commands not via I2C, which is why the bridge driver emulates the older I2C chip, making IR reception behave like the original 29xxx device.) -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Jean Delvare wrote: Hi Andy, On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote: 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if adding some new fields for struct IR_i2c_init_data is acceptable. Specifically, I'd like to add a transceiver_lock mutex, a transceiver reset callback, and a data pointer for that reset callback. (Only lirc_zilog would use the reset callback and data pointer.) Adding fields to these structures is perfectly fine, if you need to do that, just go on. But I'm a little confused about the names you chose, ir_transceiver_lock and transceiver_lock. These seem too TX-oriented for a mutex that is supposed to synchronize TX and RX access. It's particularly surprising for the ir-kbd-i2c driver, which as far as I know only supports RX. The name xcvr_lock you used for lirc_zilog seems more appropriate. Actually the term transceiver is normally understood to mean both directions. Otherwise it would be receiver or transmitter. Another screwy as aspect of english, and I say this as a native english speaker. The term xcvr is usually just considered to be shorthand for transceiver. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Jarod Wilson wrote: On Jan 19, 2011, at 8:20 AM, Mike Isely wrote: This probing behavior does not happen for HVR-1950 (or HVR-1900) since there's only one possible IR configuration there. Just to be 100% clear, the device I'm poking it is definitely an HVR-1950, using ir_scheme PVR2_IR_SCHEME_ZILOG, so the probe bits shouldn't coming into play with anything I'm doing. Only just now started looking at the pvrusb2 code. Wow, there's a LOT of it. ;) Yes, and yes :-) The standalone driver version (which is loaded with ifdef's that allow compilation back to 2.6.11) makes the in-kernel driver look small by comparison. There is a fair degree of compartmentalization between the modules. The roadmap to what it does for just HVR-1950 you can find by first looking at the declarations in pvrusb2-devattr.h and then the device-specific configurations in pvrusb2-devattr.c. From there you can usually grep your way around to see how those configuration bits affect the rest of the driver. Most of the really fun stuff is in pvrusb2-hdw.c. Pretty much everything else supports or uses that central component. The actual stuff which deals with I2C is not that large. Beyond making the access possible at all, the driver largely just tries to stay out of the way of external logic that needs to reach the bus. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ir-kbd-i2c: improve remote behavior with z8 behind usb
The pvrusb2 change is obviously trivial so I have no issue with it.
Acked-By: Mike Isely is...@pobox.com
Note the spelling of my last name Isely not Isley. A good way to
remember is to think of the normal word wisely and just drop the
leading w. (And yes, is...@isely.net and is...@pobox.com lead to the
same inbox.)
-Mike
On Thu, 20 Jan 2011, Jarod Wilson wrote:
Add the same are you ready? i2c_master_send() poll command to
get_key_haup_xvr found in lirc_zilog, which is apparently seen in
the Windows driver for the PVR-150 w/a z8. This stabilizes what is
received from both the HD-PVR and HVR-1950, even with their polling
intervals at the default of 100, thus the removal of the custom
260ms polling_interval in pvrusb2-i2c-core.c.
CC: Andy Walls awa...@md.metrocast.net
CC: Mike Isley is...@isley.net
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/video/ir-kbd-i2c.c | 13 +
drivers/media/video/pvrusb2/pvrusb2-i2c-core.c |1 -
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ir-kbd-i2c.c
b/drivers/media/video/ir-kbd-i2c.c
index d2b20ad..a221ad6 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -128,6 +128,19 @@ static int get_key_haup(struct IR_i2c *ir, u32 *ir_key,
u32 *ir_raw)
static int get_key_haup_xvr(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
{
+ int ret;
+ unsigned char buf[1] = { 0 };
+
+ /*
+ * This is the same apparent are you ready? poll command observed
+ * watching Windows driver traffic and implemented in lirc_zilog. With
+ * this added, we get far saner remote behavior with z8 chips on usb
+ * connected devices, even with the default polling interval of 100ms.
+ */
+ ret = i2c_master_send(ir-c, buf, 1);
+ if (ret != 1)
+ return (ret 0) ? ret : -EINVAL;
+
return get_key_haup_common (ir, ir_key, ir_raw, 6, 3);
}
diff --git a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
index ccc8849..451ecd4 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
@@ -597,7 +597,6 @@ static void pvr2_i2c_register_ir(struct pvr2_hdw *hdw)
init_data-internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
init_data-type = RC_TYPE_RC5;
init_data-name = hdw-hdw_desc-description;
- init_data-polling_interval = 260; /* ms From lirc_zilog */
/* IR Receiver */
info.addr = 0x71;
info.platform_data = init_data;
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ir-kbd-i2c: improve remote behavior with z8 behind usb
On Fri, 21 Jan 2011, Mike Isely wrote: Note the spelling of my last name Isely not Isley. A good way to remember is to think of the normal word wisely and just drop the leading w. (And yes, is...@isely.net and is...@pobox.com lead to the same inbox.) And of course having said that, I then failed to fix the cc list. Sorry about that. D'Oh!!! -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ir-kbd-i2c: improve remote behavior with z8 behind usb
On Fri, 21 Jan 2011, Jarod Wilson wrote: On Fri, Jan 21, 2011 at 10:31:42AM -0600, Mike Isely wrote: The pvrusb2 change is obviously trivial so I have no issue with it. Acked-By: Mike Isely is...@pobox.com Note the spelling of my last name Isely not Isley. A good way to remember is to think of the normal word wisely and just drop the leading w. (And yes, is...@isely.net and is...@pobox.com lead to the same inbox.) Thanks Mike, apologies about the misspelling, I didn't catch it until after I hit send. I had the Isley Brothers in my head. :) No problem. It's a very common mistake. And no, I'm not related to them. For the record, I generally don't get concerned about the spelling of my name, unless the error causes problems (e.g. lost e-mail) or the error gets propagated to a large list where it might multiply... Anyway, sorry also about taking this thread off topic. Enough said... -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
v4l-utils-0.8.3 and KVDR
My understanding of the wrapperscontained in this library is that v4l applications should work with kernels from 2.6.36 onwards if the compat.so is preloaded. I use KVDR for watching and controlling VDR on my TV. Xine and Xineliboutput or not options as they don't provide TV out and TV out fronm the video card is also not an option because of where things are in the house. KVDR fails with Xv-VIDIOCGCAP: Invalid argument Xv-VIDIOCGMBUF: Invalid argument works perfectly fine on linux-2.6.35 Anyone have any ideas 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
[GIT PULL FOR 2.6.39] pvrusb2 driver
Mauro, [Note: This is my first real attempt at using git to get changes pulled, so please let me know if I missed a step. These changes are all relatively minor and have been sitting around for while. There will be more to follow once I'm sure I am doing this process correctly... -Mike Isely] The following changes since commit 5ed4bbdae09d207d141759e013a0f3c24ae76ecc: Mauro Carvalho Chehab (1): [media] tuner-core: Don't touch at standby during tuner_lookup are available in the git repository at: git://git.linuxtv.org/mcisely/pvrusb2-dev.git pvrusb2-merge-1 Mike Isely (5): pvrusb2: Handle change of mode before handling change of video standard pvrusb2: Minor cosmetic code tweak pvrusb2: Fix a few missing default control values, for cropping pvrusb2: Minor VBI tweak to help potential CC support pvrusb2: Use sysfs_attr_init() where appropriate Servaas Vandenberghe (1): pvrusb2: width and height maximum values. drivers/media/video/pvrusb2/pvrusb2-hdw.c | 60 +++ drivers/media/video/pvrusb2/pvrusb2-sysfs.c |9 2 files changed, 43 insertions(+), 26 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: v4l-utils-0.8.3 and KVDR
KVDR has a number of different parameters including -xforce xv-mode on startup and disable overlay-mod -ddont switch modeline during xv with kernel 2.6.35 I run KVDR with -x as I have an NVIDIA graphics. Running on 2.6.38 KVDR -x doesn't produce any log. The display appears and immediately disappears although there is a process running. With KVDR -d I get a display window but no picture but the attached log is produced. I hope this helps Mike libv4l2: open: 4 request == VIDIOC_G_FMT pixelformat: BGR3 384x288 field: 0 bytesperline: 0 imagesize331776 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 0, description: RGB-8 (3-3-2) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB1 48x32 field: 3 bytesperline: 48 imagesize1536 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB1 768x288 field: 3 bytesperline: 768 imagesize221184 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 1, description: RGB-16 (5/B-6/G-5/R) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGBP 48x32 field: 3 bytesperline: 768 imagesize24576 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGBP 768x288 field: 3 bytesperline: 1536 imagesize442368 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 2, description: RGB-24 (B-G-R) result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR3 48x32 field: 3 bytesperline: 1536 imagesize49152 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR3 768x288 field: 3 bytesperline: 2304 imagesize663552 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 3, description: RGB-32 (B-G-R) result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR4 48x32 field: 3 bytesperline: 2304 imagesize73728 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR4 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 4, description: RGB-32 (R-G-B) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB4 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB4 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 5, description: Greyscale-8 result == 0 request == VIDIOC_TRY_FMT pixelformat: GREY 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: GREY 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 6, description: YUV 4:2:2 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: 422P 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: 422P 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 7, description: YVU 4:2:0 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: YV12 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: YV12 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 8, description: YUV 4:2:0 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: YU12 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: YU12 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 9, description: YUV 4:2:2 (U-Y-V-Y) result == 0 request == VIDIOC_TRY_FMT pixelformat: UYVY 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: UYVY 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 10, description: RGB3 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB3 48x32 field: 3 bytesperline: 144 imagesize4608 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB3 768x288 field: 3 bytesperline: 2304 imagesize663552 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 11, description: result == -1 (Invalid argument) request == VIDIOC_ENUMINPUT result == 0 request == VIDIOC_ENUMSTD result == 0 libv4l1: open: 4 request == VIDIOC_QUERYCAP result == 0 request == VIDIOC_G_FBUF result == 0 request == VIDIOC_S_FBUF result == 0 libv4l2: close: 4 libv4l1: close: 4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More
Re: compilation warnings/errors
On Fri, 11 Mar 2011, Mauro Carvalho Chehab wrote: /home/mchehab/new_build/v4l/pvrusb2-v4l2.c: In function 'pvr2_v4l2_do_ioctl': /home/mchehab/new_build/v4l/pvrusb2-v4l2.c:798:23: warning: variable 'cap' set but not used [-Wunused-but-set-variable] I will look into these. I'm a little puzzled right now since silly stuff like this usually doesn't get by me. Unfortunately I can't look at it right this minute. Expect to hear from me on Sunday. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: compilation warnings/errors
On Fri, 11 Mar 2011, Mike Isely wrote: On Fri, 11 Mar 2011, Mauro Carvalho Chehab wrote: /home/mchehab/new_build/v4l/pvrusb2-v4l2.c: In function 'pvr2_v4l2_do_ioctl': /home/mchehab/new_build/v4l/pvrusb2-v4l2.c:798:23: warning: variable 'cap' set but not used [-Wunused-but-set-variable] I will look into these. I'm a little puzzled right now since silly stuff like this usually doesn't get by me. Unfortunately I can't look at it right this minute. Expect to hear from me on Sunday. I looked at these two warnings. It's dead code that should be removed. Amazingly enough, this particular bit of crap has been in the driver, unnoticed, since 2008! I have a pull request coming for more pvrusb2 patches, probably in a few more hours, once I'm done testing. A fix for this will be in the patch set. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
[GIT PATCHES FOR 2.6.39] pvrusb2 driver fixes / improvements
Mauro: Please pull the following patches. Note also that the Implement support for Terratec Grabster AV400 is not as big of a change as it might sound. The work to implement that really amounted to just some extra table entries, plus those changes have been out in the wild via the standalone pvrusb2 driver for quite some time. Getting that into the kernel is long overdue. -Mike The following changes since commit 41f3becb7bef489f9e8c35284dd88a1ff59b190c: Hans Verkuil (1): [media] V4L DocBook: update V4L2 version are available in the git repository at: git://git.linuxtv.org/mcisely/pvrusb2-dev.git pvrusb2-merge-2 Mike Isely (2): pvrusb2: Implement support for Terratec Grabster AV400 pvrusb2: Remove dead code Xiaochen Wang (1): pvrusb2: check kmalloc return value drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c | 18 +++ drivers/media/video/pvrusb2/pvrusb2-devattr.c | 24 + drivers/media/video/pvrusb2/pvrusb2-hdw.c | 24 ++--- drivers/media/video/pvrusb2/pvrusb2-v4l2.c|2 - 4 files changed, 58 insertions(+), 10 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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/6] [media] pvrusb2: white space changes
I vehemently object to this scale of disruption to the pvrusb2 driver
source code purely to move around a bunch of braces and whitespace.
ESPECIALLY the massive ridiculous changes having to do with if-statement
syntax!
Nacked-By: Mike Isely is...@pobox.com
On Sat, 26 Mar 2011, Dan Carpenter wrote:
* Broke up if statements so that the condition and the body are on
separate lines.
* Added spaces around commas and other operator characters.
* Removed extra blank lines.
* Added blank lines after declarations.
* Changed C99 comments into kernel style.
* Fixed checkpatch complaints where { char was on its own line but it
wasn't the start of a function.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
b/drivers/media/video/pvrusb2/pvrusb2-std.c
index ca9f83a..a5d4867 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-std.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
@@ -28,39 +28,38 @@ struct std_name {
v4l2_std_id id;
};
-
#define CSTD_PAL \
- (V4L2_STD_PAL_B| \
- V4L2_STD_PAL_B1| \
- V4L2_STD_PAL_G| \
- V4L2_STD_PAL_H| \
- V4L2_STD_PAL_I| \
- V4L2_STD_PAL_D| \
- V4L2_STD_PAL_D1| \
- V4L2_STD_PAL_K| \
- V4L2_STD_PAL_M| \
- V4L2_STD_PAL_N| \
- V4L2_STD_PAL_Nc| \
+ (V4L2_STD_PAL_B | \
+ V4L2_STD_PAL_B1 | \
+ V4L2_STD_PAL_G | \
+ V4L2_STD_PAL_H | \
+ V4L2_STD_PAL_I | \
+ V4L2_STD_PAL_D | \
+ V4L2_STD_PAL_D1 | \
+ V4L2_STD_PAL_K | \
+ V4L2_STD_PAL_M | \
+ V4L2_STD_PAL_N | \
+ V4L2_STD_PAL_Nc | \
V4L2_STD_PAL_60)
#define CSTD_NTSC \
- (V4L2_STD_NTSC_M| \
- V4L2_STD_NTSC_M_JP| \
- V4L2_STD_NTSC_M_KR| \
+ (V4L2_STD_NTSC_M| \
+ V4L2_STD_NTSC_M_JP | \
+ V4L2_STD_NTSC_M_KR | \
V4L2_STD_NTSC_443)
#define CSTD_ATSC \
- (V4L2_STD_ATSC_8_VSB| \
+ (V4L2_STD_ATSC_8_VSB | \
V4L2_STD_ATSC_16_VSB)
#define CSTD_SECAM \
- (V4L2_STD_SECAM_B| \
- V4L2_STD_SECAM_D| \
- V4L2_STD_SECAM_G| \
- V4L2_STD_SECAM_H| \
- V4L2_STD_SECAM_K| \
- V4L2_STD_SECAM_K1| \
- V4L2_STD_SECAM_L| \
+ (V4L2_STD_SECAM_B | \
+ V4L2_STD_SECAM_D | \
+ V4L2_STD_SECAM_G | \
+ V4L2_STD_SECAM_H | \
+ V4L2_STD_SECAM_K | \
+ V4L2_STD_SECAM_K1 | \
+ V4L2_STD_SECAM_L | \
V4L2_STD_SECAM_LC)
#define TSTD_B (V4L2_STD_PAL_B|V4L2_STD_SECAM_B)
@@ -82,39 +81,40 @@ struct std_name {
/* Mapping of standard bits to color system */
static const struct std_name std_groups[] = {
- {PAL,CSTD_PAL},
- {NTSC,CSTD_NTSC},
- {SECAM,CSTD_SECAM},
- {ATSC,CSTD_ATSC},
+ {PAL, CSTD_PAL},
+ {NTSC, CSTD_NTSC},
+ {SECAM, CSTD_SECAM},
+ {ATSC, CSTD_ATSC},
};
/* Mapping of standard bits to modulation system */
static const struct std_name std_items[] = {
- {B,TSTD_B},
- {B1,TSTD_B1},
- {D,TSTD_D},
- {D1,TSTD_D1},
- {G,TSTD_G},
- {H,TSTD_H},
- {I,TSTD_I},
- {K,TSTD_K},
- {K1,TSTD_K1},
- {L,TSTD_L},
- {LC,V4L2_STD_SECAM_LC},
- {M,TSTD_M},
- {Mj,V4L2_STD_NTSC_M_JP},
- {443,V4L2_STD_NTSC_443},
- {Mk,V4L2_STD_NTSC_M_KR},
- {N,TSTD_N},
- {Nc,TSTD_Nc},
- {60,TSTD_60},
- {8VSB,V4L2_STD_ATSC_8_VSB},
- {16VSB,V4L2_STD_ATSC_16_VSB},
+ {B, TSTD_B},
+ {B1,TSTD_B1},
+ {D, TSTD_D},
+ {D1,TSTD_D1},
+ {G, TSTD_G},
+ {H, TSTD_H},
+ {I, TSTD_I},
+ {K, TSTD_K},
+ {K1,TSTD_K1},
+ {L, TSTD_L},
+ {LC,V4L2_STD_SECAM_LC},
+ {M, TSTD_M},
+ {Mj,V4L2_STD_NTSC_M_JP},
+ {443, V4L2_STD_NTSC_443},
+ {Mk,V4L2_STD_NTSC_M_KR},
+ {N, TSTD_N},
+ {Nc,TSTD_Nc},
+ {60,TSTD_60},
+ {8VSB, V4L2_STD_ATSC_8_VSB},
+ {16VSB, V4L2_STD_ATSC_16_VSB},
};
-
-// Search an array of std_name structures and return a pointer to the
-// element with the matching name.
+/*
+ * Search an array of std_name structures and return a pointer to the
+ * element with the matching name.
+ */
static const struct std_name *find_std_name(const struct std_name *arrPtr,
unsigned int arrSize,
const char *bufPtr,
@@ -122,16 +122,18 @@ static const struct std_name *find_std_name(const
struct std_name *arrPtr,
{
unsigned int idx;
const struct std_name *p;
+
for (idx = 0; idx arrSize; idx++) {
p = arrPtr + idx;
- if (strlen(p-name) != bufSize) continue;
- if (!memcmp(bufPtr,p-name,bufSize)) return p;
+ if (strlen(p-name) != bufSize)
+ continue;
+ if (!memcmp(bufPtr, p-name, bufSize))
+ return p
Re: [PATCH 2/6] [media] pvrusb2: fix remaining checkpatch.pl complaints
I am OK with the #include change, but NOT the if-statement change. But
since it's bundled into one patch...
Nacked-By: Mike Isely is...@pobox.com
On Sat, 26 Mar 2011, Dan Carpenter wrote:
* Include linux/string.h instead of asm/string.h.
* Remove unneeded curly braces.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
b/drivers/media/video/pvrusb2/pvrusb2-std.c
index a5d4867..370a9ab 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-std.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
@@ -20,7 +20,7 @@
#include pvrusb2-std.h
#include pvrusb2-debug.h
-#include asm/string.h
+#include linux/string.h
#include linux/slab.h
struct std_name {
@@ -294,9 +294,8 @@ static struct v4l2_standard *match_std(v4l2_std_id id)
unsigned int idx;
for (idx = 0; idx generic_standards_cnt; idx++) {
- if (generic_standards[idx].id id) {
+ if (generic_standards[idx].id id)
return generic_standards + idx;
- }
}
return NULL;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] [media] pvrusb2: check for allocation failures
Acked-By: Mike Isely is...@pobox.com On Sat, 26 Mar 2011, Dan Carpenter wrote: This function returns NULL on failure so lets do that if kzalloc() fails. There is a separate problem that the caller for this function doesn't check for errors... Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c b/drivers/media/video/pvrusb2/pvrusb2-std.c index 370a9ab..b214f77 100644 --- a/drivers/media/video/pvrusb2/pvrusb2-std.c +++ b/drivers/media/video/pvrusb2/pvrusb2-std.c @@ -388,6 +388,9 @@ struct v4l2_standard *pvr2_std_create_enum(unsigned int *countptr, stddefs = kzalloc(sizeof(struct v4l2_standard) * std_cnt, GFP_KERNEL); + if (!stddefs) + return NULL; + for (idx = 0; idx std_cnt; idx++) stddefs[idx].index = idx; -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] [media] pvrusb2: fix camel case variables
It not worth this scale of source code disruption to the source code
just to rename a bunch of variables. I'm sorry, but...
Nacked-By: Mike Isely is...@pobox.com
On Sat, 26 Mar 2011, Dan Carpenter wrote:
This patch renames some variables to bring them more in line with
kernel CodingStyle.
arrPtr = arr
arrSize = arr_size
bufPtr = buf
bufSize = buf_size
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
b/drivers/media/video/pvrusb2/pvrusb2-std.c
index b214f77..d5a679f 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-std.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
@@ -115,26 +115,26 @@ static const struct std_name std_items[] = {
* Search an array of std_name structures and return a pointer to the
* element with the matching name.
*/
-static const struct std_name *find_std_name(const struct std_name *arrPtr,
- unsigned int arrSize,
- const char *bufPtr,
- unsigned int bufSize)
+static const struct std_name *find_std_name(const struct std_name *arr,
+ unsigned int arr_size,
+ const char *buf,
+ unsigned int buf_size)
{
unsigned int idx;
const struct std_name *p;
- for (idx = 0; idx arrSize; idx++) {
- p = arrPtr + idx;
- if (strlen(p-name) != bufSize)
+ for (idx = 0; idx arr_size; idx++) {
+ p = arr + idx;
+ if (strlen(p-name) != buf_size)
continue;
- if (!memcmp(bufPtr, p-name, bufSize))
+ if (!memcmp(buf, p-name, buf_size))
return p;
}
return NULL;
}
-int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char *bufPtr,
-unsigned int bufSize)
+int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char *buf,
+unsigned int buf_size)
{
v4l2_std_id id = 0;
v4l2_std_id cmsk = 0;
@@ -144,27 +144,27 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
*bufPtr,
char ch;
const struct std_name *sp;
- while (bufSize) {
+ while (buf_size) {
if (!mMode) {
cnt = 0;
- while ((cnt bufSize) (bufPtr[cnt] != '-'))
+ while ((cnt buf_size) (buf[cnt] != '-'))
cnt++;
- if (cnt = bufSize)
+ if (cnt = buf_size)
return 0; /* No more characters */
sp = find_std_name(std_groups, ARRAY_SIZE(std_groups),
-bufPtr, cnt);
+buf, cnt);
if (!sp)
return 0; /* Illegal color system name */
cnt++;
- bufPtr += cnt;
- bufSize -= cnt;
+ buf += cnt;
+ buf_size -= cnt;
mMode = !0;
cmsk = sp-id;
continue;
}
cnt = 0;
- while (cnt bufSize) {
- ch = bufPtr[cnt];
+ while (cnt buf_size) {
+ ch = buf[cnt];
if (ch == ';') {
mMode = 0;
break;
@@ -174,7 +174,7 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
*bufPtr,
cnt++;
}
sp = find_std_name(std_items, ARRAY_SIZE(std_items),
-bufPtr, cnt);
+buf, cnt);
if (!sp)
return 0; /* Illegal modulation system ID */
t = sp-id cmsk;
@@ -182,10 +182,10 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
*bufPtr,
return 0; /* Specific color + modulation system
illegal */
id |= t;
- if (cnt bufSize)
+ if (cnt buf_size)
cnt++;
- bufPtr += cnt;
- bufSize -= cnt;
+ buf += cnt;
+ buf_size -= cnt;
}
if (idPtr)
@@ -193,7 +193,7 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
*bufPtr,
return !0;
}
-unsigned int pvr2_std_id_to_str(char *bufPtr, unsigned int bufSize,
+unsigned int pvr2_std_id_to_str(char *buf, unsigned int buf_size,
v4l2_std_id id)
{
unsigned int idx1, idx2;
@@ -212,26 +212,26 @@ unsigned int pvr2_std_id_to_str(char *bufPtr, unsigned
int bufSize,
continue
Re: [PATCH 5/5] [media] pvrusb2: delete generic_standards_cnt
Are you actually serious about this? Well it's a small change...
Acked-By: Mike Isely is...@pobox.com
On Sat, 26 Mar 2011, Dan Carpenter wrote:
The generic_standards_cnt define is only used in one place and it's
more readable to just call ARRAY_SIZE(generic_standards) directly.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
b/drivers/media/video/pvrusb2/pvrusb2-std.c
index d5a679f..9bebc08 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-std.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
@@ -287,13 +287,11 @@ static struct v4l2_standard generic_standards[] = {
}
};
-#define generic_standards_cnt ARRAY_SIZE(generic_standards)
-
static struct v4l2_standard *match_std(v4l2_std_id id)
{
unsigned int idx;
- for (idx = 0; idx generic_standards_cnt; idx++) {
+ for (idx = 0; idx ARRAY_SIZE(generic_standards); idx++) {
if (generic_standards[idx].id id)
return generic_standards + idx;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 6/6] [media] pvrusb2: replace !0 with 1
That's an opinion which I as the driver author disagree with. Strongly.
How hard is it to read not false?
Nacked-By: Mike Isely is...@pobox.com
On Sat, 26 Mar 2011, Dan Carpenter wrote:
Using !0 is less readable than just saying 1.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
b/drivers/media/video/pvrusb2/pvrusb2-std.c
index 9bebc08..ca4f67b 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-std.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
@@ -158,7 +158,7 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
*buf,
cnt++;
buf += cnt;
buf_size -= cnt;
- mMode = !0;
+ mMode = 1;
cmsk = sp-id;
continue;
}
@@ -190,7 +190,7 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
*buf,
if (idPtr)
*idPtr = id;
- return !0;
+ return 1;
}
unsigned int pvr2_std_id_to_str(char *buf, unsigned int buf_size,
@@ -217,10 +217,10 @@ unsigned int pvr2_std_id_to_str(char *buf, unsigned int
buf_size,
buf_size -= c2;
buf += c2;
}
- cfl = !0;
+ cfl = 1;
c2 = scnprintf(buf, buf_size,
%s-, gp-name);
- gfl = !0;
+ gfl = 1;
} else {
c2 = scnprintf(buf, buf_size, /);
}
@@ -315,7 +315,7 @@ static int pvr2_std_fill(struct v4l2_standard *std,
v4l2_std_id id)
std-name[bcnt] = 0;
pvr2_trace(PVR2_TRACE_STD, Set up standard idx=%u name=%s,
std-index, std-name);
- return !0;
+ return 1;
}
/*
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] [media] pvrusb2: check for allocation failures
I'll look at the surrounding code and see what makes sense there. Having an error leg for allocation failures is a useful thing. -Mike Dan Carpenter wrote: On Fri, Mar 25, 2011 at 11:33:36PM -0500, Mike Isely wrote: Acked-By: Mike Isely is...@pobox.com I'd need to reformat this one to get it to apply... :/ It doesn't actually fix the bug so it's not worth it. regards, dan carpenter -- 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 -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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] media/radio/wl1273: fix build errors
On Sun, Feb 27, 2011 at 12:51, Randy Dunlap wrote: From: Randy Dunlap randy.dun...@oracle.com RADIO_WL1273 needs to make sure that the mfd core is built to avoid build errors: ERROR: mfd_add_devices [drivers/mfd/wl1273-core.ko] undefined! ERROR: mfd_remove_devices [drivers/mfd/wl1273-core.ko] undefined! 2.6.38 stable worthy ? now in mainline as 1b149bbe9156d2eb2afd5a072bd61ad0d4bfaca7 ... -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: [RFCv6 PATCH 04/10] pvrusb2: fix g/s_tuner support.
I understand that this patch would not have been need had the pvrusb2
driver been using videodev_ioctl2. This is a situation that I'm going
to (finally) remedy ASAP. In the mean time...
Acked-By: Mike Isely is...@pobox.com
-Mike
On Tue, 14 Jun 2011, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
The tuner-core subdev requires that the type field of v4l2_tuner is
filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
use that yet, so we have to do it manually based on whether the current
input is radio or not.
Tested with my pvrusb2.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/pvrusb2/pvrusb2-hdw.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
index 9d0dd08..e98d382 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -3046,6 +3046,8 @@ static void pvr2_subdev_update(struct pvr2_hdw *hdw)
if (hdw-input_dirty || hdw-audiomode_dirty || hdw-force_dirty) {
struct v4l2_tuner vt;
memset(vt, 0, sizeof(vt));
+ vt.type = (hdw-input_val == PVR2_CVAL_INPUT_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
vt.audmode = hdw-audiomode_val;
v4l2_device_call_all(hdw-v4l2_dev, 0, tuner, s_tuner, vt);
}
@@ -5171,6 +5173,8 @@ void pvr2_hdw_status_poll(struct pvr2_hdw *hdw)
{
struct v4l2_tuner *vtp = hdw-tuner_signal_info;
memset(vtp, 0, sizeof(*vtp));
+ vtp-type = (hdw-input_val == PVR2_CVAL_INPUT_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
hdw-tuner_signal_stale = 0;
/* Note: There apparently is no replacement for VIDIOC_CROPCAP
using v4l2-subdev - therefore we can't support that AT ALL right
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [beagleboard] [PATCH v8 2/2] Add support for mt9p031 sensor in Beagleboard XM.
PLEASE TAKE NOTE - THIS IS THE THIRD TIME I HAVE ASKED FOR UNSUBSCRIBE
The email address lwal...@bluechiptechnology.co.uk nneds to be deleted
urgently. This is a former employee, I have to monitor this email box and it
is full of this beagleboard messaging which is no longer relevant to this
business.;
PLEASE ACTION URGENTLY
M G Gulliford
Blue Chip Te4chnology Ltd
-Original Message-
From: Javier Martin javier.mar...@vista-silicon.com
Sent: 20/06/2011 12:21
To: linux-media@vger.kernel.org linux-media@vger.kernel.org
Cc: g.liakhovet...@gmx.de g.liakhovet...@gmx.de;
laurent.pinch...@ideasonboard.com laurent.pinch...@ideasonboard.com;
carlight...@yahoo.co.nz carlight...@yahoo.co.nz;
beaglebo...@googlegroups.com beaglebo...@googlegroups.com;
mch_...@yahoo.com.cn mch_...@yahoo.com.cn; Javier Martin
javier.mar...@vista-silicon.com
Subject: [beagleboard] [PATCH v8 2/2] Add support for mt9p031 sensor in
Beagleboard XM.
Use new platform data ext_freq and target_freq.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3beagle-camera.c | 95
arch/arm/mach-omap2/board-omap3beagle.c| 50
3 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..05cd983 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) +=
board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
+ board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..96b4f95
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,95 @@
+#include linux/gpio.h
+#include linux/regulator/machine.h
+
+#include plat/i2c.h
+
+#include media/mt9p031.h
+#include asm/mach-types.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
+#define MT9P031_EXT_FREQ 2100
+
+static struct regulator *reg_1v8, *reg_2v8;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+
+ return isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+}
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+ .ext_freq = MT9P031_EXT_FREQ,
+ .target_freq= 4800,
+ .version= MT9P031_COLOR_VERSION,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
+static int __init beagle_camera_init(void)
+{
+ if (!machine_is_omap3_beagle() || !cpu_is_omap3630())
+ return 0;
+
+ reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(reg_1v8))
+ pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_1v8);
+
+ reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(reg_2v8))
+ pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_2v8);
+
+ omap_register_i2c_bus(2, 100, NULL, 0);
+
Re: [PATCH 5 of 8] pvrusb2: use usb_interface.dev for v4l2_device_register
This patch will not at all impact the operation of the pvrusb2 driver,
and if associating with the USB interface's device node is preferred
then I'm fine with it.
Acked-by: Mike Isely is...@pobox.com
Mauro: Is this series going to be pulled into v4l-dvb or shall I just
bring this one specific change into my pvrusb2 repo? Is there any
reason not to pull it?
-Mike
On Sun, 29 Mar 2009, Janne Grunau wrote:
# HG changeset patch
# User Janne Grunau j...@jannau.net
# Date 1238338428 -7200
# Node ID 2d52ac089920f9ac36960c0245442fd89a06bb75
# Parent 01af508490af3bc9c939c36001d6989e2c147aa0
pvrusb2: use usb_interface.dev for v4l2_device_register
Priority: normal
Signed-off-by: Janne Grunau j...@jannau.net
diff -r 01af508490af -r 2d52ac089920
linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
--- a/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c Sun Mar 29 16:53:48
2009 +0200
+++ b/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c Sun Mar 29 16:53:48
2009 +0200
@@ -2591,7 +2591,7 @@
hdw-ctl_read_urb = usb_alloc_urb(0,GFP_KERNEL);
if (!hdw-ctl_read_urb) goto fail;
- if (v4l2_device_register(usb_dev-dev, hdw-v4l2_dev) != 0) {
+ if (v4l2_device_register(intf-dev, hdw-v4l2_dev) != 0) {
pvr2_trace(PVR2_TRACE_ERROR_LEGS,
Error registering with v4l core, giving up);
goto fail;
--
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
--
Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for a few pvrusb2 changesets. All should find their way into 2.6.30; two in particular are important bug fixes. -Mike - pvrusb2: Fix incorrect reporting of default value for non-integer controls - pvrusb2: Report def_val items in sysfs symbolically, consistent with cur_val - pvrusb2: Fix uninitialized tuner_setup field(s) pvrusb2-ctrl.c | 12 +--- pvrusb2-hdw.c |1 + pvrusb2-sysfs.c | 14 -- 3 files changed, 14 insertions(+), 13 deletions(-) -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Nacked-by: Mike Isely is...@pobox.com
This will interfere with the alternative use of LIRC drivers (which work
in more cases that ir-kbd). It will thus break some peoples' use of the
driver. Also we have better information on what i2c addresses needed to
be probed based on the model of the device - and some devices supported
by this device are not from Hauppauge so you are making a too-strong
assumption that IR should be probed this way in all cases. Also, unless
ir-kbd has suddenly improved, this will not work at all for HVR-1950
class devices nor MCE type PVR-24xxx devices (different incompatible IR
receiver).
This is why the pvrusb2 driver has never directly attempted to load
ir-kbd.
-Mike
On Sat, 4 Apr 2009, Jean Delvare wrote:
--- v4l-dvb.orig/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-04-04 10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-04-04 10:58:36.0 +0200
@@ -649,6 +649,27 @@ static void do_i2c_scan(struct pvr2_hdw
printk(KERN_INFO %s: i2c scan done.\n, hdw-name);
}
+static void pvr2_i2c_register_ir(struct i2c_adapter *i2c_adap)
+{
+ struct i2c_board_info info;
+ /* The external IR receiver is at i2c address 0x34 (0x35 for
+reads). Future Hauppauge cards will have an internal
+receiver at 0x30 (0x31 for reads). In theory, both can be
+fitted, and Hauppauge suggest an external overrides an
+internal.
+
+That's why we probe 0x1a (~0x34) first. CB
+ */
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x4b, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, ir-kbd, I2C_NAME_SIZE);
+ i2c_new_probed_device(i2c_adap, info, addr_list);
+}
+
void pvr2_i2c_core_init(struct pvr2_hdw *hdw)
{
unsigned int idx;
@@ -696,6 +717,9 @@ void pvr2_i2c_core_init(struct pvr2_hdw
}
}
if (i2c_scan) do_i2c_scan(hdw);
+
+ /* Instantiate the IR receiver device, if present */
+ pvr2_i2c_register_ir(hdw-i2c_adap);
}
void pvr2_i2c_core_done(struct pvr2_hdw *hdw)
--
Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 0/6] ir-kbd-i2c conversion to the new i2c binding model
Jean: I understand what you're trying to do but how is LIRC expected to still work if all drivers now force the user over to ir-kbd? -Mike On Sat, 4 Apr 2009, Jean Delvare wrote: Hi all, Here finally comes my conversion of ir-kbd-i2c to the new i2c binding model. I've split it into 6 pieces for easier review. Firstly there are 2 preliminary patches: media-video-01-cx18-fix-i2c-error-handling.patch media-video-02-ir-kbd-i2c-dont-abuse-client-name.patch Then 2 patches doing the actual conversion: media-video-03-ir-kbd-i2c-convert-to-new-style.patch media-video-04-configure-ir-receiver.patch And lastly 2 patches cleaning up saa7134-input thanks to the new possibilities offered by the conversion: media-video-05-saa7134-input-cleanup-msi-ir.patch media-video-06-saa7134-input-cleanup-avermedia-cardbus.patch This patch set is against the v4l-dvb repository, but I didn't pay attention to the compatibility issues. I simply build-tested it on 2.6.27 and 2.6.29. This patch set touches many different drivers and I can't test any of them. My only TV card with an IR receiver doesn't make use of ir-kbd-i2c. So I would warmly welcome testers. The more testing my changes can get, the better. And of course I welcome reviews and comments as well. I had to touch many drivers I don't know anything about so it is possible that I missed something. I'll post all 6 patches as replies to this post. They can also be temporarily downloaded from: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ Additionally I've put a combined patch there, to make testing easier: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN-ONE.patch But for review the individual patches are much better. Thanks, -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sat, 4 Apr 2009, Andy Walls wrote: [...] I have an I2C related question. If the cx18 or ivtv driver autoloads ir-kbd-i2c and registers an I2C client on the bus, does that preclude lirc_i2c, lirc_pvr150 or lirc_zilog from using the device? LIRC users may notice, if it does. If that is the case, then we probably shouldn't autoload the ir-kbd module after the CX23418 i2c adapters are initialized. I'm not sure what's the best solution: 1. A module option to the cx18 driver to tell it to call init_cx18_i2c_ir() from cx18_probe() or not? (Easiest solution) 2. Some involved programmatic way for IR device modules to query bridge drivers about what IR devices they may have, and on which I2C bus, and at what addresses to probe, and whether a driver/module has already claimed that device? (Gold plated solution) Regards, Andy Ah, glad to see I'm not the only one concerned about this. I suppose I could instead add a module option to the pvrusb2 driver to control autoloading of ir-kbd (option 1). It also should probably be a per-device attribute, since AFAIK, ir-kbd only even works when using older Hauppauge IR receivers (i.e. lirc_i2c - cases that would otherwise use lirc_pvr150 or lirc_zilog I believe do not work with ir-kbd). Some devices handled by the pvrusb2 driver are not from Hauppauge. Too bad if this is the case, it was easier to let the user decide just by choosing which actual module to load. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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] pvrusb2: Drop client_register/unregister stubs
Acked-by: Mike Isely is...@pobox.com
On Sat, 4 Apr 2009, Jean Delvare wrote:
The client_register and client_unregister methods are optional so
there is no point in defining stub ones. Especially when these methods
are likely to be removed soon.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c | 12
1 file changed, 12 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-04-04 13:58:40.0 +0200
+++ v4l-dvb/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-04-04 22:12:21.0 +0200
@@ -595,16 +595,6 @@ static u32 pvr2_i2c_functionality(struct
return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C;
}
-static int pvr2_i2c_attach_inform(struct i2c_client *client)
-{
- return 0;
-}
-
-static int pvr2_i2c_detach_inform(struct i2c_client *client)
-{
- return 0;
-}
-
static struct i2c_algorithm pvr2_i2c_algo_template = {
.master_xfer = pvr2_i2c_xfer,
.functionality = pvr2_i2c_functionality,
@@ -617,8 +607,6 @@ static struct i2c_adapter pvr2_i2c_adap_
.owner = THIS_MODULE,
.class = 0,
.id= I2C_HW_B_BT848,
- .client_register = pvr2_i2c_attach_inform,
- .client_unregister = pvr2_i2c_detach_inform,
};
--
Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 0/6] ir-kbd-i2c conversion to the new i2c binding model
On Sun, 5 Apr 2009, Jean Delvare wrote: Hi Mauro, On Sun, 5 Apr 2009 07:01:16 -0300, Mauro Carvalho Chehab wrote: From the discussions we already have, I noticed some points to take care of: 1) about the lirc support, I don't think we should change a kernel driver due to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, we need to better address this with lirc developers; Well, the new binding model makes it harder for rogue drivers such as lirc_i2c. They will need _some_ form of cooperation from us, which will most likely come when they get merged into the kernel tree. 2) the way Mike is proposing to solve the issue with pvrusb2 will break userspace usage for people that have those devices whose IR work with the in-kernel IR i2c driver. This means that we'll cause a kernel regression due to an out-of-tree driver; It's an either/or. If nothing is done, the ir-kbd-i2c become unusable for pvrusb2 but lirc (for now) continues to work. If Jean's change is accepted as-is, then ir-kbd-i2c will be ok but now lirc is toast. If I implement what I am suggesting, then it becomes possible at least for both cases to still work, but with a module option. Not perfect, but it is the only way I see to allow this situation to retain some sanity. In the longer term, the lirc folks are going to have to change what they are doing. Fine, that's a problem they have to solve. It's nothing I can do anyting about. But I am not going to be the instigator that breaks lirc as used by the pvrusb2 driver. In the short term, implementing the module option breaks the deadlock here. Jean can continue getting rid of the old i2c model and I won't be a pain about it. 3) So far, nobody gave us any positive return that the new IR model is working with any of the touched drivers. So, more tests are needed. I'm expecting to have a positive reply for each of the touched drivers. People, please test! Yes, please! :) Since the merge window is almost finished, IMO, we should postpone those changes to 2.6.31, (...) The legacy i2c model will be gone in 2.6.30. Really. Hans and myself have put enough energy into this to not let it slip for just a miserable infrared support module which I understand is hardly used by anyone. So it's really up to you, either you accept my ir-kbd-i2c conversion now (that is, when it has received the minimum testing and reviewing it deserves) and ir-kbd-i2c has a chance to work in 2.6.30, or you don't and I'll just have to mark ir-kbd-i2c as BROKEN to prevent build failures. Accept his ir-kbd-i2c conversion now, minus the pvrusb2 changes. I will deal with the pvrusb2 driver appropriately (and immediately). That should resolve the issue for the short term. to better address the lirc issue and to give people more time for testing, applying the changesets after the end of the merge window at the v4l/dvb development tree. This will help people to test, review and propose changes if needed. These changes are on-going for over a year now. If the lirc people didn't hear about it so far, I doubt they will pay more attention just because we delay the deadline by 2 months. The only thing that will get their attention is when lirc_i2c break. So let's just do that ;) Don't get me wrong. I don't want to be (too) rude to lirc developers. If they need help to port their code to the new i2c binding model, I'll help them. If they need help to merge lirc_i2c into the kernel, I'll help as well. But I don't see any point in delaying important, long awaited kernel changes just for them. As long as they are out-of-tree, they can fix things after the fact easily. They aren't affected by the merge window. They'll have several weeks before kernel 2.6.30 is actually released, which they can use to fix anything that broke. I agree. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009, Hans Verkuil wrote: [...] Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). Yes, and I will do the same for pvrusb2. Simple is good. It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. It's probably going to break, and that will wake them up. There's no choice otherwise. The new mechanism is the right way to do it: the adapter driver has all the information if, where and what IR is used and so should be the one to tell the kernel what to do. Attempting to autodetect and magically figure out what IR might be there is awkward and probably impossible to get right 100%. Hell, it's wrong already: if you have another board that already loads ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c whether you like it or not, because ir-kbd-i2c will connect to your i2c adapter like a leech. So with the addition of a module option you at least give back control of this to the user. Yes, I know this is a possibility. It sucks and long term the new mechanism is the solution. I don't want anyone to think I am against the new mechanism. I'm for it. But I'd like to minimize the damage potential on the way there. When this initial conversion is done I'm pretty sure we can improve ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. So we don't need those horrible adapter ID tests and other magic that's going on in that driver. But that's phase two. My impression (at least for pvrusb2-driven devices) is that the later IR receivers require a completely different driver to work properly; one can't just bolt additional features into ir-kbd-i2c for this. In lirc's case, a different driver is in fact used. But you know this already. I haven't looked at ir-kbd-i2c in a while, but one other thing I seriously did not like about it was that the mapping of IR codes to key events was effectively hardcoded in the driver. That makes it difficult to make the same driver work with different kinds of remotes. Even if the bridge driver (e.g. pvrusb2) were to supply such a map, that's still wrong because it's within the realm of possibility that the user might actually want to use a different remote transmitter (provided it is compatible enough to work with the receiver hardware). The lirc architecture solves this easily via a conf file in userspace. In fact, lirc can map multiple mappings to a single receiver, permitting it to work concurrently with more than one remote. But is such a thing even possible with ir-kbd-i2c? I know this is one reason people tend to choose lirc. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
?!? 3. A given IR remote may be described by much more than what 'scan codes' it produces. I don't know a lot about IR, but looking at the typical lirc definition for a remote, there's obvious timing and protocol parameters as well. Just being able to swap scan codes around is not always going to be enough. 4. I imagine that the input event framework in the kernel has a means for programmatic mapping of scan codes to key codes, but looking at ir-kbd-i2c.c, it appears to only be selecting from among a very small set of kernel-compiled translation tables. I must be missing something here. In an earlier post (from Andy?) some history was dug up about ir-kbd-i2c.c. From what I understand, the only reason ir-kbd-i2c.c came into existence was because lirc was late in supporting 2.6.x series kernels and Gerd needed *something* to allow IR to work. So he created this module, knowing full well that it didn't cover all possible cases. Rather it covered the common cases he cared about. That was a while ago. And we need to do all the cases - or at least not mess up what already exists elsewhere that does handle the uncommon cases. The lirc drivers do work in 2.6. And apparently they were on the scene before ir-kbd-i2c.c, just unfortunately not in-tree. The lirc drivers really need to get into the kernel. From where I'm sitting the long term goal should be to get lirc into the kernel. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
pvrusb2 IR changes coming [was: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model]
Jean: Here's a description of what I've got on the front burner right now: 1. The pvrusb2 driver now can unambiguously know if it is dealing with a device that is known to have ir-kbd-i2c compatible IR capabilities. 2. There is a new module option, disable_autoload_ir_kbd, which if present and set to 1 will indicate that ir-kbd should not be loaded. 2. Based upon (1) and (2), the driver will optionally attempt to load ir-kbd using the code from your patch. 3. In the pvrusb2 case, the only i2c address that currently matters is 0x18 (though I have some suspicions about another case but that can be dealt with later), so I trimmed the probe list in the register function you had added. Since calling i2c_new_probed_device() for a non-existent target driver doesn't cause any harm, then merging the above now should not result in any kind of regression. So it can go in even before the rest of your changes. That I believe also removes the objection Mauro had - this way there's no issues / dependencies. I've tested this enough to know that it at least doesn't do any further harm. I will put this up in a changeset shortly. With all that said, we should not ignore lirc and instead do whatever is reasonable to help ensure it continues to work. Though admittedly there's been plenty of opportunity to update and this whole transition has been going on for a long time. The stuff I describe above should at least keep the pvrusb2 driver out of the fray for now. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for two pvrusb2 changesets. One sets up the ability to track what kind of IR receiver is expected, the other optionally autoloads ir-kbd-i2c based on that result and a module option that can be used to disable that autoloading. This is the result of what I had posted about an hour ago. It looks like a lot of lines, but it was all basically trivial stuff. Note that these changes are safe; nothing is regressed here and this does not depend on anyone else's changes. Even though that second changeset won't really do much until Jean's ir-kbd-i2c stuff is merged, the fact is that it won't cause any harm either. Since the pvrusb2 driver wasn't previously autoloading ir-kbd-i2c anyway, this change therefore breaks nothing. But it does have the desirable effect in that it should take me out of the IR debate for now and I can stop being a pain to Jean :-) Jean: I hope I didn't break any etiquette here. Though that second change is from me, the majority of the changeset really is from your patch to the pvrusb2 driver. I made changes to it so I didn't feel right in still trying to blame you for it ;-) Plus, if I were to hand it back to you for inclusion in your patch series then you would be dependant upon the pvrusb2 change I made to drive the decision about loading based on the device hardware. Since this change as a whole is mergeable without the rest of your changeset I felt it most expedient just to push this up now. -Mike - pvrusb2: Select, track, and report IR scheme in use with the device - pvrusb2: autoload ir-kbd when appropriate pvrusb2-devattr.c |1 + pvrusb2-devattr.h | 22 +++--- pvrusb2-hdw-internal.h |3 +++ pvrusb2-hdw.c | 18 +- pvrusb2-i2c-core.c | 40 ++-- 5 files changed, 66 insertions(+), 18 deletions(-) -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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://linuxtv.org/hg/~mcisely/pvrusb2
On Mon, 6 Apr 2009, Jean Delvare wrote: Hi Mike, I'll answer all your questions and express my concerns in this reply, to avoid spreading the info all around the discussion thread. On Mon, 6 Apr 2009 00:19:23 -0500 (CDT), Mike Isely wrote: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for two pvrusb2 changesets. One sets up the ability to track what kind of IR receiver is expected, Looks very good. The more we know about each board, the less probing we have to do, the better. the other optionally autoloads ir-kbd-i2c based on that result and a module option that can be used to disable that autoloading. Again, ir-kbd-i2c does _not_ auto-load. What my code (and now yours) does is instantiating an i2c device named ir-kbd. _If_ the ir-kbd-i2c driver is later loaded, it will bind to that device. We might let udev load the ir-kbd-i2c driver at some point in the future, but clearly we need to sort out the lirc case beforehand, otherwise some users will hit the problems you have anticipated, and we don't want this to happen. So, your module parameter is improperly named. Setting it to 1 does prevent the pvrusb2 driver from instantiating the ir-kbd device, and that's all. The module parameter is named disabled_autoload_ir_kbd, how is that wrong? The name is based on the internal receiver name ir-kbd. There's no [-_]i2c in the name. The parameter's description also does not reference ir-kbd-i2c by name either. I did it that way specifically for the reason you point out here. I was originally going to use the name that Hans had suggested but then decided otherwise because (1) I decided to follow your desire and make it a disable option, (2) Hans' suggested name did in fact encode the name ir-kbd-i2c in the module option. Speaking of this module parameter, I was a little worried at first that you wanted an inverted logic for it in pvrusb2 compared to what some other bridge drivers (saa7134, em28xx, cx231xx), but thinking a bit more about I came to the conclusion that it was OK because it matched the history of the pvrusb2 driver. Now I see that you followed their logic (enabled is the default) but you use a different module parameter name (disable_autoload_ir_kbd vs. disable_ir). I think there would be some value in sticking to a common name in all bridge drivers (like we have the standard video_nr module parameter.) That being said, I will not insist on this. My feeling is that this is all temporary anyway, because the removal of the legacy i2c model will break lirc and the main point is to decide how we will fix it. I'll post a separate summary with proposals. Depending on what we do, the module parameter you added is likely to become obsolete. I did want it to be an enable parameter, in order to match previous driver behavior. But whether it is an enable or a disable option, in one use-case somebody has to set it. So I relented and made it a disable option. This is the result of what I had posted about an hour ago. It looks like a lot of lines, but it was all basically trivial stuff. Note that these changes are safe; nothing is regressed here and this does not depend on anyone else's changes. Even though that second changeset won't really do much until Jean's ir-kbd-i2c stuff is merged, the fact is that it won't cause any harm either. Since the pvrusb2 driver wasn't previously autoloading ir-kbd-i2c anyway, this change therefore breaks nothing. For completeness, your second patch actually breaks the ir-kbd-i2c use case. Your code will instantiate a new-style ir-kbd device which the legacy ir-kbd-i2c can't use. As the instantiated device makes the address busy, the probing logic of legacy ir-kbd-i2c driver will skip it. Without my changes, all users will have to pass disable_autoload_ir_kbd=1, whether they want to use lirc or ir-kbd-i2c, otherwise they lose IR support. Well yes. I was saying no harm in the sense that everything that was possible before is still possible now, though perhaps with the module option set. But honestly that doesn't matter much, I think, because the idea is to merge my changes quickly. Yes, exactly. [...] This morning I actually realized another use-case that has been missed. It was likely an issue before anyway, but it got me thinking about this: If a user has multiple devices attached to one system, he probably won't want all of the corresponding IR receivers enabled - that would just trigger redundant input events. With a PCI-hosted ivtv device this is not really an issue - because there one can just decline to plug in the actual IR sensor. But with USB-hosted devices, the IR sensor is an integral part of the device and can't be unplugged. OK, well such a user could instead just choose to put a piece of tape over the window or stick all but one device in a box (and causing potential heat problems if it isn't ventilated
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Mon, 6 Apr 2009, Jean Delvare wrote: Hi Mike, Please note: I think the long post I just sent makes part of this discussion obsolete from a technical perspective. But still interesting from a functional perspective, which is why I am following up. I plan a reply to your RFC as well, probably later on tonight. On Mon, 6 Apr 2009 10:03:00 -0500 (CDT), Mike Isely wrote: On Mon, 6 Apr 2009, Jean Delvare wrote: Again, ir-kbd-i2c does _not_ auto-load. What my code (and now yours) does is instantiating an i2c device named ir-kbd. _If_ the ir-kbd-i2c driver is later loaded, it will bind to that device. We might let udev load the ir-kbd-i2c driver at some point in the future, but clearly we need to sort out the lirc case beforehand, otherwise some users will hit the problems you have anticipated, and we don't want this to happen. So, your module parameter is improperly named. Setting it to 1 does prevent the pvrusb2 driver from instantiating the ir-kbd device, and that's all. The module parameter is named disabled_autoload_ir_kbd, how is that wrong? The name is based on the internal receiver name ir-kbd. There's no [-_]i2c in the name. The parameter's description also does not reference ir-kbd-i2c by name either. I did it that way specifically for the reason you point out here. I was perfectly fine with the ir_kbd part. The part I complain about is autoload, because the original mechanism doesn't involve any autoloading. But from the viewpoint of a user of the pvrusb2 driver, that is in fact what will appear to happen. 1. User plugs in device. 2. Driver (pvrusb2) instantiates self. 3. Driver automatically attempts to load and bind ir-kbd-i2c to the IR receiver, hence autoload. Yes I know ir-kbd-i2c no longer autoloads itself; that is a major goal of the conversion. But with the pvrusb2 change to explicitly bind it, the behavior from the view of the user is still that of an autoload operation. I think we're just arguing semantics, but it's why I put autoload in the name. However given the realization below about multiple devices, I think I need to step back and look at this from a larger scope (e.g. make it an array, merge with the fairly clunky ir_mode switch already in the driver and clean that up, etc). [...] This morning I actually realized another use-case that has been missed. It was likely an issue before anyway, but it got me thinking about this: If a user has multiple devices attached to one system, he probably won't want all of the corresponding IR receivers enabled - that would just trigger redundant input events. With a PCI-hosted ivtv device this is not really an issue - because there one can just decline to plug in the actual IR sensor. But with USB-hosted devices, the IR sensor is an integral part of the device and can't be unplugged. OK, well such a user could instead just choose to put a piece of tape over the window or stick all but one device in a box (and causing potential heat problems if it isn't ventilated), but that approach is well, inelegant. I think this argues for a better solution in the bridge driver to selectively disable IR on a per-device instance basis. There's already some logic in the pvrusb2 driver to do this, but it's clumsy and wasn't intended to solve that particular use-case. I need to consider this further and do some cleanup. This use-case may actually suggest the disable option should be expanded and possibly made permanent. I agree. I presume that this is one of the reasons why some bridge drivers have a disable_ir parameter (the other reason being lirc). It would probably make sense to not only keep these module parameters even after lirc is merged into the kernel tree, but turn them into arrays, so that IR receivers can be disabled selectively. This would address the problem you just raised. But all this can be done after the conversion work it finished. I believe I can solve this for the pvrusb2 driver without entanglement with the conversion work underway. Pieces of the solution are already in the driver; I just need to clean this up. In any case, I'm not going to worry about it immediately. I've been neglecting some non-Linux tasks, like filing bills and finishing my tax return :-) -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [RFC] Anticipating lirc breakage
On Mon, 6 Apr 2009, Jean Delvare wrote: Hi all, In the light of recent discussions and planed changes to the i2c subsystem and the ir-kbd-i2c driver, I will try to summarize the situation and make some proposals. Note that I am really not sure what we want to do, so this is a true request for opinions. First of all, the original reason for these changes is that I want to get rid of the legacy i2c binding model. As far as IR support is concerned, this means two things: * The ir-kbd-i2c driver must be converted to the new i2c binding model. I have been working on this already. * The removal of the legacy model will break lirc_i2c and possibly other lirc drivers. These will have to be converted to the new i2c binding model as well. While discussing my changes to ir-kbd-i2c, I received objections that these would adversely affect lirc users, and proposals were made to work around this problem, either by the means of module parameters, or by adding per-card logic in the bridge drivers. While this temporarily addresses the conflict with lirc, I feel like it is wasted energy because the second point is much more critical for lirc users. I'm going to remove the legacy i2c model pretty soon now and lirc_i2c and friends will have to be updated. This means two things: It wasn't really wasting that much energy for me. The change was simple and now that you made me look at this issue more closely, I realize I need to do something more serious in the pvrusb2 driver anyway to enable better control over which IR receiver(s) are to be enabled when the user has multiple devices. So in the end for me at least, it wasn't a waste. * There is no point in refining the ir-kbd-i2c conversion for users of the current lirc drivers, because the removal of the legacy i2c model will break these drivers a lot more anyway. * We need to come up with a strategy that makes it possible for lirc modules to still work afterwards. This is not trivial because the new i2c binding model makes life much harder for rogue/out-of-tree i2c drivers (note, this is just a side effect, the new model was not designed with this in mind.) The main technical problems I see as far as converting lirc to the new i2c binding model is concerned are: * Going the .detect() route is not as flexible as it was beforehand. In particular, having per-board probed address lists is no longer possible. It is possible to filter the addresses on a per-board basis after the fact, but the probes will still be issued for all addresses. I seem to remember that probing random addresses did cause trouble in the past on some boards, so I doubt we want to go that route. This is the reason why I decided to NOT go the .detect() route for ir-kbd-i2c conversion. * If we don't use .detect(), the bridge drivers must instantiate the devices themselves. That's what my ir-kbd-i2c patches do. One requirement is then that the bridge drivers and the chip drivers agree on the i2c device name(s). This was true for ir-kbd-i2c, it is true for lirc as well. Where it becomes difficult is that lirc lives outside of the kernel, while bridge drivers live inside the kernel. This will make the changes more difficult to synchronize. Probably a good incentive for lirc developers to merge their drivers into the kernel tree. While I think we all agree that lirc drivers should be merged in the kernel tree, it is pretty clear that it won't happen tomorrow. And, more importantly, it won't happen before I get rid of the legacy i2c binding model. So we need to come up with a design which makes it possible to keep using out-of-tree lirc drivers. It doesn't need to be perfect, but it has to somewhat work for now. Yup. Totally agree. My initial proposal made bridge drivers create ir-kbd [1] I2C devices for the ir-kbd-i2c driver to use. Mike Isely changed this in the pvrusb2 bridge driver to only instantiate the devices for boards on which ir-kbd-i2c is known to work. While this makes sense for the current situation (lirc_i2c is a legacy i2c driver) it will break as soon as lirc_i2c is converted to a new-style i2c driver: the converted lirc_i2c driver will need I2C devices to bind to, and the pvrusb2 driver won't create them. Right, because we haven't addressed the question of still making possible the choice of which actual driver to load. The change I proposed and implemented (within the pvrusb2 driver) was just a simple low-risk attempt to allow for the status quo to still be possible within the pvrusb2 driver. That will work for _right this moment_, but once you've removed the legacy i2c binding mechanism, there's no longer any status quo to maintain. Same goes for cx18 boards, as Andy Walls and myself agreed to not create I2C devices for the IR receivers, because we know that ir-kbd-i2c doesn't support them. This made sense for the current situation, but the lirc_i2c
Re: [RFC] Anticipating lirc breakage
On Tue, 7 Apr 2009, Jean Delvare wrote: I'll rework my patch set to implement strategy #1 and post it when I'm done. As far as I can see this should be very similar to my original attempt, with just ir_video devices instead or ir-kbd devices, and also fixes for the minor issues that have been reported. Do you want me to include pvrusb2 in my new patch set, or should I still leave it to you? If you were to include pvrusb2, you would also need the changeset which expands the IR scheme handling to make it possible to correctly select when to bind the driver. But Mauro hasn't pulled that so you can't easily build on it right now. And as I understand it, the only real impact in the second changeset in the pending series is just the name of the module (i.e. change ir-kbd to ir_video). It's extra work for you to do this. So just let me deal with it. If my understanding above is correct, I'll just fix the second patch and the pvrusb2 driver should be ready to go for this. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ir-kbd-i2c: Switch to the new-style device binding model
I thought we were going to leave the pvrusb2 driver out of this since I've already got a change ready that also includes additional logic to take into account the properties of the hardware device (i.e. only activate ir-kbd-i2c when we know it has a chance of working). -Mike On Fri, 17 Apr 2009, Jean Delvare wrote: Let card drivers probe for IR receiver devices and instantiate them if found. Ultimately it would be better if we could stop probing completely, but I suspect this won't be possible for all card types. There's certainly room for cleanups. For example, some drivers are sharing I2C adapter IDs, so they also had to share the list of I2C addresses being probed for an IR receiver. Now that each driver explicitly says which addresses should be probed, maybe some addresses can be dropped from some drivers. Also, the special cases in saa7134-i2c should probably be handled on a per-board basis. This would be more efficient and less risky than always probing extra addresses on all boards. I'll give it a try later. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Hans Verkuil hverk...@xs4all.nl Cc: Andy Walls awa...@radix.net Cc: Mike Isely is...@pobox.com --- linux/drivers/media/video/bt8xx/bttv-i2c.c | 21 + linux/drivers/media/video/cx231xx/cx231xx-cards.c| 11 linux/drivers/media/video/cx231xx/cx231xx-i2c.c |3 linux/drivers/media/video/cx231xx/cx231xx.h |1 linux/drivers/media/video/cx23885/cx23885-i2c.c | 12 + linux/drivers/media/video/cx88/cx88-i2c.c| 13 + linux/drivers/media/video/em28xx/em28xx-cards.c | 20 + linux/drivers/media/video/em28xx/em28xx-i2c.c|3 linux/drivers/media/video/em28xx/em28xx-input.c |6 linux/drivers/media/video/em28xx/em28xx.h|1 linux/drivers/media/video/ir-kbd-i2c.c | 200 +++--- linux/drivers/media/video/ivtv/ivtv-i2c.c| 31 ++ linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c | 24 ++ linux/drivers/media/video/saa7134/saa7134-i2c.c |3 linux/drivers/media/video/saa7134/saa7134-input.c| 86 ++- linux/drivers/media/video/saa7134/saa7134.h |1 linux/include/media/ir-kbd-i2c.h |2 17 files changed, 244 insertions(+), 194 deletions(-) [...] -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
On Mon, 20 Apr 2009, Alexey Klimov wrote: [...] When trying to compile v4l-dvb tree under 2.6.30-rc2 (up-to-date) i have such error with pvr2 module: CC [M] /w/new/v4l-dvb/v4l/pvrusb2-hdw.o /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_upload_firmware1': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:1474: error: implicit declaration of function 'usb_settoggle' /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_hdw_load_modules': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:2133: warning: format not a string literal and no format arguments make[3]: *** [/w/new/v4l-dvb/v4l/pvrusb2-hdw.o] Error 1 make[2]: *** [_module_/w/new/v4l-dvb/v4l] Error 2 It's probably due to this git commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3444b26afa145148951112534f298bdc554ec789 I don't have idea how to fix it fast and correctly. This might explain things a bit. The following thread took place on linux-usb on 7-April: quote On Tue, 7 Apr 2009, Greg KH wrote: On Tue, Apr 07, 2009 at 05:31:55PM +, David Vrabel wrote: Wireless USB endpoint state has a sequence number and a current window and not just a single toggle bit. So allow HCDs to provide a endpoint_reset method and call this or clear the software toggles as required (after a clear halt). usb_settoggle() and friends are then HCD internal and are moved into core/hcd.h. You remove this api, yet the pvrusb2 driver used it, and you don't seem to have resolved the issue where it was calling it: diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c b/drivers/media/video/pvrusb2/pvrusb2-hdw.c index fa304e5..b86682d 100644 --- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c @@ -1418,7 +1418,6 @@ static int pvr2_upload_firmware1(struct pvr2_hdw *hdw) return ret; } - usb_settoggle(hdw-usb_dev, 0 0xf, !(0 USB_DIR_IN), 0); usb_clear_halt(hdw-usb_dev, usb_sndbulkpipe(hdw-usb_dev, 0 0x7f)); pipe = usb_sndctrlpipe(hdw-usb_dev, 0); Should usb_reset_endpoint() be called here instead? Speaking as the maintainer of that driver, I'm OK with accepting this as-is for now. This is a sequence that should not interfere with normal driver operation. I will look at this further a little later (not likely before the merge window closes) and if this change turns out to cause a problem I'll make a follow-up fix upstream. Acked-By: Mike Isely is...@pobox.com -Mike /quote So the kernel already has this; it just needs to be pulled back into v4l-dvb. It's an obvious trivial thing for now and I've acked it there. Obviously we're getting had here because you're compiling against a kernel snapshot that's been changed but v4l-dvb doesn't have the corresponding change in its local copy of the pvrusb2 driver. Part of the fun of synchronizing changes from different trees :-( Mauro: If you just want to take this as-is (or find the git commit and pull it down), I'm fine. Otherwise I'll set up a repo that you can pull from with this single-line change. The above changeset also has the following attributions: From: David Vrabel david.vra...@csr.com Signed-off-by: David Vrabel david.vra...@csr.com -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Jean, I had actually written out a longer, detailed, point-by-point reply earlier today, but before I could finish it I got interrupted with a crisis. And then another. And that's kind of how my day went. Now I'm finally back to this, but I have another e-mail debacle to immediately deal with (thank you pobox.com, not!) so I'm tossing that unfinished lengthy reply. I think I can sum this whole thing up very simply. Here's what I think should be happening: 1a. Your existing IR changeset, minus the pvrusb2 changes, should be merged. 1b. In parallel with (1a) I modify my pvrusb2 changeset to use the right module name and I adjust the driver option name to match. 2. My pvrusb2 changeset, with changes from (1b) is merged. 3. Andy's proposed change for ir_kbd_i2c to support additional IR devices is investigated and probably merged. 4. I test the changed ir_kbd_i2c against additional pvrusb2 devices known not to work previously with ir_kbd_i2c. If they work, then I will create a pvrusb2 patch to load ir_video in those cases as well as the cases already set up (which still won't cover all possible pvrusb2-driven devices). I think this satisfies the remaining issues, except that from between steps 1 and 2 ir_kbd_i2c won't work with the pvrusb2 driver. But you know, I'm OK with that. I expect (2) to happen within a few days after (1) so the impact should be minimal. It certainly won't escape into the kernel tree that way. In addition, my impression from the community of pvrusb2 users is that the preferred IR strategy is lirc anyway, and it's a foregone conclusion that they are all going to be, uh, impacted once your compatibility parts are gone from i2c. From where I'm sitting the gap from (1) to (2) is trivial compared to that impending mess - realize I'm not complaining since after all (a) it really falls to the lirc developers to fix that, (b) you do need to get your changes in, and (c) there's little I can do for lirc there except to keep it working as long as possible with the pvrusb2 driver. I'm just pointing out that I'm OK with the step 1 - 2 gap for the pvrusb2 driver because it's small and will be nothing compared to what's about to happen with lirc. If you still don't like any of that, well, then I give up. In that case, then merge your changes with the pvrusb2 changes included. I won't ack them, but I'll just deal with it later. Because while your changes might keep ir_kbd_i2c going, they will also immediately break the more-useful and apparently more-used lirc (by always binding ir_kbd_i2c even in cases in the pvrusb2 driver where it's known that it can't even work but lirc would have) which as far as I'm concerned is far worse than the step 1 - 2 gap above. But it's just another gap and I'll push another pvrusb2 changeset on top to clean it up. So just do whatever you think is best right now, if you disagree with the sequence above. Now I will go off and deal with the steamer that pobox.com has just handed me :-( -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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] pvrusb2: Don't use the internal i2c client list
On Thu, 30 Apr 2009, Jean Delvare wrote:
The i2c core used to maintain a list of client for each adapter. This
is a duplication of what the driver core already does, so this list
will be removed as part of a future cleanup. Anyone using this list
must stop doing so.
For pvrusb2, I propose the following change, which should lead to an
equally informative output. The only difference is that i2c clients
which are not a v4l2 subdev won't show up, but I guess this case is
not supposed to happen anyway.
It will happen for anything i2c used by v4l which itself is not really a
part of v4l. That would include, uh, lirc.
I will review and test this first chance I get which should be tomorrow.
-Mike
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mike Isely is...@pobox.com
---
Mike, can you please review and test this patch? Thanks.
linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c | 56
+--
1 file changed, 13 insertions(+), 43 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-04-30 16:52:32.0 +0200
+++ v4l-dvb/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c 2009-04-30
17:20:37.0 +0200
@@ -4920,65 +4920,35 @@ static unsigned int pvr2_hdw_report_clie
unsigned int tcnt = 0;
unsigned int ccnt;
struct i2c_client *client;
- struct list_head *item;
- void *cd;
const char *p;
unsigned int id;
- ccnt = scnprintf(buf, acnt, Associated v4l2-subdev drivers:);
+ ccnt = scnprintf(buf, acnt, Associated v4l2-subdev drivers and I2C
clients:\n);
tcnt += ccnt;
v4l2_device_for_each_subdev(sd, hdw-v4l2_dev) {
id = sd-grp_id;
p = NULL;
if (id ARRAY_SIZE(module_names)) p = module_names[id];
if (p) {
- ccnt = scnprintf(buf + tcnt, acnt - tcnt, %s, p);
+ ccnt = scnprintf(buf + tcnt, acnt - tcnt, %s:, p);
tcnt += ccnt;
} else {
ccnt = scnprintf(buf + tcnt, acnt - tcnt,
- (unknown id=%u), id);
+(unknown id=%u):, id);
tcnt += ccnt;
}
- }
- ccnt = scnprintf(buf + tcnt, acnt - tcnt, \n);
- tcnt += ccnt;
-
- ccnt = scnprintf(buf + tcnt, acnt - tcnt, I2C clients:\n);
- tcnt += ccnt;
-
- mutex_lock(hdw-i2c_adap.clist_lock);
- list_for_each(item, hdw-i2c_adap.clients) {
- client = list_entry(item, struct i2c_client, list);
- ccnt = scnprintf(buf + tcnt, acnt - tcnt,
-%s: i2c=%02x, client-name, client-addr);
- tcnt += ccnt;
- cd = i2c_get_clientdata(client);
- v4l2_device_for_each_subdev(sd, hdw-v4l2_dev) {
- if (cd == sd) {
- id = sd-grp_id;
- p = NULL;
- if (id ARRAY_SIZE(module_names)) {
- p = module_names[id];
- }
- if (p) {
- ccnt = scnprintf(buf + tcnt,
- acnt - tcnt,
- subdev=%s, p);
- tcnt += ccnt;
- } else {
- ccnt = scnprintf(buf + tcnt,
- acnt - tcnt,
- subdev= id %u),
- id);
- tcnt += ccnt;
- }
- break;
- }
+ client = v4l2_get_subdevdata(sd);
+ if (client) {
+ ccnt = scnprintf(buf + tcnt, acnt - tcnt,
+ %s @ %02x\n, client-name,
+ client-addr);
+ tcnt += ccnt;
+ } else {
+ ccnt = scnprintf(buf + tcnt, acnt - tcnt,
+ no i2c client\n);
+ tcnt += ccnt;
}
- ccnt = scnprintf(buf + tcnt, acnt - tcnt, \n);
- tcnt += ccnt;
}
- mutex_unlock(hdw-i2c_adap.clist_lock);
return tcnt;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
On Fri, 1 May 2009, Alexey Klimov wrote: Hello, On Mon, Apr 20, 2009 at 3:59 AM, Mike Isely is...@isely.net wrote: [...] So the kernel already has this; it just needs to be pulled back into v4l-dvb. It's an obvious trivial thing for now and I've acked it there. Obviously we're getting had here because you're compiling against a kernel snapshot that's been changed but v4l-dvb doesn't have the corresponding change in its local copy of the pvrusb2 driver. Part of the fun of synchronizing changes from different trees :-( Well, good to know that this thing is already fixed. I'm very sorry for the mess. No apology needed. Really - this mess wasn't caused by you. If anything I should have just immediately pulled that patch into hg and not waited for it to trickle back to Mauro. That would have avoided the error. So, all I can say is that I'm sorry you had to hit this! -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
Re: [PATCH 2/6] ir-kbd-i2c: Switch to the new-style device binding model
Jean: I have another idea that I think you'll like. I'm putting the finishing touches on the patch right now. What I have implements correct ir_video loading for the pvrusb2 driver. It also includes a lookup table (though with only 1 entry right now) to determine the proper I2C address and I use i2c_new_device() now instead of i2c_new_probed_device(). I've also renamed things to be ir_video everywhere instead of ir_kbd_i2c as was discussed. In particular the disable option is there like before, but now it's called disable_autoload_ir_video. So far this is exactly what I was saying before. But I'm also making one more change: the disable_autoload_ir_video option default value will - for now - be 1, i.e. everything above I just described starts off disabled. This means that the entire patch can be pulled _right_ _now_ without breaking anything at all, because the outward behavior is still unchanged. Then, when you're ready to bring your stuff in, all you need to do is include a 1-line change to pvrusb2-i2c-core.c to switch the default value of disable_autoload_ir_video back to 0, which now enables all the corresponding pvrusb2 changes that you need to avoid any breakage inside my driver. Just to be absolutely crystal clear, here's the change you will be able to do once these changes are in: diff -r 8d2e1361520c linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c --- a/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c Fri May 01 20:23:39 2009 -0500 +++ b/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c Fri May 01 20:24:23 2009 -0500 @@ -43,7 +43,7 @@ module_param_array(ir_mode, int, NULL, 0444); MODULE_PARM_DESC(ir_mode,specify: 0=disable IR reception, 1=normal IR); +static int pvr2_disable_ir_video; -static int pvr2_disable_ir_video = 1; module_param_named(disable_autoload_ir_video, pvr2_disable_ir_video, int, S_IRUGO|S_IWUSR); MODULE_PARM_DESC(disable_autoload_ir_video, So with all this, what I am setting up right now will cause no harm to the existing situation, requires no actual messing with module options, and once you're reading, just include the 1-line change above and you're set. There's no race here, no gap in IR handling. -Mike On Thu, 23 Apr 2009, Mike Isely wrote: Hi Jean, I had actually written out a longer, detailed, point-by-point reply earlier today, but before I could finish it I got interrupted with a crisis. And then another. And that's kind of how my day went. Now I'm finally back to this, but I have another e-mail debacle to immediately deal with (thank you pobox.com, not!) so I'm tossing that unfinished lengthy reply. I think I can sum this whole thing up very simply. Here's what I think should be happening: 1a. Your existing IR changeset, minus the pvrusb2 changes, should be merged. 1b. In parallel with (1a) I modify my pvrusb2 changeset to use the right module name and I adjust the driver option name to match. 2. My pvrusb2 changeset, with changes from (1b) is merged. 3. Andy's proposed change for ir_kbd_i2c to support additional IR devices is investigated and probably merged. 4. I test the changed ir_kbd_i2c against additional pvrusb2 devices known not to work previously with ir_kbd_i2c. If they work, then I will create a pvrusb2 patch to load ir_video in those cases as well as the cases already set up (which still won't cover all possible pvrusb2-driven devices). I think this satisfies the remaining issues, except that from between steps 1 and 2 ir_kbd_i2c won't work with the pvrusb2 driver. But you know, I'm OK with that. I expect (2) to happen within a few days after (1) so the impact should be minimal. It certainly won't escape into the kernel tree that way. In addition, my impression from the community of pvrusb2 users is that the preferred IR strategy is lirc anyway, and it's a foregone conclusion that they are all going to be, uh, impacted once your compatibility parts are gone from i2c. From where I'm sitting the gap from (1) to (2) is trivial compared to that impending mess - realize I'm not complaining since after all (a) it really falls to the lirc developers to fix that, (b) you do need to get your changes in, and (c) there's little I can do for lirc there except to keep it working as long as possible with the pvrusb2 driver. I'm just pointing out that I'm OK with the step 1 - 2 gap for the pvrusb2 driver because it's small and will be nothing compared to what's about to happen with lirc. If you still don't like any of that, well, then I give up. In that case, then merge your changes with the pvrusb2 changes included. I won't ack them, but I'll just deal with it later. Because while your changes might keep ir_kbd_i2c going, they will also immediately break the more-useful and apparently more-used lirc (by always binding ir_kbd_i2c even in cases in the pvrusb2 driver where it's known
Re: [PATCH] media: remove driver_data direct access of struct device
Acked-By: Mike Isely is...@pobox.com
Note #1: I am just acking the pvrusb2 part of this.
Note #2: I am immediately pulling the pvrusb2 part of these changes into
that driver.
-Mike
On Thu, 30 Apr 2009, Greg Kroah-Hartman wrote:
From: Greg Kroah-Hartman gre...@suse.de
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/media/dvb/firewire/firedtv-1394.c |4 ++--
drivers/media/dvb/firewire/firedtv-dvb.c|2 +-
drivers/media/video/pvrusb2/pvrusb2-sysfs.c | 22 +++---
3 files changed, 14 insertions(+), 14 deletions(-)
--- a/drivers/media/dvb/firewire/firedtv-1394.c
+++ b/drivers/media/dvb/firewire/firedtv-1394.c
@@ -225,7 +225,7 @@ fail_free:
static int node_remove(struct device *dev)
{
- struct firedtv *fdtv = dev-driver_data;
+ struct firedtv *fdtv = dev_get_drvdata(dev);
fdtv_dvb_unregister(fdtv);
@@ -242,7 +242,7 @@ static int node_remove(struct device *de
static int node_update(struct unit_directory *ud)
{
- struct firedtv *fdtv = ud-device.driver_data;
+ struct firedtv *fdtv = dev_get_drvdata(ud-device);
if (fdtv-isochannel = 0)
cmp_establish_pp_connection(fdtv, fdtv-subunit,
--- a/drivers/media/dvb/firewire/firedtv-dvb.c
+++ b/drivers/media/dvb/firewire/firedtv-dvb.c
@@ -268,7 +268,7 @@ struct firedtv *fdtv_alloc(struct device
if (!fdtv)
return NULL;
- dev-driver_data= fdtv;
+ dev_set_drvdata(dev, fdtv);
fdtv-device= dev;
fdtv-isochannel= -1;
fdtv-voltage = 0xff;
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -539,7 +539,7 @@ static void class_dev_destroy(struct pvr
sfp-attr_unit_number);
}
pvr2_sysfs_trace(Destroying class_dev id=%p,sfp-class_dev);
- sfp-class_dev-driver_data = NULL;
+ dev_set_drvdata(sfp-class_dev, NULL);
device_unregister(sfp-class_dev);
sfp-class_dev = NULL;
}
@@ -549,7 +549,7 @@ static ssize_t v4l_minor_number_show(str
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -561,7 +561,7 @@ static ssize_t bus_info_show(struct devi
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_bus_info(sfp-channel.hdw));
@@ -572,7 +572,7 @@ static ssize_t hdw_name_show(struct devi
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_type(sfp-channel.hdw));
@@ -583,7 +583,7 @@ static ssize_t hdw_desc_show(struct devi
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_desc(sfp-channel.hdw));
@@ -595,7 +595,7 @@ static ssize_t v4l_radio_minor_number_sh
char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -607,7 +607,7 @@ static ssize_t unit_number_show(struct d
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_get_unit_number(sfp-channel.hdw));
@@ -635,7 +635,7 @@ static void class_dev_create(struct pvr2
Re: [PULL] http://linuxtv.org/hg/~stoth/tda10048
Nice catch. Thanks. -Mike On Tue, 5 May 2009, Steven Toth wrote: In addition to this: Please pull from http://www.linuxtv.org/hg/~stoth/tda10048 - tda10048: Added option to block i2c gate control from other drivers. - pvrusb2: Ensure the PVRUSB2 disabled the i2c gate on the tda10048. dvb/frontends/tda10048.c| 222 +++- dvb/frontends/tda10048.h| 17 + video/cx23885/cx23885-dvb.c |4 video/pvrusb2/pvrusb2-devattr.c |3 4 files changed, 244 insertions(+), 2 deletions(-) This fixes a bug in the current PVRUSB2 tree where DVB-T is not working due to multiple repeaters upsteam of the tuner on the same i2c bus. - Steve Steven Toth wrote: Mauro, Please pull from http://www.linuxtv.org/hg/~stoth/tda10048 - tda10048: Add ability to select I/F at attach time. - cx23885: For tda10048 boards ensure we specify the I/F - pvrusb2: Ensure we specify the I/F at attach time. dvb/frontends/tda10048.c| 219 +++- dvb/frontends/tda10048.h| 14 + video/cx23885/cx23885-dvb.c |4 video/pvrusb2/pvrusb2-devattr.c |2 4 files changed, 237 insertions(+), 2 deletions(-) The TDA10048 used to have a hard-coded I/F, I've improved this to support different I/F's and ensured that all current bridge drivers specify their needs. Regards, - Steve -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-dev
Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2-dev for various pvrusb2 changesets. Several have to do with IR as previously discussed with Jean Delvare. He's waiting for these changes. Other stuff is more of a miscellaneous / cleanup nature. -Mike - pvrusb2: Select, track, and report IR scheme in use with the device - pvrusb2: Update to work with upcoming ir_video changes in v4l-dvb core - pvrusb2: Set ir_video autoloading to default disabled - pvrusb2: Bump up version advertised through v4l interface - pvrusb2: Don't use the internal i2c client list - pvrusb2: remove driver_data direct access of struct device - pvrusb2: Allocate a routing ID for future support of Terratec Grabster AV400 pvrusb2-devattr.c |1 pvrusb2-devattr.h | 23 +- pvrusb2-hdw-internal.h |3 + pvrusb2-hdw.c | 78 - pvrusb2-i2c-core.c | 53 +++-- pvrusb2-sysfs.c| 22 ++--- pvrusb2-v4l2.c |2 - 7 files changed, 106 insertions(+), 76 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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://linuxtv.org/hg/~mcisely/pvrusb2-dev
On Mon, 11 May 2009, Mauro Carvalho Chehab wrote: Em Mon, 11 May 2009 22:09:26 -0300 Mauro Carvalho Chehab mche...@infradead.org escreveu: Em Sat, 9 May 2009 16:49:31 -0500 (CDT) Mike Isely is...@isely.net escreveu: Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2-dev for various pvrusb2 changesets. Several have to do with IR as previously discussed with Jean Delvare. He's waiting for these changes. Other stuff is more of a miscellaneous / cleanup nature. Hmm... this one failed when importing on -git: Changeset: 11749 From: Greg Kroah-Hartman gre...@suse.de Commiter: Mike Isely is...@pobox.com Date: Fri May 01 22:36:33 2009 -0500 Subject: pvrusb2: remove driver_data direct access of struct device In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Priority: normal Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org $ patch -p1 -i 11749.patch patching file drivers/media/video/pvrusb2/pvrusb2-sysfs.c Reversed (or previously applied) patch detected! Assume -R? [n] It seems that you've got a Greg's patch, removed the parts that touch on other files, applied on your tree and asked me to merge it. Please, never do it, since this will cause merge problems when exporting the patches to git. Next time, just reply with an acked-by, and let Patchwork to add your ack on the original patch. I in fact did what you are asking for here (i.e. wait for it to show up on its own) before for another change that got rid of usb_settoggle(). It took a LONG time - WEEKS - for that fix to get back into v4l-dvb via the mechanism you just described. And this had the effect of breaking the v4l-dvb repository for a period of time when the kernel mainline then unpublished the usb_settoggle() function. I do NOT like to see that happen. That caused me to decide not to rely on what you are now telling me to do. I also disagree with this for another reason. What happens if, say, Greg generates a patch that I need before I can proceed with other changes? Do I just sit around and wait for it to trickle back before I can continue? That seems wrong. In addition in the past when there have been pvrusb2 changes generated from upstream you have asked if I was planning on pulling them in myself - which I've done in the past. It seems wrong on its face to tell me that I can't go get a patch that affects my driver. AND... In the case of the remove usb_settoggle() patch, I *DID* in fact add my acked-by to that patch. Greg dutifully took note of this and ensured it was part of the git patch. However when it got back into v4l-dvb, the acked-by attribution was missing. I complained about this to you and your response was that this was a fault of the pathway / mechanism and that I should basically accept this. So now you're telling me to do this anyway? Whatever. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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 0/8] ir-kbd-i2c conversion to the new i2c binding model (v3)
On Thu, 14 May 2009, Jean Delvare wrote: On Thu, 14 May 2009 21:25:02 +0200, Oldřich Jedlička wrote: On Wednesday 13 of May 2009 at 21:45:59, Jean Delvare wrote: Hi all, Here comes an update of my conversion of ir-kbd-i2c to the new i2c binding model. I've split it into 8 pieces for easier review. Firstly there is 1 preliminary patch: Hi Jean, works for me, as usual :-) I've used the all-in-one patch and the up-to-date v4l-dvb tree (compiled yesterday for completeness). Oldrich, thanks a lot for testing and reporting, this is very appreciated. Jean: I tried the all-in-one patch here on a PVR-USB2 24xxx model (slightly older v4l-dvb repo and 2.6.27.13 vanilla kernel) and it worked fine. I'll add an acked-by to the corresponding (trivial) pvrusb2 patch that you've posted. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
Re: [PATCH 8/8] pvrusb2: Instantiate ir_video I2C device by default
On Wed, 13 May 2009, Jean Delvare wrote:
Now that the ir-kbd-i2c driver has been converted to a new-style i2c
driver, we can instantiate the ir_video I2C device by default. The
pvr2_disable_ir_video is kept to disable the IR receiver, either
because the user doesn't use it, or for debugging purpose.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mike Isely is...@pobox.com
Acked-by: Mike Isely is...@pobox.com
---
linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- v4l-dvb.orig/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-05-13 18:05:54.0 +0200
+++ v4l-dvb/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-05-13 18:06:32.0 +0200
@@ -43,7 +43,7 @@ static int ir_mode[PVR_NUM] = { [0 ... P
module_param_array(ir_mode, int, NULL, 0444);
MODULE_PARM_DESC(ir_mode,specify: 0=disable IR reception, 1=normal IR);
-static int pvr2_disable_ir_video = 1;
+static int pvr2_disable_ir_video;
module_param_named(disable_autoload_ir_video, pvr2_disable_ir_video,
int, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(disable_autoload_ir_video,
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
SNR Signal Strength an d BER
I have the good fortune to be the 'lucky' owner of an stb0899/stb6100 based DVB card. Whilst the performance of the card is fine, at least as good as the two other s1 TT cards I have, I find it really frustrating that I can't use it in the way that I can the other two. I use them, together with the femon and rotor plugins, to tune up my roof mounted dishes. with the s1 cards I can see that I am getting closer from the displays, but with the s2.. nothing. I have been keeping my eye on the list for ages hoping that there will be some advancement in this area and although there was quite some discussion in March about the right way to interpret these stats., that dried up at the end of March with nothing further since. I am only a User having no development skills so can't help in that area but I do know that I want measurements that get bigger as dish alignment gets better. I really don't give a knack what units are used. I don't want to start world war 3 ( or even another interminable and seemingly fruitless discussion ) but can someone in the development team tell me what is being done, if anything, to incorporate SNR SS and BER in STB0899/STB6100 drivers. Lets face it these drivers have been around for quite some time and my guess would be that Technotrend cards represent a fair proportion of the total out there. 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: [PULL] http://kernellabs.com/hg/~stoth/tda10048-merge/
I see no issues here with the pvrusb2 part of it... Acked-by: Mike Isely is...@pobox.com On Wed, 20 May 2009, Steven Toth wrote: Mauro, Please pull from http://kernellabs.com/hg/~stoth/tda10048-merge/ - TDA10048: Ensure the I/F changes during DVB-T 6/7/8 bandwidth changes. - cx23885: Ensure we specify I/F's for all bandwidths - pvrusb2: Ensure we specify I/F's for all bandwidths - TDA10048: Missing two I/F's / Pll combinations from the PLL table - cx23885: fix tda10048 IF frequencies for the Hauppauge WinTV-HVR1210 dvb/frontends/tda10048.c| 188 +--- dvb/frontends/tda10048.h|6 video/cx23885/cx23885-dvb.c |8 video/pvrusb2/pvrusb2-devattr.c |4 4 files changed, 139 insertions(+), 67 deletions(-) This was regression tested on the following products. HVR-1900, HVR-1200 and HVR-1700. Thanks -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: s5h1411_readreg: readreg error (ret == -5)
On Sun, 7 Jun 2009, Roger wrote: From looking at linux/drivers/media/dvb/frontends/s5h1411.c, The s5h1411_readreg wants to see 2 but is getting -5 from the i2c bus. --- Snip --- s5h1411_readreg: readreg error (ret == -5) pvrusb2: unregistering DVB devices device: 'dvb0.net0': device_unregister --- Snip --- What exactly does this mean? Roger: It means that the module attempted an I2C transfer and the transfer failed. The I2C adapter within the pvrusb2 driver will return either the number of bytes that it transferred or a failure code. The failure code, as is normal convention in the kernel, will be a negated errno value. Thus the expected value of 2 would be the fact that it probably tried a 2 byte transfer, while the actual value returned of -5 indicate an EIO error, which is what the pvrusb2 driver will return when the underlying I2C transaction has failed. Of course the real question is not that it failed but why it failed. And for that I unfortunately do not have an answer. It's possible that the s5h1411 driver did something that the chip didn't like and the chip responded by going deaf on the I2C bus. More than a few I2C-driven parts can behave this way. It's also possible that the part might have been busy and unable to respond - but usually in that case the driver for such a part will be written with this in mind and will know how / when to communicate with the hardware. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: s5h1411_readreg: readreg error (ret == -5)
On Thu, 11 Jun 2009, Steven Toth wrote: Mike Isely wrote: On Sun, 7 Jun 2009, Roger wrote: From looking at linux/drivers/media/dvb/frontends/s5h1411.c, The s5h1411_readreg wants to see 2 but is getting -5 from the i2c bus. --- Snip --- s5h1411_readreg: readreg error (ret == -5) pvrusb2: unregistering DVB devices device: 'dvb0.net0': device_unregister --- Snip --- What exactly does this mean? Roger: It means that the module attempted an I2C transfer and the transfer failed. The I2C adapter within the pvrusb2 driver will return either the number of bytes that it transferred or a failure code. The failure code, as is normal convention in the kernel, will be a negated errno value. Thus the expected value of 2 would be the fact that it probably tried a 2 byte transfer, while the actual value returned of -5 indicate an EIO error, which is what the pvrusb2 driver will return when the underlying I2C transaction has failed. Of course the real question is not that it failed but why it failed. And for that I unfortunately do not have an answer. It's possible that the s5h1411 driver did something that the chip didn't like and the chip responded by going deaf on the I2C bus. More than a few I2C-driven parts can behave this way. It's also possible that the part might have been busy and unable to respond - but usually in that case the driver for such a part will be written with this in mind and will know how / when to communicate with the hardware. Roger: Another possibility, although I don't know the PVRUSB2 driver too well, the s5h1411 is being held in reset when the driver unloads _AFTER_ the last active use was analog video (assuming the s5h1411 is floated in reset as the FX2 input port might be shared with the analog encoder) Good point. The pvrusb2 driver is not currently doing anything specific - or at least deliberate - via the FX2 to move that part in/out of reset. (Of course, I am issuing FX2 commands to shift modes and that might in turn be triggering other things.) But even if I did do something specific, what kind of impact is that likely to do on the corresponding, blissfully ignorant, driver? This actually drives towards a larger issue - the pvrusb2 driver works with various V4L-only sub-devices, e.g. cx25840, which have no relevance in digital mode but I can't really control when that corresponding driver is enabled / disabled. So if I have to take an extra step to physically disable a chip when in digital mode, then this might impact the sub-driver which otherwise is going to have no clue what is really going on. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: s5h1411_readreg: readreg error (ret == -5)
I am unable to reproduce the s5h1411 error here. However my HVR-1950 loads the s5h1409 module - NOT s5h1411.ko; I wonder if Hauppauge has changed chips on newer devices and so you're running a different tuner module. That would explain the different behavior. Unfortunately it also means it will be very difficult for me to track the problem down here since I don't have that device variant. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: s5h1411_readreg: readreg error (ret == -5)
Well now I feel like an idiot. Thanks for pointing that out in my own
code :-)
Still digging through this.
-Mike
On Fri, 12 Jun 2009, Andy Walls wrote:
On Fri, 2009-06-12 at 15:33 -0500, Mike Isely wrote:
I am unable to reproduce the s5h1411 error here.
However my HVR-1950 loads the s5h1409 module - NOT s5h1411.ko; I wonder
if Hauppauge has changed chips on newer devices and so you're running a
different tuner module.
The digital demodulator driver to use is hardcoded in pvrusb2-devattr.c:
static const struct pvr2_dvb_props pvr2_750xx_dvb_props = {
.frontend_attach = pvr2_s5h1409_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
static const struct pvr2_dvb_props pvr2_751xx_dvb_props = {
.frontend_attach = pvr2_s5h1411_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
...
static const struct pvr2_device_desc pvr2_device_750xx = {
.description = WinTV HVR-1950 Model Category 750xx,
...
.dvb_props = pvr2_750xx_dvb_props,
#endif
};
...
static const struct pvr2_device_desc pvr2_device_751xx = {
.description = WinTV HVR-1950 Model Category 751xx,
...
.dvb_props = pvr2_751xx_dvb_props,
#endif
};
That would explain the different behavior.
Unfortunately it also means it will be very difficult for me to track
the problem down here since I don't have that device variant.
If you have more than 1 HVR-1950, maybe one is a 751xx variant.
When I ran into I2C errors often, it was because of PCI bus errors
screwing up the bit banging. Obviously, that's not the case here.
-Andy
-Mike
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-dev
[sorry, reposted with corrected subject tag] Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2-dev for a number of pvrusb2 driver fixes. The first two in particular are high-priority critical fixes that clean up a nasty regression involving analog capture on the HVR-1950 and the older 24xxx model series. It would be good to see those at least backported to a 2.6.30.x release. - pvrusb2: Fix hardware scaling when used with cx25840 - pvrusb2: Re-fix hardware scaling on video standard change - pvrusb2: Change initial default frequency setting - pvrusb2: Improve handling of routing schemes - pvrusb2: De-obfuscate code which handles routing schemes pvrusb2-audio.c | 14 ++- pvrusb2-cs53l32a.c| 26 +++-- pvrusb2-cx2584x-v4l.c | 39 +--- pvrusb2-hdw.c | 60 -- pvrusb2-video-v4l.c | 37 +- 5 files changed, 98 insertions(+), 78 deletions(-) -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-20091011
Mauro: Please from http://linuxtv.org/hg/~mcisely/pvrusb2-20091011 for a few various pvrusb2 fixes / improvements. No critical bug fixes here, just a bunch of little things: - pvrusb2: Make more info available to udev - pvrusb2: Soften encoder warning message - pvrusb2: Improve diagnostic info on driver initialization failure - pvrusb2: Report hardware description to kernel log upon initialization - pvrusb2: Add hardware description to debuginfo output - pvrusb2: Fix redundant message on driver initialization failure (missing break) - pvrusb2: Cosmetic kernel log tweak pvrusb2-debugifc.c |3 +++ pvrusb2-encoder.c |5 - pvrusb2-hdw-internal.h |1 + pvrusb2-hdw.c | 33 - pvrusb2-v4l2.c | 21 - 5 files changed, 52 insertions(+), 11 deletions(-) -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: Details about DVB frontend API
On Friday 23 October 2009 06:13:30 Jean Delvare wrote: Hi folks, I am looking for details regarding the DVB frontend API. I've read linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS commands return, however it does not give any information about how the returned values should be interpreted (or, seen from the other end, how the frontend kernel drivers should encode these values.) If there documentation available that would explain this? For example, the signal strength. All I know so far is that this is a 16-bit value. But then what? Do greater values represent stronger signal or weaker signal? Are 0x and 0x special values? Is the returned value meaningful even when FE_HAS_SIGNAL is 0? When FE_HAS_LOCK is 0? Is the scale linear, or do some values have well-defined meanings, or is it arbitrary and each driver can have its own scale? What are the typical use cases by user-space application for this value? That's the kind of details I'd like to know, not only for the signal strength, but also for the SNR, BER and UB. Without this information, it seems a little difficult to have consistent frontend drivers. Thanks, I have tried on two occasions to engage the the author of my particular driver as to how to implement a patch and use femon with no response. Its good that there is some movement at last which might get a result. I've said before I don't really care too much about spot on accuracy but rather a scale that increases as you get closer to a lock. I can imagine there are loads of users out there who rely on the output of things like femon and vdr-rotor to tune their equipment and with S2 cards like both of mine they are knackered so to speak. 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-20091011
On Thu, 29 Oct 2009, Mauro Carvalho Chehab wrote: Em Sun, 11 Oct 2009 22:53:14 -0500 (CDT) Mike Isely is...@isely.net escreveu: Mauro: Please from http://linuxtv.org/hg/~mcisely/pvrusb2-20091011 for a few various pvrusb2 fixes / improvements. No critical bug fixes here, just a bunch of little things: - pvrusb2: Make more info available to udev - pvrusb2: Soften encoder warning message - pvrusb2: Improve diagnostic info on driver initialization failure - pvrusb2: Report hardware description to kernel log upon initialization - pvrusb2: Add hardware description to debuginfo output - pvrusb2: Fix redundant message on driver initialization failure (missing break) - pvrusb2: Cosmetic kernel log tweak Committed. Please fix the existing CodingStyle erros added on this changeset on a next pull request: We've had this discussion many times in the past. I am not going to have that debate yet again. These will NOT be changed. -Mike ERROR: trailing statements should be on next line #26: FILE: linux/drivers/media/video/pvrusb2/pvrusb2-v4l2.c:919: + if (!dip) return; + if (!dip) return; ERROR: trailing statements should be on next line #27: FILE: linux/drivers/media/video/pvrusb2/pvrusb2-v4l2.c:920: + if (!dip-devbase.parent) return; + if (!dip-devbase.parent) return; Cheers, Mauro -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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/3] em-x270: don't use pxa_camera init() callback
Antonio Ospite wrote:
pxa_camera init() is going to be removed.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
arch/arm/mach-pxa/em-x270.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
Acked-by: Mike Rapoport m...@compulab.co.il
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index aec7f42..f71f34c 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -967,7 +967,7 @@ static inline void em_x270_init_gpio_keys(void) {}
#if defined(CONFIG_VIDEO_PXA27x) || defined(CONFIG_VIDEO_PXA27x_MODULE)
static struct regulator *em_x270_camera_ldo;
-static int em_x270_sensor_init(struct device *dev)
+static int em_x270_sensor_init(void)
{
int ret;
@@ -996,7 +996,6 @@ static int em_x270_sensor_init(struct device *dev)
}
struct pxacamera_platform_data em_x270_camera_platform_data = {
- .init = em_x270_sensor_init,
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
.mclk_10khz = 2600,
@@ -1049,8 +1048,10 @@ static struct platform_device em_x270_camera = {
static void __init em_x270_init_camera(void)
{
- pxa_set_camera_info(em_x270_camera_platform_data);
- platform_device_register(em_x270_camera);
+ if (em_x270_sensor_init() == 0) {
+ pxa_set_camera_info(em_x270_camera_platform_data);
+ platform_device_register(em_x270_camera);
+ }
}
#else
static inline void em_x270_init_camera(void) {}
--
Sincerely yours,
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
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-20091124
Mauro: Please from http://linuxtv.org/hg/~mcisely/pvrusb2-20091124 for the following pvrusb2 driver fixes / improvements: - pvrusb2: Support 16KB FX2 firmware - pvrusb2: Support manual extraction of 16KB FX2 firmware - pvrusb2: Shorten device hardware description text to work around V4L shortcoming - pvrusb2: Bind I2C address 0x71 for Zilog IR devices - pvrusb2: Cosmetic tweak to minimize size_t exposure - pvrusb2: Fix lingering 16KB FX2 Firmware issues pvrusb2-debugifc.c | 14 +- pvrusb2-devattr.c | 13 - pvrusb2-devattr.h |1 + pvrusb2-hdw.c | 44 +--- pvrusb2-hdw.h |2 +- pvrusb2-i2c-core.c |1 + 6 files changed, 49 insertions(+), 26 deletions(-) The 16KB fixes are pretty important - Hauppauge has updated the FX2 firmware for HVR-1950 and HVR-1900 devices such that it is 16KB in size now. Unfortunately the driver for years had been enforcing the size to be 8KB which made it unable to load the newer firmware. This causes a problem for new users of the driver since the driver CD from Hauppauge contains this newer firmware. With the 16KB fixes this problem is solved. They are marked high priority. Thanks, -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PULL for 2.6.32] V4L/DVB updates
On Sat, 28 Nov 2009, Hans Verkuil wrote: On Friday 27 November 2009 22:40:01 Stefan Lippers-Hollmann wrote: Hi On Friday 27 November 2009, Mauro Carvalho Chehab wrote: Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For the following drivers and building fixes: - radio-gemtek-pci: fix double mutex_lock - v4l: add more missing linux/sched.h includes - soc-camera: properly initialise the device object when reusing - soc-camera: sh_mobile_ceu_camera: call pm_runtime_disable - em28xx: fix Reddo DVB-C USB TV Box GPIO - davinci: remove stray duplicate config pointer - SMS_SIANO_MDTV should depend on HAS_DMA - cxusb: Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) - sh_mobile_ceu_camera: fix compile warning - Fix wrong parameter order in memset [...] Please consider cherry picking the following two patches from Hans Verkuil [1]: - add the missing s2250-loader.h - s2250 mutex patch Good catch. Mauro, can you please add these two as well for 2.6.32? I'm sure I marked these two as high-prio patches. This staging driver is actively being used and developed so this regression should be fixed. Mauro: I had also posted up two high priority pvrusb2 patches that should really be cherry-picked for 2.6.32. You've already pulled them into v4l/dvb and I did mark them as high priority at the time. These patches enable use of FX2 microcontroller firmware that is 16KB in size. Hauppauge is no longer shipping 8KB firmware for HVR-1950 and HVR-1900 and without these changes then those devices won't work AT ALL in kernel 2.6.32. You can find these within the v4l-dvb Mercurial repository here: Changeset 13495:87c3853fe2b3 Subject: pvrusb2: Support 16KB FX2 firmware http://linuxtv.org/hg/v4l-dvb/rev/87c3853fe2b3 Changeset 13500:d4c418d4b25c Subject: pvrusb2: Fix lingering 16KB FX2 Firmware issues http://linuxtv.org/hg/v4l-dvb/rev/d4c418d4b25c I do not believe these patches have any ordering dependencies with other patches, though between the two the second one technically should come after the first. Thanks, -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
