linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Neuling <mikey@neuling.org>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	bg-linux@lists.anl-external.org
Subject: Re: [PATCH 3/7] [RFC] add support for BlueGene/P FPU
Date: Thu, 19 May 2011 15:58:38 +1000	[thread overview]
Message-ID: <425.1305784718@neuling.org> (raw)
In-Reply-To: <1305753895-24845-3-git-send-email-ericvh@gmail.com>

Eric,

> This patch adds save/restore register support for the BlueGene/P
> double hummer FPU.

What does this mean?  Needs more details here.

> Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
> ---
>  arch/powerpc/include/asm/ppc_asm.h |   39 ++++++++++++++++++++++++----------
-
>  arch/powerpc/kernel/fpu.S          |    8 +++---
>  arch/powerpc/platforms/44x/Kconfig |    9 ++++++++
>  3 files changed, 40 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/pp
c_asm.h
> index 9821006..daa22bb 100644
> --- a/arch/powerpc/include/asm/ppc_asm.h
> +++ b/arch/powerpc/include/asm/ppc_asm.h
> @@ -88,6 +88,13 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
>  				REST_10GPRS(22, base)
>  #endif
>  
> +#ifdef CONFIG_BGP
> +#define LFPDX(frt, ra, rb)	.long (31<<26)|((frt)<<21)|((ra)<<16)| \
> +							((rb)<<11)|(462<<1)
> +#define STFPDX(frt, ra, rb)	.long (31<<26)|((frt)<<21)|((ra)<<16)| \
> +							((rb)<<11)|(974<<1)
> +#endif /* CONFIG_BGP */

Put these in arch/powerpc/include/asm/ppc-opcode.h and reformat to fit
whats there already.  

Also, don't need to put these defines inside a #ifdef.

> +
>  #define SAVE_2GPRS(n, base)	SAVE_GPR(n, base); SAVE_GPR(n+1, base)
>  #define SAVE_4GPRS(n, base)	SAVE_2GPRS(n, base); SAVE_2GPRS(n+2, base)
>  #define SAVE_8GPRS(n, base)	SAVE_4GPRS(n, base); SAVE_4GPRS(n+4, base)
> @@ -97,18 +104,26 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
>  #define REST_8GPRS(n, base)	REST_4GPRS(n, base); REST_4GPRS(n+4, base)
>  #define REST_10GPRS(n, base)	REST_8GPRS(n, base); REST_2GPRS(n+8, base)
>  
> -#define SAVE_FPR(n, base)	stfd	n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> -#define SAVE_2FPRS(n, base)	SAVE_FPR(n, base); SAVE_FPR(n+1, base)
> -#define SAVE_4FPRS(n, base)	SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base)
> -#define SAVE_8FPRS(n, base)	SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base)
> -#define SAVE_16FPRS(n, base)	SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base)
> -#define SAVE_32FPRS(n, base)	SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base)
> -#define REST_FPR(n, base)	lfd	n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> -#define REST_2FPRS(n, base)	REST_FPR(n, base); REST_FPR(n+1, base)
> -#define REST_4FPRS(n, base)	REST_2FPRS(n, base); REST_2FPRS(n+2, base)
> -#define REST_8FPRS(n, base)	REST_4FPRS(n, base); REST_4FPRS(n+4, base)
> -#define REST_16FPRS(n, base)	REST_8FPRS(n, base); REST_8FPRS(n+8, base)
> -#define REST_32FPRS(n, base)	REST_16FPRS(n, base); REST_16FPRS(n+16, base)
> +#ifdef CONFIG_BGP
> +#define SAVE_FPR(n, b, base)	li b, THREAD_FPR0+(16*(n)); STFPDX(n, base, b)
> +#define REST_FPR(n, b, base)	li b, THREAD_FPR0+(16*(n)); LFPDX(n, base, b)

16*?  Are these FP regs 64 or 128 bits wide?  If 128 you are doing to
have to play with TS_WIDTH to get the size of the FPs correct in the
thread_struct.

I think there's a bug here.

