2015-04-30 16:21:00

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 00/15] Add support to STMicroelectronics STM32 family

In this seventh round, the series has been rebased on top of 4.1-rc1.
The series also fixes sysrq support in serial driver.

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 STM32F419 Discovery can boot succesfully.

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 (15):
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: 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 | 107 +++
.../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 | 226 +++++++
arch/arm/configs/stm32_defconfig | 69 ++
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 | 737 +++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 +
scripts/link-vmlinux.sh | 2 +-
30 files changed, 1852 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

--
1.9.1


2015-04-30 16:21:06

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 01/15] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

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

2015-04-30 16:21:12

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 02/15] ARM: ARMv7-M: Enlarge vector table up to 256 entries

>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

2015-04-30 16:26:31

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 03/15] dt-bindings: Document the ARM System timer bindings

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

2015-04-30 16:21:18

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 04/15] clocksource/drivers: Add ARM System timer driver

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

2015-04-30 16:26:03

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

This adds documentation of device tree bindings for the
STM32 reset controller.

Tested-by: Chanwoo Choi <[email protected]>
Acked-by: Philipp Zabel <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
.../devicetree/bindings/reset/st,stm32-rcc.txt | 107 +++++++++++++++++++++
1 file changed, 107 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..c1b0f8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
@@ -0,0 +1,107 @@
+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
+
+example:
+
+ timer2 {
+ resets = <&rcc 256>;
+ };
+
+List of valid indices for STM32F429:
+ - gpioa: 128
+ - gpiob: 129
+ - gpioc: 130
+ - gpiod: 131
+ - gpioe: 132
+ - gpiof: 133
+ - gpiog: 134
+ - gpioh: 135
+ - gpioi: 136
+ - gpioj: 137
+ - gpiok: 138
+ - crc: 140
+ - dma1: 149
+ - dma2: 150
+ - dma2d: 151
+ - ethmac: 153
+ - otghs: 157
+ - dcmi: 160
+ - cryp: 164
+ - hash: 165
+ - rng: 166
+ - otgfs: 167
+ - fmc: 192
+ - tim2: 256
+ - tim3: 257
+ - tim4: 258
+ - tim5: 259
+ - tim6: 260
+ - tim7: 261
+ - tim12: 262
+ - tim13: 263
+ - tim14: 264
+ - wwdg: 267
+ - spi2: 270
+ - spi3: 271
+ - uart2: 273
+ - uart3: 274
+ - uart4: 275
+ - uart5: 276
+ - i2c1: 277
+ - i2c2: 278
+ - i2c3: 279
+ - can1: 281
+ - can2: 282
+ - pwr: 284
+ - dac: 285
+ - uart7: 286
+ - uart8: 287
+ - tim1: 288
+ - tim8: 289
+ - usart1: 292
+ - usart6: 293
+ - adc: 296
+ - sdio: 299
+ - spi1: 300
+ - spi4: 301
+ - syscfg: 302
+ - tim9: 304
+ - tim10: 305
+ - tim11: 306
+ - spi5: 308
+ - spi6: 309
+ - sai1: 310
+ - ltdc: 314
--
1.9.1

2015-04-30 16:25:01

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 06/15] drivers: reset: Add STM32 reset driver

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

2015-04-30 16:21:27

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 07/15] dt-bindings: Document the STM32 timer bindings

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

2015-04-30 16:24:33

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 08/15] clockevents/drivers: Add STM32 Timer driver

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

2015-04-30 16:21:32

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 09/15] dt-bindings: Document the STM32 USART bindings

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

