| Message ID | 20211026041616.4956-1-bqiang@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | ath11k: support one MSI vector | expand |
Baochen Qiang <bqiang@codeaurora.org> writes: > This patch set is to support one MSI vector for QCA6390. > > Depends-On: > 1. ath11k: Fix crash caused by uninitialized TX ring > https://patchwork.kernel.org/project/linux-wireless/patch/20211026011605.58615-1-quic_bqiang@quicinc.com/ > > Baochen Qiang (1): > ath11k: Set IRQ affinity to CPU0 in case of one MSI vector > > Carl Huang (6): > ath11k: get msi_data again after request_irq is called > ath11k: add CE and ext IRQ flag to indicate irq_handler > ath11k: use ATH11K_PCI_IRQ_DP_OFFSET for DP IRQ > ath11k: refactor multiple MSI vector implementation > ath11k: supports one MSI vector > ath11k: do not restore ASPM in case of single MSI vector I assume this is v2 of Carl's patchset: https://patchwork.kernel.org/project/linux-wireless/cover/20201223030225.2345-1-cjhuang@codeaurora.org/ Can you provide a changelog? No need to resend because of that, just a reply to this thread enough.
On 2021-11-15 18:30, Kalle Valo wrote: > Baochen Qiang <bqiang@codeaurora.org> writes: > >> This patch set is to support one MSI vector for QCA6390. >> >> Depends-On: >> 1. ath11k: Fix crash caused by uninitialized TX ring >> >> https://patchwork.kernel.org/project/linux-wireless/patch/20211026011605.58615-1-quic_bqiang@quicinc.com/ >> >> Baochen Qiang (1): >> ath11k: Set IRQ affinity to CPU0 in case of one MSI vector >> >> Carl Huang (6): >> ath11k: get msi_data again after request_irq is called >> ath11k: add CE and ext IRQ flag to indicate irq_handler >> ath11k: use ATH11K_PCI_IRQ_DP_OFFSET for DP IRQ >> ath11k: refactor multiple MSI vector implementation >> ath11k: supports one MSI vector >> ath11k: do not restore ASPM in case of single MSI vector > > I assume this is v2 of Carl's patchset: > > https://patchwork.kernel.org/project/linux-wireless/cover/20201223030225.2345-1-cjhuang@codeaurora.org/ > > Can you provide a changelog? No need to resend because of that, just a > reply to this thread enough. Hi Kalle, this is the changelog: 1. changes by Kalle based on Carl's v1: * add a log message for MSI vector count * add a log message when disabling ASPM * patch 1: fix error handling in ath11k_pci_probe() * patch 1: simplify ath11k_pci_config_msi_data() * patch 2: convert booleans to set_bit() & co for atomic access * patch 2:__ath11k_pci_ext_irq_disable(): fix compilation * patch 4: bool vectors_32_capability to set_bit() for atomic access * patch 4: ath11k_mhi_get_msi(): don't use ? operator * improve commits logs a bit 2. changes by Baochen based on Kalle's version: * add a new patch: "ath11k: Set IRQ affinity to CPU0 in case of one MSI vector" * address Jeff's comments on "ath11k: do not restore ASPM in case of single MSI vector": change debug info from "disabling PCI ASPM ..." to "leaving PCI ASPM disabled ..." * change error handling in patch "ath11k: get msi_data again after request_irq is called" * address Vasanth's comments on "ath11k: refactor multiple msi vector implementation"
Baochen Qiang <bqiang@codeaurora.org> writes: > On 2021-11-15 18:30, Kalle Valo wrote: >> Baochen Qiang <bqiang@codeaurora.org> writes: >> >>> This patch set is to support one MSI vector for QCA6390. >>> >>> Depends-On: >>> 1. ath11k: Fix crash caused by uninitialized TX ring >>> https://patchwork.kernel.org/project/linux-wireless/patch/20211026011605.58615-1-quic_bqiang@quicinc.com/ >>> >>> Baochen Qiang (1): >>> ath11k: Set IRQ affinity to CPU0 in case of one MSI vector >>> >>> Carl Huang (6): >>> ath11k: get msi_data again after request_irq is called >>> ath11k: add CE and ext IRQ flag to indicate irq_handler >>> ath11k: use ATH11K_PCI_IRQ_DP_OFFSET for DP IRQ >>> ath11k: refactor multiple MSI vector implementation >>> ath11k: supports one MSI vector >>> ath11k: do not restore ASPM in case of single MSI vector >> >> I assume this is v2 of Carl's patchset: >> >> https://patchwork.kernel.org/project/linux-wireless/cover/20201223030225.2345-1-cjhuang@codeaurora.org/ >> >> Can you provide a changelog? No need to resend because of that, just a >> reply to this thread enough. > > Hi Kalle, this is the changelog: > > 1. changes by Kalle based on Carl's v1: > > * add a log message for MSI vector count > * add a log message when disabling ASPM > * patch 1: fix error handling in ath11k_pci_probe() > * patch 1: simplify ath11k_pci_config_msi_data() > * patch 2: convert booleans to set_bit() & co for atomic access > * patch 2:__ath11k_pci_ext_irq_disable(): fix compilation > * patch 4: bool vectors_32_capability to set_bit() for atomic access > * patch 4: ath11k_mhi_get_msi(): don't use ? operator > * improve commits logs a bit > > 2. changes by Baochen based on Kalle's version: > > * add a new patch: "ath11k: Set IRQ affinity to CPU0 in case of one > MSI vector" > * address Jeff's comments on "ath11k: do not restore ASPM in case of > single MSI vector": > change debug info from "disabling PCI ASPM ..." to "leaving > PCI ASPM disabled ..." > * change error handling in patch "ath11k: get msi_data again after > request_irq is called" > * address Vasanth's comments on "ath11k: refactor multiple msi vector > implementation" Thanks. I shortly tested this patchset (commit 5d9dd5b3db33 in master-pending) on a NUC x86 box and Dell XPS 13 9310 laptop using QCA6390 hw2.0, both with 32 MSI vectors (VT-d enabled in BIOS) and 1 MSI vector (VT-d disabled in BIOS). No issues found, and also suspend works fine for me. So I think we have solved all the stability issues.
On 2021-11-19 20:31, Kalle Valo wrote: > Baochen Qiang <bqiang@codeaurora.org> writes: > >> On 2021-11-15 18:30, Kalle Valo wrote: >>> Baochen Qiang <bqiang@codeaurora.org> writes: >>> >>>> This patch set is to support one MSI vector for QCA6390. >>>> >>>> Depends-On: >>>> 1. ath11k: Fix crash caused by uninitialized TX ring >>>> >>>> https://patchwork.kernel.org/project/linux-wireless/patch/20211026011605.58615-1-quic_bqiang@quicinc.com/ >>>> >>>> Baochen Qiang (1): >>>> ath11k: Set IRQ affinity to CPU0 in case of one MSI vector >>>> >>>> Carl Huang (6): >>>> ath11k: get msi_data again after request_irq is called >>>> ath11k: add CE and ext IRQ flag to indicate irq_handler >>>> ath11k: use ATH11K_PCI_IRQ_DP_OFFSET for DP IRQ >>>> ath11k: refactor multiple MSI vector implementation >>>> ath11k: supports one MSI vector >>>> ath11k: do not restore ASPM in case of single MSI vector >>> >>> I assume this is v2 of Carl's patchset: >>> >>> https://patchwork.kernel.org/project/linux-wireless/cover/20201223030225.2345-1-cjhuang@codeaurora.org/ >>> >>> Can you provide a changelog? No need to resend because of that, just >>> a >>> reply to this thread enough. >> >> Hi Kalle, this is the changelog: >> >> 1. changes by Kalle based on Carl's v1: >> >> * add a log message for MSI vector count >> * add a log message when disabling ASPM >> * patch 1: fix error handling in ath11k_pci_probe() >> * patch 1: simplify ath11k_pci_config_msi_data() >> * patch 2: convert booleans to set_bit() & co for atomic access >> * patch 2:__ath11k_pci_ext_irq_disable(): fix compilation >> * patch 4: bool vectors_32_capability to set_bit() for atomic access >> * patch 4: ath11k_mhi_get_msi(): don't use ? operator >> * improve commits logs a bit >> >> 2. changes by Baochen based on Kalle's version: >> >> * add a new patch: "ath11k: Set IRQ affinity to CPU0 in case of one >> MSI vector" >> * address Jeff's comments on "ath11k: do not restore ASPM in case of >> single MSI vector": >> change debug info from "disabling PCI ASPM ..." to "leaving >> PCI ASPM disabled ..." >> * change error handling in patch "ath11k: get msi_data again after >> request_irq is called" >> * address Vasanth's comments on "ath11k: refactor multiple msi vector >> implementation" > > Thanks. I shortly tested this patchset (commit 5d9dd5b3db33 in > master-pending) on a NUC x86 box and Dell XPS 13 9310 laptop using > QCA6390 hw2.0, both with 32 MSI vectors (VT-d enabled in BIOS) and 1 > MSI > vector (VT-d disabled in BIOS). No issues found, and also suspend works > fine for me. So I think we have solved all the stability issues. Great to hear that. But one more thing Kalle, have you met the issue which is originally reported here https://jira-dc.qualcomm.com/jira/browse/LUW-3 ?