linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2] ARM: BCM5301X: Implement SMP support
Date: Thu, 26 Mar 2015 12:00:26 +0000	[thread overview]
Message-ID: <20150326120026.GF8656@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1427030415-31721-1-git-send-email-zajec5@gmail.com>

On Sun, Mar 22, 2015 at 02:20:15PM +0100, Rafa? Mi?ecki wrote:
> +/*
> + * BCM5301X specific entry point for secondary CPUs.
> + */
> +ENTRY(bcm5301x_secondary_startup)
> +	mrc	p15, 0, r0, c0, c0, 5
> +	and	r0, r0, #15
> +	adr	r4, 1f
> +	ldmia	r4, {r5, r6}
> +	sub	r4, r4, r5
> +	add	r6, r6, r4
> +pen:	ldr	r7, [r6]
> +	cmp	r7, r0
> +	bne	pen
> +
> +	/*
> +	 * In case L1 cache has unpredictable contents at power-up
> +	 * clean its contents without flushing.
> +	 */
> +	bl      v7_invalidate_l1
> +
> +	mov	r0, #0
> +	mcr	p15, 0, r0, c7, c5, 0	/* Invalidate icache */
> +	dsb
> +	isb

So if your I-cache contains unpredictable contents, how do you execute
the code to this point?  Shouldn't the I-cache invalidate be the very
first instruction you execute followed by the dsb and isb (oh, and iirc
it ignores the value in the register).

In the case where a CPU has unpredictable contents at power up, the
ARM ARM requires that an implementation specific sequence is followed
to initialise the caches.  I doubt that such a sequence includes testing
a pen value.

> +	sysram_base_addr = of_iomap(node, 0);
> +	if (!sysram_base_addr) {
> +		pr_warn("Failed to map sysram\n");
> +		return;
> +	}
> +
> +	writel(virt_to_phys(entry_point), sysram_base_addr + SOC_ROM_LUT_OFF);
> +
> +	dsb_sev();	/* Exit WFI */

Which WFI?  This seems to imply that you have some kind of initial
firmware.  If so, that should be taking care of the cache initialisation,
not the kernel.

> +	mb();		/* make sure write buffer is drained */

writel() already ensures that.

> +	/*
> +	 * The secondary processor is waiting to be released from
> +	 * the holding pen - release it, then wait for it to flag
> +	 * that it has been released by resetting pen_release.
> +	 *
> +	 * Note that "pen_release" is the hardware CPU ID, whereas
> +	 * "cpu" is Linux's internal ID.
> +	 */
> +	write_pen_release(cpu_logical_map(cpu));
> +
> +	 /* Send the secondary CPU SEV */
> +	dsb_sev();

If you even need any of the pen code, if you're having to send a SEV here,
wouldn't having a WFE in the pen assembly loop above be a good idea?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2015-03-26 12:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10 20:32 [PATCH RFC] ARM: BCM5301X: Implement SMP support Rafał Miłecki
2015-02-13 11:54 ` Hauke Mehrtens
2015-02-13 12:29 ` Mark Rutland
2015-02-19 22:32 ` [PATCH] " Rafał Miłecki
2015-03-11 21:23   ` Rafał Miłecki
2015-03-16 16:52   ` Florian Fainelli
2015-03-22 13:20   ` [PATCH V2] " Rafał Miłecki
2015-03-26 12:00     ` Russell King - ARM Linux [this message]
2015-10-13 22:29       ` Hauke Mehrtens
2015-10-13 22:48         ` Ray Jui
2015-10-14 13:42           ` Kapil Hali
2015-10-14 18:22             ` Hauke Mehrtens
2015-10-15 15:50               ` Kapil Hali
2015-10-22 20:30               ` Jon Mason
2015-10-23 22:36                 ` Hauke Mehrtens
2015-10-15  8:17         ` Russell King - ARM Linux

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=20150326120026.GF8656@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).