* [PATCH v5 00/14] riscv: support for svpbmt and D1 memory types
From: Heiko Stuebner @ 2022-01-21 16:36 UTC (permalink / raw)
To: palmer, paul.walmsley, aou
Cc: linux-riscv, devicetree, linux-kernel, robh+dt, wefu, liush,
guoren, atishp, anup, drew, hch, arnd, wens, maxime, dlustig,
gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick,
allen.baum, jscheid, rtrauben, samuel, cmuellner, philipp.tomsich,
Heiko Stuebner
So this is my try at implementing svpbmt (and the diverging D1 memory
types using the alternatives framework).
This includes a number of changes to the alternatives mechanism itself.
The biggest one being the move to a more central location, as I expect
in the future, nearly every chip needing some sort of patching, be it
either for erratas or for optional features (svpbmt or others).
The dt-binding for svpbmt itself is of course not finished and is still
using the binding introduced in previous versions, as where to put
a svpbmt-property in the devicetree is still under dicussion.
Atish seems to be working on a framework for extensions [0],
The series also introduces support for the memory types of the D1
which are implemented differently to svpbmt. But when patching anyway
it's pretty clean to add the D1 variant via ALTERNATIVE_2 to the same
location.
The only slightly bigger difference is that the "normal" type is not 0
as with svpbmt, so kernel patches for this PMA type need to be applied
even before the MMU is brought up, so the series introduces a separate
stage for that.
In theory this series is 3 parts:
- sbi cache-flush / null-ptr
- alternatives improvements
- svpbmt+d1
So expecially patches from the first 2 areas could be applied when
deemed ready, I just thought to keep it together to show-case where
the end-goal is and not requiring jumping between different series.
The sbi cache-flush patch is based on Atish's sparse-hartid patch [1],
as it touches a similar area in mm/cacheflush.c
I picked the recipient list from the previous version, hopefully
I didn't forget anybody.
[0] https://lore.kernel.org/r/20211224211632.1698523-1-atishp@rivosinc.com
[1] https://lore.kernel.org/r/20220120090918.2646626-1-atishp@rivosinc.com
Heiko Stuebner (12):
riscv: only use IPIs to handle cache-flushes on remote cpus
riscv: integrate alternatives better into the main architecture
riscv: allow different stages with alternatives
riscv: implement module alternatives
riscv: implement ALTERNATIVE_2 macro
riscv: extend concatenated alternatives-lines to the same length
riscv: prevent compressed instructions in alternatives
riscv: move boot alternatives to a slightly earlier position
riscv: Fix accessing pfn bits in PTEs for non-32bit variants
riscv: add cpufeature handling via alternatives
riscv: remove FIXMAP_PAGE_IO and fall back to its default value
riscv: add memory-type errata for T-Head
Wei Fu (2):
dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt
riscv: add RISC-V Svpbmt extension supports
.../devicetree/bindings/riscv/cpus.yaml | 10 ++
arch/riscv/Kconfig.erratas | 29 ++--
arch/riscv/Kconfig.socs | 1 -
arch/riscv/Makefile | 2 +-
arch/riscv/errata/Makefile | 2 +-
arch/riscv/errata/sifive/errata.c | 10 +-
arch/riscv/errata/thead/Makefile | 1 +
arch/riscv/errata/thead/errata.c | 85 +++++++++++
arch/riscv/include/asm/alternative-macros.h | 114 ++++++++-------
arch/riscv/include/asm/alternative.h | 16 ++-
arch/riscv/include/asm/errata_list.h | 52 +++++++
arch/riscv/include/asm/fixmap.h | 2 -
arch/riscv/include/asm/pgtable-32.h | 17 +++
arch/riscv/include/asm/pgtable-64.h | 79 +++++++++-
arch/riscv/include/asm/pgtable-bits.h | 10 --
arch/riscv/include/asm/pgtable.h | 53 +++++--
arch/riscv/include/asm/vendorid_list.h | 1 +
arch/riscv/kernel/Makefile | 1 +
arch/riscv/{errata => kernel}/alternative.c | 47 +++++-
arch/riscv/kernel/cpufeature.c | 136 +++++++++++++++++-
arch/riscv/kernel/head.S | 2 +
arch/riscv/kernel/module.c | 29 ++++
arch/riscv/kernel/smpboot.c | 4 -
arch/riscv/kernel/traps.c | 2 +-
arch/riscv/mm/cacheflush.c | 8 +-
arch/riscv/mm/init.c | 2 +
26 files changed, 599 insertions(+), 116 deletions(-)
create mode 100644 arch/riscv/errata/thead/Makefile
create mode 100644 arch/riscv/errata/thead/errata.c
rename arch/riscv/{errata => kernel}/alternative.c (60%)
--
2.30.2
^ permalink raw reply
* [PATCH v5 01/14] riscv: only use IPIs to handle cache-flushes on remote cpus
From: Heiko Stuebner @ 2022-01-21 16:36 UTC (permalink / raw)
To: palmer, paul.walmsley, aou
Cc: linux-riscv, devicetree, linux-kernel, robh+dt, wefu, liush,
guoren, atishp, anup, drew, hch, arnd, wens, maxime, dlustig,
gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick,
allen.baum, jscheid, rtrauben, samuel, cmuellner, philipp.tomsich,
Heiko Stuebner
In-Reply-To: <20220121163618.351934-1-heiko@sntech.de>
Right now, the flush_icache functions always use the SBI remote-fence
when SBI is available, leaving using IPIs as a fallback mechanism.
IPIs on the other hand are more flexible, as the ipi_ops are initially
set to go through SBI but later will be overwritten to go through the
ACLINT/CLINT.
In a discussion we had, Nick was of the opinion that "In general we
should prefer doing IPIs on S-mode through CLINT instead of going
through SBI/M-mode, so IMHO we should only be using
on_each_cpu_mask(ipi_remote_fence_i) on flush_icache_all()/
flush_icache_mm() and remove any explicit calls to sbi_remote_fence_i(),
because this way we continue using SBI for doing remote fences even after
CLINT/ACLINT driver is registered, instead of using direct IPIs through
CLINT/ACLINT."
So follow this suggestion and just do ipi calls to have the proper kernel
parts do them,
This also fixes the null-ptr dereference happening when flush_icache_all()
is called before sbi_init().
Suggested-by: Nick Kossifidis <mick@ics.forth.gr>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/riscv/mm/cacheflush.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
index 6cb7d96ad9c7..c35375cd52ec 100644
--- a/arch/riscv/mm/cacheflush.c
+++ b/arch/riscv/mm/cacheflush.c
@@ -17,11 +17,7 @@ static void ipi_remote_fence_i(void *info)
void flush_icache_all(void)
{
local_flush_icache_all();
-
- if (IS_ENABLED(CONFIG_RISCV_SBI))
- sbi_remote_fence_i(NULL);
- else
- on_each_cpu(ipi_remote_fence_i, NULL, 1);
+ on_each_cpu(ipi_remote_fence_i, NULL, 1);
}
EXPORT_SYMBOL(flush_icache_all);
@@ -66,8 +62,6 @@ void flush_icache_mm(struct mm_struct *mm, bool local)
* with flush_icache_deferred().
*/
smp_mb();
- } else if (IS_ENABLED(CONFIG_RISCV_SBI)) {
- sbi_remote_fence_i(&others);
} else {
on_each_cpu_mask(&others, ipi_remote_fence_i, NULL, 1);
}
--
2.30.2
^ permalink raw reply related
* [PATCH v5 08/14] riscv: move boot alternatives to a slightly earlier position
From: Heiko Stuebner @ 2022-01-21 16:36 UTC (permalink / raw)
To: palmer, paul.walmsley, aou
Cc: linux-riscv, devicetree, linux-kernel, robh+dt, wefu, liush,
guoren, atishp, anup, drew, hch, arnd, wens, maxime, dlustig,
gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick,
allen.baum, jscheid, rtrauben, samuel, cmuellner, philipp.tomsich,
Heiko Stuebner
In-Reply-To: <20220121163618.351934-1-heiko@sntech.de>
Move the application of boot alternatives to soc_early_init().
This allows to catch more generic cases of code needing patches
than doing it in smp_prepare_boot_cpu() and also makes it actually
work if CONFIG_SMP is disabled for whatever reason.
The position is chosen mainly as it is before the actual soc early
init runs but also already allows accessing the devicetree
via fdt_* functions.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/riscv/kernel/head.S | 2 ++
arch/riscv/kernel/smpboot.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index db062279d9ed..432fe7b3f897 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -10,6 +10,7 @@
#include <asm/thread_info.h>
#include <asm/page.h>
#include <asm/pgtable.h>
+#include <asm/alternative.h>
#include <asm/csr.h>
#include <asm/cpu_ops_sbi.h>
#include <asm/hwcap.h>
@@ -341,6 +342,7 @@ clear_bss_done:
call kasan_early_init
#endif
/* Start the kernel */
+ call apply_boot_alternatives
call soc_early_init
tail start_kernel
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index a6d13dca1403..f1e4948a4b52 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -32,7 +32,6 @@
#include <asm/sections.h>
#include <asm/sbi.h>
#include <asm/smp.h>
-#include <asm/alternative.h>
#include "head.h"
@@ -41,7 +40,6 @@ static DECLARE_COMPLETION(cpu_running);
void __init smp_prepare_boot_cpu(void)
{
init_cpu_topology();
- apply_boot_alternatives();
}
void __init smp_prepare_cpus(unsigned int max_cpus)
--
2.30.2
^ permalink raw reply related
* [PATCH v5 04/14] riscv: implement module alternatives
From: Heiko Stuebner @ 2022-01-21 16:36 UTC (permalink / raw)
To: palmer, paul.walmsley, aou
Cc: linux-riscv, devicetree, linux-kernel, robh+dt, wefu, liush,
guoren, atishp, anup, drew, hch, arnd, wens, maxime, dlustig,
gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick,
allen.baum, jscheid, rtrauben, samuel, cmuellner, philipp.tomsich,
Heiko Stuebner
In-Reply-To: <20220121163618.351934-1-heiko@sntech.de>
This allows alternatives to also be applied when loading modules
and follows the implementation of other architectures (e.g. arm64).
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/riscv/include/asm/alternative.h | 3 ++-
arch/riscv/kernel/alternative.c | 16 ++++++++++++---
arch/riscv/kernel/module.c | 29 ++++++++++++++++++++++++++++
3 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/include/asm/alternative.h b/arch/riscv/include/asm/alternative.h
index 811bdd8027db..f0657b1b3174 100644
--- a/arch/riscv/include/asm/alternative.h
+++ b/arch/riscv/include/asm/alternative.h
@@ -18,8 +18,10 @@
#include <asm/hwcap.h>
#define RISCV_ALTERNATIVES_BOOT 0 /* alternatives applied during regular boot */
+#define RISCV_ALTERNATIVES_MODULE 1 /* alternatives applied during module-init */
void __init apply_boot_alternatives(void);
+void apply_module_alternatives(void *start, size_t length);
struct alt_entry {
void *old_ptr; /* address of original instruciton or data */
@@ -37,6 +39,5 @@ struct errata_checkfunc_id {
void sifive_errata_patch_func(struct alt_entry *begin, struct alt_entry *end,
unsigned long archid, unsigned long impid,
unsigned int stage);
-
#endif
#endif
diff --git a/arch/riscv/kernel/alternative.c b/arch/riscv/kernel/alternative.c
index ead00c508266..e1849faa2fa1 100644
--- a/arch/riscv/kernel/alternative.c
+++ b/arch/riscv/kernel/alternative.c
@@ -7,6 +7,7 @@
*/
#include <linux/init.h>
+#include <linux/module.h>
#include <linux/cpu.h>
#include <linux/uaccess.h>
#include <asm/alternative.h>
@@ -58,9 +59,9 @@ static void __init init_alternative(void)
* a feature detect on the boot CPU). No need to worry about other CPUs
* here.
*/
-static void __init _apply_alternatives(struct alt_entry *begin,
- struct alt_entry *end,
- unsigned int stage)
+static void __init_or_module _apply_alternatives(struct alt_entry *begin,
+ struct alt_entry *end,
+ unsigned int stage)
{
if (!vendor_patch_func)
return;
@@ -81,3 +82,12 @@ void __init apply_boot_alternatives(void)
(struct alt_entry *)__alt_end,
RISCV_ALTERNATIVES_BOOT);
}
+
+#ifdef CONFIG_MODULES
+void apply_module_alternatives(void *start, size_t length)
+{
+ _apply_alternatives((struct alt_entry *)start,
+ (struct alt_entry *)(start + length),
+ RISCV_ALTERNATIVES_MODULE);
+}
+#endif
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 68a9e3d1fe16..a778abd5b8b9 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -11,6 +11,7 @@
#include <linux/vmalloc.h>
#include <linux/sizes.h>
#include <linux/pgtable.h>
+#include <asm/alternative.h>
#include <asm/sections.h>
static int apply_r_riscv_32_rela(struct module *me, u32 *location, Elf_Addr v)
@@ -416,3 +417,31 @@ void *module_alloc(unsigned long size)
__builtin_return_address(0));
}
#endif
+
+static const Elf_Shdr *find_section(const Elf_Ehdr *hdr,
+ const Elf_Shdr *sechdrs,
+ const char *name)
+{
+ const Elf_Shdr *s, *se;
+ const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
+
+ for (s = sechdrs, se = sechdrs + hdr->e_shnum; s < se; s++) {
+ if (strcmp(name, secstrs + s->sh_name) == 0)
+ return s;
+ }
+
+ return NULL;
+}
+
+int module_finalize(const Elf_Ehdr *hdr,
+ const Elf_Shdr *sechdrs,
+ struct module *me)
+{
+ const Elf_Shdr *s;
+
+ s = find_section(hdr, sechdrs, ".alternative");
+ if (s)
+ apply_module_alternatives((void *)s->sh_addr, s->sh_size);
+
+ return 0;
+}
--
2.30.2
^ permalink raw reply related
* [PATCH v5 02/14] riscv: integrate alternatives better into the main architecture
From: Heiko Stuebner @ 2022-01-21 16:36 UTC (permalink / raw)
To: palmer, paul.walmsley, aou
Cc: linux-riscv, devicetree, linux-kernel, robh+dt, wefu, liush,
guoren, atishp, anup, drew, hch, arnd, wens, maxime, dlustig,
gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick,
allen.baum, jscheid, rtrauben, samuel, cmuellner, philipp.tomsich,
Heiko Stuebner
In-Reply-To: <20220121163618.351934-1-heiko@sntech.de>
Right now the alternatives need to be explicitly enabled and
erratas are limited to SiFive ones.
Over time with more SoCs and additional RiscV extensions, many more
erratas or other patch-worthy features will emerge, so it doesn't
really make sense to have the core alternatives able to get
deactivated.
So make it part of the core RiscV kernel and drop the main
RISCV_ERRATA_ALTERNATIVES config symbol.
This also mimics how arm64 handles its alternatives implementation.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/riscv/Kconfig.erratas | 10 ----------
arch/riscv/Kconfig.socs | 1 -
arch/riscv/Makefile | 2 +-
arch/riscv/errata/Makefile | 1 -
arch/riscv/include/asm/alternative-macros.h | 22 ---------------------
arch/riscv/kernel/Makefile | 1 +
arch/riscv/{errata => kernel}/alternative.c | 0
arch/riscv/kernel/smpboot.c | 2 --
arch/riscv/kernel/traps.c | 2 +-
9 files changed, 3 insertions(+), 38 deletions(-)
rename arch/riscv/{errata => kernel}/alternative.c (100%)
diff --git a/arch/riscv/Kconfig.erratas b/arch/riscv/Kconfig.erratas
index b44d6ecdb46e..d18be8ff0245 100644
--- a/arch/riscv/Kconfig.erratas
+++ b/arch/riscv/Kconfig.erratas
@@ -1,17 +1,7 @@
menu "CPU errata selection"
-config RISCV_ERRATA_ALTERNATIVE
- bool "RISC-V alternative scheme"
- default y
- help
- This Kconfig allows the kernel to automatically patch the
- errata required by the execution platform at run time. The
- code patching is performed once in the boot stages. It means
- that the overhead from this mechanism is just taken once.
-
config ERRATA_SIFIVE
bool "SiFive errata"
- depends on RISCV_ERRATA_ALTERNATIVE
help
All SiFive errata Kconfig depend on this Kconfig. Disabling
this Kconfig will disable all SiFive errata. Please say "Y"
diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 6ec44a22278a..3df7f7ed0d81 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -14,7 +14,6 @@ config SOC_SIFIVE
select CLK_SIFIVE
select CLK_SIFIVE_PRCI
select SIFIVE_PLIC
- select RISCV_ERRATA_ALTERNATIVE
select ERRATA_SIFIVE
help
This enables support for SiFive SoC platform hardware.
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 8a107ed18b0d..194220889969 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -97,7 +97,7 @@ endif
head-y := arch/riscv/kernel/head.o
-core-$(CONFIG_RISCV_ERRATA_ALTERNATIVE) += arch/riscv/errata/
+core-y += arch/riscv/errata/
core-$(CONFIG_KVM) += arch/riscv/kvm/
libs-y += arch/riscv/lib/
diff --git a/arch/riscv/errata/Makefile b/arch/riscv/errata/Makefile
index b8f8740a3e44..0ca1c5281a2d 100644
--- a/arch/riscv/errata/Makefile
+++ b/arch/riscv/errata/Makefile
@@ -1,2 +1 @@
-obj-y += alternative.o
obj-$(CONFIG_ERRATA_SIFIVE) += sifive/
diff --git a/arch/riscv/include/asm/alternative-macros.h b/arch/riscv/include/asm/alternative-macros.h
index 67406c376389..92da6b3920a3 100644
--- a/arch/riscv/include/asm/alternative-macros.h
+++ b/arch/riscv/include/asm/alternative-macros.h
@@ -2,8 +2,6 @@
#ifndef __ASM_ALTERNATIVE_MACROS_H
#define __ASM_ALTERNATIVE_MACROS_H
-#ifdef CONFIG_RISCV_ERRATA_ALTERNATIVE
-
#ifdef __ASSEMBLY__
.macro ALT_ENTRY oldptr newptr vendor_id errata_id new_len
@@ -76,26 +74,6 @@
#endif /* __ASSEMBLY__ */
-#else /* !CONFIG_RISCV_ERRATA_ALTERNATIVE*/
-#ifdef __ASSEMBLY__
-
-.macro __ALTERNATIVE_CFG old_c
- \old_c
-.endm
-
-#define _ALTERNATIVE_CFG(old_c, new_c, vendor_id, errata_id, CONFIG_k) \
- __ALTERNATIVE_CFG old_c
-
-#else /* !__ASSEMBLY__ */
-
-#define __ALTERNATIVE_CFG(old_c) \
- old_c "\n"
-
-#define _ALTERNATIVE_CFG(old_c, new_c, vendor_id, errata_id, CONFIG_k) \
- __ALTERNATIVE_CFG(old_c)
-
-#endif /* __ASSEMBLY__ */
-#endif /* CONFIG_RISCV_ERRATA_ALTERNATIVE */
/*
* Usage:
* ALTERNATIVE(old_content, new_content, vendor_id, errata_id, CONFIG_k)
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index fb63b462ff85..62d6860af574 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -18,6 +18,7 @@ extra-y += head.o
extra-y += vmlinux.lds
obj-y += soc.o
+obj-y += alternative.o
obj-y += cpu.o
obj-y += cpufeature.o
obj-y += entry.o
diff --git a/arch/riscv/errata/alternative.c b/arch/riscv/kernel/alternative.c
similarity index 100%
rename from arch/riscv/errata/alternative.c
rename to arch/riscv/kernel/alternative.c
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 622f226454d5..a6d13dca1403 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -41,9 +41,7 @@ static DECLARE_COMPLETION(cpu_running);
void __init smp_prepare_boot_cpu(void)
{
init_cpu_topology();
-#ifdef CONFIG_RISCV_ERRATA_ALTERNATIVE
apply_boot_alternatives();
-#endif
}
void __init smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index 0daaa3e4630d..18869912d23d 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -86,7 +86,7 @@ static void do_trap_error(struct pt_regs *regs, int signo, int code,
}
}
-#if defined (CONFIG_XIP_KERNEL) && defined (CONFIG_RISCV_ERRATA_ALTERNATIVE)
+#if defined (CONFIG_XIP_KERNEL)
#define __trap_section __section(".xip.traps")
#else
#define __trap_section
--
2.30.2
^ permalink raw reply related
* [PATCH v5 05/14] riscv: implement ALTERNATIVE_2 macro
From: Heiko Stuebner @ 2022-01-21 16:36 UTC (permalink / raw)
To: palmer, paul.walmsley, aou
Cc: linux-riscv, devicetree, linux-kernel, robh+dt, wefu, liush,
guoren, atishp, anup, drew, hch, arnd, wens, maxime, dlustig,
gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick,
allen.baum, jscheid, rtrauben, samuel, cmuellner, philipp.tomsich,
Heiko Stuebner
In-Reply-To: <20220121163618.351934-1-heiko@sntech.de>
When the alternatives were added the commit already provided a template
on how to implement 2 different alternatives for one piece of code.
Make this usable.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/riscv/include/asm/alternative-macros.h | 52 +++++++++++++--------
1 file changed, 32 insertions(+), 20 deletions(-)
diff --git a/arch/riscv/include/asm/alternative-macros.h b/arch/riscv/include/asm/alternative-macros.h
index 92da6b3920a3..baf649293288 100644
--- a/arch/riscv/include/asm/alternative-macros.h
+++ b/arch/riscv/include/asm/alternative-macros.h
@@ -37,6 +37,20 @@
#define _ALTERNATIVE_CFG(old_c, new_c, vendor_id, errata_id, CONFIG_k) \
__ALTERNATIVE_CFG old_c, new_c, vendor_id, errata_id, IS_ENABLED(CONFIG_k)
+.macro __ALTERNATIVE_CFG_2 old_c, new_c_1, vendor_id_1, errata_id_1, enable_1, \
+ new_c_2, vendor_id_2, errata_id_2, enable_2
+886 :
+ \old_c
+887 :
+ ALT_NEW_CONTENT \vendor_id_1, \errata_id_1, \enable_1, \new_c_1
+ ALT_NEW_CONTENT \vendor_id_2, \errata_id_2, \enable_2, \new_c_2
+.endm
+
+#define _ALTERNATIVE_CFG_2(old_c, new_c_1, vendor_id_1, errata_id_1, CONFIG_k_1, \
+ new_c_2, vendor_id_2, errata_id_2, CONFIG_k_2) \
+ __ALTERNATIVE_CFG_2 old_c, new_c_1, vendor_id_1, errata_id_1, IS_ENABLED(CONFIG_k_1), \
+ new_c_2, vendor_id_2, errata_id_2, IS_ENABLED(CONFIG_k_2)
+
#else /* !__ASSEMBLY__ */
#include <asm/asm.h>
@@ -72,6 +86,19 @@
#define _ALTERNATIVE_CFG(old_c, new_c, vendor_id, errata_id, CONFIG_k) \
__ALTERNATIVE_CFG(old_c, new_c, vendor_id, errata_id, IS_ENABLED(CONFIG_k))
+#define __ALTERNATIVE_CFG_2(old_c, new_c_1, vendor_id_1, errata_id_1, enable_1, \
+ new_c_2, vendor_id_2, errata_id_2, enable_2) \
+ "886 :\n" \
+ old_c "\n" \
+ "887 :\n" \
+ ALT_NEW_CONTENT(vendor_id_1, errata_id_1, enable_1, new_c_1) \
+ ALT_NEW_CONTENT(vendor_id_2, errata_id_2, enable_2, new_c_2)
+
+#define _ALTERNATIVE_CFG_2(old_c, new_c_1, vendor_id_1, errata_id_1, CONFIG_k_1, \
+ new_c_2, vendor_id_2, errata_id_2, CONFIG_k_2) \
+ __ALTERNATIVE_CFG_2(old_c, new_c_1, vendor_id_1, errata_id_1, IS_ENABLED(CONFIG_k_1), \
+ new_c_2, vendor_id_2, errata_id_2, IS_ENABLED(CONFIG_k_2))
+
#endif /* __ASSEMBLY__ */
/*
@@ -96,25 +123,10 @@
* this case, this vendor can create a new macro ALTERNATIVE_2() based
* on the following sample code and then replace ALTERNATIVE() with
* ALTERNATIVE_2() to append its customized content.
- *
- * .macro __ALTERNATIVE_CFG_2 old_c, new_c_1, vendor_id_1, errata_id_1, enable_1, \
- * new_c_2, vendor_id_2, errata_id_2, enable_2
- * 886 :
- * \old_c
- * 887 :
- * ALT_NEW_CONTENT \vendor_id_1, \errata_id_1, \enable_1, \new_c_1
- * ALT_NEW_CONTENT \vendor_id_2, \errata_id_2, \enable_2, \new_c_2
- * .endm
- *
- * #define _ALTERNATIVE_CFG_2(old_c, new_c_1, vendor_id_1, errata_id_1, CONFIG_k_1, \
- * new_c_2, vendor_id_2, errata_id_2, CONFIG_k_2) \
- * __ALTERNATIVE_CFG_2 old_c, new_c_1, vendor_id_1, errata_id_1, IS_ENABLED(CONFIG_k_1), \
- * new_c_2, vendor_id_2, errata_id_2, IS_ENABLED(CONFIG_k_2) \
- *
- * #define ALTERNATIVE_2(old_content, new_content_1, vendor_id_1, errata_id_1, CONFIG_k_1, \
- * new_content_2, vendor_id_2, errata_id_2, CONFIG_k_2) \
- * _ALTERNATIVE_CFG_2(old_content, new_content_1, vendor_id_1, errata_id_1, CONFIG_k_1, \
- * new_content_2, vendor_id_2, errata_id_2, CONFIG_k_2)
- *
*/
+#define ALTERNATIVE_2(old_content, new_content_1, vendor_id_1, errata_id_1, CONFIG_k_1, \
+ new_content_2, vendor_id_2, errata_id_2, CONFIG_k_2) \
+ _ALTERNATIVE_CFG_2(old_content, new_content_1, vendor_id_1, errata_id_1, CONFIG_k_1, \
+ new_content_2, vendor_id_2, errata_id_2, CONFIG_k_2)
+
#endif
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v5 3/3] mmc: mediatek: add support for SDIO eint IRQ
From: Andy Shevchenko @ 2022-01-21 16:25 UTC (permalink / raw)
To: Axe Yang
Cc: Ulf Hansson, Rob Herring, Chaotian Jing, Matthias Brugger,
Adrian Hunter, Yoshihiro Shimoda, Satya Tangirala, Wolfram Sang,
Lucas Stach, Eric Biggers, Andrew Jeffery, Stephen Boyd,
Kiwoong Kim, Yue Hu, Tian Tao, angelogioacchino.delregno,
linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Yong Mao
In-Reply-To: <20220121071942.11601-4-axe.yang@mediatek.com>
On Fri, Jan 21, 2022 at 03:19:42PM +0800, Axe Yang wrote:
> Add support for eint IRQ when MSDC is used as an SDIO host. This
> feature requires SDIO device support async IRQ function. With this
> feature, SDIO host can be awakened by SDIO card in suspend state,
> without additional pin.
>
> MSDC driver will time-share the SDIO DAT1 pin. During suspend, MSDC
> turn off clock and switch SDIO DAT1 pin to GPIO mode. And during
> resume, switch GPIO function back to DAT1 mode then turn on clock.
>
> Some device tree property should be added or modified in MSDC node
> to support SDIO eint IRQ. Pinctrls named state_dat1 and state_eint
> are mandatory. And cap-sdio-async-irq flag is necessary since this
> feature depends on asynchronous interrupt:
> &mmcX {
> ...
> pinctrl-names = "default", "state_uhs", "state_eint",
> "state_dat1";
> ...
> pinctrl-2 = <&mmc2_pins_eint>;
> pinctrl-3 = <&mmc2_pins_dat1>;
> ...
> cap-sdio-async-irq;
> ...
> };
LGTM, so FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Co-developed-by: Yong Mao <yong.mao@mediatek.com>
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> Signed-off-by: Axe Yang <axe.yang@mediatek.com>
> ---
> drivers/mmc/host/mtk-sd.c | 123 +++++++++++++++++++++++++++++++++++---
> 1 file changed, 115 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 65037e1d7723..f8e38228d810 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> - * Copyright (c) 2014-2015 MediaTek Inc.
> + * Copyright (c) 2014-2015, 2022 MediaTek Inc.
> * Author: Chaotian.Jing <chaotian.jing@mediatek.com>
> */
>
> @@ -9,6 +9,7 @@
> #include <linux/clk.h>
> #include <linux/delay.h>
> #include <linux/dma-mapping.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/iopoll.h>
> #include <linux/ioport.h>
> #include <linux/irq.h>
> @@ -440,8 +441,12 @@ struct msdc_host {
> struct pinctrl *pinctrl;
> struct pinctrl_state *pins_default;
> struct pinctrl_state *pins_uhs;
> + struct pinctrl_state *pins_eint;
> + struct pinctrl_state *pins_dat1;
> struct delayed_work req_timeout;
> int irq; /* host interrupt */
> + int eint_irq; /* device interrupt */
> + int sdio_irq_cnt; /* irq enable cnt */
> struct reset_control *reset;
>
> struct clk *src_clk; /* msdc source clock */
> @@ -465,6 +470,7 @@ struct msdc_host {
> bool hs400_tuning; /* hs400 mode online tuning */
> bool internal_cd; /* Use internal card-detect logic */
> bool cqhci; /* support eMMC hw cmdq */
> + bool sdio_eint_ready; /* Ready to support SDIO eint interrupt */
> struct msdc_save_para save_para; /* used when gate HCLK */
> struct msdc_tune_para def_tune_para; /* default tune setting */
> struct msdc_tune_para saved_tune_para; /* tune result of CMD21/CMD19 */
> @@ -1527,10 +1533,12 @@ static void msdc_enable_sdio_irq(struct mmc_host *mmc, int enb)
> __msdc_enable_sdio_irq(host, enb);
> spin_unlock_irqrestore(&host->lock, flags);
>
> - if (enb)
> - pm_runtime_get_noresume(host->dev);
> - else
> - pm_runtime_put_noidle(host->dev);
> + if (mmc->card && !mmc->card->cccr.enable_async_irq) {
> + if (enb)
> + pm_runtime_get_noresume(host->dev);
> + else
> + pm_runtime_put_noidle(host->dev);
> + }
> }
>
> static irqreturn_t msdc_cmdq_irq(struct msdc_host *host, u32 intsts)
> @@ -2461,6 +2469,48 @@ static const struct mmc_host_ops mt_msdc_ops = {
> .hw_reset = msdc_hw_reset,
> };
>
> +static irqreturn_t msdc_sdio_eint_irq(int irq, void *dev_id)
> +{
> + struct msdc_host *host = dev_id;
> + struct mmc_host *mmc = mmc_from_priv(host);
> +
> + spin_lock(&host->lock);
> + if (likely(host->sdio_irq_cnt > 0)) {
> + disable_irq_nosync(host->eint_irq);
> + disable_irq_wake(host->eint_irq);
> + host->sdio_irq_cnt--;
> + }
> + spin_unlock(&host->lock);
> +
> + sdio_signal_irq(mmc);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int msdc_request_dat1_eint_irq(struct msdc_host *host)
> +{
> + struct gpio_desc *desc;
> + int irq, ret;
> +
> + desc = devm_gpiod_get(host->dev, "eint", GPIOD_IN);
> + if (IS_ERR(desc))
> + return PTR_ERR(desc);
> +
> + irq = gpiod_to_irq(desc);
> + if (irq < 0)
> + return irq;
> +
> + ret = devm_request_threaded_irq(host->dev, irq, NULL, msdc_sdio_eint_irq,
> + IRQF_TRIGGER_LOW | IRQF_ONESHOT | IRQF_NO_AUTOEN,
> + "sdio-eint", host);
> + if (ret)
> + return ret;
> +
> + host->eint_irq = irq;
> +
> + return 0;
> +}
> +
> static const struct cqhci_host_ops msdc_cmdq_ops = {
> .enable = msdc_cqe_enable,
> .disable = msdc_cqe_disable,
> @@ -2631,6 +2681,23 @@ static int msdc_drv_probe(struct platform_device *pdev)
> goto host_free;
> }
>
> + if (!(mmc->caps2 & MMC_CAP2_NO_SDIO) && (mmc->caps2 & MMC_CAP2_SDIO_ASYNC_IRQ)) {
> + /* Support for SDIO eint irq */
> + host->pins_eint = pinctrl_lookup_state(host->pinctrl, "state_eint");
> + if (IS_ERR(host->pins_eint)) {
> + dev_dbg(&pdev->dev, "Cannot find pinctrl eint!\n");
> + } else {
> + host->pins_dat1 = pinctrl_lookup_state(host->pinctrl, "state_dat1");
> + if (IS_ERR(host->pins_dat1)) {
> + ret = dev_err_probe(&pdev->dev, PTR_ERR(host->pins_dat1),
> + "Cannot find pinctrl dat1!\n");
> + goto host_free;
> + }
> +
> + host->sdio_eint_ready = true;
> + }
> + }
> +
> msdc_of_property_parse(pdev, host);
>
> host->dev = &pdev->dev;
> @@ -2722,6 +2789,16 @@ static int msdc_drv_probe(struct platform_device *pdev)
> if (ret)
> goto release;
>
> + if (host->sdio_eint_ready) {
> + ret = msdc_request_dat1_eint_irq(host);
> + if (ret) {
> + dev_err(host->dev, "Failed to register data1 eint irq!\n");
> + goto release;
> + }
> +
> + pinctrl_select_state(host->pinctrl, host->pins_dat1);
> + }
> +
> pm_runtime_set_active(host->dev);
> pm_runtime_set_autosuspend_delay(host->dev, MTK_MMC_AUTOSUSPEND_DELAY);
> pm_runtime_use_autosuspend(host->dev);
> @@ -2843,8 +2920,22 @@ static int __maybe_unused msdc_runtime_suspend(struct device *dev)
> {
> struct mmc_host *mmc = dev_get_drvdata(dev);
> struct msdc_host *host = mmc_priv(mmc);
> + unsigned long flags;
>
> msdc_save_reg(host);
> +
> + if (host->sdio_eint_ready) {
> + disable_irq(host->irq);
> + pinctrl_select_state(host->pinctrl, host->pins_eint);
> + spin_lock_irqsave(&host->lock, flags);
> + if (host->sdio_irq_cnt == 0) {
> + enable_irq(host->eint_irq);
> + enable_irq_wake(host->eint_irq);
> + host->sdio_irq_cnt++;
> + }
> + sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
> + spin_unlock_irqrestore(&host->lock, flags);
> + }
> msdc_gate_clock(host);
> return 0;
> }
> @@ -2853,6 +2944,7 @@ static int __maybe_unused msdc_runtime_resume(struct device *dev)
> {
> struct mmc_host *mmc = dev_get_drvdata(dev);
> struct msdc_host *host = mmc_priv(mmc);
> + unsigned long flags;
> int ret;
>
> ret = msdc_ungate_clock(host);
> @@ -2860,10 +2952,25 @@ static int __maybe_unused msdc_runtime_resume(struct device *dev)
> return ret;
>
> msdc_restore_reg(host);
> +
> + if (host->sdio_eint_ready) {
> + spin_lock_irqsave(&host->lock, flags);
> + if (host->sdio_irq_cnt > 0) {
> + disable_irq_nosync(host->eint_irq);
> + disable_irq_wake(host->eint_irq);
> + host->sdio_irq_cnt--;
> + sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
> + } else {
> + sdr_clr_bits(host->base + MSDC_INTEN, MSDC_INTEN_SDIOIRQ);
> + }
> + spin_unlock_irqrestore(&host->lock, flags);
> + pinctrl_select_state(host->pinctrl, host->pins_uhs);
> + enable_irq(host->irq);
> + }
> return 0;
> }
>
> -static int __maybe_unused msdc_suspend(struct device *dev)
> +static int __maybe_unused msdc_suspend_noirq(struct device *dev)
> {
> struct mmc_host *mmc = dev_get_drvdata(dev);
> int ret;
> @@ -2877,13 +2984,13 @@ static int __maybe_unused msdc_suspend(struct device *dev)
> return pm_runtime_force_suspend(dev);
> }
>
> -static int __maybe_unused msdc_resume(struct device *dev)
> +static int __maybe_unused msdc_resume_noirq(struct device *dev)
> {
> return pm_runtime_force_resume(dev);
> }
>
> static const struct dev_pm_ops msdc_dev_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(msdc_suspend, msdc_resume)
> + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(msdc_suspend_noirq, msdc_resume_noirq)
> SET_RUNTIME_PM_OPS(msdc_runtime_suspend, msdc_runtime_resume, NULL)
> };
>
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* RE: [PATCH v16 2/4] dmaengine: tegra: Add tegra gpcdma driver
From: Akhil R @ 2022-01-21 16:24 UTC (permalink / raw)
To: Dmitry Osipenko, dan.j.williams@intel.com,
devicetree@vger.kernel.org, dmaengine@vger.kernel.org,
Jonathan Hunter, Krishna Yarlagadda, Laxman Dewangan,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
p.zabel@pengutronix.de, Rajesh Gumasta, robh+dt@kernel.org,
thierry.reding@gmail.com, vkoul@kernel.org
Cc: Pavan Kunapuli
In-Reply-To: <683a71b1-049a-bddf-280d-5d5141b59686@gmail.com>
> >>>>> +static int tegra_dma_terminate_all(struct dma_chan *dc)
> >>>>> +{
> >>>>> + struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
> >>>>> + unsigned long flags;
> >>>>> + LIST_HEAD(head);
> >>>>> + int err;
> >>>>> +
> >>>>> + if (tdc->dma_desc) {
> >>>>
> >>>> Needs locking protection against racing with the interrupt handler.
> >>> tegra_dma_stop_client() waits for the in-flight transfer
> >>> to complete and prevents any additional transfer to start.
> >>> Wouldn't it manage the race? Do you see any potential issue there?
> >>
> >> You should consider interrupt handler like a process running in a
> >> parallel thread. The interrupt handler sets tdc->dma_desc to NULL, hence
> >> you'll get NULL dereference in tegra_dma_stop_client().
> >
> > Is it better if I remove the below part from tegra_dma_stop_client() so
> > that dma_desc is not accessed at all?
> >
> > + wcount = tdc_read(tdc, TEGRA_GPCDMA_CHAN_XFER_COUNT);
> > + tdc->dma_desc->bytes_transferred +=
> > + tdc->dma_desc->bytes_requested - (wcount * 4);
> >
> > Because I don't see a point in updating the value there. dma_desc is set
> > to NULL in the next step in terminate_all() anyway.
>
> That isn't going help you much because you also can't release DMA
> descriptor while interrupt handler still may be running and using that
> descriptor.
Does the below functions look good to resolve the issue, provided
tegra_dma_stop_client() doesn't access dma_desc?
+static int tegra_dma_terminate_all(struct dma_chan *dc)
+{
+ struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
+ unsigned long flags;
+ LIST_HEAD(head);
+ int err;
+
+ err = tegra_dma_stop_client(tdc);
+ if (err)
+ return err;
+
+ tegra_dma_stop(tdc);
+
+ spin_lock_irqsave(&tdc->vc.lock, flags);
+ tegra_dma_sid_free(tdc);
+ tdc->dma_desc = NULL;
+
+ vchan_get_all_descriptors(&tdc->vc, &head);
+ spin_unlock_irqrestore(&tdc->vc.lock, flags);
+
+ vchan_dma_desc_free_list(&tdc->vc, &head);
+
+ return 0;
+}
+static irqreturn_t tegra_dma_isr(int irq, void *dev_id)
+{
+ struct tegra_dma_channel *tdc = dev_id;
+ struct tegra_dma_desc *dma_desc = tdc->dma_desc;
+ struct tegra_dma_sg_req *sg_req;
+ u32 status;
+
+ /* Check channel error status register */
+ status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_ERR_STATUS);
+ if (status) {
+ tegra_dma_chan_decode_error(tdc, status);
+ tegra_dma_dump_chan_regs(tdc);
+ tdc_write(tdc, TEGRA_GPCDMA_CHAN_ERR_STATUS, 0xFFFFFFFF);
+ }
+
+ status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_STATUS);
+ if (!(status & TEGRA_GPCDMA_STATUS_ISE_EOC))
+ return IRQ_HANDLED;
+
+ tdc_write(tdc, TEGRA_GPCDMA_CHAN_STATUS,
+ TEGRA_GPCDMA_STATUS_ISE_EOC);
+
+ spin_lock(&tdc->vc.lock);
+ if (!dma_desc)
+ goto irq_done;
+
+ sg_req = dma_desc->sg_req;
+ dma_desc->bytes_transferred += sg_req[dma_desc->sg_idx - 1].len;
+
+ if (dma_desc->sg_idx == dma_desc->sg_count) {
+ tegra_dma_xfer_complete(tdc);
+ } else if (dma_desc->cyclic) {
+ vchan_cyclic_callback(&dma_desc->vd);
+ tegra_dma_configure_next_sg(tdc);
+ } else {
+ tegra_dma_start(tdc);
+ }
+
+irq_done:
+ spin_unlock(&tdc->vc.lock);
+ return IRQ_HANDLED;
+}
Thanks,
Akhil
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: clock: Add R9A07G054 CPG Clock and Reset Definitions
From: Lad, Prabhakar @ 2022-01-21 16:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Lad Prabhakar, Biju Das, Linux-Renesas, Rob Herring,
Linux Kernel Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAMuHMdUbK4BoYo1+L9DF9f12HSuAjR-wfE5GAi2EfftPnCEknA@mail.gmail.com>
Hi Geert,
Thank you for the review.
On Fri, Jan 21, 2022 at 2:45 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar, Biju,
>
> On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
> <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > Define RZ/V2L (R9A07G054) Clock Pulse Generator Core Clock and module
> > clock outputs, as listed in Table 7.1.4.2 ("Clock List r1.0") and also
> > add Reset definitions referring to registers CPG_RST_* in Section 7.2.3
> > ("Register configuration") of the RZ/V2L Hardware User's Manual (Rev.1.00,
> > Nov.2021).
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > Acked-by: Rob Herring <robh@kernel.org>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Before I queue this in renesas-clk-for-v5.18, I'm wondering if you
> want to add the DRP_M, DRP_D, and DRP_A core clocks, too?
>
Good point lets get everything in one shot, I'll send a v2 including
the above core clocks.
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH v4 2/3] spi: dt-bindings: Describe stacked/parallel memories modes
From: Rob Herring @ 2022-01-21 15:54 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
Pratyush Yadav, Michael Walle, linux-mtd, Michal Simek,
Thomas Petazzoni, devicetree, Mark Brown, linux-spi
In-Reply-To: <20211216160226.4fac5ccc@xps13>
On Thu, Dec 16, 2021 at 9:02 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Rob,
>
> robh@kernel.org wrote on Tue, 14 Dec 2021 11:32:56 -0600:
>
> > On Fri, Dec 10, 2021 at 09:10:38PM +0100, Miquel Raynal wrote:
> > > Describe two new memories modes:
> > > - A stacked mode when the bus is common but the address space extended
> > > with an additinals wires.
> > > - A parallel mode with parallel busses accessing parallel flashes where
> > > the data is spread.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> > > .../bindings/spi/spi-peripheral-props.yaml | 29 +++++++++++++++++++
> > > 1 file changed, 29 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > > index 5dd209206e88..4194fee8f556 100644
> > > --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > > +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > > @@ -82,6 +82,35 @@ properties:
> > > description:
> > > Delay, in microseconds, after a write transfer.
> > >
> > > + stacked-memories:
> > > + $ref: /schemas/types.yaml#/definitions/uint64-matrix
> >
> > matrix or...
> >
> > > + description: Several SPI memories can be wired in stacked mode.
> > > + This basically means that either a device features several chip
> > > + selects, or that different devices must be seen as a single
> > > + bigger chip. This basically doubles (or more) the total address
> > > + space with only a single additional wire, while still needing
> > > + to repeat the commands when crossing a chip boundary. The size of
> > > + each chip should be provided as members of the array.
> >
> > array?
> >
> > Sounds like an array from the description as there is only 1 element,
> > the size.
>
> Well, what I expected to have was something like:
>
> dt: <property> = <uint64>, <uint64>;
The downside to this is you really need:
property = /bits/ 64 <uint64>, /bits/ 64 <uint64>;
And I just fixed some examples that had:
property = /bits/ 64 <uint64>, <uint64>;
The property length there is 12 bytes. That aspect of the syntax is
really not obvious. I only realized that somewhat recently.
You can even do:
property = /bits/ 64 <uint64>, "a string", /bits/ 8 <uint8>;
While dts syntax allows this, our sanity does not.
> It seemed like the only possible way (that the tooling would validate)
> was to use:
>
> bindings: $ref: /schemas/types.yaml#/definitions/uint64-matrix
>
> So I assumed I was defining a matrix of AxB elements, where A is the
> number of devices I want to "stack" and B is the number of values
> needed to describe its size, so 1.
Yeah, that's well reasoned and I agree. The other array case is you
have N values where each value represents different data rather than
instances of the same data. The challenge is for the schema fixups to
recognize which is which without saying the schema must look like
exactly X or Y as there will be exceptions.
> I realized that the following example, which I was expecting to work,
> was failing:
>
> bindings: $ref: /schemas/types.yaml#/definitions/uint64-array
> dt: <property> = <uint64>, <uint64>;
>
> Indeed, as you propose, this actually works but describes two values
> (tied somehow) into a single element, which is not exactly what I
> wanted:
>
> bindings: $ref: /schemas/types.yaml#/definitions/uint64-array
> dt: <property> = <uint64 uint64>;
>
> But more disturbing, all the following constructions worked, when using
> 32-bits values instead:
>
> bindings: $ref: /schemas/types.yaml#/definitions/uint32-array
> dt: <property> = <uint32 uint32>;
>
> bindings: $ref: /schemas/types.yaml#/definitions/uint32-array
> dt: <property> = <uint32>, <uint32>;
>
> bindings: $ref: /schemas/types.yaml#/definitions/uint32-matrix
> dt: <property> = <uint32 uint32>;
>
> bindings: $ref: /schemas/types.yaml#/definitions/uint32-matrix
> dt: <property> = <uint32>, <uint32>;
That works because there's some really ugly code to transform the
schema into both forms.
> I am fine waiting a bit if you think there is a need for some tooling
> update on your side. Otherwise, do you really think that this solution
> is the one we should really use?
>
> bindings: $ref: /schemas/types.yaml#/definitions/uint64-array
> dt: <property> = <uint64 uint64>;
Because of the /bits/ issue, yes.
More importantly, the bracketing in dts files is not going to matter
soon (from a validation perspective). I'm working on moving validation
from using the yaml encoded DT (which depends on and preserves
brackets) to using dtbs. This will use the schemas to decode the
property values into the right format/type.
> Because from my point of view it does not match what we usually do for
> other "types" of elements, such as:
>
> dt: <property> = <phandle1 index1>, <phandle2 index2>;
>
> or
>
> dt: <property> = <small-val1>, <small-val2>;
>
> >
> > > + minItems: 2
> > > + maxItems: 2
> > > + items:
> > > + maxItems: 1
> >
> > This says you can only have 2 64-bit entries. Probably not what you
> > want. This looks like a case for a maxItems 'should be enough for now'
> > type of value.
>
> Yes, that is what I wanted to describe.
>
> In my recent contributions you always preferred to bound things as much
> as possible, even though later it might become necessary to loosen the
> constraint. Right now I see the use of these properties for 2 devices,
> but in theory there is no limit.
Ok, as long as we're not loosening it frequently.
Rob
^ permalink raw reply
* Re: [PATCH v4 1/2] leds: ktd20xx: Extension of the KTD20xx family of LED drivers from Kinetic
From: Andy Shevchenko @ 2022-01-21 15:46 UTC (permalink / raw)
To: Florian Eckert
Cc: Pavel Machek, Rob Herring, Eckert.Florian,
Linux Kernel Mailing List, Linux LED Subsystem, devicetree
In-Reply-To: <20220121140150.1729-2-fe@dev.tdt.de>
On Fri, Jan 21, 2022 at 4:01 PM Florian Eckert <fe@dev.tdt.de> wrote:
>
> Introducing the KTD2061/58/59/60 RGB LED drivers. The difference in
> these are the address numbers on the I2C bus that the device listens to.
>
> All KT20xx units can drive up to 12 LEDs.
>
> Due to the hardware limitation, we can only set 7 colors and the color
> black (LED off) for each LED independently and not the full RGB range.
> This is because the chip only has two color registers.
>
> To control the LEDs independently, the chip has to be configured in a
> special way.
>
> Color register 0 must be loaded with the current value 0mA, and color
> register 1 must be loaded with the value 'kinetic,led-current' from the
> device tree node. If the property is omitted, the register is loaded
> with the default value (0x28 = 5mA).
>
> To select a color for an LED, a combination must be written to the color
> selection register of that LED. This range for selecting the value is 3
> bits wide (RGB). A '0' in any of the bits uses color register '0' and a
> '1' uses color register '1'.
>
> So we could choose the following combination for each LED:
> R G B
> 0 0 0 = Black (off)
> 0 0 1 = Blue
> 0 1 0 = green
> 0 1 1 = Cyan
> 1 0 0 = Red
> 1 0 1 = Magenta
> 1 1 0 = Yellow
> 1 1 1 = White
...
> +/*
> + * LEDs driver for the Kinetic KDT20xx device
> + *
> + * Copyright (C) 2021 TDT AG Florian Eckert <fe@dev.tdt.de>
> + *
Redundant (blank) line.
> + */
...
> +static const struct reg_default ktd20xx_reg_defs[] = {
> + /* Color0 Configuration Registers */
> + {KTD20XX_IRED0, 0x28},
> + {KTD20XX_IGRN0, 0x28},
> + {KTD20XX_IBLU0, 0x28},
> + /* Color1 Configuration Registers */
> + {KTD20XX_IRED1, 0x60},
> + {KTD20XX_IGRN1, 0x60},
> + {KTD20XX_IBLU1, 0x60},
> + /* Selection Configuration Register */
> + {KTD20XX_ISELA12, 0x00},
> + {KTD20XX_ISELA34, 0x00},
> + {KTD20XX_ISELB12, 0x00},
> + {KTD20XX_ISELB34, 0x00},
> + {KTD20XX_ISELC12, 0x00},
> + {KTD20XX_ISELC34, 0x00}
+ Comma?
> +};
...
> + struct device *dev = &chip->client->dev;
> + int ret;
> + unsigned int value;
Here and everywhere can you use reverse xmas tree ordering?
struct device *dev = &chip->client->dev;
unsigned int value;
int ret;
...
> + /*
> + * If the device tree property 'kinetc,led-current' is found
> + * then set this value into the color0 register as the max current
> + * for all color channel LEDs. If this poperty is not set then
property
> + * use the default value 0x28 set by the chip after a hardware reset.
> + * The hardware default value 0x28 corresponds to 5mA.
> + */
...
> + set_bit(channel, &rgb);
__set_bit() will be sufficient here (no need an atomic version)
...
> + /*
> + * To use the color0 registers default value after an hadware reset,
hardware
> + * if the device tree property 'kinetc,led-current' is not set,
> + * we have to 'invert' the rgb channel!
> + */
...
> +unlock_out:
out_unlock is more usual, but it's up to you.
...
> + chip->regmap = devm_regmap_init_i2c(client, &ktd20xx_regmap_config);
> + if (IS_ERR(chip->regmap)) {
> + dev_err_probe(dev, PTR_ERR(chip->regmap),
> + "Failed to allocate register map\n");
> + goto error;
return dev_err_probe(...);
> + }
...
> + ret = regmap_field_read(chip->vendor, &vendor);
> + if (ret) {
> + dev_err_probe(dev, ret, "Failed to read vendor\n");
> + goto error;
Ditto.
> + }
> +
> + ret = regmap_field_read(chip->chip_id, &chip_id);
> + if (ret) {
> + dev_err_probe(dev, ret, "Failed to read chip id\n");
> + goto error;
Ditto,
> + }
> +
> + ret = regmap_field_read(chip->chip_rev, &chip_rev);
> + if (ret) {
> + dev_err_probe(dev, ret, "Failed to read chip rev\n");
> + goto error;
Ditto.
> + }
...
> + dev_info(dev, "vendor: 0x%02x chip-id: 0x%02x chip-rev: 0x%02x\n",
> + vendor, chip_id, chip_rev);
Why on the info level?
...
> + ret = ktd20xx_probe_dt(chip);
> + if (ret)
return ret;
> + goto error;
> +
> + ret = ktd20xx_hwinit(chip);
> + if (ret)
> + goto error;
Ditto.
...
> +error:
> + return ret;
Unneeded label, see above.
...
> +static struct i2c_driver ktd20xx_driver = {
> + .driver = {
> + .name = "ktd20xx",
> + .dev_groups = ktd20xx_led_controller_groups,
> + .of_match_table = of_ktd20xx_leds_match,
> + },
> + .probe = ktd20xx_probe,
Why not .probe_new?
> + .remove = ktd20xx_remove,
> + .id_table = ktd20xx_id
+ Comma.
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 00/22] drm/rockchip: RK356x VOP2 support
From: Piotr Oniszczuk @ 2022-01-21 15:43 UTC (permalink / raw)
To: Sascha Hauer
Cc: dri-devel, linux-arm-kernel@lists.infradead.org, linux-rockchip,
devicetree@vger.kernel.org, kernel, Andy Yan, Benjamin Gaignard,
Michael Riesch, Sandy Huang, Heiko Stübner, Peter Geis
In-Reply-To: <20220121103245.GT23490@pengutronix.de>
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 21.01.2022, o godz. 11:32:
>
>>
>> 1. how support for CEC looks/prospects (plans for future, not in this code, expecting others should implement, etc)?
>
> I had to google what CEC actually is. We don't have plans supporting it.
> It looks like this is a matter of the HDMI driver supporting this and
> not bound to the rockchip driver.
Ah ok. sure. got it!
(I asked as Rockchip hdmi driver already well supports CEC - so i was thinking on rk3566 this is more of enabling than writing support code).
> You enabled the panfrost driver with other patches, right?
Oh - i wasn't aware any patches are needed for Mesa for rk3566....
If so - may you pls point me for latest/correct patches for rk3566?
>
>>
>> 3. in kernel dmesg I have many:
>>
>> "rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier 0x810000000000001".
>
> This message is correct. This corresponds to
> DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED and the VOP2 driver doesn't
> support this. I have a similar problem here with
> weston-simple-dmabuf-egl. By default this uses DRM_FORMAT_XRGB8888
> which ends up being PIPE_FORMAT_B8G8R8_UNORM in MESA.
Ah ok. Clear now.
Thx!
btw: i added support for argb8888 in my app and now all is ok.
no anymore errors in dmesg :-)
so summarising:
your vop2 code works for me in all supported video pipeline variants:
-x11/Glamour
-Wayland-EGL
-EGLFS/EGL-dmabuf
-EGLFS/DRM Planes
Your vop2 work is impressive!
btw:
you mention:
> In weston-simple-dmabuf-egl I can pass a suitable format on the command
> line, in my case I use DRM_FORMAT_ABGR8888 (which becomes
> PIPE_FORMAT_R8G8B8A8_UNORM). With this the panfrost driver does AFBC
> which then can be rendered in the VOP2 cluster window overlay.
is this mean that: when my app is using ARGB8888 format - then I have AFBC on rk3566?
^ permalink raw reply
* Re: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one bit ADC-DAC
From: Jonathan Cameron @ 2022-01-21 14:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Cristian Pop, linux-iio, linux-gpio,
linux-kernel, devicetree, robh+dt
In-Reply-To: <CAHp75VeakSDtDfGO1tcZKgoJ0KTAHgYMKG1v=cYDSHoc-zLUbw@mail.gmail.com>
On Tue, 18 Jan 2022 19:06:20 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Mon, Jan 17, 2022 at 8:41 AM Jonathan Cameron <jic23@kernel.org> wrote:
> > On Tue, 11 Jan 2022 13:59:19 +0200
> > Cristian Pop <cristian.pop@analog.com> wrote:
>
> > > + st->labels = devm_kzalloc(device, sizeof(*st->labels) * child_num, GFP_KERNEL);
> > > + if (!st->labels)
> > > + return -ENOMEM;
> > > +
> > > + i = child_num;
> > > + fwnode_for_each_child_node(fwnode, child) {
> > > + if (fwnode_property_read_u32(child, "reg", &crt_ch))
> > > + continue;
> > > +
> > > + if (crt_ch >= num_channels)
> > > + continue;
> > > +
> > > + if (fwnode_property_read_string(child, "label", &label))
> > > + continue;
> > > +
> > > + chan = &channels[crt_ch];
> > ? Not used.
> >
> > > + st->labels[--i] = label;
>
> > I've no idea how this works... Should be looking for the chan->channel
> > value as that's what your read uses to index.
>
> It's an implicit memcpy().
Not that. What I don't follow is how it ends up in the right element of
st->labels[] seeing as i has nothing to do with reg which should
be the channel number. Far as I can see it's setting the labels
in a random order.
Jonathan
>
> > > + }
> > > +
> > > + return 0;
> > > +}
>
>
>
^ permalink raw reply
* Re: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one bit ADC-DAC
From: Jonathan Cameron @ 2022-01-21 14:54 UTC (permalink / raw)
To: Pop, Cristian
Cc: Jonathan Cameron, linux-iio@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <DM6PR03MB38660D97C97334644D755FD7E75B9@DM6PR03MB3866.namprd03.prod.outlook.com>
On Fri, 21 Jan 2022 10:24:18 +0000
"Pop, Cristian" <Cristian.Pop@analog.com> wrote:
> Hi Jonathan,
>
> The additional functionality it is a little bit unclear to me.
>
> > -----Original Message-----
> > From: Jonathan Cameron <jic23@kernel.org>
> > Sent: Sunday, January 16, 2022 1:52 PM
> > To: Pop, Cristian <Cristian.Pop@analog.com>
> > Cc: linux-iio@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> > kernel@vger.kernel.org; devicetree@vger.kernel.org; robh+dt@kernel.org
> > Subject: Re: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one bit
> > ADC-DAC
> >
> > [External]
> >
> > On Tue, 11 Jan 2022 13:59:19 +0200
> > Cristian Pop <cristian.pop@analog.com> wrote:
> >
> > > This allows remote reading and writing of the GPIOs. This is useful in
> > > application that run on another PC, at system level, where multiple
> > > iio devices and GPIO devices are integrated together.
> > Hi Cristian,
> >
> > So I fully understand why this can be useful, but it is a software only
> > construction so I'm not convinced that it makes sense to necessarily
> > configure it via device tree. A better fit may well be configfs.
> > (note I always meant to add configfs controls for iio_hwmon but haven't
> > found the time to do it yet...)
> >
> > As it currently stands, doing only polled / sysfs reads this driver doesn't do
> > enough to justify its existence. You could just do all this in userspace using
> > the existing gpio interfaces. So to be useful I'd expect it to at least do
> > triggered buffer capture.
>
> What do you mean by triggered buffer capture? Should I save previous GPIO
> states into a buffer? What should I do with them?
As in using IIO triggers in conjunction with a Kfifo. So that you can do
in kernel capture of a series of samples triggered at the same time as
captures from ADCs. Then it's easy to line the data up afterwards in
userspace.
Same in the output direction. This is only really interesting if it is being
done in sync with something else - otherwise you could just use the usespace
gpio interfaces directly.
>
> A useful use case that I see:
> - Is to register a function callback (in kernel space, maybe user space that
> should be used by a different driver), and called in the interrupt handler
> when the state of an input GPIO changes.
Ok. But if you can just do that directly using the gpio interaces as it will
require a bit of custom driver code anyway.
> - Output to a GPIO from a buffer using a clock, obtaining a PWM like signal.
Again, why is the IIO bit useful? It's only useful if you are doing it
in sync with other IIO stuff and I don't just mean using the IIO in kernel
interfaces for accessing a channel in a polled mode (effectively call read_raw
/write_raw because whereever you can do that you can just the gpio directly.
Jonathan
>
> >
> > When we have talked about handling digital signals int he past we discussed
> > whether the IIO channel description would also benefit from tighter packing
> > than the current minimum of a byte per channel. Perhaps we don't
> > technically 'need' it here but if we do add it in future it will be hard to retrofit
> > into this driver without big userspace ABI changes (i.e. breaking all existing
> > users).
> >
> > I've not repeated stuff Andy got it in his review (assuming I remembered it
> > was something Andy raised).
> >
> > Conclusion:
> > 1) Creation interface needs a rethink or strong argument why it belongs in
> > DT.
> > 2) Driver needs to do more to justify it's existence.
> >
> > Jonathan
> >
> > >
> > > Signed-off-by: Cristian Pop <cristian.pop@analog.com>
> > > ---
> > > drivers/iio/addac/Kconfig | 8 +
> > > drivers/iio/addac/Makefile | 1 +
> > > drivers/iio/addac/one-bit-adc-dac.c | 229
> > > ++++++++++++++++++++++++++++
> > > 3 files changed, 238 insertions(+)
> > > create mode 100644 drivers/iio/addac/one-bit-adc-dac.c
> > >
> > > diff --git a/drivers/iio/addac/Kconfig b/drivers/iio/addac/Kconfig
> > > index 138492362f20..5f311f4a747e 100644
> > > --- a/drivers/iio/addac/Kconfig
> > > +++ b/drivers/iio/addac/Kconfig
> > > @@ -17,4 +17,12 @@ config AD74413R
> > > To compile this driver as a module, choose M here: the
> > > module will be called ad74413r.
> > >
> > > +config ONE_BIT_ADC_DAC
> > > + tristate "ONE_BIT_ADC_DAC driver"
> > > + help
> > > + Say yes here to build support for ONE_BIT_ADC_DAC driver.
> >
> > Needs a lot more detail here. Though naming it to be explicitly about GPIO to
> > IIO binding would help.
> >
> > > +
> > > + To compile this driver as a module, choose M here: the
> > > + module will be called one-bit-adc-dac.
> > > +
> > > endmenu
> > > diff --git a/drivers/iio/addac/Makefile b/drivers/iio/addac/Makefile
> > > index cfd4bbe64ad3..0a33f0706b55 100644
> > > --- a/drivers/iio/addac/Makefile
> > > +++ b/drivers/iio/addac/Makefile
> > > @@ -5,3 +5,4 @@
> > >
> > > # When adding new entries keep the list in alphabetical order
> > > obj-$(CONFIG_AD74413R) += ad74413r.o
> > > +obj-$(CONFIG_ONE_BIT_ADC_DAC) += one-bit-adc-dac.o
> > > diff --git a/drivers/iio/addac/one-bit-adc-dac.c
> > > b/drivers/iio/addac/one-bit-adc-dac.c
> > > new file mode 100644
> > > index 000000000000..5680de594429
> > > --- /dev/null
> > > +++ b/drivers/iio/addac/one-bit-adc-dac.c
> > > @@ -0,0 +1,229 @@
> > > +// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> > > +/*
> > > + * one-bit-adc-dac
> >
> > Improve description here as well. It's really just a wrapper for a gpio in an IIO
> > channel, so just say that. Fine to say the representation is 1 bit ADC or DAC
> > channels as well, but I think the GPIO part will be more obvious to the casual
> > reader.
> >
> > > + *
> > > + * Copyright 2022 Analog Devices Inc.
> > > + */
> > > +
> > > +#include <linux/device.h>
> > > +#include <linux/module.h>
> > > +#include <linux/iio/iio.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/gpio/consumer.h>
> > > +
> > > +enum ch_direction {
> > > + CH_IN,
> > > + CH_OUT,
> > > +};
> > > +
> > > +struct one_bit_adc_dac_state {
> > > + int in_num_ch;
> > > + int out_num_ch;
> > > + struct platform_device *pdev;
> >
> > Not used after probe so don't keep it around.
> >
> > > + struct gpio_descs *in_gpio_descs;
> > > + struct gpio_descs *out_gpio_descs;
> > > + const char **labels;
> > > +};
> > > +
> > > +static int one_bit_adc_dac_read_raw(struct iio_dev *indio_dev,
> > > + const struct iio_chan_spec *chan, int *val, int *val2, long info) {
> > > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > > + struct gpio_descs *descs;
> > > +
> > > + switch (info) {
> > > + case IIO_CHAN_INFO_RAW:
> > > + if (chan->output)
> > > + descs = st->out_gpio_descs;
> > > + else
> > > + descs = st->in_gpio_descs;
> > > + *val = gpiod_get_value_cansleep(descs->desc[chan-
> > >channel]);
> > > +
> > > + return IIO_VAL_INT;
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > +}
> > > +
> > > +static int one_bit_adc_dac_write_raw(struct iio_dev *indio_dev,
> > > + struct iio_chan_spec const *chan,
> > > + int val,
> > > + int val2,
> > > + long info)
> > > +{
> > > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > > + int channel = chan->channel;
> > > +
> > > + if (!chan->output)
> > > + return 0;
> >
> > -EINVAL; It's an error that should be reported to userspace..
> >
> > > +
> > > + switch (info) {
> > > + case IIO_CHAN_INFO_RAW:
> > > + gpiod_set_value_cansleep(st->out_gpio_descs-
> > >desc[channel], val);
> > > +
> > > + return 0;
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > +}
> > > +
> > > +static int one_bit_adc_dac_read_label(struct iio_dev *indio_dev,
> > > + const struct iio_chan_spec *chan, char *label) {
> > > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > > + int ch;
> > > +
> > > + if (chan->output)
> > > + ch = chan->channel + st->in_num_ch;
> > > + else
> > > + ch = chan->channel;
> > > +
> > > + return sprintf(label, "%s\n", st->labels[ch]); }
> > > +
> > > +static const struct iio_info one_bit_adc_dac_info = {
> > > + .read_raw = &one_bit_adc_dac_read_raw,
> > > + .write_raw = &one_bit_adc_dac_write_raw,
> > > + .read_label = &one_bit_adc_dac_read_label, };
> > > +
> > > +static int one_bit_adc_dac_set_ch(struct iio_chan_spec *channels,
> > > + int num_ch,
> > > + enum ch_direction direction)
> > > +{
> > > + int i;
> > > +
> > > + for (i = 0; i < num_ch; i++) {
> > > + channels[i].type = IIO_VOLTAGE;
> > > + channels[i].indexed = 1;
> > > + channels[i].channel = i;
> > > + channels[i].info_mask_separate =
> > BIT(IIO_CHAN_INFO_RAW);
> > > + channels[i].output = direction;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int one_bit_adc_dac_set_channel_label(struct iio_dev *indio_dev,
> > > + struct iio_chan_spec
> > *channels,
> > > + int num_channels)
> > > +{
> > > + struct device *device = indio_dev->dev.parent;
> > > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > > + struct fwnode_handle *fwnode;
> > > + struct fwnode_handle *child;
> > > + struct iio_chan_spec *chan;
> > > + const char *label;
> > > + int crt_ch = 0, child_num, i = 0;
> > > +
> > > + fwnode = dev_fwnode(device);
> > > + child_num = device_get_child_node_count(device);
> > > +
> > > + st->labels = devm_kzalloc(device, sizeof(*st->labels) * child_num,
> > GFP_KERNEL);
> > > + if (!st->labels)
> > > + return -ENOMEM;
> > > +
> > > + i = child_num;
> > > + fwnode_for_each_child_node(fwnode, child) {
> > > + if (fwnode_property_read_u32(child, "reg", &crt_ch))
> > > + continue;
> > > +
> > > + if (crt_ch >= num_channels)
> > > + continue;
> > > +
> > > + if (fwnode_property_read_string(child, "label", &label))
> > > + continue;
> > > +
> > > + chan = &channels[crt_ch];
> > ? Not used.
> >
> > > + st->labels[--i] = label;
> >
> > I've no idea how this works... Should be looking for the chan->channel value
> > as that's what your read uses to index.
> >
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int one_bit_adc_dac_parse_dt(struct iio_dev *indio_dev) {
> > > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > > + struct iio_chan_spec *channels;
> > > + int ret, in_num_ch = 0, out_num_ch = 0;
> > > +
> > > + st->in_gpio_descs = devm_gpiod_get_array_optional(&st->pdev-
> > >dev, "in", GPIOD_IN);
> > > + if (IS_ERR(st->in_gpio_descs))
> > > + return PTR_ERR(st->in_gpio_descs);
> > > +
> > > + if (st->in_gpio_descs)
> > > + in_num_ch = st->in_gpio_descs->ndescs;
> > > +
> > > + st->out_gpio_descs = devm_gpiod_get_array_optional(&st->pdev-
> > >dev, "out", GPIOD_OUT_LOW);
> > > + if (IS_ERR(st->out_gpio_descs))
> > > + return PTR_ERR(st->out_gpio_descs);
> > > +
> > > + if (st->out_gpio_descs)
> > > + out_num_ch = st->out_gpio_descs->ndescs;
> > > + st->in_num_ch = in_num_ch;
> > > + st->out_num_ch = out_num_ch;
> > > +
> > > + channels = devm_kcalloc(indio_dev->dev.parent, in_num_ch +
> > out_num_ch,
> > > + sizeof(*channels), GFP_KERNEL);
> > > + if (!channels)
> > > + return -ENOMEM;
> > > +
> > > + ret = one_bit_adc_dac_set_ch(&channels[0], in_num_ch, CH_IN);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = one_bit_adc_dac_set_ch(&channels[in_num_ch],
> > out_num_ch, CH_OUT);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = one_bit_adc_dac_set_channel_label(indio_dev, channels,
> > in_num_ch + out_num_ch);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + indio_dev->channels = channels;
> > > + indio_dev->num_channels = in_num_ch + out_num_ch;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int one_bit_adc_dac_probe(struct platform_device *pdev) {
> > > + struct iio_dev *indio_dev;
> > > + struct one_bit_adc_dac_state *st;
> > > + int ret;
> > > +
> > > + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*st));
> > > + if (!indio_dev)
> > > + return -ENOMEM;
> > > +
> > > + st = iio_priv(indio_dev);
> > > + st->pdev = pdev;
> > > + indio_dev->name = "one-bit-adc-dac";
> > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > + indio_dev->info = &one_bit_adc_dac_info;
> > > +
> > > + ret = one_bit_adc_dac_parse_dt(indio_dev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + return devm_iio_device_register(indio_dev->dev.parent,
> > indio_dev); }
> > > +
> > > +static const struct of_device_id one_bit_adc_dac_dt_match[] = {
> > > + { .compatible = "one-bit-adc-dac" },
> > > + {}
> > > +};
> > > +MODULE_DEVICE_TABLE(of, one_bit_adc_dac_dt_match);
> > > +
> > > +static struct platform_driver one_bit_adc_dac_driver = {
> > > + .driver = {
> > > + .name = "one-bit-adc-dac",
> > > + .of_match_table = one_bit_adc_dac_dt_match,
> > > + },
> > > + .probe = one_bit_adc_dac_probe,
> > > +};
> > > +module_platform_driver(one_bit_adc_dac_driver);
> > > +
> > > +MODULE_AUTHOR("Cristian Pop <cristian.pop@analog.com>");
> > > +MODULE_DESCRIPTION("One bit ADC DAC converter");
> > MODULE_LICENSE("Dual
> > > +BSD/GPL");
> > > \ No newline at end of file
> >
> > Make sure to eyeball your patches before sending as this sort of thing should
> > be caught at that stage...
> >
>
^ permalink raw reply
* Re: [PATCH v2 12/12] arm64: dts: renesas: Add support for r9a07g044c1/r9a07g054l1-smarc.dts
From: Geert Uytterhoeven @ 2022-01-21 14:46 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Linux-Renesas, Magnus Damm, Rob Herring, Biju Das, Prabhakar,
Linux Kernel Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20220110134659.30424-13-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar, Biju,
On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/Makefile
> +++ b/arch/arm64/boot/dts/renesas/Makefile
> @@ -77,4 +77,6 @@ dtb-$(CONFIG_ARCH_R8A77965) += r8a779m5-salvator-xs.dtb
>
> dtb-$(CONFIG_ARCH_R9A07G044) += r9a07g044l2-smarc.dtb
> dtb-$(CONFIG_ARCH_R9A07G044) += r9a07g044c2-smarc.dtb
> +dtb-$(CONFIG_ARCH_R9A07G044) += r9a07g044c1-smarc.dtb
Please preserve sort order, and add a blank line to separate
different SoCs.
> dtb-$(CONFIG_ARCH_R9A07G054) += r9a07g054l2-smarc.dtb
> +dtb-$(CONFIG_ARCH_R9A07G054) += r9a07g054l1-smarc.dtb
Sort order.
Given this patch adds boards with two different SoCs, and the two
DTS files are quite dissimilar, I think this patch should be split in
two parts.
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r9a07g044c1-smarc.dts
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * Device Tree Source for the RZ/G2LC SMARC EVK board
> + *
> + * Copyright (C) 2021 Renesas Electronics Corp.
> + */
> +
> +/dts-v1/;
> +#include "r9a07g044c1.dtsi"
> +#include "rzg2lc-smarc-som.dtsi"
> +#include "rzg2lc-smarc-pinfunction.dtsi"
> +#include "rzg2l-smarc.dtsi"
> +
> +/ {
> + model = "Renesas SMARC EVK based on r9a07g044c2";
> + compatible = "renesas,smarc-evk", "renesas,r9a07g044c2", "renesas,r9a07g044";
"renesas,r9a07g044c1"
> +
> +};
> +
> +&canfd {
> + /delete-property/ pinctrl-0;
> + status = "disabled";
> +};
Looks like the corresponding pinctrl-names properties should be
removed, too. Else "make dtbs_check" complains.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 11/12] arm64: dts: renesas: Add initial device tree for RZ/V2L SMARC EVK
From: Geert Uytterhoeven @ 2022-01-21 14:46 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Linux-Renesas, Magnus Damm, Rob Herring, Biju Das, Prabhakar,
Linux Kernel Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20220110134659.30424-12-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add basic support for RZ/V2L SMARC EVK (based on R9A07G054L2):
> - memory
> - External input clock
> - CPG
> - Pin controller
> - SCIF
> - GbEthernet
> - Audio Clock
>
> It shares the same carrier board with RZ/G2L with the same pin mapping.
> Delete the gpio-hog nodes from pinctrl as this will be added later when
> the functionality has been tested.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.18.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 10/12] arm64: dts: renesas: Add initial DTSI for RZ/V2L SoC
From: Geert Uytterhoeven @ 2022-01-21 14:46 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Linux-Renesas, Magnus Damm, Rob Herring, Biju Das, Prabhakar,
Linux Kernel Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20220110134659.30424-11-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar, Biju,
On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The RZ/V2L is package- and pin-compatible with the RZ/G2L. The only
> difference being the RZ/V2L SoC has additional DRP-AI IP (AI
> accelerator).
>
> Add initial DTSI for RZ/V2L SoC with below SoC specific dtsi files for
> supporting single core and dual core devices.
>
> r9a07g054l1.dtsi => RZ/V2L R9A07G054L1 SoC specific parts
> r9a07g054l2.dtsi => RZ/V2L R9A07G054L2 SoC specific parts
>
> Both RZ/G2L and RZ/V2L SMARC EVK SoM are identical apart from SoC's
> used hence the common dtsi files (rzg2l-smarc*.dtsi) are share between
> RZ/G2L and RZ/V2L SMARC EVK. Place holders are added in device nodes to
> avoid compilation errors for the devices which have not been enabled yet
> on RZ/V2L SoC.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> + pinctrl: pin-controller@11030000 {
pinctrl@
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.18 with the above fixed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 09/12] dt-bindings: net: renesas,etheravb: Document RZ/V2L SoC
From: Geert Uytterhoeven @ 2022-01-21 14:46 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Linux-Renesas, Sergey Shtylyov, David S. Miller, Jakub Kicinski,
Rob Herring, Sergei Shtylyov, Biju Das, Prabhakar,
Linux Kernel Mailing List, netdev,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20220110134659.30424-10-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document Gigabit Ethernet IP found on RZ/V2L SoC. Gigabit Ethernet
> Interface is identical to one found on the RZ/G2L SoC. No driver changes
> are required as generic compatible string "renesas,rzg2l-gbeth" will be
> used as a fallback.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 08/12] dt-bindings: dma: rz-dmac: Document RZ/V2L SoC
From: Geert Uytterhoeven @ 2022-01-21 14:46 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Linux-Renesas, Vinod Koul, Rob Herring, Biju Das, Prabhakar,
Linux Kernel Mailing List, dmaengine,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20220110134659.30424-9-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document RZ/V2L DMAC bindings. RZ/V2L DMAC is identical to one found on
> the RZ/G2L SoC. No driver changes are required as generic compatible
> string "renesas,rz-dmac" will be used as a fallback.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 06/12] dt-bindings: pinctrl: renesas: Document RZ/V2L pinctrl
From: Geert Uytterhoeven @ 2022-01-21 14:46 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Linux-Renesas, Linus Walleij, Rob Herring, Biju Das, Prabhakar,
Linux Kernel Mailing List, open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20220110134659.30424-7-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document Renesas RZ/V2L pinctrl bindings. The RZ/V2L is package- and
> pin-compatible with the RZ/G2L. No driver changes are required as RZ/G2L
> compatible string "renesas,r9a07g044-pinctrl" will be used as a fallback.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-pinctrl-for-v5.18.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 04/12] dt-bindings: clock: renesas: Document RZ/V2L SoC
From: Geert Uytterhoeven @ 2022-01-21 14:45 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Linux-Renesas, Michael Turquette, Stephen Boyd, Rob Herring,
Biju Das, Prabhakar, Linux Kernel Mailing List, linux-clk,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20220110134659.30424-5-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document the device tree binding for the Renesas RZ/V2L SoC.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk-for-v5.18.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: clock: Add R9A07G054 CPG Clock and Reset Definitions
From: Geert Uytterhoeven @ 2022-01-21 14:44 UTC (permalink / raw)
To: Lad Prabhakar, Biju Das
Cc: Linux-Renesas, Rob Herring, Prabhakar, Linux Kernel Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20220110134659.30424-4-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar, Biju,
On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Define RZ/V2L (R9A07G054) Clock Pulse Generator Core Clock and module
> clock outputs, as listed in Table 7.1.4.2 ("Clock List r1.0") and also
> add Reset definitions referring to registers CPG_RST_* in Section 7.2.3
> ("Register configuration") of the RZ/V2L Hardware User's Manual (Rev.1.00,
> Nov.2021).
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Before I queue this in renesas-clk-for-v5.18, I'm wondering if you
want to add the DRP_M, DRP_D, and DRP_A core clocks, too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 01/12] dt-bindings: power: renesas,rzg2l-sysc: Document RZ/V2L SoC
From: Geert Uytterhoeven @ 2022-01-21 14:44 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Linux-Renesas, Rob Herring, Biju Das, Prabhakar,
Linux Kernel Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20220110134659.30424-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jan 10, 2022 at 2:47 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add DT binding documentation for SYSC controller found on RZ/V2L SoC.
> SYSC controller found on the RZ/V2L SoC is almost identical to one found
> on the RZ/G2L SoC's only difference being that the RZ/V2L has an
> additional register to control the DRP-AI.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.18.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 02/16] dt-bindings: arm: renesas: Document SMARC EVK
From: Geert Uytterhoeven @ 2022-01-21 14:44 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Magnus Damm, Rob Herring, Michael Turquette, Stephen Boyd,
Vinod Koul, Sergey Shtylyov, David S. Miller, Jakub Kicinski,
Linus Walleij, Greg Kroah-Hartman, Biju Das, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk, dmaengine, netdev,
open list:GPIO SUBSYSTEM, open list:SERIAL DRIVERS, Prabhakar
In-Reply-To: <20211221094717.16187-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Tue, Dec 21, 2021 at 10:47 AM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document Renesas SMARC EVK board which is based on RZ/V2L (R9A07G054)
> SoC. The SMARC EVK consists of RZ/V2L SoM module and SMARC carrier board,
> the SoM module sits on top of the carrier board.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.18, merged with the previous
patch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 01/16] dt-bindings: arm: renesas: Document Renesas RZ/V2L SoC
From: Geert Uytterhoeven @ 2022-01-21 14:43 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Magnus Damm, Rob Herring, Michael Turquette, Stephen Boyd,
Vinod Koul, Sergey Shtylyov, David S. Miller, Jakub Kicinski,
Linus Walleij, Greg Kroah-Hartman, Biju Das, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk, dmaengine, netdev,
open list:GPIO SUBSYSTEM, open list:SERIAL DRIVERS, Prabhakar
In-Reply-To: <20211221094717.16187-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Tue, Dec 21, 2021 at 10:47 AM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document Renesas RZ/V2L SoC.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.18.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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