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

Zitat von UFO

Ich habe die erste Version submitted, die mehr oder weniger in allen Kerneln gleich ist. Kurz danach hat Mauro begonnen, im DRXK herumzupfuschen. Darauf habe ich beschlossen, bis auf weiteres nichts mehr zu submitten...

Also mit anderen Worten: Mein experimtal Treiber vom Feb 2012 ist in den Kernel 3.5.x und höher?

Heißt das jetzt, dass in den aktuellen Kernels der ältere Code drin ist? Also brauche ich doch das Zusatzpatchen.

Älter als Feb 2012, den ich derzeit im Einsatz habe. Aber jetzt weiß ich endlich genau Bescheid.
Danke.

Der TT DVB S2-6400 Zweig scheint wohl tot zu sein?

"make untar" bleibt hängen bei:

vdr01 media_build_experimental # make untar
make -C linux/ untar
make[1]: Entering directory `/tmp/media_build_experimental/linux'
tar xfj linux-media.tar.bz2
rm -f .patches_applied .linked_dir .git_log.md5
../experimental/add-drivers


# Add ngene & octopus
fetch_hg_repo "http://linuxtv.org/hg/~endriss/ngene-octopus-test" "ngene-octopus-test"
requesting all changes
adding changesets
adding manifests
adding file changes
added 15243 changesets with 37436 changes to 2913 files
updating to branch default
1756 files updated, 0 files merged, 0 files removed, 0 files unresolved
rm -Rf ../linux/drivers/media/pci/{ddbridge,ngene} ../linux/drivers/staging/media/cxd2099
cp -r ngene-octopus-test/linux/drivers/media/dvb/{ddbridge,ngene} ../linux/drivers/media/pci/
cp -r ngene-octopus-test/linux/drivers/staging/cxd2099 ../linux/drivers/staging/media/
cp ngene-octopus-test/linux/drivers/media/dvb/frontends/tda18212dd* ../linux/drivers/media/dvb-frontends/
cp ngene-octopus-test/linux/drivers/media/dvb/frontends/stv0367dd*  ../linux/drivers/media/dvb-frontends/
patch -d.. -p0 < stv0367dd-tda18212dd.frontend-kconfig.diff
patching file linux/drivers/media/dvb-frontends/Kconfig
patch -d.. -p0 < stv0367dd-tda18212dd.frontend-makefile.diff
patching file linux/drivers/media/dvb-frontends/Makefile
cp -r drxk/* ../linux/drivers/media/dvb-frontends/


# Add TT DVB S2-6400
fetch_hg_repo "http://powarman.dyndns.org/hg/v4l-dvb-saa716x" "v4l-dvb-saa716x" || fetch_hg_repo "http://linuxtv.org/hg/~endriss/mirror-saa716x" "v4l-dvb-saa716x"

Zitat von 3PO

Der TT DVB S2-6400 Zweig scheint wohl tot zu sein?

Hat bei mir letztes Wochenende noch geklappt. Wenn Du ihm etwas Zeit bis zum Timeout lässt, sollte das zweite (alternative) Fetch starten bzw. den ersten Fetch temporär aus dem Skript ausbauen

Zitat von FireFly

Hat bei mir letztes Wochenende noch geklappt. Wenn Du ihm etwas Zeit bis zum Timeout lässt, sollte das zweite (alternative) Fetch starten bzw. den ersten Fetch temporär aus dem Skript ausbauen

Wieviel timeout gönnt er sich denn? Nach 15 Min. habe ich abgebrochen und das file entsprechend gepached, dann ist durchgelaufen.

--- experimental/add-drivers.orig	2013-01-13 11:29:53.000000000 +0100
+++ experimental/add-drivers	2013-01-13 11:32:07.000000000 +0100
@@ -37,7 +37,7 @@
 cp -r drxk/* ../linux/drivers/media/dvb-frontends/
 
 # Add TT DVB S2-6400
-fetch_hg_repo "http://powarman.dyndns.org/hg/v4l-dvb-saa716x" "v4l-dvb-saa716x" || fetch_hg_repo "http://linuxtv.org/hg/~endriss/mirror-saa716x" "v4l-dvb-saa716x"
+fetch_hg_repo "http://linuxtv.org/hg/~endriss/mirror-saa716x" "v4l-dvb-saa716x"
 rm -Rf ../linux/drivers/media/pci/saa716x
 cp -r v4l-dvb-saa716x/linux/drivers/media/common/saa716x  ../linux/drivers/media/pci/
 patch -d.. -p0 < saa716x.pci-kconfig.diff

Zitat von UFO

Kurz danach hat Mauro begonnen, im DRXK herumzupfuschen. Darauf habe ich beschlossen, bis auf weiteres nichts mehr zu submitten...

Uups! Das hört sich aber nicht sehr gut an
Deine Änderungen sind sehr wichtig und gehören in den Stock Kernel! Anders ist die Wartung auf lange Sicht unmöglich. Freiwillig am Kernel mit zu tun ist schon Arbeit genug, aber dann auch noch einen Branch selber lange pflegen zu müssen ... .
Was war den der Grund

Es wäre doch für dich viel besser, wenn die Änderungen im Main Kernel wären, weil dann müssen die anderen Entwickler auf deinen Code Rücksicht nehmen. Ich weiß schon, dass die Maintainer durchaus "schwierig" sein können, aber am Ende kann man sich doch einigen.
Schließlich sind wir alle Techniker, die ein Ziel haben, nämlich einen guten Support der verfügbaren Karten für eine HDTV Anwendung unter Linux.

LG
Jasmin

Zitat von jasminj

LG
Jasmin

Jo. +1

Hallo Zusammen,

mit ist gerade aufgefallen, dass ich mit der Cine-S2 V6.5 ein Problem mit dem "Poweroff" habe.

Mit der V5.x gab es das Problem, in Verbindung mit ION Boards schonmal. Soweit ich mich recht erinnere, gab es dafür einen Workaround. Gibt es für die V6.x auch einen, bzw. ist das Problem bekannt?

Wenn ich meine Octopus PCIe einbaue, habe ich o.g. nicht.

Ich habe in Moment ein "Asrock G41MH/USB3" im Einsatz.

hallo,

mein vdr generiert teilweise falsche channels.conf einträge.

Die Modulation stimmt nicht, die Sender sind dann nicht zuverlässig tunebar.

falsch:
AXN HD;SKY:11332:hC34M16O35S1:S19.2E:22000:255:0;259=deu,260=eng:32:1833,9C4,98C:125:133:10:0

richtig:
AXN HD;SKY:11332:hC34M5O35S1:S19.2E:22000:255=27:0;259=deu@106:32:1833,9C4,98C:125:133:10:0

kann man da was machen?
gruss, onur

PC mit FF und Budget, 1.7.35 laeuft. Wollte budget gegen Cine S2 6.5 mit erst mal vier Tunern (also einer flex karte zusaetzlich) ersetzen. Habe da laut anweisung die Treiber aus media_build_experimental fuer den Kern gebaut. Geht wohl im Prinzip, aber zwei Probleme:

1. Meine Streamzap/Lirc Fernbedienung ist "sluggish" nachdem die media_build_experimental Treiber laufen. Ich habe dann mal probehalber probiert, im media_build_experimental die RC Teile herauszukommentieren (so dass die da nicht gebaut werden), und vom originalen modulbaum nicht das ganze driver/media zu loeschen, sondern media/rc stehen zu lassen. Das sah auch soweit gut aus (make install hat da nix uebergebuegelt), aber der kern ist dann gecrashed (3.1.6 kern).

Frage 1: Macht das Sinn da weiter rumzuprobieren, oder kann das garnicht funktionieren ? (kann nicht so recht verstehen warum da eine Abhaengigkeit zwischen den DVB und den RC Treibern sein sollte).

Frage 2: Irgendeine andere Idee wie ich schauen sollte, warum das so "sluggish" ist ?

Frage 3: Nachdem es ja wohl einen ddbridge Treiber direkt im 3.1.6'er Kern gibt, gibts da nicht eine einfachere moeglichkeit, die 6.5'er zum laufen zu bringen ?

2. Ich glaube auf meiner 6.5'er wird die draufgesteckte cineflex nicht erkannt. Ich habe derzeit die Cine S2 mit einer cineflex (auf dem mittleren stecker der Cine S2 befestigt) drauf und die FF. Und ich sehe nur drei adapter in /dev/dvb. Was sollte ich da als naechstes machen ?

Danke!

Ich habe heute ein Kernel Update gemacht (3.7.4) und nutze die ddbridge aus dem Kernel. In VDR (sttng Skin) und femon-Plugin habe ich nun zwar noch eine Anzeige für SNR, aber die Darstellung als Balken fehlt. Der STR Balken wird aber weiterhin dargestellt.

Nach einigen Tagen suchen, denken, Kontakt zu L4M, eMails mit dem ursprünglichen Treiber Entwckler austauschen und 2 Nächten ohne Schlaf, habe ich heute beim eMail Scheiben ein lange schlummerndes Problem im CI Protokoll Treiber dvb_ca_en50221.c gefunden.

Dieser Treiber implementiert das Protokoll, welches in der EN 50221 von 1997 spezifiziert wurde und die PCMCIA Schnittstelle zum CAM beschreibt. Auf nur 2 Seiten von 86, werden dort ein paar Status Bits und Antworten dazu beschrieben.

In dem Treiber gibt es die Routine dvb_ca_en50221_write_data, welche den Write Zugriff auf das CAM implementiert. Laut Protokoll muss man das HC Bit setzen und dann das FR Bit Abfragen. Das ist auch so implementiert, allerdings hat der Papa des Treibers auf die darunter liegende Hardware vergessen. Wenn diese nicht direkt und unmittelbar in das CAM schreibt, bzw. von diesem liest, dann stimmen die Bits nicht mit der Wirklichkeit überein und es wird ein Write eingeleitet, obwohl das CAM einen Read angefordert hat (DA Bit gesetzt).
Beim CI von L4M/DD (CineS2) ist zwischen dem PCMCIA Bus und dem Prozessor ein Intelligenter Interface Chip. Der cxd2099ar, von Sony, zu dem man das Datenblatt nicht findet, da man das nur mit einem NDA bekommt. Dieser Chip wird über i2c vom Prozessor aus angesteuert. Die Details der HW kenne ich nicht, ist aber auch Wurst. Wie man sich denken kann, dauert so ein i2c Zugriff etwas Zeit und wir haben den Salat!
Die Routine schreibt das HC Bit, liest sofort die Antwort zurück und leitet den Write ein. Dieser geht dann schief, was man am gesetzten WE Bit merkt. Das führt dann zu einem Fehlercode in der write Funktion und der VDR initialisiert das CAM neu. Bei dem Zugriff gibt dann das CAM die Daten vom ursprünglich eingeleitet RD zurück und man bekommt die Fehlermeldung:
"dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size!"
Wenn man das googelt, dann findet man das Problem schon seit einigen Jahren.

Mein Patch fügt einen Modul Parameter cam_write_wait hinzu, mit dem man eine Wartezeit in Millisekunden nach dem HC Bit schreiben einfügen kann. Damit hat die HW genug Zeit das HC Bit und die Antwort zu übertragen und das Protokoll spielt.

Das Problem tritt sehr wahrscheinlich nur bei CAMs auf, die nur einen Buffer für RD und WR haben und auch nicht immer, weil es ja zufällig ist, ob der WR und der RD zusammen fallen.
Im Zuge meiner Recherchen habe ich den Treiberentwickler angeschrieben und er hat sich den cxd2099 Treiber noch einmal angesehen. Dabei seinen ursprünglich angefangenen Code für die Aktivierung des Buffers im cxd2099 weiter geschrieben und muss das jetzt nur noch testet. Wenn das fertig ist, würde es beim besagten CI auch ohne meinen Patch gehen, allerdings tritt der Fehler auch bei anderen Karten auf, weshalb der Patch in den Stock Kernel sollte. Deshalb habe ich auch einen Parameter gemacht, damit standardmäßig nicht gewartet wird.

Es reicht übrigens einen Wert von 1 für den neuen Modul Parameter cam_write_wait zu setzen, weil daraus jiffies werden und die zählen sowieso in größeren Schritten.

Es ist auch noch ein anderer Patch dabei, der einen Mutex für den ioctl Zugriff dazu fügt. Der stammt nicht von mir, sondern vom LinuxTV Repository. Bitte zuerst den mutex Patch und dann den write_wait Patch anwenden.

Vieleicht könnte der eine oder andere Wissende den Patch mal reviewen und testen.

LG
Jasmin

Hallo Jasmin,

habe mein CAM an einer TT S3200 stecken,
sollte ich die Patches auch einspielen ?

Zitat von frithjof

habe mein CAM an einer TT S3200 stecken,
sollte ich die Patches auch einspielen ?

Guckst du hier.
Wenn dein CAM an der Karte auch funktioniert gibt es ja keinen Grund dazu. Never touch a running system!

Wenn du doch Probleme hast, insbesondere wenn die zitierte Fehlermeldung kommt, dann könnte dir der Patch helfen, wenn es an einer Race Condition zw. einen WR und einen RD liegt. Das festzustellen ist ein wenig schwierig, aber man kann das mit dem aktuellen Treiber auch feststellen, wenn man cam_debug=1 als Modul Parameter angibt. Dann kommen viele Ausgaben ins syslog und ich kann dann versuchen qualifiziert zu raten, welche Ursache du für deine Probleme hast (so du welche hast). Bei mir war das recht bald nach dem vdr starten zu sehen.
Mit meinem Patch kommt eine neue Fehlerausgabe ins syslog, die explizit diese Race Condition erkennt.

Edit:
Den Mutex Patch braucht es nur dann, wenn mehrere Threads auf den Treiber zugreifen. Ich kenne den VDR Code hier noch nicht. Am HEAD ist der Patch vom Entwickler bereits drauf, weil solche Dinge MUSS man einfach im Kernel richtig machen, damit das Thread Save ist.

Ich habe noch etwas in der Erklärung vergessen:
Das Protokoll schreibt das HC Bit in das CAM. Das bedeutet für das CAM, dass der Host etwas senden möchte. Danach fragt das Protokoll das Free bit ab, aber nur dieses, und vergisst dabei das DA Bit, mit dem das CAM eine Leseanforderung signalisiert. Das DA Bit hat das Protokoll zwar bereits vorher abgefragt, aber es vergeht eben Zeit zw. dem ersten DA prüfen und dem HC setzen. Also muss man danach noch einmal das DA Bit prüfen, weil erst ein gesetztes HC, weitere DAs verhindert. Dieses zusätzliche Prüfen macht mein Patch, weil das bei jedem CAM vorkommen kann und eine Race condition darstellt.
Zusätzlich habe ich noch das umstrittene Timeout, parametrierbar, nach dem HC Bit setzten dazu gegeben, damit wirklich genug Zeit bleibt um auch bei ganz langsamer (alter) HW keine Race condition zu haben. Wenn solch eine auftritt, sieht man das jetzt durch einen Logging Eintrag, wenn debugging eingeschaltet ist.

Im Übrigen kann man das alles aus dem Code lesen, wenn man den Patch applied, was ich mir schon ausbitte, wenn meine Arbeit kritisiert wird, egal ob jetzt positiv oder negativ.

EDIT Beginn, nachdem bei der Löschaktion was technisches verloren ging:
Ich habe auch einige andere Lösungen ausprobiert. Das fängt beim Erkennen des WR Errors an und einem Retry und schließt auch einen neuen State mit vorherigem RS Kommando an das CAM ein. Letzteres scheiterte am VDR, der das CAM nach einem Fehler komplett resetiert. Bei der Retry Lösung Blieb die Kommunikation mit dem CAM aufrecht, aber der VDR hat sich dann mit dem CAM nicht mehr verstanden. Dazu wollte ich das CI Protokoll (Link und Session Layer) im VDR debuggen, weil meiner Meinung nach müsste das der VDR verkraften, aber ich hatte dann beim Durchdenken diese Lücke in der Implementierung gefunden. Möglicherweise hat auch mein CAM nach einem WR Error ein Problem.
Aber du hast recht, ich könnte noch 20 Stunden in die VDR CI State Maschine investieren und versuchen, dass der das dann richtig macht. Oder erkennen, dass mein CAM den Reset verlangt. Trotzdem würde es zu einem WR Error beim CAM kommen, der laut EN50221 eigentlich einen CAM Interface Reset erfordern würde. Dieser würde in 8 von 10 Fällen passieren. Super Lösung!
Aber du hast insofern recht, dass DIE Lösung in einer 100% funktionierenden HW liegt, was eine HW braucht, die immer sofort die CAM Register, mit den aktuellen Bits enthält. Dann funktioniert alles, wie es soll. Wir werden das im cxd2099 Treiber auch versuchen hin zu bekommen, dass diese Requirements erfüllt sind. Bis dahin und für HW, die diese Requirements nicht erfüllen kann, dafür ist mein neuer Timer, der im Übrigen ein Modul Parameter ist, was bedeutet, dass er per default nicht aktiviert ist.
EDIT Ende

Zitat von UFO

Der Workaround kommt selbstverständlich in media_build_experimental, da er
(a) nichts kaputt macht und
(b) das Problem erst einmal behebt.

Falls es später eine bessere Lösung gibt, kann man es ja wieder herausnehmen!

Das glaube ich nicht, dass wir das sollten, weil es eben auch andere HW gibt, wo man den HW Layer nicht in der Hand hat und dann kommt es zu den Problemen, die seit einigen Jahren immer wieder auftauchen. Ev. das Timeout entfernen, aber das DA Bit nach dem HC setzten sollte drinnen bleiben.

Zitat von UFO

@Jasmin
Falls Du offiziell als Patchautorin in den Repositories genannt werden möchtest, mußt Du gewisse Regeln einhalten (vgl. <kernel>/Documentation/SubmittingPatches bzw. README.patches in media_build).
...Dies ist insofern wichtig, als daß es bei Opensource außer der Ehre (und Beschimpfungen?) nichts zu verdienen gibt...

Brauchst du das auch schon für yaVDR?
Für den Trunk ist mir das klar. Ich muss nur erst mit git klar kommen, verwende beruflich nur SVN.
Und ja, wenigstens ein kleines Sternchen habe ich mir verdient

Noch ein Gedanke:
Ev könnte man prinzipiell das HC Bit setzen und dann erst DA abfragen. Wenn man eine schnelle HW hat, die direkt auf die CAM Register zugreift, würde das auch gut funktionieren, denke ich, und es wäre SPEC konform, so wie ich sie interpretiere. Muss ich mal bei mir ausprobieren. Vielleicht geht es dann ohne Timout.
Hey, danke Jungs , jetzt habe ich durch das beschreiben hier eine mögliche Verbesserung meines Patches gefunden. DAS, passiert, wenn man ein Review macht und deshalb steht das alles hier!