Re: Upstreaming SAA716x driver to the media_tree
On Wed, Jan 8, 2014 at 1:42 AM, CrazyCat crazyca...@narod.ru wrote: Konstantin Dimitrov пишет: so, i was waiting Manu to upstream his SAA716x driver code some day and then submit the improvements i made to it. yet again you're trying to take that from me and again, conveniently you included many people on CC, but not me. it's ok :) and stop compile binary blobs for TBS :) like 'stupid' binaries for LNB power control and init for 6925/5925 :) do you really believe that's mine decision to direct that to me?! what you're asking is not my decision to make. in my opinion what you're doing is not right, because that patch is not clean-room reverse-engineering, you just took those changes from another open-source base and if nothing else it's at least common courtesy in open-source community when you didn't make them to not submit them as your patches. this is open-source world :) no, it's not open-source world to take code that someone else made and say it's yours i also think with your actions you're actually hurting the community, because people like me, that do actually have the technical understanding and can help and contribute further improvements are driven away from the community, because effectively the community accepting behavior like yours is encouraging code stealing!! what stealed code ??? :) if you want write closed-source drivers for windose - make it ! :) i'm not discussing any closed source work here - i'm talking about patches made to code that is licensed under GPL. -- 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: Upstreaming SAA716x driver to the media_tree
Luis, yes, here we're or more exactly you're again, because it's clear now you have the exact same patterns - i told you already - one time any excuse may fly, when it's a pattern it's a whole new story. so, excuses like this one: http://www.spinics.net/lists/linux-media/msg65889.html and the points you're making now are more than hollow. any reasonable man can see your I2C patch - there is many ways to do it, but somehow magically and by coincidence you again do them exactly like i did it - what i mean - when it's for specific board for example you may choose to add another case in the switch statement instead do it for all boards - of course, that's the case if you do it by yourself and not copy. so, it's public discussion, i have nothing to say to you in private, in fact everything i want to say to you is in public. i see no anything offensive in that someone that have full rights to do that step in and point out when there is something that is not right. if you take it as offensive that's your problem - in fact what you're doing is offensive, not that i care so much to take it that way. after all the discussion is public - everyone can form their own opinion. as far as if my email is empty - i can say the exact same for your work on SAA716x - that's work done mainly by Manu, Andreas and me - actually after Manu left it - i and Andreas obviously span the Manu code and went different ways from there. what i can claim full credit is I2C patches (need for certain TBS boards only) and saa716x_input.[c|h] - all of them GPL work - once again everyone can check the copyright notice of saa716x_input.[c|h] and that same code base contains the I2C patches and it's years old. so, when you finally make some code that is really yours and actually making code is easy comparing to understand how the silicone works and fix problems, you're free to take credit for it. until now i see only either you're taking open-source code that's not yours or do reverse-engineering of blobs that otherwise it's not easy to make and develop from scratch. at least the last action is totally legit, contrary to the first one which is simply unethical, especially in open-source. --konstantin On Tue, Jan 7, 2014 at 10:23 PM, Luis Alves lja...@gmail.com wrote: Hi Konstantin, (here we go again...) What the hell are you talking about? I didn't submit any I2C patch. This email is just about Manu sending his SAA716x driver to the media_tree. And where do you see any saa716x_input.[c|h] in my repo? Anyway, since you asked I took some pics: https://plus.google.com/photos/105602732859464871628/albums/5966247612074668305?authkey=CN3jl9mWhrDhQg (SDA_HOLD setting in the comment) For SDA_HOLD = 0x19 the next clock rising edge is really close to the data line release. Even 0x14 is too close, so I will use a smaller value so maybe 0x10 is fine for the 400kHZ clk speed. And I do have a TBS card that doesn't work with Manu default setting (0x19). Your email besides being offending, is empty. If someone's actions hurt the community are your own. Not going to enter in personal discussions in here nor going to waist time answering to anymore of your offending emails. If you want to exchange some thoughts, mail me personally. Regards, Luis On Tue, Jan 7, 2014 at 5:31 PM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: Luis, can you explain to us all here how exactly you came up to those particular I2C fixes: https://github.com/ljalves/linux_media/commit/be7cd1ff82cc20578b805ad508d089f818ae726d because essentially they are the same as what i did years ago - included as source code in drivers i made for some TBS cards (source code is available all over online) or we just have the exact same case with you as before: http://www.spinics.net/lists/linux-media/msg65888.html http://www.spinics.net/lists/linux-media/msg65889.html and you're continue to taking credit for patches i made or basically stealing them. if they were some trivial patches i won't mind, but even they are small, they are nothing like trivial. so, i believe you will have really hard time to explain your I2C fixes, because for example the SDA hold time value of 0x14 is needed for only one particular SAA716x-based card (other such cards can work with wide range of SDA hold time settings) and i'm sure you don't know that card and cannot cite its model or any technical details why that's needed, because you don't have it, as well it takes quite an effort and good knowledge of I2C signaling with oscilloscope to figure out that value, as well that exactly that value needs changing. why you didn't use for example 0x16 or 0x13 for SDA hold time in your I2C patch?! so, one time, like the previous time, excuse that you just didn't know who the author of that work is may fly, but second time, especially considering that the SAA716x code base from which i'm sure you took (not to use stole) those settings contains my name
Re: Upstreaming SAA716x driver to the media_tree
Luis, can you explain to us all here how exactly you came up to those particular I2C fixes: https://github.com/ljalves/linux_media/commit/be7cd1ff82cc20578b805ad508d089f818ae726d because essentially they are the same as what i did years ago - included as source code in drivers i made for some TBS cards (source code is available all over online) or we just have the exact same case with you as before: http://www.spinics.net/lists/linux-media/msg65888.html http://www.spinics.net/lists/linux-media/msg65889.html and you're continue to taking credit for patches i made or basically stealing them. if they were some trivial patches i won't mind, but even they are small, they are nothing like trivial. so, i believe you will have really hard time to explain your I2C fixes, because for example the SDA hold time value of 0x14 is needed for only one particular SAA716x-based card (other such cards can work with wide range of SDA hold time settings) and i'm sure you don't know that card and cannot cite its model or any technical details why that's needed, because you don't have it, as well it takes quite an effort and good knowledge of I2C signaling with oscilloscope to figure out that value, as well that exactly that value needs changing. why you didn't use for example 0x16 or 0x13 for SDA hold time in your I2C patch?! so, one time, like the previous time, excuse that you just didn't know who the author of that work is may fly, but second time, especially considering that the SAA716x code base from which i'm sure you took (not to use stole) those settings contains my name as copyright, because i actually added to that code base new code i developed from scratch like for example saa716x_input.[c|h], is another thing you cannot explain. so, i was waiting Manu to upstream his SAA716x driver code some day and then submit the improvements i made to it. yet again you're trying to take that from me and again, conveniently you included many people on CC, but not me. in my opinion what you're doing is not right, because that patch is not clean-room reverse-engineering, you just took those changes from another open-source base and if nothing else it's at least common courtesy in open-source community when you didn't make them to not submit them as your patches. i also think with your actions you're actually hurting the community, because people like me, that do actually have the technical understanding and can help and contribute further improvements are driven away from the community, because effectively the community accepting behavior like yours is encouraging code stealing!! --konstantin On Tue, Jan 7, 2014 at 6:33 PM, Luis Alves lja...@gmail.com wrote: HI Andreas, My initial commit is based on: http://powarman.dyndns.org/hgwebdir.cgi/v4l-dvb-saa716x/ (I think it's your repo with some commits from Soeren Moch) The difference to my working area is that I have the driver placed in drivers/media/pci/saa716x (instead of drivers/media/common/saa716x) and everything is rebased on the latest media_tree. On top of that I just have 2 commits: one to be able to build FF cards and another to fix some i2c issues. You can check my repo here: https://github.com/ljalves/linux_media/commits/saa716x Regards, Luis On Tue, Jan 7, 2014 at 4:12 PM, Andreas Regel andreas.re...@gmx.de wrote: Hi Luis, Am 07.01.2014 12:58, schrieb Luis Alves: Hi, I'm finishing a new frontend driver for one of my dvb cards, but the pcie bridge uses the (cursed) saa716x. As far as I know the progress to upstream Manu's driver to the media_tree has stalled. In CC I've placed some of the people that I found working on it lately, supporting a few dvb cards. It would be good if we could gather everything in one place and send a few patchs to get this upstreamed for once... Manu, do you see any inconvenience in sending your driver to the linux_media tree? I'm available to place some effort on this task. which repository of the saa761x is your work based on? Regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
hi Hans, On Mon, Aug 19, 2013 at 10:47 PM, Hans Petter Selasky h...@bitfrost.no wrote: On 08/18/13 21:02, Steven Toth wrote: FYI: The Si2168 driver is available from dvbsky-linux-3.9-hps-v2.diff inside. Maybe the Si2165 is similar? Excellent. Hi Guys, I was contacted by someone claiming to be from RSD ??, named Danny Griegs, off-list, claiming I have the source code for sit2.c and cannot distribute it. there is www.rsd.de, which is abbreviation for rohde-schwarz-something and to where that side is actually redirecting. so, they are German-based company making DVB equipment and maybe if that's the same RSD that Danny Griegs guy could be legit. however, nothing in the binary you used proves they have any ownership over the binary or the code compiled in it. so, you can ask them to show you their NDA with Silicon Labs - after all they can't have access to that information in the code without valid NDA with Silicon Labs. I want to make clear to everyone that the tarball I've provided only contains the C-equivalent of the objdump -dx output from the media_build-bst/v4l/sit2.o.x86 which is distributed officially by DVBSKY. so, there is no any guarantee that the code Max Nibble packed in that binary is really his creation - he had a history of copy-left practices - for example some time ago he tried to change the copyright notice of code i released under GPL: http://www.mail-archive.com/linux-media@vger.kernel.org/msg41135.html as its main architecture was based on 'cx24116.c' made by Steven Toth and others, even the work of 'ds3000' demodulator is quite different and i made a lot of changes in the code leaving almost no resemblance with 'cx24116.c'. so, if you search the list there are few discussions about 'ds3000', which i made and what Max Nibble did with it. also, Max Nibble is most likely not his real name - those DVBsky-brand products are made by Chinese company with the notorious name of BestTunar (yes, i didn't make spelling error here). in any case that's issue between RSD/Danny Griegs and Max Nibble, not between you and them. also, you can check the originating IP of the email from RSD/Danny Griegs and ensure it's not some of the many personalities of Max Nibble - he writes from IP addresses located at Shenzhen, China. He claimed I had to pull the tarball off my site right away or face legal actions. I cannot understand this, and would like to ask you guys what you think. Obviously my sit2.c is too similar to their licensed sit2.c. And now these guys want to send a lawyer after me. What a mess. Should I laugh or cry. Any advice from you guys about this? BTW: The hexdump of the sit2.o.x86 contains the string license=GPL. Does that give me any rights to redistribute the re-assembled C-code ? i'm not an intellectual property lawyer, but what you did is at least honest, i mean add notice: Max Nibble wrote the initial code, but only released it in binary form. Assembly to C conversion done by HP Selasky. and as far as you can tell the license of the code in the binary module is GPL, because recently similar as what you did with that driver happened with close-source driver made by me - that driver included both open-source patches to GPL code and thus GPL and not open-source module - all the code for it was submitted as several patches to V4L and the submitter when i confronted: http://www.spinics.net/lists/linux-media/msg65888.html just said - i didn't know you made that: http://www.spinics.net/lists/linux-media/msg65889.html how convenient even thought 'modinfo' of the not-open-source module of the initial driver lists the license as not-GPL and my name and email as author and thus all changes that are made as part of that driver are clearly why and who made them. anyway, i just move one, because it seems even open-source community like V4L is no longer supportive of the real authorship and don't care the things to be open-sourced in some proper way, which is damaging for the community if you ask me. so, as i mentioned on one of the links above, i don't see anything wrong with clean-room reverse-engineering, even if that includes disassembling of some binary as you did (a lot of open-source drivers are made that way, when there is no publicly available datasheets), as far as that is mentioned as note, which you did - i mean if you have full understanding of the driver work then it's fine and you can even maintain it and make no any notes, but otherwise it's just a bunch of magic numbers that are reversed from the binary and nothing more, i.e. you can't maintain and extent its functionality beyond what's in the binary and totally ignore and give no credit to the one that made the binary - let's say some of the chip initialization values needs to be changed due to a bug. so, in the last case i guess that has more negative impact than it helps, because even like my case that NDAs are preventing the driver to become open-source that doesn't mean at some point it
Re: [PATCH] cx23885: Fix interrupt storm that happens in some cards when IR is enabled.
On Thu, Jul 18, 2013 at 4:33 AM, Luis Alves lja...@gmail.com wrote:
Signed-off-by: Luis Alves lja...@gmail.com
---
drivers/media/pci/cx23885/cx23885-cards.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 7e923f8..89ce132 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -1081,6 +1081,27 @@ int cx23885_tuner_callback(void *priv, int component,
int command, int arg)
return 0;
}
+void cx23885_ir_setup(struct cx23885_dev *dev)
+{
+ struct i2c_msg msg;
+ char buffer[2];
+
+ /* this should stop the IR interrupt
+ storm that happens in some cards */
+ msg.addr = 0x4c;
+ msg.flags = 0;
+ msg.len = 2;
+ msg.buf = buffer;
+
+ buffer[0] = 0x1f;
+ buffer[1] = 0x80;
+ i2c_transfer(dev-i2c_bus[2].i2c_adap, msg, 1);
+
+ buffer[0] = 0x23;
+ buffer[1] = 0x80;
+ i2c_transfer(dev-i2c_bus[2].i2c_adap, msg, 1);
+}
+
hi All,
i didn't want to interfere thus far for that series of related
patches, but because it starts to become a little ridiculous -
actually that's what happens when you copypaste someone else's work
without having any understanding how and why that code (even very
simple as code) was invented (but it's not that simple to invent it
though) - in this particular case - that same code you can track back
to several years ago when drivers for TBS 698x cards was released by
me. so, for whatever reason that code wasn't up-streamed by me - lack
of time, NDAs, etc. and i don't mind that be up-streamed by someone
who wants to do it (after all it was released under GPL as patch to
GPL code), what i find as highly inappropriate when the author of the
code is perfectly known and it's known to who submit the above patch,
at least as a courtesy, if you wish, the original author of the code
to be included to CC - what about if i'm not subscribed to linux-media
or even if i missed to spot the email as part of linux-media and i as
the one who mind it have something in mind. so, i must say that i
totally agree with questions and concerns Devin Heitmueller
dheitmuel...@kernellabs.com raised in regards to that code - when
it's highly specific to particular design and who submit it doesn't
really know what it does and those you know are not allow to say, it's
just increase the risk to pollute the mainline drivers rather then
improve them and that's why it needs at least to be put in right place
- not affect boards for which it's not intended. also, i think when
what that code does is not clear it should be a comment from where it
comes and the same if it wasn't open-source, but made with clean-room
reverse-engineering - that again should be mentioned, because it
implies you don't understand, at least fully, the work and you can't
really maintain what you submit as patches in case of problems.
best regards,
konstantin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
hi Anton, it's very debatable that is fault of the Linux driver(s) and let me elaborate why i think so: i have Logitech Harmony 890 remote and MCE USB IR receiver that is supported by 'mceusb.c' in Linux, i.e. it's different than your IR receiver, but yet the work is very unstable together with my Harmony no matter what type of pulses are used, e.g. RC5, RC6 or NEC. however, that is true only if default setting for the Harmony are set in the Logitech software for Windows that i used to initially setup the remote. so, if in Logitech Harmony Remote Software (7.7.0) for Windows go to: Devices - Settings - select 'Troubleshoot' - click 'Next' - select '...responds to some commands either too many times or only occasionally' - click 'Next' then you're given the option to choose number from 0 to 5 with the following explanation by Logitech: If your device responds too slowly, or not at all when you press a button on the remote, increase the value to 4 or 5. If your device responds too quickly, lower the value to 2, 1 or 0. there are no any details about what actually that setting is doing to the Harmony firmware and in fact i found that neither the default value, nor Logitech suggestion what value to choose in which case are good, but using value of 2 fixed all the issues with my MCE USB IR receiver in Linux - totally stable and proper work. in short i think the problem is created from Harmony firmware and the proper solution is to just play with those numbers in Logitech software until you find the setting with which you get stable work. of course, someone more interested than i'm in this could do further investigation and understand the root cause of the issue and what changes in how Harmony firmware behaves based on those settings Logitech offered in their software, but my point is that i have similar issue with RC5 pulses, Harmony 890 and MCE USB IR receiver that is supported by 'mceusb.c' or quite different setup than yours and the fix i found is from Logitech side and the fact Logitech offered such setting suggests that the proper way to fix it. best regards, konstantin On Thu, Jul 5, 2012 at 1:30 PM, Anton Blanchard an...@samba.org wrote: Hi David, The in-kernel RC6 decoder already has margins of around 50% for most pulse/spaces (i.e. 444us +/- 222us). Changing the sample resolution from 10 to 6 us should have little to no effect on the RC6 decoding (also, the Windows driver uses a 50us resolution IIRC). Do you have a log of a successful and unsuccesful event (the timings that is)? I had a closer look. I dumped the RC6 debug, but I also printed the raw data in the interrupt handler: printk(%x %d %d\n, irdata, rawir.pulse, rawir.duration); A successful event begins with: 7f 1 127 7f 1 127 8 1 8 db 0 91 27 1 39 b3 0 51 26 1 38 b0 0 48 ir_rc6_decode: RC6 decode started at state 0 (2620us pulse) ir_rc6_decode: RC6 decode started at state 1 (910us space) ir_rc6_decode: RC6 decode started at state 2 (390us pulse) ir_rc6_decode: RC6 decode started at state 3 (510us space) ir_rc6_decode: RC6 decode started at state 2 (66us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) 26 1 38 db 0 91 26 1 38 dd 0 93 7d 1 125--- dd 0 93 25 1 37 b4 0 52 ir_rc6_decode: RC6 decode started at state 3 (480us space) ir_rc6_decode: RC6 decode started at state 2 (36us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (910us space) ir_rc6_decode: RC6 decode started at state 2 (466us space) ir_rc6_decode: RC6 decode started at state 3 (380us pulse) ir_rc6_decode: RC6 decode started at state 4 (0us pulse) ir_rc6_decode: RC6 decode started at state 4 (930us space) ir_rc6_decode: RC6 decode started at state 5 (1250us pulse) ir_rc6_decode: RC6 decode started at state 6 (361us pulse) ir_rc6_decode: RC6 decode started at state 7 (930us space) Now compare to an unsuccesful event, in particular the byte I have tagged in both traces: 7f 1 127 7f 1 127 2 1 2 df 0 95 26 1 38 b0 0 48 26 1 38 b0 0 48 26 1 38 dc 0 92 26 1 38 ir_rc6_decode: RC6 decode started at state 0 (2560us pulse) ir_rc6_decode: RC6 decode started at state 1 (950us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (480us space) ir_rc6_decode: RC6 decode started at state 2 (36us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (480us space) ir_rc6_decode: RC6 decode started at state 2 (36us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (920us space) ir_rc6_decode: RC6 decode started at state 2 (476us space) dc 0 92 ff 0 127 de 0 94 25 1 37 b1 0 49 26 1 38 b0 0
Re: [PATCH 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
hi David, excuse me for my ignorance, but don't you think adjusting the IR receiver to universal remote control is fundamentally wrong, while the whole point of universal remote control like Logitech Harmony is to be adjusted to the IR receiver and be able to be adjusted to any IR receiver and not the other way around. so, that being said, my point is maybe the whole discussion here is just wild goose chase until those settings i mentioned in Logitech control software are not tried and there is no evidence that has already being done based on the information provided by Anton. we don't know what exactly those settings applied to Logitech Harmony firmware via Logitech control software do and it could be default pulse timings that are set trough them are just out of specification for RC6 and need to be manually refined using the Harmony firmware settings in question - once again after all universal remote control is supposed to be able to fit any IR receiver and any type of pulses and that's why provides series of different settings in order to do that - the issue seems more like misconfiguration of the universal remote control than Linux drivers problem. i'm just trying to save you time chasing not existing problems and don't mean anything else - i didn't even look at the source code you're discussing - i just have practical experience with Logitech Harmony 890 and thus i know keymaps and protocols are independently set from the proper pulse timings with Logitech control software. best regards, konstantin On Thu, Jul 5, 2012 at 5:13 PM, David Härdeman da...@hardeman.nu wrote: On Thu, 5 Jul 2012 20:30:35 +1000, Anton Blanchard an...@samba.org wrote: I had a closer look. I dumped the RC6 debug, but I also printed the raw data in the interrupt handler: printk(%x %d %d\n, irdata, rawir.pulse, rawir.duration); ... That should have been a pulse but it came out as a space. This makes me wonder if there is an issue with the run length encoding, perhaps when a pulse is the right size to just saturate it. It does seem like we set the top bit even though we should not have. It's quite weird to see a short space followed by a max space followed by a short space (0xdc 0xff 0xde). Almost like there's one or more (pulse) bytes missing in between. I've tested long pulses/spaces before and they've worked as expected (e.g. max, max, short eventsthe leading 0x7f 0x7f 0x08 sequence in your log is a good example). Now, there is a minor bug in the RLE decoding in that the duration should have 1 added to it (meaning that 0x00 or 0x80 are valid values). Just to make sure something like that isn't happening, could you correct the line in wbcir_irq_rx() which currently reads: rawir.duration = US_TO_NS((irdata 0x7F) * 10); so that it reads rawir.duration = US_TO_NS(((irdata 0x7F) + 1) * 10); However, I'm guessing you inserted the extra debug printk inside wbcir_irq_rx() so any 0x00 or 0x80 bytes would have been printed? Another possibility is that the printk in the interrupt handler causes overhead...could you do a debug run without the printk in the interrupt handler? Also, could you provide me with the full versions of both logs? (i.e. all the way to idleit might help spot a missed pulse/space) Thanks, David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
David, i see your point - as i mentioned i have no any knowledge of IR receiver part you're discussing and/or its Linux drivers and don't want just to spam, but my simple thinking is that if the Logitech Harmony universal remote control is with wrongly configured firmware it can emit something that is so messed up that makes the IR receiver part behaves in completely unpredictable way. anyway, at least Anton have some ideas to try... On Thu, Jul 5, 2012 at 5:45 PM, David Härdeman da...@hardeman.nu wrote: On Thu, 5 Jul 2012 17:39:18 +0300, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: excuse me for my ignorance, but don't you think adjusting the IR receiver to universal remote control is fundamentally wrong, while the whole point of universal remote control like Logitech Harmony is to be adjusted to the IR receiver and be able to be adjusted to any IR receiver and not the other way around. so, that being said, my point is maybe the whole discussion here is just wild goose chase until those settings i mentioned in Logitech control software are not tried and there is no evidence that has already being done based on the information provided by Anton. we don't know what exactly those settings applied to Logitech Harmony firmware via Logitech control software do and it could be default pulse timings that are set trough them are just out of specification for RC6 and need to be manually refined using the Harmony firmware settings in question - once again after all universal remote control is supposed to be able to fit any IR receiver and any type of pulses and that's why provides series of different settings in order to do that - the issue seems more like misconfiguration of the universal remote control than Linux drivers problem. i'm just trying to save you time chasing not existing problems and don't mean anything else - i didn't even look at the source code you're discussing - i just have practical experience with Logitech Harmony 890 and thus i know keymaps and protocols are independently set from the proper pulse timings with Logitech control software. Konstantin, thanks for your concern, but some of the byte sequences that Anton showed are incorrect in the sense that the receiver hardware should never generate them no matter what the (Logitech) remote is sending (unless I've misunderstood something of course). 0xdc 0xff 0xde is a sequence which shouldn't happen. So even if the Logitech can be tweaked (and I'm sure Anton is grateful for the information), there is something wrong here and I'd like to get to the bottom of what it is. Kind regards, David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ts2020: add ts2020 tuner driver
On Tue, May 8, 2012 at 9:32 AM, Igor M. Liplianin liplia...@me.by wrote:
On 7 Ð¼Ð°Ñ 2012 00:22:30 Konstantin Dimitrov wrote:
add separate ts2020 tuner driver
Signed-off-by: Konstantin Dimitrov kosio.dimit...@gmail.com
--- a/linux/drivers/media/dvb/frontends/Kconfig 2012-04-20
06:45:55.0 +0300
+++ b/linux/drivers/media/dvb/frontends/Kconfig 2012-05-07
00:58:26.888543350 +0300
@@ -221,6 +221,13 @@
help
A DVB-S tuner module. Say Y when you want to support this frontend.
+config DVB_TS2020
+ tristate Montage Tehnology TS2020 based tuners
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ A DVB-S/S2 silicon tuner. Say Y when you want to support this tuner.
+
config DVB_DS3000
tristate Montage Tehnology DS3000 based
depends on DVB_CORE I2C
--- a/linux/drivers/media/dvb/frontends/Makefile 2012-04-20
06:45:55.0 +0300
+++ b/linux/drivers/media/dvb/frontends/Makefile 2012-05-07
00:54:44.624546145 +0300
@@ -87,6 +87,7 @@
obj-$(CONFIG_DVB_EC100) += ec100.o
obj-$(CONFIG_DVB_HD29L2) += hd29l2.o
obj-$(CONFIG_DVB_DS3000) += ds3000.o
+obj-$(CONFIG_DVB_TS2020) += ts2020.o
obj-$(CONFIG_DVB_MB86A16) += mb86a16.o
obj-$(CONFIG_DVB_MB86A20S) += mb86a20s.o
obj-$(CONFIG_DVB_IX2505V) += ix2505v.o
--- a/linux/drivers/media/dvb/frontends/ts2020.h 2012-05-07
01:36:49.876514403 +0300
+++ b/linux/drivers/media/dvb/frontends/ts2020.h 2012-05-07
01:12:54.148532449 +0300
@@ -0,0 +1,68 @@
+/*
+ Montage Technology TS2020 - Silicon Tuner driver
+ Copyright (C) 2009-2012 Konstantin Dimitrov kosio.dimit...@gmail.com
+
+ Copyright (C) 2009-2012 TurboSight.com
+
+ 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 TS2020_H
+#define TS2020_H
+
+#include linux/dvb/frontend.h
+
+struct ts2020_config {
+ u8 tuner_address;
+};
+
+struct ts2020_state {
+ struct i2c_adapter *i2c;
+ const struct ts2020_config *config;
+ struct dvb_frontend *frontend;
+ int status;
+};
+
+#if defined(CONFIG_DVB_TS2020) || \
+ (defined(CONFIG_DVB_TS2020_MODULE) defined(MODULE))
+
+extern struct dvb_frontend *ts2020_attach(
+ struct dvb_frontend *fe,
+ const struct ts2020_config *config,
+ struct i2c_adapter *i2c);
+
+extern int ts2020_get_signal_strength(
+ struct dvb_frontend *fe,
+ u16 *strength);
+#else
+static inline struct dvb_frontend *ts2020_attach(
+ struct dvb_frontend *fe,
+ const struct ts2020_config *config,
+ struct i2c_adapter *i2c)
+{
+ printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
+ return NULL;
+}
+
+static inline int ts2020_get_signal_strength(
+ struct dvb_frontend *fe,
+ u16 *strength)
+{
+ printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
+ return NULL;
+}
+#endif
+
+#endif /* TS2020_H */
--- a/linux/drivers/media/dvb/frontends/ts2020_cfg.h 2012-05-07
01:36:59.836514279 +0300
+++ b/linux/drivers/media/dvb/frontends/ts2020_cfg.h 2012-05-07
01:12:56.248532422 +0300
@@ -0,0 +1,64 @@
+/*
+ Montage Technology TS2020 - Silicon Tuner driver
+ Copyright (C) 2009-2012 Konstantin Dimitrov kosio.dimit...@gmail.com
+
+ Copyright (C) 2009-2012 TurboSight.com
+
+ 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.
+ */
+
+static int ts2020_get_frequency(struct dvb_frontend *fe, u32 *frequency)
+{
+ struct dvb_frontend_ops *frontend_ops = NULL;
+ struct dvb_tuner_ops *tuner_ops = NULL;
+ struct tuner_state t_state;
+ int ret = 0
[PATCH 1/3] ds3000: remove ts2020 tuner related code
remove ts2020 tuner related code from ds3000 driver
prepare ds3000 driver for using external tuner driver
Signed-off-by: Konstantin Dimitrov kosio.dimit...@gmail.com
--- a/linux/drivers/media/dvb/frontends/ds3000.h2011-02-27
06:45:21.0 +0200
+++ b/linux/drivers/media/dvb/frontends/ds3000.h2012-05-07
00:44:19.188554007 +0300
@@ -1,8 +1,8 @@
/*
-Montage Technology DS3000/TS2020 - DVBS/S2 Satellite demod/tuner driver
-Copyright (C) 2009 Konstantin Dimitrov kosio.dimit...@gmail.com
+Montage Technology DS3000 - DVBS/S2 Demodulator driver
+Copyright (C) 2009-2012 Konstantin Dimitrov kosio.dimit...@gmail.com
-Copyright (C) 2009 TurboSight.com
+Copyright (C) 2009-2012 TurboSight.com
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
@@ -17,7 +17,7 @@
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 DS3000_H
#define DS3000_H
@@ -30,6 +30,8 @@
u8 ci_mode;
/* Set device param to start dma */
int (*set_ts_params)(struct dvb_frontend *fe, int is_punctured);
+ int (*tuner_set_frequency) (struct dvb_frontend *fe, u32 frequency);
+ int (*tuner_get_frequency) (struct dvb_frontend *fe, u32 *frequency);
};
#if defined(CONFIG_DVB_DS3000) || \
--- a/linux/drivers/media/dvb/frontends/ds3000.c2012-01-19
06:45:32.0 +0200
+++ b/linux/drivers/media/dvb/frontends/ds3000.c2012-05-07
00:40:39.856556762 +0300
@@ -1,8 +1,8 @@
/*
-Montage Technology DS3000/TS2020 - DVBS/S2 Demodulator/Tuner driver
-Copyright (C) 2009 Konstantin Dimitrov kosio.dimit...@gmail.com
+Montage Technology DS3000 - DVBS/S2 Demodulator driver
+Copyright (C) 2009-2012 Konstantin Dimitrov kosio.dimit...@gmail.com
-Copyright (C) 2009 TurboSight.com
+Copyright (C) 2009-2012 TurboSight.com
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
@@ -42,7 +42,6 @@
#define DS3000_DEFAULT_FIRMWARE dvb-fe-ds3000.fw
#define DS3000_SAMPLE_RATE 96000 /* in kHz */
-#define DS3000_XTAL_FREQ 27000 /* in kHz */
/* Register values to initialise the demod in DVB-S mode */
static u8 ds3000_dvbs_init_tab[] = {
@@ -257,22 +256,14 @@
return 0;
}
-static int ds3000_tuner_writereg(struct ds3000_state *state, int reg, int data)
+static int ds3000_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
- u8 buf[] = { reg, data };
- struct i2c_msg msg = { .addr = 0x60,
- .flags = 0, .buf = buf, .len = 2 };
- int err;
-
- dprintk(%s: write reg 0x%02x, value 0x%02x\n, __func__, reg, data);
+ struct ds3000_state *state = fe-demodulator_priv;
- ds3000_writereg(state, 0x03, 0x11);
- err = i2c_transfer(state-i2c, msg, 1);
- if (err != 1) {
- printk(%s: writereg error(err == %i, reg == 0x%02x,
- value == 0x%02x)\n, __func__, err, reg, data);
- return -EREMOTEIO;
- }
+ if (enable)
+ ds3000_writereg(state, 0x03, 0x12);
+ else
+ ds3000_writereg(state, 0x03, 0x02);
return 0;
}
@@ -349,38 +340,6 @@
return b1[0];
}
-static int ds3000_tuner_readreg(struct ds3000_state *state, u8 reg)
-{
- int ret;
- u8 b0[] = { reg };
- u8 b1[] = { 0 };
- struct i2c_msg msg[] = {
- {
- .addr = 0x60,
- .flags = 0,
- .buf = b0,
- .len = 1
- }, {
- .addr = 0x60,
- .flags = I2C_M_RD,
- .buf = b1,
- .len = 1
- }
- };
-
- ds3000_writereg(state, 0x03, 0x12);
- ret = i2c_transfer(state-i2c, msg, 2);
-
- if (ret != 2) {
- printk(KERN_ERR %s: reg=0x%x(error=%d)\n, __func__, reg, ret);
- return ret;
- }
-
- dprintk(%s: read reg 0x%02x, value 0x%02x\n, __func__, reg, b1[0]);
-
- return b1[0];
-}
-
static int ds3000_load_firmware(struct dvb_frontend *fe,
const struct firmware *fw);
@@ -580,29 +539,8 @@
static int ds3000_read_signal_strength(struct dvb_frontend *fe,
u16 *signal_strength)
{
- struct ds3000_state *state = fe-demodulator_priv;
- u16 sig_reading, sig_strength;
- u8 rfgain, bbgain;
-
- dprintk(%s()\n, __func__);
-
- rfgain = ds3000_tuner_readreg(state, 0x3d) 0x1f;
- bbgain = ds3000_tuner_readreg(state, 0x21) 0x1f;
-
- if (rfgain 15)
- rfgain = 15;
- if (bbgain 13
[PATCH 2/3] ts2020: add ts2020 tuner driver
add separate ts2020 tuner driver
Signed-off-by: Konstantin Dimitrov kosio.dimit...@gmail.com
--- a/linux/drivers/media/dvb/frontends/Kconfig 2012-04-20
06:45:55.0 +0300
+++ b/linux/drivers/media/dvb/frontends/Kconfig 2012-05-07
00:58:26.888543350 +0300
@@ -221,6 +221,13 @@
help
A DVB-S tuner module. Say Y when you want to support this frontend.
+config DVB_TS2020
+ tristate Montage Tehnology TS2020 based tuners
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ A DVB-S/S2 silicon tuner. Say Y when you want to support this tuner.
+
config DVB_DS3000
tristate Montage Tehnology DS3000 based
depends on DVB_CORE I2C
--- a/linux/drivers/media/dvb/frontends/Makefile2012-04-20
06:45:55.0 +0300
+++ b/linux/drivers/media/dvb/frontends/Makefile2012-05-07
00:54:44.624546145 +0300
@@ -87,6 +87,7 @@
obj-$(CONFIG_DVB_EC100) += ec100.o
obj-$(CONFIG_DVB_HD29L2) += hd29l2.o
obj-$(CONFIG_DVB_DS3000) += ds3000.o
+obj-$(CONFIG_DVB_TS2020) += ts2020.o
obj-$(CONFIG_DVB_MB86A16) += mb86a16.o
obj-$(CONFIG_DVB_MB86A20S) += mb86a20s.o
obj-$(CONFIG_DVB_IX2505V) += ix2505v.o
--- a/linux/drivers/media/dvb/frontends/ts2020.h2012-05-07
01:36:49.876514403 +0300
+++ b/linux/drivers/media/dvb/frontends/ts2020.h2012-05-07
01:12:54.148532449 +0300
@@ -0,0 +1,68 @@
+/*
+Montage Technology TS2020 - Silicon Tuner driver
+Copyright (C) 2009-2012 Konstantin Dimitrov kosio.dimit...@gmail.com
+
+Copyright (C) 2009-2012 TurboSight.com
+
+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 TS2020_H
+#define TS2020_H
+
+#include linux/dvb/frontend.h
+
+struct ts2020_config {
+ u8 tuner_address;
+};
+
+struct ts2020_state {
+ struct i2c_adapter *i2c;
+ const struct ts2020_config *config;
+ struct dvb_frontend *frontend;
+ int status;
+};
+
+#if defined(CONFIG_DVB_TS2020) || \
+ (defined(CONFIG_DVB_TS2020_MODULE) defined(MODULE))
+
+extern struct dvb_frontend *ts2020_attach(
+ struct dvb_frontend *fe,
+ const struct ts2020_config *config,
+ struct i2c_adapter *i2c);
+
+extern int ts2020_get_signal_strength(
+ struct dvb_frontend *fe,
+ u16 *strength);
+#else
+static inline struct dvb_frontend *ts2020_attach(
+ struct dvb_frontend *fe,
+ const struct ts2020_config *config,
+ struct i2c_adapter *i2c)
+{
+ printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
+ return NULL;
+}
+
+static inline int ts2020_get_signal_strength(
+ struct dvb_frontend *fe,
+ u16 *strength)
+{
+ printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
+ return NULL;
+}
+#endif
+
+#endif /* TS2020_H */
--- a/linux/drivers/media/dvb/frontends/ts2020_cfg.h2012-05-07
01:36:59.836514279 +0300
+++ b/linux/drivers/media/dvb/frontends/ts2020_cfg.h2012-05-07
01:12:56.248532422 +0300
@@ -0,0 +1,64 @@
+/*
+Montage Technology TS2020 - Silicon Tuner driver
+Copyright (C) 2009-2012 Konstantin Dimitrov kosio.dimit...@gmail.com
+
+Copyright (C) 2009-2012 TurboSight.com
+
+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.
+ */
+
+static int ts2020_get_frequency(struct dvb_frontend *fe, u32 *frequency)
+{
+ struct dvb_frontend_ops *frontend_ops = NULL;
+ struct dvb_tuner_ops *tuner_ops = NULL;
+ struct tuner_state t_state;
+ int ret = 0;
+
+ if (fe-ops)
+ frontend_ops = fe-ops;
+ if (frontend_ops-tuner_ops)
+ tuner_ops = frontend_ops-tuner_ops;
+ if (tuner_ops-get_state) {
+ ret
[PATCH 3/3] make the other drivers take use of the new ts2020 driver
make the other drivers take use of the separate ts2020 driver
Signed-off-by: Konstantin Dimitrov kosio.dimit...@gmail.com
--- a/linux/drivers/media/dvb/frontends/ds3000.c2012-05-07
02:24:25.900920554 +0300
+++ b/linux/drivers/media/dvb/frontends/ds3000.c2012-05-07
02:26:01.728919348 +0300
@@ -27,6 +27,7 @@
#include linux/firmware.h
#include dvb_frontend.h
+#include ts2020.h
#include ds3000.h
static int debug;
@@ -539,8 +540,7 @@
static int ds3000_read_signal_strength(struct dvb_frontend *fe,
u16 *signal_strength)
{
- /* temporary disabled until seperate ts2020 tuner driver is merged */
- *signal_strength = 0x;
+ ts2020_get_signal_strength(fe, signal_strength);
return 0;
}
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c 2012-01-17
06:45:50.0 +0200
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c 2012-05-07
01:48:37.352505509 +0300
@@ -57,6 +57,8 @@
#include netup-init.h
#include lgdt3305.h
#include atbm8830.h
+#include ts2020.h
+#include ts2020_cfg.h
#include ds3000.h
#include cx23885-f300.h
#include altera-ci.h
@@ -464,6 +466,13 @@
static struct ds3000_config tevii_ds3000_config = {
.demod_address = 0x68,
+
+ .tuner_get_frequency = ts2020_get_frequency,
+ .tuner_set_frequency = ts2020_set_frequency,
+};
+
+static struct ts2020_config tevii_ts2020_config = {
+ .tuner_address = 0x60,
};
static struct cx24116_config dvbworld_cx24116_config = {
@@ -966,8 +975,11 @@
fe0-dvb.frontend = dvb_attach(ds3000_attach,
tevii_ds3000_config,
i2c_bus-i2c_adap);
- if (fe0-dvb.frontend != NULL)
+ if (fe0-dvb.frontend != NULL) {
+ dvb_attach(ts2020_attach, fe0-dvb.frontend,
+ tevii_ts2020_config, i2c_bus-i2c_adap);
fe0-dvb.frontend-ops.set_voltage = f300_set_voltage;
+ }
break;
case CX23885_BOARD_DVBWORLD_2005:
--- a/linux/drivers/media/video/cx88/cx88-dvb.c 2012-01-08
06:45:35.0 +0200
+++ b/linux/drivers/media/video/cx88/cx88-dvb.c 2012-05-07
03:02:54.359917746 +0300
@@ -58,6 +58,8 @@
#include stb6100.h
#include stb6100_proc.h
#include mb86a16.h
+#include ts2020.h
+#include ts2020_cfg.h
#include ds3000.h
MODULE_DESCRIPTION(driver for cx2388x based DVB cards);
@@ -698,6 +700,13 @@
static struct ds3000_config tevii_ds3000_config = {
.demod_address = 0x68,
.set_ts_params = ds3000_set_ts_param,
+
+ .tuner_get_frequency = ts2020_get_frequency,
+ .tuner_set_frequency = ts2020_set_frequency,
+};
+
+static struct ts2020_config tevii_ts2020_config = {
+ .tuner_address = 0x60,
};
static const struct stv0900_config prof_7301_stv0900_config = {
@@ -1466,9 +1475,12 @@
fe0-dvb.frontend = dvb_attach(ds3000_attach,
tevii_ds3000_config,
core-i2c_adap);
- if (fe0-dvb.frontend != NULL)
+ if (fe0-dvb.frontend != NULL) {
+ dvb_attach(ts2020_attach, fe0-dvb.frontend,
+ tevii_ts2020_config, core-i2c_adap);
fe0-dvb.frontend-ops.set_voltage =
tevii_dvbs_set_voltage;
+ }
break;
case CX88_BOARD_OMICOM_SS4_PCI:
case CX88_BOARD_TBS_8920:
--- a/linux/drivers/media/dvb/dm1105/dm1105.c 2012-01-08
06:45:35.0 +0200
+++ b/linux/drivers/media/dvb/dm1105/dm1105.c 2012-05-07
03:03:10.899917539 +0300
@@ -45,6 +45,8 @@
#include si21xx.h
#include cx24116.h
#include z0194a.h
+#include ts2020.h
+#include ts2020_cfg.h
#include ds3000.h
#define MODULE_NAME dm1105
@@ -847,6 +849,13 @@
static struct ds3000_config dvbworld_ds3000_config = {
.demod_address = 0x68,
+
+ .tuner_get_frequency = ts2020_get_frequency,
+ .tuner_set_frequency = ts2020_set_frequency,
+};
+
+static struct ts2020_config dvbworld_ts2020_config = {
+ .tuner_address = 0x60,
};
static int __devinit frontend_init(struct dm1105_dev *dev)
@@ -898,8 +907,11 @@
dev-fe = dvb_attach(
ds3000_attach, dvbworld_ds3000_config,
dev-i2c_adap);
- if (dev-fe)
+ if (dev-fe) {
+ dvb_attach(ts2020_attach, dev-fe,
+ dvbworld_ts2020_config, dev-i2c_adap);
dev-fe-ops.set_voltage = dm1105_set_voltage;
+ }
break;
case DM1105_BOARD_DVBWORLD_2002:
--- a/linux/drivers/media/dvb/dvb-usb/dw2102.c 2012-01-22
03:53:17.0 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dw2102.c 2012-05-07
03:03:22.739917389 +0300
Re: [PATCH 1/6 v2] dvbsky, montage dvb-s/s2 TS202x tuner and M88DS3103demodulator driver
On Fri, Apr 27, 2012 at 5:35 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 27-04-2012 11:17, nibble.max escreveu: 2012-04-27 22:03:20 nibble@gmail.com Em 27-04-2012 04:06, nibble.max escreveu: --- drivers/media/dvb/frontends/Kconfig | 14 + drivers/media/dvb/frontends/Makefile | 3 + drivers/media/dvb/frontends/m88ds3103.c | 1153 ++ drivers/media/dvb/frontends/m88ds3103.h | 67 ++ drivers/media/dvb/frontends/m88ds3103_priv.h | 413 + drivers/media/dvb/frontends/m88ts202x.c | 590 + drivers/media/dvb/frontends/m88ts202x.h | 63 ++ 7 files changed, 2303 insertions(+) create mode 100644 drivers/media/dvb/frontends/m88ds3103.c create mode 100644 drivers/media/dvb/frontends/m88ds3103.h create mode 100644 drivers/media/dvb/frontends/m88ds3103_priv.h create mode 100644 drivers/media/dvb/frontends/m88ts202x.c create mode 100644 drivers/media/dvb/frontends/m88ts202x.h No, this is not what we've agreed. You should, instead, take Konstantin's driver, breaking it into two separate ones, without touching the copyrights. Then, apply what else is needed for ds3103/ts2123. Hello Mauro, Should I need Konstantin's agreement to do that? While the driver is GPLv2, he is the author of the driver. GPL is not copyleft. You can't simply decide to change the copyrights. Mauro, well said and thanks for standing up and defending the open-source. so, m88ds3103 in it's current version is just combination of using shuffling of my ds3000 code plus using copyrighted code by Montage Technologies - the last is even another reason why m88ds3103 can't be accepted, because then actually Montage Technologies should be listed in the copyright and wait for their approval. let me give example what i mean - let's take ToneBurst function as example - m88ds3103_diseqc_send_burst() - at the current version of m88ds3103 it's exactly the same code as the one from the reference code copyrighted by Montage Technologies and provided by them under NDA (i have access to that code), in the previous versions of m88ds3103 it was the same function as mine in ds3000_diseqc_send_burs() in ds3000.c - in both cases m88ds3103 can't be accepted. also, if you look at mine ToneBurst function ds3000_diseqc_send_burs() in ds3000.c you will see it's quite different than the one copyrighted by Montage Technologies, e.g. some of the register settings are different, etc, because i made it really from scratch - it could be even it's not better than the original settings used by the code copyrighted by Montage Technologies, but it's at least something genuine to which i came up - of course, the chip limits you in the ways how you can control it. last, but not least, just changing the condition of if-else statements (swapping it) and using do-while-loop instead for-loop is nothing more then shuffling the code. so, what i would accept: - patch against ds3000.c that adds ds3103 support: copyright is unchanged and instead credit for the ds3103 support is get by history note, example what i mean and how is the right way to be done in my opinion: === Montage Technology DS3000/TS2020 - DVBS/S2 Demodulator/Tuner driver Copyright (C) 2009 Konstantin Dimitrov kosio.dimit...@gmail.com Copyright (C) 2009 TurboSight.com History: April 2012: Add support for the new silicone revision ds3103 Max nibblenibble@gmail.com === - any changes that don't involved ds3103 support are subject to review and argumentation why they are done, i.e. they are bug, the setting is wrong, etc. Using the seperate tuner and demod, I need to change the codes which use the ds3000 frontend. How can I test the code to confirm that these codes are right without these hardwards? Well, at the split patch, you shouldn't do anything but to split tuner and demod. This will make easier for others to test, if you don't have the hardware for testing. i haven't had time to read the emails and i'm still not sure what is the motivation to split them, because Montage tuner and demodulator are like married couple. however, if there is really motivation about that then let's do it - i will help as far as my spare time allows and even with the testing, i.e. that nothing got broken as result of that. 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
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
hello Antti, sorry that i wasn't able to get back to you earlier. On Tue, Apr 24, 2012 at 12:04 AM, Antti Palosaari cr...@iki.fi wrote: Hello Konstantin, Good to heard you and finally got your reply to thread. On 23.04.2012 22:51, Konstantin Dimitrov wrote: Antti, i already commented about ds3103 drivers months ago: http://www.mail-archive.com/linux-media@vger.kernel.org/msg41135.html and from my point of view nothing have changed - ds3103 chip is almost the same as ds3000 and the driver i made for ds3000 from scratch is what was used ds3103 drivers to be created. so, what you actually is suggesting - my driver to be removed from the kernel and driver that was made based on my hard work to be included and that driver author even refuses to acknowledge my work?! such practices are really good for the open-source community, don't you think? also, we already have one case for example, where to satisfy someone's interests two drivers for the same demodulators (STV090x family of chips) were accepted in the kernel - i doubt anyone actually can tell why there are 2 drivers for STV090x in the kernel and instead the community to support the driver for STV090x that was made with more open-source ideas in mind, i.e. the one that can work with any STV090x design and which relies less on code copyrighted by ST - anyway, those details about STV090x drivers are off-topic here, but i'm still giving them as example, because the fact is that already once such mess was created having multiple drivers for the same generation of chips in the kernel and apparently those practices will continue if someone don't raise those questions out loud. also, why Montage tuner code should be spitted from the demodulator code? is there any evidence that any Montage tuner (ts2020 or ts2022) can work with 3rd party demodulator different than ds3000 or ds3103? I don't know what is situation of these Montage chips and what are possible combinations. *But* there is many existing cases from the DVB-T I am aware. Things are done wrongly and all is implemented as a one big blob. After that new device is arrived and we cannot support it since existing drivers are not split. And it is not single case... i understand your point, but i believe with DVB-T is quite different than with DVB-S2, i.e. it's very rare to mix DVB-S2 tuners and demodulators in such way how it's done with DVB-T. in fact, i'm not aware of any such mixes in real-life. also, below i will give a lot of technical details, i.e. facts about CX24116 or TDA10071 and CX24118A and then i'm sure you will understand my point why the same discussion can be made for CX24116 and TDA10071 drivers. It may happen or it may not happen. You never known. But still it is nice to split drivers correctly to avoid such problems that could be possible in some day. And I don't even know how much those tuners and demods differs - I only saw that patch and it looked there was some differences, even so much that two tuner drivers could be good choice. are there such designs in real-life, e.g. either Montage demodulator with 3rd party tuner or actually more importantly for what you're suggesting Montage tuner (ts2020 or ts2022) with third party demodulator? it's more or less the same case as with cx24116 (and tda10071) demodulator, where the tuner (cx24118a) is controlled by the firmware and thus it's solely part of the demodulator driver, even that it's possible to control the cx24118a tuner that is used with cx24116 (and tda10071) designs directly bypassing the firmware. so, why we don't change in that way the cx24116 (and tda10071) drivers too? CX24116 and TDA10071 (I made TDA10071) are somehow different as tuner is driven by demodulator firmware. There is no tuner that needs to be driven by driver at least for now. it's off-topic, but anyway i think it would be useful information to you and most of it is in the public domains anyway and thus i won't break any rules. so, you can google for: * s2TDQR-C005F and get the datasheet of LG NIM that consists of CX24118A + CX24116, read page 14 of it, there is figure diagram about it : in short it gives you all the details how CX24118A is connected to the CX24116 and explains that when there is no support for the tuner in CX24116 firmware then tuner pass-through can be used and that CX24118A also can be used with tuner pass-through, i.e. direct control no matter that it's supported tuner in the CX24116 firmware * now google for BS2F7HZ0165 datasheet in PDF (not the product brief, the datasheet is scanned and ugly looking), which is SHARP NIM that consists of CX24118A + CX24116 and on page 6 you can get even more information and even how to program the tuner pass-through mode * further more you can google for MDVBS2-24116, which is NIM made by Comtech with CX24118A + CX24116 and get all CX24118A control registers and their meaning so, the above 3 PDFs that are in the public domain gives you
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
Mauro, your reasoning makes sense to me. so, let's split them and at least settle this part of the discussion - i will do as far as my spare time allows, as well make sure there are no some problems introduced after the split. also, in one email i've just sent in answer to Antti there is enough argument why such split, i.e. tuner-pass-through-mode is subject to discussion about CX24116 and TDA10071 drivers too. currently, majority of DVB-S2 demodulator drivers in the kernel are married to particular tuners and there is no split. On Tue, Apr 24, 2012 at 12:49 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 23-04-2012 19:51, Konstantin Dimitrov escreveu: Antti, i already commented about ds3103 drivers months ago: also, why Montage tuner code should be spitted from the demodulator code? is there any evidence that any Montage tuner (ts2020 or ts2022) can work with 3rd party demodulator different than ds3000 or ds3103? This has nothing to do with Montage devices, but with the way we write those drivers in Kernel. There are _several_ examples where the driver for a single silicon were turned into more than one driver. The biggest examples are the SoC chips, that are transformed into a large series of drivers. Another example is the cx88 driver: due to technical reasons, it was splitted into 4 drivers, one for each different PCI ID exported by it. The cx2341x driver is also an interesting example: while it used to be for a separate chip, the cx2341x functions are now part of IP blocks on newer Conexant chipsets. Those single chips require two drivers to work (cx2341x and the associated media PCI bridge driver). Looking into tuners, there are the tda18271 family of devices, with are supported by several drivers: tda827x, tda8290 and tda18271-fe, depending on how the actual device is mounted. Eventually, the actual tuner may also have a tda9887 inside it. So, there's nothing wrong on splitting it on separate drivers. In a matter of fact, we strongly prefer to have tuners separate from demods. Having them together can only be justified technically, if there are really strong reasons why they should be at the same driver. I probably missed this at my review for ds3000 (that's why it ended by being merged), but, on the review I did on it (accidentally due to m88ds3103 patchset review), it is clear that the tuner has actually a different I2C address (0x60) than the demod, and it is indeed a separate device. Sorry for slipping into it. Anyway, now that this is noticed, tuner and demod drivers should be split, especially since there are some patches floating around to add support for ds3103. As I said before, the right thing to do is: 1) split ds3000 from ts2020 at the existing driver; 2) add support for the newer chips (ds3103/ts2022) to the ds3000 and ds3103 drivers. 3) test if the patches adding support for the newer chips didn't break the support for existing hardware. My proposal is that tasks (1) and (3) should be handled by you. As Max wants to add support for some devices based on ds3103/ts2022, IMO, he can do the patches for (2) in a way that they would be acceptable by you, as the driver maintainer for ds3000/ts2020, testing with their devices. 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
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
On Fri, Apr 27, 2012 at 10:55 PM, Antti Palosaari cr...@iki.fi wrote: On 27.04.2012 22:01, Konstantin Dimitrov wrote: Mauro, your reasoning makes sense to me. so, let's split them and at least settle this part of the discussion - i will do as far as my spare time allows, as well make sure there are no some problems introduced after the split. also, in one email i've just sent in answer to Antti there is enough argument why such split, i.e. tuner-pass-through-mode is subject to discussion about CX24116 and TDA10071 drivers too. currently, majority of DVB-S2 demodulator drivers in the kernel are married to particular tuners and there is no split. I read the mail and as it was long study, I comment only that CX24116+CX24118A and TDA10071+CX24118A demod+tuner combos versus Montage demod+tuner combos. As you may see, CX24116 and TDA10071 are so much different than both needs own driver. But as you said those are married always as a demod+tuner. So if I use your logic, what happens if CX24118A tuner is not driven by CX24116 or TDA10071 firmware? == it happens we have two drivers, CX24116 and TDA10071 *both* having similar CX24118A tuner driver code inside! Same tuner driver code inside two demods drivers. Could you now understand why we want it split? The reason which saves us having CX24118A tuner driver is that it is inside both CX24116 and TDA10071 firmware. There is mainly two different controlling situation. Most commonly driver controls chip but in some cases it is firmware which is controlling. And I don't see it very important trying always to by-pass firmware control and use driver for that. i got that point, but what happens if tomorrow their is CX24116 or TDA10071 design with tuner different than CX14118A? in fact the LG datasheet i pointed out to you clearly states that for example there is actually such design - case when CX24116 is used with CX24128 tuner instead CX24118A in which case the only way is to bypass the firmware and control the tuner directly. also, isn't it even double bad the current state of CX24116 or TDA10071 drivers - from one side they use 2 firmwares, part of which is doing the same, i.e control the CX24118A and from the other side they depend on proprietary firmware to do something that can be done in open-source code? i don't know, but at least from my point of view if that's not worse than the current status of ds3000 driver, it's at least as wrong as it, i.e. there isn't not only separation of tuner and demodulator code in CX24116 or TDA10071 drivers, but there is not even a code that can allow they to be separated easily, because making CX14118A driver from scratch is task that will need some effort. anyway, maybe, it's just me, but i prefer to depend as less as possible on proprietary firmwares done is such way. however, there is no any doubt current CX24116 or TDA10071 drivers don't allow any other tuner that is not supported by the proprietary firmware to be used and thus they break the rule of tuner and demodulator code separation. so, i really don't understand what makes CX24116 or TDA10071 drivers different than the others, i.e. why they are developed in such way and there is no discussion about them to be changed in way that allow use of other tuner like CX24128, which is not supported by the proprietary firmwares. so, the only explanation from my perspective is lack of such need in real-life, but it's the same for ds3000. Patrick explained those few days back in the mailing list: http://www.mail-archive.com/linux-media@vger.kernel.org/msg44814.html You said also we cannot know if Montage demod does some tweaking for the tuner too. Yes true, at that point we don't know. But I think it is rather small probability whilst driver clearly controls it. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
hi Mauro, in the mean time i was actually pointed out that there is 3rd party tuner that is proved to work in practice with both Montage ds3k demodulator family, as well ST STV090x demods, i.e. there are such reference designs. so, the split further makes sense and in fact that should be make in way that both drivers for STV090x and Montage ds3k demodulator family can share tuners with each other. so, that's just note for the upcoming review of the patches i will submit - in short the split of Montage tuner and demodulator code i will make it in the same fashion as how the driver code for ST 6100/6110 tuner are split from STV090x driver, because that now, as i've just mentioned, makes sense from practical point of view since of the 3rd party tuner for which there is reference designs with both STV090x and Montage demodulator. also, that way STB0899, STV090x and Montage demodulator drivers can be used together with any other of the DVB-S2 tuners available in the kernel - ST 6100 and 6110 and soon TS2020. however, i want to pointed out few other problems - they are off-topic as not related to drivers for Montage chips, but related as far as we're putting some order and making things in a proper way and those those things are out of that order: - there are 2 drivers for the same DVB-S2 tuner: ST 6110, respectively stv6110.c and stv6110x.c - there are 2 drivers for the same DVB-S2 demodulator family: respectively stv090x* and stv0900* the above couldn't be more wrong - in fact i can submit patches to make all drivers that relies on stv090x* and stv6110.c to use stv090x* and stv6110x.c instead except the NetUP board, for which in my opinion someone should submit patches using stv090x* and stv6110x.c and subsequently stv090x* and stv6110.c be removed - unless someone have some real argument why stv090x* and stv6110.c should stay or even if for why they should replace stv090x* and stv6110x.c and subsequently stv090x* and stv6110x.c be removed instead. so, the case with ST 6110 and STV090x support is the most frustrating and out of order thing that i can indicate regarding the support of DVB-S2 chips in the kernel and i hope you will take care as maintainer to be resolved or at least someone to explain why the current state is like that - or point me out to explanation if such was already made to the mailing list. so, what i'm suggesting is spring cleaning of all DVB-S2 tuner/demodulator drivers in the kernel - if it's not done now in the future the mess will only increase. thank you, konstantin On Fri, Apr 27, 2012 at 10:36 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Konstantin, Em 27-04-2012 16:01, Konstantin Dimitrov escreveu: Mauro, your reasoning makes sense to me. so, let's split them and at least settle this part of the discussion - i will do as far as my spare time allows, as well make sure there are no some problems introduced after the split. Thank you! also, in one email i've just sent in answer to Antti there is enough argument why such split, i.e. tuner-pass-through-mode is subject to discussion about CX24116 and TDA10071 drivers too. currently, majority of DVB-S2 demodulator drivers in the kernel are married to particular tuners and there is no split. Besides the reasoning I gave you, having the tuner and the demod on separate drivers help a lot code reviewers to check what's happening inside the code, because the code on each driver becomes more coincide and the two different functions become more decoupled, with reduces the code complexity. So, bugs tend to be reduced and they're easier to fix, especially when someone need to fix bad things at the dvb core. Also, as almost all drivers are like that, it is easier to identify driver patterns, especially when newer patches are adding extra functionality there. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
On Fri, Apr 27, 2012 at 11:37 PM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: hi Mauro, in the mean time i was actually pointed out that there is 3rd party tuner that is proved to work in practice with both Montage ds3k demodulator family, as well ST STV090x demods, i.e. there are such reference designs. so, the split further makes sense and in fact that should be make in way that both drivers for STV090x and Montage ds3k demodulator family can share tuners with each other. so, that's just note for the upcoming review of the patches i will submit - in short the split of Montage tuner and demodulator code i will make it in the same fashion as how the driver code for ST 6100/6110 tuner are split from STV090x driver, because that now, as i've just mentioned, makes sense from practical point of view since of the 3rd party tuner for which there is reference designs with both STV090x and Montage demodulator. also, that way STB0899, STV090x and Montage demodulator drivers can be used together with any other of the DVB-S2 tuners available in the kernel - ST 6100 and 6110 and soon TS2020. however, i want to pointed out few other problems - they are off-topic as not related to drivers for Montage chips, but related as far as we're putting some order and making things in a proper way and those those things are out of that order: - there are 2 drivers for the same DVB-S2 tuner: ST 6110, respectively stv6110.c and stv6110x.c - there are 2 drivers for the same DVB-S2 demodulator family: respectively stv090x* and stv0900* the above couldn't be more wrong - in fact i can submit patches to make all drivers that relies on stv090x* and stv6110.c to use stv090x* and stv6110x.c instead except the NetUP board, for which in my opinion someone should submit patches using stv090x* and stv6110x.c and subsequently stv090x* and stv6110.c be removed - to correct a typo: and subsequently stv0900* and stv6110.c be removed unless someone have some real argument why stv090x* and stv6110.c the same: unless someone have some real argument why stv0900* and stv6110.c should stay or even if for why they should replace stv090x* and stv6110x.c and subsequently stv090x* and stv6110x.c be removed instead. so, the case with ST 6110 and STV090x support is the most frustrating and out of order thing that i can indicate regarding the support of DVB-S2 chips in the kernel and i hope you will take care as maintainer to be resolved or at least someone to explain why the current state is like that - or point me out to explanation if such was already made to the mailing list. so, what i'm suggesting is spring cleaning of all DVB-S2 tuner/demodulator drivers in the kernel - if it's not done now in the future the mess will only increase. thank you, konstantin On Fri, Apr 27, 2012 at 10:36 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Konstantin, Em 27-04-2012 16:01, Konstantin Dimitrov escreveu: Mauro, your reasoning makes sense to me. so, let's split them and at least settle this part of the discussion - i will do as far as my spare time allows, as well make sure there are no some problems introduced after the split. Thank you! also, in one email i've just sent in answer to Antti there is enough argument why such split, i.e. tuner-pass-through-mode is subject to discussion about CX24116 and TDA10071 drivers too. currently, majority of DVB-S2 demodulator drivers in the kernel are married to particular tuners and there is no split. Besides the reasoning I gave you, having the tuner and the demod on separate drivers help a lot code reviewers to check what's happening inside the code, because the code on each driver becomes more coincide and the two different functions become more decoupled, with reduces the code complexity. So, bugs tend to be reduced and they're easier to fix, especially when someone need to fix bad things at the dvb core. Also, as almost all drivers are like that, it is easier to identify driver patterns, especially when newer patches are adding extra functionality there. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
On Fri, Apr 27, 2012 at 11:54 PM, Antti Palosaari cr...@iki.fi wrote: On 27.04.2012 23:40, Konstantin Dimitrov wrote: On Fri, Apr 27, 2012 at 11:37 PM, Konstantin Dimitrov however, i want to pointed out few other problems - they are off-topic as not related to drivers for Montage chips, but related as far as we're putting some order and making things in a proper way and those those things are out of that order: - there are 2 drivers for the same DVB-S2 tuner: ST 6110, respectively stv6110.c and stv6110x.c - there are 2 drivers for the same DVB-S2 demodulator family: respectively stv090x* and stv0900* the above couldn't be more wrong - in fact i can submit patches to make all drivers that relies on stv090x* and stv6110.c to use stv090x* and stv6110x.c instead except the NetUP board, for which in my opinion someone should submit patches using stv090x* and stv6110x.c and subsequently stv090x* and stv6110.c be removed - to correct a typo: and subsequently stv0900* and stv6110.c be removed unless someone have some real argument why stv090x* and stv6110.c the same: unless someone have some real argument why stv0900* and stv6110.c should stay or even if for why they should replace stv090x* and stv6110x.c and subsequently stv090x* and stv6110x.c be removed instead. so, the case with ST 6110 and STV090x support is the most frustrating and out of order thing that i can indicate regarding the support of DVB-S2 chips in the kernel and i hope you will take care as maintainer to be resolved or at least someone to explain why the current state is like that - or point me out to explanation if such was already made to the mailing list. so, what i'm suggesting is spring cleaning of all DVB-S2 tuner/demodulator drivers in the kernel - if it's not done now in the future the mess will only increase. That stv090x stuff is discussed many times earlier too. It is mistake done for the some reasons. In theory there should be only one driver per chip/logical entity but for the non-technical reason it was failed. And as it is failed at the very first try it is hard to correct later. OK, what about i commit to correct it to the degree i can? that degree is : patch all bridge drivers to use stv090x* and stv6110x* except the driver for the NetUP card since i don't have any similar hardware, which i can use for testing and remove the less mature and less versatile drivers involved in the mess, i.e. stv6110.* and stv0900*. until the NetUP don't submit patch to utilize stv090x* and stv6110x* their card will be left in unsupported stage - at least that way 99% of the mess will be cleaned and subsequently the whole mess, because i guess someone with NetUP hardware will contribute what i can't do. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
Antti, Mauro, i believe we're all on the same page here and i just want to summarize based on all the discussion so far and if we all agree: 1) ds3000 and ts2020 code split, there are already several strong arguments about it and most of all that it turned out there is reference design with 3rd party tuner that works both with ds3000 and stv090x demodulators. i will take care of this task 2) the result of 1) would be that the following DVB-S2 tuner and demodulator drivers will be able to work in any combination of each other (assuming there is such hardware design available): stb0899*, stv090x*, ds3000, stv6110x*, stb6100* and ts2020. that's good, because it starts to put order, because those are significant part of the DVB-S2 drivers in the kernel 3) not only, because of 2), but in general it's not clear why there is stv6110.* driver, which is for the exact same silicone as stv6110x*, as well stv0900*, which is for the same family of chips as stv090x*. i can help a little here to the degree that i can make all bridge drivers depend on stv6110x* and stv090x* except the driver for one card made by NetUP - there i can just do it in theory, but i can't test and probably break support for it 4) after 1), 2) and if 3) is resolved the only DVB-S2 drivers that will continue to be married to one particular tuner (CX24118A) that will left are cx24116 and tda10071, which for the time being will be left that way until basically there is someone that volunteers to make separate CX24118A driver based on the LG, SHARP and Comtech datasheets that are available in the public domain, for which i gave details in a previous email, and which in my opinion contain sufficient information that task to be made 5) ds3103 and ts2022 support, done in form of a patch respectively to ds3000 driver and ts2020 driver or if ts2022 happens to be very different than ts2020 then ts2022 support be made as separate driver, i guess Max will take this 6) if it's necessary bug fixes, improvements, etc to the shared code between ds3000 and ds3103, but only after review, discussion and argumentation why those changes are actually needed On Fri, Apr 27, 2012 at 11:42 PM, Antti Palosaari cr...@iki.fi wrote: On 27.04.2012 23:21, Konstantin Dimitrov wrote: On Fri, Apr 27, 2012 at 10:55 PM, Antti Palosaaricr...@iki.fi wrote: On 27.04.2012 22:01, Konstantin Dimitrov wrote: Mauro, your reasoning makes sense to me. so, let's split them and at least settle this part of the discussion - i will do as far as my spare time allows, as well make sure there are no some problems introduced after the split. also, in one email i've just sent in answer to Antti there is enough argument why such split, i.e. tuner-pass-through-mode is subject to discussion about CX24116 and TDA10071 drivers too. currently, majority of DVB-S2 demodulator drivers in the kernel are married to particular tuners and there is no split. I read the mail and as it was long study, I comment only that CX24116+CX24118A and TDA10071+CX24118A demod+tuner combos versus Montage demod+tuner combos. As you may see, CX24116 and TDA10071 are so much different than both needs own driver. But as you said those are married always as a demod+tuner. So if I use your logic, what happens if CX24118A tuner is not driven by CX24116 or TDA10071 firmware? == it happens we have two drivers, CX24116 and TDA10071 *both* having similar CX24118A tuner driver code inside! Same tuner driver code inside two demods drivers. Could you now understand why we want it split? The reason which saves us having CX24118A tuner driver is that it is inside both CX24116 and TDA10071 firmware. There is mainly two different controlling situation. Most commonly driver controls chip but in some cases it is firmware which is controlling. And I don't see it very important trying always to by-pass firmware control and use driver for that. i got that point, but what happens if tomorrow their is CX24116 or TDA10071 design with tuner different than CX14118A? in fact the LG datasheet i pointed out to you clearly states that for example there is actually such design - case when CX24116 is used with CX24128 tuner instead CX24118A in which case the only way is to bypass the firmware and control the tuner directly. also, isn't it even double bad the current state of CX24116 or TDA10071 drivers - from one side they use 2 firmwares, part of which is doing the same, i.e control the CX24118A and from the other side they depend on proprietary firmware to do something that can be done in open-source code? i don't know, but at least from my point of view if that's not worse than the current status of ds3000 driver, it's at least as wrong as it, i.e. there isn't not only separation of tuner and demodulator code in CX24116 or TDA10071 drivers, but there is not even a code that can allow they to be separated easily, because making CX14118A driver from scratch is task that will need some
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
Antti, i already commented about ds3103 drivers months ago: http://www.mail-archive.com/linux-media@vger.kernel.org/msg41135.html and from my point of view nothing have changed - ds3103 chip is almost the same as ds3000 and the driver i made for ds3000 from scratch is what was used ds3103 drivers to be created. so, what you actually is suggesting - my driver to be removed from the kernel and driver that was made based on my hard work to be included and that driver author even refuses to acknowledge my work?! such practices are really good for the open-source community, don't you think? also, we already have one case for example, where to satisfy someone's interests two drivers for the same demodulators (STV090x family of chips) were accepted in the kernel - i doubt anyone actually can tell why there are 2 drivers for STV090x in the kernel and instead the community to support the driver for STV090x that was made with more open-source ideas in mind, i.e. the one that can work with any STV090x design and which relies less on code copyrighted by ST - anyway, those details about STV090x drivers are off-topic here, but i'm still giving them as example, because the fact is that already once such mess was created having multiple drivers for the same generation of chips in the kernel and apparently those practices will continue if someone don't raise those questions out loud. also, why Montage tuner code should be spitted from the demodulator code? is there any evidence that any Montage tuner (ts2020 or ts2022) can work with 3rd party demodulator different than ds3000 or ds3103? are there such designs in real-life, e.g. either Montage demodulator with 3rd party tuner or actually more importantly for what you're suggesting Montage tuner (ts2020 or ts2022) with third party demodulator? it's more or less the same case as with cx24116 (and tda10071) demodulator, where the tuner (cx24118a) is controlled by the firmware and thus it's solely part of the demodulator driver, even that it's possible to control the cx24118a tuner that is used with cx24116 (and tda10071) designs directly bypassing the firmware. so, why we don't change in that way the cx24116 (and tda10071) drivers too? i just don't see what's the motivation behind what you're suggesting, because ds3103 is almost the same as ds3000 from driver point of view and one driver code can be used for both and Montage tuners in question can work only with those demodulators (or at least are used in practice only with them). so, if there are any evidences that's not true then OK let's split them, but if not then what's the point of that? On Mon, Apr 23, 2012 at 7:41 PM, Antti Palosaari cr...@iki.fi wrote: On 21.04.2012 05:45, nibble.max wrote: 2012-04-21 10:38:02 nibble@gmail.com Em 20-04-2012 06:47, Antti Palosaari escreveu: On 20.04.2012 11:01, nibble.max wrote: 2012-04-20 15:56:27 nibble@gmail.com At first time, I check it exist so try to patch it. But with new m88ds3103 features to add and ts2022 tuner include, find it is hard to do simply patch. It is better to create a new driver for maintain. Hi Max, Em 15-04-2012 12:53, nibble.max escreveu: Montage m88ds3103 demodulator and ts2022 tuner driver. It was pointed to me that this device were already discussed on: http://www.mail-archive.com/linux-media@vger.kernel.org/msg43109.html If m88ds3103 demod is similar enough to ds3000, it should just add the needed bits at the existing driver, and not creating a new driver. Thanks, Mauro The main problem of these all existing and upcoming Montage DVB-S/S2 drivers are those are not split originally correct as a tuner and demod and now it causes problems. I really suspect it should be: * single demod driver that supports both DS3000 and DS3103 * single tuner driver that supports both TS2020 and TS2022 And now what we have is 2 drivers that contains both tuner and demod. And a lot of same code. :-( But it is almost impossible to split it correctly at that phase if you don't have both hardware combinations, DS3000/TS2020 and DS3103/TS2022. I think it is best to leave old DS3000 as it is and make new driver for DS3103 *and* TS2022. Maybe after that someone could add DS3000 support to new DS3103 driver and TS2020 support to new TS2022 driver. After that it is possible to remove old DS3000 driver. And we should really consider make simple rule not to accept any driver which is not split as logical parts: USB/PCI-interface + demodulator + tuner. Mixing tuner and demod is not good. Yet, dropping the current ds3000 doesn't seem to be the best approach. IMO, Konstantin/Montage should split the ds3000 driver on two drivers, putting the ts2020 bits on a separate driver. Then, Max should write a patch for ds3000 in order to add support for ds3103 on it, and a patch for ts2020 driver, in order to add support for ts2022 on it. Of course, Konstantin should check if Max changes don't break support for
Re: DVB-S2 multistream support
hi Bob, all work to support BBFrames in the Linux kernel is done by Christian - in fact it's a long lost work from 5 years ago: http://www.linuxtv.org/pipermail/linux-dvb/2007-December/022217.html and i hope it won't be lost again. i just encouraged Christian that his work is important and there are people interested in it - you're one such example. so, i offered Christian to help him with i can. i guess more people appreciating what his doing and encourage him will give him better motivation to release the code to the public. however, i guess the delay is more, because it's not easy and it requires time to prepare the code for initial public release and that's why the delay. so, i don't have Christian's code and i'm eager as you're to be able to try it out, but we need to be patient. i'm sure that after there is some public release and repository more people will be interested to contribute to that work. best regards, konstantin On Wed, Mar 7, 2012 at 6:33 PM, Bob Winslow bob.n...@non-elite.com wrote: that's really great news! i'm looking forward to look at the code when the public repository is ready. i'm sure i'm not the only one and the news would be especially exciting for TBS 6925 owners, which use Linux, but it's away beyond that, because the real news here is working base-band support in 'dvb-core' of V4L. also, it's really good that SAA716x code seems to just work with BBFrames and no further changes are required there. Hi Christian, Konstantin, Well, my TBS 6925 just came in the mail yesterday and I am excited to plug it in and start playing with it. Your work on the bb-demux looks like a good place to start playing with the card under linux. Have you setup a public repo yet for the band band support (bb-demux) ? Also, I downloaded the linux drivers for the card from the TBS dtv site, and put them on my ubuntu 11.10 pc. They seem to work. Is this the best place to get drivers for the card?? the front end driver files seem to be just .o's and the source is not in the tarball. Sorry, I'm a bit new to the dvb world and I am still learning where to find stuff. Any pointers/help to finding the latest code/drivers would be very much appreciated. Kind regards, Bob -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-S2 multistream support
hello Christian, that's really great news! i'm looking forward to look at the code when the public repository is ready. i'm sure i'm not the only one and the news would be especially exciting for TBS 6925 owners, which use Linux, but it's away beyond that, because the real news here is working base-band support in 'dvb-core' of V4L. also, it's really good that SAA716x code seems to just work with BBFrames and no further changes are required there. kind regards, konstantin On Sat, Feb 18, 2012 at 9:06 PM, Christian Prähauser cpraeh...@cosy.sbg.ac.at wrote: Hello Konstantin! I was on holiday, so no problem at all. I wanted to tell you that I managed to get the base-band demux working with the TBS6925 card. Actually, I needed to modify the configuration of the STV0900 packet delineator to switch the circuit to frame mode. The SAA716x PCI adapter chip seems to forward the base-band frame without errors. I haven't verified if all frames are received, will do that in the next couple of days. From that point on, I'm going to complete some open issues and clean up the rest of the stuff and open a public repository for the bb-demux. Thanks for the link to the MIS filter patch. I will include it in the base-band filtering code and try to enhance it to support filtering on multiple ISIs, as the STV0900 seems to support this. Thanks and kind regards, Christian. Am 01.02.2012 um 19:49 schrieb Konstantin Dimitrov: hi Christian, sorry for the very late reply - unfortunately i'm very busy lately. so, what i can tell you about your questions: * for setting MIS filter you can follow the link in the first email that started the discussion here: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/42312 or more specifically what's posted here: http://www.tbsdtv.com/forum/viewtopic.php?f=26t=1874 i don't know if you have access to some signal modulator/generator with MIS support, but if not there are several good live MIS signals, e.g. Atlantic Bird 1 @ 12.5 W, 12718 H, 36510, FEC 5/6 it's 8PSK MIS transponder with four TS, ISIs of them are: 33, 34, 35 36 if you can't get 12.5W let me know and i will look for some other live signal useful for test purposes. * STV900AAC needs to be put on BBFrame mode, by default it strips the BB data and outputs TS. however, the necessary settings for are BBFrame mode not very clear - i need to do some trial and errors until i hopefully get the BBFrame mode working. however, what is useful as a starter is to parse/analyze for errors data dump made in Windows with TBS Recorder tool - i believe i mentioned it to you - the data dump made with that tool seems as valid BBFrames at least at first glance with hex-editor, i.e. valid BBHeader data are observed. so, is there some tool from your work (maybe 'bb-demux') that can parse/analyze data dump of supposedly BBFrames. anyway, let me know what help you need - i will look at BBFrame mode for STV900AAC, because i can identify that task as open. best wishes, konstantin On Wed, Jan 25, 2012 at 3:12 PM, Christian Prähauser cpraeh...@cosy.sbg.ac.at wrote: Hi Konstantin! I received your present :-) - many thanks! I already ported my base-band demux code to the current linux media master branch (in the v4l-dvb git repo). It currently allows drivers/frontends to pass base-band frames to the bb-demux. The bb-demux allows user-space filtering for BBFrames, TS packets, etc via the demux handle or dvr device. It also allows other kernel components to do base-band filtering (e.g. receive BBFrames on a specific ISI). Currently, the bb-demux only accepts a single, complete BBFrame in a single buffer, but I think it should also be able to cope with a stream of data (for ease of driver integration), including synchronization (search for frame start) and buffering (for assembling frames). Besides checking whether the current user-space API for base-band filtering is useful, there are a few remaining design questions to think about: * How to allow pes/section filtering when receiving multiple TSs in parallel (on different ISIs) - allow to stack filters, e.g. a bb-demux filter delivers TS from a certain ISI and forwards it to a section filter (which then passes sections to user-space). - dmx / dvr device for each? * When and how to bring frontend into base-band data mode (a mode where it delivers BBFrames instead of TS)? - Should this be set by the user or happen automatically? * How to set ISI on demux if we receive TS on a channel with MIS (if this is not already possible, didn't check it yet) - this could be covered by the bb-demux filtering API, although the base-band demux is not directly involved in this case (since TS data is delivered to dvb-core). For now, I'm working to setup a public GIT repository, so you can have a look at the current status. Do you have
Re: Re: Mystique SaTiX-S2 Sky Xpress DUAL card
hello, and what's exactly the different in 'm88ds3103.c' then your approach before - you just do the same and now even remove my name from the copyright, which is really ridiculous because almost all of your code is copypaste from my code inside 'ds3000.c'. so, in 'm88ds3103.c' you take 'ds3000.c' code, make some small patches to add ds3103 support, which are mainly one array of initialization values and even this time remove my name from the copyright, while 90% of the code inside 'm88ds3103.c' is made by me - you even leave my comments from the 'ds3000.c' code letter by letter. so, if you want to claim copyright, please develop your own code that doesn't use like 90% (and even more) of mine code. On Mon, Feb 13, 2012 at 5:28 PM, nibble.max nibble@gmail.com wrote: Hello Konstantin, I think Bestunar do make the two wrong things. One, they put the copyright without your permission. But I doute that you copy and paste the Montage Technology's reference code and why not put Montage copyright? Two, they write the code based on the ds3000.c file which you created, even they enhance and fix some bugs. They build the products based on Montage Technology advanced M88DS3103 chip, which is totally a new chip different from old ds3000. And they are the first company to adopt this new chip on the Satellite DVB-S2 tuner cards. They do the right thing now that create a new file named m88ds3103.c for the new chip in linux media tree. http://www.dvbsky.net/download/bst-patch.tar.gz Br, 2012-02-13 nibble.max 发件人： Konstantin Dimitrov 发送时间： 2011-12-29 18:25:37 收件人： Andreas Mair 抄送： linux-media 主题： Re: Mystique SaTiX-S2 Sky Xpress DUAL card hello Andreas, i've checked the Linux drivers for the card you referred to and whoever made it is breaking all the rules claiming copyright over the whole driver adding at the beginning: Copyright (C) 2010 Bestunar Inc. when they just patched the driver very slightly adding only new initialization values - if they wish they can claim copyright only over those small changes (even they are just number constants provided by the chip maker). in any case that's ridiculous, because i made that driver and the copyright notice is: http://git.linuxtv.org/media_tree.git/blob/61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf:/drivers/media/dvb/frontends/ds3000.c Montage Technology DS3000/TS2020 - DVBS/S2 Demodulator/Tuner driver Copyright (C) 2009 Konstantin Dimitrov kosio.dimit...@gmail.com Copyright (C) 2009 TurboSight.com and i strongly opposed that copyright massage can be changed in the way like they did especially over the changes they made. also, the whole 'ds3000' driver, even it's licensed under GPL, was submitted to the Linux kernel without my formal permission that to be done, i.e. you can think for that as it was leaked to the Linux kernel from third-parties and not the driver author and copyright-holder. so, it seems to me Bestunar Inc is some obscure Chinese company most probably cloning hardware rather than spent any time doing development, which or course also don't honor the work put in development of open-source driver for the chips they're using and try very hard to make it look like they did it or that they did something more significant than what they actually did. i'm sure you can understand my position and my opinion that such companies shouldn't be supported in any possible way. best regards, konstantin On Thu, Dec 29, 2011 at 11:07 AM, Andreas Mair amair@googlemail.com wrote: Hello, I'm using that card in my Linux VDR box: http://www.dvbshop.net/product_info.php/info/p2440_Mystique-SaTiX-S2-Sky-Xpress-DUAL--USALS--DiseqC-1-2--Win-Linux.html That's the lspci output: === SNIP = $ lspci -vvvnn 02:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02) Subsystem: Device [4254:0952] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at fe40 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
Re: DVB-S2 multistream support
hi Christian, sorry for the very late reply - unfortunately i'm very busy lately. so, what i can tell you about your questions: * for setting MIS filter you can follow the link in the first email that started the discussion here: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/42312 or more specifically what's posted here: http://www.tbsdtv.com/forum/viewtopic.php?f=26t=1874 i don't know if you have access to some signal modulator/generator with MIS support, but if not there are several good live MIS signals, e.g. Atlantic Bird 1 @ 12.5 W, 12718 H, 36510, FEC 5/6 it's 8PSK MIS transponder with four TS, ISIs of them are: 33, 34, 35 36 if you can't get 12.5W let me know and i will look for some other live signal useful for test purposes. * STV900AAC needs to be put on BBFrame mode, by default it strips the BB data and outputs TS. however, the necessary settings for are BBFrame mode not very clear - i need to do some trial and errors until i hopefully get the BBFrame mode working. however, what is useful as a starter is to parse/analyze for errors data dump made in Windows with TBS Recorder tool - i believe i mentioned it to you - the data dump made with that tool seems as valid BBFrames at least at first glance with hex-editor, i.e. valid BBHeader data are observed. so, is there some tool from your work (maybe 'bb-demux') that can parse/analyze data dump of supposedly BBFrames. anyway, let me know what help you need - i will look at BBFrame mode for STV900AAC, because i can identify that task as open. best wishes, konstantin On Wed, Jan 25, 2012 at 3:12 PM, Christian Prähauser cpraeh...@cosy.sbg.ac.at wrote: Hi Konstantin! I received your present :-) - many thanks! I already ported my base-band demux code to the current linux media master branch (in the v4l-dvb git repo). It currently allows drivers/frontends to pass base-band frames to the bb-demux. The bb-demux allows user-space filtering for BBFrames, TS packets, etc via the demux handle or dvr device. It also allows other kernel components to do base-band filtering (e.g. receive BBFrames on a specific ISI). Currently, the bb-demux only accepts a single, complete BBFrame in a single buffer, but I think it should also be able to cope with a stream of data (for ease of driver integration), including synchronization (search for frame start) and buffering (for assembling frames). Besides checking whether the current user-space API for base-band filtering is useful, there are a few remaining design questions to think about: * How to allow pes/section filtering when receiving multiple TSs in parallel (on different ISIs) - allow to stack filters, e.g. a bb-demux filter delivers TS from a certain ISI and forwards it to a section filter (which then passes sections to user-space). - dmx / dvr device for each? * When and how to bring frontend into base-band data mode (a mode where it delivers BBFrames instead of TS)? - Should this be set by the user or happen automatically? * How to set ISI on demux if we receive TS on a channel with MIS (if this is not already possible, didn't check it yet) - this could be covered by the bb-demux filtering API, although the base-band demux is not directly involved in this case (since TS data is delivered to dvb-core). For now, I'm working to setup a public GIT repository, so you can have a look at the current status. Do you have a repository for the TBS drivers or should I use the official ones? Do you have an idea of how to program the STV900 to output BBFrames? Thanks again and kind regards, Christian. Am 17.01.2012 um 21:04 schrieb Konstantin Dimitrov: hi Christian, it's great that you find it interesting too. i already prepared the package and i will send it tomorrow - you should get in shorty - i believe even with the most inexpensive shipping service within Europe you will get in just a week or so. i hope you will have fun with the TBS 6925 board - even if not for anything else just to receive DVB-S2 in Linux. kind regards, konstantin On Thu, Jan 12, 2012 at 3:06 PM, Christian Prähauser cpraeh...@cosy.sbg.ac.at wrote: Hi Konstantin! Thank you, and a happy new year to you too! The way to proceed you suggested sounds very interesting too me! I'd be more than happy if you could send me the TBS 6925 card to my university address: Christian Prähauser c/o Department of Computer Sciences University of Salzburg Jakob Haringer Str. 2 A 5020 Salzburg AUSTRIA I will start to update my patches to match recent LinuxDVB sources and try to integrate Baseband demux support into the TBS linux driver. If this works, we can also put in GSE-support (S2-native encapsulation for carrying IP packets in DVB). This would then probably start to be interesting for some people... Thanks and kind regards, Christian. Am 10.01.2012 um 20:40 schrieb Konstantin
Re: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
hi, does your DVB card can get signal lock when it's inserted into the PCI-to-PCIE adapter, because as far as i know most PCI-to-PCIE adapters based on PEX 8111/8112 don't provide power to 12V pins of the PCI interface, which probably all PCI DVB card use for LNB power. so, what i would check if i'm at your position is the LNB power of the card as well as if there is no some extensive amount of noise in the LNB power when the DVB card is inside PEX 8111/8112 PCI-to-PCIE adapter. also, i can give you example from my own experience with an Audiotrak Prodigy HD2 PCI audio card and PEX 8111/8112 based PCI-to-PCIE adapters - with one such adapter that don't provide power to 12V pins of the PCI interface there is no sound coming out, because the amplifier on the card uses power from 12V pins of the PCI interface, with another PEX 8111/8112 PCI-to-PCIE adapter that seems to provide power to 12V pins there is extensive noise in the sound that is coming out, because PCI-to-PCIE adapter doesn't provide good power on 12V pins of the PCI interface and thus the noise in the audio. also, on some motherboards (with nVidia chipset on my tests) there was some problem with how the memory was mapped preventing the work of the PCI card when it's inserted into PEX 8111/8112 based PCI-to-PCIE adapter. so, it's also helpful to test motherboards with different chipset. in any case it's always better to find and use native PCI-Express card instead of PEX 8111/8112 PCI-to-PCIE adapter and PCI card. anyway, maybe, someone with more hardware engineering knowledge then i have, especially if the problem is 12V can find some way to fix those cheap PEX 8111/8112 PCI-to-PCIE adapters that are floating around, because i'm sure they just sacrifice 12V power to lower the BOM cost of the adapter. BTW, i'm sure your firewire card is working, because it doesn't use 12V PCI interface pins - it's the same with many PCI cards, but all that needs 12V are no-go based on my experience. --konstantin On Mon, Feb 14, 2011 at 1:35 PM, Dennis Kurten dennis.kur...@gmail.com wrote: Hello, This card (technisat cablestar hd 2 dvb-c) works fine when plugged into a native PCI slot. When I try it with a PCI-adapter I intend to use in mITX-builds there doesn't seem to be any data coming in through the tuner. The adapter is a transparent bridge (with a PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through a 4-pin molex. My guess is some kind of dma mapping incompatibility with the mantis driver (s2-liplianin). The card seems to initialize correctly, but doesn't work when the tuner is put into action (scandvb timeouts, dvbtraffic yields nothing). For the record, I've tested the bridge with a firewire card and that works fine. Kernel is 2.6.32 (+the compiled drivers) lspci for the bridge and the card: -- 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=03, secondary=04, subordinate=04, sec-latency=32 I/O behind bridge: e000-efff Memory behind bridge: fdd0-fddf Prefetchable memory behind bridge: fdc0-fdcf Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat+ DiscTmrSERREn- Capabilities: access denied Kernel modules: shpchp 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) Subsystem: Device 1ae4:0002 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort+ MAbort- SERR- PERR- INTx- Latency: 32 (2000ns min, 63750ns max) Interrupt: pin A routed to IRQ 16 Region 0: Memory at fdcff000 (32-bit, prefetchable) [size=4K] Kernel driver in use: Mantis Kernel modules: mantis dmesg output with modules loaded: - Mantis :04:00.0: PCI INT A - Link[APC7] - GSI 16 (level, low) - IRQ 16 irq: 16, latency: 32 memory: 0xfdcff000, mmio: 0xc900031a found a VP-2040 PCI DVB-C device on (04:00.0), Mantis Rev 1 [1ae4:0002], irq: 16, latency: 32 memory: 0xfdcff000, mmio: 0xc900031a MAC Address=[00:08:c9:d0:46:b4] mantis_alloc_buffers (0): DMA=0x1bb9 cpu=0x88001bb9 size=65536 mantis_alloc_buffers (0): RISC=0x1bbec000 cpu=0x88001bbec000 size=1000 DVB: registering new adapter (Mantis dvb adapter)
Re: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
oh, i have just noticed your DVB card is for Cable and not for Satellite, but still it may use 12V PCI interface pins for something else and not exactly for LNB power as i thought assuming it's DVB-S/S2 DVB card. On Tue, Feb 15, 2011 at 10:18 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: hi, does your DVB card can get signal lock when it's inserted into the PCI-to-PCIE adapter, because as far as i know most PCI-to-PCIE adapters based on PEX 8111/8112 don't provide power to 12V pins of the PCI interface, which probably all PCI DVB card use for LNB power. so, what i would check if i'm at your position is the LNB power of the card as well as if there is no some extensive amount of noise in the LNB power when the DVB card is inside PEX 8111/8112 PCI-to-PCIE adapter. also, i can give you example from my own experience with an Audiotrak Prodigy HD2 PCI audio card and PEX 8111/8112 based PCI-to-PCIE adapters - with one such adapter that don't provide power to 12V pins of the PCI interface there is no sound coming out, because the amplifier on the card uses power from 12V pins of the PCI interface, with another PEX 8111/8112 PCI-to-PCIE adapter that seems to provide power to 12V pins there is extensive noise in the sound that is coming out, because PCI-to-PCIE adapter doesn't provide good power on 12V pins of the PCI interface and thus the noise in the audio. also, on some motherboards (with nVidia chipset on my tests) there was some problem with how the memory was mapped preventing the work of the PCI card when it's inserted into PEX 8111/8112 based PCI-to-PCIE adapter. so, it's also helpful to test motherboards with different chipset. in any case it's always better to find and use native PCI-Express card instead of PEX 8111/8112 PCI-to-PCIE adapter and PCI card. anyway, maybe, someone with more hardware engineering knowledge then i have, especially if the problem is 12V can find some way to fix those cheap PEX 8111/8112 PCI-to-PCIE adapters that are floating around, because i'm sure they just sacrifice 12V power to lower the BOM cost of the adapter. BTW, i'm sure your firewire card is working, because it doesn't use 12V PCI interface pins - it's the same with many PCI cards, but all that needs 12V are no-go based on my experience. --konstantin On Mon, Feb 14, 2011 at 1:35 PM, Dennis Kurten dennis.kur...@gmail.com wrote: Hello, This card (technisat cablestar hd 2 dvb-c) works fine when plugged into a native PCI slot. When I try it with a PCI-adapter I intend to use in mITX-builds there doesn't seem to be any data coming in through the tuner. The adapter is a transparent bridge (with a PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through a 4-pin molex. My guess is some kind of dma mapping incompatibility with the mantis driver (s2-liplianin). The card seems to initialize correctly, but doesn't work when the tuner is put into action (scandvb timeouts, dvbtraffic yields nothing). For the record, I've tested the bridge with a firewire card and that works fine. Kernel is 2.6.32 (+the compiled drivers) lspci for the bridge and the card: -- 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=03, secondary=04, subordinate=04, sec-latency=32 I/O behind bridge: e000-efff Memory behind bridge: fdd0-fddf Prefetchable memory behind bridge: fdc0-fdcf Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat+ DiscTmrSERREn- Capabilities: access denied Kernel modules: shpchp 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) Subsystem: Device 1ae4:0002 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort+ MAbort- SERR- PERR- INTx- Latency: 32 (2000ns min, 63750ns max) Interrupt: pin A routed to IRQ 16 Region 0: Memory at fdcff000 (32-bit, prefetchable) [size=4K] Kernel driver in use: Mantis Kernel modules: mantis dmesg output with modules loaded: - Mantis :04:00.0: PCI INT A - Link[APC7] - GSI 16 (level, low) - IRQ 16 irq: 16, latency: 32 memory: 0xfdcff000, mmio: 0xc900031a found a VP-2040 PCI DVB-C device on (04:00.0), Mantis Rev 1
Re: DVB-T2 tuner dismantled: PCTV Nanostick T2 290e
On Wed, Nov 24, 2010 at 6:44 PM, st...@stevekerrison.com wrote: - it looks like the demod is the only new piece of hardware to deal with and actually it makes DVB-T2 performance of that device very questionable (at least in my opinion), because NXP silicon tuner TDA18271 is old model and not DVB-T2 ready: http://www.nxp.com/#/pip/pip=[pip=TDA18271HD]|pp=[t=pip,i=TDA18271HD] like the new DVB-T2 ready NXP silicon tuner TDA18272: http://www.nxp.com/#/pip/pip=[pip=TDA18272HN_SDS]|pp=[t=pip,i=TDA18272HN_SDS] and so it's quite reasonable to assume that old silicon tuner designed for DVB-T such as TDA18271 is not capable to provide optimal performance for DVB-T2, which has high requirements for sure. --konstantin -- 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
On Mon, May 31, 2010 at 5:05 AM, Emmanuel eall...@gmail.com wrote: Konstantin Dimitrov a écrit : hello, i can't comment on your questions about the Wiki, but i made the driver for TBS 6980 and i can ensure you that the driver will be released as open-source under GPL as soon as i have permission to do that, but compared to other cards at least even at the moment you can use the card in Linux and it's very easy to add support for it using the binary modules even to the latest V4L code from repository and so those blobs are actually not so big limitation. also, you are very wrong about the price - as far as i know retails price is less than 200 USD, for example TBS online shop gives a price of 158.99 USD: http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html and i believe the dual DVB-S2 card with price of 1000 USD that you're talking about is the NetUP one and not the TurboSight TBS 6980 dual DVB-S2 card. I have two questions for you: do these board support (or will support in the near future) a CI interface for pay TV, and what is the best symbol rate they can achieve in DVB-S2 (I think I need QPSK only but could be 8PSK) TBS 6980 specifications are: DVB-S QPKS: 1000 - 45000 kSps DVB-S2 QPSK and 8PSK: 2000 - 36000 kSps but i personally have tested DVB-S2 8PSK up to 33500 kSps and it works fine. so, DVB-S2 symbol rate range is still better than what most other cards can offer i believe, which usually support 1 - 3 kSps for DVB-S2. TBS are developing card that will support 1000 - 45000 kSps for DVB-S2 (both QPSK and 8PSK), but i believe it won't be released any time soon. RELIABLY. TIA Bye Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
hello, i can't comment on your questions about the Wiki, but i made the driver for TBS 6980 and i can ensure you that the driver will be released as open-source under GPL as soon as i have permission to do that, but compared to other cards at least even at the moment you can use the card in Linux and it's very easy to add support for it using the binary modules even to the latest V4L code from repository and so those blobs are actually not so big limitation. also, you are very wrong about the price - as far as i know retails price is less than 200 USD, for example TBS online shop gives a price of 158.99 USD: http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html and i believe the dual DVB-S2 card with price of 1000 USD that you're talking about is the NetUP one and not the TurboSight TBS 6980 dual DVB-S2 card. --konstantin On Sat, May 29, 2010 at 5:16 AM, Another Sillyname anothersn...@googlemail.com wrote: Guys The TBS 6920 PCI-e card is in the Wiki and is a supported card. The TBS 6980 dual tuner PCI-e card is not in the Wiki at all, is there a reason for this given they have released a non GPL blob at least? Also is there a reason that an indicative price for supported cards is not shown in the wiki? It would save a load of time rather then having to search on each card only to find out it's ridiculously priced at $1000. Thanks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: What ever happened to standardizing signal level?
at least in driver for the frontend found on TBS 6980 Dual DVB-S2 card i added options esno and dbm respectively for reporting SNR (actually C/N) in EsNo dB and signal strength in dBm, which is at least real statistics about the signal and not like almost meaningless percents. so, that's one way to go. some DVB-S/S2 demodulators use EsNo dB and other EbNo dB and so maybe step toward some standardization is routines for conversion between those two. also, maybe there will be common agreement how to convert signal strength in dBm to percents and SNR (C/N) in EsNo or EbNo dB to percents. i believe that will guarantee more standard way to give information about the signal, but it's just my opinion. On Sat, May 29, 2010 at 6:09 AM, VDR User user@gmail.com wrote: A lot of people were anticipating this happening but it seems to have stalled out. Does anyone know what the intentions are? Many users were also hoping to _finally_ get a good signal meter for linux as well. If anyone has any info, please share! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
full TS in Linux: known issue or new one?
hello All, the issue in question is that in case full TS is captured immediately after lock ( without some delay ) then garbage data ( that don't belong to the TS ) are introduced in the stream. initially Michael Repplinger noticed the problem and told me about it. also, he made test script ( 'run_szap-s2_adapter0_record_dvbsnoop.sh' ) for reproducing the problem easily ( you can find it in the attachment, i made some very small changed to it compared to the original script). so, basically, the test script 'szap-s2' to first transponder in your 'channel.conf' file, use 'dvbsnoop' to dump the full TS from that transponder to a file for 30 seconds, then 'szap-s2' to second transponder in your 'channel.conf' file, use 'dvbsnoop' again to dump the full TS to another file for 30 seconds and repeats this in endless loop. if there is no delay ( 'sleep 0' ) or delay is less than 5 seconds ( at least on my setup those are delays i measured ) between executing 'szap-s2' and 'dvbsnoop' then captured stream contains some additional data that don't belong there, i.e. garbage and you can confirmed it with any TS analyzer tool or just use the attached 'test_file_with_dvbsnoop.sh' that Michael Repplinger prepared. i've already tested about 10 DVB devices from different manufacturers using completely different chips and PCI or PCIe interface and even USB interface, just for completeness here is what i've already tested: - Philips/NXP SAA7146 bridge driver - B2C2 Flexcop IIb PCI bridge driver (put in full TS mode with 'options b2c2_flexcop_pci enable_pid_filtering=0') - Booktree bt8xx bridge driver - Conexant cx88 bridge driver - Conexant cx23885 bridge driver - all USB DVB devices i have (all of them use Cypress USB controller) and with all of the above i can reproduce the problem using 'run_szap-s2_adapter0_record_dvbsnoop.sh' script. however, it seems SAA7146 is somehow better than the others, because sometimes it works good, i.e. captures correct data even without any delay between executing 'szap-s2' and 'dvbsnoop'. so, any ideas, please, either for what could be the root cause for the problem or for acceptable workaround? it seems to me at least at the moment it's a general problem with Linux DVB, but maybe it's known issue and someone knows more about it. many thanks, konstantin test_file_with_dvbsnoop.sh Description: Bourne shell script run_szap-s2_adapter0_record_dvbsnoop.sh Description: Bourne shell script
Re: CI USB
On Sun, Jan 24, 2010 at 10:12 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 11:49 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) No CI+ in there ... Generic USB bridge with microcontroller and possibly a FPGA programmed by Hauppauge themselves, most probably. The no, the whole Hauppauge device is actually made by SmartDTV even on the board there is a title SmartDTV Rev... also, Terratec device is the same as Hauppauge device, they even look the same: http://www.terratec.net/en/products/Cinergy_CI_USB_2296.html and Terratec driver for Windows says Copyright SmarDTV., which means it's made by SmarDTV. actually, Terratec driver for Windows is essentially the same as Hauppauge one, because firmware extracted from both drivers is the same (they update the firmware with driver updates, so matching versions of Terratec and Hauppauge driver is needed to check that the firmwares are the same). bridge would be similar to other DVB USB devices, Application on the FPGA would be more or less similar to the one found on general DVB CI devices. If it's not a Masked FPGA, it would need to load it's instructions some place, maybe an EEPROM or maybe from the firmware that you need load itself. Some part of the firmware that you load could be partly for the microcontroller on the USB bridge as well. i believe that 40 A3 firmware requests are for the USB controller and then the subsequent 40 A3 firmware requests are to load the FPGA instructions through the USB controller. Manu -- 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: CI USB
On Sun, Jan 24, 2010 at 10:54 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 10:12 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 11:49 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) No CI+ in there ... Generic USB bridge with microcontroller and possibly a FPGA programmed by Hauppauge themselves, most probably. The no, the whole Hauppauge device is actually made by SmartDTV even on the board there is a title SmartDTV Rev... also, Terratec device is the same as Hauppauge device, they even look the same: http://www.terratec.net/en/products/Cinergy_CI_USB_2296.html and Terratec driver for Windows says Copyright SmarDTV., which means it's made by SmarDTV. actually, Terratec driver for Windows is essentially the same as Hauppauge one, because firmware extracted from both drivers is the same (they update the firmware with driver updates, so matching versions of Terratec and Hauppauge driver is needed to check that the firmwares are the same). bridge would be similar to other DVB USB devices, Application on the FPGA would be more or less similar to the one found on general DVB CI devices. If it's not a Masked FPGA, it would need to load it's instructions some place, maybe an EEPROM or maybe from the firmware that you need load itself. Some part of the firmware that you load could be partly for the microcontroller on the USB bridge as well. i believe that 40 A3 firmware requests are for the USB controller typo, 40 A0 firmware requests are for the USB controller and then the subsequent 40 A3 firmware requests are to load the FPGA instructions through the USB controller. Manu -- 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: CI USB
On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CI USB
On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) also, i can confirm that firmware extractor here: http://www.bsc-bvba.be/linux/dvb/ is correct at least for A2 hardware (but A1 hardware is no longer in production anyway), because a long time ago i verified with spying the USB traffic what firmware is uploaded in Windows for A2 hardware and informed Luc Brosens and he fixed his firmware extractor tool. however, it seems that the main problem as it's mentioned by Luc Brosens is why firmware upload fails in Linux, because according to Steven Toth words: * http://www.linuxtv.org/pipermail/linux-dvb/2008-April/025284.html * I also looked at the USB traffic on the current Hauppauge driver, with a * cam inserted and decryption happening. The protocol appears pretty simple. after the firmware is uploaded is easy to figure out how to send commands to the device. Regards, Manu -- 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-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name
On Mon, Sep 7, 2009 at 9:06 AM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Mon, 7 Sep 2009 01:20:33 -0400 Michael Krufky mkru...@kernellabs.com escreveu: On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 4 Sep 2009 14:05:31 -0400 Michael Krufky mkru...@kernellabs.com escreveu: Mauro, This fix should really go to Linus before 2.6.31 is released, if possible. It also should be backported to stable, but I need it in Linus' tree before it will be accepted into -stable. Do you think you can slip this in before the weekend? As I understand, Linus plans to release 2.6.31 on Saturday, September 5th. If you dont have time for it, please let me know and I will send it in myself. This patch doesn't apply upstream: $ patch -p1 -i 12613.patch patching file drivers/media/video/cx25840/cx25840-firmware.c Hunk #5 FAILED at 107. 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re OK, this is going to need a manual backport. This does fix an issue in 2.6.31, and actually affects all kernels since the appearance of the cx23885 driver, but I can wait until you push it to Linus in the 2.6.32 merge window, then I'll backport test it for -stable. Ok. I think I asked you once, but let me re-ask again: from what I was told, the latest cx25840 firmware (the one that Conexant give us the distribution rights) seems to be common to several cx25840-based chips. It would be really good if i also noticed that 3 firmwares with different file names and used by different drivers: - v4l-cx23418-dig.fw used by cx18 driver, available here: http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz and includes notice about distribution permission from Conexant too - v4l-cx23885-avcore-01.fw used by cx23885 driver - v4l-cx25840.fw used by cx25840 driver have exactly the same md5sum: b3704908fd058485f3ef136941b2e513 and actually are the same firmware. we can test it with all devices, especially since distros will add it on their firmware packages, as they are at the firmware -git Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] cx23885: fix support for TBS 6920 card
On Thu, Aug 20, 2009 at 4:03 PM, Steven Tothst...@kernellabs.com wrote: On 8/19/09 7:20 PM, Konstantin Dimitrov wrote: fix: GPIO initialization for TBS 6920 fix: wrong I2C address for demod on TBS 6920 fix: wrong I2C bus number for demod on TBS 6920 fix: wrong gen_ctrl_val value for TS1 port on TBS 6920 (and some other cards) add: module_param lnb_pwr_ctrl as option to choose between type 0 and type 1 of LNB power control (two TBS 6920 boards no matter that they are marked as the same hardware revision may have different types of LNB power control) fix: LNB power control function for type 0 doesn't preserve the previous GPIO state, which is critical add: LNB power control function for type 1 Signed-off-by: Bob Liub...@turbosight.com Signed-off-by: Konstantin Dimitrovkosio.dimit...@gmail.com I got a weird HTML related email bounce from vger when I responded originally to this via gmail. Maybe this time via thunderbird will bring success. ... Hmm. A custom hanging off of a gpio to something that looks like an i2c power control device. I want to review some of these generic (and no-so-generic) changes before we merge this patch. Is the datasheet for the LNB power control device available to the public? I'd like to understand some of the register details. the datasheet is not available at least to me and i don't know any more details. the code in question was given to me by the author under GPLv2 license and that's why i put it in separate file tbs_lnb_pwr.c. also, the cards that use this type of LNB power control, which i called for short type 1, have the same device IDs as the one that don't use it and use type 0 of LNB power control instead. --konstantin Thanks, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] cx23885: fix support for TBS 6920 card
fix: GPIO initialization for TBS 6920
fix: wrong I2C address for demod on TBS 6920
fix: wrong I2C bus number for demod on TBS 6920
fix: wrong gen_ctrl_val value for TS1 port on TBS 6920 (and some other cards)
add: module_param lnb_pwr_ctrl as option to choose between type 0 and type
1 of LNB power control (two TBS 6920 boards no matter that they are marked as
the same hardware revision may have different types of LNB power control)
fix: LNB power control function for type 0 doesn't preserve the previous GPIO
state, which is critical
add: LNB power control function for type 1
Signed-off-by: Bob Liu b...@turbosight.com
Signed-off-by: Konstantin Dimitrov kosio.dimit...@gmail.com
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-08-19
14:11:49.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-08-19
14:30:10.0 +0300
@@ -704,7 +704,14 @@ void cx23885_gpio_setup(struct cx23885_d
case CX23885_BOARD_TEVII_S470:
cx_write(MC417_CTL, 0x0036);
cx_write(MC417_OEN, 0x1000);
- cx_write(MC417_RWD, 0x1800);
+
+ cx_set(MC417_RWD, 0x0002);
+ mdelay(200);
+
+ cx_clear(MC417_RWD, 0x0800);
+ mdelay(200);
+ cx_set(MC417_RWD, 0x0800);
+ mdelay(200);
break;
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
/* GPIO-0 INTA from CiMax1
@@ -880,7 +887,7 @@ void cx23885_card_setup(struct cx23885_d
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_TBS_6920:
case CX23885_BOARD_DVBWORLD_2005:
- ts1-gen_ctrl_val = 0x5; /* Parallel */
+ ts1-gen_ctrl_val = 0x4; /* Parallel */
ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c 2009-08-19
14:11:49.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c 2009-08-19
15:25:57.0 +0300
@@ -55,6 +55,7 @@
#include netup-eeprom.h
#include netup-init.h
#include lgdt3305.h
+#include tbs_lnb_pwr.h
static unsigned int debug;
@@ -71,6 +72,10 @@ MODULE_PARM_DESC(alt_tuner, Enable alte
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+static unsigned int lnb_pwr_ctrl;
+module_param(lnb_pwr_ctrl, int, 0644);
+MODULE_PARM_DESC(lnb_pwr_ctrl,set LNB power control 0=default type, 1=another
type);
+
/* -- */
static int dvb_buf_setup(struct videobuf_queue *q,
@@ -419,22 +424,31 @@ static struct stv6110_config netup_stv61
.clk_div = 1,
};
-static int tbs_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
+static int tbs6920_set_voltage(struct dvb_frontend *fe,
+ fe_sec_voltage_t voltage)
{
struct cx23885_tsport *port = fe-dvb-priv;
struct cx23885_dev *dev = port-dev;
- if (voltage == SEC_VOLTAGE_18)
- cx_write(MC417_RWD, 0x1e00);/* GPIO-13 high */
- else if (voltage == SEC_VOLTAGE_13)
- cx_write(MC417_RWD, 0x1a00);/* GPIO-13 low */
- else
- cx_write(MC417_RWD, 0x1800);/* GPIO-12 low */
+ switch (voltage) {
+ case SEC_VOLTAGE_13:
+ cx_set(MC417_RWD, 0x0200);
+ cx_clear(MC417_RWD, 0x0400);
+ break;
+ case SEC_VOLTAGE_18:
+ cx_set(MC417_RWD, 0x0200);
+ cx_set(MC417_RWD, 0x0400);
+ break;
+ case SEC_VOLTAGE_OFF:
+ cx_clear(MC417_RWD, 0x0200);
+ break;
+ }
+
return 0;
}
static struct cx24116_config tbs_cx24116_config = {
- .demod_address = 0x05,
+ .demod_address = 0x55,
};
static struct cx24116_config tevii_cx24116_config = {
@@ -768,14 +782,18 @@ static int dvb_register(struct cx23885_t
}
break;
case CX23885_BOARD_TBS_6920:
- i2c_bus = dev-i2c_bus[0];
+ i2c_bus = dev-i2c_bus[1];
fe0-dvb.frontend = dvb_attach(cx24116_attach,
tbs_cx24116_config,
i2c_bus-i2c_adap);
- if (fe0-dvb.frontend != NULL)
- fe0-dvb.frontend-ops.set_voltage = tbs_set_voltage;
-
+ if (fe0-dvb.frontend != NULL) {
+ if (!lnb_pwr_ctrl)
+ fe0-dvb.frontend-ops.set_voltage =
tbs6920_set_voltage;
+ else
+ fe0-dvb.frontend-ops.set_voltage =
tbs_set_voltage;
+ }
+
break;
case CX23885_BOARD_TEVII_S470:
i2c_bus = dev-i2c_bus[1];
@@ -784,7 +802,7 @@ static int dvb_register(struct cx23885_t
