Re: [PATCH 01/11] ARM: dts: ti: Fix pca954x i2c-mux node names

[Tony Lindgren]

* Geert Uytterhoeven  [221202 18:50]:
> "make dtbs_check":
> 
> arch/arm/boot/dts/am3874-iceboard.dtb: pca9548@70: $nodename:0: 
> 'pca9548@70' does not match '^(i2c-?)?mux'
>   From schema: 
> Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
> arch/arm/boot/dts/am3874-iceboard.dtb: pca9548@70: Unevaluated properties 
> are not allowed ('#address-cells', '#size-cells', 'i2c@0', 'i2c@1', 'i2c@2', 
> 'i2c@3', 'i2c@4', 'i2c@5', 'i2c@6', 'i2c@7' were unexpected)
>   From schema: 
> Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
> ...
> 
> Fix this by renaming PCA954x nodes to "i2c-mux", to match the I2C bus
> multiplexer/switch DT bindings and the Generic Names Recommendation in
> the Devicetree Specification.

Applying this patch into omap-for-v6.3/dt thanks.

Tony

Re: [PATCH v2 00/44] cpuidle,rcu: Clean up the mess

[Tony Lindgren]

Hi,

* Peter Zijlstra  [220919 10:08]:
> Hi All!
> 
> At long last, a respin of the cpuidle vs rcu cleanup patches.
> 
> v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
> 
> These here patches clean up the mess that is cpuidle vs rcuidle.

I just gave these a quick test and things still work for me. The old
omap3 off mode during idle still works. No more need to play the
whack the mole game with RCU-idle :) I did not test on x86, or on other
ARMs, but considering the test pretty much covered the all the
affected RCU-idle related paths, where suitable, feel free to add:

Tested-by: Tony Lindgren 

Re: [PATCH v2 37/44] arm,omap2: Use WFI for omap2_pm_idle()

[Tony Lindgren]

* Peter Zijlstra  [220919 10:09]:
> 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, omap2_pm_idle() is not a valid implementation. Replace it
> with a simple (shallow) omap2_do_wfi() call.
> 
> Omap2 doesn't have a cpuidle driver; but adding one would be the
> recourse to (re)gain the other idle states.

Looks good to me thanks:

Acked-by: Tony Lindgren 

Re: [PATCH 34.5/36] cpuidle,omap4: Push RCU-idle into omap4_enter_lowpower()

[Tony Lindgren]

linux.intel.com, Arnd Bergmann , ulli.kr...@googlemail.com, 
vgu...@kernel.org, linux-...@vger.kernel.org, j...@joshtriplett.org, 
rost...@goodmis.org, r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com, 
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com, 
shawn...@kernel.org, da...@davemloft.net, Peter Vasil , 
dal...@libc.org, pv-driv...@vmware.com, amakha...@vmware.com, 
bjorn.anders...@linaro.org, h...@zytor.com, sparcli...@vger.kernel.org, 
linux-hexa...@vger.kernel.org, linux-ri...@lists.infradead.org, 
anton.iva...@cambridgegreys.com, jo...@southpole.se, yury.no...@gmail.com, 
rich...@nod.at, x...@kernel.org, li...@armlinux.org.uk, mi...@redhat.com, 
a...@eecs.berkeley.edu, paul...@kernel.org, h...@linux.ibm.com, 
stefan.kristians...@saunalahti.fi, openr...@lists.librecores.org, 
paul.walms...@sifive.com, linux-te...@vger.kernel.org, namhy...@kernel.org, 
andriy.shevche...@linux.intel.com, jpoim...@kernel.org, jgr...@suse.com, 
 mon...@monstr.eu, linux-m...@vger.kernel.org, pal...@dabbelt.com, 
a...@brainfault.org, i...@jurassic.park.msu.ru, johan...@sipsolutions.net, 
linuxppc-dev@lists.ozlabs.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


Hi,

Adding Aaro Koskinen and Peter Vasil for pm24xx for n800 and n810 related
idle.

