[RFC] Add IBM Blue Gene/Q Platform

[RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

Rather than flood the mailing list with the patches, I've arranged for a =
git repo to hold the changesets.
You can find the repo here:
  <https://github.com/jimix/linux-bgq>

They are against GregKH's linux-stable.git long-term 3.4.y (y=3D22) =
branch.
The first 9 (6e58088f..) effect common code and the rest are BGQ =
specific.

Here is a are the summary logs:

$ git log --reverse linux-stable/linux-3.4.y..
commit 5a8edb2bdd914597693eed299119ff4c2e6d31f2
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Fri Nov 9 09:26:00 2012 -0600

    powerpc: Fix cputable #ifdef where CONFIG_PPC_A2 is used for =
CONFIG_PPC_BOOK3E_64
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit ea51920d7035c8d23801d6de46261e7d0a537dfd
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Fri Nov 9 08:58:27 2012 -0600

    powerpc/book3e: Remove config for PPC_A2_DD2 since there is no =
reference to it
   =20
    This must have been leftover from early DD1 days which is not
    present in any current kernel code.
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 08151401a5db4ff0d441a1b7bf8ad92bd92b14c5
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Mon Nov 5 09:38:01 2012 -0600

    powerpc/dcr: Some native DCR fixes
   =20
    The following fixes have been made:
     - dcr_read/write_native() must use the indexed version of the
       m[ft]dcrx since the non-indexed version only allows a 10-bit
       numerical space, but the C interface allows a full 32-bits.
     - C bindings for m[ft]dcrx, and the "table" versions, should use
       "unsigned long" so that they are 64/32 bit neutral.
     - The "table" versions (__m[ft]cdr) should obtain the table address
       with LOAD_REG_ADDR(), this will also make it 64/32bit neutral.
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit c8320a5daaceed03992d763302020834ea8e17dd
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Mon Nov 5 09:12:00 2012 -0600

    powerpc/dcr: Add 64-bit DCR access methods.
   =20
    This patch adds the ability to make 64-bit Device Control Register
    (DCR) accesses.
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit a763b3f8453b3bd83d7dded8c6644939863af430
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Thu Nov 29 12:49:24 2012 -0500

    powerpc/boot: Add a "spin_threads" hook to platform_ops
   =20
    It is useful for the boot program to arrange for all secondary cpus
    and threads to enter the kernel in a "kexec" fashion.  This hook =
makes
    it possible.
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 391e43393380b514d4d02a42d059619542c7597b
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Thu Nov 29 13:01:23 2012 -0500

    powerpc/kexec: Add kexec "hold" support for Book3e processors
   =20
    This patch add two items:
    1) Book3e requires that GPR4 survive the "hold" process, so we make
       sure that happens.
    2) Book3e has no real mode, and the hold code exploits this.  Since
       these processors ares always translated, we arrange for the =
kexeced
       threads to enter the hold code using the normal kernel linear =
mapping.
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Wed Dec 5 13:41:25 2012 -0500

    powerpc: Remove unecessary VSX symbols
   =20
    The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.  =
Its
    presence causes build issues with more complex configurations.
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 4e817bb42ec8e3d3689877528dd97c4286a870eb
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Tue Nov 20 10:10:52 2012 -0600

    Blue Gene/Q wicked optimizing compiler does not know the rfdi =
instruction yet
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 2071aa58b2f3b33d97c94e3a127f7c5d4ffaeb34
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Tue Nov 20 10:14:22 2012 -0600

    Blue Gene/Q wicked optimizing compiler does not know the mfdcrx =
instruction yet
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 6e58088fabedbb2d724637b539ba180c03ed8b68
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Wed Oct 31 16:33:21 2012 -0500

    powerpc/book3e: IBM Blue Gene/Q Boot
   =20
    This patch specifically deals with the initial program load
    environment so that a boot image (dtbImage.bgq) can be loaded by the
    BGQ management tools.  The boot code is a little odd because it has =
to
    deal with the following issues:
     - Linux boot image wrappers are 32-bit programs
     - BGQ Tools only load 64bit ELF programs
     - BGQ Firmware information is typically loaded at an address > 4G
     - BGQ FW information contains 64-bit ABI function pointers (which =
are
       actually function descriptors) to access firmware methods
     - BGQ FW methods must be called in 64-bit mode
   =20
    Includes code contributed from:
      Andrew Tauferner <ataufer@us.ibm.com>
      Todd Inglett <tinglett@us.ibm.com>
      Eric Van Hensbergen <ericvh@gmail.com>
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 3bc841935eb4955ce2b2db69bff16f7928464597
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Wed Oct 31 22:36:54 2012 -0500

    powerpc/book3e: IBM Blue Gene/Q Platform and SMP
   =20
    This patch introduces BGQ as a platform and adds SMP functionality
   =20
    Includes code contributed from:
      Andrew Tauferner <ataufer@us.ibm.com>
      Todd Inglett <tinglett@us.ibm.com>
      Eric Van Hensbergen <ericvh@gmail.com>
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 279c0615917b959a652e81f4ad0d886e2d426d85
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Wed Dec 5 13:43:22 2012 -0500

    powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
   =20
    This enables kernel support for the QPX extention and is intended =
for
    processors that support it, usually an IBM Blue Gene processor.
    Turning it on does not effect other processors but it does add code
    and will quadruple the per thread save and restore area for the FPU
    (hense the name).  If you have enabled VSX it will only double the
    space.
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 6ff45170ab0463fb34d7011e08c7e47c396f0fd7
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Fri Nov 23 14:52:14 2012 -0600

    powerpc/book3e: IBM Blue Gene/Q HVC Based Firmware Console
   =20
    New HVC device that uses the Blue Gene Firmware methods to erad and
    write to console.
   =20
        Includes code contributed from:
          Andrew Tauferner <ataufer@us.ibm.com>
          Todd Inglett <tinglett@us.ibm.com>
          Eric Van Hensbergen <ericvh@gmail.com>
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit e4ddc0c2ad8b3f0260d15d73e153095e95da84ac
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Thu Nov 29 15:52:04 2012 -0500

    powerpc/book3e: IBM Blue Gene/Q PCIe and MSI
   =20
    The following patch adds support for the BG/Q PCIe bridge and MSI =
interrupts.
   =20
    Includes code contributed from:
      Jay S. Bryant <jsbryant@us.ibm.com>
      Eric Van Hensbergen <ericvh@gmail.com>
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 9fc0b6f729f7bd7e31338283640a718fa4b1693b
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Wed Dec 5 07:01:49 2012 -0500

    powerpc/book3e: IBM Blue Gene/Q Character Drivers
   =20
    The following patch adds support for user and administration
    applications to access the BG/Q control system.
   =20
    Includes code contributed from:
      Jay S. Bryant <jsbryant@us.ibm.com>
      Eric Van Hensbergen <ericvh@gmail.com>
   =20
    Signed-off-by: Jimi Xenidis <jimix@pobox.com>

commit 9df2c4dfde0ac75f8b2bfcf565f78c2b7382b031
Author: Jimi Xenidis <jimix@pobox.com>
Date:   Thu Dec 6 18:07:16 2012 -0500

    Linux 3.4.22-BGQ-rc1

Re: [RFC] Add IBM Blue Gene/Q Platform

[Michael Neuling]

> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Wed Dec 5 13:41:25 2012 -0500
> 
>     powerpc: Remove unecessary VSX symbols
>     
>     The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.  Its
>     presence causes build issues with more complex configurations.
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 

Can you explain what these "complex configurations" are?

Mikey

Re: [RFC] Add IBM Blue Gene/Q Platform

[Michael Neuling]

> commit 279c0615917b959a652e81f4ad0d886e2d426d85
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Wed Dec 5 13:43:22 2012 -0500
> 
>     powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
>     
>     This enables kernel support for the QPX extention and is intended for
>     processors that support it, usually an IBM Blue Gene processor.
>     Turning it on does not effect other processors but it does add code
>     and will quadruple the per thread save and restore area for the FPU
>     (hense the name).  If you have enabled VSX it will only double the
>     space.
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>

Can you give a diagram of how the QPX registers are layed out.

+#if defined(CONFIG_PPC_QPX)
+#define TS_FPRWIDTH 4
+#elif defined(CONFIG_VSX)

Are they 256 bits wide?


+#define QVLFDXA(QRT,RA,RB)	\
+	.long (0x7c00048f | ((QRT) << 21) | ((RA) << 16) | ((RB) << 11))

Put this in ppc-opcode.h.

+#if defined(CONFIG_VSX) || defined(CONFIG_PPC_QPX)
+	/* they are the same MSR bit */

OMG!


+BEGIN_FTR_SECTION							\
+	SAVE_32VSRS(n,c,base);						\
+END_FTR_SECTION_IFSET(CPU_FTR_VSX);					\
+BEGIN_FTR_SECTION							\
+	SAVE_32QRS(n,c,base);						\
+END_FTR_SECTION_IFSET(CPU_FTR_QPX);	

I don't think we want to do this.  We are going to end up with 64
NOPS here somewhere.

I'd like to see this patch broken into different parts.

Also, have you boot tested this change on a VSX enabled box?

Mikey

Re: [RFC] Add IBM Blue Gene/Q Platform

[Michael Neuling]

Michael Neuling <mikey@neuling.org> wrote:

> > commit 279c0615917b959a652e81f4ad0d886e2d426d85
> > Author: Jimi Xenidis <jimix@pobox.com>
> > Date:   Wed Dec 5 13:43:22 2012 -0500
> > 
> >     powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
> >     
> >     This enables kernel support for the QPX extention and is intended for
> >     processors that support it, usually an IBM Blue Gene processor.
> >     Turning it on does not effect other processors but it does add code
> >     and will quadruple the per thread save and restore area for the FPU
> >     (hense the name).  If you have enabled VSX it will only double the
> >     space.
> >     
> >     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> Can you give a diagram of how the QPX registers are layed out.
> 
> +#if defined(CONFIG_PPC_QPX)
> +#define TS_FPRWIDTH 4
> +#elif defined(CONFIG_VSX)
> 
> Are they 256 bits wide?
> 
> 
> +#define QVLFDXA(QRT,RA,RB)	\
> +	.long (0x7c00048f | ((QRT) << 21) | ((RA) << 16) | ((RB) << 11))
> 
> Put this in ppc-opcode.h.
> 
> +#if defined(CONFIG_VSX) || defined(CONFIG_PPC_QPX)
> +	/* they are the same MSR bit */
> 
> OMG!
> 
> 
> +BEGIN_FTR_SECTION							\
> +	SAVE_32VSRS(n,c,base);						\
> +END_FTR_SECTION_IFSET(CPU_FTR_VSX);					\
> +BEGIN_FTR_SECTION							\
> +	SAVE_32QRS(n,c,base);						\
> +END_FTR_SECTION_IFSET(CPU_FTR_QPX);	
> 
> I don't think we want to do this.  We are going to end up with 64
> NOPS here somewhere.
> 
> I'd like to see this patch broken into different parts.
> 
> Also, have you boot tested this change on a VSX enabled box?

Also, this is going to clash with the transactional memory patches.

Mikey

Re: [RFC] Add IBM Blue Gene/Q Platform

[Michael Neuling]

Jimi Xenidis <jimix@pobox.com> wrote:

> Rather than flood the mailing list with the patches, I've arranged for a git repo to hold the changesets.
> You can find the repo here:
>   <https://github.com/jimix/linux-bgq>
> 
> They are against GregKH's linux-stable.git long-term 3.4.y (y=22) branch.
> The first 9 (6e58088f..) effect common code and the rest are BGQ specific.

Do you actually want this upstream?  I assume no.

Mikey

