* Re: [PATCH v11 00/11] Support page table check PowerPC
From: Christophe Leroy @ 2024-03-29 8:29 UTC (permalink / raw)
To: Rohan McLure, linuxppc-dev@lists.ozlabs.org
Cc: mpe@ellerman.id.au, linux-mm@kvack.org,
linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, x86@kernel.org
In-Reply-To: <eb906bc3-b372-449b-a351-eb739ffa7418@csgroup.eu>
Le 28/03/2024 à 08:57, Christophe Leroy a écrit :
>
>
> Le 28/03/2024 à 07:52, Christophe Leroy a écrit :
>>
>>
>> Le 28/03/2024 à 05:55, Rohan McLure a écrit :
>>> Support page table check on all PowerPC platforms. This works by
>>> serialising assignments, reassignments and clears of page table
>>> entries at each level in order to ensure that anonymous mappings
>>> have at most one writable consumer, and likewise that file-backed
>>> mappings are not simultaneously also anonymous mappings.
>>>
>>> In order to support this infrastructure, a number of stubs must be
>>> defined for all powerpc platforms. Additionally, seperate set_pte_at()
>>> and set_pte_at_unchecked(), to allow for internal, uninstrumented
>>> mappings.
>>
>> I gave it a try on QEMU e500 (64 bits), and get the following Oops.
>> What do I have to look for ?
>>
>> Freeing unused kernel image (initmem) memory: 2588K
>> This architecture does not have kernel memory protection.
>> Run /init as init process
>> ------------[ cut here ]------------
>> kernel BUG at mm/page_table_check.c:119!
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> BE PAGE_SIZE=4K SMP NR_CPUS=32 QEMU e500
>
> Same problem on my 8xx board:
>
> [ 7.358146] Freeing unused kernel image (initmem) memory: 448K
> [ 7.363957] Run /init as init process
> [ 7.370955] ------------[ cut here ]------------
> [ 7.375411] kernel BUG at mm/page_table_check.c:119!
> [ 7.380393] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 7.385621] BE PAGE_SIZE=16K PREEMPT CMPC885
Both problems are fixed by following change:
diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
b/arch/powerpc/include/asm/nohash/pgtable.h
index 413d01a51e6f..5b932632a5d7 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -29,6 +29,8 @@ static inline pte_basic_t pte_update(struct mm_struct
*mm, unsigned long addr, p
#ifndef __ASSEMBLY__
+#include <linux/page_table_check.h>
+
extern int icache_44x_need_flush;
/*
@@ -92,7 +94,11 @@ static inline void ptep_set_wrprotect(struct
mm_struct *mm, unsigned long addr,
static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned
long addr,
pte_t *ptep)
{
- return __pte(pte_update(mm, addr, ptep, ~0UL, 0, 0));
+ pte_t old_pte = __pte(pte_update(mm, addr, ptep, ~0UL, 0, 0));
+
+ page_table_check_pte_clear(mm, addr, old_pte);
+
+ return old_pte;
}
#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 02/15] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
From: Samuel Holland @ 2024-03-29 7:18 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
Russell King
In-Reply-To: <20240329072441.591471-1-samuel.holland@sifive.com>
ARM provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
(no changes since v2)
Changes in v2:
- Remove file name from header comment
arch/arm/Kconfig | 1 +
arch/arm/Makefile | 7 +++++++
arch/arm/include/asm/fpu.h | 15 +++++++++++++++
3 files changed, 23 insertions(+)
create mode 100644 arch/arm/include/asm/fpu.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b14aed3a17ab..b1751c2cab87 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -15,6 +15,7 @@ config ARM
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
select ARCH_HAS_KCOV
+ select ARCH_HAS_KERNEL_FPU_SUPPORT if KERNEL_MODE_NEON
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d82908b1b1bb..71afdd98ddf2 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -130,6 +130,13 @@ endif
# Accept old syntax despite ".syntax unified"
AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
+# The GCC option -ffreestanding is required in order to compile code containing
+# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
+CC_FLAGS_FPU := -ffreestanding
+# Enable <arm_neon.h>
+CC_FLAGS_FPU += -isystem $(shell $(CC) -print-file-name=include)
+CC_FLAGS_FPU += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
+
ifeq ($(CONFIG_THUMB2_KERNEL),y)
CFLAGS_ISA :=-Wa,-mimplicit-it=always $(AFLAGS_NOWARN)
AFLAGS_ISA :=$(CFLAGS_ISA) -Wa$(comma)-mthumb
diff --git a/arch/arm/include/asm/fpu.h b/arch/arm/include/asm/fpu.h
new file mode 100644
index 000000000000..2ae50bdce59b
--- /dev/null
+++ b/arch/arm/include/asm/fpu.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef __ASM_FPU_H
+#define __ASM_FPU_H
+
+#include <asm/neon.h>
+
+#define kernel_fpu_available() cpu_has_neon()
+#define kernel_fpu_begin() kernel_neon_begin()
+#define kernel_fpu_end() kernel_neon_end()
+
+#endif /* ! __ASM_FPU_H */
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 05/15] arm64: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
From: Samuel Holland @ 2024-03-29 7:18 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
Catalin Marinas, Will Deacon
In-Reply-To: <20240329072441.591471-1-samuel.holland@sifive.com>
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
(no changes since v2)
Changes in v2:
- New patch for v2
arch/arm64/lib/Makefile | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 29490be2546b..13e6a2829116 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -7,10 +7,8 @@ lib-y := clear_user.o delay.o copy_from_user.o \
ifeq ($(CONFIG_KERNEL_MODE_NEON), y)
obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
-CFLAGS_REMOVE_xor-neon.o += -mgeneral-regs-only
-CFLAGS_xor-neon.o += -ffreestanding
-# Enable <arm_neon.h>
-CFLAGS_xor-neon.o += -isystem $(shell $(CC) -print-file-name=include)
+CFLAGS_xor-neon.o += $(CC_FLAGS_FPU)
+CFLAGS_REMOVE_xor-neon.o += $(CC_FLAGS_NO_FPU)
endif
lib-$(CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE) += uaccess_flushcache.o
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 06/15] lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
From: Samuel Holland @ 2024-03-29 7:18 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
Catalin Marinas, Russell King, Will Deacon
In-Reply-To: <20240329072441.591471-1-samuel.holland@sifive.com>
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
Changes in v4:
- Add missed CFLAGS changes for recov_neon_inner.c
(fixes arm build failures)
lib/raid6/Makefile | 33 ++++++++++-----------------------
1 file changed, 10 insertions(+), 23 deletions(-)
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 385a94aa0b99..0e88bfe6445b 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -33,25 +33,6 @@ CFLAGS_REMOVE_vpermxor8.o += -msoft-float
endif
endif
-# The GCC option -ffreestanding is required in order to compile code containing
-# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
-ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
-NEON_FLAGS := -ffreestanding
-# Enable <arm_neon.h>
-NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include)
-ifeq ($(ARCH),arm)
-NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
-endif
-CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
-ifeq ($(ARCH),arm64)
-CFLAGS_REMOVE_recov_neon_inner.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon2.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon4.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon8.o += -mgeneral-regs-only
-endif
-endif
-
quiet_cmd_unroll = UNROLL $@
cmd_unroll = $(AWK) -v N=$* -f $(srctree)/$(src)/unroll.awk < $< > $@
@@ -75,10 +56,16 @@ targets += vpermxor1.c vpermxor2.c vpermxor4.c vpermxor8.c
$(obj)/vpermxor%.c: $(src)/vpermxor.uc $(src)/unroll.awk FORCE
$(call if_changed,unroll)
-CFLAGS_neon1.o += $(NEON_FLAGS)
-CFLAGS_neon2.o += $(NEON_FLAGS)
-CFLAGS_neon4.o += $(NEON_FLAGS)
-CFLAGS_neon8.o += $(NEON_FLAGS)
+CFLAGS_neon1.o += $(CC_FLAGS_FPU)
+CFLAGS_neon2.o += $(CC_FLAGS_FPU)
+CFLAGS_neon4.o += $(CC_FLAGS_FPU)
+CFLAGS_neon8.o += $(CC_FLAGS_FPU)
+CFLAGS_recov_neon_inner.o += $(CC_FLAGS_FPU)
+CFLAGS_REMOVE_neon1.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_recov_neon_inner.o += $(CC_FLAGS_NO_FPU)
targets += neon1.c neon2.c neon4.c neon8.c
$(obj)/neon%.c: $(src)/neon.uc $(src)/unroll.awk FORCE
$(call if_changed,unroll)
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 00/15] Unified cross-architecture kernel-mode FPU API
From: Samuel Holland @ 2024-03-29 7:18 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
Borislav Petkov, Catalin Marinas, Dave Hansen, Huacai Chen,
Ingo Molnar, Jonathan Corbet, Masahiro Yamada, Nathan Chancellor,
Nicolas Schier, Russell King, Thomas Gleixner, Will Deacon,
linux-doc, linux-kbuild
This series unifies the kernel-mode FPU API across several architectures
by wrapping the existing functions (where needed) in consistently-named
functions placed in a consistent header location, with mostly the same
semantics: they can be called from preemptible or non-preemptible task
context, and are not assumed to be reentrant. Architectures are also
expected to provide CFLAGS adjustments for compiling FPU-dependent code.
For the moment, SIMD/vector units are out of scope for this common API.
This allows us to remove the ifdeffery and duplicated Makefile logic at
each FPU user. It then implements the common API on RISC-V, and converts
a couple of users to the new API: the AMDGPU DRM driver, and the FPU
self test.
The underlying goal of this series is to allow using newer AMD GPUs
(e.g. Navi) on RISC-V boards such as SiFive's HiFive Unmatched. Those
GPUs need CONFIG_DRM_AMD_DC_FP to initialize, which requires kernel-mode
FPU support.
Previous versions:
v3: https://lore.kernel.org/linux-kernel/20240327200157.1097089-1-samuel.holland@sifive.com/
v2: https://lore.kernel.org/linux-kernel/20231228014220.3562640-1-samuel.holland@sifive.com/
v1: https://lore.kernel.org/linux-kernel/20231208055501.2916202-1-samuel.holland@sifive.com/
v0: https://lore.kernel.org/linux-kernel/20231122030621.3759313-1-samuel.holland@sifive.com/
Changes in v4:
- Add missed CFLAGS changes for recov_neon_inner.c
(fixes arm build failures)
- Fix x86 include guard issue (fixes x86 build failures)
Changes in v3:
- Rebase on v6.9-rc1
- Limit riscv ARCH_HAS_KERNEL_FPU_SUPPORT to 64BIT
Changes in v2:
- Add documentation explaining the built-time and runtime APIs
- Add a linux/fpu.h header for generic isolation enforcement
- Remove file name from header comment
- Clean up arch/arm64/lib/Makefile, like for arch/arm
- Remove RISC-V architecture-specific preprocessor check
- Split altivec removal to a separate patch
- Use linux/fpu.h instead of asm/fpu.h in consumers
- Declare test_fpu() in a header
Michael Ellerman (1):
drm/amd/display: Only use hard-float, not altivec on powerpc
Samuel Holland (14):
arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
ARM: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
arm64: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
powerpc: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
x86/fpu: Fix asm/fpu/types.h include guard
x86: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
riscv: Add support for kernel-mode FPU
drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
selftests/fpu: Move FP code to a separate translation unit
selftests/fpu: Allow building on other architectures
Documentation/core-api/floating-point.rst | 78 +++++++++++++++++++
Documentation/core-api/index.rst | 1 +
Makefile | 5 ++
arch/Kconfig | 6 ++
arch/arm/Kconfig | 1 +
arch/arm/Makefile | 7 ++
arch/arm/include/asm/fpu.h | 15 ++++
arch/arm/lib/Makefile | 3 +-
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile | 9 ++-
arch/arm64/include/asm/fpu.h | 15 ++++
arch/arm64/lib/Makefile | 6 +-
arch/loongarch/Kconfig | 1 +
arch/loongarch/Makefile | 5 +-
arch/loongarch/include/asm/fpu.h | 1 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 5 +-
arch/powerpc/include/asm/fpu.h | 28 +++++++
arch/riscv/Kconfig | 1 +
arch/riscv/Makefile | 3 +
arch/riscv/include/asm/fpu.h | 16 ++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/kernel_mode_fpu.c | 28 +++++++
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 20 +++++
arch/x86/include/asm/fpu.h | 13 ++++
arch/x86/include/asm/fpu/types.h | 6 +-
drivers/gpu/drm/amd/display/Kconfig | 2 +-
.../gpu/drm/amd/display/amdgpu_dm/dc_fpu.c | 35 +--------
drivers/gpu/drm/amd/display/dc/dml/Makefile | 36 +--------
drivers/gpu/drm/amd/display/dc/dml2/Makefile | 36 +--------
include/linux/fpu.h | 12 +++
lib/Kconfig.debug | 2 +-
lib/Makefile | 26 +------
lib/raid6/Makefile | 33 +++-----
lib/test_fpu.h | 8 ++
lib/{test_fpu.c => test_fpu_glue.c} | 37 ++-------
lib/test_fpu_impl.c | 37 +++++++++
38 files changed, 348 insertions(+), 193 deletions(-)
create mode 100644 Documentation/core-api/floating-point.rst
create mode 100644 arch/arm/include/asm/fpu.h
create mode 100644 arch/arm64/include/asm/fpu.h
create mode 100644 arch/powerpc/include/asm/fpu.h
create mode 100644 arch/riscv/include/asm/fpu.h
create mode 100644 arch/riscv/kernel/kernel_mode_fpu.c
create mode 100644 arch/x86/include/asm/fpu.h
create mode 100644 include/linux/fpu.h
create mode 100644 lib/test_fpu.h
rename lib/{test_fpu.c => test_fpu_glue.c} (71%)
create mode 100644 lib/test_fpu_impl.c
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 07/15] LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
From: Samuel Holland @ 2024-03-29 7:18 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
WANG Xuerui, Huacai Chen
In-Reply-To: <20240329072441.591471-1-samuel.holland@sifive.com>
LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
asm/fpu.h, so it only needs to add kernel_fpu_available() and export
the CFLAGS adjustments.
Acked-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
(no changes since v3)
Changes in v3:
- Rebase on v6.9-rc1
arch/loongarch/Kconfig | 1 +
arch/loongarch/Makefile | 5 ++++-
arch/loongarch/include/asm/fpu.h | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index a5f300ec6f28..2266c6c41c38 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -18,6 +18,7 @@ config LOONGARCH
select ARCH_HAS_CURRENT_STACK_POINTER
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KCOV
+ select ARCH_HAS_KERNEL_FPU_SUPPORT if CPU_HAS_FPU
select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
select ARCH_HAS_PTE_SPECIAL
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index df6caf79537a..efb5440a43ec 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -26,6 +26,9 @@ endif
32bit-emul = elf32loongarch
64bit-emul = elf64loongarch
+CC_FLAGS_FPU := -mfpu=64
+CC_FLAGS_NO_FPU := -msoft-float
+
ifdef CONFIG_UNWINDER_ORC
orc_hash_h := arch/$(SRCARCH)/include/generated/asm/orc_hash.h
orc_hash_sh := $(srctree)/scripts/orc_hash.sh
@@ -59,7 +62,7 @@ ld-emul = $(64bit-emul)
cflags-y += -mabi=lp64s
endif
-cflags-y += -pipe -msoft-float
+cflags-y += -pipe $(CC_FLAGS_NO_FPU)
LDFLAGS_vmlinux += -static -n -nostdlib
# When the assembler supports explicit relocation hint, we must use it.
diff --git a/arch/loongarch/include/asm/fpu.h b/arch/loongarch/include/asm/fpu.h
index c2d8962fda00..3177674228f8 100644
--- a/arch/loongarch/include/asm/fpu.h
+++ b/arch/loongarch/include/asm/fpu.h
@@ -21,6 +21,7 @@
struct sigcontext;
+#define kernel_fpu_available() cpu_has_fpu
extern void kernel_fpu_begin(void);
extern void kernel_fpu_end(void);
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 14/15] selftests/fpu: Move FP code to a separate translation unit
From: Samuel Holland @ 2024-03-29 7:18 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland
In-Reply-To: <20240329072441.591471-1-samuel.holland@sifive.com>
This ensures no compiler-generated floating-point code can appear
outside kernel_fpu_{begin,end}() sections, and some architectures
enforce this separation.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
(no changes since v2)
Changes in v2:
- Declare test_fpu() in a header
lib/Makefile | 3 ++-
lib/test_fpu.h | 8 +++++++
lib/{test_fpu.c => test_fpu_glue.c} | 32 +------------------------
lib/test_fpu_impl.c | 37 +++++++++++++++++++++++++++++
4 files changed, 48 insertions(+), 32 deletions(-)
create mode 100644 lib/test_fpu.h
rename lib/{test_fpu.c => test_fpu_glue.c} (71%)
create mode 100644 lib/test_fpu_impl.c
diff --git a/lib/Makefile b/lib/Makefile
index ffc6b2341b45..fcb35bf50979 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -133,7 +133,8 @@ FPU_CFLAGS += $(call cc-option,-msse -mpreferred-stack-boundary=3,-mpreferred-st
endif
obj-$(CONFIG_TEST_FPU) += test_fpu.o
-CFLAGS_test_fpu.o += $(FPU_CFLAGS)
+test_fpu-y := test_fpu_glue.o test_fpu_impl.o
+CFLAGS_test_fpu_impl.o += $(FPU_CFLAGS)
# Some KUnit files (hooks.o) need to be built-in even when KUnit is a module,
# so we can't just use obj-$(CONFIG_KUNIT).
diff --git a/lib/test_fpu.h b/lib/test_fpu.h
new file mode 100644
index 000000000000..4459807084bc
--- /dev/null
+++ b/lib/test_fpu.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef _LIB_TEST_FPU_H
+#define _LIB_TEST_FPU_H
+
+int test_fpu(void);
+
+#endif
diff --git a/lib/test_fpu.c b/lib/test_fpu_glue.c
similarity index 71%
rename from lib/test_fpu.c
rename to lib/test_fpu_glue.c
index e82db19fed84..85963d7be826 100644
--- a/lib/test_fpu.c
+++ b/lib/test_fpu_glue.c
@@ -19,37 +19,7 @@
#include <linux/debugfs.h>
#include <asm/fpu/api.h>
-static int test_fpu(void)
-{
- /*
- * This sequence of operations tests that rounding mode is
- * to nearest and that denormal numbers are supported.
- * Volatile variables are used to avoid compiler optimizing
- * the calculations away.
- */
- volatile double a, b, c, d, e, f, g;
-
- a = 4.0;
- b = 1e-15;
- c = 1e-310;
-
- /* Sets precision flag */
- d = a + b;
-
- /* Result depends on rounding mode */
- e = a + b / 2;
-
- /* Denormal and very large values */
- f = b / c;
-
- /* Depends on denormal support */
- g = a + c * f;
-
- if (d > a && e > a && g > a)
- return 0;
- else
- return -EINVAL;
-}
+#include "test_fpu.h"
static int test_fpu_get(void *data, u64 *val)
{
diff --git a/lib/test_fpu_impl.c b/lib/test_fpu_impl.c
new file mode 100644
index 000000000000..777894dbbe86
--- /dev/null
+++ b/lib/test_fpu_impl.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/errno.h>
+
+#include "test_fpu.h"
+
+int test_fpu(void)
+{
+ /*
+ * This sequence of operations tests that rounding mode is
+ * to nearest and that denormal numbers are supported.
+ * Volatile variables are used to avoid compiler optimizing
+ * the calculations away.
+ */
+ volatile double a, b, c, d, e, f, g;
+
+ a = 4.0;
+ b = 1e-15;
+ c = 1e-310;
+
+ /* Sets precision flag */
+ d = a + b;
+
+ /* Result depends on rounding mode */
+ e = a + b / 2;
+
+ /* Denormal and very large values */
+ f = b / c;
+
+ /* Depends on denormal support */
+ g = a + c * f;
+
+ if (d > a && e > a && g > a)
+ return 0;
+ else
+ return -EINVAL;
+}
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 1/4] remoteproc: Add TEE support
From: Arnaud POULIQUEN @ 2024-03-29 8:58 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, Jens Wiklander, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-stm32, linux-arm-kernel, linux-remoteproc,
linux-kernel, op-tee, devicetree
In-Reply-To: <ZgRSS76mtc4JBAJP@p14s>
Hello Mathieu,
On 3/27/24 18:07, Mathieu Poirier wrote:
> On Tue, Mar 26, 2024 at 08:18:23PM +0100, Arnaud POULIQUEN wrote:
>> Hello Mathieu,
>>
>> On 3/25/24 17:46, Mathieu Poirier wrote:
>>> On Fri, Mar 08, 2024 at 03:47:05PM +0100, Arnaud Pouliquen wrote:
>>>> Add a remoteproc TEE (Trusted Execution Environment) driver
>>>> that will be probed by the TEE bus. If the associated Trusted
>>>> application is supported on secure part this device offers a client
>>>
>>> Device or driver? I thought I touched on that before.
>>
>> Right, I changed the first instance and missed this one
>>
>>>
>>>> interface to load a firmware in the secure part.
>>>> This firmware could be authenticated by the secure trusted application.
>>>>
>>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>>>> ---
>>>> Updates from V3:
>>>> - rework TEE_REMOTEPROC description in Kconfig
>>>> - fix some namings
>>>> - add tee_rproc_parse_fw to support rproc_ops::parse_fw
>>>> - add proc::tee_interface;
>>>> - add rproc struct as parameter of the tee_rproc_register() function
>>>> ---
>>>> drivers/remoteproc/Kconfig | 10 +
>>>> drivers/remoteproc/Makefile | 1 +
>>>> drivers/remoteproc/tee_remoteproc.c | 434 ++++++++++++++++++++++++++++
>>>> include/linux/remoteproc.h | 4 +
>>>> include/linux/tee_remoteproc.h | 112 +++++++
>>>> 5 files changed, 561 insertions(+)
>>>> create mode 100644 drivers/remoteproc/tee_remoteproc.c
>>>> create mode 100644 include/linux/tee_remoteproc.h
>>>>
>>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>>>> index 48845dc8fa85..2cf1431b2b59 100644
>>>> --- a/drivers/remoteproc/Kconfig
>>>> +++ b/drivers/remoteproc/Kconfig
>>>> @@ -365,6 +365,16 @@ config XLNX_R5_REMOTEPROC
>>>>
>>>> It's safe to say N if not interested in using RPU r5f cores.
>>>>
>>>> +
>>>> +config TEE_REMOTEPROC
>>>> + tristate "remoteproc support by a TEE application"
>>>
>>> s/remoteproc/Remoteproc
>>>
>>>> + depends on OPTEE
>>>> + help
>>>> + Support a remote processor with a TEE application. The Trusted
>>>> + Execution Context is responsible for loading the trusted firmware
>>>> + image and managing the remote processor's lifecycle.
>>>> + This can be either built-in or a loadable module.
>>>> +
>>>> endif # REMOTEPROC
>>>>
>>>> endmenu
>>>> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
>>>> index 91314a9b43ce..fa8daebce277 100644
>>>> --- a/drivers/remoteproc/Makefile
>>>> +++ b/drivers/remoteproc/Makefile
>>>> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC) += rcar_rproc.o
>>>> obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
>>>> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>>>> obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
>>>> +obj-$(CONFIG_TEE_REMOTEPROC) += tee_remoteproc.o
>>>> obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
>>>> obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
>>>> obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
>>>> diff --git a/drivers/remoteproc/tee_remoteproc.c b/drivers/remoteproc/tee_remoteproc.c
>>>> new file mode 100644
>>>> index 000000000000..c855210e52e3
>>>> --- /dev/null
>>>> +++ b/drivers/remoteproc/tee_remoteproc.c
>>>> @@ -0,0 +1,434 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>>> +/*
>>>> + * Copyright (C) STMicroelectronics 2024 - All Rights Reserved
>>>> + * Author: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>>>> + */
>>>> +
>>>> +#include <linux/firmware.h>
>>>> +#include <linux/io.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/remoteproc.h>
>>>> +#include <linux/slab.h>
>>>> +#include <linux/tee_drv.h>
>>>> +#include <linux/tee_remoteproc.h>
>>>> +
>>>> +#include "remoteproc_internal.h"
>>>> +
>>>> +#define MAX_TEE_PARAM_ARRY_MEMBER 4
>>>> +
>>>> +/*
>>>> + * Authentication of the firmware and load in the remote processor memory
>>>> + *
>>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
>>>> + * [in] params[1].memref: buffer containing the image of the buffer
>>>> + */
>>>> +#define TA_RPROC_FW_CMD_LOAD_FW 1
>>>> +
>>>> +/*
>>>> + * Start the remote processor
>>>> + *
>>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
>>>> + */
>>>> +#define TA_RPROC_FW_CMD_START_FW 2
>>>> +
>>>> +/*
>>>> + * Stop the remote processor
>>>> + *
>>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
>>>> + */
>>>> +#define TA_RPROC_FW_CMD_STOP_FW 3
>>>> +
>>>> +/*
>>>> + * Return the address of the resource table, or 0 if not found
>>>> + * No check is done to verify that the address returned is accessible by
>>>> + * the non secure context. If the resource table is loaded in a protected
>>>> + * memory the access by the non secure context will lead to a data abort.
>>>> + *
>>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
>>>> + * [out] params[1].value.a: 32bit LSB resource table memory address
>>>> + * [out] params[1].value.b: 32bit MSB resource table memory address
>>>> + * [out] params[2].value.a: 32bit LSB resource table memory size
>>>> + * [out] params[2].value.b: 32bit MSB resource table memory size
>>>> + */
>>>> +#define TA_RPROC_FW_CMD_GET_RSC_TABLE 4
>>>> +
>>>> +/*
>>>> + * Return the address of the core dump
>>>> + *
>>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
>>>> + * [out] params[1].memref: address of the core dump image if exist,
>>>> + * else return Null
>>>> + */
>>>> +#define TA_RPROC_FW_CMD_GET_COREDUMP 5
>>>> +
>>>> +struct tee_rproc_context {
>>>> + struct list_head sessions;
>>>> + struct tee_context *tee_ctx;
>>>> + struct device *dev;
>>>> +};
>>>> +
>>>> +static struct tee_rproc_context *tee_rproc_ctx;
>>>> +
>>>> +static void tee_rproc_prepare_args(struct tee_rproc *trproc, int cmd,
>>>> + struct tee_ioctl_invoke_arg *arg,
>>>> + struct tee_param *param,
>>>> + unsigned int num_params)
>>>> +{
>>>> + memset(arg, 0, sizeof(*arg));
>>>> + memset(param, 0, MAX_TEE_PARAM_ARRY_MEMBER * sizeof(*param));
>>>> +
>>>> + arg->func = cmd;
>>>> + arg->session = trproc->session_id;
>>>> + arg->num_params = num_params + 1;
>>>> +
>>>> + param[0] = (struct tee_param) {
>>>> + .attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
>>>> + .u.value.a = trproc->rproc_id,
>>>> + };
>>>> +}
>>>> +
>>>> +int tee_rproc_load_fw(struct rproc *rproc, const struct firmware *fw)
>>>> +{
>>>> + struct tee_ioctl_invoke_arg arg;
>>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
>>>> + struct tee_rproc *trproc = rproc->tee_interface;
>>>> + struct tee_shm *fw_shm;
>>>> + int ret;
>>>
>>> Declarations in reverse ascending order here and everywhere in the driver.
>>> Sometimes it is done properly, sometimes it isn't.
>>>
>>>> +
>>>> + if (!trproc)
>>>> + return -EINVAL;
>>>> +
>>>> + fw_shm = tee_shm_register_kernel_buf(tee_rproc_ctx->tee_ctx, (void *)fw->data, fw->size);
>>>> + if (IS_ERR(fw_shm))
>>>> + return PTR_ERR(fw_shm);
>>>> +
>>>> + tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_LOAD_FW, &arg, param, 1);
>>>> +
>>>> + /* Provide the address of the firmware image */
>>>> + param[1] = (struct tee_param) {
>>>> + .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
>>>> + .u.memref = {
>>>> + .shm = fw_shm,
>>>> + .size = fw->size,
>>>> + .shm_offs = 0,
>>>> + },
>>>> + };
>>>> +
>>>> + ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
>>>> + if (ret < 0 || arg.ret != 0) {
>>>> + dev_err(tee_rproc_ctx->dev,
>>>> + "TA_RPROC_FW_CMD_LOAD_FW invoke failed TEE err: %x, ret:%x\n",
>>>> + arg.ret, ret);
>>>> + if (!ret)
>>>> + ret = -EIO;
>>>> + }
>>>> +
>>>> + tee_shm_free(fw_shm);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(tee_rproc_load_fw);
>>>> +
>>>> +struct resource_table *tee_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
>>>> +{
>>>> + struct tee_ioctl_invoke_arg arg;
>>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
>>>> + struct tee_rproc *trproc = rproc->tee_interface;
>>>> + struct resource_table *rsc_table;
>>>> + int ret;
>>>> +
>>>> + if (!trproc)
>>>> + return ERR_PTR(-EINVAL);
>>>> +
>>>> + tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_GET_RSC_TABLE, &arg, param, 2);
>>>> +
>>>> + param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
>>>> + param[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
>>>> +
>>>> + ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
>>>> + if (ret < 0 || arg.ret != 0) {
>>>> + dev_err(tee_rproc_ctx->dev,
>>>> + "TA_RPROC_FW_CMD_GET_RSC_TABLE invoke failed TEE err: %x, ret:%x\n",
>>>> + arg.ret, ret);
>>>> + return ERR_PTR(-EIO);
>>>> + }
>>>> +
>>>> + *table_sz = param[2].u.value.a;
>>>> +
>>>> + /* If the size is null no resource table defined in the image */
>>>> + if (!*table_sz)
>>>> + return NULL;
>>>> +
>>>> + /* Store the resource table address that would be updated by the remote core. */
>>>> + rsc_table = ioremap_wc(param[1].u.value.a, *table_sz);
>>>> + if (IS_ERR_OR_NULL(rsc_table)) {
>>>> + dev_err(tee_rproc_ctx->dev, "Unable to map memory region: %lld+%zx\n",
>>>> + param[1].u.value.a, *table_sz);
>>>> + return ERR_PTR(-ENOMEM);
>>>> + }
>>>> +
>>>> + return rsc_table;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(tee_rproc_get_loaded_rsc_table);
>>>> +
>>>> +int tee_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
>>>> +{
>>>> + struct tee_rproc *trproc = rproc->tee_interface;
>>>> + struct resource_table *rsc_table;
>>>> + size_t table_sz;
>>>> + int ret;
>>>> +
>>>> + ret = tee_rproc_load_fw(rproc, fw);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + rsc_table = tee_rproc_get_loaded_rsc_table(rproc, &table_sz);
>>>> + if (IS_ERR(rsc_table))
>>>> + return PTR_ERR(rsc_table);
>>>> +
>>>> + /* Create a copy of the resource table to have same behaviour than the elf loader. */
>>>> + rproc->cached_table = kmemdup(rsc_table, table_sz, GFP_KERNEL);
>>>> + if (!rproc->cached_table)
>>>> + return -ENOMEM;
>>>
>>> Why not ->table_ptr and setting ->cached_table to NULL?
>>
>> It was my plan preparing this version. But during implementarion it looks
>> to me that having exactly same behavior than the ELF loader would be
>> simpler to maintain the remoteproc avoiding to update in the remoteproc core
>> to manage for the cached resource table (see also my comment below abourt recovery)
>> That why I propose this implementation
>>
>> That said what you proposal should also work (with some updates in
>> remoteproc_core for the management of the cached table).
>>
>
> Yes
>
>> So please just comfirm your preference.
>>
>
> Definitely keep ->cached_table to NULL.
>
>>>
>>>> +
>>>> + rproc->table_ptr = rproc->cached_table;
>>>> + rproc->table_sz = table_sz;
>>>> + trproc->rsc_table = rsc_table;
>>>
>>> I really don't see why this is needed, please remove and use rproc->table_ptr
>>> instead.
>>
>> I need to store it for the iounmap in tee_rproc_remove.
>
> iounmap(entry->rproc->rsc_table);
>
> What am I missing?
rproc->rsc_table is a field that can be updated by remoteproc_core.
How can we garanty in tee_remoteproc that it still points to the mapped resource
table?
As the remoteproc_tee maps the pointer, it seems reliable that it stores it for
unmap.
Seems also that I also missed to handle the case where rproc_fw_boot() fails[3]
(not done yet).
[3]https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_core.c#L1442
>
>>
>>>
>>>> +
>>>> + return 0;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(tee_rproc_parse_fw);
>>>> +
>>>> +struct resource_table *tee_rproc_find_loaded_rsc_table(struct rproc *rproc,
>>>> + const struct firmware *fw)
>>>> +{
>>>> + struct tee_rproc *trproc = rproc->tee_interface;
>>>> + struct resource_table *rsc_table;
>>>> + size_t table_sz;
>>>> +
>>>> + if (!trproc)
>>>> + return ERR_PTR(-EINVAL);
>>>> +
>>>> + /* Check if the resourse table has already been obtained in tee_rproc_parse_fw() */
>>>> + if (trproc->rsc_table)
>>>> + return trproc->rsc_table;
>>>
>>> Again, why not simply use rproc->rsc_table? This function should only return
>>> the resource table that was set in tee_rproc_parse_fw().
>>
>> In case of recovery rproc->_rsc_table point to the cached table [1]
>
> In [1], on line 1554, add a check for rproc->tee_interface and if it is valid
> call rproc_find_loaded_rsc_table().
>
>> and we need to reapply the configuration in rproc_start() called during the
>> recovery[2]
>
> 1) Rename rproc_set_rsc_table() to rproc_set_rsc_table_on_attach()
> 2) Introduce a new function called rproc_set_rsc_table_on_start()
> 3) Move code from [2], line 1278 to 1292, to that new function. In the new
> function, add a check on rproc->tee_interface. If it is valid then call
> rproc_find_loaded_rsc_table().
> 4) in rproc_start(), replace lines 1278 to 1292 with a call to
> rproc_set_rsc_table_on_start().
I will try this
Thanks!
Arnaud
>
>> [1]https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_core.c#L1586
>> [2]https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_core.c#L1287
>>
>>>
>>>> +
>>>> + rsc_table = tee_rproc_get_loaded_rsc_table(rproc, &table_sz);
>>>> + if (IS_ERR(rsc_table))
>>>> + return rsc_table;
>>>> +
>>>> + rproc->table_sz = table_sz;
>>>> + trproc->rsc_table = rsc_table;
>>>> +
>>>> + return rsc_table;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(tee_rproc_find_loaded_rsc_table);
>>>> +
>>>> +int tee_rproc_start(struct rproc *rproc)
>>>> +{
>>>> + struct tee_ioctl_invoke_arg arg;
>>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
>>>> + struct tee_rproc *trproc = rproc->tee_interface;
>>>> + int ret;
>>>> +
>>>> + if (!trproc)
>>>> + return -EINVAL;
>>>> +
>>>> + tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_START_FW, &arg, param, 0);
>>>> +
>>>> + ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
>>>> + if (ret < 0 || arg.ret != 0) {
>>>> + dev_err(tee_rproc_ctx->dev,
>>>> + "TA_RPROC_FW_CMD_START_FW invoke failed TEE err: %x, ret:%x\n",
>>>> + arg.ret, ret);
>>>> + if (!ret)
>>>> + ret = -EIO;
>>>> + }
>>>> +
>>>> + return ret;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(tee_rproc_start);
>>>> +
>>>> +int tee_rproc_stop(struct rproc *rproc)
>>>> +{
>>>> + struct tee_ioctl_invoke_arg arg;
>>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
>>>> + struct tee_rproc *trproc = rproc->tee_interface;
>>>> + int ret;
>>>> +
>>>> + if (!trproc)
>>>> + return -EINVAL;
>>>> +
>>>> + tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_STOP_FW, &arg, param, 0);
>>>> +
>>>> + ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
>>>> + if (ret < 0 || arg.ret != 0) {
>>>> + dev_err(tee_rproc_ctx->dev,
>>>> + "TA_RPROC_FW_CMD_STOP_FW invoke failed TEE err: %x, ret:%x\n",
>>>> + arg.ret, ret);
>>>> + if (!ret)
>>>> + ret = -EIO;
>>>> + }
>>>> +
>>>> + if (!rproc->table_ptr)
>>>> + return ret;
>>>> +
>>>> + iounmap(trproc->rsc_table);
>>>> + trproc->rsc_table = NULL;
>>>> + rproc->table_ptr = NULL;
>>>> +
>>>> + return 0;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(tee_rproc_stop);
>>>> +
>>>> +static const struct tee_client_device_id stm32_tee_rproc_id_table[] = {
>>>> + {UUID_INIT(0x80a4c275, 0x0a47, 0x4905,
>>>> + 0x82, 0x85, 0x14, 0x86, 0xa9, 0x77, 0x1a, 0x08)},
>>>> + {}
>>>> +};
>>>> +
>>>> +struct tee_rproc *tee_rproc_register(struct device *dev, struct rproc *rproc, unsigned int rproc_id)
>>>> +{
>>>> + struct tee_client_device *tee_device;
>>>> + struct tee_ioctl_open_session_arg sess_arg;
>>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
>>>> + struct tee_rproc *trproc;
>>>> + int ret;
>>>> +
>>>> + /*
>>>> + * Test if the device has been probed by the TEE bus. In case of failure, we ignore the
>>>> + * reason. The bus could be not yet probed or the service not available in the secure
>>>> + * firmware.The assumption in such a case is that the TEE remoteproc is not probed.
>>>> + */
>>>> + if (!tee_rproc_ctx)
>>>> + return ERR_PTR(-EPROBE_DEFER);
>>>> +
>>>> + trproc = devm_kzalloc(dev, sizeof(*trproc), GFP_KERNEL);
>>>> + if (!trproc)
>>>> + return ERR_PTR(-ENOMEM);
>>>> +
>>>> + tee_device = to_tee_client_device(tee_rproc_ctx->dev);
>>>> + memset(&sess_arg, 0, sizeof(sess_arg));
>>>> +
>>>> + memcpy(sess_arg.uuid, tee_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
>>>> +
>>>> + sess_arg.clnt_login = TEE_IOCTL_LOGIN_REE_KERNEL;
>>>> + sess_arg.num_params = 1;
>>>> +
>>>> + param[0] = (struct tee_param) {
>>>> + .attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
>>>> + .u.value.a = rproc_id,
>>>> + };
>>>> +
>>>> + ret = tee_client_open_session(tee_rproc_ctx->tee_ctx, &sess_arg, param);
>>>> + if (ret < 0 || sess_arg.ret != 0) {
>>>> + dev_err(dev, "tee_client_open_session failed, err: %x\n", sess_arg.ret);
>>>> + return ERR_PTR(-EINVAL);
>>>> + }
>>>> +
>>>> + trproc->parent = dev;
>>>> + trproc->rproc_id = rproc_id;
>>>> + trproc->session_id = sess_arg.session;
>>>> +
>>>> + trproc->rproc = rproc;
>>>> + rproc->tee_interface = trproc;
>>>> +
>>>> + list_add_tail(&trproc->node, &tee_rproc_ctx->sessions);
>>>> +
>>>> + return trproc;
>>>
>>> Once this function was called by a client, what prevents a user from unloading
>>> the tee_remoteproc module and breaking everything?
>>
>> Good point! seems better toremove the module build capability
>>
>
> I was thinking more along the lines of try_module_get() and module_put() to
> avoid bloating the core.
>
>> Thanks,
>> Arnaud
>>
>>>
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(tee_rproc_register);
>>>> +
>>>> +int tee_rproc_unregister(struct tee_rproc *trproc)
>>>> +{
>>>
>>> If you pass a struct_rproc instead of a struct tee_rproc there is no need for
>>> tee_rproc::rproc, which is only ever used in this function.
>>>
>>>
>>>> + struct rproc *rproc = trproc->rproc;
>>>> + int ret;
>>>> +
>>>> + ret = tee_client_close_session(tee_rproc_ctx->tee_ctx, trproc->session_id);
>>>> + if (ret < 0)
>>>> + dev_err(trproc->parent, "tee_client_close_session failed, err: %x\n", ret);
>>>> +
>>>> + list_del(&trproc->node);
>>>> + rproc->tee_interface = NULL;
>>>> +
>>>> + return ret;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(tee_rproc_unregister);
>>>> +
>>>> +static int tee_rproc_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
>>>> +{
>>>> + /* Today we support only the OP-TEE, could be extend to other tees */
>>>> + return (ver->impl_id == TEE_IMPL_ID_OPTEE);
>>>> +}
>>>> +
>>>> +static int tee_rproc_probe(struct device *dev)
>>>> +{
>>>> + struct tee_context *tee_ctx;
>>>> + int ret;
>>>> +
>>>> + /* Open context with TEE driver */
>>>> + tee_ctx = tee_client_open_context(NULL, tee_rproc_ctx_match, NULL, NULL);
>>>> + if (IS_ERR(tee_ctx))
>>>> + return PTR_ERR(tee_ctx);
>>>> +
>>>> + tee_rproc_ctx = devm_kzalloc(dev, sizeof(*tee_ctx), GFP_KERNEL);
>>>> + if (!tee_rproc_ctx) {
>>>> + ret = -ENOMEM;
>>>> + goto err;
>>>> + }
>>>> +
>>>> + tee_rproc_ctx->dev = dev;
>>>> + tee_rproc_ctx->tee_ctx = tee_ctx;
>>>> + INIT_LIST_HEAD(&tee_rproc_ctx->sessions);
>>>> +
>>>> + return 0;
>>>> +err:
>>>> + tee_client_close_context(tee_ctx);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int tee_rproc_remove(struct device *dev)
>>>> +{
>>>> + struct tee_rproc *entry, *tmp;
>>>> +
>>>> + list_for_each_entry_safe(entry, tmp, &tee_rproc_ctx->sessions, node) {
>>>> + tee_client_close_session(tee_rproc_ctx->tee_ctx, entry->session_id);
>>>> + list_del(&entry->node);
>>>> + if (entry->rsc_table)
>>>> + iounmap(entry->rsc_table);
>>>> + kfree(entry);
>>>> + }
>>>> +
>>>> + tee_client_close_context(tee_rproc_ctx->tee_ctx);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +MODULE_DEVICE_TABLE(tee, stm32_tee_rproc_id_table);
>>>> +
>>>> +static struct tee_client_driver tee_rproc_fw_driver = {
>>>> + .id_table = stm32_tee_rproc_id_table,
>>>> + .driver = {
>>>> + .name = KBUILD_MODNAME,
>>>> + .bus = &tee_bus_type,
>>>> + .probe = tee_rproc_probe,
>>>> + .remove = tee_rproc_remove,
>>>> + },
>>>> +};
>>>> +
>>>> +static int __init tee_rproc_fw_mod_init(void)
>>>> +{
>>>> + return driver_register(&tee_rproc_fw_driver.driver);
>>>> +}
>>>> +
>>>> +static void __exit tee_rproc_fw_mod_exit(void)
>>>> +{
>>>> + driver_unregister(&tee_rproc_fw_driver.driver);
>>>> +}
>>>> +
>>>> +module_init(tee_rproc_fw_mod_init);
>>>> +module_exit(tee_rproc_fw_mod_exit);
>>>> +
>>>> +MODULE_DESCRIPTION(" TEE remote processor control driver");
>>>> +MODULE_LICENSE("GPL");
>>>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>>>> index b4795698d8c2..8b678009e481 100644
>>>> --- a/include/linux/remoteproc.h
>>>> +++ b/include/linux/remoteproc.h
>>>> @@ -503,6 +503,8 @@ enum rproc_features {
>>>> RPROC_MAX_FEATURES,
>>>> };
>>>>
>>>> +struct tee_rproc;
>>>> +
>>>> /**
>>>> * struct rproc - represents a physical remote processor device
>>>> * @node: list node of this rproc object
>>>> @@ -545,6 +547,7 @@ enum rproc_features {
>>>> * @cdev: character device of the rproc
>>>> * @cdev_put_on_release: flag to indicate if remoteproc should be shutdown on @char_dev release
>>>> * @features: indicate remoteproc features
>>>> + * @tee_interface: pointer to the remoteproc tee context
>>>> */
>>>> struct rproc {
>>>> struct list_head node;
>>>> @@ -586,6 +589,7 @@ struct rproc {
>>>> struct cdev cdev;
>>>> bool cdev_put_on_release;
>>>> DECLARE_BITMAP(features, RPROC_MAX_FEATURES);
>>>> + struct tee_rproc *tee_interface;
>>>> };
>>>>
>>>> /**
>>>> diff --git a/include/linux/tee_remoteproc.h b/include/linux/tee_remoteproc.h
>>>> new file mode 100644
>>>> index 000000000000..571e47190d02
>>>> --- /dev/null
>>>> +++ b/include/linux/tee_remoteproc.h
>>>> @@ -0,0 +1,112 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>>> +/*
>>>> + * Copyright(c) 2024 STMicroelectronics - All Rights Reserved
>>>> + */
>>>> +
>>>> +#ifndef TEE_REMOTEPROC_H
>>>> +#define TEE_REMOTEPROC_H
>>>> +
>>>> +#include <linux/tee_drv.h>
>>>> +#include <linux/firmware.h>
>>>> +#include <linux/remoteproc.h>
>>>> +
>>>> +struct rproc;
>>>> +
>>>> +/**
>>>> + * struct tee_rproc - TEE remoteproc structure
>>>> + * @node: Reference in list
>>>> + * @rproc: Remoteproc reference
>>>> + * @parent: Parent device
>>>> + * @rproc_id: Identifier of the target firmware
>>>> + * @session_id: TEE session identifier
>>>> + * @rsc_table: Resource table virtual address.
>>>> + */
>>>> +struct tee_rproc {
>>>> + struct list_head node;
>>>> + struct rproc *rproc;
>>>> + struct device *parent;
>>>> + u32 rproc_id;
>>>> + u32 session_id;
>>>> + struct resource_table *rsc_table;
>>>> +};
>>>> +
>>>> +#if IS_REACHABLE(CONFIG_TEE_REMOTEPROC)
>>>> +
>>>> +struct tee_rproc *tee_rproc_register(struct device *dev, struct rproc *rproc,
>>>> + unsigned int rproc_id);
>>>> +int tee_rproc_unregister(struct tee_rproc *trproc);
>>>> +int tee_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw);
>>>> +int tee_rproc_load_fw(struct rproc *rproc, const struct firmware *fw);
>>>> +struct resource_table *tee_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz);
>>>> +struct resource_table *tee_rproc_find_loaded_rsc_table(struct rproc *rproc,
>>>> + const struct firmware *fw);
>>>> +int tee_rproc_start(struct rproc *rproc);
>>>> +int tee_rproc_stop(struct rproc *rproc);
>>>> +
>>>> +#else
>>>> +
>>>> +static inline struct tee_rproc *tee_rproc_register(struct device *dev, struct rproc *rproc,
>>>> + unsigned int rproc_id)
>>>> +{
>>>> + return ERR_PTR(-ENODEV);
>>>> +}
>>>> +
>>>> +static int tee_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
>>>> +{
>>>> + /* This shouldn't be possible */
>>>> + WARN_ON(1);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static inline int tee_rproc_unregister(struct tee_rproc *trproc)
>>>> +{
>>>> + /* This shouldn't be possible */
>>>> + WARN_ON(1);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static inline int tee_rproc_load_fw(struct rproc *rproc, const struct firmware *fw)
>>>> +{
>>>> + /* This shouldn't be possible */
>>>> + WARN_ON(1);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static inline int tee_rproc_start(struct rproc *rproc)
>>>> +{
>>>> + /* This shouldn't be possible */
>>>> + WARN_ON(1);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static inline int tee_rproc_stop(struct rproc *rproc)
>>>> +{
>>>> + /* This shouldn't be possible */
>>>> + WARN_ON(1);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static inline struct resource_table *
>>>> +tee_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
>>>> +{
>>>> + /* This shouldn't be possible */
>>>> + WARN_ON(1);
>>>> +
>>>> + return NULL;
>>>> +}
>>>> +
>>>> +static inline struct resource_table *
>>>> +tee_rproc_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *fw)
>>>> +{
>>>> + /* This shouldn't be possible */
>>>> + WARN_ON(1);
>>>> +
>>>> + return NULL;
>>>> +}
>>>> +#endif /* CONFIG_TEE_REMOTEPROC */
>>>> +#endif /* TEE_REMOTEPROC_H */
>>>> --
>>>> 2.25.1
>>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] spi: s3c64xx: Use DMA mode from fifo size
From: Jaewon Kim @ 2024-03-29 8:58 UTC (permalink / raw)
To: Andi Shyti, Mark Brown, Krzysztof Kozlowski, Alim Akhtar,
Sam Protsenko
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Jaewon Kim
In-Reply-To: <CGME20240329090313epcas2p2cf95d22e44b6b1c120021622da68aeb8@epcas2p2.samsung.com>
If the SPI data size is smaller than FIFO, it operates in PIO mode,
and if it is larger than FIFO size, it oerates in DMA mode.
If the SPI data size is equal to fifo, it operates in PIO mode and it is
separated to 2 transfers. To prevent it, it must operate in DMA mode
from the case where the data size and the fifo size are the same.
Fixes: 1ee806718d5e ("spi: s3c64xx: support interrupt based pio mode")
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
---
drivers/spi/spi-s3c64xx.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 9fcbe040cb2f..f726d8670428 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -430,7 +430,7 @@ static bool s3c64xx_spi_can_dma(struct spi_controller *host,
struct s3c64xx_spi_driver_data *sdd = spi_controller_get_devdata(host);
if (sdd->rx_dma.ch && sdd->tx_dma.ch)
- return xfer->len > sdd->fifo_depth;
+ return xfer->len >= sdd->fifo_depth;
return false;
}
@@ -826,10 +826,9 @@ static int s3c64xx_spi_transfer_one(struct spi_controller *host,
return status;
}
- if (!is_polling(sdd) && (xfer->len > fifo_len) &&
+ if (!is_polling(sdd) && xfer->len >= fifo_len &&
sdd->rx_dma.ch && sdd->tx_dma.ch) {
use_dma = 1;
-
} else if (xfer->len >= fifo_len) {
tx_buf = xfer->tx_buf;
rx_buf = xfer->rx_buf;
--
2.43.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] spi: s3c64xx: Use DMA mode from fifo size
From: Jaewon Kim @ 2024-03-29 9:09 UTC (permalink / raw)
To: Andi Shyti, Mark Brown, Krzysztof Kozlowski, Alim Akhtar,
Sam Protsenko
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel
In-Reply-To: <20240329085840.65856-1-jaewon02.kim@samsung.com>
On 3/29/24 17:58, Jaewon Kim wrote:
> If the SPI data size is smaller than FIFO, it operates in PIO mode,
> and if it is larger than FIFO size, it oerates in DMA mode.
>
> If the SPI data size is equal to fifo, it operates in PIO mode and it is
> separated to 2 transfers. To prevent it, it must operate in DMA mode
> from the case where the data size and the fifo size are the same.
>
> Fixes: 1ee806718d5e ("spi: s3c64xx: support interrupt based pio mode")
> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> ---
> drivers/spi/spi-s3c64xx.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 9fcbe040cb2f..f726d8670428 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -430,7 +430,7 @@ static bool s3c64xx_spi_can_dma(struct spi_controller *host,
> struct s3c64xx_spi_driver_data *sdd = spi_controller_get_devdata(host);
>
> if (sdd->rx_dma.ch && sdd->tx_dma.ch)
> - return xfer->len > sdd->fifo_depth;
> + return xfer->len >= sdd->fifo_depth;
>
> return false;
> }
> @@ -826,10 +826,9 @@ static int s3c64xx_spi_transfer_one(struct spi_controller *host,
> return status;
> }
>
> - if (!is_polling(sdd) && (xfer->len > fifo_len) &&
> + if (!is_polling(sdd) && xfer->len >= fifo_len &&
> sdd->rx_dma.ch && sdd->tx_dma.ch) {
> use_dma = 1;
> -
> } else if (xfer->len >= fifo_len) {
> tx_buf = xfer->tx_buf;
> rx_buf = xfer->rx_buf;
Sorry, I didn't add v2 by mistake.
This is v1 mail thread.
-
https://lore.kernel.org/linux-arm-kernel/CAPLW+4k4qh4ZYBufZoGbUZN0yxSE2X8bOdkEQVw1Zg9YUVpbug@mail.gmail.com/T/
Thanks
Jaewon Kim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] dt-bindings: reset: Add Amlogic T7 Reset Controller
From: Kelvin Zhang via B4 Relay @ 2024-03-29 9:17 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Zelong Dong, Kelvin Zhang
In-Reply-To: <20240329-t7-reset-v1-0-4c6e2e68359e@amlogic.com>
From: Zelong Dong <zelong.dong@amlogic.com>
Add a new compatible and the related header file
for Amlogic T7 Reset Controller.
Signed-off-by: Zelong Dong <zelong.dong@amlogic.com>
Signed-off-by: Kelvin Zhang <kelvin.zhang@amlogic.com>
---
.../bindings/reset/amlogic,meson-reset.yaml | 1 +
include/dt-bindings/reset/amlogic,t7-reset.h | 197 +++++++++++++++++++++
2 files changed, 198 insertions(+)
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
index f0c6c0df0ce3..fefe343e5afe 100644
--- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
@@ -19,6 +19,7 @@ properties:
- amlogic,meson-a1-reset # Reset Controller on A1 and compatible SoCs
- amlogic,meson-s4-reset # Reset Controller on S4 and compatible SoCs
- amlogic,c3-reset # Reset Controller on C3 and compatible SoCs
+ - amlogic,t7-reset # Reset Controller on T7 and compatible SoCs
reg:
maxItems: 1
diff --git a/include/dt-bindings/reset/amlogic,t7-reset.h b/include/dt-bindings/reset/amlogic,t7-reset.h
new file mode 100644
index 000000000000..ca4a832eeeec
--- /dev/null
+++ b/include/dt-bindings/reset/amlogic,t7-reset.h
@@ -0,0 +1,197 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
+/*
+ * Copyright (c) 2024 Amlogic, Inc. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_AMLOGIC_T7_RESET_H
+#define _DT_BINDINGS_AMLOGIC_T7_RESET_H
+
+/* RESET0 */
+/* 0-3 */
+#define RESET_USB 4
+#define RESET_U2DRD 5
+#define RESET_U3DRD 6
+#define RESET_U3DRD_PIPE0 7
+#define RESET_U2PHY20 8
+#define RESET_U2PHY21 9
+#define RESET_GDC 10
+#define RESET_HDMI20_AES 11
+#define RESET_HDMIRX 12
+#define RESET_HDMIRX_APB 13
+#define RESET_DEWARP 14
+/* 15 */
+#define RESET_HDMITX_CAPB3 16
+#define RESET_BRG_VCBUG_DEC 17
+#define RESET_VCBUS 18
+#define RESET_VID_PLL_DIV 19
+#define RESET_VDI6 20
+#define RESET_GE2D 21
+#define RESET_HDMITXPHY 22
+#define RESET_VID_LOCK 23
+#define RESET_VENC0 24
+#define RESET_VDAC 25
+#define RESET_VENC2 26
+#define RESET_VENC1 27
+#define RESET_RDMA 28
+#define RESET_HDMITX 29
+#define RESET_VIU 30
+#define RESET_VENC 31
+
+/* RESET1 */
+#define RESET_AUDIO 32
+#define RESET_MALI_CAPB3 33
+#define RESET_MALI 34
+#define RESET_DDR_APB 35
+#define RESET_DDR 36
+#define RESET_DOS_CAPB3 37
+#define RESET_DOS 38
+#define RESET_COMBO_DPHY_CHAN2 39
+#define RESET_DEBUG_B 40
+#define RESET_DEBUG_A 41
+#define RESET_DSP_B 42
+#define RESET_DSP_A 43
+#define RESET_PCIE_A 44
+#define RESET_PCIE_PHY 45
+#define RESET_PCIE_APB 46
+#define RESET_ANAKIN 47
+#define RESET_ETH 48
+#define RESET_EDP0_CTRL 49
+#define RESET_EDP1_CTRL 50
+#define RESET_COMBO_DPHY_CHAN0 51
+#define RESET_COMBO_DPHY_CHAN1 52
+#define RESET_DSI_LVDS_EDP_TOP 53
+#define RESET_PCIE1_PHY 54
+#define RESET_PCIE1_APB 55
+#define RESET_DDR_1 56
+/* 57 */
+#define RESET_EDP1_PIPELINE 58
+#define RESET_EDP0_PIPELINE 59
+#define RESET_MIPI_DSI1_PHY 60
+#define RESET_MIPI_DSI0_PHY 61
+#define RESET_MIPI_DSI_A_HOST 62
+#define RESET_MIPI_DSI_B_HOST 63
+
+/* RESET2 */
+#define RESET_DEVICE_MMC_ARB 64
+#define RESET_IR_CTRL 65
+#define RESET_TS_A73 66
+#define RESET_TS_A53 67
+#define RESET_SPICC_2 68
+#define RESET_SPICC_3 69
+#define RESET_SPICC_4 70
+#define RESET_SPICC_5 71
+#define RESET_SMART_CARD 72
+#define RESET_SPICC_0 73
+#define RESET_SPICC_1 74
+#define RESET_RSA 75
+/* 76-79 */
+#define RESET_MSR_CLK 80
+#define RESET_SPIFC 81
+#define RESET_SAR_ADC 82
+#define RESET_BT 83
+/* 84-87 */
+#define RESET_ACODEC 88
+#define RESET_CEC 89
+#define RESET_AFIFO 90
+#define RESET_WATCHDOG 91
+/* 92-95 */
+
+/* RESET3 */
+#define RESET_BRG_NIC1_GPV 96
+#define RESET_BRG_NIC2_GPV 97
+#define RESET_BRG_NIC3_GPV 98
+#define RESET_BRG_NIC4_GPV 99
+#define RESET_BRG_NIC5_GPV 100
+/* 101-121 */
+#define RESET_MIPI_ISP 122
+#define RESET_BRG_ADB_MALI_1 123
+#define RESET_BRG_ADB_MALI_0 124
+#define RESET_BRG_ADB_A73 125
+#define RESET_BRG_ADB_A53 126
+#define RESET_BRG_CCI 127
+
+/* RESET4 */
+#define RESET_PWM_AO_AB 128
+#define RESET_PWM_AO_CD 129
+#define RESET_PWM_AO_EF 130
+#define RESET_PWM_AO_GH 131
+#define RESET_PWM_AB 132
+#define RESET_PWM_CD 133
+#define RESET_PWM_EF 134
+/* 135-137 */
+#define RESET_UART_A 138
+#define RESET_UART_B 139
+#define RESET_UART_C 140
+#define RESET_UART_D 141
+#define RESET_UART_E 142
+#define RESET_UART_F 143
+#define RESET_I2C_S_A 144
+#define RESET_I2C_M_A 145
+#define RESET_I2C_M_B 146
+#define RESET_I2C_M_C 147
+#define RESET_I2C_M_D 148
+#define RESET_I2C_M_E 149
+#define RESET_I2C_M_F 150
+#define RESET_I2C_M_AO_A 151
+#define RESET_SD_EMMC_A 152
+#define RESET_SD_EMMC_B 153
+#define RESET_SD_EMMC_C 154
+#define RESET_I2C_M_AO_B 155
+#define RESET_TS_GPU 156
+#define RESET_TS_NNA 157
+#define RESET_TS_VPN 158
+#define RESET_TS_HEVC 159
+
+/* RESET5 */
+#define RESET_BRG_NOC_DDR_1 160
+#define RESET_BRG_NOC_DDR_0 161
+#define RESET_BRG_NOC_MAIN 162
+#define RESET_BRG_NOC_ALL 163
+/* 164-167 */
+#define RESET_BRG_NIC2_SYS 168
+#define RESET_BRG_NIC2_MAIN 169
+#define RESET_BRG_NIC2_HDMI 170
+#define RESET_BRG_NIC2_ALL 171
+#define RESET_BRG_NIC3_WAVE 172
+#define RESET_BRG_NIC3_VDEC 173
+#define RESET_BRG_NIC3_HEVCF 174
+#define RESET_BRG_NIC3_HEVCB 175
+#define RESET_BRG_NIC3_HCODEC 176
+#define RESET_BRG_NIC3_GE2D 177
+#define RESET_BRG_NIC3_GDC 178
+#define RESET_BRG_NIC3_AMLOGIC 179
+#define RESET_BRG_NIC3_MAIN 180
+#define RESET_BRG_NIC3_ALL 181
+#define RESET_BRG_NIC5_VPU 182
+/* 183-185 */
+#define RESET_BRG_NIC4_DSPB 186
+#define RESET_BRG_NIC4_DSPA 187
+#define RESET_BRG_NIC4_VAPB 188
+#define RESET_BRG_NIC4_CLK81 189
+#define RESET_BRG_NIC4_MAIN 190
+#define RESET_BRG_NIC4_ALL 191
+
+/* RESET6 */
+#define RESET_BRG_VDEC_PIPEL 192
+#define RESET_BRG_HEVCF_DMC_PIPEL 193
+#define RESET_BRG_NIC2TONIC4_PIPEL 194
+#define RESET_BRG_HDMIRXTONIC2_PIPEL 195
+#define RESET_BRG_SECTONIC4_PIPEL 196
+#define RESET_BRG_VPUTONOC_PIPEL 197
+#define RESET_BRG_NIC4TONOC_PIPEL 198
+#define RESET_BRG_NIC3TONOC_PIPEL 199
+#define RESET_BRG_NIC2TONOC_PIPEL 200
+#define RESET_BRG_NNATONOC_PIPEL 201
+#define RESET_BRG_FRISP3_PIPEL 202
+#define RESET_BRG_FRISP2_PIPEL 203
+#define RESET_BRG_FRISP1_PIPEL 204
+#define RESET_BRG_FRISP0_PIPEL 205
+/* 206-217 */
+#define RESET_BRG_AMPIPE_NAND 218
+#define RESET_BRG_AMPIPE_ETH 219
+/* 220 */
+#define RESET_BRG_AM2AXI0 221
+#define RESET_BRG_AM2AXI1 222
+#define RESET_BRG_AM2AXI2 223
+
+#endif
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] Add support for Amlogic T7 Reset
From: Kelvin Zhang via B4 Relay @ 2024-03-29 9:17 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Zelong Dong, Kelvin Zhang
Add a new compatible and device node for Amlogic T7 Reset.
Signed-off-by: Zelong Dong <zelong.dong@amlogic.com>
Signed-off-by: Kelvin Zhang <kelvin.zhang@amlogic.com>
---
Zelong Dong (3):
dt-bindings: reset: Add Amlogic T7 Reset Controller
reset: reset-meson: add support for Amlogic T7 SoC Reset Controller
arm64: dts: amlogic: add reset controller for Amlogic T7 SoC
.../bindings/reset/amlogic,meson-reset.yaml | 1 +
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 7 +
drivers/reset/reset-meson.c | 6 +
include/dt-bindings/reset/amlogic,t7-reset.h | 197 +++++++++++++++++++++
4 files changed, 211 insertions(+)
---
base-commit: a6bd6c9333397f5a0e2667d4d82fef8c970108f2
change-id: 20240329-t7-reset-f87e8346fadb
Best regards,
--
Kelvin Zhang <kelvin.zhang@amlogic.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] reset: reset-meson: add support for Amlogic T7 SoC Reset Controller
From: Kelvin Zhang via B4 Relay @ 2024-03-29 9:17 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Zelong Dong, Kelvin Zhang
In-Reply-To: <20240329-t7-reset-v1-0-4c6e2e68359e@amlogic.com>
From: Zelong Dong <zelong.dong@amlogic.com>
There are 7 sets of Reset Source in Amlogic T7 SoC Reset Controller,
and the offset between base and level registers is 0x40.
Add a new compatible string and struct meson_reset_param to support
the reset controller on T7 SoC.
Signed-off-by: Zelong Dong <zelong.dong@amlogic.com>
Signed-off-by: Kelvin Zhang <kelvin.zhang@amlogic.com>
---
drivers/reset/reset-meson.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
index f78be97898bc..1e9fca3e30e8 100644
--- a/drivers/reset/reset-meson.c
+++ b/drivers/reset/reset-meson.c
@@ -102,6 +102,11 @@ static const struct meson_reset_param meson_s4_param = {
.level_offset = 0x40,
};
+static const struct meson_reset_param t7_param = {
+ .reg_count = 7,
+ .level_offset = 0x40,
+};
+
static const struct of_device_id meson_reset_dt_ids[] = {
{ .compatible = "amlogic,meson8b-reset", .data = &meson8b_param},
{ .compatible = "amlogic,meson-gxbb-reset", .data = &meson8b_param},
@@ -109,6 +114,7 @@ static const struct of_device_id meson_reset_dt_ids[] = {
{ .compatible = "amlogic,meson-a1-reset", .data = &meson_a1_param},
{ .compatible = "amlogic,meson-s4-reset", .data = &meson_s4_param},
{ .compatible = "amlogic,c3-reset", .data = &meson_s4_param},
+ { .compatible = "amlogic,t7-reset", .data = &t7_param},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, meson_reset_dt_ids);
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: amlogic: add reset controller for Amlogic T7 SoC
From: Kelvin Zhang via B4 Relay @ 2024-03-29 9:17 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Zelong Dong, Kelvin Zhang
In-Reply-To: <20240329-t7-reset-v1-0-4c6e2e68359e@amlogic.com>
From: Zelong Dong <zelong.dong@amlogic.com>
Add the reset controller device of Amlogic T7 SoC family
Signed-off-by: Zelong Dong <zelong.dong@amlogic.com>
Signed-off-by: Kelvin Zhang <kelvin.zhang@amlogic.com>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 5248bdf824ea..e94bb85b5292 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -5,6 +5,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/amlogic,t7-pwrc.h>
+#include <dt-bindings/reset/amlogic,t7-reset.h>
/ {
interrupt-parent = <&gic>;
@@ -149,6 +150,12 @@ apb4: bus@fe000000 {
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xfe000000 0x0 0x480000>;
+ reset: reset-controller@2000 {
+ compatible = "amlogic,t7-reset";
+ reg = <0x0 0x2000 0x0 0x98>;
+ #reset-cells = <1>;
+ };
+
watchdog@2100 {
compatible = "amlogic,t7-wdt";
reg = <0x0 0x2100 0x0 0x10>;
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] media: v4l2-ctrls: Add average qp control
From: Ming Qian @ 2024-03-29 9:23 UTC (permalink / raw)
To: mchehab, hverkuil-cisco
Cc: shawnguo, robh+dt, s.hauer, kernel, festevam, linux-imx,
xiahong.bao, eagle.zhou, tao.jiang_2, ming.qian, imx, linux-media,
linux-kernel, linux-arm-kernel
Add a control V4L2_CID_MPEG_VIDEO_AVERAGE_QP to report the average qp
value of current encoded frame.
Signed-off-by: Ming Qian <ming.qian@nxp.com>
---
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 4 ++++
drivers/media/v4l2-core/v4l2-ctrls-defs.c | 5 +++++
include/uapi/linux/v4l2-controls.h | 2 ++
3 files changed, 11 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 2a165ae063fb..cef20b3f54ca 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1653,6 +1653,10 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
Quantization parameter for a P frame for FWHT. Valid range: from 1
to 31.
+``V4L2_CID_MPEG_VIDEO_AVERAGE_QP (integer)``
+ This read-only control returns the average qp value of the currently
+ encoded frame. Applicable to the H264 and HEVC encoders.
+
.. raw:: latex
\normalsize
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
index 8696eb1cdd61..88e86e4e539d 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
@@ -972,6 +972,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_USE_LTR_FRAMES: return "Use LTR Frames";
case V4L2_CID_FWHT_I_FRAME_QP: return "FWHT I-Frame QP Value";
case V4L2_CID_FWHT_P_FRAME_QP: return "FWHT P-Frame QP Value";
+ case V4L2_CID_MPEG_VIDEO_AVERAGE_QP: return "Average QP value";
/* VPX controls */
case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS: return "VPX Number of Partitions";
@@ -1507,6 +1508,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
*max = 0xffffffffffffLL;
*step = 1;
break;
+ case V4L2_CID_MPEG_VIDEO_AVERAGE_QP:
+ *type = V4L2_CTRL_TYPE_INTEGER;
+ *flags |= V4L2_CTRL_FLAG_VOLATILE | V4L2_CTRL_FLAG_READ_ONLY;
+ break;
case V4L2_CID_PIXEL_RATE:
*type = V4L2_CTRL_TYPE_INTEGER64;
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 99c3f5e99da7..974fd254e573 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -898,6 +898,8 @@ enum v4l2_mpeg_video_av1_level {
V4L2_MPEG_VIDEO_AV1_LEVEL_7_3 = 23
};
+#define V4L2_CID_MPEG_VIDEO_AVERAGE_QP (V4L2_CID_CODEC_BASE + 657)
+
/* MPEG-class control IDs specific to the CX2341x driver as defined by V4L2 */
#define V4L2_CID_CODEC_CX2341X_BASE (V4L2_CTRL_CLASS_CODEC | 0x1000)
#define V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE (V4L2_CID_CODEC_CX2341X_BASE+0)
--
2.43.0-rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] media: amphion: Report the average qp of current encoded frame
From: Ming Qian @ 2024-03-29 9:23 UTC (permalink / raw)
To: mchehab, hverkuil-cisco
Cc: shawnguo, robh+dt, s.hauer, kernel, festevam, linux-imx,
xiahong.bao, eagle.zhou, tao.jiang_2, ming.qian, imx, linux-media,
linux-kernel, linux-arm-kernel
In-Reply-To: <20240329092352.2648837-1-ming.qian@nxp.com>
Report the average qp value of current encoded frame via the control
V4L2_CID_MPEG_VIDEO_AVERAGE_QP
Signed-off-by: Ming Qian <ming.qian@nxp.com>
---
drivers/media/platform/amphion/venc.c | 4 ++++
drivers/media/platform/amphion/vpu.h | 2 ++
drivers/media/platform/amphion/vpu_defs.h | 1 +
drivers/media/platform/amphion/vpu_helpers.c | 3 +++
drivers/media/platform/amphion/vpu_v4l2.c | 9 +++++++++
drivers/media/platform/amphion/vpu_v4l2.h | 1 +
drivers/media/platform/amphion/vpu_windsor.c | 2 ++
7 files changed, 22 insertions(+)
diff --git a/drivers/media/platform/amphion/venc.c b/drivers/media/platform/amphion/venc.c
index 4eb57d793a9c..12cebafeaf3b 100644
--- a/drivers/media/platform/amphion/venc.c
+++ b/drivers/media/platform/amphion/venc.c
@@ -680,6 +680,9 @@ static int venc_ctrl_init(struct vpu_inst *inst)
~(1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME),
V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME);
+ v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_AVERAGE_QP, 0, 51, 1, 0);
+
if (inst->ctrl_handler.error) {
ret = inst->ctrl_handler.error;
v4l2_ctrl_handler_free(&inst->ctrl_handler);
@@ -819,6 +822,7 @@ static int venc_get_one_encoded_frame(struct vpu_inst *inst,
vbuf->field = inst->cap_format.field;
vbuf->flags |= frame->info.pic_type;
vpu_set_buffer_state(vbuf, VPU_BUF_STATE_IDLE);
+ vpu_set_buffer_average_qp(vbuf, frame->info.average_qp);
dev_dbg(inst->dev, "[%d][OUTPUT TS]%32lld\n", inst->id, vbuf->vb2_buf.timestamp);
v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_DONE);
venc->ready_count++;
diff --git a/drivers/media/platform/amphion/vpu.h b/drivers/media/platform/amphion/vpu.h
index 0246cf0ac3a8..d21ca6bf2459 100644
--- a/drivers/media/platform/amphion/vpu.h
+++ b/drivers/media/platform/amphion/vpu.h
@@ -270,6 +270,7 @@ struct vpu_inst {
u8 xfer_func;
u32 sequence;
u32 extra_size;
+ u32 current_average_qp;
u32 flows[16];
u32 flow_idx;
@@ -306,6 +307,7 @@ struct vpu_vb2_buffer {
dma_addr_t chroma_v;
unsigned int state;
u32 tag;
+ u32 average_qp;
};
void vpu_writel(struct vpu_dev *vpu, u32 reg, u32 val);
diff --git a/drivers/media/platform/amphion/vpu_defs.h b/drivers/media/platform/amphion/vpu_defs.h
index 7320852668d6..428d988cf2f7 100644
--- a/drivers/media/platform/amphion/vpu_defs.h
+++ b/drivers/media/platform/amphion/vpu_defs.h
@@ -114,6 +114,7 @@ struct vpu_enc_pic_info {
u32 wptr;
u32 crc;
s64 timestamp;
+ u32 average_qp;
};
struct vpu_dec_codec_info {
diff --git a/drivers/media/platform/amphion/vpu_helpers.c b/drivers/media/platform/amphion/vpu_helpers.c
index d12310af9ebc..59139302cb1d 100644
--- a/drivers/media/platform/amphion/vpu_helpers.c
+++ b/drivers/media/platform/amphion/vpu_helpers.c
@@ -378,6 +378,9 @@ int vpu_helper_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:
ctrl->val = inst->min_buffer_out;
break;
+ case V4L2_CID_MPEG_VIDEO_AVERAGE_QP:
+ ctrl->val = inst->current_average_qp;
+ break;
default:
return -EINVAL;
}
diff --git a/drivers/media/platform/amphion/vpu_v4l2.c b/drivers/media/platform/amphion/vpu_v4l2.c
index c88738e8fff7..893f494ffb0b 100644
--- a/drivers/media/platform/amphion/vpu_v4l2.c
+++ b/drivers/media/platform/amphion/vpu_v4l2.c
@@ -63,6 +63,13 @@ unsigned int vpu_get_buffer_state(struct vb2_v4l2_buffer *vbuf)
return vpu_buf->state;
}
+void vpu_set_buffer_average_qp(struct vb2_v4l2_buffer *vbuf, u32 qp)
+{
+ struct vpu_vb2_buffer *vpu_buf = to_vpu_vb2_buffer(vbuf);
+
+ vpu_buf->average_qp = qp;
+}
+
void vpu_v4l2_set_error(struct vpu_inst *inst)
{
vpu_inst_lock(inst);
@@ -536,9 +543,11 @@ static int vpu_vb2_buf_prepare(struct vb2_buffer *vb)
static void vpu_vb2_buf_finish(struct vb2_buffer *vb)
{
struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+ struct vpu_vb2_buffer *vpu_buf = to_vpu_vb2_buffer(vbuf);
struct vpu_inst *inst = vb2_get_drv_priv(vb->vb2_queue);
struct vb2_queue *q = vb->vb2_queue;
+ inst->current_average_qp = vpu_buf->average_qp;
if (vbuf->flags & V4L2_BUF_FLAG_LAST)
vpu_notify_eos(inst);
diff --git a/drivers/media/platform/amphion/vpu_v4l2.h b/drivers/media/platform/amphion/vpu_v4l2.h
index 60f43056a7a2..56f2939fa84d 100644
--- a/drivers/media/platform/amphion/vpu_v4l2.h
+++ b/drivers/media/platform/amphion/vpu_v4l2.h
@@ -12,6 +12,7 @@ void vpu_inst_lock(struct vpu_inst *inst);
void vpu_inst_unlock(struct vpu_inst *inst);
void vpu_set_buffer_state(struct vb2_v4l2_buffer *vbuf, unsigned int state);
unsigned int vpu_get_buffer_state(struct vb2_v4l2_buffer *vbuf);
+void vpu_set_buffer_average_qp(struct vb2_v4l2_buffer *vbuf, u32 qp);
int vpu_v4l2_open(struct file *file, struct vpu_inst *inst);
int vpu_v4l2_close(struct file *file);
diff --git a/drivers/media/platform/amphion/vpu_windsor.c b/drivers/media/platform/amphion/vpu_windsor.c
index 5f1101d7cf9e..e7d37aa4b826 100644
--- a/drivers/media/platform/amphion/vpu_windsor.c
+++ b/drivers/media/platform/amphion/vpu_windsor.c
@@ -499,6 +499,7 @@ struct windsor_pic_info {
u32 proc_dacc_rng_wr_cnt;
s32 tv_s;
u32 tv_ns;
+ u32 average_qp;
};
u32 vpu_windsor_get_data_size(void)
@@ -734,6 +735,7 @@ static void vpu_windsor_unpack_pic_info(struct vpu_rpc_event *pkt, void *data)
info->wptr = get_ptr(windsor->str_buff_wptr);
info->crc = windsor->frame_crc;
info->timestamp = timespec64_to_ns(&ts);
+ info->average_qp = windsor->average_qp;
}
static void vpu_windsor_unpack_mem_req(struct vpu_rpc_event *pkt, void *data)
--
2.43.0-rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/3] reset: reset-meson: add support for Amlogic T7 SoC Reset Controller
From: Neil Armstrong @ 2024-03-29 9:25 UTC (permalink / raw)
To: kelvin.zhang, Philipp Zabel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Zelong Dong
In-Reply-To: <20240329-t7-reset-v1-2-4c6e2e68359e@amlogic.com>
On 29/03/2024 10:17, Kelvin Zhang via B4 Relay wrote:
> From: Zelong Dong <zelong.dong@amlogic.com>
>
> There are 7 sets of Reset Source in Amlogic T7 SoC Reset Controller,
> and the offset between base and level registers is 0x40.
> Add a new compatible string and struct meson_reset_param to support
> the reset controller on T7 SoC.
>
> Signed-off-by: Zelong Dong <zelong.dong@amlogic.com>
> Signed-off-by: Kelvin Zhang <kelvin.zhang@amlogic.com>
> ---
> drivers/reset/reset-meson.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
> index f78be97898bc..1e9fca3e30e8 100644
> --- a/drivers/reset/reset-meson.c
> +++ b/drivers/reset/reset-meson.c
> @@ -102,6 +102,11 @@ static const struct meson_reset_param meson_s4_param = {
> .level_offset = 0x40,
> };
>
> +static const struct meson_reset_param t7_param = {
> + .reg_count = 7,
> + .level_offset = 0x40,
> +};
> +
> static const struct of_device_id meson_reset_dt_ids[] = {
> { .compatible = "amlogic,meson8b-reset", .data = &meson8b_param},
> { .compatible = "amlogic,meson-gxbb-reset", .data = &meson8b_param},
> @@ -109,6 +114,7 @@ static const struct of_device_id meson_reset_dt_ids[] = {
> { .compatible = "amlogic,meson-a1-reset", .data = &meson_a1_param},
> { .compatible = "amlogic,meson-s4-reset", .data = &meson_s4_param},
> { .compatible = "amlogic,c3-reset", .data = &meson_s4_param},
> + { .compatible = "amlogic,t7-reset", .data = &t7_param},
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, meson_reset_dt_ids);
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] reset: reset-meson: add support for Amlogic T7 SoC Reset Controller
From: Neil Armstrong @ 2024-03-29 9:25 UTC (permalink / raw)
To: kelvin.zhang, Philipp Zabel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Zelong Dong
In-Reply-To: <20240329-t7-reset-v1-2-4c6e2e68359e@amlogic.com>
On 29/03/2024 10:17, Kelvin Zhang via B4 Relay wrote:
> From: Zelong Dong <zelong.dong@amlogic.com>
>
> There are 7 sets of Reset Source in Amlogic T7 SoC Reset Controller,
> and the offset between base and level registers is 0x40.
> Add a new compatible string and struct meson_reset_param to support
> the reset controller on T7 SoC.
>
> Signed-off-by: Zelong Dong <zelong.dong@amlogic.com>
> Signed-off-by: Kelvin Zhang <kelvin.zhang@amlogic.com>
> ---
> drivers/reset/reset-meson.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
> index f78be97898bc..1e9fca3e30e8 100644
> --- a/drivers/reset/reset-meson.c
> +++ b/drivers/reset/reset-meson.c
> @@ -102,6 +102,11 @@ static const struct meson_reset_param meson_s4_param = {
> .level_offset = 0x40,
> };
>
> +static const struct meson_reset_param t7_param = {
> + .reg_count = 7,
> + .level_offset = 0x40,
> +};
> +
> static const struct of_device_id meson_reset_dt_ids[] = {
> { .compatible = "amlogic,meson8b-reset", .data = &meson8b_param},
> { .compatible = "amlogic,meson-gxbb-reset", .data = &meson8b_param},
> @@ -109,6 +114,7 @@ static const struct of_device_id meson_reset_dt_ids[] = {
> { .compatible = "amlogic,meson-a1-reset", .data = &meson_a1_param},
> { .compatible = "amlogic,meson-s4-reset", .data = &meson_s4_param},
> { .compatible = "amlogic,c3-reset", .data = &meson_s4_param},
> + { .compatible = "amlogic,t7-reset", .data = &t7_param},
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, meson_reset_dt_ids);
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: amlogic: add reset controller for Amlogic T7 SoC
From: Neil Armstrong @ 2024-03-29 9:25 UTC (permalink / raw)
To: kelvin.zhang, Philipp Zabel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Zelong Dong
In-Reply-To: <20240329-t7-reset-v1-3-4c6e2e68359e@amlogic.com>
On 29/03/2024 10:17, Kelvin Zhang via B4 Relay wrote:
> From: Zelong Dong <zelong.dong@amlogic.com>
>
> Add the reset controller device of Amlogic T7 SoC family
>
> Signed-off-by: Zelong Dong <zelong.dong@amlogic.com>
> Signed-off-by: Kelvin Zhang <kelvin.zhang@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 5248bdf824ea..e94bb85b5292 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -5,6 +5,7 @@
>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/power/amlogic,t7-pwrc.h>
> +#include <dt-bindings/reset/amlogic,t7-reset.h>
>
> / {
> interrupt-parent = <&gic>;
> @@ -149,6 +150,12 @@ apb4: bus@fe000000 {
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xfe000000 0x0 0x480000>;
>
> + reset: reset-controller@2000 {
> + compatible = "amlogic,t7-reset";
> + reg = <0x0 0x2000 0x0 0x98>;
> + #reset-cells = <1>;
> + };
> +
> watchdog@2100 {
> compatible = "amlogic,t7-wdt";
> reg = <0x0 0x2100 0x0 0x10>;
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] coresight: Add support for multiple output ports on the funnel
From: Tao Zhang @ 2024-03-29 9:27 UTC (permalink / raw)
To: Suzuki K Poulose, Mathieu Poirier, Alexander Shishkin,
Konrad Dybcio, Mike Leach, Rob Herring, Krzysztof Kozlowski
Cc: Jinlong Mao, Leo Yan, Greg Kroah-Hartman, coresight,
linux-arm-kernel, linux-kernel, devicetree, Tingwei Zhang,
Yuanfang Zhang, Trilok Soni, Song Chai, linux-arm-msm, andersson
In-Reply-To: <8d381e6e-9328-46ff-83fe-efbe5bb4363e@arm.com>
On 3/22/2024 12:41 AM, Suzuki K Poulose wrote:
> On 21/03/2024 08:32, Tao Zhang wrote:
>> Funnel devices are now capable of supporting multiple-inputs and
>> multiple-outputs configuration with in built hardware filtering
>> for TPDM devices. Add software support to this function. Output
>> port is selected according to the source in the trace path.
>>
>> The source of the input port on funnels will be marked in the
>> device tree.
>> e.g.
>> tpdm@xxxxxxx {
>> ... ... ... ...
>> };
>>
>> funnel_XXX: funnel@xxxxxxx {
>> ... ... ... ...
>> out-ports {
>> ... ... ... ...
>> port@x {
>> ... ... ... ...
>> label = "xxxxxxx.tpdm"; <-- To label the source
>> }; corresponding to the output
>> ... ... ... ... connection "port@x". And this
>> }; is a hardware static connections.
>> ... ... ... ... Here needs to refer to hardware
>> }; design.
>>
>> Then driver will parse the source label marked in the device tree, and
>> save it to the coresight path. When the function needs to know the
>> source label, it could obtain it from coresight path parameter. Finally,
>> the output port knows which source it corresponds to, and it also knows
>> which input port it corresponds to.
>
> Why do we need labels ? We have connection information for all devices
> (both in and out), so, why do we need this label to find a device ?
Because our funnel's design has multi-output ports, the data stream will not
know which output port should pass in building the data trace path. This
source
label can make the data stream find the right output port to go.
>
> And also, I thought TPDM is a source device, why does a funnel output
> port link to a source ?
No, this label doesn't mean this funnel output port link to a source, it
just let
the output port know its data source.
>
> Are these funnels programmable ? Or, are they static ? If they are
> static, do these need to be described in the DT ? If they are simply
> acting as a "LINK" (or HWFIFO ?)
These funnels are static, and we will add the "label" to the DT to
describe the
multi-output ports for these funnels.
"If they are simply acting as a "LINK" (or HWFIFO ?) " I'm not sure
what's the meaning
of this. Could you describe it in detail?
Best,
Tao
>
> Suzuki
>
>>
>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>> ---
>> drivers/hwtracing/coresight/coresight-core.c | 81 ++++++++++++++++---
>> .../hwtracing/coresight/coresight-platform.c | 5 ++
>> include/linux/coresight.h | 2 +
>> 3 files changed, 75 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-core.c
>> b/drivers/hwtracing/coresight/coresight-core.c
>> index 5dde597403b3..b1b5e6d9ec7a 100644
>> --- a/drivers/hwtracing/coresight/coresight-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>> @@ -113,15 +113,63 @@ struct coresight_device
>> *coresight_get_percpu_sink(int cpu)
>> }
>> EXPORT_SYMBOL_GPL(coresight_get_percpu_sink);
>> +static struct coresight_device *coresight_get_source(struct
>> list_head *path)
>> +{
>> + struct coresight_device *csdev;
>> +
>> + if (!path)
>> + return NULL;
>> +
>> + csdev = list_first_entry(path, struct coresight_node, link)->csdev;
>> + if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE)
>> + return NULL;
>> +
>> + return csdev;
>> +}
>> +
>> +/**
>> + * coresight_source_filter - checks whether the connection matches
>> the source
>> + * of path if connection is binded to specific source.
>> + * @path: The list of devices
>> + * @conn: The connection of one outport
>> + *
>> + * Return zero if the connection doesn't have a source binded or
>> source of the
>> + * path matches the source binds to connection.
>> + */
>> +static int coresight_source_filter(struct list_head *path,
>> + struct coresight_connection *conn)
>> +{
>> + int ret = 0;
>> + struct coresight_device *source = NULL;
>> +
>> + if (conn->source_label == NULL)
>> + return ret;
>> +
>> + source = coresight_get_source(path);
>> + if (source == NULL)
>> + return ret;
>> +
>> + if (strstr(kobject_get_path(&source->dev.kobj, GFP_KERNEL),
>> + conn->source_label))
>> + ret = 0;
>> + else
>> + ret = -1;
>> +
>> + return ret;
>> +}
>> +
>> static struct coresight_connection *
>> coresight_find_out_connection(struct coresight_device *src_dev,
>> - struct coresight_device *dest_dev)
>> + struct coresight_device *dest_dev,
>> + struct list_head *path)
>> {
>> int i;
>> struct coresight_connection *conn;
>> for (i = 0; i < src_dev->pdata->nr_outconns; i++) {
>> conn = src_dev->pdata->out_conns[i];
>> + if (coresight_source_filter(path, conn))
>> + continue;
>> if (conn->dest_dev == dest_dev)
>> return conn;
>> }
>> @@ -312,7 +360,8 @@ static void coresight_disable_sink(struct
>> coresight_device *csdev)
>> static int coresight_enable_link(struct coresight_device *csdev,
>> struct coresight_device *parent,
>> - struct coresight_device *child)
>> + struct coresight_device *child,
>> + struct list_head *path)
>> {
>> int ret = 0;
>> int link_subtype;
>> @@ -321,8 +370,8 @@ static int coresight_enable_link(struct
>> coresight_device *csdev,
>> if (!parent || !child)
>> return -EINVAL;
>> - inconn = coresight_find_out_connection(parent, csdev);
>> - outconn = coresight_find_out_connection(csdev, child);
>> + inconn = coresight_find_out_connection(parent, csdev, path);
>> + outconn = coresight_find_out_connection(csdev, child, path);
>> link_subtype = csdev->subtype.link_subtype;
>> if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG &&
>> IS_ERR(inconn))
>> @@ -341,7 +390,8 @@ static int coresight_enable_link(struct
>> coresight_device *csdev,
>> static void coresight_disable_link(struct coresight_device *csdev,
>> struct coresight_device *parent,
>> - struct coresight_device *child)
>> + struct coresight_device *child,
>> + struct list_head *path)
>> {
>> int i;
>> int link_subtype;
>> @@ -350,8 +400,8 @@ static void coresight_disable_link(struct
>> coresight_device *csdev,
>> if (!parent || !child)
>> return;
>> - inconn = coresight_find_out_connection(parent, csdev);
>> - outconn = coresight_find_out_connection(csdev, child);
>> + inconn = coresight_find_out_connection(parent, csdev, path);
>> + outconn = coresight_find_out_connection(csdev, child, path);
>> link_subtype = csdev->subtype.link_subtype;
>> if (link_ops(csdev)->disable) {
>> @@ -507,7 +557,7 @@ static void coresight_disable_path_from(struct
>> list_head *path,
>> case CORESIGHT_DEV_TYPE_LINK:
>> parent = list_prev_entry(nd, link)->csdev;
>> child = list_next_entry(nd, link)->csdev;
>> - coresight_disable_link(csdev, parent, child);
>> + coresight_disable_link(csdev, parent, child, path);
>> break;
>> default:
>> break;
>> @@ -588,7 +638,7 @@ int coresight_enable_path(struct list_head *path,
>> enum cs_mode mode,
>> case CORESIGHT_DEV_TYPE_LINK:
>> parent = list_prev_entry(nd, link)->csdev;
>> child = list_next_entry(nd, link)->csdev;
>> - ret = coresight_enable_link(csdev, parent, child);
>> + ret = coresight_enable_link(csdev, parent, child, path);
>> if (ret)
>> goto err;
>> break;
>> @@ -802,7 +852,8 @@ static void coresight_drop_device(struct
>> coresight_device *csdev)
>> */
>> static int _coresight_build_path(struct coresight_device *csdev,
>> struct coresight_device *sink,
>> - struct list_head *path)
>> + struct list_head *path,
>> + struct coresight_device *source)
>> {
>> int i, ret;
>> bool found = false;
>> @@ -814,7 +865,7 @@ static int _coresight_build_path(struct
>> coresight_device *csdev,
>> if (coresight_is_percpu_source(csdev) &&
>> coresight_is_percpu_sink(sink) &&
>> sink == per_cpu(csdev_sink,
>> source_ops(csdev)->cpu_id(csdev))) {
>> - if (_coresight_build_path(sink, sink, path) == 0) {
>> + if (_coresight_build_path(sink, sink, path, source) == 0) {
>> found = true;
>> goto out;
>> }
>> @@ -825,8 +876,12 @@ static int _coresight_build_path(struct
>> coresight_device *csdev,
>> struct coresight_device *child_dev;
>> child_dev = csdev->pdata->out_conns[i]->dest_dev;
>> + if (csdev->pdata->out_conns[i]->source_label &&
>> + !strstr(kobject_get_path(&source->dev.kobj, GFP_KERNEL),
>> + csdev->pdata->out_conns[i]->source_label))
>> + continue;
>> if (child_dev &&
>> - _coresight_build_path(child_dev, sink, path) == 0) {
>> + _coresight_build_path(child_dev, sink, path, source) ==
>> 0) {
>> found = true;
>> break;
>> }
>> @@ -871,7 +926,7 @@ struct list_head *coresight_build_path(struct
>> coresight_device *source,
>> INIT_LIST_HEAD(path);
>> - rc = _coresight_build_path(source, sink, path);
>> + rc = _coresight_build_path(source, sink, path, source);
>> if (rc) {
>> kfree(path);
>> return ERR_PTR(rc);
>> diff --git a/drivers/hwtracing/coresight/coresight-platform.c
>> b/drivers/hwtracing/coresight/coresight-platform.c
>> index 9d550f5697fa..f553fb20966d 100644
>> --- a/drivers/hwtracing/coresight/coresight-platform.c
>> +++ b/drivers/hwtracing/coresight/coresight-platform.c
>> @@ -205,6 +205,7 @@ static int of_coresight_parse_endpoint(struct
>> device *dev,
>> struct fwnode_handle *rdev_fwnode;
>> struct coresight_connection conn = {};
>> struct coresight_connection *new_conn;
>> + const char *label;
>> do {
>> /* Parse the local port details */
>> @@ -243,6 +244,10 @@ static int of_coresight_parse_endpoint(struct
>> device *dev,
>> conn.dest_fwnode = fwnode_handle_get(rdev_fwnode);
>> conn.dest_port = rendpoint.port;
>> + conn.source_label = NULL;
>> + if (!of_property_read_string(ep, "label", &label))
>> + conn.source_label = label;
>> +
>> new_conn = coresight_add_out_conn(dev, pdata, &conn);
>> if (IS_ERR_VALUE(new_conn)) {
>> fwnode_handle_put(conn.dest_fwnode);
>> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
>> index e8b6e388218c..a9c06ef9bbb2 100644
>> --- a/include/linux/coresight.h
>> +++ b/include/linux/coresight.h
>> @@ -167,6 +167,7 @@ struct coresight_desc {
>> * struct coresight_connection - representation of a single connection
>> * @src_port: a connection's output port number.
>> * @dest_port: destination's input port number @src_port is
>> connected to.
>> + * @source_label: source component's label.
>> * @dest_fwnode: destination component's fwnode handle.
>> * @dest_dev: a @coresight_device representation of the component
>> connected to @src_port. NULL until the device is created
>> @@ -195,6 +196,7 @@ struct coresight_desc {
>> struct coresight_connection {
>> int src_port;
>> int dest_port;
>> + const char *source_label;
>> struct fwnode_handle *dest_fwnode;
>> struct coresight_device *dest_dev;
>> struct coresight_sysfs_link *link;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: imx6ull: add seeed studio NPi dev board
From: Parthiban @ 2024-03-29 9:40 UTC (permalink / raw)
To: Shawn Guo
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, devicetree, linux-kernel,
linux-arm-kernel, Parthiban
In-Reply-To: <ZgY82LADJS9FuvY6@dragon>
Dear Shawn,
On 3/29/24 09:30, Shawn Guo wrote:
> 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?
imx6ull-seeed-npi.dtsi is for the npi SoM and -dev-board is for the board which uses the SoM.
Thanks,
Parthiban N
>
> Shawn
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Free MSIs in case of ENOMEM
From: Aleksandr Aprelkov @ 2024-03-29 9:51 UTC (permalink / raw)
To: Will Deacon
Cc: Aleksandr Aprelkov, Robin Murphy, Joerg Roedel, Jason Gunthorpe,
Nicolin Chen, Michael Shavit, Lu Baolu, Marc Zyngier,
linux-arm-kernel, iommu, linux-kernel
If devm_add_action() returns ENOMEM, then MSIs allocated but
not freed on teardown.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 166bdbd23161 ("iommu/arm-smmu: Add support for MSI on SMMUv3")
Signed-off-by: Aleksandr Aprelkov <aaprelkov@usergate.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 41f93c3ab160..136d0cdce6a9 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -3402,7 +3402,12 @@ static void arm_smmu_setup_msis(struct arm_smmu_device *smmu)
smmu->priq.q.irq = msi_get_virq(dev, PRIQ_MSI_INDEX);
/* Add callback to free MSIs on teardown */
- devm_add_action(dev, arm_smmu_free_msis, dev);
+ ret = devm_add_action(dev, arm_smmu_free_msis, dev);
+ if (ret) {
+ dev_warn(dev, "failed to add free MSIs callback - falling back to wired irqs\n");
+ arm_smmu_free_msis(dev);
+ return;
+ }
}
static void arm_smmu_setup_unique_irqs(struct arm_smmu_device *smmu)
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v12 2/2] arm64: boot: Support Flat Image Tree
From: Masahiro Yamada @ 2024-03-29 10:00 UTC (permalink / raw)
To: Simon Glass
Cc: linux-arm-kernel, Ahmad Fatoum, Nicolas Schier, Catalin Marinas,
Jonathan Corbet, Nathan Chancellor, Nick Terrell, Will Deacon,
linux-doc, linux-kbuild, linux-kernel, workflows
In-Reply-To: <20240329032836.141899-3-sjg@chromium.org>
On Fri, Mar 29, 2024 at 12:29 PM Simon Glass <sjg@chromium.org> wrote:
>
> Add a script which produces a Flat Image Tree (FIT), a single file
> containing the built kernel and associated devicetree files.
> Compression defaults to gzip which gives a good balance of size and
> performance.
>
> The files compress from about 86MB to 24MB using this approach.
>
> The FIT can be used by bootloaders which support it, such as U-Boot
> and Linuxboot. It permits automatic selection of the correct
> devicetree, matching the compatible string of the running board with
> the closest compatible string in the FIT. There is no need for
> filenames or other workarounds.
>
> Add a 'make image.fit' build target for arm64, as well.
>
> The FIT can be examined using 'dumpimage -l'.
>
> This uses the 'dtbs-list' file but processes only .dtb files, ignoring
> the overlay .dtbo files.
>
> This features requires pylibfdt (use 'pip install libfdt'). It also
> requires compression utilities for the algorithm being used. Supported
> compression options are the same as the Image.xxx files. Use
> FIT_COMPRESSION to select an algorithm other than gzip.
>
> While FIT supports a ramdisk / initrd, no attempt is made to support
> this here, since it must be built separately from the Linux build.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v12:
> - Avoid showing FIT message if V=0
Acked-by: Masahiro Yamada <masahiroy@kernel.org>
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 00/13] firmware: qcom: qseecom: convert to using the TZ allocator
From: Bartosz Golaszewski @ 2024-03-29 10:22 UTC (permalink / raw)
To: Maximilian Luz
Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Elliot Berman,
Krzysztof Kozlowski, Guru Das Srinagesh, Andrew Halaney,
Alex Elder, Srini Kandagatla, Arnd Bergmann, linux-arm-msm,
linux-kernel, linux-arm-kernel, kernel, Bartosz Golaszewski
In-Reply-To: <CAMRc=Mf_pvrh2VMfTVE-ZTypyO010p=to-cd8Q745DzSDXLGFw@mail.gmail.com>
On Thu, Mar 28, 2024 at 7:55 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Thu, Mar 28, 2024 at 5:50 PM Maximilian Luz <luzmaximilian@gmail.com> wrote:
> >
> > If I understand correctly, it enters an atomic section in
> > qcom_tzmem_alloc() and then tries to schedule somewhere down the line.
> > So this shouldn't be qseecom specific.
> >
> > I should probably also say that I'm currently testing this on a patched
> > v6.8 kernel, so there's a chance that it's my fault. However, as far as
> > I understand, it enters an atomic section in qcom_tzmem_alloc() and then
> > later tries to expand the pool memory with dma_alloc_coherent(). Which
> > AFAIK is allowed to sleep with GFP_KERNEL (and I guess that that's the
> > issue here).
> >
> > I've also tried the shmem allocator option, but that seems to get stuck
> > quite early at boot, before I even have usb-serial access to get any
> > logs. If I can find some more time, I'll try to see if I can get some
> > useful output for that.
> >
>
> Ah, I think it happens here:
>
> + guard(spinlock_irqsave)(&pool->lock);
> +
> +again:
> + vaddr = gen_pool_alloc(pool->genpool, size);
> + if (!vaddr) {
> + if (qcom_tzmem_try_grow_pool(pool, size, gfp))
> + goto again;
>
> We were called with GFP_KERNEL so this is what we pass on to
> qcom_tzmem_try_grow_pool() but we're now holding the spinlock. I need
> to revisit it. Thanks for the catch!
>
> Bart
Can you try the following tree?
https://git.codelinaro.org/bartosz_golaszewski/linux.git
topic/shm-bridge-v10
gen_pool_alloc() and gen_pool_add_virt() can be used without external
serialization. We only really need to protect the list of areas in the
pool when adding a new element. We could possibly even use
list_add_tail_rcu() as it updates the pointers atomically and go
lockless.
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/4] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
From: Arnaud POULIQUEN @ 2024-03-29 10:57 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, Jens Wiklander, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-stm32, linux-arm-kernel, linux-remoteproc,
linux-kernel, op-tee, devicetree
In-Reply-To: <ZgRT7PtzIogAWc50@p14s>
On 3/27/24 18:14, Mathieu Poirier wrote:
> On Tue, Mar 26, 2024 at 08:31:33PM +0100, Arnaud POULIQUEN wrote:
>>
>>
>> On 3/25/24 17:51, Mathieu Poirier wrote:
>>> On Fri, Mar 08, 2024 at 03:47:08PM +0100, Arnaud Pouliquen wrote:
>>>> The new TEE remoteproc device is used to manage remote firmware in a
>>>> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
>>>> introduced to delegate the loading of the firmware to the trusted
>>>> execution context. In such cases, the firmware should be signed and
>>>> adhere to the image format defined by the TEE.
>>>>
>>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>>>> ---
>>>> Updates from V3:
>>>> - remove support of the attach use case. Will be addressed in a separate
>>>> thread,
>>>> - add st_rproc_tee_ops::parse_fw ops,
>>>> - inverse call of devm_rproc_alloc()and tee_rproc_register() to manage cross
>>>> reference between the rproc struct and the tee_rproc struct in tee_rproc.c.
>>>> ---
>>>> drivers/remoteproc/stm32_rproc.c | 60 +++++++++++++++++++++++++++++---
>>>> 1 file changed, 56 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
>>>> index 8cd838df4e92..13df33c78aa2 100644
>>>> --- a/drivers/remoteproc/stm32_rproc.c
>>>> +++ b/drivers/remoteproc/stm32_rproc.c
>>>> @@ -20,6 +20,7 @@
>>>> #include <linux/remoteproc.h>
>>>> #include <linux/reset.h>
>>>> #include <linux/slab.h>
>>>> +#include <linux/tee_remoteproc.h>
>>>> #include <linux/workqueue.h>
>>>>
>>>> #include "remoteproc_internal.h"
>>>> @@ -49,6 +50,9 @@
>>>> #define M4_STATE_STANDBY 4
>>>> #define M4_STATE_CRASH 5
>>>>
>>>> +/* Remote processor unique identifier aligned with the Trusted Execution Environment definitions */
>>>
>>> Why is this the case? At least from the kernel side it is possible to call
>>> tee_rproc_register() with any kind of value, why is there a need to be any
>>> kind of alignment with the TEE?
>>
>>
>> The use of the proc_id is to identify a processor in case of multi co-processors.
>>
>
> That is well understood.
>
>> For instance we can have a system with A DSP and a modem. We would use the same
>> TEE service, but
>
> That too.
>
>> the TEE driver will probably be different, same for the signature key.
>
> What TEE driver are we talking about here?
In OP-TEE remoteproc frameork is divided in 2 or 3 layers:
- the remoteproc Trusted Application (TA) [1] which is platform agnostic
- The remoteproc Pseudo Trusted Application (PTA) [2] which is platform
dependent and can rely on the proc ID to retrieve the context.
- the remoteproc driver (optional for some platforms) [3], which is in charge
of DT parsing and platform configuration.
Here TEE driver can be interpreted by remote PTA and/or platform driver.
[1]
https://elixir.bootlin.com/op-tee/latest/source/ta/remoteproc/src/remoteproc_core.c
[2]
https://elixir.bootlin.com/op-tee/latest/source/core/pta/stm32mp/remoteproc_pta.c
[3]
https://elixir.bootlin.com/op-tee/latest/source/core/drivers/remoteproc/stm32_remoteproc.c
>
>> In such case the proc ID allows to identify the the processor you want to address.
>>
>
> That too is well understood, but there is no alignment needed with the TEE, i.e
> the TEE application is not expecting a value of '0'. We could set
> STM32_MP1_M4_PROC_ID to 0xDEADBEEF and things would work. This driver won't go
> anywhere for as long as it is not the case.
Here I suppose that you do not challenge the rproc_ID use in general, but for
the stm32mp1 platform as we have only one remote processor. I'm right?
In OP-TEE the check is done here:
https://elixir.bootlin.com/op-tee/latest/source/core/drivers/remoteproc/stm32_remoteproc.c#L64
If driver does not register the proc ID an error is returned indicating that the
feature is not supported.
In case of stm32mp1 yes we could consider it as useless as we have only one
remote proc.
Nevertheless I can not guaranty that a customer will not add an external
companion processor that uses OP-TEE to authenticate the associated firmware. As
the trusted Application is the unique entry point. he will need the proc_id to
identify the target at PTA level.
So from my point of view having a proc ID on stm32MP1 (and on stm32mp2 that will
reuse same driver) aligned between Linux and OP-TEE is useful.
That said using a TEE_REMOTEPROC_DEFAULT_ID is something that could be
more generic (for linux and OP-TEE). This ID could be reuse in the stm32mp
driver and platform drivers with an unique internal remote processor.
It that solution would be ok for you?
Regards,
Arnaud
>
>>
>>>
>>>> +#define STM32_MP1_M4_PROC_ID 0
>>>> +
>>>> struct stm32_syscon {
>>>> struct regmap *map;
>>>> u32 reg;
>>>> @@ -257,6 +261,19 @@ static int stm32_rproc_release(struct rproc *rproc)
>>>> return 0;
>>>> }
>>>>
>>>> +static int stm32_rproc_tee_stop(struct rproc *rproc)
>>>> +{
>>>> + int err;
>>>> +
>>>> + stm32_rproc_request_shutdown(rproc);
>>>> +
>>>> + err = tee_rproc_stop(rproc);
>>>> + if (err)
>>>> + return err;
>>>> +
>>>> + return stm32_rproc_release(rproc);
>>>> +}
>>>> +
>>>> static int stm32_rproc_prepare(struct rproc *rproc)
>>>> {
>>>> struct device *dev = rproc->dev.parent;
>>>> @@ -693,8 +710,19 @@ static const struct rproc_ops st_rproc_ops = {
>>>> .get_boot_addr = rproc_elf_get_boot_addr,
>>>> };
>>>>
>>>> +static const struct rproc_ops st_rproc_tee_ops = {
>>>> + .prepare = stm32_rproc_prepare,
>>>> + .start = tee_rproc_start,
>>>> + .stop = stm32_rproc_tee_stop,
>>>> + .kick = stm32_rproc_kick,
>>>> + .load = tee_rproc_load_fw,
>>>> + .parse_fw = tee_rproc_parse_fw,
>>>> + .find_loaded_rsc_table = tee_rproc_find_loaded_rsc_table,
>>>> +};
>>>> +
>>>> static const struct of_device_id stm32_rproc_match[] = {
>>>> - { .compatible = "st,stm32mp1-m4" },
>>>> + {.compatible = "st,stm32mp1-m4",},
>>>> + {.compatible = "st,stm32mp1-m4-tee",},
>>>> {},
>>>> };
>>>> MODULE_DEVICE_TABLE(of, stm32_rproc_match);
>>>> @@ -853,6 +881,7 @@ static int stm32_rproc_probe(struct platform_device *pdev)
>>>> struct device *dev = &pdev->dev;
>>>> struct stm32_rproc *ddata;
>>>> struct device_node *np = dev->of_node;
>>>> + struct tee_rproc *trproc = NULL;
>>>> struct rproc *rproc;
>>>> unsigned int state;
>>>> int ret;
>>>> @@ -861,9 +890,26 @@ static int stm32_rproc_probe(struct platform_device *pdev)
>>>> if (ret)
>>>> return ret;
>>>>
>>>> - rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
>>>> - if (!rproc)
>>>> - return -ENOMEM;
>>>> + if (of_device_is_compatible(np, "st,stm32mp1-m4-tee")) {
>>>> + /*
>>>> + * Delegate the firmware management to the secure context.
>>>> + * The firmware loaded has to be signed.
>>>> + */
>>>> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_tee_ops, NULL, sizeof(*ddata));
>>>> + if (!rproc)
>>>> + return -ENOMEM;
>>>> +
>>>> + trproc = tee_rproc_register(dev, rproc, STM32_MP1_M4_PROC_ID);
>>>> + if (IS_ERR(trproc)) {
>>>> + dev_err_probe(dev, PTR_ERR(trproc),
>>>> + "signed firmware not supported by TEE\n");
>>>> + return PTR_ERR(trproc);
>>>> + }
>>>> + } else {
>>>> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
>>>> + if (!rproc)
>>>> + return -ENOMEM;
>>>> + }
>>>>
>>>> ddata = rproc->priv;
>>>>
>>>> @@ -915,6 +961,9 @@ static int stm32_rproc_probe(struct platform_device *pdev)
>>>> dev_pm_clear_wake_irq(dev);
>>>> device_init_wakeup(dev, false);
>>>> }
>>>> + if (trproc)
>>>
>>> if (rproc->tee_interface)
>>>
>>>
>>> I am done reviewing this set.
>>
>> Thank for your review!
>> Arnaud
>>
>>>
>>> Thanks,
>>> Mathieu
>>>
>>>> + tee_rproc_unregister(trproc);
>>>> +
>>>> return ret;
>>>> }
>>>>
>>>> @@ -935,6 +984,9 @@ static void stm32_rproc_remove(struct platform_device *pdev)
>>>> dev_pm_clear_wake_irq(dev);
>>>> device_init_wakeup(dev, false);
>>>> }
>>>> + if (rproc->tee_interface)
>>>> + tee_rproc_unregister(rproc->tee_interface);
>>>> +
>>>> }
>>>>
>>>> static int stm32_rproc_suspend(struct device *dev)
>>>> --
>>>> 2.25.1
>>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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