All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jianjun Wang <jianjun.wang@mediatek.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: youlin.pei@mediatek.com, devicetree@vger.kernel.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	qizhong.cheng@mediatek.com, chuanjia.liu@mediatek.com,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	linux-pci@vger.kernel.org, Ryder Lee <ryder.lee@mediatek.com>,
	linux-kernel@vger.kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Sj Huang <sj.huang@mediatek.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	sin_jieyang@mediatek.com, davem@davemloft.net,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [v3,2/3] PCI: mediatek: Add new generation controller support
Date: Tue, 3 Nov 2020 13:44:02 +0800	[thread overview]
Message-ID: <1604382242.2521.62.camel@mhfsdcap03> (raw)
In-Reply-To: <aaccd827fa6de117d27319884f2d70a2ea91aa5e.camel@pengutronix.de>

On Mon, 2020-09-28 at 10:32 +0200, Philipp Zabel wrote:
> Hi Jianjun,
> 
> On Sun, 2020-09-27 at 15:45 +0800, Jianjun Wang wrote:
> > MediaTek's PCIe host controller has three generation HWs, the new
> > generation HW is an individual bridge, it supoorts Gen3 speed and
> > up to 256 MSI interrupt numbers for multi-function devices.
> > 
> > Add support for new Gen3 controller which can be found on MT8192.
> > 
> > Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
> > Acked-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> >  drivers/pci/controller/Kconfig              |   14 +
> >  drivers/pci/controller/Makefile             |    1 +
> >  drivers/pci/controller/pcie-mediatek-gen3.c | 1024 +++++++++++++++++++
> >  3 files changed, 1039 insertions(+)
> >  create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c
> > 
> [...]
> > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> > new file mode 100644
> > index 000000000000..ad69c789b24d
> > --- /dev/null
> > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> > @@ -0,0 +1,1024 @@
> [...]
> > +static int mtk_pcie_power_up(struct mtk_pcie_port *port)
> > +{
> > +	struct device *dev = port->dev;
> > +	int err;
> > +
> > +	port->phy_reset = devm_reset_control_get_optional_exclusive(dev,
> > +								    "phy-rst");
> > +	if (IS_ERR(port->phy_reset))
> > +		return PTR_ERR(port->phy_reset);
> > +
> > +	reset_control_deassert(port->phy_reset);
> 
> In general, it is better to request all required resources before
> starting to activate the hardware.
> 
> > +
> > +	/* PHY power on and enable pipe clock */
> > +	port->phy = devm_phy_optional_get(dev, "pcie-phy");
> > +	if (IS_ERR(port->phy))
> > +		return PTR_ERR(port->phy);
> 
> For example, if the PHY driver is not loaded yet and this returns
> -EPROBE_DEFER, it was not useful to take the PHY out of reset above.
> Also, phy-rst is kept deasserted if this fails.
> 
> > +
> > +	err = phy_init(port->phy);
> > +	if (err) {
> > +		dev_notice(dev, "failed to initialize pcie phy\n");
> > +		return err;
> 
> phy-rst is kept deasserted if this fails.
> 
> > +	}
> > +
> > +	err = phy_power_on(port->phy);
> > +	if (err) {
> > +		dev_notice(dev, "failed to power on pcie phy\n");
> > +		goto err_phy_on;
> > +	}
> > +
> > +	port->mac_reset = devm_reset_control_get_optional_exclusive(dev,
> > +								    "mac-rst");
> > +	if (IS_ERR(port->mac_reset))
> > +		return PTR_ERR(port->mac_reset);
> 
> The PHY is not powered down if this fails.
> 
> > +
> > +	reset_control_deassert(port->mac_reset);
> > +
> > +	/* MAC power on and enable transaction layer clocks */
> > +	pm_runtime_enable(dev);
> > +	pm_runtime_get_sync(dev);
> > +
> > +	err = mtk_pcie_clk_init(port);
> > +	if (err) {
> > +		dev_notice(dev, "clock init failed\n");
> > +		goto err_clk_init;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_clk_init:
> > +	pm_runtime_put_sync(dev);
> > +	pm_runtime_disable(dev);
> > +	reset_control_assert(port->mac_reset);
> > +	phy_power_off(port->phy);
> > +err_phy_on:
> > +	phy_exit(port->phy);
> > +	reset_control_assert(port->phy_reset);
> > +
> > +	return -EBUSY;
> > +}
> > +
> > +static void mtk_pcie_power_down(struct mtk_pcie_port *port)
> > +{
> > +	phy_power_off(port->phy);
> > +	phy_exit(port->phy);
> > +
> > +	clk_bulk_disable_unprepare(port->num_clks, port->clks);
> 
> In the power-up sequence clocks are enabled last, but here they are not
> disabled before the PHY is powered off. Is this on purpose?
> 
> > +
> > +	pm_runtime_put_sync(port->dev);
> > +	pm_runtime_disable(port->dev);
> 
> In the power-up error path, PHY and controller resets are asserted
> again, but here they are kept deasserted. Should they be asserted here
> as well?
> 
> regards
> Philipp

Hi Philipp,

Sorry for the late responding and thanks for your review, I will fix it
in the next version.

Thanks.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Jianjun Wang <jianjun.wang@mediatek.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Ryder Lee <ryder.lee@mediatek.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	"Mauro Carvalho Chehab" <mchehab+huawei@kernel.org>,
	<davem@davemloft.net>, <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>
Subject: Re: [v3,2/3] PCI: mediatek: Add new generation controller support
Date: Tue, 3 Nov 2020 13:44:02 +0800	[thread overview]
Message-ID: <1604382242.2521.62.camel@mhfsdcap03> (raw)
In-Reply-To: <aaccd827fa6de117d27319884f2d70a2ea91aa5e.camel@pengutronix.de>

On Mon, 2020-09-28 at 10:32 +0200, Philipp Zabel wrote:
> Hi Jianjun,
> 
> On Sun, 2020-09-27 at 15:45 +0800, Jianjun Wang wrote:
> > MediaTek's PCIe host controller has three generation HWs, the new
> > generation HW is an individual bridge, it supoorts Gen3 speed and
> > up to 256 MSI interrupt numbers for multi-function devices.
> > 
> > Add support for new Gen3 controller which can be found on MT8192.
> > 
> > Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
> > Acked-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> >  drivers/pci/controller/Kconfig              |   14 +
> >  drivers/pci/controller/Makefile             |    1 +
> >  drivers/pci/controller/pcie-mediatek-gen3.c | 1024 +++++++++++++++++++
> >  3 files changed, 1039 insertions(+)
> >  create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c
> > 
> [...]
> > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> > new file mode 100644
> > index 000000000000..ad69c789b24d
> > --- /dev/null
> > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> > @@ -0,0 +1,1024 @@
> [...]
> > +static int mtk_pcie_power_up(struct mtk_pcie_port *port)
> > +{
> > +	struct device *dev = port->dev;
> > +	int err;
> > +
> > +	port->phy_reset = devm_reset_control_get_optional_exclusive(dev,
> > +								    "phy-rst");
> > +	if (IS_ERR(port->phy_reset))
> > +		return PTR_ERR(port->phy_reset);
> > +
> > +	reset_control_deassert(port->phy_reset);
> 
> In general, it is better to request all required resources before
> starting to activate the hardware.
> 
> > +
> > +	/* PHY power on and enable pipe clock */
> > +	port->phy = devm_phy_optional_get(dev, "pcie-phy");
> > +	if (IS_ERR(port->phy))
> > +		return PTR_ERR(port->phy);
> 
> For example, if the PHY driver is not loaded yet and this returns
> -EPROBE_DEFER, it was not useful to take the PHY out of reset above.
> Also, phy-rst is kept deasserted if this fails.
> 
> > +
> > +	err = phy_init(port->phy);
> > +	if (err) {
> > +		dev_notice(dev, "failed to initialize pcie phy\n");
> > +		return err;
> 
> phy-rst is kept deasserted if this fails.
> 
> > +	}
> > +
> > +	err = phy_power_on(port->phy);
> > +	if (err) {
> > +		dev_notice(dev, "failed to power on pcie phy\n");
> > +		goto err_phy_on;
> > +	}
> > +
> > +	port->mac_reset = devm_reset_control_get_optional_exclusive(dev,
> > +								    "mac-rst");
> > +	if (IS_ERR(port->mac_reset))
> > +		return PTR_ERR(port->mac_reset);
> 
> The PHY is not powered down if this fails.
> 
> > +
> > +	reset_control_deassert(port->mac_reset);
> > +
> > +	/* MAC power on and enable transaction layer clocks */
> > +	pm_runtime_enable(dev);
> > +	pm_runtime_get_sync(dev);
> > +
> > +	err = mtk_pcie_clk_init(port);
> > +	if (err) {
> > +		dev_notice(dev, "clock init failed\n");
> > +		goto err_clk_init;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_clk_init:
> > +	pm_runtime_put_sync(dev);
> > +	pm_runtime_disable(dev);
> > +	reset_control_assert(port->mac_reset);
> > +	phy_power_off(port->phy);
> > +err_phy_on:
> > +	phy_exit(port->phy);
> > +	reset_control_assert(port->phy_reset);
> > +
> > +	return -EBUSY;
> > +}
> > +
> > +static void mtk_pcie_power_down(struct mtk_pcie_port *port)
> > +{
> > +	phy_power_off(port->phy);
> > +	phy_exit(port->phy);
> > +
> > +	clk_bulk_disable_unprepare(port->num_clks, port->clks);
> 
> In the power-up sequence clocks are enabled last, but here they are not
> disabled before the PHY is powered off. Is this on purpose?
> 
> > +
> > +	pm_runtime_put_sync(port->dev);
> > +	pm_runtime_disable(port->dev);
> 
> In the power-up error path, PHY and controller resets are asserted
> again, but here they are kept deasserted. Should they be asserted here
> as well?
> 
> regards
> Philipp

Hi Philipp,

Sorry for the late responding and thanks for your review, I will fix it
in the next version.

Thanks.


WARNING: multiple messages have this Message-ID (diff)
From: Jianjun Wang <jianjun.wang@mediatek.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: youlin.pei@mediatek.com, devicetree@vger.kernel.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	qizhong.cheng@mediatek.com, chuanjia.liu@mediatek.com,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	linux-pci@vger.kernel.org, Ryder Lee <ryder.lee@mediatek.com>,
	linux-kernel@vger.kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Sj Huang <sj.huang@mediatek.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	sin_jieyang@mediatek.com, davem@davemloft.net,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [v3,2/3] PCI: mediatek: Add new generation controller support
Date: Tue, 3 Nov 2020 13:44:02 +0800	[thread overview]
Message-ID: <1604382242.2521.62.camel@mhfsdcap03> (raw)
In-Reply-To: <aaccd827fa6de117d27319884f2d70a2ea91aa5e.camel@pengutronix.de>

On Mon, 2020-09-28 at 10:32 +0200, Philipp Zabel wrote:
> Hi Jianjun,
> 
> On Sun, 2020-09-27 at 15:45 +0800, Jianjun Wang wrote:
> > MediaTek's PCIe host controller has three generation HWs, the new
> > generation HW is an individual bridge, it supoorts Gen3 speed and
> > up to 256 MSI interrupt numbers for multi-function devices.
> > 
> > Add support for new Gen3 controller which can be found on MT8192.
> > 
> > Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
> > Acked-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> >  drivers/pci/controller/Kconfig              |   14 +
> >  drivers/pci/controller/Makefile             |    1 +
> >  drivers/pci/controller/pcie-mediatek-gen3.c | 1024 +++++++++++++++++++
> >  3 files changed, 1039 insertions(+)
> >  create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c
> > 
> [...]
> > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> > new file mode 100644
> > index 000000000000..ad69c789b24d
> > --- /dev/null
> > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> > @@ -0,0 +1,1024 @@
> [...]
> > +static int mtk_pcie_power_up(struct mtk_pcie_port *port)
> > +{
> > +	struct device *dev = port->dev;
> > +	int err;
> > +
> > +	port->phy_reset = devm_reset_control_get_optional_exclusive(dev,
> > +								    "phy-rst");
> > +	if (IS_ERR(port->phy_reset))
> > +		return PTR_ERR(port->phy_reset);
> > +
> > +	reset_control_deassert(port->phy_reset);
> 
> In general, it is better to request all required resources before
> starting to activate the hardware.
> 
> > +
> > +	/* PHY power on and enable pipe clock */
> > +	port->phy = devm_phy_optional_get(dev, "pcie-phy");
> > +	if (IS_ERR(port->phy))
> > +		return PTR_ERR(port->phy);
> 
> For example, if the PHY driver is not loaded yet and this returns
> -EPROBE_DEFER, it was not useful to take the PHY out of reset above.
> Also, phy-rst is kept deasserted if this fails.
> 
> > +
> > +	err = phy_init(port->phy);
> > +	if (err) {
> > +		dev_notice(dev, "failed to initialize pcie phy\n");
> > +		return err;
> 
> phy-rst is kept deasserted if this fails.
> 
> > +	}
> > +
> > +	err = phy_power_on(port->phy);
> > +	if (err) {
> > +		dev_notice(dev, "failed to power on pcie phy\n");
> > +		goto err_phy_on;
> > +	}
> > +
> > +	port->mac_reset = devm_reset_control_get_optional_exclusive(dev,
> > +								    "mac-rst");
> > +	if (IS_ERR(port->mac_reset))
> > +		return PTR_ERR(port->mac_reset);
> 
> The PHY is not powered down if this fails.
> 
> > +
> > +	reset_control_deassert(port->mac_reset);
> > +
> > +	/* MAC power on and enable transaction layer clocks */
> > +	pm_runtime_enable(dev);
> > +	pm_runtime_get_sync(dev);
> > +
> > +	err = mtk_pcie_clk_init(port);
> > +	if (err) {
> > +		dev_notice(dev, "clock init failed\n");
> > +		goto err_clk_init;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_clk_init:
> > +	pm_runtime_put_sync(dev);
> > +	pm_runtime_disable(dev);
> > +	reset_control_assert(port->mac_reset);
> > +	phy_power_off(port->phy);
> > +err_phy_on:
> > +	phy_exit(port->phy);
> > +	reset_control_assert(port->phy_reset);
> > +
> > +	return -EBUSY;
> > +}
> > +
> > +static void mtk_pcie_power_down(struct mtk_pcie_port *port)
> > +{
> > +	phy_power_off(port->phy);
> > +	phy_exit(port->phy);
> > +
> > +	clk_bulk_disable_unprepare(port->num_clks, port->clks);
> 
> In the power-up sequence clocks are enabled last, but here they are not
> disabled before the PHY is powered off. Is this on purpose?
> 
> > +
> > +	pm_runtime_put_sync(port->dev);
> > +	pm_runtime_disable(port->dev);
> 
> In the power-up error path, PHY and controller resets are asserted
> again, but here they are kept deasserted. Should they be asserted here
> as well?
> 
> regards
> Philipp

Hi Philipp,

Sorry for the late responding and thanks for your review, I will fix it
in the next version.

Thanks.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-03  5:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-27  7:45 [v3,0/3] PCI: mediatek: Add new generation controller support Jianjun Wang
2020-09-27  7:45 ` Jianjun Wang
2020-09-27  7:45 ` Jianjun Wang
2020-09-27  7:45 ` [v3,1/3] dt-bindings: PCI: mediatek: Add YAML schema Jianjun Wang
2020-09-27  7:45   ` Jianjun Wang
2020-09-27  7:45   ` Jianjun Wang
2020-09-28  8:16   ` Philipp Zabel
2020-09-28  8:16     ` Philipp Zabel
2020-09-28  8:16     ` Philipp Zabel
2020-09-28 17:29   ` Rob Herring
2020-09-28 17:29     ` Rob Herring
2020-09-28 17:29     ` Rob Herring
2020-09-27  7:45 ` [v3,2/3] PCI: mediatek: Add new generation controller support Jianjun Wang
2020-09-27  7:45   ` Jianjun Wang
2020-09-27  7:45   ` Jianjun Wang
2020-09-28  8:32   ` Philipp Zabel
2020-09-28  8:32     ` Philipp Zabel
2020-09-28  8:32     ` Philipp Zabel
2020-11-03  5:44     ` Jianjun Wang [this message]
2020-11-03  5:44       ` Jianjun Wang
2020-11-03  5:44       ` Jianjun Wang
2020-09-27  7:45 ` [v3,3/3] MAINTAINERS: update entry for MediaTek PCIe controller Jianjun Wang
2020-09-27  7:45   ` Jianjun Wang
2020-09-27  7:45   ` 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=1604382242.2521.62.camel@mhfsdcap03 \
    --to=jianjun.wang@mediatek.com \
    --cc=bhelgaas@google.com \
    --cc=chuanjia.liu@mediatek.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --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=mchehab+huawei@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 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.