Denník „kernel developera“ (diskuse)

[mirec]

Přílohy:

• dump_gpio_gpiod.c (1540 bytů)
• dump_gpio.c (1063 bytů)
• i2c_scl_sda.xz (88652 bytů)
• i2c-piix4-logic-analyzer.c (41832 bytů)
• p14s_gen2_amd_acpi_tables.tar.xz (228544 bytů)
• smb_new_driver.c (181592 bytů)
• smb_old_driver.c (72431 bytů)

Keďže nie je možné pripojiť súbory k blogu, vkladám ich do komentára.

[Max]

Ty máš asi pěkně velký monitor, že ti vkládání těch obrázků v plné kvalitě nepřišlo jako problém :).
Jinak díky, že jsi to sepsal do něčeho ucelenějšího. Tvůj thread, kde jsi to řešil, byl také dobrý :).
Zdar Max

[mirec]

Môj monitor je veľký len podľa rozlíšenia (4K) :) Inak je to uhlopriečka 14". Pri screenshotoch som vynútil DPI 96 aby bola viditeľná čo najväčšia časť dumpu.

[debian+]

Hardverovo, či "udalosť" na nábežnej hrane alebo úbežnej rieší, rieši prekladací obvod D alebo T, a dosiahnutí úrovní určitého signálu v tomto prípade tranzistory (či v iných prípadoch aj AC/DC prevodník).

[debian+]

A normálne slovensky:

Ta reakcia na nábežnej hrane alebo úbežnej hrane sa rieši hardverovo prostredníctvom prekladacích obvodov D alebo T a detekcia určitého veľkosti signálu sa v tomto prípade rieši hardvérovo cez tranzistory (či v iných prípadoch môže aj cez AC/DC prevodník).

[R]

Ako tento blabol suvisi s temou?

[debian+]

Pri kernel programovaní je dobre vedie aj o hardveri.

[mirec]

Nemyslím si, že by znalosti klopných obvodov D/T boli pri obsluhe prerušenia nejak užitočné. Ak sa bavíme o APIC (Advanced Programmable Interrupt Controller) je dosť pravdepodobné, že pre interrupt line má na vstupe len Schmittov klopný obvod a celú logiku rieši softvérovo keďže každý vstup môže byť citlivý na hranu, alebo úroveň a má nastaviteľnú polaritu. Okrem toho implementuje MSI (Message Signaled Interrupts) ktoré by sa vážne implementovali dosť blbo iba klopnými obvodmi.

[debian+]

Elementárne veci sú základ. Ovplyvnia zložitejšie veci. Ľahšie na pochopenie.

Ono, kontroléry sa aj tak musia nejako realizovať. Tj. vo vnútry majú tranzistory, ...

[.]

A co jsi tím chtěl říct? Prostě jsi napsal úplně nesmyslný komentář tak jako vždycky.

[R]

Ty ale o HW nevies ani hovno ("prekladaci obvod", "AC/DC prevodnik"), navyse mas problemy aj so slovencinou. Tak nechapem, preco sa tu strapnujes...

[Bystroushaak]

Dobře ty.

[User682]

Moc pekna prace a clanek. Hodne slusnej troubleshotting.

gf

[Slovaslovaslova]

Tldr

[Pavel Píša]

Díky za článek. Je z něj vidět, jak děsivé jsou důsledky snahy o udržení kompatibility s nepromyšleným, 40 let starým návrhem. Na druhou stranu je to zázrak, že PC nakonec většinou chodí.

Je jasné, že Synaptic by bylo asi lepší připojit jako dvě samostatná zařízení na jednu nebo dvě plnohodnotné I2C sběrnice a nikam jinam. Tak by to vypadalo na nějakém ARM systému. Ale na PC pravděpodobně pro kompatibilitu s některou historickou PS2 myší je po inicializaci PS2 zajištěné, že z obou zařízení na začátek přichází nějaké základní jednoduché zprávy a až po odhalení, že se jedná o dvě novější zařízení se přepne protokol na ten složitější. Je to tak nějak?

Dále je v popisu zmiňovaný stav kolize na I2C, pokud se jedná o plnohodnotnou implementaci I2C, tak by měla být arbitrem vyřešená. Je pak otázkou, jak vypadá stavová mašina rozhraní, protože příchozí zprávy na adresu 08 by se měly vyčítat z nějaké jiné fronty/registrů než běžná data při naplánovaném přenosu. Pokud je přenos po bytech s plnou kontrolou stavu sběrnice, tak lze jak roli iniciátora, tak targetu zvládnout při rozumně navrženém kontroléru, který informuje o tom, že místo iniciátorem vysílané adresy došlo k přenosu adresy zaslané zařízením (přechod z Tx recessive - 1, jiný Tx dominat - 0 na Rx na straně kontroléru). Ale očekávám, že hodně SMBUS kontrolérů tuto část plně neimplementuje...

Jinak jádro by mohlo/mělo zvládat správně sdílení několika zařízení při edge truggered sdílených přerušeních právě díky potvrzení jestli každý z driverů všechna na něj mířící přerušení zpracoval - IRQ_HANDLED. V případě takového nešťastného sdílení je potřeba po příchodu přerušení volat postupně všech Nshared obslužných rutin postupně dokola, nejdříve do bodu, kdy první odpoví IRQ_HANDLED. Když v prvním průchodu neodpoví nikdo, tak je to nějaký spurious interrupt a měla by se hlásit chyba. Poté tak dlouho, zž posledních Nshared-1 rutin za sebou odpoví IRQ_NONE. Tím je jistota, že alespoň na minimální interval byl signál IRQ neaktivní a příští aktivace povede k hraně. Rešil jsem to pro ISA CAN karty, v dobách, kdy ještě linuxové jádro ty návratové hodoty nemělo. Ale obecně interrupty úrovní jsou vhodnější pro jednodušší zpracování.

Během dalšího vývoje jsem se setkal s osazením CAN kontrolérů na PCI kartu takovým způsobem, kdy PCI IRQ bylo standardně jádrem zpracovávané v režimu s úrovní, ale použitý PCI na local bus bridge původně navržený pro nějaké ISDN modemy zpracovával IRQ sloučené přes funkci or z jednotlivých čipů hranou. Řešení z historického LinCANu zde. Je to trochu zjednodušené, vždy se znova prochází oba řadiče. Do mainline na SocketCAN pak přepisoval driver Wolfgang Grandegger a lidi přímo z EMS.

[R]

No praveze ta PS/2 kompatibilna cast je jedina vec, ktora na tom funguje. Pripojenie cez I2C je totalne rozbite na vsetkych urovniach, od firmwaru samotneho zariadenia, cez pripojenie na nezmyselnu zbernicu (ASF) az po nespravne ACPI tabulky v BIOSe.

Zaujimave, ze pred niekolkymi rokmi mali noteboky bezne touchpad aj trackpoint, pripojene to bolo cez PS/2 a fungovalo to cez PS/2 multiplexing. Casto tam este bol (na docku) PS/2 port pre externu mys.

[johnyK]

ja jsem vzdelanim inzenyr a ne uplne padly na hlavu a i kdyz ne z oboru, musim priznat ze trochu tapu. Slovensky rozumim dobre, presto napr. nerozumim jiz te vete:

Frekvencia posielania polohy kurzoru sa výrazne znižuje, keď používam priblížim ruku k touchpadu

Tak pouziva ten uzivatel ten touchpad a nebo se k nemu rukou jen priblizuje?

Podle Vasi reakce tomu odborne rozumite a vzhledem k tomu, ze jste vysokoskolsky pedagog, tak byste event. dokazal i nejak 'lidsky' kratce popsat, o co se vlastne jedna. Samozrejme se moje prosba tyka i ostatnich kolegu kteri tomu rozumi, jestli by to nemohli nejak osvetlit.

[mirec]

Touchpad pri určovaní polohy meria kapacitu. Zrejme je dosť citlivý na to, aby reagoval ešte pred dotykom (na vzdialenosť cca 1cm kedy síce neposiela ešte žiadne packety, ale prebudí sa a spomaľuje packety druhého zariadenia na PS/2).

[mirec]

PS/2 (i8042) nie je až tak zlý protokol. I keď ...

No najskôr sa pozrime na alternatívy. Niekoho by mohlo napadnúť, čo tak USB-HID? Ten je síce pekne štandardizovaný a bežne podporovaný aj v BIOSe, ale USB protokol je kvôli pollingu žrút energie a do notebookov sa nehodí.

Protokol I2C s pomerne inteligentným kontrolérom, ktorý by vedel prerušiť pri požiadavke od slave zariadenia je teoreticky dobré riešenie. Problém je, že I2C poskytuje cca 128 adries, keď odrátam nejaké tie rezervované a adresy SMBusu, zostane ich tak polovica. Nájsť nejaký rozsah adries, ktorý by bol vyhradený len na klávesnice a myši je nemožné. Detegovať HID zariadenia postupným posielaním nejakej sekvencie bytov na všetky adresy je tiež blbosť (na I2C môže byť napríklad ovládanie chladičov a poslanie nejakej sekvencie bytov môže urobiť ktovie čo). Jedinú schodnú cestu tu vidím v separátnom I2C radiči len na HID zariadenia.

Nakoniec ešte k PS/2 protokolu ... Mal som počítač s klávesnicou a myšou na PS/2 a mal som aj staršie thinkpady s touchpadom na PS/2. Vo všetkých prípadoch absolútne bez problémov. PS/2 je dostatočne rýchly, aby zvládal > 200Hz multiplexovaných packetov. To, že na mojom thinkpade padá pod 40Hz je spôsobené len zlou implementáciou u synapticsu. Nie je to problém PS/2.

Píšem o PS/2 ako keby to bol super protokol, ale nie je. Neviem, čo zase v Lenove zbabrali, ale u nových modelov PS/2 nefunguje dobre. PS/2 nemá žiaden synchronizačný mechanizmus, alebo detekciu chýb. Ak vypadne jeden bit, celý ďalší prúd bitov je nepoužiteľný a kurzor bude pri pohybe len tak lietať po obrazovke a náhodne klikať. Niektorým používateľom to robí niekoľko krát denne. Mne sa to teraz stáva raz za niekoľko mesiacov. Pri starších modeloch sa mi to nestalo ani raz za vyše 10 rokov používania.

[Pali]

To mi pripomenulo veľmi podobný problém z minulosti.

PS/2 nemá žiaden synchronizačný mechanizmus, alebo detekciu chýb. Ak vypadne jeden bit, celý ďalší prúd bitov je nepoužiteľný a kurzor bude pri pohybe len tak lietať po obrazovke a náhodne klikať.

Pred nejakým časom som tento problém riešil s touchpadmi a trackpointami od ALPS na notebookoch od Dellu. Bol to veľmi podobný boj ako popísaný v tom blogu ale s úspešným koncom (patche sú už dlhšie v kerneli).

ALPS má vlastný 6-bajtový PS/2 formát paktov s tým, že každý bajt okrem prvého má vrchný bit nulový. Čo rieši synchronizáciu. Avšak samotný ALPS touchpad na Dell notebookoch nie je pripojený priamo na základnú dosku ale je pripojený k nejakému Dellovému mikrokontroléru, ktorý pre PS/2 slúži ako prietokový ohrievač a až PS/2 z mikrokontroléru je pripojený k i8042/CPU. Naviac vo firmware toho mikrokontroléru je nejaká chyba a nie vždy stihne odbaviť všetky PS/2 pakety z tochpadu a poslať ich na i8042 na hlavný procesor. Občas nahradí posledný bajt paketu za 0xFF alebo 0xFE. Čím úplne pokazí autosynchronizáciu toho ALPS protokolu.

A aby toho nebolo málo, buď ten Dell mikrokontrolér alebo ALPS touchpad samotný (neviem presne kto), mixuje do toho PS/2 prenosu ešte aj 3 bajtové PS/2 pakety z externej myši (pripojenej k PS/2 portu na doku). Naviac posledné dva bajty ALPS paketu splňujú podmienku validity prvých dvoch bajtov PS/2 paketu externej myši. Síce PS/2 myš na externom doku asi nikto nepoužíva ale alps driver to implementuje. A kvôli neexistencii autodetekcie pripojenia externej PS/2 myši v tomto systéme, musí stavová mašina pri spracovávaní vždy počítať, že tam ten 3-bajtový paket od myši môže príjsť prakticky hocikedy.