2015-04-30 16:23:55

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 10/15] serial: stm32-usart: Add STM32 USART Driver

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 | 737 +++++++++++++++++++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 +
4 files changed, 758 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..bdfaaaf
--- /dev/null
+++ b/drivers/tty/serial/stm32-usart.c
@@ -0,0 +1,737 @@
+/*
+ * 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;
+
+ 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

2015-04-30 16:21:44

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 11/15] ARM: Add STM32 family machine

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

2015-04-30 16:23:11

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 12/15] ARM: dts: Add ARM System timer as clocksource in armv7m

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

2015-04-30 16:23:14

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 13/15] ARM: dts: Introduce STM32F429 MCU

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 | 226 ++++++++++++++++++++++++++++++++++
3 files changed, 298 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..39ffdb8
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -0,0 +1,226 @@
+/*
+ * 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"
+
+/ {
+ 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 256>;
+ clocks = <&clk_pmtr1>;
+ status = "disabled";
+ };
+
+ timer3: timer@40000400 {
+ compatible = "st,stm32-timer";
+ reg = <0x40000400 0x400>;
+ interrupts = <29>;
+ resets = <&rcc 257>;
+ clocks = <&clk_pmtr1>;
+ status = "disabled";
+ };
+
+ timer4: timer@40000800 {
+ compatible = "st,stm32-timer";
+ reg = <0x40000800 0x400>;
+ interrupts = <30>;
+ resets = <&rcc 258>;
+ clocks = <&clk_pmtr1>;
+ status = "disabled";
+ };
+
+ timer5: timer@40000c00 {
+ compatible = "st,stm32-timer";
+ reg = <0x40000c00 0x400>;
+ interrupts = <50>;
+ resets = <&rcc 259>;
+ clocks = <&clk_pmtr1>;
+ };
+
+ timer6: timer@40001000 {
+ compatible = "st,stm32-timer";
+ reg = <0x40001000 0x400>;
+ interrupts = <54>;
+ resets = <&rcc 260>;
+ clocks = <&clk_pmtr1>;
+ status = "disabled";
+ };
+
+ timer7: timer@40001400 {
+ compatible = "st,stm32-timer";
+ reg = <0x40001400 0x400>;
+ interrupts = <55>;
+ resets = <&rcc 261>;
+ 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

2015-04-30 16:22:03

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 14/15] ARM: configs: Add STM32 defconfig

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 | 69 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 69 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..494bf39
--- /dev/null
+++ b/arch/arm/configs/stm32_defconfig
@@ -0,0 +1,69 @@
+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

2015-04-30 16:22:09

by Maxime Coquelin

[permalink] [raw]
Subject: [PATCH v7 15/15] MAINTAINERS: Add entry for STM32 MCUs

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

2015-05-01 08:08:26

by Daniel Thompson

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

On 30/04/15 17:20, Maxime Coquelin wrote:
> This adds documentation of device tree bindings for the
> STM32 reset controller.
>
> Tested-by: Chanwoo Choi <[email protected]>
> Acked-by: Philipp Zabel <[email protected]>
> Acked-by: Rob Herring <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
> ---
> .../devicetree/bindings/reset/st,stm32-rcc.txt | 107 +++++++++++++++++++++
> 1 file changed, 107 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..c1b0f8d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
> @@ -0,0 +1,107 @@
> +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";

Do you intend the clock driver to use the same compatible string (given
it is the same bit of hardware).

If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me
that the register layout of the PLLs and dividers can be the same on the
f7 parts (and later).

> + 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
> +
> +example:
> +
> + timer2 {
> + resets = <&rcc 256>;
> + };
> +
> +List of valid indices for STM32F429:
> + - gpioa: 128
> + - gpiob: 129
> + - gpioc: 130
> + - gpiod: 131
> + - gpioe: 132
> + - gpiof: 133
> + - gpiog: 134
> + - gpioh: 135
> + - gpioi: 136
> + - gpioj: 137
> + - gpiok: 138
> + - crc: 140
> + - dma1: 149
> + - dma2: 150
> + - dma2d: 151
> + - ethmac: 153
> + - otghs: 157
> + - dcmi: 160
> + - cryp: 164
> + - hash: 165
> + - rng: 166
> + - otgfs: 167
> + - fmc: 192
> + - tim2: 256
> + - tim3: 257
> + - tim4: 258
> + - tim5: 259
> + - tim6: 260
> + - tim7: 261
> + - tim12: 262
> + - tim13: 263
> + - tim14: 264
> + - wwdg: 267
> + - spi2: 270
> + - spi3: 271
> + - uart2: 273
> + - uart3: 274
> + - uart4: 275
> + - uart5: 276
> + - i2c1: 277
> + - i2c2: 278
> + - i2c3: 279
> + - can1: 281
> + - can2: 282
> + - pwr: 284
> + - dac: 285
> + - uart7: 286
> + - uart8: 287
> + - tim1: 288
> + - tim8: 289
> + - usart1: 292
> + - usart6: 293
> + - adc: 296
> + - sdio: 299
> + - spi1: 300
> + - spi4: 301
> + - syscfg: 302
> + - tim9: 304
> + - tim10: 305
> + - tim11: 306
> + - spi5: 308
> + - spi6: 309
> + - sai1: 310
> + - ltdc: 314

These numbers are stable for all STM32F4 family parts. Should this table
go into a dt-bindings header file?

2015-05-02 07:55:35

by Maxime Coquelin

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

2015-05-01 10:08 GMT+02:00 Daniel Thompson <[email protected]>:
> On 30/04/15 17:20, Maxime Coquelin wrote:
>>
>> This adds documentation of device tree bindings for the
>> STM32 reset controller.
>>
>> Tested-by: Chanwoo Choi <[email protected]>
>> Acked-by: Philipp Zabel <[email protected]>
>> Acked-by: Rob Herring <[email protected]>
>> Signed-off-by: Maxime Coquelin <[email protected]>
>> ---
>> .../devicetree/bindings/reset/st,stm32-rcc.txt | 107
>> +++++++++++++++++++++
>> 1 file changed, 107 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..c1b0f8d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>> @@ -0,0 +1,107 @@
>> +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";
>
>
> Do you intend the clock driver to use the same compatible string (given it
> is the same bit of hardware).
>
> If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me that
> the register layout of the PLLs and dividers can be the same on the f7 parts
> (and later).

I agree we need a compatible dedicate to f4 series for clocks, and
maybe even one for f429 (to be checked).
For the reset part, we don't have this need.

So either we use only "st,stm32f4" as you suggest, or we can have both
in device tree:

rcc: reset@40023800 {
#reset-cells = <1>;
compatible = "st,stm32f4-rcc", "st,stm32-rcc";
reg = <0x40023800 0x400>;
};

What do you think?

>
>
>> + 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
>> +
>> +example:
>> +
>> + timer2 {
>> + resets = <&rcc 256>;
>> + };
>> +
>> +List of valid indices for STM32F429:
>> + - gpioa: 128
>> + - gpiob: 129
>> + - gpioc: 130
>> + - gpiod: 131
>> + - gpioe: 132
>> + - gpiof: 133
>> + - gpiog: 134
>> + - gpioh: 135
>> + - gpioi: 136
>> + - gpioj: 137
>> + - gpiok: 138
>> + - crc: 140
>> + - dma1: 149
>> + - dma2: 150
>> + - dma2d: 151
>> + - ethmac: 153
>> + - otghs: 157
>> + - dcmi: 160
>> + - cryp: 164
>> + - hash: 165
>> + - rng: 166
>> + - otgfs: 167
>> + - fmc: 192
>> + - tim2: 256
>> + - tim3: 257
>> + - tim4: 258
>> + - tim5: 259
>> + - tim6: 260
>> + - tim7: 261
>> + - tim12: 262
>> + - tim13: 263
>> + - tim14: 264
>> + - wwdg: 267
>> + - spi2: 270
>> + - spi3: 271
>> + - uart2: 273
>> + - uart3: 274
>> + - uart4: 275
>> + - uart5: 276
>> + - i2c1: 277
>> + - i2c2: 278
>> + - i2c3: 279
>> + - can1: 281
>> + - can2: 282
>> + - pwr: 284
>> + - dac: 285
>> + - uart7: 286
>> + - uart8: 287
>> + - tim1: 288
>> + - tim8: 289
>> + - usart1: 292
>> + - usart6: 293
>> + - adc: 296
>> + - sdio: 299
>> + - spi1: 300
>> + - spi4: 301
>> + - syscfg: 302
>> + - tim9: 304
>> + - tim10: 305
>> + - tim11: 306
>> + - spi5: 308
>> + - spi6: 309
>> + - sai1: 310
>> + - ltdc: 314
>
>
> These numbers are stable for all STM32F4 family parts. Should this table go
> into a dt-bindings header file?
>

This has already been discussed with Philipp and Arnd in earlier
versions of this series [0].
I initially created a header file, and we decided going this way finally.

Regards,
Maxime

[0]: https://lkml.org/lkml/2015/3/10/692

2015-05-02 10:01:26

by Daniel Thompson

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

On 02/05/15 08:55, Maxime Coquelin wrote:
> 2015-05-01 10:08 GMT+02:00 Daniel Thompson <[email protected]>:
>> On 30/04/15 17:20, Maxime Coquelin wrote:
>>>
>>> This adds documentation of device tree bindings for the
>>> STM32 reset controller.
>>>
>>> Tested-by: Chanwoo Choi <[email protected]>
>>> Acked-by: Philipp Zabel <[email protected]>
>>> Acked-by: Rob Herring <[email protected]>
>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>> ---
>>> .../devicetree/bindings/reset/st,stm32-rcc.txt | 107
>>> +++++++++++++++++++++
>>> 1 file changed, 107 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..c1b0f8d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>> @@ -0,0 +1,107 @@
>>> +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";
>>
>>
>> Do you intend the clock driver to use the same compatible string (given it
>> is the same bit of hardware).
>>
>> If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me that
>> the register layout of the PLLs and dividers can be the same on the f7 parts
>> (and later).
>
> I agree we need a compatible dedicate to f4 series for clocks, and
> maybe even one for f429 (to be checked).
> For the reset part, we don't have this need.
>
> So either we use only "st,stm32f4" as you suggest, or we can have both
> in device tree:
>
> rcc: reset@40023800 {
> #reset-cells = <1>;
> compatible = "st,stm32f4-rcc", "st,stm32-rcc";
> reg = <0x40023800 0x400>;
> };
>
> What do you think?

Having both makes sense. The reset driver probably doesn't care about
differences between F4 and F7 (I know very little about F7 but I can't
think of any obvious h/ware evolution that would confuse the current
reset driver).


>>> + 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
>>> +
>>> +example:
>>> +
>>> + timer2 {
>>> + resets = <&rcc 256>;
>>> + };
>>> +
>>> +List of valid indices for STM32F429:
>>> + - gpioa: 128
>>> + - gpiob: 129
>>> ...
>>> <snip>
>>> ...
>>> + - sai1: 310
>>> + - ltdc: 314
>>
>>
>> These numbers are stable for all STM32F4 family parts. Should this table go
>> into a dt-bindings header file?
>>
>
> This has already been discussed with Philipp and Arnd in earlier
> versions of this series [0].
> I initially created a header file, and we decided going this way finally.

Thanks for the link. I had overlooked that (I only really started paying
attention at v5; I should probably have looked further back before
commenting).

However...

Arnd's concerns about mergability of headers can also be met by using
h/ware values in the header file can't there. To be honest my comment
was pretty heavily influenced after having read a recent patch from Rob
Herring ( https://lkml.org/lkml/2015/5/1/14 ) which does exactly this.

The main reason I got interested in having a header is that the reset
bits and the clock gate bits are encoded using the same bit patterns so
I wondering it we could express that only once.

I guess it doesn't matter that much, especially given there is only one
.dtsi file, and we can add a header later and remain binary compatible.
However if the same number set does end up repeated in different .dtsi
files I think that would motivate adding a header for F4 family.


Daniel.

2015-05-04 10:30:11

by Philipp Zabel

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

Am Samstag, den 02.05.2015, 11:01 +0100 schrieb Daniel Thompson:
> On 02/05/15 08:55, Maxime Coquelin wrote:
> > 2015-05-01 10:08 GMT+02:00 Daniel Thompson <[email protected]>:
[...]
> >> Do you intend the clock driver to use the same compatible string (given it
> >> is the same bit of hardware).
> >>
> >> If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me that
> >> the register layout of the PLLs and dividers can be the same on the f7 parts
> >> (and later).
> >
> > I agree we need a compatible dedicate to f4 series for clocks, and
> > maybe even one for f429 (to be checked).
> > For the reset part, we don't have this need.
> >
> > So either we use only "st,stm32f4" as you suggest, or we can have both
> > in device tree:
> >
> > rcc: reset@40023800 {
> > #reset-cells = <1>;
> > compatible = "st,stm32f4-rcc", "st,stm32-rcc";
> > reg = <0x40023800 0x400>;
> > };
> >
> > What do you think?
>
> Having both makes sense. The reset driver probably doesn't care about
> differences between F4 and F7 (I know very little about F7 but I can't
> think of any obvious h/ware evolution that would confuse the current
> reset driver).

Seconded, this is exactly the way compatible string lists are supposed
to be used.

[...]

regards
Philipp

2015-05-04 11:12:23

by Maxime Coquelin

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

2015-05-04 12:28 GMT+02:00 Philipp Zabel <[email protected]>:
> Am Samstag, den 02.05.2015, 11:01 +0100 schrieb Daniel Thompson:
>> On 02/05/15 08:55, Maxime Coquelin wrote:
>> > 2015-05-01 10:08 GMT+02:00 Daniel Thompson <[email protected]>:
> [...]
>> >> Do you intend the clock driver to use the same compatible string (given it
>> >> is the same bit of hardware).
>> >>
>> >> If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me that
>> >> the register layout of the PLLs and dividers can be the same on the f7 parts
>> >> (and later).
>> >
>> > I agree we need a compatible dedicate to f4 series for clocks, and
>> > maybe even one for f429 (to be checked).
>> > For the reset part, we don't have this need.
>> >
>> > So either we use only "st,stm32f4" as you suggest, or we can have both
>> > in device tree:
>> >
>> > rcc: reset@40023800 {
>> > #reset-cells = <1>;
>> > compatible = "st,stm32f4-rcc", "st,stm32-rcc";
>> > reg = <0x40023800 0x400>;
>> > };
>> >
>> > What do you think?
>>
>> Having both makes sense. The reset driver probably doesn't care about
>> differences between F4 and F7 (I know very little about F7 but I can't
>> think of any obvious h/ware evolution that would confuse the current
>> reset driver).
>
> Seconded, this is exactly the way compatible string lists are supposed
> to be used.

Ok good, so we all agree.

I propose I keep "st,stm32-rcc" only for this series, as it does not
contain the clock driver.
The series adding the clock driver will add "st,stm32f4-rcc", or
"st,stm32f429-rcc" depending on clock driver needs.

Thanks,
Maxime

>
> [...]
>
> regards
> Philipp
>

2015-05-04 11:25:34

by Maxime Coquelin

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

2015-05-02 12:01 GMT+02:00 Daniel Thompson <[email protected]>:
> On 02/05/15 08:55, Maxime Coquelin wrote:
>>
>> 2015-05-01 10:08 GMT+02:00 Daniel Thompson <[email protected]>:
>>>
>>> On 30/04/15 17:20, Maxime Coquelin wrote:
>>>>
>>>>
>>>> This adds documentation of device tree bindings for the
>>>> STM32 reset controller.
>>>>
>>>> Tested-by: Chanwoo Choi <[email protected]>
>>>> Acked-by: Philipp Zabel <[email protected]>
>>>> Acked-by: Rob Herring <[email protected]>
>>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>>> ---
>>>> .../devicetree/bindings/reset/st,stm32-rcc.txt | 107
>>>> +++++++++++++++++++++
>>>> 1 file changed, 107 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..c1b0f8d
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>> @@ -0,0 +1,107 @@
>>>> +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";
>>>
>>>
>>>
>>> Do you intend the clock driver to use the same compatible string (given
>>> it
>>> is the same bit of hardware).
>>>
>>> If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me
>>> that
>>> the register layout of the PLLs and dividers can be the same on the f7
>>> parts
>>> (and later).
>>
>>
>> I agree we need a compatible dedicate to f4 series for clocks, and
>> maybe even one for f429 (to be checked).
>> For the reset part, we don't have this need.
>>
>> So either we use only "st,stm32f4" as you suggest, or we can have both
>> in device tree:
>>
>> rcc: reset@40023800 {
>> #reset-cells = <1>;
>> compatible = "st,stm32f4-rcc", "st,stm32-rcc";
>> reg = <0x40023800 0x400>;
>> };
>>
>> What do you think?
>
>
> Having both makes sense. The reset driver probably doesn't care about
> differences between F4 and F7 (I know very little about F7 but I can't think
> of any obvious h/ware evolution that would confuse the current reset
> driver).
>
>
>>>> + 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
>>>> +
>>>> +example:
>>>> +
>>>> + timer2 {
>>>> + resets = <&rcc 256>;
>>>> + };
>>>> +
>>>> +List of valid indices for STM32F429:
>>>> + - gpioa: 128
>>>> + - gpiob: 129
>>>> ...
>>>> <snip>
>>>> ...
>>>> + - sai1: 310
>>>> + - ltdc: 314
>>>
>>>
>>>
>>> These numbers are stable for all STM32F4 family parts. Should this table
>>> go
>>> into a dt-bindings header file?
>>>
>>
>> This has already been discussed with Philipp and Arnd in earlier
>> versions of this series [0].
>> I initially created a header file, and we decided going this way finally.
>
>
> Thanks for the link. I had overlooked that (I only really started paying
> attention at v5; I should probably have looked further back before
> commenting).
>
> However...
>
> Arnd's concerns about mergability of headers can also be met by using h/ware
> values in the header file can't there. To be honest my comment was pretty
> heavily influenced after having read a recent patch from Rob Herring (
> https://lkml.org/lkml/2015/5/1/14 ) which does exactly this.
>
> The main reason I got interested in having a header is that the reset bits
> and the clock gate bits are encoded using the same bit patterns so I
> wondering it we could express that only once.

Ok, I understand your need, and it makes sense.
The problem is that the values defined today cannot be re-used
directly for clocks.
Since the calculation is starting from rcc base, there is a 128 offset.

To re-use the same values, maybe we should create a mfd dt-binding header file.
It would contain the bits definition starting from 0, and define
macros for both reset and clocks to add the offsets.

For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:

#define GPIOA 0
#define GPIOB 1
...
#define LTDC 186

#define STM32F4_RESET(x) (x + 128)
#define STM32F4_CLOCK(x) (x + 384)

Then, in DT, a reset would be described like this:

timer2 {
resets = <&rcc STM32F4_RESET(TIM2)>;
};

Phillip, Daniel, does that look acceptable to you?

Kind regards,
Maxime
>
> I guess it doesn't matter that much, especially given there is only one
> .dtsi file, and we can add a header later and remain binary compatible.
> However if the same number set does end up repeated in different .dtsi files
> I think that would motivate adding a header for F4 family.
>
>
> Daniel.
>

2015-05-05 14:08:03

by Daniel Thompson

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

On 04/05/15 12:25, Maxime Coquelin wrote:
> 2015-05-02 12:01 GMT+02:00 Daniel Thompson <[email protected]>:
>> On 02/05/15 08:55, Maxime Coquelin wrote:
>>>
>>> 2015-05-01 10:08 GMT+02:00 Daniel Thompson <[email protected]>:
>>>>
>>>> On 30/04/15 17:20, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> This adds documentation of device tree bindings for the
>>>>> STM32 reset controller.
>>>>>
>>>>> Tested-by: Chanwoo Choi <[email protected]>
>>>>> Acked-by: Philipp Zabel <[email protected]>
>>>>> Acked-by: Rob Herring <[email protected]>
>>>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>>>> ---
>>>>> .../devicetree/bindings/reset/st,stm32-rcc.txt | 107
>>>>> +++++++++++++++++++++
>>>>> 1 file changed, 107 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..c1b0f8d
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>> @@ -0,0 +1,107 @@
>>>>> +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";
>>>>
>>>>
>>>>
>>>> Do you intend the clock driver to use the same compatible string (given
>>>> it
>>>> is the same bit of hardware).
>>>>
>>>> If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me
>>>> that
>>>> the register layout of the PLLs and dividers can be the same on the f7
>>>> parts
>>>> (and later).
>>>
>>>
>>> I agree we need a compatible dedicate to f4 series for clocks, and
>>> maybe even one for f429 (to be checked).
>>> For the reset part, we don't have this need.
>>>
>>> So either we use only "st,stm32f4" as you suggest, or we can have both
>>> in device tree:
>>>
>>> rcc: reset@40023800 {
>>> #reset-cells = <1>;
>>> compatible = "st,stm32f4-rcc", "st,stm32-rcc";
>>> reg = <0x40023800 0x400>;
>>> };
>>>
>>> What do you think?
>>
>>
>> Having both makes sense. The reset driver probably doesn't care about
>> differences between F4 and F7 (I know very little about F7 but I can't think
>> of any obvious h/ware evolution that would confuse the current reset
>> driver).
>>
>>
>>>>> + 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
>>>>> +
>>>>> +example:
>>>>> +
>>>>> + timer2 {
>>>>> + resets = <&rcc 256>;
>>>>> + };
>>>>> +
>>>>> +List of valid indices for STM32F429:
>>>>> + - gpioa: 128
>>>>> + - gpiob: 129
>>>>> ...
>>>>> <snip>
>>>>> ...
>>>>> + - sai1: 310
>>>>> + - ltdc: 314
>>>>
>>>>
>>>>
>>>> These numbers are stable for all STM32F4 family parts. Should this table
>>>> go
>>>> into a dt-bindings header file?
>>>>
>>>
>>> This has already been discussed with Philipp and Arnd in earlier
>>> versions of this series [0].
>>> I initially created a header file, and we decided going this way finally.
>>
>>
>> Thanks for the link. I had overlooked that (I only really started paying
>> attention at v5; I should probably have looked further back before
>> commenting).
>>
>> However...
>>
>> Arnd's concerns about mergability of headers can also be met by using h/ware
>> values in the header file can't there. To be honest my comment was pretty
>> heavily influenced after having read a recent patch from Rob Herring (
>> https://lkml.org/lkml/2015/5/1/14 ) which does exactly this.
>>
>> The main reason I got interested in having a header is that the reset bits
>> and the clock gate bits are encoded using the same bit patterns so I
>> wondering it we could express that only once.
>
> Ok, I understand your need, and it makes sense.
> The problem is that the values defined today cannot be re-used
> directly for clocks.
> Since the calculation is starting from rcc base, there is a 128 offset.
>
> To re-use the same values, maybe we should create a mfd dt-binding header file.
> It would contain the bits definition starting from 0, and define
> macros for both reset and clocks to add the offsets.
>
> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>
> #define GPIOA 0
> #define GPIOB 1
> ...
> #define LTDC 186
>
> #define STM32F4_RESET(x) (x + 128)
> #define STM32F4_CLOCK(x) (x + 384)
>
> Then, in DT, a reset would be described like this:
>
> timer2 {
> resets = <&rcc STM32F4_RESET(TIM2)>;
> };
>
> Phillip, Daniel, does that look acceptable to you?

Doesn't look unreasonable.

I am a little uneasy simply because there are very few similar header
files in that directory but I haven't thought of a better idea.


Daniel.


>
> Kind regards,
> Maxime
>>
>> I guess it doesn't matter that much, especially given there is only one
>> .dtsi file, and we can add a header later and remain binary compatible.
>> However if the same number set does end up repeated in different .dtsi files
>> I think that would motivate adding a header for F4 family.
>>
>>
>> Daniel.
>>

2015-05-05 16:09:51

by Maxime Coquelin

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

2015-05-05 16:07 GMT+02:00 Daniel Thompson <[email protected]>:
> On 04/05/15 12:25, Maxime Coquelin wrote:
>>
>> 2015-05-02 12:01 GMT+02:00 Daniel Thompson <[email protected]>:
>>>
>>> On 02/05/15 08:55, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-01 10:08 GMT+02:00 Daniel Thompson <[email protected]>:
>>>>>
>>>>>
>>>>> On 30/04/15 17:20, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> This adds documentation of device tree bindings for the
>>>>>> STM32 reset controller.
>>>>>>
>>>>>> Tested-by: Chanwoo Choi <[email protected]>
>>>>>> Acked-by: Philipp Zabel <[email protected]>
>>>>>> Acked-by: Rob Herring <[email protected]>
>>>>>> Signed-off-by: Maxime Coquelin <[email protected]>
>>>>>> ---
>>>>>> .../devicetree/bindings/reset/st,stm32-rcc.txt | 107
>>>>>> +++++++++++++++++++++
>>>>>> 1 file changed, 107 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..c1b0f8d
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>>> @@ -0,0 +1,107 @@
>>>>>> +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";
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Do you intend the clock driver to use the same compatible string (given
>>>>> it
>>>>> is the same bit of hardware).
>>>>>
>>>>> If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me
>>>>> that
>>>>> the register layout of the PLLs and dividers can be the same on the f7
>>>>> parts
>>>>> (and later).
>>>>
>>>>
>>>>
>>>> I agree we need a compatible dedicate to f4 series for clocks, and
>>>> maybe even one for f429 (to be checked).
>>>> For the reset part, we don't have this need.
>>>>
>>>> So either we use only "st,stm32f4" as you suggest, or we can have both
>>>> in device tree:
>>>>
>>>> rcc: reset@40023800 {
>>>> #reset-cells = <1>;
>>>> compatible = "st,stm32f4-rcc", "st,stm32-rcc";
>>>> reg = <0x40023800 0x400>;
>>>> };
>>>>
>>>> What do you think?
>>>
>>>
>>>
>>> Having both makes sense. The reset driver probably doesn't care about
>>> differences between F4 and F7 (I know very little about F7 but I can't
>>> think
>>> of any obvious h/ware evolution that would confuse the current reset
>>> driver).
>>>
>>>
>>>>>> + 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
>>>>>> +
>>>>>> +example:
>>>>>> +
>>>>>> + timer2 {
>>>>>> + resets = <&rcc 256>;
>>>>>> + };
>>>>>> +
>>>>>> +List of valid indices for STM32F429:
>>>>>> + - gpioa: 128
>>>>>> + - gpiob: 129
>>>>>> ...
>>>>>> <snip>
>>>>>> ...
>>>>>> + - sai1: 310
>>>>>> + - ltdc: 314
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> These numbers are stable for all STM32F4 family parts. Should this
>>>>> table
>>>>> go
>>>>> into a dt-bindings header file?
>>>>>
>>>>
>>>> This has already been discussed with Philipp and Arnd in earlier
>>>> versions of this series [0].
>>>> I initially created a header file, and we decided going this way
>>>> finally.
>>>
>>>
>>>
>>> Thanks for the link. I had overlooked that (I only really started paying
>>> attention at v5; I should probably have looked further back before
>>> commenting).
>>>
>>> However...
>>>
>>> Arnd's concerns about mergability of headers can also be met by using
>>> h/ware
>>> values in the header file can't there. To be honest my comment was pretty
>>> heavily influenced after having read a recent patch from Rob Herring (
>>> https://lkml.org/lkml/2015/5/1/14 ) which does exactly this.
>>>
>>> The main reason I got interested in having a header is that the reset
>>> bits
>>> and the clock gate bits are encoded using the same bit patterns so I
>>> wondering it we could express that only once.
>>
>>
>> Ok, I understand your need, and it makes sense.
>> The problem is that the values defined today cannot be re-used
>> directly for clocks.
>> Since the calculation is starting from rcc base, there is a 128 offset.
>>
>> To re-use the same values, maybe we should create a mfd dt-binding header
>> file.
>> It would contain the bits definition starting from 0, and define
>> macros for both reset and clocks to add the offsets.
>>
>> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>>
>> #define GPIOA 0
>> #define GPIOB 1
>> ...
>> #define LTDC 186
>>
>> #define STM32F4_RESET(x) (x + 128)
>> #define STM32F4_CLOCK(x) (x + 384)
>>
>> Then, in DT, a reset would be described like this:
>>
>> timer2 {
>> resets = <&rcc STM32F4_RESET(TIM2)>;
>> };
>>
>> Phillip, Daniel, does that look acceptable to you?
>
>
> Doesn't look unreasonable.
>
> I am a little uneasy simply because there are very few similar header files
> in that directory but I haven't thought of a better idea.

Since this file will be shared by both clock and reset drivers, I
don't see better option.
I will implement it in v8 if Philipp agrees.

Thanks,
Maxime

>
>
> Daniel.
>
>
>
>>
>> Kind regards,
>> Maxime
>>>
>>>
>>> I guess it doesn't matter that much, especially given there is only one
>>> .dtsi file, and we can add a header later and remain binary compatible.
>>> However if the same number set does end up repeated in different .dtsi
>>> files
>>> I think that would motivate adding a header for F4 family.
>>>
>>>
>>> Daniel.
>>>
>

2015-05-05 16:11:06

by Philipp Zabel

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

Am Dienstag, den 05.05.2015, 17:19 +0200 schrieb Maxime Coquelin:
> >> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
> >>
> >> #define GPIOA 0
> >> #define GPIOB 1
> >> ...
> >> #define LTDC 186

That looks a bit fragile.
At least the defines for the indices should be properly namespaced,
check out include/dt-bindings/gpio/tegra-gpio.h for a similar case.

> >> #define STM32F4_RESET(x) (x + 128)
> >> #define STM32F4_CLOCK(x) (x + 384)
> >>
> >> Then, in DT, a reset would be described like this:
> >>
> >> timer2 {
> >> resets = <&rcc STM32F4_RESET(TIM2)>;
> >> };
> >>
> >> Phillip, Daniel, does that look acceptable to you?
> >
> >
> > Doesn't look unreasonable.
> >
> > I am a little uneasy simply because there are very few similar header files
> > in that directory but I haven't thought of a better idea.
>
> Since this file will be shared by both clock and reset drivers, I
> don't see better option.
> I will implement it in v8 if Philipp agrees.

Are the device tree maintainers happy with this idiom spreading?
Except for the point above, I think this is acceptable.

regards
Philipp

2015-05-05 17:27:31

by Daniel Thompson

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

On 05/05/15 16:42, Philipp Zabel wrote:
> Am Dienstag, den 05.05.2015, 17:19 +0200 schrieb Maxime Coquelin:
>>>> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>>>>
>>>> #define GPIOA 0
>>>> #define GPIOB 1
>>>> ...
>>>> #define LTDC 186
>
> That looks a bit fragile.
> At least the defines for the indices should be properly namespaced,
> check out include/dt-bindings/gpio/tegra-gpio.h for a similar case.

Good point.

>>>> #define STM32F4_RESET(x) (x + 128)
>>>> #define STM32F4_CLOCK(x) (x + 384)

Thinking more about this point, if we are going to follow hardware if
might be better to have:

#define STM32F4_RCC_AHB1_GPIOA 0
#define STM32F4_RCC_AHB1_GPIOA 1
...
#define STM32F4_RCC_APB2_LTDC 26


#define STM32F4_AHB1_RESET(x) (STM32F4_RCC_AHB1_##x##_BIT + (0x10 * 8))
#define STM32F4_AHB2_RESET(x) (STM32F4_RCC_AHB2_##x##_BIT + (0x14 * 8))
...
#define STM32F4_APB2_RESET(x) (STM32F4_RCC_APB2_##x##_BIT + (0x24 * 8))

Its more typing (or copy 'n pasting) by at least every number now maps
directly to the datasheet.


>>>>
>>>> Then, in DT, a reset would be described like this:
>>>>
>>>> timer2 {
>>>> resets = <&rcc STM32F4_RESET(TIM2)>;
>>>> };
>>>>
>>>> Phillip, Daniel, does that look acceptable to you?
>>>
>>>
>>> Doesn't look unreasonable.
>>>
>>> I am a little uneasy simply because there are very few similar header files
>>> in that directory but I haven't thought of a better idea.
>>
>> Since this file will be shared by both clock and reset drivers, I
>> don't see better option.
>> I will implement it in v8 if Philipp agrees.
>
> Are the device tree maintainers happy with this idiom spreading?
> Except for the point above, I think this is acceptable.
>
> regards
> Philipp
>

2015-05-05 17:22:26

by Maxime Coquelin

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

2015-05-05 17:42 GMT+02:00 Philipp Zabel <[email protected]>:
> Am Dienstag, den 05.05.2015, 17:19 +0200 schrieb Maxime Coquelin:
>> >> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>> >>
>> >> #define GPIOA 0
>> >> #define GPIOB 1
>> >> ...
>> >> #define LTDC 186
>
> That looks a bit fragile.
> At least the defines for the indices should be properly namespaced,
> check out include/dt-bindings/gpio/tegra-gpio.h for a similar case.

Thanks, I will prefix them with the proper namespace, Daniel proposal
is fine to me.

>
>> >> #define STM32F4_RESET(x) (x + 128)
>> >> #define STM32F4_CLOCK(x) (x + 384)
>> >>
>> >> Then, in DT, a reset would be described like this:
>> >>
>> >> timer2 {
>> >> resets = <&rcc STM32F4_RESET(TIM2)>;
>> >> };
>> >>
>> >> Phillip, Daniel, does that look acceptable to you?
>> >
>> >
>> > Doesn't look unreasonable.
>> >
>> > I am a little uneasy simply because there are very few similar header files
>> > in that directory but I haven't thought of a better idea.
>>
>> Since this file will be shared by both clock and reset drivers, I
>> don't see better option.
>> I will implement it in v8 if Philipp agrees.
>
> Are the device tree maintainers happy with this idiom spreading?
> Except for the point above, I think this is acceptable.
Ok good. Let's see what DT maintainers thinks about that.

Regards,
Maxime

>
> regards
> Philipp
>

2015-05-05 17:24:14

by Maxime Coquelin

[permalink] [raw]
Subject: Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings

2015-05-05 18:07 GMT+02:00 Daniel Thompson <[email protected]>:
> On 05/05/15 16:42, Philipp Zabel wrote:
>>
>> Am Dienstag, den 05.05.2015, 17:19 +0200 schrieb Maxime Coquelin:
>>>>>
>>>>> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>>>>>
>>>>> #define GPIOA 0
>>>>> #define GPIOB 1
>>>>> ...
>>>>> #define LTDC 186
>>
>>
>> That looks a bit fragile.
>> At least the defines for the indices should be properly namespaced,
>> check out include/dt-bindings/gpio/tegra-gpio.h for a similar case.
>
>
> Good point.
>
>>>>> #define STM32F4_RESET(x) (x + 128)
>>>>> #define STM32F4_CLOCK(x) (x + 384)
>
>
> Thinking more about this point, if we are going to follow hardware if might
> be better to have:
>
> #define STM32F4_RCC_AHB1_GPIOA 0
> #define STM32F4_RCC_AHB1_GPIOA 1
> ...
> #define STM32F4_RCC_APB2_LTDC 26
>
>
> #define STM32F4_AHB1_RESET(x) (STM32F4_RCC_AHB1_##x##_BIT + (0x10 * 8))
> #define STM32F4_AHB2_RESET(x) (STM32F4_RCC_AHB2_##x##_BIT + (0x14 * 8))
> ...
> #define STM32F4_APB2_RESET(x) (STM32F4_RCC_APB2_##x##_BIT + (0x24 * 8))
>
> Its more typing (or copy 'n pasting) by at least every number now maps
> directly to the datasheet.

As said in Philipp's reply, I like the idea.

Regards,
Maxime
>
>
>
>>>>>
>>>>> Then, in DT, a reset would be described like this:
>>>>>
>>>>> timer2 {
>>>>> resets = <&rcc STM32F4_RESET(TIM2)>;
>>>>> };
>>>>>
>>>>> Phillip, Daniel, does that look acceptable to you?
>>>>
>>>>
>>>>
>>>> Doesn't look unreasonable.
>>>>
>>>> I am a little uneasy simply because there are very few similar header
>>>> files
>>>> in that directory but I haven't thought of a better idea.
>>>
>>>
>>> Since this file will be shared by both clock and reset drivers, I
>>> don't see better option.
>>> I will implement it in v8 if Philipp agrees.
>>
>>
>> Are the device tree maintainers happy with this idiom spreading?
>> Except for the point above, I think this is acceptable.
>>
>> regards
>> Philipp
>>
>