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

Nee, hilft auch nicht wirklich. Ohne viele Debug-Meldungen (nur das NACK) passiert es doch wieder. Also doch ein Timing-Problem!?

Gruß,

Sören

Transfermode betrifft ja nur die TS-Daten. Die Einstellungen und Abfragen von Tuner und Demod ueber I2C sind komplett unabhaengig davon, wie die TS-Daten weiterverarbeitet werden.

Nach meiner letzten Theorie handelt es sich doch um ein Timing-Problem. Eine signifikante Wartezeit zwischen Setzen der Leseadresse und dem eigentlichen Lesen scheint die Wahrscheinlichkeit fuer so ein NACK zu verringern. Vermutlich ist diese Zeit bei mir auf den armv7 / armv8-Systemen (i.MX6Q / RK3399 mit PCIe-Switch) generell etwas größer als auf Deinem Ryzen7.

Jedenfalls habe ich keine Abhaengigkeit von Aufnahmen oder Tunernummer feststellen koennen. Aber die Statistik ist natuerlich schlecht bei einem NACK alle paar Stunden...

Grüße,

Sören

Warum nicht einfach bei jedem NAck mitloggen und automatisch die Zeitkonstante erhöhen mit print ins log?

Zitat von kamel5

Nützt es Dir was, wenn ich Dir die NACK häufiger schicke oder soll ich die eher sammeln?

Ich meine, die NACK bei mir treten nur alle paar Stunden auf.

Deine NACKs haben sehr geholfen festzustellen, dass die bei beliebigen Adressen auftreten und nicht an das I2C-Gate gekoppelt sind (dort nur besonders fatale Auswirkungen haben wenn Unsinn zurueckgeschrieben wird). Im Moment versuche ich, eine Einstellung zu finden, wo gar keine NACKs mehr bei vdr-Betrieb auftreten.

Ich brauche im Moment nicht mehr die vollstaendigen Logs, nur die Information ob NACKs auftreten. Trotzdem nochmal Danke fuer Deine Bemuehungen.

Zitat von kamel5

Gibt es da einen Parameter, an dem ich hier vorsichtig mal Änderungen vornehmen könnte, um zu sehen, ob sich da bei mir was ändert?

In dem fix3 gibt es

+		//fixme if (!add_stop)
+		//fixme 	usleep_range(20, 50);

Das wieder einkommentieren. Mit einer Range (100, 120) sieht es bei mir gerade recht gut aus.

Danke,

Sören

So ein Hack ist irgendwie unbefriedigend, weil es keine Erklaerung fuer die Wartezeit gibt. Einen anderen Fehler habe ich aber auch nicht finden koennen (z.B. Probleme mit I2C_SDA_HOLD).

Alternativ koennte man ueberlegen, doch wieder so einen Retry-Mechanismus einzubauen, wie es im alten Treiber war. Hier wurden Transfers bis zu 2x wiederholt, wenn etwas schief gegangen ist. Sowas koennte aber auch an sich Probleme mit manchen I2C-Slaves verursachen.

Langsam gehen mir die Ideen aus...

Gruss,

S:oren

Interessant ist auch, dass ich keinen Unterschied feststellen kann, egal ob der I2C-Bus mit 100 oder 400kHz betrieben wird.

Gruß,

Sören

Sehr schoen, sowas hoert man gerne.

Da lohnt es sich doch, wieder ein paar Patches fertig zu machen, immerhin steht 5.17 an.

Sollen der 5.16er Branch stabil bleiben, oder kann ich Fixes von Fixes zusammenfassen?

Gruß,

Sören

Ich glaube zu wissen, was das Problem ist. Es gibt keine Moeglichkeit festzustellen, wann ein Byte ueber I2C fertig uebertragen wurde. Im Treiber kann ich nur sehen, wann mit der Uebertragung begonnen wurde, das ACK-Bit kommt irgendwann spaeter (und damit das NACK-Flag, oder eben nicht).

Wie kann man nur eine derartig unsinnige Hardware bauen!

Gruss,

S:oren

Hier nochmal eine neue Version zum Testen. Das ergibt so fuer mich Sinn, so gut es eben mit dieser "merkwuerdigen" Hardware geht.

Gruss,

S:oren

Ich habe noch ein paar kleinere Verbesserungen angebracht.

Die Wartezeiten werden jetzt in Abhaengigkeit des I2C-Taktes gesetzt und dadurch besser angepasst, damit man moeglichst nicht zu lange wartet, aber auch nicht zu viele kurze Wartepausen nacheinander einlegt. Auch kann die Wartezeit ganz am Ende eines Write-Transfers etwas reduziert werden, wenn man hier speziell auf das Ende der Transaktion (I2C-STOP) wartet.

Fix4 wurde ja schon recht oft heruntergeladen, danke an alle fuer's Testen! Trotzdem hier noch eine weitere Version, das soll jetzt wirklich die (vorerst) letzte sein.

Gruss,

S:oren