[Skiboot] [PATCH] Add NX P7+ support

[Dan Streetman]

On Mon, Mar 16, 2015 at 2:03 PM, Dan Streetman <ddstreet at ieee.org> wrote:
> On Thu, Mar 12, 2015 at 10:59 PM, Stewart Smith
> <stewart at linux.vnet.ibm.com> wrote:
>> Dan Streetman <ddstreet at ieee.org> writes:
>>> Add NX config register values for P7+.  Remove "P8" from all register
>>> defines, where the define is common to P7+ and P8.  For values new to P8
>>> (specifically 842 prefeching), only enable on P8.
>>>
>>> This should correctly setup the NX coprocessors on P7+ systems.
>>>
>>> Signed-off-by: Dan Streetman <ddstreet at ieee.org>
>>> ---
>>>
>>> I don't have access to any P7+ bare metal system right now, so I haven't
>>> tested this to verify it works on P7+, but I did verify it still works
>>> on a P8 system.
>>
>> I have P7+ in the lab in CBR that I can test on. I guess the best way is
>> with the kernel patches?
>
> yep.  I'll resend the patch set, updated for the nx node location per
> the other skiboot patch I sent.  I can provide a pre-built kernel with
> the patches too if you want, either using pkvm 3.1 src or the latest
> upstream kernel src.

I just re-sent the patch set with a change to use the relocated nx
device tree nodes, so you can test with that kernel patch set if
you've included my last two skiboot patches.  I'll update this patch
set as mentioned to Ben, to change the xscom r/w into opal calls.

I can provide a pre-build test kernel also if you want, let me know.

>
> once you get the patched kernel loaded on the system, you just need to
> load the module nx-compress-powernv.  To test, you could use zswap,
> although it's a bit complicated to set up; or you can use the
> compression test module i added, comp_selftest.  Once you load
> comp_selftest there's a debugfs interface; in the
> /sys/kernel/debugfs/comp_selftest dir you can do:
>
> echo 842 > compressor
> echo 1 > running
>
> that should start it testing, you can do
> cat status
>
> for a continually-updated status, and you can ajdust the number of
> threads and other params using the other nodes in the dir.  you can
> stop the test by writing 0 to the running node.  (I still plan to
> adjust the interface here, breaking out each of the status info values
> into their own nodes, and maybe removing the status node as you can
> script a constant checking easily...)
>
> On the P8 test systems, I was getting some pretty impressive
> compression throughput (between 5-10 GBps, per thread, it seemed to be
> only about 1/4 or so of the throughput of the memcpy-only null
> compressor), so I'm interested to see what it looks like on the p7+
> system.
>
>>
>> From a quick glance, there's nothing we can really do to abstract away
>> the slight differences between P7 and P8 for kernel?
>
> Well the kernel driver doesn't care at all about P7/P8 except for the
> xscom r/w, since the xscom addrs are different between P7/P8.  As I
> haven't actually added any error recovery (via xscoms) to the kernel
> driver yet, I could remove the xscom stuff from the first kernel patch
> set.  However, if the kernel driver is who eventually monitors and
> handles NX errors, I don't see any way around r/w directly from the NX
> xscoms.  The P7/P8 differences should be able to be abstracted in the
> nx-842-xscom.h header though, and I don't think the actual driver will
> need to know the P num.
>
> Also, we could use skiboot to add device tree nodes telling the driver
> what NX xscom register addrs to use, which would remove the P7/P8
> specifics from the kernel completely, but then we rely on having to
> update skiboot if we ever want to r/w a new NX xscom register in the
> kernel driver, which isn't ideal.
>
>
>>
>> It doesn't really matter anyway, as P7 with OPAL has only ever been used
>> internally for development purposes.
>>
>
> yeah, but it would be nice to be able to test on p7+ also, as you said
> before there's more of them out there than P8's for people to work
> with.  I managed to get 2 surplus p7+ systems myself, although they
> are still being moved to our lab space.
>
> i assume p7+ systems can be updated to fw830?