Umbau FF Rev 1.3-2.2 -> Rev 2.3 + AV-Board

Zitat

Original von morus
Eine FF mit defektem ARM hätte ich zum Testen parat. Nur an Zeit mangelt es...

Dann würde es sich ja eigentlich anbieten die beiden AV7110s zu tauschen.
Irgendwo hab ich schon mal 'ne Anleitung für den Austausch von BGA-ICs gesehen. Die hatten es, glaube ich, mit Heissluft von unten gemacht. Kaputt gehen kann bei so einer Karte eh nicht mehr viel.

Die Versorgungsspannungen, also das was aus den Linearreglern rauskommt, hast du schon gecheckt?
Und der Oszillator läuft auch an?

Zitat

Original von morus

Hab das inzwischen versucht, leider ohne Erfolg. Das Löten war mit einer professionellen Rework-Station kein Problem,

Toll, auf was für Werkzeug Ihr zurückgreifen könnt.

Zitat

ich habe aber immer noch den "debi test in av7110_bootarm() failed" Fehler. Vermutlich war der ARM doch nicht tot, sondern der SAA7146 oder das DPRAM.

Wenn der Debi-Test schief geht, kommen eigentlich nur der saa7146 oder das DPRAM bzw. deren Spannungsversorgung in Frage. (Der ARM wird hierzu nicht gebraucht, der kommt erst bei "boot arm" / "load dram" ins Spiel.)

CU
Oliver

Zitat

Original von morus
Wie in UFOs Thread zum 'full-ts mod' bereits erwähnt, habe ich mir aus einer rev. 1.3 Full Featured Karte und dem in diesem Thread beschriebenen Premiere Receiver Imperial P1S eine Twintuner FF gebastelt. Der Receiver dient dabei auch als AV-Board und VDR-Sanitizer. Das ganze läuft bei mir seit ein paar Tagen problemlos.

Eine kleine Anleitung befindet sich als Kommentar im source code des Treibers (siehe patch im Anhang).

Bilder gibts sobald ich mir eine Digicam besorgt habe.

UFO:
Wäre es möglich den patch in deinen Treiber zu übernehmen? Er beinhaltet auch deinen patch für den 22kHz Ton über GPIO3. Ich musste ihn etwas abändern, da ich den GPIO3 auch für das AC3-PLD gebraucht habe.

Alles anzeigen

Ich denke, da müssen wir vorher noch ein paar Hühnchen rupfen.
Muß mir das noch genauer anschauen, einiges ist mir aber jetzt schon aufgefallen.

Die Source-Duplizierung für lnbp21 gefällt mir überhaupt nicht. Da gibt es sicher eine bessere Lösung. Ditto für bsbe1.

Es sollte möglichst keine Kommandozeilen-Optionen geben. (Auch der full-ts Parameter wird vermutlich rausfliegen.) Flags im EEPROM sind ausreichend. Werde zum Bearbeiten noch ein ordentliches Tool schreiben.

Wieso mußte der 22kHz-Patch geändert werden? Kann ich nicht so recht erkennen. Die beiden Features schließen sich aus, d.h. wir gehen einfach davon aus, daß das EEPROM richtig programmiert ist. Und gut ist.

Was hat es mit dem Non-Audio-Flag auf sich? Wieso wird es beim Laden des Treibers gesetzt und nicht dann, wenn es gebraucht wird?
Falls dies stimmt:

/*FIXME
On Rev 2.3 cards this GPIO seems to control wheter the AC3-PLD sets or clears the non-audio bit in the SPDIF stream.
So it should be set dynamically to 0 for PCM and to 1 for AC3 streams. This behavior could be measured at an TT STB,
where obviously the same PLD is used.*/

dann sollte sich endlich mal ein Besitzer einer solchen Karte darum kümmern, damit es im Treiber korrigiert werden kann.

Der richtige Ort zum dynamischen Umschalten wäre imho der AUDIO_SET_BYPASS_MODE-Ioctl.

Was mir gar nicht gefällt, ist der zweite DVB-Adapter. Das zweite Frontend gehört zum gleichen Adapter wie das erste. Der Ansatz beim Budget-Patch ist imho richtig.

