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

Wow. Das ist doch mal was. Ich versuche schon seit ein paar Tagen das media_build_experimental-dkms Paket für VDR4Arch zu reparieren.
Da kommt mir das hier wirklich entgegen.

Zitat von nst

(Commit-Hashes können/werden sich aufgrund Rebase/Force-Pushes ändern!)

Das lässt sich ganz leicht verhindern. Wenn der Kernel 4.4.4 kommt machst du einfach einen neuen Branch und führst dort den Rebase aus. So bleiben die alten Hashes valide. Zusätzlich dann den neuen Branch als neuen Hauptbranch setzen.

Zitat von nst

Entsprechend werde ich auch keine Versuche unternehmen, die Patchserie in Mainline unterzubringen, das überlasse ich den Autoren oder Freiwilligen, die den Code besser kennen, verstehen und Fragen beantworten können.

Hach... Und da hatte ich für einen Moment Hoffnung, dass es endlich zur perfekten Lösung wird.

Zitat von Copperhead

Das lässt sich ganz leicht verhindern. Wenn der Kernel 4.4.4 kommt machst du einfach einen neuen Branch und führst dort den Rebase aus. So bleiben die alten Hashes valide. Zusätzlich dann den neuen Branch als neuen Hauptbranch setzen.

Die Variante gibts natürlich auch (und mach' ich so in meinem Kodi Fork), der Rattenschwanz an Branches ist aber etwas unelegant, Commits (Hashes) bleiben aber natürlich erhalten.

Zitat von Copperhead

Hach... Und da hatte ich für einen Moment Hoffnung, dass es endlich zur perfekten Lösung wird.

Sorry, aber wie ursprungs erwähnt hab' ich lediglich alle Teilfragmente zusammengesetzt, Argumentieren vor allem gegenüber den Linux-Media-Maintainern ist für mich einfach nicht möglich, wenns um den Code geht...

Zitat von mini73

Wenn ich mich richtig erinnere, dann hatte bisher der Kernel-drxk noch keine Unterstützung für ENUM_DELSYS, d.h. für C und T gab es getrennte Frontends, was dem vdr nicht gefällt, weil man nur eins zur Zeit öffnen kann. Aber vielleicht geht das ja mittlerweile. UFO hatte deshalb einen älteren Stand entsprechend angepasst und den in sein media-build-experimental integriert.

Mit den Treibern aus dem Kernel 4.4.1 sieht es mit einer DuoFlex an einer ngene PCIe-Bridge nach gemeinsamen Frontends für DVB-C und DVB-T aus:

# dmesg
[    5.663865] ngene 0000:04:00.0: enabling device (0000 -> 0002)
[    5.663877] ngene: Found Digital Devices DuoFlex PCIe or miniPCIe
[    5.664394] ngene: Device version 1
[...]
[    5.670867] ngene: Loading firmware file ngene_18.fw.
[...]
[    5.708416] i2c i2c-1: error in i2c_read_reg
[    5.708425] i2c i2c-1: No CXD2099 detected at 40
[    5.710560] No demod found on chan 0
[    5.712132] No demod found on chan 1
[    5.771667] drxk: status = 0x639130d9
[    5.771671] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
[...]
[    8.785235] drxk: DRXK driver version 0.9.4300
[    8.838989] drxk: frontend initialized.
[...]
[   11.977810] DVB: registering new adapter (nGene)
[   11.977820] ngene 0000:04:00.0: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)...
[   12.005929] drxk: status = 0x639130d9
[   12.005936] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
[   14.975669] drxk: DRXK driver version 0.9.4300
[   15.028575] drxk: frontend initialized.
[   18.153311] DVB: registering new adapter (nGene)
[   18.153320] ngene 0000:04:00.0: DVB: registering adapter 1 frontend 0 (DRXK DVB-C DVB-T)...
[...]
$ uname -a
Linux vdr4arch 4.4.1-2-ARCH #1 SMP PREEMPT Wed Feb 3 13:12:33 UTC 2016 x86_64 GNU/Linux
$ ls /dev/dvb/
adapter0  adapter1
$ ls -l /dev/dvb/*
/dev/dvb/adapter0:
insgesamt 0
crw-rw----+ 1 root video 212, 4 29. Feb 08:13 demux0
crw-rw----+ 1 root video 212, 5 29. Feb 08:13 dvr0
crw-rw----+ 1 root video 212, 3 29. Feb 08:13 frontend0
crw-rw----+ 1 root video 212, 7 29. Feb 08:13 net0


/dev/dvb/adapter1:
insgesamt 0
crw-rw----+ 1 root video 212, 68 29. Feb 08:13 demux0
crw-rw----+ 1 root video 212, 69 29. Feb 08:13 dvr0
crw-rw----+ 1 root video 212, 67 29. Feb 08:13 frontend0
crw-rw----+ 1 root video 212, 71 29. Feb 08:13 net0

Bis vor ca. 1,5h gab es Probleme beim Compilen mit CONFIG_PCI_MSI (zuviel bzw. falsch wegrationalisiert...), den Fix werd' ich in Kürze mit dem ursprünglichen Cleanup-Commit zusammenführen (squashen) und gleichzeitig die API-Erweiterungen etwas umsortieren, also falls den Tree schon jemand in Benutzung hat: Die Hashes werden sich ändern

EDIT: Done.

nst

Falls zwischendurch jemandem der Sinn nach Testen steht und sich der Drang zum Experimentellen äussert:

AFAIK ist Voraussetzung zur Aufnahme in den offiziellen Kerneltree, dass keine funktionalen Moduldupletten akzeptiert und eingecheckt werden - Ich habe gerade mal einen von Antti's Patches applied (https://patchwork.linuxtv.org/patch/25146/), das TDA18212DD Tuner Modul ist damit überflüssig und im "experimental" Branch auch direkt entfernt. Mein Streamingserver (DVB-C, DVB-T) läuft damit derzeit ganz hervorragend, nur die DVB-T-Config musste etwas nachgestellt werden (alle Parameter auf AUTO funktionierte nicht mehr, ich musste explizit QAM16 und 8MHz Bandbreite angeben). Das lass' ich jetzt mal so laufen

Mit dem in-Kernel-Tunermodul meldet sich "modprobe ddbridge" jetzt so (Adapter 0 ist die erwähnte KNC ONE):

[89354.027762] Digital Devices PCIE bridge driver 0.9.22, Copyright (C) 2010-15 Digital Devices GmbH
[89354.036140] DDBridge driver detected: Digital Devices DVBCT V6.1 DVB adapter
[89354.036155] DDBridge: HW 0001000d REGMAP 00010004
[89354.036209] DDBridge: using 1 MSI interrupt(s)
[89354.038047] Port 0: Link 0, Link Port 0 (TAB 1): DUAL DVB-C/T
[89354.146001] Port 1: Link 0, Link Port 1 (TAB 2): DUAL DVB-C/T/T2
[89354.146960] Port 2: Link 0, Link Port 2 (TAB 3): NO MODULE
[89354.147643] 0 netstream channels
[89354.147648] DVB: registering new adapter (DDBridge)
[89354.147650] DVB: registering new adapter (DDBridge)
[89354.147651] DVB: registering new adapter (DDBridge)
[89354.147653] DVB: registering new adapter (DDBridge)
[89354.149788] stv0367 found
[89354.400854] tda18212 2-0060: NXP TDA18212HN/M successfully identified
[89354.400862] ddbridge 0000:03:00.0: DVB: registering adapter 1 frontend 0 (STV0367 DVB-C DVB-T)...
[89354.401588] stv0367 found
[89354.653775] tda18212 2-0063: NXP TDA18212HN/S successfully identified
[89354.653784] ddbridge 0000:03:00.0: DVB: registering adapter 2 frontend 0 (STV0367 DVB-C DVB-T)...
[89354.687359] tda18212 3-0060: NXP TDA18212HN/M successfully identified
[89354.687368] ddbridge 0000:03:00.0: DVB: registering adapter 3 frontend 0 (CXD2837 DVB-C DVB-T/T2)...
[89354.719810] tda18212 3-0063: NXP TDA18212HN/S successfully identified
[89354.719819] ddbridge 0000:03:00.0: DVB: registering adapter 4 frontend 0 (CXD2837 DVB-C DVB-T/T2)...

Ich werd' mich mal am STV0367-Ersatz versuchen.

Der Code basierend auf Linux-4.4.3: https://github.com/herrnst/ddd…-4.4.y-dddvb-experimental

Grüße,
nst

Genau genommen wendest du die Patches auch auf den falschen Tree an. Soweit ich weiß müssen die DVB-Sachen auf den media_tree von linuxtv angewendet werden.
Das ist aber das kleinste Problem. Das habe ich bei mir hier lokal schonmal gemacht ohne dabei die ursprünglichen Commits zu verlieren.

Selber testen werde ich wohl ab morgen mit meinem media_tree Konstrukt und meiner Cine S2 V6

Zitat von Copperhead

Genau genommen wendest du die Patches auch auf den falschen Tree an. Soweit ich weiß müssen die DVB-Sachen auf den media_tree von linuxtv angewendet werden.
Das ist aber das kleinste Problem. Das habe ich bei mir hier lokal schonmal gemacht ohne dabei die ursprünglichen Commits zu verlieren.

Ja, falls der Kram mal für'n Pull zu gebrauchen wird... Fix mit "git cherry-pick" - https://github.com/herrnst/ddd…master-dddvb-experimental (komplett ungetestet, nichtmal kompiliert...)

Zitat von nst

Ich werd' mich mal am STV0367-Ersatz versuchen.

Erster Versuch mit https://github.com/herrnst/ddd…ddvb-experimental-stv0367: Durchwachsen.

Das Frontend wird zwar erkannt, geladen und attached, sobald aber TVH auf die DVB Interfaces zugreifen will, schiessen i2c_read/write Errors durchs Kernel Log. Ausserdem lässt sich das Modul nicht entladen, da nach "rmmod ddbridge" der RefCounter auf 2 steht.

Hast du das hier schon gesehen?
https://git.linuxtv.org/anttip…git/log/?h=digitaldevices

Dein Patch oben stammt wahrscheinlich von hier. Eventuell kannst du ja die Commits von dort Cherry picken.
Vielleicht ist auch das ein oder andere dort noch zusätzlich zu gebrauchen.

Danke! Ja, die Commits sind bekannt (und von da bzw. den zugehörigen media-tree-list Posts kommt der TDA18212 Patch). Die Änderungen am TDA18212-Modul sind bereits in abgewandelter Form in Mainline, daher funktioniert der TDA18212DD->TDA18212 Austausch vermutlich auch "einfach so" Das STV0367-Frontend (das ist leider auf den CineCTV6-Bridges aufgelötet) hat Antti leider ersatzlos entfernt, daher mein erster Versuch von vorhin. Nützlich erscheint der "Remove network streaming functionality (Clean up driver for release)" Commit, dürfte Diskussionen um API-Anpassungen ersparen - falls es denn mal (für wen auch immer) so weit kommen sollte...

Hm. Das Thema "stv0367dd" durch "stv0367" ersetzen sollte besser jemand übernehmen, der weiss, was er da tut und sich damit auskennt...

Mit dem letzten Commit in https://github.com/herrnst/ddd…ddvb-experimental-stv0367 habe ich meine CineCTv6 zum Initialisieren überreden können (d.h. laut Kernel-Log wurden die Frontends initialisiert und die TDA18212 Tuner angehängt), obwohl noch ein einzelner "i2c_write failed" im Log aufgetaucht ist. TVHeadend hat die Tuner auch anschliessend in seiner Konfiguration "gesehen". Beim Versuch, diese zu verwenden ist TVH dann aber einfach hängen geblieben und der Prozess lies sich nur mit SIGTERM verabschieden. Schlimmer aber: "rmmod ddbridge" hat das ddbridge-Modul mit einem RefCount von -1 hinterlassen und rmmod konnte nicht mehr zum Abbruch überredet werden. Nach Revert der Kernel-Module (zurück zu stv3067dd+tda18212 in-tree) gabs dann kleine Schweissperlen auf der Stirn - TDA18212 konnte die Tuner auch nach Power-Cycle und 1min. Power-abkabeln nicht richtig initialisieren ("failed with error -5"). Glücklicherweise lies sich der Spuk mit tda18212dd wieder beenden... Die Kiste läuft und streamt jetzt im Augenblick wieder mit "stv0367dd+tda18212" (nach einmaliger Verwendung von tda18212dd war Frontend+Tuner offenbar wieder beschwichtigt), und ich werd' das stv0367-Thema vorerst nicht weiter beackern... Allerdings werd' ich mal schauen, die GIT commits so umzuordnen, dass diese den Vorstellungen der media-tree-admins entspricht (habe die Woche relativ viel in der Mailinglist geblättert).

Nebenbei, Linux-4.4.3+dddvb liegt jetzt im Branch "v4.4.3-dddvb-0.9.22" und wird nicht weiter verändert, "linux-4.4.y-dddvb" ist auf 4.4.4 rebased.

Hallo zusammen,

wie schon angedeutet habe ich mir in den letzten Tagen den dddvb-Code nochmal 'n ganzes Eck ausführlicher zur Brust genommen:

Es ist mir gelungen, alle Codeteile, welche Änderungen oder Erweiterungen an der Kernel DVB-API erfordern, auszukapseln und alles in einzelne, kleine Patches bzw. Commit-Häppchen zu verpacken. Das Ergebnis ist, dass mit Ausnahme der DD-MaxS8 alle Karten ohne Änderungen an den Schnittstellen funktionieren (sollten) - mit der Einschränkung, dass das CXD2843-Frontend kein DVB-C2 delivery system kennt (betrifft CineCTv7 C/C2/T/T2 und DuoFlex C/C2/T/T2). Der Code läuft derzeit auf meinem Server mit Kernel 4.4 bislang ohne Mucken In (einem) weiteren Branch(es) folgen darauf - ebenfalls in kleine Stückchen gesplittet - alle Teile, die die Gesamtfunktionalität (inkl. DVB-C2, MaxS8, OctoNet und DVB-C Resi Modulator) wieder hinzufügen. Unterm Strich kommt funktional derselbe Code raus, der auch in dddvb-0.9.22 zu finden ist (Diff ist nicht identisch, da der Code im GIT bereits "checkpatch"-bereinigt ist und von unbenutzem Code befreit wurde).

Zwei aufwändige TODO's stehen derzeit ganz oben: Der TDA18212-Austausch muss nochmal genauer verifiziert und getestet werden (beim Laden tritt derzeit noch häufig der Fall ein, dass der Tuner nicht gefunden wird, was im Anschluss in einem Berg NULL pointer exceptions im Kernellog resultiert und ddbridge aufgrund negativem Refcount nicht entladen werden kann; dazu habe ich schon eine Teständerung zusammengefummelt, aber noch nicht in Betrieb). Ausserdem sollte (muss) das STV0367-Frontend ausgewechselt werden.

Weiterhin wird bereits das In-Tree-Modul für den LNB-Steuer-IC lnbh25 verwendet, mangels Hardware kann ich das aber nicht testen. Betroffen sind wohl alle CineS2 v6.x oder neuer (alle mit STV0910 Demodulator).

Derzeit verfügbare Branches:
* Linux-4.4 stable: ddbridge-Basis ddbridge + TDA18212/STV0367 Tests ddbridge + Zusatzfeatures
* Linux-master (4.5rc): ddbridge-Basis ddbridge + Zusatzfeatures
* Linux Media Tree: ddbridge-Basis ddbridge + TDA18212/STV0367 Tests ddbridge + Zusatzfeatures

(In Master/4.5rc sowie Media Tree sind bereits Build-Fixes aufgrund veränderter In-Tree-API enthalten)

Ausserdem hab' ich mal unter https://github.com/herrnst/dddvb-linux-kernel/wiki angefangen zu dokumentieren, über die Dokumentationsstruktur bin ich aber noch nicht hinausgekommen...

Falls jemand Interesse daran hat, den Kram auf dieser Basis zu upstreamen, bin ich gerne zumindest unterstützend dabei.

Nachtrag: Ich denke, die "alten" dddvb Branches werden nicht mehr angefasst.

Grüße,
Daniel (nst)

Zitat von mini73

Ich folge dir unauffällig und hoffe, mit gelegenlichen Tests unterstützen zu können.
Ich hab hier ein Testsystem mit stv0367dd, drxk, tda18212dd, tda18271c2dd und cxd2099 an einer ddbrigde, allerdings nur DVB-C angeschlossen, kein DVB-T.

Interessant wäre bei der Konstellation derzeit:
- Funktioniert drxk, und als Bonus - wie erwartet? Der drxk-Code ist nicht aus dem dddvb Package übernommen.
- Wie gut oder schlecht funktioniert die TDA18212-Anpassung aus dem TDA18212/STV0367 Testing-Branch? (aus dem Basis-Branch hingegen sollten alle Deine Demods und Tuner einfach so laufen)
- Funktionieren CI-Module (cxd2099) einfach so, oder sind die dddvb-Änderungen notwendig (obere drei Feature-Patches)? Die Änderungen auch an der DVB-API kann ich ehrlich gesagt nicht ganz einordnen...

Zitat von mini73

Ich weiß, dass der CI-Treiber wohl ein neues Device benutzt, das noch nicht in der API ist (ciX). Da wird der verschlüsselte TS reingeschrieben und mit einem anderen Thread sollte das Entschlüsslte ausgelesen werden können (vorausgesetzt CAM und Karte können es entschlüsseln und das ca-device wird korrekt mit Daten beliefert).

Das /dev/*/ciX-Device müsste derzeit als /dev/*/secX erzeugt werden (so ists im Vanilla-Kernel mit "Vanilla"-ddbridge auch), für /dev/*/ciX sind diese beiden Mini-Patches verantwortlich. Ob diese API-Ergänzung wirklich zwingend notwendig ist, sei mal dahingestellt (vdr-ddci oder andere Software kann bestimmt auch mit einem anders benannten Device Node arbeiten). Fraglich sind halt die drei Commits, die direkt den cxd2099- sowie dvb_ca_en50221-Code verändern.

Zitat von mini73

Ich werde aber nicht schnell sein, ich muss erst mal lernen, wie ich das am besten unter Ubuntu baue und verpacke, so dass ich jederzeit auch wieder zurück kann. Hab also Geduld...

Alles gut, kein Stress Der Kram der letzten Tage muss jetzt eh erstmal sacken

Daniel

mini73: Ich möchte mich morgen mal an ein dkms PKGBUILD für Arch setzen. Da kannst du dann sicherlich von abgucken.