> +#else /* CONFIG_BGP */
> +#define SAVE_FPR(n, b, base)	(stfd	n, THREAD_FPR0+8*TS_FPRWIDTH*(n)(base))
> +#define REST_FPR(n, b, base)	(lfd	n, THREAD_FPR0+8*TS_FPRWIDTH*(n)(base))
> +#endif /* CONFIG_BGP */
> +
> +#define SAVE_2FPRS(n, b, base)	SAVE_FPR(n, b, base); SAVE_FPR(n+1, b, 
base)
> +#define SAVE_4FPRS(n, b, base)	SAVE_2FPRS(n, b, base); SAVE_2FPRS(n+2,
 b, base)
> +#define SAVE_8FPRS(n, b, base)	SAVE_4FPRS(n, b, base); SAVE_4FPRS(n+4,
 b, base)
> +#define SAVE_16FPRS(n, b, base)	SAVE_8FPRS(n, b, base); SAVE_8FPRS(n+8,
 b, base)
> +#define SAVE_32FPRS(n, b, base)	SAVE_16FPRS(n, b, base); \
> +				SAVE_16FPRS(n+16, b, base)
> +#define REST_2FPRS(n, b, base)	REST_FPR(n, b, base); REST_FPR(n+1, b, 
base)
> +#define REST_4FPRS(n, b, base)	REST_2FPRS(n, b, base); REST_2FPRS(n+2,
 b, base)
> +#define REST_8FPRS(n, b, base)	REST_4FPRS(n, b, base); REST_4FPRS(n+4,
 b, base)
> +#define REST_16FPRS(n, b, base)	REST_8FPRS(n, b, base); REST_8FPRS(n+8,
 b, base)
> +#define REST_32FPRS(n, b, base)	REST_16FPRS(n, b, base); \
> +				REST_16FPRS(n+16, b, base)
>  
>  #define SAVE_VR(n,b,base)	li b,THREAD_VR0+(16*(n));  stvx n,base,b
>  #define SAVE_2VRS(n,b,base)	SAVE_VR(n,b,base); SAVE_VR(n+1,b,base)
> diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
> index de36955..9f11c66 100644
> --- a/arch/powerpc/kernel/fpu.S
> +++ b/arch/powerpc/kernel/fpu.S
> @@ -30,7 +30,7 @@
>  BEGIN_FTR_SECTION							\
>  	b	2f;							\
>  END_FTR_SECTION_IFSET(CPU_FTR_VSX);					\
> -	REST_32FPRS(n,base);						\
> +	REST_32FPRS(n,c,base);						\
>  	b	3f;							\
>  2:	REST_32VSRS(n,c,base);						\
>  3:
> @@ -39,13 +39,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX);		
			\
