* [PATCH v2 04/27] riscv: zicfiss/zicfilp enumeration
From: Deepak Gupta @ 2024-03-29 4:44 UTC (permalink / raw)
To: paul.walmsley, rick.p.edgecombe, broonie, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, palmer, conor, linux-doc,
linux-riscv, linux-kernel, devicetree, linux-mm, linux-arch,
linux-kselftest
Cc: corbet, tech-j-ext, palmer, aou, robh+dt, krzysztof.kozlowski+dt,
oleg, akpm, arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah,
brauner, debug, andy.chiu, jerry.shih, hankuan.chen, greentime.hu,
evan, xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
david, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard
In-Reply-To: <20240329044459.3990638-1-debug@rivosinc.com>
Adds description in dt-bindings (extensions.yaml)
This patch adds support for detecting zicfiss and zicfilp. zicfiss and zicfilp
stands for unprivleged integer spec extension for shadow stack and branch
tracking on indirect branches, respectively.
This patch looks for zicfiss and zicfilp in device tree and accordinlgy lights
up bit in cpu feature bitmap. Furthermore this patch adds detection utility
functions to return whether shadow stack or landing pads are supported by
cpu.
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
---
.../devicetree/bindings/riscv/extensions.yaml | 10 ++++++++++
arch/riscv/include/asm/cpufeature.h | 13 +++++++++++++
arch/riscv/include/asm/hwcap.h | 2 ++
arch/riscv/include/asm/processor.h | 1 +
arch/riscv/kernel/cpufeature.c | 2 ++
5 files changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 63d81dc895e5..f8d78bf7400b 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -317,6 +317,16 @@ properties:
The standard Zicboz extension for cache-block zeroing as ratified
in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+ - const: zicfilp
+ description:
+ The standard Zicfilp extension for enforcing forward edge control-flow
+ integrity as ratified in commit 0036ff2 of riscv-cfi.
+
+ - const: zicfiss
+ description:
+ The standard Zicfiss extension for enforcing backward edge control-flow
+ integrity as ratified in commit 0036ff2 of riscv-cfi.
+
- const: zicntr
description:
The standard Zicntr extension for base counters and timers, as
diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
index 0bd11862b760..f0fb8d8ae273 100644
--- a/arch/riscv/include/asm/cpufeature.h
+++ b/arch/riscv/include/asm/cpufeature.h
@@ -8,6 +8,7 @@
#include <linux/bitmap.h>
#include <linux/jump_label.h>
+#include <linux/smp.h>
#include <asm/hwcap.h>
#include <asm/alternative-macros.h>
#include <asm/errno.h>
@@ -137,4 +138,16 @@ static __always_inline bool riscv_cpu_has_extension_unlikely(int cpu, const unsi
DECLARE_STATIC_KEY_FALSE(fast_misaligned_access_speed_key);
+static inline bool cpu_supports_shadow_stack(void)
+{
+ return (IS_ENABLED(CONFIG_RISCV_USER_CFI) &&
+ riscv_cpu_has_extension_unlikely(smp_processor_id(), RISCV_ISA_EXT_ZICFISS));
+}
+
+static inline bool cpu_supports_indirect_br_lp_instr(void)
+{
+ return (IS_ENABLED(CONFIG_RISCV_USER_CFI) &&
+ riscv_cpu_has_extension_unlikely(smp_processor_id(), RISCV_ISA_EXT_ZICFILP));
+}
+
#endif
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 1f2d2599c655..74b6c727f545 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -80,6 +80,8 @@
#define RISCV_ISA_EXT_ZFA 71
#define RISCV_ISA_EXT_ZTSO 72
#define RISCV_ISA_EXT_ZACAS 73
+#define RISCV_ISA_EXT_ZICFILP 74
+#define RISCV_ISA_EXT_ZICFISS 75
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
index a8509cc31ab2..6c5b3d928b12 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -13,6 +13,7 @@
#include <vdso/processor.h>
#include <asm/ptrace.h>
+#include <asm/hwcap.h>
#ifdef CONFIG_64BIT
#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 79a5a35fab96..d052cad5b82f 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -263,6 +263,8 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
__RISCV_ISA_EXT_SUPERSET(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts),
__RISCV_ISA_EXT_SUPERSET(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts),
+ __RISCV_ISA_EXT_SUPERSET(zicfilp, RISCV_ISA_EXT_ZICFILP, riscv_xlinuxenvcfg_exts),
+ __RISCV_ISA_EXT_SUPERSET(zicfiss, RISCV_ISA_EXT_ZICFISS, riscv_xlinuxenvcfg_exts),
__RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
__RISCV_ISA_EXT_DATA(zicond, RISCV_ISA_EXT_ZICOND),
__RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
--
2.43.2
^ permalink raw reply related
* [PATCH v2 03/27] riscv/Kconfig: enable HAVE_EXIT_THREAD for riscv
From: Deepak Gupta @ 2024-03-29 4:44 UTC (permalink / raw)
To: paul.walmsley, rick.p.edgecombe, broonie, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, palmer, conor, linux-doc,
linux-riscv, linux-kernel, devicetree, linux-mm, linux-arch,
linux-kselftest
Cc: corbet, tech-j-ext, palmer, aou, robh+dt, krzysztof.kozlowski+dt,
oleg, akpm, arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah,
brauner, debug, andy.chiu, jerry.shih, hankuan.chen, greentime.hu,
evan, xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
david, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard
In-Reply-To: <20240329044459.3990638-1-debug@rivosinc.com>
riscv will need an implementation for exit_thread to clean up shadow stack
when thread exits. If current thread had shadow stack enabled, shadow
stack is allocated by default for any new thread.
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
---
arch/riscv/Kconfig | 1 +
arch/riscv/kernel/process.c | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e3142ce531a0..7e0b2bcc388f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -149,6 +149,7 @@ config RISCV
select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
+ select HAVE_EXIT_THREAD
select HOTPLUG_CORE_SYNC_DEAD if HOTPLUG_CPU
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 9a85c9d4c902..d864eef5a10d 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -195,6 +195,11 @@ int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
return 0;
}
+void exit_thread(struct task_struct *tsk)
+{
+ return;
+}
+
int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
{
unsigned long clone_flags = args->flags;
--
2.43.2
^ permalink raw reply related
* [PATCH v2 02/27] riscv: define default value for envcfg
From: Deepak Gupta @ 2024-03-29 4:44 UTC (permalink / raw)
To: paul.walmsley, rick.p.edgecombe, broonie, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, palmer, conor, linux-doc,
linux-riscv, linux-kernel, devicetree, linux-mm, linux-arch,
linux-kselftest
Cc: corbet, tech-j-ext, palmer, aou, robh+dt, krzysztof.kozlowski+dt,
oleg, akpm, arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah,
brauner, debug, andy.chiu, jerry.shih, hankuan.chen, greentime.hu,
evan, xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
david, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard
In-Reply-To: <20240329044459.3990638-1-debug@rivosinc.com>
Defines a base default value for envcfg per task. By default all tasks
should have cache zeroing capability. Any future base capabilities that
apply to all tasks can be turned on same way.
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
---
arch/riscv/include/asm/csr.h | 2 ++
arch/riscv/kernel/process.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index 2468c55933cd..bbd2207adb39 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -202,6 +202,8 @@
#define ENVCFG_CBIE_FLUSH _AC(0x1, UL)
#define ENVCFG_CBIE_INV _AC(0x3, UL)
#define ENVCFG_FIOM _AC(0x1, UL)
+/* by default all threads should be able to zero cache */
+#define ENVCFG_BASE ENVCFG_CBZE
/* Smstateen bits */
#define SMSTATEEN0_AIA_IMSIC_SHIFT 58
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 92922dbd5b5c..9a85c9d4c902 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -152,6 +152,7 @@ void start_thread(struct pt_regs *regs, unsigned long pc,
else
regs->status |= SR_UXL_64;
#endif
+ current->thread_info.envcfg = ENVCFG_BASE;
}
void flush_thread(void)
--
2.43.2
^ permalink raw reply related
* [PATCH v2 01/27] riscv: envcfg save and restore on task switching
From: Deepak Gupta @ 2024-03-29 4:44 UTC (permalink / raw)
To: paul.walmsley, rick.p.edgecombe, broonie, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, palmer, conor, linux-doc,
linux-riscv, linux-kernel, devicetree, linux-mm, linux-arch,
linux-kselftest
Cc: corbet, tech-j-ext, palmer, aou, robh+dt, krzysztof.kozlowski+dt,
oleg, akpm, arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah,
brauner, debug, andy.chiu, jerry.shih, hankuan.chen, greentime.hu,
evan, xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
david, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard
In-Reply-To: <20240329044459.3990638-1-debug@rivosinc.com>
envcfg CSR defines enabling bits for cache management instructions and soon
will control enabling for control flow integrity and pointer masking features.
Control flow integrity enabling for forward cfi and backward cfi is controlled
via envcfg and thus need to be enabled on per thread basis.
This patch creates a place holder for envcfg CSR in `thread_info` and adds
logic to save and restore on task switching.
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
---
arch/riscv/include/asm/switch_to.h | 10 ++++++++++
arch/riscv/include/asm/thread_info.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/arch/riscv/include/asm/switch_to.h b/arch/riscv/include/asm/switch_to.h
index 7efdb0584d47..2d9a00a30394 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -69,6 +69,15 @@ static __always_inline bool has_fpu(void) { return false; }
#define __switch_to_fpu(__prev, __next) do { } while (0)
#endif
+static inline void __switch_to_envcfg(struct task_struct *next)
+{
+ register unsigned long envcfg = next->thread_info.envcfg;
+
+ asm volatile (ALTERNATIVE("nop", "csrw " __stringify(CSR_ENVCFG) ", %0", 0,
+ RISCV_ISA_EXT_XLINUXENVCFG, 1)
+ :: "r" (envcfg) : "memory");
+}
+
extern struct task_struct *__switch_to(struct task_struct *,
struct task_struct *);
@@ -80,6 +89,7 @@ do { \
__switch_to_fpu(__prev, __next); \
if (has_vector()) \
__switch_to_vector(__prev, __next); \
+ __switch_to_envcfg(__next); \
((last) = __switch_to(__prev, __next)); \
} while (0)
diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h
index 5d473343634b..a503bdc2f6dd 100644
--- a/arch/riscv/include/asm/thread_info.h
+++ b/arch/riscv/include/asm/thread_info.h
@@ -56,6 +56,7 @@ struct thread_info {
long user_sp; /* User stack pointer */
int cpu;
unsigned long syscall_work; /* SYSCALL_WORK_ flags */
+ unsigned long envcfg;
#ifdef CONFIG_SHADOW_CALL_STACK
void *scs_base;
void *scs_sp;
--
2.43.2
^ permalink raw reply related
* [PATCH v2 00/27] riscv control-flow integrity for usermode
From: Deepak Gupta @ 2024-03-29 4:44 UTC (permalink / raw)
To: paul.walmsley, rick.p.edgecombe, broonie, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, palmer, conor, linux-doc,
linux-riscv, linux-kernel, devicetree, linux-mm, linux-arch,
linux-kselftest
Cc: corbet, tech-j-ext, palmer, aou, robh+dt, krzysztof.kozlowski+dt,
oleg, akpm, arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah,
brauner, debug, andy.chiu, jerry.shih, hankuan.chen, greentime.hu,
evan, xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
david, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard
I had sent RFC patchset early this year (January) [7] to enable CPU assisted
control-flow integrity for usermode on riscv. Since then I've been able to do
more testing of the changes. As part of testing effort, compiled a rootfs with
shadow stack and landing pad enabled (libraries and binaries) and booted to
shell. As part of long running tests, I have been able to run some spec 2006
benchmarks [8] (here link is provided only for list of benchmarks that were
tested for long running tests, excel sheet provided here actually is for some
static stats like code size growth on spec binaries). Thus converting from RFC
to regular patchset.
Securing control-flow integrity for usermode requires following
- Securing forward control flow : All callsites must reach
reach a target that they actually intend to reach.
- Securing backward control flow : All function returns must
return to location where they were called from.
This patch series use riscv cpu extension `zicfilp` [2] to secure forward
control flow and `zicfiss` [2] to secure backward control flow. `zicfilp`
enforces that all indirect calls or jmps must land on a landing pad instr
and label embedded in landing pad instr must match a value programmed in
`x7` register (at callsite via compiler). `zicfiss` introduces shadow stack
which can only be writeable via shadow stack instructions (sspush and
ssamoswap) and thus can't be tampered with via inadvertent stores. More
details about extension can be read from [2] and there are details in
documentation as well (in this patch series).
Using config `CONFIG_RISCV_USER_CFI`, kernel support for riscv control flow
integrity for user mode programs can be compiled in the kernel.
Enabling of control flow integrity for user programs is left to user runtime
(specifically expected from dynamic loader). There has been a lot of earlier
discussion on the enabling topic around x86 shadow stack enabling [3, 4, 5] and
overall consensus had been to let dynamic loader (or usermode) to decide for
enabling the feature.
This patch series introduces arch agnostic `prctls` to enable shadow stack
and indirect branch tracking. And implements them on riscv. arm64 is expected
to implement shadow stack part of these arch agnostic `prctls` [6]
Changes since last time
***********************
Spec changes
------------
- Forward cfi spec has become much simpler. `lpad` instruction is pseudo for
`auipc rd, <20bit_imm>`. `lpad` checks x7 against 20bit embedded in instr.
Thus label width is 20bit.
- Shadow stack management instructions are reduced to
sspush - to push x1/x5 on shadow stack
sspopchk - pops from shadow stack and comapres with x1/x5.
ssamoswap - atomically swap value on shadow stack.
rdssp - reads current shadow stack pointer
- Shadow stack accesses on readonly memory always raise AMO/store page fault.
`sspopchk` is load but if underlying page is readonly, it'll raise a store
page fault. It simplifies hardware and kernel for COW handling for shadow
stack pages.
- riscv defines a new exception type `software check exception` and control flow
violations raise software check exception.
- enabling controls for shadow stack and landing are in xenvcfg CSR and controls
lower privilege mode enabling. As an example senvcfg controls enabling for U and
menvcfg controls enabling for S mode.
core mm shadow stack enabling
-----------------------------
Shadow stack for x86 usermode are now in mainline and thus this patch
series builds on top of that for arch-agnostic mm related changes. Big
thanks and shout out to Rick Edgecombe for that.
selftests
---------
Created some minimal selftests to test the patch series.
[1] - https://lore.kernel.org/lkml/20230213045351.3945824-1-debug@rivosinc.com/
[2] - https://github.com/riscv/riscv-cfi
[3] - https://lore.kernel.org/lkml/ZWHcBq0bJ+15eeKs@finisterre.sirena.org.uk/T/#mb121cd8b33d564e64234595a0ec52211479cf474
[4] - https://lore.kernel.org/all/20220130211838.8382-1-rick.p.edgecombe@intel.com/
[5] - https://lore.kernel.org/lkml/CAHk-=wgP5mk3poVeejw16Asbid0ghDt4okHnWaWKLBkRhQntRA@mail.gmail.com/
[6] - https://lore.kernel.org/linux-mm/20231122-arm64-gcs-v7-2-201c483bd775@kernel.org/
[7] - https://lore.kernel.org/lkml/20240125062739.1339782-1-debug@rivosinc.com/
[8] - https://docs.google.com/spreadsheets/d/1_cHGH4ctNVvFRiS7hW9dEGKtXLAJ3aX4Z_iTSa3Tw2U/edit#gid=0
Deepak Gupta (26):
riscv: envcfg save and restore on task switching
riscv: define default value for envcfg
riscv/Kconfig: enable HAVE_EXIT_THREAD for riscv
riscv: zicfiss/zicfilp enumeration
riscv: zicfiss/zicfilp extension csr and bit definitions
riscv: usercfi state for task and save/restore of CSR_SSP on trap
entry/exit
mm: Define VM_SHADOW_STACK for RISC-V
mm: abstract shadow stack vma behind `arch_is_shadow_stack`
riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE
riscv mm: manufacture shadow stack pte
riscv mmu: teach pte_mkwrite to manufacture shadow stack PTEs
riscv mmu: write protect and shadow stack
riscv/mm: Implement map_shadow_stack() syscall
riscv/shstk: If needed allocate a new shadow stack on clone
prctl: arch-agnostic prtcl for indirect branch tracking
riscv: Implements arch agnostic shadow stack prctls
riscv: Implements arch argnostic indirect branch tracking prctls
riscv/kernel: update __show_regs to print shadow stack register
riscv/traps: Introduce software check exception
riscv sigcontext: adding cfi state field in sigcontext
riscv signal: Save and restore of shadow stack for signal
riscv/ptrace: riscv cfi status and state via ptrace and in core files
riscv: create a config for shadow stack and landing pad instr support
riscv: Documentation for landing pad / indirect branch tracking
riscv: Documentation for shadow stack on riscv
kselftest/riscv: kselftest for user mode cfi
Mark Brown (1):
prctl: arch-agnostic prctl for shadow stack
Documentation/arch/riscv/zicfilp.rst | 104 ++++
Documentation/arch/riscv/zicfiss.rst | 169 ++++++
.../devicetree/bindings/riscv/extensions.yaml | 10 +
arch/riscv/Kconfig | 19 +
arch/riscv/include/asm/asm-prototypes.h | 1 +
arch/riscv/include/asm/cpufeature.h | 13 +
arch/riscv/include/asm/csr.h | 18 +
arch/riscv/include/asm/hwcap.h | 2 +
arch/riscv/include/asm/mman.h | 24 +
arch/riscv/include/asm/pgtable.h | 32 +-
arch/riscv/include/asm/processor.h | 2 +
arch/riscv/include/asm/switch_to.h | 10 +
arch/riscv/include/asm/thread_info.h | 4 +
arch/riscv/include/asm/usercfi.h | 118 ++++
arch/riscv/include/uapi/asm/ptrace.h | 18 +
arch/riscv/include/uapi/asm/sigcontext.h | 5 +
arch/riscv/kernel/Makefile | 2 +
arch/riscv/kernel/asm-offsets.c | 4 +
arch/riscv/kernel/cpufeature.c | 2 +
arch/riscv/kernel/entry.S | 29 +
arch/riscv/kernel/process.c | 35 +-
arch/riscv/kernel/ptrace.c | 83 +++
arch/riscv/kernel/signal.c | 45 ++
arch/riscv/kernel/sys_riscv.c | 11 +
arch/riscv/kernel/traps.c | 38 ++
arch/riscv/kernel/usercfi.c | 510 ++++++++++++++++++
arch/riscv/mm/init.c | 2 +-
arch/riscv/mm/pgtable.c | 21 +
include/linux/mm.h | 35 +-
include/uapi/asm-generic/mman.h | 1 +
include/uapi/linux/elf.h | 1 +
include/uapi/linux/prctl.h | 49 ++
kernel/sys.c | 60 +++
mm/gup.c | 5 +-
mm/internal.h | 2 +-
mm/mmap.c | 1 +
tools/testing/selftests/riscv/Makefile | 2 +-
tools/testing/selftests/riscv/cfi/Makefile | 10 +
.../testing/selftests/riscv/cfi/cfi_rv_test.h | 85 +++
.../selftests/riscv/cfi/riscv_cfi_test.c | 91 ++++
.../testing/selftests/riscv/cfi/shadowstack.c | 376 +++++++++++++
.../testing/selftests/riscv/cfi/shadowstack.h | 39 ++
42 files changed, 2077 insertions(+), 11 deletions(-)
create mode 100644 Documentation/arch/riscv/zicfilp.rst
create mode 100644 Documentation/arch/riscv/zicfiss.rst
create mode 100644 arch/riscv/include/asm/mman.h
create mode 100644 arch/riscv/include/asm/usercfi.h
create mode 100644 arch/riscv/kernel/usercfi.c
create mode 100644 tools/testing/selftests/riscv/cfi/Makefile
create mode 100644 tools/testing/selftests/riscv/cfi/cfi_rv_test.h
create mode 100644 tools/testing/selftests/riscv/cfi/riscv_cfi_test.c
create mode 100644 tools/testing/selftests/riscv/cfi/shadowstack.c
create mode 100644 tools/testing/selftests/riscv/cfi/shadowstack.h
--
2.43.2
^ permalink raw reply
* Re: [PATCH v12 0/5] riscv: sophgo: add clock support for sg2042
From: Chen Wang @ 2024-03-29 4:00 UTC (permalink / raw)
To: Chen Wang, aou, chao.wei, conor, krzysztof.kozlowski+dt,
mturquette, palmer, paul.walmsley, richardcochran, robh+dt, sboyd,
devicetree, linux-clk, linux-kernel, linux-riscv, haijiao.liu,
xiaoguang.xing, guoren, jszhang, inochiama, samuel.holland
In-Reply-To: <cover.1711527932.git.unicorn_wang@outlook.com>
I just found there is a defect in driver code, I will send a new version
later soon. Please ignore this v12.
Thanks,
Chen
On 2024/3/27 16:29, Chen Wang wrote:
> From: Chen Wang <unicorn_wang@outlook.com>
>
> This series adds clock controller support for sophgo sg2042.
>
> Thanks,
> Chen
>
> ---
>
> Changes in v12:
>
> The patch series is based on v6.9-rc1.
>
> Improved the dirvier code as per review comments from Stephen Boyd.
> - Remove default y for CLK_SOPHGO_SG2042.
> - Optimize sg2042_pll_get_postdiv_1_2, move postdiv1_2 to the function.
> scope and add more explaniation.
> - Optimize sg2042_get_pll_ctl_setting.
> - Switch to platform driver.
> - Use clk_hw for initialization of struct clks.
> - Don't use ignore_unused when using critical.
> - Other code cleanup as per input form the reviewers.
>
> Changes in v11:
>
> The patch series is based on v6.8-rc5. You can simply review or test the
> patches at the link [12].
>
> Quick fixed some dt_binding_check errors reported by Rob.
>
> Changes in v10:
>
> The patch series is based on v6.8-rc4. You can simply review or test the
> patches at the link [11].
>
> Add input clocks for rpgate & clkgen.
>
> Changes in v9:
> The patch series is based on v6.8-rc2. You can simply review or test the
> patches at the link [10].
>
> From this version, drop the system-controller node due to there is no actual
> device corresponding to it in IC design. SYS_CTRL is just a registers segment
> defined on TRM for misc functions. Now three clock-controllers are defined for
> SG2042, the control registers of the three clock-controllers are scattered in
> different memory address spaces:
> - the first one is for pll clocks;
> - the second one is for gate clocks for RP subsystem;
> - the third one is for div/mux, and gate clocks working for other subsystem
> than RP subsystem.
>
> Changes in v8:
> The patch series is based on v6.7. You can simply review or test the
> patches at the link [9].
>
> In this version, the main change is to split one clock provider into two.
> Strictly follow the hardware instructions, in the memoymap, the control
> registers of some clocks are defined in the SYS_CTRL segment, and the
> control registers of other clocks are defined in the CLOCK segment.
> Therefore, the new design defines two clock controllers, one as a child
> node of the system control and the other as an independent clock controller
> node.
>
> This modification involves a major modification to the binding files, so
> the reviewed-by tags has been deleted.
>
> Changes in v7:
> The patch series is based on v6.7. You can simply review or test the
> patches at the link [8].
> - fixed initval issue.
> - fixed pll clk crash issue.
> - fixed warning reported by <lkp@intel.com>
> - code optimization as per review comments.
> - code cleanup and style improvements as per review comments and checkpatch
> with "--strict"
>
> Changes in v6:
> The patch series is based on v6.7-rc1. You can simply review or test the
> patches at the link [7].
> - fixed some warnings/errors reported by kernel test robot <lkp@intel.com>.
>
> Changes in v5:
> The patch series is based on v6.7-rc1. You can simply review or test the
> patches at the link [6].
> - dt-bindings: improved yaml, such as:
> - add vendor prefix for system-ctrl property for clock generator.
> - Add explanation for system-ctrl property.
> - move sophgo,sg2042-clkgen.yaml to directly under clock folder.
> - fixed bugs for driver Makefile/Kconfig
> - continue cleaning-up debug print for driver code.
>
> Changes in v4:
> The patch series is based on v6.7-rc1. You can simply review or test the
> patches at the link [5].
> - dt-bindings: fixed a dt_binding_check error.
>
> Changes in v3:
> The patch series is based on v6.7-rc1. You can simply review or test the
> patches at the link [3].
> - DTS: don't use syscon but define sg2042 specific system control node. More
> background info can read [4].
> - Updating minor issues in dt-bindings as per input from reviews.
>
> Changes in v2:
> The patch series is based on v6.7-rc1. You can simply review or test the
> patches at the link [2].
> - Squashed the patch adding clock definitions with the patch adding the
> binding for the clock controller.
> - Updating dt-binding for syscon, remove oneOf for property compatible;
> define clock controller as child of syscon.
> - DTS changes: merge sg2042-clock.dtsi into sg2042.dtsi; move clock-frequency
> property of osc to board devicethree due to the oscillator is outside the
> SoC.
> - Fixed some bugs in driver code during testing, including removing warnings
> for rv32_defconfig.
> - Updated MAINTAINERS info.
>
> Changes in v1:
> The patch series is based on v6.7-rc1. You can simply review or test the
> patches at the link [1].
>
> Link: https://lore.kernel.org/linux-riscv/cover.1699879741.git.unicorn_wang@outlook.com/ [1]
> Link: https://lore.kernel.org/linux-riscv/cover.1701044106.git.unicorn_wang@outlook.com/ [2]
> Link: https://lore.kernel.org/linux-riscv/cover.1701691923.git.unicorn_wang@outlook.com/ [3]
> Link: https://lore.kernel.org/linux-riscv/MA0P287MB03329AE180378E1A2E034374FE82A@MA0P287MB0332.INDP287.PROD.OUTLOOK.COM/ [4]
> Link: https://lore.kernel.org/linux-riscv/cover.1701734442.git.unicorn_wang@outlook.com/ [5]
> Link: https://lore.kernel.org/linux-riscv/cover.1701938395.git.unicorn_wang@outlook.com/ [6]
> Link: https://lore.kernel.org/linux-riscv/cover.1701997033.git.unicorn_wang@outlook.com/ [7]
> Link: https://lore.kernel.org/linux-riscv/cover.1704694903.git.unicorn_wang@outlook.com/ [8]
> Link: https://lore.kernel.org/linux-riscv/cover.1705388518.git.unicorn_wang@outlook.com/ [9]
> Link: https://lore.kernel.org/linux-riscv/cover.1706854074.git.unicorn_wang@outlook.com/ [10]
> Link: https://lore.kernel.org/linux-riscv/cover.1708223519.git.unicorn_wang@outlook.com/ [11]
> Link: https://lore.kernel.org/linux-riscv/cover.1708397315.git.unicorn_wang@outlook.com/ [12]
>
> ---
>
> Chen Wang (5):
> dt-bindings: clock: sophgo: add pll clocks for SG2042
> dt-bindings: clock: sophgo: add RP gate clocks for SG2042
> dt-bindings: clock: sophgo: add clkgen for SG2042
> clk: sophgo: Add SG2042 clock driver
> riscv: dts: add clock generator for Sophgo SG2042 SoC
>
> .../bindings/clock/sophgo,sg2042-clkgen.yaml | 49 +
> .../bindings/clock/sophgo,sg2042-pll.yaml | 45 +
> .../bindings/clock/sophgo,sg2042-rpgate.yaml | 43 +
> .../boot/dts/sophgo/sg2042-milkv-pioneer.dts | 12 +
> arch/riscv/boot/dts/sophgo/sg2042.dtsi | 49 +-
> drivers/clk/Kconfig | 1 +
> drivers/clk/Makefile | 1 +
> drivers/clk/sophgo/Kconfig | 7 +
> drivers/clk/sophgo/Makefile | 2 +
> drivers/clk/sophgo/clk-sophgo-sg2042.c | 1410 +++++++++++++++++
> drivers/clk/sophgo/clk-sophgo-sg2042.h | 216 +++
> .../dt-bindings/clock/sophgo,sg2042-clkgen.h | 111 ++
> include/dt-bindings/clock/sophgo,sg2042-pll.h | 14 +
> .../dt-bindings/clock/sophgo,sg2042-rpgate.h | 58 +
> 14 files changed, 2017 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/clock/sophgo,sg2042-clkgen.yaml
> create mode 100644 Documentation/devicetree/bindings/clock/sophgo,sg2042-pll.yaml
> create mode 100644 Documentation/devicetree/bindings/clock/sophgo,sg2042-rpgate.yaml
> create mode 100644 drivers/clk/sophgo/Kconfig
> create mode 100644 drivers/clk/sophgo/Makefile
> create mode 100644 drivers/clk/sophgo/clk-sophgo-sg2042.c
> create mode 100644 drivers/clk/sophgo/clk-sophgo-sg2042.h
> create mode 100644 include/dt-bindings/clock/sophgo,sg2042-clkgen.h
> create mode 100644 include/dt-bindings/clock/sophgo,sg2042-pll.h
> create mode 100644 include/dt-bindings/clock/sophgo,sg2042-rpgate.h
>
>
> base-commit: 4cece764965020c22cff7665b18a012006359095
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: imx6ull: add seeed studio NPi dev board
From: Shawn Guo @ 2024-03-29 4:00 UTC (permalink / raw)
To: Parthiban Nallathambi
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240229082337.3090778-2-parthiban@linumiz.com>
On Thu, Feb 29, 2024 at 01:53:37PM +0530, Parthiban Nallathambi wrote:
> Add support for Seed Stuidos NPi i.MX6ULL SoM equipped with
> 512MB RAM and 8GB eMMC or 512MB NAND flash. Development
> board comes with either eMMC or NAND based SoM with peripheral
> interfaces like 2 x ethernet, 2 x USB, LCD, CSI and more.
>
> Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
> ---
> arch/arm/boot/dts/nxp/imx/Makefile | 2 +
> .../imx/imx6ull-seeed-npi-dev-board-emmc.dts | 19 +
> .../imx/imx6ull-seeed-npi-dev-board-nand.dts | 19 +
> .../nxp/imx/imx6ull-seeed-npi-dev-board.dtsi | 424 ++++++++++++++++++
> .../boot/dts/nxp/imx/imx6ull-seeed-npi.dtsi | 155 +++++++
> 5 files changed, 619 insertions(+)
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-seeed-npi-dev-board-emmc.dts
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-seeed-npi-dev-board-nand.dts
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-seeed-npi-dev-board.dtsi
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-seeed-npi.dtsi
Could you elaborate a bit the point of splitting imx6ull-seeed-npi.dtsi
and imx6ull-seeed-npi-dev-board.dtsi? Why cannot they be a single file?
Shawn
^ permalink raw reply
* RE: 回复: [PATCH v2 1/2] ASoC: dt-bindings: Add bindings for Cadence I2S-MC controller
From: Xingyu Wu @ 2024-03-29 3:56 UTC (permalink / raw)
To: Krzysztof Kozlowski, Liam Girdwood, Mark Brown, Claudiu Beznea,
Jaroslav Kysela, Takashi Iwai, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org, linux-sound@vger.kernel.org
In-Reply-To: <16f72b4a-2aa9-49d5-a4aa-ed94eea1f32a@linaro.org>
On 27/03/2024 13:12, Krzysztof Kozlowski wrote:
> On 26/03/2024 14:43, Xingyu Wu wrote:
> >>>>> +
> >>>>> +properties:
> >>>>> + compatible:
> >>>>> + enum:
> >>>>> + - cdns,i2s-mc
> >>>>
> >>>> Why did this appear? Who asked for this? Usually these blocks are
> >>>> not usable on their own.
> >>>
> >>> I wonder if I should keep the original IP compatible. Do I not need it?
> >>
> >> As I said, it is not usable on its own, so unless you have other arguments then
> no.
> >> But my point was that no one asked for this.
> >
> > I want to keep the original IP compatible which can distinguish from the JH8100
> SoC.
> > Can I write it like this:
> > compatible:
> > enum:
> > - starfive,jh8100-i2s
> > const: cdns,i2s-mc
> >
> > and I write this in the DTS:
> > compatible = "starfive,jh8100-i2s", "cdns,i2s-mc";
>
> Can you provide any rationale for this? I asked "unless you have other
> arguments", so where are the arguments?
>
> Nothing was explained in patch changelog. Nothing was provided in this email
> thread.
I don't know if I understood what mark said[1]. Is it to keep the original IP and
add other compatible?
[1] https://lore.kernel.org/all/27155281-573c-493d-96fe-1f28ebb0ce5e@sirena.org.uk/
Or should I only keep the compatible 'starfive,jh8110-i2s' and change the
bindings name to same to this compatible?
>
> >
> >>
> >>>
> >>>>
> >>>>> + - starfive,jh8100-i2s
> >>>>> +
> >>>>> + reg:
> >>>>> + maxItems: 1
> >>>>> +
> >>>>> + interrupts:
> >>>>> + description:
> >>>>> + The interrupt line number for the I2S controller. Add this
> >>>>> + parameter if the I2S controller that you are using does not
> >>>>> + using DMA.
> >>>>
> >>>> That's still wrong. You already got comment on this. Either you
> >>>> have interrupt
> >> or not.
> >>>> You do not add interrupts, based on your choice or not of having DMA.
> >>>> Drop the comment.
> >>>
> >>> Do I keep this property and drop this description?
> >>
> >> Drop description. Keep property, if your hardware has interrupts.
> >>
> >
> > Will drop.
> >
> >> ...
> >>
> >>>>
> >>>>> + - compatible
> >>>>> + - reg
> >>>>> + - clocks
> >>>>> + - clock-names
> >>>>> + - resets
> >>>>> +
> >>>>> +oneOf:
> >>>>> + - required:
> >>>>> + - dmas
> >>>>> + - dma-names
> >>>>> + - required:
> >>>>> + - interrupts
> >>>>
> >>>> This won't work. Provide both interrupts and dmas, and then test your DTS.
> >>>
> >>> I provided both properties in the DTS and test by dtbs_check. Then
> >>> it printed
> >> that:
> >>> 'More than one condition true in one of shema: ...'
> >>
> >> Exactly. Having both properties is a correct DTS. Interrupts do not
> >> disappear just because you decide to describe DMA. It is OS choice
> >> what to use if both are provided.
> >>
> >
> > But this I2S can only use either DMA or interrupts.
>
> Just like many other components. DTS should reflect hardware. Hardware has
> interrupts and DMA, right?
Yes. The hardware can use interrupts and provide the handshake interface of
DMA to DMA controller. In software, we can choose only one between them.
Do I keep them both in the bindings and provide the selection in the driver?
>
> >
> > Can I use the config (like SND_SOC_CADENCE_I2S_MC_PCM) to choose DMA
> > or interrupt if having both them in DTS?
>
> Don't know, I tend to focus here on bindings.
>
Best regards,
Xingyu Wu
^ permalink raw reply
* Re: [PATCH] dt-bindings: ti,pcm1681: Convert to dtschema
From: Animesh Agarwal @ 2024-03-29 3:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Shenghao Ding, Kevin Lu, Baojun Xu, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, alsa-devel,
devicetree, linux-kernel
In-Reply-To: <5b917ec7-f8f8-489c-a804-70ea603262dd@linaro.org>
On Thu, Mar 28, 2024 at 2:27 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> Why not existing driver maintainers? Do you have this device? Or use it,
> or care in terms of your projects?
I'll change it to the current maintainers of the bindings.
> Missing dai-cells, $ref to dai-common and unevaluatedProperties: false,
> just like in other simple DAI devices. Mention briefly in the commit msg
> adding these ("Make bindings complete by adding #sound-dai-cells").
Sure, I'll add it.
> Datasheet says it is dac, but we usually call it "audio-codec".
>
Noted.
Thanks and Regards,
Animesh Agarwal
^ permalink raw reply
* Re: [RFC PATCH 1/2] spi: dt-bindings: add Siflower Quad SPI controller
From: Rob Herring @ 2024-03-29 3:27 UTC (permalink / raw)
To: Qingfang Deng
Cc: Mark Brown, linux-kernel, Krzysztof Kozlowski, devicetree,
Conor Dooley, linux-spi, Qingfang Deng
In-Reply-To: <20240329015147.1481349-1-dqfext@gmail.com>
On Fri, 29 Mar 2024 09:51:46 +0800, Qingfang Deng wrote:
> From: Qingfang Deng <qingfang.deng@siflower.com.cn>
>
> Add YAML devicetree bindings for Siflower Quad SPI controller.
>
> Signed-off-by: Qingfang Deng <qingfang.deng@siflower.com.cn>
> ---
> .../bindings/spi/siflower,qspi.yaml | 54 +++++++++++++++++++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/siflower,qspi.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/spi/siflower,qspi.example.dtb: spi@c200000: reg: [[0, 203423744], [0, 4096]] is too long
from schema $id: http://devicetree.org/schemas/spi/siflower,qspi.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/spi/siflower,qspi.example.dtb: spi@c200000: Unevaluated properties are not allowed ('reg' was unexpected)
from schema $id: http://devicetree.org/schemas/spi/siflower,qspi.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240329015147.1481349-1-dqfext@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v3 0/3] Add HDMI and PDM sound card for imx8mp-evk
From: Shawn Guo @ 2024-03-29 3:23 UTC (permalink / raw)
To: Shengjiu Wang
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, devicetree, linux-arm-kernel,
linux-kernel, shengjiu.wang
In-Reply-To: <1709091013-14026-1-git-send-email-shengjiu.wang@nxp.com>
On Wed, Feb 28, 2024 at 11:30:10AM +0800, Shengjiu Wang wrote:
> Add HDMI and PDM sound card
>
> changes in v3:
> - split imx8mp and imx8mp-evk changes for HDMI audio.
>
> changes in v2:
> - remove 'status' in sound-hdmi
>
> Shengjiu Wang (3):
> arm64: dts: imx8mp: Add AUD2HTX device node
> arm64: dts: imx8mp-evk: Add HDMI audio sound card support
> arm64: dts: imx8mp-evk: Add PDM micphone sound card support
Applied all, thanks!
^ permalink raw reply
* Re: [PATCH V7 3/6] arm64: dts: imx8mp: add HDMI power-domains
From: Shawn Guo @ 2024-03-29 3:19 UTC (permalink / raw)
To: Adam Ford
Cc: linux-arm-kernel, linux-phy, aford, Lucas Stach, Marek Vasut,
Luca Ceresoli, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Catalin Marinas,
Will Deacon, devicetree, imx, linux-kernel
In-Reply-To: <20240227220444.77566-4-aford173@gmail.com>
On Tue, Feb 27, 2024 at 04:04:37PM -0600, Adam Ford wrote:
> From: Lucas Stach <l.stach@pengutronix.de>
>
> This adds the PGC and HDMI blk-ctrl nodes providing power control for
> HDMI subsystem peripherals.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Tested-by: Marek Vasut <marex@denx.de>
> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Applied 3 ~ 6, thanks!
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: imx8qm-mek: add adc0 support
From: Shawn Guo @ 2024-03-29 3:11 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20240227193049.457426-1-Frank.Li@nxp.com>
On Tue, Feb 27, 2024 at 02:30:46PM -0500, Frank Li wrote:
> Add adc0 for imx8qm-mek board.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied all, thanks!
^ permalink raw reply
* Re: [PATCH v3 6/6] riscv: dts: starfive: add Milkv Mars board device tree
From: Jisheng Zhang @ 2024-03-29 2:32 UTC (permalink / raw)
To: Emil Renner Berthing
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Emil Renner Berthing, linux-riscv,
devicetree, linux-kernel
In-Reply-To: <CAJM55Z8O20qjYmbjwOOE2CDCrWhCDGJ-jXY9TsR2hMSn-gEFtQ@mail.gmail.com>
On Thu, Mar 28, 2024 at 05:45:21AM -0700, Emil Renner Berthing wrote:
> Jisheng Zhang wrote:
> > On Wed, Mar 27, 2024 at 06:06:58PM +0000, Conor Dooley wrote:
> > > Yo,
> > >
> > > On Tue, Feb 06, 2024 at 07:13:48PM +0000, Conor Dooley wrote:
> > > > On Wed, Jan 31, 2024 at 09:26:00PM +0800, Jisheng Zhang wrote:
> > > > > The Milkv Mars is a development board based on the Starfive JH7110 SoC.
> > > > > The board features:
> > > > >
> > > > > - JH7110 SoC
> > > > > - 1/2/4/8 GiB LPDDR4 DRAM
> > > > > - AXP15060 PMIC
> > > > > - 40 pin GPIO header
> > > > > - 3x USB 3.0 host port
> > > > > - 1x USB 2.0 host port
> > > > > - 1x M.2 E-Key
> > > > > - 1x eMMC slot
> > > > > - 1x MicroSD slot
> > > > > - 1x QSPI Flash
> > > > > - 1x 1Gbps Ethernet port
> > > > > - 1x HDMI port
> > > > > - 1x 2-lane DSI and 1x 4-lane DSI
> > > > > - 1x 2-lane CSI
> > > > >
> > > > > Add the devicetree file describing the currently supported features,
> > > > > namely PMIC, UART, I2C, GPIO, SD card, QSPI Flash, eMMC and Ethernet.
> > > > >
> > > > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> > > >
> > > > Got a dtbs_check issue in the patchwork CI:
> > > >
> > > > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rgmii-rxin-clock: 'clock-frequency' is a required property
> > > > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> > > > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rmii-refin-clock: 'clock-frequency' is a required property
> > > > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> > > >
> > > > Can you fix that please? Also, I applied some patches the other day that
> > > > seem to conflict quite a bit with the common board dts patch. Would you
> > > > please do a rebase on top of that please?
> > >
> > > Been going through stuff on my todo list now that the merge window is
> > > closed. Could you please resend this with the rebase done?
> >
> > Thanks for the reminding, I will rebase on 6.9-rc1 then send out the
> > patches.
>
> Hi Jisheng,
Hi,
>
> A rebase would be great. It looks good to me, but could you maybe call the
> common .dtsi something more generic like jh7110-common.dtsi like the
> jh7100-common.dtsi. If we'll see other boards based on the jh7110 upstreamed
make sense, will do in v4 series.
> (eg. Star64) I suspect they'll also be heavily based on^M^M^M similar to the
> VF2 schematics.
>
> /Emil
>
> >
> > >
> > > Thanks,
> > > Conor.
> >
> >
^ permalink raw reply
* Re: [PATCH v3 6/6] riscv: dts: starfive: add Milkv Mars board device tree
From: Jisheng Zhang @ 2024-03-29 2:31 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Emil Renner Berthing, linux-riscv, devicetree,
linux-kernel, Conor Dooley, Aurelien Jarno
In-Reply-To: <43918921-0d05-41d3-a19b-f137314e868d@canonical.com>
On Thu, Mar 28, 2024 at 10:28:28PM +0100, Heinrich Schuchardt wrote:
> On 2/6/24 20:13, Conor Dooley wrote:
> > On Wed, Jan 31, 2024 at 09:26:00PM +0800, Jisheng Zhang wrote:
> > > The Milkv Mars is a development board based on the Starfive JH7110 SoC.
> > > The board features:
> > >
> > > - JH7110 SoC
> > > - 1/2/4/8 GiB LPDDR4 DRAM
> > > - AXP15060 PMIC
> > > - 40 pin GPIO header
> > > - 3x USB 3.0 host port
> > > - 1x USB 2.0 host port
> > > - 1x M.2 E-Key
> > > - 1x eMMC slot
> > > - 1x MicroSD slot
> > > - 1x QSPI Flash
> > > - 1x 1Gbps Ethernet port
> > > - 1x HDMI port
> > > - 1x 2-lane DSI and 1x 4-lane DSI
> > > - 1x 2-lane CSI
> > >
> > > Add the devicetree file describing the currently supported features,
> > > namely PMIC, UART, I2C, GPIO, SD card, QSPI Flash, eMMC and Ethernet.
> > >
> > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> >
> > Got a dtbs_check issue in the patchwork CI:
> >
> > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rgmii-rxin-clock: 'clock-frequency' is a required property
> > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rmii-refin-clock: 'clock-frequency' is a required property
> > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> >
> > Can you fix that please? Also, I applied some patches the other day that
> > seem to conflict quite a bit with the common board dts patch. Would you
> > please do a rebase on top of that please?
> >
> > Cheers,
> > Conor.
> >
> > > ---
> > > arch/riscv/boot/dts/starfive/Makefile | 1 +
> > > .../boot/dts/starfive/jh7110-milkv-mars.dts | 35 +++++++++++++++++++
> > > 2 files changed, 36 insertions(+)
> > > create mode 100644 arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
> > >
> > > diff --git a/arch/riscv/boot/dts/starfive/Makefile b/arch/riscv/boot/dts/starfive/Makefile
> > > index 0141504c0f5c..2fa0cd7f31c3 100644
> > > --- a/arch/riscv/boot/dts/starfive/Makefile
> > > +++ b/arch/riscv/boot/dts/starfive/Makefile
> > > @@ -8,5 +8,6 @@ DTC_FLAGS_jh7110-starfive-visionfive-2-v1.3b := -@
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7100-beaglev-starlight.dtb
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7100-starfive-visionfive-v1.dtb
> > > +dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-milkv-mars.dtb
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-starfive-visionfive-2-v1.2a.dtb
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-starfive-visionfive-2-v1.3b.dtb
> > > diff --git a/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts b/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
> > > new file mode 100644
> > > index 000000000000..de600e799e7d
> > > --- /dev/null
> > > +++ b/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
> > > @@ -0,0 +1,35 @@
> > > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > > +/*
> > > + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org>
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "jh7110-visionfive2-mars-common.dtsi"
> > > +
> > > +/ {
> > > + model = "Milk-V Mars";
> > > + compatible = "milkv,mars", "starfive,jh7110";
> > > +};
> > > +
> > > +&gmac0 {
> > > + starfive,tx-use-rgmii-clk;
> > > + assigned-clocks = <&aoncrg JH7110_AONCLK_GMAC0_TX>;
> > > + assigned-clock-parents = <&aoncrg JH7110_AONCLK_GMAC0_RMII_RTX>;
> > > +};
> > > +
> > > +
> > > +&phy0 {
> > > + motorcomm,tx-clk-adj-enabled;
> > > + motorcomm,tx-clk-10-inverted;
> > > + motorcomm,tx-clk-100-inverted;
> > > + motorcomm,tx-clk-1000-inverted;
> > > + motorcomm,rx-clk-drv-microamp = <3970>;
> > > + motorcomm,rx-data-drv-microamp = <2910>;
> > > + rx-internal-delay-ps = <1500>;
> > > + tx-internal-delay-ps = <1500>;
> > > +};
> > > +
> > > +&mmc1 {
> > > + disable-wp;
>
> Due to which difference is 'disable-wp' necessary for the Mars board and not
> necessary for the VisionFive 2 board?
Mars doesn't have wp pin, but dunno vf2 case since I don't have a VF2
board ;)
>
> > > + cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>;
>
> On my VisionFive 2 1.2B, and 1.3A boards GPIO 41 reflects if an SD-card is
> inserted (as shown in U-Boot by gpio status -a). So shouldn't this value be
> moved to the common include "jh7110-visionfive2-mars-common.dtsi" and
> broken-cd removed from the VisionFive2 board?
I tested the CD pin and can confirm it works on Mars, but I dunno whether
this works on VF2 since I have no VF2 board.
Could you please check whether it works or not on VF2?
>
> https://doc-en.rvspace.org/VisionFive2/PDF/SCH_RV002_V1.2A_20221216.pdf
> has a line
>
> GPIO41 | SD_SDIO0_CD_GPIO41 | Micro SD：J10
>
> Best regards
>
> Heinrich
>
> > > +};
> > > --
> > > 2.43.0
>
^ permalink raw reply
* Re: [PATCH v5 2/2] ASoC: nau8325: new driver
From: WTLI @ 2024-03-29 2:33 UTC (permalink / raw)
To: Mark Brown
Cc: lgirdwood, alsa-devel, devicetree, linux-sound,
krzysztof.kozlowski+dt, linux-kernel, robh+dt, conor+dt, perex,
tiwai, YHCHuang, KCHSU0, CTLIN0, SJLIN0, scott6986,
supercraig0719, dardar923
In-Reply-To: <8278611a-a46f-4d5e-9861-67ff1084db50@sirena.org.uk>
Mark Brown 於 3/28/2024 11:22 PM 寫道:
> On Wed, Mar 27, 2024 at 03:57:55PM +0800, Seven Lee wrote:
>
>> +static const char * const nau8325_dac_oversampl[] = {
>> + "64", "256", "128", "", "32" };
>> +
>> +static const struct soc_enum nau8325_dac_oversampl_enum =
>> + SOC_ENUM_SINGLE(NAU8325_R29_DAC_CTRL1, NAU8325_DAC_OVERSAMPLE_SFT,
>> + ARRAY_SIZE(nau8325_dac_oversampl),
>> + nau8325_dac_oversampl);
> This should really be a SOC_VALUE_ENUM so you can just hide the fourth
> value rather than having the empty (presumably invalid) option. Please
> send an incremental patch doing this.
okay, thanks for reminding.
________________________________
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
^ permalink raw reply
* RE: [PATCH v2 5/6] PCI: dwc: rcar-gen4: Add support for other R-Car Gen4 PCIe controller
From: Yoshihiro Shimoda @ 2024-03-29 2:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: lpieralisi@kernel.org, kw@linux.com, robh@kernel.org,
bhelgaas@google.com, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, mani@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <20240327181451.GA1531625@bhelgaas>
Hi Bjorn,
> From: Bjorn Helgaas, Sent: Thursday, March 28, 2024 3:15 AM
>
> On Wed, Mar 27, 2024 at 05:32:57AM +0000, Yoshihiro Shimoda wrote:
> > > From: Bjorn Helgaas, Sent: Wednesday, March 27, 2024 5:49 AM
>
> > > > static int rcar_gen4_pcie_get_resources(struct rcar_gen4_pcie *rcar)
> > > > {
> > > > + rcar->phy_base = devm_platform_ioremap_resource_byname(rcar->pdev, "phy");
> > > > + if (IS_ERR(rcar->phy_base))
> > > > + return PTR_ERR(rcar->base);
> > >
> > > I don't get it. This imposes a new requirement (presence of "phy"
> > > resource) on the existing SoCs. That doesn't sound right.
> >
> > According to the dt-binding doc, the existing SoCs are also required
> > for the "phy". That's why I didn't add any condition to simplify
> > the code.
>
> Is there anything that enforces that? Is it possible that DTs exist
> in the field without it? We don't want to break any existing setup.
Using make dtbs_check can detect an error if the "phy" doesn't exist like below:
/home/shimoda/development/linux/linux/arch/arm64/boot/dts/renesas/r8a779f0-spider.dtb: pcie@e65d0000: reg-names:5: 'phy' was expected
from schema $id: http://devicetree.org/schemas/pci/rcar-gen4-pci-host.yaml#
So, I believe that this can enforce that in review process at least.
Now arch/arm64/boot/dts/renesas/r8a779f0.dtsi has the pcie compatible,
and all pcie nodes in the dtsi have "phy". So, this patch will not break any existing setup.
Best regards,
Yoshihiro Shimoda
^ permalink raw reply
* [PATCH v6 3/3] dmaengine: add driver for Sophgo CV18XX/SG200X dmamux
From: Inochi Amaoto @ 2024-03-29 2:04 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB4953F0FAED4373660C7873A2BB3A2@IA1PR20MB4953.namprd20.prod.outlook.com>
Sophgo CV18XX/SG200X use DW AXI CORE with a multiplexer for remapping
its request lines. The multiplexer supports at most 8 request lines.
Add driver for Sophgo CV18XX/SG200X DMA multiplexer.
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
---
drivers/dma/Kconfig | 9 ++
drivers/dma/Makefile | 1 +
drivers/dma/cv1800-dmamux.c | 267 ++++++++++++++++++++++++++++++++++++
3 files changed, 277 insertions(+)
create mode 100644 drivers/dma/cv1800-dmamux.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 002a5ec80620..cb31520b9f86 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -546,6 +546,15 @@ config PLX_DMA
These are exposed via extra functions on the switch's
upstream port. Each function exposes one DMA channel.
+config SOPHGO_CV1800_DMAMUX
+ tristate "Sophgo CV1800/SG2000 series SoC DMA multiplexer support"
+ depends on MFD_SYSCON
+ depends on ARCH_SOPHGO
+ help
+ Support for the DMA multiplexer on Sophgo CV1800/SG2000
+ series SoCs.
+ Say Y here if your board have this soc.
+
config STE_DMA40
bool "ST-Ericsson DMA40 support"
depends on ARCH_U8500
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index dfd40d14e408..7465f249ee47 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SF_PDMA) += sf-pdma/
+obj-$(CONFIG_SOPHGO_CV1800_DMAMUX) += cv1800-dmamux.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
obj-$(CONFIG_STM32_DMA) += stm32-dma.o
obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
diff --git a/drivers/dma/cv1800-dmamux.c b/drivers/dma/cv1800-dmamux.c
new file mode 100644
index 000000000000..709414898b67
--- /dev/null
+++ b/drivers/dma/cv1800-dmamux.c
@@ -0,0 +1,267 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/module.h>
+#include <linux/of_dma.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/llist.h>
+#include <linux/regmap.h>
+#include <linux/spinlock.h>
+#include <linux/mfd/syscon.h>
+
+#include <soc/sophgo/cv1800-sysctl.h>
+
+#define DMAMUX_NCELLS 2
+#define MAX_DMA_MAPPING_ID 42
+#define MAX_DMA_CPU_ID 2
+#define MAX_DMA_CH_ID 7
+
+#define DMAMUX_INTMUX_REGISTER_LEN 4
+#define DMAMUX_NR_CH_PER_REGISTER 4
+#define DMAMUX_BIT_PER_CH 8
+#define DMAMUX_CH_MASk GENMASK(5, 0)
+#define DMAMUX_INT_BIT_PER_CPU 10
+#define DMAMUX_CH_UPDATE_BIT BIT(31)
+
+#define DMAMUX_CH_REGPOS(chid) \
+ ((chid) / DMAMUX_NR_CH_PER_REGISTER)
+#define DMAMUX_CH_REGOFF(chid) \
+ ((chid) % DMAMUX_NR_CH_PER_REGISTER)
+#define DMAMUX_CH_REG(chid) \
+ ((DMAMUX_CH_REGPOS(chid) * sizeof(u32)) + \
+ CV1800_SDMA_DMA_CHANNEL_REMAP0)
+#define DMAMUX_CH_SET(chid, val) \
+ (((val) << (DMAMUX_CH_REGOFF(chid) * DMAMUX_BIT_PER_CH)) | \
+ DMAMUX_CH_UPDATE_BIT)
+#define DMAMUX_CH_MASK(chid) \
+ DMAMUX_CH_SET(chid, DMAMUX_CH_MASk)
+
+#define DMAMUX_INT_BIT(chid, cpuid) \
+ BIT((cpuid) * DMAMUX_INT_BIT_PER_CPU + (chid))
+#define DMAMUX_INTEN_BIT(cpuid) \
+ DMAMUX_INT_BIT(8, cpuid)
+#define DMAMUX_INT_CH_BIT(chid, cpuid) \
+ (DMAMUX_INT_BIT(chid, cpuid) | DMAMUX_INTEN_BIT(cpuid))
+#define DMAMUX_INT_MASK(chid) \
+ (DMAMUX_INT_BIT(chid, 0) | \
+ DMAMUX_INT_BIT(chid, 1) | \
+ DMAMUX_INT_BIT(chid, 2))
+#define DMAMUX_INT_CH_MASK(chid, cpuid) \
+ (DMAMUX_INT_MASK(chid) | DMAMUX_INTEN_BIT(cpuid))
+
+struct cv1800_dmamux_data {
+ struct dma_router dmarouter;
+ struct regmap *regmap;
+ spinlock_t lock;
+ struct llist_head free_maps;
+ struct llist_head reserve_maps;
+ DECLARE_BITMAP(mapped_peripherals, MAX_DMA_MAPPING_ID);
+};
+
+struct cv1800_dmamux_map {
+ struct llist_node node;
+ unsigned int channel;
+ unsigned int peripheral;
+ unsigned int cpu;
+};
+
+static void cv1800_dmamux_free(struct device *dev, void *route_data)
+{
+ struct cv1800_dmamux_data *dmamux = dev_get_drvdata(dev);
+ struct cv1800_dmamux_map *map = route_data;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dmamux->lock, flags);
+
+ regmap_update_bits(dmamux->regmap,
+ DMAMUX_CH_REG(map->channel),
+ DMAMUX_CH_MASK(map->channel),
+ DMAMUX_CH_UPDATE_BIT);
+
+ regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
+ DMAMUX_INT_CH_MASK(map->channel, map->cpu),
+ DMAMUX_INTEN_BIT(map->cpu));
+
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+
+ dev_info(dev, "free channel %u for req %u (cpu %u)\n",
+ map->channel, map->peripheral, map->cpu);
+}
+
+static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
+ struct cv1800_dmamux_data *dmamux = platform_get_drvdata(pdev);
+ struct cv1800_dmamux_map *map;
+ struct llist_node *node;
+ unsigned long flags;
+ unsigned int chid, devid, cpuid;
+ int ret;
+
+ if (dma_spec->args_count != DMAMUX_NCELLS) {
+ dev_err(&pdev->dev, "invalid number of dma mux args\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ devid = dma_spec->args[0];
+ cpuid = dma_spec->args[1];
+ dma_spec->args_count = 1;
+
+ if (devid > MAX_DMA_MAPPING_ID) {
+ dev_err(&pdev->dev, "invalid device id: %u\n", devid);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (cpuid > MAX_DMA_CPU_ID) {
+ dev_err(&pdev->dev, "invalid cpu id: %u\n", cpuid);
+ return ERR_PTR(-EINVAL);
+ }
+
+ dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0);
+ if (!dma_spec->np) {
+ dev_err(&pdev->dev, "can't get dma master\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ spin_lock_irqsave(&dmamux->lock, flags);
+
+ if (test_bit(devid, dmamux->mapped_peripherals)) {
+ llist_for_each_entry(map, dmamux->reserve_maps.first, node) {
+ if (map->peripheral == devid && map->cpu == cpuid)
+ goto found;
+ }
+
+ ret = -EINVAL;
+ goto failed;
+ } else {
+ node = llist_del_first(&dmamux->free_maps);
+ if (!node) {
+ ret = -ENODEV;
+ goto failed;
+ }
+
+ map = llist_entry(node, struct cv1800_dmamux_map, node);
+ llist_add(&map->node, &dmamux->reserve_maps);
+ set_bit(devid, dmamux->mapped_peripherals);
+ }
+
+found:
+ chid = map->channel;
+ map->peripheral = devid;
+ map->cpu = cpuid;
+
+ regmap_set_bits(dmamux->regmap,
+ DMAMUX_CH_REG(chid),
+ DMAMUX_CH_SET(chid, devid));
+
+ regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
+ DMAMUX_INT_CH_MASK(chid, cpuid),
+ DMAMUX_INT_CH_BIT(chid, cpuid));
+
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+
+ dma_spec->args[0] = chid;
+
+ dev_info(&pdev->dev, "register channel %u for req %u (cpu %u)\n",
+ chid, devid, cpuid);
+
+ return map;
+
+failed:
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+ of_node_put(dma_spec->np);
+ dev_err(&pdev->dev, "errno %d\n", ret);
+ return ERR_PTR(ret);
+
+}
+
+static int cv1800_dmamux_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *mux_node = dev->of_node;
+ struct cv1800_dmamux_data *data;
+ struct cv1800_dmamux_map *tmp;
+ struct device *parent = dev->parent;
+ struct device_node *dma_master;
+ struct regmap *regmap = NULL;
+ unsigned int i;
+
+ if (!parent)
+ return -ENODEV;
+
+ regmap = device_node_to_regmap(parent->of_node);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ dma_master = of_parse_phandle(mux_node, "dma-masters", 0);
+ if (!dma_master) {
+ dev_err(dev, "invalid dma-requests property\n");
+ return -ENODEV;
+ }
+ of_node_put(dma_master);
+
+ data = devm_kmalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ spin_lock_init(&data->lock);
+ init_llist_head(&data->free_maps);
+
+ for (i = 0; i <= MAX_DMA_CH_ID; i++) {
+ tmp = devm_kmalloc(dev, sizeof(*tmp), GFP_KERNEL);
+ if (!tmp) {
+ /* It is OK for not allocating all channel */
+ dev_warn(dev, "can not allocate channel %u\n", i);
+ continue;
+ }
+
+ init_llist_node(&tmp->node);
+ tmp->channel = i;
+ llist_add(&tmp->node, &data->free_maps);
+ }
+
+ /* if no channel is allocated, the probe must fail */
+ if (llist_empty(&data->free_maps))
+ return -ENOMEM;
+
+ data->regmap = regmap;
+ data->dmarouter.dev = dev;
+ data->dmarouter.route_free = cv1800_dmamux_free;
+
+ platform_set_drvdata(pdev, data);
+
+ return of_dma_router_register(mux_node,
+ cv1800_dmamux_route_allocate,
+ &data->dmarouter);
+}
+
+static void cv1800_dmamux_remove(struct platform_device *pdev)
+{
+ of_dma_controller_free(pdev->dev.of_node);
+}
+
+static const struct of_device_id cv1800_dmamux_ids[] = {
+ { .compatible = "sophgo,cv1800-dmamux", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, cv1800_dmamux_ids);
+
+static struct platform_driver cv1800_dmamux_driver = {
+ .driver = {
+ .name = "cv1800-dmamux",
+ .of_match_table = cv1800_dmamux_ids,
+ },
+ .probe = cv1800_dmamux_probe,
+ .remove_new = cv1800_dmamux_remove,
+};
+module_platform_driver(cv1800_dmamux_driver);
+
+MODULE_AUTHOR("Inochi Amaoto <inochiama@outlook.com>");
+MODULE_DESCRIPTION("Sophgo CV1800/SG2000 Series Soc DMAMUX driver");
+MODULE_LICENSE("GPL");
--
2.44.0
^ permalink raw reply related
* [PATCH v6 2/3] soc/sophgo: add top sysctrl layout file for CV18XX/SG200X
From: Inochi Amaoto @ 2024-03-29 2:04 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB4953F0FAED4373660C7873A2BB3A2@IA1PR20MB4953.namprd20.prod.outlook.com>
The "top" system controller of CV18XX/SG200X exposes control
register access for various devices. Add soc header file to
describe it.
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
---
include/soc/sophgo/cv1800-sysctl.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 include/soc/sophgo/cv1800-sysctl.h
diff --git a/include/soc/sophgo/cv1800-sysctl.h b/include/soc/sophgo/cv1800-sysctl.h
new file mode 100644
index 000000000000..b9396d33e240
--- /dev/null
+++ b/include/soc/sophgo/cv1800-sysctl.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com>
+ */
+
+#ifndef CV1800_SYSCTL_H
+#define CV1800_SYSCTL_H
+
+/*
+ * SOPHGO CV1800/SG2000 SoC top system controller registers offsets.
+ */
+
+#define CV1800_CONF_INFO 0x004
+#define CV1800_SYS_CTRL_REG 0x008
+#define CV1800_USB_PHY_CTRL_REG 0x048
+#define CV1800_SDMA_DMA_CHANNEL_REMAP0 0x154
+#define CV1800_SDMA_DMA_CHANNEL_REMAP1 0x158
+#define CV1800_TOP_TIMER_CLK_SEL 0x1a0
+#define CV1800_TOP_WDT_CTRL 0x1a8
+#define CV1800_DDR_AXI_URGENT_OW 0x1b8
+#define CV1800_DDR_AXI_URGENT 0x1bc
+#define CV1800_DDR_AXI_QOS_0 0x1d8
+#define CV1800_DDR_AXI_QOS_1 0x1dc
+#define CV1800_SD_PWRSW_CTRL 0x1f4
+#define CV1800_SD_PWRSW_TIME 0x1f8
+#define CV1800_DDR_AXI_QOS_OW 0x23c
+#define CV1800_SD_CTRL_OPT 0x294
+#define CV1800_SDMA_DMA_INT_MUX 0x298
+
+#endif // CV1800_SYSCTL_H
--
2.44.0
^ permalink raw reply related
* [PATCH v6 1/3] dt-bindings: dmaengine: Add dma multiplexer for CV18XX/SG200X series SoC
From: Inochi Amaoto @ 2024-03-29 2:04 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB4953F0FAED4373660C7873A2BB3A2@IA1PR20MB4953.namprd20.prod.outlook.com>
The DMA IP of Sophgo CV18XX/SG200X is based on a DW AXI CORE, with
an additional channel remap register located in the top system control
area. The DMA channel is exclusive to each core.
In addition, the DMA multiplexer is a subdevice of system controller,
so this binding only contains necessary properties for the multiplexer
itself.
Add the dmamux binding for CV18XX/SG200X series SoC.
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
---
.../bindings/dma/sophgo,cv1800-dmamux.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
diff --git a/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
new file mode 100644
index 000000000000..480cb117db9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/sophgo,cv1800-dmamux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV1800/SG200 Series DMA multiplexer
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+description: |
+ The DMA multiplexer of CV1800 is a subdevice of the system
+ controller. It support mapping 8 channels, but each channel
+ can be mapped only once.
+
+allOf:
+ - $ref: dma-router.yaml#
+
+properties:
+ compatible:
+ const: sophgo,cv1800-dmamux
+
+ reg:
+ items:
+ - description: DMA channal remapping register
+ - description: DMA channel interrupt mapping register
+
+ '#dma-cells':
+ const: 2
+ description:
+ The first cells is device id. The second one is the cpu id.
+
+ dma-masters:
+ maxItems: 1
+
+required:
+ - reg
+ - '#dma-cells'
+ - dma-masters
+
+additionalProperties: false
+
+examples:
+ - |
+ dma-router@154 {
+ compatible = "sophgo,cv1800-dmamux";
+ reg = <0x154 0x8>, <0x298 0x4>;
+ #dma-cells = <2>;
+ dma-masters = <&dmac>;
+ };
--
2.44.0
^ permalink raw reply related
* [PATCH v6 0/3] riscv: sophgo: add dmamux support for Sophgo CV1800/SG2000 SoCs
From: Inochi Amaoto @ 2024-03-29 2:03 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
Add dma multiplexer support for the Sophgo CV1800/SG2000 SoCs.
As the syscon device of CV1800 have a usb phy subdevices. The
binding of the syscon can not be complete without the usb phy
is finished. As a result, the binding of syscon is removed
and will be evolved in its original series after the usb phy
binding is fully explored.
Changed from v5:
1. remove dead binding header.
2. make "reg" required so the syscon binding can have the same
example node of the dmamux binding.
Changed from v4:
1. remove the syscon binding since it can not be complete (still
lack some subdevices)
2. add reg description for the binding,
3. remove the fixed channel assign for dmamux binding
3. driver adopt to the binding change. Now the driver allocates all the
channel when initing and maps the request chan to the channel dynamicly.
Changed from v3:
1. fix dt-binding address issue.
Changed from v2:
1. add reg property of dmamux node in the binding of patch 2
Changed from v1:
1. fix wrong title of patch 2.
Inochi Amaoto (3):
dt-bindings: dmaengine: Add dma multiplexer for CV18XX/SG200X series
SoC
soc/sophgo: add top sysctrl layout file for CV18XX/SG200X
dmaengine: add driver for Sophgo CV18XX/SG200X dmamux
.../bindings/dma/sophgo,cv1800-dmamux.yaml | 51 ++++
drivers/dma/Kconfig | 9 +
drivers/dma/Makefile | 1 +
drivers/dma/cv1800-dmamux.c | 267 ++++++++++++++++++
include/soc/sophgo/cv1800-sysctl.h | 30 ++
5 files changed, 358 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
create mode 100644 drivers/dma/cv1800-dmamux.c
create mode 100644 include/soc/sophgo/cv1800-sysctl.h
--
2.44.0
^ permalink raw reply
* [RFC PATCH 2/2] spi: add Siflower Quad SPI controller
From: Qingfang Deng @ 2024-03-29 1:51 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-spi, devicetree, linux-kernel
Cc: Qingfang Deng
In-Reply-To: <20240329015147.1481349-1-dqfext@gmail.com>
From: Qingfang Deng <qingfang.deng@siflower.com.cn>
Add Quad SPI controller driver for Siflower SoCs. It is based on ARM
PL022, with custom modifications to support Dual/Quad SPI modes.
Signed-off-by: Qingfang Deng <qingfang.deng@siflower.com.cn>
---
drivers/spi/Kconfig | 6 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-siflower-qspi.c | 414 ++++++++++++++++++++++++++++++++
3 files changed, 421 insertions(+)
create mode 100644 drivers/spi/spi-siflower-qspi.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index bc7021da2fe9..5e3a6b431a12 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -952,6 +952,12 @@ config SPI_SIFIVE
help
This exposes the SPI controller IP from SiFive.
+config SPI_SIFLOWER_QSPI
+ tristate "Siflower Quad SPI Controller"
+ depends on OF && SPI_MEM
+ help
+ Quad SPI driver for Siflower SoCs.
+
config SPI_SLAVE_MT27XX
tristate "MediaTek SPI slave device"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 4ff8d725ba5e..226aebe80a3d 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -126,6 +126,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
obj-$(CONFIG_SPI_SIFIVE) += spi-sifive.o
+obj-$(CONFIG_SPI_SIFLOWER_QSPI) += spi-siflower-qspi.o
obj-$(CONFIG_SPI_SLAVE_MT27XX) += spi-slave-mt27xx.o
obj-$(CONFIG_SPI_SN_F_OSPI) += spi-sn-f-ospi.o
obj-$(CONFIG_SPI_SPRD) += spi-sprd.o
diff --git a/drivers/spi/spi-siflower-qspi.c b/drivers/spi/spi-siflower-qspi.c
new file mode 100644
index 000000000000..fd814de4bc4e
--- /dev/null
+++ b/drivers/spi/spi-siflower-qspi.c
@@ -0,0 +1,414 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/sh_clk.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/sizes.h>
+
+#include <linux/spi/spi-mem.h>
+#include <linux/spi/spi.h>
+
+/*
+ * siflower SSP fifo level
+ * */
+#define SF_SSP_FIFO_LEVEL 0x100
+/*
+ * siflower SSP register
+ * */
+#define SSP_CR0 0x000
+#define SSP_CR1 0x004
+#define SSP_DR 0x008
+#define SSP_SR 0x00C
+#define SSP_CPSR 0x010
+#define SSP_IMSC 0x014
+#define SSP_RIS 0x018
+#define SSP_MIS 0x01C
+#define SSP_ICR 0x020
+#define SSP_DMACR 0x024
+#define SSP_FIFO_LEVEL 0x028
+#define SSP_EXSPI_CMD0 0x02C
+#define SSP_EXSPI_CMD1 0x030
+#define SSP_EXSPI_CMD2 0x034
+/* SSP Control Register 0 - SSP_CR0 */
+#define SSP_CR0_EXSPI_FRAME (0x3 << 4)
+#define SSP_CR0_SPO (0x1 << 6)
+#define SSP_CR0_SPH (0x1 << 7)
+#define SSP_CR0_BIT_MODE(x) ((x)-1)
+#define SSP_SCR_MIN (0x00)
+#define SSP_SCR_MAX (0xFF)
+#define SSP_SCR_SHFT 8
+#define DFLT_CLKRATE 2
+/* SSP Control Register 1 - SSP_CR1 */
+#define SSP_CR1_MASK_SSE (0x1 << 1)
+#define SSP_CPSR_MIN (0x02)
+#define SSP_CPSR_MAX (0xFE)
+#define DFLT_PRESCALE (0x40)
+/* SSP Status Register - SSP_SR */
+#define SSP_SR_MASK_TFE (0x1 << 0) /* Transmit FIFO empty */
+#define SSP_SR_MASK_TNF (0x1 << 1) /* Transmit FIFO not full */
+#define SSP_SR_MASK_RNE (0x1 << 2) /* Receive FIFO not empty */
+#define SSP_SR_MASK_RFF (0x1 << 3) /* Receive FIFO full */
+#define SSP_SR_MASK_BSY (0x1 << 4) /* Busy Flag */
+
+/* SSP FIFO Threshold Register - SSP_FIFO_LEVEL */
+#define SSP_FIFO_LEVEL_RX GENMASK(14, 8) /* Receive FIFO watermark */
+#define SSP_FIFO_LEVEL_TX GENMASK(6, 0) /* Transmit FIFO watermark */
+#define DFLT_THRESH_RX 32
+#define DFLT_THRESH_TX 32
+
+/* SSP Raw Interrupt Status Register - SSP_RIS */
+#define SSP_RIS_MASK_RORRIS (0x1 << 0) /* Receive Overrun */
+#define SSP_RIS_MASK_RTRIS (0x1 << 1) /* Receive Timeout */
+#define SSP_RIS_MASK_RXRIS (0x1 << 2) /* Receive FIFO Raw Interrupt status */
+#define SSP_RIS_MASK_TXRIS (0x1 << 3) /* Transmit FIFO Raw Interrupt status */
+
+/* EXSPI command register 0 SSP_EXSPI_CMD0 */
+#define EXSPI_CMD0_CMD_COUNT BIT(0) /* cmd byte, must be set at last */
+#define EXSPI_CMD0_ADDR_COUNT GENMASK(2, 1) /* addr bytes */
+#define EXSPI_CMD0_EHC_COUNT BIT(3) /* Set 1 for 4-byte address mode */
+#define EXSPI_CMD0_TX_COUNT GENMASK(14, 4) /* TX data bytes */
+#define EXSPI_CMD0_VALID BIT(15) /* Set 1 to make the cmd to be run */
+
+/* EXSPI command register 1 SSP_EXSPI_CMD1 */
+#define EXSPI_CMD1_DUMMY_COUNT GENMASK(3, 0) /* dummy bytes */
+#define EXSPI_CMD1_RX_COUNT GENMASK(14, 4) /* RX data bytes */
+
+/* EXSPI command register 2 SSP_EXSPI_CMD2 */
+/* Set 1 for 1-wire, 2 for 2-wire, 3 for 4-wire */
+#define EXSPI_CMD2_CMD_IO_MODE GENMASK(1, 0) /* cmd IO mode */
+#define EXSPI_CMD2_ADDR_IO_MODE GENMASK(3, 2) /* addr IO mode */
+#define EXSPI_CMD2_DATA_IO_MODE GENMASK(5, 4) /* data IO mode */
+
+#define SF_READ_TIMEOUT (10 * HZ)
+#define MAX_S_BUF 100
+
+struct sf_qspi {
+ void __iomem *base;
+ struct clk *clk;
+ struct device *dev;
+ u32 freq;
+ int mode_bit;
+};
+
+static void sf_qspi_flush_rxfifo(struct sf_qspi *s) {
+ while (readw(s->base + SSP_SR) & SSP_SR_MASK_RNE)
+ readw(s->base + SSP_DR);
+}
+
+static int sf_qspi_wait_not_busy(struct sf_qspi *s) {
+ unsigned long timeout = jiffies + SF_READ_TIMEOUT;
+
+ do {
+ if (!(readw(s->base + SSP_SR) & SSP_SR_MASK_BSY))
+ return 0;
+
+ cond_resched();
+ } while (time_after(timeout, jiffies));
+
+ dev_err(s->dev, "I/O timed out\n");
+ return -ETIMEDOUT;
+}
+
+static int sf_qspi_wait_rx_not_empty(struct sf_qspi *s) {
+ unsigned long timeout = jiffies + SF_READ_TIMEOUT;
+
+ do {
+ if (readw(s->base + SSP_SR) & SSP_SR_MASK_RNE)
+ return 0;
+
+ cond_resched();
+ } while (time_after(timeout, jiffies));
+
+ dev_err(s->dev, "read timed out\n");
+ return -ETIMEDOUT;
+}
+
+static int sf_qspi_wait_rxfifo(struct sf_qspi *s) {
+ unsigned long timeout = jiffies + SF_READ_TIMEOUT;
+
+ do {
+ if (readw(s->base + SSP_RIS) & SSP_RIS_MASK_RXRIS)
+ return 0;
+
+ cond_resched();
+ } while (time_after(timeout, jiffies));
+
+ dev_err(s->dev, "read timed out\n");
+ return -ETIMEDOUT;
+}
+
+static void sf_qspi_enable(struct sf_qspi *s) {
+ /* Enable the SPI hardware */
+ writew(SSP_CR1_MASK_SSE, s->base + SSP_CR1);
+}
+
+static void sf_qspi_disable(struct sf_qspi *s) {
+ /* Disable the SPI hardware */
+ writew(0, s->base + SSP_CR1);
+}
+
+static void sf_qspi_xmit(struct sf_qspi *s, unsigned int nbytes, const u8 *out)
+{
+ while (nbytes--)
+ writew(*out++, s->base + SSP_DR);
+}
+
+static int sf_qspi_rcv(struct sf_qspi *s, unsigned int nbytes, u8 *in)
+{
+ int ret, i;
+
+ while (nbytes >= DFLT_THRESH_RX) {
+ /* wait for RX FIFO to reach the threshold */
+ ret = sf_qspi_wait_rxfifo(s);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < DFLT_THRESH_RX; i++)
+ *in++ = readw(s->base + SSP_DR);
+
+ nbytes -= DFLT_THRESH_RX;
+ }
+
+ /* read the remaining data */
+ while (nbytes) {
+ ret = sf_qspi_wait_rx_not_empty(s);
+ if (ret)
+ return ret;
+
+ *in++ = readw(s->base + SSP_DR);
+ nbytes--;
+ }
+
+ return 0;
+}
+
+static inline u32 spi_rate(u32 rate, u16 csdvsr, u16 scr) {
+ return rate / (csdvsr * (1 + scr));
+}
+
+static void sf_qspi_set_param(struct sf_qspi *s, const struct spi_mem_op *op) {
+ unsigned int tx_count = 0, rx_count = 0;
+ u8 cmd_io, addr_io, data_io;
+ u8 cmd_count, addr_count, ehc_count;
+
+ cmd_io = op->cmd.buswidth == 4 ? 3 : op->cmd.buswidth;
+ addr_io = op->addr.buswidth == 4 ? 3 : op->addr.buswidth;
+ data_io = op->data.buswidth == 4 ? 3 : op->data.buswidth;
+
+ if (op->data.nbytes) {
+ if (op->data.dir == SPI_MEM_DATA_IN) {
+ rx_count = op->data.nbytes;
+ } else {
+ tx_count = op->data.nbytes;
+ }
+ }
+ if (op->addr.nbytes > 3) {
+ addr_count = 3;
+ ehc_count = 1;
+ } else {
+ addr_count = op->addr.nbytes;
+ ehc_count = 0;
+ }
+ cmd_count = op->cmd.nbytes;
+
+ writew(FIELD_PREP(EXSPI_CMD2_CMD_IO_MODE, cmd_io) |
+ FIELD_PREP(EXSPI_CMD2_ADDR_IO_MODE, addr_io) |
+ FIELD_PREP(EXSPI_CMD2_DATA_IO_MODE, data_io),
+ s->base + SSP_EXSPI_CMD2);
+ writew(FIELD_PREP(EXSPI_CMD1_DUMMY_COUNT, op->dummy.nbytes) |
+ FIELD_PREP(EXSPI_CMD1_RX_COUNT, rx_count),
+ s->base + SSP_EXSPI_CMD1);
+ writew(EXSPI_CMD0_VALID |
+ FIELD_PREP(EXSPI_CMD0_CMD_COUNT, op->cmd.nbytes) |
+ FIELD_PREP(EXSPI_CMD0_ADDR_COUNT, addr_count) |
+ FIELD_PREP(EXSPI_CMD0_EHC_COUNT, ehc_count) |
+ FIELD_PREP(EXSPI_CMD0_TX_COUNT, tx_count),
+ s->base + SSP_EXSPI_CMD0);
+}
+
+static int sf_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ struct sf_qspi *s = spi_controller_get_devdata(mem->spi->master);
+ unsigned int pops = 0;
+ int ret, i, op_len;
+ const u8 *tx_buf = NULL;
+ u8 *rx_buf = NULL, op_buf[MAX_S_BUF];
+
+ if (op->data.nbytes) {
+ if (op->data.dir == SPI_MEM_DATA_IN) {
+ rx_buf = op->data.buf.in;
+ } else {
+ tx_buf = op->data.buf.out;
+ }
+ }
+ op_len = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
+ sf_qspi_set_param(s, op);
+ /*
+ * Avoid using malloc() here so that we can use this code in SPL where
+ * simple malloc may be used. That implementation does not allow free()
+ * so repeated calls to this code can exhaust the space.
+ *
+ * The value of op_len is small, since it does not include the actual
+ * data being sent, only the op-code and address. In fact, it should be
+ * popssible to just use a small fixed value here instead of op_len.
+ */
+ op_buf[pops++] = op->cmd.opcode;
+ if (op->addr.nbytes) {
+ for (i = 0; i < op->addr.nbytes; i++)
+ op_buf[pops + i] = op->addr.val >>
+ (8 * (op->addr.nbytes - i - 1));
+ pops += op->addr.nbytes;
+ }
+
+ sf_qspi_flush_rxfifo(s);
+ memset(op_buf + pops, 0xff, op->dummy.nbytes);
+ sf_qspi_xmit(s, op_len, op_buf);
+ if (tx_buf) {
+ sf_qspi_xmit(s, op->data.nbytes, tx_buf);
+ }
+ sf_qspi_enable(s);
+ if (rx_buf) {
+ ret = sf_qspi_rcv(s, op->data.nbytes, rx_buf);
+ } else {
+ ret = sf_qspi_wait_not_busy(s);
+ }
+ sf_qspi_disable(s);
+ return ret;
+}
+
+static int sf_qspi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
+{
+ u32 nbytes;
+
+ nbytes = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
+ if (nbytes >= SF_SSP_FIFO_LEVEL)
+ return -ENOTSUPP;
+
+ if (op->data.dir == SPI_MEM_DATA_IN)
+ op->data.nbytes = min_t(unsigned int, op->data.nbytes,
+ SF_SSP_FIFO_LEVEL);
+ else
+ op->data.nbytes = min_t(unsigned int, op->data.nbytes,
+ SF_SSP_FIFO_LEVEL - nbytes);
+
+ return 0;
+}
+
+static int sf_qspi_default_setup(struct sf_qspi *s) {
+ u16 scr = SSP_SCR_MIN, cr0 = 0, cpsr = SSP_CPSR_MIN, best_scr = scr, best_cpsr = cpsr;
+ u32 min, max, best_freq = 0, tmp;
+ u32 rate = clk_get_rate(s->clk), speed = s->freq;
+ bool found = false;
+
+ writew(DFLT_PRESCALE, s->base + SSP_CPSR);
+
+ max = spi_rate(rate, SSP_CPSR_MIN, SSP_SCR_MIN);
+ min = spi_rate(rate, SSP_CPSR_MAX, SSP_SCR_MAX);
+
+ if (speed > max || speed < min) {
+ dev_err(s->dev, "Tried to set speed to %dHz but min=%d and max=%d\n", speed, min, max);
+ return -EINVAL;
+ }
+ while (cpsr <= SSP_CPSR_MAX && !found) {
+ while (scr <= SSP_SCR_MAX) {
+ tmp = spi_rate(rate, cpsr, scr);
+ if (abs(speed - tmp) < abs(speed - best_freq)) {
+ best_freq = tmp;
+ best_cpsr = cpsr;
+ best_scr = scr;
+ if (tmp == speed) {
+ found = true;
+ break;
+ }
+ }
+ scr++;
+ }
+ cpsr += 2;
+ scr = SSP_SCR_MIN;
+ }
+ writew(best_cpsr, s->base + SSP_CPSR);
+ cr0 = SSP_CR0_BIT_MODE(8);
+ cr0 |= best_scr << 8;
+ /*set module*/
+ cr0 &= ~(SSP_CR0_SPH | SSP_CR0_SPO);
+ if(s->mode_bit & SPI_CPHA)
+ cr0 |= SSP_CR0_SPH;
+ if(s->mode_bit & SPI_CPOL)
+ cr0 |= SSP_CR0_SPO;
+ cr0 |= SSP_CR0_EXSPI_FRAME;
+ writew(cr0, s->base + SSP_CR0);
+ /*clear and enable interrupt*/
+ writew(FIELD_PREP(SSP_FIFO_LEVEL_RX, DFLT_THRESH_RX) |
+ FIELD_PREP(SSP_FIFO_LEVEL_TX, DFLT_THRESH_TX),
+ s->base + SSP_FIFO_LEVEL);
+
+ return 0;
+}
+
+static const struct spi_controller_mem_ops sf_qspi_mem_ops = {
+ .adjust_op_size = sf_qspi_adjust_op_size,
+ .exec_op = sf_qspi_exec_op,
+};
+
+static int sf_qspi_probe(struct platform_device *pdev) {
+ struct spi_controller *master;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node, *nc;
+ struct sf_qspi *s;
+
+ master = devm_spi_alloc_host(&pdev->dev, sizeof(*s));
+ if (!master)
+ return -ENOMEM;
+ master->mode_bits = SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL |
+ SPI_TX_QUAD;
+ s = spi_controller_get_devdata(master);
+ s->dev = dev;
+ s->mode_bit = 0;
+ platform_set_drvdata(pdev, s);
+ s->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(s->base))
+ return PTR_ERR(s->base);
+
+ s->clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(s->clk))
+ return PTR_ERR(s->clk);
+
+ for_each_available_child_of_node(dev->of_node, nc) {
+ of_property_read_u32(nc, "spi-max-frequency", &s->freq);
+ }
+
+ master->bus_num = pdev->id;
+ master->num_chipselect = 1;
+
+ master->mem_ops = &sf_qspi_mem_ops;
+ sf_qspi_default_setup(s);
+ master->dev.of_node = np;
+ return devm_spi_register_controller(dev, master);
+}
+
+static const struct of_device_id sf_qspi_ids[] = {
+ { .compatible = "siflower,qspi" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sf_qspi_ids);
+
+static struct platform_driver sf_qspi_driver = {
+ .driver = {
+ .name = "siflower_qspi",
+ .of_match_table = sf_qspi_ids,
+ },
+ .probe = sf_qspi_probe,
+};
+module_platform_driver(sf_qspi_driver);
+
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 1/2] spi: dt-bindings: add Siflower Quad SPI controller
From: Qingfang Deng @ 2024-03-29 1:51 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Qingfang Deng, linux-spi, devicetree, linux-kernel
From: Qingfang Deng <qingfang.deng@siflower.com.cn>
Add YAML devicetree bindings for Siflower Quad SPI controller.
Signed-off-by: Qingfang Deng <qingfang.deng@siflower.com.cn>
---
.../bindings/spi/siflower,qspi.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/siflower,qspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/siflower,qspi.yaml b/Documentation/devicetree/bindings/spi/siflower,qspi.yaml
new file mode 100644
index 000000000000..c2dbe82affc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/siflower,qspi.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/siflower,qspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Siflower Quad Serial Peripheral Interface (QSPI)
+
+maintainers:
+ - Qingfang Deng <qingfang.deng@siflower.com.cn>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: siflower,qspi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#address-cells'
+ - '#size-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@c200000 {
+ compatible = "siflower,qspi";
+ reg = <0 0xc200000 0 0x1000>;
+ clocks = <&apb_clk>;
+ interrupts = <39>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add DP output
From: Dmitry Baryshkov @ 2024-03-29 1:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Bjorn Andersson, cros-qcom-dts-watchers, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240329013743.GA3476498@hu-bjorande-lv.qualcomm.com>
On Fri, 29 Mar 2024 at 03:37, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
>
> On Thu, Mar 28, 2024 at 09:17:45AM +0200, Dmitry Baryshkov wrote:
> > On Thu, 28 Mar 2024 at 05:07, Bjorn Andersson <andersson@kernel.org> wrote:
> > >
> > > On Thu, Mar 28, 2024 at 03:51:54AM +0200, Dmitry Baryshkov wrote:
> > > > On Wed, 27 Mar 2024 at 04:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
> > > > >
> > > > > The RB3Gen2 board comes with a mini DP connector, describe this, enable
> > > > > MDSS, DP controller and the PHY that drives this.
> > > > >
> > > > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > > > > ---
> > > > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 40 ++++++++++++++++++++++++++++
> > > > > 1 file changed, 40 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > index 63ebe0774f1d..f90bf3518e98 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > @@ -39,6 +39,20 @@ chosen {
> > > > > stdout-path = "serial0:115200n8";
> > > > > };
> > > > >
> > > > > + dp-connector {
> > > > > + compatible = "dp-connector";
> > > > > + label = "DP";
> > > > > + type = "mini";
> > > > > +
> > > > > + hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> > > >
> > > > Is it the standard hpd gpio? If so, is there any reason for using it
> > > > through dp-connector rather than as a native HPD signal?
> > > >
> > >
> > > I added it because you asked for it. That said, I do like having it
> > > clearly defined in the devicetree.
> >
> > I asked for the dp-connector device, not for the HPD function change.
> >
>
> I didn't realize that you could have a dp-connector device without
> defining the hpd-gpios, but it looks like you're right.
>
> Do we have any reason for using the internal HPD, when we're already
> spending the memory to allocate the dp-connector device?
No, no particular reason. I was trying to understand if there was any
reason for that from your side.
Then:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> PS. It's recommended that you dynamically switch to GPIO-based HPD in
> lower-power scenarios, as this allow you to turn off the DP controller
> and still detect plug events...
I don't think rb3g2 is a low-power device, but I think this is still a
valid argument.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add DP output
From: Bjorn Andersson @ 2024-03-29 1:37 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, cros-qcom-dts-watchers, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <CAA8EJppCuoOnaB03GsjXGYSs5Q9iQ2uXHWQqfkPA5jKzdHc8NQ@mail.gmail.com>
On Thu, Mar 28, 2024 at 09:17:45AM +0200, Dmitry Baryshkov wrote:
> On Thu, 28 Mar 2024 at 05:07, Bjorn Andersson <andersson@kernel.org> wrote:
> >
> > On Thu, Mar 28, 2024 at 03:51:54AM +0200, Dmitry Baryshkov wrote:
> > > On Wed, 27 Mar 2024 at 04:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
> > > >
> > > > The RB3Gen2 board comes with a mini DP connector, describe this, enable
> > > > MDSS, DP controller and the PHY that drives this.
> > > >
> > > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 40 ++++++++++++++++++++++++++++
> > > > 1 file changed, 40 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > index 63ebe0774f1d..f90bf3518e98 100644
> > > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > @@ -39,6 +39,20 @@ chosen {
> > > > stdout-path = "serial0:115200n8";
> > > > };
> > > >
> > > > + dp-connector {
> > > > + compatible = "dp-connector";
> > > > + label = "DP";
> > > > + type = "mini";
> > > > +
> > > > + hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> > >
> > > Is it the standard hpd gpio? If so, is there any reason for using it
> > > through dp-connector rather than as a native HPD signal?
> > >
> >
> > I added it because you asked for it. That said, I do like having it
> > clearly defined in the devicetree.
>
> I asked for the dp-connector device, not for the HPD function change.
>
I didn't realize that you could have a dp-connector device without
defining the hpd-gpios, but it looks like you're right.
Do we have any reason for using the internal HPD, when we're already
spending the memory to allocate the dp-connector device?
PS. It's recommended that you dynamically switch to GPIO-based HPD in
lower-power scenarios, as this allow you to turn off the DP controller
and still detect plug events...
Regards,
Bjorn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox