1. Add the regulator driver framework.
2. Add the generic voltage and current regulator API support
for drivers.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
* [DM/FEATURE] Support reset controller
Reset controllers are central units that control
the reset signals to multiple peripherals.
The reset controller API is split into two parts:
1. The consumer driver interface, which allows
peripheral drivers to request control over
their reset input signals
2. The reset controller driver interface
which is used by drivers for reset controller devices to
register their reset controls to provide them to the consumers.
* [RESET/SIMPLE] Support simple reset
Currently this driver supports:
- Altera SoCFPGAs
- ASPEED BMC SoCs
- Bitmain BM1880 SoC
- Realtek SoCs
- RCC reset controller in STM32 MCUs
- Allwinner SoCs
- SiFive FU740 SoCs
- Sophgo SoCs
Signed-off-by: GuEe-GUI <2991707448@qq.com>
This framework will be of use only to devices that use
external PHY (PHY functionality is not embedded within the controller).
Use in PCIE, USB, HDMI, DP...
Signed-off-by: GuEe-GUI <2991707448@qq.com>
* [DM/FEATURE] Support NVME
1. Support PRP and SGL (>= NVME v1.1) transport.
2. Support MSI/MSI-X for IO queues.
3. Support NVME on PCI.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
1. Disk and blk device management.
2. Support partitions probe auto.
3. Support DFS and user mode fops, ioctl.
4. Add a cmd for blk info.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
1. Default return OK when input NULL (if is not necessary in device).
2. Support object parse in OFW.
3. Support CLK depends fix auto.
4. Fixup rt_clk_array_prepare_enable and rt_clk_array_disable_unprepare.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
old phy bus is too simple add phy_bus is not adapt rt_bus framework,so writer a stronger phy bus framework.
here is my commit message:
add mdio bus and phy bus to kernel,the phy bus use rt_bus framewok ,driver writer can write phy_driver first .when mac driver need to use phy they can register phy_device and pjhy_devie will serach for driver which match by uid and mask,if no driver match with the device that you register,phy_bus will return the genphy to you device,the genphy driver is the general driver for phy,so you can use it but it can not support the capcity of chip it may be cause performance is not up to peak
We need a API to fix the driver load auto when
a second driver get it in probe process that
we can not be careful of the driver-to-driver's
depends in different SoC.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
Drivers can manage their own IDs without having to concern
themselves with the register/unregister in system
Link: https://github.com/RT-Thread/rt-thread/issues/9534
Signed-off-by: GuEe-GUI <2991707448@qq.com>
add pci api,the pci/pcie driver writer can use this to get resource of current device with flag,there are three flag :
1. PCI_BUS_REGION_F_MEM it mean memory space
2. PCI_BUS_REGION_F_IO it mean io space
3. PCI_BUS_REGION_F_PREFETCH it mean prefetchable memory
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>
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>
* support period time
* enable multiple ktimer
* mv set delay_cnt to hrtimer_start
* add ktime debug info
* change current_irq_begin to local var
* fix bug: setting current timer and setting timeout in driver aren't atomicly
* create->init
* refactoring ktime
* [DM/feature] Implement PIC irq state { get; set }
There are some common state for irq:
1. Pending: IRQ was triggered, but software not ACK.
2. Active: IRQ was ACK, but not EOI.
3. Masked: IRQ was masked or umasked.
Signed-off-by: GuEe-GUI <2991707448@qq.com>
* [DM/pic] Support IRQ state { get; set } for ARM GICv2/v3
Signed-off-by: GuEe-GUI <2991707448@qq.com>
---------
Signed-off-by: GuEe-GUI <2991707448@qq.com>
GuEe-GUI
GUI
zhuzhuzhu
wdfk-prog
Kai
CYFS
hydevcode
Supper Thomas
CXSforHPU
Shell
zms123456