-
Notifications
You must be signed in to change notification settings - Fork 295
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
openamp: divide shram to TX shram & RX shram #375
Conversation
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.
This needs a detailed explanation as to why the check that the other end is ready is unnecessary.
19e3b69
to
1e42d03
Compare
Okay. Patch 1. In the multi core of lower power device, when one of core enters sleep, it needs to put its corresponding share memory into retention mode to save power consumption. Based on the limitations of the chip design, when the CPU to which share memory belongs goes to sleep, the share memory enters the retention mode, and other cores will not be able to access it. When the share memory divides tx shm and rx shm and the core of tx shm and rx shm are different, so that when one CPU sleeps, the other CPU can still access its own tx shm. Patch 2. Base 1, The call of rproc_virtio_get_status will access the resource table, but the resource table only belongs to the shm of one of the CPUs, so after sleep, the other CPU cannot access it, so we don't to check the status for rpmsg_virtio_get_tx_payload_buffer every times. |
827c32b
to
feca5cb
Compare
BTW, the boot already check the status flag: |
To help could you detail your memory mapping to understand in which memory are your shared structures?
which CPU put the memory in retention: both or only one core ( in this case is it the host or the remote processor?) |
Let's name CPU A(master) and B(slave).
SRAM A
tx: SRAM A
SRAM B
SRAM A
SRAM B
both, SRAM A and B can enter the retention state independently. |
Thanks for the details. |
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.
The PR seems to me valid. Few comments/concerns to address.
lib/include/openamp/rpmsg_virtio.h
Outdated
rpmsg_ns_bind_cb ns_bind_cb, | ||
struct metal_io_region *shm_io, | ||
struct rpmsg_virtio_shm_pool *tx_shpool, | ||
struct rpmsg_virtio_shm_pool *rx_shpool); |
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.
The const struct rpmsg_virtio_config *config param is mising
d4f0fed
to
a0ff158
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.
Otherwise, this looks reasonable.
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.
minor fixes on comments and commit message else LGTM
In the multi core of lower power device, when one of core enters sleep, it needs to put its corresponding share memory into retention mode to save power consumption. Based on the limitations of the chip design, when the CPU to which share memory belongs goes to sleep, the share memory enters the retention mode, and other cores will not be able to access it. When the share memory divides tx shm and rx shm and the core of tx shm and rx shm are different, so that when one CPU sleeps, the other CPU can still access its own tx shm. Signed-off-by: Guiding Li <[email protected]> Signed-off-by: Jiuzhu Dong <[email protected]>
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.
Looks good to me. I appreciate the commit message explaining why this code is needed.
openamp: divide shram to TX shram & RX shram
Signed-off-by: Guiding Li [email protected]
Signed-off-by: Jiuzhu Dong [email protected]