> 
> Here is a are the summary logs:
> 
> $ git log --reverse linux-stable/linux-3.4.y..
> commit 5a8edb2bdd914597693eed299119ff4c2e6d31f2
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Fri Nov 9 09:26:00 2012 -0600
> 
>     powerpc: Fix cputable #ifdef where CONFIG_PPC_A2 is used for CONFIG_PPC_BOOK3E_64
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit ea51920d7035c8d23801d6de46261e7d0a537dfd
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Fri Nov 9 08:58:27 2012 -0600
> 
>     powerpc/book3e: Remove config for PPC_A2_DD2 since there is no reference to it
>     
>     This must have been leftover from early DD1 days which is not
>     present in any current kernel code.
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 08151401a5db4ff0d441a1b7bf8ad92bd92b14c5
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Mon Nov 5 09:38:01 2012 -0600
> 
>     powerpc/dcr: Some native DCR fixes
>     
>     The following fixes have been made:
>      - dcr_read/write_native() must use the indexed version of the
>        m[ft]dcrx since the non-indexed version only allows a 10-bit
>        numerical space, but the C interface allows a full 32-bits.
>      - C bindings for m[ft]dcrx, and the "table" versions, should use
>        "unsigned long" so that they are 64/32 bit neutral.
>      - The "table" versions (__m[ft]cdr) should obtain the table address
>        with LOAD_REG_ADDR(), this will also make it 64/32bit neutral.
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit c8320a5daaceed03992d763302020834ea8e17dd
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Mon Nov 5 09:12:00 2012 -0600
> 
>     powerpc/dcr: Add 64-bit DCR access methods.
>     
>     This patch adds the ability to make 64-bit Device Control Register
>     (DCR) accesses.
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit a763b3f8453b3bd83d7dded8c6644939863af430
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Thu Nov 29 12:49:24 2012 -0500
> 
>     powerpc/boot: Add a "spin_threads" hook to platform_ops
>     
>     It is useful for the boot program to arrange for all secondary cpus
>     and threads to enter the kernel in a "kexec" fashion.  This hook makes
>     it possible.
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 391e43393380b514d4d02a42d059619542c7597b
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Thu Nov 29 13:01:23 2012 -0500
> 
>     powerpc/kexec: Add kexec "hold" support for Book3e processors
>     
>     This patch add two items:
>     1) Book3e requires that GPR4 survive the "hold" process, so we make
>        sure that happens.
>     2) Book3e has no real mode, and the hold code exploits this.  Since
>        these processors ares always translated, we arrange for the kexeced
>        threads to enter the hold code using the normal kernel linear mapping.
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Wed Dec 5 13:41:25 2012 -0500
> 
>     powerpc: Remove unecessary VSX symbols
>     
>     The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.  Its
>     presence causes build issues with more complex configurations.
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 4e817bb42ec8e3d3689877528dd97c4286a870eb
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Tue Nov 20 10:10:52 2012 -0600
> 
>     Blue Gene/Q wicked optimizing compiler does not know the rfdi instruction yet
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 2071aa58b2f3b33d97c94e3a127f7c5d4ffaeb34
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Tue Nov 20 10:14:22 2012 -0600
> 
>     Blue Gene/Q wicked optimizing compiler does not know the mfdcrx instruction yet
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 6e58088fabedbb2d724637b539ba180c03ed8b68
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Wed Oct 31 16:33:21 2012 -0500
> 
>     powerpc/book3e: IBM Blue Gene/Q Boot
>     
>     This patch specifically deals with the initial program load
>     environment so that a boot image (dtbImage.bgq) can be loaded by the
>     BGQ management tools.  The boot code is a little odd because it has to
>     deal with the following issues:
>      - Linux boot image wrappers are 32-bit programs
>      - BGQ Tools only load 64bit ELF programs
>      - BGQ Firmware information is typically loaded at an address > 4G
>      - BGQ FW information contains 64-bit ABI function pointers (which are
>        actually function descriptors) to access firmware methods
>      - BGQ FW methods must be called in 64-bit mode
>     
>     Includes code contributed from:
>       Andrew Tauferner <ataufer@us.ibm.com>
>       Todd Inglett <tinglett@us.ibm.com>
>       Eric Van Hensbergen <ericvh@gmail.com>
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 3bc841935eb4955ce2b2db69bff16f7928464597
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Wed Oct 31 22:36:54 2012 -0500
> 
>     powerpc/book3e: IBM Blue Gene/Q Platform and SMP
>     
>     This patch introduces BGQ as a platform and adds SMP functionality
>     
>     Includes code contributed from:
>       Andrew Tauferner <ataufer@us.ibm.com>
>       Todd Inglett <tinglett@us.ibm.com>
>       Eric Van Hensbergen <ericvh@gmail.com>
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 279c0615917b959a652e81f4ad0d886e2d426d85
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Wed Dec 5 13:43:22 2012 -0500
> 
>     powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
>     
>     This enables kernel support for the QPX extention and is intended for
>     processors that support it, usually an IBM Blue Gene processor.
>     Turning it on does not effect other processors but it does add code
>     and will quadruple the per thread save and restore area for the FPU
>     (hense the name).  If you have enabled VSX it will only double the
>     space.
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 6ff45170ab0463fb34d7011e08c7e47c396f0fd7
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Fri Nov 23 14:52:14 2012 -0600
> 
>     powerpc/book3e: IBM Blue Gene/Q HVC Based Firmware Console
>     
>     New HVC device that uses the Blue Gene Firmware methods to erad and
>     write to console.
>     
>         Includes code contributed from:
>           Andrew Tauferner <ataufer@us.ibm.com>
>           Todd Inglett <tinglett@us.ibm.com>
>           Eric Van Hensbergen <ericvh@gmail.com>
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit e4ddc0c2ad8b3f0260d15d73e153095e95da84ac
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Thu Nov 29 15:52:04 2012 -0500
> 
>     powerpc/book3e: IBM Blue Gene/Q PCIe and MSI
>     
>     The following patch adds support for the BG/Q PCIe bridge and MSI interrupts.
>     
>     Includes code contributed from:
>       Jay S. Bryant <jsbryant@us.ibm.com>
>       Eric Van Hensbergen <ericvh@gmail.com>
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 9fc0b6f729f7bd7e31338283640a718fa4b1693b
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Wed Dec 5 07:01:49 2012 -0500
> 
>     powerpc/book3e: IBM Blue Gene/Q Character Drivers
>     
>     The following patch adds support for user and administration
>     applications to access the BG/Q control system.
>     
>     Includes code contributed from:
>       Jay S. Bryant <jsbryant@us.ibm.com>
>       Eric Van Hensbergen <ericvh@gmail.com>
>     
>     Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> 
> commit 9df2c4dfde0ac75f8b2bfcf565f78c2b7382b031
> Author: Jimi Xenidis <jimix@pobox.com>
> Date:   Thu Dec 6 18:07:16 2012 -0500
> 
>     Linux 3.4.22-BGQ-rc1
> 
> 
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 

Re: [RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

On Dec 6, 2012, at 11:41 PM, Michael Neuling <mikey@neuling.org> wrote:

>> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Wed Dec 5 13:41:25 2012 -0500
>>=20
>>    powerpc: Remove unecessary VSX symbols
>>=20
>>    The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.  =
Its
>>    presence causes build issues with more complex configurations.
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>=20
> Can you explain what these "complex configurations" are?

In an earlier email we discussed the possibility that there was the =
possibility/desire that a single binary could support either FPU, VSX =
and the new QPX.
However, if a CONFIG_VSX is not defined then THREAD_VSR0 does not get =
defined even though there might be some code that refers to it.
Since it is an alias for the same piece of storage I was hoping to solve =
my config issue and be simplify the code.

-jx


>=20
> Mikey

Re: [RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

On Dec 6, 2012, at 11:54 PM, Michael Neuling <mikey@neuling.org> wrote:

>> commit 279c0615917b959a652e81f4ad0d886e2d426d85
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Wed Dec 5 13:43:22 2012 -0500
>>=20
>>    powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
>>=20
>>    This enables kernel support for the QPX extention and is intended =
for
>>    processors that support it, usually an IBM Blue Gene processor.
>>    Turning it on does not effect other processors but it does add =
code
>>    and will quadruple the per thread save and restore area for the =
FPU
>>    (hense the name).  If you have enabled VSX it will only double the
>>    space.
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>=20
> Can you give a diagram of how the QPX registers are layed out.
>=20
> +#if defined(CONFIG_PPC_QPX)
> +#define TS_FPRWIDTH 4
> +#elif defined(CONFIG_VSX)
>=20
> Are they 256 bits wide?

Yes, this is why we nicknamed it the "Quad Hummer" :)
 - 4-wide double precision FPU SIMD
 - 2-wide complex SIMD
 - 4R/2W register file (32x256 bits per thread)
 - 32B (256 bits) datapath to/from L1 cache

>=20
>=20
> +#define QVLFDXA(QRT,RA,RB)	\
> +	.long (0x7c00048f | ((QRT) << 21) | ((RA) << 16) | ((RB) << 11))
>=20
> Put this in ppc-opcode.h.
>=20
> +#if defined(CONFIG_VSX) || defined(CONFIG_PPC_QPX)
> +	/* they are the same MSR bit */
>=20
> OMG!

Ooops, you are correct, this was in the original patch.
I'll double check the work book, but it should be the architected =
VEC/SPV bit which is really for VMX.
I'll track it down.

>=20
>=20
> +BEGIN_FTR_SECTION							=
\
> +	SAVE_32VSRS(n,c,base);						=
\
> +END_FTR_SECTION_IFSET(CPU_FTR_VSX);					=
\
> +BEGIN_FTR_SECTION							=
\
> +	SAVE_32QRS(n,c,base);						=
\
> +END_FTR_SECTION_IFSET(CPU_FTR_QPX);=09
>=20
> I don't think we want to do this.  We are going to end up with 64
> NOPS here somewhere.

Excellent point, NOPs are cheap on most processors but not A2 and a lot =
of embedded, I can wrap some branches with the FTR instead.
Do you have a concern on the code size?

>=20
> I'd like to see this patch broken into different parts.

I'm not sure how _this_ patch:
  =
<https://github.com/jimix/linux-bgq/commit/279c0615917b959a652e81f4ad0d886=
e2d426d85>
could be broken up, please advise.

>=20
> Also, have you boot tested this change on a VSX enabled box?

I can try, I may bug you for help.
Is there a commonly test (or apps) I should run?

-jx


>=20
> Mikey

Re: [RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

On Dec 6, 2012, at 11:56 PM, Michael Neuling <mikey@neuling.org> wrote:

> Jimi Xenidis <jimix@pobox.com> wrote:
>=20
>> Rather than flood the mailing list with the patches, I've arranged =
for a git repo to hold the changesets.
>> You can find the repo here:
>>  <https://github.com/jimix/linux-bgq>
>>=20
>> They are against GregKH's linux-stable.git long-term 3.4.y (y=3D22) =
branch.
>> The first 9 (6e58088f..) effect common code and the rest are BGQ =
specific.
>=20
> Do you actually want this upstream?  I assume no.

I needed to get these long-term patches out there for the BGQ community =
for test.
I would very much like to get a version of these upstream.
I expect only the QPX, kexec, and (maybe) the DCR changes to cause any =
controversy, but I've been wrong before.
I'll be making those patches soon and hope to get a lot of feedback from =
these patches.
-jx


>=20
> Mikey
>=20
>>=20
>> Here is a are the summary logs:
>>=20
>> $ git log --reverse linux-stable/linux-3.4.y..
>> commit 5a8edb2bdd914597693eed299119ff4c2e6d31f2
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Fri Nov 9 09:26:00 2012 -0600
>>=20
>>    powerpc: Fix cputable #ifdef where CONFIG_PPC_A2 is used for =
CONFIG_PPC_BOOK3E_64
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit ea51920d7035c8d23801d6de46261e7d0a537dfd
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Fri Nov 9 08:58:27 2012 -0600
>>=20
>>    powerpc/book3e: Remove config for PPC_A2_DD2 since there is no =
reference to it
>>=20
>>    This must have been leftover from early DD1 days which is not
>>    present in any current kernel code.
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 08151401a5db4ff0d441a1b7bf8ad92bd92b14c5
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Mon Nov 5 09:38:01 2012 -0600
>>=20
>>    powerpc/dcr: Some native DCR fixes
>>=20
>>    The following fixes have been made:
>>     - dcr_read/write_native() must use the indexed version of the
>>       m[ft]dcrx since the non-indexed version only allows a 10-bit
>>       numerical space, but the C interface allows a full 32-bits.
>>     - C bindings for m[ft]dcrx, and the "table" versions, should use
>>       "unsigned long" so that they are 64/32 bit neutral.
>>     - The "table" versions (__m[ft]cdr) should obtain the table =
address
>>       with LOAD_REG_ADDR(), this will also make it 64/32bit neutral.
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit c8320a5daaceed03992d763302020834ea8e17dd
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Mon Nov 5 09:12:00 2012 -0600
>>=20
>>    powerpc/dcr: Add 64-bit DCR access methods.
>>=20
>>    This patch adds the ability to make 64-bit Device Control Register
>>    (DCR) accesses.
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit a763b3f8453b3bd83d7dded8c6644939863af430
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Thu Nov 29 12:49:24 2012 -0500
>>=20
>>    powerpc/boot: Add a "spin_threads" hook to platform_ops
>>=20
>>    It is useful for the boot program to arrange for all secondary =
cpus
>>    and threads to enter the kernel in a "kexec" fashion.  This hook =
makes
>>    it possible.
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 391e43393380b514d4d02a42d059619542c7597b
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Thu Nov 29 13:01:23 2012 -0500
>>=20
>>    powerpc/kexec: Add kexec "hold" support for Book3e processors
>>=20
>>    This patch add two items:
>>    1) Book3e requires that GPR4 survive the "hold" process, so we =
make
>>       sure that happens.
>>    2) Book3e has no real mode, and the hold code exploits this.  =
Since
>>       these processors ares always translated, we arrange for the =
kexeced
>>       threads to enter the hold code using the normal kernel linear =
mapping.
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Wed Dec 5 13:41:25 2012 -0500
>>=20
>>    powerpc: Remove unecessary VSX symbols
>>=20
>>    The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.  =
Its
>>    presence causes build issues with more complex configurations.
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 4e817bb42ec8e3d3689877528dd97c4286a870eb
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Tue Nov 20 10:10:52 2012 -0600
>>=20
>>    Blue Gene/Q wicked optimizing compiler does not know the rfdi =
instruction yet
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 2071aa58b2f3b33d97c94e3a127f7c5d4ffaeb34
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Tue Nov 20 10:14:22 2012 -0600
>>=20
>>    Blue Gene/Q wicked optimizing compiler does not know the mfdcrx =
instruction yet
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 6e58088fabedbb2d724637b539ba180c03ed8b68
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Wed Oct 31 16:33:21 2012 -0500
>>=20
>>    powerpc/book3e: IBM Blue Gene/Q Boot
>>=20
>>    This patch specifically deals with the initial program load
>>    environment so that a boot image (dtbImage.bgq) can be loaded by =
the
>>    BGQ management tools.  The boot code is a little odd because it =
has to
>>    deal with the following issues:
>>     - Linux boot image wrappers are 32-bit programs
>>     - BGQ Tools only load 64bit ELF programs
>>     - BGQ Firmware information is typically loaded at an address > 4G
>>     - BGQ FW information contains 64-bit ABI function pointers (which =
are
>>       actually function descriptors) to access firmware methods
>>     - BGQ FW methods must be called in 64-bit mode
>>=20
>>    Includes code contributed from:
>>      Andrew Tauferner <ataufer@us.ibm.com>
>>      Todd Inglett <tinglett@us.ibm.com>
>>      Eric Van Hensbergen <ericvh@gmail.com>
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 3bc841935eb4955ce2b2db69bff16f7928464597
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Wed Oct 31 22:36:54 2012 -0500
>>=20
>>    powerpc/book3e: IBM Blue Gene/Q Platform and SMP
>>=20
>>    This patch introduces BGQ as a platform and adds SMP functionality
>>=20
>>    Includes code contributed from:
>>      Andrew Tauferner <ataufer@us.ibm.com>
>>      Todd Inglett <tinglett@us.ibm.com>
>>      Eric Van Hensbergen <ericvh@gmail.com>
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 279c0615917b959a652e81f4ad0d886e2d426d85
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Wed Dec 5 13:43:22 2012 -0500
>>=20
>>    powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
>>=20
>>    This enables kernel support for the QPX extention and is intended =
for
>>    processors that support it, usually an IBM Blue Gene processor.
>>    Turning it on does not effect other processors but it does add =
code
>>    and will quadruple the per thread save and restore area for the =
FPU
>>    (hense the name).  If you have enabled VSX it will only double the
>>    space.
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 6ff45170ab0463fb34d7011e08c7e47c396f0fd7
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Fri Nov 23 14:52:14 2012 -0600
>>=20
>>    powerpc/book3e: IBM Blue Gene/Q HVC Based Firmware Console
>>=20
>>    New HVC device that uses the Blue Gene Firmware methods to erad =
and
>>    write to console.
>>=20
>>        Includes code contributed from:
>>          Andrew Tauferner <ataufer@us.ibm.com>
>>          Todd Inglett <tinglett@us.ibm.com>
>>          Eric Van Hensbergen <ericvh@gmail.com>
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit e4ddc0c2ad8b3f0260d15d73e153095e95da84ac
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Thu Nov 29 15:52:04 2012 -0500
>>=20
>>    powerpc/book3e: IBM Blue Gene/Q PCIe and MSI
>>=20
>>    The following patch adds support for the BG/Q PCIe bridge and MSI =
interrupts.
>>=20
>>    Includes code contributed from:
>>      Jay S. Bryant <jsbryant@us.ibm.com>
>>      Eric Van Hensbergen <ericvh@gmail.com>
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 9fc0b6f729f7bd7e31338283640a718fa4b1693b
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Wed Dec 5 07:01:49 2012 -0500
>>=20
>>    powerpc/book3e: IBM Blue Gene/Q Character Drivers
>>=20
>>    The following patch adds support for user and administration
>>    applications to access the BG/Q control system.
>>=20
>>    Includes code contributed from:
>>      Jay S. Bryant <jsbryant@us.ibm.com>
>>      Eric Van Hensbergen <ericvh@gmail.com>
>>=20
>>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> commit 9df2c4dfde0ac75f8b2bfcf565f78c2b7382b031
>> Author: Jimi Xenidis <jimix@pobox.com>
>> Date:   Thu Dec 6 18:07:16 2012 -0500
>>=20
>>    Linux 3.4.22-BGQ-rc1
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>=20

