linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Neuling <mikey@neuling.org>
To: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Cc: imunsie@au1.ibm.com, linuxppc-dev@ozlabs.org,
	vaibhav@linux.vnet.ibm.com,
	 Stewart Smith <stewart@linux.vnet.ibm.com>
Subject: Re: [PATCH] cxl: Set up and enable PSL Timebase
Date: Tue, 02 Jun 2015 10:36:52 +1000	[thread overview]
Message-ID: <1433205412.24546.30.camel@neuling.org> (raw)
In-Reply-To: <556C64A6.2050905@linux.vnet.ibm.com>

On Mon, 2015-06-01 at 15:56 +0200, Philippe Bergheaud wrote:
> Michael Neuling wrote:
>  > Please use negative error codes here.  -EIO?
>  > And check it here.
>=20
> Mikey,
>=20
> I am reluctant to fail the entire CAPI init after a PSL timebase sync fai=
lure.
> If we ignore the error, the CAPI device stays available (without timebase=
 sync).
> If we honour the error, the CAPI device fails entirely.
>=20
> I know three reasons why PSL timebase sync can fail:
> 1. h/w failure

This would be a good reason to fail it.  Bad hardware, we should fail.

> 2. OPAL did not initialize the CAPP timebase (wrong OPAL version)

This would not as we are going to have to deal with older opal for a
while.

Is there a way for us to tell if OPAL has this capability?  I guess we
could add something to the device tree of the PHB node if we know the
timebase has been synced.

> 3. the PCIe bus was not powered off/on between shutdown and reboot

We should fix that.  What's the problem?

> I think that it is premature to choose to fail the entire CAPI init in al=
l cases.
> In particular, point 3. introduces a regression, as PCIe off/on was never=
 a requirement for booting CAPI on P8.

We should fix it.  Is a PERST enough?

> I have tried one workaround do far: forcing the 0 to 1 transition of the =
tb bit of the PSL register TB_CTLSTAT.
> In vain.
>=20
> What do you think?

The OPAL one (2) is the most concerning but let's work out if we can
determine if the syncing has happened in the CAPP unit or not.  If we
know it's synced but it fails your test, then I think we should fail the
whole probe. =20

I the other reasons (1 and 3) shouldn't be ignored. =20

Mikey

      reply	other threads:[~2015-06-02  0:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-28 13:12 [PATCH] cxl: Set up and enable PSL Timebase Philippe Bergheaud
2015-06-01  6:41 ` Michael Neuling
2015-06-01  7:37   ` Philippe Bergheaud
2015-06-01  9:08     ` Michael Neuling
2015-06-01  9:25       ` Philippe Bergheaud
2015-06-01 13:56   ` Philippe Bergheaud
2015-06-02  0:36     ` Michael Neuling [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1433205412.24546.30.camel@neuling.org \
    --to=mikey@neuling.org \
    --cc=felix@linux.vnet.ibm.com \
    --cc=imunsie@au1.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=stewart@linux.vnet.ibm.com \
    --cc=vaibhav@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).