From: Guo Ren <guoren@kernel.org> To: Arnd Bergmann <arnd@arndb.de> Cc: "Palmer Dabbelt" <palmer@dabbelt.com>, "Anup Patel" <Anup.Patel@wdc.com>, "Anup Patel" <anup@brainfault.org>, "Drew Fustini" <drew@beagleboard.org>, "Christoph Hellwig" <hch@lst.de>, wefu@redhat.com, "Wei Wu (吴伟)" <lazyparser@gmail.com>, linux-riscv <linux-riscv@lists.infradead.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-arch <linux-arch@vger.kernel.org>, linux-sunxi@lists.linux.dev, "Guo Ren" <guoren@linux.alibaba.com>, "Paul Walmsley" <paul.walmsley@sifive.com> Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support Date: Fri, 4 Jun 2021 22:47:22 +0800 [thread overview] Message-ID: <CAJF2gTTpurWpPUcA2JkF0rOFztKQgFBhOF9zQyuyi_-sxszhRQ@mail.gmail.com> (raw) In-Reply-To: <CAK8P3a03sxxnzpZPxNnXLtCFOFBZ6espEj4V5y=K+59dOLJc6A@mail.gmail.com> Hi Arnd & Palmer, Sorry for the delayed reply, I'm working on the next version of the patch. On Fri, Jun 4, 2021 at 5:56 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Jun 3, 2021 at 5:39 PM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Wed, 02 Jun 2021 23:00:29 PDT (-0700), Anup Patel wrote: > > >> This implementation, which adds some Kconfig entries that control page table > > >> bits, definately isn't suitable for upstream. Allowing users to set arbitrary > > >> page table bits will eventually conflict with the standard, and is just going to > > >> be a mess. It'll also lead to kernels that are only compatible with specific > > >> designs, which we're trying very hard to avoid. At a bare minimum we'll need > > >> some way to detect systems with these page table bits before setting them, > > >> and some description of what the bits actually do so we can reason about > > >> them. > > > > > > Yes, vendor specific Kconfig options are strict NO NO. We can't give-up the > > > goal of unified kernel image for all platforms. Okay, Agree. Please help review the next version of the patch. > > > > I think this is just a phrasing issue, but just to be sure: > > > > IMO it's not that they're vendor-specific Kconfig options, it's that > > turning them on will conflict with standard systems (and other vendors). > > We've already got the ability to select sets of Kconfig settings that > > will only boot on one vendor's system, which is fine, as long as there > > remains a set of Kconfig settings that will boot on all systems. > > > > An example here would be the errata: every system has errata of some > > sort, so if we start flipping off various vendor's errata Kconfigs > > you'll end up with kernels that only function properly on some systems. > > That's fine with me, as long as it's possible to turn on all vendor's > > errata Kconfigs at the same time and the resulting kernel functions > > correctly on all systems. > > Yes, this is generally the goal, and it would be great to have that > working in a way where a 'defconfig' build just turns on all the options > that are needed to use any SoC specific features and drivers while > still working on all hardware. There are however limits you may run > into at some point, and other architectures usually only manage to span > some 10 to 15 years of hardware implementations with a single > kernel before it get really hard. I could follow the goal in the next version of the patchset. Please help review, thx. > > To give some common examples that make it break down: > > - 32-bit vs 64-bit already violates that rule on risc-v (as it does on > most other architectures) > > - architectures that support both big-endian and little-endian kernels > tend to have platforms that require one or the other (e.g. mips, > though not arm). Not an issue for you. > > - page table formats are the main cause of incompatibility: arm32 > and x86-32 require three-level tables for certain features, but those > are incompatible with older cores, arm64 supports three different > page sizes, but none of them works on all cores (4KB almost works > everywhere). > > - SMP-enabled ARMv7 kernels can be configured to run on either > ARMv6 or ARMv8, but not both, in this case because of incompatible > barrier instructions. > > - 32-bit Arm has a couple more remaining features that require building > a machine specific kernel if enabled because they hardcode physical > addresses: early printk (debug_ll, not the normal earlycon), NOMMU, > and XIP. > > Arnd -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
WARNING: multiple messages have this Message-ID (diff)
From: Guo Ren <guoren@kernel.org> To: Arnd Bergmann <arnd@arndb.de> Cc: "Palmer Dabbelt" <palmer@dabbelt.com>, "Anup Patel" <Anup.Patel@wdc.com>, "Anup Patel" <anup@brainfault.org>, "Drew Fustini" <drew@beagleboard.org>, "Christoph Hellwig" <hch@lst.de>, wefu@redhat.com, "Wei Wu (吴伟)" <lazyparser@gmail.com>, linux-riscv <linux-riscv@lists.infradead.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-arch <linux-arch@vger.kernel.org>, linux-sunxi@lists.linux.dev, "Guo Ren" <guoren@linux.alibaba.com>, "Paul Walmsley" <paul.walmsley@sifive.com> Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support Date: Fri, 4 Jun 2021 22:47:22 +0800 [thread overview] Message-ID: <CAJF2gTTpurWpPUcA2JkF0rOFztKQgFBhOF9zQyuyi_-sxszhRQ@mail.gmail.com> (raw) In-Reply-To: <CAK8P3a03sxxnzpZPxNnXLtCFOFBZ6espEj4V5y=K+59dOLJc6A@mail.gmail.com> Hi Arnd & Palmer, Sorry for the delayed reply, I'm working on the next version of the patch. On Fri, Jun 4, 2021 at 5:56 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Jun 3, 2021 at 5:39 PM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Wed, 02 Jun 2021 23:00:29 PDT (-0700), Anup Patel wrote: > > >> This implementation, which adds some Kconfig entries that control page table > > >> bits, definately isn't suitable for upstream. Allowing users to set arbitrary > > >> page table bits will eventually conflict with the standard, and is just going to > > >> be a mess. It'll also lead to kernels that are only compatible with specific > > >> designs, which we're trying very hard to avoid. At a bare minimum we'll need > > >> some way to detect systems with these page table bits before setting them, > > >> and some description of what the bits actually do so we can reason about > > >> them. > > > > > > Yes, vendor specific Kconfig options are strict NO NO. We can't give-up the > > > goal of unified kernel image for all platforms. Okay, Agree. Please help review the next version of the patch. > > > > I think this is just a phrasing issue, but just to be sure: > > > > IMO it's not that they're vendor-specific Kconfig options, it's that > > turning them on will conflict with standard systems (and other vendors). > > We've already got the ability to select sets of Kconfig settings that > > will only boot on one vendor's system, which is fine, as long as there > > remains a set of Kconfig settings that will boot on all systems. > > > > An example here would be the errata: every system has errata of some > > sort, so if we start flipping off various vendor's errata Kconfigs > > you'll end up with kernels that only function properly on some systems. > > That's fine with me, as long as it's possible to turn on all vendor's > > errata Kconfigs at the same time and the resulting kernel functions > > correctly on all systems. > > Yes, this is generally the goal, and it would be great to have that > working in a way where a 'defconfig' build just turns on all the options > that are needed to use any SoC specific features and drivers while > still working on all hardware. There are however limits you may run > into at some point, and other architectures usually only manage to span > some 10 to 15 years of hardware implementations with a single > kernel before it get really hard. I could follow the goal in the next version of the patchset. Please help review, thx. > > To give some common examples that make it break down: > > - 32-bit vs 64-bit already violates that rule on risc-v (as it does on > most other architectures) > > - architectures that support both big-endian and little-endian kernels > tend to have platforms that require one or the other (e.g. mips, > though not arm). Not an issue for you. > > - page table formats are the main cause of incompatibility: arm32 > and x86-32 require three-level tables for certain features, but those > are incompatible with older cores, arm64 supports three different > page sizes, but none of them works on all cores (4KB almost works > everywhere). > > - SMP-enabled ARMv7 kernels can be configured to run on either > ARMv6 or ARMv8, but not both, in this case because of incompatible > barrier instructions. > > - 32-bit Arm has a couple more remaining features that require building > a machine specific kernel if enabled because they hardcode physical > addresses: early printk (debug_ll, not the normal earlycon), NOMMU, > and XIP. > > Arnd -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-06-04 14:47 UTC|newest] Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-19 5:04 [PATCH RFC 0/3] riscv: Add DMA_COHERENT support guoren 2021-05-19 5:04 ` guoren 2021-05-19 5:04 ` [PATCH RFC 1/3] riscv: pgtable.h: Fixup _PAGE_CHG_MASK usage guoren 2021-05-19 5:04 ` guoren 2021-05-19 5:04 ` [PATCH RFC 2/3] riscv: Add DMA_COHERENT for custom PTE attributes guoren 2021-05-19 5:04 ` guoren 2021-05-19 5:04 ` [PATCH RFC 3/3] riscv: Add SYNC_DMA_FOR_CPU/DEVICE for DMA_COHERENT guoren 2021-05-19 5:04 ` guoren 2021-05-19 6:32 ` Guo Ren 2021-05-19 6:32 ` Guo Ren 2021-05-19 5:20 ` [PATCH RFC 0/3] riscv: Add DMA_COHERENT support Christoph Hellwig 2021-05-19 5:20 ` Christoph Hellwig 2021-05-19 5:48 ` Guo Ren 2021-05-19 5:48 ` Guo Ren 2021-05-19 5:55 ` Christoph Hellwig 2021-05-19 5:55 ` Christoph Hellwig 2021-05-19 6:09 ` Guo Ren 2021-05-19 6:09 ` Guo Ren 2021-05-19 6:44 ` Drew Fustini 2021-05-19 6:44 ` Drew Fustini 2021-05-19 6:53 ` Christoph Hellwig 2021-05-19 6:53 ` Christoph Hellwig 2021-05-20 1:45 ` Guo Ren 2021-05-20 1:45 ` Guo Ren 2021-05-20 5:48 ` Christoph Hellwig 2021-05-20 5:48 ` Christoph Hellwig 2021-06-06 18:14 ` Nick Kossifidis 2021-06-06 18:14 ` Nick Kossifidis 2021-06-07 0:04 ` Guo Ren 2021-06-07 0:04 ` Guo Ren 2021-06-07 2:16 ` Nick Kossifidis 2021-06-07 2:16 ` Nick Kossifidis 2021-06-07 3:19 ` Guo Ren 2021-06-07 3:19 ` Guo Ren 2021-06-07 6:27 ` Christoph Hellwig 2021-06-07 6:27 ` Christoph Hellwig 2021-06-07 6:41 ` Guo Ren 2021-06-07 6:41 ` Guo Ren 2021-06-07 6:51 ` Christoph Hellwig 2021-06-07 6:51 ` Christoph Hellwig 2021-06-07 7:46 ` Guo Ren 2021-06-07 7:46 ` Guo Ren 2021-06-08 15:00 ` David Laight 2021-06-08 15:00 ` David Laight 2021-06-08 15:32 ` 'Christoph Hellwig' 2021-06-08 15:32 ` 'Christoph Hellwig' 2021-06-08 16:11 ` David Laight 2021-06-08 16:11 ` David Laight 2021-06-07 8:35 ` Nick Kossifidis 2021-06-07 8:35 ` Nick Kossifidis 2021-06-09 3:28 ` Guo Ren 2021-06-09 3:28 ` Guo Ren 2021-06-09 6:05 ` Jisheng Zhang 2021-06-09 6:05 ` Jisheng Zhang 2021-06-09 9:45 ` Nick Kossifidis 2021-06-09 9:45 ` Nick Kossifidis 2021-06-09 12:43 ` Guo Ren 2021-06-09 12:43 ` Guo Ren 2021-05-19 6:05 ` Guo Ren 2021-05-19 6:05 ` Guo Ren 2021-05-19 6:06 ` Christoph Hellwig 2021-05-19 6:06 ` Christoph Hellwig 2021-05-19 6:11 ` Guo Ren 2021-05-19 6:11 ` Guo Ren 2021-05-19 6:54 ` Drew Fustini 2021-05-19 6:54 ` Drew Fustini 2021-05-19 6:56 ` Christoph Hellwig 2021-05-19 6:56 ` Christoph Hellwig 2021-05-19 7:14 ` Anup Patel 2021-05-19 7:14 ` Anup Patel 2021-05-19 8:25 ` Damien Le Moal 2021-05-19 8:25 ` Damien Le Moal 2021-05-20 1:47 ` Guo Ren 2021-05-20 1:47 ` Guo Ren 2021-05-20 1:59 ` Guo Ren 2021-05-20 1:59 ` Guo Ren 2021-05-22 0:36 ` Guo Ren 2021-05-22 0:36 ` Guo Ren 2021-05-30 0:30 ` Palmer Dabbelt 2021-05-30 0:30 ` Palmer Dabbelt 2021-06-03 4:13 ` Palmer Dabbelt 2021-06-03 4:13 ` Palmer Dabbelt 2021-06-03 6:00 ` Anup Patel 2021-06-03 6:00 ` Anup Patel 2021-06-03 15:39 ` Palmer Dabbelt 2021-06-03 15:39 ` Palmer Dabbelt 2021-06-04 9:02 ` David Laight 2021-06-04 9:02 ` David Laight 2021-06-04 9:53 ` Arnd Bergmann 2021-06-04 9:53 ` Arnd Bergmann 2021-06-04 14:47 ` Guo Ren [this message] 2021-06-04 14:47 ` Guo Ren 2021-06-04 16:12 ` Palmer Dabbelt 2021-06-04 16:12 ` Palmer Dabbelt 2021-06-04 21:26 ` Arnd Bergmann 2021-06-04 21:26 ` Arnd Bergmann 2021-06-04 22:10 ` Palmer Dabbelt 2021-06-04 22:10 ` Palmer Dabbelt 2021-06-08 12:26 ` Guo Ren 2021-06-08 12:26 ` Guo Ren 2021-06-06 17:11 ` Guo Ren 2021-06-06 17:11 ` Guo Ren 2021-06-07 3:38 ` Anup Patel 2021-06-07 3:38 ` Anup Patel 2021-06-07 4:22 ` Guo Ren 2021-06-07 4:22 ` Guo Ren 2021-06-07 4:47 ` Anup Patel 2021-06-07 4:47 ` Anup Patel 2021-06-07 5:08 ` Guo Ren 2021-06-07 5:08 ` Guo Ren 2021-06-07 5:13 ` Guo Ren 2021-06-07 5:13 ` Guo Ren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAJF2gTTpurWpPUcA2JkF0rOFztKQgFBhOF9zQyuyi_-sxszhRQ@mail.gmail.com \ --to=guoren@kernel.org \ --cc=Anup.Patel@wdc.com \ --cc=anup@brainfault.org \ --cc=arnd@arndb.de \ --cc=drew@beagleboard.org \ --cc=guoren@linux.alibaba.com \ --cc=hch@lst.de \ --cc=lazyparser@gmail.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=linux-sunxi@lists.linux.dev \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=wefu@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.