Re: [RFC] Add IBM Blue Gene/Q Platform

[Andrew Tauferner]

[-- Attachment #1: Type: text/plain, Size: 9114 bytes --]

Jimi,

> > Do you actually want this upstream?  I assume no.
>
> I needed to get these long-term patches out there for the BGQ
> community for test.

To which BGQ community are you referring?  What is the motivation
for this work?

> I would very much like to get a version of these upstream.
> I expect only the QPX, kexec, and (maybe) the DCR changes to cause
> any controversy, but I've been wrong before.

Hehe.  Ben had a variety of issues with the BG/Q firmware when he
gave me some feedback a few years ago.

> I'll be making those patches soon and hope to get a lot of feedback
> from these patches.

What was the starting point for this work?  On what is it based?

> -jx
>
>
> >
> > Mikey
> >
> >>
> >> Here is a are the summary logs:
> >>
> >> $ git log --reverse linux-stable/linux-3.4.y..
> >> commit 5a8edb2bdd914597693eed299119ff4c2e6d31f2
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Fri Nov 9 09:26:00 2012 -0600
> >>
> >>    powerpc: Fix cputable #ifdef where CONFIG_PPC_A2 is used for
> CONFIG_PPC_BOOK3E_64
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit ea51920d7035c8d23801d6de46261e7d0a537dfd
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Fri Nov 9 08:58:27 2012 -0600
> >>
> >>    powerpc/book3e: Remove config for PPC_A2_DD2 since there is no
> reference to it
> >>
> >>    This must have been leftover from early DD1 days which is not
> >>    present in any current kernel code.
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 08151401a5db4ff0d441a1b7bf8ad92bd92b14c5
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Mon Nov 5 09:38:01 2012 -0600
> >>
> >>    powerpc/dcr: Some native DCR fixes
> >>
> >>    The following fixes have been made:
> >>     - dcr_read/write_native() must use the indexed version of the
> >>       m[ft]dcrx since the non-indexed version only allows a 10-bit
> >>       numerical space, but the C interface allows a full 32-bits.
> >>     - C bindings for m[ft]dcrx, and the "table" versions, should use
> >>       "unsigned long" so that they are 64/32 bit neutral.
> >>     - The "table" versions (__m[ft]cdr) should obtain the table
address
> >>       with LOAD_REG_ADDR(), this will also make it 64/32bit neutral.
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit c8320a5daaceed03992d763302020834ea8e17dd
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Mon Nov 5 09:12:00 2012 -0600
> >>
> >>    powerpc/dcr: Add 64-bit DCR access methods.
> >>
> >>    This patch adds the ability to make 64-bit Device Control Register
> >>    (DCR) accesses.
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit a763b3f8453b3bd83d7dded8c6644939863af430
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Thu Nov 29 12:49:24 2012 -0500
> >>
> >>    powerpc/boot: Add a "spin_threads" hook to platform_ops
> >>
> >>    It is useful for the boot program to arrange for all secondary cpus
> >>    and threads to enter the kernel in a "kexec" fashion.  This hook
makes
> >>    it possible.
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 391e43393380b514d4d02a42d059619542c7597b
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Thu Nov 29 13:01:23 2012 -0500
> >>
> >>    powerpc/kexec: Add kexec "hold" support for Book3e processors
> >>
> >>    This patch add two items:
> >>    1) Book3e requires that GPR4 survive the "hold" process, so we make
> >>       sure that happens.
> >>    2) Book3e has no real mode, and the hold code exploits this.  Since
> >>       these processors ares always translated, we arrange for the
kexeced
> >>       threads to enter the hold code using the normal kernel
> linear mapping.
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Dec 5 13:41:25 2012 -0500
> >>
> >>    powerpc: Remove unecessary VSX symbols
> >>
> >>    The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.
Its
> >>    presence causes build issues with more complex configurations.
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 4e817bb42ec8e3d3689877528dd97c4286a870eb
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Tue Nov 20 10:10:52 2012 -0600
> >>
> >>    Blue Gene/Q wicked optimizing compiler does not know the rfdi
> instruction yet
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 2071aa58b2f3b33d97c94e3a127f7c5d4ffaeb34
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Tue Nov 20 10:14:22 2012 -0600
> >>
> >>    Blue Gene/Q wicked optimizing compiler does not know the
> mfdcrx instruction yet
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 6e58088fabedbb2d724637b539ba180c03ed8b68
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Oct 31 16:33:21 2012 -0500
> >>
> >>    powerpc/book3e: IBM Blue Gene/Q Boot
> >>
> >>    This patch specifically deals with the initial program load
> >>    environment so that a boot image (dtbImage.bgq) can be loaded by
the
> >>    BGQ management tools.  The boot code is a little odd because it has
to
> >>    deal with the following issues:
> >>     - Linux boot image wrappers are 32-bit programs
> >>     - BGQ Tools only load 64bit ELF programs
> >>     - BGQ Firmware information is typically loaded at an address > 4G
> >>     - BGQ FW information contains 64-bit ABI function pointers (which
are
> >>       actually function descriptors) to access firmware methods
> >>     - BGQ FW methods must be called in 64-bit mode
> >>
> >>    Includes code contributed from:
> >>      Andrew Tauferner <ataufer@us.ibm.com>
> >>      Todd Inglett <tinglett@us.ibm.com>
> >>      Eric Van Hensbergen <ericvh@gmail.com>
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 3bc841935eb4955ce2b2db69bff16f7928464597
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Oct 31 22:36:54 2012 -0500
> >>
> >>    powerpc/book3e: IBM Blue Gene/Q Platform and SMP
> >>
> >>    This patch introduces BGQ as a platform and adds SMP functionality
> >>
> >>    Includes code contributed from:
> >>      Andrew Tauferner <ataufer@us.ibm.com>
> >>      Todd Inglett <tinglett@us.ibm.com>
> >>      Eric Van Hensbergen <ericvh@gmail.com>
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 279c0615917b959a652e81f4ad0d886e2d426d85
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Dec 5 13:43:22 2012 -0500
> >>
> >>    powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
> >>
> >>    This enables kernel support for the QPX extention and is intended
for
> >>    processors that support it, usually an IBM Blue Gene processor.
> >>    Turning it on does not effect other processors but it does add code
> >>    and will quadruple the per thread save and restore area for the FPU
> >>    (hense the name).  If you have enabled VSX it will only double the
> >>    space.
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 6ff45170ab0463fb34d7011e08c7e47c396f0fd7
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Fri Nov 23 14:52:14 2012 -0600
> >>
> >>    powerpc/book3e: IBM Blue Gene/Q HVC Based Firmware Console
> >>
> >>    New HVC device that uses the Blue Gene Firmware methods to erad and
> >>    write to console.
> >>
> >>        Includes code contributed from:
> >>          Andrew Tauferner <ataufer@us.ibm.com>
> >>          Todd Inglett <tinglett@us.ibm.com>
> >>          Eric Van Hensbergen <ericvh@gmail.com>
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit e4ddc0c2ad8b3f0260d15d73e153095e95da84ac
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Thu Nov 29 15:52:04 2012 -0500
> >>
> >>    powerpc/book3e: IBM Blue Gene/Q PCIe and MSI
> >>
> >>    The following patch adds support for the BG/Q PCIe bridge and
> MSI interrupts.
> >>
> >>    Includes code contributed from:
> >>      Jay S. Bryant <jsbryant@us.ibm.com>
> >>      Eric Van Hensbergen <ericvh@gmail.com>
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 9fc0b6f729f7bd7e31338283640a718fa4b1693b
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Dec 5 07:01:49 2012 -0500
> >>
> >>    powerpc/book3e: IBM Blue Gene/Q Character Drivers
> >>
> >>    The following patch adds support for user and administration
> >>    applications to access the BG/Q control system.
> >>
> >>    Includes code contributed from:
> >>      Jay S. Bryant <jsbryant@us.ibm.com>
> >>      Eric Van Hensbergen <ericvh@gmail.com>
> >>
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >>
> >> commit 9df2c4dfde0ac75f8b2bfcf565f78c2b7382b031
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Thu Dec 6 18:07:16 2012 -0500
> >>
> >>    Linux 3.4.22-BGQ-rc1
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>
>

