Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

Hallo zusammen,

die Refactoring- und Cleanup-Arbeiten im "Basis"-Branch (ddbridge-Code ohne API-Änderungen) sind jetzt vorläufig erstmal abgeschlossen. Unter https://github.com/herrnst/dddvb-linux-kernel liegen jetzt folgende Branches mit dem offiziellen Linux Media Tree als Grundlage:

• mediatree/master-ddbridge: "Basis"-Branch für ddbridge 0.9.23 und CXD2843/STV0367/STV090x/STV0910/DRXK-Support (Dual DVB-C/C2/T/T2/S/S2-Karten und -Module)
• mediatree/master-ddbridge-features: Feature-Branch mit erforderlichen DVB-API-Änderungen (DVB-C2-Support, MaxS8/mxl5xx-Support, OctoNet-Support, Resi DVB-C-Modulator, CXD2099/DuoFlex-CI-Verbesserungen)
• mediatree/master-ddbridge-testing: Test-Branch, enthält derzeit nur den aufwändigeren TDA18212 Init Code sowie einen Fix-Versuch für das STV0367DD i2c_write-error-bei-init-Problem (NICHT gefixt!)
• mediatree/master-ddbridge-experimental: Experimental-Branch, enthält derzeit den kläglichen Versuch, das STV0367-Demod-Modul zu ersetzen (erfordert weitere Arbeit und Tests)

Aufgrund des MSI+SATA-Problems muss ich meine CineCTv6(+DuoFlex C/T/T2, CXD2837) mit msi=0 laufen lassen, läuft aber ansonsten mit Code aus o.g. Branches jetzt wieder >10 Tage stabil durch.

Hinweis: Die Branches sind als "moving target" zu betrachten, werden also häufig gegen den offiziellen mediatree rebased (d.h. die Commit History verändert sich). Ich werde versuchen, bei Kernel-Major-Releases "stabile", unveränderliche Branches zu pflegen.

