From: will schmidt <will_schmidt@vnet•ibm.com>
To: Kumar Gala <kumar.gala@freescale•com>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs•org>,
ppc64-dev <linuxppc64-dev@ozlabs•org>
Subject: Re: RFC: merging of cputables between ppc32/64
Date: Thu, 08 Sep 2005 15:43:04 -0500 [thread overview]
Message-ID: <4320A258.1080706@vnet.ibm.com> (raw)
In-Reply-To: <268E83D3-853C-4752-88D1-A7354E924C07@freescale.com>
Kumar Gala wrote:
> I was hoping to get some idea on which direction we wanted to head with
> cputable between ppc32/64. The only major difference that exists
> between the two is the use of cpu_setup().
>
> On ppc32, cpu_setup is called for each processor in an SMP
> configuration. Which gives us the following signature:
>
> typedef void (*cpu_setup_t)(unsigned long offset, int cpu_nr, struct
> cpu_spec* spec);
>
> On ppc64, cpu_setup is only called for the boot cpu. It is left to the
Yeah, at the time, we figured all cpu's in a system would be the same.
with the merge of 32/64, is this still going to be the case?
> cpu save/restore functions to handle setting up the state for
> additional CPUs. Which gives is the following signature:
>
> typedef void (*cpu_setup_t)(unsigned long offset, struct cpu_spec* spec);
>
> So my question is do we just extend the ppc64 signature to match the
> ppc32 by having a dummy "int cpu_nr" that is ignored or do we do
> something else? As far as I can tell cpu_nr is only used by ppc32 as
> temp storage so that the cpu_setup functions can return properly.
If cpu_nr is just used as temp storage, then can it be removed and
replaced with a local variable?
>
> - kumar
> _______________________________________________
> Linuxppc64-dev mailing list
> Linuxppc64-dev@ozlabs•org
> https://ozlabs.org/mailman/listinfo/linuxppc64-dev
prev parent reply other threads:[~2005-09-08 20:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-08 18:42 RFC: merging of cputables between ppc32/64 Kumar Gala
2005-09-08 20:43 ` will schmidt [this message]
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=4320A258.1080706@vnet.ibm.com \
--to=will_schmidt@vnet$(echo .)ibm.com \
--cc=kumar.gala@freescale$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=linuxppc64-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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