From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Niklas Cassel <cassel@kernel.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Jingoo Han" <jingoohan1@gmail.com>,
"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, mhi@lists.linux.dev,
linux-tegra@vger.kernel.org
Subject: Re: [PATCH 01/11] PCI: qcom-ep: Disable resources unconditionally during PERST# assert
Date: Tue, 26 Mar 2024 19:25:14 +0530 [thread overview]
Message-ID: <20240326135514.GB13849@thinkpad> (raw)
In-Reply-To: <ZgLR8jWfBcZB8laa@ryzen>
On Tue, Mar 26, 2024 at 02:47:30PM +0100, Niklas Cassel wrote:
> On Tue, Mar 26, 2024 at 04:40:21PM +0530, Manivannan Sadhasivam wrote:
> >
> > I was planning to drop enable_resources() from Qcom driver once the DBI rework
> > series gets merged. Because, the resource enablement during probe is currently
> > done to avoid the crash that is bound to happen if registers are accessed during
> > probe.
> >
> > But what your observation reveals is that it is possible to get PERST# assert
> > during the EP boot up itself which I was not accounting for. I always assumed
> > that the EP will receive PERST# deassert first. If that is not the case, then
> > this patch needs to be dropped.
>
> From what I saw when having debug prints from my old email to you:
> https://lore.kernel.org/linux-pci/Zalu%2F%2FdNi5BhZlBU@x1-carbon/
>
>
> ## RC side:
> # reboot
>
> ## EP side
> [ 845.606810] pci: PERST asserted by host!
> [ 852.483985] pci: PERST de-asserted by host!
> [ 852.503041] pci: PERST asserted by host!
> [ 852.522375] pci: link up! (LTSSM_STATUS: 0x230011)
> [ 852.610318] pci: PERST de-asserted by host!
>
>
>
> So in my case, I assume that the RC asserts PERST during a SoC reset.
>
> This is obviously from the RC driver asserting PERST + sleep 100 ms +
> PERST deassert:
> [ 852.503041] pci: PERST asserted by host!
> [ 852.610318] pci: PERST de-asserted by host!
>
> The two before that:
> [ 852.483985] pci: PERST de-asserted by host!
> [ 852.503041] pci: PERST asserted by host!
>
> appears to be because the RC I am using, incorrectly sets the PERST gpio as
> ACTIVE HIGH:
> https://github.com/torvalds/linux/blob/v6.9-rc1/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts#L300
>
> Well, at least they are bug compatible and sets the output to:
> https://github.com/torvalds/linux/blob/v6.9-rc1/drivers/pci/controller/dwc/pcie-dw-rockchip.c#L170-L184
>
> 0 and the 1, which, since the DT binding is incorrect, will actually
> do the right thing and assert and the deassert PERST.
>
> The problem seems to be that the initial flags:
> https://github.com/torvalds/linux/blob/v6.9-rc1/drivers/pci/controller/dwc/pcie-dw-rockchip.c#L242-L243
> is: GPIOD_OUT_HIGH
>
> which explains why I get the extra:
> [ 852.483985] pci: PERST de-asserted by host!
> before
> [ 852.503041] pci: PERST asserted by host!
>
> with basically no time between them..
>
>
> I guess I should send a patch to set the initial value to
> GPIOD_OUT_LOW, so that the RC driver does not trigger a
> "spurious" PERST deassertion when requesting the IRQ.
>
>
> So I think this patch should be fine if the RC is not buggy,
> but as we can see, in reality there are at least one platform
> in mainline that does manage to get this wrong.
>
I've validated with x86 and Qcom RCs so far and didn't see this behavior. So I
guess I'll just keep the patch for now.
- Mani
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-03-26 13:55 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 15:23 [PATCH 00/11] PCI: endpoint: Make host reboot handling more robust Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 01/11] PCI: qcom-ep: Disable resources unconditionally during PERST# assert Manivannan Sadhasivam
2024-03-22 16:08 ` Niklas Cassel
2024-03-26 7:44 ` Manivannan Sadhasivam
2024-03-26 10:24 ` Niklas Cassel
2024-03-26 11:10 ` Manivannan Sadhasivam
2024-03-26 13:47 ` Niklas Cassel
2024-03-26 13:55 ` Manivannan Sadhasivam [this message]
2024-03-26 10:37 ` Niklas Cassel
2024-03-14 15:23 ` [PATCH 02/11] PCI: endpoint: Decouple EPC and PCIe bus specific events Manivannan Sadhasivam
2024-03-22 16:08 ` Niklas Cassel
2024-03-26 7:49 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 03/11] PCI: endpoint: Rename core_init() callback in 'struct pci_epc_event_ops' to init() Manivannan Sadhasivam
2024-03-22 16:08 ` Niklas Cassel
2024-03-26 7:56 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 04/11] PCI: epf-test: Refactor pci_epf_test_unbind() function Manivannan Sadhasivam
2024-03-22 16:09 ` Niklas Cassel
2024-03-26 7:58 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 05/11] PCI: epf-{mhi/test}: Move DMA initialization to EPC init callback Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-26 8:26 ` Manivannan Sadhasivam
2024-03-26 11:05 ` Niklas Cassel
2024-03-26 14:27 ` Niklas Cassel
2024-03-27 6:20 ` Manivannan Sadhasivam
2024-03-27 6:18 ` Manivannan Sadhasivam
2024-03-27 11:39 ` Niklas Cassel
2024-03-28 18:42 ` Vinod Koul
2024-04-04 8:44 ` Niklas Cassel
2024-04-22 7:55 ` Manivannan Sadhasivam
2024-04-22 9:30 ` Niklas Cassel
2024-03-14 15:23 ` [PATCH 06/11] PCI: endpoint: Introduce EPC 'deinit' event and notify the EPF drivers Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-26 8:31 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 07/11] PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down event Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-27 18:06 ` Niklas Cassel
2024-04-01 16:34 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 08/11] PCI: qcom-ep: Use the " Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 09/11] PCI: epf-test: Handle " Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-14 15:23 ` [PATCH 10/11] PCI: qcom-ep: Rework {start/stop}_link() callbacks implementation Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-26 8:33 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 11/11] PCI: tegra194: " Manivannan Sadhasivam
2024-03-22 16:11 ` Niklas Cassel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240326135514.GB13849@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kishon@kernel.org \
--cc=kw@linux.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mhi@lists.linux.dev \
--cc=robh@kernel.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.