All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oded Gabbay <ogabbay@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Ohad Sharabi <osharabi@habana.ai>
Subject: [PATCH 4/7] habanalabs: prepare preboot stage to dynamic f/w load
Date: Sat, 17 Apr 2021 12:06:35 +0300	[thread overview]
Message-ID: <20210417090638.9802-4-ogabbay@kernel.org> (raw)
In-Reply-To: <20210417090638.9802-1-ogabbay@kernel.org>

From: Ohad Sharabi <osharabi@habana.ai>

Start the skeleton for the dynamic F/W load by marking current preboot
code path as legacy.

Signed-off-by: Ohad Sharabi <osharabi@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
---
 drivers/misc/habanalabs/common/firmware_if.c | 79 ++++++++++++++++----
 drivers/misc/habanalabs/common/habanalabs.h  |  8 +-
 2 files changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/misc/habanalabs/common/firmware_if.c b/drivers/misc/habanalabs/common/firmware_if.c
index 7cf82da67dab..337c76fb5e3c 100644
--- a/drivers/misc/habanalabs/common/firmware_if.c
+++ b/drivers/misc/habanalabs/common/firmware_if.c
@@ -811,21 +811,15 @@ static void detect_cpu_boot_status(struct hl_device *hdev, u32 status)
 	}
 }
 
