[Skiboot] [PATCH 03/16] [PATCH 03/16] opencapi5: introduce support

[Frederic Barrat]

On 20/08/2021 11:45, Christophe Lombard wrote:
> OpenCapi5 is included in the P10 chip. This requires OCAPI capable PHYs,
> Datalink Layer Logic and Transaction Layer Logic to be included.
> The PHYs are the physical connection to the OCAPI interconnect.
> The Datalink Layer provides link training.
> The Transaction Layer executes the cache coherent and data movement
> commands on the P10 chip.
> The PAU provides the Transaction Layer functionality for the OCAPI
> link(s) on the P10 chip.
> 
> The P10 PAU supports two OCAPI links. Six accelerator units PAUs are
> instantiated on the P10 chip for a total of twelve OCAPI links.
> 
> This patch adds PAU opencapi structure for supporting OpenCapi5.
> hw/pau.c file contains main of PAU management functions.
> 
> Signed-off-by: Christophe Lombard <clombard at linux.vnet.ibm.com>
> ---


> diff --git a/hdata/spira.c b/hdata/spira.c
> index baa23751..81806652 100644
> --- a/hdata/spira.c
> +++ b/hdata/spira.c
> @@ -966,21 +966,40 @@ static void add_nx(void)
>   static void add_nmmu(void)
>   {
>   	struct dt_node *xscom, *nmmu;
> -	u32 scom;
> +	u32 scom1, scom2;
> +	u32 chip_id;
> 
>   	/* Nest MMU only exists on POWER9 or later */
>   	if (proc_gen < proc_gen_p9)
>   		return;
> 
> -	if (proc_gen == proc_gen_p9)
> -		scom = 0x5012c40;
> -	else
> -		scom = 0x2010c40;
> +	if (proc_gen == proc_gen_p9) {
> +		scom1 = 0x5012c40;
> +	} else if (proc_gen == proc_gen_p10) {
> +		scom1 = 0x2010c40;
> +		scom2 = 0x3010c40;
> +	} else
> +		scom1 = 0x2010c40;
> 

Looks like there was a merge issue here. We should only have 2 cases




> @@ -1757,6 +1776,110 @@ static void add_npus(void)
>   	}
>   }
> 
> +static void add_pau(struct dt_node *xscom,
> +		    const struct HDIF_array_hdr *links)
> +{
> +	/* P10 contains 6 distinct accelerator units:  PAU0, PAU3,
> +	 * PAU4, PAU5, PAU6, PAU7
> +	 */
> +	const uint32_t pau_base[] = { 0x10010800, 0x11010800,
> +				      0x12010800, 0x12011000,
> +				      0x13010800, 0x13011000};
> +
> +	const struct sppcrd_smp_link *link;
> +	struct dt_node *pau, *node;
> +	uint32_t chip_id, link_id;
> +	uint16_t pau_index, pau_unit, brick_id, opt_unit, lane_mask;
> +	int i;
> +
> +	chip_id = dt_get_chip_id(xscom);
> +
> +	HDIF_iarray_for_each(links, i, link) {


It looks like HDAT is still not showing any links in recent builds.
HDAT parsing is done first. If HDAT adds definitions tomorrow, we're 
going to hit errors in pau_dt_create().
We should probably have a switch to choose either HDAT or static DT 
definitions. Or only create entries if they don't exist, but that risks 
mixing entries from the two sources. My vote is for the former.




> diff --git a/hw/pau.c b/hw/pau.c
> new file mode 100644

> +static void pau_dt_create_pau(struct dt_node *xscom, uint32_t pau_index)
> +{
> +	const uint32_t pau_base[] = { 0x10010800, 0x11010800,
> +				      0x12010800, 0x12011000,
> +				      0x13010800, 0x13011000};
> +	struct dt_node *pau;
> +	uint32_t links;
> +
> +	assert(pau_index < PAU_NBR);
> +	pau = dt_new_addr(xscom, "pau", pau_base[pau_index]);
> +
> +	dt_add_property_cells(pau, "#size-cells", 0);
> +	dt_add_property_cells(pau, "#address-cells", 1);
> +	dt_add_property_cells(pau, "reg", pau_base[pau_index], 0x2c);
> +	dt_add_property_string(pau, "compatible", "ibm,power10-pau");
> +	dt_add_property_cells(pau, "ibm,pau-index", pau_index);
> +	dt_add_property_cells(pau, "ibm,phb-index", 7 + pau_index);

I don't think "ibm,phb-index" is going to be used for PAU, it's just 
there to match other PHB types. But there's no reason to start numbering 
at 7. Maybe we can reuse pau_get_phb_index()
Same thing is seen in spira.c


   Fred