* Re: [PATCH v2 1/2] ASoC: fsl_sai: Clean code for synchronous mode
From: Nicolin Chen @ 2020-08-05 3:43 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
perex, broonie, festevam, linux-kernel
In-Reply-To: <1596594233-13489-2-git-send-email-shengjiu.wang@nxp.com>
On Wed, Aug 05, 2020 at 10:23:52AM +0800, Shengjiu Wang wrote:
> Tx synchronous with Rx: The RMR is the word mask register, it is used
> to mask any word in the frame, it is not relating to clock generation,
> So it is no need to be changed when Tx is going to be enabled.
>
> Rx synchronous with Tx: The TMR is the word mask register, it is used
> to mask any word in the frame, it is not relating to clock generation,
> So it is no need to be changed when Rx is going to be enabled.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Can you rename the PATCH subject to something more specific?
For example, "Drop TMR/RMR settings for synchronous mode".
Please add this once it's addressed:
Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 02/17] dma-contiguous: simplify cma_early_percent_memory()
From: Baoquan He @ 2020-08-05 3:50 UTC (permalink / raw)
To: Mike Rapoport
Cc: Emil Renner Berthing, linux-sh, Peter Zijlstra, Dave Hansen,
linux-mips, Max Filippov, Paul Mackerras, sparclinux, linux-riscv,
Will Deacon, Stafford Horne, Marek Szyprowski, linux-arch,
linux-s390, linux-c6x-dev, Yoshinori Sato, x86, Russell King,
Mike Rapoport, clang-built-linux, Ingo Molnar, linux-arm-kernel,
Catalin Marinas, uclinux-h8-devel, linux-xtensa, openrisc,
Borislav Petkov, Andy Lutomirski, Paul Walmsley, Thomas Gleixner,
Hari Bathini, Michal Simek, linux-mm, linuxppc-dev, linux-kernel,
iommu, Palmer Dabbelt, Andrew Morton, Christoph Hellwig
In-Reply-To: <20200802163601.8189-3-rppt@kernel.org>
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> The memory size calculation in cma_early_percent_memory() traverses
> memblock.memory rather than simply call memblock_phys_mem_size(). The
> comment in that function suggests that at some point there should have been
> call to memblock_analyze() before memblock_phys_mem_size() could be used.
> As of now, there is no memblock_analyze() at all and
> memblock_phys_mem_size() can be used as soon as cold-plug memory is
> registerd with memblock.
>
> Replace loop over memblock.memory with a call to memblock_phys_mem_size().
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
> kernel/dma/contiguous.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index 15bc5026c485..1992afd8ca7b 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -73,16 +73,7 @@ early_param("cma", early_cma);
>
> static phys_addr_t __init __maybe_unused cma_early_percent_memory(void)
> {
> - struct memblock_region *reg;
> - unsigned long total_pages = 0;
> -
> - /*
> - * We cannot use memblock_phys_mem_size() here, because
> - * memblock_analyze() has not been called yet.
> - */
> - for_each_memblock(memory, reg)
> - total_pages += memblock_region_memory_end_pfn(reg) -
> - memblock_region_memory_base_pfn(reg);
> + unsigned long total_pages = PHYS_PFN(memblock_phys_mem_size());
Reviewed-by: Baoquan He <bhe@redhat.com>
>
> return (total_pages * CONFIG_CMA_SIZE_PERCENTAGE / 100) << PAGE_SHIFT;
> }
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v2 11/17] arch, mm: replace for_each_memblock() with for_each_mem_pfn_range()
From: Baoquan He @ 2020-08-05 3:57 UTC (permalink / raw)
To: Mike Rapoport
Cc: Emil Renner Berthing, linux-sh, Peter Zijlstra, Dave Hansen,
linux-mips, Max Filippov, Paul Mackerras, sparclinux, linux-riscv,
Will Deacon, Stafford Horne, Marek Szyprowski, linux-arch,
linux-s390, linux-c6x-dev, Yoshinori Sato, x86, Russell King,
Mike Rapoport, clang-built-linux, Ingo Molnar, linux-arm-kernel,
Catalin Marinas, uclinux-h8-devel, linux-xtensa, openrisc,
Borislav Petkov, Andy Lutomirski, Paul Walmsley, Thomas Gleixner,
Hari Bathini, Michal Simek, linux-mm, linuxppc-dev, linux-kernel,
iommu, Palmer Dabbelt, Andrew Morton, Christoph Hellwig
In-Reply-To: <20200802163601.8189-12-rppt@kernel.org>
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> There are several occurrences of the following pattern:
>
> for_each_memblock(memory, reg) {
> start_pfn = memblock_region_memory_base_pfn(reg);
> end_pfn = memblock_region_memory_end_pfn(reg);
>
> /* do something with start_pfn and end_pfn */
> }
>
> Rather than iterate over all memblock.memory regions and each time query
> for their start and end PFNs, use for_each_mem_pfn_range() iterator to get
> simpler and clearer code.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> arch/arm/mm/init.c | 11 ++++-------
> arch/arm64/mm/init.c | 11 ++++-------
> arch/powerpc/kernel/fadump.c | 11 ++++++-----
> arch/powerpc/mm/mem.c | 15 ++++++++-------
> arch/powerpc/mm/numa.c | 7 ++-----
> arch/s390/mm/page-states.c | 6 ++----
> arch/sh/mm/init.c | 9 +++------
> mm/memblock.c | 6 ++----
> mm/sparse.c | 10 ++++------
> 9 files changed, 35 insertions(+), 51 deletions(-)
>
Reviewed-by: Baoquan He <bhe@redhat.com>
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/hotplug-cpu: increase wait time for vCPU death
From: Thiago Jung Bauermann @ 2020-08-05 4:01 UTC (permalink / raw)
To: Michael Ellerman
Cc: Nathan Lynch, Cedric Le Goater, linuxppc-dev, Greg Kurz,
Michael Roth
In-Reply-To: <87zh79yen7.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Greg Kurz <groug@kaod.org> writes:
>> On Tue, 04 Aug 2020 23:35:10 +1000
>> Michael Ellerman <mpe@ellerman.id.au> wrote:
>>> There is a bit of history to this code, but not in a good way :)
>>>
>>> Michael Roth <mdroth@linux.vnet.ibm.com> writes:
>>> > For a power9 KVM guest with XIVE enabled, running a test loop
>>> > where we hotplug 384 vcpus and then unplug them, the following traces
>>> > can be seen (generally within a few loops) either from the unplugged
>>> > vcpu:
>>> >
>>> > [ 1767.353447] cpu 65 (hwid 65) Ready to die...
>>> > [ 1767.952096] Querying DEAD? cpu 66 (66) shows 2
>>> > [ 1767.952311] list_del corruption. next->prev should be c00a000002470208, but was c00a000002470048
>>> ...
>>> >
>>> > At that point the worker thread assumes the unplugged CPU is in some
>>> > unknown/dead state and procedes with the cleanup, causing the race with
>>> > the XIVE cleanup code executed by the unplugged CPU.
>>> >
>>> > Fix this by inserting an msleep() after each RTAS call to avoid
>>>
>>> We previously had an msleep(), but it was removed:
>>>
>>> b906cfa397fd ("powerpc/pseries: Fix cpu hotplug")
>>
>> Ah, I hadn't seen that one...
>>
>>> > pseries_cpu_die() returning prematurely, and double the number of
>>> > attempts so we wait at least a total of 5 seconds. While this isn't an
>>> > ideal solution, it is similar to how we dealt with a similar issue for
>>> > cede_offline mode in the past (940ce422a3).
>>>
>>> Thiago tried to fix this previously but there was a bit of discussion
>>> that didn't quite resolve:
>>>
>>> https://lore.kernel.org/linuxppc-dev/20190423223914.3882-1-bauerman@linux.ibm.com/
>>
>> Yeah it appears that the motivation at the time was to make the "Querying DEAD?"
>> messages to disappear and to avoid potentially concurrent calls to rtas-stop-self
>> which is prohibited by PAPR... not fixing actual crashes.
>
> I'm pretty sure at one point we were triggering crashes *in* RTAS via
> this path, I think that got resolved.
Yes, pHyp's RTAS now tolerates concurrent calls to stop-self. The
original bug that was reported when I worked on this ended in an RTAS
crash because of this timeout. The crash was fixed then.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v2 2/2] ASoC: fsl_sai: Refine enable and disable sequence for synchronous mode
From: Nicolin Chen @ 2020-08-05 4:11 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
perex, broonie, festevam, linux-kernel
In-Reply-To: <1596594233-13489-3-git-send-email-shengjiu.wang@nxp.com>
On Wed, Aug 05, 2020 at 10:23:53AM +0800, Shengjiu Wang wrote:
> Tx synchronous with Rx:
> The TCSR.TE is no need to enabled when only Rx is going to be enabled.
> Check if need to disable RSCR.RE before disabling TCSR.TE.
>
> Rx synchronous with Tx:
> The RCSR.RE is no need to enabled when only Tx is going to be enabled.
> Check if need to disable TSCR.RE before disabling RCSR.TE.
Please add to the commit log more context such as what we have
discussed: what's the problem of the current driver, and why we
_have_to_ apply this change though it's sightly against what RM
recommends.
(If thing is straightforward, it's okay to make the text short.
Yet I believe that this change deserves more than these lines.)
One info that you should mention -- also the main reason why I'm
convinced to add this change: trigger() is still in the shape of
the early version where we only supported one operation mode --
Tx synchronous with Rx. So we need an update for other modes.
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
The git-diff part looks good, please add this in next ver.:
Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
Btw, the new fsl_sai_dir_is_synced() can be probably applied to
other places with a followup patch.
^ permalink raw reply
* Re: [PATCH v2 13/17] x86/setup: simplify initrd relocation and reservation
From: Baoquan He @ 2020-08-05 4:20 UTC (permalink / raw)
To: Mike Rapoport
Cc: Emil Renner Berthing, linux-sh, Peter Zijlstra, Dave Hansen,
linux-mips, Max Filippov, Paul Mackerras, sparclinux, linux-riscv,
Will Deacon, Stafford Horne, Marek Szyprowski, linux-arch,
linux-s390, linux-c6x-dev, Yoshinori Sato, x86, Russell King,
Mike Rapoport, clang-built-linux, Ingo Molnar, linux-arm-kernel,
Catalin Marinas, uclinux-h8-devel, linux-xtensa, openrisc,
Borislav Petkov, Andy Lutomirski, Paul Walmsley, Thomas Gleixner,
Hari Bathini, Michal Simek, linux-mm, linuxppc-dev, linux-kernel,
iommu, Palmer Dabbelt, Andrew Morton, Christoph Hellwig
In-Reply-To: <20200802163601.8189-14-rppt@kernel.org>
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> Currently, initrd image is reserved very early during setup and then it
> might be relocated and re-reserved after the initial physical memory
> mapping is created. The "late" reservation of memblock verifies that mapped
> memory size exceeds the size of initrd, the checks whether the relocation
~ then?
> required and, if yes, relocates inirtd to a new memory allocated from
> memblock and frees the old location.
>
> The check for memory size is excessive as memblock allocation will anyway
> fail if there is not enough memory. Besides, there is no point to allocate
> memory from memblock using memblock_find_in_range() + memblock_reserve()
> when there exists memblock_phys_alloc_range() with required functionality.
>
> Remove the redundant check and simplify memblock allocation.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> arch/x86/kernel/setup.c | 16 +++-------------
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index a3767e74c758..d8de4053c5e8 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -262,16 +262,12 @@ static void __init relocate_initrd(void)
> u64 area_size = PAGE_ALIGN(ramdisk_size);
>
> /* We need to move the initrd down into directly mapped mem */
> - relocated_ramdisk = memblock_find_in_range(0, PFN_PHYS(max_pfn_mapped),
> - area_size, PAGE_SIZE);
> -
> + relocated_ramdisk = memblock_phys_alloc_range(area_size, PAGE_SIZE, 0,
> + PFN_PHYS(max_pfn_mapped));
> if (!relocated_ramdisk)
> panic("Cannot find place for new RAMDISK of size %lld\n",
> ramdisk_size);
>
> - /* Note: this includes all the mem currently occupied by
> - the initrd, we rely on that fact to keep the data intact. */
> - memblock_reserve(relocated_ramdisk, area_size);
> initrd_start = relocated_ramdisk + PAGE_OFFSET;
> initrd_end = initrd_start + ramdisk_size;
> printk(KERN_INFO "Allocated new RAMDISK: [mem %#010llx-%#010llx]\n",
> @@ -298,13 +294,13 @@ static void __init early_reserve_initrd(void)
>
> memblock_reserve(ramdisk_image, ramdisk_end - ramdisk_image);
> }
> +
> static void __init reserve_initrd(void)
> {
> /* Assume only end is not page aligned */
> u64 ramdisk_image = get_ramdisk_image();
> u64 ramdisk_size = get_ramdisk_size();
> u64 ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size);
> - u64 mapped_size;
>
> if (!boot_params.hdr.type_of_loader ||
> !ramdisk_image || !ramdisk_size)
> @@ -312,12 +308,6 @@ static void __init reserve_initrd(void)
>
> initrd_start = 0;
>
> - mapped_size = memblock_mem_size(max_pfn_mapped);
> - if (ramdisk_size >= (mapped_size>>1))
> - panic("initrd too large to handle, "
> - "disabling initrd (%lld needed, %lld available)\n",
> - ramdisk_size, mapped_size>>1);
Reviewed-by: Baoquan He <bhe@redhat.com>
> -
> printk(KERN_INFO "RAMDISK: [mem %#010llx-%#010llx]\n", ramdisk_image,
> ramdisk_end - 1);
>
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/hotplug-cpu: increase wait time for vCPU death
From: Michael Roth @ 2020-08-05 4:37 UTC (permalink / raw)
To: Greg Kurz, Michael Ellerman
Cc: Nathan Lynch, linuxppc-dev, Cedric Le Goater,
Thiago Jung Bauermann
In-Reply-To: <87zh79yen7.fsf@mpe.ellerman.id.au>
Quoting Michael Ellerman (2020-08-04 22:07:08)
> Greg Kurz <groug@kaod.org> writes:
> > On Tue, 04 Aug 2020 23:35:10 +1000
> > Michael Ellerman <mpe@ellerman.id.au> wrote:
> >> There is a bit of history to this code, but not in a good way :)
> >>
> >> Michael Roth <mdroth@linux.vnet.ibm.com> writes:
> >> > For a power9 KVM guest with XIVE enabled, running a test loop
> >> > where we hotplug 384 vcpus and then unplug them, the following traces
> >> > can be seen (generally within a few loops) either from the unplugged
> >> > vcpu:
> >> >
> >> > [ 1767.353447] cpu 65 (hwid 65) Ready to die...
> >> > [ 1767.952096] Querying DEAD? cpu 66 (66) shows 2
> >> > [ 1767.952311] list_del corruption. next->prev should be c00a000002470208, but was c00a000002470048
> >> ...
> >> >
> >> > At that point the worker thread assumes the unplugged CPU is in some
> >> > unknown/dead state and procedes with the cleanup, causing the race with
> >> > the XIVE cleanup code executed by the unplugged CPU.
> >> >
> >> > Fix this by inserting an msleep() after each RTAS call to avoid
> >>
> >> We previously had an msleep(), but it was removed:
> >>
> >> b906cfa397fd ("powerpc/pseries: Fix cpu hotplug")
> >
> > Ah, I hadn't seen that one...
> >
> >> > pseries_cpu_die() returning prematurely, and double the number of
> >> > attempts so we wait at least a total of 5 seconds. While this isn't an
> >> > ideal solution, it is similar to how we dealt with a similar issue for
> >> > cede_offline mode in the past (940ce422a3).
> >>
> >> Thiago tried to fix this previously but there was a bit of discussion
> >> that didn't quite resolve:
> >>
> >> https://lore.kernel.org/linuxppc-dev/20190423223914.3882-1-bauerman@linux.ibm.com/
> >
> > Yeah it appears that the motivation at the time was to make the "Querying DEAD?"
> > messages to disappear and to avoid potentially concurrent calls to rtas-stop-self
> > which is prohibited by PAPR... not fixing actual crashes.
>
> I'm pretty sure at one point we were triggering crashes *in* RTAS via
> this path, I think that got resolved.
>
> >> Spinning forever seems like a bad idea, but as has been demonstrated at
> >> least twice now, continuing when we don't know the state of the other
> >> CPU can lead to straight up crashes.
> >>
> >> So I think I'm persuaded that it's preferable to have the kernel stuck
> >> spinning rather than oopsing.
> >>
> >
> > +1
> >
> >> I'm 50/50 on whether we should have a cond_resched() in the loop. My
> >> first instinct is no, if we're stuck here for 20s a stack trace would be
> >> good. But then we will probably hit that on some big and/or heavily
> >> loaded machine.
> >>
> >> So possibly we should call cond_resched() but have some custom logic in
> >> the loop to print a warning if we are stuck for more than some
> >> sufficiently long amount of time.
> >
> > How long should that be ?
>
> Yeah good question.
>
> I guess step one would be seeing how long it can take on the 384 vcpu
> machine. And we can probably test on some other big machines.
>
> Hopefully Nathan can give us some idea of how long he's seen it take on
> large systems? I know he was concerned about the 20s timeout of the
> softlockup detector.
>
> Maybe a minute or two?
Hmm, so I took a stab at this where I called cond_resched() after
every 5 seconds of polling and printed a warning at the same time (FWIW
that doesn't seem to trigger any warnings on a loaded 96-core mihawk
system using KVM running the 384vcpu unplug loop)
But it sounds like that's not quite what you had in mind. How frequently
do you think we should call cond_resched()? Maybe after 25 iterations
of polling smp_query_cpu_stopped() to keep original behavior somewhat
similar?
I'll let the current patch run on the mihawk system overnight in the
meantime so we at least have that data point, but would be good to
know what things look like a large pHyp machine.
Thanks!
>
> >> > Fixes: eac1e731b59ee ("powerpc/xive: guest exploitation of the XIVE interrupt controller")
> >> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1856588
> >>
> >> This is not public.
> >
> > I'll have a look at changing that.
>
> Thanks.
>
> cheers
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 14fd53d1e5ee7350564cac75e336f8c0dea13bc9
From: kernel test robot @ 2020-08-05 4:47 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 14fd53d1e5ee7350564cac75e336f8c0dea13bc9 Automatic merge of 'master', 'next' and 'fixes' (2020-08-04 23:16)
elapsed time: 927m
configs tested: 108
configs skipped: 7
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
sh se7750_defconfig
mips gpr_defconfig
arm spear13xx_defconfig
mips maltasmvp_defconfig
sh se7206_defconfig
arm spitz_defconfig
arm neponset_defconfig
arm shmobile_defconfig
powerpc pmac32_defconfig
sh sh7785lcr_defconfig
mips cobalt_defconfig
mips rt305x_defconfig
mips pnx8335_stb225_defconfig
ia64 tiger_defconfig
arm ep93xx_defconfig
arm colibri_pxa300_defconfig
arm netwinder_defconfig
arm versatile_defconfig
powerpc mpc7448_hpc2_defconfig
mips bcm63xx_defconfig
sh r7785rp_defconfig
sh shmin_defconfig
arm multi_v7_defconfig
mips tb0287_defconfig
sh rsk7269_defconfig
mips jmr3927_defconfig
xtensa iss_defconfig
powerpc chrp32_defconfig
powerpc powernv_defconfig
sh sdk7786_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20200804
i386 randconfig-a004-20200804
i386 randconfig-a001-20200804
i386 randconfig-a003-20200804
i386 randconfig-a002-20200804
i386 randconfig-a006-20200804
i386 randconfig-a005-20200805
i386 randconfig-a004-20200805
i386 randconfig-a001-20200805
i386 randconfig-a003-20200805
i386 randconfig-a002-20200805
i386 randconfig-a006-20200805
x86_64 randconfig-a013-20200805
x86_64 randconfig-a011-20200805
x86_64 randconfig-a012-20200805
x86_64 randconfig-a016-20200805
x86_64 randconfig-a015-20200805
x86_64 randconfig-a014-20200805
i386 randconfig-a011-20200805
i386 randconfig-a012-20200805
i386 randconfig-a013-20200805
i386 randconfig-a014-20200805
i386 randconfig-a015-20200805
i386 randconfig-a016-20200805
x86_64 randconfig-a006-20200804
x86_64 randconfig-a001-20200804
x86_64 randconfig-a004-20200804
x86_64 randconfig-a005-20200804
x86_64 randconfig-a002-20200804
x86_64 randconfig-a003-20200804
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS 0c83b277ada72b585e6a3e52b067669df15bcedb
From: kernel test robot @ 2020-08-05 4:47 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 0c83b277ada72b585e6a3e52b067669df15bcedb powerpc: Fix circular dependency between percpu.h and mmu.h
elapsed time: 925m
configs tested: 112
configs skipped: 7
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
sh se7750_defconfig
mips gpr_defconfig
arm spear13xx_defconfig
mips maltasmvp_defconfig
sh se7206_defconfig
arm spitz_defconfig
arm neponset_defconfig
arm colibri_pxa300_defconfig
arm netwinder_defconfig
arm versatile_defconfig
powerpc mpc7448_hpc2_defconfig
mips bcm63xx_defconfig
sh r7785rp_defconfig
sh shmin_defconfig
arm multi_v7_defconfig
powerpc chrp32_defconfig
powerpc powernv_defconfig
sh sdk7786_defconfig
arm eseries_pxa_defconfig
m68k atari_defconfig
powerpc holly_defconfig
arm keystone_defconfig
powerpc mpc83xx_defconfig
sh ap325rxa_defconfig
arm mxs_defconfig
sh titan_defconfig
arc alldefconfig
m68k mvme147_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20200804
x86_64 randconfig-a001-20200804
x86_64 randconfig-a004-20200804
x86_64 randconfig-a005-20200804
x86_64 randconfig-a002-20200804
x86_64 randconfig-a003-20200804
i386 randconfig-a005-20200805
i386 randconfig-a004-20200805
i386 randconfig-a001-20200805
i386 randconfig-a003-20200805
i386 randconfig-a002-20200805
i386 randconfig-a006-20200805
i386 randconfig-a005-20200804
i386 randconfig-a004-20200804
i386 randconfig-a006-20200804
i386 randconfig-a001-20200804
i386 randconfig-a003-20200804
i386 randconfig-a002-20200804
x86_64 randconfig-a013-20200805
x86_64 randconfig-a011-20200805
x86_64 randconfig-a012-20200805
x86_64 randconfig-a016-20200805
x86_64 randconfig-a015-20200805
x86_64 randconfig-a014-20200805
i386 randconfig-a011-20200804
i386 randconfig-a012-20200804
i386 randconfig-a013-20200804
i386 randconfig-a014-20200804
i386 randconfig-a015-20200804
i386 randconfig-a016-20200804
i386 randconfig-a014-20200805
i386 randconfig-a015-20200805
i386 randconfig-a016-20200805
i386 randconfig-a011-20200805
i386 randconfig-a012-20200805
i386 randconfig-a013-20200805
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v4] selftests/powerpc: Fix pkey syscall redefinitions
From: Sachin Sant @ 2020-08-05 4:56 UTC (permalink / raw)
To: Sandipan Das; +Cc: David Laight, linuxppc-dev, aneesh.kumar
In-Reply-To: <a4956d838bf59b0a71a2553c5ca81131ea8b49b9.1596561758.git.sandipan@linux.ibm.com>
> On 04-Aug-2020, at 11:01 PM, Sandipan Das <sandipan@linux.ibm.com> wrote:
>
> On distros using older glibc versions, the pkey tests
> encounter build failures due to redefinition of the
> pkey syscall numbers.
>
> For compatibility, commit 743f3544fffb added a wrapper
> for the gettid() syscall and included syscall.h if the
> version of glibc used is older than 2.30. This leads
> to different definitions of SYS_pkey_* as the ones in
> the pkey test header set numeric constants where as the
> ones from syscall.h reuse __NR_pkey_*. The compiler
> complains about redefinitions since they are different.
>
> This replaces SYS_pkey_* definitions with __NR_pkey_*
> such that the definitions in both syscall.h and pkeys.h
> are alike. This way, if syscall.h has to be included
> for compatibility reasons, builds will still succeed.
>
> Fixes: 743f3544fffb ("selftests/powerpc: Add wrapper for gettid")
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Suggested-by: David Laight <david.laight@aculab.com>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH v2 2/2] ASoC: fsl_sai: Refine enable and disable sequence for synchronous mode
From: Shengjiu Wang @ 2020-08-05 5:03 UTC (permalink / raw)
To: Nicolin Chen
Cc: Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, Mark Brown, linuxppc-dev,
linux-kernel
In-Reply-To: <20200805041111.GB10174@Asurada-Nvidia>
On Wed, Aug 5, 2020 at 12:13 PM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Wed, Aug 05, 2020 at 10:23:53AM +0800, Shengjiu Wang wrote:
> > Tx synchronous with Rx:
> > The TCSR.TE is no need to enabled when only Rx is going to be enabled.
> > Check if need to disable RSCR.RE before disabling TCSR.TE.
> >
> > Rx synchronous with Tx:
> > The RCSR.RE is no need to enabled when only Tx is going to be enabled.
> > Check if need to disable TSCR.RE before disabling RCSR.TE.
>
> Please add to the commit log more context such as what we have
> discussed: what's the problem of the current driver, and why we
> _have_to_ apply this change though it's sightly against what RM
> recommends.
>
> (If thing is straightforward, it's okay to make the text short.
> Yet I believe that this change deserves more than these lines.)
>
> One info that you should mention -- also the main reason why I'm
> convinced to add this change: trigger() is still in the shape of
> the early version where we only supported one operation mode --
> Tx synchronous with Rx. So we need an update for other modes.
>
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
>
> The git-diff part looks good, please add this in next ver.:
>
> Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
>
> Btw, the new fsl_sai_dir_is_synced() can be probably applied to
> other places with a followup patch.
Do you mean move it to the beginning of this file?
best regards
wang shengjiu
^ permalink raw reply
* Re: [PATCH v2 2/2] ASoC: fsl_sai: Refine enable and disable sequence for synchronous mode
From: Nicolin Chen @ 2020-08-05 5:15 UTC (permalink / raw)
To: Shengjiu Wang
Cc: Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, Mark Brown, linuxppc-dev,
linux-kernel
In-Reply-To: <CAA+D8ANv-qURC_wu3TzWiiiCAXC88Gc+WGssdjmuWoLPTRm3pA@mail.gmail.com>
On Wed, Aug 05, 2020 at 01:03:37PM +0800, Shengjiu Wang wrote:
> > Btw, the new fsl_sai_dir_is_synced() can be probably applied to
> > other places with a followup patch.
> Do you mean move it to the beginning of this file?
There are other existing places testing "sync[tx] && !sync[!tx]"
so you may submit another change to replace them. But, yea, will
be a good idea to move that helper function to the top.
^ permalink raw reply
* Re: [PATCH v2 13/17] x86/setup: simplify initrd relocation and reservation
From: Mike Rapoport @ 2020-08-05 5:59 UTC (permalink / raw)
To: Baoquan He
Cc: Emil Renner Berthing, linux-sh, Peter Zijlstra, Dave Hansen,
linux-mips, Max Filippov, Paul Mackerras, sparclinux, linux-riscv,
Will Deacon, Stafford Horne, Marek Szyprowski, linux-arch,
linux-s390, linux-c6x-dev, Yoshinori Sato, x86, Russell King,
Mike Rapoport, clang-built-linux, Ingo Molnar, linux-arm-kernel,
Catalin Marinas, uclinux-h8-devel, linux-xtensa, openrisc,
Borislav Petkov, Andy Lutomirski, Paul Walmsley, Thomas Gleixner,
Hari Bathini, Michal Simek, linux-mm, linuxppc-dev, linux-kernel,
iommu, Palmer Dabbelt, Andrew Morton, Christoph Hellwig
In-Reply-To: <20200805042024.GT10792@MiWiFi-R3L-srv>
On Wed, Aug 05, 2020 at 12:20:24PM +0800, Baoquan He wrote:
> On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > Currently, initrd image is reserved very early during setup and then it
> > might be relocated and re-reserved after the initial physical memory
> > mapping is created. The "late" reservation of memblock verifies that mapped
> > memory size exceeds the size of initrd, the checks whether the relocation
> ~ then?
Right, thanks!
> > required and, if yes, relocates inirtd to a new memory allocated from
> > memblock and frees the old location.
^ permalink raw reply
* Re: [PATCH v2 14/17] x86/setup: simplify reserve_crashkernel()
From: Baoquan He @ 2020-08-05 6:00 UTC (permalink / raw)
To: Mike Rapoport
Cc: Emil Renner Berthing, linux-sh, Peter Zijlstra, Dave Hansen,
linux-mips, Max Filippov, Paul Mackerras, sparclinux, linux-riscv,
Will Deacon, Stafford Horne, Marek Szyprowski, linux-arch,
linux-s390, linux-c6x-dev, Yoshinori Sato, x86, Russell King,
Mike Rapoport, clang-built-linux, Ingo Molnar, linux-arm-kernel,
Catalin Marinas, uclinux-h8-devel, linux-xtensa, openrisc,
Borislav Petkov, Andy Lutomirski, Paul Walmsley, Thomas Gleixner,
Hari Bathini, Michal Simek, linux-mm, linuxppc-dev, linux-kernel,
iommu, Palmer Dabbelt, Andrew Morton, Christoph Hellwig
In-Reply-To: <20200802163601.8189-15-rppt@kernel.org>
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> * Replace magic numbers with defines
> * Replace memblock_find_in_range() + memblock_reserve() with
> memblock_phys_alloc_range()
> * Stop checking for low memory size in reserve_crashkernel_low(). The
> allocation from limited range will anyway fail if there is no enough
> memory, so there is no need for extra traversal of memblock.memory
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> arch/x86/kernel/setup.c | 40 ++++++++++++++--------------------------
> 1 file changed, 14 insertions(+), 26 deletions(-)
Applied this patch on top of 5.8, crashkernel reservation works well.
And the code change looks good.
Reviewed-by: Baoquan He <bhe@redhat.com>
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d8de4053c5e8..d7ced6982524 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -419,13 +419,13 @@ static int __init reserve_crashkernel_low(void)
> {
> #ifdef CONFIG_X86_64
> unsigned long long base, low_base = 0, low_size = 0;
> - unsigned long total_low_mem;
> + unsigned long low_mem_limit;
> int ret;
>
> - total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
> + low_mem_limit = min(memblock_phys_mem_size(), CRASH_ADDR_LOW_MAX);
>
> /* crashkernel=Y,low */
> - ret = parse_crashkernel_low(boot_command_line, total_low_mem, &low_size, &base);
> + ret = parse_crashkernel_low(boot_command_line, low_mem_limit, &low_size, &base);
> if (ret) {
> /*
> * two parts from kernel/dma/swiotlb.c:
> @@ -443,23 +443,17 @@ static int __init reserve_crashkernel_low(void)
> return 0;
> }
>
> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0, CRASH_ADDR_LOW_MAX);
> if (!low_base) {
> pr_err("Cannot reserve %ldMB crashkernel low memory, please try smaller size.\n",
> (unsigned long)(low_size >> 20));
> return -ENOMEM;
> }
>
> - ret = memblock_reserve(low_base, low_size);
> - if (ret) {
> - pr_err("%s: Error reserving crashkernel low memblock.\n", __func__);
> - return ret;
> - }
> -
> - pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System low RAM: %ldMB)\n",
> + pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (low RAM limit: %ldMB)\n",
> (unsigned long)(low_size >> 20),
> (unsigned long)(low_base >> 20),
> - (unsigned long)(total_low_mem >> 20));
> + (unsigned long)(low_mem_limit >> 20));
>
> crashk_low_res.start = low_base;
> crashk_low_res.end = low_base + low_size - 1;
> @@ -503,13 +497,13 @@ static void __init reserve_crashkernel(void)
> * unless "crashkernel=size[KMG],high" is specified.
> */
> if (!high)
> - crash_base = memblock_find_in_range(CRASH_ALIGN,
> - CRASH_ADDR_LOW_MAX,
> - crash_size, CRASH_ALIGN);
> + crash_base = memblock_phys_alloc_range(crash_size,
> + CRASH_ALIGN, CRASH_ALIGN,
> + CRASH_ADDR_LOW_MAX);
> if (!crash_base)
> - crash_base = memblock_find_in_range(CRASH_ALIGN,
> - CRASH_ADDR_HIGH_MAX,
> - crash_size, CRASH_ALIGN);
> + crash_base = memblock_phys_alloc_range(crash_size,
> + CRASH_ALIGN, CRASH_ALIGN,
> + CRASH_ADDR_HIGH_MAX);
> if (!crash_base) {
> pr_info("crashkernel reservation failed - No suitable area found.\n");
> return;
> @@ -517,19 +511,13 @@ static void __init reserve_crashkernel(void)
> } else {
> unsigned long long start;
>
> - start = memblock_find_in_range(crash_base,
> - crash_base + crash_size,
> - crash_size, 1 << 20);
> + start = memblock_phys_alloc_range(crash_size, SZ_1M, crash_base,
> + crash_base + crash_size);
> if (start != crash_base) {
> pr_info("crashkernel reservation failed - memory is in use.\n");
> return;
> }
> }
> - ret = memblock_reserve(crash_base, crash_size);
> - if (ret) {
> - pr_err("%s: Error reserving crashkernel memblock.\n", __func__);
> - return;
> - }
>
> if (crash_base >= (1ULL << 32) && reserve_crashkernel_low()) {
> memblock_free(crash_base, crash_size);
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v8 5/8] powerpc/vdso: Prepare for switching VDSO to generic C implementation.
From: Michael Ellerman @ 2020-08-05 6:24 UTC (permalink / raw)
To: Christophe Leroy, Christophe Leroy, Benjamin Herrenschmidt,
Paul Mackerras, nathanl
Cc: linux-arch, arnd, linux-kernel, Tulio Magno Quites Machado Filho,
luto, tglx, vincenzo.frascino, linuxppc-dev
In-Reply-To: <65fd7823-cc9d-c05a-0816-c34882b5d55a@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> On 07/15/2020 01:04 AM, Michael Ellerman wrote:
>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>> Prepare for switching VDSO to generic C implementation in following
>>> patch. Here, we:
>>> - Modify __get_datapage() to take an offset
>>> - Prepare the helpers to call the C VDSO functions
>>> - Prepare the required callbacks for the C VDSO functions
>>> - Prepare the clocksource.h files to define VDSO_ARCH_CLOCKMODES
>>> - Add the C trampolines to the generic C VDSO functions
>>>
>>> powerpc is a bit special for VDSO as well as system calls in the
>>> way that it requires setting CR SO bit which cannot be done in C.
>>> Therefore, entry/exit needs to be performed in ASM.
>>>
>>> Implementing __arch_get_vdso_data() would clobber the link register,
>>> requiring the caller to save it. As the ASM calling function already
>>> has to set a stack frame and saves the link register before calling
>>> the C vdso function, retriving the vdso data pointer there is lighter.
>> ...
>>
>>> diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h
>>> new file mode 100644
>>> index 000000000000..4452897f9bd8
>>> --- /dev/null
>>> +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
>>> @@ -0,0 +1,175 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +#ifndef __ASM_VDSO_GETTIMEOFDAY_H
>>> +#define __ASM_VDSO_GETTIMEOFDAY_H
>>> +
>>> +#include <asm/ptrace.h>
>>> +
>>> +#ifdef __ASSEMBLY__
>>> +
>>> +.macro cvdso_call funct
>>> + .cfi_startproc
>>> + PPC_STLU r1, -STACK_FRAME_OVERHEAD(r1)
>>> + mflr r0
>>> + .cfi_register lr, r0
>>> + PPC_STL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
>>
>> This doesn't work for me on ppc64(le) with glibc.
>>
>> glibc doesn't create a stack frame before making the VDSO call, so the
>> store of r0 (LR) goes into the caller's frame, corrupting the saved LR,
>> leading to an infinite loop.
>>
>> This is an example from a statically built program that calls
>> clock_gettime():
>>
>> 0000000010030cb0 <__clock_gettime>:
>> 10030cb0: 0e 10 40 3c lis r2,4110
>> 10030cb4: 00 7a 42 38 addi r2,r2,31232
>> 10030cb8: a6 02 08 7c mflr r0
>> 10030cbc: ff ff 22 3d addis r9,r2,-1
>> 10030cc0: 58 6d 29 39 addi r9,r9,27992
>> 10030cc4: f0 ff c1 fb std r30,-16(r1) <-- redzone store
>> 10030cc8: 78 23 9e 7c mr r30,r4
>> 10030ccc: f8 ff e1 fb std r31,-8(r1) <-- redzone store
>> 10030cd0: 78 1b 7f 7c mr r31,r3
>> 10030cd4: 10 00 01 f8 std r0,16(r1) <-- save LR to caller's frame
>> 10030cd8: 00 00 09 e8 ld r0,0(r9)
>> 10030cdc: 00 00 20 2c cmpdi r0,0
>> 10030ce0: 50 00 82 41 beq 10030d30 <__clock_gettime+0x80>
>> 10030ce4: a6 03 09 7c mtctr r0
>> 10030ce8: 21 04 80 4e bctrl <-- vdso call
>> 10030cec: 26 00 00 7c mfcr r0
>> 10030cf0: 00 10 09 74 andis. r9,r0,4096
>> 10030cf4: 78 1b 69 7c mr r9,r3
>> 10030cf8: 28 00 82 40 bne 10030d20 <__clock_gettime+0x70>
>> 10030cfc: b4 07 23 7d extsw r3,r9
>> 10030d00: 10 00 01 e8 ld r0,16(r1) <-- load saved LR, since clobbered by the VDSO
>> 10030d04: f0 ff c1 eb ld r30,-16(r1)
>> 10030d08: f8 ff e1 eb ld r31,-8(r1)
>> 10030d0c: a6 03 08 7c mtlr r0 <-- restore LR
>> 10030d10: 20 00 80 4e blr <-- jumps to 10030cec
>>
>>
>> I'm kind of confused how it worked for you on 32-bit.
>
> Indeed, 32-bit doesn't have a redzone, so I believe it needs a stack
> frame whenever it has anything to same.
Yeah OK that would explain it.
> Here is what I have in libc.so:
>
> 000fbb60 <__clock_gettime>:
> fbb60: 94 21 ff e0 stwu r1,-32(r1)
> fbb64: 7c 08 02 a6 mflr r0
> fbb68: 48 09 75 c9 bl 193130 <_IO_stdout_+0x24b0>
> fbb6c: 93 c1 00 18 stw r30,24(r1)
> fbb70: 7f c8 02 a6 mflr r30
> fbb74: 90 01 00 24 stw r0,36(r1)
> fbb78: 93 81 00 10 stw r28,16(r1)
> fbb7c: 93 a1 00 14 stw r29,20(r1)
> fbb80: 83 9e fc 98 lwz r28,-872(r30)
> fbb84: 93 e1 00 1c stw r31,28(r1)
> fbb88: 80 1c 00 00 lwz r0,0(r28)
> fbb8c: 83 82 8f f4 lwz r28,-28684(r2)
> fbb90: 7c 7f 1b 78 mr r31,r3
> fbb94: 7c 00 e2 79 xor. r0,r0,r28
> fbb98: 7c 9d 23 78 mr r29,r4
> fbb9c: 41 82 00 40 beq fbbdc <__clock_gettime+0x7c>
> fbba0: 7c 09 03 a6 mtctr r0
> fbba4: 4e 80 04 21 bctrl
> fbba8: 7c 00 00 26 mfcr r0
> fbbac: 74 1c 10 00 andis. r28,r0,4096
> fbbb0: 40 82 00 24 bne fbbd4 <__clock_gettime+0x74>
> fbbb4: 80 01 00 24 lwz r0,36(r1)
> fbbb8: 83 81 00 10 lwz r28,16(r1)
> fbbbc: 7c 08 03 a6 mtlr r0
> fbbc0: 83 a1 00 14 lwz r29,20(r1)
> fbbc4: 83 c1 00 18 lwz r30,24(r1)
> fbbc8: 83 e1 00 1c lwz r31,28(r1)
> fbbcc: 38 21 00 20 addi r1,r1,32
> fbbd0: 4e 80 00 20 blr
> ...
> 193130: 4e 80 00 21 blrl
>
> But I guess if a prog has a way to avoid having anything to save, we may
> face the same issue.
Yes I think so.
> So lets create two frames:
Yeah I think that's what's required. Might need a comment explaining why
though ;)
> diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h
> b/arch/powerpc/include/asm/vdso/gettimeofday.h
> index a0712a6e80d9..0b6fa245d54e 100644
> --- a/arch/powerpc/include/asm/vdso/gettimeofday.h
> +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
> @@ -10,6 +10,7 @@
> .cfi_startproc
> PPC_STLU r1, -STACK_FRAME_OVERHEAD(r1)
> mflr r0
> + PPC_STLU r1, -STACK_FRAME_OVERHEAD(r1)
> .cfi_register lr, r0
The cfi_register should come directly after the mflr I think.
> PPC_STL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
> get_datapage r5, r0
> @@ -19,7 +20,7 @@
> cmpwi r3, 0
> mtlr r0
> .cfi_restore lr
> - addi r1, r1, STACK_FRAME_OVERHEAD
> + addi r1, r1, 2 * STACK_FRAME_OVERHEAD
> crclr so
> beqlr+
> crset so
> @@ -32,6 +33,7 @@
> .cfi_startproc
> PPC_STLU r1, -STACK_FRAME_OVERHEAD(r1)
> mflr r0
> + PPC_STLU r1, -STACK_FRAME_OVERHEAD(r1)
> .cfi_register lr, r0
> PPC_STL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
> get_datapage r4, r0
> @@ -41,7 +43,7 @@
> crclr so
> mtlr r0
> .cfi_restore lr
> - addi r1, r1, STACK_FRAME_OVERHEAD
> + addi r1, r1, 2 * STACK_FRAME_OVERHEAD
> blr
> .cfi_endproc
> .endm
>
>
>> There's also no code to load/restore the TOC pointer on BE, which I
>> think we'll need to handle.
>
> I see no code in the generated vdso64.so doing anything with r2, but if
> you think that's needed, just let's do it:
Hmm, true.
The compiler will use the toc for globals (and possibly also for large
constants?)
AFAIK there's no way to disable use of the toc, or make it a build error
if it's needed.
But at least currently you can't add any global to the vdso code as it
won't link, because the .data and .bss are discarded.
At the same time it's much safer for us to just save/restore r2, and
probably in the noise performance wise.
So yeah we should probably do as below.
> commit 5a704d89bd5d7aac39194fb4c775f406905bf0a4
> Author: Christophe Leroy <christophe.leroy@csgroup.eu>
> Date: Tue Aug 4 06:31:48 2020 +0000
>
> Save and restore GOT
>
> diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h
> b/arch/powerpc/include/asm/vdso/gettimeofday.h
> index 0b6fa245d54e..fa774086173b 100644
> --- a/arch/powerpc/include/asm/vdso/gettimeofday.h
> +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
> @@ -13,10 +13,16 @@
> PPC_STLU r1, -STACK_FRAME_OVERHEAD(r1)
> .cfi_register lr, r0
> PPC_STL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
> +#ifdef CONFIG_PPC64
> + PPC_STL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1)
> +#endif
> get_datapage r5, r0
> addi r5, r5, VDSO_DATA_OFFSET
> bl \funct
> PPC_LL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
> +#ifdef CONFIG_PPC64
> + PPC_LL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1)
> +#endif
> cmpwi r3, 0
> mtlr r0
> .cfi_restore lr
> @@ -36,10 +42,16 @@
> PPC_STLU r1, -STACK_FRAME_OVERHEAD(r1)
> .cfi_register lr, r0
> PPC_STL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
> +#ifdef CONFIG_PPC64
> + PPC_STL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1)
> +#endif
> get_datapage r4, r0
> addi r4, r4, VDSO_DATA_OFFSET
> bl \funct
> PPC_LL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
> +#ifdef CONFIG_PPC64
> + PPC_LL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1)
> +#endif
> crclr so
> mtlr r0
> .cfi_restore lr
cheers
^ permalink raw reply
* [PATCH v3 0/2] powerpc/watchpoint/ptrace: Buf fix plus new feature flag
From: Ravi Bangoria @ 2020-08-05 6:27 UTC (permalink / raw)
To: mpe
Cc: christophe.leroy, ravi.bangoria, mikey, rogealve, linux-kernel,
paulus, jniethe5, pedromfc, naveen.n.rao, linuxppc-dev
Patch #1 fixes a bug when watchpoint is created with ptrace
PPC_PTRACE_SETHWDEBUG and CONFIG_HAVE_HW_BREAKPOINT=N.
patch #2 introduce new feature bit
PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 which will be set when
running on ISA 3.1 compliant machine.
v2: https://lore.kernel.org/r/20200723093330.306341-1-ravi.bangoria@linux.ibm.com
v2->v3:
- #1: is new
- #2: Set PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 unconditionally
while running on p10.
- Rebased to powerpc/next (cf1ae052e073)
Ravi Bangoria (2):
powerpc/watchpoint/ptrace: Fix SETHWDEBUG when
CONFIG_HAVE_HW_BREAKPOINT=N
powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
Documentation/powerpc/ptrace.rst | 1 +
arch/powerpc/include/uapi/asm/ptrace.h | 1 +
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 4 +++-
3 files changed, 5 insertions(+), 1 deletion(-)
--
2.26.2
^ permalink raw reply
* [PATCH v3 1/2] powerpc/watchpoint/ptrace: Fix SETHWDEBUG when CONFIG_HAVE_HW_BREAKPOINT=N
From: Ravi Bangoria @ 2020-08-05 6:27 UTC (permalink / raw)
To: mpe
Cc: christophe.leroy, ravi.bangoria, mikey, rogealve, linux-kernel,
paulus, jniethe5, pedromfc, naveen.n.rao, linuxppc-dev
In-Reply-To: <20200805062750.290289-1-ravi.bangoria@linux.ibm.com>
When kernel is compiled with CONFIG_HAVE_HW_BREAKPOINT=N, user can
still create watchpoint using PPC_PTRACE_SETHWDEBUG, with limited
functionalities. But, such watchpoints are never firing because of
the missing privilege settings. Fix that.
Reported-by: Pedro Miraglia Franco de Carvalho <pedromfc@br.ibm.com>
Suggested-by: Pedro Miraglia Franco de Carvalho <pedromfc@br.ibm.com>
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 697c7e4b5877..bf94ab837735 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -217,7 +217,7 @@ long ppc_set_hwdebug(struct task_struct *child, struct ppc_hw_breakpoint *bp_inf
return -EIO;
brk.address = ALIGN_DOWN(bp_info->addr, HW_BREAKPOINT_SIZE);
- brk.type = HW_BRK_TYPE_TRANSLATE;
+ brk.type = HW_BRK_TYPE_TRANSLATE | HW_BRK_TYPE_USER;
brk.len = DABR_MAX_LEN;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
brk.type |= HW_BRK_TYPE_READ;
--
2.26.2
^ permalink raw reply related
* [PATCH v3 2/2] powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
From: Ravi Bangoria @ 2020-08-05 6:27 UTC (permalink / raw)
To: mpe
Cc: christophe.leroy, ravi.bangoria, mikey, rogealve, linux-kernel,
paulus, jniethe5, pedromfc, naveen.n.rao, linuxppc-dev
In-Reply-To: <20200805062750.290289-1-ravi.bangoria@linux.ibm.com>
PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 can be used to determine whether
we are running on an ISA 3.1 compliant machine. Which is needed to
determine DAR behaviour, 512 byte boundary limit etc. This was
requested by Pedro Miraglia Franco de Carvalho for extending
watchpoint features in gdb. Note that availability of 2nd DAWR is
independent of this flag and should be checked using
ppc_debug_info->num_data_bps.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
Documentation/powerpc/ptrace.rst | 1 +
arch/powerpc/include/uapi/asm/ptrace.h | 1 +
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/Documentation/powerpc/ptrace.rst b/Documentation/powerpc/ptrace.rst
index 864d4b6dddd1..77725d69eb4a 100644
--- a/Documentation/powerpc/ptrace.rst
+++ b/Documentation/powerpc/ptrace.rst
@@ -46,6 +46,7 @@ features will have bits indicating whether there is support for::
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
#define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x10
+ #define PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 0x20
2. PTRACE_SETHWDEBUG
diff --git a/arch/powerpc/include/uapi/asm/ptrace.h b/arch/powerpc/include/uapi/asm/ptrace.h
index f5f1ccc740fc..7004cfea3f5f 100644
--- a/arch/powerpc/include/uapi/asm/ptrace.h
+++ b/arch/powerpc/include/uapi/asm/ptrace.h
@@ -222,6 +222,7 @@ struct ppc_debug_info {
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x0000000000000004
#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x0000000000000008
#define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x0000000000000010
+#define PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 0x0000000000000020
#ifndef __ASSEMBLY__
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index bf94ab837735..d5be73ab9e74 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -57,6 +57,8 @@ void ppc_gethwdinfo(struct ppc_debug_info *dbginfo)
} else {
dbginfo->features = 0;
}
+ if (cpu_has_feature(CPU_FTR_ARCH_31))
+ dbginfo->features |= PPC_DEBUG_FEATURE_DATA_BP_ARCH_31;
}
int ptrace_get_debugreg(struct task_struct *child, unsigned long addr,
--
2.26.2
^ permalink raw reply related
* [PATCH v3 0/3] refine and clean code for synchronous mode
From: Shengjiu Wang @ 2020-08-05 6:34 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, alsa-devel, linuxppc-dev, linux-kernel
refine and clean code for synchronous mode
Shengjiu Wang (3):
ASoC: fsl_sai: Refine enable/disable TE/RE sequence in trigger()
ASoC: fsl_sai: Drop TMR/RMR settings for synchronous mode
ASoC: fsl_sai: Replace synchronous check with fsl_sai_dir_is_synced
changes in v3:
- Add reviewed-by Nicolin
- refine the commit log.
- Add one more patch #3
changes in v2:
- Split the commit
- refine the sequence in trigger stop
sound/soc/fsl/fsl_sai.c | 173 +++++++++++++++++++++++-----------------
1 file changed, 102 insertions(+), 71 deletions(-)
--
2.27.0
^ permalink raw reply
* [PATCH v3 1/3] ASoC: fsl_sai: Refine enable/disable TE/RE sequence in trigger()
From: Shengjiu Wang @ 2020-08-05 6:34 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, alsa-devel, linuxppc-dev, linux-kernel
In-Reply-To: <20200805063413.4610-1-shengjiu.wang@nxp.com>
Current code enables TCSR.TE and RCSR.RE together, and disable
TCSR.TE and RCSR.RE together in trigger(), which only supports
one operation mode：
1. Rx synchronous with Tx: TE is last enabled and first disabled
Other operation mode need to be considered also:
2. Tx synchronous with Rx: RE is last enabled and first disabled.
3. Asynchronous mode: Tx and Rx are independent.
So the enable TCSR.TE and RCSR.RE sequence and the disable
sequence need to be refined accordingly for #2 and #3.
There is slightly against what RM recommennds with this change.
For example in Rx synchronous with Tx mode, case "aplay 1.wav;
arecord 2.wav" enable TE before RE. But it should be safe to
do so, judging by years of testing results.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
sound/soc/fsl/fsl_sai.c | 126 +++++++++++++++++++++++++++-------------
1 file changed, 85 insertions(+), 41 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index cdff739924e2..566c4747362a 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -37,6 +37,24 @@ static const struct snd_pcm_hw_constraint_list fsl_sai_rate_constraints = {
.list = fsl_sai_rates,
};
+/**
+ * fsl_sai_dir_is_synced - Check if stream is synced by the opposite stream
+ *
+ * SAI supports synchronous mode using bit/frame clocks of either Transmitter's
+ * or Receiver's for both streams. This function is used to check if clocks of
+ * the stream's are synced by the opposite stream.
+ *
+ * @sai: SAI context
+ * @dir: stream direction
+ */
+static inline bool fsl_sai_dir_is_synced(struct fsl_sai *sai, int dir)
+{
+ int adir = (dir == TX) ? RX : TX;
+
+ /* current dir in async mode while opposite dir in sync mode */
+ return !sai->synchronous[dir] && sai->synchronous[adir];
+}
+
static irqreturn_t fsl_sai_isr(int irq, void *devid)
{
struct fsl_sai *sai = (struct fsl_sai *)devid;
@@ -522,6 +540,38 @@ static int fsl_sai_hw_free(struct snd_pcm_substream *substream,
return 0;
}
+static void fsl_sai_config_disable(struct fsl_sai *sai, int dir)
+{
+ unsigned int ofs = sai->soc_data->reg_offset;
+ bool tx = dir == TX;
+ u32 xcsr, count = 100;
+
+ regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx, ofs),
+ FSL_SAI_CSR_TERE, 0);
+
+ /* TERE will remain set till the end of current frame */
+ do {
+ udelay(10);
+ regmap_read(sai->regmap, FSL_SAI_xCSR(tx, ofs), &xcsr);
+ } while (--count && xcsr & FSL_SAI_CSR_TERE);
+
+ regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx, ofs),
+ FSL_SAI_CSR_FR, FSL_SAI_CSR_FR);
+
+ /*
+ * For sai master mode, after several open/close sai,
+ * there will be no frame clock, and can't recover
+ * anymore. Add software reset to fix this issue.
+ * This is a hardware bug, and will be fix in the
+ * next sai version.
+ */
+ if (!sai->is_slave_mode) {
+ /* Software Reset */
+ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR);
+ /* Clear SR bit to finish the reset */
+ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0);
+ }
+}
static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
struct snd_soc_dai *cpu_dai)
@@ -530,7 +580,9 @@ static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
unsigned int ofs = sai->soc_data->reg_offset;
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
- u32 xcsr, count = 100;
+ int adir = tx ? RX : TX;
+ int dir = tx ? TX : RX;
+ u32 xcsr;
/*
* Asynchronous mode: Clear SYNC for both Tx and Rx.
@@ -553,10 +605,22 @@ static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx, ofs),
FSL_SAI_CSR_FRDE, FSL_SAI_CSR_FRDE);
- regmap_update_bits(sai->regmap, FSL_SAI_RCSR(ofs),
- FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
- regmap_update_bits(sai->regmap, FSL_SAI_TCSR(ofs),
+ regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx, ofs),
FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
+ /*
+ * Enable the opposite direction for synchronous mode
+ * 1. Tx sync with Rx: only set RE for Rx; set TE & RE for Tx
+ * 2. Rx sync with Tx: only set TE for Tx; set RE & TE for Rx
+ *
+ * RM recommends to enable RE after TE for case 1 and to enable
+ * TE after RE for case 2, but we here may not always guarantee
+ * that happens: "arecord 1.wav; aplay 2.wav" in case 1 enables
+ * TE after RE, which is against what RM recommends but should
+ * be safe to do, judging by years of testing results.
+ */
+ if (fsl_sai_dir_is_synced(sai, adir))
+ regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
+ FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx, ofs),
FSL_SAI_CSR_xIE_MASK, FSL_SAI_FLAGS);
@@ -571,43 +635,23 @@ static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
/* Check if the opposite FRDE is also disabled */
regmap_read(sai->regmap, FSL_SAI_xCSR(!tx, ofs), &xcsr);
- if (!(xcsr & FSL_SAI_CSR_FRDE)) {
- /* Disable both directions and reset their FIFOs */
- regmap_update_bits(sai->regmap, FSL_SAI_TCSR(ofs),
- FSL_SAI_CSR_TERE, 0);
- regmap_update_bits(sai->regmap, FSL_SAI_RCSR(ofs),
- FSL_SAI_CSR_TERE, 0);
-
- /* TERE will remain set till the end of current frame */
- do {
- udelay(10);
- regmap_read(sai->regmap,
- FSL_SAI_xCSR(tx, ofs), &xcsr);
- } while (--count && xcsr & FSL_SAI_CSR_TERE);
-
- regmap_update_bits(sai->regmap, FSL_SAI_TCSR(ofs),
- FSL_SAI_CSR_FR, FSL_SAI_CSR_FR);
- regmap_update_bits(sai->regmap, FSL_SAI_RCSR(ofs),
- FSL_SAI_CSR_FR, FSL_SAI_CSR_FR);
-
- /*
- * For sai master mode, after several open/close sai,
- * there will be no frame clock, and can't recover
- * anymore. Add software reset to fix this issue.
- * This is a hardware bug, and will be fix in the
- * next sai version.
- */
- if (!sai->is_slave_mode) {
- /* Software Reset for both Tx and Rx */
- regmap_write(sai->regmap, FSL_SAI_TCSR(ofs),
- FSL_SAI_CSR_SR);
- regmap_write(sai->regmap, FSL_SAI_RCSR(ofs),
- FSL_SAI_CSR_SR);
- /* Clear SR bit to finish the reset */
- regmap_write(sai->regmap, FSL_SAI_TCSR(ofs), 0);
- regmap_write(sai->regmap, FSL_SAI_RCSR(ofs), 0);
- }
- }
+
+ /*
+ * If opposite stream provides clocks for synchronous mode and
+ * it is inactive, disable it before disabling the current one
+ */
+ if (fsl_sai_dir_is_synced(sai, adir) && !(xcsr & FSL_SAI_CSR_FRDE))
+ fsl_sai_config_disable(sai, adir);
+
+ /*
+ * Disable current stream if either of:
+ * 1. current stream doesn't provide clocks for synchronous mode
+ * 2. current stream provides clocks for synchronous mode but no
+ * more stream is active.
+ */
+ if (!fsl_sai_dir_is_synced(sai, dir) || !(xcsr & FSL_SAI_CSR_FRDE))
+ fsl_sai_config_disable(sai, dir);
+
break;
default:
return -EINVAL;
--
2.27.0
^ permalink raw reply related
* [PATCH v3 2/3] ASoC: fsl_sai: Drop TMR/RMR settings for synchronous mode
From: Shengjiu Wang @ 2020-08-05 6:34 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, alsa-devel, linuxppc-dev, linux-kernel
In-Reply-To: <20200805063413.4610-1-shengjiu.wang@nxp.com>
Tx synchronous with Rx: The RMR is the word mask register, it is used
to mask any word in the frame, it is not relating to clock generation,
So it is no need to be changed when Tx is going to be enabled.
Rx synchronous with Tx: The TMR is the word mask register, it is used
to mask any word in the frame, it is not relating to clock generation,
So it is no need to be changed when Rx is going to be enabled.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
sound/soc/fsl/fsl_sai.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 566c4747362a..334090d581ae 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -488,8 +488,7 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream,
/*
* For SAI master mode, when Tx(Rx) sync with Rx(Tx) clock, Rx(Tx) will
* generate bclk and frame clock for Tx(Rx), we should set RCR4(TCR4),
- * RCR5(TCR5) and RMR(TMR) for playback(capture), or there will be sync
- * error.
+ * RCR5(TCR5) for playback(capture), or there will be sync error.
*/
if (!sai->is_slave_mode) {
@@ -500,8 +499,6 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream,
regmap_update_bits(sai->regmap, FSL_SAI_TCR5(ofs),
FSL_SAI_CR5_WNW_MASK | FSL_SAI_CR5_W0W_MASK |
FSL_SAI_CR5_FBT_MASK, val_cr5);
- regmap_write(sai->regmap, FSL_SAI_TMR,
- ~0UL - ((1 << channels) - 1));
} else if (!sai->synchronous[RX] && sai->synchronous[TX] && tx) {
regmap_update_bits(sai->regmap, FSL_SAI_RCR4(ofs),
FSL_SAI_CR4_SYWD_MASK | FSL_SAI_CR4_FRSZ_MASK,
@@ -509,8 +506,6 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream,
regmap_update_bits(sai->regmap, FSL_SAI_RCR5(ofs),
FSL_SAI_CR5_WNW_MASK | FSL_SAI_CR5_W0W_MASK |
FSL_SAI_CR5_FBT_MASK, val_cr5);
- regmap_write(sai->regmap, FSL_SAI_RMR,
- ~0UL - ((1 << channels) - 1));
}
}
--
2.27.0
^ permalink raw reply related
* [PATCH v3 3/3] ASoC: fsl_sai: Replace synchronous check with fsl_sai_dir_is_synced
From: Shengjiu Wang @ 2020-08-05 6:34 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, alsa-devel, linuxppc-dev, linux-kernel
In-Reply-To: <20200805063413.4610-1-shengjiu.wang@nxp.com>
As new function fsl_sai_dir_is_synced is included for checking if
stream is synced by the opposite stream, then replace the existing
synchronous checking with this new function.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/fsl_sai.c | 40 ++++++++++++++++------------------------
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 334090d581ae..f6969a5d49e3 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -350,6 +350,8 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq)
unsigned int ofs = sai->soc_data->reg_offset;
unsigned long clk_rate;
u32 savediv = 0, ratio, savesub = freq;
+ int adir = tx ? RX : TX;
+ int dir = tx ? TX : RX;
u32 id;
int ret = 0;
@@ -408,19 +410,17 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq)
* 4) For Tx and Rx are both Synchronous with another SAI, we just
* ignore it.
*/
- if ((sai->synchronous[TX] && !sai->synchronous[RX]) ||
- (!tx && !sai->synchronous[RX])) {
- regmap_update_bits(sai->regmap, FSL_SAI_RCR2(ofs),
+ if (fsl_sai_dir_is_synced(sai, adir)) {
+ regmap_update_bits(sai->regmap, FSL_SAI_xCR2(!tx, ofs),
FSL_SAI_CR2_MSEL_MASK,
FSL_SAI_CR2_MSEL(sai->mclk_id[tx]));
- regmap_update_bits(sai->regmap, FSL_SAI_RCR2(ofs),
+ regmap_update_bits(sai->regmap, FSL_SAI_xCR2(!tx, ofs),
FSL_SAI_CR2_DIV_MASK, savediv - 1);
- } else if ((sai->synchronous[RX] && !sai->synchronous[TX]) ||
- (tx && !sai->synchronous[TX])) {
- regmap_update_bits(sai->regmap, FSL_SAI_TCR2(ofs),
+ } else if (!sai->synchronous[dir]) {
+ regmap_update_bits(sai->regmap, FSL_SAI_xCR2(tx, ofs),
FSL_SAI_CR2_MSEL_MASK,
FSL_SAI_CR2_MSEL(sai->mclk_id[tx]));
- regmap_update_bits(sai->regmap, FSL_SAI_TCR2(ofs),
+ regmap_update_bits(sai->regmap, FSL_SAI_xCR2(tx, ofs),
FSL_SAI_CR2_DIV_MASK, savediv - 1);
}
@@ -442,6 +442,7 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream,
u32 val_cr4 = 0, val_cr5 = 0;
u32 slots = (channels == 1) ? 2 : channels;
u32 slot_width = word_width;
+ int adir = tx ? RX : TX;
int ret;
if (sai->slots)
@@ -491,22 +492,13 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream,
* RCR5(TCR5) for playback(capture), or there will be sync error.
*/
- if (!sai->is_slave_mode) {
- if (!sai->synchronous[TX] && sai->synchronous[RX] && !tx) {
- regmap_update_bits(sai->regmap, FSL_SAI_TCR4(ofs),
- FSL_SAI_CR4_SYWD_MASK | FSL_SAI_CR4_FRSZ_MASK,
- val_cr4);
- regmap_update_bits(sai->regmap, FSL_SAI_TCR5(ofs),
- FSL_SAI_CR5_WNW_MASK | FSL_SAI_CR5_W0W_MASK |
- FSL_SAI_CR5_FBT_MASK, val_cr5);
- } else if (!sai->synchronous[RX] && sai->synchronous[TX] && tx) {
- regmap_update_bits(sai->regmap, FSL_SAI_RCR4(ofs),
- FSL_SAI_CR4_SYWD_MASK | FSL_SAI_CR4_FRSZ_MASK,
- val_cr4);
- regmap_update_bits(sai->regmap, FSL_SAI_RCR5(ofs),
- FSL_SAI_CR5_WNW_MASK | FSL_SAI_CR5_W0W_MASK |
- FSL_SAI_CR5_FBT_MASK, val_cr5);
- }
+ if (!sai->is_slave_mode && fsl_sai_dir_is_synced(sai, adir)) {
+ regmap_update_bits(sai->regmap, FSL_SAI_xCR4(!tx, ofs),
+ FSL_SAI_CR4_SYWD_MASK | FSL_SAI_CR4_FRSZ_MASK,
+ val_cr4);
+ regmap_update_bits(sai->regmap, FSL_SAI_xCR5(!tx, ofs),
+ FSL_SAI_CR5_WNW_MASK | FSL_SAI_CR5_W0W_MASK |
+ FSL_SAI_CR5_FBT_MASK, val_cr5);
}
regmap_update_bits(sai->regmap, FSL_SAI_xCR4(tx, ofs),
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v3 3/3] ASoC: fsl_sai: Replace synchronous check with fsl_sai_dir_is_synced
From: Nicolin Chen @ 2020-08-05 6:55 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
perex, broonie, festevam, linux-kernel
In-Reply-To: <20200805063413.4610-4-shengjiu.wang@nxp.com>
On Wed, Aug 05, 2020 at 02:34:13PM +0800, Shengjiu Wang wrote:
> As new function fsl_sai_dir_is_synced is included for checking if
> stream is synced by the opposite stream, then replace the existing
> synchronous checking with this new function.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Nice, thanks!
^ permalink raw reply
* [PATCH v10 3/5] powerpc/vdso: Save and restore TOC pointer on PPC64
From: Christophe Leroy @ 2020-08-05 7:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, nathanl,
anton
Cc: linux-arch, arnd, linux-kernel, luto, tglx, vincenzo.frascino,
linuxppc-dev
In-Reply-To: <cover.1596611196.git.christophe.leroy@csgroup.eu>
On PPC64, the TOC pointer needs to be saved and restored.
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v9: New.
I'm not sure this is really needed, I can't see the VDSO C code doing
anything with r2, at least on ppc64_defconfig.
So I let you decide whether you take it or not.
---
arch/powerpc/include/asm/vdso/gettimeofday.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h
index e2c462796a22..8ed4329c9fb8 100644
--- a/arch/powerpc/include/asm/vdso/gettimeofday.h
+++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
@@ -19,10 +19,16 @@
.cfi_register lr, r0
PPC_STLU r1, -STACK_FRAME_OVERHEAD(r1)
PPC_STL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
+#ifdef CONFIG_PPC64
+ PPC_STL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1)
+#endif
get_datapage r5, r0
addi r5, r5, VDSO_DATA_OFFSET
bl \funct
PPC_LL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
+#ifdef CONFIG_PPC64
+ PPC_LL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1)
+#endif
cmpwi r3, 0
mtlr r0
.cfi_restore lr
@@ -42,10 +48,16 @@
.cfi_register lr, r0
PPC_STLU r1, -STACK_FRAME_OVERHEAD(r1)
PPC_STL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
+#ifdef CONFIG_PPC64
+ PPC_STL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1)
+#endif
get_datapage r4, r0
addi r4, r4, VDSO_DATA_OFFSET
bl \funct
PPC_LL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1)
+#ifdef CONFIG_PPC64
+ PPC_LL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1)
+#endif
crclr so
mtlr r0
.cfi_restore lr
--
2.25.0
^ permalink raw reply related
* [PATCH v10 0/5] powerpc: switch VDSO to C implementation
From: Christophe Leroy @ 2020-08-05 7:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, nathanl,
anton
Cc: linux-arch, arnd, linux-kernel, luto, tglx, vincenzo.frascino,
linuxppc-dev
This is the tenth version of a series to switch powerpc VDSO to
generic C implementation.
Changes since v10 are:
- Added a comment explaining the reason for the double stack frame
- Moved back .cfi_register lr next to mflr
Main changes since v9 are:
- Dropped the patches which put the VDSO datapage in front of VDSO text in the mapping
- Adds a second stack frame because the caller doesn't set one, at least on PPC64
- Saving the TOC pointer on PPC64 (is that really needed ?)
This series applies on today's powerpc/merge branch.
See the last patches for details on changes and performance.
Christophe Leroy (5):
powerpc/processor: Move cpu_relax() into asm/vdso/processor.h
powerpc/vdso: Prepare for switching VDSO to generic C implementation.
powerpc/vdso: Save and restore TOC pointer on PPC64
powerpc/vdso: Switch VDSO to generic C implementation.
powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32
arch/powerpc/Kconfig | 2 +
arch/powerpc/include/asm/clocksource.h | 7 +
arch/powerpc/include/asm/processor.h | 13 +-
arch/powerpc/include/asm/vdso/clocksource.h | 7 +
arch/powerpc/include/asm/vdso/gettimeofday.h | 197 ++++++++++++
arch/powerpc/include/asm/vdso/processor.h | 23 ++
arch/powerpc/include/asm/vdso/vsyscall.h | 25 ++
arch/powerpc/include/asm/vdso_datapage.h | 40 +--
arch/powerpc/kernel/asm-offsets.c | 49 +--
arch/powerpc/kernel/time.c | 91 +-----
arch/powerpc/kernel/vdso.c | 5 +-
arch/powerpc/kernel/vdso32/Makefile | 32 +-
arch/powerpc/kernel/vdso32/config-fake32.h | 34 +++
arch/powerpc/kernel/vdso32/gettimeofday.S | 300 +------------------
arch/powerpc/kernel/vdso32/vdso32.lds.S | 1 +
arch/powerpc/kernel/vdso32/vgettimeofday.c | 35 +++
arch/powerpc/kernel/vdso64/Makefile | 23 +-
arch/powerpc/kernel/vdso64/gettimeofday.S | 242 +--------------
arch/powerpc/kernel/vdso64/vgettimeofday.c | 29 ++
19 files changed, 453 insertions(+), 702 deletions(-)
create mode 100644 arch/powerpc/include/asm/clocksource.h
create mode 100644 arch/powerpc/include/asm/vdso/clocksource.h
create mode 100644 arch/powerpc/include/asm/vdso/gettimeofday.h
create mode 100644 arch/powerpc/include/asm/vdso/processor.h
create mode 100644 arch/powerpc/include/asm/vdso/vsyscall.h
create mode 100644 arch/powerpc/kernel/vdso32/config-fake32.h
create mode 100644 arch/powerpc/kernel/vdso32/vgettimeofday.c
create mode 100644 arch/powerpc/kernel/vdso64/vgettimeofday.c
--
2.25.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox