This condenses the opal node searching into a single function that finds
all compatible nodes, instead of just searching the ibm,opal children,
for ipmi, flash, and prd similar to how opal-i2c nodes are found.
Signed-off-by: Jack Miller
---
arch/powerpc/platforms/powernv/opal.c | 24
On Thu, Aug 04, 2016 at 06:39:24PM +1000, Michael Ellerman wrote:
> Cyril Bur writes:
>
> > On Wed, 3 Aug 2016 12:18:00 -0500
> > Jack Miller wrote:
> >
> >> (rebased on powerpc/next)
> >>
> >> This condenses the opal node searching into a s
(rebased on powerpc/next)
This condenses the opal node searching into a single function that finds
all compatible nodes, instead of just searching the ibm,opal children,
for ipmi, flash, and prd similar to how opal-i2c nodes are found.
Signed-off-by: Jack Miller
---
arch/powerpc/platforms
This condenses the opal node searching into a single function that finds
all compatible nodes, instead of just searching the ibm,opal children,
for ipmi, flash, and prd similar to how opal-i2c nodes are found.
Signed-off-by: Jack Miller
---
arch/powerpc/platforms/powernv/opal.c | 22
On Wed, Aug 03, 2016 at 05:16:34PM +1000, Michael Ellerman wrote:
> We could instead just search for all nodes that are compatible with
> "ibm,opal-flash". We do that for i2c, see opal_i2c_create_devs().
>
> Is there a particular reason not to do that?
I'm actually surprised that this is preferre
For reference, here's a link to the skiboot patch on the list
https://lists.ozlabs.org/pipermail/skiboot/2016-August/004274.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Skiboot will place the flash device tree node at ibm,opal/flash/flash@0
on P9 and later systems, so Linux needs to search for it there as well
as ibm,opal/flash@0 for backwards compatibility.
Signed-off-by: Jack Miller
---
arch/powerpc/platforms/powernv/opal.c | 7 ++-
1 file changed, 6
Adds two tests. One is a simple test to ensure that the new registers
LMRR and LMSER are properly maintained. The other actually uses the
existing EBB test infrastructure to test that LMRR and LMSER behave as
documented.
Signed-off-by: Jack Miller
---
tools/testing/selftests/powerpc/pmu/ebb
when a facility unavailable exception is taken for using it. On context
switch, this bit is then used to determine whether the two relevant
registers are saved and restored. This is done lazily for performance
reasons.
Signed-off-by: Jack Miller
---
arch/powerpc/include/asm/processor.h | 2
Previous spin:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-April/141846.html
Now with 100% less 32 bit build breakage.
Mikey already called me on this one, not sure how it got back in?
- Jack
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.
Previously we just saved the FSCR, but only restored it in some
settings, and never copied it thread to thread. This patch always
restores the FSCR and formalizes new threads inheriting its setting so
that later we can manipulate FSCR bits in start_thread.
Signed-off-by: Jack Miller
---
arch
Adds two tests. One is a simple test to ensure that the new registers
LMRR and LMSER are properly maintained. The other actually uses the
existing EBB test infrastructure to test that LMRR and LMSER behave as
documented.
Signed-off-by: Jack Miller
---
tools/testing/selftests/powerpc/pmu/ebb
when a facility unavailable exception is taken for using it. On context
switch, this bit is then used to determine whether the two relevant
registers are saved and restored. This is done lazily for performance
reasons.
Signed-off-by: Jack Miller
---
arch/powerpc/include/asm/processor.h | 2
Previously we just saved the FSCR, but only restored it in some
settings, and never copied it thread to thread. This patch always
restores the FSCR and formalizes new threads inheriting its setting so
that later we can manipulate FSCR bits in start_thread.
Signed-off-by: Jack Miller
---
arch
Second spin of these patches:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-April/141609.html
Differences from v1:
- As part of the FSCR context switch patch, remove extra FSCR manipulation in
the DSCR case. If anything set FSCR.DSCR it should automatically be set
correctly now. If I
> I'm not sure that works on processes before power8.
>
> There DSCR SPR number 0x11 will always trap and emulate from userspace
> (see arch/powerpc/kernel/traps.c:emulate_instruction()). That is not
> controlled by FSCR and should work on POWER7 where FSCR is not
> present. We need to set the in
Hi Anton.
On Wed, Apr 13, 2016 at 5:51 AM, Anton Blanchard wrote:
> Hi Jack,
>
>> Previously we just saved the FSCR, but only restored it in some
>> settings, and never copied it thread to thread. This patch always
>> restores the FSCR and formalizes new threads inheriting its setting so
>> that
Thanks, yeah, that's more readable and more correct. I'll change it in
the next spin.
- Jack
On Tue, Apr 12, 2016 at 12:40 AM, Segher Boessenkool
wrote:
> Hi,
>
> On Mon, Apr 11, 2016 at 01:57:44PM -0500, Jack Miller wrote:
>> __init_FSCR:
>> mfspr r3,S
Adds two tests. One is a simple test to ensure that the new registers
LMRR and LMSER are properly maintained. The other actually uses the
existing EBB test infrastructure to test that LMRR and LMSER behave as
documented.
Signed-off-by: Jack Miller
---
tools/testing/selftests/powerpc/pmu/ebb
when a facility unavailable exception is taken for using it. On context
switch, this bit is then used to determine whether the two relevant
registers are saved and restored. This is done lazily for performance
reasons.
Signed-off-by: Jack Miller
---
arch/powerpc/include/asm/processor.h | 2
Previously we just saved the FSCR, but only restored it in some
settings, and never copied it thread to thread. This patch always
restores the FSCR and formalizes new threads inheriting its setting so
that later we can manipulate FSCR bits in start_thread.
Signed-off-by: Jack Miller
---
arch
All -
These are patches based on next to support the forthcoming ldmx instruction
through the existing P8 EBB infrastructure. Obviously it doesn't actually
*work* without some other patches and a P9 system, but with the context
switch change to FSCR it makes sense to get this upstream for testing
On Wed, May 20, 2015 at 10:58:42PM +0530, Shreyas B Prabhu wrote:
>
>
> On Wednesday 20 May 2015 10:43 PM, Jack Miller wrote:
> > pnv_alloc_idle_core_states is iterating over PACAs based on the
> > configured maximum number of CPUs (NR_CPUS), but PACAs are only
> > i
pnv_alloc_idle_core_states is iterating over PACAs based on the
configured maximum number of CPUs (NR_CPUS), but PACAs are only
initialized up to nr_cpu_ids, so rein in loops to keep from overwriting
adjacent memory.
Signed-off-by: Jack Miller
---
arch/powerpc/platforms/powernv/setup.c | 26
24 matches
Mail list logo