[-- Attachment #2: Type: text/html, Size: 14202 bytes --]

Re: [RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

On Dec 7, 2012, at 7:38 AM, Jimi Xenidis <jimix@pobox.com> wrote:

>=20
> On Dec 6, 2012, at 11:54 PM, Michael Neuling <mikey@neuling.org> =
wrote:
>=20
>>> commit 279c0615917b959a652e81f4ad0d886e2d426d85
>>> Author: Jimi Xenidis <jimix@pobox.com>
>>> Date:   Wed Dec 5 13:43:22 2012 -0500
>>>=20
>>>   powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
>>>=20
>>>   This enables kernel support for the QPX extention and is intended =
for
>>>   processors that support it, usually an IBM Blue Gene processor.
>>>   Turning it on does not effect other processors but it does add =
code
>>>   and will quadruple the per thread save and restore area for the =
FPU
>>>   (hense the name).  If you have enabled VSX it will only double the
>>>   space.
>>>=20
>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20

<<snip>>
>>=20
>>=20
>>=20
>> +BEGIN_FTR_SECTION							=
\
>> +	SAVE_32VSRS(n,c,base);						=
\
>> +END_FTR_SECTION_IFSET(CPU_FTR_VSX);					=
\
>> +BEGIN_FTR_SECTION							=
\
>> +	SAVE_32QRS(n,c,base);						=
\
>> +END_FTR_SECTION_IFSET(CPU_FTR_QPX);=09
>>=20
>> I don't think we want to do this.  We are going to end up with 64
>> NOPS here somewhere.
>=20
> Excellent point, NOPs are cheap on most processors but not A2 and a =
lot of embedded, I can wrap some branches with the FTR instead.
> Do you have a concern on the code size?

Thought about it a bit and came up with this solution for =
arch/powerpc/kernel/fpu.S.
This should address the following issues
 - MSR_VSX vs MSR_VEC
 - Big chunks of NOPs in the code path
 - Less FTR space fixups at boot time.
 - IMNHSO easier to read especially when disassembled

I did consider using the LR and BLR, but the !CONFIG_SMP case only adds =
one more special block and uses a different register set.
Also if this is agreeable I would like us to consider removing the =
*_32FPVSRS* macros entirely and put the FTR tests in the actual code.
This would allow us to use #ifdefs and reduce the amount of code that =
actually gets compiled.

Thoughts?

diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
index e0ada05..5964067 100644
--- a/arch/powerpc/kernel/fpu.S
+++ b/arch/powerpc/kernel/fpu.S
@@ -25,30 +25,81 @@
 #include <asm/asm-offsets.h>
 #include <asm/ptrace.h>
=20
-#ifdef CONFIG_VSX
-#define __REST_32FPVSRS(n,c,base)					=
\
-BEGIN_FTR_SECTION							=
\
-	b	2f;							=
\
-END_FTR_SECTION_IFSET(CPU_FTR_VSX);					=
\
-	REST_32FPRS(n,base);						=
\
-	b	3f;							=
\
-2:	REST_32VSRS(n,c,base);						=
\
-3:
-
-#define __SAVE_32FPVSRS(n,c,base)					=
\
-BEGIN_FTR_SECTION							=
\
-	b	2f;							=
\
-END_FTR_SECTION_IFSET(CPU_FTR_VSX);					=
\
-	SAVE_32FPRS(n,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)
-#endif
-#define REST_32FPVSRS(n,c,base) =
__REST_32FPVSRS(n,__REG_##c,__REG_##base)
-#define SAVE_32FPVSRS(n,c,base) =
__SAVE_32FPVSRS(n,__REG_##c,__REG_##base)
+
+/*
+ * Restore subroutines, R4 is scratch and R5 is base
+ */
+vsx_restore:
+	REST_32VSRS(0, __REG_R4, __REG_R5)
+	b after_restore
+qpx_restore:
+	REST_32QRS(0, __REG_R4, __REG_R5)
+	b after_restore
+fpu_restore:
+	REST_32FPRS(0, __REG_R5)
+	b after_restore
+
+#define REST_32FPVSRS(n, c, base)		\
+BEGIN_FTR_SECTION				\
+	b vsx_restore;				\
+END_FTR_SECTION_IFSET(CPU_FTR_VSX)		\
+BEGIN_FTR_SECTION				\
+	b qpx_restore;				\
+END_FTR_SECTION_IFSET(CPU_FTR_QPX)		\
+	b fpu_restore;				\
+after_restore:
+
+/*
+ * Save subroutines, R4 is scratch and R3 is base
+ */
+vsx_save:
+	SAVE_32VSRS(0, __REG_R4, __REG_R3)
+	b after_save
+qpx_save:
+	SAVE_32QRS(0, __REG_R4, __REG_R3)
+	b after_save
+fpu_save:
+	SAVE_32FPRS(0, __REG_R3)
+	b after_save
+
+#define SAVE_32FPVSRS(n, c, base)		\
+BEGIN_FTR_SECTION				\
+	b vsx_save;				\
+END_FTR_SECTION_IFSET(CPU_FTR_VSX)		\
+BEGIN_FTR_SECTION				\
+	b qpx_save;				\
+END_FTR_SECTION_IFSET(CPU_FTR_QPX)		\
+	b fpu_save;				\
+after_save:
+
+#ifndef CONFIG_SMP
+/*
+ * we need an extra save set for the !CONFIG_SMP case, see below
+ * Scratch it R5 and base is R4
+ */
+vsx_save_nosmp:
+	SAVE_32VSRS(0,R5,R4)
+	b after_save_nosmp
+
+qpx_save_nosmp:
+	SAVE_32QRS(0,R5,R4)
+	b after_save_nosmp
+
+fpu_save_nosmp:
+	SAVE_32FPRS(0,R4)
+	b after_save_nosmp
+
+#define SAVE_32FPVSRS_NOSMP(n,c,base)		\
+BEGIN_FTR_SECTION				\
+	b vsx_save_nosmp;			\
+END_FTR_SECTION_IFSET(CPU_FTR_VSX)		\
+BEGIN_FTR_SECTION				\
+	b qpx_save_nosmp;			\
+END_FTR_SECTION_IFSET(CPU_FTR_QPX)		\
+	b fpu_save_nosmp;			\
+after_save_nosmp:
+
+#endif /* !CONFIG_SMP */
=20
 /*
  * This task wants to use the FPU now.
@@ -65,6 +116,11 @@ BEGIN_FTR_SECTION
 	oris	r5,r5,MSR_VSX@h
 END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 #endif
+#ifdef CONFIG_PPC_QPX
+BEGIN_FTR_SECTION
+	oris	r5,r5,MSR_VEC@h
+END_FTR_SECTION_IFSET(CPU_FTR_QPX)
+#endif
 	SYNC
 	MTMSRD(r5)			/* enable use of fpu now */
 	isync
@@ -81,7 +137,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 	beq	1f
 	toreal(r4)
 	addi	r4,r4,THREAD		/* want =
last_task_used_math->thread */
-	SAVE_32FPVSRS(0, R5, R4)
+	SAVE_32FPVSRS_NOSMP(0, R5, R4)
 	mffs	fr0
 	stfd	fr0,THREAD_FPSCR(r4)
 	PPC_LL	r5,PT_REGS(r4)
@@ -94,7 +150,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 #endif /* CONFIG_SMP */
 	/* enable use of FP after return */
 #ifdef CONFIG_PPC32
-	mfspr	r5,SPRN_SPRG_THREAD		/* current task's THREAD =
(phys) */
+	mfspr	r5,SPRN_SPRG_THREAD	/* current task's THREAD (phys) =
*/
 	lwz	r4,THREAD_FPEXC_MODE(r5)
 	ori	r9,r9,MSR_FP		/* enable FP for current */
 	or	r9,r9,r4
@@ -132,6 +188,11 @@ BEGIN_FTR_SECTION
 	oris	r5,r5,MSR_VSX@h
 END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 #endif
+#ifdef CONFIG_PPC_QPX
+BEGIN_FTR_SECTION
+	oris	r5,r5,MSR_VEC@h
+END_FTR_SECTION_IFSET(CPU_FTR_QPX)
+#endif
 	SYNC_601
 	ISYNC_601
 	MTMSRD(r5)			/* enable use of fpu now */
@@ -148,10 +209,10 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 	beq	1f
 	PPC_LL	r4,_MSR-STACK_FRAME_OVERHEAD(r5)
 	li	r3,MSR_FP|MSR_FE0|MSR_FE1
-#ifdef CONFIG_VSX
+#if defined(CONFIG_VSX) || defined(CONFIG_PPC_QPX)
 BEGIN_FTR_SECTION
 	oris	r3,r3,MSR_VSX@h
-END_FTR_SECTION_IFSET(CPU_FTR_VSX)
+END_FTR_SECTION_IFSET(CPU_FTR_VSX | CPU_FTR_QPX)
 #endif
 	andc	r4,r4,r3		/* disable FP for previous task =
*/
 	PPC_STL	r4,_MSR-STACK_FRAME_OVERHEAD(r5)

-jx


>=20
>>=20
>> I'd like to see this patch broken into different parts.
>=20
> I'm not sure how _this_ patch:
>  =
<https://github.com/jimix/linux-bgq/commit/279c0615917b959a652e81f4ad0d886=
e2d426d85>
> could be broken up, please advise.
>=20
>>=20
>> Also, have you boot tested this change on a VSX enabled box?
>=20
> I can try, I may bug you for help.
> Is there a commonly test (or apps) I should run?
>=20
> -jx
>=20
>=20
>>=20
>> Mikey
>=20

Re: [RFC] Add IBM Blue Gene/Q Platform

[Michael Neuling]

Jimi Xenidis <jimix@pobox.com> wrote:

> 
> On Dec 6, 2012, at 11:41 PM, Michael Neuling <mikey@neuling.org> wrote:
> 
> >> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Dec 5 13:41:25 2012 -0500
> >> 
> >>    powerpc: Remove unecessary VSX symbols
> >> 
> >>    The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.  Its
> >>    presence causes build issues with more complex configurations.
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> > 
> > Can you explain what these "complex configurations" are?
> 
> In an earlier email we discussed the possibility that there was the
> possibility/desire that a single binary could support either FPU, VSX
> and the new QPX.  However, if a CONFIG_VSX is not defined then
> THREAD_VSR0 does not get defined even though there might be some code
> that refers to it.  Since it is an alias for the same piece of storage
> I was hoping to solve my config issue and be simplify the code.

Yep, I remember the conversation.  I just want that explanation in the
commit log so others know *why* it was changed.

Mikey

Re: [RFC] Add IBM Blue Gene/Q Platform

[Michael Neuling]

Jimi Xenidis <jimix@pobox.com> wrote:

> 
> On Dec 6, 2012, at 11:54 PM, Michael Neuling <mikey@neuling.org> wrote:
> 
> >> commit 279c0615917b959a652e81f4ad0d886e2d426d85
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Dec 5 13:43:22 2012 -0500
> >> 
> >>    powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
> >> 
> >>    This enables kernel support for the QPX extention and is intended for
> >>    processors that support it, usually an IBM Blue Gene processor.
> >>    Turning it on does not effect other processors but it does add code
> >>    and will quadruple the per thread save and restore area for the FPU
> >>    (hense the name).  If you have enabled VSX it will only double the
> >>    space.
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > 
> > Can you give a diagram of how the QPX registers are layed out.
> > 
> > +#if defined(CONFIG_PPC_QPX)
> > +#define TS_FPRWIDTH 4
> > +#elif defined(CONFIG_VSX)
> > 
> > Are they 256 bits wide?
> 
> Yes, this is why we nicknamed it the "Quad Hummer" :)
>  - 4-wide double precision FPU SIMD
>  - 2-wide complex SIMD
>  - 4R/2W register file (32x256 bits per thread)
>  - 32B (256 bits) datapath to/from L1 cache

OK, can you add a comment like this to the commit log and to the code so
that people know what it looks like.

> 
> > 
> > 
> > +#define QVLFDXA(QRT,RA,RB)	\
> > +	.long (0x7c00048f | ((QRT) << 21) | ((RA) << 16) | ((RB) << 11))
> > 
> > Put this in ppc-opcode.h.
> > 
> > +#if defined(CONFIG_VSX) || defined(CONFIG_PPC_QPX)
> > +	/* they are the same MSR bit */
> > 
> > OMG!
> 
> Ooops, you are correct, this was in the original patch.
> I'll double check the work book, but it should be the architected VEC/SPV bit which is really for VMX.
> I'll track it down.
> 
> > 
> > 
> > +BEGIN_FTR_SECTION							\
> > +	SAVE_32VSRS(n,c,base);						\
> > +END_FTR_SECTION_IFSET(CPU_FTR_VSX);					\
> > +BEGIN_FTR_SECTION							\
> > +	SAVE_32QRS(n,c,base);						\
> > +END_FTR_SECTION_IFSET(CPU_FTR_QPX);	
> > 
> > I don't think we want to do this.  We are going to end up with 64
> > NOPS here somewhere.
> 
> Excellent point, NOPs are cheap on most processors but not A2 and a
> lot of embedded, I can wrap some branches with the FTR instead.  Do
> you have a concern on the code size?

Code size is not the issue.  Just running over 64NOPS for no reason.  In
the past, we've preferred a branch over a section of code.

> 
> > 
> > I'd like to see this patch broken into different parts.
> 
> I'm not sure how _this_ patch:
>   <https://github.com/jimix/linux-bgq/commit/279c0615917b959a652e81f4ad0d886e2d426d85>
> could be broken up, please advise.

Add it in reviewable chunks.  Add the infrastructure (instructions,
macros, config options) then hook it into the existing code.


> > Also, have you boot tested this change on a VSX enabled box?
> 
> I can try, I may bug you for help.  Is there a commonly test (or apps)
> I should run?

I have some tests squirred away when I did the initial VSX stuff.  I can
grab them. I suspect this will either completely blow up VSX context
switching or work perfectly well.  It's unlikely to introduce subtle
bugs.

Mikey 

Re: [RFC] Add IBM Blue Gene/Q Platform

[Michael Neuling]

Jimi Xenidis <jimix@pobox.com> wrote:

> 
> On Dec 6, 2012, at 11:56 PM, Michael Neuling <mikey@neuling.org> wrote:
> 
> > Jimi Xenidis <jimix@pobox.com> wrote:
> > 
> >> Rather than flood the mailing list with the patches, I've arranged for a git repo to hold the changesets.
> >> You can find the repo here:
> >>  <https://github.com/jimix/linux-bgq>
> >> 
> >> They are against GregKH's linux-stable.git long-term 3.4.y (y=22) branch.
> >> The first 9 (6e58088f..) effect common code and the rest are BGQ specific.
> > 
> > Do you actually want this upstream?  I assume no.
> 
> I needed to get these long-term patches out there for the BGQ
> community for test.  I would very much like to get a version of these
> upstream.

Ok, cool.  

> I expect only the QPX, kexec, and (maybe) the DCR changes to cause any controversy, but I've been wrong before.

>From my perspective, the QPX stuff should be fine to get upstream once
we beat the patches into shape.  No comment on kexec and DCR.  

Mikey

> I'll be making those patches soon and hope to get a lot of feedback
> from these patches.  -jx
> 
> 
> > 
> > Mikey
> > 
> >> 
> >> Here is a are the summary logs:
> >> 
> >> $ git log --reverse linux-stable/linux-3.4.y..
> >> commit 5a8edb2bdd914597693eed299119ff4c2e6d31f2
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Fri Nov 9 09:26:00 2012 -0600
> >> 
> >>    powerpc: Fix cputable #ifdef where CONFIG_PPC_A2 is used for CONFIG_PPC_BOOK3E_64
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit ea51920d7035c8d23801d6de46261e7d0a537dfd
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Fri Nov 9 08:58:27 2012 -0600
> >> 
> >>    powerpc/book3e: Remove config for PPC_A2_DD2 since there is no reference to it
> >> 
> >>    This must have been leftover from early DD1 days which is not
> >>    present in any current kernel code.
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 08151401a5db4ff0d441a1b7bf8ad92bd92b14c5
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Mon Nov 5 09:38:01 2012 -0600
> >> 
> >>    powerpc/dcr: Some native DCR fixes
> >> 
> >>    The following fixes have been made:
> >>     - dcr_read/write_native() must use the indexed version of the
> >>       m[ft]dcrx since the non-indexed version only allows a 10-bit
> >>       numerical space, but the C interface allows a full 32-bits.
> >>     - C bindings for m[ft]dcrx, and the "table" versions, should use
> >>       "unsigned long" so that they are 64/32 bit neutral.
> >>     - The "table" versions (__m[ft]cdr) should obtain the table address
> >>       with LOAD_REG_ADDR(), this will also make it 64/32bit neutral.
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit c8320a5daaceed03992d763302020834ea8e17dd
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Mon Nov 5 09:12:00 2012 -0600
> >> 
> >>    powerpc/dcr: Add 64-bit DCR access methods.
> >> 
> >>    This patch adds the ability to make 64-bit Device Control Register
> >>    (DCR) accesses.
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit a763b3f8453b3bd83d7dded8c6644939863af430
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Thu Nov 29 12:49:24 2012 -0500
> >> 
> >>    powerpc/boot: Add a "spin_threads" hook to platform_ops
> >> 
> >>    It is useful for the boot program to arrange for all secondary cpus
> >>    and threads to enter the kernel in a "kexec" fashion.  This hook makes
> >>    it possible.
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 391e43393380b514d4d02a42d059619542c7597b
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Thu Nov 29 13:01:23 2012 -0500
> >> 
> >>    powerpc/kexec: Add kexec "hold" support for Book3e processors
> >> 
> >>    This patch add two items:
> >>    1) Book3e requires that GPR4 survive the "hold" process, so we make
> >>       sure that happens.
> >>    2) Book3e has no real mode, and the hold code exploits this.  Since
> >>       these processors ares always translated, we arrange for the kexeced
> >>       threads to enter the hold code using the normal kernel linear mapping.
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Dec 5 13:41:25 2012 -0500
> >> 
> >>    powerpc: Remove unecessary VSX symbols
> >> 
> >>    The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.  Its
> >>    presence causes build issues with more complex configurations.
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 4e817bb42ec8e3d3689877528dd97c4286a870eb
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Tue Nov 20 10:10:52 2012 -0600
> >> 
> >>    Blue Gene/Q wicked optimizing compiler does not know the rfdi instruction yet
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 2071aa58b2f3b33d97c94e3a127f7c5d4ffaeb34
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Tue Nov 20 10:14:22 2012 -0600
> >> 
> >>    Blue Gene/Q wicked optimizing compiler does not know the mfdcrx instruction yet
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 6e58088fabedbb2d724637b539ba180c03ed8b68
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Oct 31 16:33:21 2012 -0500
> >> 
> >>    powerpc/book3e: IBM Blue Gene/Q Boot
> >> 
> >>    This patch specifically deals with the initial program load
> >>    environment so that a boot image (dtbImage.bgq) can be loaded by the
> >>    BGQ management tools.  The boot code is a little odd because it has to
> >>    deal with the following issues:
> >>     - Linux boot image wrappers are 32-bit programs
> >>     - BGQ Tools only load 64bit ELF programs
> >>     - BGQ Firmware information is typically loaded at an address > 4G
> >>     - BGQ FW information contains 64-bit ABI function pointers (which are
> >>       actually function descriptors) to access firmware methods
> >>     - BGQ FW methods must be called in 64-bit mode
> >> 
> >>    Includes code contributed from:
> >>      Andrew Tauferner <ataufer@us.ibm.com>
> >>      Todd Inglett <tinglett@us.ibm.com>
> >>      Eric Van Hensbergen <ericvh@gmail.com>
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 3bc841935eb4955ce2b2db69bff16f7928464597
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Oct 31 22:36:54 2012 -0500
> >> 
> >>    powerpc/book3e: IBM Blue Gene/Q Platform and SMP
> >> 
> >>    This patch introduces BGQ as a platform and adds SMP functionality
> >> 
> >>    Includes code contributed from:
> >>      Andrew Tauferner <ataufer@us.ibm.com>
> >>      Todd Inglett <tinglett@us.ibm.com>
> >>      Eric Van Hensbergen <ericvh@gmail.com>
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 279c0615917b959a652e81f4ad0d886e2d426d85
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Dec 5 13:43:22 2012 -0500
> >> 
> >>    powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
> >> 
> >>    This enables kernel support for the QPX extention and is intended for
> >>    processors that support it, usually an IBM Blue Gene processor.
> >>    Turning it on does not effect other processors but it does add code
> >>    and will quadruple the per thread save and restore area for the FPU
> >>    (hense the name).  If you have enabled VSX it will only double the
> >>    space.
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 6ff45170ab0463fb34d7011e08c7e47c396f0fd7
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Fri Nov 23 14:52:14 2012 -0600
> >> 
> >>    powerpc/book3e: IBM Blue Gene/Q HVC Based Firmware Console
> >> 
> >>    New HVC device that uses the Blue Gene Firmware methods to erad and
> >>    write to console.
> >> 
> >>        Includes code contributed from:
> >>          Andrew Tauferner <ataufer@us.ibm.com>
> >>          Todd Inglett <tinglett@us.ibm.com>
> >>          Eric Van Hensbergen <ericvh@gmail.com>
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit e4ddc0c2ad8b3f0260d15d73e153095e95da84ac
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Thu Nov 29 15:52:04 2012 -0500
> >> 
> >>    powerpc/book3e: IBM Blue Gene/Q PCIe and MSI
> >> 
> >>    The following patch adds support for the BG/Q PCIe bridge and MSI interrupts.
> >> 
> >>    Includes code contributed from:
> >>      Jay S. Bryant <jsbryant@us.ibm.com>
> >>      Eric Van Hensbergen <ericvh@gmail.com>
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 9fc0b6f729f7bd7e31338283640a718fa4b1693b
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Wed Dec 5 07:01:49 2012 -0500
> >> 
> >>    powerpc/book3e: IBM Blue Gene/Q Character Drivers
> >> 
> >>    The following patch adds support for user and administration
> >>    applications to access the BG/Q control system.
> >> 
> >>    Includes code contributed from:
> >>      Jay S. Bryant <jsbryant@us.ibm.com>
> >>      Eric Van Hensbergen <ericvh@gmail.com>
> >> 
> >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> commit 9df2c4dfde0ac75f8b2bfcf565f78c2b7382b031
> >> Author: Jimi Xenidis <jimix@pobox.com>
> >> Date:   Thu Dec 6 18:07:16 2012 -0500
> >> 
> >>    Linux 3.4.22-BGQ-rc1
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >> 
> 

Re: [RFC] Add IBM Blue Gene/Q Platform

[Michael Neuling]

Jimi Xenidis <jimix@pobox.com> wrote:

> 
> On Dec 7, 2012, at 7:38 AM, Jimi Xenidis <jimix@pobox.com> wrote:
> 
> > 
> > On Dec 6, 2012, at 11:54 PM, Michael Neuling <mikey@neuling.org> wrote:
> > 
> >>> commit 279c0615917b959a652e81f4ad0d886e2d426d85
> >>> Author: Jimi Xenidis <jimix@pobox.com>
> >>> Date:   Wed Dec 5 13:43:22 2012 -0500
> >>> 
> >>>   powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
> >>> 
> >>>   This enables kernel support for the QPX extention and is intended for
> >>>   processors that support it, usually an IBM Blue Gene processor.
> >>>   Turning it on does not effect other processors but it does add code
> >>>   and will quadruple the per thread save and restore area for the FPU
> >>>   (hense the name).  If you have enabled VSX it will only double the
> >>>   space.
> >>> 
> >>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> 
> <<snip>>
> >> 
> >> 
> >> 
> >> +BEGIN_FTR_SECTION							\
> >> +	SAVE_32VSRS(n,c,base);						\
> >> +END_FTR_SECTION_IFSET(CPU_FTR_VSX);					\
> >> +BEGIN_FTR_SECTION							\
> >> +	SAVE_32QRS(n,c,base);						\
> >> +END_FTR_SECTION_IFSET(CPU_FTR_QPX);	
> >> 
> >> I don't think we want to do this.  We are going to end up with 64
> >> NOPS here somewhere.
> > 
> > Excellent point, NOPs are cheap on most processors but not A2 and a lot of embedded, I can wrap some branches with the FTR instead.
> > Do you have a concern on the code size?
> 
> Thought about it a bit and came up with this solution for arch/powerpc/kernel/fpu.S.
> This should address the following issues
>  - MSR_VSX vs MSR_VEC
>  - Big chunks of NOPs in the code path
>  - Less FTR space fixups at boot time.
>  - IMNHSO easier to read especially when disassembled

Indeed, I think it looks better.  I was going to mention that it was
already pretty complex to read, so a rewrite like this was probably
needed.  So thanks!!

That being said, there is a pretty complex testing matrix of
CONFIG_VSX/VMX/FPU/QPX/SMP/64/32 CPU_FTR/VSX/FPU/QPX/VMX so I'd need to
look/test more carefully to make sure all of these are covered.

Also, transactional memory (see
http://lists.ozlabs.org/pipermail/linuxppc-dev/2012-November/102216.html)
will change this code.  You should rebase on top of that if you really
want it considered for upstream.

Mikey

> 
> I did consider using the LR and BLR, but the !CONFIG_SMP case only adds one more special block and uses a different register set.
> Also if this is agreeable I would like us to consider removing the *_32FPVSRS* macros entirely and put the FTR tests in the actual code.
> This would allow us to use #ifdefs and reduce the amount of code that actually gets compiled.
> 
> Thoughts?
> 
> diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
> index e0ada05..5964067 100644
> --- a/arch/powerpc/kernel/fpu.S
> +++ b/arch/powerpc/kernel/fpu.S
> @@ -25,30 +25,81 @@
>  #include <asm/asm-offsets.h>
>  #include <asm/ptrace.h>
>  
> -#ifdef CONFIG_VSX
> -#define __REST_32FPVSRS(n,c,base)					\
> -BEGIN_FTR_SECTION							\
> -	b	2f;							\
> -END_FTR_SECTION_IFSET(CPU_FTR_VSX);					\
> -	REST_32FPRS(n,base);						\
> -	b	3f;							\
> -2:	REST_32VSRS(n,c,base);						\
> -3:
> -
> -#define __SAVE_32FPVSRS(n,c,base)					\
> -BEGIN_FTR_SECTION							\
> -	b	2f;							\
> -END_FTR_SECTION_IFSET(CPU_FTR_VSX);					\
> -	SAVE_32FPRS(n,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)
> -#endif
> -#define REST_32FPVSRS(n,c,base) __REST_32FPVSRS(n,__REG_##c,__REG_##base)
> -#define SAVE_32FPVSRS(n,c,base) __SAVE_32FPVSRS(n,__REG_##c,__REG_##base)
> +
> +/*
> + * Restore subroutines, R4 is scratch and R5 is base
> + */
> +vsx_restore:
> +	REST_32VSRS(0, __REG_R4, __REG_R5)
> +	b after_restore
> +qpx_restore:
> +	REST_32QRS(0, __REG_R4, __REG_R5)
> +	b after_restore
> +fpu_restore:
> +	REST_32FPRS(0, __REG_R5)
> +	b after_restore
> +
> +#define REST_32FPVSRS(n, c, base)		\
> +BEGIN_FTR_SECTION				\
> +	b vsx_restore;				\
> +END_FTR_SECTION_IFSET(CPU_FTR_VSX)		\
> +BEGIN_FTR_SECTION				\
> +	b qpx_restore;				\
> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)		\
> +	b fpu_restore;				\
> +after_restore:
> +
> +/*
> + * Save subroutines, R4 is scratch and R3 is base
> + */
> +vsx_save:
> +	SAVE_32VSRS(0, __REG_R4, __REG_R3)
> +	b after_save
> +qpx_save:
> +	SAVE_32QRS(0, __REG_R4, __REG_R3)
> +	b after_save
> +fpu_save:
> +	SAVE_32FPRS(0, __REG_R3)
> +	b after_save
> +
> +#define SAVE_32FPVSRS(n, c, base)		\
> +BEGIN_FTR_SECTION				\
> +	b vsx_save;				\
> +END_FTR_SECTION_IFSET(CPU_FTR_VSX)		\
> +BEGIN_FTR_SECTION				\
> +	b qpx_save;				\
> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)		\
> +	b fpu_save;				\
> +after_save:
> +
> +#ifndef CONFIG_SMP
> +/*
> + * we need an extra save set for the !CONFIG_SMP case, see below
> + * Scratch it R5 and base is R4
> + */
> +vsx_save_nosmp:
> +	SAVE_32VSRS(0,R5,R4)
> +	b after_save_nosmp
> +
> +qpx_save_nosmp:
> +	SAVE_32QRS(0,R5,R4)
> +	b after_save_nosmp
> +
> +fpu_save_nosmp:
> +	SAVE_32FPRS(0,R4)
> +	b after_save_nosmp
> +
> +#define SAVE_32FPVSRS_NOSMP(n,c,base)		\
> +BEGIN_FTR_SECTION				\
> +	b vsx_save_nosmp;			\
> +END_FTR_SECTION_IFSET(CPU_FTR_VSX)		\
> +BEGIN_FTR_SECTION				\
> +	b qpx_save_nosmp;			\
> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)		\
> +	b fpu_save_nosmp;			\
> +after_save_nosmp:
> +
> +#endif /* !CONFIG_SMP */
>  
>  /*
>   * This task wants to use the FPU now.
> @@ -65,6 +116,11 @@ BEGIN_FTR_SECTION
>  	oris	r5,r5,MSR_VSX@h
>  END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>  #endif
> +#ifdef CONFIG_PPC_QPX
> +BEGIN_FTR_SECTION
> +	oris	r5,r5,MSR_VEC@h
> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)
> +#endif
>  	SYNC
>  	MTMSRD(r5)			/* enable use of fpu now */
>  	isync
> @@ -81,7 +137,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>  	beq	1f
>  	toreal(r4)
>  	addi	r4,r4,THREAD		/* want last_task_used_math->thread */
> -	SAVE_32FPVSRS(0, R5, R4)
> +	SAVE_32FPVSRS_NOSMP(0, R5, R4)
>  	mffs	fr0
>  	stfd	fr0,THREAD_FPSCR(r4)
>  	PPC_LL	r5,PT_REGS(r4)
> @@ -94,7 +150,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>  #endif /* CONFIG_SMP */
>  	/* enable use of FP after return */
>  #ifdef CONFIG_PPC32
> -	mfspr	r5,SPRN_SPRG_THREAD		/* current task's THREAD (phys) */
> +	mfspr	r5,SPRN_SPRG_THREAD	/* current task's THREAD (phys) */
>  	lwz	r4,THREAD_FPEXC_MODE(r5)
>  	ori	r9,r9,MSR_FP		/* enable FP for current */
>  	or	r9,r9,r4
> @@ -132,6 +188,11 @@ BEGIN_FTR_SECTION
>  	oris	r5,r5,MSR_VSX@h
>  END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>  #endif
> +#ifdef CONFIG_PPC_QPX
> +BEGIN_FTR_SECTION
> +	oris	r5,r5,MSR_VEC@h
> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)
> +#endif
>  	SYNC_601
>  	ISYNC_601
>  	MTMSRD(r5)			/* enable use of fpu now */
> @@ -148,10 +209,10 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>  	beq	1f
>  	PPC_LL	r4,_MSR-STACK_FRAME_OVERHEAD(r5)
>  	li	r3,MSR_FP|MSR_FE0|MSR_FE1
> -#ifdef CONFIG_VSX
> +#if defined(CONFIG_VSX) || defined(CONFIG_PPC_QPX)
>  BEGIN_FTR_SECTION
>  	oris	r3,r3,MSR_VSX@h
> -END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> +END_FTR_SECTION_IFSET(CPU_FTR_VSX | CPU_FTR_QPX)
>  #endif
>  	andc	r4,r4,r3		/* disable FP for previous task */
>  	PPC_STL	r4,_MSR-STACK_FRAME_OVERHEAD(r5)
> 
> -jx
> 
> 
> > 
> >> 
> >> I'd like to see this patch broken into different parts.
> > 
> > I'm not sure how _this_ patch:
> >  <https://github.com/jimix/linux-bgq/commit/279c0615917b959a652e81f4ad0d886e2d426d85>
> > could be broken up, please advise.
> > 
> >> 
> >> Also, have you boot tested this change on a VSX enabled box?
> > 
> > I can try, I may bug you for help.
> > Is there a commonly test (or apps) I should run?
> > 
> > -jx
> > 
> > 
> >> 
> >> Mikey
> > 
> 

