Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

Ich habe mich nun auch dran gewagt. Ich kann auch bestätigen, dass es nun besser geworden ist. Vielen Dank für die ganzen Patche.

Freut mich, dass die Patches auch bei euch das Wiedergabe-Verhalten der S2-6400 verbessern. Leider habe ich momentan keine Idee mehr, wie man die verbleibenden Unschoenheiten im Treiber fixen koennte. Falls jemand Zugriff auf FPGA und Firmware hat, bin ich gerne bereit, dort beim Fixen zu helfen. Aber das ist vermutlich eher ein rechtliches denn ein technisches Problem.
UFO: Kannst Du auch den 4. Patch mit in Dein Repository aufnehmen, der bringt bei mir schon noch mehr Stabilitaet. Oder hast Du noch Aenderungsvorschlaege?

Gruss,
S:oren

Zitat von UFO

Die Konstruktion mit TSOUT_STAT_* gefällt mir nicht besonders. Riecht irgendwie nach Deadlock. Was passiert, wenn die Applikation niemals VIDEO_CLEAR_BUFFER aufruft?

Nichts. Das VIDEO_CLEAR_BUFFER loescht neuerdings nur auch den FPGA-Fifo, nicht nur den Treiber-Puffer. Ansonsten spiegelt das TSOUT_STAT_RESET nur das Reset-Bit im FPGA_ADDR_FIFO_CTRL, wenn gesetzt, wird einfach nicht in den Fifo geschrieben (Fifo ist ja sowieso im Reset - oder nach Power-up nicht enabled). Wenn das Fifo enabled ist (schon immer erst nach SELECT_SOURCE), dann wird das durch TSOUT_STAT_FILL oder TSOUT_STAT_RUN gekennzeichnet. Nach dem VIDEO_SELECT_SOURCE oder VIDEO_CLEAR_BUFFER ist der State erstmal TSOUT_STAT_FILL. Hier wird zunaechst der Treiberpuffer mit TS-Paketen gefuellt. Da jedes TS_Paket einzeln an den Kernel uebergeben und mit copy_from_user geprueft wird, erzeugt das einige Last. Erst wenn der Treiber-Puffer zu einem Drittel gefuellt ist, wird mit dem Kopieren in das FPGA-Fifo begonnen und in den TSOUT_STAT_RUN-State gewechselt. Das hat zwei Vorteile: erstes wird nicht jedes Paket auch noch einzeln zum FPGA kopiert, was dann zusaetzlich zum syscall und copy_from_user-check auch noch je einen Interrupt und Start des fifo_workers bedeutet. Zweitens hat man etwas Reserve, wenn mal nicht sofort TS-Pakete nachkommen.
Der Trick mit TSOUT_STAT_FILL fuehrt also zu geringerer Systemlast direkt nach dem Pufferstart und zu fortlaufend vorhandenen und in groesseren Blocken kopierbaren Paketen und damit keiner Unterbrechung im Datenstrom. Dadurch wird das Ruckeln und Stottern minimiert. Nur direkt nach dem Umschalten gibt es manchmal einen kurzen Schluckauf (nach Zeitlupen-Wiedergabe etwas laenger), das hat meiner Meinung nach aber nichts mit dem TS-Strom zu tun, sondern mit der Audio-Video-Synchronisation in der Firmware.

Ansonsten denke ich, dass selbst das Kopieren des Datenstroms in einzelnen 32-bit-Worten deutlich (Faktor 3 bis 5?) schneller sein sollte bei der Datenrate. Vermutlich bremst das FPGA (eine ready_mask von 0 heisst vermutlich, dass alle PHI_RDY-Signale aktiv sind!?), ich vermute dort also auch noch einiges Optimierungspotenzial...

Gruss,
S:oren

Hallo UFO:

Ich find deine Beschreibung einfach nur toll. Danke.
Leider scheint Digital Device wieder was verändert zu haben.
Nach einigen Fehlversuchen das Modul ddbridg mit meiner (frisch erworbenen) Karte Octupus CI zu verbinden,
habe ich festgestellt, dass es Untetschiede zwischen der Codierung der Karte und den Eintragungen in ddbridge gibt:

lspci -vvvnn:

07:00.0 Multimedia controller [0480]: Digital Devices GmbH Device [dd01:0011]
Subsystem: Digital Devices GmbH Device [dd01:0041]
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 5
Region 0: Memory at fb800000 (64-bit, non-prefetchable)
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] MSI: Enable- Count=1/2 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [90] Express (v2) 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, Latency L0 unlimited, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range A, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=00c <?>

