DPDK patches and discussions
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: Nicolas Chautru <nicolas.chautru@intel.com>,
	dev@dpdk.org, gakhil@marvell.com, trix@redhat.com
Cc: thomas@monjalon.net, ray.kinsella@intel.com,
	bruce.richardson@intel.com, hemant.agrawal@nxp.com,
	hernan.vargas@intel.com, david.marchand@redhat.com
Subject: Re: [PATCH v3 3/4] baseband/acc100: configuration of ACC101 from PF
Date: Thu, 19 May 2022 22:13:45 +0200	[thread overview]
Message-ID: <d51ba98a-e152-ead8-5162-029406cc1ff1@redhat.com> (raw)
In-Reply-To: <1652734113-124047-4-git-send-email-nicolas.chautru@intel.com>

Hi Nicolas,

On 5/16/22 22:48, Nicolas Chautru wrote:
 > Adding companion function specific to ACC100 and it
 > can be called from bbdev-test when running from PF.
 >
 > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
 > ---
 >   app/test-bbdev/test_bbdev_perf.c         |  22 ++-
 >   drivers/baseband/acc100/rte_acc100_cfg.h |  17 ++
 >   drivers/baseband/acc100/rte_acc100_pmd.c | 302 
+++++++++++++++++++++++++++++++
 >   drivers/baseband/acc100/version.map      |   2 +-
 >   4 files changed, 336 insertions(+), 7 deletions(-)
 >
 > diff --git a/app/test-bbdev/test_bbdev_perf.c 