Unter /dev/dvb/adapterX
1. Tuner -> demux0, dvr0, frontend0, ...
2. Tuner -> demux1, dvr1, frontend1, ...
usw.

Applikationen müssen mit mehr als einem Tuner je Adapter rechnen. Andernfalls wäre die Möglichkeit, mehrere Tuner pro Adapter zu haben, API-mäßig völlig sinnlos.

Auf VDR bezogen: Bei der Initialisierung sollte auf frontend1/demux1 getestet werden und diese ggf. auch verwendet werden. Evtl. läßt sich Klaus ja überzeugen.

CU
Oliver

Zitat

Original von morus

Gefällt mir auch nicht, war halt nur die einfachste Möglichkeit ohne dass andere Treiber angepasst werden müssen.

Für eine Testversion ist das ja auch ok, nur nicht für die endgültige...

Zitat

Erstens ging es mir darum die Zugriffe auf den I2C bus zu minimieren, d.h. ich wollte nicht jedesmal wenn das non-audio bit gesetzt wird auf den I2C bus zugreifen müssen, da man der Störungen wegen bei Tunern eigentlich sparsam mit I2C Zugriffen sein sollte. Da aber die dynamische Umschaltung des non-audio bits bisher noch nicht implementiert ist spielt das keine Rolle.

Man muß doch nicht jedes Mal auf den I2C-Bus zugegreifen! Man liest das EEPROM nur einmal während der Initialisierung. Im laufenden Betrieb reicht es, den GPIO3 in Abhängigkeit eines Flags zu setzen.

Zitat

Zweitens habe ich sicherheitshalber den defekten GPIO8 des AV7110 auf low programmiert, da an diesem Pin normalerweise ein Kurzschluss nach Masse vorliegt. Anderfalls könnten die dabei fliessenden (Substrat-)Ströme zu einem Latch-Up führen oder gar auf Dauer den Chip zerstören.

Besser wäre "Input" oder "Tristate". Muß ich mir in der FW mal anschauen.

Zitat

Kein Problem, solange der VDR damit klar kommt...

Leider tut er das derzeit nicht. Aber im Hinblick auf Dual-Tuner-Karten wäre das imho schon sinnvoll.

CU
Oliver

Zitat

Original von morus

Und genau das habe ich auch gemacht. Deshalb die Änderung.

Verstehe ich nicht. Bei meinem 22k-Patch wird das EEPROM genau einmal gelesen. In Abhängigkeit vom Ergebnis wird die Callback-Routine überschrieben: av7110->fe->ops.set_tone = saa7146_set_tone;

CU
Oliver

Zitat

Original von morus

Ich denke, dass ist nicht nötig, da in der Praxis immer die Drain-Diffusion des nmos gegen Substart durchbrechen wird, d.h. der Kurzschluss wird immer gegen Substart=GND sein.

Ok, dann machen wir das aber auch nur einmalig während der Initialisierung.

CU
Oliver

Zitat

Original von morus

Und ich hab das so geändert, dass dabei ein entsprechendes Flag gesetzt wird. Ich dachte mir es würde Sinn machen das dann auch dorthin zu verschieben, wo das Auswerten des eeproms für den full-ts und twintuner mod geschieht.

Hm - dadurch hast Du nur die Komplexität des Codes erhöht. Das Flag wird ja später nie mehr gebraucht. struct av7110 enthält mittlerweile so viel Zeug, daß man kaum noch durchblickt. ich bin immer froh, wenn ich nichts hinzufügen muß...

Btw, generell ist es unpraktisch, einen Jumbo-Patch zu posten, der zu viel gleichzeitig ändert. So etwas kann man nicht "as is" einchecken, sondern muß es in einzelne Patches splitten. -> Arbeit.

Hat aber noch Zeit, ich möchte jetzt erst mal das andere Zeug etwas stabilisieren.

Bei Gelegenheit kannst Du mal "make checkpatch" aufrufen. Mit diesem Codingstyle-Gedöns darf man sich mittlerweille als Maintainer herumschlagen, bevor irgendetwas in den Kernel geht.

