Re: [PATCH v6 0/4] Dedicated CLINT timer driver

From: Palmer Dabbelt
Date: Tue Aug 04 2020 - 21:48:06 EST


On Fri, 24 Jul 2020 00:18:18 PDT (-0700), Anup Patel wrote:
The current RISC-V timer driver is convoluted and implements two
distinct timers:
1. S-mode timer: This is for Linux RISC-V S-mode with MMU. The
clocksource is implemented using TIME CSR and clockevent device
is implemented using SBI Timer calls.
2. M-mode timer: This is for Linux RISC-V M-mode without MMU. The
clocksource is implemented using CLINT MMIO time register and
clockevent device is implemented using CLINT MMIO timecmp registers.

This patchset removes clint related code from RISC-V timer driver and
arch/riscv directory. Instead, the series adds a dedicated MMIO based
CLINT driver under drivers/clocksource directory which can be used by
Linux RISC-V M-mode (i.e NoMMU Linux RISC-V).

The patchset is based up Linux-5.8-rc6 and can be found at riscv_clint_v6
branch of: https://github.com/avpatel/linux.git

This series is tested on:
1. QEMU RV64 virt machine using Linux RISC-V S-mode
2. QEMU RV32 virt machine using Linux RISC-V S-mode
3. QEMU RV64 virt machine using Linux RISC-V M-mode (i.e. NoMMU)

Changes since v5:
- Fixed order of compatible strings in PATCH4
- Added "additionalProperties: false" in PATCH4
- Fixed register space size for example DT node in PATCH4

Changes since v4:
- Rebased series on Linux-5.8-rc6
- Updated Kconfig option as suggested by Daniel in PATCH2
- Removed per-CPU registered flag in PATCH2
- Addressed nit comments from Atish in PATCH2

Changes since v3:
- Updated commit description of PATCH2
- Use clint_get_cycles64() in clint_rdtime() of PATCH2
- Call clockevents_config_and_register() only once for each CPU in
clint_timer_starting_cpu of PATCH2
- Select CLINT timer driver from platform Kconfig in PATCH3
- Fixed 'make dt_binding_check' for PATCH4

Changes since v2:
- Rebased series on Linux-5.8-rc5
- Squashed PATCH3 onto PATCH2 to preserve GIT bisectability
- Moved PATCH4 before PATCH2 to preserve GIT bisectability
- Replaced CLINT dt-bindings text document with YAML schema
- Use SiFive CLINT compatible string as per SiFive IP block versioning

Changes since v1:
- Rebased series on Linux-5.8-rc2
- Added pr_warn() for case where ipi_ops not available in PATCH1
- Updated ipi_inject() prototype to use "struct cpumask *" in PATCH1
- Updated CLINT_TIMER kconfig option to depend on RISCV_M_MODE in PATCH4
- Added riscv,clint0 compatible string in DT bindings document

Anup Patel (4):
RISC-V: Add mechanism to provide custom IPI operations
clocksource/drivers: Add CLINT timer driver
RISC-V: Remove CLINT related code from timer and arch
dt-bindings: timer: Add CLINT bindings

.../bindings/timer/sifive,clint.yaml | 60 +++++
arch/riscv/Kconfig | 2 +-
arch/riscv/Kconfig.socs | 2 +
arch/riscv/configs/nommu_virt_defconfig | 7 +-
arch/riscv/include/asm/clint.h | 39 ---
arch/riscv/include/asm/smp.h | 19 ++
arch/riscv/include/asm/timex.h | 28 +--
arch/riscv/kernel/Makefile | 2 +-
arch/riscv/kernel/clint.c | 44 ----
arch/riscv/kernel/sbi.c | 14 ++
arch/riscv/kernel/setup.c | 2 -
arch/riscv/kernel/smp.c | 44 ++--
arch/riscv/kernel/smpboot.c | 4 +-
drivers/clocksource/Kconfig | 12 +-
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-clint.c | 226 ++++++++++++++++++
drivers/clocksource/timer-riscv.c | 17 +-
include/linux/cpuhotplug.h | 1 +
18 files changed, 371 insertions(+), 153 deletions(-)
create mode 100644 Documentation/devicetree/bindings/timer/sifive,clint.yaml
delete mode 100644 arch/riscv/include/asm/clint.h
delete mode 100644 arch/riscv/kernel/clint.c
create mode 100644 drivers/clocksource/timer-clint.c

Thanks, this is way cleaner. Patchwork is still broken but IIRC we reached
consensus on these. I'm not going to include these in my first 5.9 PR, as I
want to get that out tomorrow to avoid more merge conflicts, but assuming
there's reviews from the other maintainers I'd like to take this for my second
5.9 merge window PR.

Assuming you've been collecting reviews and acks, do you mind posting another
version with them? If not I have some scripts to dig them out, so it's not a
big deal.