b/app/test-bbdev/test_bbdev_perf.c
 > index 0fa119a..b10b93d 100644
 > --- a/app/test-bbdev/test_bbdev_perf.c
 > +++ b/app/test-bbdev/test_bbdev_perf.c
 > @@ -63,6 +63,8 @@
 >   #define ACC100_QMGR_INVALID_IDX -1
 >   #define ACC100_QMGR_RR 1
 >   #define ACC100_QOS_GBR 0
 > +#define ACC101PF_DRIVER_NAME   ("intel_acc101_pf")
 > +#define ACC101VF_DRIVER_NAME   ("intel_acc101_vf")
 >   #endif
 >
 >   #define OPS_CACHE_SIZE 256U
 > @@ -711,11 +713,12 @@ typedef int (test_case_function)(struct 
active_device *ad,
 >   #endif
 >   #ifdef RTE_BASEBAND_ACC100
 >   	if ((get_init_device() == true) &&
 > -		(!strcmp(info->drv.driver_name, ACC100PF_DRIVER_NAME))) {
 > +			((!strcmp(info->drv.driver_name, ACC100PF_DRIVER_NAME)) ||
 > +			(!strcmp(info->drv.driver_name, ACC101PF_DRIVER_NAME)))) {
 >   		struct rte_acc100_conf conf;
 >   		unsigned int i;
 >
 > -		printf("Configure ACC100 FEC Driver %s with default values\n",
 > +		printf("Configure ACC10X FEC Driver %s with default values\n",
 >   				info->drv.driver_name);
 >
 >   		/* clear default configuration before initialization */
 > @@ -760,10 +763,17 @@ typedef int (test_case_function)(struct 
active_device *ad,
 >   		conf.q_dl_5g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
 >
 >   		/* setup PF with configuration information */
 > -		ret = rte_acc100_configure(info->dev_name, &conf);
 > -		TEST_ASSERT_SUCCESS(ret,
 > -				"Failed to configure ACC100 PF for bbdev %s",
 > -				info->dev_name);
 > +		if (!strcmp(info->drv.driver_name, ACC100PF_DRIVER_NAME)) {
 > +			ret = rte_acc100_configure(info->dev_name, &conf);
 > +			TEST_ASSERT_SUCCESS(ret,
 > +					"Failed to configure ACC100 PF for bbdev %s",
 > +					info->dev_name);
 > +		} else {
 > +			ret = rte_acc101_configure(info->dev_name, &conf);
 > +			TEST_ASSERT_SUCCESS(ret,
 > +					"Failed to configure ACC101 PF for bbdev %s",
 > +					info->dev_name);
 > +		}
 >   	}
 >   #endif
 >   	/* Let's refresh this now this is configured */
 > diff --git a/drivers/baseband/acc100/rte_acc100_cfg.h 
b/drivers/baseband/acc100/rte_acc100_cfg.h
 > index d233e42..2e3c43f 100644
 > --- a/drivers/baseband/acc100/rte_acc100_cfg.h
 > +++ b/drivers/baseband/acc100/rte_acc100_cfg.h
 > @@ -106,6 +106,23 @@ struct rte_acc100_conf {
 >   int
 >   rte_acc100_configure(const char *dev_name, struct rte_acc100_conf 
*conf);
 >
 > +/**
 > + * Configure a ACC101 device
 > + *
 > + * @param dev_name
 > + *   The name of the device. This is the short form of PCI BDF, e.g. 
00:01.0.
 > + *   It can also be retrieved for a bbdev device from the dev_name 
field in the
 > + *   rte_bbdev_info structure returned by rte_bbdev_info_get().
 > + * @param conf
 > + *   Configuration to apply to ACC101 HW.
 > + *
 > + * @return
 > + *   Zero on success, negative value on failure.
 > + */
 > +__rte_experimental
 > +int
 > +rte_acc101_configure(const char *dev_name, struct rte_acc100_conf 
*conf);
 > +
 >   #ifdef __cplusplus
 >   }
 >   #endif
 > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c 
b/drivers/baseband/acc100/rte_acc100_pmd.c
 > index daf2ce0..b03cedc 100644
 > --- a/drivers/baseband/acc100/rte_acc100_pmd.c
 > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
 > @@ -4921,3 +4921,305 @@ static int acc100_pci_remove(struct 
rte_pci_device *pci_dev)
 >   	rte_bbdev_log_debug("PF Tip configuration complete for %s", dev_name);
 >   	return 0;
 >   }
 > +
 > +
 > +/* Initial configuration of a ACC101 device prior to running 
configure() */
 > +int
 > +rte_acc101_configure(const char *dev_name, struct rte_acc100_conf *conf)
 > +{
Please don't introduce new API for every new variant.
You should have a single API, and within it call specific configuration
function based on the device ID.

It will be easier for the application which calls it not to have to know
which variant it is for.

 > +	rte_bbdev_log(INFO, "rte_acc101_configure");
 > +	uint32_t value, address, status;
 > +	int qg_idx, template_idx, vf_idx, acc, i;
 > +	struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
 > +
 > +	/* Compile time checks */
 > +	RTE_BUILD_BUG_ON(sizeof(struct acc100_dma_req_desc) != 256);
 > +	RTE_BUILD_BUG_ON(sizeof(union acc100_dma_desc) != 256);
 > +	RTE_BUILD_BUG_ON(sizeof(struct acc100_fcw_td) != 24);
 > +	RTE_BUILD_BUG_ON(sizeof(struct acc100_fcw_te) != 32);
 > +
 > +	if (bbdev == NULL) {
 > +		rte_bbdev_log(ERR,
 > +		"Invalid dev_name (%s), or device is not yet initialised",
 > +		dev_name);
 > +		return -ENODEV;
 > +	}
 > +	struct acc100_device *d = bbdev->data->dev_private;
 > +
 > +	/* Store configuration */
 > +	rte_memcpy(&d->acc100_conf, conf, sizeof(d->acc100_conf));
 > +
 > +	/* PCIe Bridge configuration */
 > +	acc100_reg_write(d, HwPfPcieGpexBridgeControl, ACC101_CFG_PCI_BRIDGE);
 > +	for (i = 1; i < ACC101_GPEX_AXIMAP_NUM; i++)
 > +		acc100_reg_write(d, HwPfPcieGpexAxiAddrMappingWindowPexBaseHigh + 
i * 16, 0);
 > +
 > +	/* Prevent blocking AXI read on BRESP for AXI Write */
 > +	address = HwPfPcieGpexAxiPioControl;
 > +	value = ACC101_CFG_PCI_AXI;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* Explicitly releasing AXI as this may be stopped after PF FLR/BME */
 > +	usleep(2000);
This sleep looks weird, especially when ACC100 does not require it.
Isn't there a way to know it is ready to release the AXI? Or at least
document why it is necessary.

 > +	acc100_reg_write(d, HWPfDmaAxiControl, 1);
 > +
 > +	/* Set the default 5GDL DMA configuration */
 > +	acc100_reg_write(d, HWPfDmaInboundDrainDataSize, ACC101_DMA_INBOUND);
 > +
 > +	/* Enable granular dynamic clock gating */
 > +	address = HWPfHiClkGateHystReg;
 > +	value = ACC101_CLOCK_GATING_EN;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* Set default descriptor signature */
 > +	address = HWPfDmaDescriptorSignatuture;
 > +	value = 0;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* Enable the Error Detection in DMA */
 > +	value = ACC101_CFG_DMA_ERROR;
 > +	address = HWPfDmaErrorDetectionEn;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* AXI Cache configuration */
 > +	value = ACC101_CFG_AXI_CACHE;
 > +	address = HWPfDmaAxcacheReg;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* Default DMA Configuration (Qmgr Enabled) */
 > +	address = HWPfDmaConfig0Reg;
 > +	value = 0;
 > +	acc100_reg_write(d, address, value);
 > +	address = HWPfDmaQmanen;
 > +	value = 0;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* Default RLIM/ALEN configuration */
 > +	address = HWPfDmaConfig1Reg;
 > +	int alen_r = 0xF;
 > +	int alen_w = 0x7;
 > +	value = (1 << 31) + (alen_w << 20)  + (1 << 6) + alen_r;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* Configure DMA Qmanager addresses */
 > +	address = HWPfDmaQmgrAddrReg;
 > +	value = HWPfQmgrEgressQueuesTemplate;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* ===== Qmgr Configuration ===== */
 > +	/* Configuration of the AQueue Depth QMGR_GRP_0_DEPTH_LOG2 for UL */
 > +	int totalQgs = conf->q_ul_4g.num_qgroups +
 > +			conf->q_ul_5g.num_qgroups +
 > +			conf->q_dl_4g.num_qgroups +
 > +			conf->q_dl_5g.num_qgroups;
 > +	for (qg_idx = 0; qg_idx < totalQgs; qg_idx++) {
 > +		address = HWPfQmgrDepthLog2Grp +
 > +		ACC101_BYTES_IN_WORD * qg_idx;
 > +		value = aqDepth(qg_idx, conf);
 > +		acc100_reg_write(d, address, value);
 > +		address = HWPfQmgrTholdGrp +
 > +		ACC101_BYTES_IN_WORD * qg_idx;
 > +		value = (1 << 16) + (1 << (aqDepth(qg_idx, conf) - 1));
 > +		acc100_reg_write(d, address, value);
 > +	}
 > +
 > +	/* Template Priority in incremental order */
 > +	for (template_idx = 0; template_idx < ACC101_NUM_TMPL;
 > +			template_idx++) {
 > +		address = HWPfQmgrGrpTmplateReg0Indx + ACC101_BYTES_IN_WORD * 
template_idx;
 > +		value = ACC101_TMPL_PRI_0;
 > +		acc100_reg_write(d, address, value);
 > +		address = HWPfQmgrGrpTmplateReg1Indx + ACC101_BYTES_IN_WORD * 
template_idx;
 > +		value = ACC101_TMPL_PRI_1;
 > +		acc100_reg_write(d, address, value);
 > +		address = HWPfQmgrGrpTmplateReg2indx + ACC101_BYTES_IN_WORD * 
template_idx;
 > +		value = ACC101_TMPL_PRI_2;
 > +		acc100_reg_write(d, address, value);
 > +		address = HWPfQmgrGrpTmplateReg3Indx + ACC101_BYTES_IN_WORD * 
template_idx;
 > +		value = ACC101_TMPL_PRI_3;
 > +		acc100_reg_write(d, address, value);
For both ACC100 and ACC101, ACC10x_NUM_TMPL is 32.
Isn't there a bug here or in ACC100?

ACC100 performs a modulo 8 on template_idx, but ACC101 does not. But the
registers mapping is the same, so I guess this is the same HW block.

I think ACC100 is the buggy one, because it seems weird to write the
same register with the same value multiple times.

In case it is ACC100 that is buggy, it needs to be fixed in a dedicated
patch, with proper fixes tag so that it is backported.

 > +	}
 > +
 > +	address = HWPfQmgrGrpPriority;
 > +	value = ACC101_CFG_QMGR_HI_P;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* Template Configuration */
 > +	for (template_idx = 0; template_idx < ACC101_NUM_TMPL;
 > +			template_idx++) {
 > +		value = 0;
 > +		address = HWPfQmgrGrpTmplateReg4Indx
 > +				+ ACC101_BYTES_IN_WORD * template_idx;
 > +		acc100_reg_write(d, address, value);
 > +	}
 > +	/* 4GUL */
 > +	int numQgs = conf->q_ul_4g.num_qgroups;
 > +	int numQqsAcc = 0;
 > +	value = 0;
 > +	for (qg_idx = numQqsAcc; qg_idx < (numQgs + numQqsAcc); qg_idx++)
 > +		value |= (1 << qg_idx);
 > +	for (template_idx = ACC101_SIG_UL_4G;
 > +			template_idx <= ACC101_SIG_UL_4G_LAST;
 > +			template_idx++) {
 > +		address = HWPfQmgrGrpTmplateReg4Indx
 > +				+ ACC101_BYTES_IN_WORD * template_idx;
 > +		acc100_reg_write(d, address, value);
 > +	}
 > +	/* 5GUL */
 > +	numQqsAcc += numQgs;
 > +	numQgs	= conf->q_ul_5g.num_qgroups;
 > +	value = 0;
 > +	int numEngines = 0;
 > +	for (qg_idx = numQqsAcc; qg_idx < (numQgs + numQqsAcc); qg_idx++)
 > +		value |= (1 << qg_idx);
 > +	for (template_idx = ACC101_SIG_UL_5G;
 > +			template_idx <= ACC101_SIG_UL_5G_LAST;
 > +			template_idx++) {
 > +		/* Check engine power-on status */
 > +		address = HwPfFecUl5gIbDebugReg +
 > +				ACC101_ENGINE_OFFSET * template_idx;
 > +		status = (acc100_reg_read(d, address) >> 4) & 0xF;
 > +		address = HWPfQmgrGrpTmplateReg4Indx
 > +				+ ACC101_BYTES_IN_WORD * template_idx;
 > +		if (status == 1) {
 > +			acc100_reg_write(d, address, value);
 > +			numEngines++;
 > +		} else
 > +			acc100_reg_write(d, address, 0);
 > +#if RTE_ACC101_SINGLE_FEC == 1
 > +		value = 0;
 > +#endif
 > +	}
 > +	printf("Number of 5GUL engines %d\n", numEngines);
 > +	/* 4GDL */
 > +	numQqsAcc += numQgs;
 > +	numQgs	= conf->q_dl_4g.num_qgroups;
 > +	value = 0;
 > +	for (qg_idx = numQqsAcc; qg_idx < (numQgs + numQqsAcc); qg_idx++)
 > +		value |= (1 << qg_idx);
 > +	for (template_idx = ACC101_SIG_DL_4G;
 > +			template_idx <= ACC101_SIG_DL_4G_LAST;
 > +			template_idx++) {
 > +		address = HWPfQmgrGrpTmplateReg4Indx
 > +				+ ACC101_BYTES_IN_WORD * template_idx;
 > +		acc100_reg_write(d, address, value);
 > +#if RTE_ACC101_SINGLE_FEC == 1
 > +			value = 0;
 > +#endif
 > +	}
 > +	/* 5GDL */
 > +	numQqsAcc += numQgs;
 > +	numQgs	= conf->q_dl_5g.num_qgroups;
 > +	value = 0;
 > +	for (qg_idx = numQqsAcc; qg_idx < (numQgs + numQqsAcc); qg_idx++)
 > +		value |= (1 << qg_idx);
 > +	for (template_idx = ACC101_SIG_DL_5G;
 > +			template_idx <= ACC101_SIG_DL_5G_LAST;
 > +			template_idx++) {
 > +		address = HWPfQmgrGrpTmplateReg4Indx
 > +				+ ACC101_BYTES_IN_WORD * template_idx;
 > +		acc100_reg_write(d, address, value);
 > +#if RTE_ACC101_SINGLE_FEC == 1
 > +		value = 0;
 > +#endif
 > +	}
 > +
 > +	/* Queue Group Function mapping */
 > +	int qman_func_id[8] = {0, 2, 1, 3, 4, 0, 0, 0};
 > +	address = HWPfQmgrGrpFunction0;
 > +	value = 0;
 > +	for (qg_idx = 0; qg_idx < 8; qg_idx++) {
 > +		acc = accFromQgid(qg_idx, conf);
 > +		value |= qman_func_id[acc]<<(qg_idx * 4);
 > +	}
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* Configuration of the Arbitration QGroup depth to 1 */
 > +	for (qg_idx = 0; qg_idx < totalQgs; qg_idx++) {
 > +		address = HWPfQmgrArbQDepthGrp +
 > +		ACC101_BYTES_IN_WORD * qg_idx;
 > +		value = 0;
 > +		acc100_reg_write(d, address, value);
 > +	}
 > +
 > +	/* Enabling AQueues through the Queue hierarchy*/
 > +	for (vf_idx = 0; vf_idx < ACC101_NUM_VFS; vf_idx++) {
 > +		for (qg_idx = 0; qg_idx < ACC101_NUM_QGRPS; qg_idx++) {
 > +			value = 0;
 > +			if (vf_idx < conf->num_vf_bundles &&
 > +					qg_idx < totalQgs)
 > +				value = (1 << aqNum(qg_idx, conf)) - 1;
 > +			address = HWPfQmgrAqEnableVf
 > +					+ vf_idx * ACC101_BYTES_IN_WORD;
 > +			value += (qg_idx << 16);
 > +			acc100_reg_write(d, address, value);
 > +		}
 > +	}
 > +
 > +	/* This pointer to ARAM (128kB) is shifted by 2 (4B per register) */
 > +	uint32_t aram_address = 0;
 > +	for (qg_idx = 0; qg_idx < totalQgs; qg_idx++) {
 > +		for (vf_idx = 0; vf_idx < conf->num_vf_bundles; vf_idx++) {
 > +			address = HWPfQmgrVfBaseAddr + vf_idx
 > +					* ACC101_BYTES_IN_WORD + qg_idx
 > +					* ACC101_BYTES_IN_WORD * 64;
 > +			value = aram_address;
 > +			acc100_reg_write(d, address, value);
 > +			/* Offset ARAM Address for next memory bank
 > +			 * - increment of 4B
 > +			 */
 > +			aram_address += aqNum(qg_idx, conf) *
 > +					(1 << aqDepth(qg_idx, conf));
 > +		}
 > +	}
 > +
 > +	if (aram_address > ACC101_WORDS_IN_ARAM_SIZE) {
 > +		rte_bbdev_log(ERR, "ARAM Configuration not fitting %d %d\n",
 > +				aram_address, ACC101_WORDS_IN_ARAM_SIZE);
 > +		return -EINVAL;
 > +	}
 > +
 > +	/* ==== HI Configuration ==== */
 > +
 > +	/* No Info Ring/MSI by default */
 > +	acc100_reg_write(d, HWPfHiInfoRingIntWrEnRegPf, 0);
 > +	acc100_reg_write(d, HWPfHiInfoRingVf2pfLoWrEnReg, 0);
 > +	acc100_reg_write(d, HWPfHiCfgMsiIntWrEnRegPf, 0xFFFFFFFF);
 > +	acc100_reg_write(d, HWPfHiCfgMsiVf2pfLoWrEnReg, 0xFFFFFFFF);
 > +	/* Prevent Block on Transmit Error */
 > +	address = HWPfHiBlockTransmitOnErrorEn;
 > +	value = 0;
 > +	acc100_reg_write(d, address, value);
 > +	/* Prevents to drop MSI */
 > +	address = HWPfHiMsiDropEnableReg;
 > +	value = 0;
 > +	acc100_reg_write(d, address, value);
 > +	/* Set the PF Mode register */
 > +	address = HWPfHiPfMode;
 > +	value = (conf->pf_mode_en) ? ACC101_PF_VAL : 0;
 > +	acc100_reg_write(d, address, value);
 > +	/* Explicitly releasing AXI after PF Mode and 2 ms */
 > +	usleep(2000);
 > +	acc100_reg_write(d, HWPfDmaAxiControl, 1);
 > +
 > +	/* QoS overflow init */
 > +	value = 1;
 > +	address = HWPfQosmonAEvalOverflow0;
 > +	acc100_reg_write(d, address, value);
 > +	address = HWPfQosmonBEvalOverflow0;
 > +	acc100_reg_write(d, address, value);
 > +
 > +	/* HARQ DDR Configuration */
 > +	unsigned int ddrSizeInMb = ACC101_HARQ_DDR;
 > +	for (vf_idx = 0; vf_idx < conf->num_vf_bundles; vf_idx++) {
 > +		address = HWPfDmaVfDdrBaseRw + vf_idx
 > +				* 0x10;
 > +		value = ((vf_idx * (ddrSizeInMb / 64)) << 16) +
 > +				(ddrSizeInMb - 1);
 > +		acc100_reg_write(d, address, value);
 > +	}
 > +	usleep(ACC101_LONG_WAIT);
 > +
 > +	rte_bbdev_log_debug("PF TIP configuration complete for %s", dev_name);
 > +	return 0;
 > +}
 > diff --git a/drivers/baseband/acc100/version.map 
b/drivers/baseband/acc100/version.map
 > index 40604c7..37b850f 100644
 > --- a/drivers/baseband/acc100/version.map
 > +++ b/drivers/baseband/acc100/version.map
 > @@ -6,5 +6,5 @@ EXPERIMENTAL {
 >   	global:
 >
 >   	rte_acc100_configure;
 > -
 > +	rte_acc101_configure;
 >   };


  reply	other threads:[~2022-05-19 20:13 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27 18:16 [PATCH v2 0/5] drivers/baseband: PMD to support ACC101 device Nicolas Chautru
2022-04-27 18:16 ` [PATCH v2 1/5] baseband/acc100: introduce PMD for ACC101 Nicolas Chautru
2022-05-08 13:02   ` Tom Rix
2022-05-09 21:23     ` Chautru, Nicolas
2022-05-10  8:52       ` Thomas Monjalon
2022-05-10 11:55       ` Tom Rix
2022-05-23 17:53         ` Chautru, Nicolas
2022-04-27 18:17 ` [PATCH v2 2/5] baseband/acc100: modify validation code " Nicolas Chautru
2022-05-08 13:07   ` Tom Rix
2022-05-09 21:27     ` Chautru, Nicolas
2022-04-27 18:17 ` [PATCH v2 3/5] baseband/acc100: configuration of ACC101 from PF Nicolas Chautru
2022-05-08 13:38   ` Tom Rix
2022-05-09 21:36     ` Chautru, Nicolas
2022-05-10 12:02       ` Tom Rix
2022-04-27 18:17 ` [PATCH v2 4/5] baseband/acc100: start explicitly PF Monitor from PMD Nicolas Chautru
2022-05-08 13:44   ` Tom Rix
2022-05-09 22:07     ` Chautru, Nicolas
2022-04-27 18:17 ` [PATCH v2 5/5] baseband/acc100: add protection for some negative scenario Nicolas Chautru
2022-05-08 13:55   ` Tom Rix
2022-05-09 21:45     ` Chautru, Nicolas
2022-05-10 12:11       ` Tom Rix
2022-05-10 14:44         ` Thomas Monjalon
2022-05-16 20:48 ` [PATCH v3 0/4] drivers/baseband: PMD to support ACC101 device Nicolas Chautru
2022-05-16 20:48   ` [PATCH v3 1/4] baseband/acc100: introduce PMD for ACC101 Nicolas Chautru
2022-05-19 19:55     ` Maxime Coquelin
2022-05-16 20:48   ` [PATCH v3 2/4] baseband/acc100: modify validation code " Nicolas Chautru
2022-05-16 20:48   ` [PATCH v3 3/4] baseband/acc100: configuration of ACC101 from PF Nicolas Chautru
2022-05-19 20:13     ` Maxime Coquelin [this message]
2022-05-23 17:06       ` Chautru, Nicolas
2022-05-16 20:48   ` [PATCH v3 4/4] baseband/acc100: add protection for some negative scenario Nicolas Chautru
2022-05-19 19:51   ` [PATCH v3 0/4] drivers/baseband: PMD to support ACC101 device Tom Rix
2022-05-23 21:25 ` [PATCH v4 0/5] drivers/baseband: PMD to support ACC100/ACC101 devices Nicolas Chautru
2022-05-23 21:25   ` [PATCH v4 1/5] baseband/acc100: update companion PF configure function Nicolas Chautru
2022-05-23 21:25   ` [PATCH v4 2/5] baseband/acc100: add protection for some negative scenario Nicolas Chautru
2022-05-23 21:25   ` [PATCH v4 3/5] baseband/acc100: introduce PMD for ACC101 Nicolas Chautru
2022-05-23 21:25   ` [PATCH v4 4/5] baseband/acc100: modify validation code " Nicolas Chautru
2022-05-23 21:25   ` [PATCH v4 5/5] baseband/acc100: configuration of ACC101 from PF Nicolas Chautru
2022-05-24  0:08 ` [PATCH v5 0/5] drivers/baseband: PMD to support ACC100/ACC101 devices Nicolas Chautru
2022-05-24  0:08   ` [PATCH v5 1/5] baseband/acc100: update companion PF configure function Nicolas Chautru
2022-05-24  0:08   ` [PATCH v5 2/5] baseband/acc100: add protection for some negative scenario Nicolas Chautru
2022-05-24  0:08   ` [PATCH v5 3/5] baseband/acc100: introduce PMD for ACC101 Nicolas Chautru
2022-05-24  0:08   ` [PATCH v5 4/5] baseband/acc100: modify validation code " Nicolas Chautru
2022-05-25 14:33     ` Maxime Coquelin
2022-05-25 22:15       ` Chautru, Nicolas
2022-05-31  7:59         ` Maxime Coquelin
2022-05-31 18:19           ` Chautru, Nicolas
2022-05-24  0:08   ` [PATCH v5 5/5] baseband/acc100: configuration of ACC101 from PF Nicolas Chautru
2022-05-25 13:24     ` Maxime Coquelin
2022-05-25 22:09       ` Chautru, Nicolas
2022-05-26  0:49   ` [PATCH v6 0/5] drivers/baseband: PMD to support ACC100/ACC101 devices Nicolas Chautru
2022-05-26  0:55   ` Nicolas Chautru
2022-05-26  0:55     ` [PATCH v6 1/5] baseband/acc100: update companion PF configure function Nicolas Chautru
2022-05-26  0:55     ` [PATCH v6 2/5] baseband/acc100: add protection for some negative scenario Nicolas Chautru
2022-05-26  0:55     ` [PATCH v6 3/5] baseband/acc100: introduce PMD for ACC101 Nicolas Chautru
2022-05-30  7:40       ` [EXT] " Akhil Goyal
2022-05-31 18:59         ` Chautru, Nicolas
2022-05-26  0:55     ` [PATCH v6 4/5] baseband/acc100: modify validation code " Nicolas Chautru
2022-05-31  8:02       ` Maxime Coquelin
2022-05-31 18:16         ` Chautru, Nicolas
2022-05-26  0:55     ` [PATCH v6 5/5] baseband/acc100: configuration of ACC101 from PF Nicolas Chautru
2022-05-31  7:35       ` Maxime Coquelin
2022-05-31 18:28         ` Chautru, Nicolas
2022-05-31 22:31   ` [PATCH v7 0/6] drivers/baseband: PMD to support ACC100/ACC101 devices Nicolas Chautru
2022-05-31 22:31     ` [PATCH v7 1/6] baseband/acc100: update companion PF configure function Nicolas Chautru
2022-06-02  9:49       ` Kevin Traynor
2022-06-02 16:52         ` Chautru, Nicolas
2022-06-03 20:25       ` Vargas, Hernan
2022-05-31 22:31     ` [PATCH v7 2/6] baseband/acc100: add protection for some negative scenario Nicolas Chautru
2022-06-02  8:21       ` Maxime Coquelin
2022-05-31 22:31     ` [PATCH v7 3/6] baseband/acc100: remove RTE prefix for internal macro Nicolas Chautru
2022-06-01 14:11       ` Maxime Coquelin
2022-06-01 17:15         ` [EXT] " Akhil Goyal
2022-06-02 12:57           ` Maxime Coquelin
2022-05-31 22:31     ` [PATCH v7 4/6] baseband/acc100: introduce PMD for ACC101 Nicolas Chautru
2022-06-02 12:23       ` Maxime Coquelin
2022-05-31 22:31     ` [PATCH v7 5/6] baseband/acc100: modify validation code " Nicolas Chautru
2022-06-03 20:23       ` Vargas, Hernan
2022-05-31 22:31     ` [PATCH v7 6/6] baseband/acc100: configuration of ACC101 from PF Nicolas Chautru
2022-06-02  8:33       ` Maxime Coquelin
2022-06-06 14:54     ` [PATCH v7 0/6] drivers/baseband: PMD to support ACC100/ACC101 devices Chautru, Nicolas
2022-06-06 15:03       ` Akhil Goyal
2022-06-06 16:18         ` Chautru, Nicolas
2022-06-15 14:08     ` [EXT] " Akhil Goyal
2022-06-22 11:50       ` Akhil Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d51ba98a-e152-ead8-5162-029406cc1ff1@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=gakhil@marvell.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=hernan.vargas@intel.com \
    --cc=nicolas.chautru@intel.com \
    --cc=ray.kinsella@intel.com \
    --cc=thomas@monjalon.net \
    --cc=trix@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).