No a kombinácia všetkých týchto vecí dokázala stavovú mašinu alps drivru úplne rozsynchronizovať a oddebugovať to celé bolo dosť problém.

[vgy]

Takže vo woknách prišiel nejaký developer, podľa manuálu alebo odniekiaľ okopčil a zbúchal ovládač a funguje to... Zatiaľ čo v Linuxe musí človek spáchať harakiri aby sa zistilo, kde je pes zakopaný a že vo firmware je asi chyba a korektné používanie spôsobuje bordel v trafficu...

Ak je to teda naozaj tak, tak by som očakával, že sa osloví výrobca, spíše nejaké NDA a podľa nej sa urobí ako dobrovoľník linuxový ovládač, ktorý sa dá schváliť(a možno popritom vyjde aj nejaký update firmware alebo v ďalšej hw verzii bude problém opravený, čo by potom poriešil servis výmenou)... Pretože riešiť nejakú chybu firmware sa síce dá a bežne sa vo Windows deje napríklad pri hrách, že Windows alebo výrobcovia hw opravujú chyby v hrách tak, aby hra bežala...(lenže fikanejší hw výrobcovia majú dedikovaných ľudí priamo pri vývoji daných hier, aby hra bola optimalizovaná pre daného výrobcu a nema problema, keď sa nejaký gamer rozhodne sa obšťastniť nákupom od daného hw výrobcu...)...

[Pali]

Na windowsoch je to trochu inak. Tam PS/2 driver nerobí nejaký príliš sofistikovaný recovery a všetky pakety, čo rozparsuje tak pošle do jedného input myš zariadenia. Plus ten ALPS PS/2 driver je nutné si nainštalovať ručne a nahradí systémový PS/2 driver. Na linuxe psmouse.ko driver implementuje podporu pre všetky možné aj nemožné PS/2 "myš" zariadenia (od mýš, cez trackpointy až po touchpady s absolútnym poziciovaním), robí autodetekciu pripojených zariadení a v prípade, že za jedným "fyzickým" PS/2 portom sa skrýva viac zariadení (napr. ten ALPS touchpad + ALPS trackpoint a ešte k tomu externá PS/2 myš), tak sa snaží to rozdeliť do viacerých /dev/input* zariadení aby userspace prípadne sa mohol rozhodnúť "ignorovať" eventy od jedného zariadenia (napr. touchpad) a aby naďalej fungovalo ďalšie (trackpoint). Windows driver nič z toho nerobí, takže si na Windowse uľahčili robotu a to aj v implementácii stavovej mašiny.

ALPS v minulosti mal ovládač aj pre Linux ale dodal ho iba Dellu a možno ešte Red Hatu(?). Zákazníci Dellu si ho mohli z oficiálnych stránok stiahnúť (ak vedeli kde hľadať). Naviac bol napísaný v jave, bez zdrojákov s EULA a priamo si šahal z userspace na hardwarové IO porty. Tzn. celá java s JVM musela behať pod rootom, žralo to dosť CPU a aj pamäte a dnes by to už asi ani nefungovalo kvôli UEFI secure boot, kedy sa userspacu odopiera priamy prístup k HW IO portom.

Nakoniec ale vývojári z ALPS boli ochotní na probléme spolupracovať a dodali aj nejakú tú dokumentáciu a pre novšie ALPS touchpady aj nejaké patche do kernelu (pod kompatibilnou licenciou). Síce dokumentáciu iba vo forme screenshotov, na ktorých boli PDF stránky z otvoreného Adobe Readeru ale aj to bolo niečo. Tuším že tie emaily posielali verejne, takže na archíve LKML by sa png screenshoty ešte dali nájsť.

Dell samozrejme chybu vo firmware nepotrvrdil a ani sa k tomu nevyjadril.

[Cimrdam]

A není těch štítku málo Miroslave Bendíkoviči?

[mirec]

Tagy sa mi nechce editovať. Ako vyhodnotil algoritmus CMS, tak nechávam.

[.]

Pěkné.

[Gréta]

supr deníček :D ;D

[AsciiWolf]

Skvělý blogpost, díky! Klidně by mohl vyjít jako článek.