From 2b5d9946bc6bfdfa489f099eb59bcc15f8ae5afa Mon Sep 17 00:00:00 2001 From: Michael Krufky Date: Sun, 27 Sep 2009 19:11:34 -0300 Subject: V4L/DVB (13048): dib0070: fix build dependency when driver is disabled Fix build dependency on function, dib0070_ctrl_agc_filter [mchehab@redhat.com: reverted the quick workaround 3f48258e50ef4] Signed-off-by: Michael Krufky Signed-off-by: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb/dvb-usb/Kconfig b/drivers/media/dvb/dvb-usb/Kconfig index 9744b06..0e4b97f 100644 --- a/drivers/media/dvb/dvb-usb/Kconfig +++ b/drivers/media/dvb/dvb-usb/Kconfig @@ -75,7 +75,7 @@ config DVB_USB_DIB0700 select DVB_DIB3000MC if !DVB_FE_CUSTOMISE select DVB_S5H1411 if !DVB_FE_CUSTOMISE select DVB_LGDT3305 if !DVB_FE_CUSTOMISE - select DVB_TUNER_DIB0070 + select DVB_TUNER_DIB0070 if !DVB_FE_CUSTOMISE select MEDIA_TUNER_MT2060 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_MT2266 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_XC2028 if !MEDIA_TUNER_CUSTOMISE diff --git a/drivers/media/dvb/frontends/dib0070.h b/drivers/media/dvb/frontends/dib0070.h index 8a2e1e7..eec9e52 100644 --- a/drivers/media/dvb/frontends/dib0070.h +++ b/drivers/media/dvb/frontends/dib0070.h @@ -51,6 +51,7 @@ struct dib0070_config { #if defined(CONFIG_DVB_TUNER_DIB0070) || (defined(CONFIG_DVB_TUNER_DIB0070_MODULE) && defined(MODULE)) extern struct dvb_frontend *dib0070_attach(struct dvb_frontend *fe, struct i2c_adapter *i2c, struct dib0070_config *cfg); extern u16 dib0070_wbd_offset(struct dvb_frontend *); +extern void dib0070_ctrl_agc_filter(struct dvb_frontend *, u8 open); #else static inline struct dvb_frontend *dib0070_attach(struct dvb_frontend *fe, struct i2c_adapter *i2c, struct dib0070_config *cfg) { @@ -63,7 +64,11 @@ static inline u16 dib0070_wbd_offset(struct dvb_frontend *fe) printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__); return -ENODEV; } + +static inline void dib0070_ctrl_agc_filter(struct dvb_frontend *fe, u8 open) +{ + printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__); +} #endif -extern void dib0070_ctrl_agc_filter(struct dvb_frontend *, u8 open); #endif -- cgit v0.10.2 From 1e13c8f0c97c883287b1940719d0040fd38fcd58 Mon Sep 17 00:00:00 2001 From: Patrick Boettcher Date: Sat, 19 Sep 2009 05:24:40 -0300 Subject: V4L/DVB (13050): DIB0700: fix-up USB device ID for Terratec/Leadtek git commit db48138f6bc4d2b613b08731ffc8b319432ebc25 changed by accident the assignment of certain USB IDs to their device-specific-handlers. Thanks to Edward Sheldrake for finding this regression Signed-off-by: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c b/drivers/media/dvb/dvb-usb/dib0700_devices.c index 0b2812a..6bd8951 100644 --- a/drivers/media/dvb/dvb-usb/dib0700_devices.c +++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c @@ -1925,7 +1925,7 @@ struct dvb_usb_device_properties dib0700_devices[] = { { NULL }, }, { "Leadtek Winfast DTV Dongle (STK7700P based)", - { &dib0700_usb_id_table[8] }, + { &dib0700_usb_id_table[8], &dib0700_usb_id_table[34] }, { NULL }, }, { "AVerMedia AVerTV DVB-T Express", @@ -2064,7 +2064,7 @@ struct dvb_usb_device_properties dib0700_devices[] = { }, }, - .num_device_descs = 12, + .num_device_descs = 11, .devices = { { "DiBcom STK7070P reference design", { &dib0700_usb_id_table[15], NULL }, @@ -2098,11 +2098,6 @@ struct dvb_usb_device_properties dib0700_devices[] = { { &dib0700_usb_id_table[30], NULL }, { NULL }, }, - { "Terratec Cinergy T USB XXS/ T3", - { &dib0700_usb_id_table[33], - &dib0700_usb_id_table[52], NULL }, - { NULL }, - }, { "Elgato EyeTV DTT", { &dib0700_usb_id_table[49], NULL }, { NULL }, @@ -2343,8 +2338,10 @@ struct dvb_usb_device_properties dib0700_devices[] = { { &dib0700_usb_id_table[59], NULL }, { NULL }, }, - { "Terratec Cinergy T USB XXS (HD)", - { &dib0700_usb_id_table[34], &dib0700_usb_id_table[60] }, + { "Terratec Cinergy T USB XXS (HD)/ T3", + { &dib0700_usb_id_table[33], + &dib0700_usb_id_table[52], + &dib0700_usb_id_table[60], NULL}, { NULL }, }, }, -- cgit v0.10.2 From 7646b9de26c54cf4bc9c446d7ada9f91ece31e0a Mon Sep 17 00:00:00 2001 From: Martin Samek Date: Wed, 30 Sep 2009 22:59:09 -0300 Subject: V4L/DVB (13079): dib0700: fixed xc2028 firmware loading kernel oops Fixing kernel oops when driver attemps to load xc2028 firmware. Note by djh: the patch contribute by Martin is a port of a fix I made during the PCTV 340e development. It's a temporary workaround that fixes a regression (an OOPS condition) and the real fix should be in the code that manages the i2c master on the dib7000p. But this fix does address the immmediate regression and should be merged upstream until we do a cleaner fix. Signed-off-by: Martin Samek Signed-off-by: Devin Heitmueller CC: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb/frontends/dib7000p.c b/drivers/media/dvb/frontends/dib7000p.c index 55ef6ee..0781f94 100644 --- a/drivers/media/dvb/frontends/dib7000p.c +++ b/drivers/media/dvb/frontends/dib7000p.c @@ -1375,6 +1375,11 @@ struct dvb_frontend * dib7000p_attach(struct i2c_adapter *i2c_adap, u8 i2c_addr, if (dib7000p_identify(st) != 0) goto error; + /* FIXME: make sure the dev.parent field is initialized, or else + request_firmware() will hit an OOPS (this should be moved somewhere + more common) */ + st->i2c_master.gated_tuner_i2c_adap.dev.parent = i2c_adap->dev.parent; + dibx000_init_i2c_master(&st->i2c_master, DIB7000P, st->i2c_adap, st->i2c_addr); dib7000p_demod_reset(st); -- cgit v0.10.2 From 4d8317876d5f53ef792e90f89d8f162d7bca5c81 Mon Sep 17 00:00:00 2001 From: Michael Krufky Date: Sun, 27 Sep 2009 14:05:12 -0300 Subject: V4L/DVB (13107): tda18271: fix overflow in FM radio frequency calculation Multiplication by 62500 causes an overflow in the 32 bit freq variable, which is later divided by 1000 when using FM radio. This patch prevents the overflow by scaling the frequency value correctly upfront. Thanks to Henk Vergonet for spotting the problem and providing a preliminary patch, which this changeset was based upon. Cc: Henk Vergonet Signed-off-by: Michael Krufky CC: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/common/tuners/tda18271-fe.c b/drivers/media/common/tuners/tda18271-fe.c index 6459511..cccaf16 100644 --- a/drivers/media/common/tuners/tda18271-fe.c +++ b/drivers/media/common/tuners/tda18271-fe.c @@ -1000,12 +1000,12 @@ static int tda18271_set_analog_params(struct dvb_frontend *fe, struct tda18271_std_map_item *map; char *mode; int ret; - u32 freq = params->frequency * 62500; + u32 freq = params->frequency * 125 * + ((params->mode == V4L2_TUNER_RADIO) ? 1 : 1000) / 2; priv->mode = TDA18271_ANALOG; if (params->mode == V4L2_TUNER_RADIO) { - freq = freq / 1000; map = &std_map->fm_radio; mode = "fm"; } else if (params->std & V4L2_STD_MN) { -- cgit v0.10.2 From a57c1dcb93e43357ed3f666e5a2b5d5071dd3930 Mon Sep 17 00:00:00 2001 From: Seth Barry Date: Sun, 27 Sep 2009 16:42:29 -0300 Subject: V4L/DVB (13109): tda18271: fix signedness issue in tda18271_rf_tracking_filters_init While having tda18271 module set with debug=17 (cal & info prints) and cal=0 (delay calibration process until first use) - I discovered that during the calibration process, if the frequency test for 69750000 returned a bcal of 0 (see tda18721-fe.c in tda18271_powerscan func) that the tuner wouldn't be able to pickup any of the frequencies in the range (all the other frequencies bands returned bcal=1). I spent some time going over the code and the NXP's tda18271 spec (ver.4 of it i think) and adding a lot of debug prints and walking/stepping through the calibration process. I found that when the powerscan fails to find a frequency, the rf calibration is not run and the default value is supposed to be used in its place (pulled from the RF_CAL_map table) - but something was getting goofed up there. Now, my c coding skills are very rusty, but i think root of the problem is a signedness issue with the math operation for calculating the rf_a1 and rf_a2 values in tda18271_rf_tracking_filters_init func, which results in values like 20648 for rf_a1 (when it should probably have a value like 0, or so slightly negative that it should be zero - this bad value for rf_a1 would in turn makes the approx calc within tda18271c2_rf_tracking_filters_correction go out of whack). The simplest solution i found was to explicitly convert the signedness of the denominator to avoid the implicit conversion. The values placed into the u32 rf_freq array should never exceed about 900mhz, so i think the s32 max value shouldn't be an issue in this case. I've tested it out a little, and even when i get a bcal=0 with the modified code, the default calibration value gets used, rf_a1 is zero, and the tuner seems to lock on the stream and mythtv seems to play it fine. Signed-off-by: Seth Barry Signed-off-by: Michael Krufky CC: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/common/tuners/tda18271-fe.c b/drivers/media/common/tuners/tda18271-fe.c index cccaf16..3a50ce9 100644 --- a/drivers/media/common/tuners/tda18271-fe.c +++ b/drivers/media/common/tuners/tda18271-fe.c @@ -616,13 +616,13 @@ static int tda18271_rf_tracking_filters_init(struct dvb_frontend *fe, u32 freq) case RF2: map[i].rf_a1 = (prog_cal[RF2] - prog_tab[RF2] - prog_cal[RF1] + prog_tab[RF1]) / - ((rf_freq[RF2] - rf_freq[RF1]) / 1000); + (s32)((rf_freq[RF2] - rf_freq[RF1]) / 1000); map[i].rf2 = rf_freq[RF2] / 1000; break; case RF3: map[i].rf_a2 = (prog_cal[RF3] - prog_tab[RF3] - prog_cal[RF2] + prog_tab[RF2]) / - ((rf_freq[RF3] - rf_freq[RF2]) / 1000); + (s32)((rf_freq[RF3] - rf_freq[RF2]) / 1000); map[i].rf_b2 = prog_cal[RF2] - prog_tab[RF2]; map[i].rf3 = rf_freq[RF3] / 1000; break; -- cgit v0.10.2 From 1381dfd5150cfbdb5fa55ce7ab5ab56812111909 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Sun, 4 Oct 2009 14:04:47 -0300 Subject: V4L/DVB (13122): gscpa - stv06xx + ov518: dont discard every other frame When we call gspca_frame_add, it returns a pointer to the frame passed in, unless we call it with LAST_PACKET, when it will return a pointer to a new frame in which to store the frame data for the next frame. The frame pointer was not updated in stv06xx and ov518. Signed-off-by: Hans de Goede Signed-off-by: Jean-Francois Moine Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/gspca/ov519.c b/drivers/media/video/gspca/ov519.c index 2f6e135..a5c190e 100644 --- a/drivers/media/video/gspca/ov519.c +++ b/drivers/media/video/gspca/ov519.c @@ -2919,7 +2919,7 @@ static void ov518_pkt_scan(struct gspca_dev *gspca_dev, /* A false positive here is likely, until OVT gives me * the definitive SOF/EOF format */ if ((!(data[0] | data[1] | data[2] | data[3] | data[5])) && data[6]) { - gspca_frame_add(gspca_dev, LAST_PACKET, frame, data, 0); + frame = gspca_frame_add(gspca_dev, LAST_PACKET, frame, data, 0); gspca_frame_add(gspca_dev, FIRST_PACKET, frame, data, 0); sd->packet_nr = 0; } diff --git a/drivers/media/video/gspca/stv06xx/stv06xx.c b/drivers/media/video/gspca/stv06xx/stv06xx.c index 65489d6..bfae63f 100644 --- a/drivers/media/video/gspca/stv06xx/stv06xx.c +++ b/drivers/media/video/gspca/stv06xx/stv06xx.c @@ -394,7 +394,8 @@ frame_data: PDEBUG(D_PACK, "End of frame detected"); /* Complete the last frame (if any) */ - gspca_frame_add(gspca_dev, LAST_PACKET, frame, data, 0); + frame = gspca_frame_add(gspca_dev, LAST_PACKET, + frame, data, 0); if (chunk_len) PDEBUG(D_ERR, "Chunk length is " -- cgit v0.10.2 From 8cf1fec877c102beeae1e13624b1f7d20abbf8f9 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Mon, 5 Oct 2009 12:51:47 -0300 Subject: V4L/DVB (13129): sh_mobile_ceu_camera: fix cropping for scaling clients Fix a bug in cropping calculation, when the client is also scaling the image. Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/sh_mobile_ceu_camera.c b/drivers/media/video/sh_mobile_ceu_camera.c index 65ac474..2f78b4f 100644 --- a/drivers/media/video/sh_mobile_ceu_camera.c +++ b/drivers/media/video/sh_mobile_ceu_camera.c @@ -1173,8 +1173,8 @@ static int get_scales(struct soc_camera_device *icd, width_in = scale_up(cam->ceu_rect.width, *scale_h); height_in = scale_up(cam->ceu_rect.height, *scale_v); - *scale_h = calc_generic_scale(cam->ceu_rect.width, icd->user_width); - *scale_v = calc_generic_scale(cam->ceu_rect.height, icd->user_height); + *scale_h = calc_generic_scale(width_in, icd->user_width); + *scale_v = calc_generic_scale(height_in, icd->user_height); return 0; } -- cgit v0.10.2 From 07bc46e6671b4533a5e56607ddec9de9079c1844 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Mon, 5 Oct 2009 12:54:34 -0300 Subject: V4L/DVB (13131): pxa_camera: fix camera pixel format configuration A missed conversion prevents correct pixel format negotiation with client drivers. Reported-by: Antonio Ospite Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c index 6952e96..aa831d5 100644 --- a/drivers/media/video/pxa_camera.c +++ b/drivers/media/video/pxa_camera.c @@ -1432,7 +1432,9 @@ static int pxa_camera_set_fmt(struct soc_camera_device *icd, icd->sense = &sense; cam_f.fmt.pix.pixelformat = cam_fmt->fourcc; - ret = v4l2_subdev_call(sd, video, s_fmt, f); + ret = v4l2_subdev_call(sd, video, s_fmt, &cam_f); + cam_f.fmt.pix.pixelformat = pix->pixelformat; + *pix = cam_f.fmt.pix; icd->sense = NULL; -- cgit v0.10.2 From 76823b791d867c2ab563c237f188d0cbb4ced6e1 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Mon, 5 Oct 2009 12:54:54 -0300 Subject: V4L/DVB (13132): fix use-after-free Oops, resulting from a driver-core API change Commit b4028437876866aba4747a655ede00f892089e14 has broken again re-use of device objects across device_register() / device_unregister() cycles. Fix soc-camera by nullifying the struct after device_unregister(). Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c index 59aa7a3..36e617bd 100644 --- a/drivers/media/video/soc_camera.c +++ b/drivers/media/video/soc_camera.c @@ -1160,13 +1160,15 @@ void soc_camera_host_unregister(struct soc_camera_host *ici) if (icd->iface == ici->nr) { /* The bus->remove will be called */ device_unregister(&icd->dev); - /* Not before device_unregister(), .remove - * needs parent to call ici->ops->remove() */ - icd->dev.parent = NULL; - - /* If the host module is loaded again, device_register() - * would complain "already initialised" */ - memset(&icd->dev.kobj, 0, sizeof(icd->dev.kobj)); + /* + * Not before device_unregister(), .remove + * needs parent to call ici->ops->remove(). + * If the host module is loaded again, device_register() + * would complain "already initialised," since 2.6.32 + * this is also needed to prevent use-after-free of the + * device private data. + */ + memset(&icd->dev, 0, sizeof(icd->dev)); } } -- cgit v0.10.2 From e0a7e8a621666f9ce1373270bae061f92a2a2b87 Mon Sep 17 00:00:00 2001 From: HIRANO Takahito Date: Sun, 20 Sep 2009 08:57:49 -0300 Subject: V4L/DVB (13167): pt1: Fix a compile error on arm The lack of #include caused a compile error on some architectures. Signed-off-by: HIRANO Takahito Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb/pt1/pt1.c b/drivers/media/dvb/pt1/pt1.c index 81e623a..1fd8306 100644 --- a/drivers/media/dvb/pt1/pt1.c +++ b/drivers/media/dvb/pt1/pt1.c @@ -27,6 +27,7 @@ #include #include #include +#include #include "dvbdev.h" #include "dvb_demux.h" -- cgit v0.10.2 From 66349b4e7ab3825dbfc167a5f0309792a587adb7 Mon Sep 17 00:00:00 2001 From: Mike Isely Date: Mon, 21 Sep 2009 12:09:08 -0300 Subject: V4L/DVB (13169): bttv: Fix potential out-of-order field processing There is a subtle interaction in the bttv driver which can result in fields being repeatedly processed out of order. This is a problem specifically when running in V4L2_FIELD_ALTERNATE mode (probably the most common case). 1. The determination of which fields are associated with which buffers happens in videobuf, before the bttv driver gets a chance to queue the corresponding DMA. Thus by the point when the DMA is queued for a given buffer, the algorithm has to do the queuing based on the buffer's already assigned field type - not based on which field is "next" in the video stream. 2. The driver normally tries to queue both the top and bottom fields at the same time (see bttv_irq_next_video()). It tries to sort out top vs bottom by looking at the field type for the next 2 available buffers and assigning them appropriately. 3. However the bttv driver *always* actually processes the top field first. There's even an interrupt set aside for specifically recognizing when the top field has been processed so that it can be marked done even while the bottom field is still being DMAed. Given all of the above, if one gets into a situation where bttv_irq_next_video() gets entered when the first available buffer has been pre-associated as a bottom field, then the function is going to process the buffers out of order. That first available buffer will be put into the bottom field slot and the buffer after that will be put into the top field slot. Problem is, since the top field is always processed first by the driver, then that second buffer (the one after the first available buffer) will be the first one to be finished. Because of the strict fifo handling of all video buffers, then that top field won't be seen by the app until after the bottom field is also processed. Worse still, the app will get back the chronologically later bottom field first, *before* the top field is received. The buffer's timestamps will even be backwards. While not fatal to most TV apps, this behavior can subtlely degrade userspace deinterlacing (probably will cause jitter). That's probably why it has gone unnoticed. But it will also cause serious problems if the app in question discards all but the latest received buffer (a latency minimizing tactic) - causing one field to only ever be displayed since the other is now always late. Unfortunately once you get into this state, you're stuck this way - because having consumed two buffers, now the next time around the "first" available buffer will again be a bottom field and the same thing happens. How can we get into this state? In a perfect world, where there's always a few free buffers queued to the driver, it should be impossible. However if something disrupts streaming, e.g. if the userspace app can't queue free buffers fast enough for a moment due perhaps to a CPU scheduling glitch, then the driver can get momentarily starved and some number of fields will be dropped. That's OK. But if an odd number of fields get dropped, then that "first" available buffer might be the bottom field and now we're stuck... This patch fixes that problem by deliberately only setting up a single field for one frame if we don't get a top field as the first available buffer. By purposely skipping the other field, then we only handle a single buffer thus bringing things back into proper sync (i.e. top field first) for the next frame. To do this we just drop the few lines in bttv_irq_next_video() that attempt to set up the second buffer when that second buffer isn't for the bottom field. This is definitely a problem in when in V4L2_FIELD_ALTERNATE mode. In the other modes this change either has no effect or doesn't harm things any further anyway. Signed-off-by: Mike Isely CC: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c index 939d1e5..3ff84c8 100644 --- a/drivers/media/video/bt8xx/bttv-driver.c +++ b/drivers/media/video/bt8xx/bttv-driver.c @@ -3800,11 +3800,34 @@ bttv_irq_next_video(struct bttv *btv, struct bttv_buffer_set *set) if (!V4L2_FIELD_HAS_BOTH(item->vb.field) && (item->vb.queue.next != &btv->capture)) { item = list_entry(item->vb.queue.next, struct bttv_buffer, vb.queue); + /* Mike Isely - Only check + * and set up the bottom field in the logic + * below. Don't ever do the top field. This + * of course means that if we set up the + * bottom field in the above code that we'll + * actually skip a field. But that's OK. + * Having processed only a single buffer this + * time, then the next time around the first + * available buffer should be for a top field. + * That will then cause us here to set up a + * top then a bottom field in the normal way. + * The alternative to this understanding is + * that we set up the second available buffer + * as a top field, but that's out of order + * since this driver always processes the top + * field first - the effect will be the two + * buffers being returned in the wrong order, + * with the second buffer also being delayed + * by one field time (owing to the fifo nature + * of videobuf). Worse still, we'll be stuck + * doing fields out of order now every time + * until something else causes a field to be + * dropped. By effectively forcing a field to + * drop this way then we always get back into + * sync within a single frame time. (Out of + * order fields can screw up deinterlacing + * algorithms.) */ if (!V4L2_FIELD_HAS_BOTH(item->vb.field)) { - if (NULL == set->top && - V4L2_FIELD_TOP == item->vb.field) { - set->top = item; - } if (NULL == set->bottom && V4L2_FIELD_BOTTOM == item->vb.field) { set->bottom = item; -- cgit v0.10.2 From 2de26c0a4a218a351bb1970eeaddf2905b47ff13 Mon Sep 17 00:00:00 2001 From: Mike Isely Date: Mon, 21 Sep 2009 12:42:22 -0300 Subject: V4L/DVB (13170): bttv: Fix reversed polarity error when switching video standard The bttv driver function which handles switching of the video standard (set_tvnorm() in bttv-driver.c) includes a check which can optionally also reset the cropping configuration to a default value. It is "optional" based on a comparison of the cropcap parameters of the previous vs the newly requested video standard. The comparison is being done with a memcmp(), a function which only returns a true value if the comparison actually fails. This if-statement appears to have been written to assume wrong memcmp() semantics. That is, it was re-initializing the cropping configuration only if the new video standard did NOT have different cropcap values. That doesn't make any sense. One definitely should reset things if the cropcap parameters are different - if there's any comparison to made at all. The effect of this problem was that a transition from, say, PAL to NTSC would leave in place old cropping setup that made sense for the PAL geometry but not for NTSC. If the application doesn't care about cropping it also won't try to reset the cropping configuration, resulting in an improperly cropped video frame. In the case I was testing this actually caused black video frames to be displayed. Another interesting effect of this bug is that if one does something which does NOT change the video standard and this function is run, then the cropping setup gets reset anyway - again because of the backwards comparison. It turns out that just running anything which merely opens and closes the video device node (e.g. v4l-info) will cause this to happen. One can argue that simply opening the device node and not doing anything to it should not mess with any of its state - but because of this behavior, any TV app which does such things (e.g. xawtv) probably therefore doesn't see the problem. The solution is to fix the sense of the if-statement. It's easy to see how this mistake could have been made given how memcmp() works. The patch is therefore removal of a single "!" character from the if-statement in set_tvnorm in bttv-driver.c. Signed-off-by: Mike Isely CC: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c index 3ff84c8..a672401 100644 --- a/drivers/media/video/bt8xx/bttv-driver.c +++ b/drivers/media/video/bt8xx/bttv-driver.c @@ -1299,7 +1299,7 @@ set_tvnorm(struct bttv *btv, unsigned int norm) tvnorm = &bttv_tvnorms[norm]; - if (!memcmp(&bttv_tvnorms[btv->tvnorm].cropcap, &tvnorm->cropcap, + if (memcmp(&bttv_tvnorms[btv->tvnorm].cropcap, &tvnorm->cropcap, sizeof (tvnorm->cropcap))) { bttv_crop_reset(&btv->crop[0], norm); btv->crop[1] = btv->crop[0]; /* current = default */ -- cgit v0.10.2 From 96fbf771d86a90ff006bc62ca4d4de6474b3de31 Mon Sep 17 00:00:00 2001 From: Devin Heitmueller Date: Thu, 15 Oct 2009 01:14:34 -0300 Subject: V4L/DVB (13190): em28xx: fix panic that can occur when starting audio streaming Because the counters were not reset when starting up streaming, they would be reused from the previous run. This can result in cases such that when the second instance of streaming starts up, the "cnt" variable in em28xx_audio_isocirq() can end up being negative, resulting in attempting to write to memory before the start of runtime->dma_area (as well as having a negative number of bytes to copy). Signed-off-by: Devin Heitmueller CC: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/em28xx/em28xx-audio.c b/drivers/media/video/em28xx/em28xx-audio.c index 7bd8a70..ac947ae 100644 --- a/drivers/media/video/em28xx/em28xx-audio.c +++ b/drivers/media/video/em28xx/em28xx-audio.c @@ -383,6 +383,11 @@ static int snd_em28xx_hw_capture_free(struct snd_pcm_substream *substream) static int snd_em28xx_prepare(struct snd_pcm_substream *substream) { + struct em28xx *dev = snd_pcm_substream_chip(substream); + + dev->adev.hwptr_done_capture = 0; + dev->adev.capture_transfer_done = 0; + return 0; } -- cgit v0.10.2 From 78c948ab0cc44f9c8ae397d7d9d217bb498bfa2f Mon Sep 17 00:00:00 2001 From: Michael Krufky Date: Wed, 21 Oct 2009 18:27:29 -0300 Subject: V4L/DVB (13202): smsusb: add autodetection support for three additional Hauppauge USB IDs Add support for three new Hauppauge Device USB IDs: 2040:b900 2040:b910 2040:c000 Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb/siano/smsusb.c b/drivers/media/dvb/siano/smsusb.c index cb8a358..8f88a58 100644 --- a/drivers/media/dvb/siano/smsusb.c +++ b/drivers/media/dvb/siano/smsusb.c @@ -529,6 +529,12 @@ struct usb_device_id smsusb_id_table[] = { .driver_info = SMS1XXX_BOARD_SIANO_NICE }, { USB_DEVICE(0x187f, 0x0301), .driver_info = SMS1XXX_BOARD_SIANO_VENICE }, + { USB_DEVICE(0x2040, 0xb900), + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM }, + { USB_DEVICE(0x2040, 0xb910), + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM }, + { USB_DEVICE(0x2040, 0xc000), + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM }, { } /* Terminating entry */ }; -- cgit v0.10.2 From 1f95725755ab67f3198df3b5bf7517f926f310ca Mon Sep 17 00:00:00 2001 From: Mike Isely Date: Wed, 23 Sep 2009 18:06:57 -0300 Subject: V4L/DVB (13230): s2255drv: Don't conditionalize video buffer completion on waiting processes The s2255 driver had logic which aborted processing of a video frame if there was no process waiting on the video buffer in question. That simply doesn't work when the application is doing things in an asynchronous manner. If the application went to the trouble to queue the buffer in the first place, then the driver should always attempt to complete it - even if the application at that moment has its attention turned elsewhere. Applications which always blocked waiting for I/O on the capture device would not have been affected by this. Applications which *mostly* blocked waiting for I/O on the capture device probably only would have been somewhat affected (frame lossage, at a rate which goes up as the application blocks less). Applications which never blocked on the capture device (e.g. polling only) however would never have been able to receive any video frames, since in that case this "is anyone waiting on this?" check on the buffer never would have evalutated true. This patch just deletes that harmful check against the buffer's wait queue. Signed-off-by: Mike Isely Signed-off-by: Mauro Carvalho Chehab CC: stable@kernel.org diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c index 9e3262c..2c0bb06 100644 --- a/drivers/media/video/s2255drv.c +++ b/drivers/media/video/s2255drv.c @@ -598,11 +598,6 @@ static int s2255_got_frame(struct s2255_dev *dev, int chn, int jpgsize) buf = list_entry(dma_q->active.next, struct s2255_buffer, vb.queue); - if (!waitqueue_active(&buf->vb.done)) { - /* no one active */ - rc = -1; - goto unlock; - } list_del(&buf->vb.queue); do_gettimeofday(&buf->vb.ts); dprintk(100, "[%p/%d] wakeup\n", buf, buf->vb.i); -- cgit v0.10.2 From c94115ffc4d76089b26eee4d1cb56f1f6b631bd2 Mon Sep 17 00:00:00 2001 From: Henrik Kurelid Date: Sat, 3 Oct 2009 05:37:58 -0300 Subject: V4L/DVB (13237): firedtv: length field corrupt in ca2host if length>127 This solves a problem in firedtv that has become major for Swedish DVB-T users the last month or so. It will most likely solve issues seen by other users as well. If the length of an AVC message is greater than 127, the length field should be encoded in LV mode instead of V mode. V mode can only be used if the length is 127 or less. This patch ensures that the CA_PMT message is always encoded in LV mode so PMT message of greater lengths can be supported. Signed-off-by: Henrik Kurelid Signed-off-by: Stefan Richter Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb/firewire/firedtv-avc.c b/drivers/media/dvb/firewire/firedtv-avc.c index d1b67fe..485d061 100644 --- a/drivers/media/dvb/firewire/firedtv-avc.c +++ b/drivers/media/dvb/firewire/firedtv-avc.c @@ -1050,28 +1050,28 @@ int avc_ca_pmt(struct firedtv *fdtv, char *msg, int length) c->operand[4] = 0; /* slot */ c->operand[5] = SFE_VENDOR_TAG_CA_PMT; /* ca tag */ c->operand[6] = 0; /* more/last */ - /* c->operand[7] = XXXprogram_info_length + 17; */ /* length */ - c->operand[8] = list_management; - c->operand[9] = 0x01; /* pmt_cmd=OK_descramble */ + /* Use three bytes for length field in case length > 127 */ + c->operand[10] = list_management; + c->operand[11] = 0x01; /* pmt_cmd=OK_descramble */ /* TS program map table */ - c->operand[10] = 0x02; /* Table id=2 */ - c->operand[11] = 0x80; /* Section syntax + length */ - /* c->operand[12] = XXXprogram_info_length + 12; */ - c->operand[13] = msg[1]; /* Program number */ - c->operand[14] = msg[2]; - c->operand[15] = 0x01; /* Version number=0 + current/next=1 */ - c->operand[16] = 0x00; /* Section number=0 */ - c->operand[17] = 0x00; /* Last section number=0 */ - c->operand[18] = 0x1f; /* PCR_PID=1FFF */ - c->operand[19] = 0xff; - c->operand[20] = (program_info_length >> 8); /* Program info length */ - c->operand[21] = (program_info_length & 0xff); + c->operand[12] = 0x02; /* Table id=2 */ + c->operand[13] = 0x80; /* Section syntax + length */ + /* c->operand[14] = XXXprogram_info_length + 12; */ + c->operand[15] = msg[1]; /* Program number */ + c->operand[16] = msg[2]; + c->operand[17] = 0x01; /* Version number=0 + current/next=1 */ + c->operand[18] = 0x00; /* Section number=0 */ + c->operand[19] = 0x00; /* Last section number=0 */ + c->operand[20] = 0x1f; /* PCR_PID=1FFF */ + c->operand[21] = 0xff; + c->operand[22] = (program_info_length >> 8); /* Program info length */ + c->operand[23] = (program_info_length & 0xff); /* CA descriptors at programme level */ read_pos = 6; - write_pos = 22; + write_pos = 24; if (program_info_length > 0) { pmt_cmd_id = msg[read_pos++]; if (pmt_cmd_id != 1 && pmt_cmd_id != 4) @@ -1113,8 +1113,10 @@ int avc_ca_pmt(struct firedtv *fdtv, char *msg, int length) c->operand[write_pos++] = 0x00; c->operand[write_pos++] = 0x00; - c->operand[7] = write_pos - 8; - c->operand[12] = write_pos - 13; + c->operand[7] = 0x82; + c->operand[8] = (write_pos - 10) >> 8; + c->operand[9] = (write_pos - 10) & 0xff; + c->operand[14] = write_pos - 15; crc32_csum = crc32_be(0, &c->operand[10], c->operand[12] - 1); c->operand[write_pos - 4] = (crc32_csum >> 24) & 0xff; -- cgit v0.10.2 From dcff9cfe432c74b382cea327509ede2e114b1615 Mon Sep 17 00:00:00 2001 From: Stefan Richter Date: Sat, 17 Oct 2009 17:46:25 -0300 Subject: V4L/DVB (13240): firedtv: fix regression: tuning fails due to bogus error return Since 2.6.32(-rc1), DVB core checks the return value of dvb_frontend_ops.set_frontend. Now it becomes apparent that firedtv always returned a bogus value from its set_frontend method. CC: stable@kernel.org Signed-off-by: Stefan Richter Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb/firewire/firedtv-fe.c b/drivers/media/dvb/firewire/firedtv-fe.c index 7ba4363..e49cdc8 100644 --- a/drivers/media/dvb/firewire/firedtv-fe.c +++ b/drivers/media/dvb/firewire/firedtv-fe.c @@ -141,18 +141,12 @@ static int fdtv_read_uncorrected_blocks(struct dvb_frontend *fe, u32 *ucblocks) return -EOPNOTSUPP; } -#define ACCEPTED 0x9 - static int fdtv_set_frontend(struct dvb_frontend *fe, struct dvb_frontend_parameters *params) { struct firedtv *fdtv = fe->sec_priv; - /* FIXME: avc_tuner_dsd never returns ACCEPTED. Check status? */ - if (avc_tuner_dsd(fdtv, params) != ACCEPTED) - return -EINVAL; - else - return 0; /* not sure of this... */ + return avc_tuner_dsd(fdtv, params); } static int fdtv_get_frontend(struct dvb_frontend *fe, -- cgit v0.10.2 From b6ef8836c1ff5199abd40cfba162052bc7e8af00 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erik=20Andr=C3=A9n?= Date: Sun, 27 Sep 2009 10:11:43 -0300 Subject: V4L/DVB (13255): gspca - m5602-s5k4aa: Add vflip quirk for the Bruneinit laptop MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds a vflip quirk for the Bruneinit laptop. Thanks to Jörg for the report Signed-off-by: Erik Andrén Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/gspca/m5602/m5602_s5k4aa.c b/drivers/media/video/gspca/m5602/m5602_s5k4aa.c index 59400e8..f580b61 100644 --- a/drivers/media/video/gspca/m5602/m5602_s5k4aa.c +++ b/drivers/media/video/gspca/m5602/m5602_s5k4aa.c @@ -35,6 +35,13 @@ static const struct dmi_system_id s5k4aa_vflip_dmi_table[] = { { + .ident = "BRUNEINIT", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "BRUNENIT"), + DMI_MATCH(DMI_PRODUCT_NAME, "BRUNENIT"), + DMI_MATCH(DMI_BOARD_VERSION, "00030D0000000001") + } + }, { .ident = "Fujitsu-Siemens Amilo Xa 2528", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"), -- cgit v0.10.2 From 2339a1887dab469bb4bae56aa7eca3a5e05ecde7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erik=20Andr=C3=A9n?= Date: Sun, 27 Sep 2009 10:20:21 -0300 Subject: V4L/DVB (13256): gspca - m5602-s5k4aa: Add another MSI GX700 vflip quirk MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds another vflip quirk for the MSI GX700. Thanks to John Katzmaier for reporting. Signed-off-by: Erik Andrén Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/gspca/m5602/m5602_s5k4aa.c b/drivers/media/video/gspca/m5602/m5602_s5k4aa.c index f580b61..ef4ae68 100644 --- a/drivers/media/video/gspca/m5602/m5602_s5k4aa.c +++ b/drivers/media/video/gspca/m5602/m5602_s5k4aa.c @@ -64,6 +64,13 @@ static .matches = { DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star International"), DMI_MATCH(DMI_PRODUCT_NAME, "GX700"), + DMI_MATCH(DMI_BIOS_DATE, "12/02/2008") + } + }, { + .ident = "MSI GX700", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star International"), + DMI_MATCH(DMI_PRODUCT_NAME, "GX700"), DMI_MATCH(DMI_BIOS_DATE, "07/26/2007") } }, { -- cgit v0.10.2 From 81191f694cb507c49d3c7aa6238dcc0a83ad4001 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erik=20Andr=C3=A9n?= Date: Sat, 3 Oct 2009 10:01:41 -0300 Subject: V4L/DVB (13257): gspca - m5602-s5k4aa: Add vflip for Fujitsu Amilo Xi 2528 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds a vflip quirk for the Fujitsu Amilo Xi 2528. Thanks to Evgeny for the report. Signed-off-by: Erik Andrén Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/gspca/m5602/m5602_s5k4aa.c b/drivers/media/video/gspca/m5602/m5602_s5k4aa.c index ef4ae68..a27afeb 100644 --- a/drivers/media/video/gspca/m5602/m5602_s5k4aa.c +++ b/drivers/media/video/gspca/m5602/m5602_s5k4aa.c @@ -48,6 +48,12 @@ static DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Xa 2528") } }, { + .ident = "Fujitsu-Siemens Amilo Xi 2528", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"), + DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Xi 2528") + } + }, { .ident = "Fujitsu-Siemens Amilo Xi 2550", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"), -- cgit v0.10.2 From 32345b059676169444d8d3c4a59009adcdf93885 Mon Sep 17 00:00:00 2001 From: Theodore Kilgore Date: Sun, 1 Nov 2009 12:59:42 -0300 Subject: V4L/DVB (13264): gspca_mr97310a: Change vstart for CIF sensor type 1 cams gspca_mr97310a: Change vstart for CIF sensor type 1 cams This fixes the distortion at the end of the frame, and avoids the bad frame dropping done because of this distortion, trippling the framerate! Signed-off-by: Theodore Kilgore Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/gspca/mr97310a.c b/drivers/media/video/gspca/mr97310a.c index 140c8f3..f8328b9 100644 --- a/drivers/media/video/gspca/mr97310a.c +++ b/drivers/media/video/gspca/mr97310a.c @@ -483,7 +483,7 @@ static int start_cif_cam(struct gspca_dev *gspca_dev) data[3] = 0x2c; /* reg 2, H size/8 */ data[4] = 0x48; /* reg 3, V size/4 */ data[6] = 0x06; /* reg 5, H start */ - data[8] = 0x06 + sd->sensor_type; /* reg 7, V start */ + data[8] = 0x06 - sd->sensor_type; /* reg 7, V start */ break; } err_code = mr_write(gspca_dev, 11); -- cgit v0.10.2 From d514edac5df2149207f1ae2f52de63882c692eec Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Wed, 4 Nov 2009 14:18:04 -0300 Subject: V4L/DVB (13286): pxa-camera: Fix missing sched.h Required for wakeup call. Signed-off-by: Jonathan Cameron Acked-by: Guennadi Liakhovetski Signed-off-by: Douglas Schilling Landgraf Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c index aa831d5..51b683c 100644 --- a/drivers/media/video/pxa_camera.c +++ b/drivers/media/video/pxa_camera.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include -- cgit v0.10.2 From 7157fbd0ed1a00024fb915cfa5ed93fb4ce9dfaf Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Wed, 4 Nov 2009 15:26:59 -0300 Subject: V4L/DVB (13287): ce6230 - saa7164-cmd: Fix wrong sizeof Which is why I have always preferred sizeof(struct foo) over sizeof(var). Cc: Antti Palosaari Acked-by: Steven Toth Signed-off-by: Jean Delvare Signed-off-by: Douglas Schilling Landgraf Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb/dvb-usb/ce6230.c b/drivers/media/dvb/dvb-usb/ce6230.c index 0737c63..3df2045 100644 --- a/drivers/media/dvb/dvb-usb/ce6230.c +++ b/drivers/media/dvb/dvb-usb/ce6230.c @@ -105,7 +105,7 @@ static int ce6230_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int i = 0; struct req_t req; int ret = 0; - memset(&req, 0, sizeof(&req)); + memset(&req, 0, sizeof(req)); if (num > 2) return -EINVAL; diff --git a/drivers/media/video/saa7164/saa7164-cmd.c b/drivers/media/video/saa7164/saa7164-cmd.c index c45966e..9c1d3ac 100644 --- a/drivers/media/video/saa7164/saa7164-cmd.c +++ b/drivers/media/video/saa7164/saa7164-cmd.c @@ -347,7 +347,7 @@ int saa7164_cmd_send(struct saa7164_dev *dev, u8 id, tmComResCmd_t command, /* Prepare some basic command/response structures */ memset(&command_t, 0, sizeof(command_t)); - memset(&response_t, 0, sizeof(&response_t)); + memset(&response_t, 0, sizeof(response_t)); pcommand_t = &command_t; presponse_t = &response_t; command_t.id = id; -- cgit v0.10.2 From a2e35af6c756b5fa827fec5e0431cf2ce449beef Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 4 Nov 2009 11:09:12 -0300 Subject: V4L/DVB (13309): uvcvideo: Ignore the FIX_BANDWIDTH for compressed video The FIX_BANDWIDTH quirk tries to work around cameras requesting the maximum bandwidth regardless of the image size by computing a bandwidth estimate. This works only for uncompressed frames. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c index f960e8e..a6e41d1 100644 --- a/drivers/media/video/uvc/uvc_video.c +++ b/drivers/media/video/uvc/uvc_video.c @@ -90,7 +90,8 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream, ctrl->dwMaxVideoFrameSize = frame->dwMaxVideoFrameBufferSize; - if (stream->dev->quirks & UVC_QUIRK_FIX_BANDWIDTH && + if (!(format->flags & UVC_FMT_FLAG_COMPRESSED) && + stream->dev->quirks & UVC_QUIRK_FIX_BANDWIDTH && stream->intf->num_altsetting > 1) { u32 interval; u32 bandwidth; -- cgit v0.10.2 From 2e8961330ec4b558a0f4db18ab5fb566842f492b Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 4 Nov 2009 13:11:10 -0300 Subject: V4L/DVB (13311): uvcvideo: Fix compilation warning with 2.6.32 due to type mismatch with abs() The abs() macro has changed in 2.6.32 and returns a long instead of an int. Fix the driver to avoid compilation warnings. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/uvc/uvc_ctrl.c b/drivers/media/video/uvc/uvc_ctrl.c index c3225a5..1b89735 100644 --- a/drivers/media/video/uvc/uvc_ctrl.c +++ b/drivers/media/video/uvc/uvc_ctrl.c @@ -348,7 +348,7 @@ static void uvc_ctrl_set_zoom(struct uvc_control_mapping *mapping, __s32 value, __u8 *data) { data[0] = value == 0 ? 0 : (value > 0) ? 1 : 0xff; - data[2] = min(abs(value), 0xff); + data[2] = min((int)abs(value), 0xff); } static struct uvc_control_mapping uvc_ctrl_mappings[] = { -- cgit v0.10.2 From 4007a672abd88091e3cced158ec491d41c0c454c Mon Sep 17 00:00:00 2001 From: Michael Krufky Date: Wed, 4 Nov 2009 14:19:35 -0300 Subject: V4L/DVB (13313): saa7134: add support for FORCE_TS_VALID mode for mpeg ts input When FORCE_TS_VALID mode is enabled, the saa713x will accept MPEG TS input without requiring TS_VALID set high. This is required for some new boards to function properly, due to the hardware design implementation. The configuration is toggled within the board setup configuration. Boards that do not have this bit set will function as before with no change. Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/saa7134/saa7134-ts.c b/drivers/media/video/saa7134/saa7134-ts.c index 3fa6522..03488ba 100644 --- a/drivers/media/video/saa7134/saa7134-ts.c +++ b/drivers/media/video/saa7134/saa7134-ts.c @@ -262,11 +262,13 @@ int saa7134_ts_start(struct saa7134_dev *dev) switch (saa7134_boards[dev->board].ts_type) { case SAA7134_MPEG_TS_PARALLEL: saa_writeb(SAA7134_TS_SERIAL0, 0x40); - saa_writeb(SAA7134_TS_PARALLEL, 0xec); + saa_writeb(SAA7134_TS_PARALLEL, 0xec | + (saa7134_boards[dev->board].ts_force_val << 4)); break; case SAA7134_MPEG_TS_SERIAL: saa_writeb(SAA7134_TS_SERIAL0, 0xd8); - saa_writeb(SAA7134_TS_PARALLEL, 0x6c); + saa_writeb(SAA7134_TS_PARALLEL, 0x6c | + (saa7134_boards[dev->board].ts_force_val << 4)); saa_writeb(SAA7134_TS_PARALLEL_SERIAL, 0xbc); saa_writeb(SAA7134_TS_SERIAL1, 0x02); break; diff --git a/drivers/media/video/saa7134/saa7134.h b/drivers/media/video/saa7134/saa7134.h index 6ee3e9b..f8697d4 100644 --- a/drivers/media/video/saa7134/saa7134.h +++ b/drivers/media/video/saa7134/saa7134.h @@ -360,6 +360,7 @@ struct saa7134_board { enum saa7134_mpeg_type mpeg; enum saa7134_mpeg_ts_type ts_type; unsigned int vid_port_opts; + unsigned int ts_force_val:1; }; #define card_has_radio(dev) (NULL != saa7134_boards[dev->board].radio.name) -- cgit v0.10.2 From 22370ef5035f206283505409c9a64a595c5c7320 Mon Sep 17 00:00:00 2001 From: Michael Krufky Date: Wed, 4 Nov 2009 14:23:57 -0300 Subject: V4L/DVB (13314): saa7134: set ts_force_val for the Hauppauge WinTV HVR-1150 The Hauppauge WinTV HVR-1150 retail boards require the FORCE_TS_VALID bit to be set in order to function properly. This change will work on the early revisions on the board as well, but the final revision will not function without this change. Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/saa7134/saa7134-cards.c b/drivers/media/video/saa7134/saa7134-cards.c index 71145bf..0901322 100644 --- a/drivers/media/video/saa7134/saa7134-cards.c +++ b/drivers/media/video/saa7134/saa7134-cards.c @@ -3428,6 +3428,7 @@ struct saa7134_board saa7134_boards[] = { .tuner_config = 3, .mpeg = SAA7134_MPEG_DVB, .ts_type = SAA7134_MPEG_TS_SERIAL, + .ts_force_val = 1, .gpiomask = 0x0800100, /* GPIO 21 is an INPUT */ .inputs = {{ .name = name_tv, -- cgit v0.10.2