From owner-freebsd-wireless@freebsd.org Thu Dec 28 09:28:57 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 DC18EE8363F for ; Thu, 28 Dec 2017 09:28:57 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 5F65573398 for ; Thu, 28 Dec 2017 09:28:57 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id y78so39051829lfd.1 for ; Thu, 28 Dec 2017 01:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=136+nzz1dy1Cp98poGiJ0A1QJO91NxDUQM6W46NxPJo=; b=l7b9fxBqy2SXODzfdZWBnO3jSQ5hF8u0mmMwiKOw4q3bO96oqoUijcZtkYVyLyYlEV ipP34ss6f3E2mM7Uf8Ju2+9ZTtnSGVCXmgG4NTedZSg4tFFYqY2ac57dfrItVfjh0Mef dqiebbiRe4DC4RkU9IQZWV56EP4FjztdgTdmi3bYhXB79IAhGhRZ7YUomgNdqwl8FSmZ LR82UCJBOD3Icwly0vNs+3P3SPwES9YOSFFp4NY0SeJJaVPm4P6CbzvsAnb1I8USstOZ aBI4vv1hcpnYwkiKtctWPtO0a2ZMhxC0zHWis4FEQD9fCo8bW5oNeTAD2NIW9nQVZx6s A7Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=136+nzz1dy1Cp98poGiJ0A1QJO91NxDUQM6W46NxPJo=; b=L1/Gjp6RaXVehc223PVk2bw7HaGZwerqNBihB62ZbcLzPhMrZUKBGnK4pm9PhbnqK3 T/ow34wgVRv13Hd108rVkhZFL+2SXtQeoyEi0H5smhZk1kM23UwH6D8xEyc+aQcRNpTj FLpC1NBK2L23ZMcZQbU0yFOExWqQyy+c1jIDO7m8Tbs26XOXQ4etYBROCx9pJTszx54R iz6Fb9zLythHgmm6wFDcRIjDHKAKAmFc1Uc8Pg0w+6OlizKQRdw6gqIMwu5Na49KNFqr N+HwWXbbW159eraxhnhc2EhL45mJJNYfJ8M7CEcZz8YKK7AcGIh4xmIsmj2tIH8O067P j2hQ== X-Gm-Message-State: AKGB3mImNbSF1XbrbN414FVPa2V7O2SDdvQ3dRhlEcyz9z9WLksxRZus Bk/6axW0NUSWA7direbrVYY= X-Google-Smtp-Source: ACJfBotu08ZRwWSCuJu9IJ+Fq0ExQ9g/4DnUEtXZ8BOjQxek+0ALJhB93Jl394JWKososx+TKUMglQ== X-Received: by 10.25.143.71 with SMTP id r68mr15845357lfd.85.1514453335544; Thu, 28 Dec 2017 01:28:55 -0800 (PST) Received: from localhost (46-133-212-82.dialup.umc.net.ua. [46.133.212.82]) by smtp.gmail.com with ESMTPSA id t17sm6539064lfi.33.2017.12.28.01.28.54 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 28 Dec 2017 01:28:54 -0800 (PST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Farhan Khan" Cc: freebsd-wireless@freebsd.org Subject: Re: rtwn(4) extension rtl8188ee receiving constantly interrupts References: Date: Thu, 28 Dec 2017 11:28:47 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (FreeBSD) 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 09:28:58 -0000 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"