Re: cx23885-input.c does in fact use a workqueue....
On Sun, Feb 13, 2011 at 08:35:22PM -0500, Andy Walls wrote: > Tejun, > > I just noticed this commit: > > commit 8c71778cbf2c8beaefaa2dee5478aa0622d96682 > Author: Tejun Heo > Date: Fri Dec 24 16:14:20 2010 +0100 > > media/video: don't use flush_scheduled_work() > > This patch converts the remaining users of flush_scheduled_work() in > media/video. > > * bttv-input.c and cx23885-input.c don't use workqueue at all. No > need to flush. > [...] > > > The cx23885 driver does in fact schedule work for IR input handling: > > Here's where it is scheduled for CX23888 chips: > > http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx23885/cx23885-ir.c;h=7125247dd25558678c823ee3262675570c9aa630;hb=HEAD#l76 > > Here's where it is scheduled for CX23885 chips: > > http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx23885/cx23885-core.c;h=359882419b7f588b7c698dbcfb6a39ddb1603301;hb=HEAD#l1861 > > > The two different chips are handled slightly differently because > > a. the CX23888 IR unit is accessable via a PCI register block. The IR > IRQ can be acknowledged with direct PCI register accesses in an > interrupt context, and the IR pulse FIFO serviced later in a workqueue > context. > > b. the CX23885 IR unit is accessed over an I2C bus. The CX23885 A/V IRQ > has to be masked in an interrupt context (with PCI registers accesses). > Then the CX23885 A/V unit's IR IRQ is ack'ed over I2C in a workqueue > context and the IR pulse FIFO is also serviced over I2C in a workqueue > context. > > > So what should be done about the flush_scheduled_work()? I think it > belongs there. > Convert to using threaded irq? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT FIXES for 2.6.38] Fix cx23885 and cx25840 regressions
Mauro, Please pull the following regression fixes (and related compiler squawk fix) for 2.6.38. Thanks go to Sven Barth for reporting the regression with the CX2583x chips in cx25840 and providing a patch. Thanks also go to Mark Zimmerman for climinb the git learning curve and devoting the time perform a git bisect to isolate the cx23885 regression. Regards, Andy The following changes since commit cf720fed25b8078ce0d6a10036dbf7a0baded679: [media] add support for Encore FM3 (2011-01-19 16:42:42 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git cx-fix-38 Andy Walls (2): cx23885: Revert "Check for slave nack on all transactions" cx23885: Remove unused 'err:' labels to quiet compiler warning Sven Barth (1): cx25840: fix probing of cx2583x chips drivers/media/video/cx23885/cx23885-i2c.c | 10 -- drivers/media/video/cx25840/cx25840-core.c |3 ++- 2 files changed, 2 insertions(+), 11 deletions(-) -- 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
cx23885-input.c does in fact use a workqueue....
Tejun, I just noticed this commit: commit 8c71778cbf2c8beaefaa2dee5478aa0622d96682 Author: Tejun Heo Date: Fri Dec 24 16:14:20 2010 +0100 media/video: don't use flush_scheduled_work() This patch converts the remaining users of flush_scheduled_work() in media/video. * bttv-input.c and cx23885-input.c don't use workqueue at all. No need to flush. [...] The cx23885 driver does in fact schedule work for IR input handling: Here's where it is scheduled for CX23888 chips: http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx23885/cx23885-ir.c;h=7125247dd25558678c823ee3262675570c9aa630;hb=HEAD#l76 Here's where it is scheduled for CX23885 chips: http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx23885/cx23885-core.c;h=359882419b7f588b7c698dbcfb6a39ddb1603301;hb=HEAD#l1861 The two different chips are handled slightly differently because a. the CX23888 IR unit is accessable via a PCI register block. The IR IRQ can be acknowledged with direct PCI register accesses in an interrupt context, and the IR pulse FIFO serviced later in a workqueue context. b. the CX23885 IR unit is accessed over an I2C bus. The CX23885 A/V IRQ has to be masked in an interrupt context (with PCI registers accesses). Then the CX23885 A/V unit's IR IRQ is ack'ed over I2C in a workqueue context and the IR pulse FIFO is also serviced over I2C in a workqueue context. So what should be done about the flush_scheduled_work()? I think it belongs there. 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: Siano SMS1140 DVB Receiver on Debian 5.0 (Lenny)
Em 11-02-2011 12:39, jamen...@bol.com.br escreveu: > Hi everyone. > > I'm sorry if my question is a newbie question. I have a DVB receiver (Siano > SMS1140). > using settings for BRAZIL I'm assuming that what you're trying to do is to use it for ISDB-T, right? You may find some useful info (in Portuguese) at: http://br-linux.org/2010/tv-digital-brasileira-no-linux-mais-drivers-experimentais-disponiveis/ The tree indicated there is outdated (it was a test tree I've created some time ago). The latest drivers are available at the main devel tree. You may use the media_build tree to download and compile with your kernel version: http://git.linuxtv.org/media_build.git Also, AFAIK, vdr doesn't work with ISDB-T. The only application that I know for sure that works with h.264/aac isdb-t decoding is vlc. Cheers, Mauro. -- 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: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sun, Feb 13, 2011 at 04:26:50PM -0500, Andy Walls wrote: > On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote: > > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman wrote: > > > > Clearly my previous bisection went astray; I think I have a more > > > > sensible result this time. > > > > > > > > qpc$ git bisect good > > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > > > Author: Jean Delvare > > > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > > > ? ?other transactions too. > > > > > > This could be a combination of the xc5000 doing clock stretching and > > > the cx23885 i2c master not properly implementing clock stretch. In > > > the past I've seen i2c masters broken in their handling of clock > > > stretching where they treat it as a NAK. > > > > > > The xc5000 being one of the few devices that actually does i2c clock > > > stretching often exposes cases where it is improperly implemented in > > > the i2c master driver (I've had to fix this with several bridges). > > > > > > > Thanks for your insight. I am looking at cx23885-i2c.c and there is no > > clock stretching logic in i2c_slave_did_ack(). Would this be the > > right place for it to be? Can you point me to an example of another > > driver that does it correctly? I really don't know what I am doing... > > > Mark, > > You don't have much hope of getting that right without the CX23885 > datasheet. > > Let's just get the bad commit reverted and into 2.6.38, and fix what > used to work for you. Doing a git bisect is enough work for anyone. > > I'll do a patch to revert the commit and ask it to be pulled for > 2.6.38-rc-whatever. I'll be sure to add a > > Bisected-by: Mark Zimmerman > > tag to the patch. (The Linux Kernel devs understand the work involved > to do a bisection.) > > > Later, if I can work up a patch to deal with clock stretching properly, > I may ask you to test. > Thanks, that would be great. Meanwhile, I have built a 2.6.37 with the offending commit removed: git bisect reset git checkout v2.6.37 git revert 44835f197bf1e3f57464f23dfb239fef06cf89be and it seems to be working fine using both tuners: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... Thanks again -- Mark -- 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
Fwd: v4l2 lost frame when use with epoll (uvc bug)
-- Forwarded message -- From: Hans Verkuil Date: 2011/2/13 Subject: Re: v4l2 lost frame when use with epoll To: xinglp 抄送： b...@thedirks.org On Sunday, February 13, 2011 13:33:27 xinglp wrote: > 2011/2/13 Hans Verkuil : > > On Sunday, February 13, 2011 09:18:41 xinglp wrote: > >> It seems like that epoll_wait() do not return as soon as possible when one > >> frame be captured, it only returns when 4(set by > >> ioctl(..VIDIOC_REQBUFS..).) > >> frames be captured. > >> And v4l2_buffer::sequence indecates one lost per 4 frames. > > > > What hardware/driver are you using? > I' using uvcvideo. I've tried two cheap usbcam at two PC. > > lsusb > Bus 002 Device 002: ID 1871:01f0 Aveo Technology Corp. > > lsmod > Module Size Used by > uvcvideo 54924 - > videodev 65184 - > > DG45ID mainboard and a hp2530p notebook. A quick follow-up: I could reproduce this with uvc. It works fine with vivi and gspca, so this seems to be a uvc bug. Please post this bug report to the linux-media mailinglist with a CC to Laurent Pinchart who is the uvc maintainer. Regards, Hans > > >> The source in attachment can reproducte it, run it with option --epoll > >> to make it use epoll. > >> > >> The attachment is a modified version of the follow URL. > >> http://v4l2spec.bytesex.org/v4l2spec/capture.c > >> > > > > I can't reproduce this with the vivi driver. It's much more likely to be a > > driver issue. > On my machine, vivi even not work with epoll(). only capture one frame > and stop.(epoll_wait() never return again.) > > > > > BTW, it's much better to mail the linux-media mailinglist. Also note that > > Bill > > is no longer involved in V4L. > I can't subscribe any kernel maillist successfully. > > > Regards, > > > >Hans > > > > -- > > Hans Verkuil - video4linux developer - sponsored by Cisco > > > > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sun, 2011-02-13 at 16:26 -0500, Andy Walls wrote: > On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote: > > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman wrote: > > > > Clearly my previous bisection went astray; I think I have a more > > > > sensible result this time. > > > > > > > > qpc$ git bisect good > > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > > > Author: Jean Delvare > > > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > > > ? ?other transactions too. > > > > > > This could be a combination of the xc5000 doing clock stretching and > > > the cx23885 i2c master not properly implementing clock stretch. In > > > the past I've seen i2c masters broken in their handling of clock > > > stretching where they treat it as a NAK. > > > > > > The xc5000 being one of the few devices that actually does i2c clock > > > stretching often exposes cases where it is improperly implemented in > > > the i2c master driver (I've had to fix this with several bridges). > > > Devin, I just checked. The CX23885 driver *is* setting up to allow slaves to stretch the clock. By analysis, I have confirmed that Jean's sugguested patch that I moved forward was wrong for the hardware's behavior. When the cx23885 I2C routines decide to set the I2C_EXTEND flag (and maybe the I2C_NOSTOP flag), we most certainly should *not* be expecting an ACK from the particular hardware register. The original commit should certainly be reverted. Checking for slave ACK/NAK will need to be done with a little more care; so for now, I'll settle for ignoring them. 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
[PATCH] DM04/QQBOX Fix issue with firmware release and cold reset
Fix issue where firmware does not release on cold reset.
Also, default firmware never cold resets in multi tuner
environment.
Signed-off-by: Malcolm Priestley
---
drivers/media/dvb/dvb-usb/lmedm04.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c
b/drivers/media/dvb/dvb-usb/lmedm04.c
index cd26e7c..ec0f5a7 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -747,7 +747,7 @@ static int lme_firmware_switch(struct usb_device *udev, int
cold)
fw_lme = fw_s0194;
ret = request_firmware(&fw, fw_lme, &udev->dev);
if (ret == 0) {
- cold = 0;/*lme2510-s0194 cannot cold reset*/
+ cold = 0;
break;
}
dvb_usb_lme2510_firmware = TUNER_LG;
@@ -769,8 +769,10 @@ static int lme_firmware_switch(struct usb_device *udev,
int cold)
case TUNER_S7395:
fw_lme = fw_c_s7395;
ret = request_firmware(&fw, fw_lme, &udev->dev);
- if (ret == 0)
+ if (ret == 0) {
+ cold = 0;
break;
+ }
dvb_usb_lme2510_firmware = TUNER_LG;
case TUNER_LG:
fw_lme = fw_c_lg;
@@ -796,14 +798,14 @@ static int lme_firmware_switch(struct usb_device *udev,
int cold)
ret = lme2510_download_firmware(udev, fw);
}
+ release_firmware(fw);
+
if (cold) {
info("FRM Changing to %s firmware", fw_lme);
lme_coldreset(udev);
return -ENODEV;
}
- release_firmware(fw);
-
return ret;
}
@@ -1220,5 +1222,5 @@ module_exit(lme2510_module_exit);
MODULE_AUTHOR("Malcolm Priestley ");
MODULE_DESCRIPTION("LME2510(C) DVB-S USB2.0");
-MODULE_VERSION("1.80");
+MODULE_VERSION("1.81");
MODULE_LICENSE("GPL");
--
1.7.1
--
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 v8 07/12] media: Entities, pads and links enumeration
Hi Laurent, Please see my little comment below.. On 2011-01-27 13:30, Laurent Pinchart wrote: > Create the following two ioctls and implement them at the media device > level to enumerate entities, pads and links. > > - MEDIA_IOC_ENUM_ENTITIES: Enumerate entities and their properties > - MEDIA_IOC_ENUM_LINKS: Enumerate all pads and links for a given entity > > Entity IDs can be non-contiguous. Userspace applications should > enumerate entities using the MEDIA_ENT_ID_FLAG_NEXT flag. When the flag > is set in the entity ID, the MEDIA_IOC_ENUM_ENTITIES will return the > next entity with an ID bigger than the requested one. > > Only forward links that originate at one of the entity's source pads are > returned during the enumeration process. > > Signed-off-by: Laurent Pinchart > Signed-off-by: Sakari Ailus > --- > Documentation/DocBook/media-entities.tmpl |8 + > Documentation/DocBook/v4l/media-controller.xml |2 + > .../DocBook/v4l/media-ioc-device-info.xml |3 +- > .../DocBook/v4l/media-ioc-enum-entities.xml| 308 > > Documentation/DocBook/v4l/media-ioc-enum-links.xml | 202 + > drivers/media/media-device.c | 123 > include/linux/media.h | 85 ++ > include/media/media-entity.h | 24 +-- > 8 files changed, 731 insertions(+), 24 deletions(-) > create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-entities.xml > create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-links.xml > ... > diff --git a/Documentation/DocBook/v4l/media-ioc-enum-links.xml > b/Documentation/DocBook/v4l/media-ioc-enum-links.xml > new file mode 100644 > index 000..daf0360 > --- /dev/null > +++ b/Documentation/DocBook/v4l/media-ioc-enum-links.xml > @@ -0,0 +1,202 @@ > + > + > +ioctl MEDIA_IOC_ENUM_LINKS > +&manvol; > + > + > + > +MEDIA_IOC_ENUM_LINKS > +Enumerate all pads and links for a given entity > + > + > + > + > + > + int ioctl > + int fd > + int request > + struct media_links_enum > *argp > + > + > + > + > + > +Arguments > + > + > + > + fd > + > + File descriptor returned by > +linkend='media-func-open'>open(). > + > + > + > + request > + > + MEDIA_IOC_ENUM_LINKS > + > + > + > + argp > + > + > + > + > + > + > + > + > +Description > + > +To enumerate pads and/or links for a given entity, applications set > +the entity field of a &media-links-enum; structure and initialize the > +&media-pad-desc; and &media-link-desc; structure arrays pointed by the > +pads and links > fields. > +They then call the MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this > +structure. > +If the pads field is not NULL, the > driver > +fills the pads array with information about > the > +entity's pads. The array must have enough room to store all the entity's > +pads. The number of pads can be retrieved with the > &MEDIA-IOC-ENUM-ENTITIES; > +ioctl. > +If the links field is not NULL, the > driver > +fills the links array with information about > the > +entity's outbound links. The array must have enough room to store all the > +entity's outbound links. The number of outbound links can be retrieved > with > +the &MEDIA-IOC-ENUM-ENTITIES; ioctl. > +Only forward links that originate at one of the entity's source > pads > +are returned during the enumeration process. > + > + > + struct media_links_enum > + > +&cs-str; > + > + > + __u32 > + entity > + Entity id, set by the application. > + > + > + struct &media-pad-desc; > + *pads > + Pointer to a pads array allocated by the application. Ignored > + if NULL. > + > + > + struct &media-link-desc; > + *links > + Pointer to a links array allocated by the application. > Ignored > + if NULL. > + > + > + > + > + > + > + struct media_pad_desc > + > +&cs-str; > + > + > + __u32 > + entity > + ID of the entity this pad belongs to. > + > + > + __u16 > + index > + 0-based pad index. > + > + > + __u32 > + flags > + Pad flags, see for more > details. > + > + > + > + > + > + > + Media pad flags > + > + > + > + > + > + MEDIA_PAD_FL_INPUT > + Input pad, relative to the entity. Input pads sink data and > + are targets of links. > + > + > + MEDIA_PAD_FL_OUTPUT > + Output pad, relative to the entity. Output pads source data > + and are origins of
Re: [PATCH 0/8] Port xf86-video-v4l driver to V4L2 version 2
Em 13-02-2011 17:15, Steven Karatnyk escreveu: > Note: I've added a news item to the main page regarding V4L1's removal from > the kernel. In addition, I've attempted to summarize what the video-v4l > module's purpose, as well as how to use it, by sewing together the info from > a bunch of sources (such as Alex's, Mauro comments, etc etc) > > - http://www.linuxtv.org/wiki/index.php/Main_Page > - http://www.linuxtv.org/wiki/index.php/Xf86-video-v4l Thank you for adding them to the wiki. The info there seems consistent. Currently, just some PCI devices implement the V4L2 overlay support, needed by the driver to work. I'll eventually implement other modes like mmap and userptr one day, but what I want to do first is to make it support the textured video. I'm not sure about the other apps, but xawtv works fine with the v4l driver. Cheers, Mauro -- 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: radio tuner but no V4L2_CAP_RADIO ?
On Sun, 2011-02-13 at 20:39 +0100, Martin Dauskardt wrote: > The following cards have a Multi Standard tuner with radio: > KNC One TV-Station DVR (saa7134) FMD1216MEX > HVR1300 (cx88-blackbird) Philips FMD1216ME > /dev/radio0 is present and working. > > Both drivers do not report the radio when using VIDIOC_QUERYCAP. > > Is this a bug, or is there no clear specification that a driver must report > this? The V4L2 API spec is unclear on this subject in most places, but it is *very* clear here: http://linuxtv.org/downloads/v4l-dvb-apis/radio.html#id2682669 "Devices supporting the radio interface set the V4L2_CAP_RADIO and V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl." Those drivers have bugs. Regards, Andy > Is there are any other way to check radio for support (besides trying to open > a matching radio device) ? > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote: > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman wrote: > > > Clearly my previous bisection went astray; I think I have a more > > > sensible result this time. > > > > > > qpc$ git bisect good > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > > Author: Jean Delvare > > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > > ? ?other transactions too. > > > > This could be a combination of the xc5000 doing clock stretching and > > the cx23885 i2c master not properly implementing clock stretch. In > > the past I've seen i2c masters broken in their handling of clock > > stretching where they treat it as a NAK. > > > > The xc5000 being one of the few devices that actually does i2c clock > > stretching often exposes cases where it is improperly implemented in > > the i2c master driver (I've had to fix this with several bridges). > > > > Thanks for your insight. I am looking at cx23885-i2c.c and there is no > clock stretching logic in i2c_slave_did_ack(). Would this be the > right place for it to be? Can you point me to an example of another > driver that does it correctly? I really don't know what I am doing... Mark, You don't have much hope of getting that right without the CX23885 datasheet. Let's just get the bad commit reverted and into 2.6.38, and fix what used to work for you. Doing a git bisect is enough work for anyone. I'll do a patch to revert the commit and ask it to be pulled for 2.6.38-rc-whatever. I'll be sure to add a Bisected-by: Mark Zimmerman tag to the patch. (The Linux Kernel devs understand the work involved to do a bisection.) Later, if I can work up a patch to deal with clock stretching properly, I may ask you to test. 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: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman wrote: > > Clearly my previous bisection went astray; I think I have a more > > sensible result this time. > > > > qpc$ git bisect good > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > Author: Jean Delvare > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > ? ?other transactions too. > > This could be a combination of the xc5000 doing clock stretching and > the cx23885 i2c master not properly implementing clock stretch. In > the past I've seen i2c masters broken in their handling of clock > stretching where they treat it as a NAK. > > The xc5000 being one of the few devices that actually does i2c clock > stretching often exposes cases where it is improperly implemented in > the i2c master driver (I've had to fix this with several bridges). > Thanks for your insight. I am looking at cx23885-i2c.c and there is no clock stretching logic in i2c_slave_did_ack(). Would this be the right place for it to be? Can you point me to an example of another driver that does it correctly? I really don't know what I am doing... -- Mark -- 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
the V4L mailing list is deprecated
Hello whomever at Redhat who is managing this list, Its now been over two years since the Linux Media Mailing List was set up and it, indeed, has become well established (http://www.linuxtv.org/news.php?entry=2009-01-06.mchehab). While most V4L-DVB community participants have transitioned over to the LMML, unfortunately, (likely from those unaware of the change) a fair number of user messages are still getting posted to the now essentially deprecated video4linux mailing list. It is a diservice to those folks to continue allowing messages to make it on to the v4l list, as most of them will go unnoticed (as, as mentioned, most users in a position to respond to the sender have already abandoned this list in favour of the new LMML). Could we please effectively wind down the video4linux by the end of this month -- perhaps by way of setting up an auto notification response to any future submitter to the video4linux mailing list that their message should instead be sent to the LMML instead (perhaps even setting up a courtesy redirect of their message to the LMML for them) ? Cheers -- 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
radio tuner but no V4L2_CAP_RADIO ?
The following cards have a Multi Standard tuner with radio: KNC One TV-Station DVR (saa7134) FMD1216MEX HVR1300 (cx88-blackbird) Philips FMD1216ME /dev/radio0 is present and working. Both drivers do not report the radio when using VIDIOC_QUERYCAP. Is this a bug, or is there no clear specification that a driver must report this? Is there are any other way to check radio for support (besides trying to open a matching radio device) ? -- 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: 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:Sun Feb 13 19:00:28 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: OK linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] Port xf86-video-v4l driver to V4L2 version 2
Note: I've added a news item to the main page regarding V4L1's removal from the kernel. In addition, I've attempted to summarize what the video-v4l module's purpose, as well as how to use it, by sewing together the info from a bunch of sources (such as Alex's, Mauro comments, etc etc) - http://www.linuxtv.org/wiki/index.php/Main_Page - http://www.linuxtv.org/wiki/index.php/Xf86-video-v4l -- 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/5] [media] cx231xx: Use parameters to describe some board variants
Instead of per-model tests all over the code, use some parameters
at the board entries to describe the model variants for:
- devices with 417 MPEG encoder;
- devices that use external AV;
- devices where vbi VANC endpoint doesn't work;
- devices with xc5000 that require different IF
initialization (and probably will cover also
xc3028).
- devices with xceive tuner that require a reset
during init.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/cx231xx/cx231xx-avcore.c
b/drivers/media/video/cx231xx/cx231xx-avcore.c
index c53e972..b80bccf 100644
--- a/drivers/media/video/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/video/cx231xx/cx231xx-avcore.c
@@ -759,11 +759,8 @@ int cx231xx_set_decoder_video_input(struct cx231xx *dev,
case CX231XX_VMUX_TELEVISION:
case CX231XX_VMUX_CABLE:
default:
- switch (dev->model) {
- case CX231XX_BOARD_CNXT_CARRAERA:
- case CX231XX_BOARD_CNXT_RDE_250:
- case CX231XX_BOARD_CNXT_SHELBY:
- case CX231XX_BOARD_CNXT_RDU_250:
+ /* TODO: Test if this is also needed for xc2028/xc3028 */
+ if (dev->board.tuner_type == TUNER_XC5000) {
/* Disable the use of DIF */
status = vid_blk_read_word(dev, AFE_CTRL, &value);
@@ -820,8 +817,7 @@ int cx231xx_set_decoder_video_input(struct cx231xx *dev,
MODE_CTRL, FLD_INPUT_MODE,
cx231xx_set_field(FLD_INPUT_MODE,
INPUT_MODE_CVBS_0));
- break;
- default:
+ } else {
/* Enable the DIF for the tuner */
/* Reinitialize the DIF */
@@ -2550,7 +2546,7 @@ int cx231xx_initialize_stream_xfer(struct cx231xx *dev,
u32 media_type)
case 4: /* ts1 */
cx231xx_info("%s: set ts1 registers", __func__);
- if (dev->model == CX231XX_BOARD_CNXT_VIDEO_GRABBER) {
+ if (dev->board.has_417) {
cx231xx_info(" MPEG\n");
value &= 0xFFFC;
value |= 0x3;
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index ca2b24b..e04c955 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -261,6 +261,9 @@ struct cx231xx_board cx231xx_boards[] = {
.agc_analog_digital_select_gpio = 0x1c,
.gpio_pin_status_mask = 0x4001000,
.norm = V4L2_STD_PAL,
+ .no_alt_vanc = 1,
+ .external_av = 1,
+ .has_417 = 1,
.input = {{
.type = CX231XX_VMUX_COMPOSITE1,
@@ -382,6 +385,8 @@ struct cx231xx_board cx231xx_boards[] = {
.agc_analog_digital_select_gpio = 0x0c,
.gpio_pin_status_mask = 0x4001000,
.norm = V4L2_STD_NTSC,
+ .no_alt_vanc = 1,
+ .external_av = 1,
.input = {{
.type = CX231XX_VMUX_COMPOSITE1,
.vmux = CX231XX_VIN_2_1,
@@ -772,7 +777,7 @@ static int cx231xx_init_dev(struct cx231xx **devhandle,
struct usb_device *udev,
/* Reset other chips required if they are tied up with GPIO pins */
cx231xx_add_into_devlist(dev);
- if (dev->model == CX231XX_BOARD_CNXT_VIDEO_GRABBER) {
+ if (dev->board.has_417) {
printk(KERN_INFO "attach 417 %d\n", dev->model);
if (cx231xx_417_register(dev) < 0) {
printk(KERN_ERR
diff --git a/drivers/media/video/cx231xx/cx231xx-core.c
b/drivers/media/video/cx231xx/cx231xx-core.c
index 7d62d58..abe500f 100644
--- a/drivers/media/video/cx231xx/cx231xx-core.c
+++ b/drivers/media/video/cx231xx/cx231xx-core.c
@@ -571,6 +571,8 @@ int cx231xx_set_alt_setting(struct cx231xx *dev, u8 index,
u8 alt)
alt];
break;
case INDEX_VANC:
+ if (dev->board.no_alt_vanc)
+ return 0;
usb_interface_index =
dev->current_pcb_config.hs_config_info[0].interface_info.
vanc_index + 1;
@@ -600,8 +602,7 @@ int cx231xx_set_alt_setting(struct cx231xx *dev, u8 index,
u8 alt)
usb_interface_index, alt);
/*To workaround error number=-71 on EP0 for videograbber,
need add following codes.*/
- if (dev->model != CX231XX_BOARD_CNXT_VIDEO_GRABBER &&
- dev->model != CX231XX_BOARD_HAUPPAUGE_USBLIVE2)
+ if (dev->board.no_alt_vanc)
return -1;
}
@@ -1301,8 +
[PATCH 4/5] [media] cx231xx: Allow some boards to not use I2C port 3
Some devices don't need to use it. So allow to just disable this logic.
Having it enabled on some devices cause power management to complain,
generating error -71.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/cx231xx/cx231xx-avcore.c
b/drivers/media/video/cx231xx/cx231xx-avcore.c
index b80bccf..62843d3 100644
--- a/drivers/media/video/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/video/cx231xx/cx231xx-avcore.c
@@ -1271,6 +1271,8 @@ int cx231xx_enable_i2c_port_3(struct cx231xx *dev, bool
is_port_3)
int status = 0;
bool current_is_port_3;
+ if (dev->board.dont_use_port_3)
+ is_port_3 = false;
status = cx231xx_read_ctrl_reg(dev, VRT_GET_REGISTER,
PWR_CTL_EN, value, 4);
if (status < 0)
diff --git a/drivers/media/video/cx231xx/cx231xx.h
b/drivers/media/video/cx231xx/cx231xx.h
index b72503d..e1c222b 100644
--- a/drivers/media/video/cx231xx/cx231xx.h
+++ b/drivers/media/video/cx231xx/cx231xx.h
@@ -357,6 +357,7 @@ struct cx231xx_board {
unsigned int valid:1;
unsigned int no_alt_vanc:1;
unsigned int external_av:1;
+ unsigned int dont_use_port_3:1;
unsigned char xclk, i2c_speed;
--
1.7.1
--
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/5] [media] cx231xx: Use a generic check for TUNER_XC5000
The check for xc5000 assumes that the tuner will always
be using the same bus and will have the same address.
As those are configurable via dev->board, it should use,
instead, the values defined there.
Also, a similar type of test will be needed by other
tuners (for example, for TUNER_XC2028)
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/cx231xx/cx231xx-i2c.c
b/drivers/media/video/cx231xx/cx231xx-i2c.c
index 8356706..925f3a0 100644
--- a/drivers/media/video/cx231xx/cx231xx-i2c.c
+++ b/drivers/media/video/cx231xx/cx231xx-i2c.c
@@ -54,6 +54,21 @@ do { \
}\
} while (0)
+static inline bool is_tuner(struct cx231xx *dev, struct cx231xx_i2c *bus,
+ const struct i2c_msg *msg, int tuner_type)
+{
+ if (bus->nr != dev->board.tuner_i2c_master)
+ return false;
+
+ if (msg->addr != dev->board.tuner_addr)
+ return false;
+
+ if (dev->tuner_type != tuner_type)
+ return false;
+
+ return true;
+}
+
/*
* cx231xx_i2c_send_bytes()
*/
@@ -71,9 +86,7 @@ int cx231xx_i2c_send_bytes(struct i2c_adapter *i2c_adap,
u16 saddr = 0;
u8 need_gpio = 0;
- if ((bus->nr == 1) && (msg->addr == 0x61)
- && (dev->tuner_type == TUNER_XC5000)) {
-
+ if (is_tuner(dev, bus, msg, TUNER_XC5000)) {
size = msg->len;
if (size == 2) {/* register write sub addr */
@@ -180,9 +193,7 @@ static int cx231xx_i2c_recv_bytes(struct i2c_adapter
*i2c_adap,
u16 saddr = 0;
u8 need_gpio = 0;
- if ((bus->nr == 1) && (msg->addr == 0x61)
- && dev->tuner_type == TUNER_XC5000) {
-
+ if (is_tuner(dev, bus, msg, TUNER_XC5000)) {
if (msg->len == 2)
saddr = msg->buf[0] << 8 | msg->buf[1];
else if (msg->len == 1)
@@ -274,9 +285,7 @@ static int cx231xx_i2c_recv_bytes_with_saddr(struct
i2c_adapter *i2c_adap,
else if (msg1->len == 1)
saddr = msg1->buf[0];
- if ((bus->nr == 1) && (msg2->addr == 0x61)
- && dev->tuner_type == TUNER_XC5000) {
-
+ if (is_tuner(dev, bus, msg2, TUNER_XC5000)) {
if ((msg2->len < 16)) {
dprintk1(1,
@@ -454,8 +463,8 @@ static char *i2c_devs[128] = {
[0x32 >> 1] = "GeminiIII",
[0x02 >> 1] = "Aquarius",
[0xa0 >> 1] = "eeprom",
- [0xc0 >> 1] = "tuner/XC3028",
- [0xc2 >> 1] = "tuner/XC5000",
+ [0xc0 >> 1] = "tuner",
+ [0xc2 >> 1] = "tuner",
};
/*
--
1.7.1
--
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/5] [media] cx231xx: Simplify interface checking logic at probe
Just a cleanup patch. Removes one indent level by moving
the return -ENODEV to happen before the device register
logic, if the interface is not the audio/video (int 1).
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 588f3e8..ca2b24b 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -844,110 +844,110 @@ static int cx231xx_usb_probe(struct usb_interface
*interface,
udev = usb_get_dev(interface_to_usbdev(interface));
ifnum = interface->altsetting[0].desc.bInterfaceNumber;
- if (ifnum == 1) {
- /*
-* Interface number 0 - IR interface
-*/
- /* Check to see next free device and mark as used */
- nr = find_first_zero_bit(&cx231xx_devused, CX231XX_MAXBOARDS);
- cx231xx_devused |= 1 << nr;
+ /*
+* Interface number 0 - IR interface (handled by mceusb driver)
+* Interface number 1 - AV interface (handled by this driver)
+*/
+ if (ifnum != 1)
+ return -ENODEV;
- if (nr >= CX231XX_MAXBOARDS) {
- cx231xx_err(DRIVER_NAME
+ /* Check to see next free device and mark as used */
+ nr = find_first_zero_bit(&cx231xx_devused, CX231XX_MAXBOARDS);
+ cx231xx_devused |= 1 << nr;
+
+ if (nr >= CX231XX_MAXBOARDS) {
+ cx231xx_err(DRIVER_NAME
": Supports only %i cx231xx boards.\n", CX231XX_MAXBOARDS);
- cx231xx_devused &= ~(1 << nr);
- return -ENOMEM;
- }
-
- /* allocate memory for our device state and initialize it */
- dev = kzalloc(sizeof(*dev), GFP_KERNEL);
- if (dev == NULL) {
- cx231xx_err(DRIVER_NAME ": out of memory!\n");
- cx231xx_devused &= ~(1 << nr);
- return -ENOMEM;
- }
-
- snprintf(dev->name, 29, "cx231xx #%d", nr);
- dev->devno = nr;
- dev->model = id->driver_info;
- dev->video_mode.alt = -1;
- dev->interface_count++;
-
- /* reset gpio dir and value */
- dev->gpio_dir = 0;
- dev->gpio_val = 0;
- dev->xc_fw_load_done = 0;
- dev->has_alsa_audio = 1;
- dev->power_mode = -1;
- atomic_set(&dev->devlist_count, 0);
-
- /* 0 - vbi ; 1 -sliced cc mode */
- dev->vbi_or_sliced_cc_mode = 0;
-
- /* get maximum no.of IAD interfaces */
- assoc_desc = udev->actconfig->intf_assoc[0];
- dev->max_iad_interface_count = assoc_desc->bInterfaceCount;
-
- /* init CIR module TBD */
-
- /* store the current interface */
- lif = interface;
-
- /*mode_tv: digital=1 or analog=0*/
- dev->mode_tv = 0;
-
- dev->USE_ISO = transfer_mode;
-
- switch (udev->speed) {
- case USB_SPEED_LOW:
- speed = "1.5";
- break;
- case USB_SPEED_UNKNOWN:
- case USB_SPEED_FULL:
- speed = "12";
- break;
- case USB_SPEED_HIGH:
- speed = "480";
- break;
- default:
- speed = "unknown";
- }
-
- if (udev->manufacturer)
- strlcpy(descr, udev->manufacturer, sizeof(descr));
-
- if (udev->product) {
- if (*descr)
- strlcat(descr, " ", sizeof(descr));
- strlcat(descr, udev->product, sizeof(descr));
- }
+ cx231xx_devused &= ~(1 << nr);
+ return -ENOMEM;
+ }
+
+ /* allocate memory for our device state and initialize it */
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (dev == NULL) {
+ cx231xx_err(DRIVER_NAME ": out of memory!\n");
+ cx231xx_devused &= ~(1 << nr);
+ return -ENOMEM;
+ }
+
+ snprintf(dev->name, 29, "cx231xx #%d", nr);
+ dev->devno = nr;
+ dev->model = id->driver_info;
+ dev->video_mode.alt = -1;
+
+ dev->interface_count++;
+ /* reset gpio dir and value */
+ dev->gpio_dir = 0;
+ dev->gpio_val = 0;
+ dev->xc_fw_load_done = 0;
+ dev->has_alsa_audio = 1;
+ dev->power_mode = -1;
+ atomic_set(&dev->devlist_count, 0);
+
+ /* 0 - vbi ; 1 -sliced cc mode */
+ dev->vbi_or_sliced_cc_mode = 0;
+
+ /* get maximum no.of IAD interfaces */
+ assoc_desc = udev->actconfig->intf_assoc[0];
+ dev->max_iad_
[PATCH 0/5] Add support for PV Xcapture USB on cx231xx
This is a simple grabber card, and its addition should be simple. However, the cx231xx power management complains if some things are powered and starts to generate error -71. So, before adding the board entry, we need to apply a few fixes. This series also have a change at tuner code that will (hopefully) help to implement support for devices with xc3028. Mauro Carvalho Chehab (5): [media] cx231xx: Simplify interface checking logic at probe [media] cx231xx: Use a generic check for TUNER_XC5000 [media] cx231xx: Use parameters to describe some board variants [media] cx231xx: Allow some boards to not use I2C port 3 [media] cx231xx: Add support for PV Xcapture USB drivers/media/video/cx231xx/cx231xx-avcore.c | 14 +- drivers/media/video/cx231xx/cx231xx-cards.c | 228 +++--- drivers/media/video/cx231xx/cx231xx-core.c | 16 +- drivers/media/video/cx231xx/cx231xx-i2c.c| 31 +++-- drivers/media/video/cx231xx/cx231xx-video.c | 20 +- drivers/media/video/cx231xx/cx231xx.h|5 + 6 files changed, 180 insertions(+), 134 deletions(-) -- 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 5/5] [media] cx231xx: Add support for PV Xcapture USB
Adds support for Pixelviex Xcapture USB grabber device.
This device has one composite and one s-video entry
only, plus a button.
For now, the button is not supported.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index e04c955..6540b8d 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -440,6 +440,35 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = 0,
} },
},
+ [CX231XX_BOARD_PV_XCAPTURE_USB] = {
+ .name = "Pixelview Xcapture USB",
+ .tuner_type = TUNER_ABSENT,
+ .decoder = CX231XX_AVDECODER,
+ .output_mode = OUT_MODE_VIP11,
+ .demod_xfer_mode = 0,
+ .ctl_pin_status_mask = 0xFFC4,
+ .agc_analog_digital_select_gpio = 0x0c,
+ .gpio_pin_status_mask = 0x4001000,
+ .norm = V4L2_STD_NTSC,
+ .no_alt_vanc = 1,
+ .external_av = 1,
+ .dont_use_port_3 = 1,
+
+ .input = {{
+ .type = CX231XX_VMUX_COMPOSITE1,
+ .vmux = CX231XX_VIN_2_1,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_SVIDEO,
+ .vmux = CX231XX_VIN_1_1 |
+ (CX231XX_VIN_1_2 << 8) |
+ CX25840_SVIDEO_ON,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }
+ },
+ },
};
const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
@@ -469,6 +498,8 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_HAUPPAUGE_USBLIVE2},
{USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x4000,
0x4001),
.driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
+ {USB_DEVICE(USB_VID_PIXELVIEW, 0x5014),
+.driver_info = CX231XX_BOARD_PV_XCAPTURE_USB},
{},
};
diff --git a/drivers/media/video/cx231xx/cx231xx.h
b/drivers/media/video/cx231xx/cx231xx.h
index e1c222b..2d5ab0c 100644
--- a/drivers/media/video/cx231xx/cx231xx.h
+++ b/drivers/media/video/cx231xx/cx231xx.h
@@ -64,6 +64,7 @@
#define CX231XX_BOARD_HAUPPAUGE_EXETER 8
#define CX231XX_BOARD_HAUPPAUGE_USBLIVE2 9
#define CX231XX_BOARD_PV_PLAYTV_USB_HYBRID 10
+#define CX231XX_BOARD_PV_XCAPTURE_USB 11
/* Limits minimum and default number of buffers */
#define CX231XX_MIN_BUF 4
--
1.7.1
--
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: Siano SMS1140 DVB Receiver on Debian 5.0 (Lenny)
On Fri, Feb 11, 2011 at 12:39:30PM -0200, jamen...@bol.com.br wrote: > As you can see, driver is not registering the devices. So I did registration: just curious, how did you do that? > > I'm using kernel 2.6.37 (downloaded from kernel.org) with Debian GNU/Linux > 5.0 (Lenny). try different kernel versions, also sms and other modules support debug options - those are what I came across: #options smsdvb debug=3 #options smsusb debug=3 #options dvb_frontend debug=1 #options dvb_frontend dvbdev_debug=1 #options smsmdtv debug=3 #options dvb_core debug=1 #options dvb_core dvbdev_debug=1 Richard --- Name and OpenPGP keys available from pgp key servers -- 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: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman wrote: > Clearly my previous bisection went astray; I think I have a more > sensible result this time. > > qpc$ git bisect good > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > Author: Jean Delvare > Date: Sun Jul 18 16:52:05 2010 -0300 > > V4L/DVB: cx23885: Check for slave nack on all transactions > > Don't just check for nacks on zero-length transactions. Check on > other transactions too. This could be a combination of the xc5000 doing clock stretching and the cx23885 i2c master not properly implementing clock stretch. In the past I've seen i2c masters broken in their handling of clock stretching where they treat it as a NAK. The xc5000 being one of the few devices that actually does i2c clock stretching often exposes cases where it is improperly implemented in the i2c master driver (I've had to fix this with several bridges). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sat, Feb 12, 2011 at 08:29:54AM -0700, Mark Zimmerman wrote: > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > Greetings: > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > fails to load due to an i2c failure. A search of the archives indicates > > that this is not the first time this issue has occurred. > > > > What can I do to help get this problem fixed? > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: firmware upload complete... > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: firmware upload complete.. > > > > and here is what happens with 2.6.36: > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: I2C write failed (len=3) > > xc5000: firmware upload complete... > > xc5000: Unable to initialise tuner > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: I2C write failed (len=3) > > xc5000: firmware upload complete... > > > > I did a git bisect on this and finally reached the end of the line. > Blah blah blah... > Clearly my previous bisection went astray; I think I have a more sensible result this time. qpc$ git bisect good 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit commit 44835f197bf1e3f57464f23dfb239fef06cf89be Author: Jean Delvare Date: Sun Jul 18 16:52:05 2010 -0300 V4L/DVB: cx23885: Check for slave nack on all transactions Don't just check for nacks on zero-length transactions. Check on other transactions too. Signed-off-by: Jean Delvare Signed-off-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab :04 04 e48c9f6efc6186800e8d711c05987c0ad9445c09 1ba37458c6a5fc22d19271f09cde2f336887c616 M drivers git bisect start # good: [9fe6206f400646a2322096b56c59891d530e8d51] Linux 2.6.35 git bisect good 9fe6206f400646a2322096b56c59891d530e8d51 # bad: [18a87becf85d50e7f3d547f1b7a75108b151374d] V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return value git bisect bad 18a87becf85d50e7f3d547f1b7a75108b151374d # good: [03da30986793385af57eeca3296253c887b742e6] Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6 git bisect good 03da30986793385af57eeca3296253c887b742e6 # good: [ab69bcd66fb4be64edfc767365cb9eb084961246] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6 git bisect good ab69bcd66fb4be64edfc767365cb9eb084961246 # good: [a57f9a3e811cf1246b394f0cc667c6bc5a52e099] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ryusuke/nilfs2 git bisect good a57f9a3e811cf1246b394f0cc667c6bc5a52e099 # good: [9e50ab91d025afc17ca14a1764be2e1d0c24245d] Merge branch 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 git bisect good 9e50ab91d025afc17ca14a1764be2e1d0c24245d # good: [d71048e22f47725a5808ea2e4e1e72fa36c1a788] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 git bisect good d71048e22f47725a5808ea2e4e1e72fa36c1a788 # good: [4fd6c6bf83cb16321e9902b00e2af79054f4e0d6] Merge branch 'for-linus' of git://android.kernel.org/kernel/tegra git bisect good 4fd6c6bf83cb16321e9902b00e2af79054f4e0d6 # good: [c1c8f558749cbf2a7ed16b6ae6e19a4238b6fa33] CRIS: Return something from profile write git bisect good c1c8f558749cbf2a7ed16b6ae6e19a4238b6fa33 # good: [ab11b487402f97975f3ac1eeea09c82f4431481e] Merge branch 'master' into for-linus git bisect good ab11b487402f97975f3ac1eeea09c82f4431481e # good: [30d4554a02d3ad6f9928767c9f98214775f4dcb2] V4L/DVB: gspca - main: Version change git bisect good 30d4554a02d3ad6f9928767c9f98214775f4dcb2 # good: [6e80cc51b4419ca0f8162024ee2497d7ec8ba31c] V4L/DVB: gspca - sq930x: Cleanup source, add comments git bisect good 6e80cc51b4419ca0f8162024ee2497d7ec8ba31c # good: [3d217c8656842c77d6f33329a034102157363c8d] V4L/DVB: gspca - vc032x: Force main register write at probe time (po) git bisect good 3d217c8656842c77d6f33329a034102157363c8d # bad: [44835f197bf1e3f57464f23dfb239fef06cf89be] V4L/DVB: cx23885: Check for slave nack on all transactions git bisect bad 44835f197bf1e3f57464f23dfb239fef06cf89be # good: [f4acb3c4ccca74f5448354308f917e87ce83505a] V4L/DVB: cx23885: Return -ENXIO on slave nack git bisect good f4acb3c4ccca74f5448354308f917e87ce83505a -- 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://
[PATCH] Fix sysfs rc protocol lookup for rc-5-sz
With the current matching rules the lookup for rc protocol named rc-5-sz
matches with "rc-5" before finding "rc-5-sz". Thus one is able to never
enable/disable the rc-5-sz protocol via sysfs.
Fix the lookup to require an exact match which allows the manipulation of sz
protocol.
Signed-off-by: Antti Seppälä
---
drivers/media/rc/rc-main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 512a2f4..5b4422e 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -850,7 +850,7 @@ static ssize_t store_protocols(struct device *device,
count++;
} else {
for (i = 0; i < ARRAY_SIZE(proto_names); i++) {
- if (!strncasecmp(tmp, proto_names[i].name,
strlen(proto_names[i].name))) {
+ if (!strcasecmp(tmp, proto_names[i].name)) {
tmp += strlen(proto_names[i].name);
mask = proto_names[i].type;
break;
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCTV USB2 PAL / adds loud hum to correct audio
Andy Walls wrote:
> I find audio at 8 ksps very unusual for a TV capture device.
>
I tried it with pulseaudio at 44100 samples/sec
and with some commercial tuned in...
(no big copyright problem hopefully) :-)
i used this command:
parec --device=alsa_input.hw_1 > blah.raw
resulting raw data: http://www.wgboome.de./blah.raw
> The data set contains no large positive values
> (nothing in the range 0x1000-0x7fff).
>
Now the noise is in the positive range, 2...
I made a new filter program (see appendix),
that produces acceptable but still distorted sound.
filter output: http://www.wgboome.de./blah.ogg
> The valuex 0x10 and 0x80 do remind me of the YUV values for black: Y =
> 0x10, U = 0x80, V = 0x80. Maybe some video data is getting thrown in
> with the audio?
>
sounds good...
because: the unwanted data changed its range now...
-arne
appendix:
...
(buf[i]/256>=0x80 && buf[i]/256<0xC0) ||
(buf[i]/256>=0x40 && buf[i]/256<0x80)) {
...
--
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
