riscv: Add PBMT & DMA for D1 bringup
Subsystems (4)
v4 cover riscv: Add PBMT & DMA for D1 bringup
From: Guo Ren <[email protected]>
These patches are a continuation of "riscv: Add DMA_COHERENT support for Allwinner D1". In this version, we rebase on Atish's Global dma pool patchset, and it has been tested on qemu and our hardware platforms. But we append "select DMA_DIRECT_REMAP" in RISCV_DMA_NONCOHERENT, so not sure it would affect Atish's hardware platform.
We still use riscv_dma_cache_sync_set, not the alternative code. I agree the alternative framework is better for performance in dma ops. Maybe Atish's next version of the patch would use it.
The custom PBMT implementation is moved into errata and add apply_errata_setup_vm() in setup_vm prologue. Hope it could be approved.
You can follow the D1 fedora wiki[1], try the latest kernel with the patchset.
[1] https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner#Build_Linux_Kernel_for_D1
Previous versions:
V3: https://lore.kernel.org/linux-riscv/[email protected]/
V2: https://lore.kernel.org/linux-riscv/[email protected]/
V1: https://lore.kernel.org/linux-riscv/[email protected]/
Atish Patra (2):
RISC-V: Support a new config option for non-coherent DMA
RISC-V: Implement arch_sync_dma* functions
Guo Ren (3):
riscv: pgtable: Add custom protection_map init
riscv: errata: pgtable: Add custom Svpbmt supported for Allwinner D1
riscv: errata: Support T-HEAD custom dcache ops
Liu Shaohua (1):
riscv: soc: Add Allwinner SoC kconfig option
arch/riscv/Kconfig | 13 +++ arch/riscv/Kconfig.erratas | 11 +++ arch/riscv/Kconfig.socs | 15 ++++ arch/riscv/configs/defconfig | 1 + arch/riscv/errata/Makefile | 1 + arch/riscv/errata/alternative.c | 23 +++++ arch/riscv/errata/thead/Makefile | 1 + arch/riscv/errata/thead/errata.c | 108 +++++++++++++++++++++++ arch/riscv/include/asm/alternative.h | 4 + arch/riscv/include/asm/dma-noncoherent.h | 19 ++++ arch/riscv/include/asm/fixmap.h | 2 +- arch/riscv/include/asm/pgtable-64.h | 8 +- arch/riscv/include/asm/pgtable-bits.h | 46 +++++++++- arch/riscv/include/asm/pgtable.h | 30 ++++--- arch/riscv/include/asm/vendorid_list.h | 1 + arch/riscv/mm/Makefile | 1 + arch/riscv/mm/dma-noncoherent.c | 66 ++++++++++++++ arch/riscv/mm/init.c | 28 ++++++ mm/mmap.c | 4 + 19 files changed, 366 insertions(+), 16 deletions(-) create mode 100644 arch/riscv/errata/thead/Makefile create mode 100644 arch/riscv/errata/thead/errata.c create mode 100644 arch/riscv/include/asm/dma-noncoherent.h create mode 100644 arch/riscv/mm/dma-noncoherent.c
Signature · 1 line
2.25.1
RFC PATCH v4 1/6 riscv: pgtable: Add custom protection_map init
From: Guo Ren <[email protected]>
Some RISC-V CPU vendors have defined their own PTE attributes to solve non-coherent DMA bus problems. That makes _P/SXXX definitions contain global variables which could be initialized at the early boot stage before setup_vm. The patch prevents compile errors.
This patch is similar to 316d097c4cd4 (x86/pti: Filter at vma->vm_page_prot population) which give a choice for arch custom implementation.
--- arch/riscv/Kconfig | 4 ++++ arch/riscv/mm/init.c | 22 ++++++++++++++++++++++ mm/mmap.c | 4 ++++ 3 files changed, 30 insertions(+)
arch/riscv/Kconfig +4 -0
@@ -25,6 +25,7 @@ config RISCV select ARCH_HAS_GIGANTIC_PAGE select ARCH_HAS_KCOV select ARCH_HAS_MMIOWB + select ARCH_HAS_PROTECTION_MAP_INIT select ARCH_HAS_PTE_SPECIAL select ARCH_HAS_SET_DIRECT_MAP if MMU select ARCH_HAS_SET_MEMORY if MMU
@@ -201,6 +202,9 @@ config GENERIC_HWEIGHT config FIX_EARLYCON_MEM def_bool MMU +config ARCH_HAS_PROTECTION_MAP_INIT + def_bool y + config PGTABLE_LEVELS int default 3 if 64BIT
arch/riscv/mm/init.c +22 -0
@@ -550,6 +550,26 @@ static void __init create_kernel_page_table(pgd_t *pgdir, uintptr_t map_size, }#endif +static void __init setup_protection_map (void ) +{ + protection_map[0 ] = __P000; + protection_map[1 ] = __P001; + protection_map[2 ] = __P010; + protection_map[3 ] = __P011; + protection_map[4 ] = __P100; + protection_map[5 ] = __P101; + protection_map[6 ] = __P110; + protection_map[7 ] = __P111; + protection_map[8 ] = __S000; + protection_map[9 ] = __S001; + protection_map[10 ] = __S010; + protection_map[11 ] = __S011; + protection_map[12 ] = __S100; + protection_map[13 ] = __S101; + protection_map[14 ] = __S110; + protection_map[15 ] = __S111; +} + asmlinkage void __init setup_vm(uintptr_t dtb_pa) {uintptr_t __maybe_unused pa;
@@ -558,6 +578,8 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)pmd_t fix_bmap_spmd, fix_bmap_epmd;#endif +setup_protection_map (); + kernel_map.virt_addr =KERNEL_LINK_ADDR ;#ifdef CONFIG_XIP_KERNEL
mm/mmap.c +4 -0
@@ -100,10 +100,14 @@ static void unmap_region(struct mm_struct *mm,* w: (no) no * x: (yes) yes */ +#ifdef CONFIG_ARCH_HAS_PROTECTION_MAP_INIT +pgprot_t protection_map[16 ]__ro_after_init ; +#else pgprot_t protection_map[16 ]__ro_after_init = { __P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111, __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111 }; +#endif #ifndef CONFIG_ARCH_HAS_FILTER_PGPROT static inline pgprot_t arch_filter_pgprot (pgprot_t prot)
Signature · 1 line
2.25.1
Re: [RFC PATCH V4 1/6] riscv: pgtable: Add custom protection_map init
Quoted 6 lines · On Sat, Sep 11, 2021 at 05:21:34PM +0800, [email protected] wrote:
From: Guo Ren <[email protected]>
Some RISC-V CPU vendors have defined their own PTE attributes to solve non-coherent DMA bus problems. That makes _P/SXXX definitions contain global variables which could be initialized at the early boot stage before
setup_vm. The patch prevents compile errors.
That sounds way to nice for someone who deliberatly ignores the specification and should definitively not go into the kernel commit log like this.
Quoted 3 lines
This patch is similar to
316d097c4cd4(x86/pti: Filter atvma->vm_page_protpopulation) which give a choice for arch custom implementation.
How? To me it looks like a bad duplication of such functionality in a way that totally breaks abstractions. architectures really do not have any business changing protection_map.
Re: [RFC PATCH V4 1/6] riscv: pgtable: Add custom protection_map init
Hi Christoph,
Quoted 4 lines · Christoph Hellwig
Quoted 2 lines · On Sat, Sep 11, 2021 at 05:21:34PM +0800, [email protected] wrote:
From: Guo Ren <[email protected]>
Quoted 8 lines
Quoted 4 lines
Some RISC-V CPU vendors have defined their own PTE attributes to solve non-coherent DMA bus problems. That makes _P/SXXX definitions contain global variables which could be initialized at the early boot stage before
setup_vm. The patch prevents compile errors.That sounds way to nice for someone who deliberatly ignores the specification and should definitively not go into the kernel commit log like this.
Okay. In the next version, I will optimize the wording.
Quoted 8 lines
Quoted 4 lines
This patch is similar to
316d097c4cd4(x86/pti: Filter atvma->vm_page_protpopulation) which give a choice for arch custom implementation.How? To me it looks like a bad duplication of such functionality in a way that totally breaks abstractions. architectures really do not have any business changing
protection_map.
D1's _P/SXXX definintion is different from riscv standard spec to get non-coherency supported. It sets the highest bits and current spec must keep zero. So we using a global variable struct in the _P/SXXX definition to let vendors init their own _P/SXXX values during bootstrap that is very early stage before setup_vm().
Signature · 4 lines
Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
RFC PATCH v4 2/6 riscv: errata: pgtable: Add custom Svpbmt supported for Allwinner D1
In reply to [email protected]From: Guo Ren <[email protected]>
RISC-V Svpbmt is gradually maturing, the draft is:
Svpbmt PTE format:
| 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
N MT RSW D A G U X W R V
^Of the Reserved bits [63:54] in a leaf PTE, the high bit is already allocated (as the N bit), so bits [62:61] are used as the MT (aka MemType) field. This field specifies one of three memory types that are close equivalents (or equivalent in effect) to the three main x86 and ARMv8 memory types - as shown in the following table.
RISC-V
Encoding &
MemType RISC-V Description ---------- ------------------------------------------------ 00 - PMA Normal Cacheable, No change to implied PMA memory type 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory 11 - Rsvd Reserved for future standard use
But T-HEAD C906 in Allwinner D1 has defined a custom Svpbmt:
T-HEAD C9xx PTE format:
| 63 | 62 | 61 | 60 | 59-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 SO C B SH RSW D A G U X W R V ^ ^ ^ ^
BIT(63): SO - Strong Order
BIT(62): C - Cacheable
BIT(61): B - Bufferable
BIT(60): SH - Shareable
MT_MASK : [63 - 59]MT_PMA : C + SHMT_NC : (none)MT_IO : SO
The patch not only implements the D1's PBMT extension but also considers future scalability by errata framework.
We are trying to keep both below work together:
- "riscv spec acceptance policy" (Svpbmt extension in future)
- "Linux Keep real hardware work" (Allwinner D1's custom Svpbmt)
--- arch/riscv/Kconfig.erratas | 11 ++++++ arch/riscv/errata/Makefile | 1 + arch/riscv/errata/alternative.c | 18 ++++++++++ arch/riscv/errata/thead/Makefile | 1 + arch/riscv/errata/thead/errata.c | 47 ++++++++++++++++++++++++++ arch/riscv/include/asm/alternative.h | 2 ++ arch/riscv/include/asm/fixmap.h | 2 +- arch/riscv/include/asm/pgtable-64.h | 8 +++-- arch/riscv/include/asm/pgtable-bits.h | 46 +++++++++++++++++++++++-- arch/riscv/include/asm/pgtable.h | 30 ++++++++++------ arch/riscv/include/asm/vendorid_list.h | 1 + arch/riscv/mm/init.c | 6 ++++ 12 files changed, 157 insertions(+), 16 deletions(-) create mode 100644 arch/riscv/errata/thead/Makefile create mode 100644 arch/riscv/errata/thead/errata.c
arch/riscv/Kconfig.erratas +11 -0
@@ -41,4 +41,15 @@ config ERRATA_SIFIVE_CIP_1200 If you don't know what to do here, say "Y". +config ERRATA_THEAD + bool "T-HEAD errata" + depends on RISCV_ERRATA_ALTERNATIVE + default y + help + All T-HEAD errata Kconfig depend on this Kconfig. Disabling + this Kconfig will disable all T-HEAD errata. Please say "Y" + here if your platform uses T-HEAD CPU cores. + + Otherwise, please say "N" here to avoid unnecessary overhead. + endmenu
arch/riscv/errata/Makefile +1 -0
@@ -1,2 +1,3 @@ obj-y += alternative.o obj-$(CONFIG_ERRATA_SIFIVE) += sifive/ +obj-$(CONFIG_ERRATA_THEAD) += thead/
arch/riscv/errata/alternative.c +18 -0
@@ -72,3 +72,21 @@ void __init apply_boot_alternatives(void) cpu_mfr_info.arch_id, cpu_mfr_info.imp_id); } +/* +* This is called very early form setup_vm in the boot process. +*/ +void __init apply_errata_setup_vm (void ) +{ +riscv_fill_cpu_mfr_info (); + +switch (cpu_mfr_info.vendor_id) { +#ifdef CONFIG_ERRATA_THEAD +case THEAD_VENDOR_ID : +thead_errata_setup_vm (cpu_mfr_info.arch_id, + cpu_mfr_info.imp_id); +break ; +#endif +default : +break ; + } +}
arch/riscv/errata/thead/Makefile new file +1 -0
@@ -0,0 +1 @@ +obj-y += errata.o
arch/riscv/errata/thead/errata.c new file +47 -0
47 lines not on this page · raw message
arch/riscv/include/asm/alternative.h +2 -0
@@ -18,6 +18,7 @@#include <asm/hwcap.h> void __init apply_boot_alternatives (void ); +void __init apply_errata_setup_vm (void );struct alt_entry {void *old_ptr;/* address of original instruciton or data */
@@ -35,5 +36,6 @@ struct errata_checkfunc_id {void sifive_errata_patch_func (struct alt_entry *begin,struct alt_entry *end,unsigned long archid,unsigned long impid); +void thead_errata_setup_vm (unsigned long archid,unsigned long impid);#endif #endif
arch/riscv/include/asm/fixmap.h +1 -1
@@ -43,7 +43,7 @@ enum fixed_addresses { __end_of_fixed_addresses }; -#define FIXMAP_PAGE_IO PAGE_KERNEL +#define FIXMAP_PAGE_IO PAGE_IOREMAP#define __early_set_fixmap __set_fixmap
arch/riscv/include/asm/pgtable-64.h +5 -3
@@ -61,12 +61,14 @@ static inline void pud_clear(pud_t *pudp)static inline pmd_t *pud_pgtable (pud_t pud) { -return (pmd_t *)pfn_to_virt (pud_val (pud) >> _PAGE_PFN_SHIFT); +return (pmd_t *)pfn_to_virt ((pud_val (pud) & _PAGE_CHG_MASK) + >> _PAGE_PFN_SHIFT); }static inline struct page *pud_page (pud_t pud) { -return pfn_to_page (pud_val (pud) >> _PAGE_PFN_SHIFT); +return pfn_to_page ((pud_val (pud) & _PAGE_CHG_MASK) + >> _PAGE_PFN_SHIFT); }static inline pmd_t pfn_pmd (unsigned long pfn,pgprot_t prot)
@@ -76,7 +78,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)static inline unsigned long _pmd_pfn (pmd_t pmd) { -return pmd_val (pmd) >> _PAGE_PFN_SHIFT; +return (pmd_val (pmd) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT; }#define mk_pmd (page, prot) pfn_pmd(page_to_pfn(page), prot)
arch/riscv/include/asm/pgtable-bits.h +44 -2
64 lines not on this page · raw message
arch/riscv/include/asm/pgtable.h +20 -10
@@ -115,7 +115,7 @@#define USER_PTRS_PER_PGD (TASK_SIZE / PGDIR_SIZE)/* Page protection bits */ -#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_USER) +#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_USER | _PAGE_DMA_PMA)#define PAGE_NONE __pgprot(_PAGE_PROT_NONE)#define PAGE_READ __pgprot(_PAGE_BASE | _PAGE_READ)
@@ -136,7 +136,8 @@ | _PAGE_PRESENT \ | _PAGE_ACCESSED \ | _PAGE_DIRTY \ - | _PAGE_GLOBAL) + | _PAGE_GLOBAL \ + | _PAGE_DMA_PMA)#define PAGE_KERNEL __pgprot(_PAGE_KERNEL)#define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
@@ -146,11 +147,9 @@#define PAGE_TABLE __pgprot(_PAGE_TABLE) -/* -* The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't -* change the properties of memory regions. -*/ -#define _PAGE_IOREMAP _PAGE_KERNEL +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_DMA_MASK) | _PAGE_DMA_IO) + +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP)extern pgd_t swapper_pg_dir[];
@@ -230,12 +229,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)static inline struct page *pmd_page (pmd_t pmd) { -return pfn_to_page (pmd_val (pmd) >> _PAGE_PFN_SHIFT); +return pfn_to_page ((pmd_val (pmd) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT); }static inline unsigned long pmd_page_vaddr (pmd_t pmd) { -return (unsigned long )pfn_to_virt (pmd_val (pmd) >> _PAGE_PFN_SHIFT); +return (unsigned long )pfn_to_virt ((pmd_val (pmd) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT); }static inline pte_t pmd_pte (pmd_t pmd)
@@ -251,7 +250,7 @@ static inline pte_t pud_pte(pud_t pud)/* Yields the page frame number (PFN) of a page table entry */ static inline unsigned long pte_pfn (pte_t pte) { -return (pte_val (pte) >> _PAGE_PFN_SHIFT); +return ((pte_val (pte) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT); }#define pte_page (x) pfn_to_page(pte_pfn(x))
@@ -490,6 +489,17 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,return ptep_test_and_clear_young (vma, address, ptep); } +#define pgprot_noncached pgprot_noncached +static inline pgprot_t pgprot_noncached (pgprot_t _prot) +{ +unsigned long prot =pgprot_val (_prot); + + prot &= ~_PAGE_DMA_MASK; + prot |= _PAGE_DMA_IO; + +return __pgprot (prot); +} +/* * THP functions */
arch/riscv/include/asm/vendorid_list.h +1 -0
@@ -6,5 +6,6 @@#define ASM_VENDOR_LIST_H #define SIFIVE_VENDOR_ID 0x489 +#define THEAD_VENDOR_ID 0x5b7#endif
arch/riscv/mm/init.c +6 -0
@@ -577,6 +577,7 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)#ifndef __PAGETABLE_PMD_FOLDEDpmd_t fix_bmap_spmd, fix_bmap_epmd;#endif +apply_errata_setup_vm ();setup_protection_map ();
@@ -927,3 +928,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, return vmemmap_populate_basepages(start, end, node, NULL); }#endif + +#ifdef CONFIG_64BIT +struct __riscv_pbmt_struct __riscv_pbmt__ro_after_init ; +EXPORT_SYMBOL (__riscv_pbmt); +#endif
Signature · 1 line
2.25.1
Re: [RFC PATCH V4 2/6] riscv: errata: pgtable: Add custom Svpbmt supported for Allwinner D1
This is the wrong way around. We need to design around the PBMT definitions. If we want to hack in support for completely broken SOCs that intentionally violate the specification it should be done after the fact, in a separate patch, using alternatives and clearly documenting how broken these SOCs are.
Re: [RFC PATCH V4 2/6] riscv: errata: pgtable: Add custom Svpbmt supported for Allwinner D1
Quoted 3 lines · Christoph Hellwig
This is the wrong way around. We need to design around the PBMT definitions.
I've defined them in arch/riscv/include/asm/pgtable-bits.h first, that follow current latest draft. Then I undefine them in errata/thead/errata.c to illustrate we should follow standard PBMT, not a custom one.
Quoted 3 lines
If we want to hack in support for completely broken SOCs that intentionally violate the specification it should be done after the fact,
When c9xx was released in 2018, there is no clear direction for how to solve the non-coherent problem. We just thought PBMT is the correct direction, but we can't predict how encoding exactly in the highest bits. (Maybe we should keep the highest bits zero for _P/SXXX in pgtable.h, but it was really hard to guess at that time.) So don't imply we "intentionally" here! When the svpbmt is frozen in the future, we would follow that in our next-generation processor.
Quoted 2 lines
in a separate patch, using alternatives and clearly documenting how broken these SOCs are.
Okay, I would separate errata into another patch.
About documenting, I've illustrated c9xx PTE format's detail and using undef _PAGE_XXX to show that we replaced standard's in errata:
+/*
+ * T-HEAD C9xx PTE format:
+ * | 63 | 62 | 61 | 60 | 59-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
+ * SO C B SH RSW D A G U X W R V + * ^ ^ ^ ^ ^
+ * BIT(63): SO - Strong Order
+ * BIT(62): C - Cacheable
+ * BIT(61): B - Bufferable
+ * BIT(60): SH - Shareable
+ *
+ * MT_MASK : [63 - 59]
+ * MT_PMA : C + SH + * MT_NC : (none) + * MT_IO : SO
+ */
+#undef _PAGE_MT_MASK
+#undef _PAGE_MT_PMA
+#undef _PAGE_MT_NC
+#undef _PAGE_MT_IO
+
+#define _PAGE_MT_MASK 0xf800000000000000 +#define _PAGE_MT_PMA 0x5000000000000000 +#define _PAGE_MT_NC 0x0 +#define _PAGE_MT_IO 0x8000000000000000
+#endif
Signature · 4 lines
Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [RFC PATCH V4 2/6] riscv: errata: pgtable: Add custom Svpbmt supported for Allwinner D1
In reply to [email protected]Quoted 430 lines · On Sat, Sep 11, 2021 at 2:23 AM <[email protected]> wrote:
From: Guo Ren <[email protected]>
RISC-V Svpbmt is gradually maturing, the draft is:
Svpbmt PTE format:
| 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 N MT RSW D A G U X W R V ^Of the Reserved bits [63:54] in a leaf PTE, the high bit is already allocated (as the N bit), so bits [62:61] are used as the MT (aka MemType) field. This field specifies one of three memory types that are close equivalents (or equivalent in effect) to the three main x86 and ARMv8 memory types - as shown in the following table.
RISC-V
Encoding &MemType RISC-V Description ---------- ------------------------------------------------ 00 - PMA Normal Cacheable, No change to implied PMA memory type 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory 11 - Rsvd Reserved for future standard useBut T-HEAD C906 in Allwinner D1 has defined a custom Svpbmt:
T-HEAD C9xx PTE format:
| 63 | 62 | 61 | 60 | 59-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 SO C B SH RSW D A G U X W R V ^ ^ ^ ^BIT(63): SO - Strong Order
BIT(62): C - Cacheable
BIT(61): B - Bufferable
BIT(60): SH - Shareable
MT_MASK: [63 - 59]MT_PMA: C + SHMT_NC: (none)MT_IO: SOThe patch not only implements the D1's PBMT extension but also considers future scalability by errata framework.
We are trying to keep both below work together:
- "riscv spec acceptance policy" (Svpbmt extension in future)
- "Linux Keep real hardware work" (Allwinner D1's custom Svpbmt)Signed-off-by Guo Ren <[email protected]>Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Anup Patel <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Drew Fustini <[email protected]>Cc Wei Fu <[email protected]>Cc Wei Wu <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Maxime Ripard <[email protected]>Cc Daniel Lustig <[email protected]>Cc Greg Favor <[email protected]>Cc Andrea Mondelli <[email protected]>Cc Jonathan Behrens <[email protected]>Cc Xinhaoqu (Freddie) <[email protected]>Cc Bill Huffman <[email protected]>Cc Nick Kossifidis <[email protected]>Cc Allen Baum <[email protected]>Cc Josh Scheid <[email protected]>Cc Richard Trauben <[email protected]>--- arch/riscv/Kconfig.erratas | 11 ++++++ arch/riscv/errata/Makefile | 1 + arch/riscv/errata/alternative.c | 18 ++++++++++ arch/riscv/errata/thead/Makefile | 1 + arch/riscv/errata/thead/errata.c | 47 ++++++++++++++++++++++++++ arch/riscv/include/asm/alternative.h | 2 ++ arch/riscv/include/asm/fixmap.h | 2 +- arch/riscv/include/asm/pgtable-64.h | 8 +++-- arch/riscv/include/asm/pgtable-bits.h | 46 +++++++++++++++++++++++-- arch/riscv/include/asm/pgtable.h | 30 ++++++++++------ arch/riscv/include/asm/vendorid_list.h | 1 + arch/riscv/mm/init.c | 6 ++++ 12 files changed, 157 insertions(+), 16 deletions(-) create mode 100644 arch/riscv/errata/thead/Makefile create mode 100644 arch/riscv/errata/thead/errata.carch/riscv/Kconfig.erratas +11
-0@@ -41,4 +41,15 @@ config ERRATA_SIFIVE_CIP_1200 If you don't know what to do here, say "Y". +config ERRATA_THEAD + bool "T-HEAD errata" + depends on RISCV_ERRATA_ALTERNATIVE + default y + help + All T-HEAD errata Kconfig depend on this Kconfig. Disabling + this Kconfig will disable all T-HEAD errata. Please say "Y" + here if your platform uses T-HEAD CPU cores. + + Otherwise, please say "N" here to avoid unnecessary overhead. + endmenuarch/riscv/errata/Makefile +1
-0@@ -1,2 +1,3 @@ obj-y += alternative.o obj-$(CONFIG_ERRATA_SIFIVE) += sifive/ +obj-$(CONFIG_ERRATA_THEAD) += thead/arch/riscv/errata/alternative.c +18
-0@@ -72,3 +72,21 @@ void __init apply_boot_alternatives(void) cpu_mfr_info.arch_id, cpu_mfr_info.imp_id); } +/* +* This is called very early form setup_vm in the boot process. +*/ +void __init apply_errata_setup_vm (void ) +{ +riscv_fill_cpu_mfr_info (); + +switch (cpu_mfr_info.vendor_id) { +#ifdef CONFIG_ERRATA_THEAD +case THEAD_VENDOR_ID : +thead_errata_setup_vm (cpu_mfr_info.arch_id, + cpu_mfr_info.imp_id); +break ; +#endif +default : +break ; + } +}arch/riscv/errata/thead/Makefile new file +1
-0@@ -0,0 +1 @@ +obj-y += errata.oarch/riscv/errata/thead/errata.c new file +47
-0@@ -0,0 +1,47 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#include <linux/kernel.h> +#include <linux/string.h> +#include <linux/bug.h> +#include <asm/patch.h> +#include <asm/alternative.h> +#include <asm/vendorid_list.h> +#include <asm/errata_list.h> +#include <asm/pgtable-bits.h> + +#ifdef CONFIG_64BIT +/* +* T-HEAD C9xx PTE format: +* | 63 | 62 | 61 | 60 | 59-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 +* SO C B SH RSW D A G U X W R V +* ^ ^ ^ ^ ^ +* BIT(63): SO - Strong Order +* BIT(62): C - Cacheable +* BIT(61): B - Bufferable +* BIT(60): SH - Shareable +* +* MT_MASK : [63 - 59] +* MT_PMA : C + SH +* MT_NC : (none) +* MT_IO : SO +*/ +#undef _PAGE_MT_MASK +#undef _PAGE_MT_PMA +#undef _PAGE_MT_NC +#undef _PAGE_MT_IO + +#define _PAGE_MT_MASK 0xf800000000000000 +#define _PAGE_MT_PMA 0x5000000000000000 +#define _PAGE_MT_NC 0x0 +#define _PAGE_MT_IO 0x8000000000000000 +#endif + +void __init thead_errata_setup_vm (unsigned long archid,unsigned long impid) +{ +#ifdef CONFIG_64BIT + __riscv_pbmt.mask = _PAGE_MT_MASK; + __riscv_pbmt.mt[MT_PMA ] = _PAGE_MT_PMA; + __riscv_pbmt.mt[MT_NC ] = _PAGE_MT_NC; + __riscv_pbmt.mt[MT_IO ] = _PAGE_MT_IO; +#endif +}arch/riscv/include/asm/alternative.h +2
-0@@ -18,6 +18,7 @@#include <asm/hwcap.h> void __init apply_boot_alternatives (void ); +void __init apply_errata_setup_vm (void );struct alt_entry {void *old_ptr;/* address of original instruciton or data */ @@ -35,5 +36,6 @@ struct errata_checkfunc_id {void sifive_errata_patch_func (struct alt_entry *begin,struct alt_entry *end,unsigned long archid,unsigned long impid); +void thead_errata_setup_vm (unsigned long archid,unsigned long impid);#endif #endif arch/riscv/include/asm/fixmap.h +1
-1@@ -43,7 +43,7 @@ enum fixed_addresses { __end_of_fixed_addresses }; -#define FIXMAP_PAGE_IO PAGE_KERNEL +#define FIXMAP_PAGE_IO PAGE_IOREMAP#define __early_set_fixmap __set_fixmaparch/riscv/include/asm/pgtable-64.h +5
-3@@ -61,12 +61,14 @@ static inline void pud_clear(pud_t *pudp)static inline pmd_t *pud_pgtable (pud_t pud) { -return (pmd_t *)pfn_to_virt (pud_val (pud) >> _PAGE_PFN_SHIFT); +return (pmd_t *)pfn_to_virt ((pud_val (pud) & _PAGE_CHG_MASK) + >> _PAGE_PFN_SHIFT); }static inline struct page *pud_page (pud_t pud) { -return pfn_to_page (pud_val (pud) >> _PAGE_PFN_SHIFT); +return pfn_to_page ((pud_val (pud) & _PAGE_CHG_MASK) + >> _PAGE_PFN_SHIFT); }static inline pmd_t pfn_pmd (unsigned long pfn,pgprot_t prot)@@ -76,7 +78,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)static inline unsigned long _pmd_pfn (pmd_t pmd) { -return pmd_val (pmd) >> _PAGE_PFN_SHIFT; +return (pmd_val (pmd) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT; }#define mk_pmd (page, prot) pfn_pmd(page_to_pfn(page), prot)arch/riscv/include/asm/pgtable-bits.h +44
-2@@ -7,7 +7,7 @@#define _ASM_RISCV_PGTABLE_BITS_H/* -* PTE format: +* rv32 PTE format: * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 * PFN reserved for SW D A G U X W R V */ @@ -24,6 +24,47 @@#define _PAGE_DIRTY (1 << 7)/* Set by hardware on any write */ #define _PAGE_SOFT (1 << 8)/* Reserved for software */ +#ifndef __ASSEMBLY__ +#ifdef CONFIG_64BIT +/* +* rv64 PTE format: +* | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 +* N MT RSV PFN reserved for SW D A G U X W R V +* [62:61] Memory Type definitions: +* 00 - PMA Normal Cacheable, No change to implied PMA memory type +* 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory +* 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory +* 11 - Rsvd Reserved for future standard use +*/ +#define _PAGE_MT_MASK ((u64)0x3 << 61) +#define _PAGE_MT_PMA ((u64)0x0 << 61) +#define _PAGE_MT_NC ((u64)0x1 << 61) +#define _PAGE_MT_IO ((u64)0x2 << 61) + +enum { +MT_PMA , +MT_NC , +MT_IO , +MT_MAX +}; + +extern struct __riscv_pbmt_struct { +unsigned long mask; +unsigned long mt[MT_MAX ]; +} __riscv_pbmt; + +#define _PAGE_DMA_MASK __riscv_pbmt.mask +#define _PAGE_DMA_PMA __riscv_pbmt.mt[MT_PMA] +#define _PAGE_DMA_NC __riscv_pbmt.mt[MT_NC] +#define _PAGE_DMA_IO __riscv_pbmt.mt[MT_IO] +#else +#define _PAGE_DMA_MASK 0 +#define _PAGE_DMA_PMA 0 +#define _PAGE_DMA_NC 0 +#define _PAGE_DMA_IO 0 +#endif /* CONFIG_64BIT */ +#endif /* __ASSEMBLY__ */ +#define _PAGE_SPECIAL _PAGE_SOFT#define _PAGE_TABLE _PAGE_PRESENT@@ -38,7 +79,8 @@/* Set of bits to preserve across pte_modify() */ #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ _PAGE_WRITE | _PAGE_EXEC | \ - _PAGE_USER | _PAGE_GLOBAL)) + _PAGE_USER | _PAGE_GLOBAL | \ + _PAGE_DMA_MASK))/* * when all of R/W/X are zero, the PTE is a pointer to the next level * of the page table; otherwise, it is a leaf PTE. arch/riscv/include/asm/pgtable.h +20
-10@@ -115,7 +115,7 @@#define USER_PTRS_PER_PGD (TASK_SIZE / PGDIR_SIZE)/* Page protection bits */ -#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_USER) +#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_USER | _PAGE_DMA_PMA)#define PAGE_NONE __pgprot(_PAGE_PROT_NONE)#define PAGE_READ __pgprot(_PAGE_BASE | _PAGE_READ)@@ -136,7 +136,8 @@ | _PAGE_PRESENT \ | _PAGE_ACCESSED \ | _PAGE_DIRTY \ - | _PAGE_GLOBAL) + | _PAGE_GLOBAL \ + | _PAGE_DMA_PMA)#define PAGE_KERNEL __pgprot(_PAGE_KERNEL)#define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)@@ -146,11 +147,9 @@#define PAGE_TABLE __pgprot(_PAGE_TABLE) -/* -* The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't -* change the properties of memory regions. -*/ -#define _PAGE_IOREMAP _PAGE_KERNEL +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_DMA_MASK) | _PAGE_DMA_IO) + +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP)extern pgd_t swapper_pg_dir[];@@ -230,12 +229,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)static inline struct page *pmd_page (pmd_t pmd) { -return pfn_to_page (pmd_val (pmd) >> _PAGE_PFN_SHIFT); +return pfn_to_page ((pmd_val (pmd) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT); }static inline unsigned long pmd_page_vaddr (pmd_t pmd) { -return (unsigned long )pfn_to_virt (pmd_val (pmd) >> _PAGE_PFN_SHIFT); +return (unsigned long )pfn_to_virt ((pmd_val (pmd) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT); }static inline pte_t pmd_pte (pmd_t pmd)@@ -251,7 +250,7 @@ static inline pte_t pud_pte(pud_t pud)/* Yields the page frame number (PFN) of a page table entry */ static inline unsigned long pte_pfn (pte_t pte) { -return (pte_val (pte) >> _PAGE_PFN_SHIFT); +return ((pte_val (pte) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT); }#define pte_page (x) pfn_to_page(pte_pfn(x))@@ -490,6 +489,17 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,return ptep_test_and_clear_young (vma, address, ptep); } +#define pgprot_noncached pgprot_noncached +static inline pgprot_t pgprot_noncached (pgprot_t _prot) +{ +unsigned long prot =pgprot_val (_prot); + + prot &= ~_PAGE_DMA_MASK; + prot |= _PAGE_DMA_IO; + +return __pgprot (prot); +} +/* * THP functions */ arch/riscv/include/asm/vendorid_list.h +1
-0@@ -6,5 +6,6 @@#define ASM_VENDOR_LIST_H #define SIFIVE_VENDOR_ID 0x489 +#define THEAD_VENDOR_ID 0x5b7#endif arch/riscv/mm/init.c +0
-0
arch/riscv/mm/init.c asmlinkage void __init setup_vm(uintptr_t dtb_pa) · line 580
Quoted 4 lines
arch/riscv/mm/init.c +1
-0@@ -577,6 +577,7 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)#ifndef __PAGETABLE_PMD_FOLDEDpmd_t fix_bmap_spmd, fix_bmap_epmd;#endif +apply_errata_setup_vm ();
We probably should call this only if pbmt extension is present. We need to dynamically determine
the presence of PBMT anyways because DIRECT_REMAP will be enabled for all platforms (single defconfig).
We need to think about all the following possible platforms with different types of cache coherent I/O devices.
1. platform supporting standard PBMT extensions (future ones)
2. platform with custom PBMT extension (Allwinner D1)
3. platform with uncached window approach (starlight)
4. platform with fully cache coherent IO (hifive unleashed/unmatched)
I think a simple global flag based on a DT property should be sufficient. DMA generic code may also need to check
if the platform supports direct_remap in addition to checking the config option.
For the DT property, we should define a generic extensible DT binding for ISA extensions so that future ISA extensions
should be able to leverage that.
Just food for thought for RISC-V MC at plumbers next week.
Quoted 16 lines
arch/riscv/mm/init.c +5
-1setup_protection_map ();@@ -927,3 +928,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, return vmemmap_populate_basepages(start, end, node, NULL); }#endif + +#ifdef CONFIG_64BIT +struct __riscv_pbmt_struct __riscv_pbmt__ro_after_init ; +EXPORT_SYMBOL (__riscv_pbmt); +#endif --2.25.1
Quoted 4 lines
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Regards,
Atish
RFC PATCH v4 3/6 RISC-V: Support a new config option for non-coherent DMA
In reply to [email protected]From: Atish Patra <[email protected]>
In future, there will be more RISC-V platforms with non-coherent DMA. Instead of selecting all the required config options in every soc, create a new config that selects all the required configs related non-coherent DMA.
RISC-V: Support DMA_DIRECT_REMAP for non-coherent DMA
--- arch/riscv/Kconfig | 9 +++++++++ 1 file changed, 9 insertions(+)
arch/riscv/Kconfig +9 -0
@@ -213,6 +213,15 @@ config PGTABLE_LEVELS config LOCKDEP_SUPPORT def_bool y +config RISCV_DMA_NONCOHERENT + bool + select ARCH_HAS_DMA_PREP_COHERENT + select ARCH_HAS_SYNC_DMA_FOR_DEVICE + select ARCH_HAS_SYNC_DMA_FOR_CPU + select ARCH_HAS_SETUP_DMA_OPS + select DMA_GLOBAL_POOL + select DMA_DIRECT_REMAP + source "arch/riscv/Kconfig.socs" source "arch/riscv/Kconfig.erratas"
Signature · 1 line
2.25.1
Re: [RFC PATCH V4 3/6] RISC-V: Support a new config option for non-coherent DMA
arch/riscv/Kconfig config PGTABLE_LEVELS · line 223
Quoted 2 lines · On Sat, Sep 11, 2021 at 05:21:36PM +0800, [email protected] wrote:
arch/riscv/Kconfig +2
-0+ select DMA_GLOBAL_POOL + select DMA_DIRECT_REMAP
No need to select DMA_GLOBAL_POOL when DMA_DIRECT_REMAP is select.
Also a patch just to add a option that is not selected and won't build if selected does not make sense.
Re: [RFC PATCH V4 3/6] RISC-V: Support a new config option for non-coherent DMA
Quoted 6 lines · Christoph Hellwig
Review
Quoted 2 lines · On Sat, Sep 11, 2021 at 05:21:36PM +0800, [email protected] wrote:
(quoted diff) +2
-0+ select DMA_GLOBAL_POOL + select DMA_DIRECT_REMAPNo need to select
DMA_GLOBAL_POOLwhenDMA_DIRECT_REMAPis select.
If we want to support PBMT & global_dma_pool both in riscv. Could they work together in arch/riscv with [1]?
[1]: https://lore.kernel.org/lkml/[email protected]/T/
Quoted 3 lines
Also a patch just to add a option that is not selected and won't build if selected does not make sense.
I just want to rebase on Atish's patch and append DMA_DIRECT_REMAP. Okay, DMA_DIRECT_REMAP & DMA_GLOBAL_POOL should be separated from the patch.
kernel/dma/direct.c +13 -0
@@ -156,9 +156,14 @@ void *dma_direct_alloc(struct device *dev, size_t size,if (!IS_ENABLED (CONFIG_ARCH_HAS_DMA_SET_UNCACHED ) && !IS_ENABLED (CONFIG_DMA_DIRECT_REMAP ) && + !IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && !dev_is_dma_coherent (dev))return arch_dma_alloc (dev, size, dma_handle, gfp, attrs); +if (IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && + !dev_is_dma_coherent (dev)) +return dma_alloc_from_global_coherent (dev, size, dma_handle); +/* * Remapping or decrypting memory may block. If either is required and * we can't block, allocate the memory from the atomic pools.
@@ -255,11 +260,19 @@ void dma_direct_free(struct device *dev, size_t size,if (!IS_ENABLED (CONFIG_ARCH_HAS_DMA_SET_UNCACHED ) && !IS_ENABLED (CONFIG_DMA_DIRECT_REMAP ) && + !IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && !dev_is_dma_coherent (dev)) {arch_dma_free (dev, size, cpu_addr, dma_addr, attrs);return ; } +if (IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && + !dev_is_dma_coherent (dev)) { +if (!dma_release_from_global_coherent (page_order, cpu_addr)) +WARN_ON_ONCE (1 ); +return ; + } +
Here CONFIG_DMA_GLOBAL_POOL is independent from CONFIG_DMA_DIRECT_REMAP.
/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */ if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
dma_free_from_pool(dev, cpu_addr, PAGE_ALIGN(size)))
Signature · 4 lines
Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [RFC PATCH V4 3/6] RISC-V: Support a new config option for non-coherent DMA
Quoted 10 lines · Guo Ren
Quoted 6 lines · Christoph Hellwig
Review
Quoted 2 lines · On Sat, Sep 11, 2021 at 05:21:36PM +0800, [email protected] wrote:
(quoted diff) +2
-0+ select DMA_GLOBAL_POOL + select DMA_DIRECT_REMAPNo need to select
DMA_GLOBAL_POOLwhenDMA_DIRECT_REMAPis select.If we want to support PBMT &
global_dma_poolboth in riscv. Could they work together inarch/riscvwith [1]?
We don't have to worry about it as the next version of my series will use the simplerdma_uncached functionality to support uncached window approach taken by starlight socs.
I was supposed to send it sooner but got busy with PMU stuff and a bad flu :(.
Quoted 62 lines
[1]: https://lore.kernel.org/lkml/[email protected]/T/
Quoted 3 lines
Also a patch just to add a option that is not selected and won't build if selected does not make sense.
I just want to rebase on Atish's patch and append
DMA_DIRECT_REMAP. Okay,DMA_DIRECT_REMAP&DMA_GLOBAL_POOLshould be separated from the patch.kernel/dma/direct.c +13
-0@@ -156,9 +156,14 @@ void *dma_direct_alloc(struct device *dev, size_t size,if (!IS_ENABLED (CONFIG_ARCH_HAS_DMA_SET_UNCACHED ) && !IS_ENABLED (CONFIG_DMA_DIRECT_REMAP ) && + !IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && !dev_is_dma_coherent (dev))return arch_dma_alloc (dev, size, dma_handle, gfp, attrs); +if (IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && + !dev_is_dma_coherent (dev)) +return dma_alloc_from_global_coherent (dev, size, dma_handle); +/* * Remapping or decrypting memory may block. If either is required and * we can't block, allocate the memory from the atomic pools. @@ -255,11 +260,19 @@ void dma_direct_free(struct device *dev, size_t size,if (!IS_ENABLED (CONFIG_ARCH_HAS_DMA_SET_UNCACHED ) && !IS_ENABLED (CONFIG_DMA_DIRECT_REMAP ) && + !IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && !dev_is_dma_coherent (dev)) {arch_dma_free (dev, size, cpu_addr, dma_addr, attrs);return ; } +if (IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && + !dev_is_dma_coherent (dev)) { +if (!dma_release_from_global_coherent (page_order, cpu_addr)) +WARN_ON_ONCE (1 ); +return ; + } +Here
CONFIG_DMA_GLOBAL_POOLis independent fromCONFIG_DMA_DIRECT_REMAP./* If
cpu_addris not from an atomic pool,dma_free_from_pool()fails */ if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL)&&
dma_free_from_pool(dev, cpu_addr, PAGE_ALIGN(size)))--
Best Regards
Guo RenML: https://lore.kernel.org/linux-csky/
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Signature · 2 lines
Regards, Atish
Re: [RFC PATCH V4 3/6] RISC-V: Support a new config option for non-coherent DMA
Quoted 9 lines · Atish Patra
Quoted 7 lines · Guo Ren
Quoted 5 lines · Christoph Hellwig
Quoted 2 lines · On Sat, Sep 11, 2021 at 05:21:36PM +0800, [email protected] wrote:
(quoted diff) +2
-0+ select DMA_GLOBAL_POOL + select DMA_DIRECT_REMAP
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
No need to select
DMA_GLOBAL_POOLwhenDMA_DIRECT_REMAPis select.If we want to support PBMT &
global_dma_poolboth in riscv. Could they work together inarch/riscvwith [1]?We don't have to worry about it as the next version of my series will use the simpler
dma_uncachedfunctionality to support uncached window approach taken by starlight socs.
Sounds good, thx.
Quoted 2 lines
I was supposed to send it sooner but got busy with PMU stuff and a bad flu :(.
Take good care of yourself and hope you feel better soon.
Quoted 69 lines
Quoted 57 lines
[1]: https://lore.kernel.org/lkml/[email protected]/T/
Quoted 3 lines
Also a patch just to add a option that is not selected and won't build if selected does not make sense.
I just want to rebase on Atish's patch and append
DMA_DIRECT_REMAP. Okay,DMA_DIRECT_REMAP&DMA_GLOBAL_POOLshould be separated from the patch.kernel/dma/direct.c +13
-0@@ -156,9 +156,14 @@ void *dma_direct_alloc(struct device *dev, size_t size,if (!IS_ENABLED (CONFIG_ARCH_HAS_DMA_SET_UNCACHED ) && !IS_ENABLED (CONFIG_DMA_DIRECT_REMAP ) && + !IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && !dev_is_dma_coherent (dev))return arch_dma_alloc (dev, size, dma_handle, gfp, attrs); +if (IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && + !dev_is_dma_coherent (dev)) +return dma_alloc_from_global_coherent (dev, size, dma_handle); +/* * Remapping or decrypting memory may block. If either is required and * we can't block, allocate the memory from the atomic pools. @@ -255,11 +260,19 @@ void dma_direct_free(struct device *dev, size_t size,if (!IS_ENABLED (CONFIG_ARCH_HAS_DMA_SET_UNCACHED ) && !IS_ENABLED (CONFIG_DMA_DIRECT_REMAP ) && + !IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && !dev_is_dma_coherent (dev)) {arch_dma_free (dev, size, cpu_addr, dma_addr, attrs);return ; } +if (IS_ENABLED (CONFIG_DMA_GLOBAL_POOL ) && + !dev_is_dma_coherent (dev)) { +if (!dma_release_from_global_coherent (page_order, cpu_addr)) +WARN_ON_ONCE (1 ); +return ; + } +Here
CONFIG_DMA_GLOBAL_POOLis independent fromCONFIG_DMA_DIRECT_REMAP./* If
cpu_addris not from an atomic pool,dma_free_from_pool()fails */ if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL)&&
dma_free_from_pool(dev, cpu_addr, PAGE_ALIGN(size)))--
Best Regards
Guo RenQuoted 6 lines
ML: https://lore.kernel.org/linux-csky/
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv--
Regards,
Atish
Signature · 4 lines
Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
RFC PATCH v4 4/6 RISC-V: Implement arch_sync_dma* functions
In reply to [email protected]From: Atish Patra <[email protected]>
To facilitate streaming DMA APIs, this patch introduces a set of generic cache operations related dma sync. Any platform can use the generic ops to provide platform specific cache management operations. Once the standard RISC-V CMO extension is available, it can be built on top of it.
Below Added by Guo Ren:
1. Fixup arch_sync_dma_for_cpu with "add DMA_TO_DEVICE force" by Guo Ren and follow the tips by Christoph:
/*
* Cache operations depending on function and direction argument, inspired by
* https://lkml.org/lkml/2018/5/18/979
* "dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20]
* dma-mapping: provide a generic dma-noncoherent implementation)" *
* | map == for_device | unmap == for_cpu * |---------------------------------------------------------------- * TO_DEV | writeback writeback | none none * FROM_DEV | invalidate invalidate | invalidate* invalidate* * BIDIR | writeback+inv writeback+inv | invalidate invalidate
*
* [*] needed for CPU speculative prefetches
*
* NOTE: we don't check the validity of direction argument as it is done in
* upper layer functions (in include/linux/dma-mapping.h)
*/
2. Christoph:
As told a bunch of times before: doing indirect calls here is a performance nightmare. Use something that actually does perform horribly like alternatives. Or even delay implementing that until
^^^^^^^^^^^^ Agree, and TODO in Atish next path?
we need it and do a plain direct call for now.
--- arch/riscv/include/asm/dma-noncoherent.h | 19 +++++++ arch/riscv/mm/Makefile | 1 + arch/riscv/mm/dma-noncoherent.c | 66 ++++++++++++++++++++++++ 3 files changed, 86 insertions(+) create mode 100644 arch/riscv/include/asm/dma-noncoherent.h create mode 100644 arch/riscv/mm/dma-noncoherent.c
arch/riscv/include/asm/dma-noncoherent.h new file +19 -0
@@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* +* Copyright (c) 2021 Western Digital Corporation or its affiliates. +*/ + +#ifndef __ASM_RISCV_DMA_NON_COHERENT_H +#define __ASM_RISCV_DMA_NON_COHERENT_H + +#ifdef CONFIG_RISCV_DMA_NONCOHERENT +struct riscv_dma_cache_sync { +void (*cache_invalidate)(phys_addr_t paddr,size_t size); +void (*cache_clean)(phys_addr_t paddr,size_t size); +void (*cache_flush)(phys_addr_t paddr,size_t size); +}; + +void riscv_dma_cache_sync_set (struct riscv_dma_cache_sync *ops); +#endif + +#endif
arch/riscv/mm/Makefile +1 -0
@@ -27,3 +27,4 @@ KASAN_SANITIZE_init.o := n endif obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o +obj-$(CONFIG_RISCV_DMA_NONCOHERENT) += dma-noncoherent.o
arch/riscv/mm/dma-noncoherent.c new file +66 -0
66 lines not on this page · raw message
Signature · 1 line
2.25.1
Re: [RFC PATCH V4 4/6] RISC-V: Implement arch_sync_dma* functions
arch/riscv/mm/dma-noncoherent.c line 29
Quoted 9 lines · On Sat, Sep 11, 2021 at 05:21:37PM +0800, [email protected] wrote:
arch/riscv/mm/dma-noncoherent.c new file +9
-0+static void __dma_sync (phys_addr_t paddr,size_t size,enum dma_data_direction dir) +{ +if ((dir ==DMA_FROM_DEVICE ) && (dma_cache_sync->cache_invalidate)) + dma_cache_sync->cache_invalidate (paddr, size); +else if ((dir ==DMA_TO_DEVICE ) && (dma_cache_sync->cache_clean)) + dma_cache_sync->cache_clean (paddr, size); +else if ((dir ==DMA_BIDIRECTIONAL ) && dma_cache_sync->cache_flush) + dma_cache_sync->cache_flush (paddr, size); +}
Despite various snipplets this is a still pretty much the broken previous versions. These need to use the CMO instructions directly which are about to go into review, and then your SBI can trap on those can call whatever non-standard mess you're using.
Re: [RFC PATCH V4 4/6] RISC-V: Implement arch_sync_dma* functions
Quoted 16 lines · Christoph Hellwig
arch/riscv/mm/dma-noncoherent.c line 29
Quoted 9 lines · On Sat, Sep 11, 2021 at 05:21:37PM +0800, [email protected] wrote:
arch/riscv/mm/dma-noncoherent.c new file +9
-0+static void __dma_sync (phys_addr_t paddr,size_t size,enum dma_data_direction dir) +{ +if ((dir ==DMA_FROM_DEVICE ) && (dma_cache_sync->cache_invalidate)) + dma_cache_sync->cache_invalidate (paddr, size); +else if ((dir ==DMA_TO_DEVICE ) && (dma_cache_sync->cache_clean)) + dma_cache_sync->cache_clean (paddr, size); +else if ((dir ==DMA_BIDIRECTIONAL ) && dma_cache_sync->cache_flush) + dma_cache_sync->cache_flush (paddr, size); +}Despite various snipplets this is a still pretty much the broken previous versions. These need to use the CMO instructions directly which are about to go into review, and then your SBI can trap on those can call whatever non-standard mess you're using.
I think you mean put an ALTERNATIVE slot in the prologue of __dma_sync?
#define ALT_DMA_SYNC() \
asm(ALTERNATIVE(".rept 64\n nop\n .endr\n", "<vendor code>",
XXX_VENDOR_ID, \
ERRATA_XXX, CONFIG_ERRATA_XXX) \
: : : "memory")static void __dma_sync(phys_addr_t paddr, size_t size, enum dma_data_direction dir)
{
ALT_DMA_SYNC();
/* future cmo codes */
}Signature · 4 lines
Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [RFC PATCH V4 4/6] RISC-V: Implement arch_sync_dma* functions
Quoted 26 lines · Guo Ren
Quoted 16 lines · Christoph Hellwig
arch/riscv/mm/dma-noncoherent.c line 29
Quoted 9 lines · On Sat, Sep 11, 2021 at 05:21:37PM +0800, [email protected] wrote:
arch/riscv/mm/dma-noncoherent.c new file +9
-0+static void __dma_sync (phys_addr_t paddr,size_t size,enum dma_data_direction dir) +{ +if ((dir ==DMA_FROM_DEVICE ) && (dma_cache_sync->cache_invalidate)) + dma_cache_sync->cache_invalidate (paddr, size); +else if ((dir ==DMA_TO_DEVICE ) && (dma_cache_sync->cache_clean)) + dma_cache_sync->cache_clean (paddr, size); +else if ((dir ==DMA_BIDIRECTIONAL ) && dma_cache_sync->cache_flush) + dma_cache_sync->cache_flush (paddr, size); +}Despite various snipplets this is a still pretty much the broken previous versions. These need to use the CMO instructions directly which are about to go into review, and then your SBI can trap on those can call whatever non-standard mess you're using.
I think you mean put an ALTERNATIVE slot in the prologue of
__dma_sync?#define
ALT_DMA_SYNC()\
asm(ALTERNATIVE(".rept 64\n nop\n .endr\n", "<vendor code>",XXX_VENDOR_ID, \ ERRATA_XXX, CONFIG_ERRATA_XXX) \ : : : "memory")
Quoted 7 lines
static void
__dma_sync(phys_addr_t paddr, size_t size, enum dma_data_direction dir){ ALT_DMA_SYNC(); /* future cmo codes */ }
I think Christoph is suggesting to always use CMO instructions for implementing arch specific DMA sync functions. The SBI implementation will trap-n-emulate CMO instructions when underlying HW does not have it. This means custom cache instructions on D1 can reside in the platform support code of OpenSBI.
I also agree with the above suggestion. At least, this will ensure that we have only one way of doing cache operations from S-mode perspective which is CMO instructions.
Regards,
Anup
Quoted 9 lines
--
Best Regards
Guo Ren
Re: [RFC PATCH V4 4/6] RISC-V: Implement arch_sync_dma* functions
Quoted 42 lines · Anup Patel
Quoted 26 lines · Guo Ren
Quoted 16 lines · Christoph Hellwig
arch/riscv/mm/dma-noncoherent.c line 29
Quoted 9 lines · On Sat, Sep 11, 2021 at 05:21:37PM +0800, [email protected] wrote:
arch/riscv/mm/dma-noncoherent.c new file +9
-0+static void __dma_sync (phys_addr_t paddr,size_t size,enum dma_data_direction dir) +{ +if ((dir ==DMA_FROM_DEVICE ) && (dma_cache_sync->cache_invalidate)) + dma_cache_sync->cache_invalidate (paddr, size); +else if ((dir ==DMA_TO_DEVICE ) && (dma_cache_sync->cache_clean)) + dma_cache_sync->cache_clean (paddr, size); +else if ((dir ==DMA_BIDIRECTIONAL ) && dma_cache_sync->cache_flush) + dma_cache_sync->cache_flush (paddr, size); +}Despite various snipplets this is a still pretty much the broken previous versions. These need to use the CMO instructions directly which are about to go into review, and then your SBI can trap on those can call whatever non-standard mess you're using.
I think you mean put an ALTERNATIVE slot in the prologue of
__dma_sync?#define
ALT_DMA_SYNC()\
asm(ALTERNATIVE(".rept 64\n nop\n .endr\n", "<vendor code>",XXX_VENDOR_ID, \ ERRATA_XXX, CONFIG_ERRATA_XXX) \ : : : "memory")Quoted 7 lines
static void
__dma_sync(phys_addr_t paddr, size_t size, enum dma_data_direction dir){ ALT_DMA_SYNC(); /* future cmo codes */ }I think Christoph is suggesting to always use CMO instructions for implementing arch specific DMA sync functions. The SBI implementation will trap-n-emulate CMO instructions when underlying HW does not have it. This means custom cache instructions on D1 can reside in the platform support code of OpenSBI.
Quoted 4 lines
I also agree with the above suggestion. At least, this will ensure that we have only one way of doing cache operations from S-mode perspective which is CMO instructions.
Sounds good to me. For stralight Socs, we may need to add a l2 cache controller driver in OpenSBI as well. IIRC, sifive cores do have some M-mode only CMO instructions
as well but they may not align with CMO spec. I have to double check.
Quoted 17 lines
Regards,
AnupQuoted 9 lines
--
Best Regards
Guo Ren_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Signature · 2 lines
Regards, Atish
RFC PATCH v4 5/6 riscv: errata: Support T-HEAD custom dcache ops
In reply to [email protected]From: Guo Ren <[email protected]>
Here are the DMA sync ops needed by Allwinner D1. RISC-V CMO extension is still in progress, and D1 is using custom CMO instructions:
dcache.ipa rs1 (invalidate)
| 31 - 25 | 24 - 20 | 19 - 15 | 14 - 12 | 11 - 7 | 6 - 0 | 0000001 01010 rs1 000 00000 0001011
dcache.cpa rs1 (clean)
| 31 - 25 | 24 - 20 | 19 - 15 | 14 - 12 | 11 - 7 | 6 - 0 | 0000001 01001 rs1 000 00000 0001011
dcache.cipa rs1 (clean then invalidate)
| 31 - 25 | 24 - 20 | 19 - 15 | 14 - 12 | 11 - 7 | 6 - 0 | 0000001 01011 rs1 000 00000 0001011
sync.s (completion barrier)
| 31 - 25 | 24 - 20 | 19 - 15 | 14 - 12 | 11 - 7 | 6 - 0 | 0000000 11001 00000 000 00000 0001011
TODO:
- Using alternative patch_text based on Atish's patch.
--- arch/riscv/errata/alternative.c | 5 +++ arch/riscv/errata/thead/errata.c | 61 ++++++++++++++++++++++++++++ arch/riscv/include/asm/alternative.h | 2 + 3 files changed, 68 insertions(+)
arch/riscv/errata/alternative.c +5 -0
@@ -46,6 +46,11 @@ static void __init init_alternative(void)case SIFIVE_VENDOR_ID : vendor_patch_func = sifive_errata_patch_func;break ; +#endif +#ifdef CONFIG_ERRATA_THEAD +case THEAD_VENDOR_ID : + vendor_patch_func = thead_errata_patch_func; +break ;#endif default : vendor_patch_func =NULL ;
arch/riscv/errata/thead/errata.c +61 -0
70 lines not on this page · raw message
arch/riscv/include/asm/alternative.h +2 -0
@@ -35,6 +35,8 @@ struct errata_checkfunc_id {void sifive_errata_patch_func (struct alt_entry *begin,struct alt_entry *end,unsigned long archid,unsigned long impid); +void thead_errata_patch_func (struct alt_entry *begin,struct alt_entry *end, +unsigned long archid,unsigned long impid);void thead_errata_setup_vm (unsigned long archid,unsigned long impid);#endif
Signature · 1 line
2.25.1
RFC PATCH v4 6/6 riscv: soc: Add Allwinner SoC kconfig option
In reply to [email protected]From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when SOC_SUNXI selected.
--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)
arch/riscv/Kconfig.socs +15 -0
@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DW + select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. + endmenu
arch/riscv/configs/defconfig +1 -0
@@ -15,6 +15,7 @@ CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y CONFIG_BPF_SYSCALL=y CONFIG_SOC_SIFIVE=y +CONFIG_SOC_SUNXI=y CONFIG_SOC_VIRT=y CONFIG_SOC_MICROCHIP_POLARFIRE=y CONFIG_SMP=y
Signature · 1 line
2.25.1
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Hi,
Quoted 38 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +5
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 10 lines
arch/riscv/Kconfig.socs +10
-0+ select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DW + select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +
I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
These options should be in the defconfig.
Maxime
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 47 lines · Maxime Ripard
Hi,
Quoted 43 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +10
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DW
Quoted 8 lines
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 5 lines
arch/riscv/Kconfig.socs +5
-0+ select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
We just want people could bring D1 up easier, 8250 is the basic component.
Quoted 4 lines
These options should be in the defconfig.
Maxime
--
Best Regards
Guo Ren
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 56 lines · Guo Ren
Quoted 47 lines · Maxime Ripard
Hi,
Quoted 43 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +10
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DWQuoted 8 lines
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 5 lines
arch/riscv/Kconfig.socs +5
-0+ select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
Quoted 5 lines
We just want people could bring D1 up easier, 8250 is the basic component.
Quoted 2 lines
These options should be in the defconfig.
Agreed, using a defconfig is the right way to do this.
Signature · 1 line
~Randy
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 58 lines · Randy Dunlap
Quoted 56 lines · Guo Ren
Quoted 55 lines · Maxime Ripard
Hi,
Quoted 38 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +5
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEADarch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 10 lines
arch/riscv/Kconfig.socs +10
-0+ select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DW + select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
Quoted 7 lines
Quoted 5 lines
We just want people could bring D1 up easier, 8250 is the basic component.
Quoted 2 lines
These options should be in the defconfig.
Agreed, using a defconfig is the right way to do this.
Put 8250 related configs into arch/riscv/configs/defconfig?
@Palmer Dabbelt @Arnd Bergmann, How do you think about that?
(defconfig or Kconfig.soc)
My purpose is when people make the Image from riscv/defconfig, then the Image could run on all platforms include D1.
Quoted 4 lines
--
~Randy
Signature · 4 lines
Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 65 lines · Guo Ren
Quoted 64 lines · Randy Dunlap
Quoted 61 lines · Guo Ren
Quoted 47 lines · Maxime Ripard
Hi,
Quoted 43 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +10
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DWQuoted 8 lines
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 5 lines
arch/riscv/Kconfig.socs +5
-0+ select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
We just want people could bring D1 up easier, 8250 is the basic component.
Quoted 2 lines
These options should be in the defconfig.
Quoted 7 lines
Quoted 1 line
Agreed, using a defconfig is the right way to do this.
Put 8250 related configs into
arch/riscv/configs/defconfig?@Palmer Dabbelt @Arnd Bergmann, How do you think about that?
(defconfig orKconfig.soc)
My purpose is when people make the Image from riscv/defconfig, then the Image could run on all platforms include D1.
Hi,
I certainly did not understand your purpose with the patch being able to build a kernel that would run on multiple platforms. Still, I would not expect to see one platform cause unnecessary drivers to be built for platforms that don't need them.
Kconfig.socs in arch/riscv/ is a bit of an unusual Kconfig file IMO -- I suppose what you want to do fits into its style.
AFAIK the suggestion to use a defconfig (at least my suggestion) was expecting to have a defconfig for each platform, but that would not give you a boot image that could run on all platforms.
Anyway, it's Palmer's choice.
thanks.
Signature · 1 line
~Randy
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 82 lines · Randy Dunlap
Quoted 65 lines · Guo Ren
Quoted 64 lines · Randy Dunlap
Quoted 61 lines · Guo Ren
Quoted 47 lines · Maxime Ripard
Hi,
Quoted 43 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +10
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DWQuoted 8 lines
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 5 lines
arch/riscv/Kconfig.socs +5
-0+ select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
We just want people could bring D1 up easier, 8250 is the basic component.
Quoted 2 lines
These options should be in the defconfig.
Quoted 7 lines
Quoted 1 line
Agreed, using a defconfig is the right way to do this.
Put 8250 related configs into
arch/riscv/configs/defconfig?@Palmer Dabbelt @Arnd Bergmann, How do you think about that?
(defconfig orKconfig.soc)
My purpose is when people make the Image from riscv/defconfig, then the Image could run on all platforms include D1.Hi,
I certainly did not understand your purpose with the patch being able to build a kernel that would run on multiple platforms. Still, I would not expect to see one platform cause unnecessary drivers to be built for platforms that don't need them.
Quoted 6 lines
Kconfig.socsinarch/riscv/is a bit of an unusualKconfigfile IMO -- I suppose what you want to do fits into its style.AFAIK the suggestion to use a defconfig (at least my suggestion) was expecting to have a defconfig for each platform, but that would not give you a boot image that could run on all platforms.
AFAIK, having a separate defconfig for each platform is not going to fly with distros (AFAIK). We can't expect dirstros to release separate RISC-V kernel image for each platform. In fact, ARM64 kernel has just one defconfig whereas ARM32 kernel has consolidated and minimized number of defconfigs.
The long term goal for Linux RISC-V is to support single kernel image booting on multiple-platforms. Of course, users can always strip down the kernel using their custom defconfigs.
Regards,
Anup
Quoted 7 lines
Anyway, it's Palmer's choice.
thanks.
--
~Randy
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 96 lines · Anup Patel
Quoted 82 lines · Randy Dunlap
Quoted 65 lines · Guo Ren
Quoted 64 lines · Randy Dunlap
Quoted 61 lines · Guo Ren
Quoted 47 lines · Maxime Ripard
Hi,
Quoted 43 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +10
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DWQuoted 8 lines
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 5 lines
arch/riscv/Kconfig.socs +5
-0+ select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
We just want people could bring D1 up easier, 8250 is the basic component.
Quoted 2 lines
These options should be in the defconfig.
Quoted 7 lines
Quoted 1 line
Agreed, using a defconfig is the right way to do this.
Put 8250 related configs into
arch/riscv/configs/defconfig?@Palmer Dabbelt @Arnd Bergmann, How do you think about that?
(defconfig orKconfig.soc)
My purpose is when people make the Image from riscv/defconfig, then the Image could run on all platforms include D1.Hi,
I certainly did not understand your purpose with the patch being able to build a kernel that would run on multiple platforms. Still, I would not expect to see one platform cause unnecessary drivers to be built for platforms that don't need them.
Quoted 6 lines
Kconfig.socsinarch/riscv/is a bit of an unusualKconfigfile IMO -- I suppose what you want to do fits into its style.AFAIK the suggestion to use a defconfig (at least my suggestion) was expecting to have a defconfig for each platform, but that would not give you a boot image that could run on all platforms.
AFAIK, having a separate defconfig for each platform is not going to fly with distros (AFAIK). We can't expect dirstros to release separate RISC-V kernel image for each platform. In fact, ARM64 kernel has just one defconfig whereas ARM32 kernel has consolidated and minimized number of defconfigs.
Quoted 3 lines
The long term goal for Linux RISC-V is to support single kernel image booting on multiple-platforms. Of course, users can always strip down the kernel using their custom defconfigs.
OK, thanks for the info.
Signature · 1 line
~Randy
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
In reply to Guo RenQuoted 32 lines · Guo Ren
Quoted 31 lines · Randy Dunlap
Quoted 30 lines · Guo Ren
Quoted 29 lines · Maxime Ripard
Quoted 15 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.arch/riscv/Kconfig.socs +5
-0+config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEADarch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 10 lines
arch/riscv/Kconfig.socs +10
-0+ select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DW + select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
We just want people could bring D1 up easier, 8250 is the basic component.
Quoted 2 lines
These options should be in the defconfig.
Agreed, using a defconfig is the right way to do this.
Put 8250 related configs into
arch/riscv/configs/defconfig?
I think that would be best, as well as the STMMAC_ETH and DWMAC_GENERIC options.
If all RISC-V chips are required to have a 8250 compatible uart, selecting it from CONFIG_RISCV would work as well, but for consistency I'd give users the option to leave it out, just like any other driver that is not required to have a useful system.
Quoted 4 lines
@Palmer Dabbelt @Arnd Bergmann, How do you think about that?
(defconfig orKconfig.soc)
My purpose is when people make the Image from riscv/defconfig, then the Image could run on all platforms include D1.
I would try to keep the Kconfig.soc as short as possible. As a general rule, only use 'select' to enable symbols that are otherwise not user visible, such as the specific errata if you want to hide them. For individual SoCs, I prefer not having separate Kconfig options, but instead have those per driver. We have some SoC families that have part specific options elsewhere, e.g. drivers/soc/renesas/Kconfig, but I'd only add those if you can't avoid it. Having it in drivers/soc/ may be better for sunxi than spreading them over arch/{arm,arm64,riscv}.
Some subsystem maintainers want drivers to be selected by the SoC option, this is why you need the 'select SIFIVE_PLIC', but usually the drivers are selectable with a 'depends on ARCH_SUNXI || COMPILE_TEST' and enabled in the defconfig.
If you want to get fancy, you can use something like:
config RESET_SUNXI
bool "Allwinner SoCs Reset Driver" if COMPILE_TEST && !ARCH_SUNXI
default ARCH_SUNXIThis will make an option that
- always enabled when the platform is built-in
- user selectable when compile-testing for any other platform
- always disabled otherwise
Arnd
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 4 lines · Arnd Bergmann
Some subsystem maintainers want drivers to be selected by the SoC option, this is why you need the 'select
SIFIVE_PLIC', but usually the drivers are selectable with a 'depends onARCH_SUNXI||COMPILE_TEST' and enabled in the defconfig.
I would say selecting drivers is even more useful for distros and other downstream users. Especially in the ARM world where we have so many different SoCs - how could a distro person know which driver is necessary, important or useful? Having all main SoC drivers enabled when ARCH_SUNXI=y, helps distro a lot.
Quoted 10 lines
If you want to get fancy, you can use something like:
config
RESET_SUNXIbool "Allwinner SoCs Reset Driver" if COMPILE_TEST && !ARCH_SUNXI default ARCH_SUNXIThis will make an option that
- always enabled when the platform is built-in
- user selectable when compile-testing for any other platform
- always disabled otherwise
+1 for this pattern.
Best regards,
Krzysztof
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 11 lines · Krzysztof Kozlowski
Quoted 4 lines · Arnd Bergmann
Some subsystem maintainers want drivers to be selected by the SoC option, this is why you need the 'select
SIFIVE_PLIC', but usually the drivers are selectable with a 'depends onARCH_SUNXI||COMPILE_TEST' and enabled in the defconfig.I would say selecting drivers is even more useful for distros and other downstream users. Especially in the ARM world where we have so many different SoCs - how could a distro person know which driver is necessary, important or useful? Having all main SoC drivers enabled when ARCH_SUNXI=y, helps distro a lot.
Imply, maybe, but select is far too painful for everyone else.
Quoted 6 lines
Quoted 6 lines
If you want to get fancy, you can use something like:
config
RESET_SUNXIbool "Allwinner SoCs Reset Driver" if COMPILE_TEST && !ARCH_SUNXI default ARCH_SUNXI
Quoted 6 lines
Quoted 4 lines
This will make an option that
- always enabled when the platform is built-in
- user selectable when compile-testing for any other platform
- always disabled otherwise+1 for this pattern.
Yeah, or a default
Maxime
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 7 lines · Maxime Ripard
Quoted 6 lines · Krzysztof Kozlowski
Quoted 4 lines · Arnd Bergmann
Some subsystem maintainers want drivers to be selected by the SoC option, this is why you need the 'select
SIFIVE_PLIC', but usually the drivers are selectable with a 'depends onARCH_SUNXI||COMPILE_TEST' and enabled in the defconfig.
Quoted 7 lines
Quoted 5 lines
I would say selecting drivers is even more useful for distros and other downstream users. Especially in the ARM world where we have so many different SoCs - how could a distro person know which driver is necessary, important or useful? Having all main SoC drivers enabled when ARCH_SUNXI=y, helps distro a lot.
Imply, maybe, but select is far too painful for everyone else.
If we talk about UART driver, then sure - imply makes sense. But if we talk about core SoC components necessary for boot (e.g. timers, clocks, pinctrl), then select is appropriate. There is no point to enable ARCH_XXX without these core components.
Best regards,
Krzysztof
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 15 lines · Krzysztof Kozlowski
Quoted 13 lines · Maxime Ripard
Quoted 11 lines · Krzysztof Kozlowski
Quoted 4 lines · Arnd Bergmann
Some subsystem maintainers want drivers to be selected by the SoC option, this is why you need the 'select
SIFIVE_PLIC', but usually the drivers are selectable with a 'depends onARCH_SUNXI||COMPILE_TEST' and enabled in the defconfig.I would say selecting drivers is even more useful for distros and other downstream users. Especially in the ARM world where we have so many different SoCs - how could a distro person know which driver is necessary, important or useful? Having all main SoC drivers enabled when ARCH_SUNXI=y, helps distro a lot.
Quoted 6 lines
Quoted 1 line
Imply, maybe, but select is far too painful for everyone else.
If we talk about UART driver, then sure - imply makes sense. But if we talk about core SoC components necessary for boot (e.g. timers, clocks, pinctrl), then select is appropriate. There is no point to enable
ARCH_XXXwithout these core components.
Please never use 'imply', this is functionally the same as 'default', just the wrong way around, like the infamous 'comefrom' instruction in programming languages ;-)
I still prefer using defaults and defconfig files over 'select', but I can see the use of select in some cases, as long as the symbol you are selecting is not already user visible.
Arnd
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
In reply to Arnd BergmannQuoted 38 lines · Arnd Bergmann
Quoted 36 lines · Guo Ren
Quoted 35 lines · Randy Dunlap
Quoted 34 lines · Guo Ren
Quoted 21 lines · Maxime Ripard
Quoted 20 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.arch/riscv/Kconfig.socs +10
-0+config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DWQuoted 8 lines
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 5 lines
arch/riscv/Kconfig.socs +5
-0+ select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
We just want people could bring D1 up easier, 8250 is the basic component.
Quoted 1 line
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
These options should be in the defconfig.
Agreed, using a defconfig is the right way to do this.
Put 8250 related configs into
arch/riscv/configs/defconfig?I think that would be best, as well as the
STMMAC_ETHandDWMAC_GENERICoptions.
Okay, I would move STMMAC_ETH SERIAL_8250_DW SERIAL_8250_CONSOLE SERIAL_8250 & SIFIVE_PLIC into defconfig in the next version of the patch.
Quoted 37 lines
If all RISC-V chips are required to have a 8250 compatible uart, selecting it from
CONFIG_RISCVwould work as well, but for consistency I'd give users the option to leave it out, just like any other driver that is not required to have a useful system.Quoted 4 lines
@Palmer Dabbelt @Arnd Bergmann, How do you think about that?
(defconfig orKconfig.soc)
My purpose is when people make the Image from riscv/defconfig, then the Image could run on all platforms include D1.I would try to keep the
Kconfig.socas short as possible. As a general rule, only use 'select' to enable symbols that are otherwise not user visible, such as the specific errata if you want to hide them. For individual SoCs, I prefer not having separateKconfigoptions, but instead have those per driver. We have some SoC families that have part specific options elsewhere, e.g.drivers/soc/renesas/Kconfig, but I'd only add those if you can't avoid it. Having it indrivers/soc/may be better for sunxi than spreading them overarch/{arm,arm64,riscv}.Some subsystem maintainers want drivers to be selected by the SoC option, this is why you need the 'select
SIFIVE_PLIC', but usually the drivers are selectable with a 'depends onARCH_SUNXI||COMPILE_TEST' and enabled in the defconfig.If you want to get fancy, you can use something like:
config
RESET_SUNXIbool "Allwinner SoCs Reset Driver" if COMPILE_TEST && !ARCH_SUNXI default ARCH_SUNXIThis will make an option that
- always enabled when the platform is built-in
- user selectable when compile-testing for any other platform
- always disabled otherwiseArnd
Signature · 4 lines
Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
In reply to Maxime RipardQuoted 46 lines · Maxime Ripard
Hi,
Quoted 43 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +10
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DW
Quoted 8 lines
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 5 lines
arch/riscv/Kconfig.socs +5
-0+ select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
The draft of the RISC-V platform specification is available here:
https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#uartserial-console
The specification requires in section "2.1.5.1. UART/Serial Console" that on platforms with a rich operating system (e.g. Linux) you have a serial console. Hence requiring 8250 support for the D1 CPU is justified.
In the riscv defconfig as of v5.14 we have:
CONFIG_SERIAL_8250=yCONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_DW is not set
(Support for Synopsys DesignWare 8250 quirks)
CONFIG_SERIAL_8250_DW should be enabled (=y) in the defconfig.
As the specification requires a 16550 UART and marks 8250 as deprecated I expect that future Allwinner SoCs will move to 16550. Calling a Kconfig menu item "Allwinner SoCs" which includes all future Allwinner SoCs irritates me. How about CONFIG_SOC_SUNXI_D1 instead?
Why does the patch use 'depends on MMU' and does not 'select MMU'?
Best regards
Heinrich
Quoted 5 lines
These options should be in the defconfig.
Maxime
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 3 lines · Heinrich Schuchardt
Calling a
Kconfigmenu item "Allwinner SoCs" which includes all future Allwinner SoCs irritates me. How aboutCONFIG_SOC_SUNXI_D1instead?
Would you want to have a separate option for each new SoC? That seems like the only way to split things up, if you want to be more specific than than "sunxi" (or equivalently "sun20i", which is the codename for the RISC-V series).
Except at the very beginning (sun4i-sun7i), there have not been clear generational boundaries between the various sunxi SoCs, so most of the 32-bit ones already get lumped into a single symbol (MACH_SUN8I). And there is a single Kconfig symbol, ARCH_SUNXI, for all 64-bit Allwinner SoCs.
There is enough overlap in peripherals that you need a common symbol for the peripheral drivers anyway. How about... ARCH_SUNXI? There are 90+ uses of this symbol throughout drivers/ and sound/, and I have found that more than half of them apply to the D1 (see e.g. this commit[1] and some of its ancestors).
RISC-V has so far adopted a CONFIG_SOC_xxx naming scheme, which is different from arm/arm64's CONFIG_ARCH_xxx pattern. But now we have a case where a SoC family is split between the two architectures. I'm all for consistency with the names of other RISC-V platform symbols, but it seems that reusing the existing ARCH_SUNXI symbol would be better than cluttering up the driver Kconfig files with a duplicate.
Regards,
Samuel
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
Quoted 10 lines · Samuel Holland
Quoted 3 lines · Heinrich Schuchardt
Calling a
Kconfigmenu item "Allwinner SoCs" which includes all future Allwinner SoCs irritates me. How aboutCONFIG_SOC_SUNXI_D1instead?Would you want to have a separate option for each new SoC? That seems like the only way to split things up, if you want to be more specific than than "sunxi" (or equivalently "sun20i", which is the codename for the RISC-V series).
Quoted 4 lines
Except at the very beginning (sun4i-sun7i), there have not been clear generational boundaries between the various sunxi SoCs, so most of the 32-bit ones already get lumped into a single symbol (
MACH_SUN8I). And there is a singleKconfigsymbol,ARCH_SUNXI, for all 64-bit Allwinner SoCs.
On arm64 we have avoided SoC specific Kconfig symbols and left it to the defconfig to select all SoC specific drivers. Generally the tendency of the defconfigs is to provide a multiarch kernel. So this should be ok on RISC-V too.
I was just concerned about the 8250 driver assigned to something called "Allwinner SoCs" which didn't seem future proof.
Quoted 6 lines
There is enough overlap in peripherals that you need a common symbol for the peripheral drivers anyway. How about...
ARCH_SUNXI? There are 90+ uses of this symbol throughoutdrivers/andsound/, and I have found that more than half of them apply to the D1 (see e.g. this commit[1] and some of its ancestors).
Looking at the current use of ARCH_SUNXI in drivers reusing the same name on RISC-V makes sense.
Best regards
Heinrich
Quoted 13 lines
RISC-V has so far adopted a
CONFIG_SOC_xxxnaming scheme, which is different from arm/arm64'sCONFIG_ARCH_xxxpattern. But now we have a case where a SoC family is split between the two architectures. I'm all for consistency with the names of other RISC-V platform symbols, but it seems that reusing the existingARCH_SUNXIsymbol would be better than cluttering up the driverKconfigfiles with a duplicate.Regards,
Samuel
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
In reply to Heinrich SchuchardtHi,
Quoted 53 lines · Heinrich Schuchardt
Quoted 44 lines
Hi,
Quoted 41 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +10
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DWQuoted 8 lines
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 5 lines
arch/riscv/Kconfig.socs +5
-0+ select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
Quoted 6 lines
The draft of the RISC-V platform specification is available here:
https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#uartserial-consoleThe specification requires in section "2.1.5.1. UART/Serial Console" that on platforms with a rich operating system (e.g. Linux) you have a serial console. Hence requiring 8250 support for the D1 CPU is justified.
I mean, not really? The platform is required to have a UART, but nothing requires the kernel to have a driver for it as far as I'm aware.
Maxime
Re: [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option
In reply to Maxime RipardQuoted 46 lines · Maxime Ripard
Hi,
Quoted 43 lines · On Sat, Sep 11, 2021 at 05:21:39PM +0800, [email protected] wrote:
From: Liu Shaohua <[email protected]>
Add Allwinner kconfig option which selects SoC specific and common drivers that is required for this SoC.
Allwinner D1 uses custom PTE attributes to solve non-coherency SOC interconnect issues for dma synchronization, so we set the default value when
SOC_SUNXIselected.Signed-off-by Liu Shaohua <[email protected]>Signed-off-by Guo Ren <[email protected]>Signed-off-by Wei Fu <[email protected]>Cc Anup Patel <[email protected]>Cc Atish Patra <[email protected]>Cc Christoph Hellwig <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Drew Fustini <[email protected]>Cc Maxime Ripard <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Wei Wu <[email protected]>--- arch/riscv/Kconfig.socs | 15 +++++++++++++++ arch/riscv/configs/defconfig | 1 + 2 files changed, 16 insertions(+)arch/riscv/Kconfig.socs +10
-0@@ -70,4 +70,19 @@ config SOC_CANAAN_K210_DTB_SOURCE endif +config SOC_SUNXI + bool "Allwinner SoCs" + depends on MMU + select DWMAC_GENERIC + select ERRATA_THEAD + select RISCV_DMA_NONCOHERENT + select RISCV_ERRATA_ALTERNATIVE + select SERIAL_8250 + select SERIAL_8250_CONSOLE + select SERIAL_8250_DW
Quoted 8 lines
arch/riscv/Kconfig.socs config SOC_CANAAN_K210_DTB_SOURCE · line 87
Quoted 5 lines
arch/riscv/Kconfig.socs +5
-0+ select SIFIVE_PLIC + select STMMAC_ETH + help + This enables support for Allwinner SoC platforms like the D1. +I'm not sure we should select the drivers there. We could very well imagine a board without UART, or even more so without ethernet.
I could make a case for selecting the serial as it is probably the console, however the ethernet is not necessary for operation and I would prefer to see this removed.
I wonder if we should have a new Kconfig keyword of suggest which marks drivers as suggested for a given SoC/board/platform.
Signature · 9 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv