Beiträge von oliv3r

Hey all,

I've been using the 'newly' integrated driver with the 4.20 kernel for quite a while without much trouble for almost a year now.

However today, I tried to upgrade to 5.5.6 (the latest that ships with gentoo) and while the driver compiles and loads fine, probing fails two fold.

First, it cannot find the symbol for the tuner: DVB: Unable to find symbol stv090x_attach(), which is very supprising because a) it's an exported symbol, if I run 'strings' on the module itself, the symbol shows up (as wel as with nm stv090x_attach). If I unload ddbridge and dvb_core, manually load stv090x, the module loads quietly, but when loading ddbridge, it still complains about the missing symbol.

The output frmo ddbridge is as follows:

[ 524.443650] ddbridge: Digital Devices PCIE bridge driver 0.9.33-integrated, Copyright (C) 2010-17 Digital Devices GmbH

[ 524.444121] ddbridge 0000:06:00.0: detected Digital Devices Octopus Mini

[ 524.444288] ddbridge 0000:06:00.0: HW 00010007 REGMAP 00010003

[ 524.444452] ddbridge 0000:06:00.0: using 1 MSI interrupt(s)

[ 524.445730] ddbridge 0000:06:00.0: Port 0: Link 0, Link Port 0 (TAB 1): DUAL DVB-S2

[ 524.447941] ddbridge 0000:06:00.0: Port 1: Link 0, Link Port 1 (TAB 2): NO MODULE

[ 524.449123] ddbridge 0000:06:00.0: Port 2: Link 0, Link Port 2 (TAB 3): NO MODULE

[ 524.450262] ddbridge 0000:06:00.0: Port 3: Link 0, Link Port 3 (TAB 4): NO MODULE

[ 524.450865] dvbdev: DVB: registering new adapter (DDBridge)

[ 524.450937] dvbdev: DVB: registering new adapter (DDBridge)

[ 524.454132] DVB: Unable to find symbol stv090x_attach()

[ 524.454235] ddbridge 0000:06:00.0: No STV0900 found!

[ 524.454690] ddbridge 0000:06:00.0: port_attach on port 0 failed

[ 524.454797] ddbridge 0000:06:00.0: All connected ports failed to initialise!

[ 524.454907] ddbridge 0000:06:00.0: fail3

[ 524.455028] ddbridge 0000:06:00.0: fail2

[ 524.455288] ddbridge 0000:06:00.0: fail1

[ 524.455408] ddbridge 0000:06:00.0: fail0

[ 524.455554] ddbridge 0000:06:00.0: fail

[ 524.455817] ddbridge: probe of 0000:06:00.0 failed with error -1

which is of course no supprise that it can't find a port to initialize. Searching for the error message, I do find it quite a few times, and I do see some rework on the media driver that could have caused this, but I would expect that all users of the stv090x driver would be updated as well.

eb5005df886b (media: stv090x: Implement probe/remove for stv090x, 2019-05-29)

So if anything knows anything, about where to start poking, that'd be great!

Hi,

I just upgraded from UFO's media-build-experimental on 4.5.0 to the dddbridge github driver @ 0.9.23 and 4.6.0. I have now no more SNR info and the signal strength is always at 100%. Anybody notice this as well? Is this a change in the kernel API or in the dddbridge driver?

oliver

I have a small update on this. It turns out the LNB is broken, de Horizontals no longer work. I have thus far excluded the cables and used a different LNB. With a different LNB it worked for a day, after a day, the signal strength dropped from 80% to 20% on the H and a day later, de V also had a drop from 80% to 20%. Using the original M7 tuner also shows the same symptoms on the LNB now.