* Peter Zijlstra  [220614 22:07]:
> On Mon, Jun 13, 2022 at 03:39:05PM +0300, Tony Lindgren wrote:
> > OMAP4 uses full SoC suspend modes as idle states, as such it needs the
> > whole power-domain and clock-domain code from the idle path.
> > 
> > All that code is not suitable to run with RCU disabled, as such push
> > RCU-idle deeper still.
> > 
> > Signed-off-by: Tony Lindgren 
> > ---
> > 
> > Peter here's one more for your series, looks like this is needed to avoid
> > warnings similar to what you did for omap3.
> 
> Thanks Tony!
> 
> I've had a brief look at omap2_pm_idle() and do I understand it right
> that something like the below patch would reduce it to a simple 'WFI'?

Yes that should do for omap2_do_wfi().

> What do I do with the rest of that code, because I don't think this
> thing has a cpuidle driver to take over, effectively turning it into
> dead code.

As we are establishing a policy where deeper idle states must be
handled by cpuidle, and for most part that has been the case for at least
10 years, I'd just drop the unused functions with an explanation in the
patch why we're doing it. Or the functions could be tagged with
__maybe_unused if folks prefer that.

In the pm24xx case we are not really causing a regression for users as
there are still pending patches to make n800 and n810 truly usable with
the mainline kernel. At least the PMIC and LCD related patches need some
work [0]. The deeper idle states can be added back later using cpuidle
as needed so we have a clear path.

Aaro & Peter V, do you have any better suggestions here as this will
mostly affect you guys currently?

Regards,

Tony

[0] 
https://lore.kernel.org/linux-omap/20211224214512.1583430-1-peter.va...@gmail.com/


