linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gwendal Grignou <gwendal@chromium.org>
To: enric.balletbo@collabora.com, bleung@chromium.org,
	groeck@chromium.org, lee.jones@linaro.org, jic23@kernel.org,
	broonie@kernel.org, cychiang@chromium.org, tiwai@suse.com
Cc: linux-iio@vger.kernel.org, alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org,
	Gwendal Grignou <gwendal@chromium.org>
Subject: [PATCH v3 10/30] mfd: cros_ec: Add Flash V2 commands API
Date: Thu,  9 May 2019 14:13:33 -0700	[thread overview]
Message-ID: <20190509211353.213194-11-gwendal@chromium.org> (raw)
In-Reply-To: <20190509211353.213194-1-gwendal@chromium.org>

Added for supporting larger embedded controller flash.

Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
---
 include/linux/mfd/cros_ec_commands.h | 150 ++++++++++++++++++++++++++-
 1 file changed, 147 insertions(+), 3 deletions(-)

diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
index fabf341af97f..3d1d26f62bd3 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -1138,6 +1138,7 @@ struct ec_response_get_features {
 
 /* Get flash info */
 #define EC_CMD_FLASH_INFO 0x0010
+#define EC_VER_FLASH_INFO 2
 
 /**
  * struct ec_response_flash_info - Response to the flash info command.
@@ -1164,6 +1165,15 @@ struct ec_response_flash_info {
  */
 #define EC_FLASH_INFO_ERASE_TO_0 BIT(0)
 
+/*
+ * Flash must be selected for read/write/erase operations to succeed.  This may
+ * be necessary on a chip where write/erase can be corrupted by other board
+ * activity, or where the chip needs to enable some sort of programming voltage,
+ * or where the read/write/erase operations require cleanly suspending other
+ * chip functionality.
+ */
+#define EC_FLASH_INFO_SELECT_REQUIRED BIT(1)
+
 /**
  * struct ec_response_flash_info_1 - Response to the flash info v1 command.
  * @flash_size: Usable flash size in bytes.
@@ -1186,6 +1196,12 @@ struct ec_response_flash_info {
  * gcc anonymous structs don't seem to get along with the __packed directive;
  * if they did we'd define the version 0 structure as a sub-structure of this
  * one.
+ *
+ * Version 2 supports flash banks of different sizes:
+ * The caller specified the number of banks it has preallocated
+ * (num_banks_desc)
+ * The EC returns the number of banks describing the flash memory.
+ * It adds banks descriptions up to num_banks_desc.
  */
 struct ec_response_flash_info_1 {
 	/* Version 0 fields; see above for description */
@@ -1199,6 +1215,42 @@ struct ec_response_flash_info_1 {
 	uint32_t flags;
 } __ec_align4;
 
+struct ec_params_flash_info_2 {
+	/* Number of banks to describe */
+	uint16_t num_banks_desc;
+	/* Reserved; set 0; ignore on read */
+	uint8_t reserved[2];
+} __ec_align4;
+
+struct ec_flash_bank {
+	/* Number of sector is in this bank. */
+	uint16_t count;
+	/* Size in power of 2 of each sector (8 --> 256 bytes) */
+	uint8_t size_exp;
+	/* Minimal write size for the sectors in this bank */
+	uint8_t write_size_exp;
+	/* Erase size for the sectors in this bank */
+	uint8_t erase_size_exp;
+	/* Size for write protection, usually identical to erase size. */
+	uint8_t protect_size_exp;
+	/* Reserved; set 0; ignore on read */
+	uint8_t reserved[2];
+};
+
+struct ec_response_flash_info_2 {
+	/* Total flash in the EC. */
+	uint32_t flash_size;
+	/* Flags; see EC_FLASH_INFO_* */
+	uint32_t flags;
+	/* Maximum size to use to send data to write to the EC. */
+	uint32_t write_ideal_size;
+	/* Number of banks present in the EC. */
+	uint16_t num_banks_total;
+	/* Number of banks described in banks array. */
+	uint16_t num_banks_desc;
+	struct ec_flash_bank banks[0];
+} __ec_align4;
+
 /*
  * Read flash
  *
@@ -1238,7 +1290,7 @@ struct ec_params_flash_write {
 #define EC_CMD_FLASH_ERASE 0x0013
 
 /**
- * struct ec_params_flash_erase - Parameters for the flash erase command.
+ * struct ec_params_flash_erase - Parameters for the flash erase command, v0.
  * @offset: Byte offset to erase.
  * @size: Size to erase in bytes.
  */
@@ -1247,6 +1299,43 @@ struct ec_params_flash_erase {
 	uint32_t size;
 } __ec_align4;
 
+/*
+ * v1 add async erase:
+ * subcommands can returns:
+ * EC_RES_SUCCESS : erased (see ERASE_SECTOR_ASYNC case below).
+ * EC_RES_INVALID_PARAM : offset/size are not aligned on a erase boundary.
+ * EC_RES_ERROR : other errors.
+ * EC_RES_BUSY : an existing erase operation is in progress.
+ * EC_RES_ACCESS_DENIED: Trying to erase running image.
+ *
+ * When ERASE_SECTOR_ASYNC returns EC_RES_SUCCESS, the operation is just
+ * properly queued. The user must call ERASE_GET_RESULT subcommand to get
+ * the proper result.
+ * When ERASE_GET_RESULT returns EC_RES_BUSY, the caller must wait and send
+ * ERASE_GET_RESULT again to get the result of ERASE_SECTOR_ASYNC.
+ * ERASE_GET_RESULT command may timeout on EC where flash access is not
+ * permitted while erasing. (For instance, STM32F4).
+ */
+enum ec_flash_erase_cmd {
+	FLASH_ERASE_SECTOR,     /* Erase and wait for result */
+	FLASH_ERASE_SECTOR_ASYNC,  /* Erase and return immediately. */
+	FLASH_ERASE_GET_RESULT,  /* Ask for last erase result */
+};
+
+/**
+ * struct ec_params_flash_erase_v1 - Parameters for the flash erase command, v1.
+ * @cmd: One of ec_flash_erase_cmd.
+ * @reserved: Pad byte; currently always contains 0.
+ * @flag: No flags defined yet; set to 0.
+ * @params: Same as v0 parameters.
+ */
+struct ec_params_flash_erase_v1 {
+	uint8_t  cmd;
+	uint8_t  reserved;
+	uint16_t flag;
+	struct ec_params_flash_erase params;
+} __ec_align4;
+
 /*
  * Get/set flash protection.
  *
@@ -1282,6 +1371,15 @@ struct ec_params_flash_erase {
 #define EC_FLASH_PROTECT_ERROR_INCONSISTENT BIT(5)
 /* Entire flash code protected when the EC boots */
 #define EC_FLASH_PROTECT_ALL_AT_BOOT        BIT(6)
+/* RW flash code protected when the EC boots */
+#define EC_FLASH_PROTECT_RW_AT_BOOT         BIT(7)
+/* RW flash code protected now. */
+#define EC_FLASH_PROTECT_RW_NOW             BIT(8)
+/* Rollback information flash region protected when the EC boots */
+#define EC_FLASH_PROTECT_ROLLBACK_AT_BOOT   BIT(9)
+/* Rollback information flash region protected now */
+#define EC_FLASH_PROTECT_ROLLBACK_NOW       BIT(10)
+
 
 /**
  * struct ec_params_flash_protect - Parameters for the flash protect command.
@@ -1320,16 +1418,31 @@ struct ec_response_flash_protect {
 enum ec_flash_region {
 	/* Region which holds read-only EC image */
 	EC_FLASH_REGION_RO = 0,
-	/* Region which holds rewritable EC image */
-	EC_FLASH_REGION_RW,
+	/*
+	 * Region which holds active RW image. 'Active' is different from
+	 * 'running'. Active means 'scheduled-to-run'. Since RO image always
+	 * scheduled to run, active/non-active applies only to RW images (for
+	 * the same reason 'update' applies only to RW images. It's a state of
+	 * an image on a flash. Running image can be RO, RW_A, RW_B but active
+	 * image can only be RW_A or RW_B. In recovery mode, an active RW image
+	 * doesn't enter 'running' state but it's still active on a flash.
+	 */
+	EC_FLASH_REGION_ACTIVE,
 	/*
 	 * Region which should be write-protected in the factory (a superset of
 	 * EC_FLASH_REGION_RO)
 	 */
 	EC_FLASH_REGION_WP_RO,
+	/* Region which holds updatable (non-active) RW image */
+	EC_FLASH_REGION_UPDATE,
 	/* Number of regions */
 	EC_FLASH_REGION_COUNT,
 };
+/*
+ * 'RW' is vague if there are multiple RW images; we mean the active one,
+ * so the old constant is deprecated.
+ */
+#define EC_FLASH_REGION_RW EC_FLASH_REGION_ACTIVE
 
 /**
  * struct ec_params_flash_region_info - Parameters for the flash region info
@@ -1364,6 +1477,37 @@ struct ec_response_vbnvcontext {
 	uint8_t block[EC_VBNV_BLOCK_SIZE];
 } __ec_align4;
 
+
+/* Get SPI flash information */
+#define EC_CMD_FLASH_SPI_INFO 0x0018
+
+struct ec_response_flash_spi_info {
+	/* JEDEC info from command 0x9F (manufacturer, memory type, size) */
+	uint8_t jedec[3];
+
+	/* Pad byte; currently always contains 0 */
+	uint8_t reserved0;
+
+	/* Manufacturer / device ID from command 0x90 */
+	uint8_t mfr_dev_id[2];
+
+	/* Status registers from command 0x05 and 0x35 */
+	uint8_t sr1, sr2;
+} __ec_align1;
+
+
+/* Select flash during flash operations */
+#define EC_CMD_FLASH_SELECT 0x0019
+
+/**
+ * struct ec_params_flash_select - Parameters for the flash select command.
+ * @select: 1 to select flash, 0 to deselect flash
+ */
+struct ec_params_flash_select {
+	uint8_t select;
+} __ec_align4;
+
+
 /*****************************************************************************/
 /* PWM commands */
 
-- 
2.21.0.1020.gf2820cf01a-goog


  parent reply	other threads:[~2019-05-09 21:16 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-09 21:13 [PATCH v3 00/30] Update cros_ec_commands.h Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 01/30] mfd: cros_ec: Update license term Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 02/30] mfd: cros_ec: Zero BUILD_ macro Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 03/30] mfd: cros_ec: set comments properly Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 04/30] mfd: cros_ec: add ec_align macros Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 05/30] mfd: cros_ec: Define commands as 4-digit UPPER CASE hex values Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 06/30] mfd: cros_ec: use BIT macro Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 07/30] mfd: cros_ec: Update ACPI interface definition Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 08/30] mfd: cros_ec: move HDMI CEC API definition Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 09/30] mfd: cros_ec: Remove zero-size structs Gwendal Grignou
2019-05-09 21:13 ` Gwendal Grignou [this message]
2019-05-09 21:13 ` [PATCH v3 11/30] mfd: cros_ec: Add PWM_SET_DUTY API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 12/30] mfd: cros_ec: Add lightbar v2 API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 13/30] mfd: cros_ec: Expand hash API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 14/30] mfd: cros_ec: Add EC transport protocol v4 Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 15/30] mfd: cros_ec: Complete MEMS sensor API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 16/30] mfd: cros_ec: Fix event processing API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 17/30] mfd: cros_ec: Add fingerprint API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 18/30] mfd: cros_ec: Fix temperature API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 19/30] mfd: cros_ec: Complete Power and USB PD API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 20/30] mfd: cros_ec: Add API for keyboard testing Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 21/30] mfd: cros_ec: Add Hibernate API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 22/30] mfd: cros_ec: Add Smart Battery Firmware update API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 23/30] mfd: cros_ec: Add I2C passthru protection API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 24/30] mfd: cros_ec: Add API for EC-EC communication Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 25/30] mfd: cros_ec: Add API for Touchpad support Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 26/30] mfd: cros_ec: Add API for Fingerprint support Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 27/30] mfd: cros_ec: Add API for rwsig Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 28/30] mfd: cros_ec: Add SKU ID and Secure storage API Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 29/30] mfd: cros_ec: Add Management API entry points Gwendal Grignou
2019-05-09 21:13 ` [PATCH v3 30/30] mfd: cros_ec: Update I2S API Gwendal Grignou
2019-05-17 22:48 ` [PATCH v3 00/30] Update cros_ec_commands.h Gwendal Grignou
2019-05-18  6:39   ` Lee Jones
2019-05-21 17:44     ` Benson Leung
2019-05-22  5:53       ` Lee Jones
2019-05-21 13:45 ` [alsa-devel] " Fabien Lahoudere
2019-05-22  5:53   ` Lee Jones
2019-06-03 12:53 ` Lee Jones

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=20190509211353.213194-11-gwendal@chromium.org \
    --to=gwendal@chromium.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=bleung@chromium.org \
    --cc=broonie@kernel.org \
    --cc=cychiang@chromium.org \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@chromium.org \
    --cc=jic23@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tiwai@suse.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).