Fix some code style and init for V2M, ITS.
V2M is the PCI MSI/MSI-X for GICv2.
ITS is the PCI MSI/MSI-X for GICv3/v4.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
PIC may free because some wrongs in debug.
We should remove in PIC list or there are
some undefined behavior will happen.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
The ofw parse should:
1. Check obj_name EQU the current node's rt_data.
2. Find the next object name.
3. goto "2" until obj_name EQU the cmp_cell's obj_name.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
When the driver request a API gets RT_NULL which return value is ptr,
they could not know why get a RT_NULL.
some API return RT_NULL, is not error internal maybe, it just not
supported for this platform, but the driver still could work ok,
the API can return (RT_NULL + -RT_EEMPTY) to driver.
on the other hand, the driver can do more behaviors by error no.
When the API return the -RT_EBUSY, driver can wait for a moment and retry.
When the API return the -RT_ENOSYS, driver can try the next mode or request's name.
Signed-off-by: GuEe-GUI <wusongjie@rt-thread.com>
PCI/PCIe have better performance and more devices support, such as
NVMe, GPU, Powerful NIC (Like RDMA). PCI/PCIe can access control by
IOMMU that the virtualiztion and userspace driver will more safety.
PCI/PCIe device could hot plugging, no design modifications SoC required,
PCI/PCIe on Embedded SoC is popular now.
We make a simple framework to support them.
Feature Lists:
1.PCI INTx: the INT[A-D] pin IRQ for legacy PCI, work with platform PIC.
2.MSI/MSI-X: the message write IRQ for PCIe, work with platform's PIC.
3.PME: we only support the D0, D1, D2, D3HOT, D3COLD init by framework.
4.Endpoint: a simple EP framework for PCI FPGA or NTB function.
5.OFW: we only support work on OFW SoC, ACPI support in the future maybe.
Host controller:
1. Common PCI host controller on ECAM.
2. Generic PCI host controller on ECAM.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
1. RT_FIELD_PREP: prepare a bitfield element.
2. RT_FIELD_GET: extract a bitfield element.
3. rt_offsetof: member offset of a struct
4. rt_upper_32_bits: high 32 bits of value.
5. rt_lower_32_bits: lower 32 bits of value.
6. rt_upper_16_bits: high 16 bits of value.
7. rt_lower_16_bits: lower 16 bits of value.
8. rt_max_t: fix type of max(...).
9. rt_ilog2: integer logarithm base 2.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
Since the completion is used to sync with ISR mostly, we should set the
default semantic to ISR-safe. So most user will be happy and don't see
any weird behavior in their codes.
Changes:
- Added `rt_completion_wait_noisr` and
`rt_completion_wait_flags_noisr` functions in `completion.h`,
`completion_comm.c`, `completion_mp.c`, and `completion_up.c`.
- The new APIs allow waiting for completions in non-ISR contexts
while ensuring thread context safety.
- Existing documentation and comments were updated to clarify
usage contexts and emphasize restrictions on ISR usage.
Signed-off-by: Shell <smokewood@qq.com>
The changes unify the tick.c implementations for all risc-v64
architectures, leveraging the CPUTIME feature. This refactoring was
necessary to streamline the codebase, and ensure consistent timer
handling across different platforms.
Changes:
- Updated `Kconfig` in `bsp/cvitek/cv18xx_risc-v` to fix formatting issues.
- Updated .config for BSPs to update `CPUTIME_TIMER_FREQ`
- Updated header of for API `riscv_cputime_init`
- Initialized riscv timer on `rt_hw_tick_init`
- Refactored `tick.c` and `tick.h` in `libcpu/risc-v/t-head/c906` and `libcpu/risc-v/virt64`:
- Replaced direct use of `rdtime` with `clock_cpu_gettime`.
- Removed redundant timer frequency definitions.
- Added static assertions to check the value of `CPUTIME_TIMER_FREQ`.
- Initialized `tick_cycles` based on `CPUTIME_TIMER_FREQ`.
- Integrated `ktime` support for tick initialization.
Signed-off-by: Shell <smokewood@qq.com>
Reviewed-on: https://github.com/RT-Thread/rt-thread/pull/9164
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
CYFS
zhujiale
GuEe-GUI
milo
Supper Thomas
CXSforHPU
SeliverWang
Yaochenger
sakumisu
zhugengyu
Shell
Fan YANG
zhao maosheng
kurisaw
wdfk-prog
zms123456