linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()
Date: Thu, 7 Apr 2016 19:42:59 +0800	[thread overview]
Message-ID: <20160407194259.5c13742c@xhacker> (raw)
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ED44208@lhreml503-mbs>

On Thu, 7 Apr 2016 10:06:45 +0000 Gabriele Paoloni wrote:

> Hi Jisheng
> 
..
> > >  
> > > >
> > > > Is it acceptable that pcie-hisi adds a call to dw_pcie_setup_rc()  
> > in  
> > > > hisi_add_pcie_port()?  
> > >
> > > I don't think so...that would try to overwrite what is already set by
> > > the bootloader; so it is wrong in principle and maybe it can lead to
> > > undefined behaviours...  
> > 
> > make sense! This commit is intend to re-setup the rc when waken from
> > s2ram (in
> > s2ram state, the host lost power)
> > 
> > I have no good solution but to introduce one function e.g
> > dw_pcie_setup_rc_after_linkup(), then move related code from
> > dw_pcie_host_init
> > to it, then let my host driver resume hook to call.
> > 
> > Hi Pratyush, Jingoo and Bjorn etc.
> > 
> > any suggestions are appreciated!  
> 
> What about:
> 
> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> index a4cccd3..e461f5d 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -434,7 +434,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
>  	struct platform_device *pdev = to_platform_device(pp->dev);
>  	struct pci_bus *bus, *child;
>  	struct resource *cfg_res;
> -	u32 val;
>  	int i, ret;
>  	LIST_HEAD(res);
>  	struct resource_entry *win;
> @@ -544,25 +543,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
>  	if (pp->ops->host_init)
>  		pp->ops->host_init(pp);
>  
> -	/*
> -	 * If the platform provides ->rd_other_conf, it means the platform
> -	 * uses its own address translation component rather than ATU, so
> -	 * we should not program the ATU here.
> -	 */
> -	if (!pp->ops->rd_other_conf)
> -		dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
> -					  PCIE_ATU_TYPE_MEM, pp->mem_base,
> -					  pp->mem_bus_addr, pp->mem_size);
> -
> -	dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0);
> -
> -	/* program correct class for RC */
> -	dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI);
> -
> -	dw_pcie_rd_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, &val);
> -	val |= PORT_LOGIC_SPEED_CHANGE;
> -	dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val);

If we introduced one global function, is it better to keep the RC registers
program sequence not changed at all? And ask each pcie dw users to call this
new function in its resume hook if necessary. Either is fine, and can provide
what I want, let's wait maintainers' comments.

Something like:


diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index a4cccd3..53c6176 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -434,7 +434,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
 	struct platform_device *pdev = to_platform_device(pp->dev);
 	struct pci_bus *bus, *child;
 	struct resource *cfg_res;
-	u32 val;
 	int i, ret;
 	LIST_HEAD(res);
 	struct resource_entry *win;
@@ -544,24 +543,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
 	if (pp->ops->host_init)
 		pp->ops->host_init(pp);
 
-	/*
-	 * If the platform provides ->rd_other_conf, it means the platform
-	 * uses its own address translation component rather than ATU, so
-	 * we should not program the ATU here.
-	 */
-	if (!pp->ops->rd_other_conf)
-		dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
-					  PCIE_ATU_TYPE_MEM, pp->mem_base,
-					  pp->mem_bus_addr, pp->mem_size);
-
-	dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0);
-
-	/* program correct class for RC */
-	dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI);
-
-	dw_pcie_rd_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, &val);
-	val |= PORT_LOGIC_SPEED_CHANGE;
-	dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val);
+	dw_pcie_setup_rc_after_linkup(pp);
 
 	pp->root_bus_nr = pp->busn->start;
 	if (IS_ENABLED(CONFIG_PCI_MSI)) {
@@ -725,6 +707,30 @@ static struct pci_ops dw_pcie_ops = {
 	.write = dw_pcie_wr_conf,
 };
 
+void dw_pcie_setup_rc_after_linkup(struct pcie_port *pp)
+{
+	u32 val;
+
+	/*
+	 * If the platform provides ->rd_other_conf, it means the platform
+	 * uses its own address translation component rather than ATU, so
+	 * we should not program the ATU here.
+	 */
+	if (!pp->ops->rd_other_conf)
+		dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
+					  PCIE_ATU_TYPE_MEM, pp->mem_base,
+					  pp->mem_bus_addr, pp->mem_size);
+
+	dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0);
+
+	/* program correct class for RC */
+	dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI);
+
+	dw_pcie_rd_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, &val);
+	val |= PORT_LOGIC_SPEED_CHANGE;
+	dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val);
+}
+
 void dw_pcie_setup_rc(struct pcie_port *pp)
 {
 	u32 val;
diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
index f437f9b..f7746bf 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -85,5 +85,6 @@ int dw_pcie_wait_for_link(struct pcie_port *pp);
 int dw_pcie_link_up(struct pcie_port *pp);
 void dw_pcie_setup_rc(struct pcie_port *pp);
 int dw_pcie_host_init(struct pcie_port *pp);
+void dw_pcie_setup_rc_after_linkup(struct pcie_port *pp);
 
 #endif /* _PCIE_DESIGNWARE_H */

  reply	other threads:[~2016-04-07 11:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16 11:40 [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc() Jisheng Zhang
2016-03-17  4:28 ` Pratyush Anand
2016-04-05 23:12 ` Bjorn Helgaas
2016-04-06 14:50 ` Gabriele Paoloni
2016-04-07  2:37   ` Jisheng Zhang
2016-04-07  8:20     ` Gabriele Paoloni
2016-04-07  8:34       ` Jisheng Zhang
2016-04-07 10:06         ` Gabriele Paoloni
2016-04-07 11:42           ` Jisheng Zhang [this message]
2016-04-07 14:05           ` Bjorn Helgaas
2016-04-08 13:33             ` Gabriele Paoloni
2016-04-08 16:01               ` Bjorn Helgaas
2016-04-12  9:43                 ` Gabriele Paoloni
2016-04-13  5:51                   ` Jingoo Han
2016-04-13  7:57                     ` Gabriele Paoloni
2016-04-14 11:52                       ` Jingoo Han
2016-04-14 13:08                         ` Pratyush Anand
2016-04-14 13:13                           ` Gabriele Paoloni
2016-04-21 15:48                   ` Bjorn Helgaas
2016-04-21 15:53                     ` Gabriele Paoloni
2016-04-07  6:59   ` Pratyush Anand
2016-04-07  8:14     ` Gabriele Paoloni

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=20160407194259.5c13742c@xhacker \
    --to=jszhang@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).