From owner-freebsd-wireless@freebsd.org Thu Dec 28 20:22:46 2017 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A312AEB21C5 for ; Thu, 28 Dec 2017 20:22:46 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D0BE6950D for ; Thu, 28 Dec 2017 20:22:46 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-yw0-x232.google.com with SMTP id r205so8846136ywb.3 for ; Thu, 28 Dec 2017 12:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lGKUYBae1pl7fyKidsJ9x7r/8JHMFx25+UF45cRknrQ=; b=JBUac/6mjs2qr+DwVeLAMtSlwINtSnrBmLr3ax/i7jizLPaguJa/33Mmfu+WnYC8lC zJ9qerz3ZuYSC2Bwj/4/M4FT65xX5wplWbdAr419YTxlIPxEKzuZFznfiriLnIFlLPrp WPsimrScJIAGbxrI+8nEjh5VjWuRMYSZ3O4rskB1Tay+BskABoZ8cqWVOV1x9m8BbPsu aNFXTJ9wNMEwcx28VRG01MeSSnmTG8kb8+JWbxlMO5gufD84yiFwQOWpvLj4Qk0DI6Dv gDJnmXtQ2Zf+AWnRSl9SymxfhG42tYQI1+LRkYAWRrpEy3UJAEZ4Gp3Qy1+BH8hZG7+X 9ZyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lGKUYBae1pl7fyKidsJ9x7r/8JHMFx25+UF45cRknrQ=; b=HQREwVw2LOXCGyRkwm+MQT4qigI+hyI3aGLqVdFz5gH9recYQ9ZnNZp23b3OLcMMtH x3citFjXqG5D7UOD74Bmm1rMRH+Zm+poj18ZvFTw/D1FbDwIVjZcfBq3HbYw7H1qDu6M N6ITkA9bwd4qHOWTtyj3P6ypiWr04zexz7kFV62zfuzFFEYqPq3Dz+5vZ/UT276Ugy64 wE/1hLjiGc4Q+dhBFrZ4KE6ucV8winUohsSAHs7BVP6f5E5uwdKmMdxXfNz+BDxbIqm6 oGl0sEHrQEMl9fsyNU7n0Uaj6CtHbgwWA3B0gAKHE5olyGpwzONw1aOz0bEXaMM9bfHO oSRQ== X-Gm-Message-State: AKGB3mLy42ez5bZCUl9tiT5M1tvQeFLk8KNtEG7PscUgf3L8Hl90PWgd TwFYCllLeBjvadxPyIfPjEY0N9/HoD79SMpo5Kg= X-Google-Smtp-Source: ACJfBotkC/Sc/A/yCglOh8W0sTHWkZbqXCmlyaV2E3FlWQK1VJcK1o+AZZZvWJCPLcq58IianJpvHB7zIO68UJFEzA8= X-Received: by 10.13.215.76 with SMTP id z73mr22031527ywd.213.1514492565161; Thu, 28 Dec 2017 12:22:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.131.194 with HTTP; Thu, 28 Dec 2017 12:22:24 -0800 (PST) In-Reply-To: References: From: Farhan Khan Date: Thu, 28 Dec 2017 15:22:24 -0500 Message-ID: Subject: Re: rtwn(4) extension rtl8188ee receiving constantly interrupts To: Andriy Voskoboinyk Cc: freebsd-wireless@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 20:22:46 -0000 Hi Andriy, I attempted to re-write all bits back, but the result is the same. Strange. Perhaps the initialization code is wrong somewhere? I will give it another review. -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE On Thu, Dec 28, 2017 at 4:28 AM, Andriy Voskoboinyk wrote: > Hi, > > there are some issues that may cause wrong interrupt handling: > > 1) IMR register bits - they were taken from 92c > (and they are not compatible - for example, RXFOVW seems to be moved > to the ext register) > > 2) Try to ACK (write back) all bits, > not masked ones (like it is done for 92c) > > > > 2017-12-22 0:43 GMT+02:00, Farhan Khan : > >> Hi, >>> >>> As I wrote a few weeks back, I am working on the extension to rtwn(4) to >>> add >>> RTL8188EE support. At the moment, I am working on the Rx code, which >>> handles >>> interrupts. After the interrupt is triggered, the code goes into the Rx >>> routine >>> and delivers "junk data" in a continuous loop. It seems that the >>> interrupt >>> code >>> is **constantly** called - enough that the load average is frequently >>> above >>> 1.0. >>> >>> I suspect the issue is giving the WiFi driver an acknowledgement of some >>> sort, >>> but I am not certain. I attempted to copy Linux's interrupt code as best >>> as >>> possible, but cannot determine if the error is within my code. >>> >>> Here is a verbose explanation of what I believe Linux is doing and what I >>> am >>> doing on FreeBSD. >>> >>> -----Linux code works as follows----- >>> >>> 1. The IRQ trigger calls the function _rtl_pci_interrupt >>> (drivers/net/wireless/realtek/rtlwifi/pci.c) >>> 2. This calls disable_interrupt, which for rtl8188ee is >>> rtl88ee_disable_interrupt. This function writes IMR_DISABLED (0x0) to >>> REG_HIMR (0xb0) and REG_HIMRE (0xb8). >>> 3. Next _rtl_pci_interrupt calls interrupt_recognized(), a function >>> pointer >>> to >>> rtl88ee_interrupt_recognized(), which: >>> * Reads from REG_HISR (0xb4), stores the value in 'inta', ANDs that >>> value >>> by >>> 0x200084ff, then writes that value back to the same register. >>> * Reads from REG_HISRE (0xbc), stores the value in 'intb', ANDs that >>> value by >>> 0x100, then writes that value back to the same register. >>> Then the function returns returns. >>> >>> 4. Back in _rtl_pci_interrupt if 'inta' is 0 and 'intb' is 0xffff, the >>> code >>> will >>> skip step 5, goto to "done" and execute enable_interrupt code >>> (rtl88ee_enable_interrupt) >>> >>> 5. If bit(0) is set to 1, this is an Rx interrupt and will run >>> _rtl_pci_rx_interrupt(). From my review of the code, from here the >>> Linux >>> driver will read from the DMA memory and send the frame to the >>> ieee80211 >>> layer. I only found 1 additional read instruction related to the power >>> value, >>> but nothing else is changed. >>> >>> 6. Here is the "done" portion, that happens no matter what, but is jumped >>> to >>> immediately as referenced above. It will call enable_interrupt(), a >>> function >>> pointer to rtl88ee_enable_Interrupt(), which will: >>> a. Write 0x200084ff to REG_HIMR (0xb0) >>> b. Write 0x100 to REG_HIMRE (0xb8) >>> c. Write 0 to to REG_C2HEVT_CLEAR (0x01AF, A register having to do >>> with >>> C2H >>> firmware) >>> d. Write 0xc0 to REG_HSIMR (0x58 , I know this value from printf'ing >>> it) >>> >>> This is what I identified from reviewing from the Linux code. >>> >>> -----My FreeBSD Code----- >>> >>> My code is located here: >>> https://github.com/khanzf/freebsd/tree/rx_not_working/sys/dev/rtwn/. >>> >>> 1. The IRQ trigger calls the function rtwn_pci_intr() >>> (sys/dev/rtwn/pci/rtwn_pci_rx.c) >>> 2. The equivalent of Linux's line 2 and 3 is in rtwn_classify_intr, >>> which is >>> a >>> pointer to r88ee_enable_intr located in >>> sys/dev/rtwn/rtl8188e/pci/r88ee_rx. >>> This write's 0x0 to REG_HIMR (0xb0) and REG_HIMRE (0xb8) >>> 3. Continuing, the same function: >>> * Reads from ISR_MINE (same as REG_HISR, 0xb4), ANDs the value by >>> 0x200084ff, >>> store it in 'status'. Then I write the value back to the same >>> register. >>> * Read from REG_HISRE (0xbc), AND the value by 0x100, store it in >>> 'statusb'. >>> Write this value back to the same register. >>> * Since this is an Rx register, the 'ret' value is AND'd by >>> RTWN_PCI_INTR_RX. >>> >>> 4. In the Linux code, if 'status' is 0x0 and 'statusb' is 0xFFFF, it will >>> goto >>> to "done". On FreeBSD, it simply does not set any bits on the 'ret' >>> value >>> and >>> the function returns 0, going back to rtwn_pci_intr. >>> >>> 5. Returning to rtwn_pci_intr(), if the 'ret' (now 'status') has >>> RTWN_PCI_INTR_RX flag on, it executes rtwn_pci_tx_done(), which will >>> read >>> the >>> DMA memory and send the frame to the ieee80211 layer. The execution >>> will >>> skip >>> step 5 if 'ret' was 0 (the RTWN_PCI_INTR_RX flag was never set). This >>> returns >>> execution back to rtwn_pci_intr(). >>> >>> 6. rtwn_pci_intr() concludes by running rtwn_pci_enable_intr(). This is >>> similar >>> to Linux's enable_interrupt(), it does the following: >>> a. Write 0x200084f to R88EE_HIMR (0xb0) >>> b. Write 0x100 to R88EE_HIMRE (0xb8) >>> c. Write 0x0 to REG_C2HEVT_CLEAR (0x01AF) >>> d. Write 0xc0 to REG_HSIMR >>> >>> --------- >>> >>> To me, it appears that I did a complete 1-to-1 copy of the Linux code. >>> However, >>> in my case the driver is receiving constant interrupts without stopping. >>> I >>> am >>> not certain what I am missing or what is different. Could it be that >>> something >>> outside of this particular code path was not properly set. If so, what >>> might >>> that be? >>> >>> Please advise. >>> Thank you, >>> >>> -- >>> Farhan Khan >>> PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@ >>> freebsd.org" >>> >>