Sure - here it comes:
I'm currently using it, looks very good. But I noticed it gets hot. I noticed that there were efforts regarding the fan, but could not find in in the DTS. Is there something I can try?
BTW, works perfect with the genric BDF 
Thank you!
There is a new driver in 6.1, but its platform data only, no DTS as DT guys cannot agree on a common fan bindings
Thanks!
I'll trust the throtteling until they have chosen the way to go 
I generated a BDF with the AX9000 variant, but based on the generic one from the ath11k repo. Perhaps that's a good intermediate solution?
What do you mean generated but based on the generic one?
I used ath11k-bdencoder to disamble the generic BDF, took this one "bus=pci,qmi-chip-id=0,qmi-board-id=255.bin" out of it and repacked it like this
[
{
"board": [
{
"names": [
"bus=pci,qmi-chip-id=0,qmi-board-id=255,variant=Xiaomi-AX9000"
],
"data": "bus=pci,qmi-chip-id=0,qmi-board-id=255.bin"
}
],
"regdb": []
}
]
So no DTS patching is needed to use the generic one. And later, if someone can finally repackage the real BDF, the file can just be replaced.
Well, it would be easier to just use the upstream board-2.bin then instead of repacking, its not really good solution anyway as I doubt frequency limits are proper in the generic BDF
OK. ATM I do not see any problems, but I'm using it on channel 36 statically.
But main thing is that I can finally use the device in my main site.
What are the channels it allows to be used on the QCN card?
Its nice to be able to use it yeah, as it felt kind of crippled so far
Absolutely! All in 5G are possible:
Frequencies:
* 5180 MHz [36] (30.0 dBm)
* 5200 MHz [40] (30.0 dBm)
* 5220 MHz [44] (30.0 dBm)
* 5240 MHz [48] (30.0 dBm)
* 5260 MHz [52] (24.0 dBm) (radar detection)
* 5280 MHz [56] (24.0 dBm) (radar detection)
* 5300 MHz [60] (24.0 dBm) (radar detection)
* 5320 MHz [64] (24.0 dBm) (radar detection)
* 5500 MHz [100] (24.0 dBm) (radar detection)
* 5520 MHz [104] (24.0 dBm) (radar detection)
* 5540 MHz [108] (24.0 dBm) (radar detection)
* 5560 MHz [112] (24.0 dBm) (radar detection)
* 5580 MHz [116] (24.0 dBm) (radar detection)
* 5600 MHz [120] (24.0 dBm) (radar detection)
* 5620 MHz [124] (24.0 dBm) (radar detection)
* 5640 MHz [128] (24.0 dBm) (radar detection)
* 5660 MHz [132] (24.0 dBm) (radar detection)
* 5680 MHz [136] (24.0 dBm) (radar detection)
* 5700 MHz [140] (24.0 dBm) (radar detection)
* 5720 MHz [144] (24.0 dBm) (radar detection)
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
* 5845 MHz [169] (30.0 dBm)
* 5865 MHz [173] (30.0 dBm)
Of course >149 doesn't make sense because it's used be the soc 5G.
And that is what I am talking about, stock BDF will limit those as RF filters are only for a certain range as other radio is handling them
Now I understod your point!
Played a bit around with 2.7 firmware. It seems, that CMA is needed for QCN9074, otherwise it will bail out with an DMA error.
I used this
diff --git a/target/linux/ipq807x/config-5.15 b/target/linux/ipq807x/config-5.15
index 9be335ab15..1eee56b8a6 100644
--- a/target/linux/ipq807x/config-5.15
+++ b/target/linux/ipq807x/config-5.15
@@ -57,6 +57,17 @@ CONFIG_BLK_PM=y
CONFIG_CAVIUM_TX2_ERRATUM_219=y
CONFIG_CC_HAVE_STACKPROTECTOR_SYSREG=y
CONFIG_CLONE_BACKWARDS=y
+CONFIG_CMA=y
+# CONFIG_CMA_DEBUG is not set
+# CONFIG_CMA_DEBUGFS is not set
+# CONFIG_CMA_SYSFS is not set
+CONFIG_CMA_AREAS=7
+CONFIG_CMA_SIZE_MBYTES=0
+CONFIG_CMA_SIZE_SEL_MBYTES=y
+# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
+# CONFIG_CMA_SIZE_SEL_MIN is not set
+# CONFIG_CMA_SIZE_SEL_MAX is not set
+CONFIG_CMA_ALIGNMENT=8
CONFIG_COMMON_CLK=y
CONFIG_COMMON_CLK_QCOM=y
# CONFIG_COMPAT_32BIT_TIME is not set
@@ -112,6 +123,7 @@ CONFIG_CRYPTO_ZSTD=y
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_DEV_COREDUMP=y
CONFIG_DMADEVICES=y
+CONFIG_DMA_CMA=y
CONFIG_DMA_DIRECT_REMAP=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_OF=y
diff --git a/target/linux/ipq807x/files/arch/arm64/boot/dts/qcom/ipq8072-ax9000.dts b/target/linux/ipq807x/files/arch/arm64/boot/dts/qcom/ipq8072-ax9000.dts
index 19af017432..fd5a3b21d4 100644
--- a/target/linux/ipq807x/files/arch/arm64/boot/dts/qcom/ipq8072-ax9000.dts
+++ b/target/linux/ipq807x/files/arch/arm64/boot/dts/qcom/ipq8072-ax9000.dts
@@ -34,6 +34,16 @@
bootargs-append = " root=/dev/ubiblock0_1";
};
+ reserved-memory {
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x00000000 0x04000000>;
+ linux,cma-default;
+ };
+ };
+
keys {
compatible = "gpio-keys";
This should sort it out:
http://lists.infradead.org/pipermail/ath11k/2022-October/003640.html
1 Like
Of course there's a patch for ath11k 
But it does not help with the board-2.bin problem. 
I dont expect it to help with that
Another Reason why I'm trying 2.7 is that I have these errors after some days:
[371247.208603] ath11k_pci 0000:01:00.0: Failed to add station: dc:e5:5b:00:xx:xx for VDEV: 1
[371247.215720] ath11k_pci 0000:01:00.0: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 8 (-105)
[371247.223762] ath11k_pci 0000:01:00.0: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 9 (-105)
[371247.232688] ath11k_pci 0000:01:00.0: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 10 (-105)
[371247.241634] ath11k_pci 0000:01:00.0: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 11 (-105)
[371247.250550] ath11k_pci 0000:01:00.0: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 12 (-105)
After that all radios are broken.
1 Like