diff mbox series

soc: qcom: smem: Document shared memory item IDs and corresponding structs

Message ID 20230915175907.17134-1-quic_jhugo@quicinc.com
State New
Headers show
Series soc: qcom: smem: Document shared memory item IDs and corresponding structs | expand

Commit Message

Jeffrey Hugo Sept. 15, 2023, 5:59 p.m. UTC
Shared memory items are assigned a globally unique ID and almost always
have a defined structure which is stored in the shared memory.  Document
assigned IDs and corresponding structures.

Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
---

Konrad, before I get too far into this, I was hoping for some early
feedback since this documentation is a request that you made.

Please let me know if this is aligned with what you were wanting.

 include/linux/soc/qcom/smem.h | 176 ++++++++++++++++++++++++++++++++++
 1 file changed, 176 insertions(+)

Comments

Konrad Dybcio Sept. 15, 2023, 6:09 p.m. UTC | #1
On 15.09.2023 19:59, Jeffrey Hugo wrote:
> Shared memory items are assigned a globally unique ID and almost always
> have a defined structure which is stored in the shared memory.  Document
> assigned IDs and corresponding structures.
> 
> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
> ---
> 
> Konrad, before I get too far into this, I was hoping for some early
> feedback since this documentation is a request that you made.
> 
> Please let me know if this is aligned with what you were wanting.
This is super nice, I'll just leave you with a few nitty
code-style pointers.

> +/* fixed items - these have a static position in shared memory */
Meaningless but eye-pleasing - comments should start with an
uppercase letter

> +#define SMEM_PROC_COMM				0
In many places like this where we essentially have a firmware
interface, it is customary to go like this:

#define FWNAME_CALL_SOMETHING_FOO	(magicval1)
struct fwname_something_foo {
	[...]
};

#define FWNAME_CALL_SOMETHING_BAR	(magicval2)
struct fwname_something_bar {
	[...]
};

This makes matching the call/function/whatev name with what
it expects/returns easier for a typical human

[...]

> +/* Legacy communication protocol between "Apps" and "Modem" processors */
The comments explaining what this does are a great addition, I
think in the spirit of that previous suggestion, they could go
like this:

/* blah blah blah yes yes yes */
#define FWNAME_CALL_SOMETHING_FOO	(magicval1)
struct fwname_something_foo {
	[...]
};

/* blah blah something something */
#define FWNAME_CALL_SOMETHING_BAR	(magicval2)
struct fwname_something_bar {
	[...]
};


[...]

> +/* SMEM_ALLOCATION_TABLE is an array of these structures.  512 elements in the array. */
> +struct smem_heap_entry {
> +        __le32 allocated;
> +        __le32 offset;
> +        __le32 size;
> +        __le32 reserved; /* bits 1:0 reserved, bits 31:2 aux smem base addr */
If we have an integer split into bitfields or similar, something
like this would make it both readable and usable in code:

struct smem_heap_entry {
        __le32 allocated;
        __le32 offset;
        __le32 size;
        __le32 reserved;
#define SMEM_HEAP_ENTRY_BASE_ADDR GENMASK(31, 2)
#define SMEM_HEAP_ENTRY_RESERVED GENMASK(1, 0)
};

[...]

> +#define FLASH_PART_MAGIC1       0x55EE73AA
> +#define FLASH_PART_MAGIC2       0xE35EBDDB
> +#define FLASH_PTABLE_V3         3
> +#define FLASH_PTABLE_V4         4
> +#define FLASH_PTABLE_MAX_PARTS_V3 16
> +#define FLASH_PTABLE_MAX_PARTS_V4 32
> +#define FLASH_PTABLE_ENTRY_NAME_SIZE 16
Similarly having such magic values under the corresponding struct
member would make things more obvious

> +
> +struct flash_partition_entry {
> +        char name[FLASH_PTABLE_ENTRY_NAME_SIZE];
> +        __le32 offset;     /* Offset in blocks from beginning of device */
> +        __le32 length;     /* Length of the partition in blocks */
> +        u8 attr;           /* Flags for this partition */
Comments like this are welcome too, particularly where things
are "very not obvious", like here where length is in blocks
and not bytes.

But if we had something like "u32 flags" followed by a bunch
of defines, that's self-explanatory.

Konrad
Bjorn Andersson Sept. 16, 2023, 1:37 a.m. UTC | #2
On Fri, Sep 15, 2023 at 11:59:07AM -0600, Jeffrey Hugo wrote:
> Shared memory items are assigned a globally unique ID and almost always
> have a defined structure which is stored in the shared memory.  Document
> assigned IDs and corresponding structures.
> 
> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
> ---
> 
> Konrad, before I get too far into this, I was hoping for some early
> feedback since this documentation is a request that you made.
> 
> Please let me know if this is aligned with what you were wanting.
> 
>  include/linux/soc/qcom/smem.h | 176 ++++++++++++++++++++++++++++++++++
>  1 file changed, 176 insertions(+)
> 
> diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
> index 223db6a9c733..2f8d1f3126a4 100644
> --- a/include/linux/soc/qcom/smem.h
> +++ b/include/linux/soc/qcom/smem.h
> @@ -4,6 +4,182 @@
>  
>  #define QCOM_SMEM_HOST_ANY -1
>  
> +/* fixed items - these have a static position in shared memory */
> +#define SMEM_PROC_COMM				0

Other parts of this interface are prefixed with qcom_.

> +#define SMEM_HEAP_INFO				1
> +#define SMEM_ALLOCATION_TABLE			2
> +#define SMEM_VERSION_INFO			3
> +#define SMEM_HW_RESET_DETECT			4
[..]
> +
> +/* Legacy communication protocol between "Apps" and "Modem" processors */
> +struct smem_proc_comm {

This is already defined in smem.c, with the same name, but slightly
different definition.

I always envisioned that we would treat this as an smem-internal
implementation detail and expose a function to invoke a proc command, if
someone cared...

Does including it here in the client api definition make sense? Is the
first entry in the smem_heap_entry list pointing to this data, even
though it's part of the header?

> +        __le32 command;
> +        __le32 status;
> +        __le32 data1;
> +        __le32 data2;
> +};
> +
> +/* Metadata structure for shared memory heap allocations */
> +struct smem_heap_info {

This, and the next entry shouldn't be accessed outside the heap
implementation itself...

> +        __le32 initialized;
> +        __le32 free_offset;
> +        __le32 heap_remaining;
> +        __le32 reserved;
> +};
> +
> +/* SMEM_ALLOCATION_TABLE is an array of these structures.  512 elements in the array. */
> +struct smem_heap_entry {
> +        __le32 allocated;
> +        __le32 offset;
> +        __le32 size;
> +        __le32 reserved; /* bits 1:0 reserved, bits 31:2 aux smem base addr */
> +};
> +
> +struct smem_version_info {
> +	__le32 version[32];
> +};
> +
> +struct smem_spinlock_array {
> +	volatile __le32 lock[8];
> +};
> +
> +#define FLASH_PART_MAGIC1       0x55EE73AA
> +#define FLASH_PART_MAGIC2       0xE35EBDDB
> +#define FLASH_PTABLE_V3         3
> +#define FLASH_PTABLE_V4         4
> +#define FLASH_PTABLE_MAX_PARTS_V3 16
> +#define FLASH_PTABLE_MAX_PARTS_V4 32
> +#define FLASH_PTABLE_ENTRY_NAME_SIZE 16
> +
> +struct flash_partition_entry {
> +        char name[FLASH_PTABLE_ENTRY_NAME_SIZE];
> +        __le32 offset;     /* Offset in blocks from beginning of device */
> +        __le32 length;     /* Length of the partition in blocks */
> +        u8 attr;           /* Flags for this partition */
> +};
> +
> +struct flash_partition_table {
> +        __le32 magic1;
> +        __le32 magic2;
> +        __le32 version;
> +        __le32 numparts;
> +        struct flash_partition_entry part_entry[FLASH_PTABLE_MAX_PARTS_V4];
> +};

This information already exist in qcomsmempart.c, but with slightly
different names.

> +
> +/* SMEM_CHANNEL_ALLOC_TBL is an array of these.  Used for SMD. */
> +struct smd_alloc_elm {

This is called qcom_smd_alloc_entry, in qcom_smd.c...

Regards,
Bjorn

> +        char name[20];
> +        __le32 cid;
> +        __le32 type;
> +        __le32 ref_count;
> +};
> +
>  int qcom_smem_alloc(unsigned host, unsigned item, size_t size);
>  void *qcom_smem_get(unsigned host, unsigned item, size_t *size);
>  
> -- 
> 2.40.1
>
Jeffrey Hugo Sept. 22, 2023, 4:42 p.m. UTC | #3
On 9/15/2023 12:09 PM, Konrad Dybcio wrote:
> On 15.09.2023 19:59, Jeffrey Hugo wrote:
>> Shared memory items are assigned a globally unique ID and almost always
>> have a defined structure which is stored in the shared memory.  Document
>> assigned IDs and corresponding structures.
>>
>> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
>> ---
>>
>> Konrad, before I get too far into this, I was hoping for some early
>> feedback since this documentation is a request that you made.
>>
>> Please let me know if this is aligned with what you were wanting.
> This is super nice, I'll just leave you with a few nitty
> code-style pointers.
> 
>> +/* fixed items - these have a static position in shared memory */
> Meaningless but eye-pleasing - comments should start with an
> uppercase letter
> 
>> +#define SMEM_PROC_COMM				0
> In many places like this where we essentially have a firmware
> interface, it is customary to go like this:
> 
> #define FWNAME_CALL_SOMETHING_FOO	(magicval1)
> struct fwname_something_foo {
> 	[...]
> };
> 
> #define FWNAME_CALL_SOMETHING_BAR	(magicval2)
> struct fwname_something_bar {
> 	[...]
> };
> 
> This makes matching the call/function/whatev name with what
> it expects/returns easier for a typical human
> 
> [...]
> 
>> +/* Legacy communication protocol between "Apps" and "Modem" processors */
> The comments explaining what this does are a great addition, I
> think in the spirit of that previous suggestion, they could go
> like this:
> 
> /* blah blah blah yes yes yes */
> #define FWNAME_CALL_SOMETHING_FOO	(magicval1)
> struct fwname_something_foo {
> 	[...]
> };
> 
> /* blah blah something something */
> #define FWNAME_CALL_SOMETHING_BAR	(magicval2)
> struct fwname_something_bar {
> 	[...]
> };
> 
> 
> [...]
> 
>> +/* SMEM_ALLOCATION_TABLE is an array of these structures.  512 elements in the array. */
>> +struct smem_heap_entry {
>> +        __le32 allocated;
>> +        __le32 offset;
>> +        __le32 size;
>> +        __le32 reserved; /* bits 1:0 reserved, bits 31:2 aux smem base addr */
> If we have an integer split into bitfields or similar, something
> like this would make it both readable and usable in code:
> 
> struct smem_heap_entry {
>          __le32 allocated;
>          __le32 offset;
>          __le32 size;
>          __le32 reserved;
> #define SMEM_HEAP_ENTRY_BASE_ADDR GENMASK(31, 2)
> #define SMEM_HEAP_ENTRY_RESERVED GENMASK(1, 0)
> };
> 
> [...]
> 
>> +#define FLASH_PART_MAGIC1       0x55EE73AA
>> +#define FLASH_PART_MAGIC2       0xE35EBDDB
>> +#define FLASH_PTABLE_V3         3
>> +#define FLASH_PTABLE_V4         4
>> +#define FLASH_PTABLE_MAX_PARTS_V3 16
>> +#define FLASH_PTABLE_MAX_PARTS_V4 32
>> +#define FLASH_PTABLE_ENTRY_NAME_SIZE 16
> Similarly having such magic values under the corresponding struct
> member would make things more obvious
> 
>> +
>> +struct flash_partition_entry {
>> +        char name[FLASH_PTABLE_ENTRY_NAME_SIZE];
>> +        __le32 offset;     /* Offset in blocks from beginning of device */
>> +        __le32 length;     /* Length of the partition in blocks */
>> +        u8 attr;           /* Flags for this partition */
> Comments like this are welcome too, particularly where things
> are "very not obvious", like here where length is in blocks
> and not bytes.
> 
> But if we had something like "u32 flags" followed by a bunch
> of defines, that's self-explanatory.

Thanks.  This all makes sense to me.  Will incorporate this feedback as 
I go.

-Jeff
Jeffrey Hugo Sept. 22, 2023, 5:07 p.m. UTC | #4
On 9/15/2023 7:37 PM, Bjorn Andersson wrote:
> On Fri, Sep 15, 2023 at 11:59:07AM -0600, Jeffrey Hugo wrote:
>> Shared memory items are assigned a globally unique ID and almost always
>> have a defined structure which is stored in the shared memory.  Document
>> assigned IDs and corresponding structures.
>>
>> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
>> ---
>>
>> Konrad, before I get too far into this, I was hoping for some early
>> feedback since this documentation is a request that you made.
>>
>> Please let me know if this is aligned with what you were wanting.
>>
>>   include/linux/soc/qcom/smem.h | 176 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 176 insertions(+)
>>
>> diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
>> index 223db6a9c733..2f8d1f3126a4 100644
>> --- a/include/linux/soc/qcom/smem.h
>> +++ b/include/linux/soc/qcom/smem.h
>> @@ -4,6 +4,182 @@
>>   
>>   #define QCOM_SMEM_HOST_ANY -1
>>   
>> +/* fixed items - these have a static position in shared memory */
>> +#define SMEM_PROC_COMM				0
> 
> Other parts of this interface are prefixed with qcom_.
> 
>> +#define SMEM_HEAP_INFO				1
>> +#define SMEM_ALLOCATION_TABLE			2
>> +#define SMEM_VERSION_INFO			3
>> +#define SMEM_HW_RESET_DETECT			4
> [..]
>> +
>> +/* Legacy communication protocol between "Apps" and "Modem" processors */
>> +struct smem_proc_comm {
> 
> This is already defined in smem.c, with the same name, but slightly
> different definition.

Unexpected, although I didn't look very hard.

My plan is to do this in phases.  First, gather all the information I 
can and put it in one place.  Then look at what we currently have in 
other committed drivers, and try to link those things up to this.  In 
many cases, I'm thinking we define the item here and have a reference 
comment to the implementation that occurs elsewhere.  All of that gets 
developed and hashed out before we commit a patch.

I think this addresses some of your further comments about overlap.

> I always envisioned that we would treat this as an smem-internal
> implementation detail and expose a function to invoke a proc command, if
> someone cared...
> 
> Does including it here in the client api definition make sense? Is the
> first entry in the smem_heap_entry list pointing to this data, even
> though it's part of the header?

I think having a function to send a proc command if someone cared makes 
sense.  I think keeping the struct in smem-internal and referencing it 
here for documentation purposes would be beneficial.  I don't think this 
needs to be in the client API for code to use.

Yes, smem_heap_entry[1] does point to this, even though its in the 
header.  Thats a quirk of the fixed memory items.

> 
>> +        __le32 command;
>> +        __le32 status;
>> +        __le32 data1;
>> +        __le32 data2;
>> +};
>> +
>> +/* Metadata structure for shared memory heap allocations */
>> +struct smem_heap_info {
> 
> This, and the next entry shouldn't be accessed outside the heap
> implementation itself...
> 
>> +        __le32 initialized;
>> +        __le32 free_offset;
>> +        __le32 heap_remaining;
>> +        __le32 reserved;
>> +};
>> +
>> +/* SMEM_ALLOCATION_TABLE is an array of these structures.  512 elements in the array. */
>> +struct smem_heap_entry {
>> +        __le32 allocated;
>> +        __le32 offset;
>> +        __le32 size;
>> +        __le32 reserved; /* bits 1:0 reserved, bits 31:2 aux smem base addr */
>> +};
>> +
>> +struct smem_version_info {
>> +	__le32 version[32];
>> +};
>> +
>> +struct smem_spinlock_array {
>> +	volatile __le32 lock[8];
>> +};
>> +
>> +#define FLASH_PART_MAGIC1       0x55EE73AA
>> +#define FLASH_PART_MAGIC2       0xE35EBDDB
>> +#define FLASH_PTABLE_V3         3
>> +#define FLASH_PTABLE_V4         4
>> +#define FLASH_PTABLE_MAX_PARTS_V3 16
>> +#define FLASH_PTABLE_MAX_PARTS_V4 32
>> +#define FLASH_PTABLE_ENTRY_NAME_SIZE 16
>> +
>> +struct flash_partition_entry {
>> +        char name[FLASH_PTABLE_ENTRY_NAME_SIZE];
>> +        __le32 offset;     /* Offset in blocks from beginning of device */
>> +        __le32 length;     /* Length of the partition in blocks */
>> +        u8 attr;           /* Flags for this partition */
>> +};
>> +
>> +struct flash_partition_table {
>> +        __le32 magic1;
>> +        __le32 magic2;
>> +        __le32 version;
>> +        __le32 numparts;
>> +        struct flash_partition_entry part_entry[FLASH_PTABLE_MAX_PARTS_V4];
>> +};
> 
> This information already exist in qcomsmempart.c, but with slightly
> different names.
> 
>> +
>> +/* SMEM_CHANNEL_ALLOC_TBL is an array of these.  Used for SMD. */
>> +struct smd_alloc_elm {
> 
> This is called qcom_smd_alloc_entry, in qcom_smd.c...
> 
> Regards,
> Bjorn
> 
>> +        char name[20];
>> +        __le32 cid;
>> +        __le32 type;
>> +        __le32 ref_count;
>> +};
>> +
>>   int qcom_smem_alloc(unsigned host, unsigned item, size_t size);
>>   void *qcom_smem_get(unsigned host, unsigned item, size_t *size);
>>   
>> -- 
>> 2.40.1
>>
diff mbox series

Patch

diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
index 223db6a9c733..2f8d1f3126a4 100644
--- a/include/linux/soc/qcom/smem.h
+++ b/include/linux/soc/qcom/smem.h
@@ -4,6 +4,182 @@ 
 
 #define QCOM_SMEM_HOST_ANY -1
 
+/* fixed items - these have a static position in shared memory */
+#define SMEM_PROC_COMM				0
+#define SMEM_HEAP_INFO				1
+#define SMEM_ALLOCATION_TABLE			2
+#define SMEM_VERSION_INFO			3
+#define SMEM_HW_RESET_DETECT			4
+#define SMEM_AARM_WARM_BOOT			5
+#define SMEM_DIAG_ERR_MESSAGE			6
+#define SMEM_SPINLOCK_ARRAY			7
+#define SMEM_MEMORY_BARRIER_LOCATION		8
+
+/* dynamic items - these are allocated out of the shared memory heap */
+#define SMEM_AARM_PARTITION_TABLE		9
+#define SMEM_AARM_BAD_BLOCK_TABLE		10
+#define SMEM_RESERVE_BAD_BLOCKS			11
+#define SMEM_WM_UUID				12
+#define SMEM_CHANNEL_ALLOC_TBL			13
+#define SMEM_SMD_BASE_ID			14
+#define SMEM_SMEM_LOG_IDX			78
+#define SMEM_SMEM_LOG_EVENTS			79
+#define SMEM_SMEM_STATIC_LOG_IDX		80
+#define SMEM_SMEM_STATIC_LOG_EVENTS		81
+#define SMEM_SMEM_SLOW_CLOCK_SYNC		82
+#define SMEM_SMEM_SLOW_CLOCK_VALUE		83
+#define SMEM_BIO_LED_BUF			84
+#define SMEM_SMSM_SHARED_STATE			85
+#define SMEM_SMSM_INT_INFO			86
+#define SMEM_SMSM_SLEEP_DELAY			87
+#define SMEM_SMSM_LIMIT_SLEEP			88
+#define SMEM_SLEEP_POWER_COLLAPSE_DISABLED	89
+#define SMEM_KEYPAD_KEYS_PRESSED		90
+#define SMEM_KEYPAD_STATE_UPDATED		91
+#define SMEM_KEYPAD_STATE_IDX			92
+#define SMEM_GPIO_INT				93
+#define SMEM_MDDI_LCD_IDX			94
+#define SMEM_MDDI_HOST_DRIVER_STATE		95
+#define SMEM_MDDI_LCD_DISP_STATE		96
+#define SMEM_LCD_CUR_PANEL			97
+#define SMEM_MARM_BOOT_SEGMENT_INFO		98
+#define SMEM_AARM_BOOT_SEGMENT_INFO		99
+#define SMEM_SLEEP_STATIC			100
+#define SMEM_SCORPION_FREQUENCY			101
+#define SMEM_SMD_PROFILES			102
+#define SMEM_TSSC_BUSY				103
+#define SMEM_HS_SUSPEND_FILTER_INFO		104
+#define SMEM_BATT_INFO				105
+#define SMEM_APPS_BOOT_MODE			106
+#define SMEM_VERSION_FIRST			107
+#define SMEM_VERSION_LAST			131
+#define SMEM_OSS_RRCASN1_BUF1			132
+#define SMEM_OSS_RRCASN1_BUF2			133
+#define SMEM_ID_VENDOR0				134
+#define SMEM_ID_VENDOR1				135
+#define SMEM_ID_VENDOR2				136
+#define SMEM_HW_SW_BUILD_ID			137
+#define SMEM_SMD_BASE_ID_2			138
+#define SMEM_SMD_FIFO_BASE_ID_2			202
+#define SMEM_CHANNEL_ALLOC_TBL_2		266
+#define SMEM_I2C_MUTEX				330
+#define SMEM_SCLK_CONVERSION			331
+#define SMEM_SMD_SMSM_INTR_MUX			332
+#define SMEM_SMSM_CPU_INTR_MASK			333
+#define SMEM_APPS_DEM_SLAVE_DATA		334
+#define SMEM_QDSP6_DEM_SLAVE_DATA		335
+#define SMEM_VSENSE_DATA			336
+#define SMEM_CLKREGIM_SOURCES			337
+#define SMEM_SMD_FIFO_BASE_ID			338
+#define SMEM_USABLE_RAM_PARTITION_TABLE		402
+#define SMEM_POWER_ON_STATUS_INFO		403
+#define SMEM_DAL_AREA				404
+#define SMEM_SMEM_LOG_POWER_IDX			405
+#define SMEM_SMEM_LOG_POWER_WRAP		406
+#define SMEM_SMEM_LOG_POWER_EVENTS		407
+#define SMEM_ERR_CRASH_LOG			408
+#define SMEM_ERR_F3_TRACE_LOG			409
+#define SMEM_SMD_BRIDGE_ALLOC_TABLE		410
+#define SMEM_SMDLITE_TABLE			411
+#define SMEM_SD_IMG_UPGRADE_STATUS		412
+#define SMEM_SEFS_INFO				413
+#define SMEM_RESET_LOG				414
+#define SMEM_RESET_LOG_SYMBOLS			415
+#define SMEM_MODEM_SW_BUILD_ID			416
+#define SMEM_SMEM_LOG_MPROC_WRAP		417
+#define SMEM_BOOT_INFO_FOR_APPS			418
+#define SMEM_SMSM_SIZE_INFO			419
+#define SMEM_SMD_LOOPBACK_REGISTER		420
+#define SMEM_SSR_REASON_MSS0			421
+#define SMEM_SSR_REASON_WCNSS0			422
+#define SMEM_SSR_REASON_LPASS0			423
+#define SMEM_SSR_REASON_DSPS0			424
+#define SMEM_SSR_REASON_VCODEC0			425
+#define SMEM_SMP2P_APPS_BASE			427
+#define SMEM_SMP2P_MODEM_BASE			435
+#define SMEM_SMP2P_AUDIO_BASE			443
+#define SMEM_SMP2P_WIRLESS_BASE			451
+#define SMEM_SMP2P_POWER_BASE			459
+#define SMEM_FLASH_DEVICE_INFO			467
+#define SMEM_BAM_PIPE_MEMORY			468
+#define SMEM_IMAGE_VERSION_TABLE		469
+#define SMEM_LC_DEBUGGER			470
+#define SMEM_FLASH_NAND_DEV_INFO		471
+#define SMEM_A2_BAM_DESCRIPTOR_FIFO		472
+#define SMEM_CPR_CONFIG				473
+#define SMEM_CLOCK_INFO				474
+#define SMEM_IPC_FIFO				475
+#define SMEM_RF_EEPROM_DATA			476
+#define SMEM_COEX_MDM_WCN			477
+#define SMEM_GLINK_NATIVE_XPRT_DESCRIPTOR	478
+#define SMEM_GLINK_NATIVE_XPRT_FIFO_0		479
+#define SMEM_GLINK_NATIVE_XPRT_FIFO_1		480
+#define SMEM_SMP2P_SENSOR_BASE			481
+#define SMEM_NUM_ITEMS				489
+
+/* Legacy communication protocol between "Apps" and "Modem" processors */
+struct smem_proc_comm {
+        __le32 command;
+        __le32 status;
+        __le32 data1;
+        __le32 data2;
+};
+
+/* Metadata structure for shared memory heap allocations */
+struct smem_heap_info {
+        __le32 initialized;
+        __le32 free_offset;
+        __le32 heap_remaining;
+        __le32 reserved;
+};
+
+/* SMEM_ALLOCATION_TABLE is an array of these structures.  512 elements in the array. */
+struct smem_heap_entry {
+        __le32 allocated;
+        __le32 offset;
+        __le32 size;
+        __le32 reserved; /* bits 1:0 reserved, bits 31:2 aux smem base addr */
+};
+
+struct smem_version_info {
+	__le32 version[32];
+};
+
+struct smem_spinlock_array {
+	volatile __le32 lock[8];
+};
+
+#define FLASH_PART_MAGIC1       0x55EE73AA
+#define FLASH_PART_MAGIC2       0xE35EBDDB
+#define FLASH_PTABLE_V3         3
+#define FLASH_PTABLE_V4         4
+#define FLASH_PTABLE_MAX_PARTS_V3 16
+#define FLASH_PTABLE_MAX_PARTS_V4 32
+#define FLASH_PTABLE_ENTRY_NAME_SIZE 16
+
+struct flash_partition_entry {
+        char name[FLASH_PTABLE_ENTRY_NAME_SIZE];
+        __le32 offset;     /* Offset in blocks from beginning of device */
+        __le32 length;     /* Length of the partition in blocks */
+        u8 attr;           /* Flags for this partition */
+};
+
+struct flash_partition_table {
+        __le32 magic1;
+        __le32 magic2;
+        __le32 version;
+        __le32 numparts;
+        struct flash_partition_entry part_entry[FLASH_PTABLE_MAX_PARTS_V4];
+};
+
+/* SMEM_CHANNEL_ALLOC_TBL is an array of these.  Used for SMD. */
+struct smd_alloc_elm {
+        char name[20];
+        __le32 cid;
+        __le32 type;
+        __le32 ref_count;
+};
+
 int qcom_smem_alloc(unsigned host, unsigned item, size_t size);
 void *qcom_smem_get(unsigned host, unsigned item, size_t *size);