All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Hollis Blanchard <hollis@austin.ibm.com>
Cc: paulus@samba.org, devel list <linuxppc-dev@lists.linuxppc.org>
Subject: Re: get_pteptr prototype
Date: Fri, 10 Jan 2003 11:42:43 +1100	[thread overview]
Message-ID: <20030110004243.GB19829@zax.zax> (raw)
In-Reply-To: <1042127751.1021.221.camel@granite.austin.ibm.com>


On Thu, Jan 09, 2003 at 09:55:40AM -0600, Hollis Blanchard wrote:
>
> On Wed, 2003-01-08 at 20:33, David Gibson wrote:
> >
> > Hmm... what's the reason that wakeup_info needs to be reserved in
> > head_4xx.S, rather than just being a normal variable in the data area
> > (which should be writable anyway)?  Its not obvious to me from the
> > patch.
>
> Sorry, I was hoping the Documentation file explained it well enough. On
> wake the firmware needs to transfer control back to Linux, so the
> firmware needs to know where to jump to. The only way I could think of
> communicating that information was with a fixed memory location known to
> both the firmware and to Linux. In future processors there will be a
> scratch register (whose contents are saved during sleep) to solve this
> problem.

Ah, ok - I only skimmed the patch I'm afraid, so I didn't notice that.

> > Actually, skimming through the patch I noticed a minor nit: you only
> > have one .long in head_4xx.S reserving space for the wakeup_info
> > struct which is 3 words long.  In practice the . = in the exception
> > handlers will give you plenty of space, but I think it would be good
> > form to explicitly reserve the right amount of space.
>
> It's just a (physical) pointer to the structure which is elsewhere in
> memory (actually on the stack).

Hmm... in that case, why does the pointer need to be updated at
runtime: could you just statically allocate the real structure (in the
data segment), and have the value at 0xc00000fc filled in constant at
link time.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2003-01-10  0:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-06 22:59 get_pteptr prototype Hollis Blanchard
2003-01-07  0:57 ` David Gibson
2003-01-08 15:48   ` Hollis Blanchard
2003-01-08 23:49     ` David Gibson
2003-01-09  0:11       ` Hollis Blanchard
2003-01-09  2:33         ` David Gibson
2003-01-09 15:55           ` Hollis Blanchard
2003-01-10  0:42             ` David Gibson [this message]
     [not found]         ` <1042107732.567.2.camel@zion.wanadoo.fr>
2003-01-09 16:53           ` 405LP sleep, no PTEs (was: get_pteptr prototype) Hollis Blanchard

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=20030110004243.GB19829@zax.zax \
    --to=david@gibson.dropbear.id.au \
    --cc=hollis@austin.ibm.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=paulus@samba.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.