* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Nicolin Chen @ 2020-08-04 3:00 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+D8ANagfMXPAkK4-vBDY9rZMukVUXs8FfBCHS0avXt57pekA@mail.gmail.com>
On Tue, Aug 04, 2020 at 10:35:12AM +0800, Shengjiu Wang wrote:
> On Tue, Aug 4, 2020 at 10:11 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> >
> > On Tue, Aug 04, 2020 at 09:39:44AM +0800, Shengjiu Wang wrote:
> > > On Tue, Aug 4, 2020 at 5:57 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> > > >
> > > > On Mon, Aug 03, 2020 at 04:04:23PM +0800, Shengjiu Wang wrote:
> > > >
> > > > > > > clock generation. The TCSR.TE is no need to enabled when only RX
> > > > > > > is enabled.
> > > > > >
> > > > > > You are correct if there's only RX running without TX joining.
> > > > > > However, that's something we can't guarantee. Then we'd enable
> > > > > > TE after RE is enabled, which is against what RM recommends:
> > > > > >
> > > > > > # From 54.3.3.1 Synchronous mode in IMX6SXRM
> > > > > > # If the receiver bit clock and frame sync are to be used by
> > > > > > # both the transmitter and receiver, it is recommended that
> > > > > > # the receiver is the last enabled and the first disabled.
> > > > > >
> > > > > > I remember I did this "ugly" design by strictly following what
> > > > > > RM says. If hardware team has updated the RM or removed this
> > > > > > limitation, please quote in the commit logs.
> > > > >
> > > > > There is no change in RM and same recommandation.
> > > > >
> > > > > My change does not violate the RM. The direction which generates
> > > > > the clock is still last enabled.
> > > >
> > > > Using Tx syncing with Rx clock for example,
> > > > T1: arecord (non-stop) => set RE
> > > > T2: aplay => set TE then RE (but RE is already set at T1)
> > > >
> > > > Anything that I am missing?
> > >
> > > This is a good example.
> > > We have used this change locally for a long time, so I think it is
> > > safe to do this change, a little different with the recommandation.
> >
> > Any reason for we have to go against the recommendation?
>
> Previous code will enable TE and RE together even for asynchronous
> mode.
> And for recommendation, previous code just consider the RX sync with
> TX, but still violates the recommendation for TX sync with RX case.
> So at least this new change is some kind of improvement.
Okay. Let's change it then. Please make sure to update/remove
those old comments in the trigger(). And it's probably better
to mention that what we do now is a bit different from RM:
/*
* 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.
*/
Btw, do we need similar change for TRIGGER_STOP?
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Shengjiu Wang @ 2020-08-04 3:23 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: <20200804030004.GA27028@Asurada-Nvidia>
On Tue, Aug 4, 2020 at 11:00 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Tue, Aug 04, 2020 at 10:35:12AM +0800, Shengjiu Wang wrote:
> > On Tue, Aug 4, 2020 at 10:11 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> > >
> > > On Tue, Aug 04, 2020 at 09:39:44AM +0800, Shengjiu Wang wrote:
> > > > On Tue, Aug 4, 2020 at 5:57 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> > > > >
> > > > > On Mon, Aug 03, 2020 at 04:04:23PM +0800, Shengjiu Wang wrote:
> > > > >
> > > > > > > > clock generation. The TCSR.TE is no need to enabled when only RX
> > > > > > > > is enabled.
> > > > > > >
> > > > > > > You are correct if there's only RX running without TX joining.
> > > > > > > However, that's something we can't guarantee. Then we'd enable
> > > > > > > TE after RE is enabled, which is against what RM recommends:
> > > > > > >
> > > > > > > # From 54.3.3.1 Synchronous mode in IMX6SXRM
> > > > > > > # If the receiver bit clock and frame sync are to be used by
> > > > > > > # both the transmitter and receiver, it is recommended that
> > > > > > > # the receiver is the last enabled and the first disabled.
> > > > > > >
> > > > > > > I remember I did this "ugly" design by strictly following what
> > > > > > > RM says. If hardware team has updated the RM or removed this
> > > > > > > limitation, please quote in the commit logs.
> > > > > >
> > > > > > There is no change in RM and same recommandation.
> > > > > >
> > > > > > My change does not violate the RM. The direction which generates
> > > > > > the clock is still last enabled.
> > > > >
> > > > > Using Tx syncing with Rx clock for example,
> > > > > T1: arecord (non-stop) => set RE
> > > > > T2: aplay => set TE then RE (but RE is already set at T1)
> > > > >
> > > > > Anything that I am missing?
> > > >
> > > > This is a good example.
> > > > We have used this change locally for a long time, so I think it is
> > > > safe to do this change, a little different with the recommandation.
> > >
> > > Any reason for we have to go against the recommendation?
> >
> > Previous code will enable TE and RE together even for asynchronous
> > mode.
> > And for recommendation, previous code just consider the RX sync with
> > TX, but still violates the recommendation for TX sync with RX case.
> > So at least this new change is some kind of improvement.
>
> Okay. Let's change it then. Please make sure to update/remove
> those old comments in the trigger(). And it's probably better
> to mention that what we do now is a bit different from RM:
> /*
> * 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.
> */
Thank you for the agreement.
>
> Btw, do we need similar change for TRIGGER_STOP?
This is a good question. It is better to do change for STOP,
but I am afraid that there is no much test to guarantee the result.
best regards
wang shengjiu
^ permalink raw reply
* [PATCH] powerpc/pseries/hotplug-cpu: increase wait time for vCPU death
From: Michael Roth @ 2020-08-04 3:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nathan Lynch, Cedric Le Goater, Greg Kurz
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
[ 1767.952322] ------------[ cut here ]------------
[ 1767.952323] kernel BUG at lib/list_debug.c:56!
[ 1767.952325] Oops: Exception in kernel mode, sig: 5 [#1]
[ 1767.952326] LE SMP NR_CPUS=2048 NUMA pSeries
[ 1767.952328] Modules linked in: fuse nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat_ipv6 nf_nat_ipv6 nft_chain_route_ipv6 nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_chain_route_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink uio_pdrv_genirq ip_tables xfs libcrc32c sd_mod sg xts vmx_crypto virtio_net net_failover failover virtio_scsi dm_multipath dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
[ 1767.952352] CPU: 66 PID: 0 Comm: swapper/66 Kdump: loaded Not tainted 4.18.0-221.el8.ppc64le #1
[ 1767.952354] NIP: c0000000007ab50c LR: c0000000007ab508 CTR: 00000000000003ac
[ 1767.952355] REGS: c0000009e5a17840 TRAP: 0700 Not tainted (4.18.0-221.el8.ppc64le)
[ 1767.952355] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28000842 XER: 20040000
[ 1767.952360] CFAR: c0000000001ffe64 IRQMASK: 1
[ 1767.952360] GPR00: c0000000007ab508 c0000009e5a17ac0 c000000001ac0700 0000000000000054
[ 1767.952360] GPR04: c0000009f056cf90 c0000009f05f5628 c0000009ed40d654 c000000001c90700
[ 1767.952360] GPR08: 0000000000000007 c0000009f0573980 00000009ef2b0000 7562202c38303230
[ 1767.952360] GPR12: 0000000000000000 c0000007fff6ce80 c00a000002470208 0000000000000000
[ 1767.952360] GPR16: 0000000000000001 c0000009f05fbb00 0000000000000800 c0000009ff3d4980
[ 1767.952360] GPR20: c0000009f05fbb10 5deadbeef0000100 5deadbeef0000200 0000000000187961
[ 1767.952360] GPR24: c0000009e5a17b78 0000000000000000 0000000000000001 ffffffffffffffff
[ 1767.952360] GPR28: c00a000002470200 c0000009f05fbb10 c0000009f05fbb10 0000000000000000
[ 1767.952375] NIP [c0000000007ab50c] __list_del_entry_valid+0xac/0x100
[ 1767.952376] LR [c0000000007ab508] __list_del_entry_valid+0xa8/0x100
[ 1767.952377] Call Trace:
[ 1767.952378] [c0000009e5a17ac0] [c0000000007ab508] __list_del_entry_valid+0xa8/0x100 (unreliable)
[ 1767.952381] [c0000009e5a17b20] [c000000000476e18] free_pcppages_bulk+0x1f8/0x940
[ 1767.952383] [c0000009e5a17c20] [c00000000047a9a0] free_unref_page+0xd0/0x100
[ 1767.952386] [c0000009e5a17c50] [c0000000000bc2a8] xive_spapr_cleanup_queue+0x148/0x1b0
[ 1767.952388] [c0000009e5a17cf0] [c0000000000b96dc] xive_teardown_cpu+0x1bc/0x240
[ 1767.952391] [c0000009e5a17d30] [c00000000010bf28] pseries_mach_cpu_die+0x78/0x2f0
[ 1767.952393] [c0000009e5a17de0] [c00000000005c8d8] cpu_die+0x48/0x70
[ 1767.952394] [c0000009e5a17e00] [c000000000021cf0] arch_cpu_idle_dead+0x20/0x40
[ 1767.952397] [c0000009e5a17e20] [c0000000001b4294] do_idle+0x2f4/0x4c0
[ 1767.952399] [c0000009e5a17ea0] [c0000000001b46a8] cpu_startup_entry+0x38/0x40
[ 1767.952400] [c0000009e5a17ed0] [c00000000005c43c] start_secondary+0x7bc/0x8f0
[ 1767.952403] [c0000009e5a17f90] [c00000000000ac70] start_secondary_prolog+0x10/0x14
or on the worker thread handling the unplug:
[ 1538.253044] pseries-hotplug-cpu: Attempting to remove CPU <NULL>, drc index: 1000013a
[ 1538.360259] Querying DEAD? cpu 314 (314) shows 2
[ 1538.360736] BUG: Bad page state in process kworker/u768:3 pfn:95de1
[ 1538.360746] cpu 314 (hwid 314) Ready to die...
[ 1538.360784] page:c00a000002577840 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0
[ 1538.361881] flags: 0x5ffffc00000000()
[ 1538.361908] raw: 005ffffc00000000 5deadbeef0000100 5deadbeef0000200 0000000000000000
[ 1538.361955] raw: 0000000000000000 0000000000000000 00000000ffffff7f 0000000000000000
[ 1538.362002] page dumped because: nonzero mapcount
[ 1538.362033] Modules linked in: kvm xt_CHECKSUM ipt_MASQUERADE xt_conntrack ipt_REJECT nft_counter nf_nat_tftp nft_objref nf_conntrack_tftp tun bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink sunrpc xts vmx_crypto ip_tables xfs libcrc32c sd_mod sg virtio_net net_failover virtio_scsi failover dm_mirror dm_region_hash dm_log dm_mod
[ 1538.362613] CPU: 0 PID: 548 Comm: kworker/u768:3 Kdump: loaded Not tainted 4.18.0-224.el8.bz1856588.ppc64le #1
[ 1538.362687] Workqueue: pseries hotplug workque pseries_hp_work_fn
[ 1538.362725] Call Trace:
[ 1538.362743] [c0000009d4adf590] [c000000000e0e0fc] dump_stack+0xb0/0xf4 (unreliable)
[ 1538.362789] [c0000009d4adf5d0] [c000000000475dfc] bad_page+0x12c/0x1b0
[ 1538.362827] [c0000009d4adf660] [c0000000004784bc] free_pcppages_bulk+0x5bc/0x940
[ 1538.362871] [c0000009d4adf760] [c000000000478c38] page_alloc_cpu_dead+0x118/0x120
[ 1538.362918] [c0000009d4adf7b0] [c00000000015b898] cpuhp_invoke_callback.constprop.5+0xb8/0x760
[ 1538.362969] [c0000009d4adf820] [c00000000015eee8] _cpu_down+0x188/0x340
[ 1538.363007] [c0000009d4adf890] [c00000000015d75c] cpu_down+0x5c/0xa0
[ 1538.363045] [c0000009d4adf8c0] [c00000000092c544] cpu_subsys_offline+0x24/0x40
[ 1538.363091] [c0000009d4adf8e0] [c0000000009212f0] device_offline+0xf0/0x130
[ 1538.363129] [c0000009d4adf920] [c00000000010aee4] dlpar_offline_cpu+0x1c4/0x2a0
[ 1538.363174] [c0000009d4adf9e0] [c00000000010b2f8] dlpar_cpu_remove+0xb8/0x190
[ 1538.363219] [c0000009d4adfa60] [c00000000010b4fc] dlpar_cpu_remove_by_index+0x12c/0x150
[ 1538.363264] [c0000009d4adfaf0] [c00000000010ca24] dlpar_cpu+0x94/0x800
[ 1538.363302] [c0000009d4adfc00] [c000000000102cc8] pseries_hp_work_fn+0x128/0x1e0
[ 1538.363347] [c0000009d4adfc70] [c00000000018aa84] process_one_work+0x304/0x5d0
[ 1538.363394] [c0000009d4adfd10] [c00000000018b5cc] worker_thread+0xcc/0x7a0
[ 1538.363433] [c0000009d4adfdc0] [c00000000019567c] kthread+0x1ac/0x1c0
[ 1538.363469] [c0000009d4adfe30] [c00000000000b7dc] ret_from_kernel_thread+0x5c/0x80
The latter trace is due to the following sequence:
page_alloc_cpu_dead
drain_pages
drain_pages_zone
free_pcppages_bulk
where drain_pages() in this case is called under the assumption that
the unplugged cpu is no longer executing. To ensure that is the case,
and early call is made to __cpu_die()->pseries_cpu_die(), which runs
a loop that waits for the cpu to reach a halted state by polling its
status via query-cpu-stopped-state RTAS calls. It only polls for
25 iterations before giving up, however, and in the trace above this
results in the following being printed only .1 seconds after the
hotplug worker thread begins processing the unplug request:
[ 1538.253044] pseries-hotplug-cpu: Attempting to remove CPU <NULL>, drc index: 1000013a
[ 1538.360259] Querying DEAD? cpu 314 (314) shows 2
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
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).
Fixes: eac1e731b59ee ("powerpc/xive: guest exploitation of the XIVE interrupt controller")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1856588
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Cedric Le Goater <clg@kaod.org>
Cc: Greg Kurz <groug@kaod.org>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index c6e0d8abf75e..3cb172758052 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -111,13 +111,12 @@ static void pseries_cpu_die(unsigned int cpu)
int cpu_status = 1;
unsigned int pcpu = get_hard_smp_processor_id(cpu);
- for (tries = 0; tries < 25; tries++) {
+ for (tries = 0; tries < 50; tries++) {
cpu_status = smp_query_cpu_stopped(pcpu);
if (cpu_status == QCSS_STOPPED ||
cpu_status == QCSS_HARDWARE_ERROR)
break;
- cpu_relax();
-
+ msleep(100);
}
if (cpu_status != 0) {
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] sched/topology: Allow archs to override cpu_smt_mask
From: Srikar Dronamraju @ 2020-08-04 3:33 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Gautham R Shenoy, Michael Neuling, Vincent Guittot,
Srikar Dronamraju, Rik van Riel, linuxppc-dev, LKML,
Dietmar Eggemann, Thomas Gleixner, Mel Gorman, Valentin Schneider
cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
most architectures. One of the users of cpu_smt_mask(), would be to
identify idle-cores. On Power9, a pair of cores can be presented by the
firmware as a big-core for backward compatibility reasons.
In order to maintain userspace backward compatibility with previous
versions of processor, (since Power8 had SMT8 cores), Power9 onwards there
is option to the firmware to advertise a pair of SMT4 cores as a fused
cores (referred to as the big_core mode in the Linux Kernel). On Power9
this pair shares the L2 cache as well. However, from the scheduler's point
of view, a core should be determined by SMT4. The load-balancer already
does this. Hence allow PowerPc architecture to override the default
cpu_smt_mask() to point to the SMT4 cores in a big_core mode.
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michael Neuling <mikey@neuling.org>
Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
---
include/linux/topology.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 608fa4aadf0e..ad03df1cc266 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -198,7 +198,7 @@ static inline int cpu_to_mem(int cpu)
#define topology_die_cpumask(cpu) cpumask_of(cpu)
#endif
-#ifdef CONFIG_SCHED_SMT
+#if defined(CONFIG_SCHED_SMT) && !defined(cpu_smt_mask)
static inline const struct cpumask *cpu_smt_mask(int cpu)
{
return topology_sibling_cpumask(cpu);
--
2.18.2
^ permalink raw reply related
* [PATCH 2/2] powerpc/topology: Override cpu_smt_mask
From: Srikar Dronamraju @ 2020-08-04 3:33 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Gautham R Shenoy, Michael Neuling, Vincent Guittot,
Srikar Dronamraju, Rik van Riel, linuxppc-dev, LKML,
Dietmar Eggemann, Thomas Gleixner, Mel Gorman, Valentin Schneider
In-Reply-To: <20200804033307.76111-1-srikar@linux.vnet.ibm.com>
On Power9 a pair of cores can be presented by the firmware as a big-core
for backward compatibility reasons, with 4 threads per (small) core and 8
threads per big-core. cpu_smt_mask() should generally point to the cpu mask
of the (small)core.
In order to maintain userspace backward compatibility (with Power8 chips in
case of Power9) in enterprise Linux systems, the topology_sibling_cpumask
has to be set to big-core. Hence override the default cpu_smt_mask() to be
powerpc specific allowing for better scheduling behaviour on Power.
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michael Neuling <mikey@neuling.org>
Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/cputhreads.h | 1 -
arch/powerpc/include/asm/smp.h | 13 +++++++++++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputhreads.h b/arch/powerpc/include/asm/cputhreads.h
index deb99fd6e060..98c8bd155bf9 100644
--- a/arch/powerpc/include/asm/cputhreads.h
+++ b/arch/powerpc/include/asm/cputhreads.h
@@ -23,7 +23,6 @@
extern int threads_per_core;
extern int threads_per_subcore;
extern int threads_shift;
-extern bool has_big_cores;
extern cpumask_t threads_core_mask;
#else
#define threads_per_core 1
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 9cd0765633c5..d4bc28accb28 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -131,6 +131,19 @@ static inline struct cpumask *cpu_smallcore_mask(int cpu)
extern int cpu_to_core_id(int cpu);
+extern bool has_big_cores;
+
+#define cpu_smt_mask cpu_smt_mask
+#ifdef CONFIG_SCHED_SMT
+static inline const struct cpumask *cpu_smt_mask(int cpu)
+{
+ if (has_big_cores)
+ return per_cpu(cpu_smallcore_map, cpu);
+
+ return per_cpu(cpu_sibling_map, cpu);
+}
+#endif /* CONFIG_SCHED_SMT */
+
/* Since OpenPIC has only 4 IPIs, we use slightly different message numbers.
*
* Make sure this matches openpic_request_IPIs in open_pic.c, or what shows up
--
2.18.2
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Shengjiu Wang @ 2020-08-04 4:22 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: <CAA+D8ANuLQuUO+VsABjt2t1ccK+LGayq13d6EEcV18=4KNaC+w@mail.gmail.com>
On Tue, Aug 4, 2020 at 11:23 AM Shengjiu Wang <shengjiu.wang@gmail.com> wrote:
>
> On Tue, Aug 4, 2020 at 11:00 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> >
> > On Tue, Aug 04, 2020 at 10:35:12AM +0800, Shengjiu Wang wrote:
> > > On Tue, Aug 4, 2020 at 10:11 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> > > >
> > > > On Tue, Aug 04, 2020 at 09:39:44AM +0800, Shengjiu Wang wrote:
> > > > > On Tue, Aug 4, 2020 at 5:57 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> > > > > >
> > > > > > On Mon, Aug 03, 2020 at 04:04:23PM +0800, Shengjiu Wang wrote:
> > > > > >
> > > > > > > > > clock generation. The TCSR.TE is no need to enabled when only RX
> > > > > > > > > is enabled.
> > > > > > > >
> > > > > > > > You are correct if there's only RX running without TX joining.
> > > > > > > > However, that's something we can't guarantee. Then we'd enable
> > > > > > > > TE after RE is enabled, which is against what RM recommends:
> > > > > > > >
> > > > > > > > # From 54.3.3.1 Synchronous mode in IMX6SXRM
> > > > > > > > # If the receiver bit clock and frame sync are to be used by
> > > > > > > > # both the transmitter and receiver, it is recommended that
> > > > > > > > # the receiver is the last enabled and the first disabled.
> > > > > > > >
> > > > > > > > I remember I did this "ugly" design by strictly following what
> > > > > > > > RM says. If hardware team has updated the RM or removed this
> > > > > > > > limitation, please quote in the commit logs.
> > > > > > >
> > > > > > > There is no change in RM and same recommandation.
> > > > > > >
> > > > > > > My change does not violate the RM. The direction which generates
> > > > > > > the clock is still last enabled.
> > > > > >
> > > > > > Using Tx syncing with Rx clock for example,
> > > > > > T1: arecord (non-stop) => set RE
> > > > > > T2: aplay => set TE then RE (but RE is already set at T1)
> > > > > >
> > > > > > Anything that I am missing?
> > > > >
> > > > > This is a good example.
> > > > > We have used this change locally for a long time, so I think it is
> > > > > safe to do this change, a little different with the recommandation.
> > > >
> > > > Any reason for we have to go against the recommendation?
> > >
> > > Previous code will enable TE and RE together even for asynchronous
> > > mode.
> > > And for recommendation, previous code just consider the RX sync with
> > > TX, but still violates the recommendation for TX sync with RX case.
> > > So at least this new change is some kind of improvement.
> >
> > Okay. Let's change it then. Please make sure to update/remove
> > those old comments in the trigger(). And it's probably better
> > to mention that what we do now is a bit different from RM:
> > /*
> > * 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.
> > */
>
> Thank you for the agreement.
>
> >
> > Btw, do we need similar change for TRIGGER_STOP?
>
> This is a good question. It is better to do change for STOP,
> but I am afraid that there is no much test to guarantee the result.
>
> best regards
> wang shengjiu
Maybe we can do this change for STOP.
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 1c0e06bb3783..6e4be398eaee 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -517,6 +517,37 @@ static int fsl_sai_hw_free(struct
snd_pcm_substream *substream,
return 0;
}
+static void fsl_sai_config_disable(struct fsl_sai *sai, bool tx)
+{
+ unsigned int ofs = sai->soc_data->reg_offset;
+ 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 for both Tx and Rx */
+ 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)
@@ -525,7 +556,7 @@ 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;
+ u32 xcsr;
/*
* Asynchronous mode: Clear SYNC for both Tx and Rx.
@@ -579,43 +610,12 @@ 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 (sai->synchronous[tx] && !sai->synchronous[!tx] &&
!(xcsr & FSL_SAI_CSR_FRDE))
+ fsl_sai_config_disable(sai, !tx);
+
+ if (sai->synchronous[tx] || !sai->synchronous[!tx] ||
!(xcsr & FSL_SAI_CSR_FRDE))
+ fsl_sai_config_disable(sai, tx);
+
^ permalink raw reply related
* [powerpc:merge] BUILD SUCCESS a3dcfbc2456df1a2d416b7d0b627d9cededa1432
From: kernel test robot @ 2020-08-04 5:17 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: a3dcfbc2456df1a2d416b7d0b627d9cededa1432 Automatic merge of 'master', 'next' and 'fixes' (2020-08-03 22:40)
elapsed time: 987m
configs tested: 82
configs skipped: 7
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm64 allyesconfig
arm64 defconfig
ia64 generic_defconfig
m68k bvme6000_defconfig
arm pxa168_defconfig
powerpc maple_defconfig
mips malta_qemu_32r6_defconfig
arm64 alldefconfig
arm vt8500_v6_v7_defconfig
arm lart_defconfig
mips omega2p_defconfig
mips loongson1c_defconfig
xtensa alldefconfig
nds32 allnoconfig
powerpc alldefconfig
mips bmips_stb_defconfig
arm magician_defconfig
parisc alldefconfig
mips ip32_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k 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
nios2 defconfig
arc allyesconfig
c6x allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a004-20200803
i386 randconfig-a005-20200803
i386 randconfig-a001-20200803
i386 randconfig-a002-20200803
i386 randconfig-a003-20200803
i386 randconfig-a006-20200803
x86_64 randconfig-a013-20200803
x86_64 randconfig-a011-20200803
x86_64 randconfig-a012-20200803
x86_64 randconfig-a016-20200803
x86_64 randconfig-a015-20200803
x86_64 randconfig-a014-20200803
i386 randconfig-a011-20200803
i386 randconfig-a012-20200803
i386 randconfig-a015-20200803
i386 randconfig-a014-20200803
i386 randconfig-a013-20200803
i386 randconfig-a016-20200803
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 2075ec9896c5aef01e837198381d04cfa6452317
From: kernel test robot @ 2020-08-04 5:17 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: 2075ec9896c5aef01e837198381d04cfa6452317 powerpc/powernv/sriov: Fix use of uninitialised variable
elapsed time: 986m
configs tested: 94
configs skipped: 5
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
ia64 generic_defconfig
m68k bvme6000_defconfig
arm pxa168_defconfig
arm pxa_defconfig
arc hsdk_defconfig
arm hisi_defconfig
arc tb10x_defconfig
arc axs103_defconfig
arm aspeed_g4_defconfig
arc axs101_defconfig
powerpc amigaone_defconfig
sh sh7770_generic_defconfig
mips bcm47xx_defconfig
h8300 h8300h-sim_defconfig
powerpc alldefconfig
mips bmips_stb_defconfig
arm magician_defconfig
sh sh03_defconfig
mips db1xxx_defconfig
arm trizeps4_defconfig
parisc alldefconfig
mips ip32_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 allyesconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a004-20200803
i386 randconfig-a005-20200803
i386 randconfig-a001-20200803
i386 randconfig-a002-20200803
i386 randconfig-a003-20200803
i386 randconfig-a006-20200803
x86_64 randconfig-a013-20200803
x86_64 randconfig-a011-20200803
x86_64 randconfig-a012-20200803
x86_64 randconfig-a016-20200803
x86_64 randconfig-a015-20200803
x86_64 randconfig-a014-20200803
i386 randconfig-a011-20200803
i386 randconfig-a012-20200803
i386 randconfig-a015-20200803
i386 randconfig-a014-20200803
i386 randconfig-a013-20200803
i386 randconfig-a016-20200803
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-test] BUILD SUCCESS dbbd7a68c8d47293bd8d027841b06dd5137e0fcc
From: kernel test robot @ 2020-08-04 5:17 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: dbbd7a68c8d47293bd8d027841b06dd5137e0fcc powerpc: Fix P10 PVR revision in /proc/cpuinfo for SMT4 cores
elapsed time: 986m
configs tested: 99
configs skipped: 6
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
ia64 generic_defconfig
m68k bvme6000_defconfig
arm pxa168_defconfig
powerpc mpc885_ads_defconfig
m68k alldefconfig
mips decstation_64_defconfig
arm neponset_defconfig
arm jornada720_defconfig
sh magicpanelr2_defconfig
arm moxart_defconfig
sh sh7763rdp_defconfig
sh microdev_defconfig
arm magician_defconfig
arm aspeed_g4_defconfig
arc axs101_defconfig
powerpc amigaone_defconfig
sh sh7770_generic_defconfig
mips bcm47xx_defconfig
h8300 h8300h-sim_defconfig
nds32 allnoconfig
powerpc alldefconfig
mips bmips_stb_defconfig
arm pxa_defconfig
sh sh03_defconfig
mips db1xxx_defconfig
arm trizeps4_defconfig
parisc alldefconfig
mips ip32_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
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 allyesconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a004-20200803
i386 randconfig-a005-20200803
i386 randconfig-a001-20200803
i386 randconfig-a002-20200803
i386 randconfig-a003-20200803
i386 randconfig-a006-20200803
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
x86_64 randconfig-a013-20200803
x86_64 randconfig-a011-20200803
x86_64 randconfig-a012-20200803
x86_64 randconfig-a016-20200803
x86_64 randconfig-a015-20200803
x86_64 randconfig-a014-20200803
i386 randconfig-a011-20200803
i386 randconfig-a012-20200803
i386 randconfig-a015-20200803
i386 randconfig-a014-20200803
i386 randconfig-a013-20200803
i386 randconfig-a016-20200803
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: [merge] Build failure selftest/powerpc/mm/pkey_exec_prot
From: Sandipan Das @ 2020-08-04 6:35 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Sachin Sant, linuxppc-dev
In-Reply-To: <87mu3bz083.fsf@mpe.ellerman.id.au>
Hi Michael,
On 04/08/20 6:38 am, Michael Ellerman wrote:
> Sandipan Das <sandipan@linux.ibm.com> writes:
>> On 03/08/20 4:32 pm, Michael Ellerman wrote:
>>> Sachin Sant <sachinp@linux.vnet.ibm.com> writes:
>>>>> On 02-Aug-2020, at 10:58 PM, Sandipan Das <sandipan@linux.ibm.com> wrote:
>>>>> On 02/08/20 4:45 pm, Sachin Sant wrote:
>>>>>> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
>>>>>> build due to following error:
>>>>>>
>>>>>> gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1276-g3f68564f1f5a"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 pkey_exec_prot.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot
>>>>>> In file included from pkey_exec_prot.c:18:
>>>>>> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
>>>>>> #define SYS_pkey_mprotect 386
>>>>>>
>>>>>> In file included from /usr/include/sys/syscall.h:31,
>>>>>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
>>>>>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
>>>>>> from pkey_exec_prot.c:18:
>>>>>> /usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
>>>>>> # define SYS_pkey_mprotect __NR_pkey_mprotect
>>>>>>
>>>>>> commit 128d3d021007 introduced this error.
>>>>>> selftests/powerpc: Move pkey helpers to headers
>>>>>>
>>>>>> Possibly the # defines for sys calls can be retained in pkey_exec_prot.c or
>>>>>>
>>>>>
>>>>> I am unable to reproduce this on the latest merge branch (HEAD at f59195f7faa4).
>>>>> I don't see any redefinitions in pkey_exec_prot.c either.
>>>>>
>>>>
>>>> I can still see this problem on latest merge branch.
>>>> I have following gcc version
>>>>
>>>> gcc version 8.3.1 20191121
>>>
>>> What libc version? Or just the distro & version?
>>
>> Sachin observed this on RHEL 8.2 with glibc-2.28.
>> I couldn't reproduce it on Ubuntu 20.04 and Fedora 32 and both these distros
>> are using glibc-2.31.
>
> OK odd. Usually it's newer glibc that hits this problem.
>
> I guess on RHEL 8.2 we're getting the asm-generic version? But that
> would be quite wrong if that's what's happening.
>
If I let GCC dump all the headers that are being used for the source file, I always
see syscall.h being included on the RHEL 8.2 system. That is the header with the
conflicting definition.
$ cd tools/testing/selftests/powerpc/mm
$ gcc -H -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1456-gf59195f7faa4-dirty"' \
-I../include -m64 pkey_exec_prot.c ../../kselftest_harness.h ../../kselftest.h ../harness.c ../utils.c \
-o pkey_exec_prot 2>&1 | grep syscall
On Ubuntu 20.04 and Fedora 32, grep doesn't find any matching text.
On RHEL 8.2, it shows the following.
... /usr/include/sys/syscall.h
.... /usr/include/bits/syscall.h
In file included from /usr/include/sys/syscall.h:31,
/usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
In file included from /usr/include/sys/syscall.h:31,
/usr/include/bits/syscall.h:1575: note: this is the location of the previous definition
In file included from /usr/include/sys/syscall.h:31,
/usr/include/bits/syscall.h:1579: note: this is the location of the previous definition
/usr/include/bits/syscall.h
.. /usr/include/sys/syscall.h
... /usr/include/bits/syscall.h
/usr/include/bits/syscall.h
.. /usr/include/sys/syscall.h
... /usr/include/bits/syscall.h
/usr/include/bits/syscall.h
So utils.h is also including /usr/include/sys/syscall.h for glibc versions older than 2.30
because of commit 743f3544fffb ("selftests/powerpc: Add wrapper for gettid") :)
[...]
. ../include/pkeys.h
[...]
.. ../include/utils.h
[...]
... /usr/include/sys/syscall.h
.... /usr/include/asm/unistd.h
.... /usr/include/bits/syscall.h
In file included from pkey_exec_prot.c:18:
../include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
#define SYS_pkey_mprotect 386
In file included from /usr/include/sys/syscall.h:31,
from ../include/utils.h:47,
from ../include/pkeys.h:12,
from pkey_exec_prot.c:18:
/usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
# define SYS_pkey_mprotect __NR_pkey_mprotect
[...]
- Sandipan
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/powernv/smp: Fix spurious DBG() warning
From: Oliver O'Halloran @ 2020-08-04 6:58 UTC (permalink / raw)
To: Joel Stanley; +Cc: linuxppc-dev
In-Reply-To: <CACPK8XfoZ8+SUG6cuWuEJqdTfmxePsBGFGgqyrPvmn1WyRVyjA@mail.gmail.com>
On Tue, Aug 4, 2020 at 12:07 PM Joel Stanley <joel@jms.id.au> wrote:
>
> Messy:
>
> $ git grep "define DBG(" arch/powerpc/ |grep -v print
> arch/powerpc/kernel/crash_dump.c:#define DBG(fmt...)
> arch/powerpc/kernel/iommu.c:#define DBG(...)
> arch/powerpc/kernel/legacy_serial.c:#define DBG(fmt...) do { } while(0)
> arch/powerpc/kernel/prom.c:#define DBG(fmt...)
> arch/powerpc/kernel/setup-common.c:#define DBG(fmt...)
> arch/powerpc/kernel/setup_32.c:#define DBG(fmt...)
> arch/powerpc/kernel/smp.c:#define DBG(fmt...)
> arch/powerpc/kernel/vdso.c:#define DBG(fmt...)
> arch/powerpc/kvm/book3s_hv_rm_xive.c:#define DBG(fmt...) do { } while(0)
> arch/powerpc/mm/book3s64/hash_utils.c:#define DBG(fmt...)
> arch/powerpc/platforms/83xx/mpc832x_mds.c:#define DBG(fmt...)
> arch/powerpc/platforms/83xx/mpc832x_rdb.c:#define DBG(fmt...)
> arch/powerpc/platforms/83xx/mpc836x_mds.c:#define DBG(fmt...)
> arch/powerpc/platforms/85xx/mpc85xx_ds.c:#define DBG(fmt, args...)
> arch/powerpc/platforms/85xx/mpc85xx_mds.c:#define DBG(fmt...)
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c:#define DBG(fmt, args...)
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c:#define DBG(fmt...) do { } while(0)
> arch/powerpc/platforms/cell/setup.c:#define DBG(fmt...)
> arch/powerpc/platforms/cell/smp.c:#define DBG(fmt...)
> arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c:#define DBG(fmt...)
> do { } while(0)
> arch/powerpc/platforms/maple/pci.c:#define DBG(x...)
> arch/powerpc/platforms/maple/setup.c:#define DBG(fmt...)
> arch/powerpc/platforms/maple/time.c:#define DBG(x...)
> arch/powerpc/platforms/powermac/bootx_init.c:#define DBG(fmt...) do { } while(0)
> arch/powerpc/platforms/powermac/feature.c:#define DBG(fmt...)
> arch/powerpc/platforms/powermac/low_i2c.c:#define DBG(x...) do {\
> arch/powerpc/platforms/powermac/low_i2c.c:#define DBG(x...)
> arch/powerpc/platforms/powermac/nvram.c:#define DBG(x...)
> arch/powerpc/platforms/powermac/pci.c:#define DBG(x...)
> arch/powerpc/platforms/powermac/pfunc_base.c:#define DBG(fmt...)
> arch/powerpc/platforms/powermac/pfunc_core.c:#define DBG(fmt...)
> arch/powerpc/platforms/powermac/smp.c:#define DBG(fmt...)
> arch/powerpc/platforms/powermac/time.c:#define DBG(x...)
> arch/powerpc/platforms/powernv/smp.c:#define DBG(fmt...)
> arch/powerpc/sysdev/dart_iommu.c:#define DBG(...)
> arch/powerpc/sysdev/ge/ge_pic.c:#define DBG(fmt...) do { } while (0)
> arch/powerpc/sysdev/mpic.c:#define DBG(fmt...)
> arch/powerpc/sysdev/tsi108_dev.c:#define DBG(fmt...) do { } while(0)
> arch/powerpc/sysdev/tsi108_pci.c:#define DBG(x...)
I started off writing a patch that fixed all these too. When I went to
test it I discovered there's a giant pile of other W=1 warnings from
other parts of arch/powerpc/ so I figured I'd start with something
less ambitious.
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Nicolin Chen @ 2020-08-04 7:03 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+D8AP=27SdR68T-LiQHkJ0_dJaqtgcS-oi9d8arUzvTz5GwA@mail.gmail.com>
On Tue, Aug 04, 2020 at 12:22:53PM +0800, Shengjiu Wang wrote:
> > > Btw, do we need similar change for TRIGGER_STOP?
> >
> > This is a good question. It is better to do change for STOP,
> > but I am afraid that there is no much test to guarantee the result.
> Maybe we can do this change for STOP.
The idea looks good to me...(check inline comments)
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index 1c0e06bb3783..6e4be398eaee 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -517,6 +517,37 @@ static int fsl_sai_hw_free(struct
> snd_pcm_substream *substream,
> return 0;
> }
>
> +static void fsl_sai_config_disable(struct fsl_sai *sai, bool tx)
> +{
> + unsigned int ofs = sai->soc_data->reg_offset;
> + 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 for both Tx and Rx */
Remove "for both Tx and Rx"
> /* Check if the opposite FRDE is also disabled */
> regmap_read(sai->regmap, FSL_SAI_xCSR(!tx, ofs), &xcsr);
> + if (sai->synchronous[tx] && !sai->synchronous[!tx] && !(xcsr & FSL_SAI_CSR_FRDE))
> + fsl_sai_config_disable(sai, !tx);
> + if (sai->synchronous[tx] || !sai->synchronous[!tx] || !(xcsr & FSL_SAI_CSR_FRDE))
> + fsl_sai_config_disable(sai, tx);
The first "||" should probably be "&&".
The trigger() logic is way more complicated than a simple cleanup
in my opinion. Would suggest to split RMR part out of this change.
And for conditions like "sync[tx] && !sync[!tx]", it'd be better
to have a helper function to improve readability:
/**
* 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
* current stream's are synced by the opposite stream.
*
* @sai: SAI context
* @dir: direction of current stream
*/
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];
}
Then add more comments in trigger:
static ...trigger()
{
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
int adir = tx ? RX : TX;
int dir = tx ? TX : RX;
// ....
{
// ...
/* Check if the opposite FRDE is also disabled */
regmap_read(sai->regmap, FSL_SAI_xCSR(!tx, ofs), &xcsr);
/*
* 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(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(dir) || !(xcsr & FSL_SAI_CSR_FRDE))
fsl_sai_config_disable(sai, dir);
// ...
}
// ....
}
Note, in fsl_sai_config_disable(sai, dir):
bool tx = dir == TX;
Above all, I am just drafting, so please test it thoroughly :)
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Nicolin Chen @ 2020-08-04 7:08 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: <20200804070345.GA27658@Asurada-Nvidia>
On Tue, Aug 04, 2020 at 12:03:46AM -0700, Nicolin Chen wrote:
> On Tue, Aug 04, 2020 at 12:22:53PM +0800, Shengjiu Wang wrote:
>
> > > > Btw, do we need similar change for TRIGGER_STOP?
> > >
> > > This is a good question. It is better to do change for STOP,
> > > but I am afraid that there is no much test to guarantee the result.
>
> > Maybe we can do this change for STOP.
>
> The idea looks good to me...(check inline comments)
>
> > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> > index 1c0e06bb3783..6e4be398eaee 100644
> > --- a/sound/soc/fsl/fsl_sai.c
> > +++ b/sound/soc/fsl/fsl_sai.c
> > @@ -517,6 +517,37 @@ static int fsl_sai_hw_free(struct
> > snd_pcm_substream *substream,
> > return 0;
> > }
> >
> > +static void fsl_sai_config_disable(struct fsl_sai *sai, bool tx)
> > +{
> > + unsigned int ofs = sai->soc_data->reg_offset;
> > + 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 for both Tx and Rx */
>
> Remove "for both Tx and Rx"
>
> > /* Check if the opposite FRDE is also disabled */
> > regmap_read(sai->regmap, FSL_SAI_xCSR(!tx, ofs), &xcsr);
> > + if (sai->synchronous[tx] && !sai->synchronous[!tx] && !(xcsr & FSL_SAI_CSR_FRDE))
> > + fsl_sai_config_disable(sai, !tx);
>
> > + if (sai->synchronous[tx] || !sai->synchronous[!tx] || !(xcsr & FSL_SAI_CSR_FRDE))
> > + fsl_sai_config_disable(sai, tx);
>
> The first "||" should probably be "&&".
>
> The trigger() logic is way more complicated than a simple cleanup
> in my opinion. Would suggest to split RMR part out of this change.
>
> And for conditions like "sync[tx] && !sync[!tx]", it'd be better
> to have a helper function to improve readability:
>
> /**
> * 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
> * current stream's are synced by the opposite stream.
Aww..this should be a generic function, so drop "current":
* 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: direction of current stream
Ditto:
* @dir: stream direction
Thanks.
-----
> */
> 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];
> }
>
> Then add more comments in trigger:
>
> static ...trigger()
> {
> bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> int adir = tx ? RX : TX;
> int dir = tx ? TX : RX;
>
> // ....
> {
> // ...
>
> /* Check if the opposite FRDE is also disabled */
> regmap_read(sai->regmap, FSL_SAI_xCSR(!tx, ofs), &xcsr);
>
> /*
> * 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(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(dir) || !(xcsr & FSL_SAI_CSR_FRDE))
> fsl_sai_config_disable(sai, dir);
>
> // ...
> }
> // ....
> }
>
> Note, in fsl_sai_config_disable(sai, dir):
> bool tx = dir == TX;
>
> Above all, I am just drafting, so please test it thoroughly :)
^ permalink raw reply
* Re: [RFC PATCH 1/2] powerpc/numa: Introduce logical numa id
From: Srikar Dronamraju @ 2020-08-04 7:25 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Nathan Lynch, linuxppc-dev
In-Reply-To: <87h7tl162y.fsf@linux.ibm.com>
* Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> [2020-08-02 19:51:41]:
> Srikar Dronamraju <srikar@linux.vnet.ibm.com> writes:
> > * Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> [2020-07-31 16:49:14]:
> >
> >
> > If its just to eliminate node 0, then we have 2 other probably better
> > solutions.
> > 1. Dont mark node 0 as spl (currently still in mm-tree and a result in
> > linux-next)
> > 2. powerpc specific: explicitly clear node 0 during numa bringup.
> >
>
>
> I am not sure I consider them better. But yes, those patches are good
> and also resolves the node 0 initialization when the firmware didn't
> indicate the presence of such a node.
>
> This patch in addition make sure that we get the same topolgy report
> across reboot on a virtualized partitions as longs as the cpu/memory
> ratio per powervm domains remain the same. This should also help to
> avoid confusion after an LPM migration once we start applying topology
> updates.
>
What do we mean by cpu/memory ratio. The topology across reboot would have
changed only if PowerVM would have allocated resources differently by
scrambling/unscrambling. We are no more processing topology updates at
runtime. As far as I know, after LPM, the source topology is maintained.
> >> This can be resolved by mapping the firmware provided group id to a logical Linux
> >> NUMA id. In this patch, we do this only for pseries platforms considering the
> >
> > On PowerVM, as you would know the nid is already a logical or a flattened
> > chip-id and not the actual hardware chip-id.
>
> Yes. But then they are derived based on PowerVM resources AKA domains.
> Now based on the available resource on a system, we could end up with
> different node numbers with same toplogy across reboots. Making it
> logical at OS level prevent that.
The above statement kind of gives an impression, that topology changes
across every reboot. We only end up with different node numbers if and only
if the underlying topology has changed and that case is very rare. Or am I
missing something?
>
> >> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> >> index e437a9ac4956..6c659aada55b 100644
> >> --- a/arch/powerpc/mm/numa.c
> >> +++ b/arch/powerpc/mm/numa.c
> >> @@ -221,25 +221,51 @@ static void initialize_distance_lookup_table(int nid,
> >> }
> >> }
> >>
> >> +static u32 nid_map[MAX_NUMNODES] = {[0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE};
> >> +
> >> +int firmware_group_id_to_nid(int firmware_gid)
> >> +{
> >> + static int last_nid = 0;
> >> +
> >> + /*
> >> + * For PowerNV we don't change the node id. This helps to avoid
> >> + * confusion w.r.t the expected node ids. On pseries, node numbers
> >> + * are virtualized. Hence do logical node id for pseries.
> >> + */
> >> + if (!firmware_has_feature(FW_FEATURE_LPAR))
> >> + return firmware_gid;
> >> +
> >> + if (firmware_gid == -1)
> >> + return NUMA_NO_NODE;
> >> +
> >> + if (nid_map[firmware_gid] == NUMA_NO_NODE)
> >> + nid_map[firmware_gid] = last_nid++;
> >
> > How do we ensure 2 simultaneous firmware_group_id_to_nid() calls dont end up
> > at this place in parallel?
>
> Do we have a code path where we do that? All the node id init should
> happen early and there should not be two cpus doing node init at the
> same time. I might be mistaken. Can you point to the code path where you
> expect this to be called in parallel?
>
associativity_to_nid gets called the first time a cpu is being made present
from offline. So it need not be in boot path. We may to verify if cpu
hotplug, dlpar, operations are synchronized. For example a memory hotadd and
cpu hotplug are they synchronized? I am not sure if they are synchronized at
this time.
> >
> >> +
> >> + return nid_map[firmware_gid];
> >> +}
> >> +
> >> /* Returns nid in the range [0..MAX_NUMNODES-1], or -1 if no useful numa
> >> * info is found.
> >> */
> >> static int associativity_to_nid(const __be32 *associativity)
> >> {
> >> int nid = NUMA_NO_NODE;
> >> + int firmware_gid = -1;
> >>
> >> if (!numa_enabled)
> >> goto out;
> >>
> >> if (of_read_number(associativity, 1) >= min_common_depth)
> >> - nid = of_read_number(&associativity[min_common_depth], 1);
> >> + firmware_gid = of_read_number(&associativity[min_common_depth], 1);
> >>
> >> /* POWER4 LPAR uses 0xffff as invalid node */
> >> - if (nid == 0xffff || nid >= MAX_NUMNODES)
> >> - nid = NUMA_NO_NODE;
> >> + if (firmware_gid == 0xffff || firmware_gid >= MAX_NUMNODES)
> >> + firmware_gid = -1;
> >
> > Lets assume two or more invocations of associativity_to_nid for the same
> > associativity, end up with -1, In each case aren't giving different
> > nids?
>
>
> I didn't quiet get the comment here. But I assume you are indicating the
> same one you mentioned above?
>
No its not related to the above comment.
We are incrementing the nid_map table for every unique firmware_gid or for
every -1 (aka invalid associativities). If there are sufficiently large
number of associativities that end up returning invalid associativities,
then don't we quickly overflow the nid_map table? Not only about the
overflow but a 8 node machine may soon look like a 80 node machine.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v2] powerpc: Warn about use of smt_snooze_delay
From: Gautham R Shenoy @ 2020-08-04 7:37 UTC (permalink / raw)
To: Joel Stanley; +Cc: Tyrel Datwyler, linuxppc-dev, Gautham R Shenoy
In-Reply-To: <20200630015935.2675676-1-joel@jms.id.au>
Hi Joel,
On Tue, Jun 30, 2020 at 11:29:35AM +0930, Joel Stanley wrote:
> It's not done anything for a long time. Save the percpu variable, and
> emit a warning to remind users to not expect it to do anything.
>
> Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay cleanup.")
> Cc: stable@vger.kernel.org # v3.14
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Sorry I missed this v2.
The patch looks good to me.
Acked-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> --
> v2:
> Use pr_warn instead of WARN
> Reword and print proccess name with pid in message
> Leave CPU_FTR_SMT test in
> Add Fixes line
>
> mpe, if you don't agree then feel free to drop the cc stable.
>
> Testing 'ppc64_cpu --smt=off' on a 24 core / 4 SMT system it's quite noisy
> as the online/offline loop that ppc64_cpu runs is slow.
>
> This could be fixed by open coding pr_warn_ratelimit with the ratelimit
> parameters tweaked if someone was concerned. I'll leave that to someone
> else as a future enhancement.
>
> [ 237.642088][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 237.642175][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 237.642261][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 237.642345][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 237.642430][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 237.642516][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 237.642625][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 237.642709][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 237.642793][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 237.642878][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264030][ T1197] store_smt_snooze_delay: 14 callbacks suppressed
> [ 254.264033][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264048][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264062][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264075][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264089][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264103][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264116][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264130][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264143][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
> [ 254.264157][ T1197] ppc64_cpu (1197) used unsupported smt_snooze_delay, this has no effect
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/powerpc/kernel/sysfs.c | 41 +++++++++++++++----------------------
> 1 file changed, 16 insertions(+), 25 deletions(-)
>
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index 571b3259697e..ba6d4cee19ef 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -32,29 +32,26 @@
>
> static DEFINE_PER_CPU(struct cpu, cpu_devices);
>
> -/*
> - * SMT snooze delay stuff, 64-bit only for now
> - */
> -
> #ifdef CONFIG_PPC64
>
> -/* Time in microseconds we delay before sleeping in the idle loop */
> -static DEFINE_PER_CPU(long, smt_snooze_delay) = { 100 };
> +/*
> + * Snooze delay has not been hooked up since 3fa8cad82b94 ("powerpc/pseries/cpuidle:
> + * smt-snooze-delay cleanup.") and has been broken even longer. As was foretold in
> + * 2014:
> + *
> + * "ppc64_util currently utilises it. Once we fix ppc64_util, propose to clean
> + * up the kernel code."
> + *
> + * At some point in the future this code should be removed.
> + */
>
> static ssize_t store_smt_snooze_delay(struct device *dev,
> struct device_attribute *attr,
> const char *buf,
> size_t count)
> {
> - struct cpu *cpu = container_of(dev, struct cpu, dev);
> - ssize_t ret;
> - long snooze;
> -
> - ret = sscanf(buf, "%ld", &snooze);
> - if (ret != 1)
> - return -EINVAL;
> -
> - per_cpu(smt_snooze_delay, cpu->dev.id) = snooze;
> + pr_warn_ratelimited("%s (%d) used unsupported smt_snooze_delay, this has no effect\n",
> + current->comm, current->pid);
> return count;
> }
>
> @@ -62,9 +59,9 @@ static ssize_t show_smt_snooze_delay(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> {
> - struct cpu *cpu = container_of(dev, struct cpu, dev);
> -
> - return sprintf(buf, "%ld\n", per_cpu(smt_snooze_delay, cpu->dev.id));
> + pr_warn_ratelimited("%s (%d) used unsupported smt_snooze_delay, this has no effect\n",
> + current->comm, current->pid);
> + return sprintf(buf, "100\n");
> }
>
> static DEVICE_ATTR(smt_snooze_delay, 0644, show_smt_snooze_delay,
> @@ -72,16 +69,10 @@ static DEVICE_ATTR(smt_snooze_delay, 0644, show_smt_snooze_delay,
>
> static int __init setup_smt_snooze_delay(char *str)
> {
> - unsigned int cpu;
> - long snooze;
> -
> if (!cpu_has_feature(CPU_FTR_SMT))
> return 1;
>
> - snooze = simple_strtol(str, NULL, 10);
> - for_each_possible_cpu(cpu)
> - per_cpu(smt_snooze_delay, cpu) = snooze;
> -
> + pr_warn("smt-snooze-delay command line option has no effect\n");
> return 1;
> }
> __setup("smt-snooze-delay=", setup_smt_snooze_delay);
> --
> 2.27.0
>
^ permalink raw reply
* Re: [RFC PATCH 2/2] powerpc/powernv/cpufreq: Don't assume chip id is same as Linux node id
From: Gautham R Shenoy @ 2020-08-04 7:47 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Nathan Lynch, linuxppc-dev, Srikar Dronamraju
In-Reply-To: <20200731112205.245716-1-aneesh.kumar@linux.ibm.com>
On Fri, Jul 31, 2020 at 04:52:05PM +0530, Aneesh Kumar K.V wrote:
> On PowerNV platforms we always have 1:1 mapping between chip ID and
> firmware group id. Use the helper to convert firmware group id to
> node id instead of directly using chip ID as Linux node id.
>
> NOTE: This doesn't have any functional change. On PowerNV platforms
> we continue to have 1:1 mapping between firmware group id and
> Linux node id.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> drivers/cpufreq/powernv-cpufreq.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> index 8646eb197cd9..ca82b6ac0989 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -27,6 +27,7 @@
> #include <asm/reg.h>
> #include <asm/smp.h> /* Required for cpu_sibling_mask() in UP configs */
> #include <asm/opal.h>
> +#include <asm/topology.h>
> #include <linux/timer.h>
>
> #define POWERNV_MAX_PSTATES_ORDER 8
> @@ -1069,8 +1070,14 @@ static int init_chip_info(void)
> }
>
> for (i = 0; i < nr_chips; i++) {
> + unsigned int nid;
> +
> chips[i].id = chip[i];
> - cpumask_copy(&chips[i].mask, cpumask_of_node(chip[i]));
> + /*
> + * On powervn platforms firmware group id is same as chipd id.
But doesn't hurt to be safe :-)
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> + */
> + nid = firmware_group_id_to_nid(chip[i]);
> + cpumask_copy(&chips[i].mask, cpumask_of_node(nid));
> INIT_WORK(&chips[i].throttle, powernv_cpufreq_work_fn);
> for_each_cpu(cpu, &chips[i].mask)
> per_cpu(chip_info, cpu) = &chips[i];
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Shengjiu Wang @ 2020-08-04 7:53 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: <20200804070345.GA27658@Asurada-Nvidia>
On Tue, Aug 4, 2020 at 3:04 PM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Tue, Aug 04, 2020 at 12:22:53PM +0800, Shengjiu Wang wrote:
>
> > > > Btw, do we need similar change for TRIGGER_STOP?
> > >
> > > This is a good question. It is better to do change for STOP,
> > > but I am afraid that there is no much test to guarantee the result.
>
> > Maybe we can do this change for STOP.
>
> The idea looks good to me...(check inline comments)
>
> > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> > index 1c0e06bb3783..6e4be398eaee 100644
> > --- a/sound/soc/fsl/fsl_sai.c
> > +++ b/sound/soc/fsl/fsl_sai.c
> > @@ -517,6 +517,37 @@ static int fsl_sai_hw_free(struct
> > snd_pcm_substream *substream,
> > return 0;
> > }
> >
> > +static void fsl_sai_config_disable(struct fsl_sai *sai, bool tx)
> > +{
> > + unsigned int ofs = sai->soc_data->reg_offset;
> > + 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 for both Tx and Rx */
>
> Remove "for both Tx and Rx"
>
> > /* Check if the opposite FRDE is also disabled */
> > regmap_read(sai->regmap, FSL_SAI_xCSR(!tx, ofs), &xcsr);
> > + if (sai->synchronous[tx] && !sai->synchronous[!tx] && !(xcsr & FSL_SAI_CSR_FRDE))
> > + fsl_sai_config_disable(sai, !tx);
>
> > + if (sai->synchronous[tx] || !sai->synchronous[!tx] || !(xcsr & FSL_SAI_CSR_FRDE))
> > + fsl_sai_config_disable(sai, tx);
>
> The first "||" should probably be "&&".
No. it is !(!sai->synchronous[tx] && sai->synchronous[!tx] && (xcsr &
FSL_SAI_CSR_FRDE))
so then convert to
(sai->synchronous[tx] || !sai->synchronous[!tx] || !(xcsr & FSL_SAI_CSR_FRDE))
if change to &&, then it won't work for:
sai->synchronous[tx] = false, sai->synchronous[!tx]=false.
or
sai->synchronous[tx] = true, sai->synchronous[!tx]=true.
(even we don't have such a case).
>
> The trigger() logic is way more complicated than a simple cleanup
> in my opinion. Would suggest to split RMR part out of this change.
>
> And for conditions like "sync[tx] && !sync[!tx]", it'd be better
> to have a helper function to improve readability:
>
> /**
> * 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
> * current stream's are synced by the opposite stream.
> *
> * @sai: SAI context
> * @dir: direction of current stream
> */
> 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];
> }
>
> Then add more comments in trigger:
>
> static ...trigger()
> {
> bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> int adir = tx ? RX : TX;
> int dir = tx ? TX : RX;
>
> // ....
> {
> // ...
>
> /* Check if the opposite FRDE is also disabled */
> regmap_read(sai->regmap, FSL_SAI_xCSR(!tx, ofs), &xcsr);
>
> /*
> * 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(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(dir) || !(xcsr & FSL_SAI_CSR_FRDE))
> fsl_sai_config_disable(sai, dir);
>
> // ...
> }
> // ....
> }
>
> Note, in fsl_sai_config_disable(sai, dir):
> bool tx = dir == TX;
>
> Above all, I am just drafting, so please test it thoroughly :)
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Nicolin Chen @ 2020-08-04 8:13 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+D8ANodghXDbUVOqpf9uq8A5FVbDFEFkf4dWdyMUNDTPaJ7A@mail.gmail.com>
On Tue, Aug 04, 2020 at 03:53:51PM +0800, Shengjiu Wang wrote:
> > > /* Check if the opposite FRDE is also disabled */
> > > regmap_read(sai->regmap, FSL_SAI_xCSR(!tx, ofs), &xcsr);
> > > + if (sai->synchronous[tx] && !sai->synchronous[!tx] && !(xcsr & FSL_SAI_CSR_FRDE))
> > > + fsl_sai_config_disable(sai, !tx);
> >
> > > + if (sai->synchronous[tx] || !sai->synchronous[!tx] || !(xcsr & FSL_SAI_CSR_FRDE))
> > > + fsl_sai_config_disable(sai, tx);
> >
> > The first "||" should probably be "&&".
>
> No. it is !(!sai->synchronous[tx] && sai->synchronous[!tx] && (xcsr &
> FSL_SAI_CSR_FRDE))
> so then convert to
> (sai->synchronous[tx] || !sai->synchronous[!tx] || !(xcsr & FSL_SAI_CSR_FRDE))
>
> if change to &&, then it won't work for:
> sai->synchronous[tx] = false, sai->synchronous[!tx]=false.
Ahh..probably should be
if (!(sync[dir] && !sync[adir]) || !frde)
I have a (seemingly) correct version in my sample code.
And...please untangle the logic using the given example -- adding
helper function(s) and comments. And, though the driver does have
places using array[tx] and array[!tx], better not to use any more
boolean type variable as an array index, as it's hard to read.
^ permalink raw reply
* Re: [PATCH 2/2] lockdep: warn on redundant or incorrect irq state changes
From: Alexey Kardashevskiy @ 2020-08-04 10:00 UTC (permalink / raw)
To: Nicholas Piggin, linux-kernel
Cc: linux-arch, Peter Zijlstra, Ingo Molnar, linuxppc-dev,
Will Deacon
In-Reply-To: <20200723105615.1268126-2-npiggin@gmail.com>
On 23/07/2020 20:56, Nicholas Piggin wrote:
> With the previous patch, lockdep hardirq state changes should not be
> redundant. Softirq state changes already follow that pattern.
>
> So warn on unexpected enable-when-enabled or disable-when-disabled
> conditions, to catch possible errors or sloppy patterns that could
> lead to similar bad behavior due to NMIs etc.
This one does not apply anymore as Peter's changes went in already but
this one is not really a fix so I can live with that. Did 1/2 go
anywhere? Thanks,
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> kernel/locking/lockdep.c | 80 +++++++++++++-----------------
> kernel/locking/lockdep_internals.h | 4 --
> kernel/locking/lockdep_proc.c | 10 +---
> 3 files changed, 35 insertions(+), 59 deletions(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 29a8de4c50b9..138458fb2234 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -3649,15 +3649,8 @@ void lockdep_hardirqs_on_prepare(unsigned long ip)
> if (unlikely(!debug_locks || current->lockdep_recursion))
> return;
>
> - if (unlikely(current->hardirqs_enabled)) {
> - /*
> - * Neither irq nor preemption are disabled here
> - * so this is racy by nature but losing one hit
> - * in a stat is not a big deal.
> - */
> - __debug_atomic_inc(redundant_hardirqs_on);
> + if (DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled))
> return;
> - }
>
> /*
> * We're enabling irqs and according to our state above irqs weren't
> @@ -3695,15 +3688,8 @@ void noinstr lockdep_hardirqs_on(unsigned long ip)
> if (unlikely(!debug_locks || curr->lockdep_recursion))
> return;
>
> - if (curr->hardirqs_enabled) {
> - /*
> - * Neither irq nor preemption are disabled here
> - * so this is racy by nature but losing one hit
> - * in a stat is not a big deal.
> - */
> - __debug_atomic_inc(redundant_hardirqs_on);
> + if (DEBUG_LOCKS_WARN_ON(curr->hardirqs_enabled))
> return;
> - }
>
> /*
> * We're enabling irqs and according to our state above irqs weren't
> @@ -3738,6 +3724,9 @@ void noinstr lockdep_hardirqs_off(unsigned long ip)
> if (unlikely(!debug_locks || curr->lockdep_recursion))
> return;
>
> + if (DEBUG_LOCKS_WARN_ON(!curr->hardirqs_enabled))
> + return;
> +
> /*
> * So we're supposed to get called after you mask local IRQs, but for
> * some reason the hardware doesn't quite think you did a proper job.
> @@ -3745,17 +3734,13 @@ void noinstr lockdep_hardirqs_off(unsigned long ip)
> if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> return;
>
> - if (curr->hardirqs_enabled) {
> - /*
> - * We have done an ON -> OFF transition:
> - */
> - curr->hardirqs_enabled = 0;
> - curr->hardirq_disable_ip = ip;
> - curr->hardirq_disable_event = ++curr->irq_events;
> - debug_atomic_inc(hardirqs_off_events);
> - } else {
> - debug_atomic_inc(redundant_hardirqs_off);
> - }
> + /*
> + * We have done an ON -> OFF transition:
> + */
> + curr->hardirqs_enabled = 0;
> + curr->hardirq_disable_ip = ip;
> + curr->hardirq_disable_event = ++curr->irq_events;
> + debug_atomic_inc(hardirqs_off_events);
> }
> EXPORT_SYMBOL_GPL(lockdep_hardirqs_off);
>
> @@ -3769,6 +3754,9 @@ void lockdep_softirqs_on(unsigned long ip)
> if (unlikely(!debug_locks || current->lockdep_recursion))
> return;
>
> + if (DEBUG_LOCKS_WARN_ON(curr->softirqs_enabled))
> + return;
> +
> /*
> * We fancy IRQs being disabled here, see softirq.c, avoids
> * funny state and nesting things.
> @@ -3776,11 +3764,6 @@ void lockdep_softirqs_on(unsigned long ip)
> if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> return;
>
> - if (curr->softirqs_enabled) {
> - debug_atomic_inc(redundant_softirqs_on);
> - return;
> - }
> -
> current->lockdep_recursion++;
> /*
> * We'll do an OFF -> ON transition:
> @@ -3809,26 +3792,26 @@ void lockdep_softirqs_off(unsigned long ip)
> if (unlikely(!debug_locks || current->lockdep_recursion))
> return;
>
> + if (DEBUG_LOCKS_WARN_ON(!curr->softirqs_enabled))
> + return;
> +
> /*
> * We fancy IRQs being disabled here, see softirq.c
> */
> if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> return;
>
> - if (curr->softirqs_enabled) {
> - /*
> - * We have done an ON -> OFF transition:
> - */
> - curr->softirqs_enabled = 0;
> - curr->softirq_disable_ip = ip;
> - curr->softirq_disable_event = ++curr->irq_events;
> - debug_atomic_inc(softirqs_off_events);
> - /*
> - * Whoops, we wanted softirqs off, so why aren't they?
> - */
> - DEBUG_LOCKS_WARN_ON(!softirq_count());
> - } else
> - debug_atomic_inc(redundant_softirqs_off);
> + /*
> + * We have done an ON -> OFF transition:
> + */
> + curr->softirqs_enabled = 0;
> + curr->softirq_disable_ip = ip;
> + curr->softirq_disable_event = ++curr->irq_events;
> + debug_atomic_inc(softirqs_off_events);
> + /*
> + * Whoops, we wanted softirqs off, so why aren't they?
> + */
> + DEBUG_LOCKS_WARN_ON(!softirq_count());
> }
>
> static int
> @@ -5684,6 +5667,11 @@ void __init lockdep_init(void)
>
> printk(" per task-struct memory footprint: %zu bytes\n",
> sizeof(((struct task_struct *)NULL)->held_locks));
> +
> + WARN_ON(irqs_disabled());
> +
> + current->hardirqs_enabled = 1;
> + current->softirqs_enabled = 1;
> }
>
> static void
> diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
> index baca699b94e9..6dd8b1f06dc4 100644
> --- a/kernel/locking/lockdep_internals.h
> +++ b/kernel/locking/lockdep_internals.h
> @@ -180,12 +180,8 @@ struct lockdep_stats {
> unsigned int chain_lookup_misses;
> unsigned long hardirqs_on_events;
> unsigned long hardirqs_off_events;
> - unsigned long redundant_hardirqs_on;
> - unsigned long redundant_hardirqs_off;
> unsigned long softirqs_on_events;
> unsigned long softirqs_off_events;
> - unsigned long redundant_softirqs_on;
> - unsigned long redundant_softirqs_off;
> int nr_unused_locks;
> unsigned int nr_redundant_checks;
> unsigned int nr_redundant;
> diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c
> index 5525cd3ba0c8..98f204220ed9 100644
> --- a/kernel/locking/lockdep_proc.c
> +++ b/kernel/locking/lockdep_proc.c
> @@ -172,12 +172,8 @@ static void lockdep_stats_debug_show(struct seq_file *m)
> #ifdef CONFIG_DEBUG_LOCKDEP
> unsigned long long hi1 = debug_atomic_read(hardirqs_on_events),
> hi2 = debug_atomic_read(hardirqs_off_events),
> - hr1 = debug_atomic_read(redundant_hardirqs_on),
> - hr2 = debug_atomic_read(redundant_hardirqs_off),
> si1 = debug_atomic_read(softirqs_on_events),
> - si2 = debug_atomic_read(softirqs_off_events),
> - sr1 = debug_atomic_read(redundant_softirqs_on),
> - sr2 = debug_atomic_read(redundant_softirqs_off);
> + si2 = debug_atomic_read(softirqs_off_events);
>
> seq_printf(m, " chain lookup misses: %11llu\n",
> debug_atomic_read(chain_lookup_misses));
> @@ -196,12 +192,8 @@ static void lockdep_stats_debug_show(struct seq_file *m)
>
> seq_printf(m, " hardirq on events: %11llu\n", hi1);
> seq_printf(m, " hardirq off events: %11llu\n", hi2);
> - seq_printf(m, " redundant hardirq ons: %11llu\n", hr1);
> - seq_printf(m, " redundant hardirq offs: %11llu\n", hr2);
> seq_printf(m, " softirq on events: %11llu\n", si1);
> seq_printf(m, " softirq off events: %11llu\n", si2);
> - seq_printf(m, " redundant softirq ons: %11llu\n", sr1);
> - seq_printf(m, " redundant softirq offs: %11llu\n", sr2);
> #endif
> }
>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 1/2] sched/topology: Allow archs to override cpu_smt_mask
From: peterz @ 2020-08-04 10:45 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Gautham R Shenoy, Michael Neuling, Vincent Guittot, Rik van Riel,
linuxppc-dev, LKML, Ingo Molnar, Thomas Gleixner, Mel Gorman,
Valentin Schneider, Dietmar Eggemann
In-Reply-To: <20200804033307.76111-1-srikar@linux.vnet.ibm.com>
On Tue, Aug 04, 2020 at 09:03:06AM +0530, Srikar Dronamraju wrote:
> cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
> most architectures. One of the users of cpu_smt_mask(), would be to
> identify idle-cores. On Power9, a pair of cores can be presented by the
> firmware as a big-core for backward compatibility reasons.
>
> In order to maintain userspace backward compatibility with previous
> versions of processor, (since Power8 had SMT8 cores), Power9 onwards there
> is option to the firmware to advertise a pair of SMT4 cores as a fused
> cores (referred to as the big_core mode in the Linux Kernel). On Power9
> this pair shares the L2 cache as well. However, from the scheduler's point
> of view, a core should be determined by SMT4. The load-balancer already
> does this. Hence allow PowerPc architecture to override the default
> cpu_smt_mask() to point to the SMT4 cores in a big_core mode.
I'm utterly confused.
Why can't you set your regular siblings mask to the smt4 thing? Who
cares about the compat stuff, I thought that was an LPAR/AIX thing.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/topology: Override cpu_smt_mask
From: peterz @ 2020-08-04 10:46 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Gautham R Shenoy, Michael Neuling, Vincent Guittot, Rik van Riel,
linuxppc-dev, LKML, Ingo Molnar, Thomas Gleixner, Mel Gorman,
Valentin Schneider, Dietmar Eggemann
In-Reply-To: <20200804033307.76111-2-srikar@linux.vnet.ibm.com>
On Tue, Aug 04, 2020 at 09:03:07AM +0530, Srikar Dronamraju wrote:
> On Power9 a pair of cores can be presented by the firmware as a big-core
> for backward compatibility reasons, with 4 threads per (small) core and 8
> threads per big-core. cpu_smt_mask() should generally point to the cpu mask
> of the (small)core.
>
> In order to maintain userspace backward compatibility (with Power8 chips in
> case of Power9) in enterprise Linux systems, the topology_sibling_cpumask
> has to be set to big-core. Hence override the default cpu_smt_mask() to be
> powerpc specific allowing for better scheduling behaviour on Power.
Why does Linux userspace care about this?
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/topology: Override cpu_smt_mask
From: Valentin Schneider @ 2020-08-04 11:02 UTC (permalink / raw)
To: peterz
Cc: Gautham R Shenoy, Michael Neuling, Vincent Guittot,
Srikar Dronamraju, Rik van Riel, linuxppc-dev, LKML,
Dietmar Eggemann, Thomas Gleixner, Mel Gorman, Ingo Molnar
In-Reply-To: <20200804104642.GC2657@hirez.programming.kicks-ass.net>
On 04/08/20 11:46, peterz@infradead.org wrote:
> On Tue, Aug 04, 2020 at 09:03:07AM +0530, Srikar Dronamraju wrote:
>> On Power9 a pair of cores can be presented by the firmware as a big-core
>> for backward compatibility reasons, with 4 threads per (small) core and 8
>> threads per big-core. cpu_smt_mask() should generally point to the cpu mask
>> of the (small)core.
>>
>> In order to maintain userspace backward compatibility (with Power8 chips in
>> case of Power9) in enterprise Linux systems, the topology_sibling_cpumask
>> has to be set to big-core. Hence override the default cpu_smt_mask() to be
>> powerpc specific allowing for better scheduling behaviour on Power.
>
> Why does Linux userspace care about this?
Ditto; from [1], a core contains CPUs that all share the same L1 (and capacity,
as per SD_SHARE_CPUCAPACITY). So IMO it makes perfect sense to have a first
domain spanning L1, and its parent spanning L2 - that means
topology_sibling_cpumask *itself* should span a single core rather than a
pair.
[1]: https://lkml.kernel.org/r/jhjr1sviswg.mognet@arm.com
^ permalink raw reply
* Re: [PATCH v8 5/8] powerpc/vdso: Prepare for switching VDSO to generic C implementation.
From: Christophe Leroy @ 2020-08-04 11:14 UTC (permalink / raw)
To: Michael Ellerman, 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: <878sflvbad.fsf@mpe.ellerman.id.au>
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. 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. So lets create two frames:
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
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:
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
Christophe
^ permalink raw reply related
* Re: [PATCH v8 2/8] powerpc/vdso: Remove __kernel_datapage_offset and simplify __get_datapage()
From: Christophe Leroy @ 2020-08-04 11:17 UTC (permalink / raw)
To: Michael Ellerman, Christophe Leroy, Benjamin Herrenschmidt,
Paul Mackerras, nathanl
Cc: linux-arch, arnd, linux-kernel, luto, tglx, vincenzo.frascino,
linuxppc-dev
In-Reply-To: <87wo34tbas.fsf@mpe.ellerman.id.au>
On 07/16/2020 02:59 AM, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> The VDSO datapage and the text pages are always located immediately
>> next to each other, so it can be hardcoded without an indirection
>> through __kernel_datapage_offset
>>
>> In order to ease things, move the data page in front like other
>> arches, that way there is no need to know the size of the library
>> to locate the data page.
>>
>> Before:
>> clock-getres-realtime-coarse: vdso: 714 nsec/call
>> clock-gettime-realtime-coarse: vdso: 792 nsec/call
>> clock-gettime-realtime: vdso: 1243 nsec/call
>>
>> After:
>> clock-getres-realtime-coarse: vdso: 699 nsec/call
>> clock-gettime-realtime-coarse: vdso: 784 nsec/call
>> clock-gettime-realtime: vdso: 1231 nsec/call
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>> v7:
>> - Moved the removal of the tmp param of __get_datapage()
>> in a subsequent patch
>> - Included the addition of the offset param to __get_datapage()
>> in the further preparatory patch
>> ---
>> arch/powerpc/include/asm/vdso_datapage.h | 8 ++--
>> arch/powerpc/kernel/vdso.c | 53 ++++--------------------
>> arch/powerpc/kernel/vdso32/datapage.S | 3 --
>> arch/powerpc/kernel/vdso32/vdso32.lds.S | 7 +---
>> arch/powerpc/kernel/vdso64/datapage.S | 3 --
>> arch/powerpc/kernel/vdso64/vdso64.lds.S | 7 +---
>> 6 files changed, 16 insertions(+), 65 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/vdso_datapage.h b/arch/powerpc/include/asm/vdso_datapage.h
>> index b9ef6cf50ea5..11886467dfdf 100644
>> --- a/arch/powerpc/include/asm/vdso_datapage.h
>> +++ b/arch/powerpc/include/asm/vdso_datapage.h
>> @@ -118,10 +118,12 @@ extern struct vdso_data *vdso_data;
>>
>> .macro get_datapage ptr, tmp
>> bcl 20, 31, .+4
>> +999:
>> mflr \ptr
>> - addi \ptr, \ptr, (__kernel_datapage_offset - (.-4))@l
>> - lwz \tmp, 0(\ptr)
>> - add \ptr, \tmp, \ptr
>> +#if CONFIG_PPC_PAGE_SHIFT > 14
>> + addis \ptr, \ptr, (_vdso_datapage - 999b)@ha
>> +#endif
>> + addi \ptr, \ptr, (_vdso_datapage - 999b)@l
>> .endm
>>
>> #endif /* __ASSEMBLY__ */
>> diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
>> index f38f26e844b6..d33fa22ddbed 100644
>> --- a/arch/powerpc/kernel/vdso.c
>> +++ b/arch/powerpc/kernel/vdso.c
>> @@ -190,7 +190,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
>> * install_special_mapping or the perf counter mmap tracking code
>> * will fail to recognise it as a vDSO (since arch_vma_name fails).
>> */
>> - current->mm->context.vdso_base = vdso_base;
>> + current->mm->context.vdso_base = vdso_base + PAGE_SIZE;
>
> I merged this but then realised it breaks the display of the vdso in /proc/self/maps.
>
> ie. the vdso vma gets no name:
>
> # cat /proc/self/maps
> 110f90000-110fa0000 r-xp 00000000 08:03 17021844 /usr/bin/cat
> 110fa0000-110fb0000 r--p 00000000 08:03 17021844 /usr/bin/cat
> 110fb0000-110fc0000 rw-p 00010000 08:03 17021844 /usr/bin/cat
> 126000000-126030000 rw-p 00000000 00:00 0 [heap]
> 7fffa8790000-7fffa87d0000 rw-p 00000000 00:00 0
> 7fffa87d0000-7fffa8830000 r--p 00000000 08:03 17521786 /usr/lib/locale/en_AU.utf8/LC_CTYPE
> 7fffa8830000-7fffa8840000 r--p 00000000 08:03 16958337 /usr/lib/locale/en_AU.utf8/LC_NUMERIC
> 7fffa8840000-7fffa8850000 r--p 00000000 08:03 8501358 /usr/lib/locale/en_AU.utf8/LC_TIME
> 7fffa8850000-7fffa8ad0000 r--p 00000000 08:03 16870886 /usr/lib/locale/en_AU.utf8/LC_COLLATE
> 7fffa8ad0000-7fffa8ae0000 r--p 00000000 08:03 8509433 /usr/lib/locale/en_AU.utf8/LC_MONETARY
> 7fffa8ae0000-7fffa8af0000 r--p 00000000 08:03 25383753 /usr/lib/locale/en_AU.utf8/LC_MESSAGES/SYS_LC_MESSAGES
> 7fffa8af0000-7fffa8b00000 r--p 00000000 08:03 17521790 /usr/lib/locale/en_AU.utf8/LC_PAPER
> 7fffa8b00000-7fffa8b10000 r--p 00000000 08:03 8501354 /usr/lib/locale/en_AU.utf8/LC_NAME
> 7fffa8b10000-7fffa8b20000 r--p 00000000 08:03 8509431 /usr/lib/locale/en_AU.utf8/LC_ADDRESS
> 7fffa8b20000-7fffa8b30000 r--p 00000000 08:03 8509434 /usr/lib/locale/en_AU.utf8/LC_TELEPHONE
> 7fffa8b30000-7fffa8b40000 r--p 00000000 08:03 17521787 /usr/lib/locale/en_AU.utf8/LC_MEASUREMENT
> 7fffa8b40000-7fffa8b50000 r--s 00000000 08:03 25623315 /usr/lib64/gconv/gconv-modules.cache
> 7fffa8b50000-7fffa8d40000 r-xp 00000000 08:03 25383789 /usr/lib64/libc-2.30.so
> 7fffa8d40000-7fffa8d50000 r--p 001e0000 08:03 25383789 /usr/lib64/libc-2.30.so
> 7fffa8d50000-7fffa8d60000 rw-p 001f0000 08:03 25383789 /usr/lib64/libc-2.30.so
> 7fffa8d60000-7fffa8d70000 r--p 00000000 08:03 8509432 /usr/lib/locale/en_AU.utf8/LC_IDENTIFICATION
> 7fffa8d70000-7fffa8d90000 r-xp 00000000 00:00 0 <--- missing
> 7fffa8d90000-7fffa8dc0000 r-xp 00000000 08:03 25383781 /usr/lib64/ld-2.30.so
> 7fffa8dc0000-7fffa8dd0000 r--p 00020000 08:03 25383781 /usr/lib64/ld-2.30.so
> 7fffa8dd0000-7fffa8de0000 rw-p 00030000 08:03 25383781 /usr/lib64/ld-2.30.so
> 7fffc31c0000-7fffc31f0000 rw-p 00000000 00:00 0 [stack]
>
>
> And it's also going to break the logic in arch_unmap() to detect if
> we're unmapping (part of) the VDSO. And it will break arch_remap() too.
>
> And the logic to recognise the signal trampoline in
> arch/powerpc/perf/callchain_*.c as well.
I don't think it breaks that one, because ->vdsobase is still the start
of text.
>
> So I'm going to rebase and drop this for now.
>
> Basically we have a bunch of places that assume that vdso_base is == the
> start of the VDSO vma, and also that the code starts there. So that will
> need some work to tease out all those assumptions and make them work
> with this change.
Ok, one day I need to look at it in more details and see how other
architectures handle it etc ...
As the benefit is only 2 CPU cycles, I'll drop it for now.
Christophe
^ permalink raw reply
* [PATCH v9 1/5] powerpc/processor: Move cpu_relax() into asm/vdso/processor.h
From: Christophe Leroy @ 2020-08-04 11:47 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.1596541334.git.christophe.leroy@csgroup.eu>
cpu_relax() need to be in asm/vdso/processor.h to be used by
the C VDSO generic library.
Move it there.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v9: Forgot to remove cpu_relax() from processor.h in v8
---
arch/powerpc/include/asm/processor.h | 13 ++-----------
arch/powerpc/include/asm/vdso/processor.h | 23 +++++++++++++++++++++++
2 files changed, 25 insertions(+), 11 deletions(-)
create mode 100644 arch/powerpc/include/asm/vdso/processor.h
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index ed0d633ab5aa..c1ba9c8d9b90 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -6,6 +6,8 @@
* Copyright (C) 2001 PPC 64 Team, IBM Corp
*/
+#include <vdso/processor.h>
+
#include <asm/reg.h>
#ifdef CONFIG_VSX
@@ -63,14 +65,6 @@ extern int _chrp_type;
#endif /* defined(__KERNEL__) && defined(CONFIG_PPC32) */
-/* Macros for adjusting thread priority (hardware multi-threading) */
-#define HMT_very_low() asm volatile("or 31,31,31 # very low priority")
-#define HMT_low() asm volatile("or 1,1,1 # low priority")
-#define HMT_medium_low() asm volatile("or 6,6,6 # medium low priority")
-#define HMT_medium() asm volatile("or 2,2,2 # medium priority")
-#define HMT_medium_high() asm volatile("or 5,5,5 # medium high priority")
-#define HMT_high() asm volatile("or 3,3,3 # high priority")
-
#ifdef __KERNEL__
#ifdef CONFIG_PPC64
@@ -350,7 +344,6 @@ static inline unsigned long __pack_fe01(unsigned int fpmode)
}
#ifdef CONFIG_PPC64
-#define cpu_relax() do { HMT_low(); HMT_medium(); barrier(); } while (0)
#define spin_begin() HMT_low()
@@ -369,8 +362,6 @@ do { \
} \
} while (0)
-#else
-#define cpu_relax() barrier()
#endif
/* Check that a certain kernel stack pointer is valid in task_struct p */
diff --git a/arch/powerpc/include/asm/vdso/processor.h b/arch/powerpc/include/asm/vdso/processor.h
new file mode 100644
index 000000000000..39b9beace9ca
--- /dev/null
+++ b/arch/powerpc/include/asm/vdso/processor.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_VDSO_PROCESSOR_H
+#define __ASM_VDSO_PROCESSOR_H
+
+#ifndef __ASSEMBLY__
+
+/* Macros for adjusting thread priority (hardware multi-threading) */
+#define HMT_very_low() asm volatile("or 31, 31, 31 # very low priority")
+#define HMT_low() asm volatile("or 1, 1, 1 # low priority")
+#define HMT_medium_low() asm volatile("or 6, 6, 6 # medium low priority")
+#define HMT_medium() asm volatile("or 2, 2, 2 # medium priority")
+#define HMT_medium_high() asm volatile("or 5, 5, 5 # medium high priority")
+#define HMT_high() asm volatile("or 3, 3, 3 # high priority")
+
+#ifdef CONFIG_PPC64
+#define cpu_relax() do { HMT_low(); HMT_medium(); barrier(); } while (0)
+#else
+#define cpu_relax() barrier()
+#endif
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_VDSO_PROCESSOR_H */
--
2.25.0
^ permalink raw reply related
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