[erledigt] Probleme mit Kernel Treiber TT6400 für linux 5.16

  • Könnte die Ursache für die NACKs beim einem Fehler schon beim wechseln des Target-ICs liegen?

    Dann könnte es reichen, wenn die Wartezeit nur nach dem senden eines Stop-Bit eingefügt wird. Oder wurde das schon mal probiert?

    Gruss
    SHF


  • Ist das auch für altere Versionen relevant? openSuse hat momentan Kernel 5.3 und ab Juni 5.14

    Für ältere Kernel hat das keine Bedeutung.

    Der von S:oren überarbeitete Treiber gilt erst ab Kernel 5.16.

    So strikt und absolut ist das nicht.


    Die ersten I2C-Aenderungen hatte ich fuer 5.15 eingebaut, weil das der aktuelle Kernel zu Weihnachten war, wo ich diverse Abstuerze bei mir mal genauer untersuchen konnte (und das hatte fuer mich danach auch recht gut funktioniert). Die ganzen weiteren Untersuchungen und Verbesserungen sind fuer 5.16, weil es fuer diese Version einen engagierten Tester gab und gibt. (Danke kamel5 !)


    Einen Backport fuer 5.15 hatte ich eigentlich vor, weil das ein longterm-Kernel ist. Und weil die eingecheckten "halbgaren" I2C-Aenderungen ja nicht der Weisheit letzter Schluss sein koennen.


    Ein Backport weiter in die Vergangenheit ist sicher moeglich. Vermutlich wird sich der 5.17er Patch (wenn er denn da ist - diese Woche noch, hoffe ich) auch auf 5.14 anwenden lassen (zumindest die I2C-Aenderungen). Eventuelle kleinere Problemchen bei der Portierung kann ich mir da gerne noch anschauen, wenn Interesse besteht. Nur testen kann ich nichts fuer aeltere Versionen. Ich habe bei mir immer die neueste Kernelversion laufen, kann live nur mit einem VDR zur Zeit schauen, und die hier diskutierten Fehler treten ja immer erst nach Stunden, Tagen oder Wochen auf.


    Wenn sich also jemand zum Testen findet, kann ich gerne auch Anpassungen fuer aeltere Kernelversionen einchecken. Ich fuege auch gerne ein Tested-by-Tag hinzu, wenn mir jemand eines schickt.


    Gruss,

    S:oren

  • Könnte die Ursache für die NACKs beim einem Fehler schon beim wechseln des Target-ICs liegen?

    Dann könnte es reichen, wenn die Wartezeit nur nach dem senden eines Stop-Bit eingefügt wird. Oder wurde das schon mal probiert?

    Probiert wurde schon sehr viel.


    Die beobachteten Probleme ließen sich immer auf ein NACK beim Wechsel vom Write zum Read auf dem selben IC zurueckfuehren. (Setzen der Read-Adresse und eigentlicher Read, speziell auf dem Demod). Deshalb wird eine zusaetzliche Wartezeit vor dem Repeated-Start eingefuegt. Ein Stop-Bit gehoert da nicht hin (waere aber eventuell auch ein denkbarer Workaround).


    Offenbar kann der Demod den Read nicht durch Clock-Stretching verzoegern (die eigentlich saubere Loesung nach I2C-Spec, die aber nicht kompatibel ist mit SMB und generell auch nicht schoen). Der deshalb noetige Warte-Workaround wird kompliziert, weil der I2C-Controller kein Status-Bit hat, wann das letzte Byte der Read-Adresse geschrieben wurde.


    Interessant auch, dass der zweite LNB-Versorgungs-IC sich manchmal nicht meldet, wenn kein Stop-Bit zwischen den Zugriffen auf beide ICs (7Bit-Adressen 8 und 9 auf der S2-6400) kommt. Das ist auch nicht so ganz I2C-Spec-konform, aber fuer VDR-Betrieb kein Problem. Und jetzt auch gefixt fuer i2cdetect.


    Edit:

    Zur Klarstellung: Mit Read-Adresse ist nicht die I2C-Device-Adresse des Target (frueher mal Slave genannt) gemeint, sondern die Registeradresse innerhalb des ICs.


    Gruss,

    S:oren

  • Die beobachteten Probleme ließen sich immer auf ein NACK beim Wechsel vom Write zum Read auf dem selben IC zurueckfuehren. Deshalb wird eine zusaetzliche Wartezeit vor dem Repeated-Start eingefuegt. Ein Stop-Bit gehoert da nicht hin (waere aber eventuell auch ein denkbarer Workaround).

    Ich hatte vermutet, dass da noch ein anderes Target auf dem Bus was sendet und dadurch Chaos entsteht und das ACK ausbleibt.

    Aber wenn die Wartezeit nur an der Stelle eingefügt wird, ist das wohl auszuschliessen. Ich war bei dem Patch nicht sicher, weil da an einigen Stellen das Timing geändert wurde.


    Sollte das Stop-Bit an der Stelle nicht eher das Target zurücksetzen?

    Versuchen kann man es trotzdem.

    Offenbar kann der Demod den Read nicht durch Clock-Stretching verzoegern (die eigentlich saubere Loesung nach I2C-Spec, die aber nicht kompatibel ist mit SMB und generell auch nicht schoen).

    Clock-Stretching ist optional und können auch nicht viele Target-ICs.

    Ein NACK zu senden, wenn das Target-IC "busy" und nicht in der Lage ist sinnvolle Informationen zu liefern, ist aber auch standardkonform (zumindest interpretiere ich das so).

    Bei EEPROMs ist das beim Schreiben so üblich, dass sie nicht reagieren (NACK), bis sie das Byte intern geschrieben haben.


    Wie man bei so einem NACK reagieren muss hängt vom Target ab, bei den EEPROMs probiert man es solange erneut, bis es wieder auf seine I2C-Device-Adresse antwortet (ACK).


    Ob es hier reicht den eigentlichen Lesebefehl zu wiederholen, oder ob man die Registeradresse erneut schreiben muss?

    Wenn der NACK schon bei der I2C-Device-Adresse des Leseversuchs kommt, würde ich meinen, es reicht nur den eigentlichen Lesebefehl zu wiederholen. Ist ohne Datenblatt aber nur eine Vermutung.

    Der deshalb noetige Warte-Workaround wird kompliziert, weil der I2C-Controller kein Status-Bit hat, wann das letzte Byte der Read-Adresse geschrieben wurde.

    Ernsthaft? Das kann ich mir eigentlich nicht vorstellen.

    Der SAA7146 hatte so ein I2C-Busy-Bit und der Nachfolger soll keines haben? Ich hab leider kein Datenblatt.


    Irgendwie muss man doch nach schreiben der I2C-Device-Adresse und Registeradresse feststellen können, ob das erfolgreich war.

    Interessant auch, dass der zweite LNB-Versorgungs-IC sich manchmal nicht meldet, wenn kein Stop-Bit zwischen den Zugriffen auf beide ICs (7Bit-Adressen 8 und 9 auf der S2-6400) kommt.

    Das Problem scheint aber nicht so ungewöhnlich zu sein. Dass einige ICs auf ein Stop-Bit beim Wechsel der Adresse bestehen hab ich schon irgendwo mal gelesen.

    Gruss
    SHF


  • Was soll ich hier dazu sagen?


    Im Prinzip hoere ich mir gerne neue Ideen und Vorschlaege fuer bessere Workarounds an. Am liebsten Ideen, wie man etwas sauber ohne Workarounds implementieren kann. Wenn jemand hier selbst irgendwas ausprobieren will, gerne. Ist alles Open-Source-Code.


    Ich kenne EEPROMs, wo man zum Feststellen des erfolgten Schreibens solange Lesen muss, bis die Schreibdaten wieder gelesen werden (und nicht Daten mit invertiertem unteren Bit, aber immer mit ACK). Das ist alles fuer einen Target-Device-Treiber schoen und wichtig, fuer den hier diskutierten Controller-Treiber eher nicht.

    War Dein Vorschlag, lieber keine Quirks fuer merkwuerdige Target-Devices oder deren Treiber hier einzubauen? Von mir aus gerne. Hast Du Patches oder zumindest konkrete Ideen, das anders besser zu loesen? Der vorliegende Status quo versucht die Probleme der alten saa716x_i2c-Implementierung (unendliche read transfer errors, selten) zu loesen, ohne neue Probleme zu schaffen. Eine große bessere Loesung soll mir recht sein. Hilfe jederzeit willkommen.


    Ich habe schon vor Jahrzehnten mit Philips Semiconductor in einem Chipdesignprojekt zusammengearbeitet und arbeite immer noch mit Kollegen zusammen, die noch mehr und laenger fuer Philips Hardware implementiert haben. Ich kann mir sehr gut vorstellen, dass alles so schlimm ist wie es aussieht. Ich habe ein Datenblatt und ein UserManual fuer den SAA7160, die sind leider nicht so ausfuehrlich und hilfreich, wie man sich wuenschen wuerde. Aber ich bin mir ziemlich sicher, dort nicht ein Status-Bit uebersehen zu haben. Was nicht heißen muss, dass es das nicht doch gibt und nur nicht dokumentiert ist (oder ich mittlerweile alt und senil bin).


    Ich bin auch der Meining, dass man nicht alles machen muss, was prinzipiell erlaubt ist, sondern moeglichst alles so macht, wie die meisten anderen. Dann ist die Chance am groessten, dass alles kompatibel ist. Aus diesem Grund habe ich STOP-Bits dort eingebaut, wo sie hingehoeren, und keine wo man ueblicherweise keine hat.


    Gruss,

    S:oren

  • Auch mit fix5 bisher keine Auffälligkeiten.

    OK, danke!


    Ich habe den aktuellen Stand der Treiberimplementierung in den 5.16er Branch gepusht. Hier doch nur als zusaetzliche Patches. Fuer Leute, die nur einen Gesamtpatch erzeugen, ist es egal. Fuer die, die den Git-Branch pullen, braucht es kein force.


    Die NACK-Meldung ist jetzt wieder eine normale Debug-Message, ein echter Fehler ist es ja nicht. Fuer i2cdetect ist es ja ganz normales Verhalten.


    Falls es mit diesem Stand erstmal keine Probleme mehr gibt, werde ich das (am Wochenende?) auch fuer 5.15 und 5.17 anpassen.


    Gruss,

    S:oren

  • Zunächst, mir ist schon bewusst, dass da einiges probiert wurde und das von Leuten, die sicher deutlich mehr Ahnung bei dem Thema haben als ich Gelegenheitsbastler.

    Wenn das alles Trivialitäten sind, die eh schon alle versucht wurden, dann Schwamm drüber ...


    Ich kenne EEPROMs, wo man zum Feststellen des erfolgten Schreibens solange Lesen muss, bis die Schreibdaten wieder gelesen werden (und nicht Daten mit invertiertem unteren Bit, aber immer mit ACK).

    Das AT24HC02C antwortet in dem Zustand gar nicht mehr (Datenblatt 7.3 Acknowledge Polling), zumindest habe ich das so verstanden.

    Auf das Datenblatt bin ich gestossen, weil ich für den Fall (ausbleibendes ACK nach Adresse) ein Beispiel suchte wie zu Verfahren ist.

    Das IC selber habe ich nie verwendet, aber das Vorgehen, ab dem letzten START erneut zu beginnen, hat bislang ganz gut funktioniert.


    Hast Du Patches oder zumindest konkrete Ideen, das anders besser zu loesen?

    Mein Vorschlag ist, im Falle eines NACK beim letzten START erneut zu beginnen.

    Im Falle des Demod also nicht vorher das Register erneut schreiben.

    Wurde das so schon mal versucht?


    Das sollte eigentlich universell funktionieren und der Demod hätte genug Zeit sich zu sortieren.

    Ich habe ein Datenblatt und ein UserManual fuer den SAA7160, die sind leider nicht so ausfuehrlich und hilfreich, wie man sich wuenschen wuerde. Aber ich bin mir ziemlich sicher, dort nicht ein Status-Bit uebersehen zu haben. Was nicht heißen muss, dass es das nicht doch gibt und nur nicht dokumentiert ist (oder ich mittlerweile alt und senil bin).

    Ich wollte dir da keinesfalls zu nahe treten, aber ohne Datenblatt bin ich halt auf Vermutungen angewiesen. Also bitte nicht übel nehmen.


    Irgendwie muss man aber doch raus finden können, ob das Schreiben auf ein Target erfolgreich war. Oder bekommt man es nur mit, wenn ein Fehler auftritt?

    Aber auch da muss man wissen, wann der Transfare beendet ist, sonst muss man warten und hoffen, dass es lange genug war. Ziemlicher Schrott wäre das...

    (Bei dem Teil vom Treiber steige ich ohne Datenblatt nicht wirklich durch, sorry.)

    Gruss
    SHF


  • Nochmal: Hier geht es nur um den Controller- (Master) Treiber im saa716x. Im Target-Treiber fuer einen EEPROM oder Demod oder was-auch-immer wuerde ich natuerlich Transfers wiederholen, die fehlgeschlagen sind. Oder irgendwas machen, was dieser Chip so erfordert.


    Aber das ist nicht der Job des Master-Treibers, der schreibt einfach nur die Bytes auf den Bus, wie es ein anderer Treiber angefordert hat. Auch die eingebaute Wartezeit gehoert da eigentlich nicht hin (wie es auch in dem Commit steht). Aber diese Wartezeit ist immer noch schneller als irgendeine Wiederholung, und so eine Wartezeit laesst sich nicht mit dem bestehenden I2C-API im Linux-Kernel anfordern. Es ist halt ein Hack, der gut funktioniert. Und hoffentlich auch mit den ganzen saa716x-Budget-Karten, die unterstuetzt bleiben muessen und die ich nicht testen kann, weil ich sie nicht habe.


    In dem jetzigen Treiberstand wird (im Gegensatz zu vorher) auf das Ende eines kompletten Transfers (mit STOP) gewartet. Nur auf das Ende einer Message (vor dem Repeated-START) kann nicht präzise gewartet werden.


    Gibt es irgendein Problem, das noch gefixt werden muesste, oder ist das ganze hier eine Diskussion "im luftleeren Raum" fuer langweilige Stunden (die ich nicht kenne)?


    Gruss,

    S:oren

  • Kernel 5.17 kann ich im Moment leider nicht testen.

    Ich muss da warten, bis Fedora den über Update bereitstellt. Das kann ein paar Tage dauern.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich sehe gerade, Du hast ja momentan im 5.17-test-Branch nur einen zusätzlichen commit "saa716x_ff: select faster i2c timings".

    Das könnte ich für Kernel 5.16 übernehmen und damit zwischendurch mal testen.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Das ist fuer mich erstmal kein Problem, ich habe die 5.17er Version bei mir jetzt laufen. Die ist etwas aufgeraeumter, z.B. wenn man sie fuer aeltere Versionen backportieren will. Ansonsten ist bei 5.16 alles gleich, bis auf die Takterhöhung im letzten Commit (das koenntest Du auch mit 5.16 ausprobieren, ist ja nur eine Ziffer zu aendern).


    Im Moment gibt es fuer 5.17 nur den test-Branch. Ein bisschen unabhaengiges Testen ist sicher gut. Aber ich blicke auch nicht so ganz durch, ob irgendwer hier noch ein Problem damit hat oder eine andere Loesung gewuenscht ist. Jedenfalls sind gegenueber der alten Treiberversion einige Sachen verbessert, die durchaus fuer mich Sinn ergeben. Aber wie man gesehen hat, koennen bei mehr Testern auch mehr Probleme auftreten.


    Gruss,

    S:oren

  • Die letzte Antwort bezog sich auf den vorletzten Post (den letzten hatte ich verpasst), aber das ist trotzdem alles klar geworden, denke ich. Gerne auch mit dem 400kHz-Takt noch testen.

    Ergibt sich da gefuehlt ein Unterschied in der Umschaltzeit der Sender? Mir kommt die Verbesserung von dem alten Stand auf die 5.16er Version größer vor als dann der Schritt mit dem I2C-Fastmode. Probleme gab es damit aber auch nicht. Ich hatte das so vorher schon immer mal mitlaufen...


    Gruss,

    S:oren

  • Ich habe heute den 5.17-test Kernel ausprobiert da wurde das Digital Devices Erweiterungsmodul nicht erkannt, mit 5.16 war es noch OK.

    Ich bin dann erst einmal zurück auf 5.16. Den relvanten Teil, komplett als Anhang.


  • Ergibt sich da gefuehlt ein Unterschied in der Umschaltzeit der Sender? Mir kommt die Verbesserung von dem alten Stand auf die 5.16er Version größer vor als dann der Schritt mit dem I2C-Fastmode.

    Seit gestern habe ich den I2C-Fastmode mit Kernel 5.16 aktiv. Ob das nochmal eine Verbesserung gebracht hat, ist schwer zu sagen. Zumindest funktioniert es damit auch.

    Die Umschaltzeiten lassen sich bei mir schwer beurteilen, da ich hier ein CI mit den entsprechenden Plugins im Einsatz habe und außerdem auch permashift benutze. Damit sind die Umschaltzeiten eh immer etwas länger, was mich nicht so stört, da ich nicht der große Zapper bin.

    Insgesamt kann ich aber bestätigen, das ich subjektiv den Eindruck habe, das sich der umgebaute Treiber gefühlt "williger" verhält. Ich weiß nicht, wie ich das besser beschreiben soll.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!