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

[Oliver O'Halloran]

On Thu, Jan 23, 2020 at 2:03 AM Frederic Barrat <fbarrat at linux.ibm.com> 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.
>
> Reviewed-by: Reza Arbab <arbab at linux.ibm.com>
> Reviewed-by: Andrew Donnellan <ajd at linux.ibm.com>
> Signed-off-by: Frederic Barrat <fbarrat at linux.ibm.com>
> ---
>
> Resending series after rebasing to current master, since it was no
> longer applying cleanly. I've picked up the Reviewed-by's from v2. No
> code change.

Thanks, series to master as da28a6642b79a68d6c8773f149692a3702a31240

Sorry about the delay.