[Skiboot] [PATCH v2 1/4] npu2: Rework phb-index assignments for virtual PHBs

[Reza Arbab]

On Fri, Aug 09, 2019 at 03:05:31PM +0200, Frederic Barrat wrote:
>Until now, opencapi PHBs were not using the 'ibm,phb-index' property,
>as it was thought unnecessary. For nvlink, a phb-index was associated
>to the npu when parsing hdat data, and the nvlink PHB was reusing the
>same value.
>
>It turns out it helps to have the 'ibm,phb-index' property for
>opencapi PHBs after all. Otherwise it can lead to wrong results on
>platforms like mihawk when trying to match entries in the slot
>table. We end up with an opencapi device inheriting wrong properties
>in the device tree, because match_slot_phb_entry() default to
>phb-index 0 if it cannot find the property. Though it doesn't seem to
>cause any harm, it's wrong and a future patch is expected to start
>using the slot table for opencapi, so it needs fixing.
>
>The twist is that with opencapi, we can have multiple virtual PHBs for
>a single NPU on P9. There's one PHB per (opencapi) brick. Therefore
>there's no 1-to-1 mapping between the NPU and PHB index and it no
>longer makes sense to associate a phb-index to a npu.
>
>With this patch, opencapi PHBs created under a NPU use a fixed mapping
>for their phb-index, based on the brick index. The range of possible
>values is 7 to 12. Because there can only be one nvlink PHB per NPU,
>it is always using a phb-index of 7.
>
>A side effect is that 2 virtual PHBs on 2 different chips can have the
>same phb-index, which is similar to what happens for 'real' PCI PHBs,
>but is different from what was happening on a nvlink-only witherspoon
>so far.
>
>Signed-off-by: Frederic Barrat <fbarrat at linux.ibm.com>

Reviewed-by: Reza Arbab <arbab at linux.ibm.com>

-- 
Reza Arbab