[linux-yocto] [PATCH 1/1] dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC
From: Quanyang Wang
The function xilinx_dpdma_chan_alloc_tx_desc can be called
from atomic context, hence use GFP_ATOMIC instead of GFP_KERNEL,
or else it will cause the calltrace as below:
BUG: sleeping function called from invalid context at mm/slab.h:418
in_atomic(): 1, irqs_disabled(): 128, pid: 416, name: alsa-sink-(null
Preemption disabled at:
[] snd_pcm_stream_lock_irq+0x40/0x50
CPU: 2 PID: 416 Comm: alsa-sink-(null Tainted: G O 5.2.17-yocto-standard #1
Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Call trace:
dump_backtrace+0x0/0x138
show_stack+0x24/0x30
dump_stack+0x94/0xbc
___might_sleep+0x14c/0x178
__might_sleep+0x58/0x90
kmem_cache_alloc_trace+0x1a4/0x300
xilinx_dpdma_chan_alloc_tx_desc.isra.0+0x24/0x40
xilinx_dpdma_prep_dma_cyclic+0xc0/0x208
snd_dmaengine_pcm_trigger+0xf8/0x198
soc_pcm_trigger+0xb4/0x128
snd_pcm_do_start+0x48/0x58
snd_pcm_action_single+0x4c/0xa0
snd_pcm_action+0x78/0x90
snd_pcm_action_lock_irq+0x3c/0x60
snd_pcm_common_ioctl+0x4ac/0x10c8
snd_pcm_ioctl+0x48/0x68
do_vfs_ioctl+0x6d4/0x968
ksys_ioctl+0x84/0xb8
__arm64_sys_ioctl+0x28/0x38
el0_svc_common.constprop.0+0x74/0x180
el0_svc_handler+0x70/0x90
el0_svc+0x8/0xc
Signed-off-by: Quanyang Wang
Reviewed-by: Hyun Kwon
---
There are two available flags which can be used here: GFP_ATOMIC
and GFP_NOWAIT. The difference is that GFP_ATOMIC may grab memory
from emergency pools but GFP_NOWAIT not. Since struct xilinx_dpdma_tx_desc
is small, use GFP_ATOMIC is better.
drivers/dma/xilinx/xilinx_dpdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/xilinx/xilinx_dpdma.c
b/drivers/dma/xilinx/xilinx_dpdma.c
index 1ea509e00742..89ade893f51c 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -797,7 +797,7 @@ xilinx_dpdma_chan_alloc_tx_desc(struct xilinx_dpdma_chan
*chan)
{
struct xilinx_dpdma_tx_desc *tx_desc;
- tx_desc = kzalloc(sizeof(*tx_desc), GFP_KERNEL);
+ tx_desc = kzalloc(sizeof(*tx_desc), GFP_ATOMIC);
if (!tx_desc)
return NULL;
--
2.17.1
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/1] [V2] xilinx-zynqmp: fix calltrace
From: Quanyang Wang Hi Bruce, This patch is a V2 patch but no change against V1. Just add some comments in the temporary section of the patch. Would you please help merge these patches to linux-yocto v5.2/standard/xlnx-soc branch? Quanyang Wang (1): dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC drivers/dma/xilinx/xilinx_dpdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.17.1 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] arm64: dts: r8a7795: Add CPUIdle support for all CPU core
This should already be on the branches:
Author: Takeshi Kihara
Date: Tue Oct 15 13:46:44 2019 +0800
arm64: dts: r8a7795: Add CPUIdle support for all CPU core
commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
This patch enables CPUIdle (Core shutdown) support for R-Car H3.
Signed-off-by: Takeshi Kihara
Signed-off-by: Meng Li
Signed-off-by: Bruce Ashfield
:100644 100644 097538cc4b1f 7596216409cd M
arch/arm64/boot/dts/renesas/r8a7795.dtsi
On Tue, Oct 22, 2019 at 10:47 PM wrote:
>
> From: Takeshi Kihara
>
> commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
>
> This patch enables CPUIdle (Core shutdown) support for R-Car H3.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Meng Li
> ---
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 32
>
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index e8c3d5f..7fe7428 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -123,6 +123,7 @@
> power-domains = < R8A7795_PD_CA57_CPU0>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> clocks = < CPG_CORE R8A7795_CLK_Z>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <1024>;
> @@ -135,6 +136,7 @@
> power-domains = < R8A7795_PD_CA57_CPU1>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> clocks = < CPG_CORE R8A7795_CLK_Z>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <1024>;
> @@ -147,6 +149,7 @@
> power-domains = < R8A7795_PD_CA57_CPU2>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> clocks = < CPG_CORE R8A7795_CLK_Z>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <1024>;
> @@ -159,6 +162,7 @@
> power-domains = < R8A7795_PD_CA57_CPU3>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> clocks = < CPG_CORE R8A7795_CLK_Z>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <1024>;
> @@ -171,6 +175,7 @@
> power-domains = < R8A7795_PD_CA53_CPU0>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_1>;
> clocks = < CPG_CORE R8A7795_CLK_Z2>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <535>;
> @@ -182,6 +187,7 @@
> power-domains = < R8A7795_PD_CA53_CPU1>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_1>;
> clocks = < CPG_CORE R8A7795_CLK_Z2>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <535>;
> @@ -193,6 +199,7 @@
> power-domains = < R8A7795_PD_CA53_CPU2>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_1>;
> clocks = < CPG_CORE R8A7795_CLK_Z2>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <535>;
> @@ -204,6 +211,7 @@
> power-domains = < R8A7795_PD_CA53_CPU3>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_1>;
> clocks = < CPG_CORE R8A7795_CLK_Z2>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <535>;
> @@ -221,6 +229,30 @@
> cache-unified;
> cache-level = <2>;
> };
> +
> + idle-states {
> + entry-method = "psci";
> +
> + CPU_SLEEP_0: cpu-sleep-0 {
> + compatible = "arm,idle-state";
> +
Re: [linux-yocto] [PATCH] arm64: dts: r8a7795: Add CPUIdle support for all CPU core
On Tue, Oct 22, 2019 at 10:57 PM Bruce Ashfield wrote: > > This should already be on the branches: > .. and I forgot the commit id: c93bf81feabf89b5ee77838d3bb62825d04dab09 Bruce > Author: Takeshi Kihara > Date: Tue Oct 15 13:46:44 2019 +0800 > > arm64: dts: r8a7795: Add CPUIdle support for all CPU core > > commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git > > This patch enables CPUIdle (Core shutdown) support for R-Car H3. > > Signed-off-by: Takeshi Kihara > Signed-off-by: Meng Li > Signed-off-by: Bruce Ashfield > > :100644 100644 097538cc4b1f 7596216409cd M > arch/arm64/boot/dts/renesas/r8a7795.dtsi > > On Tue, Oct 22, 2019 at 10:47 PM wrote: > > > > From: Takeshi Kihara > > > > commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git > > > > This patch enables CPUIdle (Core shutdown) support for R-Car H3. > > > > Signed-off-by: Takeshi Kihara > > Signed-off-by: Meng Li > > --- > > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 32 > > > > 1 file changed, 32 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi > > b/arch/arm64/boot/dts/renesas/r8a7795.dtsi > > index e8c3d5f..7fe7428 100644 > > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi > > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi > > @@ -123,6 +123,7 @@ > > power-domains = < R8A7795_PD_CA57_CPU0>; > > next-level-cache = <_CA57>; > > enable-method = "psci"; > > + cpu-idle-states = <_SLEEP_0>; > > clocks = < CPG_CORE R8A7795_CLK_Z>; > > operating-points-v2 = <_opp>; > > capacity-dmips-mhz = <1024>; > > @@ -135,6 +136,7 @@ > > power-domains = < R8A7795_PD_CA57_CPU1>; > > next-level-cache = <_CA57>; > > enable-method = "psci"; > > + cpu-idle-states = <_SLEEP_0>; > > clocks = < CPG_CORE R8A7795_CLK_Z>; > > operating-points-v2 = <_opp>; > > capacity-dmips-mhz = <1024>; > > @@ -147,6 +149,7 @@ > > power-domains = < R8A7795_PD_CA57_CPU2>; > > next-level-cache = <_CA57>; > > enable-method = "psci"; > > + cpu-idle-states = <_SLEEP_0>; > > clocks = < CPG_CORE R8A7795_CLK_Z>; > > operating-points-v2 = <_opp>; > > capacity-dmips-mhz = <1024>; > > @@ -159,6 +162,7 @@ > > power-domains = < R8A7795_PD_CA57_CPU3>; > > next-level-cache = <_CA57>; > > enable-method = "psci"; > > + cpu-idle-states = <_SLEEP_0>; > > clocks = < CPG_CORE R8A7795_CLK_Z>; > > operating-points-v2 = <_opp>; > > capacity-dmips-mhz = <1024>; > > @@ -171,6 +175,7 @@ > > power-domains = < R8A7795_PD_CA53_CPU0>; > > next-level-cache = <_CA53>; > > enable-method = "psci"; > > + cpu-idle-states = <_SLEEP_1>; > > clocks = < CPG_CORE R8A7795_CLK_Z2>; > > operating-points-v2 = <_opp>; > > capacity-dmips-mhz = <535>; > > @@ -182,6 +187,7 @@ > > power-domains = < R8A7795_PD_CA53_CPU1>; > > next-level-cache = <_CA53>; > > enable-method = "psci"; > > + cpu-idle-states = <_SLEEP_1>; > > clocks = < CPG_CORE R8A7795_CLK_Z2>; > > operating-points-v2 = <_opp>; > > capacity-dmips-mhz = <535>; > > @@ -193,6 +199,7 @@ > > power-domains = < R8A7795_PD_CA53_CPU2>; > > next-level-cache = <_CA53>; > > enable-method = "psci"; > > + cpu-idle-states = <_SLEEP_1>; > > clocks = < CPG_CORE R8A7795_CLK_Z2>; > > operating-points-v2 = <_opp>; > > capacity-dmips-mhz = <535>; > > @@ -204,6 +211,7 @@ > > power-domains = < R8A7795_PD_CA53_CPU3>; > > next-level-cache = <_CA53>; > > enable-method = "psci"; > > + cpu-idle-states = <_SLEEP_1>; > > clocks = < CPG_CORE R8A7795_CLK_Z2>; > > operating-points-v2 = <_opp>; > > capacity-dmips-mhz = <535>; > > @@ -221,6 +229,30 @@ > >
Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/1] xilinx-zynqmp: fix calltrace
In message: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 0/1] xilinx-zynqmp: fix calltrace on 15/10/2019 quanyang.w...@windriver.com wrote: > From: Quanyang Wang > > Hi Bruce, Michal, > > This patch fixes a calltrace when enable CONFIG_TRACING kernel option. > > Would you please help review and merge these patches to linux-yocto > v5.2/standard/xlnx-soc branch? I've dropped this from my pending queue. Can you send a v2 (clearly marked .. these series are starting to get tangled) with the comments of this thread summarized in the temporary section of the patch. That way, I'll know that I'm merging the proper version. Bruce > > Quanyang Wang (1): > dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC > > drivers/dma/xilinx/xilinx_dpdma.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > -- > 2.17.1 > -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [yocto-kernel-cache master/yocto-5.2][PATCH] marvell-cn96xx: Add profiling feature
In message: [linux-yocto][yocto-kernel-cache master/yocto-5.2][PATCH] marvell-cn96xx: Add profiling feature on 21/10/2019 zhe...@windriver.com wrote: > From: He Zhe > > Add profiling related options for convenience for perf and etc. merged. Bruce > > Signed-off-by: He Zhe > --- > bsp/marvell-cn96xx/marvell-cn96xx.scc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/bsp/marvell-cn96xx/marvell-cn96xx.scc > b/bsp/marvell-cn96xx/marvell-cn96xx.scc > index b98c442f..08d2e721 100644 > --- a/bsp/marvell-cn96xx/marvell-cn96xx.scc > +++ b/bsp/marvell-cn96xx/marvell-cn96xx.scc > @@ -5,3 +5,4 @@ kconf hardware features/edac/edac.cfg > include cfg/usb-mass-storage.scc > > include features/hugetlb/hugetlb.scc > +include features/profiling/profiling.scc > -- > 2.17.1 > -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH] arm64: dts: r8a7795: Add CPUIdle support for all CPU core
From: Takeshi Kihara
commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
This patch enables CPUIdle (Core shutdown) support for R-Car H3.
Signed-off-by: Takeshi Kihara
Signed-off-by: Meng Li
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e8c3d5f..7fe7428 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -123,6 +123,7 @@
power-domains = < R8A7795_PD_CA57_CPU0>;
next-level-cache = <_CA57>;
enable-method = "psci";
+ cpu-idle-states = <_SLEEP_0>;
clocks = < CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <1024>;
@@ -135,6 +136,7 @@
power-domains = < R8A7795_PD_CA57_CPU1>;
next-level-cache = <_CA57>;
enable-method = "psci";
+ cpu-idle-states = <_SLEEP_0>;
clocks = < CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <1024>;
@@ -147,6 +149,7 @@
power-domains = < R8A7795_PD_CA57_CPU2>;
next-level-cache = <_CA57>;
enable-method = "psci";
+ cpu-idle-states = <_SLEEP_0>;
clocks = < CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <1024>;
@@ -159,6 +162,7 @@
power-domains = < R8A7795_PD_CA57_CPU3>;
next-level-cache = <_CA57>;
enable-method = "psci";
+ cpu-idle-states = <_SLEEP_0>;
clocks = < CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <1024>;
@@ -171,6 +175,7 @@
power-domains = < R8A7795_PD_CA53_CPU0>;
next-level-cache = <_CA53>;
enable-method = "psci";
+ cpu-idle-states = <_SLEEP_1>;
clocks = < CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <535>;
@@ -182,6 +187,7 @@
power-domains = < R8A7795_PD_CA53_CPU1>;
next-level-cache = <_CA53>;
enable-method = "psci";
+ cpu-idle-states = <_SLEEP_1>;
clocks = < CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <535>;
@@ -193,6 +199,7 @@
power-domains = < R8A7795_PD_CA53_CPU2>;
next-level-cache = <_CA53>;
enable-method = "psci";
+ cpu-idle-states = <_SLEEP_1>;
clocks = < CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <535>;
@@ -204,6 +211,7 @@
power-domains = < R8A7795_PD_CA53_CPU3>;
next-level-cache = <_CA53>;
enable-method = "psci";
+ cpu-idle-states = <_SLEEP_1>;
clocks = < CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <535>;
@@ -221,6 +229,30 @@
cache-unified;
cache-level = <2>;
};
+
+ idle-states {
+ entry-method = "psci";
+
+ CPU_SLEEP_0: cpu-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x001>;
+ local-timer-stop;
+ entry-latency-us = <400>;
+ exit-latency-us = <500>;
+ min-residency-us = <4000>;
+ status = "okay";
+ };
+
+ CPU_SLEEP_1: cpu-sleep-1 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x001>;
+ local-timer-stop;
+ entry-latency-us = <700>;
+ exit-latency-us = <700>;
+ min-residency-us = <5000>;
+ status =
[linux-yocto] [linux-yocto-v5.2]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core
From: Limeng Hi Bruce, I get below patch from SDK kernel to support cpu idle feature, and intend to merge it into yocto community. 0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch Could you please merge this patch into linux-yocto, branch is v5.2/standard/base? r8a7795.dtsi | 32 1 file changed, 32 insertions(+) thanks, Limeng -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] xilinx-zyqn: Move disable_nonboot_cpus() in front of local_irq_disable()
On Mon, Oct 21, 2019 at 11:27 PM Quanyang Wang
wrote:
>
>
> On 10/21/19 8:05 PM, Bruce Ashfield wrote:
> > On Mon, Oct 21, 2019 at 6:45 AM Michal Simek
> > wrote:
> >> On 21. 10. 19 10:45, Quanyang Wang wrote:
> >>> Hi Michal,
> >>>
> >>> On 10/21/19 4:16 PM, Michal Simek wrote:
> On 21. 10. 19 7:50, quanyang.w...@windriver.com wrote:
> > From: Quanyang Wang
> >
> > When run kdump with enabling CONFIG_DEBUG_PREEMPT, there is a calltrace
> > as below:
> >
> > BUG: using smp_processor_id() in preemptible [] code: sh/303
> > caller is machine_crash_shutdown+0x2c/0xe8
> > CPU: 0 PID: 303 Comm: sh Kdump: loaded Not tainted
> > 5.2.20-yocto-standard #1
> > Hardware name: Xilinx Zynq Platform
> > [<80112ff4>] (unwind_backtrace) from [<8010ca4c>] (show_stack+0x18/0x1c)
> > [<8010ca4c>] (show_stack) from [<809b000c>] (dump_stack+0x70/0x8c)
> > [<809b000c>] (dump_stack) from [<80549a14>]
> > (debug_smp_processor_id+0xd4/0x118)
> > [<80549a14>] (debug_smp_processor_id) from [<80111428>]
> > (machine_crash_shutdown+0x2c/0xe8)
> > [<80111428>] (machine_crash_shutdown) from [<801afe24>]
> > (__crash_kexec+0x70/0xd0)
> > [<801afe24>] (__crash_kexec) from [<801259b4>] (panic+0x110/0x324)
> > [<801259b4>] (panic) from [<805f7018>] (sysrq_handle_crash+0x18/0x1c)
> > [<805f7018>] (sysrq_handle_crash) from [<805f7584>]
> > (__handle_sysrq+0x9c/0x14c)
> > [<805f7584>] (__handle_sysrq) from [<805f79e8>]
> > (write_sysrq_trigger+0x5c/0x6c)
> > [<805f79e8>] (write_sysrq_trigger) from [<8031e850>]
> > (proc_reg_write+0x78/0x8c)
> > [<8031e850>] (proc_reg_write) from [<802b1b28>] (vfs_write+0xc0/0x154)
> > [<802b1b28>] (vfs_write) from [<802b2a64>] (ksys_write+0x6c/0xd4)
> > [<802b2a64>] (ksys_write) from [<80101000>] (ret_fast_syscall+0x0/0x54)
> > Exception stack(0xba157fa8 to 0xba157ff0)
> > 7fa0: 0002 005ab930 0001 005ab930 0002
> > 7fc0: 0002 005ab930 76fa2290 0004 76f3d124 76f3cc8c
> >
> > 7fe0: 0004 7edec940 76edbfff 76e67d16
> >
> > This is because that the function disable_nonboot_cpus is called in
> > order to make sure that the crash kernel runs in the boot CPU(cpu0).
> > And it will enable local irq by calling as below:
> >
> > disable_nonboot_cpus
> >-> freeze_secondary_cpus
> > -> _cpu_down
> > -> percpu_down_write
> > -> rcu_sync_enter
> >-> spin_unlock_irq(>rss_lock)
> > -> local_irq_enable()
> >
> > Then the functions including smp_processor_id() behind
> > disable_nonboot_cpus
> > will run at the irq-enabled context, and this will trigger the
> > calltrace.
> >
> > So move disable_nonboot_cpus() in front of local_irq_disable() to avoid
> > it since disable_nonboot_cpus() not need run at an atomic context.
> >
> > Signed-off-by: Quanyang Wang
> > ---
> >arch/arm/kernel/machine_kexec.c | 3 ++-
> >1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/kernel/machine_kexec.c
> > b/arch/arm/kernel/machine_kexec.c
> > index 654f2b1f9ac0..83d2025a4ab1 100644
> > --- a/arch/arm/kernel/machine_kexec.c
> > +++ b/arch/arm/kernel/machine_kexec.c
> > @@ -145,9 +145,10 @@ static void machine_kexec_mask_interrupts(void)
> > void machine_crash_shutdown(struct pt_regs *regs)
> >{
> > -local_irq_disable();
> >disable_nonboot_cpus();
> >+local_irq_disable();
> > +
> >crash_smp_send_stop();
> > crash_save_cpu(regs, smp_processor_id());
> >
> ok. Can you please check before this if your usecases work without
> disable_nonboot_cpus(). This patch was done pretty long time ago where
> there was an issue with kexec. Long time ago I was talking to arm-soc
> maintainers about this and they told me that mainline code should work
> fine without any need to call disable_nonboot_cpus().
> It means if kexec is working fine we can revert origin patch and use
> what mainline is using.
> >>> It seems that the issue is still there. When crash at cpu1 and crash
> >>> kernel runs at cpu1,
> >>>
> >>> it will hang, the log is as below:
> >>>
> >>> root@xilinx-zynq:~# sh 1.sh
> >>> syscall kexec_file_load not available.
> >>> sysrq: Trigger a crash
> >>> Kernel panic - not syncing: sysrq triggered crash
> >>> CPU: 1 PID: 308 Comm: sh Kdump: loaded Not tainted 5.2.20-yocto-standard
> >>> #4
> >>> Hardware name: Xilinx Zynq Platform
> >>> [<80112eb0>] (unwind_backtrace) from [<8010cc04>] (show_stack+0x18/0x1c)
> >>> [<8010cc04>] (show_stack) from [<8094f8f4>] (dump_stack+0x70/0x8c)
> >>> [<8094f8f4>] (dump_stack) from [<801256f4>] (panic+0xf8/0x320)
> >>> [<801256f4>] (panic) from [<805dbeb0>] (sysrq_handle_crash+0x18/0x1c)
> >>> [<805dbeb0>]
Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core
> -Original Message- > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] > Sent: Wednesday, October 23, 2019 10:39 AM > To: Li, Meng > Cc: linux-yocto@yoctoproject.org; He, Zhe > Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: > dts: r8a7795: Add CPUIdle support for all CPU core > > On Tue, Oct 22, 2019 at 8:06 AM Bruce Ashfield > wrote: > > > > On Tue, Oct 22, 2019 at 3:06 AM Li, Meng wrote: > > > > > > > > > > > > > -Original Message- > > > > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] > > > > Sent: Saturday, October 19, 2019 12:51 PM > > > > To: Li, Meng > > > > Cc: linux-yocto@yoctoproject.org > > > > Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: > arm64: > > > > dts: r8a7795: Add CPUIdle support for all CPU core > > > > > > > > In message: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: > arm64: > > > > dts: r8a7795: Add CPUIdle support for all CPU core > > > > on 15/10/2019 meng...@windriver.com wrote: > > > > > > > > > From: Limeng > > > > > > > > > > Hi Bruce, > > > > > > > > > > I get below patch from SDK kernel to support cpu idle feature, and > intend > > > > to merge it into yocto community. > > > > > > > > > > 0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch > > > > > > > > > > Could you please merge this patch into linux-yocto-dev, branch is > > > > standard/base? > > > > > > > > Looks fine to me, this is now merged. > > > > > > > > > > Hi Bruce, > > > > > > I found a strange thing. > > > When build project, this patch existed yesterday. > > > But now, the patch is missed. > > > Could you please help to check it? > > > > linux-yocto-dev is now 5.4, so all existing branches are gone, support > > and work in -dev now needs to rebased and sent as pull requests. > > > > > > > > I also another similar patch that is requested to be merged into linux- > yocto-5.2, branch is v5.2/standard/base, could you please help to check > whether it is merged, too? > > > > I'll double check 5.2. > > I'm not sure where the patch went .. but I just added it to > v5.2/standard/base and merged it to the BSPs. > Hi Bruce, Thanks! You merged my yesterday pull request for reserve memory, not the patch for CPU idle that I sent to you some days ago. I will send a pull request for CPU idle feature again, wait a moment. Regards, Limeng > Bruce > > > > > Bruce > > > > > > > > Thanks, > > > Limeng > > > > > > > > > > Bruce > > > > > > > > > > > > > > r8a7795.dtsi | 32 > > > > > 1 file changed, 32 insertions(+) > > > > > > > > > > > > > > > thanks, > > > > > Limeng > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [linux-yocto-v5.2/dev]: [kernel v5.2/standard/base and standard/base]: renesas-rcar: arm64: dts: r8a7795-h3ulcb: Add reserved memory regions
merged Bruce On Tue, Oct 22, 2019 at 1:07 AM wrote: > > From: Limeng > > Hi Bruce, > > I get below patch from SDK kernel to support reserved memory for renesas > platform firmware that is integrated in bootloader, and intend to merge it > into yocto community. > > 0001-arm64-dts-r8a7795-h3ulcb-Add-reserved-memory-regions.patch > > Could you please merge this patch into linux-yocto and linux-yocto-dev, > branch are v5.2/standard/base and standard/base? > > r8a7795-h3ulcb.dts | 29 - > 1 file changed, 28 insertions(+), 1 deletion(-) > > > thanks, > Limeng -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core
On Tue, Oct 22, 2019 at 8:06 AM Bruce Ashfield wrote: > > On Tue, Oct 22, 2019 at 3:06 AM Li, Meng wrote: > > > > > > > > > -Original Message- > > > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] > > > Sent: Saturday, October 19, 2019 12:51 PM > > > To: Li, Meng > > > Cc: linux-yocto@yoctoproject.org > > > Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: > > > arm64: > > > dts: r8a7795: Add CPUIdle support for all CPU core > > > > > > In message: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: > > > arm64: > > > dts: r8a7795: Add CPUIdle support for all CPU core > > > on 15/10/2019 meng...@windriver.com wrote: > > > > > > > From: Limeng > > > > > > > > Hi Bruce, > > > > > > > > I get below patch from SDK kernel to support cpu idle feature, and > > > > intend > > > to merge it into yocto community. > > > > > > > > 0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch > > > > > > > > Could you please merge this patch into linux-yocto-dev, branch is > > > standard/base? > > > > > > Looks fine to me, this is now merged. > > > > > > > Hi Bruce, > > > > I found a strange thing. > > When build project, this patch existed yesterday. > > But now, the patch is missed. > > Could you please help to check it? > > linux-yocto-dev is now 5.4, so all existing branches are gone, support > and work in -dev now needs to rebased and sent as pull requests. > > > > > I also another similar patch that is requested to be merged into > > linux-yocto-5.2, branch is v5.2/standard/base, could you please help to > > check whether it is merged, too? > > I'll double check 5.2. I'm not sure where the patch went .. but I just added it to v5.2/standard/base and merged it to the BSPs. Bruce > > Bruce > > > > > Thanks, > > Limeng > > > > > > > Bruce > > > > > > > > > > > r8a7795.dtsi | 32 > > > > 1 file changed, 32 insertions(+) > > > > > > > > > > > > thanks, > > > > Limeng > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core
On Tue, Oct 22, 2019 at 3:06 AM Li, Meng wrote: > > > > > -Original Message- > > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] > > Sent: Saturday, October 19, 2019 12:51 PM > > To: Li, Meng > > Cc: linux-yocto@yoctoproject.org > > Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: > > dts: r8a7795: Add CPUIdle support for all CPU core > > > > In message: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: > > dts: r8a7795: Add CPUIdle support for all CPU core > > on 15/10/2019 meng...@windriver.com wrote: > > > > > From: Limeng > > > > > > Hi Bruce, > > > > > > I get below patch from SDK kernel to support cpu idle feature, and intend > > to merge it into yocto community. > > > > > > 0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch > > > > > > Could you please merge this patch into linux-yocto-dev, branch is > > standard/base? > > > > Looks fine to me, this is now merged. > > > > Hi Bruce, > > I found a strange thing. > When build project, this patch existed yesterday. > But now, the patch is missed. > Could you please help to check it? linux-yocto-dev is now 5.4, so all existing branches are gone, support and work in -dev now needs to rebased and sent as pull requests. > > I also another similar patch that is requested to be merged into > linux-yocto-5.2, branch is v5.2/standard/base, could you please help to check > whether it is merged, too? I'll double check 5.2. Bruce > > Thanks, > Limeng > > > > Bruce > > > > > > > > r8a7795.dtsi | 32 > > > 1 file changed, 32 insertions(+) > > > > > > > > > thanks, > > > Limeng -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [linux-yocto preempt-rt v5.2][PATCH 0/1] kmemleak: Change the lock of kmemleak_object to raw_spinlock_t
I already have the latest 5.2 -stable and -rt under test, so I'll finish those rather than merging this. Bruce On Tue, Oct 22, 2019 at 3:23 AM Yongxin Liu wrote: > > Hi Bruce, > > Could you help to merge this patch to linux-yocto v5.2/standard/preempt-rt? > This patch is only for RT kernel. > It was added in v5.2 rt11. > I know you periodically pull RT patches. But could you help to merge this > patch in advance? > > > Liu Haitao (1): > kmemleak: Change the lock of kmemleak_object to raw_spinlock_t > > mm/kmemleak.c | 72 > +-- > 1 file changed, 36 insertions(+), 36 deletions(-) > > > Thanks, > Yongxin -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [linux-yocto preempt-rt v5.2][PATCH 0/1] kmemleak: Change the lock of kmemleak_object to raw_spinlock_t
Hi Bruce, Could you help to merge this patch to linux-yocto v5.2/standard/preempt-rt? This patch is only for RT kernel. It was added in v5.2 rt11. I know you periodically pull RT patches. But could you help to merge this patch in advance? Liu Haitao (1): kmemleak: Change the lock of kmemleak_object to raw_spinlock_t mm/kmemleak.c | 72 +-- 1 file changed, 36 insertions(+), 36 deletions(-) Thanks, Yongxin -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [linux-yocto preempt-rt v5.2][PATCH 1/1] kmemleak: Change the lock of kmemleak_object to raw_spinlock_t
From: Liu Haitao
commit 217847f57119b5fdd377bfa3d344613ddb98d9fc upstream.
The commit ("kmemleak: Turn kmemleak_lock to raw spinlock on RT")
changed the kmemleak_lock to raw spinlock. However the
kmemleak_object->lock is held after the kmemleak_lock is held in
scan_block().
Make the object->lock a raw_spinlock_t.
Cc: stable...@vger.kernel.org
Link: https://lkml.kernel.org/r/20190927082230.34152-1-yongxin@windriver.com
Signed-off-by: Liu Haitao
Signed-off-by: Yongxin Liu
Signed-off-by: Sebastian Andrzej Siewior
---
mm/kmemleak.c | 72 +--
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index aaee59c0306a..355dd95d0611 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -135,7 +135,7 @@ struct kmemleak_scan_area {
* (use_count) and freed using the RCU mechanism.
*/
struct kmemleak_object {
- spinlock_t lock;
+ raw_spinlock_t lock;
unsigned int flags; /* object status flags */
struct list_head object_list;
struct list_head gray_list;
@@ -560,7 +560,7 @@ static struct kmemleak_object *create_object(unsigned long
ptr, size_t size,
INIT_LIST_HEAD(>object_list);
INIT_LIST_HEAD(>gray_list);
INIT_HLIST_HEAD(>area_list);
- spin_lock_init(>lock);
+ raw_spin_lock_init(>lock);
atomic_set(>use_count, 1);
object->flags = OBJECT_ALLOCATED;
object->pointer = ptr;
@@ -642,9 +642,9 @@ static void __delete_object(struct kmemleak_object *object)
* Locking here also ensures that the corresponding memory block
* cannot be freed when it is being scanned.
*/
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
object->flags &= ~OBJECT_ALLOCATED;
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
put_object(object);
}
@@ -716,9 +716,9 @@ static void paint_it(struct kmemleak_object *object, int
color)
{
unsigned long flags;
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
__paint_it(object, color);
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
}
static void paint_ptr(unsigned long ptr, int color)
@@ -778,7 +778,7 @@ static void add_scan_area(unsigned long ptr, size_t size,
gfp_t gfp)
goto out;
}
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
if (size == SIZE_MAX) {
size = object->pointer + object->size - ptr;
} else if (ptr + size > object->pointer + object->size) {
@@ -794,7 +794,7 @@ static void add_scan_area(unsigned long ptr, size_t size,
gfp_t gfp)
hlist_add_head(>node, >area_list);
out_unlock:
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
out:
put_object(object);
}
@@ -817,9 +817,9 @@ static void object_set_excess_ref(unsigned long ptr,
unsigned long excess_ref)
return;
}
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
object->excess_ref = excess_ref;
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
put_object(object);
}
@@ -839,9 +839,9 @@ static void object_no_scan(unsigned long ptr)
return;
}
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
object->flags |= OBJECT_NO_SCAN;
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
put_object(object);
}
@@ -902,11 +902,11 @@ static void early_alloc(struct early_log *log)
log->min_count, GFP_ATOMIC);
if (!object)
goto out;
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
for (i = 0; i < log->trace_len; i++)
object->trace[i] = log->trace[i];
object->trace_len = log->trace_len;
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
out:
rcu_read_unlock();
}
@@ -1096,9 +1096,9 @@ void __ref kmemleak_update_trace(const void *ptr)
return;
}
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
object->trace_len = __save_stack_trace(object->trace);
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
put_object(object);
}
@@ -1346,7 +1346,7 @@ static void scan_block(void *_start, void *_end,
* previously acquired in scan_object(). These locks are
* enclosed by scan_mutex.
*/
- spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+
[linux-yocto] Next Sync-up
Hi Bruce, When will the next sync-up with stable and RT trees happen? Thanks, Zhe -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core
> -Original Message- > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] > Sent: Saturday, October 19, 2019 12:51 PM > To: Li, Meng > Cc: linux-yocto@yoctoproject.org > Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: > dts: r8a7795: Add CPUIdle support for all CPU core > > In message: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: > dts: r8a7795: Add CPUIdle support for all CPU core > on 15/10/2019 meng...@windriver.com wrote: > > > From: Limeng > > > > Hi Bruce, > > > > I get below patch from SDK kernel to support cpu idle feature, and intend > to merge it into yocto community. > > > > 0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch > > > > Could you please merge this patch into linux-yocto-dev, branch is > standard/base? > > Looks fine to me, this is now merged. > Hi Bruce, I found a strange thing. When build project, this patch existed yesterday. But now, the patch is missed. Could you please help to check it? I also another similar patch that is requested to be merged into linux-yocto-5.2, branch is v5.2/standard/base, could you please help to check whether it is merged, too? Thanks, Limeng > Bruce > > > > > r8a7795.dtsi | 32 > > 1 file changed, 32 insertions(+) > > > > > > thanks, > > Limeng -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC
On 10/18/19 10:42 PM, Radhey Shyam Pandey wrote: -Original Message- From: Hyun Kwon Sent: Thursday, October 17, 2019 11:01 PM To: Quanyang Wang Cc: Hyun Kwon ; Michal Simek ; Bruce ; linux-yocto@yoctoproject.org; Radhey Shyam Pandey Subject: Re: [linux-yocto][PATCH 1/1] dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC Hi Quanyang, + Radhey On Wed, 2019-10-16 at 20:11:39 -0700, Quanyang Wang wrote: On 10/17/19 1:01 AM, Hyun Kwon wrote: Hi Quanyang, Thanks for the patch. On Tue, 2019-10-15 at 22:49:41 -0700, Michal Simek wrote: +Hyun, On 15. 10. 19 16:56, quanyang.w...@windriver.com wrote: From: Quanyang Wang The function xilinx_dpdma_chan_alloc_tx_desc can be called from atomic context, hence use GFP_ATOMIC instead of GFP_KERNEL, or else it will cause the calltrace as below: BUG: sleeping function called from invalid context at mm/slab.h:418 in_atomic(): 1, irqs_disabled(): 128, pid: 416, name: alsa-sink-(null Preemption disabled at: [] snd_pcm_stream_lock_irq+0x40/0x50 CPU: 2 PID: 416 Comm: alsa-sink-(null Tainted: G O 5.2.17-yocto- standard #1 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Call trace: dump_backtrace+0x0/0x138 show_stack+0x24/0x30 dump_stack+0x94/0xbc ___might_sleep+0x14c/0x178 __might_sleep+0x58/0x90 kmem_cache_alloc_trace+0x1a4/0x300 xilinx_dpdma_chan_alloc_tx_desc.isra.0+0x24/0x40 xilinx_dpdma_prep_dma_cyclic+0xc0/0x208 snd_dmaengine_pcm_trigger+0xf8/0x198 soc_pcm_trigger+0xb4/0x128 snd_pcm_do_start+0x48/0x58 snd_pcm_action_single+0x4c/0xa0 snd_pcm_action+0x78/0x90 snd_pcm_action_lock_irq+0x3c/0x60 snd_pcm_common_ioctl+0x4ac/0x10c8 snd_pcm_ioctl+0x48/0x68 do_vfs_ioctl+0x6d4/0x968 ksys_ioctl+0x84/0xb8 __arm64_sys_ioctl+0x28/0x38 el0_svc_common.constprop.0+0x74/0x180 el0_svc_handler+0x70/0x90 el0_svc+0x8/0xc Signed-off-by: Quanyang Wang Maybe the 'nonatomic' can be set to true in xilinx_dp_dai_links? But I don't know much about the flag, ex what's required, and I don't see any problem with this change. So, Reviewed-by: Hyun Kwon Hi Hyun, Thank you for looking this patch over. I test and the "nonatomic" can also eliminate the calltrace. But I don't know if there is any problem with alsa driver running in a nonatomic context. Me neither, so maybe changing gfp flag seems safer in that aspect. :-) And do you think it's better using GFP_NOWAIT instead of GFP_ATOMIC ? This can save some atomic memory. In my limited view, GFP_ATOMIC seems better as the allocation is relatively small but related to IO, rather than relying only on page reclaim. I see both are quite commonly used for dma descriptor allocation, so it doesn't seem like one is clearly better than the other. But I may be wrong. Radhey may have better answer. _NOWAIT is like _ATOMIC except that no wait will not fall back to emergency pools. http://lkml.iu.edu/hypermail/linux/kernel/0911.1/02316.html IMO if allocation is in critical path and small then GFP_ATOMIC can be used else switching to _NOWAIT might be preferred. Hi Radhey, Thank you for your suggestion. Since xilinx_dpdma_tx_desc is small, it seems that GFP_ATOMIC is better. Thanks, Quanyang Thanks, -hyun -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