-int hl_fw_read_preboot_status(struct hl_device *hdev, u32 cpu_boot_status_reg,
-		u32 cpu_security_boot_status_reg, u32 boot_err0_reg,
-		u32 timeout)
+static int hl_fw_read_preboot_caps(struct hl_device *hdev,
+					u32 cpu_boot_status_reg,
+					u32 cpu_boot_caps_reg,
+					u32 boot_err0_reg, u32 timeout)
 {
 	struct asic_fixed_properties *prop = &hdev->asic_prop;
-	u32 status, security_status;
+	u32 status;
 	int rc;
 
-	/* pldm was added for cases in which we use preboot on pldm and want
-	 * to load boot fit, but we can't wait for preboot because it runs
-	 * very slowly
-	 */
-	if (!(hdev->fw_components & FW_TYPE_PREBOOT_CPU) || hdev->pldm)
-		return 0;
-
 	/* Need to check two possible scenarios:
 	 *
 	 * CPU_BOOT_STATUS_WAITING_FOR_BOOT_FIT - for newer firmwares where
@@ -848,18 +842,41 @@ int hl_fw_read_preboot_status(struct hl_device *hdev, u32 cpu_boot_status_reg,
 		timeout);
 
 	if (rc) {
-		dev_err(hdev->dev, "Failed to read preboot version\n");
+		dev_err(hdev->dev, "CPU boot ready status timeout\n");
 		detect_cpu_boot_status(hdev, status);
-		fw_read_errors(hdev, boot_err0_reg,
-				cpu_security_boot_status_reg);
+		fw_read_errors(hdev, boot_err0_reg, cpu_boot_status_reg);
 		return -EIO;
 	}
 
+	prop->fw_preboot_caps_map = RREG32(cpu_boot_caps_reg);
+
+	/*
+	 * For now- force dynamic_fw_load to false as LKD does not yet
+	 * implements all necessary parts of it.
+	 * TODO: once dynamic load is ready set to:
+	 * prop->dynamic_fw_load = !!(prop->fw_preboot_caps_map &
+	 *                                CPU_BOOT_DEV_STS0_FW_LD_COM_EN)
+	 */
+	prop->dynamic_fw_load = 0;
+
+	dev_dbg(hdev->dev, "Attempting %s FW load\n",
+			prop->dynamic_fw_load ? "dynamic" : "legacy");
+	return 0;
+}
+
+static int hl_fw_read_preboot_status_legacy(struct hl_device *hdev,
+		u32 cpu_boot_status_reg, u32 cpu_security_boot_status_reg,
+		u32 boot_err0_reg, u32 timeout)
+{
+	struct asic_fixed_properties *prop = &hdev->asic_prop;
+	u32 security_status;
+	int rc;
+
 	rc = hdev->asic_funcs->read_device_fw_version(hdev, FW_COMP_PREBOOT);
 	if (rc)
 		return rc;
 
-	security_status = RREG32(cpu_security_boot_status_reg);
+	security_status = prop->fw_preboot_caps_map;
 
 	/* We read security status multiple times during boot:
 	 * 1. preboot - a. Check whether the security status bits are valid
@@ -901,6 +918,38 @@ int hl_fw_read_preboot_status(struct hl_device *hdev, u32 cpu_boot_status_reg,
 	return 0;
 }
 
+int hl_fw_read_preboot_status(struct hl_device *hdev, u32 cpu_boot_status_reg,
+		u32 cpu_boot_caps_reg, u32 boot_err0_reg,
+		u32 timeout)
+{
+	int rc;
+
+	/* pldm was added for cases in which we use preboot on pldm and want
+	 * to load boot fit, but we can't wait for preboot because it runs
+	 * very slowly
+	 */
+	if (!(hdev->fw_components & FW_TYPE_PREBOOT_CPU) || hdev->pldm)
+		return 0;
+
+	/*
+	 * In order to determine boot method (static VS dymanic) we need to
+	 * read the boot caps register
+	 */
+	rc = hl_fw_read_preboot_caps(hdev, cpu_boot_status_reg,
+				cpu_boot_caps_reg, boot_err0_reg,
+				timeout);
+	if (rc)
+		return rc;
+
+	if (!hdev->asic_prop.dynamic_fw_load)
+		return hl_fw_read_preboot_status_legacy(hdev, cpu_boot_status_reg,
+				cpu_boot_caps_reg, boot_err0_reg,
+				timeout);
+
+	dev_err(hdev->dev, "Dynamic FW load is not supported\n");
+	return -EINVAL;
+}
+
 int hl_fw_init_cpu(struct hl_device *hdev, u32 cpu_boot_status_reg,
 			u32 msg_to_cpu_reg, u32 cpu_msg_status_reg,
 			u32 cpu_security_boot_status_reg, u32 boot_err0_reg,
diff --git a/drivers/misc/habanalabs/common/habanalabs.h b/drivers/misc/habanalabs/common/habanalabs.h
index 91291a8e201e..6441a270e10a 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -420,6 +420,9 @@ struct hl_mmu_properties {
  * @cb_pool_cb_size: size of each CB in the CB pool.
  * @max_pending_cs: maximum of concurrent pending command submissions
  * @max_queues: maximum amount of queues in the system
+ * @fw_preboot_caps_map: bitmap representation of preboot cpu capabilities
+ *                              reported by FW, bit description can be found in
+ *                              CPU_BOOT_DEV_STS*
  * @fw_boot_cpu_security_map: bitmap representation of boot cpu security status
  *                            reported by FW, bit description can be found in
  *                            CPU_BOOT_DEV_STS*
@@ -446,6 +449,7 @@ struct hl_mmu_properties {
  * @hard_reset_done_by_fw: true if firmware is handling hard reset flow
  * @num_functional_hbms: number of functional HBMs in each DCORE.
  * @iatu_done_by_fw: true if iATU configuration is being done by FW.
+ * @dynamic_fw_load: is dynamic FW load is supported.
  */
 struct asic_fixed_properties {
 	struct hw_queue_properties	*hw_queues_props;
@@ -491,6 +495,7 @@ struct asic_fixed_properties {
 	u32				cb_pool_cb_size;
 	u32				max_pending_cs;
 	u32				max_queues;
+	u32				fw_preboot_caps_map;
 	u32				fw_boot_cpu_security_map;
 	u32				fw_app_security_map;
 	u16				collective_first_sob;
@@ -510,6 +515,7 @@ struct asic_fixed_properties {
 	u8				hard_reset_done_by_fw;
 	u8				num_functional_hbms;
 	u8				iatu_done_by_fw;
+	u8				dynamic_fw_load;
 };
 
 /**
@@ -2397,7 +2403,7 @@ int hl_fw_init_cpu(struct hl_device *hdev, u32 cpu_boot_status_reg,
 			u32 cpu_security_boot_status_reg, u32 boot_err0_reg,
 			bool skip_bmc, u32 cpu_timeout, u32 boot_fit_timeout);
 int hl_fw_read_preboot_status(struct hl_device *hdev, u32 cpu_boot_status_reg,
-		u32 cpu_security_boot_status_reg, u32 boot_err0_reg,
+		u32 cpu_boot_caps_reg, u32 boot_err0_reg,
 		u32 timeout);
 
 int hl_pci_bars_map(struct hl_device *hdev, const char * const name[3],
-- 
2.25.1


  parent reply	other threads:[~2021-04-17  9:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-17  9:06 [PATCH 1/7] habanalabs: expose ASIC specific PLL index Oded Gabbay
2021-04-17  9:06 ` [PATCH 2/7] habanalabs: increase ELBI reset timeout for PLDM Oded Gabbay
2021-04-17  9:06 ` [PATCH 3/7] habanalabs: update firmware files to latest Oded Gabbay
2021-04-17  9:06 ` Oded Gabbay [this message]
2021-04-17  9:06 ` [PATCH 5/7] habanalabs: request f/w in separate function Oded Gabbay
2021-04-17  9:06 ` [PATCH 6/7] habanalabs: refactor init device cpu code Oded Gabbay
2021-04-17  9:06 ` [PATCH 7/7] habanalabs: use mmu cache range invalidation Oded Gabbay

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=20210417090638.9802-4-ogabbay@kernel.org \
    --to=ogabbay@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=osharabi@habana.ai \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.