The new API is defined by GNU and implemented in other LibCs, such as
Musl.
This also modifies API of obstack_blank_fast and obstack_1grow_fast.
These are defined as returning void and thus return value here is
incompatibility with other implementations.
rpmsg_port_spi_connect can not be used here because peer may have not finished
the last transmission which will keep the sreq gpio in high level, and it will
read an error data frame.
Signed-off-by: liaoao <liaoao@xiaomi.com>
Because the data transmision may has been started before
rpmsg_port_initialize(), this should be not allowed.
Signed-off-by: liaoao <liaoao@xiaomi.com>
Rpmsg Port Uart is a new rpmsg transport layer.
Just like the rpmsg port spi, the difference is that the physical
communication method changed from SPI to UART.
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
Add get_local_cpuname to the rpmsg framework ops to support communicate
with the same remote core with multi rpmsg transport.
Some rpmsg services will send local cpu name to remote core and then let
remote core to connect local core by using this cpu name, when there are
multi rpmsg channels with same remote core, the remote core may connect
to incorrect core, so use the error rpmsg channel.
For example, there are two rpmsg channels between ap and audio:
ap core audio core
[ap1] <-- rpmsg virtio1 --> [audio1]
[ap2] <-- rpmsg virtio2 --> [audio2]
When we want to use the rpmsg virtio1 to communicate, ap core may send
local cpuname "ap2" to audio, so the audio core use remote cpu "ap2" to
connect with ap, and resulting in the use of incorrect rpmsg channel.
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
Rpmsg Router is new rpmsg transport layer, it can router the rpmsg
messages to a cpu that not directly connected with local cpu by Rpmsg,
For the rpmsg services, it is as if there is a real Rpmsg Channel between
the local cpu and the remote cpu.
For examples, there are three cpus: ap, cp and audio.
ap and cp, ap and audio has share memory and be connected by Rpmsg VirtIO,
so ap and cp, ap and audio can communicate with each other by Rpmsg, but
cp can not communicate with audio direclty.
[cp] <-- rpmsg virtio --> [ap] <-- rpmsg virtio --> [audio]
With rpmsg router, the cp can communicate with audip by Rpmsg dereclty because
the router in ap will forward the rpmsg message from cp/audio to audio/cp, like
this:
+<----- rpmsg router --> hub <-- rpmsg router ------>+
| | |
[cp] <-- rpmsg virtio --> [ap] <-- rpmsg virtio --> [audio]
Signed-off-by: yintao <yintao@xiaomi.com>
Add Rpmsg-Port-SPI transport layer.
Rpmsg Port SPI is a new rpmsg transport layer based on the Rpmsg Port,
it provides the capability for two SPI-connected (and two extra GPIO)
chips to communicate with each other using Rpmsg.
All already implemented Rpmsg Services can be used with this new transport
layer without any modifications.
Signed-off-by: liaoao <liaoao@xiaomi.com>
Rpmsg Physical Transport Layer is a new rpmsg transport, it's a
common part for the physical communication based rpmsg transport
layers such as Rpmsg-SPI and Rpmsg-Uart.
It implements three common parts:
1. Implement the NuttX and OpenAMP rpmsg frameworks' ops and the
rpmsg name service;
2. The buffer management and provide some APIs to lower layer to use;
Signed-off-by: liaoao <liaoao@xiaomi.com>
This interface may be used by application specific logic to start
specified slave cpu core under the pseudo AMP case which is different
with armv7-a/armv8-a SMP. Support for this function is required by
board-level logic if CONFIG_BOARDCTL_START_CPU is selected.
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
After changing sp, following functions calling will result
in unpredictable behavior in case of jumping
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
In SMP mode, qemu/goldfish platform, cpu0 use up_cpu_start()
to start others cpus.
But in previous patch(mathion ahead), arm_gic_initialize() will
wait others cpus start, so deadlocked!
Resolve:
Move the wait logic when use using sgi
Signed-off-by: ligd <liguiding1@xiaomi.com>
After move the SGI irq to group1, other cpu can't response the
sgi request from cpu0 when its gic not initialized.
So let cpu0 wait until all other cpus gic initialize done.
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
