We unified the Freescale pci/pcie initialization by changing the fsl_pci
to a platform driver. In previous PCI code architecture the initialization
routine is called at board_setup_arch stage. Now the initialization is done
in probe function which is architectural better. Also It's convenient for
adding PM support for PCI controller in later patch.
One issue introduced by this architecture is the timing of swiotlb_init.
During PCI initialization the need of swiotlb is determined and this should
be done before swiotlb_init. So a new function to determine swiotlb by
parsing pci ranges is made. This function is called at board_setup_arch
stage which is earlier than swiotlb_init.
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
arch/powerpc/sysdev/fsl_pci.c | 155 ++++++++++++++++++++++++++++++++---------
arch/powerpc/sysdev/fsl_pci.h | 9 +--
2 files changed, 125 insertions(+), 39 deletions(-)
@@ -823,56 +823,143 @@ static const struct of_device_id pci_ids[] = {{},};-structdevice_node*fsl_pci_primary;--void__devinitfsl_pci_init(void)+#ifdef CONFIG_SWIOTLB+voidpci_determine_swiotlb(void){+constu32*ranges;+intrlen;+intpna;+intnp;structdevice_node*node;-structpci_controller*hose;-dma_addr_tmax=0xffffffff;--/* Callers can specify the primary bus using other means. */-if(!fsl_pci_primary){-/* If a PCI host bridge contains an ISA node, it's primary. */-node=of_find_node_by_type(NULL,"isa");-while((fsl_pci_primary=of_get_parent(node))){-of_node_put(node);-node=fsl_pci_primary;--if(of_match_node(pci_ids,node))-break;-}-}+intmemno;+u32pci_space;+unsignedlonglongpci_addr,cpu_addr,pci_next,cpu_next,size;+unsignedlonglongpci_addr_lo=ULLONG_MAX;+unsignedlonglongpci_addr_hi=0x0;+dma_addr_tpci_dma_sz;-node=NULL;for_each_node_by_type(node,"pci"){if(of_match_node(pci_ids,node)){-/*-*Ifthere'snoPCIhostbridgewithISA,arbitrarily-*designateoneasprimary.Thiscangoawayonce-*variousbugswithprimary-lesssystemsarefixed.-*/-if(!fsl_pci_primary)-fsl_pci_primary=node;--fsl_add_bridge(node,fsl_pci_primary==node);-hose=pci_find_hose_for_OF_device(node);-max=min(max,hose->dma_window_base_cur+-hose->dma_window_size);+memno=0;+pna=of_n_addr_cells(node);+np=pna+5;+/* Get ranges property */+ranges=of_get_property(node,"ranges",&rlen);+if(ranges==NULL)+return;++/* Parse outbound MEM window range */+while((rlen-=np*4)>=0){+/* Read next ranges element */+pci_space=ranges[0];+if(!((pci_space>>24)&0x2)){+ranges+=np;+break;+}+pci_addr=of_read_number(ranges+1,2);+cpu_addr=of_translate_address(+node,ranges+3);+size=of_read_number(ranges+pna+3,2);+ranges+=np;++/*+*Ifwefailedtranslationorgotazero-sized+*region(someFWtrytofeeduswithnon+*sensicalzerosizedregionssuchaspower3+*whichlooklikesomekindofattemptat+*exposingtheVGAmemoryhole)+*/+if(cpu_addr==OF_BAD_ADDR||size==0)+continue;++/*+*Nowconsumefollowingelementswhilethey+*arecontiguous+*/+for(;rlen>=np*sizeof(u32);+ranges+=np,rlen-=np*4){+if(ranges[0]!=pci_space)+break;+pci_next=of_read_number(ranges+1,+2);+cpu_next=of_translate_address(node,+ranges+3);+if(pci_next!=pci_addr+size||+cpu_next!=cpu_addr+size)+break;+size+=of_read_number(+ranges+pna+3,2);+}++/* We support only 3 memory ranges */+if(memno>=3){+printk(KERN_INFO+" \\--> Skipped (too many) !\n");+continue;+}++pci_addr_lo=min(pci_addr,pci_addr_lo);+pci_addr_hi=max(pci_addr+size,pci_addr_hi);+memno++;+}}}-#ifdef CONFIG_SWIOTLB+/* Get PEXCSRBAR size (equal to CCSR size) */+node=of_find_node_by_type(NULL,"soc");+ranges=of_get_property(node,"ranges",&rlen);+if(ranges==NULL)+return;++size=of_read_number(ranges+3,1);+of_node_put(node);++if(pci_addr_hi<(0x100000000ull-size))+pci_dma_sz=pci_addr_lo;+else+pci_dma_sz=pci_addr_lo-size;+/**ifwecouldn'tmapallofDRAMviathedmawindows*weneedSWIOTLBtohandlebufferslocatedoutsideof*dmacapablememoryregion*/-if(memblock_end_of_DRAM()-1>max){+if(memblock_end_of_DRAM()>pci_dma_sz){ppc_swiotlb_enable=1;set_pci_dma_ops(&swiotlb_dma_ops);-ppc_md.pci_dma_dev_setup=pci_dma_dev_setup_swiotlb;+ppc_md.pci_dma_dev_setup=+pci_dma_dev_setup_swiotlb;}+}#endif++intprimary_phb_addr;+staticint__devinitfsl_pci_probe(structplatform_device*pdev)+{+structpci_controller*hose;+boolis_primary;++if(of_match_node(pci_ids,pdev->dev.of_node)){+structresourcersrc;+of_address_to_resource(pdev->dev.of_node,0,&rsrc);+is_primary=((rsrc.start&0xfffff)==primary_phb_addr);+fsl_add_bridge(pdev->dev.of_node,is_primary);+}++return0;+}++staticstructplatform_driverfsl_pci_driver={+.driver={+.name="fsl-pci",+.of_match_table=pci_ids,+},+.probe=fsl_pci_probe,+};++staticint__initfsl_pci_init(void)+{+returnplatform_driver_register(&fsl_pci_driver);}+arch_initcall(fsl_pci_init);#endif
PCI host bridge is primary bus if it contains an ISA node. But not all boards
fit this rule. Device tree should be updated for all these boards.
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Using non-recursive function to find ISA under PCI
arch/powerpc/include/asm/pci-bridge.h | 1 +
arch/powerpc/sysdev/fsl_pci.c | 31 ++++++++++++++++++++++++-------
arch/powerpc/sysdev/fsl_pci.h | 12 +++++++++++-
3 files changed, 36 insertions(+), 8 deletions(-)
@@ -453,6 +453,7 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)hose->first_busno=bus_range?bus_range[0]:0x0;hose->last_busno=bus_range?bus_range[1]:0xff;+hose->is_primary=is_primary;setup_indirect_pci(hose,rsrc.start,rsrc.start+0x4,PPC_INDIRECT_TYPE_BIG_ENDIAN);
@@ -933,18 +934,34 @@ void pci_determine_swiotlb(void)}#endif-intprimary_phb_addr;+/* Checkout if PCI contains ISA node (Only scan the children of PCI) */+staticintof_pci_has_isa(structdevice_node*pci_node)+{+structdevice_node*np;++read_lock(&devtree_lock);+if(!pci_node)+return0;+np=pci_node->allnext;+for(;np!=pci_node->sibling;np=np->allnext){+if(np->type&&(of_node_cmp(np->type,"isa")==0)+&&of_node_get(np)){+of_node_put(pci_node);+return1;+}+}+of_node_put(pci_node);+read_unlock(&devtree_lock);+return0;+}+staticint__devinitfsl_pci_probe(structplatform_device*pdev){-structpci_controller*hose;boolis_primary;+is_primary=of_pci_has_isa(pdev->dev.of_node);-if(of_match_node(pci_ids,pdev->dev.of_node)){-structresourcersrc;-of_address_to_resource(pdev->dev.of_node,0,&rsrc);-is_primary=((rsrc.start&0xfffff)==primary_phb_addr);+if(of_match_node(pci_ids,pdev->dev.of_node))fsl_add_bridge(pdev->dev.of_node,is_primary);-}return0;}
PCI initialization is now done by PCI controller driver. In board_setup_arch
stage we don't need PCI init any more but swiotlb should be determined at this
stage.
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
We now just apply this for mpc85xx_ds and qemu
arch/powerpc/kernel/iommu.c.rej | 22 -----------------
arch/powerpc/platforms/85xx/common.c | 9 +++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 38 +++++++----------------------
arch/powerpc/platforms/85xx/qemu_e500.c | 5 +++-
4 files changed, 22 insertions(+), 52 deletions(-)
delete mode 100644 arch/powerpc/kernel/iommu.c.rej
@@ -117,40 +117,16 @@ void __init mpc85xx_ds_pic_init(void)externintuli_exclude_device(structpci_controller*hose,u_charbus,u_chardevfn);-staticstructdevice_node*pci_with_uli;-staticintmpc85xx_exclude_device(structpci_controller*hose,u_charbus,u_chardevfn){-if(hose->dn==pci_with_uli)+if(hose->is_primary)returnuli_exclude_device(hose,bus,devfn);returnPCIBIOS_SUCCESSFUL;}#endif /* CONFIG_PCI */-staticvoid__initmpc85xx_ds_pci_init(void)-{-#ifdef CONFIG_PCI-structdevice_node*node;--fsl_pci_init();--/* See if we have a ULI under the primary */--node=of_find_node_by_name(NULL,"uli1575");-while((pci_with_uli=of_get_parent(node))){-of_node_put(node);-node=pci_with_uli;--if(pci_with_uli==fsl_pci_primary){-ppc_md.pci_exclude_device=mpc85xx_exclude_device;-break;-}-}-#endif-}-/**Setupthearchitecture*/
Power supply for PCI inbound/outbound window registers is off when system
go to deep-sleep state. We save the values of registers before suspend
and restore to registers after resume.
Signed-off-by: Jiang Yutang <redacted>
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/include/asm/pci-bridge.h | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 121 +++++++++++++++++++++++++++++++++
2 files changed, 122 insertions(+), 1 deletions(-)
@@ -90,9 +90,9 @@ struct pci_controller {#ifdef CONFIG_PPC64unsignedlongbuid;+#endif /* CONFIG_PPC64 */void*private_data;-#endif /* CONFIG_PPC64 */};/* These are used for config access before all the PCI probing
From: Chunhe Lan <redacted>
Now we registered pci controllers as platform devices. It will make edac
driver failed to register pci nodes as platform devices too. So we combine
two initialization code as one platform driver.
Signed-off-by: Chunhe Lan <redacted>
Signed-off-by: Li Yang <redacted>
Signed-off-by: Jia Hongtao <redacted>
---
arch/powerpc/sysdev/fsl_pci.c | 4 +++
arch/powerpc/sysdev/fsl_pci.h | 4 +++
drivers/edac/mpc85xx_edac.c | 43 +++++++++++-----------------------------
3 files changed, 20 insertions(+), 31 deletions(-)
From: Kumar Gala <hidden> Date: 2012-07-26 17:46:46
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
PCI initialization is now done by PCI controller driver. In =
board_setup_arch
stage we don't need PCI init any more but swiotlb should be determined =
at this
stage.
=20
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
We now just apply this for mpc85xx_ds and qemu
=20
arch/powerpc/kernel/iommu.c.rej | 22 -----------------
arch/powerpc/platforms/85xx/common.c | 9 +++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 38 =
From: Kumar Gala <hidden> Date: 2012-07-26 17:47:57
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
PCI initialization is now done by PCI controller driver. In =
board_setup_arch
stage we don't need PCI init any more but swiotlb should be determined =
at this
stage.
=20
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
We now just apply this for mpc85xx_ds and qemu
=20
arch/powerpc/kernel/iommu.c.rej | 22 -----------------
arch/powerpc/platforms/85xx/common.c | 9 +++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 38 =
From: Kumar Gala <hidden> Date: 2012-07-26 17:53:17
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
We unified the Freescale pci/pcie initialization by changing the =
fsl_pci
to a platform driver. In previous PCI code architecture the =
initialization
routine is called at board_setup_arch stage. Now the initialization is =
done
in probe function which is architectural better. Also It's convenient =
for
adding PM support for PCI controller in later patch.
=20
One issue introduced by this architecture is the timing of =
swiotlb_init.
During PCI initialization the need of swiotlb is determined and this =
should
be done before swiotlb_init. So a new function to determine swiotlb by
parsing pci ranges is made. This function is called at =
board_setup_arch
stage which is earlier than swiotlb_init.
=20
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
=20
arch/powerpc/sysdev/fsl_pci.c | 155 =
{},
};
=20
-struct device_node *fsl_pci_primary;
-
-void __devinit fsl_pci_init(void)
+#ifdef CONFIG_SWIOTLB
+void pci_determine_swiotlb(void)
{
+ const u32 *ranges;
+ int rlen;
+ int pna;
+ int np;
struct device_node *node;
- struct pci_controller *hose;
- dma_addr_t max =3D 0xffffffff;
-
- /* Callers can specify the primary bus using other means. */
- if (!fsl_pci_primary) {
- /* If a PCI host bridge contains an ISA node, it's =
primary. */
- node =3D of_find_node_by_type(NULL, "isa");
- while ((fsl_pci_primary =3D of_get_parent(node))) {
- of_node_put(node);
- node =3D fsl_pci_primary;
-
- if (of_match_node(pci_ids, node))
- break;
- }
- }
+ int memno;
+ u32 pci_space;
+ unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+ unsigned long long pci_addr_lo =3D ULLONG_MAX;
+ unsigned long long pci_addr_hi =3D 0x0;
+ dma_addr_t pci_dma_sz;
=20
- node =3D NULL;
for_each_node_by_type(node, "pci") {
if (of_match_node(pci_ids, node)) {
- /*
- * If there's no PCI host bridge with ISA, =
From: Kumar Gala <hidden> Date: 2012-07-26 18:14:40
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
We unified the Freescale pci/pcie initialization by changing the =
fsl_pci
to a platform driver. In previous PCI code architecture the =
initialization
routine is called at board_setup_arch stage. Now the initialization is =
done
in probe function which is architectural better. Also It's convenient =
for
adding PM support for PCI controller in later patch.
=20
One issue introduced by this architecture is the timing of =
swiotlb_init.
During PCI initialization the need of swiotlb is determined and this =
should
be done before swiotlb_init. So a new function to determine swiotlb by
parsing pci ranges is made. This function is called at =
board_setup_arch
stage which is earlier than swiotlb_init.
=20
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
=20
arch/powerpc/sysdev/fsl_pci.c | 155 =
I'd like the SWIOTLB refactoring as a separate patch. Additionally, the =
order of patches should be as follows:
1. refactor PCI node parsing code
2. add pci_determine_swiotlb (should rename to =
fsl_pci_determine_swiotlb)
3. Determine primary bus by looking for ISA node
4. convert all boards over to fsl_pci_init
5. convert fsl pci to platform driver (edac and other fixes should be =
merged in here)
6. PM support
- k=
From: Kumar Gala <hidden> Date: 2012-07-26 18:21:51
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
PCI host bridge is primary bus if it contains an ISA node. But not all =
boards
fit this rule. Device tree should be updated for all these boards.
I don't really seen any reason for this patch. We can just use the code =
as Scott wrote it that sets fsl_pci_primary based on search for the isa =
node.
=20
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Using non-recursive function to find ISA under PCI
=20
arch/powerpc/include/asm/pci-bridge.h | 1 +
arch/powerpc/sysdev/fsl_pci.c | 31 =
Thanks for all your comments.
Sorry for the mistakes in this patchset.
I am just so eager to push them to upstream.
I will work on the comments very carfully.
Thanks.
-Hongtao.
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 2:22 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 2/5] powerpc/fsl-pci: Determine primary bus by
looking for ISA node
=20
=20
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
=20
quoted
PCI host bridge is primary bus if it contains an ISA node. But not all
boards
quoted
fit this rule. Device tree should be updated for all these boards.
=20
I don't really seen any reason for this patch. We can just use the code
as Scott wrote it that sets fsl_pci_primary based on search for the isa
node.
=20
quoted
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Using non-recursive function to find ISA under PCI
arch/powerpc/include/asm/pci-bridge.h | 1 +
arch/powerpc/sysdev/fsl_pci.c | 31 ++++++++++++++++++++++++--
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 2:22 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 2/5] powerpc/fsl-pci: Determine primary bus by
looking for ISA node
=20
=20
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
=20
quoted
PCI host bridge is primary bus if it contains an ISA node. But not all
boards
quoted
fit this rule. Device tree should be updated for all these boards.
=20
I don't really seen any reason for this patch. We can just use the code
as Scott wrote it that sets fsl_pci_primary based on search for the isa
node.
=20
I change the way of searching ISA node just because the platform driver
mechanism. Probe function of this driver will be called for each PCI
controller which means more than once. I think the Scott's way is not
perfectly match this situation. Anyway I will find a better way to solve
this by refactoring the Scott's method or using my own way.
Thanks.
-Hongtao.
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 2:15 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
=20
quoted
We unified the Freescale pci/pcie initialization by changing the
fsl_pci
quoted
to a platform driver. In previous PCI code architecture the
initialization
quoted
routine is called at board_setup_arch stage. Now the initialization is
done
quoted
in probe function which is architectural better. Also It's convenient
for
quoted
adding PM support for PCI controller in later patch.
One issue introduced by this architecture is the timing of swiotlb_init=
.
quoted
During PCI initialization the need of swiotlb is determined and this
should
quoted
be done before swiotlb_init. So a new function to determine swiotlb by
parsing pci ranges is made. This function is called at board_setup_arch
stage which is earlier than swiotlb_init.
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
arch/powerpc/sysdev/fsl_pci.c | 155 ++++++++++++++++++++++++++++++++--
=20
I'd like the SWIOTLB refactoring as a separate patch. Additionally, the
order of patches should be as follows:
=20
1. refactor PCI node parsing code
2. add pci_determine_swiotlb (should rename to fsl_pci_determine_swiotlb)
3. Determine primary bus by looking for ISA node
4. convert all boards over to fsl_pci_init
5. convert fsl pci to platform driver (edac and other fixes should be
merged in here)
6. PM support
=20
- k
Should I convert all boards over to fsl_pci_init first and then convert the=
m
over to platform driver again or just convert them direct to platform drive=
r?
Thanks.
-Hongtao.
Hi kumar,
I know "duplicate code from pci_process_bridge_OF_ranges()" is
hard to accept but "refactor the code to have a shared function"
is knotty. Actually this is the reason I didn't do the refactor.
Here is the situation:
First, pci_process_bridge_OF_ranges() is a common code using by
so many pci client.
Second, the contents of pci_process_bridge_OF_ranges() twisted
together. It's hard to decouple the function I need for determining
swiotlb with other contents. I tried and found a way to do this
but the shared function need so many parameters which is also
unacceptable.=20
Third, my function to determine swiotlb should know the start
and the end of pci mem space address for all the controllers.
Note that the end of address is for determining where to map
PEXCSRBAR.
If you have any idea for this please let me know.
Thanks.
-Hongtao.
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 1:53 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
=20
quoted
We unified the Freescale pci/pcie initialization by changing the
fsl_pci
quoted
to a platform driver. In previous PCI code architecture the
initialization
quoted
routine is called at board_setup_arch stage. Now the initialization is
done
quoted
in probe function which is architectural better. Also It's convenient
for
quoted
adding PM support for PCI controller in later patch.
One issue introduced by this architecture is the timing of swiotlb_init=
.
quoted
During PCI initialization the need of swiotlb is determined and this
should
quoted
be done before swiotlb_init. So a new function to determine swiotlb by
parsing pci ranges is made. This function is called at board_setup_arch
stage which is earlier than swiotlb_init.
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
arch/powerpc/sysdev/fsl_pci.c | 155 ++++++++++++++++++++++++++++++++--
{},
};
-struct device_node *fsl_pci_primary;
-
-void __devinit fsl_pci_init(void)
+#ifdef CONFIG_SWIOTLB
+void pci_determine_swiotlb(void)
{
+ const u32 *ranges;
+ int rlen;
+ int pna;
+ int np;
struct device_node *node;
- struct pci_controller *hose;
- dma_addr_t max =3D 0xffffffff;
-
- /* Callers can specify the primary bus using other means. */
- if (!fsl_pci_primary) {
- /* If a PCI host bridge contains an ISA node, it's primary.
*/
quoted
- node =3D of_find_node_by_type(NULL, "isa");
- while ((fsl_pci_primary =3D of_get_parent(node))) {
- of_node_put(node);
- node =3D fsl_pci_primary;
-
- if (of_match_node(pci_ids, node))
- break;
- }
- }
+ int memno;
+ u32 pci_space;
+ unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+ unsigned long long pci_addr_lo =3D ULLONG_MAX;
+ unsigned long long pci_addr_hi =3D 0x0;
+ dma_addr_t pci_dma_sz;
- node =3D NULL;
for_each_node_by_type(node, "pci") {
if (of_match_node(pci_ids, node)) {
- /*
- * If there's no PCI host bridge with ISA, arbitrarily
- * designate one as primary. This can go away once
- * various bugs with primary-less systems are fixed.
- */
- if (!fsl_pci_primary)
- fsl_pci_primary =3D node;
-
- fsl_add_bridge(node, fsl_pci_primary =3D=3D node);
- hose =3D pci_find_hose_for_OF_device(node);
- max =3D min(max, hose->dma_window_base_cur +
- hose->dma_window_size);
+ memno =3D 0;
+ pna =3D of_n_addr_cells(node);
+ np =3D pna + 5;
=20
Don't duplicate code from pci_process_bridge_OF_ranges(), refactor the
code to have a shared function:
=20
quoted
+ /* Get ranges property */
+ ranges =3D of_get_property(node, "ranges", &rlen);
+ if (ranges =3D=3D NULL)
+ return;
+
+ /* Parse outbound MEM window range */
+ while ((rlen -=3D np * 4) >=3D 0) {
+ /* Read next ranges element */
+ pci_space =3D ranges[0];
+ if (!((pci_space >> 24) & 0x2)) {
+ ranges +=3D np;
+ break;
+ }
+ pci_addr =3D of_read_number(ranges + 1, 2);
+ cpu_addr =3D of_translate_address(
+ node, ranges + 3);
+ size =3D of_read_number(ranges + pna + 3, 2);
+ ranges +=3D np;
+
+ /*
+ * If we failed translation or got a zero-sized
+ * region (some FW try to feed us with non
+ * sensical zero sized regions such as power3
+ * which look like some kind of attempt at
+ * exposing the VGA memory hole)
+ */
+ if (cpu_addr =3D=3D OF_BAD_ADDR || size =3D=3D 0)
+ continue;
+
+ /*
+ * Now consume following elements while they
+ * are contiguous
+ */
+ for (; rlen >=3D np * sizeof(u32);
+ ranges +=3D np, rlen -=3D np * 4) {
+ if (ranges[0] !=3D pci_space)
+ break;
+ pci_next =3D of_read_number(ranges + 1,
+ 2);
+ cpu_next =3D of_translate_address(node,
+ ranges + 3);
+ if (pci_next !=3D pci_addr + size ||
+ cpu_next !=3D cpu_addr + size)
+ break;
+ size +=3D of_read_number(
+ ranges + pna + 3, 2);
+ }
+
+ /* We support only 3 memory ranges */
+ if (memno >=3D 3) {
+ printk(KERN_INFO
+ " \\--> Skipped (too
many) !\n");
quoted
+ continue;
+ }
+
+ pci_addr_lo =3D min(pci_addr, pci_addr_lo);
+ pci_addr_hi =3D max(pci_addr + size, pci_addr_hi);
+ memno++;
+ }
}
}
-#ifdef CONFIG_SWIOTLB
+ /* Get PEXCSRBAR size (equal to CCSR size) */
+ node =3D of_find_node_by_type(NULL, "soc");
+ ranges =3D of_get_property(node, "ranges", &rlen);
+ if (ranges =3D=3D NULL)
+ return;
+
+ size =3D of_read_number(ranges + 3, 1);
+ of_node_put(node);
+
+ if (pci_addr_hi < (0x100000000ull - size))
+ pci_dma_sz =3D pci_addr_lo;
+ else
+ pci_dma_sz =3D pci_addr_lo - size;
+
/*
* if we couldn't map all of DRAM via the dma windows
* we need SWIOTLB to handle buffers located outside of
* dma capable memory region
*/
- if (memblock_end_of_DRAM() - 1 > max) {
+ if (memblock_end_of_DRAM() > pci_dma_sz) {
ppc_swiotlb_enable =3D 1;
set_pci_dma_ops(&swiotlb_dma_ops);
- ppc_md.pci_dma_dev_setup =3D pci_dma_dev_setup_swiotlb;
+ ppc_md.pci_dma_dev_setup =3D
+ pci_dma_dev_setup_swiotlb;
From: Kumar Gala <hidden> Date: 2012-07-27 12:47:55
On Jul 27, 2012, at 3:35 AM, Jia Hongtao-B38951 wrote:
=20
=20
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 2:15 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
=20
quoted
We unified the Freescale pci/pcie initialization by changing the
fsl_pci
quoted
to a platform driver. In previous PCI code architecture the
initialization
quoted
routine is called at board_setup_arch stage. Now the initialization =
is
quoted
done
quoted
in probe function which is architectural better. Also It's =
convenient
quoted
for
quoted
adding PM support for PCI controller in later patch.
=20
One issue introduced by this architecture is the timing of =
swiotlb_init.
quoted
quoted
During PCI initialization the need of swiotlb is determined and this
should
quoted
be done before swiotlb_init. So a new function to determine swiotlb =
by
quoted
quoted
parsing pci ranges is made. This function is called at =
board_setup_arch
quoted
quoted
stage which is earlier than swiotlb_init.
=20
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
=20
arch/powerpc/sysdev/fsl_pci.c | 155 =
=20
I'd like the SWIOTLB refactoring as a separate patch. Additionally, =
the
quoted
order of patches should be as follows:
=20
1. refactor PCI node parsing code
2. add pci_determine_swiotlb (should rename to =
fsl_pci_determine_swiotlb)
quoted
3. Determine primary bus by looking for ISA node
4. convert all boards over to fsl_pci_init
5. convert fsl pci to platform driver (edac and other fixes should be
merged in here)
6. PM support
=20
- k
=20
Should I convert all boards over to fsl_pci_init first and then =
convert them
over to platform driver again or just convert them direct to platform =
driver?
Yes do the fsl_pci_init conversion first. The reason is we should NOT =
break functionality from one patch to another.
- k=
From: Scott Wood <hidden> Date: 2012-07-27 20:24:41
On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
Hi kumar,
I know "duplicate code from pci_process_bridge_OF_ranges()" is
hard to accept but "refactor the code to have a shared function"
is knotty. Actually this is the reason I didn't do the refactor.
Maybe we should keep doing the init early? We could still have a
platform device for the PM stuff, but some init would be done before probe.
Another possibility is to try to handle swiotlb init later -- possibly
by reserving memory for it if the platform indicates it's a possibility
that it will be needed, then freeing the memory if it's not needed.
-Scott
From: Kumar Gala <hidden> Date: 2012-07-27 21:17:30
On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
quoted
Hi kumar,
=20
I know "duplicate code from pci_process_bridge_OF_ranges()" is
hard to accept but "refactor the code to have a shared function"
is knotty. Actually this is the reason I didn't do the refactor.
=20
Maybe we should keep doing the init early? We could still have a
platform device for the PM stuff, but some init would be done before =
probe.
=20
Another possibility is to try to handle swiotlb init later -- possibly
by reserving memory for it if the platform indicates it's a =
possibility
that it will be needed, then freeing the memory if it's not needed.
=20
-Scott
I think the first option seems reasonable. Can we leave fsl_pci_init() =
as we now have it and just have the platform driver deal with PM restore =
via calling setup_pci_atmu() [probably need to update setup_pci_atmu to =
handle restore case, but seems like minor changes]
- k
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 8:47 PM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 27, 2012, at 3:35 AM, Jia Hongtao-B38951 wrote:
=20
quoted
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 2:15 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
quoted
We unified the Freescale pci/pcie initialization by changing the
fsl_pci
quoted
to a platform driver. In previous PCI code architecture the
initialization
quoted
routine is called at board_setup_arch stage. Now the initialization
is
quoted
quoted
done
quoted
in probe function which is architectural better. Also It's convenient
for
quoted
adding PM support for PCI controller in later patch.
One issue introduced by this architecture is the timing of
swiotlb_init.
quoted
quoted
quoted
During PCI initialization the need of swiotlb is determined and this
should
quoted
be done before swiotlb_init. So a new function to determine swiotlb
by
quoted
quoted
quoted
parsing pci ranges is made. This function is called at
board_setup_arch
quoted
quoted
quoted
stage which is earlier than swiotlb_init.
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
arch/powerpc/sysdev/fsl_pci.c | 155
I'd like the SWIOTLB refactoring as a separate patch. Additionally,
the
quoted
quoted
order of patches should be as follows:
1. refactor PCI node parsing code
2. add pci_determine_swiotlb (should rename to
fsl_pci_determine_swiotlb)
quoted
quoted
3. Determine primary bus by looking for ISA node
4. convert all boards over to fsl_pci_init
5. convert fsl pci to platform driver (edac and other fixes should be
merged in here)
6. PM support
- k
Should I convert all boards over to fsl_pci_init first and then convert
them
quoted
over to platform driver again or just convert them direct to platform
driver?
=20
Yes do the fsl_pci_init conversion first. The reason is we should NOT
break functionality from one patch to another.
=20
- k
Actually, the functionality is not broken, other boards just use the old
Way to init pci controller and it still works.
-Hongtao.
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Saturday, July 28, 2012 5:17 AM
To: Wood Scott-B07421
Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
=20
quoted
On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
quoted
Hi kumar,
I know "duplicate code from pci_process_bridge_OF_ranges()" is
hard to accept but "refactor the code to have a shared function"
is knotty. Actually this is the reason I didn't do the refactor.
Maybe we should keep doing the init early? We could still have a
platform device for the PM stuff, but some init would be done before
probe.
quoted
Another possibility is to try to handle swiotlb init later -- possibly
by reserving memory for it if the platform indicates it's a possibility
that it will be needed, then freeing the memory if it's not needed.
-Scott
=20
I think the first option seems reasonable. Can we leave fsl_pci_init()
as we now have it and just have the platform driver deal with PM restore
via calling setup_pci_atmu() [probably need to update setup_pci_atmu to
handle restore case, but seems like minor changes]
=20
- k
=20
I think the second option is better if it's hard to decouple swiotlb
determination from pci init. I believe the better architecture that
PCI init in probe function of platform driver will bring us considerable
advantage. I really like to keep the completion of pci controller
platform driver not only for PM support but also for pci init.
-Hongtao.=20
From: Kumar Gala <hidden> Date: 2012-07-30 14:46:54
On Jul 30, 2012, at 3:07 AM, Jia Hongtao-B38951 wrote:
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 8:47 PM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 27, 2012, at 3:35 AM, Jia Hongtao-B38951 wrote:
=20
quoted
=20
=20
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 2:15 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li =
We unified the Freescale pci/pcie initialization by changing the
fsl_pci
quoted
to a platform driver. In previous PCI code architecture the
initialization
quoted
routine is called at board_setup_arch stage. Now the =
initialization
quoted
is
quoted
quoted
done
quoted
in probe function which is architectural better. Also It's =
convenient
quoted
quoted
quoted
for
quoted
adding PM support for PCI controller in later patch.
=20
One issue introduced by this architecture is the timing of
swiotlb_init.
quoted
quoted
quoted
During PCI initialization the need of swiotlb is determined and =
this
quoted
quoted
quoted
should
quoted
be done before swiotlb_init. So a new function to determine =
swiotlb
quoted
by
quoted
quoted
quoted
parsing pci ranges is made. This function is called at
board_setup_arch
quoted
quoted
quoted
stage which is earlier than swiotlb_init.
=20
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
=20
arch/powerpc/sysdev/fsl_pci.c | 155
=20
I'd like the SWIOTLB refactoring as a separate patch. =
Additionally,
quoted
the
quoted
quoted
order of patches should be as follows:
=20
1. refactor PCI node parsing code
2. add pci_determine_swiotlb (should rename to
fsl_pci_determine_swiotlb)
quoted
quoted
3. Determine primary bus by looking for ISA node
4. convert all boards over to fsl_pci_init
5. convert fsl pci to platform driver (edac and other fixes should =
be
quoted
quoted
quoted
merged in here)
6. PM support
=20
- k
=20
Should I convert all boards over to fsl_pci_init first and then =
convert
quoted
them
quoted
over to platform driver again or just convert them direct to =
platform
quoted
driver?
=20
Yes do the fsl_pci_init conversion first. The reason is we should =
NOT
quoted
break functionality from one patch to another.
=20
- k
=20
=20
Actually, the functionality is not broken, other boards just use the =
old
Way to init pci controller and it still works.
How do you figure? The platform driver is going to get called on boards =
not yet converted. So than you will get 2 different inits of PCI going =
on.
- k=
From: Kumar Gala <hidden> Date: 2012-07-30 14:49:12
On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
=20
=20
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Saturday, July 28, 2012 5:17 AM
To: Wood Scott-B07421
Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood =
Scott-B07421;
quoted
Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
=20
quoted
On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
quoted
Hi kumar,
=20
I know "duplicate code from pci_process_bridge_OF_ranges()" is
hard to accept but "refactor the code to have a shared function"
is knotty. Actually this is the reason I didn't do the refactor.
=20
Maybe we should keep doing the init early? We could still have a
platform device for the PM stuff, but some init would be done before
probe.
quoted
=20
Another possibility is to try to handle swiotlb init later -- =
possibly
quoted
quoted
by reserving memory for it if the platform indicates it's a =
possibility
quoted
quoted
that it will be needed, then freeing the memory if it's not needed.
=20
-Scott
=20
I think the first option seems reasonable. Can we leave =
fsl_pci_init()
quoted
as we now have it and just have the platform driver deal with PM =
restore
quoted
via calling setup_pci_atmu() [probably need to update setup_pci_atmu =
to
quoted
handle restore case, but seems like minor changes]
=20
- k
=20
=20
=20
I think the second option is better if it's hard to decouple swiotlb
determination from pci init. I believe the better architecture that
PCI init in probe function of platform driver will bring us =
considerable
advantage. I really like to keep the completion of pci controller
platform driver not only for PM support but also for pci init.
=20
-Hongtao.=20
=20
Shifting of swiotlb init has a lot more issues. Why do we need to do =
the PCI init in probe?
- k=
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Monday, July 30, 2012 10:47 PM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 30, 2012, at 3:07 AM, Jia Hongtao-B38951 wrote:
=20
quoted
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 8:47 PM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
On Jul 27, 2012, at 3:35 AM, Jia Hongtao-B38951 wrote:
quoted
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, July 27, 2012 2:15 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
quoted
We unified the Freescale pci/pcie initialization by changing the
fsl_pci
quoted
to a platform driver. In previous PCI code architecture the
initialization
quoted
routine is called at board_setup_arch stage. Now the initialization
is
quoted
quoted
done
quoted
in probe function which is architectural better. Also It's
convenient
quoted
quoted
quoted
quoted
for
quoted
adding PM support for PCI controller in later patch.
One issue introduced by this architecture is the timing of
swiotlb_init.
quoted
quoted
quoted
During PCI initialization the need of swiotlb is determined and
this
quoted
quoted
quoted
quoted
should
quoted
be done before swiotlb_init. So a new function to determine swiotlb
by
quoted
quoted
quoted
parsing pci ranges is made. This function is called at
board_setup_arch
quoted
quoted
quoted
stage which is earlier than swiotlb_init.
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
arch/powerpc/sysdev/fsl_pci.c | 155
I'd like the SWIOTLB refactoring as a separate patch. Additionally,
the
quoted
quoted
order of patches should be as follows:
1. refactor PCI node parsing code
2. add pci_determine_swiotlb (should rename to
fsl_pci_determine_swiotlb)
quoted
quoted
3. Determine primary bus by looking for ISA node
4. convert all boards over to fsl_pci_init
5. convert fsl pci to platform driver (edac and other fixes should
be
quoted
quoted
quoted
quoted
merged in here)
6. PM support
- k
Should I convert all boards over to fsl_pci_init first and then
convert
quoted
quoted
them
quoted
over to platform driver again or just convert them direct to platform
driver?
Yes do the fsl_pci_init conversion first. The reason is we should NOT
break functionality from one patch to another.
- k
Actually, the functionality is not broken, other boards just use the
old
quoted
Way to init pci controller and it still works.
=20
How do you figure? The platform driver is going to get called on boards
not yet converted. So than you will get 2 different inits of PCI going
on.
=20
- k
In Scott's patch set no platform driver used. fsl_pci_init is just a unifie=
d
routine function for all boards to call. Now other boards in which fsl_pci_=
init
is not called just use the old way to init.
-Hongtao.
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Monday, July 30, 2012 10:47 PM
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
=20
quoted
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Saturday, July 28, 2012 5:17 AM
To: Wood Scott-B07421
Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-
B07421;
quoted
quoted
Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
quoted
On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
quoted
Hi kumar,
I know "duplicate code from pci_process_bridge_OF_ranges()" is
hard to accept but "refactor the code to have a shared function"
is knotty. Actually this is the reason I didn't do the refactor.
Maybe we should keep doing the init early? We could still have a
platform device for the PM stuff, but some init would be done before
probe.
quoted
Another possibility is to try to handle swiotlb init later --
possibly
quoted
quoted
quoted
by reserving memory for it if the platform indicates it's a
possibility
quoted
quoted
quoted
that it will be needed, then freeing the memory if it's not needed.
-Scott
I think the first option seems reasonable. Can we leave fsl_pci_init(=
)
quoted
quoted
as we now have it and just have the platform driver deal with PM
restore
quoted
quoted
via calling setup_pci_atmu() [probably need to update setup_pci_atmu
to
quoted
quoted
handle restore case, but seems like minor changes]
- k
I think the second option is better if it's hard to decouple swiotlb
determination from pci init. I believe the better architecture that
PCI init in probe function of platform driver will bring us
considerable
quoted
advantage. I really like to keep the completion of pci controller
platform driver not only for PM support but also for pci init.
-Hongtao.
=20
Shifting of swiotlb init has a lot more issues. Why do we need to do the
PCI init in probe?
=20
- k
I investigated the swiotlb init thing and found that in x86 swiotlb init is
done first and free if we don't need it.
-Hongtao.
On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala [off-list ref] wrote:
On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
quoted
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Saturday, July 28, 2012 5:17 AM
To: Wood Scott-B07421
Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
quoted
On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
quoted
Hi kumar,
I know "duplicate code from pci_process_bridge_OF_ranges()" is
hard to accept but "refactor the code to have a shared function"
is knotty. Actually this is the reason I didn't do the refactor.
Maybe we should keep doing the init early? We could still have a
platform device for the PM stuff, but some init would be done before
probe.
quoted
Another possibility is to try to handle swiotlb init later -- possibly
by reserving memory for it if the platform indicates it's a possibility
that it will be needed, then freeing the memory if it's not needed.
-Scott
I think the first option seems reasonable. Can we leave fsl_pci_init()
as we now have it and just have the platform driver deal with PM restore
via calling setup_pci_atmu() [probably need to update setup_pci_atmu to
handle restore case, but seems like minor changes]
- k
I think the second option is better if it's hard to decouple swiotlb
determination from pci init. I believe the better architecture that
PCI init in probe function of platform driver will bring us considerable
advantage. I really like to keep the completion of pci controller
platform driver not only for PM support but also for pci init.
-Hongtao.
Shifting of swiotlb init has a lot more issues. Why do we need to do the PCI init in probe?
The ordering issues are introduced by swiotlb. And the ideal way is
to solve the problem within swiotlb instead of changing PCI to
workaround it. Take the implementation of x86 as reference it's
possible to be addressed bu allocating first and free later approach.
It is common sense that the initialization of a device is in the probe
function of the driver of the device. And the change will provide
better unification of PCI controller code. The PCI controller is
generic enough not to be taken care of at the platform area.
Leo
From: Kumar Gala <hidden> Date: 2012-07-31 13:37:32
On Jul 31, 2012, at 2:21 AM, Li Yang wrote:
On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala =
[off-list ref] wrote:
quoted
=20
On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
=20
quoted
=20
=20
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Saturday, July 28, 2012 5:17 AM
To: Wood Scott-B07421
Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood =
Scott-B07421;
quoted
quoted
quoted
Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
=20
quoted
On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
quoted
Hi kumar,
=20
I know "duplicate code from pci_process_bridge_OF_ranges()" is
hard to accept but "refactor the code to have a shared function"
is knotty. Actually this is the reason I didn't do the refactor.
=20
Maybe we should keep doing the init early? We could still have a
platform device for the PM stuff, but some init would be done =
before
quoted
quoted
quoted
probe.
quoted
=20
Another possibility is to try to handle swiotlb init later -- =
possibly
quoted
quoted
quoted
quoted
by reserving memory for it if the platform indicates it's a =
possibility
quoted
quoted
quoted
quoted
that it will be needed, then freeing the memory if it's not =
needed.
quoted
quoted
quoted
quoted
=20
-Scott
=20
I think the first option seems reasonable. Can we leave =
fsl_pci_init()
quoted
quoted
quoted
as we now have it and just have the platform driver deal with PM =
restore
quoted
quoted
quoted
via calling setup_pci_atmu() [probably need to update =
setup_pci_atmu to
quoted
quoted
quoted
handle restore case, but seems like minor changes]
=20
- k
=20
=20
=20
I think the second option is better if it's hard to decouple swiotlb
determination from pci init. I believe the better architecture that
PCI init in probe function of platform driver will bring us =
considerable
quoted
quoted
advantage. I really like to keep the completion of pci controller
platform driver not only for PM support but also for pci init.
=20
-Hongtao.
=20
=20
Shifting of swiotlb init has a lot more issues. Why do we need to do =
the PCI init in probe?
=20
The ordering issues are introduced by swiotlb. And the ideal way is
to solve the problem within swiotlb instead of changing PCI to
workaround it. Take the implementation of x86 as reference it's
possible to be addressed bu allocating first and free later approach.
=20
It is common sense that the initialization of a device is in the probe
function of the driver of the device. And the change will provide
better unification of PCI controller code. The PCI controller is
generic enough not to be taken care of at the platform area.
=20
Leo
Than lets look at going with that approach.. Be careful with impact on =
other users of swiotlb on PPC, I believe one 44x board uses swiotlb.
- k=
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Tuesday, July 31, 2012 9:38 PM
To: Li Yang-R58472
Cc: Jia Hongtao-B38951; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
=20
=20
On Jul 31, 2012, at 2:21 AM, Li Yang wrote:
=20
quoted
On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala <galak@kernel.crashing.org=
wrote:
quoted
quoted
On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
quoted
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Saturday, July 28, 2012 5:17 AM
To: Wood Scott-B07421
Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-
B07421;
quoted
quoted
quoted
quoted
Li Yang-R58472
Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
initialization code
On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
quoted
On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
quoted
Hi kumar,
I know "duplicate code from pci_process_bridge_OF_ranges()" is
hard to accept but "refactor the code to have a shared function"
is knotty. Actually this is the reason I didn't do the refactor.
Maybe we should keep doing the init early? We could still have a
platform device for the PM stuff, but some init would be done
before
quoted
quoted
quoted
quoted
probe.
quoted
Another possibility is to try to handle swiotlb init later --
possibly
quoted
quoted
quoted
quoted
quoted
by reserving memory for it if the platform indicates it's a
possibility
quoted
quoted
quoted
quoted
quoted
that it will be needed, then freeing the memory if it's not needed.
-Scott
I think the first option seems reasonable. Can we leave
fsl_pci_init()
quoted
quoted
quoted
quoted
as we now have it and just have the platform driver deal with PM
restore
quoted
quoted
quoted
quoted
via calling setup_pci_atmu() [probably need to update setup_pci_atmu
to
quoted
quoted
quoted
quoted
handle restore case, but seems like minor changes]
- k
I think the second option is better if it's hard to decouple swiotlb
determination from pci init. I believe the better architecture that
PCI init in probe function of platform driver will bring us
considerable
quoted
quoted
quoted
advantage. I really like to keep the completion of pci controller
platform driver not only for PM support but also for pci init.
-Hongtao.
Shifting of swiotlb init has a lot more issues. Why do we need to do
the PCI init in probe?
quoted
The ordering issues are introduced by swiotlb. And the ideal way is
to solve the problem within swiotlb instead of changing PCI to
workaround it. Take the implementation of x86 as reference it's
possible to be addressed bu allocating first and free later approach.
It is common sense that the initialization of a device is in the probe
function of the driver of the device. And the change will provide
better unification of PCI controller code. The PCI controller is
generic enough not to be taken care of at the platform area.
Leo
=20
Than lets look at going with that approach.. Be careful with impact on
other users of swiotlb on PPC, I believe one 44x board uses swiotlb.
=20
- k
I will be careful with this approach.
I have already noticed 44x. Thank you all the same.
-Hongtao.
We unified the Freescale pci/pcie initialization by changing the fsl_pci
to a platform driver. In previous PCI code architecture the initialization
routine is called at board_setup_arch stage. Now the initialization is done
in probe function which is architectural better. Also It's convenient for
adding PM support for PCI controller in later patch.
One issue introduced by this architecture is the timing of swiotlb_init.
During PCI initialization the need of swiotlb is determined and this should
be done before swiotlb_init. So a new function to determine swiotlb by
parsing pci ranges is made. This function is called at board_setup_arch
stage which is earlier than swiotlb_init.
Signed-off-by: Jia Hongtao <redacted>
Signed-off-by: Li Yang <redacted>
---
Changed for V3:
- Rebase the patch set on the latest tree
- merge PCI unify and swiotlb patch into one
arch/powerpc/sysdev/fsl_pci.c | 155 ++++++++++++++++++++++++++++++++---------
arch/powerpc/sysdev/fsl_pci.h | 9 +--
2 files changed, 125 insertions(+), 39 deletions(-)
I'd like the SWIOTLB refactoring as a separate patch. Additionally, the order of patches should be as follows:
1. refactor PCI node parsing code
2. add pci_determine_swiotlb (should rename to fsl_pci_determine_swiotlb)
3. Determine primary bus by looking for ISA node
4. convert all boards over to fsl_pci_init
5. convert fsl pci to platform driver (edac and other fixes should be merged in here)
6. PM support
Could you add:
7. Fix PPC_INDIRECT_TYPE_NO_PCIE_LINK issue. The link is only probed at init and a subsequent
pci/rescan does not change that. See mail thread titled:
mpc8xxx PCIe hotplug needs fixing, some clues ..
Jocke