From: Manivannan Sadhasivam <mani@kernel.org>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Frank Li <Frank.li@nxp.com>,
manivannan.sadhasivam@linaro.org, helgaas@kernel.org,
bhelgaas@google.com, devicetree@vger.kernel.org,
gustavo.pimentel@synopsys.com, imx@lists.linux.dev, kw@linux.com,
leoyang.li@nxp.com, linux-arm-kernel@lists.infradead.org,
linux-imx@nxp.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, lorenzo.pieralisi@arm.com,
minghuan.lian@nxp.com, mingkai.hu@nxp.com, robh+dt@kernel.org,
roy.zang@nxp.com, shawnguo@kernel.org, zhiqiang.hou@nxp.com
Subject: Re: [PATCH v11 3/3] PCI: layerscape: Add power management support for ls1028a
Date: Mon, 21 Aug 2023 16:03:57 +0530 [thread overview]
Message-ID: <20230821103357.GA36455@thinkpad> (raw)
In-Reply-To: <ZOMecaueyN3cutUH@lpieralisi>
On Mon, Aug 21, 2023 at 10:21:05AM +0200, Lorenzo Pieralisi wrote:
> On Thu, Aug 17, 2023 at 06:42:50PM -0400, Frank Li wrote:
> > On Wed, Aug 16, 2023 at 05:30:10PM +0200, Lorenzo Pieralisi wrote:
> > > On Wed, Aug 09, 2023 at 11:35:40AM -0400, Frank Li wrote:
> > > > From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> > > >
> > > > Add PME_Turn_off/PME_TO_Ack handshake sequence for ls1028a platform. Call
> > > > common dwc dw_pcie_suspend(resume)_noirq() function when system enter/exit
> > > > suspend state.
> > > >
> > > > Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> > > > Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > ---
> > > > drivers/pci/controller/dwc/pci-layerscape.c | 130 ++++++++++++++++++--
> > > > 1 file changed, 121 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> > > > index ed5fb492fe084..b49f654335fd7 100644
> > > > --- a/drivers/pci/controller/dwc/pci-layerscape.c
> > > > +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> > > > @@ -8,9 +8,11 @@
> > > > * Author: Minghuan Lian <Minghuan.Lian@freescale.com>
> > > > */
> > > >
> > > > +#include <linux/delay.h>
> > > > #include <linux/kernel.h>
> > > > #include <linux/interrupt.h>
> > > > #include <linux/init.h>
> > > > +#include <linux/iopoll.h>
> > > > #include <linux/of_pci.h>
> > > > #include <linux/of_platform.h>
> > > > #include <linux/of_address.h>
> > > > @@ -20,6 +22,7 @@
> > > > #include <linux/mfd/syscon.h>
> > > > #include <linux/regmap.h>
> > > >
> > > > +#include "../../pci.h"
> > > > #include "pcie-designware.h"
> > > >
> > > > /* PEX Internal Configuration Registers */
> > > > @@ -27,12 +30,26 @@
> > > > #define PCIE_ABSERR 0x8d0 /* Bridge Slave Error Response Register */
> > > > #define PCIE_ABSERR_SETTING 0x9401 /* Forward error of non-posted request */
> > > >
> > > > +/* PF Message Command Register */
> > > > +#define LS_PCIE_PF_MCR 0x2c
> > > > +#define PF_MCR_PTOMR BIT(0)
> > > > +#define PF_MCR_EXL2S BIT(1)
> > > > +
> > > > #define PCIE_IATU_NUM 6
> > > >
> > > > +struct ls_pcie_drvdata {
> > > > + const u32 pf_off;
> > > > + bool pm_support;
> > > > +};
> > > > +
> > > > struct ls_pcie {
> > > > struct dw_pcie *pci;
> > > > + const struct ls_pcie_drvdata *drvdata;
> > > > + void __iomem *pf_base;
> > > > + bool big_endian;
> > > > };
> > > >
> > > > +#define ls_pcie_pf_readl_addr(addr) ls_pcie_pf_readl(pcie, addr)
> > > > #define to_ls_pcie(x) dev_get_drvdata((x)->dev)
> > > >
> > > > static bool ls_pcie_is_bridge(struct ls_pcie *pcie)
> > > > @@ -73,6 +90,60 @@ static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
> > > > iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR);
> > > > }
> > > >
> > > > +static u32 ls_pcie_pf_readl(struct ls_pcie *pcie, u32 off)
> > > > +{
> > > > + if (pcie->big_endian)
> > > > + return ioread32be(pcie->pf_base + off);
> > > > +
> > > > + return ioread32(pcie->pf_base + off);
> > > > +}
> > > > +
> > > > +static void ls_pcie_pf_writel(struct ls_pcie *pcie, u32 off, u32 val)
> > > > +{
> > > > + if (pcie->big_endian)
> > > > + iowrite32be(val, pcie->pf_base + off);
> > > > + else
> > > > + iowrite32(val, pcie->pf_base + off);
> > > > +}
> > > > +
> > > > +static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
> > > > +{
> > > > + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > > > + struct ls_pcie *pcie = to_ls_pcie(pci);
> > > > + u32 val;
> > > > + int ret;
> > > > +
> > > > + val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
> > > > + val |= PF_MCR_PTOMR;
> > > > + ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
> > > > +
> > > > + ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
> > > > + val, !(val & PF_MCR_PTOMR),
> > > > + PCIE_PME_TO_L2_TIMEOUT_US/10,
> > > > + PCIE_PME_TO_L2_TIMEOUT_US);
> > > > + if (ret)
> > > > + dev_err(pcie->pci->dev, "PME_Turn_off timeout\n");
> > > > +}
> > > > +
> > > > +static void ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
> > > > +{
> > > > + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > > > + struct ls_pcie *pcie = to_ls_pcie(pci);
> > > > + u32 val;
> > > > + int ret;
> > > > +
> > > > + val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
> > > > + val |= PF_MCR_EXL2S;
> > > > + ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
> > >
> > > What is this write transaction generating in HW ?
> >
> > I don't think send anything to to pci bus because it was called before
> > host init.
> >
> > The spec of ls1028 is not clear enough.
> >
> > `EXL2S: exit l2 state command. when set to 1, an L2 exit command is
> > generated. The bit is self clearing. Once the bit is set. SW needs to wait
> > for the bit to selfclear before sending a new command'
> >
> > >
> > > Why is it needed ? Shouldn't L2 exit happen automatically
> > > in HW ?
> >
> > I tried remove this, PCI can't resume. I think this is specific for ls1028
> > chip to clear internal logic.
>
> Well, if you don't even know what this does how can you write a sane
> device driver ?
>
> Can you ask designers a more detailed description please ?
>
I often encounter hw quirks like this one and the hw designers will just say
that "set bit X to make Y happpen". IMO a comment saying that the driver need to
set PF_MCR_EXL2S bit in LS_PCIE_PF_MCR register for the link to exit L2 state is
good enough.
> > > > +
> > > > + ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
> > > > + val, !(val & PF_MCR_EXL2S),
> > > > + PCIE_PME_TO_L2_TIMEOUT_US/10,
> > > > + PCIE_PME_TO_L2_TIMEOUT_US);
> > >
> > > And why is the timeout value the same used for the PME_turn_off message ?
> >
> > I think No spec define it, just reused it. use PCIE_PME_TO_L2_TIMEOUT_US
> > may cause confuse. What's do you prefered? Just use number,such as 10ms.
>
> This delay value is misleading, it is not good to reuse a value for
> a delay that is most certainly controller specific.
>
> From this discussion I would say that having pme_turn_off() and
> exit_from_l2() hooks is generalizing something we don't know yet
> it is needed for all DWC based controllers.
>
> It is probably worth keeping the layerscape specific changes in
> the layerscape driver and from there call the "generic" DWC
> suspend/resume functions:
>
> dw_pcie_suspend_noirq()
> dw_pcie_resume_noirq()
>
> rather than adding hooks that we barely know what they are needed for.
>
> Mani, what do you think ?
>
PME_Turn_off procedure may vary between controllers and is really required
from core DWC perspective. So I'd prefer to keep the pme_turn_off() callback
and leave exit_from_l2() since later seems to be only required for layerscape.
- Mani
--
மணிவண்ணன் சதாசிவம்
WARNING: multiple messages have this Message-ID (diff)
From: Manivannan Sadhasivam <mani@kernel.org>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Frank Li <Frank.li@nxp.com>,
manivannan.sadhasivam@linaro.org, helgaas@kernel.org,
bhelgaas@google.com, devicetree@vger.kernel.org,
gustavo.pimentel@synopsys.com, imx@lists.linux.dev, kw@linux.com,
leoyang.li@nxp.com, linux-arm-kernel@lists.infradead.org,
linux-imx@nxp.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, lorenzo.pieralisi@arm.com,
minghuan.lian@nxp.com, mingkai.hu@nxp.com, robh+dt@kernel.org,
roy.zang@nxp.com, shawnguo@kernel.org, zhiqiang.hou@nxp.com
Subject: Re: [PATCH v11 3/3] PCI: layerscape: Add power management support for ls1028a
Date: Mon, 21 Aug 2023 16:03:57 +0530 [thread overview]
Message-ID: <20230821103357.GA36455@thinkpad> (raw)
In-Reply-To: <ZOMecaueyN3cutUH@lpieralisi>
On Mon, Aug 21, 2023 at 10:21:05AM +0200, Lorenzo Pieralisi wrote:
> On Thu, Aug 17, 2023 at 06:42:50PM -0400, Frank Li wrote:
> > On Wed, Aug 16, 2023 at 05:30:10PM +0200, Lorenzo Pieralisi wrote:
> > > On Wed, Aug 09, 2023 at 11:35:40AM -0400, Frank Li wrote:
> > > > From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> > > >
> > > > Add PME_Turn_off/PME_TO_Ack handshake sequence for ls1028a platform. Call
> > > > common dwc dw_pcie_suspend(resume)_noirq() function when system enter/exit
> > > > suspend state.
> > > >
> > > > Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> > > > Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > ---
> > > > drivers/pci/controller/dwc/pci-layerscape.c | 130 ++++++++++++++++++--
> > > > 1 file changed, 121 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> > > > index ed5fb492fe084..b49f654335fd7 100644
> > > > --- a/drivers/pci/controller/dwc/pci-layerscape.c
> > > > +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> > > > @@ -8,9 +8,11 @@
> > > > * Author: Minghuan Lian <Minghuan.Lian@freescale.com>
> > > > */
> > > >
> > > > +#include <linux/delay.h>
> > > > #include <linux/kernel.h>
> > > > #include <linux/interrupt.h>
> > > > #include <linux/init.h>
> > > > +#include <linux/iopoll.h>
> > > > #include <linux/of_pci.h>
> > > > #include <linux/of_platform.h>
> > > > #include <linux/of_address.h>
> > > > @@ -20,6 +22,7 @@
> > > > #include <linux/mfd/syscon.h>
> > > > #include <linux/regmap.h>
> > > >
> > > > +#include "../../pci.h"
> > > > #include "pcie-designware.h"
> > > >
> > > > /* PEX Internal Configuration Registers */
> > > > @@ -27,12 +30,26 @@
> > > > #define PCIE_ABSERR 0x8d0 /* Bridge Slave Error Response Register */
> > > > #define PCIE_ABSERR_SETTING 0x9401 /* Forward error of non-posted request */
> > > >
> > > > +/* PF Message Command Register */
> > > > +#define LS_PCIE_PF_MCR 0x2c
> > > > +#define PF_MCR_PTOMR BIT(0)
> > > > +#define PF_MCR_EXL2S BIT(1)
> > > > +
> > > > #define PCIE_IATU_NUM 6
> > > >
> > > > +struct ls_pcie_drvdata {
> > > > + const u32 pf_off;
> > > > + bool pm_support;
> > > > +};
> > > > +
> > > > struct ls_pcie {
> > > > struct dw_pcie *pci;
> > > > + const struct ls_pcie_drvdata *drvdata;
> > > > + void __iomem *pf_base;
> > > > + bool big_endian;
> > > > };
> > > >
> > > > +#define ls_pcie_pf_readl_addr(addr) ls_pcie_pf_readl(pcie, addr)
> > > > #define to_ls_pcie(x) dev_get_drvdata((x)->dev)
> > > >
> > > > static bool ls_pcie_is_bridge(struct ls_pcie *pcie)
> > > > @@ -73,6 +90,60 @@ static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
> > > > iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR);
> > > > }
> > > >
> > > > +static u32 ls_pcie_pf_readl(struct ls_pcie *pcie, u32 off)
> > > > +{
> > > > + if (pcie->big_endian)
> > > > + return ioread32be(pcie->pf_base + off);
> > > > +
> > > > + return ioread32(pcie->pf_base + off);
> > > > +}
> > > > +
> > > > +static void ls_pcie_pf_writel(struct ls_pcie *pcie, u32 off, u32 val)
> > > > +{
> > > > + if (pcie->big_endian)
> > > > + iowrite32be(val, pcie->pf_base + off);
> > > > + else
> > > > + iowrite32(val, pcie->pf_base + off);
> > > > +}
> > > > +
> > > > +static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
> > > > +{
> > > > + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > > > + struct ls_pcie *pcie = to_ls_pcie(pci);
> > > > + u32 val;
> > > > + int ret;
> > > > +
> > > > + val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
> > > > + val |= PF_MCR_PTOMR;
> > > > + ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
> > > > +
> > > > + ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
> > > > + val, !(val & PF_MCR_PTOMR),
> > > > + PCIE_PME_TO_L2_TIMEOUT_US/10,
> > > > + PCIE_PME_TO_L2_TIMEOUT_US);
> > > > + if (ret)
> > > > + dev_err(pcie->pci->dev, "PME_Turn_off timeout\n");
> > > > +}
> > > > +
> > > > +static void ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
> > > > +{
> > > > + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > > > + struct ls_pcie *pcie = to_ls_pcie(pci);
> > > > + u32 val;
> > > > + int ret;
> > > > +
> > > > + val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
> > > > + val |= PF_MCR_EXL2S;
> > > > + ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
> > >
> > > What is this write transaction generating in HW ?
> >
> > I don't think send anything to to pci bus because it was called before
> > host init.
> >
> > The spec of ls1028 is not clear enough.
> >
> > `EXL2S: exit l2 state command. when set to 1, an L2 exit command is
> > generated. The bit is self clearing. Once the bit is set. SW needs to wait
> > for the bit to selfclear before sending a new command'
> >
> > >
> > > Why is it needed ? Shouldn't L2 exit happen automatically
> > > in HW ?
> >
> > I tried remove this, PCI can't resume. I think this is specific for ls1028
> > chip to clear internal logic.
>
> Well, if you don't even know what this does how can you write a sane
> device driver ?
>
> Can you ask designers a more detailed description please ?
>
I often encounter hw quirks like this one and the hw designers will just say
that "set bit X to make Y happpen". IMO a comment saying that the driver need to
set PF_MCR_EXL2S bit in LS_PCIE_PF_MCR register for the link to exit L2 state is
good enough.
> > > > +
> > > > + ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
> > > > + val, !(val & PF_MCR_EXL2S),
> > > > + PCIE_PME_TO_L2_TIMEOUT_US/10,
> > > > + PCIE_PME_TO_L2_TIMEOUT_US);
> > >
> > > And why is the timeout value the same used for the PME_turn_off message ?
> >
> > I think No spec define it, just reused it. use PCIE_PME_TO_L2_TIMEOUT_US
> > may cause confuse. What's do you prefered? Just use number,such as 10ms.
>
> This delay value is misleading, it is not good to reuse a value for
> a delay that is most certainly controller specific.
>
> From this discussion I would say that having pme_turn_off() and
> exit_from_l2() hooks is generalizing something we don't know yet
> it is needed for all DWC based controllers.
>
> It is probably worth keeping the layerscape specific changes in
> the layerscape driver and from there call the "generic" DWC
> suspend/resume functions:
>
> dw_pcie_suspend_noirq()
> dw_pcie_resume_noirq()
>
> rather than adding hooks that we barely know what they are needed for.
>
> Mani, what do you think ?
>
PME_Turn_off procedure may vary between controllers and is really required
from core DWC perspective. So I'd prefer to keep the pme_turn_off() callback
and leave exit_from_l2() since later seems to be only required for layerscape.
- Mani
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
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:[~2023-08-21 10:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 15:35 [PATCH v11 resend 0/3] dwc general suspend/resume functionality Frank Li
2023-08-09 15:35 ` Frank Li
2023-08-09 15:35 ` [PATCH v11 1/3] PCI: Add macro PCIE_PME_TO_L2_TIMEOUT_US Frank Li
2023-08-09 15:35 ` Frank Li
2023-08-16 10:20 ` Lorenzo Pieralisi
2023-08-16 10:20 ` Lorenzo Pieralisi
2023-08-16 11:44 ` Bjorn Helgaas
2023-08-16 11:44 ` Bjorn Helgaas
2023-08-09 15:35 ` [PATCH v11 2/3] PCI: dwc: Implement general suspend/resume functionality for L2/L3 transitions Frank Li
2023-08-09 15:35 ` Frank Li
2023-08-09 15:35 ` [PATCH v11 3/3] PCI: layerscape: Add power management support for ls1028a Frank Li
2023-08-09 15:35 ` Frank Li
2023-08-16 15:30 ` Lorenzo Pieralisi
2023-08-16 15:30 ` Lorenzo Pieralisi
2023-08-17 22:42 ` Frank Li
2023-08-17 22:42 ` Frank Li
2023-08-21 8:21 ` Lorenzo Pieralisi
2023-08-21 8:21 ` Lorenzo Pieralisi
2023-08-21 10:33 ` Manivannan Sadhasivam [this message]
2023-08-21 10:33 ` Manivannan Sadhasivam
2023-08-21 15:23 ` Frank Li
2023-08-21 15:23 ` Frank Li
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=20230821103357.GA36455@thinkpad \
--to=mani@kernel.org \
--cc=Frank.li@nxp.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=gustavo.pimentel@synopsys.com \
--cc=helgaas@kernel.org \
--cc=imx@lists.linux.dev \
--cc=kw@linux.com \
--cc=leoyang.li@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=minghuan.lian@nxp.com \
--cc=mingkai.hu@nxp.com \
--cc=robh+dt@kernel.org \
--cc=roy.zang@nxp.com \
--cc=shawnguo@kernel.org \
--cc=zhiqiang.hou@nxp.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.