From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mody, Rasesh" Subject: [PATCH 04/18] net/qede/base: workaround to indicate SHMEM data ready Date: Sat, 29 Sep 2018 08:14:29 +0000 Message-ID: <1538208822-9726-5-git-send-email-rasesh.mody@cavium.com> References: <1538208822-9726-1-git-send-email-rasesh.mody@cavium.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "Mody, Rasesh" , "ferruh.yigit@intel.com" , Dept-Eng DPDK Dev To: "dev@dpdk.org" Return-path: Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690074.outbound.protection.outlook.com [40.107.69.74]) by dpdk.org (Postfix) with ESMTP id 71FB67EC7 for ; Sat, 29 Sep 2018 10:14:36 +0200 (CEST) In-Reply-To: <1538208822-9726-1-git-send-email-rasesh.mody@cavium.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" The driver can notify that there was an MCP reset and read the SHMEM values before the management FW has completed initializing them. As a temporary solution, the "sup_msgs" field is used as a SHMEM data ready indication. This should be replaced with an actual indication when it is provided by the management FW. Signed-off-by: Rasesh Mody --- drivers/net/qede/base/ecore_mcp.c | 43 ++++++++++++++++++++++++++++++---= ---- 1 file changed, 35 insertions(+), 8 deletions(-) diff --git a/drivers/net/qede/base/ecore_mcp.c b/drivers/net/qede/base/ecor= e_mcp.c index 364c146..3811d27 100644 --- a/drivers/net/qede/base/ecore_mcp.c +++ b/drivers/net/qede/base/ecore_mcp.c @@ -177,10 +177,16 @@ enum _ecore_status_t ecore_mcp_free(struct ecore_hwfn= *p_hwfn) return ECORE_SUCCESS; } =20 +/* Maximum of 1 sec to wait for the SHMEM ready indication */ +#define ECORE_MCP_SHMEM_RDY_MAX_RETRIES 20 +#define ECORE_MCP_SHMEM_RDY_ITER_MS 50 + static enum _ecore_status_t ecore_load_mcp_offsets(struct ecore_hwfn *p_hw= fn, struct ecore_ptt *p_ptt) { struct ecore_mcp_info *p_info =3D p_hwfn->mcp_info; + u8 cnt =3D ECORE_MCP_SHMEM_RDY_MAX_RETRIES; + u8 msec =3D ECORE_MCP_SHMEM_RDY_ITER_MS; u32 drv_mb_offsize, mfw_mb_offsize; u32 mcp_pf_id =3D MCP_PF_ID(p_hwfn); =20 @@ -198,6 +204,35 @@ static enum _ecore_status_t ecore_load_mcp_offsets(str= uct ecore_hwfn *p_hwfn, =20 p_info->public_base |=3D GRCBASE_MCP; =20 + /* Get the MFW MB address and number of supported messages */ + mfw_mb_offsize =3D ecore_rd(p_hwfn, p_ptt, + SECTION_OFFSIZE_ADDR(p_info->public_base, + PUBLIC_MFW_MB)); + p_info->mfw_mb_addr =3D SECTION_ADDR(mfw_mb_offsize, mcp_pf_id); + p_info->mfw_mb_length =3D (u16)ecore_rd(p_hwfn, p_ptt, + p_info->mfw_mb_addr); + + /* @@@TBD: + * The driver can notify that there was an MCP reset, and read the SHMEM + * values before the MFW has completed initializing them. + * As a temporary solution, the "sup_msgs" field is used as a data ready + * indication. + * This should be replaced with an actual indication when it is provided + * by the MFW. + */ + while (!p_info->mfw_mb_length && cnt--) { + OSAL_MSLEEP(msec); + p_info->mfw_mb_length =3D (u16)ecore_rd(p_hwfn, p_ptt, + p_info->mfw_mb_addr); + } + + if (!cnt) { + DP_NOTICE(p_hwfn, false, + "Failed to get the SHMEM ready notification after %d msec\n", + ECORE_MCP_SHMEM_RDY_MAX_RETRIES * msec); + return ECORE_TIMEOUT; + } + /* Calculate the driver and MFW mailbox address */ drv_mb_offsize =3D ecore_rd(p_hwfn, p_ptt, SECTION_OFFSIZE_ADDR(p_info->public_base, @@ -208,14 +243,6 @@ static enum _ecore_status_t ecore_load_mcp_offsets(str= uct ecore_hwfn *p_hwfn, " mcp_pf_id =3D 0x%x\n", drv_mb_offsize, p_info->drv_mb_addr, mcp_pf_id); =20 - /* Set the MFW MB address */ - mfw_mb_offsize =3D ecore_rd(p_hwfn, p_ptt, - SECTION_OFFSIZE_ADDR(p_info->public_base, - PUBLIC_MFW_MB)); - p_info->mfw_mb_addr =3D SECTION_ADDR(mfw_mb_offsize, mcp_pf_id); - p_info->mfw_mb_length =3D (u16)ecore_rd(p_hwfn, p_ptt, - p_info->mfw_mb_addr); - /* Get the current driver mailbox sequence before sending * the first command */ --=20 1.7.10.3