On 07/09/2023 15:34, Mark Rutland wrote:
> We attempt to initialize each CPU's arch_timer event stream in
> arch_timer_evtstrm_enable(), which we call from the
> arch_timer_starting_cpu() cpu hotplug callback which is registered early
> in boot. As this is registered before we initialize the system cpucaps,
> the test for ARM64_HAS_ECV will always be false for CPUs present at boot
> time, and will only be taken into account for CPUs onlined late
> (including those which are hotplugged out and in again).
>
> Due to this, CPUs present and boot time may not use the intended divider
> and scale factor to generate the event stream, and may differ from other
> CPUs.
>
> Correct this by only initializing the event stream after cpucaps have been
> finalized, registering a separate CPU hotplug callback for the event stream
> configuration. Since the caps must be finalized by this point, use
> spus_have_final_cap() to verify this.
>
> Signed-off-by: Mark Rutland <[email protected]>
> Cc: Daniel Lezcano <[email protected]>
> Cc: Marc Zyngier <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> ---
Applied thanks
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Hi Daniel,
On Wed, Oct 11, 2023 at 10:30:39AM +0200, Daniel Lezcano wrote:
> On 07/09/2023 15:34, Mark Rutland wrote:
> > We attempt to initialize each CPU's arch_timer event stream in
> > arch_timer_evtstrm_enable(), which we call from the
> > arch_timer_starting_cpu() cpu hotplug callback which is registered early
> > in boot. As this is registered before we initialize the system cpucaps,
> > the test for ARM64_HAS_ECV will always be false for CPUs present at boot
> > time, and will only be taken into account for CPUs onlined late
> > (including those which are hotplugged out and in again).
> >
> > Due to this, CPUs present and boot time may not use the intended divider
> > and scale factor to generate the event stream, and may differ from other
> > CPUs.
> >
> > Correct this by only initializing the event stream after cpucaps have been
> > finalized, registering a separate CPU hotplug callback for the event stream
> > configuration. Since the caps must be finalized by this point, use
> > spus_have_final_cap() to verify this.
> >
> > Signed-off-by: Mark Rutland <[email protected]>
> > Cc: Daniel Lezcano <[email protected]>
> > Cc: Marc Zyngier <[email protected]>
> > Cc: Thomas Gleixner <[email protected]>
> > ---
>
> Applied thanks
This got folded into a larger series that we were hoping to take through the arm64 tree:
https://lore.kernel.org/linux-arm-kernel/[email protected]/
https://lore.kernel.org/linux-arm-kernel/[email protected]/
I think that won't conflict, since all that's changed is the commit text, but
it might be worth dropping this patch for now to avoid the risk of a conflict.
Thanks,
Mark.
On 11/10/2023 11:36, Mark Rutland wrote:
> Hi Daniel,
>
> On Wed, Oct 11, 2023 at 10:30:39AM +0200, Daniel Lezcano wrote:
>> On 07/09/2023 15:34, Mark Rutland wrote:
>>> We attempt to initialize each CPU's arch_timer event stream in
>>> arch_timer_evtstrm_enable(), which we call from the
>>> arch_timer_starting_cpu() cpu hotplug callback which is registered early
>>> in boot. As this is registered before we initialize the system cpucaps,
>>> the test for ARM64_HAS_ECV will always be false for CPUs present at boot
>>> time, and will only be taken into account for CPUs onlined late
>>> (including those which are hotplugged out and in again).
>>>
>>> Due to this, CPUs present and boot time may not use the intended divider
>>> and scale factor to generate the event stream, and may differ from other
>>> CPUs.
>>>
>>> Correct this by only initializing the event stream after cpucaps have been
>>> finalized, registering a separate CPU hotplug callback for the event stream
>>> configuration. Since the caps must be finalized by this point, use
>>> spus_have_final_cap() to verify this.
>>>
>>> Signed-off-by: Mark Rutland <[email protected]>
>>> Cc: Daniel Lezcano <[email protected]>
>>> Cc: Marc Zyngier <[email protected]>
>>> Cc: Thomas Gleixner <[email protected]>
>>> ---
>>
>> Applied thanks
>
> This got folded into a larger series that we were hoping to take through the arm64 tree:
>
> https://lore.kernel.org/linux-arm-kernel/[email protected]/
> https://lore.kernel.org/linux-arm-kernel/[email protected]/
>
> I think that won't conflict, since all that's changed is the commit text, but
> it might be worth dropping this patch for now to avoid the risk of a conflict.
Sure, thanks for letting me know. I was suspecting that was the case :)
I've dropped it
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
On Wed, Oct 11, 2023 at 12:06:20PM +0200, Daniel Lezcano wrote:
> On 11/10/2023 11:36, Mark Rutland wrote:
> > On Wed, Oct 11, 2023 at 10:30:39AM +0200, Daniel Lezcano wrote:
> > > Applied thanks
> >
> > This got folded into a larger series that we were hoping to take through the arm64 tree:
> >
> > https://lore.kernel.org/linux-arm-kernel/[email protected]/
> > https://lore.kernel.org/linux-arm-kernel/[email protected]/
> >
> > I think that won't conflict, since all that's changed is the commit text, but
> > it might be worth dropping this patch for now to avoid the risk of a conflict.
>
> Sure, thanks for letting me know. I was suspecting that was the case :)
>
> I've dropped it
Thanks, and sorry for the hassle!
Mark.