Re: [RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

On Dec 9, 2012, at 6:47 PM, Michael Neuling <mikey@neuling.org> wrote:

> Jimi Xenidis <jimix@pobox.com> wrote:
>=20
>>=20
>> On Dec 7, 2012, at 7:38 AM, Jimi Xenidis <jimix@pobox.com> wrote:
>>=20
>>>=20
>>> On Dec 6, 2012, at 11:54 PM, Michael Neuling <mikey@neuling.org> wrote:
>>>=20
>>>>> commit 279c0615917b959a652e81f4ad0d886e2d426d85
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Wed Dec 5 13:43:22 2012 -0500
>>>>>=20
>>>>>  powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
>>>>>=20
>>>>>  This enables kernel support for the QPX extention and is intended for=

>>>>>  processors that support it, usually an IBM Blue Gene processor.
>>>>>  Turning it on does not effect other processors but it does add code
>>>>>  and will quadruple the per thread save and restore area for the FPU
>>>>>  (hense the name).  If you have enabled VSX it will only double the
>>>>>  space.
>>>>>=20
>>>>>  Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>=20
>> <<snip>>
>>>>=20
>>>>=20
>>>>=20
>>>> +BEGIN_FTR_SECTION                            \
>>>> +    SAVE_32VSRS(n,c,base);                        \
>>>> +END_FTR_SECTION_IFSET(CPU_FTR_VSX);                    \
>>>> +BEGIN_FTR_SECTION                            \
>>>> +    SAVE_32QRS(n,c,base);                        \
>>>> +END_FTR_SECTION_IFSET(CPU_FTR_QPX);   =20
>>>>=20
>>>> I don't think we want to do this.  We are going to end up with 64
>>>> NOPS here somewhere.
>>>=20
>>> Excellent point, NOPs are cheap on most processors but not A2 and a lot o=
f embedded, I can wrap some branches with the FTR instead.
>>> Do you have a concern on the code size?
>>=20
>> Thought about it a bit and came up with this solution for arch/powerpc/ke=
rnel/fpu.S.
>> This should address the following issues
>> - MSR_VSX vs MSR_VEC
>> - Big chunks of NOPs in the code path
>> - Less FTR space fixups at boot time.
>> - IMNHSO easier to read especially when disassembled
>=20
> Indeed, I think it looks better.  I was going to mention that it was
> already pretty complex to read, so a rewrite like this was probably
> needed.  So thanks!!
>=20
> That being said, there is a pretty complex testing matrix of
> CONFIG_VSX/VMX/FPU/QPX/SMP/64/32 CPU_FTR/VSX/FPU/QPX/VMX so I'd need to
> look/test more carefully to make sure all of these are covered.
>=20
> Also, transactional memory (see
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2012-November/102216.html)
> will change this code.  You should rebase on top of that if you really
> want it considered for upstream.

Is this in a git tree anywhere? perhaps BenH's next branch?
-jx

>=20
> Mikey
>=20
>>=20
>> I did consider using the LR and BLR, but the !CONFIG_SMP case only adds o=
ne more special block and uses a different register set.
>> Also if this is agreeable I would like us to consider removing the *_32FP=
VSRS* macros entirely and put the FTR tests in the actual code.
>> This would allow us to use #ifdefs and reduce the amount of code that act=
ually gets compiled.
>>=20
>> Thoughts?
>>=20
>> diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
>> index e0ada05..5964067 100644
>> --- a/arch/powerpc/kernel/fpu.S
>> +++ b/arch/powerpc/kernel/fpu.S
>> @@ -25,30 +25,81 @@
>> #include <asm/asm-offsets.h>
>> #include <asm/ptrace.h>
>>=20
>> -#ifdef CONFIG_VSX
>> -#define __REST_32FPVSRS(n,c,base)                    \
>> -BEGIN_FTR_SECTION                            \
>> -    b    2f;                            \
>> -END_FTR_SECTION_IFSET(CPU_FTR_VSX);                    \
>> -    REST_32FPRS(n,base);                        \
>> -    b    3f;                            \
>> -2:    REST_32VSRS(n,c,base);                        \
>> -3:
>> -
>> -#define __SAVE_32FPVSRS(n,c,base)                    \
>> -BEGIN_FTR_SECTION                            \
>> -    b    2f;                            \
>> -END_FTR_SECTION_IFSET(CPU_FTR_VSX);                    \
>> -    SAVE_32FPRS(n,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)
>> -#endif
>> -#define REST_32FPVSRS(n,c,base) __REST_32FPVSRS(n,__REG_##c,__REG_##base=
)
>> -#define SAVE_32FPVSRS(n,c,base) __SAVE_32FPVSRS(n,__REG_##c,__REG_##base=
)
>> +
>> +/*
>> + * Restore subroutines, R4 is scratch and R5 is base
>> + */
>> +vsx_restore:
>> +    REST_32VSRS(0, __REG_R4, __REG_R5)
>> +    b after_restore
>> +qpx_restore:
>> +    REST_32QRS(0, __REG_R4, __REG_R5)
>> +    b after_restore
>> +fpu_restore:
>> +    REST_32FPRS(0, __REG_R5)
>> +    b after_restore
>> +
>> +#define REST_32FPVSRS(n, c, base)        \
>> +BEGIN_FTR_SECTION                \
>> +    b vsx_restore;                \
>> +END_FTR_SECTION_IFSET(CPU_FTR_VSX)        \
>> +BEGIN_FTR_SECTION                \
>> +    b qpx_restore;                \
>> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)        \
>> +    b fpu_restore;                \
>> +after_restore:
>> +
>> +/*
>> + * Save subroutines, R4 is scratch and R3 is base
>> + */
>> +vsx_save:
>> +    SAVE_32VSRS(0, __REG_R4, __REG_R3)
>> +    b after_save
>> +qpx_save:
>> +    SAVE_32QRS(0, __REG_R4, __REG_R3)
>> +    b after_save
>> +fpu_save:
>> +    SAVE_32FPRS(0, __REG_R3)
>> +    b after_save
>> +
>> +#define SAVE_32FPVSRS(n, c, base)        \
>> +BEGIN_FTR_SECTION                \
>> +    b vsx_save;                \
>> +END_FTR_SECTION_IFSET(CPU_FTR_VSX)        \
>> +BEGIN_FTR_SECTION                \
>> +    b qpx_save;                \
>> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)        \
>> +    b fpu_save;                \
>> +after_save:
>> +
>> +#ifndef CONFIG_SMP
>> +/*
>> + * we need an extra save set for the !CONFIG_SMP case, see below
>> + * Scratch it R5 and base is R4
>> + */
>> +vsx_save_nosmp:
>> +    SAVE_32VSRS(0,R5,R4)
>> +    b after_save_nosmp
>> +
>> +qpx_save_nosmp:
>> +    SAVE_32QRS(0,R5,R4)
>> +    b after_save_nosmp
>> +
>> +fpu_save_nosmp:
>> +    SAVE_32FPRS(0,R4)
>> +    b after_save_nosmp
>> +
>> +#define SAVE_32FPVSRS_NOSMP(n,c,base)        \
>> +BEGIN_FTR_SECTION                \
>> +    b vsx_save_nosmp;            \
>> +END_FTR_SECTION_IFSET(CPU_FTR_VSX)        \
>> +BEGIN_FTR_SECTION                \
>> +    b qpx_save_nosmp;            \
>> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)        \
>> +    b fpu_save_nosmp;            \
>> +after_save_nosmp:
>> +
>> +#endif /* !CONFIG_SMP */
>>=20
>> /*
>>  * This task wants to use the FPU now.
>> @@ -65,6 +116,11 @@ BEGIN_FTR_SECTION
>>    oris    r5,r5,MSR_VSX@h
>> END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>> #endif
>> +#ifdef CONFIG_PPC_QPX
>> +BEGIN_FTR_SECTION
>> +    oris    r5,r5,MSR_VEC@h
>> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)
>> +#endif
>>    SYNC
>>    MTMSRD(r5)            /* enable use of fpu now */
>>    isync
>> @@ -81,7 +137,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>>    beq    1f
>>    toreal(r4)
>>    addi    r4,r4,THREAD        /* want last_task_used_math->thread */
>> -    SAVE_32FPVSRS(0, R5, R4)
>> +    SAVE_32FPVSRS_NOSMP(0, R5, R4)
>>    mffs    fr0
>>    stfd    fr0,THREAD_FPSCR(r4)
>>    PPC_LL    r5,PT_REGS(r4)
>> @@ -94,7 +150,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>> #endif /* CONFIG_SMP */
>>    /* enable use of FP after return */
>> #ifdef CONFIG_PPC32
>> -    mfspr    r5,SPRN_SPRG_THREAD        /* current task's THREAD (phys) *=
/
>> +    mfspr    r5,SPRN_SPRG_THREAD    /* current task's THREAD (phys) */
>>    lwz    r4,THREAD_FPEXC_MODE(r5)
>>    ori    r9,r9,MSR_FP        /* enable FP for current */
>>    or    r9,r9,r4
>> @@ -132,6 +188,11 @@ BEGIN_FTR_SECTION
>>    oris    r5,r5,MSR_VSX@h
>> END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>> #endif
>> +#ifdef CONFIG_PPC_QPX
>> +BEGIN_FTR_SECTION
>> +    oris    r5,r5,MSR_VEC@h
>> +END_FTR_SECTION_IFSET(CPU_FTR_QPX)
>> +#endif
>>    SYNC_601
>>    ISYNC_601
>>    MTMSRD(r5)            /* enable use of fpu now */
>> @@ -148,10 +209,10 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>>    beq    1f
>>    PPC_LL    r4,_MSR-STACK_FRAME_OVERHEAD(r5)
>>    li    r3,MSR_FP|MSR_FE0|MSR_FE1
>> -#ifdef CONFIG_VSX
>> +#if defined(CONFIG_VSX) || defined(CONFIG_PPC_QPX)
>> BEGIN_FTR_SECTION
>>    oris    r3,r3,MSR_VSX@h
>> -END_FTR_SECTION_IFSET(CPU_FTR_VSX)
>> +END_FTR_SECTION_IFSET(CPU_FTR_VSX | CPU_FTR_QPX)
>> #endif
>>    andc    r4,r4,r3        /* disable FP for previous task */
>>    PPC_STL    r4,_MSR-STACK_FRAME_OVERHEAD(r5)
>>=20
>> -jx
>>=20
>>=20
>>>=20
>>>>=20
>>>> I'd like to see this patch broken into different parts.
>>>=20
>>> I'm not sure how _this_ patch:
>>> <https://github.com/jimix/linux-bgq/commit/279c0615917b959a652e81f4ad0d8=
86e2d426d85>
>>> could be broken up, please advise.
>>>=20
>>>>=20
>>>> Also, have you boot tested this change on a VSX enabled box?
>>>=20
>>> I can try, I may bug you for help.
>>> Is there a commonly test (or apps) I should run?
>>>=20
>>> -jx
>>>=20
>>>=20
>>>>=20
>>>> Mikey
>>=20

