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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).