| 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 |
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
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 >
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
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 --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);
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(+)