Re: [RFC] Add IBM Blue Gene/Q Platform

[Michael Neuling]

Jimi Xenidis <jimix@pobox.com> wrote:

> 
> 
> On Dec 9, 2012, at 6:47 PM, Michael Neuling <mikey@neuling.org> wrote:
> 
> > Jimi Xenidis <jimix@pobox.com> wrote:
> > 
> >> 
> >> On Dec 7, 2012, at 7:38 AM, Jimi Xenidis <jimix@pobox.com> wrote:
> >> 
> >>> 
> >>> On Dec 6, 2012, at 11:54 PM, Michael Neuling <mikey@neuling.org> wrote:
> >>> 
> >>>>> commit 279c0615917b959a652e81f4ad0d886e2d426d85
> >>>>> Author: Jimi Xenidis <jimix@pobox.com>
> >>>>> Date:   Wed Dec 5 13:43:22 2012 -0500
> >>>>> 
> >>>>>  powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
> >>>>> 
> >>>>>  This enables kernel support for the QPX extention and is intended for
> >>>>>  processors that support it, usually an IBM Blue Gene processor.
> >>>>>  Turning it on does not effect other processors but it does add code
> >>>>>  and will quadruple the per thread save and restore area for the FPU
> >>>>>  (hense the name).  If you have enabled VSX it will only double the
> >>>>>  space.
> >>>>> 
> >>>>>  Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> >> 
> >> <<snip>>
> >>>> 
> >>>> 
> >>>> 
> >>>> +BEGIN_FTR_SECTION                            \
> >>>> +    SAVE_32VSRS(n,c,base);                        \
> >>>> +END_FTR_SECTION_IFSET(CPU_FTR_VSX);                    \
> >>>> +BEGIN_FTR_SECTION                            \
> >>>> +    SAVE_32QRS(n,c,base);                        \
> >>>> +END_FTR_SECTION_IFSET(CPU_FTR_QPX);    
> >>>> 
> >>>> I don't think we want to do this.  We are going to end up with 64
> >>>> NOPS here somewhere.
> >>> 
> >>> Excellent point, NOPs are cheap on most processors but not A2 and a lot of embedded, I can wrap some branches with the FTR instead.
> >>> Do you have a concern on the code size?
> >> 
> >> Thought about it a bit and came up with this solution for arch/powerpc/kernel/fpu.S.
> >> This should address the following issues
> >> - MSR_VSX vs MSR_VEC
> >> - Big chunks of NOPs in the code path
> >> - Less FTR space fixups at boot time.
> >> - IMNHSO easier to read especially when disassembled
> > 
> > Indeed, I think it looks better.  I was going to mention that it was
> > already pretty complex to read, so a rewrite like this was probably
> > needed.  So thanks!!
> > 
> > That being said, there is a pretty complex testing matrix of
> > CONFIG_VSX/VMX/FPU/QPX/SMP/64/32 CPU_FTR/VSX/FPU/QPX/VMX so I'd need to
> > look/test more carefully to make sure all of these are covered.
> > 
> > Also, transactional memory (see
> > http://lists.ozlabs.org/pipermail/linuxppc-dev/2012-November/102216.html)
> > will change this code.  You should rebase on top of that if you really
> > want it considered for upstream.
> 
> Is this in a git tree anywhere? perhaps BenH's next branch?

It's not in benh's tree as yet (so could change).

Grab the power8 branch here git://github.com/mikey/linux.git
or checkout https://github.com/mikey/linux/commits/power8.

It's about 20 patches on top of benh's next tree.  Also includes the
power8 doorbell changes from Ian.

Mikey

Re: [RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

On Dec 7, 2012, at 8:31 AM, Andrew Tauferner <ataufer@us.ibm.com> wrote:

> Jimi,
>=20
> > > Do you actually want this upstream?  I assume no.
> >=20
> > I needed to get these long-term patches out there for the BGQ=20
> > community for test.
>=20
> To which BGQ community are you referring?

This work is being done by IBM Research (me) and made possible by the =
US-DOE via:
  <https://sites.google.com/site/foxxstack/project-updates>

>  What is the motivation for this work?

Maintain a modern kernel that has a "reasonable" set of patches that, =
with the much appreciated feedback from the Linux community, _could_ go =
upstream.

>=20
> > I would very much like to get a version of these upstream.
> > I expect only the QPX, kexec, and (maybe) the DCR changes to cause=20=

> > any controversy, but I've been wrong before.
>=20
> Hehe.  Ben had a variety of issues with the BG/Q firmware when he=20
> gave me some feedback a few years ago.

Yup, I think I have addressed these issues.

>=20
> > I'll be making those patches soon and hope to get a lot of feedback=20=

> > from these patches.
>=20
> What was the starting point for this work?  On what is it based?

  =
<https://repo.anl-external.org/viewvc/bgq-driver/V1R1M2/?sortdir=3Ddown>>

-jx


>=20
> > -jx
> >=20
> >=20
> > >=20
> > > Mikey
> > >=20
> > >>=20
> > >> Here is a are the summary logs:
> > >>=20
> > >> $ git log --reverse linux-stable/linux-3.4.y..
> > >> commit 5a8edb2bdd914597693eed299119ff4c2e6d31f2
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Fri Nov 9 09:26:00 2012 -0600
> > >>=20
> > >>    powerpc: Fix cputable #ifdef where CONFIG_PPC_A2 is used for=20=

> > CONFIG_PPC_BOOK3E_64
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit ea51920d7035c8d23801d6de46261e7d0a537dfd
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Fri Nov 9 08:58:27 2012 -0600
> > >>=20
> > >>    powerpc/book3e: Remove config for PPC_A2_DD2 since there is no
> > reference to it
> > >>=20
> > >>    This must have been leftover from early DD1 days which is not
> > >>    present in any current kernel code.
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 08151401a5db4ff0d441a1b7bf8ad92bd92b14c5
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Mon Nov 5 09:38:01 2012 -0600
> > >>=20
> > >>    powerpc/dcr: Some native DCR fixes
> > >>=20
> > >>    The following fixes have been made:
> > >>     - dcr_read/write_native() must use the indexed version of the
> > >>       m[ft]dcrx since the non-indexed version only allows a =
10-bit
> > >>       numerical space, but the C interface allows a full 32-bits.
> > >>     - C bindings for m[ft]dcrx, and the "table" versions, should =
use
> > >>       "unsigned long" so that they are 64/32 bit neutral.
> > >>     - The "table" versions (__m[ft]cdr) should obtain the table =
address
> > >>       with LOAD_REG_ADDR(), this will also make it 64/32bit =
neutral.
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit c8320a5daaceed03992d763302020834ea8e17dd
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Mon Nov 5 09:12:00 2012 -0600
> > >>=20
> > >>    powerpc/dcr: Add 64-bit DCR access methods.
> > >>=20
> > >>    This patch adds the ability to make 64-bit Device Control =
Register
> > >>    (DCR) accesses.
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit a763b3f8453b3bd83d7dded8c6644939863af430
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Thu Nov 29 12:49:24 2012 -0500
> > >>=20
> > >>    powerpc/boot: Add a "spin_threads" hook to platform_ops
> > >>=20
> > >>    It is useful for the boot program to arrange for all secondary =
cpus
> > >>    and threads to enter the kernel in a "kexec" fashion.  This =
hook makes
> > >>    it possible.
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 391e43393380b514d4d02a42d059619542c7597b
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Thu Nov 29 13:01:23 2012 -0500
> > >>=20
> > >>    powerpc/kexec: Add kexec "hold" support for Book3e processors
> > >>=20
> > >>    This patch add two items:
> > >>    1) Book3e requires that GPR4 survive the "hold" process, so we =
make
> > >>       sure that happens.
> > >>    2) Book3e has no real mode, and the hold code exploits this.  =
Since
> > >>       these processors ares always translated, we arrange for the =
kexeced
> > >>       threads to enter the hold code using the normal kernel=20
> > linear mapping.
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Wed Dec 5 13:41:25 2012 -0500
> > >>=20
> > >>    powerpc: Remove unecessary VSX symbols
> > >>=20
> > >>    The symbol THREAD_VSR0 is defined to be the same as =
THREAD_FPR0.  Its
> > >>    presence causes build issues with more complex configurations.
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 4e817bb42ec8e3d3689877528dd97c4286a870eb
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Tue Nov 20 10:10:52 2012 -0600
> > >>=20
> > >>    Blue Gene/Q wicked optimizing compiler does not know the rfdi=20=

