[OpenWrt-Devel] ath10k TPC reg. domain incorrect?

[Sven Eckelmann]

On Monday, 13 May 2019 22:58:00 CEST Sam Samy wrote:
>  I installed master branch openwrt onto Asus MAP-AC2200 AP. It has tri
> band. Its based on IPQ4019 DK04 QCA reference platform. 2 radios
> (2Ghz/5Ghz) on AHB bus and one 5GHZ on PCIe bus. Its generally working
> fine except one problem in 5Ghz. On both the 5Ghz radios the RSSI is
> pretty low on any 5Ghz channel I put it in.  In one feet range I see -60dB
> RSSI, where as the stock firmware that came with the AP gives an RSSI
> of -36dB at one foot distance.The downstream transmit rates are MCS8/9
> for most part. The 2Ghz is working fine.

It could be the boarddata which contains more than the targetpower and CTLs 
(and thus not necessarily visible in tpc_stats). As first check, test whether 
your board-2.bin has the md5sum 34c1e73e609a27eb9848fdc89cbc2be7 for 
/lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin. Also check that the correct
BDF (with the variant string is loaded). But this should only affect 
the QCA4019 5GHz PHY because the QCA9886 boarddata is generated here using the 
pre-cal data from art (unsure whether this is valid or not for this board and 
bootup sequence).

You can just check with the ath10k-bdencoder [0] from qca-swiss-army-knife 
whether the board files from board-2.bin are the ones which also your stock 
firmware is loading.

The next big problem are filters in the rx/tx chains [1]. The ieee80211-freq-
limit in the DTS file should assist you and not allow you to chose the wrong 
channel/frequency for a specific PHY. But maybe the author accidentally 
switched the settings in the board and actually wanted the lower 5GHz channels 
on the SoC 5GHz PHY and the the upper 5GHz channels on the PCIe card? This 
would be at least worth a try.

> What is the reg. domains 0x20 and 0x58 value points to?

It is 20 (0x14) and not 0x20. Same for 58 (0x3a)

Btw. the regd numbers from QCA can be checked in regd_common.h [2]. The 
mapping in regDomainPairs is not necessarily correct because someone has to 
take them from the newest proprietary driver and use them to update the ath*k 
stuff.

>   Looks like ./sys/kernel/debug/ieee80211/phy2/ath10k/cal_data is junk
> for both the 5Ghz radios even though the
> pre-cal-pci-0000:01:00.0.bin/pre-cal-ahb-a800000.wifi.bin is correct.

Yes, the implemented method for reading the data is not correct for the
wave 2 cards (and maybe also other). You can try the attached hack. At 
least this worked in 2017 when I've poked around in the stuff with 
Christian Lamparter.

Kind regards,
	Sven

[0] https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-bdencoder
[1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=41a86debe3c0a01e075e749d0bb1c6d631e35c32
[2] https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers/net/wireless/ath/regd_common.h?id=5fad78689a9229d08ea11af53e48de3c2a845ea3#n29
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 999-readback-caldata.patch
Type: text/x-patch
Size: 3423 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190514/b5e6ea08/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 999-show-variant.patch
Type: text/x-patch
Size: 663 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190514/b5e6ea08/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190514/b5e6ea08/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel