Hm, is the 0x5 chainmask triggering the ALT_CHAIN logic? What are you trying to do? Control the receive antenna config, or the transmit antenna config? -a On 8 November 2013 16:32, Julius Schulz-Zander <julius@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi Sven, > > I've asked nbd about this some time ago. It doesn't work if you have gaps in the chain mask! Try chain mask 3 (110) and it should work with 2x2. > > Regards, > -Julius > > On 06.11.2013, at 16:04, Sven Eckelmann <sven@xxxxxxxxxxxxx> wrote: > >> Hi, >> >> I've needed to test some problems with a QCA9558 Rev 0 based 3x3 2.4G device. >> During these tests I've wanted to try different antenna configurations to >> reduce the complexity of the problem. This was done by setting the >> rxchainmask/txchainsmask to settings like 1, 5 and 7. Unfortunatelly, the >> setting 5 (antenna 0 and 1) turned the device completely deaf. Here an >> overview of the settings (excerpt) >> >> chainmask | ant 0 | ant 1 | ant 2 | Status >> 1 | 1 | 0 | 0 | works >> 5 | 1 | 0 | 1 | deaf >> 7 | 1 | 1 | 1 | works >> >> The antenna setting is used in ath9k at different places but trigger seems to >> be the AR_PHY_RX_CHAINMASK register write in ar9003_phy.c in the function >> ar9003_hw_set_chain_masks. Forcing it to 7 instead of the requested 5 avoids >> this deaf state (but makes the rx chainmask setting useless). Of course, this >> is not a valid workaround and quite unexpected. >> >> The test platform was a current trunk OpenWrt build together with compat- >> wireless 2013-02-22, compat-wireless 2013-06-27 and backports 2013-10-31. The >> settings were configured using the txantenna and rxantenna of the OpenWrt >> wireless config system. Both were always set to the same values during the >> tests. >> >> The deaf state was identified using 1x1 and 2x2 clients which could receive >> the beacons of the device. The QCA9558 device was then unable to receive the >> probe request from the clients or any other traffic on the air. This was also >> checked by a monitor (flags: control) interface on the same phy. >> >> Maybe someone knows whether this is a known problem with this SoC or what >> information can be gathered to debug this problem further. >> >> Kind regards, >> Sven >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel@xxxxxxxxxxxxxxx >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@xxxxxxxxxxxxxxxxx > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- 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
