Main change in this eighth round is the introduction of a new DT bindings
include file for RCC IP drivers. It is for now only used by reset driver,
but goal is to use it also for the clock driver later.
Other changes are bug fix in termios callback of serial driver (uninitialized
variables), and NO_HZ enablement in stm32_defconfig.
STM32 MCUs are Cortex-M CPU, used in various applications (consumer
electronics, industrial applications, hobbyists...).
Datasheets, user and programming manuals are publicly available on
STMicroelectronics website.
With this series applied, the STM32F429 Discovery can boot succesfully.
Note: Patch 2/16 has already been applied by Russell (8340/1).
Changes since v7:
-----------------
- Add DT-bindings header file for RCC IP (Daniel)
- Fix uninitialized variables in serial driver
- Enable CONFIG_NO_HZ in stm32_defconfig
Changes since v6:
-----------------
- serial: Fix locking in case of sysrq (Vladimir)
- Rebase on top of v4.1-rc1
- Apply Acked-by and Reviewed-by
- Clean-up stm32_defconfig
Changes since v5:
-----------------
- Change st,hw-flow-ctrl property to auto-flow-control (Rob)
- Constify stm32_uart_ops (Joe)
- Propagate request_irq error in USART driver (Andy)
- Applies Acked-by and Reviewed-by (Rob, Peter)
Changes since v4:
-----------------
- Cosmetic changes in USART driver (Andy)
- Apply Acks on reset driver & bindings (Philipp & Rob)
Changes since v3:
-----------------
- Fix and simplify error path in ARMv7-M Systick driver (Daniel)
- Improve reset bindings documentation (Philipp)
- Fix trailing lines anf typos in reset driver & doc (Philipp & Chanwoo)
- Fix MODULE_LICENCE in USART driver (Paul)
- Refactor USART baudrate calculation (Peter & Andy)
- Fix error path in USART init (Peter & Russell)
- Fix HW flow control in USART driver (Peter)
- Fix serial port type number to unused one (Peter)
- Applies Chanwoo's Tested-by on the series
Changes since v2:
-----------------
- Remove pinctrl driver from the series.
- Remove reset_controller_of_init(), and reset the timers in the bootloader
- Add HW flow contrl property for serial driver
- Lots of changes in the DTS file, as per Andreas recommendations
- Some Kconfig clean-ups
- Adapt the config to be compatible with Andreas' bootwrapper, except UART port.
- Various fixes in documentation
Changes since v1:
-----------------
- Move bindings documentation in their own patches (Andreas)
- Rename ARM System timer to armv7m-systick (Rob)
- Add clock-frequency property handling in armv7m-systick (Rob)
- Re-factor the reset controllers into a single controller (Philipp)
- Add kerneldoc to reset_controller_of_init (Philipp)
- Add named constants in include/dt-bindings/reset/ (Philipp)
- Make pinctrl driver to depend on ARCH_STM32 or COMPILE_TEST (Geert)
- Introduce CPUV7M_NUM_IRQ config flag to indicate the number of interrupts
supported by the MCU, in order to limit memory waste in vectors' table (Uwe)
Maxime Coquelin (16):
scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP
Kernel
ARM: ARMv7-M: Enlarge vector table up to 256 entries
dt-bindings: Document the ARM System timer bindings
clocksource/drivers: Add ARM System timer driver
dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include
file
dt-bindings: Document the STM32 reset bindings
drivers: reset: Add STM32 reset driver
dt-bindings: Document the STM32 timer bindings
clockevents/drivers: Add STM32 Timer driver
dt-bindings: Document the STM32 USART bindings
serial: stm32-usart: Add STM32 USART Driver
ARM: Add STM32 family machine
ARM: dts: Add ARM System timer as clocksource in armv7m
ARM: dts: Introduce STM32F429 MCU
ARM: configs: Add STM32 defconfig
MAINTAINERS: Add entry for STM32 MCUs
Documentation/arm/stm32/overview.txt | 32 +
Documentation/arm/stm32/stm32f429-overview.txt | 22 +
.../devicetree/bindings/arm/armv7m_systick.txt | 26 +
.../devicetree/bindings/reset/st,stm32-rcc.txt | 50 ++
.../devicetree/bindings/serial/st,stm32-usart.txt | 32 +
.../devicetree/bindings/timer/st,stm32-timer.txt | 22 +
MAINTAINERS | 8 +
arch/arm/Kconfig | 18 +
arch/arm/Makefile | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armv7-m.dtsi | 6 +
arch/arm/boot/dts/stm32f429-disco.dts | 71 ++
arch/arm/boot/dts/stm32f429.dtsi | 227 +++++++
arch/arm/configs/stm32_defconfig | 70 ++
arch/arm/kernel/entry-v7m.S | 13 +-
arch/arm/mach-stm32/Makefile | 1 +
arch/arm/mach-stm32/Makefile.boot | 3 +
arch/arm/mach-stm32/board-dt.c | 19 +
arch/arm/mm/Kconfig | 15 +
drivers/clocksource/Kconfig | 15 +
drivers/clocksource/Makefile | 2 +
drivers/clocksource/armv7m_systick.c | 79 +++
drivers/clocksource/timer-stm32.c | 184 +++++
drivers/reset/Makefile | 1 +
drivers/reset/reset-stm32.c | 124 ++++
drivers/tty/serial/Kconfig | 17 +
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++
include/dt-bindings/mfd/stm32f4-rcc.h | 92 +++
include/uapi/linux/serial_core.h | 3 +
scripts/link-vmlinux.sh | 2 +-
31 files changed, 1891 insertions(+), 5 deletions(-)
create mode 100644 Documentation/arm/stm32/overview.txt
create mode 100644 Documentation/arm/stm32/stm32f429-overview.txt
create mode 100644 Documentation/devicetree/bindings/arm/armv7m_systick.txt
create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
create mode 100644 Documentation/devicetree/bindings/serial/st,stm32-usart.txt
create mode 100644 Documentation/devicetree/bindings/timer/st,stm32-timer.txt
create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
create mode 100644 arch/arm/boot/dts/stm32f429.dtsi
create mode 100644 arch/arm/configs/stm32_defconfig
create mode 100644 arch/arm/mach-stm32/Makefile
create mode 100644 arch/arm/mach-stm32/Makefile.boot
create mode 100644 arch/arm/mach-stm32/board-dt.c
create mode 100644 drivers/clocksource/armv7m_systick.c
create mode 100644 drivers/clocksource/timer-stm32.c
create mode 100644 drivers/reset/reset-stm32.c
create mode 100644 drivers/tty/serial/stm32-usart.c
create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h
--
1.9.1
When Kernel is executed in place from ROM, the symbol addresses can be
lower than the page offset.
Tested-by: Chanwoo Choi <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
scripts/link-vmlinux.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 86a4fe7..b055d9d 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -82,7 +82,7 @@ kallsyms()
kallsymopt="${kallsymopt} --all-symbols"
fi
- if [ -n "${CONFIG_ARM}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
+ if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
fi
--
1.9.1
>From Cortex-M reference manuals, the nvic supports up to 240 interrupts.
So the number of entries in vectors table is up to 256.
This patch adds a new config flag to specify the number of external interrupts.
Some ifdeferies are added in order to respect the natural alignment without
wasting too much space on smaller systems.
Acked-by: Uwe Kleine-König <[email protected]>
Acked-by: Stefan Agner <[email protected]>
Tested-by: Chanwoo Choi <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
arch/arm/kernel/entry-v7m.S | 13 +++++++++----
arch/arm/mm/Kconfig | 15 +++++++++++++++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
index 8944f49..b6c8bb9 100644
--- a/arch/arm/kernel/entry-v7m.S
+++ b/arch/arm/kernel/entry-v7m.S
@@ -117,9 +117,14 @@ ENTRY(__switch_to)
ENDPROC(__switch_to)
.data
- .align 8
+#if CONFIG_CPU_V7M_NUM_IRQ <= 112
+ .align 9
+#else
+ .align 10
+#endif
+
/*
- * Vector table (64 words => 256 bytes natural alignment)
+ * Vector table (Natural alignment need to be ensured)
*/
ENTRY(vector_table)
.long 0 @ 0 - Reset stack pointer
@@ -138,6 +143,6 @@ ENTRY(vector_table)
.long __invalid_entry @ 13 - Reserved
.long __pendsv_entry @ 14 - PendSV
.long __invalid_entry @ 15 - SysTick
- .rept 64 - 16
- .long __irq_entry @ 16..64 - External Interrupts
+ .rept CONFIG_CPU_V7M_NUM_IRQ
+ .long __irq_entry @ External Interrupts
.endr
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index b4f92b9..6173aa3 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -604,6 +604,21 @@ config CPU_USE_DOMAINS
This option enables or disables the use of domain switching
via the set_fs() function.
+config CPU_V7M_NUM_IRQ
+ int "Number of external interrupts connected to the NVIC"
+ depends on CPU_V7M
+ default 90 if ARCH_STM32
+ default 38 if ARCH_EFM32
+ default 240
+ help
+ This option indicates the number of interrupts connected to the NVIC.
+ The value can be larger than the real number of interrupts supported
+ by the system, but must not be lower.
+ The default value is 240, corresponding to the maximum number of
+ interrupts supported by the NVIC on Cortex-M family.
+
+ If unsure, keep default value.
+
#
# CPU supports 36-bit I/O
#
--
1.9.1
This adds documentation of device tree bindings for the
ARM System timer.
Tested-by: Chanwoo Choi <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
.../devicetree/bindings/arm/armv7m_systick.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/armv7m_systick.txt
diff --git a/Documentation/devicetree/bindings/arm/armv7m_systick.txt b/Documentation/devicetree/bindings/arm/armv7m_systick.txt
new file mode 100644
index 0000000..7cf4a24
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armv7m_systick.txt
@@ -0,0 +1,26 @@
+* ARMv7M System Timer
+
+ARMv7-M includes a system timer, known as SysTick. Current driver only
+implements the clocksource feature.
+
+Required properties:
+- compatible : Should be "arm,armv7m-systick"
+- reg : The address range of the timer
+
+Required clocking property, have to be one of:
+- clocks : The input clock of the timer
+- clock-frequency : The rate in HZ in input of the ARM SysTick
+
+Examples:
+
+systick: timer@e000e010 {
+ compatible = "arm,armv7m-systick";
+ reg = <0xe000e010 0x10>;
+ clocks = <&clk_systick>;
+};
+
+systick: timer@e000e010 {
+ compatible = "arm,armv7m-systick";
+ reg = <0xe000e010 0x10>;
+ clock-frequency = <90000000>;
+};
--
1.9.1
This patch adds clocksource support for ARMv7-M's System timer,
also known as SysTick.
Tested-by: Chanwoo Choi <[email protected]>
Acked-by: Daniel Lezcano <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
drivers/clocksource/Kconfig | 7 ++++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
3 files changed, 87 insertions(+)
create mode 100644 drivers/clocksource/armv7m_systick.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 51d7865f..bf9364c 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -139,6 +139,13 @@ config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
help
Use ARM global timer clock source as sched_clock
+config ARMV7M_SYSTICK
+ bool
+ select CLKSRC_OF if OF
+ select CLKSRC_MMIO
+ help
+ This options enables support for the ARMv7M system timer unit
+
config ATMEL_PIT
select CLKSRC_OF if OF
def_bool SOC_AT91SAM9 || SOC_SAMA5
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 5b85f6a..d510c54 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MTK_TIMER) += mtk_timer.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
+obj-$(CONFIG_ARMV7M_SYSTICK) += armv7m_systick.o
obj-$(CONFIG_CLKSRC_METAG_GENERIC) += metag_generic.o
obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST) += dummy_timer.o
obj-$(CONFIG_ARCH_KEYSTONE) += timer-keystone.o
diff --git a/drivers/clocksource/armv7m_systick.c b/drivers/clocksource/armv7m_systick.c
new file mode 100644
index 0000000..addfd2c
--- /dev/null
+++ b/drivers/clocksource/armv7m_systick.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin <[email protected]>
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/kernel.h>
+#include <linux/clocksource.h>
+#include <linux/clockchips.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/clk.h>
+#include <linux/bitops.h>
+
+#define SYST_CSR 0x00
+#define SYST_RVR 0x04
+#define SYST_CVR 0x08
+#define SYST_CALIB 0x0c
+
+#define SYST_CSR_ENABLE BIT(0)
+
+#define SYSTICK_LOAD_RELOAD_MASK 0x00FFFFFF
+
+static void __init system_timer_of_register(struct device_node *np)
+{
+ struct clk *clk = NULL;
+ void __iomem *base;
+ u32 rate;
+ int ret;
+
+ base = of_iomap(np, 0);
+ if (!base) {
+ pr_warn("system-timer: invalid base address\n");
+ return;
+ }
+
+ ret = of_property_read_u32(np, "clock-frequency", &rate);
+ if (ret) {
+ clk = of_clk_get(np, 0);
+ if (IS_ERR(clk))
+ goto out_unmap;
+
+ ret = clk_prepare_enable(clk);
+ if (ret)
+ goto out_clk_put;
+
+ rate = clk_get_rate(clk);
+ if (!rate)
+ goto out_clk_disable;
+ }
+
+ writel_relaxed(SYSTICK_LOAD_RELOAD_MASK, base + SYST_RVR);
+ writel_relaxed(SYST_CSR_ENABLE, base + SYST_CSR);
+
+ ret = clocksource_mmio_init(base + SYST_CVR, "arm_system_timer", rate,
+ 200, 24, clocksource_mmio_readl_down);
+ if (ret) {
+ pr_err("failed to init clocksource (%d)\n", ret);
+ if (clk)
+ goto out_clk_disable;
+ else
+ goto out_unmap;
+ }
+
+ pr_info("ARM System timer initialized as clocksource\n");
+
+ return;
+
+out_clk_disable:
+ clk_disable_unprepare(clk);
+out_clk_put:
+ clk_put(clk);
+out_unmap:
+ iounmap(base);
+ pr_warn("ARM System timer register failed (%d)\n", ret);
+}
+
+CLOCKSOURCE_OF_DECLARE(arm_systick, "arm,armv7m-systick",
+ system_timer_of_register);
--
1.9.1
Ths patch lists STM32F4's RCC numeric constants.
It will be used by clock and reset drivers, and DT bindings.
Signed-off-by: Maxime Coquelin <[email protected]>
---
include/dt-bindings/mfd/stm32f4-rcc.h | 92 +++++++++++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h
diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
new file mode 100644
index 0000000..2f7ab9c
--- /dev/null
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -0,0 +1,92 @@
+/*
+ * This header provides constants for the STM32F4 RCC IP
+ */
+
+#ifndef _DT_BINDINGS_MFD_STM32F4_RCC_H
+#define _DT_BINDINGS_MFD_STM32F4_RCC_H
+
+/* AHB1 */
+#define STM32F4_RCC_AHB1_GPIOA 0
+#define STM32F4_RCC_AHB1_GPIOB 1
+#define STM32F4_RCC_AHB1_GPIOC 2
+#define STM32F4_RCC_AHB1_GPIOD 3
+#define STM32F4_RCC_AHB1_GPIOE 4
+#define STM32F4_RCC_AHB1_GPIOF 5
+#define STM32F4_RCC_AHB1_GPIOG 6
+#define STM32F4_RCC_AHB1_GPIOH 7
+#define STM32F4_RCC_AHB1_GPIOI 8
+#define STM32F4_RCC_AHB1_GPIOJ 9
+#define STM32F4_RCC_AHB1_GPIOK 10
+#define STM32F4_RCC_AHB1_CRC 12
+#define STM32F4_RCC_AHB1_DMA1 21
+#define STM32F4_RCC_AHB1_DMA2 22
+#define STM32F4_RCC_AHB1_DMA2D 23
+#define STM32F4_RCC_AHB1_ETHMAC 25
+#define STM32F4_RCC_AHB1_OTGHS 29
+
+#define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8))
+
+/* AHB2 */
+#define STM32F4_RCC_AHB2_DCMI 0
+#define STM32F4_RCC_AHB2_CRYP 4
+#define STM32F4_RCC_AHB2_HASH 5
+#define STM32F4_RCC_AHB2_RNG 6
+#define STM32F4_RCC_AHB2_OTGFS 7
+
+#define STM32F4_AHB2_RESET(bit) (STM32F4_RCC_AHB2_##bit + (0x14 * 8))
+
+/* AHB3 */
+#define STM32F4_RCC_AHB3_FMC 0
+
+#define STM32F4_AHB3_RESET(bit) (STM32F4_RCC_AHB3_##bit + (0x18 * 8))
+
+/* APB1 */
+#define STM32F4_RCC_APB1_TIM2 0
+#define STM32F4_RCC_APB1_TIM3 1
+#define STM32F4_RCC_APB1_TIM4 2
+#define STM32F4_RCC_APB1_TIM5 3
+#define STM32F4_RCC_APB1_TIM6 4
+#define STM32F4_RCC_APB1_TIM7 5
+#define STM32F4_RCC_APB1_TIM12 6
+#define STM32F4_RCC_APB1_TIM13 7
+#define STM32F4_RCC_APB1_TIM14 8
+#define STM32F4_RCC_APB1_WWDG 11
+#define STM32F4_RCC_APB1_SPI2 14
+#define STM32F4_RCC_APB1_SPI3 15
+#define STM32F4_RCC_APB1_UART2 17
+#define STM32F4_RCC_APB1_UART3 18
+#define STM32F4_RCC_APB1_UART4 19
+#define STM32F4_RCC_APB1_UART5 20
+#define STM32F4_RCC_APB1_I2C1 21
+#define STM32F4_RCC_APB1_I2C2 22
+#define STM32F4_RCC_APB1_I2C3 23
+#define STM32F4_RCC_APB1_CAN1 25
+#define STM32F4_RCC_APB1_CAN2 26
+#define STM32F4_RCC_APB1_PWR 28
+#define STM32F4_RCC_APB1_DAC 29
+#define STM32F4_RCC_APB1_UART7 30
+#define STM32F4_RCC_APB1_UART8 31
+
+#define STM32F4_APB1_RESET(bit) (STM32F4_RCC_APB1_##bit + (0x20 * 8))
+
+/* APB2 */
+#define STM32F4_RCC_APB2_TIM1 0
+#define STM32F4_RCC_APB2_TIM8 1
+#define STM32F4_RCC_APB2_USART1 4
+#define STM32F4_RCC_APB2_USART6 5
+#define STM32F4_RCC_APB2_ADC 8
+#define STM32F4_RCC_APB2_SDIO 11
+#define STM32F4_RCC_APB2_SPI1 12
+#define STM32F4_RCC_APB2_SPI4 13
+#define STM32F4_RCC_APB2_SYSCFG 14
+#define STM32F4_RCC_APB2_TIM9 16
+#define STM32F4_RCC_APB2_TIM10 17
+#define STM32F4_RCC_APB2_TIM11 18
+#define STM32F4_RCC_APB2_SPI5 20
+#define STM32F4_RCC_APB2_SPI6 21
+#define STM32F4_RCC_APB2_SAI1 22
+#define STM32F4_RCC_APB2_LTDC 26
+
+#define STM32F4_APB2_RESET(bit) (STM32F4_RCC_APB2_##bit + (0x24 * 8))
+
+#endif /* _DT_BINDINGS_MFD_STM32F4_RCC_H */
--
1.9.1
This adds documentation of device tree bindings for the
STM32 reset controller.
Signed-off-by: Maxime Coquelin <[email protected]>
---
.../devicetree/bindings/reset/st,stm32-rcc.txt | 50 ++++++++++++++++++++++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
new file mode 100644
index 0000000..333080c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
@@ -0,0 +1,50 @@
+STMicroelectronics STM32 Peripheral Reset Controller
+====================================================
+
+The RCC IP is both a reset and a clock controller. This documentation only
+documents the reset part.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,stm32-rcc"
+- reg: should be register base and length as documented in the
+ datasheet
+- #reset-cells: 1, see below
+
+example:
+
+rcc: reset@40023800 {
+ #reset-cells = <1>;
+ compatible = "st,stm32-rcc";
+ reg = <0x40023800 0x400>;
+};
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the reset device node and an index specifying
+which channel to use.
+The index is the bit number within the RCC registers bank, starting from RCC
+base address.
+It is calculated as: index = register_offset / 4 * 32 + bit_offset.
+Where bit_offset is the bit offset within the register.
+For example, for CRC reset:
+ crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
+
+To simplify the usagen and to share bit definition with the clock driver of
+the RCC IP, macros are available to generate the index in human-readble
+format.
+
+For STM32F4 series, the macro are available here:
+ - include/dt-bindings/mfd/stm32f4-rcc.h
+
+example:
+
+ timer2 {
+ resets = <&rcc STM32F4_APB1_RESET(TIM2)>;
+ };
+
+
--
1.9.1
The STM32 MCUs family IPs can be reset by accessing some registers
from the RCC block.
The list of available reset lines is documented in the DT bindings.
Tested-by: Chanwoo Choi <[email protected]>
Acked-by: Philipp Zabel <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
drivers/reset/Makefile | 1 +
drivers/reset/reset-stm32.c | 124 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 125 insertions(+)
create mode 100644 drivers/reset/reset-stm32.c
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421..aed12d1 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
+obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
diff --git a/drivers/reset/reset-stm32.c b/drivers/reset/reset-stm32.c
new file mode 100644
index 0000000..2c41858
--- /dev/null
+++ b/drivers/reset/reset-stm32.c
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin <[email protected]>
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * Heavily based on sunxi driver from Maxime Ripard.
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+struct stm32_reset_data {
+ spinlock_t lock;
+ void __iomem *membase;
+ struct reset_controller_dev rcdev;
+};
+
+static int stm32_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct stm32_reset_data *data = container_of(rcdev,
+ struct stm32_reset_data,
+ rcdev);
+ int bank = id / BITS_PER_LONG;
+ int offset = id % BITS_PER_LONG;
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ reg = readl_relaxed(data->membase + (bank * 4));
+ writel_relaxed(reg | BIT(offset), data->membase + (bank * 4));
+
+ spin_unlock_irqrestore(&data->lock, flags);
+
+ return 0;
+}
+
+static int stm32_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct stm32_reset_data *data = container_of(rcdev,
+ struct stm32_reset_data,
+ rcdev);
+ int bank = id / BITS_PER_LONG;
+ int offset = id % BITS_PER_LONG;
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ reg = readl_relaxed(data->membase + (bank * 4));
+ writel_relaxed(reg & ~BIT(offset), data->membase + (bank * 4));
+
+ spin_unlock_irqrestore(&data->lock, flags);
+
+ return 0;
+}
+
+static struct reset_control_ops stm32_reset_ops = {
+ .assert = stm32_reset_assert,
+ .deassert = stm32_reset_deassert,
+};
+
+static const struct of_device_id stm32_reset_dt_ids[] = {
+ { .compatible = "st,stm32-rcc", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
+
+static int stm32_reset_probe(struct platform_device *pdev)
+{
+ struct stm32_reset_data *data;
+ struct resource *res;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->membase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->membase))
+ return PTR_ERR(data->membase);
+
+ spin_lock_init(&data->lock);
+
+ data->rcdev.owner = THIS_MODULE;
+ data->rcdev.nr_resets = resource_size(res) * 8;
+ data->rcdev.ops = &stm32_reset_ops;
+ data->rcdev.of_node = pdev->dev.of_node;
+
+ return reset_controller_register(&data->rcdev);
+}
+
+static int stm32_reset_remove(struct platform_device *pdev)
+{
+ struct stm32_reset_data *data = platform_get_drvdata(pdev);
+
+ reset_controller_unregister(&data->rcdev);
+
+ return 0;
+}
+
+static struct platform_driver stm32_reset_driver = {
+ .probe = stm32_reset_probe,
+ .remove = stm32_reset_remove,
+ .driver = {
+ .name = "stm32-rcc-reset",
+ .of_match_table = stm32_reset_dt_ids,
+ },
+};
+module_platform_driver(stm32_reset_driver);
+
+MODULE_AUTHOR("Maxime Coquelin <[email protected]>");
+MODULE_DESCRIPTION("STM32 MCUs Reset Controller Driver");
+MODULE_LICENSE("GPL");
--
1.9.1
This adds documentation of device tree bindings for the
STM32 timer.
Tested-by: Chanwoo Choi <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
.../devicetree/bindings/timer/st,stm32-timer.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/st,stm32-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/st,stm32-timer.txt b/Documentation/devicetree/bindings/timer/st,stm32-timer.txt
new file mode 100644
index 0000000..8ef28e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/st,stm32-timer.txt
@@ -0,0 +1,22 @@
+. STMicroelectronics STM32 timer
+
+The STM32 MCUs family has several general-purpose 16 and 32 bits timers.
+
+Required properties:
+- compatible : Should be "st,stm32-timer"
+- reg : Address and length of the register set
+- clocks : Reference on the timer input clock
+- interrupts : Reference to the timer interrupt
+
+Optional properties:
+- resets: Reference to a reset controller asserting the timer
+
+Example:
+
+timer5: timer@40000c00 {
+ compatible = "st,stm32-timer";
+ reg = <0x40000c00 0x400>;
+ interrupts = <50>;
+ resets = <&rrc 259>;
+ clocks = <&clk_pmtr1>;
+};
--
1.9.1
STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
The drivers detects whether the time is 16 or 32 bits, and applies a
1024 prescaler value if it is 16 bits.
Reviewed-by: Linus Walleij <[email protected]>
Tested-by: Chanwoo Choi <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
drivers/clocksource/Kconfig | 8 ++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-stm32.c | 184 ++++++++++++++++++++++++++++++++++++++
3 files changed, 193 insertions(+)
create mode 100644 drivers/clocksource/timer-stm32.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index bf9364c..2443520 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -106,6 +106,14 @@ config CLKSRC_EFM32
Support to use the timers of EFM32 SoCs as clock source and clock
event device.
+config CLKSRC_STM32
+ bool "Clocksource for STM32 SoCs" if !ARCH_STM32
+ depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
+ select CLKSRC_MMIO
+ default ARCH_STM32
+ help
+ Support to use the timers of STM32 SoCs as clock event device.
+
config ARM_ARCH_TIMER
bool
select CLKSRC_OF if OF
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index d510c54..888a7df 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_ARCH_NSPIRE) += zevio-timer.o
obj-$(CONFIG_ARCH_BCM_MOBILE) += bcm_kona_timer.o
obj-$(CONFIG_CADENCE_TTC_TIMER) += cadence_ttc_timer.o
obj-$(CONFIG_CLKSRC_EFM32) += time-efm32.o
+obj-$(CONFIG_CLKSRC_STM32) += timer-stm32.o
obj-$(CONFIG_CLKSRC_EXYNOS_MCT) += exynos_mct.o
obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
obj-$(CONFIG_FSL_FTM_TIMER) += fsl_ftm_timer.o
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
new file mode 100644
index 0000000..fad2e2e
--- /dev/null
+++ b/drivers/clocksource/timer-stm32.c
@@ -0,0 +1,184 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin <[email protected]>
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * Inspired by time-efm32.c from Uwe Kleine-Koenig
+ */
+
+#include <linux/kernel.h>
+#include <linux/clocksource.h>
+#include <linux/clockchips.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/clk.h>
+#include <linux/reset.h>
+
+#define TIM_CR1 0x00
+#define TIM_DIER 0x0c
+#define TIM_SR 0x10
+#define TIM_EGR 0x14
+#define TIM_PSC 0x28
+#define TIM_ARR 0x2c
+
+#define TIM_CR1_CEN BIT(0)
+#define TIM_CR1_OPM BIT(3)
+#define TIM_CR1_ARPE BIT(7)
+
+#define TIM_DIER_UIE BIT(0)
+
+#define TIM_SR_UIF BIT(0)
+
+#define TIM_EGR_UG BIT(0)
+
+struct stm32_clock_event_ddata {
+ struct clock_event_device evtdev;
+ unsigned periodic_top;
+ void __iomem *base;
+};
+
+static void stm32_clock_event_set_mode(enum clock_event_mode mode,
+ struct clock_event_device *evtdev)
+{
+ struct stm32_clock_event_ddata *data =
+ container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
+ void *base = data->base;
+
+ switch (mode) {
+ case CLOCK_EVT_MODE_PERIODIC:
+ writel_relaxed(data->periodic_top, base + TIM_ARR);
+ writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, base + TIM_CR1);
+ break;
+
+ case CLOCK_EVT_MODE_ONESHOT:
+ default:
+ writel_relaxed(0, base + TIM_CR1);
+ break;
+ }
+}
+
+static int stm32_clock_event_set_next_event(unsigned long evt,
+ struct clock_event_device *evtdev)
+{
+ struct stm32_clock_event_ddata *data =
+ container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
+
+ writel_relaxed(evt, data->base + TIM_ARR);
+ writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
+ data->base + TIM_CR1);
+
+ return 0;
+}
+
+static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
+{
+ struct stm32_clock_event_ddata *data = dev_id;
+
+ writel_relaxed(0, data->base + TIM_SR);
+
+ data->evtdev.event_handler(&data->evtdev);
+
+ return IRQ_HANDLED;
+}
+
+static struct stm32_clock_event_ddata clock_event_ddata = {
+ .evtdev = {
+ .name = "stm32 clockevent",
+ .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
+ .set_mode = stm32_clock_event_set_mode,
+ .set_next_event = stm32_clock_event_set_next_event,
+ .rating = 200,
+ },
+};
+
+static void __init stm32_clockevent_init(struct device_node *np)
+{
+ struct stm32_clock_event_ddata *data = &clock_event_ddata;
+ struct clk *clk;
+ struct reset_control *rstc;
+ unsigned long rate, max_delta;
+ int irq, ret, bits, prescaler = 1;
+
+ clk = of_clk_get(np, 0);
+ if (IS_ERR(clk)) {
+ ret = PTR_ERR(clk);
+ pr_err("failed to get clock for clockevent (%d)\n", ret);
+ goto err_clk_get;
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ pr_err("failed to enable timer clock for clockevent (%d)\n",
+ ret);
+ goto err_clk_enable;
+ }
+
+ rate = clk_get_rate(clk);
+
+ rstc = of_reset_control_get(np, NULL);
+ if (!IS_ERR(rstc)) {
+ reset_control_assert(rstc);
+ reset_control_deassert(rstc);
+ }
+
+ data->base = of_iomap(np, 0);
+ if (!data->base) {
+ pr_err("failed to map registers for clockevent\n");
+ goto err_iomap;
+ }
+
+ irq = irq_of_parse_and_map(np, 0);
+ if (!irq) {
+ pr_err("%s: failed to get irq.\n", np->full_name);
+ goto err_get_irq;
+ }
+
+ /* Detect whether the timer is 16 or 32 bits */
+ writel_relaxed(~0UL, data->base + TIM_ARR);
+ max_delta = readl_relaxed(data->base + TIM_ARR);
+ if (max_delta == ~0UL) {
+ prescaler = 1;
+ bits = 32;
+ } else {
+ prescaler = 1024;
+ bits = 16;
+ }
+ writel_relaxed(0, data->base + TIM_ARR);
+
+ writel_relaxed(prescaler - 1, data->base + TIM_PSC);
+ writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
+ writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
+ writel_relaxed(0, data->base + TIM_SR);
+
+ data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
+
+ clockevents_config_and_register(&data->evtdev,
+ DIV_ROUND_CLOSEST(rate, prescaler),
+ 0x1, max_delta);
+
+ ret = request_irq(irq, stm32_clock_event_handler, IRQF_TIMER,
+ "stm32 clockevent", data);
+ if (ret) {
+ pr_err("%s: failed to request irq.\n", np->full_name);
+ goto err_get_irq;
+ }
+
+ pr_info("%s: STM32 clockevent driver initialized (%d bits)\n",
+ np->full_name, bits);
+
+ return;
+
+err_get_irq:
+ iounmap(data->base);
+err_iomap:
+ clk_disable_unprepare(clk);
+err_clk_enable:
+ clk_put(clk);
+err_clk_get:
+ return;
+}
+
+CLOCKSOURCE_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
--
1.9.1
This adds documentation of device tree bindings for the
STM32 USART
Tested-by: Chanwoo Choi <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
.../devicetree/bindings/serial/st,stm32-usart.txt | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/st,stm32-usart.txt
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
new file mode 100644
index 0000000..8480a76
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
@@ -0,0 +1,32 @@
+* STMicroelectronics STM32 USART
+
+Required properties:
+- compatible: Can be either "st,stm32-usart" or "st,stm32-uart" depending on
+whether the device supports synchronous mode.
+- reg: The address and length of the peripheral registers space
+- interrupts: The interrupt line of the USART instance
+- clocks: The input clock of the USART instance
+
+Optional properties:
+- pinctrl: The reference on the pins configuration
+- auto-flow-control: bool flag to enable hardware flow control.
+
+Examples:
+usart4: serial@40004c00 {
+ compatible = "st,stm32-uart";
+ reg = <0x40004c00 0x400>;
+ interrupts = <52>;
+ clocks = <&clk_pclk1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart4>;
+};
+
+usart2: serial@40004400 {
+ compatible = "st,stm32-usart", "st,stm32-uart";
+ reg = <0x40004400 0x400>;
+ interrupts = <38>;
+ clocks = <&clk_pclk1>;
+ auto-flow-control;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rtscts>;
+};
--
1.9.1
This drivers adds support to the STM32 USART controller, which is a
standard serial driver.
Tested-by: Chanwoo Choi <[email protected]>
Reviewed-by: Peter Hurley <[email protected]>
Reviewed-by: Vladimir Zapolskiy <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
drivers/tty/serial/Kconfig | 17 +
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 +
4 files changed, 760 insertions(+)
create mode 100644 drivers/tty/serial/stm32-usart.c
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index f8120c1..7eb62f1 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1589,6 +1589,23 @@ config SERIAL_SPRD_CONSOLE
with "earlycon" on the kernel command line. The console is
enabled when early_param is processed.
+config SERIAL_STM32
+ tristate "STMicroelectronics STM32 serial port support"
+ select SERIAL_CORE
+ depends on ARM || COMPILE_TEST
+ help
+ This driver is for the on-chip Serial Controller on
+ STMicroelectronics STM32 MCUs.
+ USART supports Rx & Tx functionality.
+ It support all industry standard baud rates.
+
+ If unsure, say N.
+
+config SERIAL_STM32_CONSOLE
+ bool "Support for console on STM32"
+ depends on SERIAL_STM32=y
+ select SERIAL_CORE_CONSOLE
+
endmenu
config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index c3ac3d9..61979ce 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART) += fsl_lpuart.o
obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR) += digicolor-usart.o
obj-$(CONFIG_SERIAL_MEN_Z135) += men_z135_uart.o
obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
+obj-$(CONFIG_SERIAL_STM32) += stm32-usart.o
# GPIOLIB helpers for modem control lines
obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
new file mode 100644
index 0000000..4a6eab6
--- /dev/null
+++ b/drivers/tty/serial/stm32-usart.c
@@ -0,0 +1,739 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin <[email protected]>
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * Inspired by st-asc.c from STMicroelectronics (c)
+ */
+
+#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#include <linux/module.h>
+#include <linux/serial.h>
+#include <linux/console.h>
+#include <linux/sysrq.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+#include <linux/delay.h>
+#include <linux/spinlock.h>
+#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/serial_core.h>
+#include <linux/clk.h>
+
+#define DRIVER_NAME "stm32-usart"
+
+/* Register offsets */
+#define USART_SR 0x00
+#define USART_DR 0x04
+#define USART_BRR 0x08
+#define USART_CR1 0x0c
+#define USART_CR2 0x10
+#define USART_CR3 0x14
+#define USART_GTPR 0x18
+
+/* USART_SR */
+#define USART_SR_PE BIT(0)
+#define USART_SR_FE BIT(1)
+#define USART_SR_NF BIT(2)
+#define USART_SR_ORE BIT(3)
+#define USART_SR_IDLE BIT(4)
+#define USART_SR_RXNE BIT(5)
+#define USART_SR_TC BIT(6)
+#define USART_SR_TXE BIT(7)
+#define USART_SR_LBD BIT(8)
+#define USART_SR_CTS BIT(9)
+#define USART_SR_ERR_MASK (USART_SR_LBD | USART_SR_ORE | \
+ USART_SR_FE | USART_SR_PE)
+/* Dummy bits */
+#define USART_SR_DUMMY_RX BIT(16)
+
+/* USART_DR */
+#define USART_DR_MASK GENMASK(8, 0)
+
+/* USART_BRR */
+#define USART_BRR_DIV_F_MASK GENMASK(3, 0)
+#define USART_BRR_DIV_M_MASK GENMASK(15, 4)
+#define USART_BRR_DIV_M_SHIFT 4
+
+/* USART_CR1 */
+#define USART_CR1_SBK BIT(0)
+#define USART_CR1_RWU BIT(1)
+#define USART_CR1_RE BIT(2)
+#define USART_CR1_TE BIT(3)
+#define USART_CR1_IDLEIE BIT(4)
+#define USART_CR1_RXNEIE BIT(5)
+#define USART_CR1_TCIE BIT(6)
+#define USART_CR1_TXEIE BIT(7)
+#define USART_CR1_PEIE BIT(8)
+#define USART_CR1_PS BIT(9)
+#define USART_CR1_PCE BIT(10)
+#define USART_CR1_WAKE BIT(11)
+#define USART_CR1_M BIT(12)
+#define USART_CR1_UE BIT(13)
+#define USART_CR1_OVER8 BIT(15)
+#define USART_CR1_IE_MASK GENMASK(8, 4)
+
+/* USART_CR2 */
+#define USART_CR2_ADD_MASK GENMASK(3, 0)
+#define USART_CR2_LBDL BIT(5)
+#define USART_CR2_LBDIE BIT(6)
+#define USART_CR2_LBCL BIT(8)
+#define USART_CR2_CPHA BIT(9)
+#define USART_CR2_CPOL BIT(10)
+#define USART_CR2_CLKEN BIT(11)
+#define USART_CR2_STOP_2B BIT(13)
+#define USART_CR2_STOP_MASK GENMASK(13, 12)
+#define USART_CR2_LINEN BIT(14)
+
+/* USART_CR3 */
+#define USART_CR3_EIE BIT(0)
+#define USART_CR3_IREN BIT(1)
+#define USART_CR3_IRLP BIT(2)
+#define USART_CR3_HDSEL BIT(3)
+#define USART_CR3_NACK BIT(4)
+#define USART_CR3_SCEN BIT(5)
+#define USART_CR3_DMAR BIT(6)
+#define USART_CR3_DMAT BIT(7)
+#define USART_CR3_RTSE BIT(8)
+#define USART_CR3_CTSE BIT(9)
+#define USART_CR3_CTSIE BIT(10)
+#define USART_CR3_ONEBIT BIT(11)
+
+/* USART_GTPR */
+#define USART_GTPR_PSC_MASK GENMASK(7, 0)
+#define USART_GTPR_GT_MASK GENMASK(15, 8)
+
+#define DRIVER_NAME "stm32-usart"
+#define STM32_SERIAL_NAME "ttyS"
+#define STM32_MAX_PORTS 6
+
+struct stm32_port {
+ struct uart_port port;
+ struct clk *clk;
+ bool hw_flow_control;
+};
+
+static struct stm32_port stm32_ports[STM32_MAX_PORTS];
+static struct uart_driver stm32_usart_driver;
+
+static void stm32_stop_tx(struct uart_port *port);
+
+static inline struct stm32_port *to_stm32_port(struct uart_port *port)
+{
+ return container_of(port, struct stm32_port, port);
+}
+
+static void stm32_set_bits(struct uart_port *port, u32 reg, u32 bits)
+{
+ u32 val;
+
+ val = readl_relaxed(port->membase + reg);
+ val |= bits;
+ writel_relaxed(val, port->membase + reg);
+}
+
+static void stm32_clr_bits(struct uart_port *port, u32 reg, u32 bits)
+{
+ u32 val;
+
+ val = readl_relaxed(port->membase + reg);
+ val &= ~bits;
+ writel_relaxed(val, port->membase + reg);
+}
+
+static void stm32_receive_chars(struct uart_port *port)
+{
+ struct tty_port *tport = &port->state->port;
+ unsigned long c;
+ u32 sr;
+ char flag;
+
+ if (port->irq_wake)
+ pm_wakeup_event(tport->tty->dev, 0);
+
+ while ((sr = readl_relaxed(port->membase + USART_SR)) & USART_SR_RXNE) {
+ sr |= USART_SR_DUMMY_RX;
+ c = readl_relaxed(port->membase + USART_DR);
+ flag = TTY_NORMAL;
+ port->icount.rx++;
+
+ if (sr & USART_SR_ERR_MASK) {
+ if (sr & USART_SR_LBD) {
+ port->icount.brk++;
+ if (uart_handle_break(port))
+ continue;
+ } else if (sr & USART_SR_ORE) {
+ port->icount.overrun++;
+ } else if (sr & USART_SR_PE) {
+ port->icount.parity++;
+ } else if (sr & USART_SR_FE) {
+ port->icount.frame++;
+ }
+
+ sr &= port->read_status_mask;
+
+ if (sr & USART_SR_LBD)
+ flag = TTY_BREAK;
+ else if (sr & USART_SR_PE)
+ flag = TTY_PARITY;
+ else if (sr & USART_SR_FE)
+ flag = TTY_FRAME;
+ }
+
+ if (uart_handle_sysrq_char(port, c))
+ continue;
+ uart_insert_char(port, sr, USART_SR_ORE, c, flag);
+ }
+
+ spin_unlock(&port->lock);
+ tty_flip_buffer_push(tport);
+ spin_lock(&port->lock);
+}
+
+static void stm32_transmit_chars(struct uart_port *port)
+{
+ struct circ_buf *xmit = &port->state->xmit;
+
+ if (port->x_char) {
+ writel_relaxed(port->x_char, port->membase + USART_DR);
+ port->x_char = 0;
+ port->icount.tx++;
+ return;
+ }
+
+ if (uart_tx_stopped(port)) {
+ stm32_stop_tx(port);
+ return;
+ }
+
+ if (uart_circ_empty(xmit)) {
+ stm32_stop_tx(port);
+ return;
+ }
+
+ writel_relaxed(xmit->buf[xmit->tail], port->membase + USART_DR);
+ xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+ port->icount.tx++;
+
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ uart_write_wakeup(port);
+
+ if (uart_circ_empty(xmit))
+ stm32_stop_tx(port);
+}
+
+static irqreturn_t stm32_interrupt(int irq, void *ptr)
+{
+ struct uart_port *port = ptr;
+ u32 sr;
+
+ spin_lock(&port->lock);
+
+ sr = readl_relaxed(port->membase + USART_SR);
+
+ if (sr & USART_SR_RXNE)
+ stm32_receive_chars(port);
+
+ if (sr & USART_SR_TXE)
+ stm32_transmit_chars(port);
+
+ spin_unlock(&port->lock);
+
+ return IRQ_HANDLED;
+}
+
+static unsigned int stm32_tx_empty(struct uart_port *port)
+{
+ return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
+}
+
+static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+ if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
+ stm32_set_bits(port, USART_CR3, USART_CR3_RTSE);
+ else
+ stm32_clr_bits(port, USART_CR3, USART_CR3_RTSE);
+}
+
+static unsigned int stm32_get_mctrl(struct uart_port *port)
+{
+ /* This routine is used to get signals of: DCD, DSR, RI, and CTS */
+ return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+}
+
+/* Transmit stop */
+static void stm32_stop_tx(struct uart_port *port)
+{
+ stm32_clr_bits(port, USART_CR1, USART_CR1_TXEIE);
+}
+
+/* There are probably characters waiting to be transmitted. */
+static void stm32_start_tx(struct uart_port *port)
+{
+ struct circ_buf *xmit = &port->state->xmit;
+
+ if (uart_circ_empty(xmit))
+ return;
+
+ stm32_set_bits(port, USART_CR1, USART_CR1_TXEIE | USART_CR1_TE);
+}
+
+/* Throttle the remote when input buffer is about to overflow. */
+static void stm32_throttle(struct uart_port *port)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->lock, flags);
+ stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/* Unthrottle the remote, the input buffer can now accept data. */
+static void stm32_unthrottle(struct uart_port *port)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->lock, flags);
+ stm32_set_bits(port, USART_CR1, USART_CR1_RXNEIE);
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/* Receive stop */
+static void stm32_stop_rx(struct uart_port *port)
+{
+ stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
+}
+
+/* Handle breaks - ignored by us */
+static void stm32_break_ctl(struct uart_port *port, int break_state)
+{
+}
+
+static int stm32_startup(struct uart_port *port)
+{
+ const char *name = to_platform_device(port->dev)->name;
+ u32 val;
+ int ret;
+
+ ret = request_irq(port->irq, stm32_interrupt, IRQF_NO_SUSPEND,
+ name, port);
+ if (ret)
+ return ret;
+
+ val = USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
+ stm32_set_bits(port, USART_CR1, val);
+
+ return 0;
+}
+
+static void stm32_shutdown(struct uart_port *port)
+{
+ u32 val;
+
+ val = USART_CR1_TXEIE | USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
+ stm32_set_bits(port, USART_CR1, val);
+
+ free_irq(port->irq, port);
+}
+
+static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
+ struct ktermios *old)
+{
+ struct stm32_port *stm32_port = to_stm32_port(port);
+ unsigned int baud;
+ u32 usartdiv, mantissa, fraction, oversampling;
+ tcflag_t cflag = termios->c_cflag;
+ u32 cr1, cr2, cr3;
+ unsigned long flags;
+
+ if (!stm32_port->hw_flow_control)
+ cflag &= ~CRTSCTS;
+
+ baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 8);
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ /* Stop serial port and reset value */
+ writel_relaxed(0, port->membase + USART_CR1);
+
+ cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
+ cr2 = 0;
+ cr3 = 0;
+
+ if (cflag & CSTOPB)
+ cr2 |= USART_CR2_STOP_2B;
+
+ if (cflag & PARENB) {
+ cr1 |= USART_CR1_PCE;
+ if ((cflag & CSIZE) == CS8)
+ cr1 |= USART_CR1_M;
+ }
+
+ if (cflag & PARODD)
+ cr1 |= USART_CR1_PS;
+
+ port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS);
+ if (cflag & CRTSCTS) {
+ port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
+ cr3 |= USART_CR3_CTSE;
+ }
+
+ usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
+
+ /*
+ * The USART supports 16 or 8 times oversampling.
+ * By default we prefer 16 times oversampling, so that the receiver
+ * has a better tolerance to clock deviations.
+ * 8 times oversampling is only used to achieve higher speeds.
+ */
+ if (usartdiv < 16) {
+ oversampling = 8;
+ stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
+ } else {
+ oversampling = 16;
+ stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
+ }
+
+ mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
+ fraction = usartdiv % oversampling;
+ writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
+
+ uart_update_timeout(port, cflag, baud);
+
+ port->read_status_mask = USART_SR_ORE;
+ if (termios->c_iflag & INPCK)
+ port->read_status_mask |= USART_SR_PE | USART_SR_FE;
+ if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
+ port->read_status_mask |= USART_SR_LBD;
+
+ /* Characters to ignore */
+ port->ignore_status_mask = 0;
+ if (termios->c_iflag & IGNPAR)
+ port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
+ if (termios->c_iflag & IGNBRK) {
+ port->ignore_status_mask |= USART_SR_LBD;
+ /*
+ * If we're ignoring parity and break indicators,
+ * ignore overruns too (for real raw support).
+ */
+ if (termios->c_iflag & IGNPAR)
+ port->ignore_status_mask |= USART_SR_ORE;
+ }
+
+ /* Ignore all characters if CREAD is not set */
+ if ((termios->c_cflag & CREAD) == 0)
+ port->ignore_status_mask |= USART_SR_DUMMY_RX;
+
+ writel_relaxed(cr3, port->membase + USART_CR3);
+ writel_relaxed(cr2, port->membase + USART_CR2);
+ writel_relaxed(cr1, port->membase + USART_CR1);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *stm32_type(struct uart_port *port)
+{
+ return (port->type == PORT_STM32) ? DRIVER_NAME : NULL;
+}
+
+static void stm32_release_port(struct uart_port *port)
+{
+}
+
+static int stm32_request_port(struct uart_port *port)
+{
+ return 0;
+}
+
+static void stm32_config_port(struct uart_port *port, int flags)
+{
+ if (flags & UART_CONFIG_TYPE)
+ port->type = PORT_STM32;
+}
+
+static int
+stm32_verify_port(struct uart_port *port, struct serial_struct *ser)
+{
+ /* No user changeable parameters */
+ return -EINVAL;
+}
+
+static void stm32_pm(struct uart_port *port, unsigned int state,
+ unsigned int oldstate)
+{
+ struct stm32_port *stm32port = container_of(port,
+ struct stm32_port, port);
+ unsigned long flags = 0;
+
+ switch (state) {
+ case UART_PM_STATE_ON:
+ clk_prepare_enable(stm32port->clk);
+ break;
+ case UART_PM_STATE_OFF:
+ spin_lock_irqsave(&port->lock, flags);
+ stm32_clr_bits(port, USART_CR1, USART_CR1_UE);
+ spin_unlock_irqrestore(&port->lock, flags);
+ clk_disable_unprepare(stm32port->clk);
+ break;
+ }
+}
+
+static const struct uart_ops stm32_uart_ops = {
+ .tx_empty = stm32_tx_empty,
+ .set_mctrl = stm32_set_mctrl,
+ .get_mctrl = stm32_get_mctrl,
+ .stop_tx = stm32_stop_tx,
+ .start_tx = stm32_start_tx,
+ .throttle = stm32_throttle,
+ .unthrottle = stm32_unthrottle,
+ .stop_rx = stm32_stop_rx,
+ .break_ctl = stm32_break_ctl,
+ .startup = stm32_startup,
+ .shutdown = stm32_shutdown,
+ .set_termios = stm32_set_termios,
+ .pm = stm32_pm,
+ .type = stm32_type,
+ .release_port = stm32_release_port,
+ .request_port = stm32_request_port,
+ .config_port = stm32_config_port,
+ .verify_port = stm32_verify_port,
+};
+
+static int stm32_init_port(struct stm32_port *stm32port,
+ struct platform_device *pdev)
+{
+ struct uart_port *port = &stm32port->port;
+ struct resource *res;
+ int ret;
+
+ port->iotype = UPIO_MEM;
+ port->flags = UPF_BOOT_AUTOCONF;
+ port->ops = &stm32_uart_ops;
+ port->dev = &pdev->dev;
+ port->irq = platform_get_irq(pdev, 0);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ port->membase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(port->membase))
+ return PTR_ERR(port->membase);
+ port->mapbase = res->start;
+
+ spin_lock_init(&port->lock);
+
+ stm32port->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(stm32port->clk))
+ return PTR_ERR(stm32port->clk);
+
+ /* Ensure that clk rate is correct by enabling the clk */
+ ret = clk_prepare_enable(stm32port->clk);
+ if (ret)
+ return ret;
+
+ stm32port->port.uartclk = clk_get_rate(stm32port->clk);
+ if (!stm32port->port.uartclk)
+ ret = -EINVAL;
+
+ clk_disable_unprepare(stm32port->clk);
+
+ return ret;
+}
+
+static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ int id;
+
+ if (!np)
+ return NULL;
+
+ id = of_alias_get_id(np, "serial");
+ if (id < 0)
+ id = 0;
+
+ if (WARN_ON(id >= STM32_MAX_PORTS))
+ return NULL;
+
+ stm32_ports[id].hw_flow_control = of_property_read_bool(np,
+ "auto-flow-control");
+ stm32_ports[id].port.line = id;
+ return &stm32_ports[id];
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id stm32_match[] = {
+ { .compatible = "st,stm32-usart", },
+ { .compatible = "st,stm32-uart", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, stm32_match);
+#endif
+
+static int stm32_serial_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct stm32_port *stm32port;
+
+ stm32port = stm32_of_get_stm32_port(pdev);
+ if (!stm32port)
+ return -ENODEV;
+
+ ret = stm32_init_port(stm32port, pdev);
+ if (ret)
+ return ret;
+
+ ret = uart_add_one_port(&stm32_usart_driver, &stm32port->port);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, &stm32port->port);
+
+ return 0;
+}
+
+static int stm32_serial_remove(struct platform_device *pdev)
+{
+ struct uart_port *port = platform_get_drvdata(pdev);
+
+ return uart_remove_one_port(&stm32_usart_driver, port);
+}
+
+
+#ifdef CONFIG_SERIAL_STM32_CONSOLE
+static void stm32_console_putchar(struct uart_port *port, int ch)
+{
+ while (!(readl_relaxed(port->membase + USART_SR) & USART_SR_TXE))
+ cpu_relax();
+
+ writel_relaxed(ch, port->membase + USART_DR);
+}
+
+static void stm32_console_write(struct console *co, const char *s, unsigned cnt)
+{
+ struct uart_port *port = &stm32_ports[co->index].port;
+ unsigned long flags;
+ u32 old_cr1, new_cr1;
+ int locked = 1;
+
+ local_irq_save(flags);
+ if (port->sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&port->lock);
+ else
+ spin_lock(&port->lock);
+
+ /* Save and disable interrupts */
+ old_cr1 = readl_relaxed(port->membase + USART_CR1);
+ new_cr1 = old_cr1 & ~USART_CR1_IE_MASK;
+ writel_relaxed(new_cr1, port->membase + USART_CR1);
+
+ uart_console_write(port, s, cnt, stm32_console_putchar);
+
+ /* Restore interrupt state */
+ writel_relaxed(old_cr1, port->membase + USART_CR1);
+
+ if (locked)
+ spin_unlock(&port->lock);
+ local_irq_restore(flags);
+}
+
+static int stm32_console_setup(struct console *co, char *options)
+{
+ struct stm32_port *stm32port;
+ int baud = 9600;
+ int bits = 8;
+ int parity = 'n';
+ int flow = 'n';
+
+ if (co->index >= STM32_MAX_PORTS)
+ return -ENODEV;
+
+ stm32port = &stm32_ports[co->index];
+
+ /*
+ * This driver does not support early console initialization
+ * (use ARM early printk support instead), so we only expect
+ * this to be called during the uart port registration when the
+ * driver gets probed and the port should be mapped at that point.
+ */
+ if (stm32port->port.mapbase == 0 || stm32port->port.membase == NULL)
+ return -ENXIO;
+
+ if (options)
+ uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+ return uart_set_options(&stm32port->port, co, baud, parity, bits, flow);
+}
+
+static struct console stm32_console = {
+ .name = STM32_SERIAL_NAME,
+ .device = uart_console_device,
+ .write = stm32_console_write,
+ .setup = stm32_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ .data = &stm32_usart_driver,
+};
+
+#define STM32_SERIAL_CONSOLE (&stm32_console)
+
+#else
+#define STM32_SERIAL_CONSOLE NULL
+#endif /* CONFIG_SERIAL_STM32_CONSOLE */
+
+static struct uart_driver stm32_usart_driver = {
+ .driver_name = DRIVER_NAME,
+ .dev_name = STM32_SERIAL_NAME,
+ .major = 0,
+ .minor = 0,
+ .nr = STM32_MAX_PORTS,
+ .cons = STM32_SERIAL_CONSOLE,
+};
+
+static struct platform_driver stm32_serial_driver = {
+ .probe = stm32_serial_probe,
+ .remove = stm32_serial_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(stm32_match),
+ },
+};
+
+static int __init usart_init(void)
+{
+ static char banner[] __initdata = "STM32 USART driver initialized";
+ int ret;
+
+ pr_info("%s\n", banner);
+
+ ret = uart_register_driver(&stm32_usart_driver);
+ if (ret)
+ return ret;
+
+ ret = platform_driver_register(&stm32_serial_driver);
+ if (ret)
+ uart_unregister_driver(&stm32_usart_driver);
+
+ return ret;
+}
+
+static void __exit usart_exit(void)
+{
+ platform_driver_unregister(&stm32_serial_driver);
+ uart_unregister_driver(&stm32_usart_driver);
+}
+
+module_init(usart_init);
+module_exit(usart_exit);
+
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_DESCRIPTION("STMicroelectronics STM32 serial port driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index b212281..93ba148 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -258,4 +258,7 @@
/* Cris v10 / v32 SoC */
#define PORT_CRIS 112
+/* STM32 USART */
+#define PORT_STM32 113
+
#endif /* _UAPILINUX_SERIAL_CORE_H */
--
1.9.1
STMicrolectronics's STM32 series is a family of Cortex-M
microcontrollers. It is used in various applications, and
proposes a wide range of peripherals.
Tested-by: Chanwoo Choi <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
Documentation/arm/stm32/overview.txt | 32 ++++++++++++++++++++++++++
Documentation/arm/stm32/stm32f429-overview.txt | 22 ++++++++++++++++++
arch/arm/Kconfig | 18 +++++++++++++++
arch/arm/Makefile | 1 +
arch/arm/mach-stm32/Makefile | 1 +
arch/arm/mach-stm32/Makefile.boot | 3 +++
arch/arm/mach-stm32/board-dt.c | 19 +++++++++++++++
7 files changed, 96 insertions(+)
create mode 100644 Documentation/arm/stm32/overview.txt
create mode 100644 Documentation/arm/stm32/stm32f429-overview.txt
create mode 100644 arch/arm/mach-stm32/Makefile
create mode 100644 arch/arm/mach-stm32/Makefile.boot
create mode 100644 arch/arm/mach-stm32/board-dt.c
diff --git a/Documentation/arm/stm32/overview.txt b/Documentation/arm/stm32/overview.txt
new file mode 100644
index 0000000..09aed55
--- /dev/null
+++ b/Documentation/arm/stm32/overview.txt
@@ -0,0 +1,32 @@
+ STM32 ARM Linux Overview
+ ========================
+
+Introduction
+------------
+
+ The STMicroelectronics family of Cortex-M based MCUs are supported by the
+ 'STM32' platform of ARM Linux. Currently only the STM32F429 is supported.
+
+
+Configuration
+-------------
+
+ A generic configuration is provided for STM32 family, and can be used as the
+ default by
+ make stm32_defconfig
+
+Layout
+------
+
+ All the files for multiple machine families are located in the platform code
+ contained in arch/arm/mach-stm32
+
+ There is a generic board board-dt.c in the mach folder which support
+ Flattened Device Tree, which means, it works with any compatible board with
+ Device Trees.
+
+
+Document Author
+---------------
+
+ Maxime Coquelin <[email protected]>
diff --git a/Documentation/arm/stm32/stm32f429-overview.txt b/Documentation/arm/stm32/stm32f429-overview.txt
new file mode 100644
index 0000000..5206822
--- /dev/null
+++ b/Documentation/arm/stm32/stm32f429-overview.txt
@@ -0,0 +1,22 @@
+ STM32F429 Overview
+ ==================
+
+ Introduction
+ ------------
+ The STM32F429 is a Cortex-M4 MCU aimed at various applications.
+ It features:
+ - ARM Cortex-M4 up to 180MHz with FPU
+ - 2MB internal Flash Memory
+ - External memory support through FMC controller (PSRAM, SDRAM, NOR, NAND)
+ - I2C, SPI, SAI, CAN, USB OTG, Ethernet controllers
+ - LCD controller & Camera interface
+ - Cryptographic processor
+
+ Resources
+ ---------
+ Datasheet and reference manual are publicly available on ST website:
+ - http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577/LN1806?ecmp=stm32f429-439_pron_pr-ces2014_nov2013
+
+ Document Author
+ ---------------
+ Maxime Coquelin <[email protected]>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 45df48b..21fe5c8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -757,6 +757,24 @@ config ARCH_OMAP1
help
Support for older TI OMAP1 (omap7xx, omap15xx or omap16xx)
+config ARCH_STM32
+ bool "STMicrolectronics STM32"
+ depends on !MMU
+ select ARCH_HAS_RESET_CONTROLLER
+ select ARM_NVIC
+ select ARMV7M_SYSTICK
+ select AUTO_ZRELADDR
+ select CLKSRC_OF
+ select COMMON_CLK
+ select CPU_V7M
+ select GENERIC_CLOCKEVENTS
+ select NO_IOPORT_MAP
+ select RESET_CONTROLLER
+ select SPARSE_IRQ
+ select USE_OF
+ help
+ Support for STMicroelectronics STM32 processors.
+
endchoice
menu "Multiple platform selection"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 985227c..0fac562 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -196,6 +196,7 @@ machine-$(CONFIG_ARCH_SHMOBILE) += shmobile
machine-$(CONFIG_ARCH_SIRF) += prima2
machine-$(CONFIG_ARCH_SOCFPGA) += socfpga
machine-$(CONFIG_ARCH_STI) += sti
+machine-$(CONFIG_ARCH_STM32) += stm32
machine-$(CONFIG_ARCH_SUNXI) += sunxi
machine-$(CONFIG_ARCH_TEGRA) += tegra
machine-$(CONFIG_ARCH_U300) += u300
diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
new file mode 100644
index 0000000..bd0b7b5
--- /dev/null
+++ b/arch/arm/mach-stm32/Makefile
@@ -0,0 +1 @@
+obj-y += board-dt.o
diff --git a/arch/arm/mach-stm32/Makefile.boot b/arch/arm/mach-stm32/Makefile.boot
new file mode 100644
index 0000000..eacfc3f
--- /dev/null
+++ b/arch/arm/mach-stm32/Makefile.boot
@@ -0,0 +1,3 @@
+# Empty file waiting for deletion once Makefile.boot isn't needed any more.
+# Patch waits for application at
+# http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7889/1 .
diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-dt.c
new file mode 100644
index 0000000..f2ad772
--- /dev/null
+++ b/arch/arm/mach-stm32/board-dt.c
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin <[email protected]>
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/kernel.h>
+#include <asm/v7m.h>
+#include <asm/mach/arch.h>
+
+static const char *const stm32_compat[] __initconst = {
+ "st,stm32f429",
+ NULL
+};
+
+DT_MACHINE_START(STM32DT, "STM32 (Device Tree Support)")
+ .dt_compat = stm32_compat,
+ .restart = armv7m_restart,
+MACHINE_END
--
1.9.1
Tested-by: Chanwoo Choi <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
arch/arm/boot/dts/armv7-m.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/armv7-m.dtsi b/arch/arm/boot/dts/armv7-m.dtsi
index 5a660d0..b1ad7cf 100644
--- a/arch/arm/boot/dts/armv7-m.dtsi
+++ b/arch/arm/boot/dts/armv7-m.dtsi
@@ -8,6 +8,12 @@
reg = <0xe000e100 0xc00>;
};
+ systick: timer@e000e010 {
+ compatible = "arm,armv7m-systick";
+ reg = <0xe000e010 0x10>;
+ status = "disabled";
+ };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
--
1.9.1
The STMicrolectornics's STM32F429 MCU has the following main features:
- Cortex-M4 core running up to @180MHz
- 2MB internal flash, 256KBytes internal RAM
- FMC controller to connect SDRAM, NOR and NAND memories
- SD/MMC/SDIO support
- Ethernet controller
- USB OTFG FS & HS controllers
- I2C, SPI, CAN busses support
- Several 16 & 32 bits general purpose timers
- Serial Audio interface
- LCD controller
Tested-by: Chanwoo Choi <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/stm32f429-disco.dts | 71 +++++++++++
arch/arm/boot/dts/stm32f429.dtsi | 227 ++++++++++++++++++++++++++++++++++
3 files changed, 299 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
create mode 100644 arch/arm/boot/dts/stm32f429.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 86217db..db1d8c6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -520,6 +520,7 @@ dtb-$(CONFIG_ARCH_STI) += \
stih416-b2020.dtb \
stih416-b2020e.dtb \
stih418-b2199.dtb
+dtb-$(CONFIG_ARCH_STM32)+= stm32f429-disco.dtb
dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-a1000.dtb \
sun4i-a10-ba10-tvbox.dtb \
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
new file mode 100644
index 0000000..6b9aa59
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -0,0 +1,71 @@
+/*
+ * Copyright 2015 - Maxime Coquelin <[email protected]>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f429.dtsi"
+
+/ {
+ model = "STMicroelectronics STM32F429i-DISCO board";
+ compatible = "st,stm32f429i-disco", "st,stm32f429";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 root=/dev/ram rdinit=/linuxrc";
+ linux,stdout-path = &usart1;
+ };
+
+ memory {
+ reg = <0x90000000 0x800000>;
+ };
+
+ aliases {
+ serial0 = &usart1;
+ };
+};
+
+&usart1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
new file mode 100644
index 0000000..2719f3a
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -0,0 +1,227 @@
+/*
+ * Copyright 2015 - Maxime Coquelin <[email protected]>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armv7-m.dtsi"
+#include <dt-bindings/mfd/stm32f4-rcc.h>
+
+/ {
+ clocks {
+ clk_sysclk: clk-sysclk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <180000000>;
+ };
+
+ clk_hclk: clk-hclk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <180000000>;
+ };
+
+ clk_pclk1: clk-pclk1 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <45000000>;
+ };
+
+ clk_pclk2: clk-pclk2 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <90000000>;
+ };
+
+ clk_pmtr1: clk-pmtr1 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <90000000>;
+ };
+
+ clk_pmtr2: clk-pmtr2 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <180000000>;
+ };
+
+ clk_systick: clk-systick {
+ compatible = "fixed-factor-clock";
+ clocks = <&clk_hclk>;
+ #clock-cells = <0>;
+ clock-div = <8>;
+ clock-mult = <1>;
+ };
+ };
+
+ soc {
+ timer2: timer@40000000 {
+ compatible = "st,stm32-timer";
+ reg = <0x40000000 0x400>;
+ interrupts = <28>;
+ resets = <&rcc STM32F4_APB1_RESET(TIM2)>;
+ clocks = <&clk_pmtr1>;
+ status = "disabled";
+ };
+
+ timer3: timer@40000400 {
+ compatible = "st,stm32-timer";
+ reg = <0x40000400 0x400>;
+ interrupts = <29>;
+ resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
+ clocks = <&clk_pmtr1>;
+ status = "disabled";
+ };
+
+ timer4: timer@40000800 {
+ compatible = "st,stm32-timer";
+ reg = <0x40000800 0x400>;
+ interrupts = <30>;
+ resets = <&rcc STM32F4_APB1_RESET(TIM4)>;
+ clocks = <&clk_pmtr1>;
+ status = "disabled";
+ };
+
+ timer5: timer@40000c00 {
+ compatible = "st,stm32-timer";
+ reg = <0x40000c00 0x400>;
+ interrupts = <50>;
+ resets = <&rcc STM32F4_APB1_RESET(TIM5)>;
+ clocks = <&clk_pmtr1>;
+ };
+
+ timer6: timer@40001000 {
+ compatible = "st,stm32-timer";
+ reg = <0x40001000 0x400>;
+ interrupts = <54>;
+ resets = <&rcc STM32F4_APB1_RESET(TIM6)>;
+ clocks = <&clk_pmtr1>;
+ status = "disabled";
+ };
+
+ timer7: timer@40001400 {
+ compatible = "st,stm32-timer";
+ reg = <0x40001400 0x400>;
+ interrupts = <55>;
+ resets = <&rcc STM32F4_APB1_RESET(TIM7)>;
+ clocks = <&clk_pmtr1>;
+ status = "disabled";
+ };
+
+ usart2: serial@40004400 {
+ compatible = "st,stm32-usart", "st,stm32-uart";
+ reg = <0x40004400 0x400>;
+ interrupts = <38>;
+ clocks = <&clk_pclk1>;
+ status = "disabled";
+ };
+
+ usart3: serial@40004800 {
+ compatible = "st,stm32-usart", "st,stm32-uart";
+ reg = <0x40004800 0x400>;
+ interrupts = <39>;
+ clocks = <&clk_pclk1>;
+ status = "disabled";
+ };
+
+ usart4: serial@40004c00 {
+ compatible = "st,stm32-uart";
+ reg = <0x40004c00 0x400>;
+ interrupts = <52>;
+ clocks = <&clk_pclk1>;
+ status = "disabled";
+ };
+
+ usart5: serial@40005000 {
+ compatible = "st,stm32-uart";
+ reg = <0x40005000 0x400>;
+ interrupts = <53>;
+ clocks = <&clk_pclk1>;
+ status = "disabled";
+ };
+
+ usart7: serial@40007800 {
+ compatible = "st,stm32-usart", "st,stm32-uart";
+ reg = <0x40007800 0x400>;
+ interrupts = <82>;
+ clocks = <&clk_pclk1>;
+ status = "disabled";
+ };
+
+ usart8: serial@40007c00 {
+ compatible = "st,stm32-usart", "st,stm32-uart";
+ reg = <0x40007c00 0x400>;
+ interrupts = <83>;
+ clocks = <&clk_pclk1>;
+ status = "disabled";
+ };
+
+ usart1: serial@40011000 {
+ compatible = "st,stm32-usart", "st,stm32-uart";
+ reg = <0x40011000 0x400>;
+ interrupts = <37>;
+ clocks = <&clk_pclk2>;
+ status = "disabled";
+ };
+
+ usart6: serial@40011400 {
+ compatible = "st,stm32-usart", "st,stm32-uart";
+ reg = <0x40011400 0x400>;
+ interrupts = <71>;
+ clocks = <&clk_pclk2>;
+ status = "disabled";
+ };
+
+ rcc: rcc@40023810 {
+ #reset-cells = <1>;
+ compatible = "st,stm32-rcc";
+ reg = <0x40023800 0x400>;
+ };
+ };
+};
+
+&systick {
+ clocks = <&clk_systick>;
+ status = "okay";
+};
--
1.9.1
This patch adds a new config for STM32 MCUs.
STM32F429 Discovery board boots successfully with this config applied.
Tested-by: Chanwoo Choi <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
arch/arm/configs/stm32_defconfig | 70 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
create mode 100644 arch/arm/configs/stm32_defconfig
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
new file mode 100644
index 0000000..af757925
--- /dev/null
+++ b/arch/arm/configs/stm32_defconfig
@@ -0,0 +1,70 @@
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="./rootfs.cpio"
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_UID16 is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+# CONFIG_MMU is not set
+CONFIG_ARCH_STM32=y
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x90000000
+CONFIG_FLASH_MEM_BASE=0x08000000
+CONFIG_FLASH_SIZE=0x00200000
+CONFIG_PREEMPT=y
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_XIP_KERNEL=y
+CONFIG_XIP_PHYS_ADDR=0x08008000
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_COREDUMP is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_BLK_DEV is not set
+CONFIG_EEPROM_93CX6=y
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_UNIX98_PTYS is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_NONSTANDARD=y
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_STM32=y
+CONFIG_SERIAL_STM32_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+# CONFIG_FILE_LOCKING is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+CONFIG_NLS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_FTRACE is not set
+CONFIG_CRC_ITU_T=y
+CONFIG_CRC7=y
--
1.9.1
Add a MAINTAINER entry covering all STM32 machine and drivers files.
Signed-off-by: Maxime Coquelin <[email protected]>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2e5bbc0..858d821 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1479,6 +1479,14 @@ F: drivers/usb/host/ehci-st.c
F: drivers/usb/host/ohci-st.c
F: drivers/ata/ahci_st.c
+ARM/STM32 ARCHITECTURE
+M: Maxime Coquelin <[email protected]>
+L: [email protected] (moderated for non-subscribers)
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mcoquelin/stm32.git
+N: stm32
+F: drivers/clocksource/armv7m_systick.c
+
ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
M: Lennert Buytenhek <[email protected]>
L: [email protected] (moderated for non-subscribers)
--
1.9.1
On Sat, May 9, 2015 at 10:53 AM, Maxime Coquelin
<[email protected]> wrote:
> This drivers adds support to the STM32 USART controller, which is a
> standard serial driver.
>
Reviewed-by: Andy Shevchenko <[email protected]>
> Tested-by: Chanwoo Choi <[email protected]>
> Reviewed-by: Peter Hurley <[email protected]>
> Reviewed-by: Vladimir Zapolskiy <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
> ---
> drivers/tty/serial/Kconfig | 17 +
> drivers/tty/serial/Makefile | 1 +
> drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/serial_core.h | 3 +
> 4 files changed, 760 insertions(+)
> create mode 100644 drivers/tty/serial/stm32-usart.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index f8120c1..7eb62f1 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1589,6 +1589,23 @@ config SERIAL_SPRD_CONSOLE
> with "earlycon" on the kernel command line. The console is
> enabled when early_param is processed.
>
> +config SERIAL_STM32
> + tristate "STMicroelectronics STM32 serial port support"
> + select SERIAL_CORE
> + depends on ARM || COMPILE_TEST
> + help
> + This driver is for the on-chip Serial Controller on
> + STMicroelectronics STM32 MCUs.
> + USART supports Rx & Tx functionality.
> + It support all industry standard baud rates.
> +
> + If unsure, say N.
> +
> +config SERIAL_STM32_CONSOLE
> + bool "Support for console on STM32"
> + depends on SERIAL_STM32=y
> + select SERIAL_CORE_CONSOLE
> +
> endmenu
>
> config SERIAL_MCTRL_GPIO
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index c3ac3d9..61979ce 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART) += fsl_lpuart.o
> obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR) += digicolor-usart.o
> obj-$(CONFIG_SERIAL_MEN_Z135) += men_z135_uart.o
> obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
> +obj-$(CONFIG_SERIAL_STM32) += stm32-usart.o
>
> # GPIOLIB helpers for modem control lines
> obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> new file mode 100644
> index 0000000..4a6eab6
> --- /dev/null
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -0,0 +1,739 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author: Maxime Coquelin <[email protected]>
> + * License terms: GNU General Public License (GPL), version 2
> + *
> + * Inspired by st-asc.c from STMicroelectronics (c)
> + */
> +
> +#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> +#define SUPPORT_SYSRQ
> +#endif
> +
> +#include <linux/module.h>
> +#include <linux/serial.h>
> +#include <linux/console.h>
> +#include <linux/sysrq.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/irq.h>
> +#include <linux/tty.h>
> +#include <linux/tty_flip.h>
> +#include <linux/delay.h>
> +#include <linux/spinlock.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/serial_core.h>
> +#include <linux/clk.h>
> +
> +#define DRIVER_NAME "stm32-usart"
> +
> +/* Register offsets */
> +#define USART_SR 0x00
> +#define USART_DR 0x04
> +#define USART_BRR 0x08
> +#define USART_CR1 0x0c
> +#define USART_CR2 0x10
> +#define USART_CR3 0x14
> +#define USART_GTPR 0x18
> +
> +/* USART_SR */
> +#define USART_SR_PE BIT(0)
> +#define USART_SR_FE BIT(1)
> +#define USART_SR_NF BIT(2)
> +#define USART_SR_ORE BIT(3)
> +#define USART_SR_IDLE BIT(4)
> +#define USART_SR_RXNE BIT(5)
> +#define USART_SR_TC BIT(6)
> +#define USART_SR_TXE BIT(7)
> +#define USART_SR_LBD BIT(8)
> +#define USART_SR_CTS BIT(9)
> +#define USART_SR_ERR_MASK (USART_SR_LBD | USART_SR_ORE | \
> + USART_SR_FE | USART_SR_PE)
> +/* Dummy bits */
> +#define USART_SR_DUMMY_RX BIT(16)
> +
> +/* USART_DR */
> +#define USART_DR_MASK GENMASK(8, 0)
> +
> +/* USART_BRR */
> +#define USART_BRR_DIV_F_MASK GENMASK(3, 0)
> +#define USART_BRR_DIV_M_MASK GENMASK(15, 4)
> +#define USART_BRR_DIV_M_SHIFT 4
> +
> +/* USART_CR1 */
> +#define USART_CR1_SBK BIT(0)
> +#define USART_CR1_RWU BIT(1)
> +#define USART_CR1_RE BIT(2)
> +#define USART_CR1_TE BIT(3)
> +#define USART_CR1_IDLEIE BIT(4)
> +#define USART_CR1_RXNEIE BIT(5)
> +#define USART_CR1_TCIE BIT(6)
> +#define USART_CR1_TXEIE BIT(7)
> +#define USART_CR1_PEIE BIT(8)
> +#define USART_CR1_PS BIT(9)
> +#define USART_CR1_PCE BIT(10)
> +#define USART_CR1_WAKE BIT(11)
> +#define USART_CR1_M BIT(12)
> +#define USART_CR1_UE BIT(13)
> +#define USART_CR1_OVER8 BIT(15)
> +#define USART_CR1_IE_MASK GENMASK(8, 4)
> +
> +/* USART_CR2 */
> +#define USART_CR2_ADD_MASK GENMASK(3, 0)
> +#define USART_CR2_LBDL BIT(5)
> +#define USART_CR2_LBDIE BIT(6)
> +#define USART_CR2_LBCL BIT(8)
> +#define USART_CR2_CPHA BIT(9)
> +#define USART_CR2_CPOL BIT(10)
> +#define USART_CR2_CLKEN BIT(11)
> +#define USART_CR2_STOP_2B BIT(13)
> +#define USART_CR2_STOP_MASK GENMASK(13, 12)
> +#define USART_CR2_LINEN BIT(14)
> +
> +/* USART_CR3 */
> +#define USART_CR3_EIE BIT(0)
> +#define USART_CR3_IREN BIT(1)
> +#define USART_CR3_IRLP BIT(2)
> +#define USART_CR3_HDSEL BIT(3)
> +#define USART_CR3_NACK BIT(4)
> +#define USART_CR3_SCEN BIT(5)
> +#define USART_CR3_DMAR BIT(6)
> +#define USART_CR3_DMAT BIT(7)
> +#define USART_CR3_RTSE BIT(8)
> +#define USART_CR3_CTSE BIT(9)
> +#define USART_CR3_CTSIE BIT(10)
> +#define USART_CR3_ONEBIT BIT(11)
> +
> +/* USART_GTPR */
> +#define USART_GTPR_PSC_MASK GENMASK(7, 0)
> +#define USART_GTPR_GT_MASK GENMASK(15, 8)
> +
> +#define DRIVER_NAME "stm32-usart"
> +#define STM32_SERIAL_NAME "ttyS"
> +#define STM32_MAX_PORTS 6
> +
> +struct stm32_port {
> + struct uart_port port;
> + struct clk *clk;
> + bool hw_flow_control;
> +};
> +
> +static struct stm32_port stm32_ports[STM32_MAX_PORTS];
> +static struct uart_driver stm32_usart_driver;
> +
> +static void stm32_stop_tx(struct uart_port *port);
> +
> +static inline struct stm32_port *to_stm32_port(struct uart_port *port)
> +{
> + return container_of(port, struct stm32_port, port);
> +}
> +
> +static void stm32_set_bits(struct uart_port *port, u32 reg, u32 bits)
> +{
> + u32 val;
> +
> + val = readl_relaxed(port->membase + reg);
> + val |= bits;
> + writel_relaxed(val, port->membase + reg);
> +}
> +
> +static void stm32_clr_bits(struct uart_port *port, u32 reg, u32 bits)
> +{
> + u32 val;
> +
> + val = readl_relaxed(port->membase + reg);
> + val &= ~bits;
> + writel_relaxed(val, port->membase + reg);
> +}
> +
> +static void stm32_receive_chars(struct uart_port *port)
> +{
> + struct tty_port *tport = &port->state->port;
> + unsigned long c;
> + u32 sr;
> + char flag;
> +
> + if (port->irq_wake)
> + pm_wakeup_event(tport->tty->dev, 0);
> +
> + while ((sr = readl_relaxed(port->membase + USART_SR)) & USART_SR_RXNE) {
> + sr |= USART_SR_DUMMY_RX;
> + c = readl_relaxed(port->membase + USART_DR);
> + flag = TTY_NORMAL;
> + port->icount.rx++;
> +
> + if (sr & USART_SR_ERR_MASK) {
> + if (sr & USART_SR_LBD) {
> + port->icount.brk++;
> + if (uart_handle_break(port))
> + continue;
> + } else if (sr & USART_SR_ORE) {
> + port->icount.overrun++;
> + } else if (sr & USART_SR_PE) {
> + port->icount.parity++;
> + } else if (sr & USART_SR_FE) {
> + port->icount.frame++;
> + }
> +
> + sr &= port->read_status_mask;
> +
> + if (sr & USART_SR_LBD)
> + flag = TTY_BREAK;
> + else if (sr & USART_SR_PE)
> + flag = TTY_PARITY;
> + else if (sr & USART_SR_FE)
> + flag = TTY_FRAME;
> + }
> +
> + if (uart_handle_sysrq_char(port, c))
> + continue;
> + uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> + }
> +
> + spin_unlock(&port->lock);
> + tty_flip_buffer_push(tport);
> + spin_lock(&port->lock);
> +}
> +
> +static void stm32_transmit_chars(struct uart_port *port)
> +{
> + struct circ_buf *xmit = &port->state->xmit;
> +
> + if (port->x_char) {
> + writel_relaxed(port->x_char, port->membase + USART_DR);
> + port->x_char = 0;
> + port->icount.tx++;
> + return;
> + }
> +
> + if (uart_tx_stopped(port)) {
> + stm32_stop_tx(port);
> + return;
> + }
> +
> + if (uart_circ_empty(xmit)) {
> + stm32_stop_tx(port);
> + return;
> + }
> +
> + writel_relaxed(xmit->buf[xmit->tail], port->membase + USART_DR);
> + xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> + port->icount.tx++;
> +
> + if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> + uart_write_wakeup(port);
> +
> + if (uart_circ_empty(xmit))
> + stm32_stop_tx(port);
> +}
> +
> +static irqreturn_t stm32_interrupt(int irq, void *ptr)
> +{
> + struct uart_port *port = ptr;
> + u32 sr;
> +
> + spin_lock(&port->lock);
> +
> + sr = readl_relaxed(port->membase + USART_SR);
> +
> + if (sr & USART_SR_RXNE)
> + stm32_receive_chars(port);
> +
> + if (sr & USART_SR_TXE)
> + stm32_transmit_chars(port);
> +
> + spin_unlock(&port->lock);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static unsigned int stm32_tx_empty(struct uart_port *port)
> +{
> + return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
> +}
> +
> +static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> + if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
> + stm32_set_bits(port, USART_CR3, USART_CR3_RTSE);
> + else
> + stm32_clr_bits(port, USART_CR3, USART_CR3_RTSE);
> +}
> +
> +static unsigned int stm32_get_mctrl(struct uart_port *port)
> +{
> + /* This routine is used to get signals of: DCD, DSR, RI, and CTS */
> + return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
> +}
> +
> +/* Transmit stop */
> +static void stm32_stop_tx(struct uart_port *port)
> +{
> + stm32_clr_bits(port, USART_CR1, USART_CR1_TXEIE);
> +}
> +
> +/* There are probably characters waiting to be transmitted. */
> +static void stm32_start_tx(struct uart_port *port)
> +{
> + struct circ_buf *xmit = &port->state->xmit;
> +
> + if (uart_circ_empty(xmit))
> + return;
> +
> + stm32_set_bits(port, USART_CR1, USART_CR1_TXEIE | USART_CR1_TE);
> +}
> +
> +/* Throttle the remote when input buffer is about to overflow. */
> +static void stm32_throttle(struct uart_port *port)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&port->lock, flags);
> + stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
> + spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +/* Unthrottle the remote, the input buffer can now accept data. */
> +static void stm32_unthrottle(struct uart_port *port)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&port->lock, flags);
> + stm32_set_bits(port, USART_CR1, USART_CR1_RXNEIE);
> + spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +/* Receive stop */
> +static void stm32_stop_rx(struct uart_port *port)
> +{
> + stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +}
> +
> +/* Handle breaks - ignored by us */
> +static void stm32_break_ctl(struct uart_port *port, int break_state)
> +{
> +}
> +
> +static int stm32_startup(struct uart_port *port)
> +{
> + const char *name = to_platform_device(port->dev)->name;
> + u32 val;
> + int ret;
> +
> + ret = request_irq(port->irq, stm32_interrupt, IRQF_NO_SUSPEND,
> + name, port);
> + if (ret)
> + return ret;
> +
> + val = USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
> + stm32_set_bits(port, USART_CR1, val);
> +
> + return 0;
> +}
> +
> +static void stm32_shutdown(struct uart_port *port)
> +{
> + u32 val;
> +
> + val = USART_CR1_TXEIE | USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
> + stm32_set_bits(port, USART_CR1, val);
> +
> + free_irq(port->irq, port);
> +}
> +
> +static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
> + struct ktermios *old)
> +{
> + struct stm32_port *stm32_port = to_stm32_port(port);
> + unsigned int baud;
> + u32 usartdiv, mantissa, fraction, oversampling;
> + tcflag_t cflag = termios->c_cflag;
> + u32 cr1, cr2, cr3;
> + unsigned long flags;
> +
> + if (!stm32_port->hw_flow_control)
> + cflag &= ~CRTSCTS;
> +
> + baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 8);
> +
> + spin_lock_irqsave(&port->lock, flags);
> +
> + /* Stop serial port and reset value */
> + writel_relaxed(0, port->membase + USART_CR1);
> +
> + cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
> + cr2 = 0;
> + cr3 = 0;
> +
> + if (cflag & CSTOPB)
> + cr2 |= USART_CR2_STOP_2B;
> +
> + if (cflag & PARENB) {
> + cr1 |= USART_CR1_PCE;
> + if ((cflag & CSIZE) == CS8)
> + cr1 |= USART_CR1_M;
> + }
> +
> + if (cflag & PARODD)
> + cr1 |= USART_CR1_PS;
> +
> + port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS);
> + if (cflag & CRTSCTS) {
> + port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
> + cr3 |= USART_CR3_CTSE;
> + }
> +
> + usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
> +
> + /*
> + * The USART supports 16 or 8 times oversampling.
> + * By default we prefer 16 times oversampling, so that the receiver
> + * has a better tolerance to clock deviations.
> + * 8 times oversampling is only used to achieve higher speeds.
> + */
> + if (usartdiv < 16) {
> + oversampling = 8;
> + stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
> + } else {
> + oversampling = 16;
> + stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
> + }
> +
> + mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
> + fraction = usartdiv % oversampling;
> + writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
> +
> + uart_update_timeout(port, cflag, baud);
> +
> + port->read_status_mask = USART_SR_ORE;
> + if (termios->c_iflag & INPCK)
> + port->read_status_mask |= USART_SR_PE | USART_SR_FE;
> + if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
> + port->read_status_mask |= USART_SR_LBD;
> +
> + /* Characters to ignore */
> + port->ignore_status_mask = 0;
> + if (termios->c_iflag & IGNPAR)
> + port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
> + if (termios->c_iflag & IGNBRK) {
> + port->ignore_status_mask |= USART_SR_LBD;
> + /*
> + * If we're ignoring parity and break indicators,
> + * ignore overruns too (for real raw support).
> + */
> + if (termios->c_iflag & IGNPAR)
> + port->ignore_status_mask |= USART_SR_ORE;
> + }
> +
> + /* Ignore all characters if CREAD is not set */
> + if ((termios->c_cflag & CREAD) == 0)
> + port->ignore_status_mask |= USART_SR_DUMMY_RX;
> +
> + writel_relaxed(cr3, port->membase + USART_CR3);
> + writel_relaxed(cr2, port->membase + USART_CR2);
> + writel_relaxed(cr1, port->membase + USART_CR1);
> +
> + spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static const char *stm32_type(struct uart_port *port)
> +{
> + return (port->type == PORT_STM32) ? DRIVER_NAME : NULL;
> +}
> +
> +static void stm32_release_port(struct uart_port *port)
> +{
> +}
> +
> +static int stm32_request_port(struct uart_port *port)
> +{
> + return 0;
> +}
> +
> +static void stm32_config_port(struct uart_port *port, int flags)
> +{
> + if (flags & UART_CONFIG_TYPE)
> + port->type = PORT_STM32;
> +}
> +
> +static int
> +stm32_verify_port(struct uart_port *port, struct serial_struct *ser)
> +{
> + /* No user changeable parameters */
> + return -EINVAL;
> +}
> +
> +static void stm32_pm(struct uart_port *port, unsigned int state,
> + unsigned int oldstate)
> +{
> + struct stm32_port *stm32port = container_of(port,
> + struct stm32_port, port);
> + unsigned long flags = 0;
> +
> + switch (state) {
> + case UART_PM_STATE_ON:
> + clk_prepare_enable(stm32port->clk);
> + break;
> + case UART_PM_STATE_OFF:
> + spin_lock_irqsave(&port->lock, flags);
> + stm32_clr_bits(port, USART_CR1, USART_CR1_UE);
> + spin_unlock_irqrestore(&port->lock, flags);
> + clk_disable_unprepare(stm32port->clk);
> + break;
> + }
> +}
> +
> +static const struct uart_ops stm32_uart_ops = {
> + .tx_empty = stm32_tx_empty,
> + .set_mctrl = stm32_set_mctrl,
> + .get_mctrl = stm32_get_mctrl,
> + .stop_tx = stm32_stop_tx,
> + .start_tx = stm32_start_tx,
> + .throttle = stm32_throttle,
> + .unthrottle = stm32_unthrottle,
> + .stop_rx = stm32_stop_rx,
> + .break_ctl = stm32_break_ctl,
> + .startup = stm32_startup,
> + .shutdown = stm32_shutdown,
> + .set_termios = stm32_set_termios,
> + .pm = stm32_pm,
> + .type = stm32_type,
> + .release_port = stm32_release_port,
> + .request_port = stm32_request_port,
> + .config_port = stm32_config_port,
> + .verify_port = stm32_verify_port,
> +};
> +
> +static int stm32_init_port(struct stm32_port *stm32port,
> + struct platform_device *pdev)
> +{
> + struct uart_port *port = &stm32port->port;
> + struct resource *res;
> + int ret;
> +
> + port->iotype = UPIO_MEM;
> + port->flags = UPF_BOOT_AUTOCONF;
> + port->ops = &stm32_uart_ops;
> + port->dev = &pdev->dev;
> + port->irq = platform_get_irq(pdev, 0);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + port->membase = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(port->membase))
> + return PTR_ERR(port->membase);
> + port->mapbase = res->start;
> +
> + spin_lock_init(&port->lock);
> +
> + stm32port->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(stm32port->clk))
> + return PTR_ERR(stm32port->clk);
> +
> + /* Ensure that clk rate is correct by enabling the clk */
> + ret = clk_prepare_enable(stm32port->clk);
> + if (ret)
> + return ret;
> +
> + stm32port->port.uartclk = clk_get_rate(stm32port->clk);
> + if (!stm32port->port.uartclk)
> + ret = -EINVAL;
> +
> + clk_disable_unprepare(stm32port->clk);
> +
> + return ret;
> +}
> +
> +static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + int id;
> +
> + if (!np)
> + return NULL;
> +
> + id = of_alias_get_id(np, "serial");
> + if (id < 0)
> + id = 0;
> +
> + if (WARN_ON(id >= STM32_MAX_PORTS))
> + return NULL;
> +
> + stm32_ports[id].hw_flow_control = of_property_read_bool(np,
> + "auto-flow-control");
> + stm32_ports[id].port.line = id;
> + return &stm32_ports[id];
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id stm32_match[] = {
> + { .compatible = "st,stm32-usart", },
> + { .compatible = "st,stm32-uart", },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, stm32_match);
> +#endif
> +
> +static int stm32_serial_probe(struct platform_device *pdev)
> +{
> + int ret;
> + struct stm32_port *stm32port;
> +
> + stm32port = stm32_of_get_stm32_port(pdev);
> + if (!stm32port)
> + return -ENODEV;
> +
> + ret = stm32_init_port(stm32port, pdev);
> + if (ret)
> + return ret;
> +
> + ret = uart_add_one_port(&stm32_usart_driver, &stm32port->port);
> + if (ret)
> + return ret;
> +
> + platform_set_drvdata(pdev, &stm32port->port);
> +
> + return 0;
> +}
> +
> +static int stm32_serial_remove(struct platform_device *pdev)
> +{
> + struct uart_port *port = platform_get_drvdata(pdev);
> +
> + return uart_remove_one_port(&stm32_usart_driver, port);
> +}
> +
> +
> +#ifdef CONFIG_SERIAL_STM32_CONSOLE
> +static void stm32_console_putchar(struct uart_port *port, int ch)
> +{
> + while (!(readl_relaxed(port->membase + USART_SR) & USART_SR_TXE))
> + cpu_relax();
> +
> + writel_relaxed(ch, port->membase + USART_DR);
> +}
> +
> +static void stm32_console_write(struct console *co, const char *s, unsigned cnt)
> +{
> + struct uart_port *port = &stm32_ports[co->index].port;
> + unsigned long flags;
> + u32 old_cr1, new_cr1;
> + int locked = 1;
> +
> + local_irq_save(flags);
> + if (port->sysrq)
> + locked = 0;
> + else if (oops_in_progress)
> + locked = spin_trylock(&port->lock);
> + else
> + spin_lock(&port->lock);
> +
> + /* Save and disable interrupts */
> + old_cr1 = readl_relaxed(port->membase + USART_CR1);
> + new_cr1 = old_cr1 & ~USART_CR1_IE_MASK;
> + writel_relaxed(new_cr1, port->membase + USART_CR1);
> +
> + uart_console_write(port, s, cnt, stm32_console_putchar);
> +
> + /* Restore interrupt state */
> + writel_relaxed(old_cr1, port->membase + USART_CR1);
> +
> + if (locked)
> + spin_unlock(&port->lock);
> + local_irq_restore(flags);
> +}
> +
> +static int stm32_console_setup(struct console *co, char *options)
> +{
> + struct stm32_port *stm32port;
> + int baud = 9600;
> + int bits = 8;
> + int parity = 'n';
> + int flow = 'n';
> +
> + if (co->index >= STM32_MAX_PORTS)
> + return -ENODEV;
> +
> + stm32port = &stm32_ports[co->index];
> +
> + /*
> + * This driver does not support early console initialization
> + * (use ARM early printk support instead), so we only expect
> + * this to be called during the uart port registration when the
> + * driver gets probed and the port should be mapped at that point.
> + */
> + if (stm32port->port.mapbase == 0 || stm32port->port.membase == NULL)
> + return -ENXIO;
> +
> + if (options)
> + uart_parse_options(options, &baud, &parity, &bits, &flow);
> +
> + return uart_set_options(&stm32port->port, co, baud, parity, bits, flow);
> +}
> +
> +static struct console stm32_console = {
> + .name = STM32_SERIAL_NAME,
> + .device = uart_console_device,
> + .write = stm32_console_write,
> + .setup = stm32_console_setup,
> + .flags = CON_PRINTBUFFER,
> + .index = -1,
> + .data = &stm32_usart_driver,
> +};
> +
> +#define STM32_SERIAL_CONSOLE (&stm32_console)
> +
> +#else
> +#define STM32_SERIAL_CONSOLE NULL
> +#endif /* CONFIG_SERIAL_STM32_CONSOLE */
> +
> +static struct uart_driver stm32_usart_driver = {
> + .driver_name = DRIVER_NAME,
> + .dev_name = STM32_SERIAL_NAME,
> + .major = 0,
> + .minor = 0,
> + .nr = STM32_MAX_PORTS,
> + .cons = STM32_SERIAL_CONSOLE,
> +};
> +
> +static struct platform_driver stm32_serial_driver = {
> + .probe = stm32_serial_probe,
> + .remove = stm32_serial_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = of_match_ptr(stm32_match),
> + },
> +};
> +
> +static int __init usart_init(void)
> +{
> + static char banner[] __initdata = "STM32 USART driver initialized";
> + int ret;
> +
> + pr_info("%s\n", banner);
> +
> + ret = uart_register_driver(&stm32_usart_driver);
> + if (ret)
> + return ret;
> +
> + ret = platform_driver_register(&stm32_serial_driver);
> + if (ret)
> + uart_unregister_driver(&stm32_usart_driver);
> +
> + return ret;
> +}
> +
> +static void __exit usart_exit(void)
> +{
> + platform_driver_unregister(&stm32_serial_driver);
> + uart_unregister_driver(&stm32_usart_driver);
> +}
> +
> +module_init(usart_init);
> +module_exit(usart_exit);
> +
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> +MODULE_DESCRIPTION("STMicroelectronics STM32 serial port driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index b212281..93ba148 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -258,4 +258,7 @@
> /* Cris v10 / v32 SoC */
> #define PORT_CRIS 112
>
> +/* STM32 USART */
> +#define PORT_STM32 113
> +
> #endif /* _UAPILINUX_SERIAL_CORE_H */
> --
> 1.9.1
>
--
With Best Regards,
Andy Shevchenko
On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> +#include <dt-bindings/mfd/stm32f4-rcc.h>
> +
>
Can you find a way to avoid this dependency?
Maybe you can change the bindings so that the numbers you pass as
arguments to the reset and clock specifiers reflect the numbers that
the hardware use?
Arnd
2015-05-12 23:21 GMT+02:00 Arnd Bergmann <[email protected]>:
> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>> +#include <dt-bindings/mfd/stm32f4-rcc.h>
>> +
>>
>
> Can you find a way to avoid this dependency?
>
> Maybe you can change the bindings so that the numbers you pass as
> arguments to the reset and clock specifiers reflect the numbers that
> the hardware use?
If I understand correctly, you prefer the way I did in v7 [0]?
I don't have a strong opinion on this. Either way is fine to me.
I changed the bindings in the v8 after discussions with Daniel
Thompson, who is implementing the clock driver part of the RCC IP.
He proposed we used common defines, because each peripheral has a
reset line and a clock gate.
Both reset and clock are represented as a single bit, with only the
base offset differing between clock and reset.
You can have a look at chapter 6 of the reference manual [1] if you
find some time.
Having common defines between clocks and reset make sense to me, but I
also understand your point of avoiding dependencies.
Maybe I can revert back to v7 bindings for now, and then we can
reconsider using common defines when Daniel will send the clock
patches.
Note that doing that won't break the DT binary compatibility, as the
raw reset values, or the ones from defines are the same.
Daniel, could you share an example of the bindings you would use for the clocks?
Kind regards,
Maxime
>
> Arnd
[0]: http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04523.html
[1]: http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
On 13/05/15 12:45, Maxime Coquelin wrote:
> 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <[email protected]>:
>> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>>> +#include <dt-bindings/mfd/stm32f4-rcc.h>
>>> +
>>>
>>
>> Can you find a way to avoid this dependency?
>>
>> Maybe you can change the bindings so that the numbers you pass as
>> arguments to the reset and clock specifiers reflect the numbers that
>> the hardware use?
>
> If I understand correctly, you prefer the way I did in v7 [0]?
>
> I don't have a strong opinion on this. Either way is fine to me.
>
> I changed the bindings in the v8 after discussions with Daniel
> Thompson, who is implementing the clock driver part of the RCC IP.
>
> He proposed we used common defines, because each peripheral has a
> reset line and a clock gate.
> Both reset and clock are represented as a single bit, with only the
> base offset differing between clock and reset.
> You can have a look at chapter 6 of the reference manual [1] if you
> find some time.
>
> Having common defines between clocks and reset make sense to me, but I
> also understand your point of avoiding dependencies.
>
> Maybe I can revert back to v7 bindings for now, and then we can
> reconsider using common defines when Daniel will send the clock
> patches.
> Note that doing that won't break the DT binary compatibility, as the
> raw reset values, or the ones from defines are the same.
>
> Daniel, could you share an example of the bindings you would use for the clocks?
For the most cases, where there is a clock gate just before the
peripheral it looks pretty much like the reset driver and I use the bit
offset of the clock gating bit as the index.
However there are a couple of clocks without gating just before the
clock reaches the peripheral:
1. A hard coded /8. I think this will have to be given a synthetic
number.
2. Ungated dividers. For these I am using the bit offset of the LSB of
the mux field.
So I think there is only one value that is completely unrelated to the
hardware and will use a magic constant instead.
I had planned to macros similar to the STM32F4_AxB_RESET() family of
macros in both clk driver and DT in order to reuse the bit layouts from
dt-bindings/mfd/stm32f4-rcc.h .
Normal case would have looked like this:
timer3: timer@40000000 {
compatible = "st,stm32-timer";
reg = <0x40000000 0x400>;
interrupts = <28>;
resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
status = "disabled";
};
Without the macros it looks like this:
timer3: timer@40000000 {
compatible = "st,stm32-timer";
reg = <0x40000000 0x400>;
interrupts = <28>;
resets = <&rcc 257>;
clocks = <&rcc 513>;
status = "disabled";
};
However we could perhaps be more literate even if we don't use the macros?
timer3: timer@40000000 {
compatible = "st,stm32-timer";
reg = <0x40000000 0x400>;
interrupts = <28>;
resets = <&rcc ((0x20*8) + 1)>;
clocks = <&rcc ((0x40*8) + 1)>;
status = "disabled";
};
Daniel.
> Kind regards,
> Maxime
>
>>
>> Arnd
>
> [0]: http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04523.html
> [1]: http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
>
On Wednesday 13 May 2015 13:58:05 Daniel Thompson wrote:
> On 13/05/15 12:45, Maxime Coquelin wrote:
> > 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <[email protected]>:
> >> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> >>> +#include <dt-bindings/mfd/stm32f4-rcc.h>
> >>> +
> >>>
> >>
> >> Can you find a way to avoid this dependency?
> >>
> >> Maybe you can change the bindings so that the numbers you pass as
> >> arguments to the reset and clock specifiers reflect the numbers that
> >> the hardware use?
> >
> > If I understand correctly, you prefer the way I did in v7 [0]?
Yes, that looks better. I would probably not list all the possible
values in the binding though, when the intention is to use the
hardware specific values, and being able to reuse the binding
and driver for variations of the same chip.
> > Note that doing that won't break the DT binary compatibility, as the
> > raw reset values, or the ones from defines are the same.
> >
> > Daniel, could you share an example of the bindings you would use for the clocks?
>
> For the most cases, where there is a clock gate just before the
> peripheral it looks pretty much like the reset driver and I use the bit
> offset of the clock gating bit as the index.
Is this bit always the same index as the one for the reset driver?
> However there are a couple of clocks without gating just before the
> clock reaches the peripheral:
>
> 1. A hard coded /8. I think this will have to be given a synthetic
> number.
If this is just a divider, why not use a separate DT node for that,
like this:
clock {
compatible = "fixed-factor-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
clock-div = <8>;
clock-mult = <1>;
};
No need to assign a number for this.
> 2. Ungated dividers. For these I am using the bit offset of the LSB of
> the mux field.
Do these ones also come with resets?
> So I think there is only one value that is completely unrelated to the
> hardware and will use a magic constant instead.
>
> I had planned to macros similar to the STM32F4_AxB_RESET() family of
> macros in both clk driver and DT in order to reuse the bit layouts from
> dt-bindings/mfd/stm32f4-rcc.h .
>
> Normal case would have looked like this:
>
> timer3: timer@40000000 {
> compatible = "st,stm32-timer";
> reg = <0x40000000 0x400>;
> interrupts = <28>;
> resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
> clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
> status = "disabled";
> };
>
> Without the macros it looks like this:
>
> timer3: timer@40000000 {
> compatible = "st,stm32-timer";
> reg = <0x40000000 0x400>;
> interrupts = <28>;
> resets = <&rcc 257>;
> clocks = <&rcc 513>;
> status = "disabled";
> };
>
> However we could perhaps be more literate even if we don't use the macros?
>
> timer3: timer@40000000 {
> compatible = "st,stm32-timer";
> reg = <0x40000000 0x400>;
> interrupts = <28>;
> resets = <&rcc ((0x20*8) + 1)>;
> clocks = <&rcc ((0x40*8) + 1)>;
> status = "disabled";
> };
How about #address-cells = <2>, so you can do
resets = <&rcc 8 1>;
clocks = <&rcc 8 1>;
with the first cell being an index for the block and the second cell the
bit number within that block.
Arnd
On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
> For the all reset bits:
>
> clock idx = reset idx + 256
>
> The opposite is not true; the clock bits are a superset of the reset
> bits (the reset bits act on cells but some cells have >1 clock).
Ok, in that case, I would strongly recommend subtracting that 256
offset keeping the numbers the same, to remove the function-type
macros.
> >> However there are a couple of clocks without gating just before the
> >> clock reaches the peripheral:
> >>
> >> 1. A hard coded /8. I think this will have to be given a synthetic
> >> number.
> >
> > If this is just a divider, why not use a separate DT node for that,
> > like this:
> >
> > clock {
> > compatible = "fixed-factor-clock";
> > clocks = <&parentclk>;
> > #clock-cells = <0>;
> > clock-div = <8>;
> > clock-mult = <1>;
> > };
> >
> > No need to assign a number for this.
>
> I'd wondered about doing that.
>
> It will certainly work but it seemed a bit odd to me to have one (really
> tiny) part of the RCC cell included seperately in the platform
> description whilst all the complicated bits end up aggregated into the
> RCC cell.
>
> Is there much prior art that uses this type of trick to avoid having
> magic numbers into the bindings?
Are you sure that divider is actually part of the RCC?
> >> 2. Ungated dividers. For these I am using the bit offset of the LSB of
> >> the mux field.
> >
> > Do these ones also come with resets?
>
> No. They mostly run to the core and its intimate peripherals (i.e. only
> reset line comes from WDT).
Ok.
> >> So I think there is only one value that is completely unrelated to the
> >> hardware and will use a magic constant instead.
> >>
> >> I had planned to macros similar to the STM32F4_AxB_RESET() family of
> >> macros in both clk driver and DT in order to reuse the bit layouts from
> >> dt-bindings/mfd/stm32f4-rcc.h .
> >>
> >> Normal case would have looked like this:
> >>
> >> timer3: timer@40000000 {
> >> compatible = "st,stm32-timer";
> >> reg = <0x40000000 0x400>;
> >> interrupts = <28>;
> >> resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
> >> clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
> >> status = "disabled";
> >> };
> >>
> >> Without the macros it looks like this:
> >>
> >> timer3: timer@40000000 {
> >> compatible = "st,stm32-timer";
> >> reg = <0x40000000 0x400>;
> >> interrupts = <28>;
> >> resets = <&rcc 257>;
> >> clocks = <&rcc 513>;
> >> status = "disabled";
> >> };
> >>
> >> However we could perhaps be more literate even if we don't use the macros?
> >>
> >> timer3: timer@40000000 {
> >> compatible = "st,stm32-timer";
> >> reg = <0x40000000 0x400>;
> >> interrupts = <28>;
> >> resets = <&rcc ((0x20*8) + 1)>;
> >> clocks = <&rcc ((0x40*8) + 1)>;
> >> status = "disabled";
> >> };
> >
> > How about #address-cells = <2>, so you can do
> >
> > resets = <&rcc 8 1>;
> > clocks = <&rcc 8 1>;
> >
> > with the first cell being an index for the block and the second cell the
> > bit number within that block.
>
> That would suit me very well (although is the 0x20/0x40 not the 8 that
> we would need in the middle column).
We don't normally use register offsets in DT. The number 8 here instead
would indicate block 8, where each block is four bytes wide. Using the
same index here for reset and clock would also help readability.
Arnd
2015-05-13 17:28 GMT+02:00 Arnd Bergmann <[email protected]>:
> On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>> For the all reset bits:
>>
>> clock idx = reset idx + 256
>>
>> The opposite is not true; the clock bits are a superset of the reset
>> bits (the reset bits act on cells but some cells have >1 clock).
>
> Ok, in that case, I would strongly recommend subtracting that 256
> offset keeping the numbers the same, to remove the function-type
> macros.
>
>> >> However there are a couple of clocks without gating just before the
>> >> clock reaches the peripheral:
>> >>
>> >> 1. A hard coded /8. I think this will have to be given a synthetic
>> >> number.
>> >
>> > If this is just a divider, why not use a separate DT node for that,
>> > like this:
>> >
>> > clock {
>> > compatible = "fixed-factor-clock";
>> > clocks = <&parentclk>;
>> > #clock-cells = <0>;
>> > clock-div = <8>;
>> > clock-mult = <1>;
>> > };
>> >
>> > No need to assign a number for this.
>>
>> I'd wondered about doing that.
>>
>> It will certainly work but it seemed a bit odd to me to have one (really
>> tiny) part of the RCC cell included seperately in the platform
>> description whilst all the complicated bits end up aggregated into the
>> RCC cell.
>>
>> Is there much prior art that uses this type of trick to avoid having
>> magic numbers into the bindings?
>
> Are you sure that divider is actually part of the RCC?
>
>> >> 2. Ungated dividers. For these I am using the bit offset of the LSB of
>> >> the mux field.
>> >
>> > Do these ones also come with resets?
>>
>> No. They mostly run to the core and its intimate peripherals (i.e. only
>> reset line comes from WDT).
>
> Ok.
>
>> >> So I think there is only one value that is completely unrelated to the
>> >> hardware and will use a magic constant instead.
>> >>
>> >> I had planned to macros similar to the STM32F4_AxB_RESET() family of
>> >> macros in both clk driver and DT in order to reuse the bit layouts from
>> >> dt-bindings/mfd/stm32f4-rcc.h .
>> >>
>> >> Normal case would have looked like this:
>> >>
>> >> timer3: timer@40000000 {
>> >> compatible = "st,stm32-timer";
>> >> reg = <0x40000000 0x400>;
>> >> interrupts = <28>;
>> >> resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
>> >> clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
>> >> status = "disabled";
>> >> };
>> >>
>> >> Without the macros it looks like this:
>> >>
>> >> timer3: timer@40000000 {
>> >> compatible = "st,stm32-timer";
>> >> reg = <0x40000000 0x400>;
>> >> interrupts = <28>;
>> >> resets = <&rcc 257>;
>> >> clocks = <&rcc 513>;
>> >> status = "disabled";
>> >> };
>> >>
>> >> However we could perhaps be more literate even if we don't use the macros?
>> >>
>> >> timer3: timer@40000000 {
>> >> compatible = "st,stm32-timer";
>> >> reg = <0x40000000 0x400>;
>> >> interrupts = <28>;
>> >> resets = <&rcc ((0x20*8) + 1)>;
>> >> clocks = <&rcc ((0x40*8) + 1)>;
>> >> status = "disabled";
>> >> };
>> >
>> > How about #address-cells = <2>, so you can do
>> >
>> > resets = <&rcc 8 1>;
>> > clocks = <&rcc 8 1>;
>> >
>> > with the first cell being an index for the block and the second cell the
>> > bit number within that block.
>>
>> That would suit me very well (although is the 0x20/0x40 not the 8 that
>> we would need in the middle column).
>
> We don't normally use register offsets in DT. The number 8 here instead
> would indicate block 8, where each block is four bytes wide. Using the
> same index here for reset and clock would also help readability.
My view is that it makes the bindings usage very complex.
Also, it implies we have a specific compatible for stm32f429, whereas
we didn't need with my earlier proposals.
Indeed, the reset driver will need to know the offset of every reset
registers, because:
1. The AHB registers start at RCC offset 0x10 (up to 0x18)
2. The APB registers start at RCC offset 0x20 (up to 0x24).
We have a gap between AHB and APB registers, so how do we map the
index for the block you propose?
Should the gap be considered as a block, or we should skip it?
I'm afraid it will not be straightforward for a reset user to
understand how to use this bindings.
Either my v7 or v8 versions would have made possible to use a single
compatible for STM32 series.
If we stick with one of these, we could even think to have a "generic"
reset driver, as it could be compatible with sunxi driver bindings.
What is your view?
Kind regards,
Maxime
>
> Arnd
On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <[email protected]>:
> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
> >>
> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
> >> we would need in the middle column).
> >
> > We don't normally use register offsets in DT. The number 8 here instead
> > would indicate block 8, where each block is four bytes wide. Using the
> > same index here for reset and clock would also help readability.
>
> My view is that it makes the bindings usage very complex.
> Also, it implies we have a specific compatible for stm32f429, whereas
> we didn't need with my earlier proposals.
> Indeed, the reset driver will need to know the offset of every reset
> registers, because:
> 1. The AHB registers start at RCC offset 0x10 (up to 0x18)
> 2. The APB registers start at RCC offset 0x20 (up to 0x24).
> We have a gap between AHB and APB registers, so how do we map the
> index for the block you propose?
> Should the gap be considered as a block, or we should skip it?
>
> I'm afraid it will not be straightforward for a reset user to
> understand how to use this bindings.
>
> Either my v7 or v8 versions would have made possible to use a single
> compatible for STM32 series.
> If we stick with one of these, we could even think to have a "generic"
> reset driver, as it could be compatible with sunxi driver bindings.
We should definitely try to use the same compatible string for all of
them, and make a binding that is easy to use.
I haven't fully understood the requirements for the various parts that
are involved here. My understanding so far was that the driver could
use the index from the first cell and compute
void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
Are there parts that need something else? If the 0x10 offset is
different, we probably want a different compatible string, and I'd
consider it a different part at that point. If there are chips
that do not spread the clock from the reset by exactly 256 bits,
we could add a DT property in the rcc node for that.
Arnd
2015-05-13 18:37 GMT+02:00 Arnd Bergmann <[email protected]>:
> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <[email protected]>:
>> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>> >>
>> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
>> >> we would need in the middle column).
>> >
>> > We don't normally use register offsets in DT. The number 8 here instead
>> > would indicate block 8, where each block is four bytes wide. Using the
>> > same index here for reset and clock would also help readability.
>>
>> My view is that it makes the bindings usage very complex.
>> Also, it implies we have a specific compatible for stm32f429, whereas
>> we didn't need with my earlier proposals.
>> Indeed, the reset driver will need to know the offset of every reset
>> registers, because:
>> 1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>> 2. The APB registers start at RCC offset 0x20 (up to 0x24).
>> We have a gap between AHB and APB registers, so how do we map the
>> index for the block you propose?
>> Should the gap be considered as a block, or we should skip it?
>>
>> I'm afraid it will not be straightforward for a reset user to
>> understand how to use this bindings.
>>
>> Either my v7 or v8 versions would have made possible to use a single
>> compatible for STM32 series.
>> If we stick with one of these, we could even think to have a "generic"
>> reset driver, as it could be compatible with sunxi driver bindings.
>
> We should definitely try to use the same compatible string for all of
> them, and make a binding that is easy to use.
>
> I haven't fully understood the requirements for the various parts that
> are involved here. My understanding so far was that the driver could
> use the index from the first cell and compute
>
> void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
> void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
This calculation is true, but we have to take into account there is a
hole in the middle, between AHB3, and APB1 register:
AHB1RSTR : offset = 0x10, index = 0
AHB2RSTR : offset = 0x14, index = 1
AHB3RSTR : offset = 0x18, index = 2
<HOLE > : offset = 0x1c, index = 3
APB1RSTR : offset = 0x20, index = 4
APB2RSTR : offset = 0x24, index = 5
So we have to carefully document this hole in the bindings, maybe by
listing indexes in the documentation?
>
> Are there parts that need something else? If the 0x10 offset is
> different, we probably want a different compatible string, and I'd
> consider it a different part at that point. If there are chips
> that do not spread the clock from the reset by exactly 256 bits,
> we could add a DT property in the rcc node for that.
I will check other chips, to see if this is valid generally.
Thanks for your feedback,
Maxime
>
> Arnd
On Wednesday 13 May 2015 18:54:10 Maxime Coquelin wrote:
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
>
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE > : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
>
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?
I would only list the index definitions in the binding if they
are common across all chips using that binding.
>From what I see above, this is really regular, so it's possible
that others follow it as well, but it's also possible that another
chip completely screwed up that system because it didn't fit
otherwise.
Ideally the binding should follow closely what is documented
in the data sheet.
> > Are there parts that need something else? If the 0x10 offset is
> > different, we probably want a different compatible string, and I'd
> > consider it a different part at that point. If there are chips
> > that do not spread the clock from the reset by exactly 256 bits,
> > we could add a DT property in the rcc node for that.
>
> I will check other chips, to see if this is valid generally.
Ok.
Arnd
On 13/05/15 17:54, Maxime Coquelin wrote:
> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <[email protected]>:
>> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <[email protected]>:
>>>> On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>>>>>
>>>>> That would suit me very well (although is the 0x20/0x40 not the 8 that
>>>>> we would need in the middle column).
>>>>
>>>> We don't normally use register offsets in DT. The number 8 here instead
>>>> would indicate block 8, where each block is four bytes wide. Using the
>>>> same index here for reset and clock would also help readability.
>>>
>>> My view is that it makes the bindings usage very complex.
>>> Also, it implies we have a specific compatible for stm32f429, whereas
>>> we didn't need with my earlier proposals.
>>> Indeed, the reset driver will need to know the offset of every reset
>>> registers, because:
>>> 1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>> 2. The APB registers start at RCC offset 0x20 (up to 0x24).
>>> We have a gap between AHB and APB registers, so how do we map the
>>> index for the block you propose?
>>> Should the gap be considered as a block, or we should skip it?
>>>
>>> I'm afraid it will not be straightforward for a reset user to
>>> understand how to use this bindings.
>>>
>>> Either my v7 or v8 versions would have made possible to use a single
>>> compatible for STM32 series.
>>> If we stick with one of these, we could even think to have a "generic"
>>> reset driver, as it could be compatible with sunxi driver bindings.
>>
>> We should definitely try to use the same compatible string for all of
>> them, and make a binding that is easy to use.
>>
>> I haven't fully understood the requirements for the various parts that
>> are involved here. My understanding so far was that the driver could
>> use the index from the first cell and compute
>>
>> void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>> void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
... and equally importantly, only allows us to use hardware mappings for
the gated clocks.
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE > : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
>
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?
The register set has PLL, mux and dividers in the registers at 0x00,
0x04 and 0x08.
Many of these clocks can be kept out of DT entirely because they are
only there to feed other parts of the clock tree. However some of the
dividers flow directly into cells that appear in device tree (such as
the systick) and so we need to be able to reference them.
In other words the proposed mapping cannot allow us to express the
dividers properly (because the index would have to be negative):
void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
Thus I'd favour using different indexes for reset and clock bindings,
both using the naive mapping function:
void __iomem *reg = rcc_base + 4 * index
I think that its so much easier to check against the datasheet like
that. Admittedly is we follow the block-of-4-bytes idiom we have to
divide a hex number by four but thats not so hard and we end up with:
resets = <&rcc 8 0>;
clocks = <&rcc 16 0>;
At the end of the day if we say we want to follow the datasheet, lets be
do it in the most direct way properly.
Daniel.
PS
I've written a custom lookup function to to get from the DT index to an
offset into the struct clk *array I'm using. That means I don't care
much about any big holes in the register space.
>> Are there parts that need something else? If the 0x10 offset is
>> different, we probably want a different compatible string, and I'd
>> consider it a different part at that point. If there are chips
>> that do not spread the clock from the reset by exactly 256 bits,
>> we could add a DT property in the rcc node for that.
>
> I will check other chips, to see if this is valid generally.
>
> Thanks for your feedback,
> Maxime
>
>>
>> Arnd
On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
> On 13/05/15 17:54, Maxime Coquelin wrote:
> > 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <[email protected]>:
> >>
> >> We should definitely try to use the same compatible string for all of
> >> them, and make a binding that is easy to use.
> >>
> >> I haven't fully understood the requirements for the various parts that
> >> are involved here. My understanding so far was that the driver could
> >> use the index from the first cell and compute
> >>
> >> void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
> >> void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
> >
> > This calculation is true, but we have to take into account there is a
> > hole in the middle, between AHB3, and APB1 register:
>
> ... and equally importantly, only allows us to use hardware mappings for
> the gated clocks.
>
> > AHB1RSTR : offset = 0x10, index = 0
> > AHB2RSTR : offset = 0x14, index = 1
> > AHB3RSTR : offset = 0x18, index = 2
> > <HOLE > : offset = 0x1c, index = 3
> > APB1RSTR : offset = 0x20, index = 4
> > APB2RSTR : offset = 0x24, index = 5
> >
> > So we have to carefully document this hole in the bindings, maybe by
> > listing indexes in the documentation?
>
> The register set has PLL, mux and dividers in the registers at 0x00,
> 0x04 and 0x08.
>
> Many of these clocks can be kept out of DT entirely because they are
> only there to feed other parts of the clock tree. However some of the
> dividers flow directly into cells that appear in device tree (such as
> the systick) and so we need to be able to reference them.
>
> In other words the proposed mapping cannot allow us to express the
> dividers properly (because the index would have to be negative):
> void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>
> Thus I'd favour using different indexes for reset and clock bindings,
> both using the naive mapping function:
> void __iomem *reg = rcc_base + 4 * index
>
> I think that its so much easier to check against the datasheet like
> that. Admittedly is we follow the block-of-4-bytes idiom we have to
> divide a hex number by four but thats not so hard and we end up with:
>
> resets = <&rcc 8 0>;
> clocks = <&rcc 16 0>;
>
> At the end of the day if we say we want to follow the datasheet, lets be
> do it in the most direct way properly.
>
>
> PS
> I've written a custom lookup function to to get from the DT index to an
> offset into the struct clk *array I'm using. That means I don't care
> much about any big holes in the register space.
How about using the first cell to indicate the type (pll, mux, div, gate)
and the second cell for the number (between 0 and 256)? That way, the
gates numbers would match the reset numbers, and your internal mapping
function would look a bit nicer.
Arnd
2015-05-13 21:37 GMT+02:00 Arnd Bergmann <[email protected]>:
> On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
>> On 13/05/15 17:54, Maxime Coquelin wrote:
>> > 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <[email protected]>:
>> >>
>> >> We should definitely try to use the same compatible string for all of
>> >> them, and make a binding that is easy to use.
>> >>
>> >> I haven't fully understood the requirements for the various parts that
>> >> are involved here. My understanding so far was that the driver could
>> >> use the index from the first cell and compute
>> >>
>> >> void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>> >> void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>> >
>> > This calculation is true, but we have to take into account there is a
>> > hole in the middle, between AHB3, and APB1 register:
>>
>> ... and equally importantly, only allows us to use hardware mappings for
>> the gated clocks.
>>
>> > AHB1RSTR : offset = 0x10, index = 0
>> > AHB2RSTR : offset = 0x14, index = 1
>> > AHB3RSTR : offset = 0x18, index = 2
>> > <HOLE > : offset = 0x1c, index = 3
>> > APB1RSTR : offset = 0x20, index = 4
>> > APB2RSTR : offset = 0x24, index = 5
>> >
>> > So we have to carefully document this hole in the bindings, maybe by
>> > listing indexes in the documentation?
>>
>> The register set has PLL, mux and dividers in the registers at 0x00,
>> 0x04 and 0x08.
>>
>> Many of these clocks can be kept out of DT entirely because they are
>> only there to feed other parts of the clock tree. However some of the
>> dividers flow directly into cells that appear in device tree (such as
>> the systick) and so we need to be able to reference them.
>>
>> In other words the proposed mapping cannot allow us to express the
>> dividers properly (because the index would have to be negative):
>> void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>
>> Thus I'd favour using different indexes for reset and clock bindings,
>> both using the naive mapping function:
>> void __iomem *reg = rcc_base + 4 * index
>>
>> I think that its so much easier to check against the datasheet like
>> that. Admittedly is we follow the block-of-4-bytes idiom we have to
>> divide a hex number by four but thats not so hard and we end up with:
>>
>> resets = <&rcc 8 0>;
>> clocks = <&rcc 16 0>;
>>
>> At the end of the day if we say we want to follow the datasheet, lets be
>> do it in the most direct way properly.
Daniel, I'm fine with your proposal.
Doing that, we can have a single compatible string for stm32 family,
even if the reset start offset change between two chips.
>>
>>
>> PS
>> I've written a custom lookup function to to get from the DT index to an
>> offset into the struct clk *array I'm using. That means I don't care
>> much about any big holes in the register space.
>
> How about using the first cell to indicate the type (pll, mux, div, gate)
> and the second cell for the number (between 0 and 256)? That way, the
> gates numbers would match the reset numbers, and your internal mapping
> function would look a bit nicer.
That's another option.
In this case, for reset, we will only need one cell, right?
Regards,
Maxime
>
> Arnd
On 14/05/15 17:34, Maxime Coquelin wrote:
> 2015-05-13 21:37 GMT+02:00 Arnd Bergmann <[email protected]>:
>> On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
>>> On 13/05/15 17:54, Maxime Coquelin wrote:
>>>> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <[email protected]>:
>>>>>
>>>>> We should definitely try to use the same compatible string for all of
>>>>> them, and make a binding that is easy to use.
>>>>>
>>>>> I haven't fully understood the requirements for the various parts that
>>>>> are involved here. My understanding so far was that the driver could
>>>>> use the index from the first cell and compute
>>>>>
>>>>> void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>>>> void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>>>
>>>> This calculation is true, but we have to take into account there is a
>>>> hole in the middle, between AHB3, and APB1 register:
>>>
>>> ... and equally importantly, only allows us to use hardware mappings for
>>> the gated clocks.
>>>
>>>> AHB1RSTR : offset = 0x10, index = 0
>>>> AHB2RSTR : offset = 0x14, index = 1
>>>> AHB3RSTR : offset = 0x18, index = 2
>>>> <HOLE > : offset = 0x1c, index = 3
>>>> APB1RSTR : offset = 0x20, index = 4
>>>> APB2RSTR : offset = 0x24, index = 5
>>>>
>>>> So we have to carefully document this hole in the bindings, maybe by
>>>> listing indexes in the documentation?
>>>
>>> The register set has PLL, mux and dividers in the registers at 0x00,
>>> 0x04 and 0x08.
>>>
>>> Many of these clocks can be kept out of DT entirely because they are
>>> only there to feed other parts of the clock tree. However some of the
>>> dividers flow directly into cells that appear in device tree (such as
>>> the systick) and so we need to be able to reference them.
>>>
>>> In other words the proposed mapping cannot allow us to express the
>>> dividers properly (because the index would have to be negative):
>>> void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>>
>>> Thus I'd favour using different indexes for reset and clock bindings,
>>> both using the naive mapping function:
>>> void __iomem *reg = rcc_base + 4 * index
>>>
>>> I think that its so much easier to check against the datasheet like
>>> that. Admittedly is we follow the block-of-4-bytes idiom we have to
>>> divide a hex number by four but thats not so hard and we end up with:
>>>
>>> resets = <&rcc 8 0>;
>>> clocks = <&rcc 16 0>;
>>>
>>> At the end of the day if we say we want to follow the datasheet, lets be
>>> do it in the most direct way properly.
>
> Daniel, I'm fine with your proposal.
> Doing that, we can have a single compatible string for stm32 family,
> even if the reset start offset change between two chips.
>
>>> PS
>>> I've written a custom lookup function to to get from the DT index to an
>>> offset into the struct clk *array I'm using. That means I don't care
>>> much about any big holes in the register space.
>>
>> How about using the first cell to indicate the type (pll, mux, div, gate)
>> and the second cell for the number (between 0 and 256)? That way, the
>> gates numbers would match the reset numbers, and your internal mapping
>> function would look a bit nicer.
>
> That's another option.
> In this case, for reset, we will only need one cell, right?
I think so. For the reset, this is essentially no change versus v7
except for applying an offset of 0x10 when calculating the base address.
I won't get time to polish up the clk driver this weekend but I will try
to write a documentation file proposing some clock bindings for you to
look at.
Daniel.
On Saturday 09 May 2015 09:53:54 Maxime Coquelin wrote:
> STMicrolectronics's STM32 series is a family of Cortex-M
> microcontrollers. It is used in various applications, and
> proposes a wide range of peripherals.
>
> Tested-by: Chanwoo Choi <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
Applied to next/soc, thanks
Arnd
On Saturday 09 May 2015 09:53:58 Maxime Coquelin wrote:
> Add a MAINTAINER entry covering all STM32 machine and drivers files.
>
> Signed-off-by: Maxime Coquelin <[email protected]>
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2e5bbc0..858d821 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1479,6 +1479,14 @@ F: drivers/usb/host/ehci-st.c
> F: drivers/usb/host/ohci-st.c
> F: drivers/ata/ahci_st.c
>
> +ARM/STM32 ARCHITECTURE
> +M: Maxime Coquelin <[email protected]>
> +L: [email protected] (moderated for non-subscribers)
> +S: Maintained
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mcoquelin/stm32.git
> +N: stm32
> +F: drivers/clocksource/armv7m_systick.c
> +
> ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
> M: Lennert Buytenhek <[email protected]>
> L: [email protected] (moderated for non-subscribers)
>
Applied to next/soc, thanks!
Arnd
On Saturday 09 May 2015 09:53:55 Maxime Coquelin wrote:
> Tested-by: Chanwoo Choi <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
> ---
> arch/arm/boot/dts/armv7-m.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
Applied to next/dt. I've left out patch 14 for now, until we have a new version.
Arnd
On Saturday 09 May 2015 09:53:57 Maxime Coquelin wrote:
> This patch adds a new config for STM32 MCUs.
> STM32F429 Discovery board boots successfully with this config applied.
>
> Tested-by: Chanwoo Choi <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
>
Applied to next/defconfig, thanks!
Arnd
Hi Michal,
2015-05-09 9:53 GMT+02:00 Maxime Coquelin <[email protected]>:
> When Kernel is executed in place from ROM, the symbol addresses can be
> lower than the page offset.
>
> Tested-by: Chanwoo Choi <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
> ---
> scripts/link-vmlinux.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index 86a4fe7..b055d9d 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -82,7 +82,7 @@ kallsyms()
> kallsymopt="${kallsymopt} --all-symbols"
> fi
>
> - if [ -n "${CONFIG_ARM}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
> + if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
> kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
> fi
>
> --
> 1.9.1
>
The get_maintainer.pl does not explicitly provide your name as
maintainer for this file.
But looking at MAINTAINERS file, I think you are the one for it.
Do you confirm?
If this is the case and you agree with the patch, could you consider
taking it for v4.2?
Thanks in advance,
Maxime
Hi Daniel,
2015-05-09 9:53 GMT+02:00 Maxime Coquelin <[email protected]>:
> This patch adds clocksource support for ARMv7-M's System timer,
> also known as SysTick.
>
> Tested-by: Chanwoo Choi <[email protected]>
> Acked-by: Daniel Lezcano <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
> ---
> drivers/clocksource/Kconfig | 7 ++++
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 87 insertions(+)
> create mode 100644 drivers/clocksource/armv7m_systick.c
>
Could you consider applying this patch and its dt-bindings
documentation (patch 3/16) on your tree for v4.2?
Thanks in advance,
Maxime
Hi Arnd, Daniel,
2015-05-13 18:54 GMT+02:00 Maxime Coquelin <[email protected]>:
> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <[email protected]>:
>> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <[email protected]>:
>>> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>>> >>
>>> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
>>> >> we would need in the middle column).
>>> >
>>> > We don't normally use register offsets in DT. The number 8 here instead
>>> > would indicate block 8, where each block is four bytes wide. Using the
>>> > same index here for reset and clock would also help readability.
>>>
>>> My view is that it makes the bindings usage very complex.
>>> Also, it implies we have a specific compatible for stm32f429, whereas
>>> we didn't need with my earlier proposals.
>>> Indeed, the reset driver will need to know the offset of every reset
>>> registers, because:
>>> 1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>> 2. The APB registers start at RCC offset 0x20 (up to 0x24).
>>> We have a gap between AHB and APB registers, so how do we map the
>>> index for the block you propose?
>>> Should the gap be considered as a block, or we should skip it?
>>>
>>> I'm afraid it will not be straightforward for a reset user to
>>> understand how to use this bindings.
>>>
>>> Either my v7 or v8 versions would have made possible to use a single
>>> compatible for STM32 series.
>>> If we stick with one of these, we could even think to have a "generic"
>>> reset driver, as it could be compatible with sunxi driver bindings.
>>
>> We should definitely try to use the same compatible string for all of
>> them, and make a binding that is easy to use.
>>
>> I haven't fully understood the requirements for the various parts that
>> are involved here. My understanding so far was that the driver could
>> use the index from the first cell and compute
>>
>> void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>> void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
>
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE > : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
>
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?
>
>>
>> Are there parts that need something else? If the 0x10 offset is
>> different, we probably want a different compatible string, and I'd
>> consider it a different part at that point. If there are chips
>> that do not spread the clock from the reset by exactly 256 bits,
>> we could add a DT property in the rcc node for that.
>
> I will check other chips, to see if this is valid generally.
I checked on other chips, and the assumption looks valid generally.
Kind regards,
Maxime
>
> Thanks for your feedback,
> Maxime
>
>>
>> Arnd
On 05/18/2015 01:55 PM, Maxime Coquelin wrote:
> Hi Daniel,
>
> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <[email protected]>:
>> This patch adds clocksource support for ARMv7-M's System timer,
>> also known as SysTick.
>>
>> Tested-by: Chanwoo Choi <[email protected]>
>> Acked-by: Daniel Lezcano <[email protected]>
>> Signed-off-by: Maxime Coquelin <[email protected]>
>> ---
>> drivers/clocksource/Kconfig | 7 ++++
>> drivers/clocksource/Makefile | 1 +
>> drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 87 insertions(+)
>> create mode 100644 drivers/clocksource/armv7m_systick.c
>>
>
> Could you consider applying this patch and its dt-bindings
> documentation (patch 3/16) on your tree for v4.2?
Patches applied for 4.2.
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
2015-05-18 14:49 GMT+02:00 Daniel Lezcano <[email protected]>:
> On 05/18/2015 01:55 PM, Maxime Coquelin wrote:
>>
>> Hi Daniel,
>>
>> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <[email protected]>:
>>>
>>> This patch adds clocksource support for ARMv7-M's System timer,
>>> also known as SysTick.
>>>
>>> Tested-by: Chanwoo Choi <[email protected]>
>>> Acked-by: Daniel Lezcano <[email protected]>
>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>> ---
>>> drivers/clocksource/Kconfig | 7 ++++
>>> drivers/clocksource/Makefile | 1 +
>>> drivers/clocksource/armv7m_systick.c | 79
>>> ++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 87 insertions(+)
>>> create mode 100644 drivers/clocksource/armv7m_systick.c
>>>
>>
>> Could you consider applying this patch and its dt-bindings
>> documentation (patch 3/16) on your tree for v4.2?
>
>
> Patches applied for 4.2.
Thanks Daniel!
>
> Thanks
>
> -- Daniel
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
> The drivers detects whether the time is 16 or 32 bits, and applies a
> 1024 prescaler value if it is 16 bits.
>
> Reviewed-by: Linus Walleij <[email protected]>
> Tested-by: Chanwoo Choi <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
> ---
> drivers/clocksource/Kconfig | 8 ++
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-stm32.c | 184 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 193 insertions(+)
> create mode 100644 drivers/clocksource/timer-stm32.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index bf9364c..2443520 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
> Support to use the timers of EFM32 SoCs as clock source and clock
> event device.
>
> +config CLKSRC_STM32
> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
Are the interactive bool and the 'COMPILE_TEST' necessary ?
> + select CLKSRC_MMIO
> + default ARCH_STM32
> + help
> + Support to use the timers of STM32 SoCs as clock event device.
> +
> config ARM_ARCH_TIMER
> bool
> select CLKSRC_OF if OF
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index d510c54..888a7df 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_ARCH_NSPIRE) += zevio-timer.o
> obj-$(CONFIG_ARCH_BCM_MOBILE) += bcm_kona_timer.o
> obj-$(CONFIG_CADENCE_TTC_TIMER) += cadence_ttc_timer.o
> obj-$(CONFIG_CLKSRC_EFM32) += time-efm32.o
> +obj-$(CONFIG_CLKSRC_STM32) += timer-stm32.o
> obj-$(CONFIG_CLKSRC_EXYNOS_MCT) += exynos_mct.o
> obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
> obj-$(CONFIG_FSL_FTM_TIMER) += fsl_ftm_timer.o
> diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
> new file mode 100644
> index 0000000..fad2e2e
> --- /dev/null
> +++ b/drivers/clocksource/timer-stm32.c
> @@ -0,0 +1,184 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author: Maxime Coquelin <[email protected]>
> + * License terms: GNU General Public License (GPL), version 2
> + *
> + * Inspired by time-efm32.c from Uwe Kleine-Koenig
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/clocksource.h>
> +#include <linux/clockchips.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +
> +#define TIM_CR1 0x00
> +#define TIM_DIER 0x0c
> +#define TIM_SR 0x10
> +#define TIM_EGR 0x14
> +#define TIM_PSC 0x28
> +#define TIM_ARR 0x2c
> +
> +#define TIM_CR1_CEN BIT(0)
> +#define TIM_CR1_OPM BIT(3)
> +#define TIM_CR1_ARPE BIT(7)
> +
> +#define TIM_DIER_UIE BIT(0)
> +
> +#define TIM_SR_UIF BIT(0)
> +
> +#define TIM_EGR_UG BIT(0)
> +
> +struct stm32_clock_event_ddata {
> + struct clock_event_device evtdev;
> + unsigned periodic_top;
> + void __iomem *base;
> +};
> +
> +static void stm32_clock_event_set_mode(enum clock_event_mode mode,
> + struct clock_event_device *evtdev)
> +{
> + struct stm32_clock_event_ddata *data =
> + container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> + void *base = data->base;
> +
> + switch (mode) {
> + case CLOCK_EVT_MODE_PERIODIC:
> + writel_relaxed(data->periodic_top, base + TIM_ARR);
> + writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, base + TIM_CR1);
> + break;
> +
> + case CLOCK_EVT_MODE_ONESHOT:
> + default:
> + writel_relaxed(0, base + TIM_CR1);
> + break;
> + }
> +}
> +
> +static int stm32_clock_event_set_next_event(unsigned long evt,
> + struct clock_event_device *evtdev)
> +{
> + struct stm32_clock_event_ddata *data =
> + container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> +
> + writel_relaxed(evt, data->base + TIM_ARR);
> + writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
> + data->base + TIM_CR1);
> +
> + return 0;
> +}
> +
> +static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
> +{
> + struct stm32_clock_event_ddata *data = dev_id;
> +
> + writel_relaxed(0, data->base + TIM_SR);
> +
> + data->evtdev.event_handler(&data->evtdev);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static struct stm32_clock_event_ddata clock_event_ddata = {
> + .evtdev = {
> + .name = "stm32 clockevent",
> + .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
> + .set_mode = stm32_clock_event_set_mode,
> + .set_next_event = stm32_clock_event_set_next_event,
> + .rating = 200,
> + },
> +};
> +
> +static void __init stm32_clockevent_init(struct device_node *np)
> +{
> + struct stm32_clock_event_ddata *data = &clock_event_ddata;
> + struct clk *clk;
> + struct reset_control *rstc;
> + unsigned long rate, max_delta;
> + int irq, ret, bits, prescaler = 1;
> +
> + clk = of_clk_get(np, 0);
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + pr_err("failed to get clock for clockevent (%d)\n", ret);
> + goto err_clk_get;
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret) {
> + pr_err("failed to enable timer clock for clockevent (%d)\n",
> + ret);
> + goto err_clk_enable;
> + }
> +
> + rate = clk_get_rate(clk);
> +
> + rstc = of_reset_control_get(np, NULL);
> + if (!IS_ERR(rstc)) {
> + reset_control_assert(rstc);
> + reset_control_deassert(rstc);
> + }
> +
> + data->base = of_iomap(np, 0);
> + if (!data->base) {
> + pr_err("failed to map registers for clockevent\n");
> + goto err_iomap;
> + }
> +
> + irq = irq_of_parse_and_map(np, 0);
> + if (!irq) {
> + pr_err("%s: failed to get irq.\n", np->full_name);
> + goto err_get_irq;
> + }
> +
> + /* Detect whether the timer is 16 or 32 bits */
> + writel_relaxed(~0UL, data->base + TIM_ARR);
> + max_delta = readl_relaxed(data->base + TIM_ARR);
> + if (max_delta == ~0UL) {
> + prescaler = 1;
> + bits = 32;
> + } else {
> + prescaler = 1024;
> + bits = 16;
> + }
> + writel_relaxed(0, data->base + TIM_ARR);
> +
> + writel_relaxed(prescaler - 1, data->base + TIM_PSC);
> + writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
> + writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
> + writel_relaxed(0, data->base + TIM_SR);
> +
> + data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
> +
> + clockevents_config_and_register(&data->evtdev,
> + DIV_ROUND_CLOSEST(rate, prescaler),
> + 0x1, max_delta);
> +
> + ret = request_irq(irq, stm32_clock_event_handler, IRQF_TIMER,
> + "stm32 clockevent", data);
> + if (ret) {
> + pr_err("%s: failed to request irq.\n", np->full_name);
> + goto err_get_irq;
> + }
> +
> + pr_info("%s: STM32 clockevent driver initialized (%d bits)\n",
> + np->full_name, bits);
> +
> + return;
> +
> +err_get_irq:
> + iounmap(data->base);
> +err_iomap:
> + clk_disable_unprepare(clk);
> +err_clk_enable:
> + clk_put(clk);
> +err_clk_get:
> + return;
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
2015-05-18 15:10 GMT+02:00 Daniel Lezcano <[email protected]>:
> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>
>> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
>> The drivers detects whether the time is 16 or 32 bits, and applies a
>> 1024 prescaler value if it is 16 bits.
>>
>> Reviewed-by: Linus Walleij <[email protected]>
>> Tested-by: Chanwoo Choi <[email protected]>
>> Signed-off-by: Maxime Coquelin <[email protected]>
>> ---
>> drivers/clocksource/Kconfig | 8 ++
>> drivers/clocksource/Makefile | 1 +
>> drivers/clocksource/timer-stm32.c | 184
>> ++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 193 insertions(+)
>> create mode 100644 drivers/clocksource/timer-stm32.c
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index bf9364c..2443520 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>> Support to use the timers of EFM32 SoCs as clock source and
>> clock
>> event device.
>>
>> +config CLKSRC_STM32
>> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>
>
> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>
The interactive bool is necessary if we want to be able to
select/deselect it in COMPILE_TEST configuration.
And personnaly, I think COMPILE_TEST use makes sense.
Note that other timer drivers are doing the same thing today
(CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
Do you have a specific concern regarding COMPILE_TEST?
Kind regards,
Maxime
On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <[email protected]>:
>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>
>>> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>> 1024 prescaler value if it is 16 bits.
>>>
>>> Reviewed-by: Linus Walleij <[email protected]>
>>> Tested-by: Chanwoo Choi <[email protected]>
>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>> ---
>>> drivers/clocksource/Kconfig | 8 ++
>>> drivers/clocksource/Makefile | 1 +
>>> drivers/clocksource/timer-stm32.c | 184
>>> ++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 193 insertions(+)
>>> create mode 100644 drivers/clocksource/timer-stm32.c
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index bf9364c..2443520 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>> Support to use the timers of EFM32 SoCs as clock source and
>>> clock
>>> event device.
>>>
>>> +config CLKSRC_STM32
>>> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>
>>
>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>
>
> The interactive bool is necessary if we want to be able to
> select/deselect it in COMPILE_TEST configuration.
> And personnaly, I think COMPILE_TEST use makes sense.
>
> Note that other timer drivers are doing the same thing today
> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>
> Do you have a specific concern regarding COMPILE_TEST?
Actually, we try to keep the timer selection non-interactive and let the
platform's Kconfig to select the timer.
I like when the code is consistent. The COMPILE_TEST was introduced and
created a precedence. I would like to get rid of the interactive timer
selection but I did not have time to go through this yet.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
2015-05-19 10:16 GMT+02:00 Daniel Lezcano <[email protected]>:
> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>
>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <[email protected]>:
>>>
>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>> prescalers.
>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>> 1024 prescaler value if it is 16 bits.
>>>>
>>>> Reviewed-by: Linus Walleij <[email protected]>
>>>> Tested-by: Chanwoo Choi <[email protected]>
>>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>>> ---
>>>> drivers/clocksource/Kconfig | 8 ++
>>>> drivers/clocksource/Makefile | 1 +
>>>> drivers/clocksource/timer-stm32.c | 184
>>>> ++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 193 insertions(+)
>>>> create mode 100644 drivers/clocksource/timer-stm32.c
>>>>
>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>> index bf9364c..2443520 100644
>>>> --- a/drivers/clocksource/Kconfig
>>>> +++ b/drivers/clocksource/Kconfig
>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>> Support to use the timers of EFM32 SoCs as clock source and
>>>> clock
>>>> event device.
>>>>
>>>> +config CLKSRC_STM32
>>>> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>
>>>
>>>
>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>
>>
>> The interactive bool is necessary if we want to be able to
>> select/deselect it in COMPILE_TEST configuration.
>> And personnaly, I think COMPILE_TEST use makes sense.
>>
>> Note that other timer drivers are doing the same thing today
>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>
>> Do you have a specific concern regarding COMPILE_TEST?
>
>
> Actually, we try to keep the timer selection non-interactive and let the
> platform's Kconfig to select the timer.
Ok.
>
> I like when the code is consistent. The COMPILE_TEST was introduced and
> created a precedence. I would like to get rid of the interactive timer
> selection but I did not have time to go through this yet.
Indeed, consistency is important.
On my side, I don't have a strong opinion regarding the COMPILE_TEST thing.
IMHO, it is more a subsystem's maintainer choice.
So, if as a maintainer you don't use it and prefer not supporting it,
I'm fine to provide you a new version without COMPILE_TEST.
Doing that, the interactive selection will disappear too.
I can provide you a new version this evenning.
Best regards,
Maxime
>
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <[email protected]>:
>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>
>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <[email protected]>:
>>>>
>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>> prescalers.
>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>> 1024 prescaler value if it is 16 bits.
>>>>>
>>>>> Reviewed-by: Linus Walleij <[email protected]>
>>>>> Tested-by: Chanwoo Choi <[email protected]>
>>>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>>>> ---
>>>>> drivers/clocksource/Kconfig | 8 ++
>>>>> drivers/clocksource/Makefile | 1 +
>>>>> drivers/clocksource/timer-stm32.c | 184
>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 193 insertions(+)
>>>>> create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>
>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>> index bf9364c..2443520 100644
>>>>> --- a/drivers/clocksource/Kconfig
>>>>> +++ b/drivers/clocksource/Kconfig
>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>> Support to use the timers of EFM32 SoCs as clock source and
>>>>> clock
>>>>> event device.
>>>>>
>>>>> +config CLKSRC_STM32
>>>>> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>
>>>>
>>>>
>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>
>>>
>>> The interactive bool is necessary if we want to be able to
>>> select/deselect it in COMPILE_TEST configuration.
>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>
>>> Note that other timer drivers are doing the same thing today
>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>
>>> Do you have a specific concern regarding COMPILE_TEST?
>>
>>
>> Actually, we try to keep the timer selection non-interactive and let the
>> platform's Kconfig to select the timer.
>
> Ok.
>
>>
>> I like when the code is consistent. The COMPILE_TEST was introduced and
>> created a precedence. I would like to get rid of the interactive timer
>> selection but I did not have time to go through this yet.
>
> Indeed, consistency is important.
> On my side, I don't have a strong opinion regarding the COMPILE_TEST thing.
> IMHO, it is more a subsystem's maintainer choice.
>
> So, if as a maintainer you don't use it and prefer not supporting it,
> I'm fine to provide you a new version without COMPILE_TEST.
> Doing that, the interactive selection will disappear too.
>
> I can provide you a new version this evenning.
Ok, great.
Thanks
-- Daniel
>>
>>
>>
>> --
>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
2015-05-19 11:06 GMT+02:00 Daniel Lezcano <[email protected]>:
> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>
>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <[email protected]>:
>>>
>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <[email protected]>:
>>>>>
>>>>>
>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>> prescalers.
>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>
>>>>>> Reviewed-by: Linus Walleij <[email protected]>
>>>>>> Tested-by: Chanwoo Choi <[email protected]>
>>>>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>>>>> ---
>>>>>> drivers/clocksource/Kconfig | 8 ++
>>>>>> drivers/clocksource/Makefile | 1 +
>>>>>> drivers/clocksource/timer-stm32.c | 184
>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>> 3 files changed, 193 insertions(+)
>>>>>> create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>
>>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>>> index bf9364c..2443520 100644
>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>> Support to use the timers of EFM32 SoCs as clock source
>>>>>> and
>>>>>> clock
>>>>>> event device.
>>>>>>
>>>>>> +config CLKSRC_STM32
>>>>>> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>
>>>>
>>>> The interactive bool is necessary if we want to be able to
>>>> select/deselect it in COMPILE_TEST configuration.
>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>
>>>> Note that other timer drivers are doing the same thing today
>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>
>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>
>>>
>>>
>>> Actually, we try to keep the timer selection non-interactive and let the
>>> platform's Kconfig to select the timer.
>>
>>
>> Ok.
>>
>>>
>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>> created a precedence. I would like to get rid of the interactive timer
>>> selection but I did not have time to go through this yet.
>>
>>
>> Indeed, consistency is important.
>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>> thing.
>> IMHO, it is more a subsystem's maintainer choice.
>>
>> So, if as a maintainer you don't use it and prefer not supporting it,
>> I'm fine to provide you a new version without COMPILE_TEST.
>> Doing that, the interactive selection will disappear too.
>>
>> I can provide you a new version this evenning.
>
>
> Ok, great.
Is the below Kconfig entry fine for you?
config CLKSRC_STM32
def_bool y if ARCH_STM32
select CLKSRC_MMIO
Best regards,
Maxime
>
> Thanks
> -- Daniel
>
>
>>>
>>>
>>>
>>> --
>>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>
>>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <[email protected]>:
>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>
>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <[email protected]>:
>>>>
>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <[email protected]>:
>>>>>>
>>>>>>
>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>> prescalers.
>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>
>>>>>>> Reviewed-by: Linus Walleij <[email protected]>
>>>>>>> Tested-by: Chanwoo Choi <[email protected]>
>>>>>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>>>>>> ---
>>>>>>> drivers/clocksource/Kconfig | 8 ++
>>>>>>> drivers/clocksource/Makefile | 1 +
>>>>>>> drivers/clocksource/timer-stm32.c | 184
>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>> 3 files changed, 193 insertions(+)
>>>>>>> create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>
>>>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>>>> index bf9364c..2443520 100644
>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>> Support to use the timers of EFM32 SoCs as clock source
>>>>>>> and
>>>>>>> clock
>>>>>>> event device.
>>>>>>>
>>>>>>> +config CLKSRC_STM32
>>>>>>> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>
>>>>>
>>>>> The interactive bool is necessary if we want to be able to
>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>
>>>>> Note that other timer drivers are doing the same thing today
>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>
>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>
>>>>
>>>>
>>>> Actually, we try to keep the timer selection non-interactive and let the
>>>> platform's Kconfig to select the timer.
>>>
>>>
>>> Ok.
>>>
>>>>
>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>> created a precedence. I would like to get rid of the interactive timer
>>>> selection but I did not have time to go through this yet.
>>>
>>>
>>> Indeed, consistency is important.
>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>> thing.
>>> IMHO, it is more a subsystem's maintainer choice.
>>>
>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>> I'm fine to provide you a new version without COMPILE_TEST.
>>> Doing that, the interactive selection will disappear too.
>>>
>>> I can provide you a new version this evenning.
>>
>>
>> Ok, great.
>
> Is the below Kconfig entry fine for you?
>
> config CLKSRC_STM32
> def_bool y if ARCH_STM32
> select CLKSRC_MMIO
config CLKSRC_STM32
bool
select CLKSRC_MMIO
and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> Best regards,
> Maxime
>
>
>>
>> Thanks
>> -- Daniel
>>
>>
>>>>
>>>>
>>>>
>>>> --
>>>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>>
>>>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>
>>
>>
>> --
>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
2015-05-19 11:59 GMT+02:00 Daniel Lezcano <[email protected]>:
> On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
>>
>> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <[email protected]>:
>>>
>>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <[email protected]>:
>>>>>
>>>>>
>>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <[email protected]>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>>> prescalers.
>>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>>
>>>>>>>> Reviewed-by: Linus Walleij <[email protected]>
>>>>>>>> Tested-by: Chanwoo Choi <[email protected]>
>>>>>>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>>>>>>> ---
>>>>>>>> drivers/clocksource/Kconfig | 8 ++
>>>>>>>> drivers/clocksource/Makefile | 1 +
>>>>>>>> drivers/clocksource/timer-stm32.c | 184
>>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>>> 3 files changed, 193 insertions(+)
>>>>>>>> create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>>
>>>>>>>> diff --git a/drivers/clocksource/Kconfig
>>>>>>>> b/drivers/clocksource/Kconfig
>>>>>>>> index bf9364c..2443520 100644
>>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>>> Support to use the timers of EFM32 SoCs as clock source
>>>>>>>> and
>>>>>>>> clock
>>>>>>>> event device.
>>>>>>>>
>>>>>>>> +config CLKSRC_STM32
>>>>>>>> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>>> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>>
>>>>>>
>>>>>> The interactive bool is necessary if we want to be able to
>>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>>
>>>>>> Note that other timer drivers are doing the same thing today
>>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>>
>>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Actually, we try to keep the timer selection non-interactive and let
>>>>> the
>>>>> platform's Kconfig to select the timer.
>>>>
>>>>
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>>> created a precedence. I would like to get rid of the interactive timer
>>>>> selection but I did not have time to go through this yet.
>>>>
>>>>
>>>>
>>>> Indeed, consistency is important.
>>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>>> thing.
>>>> IMHO, it is more a subsystem's maintainer choice.
>>>>
>>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>>> I'm fine to provide you a new version without COMPILE_TEST.
>>>> Doing that, the interactive selection will disappear too.
>>>>
>>>> I can provide you a new version this evenning.
>>>
>>>
>>>
>>> Ok, great.
>>
>>
>> Is the below Kconfig entry fine for you?
>>
>> config CLKSRC_STM32
>> def_bool y if ARCH_STM32
>> select CLKSRC_MMIO
>
>
> config CLKSRC_STM32
> bool
> select CLKSRC_MMIO
>
> and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
the one intruducing ARCH_STM32.
Thanks,
Maxime
>
>
>> Best regards,
>> Maxime
>>
>>
>>>
>>> Thanks
>>> -- Daniel
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM
>>>>> SoCs
>>>>>
>>>>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>>
>>>
>>>
>>> --
>>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>
>>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
On Tuesday 19 May 2015 12:02:59 Maxime Coquelin wrote:
> >
> > config CLKSRC_STM32
> > bool
> > select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
>
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.
>
>
Please also make it possible to select this driver on other architectures
with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
Arnd
On Tue, 19 May 2015, Maxime Coquelin wrote:
> 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <[email protected]>:
> >> Is the below Kconfig entry fine for you?
> >>
> >> config CLKSRC_STM32
> >> def_bool y if ARCH_STM32
> >> select CLKSRC_MMIO
> >
> >
> > config CLKSRC_STM32
> > bool
> > select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
>
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.
Folks, can you please trim your replies. It's a PITA to scroll down
through several pages to find a single line of content.
Thanks,
tglx
On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
> On Tue, 19 May 2015, Maxime Coquelin wrote:
> > 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <[email protected]>:
> > >> Is the below Kconfig entry fine for you?
> > >>
> > >> config CLKSRC_STM32
> > >> def_bool y if ARCH_STM32
> > >> select CLKSRC_MMIO
> > >
> > >
> > > config CLKSRC_STM32
> > > bool
> > > select CLKSRC_MMIO
> > >
> > > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> >
> > Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> > the one intruducing ARCH_STM32.
>
> Folks, can you please trim your replies. It's a PITA to scroll down
> through several pages to find a single line of content.
Absolutely right. Too many people do not do this, and it's a waste of
readers time. Maybe we should start ignoring emails which contain only
quoted mail in the first 50 lines.
Also, cutting the rest of the email below the point which you've finished
replying is good etiquette as well. I've seen a number of posts where
people have added their signature mid-mail and left a huge chunk of quoted
mail below. That's just not on either.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
2015-05-19 15:00 GMT+02:00 Russell King - ARM Linux <[email protected]>:
> On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
>> Folks, can you please trim your replies. It's a PITA to scroll down
>> through several pages to find a single line of content.
>
> Absolutely right. Too many people do not do this, and it's a waste of
> readers time. Maybe we should start ignoring emails which contain only
> quoted mail in the first 50 lines.
>
> Also, cutting the rest of the email below the point which you've finished
> replying is good etiquette as well. I've seen a number of posts where
> people have added their signature mid-mail and left a huge chunk of quoted
> mail below. That's just not on either.
>
Ok, I will take care of that.
Sorry for the inconvenience,
Maxime
2015-05-19 12:55 GMT+02:00 Arnd Bergmann <[email protected]>:
> Please also make it possible to select this driver on other architectures
> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
You proposal is to revert back to the original patch, except that
ARCH_STM32 should select CLKSRC_STM32, right?
Daniel, what do you think?
Regards,
Maxime
On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <[email protected]>:
>> Please also make it possible to select this driver on other architectures
>> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
>
> You proposal is to revert back to the original patch, except that
> ARCH_STM32 should select CLKSRC_STM32, right?
>
> Daniel, what do you think?
It is not exactly as the initial patch.
I think Arnd is proposing:
config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if COMPILE_TEST
select CLKSRC_MMIO
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
On Tuesday 19 May 2015 15:49:52 Daniel Lezcano wrote:
> On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> > 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <[email protected]>:
> >> Please also make it possible to select this driver on other architectures
> >> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
> >
> > You proposal is to revert back to the original patch, except that
> > ARCH_STM32 should select CLKSRC_STM32, right?
> >
> > Daniel, what do you think?
>
> It is not exactly as the initial patch.
>
> I think Arnd is proposing:
>
> config CLKSRC_STM32
> bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> select CLKSRC_MMIO
Yes, that's fine, although we might also need a 'depends on OF'
line, not sure.
Arnd
2015-05-19 15:49 GMT+02:00 Daniel Lezcano <[email protected]>:
>
>
> It is not exactly as the initial patch.
>
> I think Arnd is proposing:
>
> config CLKSRC_STM32
> bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> select CLKSRC_MMIO
>
Isn't "depends on OF" missing for COMPILE_TEST case?
Other than that, I'm fine with the proposal.
Daniel, is it the case for you too?
Regards,
Maxime
On Tue, May 19, 2015 at 04:41:58PM +0200, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <[email protected]>:
> >
> >
> > It is not exactly as the initial patch.
> >
> > I think Arnd is proposing:
> >
> > config CLKSRC_STM32
> > bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> > select CLKSRC_MMIO
> >
>
> Isn't "depends on OF" missing for COMPILE_TEST case?
config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if COMPILE_TEST
depends on OF
select CLKSRC_MMIO
This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
it's always going to be for that case, right?) while allowing the option
to be visible when both OF!=n and COMPILE_TEST!=n.
Remember,
bool "string" if <condition-affects-visibility-of-string>
depends on <condition-affects-config-symbol-availability>
The former merely hides the option from the user _if_ the condition fails.
The latter _disables_ the option completely (except if you try and select
it, at which point you end up with a Kconfig warning about that.)
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
On 05/19/2015 04:41 PM, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <[email protected]>:
>>
>>
>> It is not exactly as the initial patch.
>>
>> I think Arnd is proposing:
>>
>> config CLKSRC_STM32
>> bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>> select CLKSRC_MMIO
>>
>
> Isn't "depends on OF" missing for COMPILE_TEST case?
Hmm, yes. Probably.
> Other than that, I'm fine with the proposal.
> Daniel, is it the case for you too?
Yep.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
2015-05-19 16:50 GMT+02:00 Russell King - ARM Linux <[email protected]>:
>
> config CLKSRC_STM32
> bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> depends on OF
> select CLKSRC_MMIO
>
> This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
> it's always going to be for that case, right?) while allowing the option
> to be visible when both OF!=n and COMPILE_TEST!=n.
Yes OF is always enabled when STM32.
So it fits our needs, as we only want the option to be visible when
both OF!=n and COMPILE_TEST!=n.
>
> Remember,
>
> bool "string" if <condition-affects-visibility-of-string>
> depends on <condition-affects-config-symbol-availability>
>
> The former merely hides the option from the user _if_ the condition fails.
> The latter _disables_ the option completely (except if you try and select
> it, at which point you end up with a Kconfig warning about that.)
Thanks for the reminder!
Maxime
Hi Arnd, Philipp,
2015-05-13 21:11 GMT+02:00 Arnd Bergmann <[email protected]>:
> Ideally the binding should follow closely what is documented
> in the data sheet.
>
Daniel and myself would like your opinion about this binding:
rcc: rcc@40023800 {
#reset-cells = <1>;
#clock-cells = <2>;
compatible = "st,stm32-rcc";
reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
reg-names = "clock-cfg", "reset", "clock-gates";
};
It would solve a problem Daniel is facing due to conflicting mem
region when clock and reset drivers are enabled, as both would reserve
the same region.
Also, it would make the reset driver very generic.
Doing that, we could even create a generic-reset.c driver that would
be used by STM32 and Sunxi (at least).
In the probe function, it would check the number of reg resources.
If a single resource is passed, it would take it, else it would look
the one named "reset".
The driver and bindings would be the same for the two families, and
the bindings would be backward compatible with sunxi ones.
Philip, Arnd, what do you think?
Kind regards,
Maxime
Hi,
Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <[email protected]>:
>> When Kernel is executed in place from ROM, the symbol addresses can be
>> lower than the page offset.
>>
>> Tested-by: Chanwoo Choi <[email protected]>
>> Signed-off-by: Maxime Coquelin <[email protected]>
This issue was reported by Stefan Agner in 2014 for the VF610 [1], not
sure if I asked already whether there should be a Reported-by line?
Stefan, have you had a chance to test this patch?
Back then on STM32F4 I debugged that disabling KALLSYMS works around it.
Now on a different XIP target I have confirmed this patch to help show a
stacktrace (my clk driver was missing some CLK_DIVIDER_ALLOW_ZEROs) ...
although my earlyprintk serial output still gets stuck further down the
stacktrace - probably unrelated.
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:126
divider_recalc_rate+0x2b/0x44()
[ 0.000000] SYS: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.1.0-rc4-next-20150519+ #23
[ 0.000000] Hardware name: XMC4000 (Device Tree Support)
[ 0.000000] [<0800bd5d>] (unwind_backtrace) from [<0800b0cb>]
(show_stack+0xb/0xc)
[ 0.000000] [<0800b0cb>] (show_stack) from [<0800e0a5>]
(warn_slowpath_common+0x55/0x78)
[ 0.000000] [<0800e0a5>] (warn_slowpath_common) from [<0800e103>]
(warn_slowpath_fmt+0x1b/0x24)
[ 0.000000] [<0800e103>] (warn_slowpath_fmt) from [<080942e3>] (divide
But this is definitely an improvement for ARMv7-M debugging,
Tested-by: Andreas F?rber <[email protected]>
> [Hi Michal, ...] could you consider
> taking it for v4.2?
Regards,
Andreas
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/307297.html
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)
Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
> The STM32 MCUs family IPs can be reset by accessing some registers
> from the RCC block.
>
> The list of available reset lines is documented in the DT bindings.
>
> Tested-by: Chanwoo Choi <[email protected]>
> Acked-by: Philipp Zabel <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
> ---
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-stm32.c | 124 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 125 insertions(+)
> create mode 100644 drivers/reset/reset-stm32.c
>
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 157d421..aed12d1 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_RESET_CONTROLLER) += core.o
> obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
> obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
> +obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
> obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
> obj-$(CONFIG_ARCH_STI) += sti/
> diff --git a/drivers/reset/reset-stm32.c b/drivers/reset/reset-stm32.c
> new file mode 100644
> index 0000000..2c41858
> --- /dev/null
> +++ b/drivers/reset/reset-stm32.c
[...]
> +static const struct of_device_id stm32_reset_dt_ids[] = {
> + { .compatible = "st,stm32-rcc", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
Typo.
IIUC the timer depends on the reset controller, so it must be built in
anyway, and that's what's enforced in the Makefile above. Drop the line?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)
Dne 21.5.2015 v 07:04 Andreas F?rber napsal(a):
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
> But this is definitely an improvement for ARMv7-M debugging,
>
> Tested-by: Andreas F?rber <[email protected]>
>
>> [Hi Michal, ...] could you consider
>> taking it for v4.2?
I applied it to kbuild.git#kbuild now.
Thanks,
Michal
2015-05-21 7:40 GMT+02:00 Michal Marek <[email protected]>:
> Dne 21.5.2015 v 07:04 Andreas Färber napsal(a):
>> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
>> But this is definitely an improvement for ARMv7-M debugging,
>>
>> Tested-by: Andreas Färber <[email protected]>
>>
>>> [Hi Michal, ...] could you consider
>>> taking it for v4.2?
>
> I applied it to kbuild.git#kbuild now.
Thanks!
Maxime
2015-05-21 1:45 GMT+02:00 Andreas Färber <[email protected]>:
> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>> + { .compatible = "st,stm32-rcc", },
>> + { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>
> Typo.
Indeed, thanks for pointing this out.
>
> IIUC the timer depends on the reset controller, so it must be built in
> anyway, and that's what's enforced in the Makefile above. Drop the line?
>
Agree it must be built-in.
I will fix that in next version.
Thanks for the review,
Maxime
Am 21.05.2015 um 09:46 schrieb Maxime Coquelin:
> 2015-05-21 1:45 GMT+02:00 Andreas F?rber <[email protected]>:
>> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>>> + { .compatible = "st,stm32-rcc", },
>>> + { /* sentinel */ },
>>> +};
>>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>>
>> Typo.
>
> Indeed, thanks for pointing this out.
>
>>
>> IIUC the timer depends on the reset controller, so it must be built in
>> anyway, and that's what's enforced in the Makefile above. Drop the line?
>>
>
> Agree it must be built-in.
> I will fix that in next version.
Actually, I've updated a timer implementation of mine to invoke a reset
controller similar to how you do in the STM32 clocksource patch, but no
reset controller is getting returned.
It seems to me, you are working around that by simply ignoring the error
in the timer code and not doing a reset then, so the STM32 timer does in
fact _not_ depend on the reset controller? What happened to your efforts
of making the reset controller usable for the timer? In my case, my
timer is originally in reset state and needs to be deasserted, so I
can't just ignore it.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)
2015-05-21 19:58 GMT+02:00 Andreas Färber <[email protected]>:
> Am 21.05.2015 um 09:46 schrieb Maxime Coquelin:
>> 2015-05-21 1:45 GMT+02:00 Andreas Färber <[email protected]>:
>>> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>>>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>>>> + { .compatible = "st,stm32-rcc", },
>>>> + { /* sentinel */ },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>>>
>>> Typo.
>>
>> Indeed, thanks for pointing this out.
>>
>>>
>>> IIUC the timer depends on the reset controller, so it must be built in
>>> anyway, and that's what's enforced in the Makefile above. Drop the line?
>>>
>>
>> Agree it must be built-in.
>> I will fix that in next version.
>
> Actually, I've updated a timer implementation of mine to invoke a reset
> controller similar to how you do in the STM32 clocksource patch, but no
> reset controller is getting returned.
>
> It seems to me, you are working around that by simply ignoring the error
> in the timer code and not doing a reset then, so the STM32 timer does in
> fact _not_ depend on the reset controller? What happened to your efforts
> of making the reset controller usable for the timer? In my case, my
> timer is originally in reset state and needs to be deasserted, so I
> can't just ignore it.
Indeed, I made the reset optionnal in the clocksource patch since v3.
Rob and Arnd said a lot of platform relies on such things are done by
the bootloader [0].
I decided to deassert timers reset at bootloader stage, and make it
optionnal in clocksource driver.
I made it optionnal in case we decide one day to move reset
initialization before timer are initialized.
Note that for now, I still use your bootloader.
I have done the changes to reset the timers in the afboot-stm32.
That's the reason why I asked you under which licence it is delivered
few months ago.
I can share you the patch if you want, even if I understand it is more
about the concept that you are reluctant.
On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
support in mainline [1].
In case of U-Boot, the timer reset should be de-asserted when jumping
into the Kernel, as Rob mentionned [0].
Kind regards,
Maxime
[0]: https://lkml.org/lkml/2015/3/10/737
[1]: http://u-boot.10912.n7.nabble.com/PATCH-v2-stm32f4-fix-serial-output-td212812.html
2015-05-21 20:51 GMT+02:00 Maxime Ripard <[email protected]>:
> On Wed, May 20, 2015 at 06:17:34PM +0200, Maxime Coquelin wrote:
>> Hi Arnd, Philipp,
>>
>> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <[email protected]>:
>> > Ideally the binding should follow closely what is documented
>> > in the data sheet.
>> >
>>
>> Daniel and myself would like your opinion about this binding:
>>
>> rcc: rcc@40023800 {
>> #reset-cells = <1>;
>> #clock-cells = <2>;
>> compatible = "st,stm32-rcc";
>> reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>> reg-names = "clock-cfg", "reset", "clock-gates";
>> };
>>
>> It would solve a problem Daniel is facing due to conflicting mem
>> region when clock and reset drivers are enabled, as both would reserve
>> the same region.
>>
>> Also, it would make the reset driver very generic.
>> Doing that, we could even create a generic-reset.c driver that would
>> be used by STM32 and Sunxi (at least).
>> In the probe function, it would check the number of reg resources.
>> If a single resource is passed, it would take it, else it would look
>> the one named "reset".
>> The driver and bindings would be the same for the two families, and
>> the bindings would be backward compatible with sunxi ones.
>>
>> Philip, Arnd, what do you think?
>
> I lack a bit of context here, but I'd be very happy to use a generic
> driver. As a matter of fact, the sunxi reset driver is already pretty
> much there (not that it's very difficult to do).
Ok, good. The two drivers are almost the same, so squashing to a
generic one would be trivial.
>
> The only thing we did that stands out a bit is that we actually need
> the reset driver much earlier than the default probe, since some of
> our timers are maintained in reset. We have some code to do just that
> already, we just need have something similar to be on board.
We have the same problem on stm32, as just discussed with Andreas [0].
I decided to patch the bootloader to deassert timers reset, after
discussions with Rob Herring and Arnd.
Moving to a common driver, stm32 could use the same early init method
to initiliaze reset before timers.
Regards,
Maxime
[0]: http://marc.info/?l=linux-arm-kernel&m=143223846802405&w=2#0
Am 21.05.2015 um 21:57 schrieb Maxime Coquelin:
> 2015-05-21 19:58 GMT+02:00 Andreas Färber <[email protected]>:
>> Actually, I've updated a timer implementation of mine to invoke a reset
>> controller similar to how you do in the STM32 clocksource patch, but no
>> reset controller is getting returned.
>>
>> It seems to me, you are working around that by simply ignoring the error
>> in the timer code and not doing a reset then, so the STM32 timer does in
>> fact _not_ depend on the reset controller? What happened to your efforts
>> of making the reset controller usable for the timer? In my case, my
>> timer is originally in reset state and needs to be deasserted, so I
>> can't just ignore it.
>
> Indeed, I made the reset optionnal in the clocksource patch since v3.
> Rob and Arnd said a lot of platform relies on such things are done by
> the bootloader [0].
> I decided to deassert timers reset at bootloader stage, and make it
> optionnal in clocksource driver.
> I made it optionnal in case we decide one day to move reset
> initialization before timer are initialized.
>
> Note that for now, I still use your bootloader.
> I have done the changes to reset the timers in the afboot-stm32.
> That's the reason why I asked you under which licence it is delivered
> few months ago.
Sorry, too many mails... The stm32 one is GPL-2.0, as parts of it were
derived from a U-Boot fork. (Personally I prefer GPL-2.0+; fm4 and
xmc4000 are MIT/X11.)
> I can share you the patch if you want, even if I understand it is more
> about the concept that you are reluctant.
>
> On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
> support in mainline [1].
You're free to use any bootloader you like, but you will find it
difficult to build in USB etc. drivers given the sheer size of U-Boot.
That was my motivation for writing the tiny one. ;)
> In case of U-Boot, the timer reset should be de-asserted when jumping
> into the Kernel, as Rob mentionned [0].
Thanks, I've updated the xmc4000 one accordingly and can do the same for
stm32. But you are right that I consider that an ugly workaround,
although on the other hand my earlyprintk patches also depend on the
bootloader setting up GPIOs and UART.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)
On 22/05/15 13:32, Maxime Coquelin wrote:
> 2015-05-22 12:07 GMT+02:00 Philipp Zabel <[email protected]>:
>> And that's how I'd expect it to be described by the device tree:
>>
>> rcc: rcc@40023800 {
>> compatible = "st,stm32-rcc";
>> reg = <0x40023800 0xc0>;
>> };
>>
>
> Doing that, since this register bank contains both reset and clock
> registers, the reset device cannot get the IO resource at probe time
> because the clock driver has already reserved it.
> Daniel, who has started to work on the clock driver is facing this issue.
> This is why I proposed this binding for "reg" property.
Temporarily I've kept things working for me by avoiding
of_io_request_and_map() in the clock driver (I am using raw of_iomap()
instead).
I view this as a hack rather than a solution!
Note that, with or without the hack, I do hope to be able to post the
clock driver this weekend. I am acutely aware that at the moment we are
discussing code I haven't posted yet.
> We could think of creating a MFD driver, but the problem is that clock
> need to be intialized before a MFD device can be probed.
>
> Maybe there is a way to have you binding working properly, but I
> haven't found one for now.
I guess a driver doesn't *have* to reserve all the register space
described in DT. The driver could replace of_io_request_and_map() with
lower level calls.
Thus if we wanted to keep this detail out of DT then I guess the two
drivers could simply make an agreement not to request registers they do
not use.
2015-05-22 15:09 GMT+02:00 Andreas Färber <[email protected]>:
> As you should know, I did have an RCC clk driver, and there is no such
> issue. The two drivers use different mechanisms for initialization. And
> I'm pretty sure that I've already remarked that on the list, too.
Yes, you use of_iomap in your clock driver [0].
Daniel, would you accept to do the same?
That would remove one difference between stm32/sunxi/socfpga reset drivers.
Regards,
Maxime
[0]: https://github.com/afaerber/linux/blob/stm32/drivers/clk/clk-stm32f42xxx-rcc.c
2015-05-22 0:01 GMT+02:00 Andreas Färber <[email protected]>:
> Am 21.05.2015 um 21:57 schrieb Maxime Coquelin:
>> Note that for now, I still use your bootloader.
>> I have done the changes to reset the timers in the afboot-stm32.
>> That's the reason why I asked you under which licence it is delivered
>> few months ago.
>
> Sorry, too many mails... The stm32 one is GPL-2.0, as parts of it were
> derived from a U-Boot fork. (Personally I prefer GPL-2.0+; fm4 and
> xmc4000 are MIT/X11.)
Not a problem, thanks for providing the licence.
>> I can share you the patch if you want, even if I understand it is more
>> about the concept that you are reluctant.
>>
>> On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
>> support in mainline [1].
>
> You're free to use any bootloader you like, but you will find it
> difficult to build in USB etc. drivers given the sheer size of U-Boot.
> That was my motivation for writing the tiny one. ;)
I think the two bootloaders make sense. Indeed, using U-Boot restricts
the size of the Kernel.
I also have the stm32429i-eval board, with 32MB NOR and 32MB SD-Ram.
At least on this one I will use U-Boot, as tftp could be used to load
Kernel since it has Ethernet port.
>> In case of U-Boot, the timer reset should be de-asserted when jumping
>> into the Kernel, as Rob mentionned [0].
>
> Thanks, I've updated the xmc4000 one accordingly and can do the same for
> stm32. But you are right that I consider that an ugly workaround,
> although on the other hand my earlyprintk patches also depend on the
> bootloader setting up GPIOs and UART.
Yes, the Kernel always need to rely on the bootloader to provide a
minimal setup (clock/ddr/muxing...).
Regards,
Maxime
Am 22.05.2015 um 15:57 schrieb Maxime Coquelin:
> 2015-05-22 15:09 GMT+02:00 Andreas Färber <[email protected]>:
>> As you should know, I did have an RCC clk driver, and there is no such
>> issue. The two drivers use different mechanisms for initialization. And
>> I'm pretty sure that I've already remarked that on the list, too.
>
> Yes, you use of_iomap in your clock driver [0].
Which was inspired by the efm32 driver iirc.
> Daniel, would you accept to do the same?
> That would remove one difference between stm32/sunxi/socfpga reset drivers.
>
> Regards,
> Maxime
>
> [0]: https://github.com/afaerber/linux/blob/stm32/drivers/clk/clk-stm32f42xxx-rcc.c
For the record, that still has some internal clocks that shouldn't be
exposed.
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)
On 22/05/15 14:57, Maxime Coquelin wrote:
> 2015-05-22 15:09 GMT+02:00 Andreas Färber <[email protected]>:
>> As you should know, I did have an RCC clk driver, and there is no such
>> issue. The two drivers use different mechanisms for initialization. And
>> I'm pretty sure that I've already remarked that on the list, too.
>
> Yes, you use of_iomap in your clock driver [0].
> Daniel, would you accept to do the same?
> That would remove one difference between stm32/sunxi/socfpga reset drivers.
In fact, that is exactly what I am currently doing, though I was
planning for it to be temporary.
It seems a bit weird to me that one driver (which requests too much
register space) only works because another driver chooses not to request
any.
BTW in drivers/clk there are ~110 of_iomaps and only 10
of_io_request_and_maps... so I don't think anyone will yell at me for
using of_iomap().
Daniel.
Am 21.05.2015 um 01:04 schrieb Andreas F?rber:
> Hi,
>
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
>> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <[email protected]>:
>>> When Kernel is executed in place from ROM, the symbol addresses can be
>>> lower than the page offset.
>>>
>>> Tested-by: Chanwoo Choi <[email protected]>
>>> Signed-off-by: Maxime Coquelin <[email protected]>
[...]
> Back then on STM32F4 I debugged that disabling KALLSYMS works around it.
>
> Now on a different XIP target I have confirmed this patch to help show a
> stacktrace (my clk driver was missing some CLK_DIVIDER_ALLOW_ZEROs) ...
> although my earlyprintk serial output still gets stuck further down the
> stacktrace - probably unrelated.
FTR confirming my suspicion: insufficient power supply. ;)
Andreas
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:126
> divider_recalc_rate+0x2b/0x44()
> [ 0.000000] SYS: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.1.0-rc4-next-20150519+ #23
> [ 0.000000] Hardware name: XMC4000 (Device Tree Support)
> [ 0.000000] [<0800bd5d>] (unwind_backtrace) from [<0800b0cb>]
> (show_stack+0xb/0xc)
> [ 0.000000] [<0800b0cb>] (show_stack) from [<0800e0a5>]
> (warn_slowpath_common+0x55/0x78)
> [ 0.000000] [<0800e0a5>] (warn_slowpath_common) from [<0800e103>]
> (warn_slowpath_fmt+0x1b/0x24)
> [ 0.000000] [<0800e103>] (warn_slowpath_fmt) from [<080942e3>] (divide
>
> But this is definitely an improvement for ARMv7-M debugging,
>
> Tested-by: Andreas F?rber <[email protected]>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)
Hi Maxime,
On Thu, May 21, 2015 at 10:10:35PM +0200, Maxime Coquelin wrote:
> > The only thing we did that stands out a bit is that we actually need
> > the reset driver much earlier than the default probe, since some of
> > our timers are maintained in reset. We have some code to do just that
> > already, we just need have something similar to be on board.
>
> We have the same problem on stm32, as just discussed with Andreas [0].
> I decided to patch the bootloader to deassert timers reset, after
> discussions with Rob Herring and Arnd.
That seems like the best solution, but we don't have control over the
bootloader in most cases. We have an alternative implementation (ie
mainline u-boot) that is required for a few things already, but I'd
really like to still be able to at least boot the kernel on a "legacy"
bootloader (that is the one flashed on the device).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Hi Maxime,
2015-05-23 10:28 GMT+02:00 Maxime Ripard <[email protected]>:
> On Thu, May 21, 2015 at 10:10:35PM +0200, Maxime Coquelin wrote:
>> We have the same problem on stm32, as just discussed with Andreas [0].
>> I decided to patch the bootloader to deassert timers reset, after
>> discussions with Rob Herring and Arnd.
>
> That seems like the best solution, but we don't have control over the
> bootloader in most cases. We have an alternative implementation (ie
> mainline u-boot) that is required for a few things already, but I'd
> really like to still be able to at least boot the kernel on a "legacy"
> bootloader (that is the one flashed on the device).
For sure it will have to remain compliant with the legacy bootloader.
It is easier for STM32 since it is a newly platform.
Regards,
Maxime C.