All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: David Daney <ddaney@caviumnetworks.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH v3] Virtual memory size detection for 64 bit MIPS CPUs
Date: Tue, 2 Feb 2010 12:42:59 +0100	[thread overview]
Message-ID: <20100202114259.GA10837@linux-mips.org> (raw)
In-Reply-To: <20100202001026.GA6883@ericsson.com>

On Mon, Feb 01, 2010 at 04:10:26PM -0800, Guenter Roeck wrote:

> > > +	if (cpu_has_64bits) {
> > > +		write_c0_entryhi(0xfffffffffffff000ULL);
> > 
> > macro indicated that we need to avoid hazards here on R4000.

A MTC0 instruction on an R4000 writes EntryHi on pipeline stage 7 but
will read from the same register on stage 4 which leaves a window of
2 instructions, that is 2 NOP instructions needed.

> > Perhaps adding:
> > 
> >   	back_to_back_c0_hazard();
> > 
> Compiler already added a nop, so I thought it wasn't necessary.
> Doesn't hurt either, so I'll put it in.

This probe is needed as per MIPSxx architecture spec and several CPUs will
missbehave without it.  The 74K which of course is 32-bit but it
illustrates the issue might even issue these instructions out of order.
back_to_back_c0_hazard will expand into a suitable sequence to handle
the pipeline hazard.  And we can't trust on the compiler doing the right
thing here; as explained above we might need multiple nops and some CPUs
will need other instructions to deal with the hazard, for example a number
of SSNOPs or an EHB instruction.

  Ralf

  reply	other threads:[~2010-02-02 11:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-01 22:51 [PATCH v3] Virtual memory size detection for 64 bit MIPS CPUs Guenter Roeck
2010-02-01 23:44 ` David Daney
2010-02-02  0:10   ` Guenter Roeck
2010-02-02 11:42     ` Ralf Baechle [this message]
2010-02-02 15:24       ` Maciej W. Rozycki

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=20100202114259.GA10837@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=ddaney@caviumnetworks.com \
    --cc=guenter.roeck@ericsson.com \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.