[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YqHBzbAiqaZeoipw@worktop.programming.kicks-ass.net>
Date: Thu, 9 Jun 2022 11:47:57 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Tony Lindgren <tony@...mide.com>
Cc: Arnd Bergmann <arnd@...db.de>, Richard Henderson <rth@...ddle.net>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>,
Vineet Gupta <vgupta@...nel.org>,
Russell King - ARM Linux <linux@...linux.org.uk>,
Hans Ulli Kroll <ulli.kroll@...glemail.com>,
Linus Walleij <linus.walleij@...aro.org>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Sascha Hauer <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Kevin Hilman <khilman@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Guo Ren <guoren@...nel.org>,
bcain@...cinc.com, Huacai Chen <chenhuacai@...nel.org>,
Xuerui Wang <kernel@...0n.name>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Sam Creasey <sammy@...my.net>, Michal Simek <monstr@...str.eu>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Dinh Nguyen <dinguyen@...nel.org>,
Jonas Bonn <jonas@...thpole.se>,
Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
Stafford Horne <shorne@...il.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Helge Deller <deller@....de>,
Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>,
David Miller <davem@...emloft.net>,
Richard Weinberger <richard@....at>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Johannes Berg <johannes@...solutions.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
the arch/x86 maintainers <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Juergen Gross <jgross@...e.com>, srivatsa@...il.mit.edu,
amakhalov@...are.com, Pv-drivers <pv-drivers@...are.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Chris Zankel <chris@...kel.net>,
Max Filippov <jcmvbkbc@...il.com>,
Rafael Wysocki <rafael@...nel.org>,
Len Brown <lenb@...nel.org>, Pavel Machek <pavel@....cz>,
gregkh <gregkh@...uxfoundation.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
lpieralisi@...nel.org, Sudeep Holla <sudeep.holla@....com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Anup Patel <anup@...infault.org>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
jacob.jun.pan@...ux.intel.com, Yury Norov <yury.norov@...il.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Steven Rostedt <rostedt@...dmis.org>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
John Ogness <john.ogness@...utronix.de>,
"Paul E. McKenney" <paulmck@...nel.org>,
Frederic Weisbecker <frederic@...nel.org>,
quic_neeraju@...cinc.com, Josh Triplett <josh@...htriplett.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Joel Fernandes <joel@...lfernandes.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
vschneid@...hat.com, jpoimboe@...nel.org,
alpha <linux-alpha@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@...ts.infradead.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-omap <linux-omap@...r.kernel.org>,
linux-csky@...r.kernel.org,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@...r.kernel.org>,
"open list:IA64 (Itanium) PLATFORM" <linux-ia64@...r.kernel.org>,
linux-m68k <linux-m68k@...ts.linux-m68k.org>,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
Openrisc <openrisc@...ts.librecores.org>,
Parisc List <linux-parisc@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
linux-s390 <linux-s390@...r.kernel.org>,
Linux-sh list <linux-sh@...r.kernel.org>,
sparclinux <sparclinux@...r.kernel.org>,
linux-um <linux-um@...ts.infradead.org>,
linux-perf-users@...r.kernel.org,
"open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE"
<virtualization@...ts.linux-foundation.org>,
xen-devel <xen-devel@...ts.xenproject.org>,
"open list:TENSILICA XTENSA PORT (xtensa)"
<linux-xtensa@...ux-xtensa.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux PM list <linux-pm@...r.kernel.org>,
linux-clk <linux-clk@...r.kernel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
"open list:TEGRA ARCHITECTURE SUPPORT" <linux-tegra@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>, rcu@...r.kernel.org
Subject: Re: [PATCH 33/36] cpuidle,omap3: Use WFI for omap3_pm_idle()
On Thu, Jun 09, 2022 at 10:39:22AM +0300, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@...db.de> [220608 18:18]:
> > On Wed, Jun 8, 2022 at 4:27 PM Peter Zijlstra <peterz@...radead.org> wrote:
> > >
> > > arch_cpu_idle() is a very simple idle interface and exposes only a
> > > single idle state and is expected to not require RCU and not do any
> > > tracing/instrumentation.
> > >
> > > As such, omap_sram_idle() is not a valid implementation. Replace it
> > > with the simple (shallow) omap3_do_wfi() call. Leaving the more
> > > complicated idle states for the cpuidle driver.
>
> Agreed it makes sense to limit deeper idle states to cpuidle. Hopefully
> there is some informative splat for attempting to use arch_cpu_ide()
> for deeper idle states :)
The arch_cpu_idle() interface doesn't allow one to express a desire for
deeper states. I'm not sure how anyone could even attempt this.
But given what OMAP needs to go deeper, this would involve things that
require RCU, combine that with the follow up patches that rip out all
the trace_.*_rcuidle() hackery from the power and clock domain code,
PROVE_RCU should scream if anybody were to attempt it.
Powered by blists - more mailing lists