Re: hvr-1600 fails frequently on multiple recordings
Have you checked on the Ubuntu Forums for any information about this? There's a thread about 0-byte recordings there, which might have some solutions for you. I had the same issue with analog recording a while back, and found that in my case, it was due to having a second hard drive listed as a storage directory. If the hard drive didn't spin up quick enough, the recording failed. Here's a link to the thread on their site: http://ubuntuforums.org/showthread.php?t=1687846 Hope this helps, and have a great day:) Patrick. On Wed, 2012-10-03 at 20:44 -0400, Brian J. Murrell wrote: > I have a fairly new HVR-1600 which I have seen fail quite a number of > times now when it's asked to record more than one channel on a clearqam > multiplex. This time it was 3 recordings at once. > > There's nothing at all in the kernel ring buffer, just mythtv reports a > failed recording. Usually one of the files being recorded to will only > be 376 bytes long and the rest will be 0 bytes. > > I am running ubuntu's 3.2.0-27-generic kernel with what looks like a > 1.5.1 cx18 driver. The card is either a: > > 14f1:5b7a Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with > Integrated Analog Video/Broadcast Audio Decoder > > or a: > > :0016 Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01) > > Sorry. I don't recall which is which any more. > > But I really need to figure this out since failed recordings is causing > all kinds of disappointment around here. I'm really at the end of my > rope with it. > > Tomorrow morning I am going to demote this card to secondary duty and > promote my HVR-950Q to primary duty since I never had this kind of > grief with it. But even in secondary duty, it could very well be > called upon to record multiple clearqam channels simultaneously so I > would really like to get this figured out. > > Any ideas? > > Cheers, > b. > -- 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
Preferred setup for development?
I'm looking for information about what distributions people are using, and how they go about testing their code. The reason is, I'm running Ubuntu for my main distribution, and it seems like I'll have to go through a lot of hoops in order to compile and test changes to the kernel. I realize that I could probably just use the media_build tree, and add the changes there. But, I'd prefer to go the same route that the majority of the developers here do. So, my questions are these: 1. Do you use a specific distribution for development, or a roll your own (like Linux from Scratch)? 2. If you use a distribution, which one? 3. Do you do your development on physical computers or on virtual machines (or both)? 4. Do you have a machine that's dedicated to development, or is it one that you use for other things? 5. Do you use a newer computer, or older computer for development? (or both) For anyone using the media_build tree (instead of the media_git tree): Are you able to seamlessly implement changes that are in the media_git tree files to the media_build tree, or do you have to make changes in order to get them to compile? Are your files able to be implemented into the media_git tree seamlessly, or do you have to make changes to get them to compile? If you're able to use the media_build tree, and the changes you make can be implemented in the media_git tree without hassle, I may go that route instead. I downloaded a Slackware DVD, as it appears to be one that you can "roll your own kernel" without too much of a hassle. But, I want to get people's opinions before I start. Thanks to everyone who responds, and have a great day:) Patrick. -- 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: Patch update notification: 23 patches updated]
Is there anything that I need to do for this? The patches were the older versions, if I remember correctly, and Mauro has moved them to a branch on his tree (but I haven't checked lately to see if there has been any work done on that branch). Thanks, and have a great day:) Patrick. --- Begin Message --- Hello, The following patches (submitted by you) have been updated in patchwork: * [08/25] added drx39_dummy for pctv80e support - http://patchwork.linuxtv.org/patch/8387/ was: New now: RFC * [02/25] added bsp_host for pctv80e support - http://patchwork.linuxtv.org/patch/8368/ was: New now: RFC * [2/2] import-pctv-80e-from-devin-heitmueller-hg-repository # HG changeset patch # User Devin Heitmueller # Date 1278279731 14400 # Node ID 30c6512030acb8dea04c653b40340f6038d57367 # Parent c119f08c4dd266f6024cde6b5e660c7d32a0 - http://patchwork.linuxtv.org/patch/9586/ was: New now: Under Review * [25/25] modified em28xx header for pctv80e support - http://patchwork.linuxtv.org/patch/8381/ was: New now: RFC * [03/25] added bsp_i2c for pctv80e support - http://patchwork.linuxtv.org/patch/8375/ was: New now: RFC * [05/25] added bsp_types for pctv80e support - http://patchwork.linuxtv.org/patch/8388/ was: New now: RFC * [01/25] added PCTV80e information to cardlist file - http://patchwork.linuxtv.org/patch/8369/ was: New now: RFC * [24/25] modified em28xx-dvb for pctv80e support - http://patchwork.linuxtv.org/patch/8382/ was: New now: RFC * [07/25] added drx39xxj header for pctv80e support - http://patchwork.linuxtv.org/patch/8376/ was: New now: RFC * [10/25] added drx_dap_fasi header for pctv80e support - http://patchwork.linuxtv.org/patch/8389/ was: New now: RFC * [09/25] added drx_dap_fasi for pctv80e support - http://patchwork.linuxtv.org/patch/8370/ was: New now: RFC * [20/25] added drxj_options header for pctv80e support - http://patchwork.linuxtv.org/patch/8383/ was: New now: RFC * [04/25] added bsp_tuner for pctv80e support - http://patchwork.linuxtv.org/patch/8377/ was: New now: RFC * [06/25] added drx39xxj for pctv80e support - http://patchwork.linuxtv.org/patch/8371/ was: New now: RFC * [23/25] modified em28xx-cards for pctv80e support - http://patchwork.linuxtv.org/patch/8384/ was: New now: RFC * [22/25] modified Makefile for pctv80e support - http://patchwork.linuxtv.org/patch/8378/ was: New now: RFC * [11/25] added drx_driver for pctv80e support - http://patchwork.linuxtv.org/patch/8372/ was: New now: RFC * [19/25] added drxj_mc_vsbqam header for pctv80e support - http://patchwork.linuxtv.org/patch/8385/ was: New now: RFC * [18/25] added drxj_mc_vsb header for pctv80e support - http://patchwork.linuxtv.org/patch/8379/ was: New now: RFC * [13/25] added drx_driver_version header for pctv80e support - http://patchwork.linuxtv.org/patch/8373/ was: New now: RFC * [15/25] added drxj header for pctv80e support - http://patchwork.linuxtv.org/patch/8386/ was: New now: RFC * [21/25] modified Kconfig to include pctv80e support - http://patchwork.linuxtv.org/patch/8380/ was: New now: RFC * [12/25] added drx_driver header for pctv80e support - http://patchwork.linuxtv.org/patch/8374/ was: New now: RFC This email is a notification only - you do not need to respond. Happy patchworking. -- This is an automated mail sent by the patchwork system at patchwork.linuxtv.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.linuxtv.org/mail/ --- End Message ---
Re: How I must report that a driver has been broken?
I'm not an expert (or anywhere near one), but I'm guessing that the reason you didn't get a response to your two previous (actually three or four previous) emails is because you "submitted" a patch that was already in the kernel. You were intending to show that the patch breaks something, yet instead of submitting the fix for the problem, you resubmitted the patch that was already applied. Either that, or for some other reason, the patch that you submitted was rejected. My suggestion is to take what you've submitted (if it was the fix for the problem) and resubmit it. If you were just pointing out the broken code, then submit your fix for the issue (by creating a patch that fixes or removes the broken code). Also one other thing I found is that you submitted the original patches for the card. Or at least you submitted some patches for it around November of last year. So my question is, do the patches that you submitted back then work, or are they the broken code now? Have a great day:) Patrick. P.S. Again, I'm not an expert here, nor do I claim to be. So if someone else gives you an answer, I'd put more weight on theirs--as they probably have more experience than I do. On Sat, 2012-05-12 at 16:26 -0300, Alfredo Jesús Delaiti wrote: > Hi > > Thanks for your response Hans and Patrick > > Maybe I doing wrong this, because it reports twice: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg45199.html > http://www.mail-archive.com/linux-media@vger.kernel.org/msg44846.html > > and I have not had any response. > > > Thanks again, > > Alfredo > > > > > > El 12/05/12 05:17, Hans de Goede escribió: > > Hi > > > > On 05/12/2012 06:26 AM, Alfredo Jesús Delaiti wrote: > >> Hi > >> > >> New features of the driver has left a card does not work. > >> How I must report that a driver has been broken? > > > > Well this list would be a good place for starters, please > > send a *detailed* bug report to this list, including > > things like what is the last (kernel) version it worked > > with, what is the first version it is broken. > > > > What did it do before breaking what know now longer works, > > etc. > > > > Regards, > > > > Hans > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-T USB Stick Pinnacle PCTV
Hello Michael, Which Pinnacle PCTV tuner do you have (PCTV 290e, PCTV 80e, etc)? The 80e is not supported yet, although it's in the works. What does lsusb show for information about the tuner? Have a great day:) Patrick. On Sat, 2012-04-07 at 05:22 +0200, Michael Hagner wrote: > Hello, > > I' ve tried to install the above mentioned USB-device, > but the system doesn't work e.g. the device hasn't > been recognized from the system. > > Kubuntu 10.10 Kernel ...35.28 > > Do you have some information to solve that problem ? > I believe, that's the USB portmaybe I've to use the insmodsee the > bold red mark in the syslog. > > Thanks in advance... > > Michael > > Att.: Syslog -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Import PCTV-80e Drivers from Devin Heitmueller's Repository
On 01/26/2012 10:36 AM, Mauro Carvalho Chehab wrote: > Em 21-01-2012 05:34, pdickeyb...@gmail.com escreveu: >> From: Patrick Dickey >> >> This series of patches will import the drx39xxj(drx39xyj) drivers from Devin >> Heitmueller's HG Repository for the Pinnacle PCTV-80e USB Tuner. >> >> Patrick Dickey (2): >> import-pctv-80e-from-devin-heitmueller-hg-repository >> Signed-off-by: Devin Heitmueller >> Signed-off-by: Patrick Dickey >> import-pctv-80e-from-devin-heitmueller-hg-repository >> Signed-off-by: Devin Heitmueller >> Signed-off-by: Patrick Dickey > > Patch 0 never arrived. Is there a place where I could get it? > If the patch is from some Devin's tree, maybe I can just get it there. I may have to resend them. Somehow the subject heading of the patches became mangled. Patch 0, is just the cover letter, patch 1/2 and 2/2 (which both have mangled subject headings) are the actual patches. The other two have the subject heading of [PATCH x/2] Import PCTV-80e Drivers from Devin Heitmueller's Repository#... It combined the comments from the patch with the subject. Sorry for any inconvenience and confusion that this created. Have a great day:) Patrick. > >> >> Documentation/video4linux/CARDLIST.em28xx |1 + >> .../staging/media/dvb/frontends/drx39xyj/Kconfig |7 + >> .../staging/media/dvb/frontends/drx39xyj/Makefile |3 + >> .../media/dvb/frontends/drx39xyj/bsp_host.h| 80 + >> .../staging/media/dvb/frontends/drx39xyj/bsp_i2c.h | 217 + >> .../media/dvb/frontends/drx39xyj/bsp_tuner.h | 215 + >> .../media/dvb/frontends/drx39xyj/bsp_types.h | 229 + >> .../media/dvb/frontends/drx39xyj/drx39xxj.c| 457 + >> .../media/dvb/frontends/drx39xyj/drx39xxj.h| 40 + >> .../media/dvb/frontends/drx39xyj/drx39xxj_dummy.c | 134 + >> .../media/dvb/frontends/drx39xyj/drx_dap_fasi.c| 675 + >> .../media/dvb/frontends/drx39xyj/drx_dap_fasi.h| 268 + >> .../media/dvb/frontends/drx39xyj/drx_driver.c | 1600 ++ >> .../media/dvb/frontends/drx39xyj/drx_driver.h | 2588 +++ >> .../dvb/frontends/drx39xyj/drx_driver_version.h| 82 + >> .../staging/media/dvb/frontends/drx39xyj/drxj.c|16758 >> >> .../staging/media/dvb/frontends/drx39xyj/drxj.h| 730 + >> .../media/dvb/frontends/drx39xyj/drxj_map.h|15359 ++ >> .../staging/media/dvb/frontends/drx39xyj/drxj_mc.h | 3939 + >> .../media/dvb/frontends/drx39xyj/drxj_mc_vsb.h | 744 + >> .../media/dvb/frontends/drx39xyj/drxj_mc_vsbqam.h | 1437 ++ >> .../media/dvb/frontends/drx39xyj/drxj_options.h| 65 + >> 22 files changed, 45628 insertions(+), 0 deletions(-) >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/Kconfig >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/Makefile >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_host.h >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_i2c.h >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_tuner.h >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_types.h >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj.c >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj.h >> create mode 100644 >> drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj_dummy.c >> create mode 100644 >> drivers/staging/media/dvb/frontends/drx39xyj/drx_dap_fasi.c >> create mode 100644 >> drivers/staging/media/dvb/frontends/drx39xyj/drx_dap_fasi.h >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver.c >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver.h >> create mode 100644 >> drivers/staging/media/dvb/frontends/drx39xyj/drx_driver_version.h >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj.c >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj.h >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_map.h >> create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc.h >> create mode 100644 >> drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc_vsb.h >> create mode 100644 >> drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc_vsbqam.h >> create mode 100644 >> drivers/staging/media/dvb/frontends/drx39xyj/drxj_options.h >> > -- 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
Adding support for PCTV-80e Tuner
Hello everyone, A few months ago, I posted a 25-patch series on the PCTV-80e Tuner to the mailing list, which was nacked. I've since rewrote the patches, but have an issue that I need some advice with. I took Devin's advice, and created two patches using his hg patches. The only modifications that I made were to remove the Makefile and Kconfig entries, and then to move the drivers to the staging/media/frontends/drx39xyj directory. I've got a couple of problems/questions, and am looking for opinions on how to deal with them. I included the mailing list in this, because there might be someone who's had similar issues, and because this issue might come up in the future with other projects. So, here are my problems. 1. If I try to make the media_git with just the two patches included, I get compilation errors in em28xx-cards.c. This is because it needs the drx39xxj.h file, which is in drivers/staging/media/frontends/drx39xyj (and hasn't been compiled). 2. If I add an entry into the drivers/media Makefile and Kconfig, pointing to the drvers/staging/media/frontends/drx39xyj directory, it fails to compile because drx39xxj.c requires dvb_frontend.h from drivers/media/dvb/dvb-core, which hasn't been compiled yet. The short question is how do I handle this situation? The longer questions are 1. Do I make entries in the drx39xyj/Makefile and Kconfig that point back to the dvb/dvb-core directory (or add the drivers/dvb/ entry before the drivers/staging/media/frontends/drx39xyj/ entry in the Makefile/Kconfig entries in drivers/media/)? 2. Do I submit my two patches, knowing that they will break compilation of the media_git tree at the em28xx-cards.c file? 3. Do I comment out the entries in em28xx-cards.c (or remove them from the patches altogether), so that everything will be made and we can work on the compilation and coding style issues in the drx39xyj files? (I would do this in a third patch, so that I can preserve Devin's original patches as much as possible) Right now, I have two patches that create the drivers and add them to the em28xx files where necessary, and that update the licensing and authorship (Devin's original updates). And I have a third patch, which adds a ccflags-y entry to the em28xx Makefile, pointing to the drivers/staging/media/frontends/drx39xyj directory (for finding the files it needs). Thanks for any information and advice. And if I should have just directed this to Devin and/or Mauro (or waited for a reply from an earlier email to Mauro), I'm sorry for the inconvenience that sending this to the entire list may have caused. Have a great day:) Patrick. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2011 05:07 AM, Mauro Carvalho Chehab wrote: > On 31-12-2011 08:15, Dorozel Csaba wrote: >>> Basically, the bridge driver is not sending the complete RC-5 >>> keycode to the IR core, but just the 8 least siginificant >>> bits. So, it is loosing the 0x1e00 code for the Hauppauge grey >>> remote. >>> >>> The fix should be at saa7134-input. It should be something >>> like the enclosed patch (I'm just guessing there that code3 >>> contains the MSB bits - you may need to adjust it to match the >>> IR decoder there): >> >> I'm absolutly not a programer but an unhappy linux user who want >> his working remote back. Know nothing about c code, MSB bits ... >> After apply your fix looks what happening but remote is still >> broken. >> >> user juuzer # ir-keytable -t Testing events. Please, press CTRL-C >> to abort. 1325324726.066129: event MSC: scancode = de3d >> 1325324726.066131: event sync 1325324726.169132: event MSC: >> scancode = de3d 1325324726.169134: event sync 1325324727.508129: >> event MSC: scancode = fe3d 1325324727.508131: event sync >> 1325324727.611132: event MSC: scancode = fe3d 1325324727.611134: >> event sync 1325324730.084132: event MSC: scancode = de3d >> 1325324730.084134: event sync 1325324730.187132: event MSC: >> scancode = de3d >> >> It seems the code3 sometimes return with de (1100) sometimes >> fe (1110). Is it possible to bitwise left 3 then bitwise >> right 3 so the result in both case is 1e (0000) ? Or its >> totaly wrong ? > > An RC-5 code is just 14 bits. I found some Hauppauge decoders > returning just 12 bits on some places. It seems that all it needs > is to do a code3 | 0x3f, in order to discard the two most > significant bits (MSB). > > So, the enclosed patch should fix the issues. Please test. > > Regards, Mauro - > > saa7134-input: Fix get_key_hvr1110() handling > > Instead of returning just 8 bits, return the full RC-5 code > > Signed-off-by: Mauro Carvalho Chehab > > diff --git a/drivers/media/video/saa7134/saa7134-input.c > b/drivers/media/video/saa7134/saa7134-input.c index > d4ee24b..29c8efd 100644 --- > a/drivers/media/video/saa7134/saa7134-input.c +++ > b/drivers/media/video/saa7134/saa7134-input.c @@ -249,8 +249,8 @@ > static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 > *ir_raw) return 0; > > /* return key */ -*ir_key = code4; - *ir_raw = code4; + *ir_key > = > 0x3fff & (code4 | code3 << 8); + *ir_raw = *ir_key; return 1; } > > > Regards, 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 Will this work regardless of what remote is being used? Currently I'm using a Windows Media Center Remote (Hauppauge HVR-1600 provided it) with a combination of saa7134 (MSI TV@nywhere Plus) and Hauppauge HVR-1600 tuners. Right now, the Hauppauge works fine (all of this is in Mythtv 0.24), but the MSI crashes when I change channels. Have a great day:) Patrick. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7+72UACgkQMp6rvjb3CAR2tQCgqSAc55bQyDEe3Z4vu0sUYAne RrQAoIU89vMVzI8UBH8v+dJxl3RsHj44 =3joI -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 12/07/2011 08:01 AM, Andreas Oberritter wrote: > On 07.12.2011 14:49, Mark Brown wrote: >> On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: >>> On 06.12.2011 15:19, Mark Brown wrote: >> Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely in line with reality. >> >>> Did you notice that we're talking about a very particular application? >> >> *sigh* >> >>> VoIP really is totally off-topic. The B in DVB stands for broadcast. >>> There's only one direction in which MPEG payload is to be sent (using >>> RTP for example). You can't just re-encode the data on the fly without >>> loss of information. >> >> This is pretty much exactly the case for VoIP some of the time (though >> obviously bidirectional use cases are rather common there's things like >> conferencing). I would really expect similar considerations to apply >> for video content as they certainly do in videoconferencing VoIP >> applications - if the application knows about the network it can tailor >> what it's doing to that network. >> >> For example, if it is using a network with a guaranteed bandwidth it can >> assume that bandwidth. If it knows something about the structure of the >> network it may be able to arrange to work around choke points. >> Depending on the situation even something lossy may be the answer - if >> it's the difference between working at all and not working then the cost >> may be worth it. > > Once and for all: We have *not* discussed a generic video streaming > application. It's only, I repeat, only about accessing a remote DVB API > tuner *as if it was local*. No data received from a satellite, cable or > terrestrial DVB network shall be modified by this application! > > Virtually *every* user of it will use it in a LAN. > > It can't be so hard to understand. > -- > 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 I tend to stay out of these discussions, since like a couple of others, I'm not a kernel developer (or hacker). However, I wanted to chime in with my two cents here. 1. I agree that it's not acceptable to "NACK" purely for philosophical reasons (except when it's a clear violation of a license--be that open source or closed source (since we don't want to open ourselves up to lawsuits). 2. In this case, there have been technical reasons provided. Granted the developers (and people who are pro-inclusion) don't feel those are justified, but they have been cited. 3. You'll catch more flies with honey than vinegar (in other words, fighting with the person(s) who maintain the project will most definitely *not* get your code included). 4 (and the reason I decided to chime in here). This email sums everything up. Mark is pointing out that someone may want to use this in a non LAN setting, and they may/will have problems due to the Internet (and their specific way of accessing it). Andreas is arguing that it's not the case. I have to side with Mark on this one, solely because if I knew that it would work, I'd use it to watch television when I'm traveling (as some places don't carry the same channels that I have at home). So, I would prove Mark's point. Andreas, you said that "virtually EVERY (emphasis mine) user of it will use it on a LAN". "Virtually" implies almost all-- NOT ALL. So, unless there's some restriction in the application, which prevents it from being used over the Internet, you can't guarantee that Mark's issues aren't valid. If as HoP pointed out in another reply on this thread, there's no kernel patching required, then I suggest that you keep on developing it as a userspace application. There's no law/rule/anything that says you can't install your own driver in the kernel. It just won't be supported upstream. That just means more work for you, if you want the application to continue working in the future. Truthfully, that has it's upsides also. If you find out about a way to improve the transmission, you don't have to wait (and hope) that it gets included in the kernel. You can include it in your driver. Sorry for butting into this. You're free to flame or ignore me, as you choose. Have a great day:) Patrick. -- 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: LinuxTV ported to Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2011 12:03 PM, Rémi Denis-Courmont wrote: > Hello, > > A GPL troll, as the "Vicious Nokia Employee [that got] VLC Removed > from Apple App Store" I cannot resist... > > Le mercredi 30 novembre 2011 19:23:26 Devin Heitmueller, vous avez > écrit : >> Am I the only one who thinks this is a legally ambigious grey >> area? Seems like this could be a violation of the GPL as the >> driver code in question links against a proprietary kernel. > > If you have any doubt, I would suggest you ask the SFLC. They tend > to give valuable insights into that sort of problems. It might be > intricate and/or not what you want to hear from them though (Been > there done that). > >> I don't want to start a flame war, but I don't see how this is >> legal. And you could definitely question whether it goes against >> the intentions of the original authors to see their GPL driver >> code being used in non-free operating systems. > > As long as the distributed binaries do not include any > GPL-incompatible code (presumably from Microsoft), there should be > no GPL contamination problem. So it boils down to whether the > driver binary has non-GPL code in it. I don't see how the license > of the Windows code is relevant, so long as NetUp is not > distributing the Windows OS alongside the driver (or vice versa). > > And while I do not know the Windows DDK license, I doubt it cares > much about the driver license, so long as Microsoft does not need > to distribute nor certify the driver. > I'm not sure about the Windows DDK license either, but I can tell you that at least some of their licenses specifically forbid you to use their libraries or source code in GPL-style programs. I downloaded an iso of the Windows Driver Kit version 7.1.0, and what I found in the Windows Development Kit license is this (concerning redistributed code from the WDK) > iii. Distribution Restrictions. You may not alter any copyright, > trademark or patent notice in the Distributable Code; use > Microsoft’s trademarks in your programs’ names or in a way that > suggests your programs come from or are endorsed by Microsoft; > distribute Distributable Code to run on a platform other than the > Windows platform; > include Distributable Code in malicious, deceptive or unlawful > programs; or > modify or distribute the source code of any Distributable Code so > that any part of it becomes subject to an Excluded License. An > Excluded License is one that requires, as a condition of use, > modification or distribution, that the code be disclosed or > distributed in source code form; or others have the right to modify > it. Which would tell me that you can't redistribute their code in any product licensed under the GPL. So, if NetUP used any of the redistributable code from the development kit in their port, it would violate Microsoft's licensing. And any code that NetUP used cannot be backported to Linux. (The **'s are my emphasis of what I believe are the relevant portions of the license) > > There may however be problems with the toolchain. The driver binary > must be recompilable with just the GPL'd source code and "anything > that is normally distributed with the operating system". > VisualStudio is not distributed with Windows. In fact, it is sold > as a separate product, except for restrictive freeware versions. > > So unless this driver can be compiled with a GPL-compatible > toolchain (and the toolchain is provided by NetUp), it might not be > possible to distribute binary copies of the driver. > > Then again, I am not a laywer. Someone that cares, please ask SFLC > or friends. > I agree about contacting the SFLC. Also the copyright holder (Steven Toth) weighed in about his concerns. So at the end of the day, this is between him and the developers (NetUP, Abylay, etc). GPL questions/potential issues aside, I can see some benefit from this. Just in the idea that if the port works fairly decently, and with the proper advertising, it might get the name "Linux" into the average user's field of view (so to speak). Of course if the port is crap, or if you have to pay for the product (or pay for a spyware/adware free version), then it might have the opposite effect. This is just my 2 cents worth, as an end-user mainly. Have a great day:) Patrick. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ZTLcACgkQMp6rvjb3CARnqwCgy6MqGTObMugv1S0v5gOTf/xx f+sAn3hkImJvOCVMJlKcnV/b+VfI4wZL =UJN4 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/12/2011 08:53 AM, jonathanjstev...@gmail.com wrote: > I've just done some tests without Xen. > > The situation does change, in that scandvb finds the services (so > no more "filter timeouts"). Kaffeine also manages to scan the > channels OK - however despite managing to scan, tune and get the > EPG there is no picture on any channel. > > I can't test MythTV without Xen, as it relies on an SQL database > that is on a Xen VM. > > Not sure where to go with this next? The card worked Ok through > Xen (am running all this in dom0 by the way) with Opensuse (once > patches applied) and the version of Xen is not very different - > although the dom0 kernel will be I guess. > > Hi Jonathon, I would make two suggestions to you. 1. Check on the Mythtv forums (and post the question there), if you haven't already. They may have a bit more insight into the card with their system. And they may be able to sort out the lack of picture (even though it's not on their software). 2. If you can allocate a lower percentage of processor and/or memory to the Xen VM, that may solve part of the problem. My theory is that Xen is using too much of the CPU and/or memory right now, and everything else has to fight for what's left. Which means that when you try using the card, it's basically getting scraps. So it times out and can't scan. That's why it works (better at least) when Xen is off. If you can't allocate lower percentages, then maybe trying Virtualbox or VMWare would work. But, I would see what all you can do with Xen first. Have a great weekend. :) Patrick. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6+i3AACgkQMp6rvjb3CASrAACfW67fWDTETYRu6kQg/rRnxM14 53AAn3C3MMkFZaKcdGn+IUE9EGuuwBkn =p/K3 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any update on the Hauppauge WinTV-HVR-900H?
On 11/12/2011 07:26 AM, Rory McCann wrote: > Hi, > > I recently bought a Hauppauge WinTV-HVR-900H (usb id: 2040:b138), but I > see from this wiki page > http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-900H that there is > no driver for it. However that's as of 2008. > > Has there been any progress on this since? Is that wiki page correct > that there is still no support for that card? Is there anyway to get > this USB device to work under linux? > > Thanks, > Hi Rory, If you search for the 900H, you'll find a thread titled "Hauppauge HVR900H don't work with kernel 3.*". The original submitter stated that it worked in 2.6.x, but when the computer was upgraded to a 3.x kernel, it stopped working. This was two days ago (9 November 2011), so I'm not sure how much progress was made (if any). So, if your running a 2.6.x kernel, it *may* work, but it seems to be broken on the 3.x kernels (Ubuntu 11.10 or similar distros). Unfortunately I don't have that tuner, so I can't help out with it. I would say try it. You can check dmesg to see if the tuner is even being recognized (and drivers loaded). If so, then see if it works. If not, then you might need the latest build of the v4l. You can get information on installing the latest version from http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers . Then make it (without your tuner plugged in) and try plugging it in again. Check dmesg again, and if it's recognized, try it. Sorry I couldn't find more information on this. Also if anyone else posts a reply, I would defer to their suggestions--as they have more experience with this than me. Have a good weekend.:) Patrick. -- 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 00/25] Add PCTV-80e Support to v4l
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/2011 09:19 PM, Devin Heitmueller wrote: > On Thu, Nov 10, 2011 at 9:36 PM, Patrick Dickey > wrote: snipped to conserve space and also > unrelated to this email > > This shouldn't be the case (the two patches will have no > interaction with any driver other than em28xx). I would suggest > that instead of treating it as a tree, just suck the two patches > off the top and apply them to your current tree one at a time, and > fix any conflicts that pop up. > > http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/raw-rev/c119f08c4dd2 > > http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/raw-rev/30c6512030ac > > If you just apply the patches instead of trying to hand-merge the > two trees together, you will only get the delta and will likely > just have to fix the 4 or five conflicts in em28xx.h and > em28xx-cards.c (related to the fact that subsequent boards were > added to the driver after my patch). > Here are the results of applying the first patch (c119f08c4dd2.patch) to my branch: patch -p2 -i c119f08c4dd2.patch patching file Documentation/video4linux/CARDLIST.em28xx Hunk #1 FAILED at 72. 1 out of 1 hunk FAILED -- saving rejects to file Documentation/video4linux/CARDLIST.em28xx.rej patching file drivers/media/dvb/frontends/Kconfig Hunk #1 FAILED at 614. 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/dvb/frontends/Kconfig.rej patching file drivers/media/dvb/frontends/Makefile Hunk #1 FAILED at 82. 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/dvb/frontends/Makefile.rej patching file drivers/media/video/em28xx/em28xx-cards.c Hunk #1 succeeded at 193 with fuzz 1 (offset 12 lines). Hunk #2 succeeded at 1852 with fuzz 2 (offset 121 lines). Hunk #3 succeeded at 1980 with fuzz 1 (offset 125 lines). patching file drivers/media/video/em28xx/em28xx-dvb.c Hunk #1 FAILED at 35. Hunk #2 succeeded at 420 with fuzz 1 (offset 120 lines). Hunk #3 succeeded at 639 with fuzz 2 (offset 172 lines). Hunk #4 succeeded at 848 with fuzz 2 (offset 262 lines). 1 out of 4 hunks FAILED -- saving rejects to file drivers/media/video/em28xx/em28xx-dvb.c.rej patching file drivers/media/video/em28xx/em28xx.h Hunk #1 FAILED at 114. 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/em28xx/em28xx.h.rej patching file drivers/media/dvb/frontends/drx39xyj/Kconfig patching file drivers/media/dvb/frontends/drx39xyj/Makefile patching file drivers/media/dvb/frontends/drx39xyj/bsp_host.h patching file drivers/media/dvb/frontends/drx39xyj/bsp_i2c.h patching file drivers/media/dvb/frontends/drx39xyj/bsp_tuner.h patching file drivers/media/dvb/frontends/drx39xyj/bsp_types.h patching file drivers/media/dvb/frontends/drx39xyj/drx39xxj.c patching file drivers/media/dvb/frontends/drx39xyj/drx39xxj.h patching file drivers/media/dvb/frontends/drx39xyj/drx39xxj_dummy.c patching file drivers/media/dvb/frontends/drx39xyj/drx_dap_fasi.c patching file drivers/media/dvb/frontends/drx39xyj/drx_dap_fasi.h patching file drivers/media/dvb/frontends/drx39xyj/drx_driver.c patching file drivers/media/dvb/frontends/drx39xyj/drx_driver.h patching file drivers/media/dvb/frontends/drx39xyj/drx_driver_version.h patching file drivers/media/dvb/frontends/drx39xyj/drxj.c patching file drivers/media/dvb/frontends/drx39xyj/drxj.h patching file drivers/media/dvb/frontends/drx39xyj/drxj_map.h patching file drivers/media/dvb/frontends/drx39xyj/drxj_mc.h patching file drivers/media/dvb/frontends/drx39xyj/drxj_mc_vsb.h patching file drivers/media/dvb/frontends/drx39xyj/drxj_mc_vsbqam.h patching file drivers/media/dvb/frontends/drx39xyj/drxj_options.h > That approach should only take a few minutes, given the conflicts > are trivial to resolve. Yes they are trivial to resolve. The CARDLIST.em28xx needs to be changed to 81 and reflect the preceeding lines. The Kconfig and Makefile just need to have lines adjusted (and the endif removed from the Kconfig). I successfully applied the second patch (30c6512030ac.patch) to everything (since it's only changing your email address on the drx39xyj files). I have your two patches in my branch directory.Now I have a few options to choose from (as I see it) 1. Should I submit your two patches and then go back and fix the bugs, then submit those patches? 2. Should I fix the bugs first, then submit your two patches as 01 and 02, and my bug-fixes as 03 through 07? 3. Should I fix the bugs, then fix as many of the coding style issues as I can find, and submit all of the patches as one giant group (your two patches being 01 and 02, the bug fixes being 03 through 07, and the coding style fixes being 08 through 25 or so)? or 4. Should I fix your patches and submit those (I'm already ruling this out, but it does seem like the easiest way through this whole process)? If these seem like trivial or newbie questions, I'm sorry. I look at it like thi
Re: [PATCH 00/25] Add PCTV-80e Support to v4l
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/2011 09:19 PM, Devin Heitmueller wrote: > On Thu, Nov 10, 2011 at 9:36 PM, Patrick Dickey > wrote: >> Also, I started to clean up the files tonight. Then I started >> thinking about what you told me about the as102 drivers, and >> thought I should submit them "as is" and then start the cleanup >> and submit those patches separately. Also that way others could >> help with some of the cleanup. I have to figure out if there's an >> easy way to convert all of the "DOS Line Endings" to the >> appropriate style, or if I'll have to do that manually (and >> whether my editor(s) caused this). > > Definitely you want the cleanup fixes to be in separate patches > from the original patch with the driver. This is necessary because > it makes it *much* easier to figure out if something got broken as > a result of a cleanup patch (which isn't supposed to make any > functional change). > >> One reason I did the extra work is because your tree had other >> files (the cx18 drivers for example) that didn't seem to be >> needed by the tuner. So, I cleaned them out (partially because I >> have two cards that use those drivers and didn't want to break >> those). I can review all of the files to make sure that I didn't >> miss any. And I can update all of the files from your tree to >> the most current versions and submit everything again. > > This shouldn't be the case (the two patches will have no > interaction with any driver other than em28xx). I would suggest > that instead of treating it as a tree, just suck the two patches > off the top and apply them to your current tree one at a time, and > fix any conflicts that pop up. > > http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/raw-rev/c119f08c4dd2 > > http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/raw-rev/30c6512030ac > > If you just apply the patches instead of trying to hand-merge the > two trees together, you will only get the delta and will likely > just have to fix the 4 or five conflicts in em28xx.h and > em28xx-cards.c (related to the fact that subsequent boards were > added to the driver after my patch). > > That approach should only take a few minutes, given the conflicts > are trivial to resolve. > > Good luck! > > Devin > Thank you again for the quick reply. I think that the problem I had was that I hand merged everything (using meld, but that's beside the point). While I was at work last night, I decided that I need to do exactly what you suggested here. Hopefully that will take care of the Signed Off By problems too (if not, then I'll manually enter them). If this works as it should, how do I retract this patch series (as they'll no longer be valid) or is it safe to say that they'll be ignored from here out? Have a great day:) Patrick. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk69CW8ACgkQMp6rvjb3CAQm+QCcD9W6MlDVOWyLF6g9pK8GJPOs YLoAn3YINjWVGBRW+nhP02YHxAmT4nAu =ll3c -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] Add PCTV-80e Support to v4l
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/2011 07:45 PM, Devin Heitmueller wrote: > On Thu, Nov 10, 2011 at 6:31 PM, Patrick Dickey > wrote: >> These are the files required to support the Pinnacle PCTV-80e USB >> Tuner in video-4-linux. The files were originally downloaded >> from http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-80e and >> modified to fix compilation errors and also to move the driver >> files from the drx39xy subdirectory to the frontends directory. > > > Hi Patrick, > > It's great to see someone taking the time to work to get this > upstream. A few comments though: > > None of these patches appear to have an Signed-off-by line. Since > I'm the one vouching for the Micronas code being legitimately > allowed to be submitted (in conformance with the Developer's > Certificate of Origin), I am the one who needs to be the top > signed-off-by (in fact, by arbitrarily breaking my tree into 25 > patches, you effectively stripped off my authorship). > I thought the signed off lines were there. When I generated the patches, I used "git format-patch -s --subject-prefix='PATCH] [SIGNED-OFF' media-master " which I thought would add that in. However it must not have. I'll resubmit the patches with your name on the top and then mine below. It'll probably be tomorrow or Saturday before I get to that, though. > Further, while it's commendable that you broke this into 25 > patches, I think it's perfectly fine that it essentially be the two > patches as found in my hg tree (plus the very minor change needed > to get the code to compile against 3.x). In fact, I suspect you > could probably take my two patches, apply them to the current 3.x > tree, fix the two or three conflicts, and have something that is > submittable to staging. > The reason that I broke it up into 25 patches is because I did a test send to myself (as one patch for the entire driver) and it was almost 3MB in size. So, I decided to break it into a single patch for each file to reduce the size--and so each file could be dealt with separately. If that was the wrong thing to do, I'll fix it. > It's not clear to me why you moved the driver files from > frontends/drx39xxj to just frontends. I don't think anybody has > ever complained about having a subdirectory if there is a large > enough set of files. Did somebody ask you to do that and I didn't > see the email? > This was another unilateral decision. When I was trying to get this working on my computer, I found that make wouldn't even go into the subdirectory. Which meant that whenever I plugged the USB Tuner in, it would fail because it couldn't find the dvb_attach() method (from one of the driver files). After moving them from the subdirectory to frontends (and fixing the Makefile and Kconfig appropriately) everything compiled and loaded correctly. In the end, that was the only thing I found that worked. However, I can send them in the subdirectory also. > As you indicated, the code hasn't gone through any form of > codingstyle cleanup, and as a result needs to go against the > staging tree instead of the main tree. You should consult with > Mauro on how to approach this problem, because currently you cannot > do a demodulator driver against staging because of the dependency > on the em28xx bridge which is already in stable (adding Mauro to > the cc: to get his opinion). > This brings up a question for me. Most of the "trailing whitespace" errors aren't showing up in any of my editors (nano or meld to name two of them). And most of the trailing whitespace errors are in the comments. So are those really issues that will block the files from being submitted? Also, would they be happening because of the "DOS Line Ending" errors on most of the same lines? Also, I started to clean up the files tonight. Then I started thinking about what you told me about the as102 drivers, and thought I should submit them "as is" and then start the cleanup and submit those patches separately. Also that way others could help with some of the cleanup. I have to figure out if there's an easy way to convert all of the "DOS Line Endings" to the appropriate style, or if I'll have to do that manually (and whether my editor(s) caused this). For Mauro: I can either resubmit everything once it's cleaned up, go from here, start over and submit the original patches from Devin's tree, or whatever you think is best. > In short, it almost feels like you did *too much* work given you > didn't make any material changes to the code itself as it's in my > tree. I would suggest just submitting my two patches, and then on > top of that you can submit a whole series o
[PATCH 05/25] added bsp_types for pctv80e support
---
drivers/media/dvb/frontends/bsp_types.h | 229 +++
1 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/bsp_types.h
diff --git a/drivers/media/dvb/frontends/bsp_types.h
b/drivers/media/dvb/frontends/bsp_types.h
new file mode 100644
index 000..1c48046
--- /dev/null
+++ b/drivers/media/dvb/frontends/bsp_types.h
@@ -0,0 +1,229 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: bsp_types.h,v 1.5 2009/08/06 12:55:57 carlo Exp $
+*
+* \brief General type definitions for board support packages
+*
+* This file contains type definitions that are needed for almost any
+* board support package.
+* The definitions are host and project independent.
+*
+*/
+
+#ifndef __BSP_TYPES_H__
+#define __BSP_TYPES_H__
+/*-
+INCLUDES
+-*/
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+/*-
+TYPEDEFS
+-*/
+
+/**
+* \typedef unsigned char u8_t
+* \brief type definition of an unsigned 8 bits integer
+*/
+typedef unsigned char u8_t;
+/**
+* \typedef char s8_t
+* \brief type definition of a signed 8 bits integer
+*/
+typedef char s8_t;
+/**
+* \typedef unsigned short u16_t *pu16_t
+* \brief type definition of an unsigned 16 bits integer
+*/
+typedef unsigned short u16_t;
+/**
+* \typedef short s16_t
+* \brief type definition of a signed 16 bits integer
+*/
+typedef short s16_t;
+/**
+* \typedef unsigned long u32_t
+* \brief type definition of an unsigned 32 bits integer
+*/
+typedef unsigned long u32_t;
+/**
+* \typedef long s32_t
+* \brief type definition of a signed 32 bits integer
+*/
+typedef long s32_t;
+/*
+* \typedef struct ... u64_t
+* \brief type definition of an usigned 64 bits integer
+*/
+typedef struct {
+ u32_t MSLW;
+ u32_t LSLW;
+} u64_t;
+/*
+* \typedef struct ... i64_t
+* \brief type definition of a signed 64 bits integer
+*/
+typedef struct {
+ s32_t MSLW;
+ u32_t LSLW;
+} s64_t;
+
+/**
+* \typedef u8_t *pu8_t
+* \brief type definition of pointer to an unsigned 8 bits integer
+*/
+typedef u8_t *pu8_t;
+/**
+* \typedef s8_t *ps8_t
+* \brief type definition of pointer to a signed 8 bits integer
+*/
+typedef s8_t *ps8_t;
+/**
+* \typedef u16_t *pu16_t
+* \brief type definition of pointer to an unsigned 16 bits integer
+*/
+typedef u16_t*pu16_t;
+/**
+* \typedef s16_t *ps16_t
+* \brief type definition of pointer to a signed 16 bits integer
+*/
+typedef s16_t*ps16_t;
+/**
+* \typedef u32_t *pu32_t
+* \brief type definition of pointer to an unsigned 32 bits integer
+*/
+typedef u32_t*pu32_t;
+/**
+* \typedef s32_t *ps32_t
+* \brief type definition of pointer to a signed 32 bits integer
+*/
+typedef s32_t*ps32_t;
+/**
+* \typedef u64_t *pu64_t
+* \brief type definition of pointer to an usigned 64 bits integer
+*/
+typedef u64_t*pu64_t;
+/**
+* \typedef s64_t *ps64_t
+* \brief type definition of pointer to a signed 64 bits integer
+*/
+typedef s64_t*ps64_t;
+
+
+/**
+* \typedef s32_t DRXFrequency_t
+* \brief type definition of frequency
+*/
+typedef s32_t DRXFrequ
[PATCH 10/25] added drx_dap_fasi header for pctv80e support
--- drivers/media/dvb/frontends/drx_dap_fasi.h | 268 1 files changed, 268 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/frontends/drx_dap_fasi.h diff --git a/drivers/media/dvb/frontends/drx_dap_fasi.h b/drivers/media/dvb/frontends/drx_dap_fasi.h new file mode 100644 index 000..b1c0eb6 --- /dev/null +++ b/drivers/media/dvb/frontends/drx_dap_fasi.h @@ -0,0 +1,268 @@ +/* + Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc. + All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are met: + + * Redistributions of source code must retain the above copyright notice, +this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, +this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. + * Neither the name of Trident Microsystems nor Hauppauge Computer Works +nor the names of its contributors may be used to endorse or promote + products derived from this software without specific prior written + permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. +*/ + +/*** +* FILENAME: $Id: drx_dap_fasi.h,v 1.5 2009/07/07 14:21:40 justin Exp $ +* +* DESCRIPTION: +* Part of DRX driver. +* Data access protocol: Fast Access Sequential Interface (fasi) +* Fast access, because of short addressing format (16 instead of 32 bits addr) +* Sequential, because of I2C. +* +* USAGE: +* Include. +* +* NOTES: +* +* +***/ + +/* compilation control switches --*/ + +#ifndef __DRX_DAP_FASI_H__ +#define __DRX_DAP_FASI_H__ + +/* Required includes -*/ + +#include "drx_driver.h" + +/* Defines, configuring the API --*/ + +/ +* Allowed address formats +/ + +/* +* Comments about short/long addressing format: +* +* The DAP FASI offers long address format (4 bytes) and short address format +* (2 bytes). The DAP can operate in 3 modes: +* (1) only short +* (2) only long +* (3) both long and short but short preferred and long only when necesarry +* +* These modes must be selected compile time via compile switches. +* Compile switch settings for the diffrent modes: +* (1) DRXDAPFASI_LONG_ADDR_ALLOWED=0, DRXDAPFASI_SHORT_ADDR_ALLOWED=1 +* (2) DRXDAPFASI_LONG_ADDR_ALLOWED=1, DRXDAPFASI_SHORT_ADDR_ALLOWED=0 +* (3) DRXDAPFASI_LONG_ADDR_ALLOWED=1, DRXDAPFASI_SHORT_ADDR_ALLOWED=1 +* +* The default setting will be (3) both long and short. +* The default setting will need no compile switches. +* The default setting must be overridden if compile switches are already +* defined. +* +*/ + +/* set default */ +#if !defined(DRXDAPFASI_LONG_ADDR_ALLOWED) +#define DRXDAPFASI_LONG_ADDR_ALLOWED 1 +#endif + +/* set default */ +#if !defined(DRXDAPFASI_SHORT_ADDR_ALLOWED) +#define DRXDAPFASI_SHORT_ADDR_ALLOWED 1 +#endif + +/* check */ +#if ((DRXDAPFASI_LONG_ADDR_ALLOWED==0) && \ + (DRXDAPFASI_SHORT_ADDR_ALLOWED==0)) +#error At least one of short- or long-addressing format must be allowed. +*; /* illegal statement to force compiler error */ +#endif + + +/ +* Single/master multi master setting +/ +/* +* Comments about SINGLE MASTER/MULTI MASTER modes: +* +* Consider the two sides:1) the master and 2)the slave. +* +* Master: +* Single/multimaster operation set via DRXDAP_SINGLE_MASTER compile switch +* + single master mode means no use of repeated starts +* + multi master mode means use of repeated starts +* Default is single master. +* Default can be overriden by setting the compile switch DRXDAP_SINGLE_MASTER. +* +* Slave: +* Single/multi master selected via the flags in the FASI protocol. +* + single master m
[PATCH 15/25] added drxj header for pctv80e support
---
drivers/media/dvb/frontends/drxj.h | 990
1 files changed, 990 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drxj.h
diff --git a/drivers/media/dvb/frontends/drxj.h
b/drivers/media/dvb/frontends/drxj.h
new file mode 100644
index 000..5899537
--- /dev/null
+++ b/drivers/media/dvb/frontends/drxj.h
@@ -0,0 +1,990 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: drxj.h,v 1.132 2009/12/22 12:13:48 danielg Exp $
+*
+* \brief DRXJ specific header file
+*
+* \author Dragan Savic, Milos Nikolic, Mihajlo Katona, Tao Ding, Paul Janssen
+*/
+
+#ifndef __DRXJ_H__
+#define __DRXJ_H__
+/*-
+INCLUDES
+-*/
+
+#include "drx_driver.h"
+#include "drx_dap_fasi.h"
+
+#ifdef __cplusplus
+extern "C" {
+
+#endif /*
+ */
+
+/* Check DRX-J specific dap condition */
+/* Multi master mode and short addr format only will not work.
+ RMW, CRC reset, broadcast and switching back to single master mode
+ cannot be done with short addr only in multi master mode. */
+#if ((DRXDAP_SINGLE_MASTER==0)&&(DRXDAPFASI_LONG_ADDR_ALLOWED==0))
+#error "Multi master mode and short addressing only is an illegal combination"
+ *; /* Generate a fatal compiler error to make sure
it stops here,
+ this is necesarry because not all compilers
stop after a #error. */
+
+#endif /*
+ */
+
+/*-
+TYPEDEFS
+-*/
+/**/
+/**/
+/*== code support
*/
+/**/
+/**/
+
+/**/
+/**/
+/*== SCU cmd if
=*/
+/**/
+/**/
+
+typedef struct {
+
+u16_t command;
+/**< Command number */
+
+u16_t parameterLen;
+/**< Data length in byte */
+
+u16_t resultLen;
+/**< result length in byte */
+
+u16_t * parameter;
+/**< General purpous param */
+
+u16_t * result;
+/**< General purpous param */
+
+} DRXJSCUCmd_t, *pDRXJSCUCmd_t;
+
+
+
+/**/
+/**/
+/*== CTRL CFG related data structures
*/
+/**/
+/*==
[PATCH 20/25] added drxj_options header for pctv80e support
---
drivers/media/dvb/frontends/drxj_options.h | 65
1 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drxj_options.h
diff --git a/drivers/media/dvb/frontends/drxj_options.h
b/drivers/media/dvb/frontends/drxj_options.h
new file mode 100644
index 000..962bd61
--- /dev/null
+++ b/drivers/media/dvb/frontends/drxj_options.h
@@ -0,0 +1,65 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: drxj_options.h,v 1.5 2009/10/05 21:32:49 dingtao Exp $
+*
+* \brief DRXJ optional settings
+*
+* \author Tao Ding
+*/
+
+/* Note: Please add preprocessor DRXJ_OPTIONS_H for drxj.c to include this
file */
+#ifndef __DRXJ_OPTIONS_H__
+#define __DRXJ_OPTIONS_H__
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* #define DRXJ_DIGITAL_ONLY */
+/* #define DRXJ_VSB_ONLY */
+/* #define DRXJ_SIGNAL_ACCUM_ERR */
+/* #define MPEG_SERIAL_OUTPUT_PIN_DRIVE_STRENGTH 0x03 */
+/* #define MPEG_PARALLEL_OUTPUT_PIN_DRIVE_STRENGTH 0x04 */
+/* #define MPEG_OUTPUT_CLK_DRIVE_STRENGTH0x05 */
+/* #define OOB_CRX_DRIVE_STRENGTH0x04 */
+/* #define OOB_DRX_DRIVE_STRENGTH0x05 */
+/* #define DRXJ_QAM_MAX_WAITTIME 1000 */
+/* #define DRXJ_QAM_FEC_LOCK_WAITTIME200 */
+/* #define DRXJ_QAM_DEMOD_LOCK_EXT_WAITTIME 250 */
+
+/*-
+THE END
+-*/
+#ifdef __cplusplus
+}
+#endif
+#endif /* __DRXJ_OPTIONS_H__ */
--
1.7.5.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
[PATCH 23/25] modified em28xx-cards for pctv80e support
---
drivers/media/video/em28xx/em28xx-cards.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 9b747c2..550bb8e 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -195,6 +195,17 @@ static struct em28xx_reg_seq pinnacle_hybrid_pro_digital[]
= {
{ -1, -1, -1, -1},
};
+/* PCTV HD Mini (80e) GPIOs
+ 0-5: not used
+ 6: demod reset, active low
+ 7: LED on, active high */
+static struct em28xx_reg_seq em2874_pctv_80e_digital[] = {
+ {EM28XX_R06_I2C_CLK,0x45, 0xff, 10}, /*400 KHz*/
+ {EM2874_R80_GPIO, 0x80, 0xff, 100},/*Demod reset*/
+ {EM2874_R80_GPIO, 0xc0, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
static struct em28xx_reg_seq terratec_cinergy_USB_XS_FR_analog[] = {
{EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
{EM2880_R04_GPO,0x00, 0xff, 10},
@@ -1808,6 +1819,13 @@ struct em28xx_board em28xx_boards[] = {
.tuner_gpio= reddo_dvb_c_usb_box,
.has_dvb = 1,
},
+ [EM2874_BOARD_PCTV_HD_MINI_80E] = {
+ .name = "Pinnacle PCTV HD Mini",
+ .tuner_type = TUNER_ABSENT,
+ .has_dvb = 1,
+ .dvb_gpio = em2874_pctv_80e_digital,
+ .decoder = EM28XX_NODECODER,
+ },
/* 1b80:a340 - Empia EM2870, NXP TDA18271HD and LG DT3304, sold
* initially as the KWorld PlusTV 340U, then as the UB435-Q.
* Early variants have a TDA18271HD/C1, later ones a TDA18271HD/C2 */
@@ -1961,6 +1979,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2882_BOARD_PINNACLE_HYBRID_PRO_330E },
{ USB_DEVICE(0x2304, 0x0227),
.driver_info = EM2880_BOARD_PINNACLE_PCTV_HD_PRO },
+ { USB_DEVICE(0x2304, 0x023f),
+ .driver_info = EM2874_BOARD_PCTV_HD_MINI_80E },
{ USB_DEVICE(0x0413, 0x6023),
.driver_info = EM2800_BOARD_LEADTEK_WINFAST_USBII },
{ USB_DEVICE(0x093b, 0xa005),
--
1.7.5.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
[PATCH 24/25] modified em28xx-dvb for pctv80e support
---
drivers/media/video/em28xx/em28xx-dvb.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c
b/drivers/media/video/em28xx/em28xx-dvb.c
index cef7a2d..b69e5f3 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -36,6 +36,7 @@
#include "mt352.h"
#include "mt352_priv.h" /* FIXME */
#include "tda1002x.h"
+#include "drx39xxj.h"
#include "tda18271.h"
#include "s921.h"
#include "drxd.h"
@@ -309,6 +310,20 @@ static struct drxd_config em28xx_drxd = {
.disable_i2c_gate_ctrl = 1,
};
+
+static struct tda18271_std_map drx_j_std_map = {
+ .atsc_6 = { .if_freq = 5000, .agc_mode = 3, .std = 0, .if_lvl = 1,
+ .rfagc_top = 0x37, },
+ .qam_6= { .if_freq = 5380, .agc_mode = 3, .std = 3, .if_lvl = 1,
+ .rfagc_top = 0x37, },
+};
+
+static struct tda18271_config pinnacle_80e_dvb_config = {
+ .std_map = &drx_j_std_map,
+ .gate= TDA18271_GATE_DIGITAL,
+ .role= TDA18271_MASTER,
+};
+
struct drxk_config terratec_h5_drxk = {
.adr = 0x29,
.single_master = 1,
@@ -625,6 +640,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
{
int result = 0, mfe_shared = 0;
struct em28xx_dvb *dvb;
+ struct dvb_frontend *fe;
if (!dev->board.has_dvb) {
/* This device does not support the extension */
@@ -752,6 +768,15 @@ static int em28xx_dvb_init(struct em28xx *dev)
}
}
break;
+ case EM2874_BOARD_PCTV_HD_MINI_80E:
+ dvb->fe[0] = dvb_attach(drx39xxj_attach, &dev->i2c_adap);
+ if (dvb->fe[0] != NULL) {
+ fe = dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
+ &dev->i2c_adap,
+ &pinnacle_80e_dvb_config);
+ printk(KERN_ERR "dvb_attach tuner result=%p\n", fe);
+ }
+ break;
case EM2870_BOARD_KWORLD_A340:
dvb->fe[0] = dvb_attach(lgdt3305_attach,
&em2870_lgdt3304_dev,
--
1.7.5.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
[PATCH 25/25] modified em28xx header for pctv80e support
--- drivers/media/video/em28xx/em28xx.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/em28xx/em28xx.h b/drivers/media/video/em28xx/em28xx.h index 2a2cb7e..ead2cfe 100644 --- a/drivers/media/video/em28xx/em28xx.h +++ b/drivers/media/video/em28xx/em28xx.h @@ -121,6 +121,7 @@ #define EM28174_BOARD_PCTV_290E 78 #define EM2884_BOARD_TERRATEC_H5 79 #define EM28174_BOARD_PCTV_460E 80 +#define EM2874_BOARD_PCTV_HD_MINI_80E81 /* Limits minimum and default number of buffers */ #define EM28XX_MIN_BUF 4 -- 1.7.5.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
[PATCH 22/25] modified Makefile for pctv80e support
--- drivers/media/dvb/frontends/Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/frontends/Makefile b/drivers/media/dvb/frontends/Makefile index f639f67..4709ebc 100644 --- a/drivers/media/dvb/frontends/Makefile +++ b/drivers/media/dvb/frontends/Makefile @@ -11,6 +11,7 @@ au8522-objs = au8522_dig.o au8522_decoder.o drxd-objs = drxd_firm.o drxd_hard.o cxd2820r-objs = cxd2820r_core.o cxd2820r_c.o cxd2820r_t.o cxd2820r_t2.o drxk-objs := drxk_hard.o +drx39xyj-objs := drx39xxj.o drx_driver.o drx39xxj_dummy.o drxj.o drx_dap_fasi.o obj-$(CONFIG_DVB_PLL) += dvb-pll.o obj-$(CONFIG_DVB_STV0299) += stv0299.o @@ -86,6 +87,7 @@ obj-$(CONFIG_DVB_ISL6423) += isl6423.o obj-$(CONFIG_DVB_EC100) += ec100.o obj-$(CONFIG_DVB_DS3000) += ds3000.o obj-$(CONFIG_DVB_MB86A16) += mb86a16.o +obj-$(CONFIG_DVB_DRX39XYJ) += drx39xyj.o obj-$(CONFIG_DVB_MB86A20S) += mb86a20s.o obj-$(CONFIG_DVB_IX2505V) += ix2505v.o obj-$(CONFIG_DVB_STV0367) += stv0367.o -- 1.7.5.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
[PATCH 21/25] modified Kconfig to include pctv80e support
--- drivers/media/dvb/frontends/Kconfig |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/frontends/Kconfig b/drivers/media/dvb/frontends/Kconfig index 4a2d2e6..352815e 100644 --- a/drivers/media/dvb/frontends/Kconfig +++ b/drivers/media/dvb/frontends/Kconfig @@ -683,6 +683,14 @@ config DVB_IX2505V help A DVB-S tuner module. Say Y when you want to support this frontend. +config DVB_DRX39XYJ + tristate "Micronas DRX-J demodulator" + depends on DVB_CORE && I2C + default m if DVB_FE_CUSTOMISE + help + An ATSC 8VSB and QAM64/256 tuner module. Say Y when you want + to support this frontend. + config DVB_IT913X_FE tristate "it913x frontend and it9137 tuner" depends on DVB_CORE && I2C -- 1.7.5.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
[PATCH 08/25] added drx39_dummy for pctv80e support
---
drivers/media/dvb/frontends/drx39xxj_dummy.c | 135 ++
1 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drx39xxj_dummy.c
diff --git a/drivers/media/dvb/frontends/drx39xxj_dummy.c
b/drivers/media/dvb/frontends/drx39xxj_dummy.c
new file mode 100644
index 000..3ed2c39
--- /dev/null
+++ b/drivers/media/dvb/frontends/drx39xxj_dummy.c
@@ -0,0 +1,135 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drx_driver.h"
+#include "bsp_types.h"
+#include "bsp_tuner.h"
+#include "drx39xxj.h"
+
+/* Dummy function to satisfy drxj.c */
+DRXStatus_t DRXBSP_TUNER_Open(pTUNERInstance_t tuner)
+{
+ return DRX_STS_OK;
+}
+
+DRXStatus_t DRXBSP_TUNER_Close(pTUNERInstance_t tuner)
+{
+ return DRX_STS_OK;
+}
+
+DRXStatus_t DRXBSP_TUNER_SetFrequency(pTUNERInstance_t tuner,
+ TUNERMode_t mode,
+ DRXFrequency_t centerFrequency)
+{
+ return DRX_STS_OK;
+}
+
+DRXStatus_t
+DRXBSP_TUNER_GetFrequency(pTUNERInstance_t tuner,
+ TUNERMode_t mode,
+ pDRXFrequency_t RFfrequency,
+ pDRXFrequency_t IFfrequency)
+{
+ return DRX_STS_OK;
+}
+
+DRXStatus_t DRXBSP_HST_Sleep(u32_t n)
+{
+ msleep(n);
+ return DRX_STS_OK;
+}
+
+u32_t DRXBSP_HST_Clock(void)
+{
+ return jiffies_to_msecs(jiffies);
+}
+
+int DRXBSP_HST_Memcmp(void *s1, void *s2, u32_t n)
+{
+ return (memcmp(s1, s2, (size_t) n));
+}
+
+void* DRXBSP_HST_Memcpy(void *to, void *from, u32_t n)
+{
+ return (memcpy(to, from, (size_t) n));
+}
+
+DRXStatus_t DRXBSP_I2C_WriteRead(pI2CDeviceAddr_t wDevAddr,
+ u16_twCount,
+ pu8_twData,
+ pI2CDeviceAddr_t rDevAddr,
+ u16_trCount,
+ pu8_trData)
+{
+ struct drx39xxj_state *state;
+ struct i2c_msg msg[2];
+ unsigned int num_msgs;
+
+ if (wDevAddr == NULL) {
+ /* Read only */
+ state = rDevAddr->userData;
+ msg[0].addr = rDevAddr->i2cAddr >> 1;
+ msg[0].flags = I2C_M_RD;
+ msg[0].buf = rData;
+ msg[0].len = rCount;
+ num_msgs = 1;
+ } else if (rDevAddr == NULL) {
+ /* Write only */
+ state = wDevAddr->userData;
+ msg[0].addr = wDevAddr->i2cAddr >> 1;
+ msg[0].flags = 0;
+ msg[0].buf = wData;
+ msg[0].len = wCount;
+ num_msgs = 1;
+ } else {
+ /* Both write and read */
+ state = wDevAddr->userData;
+ msg[0].addr = wDevAddr->i2cAddr >> 1;
+ msg[0].flags = 0;
+ msg[0].buf = wData;
+ msg[0].len = wCount;
+ msg[1].addr = rDevAddr->i2cAddr >> 1;
+ msg[1].flags = I2C_M_RD;
+ msg[1].buf = rData;
+ msg[1].len = rCount;
+ num_msgs = 2;
+ }
+
+ if (state->i2c == NULL) {
+ printk("i2c was zero, aborting\n");
+ return 0;
+ }
+ if (i2c_transfer(state->i2c, msg, num_msgs) != num_msgs) {
+ printk(KERN_WARNING "drx3933: I2C write/read failed\n");
+ return -EREMOTEIO;
+ }
+
+ return DRX_STS_OK;
+
+#ifdef DJH_DEBUG
+
+ struct drx39xxj_state *state = wDevAddr->userData;
+
+ struct i2c_msg msg[2] = {
+ { .addr = wDevAddr->i2cAddr,
+ .flags = 0, .buf = wData, .len = wCount },
+ { .addr = rDevAddr->i2cAddr,
+ .flags = I2C_M_RD, .buf = rData, .len = rCount },
+ };
+
+ printk("drx3933 i2c operation addr=%x i2c=%p, wc=%x rc=%x\n",
+ wDevAddr->i2cAddr, state->i2c, wCount, rCount);
+
+ if (i2c_transfer(state->i2c, msg, 2) != 2) {
+ printk(KERN_WARNING "drx3933: I2C write/read failed\n");
+ return -EREMOTEIO;
+ }
+#endif
+ return 0;
+}
--
1.7.5.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
[PATCH 13/25] added drx_driver_version header for pctv80e support
---
drivers/media/dvb/frontends/drx_driver_version.h | 82 ++
1 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drx_driver_version.h
diff --git a/drivers/media/dvb/frontends/drx_driver_version.h
b/drivers/media/dvb/frontends/drx_driver_version.h
new file mode 100644
index 000..b6a37d8
--- /dev/null
+++ b/drivers/media/dvb/frontends/drx_driver_version.h
@@ -0,0 +1,82 @@
+/*
+
***
+ * WARNING - THIS FILE HAS BEEN GENERATED - DO NOT CHANGE
+ *
+ * Filename:drx_driver_version.h
+ * Generated on:Mon Jan 18 12:09:23 2010
+ * Generated by:IDF:x 1.3.0
+ * Generated from: ../../../device/drxj/version
+ * Output start:[entry point]
+ *
+ * filename last modified re-use
+ *
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/* -
+ * version.idf Mon Jan 18 11:56:10 2010-
+ *
+ */
+
+#ifndef __DRX_DRIVER_VERSION__H__
+#define __DRX_DRIVER_VERSION__H__ INCLUDED
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#ifdef _REGISTERTABLE_
+#include
+extern RegisterTable_t drx_driver_version[];
+extern RegisterTableInfo_t drx_driver_version_info[];
+#endif /* _REGISTERTABLE_ */
+
+
+/*
+
*==
+ * VERSION
+ * version@/var/cvs/projects/drxj.cvsroot/hostcode/drxdriver/device/drxj
+
*==
+ */
+
+#define VERSION__A 0x0
+#define VERSION_MAJOR 1
+#define VERSION_MINOR 0
+#define VERSION_PATCH 56
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __DRX_DRIVER_VERSION__H__ */
+
+/*
+ * End of file (drx_driver_version.h)
+
***
+ */
--
1.7.5.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
[PATCH 11/25] added drx_driver for pctv80e support
--- drivers/media/dvb/frontends/drx_driver.c | 1504 ++ 1 files changed, 1504 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/frontends/drx_driver.c diff --git a/drivers/media/dvb/frontends/drx_driver.c b/drivers/media/dvb/frontends/drx_driver.c new file mode 100644 index 000..1f58de7 --- /dev/null +++ b/drivers/media/dvb/frontends/drx_driver.c @@ -0,0 +1,1504 @@ +/* + Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc. + All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are met: + + * Redistributions of source code must retain the above copyright notice, +this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, +this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. + * Neither the name of Trident Microsystems nor Hauppauge Computer Works +nor the names of its contributors may be used to endorse or promote + products derived from this software without specific prior written + permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. +*/ + +/** +* \file $Id: drx_driver.c,v 1.40 2010/01/12 01:24:56 lfeng Exp $ +* +* \brief Generic DRX functionality, DRX driver core. +* +*/ + +/*-- +INCLUDE FILES +--*/ +#include "drx_driver.h" +#include "bsp_host.h" + +#define VERSION_FIXED 0 +#if VERSION_FIXED +#define VERSION_MAJOR 0 +#define VERSION_MINOR 0 +#define VERSION_PATCH 0 +#else +#include "drx_driver_version.h" +#endif + +/*-- +DEFINES +--*/ + +/**/ +/*=== MICROCODE RELATED DEFINES ==*/ +/**/ + +/** \brief Magic word for checking correct Endianess of microcode data. */ +#ifndef DRX_UCODE_MAGIC_WORD +#define DRX_UCODE_MAGIC_WORD u16_t)'H')<<8)+((u16_t)'L')) +#endif + +/** \brief CRC flag in ucode header, flags field. */ +#ifndef DRX_UCODE_CRC_FLAG +#define DRX_UCODE_CRC_FLAG (0x0001) +#endif + +/** \brief Compression flag in ucode header, flags field. */ +#ifndef DRX_UCODE_COMPRESSION_FLAG +#define DRX_UCODE_COMPRESSION_FLAG (0x0002) +#endif + +/** \brief Maximum size of buffer used to verify the microcode. + Must be an even number. */ +#ifndef DRX_UCODE_MAX_BUF_SIZE +#define DRX_UCODE_MAX_BUF_SIZE (DRXDAP_MAX_RCHUNKSIZE) +#endif +#if DRX_UCODE_MAX_BUF_SIZE & 1 +#error DRX_UCODE_MAX_BUF_SIZE must be an even number +#endif + +/**/ +/*=== CHANNEL SCAN RELATED DEFINES ===*/ +/**/ + +/** +* \brief Maximum progress indication. +* +* Progress indication will run from 0 upto DRX_SCAN_MAX_PROGRESS during scan. +* +*/ +#ifndef DRX_SCAN_MAX_PROGRESS +#define DRX_SCAN_MAX_PROGRESS 1000 +#endif + +/**/ +/*=== MACROS =*/ +/**/ + +#define DRX_ISPOWERDOWNMODE(mode) ((mode == DRX_POWER_MODE_9) || \ + (mode == DRX_POWER_MODE_10) || \ + (mode == DRX_POWER_MODE_11) || \ + (mode == DRX_POWER_MODE_12) || \ + (mode == DRX_POWER_MODE_13) || \ + (mode == DRX_POWER_MODE_14) || \ + (mode == DRX_POWE
[PATCH 06/25] added drx39xxj for pctv80e support
---
drivers/media/dvb/frontends/drx39xxj.c | 464
1 files changed, 464 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drx39xxj.c
diff --git a/drivers/media/dvb/frontends/drx39xxj.c
b/drivers/media/dvb/frontends/drx39xxj.c
new file mode 100644
index 000..a74e81b
--- /dev/null
+++ b/drivers/media/dvb/frontends/drx39xxj.c
@@ -0,0 +1,464 @@
+/*
+ * Driver for Micronas DRX39xx family (drx3933j)
+ *
+ * Written by Devin Heitmueller
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.=
+ */
+
+#include
+#include
+#include
+#include
+
+#include "dvb_frontend.h"
+#include "drx39xxj.h"
+#include "drx_driver.h"
+#include "bsp_types.h"
+#include "bsp_tuner.h"
+#include "drxj_mc.h"
+#include "drxj.h"
+
+static int drx39xxj_set_powerstate(struct dvb_frontend* fe, int enable)
+{
+ struct drx39xxj_state *state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demod;
+ DRXStatus_t result;
+ DRXPowerMode_t powerMode;
+
+ if (enable)
+ powerMode = DRX_POWER_UP;
+ else
+ powerMode = DRX_POWER_DOWN;
+
+ result = DRX_Ctrl(demod, DRX_CTRL_POWER_MODE, &powerMode);
+ if (result != DRX_STS_OK) {
+ printk("Power state change failed\n");
+ return 0;
+ }
+
+ state->powered_up = enable;
+ return 0;
+}
+
+static int drx39xxj_read_status(struct dvb_frontend* fe, fe_status_t* status)
+{
+ struct drx39xxj_state* state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demod;
+ DRXStatus_t result;
+ DRXLockStatus_t lock_status;
+
+ *status = 0;
+
+ result = DRX_Ctrl(demod, DRX_CTRL_LOCK_STATUS, &lock_status);
+ if (result != DRX_STS_OK) {
+ printk("drx39xxj: could not get lock status!\n");
+ *status = 0;
+ }
+
+ switch (lock_status) {
+ case DRX_NEVER_LOCK:
+ *status = 0;
+ printk("drx says NEVER_LOCK\n");
+ break;
+ case DRX_NOT_LOCKED:
+ *status = 0;
+ break;
+ case DRX_LOCK_STATE_1:
+ case DRX_LOCK_STATE_2:
+ case DRX_LOCK_STATE_3:
+ case DRX_LOCK_STATE_4:
+ case DRX_LOCK_STATE_5:
+ case DRX_LOCK_STATE_6:
+ case DRX_LOCK_STATE_7:
+ case DRX_LOCK_STATE_8:
+ case DRX_LOCK_STATE_9:
+ *status = FE_HAS_SIGNAL
+ | FE_HAS_CARRIER
+ | FE_HAS_VITERBI
+ | FE_HAS_SYNC;
+ break;
+ case DRX_LOCKED:
+ *status = FE_HAS_SIGNAL
+ | FE_HAS_CARRIER
+ | FE_HAS_VITERBI
+ | FE_HAS_SYNC
+ | FE_HAS_LOCK;
+ break;
+ default:
+ printk("Lock state unknown %d\n", lock_status);
+ }
+
+ return 0;
+}
+
+static int drx39xxj_read_ber(struct dvb_frontend* fe, u32* ber)
+{
+ struct drx39xxj_state* state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demod;
+ DRXStatus_t result;
+ DRXSigQuality_t sig_quality;
+
+ result = DRX_Ctrl(demod, DRX_CTRL_SIG_QUALITY, &sig_quality);
+ if (result != DRX_STS_OK) {
+ printk("drx39xxj: could not get ber!\n");
+ *ber = 0;
+ return 0;
+ }
+
+ *ber = sig_quality.postReedSolomonBER;
+ return 0;
+}
+
+static int drx39xxj_read_signal_strength(struct dvb_frontend* fe, u16*
strength)
+{
+ struct drx39xxj_state* state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demod;
+ DRXStatus_t result;
+ DRXSigQuality_t sig_quality;
+
+ result = DRX_Ctrl(demod, DRX_CTRL_SIG_QUALITY, &sig_quality);
+ if (result != DRX_STS_OK) {
+ printk("drx39xxj: could not get signal strength!\n");
+ *strength = 0;
+ return 0;
+ }
+
+ /* 1-100% scaled to 0-65535 */
+ *strength = (sig_quality.indicator * 65535 / 100);
+ return 0;
+}
+
+static int drx39xxj_read_snr(struct dvb_frontend* fe, u16* snr)
+{
+ struct drx39xxj_state* state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demo
[PATCH 09/25] added drx_dap_fasi for pctv80e support
--- drivers/media/dvb/frontends/drx_dap_fasi.c | 670 1 files changed, 670 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/frontends/drx_dap_fasi.c diff --git a/drivers/media/dvb/frontends/drx_dap_fasi.c b/drivers/media/dvb/frontends/drx_dap_fasi.c new file mode 100644 index 000..f34641d --- /dev/null +++ b/drivers/media/dvb/frontends/drx_dap_fasi.c @@ -0,0 +1,670 @@ +/* + Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc. + All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are met: + + * Redistributions of source code must retain the above copyright notice, +this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, +this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. + * Neither the name of Trident Microsystems nor Hauppauge Computer Works +nor the names of its contributors may be used to endorse or promote + products derived from this software without specific prior written + permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. +*/ + +/*** +* FILENAME: $Id: drx_dap_fasi.c,v 1.7 2009/12/28 14:36:21 carlo Exp $ +* +* DESCRIPTION: +* Part of DRX driver. +* Data access protocol: Fast Access Sequential Interface (fasi) +* Fast access, because of short addressing format (16 instead of 32 bits addr) +* Sequential, because of I2C. +* These functions know how the chip's memory and registers are to be accessed, +* but nothing more. +* +* These functions should not need adapting to a new platform. +* +* USAGE: +* - +* +* NOTES: +* +* +***/ + +#include "drx_dap_fasi.h" +#include "bsp_host.h" /* for DRXBSP_HST_Memcpy() */ + +/**/ + +/* Function prototypes */ +static DRXStatus_t DRXDAP_FASI_WriteBlock ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t addr, /* address of register/memory */ + u16_t datasize, /* size of data */ + pu8_t data, /* data to send */ + DRXflags_tflags);/* special device flags */ + +static DRXStatus_t DRXDAP_FASI_ReadBlock ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t addr, /* address of register/memory */ + u16_t datasize, /* size of data */ + pu8_t data, /* data to send */ + DRXflags_tflags);/* special device flags */ + +static DRXStatus_t DRXDAP_FASI_WriteReg8 ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t addr, /* address of register */ + u8_t data, /* data to write*/ + DRXflags_tflags);/* special device flags */ + +static DRXStatus_t DRXDAP_FASI_ReadReg8 ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t addr, /* address of register */ + pu8_t data, /* buffer to receive data */ + DRXflags_tflags);/* special device flags */ + +static DRXStatus_t DRXDAP_FASI_ReadModifyWriteReg8 ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t waddr, /* address of register */ + DRXaddr_t raddr, /* address to read back from*/ + u8_t datain,/* data to send */ + pu8_t dataout); /* data to receive back */ + +static DRXStatus_t DRXDAP_FASI_WriteReg16 ( + pI2CDeviceAddr_t devAddr, /*
[PATCH 07/25] added drx39xxj header for pctv80e support
---
drivers/media/dvb/frontends/drx39xxj.h | 40
1 files changed, 40 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drx39xxj.h
diff --git a/drivers/media/dvb/frontends/drx39xxj.h
b/drivers/media/dvb/frontends/drx39xxj.h
new file mode 100644
index 000..168d251
--- /dev/null
+++ b/drivers/media/dvb/frontends/drx39xxj.h
@@ -0,0 +1,40 @@
+/*
+ * Driver for Micronas DRX39xx family (drx3933j)
+ *
+ * Written by Devin Heitmueller
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.=
+ */
+
+#ifndef DRX39XXJ_H
+#define DRX39XXJ_H
+
+#include
+#include "dvb_frontend.h"
+#include "drx_driver.h"
+
+struct drx39xxj_state {
+ struct i2c_adapter *i2c;
+ DRXDemodInstance_t *demod;
+ DRXStandard_t current_standard;
+ struct dvb_frontend frontend;
+ int powered_up:1;
+ unsigned int i2c_gate_open:1;
+};
+
+extern struct dvb_frontend *drx39xxj_attach(struct i2c_adapter *i2c);
+
+#endif // DRX39XXJ_H
--
1.7.5.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
[PATCH 04/25] added bsp_tuner for pctv80e support
---
drivers/media/dvb/frontends/bsp_tuner.h | 215 +++
1 files changed, 215 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/bsp_tuner.h
diff --git a/drivers/media/dvb/frontends/bsp_tuner.h
b/drivers/media/dvb/frontends/bsp_tuner.h
new file mode 100644
index 000..b67027f
--- /dev/null
+++ b/drivers/media/dvb/frontends/bsp_tuner.h
@@ -0,0 +1,215 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: bsp_tuner.h,v 1.5 2009/10/19 22:15:13 dingtao Exp $
+*
+* \brief Tuner dependable type definitions, macro's and functions
+*
+*/
+
+#ifndef __DRXBSP_TUNER_H__
+#define __DRXBSP_TUNER_H__
+/*--
+INCLUDES
+--*/
+#include "bsp_types.h"
+#include "bsp_i2c.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*--
+DEFINES
+--*/
+
+
+ /* Sub-mode bits should be adjacent and incremental */
+#define TUNER_MODE_SUB00x0001 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB10x0002 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB20x0004 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB30x0008 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB40x0010 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB50x0020 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB60x0040 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB70x0080 /* for sub-mode (e.g. RF-AGC setting) */
+
+#define TUNER_MODE_DIGITAL 0x0100 /* for digital channel (e.g. DVB-T) */
+#define TUNER_MODE_ANALOG 0x0200 /* for analog channel (e.g. PAL) */
+#define TUNER_MODE_SWITCH 0x0400 /* during channel switch & scanning */
+#define TUNER_MODE_LOCK0x0800 /* after tuner has locked */
+#define TUNER_MODE_6MHZ0x1000 /* for 6MHz bandwidth channels*/
+#define TUNER_MODE_7MHZ0x2000 /* for 7MHz bandwidth channels*/
+#define TUNER_MODE_8MHZ0x4000 /* for 8MHz bandwidth channels*/
+
+#define TUNER_MODE_SUB_MAX 8
+#define TUNER_MODE_SUBALL (TUNER_MODE_SUB0 | TUNER_MODE_SUB1 | \
+ TUNER_MODE_SUB2 | TUNER_MODE_SUB3 | \
+ TUNER_MODE_SUB4 | TUNER_MODE_SUB5 | \
+ TUNER_MODE_SUB6 | TUNER_MODE_SUB7)
+
+/*--
+TYPEDEFS
+--*/
+
+typedef u32_t TUNERMode_t;
+typedef pu32_t pTUNERMode_t;
+
+typedef char* TUNERSubMode_t;/* description of submode */
+typedef TUNERSubMode_t *pTUNERSubMode_t;
+
+
+typedef enum {
+
+ TUNER_LOCKED,
+ TUNER_NOT_LOCKED
+
+} TUNERLockStatus_t, *pTUNERLockStatus_t;
+
+
+typedef struct {
+
+ char *name; /* Tuner brand & type name */
+ DRXFrequency_t minFreqRF; /* Lowest RF input frequency, in kHz */
+ DRXFrequency_t maxFreqRF; /* Highest RF input frequency, in kHz */
+
+ u8_tsubMode;
[PATCH 03/25] added bsp_i2c for pctv80e support
---
drivers/media/dvb/frontends/bsp_i2c.h | 217 +
1 files changed, 217 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/bsp_i2c.h
diff --git a/drivers/media/dvb/frontends/bsp_i2c.h
b/drivers/media/dvb/frontends/bsp_i2c.h
new file mode 100644
index 000..628c616
--- /dev/null
+++ b/drivers/media/dvb/frontends/bsp_i2c.h
@@ -0,0 +1,217 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: bsp_i2c.h,v 1.5 2009/07/07 14:20:30 justin Exp $
+*
+* \brief I2C API, implementation depends on board specifics
+*
+* This module encapsulates I2C access.In some applications several devices
+* share one I2C bus. If these devices have the same I2C address some kind
+* off "switch" must be implemented to ensure error free communication with
+* one device. In case such a "switch" is used, the device ID can be used
+* to implement control over this "switch".
+*
+*
+*/
+
+#ifndef __BSPI2C_H__
+#define __BSPI2C_H__
+/*--
+INCLUDES
+--*/
+#include "bsp_types.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+/*--
+TYPEDEFS
+--*/
+/**
+* \typedef I2Caddr_t
+* \brief I2C device address (7-bit or 10-bit)
+*/
+typedef u16_t I2Caddr_t;
+
+/**
+* \typedef I2CdevId_t
+* \brief Device identifier.
+*
+* The device ID can be useful if several devices share an I2C address,
+* or if multiple I2C busses are used.
+* It can be used to control a "switch" selecting the correct device and/or
+* I2C bus.
+*
+*/
+typedef u16_t I2CdevId_t;
+
+/**
+* \struct _I2CDeviceAddr_t
+* \brief I2C device parameters.
+*
+* This structure contains the I2C address, the device ID and a userData
pointer.
+* The userData pointer can be used for application specific purposes.
+*
+*/
+struct _I2CDeviceAddr_t {
+ I2Caddr_t i2cAddr;/**< The I2C address of the device. */
+ I2CdevId_t i2cDevId; /**< The device identifier. */
+ void*userData; /**< User data pointer */
+};
+
+/**
+* \typedef I2CDeviceAddr_t
+* \brief I2C device parameters.
+*
+* This structure contains the I2C address and the device ID.
+*
+*/
+typedef struct _I2CDeviceAddr_t I2CDeviceAddr_t;
+
+/**
+* \typedef pI2CDeviceAddr_t
+* \brief Pointer to I2C device parameters.
+*/
+typedef I2CDeviceAddr_t *pI2CDeviceAddr_t;
+
+/*--
+DEFINES
+--*/
+
+/*--
+MACROS
+--*/
+
+/**
+* \def IS_I2C_10BIT(addr)
+* \brief Determine if I2C address 'addr' is a 10 bits address or not.
+* \param addr The I2C address.
+* \return int.
+* \retval 0 if address is not a 10 bits I2C address.
+* \retval 1 if address is a 10 bits I2C address.
+*/
+#define IS_I2C_10BIT(addr) \
+(((addr) & 0xF8) == 0xF0)
+
+/*--
+ENUM
+-
[PATCH 01/25] added PCTV80e information to cardlist file
--- Documentation/video4linux/CARDLIST.em28xx |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index d8c8544..319a9b2 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -78,3 +78,4 @@ 78 -> PCTV nanoStick T2 290e (em28174) 79 -> Terratec Cinergy H5 (em2884) [0ccd:0043,0ccd:10a2] 80 -> PCTV DVB-S2 Stick (460e) (em28174) +81 -> Pinnacle PCTV HD Mini(em2874)[2304:023f] -- 1.7.5.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
[PATCH 02/25] added bsp_host for pctv80e support
---
drivers/media/dvb/frontends/bsp_host.h | 80
1 files changed, 80 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/bsp_host.h
diff --git a/drivers/media/dvb/frontends/bsp_host.h
b/drivers/media/dvb/frontends/bsp_host.h
new file mode 100644
index 000..75a5f7b
--- /dev/null
+++ b/drivers/media/dvb/frontends/bsp_host.h
@@ -0,0 +1,80 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: bsp_host.h,v 1.3 2009/07/07 14:20:30 justin Exp $
+*
+* \brief Host and OS dependent type definitions, macro's and functions
+*
+*/
+
+#ifndef __DRXBSP_HOST_H__
+#define __DRXBSP_HOST_H__
+/*-
+INCLUDES
+-*/
+#include "bsp_types.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*-
+TYPEDEFS
+-*/
+
+
+/*-
+DEFINES
+-*/
+
+/*-
+Exported FUNCTIONS
+-*/
+DRXStatus_t DRXBSP_HST_Init(void);
+
+DRXStatus_t DRXBSP_HST_Term(void);
+
+void* DRXBSP_HST_Memcpy(void *to, void *from, u32_t n);
+
+int DRXBSP_HST_Memcmp(void *s1, void *s2, u32_t n);
+
+u32_t DRXBSP_HST_Clock(void);
+
+DRXStatus_t DRXBSP_HST_Sleep(u32_t n);
+
+/*-
+THE END
+-*/
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __DRXBSP_HOST_H__ */
--
1.7.5.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
[PATCH 00/25] Add PCTV-80e Support to v4l
These are the files required to support the Pinnacle PCTV-80e USB Tuner in video-4-linux. The files were originally downloaded from http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-80e and modified to fix compilation errors and also to move the driver files from the drx39xy subdirectory to the frontends directory. There are still coding style errors (mainly trailing whitespace and DOS Line Endings, but some other style errors exist as well). I have successfully compiled and installed this under the 3.0.x kernel, but haven't tried under any later kernels. Patrick Dickey (25): added PCTV80e information to cardlist file added bsp_host for pctv80e support added bsp_i2c for pctv80e support added bsp_tuner for pctv80e support added bsp_types for pctv80e support added drx39xxj for pctv80e support added drx39xxj header for pctv80e support added drx39_dummy for pctv80e support added drx_dap_fasi for pctv80e support added drx_dap_fasi header for pctv80e support added drx_driver for pctv80e support added drx_driver header for pctv80e support added drx_driver_version header for pctv80e support added drxj for pctv80e support added drxj header for pctv80e support added drxj_map header for pctv80e support added drxj_mc header for pctv80e support added drxj_mc_vsb header for pctv80e support added drxj_mc_vsbqam header for pctv80e support added drxj_options header for pctv80e support modified Kconfig to include pctv80e support modified Makefile for pctv80e support modified em28xx-cards for pctv80e support modified em28xx-dvb for pctv80e support modified em28xx header for pctv80e support Documentation/video4linux/CARDLIST.em28xx|1 + drivers/media/dvb/frontends/Kconfig |8 + drivers/media/dvb/frontends/Makefile |2 + drivers/media/dvb/frontends/bsp_host.h | 80 + drivers/media/dvb/frontends/bsp_i2c.h| 217 + drivers/media/dvb/frontends/bsp_tuner.h | 215 + drivers/media/dvb/frontends/bsp_types.h | 229 + drivers/media/dvb/frontends/drx39xxj.c | 464 + drivers/media/dvb/frontends/drx39xxj.h | 40 + drivers/media/dvb/frontends/drx39xxj_dummy.c | 135 + drivers/media/dvb/frontends/drx_dap_fasi.c | 670 + drivers/media/dvb/frontends/drx_dap_fasi.h | 268 + drivers/media/dvb/frontends/drx_driver.c | 1504 +++ drivers/media/dvb/frontends/drx_driver.h | 2588 drivers/media/dvb/frontends/drx_driver_version.h | 82 + drivers/media/dvb/frontends/drxj.c |15732 ++ drivers/media/dvb/frontends/drxj.h | 990 ++ drivers/media/dvb/frontends/drxj_map.h |15359 + drivers/media/dvb/frontends/drxj_mc.h| 3939 ++ drivers/media/dvb/frontends/drxj_mc_vsb.h| 744 + drivers/media/dvb/frontends/drxj_mc_vsbqam.h | 1437 ++ drivers/media/dvb/frontends/drxj_options.h | 65 + drivers/media/video/em28xx/em28xx-cards.c| 20 + drivers/media/video/em28xx/em28xx-dvb.c | 25 + drivers/media/video/em28xx/em28xx.h |1 + 25 files changed, 44815 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/frontends/bsp_host.h create mode 100644 drivers/media/dvb/frontends/bsp_i2c.h create mode 100644 drivers/media/dvb/frontends/bsp_tuner.h create mode 100644 drivers/media/dvb/frontends/bsp_types.h create mode 100644 drivers/media/dvb/frontends/drx39xxj.c create mode 100644 drivers/media/dvb/frontends/drx39xxj.h create mode 100644 drivers/media/dvb/frontends/drx39xxj_dummy.c create mode 100644 drivers/media/dvb/frontends/drx_dap_fasi.c create mode 100644 drivers/media/dvb/frontends/drx_dap_fasi.h create mode 100644 drivers/media/dvb/frontends/drx_driver.c create mode 100644 drivers/media/dvb/frontends/drx_driver.h create mode 100644 drivers/media/dvb/frontends/drx_driver_version.h create mode 100644 drivers/media/dvb/frontends/drxj.c create mode 100644 drivers/media/dvb/frontends/drxj.h create mode 100644 drivers/media/dvb/frontends/drxj_map.h create mode 100644 drivers/media/dvb/frontends/drxj_mc.h create mode 100644 drivers/media/dvb/frontends/drxj_mc_vsb.h create mode 100644 drivers/media/dvb/frontends/drxj_mc_vsbqam.h create mode 100644 drivers/media/dvb/frontends/drxj_options.h -- 1.7.5.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: [GIT PULL for 3.2-rc1] media updates part 2
On 11/07/2011 06:25 AM, Mauro Carvalho Chehab wrote: > Em 04-11-2011 11:22, Antti Palosaari escreveu: >> Mauro, >> >> Could you still try PULL some rather small Anysee changes for 3.2 I have >> requested two weeks ago? >> http://patchwork.linuxtv.org/patch/8182/ >> >> Those are Common Interface support and new board layout for Anysee E7 T2C. > > Sorry, but it is very likely to merge them for 3.3. I doubt that we still > would have time > to push this into -next and merge upstream. > > Regards, > Mauro >> Hi Mauro, For those of us who are new to the project, how soon can we expect you to create the remote for 3.3 (/staging_for_v3.3, I'm guessing the name will be)? A ballpark timeframe (rough guess, in other words) is fine since a lot will depend on when the 3.2 kernel will be released, I'd guess. Thanks, and have a great day:) Patrick. -- 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: Adding PCTV80e support to linuxtv.
On 11/03/2011 01:01 PM, semiRocket wrote: > On Wed, 02 Nov 2011 23:10:23 +0100, Patrick Dickey > wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 11/02/2011 01:44 PM, semiRocket wrote: >>> On Wed, 26 Oct 2011 02:10:56 +0200, Patrick Dickey >>> wrote: >>> >>>> Hello everyone, >>>> >>>> Since my repository isn't under the linuxtv.org banner, I'm not >>>> sure how to create an actual patch or pull request for the code. >>>> It needs some cleanup work, but essentially the code works (for >>>> the ATSC portion, but possibly not the QAM portion). >>>> >>>> The repository is located at >>>> https://github.com/patrickdickey52761/PCTV80e >>>> >>>> so I'd imagine that either git clone >>>> git://github.com/patrickdickey52761/PCTV80e or git remote add >>>> git://github.com/patrickdickey52761/PCTV80e will pull the code in >>>> for you (it's a public repository). >>>> >>>> If this doesn't work, I'm asking for assistance in getting the >>>> code into a repository that can be pulled in (or assistance in >>>> how to prepare a patch/pull request from my current repository). >>>> >>>> If this does work, then I'm asking for assistance in cleanup of >>>> the code--and specifics on what I need to do to clean up the code >>>> (breaking lines up into fewer than 80 columns, whitespace, etc). >>>> One thing to note is that I haven't removed the trailing >>>> whitespace from the drxj_map.h file, as it was an automatically >>>> generated file. I wasn't sure what implications could arise from >>>> altering the file. >>>> >>>> Thank you, and have a great day:) Patrick. >>> >>> Hi, >>> >>> I'm not a developer, but I have some basic understanding how v4l >>> patching works. >>> >>> You don't have to have a repository online, you can simply submit >>> patches from your local tree using git or hg or even diff tools. >>> Patches should come from newer trees (preferably current >>> development tree) so they could apply cleanly. >>> >>> Please read the following links and see if they could help: >>> http://linuxtv.org/wiki/index.php/Developer_Section >>> http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches >>> >>> >>> >> >> Thanks for the reply. I've looked through most of the links on those >> pages, and am almost ready to send the patches. The main problem that >> I have is that even after rebasing my branch (per the instruction on >> the media_git.git page), when I do a format patch there are 350+ >> patches generated (all but the last 29 are from other submitters). >> >> So, I either have to wait for all of those other patches to be added >> to the master repository, or I need to figure out how to isolate my >> specific patches from the list (so I can send them). >> >> If you've got any suggestions on that, I'd greatly appreciate it. I'm >> more new to git than anything else--as most of my programming was in >> classes, and they don't teach this stuff there. >> >> Have a great day:) >> Patrick. > > > Hello, > > don't know the answer, so I am adding list back. > > Maybe someone else would know how to synchronize your old tree against > current development tree (except by manually cut/paste). Just for clarification. When I run git format-patch, it creates 379 patches (the 354 that are already in the repository, and my 25). I tried running the git rebase line from the http://git.linuxtv.org/media_build.git page, but it didn't do anything (unless I need to run it after generating the other 354 patches). So, my questions are: 1. Do I need to rebase after generating the patches that everyone else has submitted, in order to not have 300+ patches that don't apply to my portion? 2. How can I isolate my own patches, if #1 is no (or if it doesn't work, and I still get 300+ patches)? Most importantly: Should I just wait until Mauro creates the staginng-for-v3-3 branch, as he's already pulling in for the merge window? Have a great day:) Patrick. -- 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
Adding PCTV80e support to linuxtv.
Hello everyone, Since my repository isn't under the linuxtv.org banner, I'm not sure how to create an actual patch or pull request for the code. It needs some cleanup work, but essentially the code works (for the ATSC portion, but possibly not the QAM portion). The repository is located at https://github.com/patrickdickey52761/PCTV80e so I'd imagine that either git clone git://github.com/patrickdickey52761/PCTV80e or git remote add git://github.com/patrickdickey52761/PCTV80e will pull the code in for you (it's a public repository). If this doesn't work, I'm asking for assistance in getting the code into a repository that can be pulled in (or assistance in how to prepare a patch/pull request from my current repository). If this does work, then I'm asking for assistance in cleanup of the code--and specifics on what I need to do to clean up the code (breaking lines up into fewer than 80 columns, whitespace, etc). One thing to note is that I haven't removed the trailing whitespace from the drxj_map.h file, as it was an automatically generated file. I wasn't sure what implications could arise from altering the file. Thank you, and have a great day:) Patrick. -- 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: Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup
Thank you for the suggestions (both of you). I'll submit a pull request by this weekend (as I want to test it again in Ubuntu 11.10 just to make sure everything works). And for Mauro, is there a direct link to the scripts? I looked for them after the last time I emailed, but couldn't find them (or I wasn't looking in the right place). Have a great day:) Patrick. On 10/19/2011 10:44 PM, Mauro Carvalho Chehab wrote: > Em 19-10-2011 11:57, Devin Heitmueller escreveu: >> Hi Patrick, >> >> On Wed, Oct 19, 2011 at 8:36 AM, Patrick Dickey >> wrote: >>> I'm posting this question under this thread because the subject pertains >>> to the question (in that I'm asking about staging and about the PCTV 80e >>> drivers). >> >> You should definitely be looking at the "as102" thread that is >> currently going on this mailing list. Piotr is actually going through >> the same process as you are (he is working on upstreaming the as102 >> driver from a kernellabs.com tree). He made some pretty common >> mistakes (all perfectly understandable), and your reading the thread >> might help you avoid them (and having to redo your patch series). >> >>> I started cleaning up the drx39xx* drivers for the PCTV-80e and have >>> them in a github repository. Ultimately I want to send a pull request, >>> so other people can finish the cleaning (as I'm not comfortable with >>> pulling out the #ifdef statements myself). >> >> You should definitely ask Mauro how he expects to do a staging driver >> for a demodulator before you do any further work. The staging tree >> works well for bridge drivers, but demod drivers such as the drx >> require code in the bridge driver (the em28xx in this case), so it's >> not clear how you would do staging for a product where the bridge >> driver isn't in staging as well. The answer to that question will >> likely guide you in how to get the driver into staging. > > Ah yes, good point. Well, just submit it as if it should be added at > the right place, but putting the Kconfig changes in separate. If this > driver is not that different than the other drx drivers, I may try to > find some time to fix it on the same way. > > You may also take a look at the history for the drx-k merging patches. > I basically wrote a few small perl scripts to correct coding style, and > a few manual work. > >> >> If you have specific questions regarding anything you see in the >> driver, let me know. I don't have much time nowadays but will find >> the time if you ask concise questions. >> >> Good luck. It will be great to finally see this merged upstream. >> >> Devin >> > -- 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
Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup
I'm posting this question under this thread because the subject pertains to the question (in that I'm asking about staging and about the PCTV 80e drivers). I started cleaning up the drx39xx* drivers for the PCTV-80e and have them in a github repository. Ultimately I want to send a pull request, so other people can finish the cleaning (as I'm not comfortable with pulling out the #ifdef statements myself). So my questions are these: 1. If I move the drx39xx* and associated files into the staging directory (staging/media/dvb/frontends to be exact), do I simply need to point to staging/filename for any #include statements (specifically in the em28xx-dvb.c and em28xx-cards.c files), or do I need to do something else? 2. In the Makefile for the frontends, I have the commands to make the drivers for the drx39xx* files. Do I need to point those to the staging/ directory as well, or do I need to create Makefiles in that directory for these files? I ask this because on my system, I wasn't able to "make" the files when they were in a subdirectory of frontends. I actually had to move them to the frontends directory and transfer the commands from the Makefile in the subdirectory to the frontends Makefile. 3. If I submit a pull request as is right now (where these files will go into the linux/drivers/media/dvb/frontends directory and the em28xx-* files will point to those files), will they be pulled in, and someone will help me to get them in the right places? Or do I need to move them to staging, reconfigure everything, and then submit the pull request? Thank you for any help and information, and have a great day:) Patrick. On 10/17/2011 05:31 PM, Greg KH wrote: > On Sat, Oct 15, 2011 at 10:54:14PM +0200, Piotr Chmura wrote: >> [PATCH 1/7] pull as102 driver >> fromhttp://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/ >> with the only change needed to compile it in git tree[1]: usb_buffer_alloc() >> to usb_alloc_coherent() and usb_buffer_free() to usb_free_coherent() >> >> [PATCH 2/7] as102: add new device nBox DVB-T Dongle >> adds new device working on this driver >> >> >> Next patches i made basing on Mauro Carvalho Chehab comments from previous >> pull try [2]. >> >> [PATCH 3/7] as102: cleanup - get rid off typedefs >> [PATCH 4/7] as102: cleanup - formatting code >> [PATCH 5/7] as102: cleanup - set __attribute__(packed) instead of >> pragma(pack) >> [PATCH 6/7] as102: cleanup - delete vim comments >> [PATCH 7/7] as102: cleanup - get rid of unnecessary defines (WIN32, LINUX) > > Mauro, care to take these and move them under your newly-created > drivers/staging/media/ directory? > > thanks, > > greg k-h -- 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: Cannot configure second Kodicom 4400R
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there Allan, I'm not familiar with the card (so you'll want to defer to someone else if their answer differs from mine). It looks like video0 and video1 are assigned to the first card, and video2 and video3 are assigned to the second card. So, you might want to try xawtv -d /dev/video2' or xawtv -d /dev/video3 and see if one of those uses the second card (you could try video4 or video5 also, since they're assigned to cards). Have a great day:) Patrick. On 10/10/2011 01:45 PM, Allan Macdonald wrote: > Hi to all, > > I am new to this list. > > I have been successfully using a Kodicom 4400R with zoneminder but I > wanted to expand so I bought a second card and installed it. The > problem with this card is that I cannot seem to be able to get the > second card to work. I tried using xawtv with the following command: > > xawtv -d /dev/video1 > > The result is that I get images from /dev/video0 > > I also tried: > > xawtv -d /dev/video4 > > with the same result. > > I obviously don't understand what's going on. > > I tried following the instructions here, to no avail: > > http://www.zoneminder.com/wiki/index.php/Kodicom_4400r > > I also looked here: > > http://linuxtv.org/wiki/index.php/Kodicom_4400R > > but, unfortunately, the following page does not explain what happens > with more than one card installed. > > Here's my bttv.conf: > > [code] > options bttv gbuffers=32 card=133,132,133,133,133,132,133,133 tuner=4 > chroma_agc=1 > [/code] > > I have attached a dmesg output and an lsmod output. > > I would greatly appreciate some help. Many thanks in advance. > > Regards, > > Allan Macdonald -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6TUuUACgkQMp6rvjb3CAT9VwCfTyqoIrlUS+IszJIQWpyYD7j9 NlsAnRFpxHKQT+p7Hem+D2SpUWiDkxu2 =l16i -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems cloning the git repostories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I ran into that issue yesterday, but figured that I'd caused enough of a headache asking about the problems already--so I decided to wait and see if it was fixed this morning. Thank you (even though I didn't report the issue), and have a great day:) Patrick. On 09/25/2011 09:56 PM, Mauro Carvalho Chehab wrote: > Em 25-09-2011 15:03, Johannes Stezenbach escreveu: >> On Sun, Sep 25, 2011 at 07:33:57AM -0500, Patrick Dickey wrote: >>> >>> I tried to follow the steps for cloning both the "media_tree.git" and >>> "media_build.git" repositories, and received errors for both. The >>> media_tree repository failed on the first line >>> >>>> git clone >>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >>>> v4l-dvb >>> >>> which I'm assuming is because kernel.org is down. >>> >>> The media_build.git repository fails on the first line also >>> >>>> git clone git://linuxtv.org/media_build.git >>> >>> with a fatal: read error: Connection reset by peer. >> >> The git error should be fixed now. >> >> But please don't clone from linuxtv.org, intead use >> git clone git://github.com/torvalds/linux.git >> and then add linuxtv to your repo like described on >> http://git.linuxtv.org/media_tree.git > > I've updated the instructions together with the git tree to point to the > github tree. > > Btw, the media_build had an issue due to the move of tm6000 and altera-stapl > out of staging. I've fixed it. At least here with 3.0 kernel, everything > is compiling fine. > > Cheers, > Mauro >> >> >> Johannes >> -- >> 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6AYZ0ACgkQMp6rvjb3CAQj1QCffarBsYJw3Dx8sowrXF0i0gnF tugAoKBFVFcRcX8jHyQM1vMKpX3qz6Ks =GGGa -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problems cloning the git repostories
Hello there, I tried to follow the steps for cloning both the "media_tree.git" and "media_build.git" repositories, and received errors for both. The media_tree repository failed on the first line > git clone > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb which I'm assuming is because kernel.org is down. The media_build.git repository fails on the first line also > git clone git://linuxtv.org/media_build.git with a fatal: read error: Connection reset by peer. Is it possible to clone either (or both) repositories at this time, or are they down? And in the absence of cloning the kernel for the media_tree.git repository, is it possible to simply clone the git://linuxtv.org/media_tree.git repository and work from that? My interest in this is to install some patches created by Devin Heitmueller for the Pinnacle PCTV 80e USB tuner (at least the ATSC portion of the tuner). Once I'm able to determine exactly what changes are made, I would like to either submit the patches to the repository, or send them to someone who has more experience in patching the files for submission. One other question (totally unrelated to this post though): When I send emails, normally they are GPG signed. Should I disable that for this list, or is it acceptable? Thank you for any information, and have a great day:) Patrick. -- 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
