On 10/06/2022 15:33, Shahab Vahedi via buildroot wrote:
If on the host machine the "co-re" is supported, bpftool will
build a bootstrap version of itself as well. In that case, the
cross compilation can fail. This commit adds a patch to remedy
that. The fix that you see here is already upsteam
On Jun 13, 2022, at 11:48 AM, Srivatsa S. Bhat wrote:
> ⚠ External Email
>
> On 6/8/22 4:27 PM, Peter Zijlstra wrote:
>> vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wbinvd()
>> leaves .noinstr.text section
>> vmlinux.o: warning: objtool: default_idle+0x4: call to arch_safe
On 6/8/22 4:27 PM, Peter Zijlstra wrote:
> vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wbinvd()
> leaves .noinstr.text section
> vmlinux.o: warning: objtool: default_idle+0x4: call to arch_safe_halt()
> leaves .noinstr.text section
> vmlinux.o: warning: objtool: xen_safe_hal
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,
* 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
* 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_rc
* 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
_
* 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
___
linux-snps-arc mailing list
linux-snps-arc@lists.infrad
On Thu, Jun 09, 2022 at 04:49:21PM -0700, Jacob Pan wrote:
> Hi Peter,
>
> On Wed, 08 Jun 2022 16:27:27 +0200, Peter Zijlstra
> wrote:
>
> > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > Xeons") wrecked intel_idle in two ways:
> >
> > - must not have tracing in idle func
On Mon, Jun 13, 2022 at 04:26:01PM +0800, Lai Jiangshan wrote:
> On Wed, Jun 8, 2022 at 10:48 PM Peter Zijlstra wrote:
> >
> > Now that arch_cpu_idle() is expected to return with IRQs disabled,
> > avoid the useless STI/CLI dance.
> >
> > Per the specs this is supposed to work, but nobody has yet
On Wed, Jun 8, 2022 at 10:48 PM Peter Zijlstra wrote:
>
> Now that arch_cpu_idle() is expected to return with IRQs disabled,
> avoid the useless STI/CLI dance.
>
> Per the specs this is supposed to work, but nobody has yet relied up
> this behaviour so broken implementations are possible.
I'm tot
11 matches
Mail list logo