Is it possible that for some reason the 0.9.8.1 driver can potentially kill LNB's? I've been using the 0.5 driver for 3 years now and never had a problem and within a week of using the 0.9.8 driver I killed the H on my duo lnb and the H and V on my inverto black LNB. For now, I will connect the duo lnb again to the 0.9.8 driver and see how long it takes before the V is killed also here (since the LNB is half-useless. If the V also dies, i'll roll back the 0.9.8 driver ... and keep using the 0.5

Hi, I'm using an Octopus with a dual S2 board and was using the 0.5 for a few years without problem. Upgrading to a new kernel I decided to give the latest 0.9.18 a try but for some reason only vertical polarized channels seem to work. Anybody experienced this yet? The only symptoms I see are very very high BER, and 0 or very low signal strength and SNR.

version: 0.9.18
srcversion: B3FB489B38DDF7D19A16E2B

What supprises me is that the vertical channels work. While this could in theory be a LNB problem (water/moisture inside the LNB? I noticed the change with the different version so thinking of this at first.

Zitat von Copperhead

Es gehört zwar nicht direkt hier in den Thread, aber auch DVBSky Treiber kommen in den Kernel.
https://patchwork.linuxtv.org/…edia/list/?submitter=1488

So wie es aussieht können wir uns langsam darauf einstellen in Zukunft keine Treiber mehr zu kompilieren.

Very cool stuff, I will try your patch on my v6 S/S2 and see how well it works. What exactly needs to be done further more? I'm sure I can find time to work on a patch or two (But I only have an octopus with a s/s2 card)

Zitat von mbroemme

Nunja damit kann ich erstmal leben, ich wollte explizit ja Feedback haben, was ich alles noch ändern muss. Ich hab den Treiber von Ralph erstmal genommen und ihn so umgebaut, dass er mit dem aktuellen v4l/dvb media-tree läuft. Den Coding Style hab ich dabei bewusst erstmal ignoriert. Das kommt aber mit der nächsten Patchserie.

Generell bin ich hier offen. Ich halte mich da gern an die Struktur die der Kernel für media/ vorgibt.

Das hat im ersten Versuch so nicht ganz funktioniert, ich hab das zwar letzte Woche getestet, aber musste dann doch einiges ändern, damit das mit v4l/dvb läuft und auch die anderen Treiber dennoch kompilieren. Ich hab in meinem Patchset auch erstmal Octonet und DVB Netstream entfernt, denn das ist wirklich zuviel auf einmal.

Generell ist mein Ziel den aktuellen ddbridge Treiber in den offiziellen media-tree zu bekommen so daß er im Stock Kernel landet. Das ist aber keine Sache die in 1-2 Wochen erledigt ist, denn die Änderungen zwischen dem derzeitige 0.5 im Kernel und 0.9.10 von Ralph sind schon riesig. Zuerstmal werde ich jetzt CXD2843 aufbereiten und neu and die ML schicken mit Lösungen zu den Punkten die Mauro angesprochen hat.

Alles anzeigen

Hey, as I mentioned in the original driver thread, where this one forked from, have patched in the 0.8 ddbridge driver (copied it over the 0.5 driver currently in the kernel and removed some headers for hardware that caused compile issues and I didn't have anyway). This has been working quite well for a few months now on my Gentoo 3.11 kernel. I haven't tried the same with 0.9.10 but expect it to work the same, do you have these sources or did you use Oliver's sources? Do you have a git-tree somwhere so I can pull those drivers and start testing it?

I'm glad someone is picking up on this, I mentioned it in the previous thread aswell, that I would be willing to start this undertaking, but some things needed to happen first and my plate is more then full as it is atm

Having read Mauro's comments, they are all very reasonable. Maybe mentioning beforehand that this would be a RFC more then a patch would have helped a little

I may have a few hours to do some coding style if you have a public git tree somewhere.

oliver

Zitat von tom66

The "plain"-Kernel 3.11 don't work? I hope the 3.10.7 works fine.

Both should work just fine, but that would be using the 0.5 ddbridge driver, I'm using the new, from UFO's repository, 0.8 driver with 3.11 I didn't want to go through the whole media build and using that kernel, so I just patched in the 0.8 driver to replace the 0.5 driver, as the 0.5 is known to have issues.

I copied the 0.8 ddbridge files as described in my earlier post to 3.11 and works just fine. No issues that I can see.

Zitat von tom66

Danke für die positive Info über den Kernel 3.10.7. Auf den will ich nämlich gerade updaten (der aktuell stabile freigegebe bei Gentoo). Gibt es einen Ort, wo diese Info auch noch gepflegt wird?

3.10.7 on Gentoo works just fine; will try 3.11 the next few days with my 'copy only ddbridge' way. Wil report once i've tried.

Hey all, I just tried simply copy over only the ddbridge part 'as it was with 0.5' without having to build the entire separate and outdated media-build-tree. With 'as it was' I mean there is no support for: CXD2099 CI module, no support for TDA18271C2DD, STV0367DD or TDA18212DD tuners for the Terrestrial/Coaxial tuners. So only the DVB-S and DVB-S2 tuners are supported with the following patch.

It does also fix a minor compiler warning

Since I only have a DVB-S(2) device, and use OSCAM for decryption I don't really care for those features and want the 0.8 driver as it 'fixes many issues'. This was done on 3.10.6 so 3.11 might work equally well.

The only thing that isn't fixed in mainline that I saw a fix in the endriss tree's is a BER calculation thing, which hopefully will be submitted upstream anyway

--- drivers/media/pci/ddbridge/ddbridge-core.c 2013-08-13 22:07:16.199854102 +0200
+++ drivers/media/pci/ddbridge/ddbridge-core.c  2013-08-13 23:43:10.589803718 +0200
@@ -38,21 +38,10 @@
 #include "ddbridge.h"
 #include "ddbridge-regs.h"
 
-#include "tda18271c2dd.h"
 #include "stv6110x.h"
 #include "stv090x.h"
 #include "lnbh24.h"
 #include "drxk.h"
-#if 0
-#include "stv0367.h"
-#else
-#include "stv0367dd.h"
-#endif
-#if 0
-#include "tda18212.h"
-#else
-#include "tda18212dd.h"
-#endif
 
 static int adapter_alloc;
 module_param(adapter_alloc, int, 0444);
@@ -817,7 +806,6 @@
    	fe->ops.i2c_gate_ctrl = locked_gate_ctrl;
    	return 0;
 }
-#endif
 
 struct stv0367_cfg stv0367dd_0 = {
    	.adr = 0x1f,
@@ -878,7 +866,6 @@
    	return 0;
 }
 
-#if 0
 struct tda18212_config tda18212_0 = {
    	.i2c_address = 0x60,
 };
@@ -1245,14 +1232,20 @@
    	case DDB_TUNER_DVBCT_TR:
            	if (demod_attach_drxk(input) < 0)
                    	return -ENODEV;
+#ifdef DVB_TDA18271C2DD
            	if (tuner_attach_tda18271(input) < 0)
                    	return -ENODEV;
+#endif
            	break;
    	case DDB_TUNER_DVBCT_ST:
+#ifdef DVB_STV0367DD
            	if (demod_attach_stv0367dd(input) < 0)
                    	return -ENODEV;
+#endif
+#ifdef DVB_TDA18212DD
            	if (tuner_attach_tda18212dd(input) < 0)
                    	return -ENODEV;
+#endif
            	break;
    	}
    	input->dvb.attached = 5;
@@ -1704,6 +1697,7 @@
 
 static int ddb_ci_attach(struct ddb_port *port)
 {
+#ifdef DVB_CXD2099
    	if (port->type == DDB_CI_EXTERNAL_SONY) {
            	port->en = cxd2099_attach(&cxd_cfg, port, &port->i2c->adap);
            	if (!port->en)
@@ -1711,6 +1705,7 @@
            	dvb_ca_en50221_init(port->input[0]->dvb.adap,
                                	port->en, 0, 1);
    	}
+#endif
 #if 1
    	if (port->type == DDB_CI_INTERNAL) {
            	ci_attach(port);
@@ -2215,7 +2210,7 @@
    	.open       	= ddb_open,
 };
 
-static char *ddb_devnode(struct device *device, mode_t *mode)
+static char *ddb_devnode(struct device *device, umode_t *mode)
 {
    	struct ddb *dev = dev_get_drvdata(device);

Zitat von karlson

I don't want to seem mean, but I hope for very bad weather ... your work will for sure be apreciated by those
knowing about the different development lines, and would be without knowing by all the others, too.

BR, Karlson.

Hah, but you need very bad weather in Germany first so that Oliver can finish porting 0.9.8

And then you need much bad weather here, I'll have to read up on a lot to get up to speed But we will see

Zitat von jasminj

I worked some months ago on the CI issue. Due to a physical problem, I had to stop this for undefined time.
I got the driver 0.9.x from Ralph and checked the differences in the part which I was interested in. I found a lot of changes and at the end most of it was formatting. Ralph answered, that he didn't took Olivers driver (who had already made the Linux code style changes in version 0.8 ) to start with the modifications for 0.9.x, but instead he used his original 0.8 version.
So he ignore Olivers work and Oliver or I or someone else need to do the work again!

As long as Ralph, who got the technical description from DD for the chips and the FPGA on the cards, does not use the work from others to continue his updates, this is a waste of time!
I don't know, if Ralph is willing to change his development to the code base of Oliver and I don't know how long Oliver is willing to do any time the same changes ... .
And if you could merge Olivers version to the Kernel tree, then Oliver would need get it back and then Ralph and ... .
It is a mess, frustrating and ... .

I am not sure, if the situation is still the same. Maybe Oliver and Ralph does now share the code.
If they share the code, then there would be still changes between the Oliver/Ralph version and the mainline, because Oliver and Ralph are not willing to deal with the current head maintainer Mauro. I read some posts about this issue from Ralph and from Oliver (again just some posts, ago). And I can understand the reasons. They are technical and maybe personal, too.

The real pity is, that Oliver and Ralph are experienced developers and that the cards from DD are excellent good cards. This is real quality, made in Germany. They are very good HW engineers, but if the mainstream SW doesn't use them with a recent driver, there could start rumours the cards are not supported by Linux, which is definite not true.

BR,
Jasmin

Alles anzeigen

I feel it is extremely important to have the driver mainlined. I understand that some maintainers can be extremly hard to deal with, but having 3 drivers is horrible. We have the 'Ralph' version, that nobody uses? But is the most accurate in hardware support since Ralph as far as I understand it works with/for DD.

Then we have the 'Oliver' version (not me) that tries to bring the Ralph version closer to mainline, but not entirly. And then we have the mainline version, that's pretty out dated, but probably used the most who are unaware of the other two drivers.

Hardware wise they look very decent and should work extremely well.

So once 0.9.8 is done being ported to oliver's tree, I'll take the code and port it over to mainline, which looks like quite the task, but we'll see. Frustrating for everybody, but I guess mostly the users

Oliver

Zitat von oliv3r

What is the status of the ddbridge driver at this moment? I know Ralph Metzler is working on the driver (dd employee) but he does not wish to merge his driver with mainline.I think he's upto verison 0.8 or 0.9 now, the kernel version is stuck at 0.5. I saw your repostiory: http://linuxtv.org/hg/~endriss/ngene-octopus-test with the latest commit 4 months ago.

I can help I suppose by taking your repostitory, extract the patches since your fork and backport them to mainline, unless you prefer to do it yourself of course ;)
As I stated several times before, I will not submit drivers to linuxtv anymore. I am deeply disappointed. The maintainers tossed all good principles of linux dvb driver development. They break userspace by changing ABIs/APIs at will. I am tired fighting that.

I maintain the drivers, which I care about, in media_build_experimental. Currently I am working on ddbridge 0.9.8 integration, but this needs some more time - and we have nice weather here atm.

Anyway, the code is GPL. If you want to submit a driver, you can do so. But do not expect that I will maintain the submitted driver in any way!

CU
Oliver

Alles anzeigen

I can understand, alright, I'll keep tracking your progress and check this forum for when you are done with 0.9.8. If you don't mind, I will take your code/patches and integrate them into linux-media as best as I can.

Oliver

P.S. Lucky you, here in NL the wether is not so nice. Though next week it should be better.

Zitat von Dr. Seltsam

@ UFO:
ist eine Integration der Treiber in linuxtv bzw. den Kernel eigentlich noch in Arbeit, bzw. wo liegen die Probleme?

Oliver,

What is the status of the ddbridge driver at this moment? I know Ralph Metzler is working on the driver (dd employee) but he does not wish to merge his driver with mainline.I think he's upto verison 0.8 or 0.9 now, the kernel version is stuck at 0.5. I saw your repostiory: http://linuxtv.org/hg/~endriss/ngene-octopus-test with the latest commit 4 months ago.

I can help I suppose by taking your repostitory, extract the patches since your fork and backport them to mainline, unless you prefer to do it yourself of course