Message ID | 1375260424-20777-4-git-send-email-shangw@linux.vnet.ibm.com (mailing list archive) |
---|---|
State | Rejected, archived |
Headers | show |
On Wed, 2013-07-31 at 16:47 +0800, Gavin Shan wrote: > Usually, the property "ibm,opal-num-pes" of PHB dev-tree node > indicates the number of total PEs. If that property isn't existing > or valid, we should fall back to pick the correct number of total > PEs according to PHB type: IODA1 or IODA2. Is that correct ? Don't we get the total number of PEs from a config register on the bridge ? I didn't think the IODA architecture specified the total number of PE of a given implementation... For example, does Torrent implement 128 ? I'd rather stick to safe here, if the firmware doesn't say, just use one. Now some of the PHB registers are actually architected in IODA afaik, so we could just go look but let's not make a precedent here. Cheers, Ben. > Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> > --- > arch/powerpc/platforms/powernv/pci-ioda.c | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c > index 829047b..6386bb4 100644 > --- a/arch/powerpc/platforms/powernv/pci-ioda.c > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c > @@ -1172,11 +1172,14 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np, > > /* Initialize more IODA stuff */ > prop32 = of_get_property(np, "ibm,opal-num-pes", NULL); > - if (!prop32) > - phb->ioda.total_pe = 1; > - else > + if (prop32) > phb->ioda.total_pe = *prop32; > - > + else if (phb->type == PNV_PHB_IODA1) > + phb->ioda.total_pe = 128; > + else if (phb->type == PNV_PHB_IODA2) > + phb->ioda.total_pe = 256; > + else > + phb->ioda.total_pe = 1; > phb->ioda.m32_size = resource_size(&hose->mem_resources[0]); > /* FW Has already off top 64k of M32 space (MSI space) */ > phb->ioda.m32_size += 0x10000;
On Wed, Jul 31, 2013 at 07:18:46PM +1000, Benjamin Herrenschmidt wrote: >On Wed, 2013-07-31 at 16:47 +0800, Gavin Shan wrote: >> Usually, the property "ibm,opal-num-pes" of PHB dev-tree node >> indicates the number of total PEs. If that property isn't existing >> or valid, we should fall back to pick the correct number of total >> PEs according to PHB type: IODA1 or IODA2. > >Is that correct ? Don't we get the total number of PEs from a config >register on the bridge ? I didn't think the IODA architecture specified >the total number of PE of a given implementation... > For now, the firmware has fixed values (1/128/256), which isn't figured out from EEH capability register. That might be something to do later for the f/w. >For example, does Torrent implement 128 ? > I don't know what's "Torrent" :-) >I'd rather stick to safe here, if the firmware doesn't say, just use >one. > >Now some of the PHB registers are actually architected in IODA afaik, so >we could just go look but let's not make a precedent here. > Ok. Thanks, Ben. Please drop this one :-) Thanks, Gavin
On Thu, 2013-08-01 at 12:24 +0800, Gavin Shan wrote: > at correct ? Don't we get the total number of PEs from a config > >register on the bridge ? I didn't think the IODA architecture specified > >the total number of PE of a given implementation... > > > > For now, the firmware has fixed values (1/128/256), which isn't figured > out from EEH capability register. That might be something to do later > for the f/w. Sure but we can fix the firmware easily, we need per-chip code in there anyway, while in Linux, we mostly avoid exposing the specifics of a given implementation of the architecture, we only expose the architectural version (IODA1 vs IODA2). > >For example, does Torrent implement 128 ? > > > I don't know what's "Torrent" :-) It's one of our IO chips for P7 :-) It has a built-in HFI (sort-of infiniband thingy) and implements PCIe slots with IODA1. It has *some* differences to P7IOC however. > >I'd rather stick to safe here, if the firmware doesn't say, just use > >one. > > > >Now some of the PHB registers are actually architected in IODA afaik, so > >we could just go look but let's not make a precedent here. > > > > Ok. Thanks, Ben. Please drop this one :-) Will do :-) Cheers, Ben.
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 829047b..6386bb4 100644 --- a/arch/powerpc/platforms/powernv/pci-ioda.c +++ b/arch/powerpc/platforms/powernv/pci-ioda.c @@ -1172,11 +1172,14 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np, /* Initialize more IODA stuff */ prop32 = of_get_property(np, "ibm,opal-num-pes", NULL); - if (!prop32) - phb->ioda.total_pe = 1; - else + if (prop32) phb->ioda.total_pe = *prop32; - + else if (phb->type == PNV_PHB_IODA1) + phb->ioda.total_pe = 128; + else if (phb->type == PNV_PHB_IODA2) + phb->ioda.total_pe = 256; + else + phb->ioda.total_pe = 1; phb->ioda.m32_size = resource_size(&hose->mem_resources[0]); /* FW Has already off top 64k of M32 space (MSI space) */ phb->ioda.m32_size += 0x10000;
Usually, the property "ibm,opal-num-pes" of PHB dev-tree node indicates the number of total PEs. If that property isn't existing or valid, we should fall back to pick the correct number of total PEs according to PHB type: IODA1 or IODA2. Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> --- arch/powerpc/platforms/powernv/pci-ioda.c | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-)