Hi Stanislaw, > -----Ursprüngliche Nachricht----- > Von: Stanislaw Gruszka [mailto:sgruszka@xxxxxxxxxx] > Gesendet: Dienstag, 27. Mai 2014 17:12 > An: Matthias Fend > Cc: linux-wireless@xxxxxxxxxxxxxxx > Betreff: Re: rt2x00: Ralink RT5572 very high peak current consumption > > On Mon, May 26, 2014 at 03:37:36PM +0000, Matthias Fend wrote: > > Hello, > > > > Here are some updates concerning my current issues. > > > > > -----Ursprüngliche Nachricht----- > > > Von: linux-wireless-owner@xxxxxxxxxxxxxxx [mailto:linux-wireless- > > > owner@xxxxxxxxxxxxxxx] Im Auftrag von Matthias Fend > > > Gesendet: Freitag, 23. Mai 2014 14:25 > > > An: linux-wireless@xxxxxxxxxxxxxxx > > > Betreff: rt2x00: Ralink RT5572 very high peak current consumption > > > > > > Hello Ralink experts, > > > > > > I recognized spurious problems with Ralink RT5572 USB-dongles when > > > using this dongles as access point in 5G band. > > > The problems may appear as short usb disconnect-connect events or > > > failed vendor request messages at different offsets with different > > > error codes or will not appear for days ;) During error research I > > > noticed that, most likely during the beacon send time (100ms > > > interval), there are very high peak currents in the supply of the USB- > dongle. > > > > > > I tried it with two different dongles, the base current for all > > > three is in the range of ~200mA: > > > Buffalo WI-U2-300D: Peak ~1A > > > TP-Link TL-WDN3200: Peak ~1.2mA > > > > > > We could reproduce this issue on two different machines (x86 and > > > arm), did test with kernel versions 3.10.19, 3.13.0 and 3.14.4 tried > > > hostapd-2.0 and > > > hostapd-2.1 and loaded chip firmware version V0.29, V0.33 and V0.35. > > > > > > As a comparison I also created an 5G access point setup with a > > > windows7 machine - all with the latest drivers from the manufacturer > webpage. > > > Buffalo WI-U2-300D: Peak 330mA > > > TP-Link TL-WDN3200: Peak 330mA > > > Which seems more legit than the values from the linux setups. > > > > > > The access point functionality itself worked with every tested > > > combination, but there is definitively something wrong. > > > I also started to grab the usb communication of the windows driver > > > to see if there is an obvious difference in some of the written registers. > > > But this kind of reverse engineering is not as easy since the > > > windows driver does not write the same registers as the linux > > > drivers but write some others - and of course I have no > datasheet/register description. > > > > > > Until now the only interesting thing I found out is that the linux > > > driver writes > > > 0x00000082 to the TXOP_HLDR_ET (0x1608) register whereas the > windows > > > driver uses a value of 0x0000000a. Changing this register during > > > runtime in a linux system reduces the current peaks to 50 percent of their > previous value. > > > But there is still something else wrong. > > > > > > So, in my despair I try to get help in any form (hints, > > > datasheets/manuals, ideas, experience, ...). > > > > I found out that the discovered high current peaks are somehow related to > invalidated beacons. > > Usually I can see 1 block with a normal tx-condition current followed by 7 > additional blocks with high current peaks. > > For a test I copied the beacon data from HW_BEACON_BASE0 to > > HW_BEACON_BASE2 and then the first and the third beacon block have > > normal current values while the others still generate high current > > peaks > > > > It seems that setting all five words of the TXWI at the beacon base does not > complete disable the generation of this beacon. > > If I modify the TXIW_W0 of the disabled beacons to 0x40000000 (set > TXWI_W0_PHYMODE as in the really used beacon) then the current > consumption does not exceed the usual value. But it seems that there is still > a short activity for this beacon which, in my opinion, should not be the case. > > > > So, currently I'm wondering about two things: > > -)How do I completely turn off unused beacons (from the measurements > with the windows setup I know that this should be somehow possible)? > > Perhaps this could be MULTI_BCN_NUM value in MAC_BSSID_DW1 register. > Try below patch. If it would help we will need to change way we clear/setup > beacons on multiple BSSes, because seems that HW send MULTI_BCN_NUM > beacons from first registers. You just made my day! This was exactly the setting I was looking for. And yes, it seems that clearing the TXWI at the beacon location is not enough to completely disable beacon sending. Together with the already mentioned change in TXOP_HLDR_ET (use 0x0A instead of 0x82) it's looking identical to the windows setup. Thanks a lot, ~Matthias > > Stanislaw > > diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c > b/drivers/net/wireless/rt2x00/rt2800lib.c > index c17fcf2..2e799d5 100644 > --- a/drivers/net/wireless/rt2x00/rt2800lib.c > +++ b/drivers/net/wireless/rt2x00/rt2800lib.c > @@ -1556,7 +1556,7 @@ void rt2800_config_intf(struct rt2x00_dev > *rt2x00dev, struct rt2x00_intf *intf, > if (!is_zero_ether_addr((const u8 *)conf->bssid)) { > reg = le32_to_cpu(conf->bssid[1]); > rt2x00_set_field32(®, > MAC_BSSID_DW1_BSS_ID_MASK, 3); > - rt2x00_set_field32(®, > MAC_BSSID_DW1_BSS_BCN_NUM, 7); > + rt2x00_set_field32(®, > MAC_BSSID_DW1_BSS_BCN_NUM, 0); > conf->bssid[1] = cpu_to_le32(reg); > } > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
