diff mbox

[4/5] powerpc/powernv: Pick up correct number of PEs

Message ID 1375260424-20777-4-git-send-email-shangw@linux.vnet.ibm.com (mailing list archive)
State Rejected
Headers show

Commit Message

Gavin Shan July 31, 2013, 8:47 a.m. UTC
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(-)

Comments

Benjamin Herrenschmidt July 31, 2013, 9:18 a.m. UTC | #1
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;
Gavin Shan Aug. 1, 2013, 4:24 a.m. UTC | #2
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
Benjamin Herrenschmidt Aug. 1, 2013, 4:42 a.m. UTC | #3
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 mbox

Patch

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;