Administrace komentářů

Takže prepísal som všetky používané časti ovládača podľa disassemblovaného ovládača z windowsu. Predpokladám, že prepis je správny, ale nefunguje to, z čoho usudzujem, že kernel robí niečo zle.

V prvom rade ResourceTemplate z ACPI vyzerá takto:

Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
{
    IO (Decode16,
        0x0B20,             // Range Minimum
        0x0B20,             // Range Maximum
        0x20,               // Alignment
        0x20,               // Length
        )
    IRQ (Level, ActiveLow, Shared, )
        {7}
})

Dôležité je, že IRQ je level triggered s aktívnym stavom low.

Moja registrácia IRQ handleru vyzerá takto:

retval = devm_request_irq(&dev->dev, dev->irq, piix4_isr, IRQF_SHARED | IRQF_TRIGGER_LOW, "piix4_smbus", piix4_aux_adapter);

Výpis z /proc/interrupts vyzerá takto:

            CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       CPU8       CPU9       CPU10      CPU11      CPU12      CPU13      CPU14      CPU15
   0:        110          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-IO-APIC    2-edge      timer
   1:          0          0          0          0          0          0          0          0          0          0          0       3298          0          0          0          0  IR-IO-APIC    1-edge      i8042
   7:          0          0          0          0          0          0          0          0          0          0          0          0          0          3          0          0  IR-IO-APIC    7-edge      piix4_smbus

Kernel síce registruje môj interrupt handler, ale je nastavený ako edge triggered, nie level triggerred.

Súčasný kernel driver používa pre kontrolu stavu aktívne čakanie v slučke. Teda nastaví príslušné registre a v slučke kontroluje, vyčistenie bitu busy. Ja sa snažím prepísať ovládač, tak, aby bol riadený priamo prerušeniami bez použitia aktívneho čakania. Teraz prichádza paradox:

Po spustení prvej transakcie nedôjde k volaniu prerušenia. Pri druhej, tretej atď áno. V prerušení je vždy status 0, teda zariadenie nie je busy, nedokončilo operáciu, neskončilo chybou. Teda v stave, v akom by malo byť pred transakciou. Tak mi to vŕtalo v hlave a pozrel som sa na časovanie:

[  297.581942] Quick
[  297.581949] isr HostStatus=00

Interrupt handler je spustený o 7µs. Pripomeňme si, čo je vlastne quick write. Na I2C zbernici môže byť niekoľko zariadení. Každé zariadenie má 7-bitovú adresu. Komunikácia s každým zariadením začína tým, že master vyšle start bit, potom adresu, R/W bit a nakoniec čaká na potvrdenie od zariadenia. Ak zariadenie potvrdí príjem, komunikácia môže pokračovať. Quick write príkaz je len odoslanie adresy, čo je veľmi pekne vymyslené, pretože umožňuje enumerovať zariadenia (každé zariadenie, ktoré chce komunikovať musí najskôr odpovedať na svoju adresu). No ok, to som už asi zašiel trochu do detailov.

Takže pošlem 10 bitov a interrupt handler sa spustí o 7µs po spustení druhého a každého ďalšieho zápisu. Z PM registra namapovaného cez MMIO viem, že frekvencia zbernice je 100kHz. Maximálna frekvencia je 1MHz. Ak beriem do úvahy to, čo viem prečítať z registrov, potom minimálny čas do ukončenia transakcie mal byť 100µs. Aj keby zbernica bežala na maximálnej frekvencii, nebolo by to pod 10µs. Takže interrupt handler sa mi spúšťa určite pred spustením transakcie (alebo prejsnejšie povedané po uvoľnení interrupt line), zatiaľ čo vo windowse to funguje po ukončení transakcie. Preto mám neplatný stav a preto zrejme dochádza ku kolíziám, pretože sa snažím vysielať presne v momente, keď sa o to snaží zariadenie.

Otázka znie, prečo kernel ignoruje moju požiadavku o level triggered interrupt?