This removes all occurrences of arm,num-mpu-regions relying on the value
reported by the register instead.
A user may still define this property if they need to have a compile time
definition for it.
Signed-off-by: Wilfried Chauveau <wilfried.chauveau@arm.com>
Add initial support for gd32l23x series. gd32l23x used Cortex-M23, based
on ARMv8-M baseline, implement the System Timer.
Signed-off-by: HaiLong Yang <hailong.yang@brainco.cn>
Add config cell property to gd,gd32-dma.
For supporting hardware variation, Splitting base definition
to gd,gd32-dma-base.yaml.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
There are three types GD32 FMC.
GD32 FMC v1: its flash memory has 1 bank, page size is equal in the
bank, flash size is smaller than 512KB.
GD32 FMC v2: its flash memory has 2 banks. Page size equal within the
same bank but different between banks. Flash size can be up to 3072KB.
FMC v2 has two registers to control bank0 and bank1 separately.
GD32 FMC v3: its flash memory has 2 banks, use sector size as the
minimum operating unit, the sector size is not equal.
Signed-off-by: HaiLong Yang <hailong.yang@brainco.cn>
Use the clock control API to enable peripheral clocks. Note that both
GPIO and pinctrl drivers are updated at once since they share some IP
blocks.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Use the clock control API to turn on ADC clocks. Note that clock
selection is not yet implemented, so we still rely on custom rcu
properties for that.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
This patch adds a clock control driver for GD32 platforms. It is
important to note that the driver is only able to handle peripheral
clocks, but not "system clocks" (e.g. PLL settings, SYS_CK, etc.). On
some similar platforms (STM32) this task is embedded in the same clock
driver, performed at init time but with no options to do any
manipulation at runtime via the API calls. The clock control API as-is
is really orthogonal to "system clocks", and it is arguably a bad idea
to embed system clock init code in a clock control driver. It can be
done at SoC level still using Devicetree as a source of hardware
description/initial configuration.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
There is only a single DMA in GD32F3X0. It is referenced as DMA in
datasheet, not DMA0 as in series that have > 1.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
All 'k' parts share the same amount of RAM/FLASH, so rename file to
include 'x' instead of 'i'.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Add a new reset driver for GD32 platforms. This driver controls the
reset registers from the RCU peripheral. It can be used to restore
peripherals to their initial state when initializing a device.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
According to DT spec, device_type property is deprecated (ref. 0.3 spec,
2.3.11):
> The device_type property was used in IEEE 1275 to describe the device’s
FCode programming model. Because DTSpec does not have FCode, new use
of the property is deprecated, and it should be included only on cpu and
memory nodes for compatibility with IEEE 1275–derived devicetrees.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Set the default value for SYS_CLOCK_HW_CYCLES_PER_SEC based on DT cpu0
clock-frequency property.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Set the default value for SYS_CLOCK_HW_CYCLES_PER_SEC based on DT cpu0
clock-frequency property.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Make use of nodelabels to extend flash/sram nodes instead of re-defining
the whole tree. This pattern is already used in some other files.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
In order to bring consistency in-tree, migrate all dts code to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add the period cell to GD32 PWM compatible and update all boards
accordingly. A period of 20 ms (50 Hz) has been set for all PWM LEDs.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
