From: Niklas Cassel <cassel@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.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>,
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 v2 10/10] PCI: qcom: Implement shutdown() callback to properly reset the endpoint devices
Date: Tue, 2 Apr 2024 13:18:54 +0200 [thread overview]
Message-ID: <ZgvpnqdjQ39JMRiV@ryzen> (raw)
In-Reply-To: <20240401-pci-epf-rework-v2-10-970dbe90b99d@linaro.org>
On Mon, Apr 01, 2024 at 09:20:36PM +0530, Manivannan Sadhasivam wrote:
> PCIe host controller drivers are supposed to properly reset the endpoint
> devices during host shutdown/reboot. Currently, Qcom driver doesn't do
> anything during host shutdown/reboot, resulting in both PERST# and refclk
> getting disabled at the same time. This prevents the endpoint device
> firmware to properly reset the state machine. Because, if the refclk is
> cutoff immediately along with PERST#, access to device specific registers
> within the endpoint will result in a firmware crash.
>
> To address this issue, let's call qcom_pcie_host_deinit() inside the
> shutdown callback, that asserts PERST# and then cuts off the refclk with a
> delay of 1ms, thus allowing the endpoint device firmware to properly
> cleanup the state machine.
Hm... a QCOM EP device could be attached to any of the PCIe RC drivers that
we have in the kernel, so it seems a bit weird to fix this problem by
patching the QCOM RC driver only.
Which DBI call is it that causes this problem during perst assert on EP side?
I assume that it is pci-epf-test:deinit() callback that calls
pci_epc_clear_bar(), which calls dw_pcie_ep_clear_bar(), which will both:
-clear local data structures, e.g.
ep->epf_bar[bar] = NULL;
ep->bar_to_atu[bar] = 0;
but also call:
__dw_pcie_ep_reset_bar()
dw_pcie_disable_atu()
Do we perhaps need to redesign the .deinit EPF callback?
Considering that we know that .deinit() will only be called on platforms
where there will be a fundamental core reset, I guess we could do something
like introduce a __dw_pcie_ep_clear_bar() which will only clear the local
data structures. (It might not need to do any DBI writes, since the
fundamental core reset should have reset all values.)
Or perhaps instead of letting pci_epf_test_epc_deinit() call
pci_epf_test_clear_bar()/__pci_epf_test_clear_bar() directly, perhaps let
pci_epf_test_epc_deinit() call add a .deinit()/.cleanup() defined in the
EPC driver.
This EPC .deinit()/.cleanup() callback would then only clear the
local data structures (no DBI writes...).
Something like that?
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 14772edcf0d3..b2803978c0ad 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1655,6 +1655,13 @@ static int qcom_pcie_resume_noirq(struct device *dev)
> return 0;
> }
>
> +static void qcom_pcie_shutdown(struct platform_device *pdev)
> +{
> + struct qcom_pcie *pcie = platform_get_drvdata(pdev);
> +
> + qcom_pcie_host_deinit(&pcie->pci->pp);
> +}
> +
> static const struct of_device_id qcom_pcie_match[] = {
> { .compatible = "qcom,pcie-apq8064", .data = &cfg_2_1_0 },
> { .compatible = "qcom,pcie-apq8084", .data = &cfg_1_0_0 },
> @@ -1708,5 +1715,6 @@ static struct platform_driver qcom_pcie_driver = {
> .pm = &qcom_pcie_pm_ops,
> .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> },
> + .shutdown = qcom_pcie_shutdown,
> };
> builtin_platform_driver(qcom_pcie_driver);
>
> --
> 2.25.1
>
next prev parent reply other threads:[~2024-04-02 11:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-01 15:50 [PATCH v2 00/10] PCI: endpoint: Make host reboot handling more robust Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 01/10] PCI: qcom-ep: Disable resources unconditionally during PERST# assert Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 02/10] PCI: endpoint: Decouple EPC and PCIe bus specific events Manivannan Sadhasivam
2024-04-02 0:14 ` Damien Le Moal
2024-04-03 14:26 ` Manivannan Sadhasivam
2024-04-04 2:40 ` Damien Le Moal
2024-04-01 15:50 ` [PATCH v2 03/10] PCI: endpoint: Rename core_init() callback in 'struct pci_epc_event_ops' to init() Manivannan Sadhasivam
2024-04-02 10:52 ` Niklas Cassel
2024-04-03 13:46 ` Manivannan Sadhasivam
2024-04-03 15:51 ` Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 04/10] PCI: epf-test: Refactor pci_epf_test_unbind() function Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 05/10] PCI: epf-{mhi/test}: Move DMA initialization to EPC init callback Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 06/10] PCI: endpoint: Introduce EPC 'deinit' event and notify the EPF drivers Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 07/10] PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down event Manivannan Sadhasivam
2024-04-02 10:52 ` Niklas Cassel
2024-04-01 15:50 ` [PATCH v2 08/10] PCI: qcom-ep: Use the " Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 09/10] PCI: epf-test: Handle " Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 10/10] PCI: qcom: Implement shutdown() callback to properly reset the endpoint devices Manivannan Sadhasivam
2024-04-02 11:18 ` Niklas Cassel [this message]
2024-04-03 13:32 ` Manivannan Sadhasivam
2024-04-03 20:03 ` Niklas Cassel
2024-04-09 13:31 ` Bjorn Helgaas
2024-04-10 10:54 ` Manivannan Sadhasivam
2024-04-10 14:52 ` Niklas Cassel
2024-04-10 21:10 ` Niklas Cassel
2024-04-12 6:32 ` Manivannan Sadhasivam
2024-04-02 9:41 ` [PATCH v2 00/10] PCI: endpoint: Make host reboot handling more robust Niklas Cassel
2024-04-03 13:48 ` Manivannan Sadhasivam
2024-04-08 9:49 ` Niklas Cassel
2024-04-02 10:52 ` 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=ZgvpnqdjQ39JMRiV@ryzen \
--to=cassel@kernel.org \
--cc=bhelgaas@google.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=manivannan.sadhasivam@linaro.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).