> > instruction yet
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 2071aa58b2f3b33d97c94e3a127f7c5d4ffaeb34
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Tue Nov 20 10:14:22 2012 -0600
> > >>=20
> > >>    Blue Gene/Q wicked optimizing compiler does not know the=20
> > mfdcrx instruction yet
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 6e58088fabedbb2d724637b539ba180c03ed8b68
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Wed Oct 31 16:33:21 2012 -0500
> > >>=20
> > >>    powerpc/book3e: IBM Blue Gene/Q Boot
> > >>=20
> > >>    This patch specifically deals with the initial program load
> > >>    environment so that a boot image (dtbImage.bgq) can be loaded =
by the
> > >>    BGQ management tools.  The boot code is a little odd because =
it has to
> > >>    deal with the following issues:
> > >>     - Linux boot image wrappers are 32-bit programs
> > >>     - BGQ Tools only load 64bit ELF programs
> > >>     - BGQ Firmware information is typically loaded at an address =
> 4G
> > >>     - BGQ FW information contains 64-bit ABI function pointers =
(which are
> > >>       actually function descriptors) to access firmware methods
> > >>     - BGQ FW methods must be called in 64-bit mode
> > >>=20
> > >>    Includes code contributed from:
> > >>      Andrew Tauferner <ataufer@us.ibm.com>
> > >>      Todd Inglett <tinglett@us.ibm.com>
> > >>      Eric Van Hensbergen <ericvh@gmail.com>
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 3bc841935eb4955ce2b2db69bff16f7928464597
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Wed Oct 31 22:36:54 2012 -0500
> > >>=20
> > >>    powerpc/book3e: IBM Blue Gene/Q Platform and SMP
> > >>=20
> > >>    This patch introduces BGQ as a platform and adds SMP =
functionality
> > >>=20
> > >>    Includes code contributed from:
> > >>      Andrew Tauferner <ataufer@us.ibm.com>
> > >>      Todd Inglett <tinglett@us.ibm.com>
> > >>      Eric Van Hensbergen <ericvh@gmail.com>
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 279c0615917b959a652e81f4ad0d886e2d426d85
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Wed Dec 5 13:43:22 2012 -0500
> > >>=20
> > >>    powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention =
(QPX)
> > >>=20
> > >>    This enables kernel support for the QPX extention and is =
intended for
> > >>    processors that support it, usually an IBM Blue Gene =
processor.
> > >>    Turning it on does not effect other processors but it does add =
code
> > >>    and will quadruple the per thread save and restore area for =
the FPU
> > >>    (hense the name).  If you have enabled VSX it will only double =
the
> > >>    space.
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 6ff45170ab0463fb34d7011e08c7e47c396f0fd7
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Fri Nov 23 14:52:14 2012 -0600
> > >>=20
> > >>    powerpc/book3e: IBM Blue Gene/Q HVC Based Firmware Console
> > >>=20
> > >>    New HVC device that uses the Blue Gene Firmware methods to =
erad and
> > >>    write to console.
> > >>=20
> > >>        Includes code contributed from:
> > >>          Andrew Tauferner <ataufer@us.ibm.com>
> > >>          Todd Inglett <tinglett@us.ibm.com>
> > >>          Eric Van Hensbergen <ericvh@gmail.com>
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit e4ddc0c2ad8b3f0260d15d73e153095e95da84ac
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Thu Nov 29 15:52:04 2012 -0500
> > >>=20
> > >>    powerpc/book3e: IBM Blue Gene/Q PCIe and MSI
> > >>=20
> > >>    The following patch adds support for the BG/Q PCIe bridge and=20=

