From: Bjorn Helgaas <helgaas@kernel.org>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: "Ryder Lee" <ryder.lee@mediatek.com>,
"Jianjun Wang" <jianjun.wang@mediatek.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Christian Marangi" <ansuelsmth@gmail.com>,
linux-pci@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, upstream@airoha.com,
"Hui Ma" <hui.ma@airoha.com>
Subject: Re: [PATCH v2] PCI: mediatek-gen3: Avoid PCIe resetting via PCIE_RSTB for Airoha EN7581 SoC
Date: Tue, 5 Nov 2024 14:57:48 -0600 [thread overview]
Message-ID: <20241105205748.GA1484220@bhelgaas> (raw)
In-Reply-To: <ZypgYOn7dcYIoW4i@lore-desk>
On Tue, Nov 05, 2024 at 07:13:52PM +0100, Lorenzo Bianconi wrote:
> > On Mon, Nov 04, 2024 at 11:00:05PM +0100, Lorenzo Bianconi wrote:
> > > Airoha EN7581 has a hw bug asserting/releasing PCIE_PE_RSTB signal
> > > causing occasional PCIe link down issues. In order to overcome the
> > > problem, PCIE_RSTB signals are not asserted/released during device probe or
> > > suspend/resume phase and the PCIe block is reset using REG_PCI_CONTROL
> > > (0x88) and REG_RESET_CONTROL (0x834) registers available via the clock
> > > module.
> > > Introduce flags field in the mtk_gen3_pcie_pdata struct in order to
> > > specify per-SoC capabilities.
> >
> > Where does this alternate way of doing reset (using REG_PCI_CONTROL
> > and REG_RESET_CONTROL) happen? Why isn't there something in this
> > patch to use that alternate method at the same points where
> > PCIE_PE_RSTB is used?
>
> REG_RESET_CONTROL (0x834) is already asserted/released in the following flow:
>
> mtk_pcie_en7581_power_up() -> reset_control_bulk_deassert() -> en7523_reset_update()
> https://github.com/torvalds/linux/blob/master/drivers/clk/clk-en7523.c#L470
>
> REG_PCI_CONTROL (0x88) is already asserted/released in the following flow:
> mtk_pcie_en7581_power_up() -> clk_bulk_enable() -> en7581_pci_enable()
> https://github.com/torvalds/linux/blob/master/drivers/clk/clk-en7523.c#L385
So IIUC, you're saying that on EN7581, the PCI hierarchy is reset by
the soc->power_up() callback, mtk_pcie_en7581_power_up(), via
REG_PCI_CONTROL and REG_RESET_CONTROL.
I assume the hierarchy is also reset by the non-EN7581 .power_up()
callback, mtk_pcie_power_up()?
And prior to this patch, we reset the hierarchy *again* in
mtk_pcie_startup_port() via PCIE_RST_CTRL_REG, but this causes
occasional "link down" issues because of a EN7581 hardware defect.
So for EN7581, this patch skips the PCIE_RST_CTRL_REG reset in
mtk_pcie_startup_port().
.power_up() and mtk_pcie_startup_port() are used both at probe time
and in mtk_pcie_resume_noirq(). So after this patch, I assume:
- EN7581 resets the hierarchy once at probe and resume instead of
twice.
- Non-EN7581 resets the hierarchy twice at probe and resume.
I assume I'm missing something (maybe mtk_pcie_power_up() doesn't
actually reset the hierarchy?) because I don't see why we would reset
the hierarchy twice for either controller.
Bjorn
next prev parent reply other threads:[~2024-11-05 20:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 22:00 [PATCH v2] PCI: mediatek-gen3: Avoid PCIe resetting via PCIE_RSTB for Airoha EN7581 SoC Lorenzo Bianconi
2024-11-05 9:23 ` Jianjun Wang (王建军)
2024-11-05 9:30 ` lorenzo
2024-11-06 8:25 ` Jianjun Wang (王建军)
2024-11-06 9:00 ` lorenzo
2024-11-05 17:22 ` Bjorn Helgaas
2024-11-05 18:13 ` Lorenzo Bianconi
2024-11-05 20:57 ` Bjorn Helgaas [this message]
2024-11-06 1:18 ` Jianjun Wang (王建军)
2024-11-06 9:18 ` Lorenzo Bianconi
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=20241105205748.GA1484220@bhelgaas \
--to=helgaas@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=ansuelsmth@gmail.com \
--cc=bhelgaas@google.com \
--cc=hui.ma@airoha.com \
--cc=jianjun.wang@mediatek.com \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
--cc=ryder.lee@mediatek.com \
--cc=upstream@airoha.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.