> --- a/arch/arm/mach-omap2/pm24xx.c
> +++ b/arch/arm/mach-omap2/pm24xx.c
> @@ -126,10 +126,20 @@ static int omap2_allow_mpu_retention(voi
>   return 1;
>  }
>  
> -static void omap2_enter_mpu_retention(void)
> +static void omap2_do_wfi(void)
>  {
>   const int zero = 0;
>  
> + /* WFI */
> + asm("mcr p15, 0, %0, c7, c0, 4" : : "r" (zero) : "memory", "cc");
> +}
> +
> +#if 0
> +/*
> + * possible cpuidle implementation between WFI and full_retention above
> + */
> +static void omap2_enter_mpu_retention(void)
> +{
>   /* The peripherals seem not to be able to wake up the MPU when
>* it is in retention mode. */
>   if (omap2_allow_mpu_retention()) {
> @@ -146,8 +157,7 @@ static void omap2_enter_mpu_retention(vo
>   pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
>   }
>  
> - /* WFI */
> - asm("mcr p15, 0, %0, c7, c0, 4" : : "r" (zero) : "memory", "cc");
> + omap2_do_wfi();
>  
>   pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
>  }
> @@ -161,6 +171,7 @@ static int omap2_can_sleep(void)
>  
>   return 1;
>  }
> +#endif
>  
>  static void omap2_pm_idle(void)
>  {
> @@ -169,6 +180,7 @@ static void omap2_pm_idle(void)
>   if (omap_irq_pending())
>   return;
>  
> +#if 0
>   error = cpu_cluster_pm_enter();
>   if (error || !omap2_can_sleep()) {
>   omap2_enter_mpu_retention();
> @@ -179,6 +191,9 @@ static void omap2_pm_idle(void)
>  
>  out_cpu_cluster_pm:
>   cpu_cluster_pm_exit();
> +#else
> + omap2_do_wfi();
> +#endif
>  }
>  
>  static void __init prcm_setup_regs(void)

[PATCH 34.5/36] cpuidle,omap4: Push RCU-idle into omap4_enter_lowpower()

[Tony Lindgren]

rndb.de>, ulli.kr...@googlemail.com, vgu...@kernel.org, 
linux-...@vger.kernel.org, j...@joshtriplett.org, rost...@goodmis.org, 
r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com, 
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com, 
shawn...@kernel.org, da...@davemloft.net, dal...@libc.org, 
pv-driv...@vmware.com, amakha...@vmware.com, bjorn.anders...@linaro.org, 
h...@zytor.com, sparcli...@vger.kernel.org, linux-hexa...@vger.kernel.org, 
linux-ri...@lists.infradead.org, anton.iva...@cambridgegreys.com, 
jo...@southpole.se, yury.no...@gmail.com, rich...@nod.at, x...@kernel.org, 
li...@armlinux.org.uk, mi...@redhat.com, a...@eecs.berkeley.edu, 
paul...@kernel.org, h...@linux.ibm.com, stefan.kristians...@saunalahti.fi, 
openr...@lists.librecores.org, paul.walms...@sifive.com, 
linux-te...@vger.kernel.org, namhy...@kernel.org, 
andriy.shevche...@linux.intel.com, jpoim...@kernel.org, jgr...@suse.com, 
mon...@monstr.eu, linux-m...@vger.kernel.org, pal...@dabbelt.com, anup@bra
 infault.org, i...@jurassic.park.msu.ru, johan...@sipsolutions.net, 
linuxppc-dev@lists.ozlabs.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


OMAP4 uses full SoC suspend modes as idle states, as such it needs the
whole power-domain and clock-domain code from the idle path.

All that code is not suitable to run with RCU disabled, as such push
RCU-idle deeper still.

Signed-off-by: Tony Lindgren 
---

Peter here's one more for your series, looks like this is needed to avoid
warnings similar to what you did for omap3.

---
 arch/arm/mach-omap2/common.h  |  6 --
 arch/arm/mach-omap2/cpuidle44xx.c |  8 ++--
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 12 +++-
 arch/arm/mach-omap2/pm44xx.c  |  2 +-
 4 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -284,11 +284,13 @@ extern u32 omap4_get_cpu1_ns_pa_addr(void);
 
 #if defined(CONFIG_SMP) && defined(CONFIG_PM)
 extern int omap4_mpuss_init(void);
-extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
+extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state,
+   bool rcuidle);
 extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
 #else
 static inline int omap4_enter_lowpower(unsigned int cpu,
-   unsigned int power_state)
+   unsigned int power_state,
+   bool rcuidle)
 {
cpu_do_idle();
return 0;
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -105,9 +105,7 @@ static int omap_enter_idle_smp(struct cpuidle_device *dev,
}
raw_spin_unlock_irqrestore(_lock, flag);
 
-   cpuidle_rcu_enter();
-   omap4_enter_lowpower(dev->cpu, cx->cpu_state);
-   cpuidle_rcu_exit();
+   omap4_enter_lowpower(dev->cpu, cx->cpu_state, true);
 
raw_spin_lock_irqsave(_lock, flag);
if (cx->mpu_state_vote == num_online_cpus())
@@ -186,10 +184,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
}
}
 
-   cpuidle_rcu_enter();
-   omap4_enter_lowpower(dev->cpu, cx->cpu_state);
+   omap4_enter_lowpower(dev->cpu, cx->cpu_state, true);
cpu_done[dev->cpu] = true;
-   cpuidle_rcu_exit();
 
/* Wakeup CPU1 only if it is not offlined */
if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c 
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -33,6 +33,7 @@
  * and first to wake-up when MPUSS low power states are excercised
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -214,6 +215,7 @@ static void __init save_l2x0_context(void)
  * of OMAP4 MPUSS subsystem
  * @cpu : CPU ID
  * @power_state: Low power state.
+ * @rcuidle: RCU needs to be idled
  *
  * MPUSS states for the context save:
  * save_state =
@@ -222,7 +224,8 @@ static void __init save_l2x0_context(void)
  * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
  * 3 - CPUx L1 and logic lost + GIC + L2 lost: DEVICE OFF
  */
