From: "Pali Rohár" <pali@kernel.org>
To: Jianjun Wang <jianjun.wang@mediatek.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Rob Herring <robh+dt@kernel.org>,
maz@kernel.org, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Ryder Lee <ryder.lee@mediatek.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-pci@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Sj Huang <sj.huang@mediatek.com>,
youlin.pei@mediatek.com, chuanjia.liu@mediatek.com,
qizhong.cheng@mediatek.com, sin_jieyang@mediatek.com,
drinkcat@chromium.org, Rex-BC.Chen@mediatek.com,
anson.chuang@mediatek.com
Subject: Re: [v8,3/7] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192
Date: Thu, 18 Mar 2021 01:02:11 +0100 [thread overview]
Message-ID: <20210318000211.ykjsfavfc7suu2sb@pali> (raw)
In-Reply-To: <1615621394.25662.70.camel@mhfsdcap03>
On Saturday 13 March 2021 15:43:14 Jianjun Wang wrote:
> On Thu, 2021-03-11 at 13:38 +0100, Pali Rohár wrote:
> > On Wednesday 24 February 2021 14:11:28 Jianjun Wang wrote:
> > > +static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
> > > +{
> > ...
> > > +
> > > + /* Delay 100ms to wait the reference clocks become stable */
> > > + msleep(100);
> > > +
> > > + /* De-assert PERST# signal */
> > > + val &= ~PCIE_PE_RSTB;
> > > + writel_relaxed(val, port->base + PCIE_RST_CTRL_REG);
> >
> > Hello! This is a new driver which introduce yet another custom timeout
> > prior PERST# signal for PCIe card is de-asserted. Timeouts for other
> > drivers I collected in older email [2].
> >
> > Please look at my email [1] about PCIe Warm Reset if you have any clue
> > about it. Lorenzo and Rob already expressed that this timeout should not
> > be driver specific. But nobody was able to "decode" and "understand"
> > PCIe spec yet about these timeouts.
>
> Hi Pali,
>
> I think this is more like a platform specific timeout, which is used to
> wait for the reference clocks to become stable and finish the reset flow
> of HW blocks.
>
> Here is the steps to start a link training in this HW:
>
> 1. Assert all reset signals which including the transaction layer, PIPE
> interface and internal bus interface;
>
> 2. De-assert reset signals except the PERST#, this will make the
> physical layer active and start to output the reference clock, but the
> EP device remains in the reset state.
> Before releasing the PERST# signal, the HW blocks needs at least 10ms
> to finish the reset flow, and ref-clk needs about 30us to become stable.
>
> 3. De-assert PERST# signal, wait LTSSM enter L0 state.
>
> This 100ms timeout is reference to TPVPERL in the PCIe CEM spec. Since
> we are in the kernel stage, the power supply has already stabled, this
> timeout may not take that long.
I think that this is not platform specific timeout or platform specific
steps. This matches generic steps as defined in PCIe CEM spec, section
2.2.1. Initial Power-Up (G3 to S0).
What is platform specific is just how to achieve these steps.
Am I right?
...
TPVPERL is one of my timeout candidates as minimal required timeout for
Warm Reset. I have wrote it in email:
https://lore.kernel.org/linux-pci/20200430082245.xblvb7xeamm4e336@pali/
But I'm not sure as specially in none diagram is described just warm
reset as defined in mPCIe CEM (3.2.4.3. PERST# Signal).
...
Anyway, I would suggest to define constants for those timeouts. I guess
that in future we could be able to define "generic" timeout constants
which would not be in private driver section, but in some common header
file.
> > > +
> > > + /* Check if the link is up or not */
> > > + err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_REG, val,
> > > + !!(val & PCIE_PORT_LINKUP), 20,
> > > + 50 * USEC_PER_MSEC);
> >
> > IIRC, you need to wait at least 100ms after de-asserting PERST# signal
> > as it is required by PCIe specs and also because experiments proved that
> > some Compex wifi cards (e.g. WLE900VX) are not detected if you do not
> > wait this minimal time.
>
> Yes, this should be 100ms, I will fix it at next version, thanks for
> your review.
In past Bjorn suggested to use msleep(PCI_PM_D3COLD_WAIT); macro for
this step during reviewing aardvark driver.
https://lore.kernel.org/linux-pci/20190426161050.GA189964@google.com/
And next iteration used this PCI_PM_D3COLD_WAIT macro instead of 100:
https://lore.kernel.org/linux-pci/20190522213351.21366-2-repk@triplefau.lt/
> Thanks.
> >
> > > + if (err) {
> > > + val = readl_relaxed(port->base + PCIE_LTSSM_STATUS_REG);
> > > + dev_err(port->dev, "PCIe link down, ltssm reg val: %#x\n", val);
> > > + return err;
> > > + }
> >
> > [1] - https://lore.kernel.org/linux-pci/20210310110535.zh4pnn4vpmvzwl5q@pali/
> > [2] - https://lore.kernel.org/linux-pci/20200424092546.25p3hdtkehohe3xw@pali/
>
next prev parent reply other threads:[~2021-03-18 0:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 6:11 [v8,0/7] PCI: mediatek: Add new generation controller support Jianjun Wang
2021-02-24 6:11 ` [v8,1/7] dt-bindings: PCI: mediatek-gen3: Add YAML schema Jianjun Wang
2021-03-06 20:09 ` Rob Herring
2021-02-24 6:11 ` [v8,2/7] PCI: Export pci_pio_to_address() for module use Jianjun Wang
2021-02-24 6:11 ` [v8,3/7] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192 Jianjun Wang
2021-02-24 13:36 ` Krzysztof Wilczyński
2021-02-25 3:07 ` Jianjun Wang
2021-03-11 12:38 ` Pali Rohár
2021-03-13 7:43 ` Jianjun Wang
2021-03-18 0:02 ` Pali Rohár [this message]
2021-03-18 5:48 ` Jianjun Wang
2021-03-19 18:53 ` Pali Rohár
2021-03-23 1:31 ` Jianjun Wang
2021-03-23 14:51 ` Pali Rohár
2021-03-29 22:58 ` Pali Rohár
2021-02-24 6:11 ` [v8,4/7] PCI: mediatek-gen3: Add INTx support Jianjun Wang
2021-02-24 14:24 ` Krzysztof Wilczyński
2021-02-25 3:10 ` Jianjun Wang
2021-03-09 11:10 ` Marc Zyngier
2021-03-10 3:05 ` Jianjun Wang
2021-02-24 6:11 ` [v8,5/7] PCI: mediatek-gen3: Add MSI support Jianjun Wang
2021-02-24 14:31 ` Krzysztof Wilczyński
2021-02-25 3:09 ` Jianjun Wang
2021-03-09 11:23 ` Marc Zyngier
2021-03-10 6:48 ` Jianjun Wang
[not found] ` <87a6rbxs4w.wl-maz@kernel.org>
2021-03-11 9:47 ` Jianjun Wang
2021-03-11 0:05 ` Pali Rohár
2021-03-11 8:19 ` Marc Zyngier
2021-03-11 9:50 ` Jianjun Wang
2021-02-24 6:11 ` [v8,6/7] PCI: mediatek-gen3: Add system PM support Jianjun Wang
2021-02-24 14:10 ` Krzysztof Wilczyński
2021-02-25 3:34 ` Jianjun Wang
2021-02-25 22:00 ` Krzysztof Wilczyński
2021-02-26 10:06 ` Jianjun Wang
2021-02-24 6:11 ` [v8,7/7] MAINTAINERS: Add Jianjun Wang as MediaTek PCI co-maintainer Jianjun Wang
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=20210318000211.ykjsfavfc7suu2sb@pali \
--to=pali@kernel.org \
--cc=Rex-BC.Chen@mediatek.com \
--cc=anson.chuang@mediatek.com \
--cc=bhelgaas@google.com \
--cc=chuanjia.liu@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=drinkcat@chromium.org \
--cc=jianjun.wang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=maz@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=qizhong.cheng@mediatek.com \
--cc=robh+dt@kernel.org \
--cc=ryder.lee@mediatek.com \
--cc=sin_jieyang@mediatek.com \
--cc=sj.huang@mediatek.com \
--cc=youlin.pei@mediatek.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 NNTP newsgroup(s).