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/
next prev parent 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 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).