>  BEGIN_FTR_SECTION							\
>  	b	2f;							\
>  END_FTR_SECTION_IFSET(CPU_FTR_VSX);					\
> -	SAVE_32FPRS(n,base);						\
> +	SAVE_32FPRS(n,c,base);						\
>  	b	3f;							\
>  2:	SAVE_32VSRS(n,c,base);						\
>  3:
>  #else
> -#define REST_32FPVSRS(n,b,base)	REST_32FPRS(n, base)
> -#define SAVE_32FPVSRS(n,b,base)	SAVE_32FPRS(n, base)
> +#define REST_32FPVSRS(n,b,base)	REST_32FPRS(n,b,base)
> +#define SAVE_32FPVSRS(n,b,base)	SAVE_32FPRS(n,b,base)
>  #endif
>  
>  /*
> diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/
Kconfig
> index f485fc5f..24a515e 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -169,6 +169,15 @@ config YOSEMITE
>  	help
>  	  This option enables support for the AMCC PPC440EP evaluation board.
>  
> +config	BGP

Does this FPU feature have a specific name like double hammer?  I'd
rather have the BGP defconfig depend on PPC_FPU_DOUBLE_HUMMER, or
something like that...

> +	bool "Blue Gene/P"
> +	depends on 44x
> +	default n
> +	select PPC_FPU
> +	select PPC_DOUBLE_FPU

... in fact, it seem you are doing something like these here but you
don't use PPC_DOUBLE_FPU anywhere?

Mikey

> +	help
> +	  This option enables support for the IBM BlueGene/P supercomputer.
> +
>  config ISS4xx
>  	bool "ISS 4xx Simulator"
>  	depends on (44x || 40x)
> -- 
> 1.7.4.1
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 

  reply	other threads:[~2011-05-19  5:58 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-18 21:24 [PATCH 1/7] [RFC] Mainline BG/P platform support Eric Van Hensbergen
2011-05-18 21:24 ` [PATCH 2/7] [RFC] add bluegene entry to cputable Eric Van Hensbergen
2011-05-20  0:35   ` Benjamin Herrenschmidt
2011-05-20  1:08     ` Eric Van Hensbergen
2011-05-20  1:50       ` Benjamin Herrenschmidt
2011-05-18 21:24 ` [PATCH 3/7] [RFC] add support for BlueGene/P FPU Eric Van Hensbergen
2011-05-19  5:58   ` Michael Neuling [this message]
2011-05-19 13:53     ` Eric Van Hensbergen
2011-05-19 15:22       ` [bg-linux] " Kazutomo Yoshii
2011-05-19 21:36       ` Michael Neuling
2011-05-19 21:55         ` Eric Van Hensbergen
2011-05-19 23:16           ` Michael Neuling
2011-05-20  0:30             ` Eric Van Hensbergen
2011-05-20  0:43               ` Michael Neuling
2011-05-20  0:53       ` Benjamin Herrenschmidt
2011-05-20  0:52     ` Benjamin Herrenschmidt
2011-05-19 21:41   ` [PATCH 3/7] [RFC][V2] add support for BlueGene/P Double FPU Eric Van Hensbergen
2011-05-18 21:24 ` [PATCH 4/7] [RFC] enable L1_WRITETHROUGH mode for BG/P Eric Van Hensbergen
2011-05-19 10:43   ` Josh Boyer
2011-05-19 12:53     ` Eric Van Hensbergen
2011-05-19 21:42   ` [PATCH 4/7] [RFC][V2] enable BGP_L1_WRITETHROUGH " Eric Van Hensbergen
2011-05-20  1:01   ` [PATCH 4/7] [RFC] enable L1_WRITETHROUGH " Benjamin Herrenschmidt
2011-05-18 21:24 ` [PATCH 5/7] [RFC] force 32-byte aligned kmallocs Eric Van Hensbergen
2011-05-20  0:36   ` Benjamin Herrenschmidt
2011-05-20  0:47     ` Eric Van Hensbergen
2011-05-20  1:50       ` Benjamin Herrenschmidt
2011-05-20  1:32     ` [bg-linux] " Kazutomo Yoshii
2011-05-20  2:08       ` Benjamin Herrenschmidt
2011-05-20  2:13         ` Benjamin Herrenschmidt
2011-05-20  3:02           ` Kazutomo Yoshii
2011-05-20  3:13             ` Benjamin Herrenschmidt
2011-05-18 21:24 ` [PATCH 6/7] [RFC] enable early TLBs for BG/P Eric Van Hensbergen
2011-05-20  0:39   ` Benjamin Herrenschmidt
2011-05-20  1:21     ` Eric Van Hensbergen
2011-05-20  1:54       ` Benjamin Herrenschmidt
2011-05-20  3:38         ` [bg-linux] " Kazutomo Yoshii
2011-05-20  3:52           ` Benjamin Herrenschmidt
2011-05-20 13:01             ` Eric Van Hensbergen
2011-05-20 22:20               ` Benjamin Herrenschmidt
2011-05-18 21:24 ` [PATCH 7/7] [RFC] SMP support code Eric Van Hensbergen
2011-05-20  1:05   ` Benjamin Herrenschmidt
2011-05-19 11:01 ` [PATCH 1/7] [RFC] Mainline BG/P platform support Josh Boyer
2011-05-19 12:35   ` Eric Van Hensbergen

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=425.1305784718@neuling.org \
    --to=mikey@neuling.org \
    --cc=bg-linux@lists.anl-external.org \
    --cc=ericvh@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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).