Re: [ath9k-devel] atk9k PCIe-card sometimes comes up with wrong PCI ID
On 10/21/2013 02:51 PM, Holger Schurig wrote: Hi ! I'm using several Sparklan WPEA 110N cards that normally come up as 168c:002a. But sometimes they announces themself as 168c:ff1c. Even lspci -nn -A intel-conf2 (which goes directly to the PCI address range) shows the wrong PCI ID in such cases. What could be the cause of this issue? I have seen such behaviour on older cards if the card sees two reset pulses in too short succession - ie. when the second reset pulse happens while the card is still loading data from the EEPROM. Newer Atheros cards use I2C EEPROMs, so a chip reset during communication can hang up the bus to the EEPROM. cu Michael ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On 03/28/2013 04:04 PM, Steffen Dettmer wrote: I talked with an expert of my unit about resetting PCI express cards. The units have a special controller (I^2C) able to power off and power on the card slots. I was told that this does not handle the PCI reset line correctly (leaves it open), but makes a hard cut to the 3 volts (I hope I repeat it correctly). For my WPEA-121N cards, such a power cycle in my tests so far worked around the issue. Even if it works, it is not PCI(e) compliant. When physically powering up a PCI device, you *have* to assert the reset signal to the slot. cu Michael ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Am 27.03.2013 23:33, schrieb Adrian Chadd: Sure, here's what's going on: * There's a PCI bus reset. It's a pin. On the PCI bus. * The BIOS can yank that down to reset all the devices. * There's timing requirements for how long that pin can be pulled down to reset and release. * After the PCI bus is reset, the atheros MAC initialises the PCI space by reading a bunch of values from EEPROM/OTP and writing them into the register space. Most of these are PCI space registers but there can be others. * Some vendors do daft things, like multiple quick PCI bus resets back-to-back rather than doing a reset and waiting for whatever the standard requires or the best practice is; or just asserting reset quickly rather than holding it down for the required time is; * .. and this can interrupt / confuse the MAC during this whole register initialisation path. I have had this on an ambedded design - IIRC with an AR5414, back when Atheros switched from 3-wire EEPROMs to I2C EEPROMs on the MiniPCI modules. If you do a PCI reset just at the time when the MAC is doing an I2C read, the I2C EEPROM will hang in the middle of a bus cycle, with no possibility to reset it when the MAC does the next read access, so at least the first read will get corrupt data. AFAIK, the PCI standard does not forbid this (there are only minimum times for *assertion* of the reset signal), so technically, the card violates the PCI spec if it can't cope with two PCI resets in direct order. However, I would consider this really bad practice. In our case, inserting a minimum delay between the point where the hardware de-asserts reset and the point where the code re-asserts it (because it might be a warm boot) fixed the problem reliably. cu Michael ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] support for AR9220
Queenie de Melo wrote: Dear All, Iam using kernel 2.6.27 due to cross-compile some reasons but when i use the lastest ath9k, i get only the wlan0 interface. Is AR9220 chipset supported by ath9k driver? how can i verify that? It is definitely supported - I have an AR9220-based card in my Thinkpad 41T. It basically just works (with some stability and regdomain problems left), using compat-wireless from 2-3 months ago. cu Michael ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k firmware
hong zhang wrote: firmware runs on microprocessor on wifi chip and driver runs on main CPU. If no firmware, how driver utilizes microprocessor on wifi chip? If driver all runs on main CPU, does it waiste resource of microprocessor of wifi chip and slow down speed? The Atheros PCI chips do not have a microprocessor, and thus do not need any firmware. The MAC (including encryption) is implemented in hardware, doing descriptor-based DMA (just like a PCI ethernet chip), with the help of some timers for beacon transmission etc.. All the higher 802.11 protocol stuff is handled on the host CPU (which does not cost much in terms of CPU cycles - these are just protocol frames), which makes the chips quite flexible. cu Michael ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
