soc/intel/cmn/cse: Handle EOP completion asynchronously

coreboot supports three instances of sending EOP:
1. At CSE `.final' device operation
2. Early as with Alder Lake in chip_operations.init if
   `SOC_INTEL_CSE_SEND_EOP_EARLY' is selected
3. At BS_PAYLOAD_BOOT as designed for Meteor Lake if
   `SOC_INTEL_CSE_SEND_EOP_LATE' is selected

Currently, Alder Lake uses #3 as it results in better and more stable
boot time. However, what would deliver even better result is to not
actively wait for CSE completion.

This patch introduces a new `SOC_INTEL_CSE_SEND_EOP_ASYNC' Kconfig
which split the action of sending EOP request and receiving EOP
completion response from the CSE.

This patch used in conjunction with #1 can significantly
improves the overall boot time on a Raptor Lake design. For example
`SOC_INTEL_CSE_SEND_EOP_ASYNC' on a skolas board can deliver up to 36
ms boot time improvement as illustrated below.

   |    #     | Late EOP | Async EOP |
   |----------+----------+-----------|
   |    1     | 1020.052 |   971.272 |
   |    2     | 1015.911 |   971.821 |
   |    3     | 1038.415 |  1021.841 |
   |    4     | 1020.657 |   993.751 |
   |    5     | 1065.128 |  1020.951 |
   |    6     | 1037.859 |  1023.326 |
   |    7     | 1042.010 |   984.412 |
   |----------+----------+-----------|
   | Mean     |  1034.29 |    998.20 |
   | Variance |   4.76 % |    5.21 % |

The improvement is not stable but comparing coreboot and FSP
performance timestamps demonstrate that the slowness is caused by a
lower memory frequency (SaGv point) at early boot which is not an
issue addressed by this patch.

We also observe some improvement on an Alder Lake design. For example,
the same configuration on a kano board can deliver up to 10 ms boot time
improvement as illustrated below.

   |        # | Late EOP | Async EOP |
   |----------+----------+-----------|
   |        0 | 1067.719 |  1050.106 |
   |        1 | 1058.263 |  1056.836 |
   |        2 | 1064.091 |  1056.709 |
   |        3 | 1068.614 |  1055.042 |
   |        4 | 1065.749 |  1056.732 |
   |        5 | 1069.838 |  1057.846 |
   |        6 | 1066.897 |  1053.548 |
   |        7 | 1060.850 |  1051.911 |
   |----------+----------+-----------|
   |     Mean |  1065.25 |   1054.84 |

The improvement is more limited on kano because a longer PCIe
initialization delays EOP in the Late EOP configuration which make it
faster to complete.

CSME team confirms that:
1. End-Of-Post is a blocking command in the sense that BIOS is
   requested to wait for the command completion before loading the OS or
   second stage bootloader.
2. The BIOS is not required to actively wait for completion of the
   command and can perform other operations in the meantime as long as
   they do not involve HECI commands.

On Raptor Lake, coreboot does not send any HECI command after
End-Of-Post.  FSP-s code review did not reveal any HECI command being
sent as part of the `AFTER_PCI_ENUM', `READY_TO_BOOT' or
`END_OF_FIRMWARE' notifications.

If any HECI send and receive command has been sent the extra code
added in `cse_receive_eop()' should catch it.

According to commit 387ec919d9f7 ("soc/intel/alderlake: Select
SOC_INTEL_CSE_SEND_EOP_LATE"), FSP-silicon can sometimes (on the first
boot after flashing of a Marasov board for instance) request coreboot
to perform a global request out of AFTER_PCI_ENUM notification. Global
request relies on a HECI command. Even though, we tested that it does
not create any issue, `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag should not
be associated to the `SOC_INTEL_CSE_SEND_EOP_EARLY' flag to prevent
potential a global reset command to "conflict" with the EOP command.

This patch also introduces a new code logic to detect if CSE is in the
right state to handle the EOP command. Otherwise, it uses the
prescribed method to make the CSE function disable. The typical
scenario is the ChromeOS recovery boot where CSE stays in RO partition
and therefore EOP command should be avoided.

    [DEBUG]  BS: BS_PAYLOAD_LOAD exit times (exec / console): 0 / 14 ms
    [INFO ]  HECI: coreboot in recovery mode; found CSE in expected
             SOFT TEMP DISABLE state, skipping EOP
    [INFO ]  Disabling Heci using PMC IPC
    [WARN ]  HECI: CSE device 16.0 is hidden
    [WARN ]  HECI: CSE device 16.1 is disabled
    [WARN ]  HECI: CSE device 16.2 is disabled
    [WARN ]  HECI: CSE device 16.3 is disabled
    [WARN ]  HECI: CSE device 16.4 is disabled
    [WARN ]  HECI: CSE device 16.5 is disabled

BUG=b:276339544
BRANCH=firmware-brya-14505.B
TEST=Tests on brya0 with and `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
     End-Of-Post sent soon after FSP-s and EOP message receive at
     `BS_PAYLOAD_BOOT'.  Verify robustness by injecting a
     `GET_BOOT_STATE' HECI command with or without `heci_reset'. The
     implementation always successfully completed the EOP before
     moving to the payload. As expected, the boot time benefit of the
     asynchronous solution was under some injection scenario
     undermined by this unexpected HECI command.

Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I01a56bfe3f6c37ffb5e51a527d9fe74785441c5a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>

1 files changed, 10 insertions, 1 deletions

diff --git a/src/soc/intel/common/block/cse/cse.c b/src/soc/intel/common/block/cse/cse.c
index 9902094180..6c4bb73cee 100644
--- a/src/soc/intel/common/block/cse/cse.c
+++ b/src/soc/intel/common/block/cse/cse.c
@@ -1407,7 +1407,8 @@ static void cse_final_end_of_firmware(void)
  */
 void cse_late_finalize(void)
 {
-	if (!CONFIG(SOC_INTEL_CSE_SEND_EOP_LATE))
+	if (!CONFIG(SOC_INTEL_CSE_SEND_EOP_LATE) &&
+	    !CONFIG(SOC_INTEL_CSE_SEND_EOP_ASYNC))
 		return;
 
 	if (!CONFIG(USE_FSP_NOTIFY_PHASE_READY_TO_BOOT))
@@ -1431,6 +1432,14 @@ static void cse_final(struct device *dev)
 	if (CONFIG(SOC_INTEL_CSE_SET_EOP))
 		cse_send_end_of_post();
 
+	/*
+	 * In asynchronous mode, the EOP command has most likely not been
+	 * completed yet. Finalization steps will be run once the EOP command
+	 * has successfully been completed.
+	 */
+	if (CONFIG(SOC_INTEL_CSE_SEND_EOP_ASYNC))
+		return;
+
 	if (!CONFIG(USE_FSP_NOTIFY_PHASE_READY_TO_BOOT))
 		cse_final_ready_to_boot();