CU
Oliver

Zitat

Original von morus

Doch, für die dynamische non-audio bit Umschaltung, die aber noch nicht implementiert ist, was ich bereits geschriegen hatte...

Ich bezog mich nur auf die GPIO3-22kHz-Umschaltung: Wenn man es so macht, wie ich vorgeschlagen habe, braucht man kein Flag in struct av7110.

Zu den anderen Features:

LNBP21:
Ich werde dem attach-Aufruf einen Address-Parameter spendieren und überall entsprechend ändern. Diese Änderung macht Sinn und ist ziemlich unkritisch.

BSBE1:
Von bsbe1mod.h wird eigentlich nur alps_bsbe1_mod_tuner_set_params() benötigt.
Tendiere momentan dazu, diese Routine einfach in av7110.c reinzunehmen. Wird sonst ja (noch) nirgends gebraucht. Wenn sich das jemals ändern sollte, kann man sie nach bsbe1.h verschieben.

Rest:
Wenn das alles in den Treiber soll, müssen wir es so einfach und idiotensicher wie möglich machen. Auf gar keinen Fall darf irgendeine Standardkarte falsch erkannt werden o.ä. Daher wird es kein Autoprobing irgendwelcher Chips geben (und schon gar nicht mit I2C-Write-Kommandos!).

Wenn gemoddete HW ein Feature unterstützt, dann gibt es hierzu im EEPROM ein entsprechendes Bit, welches gesetzt ist. Es liegt in der Verantwortung des Modders, die Modding-Bits korrekt zu setzen. Der Treiber wertet diese Bits aus, und gut ist.

CU
Oliver

Zitat

Original von UFO
Was mir gar nicht gefällt, ist der zweite DVB-Adapter. Das zweite Frontend gehört zum gleichen Adapter wie das erste. Der Ansatz beim Budget-Patch ist imho richtig.

Unter /dev/dvb/adapterX
1. Tuner -> demux0, dvr0, frontend0, ...
2. Tuner -> demux1, dvr1, frontend1, ...
usw.

Applikationen müssen mit mehr als einem Tuner je Adapter rechnen.

Alles anzeigen

Tun einige aber wohl leider nicht.

Zitat

Andernfalls wäre die Möglichkeit, mehrere Tuner pro Adapter zu haben, API-mäßig völlig sinnlos.

Auf VDR bezogen: Bei der Initialisierung sollte auf frontend1/demux1 getestet werden und diese ggf. auch verwendet werden. Evtl. läßt sich Klaus ja überzeugen.

Der allein wird aber nicht reichen, da müssen auch noch einige Plugins (Das femon-Plugin zum Beispiel unterstützt laut der Dokumentation Karten mit mehreren Frontends nicht.) und Patches nachgezogen werden.
Da Multituner-Karten noch immer sehr rar sind bezweifele ich, dass das in der nächsten Zeit passieren wird.

Richtig "schön" ist die Lösung mit mehreren Adaptern zwar nicht, aber wenn die Karte damit wirklich so einfach ans Laufen zu bekommt ist, ist das imho momentan die einzig praktikabele Möglichkeit. Oder gibt es gravierende Nachteile bei dem Vorgehen?.
Bislang war ich immer davon ausgegangen, dass nur ein Adapter pro Karte möglich ist. Wenn sich das Problem mit dem zweiten Frontend aber derart elegant umgehen lässt wird eine Multituner-Karte wieder interessant. (Allerdings muss ich mir mit meiner 1.5er FF noch was einfallen lassen.)

Zitat

Original von morus
Doch, für die dynamische non-audio bit Umschaltung, die aber noch nicht implementiert ist, was ich bereits geschriegen hatte... Das zu implementieren eilt auch nicht...

Wenn man sieht wie die VDR-Sanitizer weg gehen dürfte es da durchaus einige Interessenten geben.
Wenn du dafür einen extra Tread dürften sich sicher einige Mitstreiter / Tester finden lassen, denke ich. Hier wird das wohl eher untergehen.