[PATCH v8 00/16] Add support to STMicroelectronics STM32 family

[PATCH v8 00/16] Add support to STMicroelectronics STM32 family

[Maxime Coquelin]

Main change in this eighth round is the introduction of a new DT bindings
include file for RCC IP drivers. It is for now only used by reset driver,
but goal is to use it also for the clock driver later.
Other changes are bug fix in termios callback of serial driver (uninitialized 
variables), and NO_HZ enablement in stm32_defconfig.

STM32 MCUs are Cortex-M CPU, used in various applications (consumer
electronics, industrial applications, hobbyists...).
Datasheets, user and programming manuals are publicly available on
STMicroelectronics website.

With this series applied, the STM32F429 Discovery can boot succesfully.

Note: Patch 2/16 has already been applied by Russell (8340/1).

Changes since v7:
-----------------
 - Add DT-bindings header file for RCC IP (Daniel)
 - Fix uninitialized variables in serial driver
 - Enable CONFIG_NO_HZ in stm32_defconfig

Changes since v6:
-----------------
 - serial: Fix locking in case of sysrq (Vladimir)
 - Rebase on top of v4.1-rc1
 - Apply Acked-by and Reviewed-by
 - Clean-up stm32_defconfig

Changes since v5:
-----------------
 - Change st,hw-flow-ctrl property to auto-flow-control (Rob)
 - Constify stm32_uart_ops (Joe)
 - Propagate request_irq error in USART driver (Andy)
 - Applies Acked-by and Reviewed-by (Rob, Peter)

Changes since v4:
-----------------
 - Cosmetic changes in USART driver (Andy)
 - Apply Acks on reset driver & bindings (Philipp & Rob)

Changes since v3:
-----------------
 - Fix and simplify error path in ARMv7-M Systick driver (Daniel)
 - Improve reset bindings documentation (Philipp)
 - Fix trailing lines anf typos in reset driver & doc (Philipp & Chanwoo)
 - Fix MODULE_LICENCE in USART driver (Paul)
 - Refactor USART baudrate calculation (Peter & Andy)
 - Fix error path in USART init (Peter & Russell)
 - Fix HW flow control in USART driver (Peter)
 - Fix serial port type number to unused one (Peter)
 - Applies Chanwoo's Tested-by on the series

Changes since v2:
-----------------
 - Remove pinctrl driver from the series. 
 - Remove reset_controller_of_init(), and reset the timers in the bootloader
 - Add HW flow contrl property for serial driver
 - Lots of changes in the DTS file, as per Andreas recommendations
 - Some Kconfig clean-ups
 - Adapt the config to be compatible with Andreas' bootwrapper, except UART port.
 - Various fixes in documentation

Changes since v1:
-----------------
 - Move bindings documentation in their own patches (Andreas)
 - Rename ARM System timer to armv7m-systick (Rob)
 - Add clock-frequency property handling in armv7m-systick (Rob)
 - Re-factor the reset controllers into a single controller (Philipp)
 - Add kerneldoc to reset_controller_of_init (Philipp)
 - Add named constants in include/dt-bindings/reset/ (Philipp)
 - Make pinctrl driver to depend on ARCH_STM32 or COMPILE_TEST (Geert)
 - Introduce CPUV7M_NUM_IRQ config flag to indicate the number of interrupts
supported by the MCU, in order to limit memory waste in vectors' table (Uwe)

Maxime Coquelin (16):
  scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP
    Kernel
  ARM: ARMv7-M: Enlarge vector table up to 256 entries
  dt-bindings: Document the ARM System timer bindings
  clocksource/drivers: Add ARM System timer driver
  dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include
    file
  dt-bindings: Document the STM32 reset bindings
  drivers: reset: Add STM32 reset driver
  dt-bindings: Document the STM32 timer bindings
  clockevents/drivers: Add STM32 Timer driver
  dt-bindings: Document the STM32 USART bindings
  serial: stm32-usart: Add STM32 USART Driver
  ARM: Add STM32 family machine
  ARM: dts: Add ARM System timer as clocksource in armv7m
  ARM: dts: Introduce STM32F429 MCU
  ARM: configs: Add STM32 defconfig
  MAINTAINERS: Add entry for STM32 MCUs

 Documentation/arm/stm32/overview.txt               |  32 +
 Documentation/arm/stm32/stm32f429-overview.txt     |  22 +
 .../devicetree/bindings/arm/armv7m_systick.txt     |  26 +
 .../devicetree/bindings/reset/st,stm32-rcc.txt     |  50 ++
 .../devicetree/bindings/serial/st,stm32-usart.txt  |  32 +
 .../devicetree/bindings/timer/st,stm32-timer.txt   |  22 +
 MAINTAINERS                                        |   8 +
 arch/arm/Kconfig                                   |  18 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/armv7-m.dtsi                     |   6 +
 arch/arm/boot/dts/stm32f429-disco.dts              |  71 ++
 arch/arm/boot/dts/stm32f429.dtsi                   | 227 +++++++
 arch/arm/configs/stm32_defconfig                   |  70 ++
 arch/arm/kernel/entry-v7m.S                        |  13 +-
 arch/arm/mach-stm32/Makefile                       |   1 +
 arch/arm/mach-stm32/Makefile.boot                  |   3 +
 arch/arm/mach-stm32/board-dt.c                     |  19 +
 arch/arm/mm/Kconfig                                |  15 +
 drivers/clocksource/Kconfig                        |  15 +
 drivers/clocksource/Makefile                       |   2 +
 drivers/clocksource/armv7m_systick.c               |  79 +++
 drivers/clocksource/timer-stm32.c                  | 184 +++++
 drivers/reset/Makefile                             |   1 +
 drivers/reset/reset-stm32.c                        | 124 ++++
 drivers/tty/serial/Kconfig                         |  17 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/stm32-usart.c                   | 739 +++++++++++++++++++++
 include/dt-bindings/mfd/stm32f4-rcc.h              |  92 +++
 include/uapi/linux/serial_core.h                   |   3 +
 scripts/link-vmlinux.sh                            |   2 +-
 31 files changed, 1891 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/arm/stm32/overview.txt
 create mode 100644 Documentation/arm/stm32/stm32f429-overview.txt
 create mode 100644 Documentation/devicetree/bindings/arm/armv7m_systick.txt
 create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
 create mode 100644 Documentation/devicetree/bindings/serial/st,stm32-usart.txt
 create mode 100644 Documentation/devicetree/bindings/timer/st,stm32-timer.txt
 create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
 create mode 100644 arch/arm/boot/dts/stm32f429.dtsi
 create mode 100644 arch/arm/configs/stm32_defconfig
 create mode 100644 arch/arm/mach-stm32/Makefile
 create mode 100644 arch/arm/mach-stm32/Makefile.boot
 create mode 100644 arch/arm/mach-stm32/board-dt.c
 create mode 100644 drivers/clocksource/armv7m_systick.c
 create mode 100644 drivers/clocksource/timer-stm32.c
 create mode 100644 drivers/reset/reset-stm32.c
 create mode 100644 drivers/tty/serial/stm32-usart.c
 create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h

-- 
1.9.1

[PATCH v8 00/16] Add support to STMicroelectronics STM32 family

[Maxime Coquelin]

Main change in this eighth round is the introduction of a new DT bindings
include file for RCC IP drivers. It is for now only used by reset driver,
but goal is to use it also for the clock driver later.
Other changes are bug fix in termios callback of serial driver (uninitialized 
variables), and NO_HZ enablement in stm32_defconfig.

STM32 MCUs are Cortex-M CPU, used in various applications (consumer
electronics, industrial applications, hobbyists...).
Datasheets, user and programming manuals are publicly available on
STMicroelectronics website.

With this series applied, the STM32F429 Discovery can boot succesfully.

Note: Patch 2/16 has already been applied by Russell (8340/1).

Changes since v7:
-----------------
 - Add DT-bindings header file for RCC IP (Daniel)
 - Fix uninitialized variables in serial driver
 - Enable CONFIG_NO_HZ in stm32_defconfig

Changes since v6:
-----------------
 - serial: Fix locking in case of sysrq (Vladimir)
 - Rebase on top of v4.1-rc1
 - Apply Acked-by and Reviewed-by
 - Clean-up stm32_defconfig

Changes since v5:
-----------------
 - Change st,hw-flow-ctrl property to auto-flow-control (Rob)
 - Constify stm32_uart_ops (Joe)
 - Propagate request_irq error in USART driver (Andy)
 - Applies Acked-by and Reviewed-by (Rob, Peter)

Changes since v4:
-----------------
 - Cosmetic changes in USART driver (Andy)
 - Apply Acks on reset driver & bindings (Philipp & Rob)

Changes since v3:
-----------------
 - Fix and simplify error path in ARMv7-M Systick driver (Daniel)
 - Improve reset bindings documentation (Philipp)
 - Fix trailing lines anf typos in reset driver & doc (Philipp & Chanwoo)
 - Fix MODULE_LICENCE in USART driver (Paul)
 - Refactor USART baudrate calculation (Peter & Andy)
 - Fix error path in USART init (Peter & Russell)
 - Fix HW flow control in USART driver (Peter)
 - Fix serial port type number to unused one (Peter)
 - Applies Chanwoo's Tested-by on the series

Changes since v2:
-----------------
 - Remove pinctrl driver from the series. 
 - Remove reset_controller_of_init(), and reset the timers in the bootloader
 - Add HW flow contrl property for serial driver
 - Lots of changes in the DTS file, as per Andreas recommendations
 - Some Kconfig clean-ups
 - Adapt the config to be compatible with Andreas' bootwrapper, except UART port.
 - Various fixes in documentation

Changes since v1:
-----------------
 - Move bindings documentation in their own patches (Andreas)
 - Rename ARM System timer to armv7m-systick (Rob)
 - Add clock-frequency property handling in armv7m-systick (Rob)
 - Re-factor the reset controllers into a single controller (Philipp)
 - Add kerneldoc to reset_controller_of_init (Philipp)
 - Add named constants in include/dt-bindings/reset/ (Philipp)
 - Make pinctrl driver to depend on ARCH_STM32 or COMPILE_TEST (Geert)
 - Introduce CPUV7M_NUM_IRQ config flag to indicate the number of interrupts
supported by the MCU, in order to limit memory waste in vectors' table (Uwe)

Maxime Coquelin (16):
  scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP
    Kernel
  ARM: ARMv7-M: Enlarge vector table up to 256 entries
  dt-bindings: Document the ARM System timer bindings
  clocksource/drivers: Add ARM System timer driver
  dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include
    file
  dt-bindings: Document the STM32 reset bindings
  drivers: reset: Add STM32 reset driver
  dt-bindings: Document the STM32 timer bindings
  clockevents/drivers: Add STM32 Timer driver
  dt-bindings: Document the STM32 USART bindings
  serial: stm32-usart: Add STM32 USART Driver
  ARM: Add STM32 family machine
  ARM: dts: Add ARM System timer as clocksource in armv7m
  ARM: dts: Introduce STM32F429 MCU
  ARM: configs: Add STM32 defconfig
  MAINTAINERS: Add entry for STM32 MCUs

 Documentation/arm/stm32/overview.txt               |  32 +
 Documentation/arm/stm32/stm32f429-overview.txt     |  22 +
 .../devicetree/bindings/arm/armv7m_systick.txt     |  26 +
 .../devicetree/bindings/reset/st,stm32-rcc.txt     |  50 ++
 .../devicetree/bindings/serial/st,stm32-usart.txt  |  32 +
 .../devicetree/bindings/timer/st,stm32-timer.txt   |  22 +
 MAINTAINERS                                        |   8 +
 arch/arm/Kconfig                                   |  18 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/armv7-m.dtsi                     |   6 +
 arch/arm/boot/dts/stm32f429-disco.dts              |  71 ++
 arch/arm/boot/dts/stm32f429.dtsi                   | 227 +++++++
 arch/arm/configs/stm32_defconfig                   |  70 ++
 arch/arm/kernel/entry-v7m.S                        |  13 +-
 arch/arm/mach-stm32/Makefile                       |   1 +
 arch/arm/mach-stm32/Makefile.boot                  |   3 +
 arch/arm/mach-stm32/board-dt.c                     |  19 +
 arch/arm/mm/Kconfig                                |  15 +
 drivers/clocksource/Kconfig                        |  15 +
 drivers/clocksource/Makefile                       |   2 +
 drivers/clocksource/armv7m_systick.c               |  79 +++
 drivers/clocksource/timer-stm32.c                  | 184 +++++
 drivers/reset/Makefile                             |   1 +
 drivers/reset/reset-stm32.c                        | 124 ++++
 drivers/tty/serial/Kconfig                         |  17 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/stm32-usart.c                   | 739 +++++++++++++++++++++
 include/dt-bindings/mfd/stm32f4-rcc.h              |  92 +++
 include/uapi/linux/serial_core.h                   |   3 +
 scripts/link-vmlinux.sh                            |   2 +-
 31 files changed, 1891 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/arm/stm32/overview.txt
 create mode 100644 Documentation/arm/stm32/stm32f429-overview.txt
 create mode 100644 Documentation/devicetree/bindings/arm/armv7m_systick.txt
 create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
 create mode 100644 Documentation/devicetree/bindings/serial/st,stm32-usart.txt
 create mode 100644 Documentation/devicetree/bindings/timer/st,stm32-timer.txt
 create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
 create mode 100644 arch/arm/boot/dts/stm32f429.dtsi
 create mode 100644 arch/arm/configs/stm32_defconfig
 create mode 100644 arch/arm/mach-stm32/Makefile
 create mode 100644 arch/arm/mach-stm32/Makefile.boot
 create mode 100644 arch/arm/mach-stm32/board-dt.c
 create mode 100644 drivers/clocksource/armv7m_systick.c
 create mode 100644 drivers/clocksource/timer-stm32.c
 create mode 100644 drivers/reset/reset-stm32.c
 create mode 100644 drivers/tty/serial/stm32-usart.c
 create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h

-- 
1.9.1

[PATCH v8 00/16] Add support to STMicroelectronics STM32 family

[Maxime Coquelin]

Main change in this eighth round is the introduction of a new DT bindings
include file for RCC IP drivers. It is for now only used by reset driver,
but goal is to use it also for the clock driver later.
Other changes are bug fix in termios callback of serial driver (uninitialized 
variables), and NO_HZ enablement in stm32_defconfig.

STM32 MCUs are Cortex-M CPU, used in various applications (consumer
electronics, industrial applications, hobbyists...).
Datasheets, user and programming manuals are publicly available on
STMicroelectronics website.

With this series applied, the STM32F429 Discovery can boot succesfully.

Note: Patch 2/16 has already been applied by Russell (8340/1).

Changes since v7:
-----------------
 - Add DT-bindings header file for RCC IP (Daniel)
 - Fix uninitialized variables in serial driver
 - Enable CONFIG_NO_HZ in stm32_defconfig

Changes since v6:
-----------------
 - serial: Fix locking in case of sysrq (Vladimir)
 - Rebase on top of v4.1-rc1
 - Apply Acked-by and Reviewed-by
 - Clean-up stm32_defconfig

Changes since v5:
-----------------
 - Change st,hw-flow-ctrl property to auto-flow-control (Rob)
 - Constify stm32_uart_ops (Joe)
 - Propagate request_irq error in USART driver (Andy)
 - Applies Acked-by and Reviewed-by (Rob, Peter)

Changes since v4:
-----------------
 - Cosmetic changes in USART driver (Andy)
 - Apply Acks on reset driver & bindings (Philipp & Rob)

Changes since v3:
-----------------
 - Fix and simplify error path in ARMv7-M Systick driver (Daniel)
 - Improve reset bindings documentation (Philipp)
 - Fix trailing lines anf typos in reset driver & doc (Philipp & Chanwoo)
 - Fix MODULE_LICENCE in USART driver (Paul)
 - Refactor USART baudrate calculation (Peter & Andy)
 - Fix error path in USART init (Peter & Russell)
 - Fix HW flow control in USART driver (Peter)
 - Fix serial port type number to unused one (Peter)
 - Applies Chanwoo's Tested-by on the series

Changes since v2:
-----------------
 - Remove pinctrl driver from the series. 
 - Remove reset_controller_of_init(), and reset the timers in the bootloader
 - Add HW flow contrl property for serial driver
 - Lots of changes in the DTS file, as per Andreas recommendations
 - Some Kconfig clean-ups
 - Adapt the config to be compatible with Andreas' bootwrapper, except UART port.
 - Various fixes in documentation

Changes since v1:
-----------------
 - Move bindings documentation in their own patches (Andreas)
 - Rename ARM System timer to armv7m-systick (Rob)
 - Add clock-frequency property handling in armv7m-systick (Rob)
 - Re-factor the reset controllers into a single controller (Philipp)
 - Add kerneldoc to reset_controller_of_init (Philipp)
 - Add named constants in include/dt-bindings/reset/ (Philipp)
 - Make pinctrl driver to depend on ARCH_STM32 or COMPILE_TEST (Geert)
 - Introduce CPUV7M_NUM_IRQ config flag to indicate the number of interrupts
supported by the MCU, in order to limit memory waste in vectors' table (Uwe)

Maxime Coquelin (16):
  scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP
    Kernel
  ARM: ARMv7-M: Enlarge vector table up to 256 entries
  dt-bindings: Document the ARM System timer bindings
  clocksource/drivers: Add ARM System timer driver
  dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include
    file
  dt-bindings: Document the STM32 reset bindings
  drivers: reset: Add STM32 reset driver
  dt-bindings: Document the STM32 timer bindings
  clockevents/drivers: Add STM32 Timer driver
  dt-bindings: Document the STM32 USART bindings
  serial: stm32-usart: Add STM32 USART Driver
  ARM: Add STM32 family machine
  ARM: dts: Add ARM System timer as clocksource in armv7m
  ARM: dts: Introduce STM32F429 MCU
  ARM: configs: Add STM32 defconfig
  MAINTAINERS: Add entry for STM32 MCUs

 Documentation/arm/stm32/overview.txt               |  32 +
 Documentation/arm/stm32/stm32f429-overview.txt     |  22 +
 .../devicetree/bindings/arm/armv7m_systick.txt     |  26 +
 .../devicetree/bindings/reset/st,stm32-rcc.txt     |  50 ++
 .../devicetree/bindings/serial/st,stm32-usart.txt  |  32 +
 .../devicetree/bindings/timer/st,stm32-timer.txt   |  22 +
 MAINTAINERS                                        |   8 +
 arch/arm/Kconfig                                   |  18 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/armv7-m.dtsi                     |   6 +
 arch/arm/boot/dts/stm32f429-disco.dts              |  71 ++
 arch/arm/boot/dts/stm32f429.dtsi                   | 227 +++++++
 arch/arm/configs/stm32_defconfig                   |  70 ++
 arch/arm/kernel/entry-v7m.S                        |  13 +-
 arch/arm/mach-stm32/Makefile                       |   1 +
 arch/arm/mach-stm32/Makefile.boot                  |   3 +
 arch/arm/mach-stm32/board-dt.c                     |  19 +
 arch/arm/mm/Kconfig                                |  15 +
 drivers/clocksource/Kconfig                        |  15 +
 drivers/clocksource/Makefile                       |   2 +
 drivers/clocksource/armv7m_systick.c               |  79 +++
 drivers/clocksource/timer-stm32.c                  | 184 +++++
 drivers/reset/Makefile                             |   1 +
 drivers/reset/reset-stm32.c                        | 124 ++++
 drivers/tty/serial/Kconfig                         |  17 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/stm32-usart.c                   | 739 +++++++++++++++++++++
 include/dt-bindings/mfd/stm32f4-rcc.h              |  92 +++
 include/uapi/linux/serial_core.h                   |   3 +
 scripts/link-vmlinux.sh                            |   2 +-
 31 files changed, 1891 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/arm/stm32/overview.txt
 create mode 100644 Documentation/arm/stm32/stm32f429-overview.txt
 create mode 100644 Documentation/devicetree/bindings/arm/armv7m_systick.txt
 create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
 create mode 100644 Documentation/devicetree/bindings/serial/st,stm32-usart.txt
 create mode 100644 Documentation/devicetree/bindings/timer/st,stm32-timer.txt
 create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
 create mode 100644 arch/arm/boot/dts/stm32f429.dtsi
 create mode 100644 arch/arm/configs/stm32_defconfig
 create mode 100644 arch/arm/mach-stm32/Makefile
 create mode 100644 arch/arm/mach-stm32/Makefile.boot
 create mode 100644 arch/arm/mach-stm32/board-dt.c
 create mode 100644 drivers/clocksource/armv7m_systick.c
 create mode 100644 drivers/clocksource/timer-stm32.c
 create mode 100644 drivers/reset/reset-stm32.c
 create mode 100644 drivers/tty/serial/stm32-usart.c
 create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h

-- 
1.9.1

[PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Maxime Coquelin]

When Kernel is executed in place from ROM, the symbol addresses can be
lower than the page offset.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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

[PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Maxime Coquelin]

When Kernel is executed in place from ROM, the symbol addresses can be
lower than the page offset.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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

[PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Maxime Coquelin]

When Kernel is executed in place from ROM, the symbol addresses can be
lower than the page offset.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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

[PATCH v8 02/16] ARM: ARMv7-M: Enlarge vector table up to 256 entries

[Maxime Coquelin]

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 <u.kleine-koenig@pengutronix.de>
Acked-by: Stefan Agner <stefan@agner.ch>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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

[PATCH v8 02/16] ARM: ARMv7-M: Enlarge vector table up to 256 entries

[Maxime Coquelin]

>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 <u.kleine-koenig@pengutronix.de>
Acked-by: Stefan Agner <stefan@agner.ch>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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

[PATCH v8 02/16] ARM: ARMv7-M: Enlarge vector table up to 256 entries

[Maxime Coquelin]

[PATCH v8 02/16] ARM: ARMv7-M: Enlarge vector table up to 256 entries

[Maxime Coquelin]

>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 <u.kleine-koenig@pengutronix.de>
Acked-by: Stefan Agner <stefan@agner.ch>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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

[PATCH v8 03/16] dt-bindings: Document the ARM System timer bindings

[Maxime Coquelin]

This adds documentation of device tree bindings for the
ARM System timer.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../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

[PATCH v8 03/16] dt-bindings: Document the ARM System timer bindings

[Maxime Coquelin]

This adds documentation of device tree bindings for the
ARM System timer.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../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

[PATCH v8 03/16] dt-bindings: Document the ARM System timer bindings

[Maxime Coquelin]

This adds documentation of device tree bindings for the
ARM System timer.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../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 at e000e010 {
+	compatible = "arm,armv7m-systick";
+	reg = <0xe000e010 0x10>;
+	clocks = <&clk_systick>;
+};
+
+systick: timer at e000e010 {
+	compatible = "arm,armv7m-systick";
+	reg = <0xe000e010 0x10>;
+	clock-frequency = <90000000>;
+};
-- 
1.9.1

[PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

This patch adds clocksource support for ARMv7-M's System timer,
also known as SysTick.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+ * 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

[PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

This patch adds clocksource support for ARMv7-M's System timer,
also known as SysTick.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+ * 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

[PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

This patch adds clocksource support for ARMv7-M's System timer,
also known as SysTick.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+ * 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

[PATCH v8 05/16] dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include file

[Maxime Coquelin]

Ths patch lists STM32F4's RCC numeric constants.
It will be used by clock and reset drivers, and DT bindings.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 include/dt-bindings/mfd/stm32f4-rcc.h | 92 +++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h

diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
new file mode 100644
index 0000000..2f7ab9c
--- /dev/null
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -0,0 +1,92 @@
+/*
+ * This header provides constants for the STM32F4 RCC IP
+ */
+
+#ifndef _DT_BINDINGS_MFD_STM32F4_RCC_H
+#define _DT_BINDINGS_MFD_STM32F4_RCC_H
+
+/* AHB1 */
+#define STM32F4_RCC_AHB1_GPIOA	0
+#define STM32F4_RCC_AHB1_GPIOB	1
+#define STM32F4_RCC_AHB1_GPIOC	2
+#define STM32F4_RCC_AHB1_GPIOD	3
+#define STM32F4_RCC_AHB1_GPIOE	4
+#define STM32F4_RCC_AHB1_GPIOF	5
+#define STM32F4_RCC_AHB1_GPIOG	6
+#define STM32F4_RCC_AHB1_GPIOH	7
+#define STM32F4_RCC_AHB1_GPIOI	8
+#define STM32F4_RCC_AHB1_GPIOJ	9
+#define STM32F4_RCC_AHB1_GPIOK	10
+#define STM32F4_RCC_AHB1_CRC	12
+#define STM32F4_RCC_AHB1_DMA1	21
+#define STM32F4_RCC_AHB1_DMA2	22
+#define STM32F4_RCC_AHB1_DMA2D	23
+#define STM32F4_RCC_AHB1_ETHMAC	25
+#define STM32F4_RCC_AHB1_OTGHS	29
+
+#define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8))
+
+/* AHB2 */
+#define STM32F4_RCC_AHB2_DCMI	0
+#define STM32F4_RCC_AHB2_CRYP	4
+#define STM32F4_RCC_AHB2_HASH	5
+#define STM32F4_RCC_AHB2_RNG	6
+#define STM32F4_RCC_AHB2_OTGFS	7
+
+#define STM32F4_AHB2_RESET(bit)	(STM32F4_RCC_AHB2_##bit + (0x14 * 8))
+
+/* AHB3 */
+#define STM32F4_RCC_AHB3_FMC	0
+
+#define STM32F4_AHB3_RESET(bit)	(STM32F4_RCC_AHB3_##bit + (0x18 * 8))
+
+/* APB1 */
+#define STM32F4_RCC_APB1_TIM2	0
+#define STM32F4_RCC_APB1_TIM3	1
+#define STM32F4_RCC_APB1_TIM4	2
+#define STM32F4_RCC_APB1_TIM5	3
+#define STM32F4_RCC_APB1_TIM6	4
+#define STM32F4_RCC_APB1_TIM7	5
+#define STM32F4_RCC_APB1_TIM12	6
+#define STM32F4_RCC_APB1_TIM13	7
+#define STM32F4_RCC_APB1_TIM14	8
+#define STM32F4_RCC_APB1_WWDG	11
+#define STM32F4_RCC_APB1_SPI2	14
+#define STM32F4_RCC_APB1_SPI3	15
+#define STM32F4_RCC_APB1_UART2	17
+#define STM32F4_RCC_APB1_UART3	18
+#define STM32F4_RCC_APB1_UART4	19
+#define STM32F4_RCC_APB1_UART5	20
+#define STM32F4_RCC_APB1_I2C1	21
+#define STM32F4_RCC_APB1_I2C2	22
+#define STM32F4_RCC_APB1_I2C3	23
+#define STM32F4_RCC_APB1_CAN1	25
+#define STM32F4_RCC_APB1_CAN2	26
+#define STM32F4_RCC_APB1_PWR	28
+#define STM32F4_RCC_APB1_DAC	29
+#define STM32F4_RCC_APB1_UART7	30
+#define STM32F4_RCC_APB1_UART8	31
+
+#define STM32F4_APB1_RESET(bit)	(STM32F4_RCC_APB1_##bit + (0x20 * 8))
+
+/* APB2 */
+#define STM32F4_RCC_APB2_TIM1	0
+#define STM32F4_RCC_APB2_TIM8	1
+#define STM32F4_RCC_APB2_USART1	4
+#define STM32F4_RCC_APB2_USART6	5
+#define STM32F4_RCC_APB2_ADC	8
+#define STM32F4_RCC_APB2_SDIO	11
+#define STM32F4_RCC_APB2_SPI1	12
+#define STM32F4_RCC_APB2_SPI4	13
+#define STM32F4_RCC_APB2_SYSCFG	14
+#define STM32F4_RCC_APB2_TIM9	16
+#define STM32F4_RCC_APB2_TIM10	17
+#define STM32F4_RCC_APB2_TIM11	18
+#define STM32F4_RCC_APB2_SPI5	20
+#define STM32F4_RCC_APB2_SPI6	21
+#define STM32F4_RCC_APB2_SAI1	22
+#define STM32F4_RCC_APB2_LTDC	26
+
+#define STM32F4_APB2_RESET(bit)	(STM32F4_RCC_APB2_##bit + (0x24 * 8))
+
+#endif /* _DT_BINDINGS_MFD_STM32F4_RCC_H */
-- 
1.9.1

[PATCH v8 05/16] dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include file

[Maxime Coquelin]

Ths patch lists STM32F4's RCC numeric constants.
It will be used by clock and reset drivers, and DT bindings.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 include/dt-bindings/mfd/stm32f4-rcc.h | 92 +++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h

diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
new file mode 100644
index 0000000..2f7ab9c
--- /dev/null
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -0,0 +1,92 @@
+/*
+ * This header provides constants for the STM32F4 RCC IP
+ */
+
+#ifndef _DT_BINDINGS_MFD_STM32F4_RCC_H
+#define _DT_BINDINGS_MFD_STM32F4_RCC_H
+
+/* AHB1 */
+#define STM32F4_RCC_AHB1_GPIOA	0
+#define STM32F4_RCC_AHB1_GPIOB	1
+#define STM32F4_RCC_AHB1_GPIOC	2
+#define STM32F4_RCC_AHB1_GPIOD	3
+#define STM32F4_RCC_AHB1_GPIOE	4
+#define STM32F4_RCC_AHB1_GPIOF	5
+#define STM32F4_RCC_AHB1_GPIOG	6
+#define STM32F4_RCC_AHB1_GPIOH	7
+#define STM32F4_RCC_AHB1_GPIOI	8
+#define STM32F4_RCC_AHB1_GPIOJ	9
+#define STM32F4_RCC_AHB1_GPIOK	10
+#define STM32F4_RCC_AHB1_CRC	12
+#define STM32F4_RCC_AHB1_DMA1	21
+#define STM32F4_RCC_AHB1_DMA2	22
+#define STM32F4_RCC_AHB1_DMA2D	23
+#define STM32F4_RCC_AHB1_ETHMAC	25
+#define STM32F4_RCC_AHB1_OTGHS	29
+
+#define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8))
+
+/* AHB2 */
+#define STM32F4_RCC_AHB2_DCMI	0
+#define STM32F4_RCC_AHB2_CRYP	4
+#define STM32F4_RCC_AHB2_HASH	5
+#define STM32F4_RCC_AHB2_RNG	6
+#define STM32F4_RCC_AHB2_OTGFS	7
+
+#define STM32F4_AHB2_RESET(bit)	(STM32F4_RCC_AHB2_##bit + (0x14 * 8))
+
+/* AHB3 */
+#define STM32F4_RCC_AHB3_FMC	0
+
+#define STM32F4_AHB3_RESET(bit)	(STM32F4_RCC_AHB3_##bit + (0x18 * 8))
+
+/* APB1 */
+#define STM32F4_RCC_APB1_TIM2	0
+#define STM32F4_RCC_APB1_TIM3	1
+#define STM32F4_RCC_APB1_TIM4	2
+#define STM32F4_RCC_APB1_TIM5	3
+#define STM32F4_RCC_APB1_TIM6	4
+#define STM32F4_RCC_APB1_TIM7	5
+#define STM32F4_RCC_APB1_TIM12	6
+#define STM32F4_RCC_APB1_TIM13	7
+#define STM32F4_RCC_APB1_TIM14	8
+#define STM32F4_RCC_APB1_WWDG	11
+#define STM32F4_RCC_APB1_SPI2	14
+#define STM32F4_RCC_APB1_SPI3	15
+#define STM32F4_RCC_APB1_UART2	17
+#define STM32F4_RCC_APB1_UART3	18
+#define STM32F4_RCC_APB1_UART4	19
+#define STM32F4_RCC_APB1_UART5	20
+#define STM32F4_RCC_APB1_I2C1	21
+#define STM32F4_RCC_APB1_I2C2	22
+#define STM32F4_RCC_APB1_I2C3	23
+#define STM32F4_RCC_APB1_CAN1	25
+#define STM32F4_RCC_APB1_CAN2	26
+#define STM32F4_RCC_APB1_PWR	28
+#define STM32F4_RCC_APB1_DAC	29
+#define STM32F4_RCC_APB1_UART7	30
+#define STM32F4_RCC_APB1_UART8	31
+
+#define STM32F4_APB1_RESET(bit)	(STM32F4_RCC_APB1_##bit + (0x20 * 8))
+
+/* APB2 */
+#define STM32F4_RCC_APB2_TIM1	0
+#define STM32F4_RCC_APB2_TIM8	1
+#define STM32F4_RCC_APB2_USART1	4
+#define STM32F4_RCC_APB2_USART6	5
+#define STM32F4_RCC_APB2_ADC	8
+#define STM32F4_RCC_APB2_SDIO	11
+#define STM32F4_RCC_APB2_SPI1	12
+#define STM32F4_RCC_APB2_SPI4	13
+#define STM32F4_RCC_APB2_SYSCFG	14
+#define STM32F4_RCC_APB2_TIM9	16
+#define STM32F4_RCC_APB2_TIM10	17
+#define STM32F4_RCC_APB2_TIM11	18
+#define STM32F4_RCC_APB2_SPI5	20
+#define STM32F4_RCC_APB2_SPI6	21
+#define STM32F4_RCC_APB2_SAI1	22
+#define STM32F4_RCC_APB2_LTDC	26
+
+#define STM32F4_APB2_RESET(bit)	(STM32F4_RCC_APB2_##bit + (0x24 * 8))
+
+#endif /* _DT_BINDINGS_MFD_STM32F4_RCC_H */
-- 
1.9.1

[PATCH v8 05/16] dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include file

[Maxime Coquelin]

Ths patch lists STM32F4's RCC numeric constants.
It will be used by clock and reset drivers, and DT bindings.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 include/dt-bindings/mfd/stm32f4-rcc.h | 92 +++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h

diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
new file mode 100644
index 0000000..2f7ab9c
--- /dev/null
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -0,0 +1,92 @@
+/*
+ * This header provides constants for the STM32F4 RCC IP
+ */
+
+#ifndef _DT_BINDINGS_MFD_STM32F4_RCC_H
+#define _DT_BINDINGS_MFD_STM32F4_RCC_H
+
+/* AHB1 */
+#define STM32F4_RCC_AHB1_GPIOA	0
+#define STM32F4_RCC_AHB1_GPIOB	1
+#define STM32F4_RCC_AHB1_GPIOC	2
+#define STM32F4_RCC_AHB1_GPIOD	3
+#define STM32F4_RCC_AHB1_GPIOE	4
+#define STM32F4_RCC_AHB1_GPIOF	5
+#define STM32F4_RCC_AHB1_GPIOG	6
+#define STM32F4_RCC_AHB1_GPIOH	7
+#define STM32F4_RCC_AHB1_GPIOI	8
+#define STM32F4_RCC_AHB1_GPIOJ	9
+#define STM32F4_RCC_AHB1_GPIOK	10
+#define STM32F4_RCC_AHB1_CRC	12
+#define STM32F4_RCC_AHB1_DMA1	21
+#define STM32F4_RCC_AHB1_DMA2	22
+#define STM32F4_RCC_AHB1_DMA2D	23
+#define STM32F4_RCC_AHB1_ETHMAC	25
+#define STM32F4_RCC_AHB1_OTGHS	29
+
+#define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8))
+
+/* AHB2 */
+#define STM32F4_RCC_AHB2_DCMI	0
+#define STM32F4_RCC_AHB2_CRYP	4
+#define STM32F4_RCC_AHB2_HASH	5
+#define STM32F4_RCC_AHB2_RNG	6
+#define STM32F4_RCC_AHB2_OTGFS	7
+
+#define STM32F4_AHB2_RESET(bit)	(STM32F4_RCC_AHB2_##bit + (0x14 * 8))
+
+/* AHB3 */
+#define STM32F4_RCC_AHB3_FMC	0
+
+#define STM32F4_AHB3_RESET(bit)	(STM32F4_RCC_AHB3_##bit + (0x18 * 8))
+
+/* APB1 */
+#define STM32F4_RCC_APB1_TIM2	0
+#define STM32F4_RCC_APB1_TIM3	1
+#define STM32F4_RCC_APB1_TIM4	2
+#define STM32F4_RCC_APB1_TIM5	3
+#define STM32F4_RCC_APB1_TIM6	4
+#define STM32F4_RCC_APB1_TIM7	5
+#define STM32F4_RCC_APB1_TIM12	6
+#define STM32F4_RCC_APB1_TIM13	7
+#define STM32F4_RCC_APB1_TIM14	8
+#define STM32F4_RCC_APB1_WWDG	11
+#define STM32F4_RCC_APB1_SPI2	14
+#define STM32F4_RCC_APB1_SPI3	15
+#define STM32F4_RCC_APB1_UART2	17
+#define STM32F4_RCC_APB1_UART3	18
+#define STM32F4_RCC_APB1_UART4	19
+#define STM32F4_RCC_APB1_UART5	20
+#define STM32F4_RCC_APB1_I2C1	21
+#define STM32F4_RCC_APB1_I2C2	22
+#define STM32F4_RCC_APB1_I2C3	23
+#define STM32F4_RCC_APB1_CAN1	25
+#define STM32F4_RCC_APB1_CAN2	26
+#define STM32F4_RCC_APB1_PWR	28
+#define STM32F4_RCC_APB1_DAC	29
+#define STM32F4_RCC_APB1_UART7	30
+#define STM32F4_RCC_APB1_UART8	31
+
+#define STM32F4_APB1_RESET(bit)	(STM32F4_RCC_APB1_##bit + (0x20 * 8))
+
+/* APB2 */
+#define STM32F4_RCC_APB2_TIM1	0
+#define STM32F4_RCC_APB2_TIM8	1
+#define STM32F4_RCC_APB2_USART1	4
+#define STM32F4_RCC_APB2_USART6	5
+#define STM32F4_RCC_APB2_ADC	8
+#define STM32F4_RCC_APB2_SDIO	11
+#define STM32F4_RCC_APB2_SPI1	12
+#define STM32F4_RCC_APB2_SPI4	13
+#define STM32F4_RCC_APB2_SYSCFG	14
+#define STM32F4_RCC_APB2_TIM9	16
+#define STM32F4_RCC_APB2_TIM10	17
+#define STM32F4_RCC_APB2_TIM11	18
+#define STM32F4_RCC_APB2_SPI5	20
+#define STM32F4_RCC_APB2_SPI6	21
+#define STM32F4_RCC_APB2_SAI1	22
+#define STM32F4_RCC_APB2_LTDC	26
+
+#define STM32F4_APB2_RESET(bit)	(STM32F4_RCC_APB2_##bit + (0x24 * 8))
+
+#endif /* _DT_BINDINGS_MFD_STM32F4_RCC_H */
-- 
1.9.1

[PATCH v8 06/16] dt-bindings: Document the STM32 reset bindings

[Maxime Coquelin]

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

Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 .../devicetree/bindings/reset/st,stm32-rcc.txt     | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt

diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
new file mode 100644
index 0000000..333080c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
@@ -0,0 +1,50 @@
+STMicroelectronics STM32 Peripheral Reset Controller
+====================================================
+
+The RCC IP is both a reset and a clock controller. This documentation only
+documents the reset part.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,stm32-rcc"
+- reg: should be register base and length as documented in the
+  datasheet
+- #reset-cells: 1, see below
+
+example:
+
+rcc: reset@40023800 {
+	#reset-cells = <1>;
+	compatible = "st,stm32-rcc";
+	reg = <0x40023800 0x400>;
+};
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the reset device node and an index specifying
+which channel to use.
+The index is the bit number within the RCC registers bank, starting from RCC
+base address.
+It is calculated as: index = register_offset / 4 * 32 + bit_offset.
+Where bit_offset is the bit offset within the register.
+For example, for CRC reset:
+  crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
+
+To simplify the usagen and to share bit definition with the clock driver of
+the RCC IP, macros are available to generate the index in human-readble
+format.
+
+For STM32F4 series, the macro are available here:
+ - include/dt-bindings/mfd/stm32f4-rcc.h
+
+example:
+
+	timer2 {
+		resets			= <&rcc STM32F4_APB1_RESET(TIM2)>;
+	};
+
+
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 06/16] dt-bindings: Document the STM32 reset bindings

[Maxime Coquelin]

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

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../devicetree/bindings/reset/st,stm32-rcc.txt     | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt

diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
new file mode 100644
index 0000000..333080c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
@@ -0,0 +1,50 @@
+STMicroelectronics STM32 Peripheral Reset Controller
+====================================================
+
+The RCC IP is both a reset and a clock controller. This documentation only
+documents the reset part.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,stm32-rcc"
+- reg: should be register base and length as documented in the
+  datasheet
+- #reset-cells: 1, see below
+
+example:
+
+rcc: reset@40023800 {
+	#reset-cells = <1>;
+	compatible = "st,stm32-rcc";
+	reg = <0x40023800 0x400>;
+};
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the reset device node and an index specifying
+which channel to use.
+The index is the bit number within the RCC registers bank, starting from RCC
+base address.
+It is calculated as: index = register_offset / 4 * 32 + bit_offset.
+Where bit_offset is the bit offset within the register.
+For example, for CRC reset:
+  crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
+
+To simplify the usagen and to share bit definition with the clock driver of
+the RCC IP, macros are available to generate the index in human-readble
+format.
+
+For STM32F4 series, the macro are available here:
+ - include/dt-bindings/mfd/stm32f4-rcc.h
+
+example:
+
+	timer2 {
+		resets			= <&rcc STM32F4_APB1_RESET(TIM2)>;
+	};
+
+
-- 
1.9.1

[PATCH v8 06/16] dt-bindings: Document the STM32 reset bindings

[Maxime Coquelin]

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

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../devicetree/bindings/reset/st,stm32-rcc.txt     | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt

diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
new file mode 100644
index 0000000..333080c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
@@ -0,0 +1,50 @@
+STMicroelectronics STM32 Peripheral Reset Controller
+====================================================
+
+The RCC IP is both a reset and a clock controller. This documentation only
+documents the reset part.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,stm32-rcc"
+- reg: should be register base and length as documented in the
+  datasheet
+- #reset-cells: 1, see below
+
+example:
+
+rcc: reset at 40023800 {
+	#reset-cells = <1>;
+	compatible = "st,stm32-rcc";
+	reg = <0x40023800 0x400>;
+};
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the reset device node and an index specifying
+which channel to use.
+The index is the bit number within the RCC registers bank, starting from RCC
+base address.
+It is calculated as: index = register_offset / 4 * 32 + bit_offset.
+Where bit_offset is the bit offset within the register.
+For example, for CRC reset:
+  crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
+
+To simplify the usagen and to share bit definition with the clock driver of
+the RCC IP, macros are available to generate the index in human-readble
+format.
+
+For STM32F4 series, the macro are available here:
+ - include/dt-bindings/mfd/stm32f4-rcc.h
+
+example:
+
+	timer2 {
+		resets			= <&rcc STM32F4_APB1_RESET(TIM2)>;
+	};
+
+
-- 
1.9.1

[PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

The STM32 MCUs family IPs can be reset by accessing some registers
from the RCC block.

The list of available reset lines is documented in the DT bindings.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+ * 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 <maxime.coquelin@gmail.com>");
+MODULE_DESCRIPTION("STM32 MCUs Reset Controller Driver");
+MODULE_LICENSE("GPL");
-- 
1.9.1

[PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

The STM32 MCUs family IPs can be reset by accessing some registers
from the RCC block.

The list of available reset lines is documented in the DT bindings.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+ * 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 <maxime.coquelin@gmail.com>");
+MODULE_DESCRIPTION("STM32 MCUs Reset Controller Driver");
+MODULE_LICENSE("GPL");
-- 
1.9.1

[PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

The STM32 MCUs family IPs can be reset by accessing some registers
from the RCC block.

The list of available reset lines is documented in the DT bindings.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+ * 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 <maxime.coquelin@gmail.com>");
+MODULE_DESCRIPTION("STM32 MCUs Reset Controller Driver");
+MODULE_LICENSE("GPL");
-- 
1.9.1

[PATCH v8 08/16] dt-bindings: Document the STM32 timer bindings

[Maxime Coquelin]

This adds documentation of device tree bindings for the
STM32 timer.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../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

[PATCH v8 08/16] dt-bindings: Document the STM32 timer bindings

[Maxime Coquelin]

This adds documentation of device tree bindings for the
STM32 timer.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../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

[PATCH v8 08/16] dt-bindings: Document the STM32 timer bindings

[Maxime Coquelin]

This adds documentation of device tree bindings for the
STM32 timer.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../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 at 40000c00 {
+	compatible = "st,stm32-timer";
+	reg = <0x40000c00 0x400>;
+	interrupts = <50>;
+	resets = <&rrc 259>;
+	clocks = <&clk_pmtr1>;
+};
-- 
1.9.1

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

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 <linus.walleij@linaro.org>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+ * 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

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

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 <linus.walleij@linaro.org>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+ * 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

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

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 <linus.walleij@linaro.org>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+ * 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

[PATCH v8 10/16] dt-bindings: Document the STM32 USART bindings

[Maxime Coquelin]

This adds documentation of device tree bindings for the
STM32 USART

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../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

[PATCH v8 10/16] dt-bindings: Document the STM32 USART bindings

[Maxime Coquelin]

This adds documentation of device tree bindings for the
STM32 USART

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../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

[PATCH v8 10/16] dt-bindings: Document the STM32 USART bindings

[Maxime Coquelin]

This adds documentation of device tree bindings for the
STM32 USART

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 .../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 at 40004c00 {
+	compatible = "st,stm32-uart";
+	reg = <0x40004c00 0x400>;
+	interrupts = <52>;
+	clocks = <&clk_pclk1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usart4>;
+};
+
+usart2: serial at 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

[PATCH v8 11/16] serial: stm32-usart: Add STM32 USART Driver

[Maxime Coquelin]

This drivers adds support to the STM32 USART controller, which is a
standard serial driver.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 drivers/tty/serial/Kconfig       |  17 +
 drivers/tty/serial/Makefile      |   1 +
 drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |   3 +
 4 files changed, 760 insertions(+)
 create mode 100644 drivers/tty/serial/stm32-usart.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index f8120c1..7eb62f1 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1589,6 +1589,23 @@ config SERIAL_SPRD_CONSOLE
 	  with "earlycon" on the kernel command line. The console is
 	  enabled when early_param is processed.
 
+config SERIAL_STM32
+	tristate "STMicroelectronics STM32 serial port support"
+	select SERIAL_CORE
+	depends on ARM || COMPILE_TEST
+	help
+	  This driver is for the on-chip Serial Controller on
+	  STMicroelectronics STM32 MCUs.
+	  USART supports Rx & Tx functionality.
+	  It support all industry standard baud rates.
+
+	  If unsure, say N.
+
+config SERIAL_STM32_CONSOLE
+	bool "Support for console on STM32"
+	depends on SERIAL_STM32=y
+	select SERIAL_CORE_CONSOLE
+
 endmenu
 
 config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index c3ac3d9..61979ce 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART)	+= fsl_lpuart.o
 obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
+obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
new file mode 100644
index 0000000..4a6eab6
--- /dev/null
+++ b/drivers/tty/serial/stm32-usart.c
@@ -0,0 +1,739 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author:  Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ * Inspired by st-asc.c from STMicroelectronics (c)
+ */
+
+#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#include <linux/module.h>
+#include <linux/serial.h>
+#include <linux/console.h>
+#include <linux/sysrq.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+#include <linux/delay.h>
+#include <linux/spinlock.h>
+#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/serial_core.h>
+#include <linux/clk.h>
+
+#define DRIVER_NAME "stm32-usart"
+
+/* Register offsets */
+#define USART_SR		0x00
+#define USART_DR		0x04
+#define USART_BRR		0x08
+#define USART_CR1		0x0c
+#define USART_CR2		0x10
+#define USART_CR3		0x14
+#define USART_GTPR		0x18
+
+/* USART_SR */
+#define USART_SR_PE		BIT(0)
+#define USART_SR_FE		BIT(1)
+#define USART_SR_NF		BIT(2)
+#define USART_SR_ORE		BIT(3)
+#define USART_SR_IDLE		BIT(4)
+#define USART_SR_RXNE		BIT(5)
+#define USART_SR_TC		BIT(6)
+#define USART_SR_TXE		BIT(7)
+#define USART_SR_LBD		BIT(8)
+#define USART_SR_CTS		BIT(9)
+#define USART_SR_ERR_MASK	(USART_SR_LBD | USART_SR_ORE | \
+				 USART_SR_FE | USART_SR_PE)
+/* Dummy bits */
+#define USART_SR_DUMMY_RX	BIT(16)
+
+/* USART_DR */
+#define USART_DR_MASK		GENMASK(8, 0)
+
+/* USART_BRR */
+#define USART_BRR_DIV_F_MASK	GENMASK(3, 0)
+#define USART_BRR_DIV_M_MASK	GENMASK(15, 4)
+#define USART_BRR_DIV_M_SHIFT	4
+
+/* USART_CR1 */
+#define USART_CR1_SBK		BIT(0)
+#define USART_CR1_RWU		BIT(1)
+#define USART_CR1_RE		BIT(2)
+#define USART_CR1_TE		BIT(3)
+#define USART_CR1_IDLEIE	BIT(4)
+#define USART_CR1_RXNEIE	BIT(5)
+#define USART_CR1_TCIE		BIT(6)
+#define USART_CR1_TXEIE		BIT(7)
+#define USART_CR1_PEIE		BIT(8)
+#define USART_CR1_PS		BIT(9)
+#define USART_CR1_PCE		BIT(10)
+#define USART_CR1_WAKE		BIT(11)
+#define USART_CR1_M		BIT(12)
+#define USART_CR1_UE		BIT(13)
+#define USART_CR1_OVER8		BIT(15)
+#define USART_CR1_IE_MASK	GENMASK(8, 4)
+
+/* USART_CR2 */
+#define USART_CR2_ADD_MASK	GENMASK(3, 0)
+#define USART_CR2_LBDL		BIT(5)
+#define USART_CR2_LBDIE		BIT(6)
+#define USART_CR2_LBCL		BIT(8)
+#define USART_CR2_CPHA		BIT(9)
+#define USART_CR2_CPOL		BIT(10)
+#define USART_CR2_CLKEN		BIT(11)
+#define USART_CR2_STOP_2B	BIT(13)
+#define USART_CR2_STOP_MASK	GENMASK(13, 12)
+#define USART_CR2_LINEN		BIT(14)
+
+/* USART_CR3 */
+#define USART_CR3_EIE		BIT(0)
+#define USART_CR3_IREN		BIT(1)
+#define USART_CR3_IRLP		BIT(2)
+#define USART_CR3_HDSEL		BIT(3)
+#define USART_CR3_NACK		BIT(4)
+#define USART_CR3_SCEN		BIT(5)
+#define USART_CR3_DMAR		BIT(6)
+#define USART_CR3_DMAT		BIT(7)
+#define USART_CR3_RTSE		BIT(8)
+#define USART_CR3_CTSE		BIT(9)
+#define USART_CR3_CTSIE		BIT(10)
+#define USART_CR3_ONEBIT	BIT(11)
+
+/* USART_GTPR */
+#define USART_GTPR_PSC_MASK	GENMASK(7, 0)
+#define USART_GTPR_GT_MASK	GENMASK(15, 8)
+
+#define DRIVER_NAME "stm32-usart"
+#define STM32_SERIAL_NAME "ttyS"
+#define STM32_MAX_PORTS 6
+
+struct stm32_port {
+	struct uart_port port;
+	struct clk *clk;
+	bool hw_flow_control;
+};
+
+static struct stm32_port stm32_ports[STM32_MAX_PORTS];
+static struct uart_driver stm32_usart_driver;
+
+static void stm32_stop_tx(struct uart_port *port);
+
+static inline struct stm32_port *to_stm32_port(struct uart_port *port)
+{
+	return container_of(port, struct stm32_port, port);
+}
+
+static void stm32_set_bits(struct uart_port *port, u32 reg, u32 bits)
+{
+	u32 val;
+
+	val = readl_relaxed(port->membase + reg);
+	val |= bits;
+	writel_relaxed(val, port->membase + reg);
+}
+
+static void stm32_clr_bits(struct uart_port *port, u32 reg, u32 bits)
+{
+	u32 val;
+
+	val = readl_relaxed(port->membase + reg);
+	val &= ~bits;
+	writel_relaxed(val, port->membase + reg);
+}
+
+static void stm32_receive_chars(struct uart_port *port)
+{
+	struct tty_port *tport = &port->state->port;
+	unsigned long c;
+	u32 sr;
+	char flag;
+
+	if (port->irq_wake)
+		pm_wakeup_event(tport->tty->dev, 0);
+
+	while ((sr = readl_relaxed(port->membase + USART_SR)) & USART_SR_RXNE) {
+		sr |= USART_SR_DUMMY_RX;
+		c = readl_relaxed(port->membase + USART_DR);
+		flag = TTY_NORMAL;
+		port->icount.rx++;
+
+		if (sr & USART_SR_ERR_MASK) {
+			if (sr & USART_SR_LBD) {
+				port->icount.brk++;
+				if (uart_handle_break(port))
+					continue;
+			} else if (sr & USART_SR_ORE) {
+				port->icount.overrun++;
+			} else if (sr & USART_SR_PE) {
+				port->icount.parity++;
+			} else if (sr & USART_SR_FE) {
+				port->icount.frame++;
+			}
+
+			sr &= port->read_status_mask;
+
+			if (sr & USART_SR_LBD)
+				flag = TTY_BREAK;
+			else if (sr & USART_SR_PE)
+				flag = TTY_PARITY;
+			else if (sr & USART_SR_FE)
+				flag = TTY_FRAME;
+		}
+
+		if (uart_handle_sysrq_char(port, c))
+			continue;
+		uart_insert_char(port, sr, USART_SR_ORE, c, flag);
+	}
+
+	spin_unlock(&port->lock);
+	tty_flip_buffer_push(tport);
+	spin_lock(&port->lock);
+}
+
+static void stm32_transmit_chars(struct uart_port *port)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+
+	if (port->x_char) {
+		writel_relaxed(port->x_char, port->membase + USART_DR);
+		port->x_char = 0;
+		port->icount.tx++;
+		return;
+	}
+
+	if (uart_tx_stopped(port)) {
+		stm32_stop_tx(port);
+		return;
+	}
+
+	if (uart_circ_empty(xmit)) {
+		stm32_stop_tx(port);
+		return;
+	}
+
+	writel_relaxed(xmit->buf[xmit->tail], port->membase + USART_DR);
+	xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+	port->icount.tx++;
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		stm32_stop_tx(port);
+}
+
+static irqreturn_t stm32_interrupt(int irq, void *ptr)
+{
+	struct uart_port *port = ptr;
+	u32 sr;
+
+	spin_lock(&port->lock);
+
+	sr = readl_relaxed(port->membase + USART_SR);
+
+	if (sr & USART_SR_RXNE)
+		stm32_receive_chars(port);
+
+	if (sr & USART_SR_TXE)
+		stm32_transmit_chars(port);
+
+	spin_unlock(&port->lock);
+
+	return IRQ_HANDLED;
+}
+
+static unsigned int stm32_tx_empty(struct uart_port *port)
+{
+	return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
+}
+
+static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+	if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
+		stm32_set_bits(port, USART_CR3, USART_CR3_RTSE);
+	else
+		stm32_clr_bits(port, USART_CR3, USART_CR3_RTSE);
+}
+
+static unsigned int stm32_get_mctrl(struct uart_port *port)
+{
+	/* This routine is used to get signals of: DCD, DSR, RI, and CTS */
+	return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+}
+
+/* Transmit stop */
+static void stm32_stop_tx(struct uart_port *port)
+{
+	stm32_clr_bits(port, USART_CR1, USART_CR1_TXEIE);
+}
+
+/* There are probably characters waiting to be transmitted. */
+static void stm32_start_tx(struct uart_port *port)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+
+	if (uart_circ_empty(xmit))
+		return;
+
+	stm32_set_bits(port, USART_CR1, USART_CR1_TXEIE | USART_CR1_TE);
+}
+
+/* Throttle the remote when input buffer is about to overflow. */
+static void stm32_throttle(struct uart_port *port)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/* Unthrottle the remote, the input buffer can now accept data. */
+static void stm32_unthrottle(struct uart_port *port)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	stm32_set_bits(port, USART_CR1, USART_CR1_RXNEIE);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/* Receive stop */
+static void stm32_stop_rx(struct uart_port *port)
+{
+	stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
+}
+
+/* Handle breaks - ignored by us */
+static void stm32_break_ctl(struct uart_port *port, int break_state)
+{
+}
+
+static int stm32_startup(struct uart_port *port)
+{
+	const char *name = to_platform_device(port->dev)->name;
+	u32 val;
+	int ret;
+
+	ret = request_irq(port->irq, stm32_interrupt, IRQF_NO_SUSPEND,
+			  name, port);
+	if (ret)
+		return ret;
+
+	val = USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
+	stm32_set_bits(port, USART_CR1, val);
+
+	return 0;
+}
+
+static void stm32_shutdown(struct uart_port *port)
+{
+	u32 val;
+
+	val = USART_CR1_TXEIE | USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
+	stm32_set_bits(port, USART_CR1, val);
+
+	free_irq(port->irq, port);
+}
+
+static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
+			    struct ktermios *old)
+{
+	struct stm32_port *stm32_port = to_stm32_port(port);
+	unsigned int baud;
+	u32 usartdiv, mantissa, fraction, oversampling;
+	tcflag_t cflag = termios->c_cflag;
+	u32 cr1, cr2, cr3;
+	unsigned long flags;
+
+	if (!stm32_port->hw_flow_control)
+		cflag &= ~CRTSCTS;
+
+	baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 8);
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	/* Stop serial port and reset value */
+	writel_relaxed(0, port->membase + USART_CR1);
+
+	cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
+	cr2 = 0;
+	cr3 = 0;
+
+	if (cflag & CSTOPB)
+		cr2 |= USART_CR2_STOP_2B;
+
+	if (cflag & PARENB) {
+		cr1 |= USART_CR1_PCE;
+		if ((cflag & CSIZE) == CS8)
+			cr1 |= USART_CR1_M;
+	}
+
+	if (cflag & PARODD)
+		cr1 |= USART_CR1_PS;
+
+	port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS);
+	if (cflag & CRTSCTS) {
+		port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
+		cr3 |= USART_CR3_CTSE;
+	}
+
+	usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
+
+	/*
+	 * The USART supports 16 or 8 times oversampling.
+	 * By default we prefer 16 times oversampling, so that the receiver
+	 * has a better tolerance to clock deviations.
+	 * 8 times oversampling is only used to achieve higher speeds.
+	 */
+	if (usartdiv < 16) {
+		oversampling = 8;
+		stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
+	} else {
+		oversampling = 16;
+		stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
+	}
+
+	mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
+	fraction = usartdiv % oversampling;
+	writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
+
+	uart_update_timeout(port, cflag, baud);
+
+	port->read_status_mask = USART_SR_ORE;
+	if (termios->c_iflag & INPCK)
+		port->read_status_mask |= USART_SR_PE | USART_SR_FE;
+	if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
+		port->read_status_mask |= USART_SR_LBD;
+
+	/* Characters to ignore */
+	port->ignore_status_mask = 0;
+	if (termios->c_iflag & IGNPAR)
+		port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
+	if (termios->c_iflag & IGNBRK) {
+		port->ignore_status_mask |= USART_SR_LBD;
+		/*
+		 * If we're ignoring parity and break indicators,
+		 * ignore overruns too (for real raw support).
+		 */
+		if (termios->c_iflag & IGNPAR)
+			port->ignore_status_mask |= USART_SR_ORE;
+	}
+
+	/* Ignore all characters if CREAD is not set */
+	if ((termios->c_cflag & CREAD) == 0)
+		port->ignore_status_mask |= USART_SR_DUMMY_RX;
+
+	writel_relaxed(cr3, port->membase + USART_CR3);
+	writel_relaxed(cr2, port->membase + USART_CR2);
+	writel_relaxed(cr1, port->membase + USART_CR1);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *stm32_type(struct uart_port *port)
+{
+	return (port->type == PORT_STM32) ? DRIVER_NAME : NULL;
+}
+
+static void stm32_release_port(struct uart_port *port)
+{
+}
+
+static int stm32_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+static void stm32_config_port(struct uart_port *port, int flags)
+{
+	if (flags & UART_CONFIG_TYPE)
+		port->type = PORT_STM32;
+}
+
+static int
+stm32_verify_port(struct uart_port *port, struct serial_struct *ser)
+{
+	/* No user changeable parameters */
+	return -EINVAL;
+}
+
+static void stm32_pm(struct uart_port *port, unsigned int state,
+		unsigned int oldstate)
+{
+	struct stm32_port *stm32port = container_of(port,
+			struct stm32_port, port);
+	unsigned long flags = 0;
+
+	switch (state) {
+	case UART_PM_STATE_ON:
+		clk_prepare_enable(stm32port->clk);
+		break;
+	case UART_PM_STATE_OFF:
+		spin_lock_irqsave(&port->lock, flags);
+		stm32_clr_bits(port, USART_CR1, USART_CR1_UE);
+		spin_unlock_irqrestore(&port->lock, flags);
+		clk_disable_unprepare(stm32port->clk);
+		break;
+	}
+}
+
+static const struct uart_ops stm32_uart_ops = {
+	.tx_empty	= stm32_tx_empty,
+	.set_mctrl	= stm32_set_mctrl,
+	.get_mctrl	= stm32_get_mctrl,
+	.stop_tx	= stm32_stop_tx,
+	.start_tx	= stm32_start_tx,
+	.throttle	= stm32_throttle,
+	.unthrottle	= stm32_unthrottle,
+	.stop_rx	= stm32_stop_rx,
+	.break_ctl	= stm32_break_ctl,
+	.startup	= stm32_startup,
+	.shutdown	= stm32_shutdown,
+	.set_termios	= stm32_set_termios,
+	.pm		= stm32_pm,
+	.type		= stm32_type,
+	.release_port	= stm32_release_port,
+	.request_port	= stm32_request_port,
+	.config_port	= stm32_config_port,
+	.verify_port	= stm32_verify_port,
+};
+
+static int stm32_init_port(struct stm32_port *stm32port,
+			  struct platform_device *pdev)
+{
+	struct uart_port *port = &stm32port->port;
+	struct resource *res;
+	int ret;
+
+	port->iotype	= UPIO_MEM;
+	port->flags	= UPF_BOOT_AUTOCONF;
+	port->ops	= &stm32_uart_ops;
+	port->dev	= &pdev->dev;
+	port->irq	= platform_get_irq(pdev, 0);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	port->membase = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(port->membase))
+		return PTR_ERR(port->membase);
+	port->mapbase = res->start;
+
+	spin_lock_init(&port->lock);
+
+	stm32port->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(stm32port->clk))
+		return PTR_ERR(stm32port->clk);
+
+	/* Ensure that clk rate is correct by enabling the clk */
+	ret = clk_prepare_enable(stm32port->clk);
+	if (ret)
+		return ret;
+
+	stm32port->port.uartclk = clk_get_rate(stm32port->clk);
+	if (!stm32port->port.uartclk)
+		ret = -EINVAL;
+
+	clk_disable_unprepare(stm32port->clk);
+
+	return ret;
+}
+
+static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int id;
+
+	if (!np)
+		return NULL;
+
+	id = of_alias_get_id(np, "serial");
+	if (id < 0)
+		id = 0;
+
+	if (WARN_ON(id >= STM32_MAX_PORTS))
+		return NULL;
+
+	stm32_ports[id].hw_flow_control = of_property_read_bool(np,
+							"auto-flow-control");
+	stm32_ports[id].port.line = id;
+	return &stm32_ports[id];
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id stm32_match[] = {
+	{ .compatible = "st,stm32-usart", },
+	{ .compatible = "st,stm32-uart", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, stm32_match);
+#endif
+
+static int stm32_serial_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct stm32_port *stm32port;
+
+	stm32port = stm32_of_get_stm32_port(pdev);
+	if (!stm32port)
+		return -ENODEV;
+
+	ret = stm32_init_port(stm32port, pdev);
+	if (ret)
+		return ret;
+
+	ret = uart_add_one_port(&stm32_usart_driver, &stm32port->port);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, &stm32port->port);
+
+	return 0;
+}
+
+static int stm32_serial_remove(struct platform_device *pdev)
+{
+	struct uart_port *port = platform_get_drvdata(pdev);
+
+	return uart_remove_one_port(&stm32_usart_driver, port);
+}
+
+
+#ifdef CONFIG_SERIAL_STM32_CONSOLE
+static void stm32_console_putchar(struct uart_port *port, int ch)
+{
+	while (!(readl_relaxed(port->membase + USART_SR) & USART_SR_TXE))
+		cpu_relax();
+
+	writel_relaxed(ch, port->membase + USART_DR);
+}
+
+static void stm32_console_write(struct console *co, const char *s, unsigned cnt)
+{
+	struct uart_port *port = &stm32_ports[co->index].port;
+	unsigned long flags;
+	u32 old_cr1, new_cr1;
+	int locked = 1;
+
+	local_irq_save(flags);
+	if (port->sysrq)
+		locked = 0;
+	else if (oops_in_progress)
+		locked = spin_trylock(&port->lock);
+	else
+		spin_lock(&port->lock);
+
+	/* Save and disable interrupts */
+	old_cr1 = readl_relaxed(port->membase + USART_CR1);
+	new_cr1 = old_cr1 & ~USART_CR1_IE_MASK;
+	writel_relaxed(new_cr1, port->membase + USART_CR1);
+
+	uart_console_write(port, s, cnt, stm32_console_putchar);
+
+	/* Restore interrupt state */
+	writel_relaxed(old_cr1, port->membase + USART_CR1);
+
+	if (locked)
+		spin_unlock(&port->lock);
+	local_irq_restore(flags);
+}
+
+static int stm32_console_setup(struct console *co, char *options)
+{
+	struct stm32_port *stm32port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index >= STM32_MAX_PORTS)
+		return -ENODEV;
+
+	stm32port = &stm32_ports[co->index];
+
+	/*
+	 * This driver does not support early console initialization
+	 * (use ARM early printk support instead), so we only expect
+	 * this to be called during the uart port registration when the
+	 * driver gets probed and the port should be mapped at that point.
+	 */
+	if (stm32port->port.mapbase == 0 || stm32port->port.membase == NULL)
+		return -ENXIO;
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(&stm32port->port, co, baud, parity, bits, flow);
+}
+
+static struct console stm32_console = {
+	.name		= STM32_SERIAL_NAME,
+	.device		= uart_console_device,
+	.write		= stm32_console_write,
+	.setup		= stm32_console_setup,
+	.flags		= CON_PRINTBUFFER,
+	.index		= -1,
+	.data		= &stm32_usart_driver,
+};
+
+#define STM32_SERIAL_CONSOLE (&stm32_console)
+
+#else
+#define STM32_SERIAL_CONSOLE NULL
+#endif /* CONFIG_SERIAL_STM32_CONSOLE */
+
+static struct uart_driver stm32_usart_driver = {
+	.driver_name	= DRIVER_NAME,
+	.dev_name	= STM32_SERIAL_NAME,
+	.major		= 0,
+	.minor		= 0,
+	.nr		= STM32_MAX_PORTS,
+	.cons		= STM32_SERIAL_CONSOLE,
+};
+
+static struct platform_driver stm32_serial_driver = {
+	.probe		= stm32_serial_probe,
+	.remove		= stm32_serial_remove,
+	.driver	= {
+		.name	= DRIVER_NAME,
+		.of_match_table = of_match_ptr(stm32_match),
+	},
+};
+
+static int __init usart_init(void)
+{
+	static char banner[] __initdata = "STM32 USART driver initialized";
+	int ret;
+
+	pr_info("%s\n", banner);
+
+	ret = uart_register_driver(&stm32_usart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&stm32_serial_driver);
+	if (ret)
+		uart_unregister_driver(&stm32_usart_driver);
+
+	return ret;
+}
+
+static void __exit usart_exit(void)
+{
+	platform_driver_unregister(&stm32_serial_driver);
+	uart_unregister_driver(&stm32_usart_driver);
+}
+
+module_init(usart_init);
+module_exit(usart_exit);
+
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_DESCRIPTION("STMicroelectronics STM32 serial port driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index b212281..93ba148 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -258,4 +258,7 @@
 /* Cris v10 / v32 SoC */
 #define PORT_CRIS	112
 
+/* STM32 USART */
+#define PORT_STM32	113
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
1.9.1

[PATCH v8 11/16] serial: stm32-usart: Add STM32 USART Driver

[Maxime Coquelin]

This drivers adds support to the STM32 USART controller, which is a
standard serial driver.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 drivers/tty/serial/Kconfig       |  17 +
 drivers/tty/serial/Makefile      |   1 +
 drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |   3 +
 4 files changed, 760 insertions(+)
 create mode 100644 drivers/tty/serial/stm32-usart.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index f8120c1..7eb62f1 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1589,6 +1589,23 @@ config SERIAL_SPRD_CONSOLE
 	  with "earlycon" on the kernel command line. The console is
 	  enabled when early_param is processed.
 
+config SERIAL_STM32
+	tristate "STMicroelectronics STM32 serial port support"
+	select SERIAL_CORE
+	depends on ARM || COMPILE_TEST
+	help
+	  This driver is for the on-chip Serial Controller on
+	  STMicroelectronics STM32 MCUs.
+	  USART supports Rx & Tx functionality.
+	  It support all industry standard baud rates.
+
+	  If unsure, say N.
+
+config SERIAL_STM32_CONSOLE
+	bool "Support for console on STM32"
+	depends on SERIAL_STM32=y
+	select SERIAL_CORE_CONSOLE
+
 endmenu
 
 config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index c3ac3d9..61979ce 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART)	+= fsl_lpuart.o
 obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
+obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
new file mode 100644
index 0000000..4a6eab6
--- /dev/null
+++ b/drivers/tty/serial/stm32-usart.c
@@ -0,0 +1,739 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author:  Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ * Inspired by st-asc.c from STMicroelectronics (c)
+ */
+
+#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#include <linux/module.h>
+#include <linux/serial.h>
+#include <linux/console.h>
+#include <linux/sysrq.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+#include <linux/delay.h>
+#include <linux/spinlock.h>
+#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/serial_core.h>
+#include <linux/clk.h>
+
+#define DRIVER_NAME "stm32-usart"
+
+/* Register offsets */
+#define USART_SR		0x00
+#define USART_DR		0x04
+#define USART_BRR		0x08
+#define USART_CR1		0x0c
+#define USART_CR2		0x10
+#define USART_CR3		0x14
+#define USART_GTPR		0x18
+
+/* USART_SR */
+#define USART_SR_PE		BIT(0)
+#define USART_SR_FE		BIT(1)
+#define USART_SR_NF		BIT(2)
+#define USART_SR_ORE		BIT(3)
+#define USART_SR_IDLE		BIT(4)
+#define USART_SR_RXNE		BIT(5)
+#define USART_SR_TC		BIT(6)
+#define USART_SR_TXE		BIT(7)
+#define USART_SR_LBD		BIT(8)
+#define USART_SR_CTS		BIT(9)
+#define USART_SR_ERR_MASK	(USART_SR_LBD | USART_SR_ORE | \
+				 USART_SR_FE | USART_SR_PE)
+/* Dummy bits */
+#define USART_SR_DUMMY_RX	BIT(16)
+
+/* USART_DR */
+#define USART_DR_MASK		GENMASK(8, 0)
+
+/* USART_BRR */
+#define USART_BRR_DIV_F_MASK	GENMASK(3, 0)
+#define USART_BRR_DIV_M_MASK	GENMASK(15, 4)
+#define USART_BRR_DIV_M_SHIFT	4
+
+/* USART_CR1 */
+#define USART_CR1_SBK		BIT(0)
+#define USART_CR1_RWU		BIT(1)
+#define USART_CR1_RE		BIT(2)
+#define USART_CR1_TE		BIT(3)
+#define USART_CR1_IDLEIE	BIT(4)
+#define USART_CR1_RXNEIE	BIT(5)
+#define USART_CR1_TCIE		BIT(6)
+#define USART_CR1_TXEIE		BIT(7)
+#define USART_CR1_PEIE		BIT(8)
+#define USART_CR1_PS		BIT(9)
+#define USART_CR1_PCE		BIT(10)
+#define USART_CR1_WAKE		BIT(11)
+#define USART_CR1_M		BIT(12)
+#define USART_CR1_UE		BIT(13)
+#define USART_CR1_OVER8		BIT(15)
+#define USART_CR1_IE_MASK	GENMASK(8, 4)
+
+/* USART_CR2 */
+#define USART_CR2_ADD_MASK	GENMASK(3, 0)
+#define USART_CR2_LBDL		BIT(5)
+#define USART_CR2_LBDIE		BIT(6)
+#define USART_CR2_LBCL		BIT(8)
+#define USART_CR2_CPHA		BIT(9)
+#define USART_CR2_CPOL		BIT(10)
+#define USART_CR2_CLKEN		BIT(11)
+#define USART_CR2_STOP_2B	BIT(13)
+#define USART_CR2_STOP_MASK	GENMASK(13, 12)
+#define USART_CR2_LINEN		BIT(14)
+
+/* USART_CR3 */
+#define USART_CR3_EIE		BIT(0)
+#define USART_CR3_IREN		BIT(1)
+#define USART_CR3_IRLP		BIT(2)
+#define USART_CR3_HDSEL		BIT(3)
+#define USART_CR3_NACK		BIT(4)
+#define USART_CR3_SCEN		BIT(5)
+#define USART_CR3_DMAR		BIT(6)
+#define USART_CR3_DMAT		BIT(7)
+#define USART_CR3_RTSE		BIT(8)
+#define USART_CR3_CTSE		BIT(9)
+#define USART_CR3_CTSIE		BIT(10)
+#define USART_CR3_ONEBIT	BIT(11)
+
+/* USART_GTPR */
+#define USART_GTPR_PSC_MASK	GENMASK(7, 0)
+#define USART_GTPR_GT_MASK	GENMASK(15, 8)
+
+#define DRIVER_NAME "stm32-usart"
+#define STM32_SERIAL_NAME "ttyS"
+#define STM32_MAX_PORTS 6
+
+struct stm32_port {
+	struct uart_port port;
+	struct clk *clk;
+	bool hw_flow_control;
+};
+
+static struct stm32_port stm32_ports[STM32_MAX_PORTS];
+static struct uart_driver stm32_usart_driver;
+
+static void stm32_stop_tx(struct uart_port *port);
+
+static inline struct stm32_port *to_stm32_port(struct uart_port *port)
+{
+	return container_of(port, struct stm32_port, port);
+}
+
+static void stm32_set_bits(struct uart_port *port, u32 reg, u32 bits)
+{
+	u32 val;
+
+	val = readl_relaxed(port->membase + reg);
+	val |= bits;
+	writel_relaxed(val, port->membase + reg);
+}
+
+static void stm32_clr_bits(struct uart_port *port, u32 reg, u32 bits)
+{
+	u32 val;
+
+	val = readl_relaxed(port->membase + reg);
+	val &= ~bits;
+	writel_relaxed(val, port->membase + reg);
+}
+
+static void stm32_receive_chars(struct uart_port *port)
+{
+	struct tty_port *tport = &port->state->port;
+	unsigned long c;
+	u32 sr;
+	char flag;
+
+	if (port->irq_wake)
+		pm_wakeup_event(tport->tty->dev, 0);
+
+	while ((sr = readl_relaxed(port->membase + USART_SR)) & USART_SR_RXNE) {
+		sr |= USART_SR_DUMMY_RX;
+		c = readl_relaxed(port->membase + USART_DR);
+		flag = TTY_NORMAL;
+		port->icount.rx++;
+
+		if (sr & USART_SR_ERR_MASK) {
+			if (sr & USART_SR_LBD) {
+				port->icount.brk++;
+				if (uart_handle_break(port))
+					continue;
+			} else if (sr & USART_SR_ORE) {
+				port->icount.overrun++;
+			} else if (sr & USART_SR_PE) {
+				port->icount.parity++;
+			} else if (sr & USART_SR_FE) {
+				port->icount.frame++;
+			}
+
+			sr &= port->read_status_mask;
+
+			if (sr & USART_SR_LBD)
+				flag = TTY_BREAK;
+			else if (sr & USART_SR_PE)
+				flag = TTY_PARITY;
+			else if (sr & USART_SR_FE)
+				flag = TTY_FRAME;
+		}
+
+		if (uart_handle_sysrq_char(port, c))
+			continue;
+		uart_insert_char(port, sr, USART_SR_ORE, c, flag);
+	}
+
+	spin_unlock(&port->lock);
+	tty_flip_buffer_push(tport);
+	spin_lock(&port->lock);
+}
+
+static void stm32_transmit_chars(struct uart_port *port)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+
+	if (port->x_char) {
+		writel_relaxed(port->x_char, port->membase + USART_DR);
+		port->x_char = 0;
+		port->icount.tx++;
+		return;
+	}
+
+	if (uart_tx_stopped(port)) {
+		stm32_stop_tx(port);
+		return;
+	}
+
+	if (uart_circ_empty(xmit)) {
+		stm32_stop_tx(port);
+		return;
+	}
+
+	writel_relaxed(xmit->buf[xmit->tail], port->membase + USART_DR);
+	xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+	port->icount.tx++;
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		stm32_stop_tx(port);
+}
+
+static irqreturn_t stm32_interrupt(int irq, void *ptr)
+{
+	struct uart_port *port = ptr;
+	u32 sr;
+
+	spin_lock(&port->lock);
+
+	sr = readl_relaxed(port->membase + USART_SR);
+
+	if (sr & USART_SR_RXNE)
+		stm32_receive_chars(port);
+
+	if (sr & USART_SR_TXE)
+		stm32_transmit_chars(port);
+
+	spin_unlock(&port->lock);
+
+	return IRQ_HANDLED;
+}
+
+static unsigned int stm32_tx_empty(struct uart_port *port)
+{
+	return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
+}
+
+static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+	if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
+		stm32_set_bits(port, USART_CR3, USART_CR3_RTSE);
+	else
+		stm32_clr_bits(port, USART_CR3, USART_CR3_RTSE);
+}
+
+static unsigned int stm32_get_mctrl(struct uart_port *port)
+{
+	/* This routine is used to get signals of: DCD, DSR, RI, and CTS */
+	return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+}
+
+/* Transmit stop */
+static void stm32_stop_tx(struct uart_port *port)
+{
+	stm32_clr_bits(port, USART_CR1, USART_CR1_TXEIE);
+}
+
+/* There are probably characters waiting to be transmitted. */
+static void stm32_start_tx(struct uart_port *port)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+
+	if (uart_circ_empty(xmit))
+		return;
+
+	stm32_set_bits(port, USART_CR1, USART_CR1_TXEIE | USART_CR1_TE);
+}
+
+/* Throttle the remote when input buffer is about to overflow. */
+static void stm32_throttle(struct uart_port *port)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/* Unthrottle the remote, the input buffer can now accept data. */
+static void stm32_unthrottle(struct uart_port *port)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	stm32_set_bits(port, USART_CR1, USART_CR1_RXNEIE);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/* Receive stop */
+static void stm32_stop_rx(struct uart_port *port)
+{
+	stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
+}
+
+/* Handle breaks - ignored by us */
+static void stm32_break_ctl(struct uart_port *port, int break_state)
+{
+}
+
+static int stm32_startup(struct uart_port *port)
+{
+	const char *name = to_platform_device(port->dev)->name;
+	u32 val;
+	int ret;
+
+	ret = request_irq(port->irq, stm32_interrupt, IRQF_NO_SUSPEND,
+			  name, port);
+	if (ret)
+		return ret;
+
+	val = USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
+	stm32_set_bits(port, USART_CR1, val);
+
+	return 0;
+}
+
+static void stm32_shutdown(struct uart_port *port)
+{
+	u32 val;
+
+	val = USART_CR1_TXEIE | USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
+	stm32_set_bits(port, USART_CR1, val);
+
+	free_irq(port->irq, port);
+}
+
+static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
+			    struct ktermios *old)
+{
+	struct stm32_port *stm32_port = to_stm32_port(port);
+	unsigned int baud;
+	u32 usartdiv, mantissa, fraction, oversampling;
+	tcflag_t cflag = termios->c_cflag;
+	u32 cr1, cr2, cr3;
+	unsigned long flags;
+
+	if (!stm32_port->hw_flow_control)
+		cflag &= ~CRTSCTS;
+
+	baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 8);
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	/* Stop serial port and reset value */
+	writel_relaxed(0, port->membase + USART_CR1);
+
+	cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
+	cr2 = 0;
+	cr3 = 0;
+
+	if (cflag & CSTOPB)
+		cr2 |= USART_CR2_STOP_2B;
+
+	if (cflag & PARENB) {
+		cr1 |= USART_CR1_PCE;
+		if ((cflag & CSIZE) == CS8)
+			cr1 |= USART_CR1_M;
+	}
+
+	if (cflag & PARODD)
+		cr1 |= USART_CR1_PS;
+
+	port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS);
+	if (cflag & CRTSCTS) {
+		port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
+		cr3 |= USART_CR3_CTSE;
+	}
+
+	usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
+
+	/*
+	 * The USART supports 16 or 8 times oversampling.
+	 * By default we prefer 16 times oversampling, so that the receiver
+	 * has a better tolerance to clock deviations.
+	 * 8 times oversampling is only used to achieve higher speeds.
+	 */
+	if (usartdiv < 16) {
+		oversampling = 8;
+		stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
+	} else {
+		oversampling = 16;
+		stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
+	}
+
+	mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
+	fraction = usartdiv % oversampling;
+	writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
+
+	uart_update_timeout(port, cflag, baud);
+
+	port->read_status_mask = USART_SR_ORE;
+	if (termios->c_iflag & INPCK)
+		port->read_status_mask |= USART_SR_PE | USART_SR_FE;
+	if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
+		port->read_status_mask |= USART_SR_LBD;
+
+	/* Characters to ignore */
+	port->ignore_status_mask = 0;
+	if (termios->c_iflag & IGNPAR)
+		port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
+	if (termios->c_iflag & IGNBRK) {
+		port->ignore_status_mask |= USART_SR_LBD;
+		/*
+		 * If we're ignoring parity and break indicators,
+		 * ignore overruns too (for real raw support).
+		 */
+		if (termios->c_iflag & IGNPAR)
+			port->ignore_status_mask |= USART_SR_ORE;
+	}
+
+	/* Ignore all characters if CREAD is not set */
+	if ((termios->c_cflag & CREAD) == 0)
+		port->ignore_status_mask |= USART_SR_DUMMY_RX;
+
+	writel_relaxed(cr3, port->membase + USART_CR3);
+	writel_relaxed(cr2, port->membase + USART_CR2);
+	writel_relaxed(cr1, port->membase + USART_CR1);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *stm32_type(struct uart_port *port)
+{
+	return (port->type == PORT_STM32) ? DRIVER_NAME : NULL;
+}
+
+static void stm32_release_port(struct uart_port *port)
+{
+}
+
+static int stm32_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+static void stm32_config_port(struct uart_port *port, int flags)
+{
+	if (flags & UART_CONFIG_TYPE)
+		port->type = PORT_STM32;
+}
+
+static int
+stm32_verify_port(struct uart_port *port, struct serial_struct *ser)
+{
+	/* No user changeable parameters */
+	return -EINVAL;
+}
+
+static void stm32_pm(struct uart_port *port, unsigned int state,
+		unsigned int oldstate)
+{
+	struct stm32_port *stm32port = container_of(port,
+			struct stm32_port, port);
+	unsigned long flags = 0;
+
+	switch (state) {
+	case UART_PM_STATE_ON:
+		clk_prepare_enable(stm32port->clk);
+		break;
+	case UART_PM_STATE_OFF:
+		spin_lock_irqsave(&port->lock, flags);
+		stm32_clr_bits(port, USART_CR1, USART_CR1_UE);
+		spin_unlock_irqrestore(&port->lock, flags);
+		clk_disable_unprepare(stm32port->clk);
+		break;
+	}
+}
+
+static const struct uart_ops stm32_uart_ops = {
+	.tx_empty	= stm32_tx_empty,
+	.set_mctrl	= stm32_set_mctrl,
+	.get_mctrl	= stm32_get_mctrl,
+	.stop_tx	= stm32_stop_tx,
+	.start_tx	= stm32_start_tx,
+	.throttle	= stm32_throttle,
+	.unthrottle	= stm32_unthrottle,
+	.stop_rx	= stm32_stop_rx,
+	.break_ctl	= stm32_break_ctl,
+	.startup	= stm32_startup,
+	.shutdown	= stm32_shutdown,
+	.set_termios	= stm32_set_termios,
+	.pm		= stm32_pm,
+	.type		= stm32_type,
+	.release_port	= stm32_release_port,
+	.request_port	= stm32_request_port,
+	.config_port	= stm32_config_port,
+	.verify_port	= stm32_verify_port,
+};
+
+static int stm32_init_port(struct stm32_port *stm32port,
+			  struct platform_device *pdev)
+{
+	struct uart_port *port = &stm32port->port;
+	struct resource *res;
+	int ret;
+
+	port->iotype	= UPIO_MEM;
+	port->flags	= UPF_BOOT_AUTOCONF;
+	port->ops	= &stm32_uart_ops;
+	port->dev	= &pdev->dev;
+	port->irq	= platform_get_irq(pdev, 0);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	port->membase = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(port->membase))
+		return PTR_ERR(port->membase);
+	port->mapbase = res->start;
+
+	spin_lock_init(&port->lock);
+
+	stm32port->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(stm32port->clk))
+		return PTR_ERR(stm32port->clk);
+
+	/* Ensure that clk rate is correct by enabling the clk */
+	ret = clk_prepare_enable(stm32port->clk);
+	if (ret)
+		return ret;
+
+	stm32port->port.uartclk = clk_get_rate(stm32port->clk);
+	if (!stm32port->port.uartclk)
+		ret = -EINVAL;
+
+	clk_disable_unprepare(stm32port->clk);
+
+	return ret;
+}
+
+static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int id;
+
+	if (!np)
+		return NULL;
+
+	id = of_alias_get_id(np, "serial");
+	if (id < 0)
+		id = 0;
+
+	if (WARN_ON(id >= STM32_MAX_PORTS))
+		return NULL;
+
+	stm32_ports[id].hw_flow_control = of_property_read_bool(np,
+							"auto-flow-control");
+	stm32_ports[id].port.line = id;
+	return &stm32_ports[id];
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id stm32_match[] = {
+	{ .compatible = "st,stm32-usart", },
+	{ .compatible = "st,stm32-uart", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, stm32_match);
+#endif
+
+static int stm32_serial_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct stm32_port *stm32port;
+
+	stm32port = stm32_of_get_stm32_port(pdev);
+	if (!stm32port)
+		return -ENODEV;
+
+	ret = stm32_init_port(stm32port, pdev);
+	if (ret)
+		return ret;
+
+	ret = uart_add_one_port(&stm32_usart_driver, &stm32port->port);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, &stm32port->port);
+
+	return 0;
+}
+
+static int stm32_serial_remove(struct platform_device *pdev)
+{
+	struct uart_port *port = platform_get_drvdata(pdev);
+
+	return uart_remove_one_port(&stm32_usart_driver, port);
+}
+
+
+#ifdef CONFIG_SERIAL_STM32_CONSOLE
+static void stm32_console_putchar(struct uart_port *port, int ch)
+{
+	while (!(readl_relaxed(port->membase + USART_SR) & USART_SR_TXE))
+		cpu_relax();
+
+	writel_relaxed(ch, port->membase + USART_DR);
+}
+
+static void stm32_console_write(struct console *co, const char *s, unsigned cnt)
+{
+	struct uart_port *port = &stm32_ports[co->index].port;
+	unsigned long flags;
+	u32 old_cr1, new_cr1;
+	int locked = 1;
+
+	local_irq_save(flags);
+	if (port->sysrq)
+		locked = 0;
+	else if (oops_in_progress)
+		locked = spin_trylock(&port->lock);
+	else
+		spin_lock(&port->lock);
+
+	/* Save and disable interrupts */
+	old_cr1 = readl_relaxed(port->membase + USART_CR1);
+	new_cr1 = old_cr1 & ~USART_CR1_IE_MASK;
+	writel_relaxed(new_cr1, port->membase + USART_CR1);
+
+	uart_console_write(port, s, cnt, stm32_console_putchar);
+
+	/* Restore interrupt state */
+	writel_relaxed(old_cr1, port->membase + USART_CR1);
+
+	if (locked)
+		spin_unlock(&port->lock);
+	local_irq_restore(flags);
+}
+
+static int stm32_console_setup(struct console *co, char *options)
+{
+	struct stm32_port *stm32port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index >= STM32_MAX_PORTS)
+		return -ENODEV;
+
+	stm32port = &stm32_ports[co->index];
+
+	/*
+	 * This driver does not support early console initialization
+	 * (use ARM early printk support instead), so we only expect
+	 * this to be called during the uart port registration when the
+	 * driver gets probed and the port should be mapped at that point.
+	 */
+	if (stm32port->port.mapbase == 0 || stm32port->port.membase == NULL)
+		return -ENXIO;
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(&stm32port->port, co, baud, parity, bits, flow);
+}
+
+static struct console stm32_console = {
+	.name		= STM32_SERIAL_NAME,
+	.device		= uart_console_device,
+	.write		= stm32_console_write,
+	.setup		= stm32_console_setup,
+	.flags		= CON_PRINTBUFFER,
+	.index		= -1,
+	.data		= &stm32_usart_driver,
+};
+
+#define STM32_SERIAL_CONSOLE (&stm32_console)
+
+#else
+#define STM32_SERIAL_CONSOLE NULL
+#endif /* CONFIG_SERIAL_STM32_CONSOLE */
+
+static struct uart_driver stm32_usart_driver = {
+	.driver_name	= DRIVER_NAME,
+	.dev_name	= STM32_SERIAL_NAME,
+	.major		= 0,
+	.minor		= 0,
+	.nr		= STM32_MAX_PORTS,
+	.cons		= STM32_SERIAL_CONSOLE,
+};
+
+static struct platform_driver stm32_serial_driver = {
+	.probe		= stm32_serial_probe,
+	.remove		= stm32_serial_remove,
+	.driver	= {
+		.name	= DRIVER_NAME,
+		.of_match_table = of_match_ptr(stm32_match),
+	},
+};
+
+static int __init usart_init(void)
+{
+	static char banner[] __initdata = "STM32 USART driver initialized";
+	int ret;
+
+	pr_info("%s\n", banner);
+
+	ret = uart_register_driver(&stm32_usart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&stm32_serial_driver);
+	if (ret)
+		uart_unregister_driver(&stm32_usart_driver);
+
+	return ret;
+}
+
+static void __exit usart_exit(void)
+{
+	platform_driver_unregister(&stm32_serial_driver);
+	uart_unregister_driver(&stm32_usart_driver);
+}
+
+module_init(usart_init);
+module_exit(usart_exit);
+
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_DESCRIPTION("STMicroelectronics STM32 serial port driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index b212281..93ba148 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -258,4 +258,7 @@
 /* Cris v10 / v32 SoC */
 #define PORT_CRIS	112
 
+/* STM32 USART */
+#define PORT_STM32	113
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
1.9.1

[PATCH v8 11/16] serial: stm32-usart: Add STM32 USART Driver

[Maxime Coquelin]

This drivers adds support to the STM32 USART controller, which is a
standard serial driver.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 drivers/tty/serial/Kconfig       |  17 +
 drivers/tty/serial/Makefile      |   1 +
 drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |   3 +
 4 files changed, 760 insertions(+)
 create mode 100644 drivers/tty/serial/stm32-usart.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index f8120c1..7eb62f1 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1589,6 +1589,23 @@ config SERIAL_SPRD_CONSOLE
 	  with "earlycon" on the kernel command line. The console is
 	  enabled when early_param is processed.
 
+config SERIAL_STM32
+	tristate "STMicroelectronics STM32 serial port support"
+	select SERIAL_CORE
+	depends on ARM || COMPILE_TEST
+	help
+	  This driver is for the on-chip Serial Controller on
+	  STMicroelectronics STM32 MCUs.
+	  USART supports Rx & Tx functionality.
+	  It support all industry standard baud rates.
+
+	  If unsure, say N.
+
+config SERIAL_STM32_CONSOLE
+	bool "Support for console on STM32"
+	depends on SERIAL_STM32=y
+	select SERIAL_CORE_CONSOLE
+
 endmenu
 
 config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index c3ac3d9..61979ce 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART)	+= fsl_lpuart.o
 obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
+obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
new file mode 100644
index 0000000..4a6eab6
--- /dev/null
+++ b/drivers/tty/serial/stm32-usart.c
@@ -0,0 +1,739 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author:  Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ * Inspired by st-asc.c from STMicroelectronics (c)
+ */
+
+#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#include <linux/module.h>
+#include <linux/serial.h>
+#include <linux/console.h>
+#include <linux/sysrq.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+#include <linux/delay.h>
+#include <linux/spinlock.h>
+#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/serial_core.h>
+#include <linux/clk.h>
+
+#define DRIVER_NAME "stm32-usart"
+
+/* Register offsets */
+#define USART_SR		0x00
+#define USART_DR		0x04
+#define USART_BRR		0x08
+#define USART_CR1		0x0c
+#define USART_CR2		0x10
+#define USART_CR3		0x14
+#define USART_GTPR		0x18
+
+/* USART_SR */
+#define USART_SR_PE		BIT(0)
+#define USART_SR_FE		BIT(1)
+#define USART_SR_NF		BIT(2)
+#define USART_SR_ORE		BIT(3)
+#define USART_SR_IDLE		BIT(4)
+#define USART_SR_RXNE		BIT(5)
+#define USART_SR_TC		BIT(6)
+#define USART_SR_TXE		BIT(7)
+#define USART_SR_LBD		BIT(8)
+#define USART_SR_CTS		BIT(9)
+#define USART_SR_ERR_MASK	(USART_SR_LBD | USART_SR_ORE | \
+				 USART_SR_FE | USART_SR_PE)
+/* Dummy bits */
+#define USART_SR_DUMMY_RX	BIT(16)
+
+/* USART_DR */
+#define USART_DR_MASK		GENMASK(8, 0)
+
+/* USART_BRR */
+#define USART_BRR_DIV_F_MASK	GENMASK(3, 0)
+#define USART_BRR_DIV_M_MASK	GENMASK(15, 4)
+#define USART_BRR_DIV_M_SHIFT	4
+
+/* USART_CR1 */
+#define USART_CR1_SBK		BIT(0)
+#define USART_CR1_RWU		BIT(1)
+#define USART_CR1_RE		BIT(2)
+#define USART_CR1_TE		BIT(3)
+#define USART_CR1_IDLEIE	BIT(4)
+#define USART_CR1_RXNEIE	BIT(5)
+#define USART_CR1_TCIE		BIT(6)
+#define USART_CR1_TXEIE		BIT(7)
+#define USART_CR1_PEIE		BIT(8)
+#define USART_CR1_PS		BIT(9)
+#define USART_CR1_PCE		BIT(10)
+#define USART_CR1_WAKE		BIT(11)
+#define USART_CR1_M		BIT(12)
+#define USART_CR1_UE		BIT(13)
+#define USART_CR1_OVER8		BIT(15)
+#define USART_CR1_IE_MASK	GENMASK(8, 4)
+
+/* USART_CR2 */
+#define USART_CR2_ADD_MASK	GENMASK(3, 0)
+#define USART_CR2_LBDL		BIT(5)
+#define USART_CR2_LBDIE		BIT(6)
+#define USART_CR2_LBCL		BIT(8)
+#define USART_CR2_CPHA		BIT(9)
+#define USART_CR2_CPOL		BIT(10)
+#define USART_CR2_CLKEN		BIT(11)
+#define USART_CR2_STOP_2B	BIT(13)
+#define USART_CR2_STOP_MASK	GENMASK(13, 12)
+#define USART_CR2_LINEN		BIT(14)
+
+/* USART_CR3 */
+#define USART_CR3_EIE		BIT(0)
+#define USART_CR3_IREN		BIT(1)
+#define USART_CR3_IRLP		BIT(2)
+#define USART_CR3_HDSEL		BIT(3)
+#define USART_CR3_NACK		BIT(4)
+#define USART_CR3_SCEN		BIT(5)
+#define USART_CR3_DMAR		BIT(6)
+#define USART_CR3_DMAT		BIT(7)
+#define USART_CR3_RTSE		BIT(8)
+#define USART_CR3_CTSE		BIT(9)
+#define USART_CR3_CTSIE		BIT(10)
+#define USART_CR3_ONEBIT	BIT(11)
+
+/* USART_GTPR */
+#define USART_GTPR_PSC_MASK	GENMASK(7, 0)
+#define USART_GTPR_GT_MASK	GENMASK(15, 8)
+
+#define DRIVER_NAME "stm32-usart"
+#define STM32_SERIAL_NAME "ttyS"
+#define STM32_MAX_PORTS 6
+
+struct stm32_port {
+	struct uart_port port;
+	struct clk *clk;
+	bool hw_flow_control;
+};
+
+static struct stm32_port stm32_ports[STM32_MAX_PORTS];
+static struct uart_driver stm32_usart_driver;
+
+static void stm32_stop_tx(struct uart_port *port);
+
+static inline struct stm32_port *to_stm32_port(struct uart_port *port)
+{
+	return container_of(port, struct stm32_port, port);
+}
+
+static void stm32_set_bits(struct uart_port *port, u32 reg, u32 bits)
+{
+	u32 val;
+
+	val = readl_relaxed(port->membase + reg);
+	val |= bits;
+	writel_relaxed(val, port->membase + reg);
+}
+
+static void stm32_clr_bits(struct uart_port *port, u32 reg, u32 bits)
+{
+	u32 val;
+
+	val = readl_relaxed(port->membase + reg);
+	val &= ~bits;
+	writel_relaxed(val, port->membase + reg);
+}
+
+static void stm32_receive_chars(struct uart_port *port)
+{
+	struct tty_port *tport = &port->state->port;
+	unsigned long c;
+	u32 sr;
+	char flag;
+
+	if (port->irq_wake)
+		pm_wakeup_event(tport->tty->dev, 0);
+
+	while ((sr = readl_relaxed(port->membase + USART_SR)) & USART_SR_RXNE) {
+		sr |= USART_SR_DUMMY_RX;
+		c = readl_relaxed(port->membase + USART_DR);
+		flag = TTY_NORMAL;
+		port->icount.rx++;
+
+		if (sr & USART_SR_ERR_MASK) {
+			if (sr & USART_SR_LBD) {
+				port->icount.brk++;
+				if (uart_handle_break(port))
+					continue;
+			} else if (sr & USART_SR_ORE) {
+				port->icount.overrun++;
+			} else if (sr & USART_SR_PE) {
+				port->icount.parity++;
+			} else if (sr & USART_SR_FE) {
+				port->icount.frame++;
+			}
+
+			sr &= port->read_status_mask;
+
+			if (sr & USART_SR_LBD)
+				flag = TTY_BREAK;
+			else if (sr & USART_SR_PE)
+				flag = TTY_PARITY;
+			else if (sr & USART_SR_FE)
+				flag = TTY_FRAME;
+		}
+
+		if (uart_handle_sysrq_char(port, c))
+			continue;
+		uart_insert_char(port, sr, USART_SR_ORE, c, flag);
+	}
+
+	spin_unlock(&port->lock);
+	tty_flip_buffer_push(tport);
+	spin_lock(&port->lock);
+}
+
+static void stm32_transmit_chars(struct uart_port *port)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+
+	if (port->x_char) {
+		writel_relaxed(port->x_char, port->membase + USART_DR);
+		port->x_char = 0;
+		port->icount.tx++;
+		return;
+	}
+
+	if (uart_tx_stopped(port)) {
+		stm32_stop_tx(port);
+		return;
+	}
+
+	if (uart_circ_empty(xmit)) {
+		stm32_stop_tx(port);
+		return;
+	}
+
+	writel_relaxed(xmit->buf[xmit->tail], port->membase + USART_DR);
+	xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+	port->icount.tx++;
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		stm32_stop_tx(port);
+}
+
+static irqreturn_t stm32_interrupt(int irq, void *ptr)
+{
+	struct uart_port *port = ptr;
+	u32 sr;
+
+	spin_lock(&port->lock);
+
+	sr = readl_relaxed(port->membase + USART_SR);
+
+	if (sr & USART_SR_RXNE)
+		stm32_receive_chars(port);
+
+	if (sr & USART_SR_TXE)
+		stm32_transmit_chars(port);
+
+	spin_unlock(&port->lock);
+
+	return IRQ_HANDLED;
+}
+
+static unsigned int stm32_tx_empty(struct uart_port *port)
+{
+	return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
+}
+
+static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+	if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
+		stm32_set_bits(port, USART_CR3, USART_CR3_RTSE);
+	else
+		stm32_clr_bits(port, USART_CR3, USART_CR3_RTSE);
+}
+
+static unsigned int stm32_get_mctrl(struct uart_port *port)
+{
+	/* This routine is used to get signals of: DCD, DSR, RI, and CTS */
+	return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+}
+
+/* Transmit stop */
+static void stm32_stop_tx(struct uart_port *port)
+{
+	stm32_clr_bits(port, USART_CR1, USART_CR1_TXEIE);
+}
+
+/* There are probably characters waiting to be transmitted. */
+static void stm32_start_tx(struct uart_port *port)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+
+	if (uart_circ_empty(xmit))
+		return;
+
+	stm32_set_bits(port, USART_CR1, USART_CR1_TXEIE | USART_CR1_TE);
+}
+
+/* Throttle the remote when input buffer is about to overflow. */
+static void stm32_throttle(struct uart_port *port)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/* Unthrottle the remote, the input buffer can now accept data. */
+static void stm32_unthrottle(struct uart_port *port)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	stm32_set_bits(port, USART_CR1, USART_CR1_RXNEIE);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+/* Receive stop */
+static void stm32_stop_rx(struct uart_port *port)
+{
+	stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
+}
+
+/* Handle breaks - ignored by us */
+static void stm32_break_ctl(struct uart_port *port, int break_state)
+{
+}
+
+static int stm32_startup(struct uart_port *port)
+{
+	const char *name = to_platform_device(port->dev)->name;
+	u32 val;
+	int ret;
+
+	ret = request_irq(port->irq, stm32_interrupt, IRQF_NO_SUSPEND,
+			  name, port);
+	if (ret)
+		return ret;
+
+	val = USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
+	stm32_set_bits(port, USART_CR1, val);
+
+	return 0;
+}
+
+static void stm32_shutdown(struct uart_port *port)
+{
+	u32 val;
+
+	val = USART_CR1_TXEIE | USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
+	stm32_set_bits(port, USART_CR1, val);
+
+	free_irq(port->irq, port);
+}
+
+static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
+			    struct ktermios *old)
+{
+	struct stm32_port *stm32_port = to_stm32_port(port);
+	unsigned int baud;
+	u32 usartdiv, mantissa, fraction, oversampling;
+	tcflag_t cflag = termios->c_cflag;
+	u32 cr1, cr2, cr3;
+	unsigned long flags;
+
+	if (!stm32_port->hw_flow_control)
+		cflag &= ~CRTSCTS;
+
+	baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 8);
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	/* Stop serial port and reset value */
+	writel_relaxed(0, port->membase + USART_CR1);
+
+	cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
+	cr2 = 0;
+	cr3 = 0;
+
+	if (cflag & CSTOPB)
+		cr2 |= USART_CR2_STOP_2B;
+
+	if (cflag & PARENB) {
+		cr1 |= USART_CR1_PCE;
+		if ((cflag & CSIZE) == CS8)
+			cr1 |= USART_CR1_M;
+	}
+
+	if (cflag & PARODD)
+		cr1 |= USART_CR1_PS;
+
+	port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS);
+	if (cflag & CRTSCTS) {
+		port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
+		cr3 |= USART_CR3_CTSE;
+	}
+
+	usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
+
+	/*
+	 * The USART supports 16 or 8 times oversampling.
+	 * By default we prefer 16 times oversampling, so that the receiver
+	 * has a better tolerance to clock deviations.
+	 * 8 times oversampling is only used to achieve higher speeds.
+	 */
+	if (usartdiv < 16) {
+		oversampling = 8;
+		stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
+	} else {
+		oversampling = 16;
+		stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
+	}
+
+	mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
+	fraction = usartdiv % oversampling;
+	writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
+
+	uart_update_timeout(port, cflag, baud);
+
+	port->read_status_mask = USART_SR_ORE;
+	if (termios->c_iflag & INPCK)
+		port->read_status_mask |= USART_SR_PE | USART_SR_FE;
+	if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
+		port->read_status_mask |= USART_SR_LBD;
+
+	/* Characters to ignore */
+	port->ignore_status_mask = 0;
+	if (termios->c_iflag & IGNPAR)
+		port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
+	if (termios->c_iflag & IGNBRK) {
+		port->ignore_status_mask |= USART_SR_LBD;
+		/*
+		 * If we're ignoring parity and break indicators,
+		 * ignore overruns too (for real raw support).
+		 */
+		if (termios->c_iflag & IGNPAR)
+			port->ignore_status_mask |= USART_SR_ORE;
+	}
+
+	/* Ignore all characters if CREAD is not set */
+	if ((termios->c_cflag & CREAD) == 0)
+		port->ignore_status_mask |= USART_SR_DUMMY_RX;
+
+	writel_relaxed(cr3, port->membase + USART_CR3);
+	writel_relaxed(cr2, port->membase + USART_CR2);
+	writel_relaxed(cr1, port->membase + USART_CR1);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *stm32_type(struct uart_port *port)
+{
+	return (port->type == PORT_STM32) ? DRIVER_NAME : NULL;
+}
+
+static void stm32_release_port(struct uart_port *port)
+{
+}
+
+static int stm32_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+static void stm32_config_port(struct uart_port *port, int flags)
+{
+	if (flags & UART_CONFIG_TYPE)
+		port->type = PORT_STM32;
+}
+
+static int
+stm32_verify_port(struct uart_port *port, struct serial_struct *ser)
+{
+	/* No user changeable parameters */
+	return -EINVAL;
+}
+
+static void stm32_pm(struct uart_port *port, unsigned int state,
+		unsigned int oldstate)
+{
+	struct stm32_port *stm32port = container_of(port,
+			struct stm32_port, port);
+	unsigned long flags = 0;
+
+	switch (state) {
+	case UART_PM_STATE_ON:
+		clk_prepare_enable(stm32port->clk);
+		break;
+	case UART_PM_STATE_OFF:
+		spin_lock_irqsave(&port->lock, flags);
+		stm32_clr_bits(port, USART_CR1, USART_CR1_UE);
+		spin_unlock_irqrestore(&port->lock, flags);
+		clk_disable_unprepare(stm32port->clk);
+		break;
+	}
+}
+
+static const struct uart_ops stm32_uart_ops = {
+	.tx_empty	= stm32_tx_empty,
+	.set_mctrl	= stm32_set_mctrl,
+	.get_mctrl	= stm32_get_mctrl,
+	.stop_tx	= stm32_stop_tx,
+	.start_tx	= stm32_start_tx,
+	.throttle	= stm32_throttle,
+	.unthrottle	= stm32_unthrottle,
+	.stop_rx	= stm32_stop_rx,
+	.break_ctl	= stm32_break_ctl,
+	.startup	= stm32_startup,
+	.shutdown	= stm32_shutdown,
+	.set_termios	= stm32_set_termios,
+	.pm		= stm32_pm,
+	.type		= stm32_type,
+	.release_port	= stm32_release_port,
+	.request_port	= stm32_request_port,
+	.config_port	= stm32_config_port,
+	.verify_port	= stm32_verify_port,
+};
+
+static int stm32_init_port(struct stm32_port *stm32port,
+			  struct platform_device *pdev)
+{
+	struct uart_port *port = &stm32port->port;
+	struct resource *res;
+	int ret;
+
+	port->iotype	= UPIO_MEM;
+	port->flags	= UPF_BOOT_AUTOCONF;
+	port->ops	= &stm32_uart_ops;
+	port->dev	= &pdev->dev;
+	port->irq	= platform_get_irq(pdev, 0);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	port->membase = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(port->membase))
+		return PTR_ERR(port->membase);
+	port->mapbase = res->start;
+
+	spin_lock_init(&port->lock);
+
+	stm32port->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(stm32port->clk))
+		return PTR_ERR(stm32port->clk);
+
+	/* Ensure that clk rate is correct by enabling the clk */
+	ret = clk_prepare_enable(stm32port->clk);
+	if (ret)
+		return ret;
+
+	stm32port->port.uartclk = clk_get_rate(stm32port->clk);
+	if (!stm32port->port.uartclk)
+		ret = -EINVAL;
+
+	clk_disable_unprepare(stm32port->clk);
+
+	return ret;
+}
+
+static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int id;
+
+	if (!np)
+		return NULL;
+
+	id = of_alias_get_id(np, "serial");
+	if (id < 0)
+		id = 0;
+
+	if (WARN_ON(id >= STM32_MAX_PORTS))
+		return NULL;
+
+	stm32_ports[id].hw_flow_control = of_property_read_bool(np,
+							"auto-flow-control");
+	stm32_ports[id].port.line = id;
+	return &stm32_ports[id];
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id stm32_match[] = {
+	{ .compatible = "st,stm32-usart", },
+	{ .compatible = "st,stm32-uart", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, stm32_match);
+#endif
+
+static int stm32_serial_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct stm32_port *stm32port;
+
+	stm32port = stm32_of_get_stm32_port(pdev);
+	if (!stm32port)
+		return -ENODEV;
+
+	ret = stm32_init_port(stm32port, pdev);
+	if (ret)
+		return ret;
+
+	ret = uart_add_one_port(&stm32_usart_driver, &stm32port->port);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, &stm32port->port);
+
+	return 0;
+}
+
+static int stm32_serial_remove(struct platform_device *pdev)
+{
+	struct uart_port *port = platform_get_drvdata(pdev);
+
+	return uart_remove_one_port(&stm32_usart_driver, port);
+}
+
+
+#ifdef CONFIG_SERIAL_STM32_CONSOLE
+static void stm32_console_putchar(struct uart_port *port, int ch)
+{
+	while (!(readl_relaxed(port->membase + USART_SR) & USART_SR_TXE))
+		cpu_relax();
+
+	writel_relaxed(ch, port->membase + USART_DR);
+}
+
+static void stm32_console_write(struct console *co, const char *s, unsigned cnt)
+{
+	struct uart_port *port = &stm32_ports[co->index].port;
+	unsigned long flags;
+	u32 old_cr1, new_cr1;
+	int locked = 1;
+
+	local_irq_save(flags);
+	if (port->sysrq)
+		locked = 0;
+	else if (oops_in_progress)
+		locked = spin_trylock(&port->lock);
+	else
+		spin_lock(&port->lock);
+
+	/* Save and disable interrupts */
+	old_cr1 = readl_relaxed(port->membase + USART_CR1);
+	new_cr1 = old_cr1 & ~USART_CR1_IE_MASK;
+	writel_relaxed(new_cr1, port->membase + USART_CR1);
+
+	uart_console_write(port, s, cnt, stm32_console_putchar);
+
+	/* Restore interrupt state */
+	writel_relaxed(old_cr1, port->membase + USART_CR1);
+
+	if (locked)
+		spin_unlock(&port->lock);
+	local_irq_restore(flags);
+}
+
+static int stm32_console_setup(struct console *co, char *options)
+{
+	struct stm32_port *stm32port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index >= STM32_MAX_PORTS)
+		return -ENODEV;
+
+	stm32port = &stm32_ports[co->index];
+
+	/*
+	 * This driver does not support early console initialization
+	 * (use ARM early printk support instead), so we only expect
+	 * this to be called during the uart port registration when the
+	 * driver gets probed and the port should be mapped at that point.
+	 */
+	if (stm32port->port.mapbase == 0 || stm32port->port.membase == NULL)
+		return -ENXIO;
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(&stm32port->port, co, baud, parity, bits, flow);
+}
+
+static struct console stm32_console = {
+	.name		= STM32_SERIAL_NAME,
+	.device		= uart_console_device,
+	.write		= stm32_console_write,
+	.setup		= stm32_console_setup,
+	.flags		= CON_PRINTBUFFER,
+	.index		= -1,
+	.data		= &stm32_usart_driver,
+};
+
+#define STM32_SERIAL_CONSOLE (&stm32_console)
+
+#else
+#define STM32_SERIAL_CONSOLE NULL
+#endif /* CONFIG_SERIAL_STM32_CONSOLE */
+
+static struct uart_driver stm32_usart_driver = {
+	.driver_name	= DRIVER_NAME,
+	.dev_name	= STM32_SERIAL_NAME,
+	.major		= 0,
+	.minor		= 0,
+	.nr		= STM32_MAX_PORTS,
+	.cons		= STM32_SERIAL_CONSOLE,
+};
+
+static struct platform_driver stm32_serial_driver = {
+	.probe		= stm32_serial_probe,
+	.remove		= stm32_serial_remove,
+	.driver	= {
+		.name	= DRIVER_NAME,
+		.of_match_table = of_match_ptr(stm32_match),
+	},
+};
+
+static int __init usart_init(void)
+{
+	static char banner[] __initdata = "STM32 USART driver initialized";
+	int ret;
+
+	pr_info("%s\n", banner);
+
+	ret = uart_register_driver(&stm32_usart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&stm32_serial_driver);
+	if (ret)
+		uart_unregister_driver(&stm32_usart_driver);
+
+	return ret;
+}
+
+static void __exit usart_exit(void)
+{
+	platform_driver_unregister(&stm32_serial_driver);
+	uart_unregister_driver(&stm32_usart_driver);
+}
+
+module_init(usart_init);
+module_exit(usart_exit);
+
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_DESCRIPTION("STMicroelectronics STM32 serial port driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index b212281..93ba148 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -258,4 +258,7 @@
 /* Cris v10 / v32 SoC */
 #define PORT_CRIS	112
 
+/* STM32 USART */
+#define PORT_STM32	113
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
1.9.1

[PATCH v8 12/16] ARM: Add STM32 family machine

[Maxime Coquelin]

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 <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
+ * 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

[PATCH v8 12/16] ARM: Add STM32 family machine

[Maxime Coquelin]

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 <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
+ * 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

[PATCH v8 12/16] ARM: Add STM32 family machine

[Maxime Coquelin]

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 <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
+ * 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

[PATCH v8 13/16] ARM: dts: Add ARM System timer as clocksource in armv7m

[Maxime Coquelin]

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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

[PATCH v8 13/16] ARM: dts: Add ARM System timer as clocksource in armv7m

[Maxime Coquelin]

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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

[PATCH v8 13/16] ARM: dts: Add ARM System timer as clocksource in armv7m

[Maxime Coquelin]

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 at e000e010 {
+		compatible = "arm,armv7m-systick";
+		reg = <0xe000e010 0x10>;
+		status = "disabled";
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.9.1

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

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 <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 arch/arm/boot/dts/Makefile            |   1 +
 arch/arm/boot/dts/stm32f429-disco.dts |  71 +++++++++++
 arch/arm/boot/dts/stm32f429.dtsi      | 227 ++++++++++++++++++++++++++++++++++
 3 files changed, 299 insertions(+)
 create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
 create mode 100644 arch/arm/boot/dts/stm32f429.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 86217db..db1d8c6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -520,6 +520,7 @@ dtb-$(CONFIG_ARCH_STI) += \
 	stih416-b2020.dtb \
 	stih416-b2020e.dtb \
 	stih418-b2199.dtb
+dtb-$(CONFIG_ARCH_STM32)+= stm32f429-disco.dtb
 dtb-$(CONFIG_MACH_SUN4I) += \
 	sun4i-a10-a1000.dtb \
 	sun4i-a10-ba10-tvbox.dtb \
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
new file mode 100644
index 0000000..6b9aa59
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -0,0 +1,71 @@
+/*
+ * Copyright 2015 - Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this file; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f429.dtsi"
+
+/ {
+	model = "STMicroelectronics STM32F429i-DISCO board";
+	compatible = "st,stm32f429i-disco", "st,stm32f429";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 root=/dev/ram rdinit=/linuxrc";
+		linux,stdout-path = &usart1;
+	};
+
+	memory {
+		reg = <0x90000000 0x800000>;
+	};
+
+	aliases {
+		serial0 = &usart1;
+	};
+};
+
+&usart1 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
new file mode 100644
index 0000000..2719f3a
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -0,0 +1,227 @@
+/*
+ * Copyright 2015 - Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this file; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armv7-m.dtsi"
+#include  <dt-bindings/mfd/stm32f4-rcc.h>
+
+/ {
+	clocks {
+		clk_sysclk: clk-sysclk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_hclk: clk-hclk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_pclk1: clk-pclk1 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <45000000>;
+		};
+
+		clk_pclk2: clk-pclk2 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <90000000>;
+		};
+
+		clk_pmtr1: clk-pmtr1 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <90000000>;
+		};
+
+		clk_pmtr2: clk-pmtr2 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_systick: clk-systick {
+			compatible = "fixed-factor-clock";
+			clocks = <&clk_hclk>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+	};
+
+	soc {
+		timer2: timer@40000000 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000000 0x400>;
+			interrupts = <28>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM2)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer3: timer@40000400 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000400 0x400>;
+			interrupts = <29>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer4: timer@40000800 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000800 0x400>;
+			interrupts = <30>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM4)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer5: timer@40000c00 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000c00 0x400>;
+			interrupts = <50>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM5)>;
+			clocks = <&clk_pmtr1>;
+		};
+
+		timer6: timer@40001000 {
+			compatible = "st,stm32-timer";
+			reg = <0x40001000 0x400>;
+			interrupts = <54>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM6)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer7: timer@40001400 {
+			compatible = "st,stm32-timer";
+			reg = <0x40001400 0x400>;
+			interrupts = <55>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM7)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		usart2: serial@40004400 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40004400 0x400>;
+			interrupts = <38>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart3: serial@40004800 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40004800 0x400>;
+			interrupts = <39>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart4: serial@40004c00 {
+			compatible = "st,stm32-uart";
+			reg = <0x40004c00 0x400>;
+			interrupts = <52>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart5: serial@40005000 {
+			compatible = "st,stm32-uart";
+			reg = <0x40005000 0x400>;
+			interrupts = <53>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart7: serial@40007800 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40007800 0x400>;
+			interrupts = <82>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart8: serial@40007c00 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40007c00 0x400>;
+			interrupts = <83>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart1: serial@40011000 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40011000 0x400>;
+			interrupts = <37>;
+			clocks = <&clk_pclk2>;
+			status = "disabled";
+		};
+
+		usart6: serial@40011400 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40011400 0x400>;
+			interrupts = <71>;
+			clocks = <&clk_pclk2>;
+			status = "disabled";
+		};
+
+		rcc: rcc@40023810 {
+			#reset-cells = <1>;
+			compatible = "st,stm32-rcc";
+			reg = <0x40023800 0x400>;
+		};
+	};
+};
+
+&systick {
+	clocks = <&clk_systick>;
+	status = "okay";
+};
-- 
1.9.1

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

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 <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 arch/arm/boot/dts/Makefile            |   1 +
 arch/arm/boot/dts/stm32f429-disco.dts |  71 +++++++++++
 arch/arm/boot/dts/stm32f429.dtsi      | 227 ++++++++++++++++++++++++++++++++++
 3 files changed, 299 insertions(+)
 create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
 create mode 100644 arch/arm/boot/dts/stm32f429.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 86217db..db1d8c6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -520,6 +520,7 @@ dtb-$(CONFIG_ARCH_STI) += \
 	stih416-b2020.dtb \
 	stih416-b2020e.dtb \
 	stih418-b2199.dtb
+dtb-$(CONFIG_ARCH_STM32)+= stm32f429-disco.dtb
 dtb-$(CONFIG_MACH_SUN4I) += \
 	sun4i-a10-a1000.dtb \
 	sun4i-a10-ba10-tvbox.dtb \
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
new file mode 100644
index 0000000..6b9aa59
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -0,0 +1,71 @@
+/*
+ * Copyright 2015 - Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this file; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f429.dtsi"
+
+/ {
+	model = "STMicroelectronics STM32F429i-DISCO board";
+	compatible = "st,stm32f429i-disco", "st,stm32f429";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 root=/dev/ram rdinit=/linuxrc";
+		linux,stdout-path = &usart1;
+	};
+
+	memory {
+		reg = <0x90000000 0x800000>;
+	};
+
+	aliases {
+		serial0 = &usart1;
+	};
+};
+
+&usart1 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
new file mode 100644
index 0000000..2719f3a
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -0,0 +1,227 @@
+/*
+ * Copyright 2015 - Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this file; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armv7-m.dtsi"
+#include  <dt-bindings/mfd/stm32f4-rcc.h>
+
+/ {
+	clocks {
+		clk_sysclk: clk-sysclk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_hclk: clk-hclk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_pclk1: clk-pclk1 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <45000000>;
+		};
+
+		clk_pclk2: clk-pclk2 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <90000000>;
+		};
+
+		clk_pmtr1: clk-pmtr1 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <90000000>;
+		};
+
+		clk_pmtr2: clk-pmtr2 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_systick: clk-systick {
+			compatible = "fixed-factor-clock";
+			clocks = <&clk_hclk>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+	};
+
+	soc {
+		timer2: timer@40000000 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000000 0x400>;
+			interrupts = <28>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM2)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer3: timer@40000400 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000400 0x400>;
+			interrupts = <29>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer4: timer@40000800 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000800 0x400>;
+			interrupts = <30>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM4)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer5: timer@40000c00 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000c00 0x400>;
+			interrupts = <50>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM5)>;
+			clocks = <&clk_pmtr1>;
+		};
+
+		timer6: timer@40001000 {
+			compatible = "st,stm32-timer";
+			reg = <0x40001000 0x400>;
+			interrupts = <54>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM6)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer7: timer@40001400 {
+			compatible = "st,stm32-timer";
+			reg = <0x40001400 0x400>;
+			interrupts = <55>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM7)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		usart2: serial@40004400 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40004400 0x400>;
+			interrupts = <38>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart3: serial@40004800 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40004800 0x400>;
+			interrupts = <39>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart4: serial@40004c00 {
+			compatible = "st,stm32-uart";
+			reg = <0x40004c00 0x400>;
+			interrupts = <52>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart5: serial@40005000 {
+			compatible = "st,stm32-uart";
+			reg = <0x40005000 0x400>;
+			interrupts = <53>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart7: serial@40007800 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40007800 0x400>;
+			interrupts = <82>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart8: serial@40007c00 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40007c00 0x400>;
+			interrupts = <83>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart1: serial@40011000 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40011000 0x400>;
+			interrupts = <37>;
+			clocks = <&clk_pclk2>;
+			status = "disabled";
+		};
+
+		usart6: serial@40011400 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40011400 0x400>;
+			interrupts = <71>;
+			clocks = <&clk_pclk2>;
+			status = "disabled";
+		};
+
+		rcc: rcc@40023810 {
+			#reset-cells = <1>;
+			compatible = "st,stm32-rcc";
+			reg = <0x40023800 0x400>;
+		};
+	};
+};
+
+&systick {
+	clocks = <&clk_systick>;
+	status = "okay";
+};
-- 
1.9.1

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

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 <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 arch/arm/boot/dts/Makefile            |   1 +
 arch/arm/boot/dts/stm32f429-disco.dts |  71 +++++++++++
 arch/arm/boot/dts/stm32f429.dtsi      | 227 ++++++++++++++++++++++++++++++++++
 3 files changed, 299 insertions(+)
 create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
 create mode 100644 arch/arm/boot/dts/stm32f429.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 86217db..db1d8c6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -520,6 +520,7 @@ dtb-$(CONFIG_ARCH_STI) += \
 	stih416-b2020.dtb \
 	stih416-b2020e.dtb \
 	stih418-b2199.dtb
+dtb-$(CONFIG_ARCH_STM32)+= stm32f429-disco.dtb
 dtb-$(CONFIG_MACH_SUN4I) += \
 	sun4i-a10-a1000.dtb \
 	sun4i-a10-ba10-tvbox.dtb \
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
new file mode 100644
index 0000000..6b9aa59
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -0,0 +1,71 @@
+/*
+ * Copyright 2015 - Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this file; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f429.dtsi"
+
+/ {
+	model = "STMicroelectronics STM32F429i-DISCO board";
+	compatible = "st,stm32f429i-disco", "st,stm32f429";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 root=/dev/ram rdinit=/linuxrc";
+		linux,stdout-path = &usart1;
+	};
+
+	memory {
+		reg = <0x90000000 0x800000>;
+	};
+
+	aliases {
+		serial0 = &usart1;
+	};
+};
+
+&usart1 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
new file mode 100644
index 0000000..2719f3a
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -0,0 +1,227 @@
+/*
+ * Copyright 2015 - Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this file; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armv7-m.dtsi"
+#include  <dt-bindings/mfd/stm32f4-rcc.h>
+
+/ {
+	clocks {
+		clk_sysclk: clk-sysclk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_hclk: clk-hclk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_pclk1: clk-pclk1 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <45000000>;
+		};
+
+		clk_pclk2: clk-pclk2 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <90000000>;
+		};
+
+		clk_pmtr1: clk-pmtr1 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <90000000>;
+		};
+
+		clk_pmtr2: clk-pmtr2 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_systick: clk-systick {
+			compatible = "fixed-factor-clock";
+			clocks = <&clk_hclk>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+	};
+
+	soc {
+		timer2: timer at 40000000 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000000 0x400>;
+			interrupts = <28>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM2)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer3: timer at 40000400 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000400 0x400>;
+			interrupts = <29>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer4: timer at 40000800 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000800 0x400>;
+			interrupts = <30>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM4)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer5: timer at 40000c00 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000c00 0x400>;
+			interrupts = <50>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM5)>;
+			clocks = <&clk_pmtr1>;
+		};
+
+		timer6: timer at 40001000 {
+			compatible = "st,stm32-timer";
+			reg = <0x40001000 0x400>;
+			interrupts = <54>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM6)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		timer7: timer at 40001400 {
+			compatible = "st,stm32-timer";
+			reg = <0x40001400 0x400>;
+			interrupts = <55>;
+			resets = <&rcc STM32F4_APB1_RESET(TIM7)>;
+			clocks = <&clk_pmtr1>;
+			status = "disabled";
+		};
+
+		usart2: serial at 40004400 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40004400 0x400>;
+			interrupts = <38>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart3: serial at 40004800 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40004800 0x400>;
+			interrupts = <39>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart4: serial at 40004c00 {
+			compatible = "st,stm32-uart";
+			reg = <0x40004c00 0x400>;
+			interrupts = <52>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart5: serial at 40005000 {
+			compatible = "st,stm32-uart";
+			reg = <0x40005000 0x400>;
+			interrupts = <53>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart7: serial at 40007800 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40007800 0x400>;
+			interrupts = <82>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart8: serial at 40007c00 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40007c00 0x400>;
+			interrupts = <83>;
+			clocks = <&clk_pclk1>;
+			status = "disabled";
+		};
+
+		usart1: serial at 40011000 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40011000 0x400>;
+			interrupts = <37>;
+			clocks = <&clk_pclk2>;
+			status = "disabled";
+		};
+
+		usart6: serial at 40011400 {
+			compatible = "st,stm32-usart", "st,stm32-uart";
+			reg = <0x40011400 0x400>;
+			interrupts = <71>;
+			clocks = <&clk_pclk2>;
+			status = "disabled";
+		};
+
+		rcc: rcc at 40023810 {
+			#reset-cells = <1>;
+			compatible = "st,stm32-rcc";
+			reg = <0x40023800 0x400>;
+		};
+	};
+};
+
+&systick {
+	clocks = <&clk_systick>;
+	status = "okay";
+};
-- 
1.9.1

[PATCH v8 15/16] ARM: configs: Add STM32 defconfig

[Maxime Coquelin]

This patch adds a new config for STM32 MCUs.
STM32F429 Discovery board boots successfully with this config applied.

Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm/configs/stm32_defconfig | 70 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 arch/arm/configs/stm32_defconfig

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
new file mode 100644
index 0000000..af757925
--- /dev/null
+++ b/arch/arm/configs/stm32_defconfig
@@ -0,0 +1,70 @@
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="./rootfs.cpio"
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_UID16 is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+# CONFIG_MMU is not set
+CONFIG_ARCH_STM32=y
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x90000000
+CONFIG_FLASH_MEM_BASE=0x08000000
+CONFIG_FLASH_SIZE=0x00200000
+CONFIG_PREEMPT=y
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_XIP_KERNEL=y
+CONFIG_XIP_PHYS_ADDR=0x08008000
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_COREDUMP is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_BLK_DEV is not set
+CONFIG_EEPROM_93CX6=y
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_UNIX98_PTYS is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_NONSTANDARD=y
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_STM32=y
+CONFIG_SERIAL_STM32_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+# CONFIG_FILE_LOCKING is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+CONFIG_NLS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_FTRACE is not set
+CONFIG_CRC_ITU_T=y
+CONFIG_CRC7=y
-- 
1.9.1

[PATCH v8 15/16] ARM: configs: Add STM32 defconfig

[Maxime Coquelin]

This patch adds a new config for STM32 MCUs.
STM32F429 Discovery board boots successfully with this config applied.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 arch/arm/configs/stm32_defconfig | 70 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 arch/arm/configs/stm32_defconfig

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
new file mode 100644
index 0000000..af757925
--- /dev/null
+++ b/arch/arm/configs/stm32_defconfig
@@ -0,0 +1,70 @@
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="./rootfs.cpio"
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_UID16 is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+# CONFIG_MMU is not set
+CONFIG_ARCH_STM32=y
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x90000000
+CONFIG_FLASH_MEM_BASE=0x08000000
+CONFIG_FLASH_SIZE=0x00200000
+CONFIG_PREEMPT=y
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_XIP_KERNEL=y
+CONFIG_XIP_PHYS_ADDR=0x08008000
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_COREDUMP is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_BLK_DEV is not set
+CONFIG_EEPROM_93CX6=y
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_UNIX98_PTYS is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_NONSTANDARD=y
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_STM32=y
+CONFIG_SERIAL_STM32_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+# CONFIG_FILE_LOCKING is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+CONFIG_NLS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_FTRACE is not set
+CONFIG_CRC_ITU_T=y
+CONFIG_CRC7=y
-- 
1.9.1

[PATCH v8 15/16] ARM: configs: Add STM32 defconfig

[Maxime Coquelin]

This patch adds a new config for STM32 MCUs.
STM32F429 Discovery board boots successfully with this config applied.

Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 arch/arm/configs/stm32_defconfig | 70 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 arch/arm/configs/stm32_defconfig

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
new file mode 100644
index 0000000..af757925
--- /dev/null
+++ b/arch/arm/configs/stm32_defconfig
@@ -0,0 +1,70 @@
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="./rootfs.cpio"
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_UID16 is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+# CONFIG_MMU is not set
+CONFIG_ARCH_STM32=y
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x90000000
+CONFIG_FLASH_MEM_BASE=0x08000000
+CONFIG_FLASH_SIZE=0x00200000
+CONFIG_PREEMPT=y
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_XIP_KERNEL=y
+CONFIG_XIP_PHYS_ADDR=0x08008000
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_COREDUMP is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_BLK_DEV is not set
+CONFIG_EEPROM_93CX6=y
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_UNIX98_PTYS is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_NONSTANDARD=y
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_STM32=y
+CONFIG_SERIAL_STM32_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+# CONFIG_FILE_LOCKING is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+CONFIG_NLS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_FTRACE is not set
+CONFIG_CRC_ITU_T=y
+CONFIG_CRC7=y
-- 
1.9.1

[PATCH v8 16/16] MAINTAINERS: Add entry for STM32 MCUs

[Maxime Coquelin]

Add a MAINTAINER entry covering all STM32 machine and drivers files.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+L:	linux-arm-kernel@lists.infradead.org (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 <kernel@wantstofly.org>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-- 
1.9.1

[PATCH v8 16/16] MAINTAINERS: Add entry for STM32 MCUs

[Maxime Coquelin]

Add a MAINTAINER entry covering all STM32 machine and drivers files.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+L:	linux-arm-kernel@lists.infradead.org (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 <kernel@wantstofly.org>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-- 
1.9.1

[PATCH v8 16/16] MAINTAINERS: Add entry for STM32 MCUs

[Maxime Coquelin]

Add a MAINTAINER entry covering all STM32 machine and drivers files.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 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 <mcoquelin.stm32@gmail.com>
+L:	linux-arm-kernel at lists.infradead.org (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 <kernel@wantstofly.org>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-- 
1.9.1

Re: [PATCH v8 11/16] serial: stm32-usart: Add STM32 USART Driver

[Andy Shevchenko]

On Sat, May 9, 2015 at 10:53 AM, Maxime Coquelin
<mcoquelin.stm32@gmail.com> wrote:
> This drivers adds support to the STM32 USART controller, which is a
> standard serial driver.
>

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/tty/serial/Kconfig       |  17 +
>  drivers/tty/serial/Makefile      |   1 +
>  drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/serial_core.h |   3 +
>  4 files changed, 760 insertions(+)
>  create mode 100644 drivers/tty/serial/stm32-usart.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index f8120c1..7eb62f1 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1589,6 +1589,23 @@ config SERIAL_SPRD_CONSOLE
>           with "earlycon" on the kernel command line. The console is
>           enabled when early_param is processed.
>
> +config SERIAL_STM32
> +       tristate "STMicroelectronics STM32 serial port support"
> +       select SERIAL_CORE
> +       depends on ARM || COMPILE_TEST
> +       help
> +         This driver is for the on-chip Serial Controller on
> +         STMicroelectronics STM32 MCUs.
> +         USART supports Rx & Tx functionality.
> +         It support all industry standard baud rates.
> +
> +         If unsure, say N.
> +
> +config SERIAL_STM32_CONSOLE
> +       bool "Support for console on STM32"
> +       depends on SERIAL_STM32=y
> +       select SERIAL_CORE_CONSOLE
> +
>  endmenu
>
>  config SERIAL_MCTRL_GPIO
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index c3ac3d9..61979ce 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART)       += fsl_lpuart.o
>  obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)        += digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)  += men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
> +obj-$(CONFIG_SERIAL_STM32)     += stm32-usart.o
>
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)        += serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> new file mode 100644
> index 0000000..4a6eab6
> --- /dev/null
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -0,0 +1,739 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author:  Maxime Coquelin <mcoquelin.stm32@gmail.com>
> + * License terms:  GNU General Public License (GPL), version 2
> + *
> + * Inspired by st-asc.c from STMicroelectronics (c)
> + */
> +
> +#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> +#define SUPPORT_SYSRQ
> +#endif
> +
> +#include <linux/module.h>
> +#include <linux/serial.h>
> +#include <linux/console.h>
> +#include <linux/sysrq.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/irq.h>
> +#include <linux/tty.h>
> +#include <linux/tty_flip.h>
> +#include <linux/delay.h>
> +#include <linux/spinlock.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/serial_core.h>
> +#include <linux/clk.h>
> +
> +#define DRIVER_NAME "stm32-usart"
> +
> +/* Register offsets */
> +#define USART_SR               0x00
> +#define USART_DR               0x04
> +#define USART_BRR              0x08
> +#define USART_CR1              0x0c
> +#define USART_CR2              0x10
> +#define USART_CR3              0x14
> +#define USART_GTPR             0x18
> +
> +/* USART_SR */
> +#define USART_SR_PE            BIT(0)
> +#define USART_SR_FE            BIT(1)
> +#define USART_SR_NF            BIT(2)
> +#define USART_SR_ORE           BIT(3)
> +#define USART_SR_IDLE          BIT(4)
> +#define USART_SR_RXNE          BIT(5)
> +#define USART_SR_TC            BIT(6)
> +#define USART_SR_TXE           BIT(7)
> +#define USART_SR_LBD           BIT(8)
> +#define USART_SR_CTS           BIT(9)
> +#define USART_SR_ERR_MASK      (USART_SR_LBD | USART_SR_ORE | \
> +                                USART_SR_FE | USART_SR_PE)
> +/* Dummy bits */
> +#define USART_SR_DUMMY_RX      BIT(16)
> +
> +/* USART_DR */
> +#define USART_DR_MASK          GENMASK(8, 0)
> +
> +/* USART_BRR */
> +#define USART_BRR_DIV_F_MASK   GENMASK(3, 0)
> +#define USART_BRR_DIV_M_MASK   GENMASK(15, 4)
> +#define USART_BRR_DIV_M_SHIFT  4
> +
> +/* USART_CR1 */
> +#define USART_CR1_SBK          BIT(0)
> +#define USART_CR1_RWU          BIT(1)
> +#define USART_CR1_RE           BIT(2)
> +#define USART_CR1_TE           BIT(3)
> +#define USART_CR1_IDLEIE       BIT(4)
> +#define USART_CR1_RXNEIE       BIT(5)
> +#define USART_CR1_TCIE         BIT(6)
> +#define USART_CR1_TXEIE                BIT(7)
> +#define USART_CR1_PEIE         BIT(8)
> +#define USART_CR1_PS           BIT(9)
> +#define USART_CR1_PCE          BIT(10)
> +#define USART_CR1_WAKE         BIT(11)
> +#define USART_CR1_M            BIT(12)
> +#define USART_CR1_UE           BIT(13)
> +#define USART_CR1_OVER8                BIT(15)
> +#define USART_CR1_IE_MASK      GENMASK(8, 4)
> +
> +/* USART_CR2 */
> +#define USART_CR2_ADD_MASK     GENMASK(3, 0)
> +#define USART_CR2_LBDL         BIT(5)
> +#define USART_CR2_LBDIE                BIT(6)
> +#define USART_CR2_LBCL         BIT(8)
> +#define USART_CR2_CPHA         BIT(9)
> +#define USART_CR2_CPOL         BIT(10)
> +#define USART_CR2_CLKEN                BIT(11)
> +#define USART_CR2_STOP_2B      BIT(13)
> +#define USART_CR2_STOP_MASK    GENMASK(13, 12)
> +#define USART_CR2_LINEN                BIT(14)
> +
> +/* USART_CR3 */
> +#define USART_CR3_EIE          BIT(0)
> +#define USART_CR3_IREN         BIT(1)
> +#define USART_CR3_IRLP         BIT(2)
> +#define USART_CR3_HDSEL                BIT(3)
> +#define USART_CR3_NACK         BIT(4)
> +#define USART_CR3_SCEN         BIT(5)
> +#define USART_CR3_DMAR         BIT(6)
> +#define USART_CR3_DMAT         BIT(7)
> +#define USART_CR3_RTSE         BIT(8)
> +#define USART_CR3_CTSE         BIT(9)
> +#define USART_CR3_CTSIE                BIT(10)
> +#define USART_CR3_ONEBIT       BIT(11)
> +
> +/* USART_GTPR */
> +#define USART_GTPR_PSC_MASK    GENMASK(7, 0)
> +#define USART_GTPR_GT_MASK     GENMASK(15, 8)
> +
> +#define DRIVER_NAME "stm32-usart"
> +#define STM32_SERIAL_NAME "ttyS"
> +#define STM32_MAX_PORTS 6
> +
> +struct stm32_port {
> +       struct uart_port port;
> +       struct clk *clk;
> +       bool hw_flow_control;
> +};
> +
> +static struct stm32_port stm32_ports[STM32_MAX_PORTS];
> +static struct uart_driver stm32_usart_driver;
> +
> +static void stm32_stop_tx(struct uart_port *port);
> +
> +static inline struct stm32_port *to_stm32_port(struct uart_port *port)
> +{
> +       return container_of(port, struct stm32_port, port);
> +}
> +
> +static void stm32_set_bits(struct uart_port *port, u32 reg, u32 bits)
> +{
> +       u32 val;
> +
> +       val = readl_relaxed(port->membase + reg);
> +       val |= bits;
> +       writel_relaxed(val, port->membase + reg);
> +}
> +
> +static void stm32_clr_bits(struct uart_port *port, u32 reg, u32 bits)
> +{
> +       u32 val;
> +
> +       val = readl_relaxed(port->membase + reg);
> +       val &= ~bits;
> +       writel_relaxed(val, port->membase + reg);
> +}
> +
> +static void stm32_receive_chars(struct uart_port *port)
> +{
> +       struct tty_port *tport = &port->state->port;
> +       unsigned long c;
> +       u32 sr;
> +       char flag;
> +
> +       if (port->irq_wake)
> +               pm_wakeup_event(tport->tty->dev, 0);
> +
> +       while ((sr = readl_relaxed(port->membase + USART_SR)) & USART_SR_RXNE) {
> +               sr |= USART_SR_DUMMY_RX;
> +               c = readl_relaxed(port->membase + USART_DR);
> +               flag = TTY_NORMAL;
> +               port->icount.rx++;
> +
> +               if (sr & USART_SR_ERR_MASK) {
> +                       if (sr & USART_SR_LBD) {
> +                               port->icount.brk++;
> +                               if (uart_handle_break(port))
> +                                       continue;
> +                       } else if (sr & USART_SR_ORE) {
> +                               port->icount.overrun++;
> +                       } else if (sr & USART_SR_PE) {
> +                               port->icount.parity++;
> +                       } else if (sr & USART_SR_FE) {
> +                               port->icount.frame++;
> +                       }
> +
> +                       sr &= port->read_status_mask;
> +
> +                       if (sr & USART_SR_LBD)
> +                               flag = TTY_BREAK;
> +                       else if (sr & USART_SR_PE)
> +                               flag = TTY_PARITY;
> +                       else if (sr & USART_SR_FE)
> +                               flag = TTY_FRAME;
> +               }
> +
> +               if (uart_handle_sysrq_char(port, c))
> +                       continue;
> +               uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> +       }
> +
> +       spin_unlock(&port->lock);
> +       tty_flip_buffer_push(tport);
> +       spin_lock(&port->lock);
> +}
> +
> +static void stm32_transmit_chars(struct uart_port *port)
> +{
> +       struct circ_buf *xmit = &port->state->xmit;
> +
> +       if (port->x_char) {
> +               writel_relaxed(port->x_char, port->membase + USART_DR);
> +               port->x_char = 0;
> +               port->icount.tx++;
> +               return;
> +       }
> +
> +       if (uart_tx_stopped(port)) {
> +               stm32_stop_tx(port);
> +               return;
> +       }
> +
> +       if (uart_circ_empty(xmit)) {
> +               stm32_stop_tx(port);
> +               return;
> +       }
> +
> +       writel_relaxed(xmit->buf[xmit->tail], port->membase + USART_DR);
> +       xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> +       port->icount.tx++;
> +
> +       if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +               uart_write_wakeup(port);
> +
> +       if (uart_circ_empty(xmit))
> +               stm32_stop_tx(port);
> +}
> +
> +static irqreturn_t stm32_interrupt(int irq, void *ptr)
> +{
> +       struct uart_port *port = ptr;
> +       u32 sr;
> +
> +       spin_lock(&port->lock);
> +
> +       sr = readl_relaxed(port->membase + USART_SR);
> +
> +       if (sr & USART_SR_RXNE)
> +               stm32_receive_chars(port);
> +
> +       if (sr & USART_SR_TXE)
> +               stm32_transmit_chars(port);
> +
> +       spin_unlock(&port->lock);
> +
> +       return IRQ_HANDLED;
> +}
> +
> +static unsigned int stm32_tx_empty(struct uart_port *port)
> +{
> +       return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
> +}
> +
> +static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> +       if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
> +               stm32_set_bits(port, USART_CR3, USART_CR3_RTSE);
> +       else
> +               stm32_clr_bits(port, USART_CR3, USART_CR3_RTSE);
> +}
> +
> +static unsigned int stm32_get_mctrl(struct uart_port *port)
> +{
> +       /* This routine is used to get signals of: DCD, DSR, RI, and CTS */
> +       return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
> +}
> +
> +/* Transmit stop */
> +static void stm32_stop_tx(struct uart_port *port)
> +{
> +       stm32_clr_bits(port, USART_CR1, USART_CR1_TXEIE);
> +}
> +
> +/* There are probably characters waiting to be transmitted. */
> +static void stm32_start_tx(struct uart_port *port)
> +{
> +       struct circ_buf *xmit = &port->state->xmit;
> +
> +       if (uart_circ_empty(xmit))
> +               return;
> +
> +       stm32_set_bits(port, USART_CR1, USART_CR1_TXEIE | USART_CR1_TE);
> +}
> +
> +/* Throttle the remote when input buffer is about to overflow. */
> +static void stm32_throttle(struct uart_port *port)
> +{
> +       unsigned long flags;
> +
> +       spin_lock_irqsave(&port->lock, flags);
> +       stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +       spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +/* Unthrottle the remote, the input buffer can now accept data. */
> +static void stm32_unthrottle(struct uart_port *port)
> +{
> +       unsigned long flags;
> +
> +       spin_lock_irqsave(&port->lock, flags);
> +       stm32_set_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +       spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +/* Receive stop */
> +static void stm32_stop_rx(struct uart_port *port)
> +{
> +       stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +}
> +
> +/* Handle breaks - ignored by us */
> +static void stm32_break_ctl(struct uart_port *port, int break_state)
> +{
> +}
> +
> +static int stm32_startup(struct uart_port *port)
> +{
> +       const char *name = to_platform_device(port->dev)->name;
> +       u32 val;
> +       int ret;
> +
> +       ret = request_irq(port->irq, stm32_interrupt, IRQF_NO_SUSPEND,
> +                         name, port);
> +       if (ret)
> +               return ret;
> +
> +       val = USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
> +       stm32_set_bits(port, USART_CR1, val);
> +
> +       return 0;
> +}
> +
> +static void stm32_shutdown(struct uart_port *port)
> +{
> +       u32 val;
> +
> +       val = USART_CR1_TXEIE | USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
> +       stm32_set_bits(port, USART_CR1, val);
> +
> +       free_irq(port->irq, port);
> +}
> +
> +static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
> +                           struct ktermios *old)
> +{
> +       struct stm32_port *stm32_port = to_stm32_port(port);
> +       unsigned int baud;
> +       u32 usartdiv, mantissa, fraction, oversampling;
> +       tcflag_t cflag = termios->c_cflag;
> +       u32 cr1, cr2, cr3;
> +       unsigned long flags;
> +
> +       if (!stm32_port->hw_flow_control)
> +               cflag &= ~CRTSCTS;
> +
> +       baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 8);
> +
> +       spin_lock_irqsave(&port->lock, flags);
> +
> +       /* Stop serial port and reset value */
> +       writel_relaxed(0, port->membase + USART_CR1);
> +
> +       cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
> +       cr2 = 0;
> +       cr3 = 0;
> +
> +       if (cflag & CSTOPB)
> +               cr2 |= USART_CR2_STOP_2B;
> +
> +       if (cflag & PARENB) {
> +               cr1 |= USART_CR1_PCE;
> +               if ((cflag & CSIZE) == CS8)
> +                       cr1 |= USART_CR1_M;
> +       }
> +
> +       if (cflag & PARODD)
> +               cr1 |= USART_CR1_PS;
> +
> +       port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS);
> +       if (cflag & CRTSCTS) {
> +               port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
> +               cr3 |= USART_CR3_CTSE;
> +       }
> +
> +       usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
> +
> +       /*
> +        * The USART supports 16 or 8 times oversampling.
> +        * By default we prefer 16 times oversampling, so that the receiver
> +        * has a better tolerance to clock deviations.
> +        * 8 times oversampling is only used to achieve higher speeds.
> +        */
> +       if (usartdiv < 16) {
> +               oversampling = 8;
> +               stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
> +       } else {
> +               oversampling = 16;
> +               stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
> +       }
> +
> +       mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
> +       fraction = usartdiv % oversampling;
> +       writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
> +
> +       uart_update_timeout(port, cflag, baud);
> +
> +       port->read_status_mask = USART_SR_ORE;
> +       if (termios->c_iflag & INPCK)
> +               port->read_status_mask |= USART_SR_PE | USART_SR_FE;
> +       if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
> +               port->read_status_mask |= USART_SR_LBD;
> +
> +       /* Characters to ignore */
> +       port->ignore_status_mask = 0;
> +       if (termios->c_iflag & IGNPAR)
> +               port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
> +       if (termios->c_iflag & IGNBRK) {
> +               port->ignore_status_mask |= USART_SR_LBD;
> +               /*
> +                * If we're ignoring parity and break indicators,
> +                * ignore overruns too (for real raw support).
> +                */
> +               if (termios->c_iflag & IGNPAR)
> +                       port->ignore_status_mask |= USART_SR_ORE;
> +       }
> +
> +       /* Ignore all characters if CREAD is not set */
> +       if ((termios->c_cflag & CREAD) == 0)
> +               port->ignore_status_mask |= USART_SR_DUMMY_RX;
> +
> +       writel_relaxed(cr3, port->membase + USART_CR3);
> +       writel_relaxed(cr2, port->membase + USART_CR2);
> +       writel_relaxed(cr1, port->membase + USART_CR1);
> +
> +       spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static const char *stm32_type(struct uart_port *port)
> +{
> +       return (port->type == PORT_STM32) ? DRIVER_NAME : NULL;
> +}
> +
> +static void stm32_release_port(struct uart_port *port)
> +{
> +}
> +
> +static int stm32_request_port(struct uart_port *port)
> +{
> +       return 0;
> +}
> +
> +static void stm32_config_port(struct uart_port *port, int flags)
> +{
> +       if (flags & UART_CONFIG_TYPE)
> +               port->type = PORT_STM32;
> +}
> +
> +static int
> +stm32_verify_port(struct uart_port *port, struct serial_struct *ser)
> +{
> +       /* No user changeable parameters */
> +       return -EINVAL;
> +}
> +
> +static void stm32_pm(struct uart_port *port, unsigned int state,
> +               unsigned int oldstate)
> +{
> +       struct stm32_port *stm32port = container_of(port,
> +                       struct stm32_port, port);
> +       unsigned long flags = 0;
> +
> +       switch (state) {
> +       case UART_PM_STATE_ON:
> +               clk_prepare_enable(stm32port->clk);
> +               break;
> +       case UART_PM_STATE_OFF:
> +               spin_lock_irqsave(&port->lock, flags);
> +               stm32_clr_bits(port, USART_CR1, USART_CR1_UE);
> +               spin_unlock_irqrestore(&port->lock, flags);
> +               clk_disable_unprepare(stm32port->clk);
> +               break;
> +       }
> +}
> +
> +static const struct uart_ops stm32_uart_ops = {
> +       .tx_empty       = stm32_tx_empty,
> +       .set_mctrl      = stm32_set_mctrl,
> +       .get_mctrl      = stm32_get_mctrl,
> +       .stop_tx        = stm32_stop_tx,
> +       .start_tx       = stm32_start_tx,
> +       .throttle       = stm32_throttle,
> +       .unthrottle     = stm32_unthrottle,
> +       .stop_rx        = stm32_stop_rx,
> +       .break_ctl      = stm32_break_ctl,
> +       .startup        = stm32_startup,
> +       .shutdown       = stm32_shutdown,
> +       .set_termios    = stm32_set_termios,
> +       .pm             = stm32_pm,
> +       .type           = stm32_type,
> +       .release_port   = stm32_release_port,
> +       .request_port   = stm32_request_port,
> +       .config_port    = stm32_config_port,
> +       .verify_port    = stm32_verify_port,
> +};
> +
> +static int stm32_init_port(struct stm32_port *stm32port,
> +                         struct platform_device *pdev)
> +{
> +       struct uart_port *port = &stm32port->port;
> +       struct resource *res;
> +       int ret;
> +
> +       port->iotype    = UPIO_MEM;
> +       port->flags     = UPF_BOOT_AUTOCONF;
> +       port->ops       = &stm32_uart_ops;
> +       port->dev       = &pdev->dev;
> +       port->irq       = platform_get_irq(pdev, 0);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       port->membase = devm_ioremap_resource(&pdev->dev, res);
> +       if (IS_ERR(port->membase))
> +               return PTR_ERR(port->membase);
> +       port->mapbase = res->start;
> +
> +       spin_lock_init(&port->lock);
> +
> +       stm32port->clk = devm_clk_get(&pdev->dev, NULL);
> +       if (IS_ERR(stm32port->clk))
> +               return PTR_ERR(stm32port->clk);
> +
> +       /* Ensure that clk rate is correct by enabling the clk */
> +       ret = clk_prepare_enable(stm32port->clk);
> +       if (ret)
> +               return ret;
> +
> +       stm32port->port.uartclk = clk_get_rate(stm32port->clk);
> +       if (!stm32port->port.uartclk)
> +               ret = -EINVAL;
> +
> +       clk_disable_unprepare(stm32port->clk);
> +
> +       return ret;
> +}
> +
> +static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
> +{
> +       struct device_node *np = pdev->dev.of_node;
> +       int id;
> +
> +       if (!np)
> +               return NULL;
> +
> +       id = of_alias_get_id(np, "serial");
> +       if (id < 0)
> +               id = 0;
> +
> +       if (WARN_ON(id >= STM32_MAX_PORTS))
> +               return NULL;
> +
> +       stm32_ports[id].hw_flow_control = of_property_read_bool(np,
> +                                                       "auto-flow-control");
> +       stm32_ports[id].port.line = id;
> +       return &stm32_ports[id];
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id stm32_match[] = {
> +       { .compatible = "st,stm32-usart", },
> +       { .compatible = "st,stm32-uart", },
> +       {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, stm32_match);
> +#endif
> +
> +static int stm32_serial_probe(struct platform_device *pdev)
> +{
> +       int ret;
> +       struct stm32_port *stm32port;
> +
> +       stm32port = stm32_of_get_stm32_port(pdev);
> +       if (!stm32port)
> +               return -ENODEV;
> +
> +       ret = stm32_init_port(stm32port, pdev);
> +       if (ret)
> +               return ret;
> +
> +       ret = uart_add_one_port(&stm32_usart_driver, &stm32port->port);
> +       if (ret)
> +               return ret;
> +
> +       platform_set_drvdata(pdev, &stm32port->port);
> +
> +       return 0;
> +}
> +
> +static int stm32_serial_remove(struct platform_device *pdev)
> +{
> +       struct uart_port *port = platform_get_drvdata(pdev);
> +
> +       return uart_remove_one_port(&stm32_usart_driver, port);
> +}
> +
> +
> +#ifdef CONFIG_SERIAL_STM32_CONSOLE
> +static void stm32_console_putchar(struct uart_port *port, int ch)
> +{
> +       while (!(readl_relaxed(port->membase + USART_SR) & USART_SR_TXE))
> +               cpu_relax();
> +
> +       writel_relaxed(ch, port->membase + USART_DR);
> +}
> +
> +static void stm32_console_write(struct console *co, const char *s, unsigned cnt)
> +{
> +       struct uart_port *port = &stm32_ports[co->index].port;
> +       unsigned long flags;
> +       u32 old_cr1, new_cr1;
> +       int locked = 1;
> +
> +       local_irq_save(flags);
> +       if (port->sysrq)
> +               locked = 0;
> +       else if (oops_in_progress)
> +               locked = spin_trylock(&port->lock);
> +       else
> +               spin_lock(&port->lock);
> +
> +       /* Save and disable interrupts */
> +       old_cr1 = readl_relaxed(port->membase + USART_CR1);
> +       new_cr1 = old_cr1 & ~USART_CR1_IE_MASK;
> +       writel_relaxed(new_cr1, port->membase + USART_CR1);
> +
> +       uart_console_write(port, s, cnt, stm32_console_putchar);
> +
> +       /* Restore interrupt state */
> +       writel_relaxed(old_cr1, port->membase + USART_CR1);
> +
> +       if (locked)
> +               spin_unlock(&port->lock);
> +       local_irq_restore(flags);
> +}
> +
> +static int stm32_console_setup(struct console *co, char *options)
> +{
> +       struct stm32_port *stm32port;
> +       int baud = 9600;
> +       int bits = 8;
> +       int parity = 'n';
> +       int flow = 'n';
> +
> +       if (co->index >= STM32_MAX_PORTS)
> +               return -ENODEV;
> +
> +       stm32port = &stm32_ports[co->index];
> +
> +       /*
> +        * This driver does not support early console initialization
> +        * (use ARM early printk support instead), so we only expect
> +        * this to be called during the uart port registration when the
> +        * driver gets probed and the port should be mapped at that point.
> +        */
> +       if (stm32port->port.mapbase == 0 || stm32port->port.membase == NULL)
> +               return -ENXIO;
> +
> +       if (options)
> +               uart_parse_options(options, &baud, &parity, &bits, &flow);
> +
> +       return uart_set_options(&stm32port->port, co, baud, parity, bits, flow);
> +}
> +
> +static struct console stm32_console = {
> +       .name           = STM32_SERIAL_NAME,
> +       .device         = uart_console_device,
> +       .write          = stm32_console_write,
> +       .setup          = stm32_console_setup,
> +       .flags          = CON_PRINTBUFFER,
> +       .index          = -1,
> +       .data           = &stm32_usart_driver,
> +};
> +
> +#define STM32_SERIAL_CONSOLE (&stm32_console)
> +
> +#else
> +#define STM32_SERIAL_CONSOLE NULL
> +#endif /* CONFIG_SERIAL_STM32_CONSOLE */
> +
> +static struct uart_driver stm32_usart_driver = {
> +       .driver_name    = DRIVER_NAME,
> +       .dev_name       = STM32_SERIAL_NAME,
> +       .major          = 0,
> +       .minor          = 0,
> +       .nr             = STM32_MAX_PORTS,
> +       .cons           = STM32_SERIAL_CONSOLE,
> +};
> +
> +static struct platform_driver stm32_serial_driver = {
> +       .probe          = stm32_serial_probe,
> +       .remove         = stm32_serial_remove,
> +       .driver = {
> +               .name   = DRIVER_NAME,
> +               .of_match_table = of_match_ptr(stm32_match),
> +       },
> +};
> +
> +static int __init usart_init(void)
> +{
> +       static char banner[] __initdata = "STM32 USART driver initialized";
> +       int ret;
> +
> +       pr_info("%s\n", banner);
> +
> +       ret = uart_register_driver(&stm32_usart_driver);
> +       if (ret)
> +               return ret;
> +
> +       ret = platform_driver_register(&stm32_serial_driver);
> +       if (ret)
> +               uart_unregister_driver(&stm32_usart_driver);
> +
> +       return ret;
> +}
> +
> +static void __exit usart_exit(void)
> +{
> +       platform_driver_unregister(&stm32_serial_driver);
> +       uart_unregister_driver(&stm32_usart_driver);
> +}
> +
> +module_init(usart_init);
> +module_exit(usart_exit);
> +
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> +MODULE_DESCRIPTION("STMicroelectronics STM32 serial port driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index b212281..93ba148 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -258,4 +258,7 @@
>  /* Cris v10 / v32 SoC */
>  #define PORT_CRIS      112
>
> +/* STM32 USART */
> +#define PORT_STM32     113
> +
>  #endif /* _UAPILINUX_SERIAL_CORE_H */
> --
> 1.9.1
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v8 11/16] serial: stm32-usart: Add STM32 USART Driver

[Andy Shevchenko]

On Sat, May 9, 2015 at 10:53 AM, Maxime Coquelin
<mcoquelin.stm32@gmail.com> wrote:
> This drivers adds support to the STM32 USART controller, which is a
> standard serial driver.
>

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/tty/serial/Kconfig       |  17 +
>  drivers/tty/serial/Makefile      |   1 +
>  drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/serial_core.h |   3 +
>  4 files changed, 760 insertions(+)
>  create mode 100644 drivers/tty/serial/stm32-usart.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index f8120c1..7eb62f1 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1589,6 +1589,23 @@ config SERIAL_SPRD_CONSOLE
>           with "earlycon" on the kernel command line. The console is
>           enabled when early_param is processed.
>
> +config SERIAL_STM32
> +       tristate "STMicroelectronics STM32 serial port support"
> +       select SERIAL_CORE
> +       depends on ARM || COMPILE_TEST
> +       help
> +         This driver is for the on-chip Serial Controller on
> +         STMicroelectronics STM32 MCUs.
> +         USART supports Rx & Tx functionality.
> +         It support all industry standard baud rates.
> +
> +         If unsure, say N.
> +
> +config SERIAL_STM32_CONSOLE
> +       bool "Support for console on STM32"
> +       depends on SERIAL_STM32=y
> +       select SERIAL_CORE_CONSOLE
> +
>  endmenu
>
>  config SERIAL_MCTRL_GPIO
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index c3ac3d9..61979ce 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART)       += fsl_lpuart.o
>  obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)        += digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)  += men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
> +obj-$(CONFIG_SERIAL_STM32)     += stm32-usart.o
>
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)        += serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> new file mode 100644
> index 0000000..4a6eab6
> --- /dev/null
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -0,0 +1,739 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author:  Maxime Coquelin <mcoquelin.stm32@gmail.com>
> + * License terms:  GNU General Public License (GPL), version 2
> + *
> + * Inspired by st-asc.c from STMicroelectronics (c)
> + */
> +
> +#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> +#define SUPPORT_SYSRQ
> +#endif
> +
> +#include <linux/module.h>
> +#include <linux/serial.h>
> +#include <linux/console.h>
> +#include <linux/sysrq.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/irq.h>
> +#include <linux/tty.h>
> +#include <linux/tty_flip.h>
> +#include <linux/delay.h>
> +#include <linux/spinlock.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/serial_core.h>
> +#include <linux/clk.h>
> +
> +#define DRIVER_NAME "stm32-usart"
> +
> +/* Register offsets */
> +#define USART_SR               0x00
> +#define USART_DR               0x04
> +#define USART_BRR              0x08
> +#define USART_CR1              0x0c
> +#define USART_CR2              0x10
> +#define USART_CR3              0x14
> +#define USART_GTPR             0x18
> +
> +/* USART_SR */
> +#define USART_SR_PE            BIT(0)
> +#define USART_SR_FE            BIT(1)
> +#define USART_SR_NF            BIT(2)
> +#define USART_SR_ORE           BIT(3)
> +#define USART_SR_IDLE          BIT(4)
> +#define USART_SR_RXNE          BIT(5)
> +#define USART_SR_TC            BIT(6)
> +#define USART_SR_TXE           BIT(7)
> +#define USART_SR_LBD           BIT(8)
> +#define USART_SR_CTS           BIT(9)
> +#define USART_SR_ERR_MASK      (USART_SR_LBD | USART_SR_ORE | \
> +                                USART_SR_FE | USART_SR_PE)
> +/* Dummy bits */
> +#define USART_SR_DUMMY_RX      BIT(16)
> +
> +/* USART_DR */
> +#define USART_DR_MASK          GENMASK(8, 0)
> +
> +/* USART_BRR */
> +#define USART_BRR_DIV_F_MASK   GENMASK(3, 0)
> +#define USART_BRR_DIV_M_MASK   GENMASK(15, 4)
> +#define USART_BRR_DIV_M_SHIFT  4
> +
> +/* USART_CR1 */
> +#define USART_CR1_SBK          BIT(0)
> +#define USART_CR1_RWU          BIT(1)
> +#define USART_CR1_RE           BIT(2)
> +#define USART_CR1_TE           BIT(3)
> +#define USART_CR1_IDLEIE       BIT(4)
> +#define USART_CR1_RXNEIE       BIT(5)
> +#define USART_CR1_TCIE         BIT(6)
> +#define USART_CR1_TXEIE                BIT(7)
> +#define USART_CR1_PEIE         BIT(8)
> +#define USART_CR1_PS           BIT(9)
> +#define USART_CR1_PCE          BIT(10)
> +#define USART_CR1_WAKE         BIT(11)
> +#define USART_CR1_M            BIT(12)
> +#define USART_CR1_UE           BIT(13)
> +#define USART_CR1_OVER8                BIT(15)
> +#define USART_CR1_IE_MASK      GENMASK(8, 4)
> +
> +/* USART_CR2 */
> +#define USART_CR2_ADD_MASK     GENMASK(3, 0)
> +#define USART_CR2_LBDL         BIT(5)
> +#define USART_CR2_LBDIE                BIT(6)
> +#define USART_CR2_LBCL         BIT(8)
> +#define USART_CR2_CPHA         BIT(9)
> +#define USART_CR2_CPOL         BIT(10)
> +#define USART_CR2_CLKEN                BIT(11)
> +#define USART_CR2_STOP_2B      BIT(13)
> +#define USART_CR2_STOP_MASK    GENMASK(13, 12)
> +#define USART_CR2_LINEN                BIT(14)
> +
> +/* USART_CR3 */
> +#define USART_CR3_EIE          BIT(0)
> +#define USART_CR3_IREN         BIT(1)
> +#define USART_CR3_IRLP         BIT(2)
> +#define USART_CR3_HDSEL                BIT(3)
> +#define USART_CR3_NACK         BIT(4)
> +#define USART_CR3_SCEN         BIT(5)
> +#define USART_CR3_DMAR         BIT(6)
> +#define USART_CR3_DMAT         BIT(7)
> +#define USART_CR3_RTSE         BIT(8)
> +#define USART_CR3_CTSE         BIT(9)
> +#define USART_CR3_CTSIE                BIT(10)
> +#define USART_CR3_ONEBIT       BIT(11)
> +
> +/* USART_GTPR */
> +#define USART_GTPR_PSC_MASK    GENMASK(7, 0)
> +#define USART_GTPR_GT_MASK     GENMASK(15, 8)
> +
> +#define DRIVER_NAME "stm32-usart"
> +#define STM32_SERIAL_NAME "ttyS"
> +#define STM32_MAX_PORTS 6
> +
> +struct stm32_port {
> +       struct uart_port port;
> +       struct clk *clk;
> +       bool hw_flow_control;
> +};
> +
> +static struct stm32_port stm32_ports[STM32_MAX_PORTS];
> +static struct uart_driver stm32_usart_driver;
> +
> +static void stm32_stop_tx(struct uart_port *port);
> +
> +static inline struct stm32_port *to_stm32_port(struct uart_port *port)
> +{
> +       return container_of(port, struct stm32_port, port);
> +}
> +
> +static void stm32_set_bits(struct uart_port *port, u32 reg, u32 bits)
> +{
> +       u32 val;
> +
> +       val = readl_relaxed(port->membase + reg);
> +       val |= bits;
> +       writel_relaxed(val, port->membase + reg);
> +}
> +
> +static void stm32_clr_bits(struct uart_port *port, u32 reg, u32 bits)
> +{
> +       u32 val;
> +
> +       val = readl_relaxed(port->membase + reg);
> +       val &= ~bits;
> +       writel_relaxed(val, port->membase + reg);
> +}
> +
> +static void stm32_receive_chars(struct uart_port *port)
> +{
> +       struct tty_port *tport = &port->state->port;
> +       unsigned long c;
> +       u32 sr;
> +       char flag;
> +
> +       if (port->irq_wake)
> +               pm_wakeup_event(tport->tty->dev, 0);
> +
> +       while ((sr = readl_relaxed(port->membase + USART_SR)) & USART_SR_RXNE) {
> +               sr |= USART_SR_DUMMY_RX;
> +               c = readl_relaxed(port->membase + USART_DR);
> +               flag = TTY_NORMAL;
> +               port->icount.rx++;
> +
> +               if (sr & USART_SR_ERR_MASK) {
> +                       if (sr & USART_SR_LBD) {
> +                               port->icount.brk++;
> +                               if (uart_handle_break(port))
> +                                       continue;
> +                       } else if (sr & USART_SR_ORE) {
> +                               port->icount.overrun++;
> +                       } else if (sr & USART_SR_PE) {
> +                               port->icount.parity++;
> +                       } else if (sr & USART_SR_FE) {
> +                               port->icount.frame++;
> +                       }
> +
> +                       sr &= port->read_status_mask;
> +
> +                       if (sr & USART_SR_LBD)
> +                               flag = TTY_BREAK;
> +                       else if (sr & USART_SR_PE)
> +                               flag = TTY_PARITY;
> +                       else if (sr & USART_SR_FE)
> +                               flag = TTY_FRAME;
> +               }
> +
> +               if (uart_handle_sysrq_char(port, c))
> +                       continue;
> +               uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> +       }
> +
> +       spin_unlock(&port->lock);
> +       tty_flip_buffer_push(tport);
> +       spin_lock(&port->lock);
> +}
> +
> +static void stm32_transmit_chars(struct uart_port *port)
> +{
> +       struct circ_buf *xmit = &port->state->xmit;
> +
> +       if (port->x_char) {
> +               writel_relaxed(port->x_char, port->membase + USART_DR);
> +               port->x_char = 0;
> +               port->icount.tx++;
> +               return;
> +       }
> +
> +       if (uart_tx_stopped(port)) {
> +               stm32_stop_tx(port);
> +               return;
> +       }
> +
> +       if (uart_circ_empty(xmit)) {
> +               stm32_stop_tx(port);
> +               return;
> +       }
> +
> +       writel_relaxed(xmit->buf[xmit->tail], port->membase + USART_DR);
> +       xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> +       port->icount.tx++;
> +
> +       if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +               uart_write_wakeup(port);
> +
> +       if (uart_circ_empty(xmit))
> +               stm32_stop_tx(port);
> +}
> +
> +static irqreturn_t stm32_interrupt(int irq, void *ptr)
> +{
> +       struct uart_port *port = ptr;
> +       u32 sr;
> +
> +       spin_lock(&port->lock);
> +
> +       sr = readl_relaxed(port->membase + USART_SR);
> +
> +       if (sr & USART_SR_RXNE)
> +               stm32_receive_chars(port);
> +
> +       if (sr & USART_SR_TXE)
> +               stm32_transmit_chars(port);
> +
> +       spin_unlock(&port->lock);
> +
> +       return IRQ_HANDLED;
> +}
> +
> +static unsigned int stm32_tx_empty(struct uart_port *port)
> +{
> +       return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
> +}
> +
> +static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> +       if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
> +               stm32_set_bits(port, USART_CR3, USART_CR3_RTSE);
> +       else
> +               stm32_clr_bits(port, USART_CR3, USART_CR3_RTSE);
> +}
> +
> +static unsigned int stm32_get_mctrl(struct uart_port *port)
> +{
> +       /* This routine is used to get signals of: DCD, DSR, RI, and CTS */
> +       return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
> +}
> +
> +/* Transmit stop */
> +static void stm32_stop_tx(struct uart_port *port)
> +{
> +       stm32_clr_bits(port, USART_CR1, USART_CR1_TXEIE);
> +}
> +
> +/* There are probably characters waiting to be transmitted. */
> +static void stm32_start_tx(struct uart_port *port)
> +{
> +       struct circ_buf *xmit = &port->state->xmit;
> +
> +       if (uart_circ_empty(xmit))
> +               return;
> +
> +       stm32_set_bits(port, USART_CR1, USART_CR1_TXEIE | USART_CR1_TE);
> +}
> +
> +/* Throttle the remote when input buffer is about to overflow. */
> +static void stm32_throttle(struct uart_port *port)
> +{
> +       unsigned long flags;
> +
> +       spin_lock_irqsave(&port->lock, flags);
> +       stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +       spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +/* Unthrottle the remote, the input buffer can now accept data. */
> +static void stm32_unthrottle(struct uart_port *port)
> +{
> +       unsigned long flags;
> +
> +       spin_lock_irqsave(&port->lock, flags);
> +       stm32_set_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +       spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +/* Receive stop */
> +static void stm32_stop_rx(struct uart_port *port)
> +{
> +       stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +}
> +
> +/* Handle breaks - ignored by us */
> +static void stm32_break_ctl(struct uart_port *port, int break_state)
> +{
> +}
> +
> +static int stm32_startup(struct uart_port *port)
> +{
> +       const char *name = to_platform_device(port->dev)->name;
> +       u32 val;
> +       int ret;
> +
> +       ret = request_irq(port->irq, stm32_interrupt, IRQF_NO_SUSPEND,
> +                         name, port);
> +       if (ret)
> +               return ret;
> +
> +       val = USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
> +       stm32_set_bits(port, USART_CR1, val);
> +
> +       return 0;
> +}
> +
> +static void stm32_shutdown(struct uart_port *port)
> +{
> +       u32 val;
> +
> +       val = USART_CR1_TXEIE | USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
> +       stm32_set_bits(port, USART_CR1, val);
> +
> +       free_irq(port->irq, port);
> +}
> +
> +static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
> +                           struct ktermios *old)
> +{
> +       struct stm32_port *stm32_port = to_stm32_port(port);
> +       unsigned int baud;
> +       u32 usartdiv, mantissa, fraction, oversampling;
> +       tcflag_t cflag = termios->c_cflag;
> +       u32 cr1, cr2, cr3;
> +       unsigned long flags;
> +
> +       if (!stm32_port->hw_flow_control)
> +               cflag &= ~CRTSCTS;
> +
> +       baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 8);
> +
> +       spin_lock_irqsave(&port->lock, flags);
> +
> +       /* Stop serial port and reset value */
> +       writel_relaxed(0, port->membase + USART_CR1);
> +
> +       cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
> +       cr2 = 0;
> +       cr3 = 0;
> +
> +       if (cflag & CSTOPB)
> +               cr2 |= USART_CR2_STOP_2B;
> +
> +       if (cflag & PARENB) {
> +               cr1 |= USART_CR1_PCE;
> +               if ((cflag & CSIZE) == CS8)
> +                       cr1 |= USART_CR1_M;
> +       }
> +
> +       if (cflag & PARODD)
> +               cr1 |= USART_CR1_PS;
> +
> +       port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS);
> +       if (cflag & CRTSCTS) {
> +               port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
> +               cr3 |= USART_CR3_CTSE;
> +       }
> +
> +       usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
> +
> +       /*
> +        * The USART supports 16 or 8 times oversampling.
> +        * By default we prefer 16 times oversampling, so that the receiver
> +        * has a better tolerance to clock deviations.
> +        * 8 times oversampling is only used to achieve higher speeds.
> +        */
> +       if (usartdiv < 16) {
> +               oversampling = 8;
> +               stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
> +       } else {
> +               oversampling = 16;
> +               stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
> +       }
> +
> +       mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
> +       fraction = usartdiv % oversampling;
> +       writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
> +
> +       uart_update_timeout(port, cflag, baud);
> +
> +       port->read_status_mask = USART_SR_ORE;
> +       if (termios->c_iflag & INPCK)
> +               port->read_status_mask |= USART_SR_PE | USART_SR_FE;
> +       if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
> +               port->read_status_mask |= USART_SR_LBD;
> +
> +       /* Characters to ignore */
> +       port->ignore_status_mask = 0;
> +       if (termios->c_iflag & IGNPAR)
> +               port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
> +       if (termios->c_iflag & IGNBRK) {
> +               port->ignore_status_mask |= USART_SR_LBD;
> +               /*
> +                * If we're ignoring parity and break indicators,
> +                * ignore overruns too (for real raw support).
> +                */
> +               if (termios->c_iflag & IGNPAR)
> +                       port->ignore_status_mask |= USART_SR_ORE;
> +       }
> +
> +       /* Ignore all characters if CREAD is not set */
> +       if ((termios->c_cflag & CREAD) == 0)
> +               port->ignore_status_mask |= USART_SR_DUMMY_RX;
> +
> +       writel_relaxed(cr3, port->membase + USART_CR3);
> +       writel_relaxed(cr2, port->membase + USART_CR2);
> +       writel_relaxed(cr1, port->membase + USART_CR1);
> +
> +       spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static const char *stm32_type(struct uart_port *port)
> +{
> +       return (port->type == PORT_STM32) ? DRIVER_NAME : NULL;
> +}
> +
> +static void stm32_release_port(struct uart_port *port)
> +{
> +}
> +
> +static int stm32_request_port(struct uart_port *port)
> +{
> +       return 0;
> +}
> +
> +static void stm32_config_port(struct uart_port *port, int flags)
> +{
> +       if (flags & UART_CONFIG_TYPE)
> +               port->type = PORT_STM32;
> +}
> +
> +static int
> +stm32_verify_port(struct uart_port *port, struct serial_struct *ser)
> +{
> +       /* No user changeable parameters */
> +       return -EINVAL;
> +}
> +
> +static void stm32_pm(struct uart_port *port, unsigned int state,
> +               unsigned int oldstate)
> +{
> +       struct stm32_port *stm32port = container_of(port,
> +                       struct stm32_port, port);
> +       unsigned long flags = 0;
> +
> +       switch (state) {
> +       case UART_PM_STATE_ON:
> +               clk_prepare_enable(stm32port->clk);
> +               break;
> +       case UART_PM_STATE_OFF:
> +               spin_lock_irqsave(&port->lock, flags);
> +               stm32_clr_bits(port, USART_CR1, USART_CR1_UE);
> +               spin_unlock_irqrestore(&port->lock, flags);
> +               clk_disable_unprepare(stm32port->clk);
> +               break;
> +       }
> +}
> +
> +static const struct uart_ops stm32_uart_ops = {
> +       .tx_empty       = stm32_tx_empty,
> +       .set_mctrl      = stm32_set_mctrl,
> +       .get_mctrl      = stm32_get_mctrl,
> +       .stop_tx        = stm32_stop_tx,
> +       .start_tx       = stm32_start_tx,
> +       .throttle       = stm32_throttle,
> +       .unthrottle     = stm32_unthrottle,
> +       .stop_rx        = stm32_stop_rx,
> +       .break_ctl      = stm32_break_ctl,
> +       .startup        = stm32_startup,
> +       .shutdown       = stm32_shutdown,
> +       .set_termios    = stm32_set_termios,
> +       .pm             = stm32_pm,
> +       .type           = stm32_type,
> +       .release_port   = stm32_release_port,
> +       .request_port   = stm32_request_port,
> +       .config_port    = stm32_config_port,
> +       .verify_port    = stm32_verify_port,
> +};
> +
> +static int stm32_init_port(struct stm32_port *stm32port,
> +                         struct platform_device *pdev)
> +{
> +       struct uart_port *port = &stm32port->port;
> +       struct resource *res;
> +       int ret;
> +
> +       port->iotype    = UPIO_MEM;
> +       port->flags     = UPF_BOOT_AUTOCONF;
> +       port->ops       = &stm32_uart_ops;
> +       port->dev       = &pdev->dev;
> +       port->irq       = platform_get_irq(pdev, 0);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       port->membase = devm_ioremap_resource(&pdev->dev, res);
> +       if (IS_ERR(port->membase))
> +               return PTR_ERR(port->membase);
> +       port->mapbase = res->start;
> +
> +       spin_lock_init(&port->lock);
> +
> +       stm32port->clk = devm_clk_get(&pdev->dev, NULL);
> +       if (IS_ERR(stm32port->clk))
> +               return PTR_ERR(stm32port->clk);
> +
> +       /* Ensure that clk rate is correct by enabling the clk */
> +       ret = clk_prepare_enable(stm32port->clk);
> +       if (ret)
> +               return ret;
> +
> +       stm32port->port.uartclk = clk_get_rate(stm32port->clk);
> +       if (!stm32port->port.uartclk)
> +               ret = -EINVAL;
> +
> +       clk_disable_unprepare(stm32port->clk);
> +
> +       return ret;
> +}
> +
> +static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
> +{
> +       struct device_node *np = pdev->dev.of_node;
> +       int id;
> +
> +       if (!np)
> +               return NULL;
> +
> +       id = of_alias_get_id(np, "serial");
> +       if (id < 0)
> +               id = 0;
> +
> +       if (WARN_ON(id >= STM32_MAX_PORTS))
> +               return NULL;
> +
> +       stm32_ports[id].hw_flow_control = of_property_read_bool(np,
> +                                                       "auto-flow-control");
> +       stm32_ports[id].port.line = id;
> +       return &stm32_ports[id];
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id stm32_match[] = {
> +       { .compatible = "st,stm32-usart", },
> +       { .compatible = "st,stm32-uart", },
> +       {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, stm32_match);
> +#endif
> +
> +static int stm32_serial_probe(struct platform_device *pdev)
> +{
> +       int ret;
> +       struct stm32_port *stm32port;
> +
> +       stm32port = stm32_of_get_stm32_port(pdev);
> +       if (!stm32port)
> +               return -ENODEV;
> +
> +       ret = stm32_init_port(stm32port, pdev);
> +       if (ret)
> +               return ret;
> +
> +       ret = uart_add_one_port(&stm32_usart_driver, &stm32port->port);
> +       if (ret)
> +               return ret;
> +
> +       platform_set_drvdata(pdev, &stm32port->port);
> +
> +       return 0;
> +}
> +
> +static int stm32_serial_remove(struct platform_device *pdev)
> +{
> +       struct uart_port *port = platform_get_drvdata(pdev);
> +
> +       return uart_remove_one_port(&stm32_usart_driver, port);
> +}
> +
> +
> +#ifdef CONFIG_SERIAL_STM32_CONSOLE
> +static void stm32_console_putchar(struct uart_port *port, int ch)
> +{
> +       while (!(readl_relaxed(port->membase + USART_SR) & USART_SR_TXE))
> +               cpu_relax();
> +
> +       writel_relaxed(ch, port->membase + USART_DR);
> +}
> +
> +static void stm32_console_write(struct console *co, const char *s, unsigned cnt)
> +{
> +       struct uart_port *port = &stm32_ports[co->index].port;
> +       unsigned long flags;
> +       u32 old_cr1, new_cr1;
> +       int locked = 1;
> +
> +       local_irq_save(flags);
> +       if (port->sysrq)
> +               locked = 0;
> +       else if (oops_in_progress)
> +               locked = spin_trylock(&port->lock);
> +       else
> +               spin_lock(&port->lock);
> +
> +       /* Save and disable interrupts */
> +       old_cr1 = readl_relaxed(port->membase + USART_CR1);
> +       new_cr1 = old_cr1 & ~USART_CR1_IE_MASK;
> +       writel_relaxed(new_cr1, port->membase + USART_CR1);
> +
> +       uart_console_write(port, s, cnt, stm32_console_putchar);
> +
> +       /* Restore interrupt state */
> +       writel_relaxed(old_cr1, port->membase + USART_CR1);
> +
> +       if (locked)
> +               spin_unlock(&port->lock);
> +       local_irq_restore(flags);
> +}
> +
> +static int stm32_console_setup(struct console *co, char *options)
> +{
> +       struct stm32_port *stm32port;
> +       int baud = 9600;
> +       int bits = 8;
> +       int parity = 'n';
> +       int flow = 'n';
> +
> +       if (co->index >= STM32_MAX_PORTS)
> +               return -ENODEV;
> +
> +       stm32port = &stm32_ports[co->index];
> +
> +       /*
> +        * This driver does not support early console initialization
> +        * (use ARM early printk support instead), so we only expect
> +        * this to be called during the uart port registration when the
> +        * driver gets probed and the port should be mapped at that point.
> +        */
> +       if (stm32port->port.mapbase == 0 || stm32port->port.membase == NULL)
> +               return -ENXIO;
> +
> +       if (options)
> +               uart_parse_options(options, &baud, &parity, &bits, &flow);
> +
> +       return uart_set_options(&stm32port->port, co, baud, parity, bits, flow);
> +}
> +
> +static struct console stm32_console = {
> +       .name           = STM32_SERIAL_NAME,
> +       .device         = uart_console_device,
> +       .write          = stm32_console_write,
> +       .setup          = stm32_console_setup,
> +       .flags          = CON_PRINTBUFFER,
> +       .index          = -1,
> +       .data           = &stm32_usart_driver,
> +};
> +
> +#define STM32_SERIAL_CONSOLE (&stm32_console)
> +
> +#else
> +#define STM32_SERIAL_CONSOLE NULL
> +#endif /* CONFIG_SERIAL_STM32_CONSOLE */
> +
> +static struct uart_driver stm32_usart_driver = {
> +       .driver_name    = DRIVER_NAME,
> +       .dev_name       = STM32_SERIAL_NAME,
> +       .major          = 0,
> +       .minor          = 0,
> +       .nr             = STM32_MAX_PORTS,
> +       .cons           = STM32_SERIAL_CONSOLE,
> +};
> +
> +static struct platform_driver stm32_serial_driver = {
> +       .probe          = stm32_serial_probe,
> +       .remove         = stm32_serial_remove,
> +       .driver = {
> +               .name   = DRIVER_NAME,
> +               .of_match_table = of_match_ptr(stm32_match),
> +       },
> +};
> +
> +static int __init usart_init(void)
> +{
> +       static char banner[] __initdata = "STM32 USART driver initialized";
> +       int ret;
> +
> +       pr_info("%s\n", banner);
> +
> +       ret = uart_register_driver(&stm32_usart_driver);
> +       if (ret)
> +               return ret;
> +
> +       ret = platform_driver_register(&stm32_serial_driver);
> +       if (ret)
> +               uart_unregister_driver(&stm32_usart_driver);
> +
> +       return ret;
> +}
> +
> +static void __exit usart_exit(void)
> +{
> +       platform_driver_unregister(&stm32_serial_driver);
> +       uart_unregister_driver(&stm32_usart_driver);
> +}
> +
> +module_init(usart_init);
> +module_exit(usart_exit);
> +
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> +MODULE_DESCRIPTION("STMicroelectronics STM32 serial port driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index b212281..93ba148 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -258,4 +258,7 @@
>  /* Cris v10 / v32 SoC */
>  #define PORT_CRIS      112
>
> +/* STM32 USART */
> +#define PORT_STM32     113
> +
>  #endif /* _UAPILINUX_SERIAL_CORE_H */
> --
> 1.9.1
>



-- 
With Best Regards,
Andy Shevchenko

[PATCH v8 11/16] serial: stm32-usart: Add STM32 USART Driver

[Andy Shevchenko]

On Sat, May 9, 2015 at 10:53 AM, Maxime Coquelin
<mcoquelin.stm32@gmail.com> wrote:
> This drivers adds support to the STM32 USART controller, which is a
> standard serial driver.
>

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/tty/serial/Kconfig       |  17 +
>  drivers/tty/serial/Makefile      |   1 +
>  drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/serial_core.h |   3 +
>  4 files changed, 760 insertions(+)
>  create mode 100644 drivers/tty/serial/stm32-usart.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index f8120c1..7eb62f1 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1589,6 +1589,23 @@ config SERIAL_SPRD_CONSOLE
>           with "earlycon" on the kernel command line. The console is
>           enabled when early_param is processed.
>
> +config SERIAL_STM32
> +       tristate "STMicroelectronics STM32 serial port support"
> +       select SERIAL_CORE
> +       depends on ARM || COMPILE_TEST
> +       help
> +         This driver is for the on-chip Serial Controller on
> +         STMicroelectronics STM32 MCUs.
> +         USART supports Rx & Tx functionality.
> +         It support all industry standard baud rates.
> +
> +         If unsure, say N.
> +
> +config SERIAL_STM32_CONSOLE
> +       bool "Support for console on STM32"
> +       depends on SERIAL_STM32=y
> +       select SERIAL_CORE_CONSOLE
> +
>  endmenu
>
>  config SERIAL_MCTRL_GPIO
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index c3ac3d9..61979ce 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART)       += fsl_lpuart.o
>  obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)        += digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)  += men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
> +obj-$(CONFIG_SERIAL_STM32)     += stm32-usart.o
>
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)        += serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> new file mode 100644
> index 0000000..4a6eab6
> --- /dev/null
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -0,0 +1,739 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author:  Maxime Coquelin <mcoquelin.stm32@gmail.com>
> + * License terms:  GNU General Public License (GPL), version 2
> + *
> + * Inspired by st-asc.c from STMicroelectronics (c)
> + */
> +
> +#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> +#define SUPPORT_SYSRQ
> +#endif
> +
> +#include <linux/module.h>
> +#include <linux/serial.h>
> +#include <linux/console.h>
> +#include <linux/sysrq.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/irq.h>
> +#include <linux/tty.h>
> +#include <linux/tty_flip.h>
> +#include <linux/delay.h>
> +#include <linux/spinlock.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/serial_core.h>
> +#include <linux/clk.h>
> +
> +#define DRIVER_NAME "stm32-usart"
> +
> +/* Register offsets */
> +#define USART_SR               0x00
> +#define USART_DR               0x04
> +#define USART_BRR              0x08
> +#define USART_CR1              0x0c
> +#define USART_CR2              0x10
> +#define USART_CR3              0x14
> +#define USART_GTPR             0x18
> +
> +/* USART_SR */
> +#define USART_SR_PE            BIT(0)
> +#define USART_SR_FE            BIT(1)
> +#define USART_SR_NF            BIT(2)
> +#define USART_SR_ORE           BIT(3)
> +#define USART_SR_IDLE          BIT(4)
> +#define USART_SR_RXNE          BIT(5)
> +#define USART_SR_TC            BIT(6)
> +#define USART_SR_TXE           BIT(7)
> +#define USART_SR_LBD           BIT(8)
> +#define USART_SR_CTS           BIT(9)
> +#define USART_SR_ERR_MASK      (USART_SR_LBD | USART_SR_ORE | \
> +                                USART_SR_FE | USART_SR_PE)
> +/* Dummy bits */
> +#define USART_SR_DUMMY_RX      BIT(16)
> +
> +/* USART_DR */
> +#define USART_DR_MASK          GENMASK(8, 0)
> +
> +/* USART_BRR */
> +#define USART_BRR_DIV_F_MASK   GENMASK(3, 0)
> +#define USART_BRR_DIV_M_MASK   GENMASK(15, 4)
> +#define USART_BRR_DIV_M_SHIFT  4
> +
> +/* USART_CR1 */
> +#define USART_CR1_SBK          BIT(0)
> +#define USART_CR1_RWU          BIT(1)
> +#define USART_CR1_RE           BIT(2)
> +#define USART_CR1_TE           BIT(3)
> +#define USART_CR1_IDLEIE       BIT(4)
> +#define USART_CR1_RXNEIE       BIT(5)
> +#define USART_CR1_TCIE         BIT(6)
> +#define USART_CR1_TXEIE                BIT(7)
> +#define USART_CR1_PEIE         BIT(8)
> +#define USART_CR1_PS           BIT(9)
> +#define USART_CR1_PCE          BIT(10)
> +#define USART_CR1_WAKE         BIT(11)
> +#define USART_CR1_M            BIT(12)
> +#define USART_CR1_UE           BIT(13)
> +#define USART_CR1_OVER8                BIT(15)
> +#define USART_CR1_IE_MASK      GENMASK(8, 4)
> +
> +/* USART_CR2 */
> +#define USART_CR2_ADD_MASK     GENMASK(3, 0)
> +#define USART_CR2_LBDL         BIT(5)
> +#define USART_CR2_LBDIE                BIT(6)
> +#define USART_CR2_LBCL         BIT(8)
> +#define USART_CR2_CPHA         BIT(9)
> +#define USART_CR2_CPOL         BIT(10)
> +#define USART_CR2_CLKEN                BIT(11)
> +#define USART_CR2_STOP_2B      BIT(13)
> +#define USART_CR2_STOP_MASK    GENMASK(13, 12)
> +#define USART_CR2_LINEN                BIT(14)
> +
> +/* USART_CR3 */
> +#define USART_CR3_EIE          BIT(0)
> +#define USART_CR3_IREN         BIT(1)
> +#define USART_CR3_IRLP         BIT(2)
> +#define USART_CR3_HDSEL                BIT(3)
> +#define USART_CR3_NACK         BIT(4)
> +#define USART_CR3_SCEN         BIT(5)
> +#define USART_CR3_DMAR         BIT(6)
> +#define USART_CR3_DMAT         BIT(7)
> +#define USART_CR3_RTSE         BIT(8)
> +#define USART_CR3_CTSE         BIT(9)
> +#define USART_CR3_CTSIE                BIT(10)
> +#define USART_CR3_ONEBIT       BIT(11)
> +
> +/* USART_GTPR */
> +#define USART_GTPR_PSC_MASK    GENMASK(7, 0)
> +#define USART_GTPR_GT_MASK     GENMASK(15, 8)
> +
> +#define DRIVER_NAME "stm32-usart"
> +#define STM32_SERIAL_NAME "ttyS"
> +#define STM32_MAX_PORTS 6
> +
> +struct stm32_port {
> +       struct uart_port port;
> +       struct clk *clk;
> +       bool hw_flow_control;
> +};
> +
> +static struct stm32_port stm32_ports[STM32_MAX_PORTS];
> +static struct uart_driver stm32_usart_driver;
> +
> +static void stm32_stop_tx(struct uart_port *port);
> +
> +static inline struct stm32_port *to_stm32_port(struct uart_port *port)
> +{
> +       return container_of(port, struct stm32_port, port);
> +}
> +
> +static void stm32_set_bits(struct uart_port *port, u32 reg, u32 bits)
> +{
> +       u32 val;
> +
> +       val = readl_relaxed(port->membase + reg);
> +       val |= bits;
> +       writel_relaxed(val, port->membase + reg);
> +}
> +
> +static void stm32_clr_bits(struct uart_port *port, u32 reg, u32 bits)
> +{
> +       u32 val;
> +
> +       val = readl_relaxed(port->membase + reg);
> +       val &= ~bits;
> +       writel_relaxed(val, port->membase + reg);
> +}
> +
> +static void stm32_receive_chars(struct uart_port *port)
> +{
> +       struct tty_port *tport = &port->state->port;
> +       unsigned long c;
> +       u32 sr;
> +       char flag;
> +
> +       if (port->irq_wake)
> +               pm_wakeup_event(tport->tty->dev, 0);
> +
> +       while ((sr = readl_relaxed(port->membase + USART_SR)) & USART_SR_RXNE) {
> +               sr |= USART_SR_DUMMY_RX;
> +               c = readl_relaxed(port->membase + USART_DR);
> +               flag = TTY_NORMAL;
> +               port->icount.rx++;
> +
> +               if (sr & USART_SR_ERR_MASK) {
> +                       if (sr & USART_SR_LBD) {
> +                               port->icount.brk++;
> +                               if (uart_handle_break(port))
> +                                       continue;
> +                       } else if (sr & USART_SR_ORE) {
> +                               port->icount.overrun++;
> +                       } else if (sr & USART_SR_PE) {
> +                               port->icount.parity++;
> +                       } else if (sr & USART_SR_FE) {
> +                               port->icount.frame++;
> +                       }
> +
> +                       sr &= port->read_status_mask;
> +
> +                       if (sr & USART_SR_LBD)
> +                               flag = TTY_BREAK;
> +                       else if (sr & USART_SR_PE)
> +                               flag = TTY_PARITY;
> +                       else if (sr & USART_SR_FE)
> +                               flag = TTY_FRAME;
> +               }
> +
> +               if (uart_handle_sysrq_char(port, c))
> +                       continue;
> +               uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> +       }
> +
> +       spin_unlock(&port->lock);
> +       tty_flip_buffer_push(tport);
> +       spin_lock(&port->lock);
> +}
> +
> +static void stm32_transmit_chars(struct uart_port *port)
> +{
> +       struct circ_buf *xmit = &port->state->xmit;
> +
> +       if (port->x_char) {
> +               writel_relaxed(port->x_char, port->membase + USART_DR);
> +               port->x_char = 0;
> +               port->icount.tx++;
> +               return;
> +       }
> +
> +       if (uart_tx_stopped(port)) {
> +               stm32_stop_tx(port);
> +               return;
> +       }
> +
> +       if (uart_circ_empty(xmit)) {
> +               stm32_stop_tx(port);
> +               return;
> +       }
> +
> +       writel_relaxed(xmit->buf[xmit->tail], port->membase + USART_DR);
> +       xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> +       port->icount.tx++;
> +
> +       if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +               uart_write_wakeup(port);
> +
> +       if (uart_circ_empty(xmit))
> +               stm32_stop_tx(port);
> +}
> +
> +static irqreturn_t stm32_interrupt(int irq, void *ptr)
> +{
> +       struct uart_port *port = ptr;
> +       u32 sr;
> +
> +       spin_lock(&port->lock);
> +
> +       sr = readl_relaxed(port->membase + USART_SR);
> +
> +       if (sr & USART_SR_RXNE)
> +               stm32_receive_chars(port);
> +
> +       if (sr & USART_SR_TXE)
> +               stm32_transmit_chars(port);
> +
> +       spin_unlock(&port->lock);
> +
> +       return IRQ_HANDLED;
> +}
> +
> +static unsigned int stm32_tx_empty(struct uart_port *port)
> +{
> +       return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
> +}
> +
> +static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> +       if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
> +               stm32_set_bits(port, USART_CR3, USART_CR3_RTSE);
> +       else
> +               stm32_clr_bits(port, USART_CR3, USART_CR3_RTSE);
> +}
> +
> +static unsigned int stm32_get_mctrl(struct uart_port *port)
> +{
> +       /* This routine is used to get signals of: DCD, DSR, RI, and CTS */
> +       return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
> +}
> +
> +/* Transmit stop */
> +static void stm32_stop_tx(struct uart_port *port)
> +{
> +       stm32_clr_bits(port, USART_CR1, USART_CR1_TXEIE);
> +}
> +
> +/* There are probably characters waiting to be transmitted. */
> +static void stm32_start_tx(struct uart_port *port)
> +{
> +       struct circ_buf *xmit = &port->state->xmit;
> +
> +       if (uart_circ_empty(xmit))
> +               return;
> +
> +       stm32_set_bits(port, USART_CR1, USART_CR1_TXEIE | USART_CR1_TE);
> +}
> +
> +/* Throttle the remote when input buffer is about to overflow. */
> +static void stm32_throttle(struct uart_port *port)
> +{
> +       unsigned long flags;
> +
> +       spin_lock_irqsave(&port->lock, flags);
> +       stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +       spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +/* Unthrottle the remote, the input buffer can now accept data. */
> +static void stm32_unthrottle(struct uart_port *port)
> +{
> +       unsigned long flags;
> +
> +       spin_lock_irqsave(&port->lock, flags);
> +       stm32_set_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +       spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +/* Receive stop */
> +static void stm32_stop_rx(struct uart_port *port)
> +{
> +       stm32_clr_bits(port, USART_CR1, USART_CR1_RXNEIE);
> +}
> +
> +/* Handle breaks - ignored by us */
> +static void stm32_break_ctl(struct uart_port *port, int break_state)
> +{
> +}
> +
> +static int stm32_startup(struct uart_port *port)
> +{
> +       const char *name = to_platform_device(port->dev)->name;
> +       u32 val;
> +       int ret;
> +
> +       ret = request_irq(port->irq, stm32_interrupt, IRQF_NO_SUSPEND,
> +                         name, port);
> +       if (ret)
> +               return ret;
> +
> +       val = USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
> +       stm32_set_bits(port, USART_CR1, val);
> +
> +       return 0;
> +}
> +
> +static void stm32_shutdown(struct uart_port *port)
> +{
> +       u32 val;
> +
> +       val = USART_CR1_TXEIE | USART_CR1_RXNEIE | USART_CR1_TE | USART_CR1_RE;
> +       stm32_set_bits(port, USART_CR1, val);
> +
> +       free_irq(port->irq, port);
> +}
> +
> +static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
> +                           struct ktermios *old)
> +{
> +       struct stm32_port *stm32_port = to_stm32_port(port);
> +       unsigned int baud;
> +       u32 usartdiv, mantissa, fraction, oversampling;
> +       tcflag_t cflag = termios->c_cflag;
> +       u32 cr1, cr2, cr3;
> +       unsigned long flags;
> +
> +       if (!stm32_port->hw_flow_control)
> +               cflag &= ~CRTSCTS;
> +
> +       baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 8);
> +
> +       spin_lock_irqsave(&port->lock, flags);
> +
> +       /* Stop serial port and reset value */
> +       writel_relaxed(0, port->membase + USART_CR1);
> +
> +       cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
> +       cr2 = 0;
> +       cr3 = 0;
> +
> +       if (cflag & CSTOPB)
> +               cr2 |= USART_CR2_STOP_2B;
> +
> +       if (cflag & PARENB) {
> +               cr1 |= USART_CR1_PCE;
> +               if ((cflag & CSIZE) == CS8)
> +                       cr1 |= USART_CR1_M;
> +       }
> +
> +       if (cflag & PARODD)
> +               cr1 |= USART_CR1_PS;
> +
> +       port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS);
> +       if (cflag & CRTSCTS) {
> +               port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
> +               cr3 |= USART_CR3_CTSE;
> +       }
> +
> +       usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
> +
> +       /*
> +        * The USART supports 16 or 8 times oversampling.
> +        * By default we prefer 16 times oversampling, so that the receiver
> +        * has a better tolerance to clock deviations.
> +        * 8 times oversampling is only used to achieve higher speeds.
> +        */
> +       if (usartdiv < 16) {
> +               oversampling = 8;
> +               stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
> +       } else {
> +               oversampling = 16;
> +               stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
> +       }
> +
> +       mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
> +       fraction = usartdiv % oversampling;
> +       writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
> +
> +       uart_update_timeout(port, cflag, baud);
> +
> +       port->read_status_mask = USART_SR_ORE;
> +       if (termios->c_iflag & INPCK)
> +               port->read_status_mask |= USART_SR_PE | USART_SR_FE;
> +       if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
> +               port->read_status_mask |= USART_SR_LBD;
> +
> +       /* Characters to ignore */
> +       port->ignore_status_mask = 0;
> +       if (termios->c_iflag & IGNPAR)
> +               port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
> +       if (termios->c_iflag & IGNBRK) {
> +               port->ignore_status_mask |= USART_SR_LBD;
> +               /*
> +                * If we're ignoring parity and break indicators,
> +                * ignore overruns too (for real raw support).
> +                */
> +               if (termios->c_iflag & IGNPAR)
> +                       port->ignore_status_mask |= USART_SR_ORE;
> +       }
> +
> +       /* Ignore all characters if CREAD is not set */
> +       if ((termios->c_cflag & CREAD) == 0)
> +               port->ignore_status_mask |= USART_SR_DUMMY_RX;
> +
> +       writel_relaxed(cr3, port->membase + USART_CR3);
> +       writel_relaxed(cr2, port->membase + USART_CR2);
> +       writel_relaxed(cr1, port->membase + USART_CR1);
> +
> +       spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static const char *stm32_type(struct uart_port *port)
> +{
> +       return (port->type == PORT_STM32) ? DRIVER_NAME : NULL;
> +}
> +
> +static void stm32_release_port(struct uart_port *port)
> +{
> +}
> +
> +static int stm32_request_port(struct uart_port *port)
> +{
> +       return 0;
> +}
> +
> +static void stm32_config_port(struct uart_port *port, int flags)
> +{
> +       if (flags & UART_CONFIG_TYPE)
> +               port->type = PORT_STM32;
> +}
> +
> +static int
> +stm32_verify_port(struct uart_port *port, struct serial_struct *ser)
> +{
> +       /* No user changeable parameters */
> +       return -EINVAL;
> +}
> +
> +static void stm32_pm(struct uart_port *port, unsigned int state,
> +               unsigned int oldstate)
> +{
> +       struct stm32_port *stm32port = container_of(port,
> +                       struct stm32_port, port);
> +       unsigned long flags = 0;
> +
> +       switch (state) {
> +       case UART_PM_STATE_ON:
> +               clk_prepare_enable(stm32port->clk);
> +               break;
> +       case UART_PM_STATE_OFF:
> +               spin_lock_irqsave(&port->lock, flags);
> +               stm32_clr_bits(port, USART_CR1, USART_CR1_UE);
> +               spin_unlock_irqrestore(&port->lock, flags);
> +               clk_disable_unprepare(stm32port->clk);
> +               break;
> +       }
> +}
> +
> +static const struct uart_ops stm32_uart_ops = {
> +       .tx_empty       = stm32_tx_empty,
> +       .set_mctrl      = stm32_set_mctrl,
> +       .get_mctrl      = stm32_get_mctrl,
> +       .stop_tx        = stm32_stop_tx,
> +       .start_tx       = stm32_start_tx,
> +       .throttle       = stm32_throttle,
> +       .unthrottle     = stm32_unthrottle,
> +       .stop_rx        = stm32_stop_rx,
> +       .break_ctl      = stm32_break_ctl,
> +       .startup        = stm32_startup,
> +       .shutdown       = stm32_shutdown,
> +       .set_termios    = stm32_set_termios,
> +       .pm             = stm32_pm,
> +       .type           = stm32_type,
> +       .release_port   = stm32_release_port,
> +       .request_port   = stm32_request_port,
> +       .config_port    = stm32_config_port,
> +       .verify_port    = stm32_verify_port,
> +};
> +
> +static int stm32_init_port(struct stm32_port *stm32port,
> +                         struct platform_device *pdev)
> +{
> +       struct uart_port *port = &stm32port->port;
> +       struct resource *res;
> +       int ret;
> +
> +       port->iotype    = UPIO_MEM;
> +       port->flags     = UPF_BOOT_AUTOCONF;
> +       port->ops       = &stm32_uart_ops;
> +       port->dev       = &pdev->dev;
> +       port->irq       = platform_get_irq(pdev, 0);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       port->membase = devm_ioremap_resource(&pdev->dev, res);
> +       if (IS_ERR(port->membase))
> +               return PTR_ERR(port->membase);
> +       port->mapbase = res->start;
> +
> +       spin_lock_init(&port->lock);
> +
> +       stm32port->clk = devm_clk_get(&pdev->dev, NULL);
> +       if (IS_ERR(stm32port->clk))
> +               return PTR_ERR(stm32port->clk);
> +
> +       /* Ensure that clk rate is correct by enabling the clk */
> +       ret = clk_prepare_enable(stm32port->clk);
> +       if (ret)
> +               return ret;
> +
> +       stm32port->port.uartclk = clk_get_rate(stm32port->clk);
> +       if (!stm32port->port.uartclk)
> +               ret = -EINVAL;
> +
> +       clk_disable_unprepare(stm32port->clk);
> +
> +       return ret;
> +}
> +
> +static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
> +{
> +       struct device_node *np = pdev->dev.of_node;
> +       int id;
> +
> +       if (!np)
> +               return NULL;
> +
> +       id = of_alias_get_id(np, "serial");
> +       if (id < 0)
> +               id = 0;
> +
> +       if (WARN_ON(id >= STM32_MAX_PORTS))
> +               return NULL;
> +
> +       stm32_ports[id].hw_flow_control = of_property_read_bool(np,
> +                                                       "auto-flow-control");
> +       stm32_ports[id].port.line = id;
> +       return &stm32_ports[id];
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id stm32_match[] = {
> +       { .compatible = "st,stm32-usart", },
> +       { .compatible = "st,stm32-uart", },
> +       {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, stm32_match);
> +#endif
> +
> +static int stm32_serial_probe(struct platform_device *pdev)
> +{
> +       int ret;
> +       struct stm32_port *stm32port;
> +
> +       stm32port = stm32_of_get_stm32_port(pdev);
> +       if (!stm32port)
> +               return -ENODEV;
> +
> +       ret = stm32_init_port(stm32port, pdev);
> +       if (ret)
> +               return ret;
> +
> +       ret = uart_add_one_port(&stm32_usart_driver, &stm32port->port);
> +       if (ret)
> +               return ret;
> +
> +       platform_set_drvdata(pdev, &stm32port->port);
> +
> +       return 0;
> +}
> +
> +static int stm32_serial_remove(struct platform_device *pdev)
> +{
> +       struct uart_port *port = platform_get_drvdata(pdev);
> +
> +       return uart_remove_one_port(&stm32_usart_driver, port);
> +}
> +
> +
> +#ifdef CONFIG_SERIAL_STM32_CONSOLE
> +static void stm32_console_putchar(struct uart_port *port, int ch)
> +{
> +       while (!(readl_relaxed(port->membase + USART_SR) & USART_SR_TXE))
> +               cpu_relax();
> +
> +       writel_relaxed(ch, port->membase + USART_DR);
> +}
> +
> +static void stm32_console_write(struct console *co, const char *s, unsigned cnt)
> +{
> +       struct uart_port *port = &stm32_ports[co->index].port;
> +       unsigned long flags;
> +       u32 old_cr1, new_cr1;
> +       int locked = 1;
> +
> +       local_irq_save(flags);
> +       if (port->sysrq)
> +               locked = 0;
> +       else if (oops_in_progress)
> +               locked = spin_trylock(&port->lock);
> +       else
> +               spin_lock(&port->lock);
> +
> +       /* Save and disable interrupts */
> +       old_cr1 = readl_relaxed(port->membase + USART_CR1);
> +       new_cr1 = old_cr1 & ~USART_CR1_IE_MASK;
> +       writel_relaxed(new_cr1, port->membase + USART_CR1);
> +
> +       uart_console_write(port, s, cnt, stm32_console_putchar);
> +
> +       /* Restore interrupt state */
> +       writel_relaxed(old_cr1, port->membase + USART_CR1);
> +
> +       if (locked)
> +               spin_unlock(&port->lock);
> +       local_irq_restore(flags);
> +}
> +
> +static int stm32_console_setup(struct console *co, char *options)
> +{
> +       struct stm32_port *stm32port;
> +       int baud = 9600;
> +       int bits = 8;
> +       int parity = 'n';
> +       int flow = 'n';
> +
> +       if (co->index >= STM32_MAX_PORTS)
> +               return -ENODEV;
> +
> +       stm32port = &stm32_ports[co->index];
> +
> +       /*
> +        * This driver does not support early console initialization
> +        * (use ARM early printk support instead), so we only expect
> +        * this to be called during the uart port registration when the
> +        * driver gets probed and the port should be mapped at that point.
> +        */
> +       if (stm32port->port.mapbase == 0 || stm32port->port.membase == NULL)
> +               return -ENXIO;
> +
> +       if (options)
> +               uart_parse_options(options, &baud, &parity, &bits, &flow);
> +
> +       return uart_set_options(&stm32port->port, co, baud, parity, bits, flow);
> +}
> +
> +static struct console stm32_console = {
> +       .name           = STM32_SERIAL_NAME,
> +       .device         = uart_console_device,
> +       .write          = stm32_console_write,
> +       .setup          = stm32_console_setup,
> +       .flags          = CON_PRINTBUFFER,
> +       .index          = -1,
> +       .data           = &stm32_usart_driver,
> +};
> +
> +#define STM32_SERIAL_CONSOLE (&stm32_console)
> +
> +#else
> +#define STM32_SERIAL_CONSOLE NULL
> +#endif /* CONFIG_SERIAL_STM32_CONSOLE */
> +
> +static struct uart_driver stm32_usart_driver = {
> +       .driver_name    = DRIVER_NAME,
> +       .dev_name       = STM32_SERIAL_NAME,
> +       .major          = 0,
> +       .minor          = 0,
> +       .nr             = STM32_MAX_PORTS,
> +       .cons           = STM32_SERIAL_CONSOLE,
> +};
> +
> +static struct platform_driver stm32_serial_driver = {
> +       .probe          = stm32_serial_probe,
> +       .remove         = stm32_serial_remove,
> +       .driver = {
> +               .name   = DRIVER_NAME,
> +               .of_match_table = of_match_ptr(stm32_match),
> +       },
> +};
> +
> +static int __init usart_init(void)
> +{
> +       static char banner[] __initdata = "STM32 USART driver initialized";
> +       int ret;
> +
> +       pr_info("%s\n", banner);
> +
> +       ret = uart_register_driver(&stm32_usart_driver);
> +       if (ret)
> +               return ret;
> +
> +       ret = platform_driver_register(&stm32_serial_driver);
> +       if (ret)
> +               uart_unregister_driver(&stm32_usart_driver);
> +
> +       return ret;
> +}
> +
> +static void __exit usart_exit(void)
> +{
> +       platform_driver_unregister(&stm32_serial_driver);
> +       uart_unregister_driver(&stm32_usart_driver);
> +}
> +
> +module_init(usart_init);
> +module_exit(usart_exit);
> +
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> +MODULE_DESCRIPTION("STMicroelectronics STM32 serial port driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index b212281..93ba148 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -258,4 +258,7 @@
>  /* Cris v10 / v32 SoC */
>  #define PORT_CRIS      112
>
> +/* STM32 USART */
> +#define PORT_STM32     113
> +
>  #endif /* _UAPILINUX_SERIAL_CORE_H */
> --
> 1.9.1
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
> +
> 

Can you find a way to avoid this dependency?

Maybe you can change the bindings so that the numbers you pass as
arguments to the reset and clock specifiers reflect the numbers that
the hardware use?

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
> +
> 

Can you find a way to avoid this dependency?

Maybe you can change the bindings so that the numbers you pass as
arguments to the reset and clock specifiers reflect the numbers that
the hardware use?

	Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
> +
> 

Can you find a way to avoid this dependency?

Maybe you can change the bindings so that the numbers you pass as
arguments to the reset and clock specifiers reflect the numbers that
the hardware use?

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
>> +
>>
>
> Can you find a way to avoid this dependency?
>
> Maybe you can change the bindings so that the numbers you pass as
> arguments to the reset and clock specifiers reflect the numbers that
> the hardware use?

If I understand correctly, you prefer the way I did in v7 [0]?

I don't have a strong opinion on this. Either way is fine to me.

I changed the bindings in the v8 after discussions with Daniel
Thompson, who is implementing the clock driver part of the RCC IP.

He proposed we used common defines, because each peripheral has a
reset line and a clock gate.
Both reset and clock are represented as a single bit, with only the
base offset differing between clock and reset.
You can have a look at chapter 6 of the reference manual [1] if you
find some time.

Having common defines between clocks and reset make sense to me, but I
also understand your point of avoiding dependencies.

Maybe I can revert back to v7 bindings for now, and then we can
reconsider using common defines when Daniel will send the clock
patches.
Note that doing that won't break the DT binary compatibility, as the
raw reset values, or the ones from defines are the same.

Daniel, could you share an example of the bindings you would use for the clocks?

Kind regards,
Maxime

>
>         Arnd

[0]: http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04523.html
[1]: http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
>> +
>>
>
> Can you find a way to avoid this dependency?
>
> Maybe you can change the bindings so that the numbers you pass as
> arguments to the reset and clock specifiers reflect the numbers that
> the hardware use?

If I understand correctly, you prefer the way I did in v7 [0]?

I don't have a strong opinion on this. Either way is fine to me.

I changed the bindings in the v8 after discussions with Daniel
Thompson, who is implementing the clock driver part of the RCC IP.

He proposed we used common defines, because each peripheral has a
reset line and a clock gate.
Both reset and clock are represented as a single bit, with only the
base offset differing between clock and reset.
You can have a look at chapter 6 of the reference manual [1] if you
find some time.

Having common defines between clocks and reset make sense to me, but I
also understand your point of avoiding dependencies.

Maybe I can revert back to v7 bindings for now, and then we can
reconsider using common defines when Daniel will send the clock
patches.
Note that doing that won't break the DT binary compatibility, as the
raw reset values, or the ones from defines are the same.

Daniel, could you share an example of the bindings you would use for the clocks?

Kind regards,
Maxime

>
>         Arnd

[0]: http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04523.html
[1]: http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
>> +
>>
>
> Can you find a way to avoid this dependency?
>
> Maybe you can change the bindings so that the numbers you pass as
> arguments to the reset and clock specifiers reflect the numbers that
> the hardware use?

If I understand correctly, you prefer the way I did in v7 [0]?

I don't have a strong opinion on this. Either way is fine to me.

I changed the bindings in the v8 after discussions with Daniel
Thompson, who is implementing the clock driver part of the RCC IP.

He proposed we used common defines, because each peripheral has a
reset line and a clock gate.
Both reset and clock are represented as a single bit, with only the
base offset differing between clock and reset.
You can have a look at chapter 6 of the reference manual [1] if you
find some time.

Having common defines between clocks and reset make sense to me, but I
also understand your point of avoiding dependencies.

Maybe I can revert back to v7 bindings for now, and then we can
reconsider using common defines when Daniel will send the clock
patches.
Note that doing that won't break the DT binary compatibility, as the
raw reset values, or the ones from defines are the same.

Daniel, could you share an example of the bindings you would use for the clocks?

Kind regards,
Maxime

>
>         Arnd

[0]: http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04523.html
[1]: http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 13/05/15 12:45, Maxime Coquelin wrote:
> 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
>>> +
>>>
>>
>> Can you find a way to avoid this dependency?
>>
>> Maybe you can change the bindings so that the numbers you pass as
>> arguments to the reset and clock specifiers reflect the numbers that
>> the hardware use?
>
> If I understand correctly, you prefer the way I did in v7 [0]?
>
> I don't have a strong opinion on this. Either way is fine to me.
>
> I changed the bindings in the v8 after discussions with Daniel
> Thompson, who is implementing the clock driver part of the RCC IP.
>
> He proposed we used common defines, because each peripheral has a
> reset line and a clock gate.
> Both reset and clock are represented as a single bit, with only the
> base offset differing between clock and reset.
> You can have a look at chapter 6 of the reference manual [1] if you
> find some time.
>
> Having common defines between clocks and reset make sense to me, but I
> also understand your point of avoiding dependencies.
>
> Maybe I can revert back to v7 bindings for now, and then we can
> reconsider using common defines when Daniel will send the clock
> patches.
> Note that doing that won't break the DT binary compatibility, as the
> raw reset values, or the ones from defines are the same.
>
> Daniel, could you share an example of the bindings you would use for the clocks?

For the most cases, where there is a clock gate just before the 
peripheral it looks pretty much like the reset driver and I use the bit 
offset of the clock gating bit as the index.

However there are a couple of clocks without gating just before the 
clock reaches the peripheral:

1. A hard coded /8. I think this will have to be given a synthetic
    number.

2. Ungated dividers. For these I am using the bit offset of the LSB of
    the mux field.

So I think there is only one value that is completely unrelated to the 
hardware and will use a magic constant instead.

I had planned to macros similar to the STM32F4_AxB_RESET() family of 
macros in both clk driver and DT in order to reuse the bit layouts from 
dt-bindings/mfd/stm32f4-rcc.h .

Normal case would have looked like this:

		timer3: timer@40000000 {
			compatible = "st,stm32-timer";
			reg = <0x40000000 0x400>;
			interrupts = <28>;
			resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
			clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
			status = "disabled";
		};

Without the macros it looks like this:

		timer3: timer@40000000 {
			compatible = "st,stm32-timer";
			reg = <0x40000000 0x400>;
			interrupts = <28>;
			resets = <&rcc 257>;
			clocks = <&rcc 513>;
			status = "disabled";
		};

However we could perhaps be more literate even if we don't use the macros?

		timer3: timer@40000000 {
			compatible = "st,stm32-timer";
			reg = <0x40000000 0x400>;
			interrupts = <28>;
			resets = <&rcc ((0x20*8) + 1)>;
			clocks = <&rcc ((0x40*8) + 1)>;
			status = "disabled";
		};


Daniel.


> Kind regards,
> Maxime
>
>>
>>          Arnd
>
> [0]: http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04523.html
> [1]: http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 13/05/15 12:45, Maxime Coquelin wrote:
> 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
>>> +
>>>
>>
>> Can you find a way to avoid this dependency?
>>
>> Maybe you can change the bindings so that the numbers you pass as
>> arguments to the reset and clock specifiers reflect the numbers that
>> the hardware use?
>
> If I understand correctly, you prefer the way I did in v7 [0]?
>
> I don't have a strong opinion on this. Either way is fine to me.
>
> I changed the bindings in the v8 after discussions with Daniel
> Thompson, who is implementing the clock driver part of the RCC IP.
>
> He proposed we used common defines, because each peripheral has a
> reset line and a clock gate.
> Both reset and clock are represented as a single bit, with only the
> base offset differing between clock and reset.
> You can have a look at chapter 6 of the reference manual [1] if you
> find some time.
>
> Having common defines between clocks and reset make sense to me, but I
> also understand your point of avoiding dependencies.
>
> Maybe I can revert back to v7 bindings for now, and then we can
> reconsider using common defines when Daniel will send the clock
> patches.
> Note that doing that won't break the DT binary compatibility, as the
> raw reset values, or the ones from defines are the same.
>
> Daniel, could you share an example of the bindings you would use for the clocks?

For the most cases, where there is a clock gate just before the 
peripheral it looks pretty much like the reset driver and I use the bit 
offset of the clock gating bit as the index.

However there are a couple of clocks without gating just before the 
clock reaches the peripheral:

1. A hard coded /8. I think this will have to be given a synthetic
    number.

2. Ungated dividers. For these I am using the bit offset of the LSB of
    the mux field.

So I think there is only one value that is completely unrelated to the 
hardware and will use a magic constant instead.

I had planned to macros similar to the STM32F4_AxB_RESET() family of 
macros in both clk driver and DT in order to reuse the bit layouts from 
dt-bindings/mfd/stm32f4-rcc.h .

Normal case would have looked like this:

		timer3: timer@40000000 {
			compatible = "st,stm32-timer";
			reg = <0x40000000 0x400>;
			interrupts = <28>;
			resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
			clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
			status = "disabled";
		};

Without the macros it looks like this:

		timer3: timer@40000000 {
			compatible = "st,stm32-timer";
			reg = <0x40000000 0x400>;
			interrupts = <28>;
			resets = <&rcc 257>;
			clocks = <&rcc 513>;
			status = "disabled";
		};

However we could perhaps be more literate even if we don't use the macros?

		timer3: timer@40000000 {
			compatible = "st,stm32-timer";
			reg = <0x40000000 0x400>;
			interrupts = <28>;
			resets = <&rcc ((0x20*8) + 1)>;
			clocks = <&rcc ((0x40*8) + 1)>;
			status = "disabled";
		};


Daniel.


> Kind regards,
> Maxime
>
>>
>>          Arnd
>
> [0]: http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04523.html
> [1]: http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
>

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 13/05/15 12:45, Maxime Coquelin wrote:
> 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
>>> +
>>>
>>
>> Can you find a way to avoid this dependency?
>>
>> Maybe you can change the bindings so that the numbers you pass as
>> arguments to the reset and clock specifiers reflect the numbers that
>> the hardware use?
>
> If I understand correctly, you prefer the way I did in v7 [0]?
>
> I don't have a strong opinion on this. Either way is fine to me.
>
> I changed the bindings in the v8 after discussions with Daniel
> Thompson, who is implementing the clock driver part of the RCC IP.
>
> He proposed we used common defines, because each peripheral has a
> reset line and a clock gate.
> Both reset and clock are represented as a single bit, with only the
> base offset differing between clock and reset.
> You can have a look at chapter 6 of the reference manual [1] if you
> find some time.
>
> Having common defines between clocks and reset make sense to me, but I
> also understand your point of avoiding dependencies.
>
> Maybe I can revert back to v7 bindings for now, and then we can
> reconsider using common defines when Daniel will send the clock
> patches.
> Note that doing that won't break the DT binary compatibility, as the
> raw reset values, or the ones from defines are the same.
>
> Daniel, could you share an example of the bindings you would use for the clocks?

For the most cases, where there is a clock gate just before the 
peripheral it looks pretty much like the reset driver and I use the bit 
offset of the clock gating bit as the index.

However there are a couple of clocks without gating just before the 
clock reaches the peripheral:

1. A hard coded /8. I think this will have to be given a synthetic
    number.

2. Ungated dividers. For these I am using the bit offset of the LSB of
    the mux field.

So I think there is only one value that is completely unrelated to the 
hardware and will use a magic constant instead.

I had planned to macros similar to the STM32F4_AxB_RESET() family of 
macros in both clk driver and DT in order to reuse the bit layouts from 
dt-bindings/mfd/stm32f4-rcc.h .

Normal case would have looked like this:

		timer3: timer at 40000000 {
			compatible = "st,stm32-timer";
			reg = <0x40000000 0x400>;
			interrupts = <28>;
			resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
			clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
			status = "disabled";
		};

Without the macros it looks like this:

		timer3: timer at 40000000 {
			compatible = "st,stm32-timer";
			reg = <0x40000000 0x400>;
			interrupts = <28>;
			resets = <&rcc 257>;
			clocks = <&rcc 513>;
			status = "disabled";
		};

However we could perhaps be more literate even if we don't use the macros?

		timer3: timer at 40000000 {
			compatible = "st,stm32-timer";
			reg = <0x40000000 0x400>;
			interrupts = <28>;
			resets = <&rcc ((0x20*8) + 1)>;
			clocks = <&rcc ((0x40*8) + 1)>;
			status = "disabled";
		};


Daniel.


> Kind regards,
> Maxime
>
>>
>>          Arnd
>
> [0]: http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04523.html
> [1]: http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
>

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 13:58:05 Daniel Thompson wrote:
> On 13/05/15 12:45, Maxime Coquelin wrote:
> > 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> >> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> >>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
> >>> +
> >>>
> >>
> >> Can you find a way to avoid this dependency?
> >>
> >> Maybe you can change the bindings so that the numbers you pass as
> >> arguments to the reset and clock specifiers reflect the numbers that
> >> the hardware use?
> >
> > If I understand correctly, you prefer the way I did in v7 [0]?

Yes, that looks better. I would probably not list all the possible
values in the binding though, when the intention is to use the
hardware specific values, and being able to reuse the binding
and driver for variations of the same chip.

> > Note that doing that won't break the DT binary compatibility, as the
> > raw reset values, or the ones from defines are the same.
> >
> > Daniel, could you share an example of the bindings you would use for the clocks?
> 
> For the most cases, where there is a clock gate just before the 
> peripheral it looks pretty much like the reset driver and I use the bit 
> offset of the clock gating bit as the index.

Is this bit always the same index as the one for the reset driver?

> However there are a couple of clocks without gating just before the 
> clock reaches the peripheral:
> 
> 1. A hard coded /8. I think this will have to be given a synthetic
>     number.

If this is just a divider, why not use a separate DT node for that,
like this:

        clock {
                compatible = "fixed-factor-clock";
                clocks = <&parentclk>;
                #clock-cells = <0>;
                clock-div = <8>;
                clock-mult = <1>;
        };

No need to assign a number for this.

> 2. Ungated dividers. For these I am using the bit offset of the LSB of
>     the mux field.

Do these ones also come with resets?

> So I think there is only one value that is completely unrelated to the 
> hardware and will use a magic constant instead.
> 
> I had planned to macros similar to the STM32F4_AxB_RESET() family of 
> macros in both clk driver and DT in order to reuse the bit layouts from 
> dt-bindings/mfd/stm32f4-rcc.h .
> 
> Normal case would have looked like this:
> 
>                 timer3: timer@40000000 {
>                         compatible = "st,stm32-timer";
>                         reg = <0x40000000 0x400>;
>                         interrupts = <28>;
>                         resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
>                         clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
>                         status = "disabled";
>                 };
> 
> Without the macros it looks like this:
> 
>                 timer3: timer@40000000 {
>                         compatible = "st,stm32-timer";
>                         reg = <0x40000000 0x400>;
>                         interrupts = <28>;
>                         resets = <&rcc 257>;
>                         clocks = <&rcc 513>;
>                         status = "disabled";
>                 };
> 
> However we could perhaps be more literate even if we don't use the macros?
> 
>                 timer3: timer@40000000 {
>                         compatible = "st,stm32-timer";
>                         reg = <0x40000000 0x400>;
>                         interrupts = <28>;
>                         resets = <&rcc ((0x20*8) + 1)>;
>                         clocks = <&rcc ((0x40*8) + 1)>;
>                         status = "disabled";
>                 };

How about #address-cells = <2>, so you can do

		resets = <&rcc 8 1>;
		clocks = <&rcc 8 1>;

with the first cell being an index for the block and the second cell the
bit number within that block.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 13:58:05 Daniel Thompson wrote:
> On 13/05/15 12:45, Maxime Coquelin wrote:
> > 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> >> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> >>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
> >>> +
> >>>
> >>
> >> Can you find a way to avoid this dependency?
> >>
> >> Maybe you can change the bindings so that the numbers you pass as
> >> arguments to the reset and clock specifiers reflect the numbers that
> >> the hardware use?
> >
> > If I understand correctly, you prefer the way I did in v7 [0]?

Yes, that looks better. I would probably not list all the possible
values in the binding though, when the intention is to use the
hardware specific values, and being able to reuse the binding
and driver for variations of the same chip.

> > Note that doing that won't break the DT binary compatibility, as the
> > raw reset values, or the ones from defines are the same.
> >
> > Daniel, could you share an example of the bindings you would use for the clocks?
> 
> For the most cases, where there is a clock gate just before the 
> peripheral it looks pretty much like the reset driver and I use the bit 
> offset of the clock gating bit as the index.

Is this bit always the same index as the one for the reset driver?

> However there are a couple of clocks without gating just before the 
> clock reaches the peripheral:
> 
> 1. A hard coded /8. I think this will have to be given a synthetic
>     number.

If this is just a divider, why not use a separate DT node for that,
like this:

        clock {
                compatible = "fixed-factor-clock";
                clocks = <&parentclk>;
                #clock-cells = <0>;
                clock-div = <8>;
                clock-mult = <1>;
        };

No need to assign a number for this.

> 2. Ungated dividers. For these I am using the bit offset of the LSB of
>     the mux field.

Do these ones also come with resets?

> So I think there is only one value that is completely unrelated to the 
> hardware and will use a magic constant instead.
> 
> I had planned to macros similar to the STM32F4_AxB_RESET() family of 
> macros in both clk driver and DT in order to reuse the bit layouts from 
> dt-bindings/mfd/stm32f4-rcc.h .
> 
> Normal case would have looked like this:
> 
>                 timer3: timer@40000000 {
>                         compatible = "st,stm32-timer";
>                         reg = <0x40000000 0x400>;
>                         interrupts = <28>;
>                         resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
>                         clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
>                         status = "disabled";
>                 };
> 
> Without the macros it looks like this:
> 
>                 timer3: timer@40000000 {
>                         compatible = "st,stm32-timer";
>                         reg = <0x40000000 0x400>;
>                         interrupts = <28>;
>                         resets = <&rcc 257>;
>                         clocks = <&rcc 513>;
>                         status = "disabled";
>                 };
> 
> However we could perhaps be more literate even if we don't use the macros?
> 
>                 timer3: timer@40000000 {
>                         compatible = "st,stm32-timer";
>                         reg = <0x40000000 0x400>;
>                         interrupts = <28>;
>                         resets = <&rcc ((0x20*8) + 1)>;
>                         clocks = <&rcc ((0x40*8) + 1)>;
>                         status = "disabled";
>                 };

How about #address-cells = <2>, so you can do

		resets = <&rcc 8 1>;
		clocks = <&rcc 8 1>;

with the first cell being an index for the block and the second cell the
bit number within that block.

	Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 13:58:05 Daniel Thompson wrote:
> On 13/05/15 12:45, Maxime Coquelin wrote:
> > 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> >> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> >>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
> >>> +
> >>>
> >>
> >> Can you find a way to avoid this dependency?
> >>
> >> Maybe you can change the bindings so that the numbers you pass as
> >> arguments to the reset and clock specifiers reflect the numbers that
> >> the hardware use?
> >
> > If I understand correctly, you prefer the way I did in v7 [0]?

Yes, that looks better. I would probably not list all the possible
values in the binding though, when the intention is to use the
hardware specific values, and being able to reuse the binding
and driver for variations of the same chip.

> > Note that doing that won't break the DT binary compatibility, as the
> > raw reset values, or the ones from defines are the same.
> >
> > Daniel, could you share an example of the bindings you would use for the clocks?
> 
> For the most cases, where there is a clock gate just before the 
> peripheral it looks pretty much like the reset driver and I use the bit 
> offset of the clock gating bit as the index.

Is this bit always the same index as the one for the reset driver?

> However there are a couple of clocks without gating just before the 
> clock reaches the peripheral:
> 
> 1. A hard coded /8. I think this will have to be given a synthetic
>     number.

If this is just a divider, why not use a separate DT node for that,
like this:

        clock {
                compatible = "fixed-factor-clock";
                clocks = <&parentclk>;
                #clock-cells = <0>;
                clock-div = <8>;
                clock-mult = <1>;
        };

No need to assign a number for this.

> 2. Ungated dividers. For these I am using the bit offset of the LSB of
>     the mux field.

Do these ones also come with resets?

> So I think there is only one value that is completely unrelated to the 
> hardware and will use a magic constant instead.
> 
> I had planned to macros similar to the STM32F4_AxB_RESET() family of 
> macros in both clk driver and DT in order to reuse the bit layouts from 
> dt-bindings/mfd/stm32f4-rcc.h .
> 
> Normal case would have looked like this:
> 
>                 timer3: timer at 40000000 {
>                         compatible = "st,stm32-timer";
>                         reg = <0x40000000 0x400>;
>                         interrupts = <28>;
>                         resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
>                         clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
>                         status = "disabled";
>                 };
> 
> Without the macros it looks like this:
> 
>                 timer3: timer at 40000000 {
>                         compatible = "st,stm32-timer";
>                         reg = <0x40000000 0x400>;
>                         interrupts = <28>;
>                         resets = <&rcc 257>;
>                         clocks = <&rcc 513>;
>                         status = "disabled";
>                 };
> 
> However we could perhaps be more literate even if we don't use the macros?
> 
>                 timer3: timer at 40000000 {
>                         compatible = "st,stm32-timer";
>                         reg = <0x40000000 0x400>;
>                         interrupts = <28>;
>                         resets = <&rcc ((0x20*8) + 1)>;
>                         clocks = <&rcc ((0x40*8) + 1)>;
>                         status = "disabled";
>                 };

How about #address-cells = <2>, so you can do

		resets = <&rcc 8 1>;
		clocks = <&rcc 8 1>;

with the first cell being an index for the block and the second cell the
bit number within that block.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 13/05/15 14:27, Arnd Bergmann wrote:
> On Wednesday 13 May 2015 13:58:05 Daniel Thompson wrote:
>> On 13/05/15 12:45, Maxime Coquelin wrote:
>>> 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>>>>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
>>>>> +
>>>>>
>>>>
>>>> Can you find a way to avoid this dependency?
>>>>
>>>> Maybe you can change the bindings so that the numbers you pass as
>>>> arguments to the reset and clock specifiers reflect the numbers that
>>>> the hardware use?
>>>
>>> If I understand correctly, you prefer the way I did in v7 [0]?
>
> Yes, that looks better. I would probably not list all the possible
> values in the binding though, when the intention is to use the
> hardware specific values, and being able to reuse the binding
> and driver for variations of the same chip.

Indeed. It was that long list that originally provoked me to comment in 
the first place.


>>> Note that doing that won't break the DT binary compatibility, as the
>>> raw reset values, or the ones from defines are the same.
>>>
>>> Daniel, could you share an example of the bindings you would use for the clocks?
>>
>> For the most cases, where there is a clock gate just before the
>> peripheral it looks pretty much like the reset driver and I use the bit
>> offset of the clock gating bit as the index.
>
> Is this bit always the same index as the one for the reset driver?

For the all reset bits:

   clock idx = reset idx + 256

The opposite is not true; the clock bits are a superset of the reset 
bits (the reset bits act on cells but some cells have >1 clock).

>> However there are a couple of clocks without gating just before the
>> clock reaches the peripheral:
>>
>> 1. A hard coded /8. I think this will have to be given a synthetic
>>      number.
>
> If this is just a divider, why not use a separate DT node for that,
> like this:
>
>          clock {
>                  compatible = "fixed-factor-clock";
>                  clocks = <&parentclk>;
>                  #clock-cells = <0>;
>                  clock-div = <8>;
>                  clock-mult = <1>;
>          };
>
> No need to assign a number for this.

I'd wondered about doing that.

It will certainly work but it seemed a bit odd to me to have one (really 
tiny) part of the RCC cell included seperately in the platform 
description whilst all the complicated bits end up aggregated into the 
RCC cell.

Is there much prior art that uses this type of trick to avoid having 
magic numbers into the bindings?


>> 2. Ungated dividers. For these I am using the bit offset of the LSB of
>>      the mux field.
>
> Do these ones also come with resets?

No. They mostly run to the core and its intimate peripherals (i.e. only 
reset line comes from WDT).


>> So I think there is only one value that is completely unrelated to the
>> hardware and will use a magic constant instead.
>>
>> I had planned to macros similar to the STM32F4_AxB_RESET() family of
>> macros in both clk driver and DT in order to reuse the bit layouts from
>> dt-bindings/mfd/stm32f4-rcc.h .
>>
>> Normal case would have looked like this:
>>
>>                  timer3: timer@40000000 {
>>                          compatible = "st,stm32-timer";
>>                          reg = <0x40000000 0x400>;
>>                          interrupts = <28>;
>>                          resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
>>                          clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
>>                          status = "disabled";
>>                  };
>>
>> Without the macros it looks like this:
>>
>>                  timer3: timer@40000000 {
>>                          compatible = "st,stm32-timer";
>>                          reg = <0x40000000 0x400>;
>>                          interrupts = <28>;
>>                          resets = <&rcc 257>;
>>                          clocks = <&rcc 513>;
>>                          status = "disabled";
>>                  };
>>
>> However we could perhaps be more literate even if we don't use the macros?
>>
>>                  timer3: timer@40000000 {
>>                          compatible = "st,stm32-timer";
>>                          reg = <0x40000000 0x400>;
>>                          interrupts = <28>;
>>                          resets = <&rcc ((0x20*8) + 1)>;
>>                          clocks = <&rcc ((0x40*8) + 1)>;
>>                          status = "disabled";
>>                  };
>
> How about #address-cells = <2>, so you can do
>
> 		resets = <&rcc 8 1>;
> 		clocks = <&rcc 8 1>;
>
> with the first cell being an index for the block and the second cell the
> bit number within that block.

That would suit me very well (although is the 0x20/0x40 not the 8 that 
we would need in the middle column).

Maxime: Does that suit reset driver?


Daniel.

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 13/05/15 14:27, Arnd Bergmann wrote:
> On Wednesday 13 May 2015 13:58:05 Daniel Thompson wrote:
>> On 13/05/15 12:45, Maxime Coquelin wrote:
>>> 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
>>>>> +#include  <dt-bindings/mfd/stm32f4-rcc.h>
>>>>> +
>>>>>
>>>>
>>>> Can you find a way to avoid this dependency?
>>>>
>>>> Maybe you can change the bindings so that the numbers you pass as
>>>> arguments to the reset and clock specifiers reflect the numbers that
>>>> the hardware use?
>>>
>>> If I understand correctly, you prefer the way I did in v7 [0]?
>
> Yes, that looks better. I would probably not list all the possible
> values in the binding though, when the intention is to use the
> hardware specific values, and being able to reuse the binding
> and driver for variations of the same chip.

Indeed. It was that long list that originally provoked me to comment in 
the first place.


>>> Note that doing that won't break the DT binary compatibility, as the
>>> raw reset values, or the ones from defines are the same.
>>>
>>> Daniel, could you share an example of the bindings you would use for the clocks?
>>
>> For the most cases, where there is a clock gate just before the
>> peripheral it looks pretty much like the reset driver and I use the bit
>> offset of the clock gating bit as the index.
>
> Is this bit always the same index as the one for the reset driver?

For the all reset bits:

   clock idx = reset idx + 256

The opposite is not true; the clock bits are a superset of the reset 
bits (the reset bits act on cells but some cells have >1 clock).

>> However there are a couple of clocks without gating just before the
>> clock reaches the peripheral:
>>
>> 1. A hard coded /8. I think this will have to be given a synthetic
>>      number.
>
> If this is just a divider, why not use a separate DT node for that,
> like this:
>
>          clock {
>                  compatible = "fixed-factor-clock";
>                  clocks = <&parentclk>;
>                  #clock-cells = <0>;
>                  clock-div = <8>;
>                  clock-mult = <1>;
>          };
>
> No need to assign a number for this.

I'd wondered about doing that.

It will certainly work but it seemed a bit odd to me to have one (really 
tiny) part of the RCC cell included seperately in the platform 
description whilst all the complicated bits end up aggregated into the 
RCC cell.

Is there much prior art that uses this type of trick to avoid having 
magic numbers into the bindings?


>> 2. Ungated dividers. For these I am using the bit offset of the LSB of
>>      the mux field.
>
> Do these ones also come with resets?

No. They mostly run to the core and its intimate peripherals (i.e. only 
reset line comes from WDT).


>> So I think there is only one value that is completely unrelated to the
>> hardware and will use a magic constant instead.
>>
>> I had planned to macros similar to the STM32F4_AxB_RESET() family of
>> macros in both clk driver and DT in order to reuse the bit layouts from
>> dt-bindings/mfd/stm32f4-rcc.h .
>>
>> Normal case would have looked like this:
>>
>>                  timer3: timer at 40000000 {
>>                          compatible = "st,stm32-timer";
>>                          reg = <0x40000000 0x400>;
>>                          interrupts = <28>;
>>                          resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
>>                          clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
>>                          status = "disabled";
>>                  };
>>
>> Without the macros it looks like this:
>>
>>                  timer3: timer at 40000000 {
>>                          compatible = "st,stm32-timer";
>>                          reg = <0x40000000 0x400>;
>>                          interrupts = <28>;
>>                          resets = <&rcc 257>;
>>                          clocks = <&rcc 513>;
>>                          status = "disabled";
>>                  };
>>
>> However we could perhaps be more literate even if we don't use the macros?
>>
>>                  timer3: timer at 40000000 {
>>                          compatible = "st,stm32-timer";
>>                          reg = <0x40000000 0x400>;
>>                          interrupts = <28>;
>>                          resets = <&rcc ((0x20*8) + 1)>;
>>                          clocks = <&rcc ((0x40*8) + 1)>;
>>                          status = "disabled";
>>                  };
>
> How about #address-cells = <2>, so you can do
>
> 		resets = <&rcc 8 1>;
> 		clocks = <&rcc 8 1>;
>
> with the first cell being an index for the block and the second cell the
> bit number within that block.

That would suit me very well (although is the 0x20/0x40 not the 8 that 
we would need in the middle column).

Maxime: Does that suit reset driver?


Daniel.

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
> For the all reset bits:
> 
>    clock idx = reset idx + 256
> 
> The opposite is not true; the clock bits are a superset of the reset 
> bits (the reset bits act on cells but some cells have >1 clock).

Ok, in that case, I would strongly recommend subtracting that 256
offset keeping the numbers the same, to remove the function-type
macros.

> >> However there are a couple of clocks without gating just before the
> >> clock reaches the peripheral:
> >>
> >> 1. A hard coded /8. I think this will have to be given a synthetic
> >>      number.
> >
> > If this is just a divider, why not use a separate DT node for that,
> > like this:
> >
> >          clock {
> >                  compatible = "fixed-factor-clock";
> >                  clocks = <&parentclk>;
> >                  #clock-cells = <0>;
> >                  clock-div = <8>;
> >                  clock-mult = <1>;
> >          };
> >
> > No need to assign a number for this.
> 
> I'd wondered about doing that.
> 
> It will certainly work but it seemed a bit odd to me to have one (really 
> tiny) part of the RCC cell included seperately in the platform 
> description whilst all the complicated bits end up aggregated into the 
> RCC cell.
> 
> Is there much prior art that uses this type of trick to avoid having 
> magic numbers into the bindings?

Are you sure that divider is actually part of the RCC?

> >> 2. Ungated dividers. For these I am using the bit offset of the LSB of
> >>      the mux field.
> >
> > Do these ones also come with resets?
> 
> No. They mostly run to the core and its intimate peripherals (i.e. only 
> reset line comes from WDT).

Ok.

> >> So I think there is only one value that is completely unrelated to the
> >> hardware and will use a magic constant instead.
> >>
> >> I had planned to macros similar to the STM32F4_AxB_RESET() family of
> >> macros in both clk driver and DT in order to reuse the bit layouts from
> >> dt-bindings/mfd/stm32f4-rcc.h .
> >>
> >> Normal case would have looked like this:
> >>
> >>                  timer3: timer@40000000 {
> >>                          compatible = "st,stm32-timer";
> >>                          reg = <0x40000000 0x400>;
> >>                          interrupts = <28>;
> >>                          resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
> >>                          clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
> >>                          status = "disabled";
> >>                  };
> >>
> >> Without the macros it looks like this:
> >>
> >>                  timer3: timer@40000000 {
> >>                          compatible = "st,stm32-timer";
> >>                          reg = <0x40000000 0x400>;
> >>                          interrupts = <28>;
> >>                          resets = <&rcc 257>;
> >>                          clocks = <&rcc 513>;
> >>                          status = "disabled";
> >>                  };
> >>
> >> However we could perhaps be more literate even if we don't use the macros?
> >>
> >>                  timer3: timer@40000000 {
> >>                          compatible = "st,stm32-timer";
> >>                          reg = <0x40000000 0x400>;
> >>                          interrupts = <28>;
> >>                          resets = <&rcc ((0x20*8) + 1)>;
> >>                          clocks = <&rcc ((0x40*8) + 1)>;
> >>                          status = "disabled";
> >>                  };
> >
> > How about #address-cells = <2>, so you can do
> >
> > 		resets = <&rcc 8 1>;
> > 		clocks = <&rcc 8 1>;
> >
> > with the first cell being an index for the block and the second cell the
> > bit number within that block.
> 
> That would suit me very well (although is the 0x20/0x40 not the 8 that 
> we would need in the middle column).

We don't normally use register offsets in DT. The number 8 here instead
would indicate block 8, where each block is four bytes wide. Using the
same index here for reset and clock would also help readability.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
> For the all reset bits:
> 
>    clock idx = reset idx + 256
> 
> The opposite is not true; the clock bits are a superset of the reset 
> bits (the reset bits act on cells but some cells have >1 clock).

Ok, in that case, I would strongly recommend subtracting that 256
offset keeping the numbers the same, to remove the function-type
macros.

> >> However there are a couple of clocks without gating just before the
> >> clock reaches the peripheral:
> >>
> >> 1. A hard coded /8. I think this will have to be given a synthetic
> >>      number.
> >
> > If this is just a divider, why not use a separate DT node for that,
> > like this:
> >
> >          clock {
> >                  compatible = "fixed-factor-clock";
> >                  clocks = <&parentclk>;
> >                  #clock-cells = <0>;
> >                  clock-div = <8>;
> >                  clock-mult = <1>;
> >          };
> >
> > No need to assign a number for this.
> 
> I'd wondered about doing that.
> 
> It will certainly work but it seemed a bit odd to me to have one (really 
> tiny) part of the RCC cell included seperately in the platform 
> description whilst all the complicated bits end up aggregated into the 
> RCC cell.
> 
> Is there much prior art that uses this type of trick to avoid having 
> magic numbers into the bindings?

Are you sure that divider is actually part of the RCC?

> >> 2. Ungated dividers. For these I am using the bit offset of the LSB of
> >>      the mux field.
> >
> > Do these ones also come with resets?
> 
> No. They mostly run to the core and its intimate peripherals (i.e. only 
> reset line comes from WDT).

Ok.

> >> So I think there is only one value that is completely unrelated to the
> >> hardware and will use a magic constant instead.
> >>
> >> I had planned to macros similar to the STM32F4_AxB_RESET() family of
> >> macros in both clk driver and DT in order to reuse the bit layouts from
> >> dt-bindings/mfd/stm32f4-rcc.h .
> >>
> >> Normal case would have looked like this:
> >>
> >>                  timer3: timer@40000000 {
> >>                          compatible = "st,stm32-timer";
> >>                          reg = <0x40000000 0x400>;
> >>                          interrupts = <28>;
> >>                          resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
> >>                          clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
> >>                          status = "disabled";
> >>                  };
> >>
> >> Without the macros it looks like this:
> >>
> >>                  timer3: timer@40000000 {
> >>                          compatible = "st,stm32-timer";
> >>                          reg = <0x40000000 0x400>;
> >>                          interrupts = <28>;
> >>                          resets = <&rcc 257>;
> >>                          clocks = <&rcc 513>;
> >>                          status = "disabled";
> >>                  };
> >>
> >> However we could perhaps be more literate even if we don't use the macros?
> >>
> >>                  timer3: timer@40000000 {
> >>                          compatible = "st,stm32-timer";
> >>                          reg = <0x40000000 0x400>;
> >>                          interrupts = <28>;
> >>                          resets = <&rcc ((0x20*8) + 1)>;
> >>                          clocks = <&rcc ((0x40*8) + 1)>;
> >>                          status = "disabled";
> >>                  };
> >
> > How about #address-cells = <2>, so you can do
> >
> > 		resets = <&rcc 8 1>;
> > 		clocks = <&rcc 8 1>;
> >
> > with the first cell being an index for the block and the second cell the
> > bit number within that block.
> 
> That would suit me very well (although is the 0x20/0x40 not the 8 that 
> we would need in the middle column).

We don't normally use register offsets in DT. The number 8 here instead
would indicate block 8, where each block is four bytes wide. Using the
same index here for reset and clock would also help readability.

	Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
> For the all reset bits:
> 
>    clock idx = reset idx + 256
> 
> The opposite is not true; the clock bits are a superset of the reset 
> bits (the reset bits act on cells but some cells have >1 clock).

Ok, in that case, I would strongly recommend subtracting that 256
offset keeping the numbers the same, to remove the function-type
macros.

> >> However there are a couple of clocks without gating just before the
> >> clock reaches the peripheral:
> >>
> >> 1. A hard coded /8. I think this will have to be given a synthetic
> >>      number.
> >
> > If this is just a divider, why not use a separate DT node for that,
> > like this:
> >
> >          clock {
> >                  compatible = "fixed-factor-clock";
> >                  clocks = <&parentclk>;
> >                  #clock-cells = <0>;
> >                  clock-div = <8>;
> >                  clock-mult = <1>;
> >          };
> >
> > No need to assign a number for this.
> 
> I'd wondered about doing that.
> 
> It will certainly work but it seemed a bit odd to me to have one (really 
> tiny) part of the RCC cell included seperately in the platform 
> description whilst all the complicated bits end up aggregated into the 
> RCC cell.
> 
> Is there much prior art that uses this type of trick to avoid having 
> magic numbers into the bindings?

Are you sure that divider is actually part of the RCC?

> >> 2. Ungated dividers. For these I am using the bit offset of the LSB of
> >>      the mux field.
> >
> > Do these ones also come with resets?
> 
> No. They mostly run to the core and its intimate peripherals (i.e. only 
> reset line comes from WDT).

Ok.

> >> So I think there is only one value that is completely unrelated to the
> >> hardware and will use a magic constant instead.
> >>
> >> I had planned to macros similar to the STM32F4_AxB_RESET() family of
> >> macros in both clk driver and DT in order to reuse the bit layouts from
> >> dt-bindings/mfd/stm32f4-rcc.h .
> >>
> >> Normal case would have looked like this:
> >>
> >>                  timer3: timer at 40000000 {
> >>                          compatible = "st,stm32-timer";
> >>                          reg = <0x40000000 0x400>;
> >>                          interrupts = <28>;
> >>                          resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
> >>                          clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
> >>                          status = "disabled";
> >>                  };
> >>
> >> Without the macros it looks like this:
> >>
> >>                  timer3: timer at 40000000 {
> >>                          compatible = "st,stm32-timer";
> >>                          reg = <0x40000000 0x400>;
> >>                          interrupts = <28>;
> >>                          resets = <&rcc 257>;
> >>                          clocks = <&rcc 513>;
> >>                          status = "disabled";
> >>                  };
> >>
> >> However we could perhaps be more literate even if we don't use the macros?
> >>
> >>                  timer3: timer at 40000000 {
> >>                          compatible = "st,stm32-timer";
> >>                          reg = <0x40000000 0x400>;
> >>                          interrupts = <28>;
> >>                          resets = <&rcc ((0x20*8) + 1)>;
> >>                          clocks = <&rcc ((0x40*8) + 1)>;
> >>                          status = "disabled";
> >>                  };
> >
> > How about #address-cells = <2>, so you can do
> >
> > 		resets = <&rcc 8 1>;
> > 		clocks = <&rcc 8 1>;
> >
> > with the first cell being an index for the block and the second cell the
> > bit number within that block.
> 
> That would suit me very well (although is the 0x20/0x40 not the 8 that 
> we would need in the middle column).

We don't normally use register offsets in DT. The number 8 here instead
would indicate block 8, where each block is four bytes wide. Using the
same index here for reset and clock would also help readability.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>> For the all reset bits:
>>
>>    clock idx = reset idx + 256
>>
>> The opposite is not true; the clock bits are a superset of the reset
>> bits (the reset bits act on cells but some cells have >1 clock).
>
> Ok, in that case, I would strongly recommend subtracting that 256
> offset keeping the numbers the same, to remove the function-type
> macros.
>
>> >> However there are a couple of clocks without gating just before the
>> >> clock reaches the peripheral:
>> >>
>> >> 1. A hard coded /8. I think this will have to be given a synthetic
>> >>      number.
>> >
>> > If this is just a divider, why not use a separate DT node for that,
>> > like this:
>> >
>> >          clock {
>> >                  compatible = "fixed-factor-clock";
>> >                  clocks = <&parentclk>;
>> >                  #clock-cells = <0>;
>> >                  clock-div = <8>;
>> >                  clock-mult = <1>;
>> >          };
>> >
>> > No need to assign a number for this.
>>
>> I'd wondered about doing that.
>>
>> It will certainly work but it seemed a bit odd to me to have one (really
>> tiny) part of the RCC cell included seperately in the platform
>> description whilst all the complicated bits end up aggregated into the
>> RCC cell.
>>
>> Is there much prior art that uses this type of trick to avoid having
>> magic numbers into the bindings?
>
> Are you sure that divider is actually part of the RCC?
>
>> >> 2. Ungated dividers. For these I am using the bit offset of the LSB of
>> >>      the mux field.
>> >
>> > Do these ones also come with resets?
>>
>> No. They mostly run to the core and its intimate peripherals (i.e. only
>> reset line comes from WDT).
>
> Ok.
>
>> >> So I think there is only one value that is completely unrelated to the
>> >> hardware and will use a magic constant instead.
>> >>
>> >> I had planned to macros similar to the STM32F4_AxB_RESET() family of
>> >> macros in both clk driver and DT in order to reuse the bit layouts from
>> >> dt-bindings/mfd/stm32f4-rcc.h .
>> >>
>> >> Normal case would have looked like this:
>> >>
>> >>                  timer3: timer@40000000 {
>> >>                          compatible = "st,stm32-timer";
>> >>                          reg = <0x40000000 0x400>;
>> >>                          interrupts = <28>;
>> >>                          resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
>> >>                          clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
>> >>                          status = "disabled";
>> >>                  };
>> >>
>> >> Without the macros it looks like this:
>> >>
>> >>                  timer3: timer@40000000 {
>> >>                          compatible = "st,stm32-timer";
>> >>                          reg = <0x40000000 0x400>;
>> >>                          interrupts = <28>;
>> >>                          resets = <&rcc 257>;
>> >>                          clocks = <&rcc 513>;
>> >>                          status = "disabled";
>> >>                  };
>> >>
>> >> However we could perhaps be more literate even if we don't use the macros?
>> >>
>> >>                  timer3: timer@40000000 {
>> >>                          compatible = "st,stm32-timer";
>> >>                          reg = <0x40000000 0x400>;
>> >>                          interrupts = <28>;
>> >>                          resets = <&rcc ((0x20*8) + 1)>;
>> >>                          clocks = <&rcc ((0x40*8) + 1)>;
>> >>                          status = "disabled";
>> >>                  };
>> >
>> > How about #address-cells = <2>, so you can do
>> >
>> >             resets = <&rcc 8 1>;
>> >             clocks = <&rcc 8 1>;
>> >
>> > with the first cell being an index for the block and the second cell the
>> > bit number within that block.
>>
>> That would suit me very well (although is the 0x20/0x40 not the 8 that
>> we would need in the middle column).
>
> We don't normally use register offsets in DT. The number 8 here instead
> would indicate block 8, where each block is four bytes wide. Using the
> same index here for reset and clock would also help readability.

My view is that it makes the bindings usage very complex.
Also, it implies we have a specific compatible for stm32f429, whereas
we didn't need with my earlier proposals.
Indeed, the reset driver will need to know the offset of every reset
registers, because:
  1. The AHB registers start at RCC offset 0x10 (up to 0x18)
  2. The APB registers start at RCC offset 0x20 (up to 0x24).
We have a gap between AHB and APB registers, so how do we map the
index for the block you propose?
Should the gap be considered as a block, or we should skip it?

I'm afraid it will not be straightforward for a reset user to
understand how to use this bindings.

Either my v7 or v8 versions would have made possible to use a single
compatible for STM32 series.
If we stick with one of these, we could even think to have a "generic"
reset driver, as it could be compatible with sunxi driver bindings.

What is your view?

Kind regards,
Maxime

>
>         Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>> For the all reset bits:
>>
>>    clock idx = reset idx + 256
>>
>> The opposite is not true; the clock bits are a superset of the reset
>> bits (the reset bits act on cells but some cells have >1 clock).
>
> Ok, in that case, I would strongly recommend subtracting that 256
> offset keeping the numbers the same, to remove the function-type
> macros.
>
>> >> However there are a couple of clocks without gating just before the
>> >> clock reaches the peripheral:
>> >>
>> >> 1. A hard coded /8. I think this will have to be given a synthetic
>> >>      number.
>> >
>> > If this is just a divider, why not use a separate DT node for that,
>> > like this:
>> >
>> >          clock {
>> >                  compatible = "fixed-factor-clock";
>> >                  clocks = <&parentclk>;
>> >                  #clock-cells = <0>;
>> >                  clock-div = <8>;
>> >                  clock-mult = <1>;
>> >          };
>> >
>> > No need to assign a number for this.
>>
>> I'd wondered about doing that.
>>
>> It will certainly work but it seemed a bit odd to me to have one (really
>> tiny) part of the RCC cell included seperately in the platform
>> description whilst all the complicated bits end up aggregated into the
>> RCC cell.
>>
>> Is there much prior art that uses this type of trick to avoid having
>> magic numbers into the bindings?
>
> Are you sure that divider is actually part of the RCC?
>
>> >> 2. Ungated dividers. For these I am using the bit offset of the LSB of
>> >>      the mux field.
>> >
>> > Do these ones also come with resets?
>>
>> No. They mostly run to the core and its intimate peripherals (i.e. only
>> reset line comes from WDT).
>
> Ok.
>
>> >> So I think there is only one value that is completely unrelated to the
>> >> hardware and will use a magic constant instead.
>> >>
>> >> I had planned to macros similar to the STM32F4_AxB_RESET() family of
>> >> macros in both clk driver and DT in order to reuse the bit layouts from
>> >> dt-bindings/mfd/stm32f4-rcc.h .
>> >>
>> >> Normal case would have looked like this:
>> >>
>> >>                  timer3: timer@40000000 {
>> >>                          compatible = "st,stm32-timer";
>> >>                          reg = <0x40000000 0x400>;
>> >>                          interrupts = <28>;
>> >>                          resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
>> >>                          clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
>> >>                          status = "disabled";
>> >>                  };
>> >>
>> >> Without the macros it looks like this:
>> >>
>> >>                  timer3: timer@40000000 {
>> >>                          compatible = "st,stm32-timer";
>> >>                          reg = <0x40000000 0x400>;
>> >>                          interrupts = <28>;
>> >>                          resets = <&rcc 257>;
>> >>                          clocks = <&rcc 513>;
>> >>                          status = "disabled";
>> >>                  };
>> >>
>> >> However we could perhaps be more literate even if we don't use the macros?
>> >>
>> >>                  timer3: timer@40000000 {
>> >>                          compatible = "st,stm32-timer";
>> >>                          reg = <0x40000000 0x400>;
>> >>                          interrupts = <28>;
>> >>                          resets = <&rcc ((0x20*8) + 1)>;
>> >>                          clocks = <&rcc ((0x40*8) + 1)>;
>> >>                          status = "disabled";
>> >>                  };
>> >
>> > How about #address-cells = <2>, so you can do
>> >
>> >             resets = <&rcc 8 1>;
>> >             clocks = <&rcc 8 1>;
>> >
>> > with the first cell being an index for the block and the second cell the
>> > bit number within that block.
>>
>> That would suit me very well (although is the 0x20/0x40 not the 8 that
>> we would need in the middle column).
>
> We don't normally use register offsets in DT. The number 8 here instead
> would indicate block 8, where each block is four bytes wide. Using the
> same index here for reset and clock would also help readability.

My view is that it makes the bindings usage very complex.
Also, it implies we have a specific compatible for stm32f429, whereas
we didn't need with my earlier proposals.
Indeed, the reset driver will need to know the offset of every reset
registers, because:
  1. The AHB registers start at RCC offset 0x10 (up to 0x18)
  2. The APB registers start at RCC offset 0x20 (up to 0x24).
We have a gap between AHB and APB registers, so how do we map the
index for the block you propose?
Should the gap be considered as a block, or we should skip it?

I'm afraid it will not be straightforward for a reset user to
understand how to use this bindings.

Either my v7 or v8 versions would have made possible to use a single
compatible for STM32 series.
If we stick with one of these, we could even think to have a "generic"
reset driver, as it could be compatible with sunxi driver bindings.

What is your view?

Kind regards,
Maxime

>
>         Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>> For the all reset bits:
>>
>>    clock idx = reset idx + 256
>>
>> The opposite is not true; the clock bits are a superset of the reset
>> bits (the reset bits act on cells but some cells have >1 clock).
>
> Ok, in that case, I would strongly recommend subtracting that 256
> offset keeping the numbers the same, to remove the function-type
> macros.
>
>> >> However there are a couple of clocks without gating just before the
>> >> clock reaches the peripheral:
>> >>
>> >> 1. A hard coded /8. I think this will have to be given a synthetic
>> >>      number.
>> >
>> > If this is just a divider, why not use a separate DT node for that,
>> > like this:
>> >
>> >          clock {
>> >                  compatible = "fixed-factor-clock";
>> >                  clocks = <&parentclk>;
>> >                  #clock-cells = <0>;
>> >                  clock-div = <8>;
>> >                  clock-mult = <1>;
>> >          };
>> >
>> > No need to assign a number for this.
>>
>> I'd wondered about doing that.
>>
>> It will certainly work but it seemed a bit odd to me to have one (really
>> tiny) part of the RCC cell included seperately in the platform
>> description whilst all the complicated bits end up aggregated into the
>> RCC cell.
>>
>> Is there much prior art that uses this type of trick to avoid having
>> magic numbers into the bindings?
>
> Are you sure that divider is actually part of the RCC?
>
>> >> 2. Ungated dividers. For these I am using the bit offset of the LSB of
>> >>      the mux field.
>> >
>> > Do these ones also come with resets?
>>
>> No. They mostly run to the core and its intimate peripherals (i.e. only
>> reset line comes from WDT).
>
> Ok.
>
>> >> So I think there is only one value that is completely unrelated to the
>> >> hardware and will use a magic constant instead.
>> >>
>> >> I had planned to macros similar to the STM32F4_AxB_RESET() family of
>> >> macros in both clk driver and DT in order to reuse the bit layouts from
>> >> dt-bindings/mfd/stm32f4-rcc.h .
>> >>
>> >> Normal case would have looked like this:
>> >>
>> >>                  timer3: timer at 40000000 {
>> >>                          compatible = "st,stm32-timer";
>> >>                          reg = <0x40000000 0x400>;
>> >>                          interrupts = <28>;
>> >>                          resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
>> >>                          clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
>> >>                          status = "disabled";
>> >>                  };
>> >>
>> >> Without the macros it looks like this:
>> >>
>> >>                  timer3: timer at 40000000 {
>> >>                          compatible = "st,stm32-timer";
>> >>                          reg = <0x40000000 0x400>;
>> >>                          interrupts = <28>;
>> >>                          resets = <&rcc 257>;
>> >>                          clocks = <&rcc 513>;
>> >>                          status = "disabled";
>> >>                  };
>> >>
>> >> However we could perhaps be more literate even if we don't use the macros?
>> >>
>> >>                  timer3: timer at 40000000 {
>> >>                          compatible = "st,stm32-timer";
>> >>                          reg = <0x40000000 0x400>;
>> >>                          interrupts = <28>;
>> >>                          resets = <&rcc ((0x20*8) + 1)>;
>> >>                          clocks = <&rcc ((0x40*8) + 1)>;
>> >>                          status = "disabled";
>> >>                  };
>> >
>> > How about #address-cells = <2>, so you can do
>> >
>> >             resets = <&rcc 8 1>;
>> >             clocks = <&rcc 8 1>;
>> >
>> > with the first cell being an index for the block and the second cell the
>> > bit number within that block.
>>
>> That would suit me very well (although is the 0x20/0x40 not the 8 that
>> we would need in the middle column).
>
> We don't normally use register offsets in DT. The number 8 here instead
> would indicate block 8, where each block is four bytes wide. Using the
> same index here for reset and clock would also help readability.

My view is that it makes the bindings usage very complex.
Also, it implies we have a specific compatible for stm32f429, whereas
we didn't need with my earlier proposals.
Indeed, the reset driver will need to know the offset of every reset
registers, because:
  1. The AHB registers start at RCC offset 0x10 (up to 0x18)
  2. The APB registers start at RCC offset 0x20 (up to 0x24).
We have a gap between AHB and APB registers, so how do we map the
index for the block you propose?
Should the gap be considered as a block, or we should skip it?

I'm afraid it will not be straightforward for a reset user to
understand how to use this bindings.

Either my v7 or v8 versions would have made possible to use a single
compatible for STM32 series.
If we stick with one of these, we could even think to have a "generic"
reset driver, as it could be compatible with sunxi driver bindings.

What is your view?

Kind regards,
Maxime

>
>         Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
> >>
> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
> >> we would need in the middle column).
> >
> > We don't normally use register offsets in DT. The number 8 here instead
> > would indicate block 8, where each block is four bytes wide. Using the
> > same index here for reset and clock would also help readability.
> 
> My view is that it makes the bindings usage very complex.
> Also, it implies we have a specific compatible for stm32f429, whereas
> we didn't need with my earlier proposals.
> Indeed, the reset driver will need to know the offset of every reset
> registers, because:
>   1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>   2. The APB registers start at RCC offset 0x20 (up to 0x24).
> We have a gap between AHB and APB registers, so how do we map the
> index for the block you propose?
> Should the gap be considered as a block, or we should skip it?
>
> I'm afraid it will not be straightforward for a reset user to
> understand how to use this bindings.
> 
> Either my v7 or v8 versions would have made possible to use a single
> compatible for STM32 series.
> If we stick with one of these, we could even think to have a "generic"
> reset driver, as it could be compatible with sunxi driver bindings.

We should definitely try to use the same compatible string for all of
them, and make a binding that is easy to use.

I haven't fully understood the requirements for the various parts that
are involved here. My understanding so far was that the driver could
use the index from the first cell and compute

	void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
	void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;

Are there parts that need something else? If the 0x10 offset is
different, we probably want a different compatible string, and I'd
consider it a different part at that point. If there are chips
that do not spread the clock from the reset by exactly 256 bits,
we could add a DT property in the rcc node for that.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
> >>
> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
> >> we would need in the middle column).
> >
> > We don't normally use register offsets in DT. The number 8 here instead
> > would indicate block 8, where each block is four bytes wide. Using the
> > same index here for reset and clock would also help readability.
> 
> My view is that it makes the bindings usage very complex.
> Also, it implies we have a specific compatible for stm32f429, whereas
> we didn't need with my earlier proposals.
> Indeed, the reset driver will need to know the offset of every reset
> registers, because:
>   1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>   2. The APB registers start at RCC offset 0x20 (up to 0x24).
> We have a gap between AHB and APB registers, so how do we map the
> index for the block you propose?
> Should the gap be considered as a block, or we should skip it?
>
> I'm afraid it will not be straightforward for a reset user to
> understand how to use this bindings.
> 
> Either my v7 or v8 versions would have made possible to use a single
> compatible for STM32 series.
> If we stick with one of these, we could even think to have a "generic"
> reset driver, as it could be compatible with sunxi driver bindings.

We should definitely try to use the same compatible string for all of
them, and make a binding that is easy to use.

I haven't fully understood the requirements for the various parts that
are involved here. My understanding so far was that the driver could
use the index from the first cell and compute

	void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
	void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;

Are there parts that need something else? If the 0x10 offset is
different, we probably want a different compatible string, and I'd
consider it a different part at that point. If there are chips
that do not spread the clock from the reset by exactly 256 bits,
we could add a DT property in the rcc node for that.

	Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
> >>
> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
> >> we would need in the middle column).
> >
> > We don't normally use register offsets in DT. The number 8 here instead
> > would indicate block 8, where each block is four bytes wide. Using the
> > same index here for reset and clock would also help readability.
> 
> My view is that it makes the bindings usage very complex.
> Also, it implies we have a specific compatible for stm32f429, whereas
> we didn't need with my earlier proposals.
> Indeed, the reset driver will need to know the offset of every reset
> registers, because:
>   1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>   2. The APB registers start at RCC offset 0x20 (up to 0x24).
> We have a gap between AHB and APB registers, so how do we map the
> index for the block you propose?
> Should the gap be considered as a block, or we should skip it?
>
> I'm afraid it will not be straightforward for a reset user to
> understand how to use this bindings.
> 
> Either my v7 or v8 versions would have made possible to use a single
> compatible for STM32 series.
> If we stick with one of these, we could even think to have a "generic"
> reset driver, as it could be compatible with sunxi driver bindings.

We should definitely try to use the same compatible string for all of
them, and make a binding that is easy to use.

I haven't fully understood the requirements for the various parts that
are involved here. My understanding so far was that the driver could
use the index from the first cell and compute

	void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
	void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;

Are there parts that need something else? If the 0x10 offset is
different, we probably want a different compatible string, and I'd
consider it a different part at that point. If there are chips
that do not spread the clock from the reset by exactly 256 bits,
we could add a DT property in the rcc node for that.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>> >>
>> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
>> >> we would need in the middle column).
>> >
>> > We don't normally use register offsets in DT. The number 8 here instead
>> > would indicate block 8, where each block is four bytes wide. Using the
>> > same index here for reset and clock would also help readability.
>>
>> My view is that it makes the bindings usage very complex.
>> Also, it implies we have a specific compatible for stm32f429, whereas
>> we didn't need with my earlier proposals.
>> Indeed, the reset driver will need to know the offset of every reset
>> registers, because:
>>   1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>   2. The APB registers start at RCC offset 0x20 (up to 0x24).
>> We have a gap between AHB and APB registers, so how do we map the
>> index for the block you propose?
>> Should the gap be considered as a block, or we should skip it?
>>
>> I'm afraid it will not be straightforward for a reset user to
>> understand how to use this bindings.
>>
>> Either my v7 or v8 versions would have made possible to use a single
>> compatible for STM32 series.
>> If we stick with one of these, we could even think to have a "generic"
>> reset driver, as it could be compatible with sunxi driver bindings.
>
> We should definitely try to use the same compatible string for all of
> them, and make a binding that is easy to use.
>
> I haven't fully understood the requirements for the various parts that
> are involved here. My understanding so far was that the driver could
> use the index from the first cell and compute
>
>         void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>         void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;

This calculation is true, but we have to take into account there is a
hole in the middle, between AHB3, and APB1 register:

AHB1RSTR : offset = 0x10, index = 0
AHB2RSTR : offset = 0x14, index = 1
AHB3RSTR : offset = 0x18, index = 2
<HOLE >     : offset = 0x1c, index = 3
APB1RSTR : offset = 0x20, index = 4
APB2RSTR : offset = 0x24, index = 5

So we have to carefully document this hole in the bindings, maybe by
listing indexes in the documentation?

>
> Are there parts that need something else? If the 0x10 offset is
> different, we probably want a different compatible string, and I'd
> consider it a different part at that point. If there are chips
> that do not spread the clock from the reset by exactly 256 bits,
> we could add a DT property in the rcc node for that.

I will check other chips, to see if this is valid generally.

Thanks for your feedback,
Maxime

>
>         Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>> >>
>> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
>> >> we would need in the middle column).
>> >
>> > We don't normally use register offsets in DT. The number 8 here instead
>> > would indicate block 8, where each block is four bytes wide. Using the
>> > same index here for reset and clock would also help readability.
>>
>> My view is that it makes the bindings usage very complex.
>> Also, it implies we have a specific compatible for stm32f429, whereas
>> we didn't need with my earlier proposals.
>> Indeed, the reset driver will need to know the offset of every reset
>> registers, because:
>>   1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>   2. The APB registers start at RCC offset 0x20 (up to 0x24).
>> We have a gap between AHB and APB registers, so how do we map the
>> index for the block you propose?
>> Should the gap be considered as a block, or we should skip it?
>>
>> I'm afraid it will not be straightforward for a reset user to
>> understand how to use this bindings.
>>
>> Either my v7 or v8 versions would have made possible to use a single
>> compatible for STM32 series.
>> If we stick with one of these, we could even think to have a "generic"
>> reset driver, as it could be compatible with sunxi driver bindings.
>
> We should definitely try to use the same compatible string for all of
> them, and make a binding that is easy to use.
>
> I haven't fully understood the requirements for the various parts that
> are involved here. My understanding so far was that the driver could
> use the index from the first cell and compute
>
>         void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>         void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;

This calculation is true, but we have to take into account there is a
hole in the middle, between AHB3, and APB1 register:

AHB1RSTR : offset = 0x10, index = 0
AHB2RSTR : offset = 0x14, index = 1
AHB3RSTR : offset = 0x18, index = 2
<HOLE >     : offset = 0x1c, index = 3
APB1RSTR : offset = 0x20, index = 4
APB2RSTR : offset = 0x24, index = 5

So we have to carefully document this hole in the bindings, maybe by
listing indexes in the documentation?

>
> Are there parts that need something else? If the 0x10 offset is
> different, we probably want a different compatible string, and I'd
> consider it a different part at that point. If there are chips
> that do not spread the clock from the reset by exactly 256 bits,
> we could add a DT property in the rcc node for that.

I will check other chips, to see if this is valid generally.

Thanks for your feedback,
Maxime

>
>         Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>> >>
>> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
>> >> we would need in the middle column).
>> >
>> > We don't normally use register offsets in DT. The number 8 here instead
>> > would indicate block 8, where each block is four bytes wide. Using the
>> > same index here for reset and clock would also help readability.
>>
>> My view is that it makes the bindings usage very complex.
>> Also, it implies we have a specific compatible for stm32f429, whereas
>> we didn't need with my earlier proposals.
>> Indeed, the reset driver will need to know the offset of every reset
>> registers, because:
>>   1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>   2. The APB registers start at RCC offset 0x20 (up to 0x24).
>> We have a gap between AHB and APB registers, so how do we map the
>> index for the block you propose?
>> Should the gap be considered as a block, or we should skip it?
>>
>> I'm afraid it will not be straightforward for a reset user to
>> understand how to use this bindings.
>>
>> Either my v7 or v8 versions would have made possible to use a single
>> compatible for STM32 series.
>> If we stick with one of these, we could even think to have a "generic"
>> reset driver, as it could be compatible with sunxi driver bindings.
>
> We should definitely try to use the same compatible string for all of
> them, and make a binding that is easy to use.
>
> I haven't fully understood the requirements for the various parts that
> are involved here. My understanding so far was that the driver could
> use the index from the first cell and compute
>
>         void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>         void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;

This calculation is true, but we have to take into account there is a
hole in the middle, between AHB3, and APB1 register:

AHB1RSTR : offset = 0x10, index = 0
AHB2RSTR : offset = 0x14, index = 1
AHB3RSTR : offset = 0x18, index = 2
<HOLE >     : offset = 0x1c, index = 3
APB1RSTR : offset = 0x20, index = 4
APB2RSTR : offset = 0x24, index = 5

So we have to carefully document this hole in the bindings, maybe by
listing indexes in the documentation?

>
> Are there parts that need something else? If the 0x10 offset is
> different, we probably want a different compatible string, and I'd
> consider it a different part at that point. If there are chips
> that do not spread the clock from the reset by exactly 256 bits,
> we could add a DT property in the rcc node for that.

I will check other chips, to see if this is valid generally.

Thanks for your feedback,
Maxime

>
>         Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 18:54:10 Maxime Coquelin wrote:
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
> 
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
> 
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?

I would only list the index definitions in the binding if they
are common across all chips using that binding.

>From what I see above, this is really regular, so it's possible
that others follow it as well, but it's also possible that another
chip completely screwed up that system because it didn't fit
otherwise.

Ideally the binding should follow closely what is documented
in the data sheet.

> > Are there parts that need something else? If the 0x10 offset is
> > different, we probably want a different compatible string, and I'd
> > consider it a different part at that point. If there are chips
> > that do not spread the clock from the reset by exactly 256 bits,
> > we could add a DT property in the rcc node for that.
> 
> I will check other chips, to see if this is valid generally.

Ok.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 18:54:10 Maxime Coquelin wrote:
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
> 
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
> 
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?

I would only list the index definitions in the binding if they
are common across all chips using that binding.

>From what I see above, this is really regular, so it's possible
that others follow it as well, but it's also possible that another
chip completely screwed up that system because it didn't fit
otherwise.

Ideally the binding should follow closely what is documented
in the data sheet.

> > Are there parts that need something else? If the 0x10 offset is
> > different, we probably want a different compatible string, and I'd
> > consider it a different part at that point. If there are chips
> > that do not spread the clock from the reset by exactly 256 bits,
> > we could add a DT property in the rcc node for that.
> 
> I will check other chips, to see if this is valid generally.

Ok.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 18:54:10 Maxime Coquelin wrote:
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
> 
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
> 
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?

I would only list the index definitions in the binding if they
are common across all chips using that binding.

From what I see above, this is really regular, so it's possible
that others follow it as well, but it's also possible that another
chip completely screwed up that system because it didn't fit
otherwise.

Ideally the binding should follow closely what is documented
in the data sheet.

> > Are there parts that need something else? If the 0x10 offset is
> > different, we probably want a different compatible string, and I'd
> > consider it a different part at that point. If there are chips
> > that do not spread the clock from the reset by exactly 256 bits,
> > we could add a DT property in the rcc node for that.
> 
> I will check other chips, to see if this is valid generally.

Ok.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 18:54:10 Maxime Coquelin wrote:
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
> 
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
> 
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?

I would only list the index definitions in the binding if they
are common across all chips using that binding.

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 18:54:10 Maxime Coquelin wrote:
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
> 
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
> 
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?

I would only list the index definitions in the binding if they
are common across all chips using that binding.

>From what I see above, this is really regular, so it's possible
that others follow it as well, but it's also possible that another
chip completely screwed up that system because it didn't fit
otherwise.

Ideally the binding should follow closely what is documented
in the data sheet.

> > Are there parts that need something else? If the 0x10 offset is
> > different, we probably want a different compatible string, and I'd
> > consider it a different part at that point. If there are chips
> > that do not spread the clock from the reset by exactly 256 bits,
> > we could add a DT property in the rcc node for that.
> 
> I will check other chips, to see if this is valid generally.

Ok.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 13/05/15 17:54, Maxime Coquelin wrote:
> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>>>>>
>>>>> That would suit me very well (although is the 0x20/0x40 not the 8 that
>>>>> we would need in the middle column).
>>>>
>>>> We don't normally use register offsets in DT. The number 8 here instead
>>>> would indicate block 8, where each block is four bytes wide. Using the
>>>> same index here for reset and clock would also help readability.
>>>
>>> My view is that it makes the bindings usage very complex.
>>> Also, it implies we have a specific compatible for stm32f429, whereas
>>> we didn't need with my earlier proposals.
>>> Indeed, the reset driver will need to know the offset of every reset
>>> registers, because:
>>>    1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>>    2. The APB registers start at RCC offset 0x20 (up to 0x24).
>>> We have a gap between AHB and APB registers, so how do we map the
>>> index for the block you propose?
>>> Should the gap be considered as a block, or we should skip it?
>>>
>>> I'm afraid it will not be straightforward for a reset user to
>>> understand how to use this bindings.
>>>
>>> Either my v7 or v8 versions would have made possible to use a single
>>> compatible for STM32 series.
>>> If we stick with one of these, we could even think to have a "generic"
>>> reset driver, as it could be compatible with sunxi driver bindings.
>>
>> We should definitely try to use the same compatible string for all of
>> them, and make a binding that is easy to use.
>>
>> I haven't fully understood the requirements for the various parts that
>> are involved here. My understanding so far was that the driver could
>> use the index from the first cell and compute
>>
>>          void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>          void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:

... and equally importantly, only allows us to use hardware mappings for 
the gated clocks.

> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
>
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?

The register set has PLL, mux and dividers in the registers at 0x00, 
0x04 and 0x08.

Many of these clocks can be kept out of DT entirely because they are 
only there to feed other parts of the clock tree. However some of the 
dividers flow directly into cells that appear in device tree (such as 
the systick) and so we need to be able to reference them.

In other words the proposed mapping cannot allow us to express the 
dividers properly (because the index would have to be negative):
   void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;

Thus I'd favour using different indexes for reset and clock bindings, 
both using the naive mapping function:
   void __iomem *reg =  rcc_base + 4 * index

I think that its so much easier to check against the datasheet like 
that. Admittedly is we follow the block-of-4-bytes idiom we have to 
divide a hex number by four but thats not so hard and we end up with:

		resets = <&rcc  8 0>;
		clocks = <&rcc 16 0>;

At the end of the day if we say we want to follow the datasheet, lets be 
do it in the most direct way properly.


Daniel.


PS
I've written a custom lookup function to to get from the DT index to an 
offset into the struct clk *array I'm using. That means I don't care 
much about any big holes in the register space.

>> Are there parts that need something else? If the 0x10 offset is
>> different, we probably want a different compatible string, and I'd
>> consider it a different part at that point. If there are chips
>> that do not spread the clock from the reset by exactly 256 bits,
>> we could add a DT property in the rcc node for that.
>
> I will check other chips, to see if this is valid generally.
>
> Thanks for your feedback,
> Maxime
>
>>
>>          Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 13/05/15 17:54, Maxime Coquelin wrote:
> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>>>>>
>>>>> That would suit me very well (although is the 0x20/0x40 not the 8 that
>>>>> we would need in the middle column).
>>>>
>>>> We don't normally use register offsets in DT. The number 8 here instead
>>>> would indicate block 8, where each block is four bytes wide. Using the
>>>> same index here for reset and clock would also help readability.
>>>
>>> My view is that it makes the bindings usage very complex.
>>> Also, it implies we have a specific compatible for stm32f429, whereas
>>> we didn't need with my earlier proposals.
>>> Indeed, the reset driver will need to know the offset of every reset
>>> registers, because:
>>>    1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>>    2. The APB registers start at RCC offset 0x20 (up to 0x24).
>>> We have a gap between AHB and APB registers, so how do we map the
>>> index for the block you propose?
>>> Should the gap be considered as a block, or we should skip it?
>>>
>>> I'm afraid it will not be straightforward for a reset user to
>>> understand how to use this bindings.
>>>
>>> Either my v7 or v8 versions would have made possible to use a single
>>> compatible for STM32 series.
>>> If we stick with one of these, we could even think to have a "generic"
>>> reset driver, as it could be compatible with sunxi driver bindings.
>>
>> We should definitely try to use the same compatible string for all of
>> them, and make a binding that is easy to use.
>>
>> I haven't fully understood the requirements for the various parts that
>> are involved here. My understanding so far was that the driver could
>> use the index from the first cell and compute
>>
>>          void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>          void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:

... and equally importantly, only allows us to use hardware mappings for 
the gated clocks.

> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
>
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?

The register set has PLL, mux and dividers in the registers at 0x00, 
0x04 and 0x08.

Many of these clocks can be kept out of DT entirely because they are 
only there to feed other parts of the clock tree. However some of the 
dividers flow directly into cells that appear in device tree (such as 
the systick) and so we need to be able to reference them.

In other words the proposed mapping cannot allow us to express the 
dividers properly (because the index would have to be negative):
   void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;

Thus I'd favour using different indexes for reset and clock bindings, 
both using the naive mapping function:
   void __iomem *reg =  rcc_base + 4 * index

I think that its so much easier to check against the datasheet like 
that. Admittedly is we follow the block-of-4-bytes idiom we have to 
divide a hex number by four but thats not so hard and we end up with:

		resets = <&rcc  8 0>;
		clocks = <&rcc 16 0>;

At the end of the day if we say we want to follow the datasheet, lets be 
do it in the most direct way properly.


Daniel.


PS
I've written a custom lookup function to to get from the DT index to an 
offset into the struct clk *array I'm using. That means I don't care 
much about any big holes in the register space.

>> Are there parts that need something else? If the 0x10 offset is
>> different, we probably want a different compatible string, and I'd
>> consider it a different part at that point. If there are chips
>> that do not spread the clock from the reset by exactly 256 bits,
>> we could add a DT property in the rcc node for that.
>
> I will check other chips, to see if this is valid generally.
>
> Thanks for your feedback,
> Maxime
>
>>
>>          Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 13/05/15 17:54, Maxime Coquelin wrote:
> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>>>>>
>>>>> That would suit me very well (although is the 0x20/0x40 not the 8 that
>>>>> we would need in the middle column).
>>>>
>>>> We don't normally use register offsets in DT. The number 8 here instead
>>>> would indicate block 8, where each block is four bytes wide. Using the
>>>> same index here for reset and clock would also help readability.
>>>
>>> My view is that it makes the bindings usage very complex.
>>> Also, it implies we have a specific compatible for stm32f429, whereas
>>> we didn't need with my earlier proposals.
>>> Indeed, the reset driver will need to know the offset of every reset
>>> registers, because:
>>>    1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>>    2. The APB registers start at RCC offset 0x20 (up to 0x24).
>>> We have a gap between AHB and APB registers, so how do we map the
>>> index for the block you propose?
>>> Should the gap be considered as a block, or we should skip it?
>>>
>>> I'm afraid it will not be straightforward for a reset user to
>>> understand how to use this bindings.
>>>
>>> Either my v7 or v8 versions would have made possible to use a single
>>> compatible for STM32 series.
>>> If we stick with one of these, we could even think to have a "generic"
>>> reset driver, as it could be compatible with sunxi driver bindings.
>>
>> We should definitely try to use the same compatible string for all of
>> them, and make a binding that is easy to use.
>>
>> I haven't fully understood the requirements for the various parts that
>> are involved here. My understanding so far was that the driver could
>> use the index from the first cell and compute
>>
>>          void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>          void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:

... and equally importantly, only allows us to use hardware mappings for 
the gated clocks.

> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
>
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?

The register set has PLL, mux and dividers in the registers at 0x00, 
0x04 and 0x08.

Many of these clocks can be kept out of DT entirely because they are 
only there to feed other parts of the clock tree. However some of the 
dividers flow directly into cells that appear in device tree (such as 
the systick) and so we need to be able to reference them.

In other words the proposed mapping cannot allow us to express the 
dividers properly (because the index would have to be negative):
   void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;

Thus I'd favour using different indexes for reset and clock bindings, 
both using the naive mapping function:
   void __iomem *reg =  rcc_base + 4 * index

I think that its so much easier to check against the datasheet like 
that. Admittedly is we follow the block-of-4-bytes idiom we have to 
divide a hex number by four but thats not so hard and we end up with:

		resets = <&rcc  8 0>;
		clocks = <&rcc 16 0>;

At the end of the day if we say we want to follow the datasheet, lets be 
do it in the most direct way properly.


Daniel.


PS
I've written a custom lookup function to to get from the DT index to an 
offset into the struct clk *array I'm using. That means I don't care 
much about any big holes in the register space.

>> Are there parts that need something else? If the 0x10 offset is
>> different, we probably want a different compatible string, and I'd
>> consider it a different part at that point. If there are chips
>> that do not spread the clock from the reset by exactly 256 bits,
>> we could add a DT property in the rcc node for that.
>
> I will check other chips, to see if this is valid generally.
>
> Thanks for your feedback,
> Maxime
>
>>
>>          Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
> On 13/05/15 17:54, Maxime Coquelin wrote:
> > 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> >>
> >> We should definitely try to use the same compatible string for all of
> >> them, and make a binding that is easy to use.
> >>
> >> I haven't fully understood the requirements for the various parts that
> >> are involved here. My understanding so far was that the driver could
> >> use the index from the first cell and compute
> >>
> >>          void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
> >>          void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
> >
> > This calculation is true, but we have to take into account there is a
> > hole in the middle, between AHB3, and APB1 register:
> 
> ... and equally importantly, only allows us to use hardware mappings for 
> the gated clocks.
> 
> > AHB1RSTR : offset = 0x10, index = 0
> > AHB2RSTR : offset = 0x14, index = 1
> > AHB3RSTR : offset = 0x18, index = 2
> > <HOLE >     : offset = 0x1c, index = 3
> > APB1RSTR : offset = 0x20, index = 4
> > APB2RSTR : offset = 0x24, index = 5
> >
> > So we have to carefully document this hole in the bindings, maybe by
> > listing indexes in the documentation?
> 
> The register set has PLL, mux and dividers in the registers at 0x00, 
> 0x04 and 0x08.
> 
> Many of these clocks can be kept out of DT entirely because they are 
> only there to feed other parts of the clock tree. However some of the 
> dividers flow directly into cells that appear in device tree (such as 
> the systick) and so we need to be able to reference them.
> 
> In other words the proposed mapping cannot allow us to express the 
> dividers properly (because the index would have to be negative):
>    void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
> 
> Thus I'd favour using different indexes for reset and clock bindings, 
> both using the naive mapping function:
>    void __iomem *reg =  rcc_base + 4 * index
> 
> I think that its so much easier to check against the datasheet like 
> that. Admittedly is we follow the block-of-4-bytes idiom we have to 
> divide a hex number by four but thats not so hard and we end up with:
> 
> 		resets = <&rcc  8 0>;
> 		clocks = <&rcc 16 0>;
> 
> At the end of the day if we say we want to follow the datasheet, lets be 
> do it in the most direct way properly.
> 
> 
> PS
> I've written a custom lookup function to to get from the DT index to an 
> offset into the struct clk *array I'm using. That means I don't care 
> much about any big holes in the register space.

How about using the first cell to indicate the type (pll, mux, div, gate)
and the second cell for the number (between 0 and 256)? That way, the
gates numbers would match the reset numbers, and your internal mapping
function would look a bit nicer.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
> On 13/05/15 17:54, Maxime Coquelin wrote:
> > 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> >>
> >> We should definitely try to use the same compatible string for all of
> >> them, and make a binding that is easy to use.
> >>
> >> I haven't fully understood the requirements for the various parts that
> >> are involved here. My understanding so far was that the driver could
> >> use the index from the first cell and compute
> >>
> >>          void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
> >>          void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
> >
> > This calculation is true, but we have to take into account there is a
> > hole in the middle, between AHB3, and APB1 register:
> 
> ... and equally importantly, only allows us to use hardware mappings for 
> the gated clocks.
> 
> > AHB1RSTR : offset = 0x10, index = 0
> > AHB2RSTR : offset = 0x14, index = 1
> > AHB3RSTR : offset = 0x18, index = 2
> > <HOLE >     : offset = 0x1c, index = 3
> > APB1RSTR : offset = 0x20, index = 4
> > APB2RSTR : offset = 0x24, index = 5
> >
> > So we have to carefully document this hole in the bindings, maybe by
> > listing indexes in the documentation?
> 
> The register set has PLL, mux and dividers in the registers at 0x00, 
> 0x04 and 0x08.
> 
> Many of these clocks can be kept out of DT entirely because they are 
> only there to feed other parts of the clock tree. However some of the 
> dividers flow directly into cells that appear in device tree (such as 
> the systick) and so we need to be able to reference them.
> 
> In other words the proposed mapping cannot allow us to express the 
> dividers properly (because the index would have to be negative):
>    void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
> 
> Thus I'd favour using different indexes for reset and clock bindings, 
> both using the naive mapping function:
>    void __iomem *reg =  rcc_base + 4 * index
> 
> I think that its so much easier to check against the datasheet like 
> that. Admittedly is we follow the block-of-4-bytes idiom we have to 
> divide a hex number by four but thats not so hard and we end up with:
> 
> 		resets = <&rcc  8 0>;
> 		clocks = <&rcc 16 0>;
> 
> At the end of the day if we say we want to follow the datasheet, lets be 
> do it in the most direct way properly.
> 
> 
> PS
> I've written a custom lookup function to to get from the DT index to an 
> offset into the struct clk *array I'm using. That means I don't care 
> much about any big holes in the register space.

How about using the first cell to indicate the type (pll, mux, div, gate)
and the second cell for the number (between 0 and 256)? That way, the
gates numbers would match the reset numbers, and your internal mapping
function would look a bit nicer.

	Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Arnd Bergmann]

On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
> On 13/05/15 17:54, Maxime Coquelin wrote:
> > 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> >>
> >> We should definitely try to use the same compatible string for all of
> >> them, and make a binding that is easy to use.
> >>
> >> I haven't fully understood the requirements for the various parts that
> >> are involved here. My understanding so far was that the driver could
> >> use the index from the first cell and compute
> >>
> >>          void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
> >>          void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
> >
> > This calculation is true, but we have to take into account there is a
> > hole in the middle, between AHB3, and APB1 register:
> 
> ... and equally importantly, only allows us to use hardware mappings for 
> the gated clocks.
> 
> > AHB1RSTR : offset = 0x10, index = 0
> > AHB2RSTR : offset = 0x14, index = 1
> > AHB3RSTR : offset = 0x18, index = 2
> > <HOLE >     : offset = 0x1c, index = 3
> > APB1RSTR : offset = 0x20, index = 4
> > APB2RSTR : offset = 0x24, index = 5
> >
> > So we have to carefully document this hole in the bindings, maybe by
> > listing indexes in the documentation?
> 
> The register set has PLL, mux and dividers in the registers at 0x00, 
> 0x04 and 0x08.
> 
> Many of these clocks can be kept out of DT entirely because they are 
> only there to feed other parts of the clock tree. However some of the 
> dividers flow directly into cells that appear in device tree (such as 
> the systick) and so we need to be able to reference them.
> 
> In other words the proposed mapping cannot allow us to express the 
> dividers properly (because the index would have to be negative):
>    void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
> 
> Thus I'd favour using different indexes for reset and clock bindings, 
> both using the naive mapping function:
>    void __iomem *reg =  rcc_base + 4 * index
> 
> I think that its so much easier to check against the datasheet like 
> that. Admittedly is we follow the block-of-4-bytes idiom we have to 
> divide a hex number by four but thats not so hard and we end up with:
> 
> 		resets = <&rcc  8 0>;
> 		clocks = <&rcc 16 0>;
> 
> At the end of the day if we say we want to follow the datasheet, lets be 
> do it in the most direct way properly.
> 
> 
> PS
> I've written a custom lookup function to to get from the DT index to an 
> offset into the struct clk *array I'm using. That means I don't care 
> much about any big holes in the register space.

How about using the first cell to indicate the type (pll, mux, div, gate)
and the second cell for the number (between 0 and 256)? That way, the
gates numbers would match the reset numbers, and your internal mapping
function would look a bit nicer.

	Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-13 21:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
>> On 13/05/15 17:54, Maxime Coquelin wrote:
>> > 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> >>
>> >> We should definitely try to use the same compatible string for all of
>> >> them, and make a binding that is easy to use.
>> >>
>> >> I haven't fully understood the requirements for the various parts that
>> >> are involved here. My understanding so far was that the driver could
>> >> use the index from the first cell and compute
>> >>
>> >>          void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>> >>          void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>> >
>> > This calculation is true, but we have to take into account there is a
>> > hole in the middle, between AHB3, and APB1 register:
>>
>> ... and equally importantly, only allows us to use hardware mappings for
>> the gated clocks.
>>
>> > AHB1RSTR : offset = 0x10, index = 0
>> > AHB2RSTR : offset = 0x14, index = 1
>> > AHB3RSTR : offset = 0x18, index = 2
>> > <HOLE >     : offset = 0x1c, index = 3
>> > APB1RSTR : offset = 0x20, index = 4
>> > APB2RSTR : offset = 0x24, index = 5
>> >
>> > So we have to carefully document this hole in the bindings, maybe by
>> > listing indexes in the documentation?
>>
>> The register set has PLL, mux and dividers in the registers at 0x00,
>> 0x04 and 0x08.
>>
>> Many of these clocks can be kept out of DT entirely because they are
>> only there to feed other parts of the clock tree. However some of the
>> dividers flow directly into cells that appear in device tree (such as
>> the systick) and so we need to be able to reference them.
>>
>> In other words the proposed mapping cannot allow us to express the
>> dividers properly (because the index would have to be negative):
>>    void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>
>> Thus I'd favour using different indexes for reset and clock bindings,
>> both using the naive mapping function:
>>    void __iomem *reg =  rcc_base + 4 * index
>>
>> I think that its so much easier to check against the datasheet like
>> that. Admittedly is we follow the block-of-4-bytes idiom we have to
>> divide a hex number by four but thats not so hard and we end up with:
>>
>>               resets = <&rcc  8 0>;
>>               clocks = <&rcc 16 0>;
>>
>> At the end of the day if we say we want to follow the datasheet, lets be
>> do it in the most direct way properly.

Daniel, I'm fine with your proposal.
Doing that, we can have a single compatible string for stm32 family,
even if the reset start offset change between two chips.

>>
>>
>> PS
>> I've written a custom lookup function to to get from the DT index to an
>> offset into the struct clk *array I'm using. That means I don't care
>> much about any big holes in the register space.
>
> How about using the first cell to indicate the type (pll, mux, div, gate)
> and the second cell for the number (between 0 and 256)? That way, the
> gates numbers would match the reset numbers, and your internal mapping
> function would look a bit nicer.

That's another option.
In this case, for reset, we will only need one cell, right?

Regards,
Maxime



>
>         Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-13 21:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
>> On 13/05/15 17:54, Maxime Coquelin wrote:
>> > 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> >>
>> >> We should definitely try to use the same compatible string for all of
>> >> them, and make a binding that is easy to use.
>> >>
>> >> I haven't fully understood the requirements for the various parts that
>> >> are involved here. My understanding so far was that the driver could
>> >> use the index from the first cell and compute
>> >>
>> >>          void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>> >>          void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>> >
>> > This calculation is true, but we have to take into account there is a
>> > hole in the middle, between AHB3, and APB1 register:
>>
>> ... and equally importantly, only allows us to use hardware mappings for
>> the gated clocks.
>>
>> > AHB1RSTR : offset = 0x10, index = 0
>> > AHB2RSTR : offset = 0x14, index = 1
>> > AHB3RSTR : offset = 0x18, index = 2
>> > <HOLE >     : offset = 0x1c, index = 3
>> > APB1RSTR : offset = 0x20, index = 4
>> > APB2RSTR : offset = 0x24, index = 5
>> >
>> > So we have to carefully document this hole in the bindings, maybe by
>> > listing indexes in the documentation?
>>
>> The register set has PLL, mux and dividers in the registers at 0x00,
>> 0x04 and 0x08.
>>
>> Many of these clocks can be kept out of DT entirely because they are
>> only there to feed other parts of the clock tree. However some of the
>> dividers flow directly into cells that appear in device tree (such as
>> the systick) and so we need to be able to reference them.
>>
>> In other words the proposed mapping cannot allow us to express the
>> dividers properly (because the index would have to be negative):
>>    void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>
>> Thus I'd favour using different indexes for reset and clock bindings,
>> both using the naive mapping function:
>>    void __iomem *reg =  rcc_base + 4 * index
>>
>> I think that its so much easier to check against the datasheet like
>> that. Admittedly is we follow the block-of-4-bytes idiom we have to
>> divide a hex number by four but thats not so hard and we end up with:
>>
>>               resets = <&rcc  8 0>;
>>               clocks = <&rcc 16 0>;
>>
>> At the end of the day if we say we want to follow the datasheet, lets be
>> do it in the most direct way properly.

Daniel, I'm fine with your proposal.
Doing that, we can have a single compatible string for stm32 family,
even if the reset start offset change between two chips.

>>
>>
>> PS
>> I've written a custom lookup function to to get from the DT index to an
>> offset into the struct clk *array I'm using. That means I don't care
>> much about any big holes in the register space.
>
> How about using the first cell to indicate the type (pll, mux, div, gate)
> and the second cell for the number (between 0 and 256)? That way, the
> gates numbers would match the reset numbers, and your internal mapping
> function would look a bit nicer.

That's another option.
In this case, for reset, we will only need one cell, right?

Regards,
Maxime



>
>         Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-13 21:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
>> On 13/05/15 17:54, Maxime Coquelin wrote:
>> > 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> >>
>> >> We should definitely try to use the same compatible string for all of
>> >> them, and make a binding that is easy to use.
>> >>
>> >> I haven't fully understood the requirements for the various parts that
>> >> are involved here. My understanding so far was that the driver could
>> >> use the index from the first cell and compute
>> >>
>> >>          void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>> >>          void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>> >
>> > This calculation is true, but we have to take into account there is a
>> > hole in the middle, between AHB3, and APB1 register:
>>
>> ... and equally importantly, only allows us to use hardware mappings for
>> the gated clocks.
>>
>> > AHB1RSTR : offset = 0x10, index = 0
>> > AHB2RSTR : offset = 0x14, index = 1
>> > AHB3RSTR : offset = 0x18, index = 2
>> > <HOLE >     : offset = 0x1c, index = 3
>> > APB1RSTR : offset = 0x20, index = 4
>> > APB2RSTR : offset = 0x24, index = 5
>> >
>> > So we have to carefully document this hole in the bindings, maybe by
>> > listing indexes in the documentation?
>>
>> The register set has PLL, mux and dividers in the registers at 0x00,
>> 0x04 and 0x08.
>>
>> Many of these clocks can be kept out of DT entirely because they are
>> only there to feed other parts of the clock tree. However some of the
>> dividers flow directly into cells that appear in device tree (such as
>> the systick) and so we need to be able to reference them.
>>
>> In other words the proposed mapping cannot allow us to express the
>> dividers properly (because the index would have to be negative):
>>    void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>
>> Thus I'd favour using different indexes for reset and clock bindings,
>> both using the naive mapping function:
>>    void __iomem *reg =  rcc_base + 4 * index
>>
>> I think that its so much easier to check against the datasheet like
>> that. Admittedly is we follow the block-of-4-bytes idiom we have to
>> divide a hex number by four but thats not so hard and we end up with:
>>
>>               resets = <&rcc  8 0>;
>>               clocks = <&rcc 16 0>;
>>
>> At the end of the day if we say we want to follow the datasheet, lets be
>> do it in the most direct way properly.

Daniel, I'm fine with your proposal.
Doing that, we can have a single compatible string for stm32 family,
even if the reset start offset change between two chips.

>>
>>
>> PS
>> I've written a custom lookup function to to get from the DT index to an
>> offset into the struct clk *array I'm using. That means I don't care
>> much about any big holes in the register space.
>
> How about using the first cell to indicate the type (pll, mux, div, gate)
> and the second cell for the number (between 0 and 256)? That way, the
> gates numbers would match the reset numbers, and your internal mapping
> function would look a bit nicer.

That's another option.
In this case, for reset, we will only need one cell, right?

Regards,
Maxime



>
>         Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 14/05/15 17:34, Maxime Coquelin wrote:
> 2015-05-13 21:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
>>> On 13/05/15 17:54, Maxime Coquelin wrote:
>>>> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>>>>
>>>>> We should definitely try to use the same compatible string for all of
>>>>> them, and make a binding that is easy to use.
>>>>>
>>>>> I haven't fully understood the requirements for the various parts that
>>>>> are involved here. My understanding so far was that the driver could
>>>>> use the index from the first cell and compute
>>>>>
>>>>>           void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>>>>           void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>>>
>>>> This calculation is true, but we have to take into account there is a
>>>> hole in the middle, between AHB3, and APB1 register:
>>>
>>> ... and equally importantly, only allows us to use hardware mappings for
>>> the gated clocks.
>>>
>>>> AHB1RSTR : offset = 0x10, index = 0
>>>> AHB2RSTR : offset = 0x14, index = 1
>>>> AHB3RSTR : offset = 0x18, index = 2
>>>> <HOLE >     : offset = 0x1c, index = 3
>>>> APB1RSTR : offset = 0x20, index = 4
>>>> APB2RSTR : offset = 0x24, index = 5
>>>>
>>>> So we have to carefully document this hole in the bindings, maybe by
>>>> listing indexes in the documentation?
>>>
>>> The register set has PLL, mux and dividers in the registers at 0x00,
>>> 0x04 and 0x08.
>>>
>>> Many of these clocks can be kept out of DT entirely because they are
>>> only there to feed other parts of the clock tree. However some of the
>>> dividers flow directly into cells that appear in device tree (such as
>>> the systick) and so we need to be able to reference them.
>>>
>>> In other words the proposed mapping cannot allow us to express the
>>> dividers properly (because the index would have to be negative):
>>>     void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>>
>>> Thus I'd favour using different indexes for reset and clock bindings,
>>> both using the naive mapping function:
>>>     void __iomem *reg =  rcc_base + 4 * index
>>>
>>> I think that its so much easier to check against the datasheet like
>>> that. Admittedly is we follow the block-of-4-bytes idiom we have to
>>> divide a hex number by four but thats not so hard and we end up with:
>>>
>>>                resets = <&rcc  8 0>;
>>>                clocks = <&rcc 16 0>;
>>>
>>> At the end of the day if we say we want to follow the datasheet, lets be
>>> do it in the most direct way properly.
>
> Daniel, I'm fine with your proposal.
> Doing that, we can have a single compatible string for stm32 family,
> even if the reset start offset change between two chips.
>
>>> PS
>>> I've written a custom lookup function to to get from the DT index to an
>>> offset into the struct clk *array I'm using. That means I don't care
>>> much about any big holes in the register space.
>>
>> How about using the first cell to indicate the type (pll, mux, div, gate)
>> and the second cell for the number (between 0 and 256)? That way, the
>> gates numbers would match the reset numbers, and your internal mapping
>> function would look a bit nicer.
>
> That's another option.
> In this case, for reset, we will only need one cell, right?

I think so. For the reset, this is essentially no change versus v7 
except for applying an offset of 0x10 when calculating the base address.

I won't get time to polish up the clk driver this weekend but I will try 
to write a documentation file proposing some clock bindings for you to 
look at.


Daniel.

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 14/05/15 17:34, Maxime Coquelin wrote:
> 2015-05-13 21:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
>>> On 13/05/15 17:54, Maxime Coquelin wrote:
>>>> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>>>>
>>>>> We should definitely try to use the same compatible string for all of
>>>>> them, and make a binding that is easy to use.
>>>>>
>>>>> I haven't fully understood the requirements for the various parts that
>>>>> are involved here. My understanding so far was that the driver could
>>>>> use the index from the first cell and compute
>>>>>
>>>>>           void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>>>>           void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>>>
>>>> This calculation is true, but we have to take into account there is a
>>>> hole in the middle, between AHB3, and APB1 register:
>>>
>>> ... and equally importantly, only allows us to use hardware mappings for
>>> the gated clocks.
>>>
>>>> AHB1RSTR : offset = 0x10, index = 0
>>>> AHB2RSTR : offset = 0x14, index = 1
>>>> AHB3RSTR : offset = 0x18, index = 2
>>>> <HOLE >     : offset = 0x1c, index = 3
>>>> APB1RSTR : offset = 0x20, index = 4
>>>> APB2RSTR : offset = 0x24, index = 5
>>>>
>>>> So we have to carefully document this hole in the bindings, maybe by
>>>> listing indexes in the documentation?
>>>
>>> The register set has PLL, mux and dividers in the registers at 0x00,
>>> 0x04 and 0x08.
>>>
>>> Many of these clocks can be kept out of DT entirely because they are
>>> only there to feed other parts of the clock tree. However some of the
>>> dividers flow directly into cells that appear in device tree (such as
>>> the systick) and so we need to be able to reference them.
>>>
>>> In other words the proposed mapping cannot allow us to express the
>>> dividers properly (because the index would have to be negative):
>>>     void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>>
>>> Thus I'd favour using different indexes for reset and clock bindings,
>>> both using the naive mapping function:
>>>     void __iomem *reg =  rcc_base + 4 * index
>>>
>>> I think that its so much easier to check against the datasheet like
>>> that. Admittedly is we follow the block-of-4-bytes idiom we have to
>>> divide a hex number by four but thats not so hard and we end up with:
>>>
>>>                resets = <&rcc  8 0>;
>>>                clocks = <&rcc 16 0>;
>>>
>>> At the end of the day if we say we want to follow the datasheet, lets be
>>> do it in the most direct way properly.
>
> Daniel, I'm fine with your proposal.
> Doing that, we can have a single compatible string for stm32 family,
> even if the reset start offset change between two chips.
>
>>> PS
>>> I've written a custom lookup function to to get from the DT index to an
>>> offset into the struct clk *array I'm using. That means I don't care
>>> much about any big holes in the register space.
>>
>> How about using the first cell to indicate the type (pll, mux, div, gate)
>> and the second cell for the number (between 0 and 256)? That way, the
>> gates numbers would match the reset numbers, and your internal mapping
>> function would look a bit nicer.
>
> That's another option.
> In this case, for reset, we will only need one cell, right?

I think so. For the reset, this is essentially no change versus v7 
except for applying an offset of 0x10 when calculating the base address.

I won't get time to polish up the clk driver this weekend but I will try 
to write a documentation file proposing some clock bindings for you to 
look at.


Daniel.

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 14/05/15 17:34, Maxime Coquelin wrote:
> 2015-05-13 21:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wednesday 13 May 2015 20:29:12 Daniel Thompson wrote:
>>> On 13/05/15 17:54, Maxime Coquelin wrote:
>>>> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>>>>
>>>>> We should definitely try to use the same compatible string for all of
>>>>> them, and make a binding that is easy to use.
>>>>>
>>>>> I haven't fully understood the requirements for the various parts that
>>>>> are involved here. My understanding so far was that the driver could
>>>>> use the index from the first cell and compute
>>>>>
>>>>>           void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>>>>           void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>>>
>>>> This calculation is true, but we have to take into account there is a
>>>> hole in the middle, between AHB3, and APB1 register:
>>>
>>> ... and equally importantly, only allows us to use hardware mappings for
>>> the gated clocks.
>>>
>>>> AHB1RSTR : offset = 0x10, index = 0
>>>> AHB2RSTR : offset = 0x14, index = 1
>>>> AHB3RSTR : offset = 0x18, index = 2
>>>> <HOLE >     : offset = 0x1c, index = 3
>>>> APB1RSTR : offset = 0x20, index = 4
>>>> APB2RSTR : offset = 0x24, index = 5
>>>>
>>>> So we have to carefully document this hole in the bindings, maybe by
>>>> listing indexes in the documentation?
>>>
>>> The register set has PLL, mux and dividers in the registers at 0x00,
>>> 0x04 and 0x08.
>>>
>>> Many of these clocks can be kept out of DT entirely because they are
>>> only there to feed other parts of the clock tree. However some of the
>>> dividers flow directly into cells that appear in device tree (such as
>>> the systick) and so we need to be able to reference them.
>>>
>>> In other words the proposed mapping cannot allow us to express the
>>> dividers properly (because the index would have to be negative):
>>>     void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>>>
>>> Thus I'd favour using different indexes for reset and clock bindings,
>>> both using the naive mapping function:
>>>     void __iomem *reg =  rcc_base + 4 * index
>>>
>>> I think that its so much easier to check against the datasheet like
>>> that. Admittedly is we follow the block-of-4-bytes idiom we have to
>>> divide a hex number by four but thats not so hard and we end up with:
>>>
>>>                resets = <&rcc  8 0>;
>>>                clocks = <&rcc 16 0>;
>>>
>>> At the end of the day if we say we want to follow the datasheet, lets be
>>> do it in the most direct way properly.
>
> Daniel, I'm fine with your proposal.
> Doing that, we can have a single compatible string for stm32 family,
> even if the reset start offset change between two chips.
>
>>> PS
>>> I've written a custom lookup function to to get from the DT index to an
>>> offset into the struct clk *array I'm using. That means I don't care
>>> much about any big holes in the register space.
>>
>> How about using the first cell to indicate the type (pll, mux, div, gate)
>> and the second cell for the number (between 0 and 256)? That way, the
>> gates numbers would match the reset numbers, and your internal mapping
>> function would look a bit nicer.
>
> That's another option.
> In this case, for reset, we will only need one cell, right?

I think so. For the reset, this is essentially no change versus v7 
except for applying an offset of 0x10 when calculating the base address.

I won't get time to polish up the clk driver this weekend but I will try 
to write a documentation file proposing some clock bindings for you to 
look at.


Daniel.

Re: [PATCH v8 12/16] ARM: Add STM32 family machine

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:54 Maxime Coquelin wrote:
> STMicrolectronics's STM32 series is a family of Cortex-M
> microcontrollers. It is used in various applications, and
> proposes a wide range of peripherals.
> 
> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Applied to next/soc, thanks

	Arnd

Re: [PATCH v8 12/16] ARM: Add STM32 family machine

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:54 Maxime Coquelin wrote:
> STMicrolectronics's STM32 series is a family of Cortex-M
> microcontrollers. It is used in various applications, and
> proposes a wide range of peripherals.
> 
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

Applied to next/soc, thanks

	Arnd

[PATCH v8 12/16] ARM: Add STM32 family machine

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:54 Maxime Coquelin wrote:
> STMicrolectronics's STM32 series is a family of Cortex-M
> microcontrollers. It is used in various applications, and
> proposes a wide range of peripherals.
> 
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

Applied to next/soc, thanks

	Arnd

Re: [PATCH v8 16/16] MAINTAINERS: Add entry for STM32 MCUs

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:58 Maxime Coquelin wrote:
> Add a MAINTAINER entry covering all STM32 machine and drivers files.
> 
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  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 <mcoquelin.stm32@gmail.com>
> +L:	linux-arm-kernel@lists.infradead.org (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 <kernel@wantstofly.org>
>  L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> 

Applied to next/soc, thanks!

	Arnd

Re: [PATCH v8 16/16] MAINTAINERS: Add entry for STM32 MCUs

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:58 Maxime Coquelin wrote:
> Add a MAINTAINER entry covering all STM32 machine and drivers files.
> 
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  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 <mcoquelin.stm32@gmail.com>
> +L:	linux-arm-kernel@lists.infradead.org (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 <kernel@wantstofly.org>
>  L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> 

Applied to next/soc, thanks!

	Arnd

[PATCH v8 16/16] MAINTAINERS: Add entry for STM32 MCUs

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:58 Maxime Coquelin wrote:
> Add a MAINTAINER entry covering all STM32 machine and drivers files.
> 
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  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 <mcoquelin.stm32@gmail.com>
> +L:	linux-arm-kernel at lists.infradead.org (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 <kernel@wantstofly.org>
>  L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> 

Applied to next/soc, thanks!

	Arnd

Re: [PATCH v8 13/16] ARM: dts: Add ARM System timer as clocksource in armv7m

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:55 Maxime Coquelin wrote:
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  arch/arm/boot/dts/armv7-m.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Applied to next/dt. I've left out patch 14 for now, until we have a new version.

	Arnd

Re: [PATCH v8 13/16] ARM: dts: Add ARM System timer as clocksource in armv7m

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:55 Maxime Coquelin wrote:
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  arch/arm/boot/dts/armv7-m.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Applied to next/dt. I've left out patch 14 for now, until we have a new version.

	Arnd

[PATCH v8 13/16] ARM: dts: Add ARM System timer as clocksource in armv7m

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:55 Maxime Coquelin wrote:
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  arch/arm/boot/dts/armv7-m.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Applied to next/dt. I've left out patch 14 for now, until we have a new version.

	Arnd

Re: [PATCH v8 15/16] ARM: configs: Add STM32 defconfig

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:57 Maxime Coquelin wrote:
> This patch adds a new config for STM32 MCUs.
> STM32F429 Discovery board boots successfully with this config applied.
> 
> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 

Applied to next/defconfig, thanks!

	Arnd

Re: [PATCH v8 15/16] ARM: configs: Add STM32 defconfig

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:57 Maxime Coquelin wrote:
> This patch adds a new config for STM32 MCUs.
> STM32F429 Discovery board boots successfully with this config applied.
> 
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> 

Applied to next/defconfig, thanks!

	Arnd

[PATCH v8 15/16] ARM: configs: Add STM32 defconfig

[Arnd Bergmann]

On Saturday 09 May 2015 09:53:57 Maxime Coquelin wrote:
> This patch adds a new config for STM32 MCUs.
> STM32F429 Discovery board boots successfully with this config applied.
> 
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> 

Applied to next/defconfig, thanks!

	Arnd

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Maxime Coquelin]

Hi Michal,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> When Kernel is executed in place from ROM, the symbol addresses can be
> lower than the page offset.
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  scripts/link-vmlinux.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index 86a4fe7..b055d9d 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -82,7 +82,7 @@ kallsyms()
>                 kallsymopt="${kallsymopt} --all-symbols"
>         fi
>
> -       if [ -n "${CONFIG_ARM}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
> +       if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
>                 kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
>         fi
>
> --
> 1.9.1
>

The get_maintainer.pl does not explicitly provide your name as
maintainer for this file.
But looking at MAINTAINERS file, I think you are the one for it.

Do you confirm?
If this is the case and you agree with the patch, could you consider
taking it for v4.2?

Thanks in advance,
Maxime

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Maxime Coquelin]

Hi Michal,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> When Kernel is executed in place from ROM, the symbol addresses can be
> lower than the page offset.
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  scripts/link-vmlinux.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index 86a4fe7..b055d9d 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -82,7 +82,7 @@ kallsyms()
>                 kallsymopt="${kallsymopt} --all-symbols"
>         fi
>
> -       if [ -n "${CONFIG_ARM}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
> +       if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
>                 kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
>         fi
>
> --
> 1.9.1
>

The get_maintainer.pl does not explicitly provide your name as
maintainer for this file.
But looking at MAINTAINERS file, I think you are the one for it.

Do you confirm?
If this is the case and you agree with the patch, could you consider
taking it for v4.2?

Thanks in advance,
Maxime

[PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Maxime Coquelin]

Hi Michal,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> When Kernel is executed in place from ROM, the symbol addresses can be
> lower than the page offset.
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  scripts/link-vmlinux.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index 86a4fe7..b055d9d 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -82,7 +82,7 @@ kallsyms()
>                 kallsymopt="${kallsymopt} --all-symbols"
>         fi
>
> -       if [ -n "${CONFIG_ARM}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
> +       if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
>                 kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
>         fi
>
> --
> 1.9.1
>

The get_maintainer.pl does not explicitly provide your name as
maintainer for this file.
But looking at MAINTAINERS file, I think you are the one for it.

Do you confirm?
If this is the case and you agree with the patch, could you consider
taking it for v4.2?

Thanks in advance,
Maxime

Re: [PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

Hi Daniel,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> This patch adds clocksource support for ARMv7-M's System timer,
> also known as SysTick.
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/clocksource/Kconfig          |  7 ++++
>  drivers/clocksource/Makefile         |  1 +
>  drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 87 insertions(+)
>  create mode 100644 drivers/clocksource/armv7m_systick.c
>

Could you consider applying this patch and its dt-bindings
documentation (patch 3/16) on your tree for v4.2?

Thanks in advance,
Maxime

Re: [PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

Hi Daniel,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> This patch adds clocksource support for ARMv7-M's System timer,
> also known as SysTick.
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/clocksource/Kconfig          |  7 ++++
>  drivers/clocksource/Makefile         |  1 +
>  drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 87 insertions(+)
>  create mode 100644 drivers/clocksource/armv7m_systick.c
>

Could you consider applying this patch and its dt-bindings
documentation (patch 3/16) on your tree for v4.2?

Thanks in advance,
Maxime

Re: [PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

Hi Daniel,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> This patch adds clocksource support for ARMv7-M's System timer,
> also known as SysTick.
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/clocksource/Kconfig          |  7 ++++
>  drivers/clocksource/Makefile         |  1 +
>  drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 87 insertions(+)
>  create mode 100644 drivers/clocksource/armv7m_systick.c
>

Could you consider applying this patch and its dt-bindings
documentation (patch 3/16) on your tree for v4.2?

Thanks in advance,
Maxime

[PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

Hi Daniel,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> This patch adds clocksource support for ARMv7-M's System timer,
> also known as SysTick.
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/clocksource/Kconfig          |  7 ++++
>  drivers/clocksource/Makefile         |  1 +
>  drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 87 insertions(+)
>  create mode 100644 drivers/clocksource/armv7m_systick.c
>

Could you consider applying this patch and its dt-bindings
documentation (patch 3/16) on your tree for v4.2?

Thanks in advance,
Maxime

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

Hi Arnd, Daniel,

2015-05-13 18:54 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>>> >>
>>> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
>>> >> we would need in the middle column).
>>> >
>>> > We don't normally use register offsets in DT. The number 8 here instead
>>> > would indicate block 8, where each block is four bytes wide. Using the
>>> > same index here for reset and clock would also help readability.
>>>
>>> My view is that it makes the bindings usage very complex.
>>> Also, it implies we have a specific compatible for stm32f429, whereas
>>> we didn't need with my earlier proposals.
>>> Indeed, the reset driver will need to know the offset of every reset
>>> registers, because:
>>>   1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>>   2. The APB registers start at RCC offset 0x20 (up to 0x24).
>>> We have a gap between AHB and APB registers, so how do we map the
>>> index for the block you propose?
>>> Should the gap be considered as a block, or we should skip it?
>>>
>>> I'm afraid it will not be straightforward for a reset user to
>>> understand how to use this bindings.
>>>
>>> Either my v7 or v8 versions would have made possible to use a single
>>> compatible for STM32 series.
>>> If we stick with one of these, we could even think to have a "generic"
>>> reset driver, as it could be compatible with sunxi driver bindings.
>>
>> We should definitely try to use the same compatible string for all of
>> them, and make a binding that is easy to use.
>>
>> I haven't fully understood the requirements for the various parts that
>> are involved here. My understanding so far was that the driver could
>> use the index from the first cell and compute
>>
>>         void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>         void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
>
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
>
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?
>
>>
>> Are there parts that need something else? If the 0x10 offset is
>> different, we probably want a different compatible string, and I'd
>> consider it a different part at that point. If there are chips
>> that do not spread the clock from the reset by exactly 256 bits,
>> we could add a DT property in the rcc node for that.
>
> I will check other chips, to see if this is valid generally.

I checked on other chips, and the assumption looks valid generally.

Kind regards,
Maxime

>
> Thanks for your feedback,
> Maxime
>
>>
>>         Arnd

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

Hi Arnd, Daniel,

2015-05-13 18:54 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>>> >>
>>> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
>>> >> we would need in the middle column).
>>> >
>>> > We don't normally use register offsets in DT. The number 8 here instead
>>> > would indicate block 8, where each block is four bytes wide. Using the
>>> > same index here for reset and clock would also help readability.
>>>
>>> My view is that it makes the bindings usage very complex.
>>> Also, it implies we have a specific compatible for stm32f429, whereas
>>> we didn't need with my earlier proposals.
>>> Indeed, the reset driver will need to know the offset of every reset
>>> registers, because:
>>>   1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>>   2. The APB registers start at RCC offset 0x20 (up to 0x24).
>>> We have a gap between AHB and APB registers, so how do we map the
>>> index for the block you propose?
>>> Should the gap be considered as a block, or we should skip it?
>>>
>>> I'm afraid it will not be straightforward for a reset user to
>>> understand how to use this bindings.
>>>
>>> Either my v7 or v8 versions would have made possible to use a single
>>> compatible for STM32 series.
>>> If we stick with one of these, we could even think to have a "generic"
>>> reset driver, as it could be compatible with sunxi driver bindings.
>>
>> We should definitely try to use the same compatible string for all of
>> them, and make a binding that is easy to use.
>>
>> I haven't fully understood the requirements for the various parts that
>> are involved here. My understanding so far was that the driver could
>> use the index from the first cell and compute
>>
>>         void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>         void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
>
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
>
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?
>
>>
>> Are there parts that need something else? If the 0x10 offset is
>> different, we probably want a different compatible string, and I'd
>> consider it a different part at that point. If there are chips
>> that do not spread the clock from the reset by exactly 256 bits,
>> we could add a DT property in the rcc node for that.
>
> I will check other chips, to see if this is valid generally.

I checked on other chips, and the assumption looks valid generally.

Kind regards,
Maxime

>
> Thanks for your feedback,
> Maxime
>
>>
>>         Arnd

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

Hi Arnd, Daniel,

2015-05-13 18:54 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> 2015-05-13 18:37 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wednesday 13 May 2015 18:29:05 Maxime Coquelin wrote:
>>> 2015-05-13 17:28 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>> > On Wednesday 13 May 2015 16:20:34 Daniel Thompson wrote:
>>> >>
>>> >> That would suit me very well (although is the 0x20/0x40 not the 8 that
>>> >> we would need in the middle column).
>>> >
>>> > We don't normally use register offsets in DT. The number 8 here instead
>>> > would indicate block 8, where each block is four bytes wide. Using the
>>> > same index here for reset and clock would also help readability.
>>>
>>> My view is that it makes the bindings usage very complex.
>>> Also, it implies we have a specific compatible for stm32f429, whereas
>>> we didn't need with my earlier proposals.
>>> Indeed, the reset driver will need to know the offset of every reset
>>> registers, because:
>>>   1. The AHB registers start at RCC offset 0x10 (up to 0x18)
>>>   2. The APB registers start at RCC offset 0x20 (up to 0x24).
>>> We have a gap between AHB and APB registers, so how do we map the
>>> index for the block you propose?
>>> Should the gap be considered as a block, or we should skip it?
>>>
>>> I'm afraid it will not be straightforward for a reset user to
>>> understand how to use this bindings.
>>>
>>> Either my v7 or v8 versions would have made possible to use a single
>>> compatible for STM32 series.
>>> If we stick with one of these, we could even think to have a "generic"
>>> reset driver, as it could be compatible with sunxi driver bindings.
>>
>> We should definitely try to use the same compatible string for all of
>> them, and make a binding that is easy to use.
>>
>> I haven't fully understood the requirements for the various parts that
>> are involved here. My understanding so far was that the driver could
>> use the index from the first cell and compute
>>
>>         void __iomem *reset_reg = rcc_base + 0x10 + 4 * index;
>>         void __iomem *clock_reg = rcc_base + 0x30 + 4 * index;
>
> This calculation is true, but we have to take into account there is a
> hole in the middle, between AHB3, and APB1 register:
>
> AHB1RSTR : offset = 0x10, index = 0
> AHB2RSTR : offset = 0x14, index = 1
> AHB3RSTR : offset = 0x18, index = 2
> <HOLE >     : offset = 0x1c, index = 3
> APB1RSTR : offset = 0x20, index = 4
> APB2RSTR : offset = 0x24, index = 5
>
> So we have to carefully document this hole in the bindings, maybe by
> listing indexes in the documentation?
>
>>
>> Are there parts that need something else? If the 0x10 offset is
>> different, we probably want a different compatible string, and I'd
>> consider it a different part at that point. If there are chips
>> that do not spread the clock from the reset by exactly 256 bits,
>> we could add a DT property in the rcc node for that.
>
> I will check other chips, to see if this is valid generally.

I checked on other chips, and the assumption looks valid generally.

Kind regards,
Maxime

>
> Thanks for your feedback,
> Maxime
>
>>
>>         Arnd

Re: [PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Daniel Lezcano]

On 05/18/2015 01:55 PM, Maxime Coquelin wrote:
> Hi Daniel,
>
> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> This patch adds clocksource support for ARMv7-M's System timer,
>> also known as SysTick.
>>
>> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Acked-by: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>>   drivers/clocksource/Kconfig          |  7 ++++
>>   drivers/clocksource/Makefile         |  1 +
>>   drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
>>   3 files changed, 87 insertions(+)
>>   create mode 100644 drivers/clocksource/armv7m_systick.c
>>
>
> Could you consider applying this patch and its dt-bindings
> documentation (patch 3/16) on your tree for v4.2?

Patches applied for 4.2.

Thanks

   -- Daniel

-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Daniel Lezcano]

On 05/18/2015 01:55 PM, Maxime Coquelin wrote:
> Hi Daniel,
>
> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>> This patch adds clocksource support for ARMv7-M's System timer,
>> also known as SysTick.
>>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>>   drivers/clocksource/Kconfig          |  7 ++++
>>   drivers/clocksource/Makefile         |  1 +
>>   drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
>>   3 files changed, 87 insertions(+)
>>   create mode 100644 drivers/clocksource/armv7m_systick.c
>>
>
> Could you consider applying this patch and its dt-bindings
> documentation (patch 3/16) on your tree for v4.2?

Patches applied for 4.2.

Thanks

   -- Daniel

-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Daniel Lezcano]

On 05/18/2015 01:55 PM, Maxime Coquelin wrote:
> Hi Daniel,
>
> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>> This patch adds clocksource support for ARMv7-M's System timer,
>> also known as SysTick.
>>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>>   drivers/clocksource/Kconfig          |  7 ++++
>>   drivers/clocksource/Makefile         |  1 +
>>   drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
>>   3 files changed, 87 insertions(+)
>>   create mode 100644 drivers/clocksource/armv7m_systick.c
>>
>
> Could you consider applying this patch and its dt-bindings
> documentation (patch 3/16) on your tree for v4.2?

Patches applied for 4.2.

Thanks

   -- Daniel

-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Daniel Lezcano]

On 05/18/2015 01:55 PM, Maxime Coquelin wrote:
> Hi Daniel,
>
> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>> This patch adds clocksource support for ARMv7-M's System timer,
>> also known as SysTick.
>>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>>   drivers/clocksource/Kconfig          |  7 ++++
>>   drivers/clocksource/Makefile         |  1 +
>>   drivers/clocksource/armv7m_systick.c | 79 ++++++++++++++++++++++++++++++++++++
>>   3 files changed, 87 insertions(+)
>>   create mode 100644 drivers/clocksource/armv7m_systick.c
>>
>
> Could you consider applying this patch and its dt-bindings
> documentation (patch 3/16) on your tree for v4.2?

Patches applied for 4.2.

Thanks

   -- Daniel

-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

2015-05-18 14:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/18/2015 01:55 PM, Maxime Coquelin wrote:
>>
>> Hi Daniel,
>>
>> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>>>
>>> This patch adds clocksource support for ARMv7-M's System timer,
>>> also known as SysTick.
>>>
>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>> ---
>>>   drivers/clocksource/Kconfig          |  7 ++++
>>>   drivers/clocksource/Makefile         |  1 +
>>>   drivers/clocksource/armv7m_systick.c | 79
>>> ++++++++++++++++++++++++++++++++++++
>>>   3 files changed, 87 insertions(+)
>>>   create mode 100644 drivers/clocksource/armv7m_systick.c
>>>
>>
>> Could you consider applying this patch and its dt-bindings
>> documentation (patch 3/16) on your tree for v4.2?
>
>
> Patches applied for 4.2.

Thanks Daniel!

>
> Thanks
>
>   -- Daniel
>
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

Re: [PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

2015-05-18 14:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/18/2015 01:55 PM, Maxime Coquelin wrote:
>>
>> Hi Daniel,
>>
>> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>>>
>>> This patch adds clocksource support for ARMv7-M's System timer,
>>> also known as SysTick.
>>>
>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>> ---
>>>   drivers/clocksource/Kconfig          |  7 ++++
>>>   drivers/clocksource/Makefile         |  1 +
>>>   drivers/clocksource/armv7m_systick.c | 79
>>> ++++++++++++++++++++++++++++++++++++
>>>   3 files changed, 87 insertions(+)
>>>   create mode 100644 drivers/clocksource/armv7m_systick.c
>>>
>>
>> Could you consider applying this patch and its dt-bindings
>> documentation (patch 3/16) on your tree for v4.2?
>
>
> Patches applied for 4.2.

Thanks Daniel!

>
> Thanks
>
>   -- Daniel
>
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

[PATCH v8 04/16] clocksource/drivers: Add ARM System timer driver

[Maxime Coquelin]

2015-05-18 14:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/18/2015 01:55 PM, Maxime Coquelin wrote:
>>
>> Hi Daniel,
>>
>> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>>>
>>> This patch adds clocksource support for ARMv7-M's System timer,
>>> also known as SysTick.
>>>
>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>> ---
>>>   drivers/clocksource/Kconfig          |  7 ++++
>>>   drivers/clocksource/Makefile         |  1 +
>>>   drivers/clocksource/armv7m_systick.c | 79
>>> ++++++++++++++++++++++++++++++++++++
>>>   3 files changed, 87 insertions(+)
>>>   create mode 100644 drivers/clocksource/armv7m_systick.c
>>>
>>
>> Could you consider applying this patch and its dt-bindings
>> documentation (patch 3/16) on your tree for v4.2?
>
>
> Patches applied for 4.2.

Thanks Daniel!

>
> Thanks
>
>   -- Daniel
>
> --
>  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

Daniel,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> 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 <linus.walleij@linaro.org>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  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
>

I forgot to as you to also pick this one an its documentation (patch 8).

Best regards,
Maxime

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

Daniel,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> 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 <linus.walleij@linaro.org>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  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
>

I forgot to as you to also pick this one an its documentation (patch 8).

Best regards,
Maxime

Re: [PATCH v8 11/16] serial: stm32-usart: Add STM32 USART Driver

[Maxime Coquelin]

Hi Greg,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> This drivers adds support to the STM32 USART controller, which is a
> standard serial driver.
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/tty/serial/Kconfig       |  17 +
>  drivers/tty/serial/Makefile      |   1 +
>  drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/serial_core.h |   3 +
>  4 files changed, 760 insertions(+)
>  create mode 100644 drivers/tty/serial/stm32-usart.c
>

Could you consider applying this patch and the one documenting its DT
bindings (patch 10/16) to your tree for 4.2?

Thanks in advance,
Maxime

[PATCH v8 11/16] serial: stm32-usart: Add STM32 USART Driver

[Maxime Coquelin]

Hi Greg,

2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
> This drivers adds support to the STM32 USART controller, which is a
> standard serial driver.
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/tty/serial/Kconfig       |  17 +
>  drivers/tty/serial/Makefile      |   1 +
>  drivers/tty/serial/stm32-usart.c | 739 +++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/serial_core.h |   3 +
>  4 files changed, 760 insertions(+)
>  create mode 100644 drivers/tty/serial/stm32-usart.c
>

Could you consider applying this patch and the one documenting its DT
bindings (patch 10/16) to your tree for 4.2?

Thanks in advance,
Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
> The drivers detects whether the time is 16 or 32 bits, and applies a
> 1024 prescaler value if it is 16 bits.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>   drivers/clocksource/Kconfig       |   8 ++
>   drivers/clocksource/Makefile      |   1 +
>   drivers/clocksource/timer-stm32.c | 184 ++++++++++++++++++++++++++++++++++++++
>   3 files changed, 193 insertions(+)
>   create mode 100644 drivers/clocksource/timer-stm32.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index bf9364c..2443520 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>   	  Support to use the timers of EFM32 SoCs as clock source and clock
>   	  event device.
>
> +config CLKSRC_STM32
> +	bool "Clocksource for STM32 SoCs" if !ARCH_STM32
> +	depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)

Are the interactive bool and the 'COMPILE_TEST' necessary ?


> +	select CLKSRC_MMIO
> +	default ARCH_STM32
> +	help
> +	  Support to use the timers of STM32 SoCs as clock event device.
> +
>   config ARM_ARCH_TIMER
>   	bool
>   	select CLKSRC_OF if OF
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index d510c54..888a7df 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_ARCH_NSPIRE)	+= zevio-timer.o
>   obj-$(CONFIG_ARCH_BCM_MOBILE)	+= bcm_kona_timer.o
>   obj-$(CONFIG_CADENCE_TTC_TIMER)	+= cadence_ttc_timer.o
>   obj-$(CONFIG_CLKSRC_EFM32)	+= time-efm32.o
> +obj-$(CONFIG_CLKSRC_STM32)	+= timer-stm32.o
>   obj-$(CONFIG_CLKSRC_EXYNOS_MCT)	+= exynos_mct.o
>   obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)	+= samsung_pwm_timer.o
>   obj-$(CONFIG_FSL_FTM_TIMER)	+= fsl_ftm_timer.o
> diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
> new file mode 100644
> index 0000000..fad2e2e
> --- /dev/null
> +++ b/drivers/clocksource/timer-stm32.c
> @@ -0,0 +1,184 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author:  Maxime Coquelin <mcoquelin.stm32@gmail.com>
> + * License terms:  GNU General Public License (GPL), version 2
> + *
> + * Inspired by time-efm32.c from Uwe Kleine-Koenig
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/clocksource.h>
> +#include <linux/clockchips.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +
> +#define TIM_CR1		0x00
> +#define TIM_DIER	0x0c
> +#define TIM_SR		0x10
> +#define TIM_EGR		0x14
> +#define TIM_PSC		0x28
> +#define TIM_ARR		0x2c
> +
> +#define TIM_CR1_CEN	BIT(0)
> +#define TIM_CR1_OPM	BIT(3)
> +#define TIM_CR1_ARPE	BIT(7)
> +
> +#define TIM_DIER_UIE	BIT(0)
> +
> +#define TIM_SR_UIF	BIT(0)
> +
> +#define TIM_EGR_UG	BIT(0)
> +
> +struct stm32_clock_event_ddata {
> +	struct clock_event_device evtdev;
> +	unsigned periodic_top;
> +	void __iomem *base;
> +};
> +
> +static void stm32_clock_event_set_mode(enum clock_event_mode mode,
> +				       struct clock_event_device *evtdev)
> +{
> +	struct stm32_clock_event_ddata *data =
> +		container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> +	void *base = data->base;
> +
> +	switch (mode) {
> +	case CLOCK_EVT_MODE_PERIODIC:
> +		writel_relaxed(data->periodic_top, base + TIM_ARR);
> +		writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, base + TIM_CR1);
> +		break;
> +
> +	case CLOCK_EVT_MODE_ONESHOT:
> +	default:
> +		writel_relaxed(0, base + TIM_CR1);
> +		break;
> +	}
> +}
> +
> +static int stm32_clock_event_set_next_event(unsigned long evt,
> +					    struct clock_event_device *evtdev)
> +{
> +	struct stm32_clock_event_ddata *data =
> +		container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> +
> +	writel_relaxed(evt, data->base + TIM_ARR);
> +	writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
> +		       data->base + TIM_CR1);
> +
> +	return 0;
> +}
> +
> +static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
> +{
> +	struct stm32_clock_event_ddata *data = dev_id;
> +
> +	writel_relaxed(0, data->base + TIM_SR);
> +
> +	data->evtdev.event_handler(&data->evtdev);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static struct stm32_clock_event_ddata clock_event_ddata = {
> +	.evtdev = {
> +		.name = "stm32 clockevent",
> +		.features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
> +		.set_mode = stm32_clock_event_set_mode,
> +		.set_next_event = stm32_clock_event_set_next_event,
> +		.rating = 200,
> +	},
> +};
> +
> +static void __init stm32_clockevent_init(struct device_node *np)
> +{
> +	struct stm32_clock_event_ddata *data = &clock_event_ddata;
> +	struct clk *clk;
> +	struct reset_control *rstc;
> +	unsigned long rate, max_delta;
> +	int irq, ret, bits, prescaler = 1;
> +
> +	clk = of_clk_get(np, 0);
> +	if (IS_ERR(clk)) {
> +		ret = PTR_ERR(clk);
> +		pr_err("failed to get clock for clockevent (%d)\n", ret);
> +		goto err_clk_get;
> +	}
> +
> +	ret = clk_prepare_enable(clk);
> +	if (ret) {
> +		pr_err("failed to enable timer clock for clockevent (%d)\n",
> +		       ret);
> +		goto err_clk_enable;
> +	}
> +
> +	rate = clk_get_rate(clk);
> +
> +	rstc = of_reset_control_get(np, NULL);
> +	if (!IS_ERR(rstc)) {
> +		reset_control_assert(rstc);
> +		reset_control_deassert(rstc);
> +	}
> +
> +	data->base = of_iomap(np, 0);
> +	if (!data->base) {
> +		pr_err("failed to map registers for clockevent\n");
> +		goto err_iomap;
> +	}
> +
> +	irq = irq_of_parse_and_map(np, 0);
> +	if (!irq) {
> +		pr_err("%s: failed to get irq.\n", np->full_name);
> +		goto err_get_irq;
> +	}
> +
> +	/* Detect whether the timer is 16 or 32 bits */
> +	writel_relaxed(~0UL, data->base + TIM_ARR);
> +	max_delta = readl_relaxed(data->base + TIM_ARR);
> +	if (max_delta == ~0UL) {
> +		prescaler = 1;
> +		bits = 32;
> +	} else {
> +		prescaler = 1024;
> +		bits = 16;
> +	}
> +	writel_relaxed(0, data->base + TIM_ARR);
> +
> +	writel_relaxed(prescaler - 1, data->base + TIM_PSC);
> +	writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
> +	writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
> +	writel_relaxed(0, data->base + TIM_SR);
> +
> +	data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
> +
> +	clockevents_config_and_register(&data->evtdev,
> +					DIV_ROUND_CLOSEST(rate, prescaler),
> +					0x1, max_delta);
> +
> +	ret = request_irq(irq, stm32_clock_event_handler, IRQF_TIMER,
> +			"stm32 clockevent", data);
> +	if (ret) {
> +		pr_err("%s: failed to request irq.\n", np->full_name);
> +		goto err_get_irq;
> +	}
> +
> +	pr_info("%s: STM32 clockevent driver initialized (%d bits)\n",
> +			np->full_name, bits);
> +
> +	return;
> +
> +err_get_irq:
> +	iounmap(data->base);
> +err_iomap:
> +	clk_disable_unprepare(clk);
> +err_clk_enable:
> +	clk_put(clk);
> +err_clk_get:
> +	return;
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
> The drivers detects whether the time is 16 or 32 bits, and applies a
> 1024 prescaler value if it is 16 bits.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>   drivers/clocksource/Kconfig       |   8 ++
>   drivers/clocksource/Makefile      |   1 +
>   drivers/clocksource/timer-stm32.c | 184 ++++++++++++++++++++++++++++++++++++++
>   3 files changed, 193 insertions(+)
>   create mode 100644 drivers/clocksource/timer-stm32.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index bf9364c..2443520 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>   	  Support to use the timers of EFM32 SoCs as clock source and clock
>   	  event device.
>
> +config CLKSRC_STM32
> +	bool "Clocksource for STM32 SoCs" if !ARCH_STM32
> +	depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)

Are the interactive bool and the 'COMPILE_TEST' necessary ?


> +	select CLKSRC_MMIO
> +	default ARCH_STM32
> +	help
> +	  Support to use the timers of STM32 SoCs as clock event device.
> +
>   config ARM_ARCH_TIMER
>   	bool
>   	select CLKSRC_OF if OF
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index d510c54..888a7df 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_ARCH_NSPIRE)	+= zevio-timer.o
>   obj-$(CONFIG_ARCH_BCM_MOBILE)	+= bcm_kona_timer.o
>   obj-$(CONFIG_CADENCE_TTC_TIMER)	+= cadence_ttc_timer.o
>   obj-$(CONFIG_CLKSRC_EFM32)	+= time-efm32.o
> +obj-$(CONFIG_CLKSRC_STM32)	+= timer-stm32.o
>   obj-$(CONFIG_CLKSRC_EXYNOS_MCT)	+= exynos_mct.o
>   obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)	+= samsung_pwm_timer.o
>   obj-$(CONFIG_FSL_FTM_TIMER)	+= fsl_ftm_timer.o
> diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
> new file mode 100644
> index 0000000..fad2e2e
> --- /dev/null
> +++ b/drivers/clocksource/timer-stm32.c
> @@ -0,0 +1,184 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author:  Maxime Coquelin <mcoquelin.stm32@gmail.com>
> + * License terms:  GNU General Public License (GPL), version 2
> + *
> + * Inspired by time-efm32.c from Uwe Kleine-Koenig
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/clocksource.h>
> +#include <linux/clockchips.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +
> +#define TIM_CR1		0x00
> +#define TIM_DIER	0x0c
> +#define TIM_SR		0x10
> +#define TIM_EGR		0x14
> +#define TIM_PSC		0x28
> +#define TIM_ARR		0x2c
> +
> +#define TIM_CR1_CEN	BIT(0)
> +#define TIM_CR1_OPM	BIT(3)
> +#define TIM_CR1_ARPE	BIT(7)
> +
> +#define TIM_DIER_UIE	BIT(0)
> +
> +#define TIM_SR_UIF	BIT(0)
> +
> +#define TIM_EGR_UG	BIT(0)
> +
> +struct stm32_clock_event_ddata {
> +	struct clock_event_device evtdev;
> +	unsigned periodic_top;
> +	void __iomem *base;
> +};
> +
> +static void stm32_clock_event_set_mode(enum clock_event_mode mode,
> +				       struct clock_event_device *evtdev)
> +{
> +	struct stm32_clock_event_ddata *data =
> +		container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> +	void *base = data->base;
> +
> +	switch (mode) {
> +	case CLOCK_EVT_MODE_PERIODIC:
> +		writel_relaxed(data->periodic_top, base + TIM_ARR);
> +		writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, base + TIM_CR1);
> +		break;
> +
> +	case CLOCK_EVT_MODE_ONESHOT:
> +	default:
> +		writel_relaxed(0, base + TIM_CR1);
> +		break;
> +	}
> +}
> +
> +static int stm32_clock_event_set_next_event(unsigned long evt,
> +					    struct clock_event_device *evtdev)
> +{
> +	struct stm32_clock_event_ddata *data =
> +		container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> +
> +	writel_relaxed(evt, data->base + TIM_ARR);
> +	writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
> +		       data->base + TIM_CR1);
> +
> +	return 0;
> +}
> +
> +static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
> +{
> +	struct stm32_clock_event_ddata *data = dev_id;
> +
> +	writel_relaxed(0, data->base + TIM_SR);
> +
> +	data->evtdev.event_handler(&data->evtdev);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static struct stm32_clock_event_ddata clock_event_ddata = {
> +	.evtdev = {
> +		.name = "stm32 clockevent",
> +		.features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
> +		.set_mode = stm32_clock_event_set_mode,
> +		.set_next_event = stm32_clock_event_set_next_event,
> +		.rating = 200,
> +	},
> +};
> +
> +static void __init stm32_clockevent_init(struct device_node *np)
> +{
> +	struct stm32_clock_event_ddata *data = &clock_event_ddata;
> +	struct clk *clk;
> +	struct reset_control *rstc;
> +	unsigned long rate, max_delta;
> +	int irq, ret, bits, prescaler = 1;
> +
> +	clk = of_clk_get(np, 0);
> +	if (IS_ERR(clk)) {
> +		ret = PTR_ERR(clk);
> +		pr_err("failed to get clock for clockevent (%d)\n", ret);
> +		goto err_clk_get;
> +	}
> +
> +	ret = clk_prepare_enable(clk);
> +	if (ret) {
> +		pr_err("failed to enable timer clock for clockevent (%d)\n",
> +		       ret);
> +		goto err_clk_enable;
> +	}
> +
> +	rate = clk_get_rate(clk);
> +
> +	rstc = of_reset_control_get(np, NULL);
> +	if (!IS_ERR(rstc)) {
> +		reset_control_assert(rstc);
> +		reset_control_deassert(rstc);
> +	}
> +
> +	data->base = of_iomap(np, 0);
> +	if (!data->base) {
> +		pr_err("failed to map registers for clockevent\n");
> +		goto err_iomap;
> +	}
> +
> +	irq = irq_of_parse_and_map(np, 0);
> +	if (!irq) {
> +		pr_err("%s: failed to get irq.\n", np->full_name);
> +		goto err_get_irq;
> +	}
> +
> +	/* Detect whether the timer is 16 or 32 bits */
> +	writel_relaxed(~0UL, data->base + TIM_ARR);
> +	max_delta = readl_relaxed(data->base + TIM_ARR);
> +	if (max_delta == ~0UL) {
> +		prescaler = 1;
> +		bits = 32;
> +	} else {
> +		prescaler = 1024;
> +		bits = 16;
> +	}
> +	writel_relaxed(0, data->base + TIM_ARR);
> +
> +	writel_relaxed(prescaler - 1, data->base + TIM_PSC);
> +	writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
> +	writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
> +	writel_relaxed(0, data->base + TIM_SR);
> +
> +	data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
> +
> +	clockevents_config_and_register(&data->evtdev,
> +					DIV_ROUND_CLOSEST(rate, prescaler),
> +					0x1, max_delta);
> +
> +	ret = request_irq(irq, stm32_clock_event_handler, IRQF_TIMER,
> +			"stm32 clockevent", data);
> +	if (ret) {
> +		pr_err("%s: failed to request irq.\n", np->full_name);
> +		goto err_get_irq;
> +	}
> +
> +	pr_info("%s: STM32 clockevent driver initialized (%d bits)\n",
> +			np->full_name, bits);
> +
> +	return;
> +
> +err_get_irq:
> +	iounmap(data->base);
> +err_iomap:
> +	clk_disable_unprepare(clk);
> +err_clk_enable:
> +	clk_put(clk);
> +err_clk_get:
> +	return;
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
> The drivers detects whether the time is 16 or 32 bits, and applies a
> 1024 prescaler value if it is 16 bits.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>   drivers/clocksource/Kconfig       |   8 ++
>   drivers/clocksource/Makefile      |   1 +
>   drivers/clocksource/timer-stm32.c | 184 ++++++++++++++++++++++++++++++++++++++
>   3 files changed, 193 insertions(+)
>   create mode 100644 drivers/clocksource/timer-stm32.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index bf9364c..2443520 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>   	  Support to use the timers of EFM32 SoCs as clock source and clock
>   	  event device.
>
> +config CLKSRC_STM32
> +	bool "Clocksource for STM32 SoCs" if !ARCH_STM32
> +	depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)

Are the interactive bool and the 'COMPILE_TEST' necessary ?


> +	select CLKSRC_MMIO
> +	default ARCH_STM32
> +	help
> +	  Support to use the timers of STM32 SoCs as clock event device.
> +
>   config ARM_ARCH_TIMER
>   	bool
>   	select CLKSRC_OF if OF
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index d510c54..888a7df 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_ARCH_NSPIRE)	+= zevio-timer.o
>   obj-$(CONFIG_ARCH_BCM_MOBILE)	+= bcm_kona_timer.o
>   obj-$(CONFIG_CADENCE_TTC_TIMER)	+= cadence_ttc_timer.o
>   obj-$(CONFIG_CLKSRC_EFM32)	+= time-efm32.o
> +obj-$(CONFIG_CLKSRC_STM32)	+= timer-stm32.o
>   obj-$(CONFIG_CLKSRC_EXYNOS_MCT)	+= exynos_mct.o
>   obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)	+= samsung_pwm_timer.o
>   obj-$(CONFIG_FSL_FTM_TIMER)	+= fsl_ftm_timer.o
> diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
> new file mode 100644
> index 0000000..fad2e2e
> --- /dev/null
> +++ b/drivers/clocksource/timer-stm32.c
> @@ -0,0 +1,184 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author:  Maxime Coquelin <mcoquelin.stm32@gmail.com>
> + * License terms:  GNU General Public License (GPL), version 2
> + *
> + * Inspired by time-efm32.c from Uwe Kleine-Koenig
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/clocksource.h>
> +#include <linux/clockchips.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +
> +#define TIM_CR1		0x00
> +#define TIM_DIER	0x0c
> +#define TIM_SR		0x10
> +#define TIM_EGR		0x14
> +#define TIM_PSC		0x28
> +#define TIM_ARR		0x2c
> +
> +#define TIM_CR1_CEN	BIT(0)
> +#define TIM_CR1_OPM	BIT(3)
> +#define TIM_CR1_ARPE	BIT(7)
> +
> +#define TIM_DIER_UIE	BIT(0)
> +
> +#define TIM_SR_UIF	BIT(0)
> +
> +#define TIM_EGR_UG	BIT(0)
> +
> +struct stm32_clock_event_ddata {
> +	struct clock_event_device evtdev;
> +	unsigned periodic_top;
> +	void __iomem *base;
> +};
> +
> +static void stm32_clock_event_set_mode(enum clock_event_mode mode,
> +				       struct clock_event_device *evtdev)
> +{
> +	struct stm32_clock_event_ddata *data =
> +		container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> +	void *base = data->base;
> +
> +	switch (mode) {
> +	case CLOCK_EVT_MODE_PERIODIC:
> +		writel_relaxed(data->periodic_top, base + TIM_ARR);
> +		writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, base + TIM_CR1);
> +		break;
> +
> +	case CLOCK_EVT_MODE_ONESHOT:
> +	default:
> +		writel_relaxed(0, base + TIM_CR1);
> +		break;
> +	}
> +}
> +
> +static int stm32_clock_event_set_next_event(unsigned long evt,
> +					    struct clock_event_device *evtdev)
> +{
> +	struct stm32_clock_event_ddata *data =
> +		container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> +
> +	writel_relaxed(evt, data->base + TIM_ARR);
> +	writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
> +		       data->base + TIM_CR1);
> +
> +	return 0;
> +}
> +
> +static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
> +{
> +	struct stm32_clock_event_ddata *data = dev_id;
> +
> +	writel_relaxed(0, data->base + TIM_SR);
> +
> +	data->evtdev.event_handler(&data->evtdev);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static struct stm32_clock_event_ddata clock_event_ddata = {
> +	.evtdev = {
> +		.name = "stm32 clockevent",
> +		.features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
> +		.set_mode = stm32_clock_event_set_mode,
> +		.set_next_event = stm32_clock_event_set_next_event,
> +		.rating = 200,
> +	},
> +};
> +
> +static void __init stm32_clockevent_init(struct device_node *np)
> +{
> +	struct stm32_clock_event_ddata *data = &clock_event_ddata;
> +	struct clk *clk;
> +	struct reset_control *rstc;
> +	unsigned long rate, max_delta;
> +	int irq, ret, bits, prescaler = 1;
> +
> +	clk = of_clk_get(np, 0);
> +	if (IS_ERR(clk)) {
> +		ret = PTR_ERR(clk);
> +		pr_err("failed to get clock for clockevent (%d)\n", ret);
> +		goto err_clk_get;
> +	}
> +
> +	ret = clk_prepare_enable(clk);
> +	if (ret) {
> +		pr_err("failed to enable timer clock for clockevent (%d)\n",
> +		       ret);
> +		goto err_clk_enable;
> +	}
> +
> +	rate = clk_get_rate(clk);
> +
> +	rstc = of_reset_control_get(np, NULL);
> +	if (!IS_ERR(rstc)) {
> +		reset_control_assert(rstc);
> +		reset_control_deassert(rstc);
> +	}
> +
> +	data->base = of_iomap(np, 0);
> +	if (!data->base) {
> +		pr_err("failed to map registers for clockevent\n");
> +		goto err_iomap;
> +	}
> +
> +	irq = irq_of_parse_and_map(np, 0);
> +	if (!irq) {
> +		pr_err("%s: failed to get irq.\n", np->full_name);
> +		goto err_get_irq;
> +	}
> +
> +	/* Detect whether the timer is 16 or 32 bits */
> +	writel_relaxed(~0UL, data->base + TIM_ARR);
> +	max_delta = readl_relaxed(data->base + TIM_ARR);
> +	if (max_delta == ~0UL) {
> +		prescaler = 1;
> +		bits = 32;
> +	} else {
> +		prescaler = 1024;
> +		bits = 16;
> +	}
> +	writel_relaxed(0, data->base + TIM_ARR);
> +
> +	writel_relaxed(prescaler - 1, data->base + TIM_PSC);
> +	writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
> +	writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
> +	writel_relaxed(0, data->base + TIM_SR);
> +
> +	data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
> +
> +	clockevents_config_and_register(&data->evtdev,
> +					DIV_ROUND_CLOSEST(rate, prescaler),
> +					0x1, max_delta);
> +
> +	ret = request_irq(irq, stm32_clock_event_handler, IRQF_TIMER,
> +			"stm32 clockevent", data);
> +	if (ret) {
> +		pr_err("%s: failed to request irq.\n", np->full_name);
> +		goto err_get_irq;
> +	}
> +
> +	pr_info("%s: STM32 clockevent driver initialized (%d bits)\n",
> +			np->full_name, bits);
> +
> +	return;
> +
> +err_get_irq:
> +	iounmap(data->base);
> +err_iomap:
> +	clk_disable_unprepare(clk);
> +err_clk_enable:
> +	clk_put(clk);
> +err_clk_get:
> +	return;
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
>


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>
>> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
>> The drivers detects whether the time is 16 or 32 bits, and applies a
>> 1024 prescaler value if it is 16 bits.
>>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>>   drivers/clocksource/Kconfig       |   8 ++
>>   drivers/clocksource/Makefile      |   1 +
>>   drivers/clocksource/timer-stm32.c | 184
>> ++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 193 insertions(+)
>>   create mode 100644 drivers/clocksource/timer-stm32.c
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index bf9364c..2443520 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>           Support to use the timers of EFM32 SoCs as clock source and
>> clock
>>           event device.
>>
>> +config CLKSRC_STM32
>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>
>
> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>

The interactive bool is necessary if we want to be able to
select/deselect it in COMPILE_TEST configuration.
And personnaly, I think COMPILE_TEST use makes sense.

Note that other timer drivers are doing the same thing today
(CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).

Do you have a specific concern regarding COMPILE_TEST?

Kind regards,
Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>
>> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
>> The drivers detects whether the time is 16 or 32 bits, and applies a
>> 1024 prescaler value if it is 16 bits.
>>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>>   drivers/clocksource/Kconfig       |   8 ++
>>   drivers/clocksource/Makefile      |   1 +
>>   drivers/clocksource/timer-stm32.c | 184
>> ++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 193 insertions(+)
>>   create mode 100644 drivers/clocksource/timer-stm32.c
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index bf9364c..2443520 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>           Support to use the timers of EFM32 SoCs as clock source and
>> clock
>>           event device.
>>
>> +config CLKSRC_STM32
>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>
>
> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>

The interactive bool is necessary if we want to be able to
select/deselect it in COMPILE_TEST configuration.
And personnaly, I think COMPILE_TEST use makes sense.

Note that other timer drivers are doing the same thing today
(CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).

Do you have a specific concern regarding COMPILE_TEST?

Kind regards,
Maxime

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>
>> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
>> The drivers detects whether the time is 16 or 32 bits, and applies a
>> 1024 prescaler value if it is 16 bits.
>>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>>   drivers/clocksource/Kconfig       |   8 ++
>>   drivers/clocksource/Makefile      |   1 +
>>   drivers/clocksource/timer-stm32.c | 184
>> ++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 193 insertions(+)
>>   create mode 100644 drivers/clocksource/timer-stm32.c
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index bf9364c..2443520 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>           Support to use the timers of EFM32 SoCs as clock source and
>> clock
>>           event device.
>>
>> +config CLKSRC_STM32
>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>
>
> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>

The interactive bool is necessary if we want to be able to
select/deselect it in COMPILE_TEST configuration.
And personnaly, I think COMPILE_TEST use makes sense.

Note that other timer drivers are doing the same thing today
(CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).

Do you have a specific concern regarding COMPILE_TEST?

Kind regards,
Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>
>>> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>> 1024 prescaler value if it is 16 bits.
>>>
>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>> ---
>>>    drivers/clocksource/Kconfig       |   8 ++
>>>    drivers/clocksource/Makefile      |   1 +
>>>    drivers/clocksource/timer-stm32.c | 184
>>> ++++++++++++++++++++++++++++++++++++++
>>>    3 files changed, 193 insertions(+)
>>>    create mode 100644 drivers/clocksource/timer-stm32.c
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index bf9364c..2443520 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>            Support to use the timers of EFM32 SoCs as clock source and
>>> clock
>>>            event device.
>>>
>>> +config CLKSRC_STM32
>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>
>>
>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>
>
> The interactive bool is necessary if we want to be able to
> select/deselect it in COMPILE_TEST configuration.
> And personnaly, I think COMPILE_TEST use makes sense.
>
> Note that other timer drivers are doing the same thing today
> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>
> Do you have a specific concern regarding COMPILE_TEST?

Actually, we try to keep the timer selection non-interactive and let the 
platform's Kconfig to select the timer.

I like when the code is consistent. The COMPILE_TEST was introduced and 
created a precedence. I would like to get rid of the interactive timer 
selection but I did not have time to go through this yet.


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>
>>> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>> 1024 prescaler value if it is 16 bits.
>>>
>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>> ---
>>>    drivers/clocksource/Kconfig       |   8 ++
>>>    drivers/clocksource/Makefile      |   1 +
>>>    drivers/clocksource/timer-stm32.c | 184
>>> ++++++++++++++++++++++++++++++++++++++
>>>    3 files changed, 193 insertions(+)
>>>    create mode 100644 drivers/clocksource/timer-stm32.c
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index bf9364c..2443520 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>            Support to use the timers of EFM32 SoCs as clock source and
>>> clock
>>>            event device.
>>>
>>> +config CLKSRC_STM32
>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>
>>
>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>
>
> The interactive bool is necessary if we want to be able to
> select/deselect it in COMPILE_TEST configuration.
> And personnaly, I think COMPILE_TEST use makes sense.
>
> Note that other timer drivers are doing the same thing today
> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>
> Do you have a specific concern regarding COMPILE_TEST?

Actually, we try to keep the timer selection non-interactive and let the 
platform's Kconfig to select the timer.

I like when the code is consistent. The COMPILE_TEST was introduced and 
created a precedence. I would like to get rid of the interactive timer 
selection but I did not have time to go through this yet.


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>
>>> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>> 1024 prescaler value if it is 16 bits.
>>>
>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>> ---
>>>    drivers/clocksource/Kconfig       |   8 ++
>>>    drivers/clocksource/Makefile      |   1 +
>>>    drivers/clocksource/timer-stm32.c | 184
>>> ++++++++++++++++++++++++++++++++++++++
>>>    3 files changed, 193 insertions(+)
>>>    create mode 100644 drivers/clocksource/timer-stm32.c
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index bf9364c..2443520 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>            Support to use the timers of EFM32 SoCs as clock source and
>>> clock
>>>            event device.
>>>
>>> +config CLKSRC_STM32
>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>
>>
>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>
>
> The interactive bool is necessary if we want to be able to
> select/deselect it in COMPILE_TEST configuration.
> And personnaly, I think COMPILE_TEST use makes sense.
>
> Note that other timer drivers are doing the same thing today
> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>
> Do you have a specific concern regarding COMPILE_TEST?

Actually, we try to keep the timer selection non-interactive and let the 
platform's Kconfig to select the timer.

I like when the code is consistent. The COMPILE_TEST was introduced and 
created a precedence. I would like to get rid of the interactive timer 
selection but I did not have time to go through this yet.


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>
>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>
>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>> prescalers.
>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>> 1024 prescaler value if it is 16 bits.
>>>>
>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>> ---
>>>>    drivers/clocksource/Kconfig       |   8 ++
>>>>    drivers/clocksource/Makefile      |   1 +
>>>>    drivers/clocksource/timer-stm32.c | 184
>>>> ++++++++++++++++++++++++++++++++++++++
>>>>    3 files changed, 193 insertions(+)
>>>>    create mode 100644 drivers/clocksource/timer-stm32.c
>>>>
>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>> index bf9364c..2443520 100644
>>>> --- a/drivers/clocksource/Kconfig
>>>> +++ b/drivers/clocksource/Kconfig
>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>            Support to use the timers of EFM32 SoCs as clock source and
>>>> clock
>>>>            event device.
>>>>
>>>> +config CLKSRC_STM32
>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>
>>>
>>>
>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>
>>
>> The interactive bool is necessary if we want to be able to
>> select/deselect it in COMPILE_TEST configuration.
>> And personnaly, I think COMPILE_TEST use makes sense.
>>
>> Note that other timer drivers are doing the same thing today
>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>
>> Do you have a specific concern regarding COMPILE_TEST?
>
>
> Actually, we try to keep the timer selection non-interactive and let the
> platform's Kconfig to select the timer.

Ok.

>
> I like when the code is consistent. The COMPILE_TEST was introduced and
> created a precedence. I would like to get rid of the interactive timer
> selection but I did not have time to go through this yet.

Indeed, consistency is important.
On my side, I don't have a strong opinion regarding the COMPILE_TEST thing.
IMHO, it is more a subsystem's maintainer choice.

So, if as a maintainer you don't use it and prefer not supporting it,
I'm fine to provide you a new version without COMPILE_TEST.
Doing that, the interactive selection will disappear too.

I can provide you a new version this evenning.

Best regards,
Maxime

>
>
>
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>
>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>
>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>> prescalers.
>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>> 1024 prescaler value if it is 16 bits.
>>>>
>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>> ---
>>>>    drivers/clocksource/Kconfig       |   8 ++
>>>>    drivers/clocksource/Makefile      |   1 +
>>>>    drivers/clocksource/timer-stm32.c | 184
>>>> ++++++++++++++++++++++++++++++++++++++
>>>>    3 files changed, 193 insertions(+)
>>>>    create mode 100644 drivers/clocksource/timer-stm32.c
>>>>
>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>> index bf9364c..2443520 100644
>>>> --- a/drivers/clocksource/Kconfig
>>>> +++ b/drivers/clocksource/Kconfig
>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>            Support to use the timers of EFM32 SoCs as clock source and
>>>> clock
>>>>            event device.
>>>>
>>>> +config CLKSRC_STM32
>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>
>>>
>>>
>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>
>>
>> The interactive bool is necessary if we want to be able to
>> select/deselect it in COMPILE_TEST configuration.
>> And personnaly, I think COMPILE_TEST use makes sense.
>>
>> Note that other timer drivers are doing the same thing today
>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>
>> Do you have a specific concern regarding COMPILE_TEST?
>
>
> Actually, we try to keep the timer selection non-interactive and let the
> platform's Kconfig to select the timer.

Ok.

>
> I like when the code is consistent. The COMPILE_TEST was introduced and
> created a precedence. I would like to get rid of the interactive timer
> selection but I did not have time to go through this yet.

Indeed, consistency is important.
On my side, I don't have a strong opinion regarding the COMPILE_TEST thing.
IMHO, it is more a subsystem's maintainer choice.

So, if as a maintainer you don't use it and prefer not supporting it,
I'm fine to provide you a new version without COMPILE_TEST.
Doing that, the interactive selection will disappear too.

I can provide you a new version this evenning.

Best regards,
Maxime

>
>
>
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>
>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>
>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>> prescalers.
>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>> 1024 prescaler value if it is 16 bits.
>>>>
>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>> ---
>>>>    drivers/clocksource/Kconfig       |   8 ++
>>>>    drivers/clocksource/Makefile      |   1 +
>>>>    drivers/clocksource/timer-stm32.c | 184
>>>> ++++++++++++++++++++++++++++++++++++++
>>>>    3 files changed, 193 insertions(+)
>>>>    create mode 100644 drivers/clocksource/timer-stm32.c
>>>>
>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>> index bf9364c..2443520 100644
>>>> --- a/drivers/clocksource/Kconfig
>>>> +++ b/drivers/clocksource/Kconfig
>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>            Support to use the timers of EFM32 SoCs as clock source and
>>>> clock
>>>>            event device.
>>>>
>>>> +config CLKSRC_STM32
>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>
>>>
>>>
>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>
>>
>> The interactive bool is necessary if we want to be able to
>> select/deselect it in COMPILE_TEST configuration.
>> And personnaly, I think COMPILE_TEST use makes sense.
>>
>> Note that other timer drivers are doing the same thing today
>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>
>> Do you have a specific concern regarding COMPILE_TEST?
>
>
> Actually, we try to keep the timer selection non-interactive and let the
> platform's Kconfig to select the timer.

Ok.

>
> I like when the code is consistent. The COMPILE_TEST was introduced and
> created a precedence. I would like to get rid of the interactive timer
> selection but I did not have time to go through this yet.

Indeed, consistency is important.
On my side, I don't have a strong opinion regarding the COMPILE_TEST thing.
IMHO, it is more a subsystem's maintainer choice.

So, if as a maintainer you don't use it and prefer not supporting it,
I'm fine to provide you a new version without COMPILE_TEST.
Doing that, the interactive selection will disappear too.

I can provide you a new version this evenning.

Best regards,
Maxime

>
>
>
> --
>  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>
>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano-QSEj5FYQhm5QFI55V6+gNQ@public.gmane.orgg>:
>>>>
>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>> prescalers.
>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>> 1024 prescaler value if it is 16 bits.
>>>>>
>>>>> Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> ---
>>>>>     drivers/clocksource/Kconfig       |   8 ++
>>>>>     drivers/clocksource/Makefile      |   1 +
>>>>>     drivers/clocksource/timer-stm32.c | 184
>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>     3 files changed, 193 insertions(+)
>>>>>     create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>
>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>> index bf9364c..2443520 100644
>>>>> --- a/drivers/clocksource/Kconfig
>>>>> +++ b/drivers/clocksource/Kconfig
>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>             Support to use the timers of EFM32 SoCs as clock source and
>>>>> clock
>>>>>             event device.
>>>>>
>>>>> +config CLKSRC_STM32
>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>
>>>>
>>>>
>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>
>>>
>>> The interactive bool is necessary if we want to be able to
>>> select/deselect it in COMPILE_TEST configuration.
>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>
>>> Note that other timer drivers are doing the same thing today
>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>
>>> Do you have a specific concern regarding COMPILE_TEST?
>>
>>
>> Actually, we try to keep the timer selection non-interactive and let the
>> platform's Kconfig to select the timer.
>
> Ok.
>
>>
>> I like when the code is consistent. The COMPILE_TEST was introduced and
>> created a precedence. I would like to get rid of the interactive timer
>> selection but I did not have time to go through this yet.
>
> Indeed, consistency is important.
> On my side, I don't have a strong opinion regarding the COMPILE_TEST thing.
> IMHO, it is more a subsystem's maintainer choice.
>
> So, if as a maintainer you don't use it and prefer not supporting it,
> I'm fine to provide you a new version without COMPILE_TEST.
> Doing that, the interactive selection will disappear too.
>
> I can provide you a new version this evenning.

Ok, great.

Thanks
   -- Daniel

>>
>>
>>
>> --
>>   <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>
>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>
>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>> prescalers.
>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>> 1024 prescaler value if it is 16 bits.
>>>>>
>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>> ---
>>>>>     drivers/clocksource/Kconfig       |   8 ++
>>>>>     drivers/clocksource/Makefile      |   1 +
>>>>>     drivers/clocksource/timer-stm32.c | 184
>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>     3 files changed, 193 insertions(+)
>>>>>     create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>
>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>> index bf9364c..2443520 100644
>>>>> --- a/drivers/clocksource/Kconfig
>>>>> +++ b/drivers/clocksource/Kconfig
>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>             Support to use the timers of EFM32 SoCs as clock source and
>>>>> clock
>>>>>             event device.
>>>>>
>>>>> +config CLKSRC_STM32
>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>
>>>>
>>>>
>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>
>>>
>>> The interactive bool is necessary if we want to be able to
>>> select/deselect it in COMPILE_TEST configuration.
>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>
>>> Note that other timer drivers are doing the same thing today
>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>
>>> Do you have a specific concern regarding COMPILE_TEST?
>>
>>
>> Actually, we try to keep the timer selection non-interactive and let the
>> platform's Kconfig to select the timer.
>
> Ok.
>
>>
>> I like when the code is consistent. The COMPILE_TEST was introduced and
>> created a precedence. I would like to get rid of the interactive timer
>> selection but I did not have time to go through this yet.
>
> Indeed, consistency is important.
> On my side, I don't have a strong opinion regarding the COMPILE_TEST thing.
> IMHO, it is more a subsystem's maintainer choice.
>
> So, if as a maintainer you don't use it and prefer not supporting it,
> I'm fine to provide you a new version without COMPILE_TEST.
> Doing that, the interactive selection will disappear too.
>
> I can provide you a new version this evenning.

Ok, great.

Thanks
   -- Daniel

>>
>>
>>
>> --
>>   <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>
>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>
>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>> prescalers.
>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>> 1024 prescaler value if it is 16 bits.
>>>>>
>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>> ---
>>>>>     drivers/clocksource/Kconfig       |   8 ++
>>>>>     drivers/clocksource/Makefile      |   1 +
>>>>>     drivers/clocksource/timer-stm32.c | 184
>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>     3 files changed, 193 insertions(+)
>>>>>     create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>
>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>> index bf9364c..2443520 100644
>>>>> --- a/drivers/clocksource/Kconfig
>>>>> +++ b/drivers/clocksource/Kconfig
>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>             Support to use the timers of EFM32 SoCs as clock source and
>>>>> clock
>>>>>             event device.
>>>>>
>>>>> +config CLKSRC_STM32
>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>
>>>>
>>>>
>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>
>>>
>>> The interactive bool is necessary if we want to be able to
>>> select/deselect it in COMPILE_TEST configuration.
>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>
>>> Note that other timer drivers are doing the same thing today
>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>
>>> Do you have a specific concern regarding COMPILE_TEST?
>>
>>
>> Actually, we try to keep the timer selection non-interactive and let the
>> platform's Kconfig to select the timer.
>
> Ok.
>
>>
>> I like when the code is consistent. The COMPILE_TEST was introduced and
>> created a precedence. I would like to get rid of the interactive timer
>> selection but I did not have time to go through this yet.
>
> Indeed, consistency is important.
> On my side, I don't have a strong opinion regarding the COMPILE_TEST thing.
> IMHO, it is more a subsystem's maintainer choice.
>
> So, if as a maintainer you don't use it and prefer not supporting it,
> I'm fine to provide you a new version without COMPILE_TEST.
> Doing that, the interactive selection will disappear too.
>
> I can provide you a new version this evenning.

Ok, great.

Thanks
   -- Daniel

>>
>>
>>
>> --
>>   <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>>
>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>
>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>
>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>
>>>>>
>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>> prescalers.
>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>
>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>> ---
>>>>>>     drivers/clocksource/Kconfig       |   8 ++
>>>>>>     drivers/clocksource/Makefile      |   1 +
>>>>>>     drivers/clocksource/timer-stm32.c | 184
>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>     3 files changed, 193 insertions(+)
>>>>>>     create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>
>>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>>> index bf9364c..2443520 100644
>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>             Support to use the timers of EFM32 SoCs as clock source
>>>>>> and
>>>>>> clock
>>>>>>             event device.
>>>>>>
>>>>>> +config CLKSRC_STM32
>>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>
>>>>
>>>> The interactive bool is necessary if we want to be able to
>>>> select/deselect it in COMPILE_TEST configuration.
>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>
>>>> Note that other timer drivers are doing the same thing today
>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>
>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>
>>>
>>>
>>> Actually, we try to keep the timer selection non-interactive and let the
>>> platform's Kconfig to select the timer.
>>
>>
>> Ok.
>>
>>>
>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>> created a precedence. I would like to get rid of the interactive timer
>>> selection but I did not have time to go through this yet.
>>
>>
>> Indeed, consistency is important.
>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>> thing.
>> IMHO, it is more a subsystem's maintainer choice.
>>
>> So, if as a maintainer you don't use it and prefer not supporting it,
>> I'm fine to provide you a new version without COMPILE_TEST.
>> Doing that, the interactive selection will disappear too.
>>
>> I can provide you a new version this evenning.
>
>
> Ok, great.

Is the below Kconfig entry fine for you?

config CLKSRC_STM32
    def_bool y if ARCH_STM32
    select CLKSRC_MMIO

Best regards,
Maxime


>
> Thanks
>   -- Daniel
>
>
>>>
>>>
>>>
>>> --
>>>   <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>
>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>
>
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>
>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>
>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>
>>>>>
>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>> prescalers.
>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>
>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>> ---
>>>>>>     drivers/clocksource/Kconfig       |   8 ++
>>>>>>     drivers/clocksource/Makefile      |   1 +
>>>>>>     drivers/clocksource/timer-stm32.c | 184
>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>     3 files changed, 193 insertions(+)
>>>>>>     create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>
>>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>>> index bf9364c..2443520 100644
>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>             Support to use the timers of EFM32 SoCs as clock source
>>>>>> and
>>>>>> clock
>>>>>>             event device.
>>>>>>
>>>>>> +config CLKSRC_STM32
>>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>
>>>>
>>>> The interactive bool is necessary if we want to be able to
>>>> select/deselect it in COMPILE_TEST configuration.
>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>
>>>> Note that other timer drivers are doing the same thing today
>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>
>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>
>>>
>>>
>>> Actually, we try to keep the timer selection non-interactive and let the
>>> platform's Kconfig to select the timer.
>>
>>
>> Ok.
>>
>>>
>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>> created a precedence. I would like to get rid of the interactive timer
>>> selection but I did not have time to go through this yet.
>>
>>
>> Indeed, consistency is important.
>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>> thing.
>> IMHO, it is more a subsystem's maintainer choice.
>>
>> So, if as a maintainer you don't use it and prefer not supporting it,
>> I'm fine to provide you a new version without COMPILE_TEST.
>> Doing that, the interactive selection will disappear too.
>>
>> I can provide you a new version this evenning.
>
>
> Ok, great.

Is the below Kconfig entry fine for you?

config CLKSRC_STM32
    def_bool y if ARCH_STM32
    select CLKSRC_MMIO

Best regards,
Maxime


>
> Thanks
>   -- Daniel
>
>
>>>
>>>
>>>
>>> --
>>>   <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>
>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>
>
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>
>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>
>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>
>>>>>
>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>> prescalers.
>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>
>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>> ---
>>>>>>     drivers/clocksource/Kconfig       |   8 ++
>>>>>>     drivers/clocksource/Makefile      |   1 +
>>>>>>     drivers/clocksource/timer-stm32.c | 184
>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>     3 files changed, 193 insertions(+)
>>>>>>     create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>
>>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>>> index bf9364c..2443520 100644
>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>             Support to use the timers of EFM32 SoCs as clock source
>>>>>> and
>>>>>> clock
>>>>>>             event device.
>>>>>>
>>>>>> +config CLKSRC_STM32
>>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>
>>>>
>>>> The interactive bool is necessary if we want to be able to
>>>> select/deselect it in COMPILE_TEST configuration.
>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>
>>>> Note that other timer drivers are doing the same thing today
>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>
>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>
>>>
>>>
>>> Actually, we try to keep the timer selection non-interactive and let the
>>> platform's Kconfig to select the timer.
>>
>>
>> Ok.
>>
>>>
>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>> created a precedence. I would like to get rid of the interactive timer
>>> selection but I did not have time to go through this yet.
>>
>>
>> Indeed, consistency is important.
>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>> thing.
>> IMHO, it is more a subsystem's maintainer choice.
>>
>> So, if as a maintainer you don't use it and prefer not supporting it,
>> I'm fine to provide you a new version without COMPILE_TEST.
>> Doing that, the interactive selection will disappear too.
>>
>> I can provide you a new version this evenning.
>
>
> Ok, great.

Is the below Kconfig entry fine for you?

config CLKSRC_STM32
    def_bool y if ARCH_STM32
    select CLKSRC_MMIO

Best regards,
Maxime


>
> Thanks
>   -- Daniel
>
>
>>>
>>>
>>>
>>> --
>>>   <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>>>
>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>
>
> --
>  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>
>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>
>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>>
>>>>>>
>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>> prescalers.
>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>
>>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>>> ---
>>>>>>>      drivers/clocksource/Kconfig       |   8 ++
>>>>>>>      drivers/clocksource/Makefile      |   1 +
>>>>>>>      drivers/clocksource/timer-stm32.c | 184
>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>>      3 files changed, 193 insertions(+)
>>>>>>>      create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>
>>>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>>>> index bf9364c..2443520 100644
>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>>              Support to use the timers of EFM32 SoCs as clock source
>>>>>>> and
>>>>>>> clock
>>>>>>>              event device.
>>>>>>>
>>>>>>> +config CLKSRC_STM32
>>>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>
>>>>>
>>>>> The interactive bool is necessary if we want to be able to
>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>
>>>>> Note that other timer drivers are doing the same thing today
>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>
>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>
>>>>
>>>>
>>>> Actually, we try to keep the timer selection non-interactive and let the
>>>> platform's Kconfig to select the timer.
>>>
>>>
>>> Ok.
>>>
>>>>
>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>> created a precedence. I would like to get rid of the interactive timer
>>>> selection but I did not have time to go through this yet.
>>>
>>>
>>> Indeed, consistency is important.
>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>> thing.
>>> IMHO, it is more a subsystem's maintainer choice.
>>>
>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>> I'm fine to provide you a new version without COMPILE_TEST.
>>> Doing that, the interactive selection will disappear too.
>>>
>>> I can provide you a new version this evenning.
>>
>>
>> Ok, great.
>
> Is the below Kconfig entry fine for you?
>
> config CLKSRC_STM32
>      def_bool y if ARCH_STM32
>      select CLKSRC_MMIO

config CLKSRC_STM32
	bool
	select CLKSRC_MMIO

and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32

> Best regards,
> Maxime
>
>
>>
>> Thanks
>>    -- Daniel
>>
>>
>>>>
>>>>
>>>>
>>>> --
>>>>    <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>>
>>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>
>>
>>
>> --
>>   <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>
>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>
>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>>
>>>>>>
>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>> prescalers.
>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>
>>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>>> ---
>>>>>>>      drivers/clocksource/Kconfig       |   8 ++
>>>>>>>      drivers/clocksource/Makefile      |   1 +
>>>>>>>      drivers/clocksource/timer-stm32.c | 184
>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>>      3 files changed, 193 insertions(+)
>>>>>>>      create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>
>>>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>>>> index bf9364c..2443520 100644
>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>>              Support to use the timers of EFM32 SoCs as clock source
>>>>>>> and
>>>>>>> clock
>>>>>>>              event device.
>>>>>>>
>>>>>>> +config CLKSRC_STM32
>>>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>
>>>>>
>>>>> The interactive bool is necessary if we want to be able to
>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>
>>>>> Note that other timer drivers are doing the same thing today
>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>
>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>
>>>>
>>>>
>>>> Actually, we try to keep the timer selection non-interactive and let the
>>>> platform's Kconfig to select the timer.
>>>
>>>
>>> Ok.
>>>
>>>>
>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>> created a precedence. I would like to get rid of the interactive timer
>>>> selection but I did not have time to go through this yet.
>>>
>>>
>>> Indeed, consistency is important.
>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>> thing.
>>> IMHO, it is more a subsystem's maintainer choice.
>>>
>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>> I'm fine to provide you a new version without COMPILE_TEST.
>>> Doing that, the interactive selection will disappear too.
>>>
>>> I can provide you a new version this evenning.
>>
>>
>> Ok, great.
>
> Is the below Kconfig entry fine for you?
>
> config CLKSRC_STM32
>      def_bool y if ARCH_STM32
>      select CLKSRC_MMIO

config CLKSRC_STM32
	bool
	select CLKSRC_MMIO

and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32

> Best regards,
> Maxime
>
>
>>
>> Thanks
>>    -- Daniel
>>
>>
>>>>
>>>>
>>>>
>>>> --
>>>>    <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>>
>>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>
>>
>>
>> --
>>   <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>
>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>
>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>>
>>>>>>
>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>> prescalers.
>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>
>>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>>> ---
>>>>>>>      drivers/clocksource/Kconfig       |   8 ++
>>>>>>>      drivers/clocksource/Makefile      |   1 +
>>>>>>>      drivers/clocksource/timer-stm32.c | 184
>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>>      3 files changed, 193 insertions(+)
>>>>>>>      create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>
>>>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>>>> index bf9364c..2443520 100644
>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>>              Support to use the timers of EFM32 SoCs as clock source
>>>>>>> and
>>>>>>> clock
>>>>>>>              event device.
>>>>>>>
>>>>>>> +config CLKSRC_STM32
>>>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>
>>>>>
>>>>> The interactive bool is necessary if we want to be able to
>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>
>>>>> Note that other timer drivers are doing the same thing today
>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>
>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>
>>>>
>>>>
>>>> Actually, we try to keep the timer selection non-interactive and let the
>>>> platform's Kconfig to select the timer.
>>>
>>>
>>> Ok.
>>>
>>>>
>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>> created a precedence. I would like to get rid of the interactive timer
>>>> selection but I did not have time to go through this yet.
>>>
>>>
>>> Indeed, consistency is important.
>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>> thing.
>>> IMHO, it is more a subsystem's maintainer choice.
>>>
>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>> I'm fine to provide you a new version without COMPILE_TEST.
>>> Doing that, the interactive selection will disappear too.
>>>
>>> I can provide you a new version this evenning.
>>
>>
>> Ok, great.
>
> Is the below Kconfig entry fine for you?
>
> config CLKSRC_STM32
>      def_bool y if ARCH_STM32
>      select CLKSRC_MMIO

config CLKSRC_STM32
	bool
	select CLKSRC_MMIO

and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32

> Best regards,
> Maxime
>
>
>>
>> Thanks
>>    -- Daniel
>>
>>
>>>>
>>>>
>>>>
>>>> --
>>>>    <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>>>>
>>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>
>>
>>
>> --
>>   <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>>
>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
>>
>> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>>>
>>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>
>>>>>
>>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>>> prescalers.
>>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>>
>>>>>>>> Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>>>>> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>>>>> ---
>>>>>>>>      drivers/clocksource/Kconfig       |   8 ++
>>>>>>>>      drivers/clocksource/Makefile      |   1 +
>>>>>>>>      drivers/clocksource/timer-stm32.c | 184
>>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>>>      3 files changed, 193 insertions(+)
>>>>>>>>      create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>>
>>>>>>>> diff --git a/drivers/clocksource/Kconfig
>>>>>>>> b/drivers/clocksource/Kconfig
>>>>>>>> index bf9364c..2443520 100644
>>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>>>              Support to use the timers of EFM32 SoCs as clock source
>>>>>>>> and
>>>>>>>> clock
>>>>>>>>              event device.
>>>>>>>>
>>>>>>>> +config CLKSRC_STM32
>>>>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>>
>>>>>>
>>>>>> The interactive bool is necessary if we want to be able to
>>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>>
>>>>>> Note that other timer drivers are doing the same thing today
>>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>>
>>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Actually, we try to keep the timer selection non-interactive and let
>>>>> the
>>>>> platform's Kconfig to select the timer.
>>>>
>>>>
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>>> created a precedence. I would like to get rid of the interactive timer
>>>>> selection but I did not have time to go through this yet.
>>>>
>>>>
>>>>
>>>> Indeed, consistency is important.
>>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>>> thing.
>>>> IMHO, it is more a subsystem's maintainer choice.
>>>>
>>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>>> I'm fine to provide you a new version without COMPILE_TEST.
>>>> Doing that, the interactive selection will disappear too.
>>>>
>>>> I can provide you a new version this evenning.
>>>
>>>
>>>
>>> Ok, great.
>>
>>
>> Is the below Kconfig entry fine for you?
>>
>> config CLKSRC_STM32
>>      def_bool y if ARCH_STM32
>>      select CLKSRC_MMIO
>
>
> config CLKSRC_STM32
>         bool
>         select CLKSRC_MMIO
>
> and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32

Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
the one intruducing ARCH_STM32.

Thanks,
Maxime
>
>
>> Best regards,
>> Maxime
>>
>>
>>>
>>> Thanks
>>>    -- Daniel
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>    <http://www.linaro.org/> Linaro.org │ Open source software for ARM
>>>>> SoCs
>>>>>
>>>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>>
>>>
>>>
>>> --
>>>   <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>
>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>
>
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
>>
>> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>
>>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>
>>>>>
>>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>>> prescalers.
>>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>>
>>>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>>>> ---
>>>>>>>>      drivers/clocksource/Kconfig       |   8 ++
>>>>>>>>      drivers/clocksource/Makefile      |   1 +
>>>>>>>>      drivers/clocksource/timer-stm32.c | 184
>>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>>>      3 files changed, 193 insertions(+)
>>>>>>>>      create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>>
>>>>>>>> diff --git a/drivers/clocksource/Kconfig
>>>>>>>> b/drivers/clocksource/Kconfig
>>>>>>>> index bf9364c..2443520 100644
>>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>>>              Support to use the timers of EFM32 SoCs as clock source
>>>>>>>> and
>>>>>>>> clock
>>>>>>>>              event device.
>>>>>>>>
>>>>>>>> +config CLKSRC_STM32
>>>>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>>
>>>>>>
>>>>>> The interactive bool is necessary if we want to be able to
>>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>>
>>>>>> Note that other timer drivers are doing the same thing today
>>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>>
>>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Actually, we try to keep the timer selection non-interactive and let
>>>>> the
>>>>> platform's Kconfig to select the timer.
>>>>
>>>>
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>>> created a precedence. I would like to get rid of the interactive timer
>>>>> selection but I did not have time to go through this yet.
>>>>
>>>>
>>>>
>>>> Indeed, consistency is important.
>>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>>> thing.
>>>> IMHO, it is more a subsystem's maintainer choice.
>>>>
>>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>>> I'm fine to provide you a new version without COMPILE_TEST.
>>>> Doing that, the interactive selection will disappear too.
>>>>
>>>> I can provide you a new version this evenning.
>>>
>>>
>>>
>>> Ok, great.
>>
>>
>> Is the below Kconfig entry fine for you?
>>
>> config CLKSRC_STM32
>>      def_bool y if ARCH_STM32
>>      select CLKSRC_MMIO
>
>
> config CLKSRC_STM32
>         bool
>         select CLKSRC_MMIO
>
> and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32

Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
the one intruducing ARCH_STM32.

Thanks,
Maxime
>
>
>> Best regards,
>> Maxime
>>
>>
>>>
>>> Thanks
>>>    -- Daniel
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>    <http://www.linaro.org/> Linaro.org │ Open source software for ARM
>>>>> SoCs
>>>>>
>>>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>>
>>>
>>>
>>> --
>>>   <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>
>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>
>
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
>>
>> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>
>>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>
>>>>>
>>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>>> prescalers.
>>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>>
>>>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>>>> ---
>>>>>>>>      drivers/clocksource/Kconfig       |   8 ++
>>>>>>>>      drivers/clocksource/Makefile      |   1 +
>>>>>>>>      drivers/clocksource/timer-stm32.c | 184
>>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>>>      3 files changed, 193 insertions(+)
>>>>>>>>      create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>>
>>>>>>>> diff --git a/drivers/clocksource/Kconfig
>>>>>>>> b/drivers/clocksource/Kconfig
>>>>>>>> index bf9364c..2443520 100644
>>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>>>              Support to use the timers of EFM32 SoCs as clock source
>>>>>>>> and
>>>>>>>> clock
>>>>>>>>              event device.
>>>>>>>>
>>>>>>>> +config CLKSRC_STM32
>>>>>>>> +       bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>>> +       depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>>
>>>>>>
>>>>>> The interactive bool is necessary if we want to be able to
>>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>>
>>>>>> Note that other timer drivers are doing the same thing today
>>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>>
>>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Actually, we try to keep the timer selection non-interactive and let
>>>>> the
>>>>> platform's Kconfig to select the timer.
>>>>
>>>>
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>>> created a precedence. I would like to get rid of the interactive timer
>>>>> selection but I did not have time to go through this yet.
>>>>
>>>>
>>>>
>>>> Indeed, consistency is important.
>>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>>> thing.
>>>> IMHO, it is more a subsystem's maintainer choice.
>>>>
>>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>>> I'm fine to provide you a new version without COMPILE_TEST.
>>>> Doing that, the interactive selection will disappear too.
>>>>
>>>> I can provide you a new version this evenning.
>>>
>>>
>>>
>>> Ok, great.
>>
>>
>> Is the below Kconfig entry fine for you?
>>
>> config CLKSRC_STM32
>>      def_bool y if ARCH_STM32
>>      select CLKSRC_MMIO
>
>
> config CLKSRC_STM32
>         bool
>         select CLKSRC_MMIO
>
> and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32

Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
the one intruducing ARCH_STM32.

Thanks,
Maxime
>
>
>> Best regards,
>> Maxime
>>
>>
>>>
>>> Thanks
>>>    -- Daniel
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>    <http://www.linaro.org/> Linaro.org ? Open source software for ARM
>>>>> SoCs
>>>>>
>>>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>>
>>>
>>>
>>> --
>>>   <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>>>
>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>
>
> --
>  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Arnd Bergmann]

On Tuesday 19 May 2015 12:02:59 Maxime Coquelin wrote:
> >
> > config CLKSRC_STM32
> >         bool
> >         select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> 
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.
> 
> 

Please also make it possible to select this driver on other architectures
with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.

	Arnd

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Arnd Bergmann]

On Tuesday 19 May 2015 12:02:59 Maxime Coquelin wrote:
> >
> > config CLKSRC_STM32
> >         bool
> >         select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> 
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.
> 
> 

Please also make it possible to select this driver on other architectures
with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.

	Arnd

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Arnd Bergmann]

On Tuesday 19 May 2015 12:02:59 Maxime Coquelin wrote:
> >
> > config CLKSRC_STM32
> >         bool
> >         select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> 
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.
> 
> 

Please also make it possible to select this driver on other architectures
with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.

	Arnd

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Thomas Gleixner]

On Tue, 19 May 2015, Maxime Coquelin wrote:
> 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> >> Is the below Kconfig entry fine for you?
> >>
> >> config CLKSRC_STM32
> >>      def_bool y if ARCH_STM32
> >>      select CLKSRC_MMIO
> >
> >
> > config CLKSRC_STM32
> >         bool
> >         select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> 
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.

Folks, can you please trim your replies. It's a PITA to scroll down
through several pages to find a single line of content.

Thanks,

	tglx

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Thomas Gleixner]

On Tue, 19 May 2015, Maxime Coquelin wrote:
> 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> >> Is the below Kconfig entry fine for you?
> >>
> >> config CLKSRC_STM32
> >>      def_bool y if ARCH_STM32
> >>      select CLKSRC_MMIO
> >
> >
> > config CLKSRC_STM32
> >         bool
> >         select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> 
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.

Folks, can you please trim your replies. It's a PITA to scroll down
through several pages to find a single line of content.

Thanks,

	tglx

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Thomas Gleixner]

On Tue, 19 May 2015, Maxime Coquelin wrote:
> 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> >> Is the below Kconfig entry fine for you?
> >>
> >> config CLKSRC_STM32
> >>      def_bool y if ARCH_STM32
> >>      select CLKSRC_MMIO
> >
> >
> > config CLKSRC_STM32
> >         bool
> >         select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> 
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.

Folks, can you please trim your replies. It's a PITA to scroll down
through several pages to find a single line of content.

Thanks,

	tglx

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Russell King - ARM Linux]

On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
> On Tue, 19 May 2015, Maxime Coquelin wrote:
> > 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> > >> Is the below Kconfig entry fine for you?
> > >>
> > >> config CLKSRC_STM32
> > >>      def_bool y if ARCH_STM32
> > >>      select CLKSRC_MMIO
> > >
> > >
> > > config CLKSRC_STM32
> > >         bool
> > >         select CLKSRC_MMIO
> > >
> > > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> > 
> > Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> > the one intruducing ARCH_STM32.
> 
> Folks, can you please trim your replies. It's a PITA to scroll down
> through several pages to find a single line of content.

Absolutely right.  Too many people do not do this, and it's a waste of
readers time.  Maybe we should start ignoring emails which contain only
quoted mail in the first 50 lines.

Also, cutting the rest of the email below the point which you've finished
replying is good etiquette as well.  I've seen a number of posts where
people have added their signature mid-mail and left a huge chunk of quoted
mail below.  That's just not on either.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Russell King - ARM Linux]

On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
> On Tue, 19 May 2015, Maxime Coquelin wrote:
> > 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> > >> Is the below Kconfig entry fine for you?
> > >>
> > >> config CLKSRC_STM32
> > >>      def_bool y if ARCH_STM32
> > >>      select CLKSRC_MMIO
> > >
> > >
> > > config CLKSRC_STM32
> > >         bool
> > >         select CLKSRC_MMIO
> > >
> > > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> > 
> > Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> > the one intruducing ARCH_STM32.
> 
> Folks, can you please trim your replies. It's a PITA to scroll down
> through several pages to find a single line of content.

Absolutely right.  Too many people do not do this, and it's a waste of
readers time.  Maybe we should start ignoring emails which contain only
quoted mail in the first 50 lines.

Also, cutting the rest of the email below the point which you've finished
replying is good etiquette as well.  I've seen a number of posts where
people have added their signature mid-mail and left a huge chunk of quoted
mail below.  That's just not on either.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Russell King - ARM Linux]

On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
> On Tue, 19 May 2015, Maxime Coquelin wrote:
> > 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> > >> Is the below Kconfig entry fine for you?
> > >>
> > >> config CLKSRC_STM32
> > >>      def_bool y if ARCH_STM32
> > >>      select CLKSRC_MMIO
> > >
> > >
> > > config CLKSRC_STM32
> > >         bool
> > >         select CLKSRC_MMIO
> > >
> > > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> > 
> > Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> > the one intruducing ARCH_STM32.
> 
> Folks, can you please trim your replies. It's a PITA to scroll down
> through several pages to find a single line of content.

Absolutely right.  Too many people do not do this, and it's a waste of
readers time.  Maybe we should start ignoring emails which contain only
quoted mail in the first 50 lines.

Also, cutting the rest of the email below the point which you've finished
replying is good etiquette as well.  I've seen a number of posts where
people have added their signature mid-mail and left a huge chunk of quoted
mail below.  That's just not on either.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 15:00 GMT+02:00 Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>:
> On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
>> Folks, can you please trim your replies. It's a PITA to scroll down
>> through several pages to find a single line of content.
>
> Absolutely right.  Too many people do not do this, and it's a waste of
> readers time.  Maybe we should start ignoring emails which contain only
> quoted mail in the first 50 lines.
>
> Also, cutting the rest of the email below the point which you've finished
> replying is good etiquette as well.  I've seen a number of posts where
> people have added their signature mid-mail and left a huge chunk of quoted
> mail below.  That's just not on either.
>

Ok, I will take care of that.
Sorry for the inconvenience,

Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 15:00 GMT+02:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
>> Folks, can you please trim your replies. It's a PITA to scroll down
>> through several pages to find a single line of content.
>
> Absolutely right.  Too many people do not do this, and it's a waste of
> readers time.  Maybe we should start ignoring emails which contain only
> quoted mail in the first 50 lines.
>
> Also, cutting the rest of the email below the point which you've finished
> replying is good etiquette as well.  I've seen a number of posts where
> people have added their signature mid-mail and left a huge chunk of quoted
> mail below.  That's just not on either.
>

Ok, I will take care of that.
Sorry for the inconvenience,

Maxime

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 15:00 GMT+02:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
>> Folks, can you please trim your replies. It's a PITA to scroll down
>> through several pages to find a single line of content.
>
> Absolutely right.  Too many people do not do this, and it's a waste of
> readers time.  Maybe we should start ignoring emails which contain only
> quoted mail in the first 50 lines.
>
> Also, cutting the rest of the email below the point which you've finished
> replying is good etiquette as well.  I've seen a number of posts where
> people have added their signature mid-mail and left a huge chunk of quoted
> mail below.  That's just not on either.
>

Ok, I will take care of that.
Sorry for the inconvenience,

Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> Please also make it possible to select this driver on other architectures
> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.

You proposal is to revert back to the original patch, except that
ARCH_STM32 should select CLKSRC_STM32, right?

Daniel, what do you think?

Regards,
Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> Please also make it possible to select this driver on other architectures
> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.

You proposal is to revert back to the original patch, except that
ARCH_STM32 should select CLKSRC_STM32, right?

Daniel, what do you think?

Regards,
Maxime

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> Please also make it possible to select this driver on other architectures
> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.

You proposal is to revert back to the original patch, except that
ARCH_STM32 should select CLKSRC_STM32, right?

Daniel, what do you think?

Regards,
Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>> Please also make it possible to select this driver on other architectures
>> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
>
> You proposal is to revert back to the original patch, except that
> ARCH_STM32 should select CLKSRC_STM32, right?
>
> Daniel, what do you think?

It is not exactly as the initial patch.

I think Arnd is proposing:

config CLKSRC_STM32
	bool "Clocksource for STM32 SoCs" if COMPILE_TEST
	select CLKSRC_MMIO





-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> Please also make it possible to select this driver on other architectures
>> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
>
> You proposal is to revert back to the original patch, except that
> ARCH_STM32 should select CLKSRC_STM32, right?
>
> Daniel, what do you think?

It is not exactly as the initial patch.

I think Arnd is proposing:

config CLKSRC_STM32
	bool "Clocksource for STM32 SoCs" if COMPILE_TEST
	select CLKSRC_MMIO





-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> Please also make it possible to select this driver on other architectures
>> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
>
> You proposal is to revert back to the original patch, except that
> ARCH_STM32 should select CLKSRC_STM32, right?
>
> Daniel, what do you think?

It is not exactly as the initial patch.

I think Arnd is proposing:

config CLKSRC_STM32
	bool "Clocksource for STM32 SoCs" if COMPILE_TEST
	select CLKSRC_MMIO





-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Arnd Bergmann]

On Tuesday 19 May 2015 15:49:52 Daniel Lezcano wrote:
> On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> > 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> >> Please also make it possible to select this driver on other architectures
> >> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
> >
> > You proposal is to revert back to the original patch, except that
> > ARCH_STM32 should select CLKSRC_STM32, right?
> >
> > Daniel, what do you think?
> 
> It is not exactly as the initial patch.
> 
> I think Arnd is proposing:
> 
> config CLKSRC_STM32
>         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>         select CLKSRC_MMIO

Yes, that's fine, although we might also need a 'depends on OF'
line, not sure.

	Arnd

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Arnd Bergmann]

On Tuesday 19 May 2015 15:49:52 Daniel Lezcano wrote:
> On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> > 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> >> Please also make it possible to select this driver on other architectures
> >> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
> >
> > You proposal is to revert back to the original patch, except that
> > ARCH_STM32 should select CLKSRC_STM32, right?
> >
> > Daniel, what do you think?
> 
> It is not exactly as the initial patch.
> 
> I think Arnd is proposing:
> 
> config CLKSRC_STM32
>         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>         select CLKSRC_MMIO

Yes, that's fine, although we might also need a 'depends on OF'
line, not sure.

	Arnd

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Arnd Bergmann]

On Tuesday 19 May 2015 15:49:52 Daniel Lezcano wrote:
> On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> > 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> >> Please also make it possible to select this driver on other architectures
> >> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
> >
> > You proposal is to revert back to the original patch, except that
> > ARCH_STM32 should select CLKSRC_STM32, right?
> >
> > Daniel, what do you think?
> 
> It is not exactly as the initial patch.
> 
> I think Arnd is proposing:
> 
> config CLKSRC_STM32
>         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>         select CLKSRC_MMIO

Yes, that's fine, although we might also need a 'depends on OF'
line, not sure.

	Arnd

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>
>
> It is not exactly as the initial patch.
>
> I think Arnd is proposing:
>
> config CLKSRC_STM32
>         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>         select CLKSRC_MMIO
>

Isn't "depends on OF" missing for COMPILE_TEST case?

Other than that, I'm fine with the proposal.
Daniel, is it the case for you too?

Regards,
Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>
>
> It is not exactly as the initial patch.
>
> I think Arnd is proposing:
>
> config CLKSRC_STM32
>         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>         select CLKSRC_MMIO
>

Isn't "depends on OF" missing for COMPILE_TEST case?

Other than that, I'm fine with the proposal.
Daniel, is it the case for you too?

Regards,
Maxime

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>
>
> It is not exactly as the initial patch.
>
> I think Arnd is proposing:
>
> config CLKSRC_STM32
>         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>         select CLKSRC_MMIO
>

Isn't "depends on OF" missing for COMPILE_TEST case?

Other than that, I'm fine with the proposal.
Daniel, is it the case for you too?

Regards,
Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Russell King - ARM Linux]

On Tue, May 19, 2015 at 04:41:58PM +0200, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> >
> >
> > It is not exactly as the initial patch.
> >
> > I think Arnd is proposing:
> >
> > config CLKSRC_STM32
> >         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> >         select CLKSRC_MMIO
> >
> 
> Isn't "depends on OF" missing for COMPILE_TEST case?

config CLKSRC_STM32
	bool "Clocksource for STM32 SoCs" if COMPILE_TEST
	depends on OF
	select CLKSRC_MMIO

This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
it's always going to be for that case, right?) while allowing the option
to be visible when both OF!=n and COMPILE_TEST!=n.

Remember,

	bool "string" if <condition-affects-visibility-of-string>
	depends on <condition-affects-config-symbol-availability>

The former merely hides the option from the user _if_ the condition fails.
The latter _disables_ the option completely (except if you try and select
it, at which point you end up with a Kconfig warning about that.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Russell King - ARM Linux]

On Tue, May 19, 2015 at 04:41:58PM +0200, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> >
> >
> > It is not exactly as the initial patch.
> >
> > I think Arnd is proposing:
> >
> > config CLKSRC_STM32
> >         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> >         select CLKSRC_MMIO
> >
> 
> Isn't "depends on OF" missing for COMPILE_TEST case?

config CLKSRC_STM32
	bool "Clocksource for STM32 SoCs" if COMPILE_TEST
	depends on OF
	select CLKSRC_MMIO

This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
it's always going to be for that case, right?) while allowing the option
to be visible when both OF!=n and COMPILE_TEST!=n.

Remember,

	bool "string" if <condition-affects-visibility-of-string>
	depends on <condition-affects-config-symbol-availability>

The former merely hides the option from the user _if_ the condition fails.
The latter _disables_ the option completely (except if you try and select
it, at which point you end up with a Kconfig warning about that.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Russell King - ARM Linux]

On Tue, May 19, 2015 at 04:41:58PM +0200, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> >
> >
> > It is not exactly as the initial patch.
> >
> > I think Arnd is proposing:
> >
> > config CLKSRC_STM32
> >         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> >         select CLKSRC_MMIO
> >
> 
> Isn't "depends on OF" missing for COMPILE_TEST case?

config CLKSRC_STM32
	bool "Clocksource for STM32 SoCs" if COMPILE_TEST
	depends on OF
	select CLKSRC_MMIO

This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
it's always going to be for that case, right?) while allowing the option
to be visible when both OF!=n and COMPILE_TEST!=n.

Remember,

	bool "string" if <condition-affects-visibility-of-string>
	depends on <condition-affects-config-symbol-availability>

The former merely hides the option from the user _if_ the condition fails.
The latter _disables_ the option completely (except if you try and select
it, at which point you end up with a Kconfig warning about that.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 04:41 PM, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>>
>>
>> It is not exactly as the initial patch.
>>
>> I think Arnd is proposing:
>>
>> config CLKSRC_STM32
>>          bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>>          select CLKSRC_MMIO
>>
>
> Isn't "depends on OF" missing for COMPILE_TEST case?

Hmm, yes. Probably.

> Other than that, I'm fine with the proposal.
> Daniel, is it the case for you too?

Yep.


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 04:41 PM, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>
>>
>> It is not exactly as the initial patch.
>>
>> I think Arnd is proposing:
>>
>> config CLKSRC_STM32
>>          bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>>          select CLKSRC_MMIO
>>
>
> Isn't "depends on OF" missing for COMPILE_TEST case?

Hmm, yes. Probably.

> Other than that, I'm fine with the proposal.
> Daniel, is it the case for you too?

Yep.


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/19/2015 04:41 PM, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>
>>
>> It is not exactly as the initial patch.
>>
>> I think Arnd is proposing:
>>
>> config CLKSRC_STM32
>>          bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>>          select CLKSRC_MMIO
>>
>
> Isn't "depends on OF" missing for COMPILE_TEST case?

Hmm, yes. Probably.

> Other than that, I'm fine with the proposal.
> Daniel, is it the case for you too?

Yep.


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 16:50 GMT+02:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>
> config CLKSRC_STM32
>         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>         depends on OF
>         select CLKSRC_MMIO
>
> This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
> it's always going to be for that case, right?) while allowing the option
> to be visible when both OF!=n and COMPILE_TEST!=n.

Yes OF is always enabled when STM32.

So it fits our needs, as we only want the option to be visible when
both OF!=n and COMPILE_TEST!=n.

>
> Remember,
>
>         bool "string" if <condition-affects-visibility-of-string>
>         depends on <condition-affects-config-symbol-availability>
>
> The former merely hides the option from the user _if_ the condition fails.
> The latter _disables_ the option completely (except if you try and select
> it, at which point you end up with a Kconfig warning about that.)

Thanks for the reminder!
Maxime

Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 16:50 GMT+02:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>
> config CLKSRC_STM32
>         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>         depends on OF
>         select CLKSRC_MMIO
>
> This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
> it's always going to be for that case, right?) while allowing the option
> to be visible when both OF!=n and COMPILE_TEST!=n.

Yes OF is always enabled when STM32.

So it fits our needs, as we only want the option to be visible when
both OF!=n and COMPILE_TEST!=n.

>
> Remember,
>
>         bool "string" if <condition-affects-visibility-of-string>
>         depends on <condition-affects-config-symbol-availability>
>
> The former merely hides the option from the user _if_ the condition fails.
> The latter _disables_ the option completely (except if you try and select
> it, at which point you end up with a Kconfig warning about that.)

Thanks for the reminder!
Maxime

[PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver

[Maxime Coquelin]

2015-05-19 16:50 GMT+02:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>
> config CLKSRC_STM32
>         bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>         depends on OF
>         select CLKSRC_MMIO
>
> This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
> it's always going to be for that case, right?) while allowing the option
> to be visible when both OF!=n and COMPILE_TEST!=n.

Yes OF is always enabled when STM32.

So it fits our needs, as we only want the option to be visible when
both OF!=n and COMPILE_TEST!=n.

>
> Remember,
>
>         bool "string" if <condition-affects-visibility-of-string>
>         depends on <condition-affects-config-symbol-availability>
>
> The former merely hides the option from the user _if_ the condition fails.
> The latter _disables_ the option completely (except if you try and select
> it, at which point you end up with a Kconfig warning about that.)

Thanks for the reminder!
Maxime

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

Hi Arnd, Philipp,

2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> Ideally the binding should follow closely what is documented
> in the data sheet.
>

Daniel and myself would like your opinion about this binding:

rcc: rcc@40023800 {
    #reset-cells = <1>;
    #clock-cells = <2>;
    compatible = "st,stm32-rcc";
    reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
    reg-names = "clock-cfg", "reset", "clock-gates";
};

It would solve a problem Daniel is facing due to conflicting mem
region when clock and reset drivers are enabled, as both would reserve
the same region.

Also, it would make the reset driver very generic.
Doing that, we could even create a generic-reset.c driver that would
be used by STM32 and Sunxi (at least).
In the probe function, it would check the number of reg resources.
If a single resource is passed, it would take it, else it would look
the one named "reset".
The driver and bindings would be the same for the two families, and
the bindings would be backward compatible with sunxi ones.

Philip, Arnd, what do you think?

Kind regards,
Maxime

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

Hi Arnd, Philipp,

2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> Ideally the binding should follow closely what is documented
> in the data sheet.
>

Daniel and myself would like your opinion about this binding:

rcc: rcc@40023800 {
    #reset-cells = <1>;
    #clock-cells = <2>;
    compatible = "st,stm32-rcc";
    reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
    reg-names = "clock-cfg", "reset", "clock-gates";
};

It would solve a problem Daniel is facing due to conflicting mem
region when clock and reset drivers are enabled, as both would reserve
the same region.

Also, it would make the reset driver very generic.
Doing that, we could even create a generic-reset.c driver that would
be used by STM32 and Sunxi (at least).
In the probe function, it would check the number of reg resources.
If a single resource is passed, it would take it, else it would look
the one named "reset".
The driver and bindings would be the same for the two families, and
the bindings would be backward compatible with sunxi ones.

Philip, Arnd, what do you think?

Kind regards,
Maxime

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

Hi Arnd, Philipp,

2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> Ideally the binding should follow closely what is documented
> in the data sheet.
>

Daniel and myself would like your opinion about this binding:

rcc: rcc at 40023800 {
    #reset-cells = <1>;
    #clock-cells = <2>;
    compatible = "st,stm32-rcc";
    reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
    reg-names = "clock-cfg", "reset", "clock-gates";
};

It would solve a problem Daniel is facing due to conflicting mem
region when clock and reset drivers are enabled, as both would reserve
the same region.

Also, it would make the reset driver very generic.
Doing that, we could even create a generic-reset.c driver that would
be used by STM32 and Sunxi (at least).
In the probe function, it would check the number of reg resources.
If a single resource is passed, it would take it, else it would look
the one named "reset".
The driver and bindings would be the same for the two families, and
the bindings would be backward compatible with sunxi ones.

Philip, Arnd, what do you think?

Kind regards,
Maxime

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Andreas Färber]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

Hi,

Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>> When Kernel is executed in place from ROM, the symbol addresses can be
>> lower than the page offset.
>>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

This issue was reported by Stefan Agner in 2014 for the VF610 [1], not
sure if I asked already whether there should be a Reported-by line?
Stefan, have you had a chance to test this patch?

Back then on STM32F4 I debugged that disabling KALLSYMS works around it.

Now on a different XIP target I have confirmed this patch to help show a
stacktrace (my clk driver was missing some CLK_DIVIDER_ALLOW_ZEROs) ...
although my earlyprintk serial output still gets stuck further down the
stacktrace - probably unrelated.

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:126
divider_recalc_rate+0x2b/0x44()
[    0.000000] SYS: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.1.0-rc4-next-20150519+ #23
[    0.000000] Hardware name: XMC4000 (Device Tree Support)
[    0.000000] [<0800bd5d>] (unwind_backtrace) from [<0800b0cb>]
(show_stack+0xb/0xc)
[    0.000000] [<0800b0cb>] (show_stack) from [<0800e0a5>]
(warn_slowpath_common+0x55/0x78)
[    0.000000] [<0800e0a5>] (warn_slowpath_common) from [<0800e103>]
(warn_slowpath_fmt+0x1b/0x24)
[    0.000000] [<0800e103>] (warn_slowpath_fmt) from [<080942e3>] (divide

But this is definitely an improvement for ARMv7-M debugging,

Tested-by: Andreas Färber <afaerber@suse.de>

> [Hi Michal, ...] could you consider
> taking it for v4.2?

Regards,
Andreas

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/307297.html

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Andreas Färber]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

Hi,

Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>> When Kernel is executed in place from ROM, the symbol addresses can be
>> lower than the page offset.
>>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

This issue was reported by Stefan Agner in 2014 for the VF610 [1], not
sure if I asked already whether there should be a Reported-by line?
Stefan, have you had a chance to test this patch?

Back then on STM32F4 I debugged that disabling KALLSYMS works around it.

Now on a different XIP target I have confirmed this patch to help show a
stacktrace (my clk driver was missing some CLK_DIVIDER_ALLOW_ZEROs) ...
although my earlyprintk serial output still gets stuck further down the
stacktrace - probably unrelated.

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:126
divider_recalc_rate+0x2b/0x44()
[    0.000000] SYS: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.1.0-rc4-next-20150519+ #23
[    0.000000] Hardware name: XMC4000 (Device Tree Support)
[    0.000000] [<0800bd5d>] (unwind_backtrace) from [<0800b0cb>]
(show_stack+0xb/0xc)
[    0.000000] [<0800b0cb>] (show_stack) from [<0800e0a5>]
(warn_slowpath_common+0x55/0x78)
[    0.000000] [<0800e0a5>] (warn_slowpath_common) from [<0800e103>]
(warn_slowpath_fmt+0x1b/0x24)
[    0.000000] [<0800e103>] (warn_slowpath_fmt) from [<080942e3>] (divide

But this is definitely an improvement for ARMv7-M debugging,

Tested-by: Andreas Färber <afaerber@suse.de>

> [Hi Michal, ...] could you consider
> taking it for v4.2?

Regards,
Andreas

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/307297.html

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Andreas Färber]

Hi,

Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>> When Kernel is executed in place from ROM, the symbol addresses can be
>> lower than the page offset.
>>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

This issue was reported by Stefan Agner in 2014 for the VF610 [1], not
sure if I asked already whether there should be a Reported-by line?
Stefan, have you had a chance to test this patch?

Back then on STM32F4 I debugged that disabling KALLSYMS works around it.

Now on a different XIP target I have confirmed this patch to help show a
stacktrace (my clk driver was missing some CLK_DIVIDER_ALLOW_ZEROs) ...
although my earlyprintk serial output still gets stuck further down the
stacktrace - probably unrelated.

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:126
divider_recalc_rate+0x2b/0x44()
[    0.000000] SYS: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.1.0-rc4-next-20150519+ #23
[    0.000000] Hardware name: XMC4000 (Device Tree Support)
[    0.000000] [<0800bd5d>] (unwind_backtrace) from [<0800b0cb>]
(show_stack+0xb/0xc)
[    0.000000] [<0800b0cb>] (show_stack) from [<0800e0a5>]
(warn_slowpath_common+0x55/0x78)
[    0.000000] [<0800e0a5>] (warn_slowpath_common) from [<0800e103>]
(warn_slowpath_fmt+0x1b/0x24)
[    0.000000] [<0800e103>] (warn_slowpath_fmt) from [<080942e3>] (divide

But this is definitely an improvement for ARMv7-M debugging,

Tested-by: Andreas F?rber <afaerber@suse.de>

> [Hi Michal, ...] could you consider
> taking it for v4.2?

Regards,
Andreas

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/307297.html

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150521/cb0d9366/attachment-0001.sig>

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Andreas Färber]

Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
> The STM32 MCUs family IPs can be reset by accessing some registers
> from the RCC block.
> 
> The list of available reset lines is documented in the DT bindings.
> 
> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/reset/Makefile      |   1 +
>  drivers/reset/reset-stm32.c | 124 ++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 125 insertions(+)
>  create mode 100644 drivers/reset/reset-stm32.c
> 
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 157d421..aed12d1 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_RESET_CONTROLLER) += core.o
>  obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
>  obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
> +obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
>  obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
>  obj-$(CONFIG_ARCH_STI) += sti/
> diff --git a/drivers/reset/reset-stm32.c b/drivers/reset/reset-stm32.c
> new file mode 100644
> index 0000000..2c41858
> --- /dev/null
> +++ b/drivers/reset/reset-stm32.c
[...]
> +static const struct of_device_id stm32_reset_dt_ids[] = {
> +	 { .compatible = "st,stm32-rcc", },
> +	 { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);

Typo.

IIUC the timer depends on the reset controller, so it must be built in
anyway, and that's what's enforced in the Makefile above. Drop the line?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Andreas Färber]

Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
> The STM32 MCUs family IPs can be reset by accessing some registers
> from the RCC block.
> 
> The list of available reset lines is documented in the DT bindings.
> 
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/reset/Makefile      |   1 +
>  drivers/reset/reset-stm32.c | 124 ++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 125 insertions(+)
>  create mode 100644 drivers/reset/reset-stm32.c
> 
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 157d421..aed12d1 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_RESET_CONTROLLER) += core.o
>  obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
>  obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
> +obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
>  obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
>  obj-$(CONFIG_ARCH_STI) += sti/
> diff --git a/drivers/reset/reset-stm32.c b/drivers/reset/reset-stm32.c
> new file mode 100644
> index 0000000..2c41858
> --- /dev/null
> +++ b/drivers/reset/reset-stm32.c
[...]
> +static const struct of_device_id stm32_reset_dt_ids[] = {
> +	 { .compatible = "st,stm32-rcc", },
> +	 { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);

Typo.

IIUC the timer depends on the reset controller, so it must be built in
anyway, and that's what's enforced in the Makefile above. Drop the line?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

[PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Andreas Färber]

Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
> The STM32 MCUs family IPs can be reset by accessing some registers
> from the RCC block.
> 
> The list of available reset lines is documented in the DT bindings.
> 
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  drivers/reset/Makefile      |   1 +
>  drivers/reset/reset-stm32.c | 124 ++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 125 insertions(+)
>  create mode 100644 drivers/reset/reset-stm32.c
> 
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 157d421..aed12d1 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_RESET_CONTROLLER) += core.o
>  obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
>  obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
> +obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
>  obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
>  obj-$(CONFIG_ARCH_STI) += sti/
> diff --git a/drivers/reset/reset-stm32.c b/drivers/reset/reset-stm32.c
> new file mode 100644
> index 0000000..2c41858
> --- /dev/null
> +++ b/drivers/reset/reset-stm32.c
[...]
> +static const struct of_device_id stm32_reset_dt_ids[] = {
> +	 { .compatible = "st,stm32-rcc", },
> +	 { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);

Typo.

IIUC the timer depends on the reset controller, so it must be built in
anyway, and that's what's enforced in the Makefile above. Drop the line?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Michal Marek]

Dne 21.5.2015 v 07:04 Andreas Färber napsal(a):
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
> But this is definitely an improvement for ARMv7-M debugging,
> 
> Tested-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> 
>> [Hi Michal, ...] could you consider
>> taking it for v4.2?

I applied it to kbuild.git#kbuild now.

Thanks,
Michal

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Michal Marek]

Dne 21.5.2015 v 07:04 Andreas Färber napsal(a):
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
> But this is definitely an improvement for ARMv7-M debugging,
> 
> Tested-by: Andreas Färber <afaerber@suse.de>
> 
>> [Hi Michal, ...] could you consider
>> taking it for v4.2?

I applied it to kbuild.git#kbuild now.

Thanks,
Michal

[PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Michal Marek]

Dne 21.5.2015 v 07:04 Andreas F?rber napsal(a):
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
> But this is definitely an improvement for ARMv7-M debugging,
> 
> Tested-by: Andreas F?rber <afaerber@suse.de>
> 
>> [Hi Michal, ...] could you consider
>> taking it for v4.2?

I applied it to kbuild.git#kbuild now.

Thanks,
Michal

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Maxime Coquelin]

2015-05-21 7:40 GMT+02:00 Michal Marek <mmarek@suse.cz>:
> Dne 21.5.2015 v 07:04 Andreas Färber napsal(a):
>> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
>> But this is definitely an improvement for ARMv7-M debugging,
>>
>> Tested-by: Andreas Färber <afaerber@suse.de>
>>
>>> [Hi Michal, ...] could you consider
>>> taking it for v4.2?
>
> I applied it to kbuild.git#kbuild now.

Thanks!
Maxime

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Maxime Coquelin]

2015-05-21 7:40 GMT+02:00 Michal Marek <mmarek@suse.cz>:
> Dne 21.5.2015 v 07:04 Andreas Färber napsal(a):
>> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
>> But this is definitely an improvement for ARMv7-M debugging,
>>
>> Tested-by: Andreas Färber <afaerber@suse.de>
>>
>>> [Hi Michal, ...] could you consider
>>> taking it for v4.2?
>
> I applied it to kbuild.git#kbuild now.

Thanks!
Maxime

[PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Maxime Coquelin]

2015-05-21 7:40 GMT+02:00 Michal Marek <mmarek@suse.cz>:
> Dne 21.5.2015 v 07:04 Andreas F?rber napsal(a):
>> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
>> But this is definitely an improvement for ARMv7-M debugging,
>>
>> Tested-by: Andreas F?rber <afaerber@suse.de>
>>
>>> [Hi Michal, ...] could you consider
>>> taking it for v4.2?
>
> I applied it to kbuild.git#kbuild now.

Thanks!
Maxime

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-05-21 1:45 GMT+02:00 Andreas Färber <afaerber@suse.de>:
> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>> +      { .compatible = "st,stm32-rcc", },
>> +      { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>
> Typo.

Indeed, thanks for pointing this out.

>
> IIUC the timer depends on the reset controller, so it must be built in
> anyway, and that's what's enforced in the Makefile above. Drop the line?
>

Agree it must be built-in.
I will fix that in next version.

Thanks for the review,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-05-21 1:45 GMT+02:00 Andreas Färber <afaerber@suse.de>:
> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>> +      { .compatible = "st,stm32-rcc", },
>> +      { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>
> Typo.

Indeed, thanks for pointing this out.

>
> IIUC the timer depends on the reset controller, so it must be built in
> anyway, and that's what's enforced in the Makefile above. Drop the line?
>

Agree it must be built-in.
I will fix that in next version.

Thanks for the review,
Maxime

[PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-05-21 1:45 GMT+02:00 Andreas F?rber <afaerber@suse.de>:
> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>> +      { .compatible = "st,stm32-rcc", },
>> +      { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>
> Typo.

Indeed, thanks for pointing this out.

>
> IIUC the timer depends on the reset controller, so it must be built in
> anyway, and that's what's enforced in the Makefile above. Drop the line?
>

Agree it must be built-in.
I will fix that in next version.

Thanks for the review,
Maxime

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Andreas Färber]

Am 21.05.2015 um 09:46 schrieb Maxime Coquelin:
> 2015-05-21 1:45 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>>> +      { .compatible = "st,stm32-rcc", },
>>> +      { /* sentinel */ },
>>> +};
>>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>>
>> Typo.
> 
> Indeed, thanks for pointing this out.
> 
>>
>> IIUC the timer depends on the reset controller, so it must be built in
>> anyway, and that's what's enforced in the Makefile above. Drop the line?
>>
> 
> Agree it must be built-in.
> I will fix that in next version.

Actually, I've updated a timer implementation of mine to invoke a reset
controller similar to how you do in the STM32 clocksource patch, but no
reset controller is getting returned.

It seems to me, you are working around that by simply ignoring the error
in the timer code and not doing a reset then, so the STM32 timer does in
fact _not_ depend on the reset controller? What happened to your efforts
of making the reset controller usable for the timer? In my case, my
timer is originally in reset state and needs to be deasserted, so I
can't just ignore it.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Andreas Färber]

Am 21.05.2015 um 09:46 schrieb Maxime Coquelin:
> 2015-05-21 1:45 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>>> +      { .compatible = "st,stm32-rcc", },
>>> +      { /* sentinel */ },
>>> +};
>>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>>
>> Typo.
> 
> Indeed, thanks for pointing this out.
> 
>>
>> IIUC the timer depends on the reset controller, so it must be built in
>> anyway, and that's what's enforced in the Makefile above. Drop the line?
>>
> 
> Agree it must be built-in.
> I will fix that in next version.

Actually, I've updated a timer implementation of mine to invoke a reset
controller similar to how you do in the STM32 clocksource patch, but no
reset controller is getting returned.

It seems to me, you are working around that by simply ignoring the error
in the timer code and not doing a reset then, so the STM32 timer does in
fact _not_ depend on the reset controller? What happened to your efforts
of making the reset controller usable for the timer? In my case, my
timer is originally in reset state and needs to be deasserted, so I
can't just ignore it.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

[PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Andreas Färber]

Am 21.05.2015 um 09:46 schrieb Maxime Coquelin:
> 2015-05-21 1:45 GMT+02:00 Andreas F?rber <afaerber@suse.de>:
>> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>>> +      { .compatible = "st,stm32-rcc", },
>>> +      { /* sentinel */ },
>>> +};
>>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>>
>> Typo.
> 
> Indeed, thanks for pointing this out.
> 
>>
>> IIUC the timer depends on the reset controller, so it must be built in
>> anyway, and that's what's enforced in the Makefile above. Drop the line?
>>
> 
> Agree it must be built-in.
> I will fix that in next version.

Actually, I've updated a timer implementation of mine to invoke a reset
controller similar to how you do in the STM32 clocksource patch, but no
reset controller is getting returned.

It seems to me, you are working around that by simply ignoring the error
in the timer code and not doing a reset then, so the STM32 timer does in
fact _not_ depend on the reset controller? What happened to your efforts
of making the reset controller usable for the timer? In my case, my
timer is originally in reset state and needs to be deasserted, so I
can't just ignore it.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1850 bytes --]

On Wed, May 20, 2015 at 06:17:34PM +0200, Maxime Coquelin wrote:
> Hi Arnd, Philipp,
> 
> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> > Ideally the binding should follow closely what is documented
> > in the data sheet.
> >
> 
> Daniel and myself would like your opinion about this binding:
> 
> rcc: rcc@40023800 {
>     #reset-cells = <1>;
>     #clock-cells = <2>;
>     compatible = "st,stm32-rcc";
>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>     reg-names = "clock-cfg", "reset", "clock-gates";
> };
> 
> It would solve a problem Daniel is facing due to conflicting mem
> region when clock and reset drivers are enabled, as both would reserve
> the same region.
> 
> Also, it would make the reset driver very generic.
> Doing that, we could even create a generic-reset.c driver that would
> be used by STM32 and Sunxi (at least).
> In the probe function, it would check the number of reg resources.
> If a single resource is passed, it would take it, else it would look
> the one named "reset".
> The driver and bindings would be the same for the two families, and
> the bindings would be backward compatible with sunxi ones.
> 
> Philip, Arnd, what do you think?

I lack a bit of context here, but I'd be very happy to use a generic
driver. As a matter of fact, the sunxi reset driver is already pretty
much there (not that it's very difficult to do).

The only thing we did that stands out a bit is that we actually need
the reset driver much earlier than the default probe, since some of
our timers are maintained in reset. We have some code to do just that
already, we just need have something similar to be on board.

Maxime (the other one)

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Ripard]

On Wed, May 20, 2015 at 06:17:34PM +0200, Maxime Coquelin wrote:
> Hi Arnd, Philipp,
> 
> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> > Ideally the binding should follow closely what is documented
> > in the data sheet.
> >
> 
> Daniel and myself would like your opinion about this binding:
> 
> rcc: rcc at 40023800 {
>     #reset-cells = <1>;
>     #clock-cells = <2>;
>     compatible = "st,stm32-rcc";
>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>     reg-names = "clock-cfg", "reset", "clock-gates";
> };
> 
> It would solve a problem Daniel is facing due to conflicting mem
> region when clock and reset drivers are enabled, as both would reserve
> the same region.
> 
> Also, it would make the reset driver very generic.
> Doing that, we could even create a generic-reset.c driver that would
> be used by STM32 and Sunxi (at least).
> In the probe function, it would check the number of reg resources.
> If a single resource is passed, it would take it, else it would look
> the one named "reset".
> The driver and bindings would be the same for the two families, and
> the bindings would be backward compatible with sunxi ones.
> 
> Philip, Arnd, what do you think?

I lack a bit of context here, but I'd be very happy to use a generic
driver. As a matter of fact, the sunxi reset driver is already pretty
much there (not that it's very difficult to do).

The only thing we did that stands out a bit is that we actually need
the reset driver much earlier than the default probe, since some of
our timers are maintained in reset. We have some code to do just that
already, we just need have something similar to be on board.

Maxime (the other one)

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150521/bce7b949/attachment-0001.sig>

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-05-21 19:58 GMT+02:00 Andreas Färber <afaerber@suse.de>:
> Am 21.05.2015 um 09:46 schrieb Maxime Coquelin:
>> 2015-05-21 1:45 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>>> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>>>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>>>> +      { .compatible = "st,stm32-rcc", },
>>>> +      { /* sentinel */ },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>>>
>>> Typo.
>>
>> Indeed, thanks for pointing this out.
>>
>>>
>>> IIUC the timer depends on the reset controller, so it must be built in
>>> anyway, and that's what's enforced in the Makefile above. Drop the line?
>>>
>>
>> Agree it must be built-in.
>> I will fix that in next version.
>
> Actually, I've updated a timer implementation of mine to invoke a reset
> controller similar to how you do in the STM32 clocksource patch, but no
> reset controller is getting returned.
>
> It seems to me, you are working around that by simply ignoring the error
> in the timer code and not doing a reset then, so the STM32 timer does in
> fact _not_ depend on the reset controller? What happened to your efforts
> of making the reset controller usable for the timer? In my case, my
> timer is originally in reset state and needs to be deasserted, so I
> can't just ignore it.

Indeed, I made the reset optionnal in the clocksource patch since v3.
Rob and Arnd said a lot of platform relies on such things are done by
the bootloader [0].
I decided to deassert timers reset at bootloader stage, and make it
optionnal in clocksource driver.
I made it optionnal in case we decide one day to move reset
initialization before timer are initialized.

Note that for now, I still use your bootloader.
I have done the changes to reset the timers in the afboot-stm32.
That's the reason why I asked you under which licence it is delivered
few months ago.
I can share you the patch if you want, even if I understand it is more
about the concept that you are reluctant.

On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
support in mainline [1].
In case of U-Boot, the timer reset should be de-asserted when jumping
into the Kernel, as Rob mentionned [0].

Kind regards,
Maxime

[0]: https://lkml.org/lkml/2015/3/10/737
[1]: http://u-boot.10912.n7.nabble.com/PATCH-v2-stm32f4-fix-serial-output-td212812.html
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-05-21 19:58 GMT+02:00 Andreas Färber <afaerber@suse.de>:
> Am 21.05.2015 um 09:46 schrieb Maxime Coquelin:
>> 2015-05-21 1:45 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>>> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>>>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>>>> +      { .compatible = "st,stm32-rcc", },
>>>> +      { /* sentinel */ },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>>>
>>> Typo.
>>
>> Indeed, thanks for pointing this out.
>>
>>>
>>> IIUC the timer depends on the reset controller, so it must be built in
>>> anyway, and that's what's enforced in the Makefile above. Drop the line?
>>>
>>
>> Agree it must be built-in.
>> I will fix that in next version.
>
> Actually, I've updated a timer implementation of mine to invoke a reset
> controller similar to how you do in the STM32 clocksource patch, but no
> reset controller is getting returned.
>
> It seems to me, you are working around that by simply ignoring the error
> in the timer code and not doing a reset then, so the STM32 timer does in
> fact _not_ depend on the reset controller? What happened to your efforts
> of making the reset controller usable for the timer? In my case, my
> timer is originally in reset state and needs to be deasserted, so I
> can't just ignore it.

Indeed, I made the reset optionnal in the clocksource patch since v3.
Rob and Arnd said a lot of platform relies on such things are done by
the bootloader [0].
I decided to deassert timers reset at bootloader stage, and make it
optionnal in clocksource driver.
I made it optionnal in case we decide one day to move reset
initialization before timer are initialized.

Note that for now, I still use your bootloader.
I have done the changes to reset the timers in the afboot-stm32.
That's the reason why I asked you under which licence it is delivered
few months ago.
I can share you the patch if you want, even if I understand it is more
about the concept that you are reluctant.

On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
support in mainline [1].
In case of U-Boot, the timer reset should be de-asserted when jumping
into the Kernel, as Rob mentionned [0].

Kind regards,
Maxime

[0]: https://lkml.org/lkml/2015/3/10/737
[1]: http://u-boot.10912.n7.nabble.com/PATCH-v2-stm32f4-fix-serial-output-td212812.html

[PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-05-21 19:58 GMT+02:00 Andreas F?rber <afaerber@suse.de>:
> Am 21.05.2015 um 09:46 schrieb Maxime Coquelin:
>> 2015-05-21 1:45 GMT+02:00 Andreas F?rber <afaerber@suse.de>:
>>> Am 09.05.2015 um 09:53 schrieb Maxime Coquelin:
>>>> +static const struct of_device_id stm32_reset_dt_ids[] = {
>>>> +      { .compatible = "st,stm32-rcc", },
>>>> +      { /* sentinel */ },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, sstm32_reset_dt_ids);
>>>
>>> Typo.
>>
>> Indeed, thanks for pointing this out.
>>
>>>
>>> IIUC the timer depends on the reset controller, so it must be built in
>>> anyway, and that's what's enforced in the Makefile above. Drop the line?
>>>
>>
>> Agree it must be built-in.
>> I will fix that in next version.
>
> Actually, I've updated a timer implementation of mine to invoke a reset
> controller similar to how you do in the STM32 clocksource patch, but no
> reset controller is getting returned.
>
> It seems to me, you are working around that by simply ignoring the error
> in the timer code and not doing a reset then, so the STM32 timer does in
> fact _not_ depend on the reset controller? What happened to your efforts
> of making the reset controller usable for the timer? In my case, my
> timer is originally in reset state and needs to be deasserted, so I
> can't just ignore it.

Indeed, I made the reset optionnal in the clocksource patch since v3.
Rob and Arnd said a lot of platform relies on such things are done by
the bootloader [0].
I decided to deassert timers reset at bootloader stage, and make it
optionnal in clocksource driver.
I made it optionnal in case we decide one day to move reset
initialization before timer are initialized.

Note that for now, I still use your bootloader.
I have done the changes to reset the timers in the afboot-stm32.
That's the reason why I asked you under which licence it is delivered
few months ago.
I can share you the patch if you want, even if I understand it is more
about the concept that you are reluctant.

On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
support in mainline [1].
In case of U-Boot, the timer reset should be de-asserted when jumping
into the Kernel, as Rob mentionned [0].

Kind regards,
Maxime

[0]: https://lkml.org/lkml/2015/3/10/737
[1]: http://u-boot.10912.n7.nabble.com/PATCH-v2-stm32f4-fix-serial-output-td212812.html

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-21 20:51 GMT+02:00 Maxime Ripard <maxime.ripard@free-electrons.com>:
> On Wed, May 20, 2015 at 06:17:34PM +0200, Maxime Coquelin wrote:
>> Hi Arnd, Philipp,
>>
>> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > Ideally the binding should follow closely what is documented
>> > in the data sheet.
>> >
>>
>> Daniel and myself would like your opinion about this binding:
>>
>> rcc: rcc@40023800 {
>>     #reset-cells = <1>;
>>     #clock-cells = <2>;
>>     compatible = "st,stm32-rcc";
>>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>>     reg-names = "clock-cfg", "reset", "clock-gates";
>> };
>>
>> It would solve a problem Daniel is facing due to conflicting mem
>> region when clock and reset drivers are enabled, as both would reserve
>> the same region.
>>
>> Also, it would make the reset driver very generic.
>> Doing that, we could even create a generic-reset.c driver that would
>> be used by STM32 and Sunxi (at least).
>> In the probe function, it would check the number of reg resources.
>> If a single resource is passed, it would take it, else it would look
>> the one named "reset".
>> The driver and bindings would be the same for the two families, and
>> the bindings would be backward compatible with sunxi ones.
>>
>> Philip, Arnd, what do you think?
>
> I lack a bit of context here, but I'd be very happy to use a generic
> driver. As a matter of fact, the sunxi reset driver is already pretty
> much there (not that it's very difficult to do).

Ok, good. The two drivers are almost the same, so squashing to a
generic one would be trivial.

>
> The only thing we did that stands out a bit is that we actually need
> the reset driver much earlier than the default probe, since some of
> our timers are maintained in reset. We have some code to do just that
> already, we just need have something similar to be on board.

We have the same problem on stm32, as just discussed with Andreas [0].
I decided to patch the bootloader to deassert timers reset, after
discussions with Rob Herring and Arnd.

Moving to a common driver, stm32 could use the same early init method
to initiliaze reset before timers.

Regards,
Maxime

[0]: http://marc.info/?l=linux-arm-kernel&m=143223846802405&w=2#0

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-21 20:51 GMT+02:00 Maxime Ripard <maxime.ripard@free-electrons.com>:
> On Wed, May 20, 2015 at 06:17:34PM +0200, Maxime Coquelin wrote:
>> Hi Arnd, Philipp,
>>
>> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > Ideally the binding should follow closely what is documented
>> > in the data sheet.
>> >
>>
>> Daniel and myself would like your opinion about this binding:
>>
>> rcc: rcc@40023800 {
>>     #reset-cells = <1>;
>>     #clock-cells = <2>;
>>     compatible = "st,stm32-rcc";
>>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>>     reg-names = "clock-cfg", "reset", "clock-gates";
>> };
>>
>> It would solve a problem Daniel is facing due to conflicting mem
>> region when clock and reset drivers are enabled, as both would reserve
>> the same region.
>>
>> Also, it would make the reset driver very generic.
>> Doing that, we could even create a generic-reset.c driver that would
>> be used by STM32 and Sunxi (at least).
>> In the probe function, it would check the number of reg resources.
>> If a single resource is passed, it would take it, else it would look
>> the one named "reset".
>> The driver and bindings would be the same for the two families, and
>> the bindings would be backward compatible with sunxi ones.
>>
>> Philip, Arnd, what do you think?
>
> I lack a bit of context here, but I'd be very happy to use a generic
> driver. As a matter of fact, the sunxi reset driver is already pretty
> much there (not that it's very difficult to do).

Ok, good. The two drivers are almost the same, so squashing to a
generic one would be trivial.

>
> The only thing we did that stands out a bit is that we actually need
> the reset driver much earlier than the default probe, since some of
> our timers are maintained in reset. We have some code to do just that
> already, we just need have something similar to be on board.

We have the same problem on stm32, as just discussed with Andreas [0].
I decided to patch the bootloader to deassert timers reset, after
discussions with Rob Herring and Arnd.

Moving to a common driver, stm32 could use the same early init method
to initiliaze reset before timers.

Regards,
Maxime

[0]: http://marc.info/?l=linux-arm-kernel&m=143223846802405&w=2#0

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-21 20:51 GMT+02:00 Maxime Ripard <maxime.ripard@free-electrons.com>:
> On Wed, May 20, 2015 at 06:17:34PM +0200, Maxime Coquelin wrote:
>> Hi Arnd, Philipp,
>>
>> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > Ideally the binding should follow closely what is documented
>> > in the data sheet.
>> >
>>
>> Daniel and myself would like your opinion about this binding:
>>
>> rcc: rcc at 40023800 {
>>     #reset-cells = <1>;
>>     #clock-cells = <2>;
>>     compatible = "st,stm32-rcc";
>>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>>     reg-names = "clock-cfg", "reset", "clock-gates";
>> };
>>
>> It would solve a problem Daniel is facing due to conflicting mem
>> region when clock and reset drivers are enabled, as both would reserve
>> the same region.
>>
>> Also, it would make the reset driver very generic.
>> Doing that, we could even create a generic-reset.c driver that would
>> be used by STM32 and Sunxi (at least).
>> In the probe function, it would check the number of reg resources.
>> If a single resource is passed, it would take it, else it would look
>> the one named "reset".
>> The driver and bindings would be the same for the two families, and
>> the bindings would be backward compatible with sunxi ones.
>>
>> Philip, Arnd, what do you think?
>
> I lack a bit of context here, but I'd be very happy to use a generic
> driver. As a matter of fact, the sunxi reset driver is already pretty
> much there (not that it's very difficult to do).

Ok, good. The two drivers are almost the same, so squashing to a
generic one would be trivial.

>
> The only thing we did that stands out a bit is that we actually need
> the reset driver much earlier than the default probe, since some of
> our timers are maintained in reset. We have some code to do just that
> already, we just need have something similar to be on board.

We have the same problem on stm32, as just discussed with Andreas [0].
I decided to patch the bootloader to deassert timers reset, after
discussions with Rob Herring and Arnd.

Moving to a common driver, stm32 could use the same early init method
to initiliaze reset before timers.

Regards,
Maxime

[0]: http://marc.info/?l=linux-arm-kernel&m=143223846802405&w=2#0

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Andreas Färber]

Am 21.05.2015 um 21:57 schrieb Maxime Coquelin:
> 2015-05-21 19:58 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>> Actually, I've updated a timer implementation of mine to invoke a reset
>> controller similar to how you do in the STM32 clocksource patch, but no
>> reset controller is getting returned.
>>
>> It seems to me, you are working around that by simply ignoring the error
>> in the timer code and not doing a reset then, so the STM32 timer does in
>> fact _not_ depend on the reset controller? What happened to your efforts
>> of making the reset controller usable for the timer? In my case, my
>> timer is originally in reset state and needs to be deasserted, so I
>> can't just ignore it.
> 
> Indeed, I made the reset optionnal in the clocksource patch since v3.
> Rob and Arnd said a lot of platform relies on such things are done by
> the bootloader [0].
> I decided to deassert timers reset at bootloader stage, and make it
> optionnal in clocksource driver.
> I made it optionnal in case we decide one day to move reset
> initialization before timer are initialized.
> 
> Note that for now, I still use your bootloader.
> I have done the changes to reset the timers in the afboot-stm32.
> That's the reason why I asked you under which licence it is delivered
> few months ago.

Sorry, too many mails... The stm32 one is GPL-2.0, as parts of it were
derived from a U-Boot fork. (Personally I prefer GPL-2.0+; fm4 and
xmc4000 are MIT/X11.)

> I can share you the patch if you want, even if I understand it is more
> about the concept that you are reluctant.
> 
> On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
> support in mainline [1].

You're free to use any bootloader you like, but you will find it
difficult to build in USB etc. drivers given the sheer size of U-Boot.
That was my motivation for writing the tiny one. ;)

> In case of U-Boot, the timer reset should be de-asserted when jumping
> into the Kernel, as Rob mentionned [0].

Thanks, I've updated the xmc4000 one accordingly and can do the same for
stm32. But you are right that I consider that an ugly workaround,
although on the other hand my earlyprintk patches also depend on the
bootloader setting up GPIOs and UART.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Andreas Färber]

Am 21.05.2015 um 21:57 schrieb Maxime Coquelin:
> 2015-05-21 19:58 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>> Actually, I've updated a timer implementation of mine to invoke a reset
>> controller similar to how you do in the STM32 clocksource patch, but no
>> reset controller is getting returned.
>>
>> It seems to me, you are working around that by simply ignoring the error
>> in the timer code and not doing a reset then, so the STM32 timer does in
>> fact _not_ depend on the reset controller? What happened to your efforts
>> of making the reset controller usable for the timer? In my case, my
>> timer is originally in reset state and needs to be deasserted, so I
>> can't just ignore it.
> 
> Indeed, I made the reset optionnal in the clocksource patch since v3.
> Rob and Arnd said a lot of platform relies on such things are done by
> the bootloader [0].
> I decided to deassert timers reset at bootloader stage, and make it
> optionnal in clocksource driver.
> I made it optionnal in case we decide one day to move reset
> initialization before timer are initialized.
> 
> Note that for now, I still use your bootloader.
> I have done the changes to reset the timers in the afboot-stm32.
> That's the reason why I asked you under which licence it is delivered
> few months ago.

Sorry, too many mails... The stm32 one is GPL-2.0, as parts of it were
derived from a U-Boot fork. (Personally I prefer GPL-2.0+; fm4 and
xmc4000 are MIT/X11.)

> I can share you the patch if you want, even if I understand it is more
> about the concept that you are reluctant.
> 
> On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
> support in mainline [1].

You're free to use any bootloader you like, but you will find it
difficult to build in USB etc. drivers given the sheer size of U-Boot.
That was my motivation for writing the tiny one. ;)

> In case of U-Boot, the timer reset should be de-asserted when jumping
> into the Kernel, as Rob mentionned [0].

Thanks, I've updated the xmc4000 one accordingly and can do the same for
stm32. But you are right that I consider that an ugly workaround,
although on the other hand my earlyprintk patches also depend on the
bootloader setting up GPIOs and UART.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

[PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Andreas Färber]

Am 21.05.2015 um 21:57 schrieb Maxime Coquelin:
> 2015-05-21 19:58 GMT+02:00 Andreas F?rber <afaerber@suse.de>:
>> Actually, I've updated a timer implementation of mine to invoke a reset
>> controller similar to how you do in the STM32 clocksource patch, but no
>> reset controller is getting returned.
>>
>> It seems to me, you are working around that by simply ignoring the error
>> in the timer code and not doing a reset then, so the STM32 timer does in
>> fact _not_ depend on the reset controller? What happened to your efforts
>> of making the reset controller usable for the timer? In my case, my
>> timer is originally in reset state and needs to be deasserted, so I
>> can't just ignore it.
> 
> Indeed, I made the reset optionnal in the clocksource patch since v3.
> Rob and Arnd said a lot of platform relies on such things are done by
> the bootloader [0].
> I decided to deassert timers reset at bootloader stage, and make it
> optionnal in clocksource driver.
> I made it optionnal in case we decide one day to move reset
> initialization before timer are initialized.
> 
> Note that for now, I still use your bootloader.
> I have done the changes to reset the timers in the afboot-stm32.
> That's the reason why I asked you under which licence it is delivered
> few months ago.

Sorry, too many mails... The stm32 one is GPL-2.0, as parts of it were
derived from a U-Boot fork. (Personally I prefer GPL-2.0+; fm4 and
xmc4000 are MIT/X11.)

> I can share you the patch if you want, even if I understand it is more
> about the concept that you are reluctant.
> 
> On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
> support in mainline [1].

You're free to use any bootloader you like, but you will find it
difficult to build in USB etc. drivers given the sheer size of U-Boot.
That was my motivation for writing the tiny one. ;)

> In case of U-Boot, the timer reset should be de-asserted when jumping
> into the Kernel, as Rob mentionned [0].

Thanks, I've updated the xmc4000 one accordingly and can do the same for
stm32. But you are right that I consider that an ugly workaround,
although on the other hand my earlyprintk patches also depend on the
bootloader setting up GPIOs and UART.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Philipp Zabel]

Am Mittwoch, den 20.05.2015, 18:17 +0200 schrieb Maxime Coquelin:
> Hi Arnd, Philipp,
> 
> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> > Ideally the binding should follow closely what is documented
> > in the data sheet.
> >
> 
> Daniel and myself would like your opinion about this binding:
> 
> rcc: rcc@40023800 {
>     #reset-cells = <1>;
>     #clock-cells = <2>;
>     compatible = "st,stm32-rcc";
>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>     reg-names = "clock-cfg", "reset", "clock-gates";

"reset" singular, "clock-gates" plural seems inconsistent to me.

> };
> 
> It would solve a problem Daniel is facing due to conflicting mem
> region when clock and reset drivers are enabled, as both would reserve
> the same region.
> 
> Also, it would make the reset driver very generic.
> Doing that, we could even create a generic-reset.c driver that would
> be used by STM32 and Sunxi (at least).

Adding support for providing the reset register range via of_device_id
data and the possibility to invert set/clear ops would allow to also
include the socfpga driver.

> In the probe function, it would check the number of reg resources.
> If a single resource is passed, it would take it, else it would look
> the one named "reset".
> The driver and bindings would be the same for the two families, and
> the bindings would be backward compatible with sunxi ones.
> 
> Philip, Arnd, what do you think?

I'm not a fan of describing the register layout in the device tree as
detailed as the sunxi bindings do. I'd prefer the reg property to
describe the device's register address space with one entry per
contiguous block of registers.
Unifying the mostly identical drivers is a good idea though, and reusing
preexisting bindings is better than inventing new ones. I favor the
socfpga binding, but I still like the sunxi bindings and this proposal
better than encoding the register offset in the reset index.

best regards
Philipp

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Philipp Zabel]

Am Mittwoch, den 20.05.2015, 18:17 +0200 schrieb Maxime Coquelin:
> Hi Arnd, Philipp,
> 
> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> > Ideally the binding should follow closely what is documented
> > in the data sheet.
> >
> 
> Daniel and myself would like your opinion about this binding:
> 
> rcc: rcc at 40023800 {
>     #reset-cells = <1>;
>     #clock-cells = <2>;
>     compatible = "st,stm32-rcc";
>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>     reg-names = "clock-cfg", "reset", "clock-gates";

"reset" singular, "clock-gates" plural seems inconsistent to me.

> };
> 
> It would solve a problem Daniel is facing due to conflicting mem
> region when clock and reset drivers are enabled, as both would reserve
> the same region.
> 
> Also, it would make the reset driver very generic.
> Doing that, we could even create a generic-reset.c driver that would
> be used by STM32 and Sunxi (at least).

Adding support for providing the reset register range via of_device_id
data and the possibility to invert set/clear ops would allow to also
include the socfpga driver.

> In the probe function, it would check the number of reg resources.
> If a single resource is passed, it would take it, else it would look
> the one named "reset".
> The driver and bindings would be the same for the two families, and
> the bindings would be backward compatible with sunxi ones.
> 
> Philip, Arnd, what do you think?

I'm not a fan of describing the register layout in the device tree as
detailed as the sunxi bindings do. I'd prefer the reg property to
describe the device's register address space with one entry per
contiguous block of registers.
Unifying the mostly identical drivers is a good idea though, and reusing
preexisting bindings is better than inventing new ones. I favor the
socfpga binding, but I still like the sunxi bindings and this proposal
better than encoding the register offset in the reset index.

best regards
Philipp

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1261 bytes --]

On Fri, May 22, 2015 at 11:06:28AM +0200, Philipp Zabel wrote:
> > In the probe function, it would check the number of reg resources.
> > If a single resource is passed, it would take it, else it would look
> > the one named "reset".
> > The driver and bindings would be the same for the two families, and
> > the bindings would be backward compatible with sunxi ones.
> > 
> > Philip, Arnd, what do you think?
> 
> I'm not a fan of describing the register layout in the device tree as
> detailed as the sunxi bindings do. I'd prefer the reg property to
> describe the device's register address space with one entry per
> contiguous block of registers.

That's exactly what we do.

> Unifying the mostly identical drivers is a good idea though, and reusing
> preexisting bindings is better than inventing new ones. I favor the
> socfpga binding, but I still like the sunxi bindings and this proposal
> better than encoding the register offset in the reset index.

I don't really get the difference between the socfpga and our bindings
actually. Would you mind to explain a bit further what you don't like
about it ?

Maxime
-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Ripard]

On Fri, May 22, 2015 at 11:06:28AM +0200, Philipp Zabel wrote:
> > In the probe function, it would check the number of reg resources.
> > If a single resource is passed, it would take it, else it would look
> > the one named "reset".
> > The driver and bindings would be the same for the two families, and
> > the bindings would be backward compatible with sunxi ones.
> > 
> > Philip, Arnd, what do you think?
> 
> I'm not a fan of describing the register layout in the device tree as
> detailed as the sunxi bindings do. I'd prefer the reg property to
> describe the device's register address space with one entry per
> contiguous block of registers.

That's exactly what we do.

> Unifying the mostly identical drivers is a good idea though, and reusing
> preexisting bindings is better than inventing new ones. I favor the
> socfpga binding, but I still like the sunxi bindings and this proposal
> better than encoding the register offset in the reset index.

I don't really get the difference between the socfpga and our bindings
actually. Would you mind to explain a bit further what you don't like
about it ?

Maxime
-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150522/fa7eac4f/attachment.sig>

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-22 11:06 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Am Mittwoch, den 20.05.2015, 18:17 +0200 schrieb Maxime Coquelin:
>> Hi Arnd, Philipp,
>>
>> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > Ideally the binding should follow closely what is documented
>> > in the data sheet.
>> >
>>
>> Daniel and myself would like your opinion about this binding:
>>
>> rcc: rcc@40023800 {
>>     #reset-cells = <1>;
>>     #clock-cells = <2>;
>>     compatible = "st,stm32-rcc";
>>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>>     reg-names = "clock-cfg", "reset", "clock-gates";
>
> "reset" singular, "clock-gates" plural seems inconsistent to me.
Indeed. I will change to "resets".

About the compatible string, any idea how could I name it?

>
>> };
>>
>> It would solve a problem Daniel is facing due to conflicting mem
>> region when clock and reset drivers are enabled, as both would reserve
>> the same region.
>>
>> Also, it would make the reset driver very generic.
>> Doing that, we could even create a generic-reset.c driver that would
>> be used by STM32 and Sunxi (at least).
>
> Adding support for providing the reset register range via of_device_id
> data and the possibility to invert set/clear ops would allow to also
> include the socfpga driver.

Ok, it sounds like a good plan.
Should I also add a property in the bindings for the reset polarity?
It won't be used for now, as for socfpga we have to do it via
of_device_id data, in order not to break DT backward compatibility.

>
>> In the probe function, it would check the number of reg resources.
>> If a single resource is passed, it would take it, else it would look
>> the one named "reset".
>> The driver and bindings would be the same for the two families, and
>> the bindings would be backward compatible with sunxi ones.
>>
>> Philip, Arnd, what do you think?
>
> I'm not a fan of describing the register layout in the device tree as
> detailed as the sunxi bindings do. I'd prefer the reg property to
> describe the device's register address space with one entry per
> contiguous block of registers.
> Unifying the mostly identical drivers is a good idea though, and reusing
> preexisting bindings is better than inventing new ones. I favor the
> socfpga binding, but I still like the sunxi bindings and this proposal
> better than encoding the register offset in the reset index.

Ok, I will propose a RFC.

Thanks,
Maxime

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-22 11:06 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Am Mittwoch, den 20.05.2015, 18:17 +0200 schrieb Maxime Coquelin:
>> Hi Arnd, Philipp,
>>
>> 2015-05-13 21:11 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > Ideally the binding should follow closely what is documented
>> > in the data sheet.
>> >
>>
>> Daniel and myself would like your opinion about this binding:
>>
>> rcc: rcc at 40023800 {
>>     #reset-cells = <1>;
>>     #clock-cells = <2>;
>>     compatible = "st,stm32-rcc";
>>     reg = <0x40023800 0x10>, <0x40023810 0x20>, <0x40023830 0x20>;
>>     reg-names = "clock-cfg", "reset", "clock-gates";
>
> "reset" singular, "clock-gates" plural seems inconsistent to me.
Indeed. I will change to "resets".

About the compatible string, any idea how could I name it?

>
>> };
>>
>> It would solve a problem Daniel is facing due to conflicting mem
>> region when clock and reset drivers are enabled, as both would reserve
>> the same region.
>>
>> Also, it would make the reset driver very generic.
>> Doing that, we could even create a generic-reset.c driver that would
>> be used by STM32 and Sunxi (at least).
>
> Adding support for providing the reset register range via of_device_id
> data and the possibility to invert set/clear ops would allow to also
> include the socfpga driver.

Ok, it sounds like a good plan.
Should I also add a property in the bindings for the reset polarity?
It won't be used for now, as for socfpga we have to do it via
of_device_id data, in order not to break DT backward compatibility.

>
>> In the probe function, it would check the number of reg resources.
>> If a single resource is passed, it would take it, else it would look
>> the one named "reset".
>> The driver and bindings would be the same for the two families, and
>> the bindings would be backward compatible with sunxi ones.
>>
>> Philip, Arnd, what do you think?
>
> I'm not a fan of describing the register layout in the device tree as
> detailed as the sunxi bindings do. I'd prefer the reg property to
> describe the device's register address space with one entry per
> contiguous block of registers.
> Unifying the mostly identical drivers is a good idea though, and reusing
> preexisting bindings is better than inventing new ones. I favor the
> socfpga binding, but I still like the sunxi bindings and this proposal
> better than encoding the register offset in the reset index.

Ok, I will propose a RFC.

Thanks,
Maxime

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Philipp Zabel]

Am Freitag, den 22.05.2015, 11:18 +0200 schrieb Maxime Ripard:
> On Fri, May 22, 2015 at 11:06:28AM +0200, Philipp Zabel wrote:
> > > In the probe function, it would check the number of reg resources.
> > > If a single resource is passed, it would take it, else it would look
> > > the one named "reset".
> > > The driver and bindings would be the same for the two families, and
> > > the bindings would be backward compatible with sunxi ones.
> > > 
> > > Philip, Arnd, what do you think?
> > 
> > I'm not a fan of describing the register layout in the device tree as
> > detailed as the sunxi bindings do. I'd prefer the reg property to
> > describe the device's register address space with one entry per
> > contiguous block of registers.
> 
> That's exactly what we do.

Sorry, what I mean is 'as detailed as reusing the sunxi bindings for
stm32xx here would do'. I don't know enough about the Allwinner register
layouts to form an opinion.

The STM32F427xx/STM32F429xx manual, Table 13. "STM32F427xx and
STM32F429xx register boundary addresses" contains this entry:
    Bus    Boundary address       Peripheral
    AHB1   0x40023800-0x400238bf  RCC

And that's how I'd expect it to be described by the device tree:

    rcc: rcc@40023800 {
        compatible = "st,stm32-rcc";
        reg = <0x40023800 0xc0>;
    };

Instead of "reg = <0x40023810 0x20>" for the resets. Where in the
address range the reset, clock gate and clock configuration registers
reside could be derived from the compatible value.

> > Unifying the mostly identical drivers is a good idea though, and reusing
> > preexisting bindings is better than inventing new ones. I favor the
> > socfpga binding, but I still like the sunxi bindings and this proposal
> > better than encoding the register offset in the reset index.
> 
> I don't really get the difference between the socfpga and our bindings
> actually. Would you mind to explain a bit further what you don't like
> about it ?

The socfpga driver currently hardcodes the reset register offset (0x10)
and number of banks (4), the sunxi driver has no register offset (0x0)
and derives the number of banks from the resource size.
I'd store the internal register offsets and number of banks in the
driver, together with the compatible string.

regards
Philipp

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Philipp Zabel]

Am Freitag, den 22.05.2015, 11:18 +0200 schrieb Maxime Ripard:
> On Fri, May 22, 2015 at 11:06:28AM +0200, Philipp Zabel wrote:
> > > In the probe function, it would check the number of reg resources.
> > > If a single resource is passed, it would take it, else it would look
> > > the one named "reset".
> > > The driver and bindings would be the same for the two families, and
> > > the bindings would be backward compatible with sunxi ones.
> > > 
> > > Philip, Arnd, what do you think?
> > 
> > I'm not a fan of describing the register layout in the device tree as
> > detailed as the sunxi bindings do. I'd prefer the reg property to
> > describe the device's register address space with one entry per
> > contiguous block of registers.
> 
> That's exactly what we do.

Sorry, what I mean is 'as detailed as reusing the sunxi bindings for
stm32xx here would do'. I don't know enough about the Allwinner register
layouts to form an opinion.

The STM32F427xx/STM32F429xx manual, Table 13. "STM32F427xx and
STM32F429xx register boundary addresses" contains this entry:
    Bus    Boundary address       Peripheral
    AHB1   0x40023800-0x400238bf  RCC

And that's how I'd expect it to be described by the device tree:

    rcc: rcc at 40023800 {
        compatible = "st,stm32-rcc";
        reg = <0x40023800 0xc0>;
    };

Instead of "reg = <0x40023810 0x20>" for the resets. Where in the
address range the reset, clock gate and clock configuration registers
reside could be derived from the compatible value.

> > Unifying the mostly identical drivers is a good idea though, and reusing
> > preexisting bindings is better than inventing new ones. I favor the
> > socfpga binding, but I still like the sunxi bindings and this proposal
> > better than encoding the register offset in the reset index.
> 
> I don't really get the difference between the socfpga and our bindings
> actually. Would you mind to explain a bit further what you don't like
> about it ?

The socfpga driver currently hardcodes the reset register offset (0x10)
and number of banks (4), the sunxi driver has no register offset (0x0)
and derives the number of banks from the resource size.
I'd store the internal register offsets and number of banks in the
driver, together with the compatible string.

regards
Philipp

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-22 12:07 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
> The STM32F427xx/STM32F429xx manual, Table 13. "STM32F427xx and
> STM32F429xx register boundary addresses" contains this entry:
>     Bus    Boundary address       Peripheral
>     AHB1   0x40023800-0x400238bf  RCC
>
> And that's how I'd expect it to be described by the device tree:
>
>     rcc: rcc@40023800 {
>         compatible = "st,stm32-rcc";
>         reg = <0x40023800 0xc0>;
>     };
>

Doing that, since this register bank contains both reset and clock
registers, the reset device cannot get the IO resource at probe time
because the clock driver has already reserved it.
Daniel, who has started to work on the clock driver is facing this issue.
This is why I proposed this binding for "reg" property.

We could think of creating a MFD driver, but the problem is that clock
need to be intialized before a MFD device can be probed.

Maybe there is a way to have you binding working properly, but I
haven't found one for now.

Regards,
Maxime

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-22 12:07 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
> The STM32F427xx/STM32F429xx manual, Table 13. "STM32F427xx and
> STM32F429xx register boundary addresses" contains this entry:
>     Bus    Boundary address       Peripheral
>     AHB1   0x40023800-0x400238bf  RCC
>
> And that's how I'd expect it to be described by the device tree:
>
>     rcc: rcc at 40023800 {
>         compatible = "st,stm32-rcc";
>         reg = <0x40023800 0xc0>;
>     };
>

Doing that, since this register bank contains both reset and clock
registers, the reset device cannot get the IO resource at probe time
because the clock driver has already reserved it.
Daniel, who has started to work on the clock driver is facing this issue.
This is why I proposed this binding for "reg" property.

We could think of creating a MFD driver, but the problem is that clock
need to be intialized before a MFD device can be probed.

Maybe there is a way to have you binding working properly, but I
haven't found one for now.

Regards,
Maxime

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 22/05/15 13:32, Maxime Coquelin wrote:
> 2015-05-22 12:07 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> And that's how I'd expect it to be described by the device tree:
>>
>>      rcc: rcc@40023800 {
>>          compatible = "st,stm32-rcc";
>>          reg = <0x40023800 0xc0>;
>>      };
>>
>
> Doing that, since this register bank contains both reset and clock
> registers, the reset device cannot get the IO resource at probe time
> because the clock driver has already reserved it.
> Daniel, who has started to work on the clock driver is facing this issue.
> This is why I proposed this binding for "reg" property.

Temporarily I've kept things working for me by avoiding 
of_io_request_and_map() in the clock driver (I am using raw of_iomap() 
instead).

I view this as a hack rather than a solution!

Note that, with or without the hack, I do hope to be able to post the 
clock driver this weekend. I am acutely aware that at the moment we are 
discussing code I haven't posted yet.


> We could think of creating a MFD driver, but the problem is that clock
> need to be intialized before a MFD device can be probed.
>
> Maybe there is a way to have you binding working properly, but I
> haven't found one for now.

I guess a driver doesn't *have* to reserve all the register space 
described in DT. The driver could replace of_io_request_and_map() with 
lower level calls.

Thus if we wanted to keep this detail out of DT then I guess the two 
drivers could simply make an agreement not to request registers they do 
not use.

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 22/05/15 13:32, Maxime Coquelin wrote:
> 2015-05-22 12:07 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> And that's how I'd expect it to be described by the device tree:
>>
>>      rcc: rcc@40023800 {
>>          compatible = "st,stm32-rcc";
>>          reg = <0x40023800 0xc0>;
>>      };
>>
>
> Doing that, since this register bank contains both reset and clock
> registers, the reset device cannot get the IO resource at probe time
> because the clock driver has already reserved it.
> Daniel, who has started to work on the clock driver is facing this issue.
> This is why I proposed this binding for "reg" property.

Temporarily I've kept things working for me by avoiding 
of_io_request_and_map() in the clock driver (I am using raw of_iomap() 
instead).

I view this as a hack rather than a solution!

Note that, with or without the hack, I do hope to be able to post the 
clock driver this weekend. I am acutely aware that at the moment we are 
discussing code I haven't posted yet.


> We could think of creating a MFD driver, but the problem is that clock
> need to be intialized before a MFD device can be probed.
>
> Maybe there is a way to have you binding working properly, but I
> haven't found one for now.

I guess a driver doesn't *have* to reserve all the register space 
described in DT. The driver could replace of_io_request_and_map() with 
lower level calls.

Thus if we wanted to keep this detail out of DT then I guess the two 
drivers could simply make an agreement not to request registers they do 
not use.

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 22/05/15 13:32, Maxime Coquelin wrote:
> 2015-05-22 12:07 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> And that's how I'd expect it to be described by the device tree:
>>
>>      rcc: rcc at 40023800 {
>>          compatible = "st,stm32-rcc";
>>          reg = <0x40023800 0xc0>;
>>      };
>>
>
> Doing that, since this register bank contains both reset and clock
> registers, the reset device cannot get the IO resource at probe time
> because the clock driver has already reserved it.
> Daniel, who has started to work on the clock driver is facing this issue.
> This is why I proposed this binding for "reg" property.

Temporarily I've kept things working for me by avoiding 
of_io_request_and_map() in the clock driver (I am using raw of_iomap() 
instead).

I view this as a hack rather than a solution!

Note that, with or without the hack, I do hope to be able to post the 
clock driver this weekend. I am acutely aware that at the moment we are 
discussing code I haven't posted yet.


> We could think of creating a MFD driver, but the problem is that clock
> need to be intialized before a MFD device can be probed.
>
> Maybe there is a way to have you binding working properly, but I
> haven't found one for now.

I guess a driver doesn't *have* to reserve all the register space 
described in DT. The driver could replace of_io_request_and_map() with 
lower level calls.

Thus if we wanted to keep this detail out of DT then I guess the two 
drivers could simply make an agreement not to request registers they do 
not use.

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Andreas Färber]

Am 22.05.2015 um 14:32 schrieb Maxime Coquelin:
> 2015-05-22 12:07 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> The STM32F427xx/STM32F429xx manual, Table 13. "STM32F427xx and
>> STM32F429xx register boundary addresses" contains this entry:
>>     Bus    Boundary address       Peripheral
>>     AHB1   0x40023800-0x400238bf  RCC
>>
>> And that's how I'd expect it to be described by the device tree:
>>
>>     rcc: rcc@40023800 {
>>         compatible = "st,stm32-rcc";
>>         reg = <0x40023800 0xc0>;
>>     };
>>
> 
> Doing that, since this register bank contains both reset and clock
> registers, the reset device cannot get the IO resource at probe time
> because the clock driver has already reserved it.
> Daniel, who has started to work on the clock driver is facing this issue.
> This is why I proposed this binding for "reg" property.

As you should know, I did have an RCC clk driver, and there is no such
issue. The two drivers use different mechanisms for initialization. And
I'm pretty sure that I've already remarked that on the list, too.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Andreas Färber]

Am 22.05.2015 um 14:32 schrieb Maxime Coquelin:
> 2015-05-22 12:07 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> The STM32F427xx/STM32F429xx manual, Table 13. "STM32F427xx and
>> STM32F429xx register boundary addresses" contains this entry:
>>     Bus    Boundary address       Peripheral
>>     AHB1   0x40023800-0x400238bf  RCC
>>
>> And that's how I'd expect it to be described by the device tree:
>>
>>     rcc: rcc at 40023800 {
>>         compatible = "st,stm32-rcc";
>>         reg = <0x40023800 0xc0>;
>>     };
>>
> 
> Doing that, since this register bank contains both reset and clock
> registers, the reset device cannot get the IO resource at probe time
> because the clock driver has already reserved it.
> Daniel, who has started to work on the clock driver is facing this issue.
> This is why I proposed this binding for "reg" property.

As you should know, I did have an RCC clk driver, and there is no such
issue. The two drivers use different mechanisms for initialization. And
I'm pretty sure that I've already remarked that on the list, too.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-22 15:09 GMT+02:00 Andreas Färber <afaerber@suse.de>:
> As you should know, I did have an RCC clk driver, and there is no such
> issue. The two drivers use different mechanisms for initialization. And
> I'm pretty sure that I've already remarked that on the list, too.

Yes, you use of_iomap in your clock driver [0].
Daniel, would you accept to do the same?
That would remove one difference between stm32/sunxi/socfpga reset drivers.

Regards,
Maxime

[0]: https://github.com/afaerber/linux/blob/stm32/drivers/clk/clk-stm32f42xxx-rcc.c
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-22 15:09 GMT+02:00 Andreas Färber <afaerber@suse.de>:
> As you should know, I did have an RCC clk driver, and there is no such
> issue. The two drivers use different mechanisms for initialization. And
> I'm pretty sure that I've already remarked that on the list, too.

Yes, you use of_iomap in your clock driver [0].
Daniel, would you accept to do the same?
That would remove one difference between stm32/sunxi/socfpga reset drivers.

Regards,
Maxime

[0]: https://github.com/afaerber/linux/blob/stm32/drivers/clk/clk-stm32f42xxx-rcc.c

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

2015-05-22 15:09 GMT+02:00 Andreas F?rber <afaerber@suse.de>:
> As you should know, I did have an RCC clk driver, and there is no such
> issue. The two drivers use different mechanisms for initialization. And
> I'm pretty sure that I've already remarked that on the list, too.

Yes, you use of_iomap in your clock driver [0].
Daniel, would you accept to do the same?
That would remove one difference between stm32/sunxi/socfpga reset drivers.

Regards,
Maxime

[0]: https://github.com/afaerber/linux/blob/stm32/drivers/clk/clk-stm32f42xxx-rcc.c

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-05-22 0:01 GMT+02:00 Andreas Färber <afaerber@suse.de>:
> Am 21.05.2015 um 21:57 schrieb Maxime Coquelin:
>> Note that for now, I still use your bootloader.
>> I have done the changes to reset the timers in the afboot-stm32.
>> That's the reason why I asked you under which licence it is delivered
>> few months ago.
>
> Sorry, too many mails... The stm32 one is GPL-2.0, as parts of it were
> derived from a U-Boot fork. (Personally I prefer GPL-2.0+; fm4 and
> xmc4000 are MIT/X11.)

Not a problem, thanks for providing the licence.

>> I can share you the patch if you want, even if I understand it is more
>> about the concept that you are reluctant.
>>
>> On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
>> support in mainline [1].
>
> You're free to use any bootloader you like, but you will find it
> difficult to build in USB etc. drivers given the sheer size of U-Boot.
> That was my motivation for writing the tiny one. ;)

I think the two bootloaders make sense. Indeed, using U-Boot restricts
the size of the Kernel.
I also have the stm32429i-eval board, with 32MB NOR and 32MB SD-Ram.
At least on this one I will use U-Boot, as tftp could be used to load
Kernel since it has Ethernet port.

>> In case of U-Boot, the timer reset should be de-asserted when jumping
>> into the Kernel, as Rob mentionned [0].
>
> Thanks, I've updated the xmc4000 one accordingly and can do the same for
> stm32. But you are right that I consider that an ugly workaround,
> although on the other hand my earlyprintk patches also depend on the
> bootloader setting up GPIOs and UART.

Yes, the Kernel always need to rely on the bootloader to provide a
minimal setup (clock/ddr/muxing...).

Regards,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-05-22 0:01 GMT+02:00 Andreas Färber <afaerber@suse.de>:
> Am 21.05.2015 um 21:57 schrieb Maxime Coquelin:
>> Note that for now, I still use your bootloader.
>> I have done the changes to reset the timers in the afboot-stm32.
>> That's the reason why I asked you under which licence it is delivered
>> few months ago.
>
> Sorry, too many mails... The stm32 one is GPL-2.0, as parts of it were
> derived from a U-Boot fork. (Personally I prefer GPL-2.0+; fm4 and
> xmc4000 are MIT/X11.)

Not a problem, thanks for providing the licence.

>> I can share you the patch if you want, even if I understand it is more
>> about the concept that you are reluctant.
>>
>> On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
>> support in mainline [1].
>
> You're free to use any bootloader you like, but you will find it
> difficult to build in USB etc. drivers given the sheer size of U-Boot.
> That was my motivation for writing the tiny one. ;)

I think the two bootloaders make sense. Indeed, using U-Boot restricts
the size of the Kernel.
I also have the stm32429i-eval board, with 32MB NOR and 32MB SD-Ram.
At least on this one I will use U-Boot, as tftp could be used to load
Kernel since it has Ethernet port.

>> In case of U-Boot, the timer reset should be de-asserted when jumping
>> into the Kernel, as Rob mentionned [0].
>
> Thanks, I've updated the xmc4000 one accordingly and can do the same for
> stm32. But you are right that I consider that an ugly workaround,
> although on the other hand my earlyprintk patches also depend on the
> bootloader setting up GPIOs and UART.

Yes, the Kernel always need to rely on the bootloader to provide a
minimal setup (clock/ddr/muxing...).

Regards,
Maxime

[PATCH v8 07/16] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-05-22 0:01 GMT+02:00 Andreas F?rber <afaerber@suse.de>:
> Am 21.05.2015 um 21:57 schrieb Maxime Coquelin:
>> Note that for now, I still use your bootloader.
>> I have done the changes to reset the timers in the afboot-stm32.
>> That's the reason why I asked you under which licence it is delivered
>> few months ago.
>
> Sorry, too many mails... The stm32 one is GPL-2.0, as parts of it were
> derived from a U-Boot fork. (Personally I prefer GPL-2.0+; fm4 and
> xmc4000 are MIT/X11.)

Not a problem, thanks for providing the licence.

>> I can share you the patch if you want, even if I understand it is more
>> about the concept that you are reluctant.
>>
>> On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32
>> support in mainline [1].
>
> You're free to use any bootloader you like, but you will find it
> difficult to build in USB etc. drivers given the sheer size of U-Boot.
> That was my motivation for writing the tiny one. ;)

I think the two bootloaders make sense. Indeed, using U-Boot restricts
the size of the Kernel.
I also have the stm32429i-eval board, with 32MB NOR and 32MB SD-Ram.
At least on this one I will use U-Boot, as tftp could be used to load
Kernel since it has Ethernet port.

>> In case of U-Boot, the timer reset should be de-asserted when jumping
>> into the Kernel, as Rob mentionned [0].
>
> Thanks, I've updated the xmc4000 one accordingly and can do the same for
> stm32. But you are right that I consider that an ugly workaround,
> although on the other hand my earlyprintk patches also depend on the
> bootloader setting up GPIOs and UART.

Yes, the Kernel always need to rely on the bootloader to provide a
minimal setup (clock/ddr/muxing...).

Regards,
Maxime

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Andreas Färber]

Am 22.05.2015 um 15:57 schrieb Maxime Coquelin:
> 2015-05-22 15:09 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>> As you should know, I did have an RCC clk driver, and there is no such
>> issue. The two drivers use different mechanisms for initialization. And
>> I'm pretty sure that I've already remarked that on the list, too.
> 
> Yes, you use of_iomap in your clock driver [0].

Which was inspired by the efm32 driver iirc.

> Daniel, would you accept to do the same?
> That would remove one difference between stm32/sunxi/socfpga reset drivers.
> 
> Regards,
> Maxime
> 
> [0]: https://github.com/afaerber/linux/blob/stm32/drivers/clk/clk-stm32f42xxx-rcc.c

For the record, that still has some internal clocks that shouldn't be
exposed.

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Andreas Färber]

Am 22.05.2015 um 15:57 schrieb Maxime Coquelin:
> 2015-05-22 15:09 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>> As you should know, I did have an RCC clk driver, and there is no such
>> issue. The two drivers use different mechanisms for initialization. And
>> I'm pretty sure that I've already remarked that on the list, too.
> 
> Yes, you use of_iomap in your clock driver [0].

Which was inspired by the efm32 driver iirc.

> Daniel, would you accept to do the same?
> That would remove one difference between stm32/sunxi/socfpga reset drivers.
> 
> Regards,
> Maxime
> 
> [0]: https://github.com/afaerber/linux/blob/stm32/drivers/clk/clk-stm32f42xxx-rcc.c

For the record, that still has some internal clocks that shouldn't be
exposed.

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Andreas Färber]

Am 22.05.2015 um 15:57 schrieb Maxime Coquelin:
> 2015-05-22 15:09 GMT+02:00 Andreas F?rber <afaerber@suse.de>:
>> As you should know, I did have an RCC clk driver, and there is no such
>> issue. The two drivers use different mechanisms for initialization. And
>> I'm pretty sure that I've already remarked that on the list, too.
> 
> Yes, you use of_iomap in your clock driver [0].

Which was inspired by the efm32 driver iirc.

> Daniel, would you accept to do the same?
> That would remove one difference between stm32/sunxi/socfpga reset drivers.
> 
> Regards,
> Maxime
> 
> [0]: https://github.com/afaerber/linux/blob/stm32/drivers/clk/clk-stm32f42xxx-rcc.c

For the record, that still has some internal clocks that shouldn't be
exposed.

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 22/05/15 14:57, Maxime Coquelin wrote:
> 2015-05-22 15:09 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>> As you should know, I did have an RCC clk driver, and there is no such
>> issue. The two drivers use different mechanisms for initialization. And
>> I'm pretty sure that I've already remarked that on the list, too.
>
> Yes, you use of_iomap in your clock driver [0].
> Daniel, would you accept to do the same?
> That would remove one difference between stm32/sunxi/socfpga reset drivers.

In fact, that is exactly what I am currently doing, though I was 
planning for it to be temporary.

It seems a bit weird to me that one driver (which requests too much 
register space) only works because another driver chooses not to request 
any.

BTW in drivers/clk there are ~110 of_iomaps and only 10 
of_io_request_and_maps... so I don't think anyone will yell at me for 
using of_iomap().


Daniel.

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 22/05/15 14:57, Maxime Coquelin wrote:
> 2015-05-22 15:09 GMT+02:00 Andreas Färber <afaerber@suse.de>:
>> As you should know, I did have an RCC clk driver, and there is no such
>> issue. The two drivers use different mechanisms for initialization. And
>> I'm pretty sure that I've already remarked that on the list, too.
>
> Yes, you use of_iomap in your clock driver [0].
> Daniel, would you accept to do the same?
> That would remove one difference between stm32/sunxi/socfpga reset drivers.

In fact, that is exactly what I am currently doing, though I was 
planning for it to be temporary.

It seems a bit weird to me that one driver (which requests too much 
register space) only works because another driver chooses not to request 
any.

BTW in drivers/clk there are ~110 of_iomaps and only 10 
of_io_request_and_maps... so I don't think anyone will yell at me for 
using of_iomap().


Daniel.

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Daniel Thompson]

On 22/05/15 14:57, Maxime Coquelin wrote:
> 2015-05-22 15:09 GMT+02:00 Andreas F?rber <afaerber@suse.de>:
>> As you should know, I did have an RCC clk driver, and there is no such
>> issue. The two drivers use different mechanisms for initialization. And
>> I'm pretty sure that I've already remarked that on the list, too.
>
> Yes, you use of_iomap in your clock driver [0].
> Daniel, would you accept to do the same?
> That would remove one difference between stm32/sunxi/socfpga reset drivers.

In fact, that is exactly what I am currently doing, though I was 
planning for it to be temporary.

It seems a bit weird to me that one driver (which requests too much 
register space) only works because another driver chooses not to request 
any.

BTW in drivers/clk there are ~110 of_iomaps and only 10 
of_io_request_and_maps... so I don't think anyone will yell at me for 
using of_iomap().


Daniel.

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Andreas Färber]

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

Am 21.05.2015 um 01:04 schrieb Andreas Färber:
> Hi,
> 
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
>> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>> When Kernel is executed in place from ROM, the symbol addresses can be
>>> lower than the page offset.
>>>
>>> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[...]
> Back then on STM32F4 I debugged that disabling KALLSYMS works around it.
> 
> Now on a different XIP target I have confirmed this patch to help show a
> stacktrace (my clk driver was missing some CLK_DIVIDER_ALLOW_ZEROs) ...
> although my earlyprintk serial output still gets stuck further down the
> stacktrace - probably unrelated.

FTR confirming my suspicion: insufficient power supply. ;)

Andreas

> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:126
> divider_recalc_rate+0x2b/0x44()
> [    0.000000] SYS: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.1.0-rc4-next-20150519+ #23
> [    0.000000] Hardware name: XMC4000 (Device Tree Support)
> [    0.000000] [<0800bd5d>] (unwind_backtrace) from [<0800b0cb>]
> (show_stack+0xb/0xc)
> [    0.000000] [<0800b0cb>] (show_stack) from [<0800e0a5>]
> (warn_slowpath_common+0x55/0x78)
> [    0.000000] [<0800e0a5>] (warn_slowpath_common) from [<0800e103>]
> (warn_slowpath_fmt+0x1b/0x24)
> [    0.000000] [<0800e103>] (warn_slowpath_fmt) from [<080942e3>] (divide
> 
> But this is definitely an improvement for ARMv7-M debugging,
> 
> Tested-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Andreas Färber]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

Am 21.05.2015 um 01:04 schrieb Andreas Färber:
> Hi,
> 
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
>> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>>> When Kernel is executed in place from ROM, the symbol addresses can be
>>> lower than the page offset.
>>>
>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
[...]
> Back then on STM32F4 I debugged that disabling KALLSYMS works around it.
> 
> Now on a different XIP target I have confirmed this patch to help show a
> stacktrace (my clk driver was missing some CLK_DIVIDER_ALLOW_ZEROs) ...
> although my earlyprintk serial output still gets stuck further down the
> stacktrace - probably unrelated.

FTR confirming my suspicion: insufficient power supply. ;)

Andreas

> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:126
> divider_recalc_rate+0x2b/0x44()
> [    0.000000] SYS: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.1.0-rc4-next-20150519+ #23
> [    0.000000] Hardware name: XMC4000 (Device Tree Support)
> [    0.000000] [<0800bd5d>] (unwind_backtrace) from [<0800b0cb>]
> (show_stack+0xb/0xc)
> [    0.000000] [<0800b0cb>] (show_stack) from [<0800e0a5>]
> (warn_slowpath_common+0x55/0x78)
> [    0.000000] [<0800e0a5>] (warn_slowpath_common) from [<0800e103>]
> (warn_slowpath_fmt+0x1b/0x24)
> [    0.000000] [<0800e103>] (warn_slowpath_fmt) from [<080942e3>] (divide
> 
> But this is definitely an improvement for ARMv7-M debugging,
> 
> Tested-by: Andreas Färber <afaerber@suse.de>

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

[Andreas Färber]

Am 21.05.2015 um 01:04 schrieb Andreas F?rber:
> Hi,
> 
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
>> 2015-05-09 9:53 GMT+02:00 Maxime Coquelin <mcoquelin.stm32@gmail.com>:
>>> When Kernel is executed in place from ROM, the symbol addresses can be
>>> lower than the page offset.
>>>
>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
[...]
> Back then on STM32F4 I debugged that disabling KALLSYMS works around it.
> 
> Now on a different XIP target I have confirmed this patch to help show a
> stacktrace (my clk driver was missing some CLK_DIVIDER_ALLOW_ZEROs) ...
> although my earlyprintk serial output still gets stuck further down the
> stacktrace - probably unrelated.

FTR confirming my suspicion: insufficient power supply. ;)

Andreas

> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:126
> divider_recalc_rate+0x2b/0x44()
> [    0.000000] SYS: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.1.0-rc4-next-20150519+ #23
> [    0.000000] Hardware name: XMC4000 (Device Tree Support)
> [    0.000000] [<0800bd5d>] (unwind_backtrace) from [<0800b0cb>]
> (show_stack+0xb/0xc)
> [    0.000000] [<0800b0cb>] (show_stack) from [<0800e0a5>]
> (warn_slowpath_common+0x55/0x78)
> [    0.000000] [<0800e0a5>] (warn_slowpath_common) from [<0800e103>]
> (warn_slowpath_fmt+0x1b/0x24)
> [    0.000000] [<0800e103>] (warn_slowpath_fmt) from [<080942e3>] (divide
> 
> But this is definitely an improvement for ARMv7-M debugging,
> 
> Tested-by: Andreas F?rber <afaerber@suse.de>

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG N?rnberg)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150522/bb9a5ecf/attachment.sig>

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 2183 bytes --]

Hi Philipp,

On Fri, May 22, 2015 at 12:07:11PM +0200, Philipp Zabel wrote:
> Am Freitag, den 22.05.2015, 11:18 +0200 schrieb Maxime Ripard:
> > On Fri, May 22, 2015 at 11:06:28AM +0200, Philipp Zabel wrote:
> > > > In the probe function, it would check the number of reg resources.
> > > > If a single resource is passed, it would take it, else it would look
> > > > the one named "reset".
> > > > The driver and bindings would be the same for the two families, and
> > > > the bindings would be backward compatible with sunxi ones.
> > > > 
> > > > Philip, Arnd, what do you think?
> > > 
> > > I'm not a fan of describing the register layout in the device tree as
> > > detailed as the sunxi bindings do. I'd prefer the reg property to
> > > describe the device's register address space with one entry per
> > > contiguous block of registers.
> > 
> > That's exactly what we do.
> 
> Sorry, what I mean is 'as detailed as reusing the sunxi bindings for
> stm32xx here would do'. I don't know enough about the Allwinner register
> layouts to form an opinion.
> 
> The STM32F427xx/STM32F429xx manual, Table 13. "STM32F427xx and
> STM32F429xx register boundary addresses" contains this entry:
>     Bus    Boundary address       Peripheral
>     AHB1   0x40023800-0x400238bf  RCC
> 
> And that's how I'd expect it to be described by the device tree:
> 
>     rcc: rcc@40023800 {
>         compatible = "st,stm32-rcc";
>         reg = <0x40023800 0xc0>;
>     };

It's pretty much what we do already. The thing is that our reset
controllers are intertwined with our clock ones, so our reset
controllers are usually taking only a few registers, and we can't use
more than that since we have clocks in the registers around.

> Instead of "reg = <0x40023810 0x20>" for the resets. Where in the
> address range the reset, clock gate and clock configuration registers
> reside could be derived from the compatible value.

I agree on that, and if a generic solution was to be made like this,
we could definitely use it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Ripard]

Hi Philipp,

On Fri, May 22, 2015 at 12:07:11PM +0200, Philipp Zabel wrote:
> Am Freitag, den 22.05.2015, 11:18 +0200 schrieb Maxime Ripard:
> > On Fri, May 22, 2015 at 11:06:28AM +0200, Philipp Zabel wrote:
> > > > In the probe function, it would check the number of reg resources.
> > > > If a single resource is passed, it would take it, else it would look
> > > > the one named "reset".
> > > > The driver and bindings would be the same for the two families, and
> > > > the bindings would be backward compatible with sunxi ones.
> > > > 
> > > > Philip, Arnd, what do you think?
> > > 
> > > I'm not a fan of describing the register layout in the device tree as
> > > detailed as the sunxi bindings do. I'd prefer the reg property to
> > > describe the device's register address space with one entry per
> > > contiguous block of registers.
> > 
> > That's exactly what we do.
> 
> Sorry, what I mean is 'as detailed as reusing the sunxi bindings for
> stm32xx here would do'. I don't know enough about the Allwinner register
> layouts to form an opinion.
> 
> The STM32F427xx/STM32F429xx manual, Table 13. "STM32F427xx and
> STM32F429xx register boundary addresses" contains this entry:
>     Bus    Boundary address       Peripheral
>     AHB1   0x40023800-0x400238bf  RCC
> 
> And that's how I'd expect it to be described by the device tree:
> 
>     rcc: rcc at 40023800 {
>         compatible = "st,stm32-rcc";
>         reg = <0x40023800 0xc0>;
>     };

It's pretty much what we do already. The thing is that our reset
controllers are intertwined with our clock ones, so our reset
controllers are usually taking only a few registers, and we can't use
more than that since we have clocks in the registers around.

> Instead of "reg = <0x40023810 0x20>" for the resets. Where in the
> address range the reset, clock gate and clock configuration registers
> reside could be derived from the compatible value.

I agree on that, and if a generic solution was to be made like this,
we could definitely use it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150523/6b8a563a/attachment-0001.sig>

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

Hi Maxime,

On Thu, May 21, 2015 at 10:10:35PM +0200, Maxime Coquelin wrote:
> > The only thing we did that stands out a bit is that we actually need
> > the reset driver much earlier than the default probe, since some of
> > our timers are maintained in reset. We have some code to do just that
> > already, we just need have something similar to be on board.
> 
> We have the same problem on stm32, as just discussed with Andreas [0].
> I decided to patch the bootloader to deassert timers reset, after
> discussions with Rob Herring and Arnd.

That seems like the best solution, but we don't have control over the
bootloader in most cases. We have an alternative implementation (ie
mainline u-boot) that is required for a few things already, but I'd
really like to still be able to at least boot the kernel on a "legacy"
bootloader (that is the one flashed on the device).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

Hi Maxime,

On Thu, May 21, 2015 at 10:10:35PM +0200, Maxime Coquelin wrote:
> > The only thing we did that stands out a bit is that we actually need
> > the reset driver much earlier than the default probe, since some of
> > our timers are maintained in reset. We have some code to do just that
> > already, we just need have something similar to be on board.
> 
> We have the same problem on stm32, as just discussed with Andreas [0].
> I decided to patch the bootloader to deassert timers reset, after
> discussions with Rob Herring and Arnd.

That seems like the best solution, but we don't have control over the
bootloader in most cases. We have an alternative implementation (ie
mainline u-boot) that is required for a few things already, but I'd
really like to still be able to at least boot the kernel on a "legacy"
bootloader (that is the one flashed on the device).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Ripard]

Hi Maxime,

On Thu, May 21, 2015 at 10:10:35PM +0200, Maxime Coquelin wrote:
> > The only thing we did that stands out a bit is that we actually need
> > the reset driver much earlier than the default probe, since some of
> > our timers are maintained in reset. We have some code to do just that
> > already, we just need have something similar to be on board.
> 
> We have the same problem on stm32, as just discussed with Andreas [0].
> I decided to patch the bootloader to deassert timers reset, after
> discussions with Rob Herring and Arnd.

That seems like the best solution, but we don't have control over the
bootloader in most cases. We have an alternative implementation (ie
mainline u-boot) that is required for a few things already, but I'd
really like to still be able to at least boot the kernel on a "legacy"
bootloader (that is the one flashed on the device).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150523/f4e4f7d0/attachment.sig>

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

Hi Maxime,

2015-05-23 10:28 GMT+02:00 Maxime Ripard <maxime.ripard@free-electrons.com>:
> On Thu, May 21, 2015 at 10:10:35PM +0200, Maxime Coquelin wrote:
>> We have the same problem on stm32, as just discussed with Andreas [0].
>> I decided to patch the bootloader to deassert timers reset, after
>> discussions with Rob Herring and Arnd.
>
> That seems like the best solution, but we don't have control over the
> bootloader in most cases. We have an alternative implementation (ie
> mainline u-boot) that is required for a few things already, but I'd
> really like to still be able to at least boot the kernel on a "legacy"
> bootloader (that is the one flashed on the device).

For sure it will have to remain compliant with the legacy bootloader.
It is easier for STM32 since it is a newly platform.

Regards,
Maxime C.

Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

Hi Maxime,

2015-05-23 10:28 GMT+02:00 Maxime Ripard <maxime.ripard@free-electrons.com>:
> On Thu, May 21, 2015 at 10:10:35PM +0200, Maxime Coquelin wrote:
>> We have the same problem on stm32, as just discussed with Andreas [0].
>> I decided to patch the bootloader to deassert timers reset, after
>> discussions with Rob Herring and Arnd.
>
> That seems like the best solution, but we don't have control over the
> bootloader in most cases. We have an alternative implementation (ie
> mainline u-boot) that is required for a few things already, but I'd
> really like to still be able to at least boot the kernel on a "legacy"
> bootloader (that is the one flashed on the device).

For sure it will have to remain compliant with the legacy bootloader.
It is easier for STM32 since it is a newly platform.

Regards,
Maxime C.

[PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU

[Maxime Coquelin]

Hi Maxime,

2015-05-23 10:28 GMT+02:00 Maxime Ripard <maxime.ripard@free-electrons.com>:
> On Thu, May 21, 2015 at 10:10:35PM +0200, Maxime Coquelin wrote:
>> We have the same problem on stm32, as just discussed with Andreas [0].
>> I decided to patch the bootloader to deassert timers reset, after
>> discussions with Rob Herring and Arnd.
>
> That seems like the best solution, but we don't have control over the
> bootloader in most cases. We have an alternative implementation (ie
> mainline u-boot) that is required for a few things already, but I'd
> really like to still be able to at least boot the kernel on a "legacy"
> bootloader (that is the one flashed on the device).

For sure it will have to remain compliant with the legacy bootloader.
It is easier for STM32 since it is a newly platform.

Regards,
Maxime C.