[PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

Subsystems: linux for powerpc (32-bit and 64-bit), the rest

STALE5028d

21 messages, 4 authors, 2012-10-30 · open the first message on its own page

[PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

From: Jia Hongtao <hidden>
Date: 2012-09-18 02:45:08 

Power supply for PCI inbound/outbound window registers is off when system
go to deep-sleep state. We save the values of registers before suspend
and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

 arch/powerpc/include/asm/pci-bridge.h |    2 +-
 arch/powerpc/sysdev/fsl_pci.c         |  121 +++++++++++++++++++++++++++++++++
 2 files changed, 122 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index ac39e6a..823e000 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -89,9 +89,9 @@ struct pci_controller {
 
 #ifdef CONFIG_PPC64
 	unsigned long buid;
+#endif	/* CONFIG_PPC64 */
 
 	void *private_data;
-#endif	/* CONFIG_PPC64 */
 };
 
 /* These are used for config access before all the PCI probing
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index e577cb5..8c15177 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -887,12 +887,133 @@ static int __devinit fsl_pci_probe(struct platform_device *pdev)
 	return 0;
 }
 
+#ifdef CONFIG_SUSPEND
+
+#define PCI_POW_PIW_OFFSET	0xc00
+#define PCI_POW_PIW_SIZE	0x200
+#define PCI_POW_NUMBER		5
+
+static int fsl_pci_suspend(struct platform_device *pdev, pm_message_t state)
+{
+	struct pci_controller *hose;
+	struct pci_outbound_window_regs *pci_saved_pow;
+	struct pci_inbound_window_regs *pci_saved_piw, *temp_piw;
+	struct resource pci_rsrc;
+	unsigned int i;
+	struct fsl_pci_private_data *sus_info;
+
+	hose = pci_find_hose_for_OF_device(pdev->dev.of_node);
+	of_address_to_resource(pdev->dev.of_node, 0, &pci_rsrc);
+
+	sus_info = kmalloc(
+			sizeof(struct fsl_pci_private_data), GFP_KERNEL);
+	if (!sus_info)
+		return -ENOMEM;
+
+	hose->private_data = sus_info;
+
+	sus_info->pci_pow = ioremap(pci_rsrc.start + PCI_POW_PIW_OFFSET,
+			PCI_POW_PIW_SIZE);
+	if (!sus_info->pci_pow) {
+		dev_err(&pdev->dev, "pci outbound/inbound windows ioremap error!\n");
+		goto err1;
+	}
+
+	sus_info->pci_piw = (struct pci_inbound_window_regs *)
+		((void *)sus_info->pci_pow + PCI_POW_PIW_SIZE) - 1;
+
+	if (of_device_is_compatible(pdev->dev.of_node, "fsl,qoriq-pcie-v2.2"))
+		sus_info->inbound_num = 4;
+	else
+		sus_info->inbound_num = 3;
+
+	sus_info->saved_regs = kmalloc(
+		sizeof(struct pci_outbound_window_regs) * PCI_POW_NUMBER +
+		sizeof(struct pci_inbound_window_regs) * sus_info->inbound_num,
+		GFP_KERNEL);
+	if (!sus_info->saved_regs)
+		goto err2;
+
+	pci_saved_pow = sus_info->saved_regs;
+	for (i = 0; i < PCI_POW_NUMBER; i++) {
+		pci_saved_pow[i].potar = in_be32(&sus_info->pci_pow[i].potar);
+		pci_saved_pow[i].potear = in_be32(&sus_info->pci_pow[i].potear);
+		pci_saved_pow[i].powbar = in_be32(&sus_info->pci_pow[i].powbar);
+		pci_saved_pow[i].powar = in_be32(&sus_info->pci_pow[i].powar);
+	}
+
+	pci_saved_piw = (struct pci_inbound_window_regs *)
+		(pci_saved_pow + PCI_POW_NUMBER);
+	temp_piw = sus_info->pci_piw;
+	for (i = 0; i < sus_info->inbound_num; i++, temp_piw--) {
+		pci_saved_piw[i].pitar = in_be32(&temp_piw->pitar);
+		pci_saved_piw[i].piwbar = in_be32(&temp_piw->piwbar);
+		pci_saved_piw[i].piwbear = in_be32(&temp_piw->piwbear);
+		pci_saved_piw[i].piwar = in_be32(&temp_piw->piwar);
+	}
+
+	return 0;
+
+err2:
+	iounmap(sus_info->pci_pow);
+
+err1:
+	kfree(sus_info);
+	return -ENOMEM;
+}
+
+static int fsl_pci_resume(struct platform_device *pdev)
+{
+	struct pci_controller *hose;
+	struct pci_outbound_window_regs *pci_saved_pow;
+	struct pci_inbound_window_regs *pci_saved_piw, *temp_piw;
+	unsigned int i;
+	struct fsl_pci_private_data *sus_info;
+
+	hose = pci_find_hose_for_OF_device(pdev->dev.of_node);
+	sus_info = (struct fsl_pci_private_data *)hose->private_data;
+
+	if (!sus_info->pci_pow || !sus_info->pci_piw || !sus_info->saved_regs)
+		return 0;
+
+	pci_saved_pow = sus_info->saved_regs;
+	for (i = 0; i < PCI_POW_NUMBER; i++) {
+		out_be32(&sus_info->pci_pow[i].potar, pci_saved_pow[i].potar);
+		out_be32(&sus_info->pci_pow[i].potear, pci_saved_pow[i].potear);
+		out_be32(&sus_info->pci_pow[i].powbar, pci_saved_pow[i].powbar);
+		out_be32(&sus_info->pci_pow[i].powar, pci_saved_pow[i].powar);
+	}
+
+	pci_saved_piw = (struct pci_inbound_window_regs *)
+		(pci_saved_pow + PCI_POW_NUMBER);
+	temp_piw = sus_info->pci_piw;
+	for (i = 0; i < sus_info->inbound_num; i++, temp_piw--) {
+		out_be32(&temp_piw->pitar, pci_saved_piw[i].pitar);
+		out_be32(&temp_piw->piwbar, pci_saved_piw[i].piwbar);
+		out_be32(&temp_piw->piwbear, pci_saved_piw[i].piwbear);
+		out_be32(&temp_piw->piwar, pci_saved_piw[i].piwar);
+	}
+	iounmap(sus_info->pci_pow);
+	kfree(sus_info->saved_regs);
+	sus_info->saved_regs = NULL;
+	kfree(sus_info);
+	sus_info = NULL;
+	hose->private_data = NULL;
+
+	return 0;
+}
+#endif
+
 static struct platform_driver fsl_pci_driver = {
 	.driver = {
 		.name = "fsl-pci",
 		.of_match_table = pci_ids,
 	},
 	.probe = fsl_pci_probe,
+#ifdef CONFIG_SUSPEND
+	.suspend	= fsl_pci_suspend,
+	.resume		= fsl_pci_resume,
+#endif
 };
 
 static int __init fsl_pci_init(void)
-- 
1.7.5.1

Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

From: Kumar Gala <hidden>
Date: 2012-09-18 05:03:38 

On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

Power supply for PCI inbound/outbound window registers is off when =
system
go to deep-sleep state. We save the values of registers before suspend
and restore to registers after resume.
=20
Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code
=20
arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121 =
+++++++++++++++++++++++++++++++++
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree method?

- k=

RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

From: Jia Hongtao-B38951 <hidden>
Date: 2012-09-19 07:10:19 

-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Tuesday, September 18, 2012 1:04 PM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support
=20
=20
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
=20
quoted
Power supply for PCI inbound/outbound window registers is off when
system go to deep-sleep state. We save the values of registers before
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
=20
Did you ever compare this to just re-parsing device tree method?
=20
- k
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO translation
address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but atmu
is not updated according to the new hose->io_resource value.
In resume from sleep setup_atmu() will reset atmu according to the
new hose->io_resource value. So the setup_atmu() will cause different
result on outbound IO register between first bootup and resume from
sleep.

So... There's a possibility that in the first bootup atmu is not setup
properly.

Anyway, if setup_pci_atmu() at resume is functionally right then re-parsing
is a good way for PM. I also test the latency of re-parsing and save/restor=
e,
both way are acceptable.


- Hongtao.





  

    
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Kumar Gala <hidden>

      Date: 2012-09-19 14:27:35 
    

  

  
On Sep 19, 2012, at 2:10 AM, Jia Hongtao-B38951 wrote:

=20
=20
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Tuesday, September 18, 2012 1:04 PM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support
=20
=20
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
=20
quoted
Power supply for PCI inbound/outbound window registers is off when
system go to deep-sleep state. We save the values of registers =
before
quoted
quoted
suspend and restore to registers after resume.
=20
Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code
=20
arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
=20
Did you ever compare this to just re-parsing device tree method?
=20
- k
=20
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO translation
address regitster.
=20
It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but atmu
is not updated according to the new hose->io_resource value.
In resume from sleep setup_atmu() will reset atmu according to the
new hose->io_resource value. So the setup_atmu() will cause different
result on outbound IO register between first bootup and resume from
sleep.
=20
So... There's a possibility that in the first bootup atmu is not setup
properly.
Are you seeing this happen in your testing?  If so its a bug we need to =
look at fixing.

=20
Anyway, if setup_pci_atmu() at resume is functionally right then =
re-parsing
is a good way for PM. I also test the latency of re-parsing and =
save/restore,
both way are acceptable.
=20
=20
- Hongtao.





  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Jia Hongtao-B38951 <hidden>

      Date: 2012-09-19 15:41:50 
    

  

  
=0A=
________________________________________=0A=
From: Kumar Gala [galak@kernel.crashing.org]=0A=
Sent: Wednesday, September 19, 2012 10:27 PM=0A=
To: Jia Hongtao-B38951=0A=
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421=0A=
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM suppo=
rt=0A=
=0A=
On Sep 19, 2012, at 2:10 AM, Jia Hongtao-B38951 wrote:=0A=
=0A=
=0A=
=0A=
quoted
-----Original Message-----=0A=
From: Kumar Gala [mailto:galak@kernel.crashing.org]=0A=
Sent: Tuesday, September 18, 2012 1:04 PM=0A=
To: Jia Hongtao-B38951=0A=
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421=0A=
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM=0A=
support=0A=
=0A=
=0A=
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:=0A=
=0A=
quoted
Power supply for PCI inbound/outbound window registers is off when=0A=
system go to deep-sleep state. We save the values of registers before=
=0A=
quoted
quoted
suspend and restore to registers after resume.=0A=
=0A=
Signed-off-by: Jiang Yutang <redacted>=0A=
Signed-off-by: Jia Hongtao <redacted>=0A=
Signed-off-by: Li Yang <redacted>=0A=
---=0A=
Changes for V4:=0A=
We just rebase the patch upon following patch:=0A=
powerpc/fsl-pci: Unify pci/pcie initialization code=0A=
=0A=
arch/powerpc/include/asm/pci-bridge.h |    2 +-=0A=
arch/powerpc/sysdev/fsl_pci.c         |  121=0A=
+++++++++++++++++++++++++++++++++=0A=
quoted
2 files changed, 122 insertions(+), 1 deletions(-)=0A=
=0A=
Did you ever compare this to just re-parsing device tree method?=0A=
=0A=
- k=0A=
=0A=
I tested the re-parsing way by using setup_pci_atmu() when resume.=0A=
And I found out that re-parsing will *change* outbound IO translation=0A=
address regitster.=0A=
=0A=
It seems that in the first bootup, after setup_atmu()=0A=
pcibios_setup_phb_resources() may update hose->io_resource, but atmu=0A=
is not updated according to the new hose->io_resource value.=0A=
In resume from sleep setup_atmu() will reset atmu according to the=0A=
new hose->io_resource value. So the setup_atmu() will cause different=0A=
result on outbound IO register between first bootup and resume from=0A=
sleep.=0A=
=0A=
So... There's a possibility that in the first bootup atmu is not setup=0A=
properly.=0A=
=0A=
[Are you seeing this happen in your testing?  If so its a bug we need to lo=
ok at fixing.]=0A=
=0A=
Yes, I see this in my testing.=0A=
Also PCIe ethernet card works well after resuming from sleep in both save/r=
estore=0A=
and re-parsing way. (Maybe PCIe ethernet card don't need outbound IO resour=
ce)=0A=
So, I guess the result of re-parsing (actually it's re-setup) is right and =
ATMU is not setup=0A=
properly at the first bootup.=0A=
=0A=
=0A=
=0A=
=0A=
Anyway, if setup_pci_atmu() at resume is functionally right then re-parsi=
ng=0A=
is a good way for PM. I also test the latency of re-parsing and save/rest=
ore,=0A=
both way are acceptable.=0A=
=0A=
=0A=
- Hongtao.=0A=
=0A=
=0A=





  

    
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Kumar Gala <hidden>

      Date: 2012-09-19 15:49:51 
    

  

  
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
=20
quoted
Power supply for PCI inbound/outbound window registers is off when
system go to deep-sleep state. We save the values of registers =
before
quoted
quoted
quoted
suspend and restore to registers after resume.
=20
Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code
=20
arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
=20
Did you ever compare this to just re-parsing device tree method?
=20
- k
=20
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO translation
address regitster.
=20
It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but atmu
is not updated according to the new hose->io_resource value.
In resume from sleep setup_atmu() will reset atmu according to the
new hose->io_resource value. So the setup_atmu() will cause different
result on outbound IO register between first bootup and resume from
sleep.
=20
So... There's a possibility that in the first bootup atmu is not =
setup
quoted
properly.
=20
[Are you seeing this happen in your testing?  If so its a bug we need =
to look at fixing.]
=20
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in both =
save/restore
and re-parsing way. (Maybe PCIe ethernet card don't need outbound IO =
resource)
So, I guess the result of re-parsing (actually it's re-setup) is right =
and ATMU is not setup
properly at the first bootup.
Are you seeing the following message - "PCI: I/O resource not set for =
host bridge" ?

Trying to understand why you'd hit the reassignment of io_resource.

- k

=20
=20
=20
quoted
=20
Anyway, if setup_pci_atmu() at resume is functionally right then =
re-parsing
quoted
is a good way for PM. I also test the latency of re-parsing and =
save/restore,
quoted
both way are acceptable.
=20
=20
- Hongtao.
=20
=20





  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Jia Hongtao-B38951 <hidden>

      Date: 2012-09-21 03:13:57 
    

  

  
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Wednesday, September 19, 2012 11:49 PM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support
=20
quoted
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

quoted
Power supply for PCI inbound/outbound window registers is off when
system go to deep-sleep state. We save the values of registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree method?

- k
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO translation
address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but atmu
is not updated according to the new hose->io_resource value.
In resume from sleep setup_atmu() will reset atmu according to the
new hose->io_resource value. So the setup_atmu() will cause different
result on outbound IO register between first bootup and resume from
sleep.

So... There's a possibility that in the first bootup atmu is not setup
properly.
[Are you seeing this happen in your testing?  If so its a bug we need
to look at fixing.]
quoted
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need outbound IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup) is right
and ATMU is not setup
quoted
properly at the first bootup.
=20
Are you seeing the following message - "PCI: I/O resource not set for
host bridge" ?
No.

=20
Trying to understand why you'd hit the reassignment of io_resource.
=20
- k
=20
I did some investigations and the conclusion is:

io_resource.flags & IORESOURCE_IO are both positive but io_resource.start
is 0 before pcibios_setup_phb_io_space() is done.

The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() -> pcibios_setup_phb_io_space()

Because fsl_add_bridge() must be finished before pcibios_init() so ATMU
is set when io_resource.start is 0. That means outbound IO regs are not
set.

If system re-setup ATMU the io_resource.start has already updated so
outbound IO regs are set.

My question is:
Is there any problem if outbound IO regs are not set in first bootup?

- Hongtao.





  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Li Yang-R58472 <hidden>

      Date: 2012-09-21 03:50:56 
    

  

  
-----Original Message-----
From: Jia Hongtao-B38951
Sent: Friday, September 21, 2012 11:14 AM
To: Kumar Gala
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421
Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support
=20
=20
=20
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Wednesday, September 19, 2012 11:49 PM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support

quoted
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

quoted
Power supply for PCI inbound/outbound window registers is off
when system go to deep-sleep state. We save the values of
registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree method?

- k
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but
atmu is not updated according to the new hose->io_resource value.
In resume from sleep setup_atmu() will reset atmu according to the
new hose->io_resource value. So the setup_atmu() will cause
different result on outbound IO register between first bootup and
resume from sleep.

So... There's a possibility that in the first bootup atmu is not
setup properly.
[Are you seeing this happen in your testing?  If so its a bug we
need
to look at fixing.]
quoted
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need outbound IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup) is
right
and ATMU is not setup
quoted
properly at the first bootup.
Are you seeing the following message - "PCI: I/O resource not set for
host bridge" ?
=20
No.
=20
quoted
Trying to understand why you'd hit the reassignment of io_resource.

- k
=20
I did some investigations and the conclusion is:
=20
io_resource.flags & IORESOURCE_IO are both positive but io_resource.start
is 0 before pcibios_setup_phb_io_space() is done.
=20
The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() -> pcibios_setup_phb_io_space()
=20
Because fsl_add_bridge() must be finished before pcibios_init() so ATMU
is set when io_resource.start is 0. That means outbound IO regs are not
set.
=20
If system re-setup ATMU the io_resource.start has already updated so
outbound IO regs are set.
=20
My question is:
Is there any problem if outbound IO regs are not set in first bootup?
Please also provide the IO resource address range before and after the pci =
scan.  Then we can evaluate if the range is needed to be mapped via ATMU.

Leo





  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Jia Hongtao-B38951 <hidden>

      Date: 2012-09-21 05:15:44 
    

  

  
-----Original Message-----
From: Li Yang-R58472
Sent: Friday, September 21, 2012 11:51 AM
To: Jia Hongtao-B38951; Kumar Gala
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support
=20
=20
=20
quoted
-----Original Message-----
From: Jia Hongtao-B38951
Sent: Friday, September 21, 2012 11:14 AM
To: Kumar Gala
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421
Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support



quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Wednesday, September 19, 2012 11:49 PM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound
PM support

quoted
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

quoted
Power supply for PCI inbound/outbound window registers is off
when system go to deep-sleep state. We save the values of
registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree method?

- k
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but
atmu is not updated according to the new hose->io_resource value.
In resume from sleep setup_atmu() will reset atmu according to
the new hose->io_resource value. So the setup_atmu() will cause
different result on outbound IO register between first bootup and
resume from sleep.

So... There's a possibility that in the first bootup atmu is not
setup properly.
[Are you seeing this happen in your testing?  If so its a bug we
need
to look at fixing.]
quoted
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in
both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need outbound
IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup) is
right
and ATMU is not setup
quoted
properly at the first bootup.
Are you seeing the following message - "PCI: I/O resource not set
for host bridge" ?
No.

quoted
Trying to understand why you'd hit the reassignment of io_resource.

- k
I did some investigations and the conclusion is:

io_resource.flags & IORESOURCE_IO are both positive but
io_resource.start is 0 before pcibios_setup_phb_io_space() is done.

The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() -> pcibios_setup_phb_io_space()

Because fsl_add_bridge() must be finished before pcibios_init() so
ATMU is set when io_resource.start is 0. That means outbound IO regs
are not set.

If system re-setup ATMU the io_resource.start has already updated so
outbound IO regs are set.

My question is:
Is there any problem if outbound IO regs are not set in first bootup?
=20
Please also provide the IO resource address range before and after the
pci scan.  Then we can evaluate if the range is needed to be mapped via
ATMU.
=20
Leo
Since potar is set by out_be32(&pci->pow[j].potar, (hose->io_resource.start=
 >> 12);
I provide the result of hose->io_resource.start >> 12 as follows:

pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7ed

pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7db

pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7c9

Note that I tested on P1022DS.

- Hongtao.





  

    
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Kumar Gala <hidden>

      Date: 2012-09-21 13:16:00 
    

  

  
quoted
quoted
quoted
quoted
quoted
quoted
=20
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
=20
quoted
Power supply for PCI inbound/outbound window registers is off
when system go to deep-sleep state. We save the values of
registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.
=20
Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code
=20
arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
=20
Did you ever compare this to just re-parsing device tree method?
=20
- k
=20
I tested the re-parsing way by using setup_pci_atmu() when =
resume.
quoted
quoted
quoted
quoted
quoted
And I found out that re-parsing will *change* outbound IO
translation address regitster.
=20
It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but
atmu is not updated according to the new hose->io_resource value.
In resume from sleep setup_atmu() will reset atmu according to
the new hose->io_resource value. So the setup_atmu() will cause
different result on outbound IO register between first bootup and
resume from sleep.
=20
So... There's a possibility that in the first bootup atmu is not
setup properly.
=20
[Are you seeing this happen in your testing?  If so its a bug we
need
to look at fixing.]
quoted
=20
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in
both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need outbound
IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup) is
right
and ATMU is not setup
quoted
properly at the first bootup.
=20
Are you seeing the following message - "PCI: I/O resource not set
for host bridge" ?
=20
No.
=20
quoted
=20
Trying to understand why you'd hit the reassignment of io_resource.
=20
- k
=20
=20
I did some investigations and the conclusion is:
=20
io_resource.flags & IORESOURCE_IO are both positive but
io_resource.start is 0 before pcibios_setup_phb_io_space() is done.
=20
The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() -> pcibios_setup_phb_io_space()
=20
Because fsl_add_bridge() must be finished before pcibios_init() so
ATMU is set when io_resource.start is 0. That means outbound IO regs
are not set.
=20
If system re-setup ATMU the io_resource.start has already updated so
outbound IO regs are set.
=20
My question is:
Is there any problem if outbound IO regs are not set in first =
bootup?

Yes, it means that IO transactions would not work.

quoted
Please also provide the IO resource address range before and after =
the
quoted
pci scan.  Then we can evaluate if the range is needed to be mapped =
via
quoted
ATMU.
=20
Leo
=20
Since potar is set by out_be32(&pci->pow[j].potar, =
(hose->io_resource.start >> 12);
I provide the result of hose->io_resource.start >> 12 as follows:
=20
pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7ed
=20
pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7db
=20
pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7c9
=20
Note that I tested on P1022DS.
=20
- Hongtao.
1. What's the device tree nodes for PCIe look like?
2. Can you get the pr_debug() in setup_pci_atmu() to print and report =
results (as well as full boot log)

However, I think the change of the io_resource.start is normal and =
correct behavior.

- k





  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Jia Hongtao-B38951 <hidden>

      Date: 2012-09-24 02:47:45 
    

  

  
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, September 21, 2012 9:16 PM
To: Jia Hongtao-B38951
Cc: Li Yang-R58472; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support

quoted
quoted
quoted
quoted
quoted
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

quoted
Power supply for PCI inbound/outbound window registers is off
when system go to deep-sleep state. We save the values of
registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree method?

- k
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but
atmu is not updated according to the new hose->io_resource value.
In resume from sleep setup_atmu() will reset atmu according to
the new hose->io_resource value. So the setup_atmu() will cause
different result on outbound IO register between first bootup and
resume from sleep.

So... There's a possibility that in the first bootup atmu is not
setup properly.
[Are you seeing this happen in your testing?  If so its a bug we
need
to look at fixing.]
quoted
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in
both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need outbound
IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup) is
right
and ATMU is not setup
quoted
properly at the first bootup.
Are you seeing the following message - "PCI: I/O resource not set
for host bridge" ?
No.

quoted
Trying to understand why you'd hit the reassignment of io_resource.

- k
I did some investigations and the conclusion is:

io_resource.flags & IORESOURCE_IO are both positive but
io_resource.start is 0 before pcibios_setup_phb_io_space() is done.

The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() -> pcibios_setup_phb_io_space()

Because fsl_add_bridge() must be finished before pcibios_init() so
ATMU is set when io_resource.start is 0. That means outbound IO regs
are not set.

If system re-setup ATMU the io_resource.start has already updated so
outbound IO regs are set.

My question is:
Is there any problem if outbound IO regs are not set in first bootup?
Yes, it means that IO transactions would not work.
I agree.

quoted
quoted
Please also provide the IO resource address range before and after the
pci scan.  Then we can evaluate if the range is needed to be mapped
via
quoted
quoted
ATMU.

Leo
Since potar is set by out_be32(&pci->pow[j].potar, (hose-
io_resource.start >> 12);
I provide the result of hose->io_resource.start >> 12 as follows:

pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7ed

pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7db

pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7c9

Note that I tested on P1022DS.

- Hongtao.
1. What's the device tree nodes for PCIe look like?
2. Can you get the pr_debug() in setup_pci_atmu() to print and report
results (as well as full boot log)
Please refer to the attached file.
In the log file I also print the device tree.

- Hongtao.

However, I think the change of the io_resource.start is normal and
correct behavior.

- k





  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Jia Hongtao-B38951 <hidden>

      Date: 2012-09-27 02:59:07 
    

  

  
-----Original Message-----
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+b38951=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Jia Hongtao=
-
B38951
Sent: Monday, September 24, 2012 10:47 AM
To: Kumar Gala
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support
=20
=20
=20
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, September 21, 2012 9:16 PM
To: Jia Hongtao-B38951
Cc: Li Yang-R58472; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support

quoted
quoted
quoted
quoted
quoted
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

quoted
Power supply for PCI inbound/outbound window registers is off
when system go to deep-sleep state. We save the values of
registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree method=
?
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
- k
I tested the re-parsing way by using setup_pci_atmu() when
resume.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
And I found out that re-parsing will *change* outbound IO
translation address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but
atmu is not updated according to the new hose->io_resource value=
.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
In resume from sleep setup_atmu() will reset atmu according to
the new hose->io_resource value. So the setup_atmu() will cause
different result on outbound IO register between first bootup
and resume from sleep.

So... There's a possibility that in the first bootup atmu is
not setup properly.
[Are you seeing this happen in your testing?  If so its a bug we
need
to look at fixing.]
quoted
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in
both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need
outbound IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup) is
right
and ATMU is not setup
quoted
properly at the first bootup.
Are you seeing the following message - "PCI: I/O resource not set
for host bridge" ?
No.

quoted
Trying to understand why you'd hit the reassignment of io_resource=
.
quoted
quoted
quoted
quoted
quoted
- k
I did some investigations and the conclusion is:

io_resource.flags & IORESOURCE_IO are both positive but
io_resource.start is 0 before pcibios_setup_phb_io_space() is done.

The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() ->
pcibios_setup_phb_io_space()

Because fsl_add_bridge() must be finished before pcibios_init() so
ATMU is set when io_resource.start is 0. That means outbound IO
regs are not set.

If system re-setup ATMU the io_resource.start has already updated
so outbound IO regs are set.

My question is:
Is there any problem if outbound IO regs are not set in first
bootup?
quoted
Yes, it means that IO transactions would not work.
=20
I agree.
=20
quoted
quoted
quoted
Please also provide the IO resource address range before and after
the pci scan.  Then we can evaluate if the range is needed to be
mapped
via
quoted
quoted
ATMU.

Leo
Since potar is set by out_be32(&pci->pow[j].potar, (hose-
io_resource.start >> 12);  I provide the result of
hose->io_resource.start >> 12 as follows:

pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7ed

pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7db

pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7c9

Note that I tested on P1022DS.

- Hongtao.
1. What's the device tree nodes for PCIe look like?
2. Can you get the pr_debug() in setup_pci_atmu() to print and report
results (as well as full boot log)
=20
Please refer to the attached file.
In the log file I also print the device tree.
=20
- Hongtao.
=20
quoted
However, I think the change of the io_resource.start is normal and
correct behavior.

- k
=20
Hi Kumar,
I have already sent the log.
Do you have any comment on it?

Thanks.
- Hongtao.





  

    
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Kumar Gala <hidden>

      Date: 2012-09-27 12:05:44 
    

  

  
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
=20
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
=20
quoted
Power supply for PCI inbound/outbound window registers is =
off
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
when system go to deep-sleep state. We save the values of
registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.
=20
Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code
=20
arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
=20
Did you ever compare this to just re-parsing device tree =
method?
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
=20
- k
=20
I tested the re-parsing way by using setup_pci_atmu() when
resume.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
And I found out that re-parsing will *change* outbound IO
translation address regitster.
=20
It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, =
but
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
atmu is not updated according to the new hose->io_resource =
value.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
In resume from sleep setup_atmu() will reset atmu according to
the new hose->io_resource value. So the setup_atmu() will =
cause
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
different result on outbound IO register between first bootup
and resume from sleep.
=20
So... There's a possibility that in the first bootup atmu is
not setup properly.
=20
[Are you seeing this happen in your testing?  If so its a bug =
we
quoted
quoted
quoted
quoted
quoted
quoted
quoted
need
to look at fixing.]
quoted
=20
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in
both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need
outbound IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup) =
is
quoted
quoted
quoted
quoted
quoted
quoted
quoted
right
and ATMU is not setup
quoted
properly at the first bootup.
=20
Are you seeing the following message - "PCI: I/O resource not =
set
quoted
quoted
quoted
quoted
quoted
quoted
for host bridge" ?
=20
No.
=20
quoted
=20
Trying to understand why you'd hit the reassignment of =
io_resource.
quoted
quoted
quoted
quoted
quoted
quoted
=20
- k
=20
=20
I did some investigations and the conclusion is:
=20
io_resource.flags & IORESOURCE_IO are both positive but
io_resource.start is 0 before pcibios_setup_phb_io_space() is =
done.
quoted
quoted
quoted
quoted
quoted
=20
The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() ->
pcibios_setup_phb_io_space()
=20
Because fsl_add_bridge() must be finished before pcibios_init() =
so
quoted
quoted
quoted
quoted
quoted
ATMU is set when io_resource.start is 0. That means outbound IO
regs are not set.
=20
If system re-setup ATMU the io_resource.start has already updated
so outbound IO regs are set.
=20
My question is:
Is there any problem if outbound IO regs are not set in first
bootup?
quoted
=20
Yes, it means that IO transactions would not work.
=20
I agree.
=20
quoted
=20
quoted
quoted
Please also provide the IO resource address range before and after
the pci scan.  Then we can evaluate if the range is needed to be
mapped
via
quoted
quoted
ATMU.
=20
Leo
=20
Since potar is set by out_be32(&pci->pow[j].potar, (hose-
io_resource.start >> 12);  I provide the result of
hose->io_resource.start >> 12 as follows:
=20
pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7ed
=20
pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7db
=20
pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7c9
=20
Note that I tested on P1022DS.
=20
- Hongtao.
=20
1. What's the device tree nodes for PCIe look like?
2. Can you get the pr_debug() in setup_pci_atmu() to print and =
report
quoted
quoted
results (as well as full boot log)
=20
Please refer to the attached file.
In the log file I also print the device tree.
=20
- Hongtao.
=20
quoted
=20
However, I think the change of the io_resource.start is normal and
correct behavior.
=20
- k
=20
=20
=20
Hi Kumar,
I have already sent the log.
Do you have any comment on it?
=20
Thanks.
- Hongtao.
=20
Hongtao,

You mentioned:

I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.
What do the values look like in both ATMU registers and io_resource if =
you reparse?

- k=





  

    
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Li Yang <hidden>

      Date: 2012-09-27 13:24:40 
    

  

  
On Thu, Sep 27, 2012 at 8:05 PM, Kumar Gala [off-list ref] wrote:
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

quoted
Power supply for PCI inbound/outbound window registers is off
when system go to deep-sleep state. We save the values of
registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree method?

- k
I tested the re-parsing way by using setup_pci_atmu() when
resume.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
And I found out that re-parsing will *change* outbound IO
translation address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource, but
atmu is not updated according to the new hose->io_resource value.
In resume from sleep setup_atmu() will reset atmu according to
the new hose->io_resource value. So the setup_atmu() will cause
different result on outbound IO register between first bootup
and resume from sleep.

So... There's a possibility that in the first bootup atmu is
not setup properly.
[Are you seeing this happen in your testing?  If so its a bug we
need
to look at fixing.]
quoted
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in
both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need
outbound IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup) is
right
and ATMU is not setup
quoted
properly at the first bootup.
Are you seeing the following message - "PCI: I/O resource not set
for host bridge" ?
No.

quoted
Trying to understand why you'd hit the reassignment of io_resource.

- k
I did some investigations and the conclusion is:

io_resource.flags & IORESOURCE_IO are both positive but
io_resource.start is 0 before pcibios_setup_phb_io_space() is done.

The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() ->
pcibios_setup_phb_io_space()

Because fsl_add_bridge() must be finished before pcibios_init() so
ATMU is set when io_resource.start is 0. That means outbound IO
regs are not set.

If system re-setup ATMU the io_resource.start has already updated
so outbound IO regs are set.

My question is:
Is there any problem if outbound IO regs are not set in first
bootup?
quoted
Yes, it means that IO transactions would not work.
I agree.

quoted
quoted
quoted
Please also provide the IO resource address range before and after
the pci scan.  Then we can evaluate if the range is needed to be
mapped
via
quoted
quoted
ATMU.

Leo
Since potar is set by out_be32(&pci->pow[j].potar, (hose-
io_resource.start >> 12);  I provide the result of
hose->io_resource.start >> 12 as follows:

pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7ed

pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7db

pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7c9

Note that I tested on P1022DS.

- Hongtao.
1. What's the device tree nodes for PCIe look like?
2. Can you get the pr_debug() in setup_pci_atmu() to print and report
results (as well as full boot log)
Please refer to the attached file.
In the log file I also print the device tree.

- Hongtao.

quoted
However, I think the change of the io_resource.start is normal and
correct behavior.

- k
Hi Kumar,
I have already sent the log.
Do you have any comment on it?

Thanks.
- Hongtao.
Hongtao,

You mentioned:

quoted
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.
What do the values look like in both ATMU registers and io_resource if you reparse?
I think Hongtao mentioned in previous email as follows, the ATMU
registers are inline with the io_resource address.

quoted
Since potar is set by out_be32(&pci->pow[j].potar, (hose-
io_resource.start >> 12);
I provide the result of hose->io_resource.start >> 12 as follows:

pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7ed

pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7db

pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7c9

Note that I tested on P1022DS.





  

    
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Kumar Gala <hidden>

      Date: 2012-09-27 16:04:03 
    

  

  
quoted
quoted
Hi Kumar,
I have already sent the log.
Do you have any comment on it?
=20
Thanks.
- Hongtao.
=20
=20
Hongtao,
=20
You mentioned:
=20
quoted
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.
=20
What do the values look like in both ATMU registers and io_resource =
if you reparse?
=20
I think Hongtao mentioned in previous email as follows, the ATMU
registers are inline with the io_resource address.
I was under that the impression that was the normal boot case, not the =
values from after wakeup.

- k

quoted
quoted
Since potar is set by out_be32(&pci->pow[j].potar, (hose-
io_resource.start >> 12);
I provide the result of hose->io_resource.start >> 12 as follows:
=20
pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7ed
=20
pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7db
=20
pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7c9
=20
Note that I tested on P1022DS.





  

    
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Li Yang-R58472 <hidden>

      Date: 2012-09-27 16:27:47 
    

  

  
DQrU2iBTZXAgMjgsIDIwMTKjrDA6MDejrCJLdW1hciBHYWxhIiA8Z2FsYWtAa2VybmVsLmNyYXNo
aW5nLm9yZz4g0LS1wKO6DQoNCj4+Pj4gSGkgS3VtYXIsDQo+Pj4+IEkgaGF2ZSBhbHJlYWR5IHNl
bnQgdGhlIGxvZy4NCj4+Pj4gRG8geW91IGhhdmUgYW55IGNvbW1lbnQgb24gaXQ/DQo+Pj4+IA0K
Pj4+PiBUaGFua3MuDQo+Pj4+IC0gSG9uZ3Rhby4NCj4+Pj4gDQo+Pj4gDQo+Pj4gSG9uZ3RhbywN
Cj4+PiANCj4+PiBZb3UgbWVudGlvbmVkOg0KPj4+IA0KPj4+PiBJIHRlc3RlZCB0aGUgcmUtcGFy
c2luZyB3YXkgYnkgdXNpbmcgc2V0dXBfcGNpX2F0bXUoKSB3aGVuIHJlc3VtZS4NCj4+Pj4gQW5k
IEkgZm91bmQgb3V0IHRoYXQgcmUtcGFyc2luZyB3aWxsICpjaGFuZ2UqIG91dGJvdW5kIElPDQo+
Pj4+IHRyYW5zbGF0aW9uIGFkZHJlc3MgcmVnaXRzdGVyLg0KPj4+IA0KPj4+IFdoYXQgZG8gdGhl
IHZhbHVlcyBsb29rIGxpa2UgaW4gYm90aCBBVE1VIHJlZ2lzdGVycyBhbmQgaW9fcmVzb3VyY2Ug
aWYgeW91IHJlcGFyc2U/DQo+PiANCj4+IEkgdGhpbmsgSG9uZ3RhbyBtZW50aW9uZWQgaW4gcHJl
dmlvdXMgZW1haWwgYXMgZm9sbG93cywgdGhlIEFUTVUNCj4+IHJlZ2lzdGVycyBhcmUgaW5saW5l
IHdpdGggdGhlIGlvX3Jlc291cmNlIGFkZHJlc3MuDQo+IA0KPiBJIHdhcyB1bmRlciB0aGF0IHRo
ZSBpbXByZXNzaW9uIHRoYXQgd2FzIHRoZSBub3JtYWwgYm9vdCBjYXNlLCBub3QgdGhlIHZhbHVl
cyBmcm9tIGFmdGVyIHdha2V1cC4NCg0KSXQgaXMgZm9yIHRoZSBub3JtYWwgYm9vdC4gIEJ1dCBy
ZS1wYXJzZSB3aWxsIHVzZSB0aGUgaW8gcmVzb3VyY2UgYWZ0ZXIgcGljIHNjYW4gdG8gaW5pdGlh
bGl6ZSBhdG11LiAgSW5zdGVhZCwgdGhlIG9yaWdpbmFsIGF0bXUgaXMgaW5pdGlhbGl6ZWQgdXNl
IHRoZSBpbyByZXNvdXJjZSBiZWZvcmUgdGhlIHNjYW4uDQoNCkxlbw0KPiANCj4gLSBrDQo+IA0K
Pj4+PiBTaW5jZSBwb3RhciBpcyBzZXQgYnkgb3V0X2JlMzIoJnBjaS0+cG93W2pdLnBvdGFyLCAo
aG9zZS0NCj4+Pj4gaW9fcmVzb3VyY2Uuc3RhcnQgPj4gMTIpOw0KPj4+PiBJIHByb3ZpZGUgdGhl
IHJlc3VsdCBvZiBob3NlLT5pb19yZXNvdXJjZS5zdGFydCA+PiAxMiBhcyBmb2xsb3dzOg0KPj4+
PiANCj4+Pj4gcGNpZUBmZmUwOTAwMDoNCj4+Pj4gYmVmb3JlIHBjaSBzY2FuOiBpb19yZXNvdXJj
ZS5zdGFydCA+PiAxMjogMA0KPj4+PiBhZnRlciBwY2kgc2NhbiA6IGlvX3Jlc291cmNlLnN0YXJ0
ID4+IDEyOiBmZjdlZA0KPj4+PiANCj4+Pj4gcGNpZUBmZmUwYTAwMDoNCj4+Pj4gYmVmb3JlIHBj
aSBzY2FuOiBpb19yZXNvdXJjZS5zdGFydCA+PiAxMjogMA0KPj4+PiBhZnRlciBwY2kgc2NhbiA6
IGlvX3Jlc291cmNlLnN0YXJ0ID4+IDEyOiBmZjdkYg0KPj4+PiANCj4+Pj4gcGNpZUBmZmUwYjAw
MDoNCj4+Pj4gYmVmb3JlIHBjaSBzY2FuOiBpb19yZXNvdXJjZS5zdGFydCA+PiAxMjogMA0KPj4+
PiBhZnRlciBwY2kgc2NhbiA6IGlvX3Jlc291cmNlLnN0YXJ0ID4+IDEyOiBmZjdjOQ0KPj4+PiAN
Cj4+Pj4gTm90ZSB0aGF0IEkgdGVzdGVkIG9uIFAxMDIyRFMuDQo+IA0KPiANCg==





  

    
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Kumar Gala <hidden>

      Date: 2012-09-27 21:40:17 
    

  

  
On Sep 27, 2012, at 11:27 AM, Li Yang-R58472 wrote:

=20
=D4=DA Sep 28, 2012=A3=AC0:07=A3=AC"Kumar Gala" =
[off-list ref] =D0=B4=B5=C0=A3=BA
=20
quoted
quoted
quoted
quoted
Hi Kumar,
I have already sent the log.
Do you have any comment on it?
=20
Thanks.
- Hongtao.
=20
=20
Hongtao,
=20
You mentioned:
=20
quoted
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.
=20
What do the values look like in both ATMU registers and io_resource =
if you reparse?
quoted
quoted
=20
I think Hongtao mentioned in previous email as follows, the ATMU
registers are inline with the io_resource address.
=20
I was under that the impression that was the normal boot case, not =
the values from after wakeup.
=20
It is for the normal boot.  But re-parse will use the io resource =
after pic scan to initialize atmu.  Instead, the original atmu is =
initialized use the io resource before the scan.
=20
Leo
I think I see, so isn't the mem resources also wrong?

Can we dump the following:

1. enable pr_debug() in pcibios_setup_phb_resources so we get "PHB: " =
prints
2. Can we dump hose->io_resource & hose->mem_resources[] right after =
wakeup?

I think I see what direction but would be useful to get a few more =
answers.

- k=





  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Jia Hongtao-B38951 <hidden>

      Date: 2012-09-28 02:57:16 
    

  

  
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, September 28, 2012 5:38 AM
To: Li Yang-R58472
Cc: Jia Hongtao-B38951; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support


On Sep 27, 2012, at 11:27 AM, Li Yang-R58472 wrote:

quoted
在 Sep 28, 2012，0:07，"Kumar Gala" [off-list ref] 写道：

quoted
quoted
quoted
quoted
Hi Kumar,
I have already sent the log.
Do you have any comment on it?

Thanks.
- Hongtao.
Hongtao,

You mentioned:

quoted
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.
What do the values look like in both ATMU registers and io_resource
if you reparse?
quoted
quoted
quoted
I think Hongtao mentioned in previous email as follows, the ATMU
registers are inline with the io_resource address.
I was under that the impression that was the normal boot case, not the
values from after wakeup.
quoted
It is for the normal boot.  But re-parse will use the io resource after
pic scan to initialize atmu.  Instead, the original atmu is initialized
use the io resource before the scan.
quoted
Leo
I think I see, so isn't the mem resources also wrong?

Can we dump the following:

1. enable pr_debug() in pcibios_setup_phb_resources so we get "PHB: "
prints 2. Can we dump hose->io_resource & hose->mem_resources[] right
after wakeup?

I think I see what direction but would be useful to get a few more
answers.

- k
I enable pr_debug() on these three files:
arch/powerpc/sysdev/fsl_pci.c
arch/powerpc/kernel/pci-common.c
arch/powerpc/kernel/pci_32.c

Also I print the io_resource and mem_resources after wakeup.
(actually pr_debug already done this)

You can see that io resource is changed after pci scan in normal boot.

To see the log please refer to the attachment.

- Hongtao.






  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Jia Hongtao-B38951 <hidden>

      Date: 2012-10-19 04:15:28 
    

  

  
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Thursday, September 27, 2012 8:06 PM
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support
=20
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

quoted
Power supply for PCI inbound/outbound window registers is
off when system go to deep-sleep state. We save the values
of registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree
method?
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
- k
I tested the re-parsing way by using setup_pci_atmu() when
resume.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
And I found out that re-parsing will *change* outbound IO
translation address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource,
but atmu is not updated according to the new hose->io_resource
value.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
In resume from sleep setup_atmu() will reset atmu according to
the new hose->io_resource value. So the setup_atmu() will
cause different result on outbound IO register between first
bootup and resume from sleep.

So... There's a possibility that in the first bootup atmu is
not setup properly.
[Are you seeing this happen in your testing?  If so its a bug
we need
to look at fixing.]
quoted
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep in
both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need
outbound IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup)
is right
and ATMU is not setup
quoted
properly at the first bootup.
Are you seeing the following message - "PCI: I/O resource not
set for host bridge" ?
No.

quoted
Trying to understand why you'd hit the reassignment of
io_resource.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
- k
I did some investigations and the conclusion is:

io_resource.flags & IORESOURCE_IO are both positive but
io_resource.start is 0 before pcibios_setup_phb_io_space() is done=
.
quoted
quoted
quoted
quoted
quoted
quoted
The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() ->
pcibios_setup_phb_io_space()

Because fsl_add_bridge() must be finished before pcibios_init()
so ATMU is set when io_resource.start is 0. That means outbound
IO regs are not set.

If system re-setup ATMU the io_resource.start has already updated
so outbound IO regs are set.

My question is:
Is there any problem if outbound IO regs are not set in first
bootup?
quoted
Yes, it means that IO transactions would not work.
I agree.

quoted
quoted
quoted
Please also provide the IO resource address range before and after
the pci scan.  Then we can evaluate if the range is needed to be
mapped
via
quoted
quoted
ATMU.

Leo
Since potar is set by out_be32(&pci->pow[j].potar, (hose-
io_resource.start >> 12);  I provide the result of
hose->io_resource.start >> 12 as follows:

pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7ed

pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7db

pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7c9

Note that I tested on P1022DS.

- Hongtao.
1. What's the device tree nodes for PCIe look like?
2. Can you get the pr_debug() in setup_pci_atmu() to print and
report results (as well as full boot log)
Please refer to the attached file.
In the log file I also print the device tree.

- Hongtao.

quoted
However, I think the change of the io_resource.start is normal and
correct behavior.

- k
Hi Kumar,
I have already sent the log.
Do you have any comment on it?

Thanks.
- Hongtao.
=20
Hongtao,
=20
You mentioned:
=20
quoted
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO translation
address regitster.
=20
What do the values look like in both ATMU registers and io_resource if
you reparse?
=20
- k

Hi Kumar,

About this topic do you have any further comments?

Thanks.
- Hongtao.





  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Jia Hongtao-B38951 <hidden>

      Date: 2012-10-24 02:09:40 
    

  

  
Hi Kumar,

This PCI controller PM thing is pending for nearly a month without
further discussion. Maybe it's time now to reach an agreement.

- Hongtao.



-----Original Message-----
From: Jia Hongtao-B38951
Sent: Friday, October 19, 2012 12:15 PM
To: 'Kumar Gala'
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support
=20
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Thursday, September 27, 2012 8:06 PM
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support

quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

quoted
Power supply for PCI inbound/outbound window registers is
off when system go to deep-sleep state. We save the values
of registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree
method?
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
- k
I tested the re-parsing way by using setup_pci_atmu() when
resume.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
And I found out that re-parsing will *change* outbound IO
translation address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update hose->io_resource,
but atmu is not updated according to the new
hose->io_resource
value.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
In resume from sleep setup_atmu() will reset atmu according
to the new hose->io_resource value. So the setup_atmu() will
cause different result on outbound IO register between first
bootup and resume from sleep.

So... There's a possibility that in the first bootup atmu is
not setup properly.
[Are you seeing this happen in your testing?  If so its a bug
we need
to look at fixing.]
quoted
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from sleep
in both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need
outbound IO
resource)
quoted
So, I guess the result of re-parsing (actually it's re-setup)
is right
and ATMU is not setup
quoted
properly at the first bootup.
Are you seeing the following message - "PCI: I/O resource not
set for host bridge" ?
No.

quoted
Trying to understand why you'd hit the reassignment of
io_resource.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
- k
I did some investigations and the conclusion is:

io_resource.flags & IORESOURCE_IO are both positive but
io_resource.start is 0 before pcibios_setup_phb_io_space() is
done.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() ->
pcibios_setup_phb_io_space()

Because fsl_add_bridge() must be finished before pcibios_init()
so ATMU is set when io_resource.start is 0. That means outbound
IO regs are not set.

If system re-setup ATMU the io_resource.start has already
updated so outbound IO regs are set.

My question is:
Is there any problem if outbound IO regs are not set in first
bootup?
quoted
Yes, it means that IO transactions would not work.
I agree.

quoted
quoted
quoted
Please also provide the IO resource address range before and
after the pci scan.  Then we can evaluate if the range is needed
to be mapped
via
quoted
quoted
ATMU.

Leo
Since potar is set by out_be32(&pci->pow[j].potar, (hose-
io_resource.start >> 12);  I provide the result of
hose->io_resource.start >> 12 as follows:

pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7ed

pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7db

pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7c9

Note that I tested on P1022DS.

- Hongtao.
1. What's the device tree nodes for PCIe look like?
2. Can you get the pr_debug() in setup_pci_atmu() to print and
report results (as well as full boot log)
Please refer to the attached file.
In the log file I also print the device tree.

- Hongtao.

quoted
However, I think the change of the io_resource.start is normal and
correct behavior.

- k
Hi Kumar,
I have already sent the log.
Do you have any comment on it?

Thanks.
- Hongtao.
Hongtao,

You mentioned:

quoted
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.
What do the values look like in both ATMU registers and io_resource if
you reparse?

- k
=20
=20
Hi Kumar,
=20
About this topic do you have any further comments?
=20
Thanks.
- Hongtao.





  

    
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

    

      From: Jia Hongtao-B38951 <hidden>

      Date: 2012-10-30 03:04:17 
    

  

  
Hi Kumar,

Since PCI controller PM support is inactive for a long while I'd
like to submit a new patch using re-setup atmu to restore PCI states.
Maybe the outbound IO issue during first bootup will be discussed
later when you have time.

- Hongtao.

-----Original Message-----
From: Jia Hongtao-B38951
Sent: Wednesday, October 24, 2012 9:59 AM
To: Jia Hongtao-B38951; Kumar Gala
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support
=20
Hi Kumar,
=20
This PCI controller PM thing is pending for nearly a month without
further discussion. Maybe it's time now to reach an agreement.
=20
- Hongtao.
=20
=20
=20
quoted
-----Original Message-----
From: Jia Hongtao-B38951
Sent: Friday, October 19, 2012 12:15 PM
To: 'Kumar Gala'
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
support

quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Thursday, September 27, 2012 8:06 PM
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound
PM support

quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:

quoted
Power supply for PCI inbound/outbound window registers
is off when system go to deep-sleep state. We save the
values of registers
before
quoted
quoted
quoted
quoted
suspend and restore to registers after resume.

Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changes for V4:
We just rebase the patch upon following patch:
powerpc/fsl-pci: Unify pci/pcie initialization code

arch/powerpc/include/asm/pci-bridge.h |    2 +-
arch/powerpc/sysdev/fsl_pci.c         |  121
+++++++++++++++++++++++++++++++++
quoted
2 files changed, 122 insertions(+), 1 deletions(-)
Did you ever compare this to just re-parsing device tree
method?
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
- k
I tested the re-parsing way by using setup_pci_atmu() when
resume.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
And I found out that re-parsing will *change* outbound IO
translation address regitster.

It seems that in the first bootup, after setup_atmu()
pcibios_setup_phb_resources() may update
hose->io_resource, but atmu is not updated according to
the new
hose->io_resource
value.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
In resume from sleep setup_atmu() will reset atmu
according to the new hose->io_resource value. So the
setup_atmu() will cause different result on outbound IO
register between first bootup and resume from sleep.

So... There's a possibility that in the first bootup atmu
is not setup properly.
[Are you seeing this happen in your testing?  If so its a
bug we need
to look at fixing.]
quoted
Yes, I see this in my testing.
Also PCIe ethernet card works well after resuming from
sleep in both
save/restore
quoted
and re-parsing way. (Maybe PCIe ethernet card don't need
outbound IO
resource)
quoted
So, I guess the result of re-parsing (actually it's
re-setup) is right
and ATMU is not setup
quoted
properly at the first bootup.
Are you seeing the following message - "PCI: I/O resource
not set for host bridge" ?
No.

quoted
Trying to understand why you'd hit the reassignment of
io_resource.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
- k
I did some investigations and the conclusion is:

io_resource.flags & IORESOURCE_IO are both positive but
io_resource.start is 0 before pcibios_setup_phb_io_space() is
done.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() ->
pcibios_setup_phb_io_space()

Because fsl_add_bridge() must be finished before
pcibios_init() so ATMU is set when io_resource.start is 0.
That means outbound IO regs are not set.

If system re-setup ATMU the io_resource.start has already
updated so outbound IO regs are set.

My question is:
Is there any problem if outbound IO regs are not set in first
bootup?
quoted
Yes, it means that IO transactions would not work.
I agree.

quoted
quoted
quoted
Please also provide the IO resource address range before and
after the pci scan.  Then we can evaluate if the range is
needed to be mapped
via
quoted
quoted
ATMU.

Leo
Since potar is set by out_be32(&pci->pow[j].potar, (hose-
io_resource.start >> 12);  I provide the result of
hose->io_resource.start >> 12 as follows:

pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7ed

pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7db

pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0 after pci scan :
io_resource.start >> 12: ff7c9

Note that I tested on P1022DS.

- Hongtao.
1. What's the device tree nodes for PCIe look like?
2. Can you get the pr_debug() in setup_pci_atmu() to print and
report results (as well as full boot log)
Please refer to the attached file.
In the log file I also print the device tree.

- Hongtao.

quoted
However, I think the change of the io_resource.start is normal
and correct behavior.

- k
Hi Kumar,
I have already sent the log.
Do you have any comment on it?

Thanks.
- Hongtao.
Hongtao,

You mentioned:

quoted
I tested the re-parsing way by using setup_pci_atmu() when resume.
And I found out that re-parsing will *change* outbound IO
translation address regitster.
What do the values look like in both ATMU registers and io_resource
if you reparse?

- k

Hi Kumar,

About this topic do you have any further comments?

Thanks.
- Hongtao.




    
  

  
    

      

        Keyboard shortcuts
      

      

        
          
hback out one level

          
jnext message in thread

          
kprevious message in thread

          
ldrill in

          
Escclose help / fold thread tree

          
?toggle this help