> > MSI interrupts.
> > >>=20
> > >>    Includes code contributed from:
> > >>      Jay S. Bryant <jsbryant@us.ibm.com>
> > >>      Eric Van Hensbergen <ericvh@gmail.com>
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 9fc0b6f729f7bd7e31338283640a718fa4b1693b
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Wed Dec 5 07:01:49 2012 -0500
> > >>=20
> > >>    powerpc/book3e: IBM Blue Gene/Q Character Drivers
> > >>=20
> > >>    The following patch adds support for user and administration
> > >>    applications to access the BG/Q control system.
> > >>=20
> > >>    Includes code contributed from:
> > >>      Jay S. Bryant <jsbryant@us.ibm.com>
> > >>      Eric Van Hensbergen <ericvh@gmail.com>
> > >>=20
> > >>    Signed-off-by: Jimi Xenidis <jimix@pobox.com>
> > >>=20
> > >> commit 9df2c4dfde0ac75f8b2bfcf565f78c2b7382b031
> > >> Author: Jimi Xenidis <jimix@pobox.com>
> > >> Date:   Thu Dec 6 18:07:16 2012 -0500
> > >>=20
> > >>    Linux 3.4.22-BGQ-rc1
> > >>=20
> > >>=20
> > >>=20
> > >>=20
> > >> _______________________________________________
> > >> Linuxppc-dev mailing list
> > >> Linuxppc-dev@lists.ozlabs.org
> > >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> > >>=20
> >=20
>=20

Re: [RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

On Dec 10, 2012, at 3:32 PM, Jimi Xenidis <jimix@pobox.com> wrote:

>=20
> On Dec 7, 2012, at 8:31 AM, Andrew Tauferner <ataufer@us.ibm.com> =
wrote:
>=20
>> Jimi,
>>=20
>>>> Do you actually want this upstream?  I assume no.
>>>=20
>>> I needed to get these long-term patches out there for the BGQ=20
>>> community for test.
>>=20
>> To which BGQ community are you referring?
>=20
> This work is being done by IBM Research (me) and made possible by the =
US-DOE via:
>  <https://sites.google.com/site/foxxstack/project-updates>
>=20
>> What is the motivation for this work?
>=20
> Maintain a modern kernel that has a "reasonable" set of patches that, =
with the much appreciated feedback from the Linux community, _could_ go =
upstream.
>=20
>>=20
>>> I would very much like to get a version of these upstream.
>>> I expect only the QPX, kexec, and (maybe) the DCR changes to cause=20=

>>> any controversy, but I've been wrong before.
>>=20
>> Hehe.  Ben had a variety of issues with the BG/Q firmware when he=20
>> gave me some feedback a few years ago.
>=20
> Yup, I think I have addressed these issues.
>=20
>>=20
>>> I'll be making those patches soon and hope to get a lot of feedback=20=

>>> from these patches.
>>=20
>> What was the starting point for this work?  On what is it based?
>=20
>  =
<https://repo.anl-external.org/viewvc/bgq-driver/V1R1M2/?sortdir=3Ddown>>

I should add that these patches have been heavily modified to meet =
requirements and suggestions of BenH and others.
-jx


>=20
> -jx
>=20
>=20
>>=20
>>> -jx
>>>=20
>>>=20
>>>>=20
>>>> Mikey
>>>>=20
>>>>>=20
>>>>> Here is a are the summary logs:
>>>>>=20
>>>>> $ git log --reverse linux-stable/linux-3.4.y..
>>>>> commit 5a8edb2bdd914597693eed299119ff4c2e6d31f2
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Fri Nov 9 09:26:00 2012 -0600
>>>>>=20
>>>>>   powerpc: Fix cputable #ifdef where CONFIG_PPC_A2 is used for=20
>>> CONFIG_PPC_BOOK3E_64
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit ea51920d7035c8d23801d6de46261e7d0a537dfd
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Fri Nov 9 08:58:27 2012 -0600
>>>>>=20
>>>>>   powerpc/book3e: Remove config for PPC_A2_DD2 since there is no
>>> reference to it
>>>>>=20
>>>>>   This must have been leftover from early DD1 days which is not
>>>>>   present in any current kernel code.
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 08151401a5db4ff0d441a1b7bf8ad92bd92b14c5
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Mon Nov 5 09:38:01 2012 -0600
>>>>>=20
>>>>>   powerpc/dcr: Some native DCR fixes
>>>>>=20
>>>>>   The following fixes have been made:
>>>>>    - dcr_read/write_native() must use the indexed version of the
>>>>>      m[ft]dcrx since the non-indexed version only allows a 10-bit
>>>>>      numerical space, but the C interface allows a full 32-bits.
>>>>>    - C bindings for m[ft]dcrx, and the "table" versions, should =
use
>>>>>      "unsigned long" so that they are 64/32 bit neutral.
>>>>>    - The "table" versions (__m[ft]cdr) should obtain the table =
address
>>>>>      with LOAD_REG_ADDR(), this will also make it 64/32bit =
neutral.
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit c8320a5daaceed03992d763302020834ea8e17dd
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Mon Nov 5 09:12:00 2012 -0600
>>>>>=20
>>>>>   powerpc/dcr: Add 64-bit DCR access methods.
>>>>>=20
>>>>>   This patch adds the ability to make 64-bit Device Control =
Register
>>>>>   (DCR) accesses.
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit a763b3f8453b3bd83d7dded8c6644939863af430
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Thu Nov 29 12:49:24 2012 -0500
>>>>>=20
>>>>>   powerpc/boot: Add a "spin_threads" hook to platform_ops
>>>>>=20
>>>>>   It is useful for the boot program to arrange for all secondary =
cpus
>>>>>   and threads to enter the kernel in a "kexec" fashion.  This hook =
makes
>>>>>   it possible.
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 391e43393380b514d4d02a42d059619542c7597b
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Thu Nov 29 13:01:23 2012 -0500
>>>>>=20
>>>>>   powerpc/kexec: Add kexec "hold" support for Book3e processors
>>>>>=20
>>>>>   This patch add two items:
>>>>>   1) Book3e requires that GPR4 survive the "hold" process, so we =
make
>>>>>      sure that happens.
>>>>>   2) Book3e has no real mode, and the hold code exploits this.  =
Since
>>>>>      these processors ares always translated, we arrange for the =
kexeced
>>>>>      threads to enter the hold code using the normal kernel=20
>>> linear mapping.
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Wed Dec 5 13:41:25 2012 -0500
>>>>>=20
>>>>>   powerpc: Remove unecessary VSX symbols
>>>>>=20
>>>>>   The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0. =
 Its
>>>>>   presence causes build issues with more complex configurations.
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 4e817bb42ec8e3d3689877528dd97c4286a870eb
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Tue Nov 20 10:10:52 2012 -0600
>>>>>=20
>>>>>   Blue Gene/Q wicked optimizing compiler does not know the rfdi=20
>>> instruction yet
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 2071aa58b2f3b33d97c94e3a127f7c5d4ffaeb34
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Tue Nov 20 10:14:22 2012 -0600
>>>>>=20
>>>>>   Blue Gene/Q wicked optimizing compiler does not know the=20
>>> mfdcrx instruction yet
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 6e58088fabedbb2d724637b539ba180c03ed8b68
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Wed Oct 31 16:33:21 2012 -0500
>>>>>=20
>>>>>   powerpc/book3e: IBM Blue Gene/Q Boot
>>>>>=20
>>>>>   This patch specifically deals with the initial program load
>>>>>   environment so that a boot image (dtbImage.bgq) can be loaded by =
the
>>>>>   BGQ management tools.  The boot code is a little odd because it =
has to
>>>>>   deal with the following issues:
>>>>>    - Linux boot image wrappers are 32-bit programs
>>>>>    - BGQ Tools only load 64bit ELF programs
>>>>>    - BGQ Firmware information is typically loaded at an address > =
4G
>>>>>    - BGQ FW information contains 64-bit ABI function pointers =
(which are
>>>>>      actually function descriptors) to access firmware methods
>>>>>    - BGQ FW methods must be called in 64-bit mode
>>>>>=20
>>>>>   Includes code contributed from:
>>>>>     Andrew Tauferner <ataufer@us.ibm.com>
>>>>>     Todd Inglett <tinglett@us.ibm.com>
>>>>>     Eric Van Hensbergen <ericvh@gmail.com>
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 3bc841935eb4955ce2b2db69bff16f7928464597
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Wed Oct 31 22:36:54 2012 -0500
>>>>>=20
>>>>>   powerpc/book3e: IBM Blue Gene/Q Platform and SMP
>>>>>=20
>>>>>   This patch introduces BGQ as a platform and adds SMP =
functionality
>>>>>=20
>>>>>   Includes code contributed from:
>>>>>     Andrew Tauferner <ataufer@us.ibm.com>
>>>>>     Todd Inglett <tinglett@us.ibm.com>
>>>>>     Eric Van Hensbergen <ericvh@gmail.com>
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 279c0615917b959a652e81f4ad0d886e2d426d85
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Wed Dec 5 13:43:22 2012 -0500
>>>>>=20
>>>>>   powerpc/book3e: IBM Blue Gene/Q Quad Processing eXtention (QPX)
>>>>>=20
>>>>>   This enables kernel support for the QPX extention and is =
intended for
>>>>>   processors that support it, usually an IBM Blue Gene processor.
>>>>>   Turning it on does not effect other processors but it does add =
code
>>>>>   and will quadruple the per thread save and restore area for the =
FPU
>>>>>   (hense the name).  If you have enabled VSX it will only double =
the
>>>>>   space.
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 6ff45170ab0463fb34d7011e08c7e47c396f0fd7
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Fri Nov 23 14:52:14 2012 -0600
>>>>>=20
>>>>>   powerpc/book3e: IBM Blue Gene/Q HVC Based Firmware Console
>>>>>=20
>>>>>   New HVC device that uses the Blue Gene Firmware methods to erad =
and
>>>>>   write to console.
>>>>>=20
>>>>>       Includes code contributed from:
>>>>>         Andrew Tauferner <ataufer@us.ibm.com>
>>>>>         Todd Inglett <tinglett@us.ibm.com>
>>>>>         Eric Van Hensbergen <ericvh@gmail.com>
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit e4ddc0c2ad8b3f0260d15d73e153095e95da84ac
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Thu Nov 29 15:52:04 2012 -0500
>>>>>=20
>>>>>   powerpc/book3e: IBM Blue Gene/Q PCIe and MSI
>>>>>=20
>>>>>   The following patch adds support for the BG/Q PCIe bridge and=20
>>> MSI interrupts.
>>>>>=20
>>>>>   Includes code contributed from:
>>>>>     Jay S. Bryant <jsbryant@us.ibm.com>
>>>>>     Eric Van Hensbergen <ericvh@gmail.com>
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 9fc0b6f729f7bd7e31338283640a718fa4b1693b
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Wed Dec 5 07:01:49 2012 -0500
>>>>>=20
>>>>>   powerpc/book3e: IBM Blue Gene/Q Character Drivers
>>>>>=20
>>>>>   The following patch adds support for user and administration
>>>>>   applications to access the BG/Q control system.
>>>>>=20
>>>>>   Includes code contributed from:
>>>>>     Jay S. Bryant <jsbryant@us.ibm.com>
>>>>>     Eric Van Hensbergen <ericvh@gmail.com>
>>>>>=20
>>>>>   Signed-off-by: Jimi Xenidis <jimix@pobox.com>
>>>>>=20
>>>>> commit 9df2c4dfde0ac75f8b2bfcf565f78c2b7382b031
>>>>> Author: Jimi Xenidis <jimix@pobox.com>
>>>>> Date:   Thu Dec 6 18:07:16 2012 -0500
>>>>>=20
>>>>>   Linux 3.4.22-BGQ-rc1
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> Linuxppc-dev mailing list
>>>>> Linuxppc-dev@lists.ozlabs.org
>>>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>>>>=20
>>>=20
>>=20
>=20