-
Notifications
You must be signed in to change notification settings - Fork 34
wifi: ath12k: enable QCC2072 support #166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
miaoqing-quic
wants to merge
17
commits into
qualcomm-linux:qcom-6.18.y
Choose a base branch
from
miaoqing-quic:v6.18-tmp
base: qcom-6.18.y
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
wifi: ath12k: enable QCC2072 support #166
miaoqing-quic
wants to merge
17
commits into
qualcomm-linux:qcom-6.18.y
from
miaoqing-quic:v6.18-tmp
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently offset of PCI window register address is defined as 0x310c which is same across existing chips. However QCC2072 has a different offset 0x3278. In order to make the window selection logic work for QCC2072 as well, change to initialize this parameter per device at the probe time. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-1-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
The entry of REO CMD ring of existing chips has a 64 bit TLV header, hence below functions take a 64 bit TLV assumption by default reo_init_cmd_ring reo_cmd_encode_hdr However this is not the case for QCC2072 of which the TLV is 32 bit, meaning above functions don't work for it. Rename/refactor above functions to prepare for QCC2072 support: Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-2-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
The entry of REO status ring of existing chips has a 64 bit TLV header, however this is not the case for QCC2072 of which the TLV is 32 bit. Refactor above functions to prepare for QCC2072 support, this is done by removing TLV length assumption and offloading TLV decoding work to a newly added callback _reo_status_dec_tlv_hdr. This way each chip can register its own handler hence can do the work accordingly. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-3-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…tion For single pdev device like WCN7850/QCC2072, preferred_hw_mode is initialized to WMI_HOST_HW_MODE_SINGLE. Later when firmware sends supported modes to host, each mode is compared with the initial one and if the priority of the new mode is higher, update the parameter and store mode capability. For WCN7850, this does not result in issue, as one of the supported mode indeed has a higher priority. However the only available mode of QCC2072 at this stage is WMI_HOST_HW_MODE_SINGLE, which fails the comparison, hence mode capability is not stored. Subsequently driver initialization fails. Fix it by accepting a mode with the same priority. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-4-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…parsing For single pdev device, 320 MHz bandwidth support is reported only in capability of WMI_HOST_HW_MODE_SINGLE mode, hence commit d4e244c ("wifi: ath12k: enable 320 MHz bandwidth for 6 GHz band in EHT PHY capability for WCN7850") relaxed the condition check in ath12k_wmi_tlv_mac_phy_caps_ext() to allow SINGLE mode getting parsed in ath12k_wmi_tlv_mac_phy_caps_ext_parse(). Since SINGLE mode is not assumed to be preferred, the function returns unconditionally after parsing 320 MHz support. This works for WCN7850 because it prefers another mode indeed, while it breaks QCC2072 since it prefers SINGLE mode. Due to the unconditional return, the subsequent EHT parsing is skipped. Consequently EHT related features are disabled. Refactor it by moving 320 MHz parsing to ath12k_wmi_tlv_mac_phy_caps_ext(), before the mode checking. This makes the code more straightforward, and work for both WCN7850 and QCC2072. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-5-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Currently ath12k_pull_mac_phy_cap_svc_ready_ext() assumes only one band supported in each phy, hence it skips 5 GHz band if 2 GHz band support is detected. This does not work for device which gets only one phy but has both bands supported, such as QCC2072. Change to check each band individually to fix this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-6-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Add hardware registers and populate hw_regs field in ath12k_wifi7_hw_ver_map for QCC2072. Note for some registers not defined and not used by QCC2072, a magic value is assigned. Also populate other fields to be the same with WCN7850. Among them, however, QCC2072 requires different HAL ops and descriptor size, both will be updated in upcoming patches. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-7-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Add hardware parameters for QCC2072, these parameters are directly taken from WCN7850, with exceptions to hardware name, revision, firmware directory, iova_mask and RFKILL parameter set. Compared to WCN7850, QCC2072 doesn't require aligned IOVA when transmitting packets, hence iova_mask is set to zero. Besides, WCN7850 has a dedicated GPIO for RFKILL purpose, however QCC2072 has it coupled with WLAN_EN pin. For QCC2072, host is not allowed to send any RFKILL configuration info to firmware, or firmware crashes. Hence those parameters are all cleared to skip configuring command. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-8-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
… for QCC2072 Firmware (amss.bin) of QCC2072 is a standard ELF image, however those of other chips are not. MHI subsystem supports both format, but by default takes it as non-standard. Flag this to MHI subsystem to avoid firmware loading failure. Also refine hardware parameter dereferencing by defining a new local pointer. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-9-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…type QCC2072 requires a new type of QMI target memory named LPASS_SHARED_V01, add support for it. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-10-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
… image for QCC2072 QCC2072 requires another firmware image named aux_ucode.bin, add support to download it. Add a new hardware parameter download_aux_ucode to make sure other chips are not affected. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-11-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
QCC2072 has different HAL descriptors hence require different HAL handling, compared to other chips. Add support for this. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-12-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Due to HAL descriptors, QCC2027 has different offsets of MPDU start tag and MSDU end tag, compared with other chips. Hence add new hardware ops structure for QCC2072. All ops are directly taken from WCN7850, with the exception to rxdma_ring_sel_config, which needs a new function ath12k_dp_rxdma_ring_sel_config_qcc2072() to handle the difference mentioned above. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-13-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…mmand Currently the number of channels can be sent in a single WMI command is calculated based on the maximum message length of the target, this results in WMI exchange hang for QCC2072 as its firmware can not support those many channels in a single command. Add a limit to avoid this issue. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-16-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…ware Peer meta data version is currently not delivered to firmware, resulting in QCC2072 data path issues. Parse it from service ready ext2 event and send to firmware in WMI init command. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-17-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…inition for QCC2072 The definition of PCIE_LOCAL_REG_QRTR_NODE_ID in QCC2072 is incorrect, which causes the QMI connection to fail when ATH12K_FW_FEATURE_MULTI_QRTR_ID is enabled. To resolve this issue, move it to the hardware register table. Note IPQ5332 is not affected as it is not PCIe based device. Tested-on: QCC2072 hw1.0 PCI CI_WLAN.COL.1.0-01668.1-QCACOLSWPL_V1_TO_SILICONZ-9 Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-18-87928cf8e547@oss.qualcomm.com/
Add QCC2072's PCI device ID to the table such that it can be probed, also populate some parameters when probing. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-19-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.