-int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
+int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state,
+bool rcuidle)
 {
struct omap4_cpu_pm_info *pm_info = _cpu(omap4_pm_info, cpu);
unsigned int save_state = 0, cpu_logic_state = PWRDM_POWER_RET;
@@ -268,6 +271,10 @@ int omap4_enter_lowpower(unsigned int cpu, uns

Re: [PATCH 33/36] cpuidle,omap3: Use WFI for omap3_pm_idle()

[Tony Lindgren]

rndb.de>, ulli.kr...@googlemail.com, vgu...@kernel.org, 
linux-...@vger.kernel.org, j...@joshtriplett.org, rost...@goodmis.org, 
r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com, 
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com, 
shawn...@kernel.org, da...@davemloft.net, dal...@libc.org, 
pv-driv...@vmware.com, amakha...@vmware.com, bjorn.anders...@linaro.org, 
h...@zytor.com, sparcli...@vger.kernel.org, linux-hexa...@vger.kernel.org, 
linux-ri...@lists.infradead.org, anton.iva...@cambridgegreys.com, 
jo...@southpole.se, yury.no...@gmail.com, rich...@nod.at, x...@kernel.org, 
li...@armlinux.org.uk, mi...@redhat.com, a...@eecs.berkeley.edu, 
paul...@kernel.org, h...@linux.ibm.com, stefan.kristians...@saunalahti.fi, 
openr...@lists.librecores.org, paul.walms...@sifive.com, 
linux-te...@vger.kernel.org, namhy...@kernel.org, 
andriy.shevche...@linux.intel.com, jpoim...@kernel.org, jgr...@suse.com, 
mon...@monstr.eu, linux-m...@vger.kernel.org, pal...@dabbelt.com, anup@bra
 infault.org, i...@jurassic.park.msu.ru, johan...@sipsolutions.net, 
linuxppc-dev@lists.ozlabs.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


* Peter Zijlstra  [220608 14:52]:
> 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.

Acked-by: Tony Lindgren 

Re: [PATCH 34/36] cpuidle,omap3: Push RCU-idle into omap_sram_idle()

[Tony Lindgren]

rndb.de>, ulli.kr...@googlemail.com, vgu...@kernel.org, 
linux-...@vger.kernel.org, j...@joshtriplett.org, rost...@goodmis.org, 
r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com, 
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com, 
shawn...@kernel.org, da...@davemloft.net, dal...@libc.org, 
pv-driv...@vmware.com, amakha...@vmware.com, bjorn.anders...@linaro.org, 
h...@zytor.com, sparcli...@vger.kernel.org, linux-hexa...@vger.kernel.org, 
linux-ri...@lists.infradead.org, anton.iva...@cambridgegreys.com, 
jo...@southpole.se, yury.no...@gmail.com, rich...@nod.at, x...@kernel.org, 
li...@armlinux.org.uk, mi...@redhat.com, a...@eecs.berkeley.edu, 
paul...@kernel.org, h...@linux.ibm.com, stefan.kristians...@saunalahti.fi, 
openr...@lists.librecores.org, paul.walms...@sifive.com, 
linux-te...@vger.kernel.org, namhy...@kernel.org, 
andriy.shevche...@linux.intel.com, jpoim...@kernel.org, jgr...@suse.com, 
mon...@monstr.eu, linux-m...@vger.kernel.org, pal...@dabbelt.com, anup@bra
 infault.org, i...@jurassic.park.msu.ru, johan...@sipsolutions.net, 
linuxppc-dev@lists.ozlabs.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


* Peter Zijlstra  [220608 15:00]:
> On Wed, Jun 08, 2022 at 04:27:57PM +0200, Peter Zijlstra wrote:
> > @@ -254,11 +255,18 @@ void omap_sram_idle(void)
> >  */
> > if (save_state)
> > omap34xx_save_context(omap3_arm_context);
> > +
> > +   if (rcuidle)
> > +   cpuidle_rcu_enter();
> > +
> > if (save_state == 1 || save_state == 3)
> > cpu_suspend(save_state, omap34xx_do_sram_idle);
> > else
> > omap34xx_do_sram_idle(save_state);
> >  
> > +   if (rcuidle)
> > +   rcuidle_rcu_exit();
> 
> *sigh* so much for this having been exposed to the robots for >2 days :/

I tested your git branch of these patches, so:

Reviewed-by: Tony Lindgren 
Tested-by: Tony Lindgren 

Re: [PATCH 12/36] cpuidle,omap2: Push RCU-idle into driver

[Tony Lindgren]

rndb.de>, ulli.kr...@googlemail.com, vgu...@kernel.org, 
linux-...@vger.kernel.org, j...@joshtriplett.org, rost...@goodmis.org, 
r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com, 
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com, 
shawn...@kernel.org, da...@davemloft.net, dal...@libc.org, 
pv-driv...@vmware.com, amakha...@vmware.com, bjorn.anders...@linaro.org, 
h...@zytor.com, sparcli...@vger.kernel.org, linux-hexa...@vger.kernel.org, 
linux-ri...@lists.infradead.org, anton.iva...@cambridgegreys.com, 
jo...@southpole.se, yury.no...@gmail.com, rich...@nod.at, x...@kernel.org, 
li...@armlinux.org.uk, mi...@redhat.com, a...@eecs.berkeley.edu, 
paul...@kernel.org, h...@linux.ibm.com, stefan.kristians...@saunalahti.fi, 
openr...@lists.librecores.org, paul.walms...@sifive.com, 
linux-te...@vger.kernel.org, namhy...@kernel.org, 
andriy.shevche...@linux.intel.com, jpoim...@kernel.org, jgr...@suse.com, 
mon...@monstr.eu, linux-m...@vger.kernel.org, pal...@dabbelt.com, anup@bra
 infault.org, i...@jurassic.park.msu.ru, johan...@sipsolutions.net, 
linuxppc-dev@lists.ozlabs.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


* Peter Zijlstra  [220608 14:42]:
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again, some *four* times, before going idle is daft.

Maybe update the subject line with s/omap2/omap4/, other than that:

Reviewed-by: Tony Lindgren 
Tested-by: Tony Lindgren 

Re: [PATCH 10/36] cpuidle,omap3: Push RCU-idle into driver

[Tony Lindgren]

rndb.de>, ulli.kr...@googlemail.com, vgu...@kernel.org, 
linux-...@vger.kernel.org, j...@joshtriplett.org, rost...@goodmis.org, 
r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com, 
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com, 
shawn...@kernel.org, da...@davemloft.net, dal...@libc.org, 
pv-driv...@vmware.com, amakha...@vmware.com, bjorn.anders...@linaro.org, 
h...@zytor.com, sparcli...@vger.kernel.org, linux-hexa...@vger.kernel.org, 
linux-ri...@lists.infradead.org, anton.iva...@cambridgegreys.com, 
jo...@southpole.se, yury.no...@gmail.com, rich...@nod.at, x...@kernel.org, 
li...@armlinux.org.uk, mi...@redhat.com, a...@eecs.berkeley.edu, 
paul...@kernel.org, h...@linux.ibm.com, stefan.kristians...@saunalahti.fi, 
openr...@lists.librecores.org, paul.walms...@sifive.com, 
linux-te...@vger.kernel.org, namhy...@kernel.org, 
andriy.shevche...@linux.intel.com, jpoim...@kernel.org, jgr...@suse.com, 
mon...@monstr.eu, linux-m...@vger.kernel.org, pal...@dabbelt.com, anup@bra
 infault.org, i...@jurassic.park.msu.ru, johan...@sipsolutions.net, 
linuxppc-dev@lists.ozlabs.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


* Peter Zijlstra  [220608 14:42]:
> Doing RCU-idle outside the driver, only to then teporarily enable it
> again before going idle is daft.

Reviewed-by: Tony Lindgren 
Tested-by: Tony Lindgren 

Re: [PATCH 33/36] cpuidle,omap3: Use WFI for omap3_pm_idle()

[Tony Lindgren]

o...@users.sourceforge.jp>, Linux-sh list , Fabio 
Estevam , Helge Deller , Daniel Lezcano 
, Jonathan Hunter , Mathieu 
Desnoyers , Frederic Weisbecker 
, Len Brown , "open list:TENSILICA XTENSA 
PORT \(xtensa\)" , Sascha Hauer 
, Vasily Gorbik , linux-arm-msm 
, alpha , 
linux-m68k , Stafford Horne 
, Linux ARM , Chris 
Zankel , Stephen Boyd , Dinh Nguyen 
, Daniel Bristot de Oliveira , 
Alexander Shishkin , lpieral...@kernel.org, 
Rasmus Villemoes , Joel Fernandes <
 j...@joelfernandes.org>, Will Deacon , Boris Ostrovsky 
, Kevin Hilman , 
linux-c...@vger.kernel.org, Pv-drivers , "open 
list:SYNOPSYS ARC ARCHITECTURE" , Mel 
Gorman , jacob.jun@linux.intel.com, Yury Norov 
, Hans Ulli Kroll , Vineet 
Gupta , linux-clk , Josh Triplett 
, Steven Rostedt , 
r...@vger.kernel.org, Borislav Petkov , bc...@quicinc.com, 
Thomas Bogendoerfer , Parisc List 
, Sudeep Holla , Shawn Guo 
, David Miller , Rich Felker 
, Peter Zijlstra , amakha...@vmware.com, 
Bjorn Andersson , "H. Peter Anvin" , sparclinux 
, "open list:QUALCOMM HEXAGON..." , linux-riscv 
, Anton Ivanov 
, Jonas Bonn , Richard 
Weinberger , the arch/x86 maintainers , 
Russell King - ARM Linux , Ingo Molnar 
, Albert Ou , "Paul E. McKenney" 
, Heiko Carstens , Stefan Kristiansson 
, Openrisc , 
Paul Walmsley , "open list:TEGRA ARCHITECTURE 
SUPPORT" , Namhyung Kim , 
Andy Shevchenko , jpoim...@kernel.org, 
Juergen Gross , Michal Simek , "open 
list:BROADCOM NVRAM DRIVER" , Palmer Dabbelt 
, Anup Patel , Ivan Ko
 kshaysky , Johannes Berg 
, linuxppc-dev 
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


* Arnd Bergmann  [220608 18:18]:
> On Wed, Jun 8, 2022 at 4:27 PM Peter Zijlstra  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 :)

> I see similar code in omap2:
> 
> omap2_pm_idle()
>  -> omap2_enter_full_retention()
>  -> omap2_sram_suspend()
> 
> Is that code path safe to use without RCU or does it need a similar change?

Seems like a similar change should be done for omap2. Then anybody who
cares to implement a minimal cpuidle support can do so.

Regards,

Tony

Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()

[Tony Lindgren]

* Geert Uytterhoeven  [210128 09:32]:
> It wasn't.  The regression is that the driver no longer probes at first
> try, because its dependencies are now probed later.  The question is:
> why are the dependencies now probed later?  How to fix that?

I'm afraid that may be unfixable.. It depends on things like the bus
driver probe that might get also deferred.

As suggested, I agree it's best to get rid of builtin_platform_driver_probe
where possible at the cost of dropping the __init as needed.

To me it seems we can't even add a warning to __platform_driver_probe()
if there's drv->driver.of_match_table for example. That warning would
show up on all the devices with driver in question built in even if
the device has no such hardware.

Regards,

Tony

Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()

[Tony Lindgren]

Hi,

* Michael Walle  [210125 19:52]:
> Although I do have the changes for the builtin_platform_driver_probe()
> ready, I don't think it makes much sense to send these unless we agree
> on the increased memory footprint. While there are just a few
> builtin_platform_driver_probe() and memory increase _might_ be
> negligible, there are many more module_platform_driver_probe().

I just noticed this thread today and have pretty much come to the same
conclusions. No need to post a patch for pci-dra7xx.c, I already posted
a patch for pci-dra7xx.c yesterday as part of genpd related changes.

For me probing started breaking as the power-domains property got added.

FYI, it's the following patch:

[PATCH 01/15] PCI: pci-dra7xx: Prepare for deferred probe with 
module_platform_driver

Regards,

Tony

Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h

[Tony Lindgren]

* Boris Brezillon <boris.brezil...@free-electrons.com> [170804 08:30]:
> We are planning to share more code between different NAND based
> devices (SPI NAND, OneNAND and raw NANDs), but before doing that
> we need to move the existing include/linux/mtd/nand.h file into
> include/linux/mtd/rawnand.h so we can later create a nand.h header
> containing all common structure and function prototypes.

For omap:

Acked-by: Tony Lindgren <t...@atomide.com>

Re: [PATCH 37/37] ARM: dts: DRA7: Add pcie1 dt node for EP mode

[Tony Lindgren]

* Kishon Vijay Abraham I  [170112 02:34]:
> Add pcie1 dt node in order for the controller to operate in
> endpoint mode. However since none of the dra7 based boards have
> slots configured to operate in endpoint mode, keep EP mode
> disabled.

Can this be merged separately later on without breaking anything?

Regards,

Tony

Re: [PATCH 36/37] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP

[Tony Lindgren]

* Kishon Vijay Abraham I <kis...@ti.com> [170115 22:06]:
> Hi Tony,
> 
> On Friday 13 January 2017 10:45 PM, Tony Lindgren wrote:
> > * Kishon Vijay Abraham I <kis...@ti.com> [170112 02:35]:
> >> The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should
> >> be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO
> >> in RC mode. However in EP mode, the host system is not able to access the
> >> MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.
> > 
> > I guess ideally in the long run we would set this dynamically based on
> > the selected mode, right?
> 
> The programming sequence mentioned in the TRM w.r.t clock programming is same
> for both host mode or device mode. Though we never faced any issues in host
> mode when HW_AUTO is set, it's better to follow TRM recommended settings IMHO.

OK best to merge this with the whole series:

Acked-by: Tony Lindgren <t...@atomide.com>

Re: [PATCH 36/37] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP

[Tony Lindgren]

* Kishon Vijay Abraham I  [170112 02:35]:
> The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should
> be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO
> in RC mode. However in EP mode, the host system is not able to access the
> MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.

I guess ideally in the long run we would set this dynamically based on
the selected mode, right?

Regards,

Tony

> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  arch/arm/mach-omap2/clockdomains7xx_data.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c 
> b/arch/arm/mach-omap2/clockdomains7xx_data.c
> index 6c67965..67ebff8 100644
> --- a/arch/arm/mach-omap2/clockdomains7xx_data.c
> +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
> @@ -524,7 +524,7 @@
>   .dep_bit  = DRA7XX_PCIE_STATDEP_SHIFT,
>   .wkdep_srcs   = pcie_wkup_sleep_deps,
>   .sleepdep_srcs= pcie_wkup_sleep_deps,
> - .flags= CLKDM_CAN_HWSUP_SWSUP,
> + .flags= CLKDM_CAN_SWSUP,
>  };
>  
>  static struct clockdomain atl_7xx_clkdm = {
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 04/14] ARM: dts: OMAP36xx: : DT spelling s/#address-cell/#address-cells/

[Tony Lindgren]

* Rob Herring  [160420 16:48]:
> On Wed, Apr 20, 2016 at 10:32 AM, Geert Uytterhoeven
>  wrote:
> > Signed-off-by: Geert Uytterhoeven 
> > ---
> >  arch/arm/boot/dts/omap36xx.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/omap36xx.dtsi 
> > b/arch/arm/boot/dts/omap36xx.dtsi
> > index ce1e242d4dc07ea8..8b797915300894d8 100644
> > --- a/arch/arm/boot/dts/omap36xx.dtsi
> > +++ b/arch/arm/boot/dts/omap36xx.dtsi
> > @@ -44,7 +44,7 @@
> > abb_mpu_iva: regulator-abb-mpu {
> > compatible = "ti,abb-v1";
> > regulator-name = "abb_mpu_iva";
> > -   #address-cell = <0>;
> > +   #address-cells = <0>;
> 
> dtc should flag this if it was really needed. However, it looks like
> it isn't as there are no child nodes (unless the board files add
> them).
> 
> A nice dtc check would be to flag unnecessary #address-cells or
> #size-cells. That would only help here after your fix though.

Yeah. Applying patches 2 - 4 into omap-for-v4.7/dt thanks.

Tony
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 00/25] irq_domain generalization and refinement

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [120204 14:00]:
 
 Actually, it turns out to be not that hard, because twl doesn't actually
 make use of the IRQ domain stuff:
 
 commit aeb5032b3f8b9ab69daa545777433fa94b3494c4
 Author: Benoit Cousson b-cous...@ti.com
 AuthorDate: Mon Aug 29 16:20:23 2011 +0200
 Commit: Samuel Ortiz sa...@linux.intel.com
 CommitDate: Mon Jan 9 00:37:40 2012 +0100
 
 mfd: twl-core: Add initial DT support for twl4030/twl6030
 
 [grant.lik...@secretlab.ca: Fix IRQ_DOMAIN dependency in kconfig]
 
 Adding any dependency - especially one which wouldn't be enabled - for
 a new feature which wasn't required before is going to break existing
 users, so this shouldn't have been done in the first place.
 
 A better fix to preserve existing users would've been as below - yes
 it means more ifdefs, but if irq domain is to remain a DT only thing
 then we're going to end up with _lots_ of this stuff.
 
 I'd much prefer to see irq domain become more widely available so it
 doesn't require these ifdefs everywhere.