modinfo ddbridge:
filename: /lib/modules/3.2.0-32-generic-pae/kernel/drivers/media/dvb/ddbridge/ddbridge.ko
version: 0.8
license: GPL
author: Ralph Metzler
description: Digital Devices PCIe Bridge
srcversion: 533BB7E5866E52F63B9ACCB
alias: pci:v0000DD01d00000003sv*sd*bc*sc*i*
alias: pci:v0000DD01d00000011sv0000DD01sd00000040bc*sc*i*
alias: pci:v0000DD01d00000003sv0000DD01sd0000DB03bc*sc*i*
alias: pci:v0000DD01d00000003sv0000DD01sd00000030bc*sc*i*
alias: pci:v0000DD01d00000003sv0000DD01sd00000020bc*sc*i*
alias: pci:v0000DD01d00000003sv0000DD01sd00000010bc*sc*i*
alias: pci:v0000DD01d00000003sv0000DD01sd00000003bc*sc*i*
alias: pci:v0000DD01d00000003sv0000DD01sd00000002bc*sc*i*
alias: pci:v0000DD01d00000003sv0000DD01sd00000001bc*sc*i*
alias: pci:v0000DD01d00000002sv0000DD01sd00000001bc*sc*i*
depends: cxd2099,dvb-core
vermagic: 3.2.0-32-generic-pae SMP mod_unload modversions 686
parm: adapter_alloc: 0-one adapter per io, 1-one per tab with io, 2-one per tab, 3-one for all (int)
parm: ts_loop: TS in/out on port ts_loop (int)
parm: adapter_nr: DVB adapter numbers (array of short)

Geh ich richtig in der Annahme, daß ich deshalb die Karte und ddbrid nicht zusammenbringe.
Und wenn ja, wie kann ich Abhife schaffen?
Herzlichen Dank im Voraus.

Danke,

ich habe nach Deinen Vorgaben die Datei eigefügt und siehe da, die Karte wurde erkannt.
Also prinzipiel funktioniert es. Ich habe es mit Kaffein mit guten Ergebnissen ausprobiert.
Nun benutze ich aber MythTV (unter Ubuntu), und dort habe ich Probleme mit dem Empfang.
Das Backend erkennt noch alle Sender aber das Frontend logt sich in keinen Sender ein.
Ich suche weiter nach meinem Fehler.

So nach eingen Tests (auch unter Windows) hab ichs mir total versaut:
Hab einfach aus Frust (nach dem die Karte nicht mal unter WindowsMediaCenter vernünftig lief)
die neue FW V1.1 von DD auf die Karte geladen.
Danach leif Sie unter WMC ohne Problem.
Ich wil mich aber von Windows verabschieden.
Also Ubuntu neu installiert. Nach den Angaben hier die neuen Treiber nachgeladen:
Jetzt klappt es nicht mehr. Bei modprobe ddbridge kommt immer:
FATAL: Error inserting ddbridge (/lib/modules/..../ddbridge.ko): Invalid argument
Ich glaub ich muß auf eien überarbeitetes Modul warten.
Oder wie kann ich den Fehler eingrenzen?
Oder hat jemand nne Idee, wie ich die alte FW wieder reinbekommen?

OK, danke für diese Gedankenstütze. Ich habe aus dmesg folgendes rausgefiltert:

[ 14.346721] cxd2099: module is from the staging directory, the quality is unknown, you have been warned.
[ 14.370196] WARNING: You are using an experimental version of the media stack.
[ 14.370198] As the driver is backported to an older kernel, it doesn't offer
[ 14.370199] enough quality for its usage in production.
[ 14.370200] Use it with care.
[ 14.370200] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org
[ 14.370202] da2cd767f537082be0a02d83f87e0da4270e25b2 [media] ttpci: add support for Omicom S2 PCI
[ 14.370203] 062ef0d4bb66e975a79dec4d5cc3ef1bf584efef [media] staging: media: Remove easycap driver
[ 14.370204] 9cb2173e6ea8f2948bd1367c93083a2500fcf08f [media] media: Add stk1160 new driver (easycap replacement)
[ 14.493506] ddbridge: disagrees about version of symbol cxd2099_attach
[ 14.493510] ddbridge: Unknown symbol cxd2099_attach (err -22)

Nach weiteren Recherchen mußte ich feststellen, dass bei make install die cxd2099.ko im Stammverzeichniss /lib/modules/.... nich duch die aktualisierte Version ersetzt wurde.
Hab ich also von Hand gemacht und siehe da:

[ 14.550093] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
[ 14.550132] DDBridge 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 14.550139] DDBridge driver detected: Digital Devices Octopus CI single
[ 14.550162] HW 00010006 REG 00010002
[ 14.550242] DDBridge 0000:07:00.0: irq 53 for MSI/MSI-X
[ 14.551963] Port 0 (TAB 1): DUAL DVB-C/T
[ 14.553509] Port 1 (TAB 2): DUAL DVB-C/T
[ 14.553512] Port 2 (TAB 3): CI internal
[ 14.554198] DVB: registering new adapter (DDBridge)
[ 14.610066] stv0367 found

Danke Oliver

Jetz muss ich nur noch das CI-Modul einbinden und dann bin ich glücklich.
Gibt es eigendlich schon eine Lösung für Multi Transponder Decrypting unter Linux?

Gruß Matthias

Zitat von UFO

Upstream media_build ist nach wie vor unbrauchbar, vgl. Postings "cron job: media_tree daily build: ERRORS" auf der ML.
Solange sich dies nicht ändert, fange ich gar nicht erst mit den Anpassungen an...

CU
Oliver

Ich wollte mal nachfragen, ob der Upstream immer noch eingefroren ist?

Seit ich die aktuelle Treiberversion (über 'hg clone http://linuxtv.org/hg/~endriss/media_build_experimental') benutze ist es mir schon diverse male passiert, daß die Wiedergabe hängengeblieben ist, wenn ich nach einem schnellen Vor-/Rücklauf wieder auf Play geschaltet habe, oder mit Grün/Gelb mehrfach um eine Minute gesprungen bin. Damit es dann weitergeht muß ich erneut kurz einen schnellen Vor-/Rücklauf machen, und dann funktioniert Play wieder.

Hat das sonst auch jemand beobachtet?

Die TT S2-6400 Firmware ist die 0.3.8, und das dvbhddevice Plugin ist auf dem aktuellen Stand von http://powarman.dyndns.org/hgwebdir.cgi/dvbhddevice.

Klaus

Ja, ich Das kommt bei mir, wenn ich die Sprungtasten zu schnell hintereinander drücke. Das Bild bleibt dann stehen. Ein erneuter Sprung und alles läuft wieder...

Zitat von UFO

Verschwindet das Problem, wenn man den Patch "experimental/patch.d/504_saa716x-tsout_cleanup.hg.diff" herausnimmt?

Ich werde mir den Patch nochmal ansehen und ggf. eine neue Version vorstellen. Brauche dann mal einen Tester, bei mir tritt das Problem nicht auf.

Gruss,
S:oren

Hi UFO (u.a.),

nach nun über einem halben Jahr, will (muss) ich meinen Server updaten, der auch als VDR-Server dient. Damals (Febr. 2012) noch mit dem media_build_experimental gebaut und dem 3.2.1er Kernel, funktioniert mein System richtig gut und stabil:

Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
DDBridge 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
DDBridge driver detected: Digital Devices Octopus CI
...
DDBridge 0000:07:00.0: irq 72 for MSI/MSI-X
Port 0 (TAB 1): DUAL DVB-S2
Port 1 (TAB 2): DUAL DVB-S2
...
stv6110x_attach: Attaching STV6110x
attach tuner input 0 adr 60
DVB: registering adapter 0 frontend 0 (STV090x Multistandard)...
LNBx2x attached on addr=9

Da ich trotz des vielen Lesens nicht so recht damit klar komme, ob ich nun auf den neuen Kernel linux-3.5.7-gentoo (und nur diesen) oder wieder auf media_build_experimental zurückgreifen kann die Frage an Euch. Lieber wäre mir der Kernel, doch funktioniert dann mein VDR immer noch stabil?

Danke & Gruß
Thomas

PS: Ein Update auf VDR-1.7.31 kommt damit auch ein her.

Also bei mir läuft der Treiber mit linux-3.6.6-gentoo stabil.

Zitat von S:oren

Zitat von »UFO«
Verschwindet das Problem, wenn man den Patch "experimental/patch.d/504_saa716x-tsout_cleanup.hg.diff" herausnimmt?

Ich werde mir den Patch nochmal ansehen und ggf. eine neue Version vorstellen. Brauche dann mal einen Tester, bei mir tritt das Problem nicht auf.

Hier eine neue Version. Ich hoffe, die funktioniert besser.
Da das Haengenbleiben beim Springen in der Wiedergabe bei mir nicht auftritt, kann ich den Erfolg nicht testen. Aber diese Version funktioniert bei mir zumindest nicht schlechter.

Gruss,
S:oren

Hallo,

um die letste version von http://linuxtv.org/hg/~endriss/media_build_experimental mit Mythtv zu nutzen musste ich diesen patch installieren:

http://patchwork.linuxtv.org/patch/13563/

Without the patch I couldn't configure the tuners (they would work without the patch, but myth didn't get the details of the tuners ).

this is on 3.2.0-32-generic (current version of mythbuntu) using CineS2.

Walter