Message ID | 20220523181836.2019180-1-dmitry.baryshkov@linaro.org |
---|---|
Headers | show |
Series | PCI: qcom: Fix higher MSI vectors handling | expand |
On Mon, May 23, 2022 at 09:18:28PM +0300, Dmitry Baryshkov wrote: > I have replied with my Tested-by to the patch at [2], which has landed > in the linux-next as the commit 20f1bfb8dd62 ("PCI: qcom: > Add support for handling MSIs from 8 endpoints"). However lately I > noticed that during the tests I still had 'pcie_pme=nomsi', so the > device was not forced to use higher MSI vectors. > > After removing this option I noticed that hight MSI vectors are not > delivered on tested platforms. After additional research I stumbled upon > a patch in msm-4.14 ([1]), which describes that each group of MSI > vectors is mapped to the separate interrupt. Implement corresponding > mapping. > > The first patch in the series is a revert of [2] (landed in pci-next). > Either both patches should be applied or both should be dropped. 20f1bfb8dd62 is currently on Lorenzo's pci/qcom branch: $ git log --oneline remotes/lorenzo/pci/qcom bddedfeb1315 dt-bindings: PCI: qcom: Add schema for sc7280 chipset a6f2d6b1b349 dt-bindings: PCI: qcom: Specify reg-names explicitly 81dab110d351 dt-bindings: PCI: qcom: Do not require resets on msm8996 platforms 5383d16f0607 dt-bindings: PCI: qcom: Convert to YAML 3ae93c5a9718 PCI: qcom: Fix unbalanced PHY init on probe errors b986db29edbb PCI: qcom: Fix runtime PM imbalance on probe errors dcd9011f591a PCI: qcom: Fix pipe clock imbalance 3007ba831ccd PCI: qcom: Add SM8150 SoC support f52d2a0f0d32 dt-bindings: pci: qcom: Document PCIe bindings for SM8150 SoC 20f1bfb8dd62 PCI: qcom: Add support for handling MSIs from 8 endpoints 312310928417 Linux 5.18-rc1 Is it safe for me to just drop that single patch before sending the pull request for v5.19? Then target the rest of this series for v5.20? Bjorn
On Tue, 24 May 2022 at 17:53, Bjorn Helgaas <helgaas@kernel.org> wrote: > > On Mon, May 23, 2022 at 09:18:28PM +0300, Dmitry Baryshkov wrote: > > I have replied with my Tested-by to the patch at [2], which has landed > > in the linux-next as the commit 20f1bfb8dd62 ("PCI: qcom: > > Add support for handling MSIs from 8 endpoints"). However lately I > > noticed that during the tests I still had 'pcie_pme=nomsi', so the > > device was not forced to use higher MSI vectors. > > > > After removing this option I noticed that hight MSI vectors are not > > delivered on tested platforms. After additional research I stumbled upon > > a patch in msm-4.14 ([1]), which describes that each group of MSI > > vectors is mapped to the separate interrupt. Implement corresponding > > mapping. > > > > The first patch in the series is a revert of [2] (landed in pci-next). > > Either both patches should be applied or both should be dropped. > > 20f1bfb8dd62 is currently on Lorenzo's pci/qcom branch: > > $ git log --oneline remotes/lorenzo/pci/qcom > bddedfeb1315 dt-bindings: PCI: qcom: Add schema for sc7280 chipset > a6f2d6b1b349 dt-bindings: PCI: qcom: Specify reg-names explicitly > 81dab110d351 dt-bindings: PCI: qcom: Do not require resets on msm8996 platforms > 5383d16f0607 dt-bindings: PCI: qcom: Convert to YAML > 3ae93c5a9718 PCI: qcom: Fix unbalanced PHY init on probe errors > b986db29edbb PCI: qcom: Fix runtime PM imbalance on probe errors > dcd9011f591a PCI: qcom: Fix pipe clock imbalance > 3007ba831ccd PCI: qcom: Add SM8150 SoC support > f52d2a0f0d32 dt-bindings: pci: qcom: Document PCIe bindings for SM8150 SoC > 20f1bfb8dd62 PCI: qcom: Add support for handling MSIs from 8 endpoints > 312310928417 Linux 5.18-rc1 > > Is it safe for me to just drop that single patch before sending the > pull request for v5.19? Then target the rest of this series for > v5.20? Yes and yes.
On Mon, May 23, 2022 at 09:18:28PM +0300, Dmitry Baryshkov wrote: > I have replied with my Tested-by to the patch at [2], which has landed > in the linux-next as the commit 20f1bfb8dd62 ("PCI: qcom: > Add support for handling MSIs from 8 endpoints"). However lately I > noticed that during the tests I still had 'pcie_pme=nomsi', so the > device was not forced to use higher MSI vectors. > > After removing this option I noticed that hight MSI vectors are not > delivered on tested platforms. After additional research I stumbled upon > a patch in msm-4.14 ([1]), which describes that each group of MSI > vectors is mapped to the separate interrupt. Implement corresponding > mapping. > > The first patch in the series is a revert of [2] (landed in pci-next). > Either both patches should be applied or both should be dropped. > > Patchseries dependecies: [3] (for the schema change). > > Changes since v11 (suggested by Johan): > - Added back reporting errors for the "msi0" interrupt, > - Stopped overriding num_vectors field if it is less than the amount of > MSI vectors deduced from interrupt list, > - Added a warning (and an override) if the host specifies more MSI > vectors than available, > - Moved has_split_msi_irq variable to the patch where it is used. You forgot to CC me this version. Please remember to keep reviewers on CC. Johan