mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Ramin Moussavi" <ramin.moussavi@yacoub.de>,
	"Andreas Larsson" <andreas@gaisler.com>,
	"David S . Miller" <davem@davemloft.net>
Cc: "Thomas Gleixner" <tglx@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] sparc32: wait for secondary CPUs by time, not by loop count
Date: Thu, 15 Oct 2026 11:09:13 +0200	[thread overview]
Message-ID: <26e4d054-c1d6-4422-962c-e123269d36a9@app.fastmail.com> (raw)
In-Reply-To: <20261015085545.3246951-3-ramin.moussavi@yacoub.de>

On Thu, Oct 15, 2026, at 10:55, Ramin Moussavi wrote:
> smp4m_boot_one_cpu(), smp4d_boot_one_cpu() and leon_boot_one_cpu() give
> a starting CPU 10000 rounds of udelay(200) to show up in cpu_callin_map,
> which is meant to be two seconds. But udelay() is only as long as
> loops_per_jiffy says. Under qemu the delay loop calibration varies from
> boot to boot depending on host load -- on an emulated SPARCstation 20
> between 4 and 671 BogoMIPS for the same kernel and command line -- and
> with a low value the wait shrinks to a few milliseconds. The boot CPU
> then reports
>

The patch is not wrong, but having a broken udelay() is still problematic
in other places, so it may be better to fix that instead.

On most modern targets, we tend to just use the cycle counter if the
frequency is known and avoid the delay loop calibration entirely.
Any reason that sparc32 still needs the calibration?

     Arnd

  reply	other threads:[~2026-10-15  9:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15  8:55 [PATCH 0/4] sparc32: SMP fixes, futexes on SMP, and a cmpxchg system call Ramin Moussavi
2026-10-15  8:55 ` [PATCH 1/4] sparc32: keep PIL raised until the IRQ frame is gone Ramin Moussavi
2026-10-15 10:48   ` Magnus Lindholm
2026-10-15 12:20   ` Andreas Larsson
2026-10-15  8:55 ` [PATCH 2/4] sparc32: wait for secondary CPUs by time, not by loop count Ramin Moussavi
2026-10-15  9:09   ` Arnd Bergmann [this message]
2026-10-15 13:43     ` Ramin Moussavi
2026-10-15  8:55 ` [PATCH 3/4] sparc32: implement futex atomics, with casa detected at run time Ramin Moussavi
2026-10-15  9:23   ` Arnd Bergmann
2026-10-15  9:28     ` John Paul Adrian Glaubitz
2026-10-15  9:45       ` Arnd Bergmann
2026-10-15  8:55 ` [PATCH 4/4] sparc32: add the sparc_atomic_cmpxchg_32 system call Ramin Moussavi
2026-10-15  9:21   ` Arnd Bergmann
2026-10-15  9:36     ` John Paul Adrian Glaubitz
2026-10-15  9:36 ` [PATCH 0/4] sparc32: SMP fixes, futexes on SMP, and a cmpxchg " Magnus Lindholm
2026-10-15 14:15   ` Ramin Moussavi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26e4d054-c1d6-4422-962c-e123269d36a9@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=andreas@gaisler.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=peterz@infradead.org \
    --cc=ramin.moussavi@yacoub.de \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®