-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ipc reduced structures #19877
base: main
Are you sure you want to change the base?
Ipc reduced structures #19877
Conversation
The following west manifest projects have changed revision in this Pull Request:
✅ All manifest checks OK Note: This message is automatically posted and updated by the Manifest GitHub Action. |
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: da9293880a5a24a497a05449a8ef893a602655ad more detailssdk-nrf:
Github labels
List of changed files detected by CI (8)
Outputs:ToolchainVersion: 342151af73 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
3f4fe33
to
860ba08
Compare
860ba08
to
49791bb
Compare
bcbe9c9
to
51738bc
Compare
You can find the documentation preview for this PR at this link. Note: This comment is automatically posted by the Documentation Publish GitHub Action. |
b2f47e9
to
461afba
Compare
461afba
to
000dcf7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revied only the new structures definitions.
include/drivers/mspi/nrfe_mspi.h
Outdated
typedef struct { | ||
nrfe_mspi_opcode_t opcode; /* nrfe_mspi_opcode */ | ||
uint32_t command; | ||
uint32_t address; | ||
uint32_t num_bytes; | ||
} nrfe_mspi_xfer_packet_t; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is data?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I don't know the data size I couldn't add it as a field to the structure, so the data is appended at the end of structure when sending is through IPC to VPR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not send a pointer to the data then? I do not like that data is hidden in this solution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is already a task for that
https://nordicsemi.atlassian.net/browse/NRFX-6939
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@masz-nordic maybe you could see a different solution to this. Currently, data is assumed to be right after this structure in memory, because it is copied and its size may vary. All data is copied and not sent by a pointer, so that it would work on Lilium, where cores do not have access to each other's memory. Since there is a ticket for adding a solution that will work only on socs where all memory is accessible to APP and FLPR, I will not insist on implementing it in this PR. But maybe there is a better way of sending data in Lilium case than "hiding" it after the structure? I am still not a fan of this.
@nika-nordic maybe you have some insight into how data buffers are sent between cores in Lilium? Or @nordic-krch? I guess it might be a part of logging with STM.
include/drivers/mspi/nrfe_mspi.h
Outdated
enum mspi_cpp_mode cpp; | ||
enum mspi_endian endian; | ||
bool hold_ce; | ||
nrfe_mspi_polarity_t ce_polarities[NRFE_MSPI_CE_PINS_MAX]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we sending multiple CE polarities, if there is only one CE (ce_num
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have to send polarities of all the pins so that VPR knows how to set them to inactive state when sending data to only one of them. ce_num is the index of the device with which we want to talk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we have different understandings of the configuration phase, so let me explain my point of view. Zephyr's MSPI driver API has two configuration functions: mspi_config
and mspi_dev_config
. mspi_config
is used to configure the driver itself (doc: "Configure a MSPI controller."), and it takes data from DTS, which makes sense because the driver can be limited by the hardware (DTS files are supposed to describe hardware). So in DTS files you have specified CE lines that COULD be used by the driver user, meaning which hardware pins can be used by the driver as CE. Not all of them have to be used, it is just a possibility on a given soc.
Then, we also have mspi_dev_config
, which should be used to configure a peripheral MSPI device (doc: "Configure a MSPI controller with device-specific parameters."), and it takes the mspi_dev_cfg
structure (which is specified by the driver's user), which contains info, which CE PIN should be used, of the ones that are possible, and its polarity. So, we can set the pin to its inactive state in the driver as soon as the device is configured by the user.
I would assume, that all devices should or even must be configured before the first TX/RX happens, because I cannot imagine a scenario when some device has to be configured after we've already sent something to another device. If there is such case, let me know, it is possible I am not aware of something. But otherwise, I would send just one pin number and one pin polarity in nrfe_mspi_xfer_config_t
. Sure, there might be a case for specifying the polarity of all possible CE pins at once, which we do not know of yet, but IF such case appears, THEN we will worry about it.
include/drivers/mspi/nrfe_mspi.h
Outdated
NRFE_MSPI_TX, | ||
NRFE_MSPI_TXRX, | ||
NRFE_MSPI_CONFIG_PINS, /*nrfe_mspi_pinctrl_soc_pin_t*/ | ||
NRFE_MSPI_CONFIG_XFER, /*nrfe_mspi_xfer_config_t*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I would rename it to NRFE_MSPI_CONFIG_DEV
, because it is more similar to mspi_dev_cfg
than to mspi_xfer
.
000dcf7
to
61ce62d
Compare
3d095bb
to
dffb578
Compare
Memory footprint analysis revealed the following potential issuessample.matter.template.debug[nrf7002dk/nrf5340/cpuapp]: High ROM usage: 912194[B] - link (cc: @kkasperczyk-no @ArekBalysNordic @markaj-nordic) Note: This message is automatically posted and updated by the CI (latest/sdk-nrf/PR-19877/25) |
a674e62
to
b749c23
Compare
d779c02
to
b361226
Compare
kobj-types-enum.h was generated after VPR asm_gen, added kobj-types-enum.h as dependence for asm_gen. Signed-off-by: Michal Frankiewicz <[email protected]>
added mode support for SINGLE,QUAD,QUAD_1_4_4,QUAD_1_1_4 and custom Ipc mspi structures Signed-off-by: Michal Frankiewicz <[email protected]> Signed-off-by: Jakub Zymelka <[email protected]>
Added reactions to all mspi Ipc messages but NRFE_MSPI_TXRX and NRFE_MSPI_TX. The data is stored in local structures for later use. Signed-off-by: Michal Frankiewicz <[email protected]>
Added MSPI_TX reaction to NRFE_MSPI_TXRX and NRFE_MSPI_TX. Added HRT mspi TX functionality. Signed-off-by: Michal Frankiewicz <[email protected]>
b361226
to
846177c
Compare
Implemented smaller structures and reduced ammount of opcodes in IPC Signed-off-by: Michal Frankiewicz <[email protected]>
Implemented smaller structures and reduced ammount of opcodes in IPC Signed-off-by: Michal Frankiewicz <[email protected]>
846177c
to
da92938
Compare
Depends on #19449