Your patch below looks like a correct fix to me to the problem
you and Grazvydas are seeing:

Acked-by: Tony Lindgren t...@atomide.com
 
  drivers/mfd/Kconfig|2 +-
  drivers/mfd/twl-core.c |4 
  2 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
 index 28a301b..bd60ce0 100644
 --- a/drivers/mfd/Kconfig
 +++ b/drivers/mfd/Kconfig
 @@ -200,7 +200,7 @@ config MENELAUS
  
  config TWL4030_CORE
   bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support
 - depends on I2C=y  GENERIC_HARDIRQS  IRQ_DOMAIN
 + depends on I2C=y  GENERIC_HARDIRQS
   help
 Say yes here if you have TWL4030 / TWL6030 family chip on your board.
 This core driver provides register access and IRQ handling
 diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
 index e04e04d..5913aaa 100644
 --- a/drivers/mfd/twl-core.c
 +++ b/drivers/mfd/twl-core.c
 @@ -263,7 +263,9 @@ struct twl_client {
  
  static struct twl_client twl_modules[TWL_NUM_SLAVES];
  
 +#ifdef CONFIG_IRQ_DOMAIN
  static struct irq_domain domain;
 +#endif
  
  /* mapping the module id to slave id and base address */
  struct twl_mapping {
 @@ -1226,6 +1228,7 @@ twl_probe(struct i2c_client *client, const struct 
 i2c_device_id *id)
   pdata-irq_base = status;
   pdata-irq_end = pdata-irq_base + nr_irqs;
  
 +#ifdef CONFIG_IRQ_DOMAIN
   domain.irq_base = pdata-irq_base;
   domain.nr_irq = nr_irqs;
  #ifdef CONFIG_OF_IRQ
 @@ -1233,6 +1236,7 @@ twl_probe(struct i2c_client *client, const struct 
 i2c_device_id *id)
   domain.ops = irq_domain_simple_ops;
  #endif
   irq_domain_add(domain);
 +#endif
  
   if (i2c_check_functionality(client-adapter, I2C_FUNC_I2C) == 0) {
   dev_dbg(client-dev, can't talk I2C?\n);
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support

[Tony Lindgren]

* Stephen Boyd sb...@codeaurora.org [101207 11:00]:
 On 12/01/2010 12:20 PM, Stephen Boyd wrote:
  Definitely for TX since it seems like a redundant loop, but I agree RX
  code has changed. Instead of
 
  If RX buffer full
  Poll for RX buffer full
  Read character from RX buffer
 
  we would have
 
  If RX buffer full
  Read character from RX buffer
 
  which doesn't seem all that different assuming the RX buffer doesn't go
  from full to empty between the If and Poll steps. Hopefully Tony knows more.
 
 
 Tony, any thoughts?

Sorry for the delay, looks like I'm only 1 month behind with email..
Sounds like it should work to me. I can try it out if you point me
to a patch.

Regards,

Tony
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev