[Skiboot] [PATCH] Add NX P7+ support

[Dan Streetman]

On Wed, Mar 25, 2015 at 11:57 AM, Dan Streetman <ddstreet at ieee.org> wrote:
> On Tue, Mar 17, 2015 at 1:34 AM, Stewart Smith
> <stewart at linux.vnet.ibm.com> wrote:
>> Benjamin Herrenschmidt <benh at au1.ibm.com> writes:
>>> On Mon, 2015-03-16 at 14:03 -0400, Dan Streetman wrote:
>>>>
>>>> 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.
>>>
>>> I don't want linux to know about SCOMS, instead, create OPAL calls, for
>>> example OPAL_GET_NX_STATUS or whatever makes sense for you.
>>>
>>> In any case, a XSCOM is a roundtrip to OPAL so the above won't be
>>> slower.
>>
>> I'll merge this patch and possibly disable the 842 DT node creation
>> before tagging skiboot-5.0 depending on if the patch that adds OPAL
>> calls arrives in time or not.
>
> Sorry for the delay.  I sent the patch with the NX opal calls earlier
> this week, so let me know if you think it needs any adjustment.

Just to follow up on this via email, as we discussed in irc the FSP
will be monitoring the NX status/err registers, so we don't need to
add these calls since the kernel won't need to use them.  You can
ignore the patch I sent with the opal calls.

>
>>
>> (open question: should the protocol for discovering if firmware supports
>> a thing be "check device tree entry exists and OPAL calls exist" or just
>> "check device tree" OR check opal call)
>>