Posts by S:oren

    Es gibt keinen einfachen Weg, den Treiber ohne komplette Kernel-Sourcen zu bauen, da auch die Kernel-Header gepatcht werden muessen.


    Wer sich da ausgefeilte Skripte oder dkms-Pakete oder was-auch-immer bauen will, darf das natuerlich gerne machen, muss aber mit jeder neuen Kernel-Version damit rechnen, dass man da wieder etwas anpassen muss. Da das Herunterladen der Kernel-Sourcen + Patchen + Bauen der Module keine 10 Minuten dauert (wenn man es nicht zum ersten Mal macht), wird man m.E. die Zeit nie wieder einsparen, die man die Entwicklung solcher Spezial-Loesungen steckt. Wer aber Spass daran hat, soll es meinetwegen gerne machen. Ich kann und moechte dafuer jedenfalls keinen Support leisten, ich selbst nutze sowieso keine Distro-Kernel auf meinen VDR- und Treiber-Entwicklungs-Rechnern. Aber auch da soll jeder nehmen, was ihm/ihr gefaellt.


    Nach den Problembeschreibungen, die ich so bisher bekommen habe, haben jedenfalls viele Leute schon deutlich mehr Zeit in die Fehlersuche gesteckt, als das Herunterladen und Patchen der kompletten Kernel-Sourcen gedauert haette. Die meisten Distro-Kernel werden sowieso exakt passende Modul-Versionen fordern, evt. sogar signierte Module. Wie das bei SuSE aussieht, weiss ich allerdings nicht. Die letzte von mir genutzte SuSE-Version war 9.3 ...


    Gruss,

    S:oren

    Kernel 4.4 ist ja auch schon eine Weile her und wenn ich mich richtig erinnere, sind seit dem geringfügige Anpassungen am Treiber gemacht worden.

    Koennte man so sagen, exakt 95 Patches...

    Ich kann ja schlecht den Patch, der gegen einen ganzen Kerneltree laufen würde, gegen das bisschen Sourcecode werfen, das in den src.rpms drin war.

    Bitte immer nur komplette Kernel-Sourcen verwenden. Die gibt es ganz sicher auch von SuSE.


    Die letzte Anfrage, den Treiber fuer Suse zu bauen, kam von kls, siehe hier.


    Gruss,

    S:oren

    Es ist natuerlich immer eine gute Idee, "meinen Original-Kernel" aus dem Repo zu testen, wenn es Probleme mit dem Treiber gibt. Leider hat jede Distri da so ihre eigenen Tuecken.


    Mittelfristig sollte ich wahrscheinlich das request_mem_region/ioremap in das neuere devm_ioremap aendern. Es waere mir allerdings neu, wenn es "oldstyle" nicht mehr funktioniert.


    Vielleicht findet sich ja noch eine einfache Erklaerung. Ansonsten ist leider 'git bisect' angesagt...


    Gruss,

    S:oren

    Sieht erstmal nicht verkehrt aus. Nur dass "SAA716x Core" eben nicht geladen ist.

    Der Speicher ist im Prinzip da und nicht anderweitig belegt.


    Ich habe im Moment keine weitere Idee...


    Gruss,

    S:oren

    Normalerweise funktioniert das request_mem_region() nicht, wenn schon ein anderer Treiber diesen Bereich reserviert hat.

    Steht in /proc/iomem etwas dazu? Bei mir sieht das so aus:

    Code
    1. 01000000-01efffff : MEM
    2. 01000000-010fffff : 0000:00:00.0
    3. 01100000-011fffff : PCI Bus 0000:01
    4. 01100000-011fffff : 0000:01:00.0
    5. 01100000-011fffff : SAA716x Core
    6. 01200000-0120ffff : 0000:00:00.0
    7. 01ffc000-01ffffff : 1ffc000.pcie

    Deshalb die Frage in die Runde, funktioniert bei Jemanden die TT6400 in Verbindung mit Kernel 5.1.x.

    Laeuft bei mir mit 5.1.6.

    BAR0 Request failed

    Hier klappt schon das allererste Mappen des PCIe-Speichers nicht. Da wird noch nichts Karten-spezifisches gemacht.

    Im Moment keine Ahnung, was da nicht klappt.


    Gruss,

    S:oren

    Nicht Skins, sondern OSD-Implementierungen.

    Ja, nur das ergibt Sinn. Wie ist dann aber

    in SkinFlatPlus die Funktion MaxPixmapSize implementieren und einen beliebigen Wert, der für deine Zwecke groß genug ist, zurückgeben

    zu verstehen?


    Wenn keiner was dagegen hat kann ich gerne diese Änderung machen

    Zumindest von mir wird es da keinen Einspruch geben.


    Gruss,

    S:oren

    Mein Verstaendnis mal zusammengefasst:

    Der Raspi hat ein Problem mit surfaces grosser als 2048x2048 bei hardware-beschleunigtem OSD. Bei der simpelst moeglichen Implementierung im Ausgabedevice duerfen dann Pixmaps auch nicht groesser sein. Daraufhin legt der vdr-Core willkuerlich diese Aufloesung als Obergrenze fuer sein Software-OSD fest. Skins duerfen diese Grenze aber aendern!?


    Nun reichen 2048x2048 nicht mal mehr fuer die sichtbare Bildschirmaufloesung. Dann legt man wieder willkuerlich 4096x4096 fest, unabhaengig von den tatsaechlich vorhandenen Ressourcen im System, womit weder den eventuellen Erfordernissen im Ausgabedevice (die meisten nutzen die Software-Implementierung, die nur durch den vorhandenen Hauptspeicher begrenzt ist, und nur fuer die gilt dieser Wert), noch den Wuenschen eines Skin gedient ist.


    Bin ich der Einzige, der das absurd findet?


    Gruss,

    S:oren

    und unter linux-4.15.0/ liegt dann das ganze entpackt und mit eingespielten Patches

    Auf den ersten Blick ist das, was unter linux-4.15.0/ liegt, dann identisch zu dem (und genauso "kaputt"), was ich oben mit dem

    tar xjf /usr/src/linux-source-4.15.0.tar.bz2

    ausgepackt hatte. Aber wie immer gibt es mehr als einen Weg zum Ziel.

    Die "komischen" Versionsnummern in den Sourcen scheinen dann immerhin konsistent zu sein. Den "Trick" mit dem Ueberschreiben der KERNELVERSION habe ich uebrigens auch aus dem Ubuntu-Build-Skript, scheint da so ueblich zu sein...


    Gruss,

    S:oren

    Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.

    Anscheinend ist bei Ubuntu alles anders, ich "liebe" diese Distribution. Jedenfalls sehe ich auch, dass eine installierte Ubuntu-linux-source in Version 4.15.0-48.51 sich selbst als 4.15.18 bezeichnet. Gruselig.


    Folgendes Vorgehen

    ergibt zumindest mal saa716x-Module, die sich unter einem Kernel 4.15.0-48-generic laden lassen.

    Leider (oder zum Glück?) habe ich keinen Ubuntu-Rechner mit S2-6400. Ob die Module funktionieren, kann ich also nicht testen. Ich hoffe das Beste...


    Gruss,

    S:oren

    Es ist fuer mich schwer nachzuvollziehen, welche Sourcen Du genau wie installiert hast.

    Fakt ist, die Module sagen (auch die neu generierte config), es waere ein Kernel 4.15.18. Das wird dann auch so sein.


    Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.


    Ich weiss auch nicht, wie man bei Ubuntu die Kernel-Sourcen richtig installiert, da muss es aber doch Anleitungen geben!? Falls sonst niemand eine Idee hat, kann ich das heute Abend (?) mal ausprobieren...


    Gruss,

    S:oren

    Du hast den Treiber anscheinend mit einem Stable-Kernel 4.15.18 gebaut, und noch den Distro-Kernel 4.15.0-48-generic laufen.


    Ich kann nur immer wieder den Hinweis wiederholen, die 2 verschiedenen Wege zum Bauen und Nutzen des Treibers (Mainline/Stable- oder Distro-Kernel) nicht zu vermischen...


    Gruss,

    S:oren

    Leider sind die Infos zu den beiden Varianten, den Treiber zu bauen, etwas verstreut hier im Forum.

    Neben diesem und dem oben verlinkten Thread gab es kürzlich hier nochmal ein ganz kurze Anleitung. Aber auch sonst haben verschiedene User schon Anleitungen für verschiedene Linux-Distributionen gepostet.


    Konkrete Fragen beantworte ich gerne, eine allgemeingültige Anleitung für beliebige Distros auf allen denkbaren Rechnerarchitekturen mit verschiedenen Bootloadern habe ich leider auch nicht.


    Gruss,

    S:oren

    Bei der anderen Methode mit Signalisierung über Hardware-Pins

    Gerade zum Thema MSI bei PCIe gibt es wohl viele Missverstaendnisse.


    Zunaechst mal werden alle Interrupts bei PCIe ueber Messages signalisiert. Es gibt schlichtweg keine weiteren Leitungen neben den PCIe-Lanes, ueber die solche Informationen uebertragen werden koennten.

    Die erste PCIe-Version war nun so designt, dass sie softwaremaessig kompatibel zu "normalem" PCI war, somit gab es bis zu 4 "legacy" Interrupts pro PCIe-Slot, die auch fuer den ganzen "Bus" (PCIe-Root-Complex) geshared werden.

    In spaeteren PCIe-Versionen kam man nun auf die Idee, dass man neben den ohnehin vorhandenen Messages als Option auch mehr als diese 4 Interrupts signalisieren koennte (bis zu 32 in 2er-Potenz-Schritten bei MSI, flexibler bei MSI-X), kostet halt quasi (an Hardware) nix. Diese Zusatz-Interrupts werden nun nicht geshared, es gibt aber keine Garantie, dass man die angeforderte Anzahl auch zugeteilt bekommt. Ein PCIe-Root-Complex unterstuetzt halt nur eine begrenzte Anzahl an Interrupts (die er ja zunaechst mal wieder ueber regulaere Leitungen an einen Interrupt-Controller signalisieren muss), und ein PCIe-"Bus" kann ja ueber Bridges recht viele PCIe-Slots haben. "Neuerdings" muessen die Interrupt-Messages nicht mehr im PCIe-Root-Complex enden, sondern koennen - per memory-mapped-IO, uebersetzt vom Root-Complex - auch direkt in Registern eines Interrupt-Controllers enden. Somit braucht man keine dedizierten MSI-IRQ- Leitungen vom Root-Complex zum Interrupt-Controller mehr, die vorhandenen IRQ-Anzahl kann im Zweifel zwischen mehrenen PCIe-Bussen flexibel aufgeteilt werden, eine Obergrenze (Adressen im Interrupt-Controller) gibt es aber immer noch.


    In der Praxis ist es nun so, dass normalerweise keine Interrupts geshared werden, da selten mehr als 4 PCIe-Karten pro Bus benutzt werden. Auch kenne ich keine DVB-PCIe-Karte, die mehr als einen Interrupt benutzt (einfach weil der Treiber eh mit der Tatsache zurechtkommen muss, dass er nicht mehrere Interrupts (Vektoren) zugeteilt bekommt und alternativ eine single-IRQ-Option implementieren muss). Somit gibt es in der Praxis nur selten einen (meist nur kleinen) Vorteil von MSI(-X). Aber gutes Treiber-Design nutzt jedoch auch diesen potentiellen kleinen Vorteil durch Aktivierung von MSI(-X).


    Frueher (in aelteren Kernel-Versionen) war es in LInux noetig, dass ein Treiber sich entscheiden muss, ob er legacy- oder MSI(-X)-Interrupts nutzen will. Das ist heutzutage (bei aktuellen Kerneln) nicht mehr so. Ein vernuenftiger Treiber hat die Modul-Option zur Aktivierung von MSI also heutzutage nicht mehr.


    Leider gibt es einige (buggy) PCIe-Root-Complex-Implementierungen, die nicht gleichzeitig legacy- und MSI-Interrupts unterstuetzen. Auch kann man MSI im Kernel deaktivieren. Nur fuer diese Faelle ergibt eine Modul-Option fuer MSI Sinn.


    Zusammenfassend ist so eine MSI-Kernel-Modul-Option heutzutage nicht mehr notwendig und ergibt auch in aelteren Kernel-Versionen nur als Workaround fuer Hardware-Fehler Sinn. Performance-Unterschiede oder auch anderes Verhalten gegenueber PCIe-AER (wie in diesem Thread diskutiert) wird man nicht feststellen.


    Gruss,

    S:oren

    In dem Fall

    Code
    1. wget https://github.com/s-moch/linux-saa716x/compare/v4.12...saa716x-4.12.diff

    Dann mit 'patch -p1< /path/to/file/v4.12...saa716x-4.12.diff' im Distro-Kernel-Source Tree anwenden...


    Gruss,

    S:oren

    Vielleicht schafft es der Treiber ja doch nach Staging.

    Eher nicht. Mauro wollte ihn explizit nicht in staging. Deshalb habe ich bereits alles aufgeraeumt, was ich (und checkpatch.pl) fuer noetig hielt.


    Gruss,

    S:oren