Bzgl. Posten auf der Mailinglist und "Aufnahme in den Kernel": Das stv0367dd Demod Modul wird mit ziemlicher Sicherheit abgelehnt mit dem Kommentar "Use the existing driver" - der Versuch liegt im o.g. experimental-Branch und funktioniert nicht. Ohne passende Testhardware kann ich das Thema leider nicht weiter sinnvoll verfolgen (wenn mir die Module um die Ohren fliegen, fällt hier im Haushalt der gesamte TV-Empfang flach und den Server mit seinen 24h-laufenden Platten dauernd zu Power-Cyclen find' ich auch nicht soooo prall). Der Code ist zwar aufgeräumt, aber das "Duplikat"-Argument wird hier stechen. Ferner ist noch Feintuning bzgl. LNBH25 (LNB-IC auf STV0910/STV6111 Boards, neue S2-Boards wie Cine S2 V7 und neue DuoFlex S2) notwendig, mindestens bei masterpete sind eine Reihe von Sendern nicht zu empfangen, was auf fehlerhafte LNB-Ansteuerung (H/V Polarität, Umschaltung per 13/18V - dafür ist das lnbh25-Modul da) hindeutet. Wirklich genaue Details sind aber noch Fehlanzeige.

TL/DR: Feedback benötigt für DRXK- und STV0910-basierende Boards, Feedback für MaxS8-Karten mit Feature-Branch wünschenswert, MaxA8 (Octo-C/T) sollte mit dem Basis-Branch laufen, Feedback wäre aber auch nicht schlecht. Ausserdem wäre DuoFlex CI-Feedback (Vergleich Base-Branch zu Feature-Branch) hilfreich. LNBH25 benötigt wohl Fixing, STV0367DD muss wohl wie beschrieben umgebaut werden.

Nebenbei werde ich schauen, einiges von den mehr oder weniger trivialen Cleanups in den dddvb-Upstream zu bekommen.

Wie auch immer das Thema ("Integration in Upstream-Kernel") weitergehen mag - vielleicht sind die jetzt entstandenen Branches (dddvb-Splits) für jemanden hilfreich.

Viele Grüße,
"nst"

Hallo NST,

solltest Du Testhardware aus dem DigitalDevices Spektrum benötigen, so schick mir eine Nachricht, ich stelle Dir gerne was bei.

Gruss
Bernhard

Respekt für deinen Einsatz

Hallo,

möchte auch mal testen

Gilt Dein Howto dann noch?

https://github.com/herrnst/ddd…ile-using-media_build.git

# git clone git://linuxtv.org/media_build.git
# git clone https://github.com/herrnst/dddvb-linux-kernel.git

letzteres nur durch eine der 3 Möglichkeiten ersetzen?

Grüße

So hab es mal durchlaufen lassen nach dem Howto:

uname -a
Linux localhost 4.5.2 #1 SMP Tue Apr 26 14:05:00 CEST 2016 x86_64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux

.........
gelöscht
.....

Edit sehe gerade, daß die Kernelheaders nicht stimmen...

Edit 2:

[    3.673362] Digital Devices PCIE bridge driver 0.9.23, Copyright (C) 2010-15 Digital Devices GmbH
[    3.673563] DDBridge driver detected: Digital Devices Cine S2 V6.5 DVB adapter
[    3.673614] DDBridge: HW 0001000d REGMAP 00010004
[    3.677126] Port 0: Link 0, Link Port 0 (TAB 1): DUAL DVB-S2
[    3.678179] Port 1: Link 0, Link Port 1 (TAB 2): NO MODULE
[    3.679210] Port 2: Link 0, Link Port 2 (TAB 3): NO MODULE
[    3.680137] Port 3: Link 0, Link Port 3 (TAB 4): DUAL DVB-S2
[    3.680409] DVB: registering new adapter (DDBridge)
[    3.680446] DVB: registering new adapter (DDBridge)
[    3.680478] DVB: registering new adapter (DDBridge)
[    3.680510] DVB: registering new adapter (DDBridge)

scheint zu klappen...teste

Grüße

Zitat von linux4media

[...] so schick mir eine Nachricht [...]

Hast PN

Zitat von Tinitus

So hab es mal durchlaufen lassen nach dem Howto:
[...]

Code

[    3.673362] Digital Devices PCIE bridge driver 0.9.23, Copyright (C) 2010-15 Digital Devices GmbH
[    3.673563] DDBridge driver detected: Digital Devices Cine S2 V6.5 DVB adapter

Das dürften STV090x ("alte" DVB-S STV's) sein, richtig? Welches Flexmodul mit welchem Demod-Chip hängt an der Karte?

Wenn Du nicht den "-features"-Branch testest (höchstens für DuoFlex CI Addonmodule interessant), dürfte es für Dich keinen Unterschied machen, ob Du den Basisbranch oder "-testing" verwendest.

Zitat von Tinitus

scheint zu klappen...teste

Danke!

Leider funktioniert femon mit dem 0.9.23 nicht mehr.

vdr01_64 ~ # femon -H -c 3 -a1
FE: STV090x Multistandard (DVBS)
status SCVYL | signal  99% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  99% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  99% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
vdr01_64 ~ #

Zitat von 3PO

Leider funktioniert femon mit dem 0.9.23 nicht mehr.

Ehrlich gesagt sehe ich keinen Grund, warum die Statistiken aus diesem Demod "auf einmal" nicht mehr funktionieren sollten - stv090x.c wurde seit "Ewigkeiten" nicht mehr verändert (sowohl die In-Kernel-Variante als auch die aus dem dddvb-Package, wobei sich letztere nur darin unterscheidet, mit passenden Compiler-Flags Werte in dB anstatt linearer Werte zurückzuliefern).

Wo wird das "Compiler-Flag" gesetzt?

https://github.com/DigitalDevi…er/frontends/Makefile#L17 kommentieren, dafür gabs im Zusammenhang mit den DKMS-Packages hier im Forum auch schon 'nen Patch. Für https://github.com/herrnst/dddvb-linux-kernel nicht zutreffend, da nicht vorhanden.

DKMS verwende ich nicht.

Zitat von nst

https://github.com/DigitalDevi…er/frontends/Makefile#L17 kommentieren, ...

DANKE!!

Das wars, jetzt geht's wieder.

vdr01_64 ~ # femon -H -c 3 -a1
FE: STV090x Multistandard (DVBS)
status SCVYL | signal  69% | snr  71% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  68% | snr  71% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  69% | snr  71% | ber 0 | unc 0 | FE_HAS_LOCK
vdr01_64 ~ #

Hi,

kann mir jemand in einfachen Worten erklären welche Vorteile ich gegenüber diesem weg habe? Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)
Ich nutze eine Cine v7 C2/T2 und bisher habe ich die mit der obigen Anleitung am laufen. Ich möchte irgendwann demnächst noch ein S2 upgrade der Karte hinzufügen wenn das evtl relevant ist.
Da ich aber nicht deeeer Profi mit VDR und den DVB Treibern bin (bin froh das es irgendwie läuft) würde ich mich über eine kurze Erklärung für Dummies freuen.

Grüße
Dirk

Na das hört sich ja schon mal sehr gut an!

@gentoo-vdr / alle Cine CTv6 bzw. stv0367dd Tester mit DVB-C-Empfang:

e254912 fixt ein (kosmetisches) Problem, dass eine Kernel-Warning getriggert werden konnte, wenn für nicht berücksichtigte Modulationsverfahren versucht wurde, die SNR zu ermitteln. Aufgefallen beim Durchlauf von "w_scan -f c". Die Kernel-Warning führt zu keiner Systeminstabilität oder so, sieht aber im Log unschön aus und setzt ein Taint-Flag.

EDIT: Commit-ID (btw, v4.6.0-ddbridge und v4.6.0-ddbridge-features sind jetzt "stable" im Sinne von "gebrancht und wird nicht mehr modifiziert", STV0910-Karten werden möglicherweise nicht sauber funktionieren).

@Gentoo-Benutzer:

Unter https://github.com/herrnst/gentoo-ddbridge-sources-overlay/ gibts seit kurzem ein Overlay, über welches sich "sys-kernel/ddbridge-sources" (derzeit in Version 4.6.x, Basis ist sys-kernel/gentoo-sources) als Kernel-Source installieren lässt, Resultat in /usr/src/linux-4.6.x-ddbridge ist ein Kernel-Tree mit bereits integrierten ddbridge-Modulen. USE=dddvb-api-extra aktiviert alle zusätzlichen Module, welche Änderungen an der Linux DVB API erfordern (am Prominentesten MaxS8 Support).

Hallo *,

ich hoffe ich bin im richtigen Thread. Habe das erste Mal von https://github.com/DigitalDevi…dvb/archive/0.9.23.tar.gz kompiliert und bekomme unter Debian Testing 4.6.0-1-amd64 #1 SMP Debian 4.6.1-1 (2016-06-06) bei den Versionen 0.9.22 und 0.9.23 folgendes Problem:

:
<schnipp>
:
CC [M]  /usr/src/dddvb-0.9.22/frontends/drxk_hard.o
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c: In function ‘drxk_set_parameters’:
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c:4871:36: warning: unused variable ‘old_delsys’ [-Wunused-variable]
  u32 delsys  = p->delivery_system, old_delsys;
                                    ^
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c:4871:6: warning: unused variable ‘delsys’ [-Wunused-variable]
  u32 delsys  = p->delivery_system, old_delsys;
      ^
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c: At top level:
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c:4899:64: warning: ‘struct dvb_frontend_parameters’ declared inside parameter list
 static int drxk_c_get_frontend(struct dvb_frontend *fe, struct dvb_frontend_parameters *p)
                                                                ^
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c:4899:64: warning: its scope is only this definition or declaration, which is probably not what you want
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c:4993:64: warning: ‘struct dvb_frontend_parameters’ declared inside parameter list
 static int drxk_t_get_frontend(struct dvb_frontend *fe, struct dvb_frontend_parameters *p)
                                                                ^
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c:5018:18: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .get_frontend = drxk_c_get_frontend,
                  ^
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c:5018:18: note: (near initialization for ‘drxk_c_ops.get_frontend’)
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c:5052:18: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .get_frontend = drxk_t_get_frontend,
                  ^
/usr/src/dddvb-0.9.22/frontends/drxk_hard.c:5052:18: note: (near initialization for ‘drxk_t_ops.get_frontend’)
cc1: some warnings being treated as errors
/usr/src/linux-headers-4.6.0-1-common/scripts/Makefile.build:296: die Regel für Ziel „/usr/src/dddvb-0.9.22/frontends/drxk_hard.o“ scheiterte
make[5]: *** [/usr/src/dddvb-0.9.22/frontends/drxk_hard.o] Fehler 1
/usr/src/linux-headers-4.6.0-1-common/scripts/Makefile.build:445: die Regel für Ziel „/usr/src/dddvb-0.9.22/frontends“ scheiterte
make[4]: *** [/usr/src/dddvb-0.9.22/frontends] Fehler 2
/usr/src/linux-headers-4.6.0-1-common/Makefile:1446: die Regel für Ziel „_module_/usr/src/dddvb-0.9.22“ scheiterte
make[3]: *** [_module_/usr/src/dddvb-0.9.22] Fehler 2
Makefile:146: die Regel für Ziel „sub-make“ scheiterte
make[2]: *** [sub-make] Fehler 2
Makefile:8: die Regel für Ziel „all“ scheiterte
make[1]: *** [all] Fehler 2
make[1]: Verzeichnis „/usr/src/linux-headers-4.6.0-1-amd64“ wird verlassen
Makefile:7: die Regel für Ziel „all“ scheiterte
make: *** [all] Fehler 2

Unter 4.5.0-2-amd64 #1 SMP Debian 4.5.5-1 (2016-05-29) laeuft sowohl 0.9.22 als auch 0.9.23.

Gruss kalk

Nabend zusammen und verspätetes frohes Neues,

meiner offenbar masochistischen Veranlagung folgend habe ich vor kurzem damit begonnen, die In-Kernel-ddbridge von 0.9.23 auf 0.9.28 upzudaten, und stelle mir gerade ein paar Fragen, die Ihr mir evtl. beantworten könnt - Hintergrund ist, einen haufen Code/Patches weg zu rationalisieren und dadurch Aufwand (jetzt, sowie später beim Rebasing) einzusparen:

• Macht es Sinn, die Unterstützung für die DVB-C Modulator Karten weiter zu pflegen? Anders ausgedrückt: Braucht die Unterstützung irgendjemand? (noch anders: Ist das Kunst oder kann das - der Code bzw. die Patches - weg?)
• Kann ich davon ausgehen, dass die OctoNet-Unterstützung ausschliesslich für die gleichnamigen Boxen von relevanz ist, und in der Hardware sowieso keine "Fremdkarten" zum Einsatz kommen? Ausserdem: Laufen die Boxen nicht sowieso mit dem vendor-provided dddvb Package?
• in 0.9.24+ wird Unterstützung für "OctoPro" Geräte bereitgestellt. Die Hardware-IDs geben hier schon einige Hinweise, wirklich sicher bin ich aber nicht: Sind das neue Versionen der OctoNet Büchsen? Und kann der Support genau genommen ebenfalls eigentlich weg?

Falls jemand zwischendurch Testen mag - Fortschritt kann im mediatree/master-ddbridge-update-Branch verfolgt werden (zum Zeitpunkt dieses Postings compiliert der Kram ohne Warnings, mit Hardware ist aber noch nix getestet (nach wie vor keine Testgeräte).

Und nebenbei...

Zitat von klak

ich hoffe ich bin im richtigen Thread.

Nein, falscher Thread.

Grüße,
nst