Re: gpsca kernel BUG when disconnecting camera while streaming with mmap (2.6.29-rc8)
You did not tell which version of gspca you use. If it is the one of a kernel older than 2.6.30, you should update. Also, may this problem be reproduced? 2.6.29 isn't good enough, you need the patch at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d08e2ce0ebb38f2b66d875a09ebab3ed548354ee which only hit Linus' tree 3 days ago. I just tested 2.6.29 with http://linuxtv.org/hg/~jfrancois/gspca/ bz2 tarball named gspca-d8d701594f71.tar.bz2 installed over it, and it works (with higher framerate): * VIDIOC_QBUF and VIDIOC_DQBUF no longer gives EAGAIN when device goes missing * VIDIOC_STREAMOFF does no longer make the kernel oops on if device is missing. Stian Skjelstad -- 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: When is a wake_up() not a wake up?
On Fri, 3 Apr 2009, Andy Walls wrote:
1. A work queue thread or read() call needs to send a command to the
CX23418 using the cx18_api_call() function
2. It fills out a mailbox with a command for the CX23418
3. It prepares to wait, just in case a wait is needed
4. A SW1 interrupt is sent to the CX23418 telling it a mailbox is ready
5. The ack filed in the mailbox, a PCI MMIO location, is checked to see
if the mailbox was ack'ed already
6. If not, schedule_timeout() for up to 10 msecs (a near eternity...)
7. Clean up the wait and move on
10ms isn't that long. With a 100 HZ kernel it's only one jiffie. The
shortest time msleep() can sleep on a 100 HZ kernel is 20 ms.
Is it possible that it's simply taking more than 10 ms for your process to
get run?
Mar 31 23:36:56 palomino kernel: cx18-0: irq: sending interrupt SW1: 8 to
send CX18_CPU_DE_SET_MDL
Mar 31 23:36:56 palomino kernel: cx18-0: api: scheduling to wait for ack of
CX18_CPU_DE_SET_MDL: req 51267 ack 51266, pid 21092, state 2
Mar 31 23:36:56 palomino kernel: cx18-0: irq: received interrupts SW1: 0
SW2: 8 HW2: 0
Mar 31 23:36:56 palomino kernel: cx18-0: irq: Wake up initiated on pid 21092
in state 2
Mar 31 23:36:56 palomino kernel: cx18-0: irq: Wake up succeeded on pid
21092, state 2 - 0
Mar 31 23:36:56 palomino kernel: cx18-0: api: done wait for ack of
CX18_CPU_DE_SET_MDL: req 51267 ack 51267, current pid 21092, current state 0,
state 0
Mar 31 23:36:56 palomino kernel: cx18-0: warning: failed to be awakened upon
RPU acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
Try some higher resolution time stamps, you can't really tell much about
when things are happening.
Here's some code I wrote to do it on x86.
#include linux/calc64.h
#define MHZ 1666.787
#define INT (unsigned int)(MHZ * (112) + 0.5)
#define FRAC(unsigned int)(MHZ * (121) / 1000.0 + 0.5)
#define timestamp(str, args...) { u64 _time; u32 _rem; rdtscll(_time); \
_time = (_time - starttime)12; \
_rem = do_div(_time, INT); \
printk(%s - %u.%03u us str \n, __func__, \
(unsigned int)_time, (_rem 9) / FRAC , ## args); }
static u64 starttime;
Change MHZ to what /proc/cpuinfo tells you. Call 'rdtscll(starttime)' some
time when your driver inits or a device gets opened or something like that.
Makes the time stamps easier to read when they start near zero.
--
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/3] FM Transmitter driver
Hello, Am Freitag, 3. April 2009 12:12 schrieb Eduardo Valentin: On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: Hi Hans, On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. Yes, here is a little description of them: Pilot is an audible tone sent by the device. pilot_frequency - Configures the frequency of the stereo pilot tone. pilot_deviation - Configures pilot tone frequency deviation level. pilot_enabled - Enables or disables the pilot tone feature. The si4713 device is capable of applying audio compression to the transmitted signal. acomp_enabled - Enables or disables the audio dynamic range control feature. acomp_gain - Sets the gain for audio dynamic range control. acomp_threshold - Sets the threshold level for audio dynamic range control. acomp_attack_time - Sets the attack time for audio dynamic range control. acomp_release_time - Sets the release time for audio dynamic range control. Limiter setups audio deviation limiter feature. Once a over deviation occurs, it is possible to adjust the front-end gain of the audio input and always prevent over deviation. limiter_enabled - Enables or disables the limiter feature. limiter_deviation - Configures audio frequency deviation level. limiter_release_time - Sets the limiter release time. power_level - Sets the output power level for signal transmission. Hmm, there are two ways to implement these: either make a bunch of VIDIOC's for each of these categories, or use extended controls to set all these values. I'm hardly an expert on FM transmitters, but it all seems reasonable to me (i.e., not too specific for this chip). I am leaning towards extended controls, since that's so easy to extend if needed in the future. And I still intend to add sysfs support to controls in the future. On the other hand, it's a bit harder to use compared to normal VIDIOCs. Could you please explain more about extended controls vs. VIDIOC's? Pointing drivers which uses one of those also would be worth. But yes, looks like moving this properties to some sort of v4l2 control looks better implementation. RDS related rds_enabled - Enables or disables the RDS feature. rds_ps_name - Sets the RDS ps name field for transmission. rds_radio_text - Sets the RDS radio text for transmission. rds_pi - Sets the RDS PI field for transmission. rds_pty - Sets the RDS PTY field for transmission. So you set the fields and the RDS encoder will just start using them? Once you have rds_enabled set, yes, it will transmit them. This too can be done with controls (needs some work, though, to support string controls). Yes, true. Region related Setting region will affect other region properties. region_bottom_frequency region_channel_spacing region_preemphasis region_top_frequency I do not know enough about FM transmissions to judge this. Are these region properties something that is regulated by some standards commision? Do they also apply when you modulate this over a TV/radio cable system? Do you have some documentation or links that I can look at to learn more about this? stereo_enabled - Enables or disables stereo mode. How does one pass the audio and rds data to the driver? Note that for 2.6.31 we will finalize the V4L2 RDS decoder API (I recently posted an RFC for that, but I haven't had the time to implement the few changes needed). It would be nice if rds modulator support would be modeled after this demodulator API if possible. I see. This is good. I think the best way is to have a rds modulator interface. This driver have implemented it as sys properties, as described above. I don't think there is that much overlap, though. The similarities are probably limited to some flags. Does region information really belong in the driver? Perhaps
[PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model
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, -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] cx18: Fix the handling of i2c bus registration error
* Return actual error values as returned by the i2c subsystem, rather
than 0 or 1.
* If the registration of the second bus fails, unregister the first one
before exiting, otherwise we are leaking resources.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
---
linux/drivers/media/video/cx18/cx18-i2c.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c 2009-03-01
16:09:09.0 +0100
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-03
18:45:18.0 +0200
@@ -214,7 +214,7 @@ static struct i2c_algo_bit_data cx18_i2c
/* init + register i2c algo-bit adapter */
int init_cx18_i2c(struct cx18 *cx)
{
- int i;
+ int i, err;
CX18_DEBUG_I2C(i2c init\n);
for (i = 0; i 2; i++) {
@@ -273,8 +273,18 @@ int init_cx18_i2c(struct cx18 *cx)
cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL,
core, reset, (u32) CX18_GPIO_RESET_I2C);
- return i2c_bit_add_bus(cx-i2c_adap[0]) ||
- i2c_bit_add_bus(cx-i2c_adap[1]);
+ err = i2c_bit_add_bus(cx-i2c_adap[0]);
+ if (err)
+ goto err;
+ err = i2c_bit_add_bus(cx-i2c_adap[1]);
+ if (err)
+ goto err_del_bus_0;
+ return 0;
+
+ err_del_bus_0:
+ i2c_del_adapter(cx-i2c_adap[0]);
+ err:
+ return err;
}
void exit_cx18_i2c(struct cx18 *cx)
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ir-kbd-i2c: Don't use i2c_client.name for our own needs
In the standard device driver binding model, the name field of
struct i2c_client is used to match devices to their drivers, so we
must stop using it for internal purposes. Define a separate field
in struct IR_i2c as a replacement, and use it.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/cx231xx/cx231xx-input.c |2 +-
linux/drivers/media/video/em28xx/em28xx-cards.c |6 +++---
linux/drivers/media/video/em28xx/em28xx-input.c |2 +-
linux/drivers/media/video/ir-kbd-i2c.c|5 +++--
linux/drivers/media/video/saa7134/saa7134-input.c | 12 ++--
linux/include/media/ir-kbd-i2c.h |1 +
6 files changed, 15 insertions(+), 13 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-input.c
2009-03-13 09:59:49.0 +0100
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-input.c 2009-04-03
19:02:28.0 +0200
@@ -37,7 +37,7 @@ MODULE_PARM_DESC(ir_debug, enable debug
#define i2cdprintk(fmt, arg...) \
if (ir_debug) { \
- printk(KERN_DEBUG %s/ir: fmt, ir-c.name , ## arg); \
+ printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
}
#define dprintk(fmt, arg...) \
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-cards.c
2009-04-03 14:18:26.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-cards.c 2009-04-03
18:56:40.0 +0200
@@ -1921,19 +1921,19 @@ void em28xx_set_ir(struct em28xx *dev, s
case (EM2820_BOARD_TERRATEC_CINERGY_250):
ir-ir_codes = ir_codes_em_terratec;
ir-get_key = em28xx_get_key_terratec;
- snprintf(ir-c.name, sizeof(ir-c.name),
+ snprintf(ir-name, sizeof(ir-name),
i2c IR (EM28XX Terratec));
break;
case (EM2820_BOARD_PINNACLE_USB_2):
ir-ir_codes = ir_codes_pinnacle_grey;
ir-get_key = em28xx_get_key_pinnacle_usb_grey;
- snprintf(ir-c.name, sizeof(ir-c.name),
+ snprintf(ir-name, sizeof(ir-name),
i2c IR (EM28XX Pinnacle PCTV));
break;
case (EM2820_BOARD_HAUPPAUGE_WINTV_USB_2):
ir-ir_codes = ir_codes_hauppauge_new;
ir-get_key = em28xx_get_key_em_haup;
- snprintf(ir-c.name, sizeof(ir-c.name),
+ snprintf(ir-name, sizeof(ir-name),
i2c IR (EM2840 Hauppauge));
break;
case (EM2820_BOARD_MSI_VOX_USB_2):
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-input.c
2009-03-13 09:59:49.0 +0100
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-input.c 2009-04-03
18:56:40.0 +0200
@@ -41,7 +41,7 @@ MODULE_PARM_DESC(ir_debug, enable debug
#define i2cdprintk(fmt, arg...) \
if (ir_debug) { \
- printk(KERN_DEBUG %s/ir: fmt, ir-c.name , ## arg); \
+ printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
}
#define dprintk(fmt, arg...) \
--- v4l-dvb.orig/linux/drivers/media/video/ir-kbd-i2c.c 2009-03-13
09:59:49.0 +0100
+++ v4l-dvb/linux/drivers/media/video/ir-kbd-i2c.c 2009-04-03
18:56:40.0 +0200
@@ -346,6 +346,7 @@ static int ir_attach(struct i2c_adapter
ir-c.adapter = adap;
ir-c.addr= addr;
+ snprintf(ir-c.name, sizeof(ir-c.name), ir-kbd);
i2c_set_clientdata(ir-c, ir);
@@ -419,7 +420,7 @@ static int ir_attach(struct i2c_adapter
}
/* Sets name */
- snprintf(ir-c.name, sizeof(ir-c.name), i2c IR (%s), name);
+ snprintf(ir-name, sizeof(ir-name), i2c IR (%s), name);
ir-ir_codes = ir_codes;
/* register i2c device
@@ -444,7 +445,7 @@ static int ir_attach(struct i2c_adapter
/* init + register input device */
ir_input_init(input_dev, ir-ir, ir_type, ir-ir_codes);
input_dev-id.bustype = BUS_I2C;
- input_dev-name = ir-c.name;
+ input_dev-name = ir-name;
input_dev-phys = ir-phys;
err = input_register_device(ir-input);
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-03-01 16:09:10.0 +0100
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-04-03
18:56:40.0 +0200
@@ -60,7 +60,7 @@ MODULE_PARM_DESC(disable_other_ir, disa
#define dprintk(fmt, arg...) if (ir_debug) \
printk(KERN_DEBUG %s/ir: fmt, dev-name , ## arg)
#define i2cdprintk(fmt, arg...)if (ir_debug) \
- printk(KERN_DEBUG %s/ir: fmt, ir-c.name , ## arg)
+ printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg)
/* Helper functions for RC5 and NEC decoding at GPIO16 or GPIO18 */
static int saa7134_rc5_irq(struct saa7134_dev *dev);
@@ -693,7 +693,7 @@ void saa7134_set_i2c_ir(struct saa7134_d
switch (dev-board) {
case SAA7134_BOARD_PINNACLE_PCTV_110i:
case
[PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
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/cx18/cx18-i2c.c| 30 ++
linux/drivers/media/video/cx231xx/cx231xx-cards.c|5
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 | 198 ++
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/drivers/media/video/usbvision/usbvision-i2c.c | 24 ++
linux/include/media/ir-kbd-i2c.h |2
17 files changed, 284 insertions(+), 196 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-04-04
10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-04-04
10:58:36.0 +0200
@@ -405,6 +405,27 @@ int __devinit init_bttv_i2c(struct bttv
}
if (0 == btv-i2c_rc i2c_scan)
do_i2c_scan(btv-c.v4l2_dev.name, btv-i2c_client);
+
+ /* Instantiate the IR receiver device, if present */
+ if (0 == btv-i2c_rc) {
+ 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(btv-c.i2c_adap, info, addr_list);
+ }
return btv-i2c_rc;
}
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-04
10:53:15.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-04
10:58:36.0 +0200
@@ -211,7 +211,32 @@ static struct i2c_algo_bit_data cx18_i2c
.timeout= CX18_ALGO_BIT_TIMEOUT*HZ /* jiffies */
};
-/* init + register i2c algo-bit adapter */
+static void init_cx18_i2c_ir(struct cx18 *cx)
+{
+ 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, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, ir-kbd, I2C_NAME_SIZE);
+
+ /* The IR receiver device can be on either I2C bus */
+ if (i2c_new_probed_device(cx-i2c_adap[0], info, addr_list))
+ return;
+ i2c_new_probed_device(cx-i2c_adap[1], info, addr_list);
+}
+
+/* init + register i2c adapters + instantiate IR receiver */
int init_cx18_i2c(struct cx18 *cx)
{
int i, err;
@@ -279,6 +304,9 @@ int init_cx18_i2c(struct cx18 *cx)
err = i2c_bit_add_bus(cx-i2c_adap[1]);
if (err)
goto err_del_bus_0;
+
+ /* Instantiate the IR receiver device, if
[PATCH 4/6] ir-kbd-i2c: Use initialization data
For specific boards, pass initialization data to ir-kbd-i2c instead
of modifying the settings after the device is initialized. This is
more efficient and easier to read.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/cx231xx/cx231xx-cards.c | 14 ---
linux/drivers/media/video/cx231xx/cx231xx-i2c.c | 29 --
linux/drivers/media/video/cx231xx/cx231xx.h |1
linux/drivers/media/video/em28xx/em28xx-cards.c | 31 +++
linux/drivers/media/video/em28xx/em28xx-i2c.c | 22 -
linux/drivers/media/video/em28xx/em28xx.h |1
linux/drivers/media/video/ir-kbd-i2c.c| 12 ++
linux/drivers/media/video/saa7134/saa7134-i2c.c | 28 --
linux/drivers/media/video/saa7134/saa7134-input.c | 88 ++---
linux/drivers/media/video/saa7134/saa7134.h |1
linux/include/media/ir-kbd-i2c.h |7 +
11 files changed, 76 insertions(+), 158 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-cards.c
2009-04-04 09:20:21.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-cards.c 2009-04-04
09:20:23.0 +0200
@@ -282,20 +282,6 @@ static void cx231xx_config_tuner(struct
}
/* --- */
-void cx231xx_set_ir(struct cx231xx *dev, struct IR_i2c *ir)
-{
- /* detect configure */
- switch (dev-model) {
-
- case CX231XX_BOARD_CNXT_RDE_250:
- break;
- case CX231XX_BOARD_CNXT_RDU_250:
- break;
- default:
- break;
- }
-}
-
void cx231xx_card_setup(struct cx231xx *dev)
{
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-i2c.c
2009-04-04 09:20:18.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-i2c.c 2009-04-04
09:20:23.0 +0200
@@ -424,34 +424,6 @@ static u32 functionality(struct i2c_adap
return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C;
}
-/*
- * attach_inform()
- * gets called when a device attaches to the i2c bus
- * does some basic configuration
- */
-static int attach_inform(struct i2c_client *client)
-{
- struct cx231xx_i2c *bus = i2c_get_adapdata(client-adapter);
- struct cx231xx *dev = bus-dev;
-
- switch (client-addr 1) {
- case 0x8e:
- {
- struct IR_i2c *ir = i2c_get_clientdata(client);
- dprintk1(1, attach_inform: IR detected (%s).\n,
-ir-phys);
- cx231xx_set_ir(dev, ir);
- break;
- }
- break;
-
- default:
- break;
- }
-
- return 0;
-}
-
static struct i2c_algorithm cx231xx_algo = {
.master_xfer = cx231xx_i2c_xfer,
.functionality = functionality,
@@ -465,7 +437,6 @@ static struct i2c_adapter cx231xx_adap_t
.name = cx231xx,
.id = I2C_HW_B_CX231XX,
.algo = cx231xx_algo,
- .client_register = attach_inform,
};
static struct i2c_client cx231xx_client_template = {
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx.h2009-04-04
09:20:18.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx.h 2009-04-04
09:20:23.0 +0200
@@ -747,7 +747,6 @@ extern void cx231xx_card_setup(struct cx
extern struct cx231xx_board cx231xx_boards[];
extern struct usb_device_id cx231xx_id_table[];
extern const unsigned int cx231xx_bcount;
-void cx231xx_set_ir(struct cx231xx *dev, struct IR_i2c *ir);
int cx231xx_tuner_callback(void *ptr, int component, int command, int arg);
/* Provided by cx231xx-input.c */
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-cards.c
2009-04-04 09:20:21.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-cards.c 2009-04-04
09:54:59.0 +0200
@@ -1907,6 +1907,7 @@ static int em28xx_hint_board(struct em28
void em28xx_register_i2c_ir(struct em28xx *dev)
{
struct i2c_board_info info;
+ struct IR_i2c_init_data init_data;
const unsigned short addr_list[] = {
0x30, 0x47, I2C_CLIENT_END
};
@@ -1915,12 +1916,9 @@ void em28xx_register_i2c_ir(struct em28x
return;
memset(info, 0, sizeof(struct i2c_board_info));
+ memset(init_data, 0, sizeof(struct IR_i2c_init_data));
strlcpy(info.type, ir-kbd, I2C_NAME_SIZE);
- i2c_new_probed_device(dev-i2c_adap, info, addr_list);
-}
-void em28xx_set_ir(struct em28xx *dev, struct IR_i2c *ir)
-{
/* detect configure */
switch (dev-model) {
case (EM2800_BOARD_UNKNOWN):
@@ -1929,22 +1927,19 @@ void em28xx_set_ir(struct em28xx *dev, s
break;
case (EM2800_BOARD_TERRATEC_CINERGY_200):
case (EM2820_BOARD_TERRATEC_CINERGY_250):
- ir-ir_codes = ir_codes_em_terratec;
- ir-get_key = em28xx_get_key_terratec;
-
[PATCH 5/6] saa7134: Simplify handling of IR on MSI t...@nywhere Plus
Now that we instantiate I2C IR devices explicitly, we can skip probing
altogether on boards where the I2C IR device address is known. The MSI
t...@nywhere Plus is one of these boards.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/saa7134/saa7134-input.c | 27 +
1 file changed, 7 insertions(+), 20 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-04-04 10:07:49.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-04-04
10:22:14.0 +0200
@@ -691,16 +691,6 @@ void saa7134_probe_i2c_ir(struct saa7134
I2C_CLIENT_END
};
- const unsigned short addr_list_msi[] = {
- 0x30, I2C_CLIENT_END
- };
- struct i2c_msg msg_msi = {
- .addr = 0x50,
- .flags = I2C_M_RD,
- .len = 0,
- .buf = NULL,
- };
-
unsigned char subaddr, data;
struct i2c_msg msg_avermedia[] = { {
.addr = 0x40,
@@ -747,6 +737,7 @@ void saa7134_probe_i2c_ir(struct saa7134
init_data.name = MSI t...@nywhere Plus;
init_data.get_key = get_key_msi_tvanywhere_plus;
init_data.ir_codes = ir_codes_msi_tvanywhere_plus;
+ info.addr = 0x30;
break;
case SAA7134_BOARD_HAUPPAUGE_HVR1110:
init_data.name = HVR 1110;
@@ -766,18 +757,14 @@ void saa7134_probe_i2c_ir(struct saa7134
if (init_data.name)
info.platform_data = init_data;
- client = i2c_new_probed_device(dev-i2c_adap, info, addr_list);
- if (client)
+ /* No need to probe if address is known */
+ if (info.addr) {
+ i2c_new_device(dev-i2c_adap, info);
return;
+ }
- /* MSI t...@nywhere Plus controller doesn't seem to
- respond to probes unless we read something from
- an existing device. Weird... */
- rc = i2c_transfer(dev-i2c_adap, msg_msi, 1);
- dprintk(KERN_DEBUG probe 0x%02x @ %s: %s\n,
- msg_msi.addr, dev-i2c_adap.name,
- (1 == rc) ? yes : no);
- client = i2c_new_probed_device(dev-i2c_adap, info, addr_list_msi);
+ /* Address not known, fallback to probing */
+ client = i2c_new_probed_device(dev-i2c_adap, info, addr_list);
if (client)
return;
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] saa7134: Simplify handling of IR on AVerMedia Cardbus
Now that we instantiate I2C IR devices explicitly, we can skip probing
altogether on boards where the I2C IR device address is known. The
AVerMedia Cardbus are two of these boards.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/saa7134/saa7134-input.c | 35 +++--
1 file changed, 5 insertions(+), 30 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-04-04 10:41:44.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-04-04
10:47:10.0 +0200
@@ -691,22 +691,6 @@ void saa7134_probe_i2c_ir(struct saa7134
I2C_CLIENT_END
};
- unsigned char subaddr, data;
- struct i2c_msg msg_avermedia[] = { {
- .addr = 0x40,
- .flags = 0,
- .len = 1,
- .buf = subaddr,
- }, {
- .addr = 0x40,
- .flags = I2C_M_RD,
- .len = 1,
- .buf = data,
- } };
-
- struct i2c_client *client;
- int rc;
-
if (disable_ir) {
dprintk(IR has been disabled, not probing for i2c remote\n);
return;
@@ -753,6 +737,10 @@ void saa7134_probe_i2c_ir(struct saa7134
init_data.get_key = get_key_beholdm6xx;
init_data.ir_codes = ir_codes_behold;
break;
+ case SAA7134_BOARD_AVERMEDIA_CARDBUS:
+ case SAA7134_BOARD_AVERMEDIA_CARDBUS_506:
+ info.addr = 0x40;
+ break;
}
if (init_data.name)
@@ -764,20 +752,7 @@ void saa7134_probe_i2c_ir(struct saa7134
}
/* Address not known, fallback to probing */
- client = i2c_new_probed_device(dev-i2c_adap, info, addr_list);
- if (client)
- return;
-
- /* Special case for AVerMedia Cardbus remote */
- subaddr = 0x0d;
- rc = i2c_transfer(dev-i2c_adap, msg_avermedia, 2);
- dprintk(KERN_DEBUG probe 0x%02x/0x%02x @ %s: %s\n,
- msg_avermedia[0].addr, subaddr, dev-i2c_adap.name,
- (2 == rc) ? yes : no);
- if (2 == rc) {
- info.addr = msg_avermedia[0].addr;
- i2c_new_device(dev-i2c_adap, info);
- }
+ i2c_new_probed_device(dev-i2c_adap, info, addr_list);
}
static int saa7134_rc5_irq(struct saa7134_dev *dev)
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - RECALL] siano: smsendian smsdvb - binding the smsendian to smsdvb
--- On Sat, 4/4/09, Mauro Carvalho Chehab mche...@infradead.org wrote: From: Mauro Carvalho Chehab mche...@infradead.org Subject: Re: [PATCH - RECALL] siano: smsendian smsdvb - binding the smsendian to smsdvb To: Uri Shkolnik uri...@yahoo.com Cc: linux-media@vger.kernel.org Date: Saturday, April 4, 2009, 12:14 AM On Fri, 3 Apr 2009 13:31:32 -0700 (PDT) Uri Shkolnik uri...@yahoo.com wrote: --- On Fri, 4/3/09, Mauro Carvalho Chehab mche...@infradead.org wrote: From: Mauro Carvalho Chehab mche...@infradead.org Subject: Re: [PATCH - RECALL] siano: smsendian smsdvb - binding the smsendian to smsdvb To: Uri Shkolnik uri...@yahoo.com Cc: linux-media@vger.kernel.org Date: Friday, April 3, 2009, 3:15 PM Uri, On Fri, 3 Apr 2009 03:20:38 -0700 (PDT) Uri Shkolnik uri...@yahoo.com wrote: Hi, The last patch in the series (siano: smsendian smsdvb - binding the smsendian to smsdvb) breaks the driver, please ignore it. It will be very hard (again) to handle your patch series. Especially when sending a big series of patches like this, you should number the patches, for they to be applied at the proper order. Also, when a patch is broken, you should reply to that patch, without changing the subject. The original message ID will be properly handled by patchwork, and the reply message will be folded with the original patch. In this case, this is the message ID of your patch message: Message-ID: 622468.86074...@web110805.mail.gq1.yahoo.com However, your RECALL email doesn't contain any reference tag to the original message (since you didn't reply to your message). So, emailers and patchwork won't associate the reply with the patch you want to discard. Cheers, Mauro Hi Mauro, 1) Backport patch (siano: smsdvb - add support for old dvb-core version) - If this patch causes problem, discard it (trashing it does not affect the other patches), let me know, and I'll submit only the one-line endian change. (We'll support old embedded devices, etc. using specific vendor patch from our customer support team, and the kernel version will not have any backport code). 2) I'll add global serial indication to the patches from now on. Regarding the already submmited patches, is it OK if I'll email you a text list of patches with their order? Yes, if you provide me the patch numbers at patchwork. I just need a simple list of patchwork sequence numbers, in the expected order. 3) Recall message - I didn't know about the reply option and I'll do that from now on. (Any day you learn something new, and that fact distinguish you from the dead:-) ) No problem. 4) If it's OK with you, I'll hold further submission, until the already submited patches will be reviewed and commited. Seems the better for me. 5) Some related question... I emailed all patches to you and CC the linux-media@vger.kernel.org ML. I can not see any post other than your replys on the ML and nothing on http://patchwork.kernel.org/project/linux-media/list/ . Any idea why? If patchwork didn't got, then the patch is broken. You don't need to CC me, but you need to be sure that patchwork will catch they. For patchwork to do his job, you should be sure that your emailer won't do line wrapping, and avoid use attachments. Mime processing is tricky and some emailers set the wrong mime type for attachments. Have a great weekend, Same to you. Regards, Uri Cheers, Mauro Hi Mauro, I'm watching closely http://patchwork.kernel.org/project/linux-media/list/ and this ML. Until now, none of my patches appears anywhere. It seems that either html tags or other formatting issue, prevent the robot from processing my patches (I can see submissions from today, while my two days old are absent). I'll wait till tomorrow (just in case) and if nothing will happen, I'll re-submit my patches (and make sure they are pure text...). If so, I'll also add patches numeration, and remove the backport one. Regards, Uri -- 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] cx18: Fix the handling of i2c bus registration error
On Sat, 2009-04-04 at 14:26 +0200, Jean Delvare wrote:
* Return actual error values as returned by the i2c subsystem, rather
than 0 or 1.
* If the registration of the second bus fails, unregister the first one
before exiting, otherwise we are leaking resources.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
Jean,
Thanks for noticing this one and providing a patch. I have one comment
below...
---
linux/drivers/media/video/cx18/cx18-i2c.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c2009-03-01
16:09:09.0 +0100
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-03
18:45:18.0 +0200
@@ -214,7 +214,7 @@ static struct i2c_algo_bit_data cx18_i2c
/* init + register i2c algo-bit adapter */
int init_cx18_i2c(struct cx18 *cx)
{
- int i;
+ int i, err;
CX18_DEBUG_I2C(i2c init\n);
for (i = 0; i 2; i++) {
@@ -273,8 +273,18 @@ int init_cx18_i2c(struct cx18 *cx)
cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL,
core, reset, (u32) CX18_GPIO_RESET_I2C);
- return i2c_bit_add_bus(cx-i2c_adap[0]) ||
- i2c_bit_add_bus(cx-i2c_adap[1]);
+ err = i2c_bit_add_bus(cx-i2c_adap[0]);
if (err)
return err;
err = i2c_bit_add_bus(cx-i2c_adap[1]);
if (err)
i2c_del_adapter(cx-i2c_adap[0]);
return err;
This sequence saves a few lines of code and gets rid of the goto's
compared to what you proposed below.
+ if (err)
+ goto err;
+ err = i2c_bit_add_bus(cx-i2c_adap[1]);
+ if (err)
+ goto err_del_bus_0;
+ return 0;
+
+ err_del_bus_0:
+ i2c_del_adapter(cx-i2c_adap[0]);
+ err:
+ return err;
}
void exit_cx18_i2c(struct cx18 *cx)
Reviewed-by: Andy Walls awa...@radix.net
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sat, 2009-04-04 at 14:28 +0200, 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/cx18/cx18-i2c.c| 30 ++
linux/drivers/media/video/ivtv/ivtv-i2c.c| 31 ++
linux/include/media/ir-kbd-i2c.h |2
17 files changed, 284 insertions(+), 196 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c2009-04-04
10:53:15.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-04
10:58:36.0 +0200
@@ -211,7 +211,32 @@ static struct i2c_algo_bit_data cx18_i2c
.timeout= CX18_ALGO_BIT_TIMEOUT*HZ /* jiffies */
};
-/* init + register i2c algo-bit adapter */
+static void init_cx18_i2c_ir(struct cx18 *cx)
+{
+ 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, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
I think this is way out of date for cx18 based boards. The only IR chip
I know of so far is the Zilog Z8F0811 sitting at 7 bit addresses
0x70-0x74. I guess 0x71 is the proper address for Rx. I'll let you
know when I test.
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, ir-kbd, I2C_NAME_SIZE);
+
+ /* The IR receiver device can be on either I2C bus */
+ if (i2c_new_probed_device(cx-i2c_adap[0], info, addr_list))
+ return;
+ i2c_new_probed_device(cx-i2c_adap[1], info, addr_list);
+}
+
+/* init + register i2c adapters + instantiate IR receiver */
int init_cx18_i2c(struct cx18 *cx)
{
int i, err;
@@ -279,6 +304,9 @@ int init_cx18_i2c(struct cx18 *cx)
err = i2c_bit_add_bus(cx-i2c_adap[1]);
if (err)
goto err_del_bus_0;
+
+ /* Instantiate the IR receiver device, if present */
+ init_cx18_i2c_ir(cx);
return 0;
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
--
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] cx18: Fix the handling of i2c bus registration error
Hi Andy,
Thanks for the fast review.
On Sat, 04 Apr 2009 08:46:00 -0400, Andy Walls wrote:
On Sat, 2009-04-04 at 14:26 +0200, Jean Delvare wrote:
* Return actual error values as returned by the i2c subsystem, rather
than 0 or 1.
* If the registration of the second bus fails, unregister the first one
before exiting, otherwise we are leaking resources.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
Jean,
Thanks for noticing this one and providing a patch. I have one comment
below...
---
linux/drivers/media/video/cx18/cx18-i2c.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c 2009-03-01
16:09:09.0 +0100
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-03
18:45:18.0 +0200
@@ -214,7 +214,7 @@ static struct i2c_algo_bit_data cx18_i2c
/* init + register i2c algo-bit adapter */
int init_cx18_i2c(struct cx18 *cx)
{
- int i;
+ int i, err;
CX18_DEBUG_I2C(i2c init\n);
for (i = 0; i 2; i++) {
@@ -273,8 +273,18 @@ int init_cx18_i2c(struct cx18 *cx)
cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL,
core, reset, (u32) CX18_GPIO_RESET_I2C);
- return i2c_bit_add_bus(cx-i2c_adap[0]) ||
- i2c_bit_add_bus(cx-i2c_adap[1]);
+ err = i2c_bit_add_bus(cx-i2c_adap[0]);
if (err)
return err;
err = i2c_bit_add_bus(cx-i2c_adap[1]);
if (err)
i2c_del_adapter(cx-i2c_adap[0]);
return err;
This sequence saves a few lines of code and gets rid of the goto's
compared to what you proposed below.
Correct, actually my initial attempt looked like this. But then patch
3/6 adds code, which makes your solution 2 lines bigger, while my
solution stays as is, so the difference between both becomes very thin.
Some developers (including me) prefer to have a single error path,
others hate gotos more than (potential) code duplication. I didn't know
what you'd prefer as the driver maintainer. If you want me to use the
variant without gotos, I can do that, no problem.
+ if (err)
+ goto err;
+ err = i2c_bit_add_bus(cx-i2c_adap[1]);
+ if (err)
+ goto err_del_bus_0;
+ return 0;
+
+ err_del_bus_0:
+ i2c_del_adapter(cx-i2c_adap[0]);
+ err:
+ return err;
}
void exit_cx18_i2c(struct cx18 *cx)
Reviewed-by: Andy Walls awa...@radix.net
Thanks,
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 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
[cron job] v4l-dvb daily build 2.6.22 and up: OK, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Apr 4 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11346:4cd17f5a20cc gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-x86_64: OK fw/apps: OK sparse (linux-2.6.29): OK linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pvrusb2: Drop client_register/unregister stubs
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,
};
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
libv4l: Possibility of changing the current pixelformat on the fly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While trying to get hflip and vflip working for the stv06xx webcam bridge coupled to the vv6410 sensor I've come across the following problem. When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. Best regards, Erik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknXwXcACgkQN7qBt+4UG0GVfwCfQjWjSu2fdyrgl3BRGlum3cJi aFAAoKBrKtTezxcnAbmmvM1cLpYOWvvf =4D37 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Driver for STK7700D?
Hi (Matthias?), i have also a STK7700D tv-tuner card. Can anybody inform me with any updates regarding the letter to Microtune for Linux support? (i know that it is 2 years since Matthias sent the letter and probably he is not on the list any more, but its never bad to try...) Has anyone else any infos about this tuner? Is the driver[1] for MT2266 chip compatible? Thanks in Advance, Kostis [1] http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/media/common/tuners/mt2266.c Hello Patrick, thank you for your reply. I've send a request for a datasheet to Microtune. I've BCC'ed you, hope you don't mind. Am Donnerstag, den 11.01.2007, 09:40 +0100 schrieb Patrick Boettcher: Hi Matthias, This is explained very easy. The STK7700D ref design was done with MT2266 from Microtune. As of today, there is no OpenSource driver for this RF tuner. All I can do is, to ask you to contact Microtune and your notebook vendor for that. When there are enough people asking for it, it may change the minds. Patrick. -- Mail: patrick.boettcher at desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ On Thu, 11 Jan 2007, Matthias Hentges wrote: Hello all, I'm trying to get the DVB-T USB device built into my new notebook working. The device uses an STK7700D chip so I hacked dvb-usb-ids.h and added my vendor:device IDs to fake a Hauppauge Nova-T Stick. The following output of dmesg shows the module loading and firmware insertion: dvb-usb: found a 'Hauppauge Nova-T Stick' in cold state, will try to load a firm ware [...] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-01.fw' dib0700: firmware started successfully. dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state. **WARNING** I2C adapter driver [Hauppauge Nova-T Stick] forgot to specify physical device; fix it! dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T Stick). **WARNING** I2C adapter driver [DiBX000 tuner I2C bus] forgot to specify physical device; fix it! DVB: registering frontend 0 (DiBcom 7000PC)... mt2060 I2C read failed dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dib0700 While the firmware is inserted just fine, the **WARNING** messages don't look good to me. And indeed, tuning does not work: scanning /usr/share/doc/dvb-utils/examples/scan/dvb-t/de-Koeln-Bonn using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux1' initial transponder 53800 0 2 9 1 1 3 0 initial transponder 51400 0 2 9 1 1 3 0 initial transponder 69800 0 2 9 1 1 3 0 initial transponder 65000 0 2 9 1 1 3 0 initial transponder 82600 0 2 9 1 1 3 0 initial transponder 83400 0 2 9 1 1 3 0 tune to: 53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE WARNING: tuning failed!!! tune to: 53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE (tuning failed) WARNING: tuning failed!!! tune to: 51400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE WARNING: tuning failed!!! [...] tune to: 83400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE (tuning failed) WARNING: tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Done. A lsusb-vvv dump is attached. I would appreciate any pointers in the right direction ;) I'm using kernel 2.6.4.20-rc4 and latest dvb sources. Thanks Matthias Hentges -- 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, 2009-04-04 at 11:05 -0500, Mike Isely wrote:
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)
I was thinking about this while mowing the lawn today
The objectives seem to be:
1. Avoid auto probing
2. Leverage the bridge driver's knowledge of what should be available
3. Allow the user to dictate which kernel IR driver module be used with
the subordinate device.
So my rough outline of an idea (which probably runs slightly afoul of
Hans' media_controller device, but we don't have it yet):
1. Add a function to the v4l2 framework to iterate over all the
v4l2_device's that are registered (if there isn't one already).
2. Add a method to the v4l2_device class to return the IR subdevice for
a given v4l2_device:
v4l2_subdev *v4l2_device_get_ir_subdev(v4l2_device *dev);
and if it returns NULL, that device has no IR chip.
3. To the v4l2_subdev framework add:
struct v4l2_subdev_ir_ops {
(*enumerate) (v4l2_subdev *sd, /* bus_type, bus #, addr for Rx,
addr for Tx */);
(*claim) (v4l2_subdev *sd, /* claiming driver name string,
going-away callback function pointer */);
(*release) (v4l2_subdev *sd, /* handle */);
bool (*is_claimed) (v4l2_subdev *sd, /* output string of the
owner */);
/* Or maybe just */
(*send) (v4l2_subdev *sd, /* data buffer */);
(*receive) (v4l2_subdev *sd, /* data buffer */);
}
and have the bridge driver support these. (I also had some in mind for
the IR micro-controller debug/programming port, but the above will fit
the task at hand I think.)
OK so that's all a bit rough around the edges. The idea is a uniform
call in for ir-kdb-i2c or lirc_foo or ir_foo to get at an IR chip behind
a bridge device, that the bridge device driver itself cares about very
little. *Except* ir driver modules would be coordinated by the bridge
driver in what they can and cannot do to get at the IR device. This
coordination prevents bad things on the bridge chip's I2C bus(es) or
from having modules racing to get the IR device. That way whatever
module the user loads will get first shot at claiming the IR chip. This
also provides a discovery mechanism four use by ir driver modules that
is informed by the bridge chip driver. I think lirc_foo can also still
use it's current way of doing business too.
It really just looks like a small subset of what Hans intended for the
media controller, so maybe this would be a good chance to get some
lessons learned.
Regards,
Andy
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.
I think we can get there and still have the random probing reduced.
Regards,
Andy
-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 1/6] cx18: Fix the handling of i2c bus registration error
On Sat, 2009-04-04 at 16:23 +0200, Jean Delvare wrote: Hi Andy, Thanks for the fast review. On Sat, 04 Apr 2009 08:46:00 -0400, Andy Walls wrote: Correct, actually my initial attempt looked like this. But then patch 3/6 adds code, which makes your solution 2 lines bigger, while my solution stays as is, so the difference between both becomes very thin. Some developers (including me) prefer to have a single error path, others hate gotos more than (potential) code duplication. I didn't know what you'd prefer as the driver maintainer. If you want me to use the variant without gotos, I can do that, no problem. Meh, whichever way you like is fine for now. If I really decide to care about it, I'll muck with it when I get the hardware I2C masters working. I'll have to touch that section of code at that time anyway. Acked-by: Andy Walls awa...@radix.net Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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: tm6010 development repository
Steven Toth wrote: Kevin Wells wrote: I've started trying to understand the code in the following repository: http://www.linuxtv.org/hg/~mchehab/tm6010/ I have a few patches I would like to apply. How should I do this? Submit the patches to the list and I'll try to get some time to create and maintain a ~stoth/tm6010 tree. I think I can get the nova-s-usb2 running with just a little effort. Thanks Steve. Sorry for the slow reply. I'm doing this in my limited spare time. Patches to follow. Nothing exciting. Just trying to make the code more robust. Patches are very granular. Let me know if that doesn't work for you. Knowing the driver works on the nova-s-usb2 would be encouraging. I'm trying to get it to work on an hvr-900h. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4 ] tm6000
Hi all, Patches to fix minor issues found when reviewing tm6000-cards.c from: http://linuxtv.org/hg/~mchehab/tm6010/ based on changeset 3d58b6531a81. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] tm6000: More robust error handling in tm6000_usb_probe()
# HG changeset patch
# User Kevin Wells kevin.we...@kahusoft.com
# Date 1238841558 -46800
# Node ID 3140e621a17b536eb1487f8f9ad5b7b6a8ff8341
# Parent a293d5babca03bb5a7f21ecb659d55e447194e49
More robust error handling in tm6000_usb_probe()
From: Kevin Wells kevin.we...@kahusoft.com
Priority: normal
Signed-off-by: Kevin Wells kevin.we...@kahusoft.com
diff -r a293d5babca0 -r 3140e621a17b
linux/drivers/media/video/tm6000/tm6000-cards.c
--- a/linux/drivers/media/video/tm6000/tm6000-cards.cSat Apr 04
23:07:00 2009 +1300
+++ b/linux/drivers/media/video/tm6000/tm6000-cards.cSat Apr 04
23:39:18 2009 +1300
@@ -373,22 +373,22 @@
/* Selects the proper interface */
rc=usb_set_interface(usbdev,0,1);
if (rc0)
-goto err;
+goto err1;
/* Check to see next free device and mark as used */
nr=find_first_zero_bit(tm6000_devused,TM6000_MAXBOARDS);
if (nr = TM6000_MAXBOARDS) {
printk(tm6000: Only supports %i boards.\n, TM6000_MAXBOARDS);
-usb_put_dev(usbdev);
-return -ENOMEM;
+rc = -ENOMEM;
+goto err1;
}
/* Create and initialize dev struct */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (dev == NULL) {
printk (tm6000 : out of memory!\n);
-usb_put_dev(usbdev);
-return -ENOMEM;
+rc = -ENOMEM;
+goto err1;
}
spin_lock_init(dev-slock);
@@ -495,8 +495,7 @@
if (!dev-isoc_in) {
printk(tm6000: probing error: no IN ISOC endpoint!\n);
rc= -ENODEV;
-
-goto err;
+goto err2;
}
/* save our data pointer in this interface device */
@@ -514,15 +513,17 @@
rc=tm6000_init_dev(dev);
if (rc0)
-goto err;
+goto err3;
return 0;
-err:
+err3:
+usb_set_intfdata(interface, NULL);
+err2:
tm6000_devused=~(1nr);
+kfree(dev);
+err1:
usb_put_dev(usbdev);
-
-kfree(dev);
return rc;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] tm6000: Use mask when getting XFERTYPE from bmAttributes
# HG changeset patch
# User Kevin Wells kevin.we...@kahusoft.com
# Date 1238885144 -43200
# Node ID 02d3a231b99e1eef922679f1381eecd0b9990d23
# Parent 3140e621a17b536eb1487f8f9ad5b7b6a8ff8341
Use mask when getting XFERTYPE from bmAttributes
From: Kevin Wells kevin.we...@kahusoft.com
Priority: normal
Signed-off-by: Kevin Wells kevin.we...@kahusoft.com
diff -r 3140e621a17b -r 02d3a231b99e
linux/drivers/media/video/tm6000/tm6000-cards.c
--- a/linux/drivers/media/video/tm6000/tm6000-cards.cSat Apr 04
23:39:18 2009 +1300
+++ b/linux/drivers/media/video/tm6000/tm6000-cards.cSun Apr 05
10:45:44 2009 +1200
@@ -446,7 +446,7 @@
interface-altsetting[i].desc.bInterfaceNumber,
interface-altsetting[i].desc.bInterfaceClass);
-switch (e-desc.bmAttributes) {
+switch (e-desc.bmAttributes USB_ENDPOINT_XFERTYPE_MASK) {
case USB_ENDPOINT_XFER_BULK:
if (!dir_out) {
get_max_endpoint (usbdev, Bulk IN, e,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] tm6000: Clear bit in tm6000_devused when board is disconnected.
# HG changeset patch # User Kevin Wells kevin.we...@kahusoft.com # Date 1238885821 -43200 # Node ID ca10a33f275b6fefa15ef651df9b657834a28bb0 # Parent 02d3a231b99e1eef922679f1381eecd0b9990d23 Clear bit in tm6000_devused when board is disconnected. From: Kevin Wells kevin.we...@kahusoft.com Priority: normal Signed-off-by: Kevin Wells kevin.we...@kahusoft.com diff -r 02d3a231b99e -r ca10a33f275b linux/drivers/media/video/tm6000/tm6000-cards.c --- a/linux/drivers/media/video/tm6000/tm6000-cards.cSun Apr 05 10:45:44 2009 +1200 +++ b/linux/drivers/media/video/tm6000/tm6000-cards.cSun Apr 05 10:57:01 2009 +1200 @@ -559,6 +559,8 @@ dev-state |= DEV_DISCONNECTED; +tm6000_devused = ~(1 dev-devno); + usb_put_dev(dev-udev); mutex_unlock(dev-lock); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] tm6000: Remove reference to em28xx from error message.
# HG changeset patch
# User Kevin Wells kevin.we...@kahusoft.com
# Date 1238839620 -46800
# Node ID a293d5babca03bb5a7f21ecb659d55e447194e49
# Parent 3d58b6531a818aafdacde895c34e4517a4dc4104
Remove reference to em28xx from error message.
From: Kevin Wells kevin.we...@kahusoft.com
Priority: normal
Signed-off-by: Kevin Wells kevin.we...@kahusoft.com
diff -r 3d58b6531a81 -r a293d5babca0
linux/drivers/media/video/tm6000/tm6000-cards.c
--- a/linux/drivers/media/video/tm6000/tm6000-cards.cFri Nov 28
08:39:00 2008 -0200
+++ b/linux/drivers/media/video/tm6000/tm6000-cards.cSat Apr 04
23:07:00 2009 +1300
@@ -378,7 +378,7 @@
/* Check to see next free device and mark as used */
nr=find_first_zero_bit(tm6000_devused,TM6000_MAXBOARDS);
if (nr = TM6000_MAXBOARDS) {
-printk (tm6000: Supports only %i em28xx
boards.\n,TM6000_MAXBOARDS);
+printk(tm6000: Only supports %i boards.\n, TM6000_MAXBOARDS);
usb_put_dev(usbdev);
return -ENOMEM;
}
--
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, 2009-04-05 at 00:51 +0200, Jean Delvare wrote:
Hi Andy,
On Sat, 04 Apr 2009 09:42:09 -0400, Andy Walls wrote:
On Sat, 2009-04-04 at 14:28 +0200, 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/cx18/cx18-i2c.c| 30 ++
linux/drivers/media/video/ivtv/ivtv-i2c.c| 31 ++
linux/include/media/ir-kbd-i2c.h |2
17 files changed, 284 insertions(+), 196 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c
2009-04-04 10:53:15.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-04
10:58:36.0 +0200
@@ -211,7 +211,32 @@ static struct i2c_algo_bit_data cx18_i2c
.timeout= CX18_ALGO_BIT_TIMEOUT*HZ /* jiffies */
};
-/* init + register i2c algo-bit adapter */
+static void init_cx18_i2c_ir(struct cx18 *cx)
+{
+ 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, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
I think this is way out of date for cx18 based boards. The only IR chip
I know of so far is the Zilog Z8F0811 sitting at 7 bit addresses
0x70-0x74. I guess 0x71 is the proper address for Rx. I'll let you
know when I test.
This address list comes from the ir-kbd-i2c driver. The cx18 driver
happens to use the same I2C adapter ID as the ivtv driver
(I2C_HW_B_CX2341X) and this is what the ir-kbd-i2c driver used to
decide which addresses to probe. As I don't know anything about the
hardware, I had to keep the new code compatible with the old one and
keep probing the same addresses.
This is the i2cdetect output from my HVR-1600 - the only cx18 based card
known or reported to have an IR chip:
[r...@morgan ~]# i2cdetect -l
i2c-0 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter
i2c-1 i2c ivtv i2c driver #0 I2C adapter
i2c-2 i2c cx18 i2c driver #0-0I2C adapter
i2c-3 i2c cx18 i2c driver #0-1I2C adapter
[r...@morgan ~]# i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- 19 -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- --
70: 70 71 72 73 -- -- -- --
[r...@morgan ~]# i2cdetect 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
The Zilog is at 0x70-0x73. The standard IR Tx and RX addresses are 0x70
and 0x71
Now, if you tell me that this list doesn't make sense for cx18 boards,
we can change it.
I owe you the right address to probe. I think it is 0x71, but I want to
RE: HVR-1500 tuner s eems to be recognize d, but wont turn on.
Finally found more time to work on this. When i try sudo modprobe tuner-xc2028 no_poweroff=1 It returns: tuner_xc2028: Unknown parameter `no_poweroff' any thoughts? Nick Date: Tue, 17 Feb 2009 15:56:00 -0500 Subject: Re: HVR-1500 tuner seems to be recognized, but wont turn on. From: devin.heitmuel...@gmail.com To: nicko...@hotmail.com CC: linux-media@vger.kernel.org 2009/2/17 Thomas Nicolai : I will try those suggestions this evening. did he feel this should be done in addition to the modprobe tunerxc-2028 no_poweroff=1 debug=1 ? Please do both commands. That way we will get both sets of debugging messages and you only have to do the capture once. Regards, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller _ Rediscover Hotmail®: Now available on your iPhone or BlackBerry http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Mobile1_042009 -- 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
get_dvb_firmware patch + c88x board tuner question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, its my first post, and my first patch, my first try, so probably
iḿ going to make big mistakes. Dont be cruel.
I corrected urls in get_dvb_firmware, from linux-source-2.6.29, so iḿ
going to suggest a patch
Trying to configure the NPG REAL DVB-T PCI
ttp://www.npgtech.com/producto_info.asp?idProducto=98
lspci -vnn output
03:06.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05)
Subsystem: Conexant Systems, Inc. Conexant DVB-T reference design
[14f1:0187]
Flags: medium devsel, IRQ 20
Memory at fa00 (32-bit, non-prefetchable) [size=16M]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
03:06.2 Multimedia controller [0480]: Conexant Systems, Inc.
CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05)
Subsystem: Conexant Systems, Inc. Conexant DVB-T reference design
[14f1:0187]
Flags: medium devsel, IRQ 20
Memory at fb00 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2
Video input working, and lirc input not checked, with
insmod c88xx card=51 i2c_scan=1
dmesg output
cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded
cx88[0]: subsystem: 14f1:0187, board: WinFast DTV2000 H
[card=51,insmod option], frontend(s): 1
cx88[0]: TV tuner type 5, Radio tuner type -1
tuner' 1-0043: chip found @ 0x86 (cx88[0])
tda9887 1-0043: creating new instance
tda9887 1-0043: tda988[5/6/7] found
All bytes are equal. It is not a TEA5767
tuner' 1-0060: chip found @ 0xc0 (cx88[0])
tuner-simple 1-0060: creating new instance
tuner-simple 1-0060: type set to 5 (Philips PAL_BG (FI1216 and
compatibles))
input: cx88 IR (WinFast DTV2000 H) as
/devices/pci:00/:00:14.4/:03:06.2/input/input8
cx88[0]/2: cx2388x 8802 Driver Manager
cx88-mpeg driver manager :03:06.2: PCI INT A - GSI 20 (level,
low) - IRQ 20
cx88[0]/2: found at :03:06.2, rev: 5, irq: 20, latency: 32, mmio:
0xfb00
IRQ 20/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
tuner seems to be a philips tda1004x, supported in saa7134
chips in board are
conexant cx23881-19 , as pci bridge
conexant cx22702-25 , as frontend
philips tda6651, inside tuner as mixer according to datasheets
So, my newy questions, is anybody working to port this tuner, i will
try but unsure. I prefer send hardware to a real developer.
Thanks
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknYR8oACgkQ5c4hZyE8gm9cHgCgvhdSt+Wa4jvjo+uKb98xdC4J
oicAn0nrJEs0evuqYY3MsdHWuINZfUwz
=/Ffq
-END PGP SIGNATURE-
--- get_dvb_firmware 2009-03-24 00:12:14.0 +0100
+++ get_dvb_firmware 2009-04-05 06:55:18.0 +0200
@@ -112,7 +112,7 @@
sub tda10046 {
my $sourcefile = TT_PCI_2.19h_28_11_2006.zip;
- my $url = http://technotrend-online.com/download/software/219/$sourcefile;;
+ my $url = http://www.tt-download.com/download/updates/219/$sourcefile;;
my $hash = 6a7e1e2f2644b162ff0502367553c72d;
my $outfile = dvb-fe-tda10046.fw;
my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
@@ -129,8 +129,8 @@
}
sub tda10046lifeview {
-my $sourcefile = Drv_2.11.02.zip;
-my $url = http://www.lifeview.com.tw/drivers/pci_card/FlyDVB-T/$sourcefile;;
+my $sourcefile = 7%5Cdrv_2.11.02.zip;
+my $url = http://www.lifeview.hk/dbimages/document/$sourcefile;;
my $hash = 1ea24dee4eea8fe971686981f34fd2e0;
my $outfile = dvb-fe-tda10046.fw;
my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
