From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Tirumala Marri <tmarri@apm.com>
Cc: Paul Mackerras <paulus@samba.org>,
Ayman El-Khashab <ayman@elkhashab.com>,
linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
Date: Tue, 24 May 2011 13:40:12 +1000 [thread overview]
Message-ID: <1306208412.7481.214.camel@pasglop> (raw)
In-Reply-To: <6a09a426f126fb315b773fc207d68eb9@mail.gmail.com>
On Thu, 2011-05-12 at 11:16 -0700, Tirumala Marri wrote:
> So what is the best way to handle this? It appears (based
> on the comments of others and my own experience) that there
> is no DCR that exists and behaves the way that previous SOCs
> behaved to give us the link status?
The register above
> PECFGn_DLLSTA is actually in the PCIe configuration space so
> we would have to map that in to be able to read that
> register during the link check. Is that correct or ok?
> [marri] yes, you need to program DCR register access these local PCIE_CFG
> registers.
We do I think, tho we might have to re-order some stuff. I'm facing a
similar issue with some internal design here, I'm thinking off adding a
new hook to the ppc4xx_pciex_hwops for link checking to replace the SDR
business.
The interesting question of course is whether that 460SX stuff is the
same as what we're using internally :-)
> I've communicated with some people over email and they had
> tried the (PESDRn_HSSLySTS) register. Recognizing that
> there exists one of these for each port/lane, is there a way
> to use this one? It is in the indirect DCR space. I'd
> tried this myself and never did get it to do anything but I
> could have been looking at the wrong lane or something.
> [marri]This is at SERDES level. If this link up doesn't necessarily
> Overall stack is up. This is mostly used for BIST and diagnostics.
>
> Lastly, what was the reason for forcing the original code to
> be GEN-1 speeds?
> [marri] Gen-2 need some extra checks compared to Gen-1.
> There were not many Gen-2 devices at the time of submission
> To test them.
Can we fix that ?
Cheers,
Ben.
next prev parent reply other threads:[~2011-05-24 3:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 18:22 [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX Ayman El-Khashab
2011-04-08 18:22 ` [PATCH 1/1] " Ayman El-Khashab
2011-04-08 23:48 ` [PATCH 0/1] " Benjamin Herrenschmidt
2011-04-13 2:09 ` Tirumala Marri
2011-04-29 17:02 ` Ayman El-Khashab
2011-04-29 20:37 ` Benjamin Herrenschmidt
2011-05-01 4:28 ` Tirumala Marri
2011-05-04 5:32 ` Benjamin Herrenschmidt
2011-05-05 16:44 ` Tirumala Marri
2011-05-09 16:09 ` Ayman El-Khashab
2011-05-12 18:16 ` Tirumala Marri
2011-05-24 3:40 ` Benjamin Herrenschmidt [this message]
2011-05-27 16:51 ` Ayman El-Khashab
2011-05-27 22:57 ` Benjamin Herrenschmidt
2011-05-31 21:27 ` Tirumala Marri
2011-06-27 10:14 ` Ayman El-Khashab
2011-06-27 10:15 ` Benjamin Herrenschmidt
2011-05-31 21:18 ` Tirumala Marri
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=1306208412.7481.214.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=ayman@elkhashab.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=tmarri@apm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.