From: Bjorn Helgaas <helgaas@kernel.org>
To: Jianjun Wang <jianjun.wang@mediatek.com>
Cc: "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Ryder Lee" <ryder.lee@mediatek.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
linux-pci@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, qizhong.cheng@mediatek.com,
Ryan-JH.Yu@mediatek.com, "Tzung-Bi Shih" <tzungbi@google.com>
Subject: Re: [PATCH v2] PCI: mediatek-gen3: Disable DVFSRC voltage request
Date: Wed, 13 Oct 2021 14:02:26 -0500 [thread overview]
Message-ID: <20211013190226.GA1910352@bhelgaas> (raw)
In-Reply-To: <20211013183515.GA1907868@bhelgaas>
On Wed, Oct 13, 2021 at 01:35:17PM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 13, 2021 at 03:53:28PM +0800, Jianjun Wang wrote:
> > When the DVFSRC feature is not implemented, the MAC layer will
> > assert a voltage request signal when exit from the L1ss state,
> > but cannot receive the voltage ready signal, which will cause
> > the link to fail to exit the L1ss state correctly.
> >
> > Disable DVFSRC voltage request by default, we need to find
> > a common way to enable it in the future.
>
> Rewrap commit log to fill 75 columns.
>
> Does "L1ss" above refer to L1.1 and L1.2? If so, please say that
> explicitly or say something like "L1 PM Substates" (the term used in
> the PCIe spec) so it's clear.
>
> This seems on the boundary of PCIe-specified things and Mediatek
> implementation details, so I'm not sure what "DVFSRC," "MAC," and
> "voltage request signal" mean. Since I don't recognize those terms,
> I'm guessing they are Mediatek-specific things.
>
> But if they are things specified by the PCIe spec, please use the
> exact names used in the spec.
>
> > Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
> > Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
> > Tested-by: Qizhong Cheng <qizhong.cheng@mediatek.com>
Krzysztof also pointed out that if this is a bug fix, we may want a
stable tag here. And, ideally, a Fixes: tag with the specific commit
that introduced the bug.
> > ---
> > drivers/pci/controller/pcie-mediatek-gen3.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> > index f3aeb8d4eaca..79fb12fca6a9 100644
> > --- a/drivers/pci/controller/pcie-mediatek-gen3.c
> > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> > @@ -79,6 +79,9 @@
> > #define PCIE_ICMD_PM_REG 0x198
> > #define PCIE_TURN_OFF_LINK BIT(4)
> >
> > +#define PCIE_MISC_CTRL_REG 0x348
> > +#define PCIE_DISABLE_DVFSRC_VLT_REQ BIT(1)
> > +
> > #define PCIE_TRANS_TABLE_BASE_REG 0x800
> > #define PCIE_ATR_SRC_ADDR_MSB_OFFSET 0x4
> > #define PCIE_ATR_TRSL_ADDR_LSB_OFFSET 0x8
> > @@ -297,6 +300,11 @@ static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
> > val &= ~PCIE_INTX_ENABLE;
> > writel_relaxed(val, port->base + PCIE_INT_ENABLE_REG);
> >
> > + /* Disable DVFSRC voltage request */
> > + val = readl_relaxed(port->base + PCIE_MISC_CTRL_REG);
> > + val |= PCIE_DISABLE_DVFSRC_VLT_REQ;
> > + writel_relaxed(val, port->base + PCIE_MISC_CTRL_REG);
> > +
> > /* Assert all reset signals */
> > val = readl_relaxed(port->base + PCIE_RST_CTRL_REG);
> > val |= PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB;
> > --
> > 2.25.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-10-13 19:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 7:53 [PATCH v2] PCI: mediatek-gen3: Disable DVFSRC voltage request Jianjun Wang
2021-10-13 18:35 ` Bjorn Helgaas
2021-10-13 19:02 ` Bjorn Helgaas [this message]
2021-10-14 7:31 ` 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=20211013190226.GA1910352@bhelgaas \
--to=helgaas@kernel.org \
--cc=Ryan-JH.Yu@mediatek.com \
--cc=bhelgaas@google.com \
--cc=jianjun.wang@mediatek.com \
--cc=kw@linux.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=qizhong.cheng@mediatek.com \
--cc=robh+dt@kernel.org \
--cc=ryder.lee@mediatek.com \
--cc=tzungbi@google.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