* [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
@ 2012-09-18 2:10 Jia Hongtao
2012-09-18 5:03 ` Kumar Gala
0 siblings, 1 reply; 21+ messages in thread
From: Jia Hongtao @ 2012-09-18 2:10 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: B07421, b38951
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 <b14898@freescale.com>
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-18 2:10 [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support Jia Hongtao
@ 2012-09-18 5:03 ` Kumar Gala
2012-09-19 7:10 ` Jia Hongtao-B38951
0 siblings, 1 reply; 21+ messages in thread
From: Kumar Gala @ 2012-09-18 5:03 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev
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 <b14898@freescale.com>
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> 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=
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-18 5:03 ` Kumar Gala
@ 2012-09-19 7:10 ` Jia Hongtao-B38951
2012-09-19 14:27 ` Kumar Gala
0 siblings, 1 reply; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-09-19 7:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
> -----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
> > 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 <b14898@freescale.com>
> > Signed-off-by: Jia Hongtao <B38951@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
> > 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(-)
>=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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-19 7:10 ` Jia Hongtao-B38951
@ 2012-09-19 14:27 ` Kumar Gala
2012-09-19 15:41 ` Jia Hongtao-B38951
0 siblings, 1 reply; 21+ messages in thread
From: Kumar Gala @ 2012-09-19 14:27 UTC (permalink / raw)
To: Jia Hongtao-B38951; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
On Sep 19, 2012, at 2:10 AM, Jia Hongtao-B38951 wrote:
>=20
>=20
>> -----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
>>> 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 <b14898@freescale.com>
>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> ---
>>> 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(-)
>>=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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-19 14:27 ` Kumar Gala
@ 2012-09-19 15:41 ` Jia Hongtao-B38951
2012-09-19 15:49 ` Kumar Gala
0 siblings, 1 reply; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-09-19 15:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
=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=
>> -----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=
>>> 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=
>>> suspend and restore to registers after resume.=0A=
>>>=0A=
>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>=0A=
>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>=0A=
>>> Signed-off-by: Li Yang <leoli@freescale.com>=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=
>>> 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=
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-19 15:41 ` Jia Hongtao-B38951
@ 2012-09-19 15:49 ` Kumar Gala
2012-09-21 3:13 ` Jia Hongtao-B38951
0 siblings, 1 reply; 21+ messages in thread
From: Kumar Gala @ 2012-09-19 15:49 UTC (permalink / raw)
To: Jia Hongtao-B38951; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
>>> On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
>>>=20
>>>> 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 <b14898@freescale.com>
>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>> ---
>>>> 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(-)
>>>=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.
>=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
>>=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.
>=20
>=20
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-19 15:49 ` Kumar Gala
@ 2012-09-21 3:13 ` Jia Hongtao-B38951
2012-09-21 3:50 ` Li Yang-R58472
0 siblings, 1 reply; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-09-21 3:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
> -----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
> >>> 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.
> >>>>
> >>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> >>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> >>>> Signed-off-by: Li Yang <leoli@freescale.com>
> >>>> ---
> >>>> 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(-)
> >>>
> >>> 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.]
> >
> > 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.
>=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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-21 3:13 ` Jia Hongtao-B38951
@ 2012-09-21 3:50 ` Li Yang-R58472
2012-09-21 5:15 ` Jia Hongtao-B38951
0 siblings, 1 reply; 21+ messages in thread
From: Li Yang-R58472 @ 2012-09-21 3:50 UTC (permalink / raw)
To: Jia Hongtao-B38951, Kumar Gala; +Cc: Wood Scott-B07421, linuxppc-dev
> -----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
> > -----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
> >
> > >>> 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.
> > >>>>
> > >>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> > >>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> > >>>> Signed-off-by: Li Yang <leoli@freescale.com>
> > >>>> ---
> > >>>> 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(-)
> > >>>
> > >>> 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.]
> > >
> > > 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" ?
>=20
> No.
>=20
> >
> > 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-21 3:50 ` Li Yang-R58472
@ 2012-09-21 5:15 ` Jia Hongtao-B38951
2012-09-21 13:15 ` Kumar Gala
0 siblings, 1 reply; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-09-21 5:15 UTC (permalink / raw)
To: Li Yang-R58472, Kumar Gala; +Cc: Wood Scott-B07421, linuxppc-dev
> -----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
> > -----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
> >
> >
> >
> > > -----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
> > >
> > > >>> 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.
> > > >>>>
> > > >>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> > > >>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> > > >>>> Signed-off-by: Li Yang <leoli@freescale.com>
> > > >>>> ---
> > > >>>> 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(-)
> > > >>>
> > > >>> 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.]
> > > >
> > > > 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" ?
> >
> > No.
> >
> > >
> > > 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-21 5:15 ` Jia Hongtao-B38951
@ 2012-09-21 13:15 ` Kumar Gala
2012-09-24 2:47 ` Jia Hongtao-B38951
0 siblings, 1 reply; 21+ messages in thread
From: Kumar Gala @ 2012-09-21 13:15 UTC (permalink / raw)
To: Jia Hongtao-B38951; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
>>>>>>>=20
>>>>>>> On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
>>>>>>>=20
>>>>>>>> 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 <b14898@freescale.com>
>>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>>>>> ---
>>>>>>>> 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(-)
>>>>>>>=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.
>>>>>=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.
>>>>=20
>>>> Are you seeing the following message - "PCI: I/O resource not set
>>>> for host bridge" ?
>>>=20
>>> No.
>>>=20
>>>>=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.
>> 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
>=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
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-21 13:15 ` Kumar Gala
@ 2012-09-24 2:47 ` Jia Hongtao-B38951
2012-09-27 2:58 ` Jia Hongtao-B38951
0 siblings, 1 reply; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-09-24 2:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
[-- Attachment #1: Type: text/plain, Size: 4972 bytes --]
> -----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
>
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> >>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> >>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
> >>>>>>>> ---
> >>>>>>>> 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(-)
> >>>>>>>
> >>>>>>> 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.]
> >>>>>
> >>>>> 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" ?
> >>>
> >>> No.
> >>>
> >>>>
> >>>> 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.
>
> >> 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
> >
> > 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
>
[-- Attachment #2: pci_pm_setup_pci_atmu_debug.log --]
[-- Type: application/octet-stream, Size: 55671 bytes --]
U-Boot 2009.11-00132-gd404dfa (Sep 26 2010 - 14:57:28)
CPU0: P1022E, Version: 1.0, (0x80ee0010)
Core: E500, Version: 5.0, (0x80211050)
Clock Configuration:
CPU0:1199.988 MHz, CPU1:1199.988 MHz,
CCB:599.994 MHz,
DDR:399.996 MHz (799.992 MT/s data rate) (Asynchronous), LBC:37.500 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: P1022DS Sys ID: 0x19, Sys Ver: 0x03, FPGA Ver: 0x09, vBank: 0
I2C: ready
SPI: ready
DRAM: Initializing.... DDR: 2 GB (DDR3, 64-bit, CL=6, ECC off)
Now running in RAM - U-Boot at: 7ff30000
FLASH: 128 MB
L2: 256 KB enabled
NAND: 1024 MiB
MMC: FSL_ESDHC: 0
EEPROM: NXID v0
PCIE1 connected to Slot 1 as Root Complex (base addr ffe0a000)
PCIE1 on bus 00 - 00
PCIE2 connected to Slot 3 as Root Complex (base addr ffe09000)
PCIE2 on bus 01 - 01
PCIE3 connected to Slot 2 as Root Complex (base addr ffe0b000)
PCIE3 on bus 02 - 02
In: serial
Out: serial
Err: serial
Net: eTSEC1, eTSEC2
Hit any key to stop autoboot: 0
=> setenv fdtprint "tftp $fdtaddr $fdtfile;fdt addr $fdtaddr;fdt boardsetup;fdt print"
=> sav
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... 9....8....7....6....5....4....3....2....1....done
Protected 1 sectors
=> run fdtprint
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/p1022ds_32b.dtb'.
Load address: 0xc00000
Loading: ###
done
Bytes transferred = 14645 (3935 hex)
/ {
compatible = "fsl,P1022DS";
#address-cells = <0x2>;
#size-cells = <0x2>;
interrupt-parent = <0x1>;
model = "fsl,P1022DS";
cpus {
power-isa-version = "2.03";
power-isa-b;
power-isa-e;
power-isa-atb;
power-isa-cs;
power-isa-e.le;
power-isa-e.pm;
power-isa-ecl;
power-isa-mmc;
power-isa-sp;
power-isa-sp.fd;
power-isa-sp.fs;
power-isa-sp.fv;
mmu-type = "power-embedded";
#address-cells = <0x1>;
#size-cells = <0x0>;
PowerPC,P1022@0 {
i-cache-sets = <0x80>;
i-cache-size = <0x8000>;
i-cache-block-size = <0x20>;
d-cache-sets = <0x80>;
d-cache-size = <0x8000>;
d-cache-block-size = <0x20>;
status = "okay";
clock-frequency = <0x47865d2c>;
bus-frequency = <0x23c32e96>;
timebase-frequency = <0x47865d3>;
device_type = "cpu";
reg = <0x0>;
next-level-cache = <0x2>;
};
PowerPC,P1022@1 {
i-cache-sets = <0x80>;
i-cache-size = <0x8000>;
i-cache-block-size = <0x20>;
d-cache-sets = <0x80>;
d-cache-size = <0x8000>;
d-cache-block-size = <0x20>;
cpu-release-addr = <0x0 0x7ffff2a0>;
enable-method = "spin-table";
status = "disabled";
clock-frequency = <0x47865d2c>;
bus-frequency = <0x23c32e96>;
timebase-frequency = <0x47865d3>;
device_type = "cpu";
reg = <0x1>;
next-level-cache = <0x2>;
};
};
aliases {
serial0 = "/soc@ffe00000/serial@4500";
serial1 = "/soc@ffe00000/serial@4600";
ethernet0 = "/soc@ffe00000/ethernet@b0000";
ethernet1 = "/soc@ffe00000/ethernet@b1000";
pci0 = "/pcie@ffe09000";
pci1 = "/pcie@ffe0a000";
pci2 = "/pcie@ffe0b000";
};
memory {
reg = <0x0 0x0 0x0 0x80000000>;
device_type = "memory";
};
localbus@ffe05000 {
bus-frequency = <0x23c32e9>;
reg = <0x0 0xffe05000 0x0 0x1000>;
ranges = <0x0 0x0 0x0 0xe8000000 0x8000000 0x1 0x0 0x0 0xe0000000 0x8000000 0x2 0x0 0x0 0xff800000 0x40000 0x3 0x0 0x0 0xffdf0000 0x8000>;
#address-cells = <0x2>;
#size-cells = <0x1>;
compatible = "fsl,p1022-elbc", "fsl,elbc";
interrupts = <0x13 0x2 0x0 0x0>;
board-control@0,0 {
compatible = "fsl,p1022ds-indirect-pixis";
reg = <0x0 0x0 0x1 0x1 0x0 0x1>;
interrupt-parent = <0x1>;
interrupts = <0x8 0x0 0x0 0x0>;
};
nor@0,0 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "cfi-flash";
reg = <0x0 0x0 0x8000000>;
bank-width = <0x2>;
device-width = <0x1>;
partition@0 {
reg = <0x0 0x3000000>;
label = "ramdisk-nor";
read-only;
};
partition@3000000 {
reg = <0x3000000 0xe00000>;
label = "diagnostic-nor";
read-only;
};
partition@3e00000 {
reg = <0x3e00000 0x200000>;
label = "dink-nor";
read-only;
};
partition@4000000 {
reg = <0x4000000 0x400000>;
label = "kernel-nor";
read-only;
};
partition@4400000 {
reg = <0x4400000 0x3b00000>;
label = "jffs2-nor";
};
partition@7f00000 {
reg = <0x7f00000 0x80000>;
label = "dtb-nor";
read-only;
};
partition@7f80000 {
reg = <0x7f80000 0x80000>;
label = "u-boot-nor";
read-only;
};
};
nand@2,0 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "fsl,elbc-fcm-nand";
reg = <0x2 0x0 0x40000>;
partition@0 {
reg = <0x0 0x2000000>;
label = "u-boot-nand";
read-only;
};
partition@2000000 {
reg = <0x2000000 0x10000000>;
label = "jffs2-nand";
};
partition@12000000 {
reg = <0x12000000 0x10000000>;
label = "ramdisk-nand";
read-only;
};
partition@22000000 {
reg = <0x22000000 0x4000000>;
label = "kernel-nand";
};
partition@26000000 {
reg = <0x26000000 0x1000000>;
label = "dtb-nand";
read-only;
};
partition@27000000 {
reg = <0x27000000 0x19000000>;
label = "reserved-nand";
};
};
board-control@3,0 {
compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
reg = <0x3 0x0 0x30>;
interrupt-parent = <0x1>;
interrupts = <0x8 0x0 0x0 0x0>;
};
};
soc@ffe00000 {
ranges = <0x0 0x0 0xffe00000 0x100000>;
#address-cells = <0x1>;
#size-cells = <0x1>;
device_type = "soc";
compatible = "fsl,p1022-immr", "simple-bus";
bus-frequency = <0x23c32e96>;
ecm-law@0 {
compatible = "fsl,ecm-law";
reg = <0x0 0x1000>;
fsl,num-laws = <0xc>;
};
ecm@1000 {
compatible = "fsl,p1022-ecm", "fsl,ecm";
reg = <0x1000 0x1000>;
interrupts = <0x10 0x2 0x0 0x0>;
};
memory-controller@2000 {
compatible = "fsl,p1022-memory-controller";
reg = <0x2000 0x1000>;
interrupts = <0x10 0x2 0x0 0x0>;
};
i2c@3000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
cell-index = <0x0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <0x2b 0x2 0x0 0x0>;
dfsrr;
};
i2c@3100 {
#address-cells = <0x1>;
#size-cells = <0x0>;
cell-index = <0x1>;
compatible = "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <0x2b 0x2 0x0 0x0>;
dfsrr;
codec@1a {
compatible = "wlf,wm8776";
reg = <0x1a>;
linux,phandle = <0x5>;
phandle = <0x5>;
};
rtc@68 {
compatible = "dallas,ds1339";
reg = <0x68>;
};
adt7461@4c {
compatible = "adi,adt7461";
reg = <0x4c>;
};
};
serial@4500 {
cell-index = <0x0>;
device_type = "serial";
compatible = "fsl,ns16550", "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0x23c32e96>;
interrupts = <0x2a 0x2 0x0 0x0>;
};
serial@4600 {
cell-index = <0x1>;
device_type = "serial";
compatible = "fsl,ns16550", "ns16550";
reg = <0x4600 0x100>;
clock-frequency = <0x23c32e96>;
interrupts = <0x2a 0x2 0x0 0x0>;
};
spi@7000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
interrupts = <0x3b 0x2 0x0 0x0>;
fsl,espi-num-chipselects = <0x4>;
flash@0 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "spansion,s25sl12801";
reg = <0x0>;
spi-max-frequency = <0x2625a00>;
partition@0 {
label = "u-boot-spi";
reg = <0x0 0x100000>;
read-only;
};
partition@100000 {
label = "kernel-spi";
reg = <0x100000 0x500000>;
read-only;
};
partition@600000 {
label = "dtb-spi";
reg = <0x600000 0x100000>;
read-only;
};
partition@700000 {
label = "file system-spi";
reg = <0x700000 0x900000>;
};
};
slic@0 {
compatible = "zarlink,le88266";
reg = <0x1>;
spi-max-frequency = <0x7a1200>;
};
slic@1 {
compatible = "zarlink,le88266";
reg = <0x2>;
spi-max-frequency = <0x7a1200>;
};
};
dma@c300 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "fsl,eloplus-dma";
reg = <0xc300 0x4>;
ranges = <0x0 0xc100 0x200>;
cell-index = <0x1>;
dma-channel@0 {
compatible = "fsl,ssi-dma-channel";
reg = <0x0 0x80>;
cell-index = <0x0>;
interrupts = <0x4c 0x2 0x0 0x0>;
linux,phandle = <0x3>;
phandle = <0x3>;
};
dma-channel@80 {
compatible = "fsl,ssi-dma-channel";
reg = <0x80 0x80>;
cell-index = <0x1>;
interrupts = <0x4d 0x2 0x0 0x0>;
linux,phandle = <0x4>;
phandle = <0x4>;
};
dma-channel@100 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
cell-index = <0x2>;
interrupts = <0x4e 0x2 0x0 0x0>;
};
dma-channel@180 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
cell-index = <0x3>;
interrupts = <0x4f 0x2 0x0 0x0>;
};
};
gpio-controller@f000 {
#gpio-cells = <0x2>;
compatible = "fsl,pq3-gpio";
reg = <0xf000 0x100>;
interrupts = <0x2f 0x2 0x0 0x0>;
gpio-controller;
};
display@10000 {
compatible = "fsl,diu", "fsl,p1022-diu";
reg = <0x10000 0x3e8>;
interrupts = <0x40 0x2 0x0 0x0>;
};
ssi@15000 {
compatible = "fsl,mpc8610-ssi";
cell-index = <0x0>;
reg = <0x15000 0x100>;
interrupts = <0x4b 0x2 0x0 0x0>;
fsl,playback-dma = <0x3>;
fsl,capture-dma = <0x4>;
fsl,fifo-depth = <0xf>;
fsl,mode = "i2s-slave";
codec-handle = <0x5>;
fsl,ssi-asynchronous;
};
tdm@16000 {
compatible = "fsl,tdm1.0";
reg = <0x16000 0x200 0x2c000 0x2000>;
clock-frequency = <0x0>;
interrupts = <0x3e 0x8 0x0 0x0>;
fsl,max-time-slots = <0x80>;
};
sata@18000 {
compatible = "fsl,pq-sata-v2";
reg = <0x18000 0x1000>;
cell-index = <0x1>;
interrupts = <0x4a 0x2 0x0 0x0>;
};
sata@19000 {
compatible = "fsl,pq-sata-v2";
reg = <0x19000 0x1000>;
cell-index = <0x2>;
interrupts = <0x29 0x2 0x0 0x0>;
};
l2-cache-controller@20000 {
cache-level = <0x2>;
cache-sets = <0x400>;
cache-block-size = <0x20>;
cache-unified;
compatible = [66 73 6c 2c 70 31 30 32 32 2d 6c 32 2d 63 61 63 68 65 2d 63 6f 6e 74 72 6f 6c 6c 65 72 00 63 61 63 68 65 00 7f fa];
reg = <0x20000 0x1000>;
cache-line-size = <0x20>;
cache-size = <0x40000>;
interrupts = <0x10 0x2 0x0 0x0>;
linux,phandle = <0x2>;
phandle = <0x2>;
};
dma@21300 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "fsl,eloplus-dma";
reg = <0x21300 0x4>;
ranges = <0x0 0x21100 0x200>;
cell-index = <0x0>;
dma-channel@0 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x0 0x80>;
cell-index = <0x0>;
interrupts = <0x14 0x2 0x0 0x0>;
};
dma-channel@80 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
cell-index = <0x1>;
interrupts = <0x15 0x2 0x0 0x0>;
};
dma-channel@100 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
cell-index = <0x2>;
interrupts = <0x16 0x2 0x0 0x0>;
};
dma-channel@180 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
cell-index = <0x3>;
interrupts = <0x17 0x2 0x0 0x0>;
};
};
usb@22000 {
compatible = "fsl-usb2-dr-v1.6", "fsl-usb2-dr";
reg = <0x22000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
interrupts = <0x1c 0x2 0x0 0x0>;
phy_type = "ulpi";
};
usb@23000 {
compatible = "fsl-usb2-dr-v1.6", "fsl-usb2-dr";
reg = <0x23000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
interrupts = <0x2e 0x2 0x0 0x0>;
status = "disabled";
};
sdhc@2e000 {
status = "disabled";
compatible = "fsl,p1022-esdhc", "fsl,esdhc";
reg = <0x2e000 0x1000>;
interrupts = <0x48 0x2 0x0 0x0>;
clock-frequency = <0x0>;
sdhci,auto-cmd12;
};
crypto@30000 {
compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
reg = <0x30000 0x10000>;
interrupts = <0x2d 0x2 0x0 0x0 0x3a 0x2 0x0 0x0>;
fsl,num-channels = <0x4>;
fsl,channel-fifo-len = <0x18>;
fsl,exec-units-mask = <0x97c>;
fsl,descriptor-types-mask = <0x3a30abf>;
};
pic@40000 {
interrupt-controller;
#address-cells = <0x0>;
#interrupt-cells = <0x4>;
reg = <0x40000 0x40000>;
compatible = "fsl,mpic";
device_type = "open-pic";
linux,phandle = <0x1>;
phandle = <0x1>;
};
timer@41100 {
compatible = "fsl,mpic-global-timer";
reg = <0x41100 0x100 0x41300 0x4>;
interrupts = <0x0 0x0 0x3 0x0 0x1 0x0 0x3 0x0 0x2 0x0 0x3 0x0 0x3 0x0 0x3 0x0>;
};
msi@41600 {
compatible = "fsl,mpic-msi";
reg = <0x41600 0x80>;
msi-available-ranges = <0x0 0x100>;
interrupts = <0xe0 0x0 0x0 0x0 0xe1 0x0 0x0 0x0 0xe2 0x0 0x0 0x0 0xe3 0x0 0x0 0x0 0xe4 0x0 0x0 0x0 0xe5 0x0 0x0 0x0 0xe6 0x0 0x0 0x0 0xe7 0x0 0x0 0x0>;
};
timer@42100 {
compatible = "fsl,mpic-global-timer";
reg = <0x42100 0x100 0x42300 0x4>;
interrupts = <0x4 0x0 0x3 0x0 0x5 0x0 0x3 0x0 0x6 0x0 0x3 0x0 0x7 0x0 0x3 0x0>;
};
mdio@24000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,etsec2-mdio";
reg = <0x24000 0x1000 0xb0030 0x4>;
ethernet-phy@0 {
interrupts = <0x3 0x1 0x0 0x0>;
reg = <0x1>;
linux,phandle = <0x7>;
phandle = <0x7>;
};
ethernet-phy@1 {
interrupts = <0x9 0x1 0x0 0x0>;
reg = <0x2>;
linux,phandle = <0xa>;
phandle = <0xa>;
};
tbi-phy@2 {
device_type = "tbi-phy";
reg = <0x2>;
};
};
ethernet@b0000 {
rx-stash-idx = <0x0>;
rx-stash-len = <0x60>;
bd-stash;
#address-cells = <0x1>;
#size-cells = <0x1>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
fsl,magic-packet;
local-mac-address = [00 e0 0c 02 00 fd];
fsl,wake-on-filer;
fsl,pmc-handle = <0x6>;
phy-handle = <0x7>;
phy-connection-type = "rgmii-id";
ptimer-handle = <0x8>;
queue-group@b0000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
reg = <0xb0000 0x1000>;
interrupts = <0x1d 0x2 0x0 0x0 0x1e 0x2 0x0 0x0 0x22 0x2 0x0 0x0>;
};
queue-group@b4000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
reg = <0xb4000 0x1000>;
interrupts = <0x11 0x2 0x0 0x0 0x12 0x2 0x0 0x0 0x18 0x2 0x0 0x0>;
};
};
mdio@25000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,etsec2-tbi";
reg = <0x25000 0x1000 0xb1030 0x4>;
};
ethernet@b1000 {
rx-stash-idx = <0x0>;
rx-stash-len = <0x60>;
bd-stash;
#address-cells = <0x1>;
#size-cells = <0x1>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
fsl,magic-packet;
local-mac-address = [00 e0 0c 02 01 fd];
fsl,wake-on-filer;
fsl,pmc-handle = <0x9>;
phy-handle = <0xa>;
phy-connection-type = "rgmii-id";
ptimer-handle = <0x8>;
queue-group@b1000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
reg = <0xb1000 0x1000>;
interrupts = <0x23 0x2 0x0 0x0 0x24 0x2 0x0 0x0 0x28 0x2 0x0 0x0>;
};
queue-group@b5000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
reg = <0xb5000 0x1000>;
interrupts = <0x33 0x2 0x0 0x0 0x34 0x2 0x0 0x0 0x43 0x2 0x0 0x0>;
};
};
global-utilities@e0000 {
compatible = "fsl,p1022-guts";
reg = <0xe0000 0x1000>;
fsl,has-rstcr;
};
power@e0070 {
compatible = "fsl,p1022-pmc", "fsl,mpc8536-pmc", "fsl,mpc8548-pmc";
reg = <0xe0070 0x20>;
soc-clk@24 {
fsl,pmcdr-mask = <0x80>;
linux,phandle = <0x6>;
phandle = <0x6>;
};
soc-clk@25 {
fsl,pmcdr-mask = <0x40>;
linux,phandle = <0x9>;
phandle = <0x9>;
};
soc-clk@26 {
fsl,pmcdr-mask = <0x20>;
};
};
ptimer@b0e00 {
compatible = "fsl,gianfar-ptp-timer";
reg = <0xb0e00 0xb0>;
fsl,ts-to-buffer;
fsl,tmr-prsc = <0x2>;
fsl,clock-source-select = <0x1>;
linux,phandle = <0x8>;
phandle = <0x8>;
};
};
pcie@ffe09000 {
dma-ranges = <0x2000000 0x0 0xfff00000 0x0 0xffe00000 0x0 0x100000 0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
reg = <0x0 0xffe09000 0x0 0x1000>;
ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x0 0xffc10000 0x0 0x10000>;
compatible = "fsl,p1022-pcie";
device_type = "pci";
#size-cells = <0x2>;
#address-cells = <0x3>;
bus-range = <0x0 0x0>;
clock-frequency = <0x1fca055>;
interrupts = <0x10 0x2 0x0 0x0>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000 0x2000000 0x0 0xe0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x1000000 0x0 0x0 0x0 0x100000>;
reg = <0x0 0x0 0x0 0x0 0x0>;
#interrupt-cells = <0x1>;
#size-cells = <0x2>;
#address-cells = <0x3>;
device_type = "pci";
interrupts = <0x10 0x2 0x0 0x0>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x4 0x1 0x0 0x0 0x0 0x0 0x0 0x2 0x1 0x5 0x1 0x0 0x0 0x0 0x0 0x0 0x3 0x1 0x6 0x1 0x0 0x0 0x0 0x0 0x0 0x4 0x1 0x7 0x1 0x0 0x0>;
};
};
pcie@ffe0a000 {
reg = <0x0 0xffe0a000 0x0 0x1000>;
ranges = <0x2000000 0x0 0xe0000000 0x0 0xc0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x0 0xffc20000 0x0 0x10000>;
compatible = "fsl,p1022-pcie";
device_type = "pci";
#size-cells = <0x2>;
#address-cells = <0x3>;
bus-range = <0x0 0x0>;
clock-frequency = <0x1fca055>;
interrupts = <0x10 0x2 0x0 0x0>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000 0x2000000 0x0 0xe0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x1000000 0x0 0x0 0x0 0x100000>;
reg = <0x0 0x0 0x0 0x0 0x0>;
#interrupt-cells = <0x1>;
#size-cells = <0x2>;
#address-cells = <0x3>;
device_type = "pci";
interrupts = <0x10 0x2 0x0 0x0>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x2 0x1 0x1 0x1 0x0 0x0 0x0 0x0 0x0 0x3 0x1 0x2 0x1 0x0 0x0 0x0 0x0 0x0 0x4 0x1 0x3 0x1 0x0 0x0>;
};
};
pcie@ffe0b000 {
dma-ranges = <0x2000000 0x0 0xfff00000 0x0 0xffe00000 0x0 0x100000 0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
reg = <0x0 0xffe0b000 0x0 0x1000>;
ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000 0x1000000 0x0 0x0 0x0 0xffc00000 0x0 0x10000>;
compatible = "fsl,p1022-pcie";
device_type = "pci";
#size-cells = <0x2>;
#address-cells = <0x3>;
bus-range = <0x0 0x0>;
clock-frequency = <0x1fca055>;
interrupts = <0x10 0x2 0x0 0x0>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000 0x2000000 0x0 0xe0000000 0x0 0x20000000 0x1000000 0x0 0x0 0x1000000 0x0 0x0 0x0 0x100000>;
reg = <0x0 0x0 0x0 0x0 0x0>;
#interrupt-cells = <0x1>;
#size-cells = <0x2>;
#address-cells = <0x3>;
device_type = "pci";
interrupts = <0x10 0x2 0x0 0x0>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x8 0x1 0x0 0x0 0x0 0x0 0x0 0x2 0x1 0x9 0x1 0x0 0x0 0x0 0x0 0x0 0x3 0x1 0xa 0x1 0x0 0x0 0x0 0x0 0x0 0x4 0x1 0xb 0x1 0x0 0x0>;
};
};
};
=>
=>
=>
=> run ramboot
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/ramdisk.small'.
Load address: 0x2000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##############################################################
done
Bytes transferred = 4306189 (41b50d hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/uImage_1022_pm_re_parse_debug'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#######
done
Bytes transferred = 3695062 (3861d6 hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/p1022ds_32b.dtb'.
Load address: 0xc00000
Loading: ###
done
Bytes transferred = 14645 (3935 hex)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.0.43-rt64-01350-g826673b
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 3694998 Bytes = 3.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 4306125 Bytes = 4.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 00c00000
Booting using the fdt blob at 0xc00000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 2fbe4000, end 2ffff4cd ... OK
debug: ignoring loglevel setting.
Using P1022 DS machine description
Memory CAM mapping: 256/256/256 Mb, residual: 1280Mb
Linux version 3.0.43-rt64-01350-g826673b-dirty (jiaht@rock) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-38) ) #67 SMP Mon Sep 24 10:01:40 CST 2012
Found initrd at 0xefbe4000:0xeffff4cd
Found legacy serial port 0 for /soc@ffe00000/serial@4500
mem=ffe04500, taddr=ffe04500, irq=0, clk=599994006, speed=0
Found legacy serial port 1 for /soc@ffe00000/serial@4600
mem=ffe04600, taddr=ffe04600, irq=0, clk=599994006, speed=0
CPU maps initialized for 1 thread per core
(thread shift is 0)
bootconsole [udbg0] enabled
setup_arch: bootmem
p1022_ds_setup_arch()
Adding PCI host bridge /pcie@ffe09000
Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0
->Hose at 0xc0765000, cfg_addr=0xff7fd000,cfg_data=0xff7fd004
PCI host bridge /pcie@ffe09000 ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000e0000000
IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe09000, size 0x0000000000001000
PCI MEM resource start 0x00000000a0000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc10000.
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
Adding PCI host bridge /pcie@ffe0a000
Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->0
->Hose at 0xc07650e0, cfg_addr=0xff7eb000,cfg_data=0xff7eb004
PCI host bridge /pcie@ffe0a000 ranges:
MEM 0x00000000c0000000..0x00000000dfffffff -> 0x00000000e0000000
IO 0x00000000ffc20000..0x00000000ffc2ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe0a000, size 0x0000000000001000
PCI MEM resource start 0x00000000c0000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc20000.
/pcie@ffe0a000: PCICSRBAR @ 0xfff00000
Adding PCI host bridge /pcie@ffe0b000
Found FSL PCI host bridge at 0x00000000ffe0b000. Firmware bus number: 0->0
->Hose at 0xc07651c0, cfg_addr=0xff7d9000,cfg_data=0xff7d9004
PCI host bridge /pcie@ffe0b000 ranges:
MEM 0x0000000080000000..0x000000009fffffff -> 0x00000000e0000000
IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe0b000, size 0x0000000000001000
PCI MEM resource start 0x0000000080000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc00000.
/pcie@ffe0b000: PCICSRBAR @ 0xfff00000
Freescale P1022 DS reference board
arch: exit
Top of RAM: 0x80000000, Total RAM: 0x80000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00030000
Normal empty
HighMem 0x00030000 -> 0x00080000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00080000
On node 0 totalpages: 524288
free_area_init_node: node 0, pgdat c072e380, node_mem_map c0c04000
DMA zone: 1536 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 195072 pages, LIFO batch:31
HighMem zone: 2560 pages used for memmap
HighMem zone: 325120 pages, LIFO batch:31
MMU: Allocated 1088 bytes of context maps for 255 contexts
PERCPU: Embedded 7 pages/cpu @c1c10000 s4768 r8192 d15712 u32768
pcpu-alloc: s4768 r8192 d15712 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 520192
Kernel command line: root=/dev/ram rw console=ttyS0,115200 ramdisk_size=400000 cache-sram-size=0x8000 cache-sram-offset=0xfff00000 no_console_suspend ignore_loglevel
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 1310716k
Memory: 2067952k/2097152k available (7160k kernel code, 29200k reserved, 236k data, 174k bss, 268k init)
Kernel virtual memory layout:
* 0xfff5f000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xff7c7000..0xff800000 : early ioremap
* 0xf1000000..0xff7c7000 : vmalloc & ioremap
SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512 nr_irqs:512 16
mpic: Resetting
mpic: Setting up MPIC " OpenPIC " version 1.2 at ffe40000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
time_init: decrementer frequency = 74.999251 MHz
time_init: processor frequency = 1199.988012 MHz
clocksource: timebase mult[3555784] shift[22] registered
clockevent: decrementer mult[133326a2] shift[32] cpu[0]
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
mpic: requesting IPIs...
Brought up 2 CPUs
NET: Registered protocol family 16
PCI: Probing PCI hardware
pci 0000:00:00.0: [1957:0110] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
pci 0001:02:00.0: [1957:0110] type 1 class 0x000b20
pci 0001:02:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:02:00.0: supports D1 D2
pci 0001:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0001:02:00.0: PME# disabled
pci 0001:02:00.0: PCI bridge to [bus 03-ff]
pci 0001:02:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0001:02:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0001:02:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
pci 0002:04:00.0: [1957:0110] type 1 class 0x000b20
pci 0002:04:00.0: ignoring class b20 (doesn't match header type 01)
pci 0002:04:00.0: supports D1 D2
pci 0002:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0002:04:00.0: PME# disabled
pci 0002:04:00.0: PCI bridge to [bus 05-ff]
pci 0002:04:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0002:04:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0002:04:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
PCI 0000:00 Cannot reserve Legacy IO [io 0xff7ed000-0xff7edfff]
PCI 0001:02 Cannot reserve Legacy IO [io 0xff7db000-0xff7dbfff]
PCI 0002:04 Cannot reserve Legacy IO [io 0xff7c9000-0xff7c9fff]
PCI: max bus depth: 1 pci_try_num: 2
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xff7ed000-0xff7fcfff]
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xbfffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0001:02:00.0: PCI bridge to [bus 03-03]
pci 0001:02:00.0: bridge window [io 0xff7db000-0xff7eafff]
pci 0001:02:00.0: bridge window [mem 0xc0000000-0xdfffffff]
pci 0001:02:00.0: bridge window [mem pref disabled]
pci 0002:04:00.0: PCI bridge to [bus 05-05]
pci 0002:04:00.0: bridge window [io 0xff7c9000-0xff7d8fff]
pci 0002:04:00.0: bridge window [mem 0x80000000-0x9fffffff]
pci 0002:04:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci 0001:02:00.0: enabling device (0106 -> 0107)
pci 0002:04:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:00: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0000:01: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:01: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0001:02: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:02: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0001:03: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:03: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0002:04: resource 0 [io 0xff7c9000-0xff7d8fff]
pci_bus 0002:04: resource 1 [mem 0x80000000-0x9fffffff]
pci_bus 0002:05: resource 0 [io 0xff7c9000-0xff7d8fff]
pci_bus 0002:05: resource 1 [mem 0x80000000-0x9fffffff]
Registering qe_ic with sysfs...
bio: create slab <bio-0> at 0
raid6: int32x1 172 MB/s
raid6: int32x2 301 MB/s
raid6: int32x4 427 MB/s
raid6: int32x8 358 MB/s
raid6: using algorithm int32x4 (427 MB/s)
Freescale Elo / Elo Plus DMA driver
vgaarb: loaded
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.24.
Switching to clocksource timebase
Switched to NOHz mode on CPU #0
Switched to NOHz mode on CPU #1
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 32
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 4208k freed
fsl-elo-dma ffe0c300.dma: #2 (fsl,eloplus-dma-channel), irq 78
fsl-elo-dma ffe0c300.dma: #3 (fsl,eloplus-dma-channel), irq 79
fsl-l2ctlr ffe20000.l2-cache-controller: Entire L2 as cache, provide valid sram address and size
fsl-l2ctlr: probe of ffe20000.l2-cache-controller failed with error -22
fsl-elo-dma ffe21300.dma: #0 (fsl,eloplus-dma-channel), irq 20
fsl-elo-dma ffe21300.dma: #1 (fsl,eloplus-dma-channel), irq 21
fsl-elo-dma ffe21300.dma: #2 (fsl,eloplus-dma-channel), irq 22
fsl-elo-dma ffe21300.dma: #3 (fsl,eloplus-dma-channel), irq 23
Setting up Freescale MSI support
Freescale PowerQUICC MII Bus: probed
fsl-pq_mdio: probe of ffe25000.mdio failed with error -16
Freescale PMC driver
audit: initializing netlink socket (disabled)
type=2000 audit(0.704:1): initialized
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.30 [Flags: R/O].
JFFS2 version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
Allocated 267980 bytes for deflate workspace
Allocated 42284 bytes for inflate workspace
Registering JFFS2 compressor "zlib"
Registering JFFS2 compressor "rtime"
JFFS2: default compression mode: priority
msgmni has been set to 1487
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Freescale DIU driver
Console: switching to colour frame buffer device 128x48
fb0: Panel0 fb device registered successfully.
fb1: fb device registered successfully.
fb2: fb device registered successfully.
fb3: fb device registered successfully.
fb4: fb device registered successfully.
Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 42) is a 16550A
Generic non-volatile memory driver v1.1
brd: module loaded
loop: module loaded
nbd: registered device at major 43
st: Version 20101219, fixed bufsize 32768, s/g segs 256
fsl-sata ffe18000.sata: Sata FSL Platform/CSB Driver init
scsi0 : sata_fsl
ata1: SATA max UDMA/133 irq 74
fsl-sata ffe19000.sata: Sata FSL Platform/CSB Driver init
scsi1 : sata_fsl
ata2: SATA max UDMA/133 irq 41
e8000000.nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002801
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
Creating 7 MTD partitions on "e8000000.nor":
0x000000000000-0x000003000000 : "ramdisk-nor"
ftl_cs: FTL header not found.
0x000003000000-0x000003e00000 : "diagnostic-nor"
ftl_cs: FTL header not found.
0x000003e00000-0x000004000000 : "dink-nor"
ftl_cs: FTL header not found.
0x000004000000-0x000004400000 : "kernel-nor"
ftl_cs: FTL header not found.
0x000004400000-0x000007f00000 : "jffs2-nor"
ftl_cs: FTL header not found.
0x000007f00000-0x000007f80000 : "dtb-nor"
ftl_cs: FTL header not found.
0x000007f80000-0x000008000000 : "u-boot-nor"
ftl_cs: FTL header not found.
fsl-lbc ffe05000.localbus: address did not match any chip selects
m25p80 spi32766.0: s25sl12801 (16384 Kbytes)
Creating 4 MTD partitions on "spi32766.0":
0x000000000000-0x000000100000 : "u-boot-spi"
ftl_cs: FTL header not found.
0x000000100000-0x000000600000 : "kernel-spi"
ftl_cs: FTL header not found.
0x000000600000-0x000000700000 : "dtb-spi"
ftl_cs: FTL header not found.
0x000000700000-0x000001000000 : "file system-spi"
ftl_cs: FTL header not found.
fsl_espi ffe07000.spi: at 0xf1064000 (irq = 59)
Fixed MDIO Bus: probed
e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
fsl-gianfar ethernet.4: eth0: mac: 00:e0:0c:02:00:fd
fsl-gianfar ethernet.4: eth0: Running with NAPI enabled
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[0]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[1]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[2]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[3]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[4]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[5]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[6]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[7]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[0]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[1]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[2]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[3]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[4]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[5]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[6]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[7]: 256
fsl-gianfar ethernet.5: eth1: mac: 00:e0:0c:02:01:fd
fsl-gianfar ethernet.5: eth1: Running with NAPI enabled
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[0]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[1]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[2]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[3]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[4]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[5]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[6]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[7]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[0]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[1]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[2]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[3]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[4]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[5]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[6]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[7]: 256
ucc_geth: QE UCC Gigabit Ethernet Controller
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
/soc@ffe00000/usb@22000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 28, io mem 0xffe22000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mpc-i2c ffe03000.i2c: timeout 1000000 us
mpc-i2c ffe03100.i2c: timeout 1000000 us
EDAC MC: Ver: 2.1.0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
talitos ffe30000.crypto: hwrng
talitos ffe30000.crypto: fsl,sec3.3 algorithms registered in /proc/crypto
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
Freescale Synchronous Serial Interface (SSI) ASoC Driver
snd-soc-p1022ds snd-soc-p1022ds.0: codec bus-frequency property is missing or invalid
snd-soc-p1022ds: probe of snd-soc-p1022ds.0 failed with error -22
ata1: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata1: SATA link down (SStatus 0 SControl 300)
Freescale Elo DMA ASoC PCM Driver
ALSA device list:
No soundcards found.
ata2: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata2: SATA link down (SStatus 0 SControl 300)
IPv4 over IPv4 tunneling driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
Registering the dns_resolver key type
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 268k freed
Mounting /proc and /sys
Setting the hostname to mpc8572ds
Running depmod
WARNING: Couldn't open directory /lib/modules/3.0.43-rt64-01350-g826673b-dirty: No such file or directory
FATAL: Could not open /lib/modules/3.0.43-rt64-01350-g826673b-dirty/modules.dep.temp for writing: No such file or directory
Mounting filesystems
Starting syslogd and klogd
Running sysctl
Setting up networking on loopback device:
Setting up networking on eth0:
ADDRCONF(NETDEV_UP): eth0: link is not ready
Adding static route for default gateway to 192.168.1.1:
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Setting up networking on eth1:
ADDRCONF(NETDEV_UP): eth1: link is not ready
Adding static route for default gateway to 192.168.1.1:
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Starting inetd:
Please set the system time using
date <mmddhhmnyyyy>
/sbin/hwclock -w
Welcome to Freescale Semiconductor Embedded Linux Environment
!!!!! WARNING !!!!!!!
The default password for the root account is: root
please change this password using the 'passwd' command
and then edit this message (/etc/issue) to remove this message
mpc8572ds login: PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present
Welcome to Freescale Semiconductor Embedded Linux Environment
!!!!! WARNING !!!!!!!
The default password for the root account is: root
please change this password using the 'passwd' command
and then edit this message (/etc/issue) to remove this message
mpc8572ds login:
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-24 2:47 ` Jia Hongtao-B38951
@ 2012-09-27 2:58 ` Jia Hongtao-B38951
2012-09-27 12:05 ` Kumar Gala
0 siblings, 1 reply; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-09-27 2:58 UTC (permalink / raw)
To: Jia Hongtao-B38951, Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
> -----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
> > -----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
> >
> > >>>>>>>
> > >>>>>>> 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.
> > >>>>>>>>
> > >>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> > >>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> > >>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
> > >>>>>>>> ---
> > >>>>>>>> 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(-)
> > >>>>>>>
> > >>>>>>> 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.]
> > >>>>>
> > >>>>> 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" ?
> > >>>
> > >>> No.
> > >>>
> > >>>>
> > >>>> 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.
>=20
> I agree.
>=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.
> > >>
> > >> 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
> >
> > 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-27 2:58 ` Jia Hongtao-B38951
@ 2012-09-27 12:05 ` Kumar Gala
2012-09-27 13:24 ` Li Yang
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Kumar Gala @ 2012-09-27 12:05 UTC (permalink / raw)
To: Jia Hongtao-B38951; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
>>>>>>>>>>=20
>>>>>>>>>> On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
>>>>>>>>>>=20
>>>>>>>>>>> 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 <b14898@freescale.com>
>>>>>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>>>>>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>>>>>>>> ---
>>>>>>>>>>> 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(-)
>>>>>>>>>>=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.
>>>>>>>>=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.
>>>>>>>=20
>>>>>>> Are you seeing the following message - "PCI: I/O resource not =
set
>>>>>>> for host bridge" ?
>>>>>>=20
>>>>>> No.
>>>>>>=20
>>>>>>>=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?
>>>=20
>>> Yes, it means that IO transactions would not work.
>>=20
>> I agree.
>>=20
>>>=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
>>>>=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
>>> 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
>>>=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=
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-27 12:05 ` Kumar Gala
@ 2012-09-27 13:24 ` Li Yang
2012-09-27 16:04 ` Kumar Gala
2012-10-19 4:15 ` Jia Hongtao-B38951
2012-10-24 1:58 ` Jia Hongtao-B38951
2 siblings, 1 reply; 21+ messages in thread
From: Li Yang @ 2012-09-27 13:24 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472, Jia Hongtao-B38951
On Thu, Sep 27, 2012 at 8:05 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
>>>>>>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>>>>>>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> 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(-)
>>>>>>>>>>>
>>>>>>>>>>> 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.]
>>>>>>>>>
>>>>>>>>> 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" ?
>>>>>>>
>>>>>>> No.
>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>
>>>>
>>>>>> 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
>>>>>
>>>>> 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
>>>>
>>>
>>
>> Hi Kumar,
>> I have already sent the log.
>> Do you have any comment on it?
>>
>> Thanks.
>> - Hongtao.
>>
>
> 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?
I think Hongtao mentioned in previous email as follows, the ATMU
registers are inline with the io_resource address.
> > 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-27 13:24 ` Li Yang
@ 2012-09-27 16:04 ` Kumar Gala
2012-09-27 16:27 ` Li Yang-R58472
0 siblings, 1 reply; 21+ messages in thread
From: Kumar Gala @ 2012-09-27 16:04 UTC (permalink / raw)
To: Li Yang
Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472, Jia Hongtao-B38951
>>> 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
>>> 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
>>> 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-27 16:04 ` Kumar Gala
@ 2012-09-27 16:27 ` Li Yang-R58472
2012-09-27 21:38 ` Kumar Gala
0 siblings, 1 reply; 21+ messages in thread
From: Li Yang-R58472 @ 2012-09-27 16:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wood Scott-B07421, linuxppc-dev, Jia Hongtao-B38951
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==
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-27 16:27 ` Li Yang-R58472
@ 2012-09-27 21:38 ` Kumar Gala
2012-09-28 2:57 ` Jia Hongtao-B38951
0 siblings, 1 reply; 21+ messages in thread
From: Kumar Gala @ 2012-09-27 21:38 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: Wood Scott-B07421, linuxppc-dev, Jia Hongtao-B38951
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" =
<galak@kernel.crashing.org> =D0=B4=B5=C0=A3=BA
>=20
>>>>> 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
>>>>> 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.
>>=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=
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-27 21:38 ` Kumar Gala
@ 2012-09-28 2:57 ` Jia Hongtao-B38951
0 siblings, 0 replies; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-09-28 2:57 UTC (permalink / raw)
To: Kumar Gala, Li Yang-R58472; +Cc: Wood Scott-B07421, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
> -----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:
>
> >
> > 在 Sep 28, 2012，0:07，"Kumar Gala" <galak@kernel.crashing.org> 写道：
> >
> >>>>> Hi Kumar,
> >>>>> I have already sent the log.
> >>>>> Do you have any comment on it?
> >>>>>
> >>>>> Thanks.
> >>>>> - Hongtao.
> >>>>>
> >>>>
> >>>> 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?
> >>>
> >>> 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.
> >
> > 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.
> >
> > 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.
[-- Attachment #2: pci_pm_setup_pci_atmu_debug_2.log --]
[-- Type: application/octet-stream, Size: 31608 bytes --]
U-Boot 2009.11-00132-gd404dfa (Sep 26 2010 - 14:57:28)
CPU0: P1022E, Version: 1.0, (0x80ee0010)
Core: E500, Version: 5.0, (0x80211050)
Clock Configuration:
CPU0:1199.988 MHz, CPU1:1199.988 MHz,
CCB:599.994 MHz,
DDR:399.996 MHz (799.992 MT/s data rate) (Asynchronous), LBC:37.500 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: P1022DS Sys ID: 0x19, Sys Ver: 0x03, FPGA Ver: 0x09, vBank: 0
I2C: ready
SPI: ready
DRAM: Initializing.... DDR: 2 GB (DDR3, 64-bit, CL=6, ECC off)
Now running in RAM - U-Boot at: 7ff30000
FLASH: 128 MB
L2: 256 KB enabled
NAND: 1024 MiB
MMC: FSL_ESDHC: 0
EEPROM: NXID v0
PCIE1 connected to Slot 1 as Root Complex (base addr ffe0a000)
PCIE1 on bus 00 - 00
PCIE2 connected to Slot 3 as Root Complex (base addr ffe09000)
PCIE2 on bus 01 - 01
PCIE3 connected to Slot 2 as Root Complex (base addr ffe0b000)
PCIE3 on bus 02 - 02
In: serial
Out: serial
Err: serial
Net: eTSEC1, eTSEC2
Hit any key to stop autoboot: 0
=> run ramboot
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/ramdisk.small'.
Load address: 0x2000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##############################################################
done
Bytes transferred = 4306189 (41b50d hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/uImage_1022_reparse_debug'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
########
done
Bytes transferred = 3696937 (386929 hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/p1022ds_32b.dtb'.
Load address: 0xc00000
Loading: ###
done
Bytes transferred = 14645 (3935 hex)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.0.43-rt64-01350-g826673b
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 3696873 Bytes = 3.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 4306125 Bytes = 4.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 00c00000
Booting using the fdt blob at 0xc00000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 2fbe4000, end 2ffff4cd ... OK
debug: ignoring loglevel setting.
Using P1022 DS machine description
Memory CAM mapping: 256/256/256 Mb, residual: 1280Mb
Linux version 3.0.43-rt64-01350-g826673b-dirty (jiaht@rock) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-38) ) #69 SMP Fri Sep 28 10:06:47 CST 2012
Found initrd at 0xefbe4000:0xeffff4cd
Found legacy serial port 0 for /soc@ffe00000/serial@4500
mem=ffe04500, taddr=ffe04500, irq=0, clk=599994006, speed=0
Found legacy serial port 1 for /soc@ffe00000/serial@4600
mem=ffe04600, taddr=ffe04600, irq=0, clk=599994006, speed=0
CPU maps initialized for 1 thread per core
(thread shift is 0)
bootconsole [udbg0] enabled
setup_arch: bootmem
p1022_ds_setup_arch()
Adding PCI host bridge /pcie@ffe09000
Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0
->Hose at 0xc0765000, cfg_addr=0xff7fd000,cfg_data=0xff7fd004
PCI host bridge /pcie@ffe09000 ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000e0000000
IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe09000, size 0x0000000000001000
PCI MEM resource start 0x00000000a0000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc10000.
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
Adding PCI host bridge /pcie@ffe0a000
Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->0
->Hose at 0xc07650e0, cfg_addr=0xff7eb000,cfg_data=0xff7eb004
PCI host bridge /pcie@ffe0a000 ranges:
MEM 0x00000000c0000000..0x00000000dfffffff -> 0x00000000e0000000
IO 0x00000000ffc20000..0x00000000ffc2ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe0a000, size 0x0000000000001000
PCI MEM resource start 0x00000000c0000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc20000.
/pcie@ffe0a000: PCICSRBAR @ 0xfff00000
Adding PCI host bridge /pcie@ffe0b000
Found FSL PCI host bridge at 0x00000000ffe0b000. Firmware bus number: 0->0
->Hose at 0xc07651c0, cfg_addr=0xff7d9000,cfg_data=0xff7d9004
PCI host bridge /pcie@ffe0b000 ranges:
MEM 0x0000000080000000..0x000000009fffffff -> 0x00000000e0000000
IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe0b000, size 0x0000000000001000
PCI MEM resource start 0x0000000080000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc00000.
/pcie@ffe0b000: PCICSRBAR @ 0xfff00000
Freescale P1022 DS reference board
arch: exit
Top of RAM: 0x80000000, Total RAM: 0x80000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00030000
Normal empty
HighMem 0x00030000 -> 0x00080000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00080000
On node 0 totalpages: 524288
free_area_init_node: node 0, pgdat c072e380, node_mem_map c0c04000
DMA zone: 1536 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 195072 pages, LIFO batch:31
HighMem zone: 2560 pages used for memmap
HighMem zone: 325120 pages, LIFO batch:31
MMU: Allocated 1088 bytes of context maps for 255 contexts
PERCPU: Embedded 7 pages/cpu @c1c10000 s4768 r8192 d15712 u32768
pcpu-alloc: s4768 r8192 d15712 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 520192
Kernel command line: root=/dev/ram rw console=ttyS0,115200 ramdisk_size=400000 cache-sram-size=0x8000 cache-sram-offset=0xfff00000 no_console_suspend ignore_loglevel
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 1310716k
Memory: 2067952k/2097152k available (7160k kernel code, 29200k reserved, 236k data, 174k bss, 268k init)
Kernel virtual memory layout:
* 0xfff5f000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xff7c7000..0xff800000 : early ioremap
* 0xf1000000..0xff7c7000 : vmalloc & ioremap
SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512 nr_irqs:512 16
mpic: Resetting
mpic: Setting up MPIC " OpenPIC " version 1.2 at ffe40000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
time_init: decrementer frequency = 74.999251 MHz
time_init: processor frequency = 1199.988012 MHz
clocksource: timebase mult[3555784] shift[22] registered
clockevent: decrementer mult[133326a2] shift[32] cpu[0]
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
mpic: requesting IPIs...
Brought up 2 CPUs
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Scanning PHB /pcie@ffe09000
PCI: PHB IO resource = 00000000ff7ed000-00000000ff7fcfff [100]
PCI: PHB MEM resource 0 = 00000000a0000000-00000000bfffffff [200]
PCI: PHB MEM offset = 00000000c0000000
PCI: PHB IO offset = ff7ed000
probe mode: 0
pci 0000:00:00.0: [1957:0110] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
PCI: Fixup bus devices 0 (PHB)
pci_busdev_to_OF_node(0,0x0)
parent is /pcie@ffe09000
result is /pcie@ffe09000/pcie@0
PCI: Try to map irq for 0000:00:00.0...
pci_busdev_to_OF_node(0,0x0)
parent is /pcie@ffe09000
result is /pcie@ffe09000/pcie@0
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe00000/pic@40000
Mapped to linux irq 16
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
PCI: Fixup bus devices 1 (0000:00:00.0)
PCI: Scanning PHB /pcie@ffe0a000
PCI: PHB IO resource = 00000000ff7db000-00000000ff7eafff [100]
PCI: PHB MEM resource 0 = 00000000c0000000-00000000dfffffff [200]
PCI: PHB MEM offset = 00000000e0000000
PCI: PHB IO offset = ff7db000
probe mode: 0
pci 0001:02:00.0: [1957:0110] type 1 class 0x000b20
pci 0001:02:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:02:00.0: supports D1 D2
pci 0001:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0001:02:00.0: PME# disabled
PCI: Fixup bus devices 2 (PHB)
pci_busdev_to_OF_node(2,0x0)
parent is /pcie@ffe0a000
result is /pcie@ffe0a000/pcie@0
PCI: Try to map irq for 0001:02:00.0...
pci_busdev_to_OF_node(2,0x0)
parent is /pcie@ffe0a000
result is /pcie@ffe0a000/pcie@0
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe00000/pic@40000
Mapped to linux irq 16
pci 0001:02:00.0: PCI bridge to [bus 03-ff]
pci 0001:02:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0001:02:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0001:02:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
PCI: Fixup bus devices 3 (0001:02:00.0)
PCI: Scanning PHB /pcie@ffe0b000
PCI: PHB IO resource = 00000000ff7c9000-00000000ff7d8fff [100]
PCI: PHB MEM resource 0 = 0000000080000000-000000009fffffff [200]
PCI: PHB MEM offset = 00000000a0000000
PCI: PHB IO offset = ff7c9000
probe mode: 0
pci 0002:04:00.0: [1957:0110] type 1 class 0x000b20
pci 0002:04:00.0: ignoring class b20 (doesn't match header type 01)
pci 0002:04:00.0: supports D1 D2
pci 0002:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0002:04:00.0: PME# disabled
PCI: Fixup bus devices 4 (PHB)
pci_busdev_to_OF_node(4,0x0)
parent is /pcie@ffe0b000
result is /pcie@ffe0b000/pcie@0
PCI: Try to map irq for 0002:04:00.0...
pci_busdev_to_OF_node(4,0x0)
parent is /pcie@ffe0b000
result is /pcie@ffe0b000/pcie@0
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe00000/pic@40000
Mapped to linux irq 16
pci 0002:04:00.0: PCI bridge to [bus 05-ff]
pci 0002:04:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0002:04:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0002:04:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
PCI: Fixup bus devices 5 (0002:04:00.0)
PCI->OF bus map:
0 -> 0
2 -> 0
4 -> 0
PCI: Allocating bus resources for 0000:00...
PCI: PHB (bus 0) bridge rsrc 0: 00000000ff7ed000-00000000ff7fcfff [0x100], parent c07043c8 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 00000000a0000000-00000000bfffffff [0x200], parent c07043ac (PCI mem)
PCI: Allocating bus resources for 0000:01...
PCI: 0000:00:00.0 (bus 1) bridge rsrc 0: 00000000ff7ed000-00000000ff7fcfff [0x100], parent c076504c (/pcie@ffe09000)
PCI: 0000:00:00.0 (bus 1) bridge rsrc 1: 00000000a0000000-00000000bfffffff [0x200], parent c0765068 (/pcie@ffe09000)
PCI: Allocating bus resources for 0001:02...
PCI: PHB (bus 2) bridge rsrc 0: 00000000ff7db000-00000000ff7eafff [0x100], parent c07043c8 (PCI IO)
PCI: PHB (bus 2) bridge rsrc 1: 00000000c0000000-00000000dfffffff [0x200], parent c07043ac (PCI mem)
PCI: Allocating bus resources for 0001:03...
PCI: 0001:02:00.0 (bus 3) bridge rsrc 0: 00000000ff7db000-00000000ff7eafff [0x100], parent c076512c (/pcie@ffe0a000)
PCI: 0001:02:00.0 (bus 3) bridge rsrc 1: 00000000c0000000-00000000dfffffff [0x200], parent c0765148 (/pcie@ffe0a000)
PCI: Allocating bus resources for 0002:04...
PCI: PHB (bus 4) bridge rsrc 0: 00000000ff7c9000-00000000ff7d8fff [0x100], parent c07043c8 (PCI IO)
PCI: PHB (bus 4) bridge rsrc 1: 0000000080000000-000000009fffffff [0x200], parent c07043ac (PCI mem)
PCI: Allocating bus resources for 0002:05...
PCI: 0002:04:00.0 (bus 5) bridge rsrc 0: 00000000ff7c9000-00000000ff7d8fff [0x100], parent c076520c (/pcie@ffe0b000)
PCI: 0002:04:00.0 (bus 5) bridge rsrc 1: 0000000080000000-000000009fffffff [0x200], parent c0765228 (/pcie@ffe0b000)
Reserving legacy ranges for domain 0000
Candidate legacy IO: [io 0xff7ed000-0xff7edfff]
PCI 0000:00 Cannot reserve Legacy IO [io 0xff7ed000-0xff7edfff]
hose mem offset: 00000000c0000000
hose mem res: [mem 0xa0000000-0xbfffffff]
Reserving legacy ranges for domain 0001
Candidate legacy IO: [io 0xff7db000-0xff7dbfff]
PCI 0001:02 Cannot reserve Legacy IO [io 0xff7db000-0xff7dbfff]
hose mem offset: 00000000e0000000
hose mem res: [mem 0xc0000000-0xdfffffff]
Reserving legacy ranges for domain 0002
Candidate legacy IO: [io 0xff7c9000-0xff7c9fff]
PCI 0002:04 Cannot reserve Legacy IO [io 0xff7c9000-0xff7c9fff]
hose mem offset: 00000000a0000000
hose mem res: [mem 0x80000000-0x9fffffff]
PCI: Assigning unassigned resources...
PCI: max bus depth: 1 pci_try_num: 2
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xff7ed000-0xff7fcfff]
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xbfffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0001:02:00.0: PCI bridge to [bus 03-03]
pci 0001:02:00.0: bridge window [io 0xff7db000-0xff7eafff]
pci 0001:02:00.0: bridge window [mem 0xc0000000-0xdfffffff]
pci 0001:02:00.0: bridge window [mem pref disabled]
pci 0002:04:00.0: PCI bridge to [bus 05-05]
pci 0002:04:00.0: bridge window [io 0xff7c9000-0xff7d8fff]
pci 0002:04:00.0: bridge window [mem 0x80000000-0x9fffffff]
pci 0002:04:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci 0001:02:00.0: enabling device (0106 -> 0107)
pci 0002:04:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:00: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0000:01: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:01: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0001:02: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:02: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0001:03: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:03: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0002:04: resource 0 [io 0xff7c9000-0xff7d8fff]
pci_bus 0002:04: resource 1 [mem 0x80000000-0x9fffffff]
pci_bus 0002:05: resource 0 [io 0xff7c9000-0xff7d8fff]
pci_bus 0002:05: resource 1 [mem 0x80000000-0x9fffffff]
Registering qe_ic with sysfs...
bio: create slab <bio-0> at 0
raid6: int32x1 172 MB/s
raid6: int32x2 301 MB/s
raid6: int32x4 427 MB/s
raid6: int32x8 358 MB/s
raid6: using algorithm int32x4 (427 MB/s)
Freescale Elo / Elo Plus DMA driver
vgaarb: loaded
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.24.
Switching to clocksource timebase
Switched to NOHz mode on CPU #0
Switched to NOHz mode on CPU #1
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 32
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 4208k freed
fsl-elo-dma ffe0c300.dma: #2 (fsl,eloplus-dma-channel), irq 78
fsl-elo-dma ffe0c300.dma: #3 (fsl,eloplus-dma-channel), irq 79
fsl-l2ctlr ffe20000.l2-cache-controller: Entire L2 as cache, provide valid sram address and size
fsl-l2ctlr: probe of ffe20000.l2-cache-controller failed with error -22
fsl-elo-dma ffe21300.dma: #0 (fsl,eloplus-dma-channel), irq 20
fsl-elo-dma ffe21300.dma: #1 (fsl,eloplus-dma-channel), irq 21
fsl-elo-dma ffe21300.dma: #2 (fsl,eloplus-dma-channel), irq 22
fsl-elo-dma ffe21300.dma: #3 (fsl,eloplus-dma-channel), irq 23
Setting up Freescale MSI support
Freescale PowerQUICC MII Bus: probed
fsl-pq_mdio: probe of ffe25000.mdio failed with error -16
Freescale PMC driver
audit: initializing netlink socket (disabled)
type=2000 audit(0.888:1): initialized
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.30 [Flags: R/O].
JFFS2 version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
Allocated 267980 bytes for deflate workspace
Allocated 42284 bytes for inflate workspace
Registering JFFS2 compressor "zlib"
Registering JFFS2 compressor "rtime"
JFFS2: default compression mode: priority
msgmni has been set to 1487
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Freescale DIU driver
Console: switching to colour frame buffer device 128x48
fb0: Panel0 fb device registered successfully.
fb1: fb device registered successfully.
fb2: fb device registered successfully.
fb3: fb device registered successfully.
fb4: fb device registered successfully.
Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 42) is a 16550A
Generic non-volatile memory driver v1.1
brd: module loaded
loop: module loaded
nbd: registered device at major 43
st: Version 20101219, fixed bufsize 32768, s/g segs 256
fsl-sata ffe18000.sata: Sata FSL Platform/CSB Driver init
scsi0 : sata_fsl
ata1: SATA max UDMA/133 irq 74
fsl-sata ffe19000.sata: Sata FSL Platform/CSB Driver init
scsi1 : sata_fsl
ata2: SATA max UDMA/133 irq 41
e8000000.nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002801
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
Creating 7 MTD partitions on "e8000000.nor":
0x000000000000-0x000003000000 : "ramdisk-nor"
ftl_cs: FTL header not found.
0x000003000000-0x000003e00000 : "diagnostic-nor"
ftl_cs: FTL header not found.
0x000003e00000-0x000004000000 : "dink-nor"
ftl_cs: FTL header not found.
0x000004000000-0x000004400000 : "kernel-nor"
ftl_cs: FTL header not found.
0x000004400000-0x000007f00000 : "jffs2-nor"
ftl_cs: FTL header not found.
0x000007f00000-0x000007f80000 : "dtb-nor"
ftl_cs: FTL header not found.
0x000007f80000-0x000008000000 : "u-boot-nor"
ftl_cs: FTL header not found.
fsl-lbc ffe05000.localbus: address did not match any chip selects
m25p80 spi32766.0: s25sl12801 (16384 Kbytes)
Creating 4 MTD partitions on "spi32766.0":
0x000000000000-0x000000100000 : "u-boot-spi"
ftl_cs: FTL header not found.
0x000000100000-0x000000600000 : "kernel-spi"
ftl_cs: FTL header not found.
0x000000600000-0x000000700000 : "dtb-spi"
ftl_cs: FTL header not found.
0x000000700000-0x000001000000 : "file system-spi"
ftl_cs: FTL header not found.
fsl_espi ffe07000.spi: at 0xf1064000 (irq = 59)
Fixed MDIO Bus: probed
e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
fsl-gianfar ethernet.4: eth0: mac: 00:e0:0c:02:00:fd
fsl-gianfar ethernet.4: eth0: Running with NAPI enabled
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[0]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[1]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[2]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[3]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[4]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[5]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[6]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[7]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[0]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[1]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[2]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[3]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[4]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[5]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[6]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[7]: 256
fsl-gianfar ethernet.5: eth1: mac: 00:e0:0c:02:01:fd
fsl-gianfar ethernet.5: eth1: Running with NAPI enabled
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[0]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[1]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[2]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[3]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[4]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[5]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[6]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[7]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[0]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[1]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[2]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[3]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[4]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[5]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[6]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[7]: 256
ucc_geth: QE UCC Gigabit Ethernet Controller
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
/soc@ffe00000/usb@22000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 28, io mem 0xffe22000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mpc-i2c ffe03000.i2c: timeout 1000000 us
mpc-i2c ffe03100.i2c: timeout 1000000 us
EDAC MC: Ver: 2.1.0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
talitos ffe30000.crypto: hwrng
talitos ffe30000.crypto: fsl,sec3.3 algorithms registered in /proc/crypto
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
Freescale Synchronous Serial Interface (SSI) ASoC Driver
snd-soc-p1022ds snd-soc-p1022ds.0: codec bus-frequency property is missing or invalid
snd-soc-p1022ds: probe of snd-soc-p1022ds.0 failed with error -22
ata1: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata1: SATA link down (SStatus 0 SControl 300)
ata2: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata2: SATA link down (SStatus 0 SControl 300)
Freescale Elo DMA ASoC PCM Driver
ALSA device list:
No soundcards found.
IPv4 over IPv4 tunneling driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
Registering the dns_resolver key type
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 268k freed
Mounting /proc and /sys
Setting the hostname to mpc8572ds
Running depmod
WARNING: Couldn't open directory /lib/modules/3.0.43-rt64-01350-g826673b-dirty: No such file or directory
FATAL: Could not open /lib/modules/3.0.43-rt64-01350-g826673b-dirty/modules.dep.temp for writing: No such file or directory
Mounting filesystems
Starting syslogd and klogd
Running sysctl
Setting up networking on loopback device:
Setting up networking on eth0:
ADDRCONF(NETDEV_UP): eth0: link is not ready
Adding static route for default gateway to 192.168.1.1:
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Setting up networking on eth1:
ADDRCONF(NETDEV_UP): eth1: link is not ready
Adding static route for default gateway to 192.168.1.1:
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Starting inetd:
Please set the system time using
date <mmddhhmnyyyy>
/sbin/hwclock -w
Welcome to Freescale Semiconductor Embedded Linux Environment
!!!!! WARNING !!!!!!!
The default password for the root account is: root
please change this password using the 'passwd' command
and then edit this message (/etc/issue) to remove this message
mpc8572ds login: root
Password:
~ #
~ #
~ #
~ # PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
PHY: mdio@ffe24000:01 - Link is Down
~ #
~ #
~ #
~ # PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
~ #
~ #
~ #
~ # echo 5 > /sys/devices/platform/fsl-wakeup.0/fsl_wakeup;echo mem > /sys/power
/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: suspend of devices complete after 2.032 msecs
PM: late suspend of devices complete after 0.434 msecs
Disabling non-boot CPUs ...
Cannot set affinity for irq 502
PM: resume of devices complete after 27.379 msecs
Restarting tasks ... done.
~ # ata2: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata2: SATA link down (SStatus 0 SControl 300)
ata1: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata1: SATA link down (SStatus 0 SControl 300)
PHY: mdio@ffe24000:01 - Link is Down
PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
eth0: no IPv6 routers present
~ #
~ #
~ #
~ # dmesg | tail -n 60
pcieport 0000:00:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100106)
pcieport 0001:02:00.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
pcieport 0001:02:00.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0e000)
pcieport 0001:02:00.0: restoring config space at offset 0x6 (was 0x0, writing 0x30300)
pcieport 0001:02:00.0: restoring config space at offset 0x4 (was 0x0, writing 0xfff00000)
pcieport 0001:02:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100106)
pcieport 0002:04:00.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
pcieport 0002:04:00.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0e000)
pcieport 0002:04:00.0: restoring config space at offset 0x6 (was 0x0, writing 0x50500)
pcieport 0002:04:00.0: restoring config space at offset 0x4 (was 0x0, writing 0xfff00000)
Switched to NOHz mode on CPU #1
pcieport 0002:04:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100106)
PM: early resume of devices complete after 1.503 msecs
***** PCI/ffe09000 : In resume *****
io_resource.start : ff7ed000
io_resource.start >> 12: ff7ed
mem_resources[0].start : a0000000
mem_resources[0].end : bfffffff
mem_resources[1].start : 0
mem_resources[1].end : 0
PCI memory map start 0x00000000ffe09000, size 0x0000000000001000
PCI MEM resource start 0x00000000a0000000, size 0x0000000020000000.
PCI IO resource start 0x00000000ff7ed000, size 0x0000000000010000, phy base 0x00000000ffc10000.
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
pci atmu resume time last: 29561
***** PCI/ffe0a000 : In resume *****
io_resource.start : ff7db000
io_resource.start >> 12: ff7db
mem_resources[0].start : c0000000
mem_resources[0].end : dfffffff
mem_resources[1].start : 0
mem_resources[1].end : 0
PCI memory map start 0x00000000ffe0a000, size 0x0000000000001000
PCI MEM resource start 0x00000000c0000000, size 0x0000000020000000.
PCI IO resource start 0x00000000ff7db000, size 0x0000000000010000, phy base 0x00000000ffc20000.
/pcie@ffe0a000: PCICSRBAR @ 0x0
/pcie@ffe0a000: DMA window size is 0x0
pci atmu resume time last: 29717
***** PCI/ffe0b000 : In resume *****
io_resource.start : ff7c9000
io_resource.start >> 12: ff7c9
mem_resources[0].start : 80000000
mem_resources[0].end : 9fffffff
mem_resources[1].start : 0
mem_resources[1].end : 0
PCI memory map start 0x00000000ffe0b000, size 0x0000000000001000
PCI MEM resource start 0x0000000080000000, size 0x0000000020000000.
PCI IO resource start 0x00000000ff7c9000, size 0x0000000000010000, phy base 0x00000000ffc00000.
/pcie@ffe0b000: PCICSRBAR @ 0x0
/pcie@ffe0b000: DMA window size is 0x0
pci atmu resume time last: 29735
PM: resume of devices complete after 27.379 msecs
Restarting tasks ... done.
ata2: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata2: SATA link down (SStatus 0 SControl 300)
ata1: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata1: SATA link down (SStatus 0 SControl 300)
PHY: mdio@ffe24000:01 - Link is Down
PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
eth0: no IPv6 routers present
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-27 12:05 ` Kumar Gala
2012-09-27 13:24 ` Li Yang
@ 2012-10-19 4:15 ` Jia Hongtao-B38951
2012-10-24 1:58 ` Jia Hongtao-B38951
2 siblings, 0 replies; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-10-19 4:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
> -----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
> >>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>>>
> >>>>>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> >>>>>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> >>>>>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
> >>>>>>>>>>> ---
> >>>>>>>>>>> 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(-)
> >>>>>>>>>>
> >>>>>>>>>> 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.]
> >>>>>>>>
> >>>>>>>> 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" ?
> >>>>>>
> >>>>>> No.
> >>>>>>
> >>>>>>>
> >>>>>>> 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.
> >>
> >>>
> >>>>> 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
> >>>>
> >>>> 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
> >>>
> >>
> >
> > Hi Kumar,
> > I have already sent the log.
> > Do you have any comment on it?
> >
> > Thanks.
> > - Hongtao.
> >
>=20
> Hongtao,
>=20
> You mentioned:
>=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
> 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-09-27 12:05 ` Kumar Gala
2012-09-27 13:24 ` Li Yang
2012-10-19 4:15 ` Jia Hongtao-B38951
@ 2012-10-24 1:58 ` Jia Hongtao-B38951
2012-10-30 2:57 ` Jia Hongtao-B38951
2 siblings, 1 reply; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-10-24 1:58 UTC (permalink / raw)
To: Jia Hongtao-B38951, Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
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
> > -----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
> >
> > >>>>>>>>>>
> > >>>>>>>>>> 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.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> > >>>>>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> > >>>>>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
> > >>>>>>>>>>> ---
> > >>>>>>>>>>> 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(-)
> > >>>>>>>>>>
> > >>>>>>>>>> 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.]
> > >>>>>>>>
> > >>>>>>>> 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" ?
> > >>>>>>
> > >>>>>> No.
> > >>>>>>
> > >>>>>>>
> > >>>>>>> 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.
> > >>
> > >>>
> > >>>>> 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
> > >>>>
> > >>>> 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
> > >>>
> > >>
> > >
> > > Hi Kumar,
> > > I have already sent the log.
> > > Do you have any comment on it?
> > >
> > > Thanks.
> > > - Hongtao.
> > >
> >
> > 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
>=20
>=20
> Hi Kumar,
>=20
> About this topic do you have any further comments?
>=20
> Thanks.
> - Hongtao.
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
2012-10-24 1:58 ` Jia Hongtao-B38951
@ 2012-10-30 2:57 ` Jia Hongtao-B38951
0 siblings, 0 replies; 21+ messages in thread
From: Jia Hongtao-B38951 @ 2012-10-30 2:57 UTC (permalink / raw)
To: Jia Hongtao-B38951, Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472
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
> > -----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
> >
> > > -----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
> > >
> > > >>>>>>>>>>
> > > >>>>>>>>>> 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.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> > > >>>>>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> > > >>>>>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
> > > >>>>>>>>>>> ---
> > > >>>>>>>>>>> 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(-)
> > > >>>>>>>>>>
> > > >>>>>>>>>> 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.]
> > > >>>>>>>>
> > > >>>>>>>> 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" ?
> > > >>>>>>
> > > >>>>>> No.
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> 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.
> > > >>
> > > >>>
> > > >>>>> 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
> > > >>>>
> > > >>>> 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
> > > >>>
> > > >>
> > > >
> > > > Hi Kumar,
> > > > I have already sent the log.
> > > > Do you have any comment on it?
> > > >
> > > > Thanks.
> > > > - Hongtao.
> > > >
> > >
> > > 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
> >
> >
> > Hi Kumar,
> >
> > About this topic do you have any further comments?
> >
> > Thanks.
> > - Hongtao.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2012-10-30 3:04 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-18 2:10 [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support Jia Hongtao
2012-09-18 5:03 ` Kumar Gala
2012-09-19 7:10 ` Jia Hongtao-B38951
2012-09-19 14:27 ` Kumar Gala
2012-09-19 15:41 ` Jia Hongtao-B38951
2012-09-19 15:49 ` Kumar Gala
2012-09-21 3:13 ` Jia Hongtao-B38951
2012-09-21 3:50 ` Li Yang-R58472
2012-09-21 5:15 ` Jia Hongtao-B38951
2012-09-21 13:15 ` Kumar Gala
2012-09-24 2:47 ` Jia Hongtao-B38951
2012-09-27 2:58 ` Jia Hongtao-B38951
2012-09-27 12:05 ` Kumar Gala
2012-09-27 13:24 ` Li Yang
2012-09-27 16:04 ` Kumar Gala
2012-09-27 16:27 ` Li Yang-R58472
2012-09-27 21:38 ` Kumar Gala
2012-09-28 2:57 ` Jia Hongtao-B38951
2012-10-19 4:15 ` Jia Hongtao-B38951
2012-10-24 1:58 ` Jia Hongtao-B38951
2012-10-30 2:57 ` Jia Hongtao-B38951
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).