When its remote core publishes a message, all subscribed cores will receive the message,
but the local core "stublist" does not update the user's "generation" and "bufferpos" parameters.
Signed-off-by: likun17 <likun17@xiaomi.com>
After the ap core subscribes to the 25hz batch 120ms data of the sensor core, it switches
to the cp core and subscribes to the 50hz batch 120ms sensor core data. At this time,
the data subscribed by the AP will be abnormally lost (12.5hz). Mainly because ap
subscribes to sensor core data earlier than cp. The subscription of cp will be broadcast
to the ap core at the same time, and the corresponding "path" already exists
under "/dev/uorb" of ap. Thus the ap will create a "stub".
There are some restrictions on the creation of "stub" to avoid this situation.
Signed-off-by: likun17 <likun17@xiaomi.com>
Error: mmcsd/mmcsd_sdio.c:1419:12: error: 'mmcsd_setblockcount' defined
but not used [-Werror=unused-function]
1172 1419 | static int mmcsd_setblockcount(FAR struct mmcsd_state_s
*priv,
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
1. notify POLLIN to reader.
2. notify POLLPRI to writer,
in addition, notify POLLPRI to the user who completed the flush .
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Supports the flush operation of the sensor.
The application can initiate a flush action through ioctl SNIOC_FLUSH
to trigger flush, and the call will be returned immediately.
Using SNIOC_GET_EVENTS to clear flush event,
However, the flush implementation is asynchronous, when all the flush
data is push to upper circbuffer, the POLLPRI event(FLUSH_COMPLETED)
will be reported.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
When there is an actual physical sensor, the driver must implement the get info interface. The upper layer can obtain the actual physical sensor information through SNIOC_GET_INFO.
SNIOC_SET_INFO can only set the information of the local virtual sensor, which means it is bound to the local advertisement. Remote subscribers cannot set the information.
Usage:
struct sensor_device_info dev_info;
orb_ioctl(fd, SNIOC_GET_INFO, (unsigned long)(uintptr_t)&dev_info);
or:
ret = orb_set_info(fd, &dev_info);
ret = orb_get_info(fd, &dev_info);
Signed-off-by: likun17 <likun17@xiaomi.com>
Make sure that interrups are disabled during initialization.
This is a proper fix for an unexpected MSI interrupt for PCI serial driver.
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
The interaction between the shell service in adb and adbd occurs through a pseudo-terminal (pty).
so, when a command is launched through adb shell from a PC, users now have the ability to pause
or kill the launched,application by inputting specific commands CONFIG_TTY_SIGTSTP_CHAR or
CONFIG_TTY_SIGTINT_CHAR, akin to the capabilities provided by nsh.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
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>
x86_64 uses 4-5G virtual addresses, we need to convert them into physical addresses and pass them to qemu, otherwise qemu will fail to map
Signed-off-by: liwenxiang1 <liwenxiang1@xiaomi.com>
when multiple processes call poll and a event occured,
all the processes are waked up. it should wake up one
process based on pipe->id
Signed-off-by: zhanghu5 <zhanghu5@xiaomi.com>
Revert "Parallelize depend file generation"
This reverts commit d5b6ec450f.
parallel depend ddc does not significantly speed up compilation,
intermediately generated .ddc files can cause problems if compilation is interrupted unexpectedly
Signed-off-by: xuxin19 <xuxin19@xiaomi.com>
add support for UART 16550 compatible PCI device.
For now we support qemu serial PCI devices and AX99100 based cards.
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
prepare 16550 UART driver to support PCI:
- [breaking change] change argument of uart_ioctl() from `struct file *filep` to `FAR struct u16550_s *priv`
Also fix moxart_16550.c build related to this change
- [breaking change] change argument of uart_getreg() and uart_putreg from `uart_addrwidth_t base` to `FAR struct u16550_s *priv`
Also fix arch/x86/src/qemu/qemu_serial.c and arch/x86_64/src/intel64/intel64_serial.c related to this change
- [breaking change] change argument of uart_dmachan() from `uart_addrwidth_t base` to `FAR struct u16550_s *priv`
- move `struct u16550_s` to public header
- generalize UART_XXX_OFFSET so we can use it with any register increment
- make u16550_bind(), u16550_interrupt(), u16550_interrupt() public
- remove arch/or1k/src/common/or1k_uart.c and use common 16550 MIMO interfacve
- change irq type in `struct u16550_s` from uint8_t to int to match MSI API
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
move MCR_OUT2 configuration from qemu-intel64/src/qemu_boot.c to common code
also leave this option disabled for qemu-intel64 as it's not required
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
Some of PCI drivers require OS interfaces that can't be executed in the INIT context.
In that case we have to postpone PCI drivers probing and call it for example
in board initialization logic.
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
1. Some platforms do not support interrupt mode (PCI_MSI/MSIX),
so add polling mode support, so these platforms can also use virtio-pci;
2. In some cases, we do not want to use the interrupt for virtio driver
to avoid time jitter, so add the polling mode support;
3. If CONFIG_DRIVERS_VIRTIO_PCI_POLLING_PERIOD <= 0, interrupt mode.
if CONFIG_DRIVERS_VIRTIO_PCI_POLLING_PERIOD > 0, polling mode.
Signed-off-by: wangyongrong <wangyongrong@xiaomi.com>
Follow the virtio spec, support the virtio pci Legacy
Signed-off-by: wangyongrong <wangyongrong@xiaomi.com>
Signed-off-by: andi <andi6@xiaomi.com>
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
1. only support pci modern device;
2. need the pci controller support MSI/MSI-X;
It has been verified based on virtio-rng and virtio-net.
Signed-off-by: Yongrong Wang <wangyongrong@xiaomi.com>
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
