On Thu, Sep 26, 2024 at 11:15:34AM +0800, Qiang Yu wrote: > > On 9/25/2024 8:52 PM, Manivannan Sadhasivam wrote: > > On Wed, Sep 25, 2024 at 11:46:35AM +0200, Konrad Dybcio wrote: > > > On 25.09.2024 11:30 AM, Konrad Dybcio wrote: > > > > On 25.09.2024 10:05 AM, Manivannan Sadhasivam wrote: > > > > > On Tue, Sep 24, 2024 at 04:26:34PM +0200, Konrad Dybcio wrote: > > > > > > On 24.09.2024 12:14 PM, Qiang Yu wrote: > > > > > > > Describe PCIe3 controller and PHY. Also add required system resources like > > > > > > > regulators, clocks, interrupts and registers configuration for PCIe3. > > > > > > > > > > > > > > Signed-off-by: Qiang Yu <quic_qianyu@xxxxxxxxxxx> > > > > > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > > > > > > > --- > > > > > > Qiang, Mani > > > > > > > > > > > > I have a RTS5261 mmc chip on PCIe3 on the Surface Laptop. > > > > > Is it based on x1e80100? > > > > You would think so :P > > > > > > > > > > Adding the global irq breaks sdcard detection (the chip still comes > > > > > > up fine) somehow. Removing the irq makes it work again :| > > > > > > > > > > > > I've confirmed that the irq number is correct > > > > > > > > > > > Yeah, I did see some issues with MSI on SM8250 (RB5) when global interrupts are > > > > > enabled and I'm working with the hw folks to understand what is going on. But > > > > > I didn't see the same issues on newer platforms (sa8775p etc...). > > > > > > > > > > Can you please confirm if the issue is due to MSI not being received from the > > > > > device? Checking the /proc/interrutps is enough. > > > > There's no msi-map for PCIe3. I recall +Johan talking about some sort of > > > > a bug that prevents us from adding it? > > Yeah, that's for using GIC-ITS to receive MSIs. But the default one is the > > internal MSI controller in DWC. > > > > > Unless you just meant the msi0..=7 interrupts, then yeah, I only get one irq > > > event with "global" in place and it seems to never get more > > > > > Ok. Then most likely the same issue I saw on SM8250 as well. But I'm confused > > why Qiang didn't see the issue. I specifically asked him to add the global > > interrupt and test it with the endpoint to check if the issue arises or not. > > > > Qiang, can you please confirm? > Sorry, I misunderstood what you mean. I only verified if link was up but > ignored the status of ep device > driver. > > But look like this issue is because snpsys MSI irq is msked during probe. > Can you please also unmask BIT(23) - BIT(30) when unmask > PARF_INT_ALL_LINK_UP, > like this > > @@ -1772,7 +1772,8 @@ static int qcom_pcie_probe(struct platform_device > *pdev) > goto err_host_deinit; > } > > - writel_relaxed(PARF_INT_ALL_LINK_UP, pcie->parf + > PARF_INT_ALL_MASK); > + writel_relaxed(PARF_INT_ALL_LINK_UP | GENMASK(30, 23), > pcie->parf + PARF_INT_ALL_MASK); > + dev_err(dev, "INT_ALL_MASK: 0x%x\n", > readl_relaxed(pcie->parf + PARF_INT_ALL_MASK)); > } > > After that, this issue is fixed on my setup. > I did see those bits, but they were mentioned as diagnostic interrupts. So I was not sure why disabling them masks MSI. Furthermore, MSI seems to work on SM8450 without enabling these bits. Anyway, since you mentioned that it helps in bringing back MSI on this platform, it doesn't hurt to enable these interrupts. I will post a patch for that, thanks! - Mani -- மணிவண்ணன் சதாசிவம்
