| Message ID | 20210116032740.873-1-thunder.leizhen@huawei.com |
|---|---|
| Headers | show |
| Series | ARM: Add support for Hisilicon Kunpeng L3 cache controller | expand |
Hi Russell and Arnd: Do you have time to review it? On 2021/1/16 11:27, Zhen Lei wrote: > v4 --> v5: > 1. Add SoC macro ARCH_KUNPENG50X, and the Kunpeng L3 cache controller only enabled > on that platform. > 2. Require the compatible string of the Kunpeng L3 cache controller must have a > relevant name on a specific SoC. For example: > compatible = "hisilicon,kunpeng509-l3cache", "hisilicon,kunpeng-l3cache"; > > v3 --> v4: > Rename the compatible string from "hisilicon,l3cache" to "hisilicon,kunpeng-l3cache". > Then adjust the file name, configuration option name, and description accordingly. > > v2 --> v3: > Add Hisilicon L3 cache controller driver and its document. That's: patch 2-3. > > v1 --> v2: > Discard the middle-tier functions and do silent narrowing cast in the outcache > hook functions. For example: > -static void l2c220_inv_range(unsigned long start, unsigned long end) > +static void l2c220_inv_range(phys_addr_t pa_start, phys_addr_t pa_end) > { > + unsigned long start = pa_start; > + unsigned long end = pa_end; > > > v1: > Do cast phys_addr_t to unsigned long by adding a middle-tier function. > For example: > -static void l2c220_inv_range(unsigned long start, unsigned long end) > +static void __l2c220_inv_range(unsigned long start, unsigned long end) > { > ... > } > +static void l2c220_inv_range(phys_addr_t start, phys_addr_t end) > +{ > + __l2c220_inv_range(start, end); > +} > > > Zhen Lei (4): > ARM: LPAE: Use phys_addr_t instead of unsigned long in outercache > hooks > ARM: hisi: add support for Kunpeng50x SoC > dt-bindings: arm: hisilicon: Add binding for Kunpeng L3 cache > controller > ARM: Add support for Hisilicon Kunpeng L3 cache controller > > .../arm/hisilicon/kunpeng-l3cache.yaml | 40 +++++ > arch/arm/include/asm/outercache.h | 6 +- > arch/arm/mach-hisi/Kconfig | 8 + > arch/arm/mm/Kconfig | 10 ++ > arch/arm/mm/Makefile | 1 + > arch/arm/mm/cache-feroceon-l2.c | 15 +- > arch/arm/mm/cache-kunpeng-l3.c | 153 ++++++++++++++++++ > arch/arm/mm/cache-kunpeng-l3.h | 30 ++++ > arch/arm/mm/cache-l2x0.c | 50 ++++-- > arch/arm/mm/cache-tauros2.c | 15 +- > arch/arm/mm/cache-uniphier.c | 6 +- > arch/arm/mm/cache-xsc3l2.c | 12 +- > 12 files changed, 317 insertions(+), 29 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/kunpeng-l3cache.yaml > create mode 100644 arch/arm/mm/cache-kunpeng-l3.c > create mode 100644 arch/arm/mm/cache-kunpeng-l3.h >
On Sat, Jan 16, 2021 at 4:27 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile > + > +static void l3cache_maint_common(u32 range, u32 op_type) > +{ > + u32 reg; > + > + reg = readl(l3_ctrl_base + L3_MAINT_CTRL); > + reg &= ~(L3_MAINT_RANGE_MASK | L3_MAINT_TYPE_MASK); > + reg |= range | op_type; > + reg |= L3_MAINT_STATUS_START; > + writel(reg, l3_ctrl_base + L3_MAINT_CTRL); Are there contents of L3_MAINT_CTRL that need to be preserved across calls and can not be inferred? A 'readl()' is often expensive, so it might be more efficient if you can avoid that. > +static inline void l3cache_flush_all_nolock(void) > +{ > + l3cache_maint_common(L3_MAINT_RANGE_ALL, L3_MAINT_TYPE_FLUSH); > +} > + > +static void l3cache_flush_all(void) > +{ > + unsigned long flags; > + > + spin_lock_irqsave(&l3cache_lock, flags); > + l3cache_flush_all_nolock(); > + spin_unlock_irqrestore(&l3cache_lock, flags); > +} I see that cache-l2x0 uses raw_spin_lock_irqsave() instead of spin_lock_irqsave(), to avoid preemption in the middle of a cache operation. This is probably a good idea here as well. I also see that l2x0 uses readl_relaxed(), to avoid a deadlock in l2x0_cache_sync(). This may also be beneficial for performance reasons, so it might be helpful to compare performance overhead. On the other hand, readl()/writel() are usually the safe choice, as those avoid the need to argue over whether the relaxed versions are safe in all corner cases. > +static int __init l3cache_init(void) > +{ > + u32 reg; > + struct device_node *node; > + > + node = of_find_matching_node(NULL, l3cache_ids); > + if (!node) > + return -ENODEV; I think the initcall should return '0' to indicate success when running a kernel with this driver built-in on a platform that does not have this device. > diff --git a/arch/arm/mm/cache-kunpeng-l3.h b/arch/arm/mm/cache-kunpeng-l3.h > new file mode 100644 > index 000000000000000..9ef6a53e7d4db49 > --- /dev/null > +++ b/arch/arm/mm/cache-kunpeng-l3.h > @@ -0,0 +1,30 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __CACHE_KUNPENG_L3_H > +#define __CACHE_KUNPENG_L3_H > + > +#define L3_CACHE_LINE_SHITF 6 I would suggest moving the contents of the header file into the .c file, since there is only a single user of these macros. Arnd
On Sat, Jan 16, 2021 at 4:32 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > > Enable support for the Hisilicon Kunpeng506 and Kunpeng509 SoC. > > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > --- > arch/arm/mach-hisi/Kconfig | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig > index 2e980f834a6aa1b..c724acc5c642b97 100644 > --- a/arch/arm/mach-hisi/Kconfig > +++ b/arch/arm/mach-hisi/Kconfig > @@ -55,6 +55,14 @@ config ARCH_HIX5HD2 > help > Support for Hisilicon HIX5HD2 SoC family > > +config ARCH_KUNPENG50X > + bool "Hisilicon Kunpeng50x family" > + depends on ARCH_MULTI_V7 > + select ARCH_FLATMEM_ENABLE > + select ARCH_HAS_HOLES_MEMORYMODEL if SPARSEMEM I think the two 'select' statements are both wrong, though for different reasons: - ARCH_FLATMEM_ENABLE is already selected by ARCH_MULTIPLATFORM, and is something that should not be platform specific - ARCH_HAS_HOLES_MEMORYMODEL was removed in v5.11, and should also not be selected by a platform. Otherwise, this seems fine. Arnd
On Sat, Jan 16, 2021 at 4:27 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: > > The outercache of some Hisilicon SOCs support physical addresses wider > than 32-bits. The unsigned long datatype is not sufficient for mapping > physical addresses >= 4GB. The commit ad6b9c9d78b9 ("ARM: 6671/1: LPAE: > use phys_addr_t instead of unsigned long in outercache functions") has > already modified the outercache functions. But the parameters of the > outercache hooks are not changed. This patch use phys_addr_t instead of > unsigned long in outercache hooks: inv_range, clean_range, flush_range. > > To ensure the outercache that does not support LPAE works properly, do > cast phys_addr_t to unsigned long by adding a group of temporary > variables. For example: > -static void l2c220_inv_range(unsigned long start, unsigned long end) > +static void l2c220_inv_range(phys_addr_t pa_start, phys_addr_t pa_end) > { > + unsigned long start = pa_start; > + unsigned long end = pa_end; > > Note that the outercache functions have been doing this cast before this > patch. So now, the cast is just moved into the outercache hook functions. > > No functional change. > > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
On 2021/1/28 22:24, Arnd Bergmann wrote: > On Sat, Jan 16, 2021 at 4:27 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: >> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile >> + >> +static void l3cache_maint_common(u32 range, u32 op_type) >> +{ >> + u32 reg; >> + >> + reg = readl(l3_ctrl_base + L3_MAINT_CTRL); >> + reg &= ~(L3_MAINT_RANGE_MASK | L3_MAINT_TYPE_MASK); >> + reg |= range | op_type; >> + reg |= L3_MAINT_STATUS_START; >> + writel(reg, l3_ctrl_base + L3_MAINT_CTRL); > > Are there contents of L3_MAINT_CTRL that need to be preserved > across calls and can not be inferred? A 'readl()' is often expensive, > so it might be more efficient if you can avoid that. Right, this readl() can be replaced with readl_relaxed(). Thanks. I'll check and correct the readl() and writel() in other places. > >> +static inline void l3cache_flush_all_nolock(void) >> +{ >> + l3cache_maint_common(L3_MAINT_RANGE_ALL, L3_MAINT_TYPE_FLUSH); >> +} >> + >> +static void l3cache_flush_all(void) >> +{ >> + unsigned long flags; >> + >> + spin_lock_irqsave(&l3cache_lock, flags); >> + l3cache_flush_all_nolock(); >> + spin_unlock_irqrestore(&l3cache_lock, flags); >> +} > > I see that cache-l2x0 uses raw_spin_lock_irqsave() instead of > spin_lock_irqsave(), to avoid preemption in the middle of a cache > operation. This is probably a good idea here as well. I don't think there's any essential difference between the two! I don't know if the compiler or tool will do anything extra. I checked the git log of the l2x0 driver and it used raw_spin_lock_irqsave() at the beginning. Maybe there's a description in 2.6. Since you mentioned this potential risk, I'll change it to raw_spin_lock_irqsave. include/linux/spinlock.h： static __always_inline raw_spinlock_t *spinlock_check(spinlock_t *lock) { return &lock->rlock; } #define spin_lock_irqsave(lock, flags) \ do { \ raw_spin_lock_irqsave(spinlock_check(lock), flags); \ } while (0) > > I also see that l2x0 uses readl_relaxed(), to avoid a deadlock > in l2x0_cache_sync(). This may also be beneficial for performance > reasons, so it might be helpful to compare performance > overhead. On the other hand, readl()/writel() are usually the > safe choice, as those avoid the need to argue over whether > the relaxed versions are safe in all corner cases. > >> +static int __init l3cache_init(void) >> +{ >> + u32 reg; >> + struct device_node *node; >> + >> + node = of_find_matching_node(NULL, l3cache_ids); >> + if (!node) >> + return -ENODEV; > > I think the initcall should return '0' to indicate success when running > a kernel with this driver built-in on a platform that does not have > this device. I have added "depends on ARCH_KUNPENG50X" for this driver. But it's OK to return 0. > >> diff --git a/arch/arm/mm/cache-kunpeng-l3.h b/arch/arm/mm/cache-kunpeng-l3.h >> new file mode 100644 >> index 000000000000000..9ef6a53e7d4db49 >> --- /dev/null >> +++ b/arch/arm/mm/cache-kunpeng-l3.h >> @@ -0,0 +1,30 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +#ifndef __CACHE_KUNPENG_L3_H >> +#define __CACHE_KUNPENG_L3_H >> + >> +#define L3_CACHE_LINE_SHITF 6 > > I would suggest moving the contents of the header file into the .c file, > since there is only a single user of these macros. Okay, I'll move it. > > Arnd > > . >
On Fri, Jan 29, 2021 at 11:26:38AM +0100, Arnd Bergmann wrote: > Another clarification, as there are actually two independent > points here: > > * if you can completely remove the readl() above and just write a > hardcoded value into the register, or perhaps read the original > value once at boot time, that is probably a win because it > avoids one of the barriers in the beginning. The datasheet should > tell you if there are any bits in the register that have to be > preserved > > * Regarding the _relaxed() accessors, it's a lot harder to know > whether that is safe, as you first have to show, in particular in case > any of the accesses stop being guarded by the spinlock in that > case, and whether there may be a case where you have to > serialize the memory access against accesses that are still in the > store queue or prefetched. > > Whether this matters at all depends mostly on the type of devices > you are driving on your SoC. If you have any high-speed network > interfaces that are unable to do cache coherent DMA, any extra > instruction here may impact the number of packets you can transfer, > but if all your high-speed devices are connected to a coherent > interconnect, I would just go with the obvious approach and use > the safe MMIO accessors everywhere. For L2 cache code, I would say the opposite, actually, because it is all too easy to get into a deadlock otherwise. If you implement the sync callback, that will be called from every non-relaxed accessor, which means if you need to take some kind of lock in the sync callback and elsewhere in the L2 cache code, you will definitely deadlock. It is safer to put explicit barriers where it is necessary. Also remember that the barrier in readl() etc is _after_ the read, not before, and the barrier in writel() is _before_ the write, not after. The point is to ensure that DMA memory accesses are properly ordered with the IO-accessing instructions. So, using readl_relaxed() with a read-modify-write is entirely sensible provided you do not access DMA memory inbetween.
On 2021/1/29 18:33, Russell King - ARM Linux admin wrote: > On Fri, Jan 29, 2021 at 11:26:38AM +0100, Arnd Bergmann wrote: >> Another clarification, as there are actually two independent >> points here: >> >> * if you can completely remove the readl() above and just write a >> hardcoded value into the register, or perhaps read the original >> value once at boot time, that is probably a win because it >> avoids one of the barriers in the beginning. The datasheet should >> tell you if there are any bits in the register that have to be >> preserved >> >> * Regarding the _relaxed() accessors, it's a lot harder to know >> whether that is safe, as you first have to show, in particular in case >> any of the accesses stop being guarded by the spinlock in that >> case, and whether there may be a case where you have to >> serialize the memory access against accesses that are still in the >> store queue or prefetched. >> >> Whether this matters at all depends mostly on the type of devices >> you are driving on your SoC. If you have any high-speed network >> interfaces that are unable to do cache coherent DMA, any extra >> instruction here may impact the number of packets you can transfer, >> but if all your high-speed devices are connected to a coherent >> interconnect, I would just go with the obvious approach and use >> the safe MMIO accessors everywhere. > > For L2 cache code, I would say the opposite, actually, because it is > all too easy to get into a deadlock otherwise. > > If you implement the sync callback, that will be called from every > non-relaxed accessor, which means if you need to take some kind of > lock in the sync callback and elsewhere in the L2 cache code, you will > definitely deadlock. > > It is safer to put explicit barriers where it is necessary. > > Also remember that the barrier in readl() etc is _after_ the read, not > before, and the barrier in writel() is _before_ the write, not after. > The point is to ensure that DMA memory accesses are properly ordered > with the IO-accessing instructions. Yes, I known it. writel() must be used for the write operations that control "start/stop" or "enable/disable" function, to ensure that the data of previous write operations reaches the target. I've met this kind of problem before. > > So, using readl_relaxed() with a read-modify-write is entirely sensible > provided you do not access DMA memory inbetween. Actually, I don't think this register is that complicated. I copied the code back below. All the bits of L3_MAINT_CTRL are not affected by DMA access operations. The software change the "range | op_type" to specify the operation type and scope, the set the bit "L3_MAINT_STATUS_START" to start the operation. Then wait for that bit to change from 1 to 0 by hardware. + reg = readl(l3_ctrl_base + L3_MAINT_CTRL); + reg &= ~(L3_MAINT_RANGE_MASK | L3_MAINT_TYPE_MASK); + reg |= range | op_type; + reg |= L3_MAINT_STATUS_START; + writel(reg, l3_ctrl_base + L3_MAINT_CTRL); + + /* Wait until the hardware maintenance operation is complete. */ + do { + cpu_relax(); + reg = readl(l3_ctrl_base + L3_MAINT_CTRL); + } while ((reg & L3_MAINT_STATUS_MASK) != L3_MAINT_STATUS_END); >
On 2021/1/29 21:54, Leizhen (ThunderTown) wrote: > > > On 2021/1/29 18:26, Arnd Bergmann wrote: >> On Fri, Jan 29, 2021 at 9:16 AM Arnd Bergmann <arnd@kernel.org> wrote: >>> On Fri, Jan 29, 2021 at 8:23 AM Leizhen (ThunderTown) >>> <thunder.leizhen@huawei.com> wrote: >>>> On 2021/1/28 22:24, Arnd Bergmann wrote: >>>>> On Sat, Jan 16, 2021 at 4:27 AM Zhen Lei <thunder.leizhen@huawei.com> wrote: >>>>>> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile >>>>>> + >>>>>> +static void l3cache_maint_common(u32 range, u32 op_type) >>>>>> +{ >>>>>> + u32 reg; >>>>>> + >>>>>> + reg = readl(l3_ctrl_base + L3_MAINT_CTRL); >>>>>> + reg &= ~(L3_MAINT_RANGE_MASK | L3_MAINT_TYPE_MASK); >>>>>> + reg |= range | op_type; >>>>>> + reg |= L3_MAINT_STATUS_START; >>>>>> + writel(reg, l3_ctrl_base + L3_MAINT_CTRL); >>>>> >>>>> Are there contents of L3_MAINT_CTRL that need to be preserved >>>>> across calls and can not be inferred? A 'readl()' is often expensive, >>>>> so it might be more efficient if you can avoid that. >>>> >>>> Right, this readl() can be replaced with readl_relaxed(). Thanks. >>>> >>>> I'll check and correct the readl() and writel() in other places. >>> >>> What I meant is that if you want to replace them, you should provide >>> performance numbers that show how much difference this makes >>> and add comments in the source code explaining how you proved that >>> the _relaxed() version is actually correct. >> >> Another clarification, as there are actually two independent >> points here: >> >> * if you can completely remove the readl() above and just write a >> hardcoded value into the register, or perhaps read the original >> value once at boot time, that is probably a win because it >> avoids one of the barriers in the beginning. The datasheet should >> tell you if there are any bits in the register that have to be >> preserved > > Code coupling will become very strong. > >> >> * Regarding the _relaxed() accessors, it's a lot harder to know >> whether that is safe, as you first have to show, in particular in case >> any of the accesses stop being guarded by the spinlock in that >> case, and whether there may be a case where you have to >> serialize the memory access against accesses that are still in the >> store queue or prefetched. >> >> Whether this matters at all depends mostly on the type of devices >> you are driving on your SoC. If you have any high-speed network >> interfaces that are unable to do cache coherent DMA, any extra >> instruction here may impact the number of packets you can transfer, >> but if all your high-speed devices are connected to a coherent >> interconnect, I would just go with the obvious approach and use >> the safe MMIO accessors everywhere. > > In fact, this driver has been running on an earlier version for several years > and has not received any feedback about the performance issue. So I didn't > try to optimize it when I first sent these patches. I had to reconsider it > until you noticed it. > > How about keeping it unchanged for the moment? It'll take a lot of time and > energy to retest. In the spirit of code excellence, it's still necessary to optimize it. Yesterday, my family urged me to go back, I wrote it in a hurry. > >> >> Arnd >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> >> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > . >
v4 --> v5: 1. Add SoC macro ARCH_KUNPENG50X, and the Kunpeng L3 cache controller only enabled on that platform. 2. Require the compatible string of the Kunpeng L3 cache controller must have a relevant name on a specific SoC. For example: compatible = "hisilicon,kunpeng509-l3cache", "hisilicon,kunpeng-l3cache"; v3 --> v4: Rename the compatible string from "hisilicon,l3cache" to "hisilicon,kunpeng-l3cache". Then adjust the file name, configuration option name, and description accordingly. v2 --> v3: Add Hisilicon L3 cache controller driver and its document. That's: patch 2-3. v1 --> v2: Discard the middle-tier functions and do silent narrowing cast in the outcache hook functions. For example: -static void l2c220_inv_range(unsigned long start, unsigned long end) +static void l2c220_inv_range(phys_addr_t pa_start, phys_addr_t pa_end) { + unsigned long start = pa_start; + unsigned long end = pa_end; v1: Do cast phys_addr_t to unsigned long by adding a middle-tier function. For example: -static void l2c220_inv_range(unsigned long start, unsigned long end) +static void __l2c220_inv_range(unsigned long start, unsigned long end) { ... } +static void l2c220_inv_range(phys_addr_t start, phys_addr_t end) +{ + __l2c220_inv_range(start, end); +} Zhen Lei (4): ARM: LPAE: Use phys_addr_t instead of unsigned long in outercache hooks ARM: hisi: add support for Kunpeng50x SoC dt-bindings: arm: hisilicon: Add binding for Kunpeng L3 cache controller ARM: Add support for Hisilicon Kunpeng L3 cache controller .../arm/hisilicon/kunpeng-l3cache.yaml | 40 +++++ arch/arm/include/asm/outercache.h | 6 +- arch/arm/mach-hisi/Kconfig | 8 + arch/arm/mm/Kconfig | 10 ++ arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-feroceon-l2.c | 15 +- arch/arm/mm/cache-kunpeng-l3.c | 153 ++++++++++++++++++ arch/arm/mm/cache-kunpeng-l3.h | 30 ++++ arch/arm/mm/cache-l2x0.c | 50 ++++-- arch/arm/mm/cache-tauros2.c | 15 +- arch/arm/mm/cache-uniphier.c | 6 +- arch/arm/mm/cache-xsc3l2.c | 12 +- 12 files changed, 317 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/kunpeng-l3cache.yaml create mode 100644 arch/arm/mm/cache-kunpeng-l3.c create mode 100644 arch/arm/mm/cache-kunpeng-l3.h