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
next prev 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 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).