Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
Hi,
I'm not sure I explained myself clearly in previous reply, so I guess it's
worth to
rephrase it.
1000BASE-KX and 10GBASE-KR are backplane modes supported by Freescale's PCS
PHY, but different modes need different hardware settings, not just different
PHY init
routines, this also needs different serdes lane settings, this is done in
probe() according
to DTS properties.
Regarding the autoneg part, it's not like normal autoneg which can autoneg to
different
capabilities, when the PHY is 1000BSE-KX, it can only autoneg to 1000BASE-KX
only if
LP is 1000BASE-KX, same is true for 10GBASE-KR. The purpose of KR AN is to
detect whether
LP is also KR, if yes, do training, if not, do nothing, no any other result the
KR AN can give.
The reason "copper + speed" is not enough for backplane is because they are not
precise,
and backplane itself explains what it is, for ex. 1000BASE-KX clearly means the
media is copper,
speed is 1000, and should follow 1000BASE-KX standard in IEEE802.3.
The reason I mentioned maybe I should put the backplane property in fsl's
binding is because
the backplane implementation is really vendor specific, it's heavily relay how
hardware implements
the feature, maybe another vendor's hardware only needs a boolean property for
driver to tell it
should work in backplane, hardware can deal with different modes, or even no
any special
property needed if the hardware is strong enough to handle any connections, I
cannot assume.
But I know what fsl's hardware needs to support backplane.
Thank you for your time and reviewing!
Shaohui
____
From: Shaohui Xie
Sent: Friday, January 22, 2016 6:05 PM
To: Sebastian Hesselbarth; Andrew Lunn
Cc: Florian Fainelli; shh@gmail.com; devicet...@vger.kernel.org;
net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; da...@davemloft.net;
Shaohui Xie
Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
>> Looking at fsl_backplane_config_aneg() you expect phydev->speed to be
>> set, and from the speed you then kick of either KR autoneg or KX
>> autoneg. Could you also start the training at this point? Use the
>> speed to indicate if training is needed?
>
> [S.H]The training cannot be started at this point, yet, because it's based
> on
> autoneg result, only when both sides autoneg-ed to 10G-KR, then to start
> the training.
Shaohui,
look, we want you to convince us why to have a generic backplane
property in the phy binding. You had a bad start by adding new
property values to a property that does not relate to your use
case at all. Your job now really is to give strong reasons _why_
and _what_ a phy driver needs to know about the backplane setup.
[S.H] The PHY driver needs to know what the backplane mode is,
1000BASE-KX or 10GBASE-KR, the driver parses the property for
"1000base-kx" or "10gbase-kr", the driver does use the property,
I don't understand why the property is not related to my use case?
Your first approach was to add "10gbase-rk" or "40gbase-foo" but
now you tell us about ANEG. Of what use is the information given
by the property when ANEG tells you something different? E.g.
consider the property tells you "10g-something" but ANEG gives
you "40g"; does the property add any value to your training
decision now?
[S.H] The ANEG is not a gerneric AN, it's special to 10G-KR, KR AN can only
AN to KR if both sides support KR, it cannot give "40g" or anything different,
drive needs the property to do speicific init.
> Besides the driver, generally speaking, "copper + speed" is not enough to
> indicate
> it's backplane, for ex. "copper + 1000" does not mean it has to be
> 1000BASE-KX,
> it could be SGMII, hence cannot use KX autoneg.
So, is it copper + speed + backplane? or speed + backplane? And out of
the set of required input, is there anything your _cannot_ determine
from other things, e.g. ANEG?
[S.H] Backplane is enough, 1000BASE-KX means : copper + 1000 + KX stuff.
The KR AN is to check whether LP is also KR, if yes, do training, otherwise, do
nothing.
If it is backplane only, would a boolean property ("backplane-mode")
be enough for the training decision?
[S.H] a boolean property is not enough, there are different backplane modes.
> If putting backplane property to phy.txt is not good, I can put it to fsl
> specific
> binding, like the second patch 2/3 did.
You seem to see vendor specific properties as a place to dump all your
waste you don't want to think about. You fail to give good reasons what
is so special about the backplane setup and now you are telling us that
it is even fsl-specific?
[S.H] I don't think it's waste, I just thought it might be special to fsl.
Agreed I failed to give good reasons, but I tried hard to. :(
Thanks,
Shaohui
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
>> Looking at fsl_backplane_config_aneg() you expect phydev->speed to be
>> set, and from the speed you then kick of either KR autoneg or KX
>> autoneg. Could you also start the training at this point? Use the
>> speed to indicate if training is needed?
>
> [S.H]The training cannot be started at this point, yet, because it's based
> on
> autoneg result, only when both sides autoneg-ed to 10G-KR, then to start
> the training.
Shaohui,
look, we want you to convince us why to have a generic backplane
property in the phy binding. You had a bad start by adding new
property values to a property that does not relate to your use
case at all. Your job now really is to give strong reasons _why_
and _what_ a phy driver needs to know about the backplane setup.
[S.H] The PHY driver needs to know what the backplane mode is,
1000BASE-KX or 10GBASE-KR, the driver parses the property for
"1000base-kx" or "10gbase-kr", the driver does use the property,
I don't understand why the property is not related to my use case?
Your first approach was to add "10gbase-rk" or "40gbase-foo" but
now you tell us about ANEG. Of what use is the information given
by the property when ANEG tells you something different? E.g.
consider the property tells you "10g-something" but ANEG gives
you "40g"; does the property add any value to your training
decision now?
[S.H] The ANEG is not a gerneric AN, it's special to 10G-KR, KR AN can only
AN to KR if both sides support KR, it cannot give "40g" or anything different,
drive needs the property to do speicific init.
> Besides the driver, generally speaking, "copper + speed" is not enough to
> indicate
> it's backplane, for ex. "copper + 1000" does not mean it has to be
> 1000BASE-KX,
> it could be SGMII, hence cannot use KX autoneg.
So, is it copper + speed + backplane? or speed + backplane? And out of
the set of required input, is there anything your _cannot_ determine
from other things, e.g. ANEG?
[S.H] Backplane is enough, 1000BASE-KX means : copper + 1000 + KX stuff.
The KR AN is to check whether LP is also KR, if yes, do training, otherwise, do
nothing.
If it is backplane only, would a boolean property ("backplane-mode")
be enough for the training decision?
[S.H] a boolean property is not enough, there are different backplane modes.
> If putting backplane property to phy.txt is not good, I can put it to fsl
> specific
> binding, like the second patch 2/3 did.
You seem to see vendor specific properties as a place to dump all your
waste you don't want to think about. You fail to give good reasons what
is so special about the backplane setup and now you are telling us that
it is even fsl-specific?
[S.H] I don't think it's waste, I just thought it might be special to fsl.
Agreed I failed to give good reasons, but I tried hard to. :(
Thanks,
Shaohui
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
___ From: Andrew Lunn Sent: Friday, January 22, 2016 5:12 AM To: Shaohui Xie Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com; devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR On Tue, Jan 19, 2016 at 05:00:35AM +, Shaohui Xie wrote: > > -Original Message- > > From: Andrew Lunn [mailto:and...@lunn.ch] > > Sent: Monday, January 18, 2016 11:15 PM > > To: Shaohui Xie > > Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com; > > devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc- > > d...@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie > > Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR > > > > > [S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle > > > link training, It's to train link partner, and trained by link partner > > parallel. > > > > > > But if media type is not copper, e.g. optical module, we won't need this. > > > > So what we actually need to know is copper vs fibre? > Copper is not enough to indicate backplane, since backplane is > always copper, but copper is not always backplane. >O.K, lets try again [S.H]Seems I did not get your point, Sorry for the inconvenient. >If it is copper backplane you need to perform training. >Looking at the driver probe function, it is either 1000BASE-KX, no >training needed, or else it is 10GBASE-RK and training is needed. >Looking at fsl_backplane_config_aneg() you expect phydev->speed to be >set, and from the speed you then kick of either KR autoneg or KX >autoneg. Could you also start the training at this point? Use the >speed to indicate if training is needed? [S.H]The training cannot be started at this point, yet, because it's based on autoneg result, only when both sides autoneg-ed to 10G-KR, then to start the training. Besides the driver, generally speaking, "copper + speed" is not enough to indicate it's backplane, for ex. "copper + 1000" does not mean it has to be 1000BASE-KX, it could be SGMII, hence cannot use KX autoneg. If putting backplane property to phy.txt is not good, I can put it to fsl specific binding, like the second patch 2/3 did. Thank you! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, January 18, 2016 11:15 PM > To: Shaohui Xie > Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com; > devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie > Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR > > > [S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle > > link training, It's to train link partner, and trained by link partner > parallel. > > > > But if media type is not copper, e.g. optical module, we won't need this. > > So what we actually need to know is copper vs fibre? Copper is not enough to indicate backplane, since backplane is always copper, but copper is not always backplane. Thank you! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> -Original Message- > From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com] > Sent: Monday, January 18, 2016 4:06 PM > To: Shaohui Xie; Florian Fainelli; Andrew Lunn; shh@gmail.com > Cc: devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie > Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR > > On 18.01.2016 08:23, Shaohui Xie wrote: > >>> If you look at the list of possible values for "phy-mode" you'd see > >>> that none of it describes a PHY-to-PHY connection but all are for > >>> MAC-to-PHY connections. Also, names above suggest it already: MII is > >>> short for media _independent_ interface. > >>> > >>> I copy Andrew's concerns and think that neither 1base-kx nor > >>> 10gbase-kr belong in the list of phy-mode properties. > >> > >> I concur with that as well, if the phy connection does not really > >> matter here, or does not seem like a good fit, maybe we should have a > >> different property, or just define the hardware interface a little > differently? > > Right, 'phy-mode' is not a good fit for backplanes, how about a new > > property like 'backplane-mode' or something, like below: > > Hmm. We already have a speed property for that you can use for 1000, 1, > 4. Leaves the media-type, e.g. copper or whatever. [S.H] You mean the property 'max-speed'? the problem is the media-type matters. Please see below. > > Currently, you fail to convince me that it is required to describe the media > type at all. We have come a long way with different media without describing > the > PHY-to-PHY media type. > > What makes the backplane setup so special? [S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle link training, It's to train link partner, and trained by link partner parallel. But if media type is not copper, e.g. optical module, we won't need this. Thank you! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> > If you look at the list of possible values for "phy-mode" you'd see
> > that none of it describes a PHY-to-PHY connection but all are for
> > MAC-to-PHY connections. Also, names above suggest it already: MII is
> > short for media _independent_ interface.
> >
> > I copy Andrew's concerns and think that neither 1base-kx nor
> > 10gbase-kr belong in the list of phy-mode properties.
>
> I concur with that as well, if the phy connection does not really matter here,
> or does not seem like a good fit, maybe we should have a different property,
> or
> just define the hardware interface a little differently?
Right, 'phy-mode' is not a good fit for backplanes, how about a new property
like
'backplane-mode' or something, like below:
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -33,6 +33,9 @@ Optional Properties:
- broken-turn-around: If set, indicates the PHY device does not correctly
release the turn around line low at the end of a MDIO transaction.
+- backplane-mode: string, operation mode of the backplane PHY;
+ must be "1000base-kx" for 1000BASE-KX, or "10gbase-kr" for 10GBASE-KR.
+
Example:
ethernet-phy@0 {
Thank you!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] [v2] powerpc: fsl: update fman dt binding for PCS PHY
> > + - fsl-lane-handle: phandle, specifies a reference to a node representing > > a > Serdes. > > + - fsl-lane-reg: offset and length of the register set for the serdes > > lane. > > These should be fsl,... not fsl-... Will fix it. Thank you! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Friday, January 15, 2016 12:44 AM > To: shh@gmail.com > Cc: devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; f.faine...@gmail.com; da...@davemloft.net; Shaohui Xie > Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR > > On Thu, Jan 14, 2016 at 04:23:59PM +0800, shh@gmail.com wrote: > > From: Shaohui Xie > > > > This commit adds necessary definitions for the PHY layer to recognize > > backplane Ethernet 1000BASE-KX and 10GBASE-KR as valid PHY interfaces, > > "1000base-kx" for 1000BASE-KX, "10gbase-kr" for 10GBASE-KR. > > > > Signed-off-by: Shaohui Xie > > --- > > changes in v2: > > new patch. > > > > Documentation/devicetree/bindings/net/ethernet.txt | 4 ++-- > > include/linux/phy.h| 6 ++ > > 2 files changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/net/ethernet.txt > > b/Documentation/devicetree/bindings/net/ethernet.txt > > index 5d88f37..1166a5c 100644 > > --- a/Documentation/devicetree/bindings/net/ethernet.txt > > +++ b/Documentation/devicetree/bindings/net/ethernet.txt > > @@ -11,8 +11,8 @@ The following properties are common to the Ethernet > controllers: > >the maximum frame size (there's contradiction in ePAPR). > > - phy-mode: string, operation mode of the PHY interface; supported values > > are > >"mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", > > "rgmii", "rgmii-id", > > - "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a > > de-facto > > - standard property; > > + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii", "1000base-kx", > > + "10gbase-kr"; this is now a de-facto standard property; > > I know very little about this, so i'm just asking a question. None of the > other > interface modes contain a bit rate. So is the bit rate needed for your two new > modes? > > With a bit of googling, K means copper backplane, X means 4B/5B and R means > 64B/66B. Could there be a 10Gbps KX? a 1GBps KR? Do we actually need the speed > here, or is kx and kr sufficient? Hello Andrew, 1000BASE-KX and 10GBASE-KR are terms in IEEE802.3, so as XGMII and GMII. There are interfaces could be different bit rates but same types, e.g. 100BASE-LX10 and 1000BASE-LX10, or 40GBASE-KR4 and 100GBASE-KR4, having bit rate is clear to represent hardware. Thank you! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc: fsl: update fman dt binding for PCS PHY
> > [S.H] 'compatible' and 'phy-mode' are standard properties already in > > common Ethernet phy binding, I can update 'phy-mode' with > > "1000base-kx" and "10gbase-kr", how about I still list the two > > properties here for the requirement of PCS PHY to support backplane? > > Yes. The common binding should list all possible values and this binding > should > list allowed values. Got it. Thank you! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc: fsl: update fman dt binding for PCS PHY
> Subject: Re: [PATCH] powerpc: fsl: update fman dt binding for PCS PHY > > On Mon, Dec 28, 2015 at 11:47:34AM +0800, shh@gmail.com wrote: > > From: Shaohui Xie > > > > PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this needs > > to change corresponding serdes lane settings, so a reference is needed > > for serdes lane. This patch describes properties needed for PCS PHY to > > support backplane. > > > > Signed-off-by: Shaohui Xie > > --- > > based on: http://patchwork.ozlabs.org/patch/560936/ > > > > Documentation/devicetree/bindings/powerpc/fsl/fman.txt | 14 > > ++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt > > b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt > > index 55c2c03..b38e727 100644 > > --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt > > +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt > > @@ -432,6 +432,16 @@ example of how to define a PHY (Internal PHY has no > interrupt line). > > - For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY. > > - For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS > > PHY, > >PCS PHY addr must be '0'. > > + PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this > > + needs to change the corresponding serdes lane settings. > > + > > + PCS PHY node properties required for backplane: > > + > > + - compatible: must be "ethernet-phy-ieee802.3-c45". > > + - phy-mode: string, operation mode of the PHY interface; must be > > "1000base- > kx" > > +for 1000BASE-KX, or "10gbase-kr" for 10GBASE-KR. > > Seems like these should be in common ethernet phy binding. [S.H] 'compatible' and 'phy-mode' are standard properties already in common Ethernet phy binding, I can update 'phy-mode' with "1000base-kx" and "10gbase-kr", how about I still list the two properties here for the requirement of PCS PHY to support backplane? > > > + - lane-handle: phandle, specifies a reference to a node representing a > Serdes. > > + - lane-range: offset and length of the register set for the serdes lane. > > These seem pretty FSL specific, so add vendor prefix. [S.H] OK. will add fsl prefix. Thank you for reviewing the patch! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/mpc85xx: Add pcsphy nodes to FManV3 device tree
> @@ -55,6 +55,7 @@ fman@40 {
> reg = <0xe 0x1000>;
> fsl,fman-ports = <&fman0_rx_0x08 &fman0_tx_0x28>;
> ptp-timer = <&ptp_timer0>;
> + pcsphy-handle = <&pcsphy0>;
> };
>
> mdio@e1000 {
> @@ -62,5 +63,9 @@ fman@40 {
> #size-cells = <0>;
> compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
> reg = <0xe1000 0x1000>;
> +
> + pcsphy0: ethernet-phy@0 {
> + reg = <0x0>;
> + };
> };
> };
[S.H] snip.
> mdio@e1000 {
> @@ -58,5 +59,9 @@ fman@40 {
> #size-cells = <0>;
> compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
> reg = <0xe1000 0x1000>;
> +
> + pcsphy0: pcs-phy@0 {
> + reg = <0x0>;
> + };
> };
[S.H] Should use 'ethernet-phy', same as above.
Thanks,
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/2] powerpc/config: enable teranetics PHY
> On Tue, 2015-08-04 at 19:24 -0500, Scott Wood wrote: > > On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote: > > > On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > > > > From: Shaohui Xie > > > > > > > > The PHY uses XAUI interface to connect to MAC, mostly the PHY used > > > > on riser card. > > > > > > > > Signed-off-by: Shaohui Xie > > > > --- > > > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > > > 2 files changed, 2 insertions(+) > > > > > > Next time, please use a subject line that lets me know that this is > > > a patch that I'd be picking up, such as "powerpc/85xx: ..." or > > > "powerpc/corenet: ..." > > > > More importantly, don't send patches to enable config options that > > don't exist. > > Sorry, this comment was meant for patch 2/2 (CONFIG_AQUANTIA_PHY). > CONFIG_TERANETICS_PHY does exist in linux-next (that it depends on a > patch in linux-next should be mentioned below the ---). Hi Scott, The CONFIG_AQUANTIA_PHY was added in another patch sent to net-next, it was not accepted when I sent the patch to enable this config, later the patch was accepted in net-next, https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=bee8259dd31f419a883174556b11edc6f9a153d1 I should mention this below the ---. Sorry! Should I re-send the patch of enabling config option of CONFIG_AQUANTIA_PHY? Thanks! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/2] powerpc/config: enable teranetics PHY
> -Original Message- > From: Xie Shaohui-B21989 > Sent: Wednesday, August 05, 2015 11:00 AM > To: Wood Scott-B07421 > Cc: linuxppc-dev@lists.ozlabs.org > Subject: RE: [1/2] powerpc/config: enable teranetics PHY > > > On Tue, 2015-08-04 at 19:24 -0500, Scott Wood wrote: > > > On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote: > > > > On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > > > > > From: Shaohui Xie > > > > > > > > > > The PHY uses XAUI interface to connect to MAC, mostly the PHY > > > > > used on riser card. > > > > > > > > > > Signed-off-by: Shaohui Xie > > > > > --- > > > > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > > > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > > > > 2 files changed, 2 insertions(+) > > > > > > > > Next time, please use a subject line that lets me know that this > > > > is a patch that I'd be picking up, such as "powerpc/85xx: ..." or > > > > "powerpc/corenet: ..." > > > > > > More importantly, don't send patches to enable config options that > > > don't exist. > > > > Sorry, this comment was meant for patch 2/2 (CONFIG_AQUANTIA_PHY). > > CONFIG_TERANETICS_PHY does exist in linux-next (that it depends on a > > patch in linux-next should be mentioned below the ---). > Hi Scott, > > The CONFIG_AQUANTIA_PHY was added in another patch sent to net-next, it > was not accepted when I sent the patch to enable this config, later the > patch was accepted in net-next, > https://git.kernel.org/cgit/linux/kernel/git/davem/net- > next.git/commit/?id=bee8259dd31f419a883174556b11edc6f9a153d1 [S.H] Just found the patch was also merged in Linux-next: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=bee8259dd31f419a883174556b11edc6f9a153d1 Thanks. Shaohui > > I should mention this below the ---. > Sorry! > > Should I re-send the patch of enabling config option of > CONFIG_AQUANTIA_PHY? > > Thanks! > Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/2] powerpc/config: enable teranetics PHY
> -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, August 05, 2015 8:19 AM > To: shaohui xie > Cc: linuxppc-dev@lists.ozlabs.org; Xie Shaohui-B21989 > Subject: Re: [1/2] powerpc/config: enable teranetics PHY > > On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > > From: Shaohui Xie > > > > The PHY uses XAUI interface to connect to MAC, mostly the PHY used on > > riser card. > > > > Signed-off-by: Shaohui Xie > > --- > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > 2 files changed, 2 insertions(+) > > Next time, please use a subject line that lets me know that this is a > patch that I'd be picking up, such as "powerpc/85xx: ..." or > "powerpc/corenet: ..." OK. Sorry for the inconvenience. Thanks. Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v4] power/fsl: add MDIO dt binding for FMan
> -Original Message- > From: Wood Scott-B07421 > Sent: Friday, January 30, 2015 10:44 AM > To: Xie Shaohui-B21989 > Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve > Emilian-EMMEDVE1 > Subject: Re: [PATCH][v4] power/fsl: add MDIO dt binding for FMan > > On Thu, 2015-01-29 at 20:38 -0600, Xie Shaohui-B21989 wrote: > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Friday, January 30, 2015 8:54 AM > > > To: shh@gmail.com > > > Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve > > > Emilian-EMMEDVE1; Xie Shaohui-B21989 > > > Subject: Re: [PATCH][v4] power/fsl: add MDIO dt binding for FMan > > > > > > On Wed, 2015-01-28 at 19:54 +0800, shh@gmail.com wrote: > > > > +- interrupts > > > > + Usage: required > > > > + Value type: > > > > + Definition: Event interrupt of external MDIO controller. > > > > > > What if this MDIO controller is not "external"? Should Usage say > > > "required for external MDIO"? > > [S.H] I thought the definition can tell the interrupt is for external > > MDIO, I can change the Usage to "required for external MDIO" in next > version. > > how about other parts, are they OK? > > Yes. I'll fix it up when applying. Thank you! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v4] power/fsl: add MDIO dt binding for FMan
> -Original Message- > From: Wood Scott-B07421 > Sent: Friday, January 30, 2015 8:54 AM > To: shh@gmail.com > Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve > Emilian-EMMEDVE1; Xie Shaohui-B21989 > Subject: Re: [PATCH][v4] power/fsl: add MDIO dt binding for FMan > > On Wed, 2015-01-28 at 19:54 +0800, shh@gmail.com wrote: > > +- interrupts > > + Usage: required > > + Value type: > > + Definition: Event interrupt of external MDIO controller. > > What if this MDIO controller is not "external"? Should Usage say > "required for external MDIO"? [S.H] I thought the definition can tell the interrupt is for external MDIO, I can change the Usage to "required for external MDIO" in next version. how about other parts, are they OK? Thanks! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
> -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, January 08, 2015 9:13 AM > To: Medve Emilian-EMMEDVE1 > Cc: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org; > devicet...@vger.kernel.org > Subject: Re: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan > > On Wed, 2015-01-07 at 13:44 -0600, Emil Medve wrote: > > Hello Scott, > > > > > > On 01/07/2015 12:05 PM, Scott Wood wrote: > > > On Tue, 2015-01-06 at 23:29 -0600, Xie Shaohui-B21989 wrote: > > > +- interrupts > > > + Usage: optional > > > + Value type: > > > + Definition: Event interrupt of external MDIO controller. > > > + 1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt > > > respectively. > > >>> > > >>> I'm confused by "respectively" here. Does fsl,fman-memac-mdio > > >>> have two interrupts (one for 1 Gb/s and one for 10 Gb/s)? > > >> [S.H] We use two MDIO controllers for external PHY management. One > > >> for 1 Gb/s, One for 10 Gb/s, and two MDIO interrupts connected to MPIC. > > > > > > If there can be two interrupts you need to make that clear and > > > specify the order. > > > > > > Is it possible for one MDIO controller to have an interrupt > > > connected but not the other, on the same system? How would you > > > represent that in the device tree? If there are two MDIO > > > controllers why are they in the same node? > > > > Historically (FMan v2 and even before/legacy) we've had each MAC > > include an MDIO controller, but only one MDIO controller per MAC > > type/speed (1 Gb/s vs 10 Gb/s) is pinned out and all the same speed > > PHY(s) are connected to the respective MDIO controllers. As such the > > first 1 Gb/s MAC/MDIO controller is used to manage all the 1 Gb/s > > PHY(s) and the first 10 Gb/s MAC/MDIO controller is used to manage all > > the 10 Gb/s PHY(s). Each MDIO controller has the ability to generate > > interrupts but only pinned out MDIO controllers are hooked up to the > > MPIC (as such the talk about two interrupts) > > > > (Each MAC has also integrated a SERDES/TBI/"internal" PHY that is > > connected to the "local" MDIO controller) > > > > As you can imagine this creates a number of problems in a partitioning > > scenario (and not just, imagine RCWs where the first MAC is not > > used/enabled). In order to help a bit (but not quite enough), in FMan > > v3, two additional MDIO controllers (one for 1 the Gb/s PHY(s) and one > > for 1 the 10 Gb/s PHY(s)) have been integrated that are not associated > > with any MAC and these are the pinned out MDIO controllers on such > > SoC(s) (chassis v2) > > I'm happy to hear that. Is that what is meant by "external" here? I thought > it > meant external to the SoC. Is this the term used by hardware documentation? [S.H] Yes. "external" & "internal" are used by hardware documentation. > I'd have called it "independent" or similar. > > > >> Does "optional" mean it's used if and > > >>> only if external MDIO is used, or is it optional even with > > >>> external MDIO? I see it's not present in the example -- do we not > > >>> have a real example that has the interrupt? > > >> [S.H] "optional" means it's available on hardware, but MDIO driver does > > >> not > use interrupt. > > >> So we don't have a real example. > > > > > > The device tree describes the hardware, not > > > the driver > > > > Anyway, only two MDIO nodes (out of 4 to 14) would have an interrupt > > property describing exactly one interrupt. What language should we use > > to convey this situation > > So the answer is that there will not be more than one MDIO controller per MDIO > node, or more than one interrupt per MDIO node? [S.H] Yes, one MDIO controller per MDIO node, and one interrupt per "external" MDIO node. In that case just get rid of > the confusing "respectively" sentence -- and always describe the interrupt if > it > exists in hardware. [S.H] OK. Thanks! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
> > > -Original Message-
> > > From: shh@gmail.com [mailto:shh@gmail.com]
> > > Sent: Tuesday, December 23, 2014 3:58 PM
> > > To: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Wood
> > > Scott-B07421
> > > Cc: Medve Emilian-EMMEDVE1; Xie Shaohui-B21989
> > > Subject: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
> > >
> > > From: Shaohui Xie
> > >
> > > This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
> > >
> > > Signed-off-by: Shaohui Xie
> > > ---
> > > changes in v3:
> > > rephrase the 'Definition' of property 'bus-frequency', don't include
> > > the property in example.
> > >
> > > changes in v2:
> > > addressed comments from Scott in V1.
> > >
> > > .../devicetree/bindings/powerpc/fsl/fman.txt | 69
> ++
> > > 1 file changed, 69 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > > b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > > index edeea16..737aa4c 100644
> > > --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > > +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > > @@ -7,6 +7,7 @@ CONTENTS
> > >- FMan MURAM Node
> > >- FMan dTSEC/XGEC/mEMAC Node
> > >- FMan IEEE 1588 Node
> > > + - FMan MDIO Node
> > >- Example
> > >
> > >
> > >
> > > = @@ -357,6 +358,69 @@ ptp-timer@fe000 { };
> > >
> > >
> > >
> > > =
> > > +FMan MDIO Node
> > > +
> > > +DESCRIPTION
> > > +
> > > +The MDIO is a bus to which the PHY devices are connected.
> > > +
> > > +PROPERTIES
> > > +
> > > +- compatible
> > > + Usage: required
> > > + Value type:
> > > + Definition: A standard property.
> > > + Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> > > + Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> > > + Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> > > + FMan v3.
> > > +
> > > +- reg
> > > + Usage: required
> > > + Value type:
> > > + Definition: A standard property.
> > > +
> > > +- bus-frequency
> > > + Usage: optional
> > > + Value type:
> > > + Definition: Specifies the external MDIO bus clock speed to
> > > + be used, if different from the standard 2.5 MHz.
> > > + This may be due to the standard speed being unsupported (e.g.
> > > + due to a hardware problem), or to advertise that all relevant
> > > + components in the system support a faster speed.
> > > +
> > > +- interrupts
> > > + Usage: optional
> > > + Value type:
> > > + Definition: Event interrupt of external MDIO controller.
> > > + 1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt respectively.
>
> I'm confused by "respectively" here. Does fsl,fman-memac-mdio have two
> interrupts (one for 1 Gb/s and one for 10 Gb/s)?
[S.H] We use two MDIO controllers for external PHY management. One for 1 Gb/s,
One for 10 Gb/s, and two MDIO interrupts connected to MPIC.
If there's only (at
> most) one interrupt per MDIO controller then just delete this line.
>
> What interrupt is used for internal MDIO?
[S.H] internal MDIO has no interrupt.
Does "optional" mean it's used if and
> only if external MDIO is used, or is it optional even with external MDIO? I
> see
> it's not present in the example -- do we not have a real example that has the
> interrupt?
[S.H] "optional" means it's available on hardware, but MDIO driver does not use
interrupt.
So we don't have a real example.
Thanks!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
Hello Scott,
Is this v3 OK?
Best Regards,
Shaohui Xie
> -Original Message-
> From: shh@gmail.com [mailto:shh@gmail.com]
> Sent: Tuesday, December 23, 2014 3:58 PM
> To: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Wood
> Scott-B07421
> Cc: Medve Emilian-EMMEDVE1; Xie Shaohui-B21989
> Subject: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
>
> From: Shaohui Xie
>
> This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
>
> Signed-off-by: Shaohui Xie
> ---
> changes in v3:
> rephrase the 'Definition' of property 'bus-frequency', don't include the
> property in example.
>
> changes in v2:
> addressed comments from Scott in V1.
>
> .../devicetree/bindings/powerpc/fsl/fman.txt | 69
> ++
> 1 file changed, 69 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> index edeea16..737aa4c 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> @@ -7,6 +7,7 @@ CONTENTS
>- FMan MURAM Node
>- FMan dTSEC/XGEC/mEMAC Node
>- FMan IEEE 1588 Node
> + - FMan MDIO Node
>- Example
>
> =
> @@ -357,6 +358,69 @@ ptp-timer@fe000 {
> };
>
> =
> +FMan MDIO Node
> +
> +DESCRIPTION
> +
> +The MDIO is a bus to which the PHY devices are connected.
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type:
> + Definition: A standard property.
> + Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> + Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> + Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> + FMan v3.
> +
> +- reg
> + Usage: required
> + Value type:
> + Definition: A standard property.
> +
> +- bus-frequency
> + Usage: optional
> + Value type:
> + Definition: Specifies the external MDIO bus clock speed to
> + be used, if different from the standard 2.5 MHz.
> + This may be due to the standard speed being unsupported (e.g.
> + due to a hardware problem), or to advertise that all relevant
> + components in the system support a faster speed.
> +
> +- interrupts
> + Usage: optional
> + Value type:
> + Definition: Event interrupt of external MDIO controller.
> + 1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt respectively.
> +
> +- fsl,fman-internal-mdio
> + Usage: required for internal MDIO
> + Value type: boolean
> + Definition: Fman has internal MDIO for internal PCS(Physical
> + Coding Sublayer) PHYs and external MDIO for external PHYs.
> + The settings and programming routines for internal/external
> + MDIO are different. Must be included for internal MDIO.
> +
> +EXAMPLE
> +
> +Example for FMan v2 external MDIO:
> +
> +mdio@f1000 {
> + compatible = "fsl,fman-xmdio";
> + reg = <0xf1000 0x1000>;
> +};
> +
> +Example for FMan v3 internal MDIO:
> +
> +mdio@f1000 {
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0xf1000 0x1000>;
> + fsl,fman-internal-mdio;
> +};
> +
> +===
> +==
> Example
>
> fman@40 {
> @@ -531,4 +595,9 @@ fman@40 {
> compatible = "fsl,fman-ptp-timer";
> reg = <0xfe000 0x1000>;
> };
> +
> + mdio@f1000 {
> + compatible = "fsl,fman-xmdio";
> + reg = <0xf1000 0x1000>;
> + };
> };
> --
> 1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc/config: enable mdio buses muxing via Memory-mapped device
> -Original Message- > From: Emil Medve [mailto:emilian.me...@freescale.com] > Sent: Monday, January 05, 2015 5:29 PM > To: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 > Cc: Andy Fleming; Kanetkar Shruti-B44454 > Subject: Re: [PATCH 2/2] powerpc/config: enable mdio buses muxing via > Memory-mapped device > > Hello Shao-Hui, > > > On 01/03/2015 10:58 PM, Xie Shaohui-B21989 wrote: > > Hello Emil, > > > > The patches sent by Shruti were marked as "Changes Requested" over 5 > months. > > to me if the patches do need changes, the possible changes seems not in > 'config' but in corenet_generic.c. > > It was part of a series that needed changes in other patches [S.H] So the patch itself has no issue? if that is the case maybe the patch can be sent Individually since it does not depend on others? > > > I'm not sure if it's OK to add some compatibles in corenet_generic.c. > > if we can use the existing compatible "simple-bus", Then we will only > need to enable MDIO mux option in config without adding compatible in > corenet_generic.c. > > The container "bus" of the "muxing" nodes doesn't carry the "simple-bus" > compatible and (as per the ePAPR definition) I'm unsure it would be > applicable > [S.H] I'm not sure if the "simple-bus" can be used as an extension of MDIO mux compatible. I was thinking another option, if "simple-bus" is not suitable here, then forget it.:) Thanks! Shaohui > >> -Original Message- > >> From: Emil Medve [mailto:emilian.me...@freescale.com] > >> Sent: Friday, January 02, 2015 4:43 PM > >> To: shh@gmail.com; linuxppc-dev@lists.ozlabs.org; Wood > >> Scott-B07421 > >> Cc: Andy Fleming; Xie Shaohui-B21989; Kanetkar Shruti-B44454 > >> Subject: Re: [PATCH 2/2] powerpc/config: enable mdio buses muxing via > >> Memory-mapped device > >> > >> Hello Shao-Hui, > >> > >> > >> On 12/22/2014 03:21 AM, shh@gmail.com wrote: > >>> From: Andy Fleming > >>> > >>> Signed-off-by: Andy Fleming > >>> Signed-off-by: Shaohui Xie > >>> --- > >>> arch/powerpc/configs/corenet32_smp_defconfig | 1 + > >>> arch/powerpc/configs/corenet64_smp_defconfig | 1 + > >>> 2 files changed, 2 insertions(+) > >> > >> Shruti submitted a more complete version of this patch here: > >> > >> http://patchwork.ozlabs.org/patch/370873 > >> > >> We should stick with that version > >> > >> > >> Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc/config: enable mdio buses muxing via Memory-mapped device
Hello Emil, The patches sent by Shruti were marked as "Changes Requested" over 5 months. to me if the patches do need changes, the possible changes seems not in 'config' but in corenet_generic.c. I'm not sure if it's OK to add some compatibles in corenet_generic.c. if we can use the existing compatible "simple-bus", Then we will only need to enable MDIO mux option in config without adding compatible in corenet_generic.c. Best Regards, Shaohui Xie > -Original Message- > From: Emil Medve [mailto:emilian.me...@freescale.com] > Sent: Friday, January 02, 2015 4:43 PM > To: shh@gmail.com; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 > Cc: Andy Fleming; Xie Shaohui-B21989; Kanetkar Shruti-B44454 > Subject: Re: [PATCH 2/2] powerpc/config: enable mdio buses muxing via > Memory-mapped device > > Hello Shao-Hui, > > > On 12/22/2014 03:21 AM, shh@gmail.com wrote: > > From: Andy Fleming > > > > Signed-off-by: Andy Fleming > > Signed-off-by: Shaohui Xie > > --- > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > 2 files changed, 2 insertions(+) > > Shruti submitted a more complete version of this patch here: > > http://patchwork.ozlabs.org/patch/370873 > > We should stick with that version > > > Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, December 23, 2014 4:08 PM > To: Xie Shaohui-B21989 > Cc: Medve Emilian-EMMEDVE1; linuxppc-dev@lists.ozlabs.org; > devicet...@vger.kernel.org; Liberman Igal-B31950 > Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan > > On Tue, 2014-12-23 at 01:35 -0600, Xie Shaohui-B21989 wrote: > > +- bus-frequency > > + Usage: optional > > + Value type: > > + Definition: Specifies external MDIO bus clock speed which is > > + different from MDIO standard 2.5MHz. Should be defined for > SoCs > > + on which the standard one cannot work. > > > > What should I rephrase it? Replace the last sentence with "Should be > > defined For SoCs on which a lower frequency than the standard is > required."? > > Neither of these work with Emil's scenario of a system that allows a > faster-than-standard speed. > > How about: "Definition: Specifies the external MDIO bus clock speed to be > used, if different from the standard 2.5 MHz. This may be due to the > standard speed being unsupported (e.g. due to a hardware problem), or to > advertise that all relevant components in the system support a faster > speed." [S.H] OK. I'll use this in V3. > > > How about the value used in example? > > Should 2.5MHz be used or a lower one? > > If you don't have a realistic example to use, don't put it in the example > at all. 2.5MHz is the worst example to use because that's the default > and there'd be no reason to use the property at all. [S.H] OK. The V3 will not have this in example. Thank you all for reviewing! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
Best Regards, Shaohui Xie > -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, December 23, 2014 5:26 AM > To: Medve Emilian-EMMEDVE1 > Cc: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org; > devicet...@vger.kernel.org; Liberman Igal-B31950 > Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan > > On Mon, 2014-12-22 at 05:08 -0600, Emil Medve wrote: > > Hello Scott, > > > > > > On 12/22/2014 03:42 AM, Scott Wood wrote: > > > On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote: > > >> Hello Scott, > > >> > > >> > > >> On 12/22/2014 02:32 AM, Scott Wood wrote: > > >>> On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote: > > >>>> For the purpose of an example in the binding document, I suggest > > >>>> we just stick with the IEEE standard frequency. > > >>> > > >>> The whole reason for this property existing in the device tree is > > >>> non-standard frequencies. > > >> > > >> While the standard claims 2.5 MHz, most MDIO controllers and PHY > > >> devices support frequencies well beyond the standard. Specifying a > > >> lower then the standard frequency for the benefit of some errata is > > >> just one side of this property > > > > > > The erratum was (until now) the only claimed reason for it. If > > > there are other reasons why one would specify a different frequency > > > (in particular, that relate to hardware description), please > elaborate. > > > > From memory, the 1 Gb/s Vitesse PHY(s) we have on some of our DS > > boards support 12.5 MHz. I can dig out more specs for specifics on > > other PHY(s) > > > > 2.5 MHz is slow and even more so for high speed interfaces. With both > > polling and interrupts (both MDIO and/or PHY) we've noticed (or > > blamed) in the past some Ethernet performance issues on this very > > slowness > > > > As of right now I'm not aware of another way to specify/coordinate the > > MDC speed so setting a default (common denominator) in the DT that is > > different then the IEEE standard seems ok > > > > >>>> We can continue this conversation about errata handling when we > > >>>> submit the code relevant to this binding (and the FMan v3 > > >>>> support) > > >>> > > >>> It affects the binding, so let's discuss it now please. > > >> > > >> I think this specific (unpublished yet) errata has less bearing on > > >> the binding then you might believe. This is mostly about providing > > >> a common/default frequency supported by all the devices on some > > >> board > > > > > > What reason other than an erratum would there be for the standard > > > frequency not being supported? > > > > This is not about not supporting the standard frequency. This is about > > the default frequency being different then the standard > > OK, though rather than talk about defaults I'd phrase it as indicating > that a higher frequency than standard is supported, or that a lower > frequency than standard is required. [S.H] below is the statement in v2: +- bus-frequency + Usage: optional + Value type: + Definition: Specifies external MDIO bus clock speed which is + different from MDIO standard 2.5MHz. Should be defined for SoCs + on which the standard one cannot work. What should I rephrase it? Replace the last sentence with "Should be defined For SoCs on which a lower frequency than the standard is required."? How about the value used in example? Should 2.5MHz be used or a lower one? Thanks! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, December 22, 2014 4:33 PM
> To: Medve Emilian-EMMEDVE1
> Cc: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org;
> devicet...@vger.kernel.org; Liberman Igal-B31950
> Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
>
> On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
> > Hello Shao-Hui,
> >
> >
> > On 12/21/2014 08:31 PM, Xie Shaohui-B21989 wrote:
> > >> On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
> > >>>> -Original Message-
> > >>>> From: Wood Scott-B07421
> > >>>> Sent: Friday, December 19, 2014 6:01 AM
> > >>>> To: Xie Shaohui-B21989
> > >>>> Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org;
> > >>>> Medve
> > >>>> Emilian- EMMEDVE1; Liberman Igal-B31950
> > >>>> Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> > >>>>
> > >>>> On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
> > >>>>> Ping.
> > >>>>>
> > >>>>> Best Regards,
> > >>>>> Shaohui Xie
> > >>>>
> > >>>> I can't put patches in my -next until the merge window closes.
> > >>>>
> > >>>>>>>> +EXAMPLE
> > >>>>>>>> +
> > >>>>>>>> +Example for FMan v2 external MDIO:
> > >>>>>>>> +
> > >>>>>>>> +mdio@f1000 {
> > >>>>>>>> + compatible = "fsl,fman-xmdio";
> > >>>>>>>> + reg = <0xf1000 0x1000>;
> > >>>>>>>> + bus-frequency = <2>;
> > >>>>>>>> +};
> > >>>>>>>
> > >>>>>>> So the bus frequency is only 20 KHz? Or is the unit supposed
> > >>>>>>> to be something other than Hz?
> > >>>>>> [S.H] it's only an example, it could be different on real SoCs,
> > >>>>>> but they always lower than the standard one, The standard one
> > >>>>>> is 2.5MHz, I have
> > >>>> to use Hz for it.
> > >>>>
> > >>>> Is there any SoC for which 20 kHz is the right frequency? I just
> > >>>> want to make sure the example is realistic.
> > >>> [S.H] the clock divider has a limitation that the MAX value it can
> > >>> get on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
> > >>>
> > >>> So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On
> > >>> Fman
> > >>> v3 is: Fman_clock / ((2 * 511) + 1).
> > >>>
> > >>> Take default Fman frequency setting from SDK1.7 as example, the
> > >>> lowest clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is
> 600MHz.
> > >>>
> > >>> Then the lowest bus frequency can get is:
> > >>> Fman v2: ~1140KHz
> > >>> Fman v3: ~587KHz
> > >>>
> > >>> 20KHz is not practice, we don't have a suggested value in errata
> > >>> document.
> > >>> For this example, should I post a new version with a value like 1200KHz?
> > >>
> > >> This is different from how you described the problem before. If
> > >> the limitation is on the divider, rather than the absolute bus
> > >> frequency, then specifiy the max divider. Or better, since
> > >> according to the above this correlates with fman version, just have the
> driver know what the max divider is for each fman version.
> > > [S.H] The problem is not the divider has limitation, the problem is
> > > a different bus frequency Is needed which is lower than the
> > > standard, but due to the divider limitation, the lowest bus
> > > frequency also has limitation. i.e. we need to use the divider to get a
> lower frequency, but how much lower the value could be is restricted by the
> divider limitation.
>
> This is difficult to follow -- are you saying the erratum requires a speed
> that
> is not achievable?
[S.H] The errata only stated that it need to use a larger divider to reduce the
clock
Frequency, but it did not provide a suggested value, what we know is since the
divider
Has a limitation, then how much lower the clock frequency could be reduced has
a limitation.
Thanks!
Shaohui
>
> > For the purpose of an example in the binding document, I suggest we
> > just stick with the IEEE standard frequency.
>
> The whole reason for this property existing in the device tree is non-standard
> frequencies.
>
> > We can continue this conversation about errata handling when we submit
> > the code relevant to this binding (and the FMan v3 support)
>
> It affects the binding, so let's discuss it now please.
>
> -Scott
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, December 19, 2014 6:01 AM
> > > To: Xie Shaohui-B21989
> > > Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
> > > Emilian- EMMEDVE1; Liberman Igal-B31950
> > > Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> > >
> > > On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
> > > > Ping.
> > > >
> > > > Best Regards,
> > > > Shaohui Xie
> > >
> > > I can't put patches in my -next until the merge window closes.
> > >
> > > > > > > +EXAMPLE
> > > > > > > +
> > > > > > > +Example for FMan v2 external MDIO:
> > > > > > > +
> > > > > > > +mdio@f1000 {
> > > > > > > + compatible = "fsl,fman-xmdio";
> > > > > > > + reg = <0xf1000 0x1000>;
> > > > > > > + bus-frequency = <2>;
> > > > > > > +};
> > > > > >
> > > > > > So the bus frequency is only 20 KHz? Or is the unit supposed
> > > > > > to be something other than Hz?
> > > > > [S.H] it's only an example, it could be different on real SoCs,
> > > > > but they always lower than the standard one, The standard one is
> > > > > 2.5MHz, I have
> > > to use Hz for it.
> > >
> > > Is there any SoC for which 20 kHz is the right frequency? I just
> > > want to make sure the example is realistic.
> > [S.H] the clock divider has a limitation that the MAX value it can get
> > on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
> >
> > So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On Fman
> > v3 is: Fman_clock / ((2 * 511) + 1).
> >
> > Take default Fman frequency setting from SDK1.7 as example, the lowest
> > clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is 600MHz.
> >
> > Then the lowest bus frequency can get is:
> > Fman v2: ~1140KHz
> > Fman v3: ~587KHz
> >
> > 20KHz is not practice, we don't have a suggested value in errata document.
> > For this example, should I post a new version with a value like 1200KHz?
>
> This is different from how you described the problem before. If the
> limitation
> is on the divider, rather than the absolute bus frequency, then specifiy the
> max
> divider. Or better, since according to the above this correlates with fman
> version, just have the driver know what the max divider is for each fman
> version.
[S.H] The problem is not the divider has limitation, the problem is a different
bus frequency
Is needed which is lower than the standard, but due to the divider limitation,
the lowest
bus frequency also has limitation. i.e. we need to use the divider to get a
lower frequency,
but how much lower the value could be is restricted by the divider limitation.
Thanks!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, December 19, 2014 6:01 AM
> To: Xie Shaohui-B21989
> Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve Emilian-
> EMMEDVE1; Liberman Igal-B31950
> Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
>
> On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
> > Ping.
> >
> > Best Regards,
> > Shaohui Xie
>
> I can't put patches in my -next until the merge window closes.
>
> > > > > +EXAMPLE
> > > > > +
> > > > > +Example for FMan v2 external MDIO:
> > > > > +
> > > > > +mdio@f1000 {
> > > > > + compatible = "fsl,fman-xmdio";
> > > > > + reg = <0xf1000 0x1000>;
> > > > > + bus-frequency = <2>;
> > > > > +};
> > > >
> > > > So the bus frequency is only 20 KHz? Or is the unit supposed to
> > > > be something other than Hz?
> > > [S.H] it's only an example, it could be different on real SoCs, but
> > > they always lower than the standard one, The standard one is 2.5MHz, I
> > > have
> to use Hz for it.
>
> Is there any SoC for which 20 kHz is the right frequency? I just want to make
> sure the example is realistic.
[S.H] the clock divider has a limitation that the MAX value it can get on Fman
v2 is 255 (0xff, 8 bits),
On Fman v3 is 511(0x1ff, 9 bits).
So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255),
On Fman v3 is: Fman_clock / ((2 * 511) + 1).
Take default Fman frequency setting from SDK1.7 as example, the lowest clock
used for Fman v2 is 581MHz,
The lowest clock for Fman v3 is 600MHz.
Then the lowest bus frequency can get is:
Fman v2: ~1140KHz
Fman v3: ~587KHz
20KHz is not practice, we don't have a suggested value in errata document.
For this example, should I post a new version with a value like 1200KHz?
Thanks!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
Ping.
Best Regards,
Shaohui Xie
> -Original Message-
> From: Xie Shaohui-B21989
> Sent: Wednesday, November 26, 2014 10:11 AM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve Emilian-
> EMMEDVE1; Liberman Igal-B31950
> Subject: RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, November 26, 2014 9:50 AM
> > To: shh@gmail.com
> > Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
> > Emilian-EMMEDVE1; Liberman Igal-B31950; Xie Shaohui-B21989
> > Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> >
> > On Fri, 2014-11-14 at 17:53 +0800, shh@gmail.com wrote:
> > > From: Shaohui Xie
> > >
> > > This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
> > >
> > > Signed-off-by: Shaohui Xie
> > > ---
> > > changes in V2:
> > > addressed comments from Scott in V1.
> > >
> > > .../devicetree/bindings/powerpc/fsl/fman.txt | 69
> > ++
> > > 1 file changed, 69 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > > b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > > index edeea16..1523a87 100644
> > > --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > > +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > > @@ -7,6 +7,7 @@ CONTENTS
> > >- FMan MURAM Node
> > >- FMan dTSEC/XGEC/mEMAC Node
> > >- FMan IEEE 1588 Node
> > > + - FMan MDIO Node
> > >- Example
> > >
> > >
> > >
> > > == === @@ -357,6 +358,68 @@ ptp-timer@fe000 { };
> > >
> > >
> > >
> > > ==
> > > ===
> > > +FMan MDIO Node
> > > +
> > > +DESCRIPTION
> > > +
> > > +The MDIO is a bus to which the PHY devices are connected.
> > > +
> > > +PROPERTIES
> > > +
> > > +- compatible
> > > + Usage: required
> > > + Value type:
> > > + Definition: A standard property.
> > > + Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> > > + Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> > > + Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> > > + FMan v3.
> > > +
> > > +- reg
> > > + Usage: required
> > > + Value type:
> > > + Definition: A standard property.
> > > +
> > > +- bus-frequency
> > > + Usage: optional
> > > + Value type:
> > > + Definition: Specifies external MDIO bus clock speed which is
> > > + different from MDIO standard 2.5MHz. Should be defined for
> > SoCs
> > > + on which the standard one cannot work.
> > > +
> > > +- interrupts
> > > + Usage: optional
> > > + Value type:
> > > + Definition: Event interrupt of external MDIO controller.
> > > + 1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt respectively.
> > > +
> > > +- fsl,fman-internal-mdio
> > > + Usage: required for internal MDIO
> > > + Value type: boolean
> > > + Definition: Fman has internal MDIO for internal PCS(Physical
> > > + Coding Sublayer) PHYs and external MDIO for external PHYs.
> > > + The settings and programming routines for internal/external
> > > + MDIO are different. Must be included for internal MDIO.
> > > +
> > > +EXAMPLE
> > > +
> > > +Example for FMan v2 external MDIO:
> > > +
> > > +mdio@f1000 {
> > > + compatible = "fsl,fman-xmdio";
> > > + reg = <0xf1000 0x1000>;
> > > + bus-frequency = <2>;
> > > +};
> >
> > So the bus frequency is only 20 KHz? Or is the unit supposed to be
> > something other than Hz?
> [S.H] it's only an example, it could be different on real SoCs, but they
> always
> lower than the standard one, The standard one is 2.5MHz, I have to use Hz for
> it.
>
> Thanks!
> Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, November 26, 2014 9:50 AM
> To: shh@gmail.com
> Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
> Emilian-EMMEDVE1; Liberman Igal-B31950; Xie Shaohui-B21989
> Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
>
> On Fri, 2014-11-14 at 17:53 +0800, shh@gmail.com wrote:
> > From: Shaohui Xie
> >
> > This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
> >
> > Signed-off-by: Shaohui Xie
> > ---
> > changes in V2:
> > addressed comments from Scott in V1.
> >
> > .../devicetree/bindings/powerpc/fsl/fman.txt | 69
> ++
> > 1 file changed, 69 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > index edeea16..1523a87 100644
> > --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > @@ -7,6 +7,7 @@ CONTENTS
> >- FMan MURAM Node
> >- FMan dTSEC/XGEC/mEMAC Node
> >- FMan IEEE 1588 Node
> > + - FMan MDIO Node
> >- Example
> >
> >
> > ==
> > === @@ -357,6 +358,68 @@ ptp-timer@fe000 { };
> >
> >
> > ==
> > ===
> > +FMan MDIO Node
> > +
> > +DESCRIPTION
> > +
> > +The MDIO is a bus to which the PHY devices are connected.
> > +
> > +PROPERTIES
> > +
> > +- compatible
> > + Usage: required
> > + Value type:
> > + Definition: A standard property.
> > + Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> > + Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> > + Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> > + FMan v3.
> > +
> > +- reg
> > + Usage: required
> > + Value type:
> > + Definition: A standard property.
> > +
> > +- bus-frequency
> > + Usage: optional
> > + Value type:
> > + Definition: Specifies external MDIO bus clock speed which is
> > + different from MDIO standard 2.5MHz. Should be defined for
> SoCs
> > + on which the standard one cannot work.
> > +
> > +- interrupts
> > + Usage: optional
> > + Value type:
> > + Definition: Event interrupt of external MDIO controller.
> > + 1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt respectively.
> > +
> > +- fsl,fman-internal-mdio
> > + Usage: required for internal MDIO
> > + Value type: boolean
> > + Definition: Fman has internal MDIO for internal PCS(Physical
> > + Coding Sublayer) PHYs and external MDIO for external PHYs.
> > + The settings and programming routines for internal/external
> > + MDIO are different. Must be included for internal MDIO.
> > +
> > +EXAMPLE
> > +
> > +Example for FMan v2 external MDIO:
> > +
> > +mdio@f1000 {
> > + compatible = "fsl,fman-xmdio";
> > + reg = <0xf1000 0x1000>;
> > + bus-frequency = <2>;
> > +};
>
> So the bus frequency is only 20 KHz? Or is the unit supposed to be
> something other than Hz?
[S.H] it's only an example, it could be different on real SoCs, but they always
lower than the standard one,
The standard one is 2.5MHz, I have to use Hz for it.
Thanks!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
Ping.
Best Regards,
Shaohui Xie
> -Original Message-
> From: shh@gmail.com [mailto:shh@gmail.com]
> Sent: Friday, November 14, 2014 5:53 PM
> To: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Wood
> Scott-B07421
> Cc: Medve Emilian-EMMEDVE1; Liberman Igal-B31950; Xie Shaohui-B21989
> Subject: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
>
> From: Shaohui Xie
>
> This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
>
> Signed-off-by: Shaohui Xie
> ---
> changes in V2:
> addressed comments from Scott in V1.
>
> .../devicetree/bindings/powerpc/fsl/fman.txt | 69
> ++
> 1 file changed, 69 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> index edeea16..1523a87 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> @@ -7,6 +7,7 @@ CONTENTS
>- FMan MURAM Node
>- FMan dTSEC/XGEC/mEMAC Node
>- FMan IEEE 1588 Node
> + - FMan MDIO Node
>- Example
>
>
> =
>
> @@ -357,6 +358,68 @@ ptp-timer@fe000 {
> };
>
>
> =
>
> +FMan MDIO Node
> +
> +DESCRIPTION
> +
> +The MDIO is a bus to which the PHY devices are connected.
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type:
> + Definition: A standard property.
> + Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> + Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> + Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> + FMan v3.
> +
> +- reg
> + Usage: required
> + Value type:
> + Definition: A standard property.
> +
> +- bus-frequency
> + Usage: optional
> + Value type:
> + Definition: Specifies external MDIO bus clock speed which is
> + different from MDIO standard 2.5MHz. Should be defined for
> SoCs
> + on which the standard one cannot work.
> +
> +- interrupts
> + Usage: optional
> + Value type:
> + Definition: Event interrupt of external MDIO controller.
> + 1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt respectively.
> +
> +- fsl,fman-internal-mdio
> + Usage: required for internal MDIO
> + Value type: boolean
> + Definition: Fman has internal MDIO for internal PCS(Physical
> + Coding Sublayer) PHYs and external MDIO for external PHYs.
> + The settings and programming routines for internal/external
> + MDIO are different. Must be included for internal MDIO.
> +
> +EXAMPLE
> +
> +Example for FMan v2 external MDIO:
> +
> +mdio@f1000 {
> + compatible = "fsl,fman-xmdio";
> + reg = <0xf1000 0x1000>;
> + bus-frequency = <2>;
> +};
> +
> +Example for FMan v3 internal MDIO:
> +
> +mdio@f1000 {
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0xf1000 0x1000>;
> + fsl,fman-internal-mdio;
> +};
> +
> +
> =
> Example
>
> fman@40 {
> @@ -531,4 +594,10 @@ fman@40 {
> compatible = "fsl,fman-ptp-timer";
> reg = <0xfe000 0x1000>;
> };
> +
> + mdio@f1000 {
> + compatible = "fsl,fman-xmdio";
> + reg = <0xf1000 0x1000>;
> + bus-frequency = <2>;
> + };
> };
> --
> 1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] DT: add MDIO node for FMan node
Best Regards, Shaohui Xie > -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, November 13, 2014 4:04 PM > To: Xie Shaohui-B21989 > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > On Thu, 2014-11-13 at 02:02 -0600, Xie Shaohui-B21989 wrote: > > > > > > Best Regards, > > Shaohui Xie > > > > > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Thursday, November 13, 2014 3:15 PM > > > To: Xie Shaohui-B21989 > > > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > > > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > On Thu, 2014-11-13 at 01:11 -0600, Xie Shaohui-B21989 wrote: > > > > > -Original Message- > > > > > From: Wood Scott-B07421 > > > > > Sent: Thursday, November 13, 2014 2:17 PM > > > > > To: Xie Shaohui-B21989 > > > > > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > > > > > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > > > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > > > > > On Wed, 2014-11-12 at 07:40 -0600, Xie Shaohui-B21989 wrote: > > > > > > > -Original Message- > > > > > > > From: Wood Scott-B07421 > > > > > > > Sent: Wednesday, November 12, 2014 1:38 AM > > > > > > > To: Xie Shaohui-B21989 > > > > > > > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > > > > > > > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > > > > > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > > > > > > > > > On Tue, 2014-11-11 at 04:32 -0600, Xie Shaohui-B21989 wrote: > > > > > > > > > -Original Message- > > > > > > > > > From: Wood Scott-B07421 > > > > > > > > > Sent: Tuesday, November 11, 2014 8:23 AM > > > > > > > > > To: shh@gmail.com > > > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; > > > > > > > > > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1; Xie > > > > > > > > > Shaohui-B21989 > > > > > > > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > > > > > > > > > > > > > On Tue, 2014-11-04 at 19:56 +0800, shh@gmail.com > wrote: > > > > > > > > > > From: Shaohui Xie > > > > > > > > > > > > > > > > > > > > This binding is for FMan MDIO, it covers FMan v2 & FMan > v3. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Shaohui Xie > > > > > > > > > > --- > > > > > > > > > > based on http://patchwork.ozlabs.org/patch/390351/ > > > > > > > > > > for 'next' of > > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux. > > > > > > > > > > git > > > > > > > > > > > > > > > > > > Are there any other FMan pieces that are missing from > > > > > > > > > the above > > > > > patch? > > > > > > > > [S.H] I'm adding Igal for this comment. > > > > > > > > > > > > > > > > > > > > > > > > > > > +- bus-frequency > > > > > > > > > > + Usage: optional > > > > > > > > > > + Value type: > > > > > > > > > > + Definition: Default MDIO bus clock speed. > > > > > > > > > > > > > > > > > > Use clocks/clock-names > > > > > > > > [S.H] The MDIO uses Fman clock and divides it to a proper > > > > > > > > value which > > > > > > > is specified by this property. > > > > > > > > > > > > > > Use clocks/clock-names to describe that relationship. > > > > > > > > > > > > &g
RE: [PATCH] DT: add MDIO node for FMan node
Best Regards, Shaohui Xie > -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, November 13, 2014 3:15 PM > To: Xie Shaohui-B21989 > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > On Thu, 2014-11-13 at 01:11 -0600, Xie Shaohui-B21989 wrote: > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Thursday, November 13, 2014 2:17 PM > > > To: Xie Shaohui-B21989 > > > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > > > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > On Wed, 2014-11-12 at 07:40 -0600, Xie Shaohui-B21989 wrote: > > > > > -Original Message- > > > > > From: Wood Scott-B07421 > > > > > Sent: Wednesday, November 12, 2014 1:38 AM > > > > > To: Xie Shaohui-B21989 > > > > > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > > > > > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > > > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > > > > > On Tue, 2014-11-11 at 04:32 -0600, Xie Shaohui-B21989 wrote: > > > > > > > -Original Message- > > > > > > > From: Wood Scott-B07421 > > > > > > > Sent: Tuesday, November 11, 2014 8:23 AM > > > > > > > To: shh@gmail.com > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; > > > > > > > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1; Xie > > > > > > > Shaohui-B21989 > > > > > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > > > > > > > > > On Tue, 2014-11-04 at 19:56 +0800, shh@gmail.com wrote: > > > > > > > > From: Shaohui Xie > > > > > > > > > > > > > > > > This binding is for FMan MDIO, it covers FMan v2 & FMan v3. > > > > > > > > > > > > > > > > Signed-off-by: Shaohui Xie > > > > > > > > --- > > > > > > > > based on http://patchwork.ozlabs.org/patch/390351/ > > > > > > > > for 'next' of > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux. > > > > > > > > git > > > > > > > > > > > > > > Are there any other FMan pieces that are missing from the > > > > > > > above > > > patch? > > > > > > [S.H] I'm adding Igal for this comment. > > > > > > > > > > > > > > > > > > > > > +- bus-frequency > > > > > > > > + Usage: optional > > > > > > > > + Value type: > > > > > > > > + Definition: Default MDIO bus clock speed. > > > > > > > > > > > > > > Use clocks/clock-names > > > > > > [S.H] The MDIO uses Fman clock and divides it to a proper > > > > > > value which > > > > > is specified by this property. > > > > > > > > > > Use clocks/clock-names to describe that relationship. > > > > > > > > > > > > > [S.H] The MDIO node is sub-node and embedded in Fman node, the > > > > clocks/clock-names is provided by Fman node, should repeat them in > > > > MDIO node? For the default MDIO bus clock speed, maybe "clock- > ranges" > > > > should be used? > > > > > > It's a different clock. You wouldn't be repeating. If it's derived > > > from the FMan clock, then maybe you don't need anything here (does > > > the driver know what the divider is, or would that need to be > > > specified in the device tree?), but no more clock-frequency/bus- > frequency properties. > > > > > [S.H] The purpose here is to get a specific clock frequency, driver to > use it to calculate the divider. > > Then the Fman clock can be divided to the frequency. > > Oh, so this is stating a desired frequency and not something that already > exists? What determines this frequency? Is it based on board design, or > just on the MDIO standard, etc? I'm wondering if the device tree is the > right place for it. [S.H] Yes, a desired frequency which is different with MDIO standard. The Fman clock and the divider determines this frequency. Since Fman clock is different on different SoCs, so specify the desired frequency, then to get the proper divider. Thanks. shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] DT: add MDIO node for FMan node
> -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, November 13, 2014 2:17 PM > To: Xie Shaohui-B21989 > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > On Wed, 2014-11-12 at 07:40 -0600, Xie Shaohui-B21989 wrote: > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Wednesday, November 12, 2014 1:38 AM > > > To: Xie Shaohui-B21989 > > > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > > > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > On Tue, 2014-11-11 at 04:32 -0600, Xie Shaohui-B21989 wrote: > > > > > -Original Message- > > > > > From: Wood Scott-B07421 > > > > > Sent: Tuesday, November 11, 2014 8:23 AM > > > > > To: shh@gmail.com > > > > > Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; > > > > > Medve Emilian-EMMEDVE1; Xie Shaohui-B21989 > > > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > > > > > On Tue, 2014-11-04 at 19:56 +0800, shh@gmail.com wrote: > > > > > > From: Shaohui Xie > > > > > > > > > > > > This binding is for FMan MDIO, it covers FMan v2 & FMan v3. > > > > > > > > > > > > Signed-off-by: Shaohui Xie > > > > > > --- > > > > > > based on http://patchwork.ozlabs.org/patch/390351/ > > > > > > for 'next' of > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux. > > > > > > git > > > > > > > > > > Are there any other FMan pieces that are missing from the above > patch? > > > > [S.H] I'm adding Igal for this comment. > > > > > > > > > > > > > > > +- bus-frequency > > > > > > + Usage: optional > > > > > > + Value type: > > > > > > + Definition: Default MDIO bus clock speed. > > > > > > > > > > Use clocks/clock-names > > > > [S.H] The MDIO uses Fman clock and divides it to a proper value > > > > which > > > is specified by this property. > > > > > > Use clocks/clock-names to describe that relationship. > > > > > > > [S.H] The MDIO node is sub-node and embedded in Fman node, the > > clocks/clock-names is provided by Fman node, should repeat them in > > MDIO node? For the default MDIO bus clock speed, maybe "clock-ranges" > > should be used? > > It's a different clock. You wouldn't be repeating. If it's derived from > the FMan clock, then maybe you don't need anything here (does the driver > know what the divider is, or would that need to be specified in the > device tree?), but no more clock-frequency/bus-frequency properties. > [S.H] The purpose here is to get a specific clock frequency, driver to use it to calculate the divider. Then the Fman clock can be divided to the frequency. > > [S.H] since Fman V2 & V3 can be differentiated by compatible, a > > boolean property "fsl,fman-internal-mdio" seems better, if defined, it > > indicates an internal MDIO. It looks like below: > > > > fsl,fman-internal-mdio > > Usage: required for internal MDIO > > Value type: Boolean > > Definition: Fman has internal MDIO for internal PCS(Physical > > Coding Sublayer) PHYs and external MDIO for external PHYs. > > The settings and programming routines for internal/external > > MDIO are different. Must be included for internal MDIO. > > > > How about this? > > This looks better, thanks. > > This would be set on fman v2 TBI mdio nodes as well, right? [S.H] Yes. But it's not used by driver. (I know I should not say this :) ) Thanks. Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] DT: add MDIO node for FMan node
> -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, November 12, 2014 1:38 AM > To: Xie Shaohui-B21989 > Cc: Liberman Igal-B31950; linuxppc-dev@lists.ozlabs.org; > devicet...@vger.kernel.org; Medve Emilian-EMMEDVE1 > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > On Tue, 2014-11-11 at 04:32 -0600, Xie Shaohui-B21989 wrote: > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Tuesday, November 11, 2014 8:23 AM > > > To: shh@gmail.com > > > Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve > > > Emilian-EMMEDVE1; Xie Shaohui-B21989 > > > Subject: Re: [PATCH] DT: add MDIO node for FMan node > > > > > > On Tue, 2014-11-04 at 19:56 +0800, shh@gmail.com wrote: > > > > From: Shaohui Xie > > > > > > > > This binding is for FMan MDIO, it covers FMan v2 & FMan v3. > > > > > > > > Signed-off-by: Shaohui Xie > > > > --- > > > > based on http://patchwork.ozlabs.org/patch/390351/ > > > > for 'next' of > > > > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git > > > > > > Are there any other FMan pieces that are missing from the above patch? > > [S.H] I'm adding Igal for this comment. > > > > > > > > > +- bus-frequency > > > > + Usage: optional > > > > + Value type: > > > > + Definition: Default MDIO bus clock speed. > > > > > > Use clocks/clock-names > > [S.H] The MDIO uses Fman clock and divides it to a proper value which > is specified by this property. > > Use clocks/clock-names to describe that relationship. > [S.H] The MDIO node is sub-node and embedded in Fman node, the clocks/clock-names is provided by Fman node, should repeat them in MDIO node? For the default MDIO bus clock speed, maybe "clock-ranges" should be used? > > > > > > > +- interrupts > > > > + Usage: optional > > > > + Value type: > > > > + Definition: MDIO controller event interrupts. > > > > > > One interrupt or multiple? > > [S.H] One for 1 Gb/s, one for 10 Gb/s. > > Then the binding needs to say that there are two (except for "fsl,fman- > mdio", right?) and which is which. > [S.H] OK. > > > > > > > + > > > > +- type > > > > + Usage: required for FMan v3 > > > > + Value type: > > > > + Definition: A standard property. > > > > > > What standard is "type" defined in? > > > > [S.H] It's to differentiate between the internal and external MDIO, > > I'm not quite sure about naming it, or what could be better way to > > differentiate the MDIOs? > > I'm not questioning the need to convey this information. I'm saying it's > not "A standard property". I'd also like to see a better name. > [S.H] since Fman V2 & V3 can be differentiated by compatible, a boolean property "fsl,fman-internal-mdio" seems better, if defined, it indicates an internal MDIO. It looks like below: fsl,fman-internal-mdio Usage: required for internal MDIO Value type: Boolean Definition: Fman has internal MDIO for internal PCS(Physical Coding Sublayer) PHYs and external MDIO for external PHYs. The settings and programming routines for internal/external MDIO are different. Must be included for internal MDIO. How about this? Thanks! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] DT: add MDIO node for FMan node
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, November 11, 2014 8:23 AM
> To: shh@gmail.com
> Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
> Emilian-EMMEDVE1; Xie Shaohui-B21989
> Subject: Re: [PATCH] DT: add MDIO node for FMan node
>
> On Tue, 2014-11-04 at 19:56 +0800, shh@gmail.com wrote:
> > From: Shaohui Xie
> >
> > This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
> >
> > Signed-off-by: Shaohui Xie
> > ---
> > based on http://patchwork.ozlabs.org/patch/390351/
> > for 'next' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
>
> Are there any other FMan pieces that are missing from the above patch?
[S.H] I'm adding Igal for this comment.
>
> > .../devicetree/bindings/powerpc/fsl/fman.txt | 69
> ++
> > 1 file changed, 69 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > index da8e5f2..83c2f14 100644
> > --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > @@ -7,6 +7,7 @@ CONTENTS
> >- FMan MURAM Node
> >- FMan dTSEC/XGEC/mEMAC Node
> >- FMan IEEE 1588 Node
> > + - FMan MDIO Node
> >- Example
> >
> >
> > ==
> > === @@ -352,6 +353,67 @@ ptp-timer@fe000 { };
> >
> >
> > ==
> > ===
> > +FMan MDIO Node
> > +
> > +DESCRIPTION
> > +
> > +The MDIO is a bus to which the PHY devices are connected.
> > +
> > +PROPERTIES
> > +
> > +- compatible
> > + Usage: required
> > + Value type:
> > + Definition: A standard property.
> > + Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> > + Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> > + Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> > + FMan v3.
> > +
> > +- reg
> > + Usage: required
> > + Value type:
> > + Definition: A standard property.
> > +
> > +- bus-frequency
> > + Usage: optional
> > + Value type:
> > + Definition: Default MDIO bus clock speed.
>
> Use clocks/clock-names
[S.H] The MDIO uses Fman clock and divides it to a proper value which is
specified by this property.
>
> > +- interrupts
> > + Usage: optional
> > + Value type:
> > + Definition: MDIO controller event interrupts.
>
> One interrupt or multiple?
[S.H] One for 1 Gb/s, one for 10 Gb/s.
>
> > +
> > +- type
> > + Usage: required for FMan v3
> > + Value type:
> > + Definition: A standard property.
>
> What standard is "type" defined in?
[S.H] It's to differentiate between the internal and external MDIO, I'm not
quite sure about naming it, or what could be better way to differentiate the
MDIOs?
>
> > + FMan v3 has internal MDIO for internal PCS(Physical Coding
> > + Sublayer) PHYs and external MDIO for external PHYs.
> > + The settings and programming routines for internal/external
> > + MDIO are different. Must include "internal" for internal MDIO,
> > + must include "external" for external MDIO.
>
> I assume fman v2 is always internal? How about a boolean "fsl,fman-
> internal-phy" property instead?
[S.H] Both Fman v2 & v3 have internal/external MDIO, Fman v2 uses internal MDIO
for TBI operations to set the SGMII PHY,
The TBI implements transmit/receive portions of PCS, it's not used in Linux.
The PCS on Fman V3 are not just for SGMII, it has more implementations, it's
used in Linux.
>
> > +
> > +EXAMPLE
> > +
> > +Example for FMan v2:
> > +
> > +mdio@f1000 {
> > + compatible = "fsl,fman-xmdio";
> > + reg = <0xf1000 0x1000>;
> > +};
> > +
> > +Example for FMan v3:
> > +
> > +mdio@fd000 {
> > + compatible = "fsl,fman-memac-mdio";
> > + reg = <0xfd000 0x1000>;
> > + bus-frequency = <250>;
> > + type = "external";
> > +};
> > +
> > +=
> > +
> > Example
> >
> > fman@40 {
> > @@ -526,4 +588,11 @@ fman@40 {
> > compatible = "fsl,fman-ptp-timer";
> > reg = <0xfe000 0x1000>;
> > };
> > +
> > + mdio@fd000 {
> > + compatible = "fsl,fman-memac-mdio";
> > + reg = <0xfd000 0x1000>;
> > + bus-frequency = <250>;
> > + type = "external";
> > + };
> > };
>
> The rest of the example is fman v2; don't mix an fman v3 node in with
> that.
[S.H] OK. Will fix it.
Thanks!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] DT: add MDIO node for FMan node
Ping.
Best Regards,
Shaohui Xie
> -Original Message-
> From: shh@gmail.com [mailto:shh@gmail.com]
> Sent: Tuesday, November 04, 2014 7:57 PM
> To: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Wood
> Scott-B07421
> Cc: Medve Emilian-EMMEDVE1; Xie Shaohui-B21989
> Subject: [PATCH] DT: add MDIO node for FMan node
>
> From: Shaohui Xie
>
> This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
>
> Signed-off-by: Shaohui Xie
> ---
> based on http://patchwork.ozlabs.org/patch/390351/
> for 'next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
>
> .../devicetree/bindings/powerpc/fsl/fman.txt | 69
> ++
> 1 file changed, 69 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> index da8e5f2..83c2f14 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> @@ -7,6 +7,7 @@ CONTENTS
>- FMan MURAM Node
>- FMan dTSEC/XGEC/mEMAC Node
>- FMan IEEE 1588 Node
> + - FMan MDIO Node
>- Example
>
>
> =
>
> @@ -352,6 +353,67 @@ ptp-timer@fe000 {
> };
>
>
> =
>
> +FMan MDIO Node
> +
> +DESCRIPTION
> +
> +The MDIO is a bus to which the PHY devices are connected.
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type:
> + Definition: A standard property.
> + Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> + Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> + Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> + FMan v3.
> +
> +- reg
> + Usage: required
> + Value type:
> + Definition: A standard property.
> +
> +- bus-frequency
> + Usage: optional
> + Value type:
> + Definition: Default MDIO bus clock speed.
> +
> +- interrupts
> + Usage: optional
> + Value type:
> + Definition: MDIO controller event interrupts.
> +
> +- type
> + Usage: required for FMan v3
> + Value type:
> + Definition: A standard property.
> + FMan v3 has internal MDIO for internal PCS(Physical Coding
> + Sublayer) PHYs and external MDIO for external PHYs.
> + The settings and programming routines for internal/external
> + MDIO are different. Must include "internal" for internal MDIO,
> + must include "external" for external MDIO.
> +
> +EXAMPLE
> +
> +Example for FMan v2:
> +
> +mdio@f1000 {
> + compatible = "fsl,fman-xmdio";
> + reg = <0xf1000 0x1000>;
> +};
> +
> +Example for FMan v3:
> +
> +mdio@fd000 {
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0xfd000 0x1000>;
> + bus-frequency = <250>;
> + type = "external";
> +};
> +
> +
> =
> Example
>
> fman@40 {
> @@ -526,4 +588,11 @@ fman@40 {
> compatible = "fsl,fman-ptp-timer";
> reg = <0xfe000 0x1000>;
> };
> +
> + mdio@fd000 {
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0xfd000 0x1000>;
> + bus-frequency = <250>;
> + type = "external";
> + };
> };
> --
> 1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b21989=freescale@lists.ozlabs.org] On Behalf Of Scott Wood
> Sent: Friday, August 01, 2014 2:31 AM
> To: Medve Emilian-EMMEDVE1
> Cc: linuxppc-...@ozlabs.org
> Subject: Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support
> to the board device tree(s)
>
> On Thu, 2014-07-31 at 00:48 -0500, Emil Medve wrote:
> > Hello Scott,
> >
> >
> > On 07/31/2014 12:28 AM, Scott Wood wrote:
> > > On Wed, 2014-07-30 at 23:35 -0500, Emil Medve wrote:
> > >> Hello Scott,
> > >>
> > >>
> > >> On 07/30/2014 09:30 PM, Scott Wood wrote:
> > >>> On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
> > + mdio0: mdio fc000 {
> > + };
> > >>>
> > >>> Why is the empty node needed?
> > >>
> > >> For the label
> > >
> > > For mdio-parent-bus, or is there some other dts layer that makes
> > > this node non-empty?
> >
> > 'powerpc/corenet: Create the dts components for the DPAA FMan' -
> > http://patchwork.ozlabs.org/patch/370872
> > >>>
> > >>> Why does this patch define the mdio0 label for mdio@e1120, but not
> > >>> define a label for any other node?
> > >>
> > >> Only MDIO controllers that are pinned out have these labels. Only
> > >> pinned out MDIO(s) are capable of controlling external PHY(s) via
> > >> these board level MDIO buses
> > >
> > > Is there any reason to describe non-pinned-out MDIO controllers at
> all?
[S.H] Regarding the pinned-out MDIO controllers and non-pinned-out MDIO
controllers,
How to differentiate them?
> >
> > Yes. For the internal TBI PHY(s). Each MAC supporting SGMII has a TBI
> > PHY that is attached to the MDIO controller of the respective MAC
>
[S.H] there are multiple internal PHYs on Fman-v3 SOCs. Each one is used for
Specific function, for ex. on T4 there are XFI, SGMII, QSGMII.
Will all of them be listed in the DTS?
Thanks!
-Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/7] dt: Introduce the FMan 10 Gb/s MDIO binding
Hello, Scott, Shruti,
There are two types MDIO controllers, each MAC has a corresponding MDIO
controller to access internal PHYs inside Serdes, another is dedicated MDIO
controller to access external PHYs (PHYs on board or riser card, etc). Current
MDIO driver does not distinguish the two controllers, if we need to distinguish
the controllers, what could be the proper way? Perhaps a new property is needed
in dts?
Please comment!
Thanks!
Best Regards,
Shaohui Xie
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b21989=freescale@lists.ozlabs.org] On Behalf Of Shruti
> Kanetkar
> Sent: Thursday, July 17, 2014 4:17 AM
> To: Wood Scott-B07421
> Cc: Kanetkar Shruti-B44454; linuxppc-dev@lists.ozlabs.org
> Subject: [PATCH v2 1/7] dt: Introduce the FMan 10 Gb/s MDIO binding
>
> This document covers FManv2 and FManv3 mEMAC MDIO
>
> Signed-off-by: Shruti Kanetkar
> ---
> .../devicetree/bindings/net/fsl-xgmac-phy.txt | 29
> ++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/fsl-xgmac-
> phy.txt
>
> diff --git a/Documentation/devicetree/bindings/net/fsl-xgmac-phy.txt
> b/Documentation/devicetree/bindings/net/fsl-xgmac-phy.txt
> new file mode 100644
> index 000..2f2d56d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/fsl-xgmac-phy.txt
> @@ -0,0 +1,29 @@
> +*MDIO IO device
> +
> +The MDIO is a bus to which the PHY devices are connected. For each
> +device that exists on this bus, a child node should be created.
> +
> +Required properties:
> + - compatible: Currently supported strings/devices are:
> + - "fsl,fman-xmdio" (Must be used for 10 Gb/s MDIO from
> FMan v2.
> + Can be used for 1/10 Gb/s MDIO from FMan v3)
> + - "fsl,fman-memac-mdio" (Must be used for 1/10 Gb/s
> MDIO from
> + FMan v3)
> + - reg
> +
> + Example for FMan v2:
> + mdio@f1000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,fman-xmdio";
> + reg = <0xf1000 0x1000>;
> + };
> +
> + Example for FMan v3:
> +
> + mdio@f1000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
> + reg = <0xf1000 0x1000>;
> + }
> --
> 1.8.3.1
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/4] phylib: Add generic 10G driver
Hello, Florian,
Thank you for reviewing the patches!
Please see my comments inline.
Best Regards,
Shaohui Xie
> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: Wednesday, November 13, 2013 1:54 AM
> To: shh@gmail.com
> Cc: linuxppc-dev; linux-ker...@vger.kernel.org; Bucur Madalin-Cristian-
> B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
> Subject: Re: [PATCH 2/4] phylib: Add generic 10G driver
>
> Hello Shaohui,
>
> 2013/11/11 :
> > From: Andy Fleming
> >
> > Very incomplete, but will allow for binding an ethernet controller to
> > it.
> >
> > Also, Add XGMII interface type
>
> So that should be two separate patches, and
> drivers/of/of_net.c::of_get_phy_mode() must be updated to know about
> XMGII.
>
> >
> > Signed-off-by: Andy Fleming
>
> Missing Andy's Signed-off-by tag.
[S.H] Will add in next version, I removed it to make git work since Andy's
e-mail address is not valid.
>
> > Signed-off-by: Shaohui Xie
> > ---
> > drivers/net/phy/phy_device.c | 101
> ++-
> > include/linux/phy.h | 1 +
> > 2 files changed, 101 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/phy_device.c
> > b/drivers/net/phy/phy_device.c index 74630e9..30bf2d5 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -32,6 +32,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > @@ -689,6 +690,13 @@ static int genphy_config_advert(struct phy_device
> *phydev)
> > return changed;
> > }
> >
> > +int gen10g_config_advert(struct phy_device *dev) {
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_config_advert);
> > +
> > +
> > /**
> > * genphy_setup_forced - configures/forces speed/duplex from @phydev
> > * @phydev: target phy_device struct
> > @@ -742,6 +750,12 @@ int genphy_restart_aneg(struct phy_device
> > *phydev) } EXPORT_SYMBOL(genphy_restart_aneg);
> >
> > +int gen10g_restart_aneg(struct phy_device *phydev) {
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_restart_aneg);
> > +
> >
> > /**
> > * genphy_config_aneg - restart auto-negotiation or write BMCR @@
> > -784,6 +798,13 @@ int genphy_config_aneg(struct phy_device *phydev) }
> > EXPORT_SYMBOL(genphy_config_aneg);
> >
> > +int gen10g_config_aneg(struct phy_device *phydev) {
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_config_aneg);
> > +
> > +
> > /**
> > * genphy_update_link - update link status in @phydev
> > * @phydev: target phy_device struct
> > @@ -913,6 +934,35 @@ int genphy_read_status(struct phy_device *phydev)
> > } EXPORT_SYMBOL(genphy_read_status);
> >
> > +int gen10g_read_status(struct phy_device *phydev) {
> > + int devad, reg;
> > + u32 mmd_mask = phydev->c45_ids.devices_in_package;
> > +
> > + phydev->link = 1;
> > +
> > + /* For now just lie and say it's 10G all the time */
> > + phydev->speed = 1;
>
> Can you at least make this a little more proof? Something along:
>
> if (phydev->supported & (SUPPORTED_1baseT_Full))
> phydev->speed = SPEED_1; else if (phydev->supported &
> (SUPPORTED_1000baseT_Full)
> phydev->speed = SPEED_1000;
[S.H] some 10G PHY only support 10G speed.
>
> Although ideally we should be reading the relevant registers to figure
> out what to do.
[S.H] Yes, code below will try to read the mmds to get status.
>
> > + phydev->duplex = DUPLEX_FULL;
> > +
> > + for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
> > + if (!(mmd_mask & 1))
> > + continue;
> > +
> > + /* Read twice because link state is latched and a
> > +* read moves the current state into the register
> > +*/
> > + phy_read_mmd(phydev, devad, MDIO_STAT1);
> > + reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
> > + if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
> > + phydev->link = 0;
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_read_status);
> > +
> > +
> > static int genphy_config_init(struct phy_device *phydev) {
> >
RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
> On Tue, 2013-11-12 at 19:51 -0600, Xie Shaohui-B21989 wrote: > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Wednesday, November 13, 2013 5:58 AM > > > To: shh@gmail.com > > > Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; > > > Kanetkar Shruti-B44454; Xie Shaohui-B21989; Bucur > > > Madalin-Cristian-B32716 > > > Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions > > > > > > On Mon, 2013-11-11 at 19:04 +0800, shh@gmail.com wrote: > > > > From: Andy Fleming > > > > > > > > You need an extra parameter to read or write Clause 45 PHYs, so we > > > > need a different API with the extra parameter. > > > > > > > > Signed-off-by: Andy Fleming > > > > Signed-off-by: Shaohui Xie > > > > > > Why did you remove Andy's e-mail address? Even though it's no > > > longer valid, it helps identify which specific person you're talking > > > about. > > > > > [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have > to remove it to make git work. > > Tell git send-email to not include that address, e.g. using --suppress-cc, > --no- > signed-off-by-cc, --suppress-from, etc. > [S.H] OK. Thank you! Best Regards, Shaohui Xie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
> -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, November 13, 2013 5:58 AM > To: shh@gmail.com > Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Kanetkar > Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716 > Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions > > On Mon, 2013-11-11 at 19:04 +0800, shh@gmail.com wrote: > > From: Andy Fleming > > > > You need an extra parameter to read or write Clause 45 PHYs, so we > > need a different API with the extra parameter. > > > > Signed-off-by: Andy Fleming > > Signed-off-by: Shaohui Xie > > Why did you remove Andy's e-mail address? Even though it's no longer valid, > it > helps identify which specific person you're talking about. > [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work. Best Regards, Shaohui Xie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/4] phylib: Support attaching to gen10g_driver
Added more people and list.
Best Regards,
Shaohui Xie
> -Original Message-
> From: shh@gmail.com [mailto:shh@gmail.com]
> Sent: Monday, November 11, 2013 7:08 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
> Subject: [PATCH 3/4] phylib: Support attaching to gen10g_driver
>
> From: Andy Fleming
>
> phy_attach_direct() may now attach to a generic 10G driver. It can also be
> used
> exactly as phy_connect_direct(), which will be useful when using of_mdio, as
> phy_connect (and therefore of_phy_connect) start the PHY state machine, which
> is
> currently irrelevant for 10G PHYs.
>
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie
> ---
> drivers/net/phy/phy_device.c | 23 +++
> include/linux/phy.h | 2 ++
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index
> 30bf2d5..f51ea2e 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -55,15 +55,13 @@ static void phy_device_release(struct device *dev) }
>
> static struct phy_driver genphy_driver;
> +static struct phy_driver gen10g_driver;
> extern int mdio_bus_init(void);
> extern void mdio_bus_exit(void);
>
> static LIST_HEAD(phy_fixup_list);
> static DEFINE_MUTEX(phy_fixup_lock);
>
> -static int phy_attach_direct(struct net_device *dev, struct phy_device
> *phydev,
> - u32 flags, phy_interface_t interface);
> -
> /*
> * Creates a new phy_fixup and adds it to the list
> * @bus_id: A string which matches phydev->dev.bus_id (or PHY_ANY_ID) @@ -
> 521,12 +519,12 @@ int phy_init_hw(struct phy_device *phydev)
> *
> * Description: Called by drivers to attach to a particular PHY
> * device. The phy_device is found, and properly hooked up
> - * to the phy_driver. If no driver is attached, then the
> - * genphy_driver is used. The phy_device is given a ptr to
> + * to the phy_driver. If no driver is attached, then a
> + * generic driver is used. The phy_device is given a ptr to
> * the attaching device, and given a callback for link status
> * change. The phy_device is returned to the attaching driver.
> */
> -static int phy_attach_direct(struct net_device *dev, struct phy_device
> *phydev,
> +int phy_attach_direct(struct net_device *dev, struct phy_device
> +*phydev,
>u32 flags, phy_interface_t interface) {
> struct device *d = &phydev->dev;
> @@ -535,12 +533,10 @@ static int phy_attach_direct(struct net_device *dev,
> struct phy_device *phydev,
> /* Assume that if there is no driver, that it doesn't
>* exist, and we should use the genphy driver. */
> if (NULL == d->driver) {
> - if (phydev->is_c45) {
> - pr_err("No driver for phy %x\n", phydev->phy_id);
> - return -ENODEV;
> - }
> -
> - d->driver = &genphy_driver.driver;
> + if (phydev->is_c45)
> + d->driver = &gen10g_driver.driver;
> + else
> + d->driver = &genphy_driver.driver;
>
> err = d->driver->probe(d);
> if (err >= 0)
> @@ -573,6 +569,7 @@ static int phy_attach_direct(struct net_device *dev,
> struct
> phy_device *phydev,
>
> return err;
> }
> +EXPORT_SYMBOL(phy_attach_direct);
>
> /**
> * phy_attach - attach a network device to a particular PHY device @@ -623,6
> +620,8 @@ void phy_detach(struct phy_device *phydev)
>* real driver could be loaded */
> if (phydev->dev.driver == &genphy_driver.driver)
> device_release_driver(&phydev->dev);
> + else if (phydev->dev.driver == &gen10g_driver.driver)
> + device_release_driver(&phydev->dev);
> }
> EXPORT_SYMBOL(phy_detach);
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h index f864004..f36a6f6
> 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -575,6 +575,8 @@ int phy_init_hw(struct phy_device *phydev); struct
> phy_device * phy_attach(struct net_device *dev,
> const char *bus_id, phy_interface_t interface); struct
> phy_device
> *phy_find_first(struct mii_bus *bus);
> +int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> + u32 flags, phy_interface_t interface);
> int phy_connect_direct(struct net_device *dev, struct phy_device *phydev,
> void (*handler)(struct net_device *),
> phy_interface_t interface);
> --
> 1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/4] phylib: Add of_phy_attach
Added more people and list.
Best Regards,
Shaohui Xie
> -Original Message-
> From: shh@gmail.com [mailto:shh@gmail.com]
> Sent: Monday, November 11, 2013 7:08 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
> Subject: [PATCH 4/4] phylib: Add of_phy_attach
>
> From: Andy Fleming
>
> 10G PHYs don't currently support running the state machine, which is
> implicitly
> setup via of_phy_connect(). Therefore, it is necessary to implement an OF
> version of phy_attach(), which does everything except start the state machine.
>
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie
> ---
> drivers/of/of_mdio.c| 22 --
> include/linux/of_mdio.h | 8
> 2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c index
> d5a57a9..a748274
> 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -221,8 +221,7 @@ EXPORT_SYMBOL(of_phy_connect);
> * not call this function from new drivers.
> */
> struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> - void (*hndlr)(struct net_device *),
> - phy_interface_t iface)
> + void (*hndlr)(struct net_device *), phy_interface_t iface)
> {
> struct device_node *net_np;
> char bus_id[MII_BUS_ID_SIZE + 3];
> @@ -247,3 +246,22 @@ struct phy_device *of_phy_connect_fixed_link(struct
> net_device *dev,
> return IS_ERR(phy) ? NULL : phy;
> }
> EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +/**
> + * of_phy_attach - Attach to a PHY without starting the state machine
> + * @dev: pointer to net_device claiming the phy
> + * @phy_np: Node pointer for the PHY
> + * @flags: flags to pass to the PHY
> + * @iface: PHY data interface type
> + */
> +struct phy_device *of_phy_attach(struct net_device *dev,
> + struct device_node *phy_np, u32 flags, phy_interface_t iface) {
> + struct phy_device *phy = of_phy_find_device(phy_np);
> +
> + if (!phy)
> + return NULL;
> +
> + return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy; }
> +EXPORT_SYMBOL(of_phy_attach);
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h index
> 8163107..dcda44d 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -19,6 +19,8 @@ extern struct phy_device *of_phy_connect(struct net_device
> *dev,
>struct device_node *phy_np,
>void (*hndlr)(struct net_device *),
>u32 flags, phy_interface_t iface);
> +extern struct phy_device *of_phy_attach(struct net_device *dev,
> + struct device_node *phy_np, u32 flags, phy_interface_t iface);
> extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
>void (*hndlr)(struct net_device *),
>phy_interface_t iface);
> @@ -44,6 +46,12 @@ static inline struct phy_device *of_phy_connect(struct
> net_device *dev,
> return NULL;
> }
>
> +static inline struct phy_device *of_phy_attach(struct net_device *dev,
> + struct device_node *phy_np, u32 flags, phy_interface_t iface) {
> + return NULL;
> +}
> +
> static inline struct phy_device *of_phy_connect_fixed_link(struct net_device
> *dev,
> void (*hndlr)(struct
> net_device
> *),
> phy_interface_t
> iface)
> --
> 1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/4] phylib: Add generic 10G driver
Added more people and list.
Best Regards,
Shaohui Xie
> -Original Message-
> From: shh@gmail.com [mailto:shh@gmail.com]
> Sent: Monday, November 11, 2013 7:07 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
> Subject: [PATCH 2/4] phylib: Add generic 10G driver
>
> From: Andy Fleming
>
> Very incomplete, but will allow for binding an ethernet controller to it.
>
> Also, Add XGMII interface type
>
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie
> ---
> drivers/net/phy/phy_device.c | 101
> ++-
> include/linux/phy.h | 1 +
> 2 files changed, 101 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index
> 74630e9..30bf2d5 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -689,6 +690,13 @@ static int genphy_config_advert(struct phy_device
> *phydev)
> return changed;
> }
>
> +int gen10g_config_advert(struct phy_device *dev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_advert);
> +
> +
> /**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> @@ -742,6 +750,12 @@ int genphy_restart_aneg(struct phy_device *phydev) }
> EXPORT_SYMBOL(genphy_restart_aneg);
>
> +int gen10g_restart_aneg(struct phy_device *phydev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_restart_aneg);
> +
>
> /**
> * genphy_config_aneg - restart auto-negotiation or write BMCR @@ -784,6
> +798,13 @@ int genphy_config_aneg(struct phy_device *phydev) }
> EXPORT_SYMBOL(genphy_config_aneg);
>
> +int gen10g_config_aneg(struct phy_device *phydev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_aneg);
> +
> +
> /**
> * genphy_update_link - update link status in @phydev
> * @phydev: target phy_device struct
> @@ -913,6 +934,35 @@ int genphy_read_status(struct phy_device *phydev) }
> EXPORT_SYMBOL(genphy_read_status);
>
> +int gen10g_read_status(struct phy_device *phydev) {
> + int devad, reg;
> + u32 mmd_mask = phydev->c45_ids.devices_in_package;
> +
> + phydev->link = 1;
> +
> + /* For now just lie and say it's 10G all the time */
> + phydev->speed = 1;
> + phydev->duplex = DUPLEX_FULL;
> +
> + for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
> + if (!(mmd_mask & 1))
> + continue;
> +
> + /* Read twice because link state is latched and a
> + * read moves the current state into the register
> + */
> + phy_read_mmd(phydev, devad, MDIO_STAT1);
> + reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
> + if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
> + phydev->link = 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_read_status);
> +
> +
> static int genphy_config_init(struct phy_device *phydev) {
> int val;
> @@ -959,6 +1009,15 @@ static int genphy_config_init(struct phy_device *phydev)
>
> return 0;
> }
> +
> +static int gen10g_config_init(struct phy_device *phydev) {
> + /* Temporarily just say we support everything */
> + phydev->supported = phydev->advertising = SUPPORTED_1baseT_Full;
> +
> + return 0;
> +}
> +
> int genphy_suspend(struct phy_device *phydev) {
> int value;
> @@ -974,6 +1033,13 @@ int genphy_suspend(struct phy_device *phydev) }
> EXPORT_SYMBOL(genphy_suspend);
>
> +int gen10g_suspend(struct phy_device *phydev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_suspend);
> +
> +
> int genphy_resume(struct phy_device *phydev) {
> int value;
> @@ -989,6 +1055,13 @@ int genphy_resume(struct phy_device *phydev) }
> EXPORT_SYMBOL(genphy_resume);
>
> +int gen10g_resume(struct phy_device *phydev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_resume);
> +
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1129,6 +1202,20 @@ static struct phy_driver genphy_driver = {
> .driver = {.owner= THIS_MODULE, },
> };
>
> +static struct phy_driver gen10g_driver = {
> + .phy_id = 0x,
> + .phy_id_mask= 0x,
> + .name = "Generic 10G PHY",
&g
RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
Added more people and list.
Best Regards,
Shaohui Xie
> -Original Message-
> From: shh@gmail.com [mailto:shh@gmail.com]
> Sent: Monday, November 11, 2013 7:04 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
> Subject: [PATCH 1/4] phylib: Add Clause 45 read/write functions
>
> From: Andy Fleming
>
> You need an extra parameter to read or write Clause 45 PHYs, so we need a
> different API with the extra parameter.
>
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie
> ---
> include/linux/phy.h | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h index 64ab823..684925a
> 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -498,6 +498,21 @@ static inline int phy_read(struct phy_device *phydev, u32
> regnum) }
>
> /**
> + * phy_read_mmd - Convenience function for reading a register
> + * from an MMD on a given PHY.
> + * @phydev: The phy_device struct
> + * @devad: The MMD to read from
> + * @regnum: The register on the MMD to read
> + *
> + * Same rules as for phy_read();
> + */
> +static inline int phy_read_mmd(struct phy_device *phydev, int devad,
> +u32 regnum) {
> + return mdiobus_read(phydev->bus, phydev->addr,
> + MII_ADDR_C45 | (devad << 16) | (regnum & 0x)); }
> +
> +/**
> * phy_write - Convenience function for writing a given PHY register
> * @phydev: the phy_device struct
> * @regnum: register number to write
> @@ -533,6 +548,24 @@ static inline bool phy_is_internal(struct phy_device
> *phydev)
> return phydev->is_internal;
> }
>
> +/**
> + * phy_write_mmd - Convenience function for writing a register
> + * on an MMD on a given PHY.
> + * @phydev: The phy_device struct
> + * @devad: The MMD to read from
> + * @regnum: The register on the MMD to read
> + * @val: value to write to @regnum
> + *
> + * Same rules as for phy_write();
> + */
> +static inline int phy_write_mmd(struct phy_device *phydev, int devad,
> + u32 regnum, u16 val)
> +{
> + regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0x);
> +
> + return mdiobus_write(phydev->bus, phydev->addr, regnum, val); }
> +
> struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int
> phy_id,
> bool is_c45, struct phy_c45_device_ids *c45_ids); struct
> phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
> --
> 1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/corenet/config: add missing SCSI configs for corenet64_smp_defconfig
Otherwise there will be no SCSI device nodes. Signed-off-by: Shaohui Xie --- arch/powerpc/configs/corenet64_smp_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 6c8b020..53058cb 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -92,6 +92,13 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=131072 CONFIG_EEPROM_LEGACY=y +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_ST=y +CONFIG_BLK_DEV_SR=y +CONFIG_CHR_DEV_SG=y +CONFIG_SCSI_MULTI_LUN=y +CONFIG_SCSI_LOGGING=y +CONFIG_SCSI_SPI_ATTRS=y CONFIG_ATA=y CONFIG_SATA_FSL=y CONFIG_SATA_SIL24=y -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/corenet/config: add missing SCSI configs for corenet64_smp_defconfig
Otherwise there will be no SCSI device nodes. Signed-off-by: Shaohui Xie --- resend due to patch work did not capture this patch. arch/powerpc/configs/corenet64_smp_defconfig |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 83dcc6a..2333e9b 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -77,6 +77,13 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=131072 CONFIG_EEPROM_LEGACY=y +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_ST=y +CONFIG_BLK_DEV_SR=y +CONFIG_CHR_DEV_SG=y +CONFIG_SCSI_MULTI_LUN=y +CONFIG_SCSI_LOGGING=y +CONFIG_SCSI_SPI_ATTRS=y CONFIG_ATA=y CONFIG_SATA_FSL=y CONFIG_SATA_SIL24=y -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/corenet/config: add missing SCSI configs for corenet64_smp_defconfig
Otherwise there will be no SCSI device nodes. Signed-off-by: Shaohui Xie --- arch/powerpc/configs/corenet64_smp_defconfig |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 83dcc6a..2333e9b 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -77,6 +77,13 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=131072 CONFIG_EEPROM_LEGACY=y +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_ST=y +CONFIG_BLK_DEV_SR=y +CONFIG_CHR_DEV_SG=y +CONFIG_SCSI_MULTI_LUN=y +CONFIG_SCSI_LOGGING=y +CONFIG_SCSI_SPI_ATTRS=y CONFIG_ATA=y CONFIG_SATA_FSL=y CONFIG_SATA_SIL24=y -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/p1023/config: enable hugetlbfs support
Hugetlbfs is missed in current p1023rds_defconfig, enable it by default. Signed-off-by: Shaohui Xie --- arch/powerpc/configs/85xx/p1023rds_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/85xx/p1023rds_defconfig b/arch/powerpc/configs/85xx/p1023rds_defconfig index b80bcc6..98125b0 100644 --- a/arch/powerpc/configs/85xx/p1023rds_defconfig +++ b/arch/powerpc/configs/85xx/p1023rds_defconfig @@ -1,4 +1,5 @@ CONFIG_PPC_85xx=y +CONFIG_PHYS_64BIT=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_EXPERIMENTAL=y @@ -138,6 +139,7 @@ CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y +CONFIG_HUGETLBFS=y CONFIG_ADFS_FS=m CONFIG_AFFS_FS=m CONFIG_HFS_FS=m -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] edac/85xx: fix error handle of mpc85xx_mc_err_probe
Error handle in case of DDR ECC off is wrong, sysfs entries have not been
created, so edac_mc_free which frees a mci instance should not be called.
Also, free mci's memory in this case.
Signed-off-by: Shaohui Xie
---
drivers/edac/edac_core.h|1 +
drivers/edac/edac_mc.c | 53 --
drivers/edac/mpc85xx_edac.c | 14 +++
3 files changed, 45 insertions(+), 23 deletions(-)
diff --git a/drivers/edac/edac_core.h b/drivers/edac/edac_core.h
index 23bb99f..108c4e2 100644
--- a/drivers/edac/edac_core.h
+++ b/drivers/edac/edac_core.h
@@ -448,6 +448,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
unsigned sz_pvt);
extern int edac_mc_add_mc(struct mem_ctl_info *mci);
extern void edac_mc_free(struct mem_ctl_info *mci);
+extern void edac_mc_free_mem(struct mem_ctl_info *mci);
extern struct mem_ctl_info *edac_mc_find(int idx);
extern struct mem_ctl_info *find_mci_by_dev(struct device *dev);
extern struct mem_ctl_info *edac_mc_del_mc(struct device *dev);
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index 616d90b..a2488b2 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -199,6 +199,40 @@ void *edac_align_ptr(void **p, unsigned size, int n_elems)
return (void *)(((unsigned long)ptr) + align - r);
}
+/*
+ * edac_mc_free_mem
+ * 'Free' a previously allocated 'mci' memory
+ * @mci: pointer to a struct mem_ctl_info structure
+ */
+void edac_mc_free_mem(struct mem_ctl_info *mci)
+{
+ int i = 0, tot_dimms, chn, tot_channels;
+ struct csrow_info *csr;
+
+ tot_dimms = mci->tot_dimms;
+ tot_channels = mci->num_cschannel;
+
+ if (mci->dimms) {
+ for (i = 0; i < tot_dimms; i++)
+ kfree(mci->dimms[i]);
+ kfree(mci->dimms);
+ }
+ if (mci->csrows) {
+ for (chn = 0; chn < tot_channels; chn++) {
+ csr = mci->csrows[chn];
+ if (csr) {
+ for (chn = 0; chn < tot_channels; chn++)
+ kfree(csr->channels[chn]);
+ kfree(csr);
+ }
+ kfree(mci->csrows[i]);
+ }
+ kfree(mci->csrows);
+ }
+ kfree(mci);
+}
+EXPORT_SYMBOL_GPL(edac_mc_free_mem);
+
/**
* edac_mc_alloc: Allocate and partially fill a struct mem_ctl_info structure
* @mc_num:Memory controller number
@@ -413,24 +447,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
return mci;
error:
- if (mci->dimms) {
- for (i = 0; i < tot_dimms; i++)
- kfree(mci->dimms[i]);
- kfree(mci->dimms);
- }
- if (mci->csrows) {
- for (chn = 0; chn < tot_channels; chn++) {
- csr = mci->csrows[chn];
- if (csr) {
- for (chn = 0; chn < tot_channels; chn++)
- kfree(csr->channels[chn]);
- kfree(csr);
- }
- kfree(mci->csrows[i]);
- }
- kfree(mci->csrows);
- }
- kfree(mci);
+ edac_mc_free_mem(mci);
return NULL;
}
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index a1e791e..402b3f5 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -1012,7 +1012,7 @@ static int __devinit mpc85xx_mc_err_probe(struct
platform_device *op)
if (res) {
printk(KERN_ERR "%s: Unable to get resource for MC err regs\n",
__func__);
- goto err;
+ goto err1;
}
if (!devm_request_mem_region(&op->dev, r.start, resource_size(&r),
@@ -1020,14 +1020,14 @@ static int __devinit mpc85xx_mc_err_probe(struct
platform_device *op)
printk(KERN_ERR "%s: Error while requesting mem region\n",
__func__);
res = -EBUSY;
- goto err;
+ goto err1;
}
pdata->mc_vbase = devm_ioremap(&op->dev, r.start, resource_size(&r));
if (!pdata->mc_vbase) {
printk(KERN_ERR "%s: Unable to setup MC err regs\n", __func__);
res = -ENOMEM;
- goto err;
+ goto err1;
}
sdram_ctl = in_be32(pdata->mc_vbase + MPC85XX_MC_DDR_SDRAM_CFG);
@@ -1035,7 +1035,7 @@ static int __devinit mpc85xx_mc_err_probe(struct
platform_device *op)
/* no ECC */
printk(KERN_WARNING "%s: No ECC DIMMs discovered\n", __func__);
res = -ENODEV;
-
[PATCH] powerpc/p5040: fix dtb build warning of p5040ds.dtb
Device node adt7461 was wrongly added in p5040ds.dts, it should be added
into i2c instead of localbus, when build p5040ds.dtb, a warning will dump:
Warning (reg_format): "reg" property in
/localbus@ffe124000/nand@2,0/adt7461@4c has invalid length (4 bytes)
(#address-cells == 1, #size-cells == 1)
This was introduced by:
commit ea6b1ba692bcb5f6e39f409a78cf8b04fdf23baa
Author: Jia Hongtao
Date: Tue Aug 28 10:00:55 2012 +0800
powerpc: add adt7461 thermal monitor support to applicable boards
Add thermal monitor support to following boards:
P1022DS, MPC8536DS, P2041RDB, P3041DS, P4080DS, P5020DS, P5040DS
Signed-off-by: Shaohui Xie
---
based on next branch of
http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p5040ds.dts |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/p5040ds.dts
b/arch/powerpc/boot/dts/p5040ds.dts
index 8165c93..860b5cc 100644
--- a/arch/powerpc/boot/dts/p5040ds.dts
+++ b/arch/powerpc/boot/dts/p5040ds.dts
@@ -95,6 +95,10 @@
reg = <0x68>;
interrupts = <0x1 0x1 0 0>;
};
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
};
};
@@ -146,10 +150,6 @@
label = "NAND Writable User area";
reg = <0x1f00 0x0100>;
};
- adt7461@4c {
- compatible = "adi,adt7461";
- reg = <0x4c>;
- };
};
board-control@3,0 {
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v4] sata_fsl: add workaround for data length mismatch on freescale V2 controller
The freescale V2 SATA controller checks if the received data length matches
the programmed length 'ttl', if not, it assumes that this is an error.
In ATAPI, the 'ttl' is based on max allocation length and not the actual
data transfer length, controller will raise 'DLM' (Data length Mismatch)
error bit in Hstatus register. Along with 'DLM', DE (Device error) and
FE (fatal Error) bits are also set in Hstatus register, 'E' (Internal Error)
bit is set in Serror register and CE (Command Error) and DE (Device error)
registers have the corresponding bit set. In this condition, we need to
clear errors in following way: in the service routine, based on 'DLM' flag,
HCONTROL[27] operation clears Hstatus, CE and DE registers, clear Serror
register.
Signed-off-by: Shaohui Xie
Signed-off-by: Anju Bhartiya
---
changes for v4:
1. put HCONTROL_CLEAR_ERROR to enum and rename it as CLEAR_ERROR;
changes for v3:
1. not using uppercase for variable names;
2. remove unnecessary parens;
changes for v2:
1. remove the using of quirk;
2. wrap errata codes in condition;
drivers/ata/sata_fsl.c | 39 +++
1 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..124b2c1 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -123,6 +123,7 @@ enum {
ONLINE = (1 << 31),
GOING_OFFLINE = (1 << 30),
BIST_ERR = (1 << 29),
+ CLEAR_ERROR = (1 << 27),
FATAL_ERR_HC_MASTER_ERR = (1 << 18),
FATAL_ERR_PARITY_ERR_TX = (1 << 17),
@@ -143,6 +144,7 @@ enum {
FATAL_ERR_CRC_ERR_RX |
FATAL_ERR_FIFO_OVRFL_TX | FATAL_ERR_FIFO_OVRFL_RX,
+ INT_ON_DATA_LENGTH_MISMATCH = (1 << 12),
INT_ON_FATAL_ERR = (1 << 5),
INT_ON_PHYRDY_CHG = (1 << 4),
@@ -1181,25 +1183,54 @@ static void sata_fsl_host_intr(struct ata_port *ap)
u32 hstatus, done_mask = 0;
struct ata_queued_cmd *qc;
u32 SError;
+ u32 tag;
+ u32 status_mask = INT_ON_ERROR;
hstatus = ioread32(hcr_base + HSTATUS);
sata_fsl_scr_read(&ap->link, SCR_ERROR, &SError);
+ /* Read command completed register */
+ done_mask = ioread32(hcr_base + CC);
+
+ /* Workaround for data length mismatch errata */
+ if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) {
+ for (tag = 0; tag < ATA_MAX_QUEUE; tag++) {
+ qc = ata_qc_from_tag(ap, tag);
+ if (qc && ata_is_atapi(qc->tf.protocol)) {
+ u32 hcontrol;
+ /* Set HControl[27] to clear error registers */
+ hcontrol = ioread32(hcr_base + HCONTROL);
+ iowrite32(hcontrol | CLEAR_ERROR,
+ hcr_base + HCONTROL);
+
+ /* Clear HControl[27] */
+ iowrite32(hcontrol & ~CLEAR_ERROR,
+ hcr_base + HCONTROL);
+
+ /* Clear SError[E] bit */
+ sata_fsl_scr_write(&ap->link, SCR_ERROR,
+ SError);
+
+ /* Ignore fatal error and device error */
+ status_mask &= ~(INT_ON_SINGL_DEVICE_ERR
+ | INT_ON_FATAL_ERR);
+ break;
+ }
+ }
+ }
+
if (unlikely(SError & 0x)) {
DPRINTK("serror @host_intr : 0x%x\n", SError);
sata_fsl_error_intr(ap);
}
- if (unlikely(hstatus & INT_ON_ERROR)) {
+ if (unlikely(hstatus & status_mask)) {
DPRINTK("error interrupt!!\n");
sata_fsl_error_intr(ap);
return;
}
- /* Read command completed register */
- done_mask = ioread32(hcr_base + CC);
-
VPRINTK("Status of all queues :\n");
VPRINTK("done_mask/CC = 0x%x, CA = 0x%x, CE=0x%x,CQ=0x%x,apqa=0x%x\n",
done_mask,
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v3] sata_fsl: add workaround for data length mismatch on freescale V2 controller
The freescale V2 SATA controller checks if the received data length matches
the programmed length 'ttl', if not, it assumes that this is an error.
In ATAPI, the 'ttl' is based on max allocation length and not the actual
data transfer length, controller will raise 'DLM' (Data length Mismatch)
error bit in Hstatus register. Along with 'DLM', DE (Device error) and
FE (fatal Error) bits are also set in Hstatus register, 'E' (Internal Error)
bit is set in Serror register and CE (Command Error) and DE (Device error)
registers have the corresponding bit set. In this condition, we need to
clear errors in following way: in the service routine, based on 'DLM' flag,
HCONTROL[27] operation clears Hstatus, CE and DE registers, clear Serror
register.
Signed-off-by: Shaohui Xie
Signed-off-by: Anju Bhartiya
---
changes for v3:
1. not using uppercase for variable names;
2. remove unnecessary parens;
changes for v2:
1. remove the using of quirk;
2. wrap errata codes in condition;
drivers/ata/sata_fsl.c | 39 +++
1 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..9fbab68 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -143,6 +143,7 @@ enum {
FATAL_ERR_CRC_ERR_RX |
FATAL_ERR_FIFO_OVRFL_TX | FATAL_ERR_FIFO_OVRFL_RX,
+ INT_ON_DATA_LENGTH_MISMATCH = (1 << 12),
INT_ON_FATAL_ERR = (1 << 5),
INT_ON_PHYRDY_CHG = (1 << 4),
@@ -1181,25 +1182,55 @@ static void sata_fsl_host_intr(struct ata_port *ap)
u32 hstatus, done_mask = 0;
struct ata_queued_cmd *qc;
u32 SError;
+ u32 tag;
+ u32 status_mask = INT_ON_ERROR;
hstatus = ioread32(hcr_base + HSTATUS);
sata_fsl_scr_read(&ap->link, SCR_ERROR, &SError);
+ /* Read command completed register */
+ done_mask = ioread32(hcr_base + CC);
+
+ /* Workaround for data length mismatch errata */
+ if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) {
+ for (tag = 0; tag < ATA_MAX_QUEUE; tag++) {
+ qc = ata_qc_from_tag(ap, tag);
+ if (qc && ata_is_atapi(qc->tf.protocol)) {
+ u32 hcontrol;
+#define HCONTROL_CLEAR_ERROR (1 << 27)
+ /* Set HControl[27] to clear error registers */
+ hcontrol = ioread32(hcr_base + HCONTROL);
+ iowrite32(hcontrol | HCONTROL_CLEAR_ERROR,
+ hcr_base + HCONTROL);
+
+ /* Clear HControl[27] */
+ iowrite32(hcontrol & ~HCONTROL_CLEAR_ERROR,
+ hcr_base + HCONTROL);
+
+ /* Clear SError[E] bit */
+ sata_fsl_scr_write(&ap->link, SCR_ERROR,
+ SError);
+
+ /* Ignore fatal error and device error */
+ status_mask &= ~(INT_ON_SINGL_DEVICE_ERR
+ | INT_ON_FATAL_ERR);
+ break;
+ }
+ }
+ }
+
if (unlikely(SError & 0x)) {
DPRINTK("serror @host_intr : 0x%x\n", SError);
sata_fsl_error_intr(ap);
}
- if (unlikely(hstatus & INT_ON_ERROR)) {
+ if (unlikely(hstatus & status_mask)) {
DPRINTK("error interrupt!!\n");
sata_fsl_error_intr(ap);
return;
}
- /* Read command completed register */
- done_mask = ioread32(hcr_base + CC);
-
VPRINTK("Status of all queues :\n");
VPRINTK("done_mask/CC = 0x%x, CA = 0x%x, CE=0x%x,CQ=0x%x,apqa=0x%x\n",
done_mask,
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [v2] sata_fsl: add workaround for data length mismatch on freescale V2 controller
The freescale V2 SATA controller checks if the received data length matches
the programmed length 'ttl', if not, it assumes that this is an error.
In ATAPI, the 'ttl' is based on max allocation length and not the actual
data transfer length, controller will raise 'DLM' (Data length Mismatch)
error bit in Hstatus register. Along with 'DLM', DE (Device error) and
FE (fatal Error) bits are also set in Hstatus register, 'E' (Internal Error)
bit is set in Serror register and CE (Command Error) and DE (Device error)
registers have the corresponding bit set. In this condition, we need to
clear errors in following way: in the service routine, based on 'DLM' flag,
HCONTROL[27] operation clears Hstatus, CE and DE registers, clear Serror
register.
Signed-off-by: Shaohui Xie
Signed-off-by: Anju Bhartiya
---
changes for V2:
1. remove the using of quirk;
2. wrap errata codes in condition;
drivers/ata/sata_fsl.c | 40 +++-
1 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..6b7b73e 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -143,6 +143,7 @@ enum {
FATAL_ERR_CRC_ERR_RX |
FATAL_ERR_FIFO_OVRFL_TX | FATAL_ERR_FIFO_OVRFL_RX,
+ INT_ON_DATA_LENGTH_MISMATCH = (1 << 12),
INT_ON_FATAL_ERR = (1 << 5),
INT_ON_PHYRDY_CHG = (1 << 4),
@@ -1180,26 +1181,55 @@ static void sata_fsl_host_intr(struct ata_port *ap)
void __iomem *hcr_base = host_priv->hcr_base;
u32 hstatus, done_mask = 0;
struct ata_queued_cmd *qc;
- u32 SError;
+ u32 SError, tag;
+ u32 status_mask = INT_ON_ERROR;
hstatus = ioread32(hcr_base + HSTATUS);
sata_fsl_scr_read(&ap->link, SCR_ERROR, &SError);
+ /* Read command completed register */
+ done_mask = ioread32(hcr_base + CC);
+
+ /* Workaround for data length mismatch errata */
+ if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) {
+ for (tag = 0; tag < ATA_MAX_QUEUE; tag++) {
+ qc = ata_qc_from_tag(ap, tag);
+ if (qc && ata_is_atapi(qc->tf.protocol)) {
+ u32 Hcontrol;
+#define HCONTROL_CLEAR_ERROR (1 << 27)
+ /* Set HControl[27] to clear error registers */
+ Hcontrol = ioread32(hcr_base + HCONTROL);
+ iowrite32(Hcontrol | HCONTROL_CLEAR_ERROR,
+ hcr_base + HCONTROL);
+
+ /* Clear HControl[27] */
+ iowrite32(Hcontrol & (~HCONTROL_CLEAR_ERROR),
+ hcr_base + HCONTROL);
+
+ /* Clear SError[E] bit */
+ sata_fsl_scr_write(&ap->link, SCR_ERROR,
+ SError);
+
+ /* Ignore fatal error and device error */
+ status_mask &= ~(INT_ON_SINGL_DEVICE_ERR
+ | INT_ON_FATAL_ERR);
+ break;
+ }
+ }
+ }
+
if (unlikely(SError & 0x)) {
DPRINTK("serror @host_intr : 0x%x\n", SError);
sata_fsl_error_intr(ap);
}
- if (unlikely(hstatus & INT_ON_ERROR)) {
+ if (unlikely(hstatus & status_mask)) {
DPRINTK("error interrupt!!\n");
sata_fsl_error_intr(ap);
return;
}
- /* Read command completed register */
- done_mask = ioread32(hcr_base + CC);
-
VPRINTK("Status of all queues :\n");
VPRINTK("done_mask/CC = 0x%x, CA = 0x%x, CE=0x%x,CQ=0x%x,apqa=0x%x\n",
done_mask,
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] sata_fsl: add workaround for data length mismatch on freescale V2 controller
The freescale V2 SATA controller checks if the received data length matches
the programmed length 'ttl', if not, it assumes that this is an error.
In ATAPI, the 'ttl' is based on max allocation length and not the actual
data transfer length, controller will raise 'DLM' (Data length Mismatch)
error bit in Hstatus register. Along with 'DLM', DE (Device error) and
FE (fatal Error) bits are also set in Hstatus register, 'E' (Internal Error)
bit is set in Serror register and CE (Command Error) and DE (Device error)
registers have the corresponding bit set. In this condition, we need to
clear errors in following way: in the service routine, based on 'DLM' flag,
HCONTROL[27] operation clears Hstatus, CE and DE registers, clear Serror
register.
Signed-off-by: Shaohui Xie
Signed-off-by: Anju Bhartiya
---
drivers/ata/sata_fsl.c | 48 +++-
1 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..00a00cc 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -143,6 +143,7 @@ enum {
FATAL_ERR_CRC_ERR_RX |
FATAL_ERR_FIFO_OVRFL_TX | FATAL_ERR_FIFO_OVRFL_RX,
+ INT_ON_DATA_LENGTH_MISMATCH = (1 << 12),
INT_ON_FATAL_ERR = (1 << 5),
INT_ON_PHYRDY_CHG = (1 << 4),
@@ -283,6 +284,8 @@ struct sata_fsl_host_priv {
int irq;
int data_snoop;
struct device_attribute intr_coalescing;
+ u32 quirks;
+#define SATA_FSL_QUIRK_V2_ERRATA(1 << 1)
};
static void fsl_sata_set_irq_coalescing(struct ata_host *host,
@@ -1180,26 +1183,58 @@ static void sata_fsl_host_intr(struct ata_port *ap)
void __iomem *hcr_base = host_priv->hcr_base;
u32 hstatus, done_mask = 0;
struct ata_queued_cmd *qc;
- u32 SError;
+ u32 SError, tag, atapi_flag = 0;
+ u32 status_mask = INT_ON_ERROR;
hstatus = ioread32(hcr_base + HSTATUS);
sata_fsl_scr_read(&ap->link, SCR_ERROR, &SError);
+ /* Read command completed register */
+ done_mask = ioread32(hcr_base + CC);
+
+ if (host_priv->quirks & SATA_FSL_QUIRK_V2_ERRATA) {
+ if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) {
+ for (tag = 0; tag < ATA_MAX_QUEUE; tag++) {
+ qc = ata_qc_from_tag(ap, tag);
+ if (qc && ata_is_atapi(qc->tf.protocol)) {
+ atapi_flag = 1;
+ break;
+ }
+ }
+ }
+ }
+
+ /* Workaround for data length mismatch errata */
+ if (atapi_flag) {
+ u32 Hcontrol;
+#define HCONTROL_CLEAR_ERROR (1 << 27)
+ /* Set HControl[27] to clear error registers */
+ Hcontrol = ioread32(hcr_base + HCONTROL);
+ iowrite32(Hcontrol | HCONTROL_CLEAR_ERROR, hcr_base + HCONTROL);
+
+ /* Clear HControl[27] */
+ iowrite32(Hcontrol & (~HCONTROL_CLEAR_ERROR),
+ hcr_base + HCONTROL);
+
+ /* Clear SError[E] bit */
+ sata_fsl_scr_write(&ap->link, SCR_ERROR, SError);
+
+ /* Ignore fatal error and device error */
+ status_mask &= ~(INT_ON_SINGL_DEVICE_ERR | INT_ON_FATAL_ERR);
+ }
+
if (unlikely(SError & 0x)) {
DPRINTK("serror @host_intr : 0x%x\n", SError);
sata_fsl_error_intr(ap);
}
- if (unlikely(hstatus & INT_ON_ERROR)) {
+ if (unlikely(hstatus & status_mask)) {
DPRINTK("error interrupt!!\n");
sata_fsl_error_intr(ap);
return;
}
- /* Read command completed register */
- done_mask = ioread32(hcr_base + CC);
-
VPRINTK("Status of all queues :\n");
VPRINTK("done_mask/CC = 0x%x, CA = 0x%x, CE=0x%x,CQ=0x%x,apqa=0x%x\n",
done_mask,
@@ -1437,6 +1472,9 @@ static int sata_fsl_probe(struct platform_device *ofdev)
else
host_priv->data_snoop = DATA_SNOOP_ENABLE_V1;
+ if (of_device_is_compatible(ofdev->dev.of_node, "fsl,pq-sata-v2"))
+ host_priv->quirks |= SATA_FSL_QUIRK_V2_ERRATA;
+
/* allocate host structure */
host = ata_host_alloc_pinfo(&ofdev->dev, ppi, SATA_FSL_MAX_PORTS);
if (!host) {
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel
PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so all the
memory will be put into this zone. If the memory size is greater than
the device's DMA capability and device uses dma_alloc_coherent to allocate
memory, it will get an address which is over the device's DMA addressing,
the device will fail.
So we split the memory to two zones: zone ZONE_DMA32 & ZONE_NORMAL, since
we already allocate PCICSRBAR/PEXCSRBAR right below the 4G boundary (if the
lowest PCI address is above 4G), so we constrain the DMA zone ZONE_DMA32
to 2GB, also, we clear flag __GFP_DMA & __GFP_DMA32 and set __GFP_DMA32 only
if the device's dma_mask < total memory size. By doing this, devices which
cannot DMA all the memory will be limited to ZONE_DMA32, but devices which
can DMA all the memory will not be affected by this limitation.
Signed-off-by: Shaohui Xie
Signed-off-by: Mingkai Hu
Signed-off-by: Chen Yuanquan
---
changes for v2:
1. use a config option for using two zones (ZONE_DMA32 & ZONE_NORMAL) in
freescale 64 bit kernel.
arch/powerpc/Kconfig |3 +++
arch/powerpc/kernel/dma.c | 15 +++
arch/powerpc/mm/mem.c |4
3 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 352f416..a96fbbb 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -629,6 +629,9 @@ config ZONE_DMA
bool
default y
+config ZONE_DMA32
+ def_bool (PPC64 && PPC_FSL_BOOK3E)
+
config NEED_DMA_MAP_STATE
def_bool (PPC64 || NOT_COHERENT_CACHE)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 355b9d8..cbf5ac1 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -41,9 +41,24 @@ void *dma_direct_alloc_coherent(struct device *dev, size_t
size,
#else
struct page *page;
int node = dev_to_node(dev);
+#ifdef CONFIG_ZONE_DMA32
+ phys_addr_t top_ram_pfn = memblock_end_of_DRAM();
+ /*
+* check for crappy device which has dma_mask < ZONE_DMA, and
+* we are not going to support it, just warn and fail.
+*/
+ if (*dev->dma_mask < DMA_BIT_MASK(31)) {
+ dev_err(dev, "Unsupported dma_mask 0x%llx\n", *dev->dma_mask);
+ return NULL;
+ }
/* ignore region specifiers */
+ flag &= ~(__GFP_HIGHMEM | __GFP_DMA | __GFP_DMA32);
+ if (*dev->dma_mask < top_ram_pfn - 1)
+ flag |= __GFP_DMA32;
+#else
flag &= ~(__GFP_HIGHMEM);
+#endif
page = alloc_pages_node(node, flag, get_order(size));
if (page == NULL)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index baaafde..2a11e49 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -280,6 +280,10 @@ void __init paging_init(void)
#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
max_zone_pfns[ZONE_HIGHMEM] = top_of_ram >> PAGE_SHIFT;
+#elif defined CONFIG_ZONE_DMA32
+ max_zone_pfns[ZONE_DMA32] = min_t(phys_addr_t, top_of_ram,
+ 1ull << 31) >> PAGE_SHIFT;
+ max_zone_pfns[ZONE_NORMAL] = top_of_ram >> PAGE_SHIFT;
#else
max_zone_pfns[ZONE_DMA] = top_of_ram >> PAGE_SHIFT;
#endif
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so all the
memory will be put into this zone. If the memory size is greater than
the device's DMA capability and device uses dma_alloc_coherent to allocate
memory, it will get an address which is over the device's DMA addressing,
the device will fail.
So we split the memory to two zones by adding a zone ZONE_NORMAL, since
we already allocate PCICSRBAR/PEXCSRBAR right below the 4G boundary (if the
lowest PCI address is above 4G), so we constrain the DMA zone ZONE_DMA
to 2GB, also, we clear the flag __GFP_DMA and set it only if the device's
dma_mask < total memory size. By doing this, devices which cannot DMA all
the memory will be limited to ZONE_DMA, but devices which can DMA all the
memory will not be affected by this limitation.
Signed-off-by: Shaohui Xie
Signed-off-by: Mingkai Hu
Signed-off-by: Chen Yuanquan
---
arch/powerpc/kernel/dma.c | 13 -
arch/powerpc/mm/mem.c |4 +++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index b1ec983..8029295 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -30,6 +30,7 @@ void *dma_direct_alloc_coherent(struct device *dev, size_t
size,
struct dma_attrs *attrs)
{
void *ret;
+ phys_addr_t top_ram_pfn = memblock_end_of_DRAM();
#ifdef CONFIG_NOT_COHERENT_CACHE
ret = __dma_alloc_coherent(dev, size, dma_handle, flag);
if (ret == NULL)
@@ -40,8 +41,18 @@ void *dma_direct_alloc_coherent(struct device *dev, size_t
size,
struct page *page;
int node = dev_to_node(dev);
+ /*
+* check for crappy device which has dma_mask < ZONE_DMA, and
+* we are not going to support it, just warn and fail.
+*/
+ if (*dev->dma_mask < DMA_BIT_MASK(31)) {
+ dev_err(dev, "Unsupported dma_mask 0x%llx\n", *dev->dma_mask);
+ return NULL;
+ }
/* ignore region specifiers */
- flag &= ~(__GFP_HIGHMEM);
+ flag &= ~(__GFP_HIGHMEM | __GFP_DMA);
+ if (*dev->dma_mask < top_ram_pfn - 1)
+ flag |= GFP_DMA;
page = alloc_pages_node(node, flag, get_order(size));
if (page == NULL)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index baaafde..a494555 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -281,7 +281,9 @@ void __init paging_init(void)
max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
max_zone_pfns[ZONE_HIGHMEM] = top_of_ram >> PAGE_SHIFT;
#else
- max_zone_pfns[ZONE_DMA] = top_of_ram >> PAGE_SHIFT;
+ max_zone_pfns[ZONE_DMA] = min_t(phys_addr_t, top_of_ram,
+ 1ull << 31) >> PAGE_SHIFT;
+ max_zone_pfns[ZONE_NORMAL] = top_of_ram >> PAGE_SHIFT;
#endif
free_area_init_nodes(max_zone_pfns);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/p3041: change espi input-clock from 40MHz to 35MHz
Default CCB on P3041 is 750MHz, but espi cannot work at 40MHz with this CCB,
so we need to slow down the clock rate of espi to 35MHz to make it work stable
with the CCB.
Signed-off-by: Shaohui Xie
---
arch/powerpc/boot/dts/p3041ds.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/p3041ds.dts
b/arch/powerpc/boot/dts/p3041ds.dts
index 22a215e..6cdcadc 100644
--- a/arch/powerpc/boot/dts/p3041ds.dts
+++ b/arch/powerpc/boot/dts/p3041ds.dts
@@ -58,7 +58,7 @@
#size-cells = <1>;
compatible = "spansion,s25sl12801";
reg = <0>;
- spi-max-frequency = <4000>; /* input clock
*/
+ spi-max-frequency = <3500>; /* input clock
*/
partition@u-boot {
label = "u-boot";
reg = <0x 0x0010>;
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v2] powerpc/watchdog: move booke watchdog param related code to setup-common.c
Currently, BOOKE watchdog code for checking "wdt" and "wdt_period" is
in setup_32.c, it cannot be used in 64-bit, so move it to a common place
setup-common.c, which will be shared by 32-bit and 64-bit.
Also, replace the simple_strtoul with kstrtol.
Signed-off-by: Shaohui Xie
---
changes for v2:
use setup-common.c instead of prom.c
arch/powerpc/kernel/setup-common.c | 27 +++
arch/powerpc/kernel/setup_32.c | 24
2 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index afd4f05..bdc499c 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -720,6 +720,33 @@ static int powerpc_debugfs_init(void)
arch_initcall(powerpc_debugfs_init);
#endif
+#ifdef CONFIG_BOOKE_WDT
+extern u32 booke_wdt_enabled;
+extern u32 booke_wdt_period;
+
+/* Checks wdt=x and wdt_period=xx command-line option */
+notrace int __init early_parse_wdt(char *p)
+{
+ if (p && strncmp(p, "0", 1) != 0)
+ booke_wdt_enabled = 1;
+
+ return 0;
+}
+early_param("wdt", early_parse_wdt);
+
+int __init early_parse_wdt_period(char *p)
+{
+ unsigned long ret;
+ if (p) {
+ if (!kstrtol(p, 0, &ret))
+ booke_wdt_period = ret;
+ }
+
+ return 0;
+}
+early_param("wdt_period", early_parse_wdt_period);
+#endif /* CONFIG_BOOKE_WDT */
+
void ppc_printk_progress(char *s, unsigned short hex)
{
pr_info("%s\n", s);
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index ec8a53f..a8f54ec 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -149,30 +149,6 @@ notrace void __init machine_init(u64 dt_ptr)
ppc_md.progress("id mach(): done", 0x200);
}
-#ifdef CONFIG_BOOKE_WDT
-extern u32 booke_wdt_enabled;
-extern u32 booke_wdt_period;
-
-/* Checks wdt=x and wdt_period=xx command-line option */
-notrace int __init early_parse_wdt(char *p)
-{
- if (p && strncmp(p, "0", 1) != 0)
- booke_wdt_enabled = 1;
-
- return 0;
-}
-early_param("wdt", early_parse_wdt);
-
-int __init early_parse_wdt_period (char *p)
-{
- if (p)
- booke_wdt_period = simple_strtoul(p, NULL, 0);
-
- return 0;
-}
-early_param("wdt_period", early_parse_wdt_period);
-#endif /* CONFIG_BOOKE_WDT */
-
/* Checks "l2cr=" command-line option */
int __init ppc_setup_l2cr(char *str)
{
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/p2041rdb: add NAND node in device tree
NAND on p2041 uses CS1 as chip select.
Signed-off-by: Shaohui Xie
---
arch/powerpc/boot/dts/p2041rdb.dts | 41 +++-
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/p2041rdb.dts
b/arch/powerpc/boot/dts/p2041rdb.dts
index 2852139..baab034 100644
--- a/arch/powerpc/boot/dts/p2041rdb.dts
+++ b/arch/powerpc/boot/dts/p2041rdb.dts
@@ -121,7 +121,8 @@
lbc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x1000>;
- ranges = <0 0 0xf 0xe800 0x0800>;
+ ranges = <0 0 0xf 0xe800 0x0800
+ 1 0 0xf 0xffa0 0x0004>;
flash@0,0 {
compatible = "cfi-flash";
@@ -129,6 +130,44 @@
bank-width = <2>;
device-width = <2>;
};
+
+ nand@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x1 0x0 0x4>;
+
+ partition@0 {
+ label = "NAND U-Boot Image";
+ reg = <0x0 0x0200>;
+ read-only;
+ };
+
+ partition@200 {
+ label = "NAND Root File System";
+ reg = <0x0200 0x1000>;
+ };
+
+ partition@1200 {
+ label = "NAND Compressed RFS Image";
+ reg = <0x1200 0x0800>;
+ };
+
+ partition@1a00 {
+ label = "NAND Linux Kernel Image";
+ reg = <0x1a00 0x0400>;
+ };
+
+ partition@1e00 {
+ label = "NAND DTB Image";
+ reg = <0x1e00 0x0100>;
+ };
+
+ partition@1f00 {
+ label = "NAND Writable User area";
+ reg = <0x1f00 0x0100>;
+ };
+ };
};
pci0: pcie@ffe20 {
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2][v2] powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_PPC_FSL_BOOK3E
CONFIG_FSL_BOOKE is only defined in 32-bit, CONFIG_PPC_FSL_BOOK3E is defined in both 32-bit and 64-bit, so use CONFIG_PPC_FSL_BOOK3E to make driver work in 32-bit & 64-bit. Signed-off-by: Shaohui Xie --- changes for v2: use PPC_FSL_BOOK3E instead of FSL_SOC_BOOKE. drivers/watchdog/Kconfig |8 drivers/watchdog/booke_wdt.c |4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 3709624..4373ca0 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1094,10 +1094,10 @@ config BOOKE_WDT config BOOKE_WDT_DEFAULT_TIMEOUT int "PowerPC Book-E Watchdog Timer Default Timeout" depends on BOOKE_WDT - default 38 if FSL_BOOKE - range 0 63 if FSL_BOOKE - default 3 if !FSL_BOOKE - range 0 3 if !FSL_BOOKE + default 38 if PPC_FSL_BOOK3E + range 0 63 if PPC_FSL_BOOK3E + default 3 if !PPC_FSL_BOOK3E + range 0 3 if !PPC_FSL_BOOK3E help Select the default watchdog timer period to be used by the PowerPC Book-E watchdog driver. A watchdog "event" occurs when the bit diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c index ce0ab44..338a437 100644 --- a/drivers/watchdog/booke_wdt.c +++ b/drivers/watchdog/booke_wdt.c @@ -37,7 +37,7 @@ u32 booke_wdt_enabled; u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT; -#ifdef CONFIG_FSL_BOOKE +#ifdef CONFIG_PPC_FSL_BOOK3E #define WDTP(x)x)&0x3)<<30)|(((x)&0x3c)<<15)) #define WDTP_MASK (WDTP(0x3f)) #else @@ -190,7 +190,7 @@ static long booke_wdt_ioctl(struct file *file, case WDIOC_SETTIMEOUT: if (get_user(tmp, p)) return -EFAULT; -#ifdef CONFIG_FSL_BOOKE +#ifdef CONFIG_PPC_FSL_BOOK3E /* period of 1 gives the largest possible timeout */ if (tmp > period_to_sec(1)) return -EINVAL; -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_FSL_SOC_BOOKE
CONFIG_FSL_BOOKE is only defined in 32-bit, CONFIG_FSL_SOC_BOOKE is defined in both 32-bit and 64-bit, so use CONFIG_FSL_SOC_BOOKE to make diver work in 32-bit & 64-bit. Signed-off-by: Shaohui Xie --- drivers/watchdog/Kconfig |8 drivers/watchdog/booke_wdt.c |4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 3709624..4373ca0 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1094,10 +1094,10 @@ config BOOKE_WDT config BOOKE_WDT_DEFAULT_TIMEOUT int "PowerPC Book-E Watchdog Timer Default Timeout" depends on BOOKE_WDT - default 38 if FSL_BOOKE - range 0 63 if FSL_BOOKE - default 3 if !FSL_BOOKE - range 0 3 if !FSL_BOOKE + default 38 if FSL_SOC_BOOKE + range 0 63 if FSL_SOC_BOOKE + default 3 if !FSL_SOC_BOOKE + range 0 3 if !FSL_SOC_BOOKE help Select the default watchdog timer period to be used by the PowerPC Book-E watchdog driver. A watchdog "event" occurs when the bit diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c index ce0ab44..338a437 100644 --- a/drivers/watchdog/booke_wdt.c +++ b/drivers/watchdog/booke_wdt.c @@ -37,7 +37,7 @@ u32 booke_wdt_enabled; u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT; -#ifdef CONFIG_FSL_BOOKE +#ifdef CONFIG_FSL_SOC_BOOKE #define WDTP(x)x)&0x3)<<30)|(((x)&0x3c)<<15)) #define WDTP_MASK (WDTP(0x3f)) #else @@ -190,7 +190,7 @@ static long booke_wdt_ioctl(struct file *file, case WDIOC_SETTIMEOUT: if (get_user(tmp, p)) return -EFAULT; -#ifdef CONFIG_FSL_BOOKE +#ifdef CONFIG_FSL_SOC_BOOKE /* period of 1 gives the largest possible timeout */ if (tmp > period_to_sec(1)) return -EINVAL; -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/watchdog: move booke watchdog param related code to prom.c
Currently, BOOKE watchdog code for checking "wdt" and "wdt_period" is
in setup_32.c, it cannot be used in 64-bit, so move it to a common place
prom.c, which will be shared by 32-bit and 64-bit.
Also, replace the simple_strtoul with kstrtol.
Signed-off-by: Shaohui Xie
---
arch/powerpc/kernel/prom.c | 27 +++
arch/powerpc/kernel/setup_32.c | 24
2 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index f191bf0..49e1bdf 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -84,6 +84,33 @@ static int __init early_parse_mem(char *p)
}
early_param("mem", early_parse_mem);
+#ifdef CONFIG_BOOKE_WDT
+extern u32 booke_wdt_enabled;
+extern u32 booke_wdt_period;
+
+/* Checks wdt=x and wdt_period=xx command-line option */
+notrace int __init early_parse_wdt(char *p)
+{
+ if (p && strncmp(p, "0", 1) != 0)
+ booke_wdt_enabled = 1;
+
+ return 0;
+}
+early_param("wdt", early_parse_wdt);
+
+int __init early_parse_wdt_period(char *p)
+{
+ unsigned long ret;
+ if (p) {
+ if (!kstrtol(p, 0, &ret))
+ booke_wdt_period = ret;
+ }
+
+ return 0;
+}
+early_param("wdt_period", early_parse_wdt_period);
+#endif /* CONFIG_BOOKE_WDT */
+
/*
* overlaps_initrd - check for overlap with page aligned extension of
* initrd.
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index ec8a53f..a8f54ec 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -149,30 +149,6 @@ notrace void __init machine_init(u64 dt_ptr)
ppc_md.progress("id mach(): done", 0x200);
}
-#ifdef CONFIG_BOOKE_WDT
-extern u32 booke_wdt_enabled;
-extern u32 booke_wdt_period;
-
-/* Checks wdt=x and wdt_period=xx command-line option */
-notrace int __init early_parse_wdt(char *p)
-{
- if (p && strncmp(p, "0", 1) != 0)
- booke_wdt_enabled = 1;
-
- return 0;
-}
-early_param("wdt", early_parse_wdt);
-
-int __init early_parse_wdt_period (char *p)
-{
- if (p)
- booke_wdt_period = simple_strtoul(p, NULL, 0);
-
- return 0;
-}
-early_param("wdt_period", early_parse_wdt_period);
-#endif /* CONFIG_BOOKE_WDT */
-
/* Checks "l2cr=" command-line option */
int __init ppc_setup_l2cr(char *str)
{
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v2] mmc:sdhci: restore the enabled dma when do reset all
If dma is enabled, it'll be cleared when reset all is performed, this can
be observed on some platforms, such as P2041 which has a version 2.3
controller, but platform like P4080 which has a version 2.2 controller,
does not suffer this, so we will check if the dma is enabled, we should
restore it after reset all.
Signed-off-by: Shaohui Xie
---
based on http://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git,
branch 'for-linus'.
changes for v2:
call the wrapper API instead of access the register directly.
drivers/mmc/host/sdhci.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 19ed580..cf6a048 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -214,6 +214,11 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
+
+ if (host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA)) {
+ if ((host->ops->enable_dma) && (mask & SDHCI_RESET_ALL))
+ host->ops->enable_dma(host);
+ }
}
static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mmc:sdhci: restore the enabled dma when do reset all
If dma is enabled, it'll be cleared when reset all is performed, this can
be observed on some platforms, such as P2041 which has a version 2.3
controller, but platform like P4080 which has a version 2.2 controller,
does not suffer this, so we will check if the dma is enabled, we should
restore it after reset all.
Signed-off-by: Shaohui Xie
---
based on http://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git,
branch 'for-linus'.
drivers/mmc/host/sdhci.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 19ed580..22033c3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -29,6 +29,7 @@
#include
#include "sdhci.h"
+#include "sdhci-esdhc.h"
#define DRIVER_NAME "sdhci"
@@ -176,6 +177,7 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
{
unsigned long timeout;
u32 uninitialized_var(ier);
+ u32 uninitialized_var(dma);
if (host->quirks & SDHCI_QUIRK_NO_CARD_NO_RESET) {
if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
@@ -189,6 +191,8 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
if (host->ops->platform_reset_enter)
host->ops->platform_reset_enter(host, mask);
+ dma = sdhci_readl(host, ESDHC_DMA_SYSCTL);
+
sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);
if (mask & SDHCI_RESET_ALL)
@@ -214,6 +218,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
+
+ if ((dma & ESDHC_DMA_SNOOP) && (mask & SDHCI_RESET_ALL))
+ sdhci_writel(host, dma, ESDHC_DMA_SYSCTL);
}
static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v2] powerpc/usb: fix type cast for address of ioremap to compatible with 64-bit
Below are codes for accessing usb sysif_regs in driver: usb_sys_regs = (struct usb_sys_interface *) ((u32)dr_regs + USB_DR_SYS_OFFSET); these codes work in 32-bit, but in 64-bit, use u32 to type cast the address of ioremap is not right, and accessing members of 'usb_sys_regs' will cause call trace, so use (void *) for both 32-bit and 64-bit. Signed-off-by: Shaohui Xie --- changes for v2: 1. use (void *) instead of unsigned long and the double cast according to Timur's comment. drivers/usb/gadget/fsl_udc_core.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c index c81fbad..398c5e6 100644 --- a/drivers/usb/gadget/fsl_udc_core.c +++ b/drivers/usb/gadget/fsl_udc_core.c @@ -2497,8 +2497,7 @@ static int __init fsl_udc_probe(struct platform_device *pdev) #ifndef CONFIG_ARCH_MXC if (pdata->have_sysif_regs) - usb_sys_regs = (struct usb_sys_interface *) - ((u32)dr_regs + USB_DR_SYS_OFFSET); + usb_sys_regs = (void *)dr_regs + USB_DR_SYS_OFFSET; #endif /* Initialize USB clocks */ -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/usb: use unsigned long to type cast an address of ioremap
Below are codes for accessing usb sysif_regs in driver: usb_sys_regs = (struct usb_sys_interface *) ((u32)dr_regs + USB_DR_SYS_OFFSET); these codes work in 32-bit, but in 64-bit, use u32 to type cast the address of ioremap is not right, and accessing members of 'usb_sys_regs' will cause call trace, so use unsigned long for both 32-bit and 64-bit. Signed-off-by: Shaohui Xie --- drivers/usb/gadget/fsl_udc_core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c index c81fbad..581b7cc 100644 --- a/drivers/usb/gadget/fsl_udc_core.c +++ b/drivers/usb/gadget/fsl_udc_core.c @@ -2498,7 +2498,7 @@ static int __init fsl_udc_probe(struct platform_device *pdev) #ifndef CONFIG_ARCH_MXC if (pdata->have_sysif_regs) usb_sys_regs = (struct usb_sys_interface *) - ((u32)dr_regs + USB_DR_SYS_OFFSET); + ((unsigned long)dr_regs + USB_DR_SYS_OFFSET); #endif /* Initialize USB clocks */ -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/usb: use ioremap instead of base plus offset to access regs
Below are codes for accessing usb sysif_regs in driver:
usb_sys_regs = (struct usb_sys_interface *)
((u32)dr_regs + USB_DR_SYS_OFFSET);
these codes work in 32-bit, but in 64-bit, accessing members of 'usb_sys_regs'
will cause call trace like below:
Unable to handle kernel paging request for data at address 0x8817a500
Faulting instruction address: 0x8011bae8
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2 P5020 DS
Modules linked in: fsl_usb2_udc(+)
NIP: 8011bae8 LR: 8011efb8 CTR: c00ef500
REGS: c000f3e2f350 TRAP: 0300 Not tainted (3.0.6-1-g0700776)
MSR: 80029000 CR: 24000222 XER:
DEAR: 8817a500, ESR:
TASK = c000fb3b8840[3466] 'insmod' THREAD: c000f3e2c000 CPU: 1
GPR00: 0002 c000f3e2f5d0 801286b8 c000fb2e7c00
GPR04: 00d0 c000f8b026c0 0041
GPR08: 8817a400 c7653d28
GPR12: 8011f3a8 c400
GPR16: 7ff9eee4
GPR20: 100e2645 0001
GPR24: c000f8b72c10 801208e8 c000fb2e7c00
GPR28: c000fb2e7c00 80128198 801208e8
NIP [8011bae8] .dr_controller_setup+0x318/0x360 [fsl_usb2_udc]
LR [8011efb8] .fsl_udc_probe+0x3b4/0x630 [fsl_usb2_udc]
Call Trace:
[c000f3e2f5d0] [c000f3e2f660] 0xc000f3e2f660 (unreliable)
[c000f3e2f660] [8011efb8] .fsl_udc_probe+0x3b4/0x630 [fsl_usb2_udc]
[c000f3e2f730] [c02f2960] .platform_drv_probe+0x30/0x50
[c000f3e2f7a0] [c02f0df0] .driver_probe_device+0xe0/0x230
[c000f3e2f840] [c02f104c] .__driver_attach+0x10c/0x110
[c000f3e2f8d0] [c02ef83c] .bus_for_each_dev+0x7c/0xd0
[c000f3e2f970] [c02f08c8] .driver_attach+0x28/0x40
[c000f3e2f9f0] [c02f02c0] .bus_add_driver+0xd0/0x310
[c000f3e2faa0] [c02f15dc] .driver_register+0x9c/0x1a0
[c000f3e2fb40] [c02f2dc0] .platform_driver_register+0x60/0x80
[c000f3e2fbc0] [c02f2e14] .platform_driver_probe+0x34/0xf0
[c000f3e2fc50] [8011f26c] .udc_init+0x38/0x894 [fsl_usb2_udc]
[c000f3e2fcd0] [ceb0] .do_one_initcall+0x60/0x1e0
[c000f3e2fd90] [c008a7b0] .SyS_init_module+0xd0/0x220
[c000f3e2fe30] [c5a0] syscall_exit+0x0/0x2c
Instruction dump:
eba1ffe8 ebc1fff0 ebe1fff8 7c0803a6 4e800020 6529c000 793c0020 4bfffdac
65291000 793c0020 e93f0010 7c0004ac
0c00 4c00012c 6204
---[ end trace d152129396f60c53 ]---
Signed-off-by: Shaohui Xie
---
drivers/usb/gadget/fsl_udc_core.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index c81fbad..c656d2c 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -263,9 +263,11 @@ static int dr_controller_setup(struct fsl_udc *udc)
/* fall through */
case FSL_USB2_PHY_UTMI:
#ifdef CONFIG_FSL_SOC_BOOKE
+ if (udc->pdata->have_sysif_regs) {
setbits32(&usb_sys_regs->control, USB_CTRL_UTMI_PHY_EN |
USB_CTRL_USB_EN);
udelay(10*1000); /* delay for PHY clk to ready */
+ }
#endif
portctrl |= PORTSCX_PTS_UTMI;
break;
@@ -986,7 +988,7 @@ static int fsl_ep_dequeue(struct usb_ep *_ep, struct
usb_request *_req)
queue);
/* Point the QH to the first TD of next request */
- fsl_writel((u32) next_req->head, &qh->curr_dtd_ptr);
+ fsl_writel(*(u32 *) next_req->head, &qh->curr_dtd_ptr);
}
/* The request hasn't been processed, patch up the TD chain */
@@ -2497,8 +2499,8 @@ static int __init fsl_udc_probe(struct platform_device
*pdev)
#ifndef CONFIG_ARCH_MXC
if (pdata->have_sysif_regs)
- usb_sys_regs = (struct usb_sys_interface *)
- ((u32)dr_regs + USB_DR_SYS_OFFSET);
+ usb_sys_regs = ioremap(res->start + USB_DR_SYS_OFFSET,
+ sizeof(struct usb_sys_interface)/sizeof(int));
#endif
/* Initialize USB clocks */
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mtd: m25p80: don't probe device which has status of 'disabled'
On some platforms such as P3060QDS, has multiple spi flashes, but they are not available at same time, so if their status is 'disabled', which is set by u-boot, will not be probed. Signed-off-by: Shaohui Xie --- Disabled nodes should automatically not be probed. But I found this is only true for spi node, for the flash nodes which embedded in spi node, still got probed even it has a status of 'disabled'. drivers/mtd/devices/m25p80.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index 4e20c4d..30d61d5 100644 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include @@ -829,6 +830,11 @@ static int __devinit m25p_probe(struct spi_device *spi) struct mtd_partition*parts = NULL; int nr_parts = 0; +#ifdef CONFIG_MTD_OF_PARTS + if (!of_device_is_available(spi->dev.of_node)) + return -ENODEV; +#endif + /* Platform data helps sort out which chip type we have, as * well as how this board partitions it. If we don't have * a chip ID, try the JEDEC id commands; they'll work for most -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mtd: m25p80: add EON flash EN25Q32B into spi flash id table
Add support for EON spi flash EN25Q32B, which is not listed in id table,
need to add it in the id table to support the EON flash.
Signed-off-by: Shaohui Xie
Signed-off-by: Kumar Gala
---
drivers/mtd/devices/m25p80.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 35180e4..4e20c4d 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -671,6 +671,7 @@ static const struct spi_device_id m25p_ids[] = {
/* EON -- en25xxx */
{ "en25f32", INFO(0x1c3116, 0, 64 * 1024, 64, SECT_4K) },
{ "en25p32", INFO(0x1c2016, 0, 64 * 1024, 64, 0) },
+ { "en25q32b", INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
{ "en25p64", INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
/* Intel/Numonyx -- xxxs33b */
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: fix memory controller compatible for edac
compatible in dts has been changed, so driver need to update accordingly.
Signed-off-by: Shaohui Xie
---
apply for http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
'next' branch.
drivers/edac/mpc85xx_edac.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 13f6cc5..94c064a 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -1253,7 +1253,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = "fsl,p1020-memory-controller", },
{ .compatible = "fsl,p1021-memory-controller", },
{ .compatible = "fsl,p2020-memory-controller", },
- { .compatible = "fsl,p4080-memory-controller", },
+ { .compatible = "fsl,qoriq-memory-controller", },
{},
};
MODULE_DEVICE_TABLE(of, mpc85xx_mc_err_of_match);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] edac/85xx: PCI/PCIE error interrupt edac support.
From: Kai.Jiang
Add pcie error interrupt edac support for mpc85xx and p4080.
mpc85xx uses the legacy interrupt report mechanism - the error
interrupts are reported directly to mpic. While, p4080 attaches
most of error interrupts to interrupt 0. And report error interrupt
to mpic via interrupt 0. This patch can handle both of them.
Due to the error management register offset and definition
difference between pci and pcie, use ccsr_pci structure to merge
pci and pcie edac code into one.
Signed-off-by: Kai.Jiang
Signed-off-by: Kumar Gala
Signed-off-by: Shaohui Xie
---
drivers/edac/mpc85xx_edac.c | 239 --
drivers/edac/mpc85xx_edac.h | 17 +--
2 files changed, 188 insertions(+), 68 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index b048a5f..dde156f 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -1,5 +1,6 @@
/*
* Freescale MPC85xx Memory Controller kenel module
+ * Copyright (c) 2011 Freescale Semiconductor, Inc.
*
* Author: Dave Jiang
*
@@ -21,6 +22,8 @@
#include
#include
+#include
+#include
#include "edac_module.h"
#include "edac_core.h"
#include "mpc85xx_edac.h"
@@ -34,14 +37,6 @@ static int edac_mc_idx;
static u32 orig_ddr_err_disable;
static u32 orig_ddr_err_sbe;
-/*
- * PCI Err defines
- */
-#ifdef CONFIG_PCI
-static u32 orig_pci_err_cap_dr;
-static u32 orig_pci_err_en;
-#endif
-
static u32 orig_l2_err_disable;
#ifdef CONFIG_FSL_SOC_BOOKE
static u32 orig_hid1[2];
@@ -151,37 +146,52 @@ static void mpc85xx_pci_check(struct edac_pci_ctl_info
*pci)
{
struct mpc85xx_pci_pdata *pdata = pci->pvt_info;
u32 err_detect;
+ struct ccsr_pci *reg = pdata->pci_reg;
+
+ err_detect = in_be32(&pdata->pci_reg->pex_err_dr);
+
+ if (pdata->pcie_flag) {
+ printk(KERN_ERR "PCIE error(s) detected\n");
+ printk(KERN_ERR "PCIE ERR_DR register: 0x%08x\n", err_detect);
+ printk(KERN_ERR "PCIE ERR_CAP_STAT register: 0x%08x\n",
+ in_be32(®->pex_err_cap_stat));
+ printk(KERN_ERR "PCIE ERR_CAP_R0 register: 0x%08x\n",
+ in_be32(®->pex_err_cap_r0));
+ printk(KERN_ERR "PCIE ERR_CAP_R1 register: 0x%08x\n",
+ in_be32(®->pex_err_cap_r1));
+ printk(KERN_ERR "PCIE ERR_CAP_R2 register: 0x%08x\n",
+ in_be32(®->pex_err_cap_r2));
+ printk(KERN_ERR "PCIE ERR_CAP_R3 register: 0x%08x\n",
+ in_be32(®->pex_err_cap_r3));
+ } else {
+ /* master aborts can happen during PCI config cycles */
+ if (!(err_detect & ~(PCI_EDE_MULTI_ERR | PCI_EDE_MST_ABRT))) {
+ out_be32(®->pex_err_dr, err_detect);
+ return;
+ }
- err_detect = in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR);
-
- /* master aborts can happen during PCI config cycles */
- if (!(err_detect & ~(PCI_EDE_MULTI_ERR | PCI_EDE_MST_ABRT))) {
- out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR, err_detect);
- return;
+ printk(KERN_ERR "PCI error(s) detected\n");
+ printk(KERN_ERR "PCI/X ERR_DR register: 0x%08x\n", err_detect);
+ printk(KERN_ERR "PCI/X ERR_ATTRIB register: 0x%08x\n",
+ in_be32(®->pex_err_attrib));
+ printk(KERN_ERR "PCI/X ERR_ADDR register: 0x%08x\n",
+ in_be32(®->pex_err_disr));
+ printk(KERN_ERR "PCI/X ERR_EXT_ADDR register: 0x%08x\n",
+ in_be32(®->pex_err_ext_addr));
+ printk(KERN_ERR "PCI/X ERR_DL register: 0x%08x\n",
+ in_be32(®->pex_err_dl));
+ printk(KERN_ERR "PCI/X ERR_DH register: 0x%08x\n",
+ in_be32(®->pex_err_dh));
+
+ if (err_detect & PCI_EDE_PERR_MASK)
+ edac_pci_handle_pe(pci, pci->ctl_name);
+
+ if ((err_detect & ~PCI_EDE_MULTI_ERR) & ~PCI_EDE_PERR_MASK)
+ edac_pci_handle_npe(pci, pci->ctl_name);
}
- printk(KERN_ERR "PCI error(s) detected\n");
- printk(KERN_ERR "PCI/X ERR_DR register: %#08x\n", err_detect);
-
- printk(KERN_ERR "PCI/X ERR_ATTRIB register: %#08x\n",
- in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_ATTRIB));
- printk(KERN_ERR "PCI/X ERR_ADDR register: %#08x\n",
- in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_ADDR));
- printk(KERN_ERR "PCI/X ERR_EXT_ADDR register: %#08x\n",
- in_be32(pdata->
[PATCH 3/4] powerpc/85xx: Merge PCI/PCI Express error management registers
From: Kai.Jiang
There are some differences of register offset and definition between
pci and pcie error management registers. While, some other pci/pcie
error management registers are nearly the same.
Signed-off-by: Kai.Jiang
Signed-off-by: Kumar Gala
Signed-off-by: Shaohui Xie
---
arch/powerpc/sysdev/fsl_pci.h | 31 +--
1 files changed, 25 insertions(+), 6 deletions(-)
difg --gite a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index a39ed5c..60a76e9 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -74,13 +74,32 @@ struct ccsr_pci {
*/
struct pci_inbound_window_regs piw[4];
+/* Merge PCI/PCI Express error management registers */
__be32 pex_err_dr; /* 0x.e00 - PCI/PCIE error detect
register */
- u8 res21[4];
- __be32 pex_err_en; /* 0x.e08 - PCI/PCIE error interrupt
enable register */
- u8 res22[4];
- __be32 pex_err_disr; /* 0x.e10 - PCI/PCIE error disable
register */
- u8 res23[12];
- __be32 pex_err_cap_stat; /* 0x.e20 - PCI/PCIE error capture
status register */
+ __be32 pex_err_cap_dr; /* 0x.e04 */
+ /* - PCI error capture disabled
register */
+ /* - PCIE has no this register */
+ __be32 pex_err_en; /* 0x.e08 */
+ /* - PCI/PCIE error interrupt enable
register*/
+ __be32 pex_err_attrib; /* 0x.e0c */
+ /* - PCI error attributes capture
register */
+ /* - PCIE has no this register */
+ __be32 pex_err_disr; /* 0x.e10 */
+ /* - PCI error address capture register
*/
+ /* - PCIE error disable register */
+ __be32 pex_err_ext_addr; /* 0x.e14 */
+ /* - PCI error extended addr capture
register*/
+ /* - PCIE has no this register */
+ __be32 pex_err_dl; /* 0x.e18 */
+ /* - PCI error data low capture
register */
+ /* - PCIE has no this register */
+ __be32 pex_err_dh; /* 0x.e1c */
+ /* - PCI error data high capture
register */
+ /* - PCIE has no this register */
+ __be32 pex_err_cap_stat; /* 0x.e20 */
+ /* - PCI gasket timer register */
+ /* - PCIE error capture status register
*/
+
u8 res24[4];
__be32 pex_err_cap_r0; /* 0x.e28 - PCIE error capture register
0 */
__be32 pex_err_cap_r1; /* 0x.e2c - PCIE error capture register
0 */
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] powerpc/85xx: enable pcie initialization for P4080
Signed-off-by: Shaohui Xie
---
arch/powerpc/platforms/85xx/corenet_ds.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
b/arch/powerpc/platforms/85xx/corenet_ds.c
index 2ab338c..15247b0 100644
--- a/arch/powerpc/platforms/85xx/corenet_ds.c
+++ b/arch/powerpc/platforms/85xx/corenet_ds.c
@@ -114,6 +114,9 @@ static const struct of_device_id of_device_ids[]
__devinitconst = {
.compatible = "simple-bus"
},
{
+ .compatible = "fsl,p4080-pcie"
+ },
+ {
.compatible = "fsl,rapidio-delta",
},
{}
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] powerpc/85xx: fix interrupt number of memory-controller for P4080
Signed-off-by: Shaohui Xie
---
arch/powerpc/boot/dts/p4080ds.dts |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/p4080ds.dts
b/arch/powerpc/boot/dts/p4080ds.dts
index 927f94d..9c37a85 100644
--- a/arch/powerpc/boot/dts/p4080ds.dts
+++ b/arch/powerpc/boot/dts/p4080ds.dts
@@ -131,14 +131,14 @@
compatible = "fsl,p4080-memory-controller";
reg = <0x8000 0x1000>;
interrupt-parent = <&mpic>;
- interrupts = <0x12 2>;
+ interrupts = <16 2>;
};
memory-controller@9000 {
compatible = "fsl,p4080-memory-controller";
reg = <0x9000 0x1000>;
interrupt-parent = <&mpic>;
- interrupts = <0x12 2>;
+ interrupts = <16 2>;
};
corenet-cf@18000 {
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Correct offset_in_page mask bits in function edac_mc_handle_ce.
From: Kai.Jiang Parameter offset_in_page in function edac_mc_handle_ce should be masked the higher bits above the page size, not the lower bits. The original input sometimes causes crash. Signed-off-by: Kai.Jiang --- drivers/edac/mpc85xx_edac.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c index 38ab8e2..b048a5f 100644 --- a/drivers/edac/mpc85xx_edac.c +++ b/drivers/edac/mpc85xx_edac.c @@ -854,11 +854,11 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci) mpc85xx_mc_printk(mci, KERN_ERR, "PFN out of range!\n"); if (err_detect & DDR_EDE_SBE) - edac_mc_handle_ce(mci, pfn, err_addr & PAGE_MASK, + edac_mc_handle_ce(mci, pfn, err_addr & ~PAGE_MASK, syndrome, row_index, 0, mci->ctl_name); if (err_detect & DDR_EDE_MBE) - edac_mc_handle_ue(mci, pfn, err_addr & PAGE_MASK, + edac_mc_handle_ue(mci, pfn, err_addr & ~PAGE_MASK, row_index, mci->ctl_name); out_be32(pdata->mc_vbase + MPC85XX_MC_ERR_DETECT, err_detect); -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: fix NAND_CMD_READID read bytes number
when nand_get_flash_type() is called, it will read 8 bytes of ID instead of 5, but the driver only read 5 bytes, so kernel will dump error messages like: fsl-lbc ffe124000.localbus: read_byte beyond end of buffer fsl-lbc ffe124000.localbus: read_byte beyond end of buffer fsl-lbc ffe124000.localbus: read_byte beyond end of buffer Signed-off-by: Shaohui Xie Acked-by: Scott Wood --- drivers/mtd/nand/fsl_elbc_nand.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index 0bb254c..33d8aad 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -339,9 +339,9 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command, (FIR_OP_UA << FIR_OP1_SHIFT) | (FIR_OP_RBW << FIR_OP2_SHIFT)); out_be32(&lbc->fcr, NAND_CMD_READID << FCR_CMD0_SHIFT); - /* 5 bytes for manuf, device and exts */ - out_be32(&lbc->fbcr, 5); - elbc_fcm_ctrl->read_bytes = 5; + /* nand_get_flash_type() reads 8 bytes of entire ID string */ + out_be32(&lbc->fbcr, 8); + elbc_fcm_ctrl->read_bytes = 8; elbc_fcm_ctrl->use_mdr = 1; elbc_fcm_ctrl->mdr = 0; -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: fix race bug of calling request_irq after enable elbc interrupts
Signed-off-by: Shaohui Xie Signed-off-by: Kumar Gala --- arch/powerpc/sysdev/fsl_lbc.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c index e0292c3..9e7cb19 100644 --- a/arch/powerpc/sysdev/fsl_lbc.c +++ b/arch/powerpc/sysdev/fsl_lbc.c @@ -200,9 +200,6 @@ static int __devinit fsl_lbc_ctrl_init(struct fsl_lbc_ctrl *ctrl, out_be32(&lbc->lteccr, LTECCR_CLEAR); out_be32(&lbc->ltedr, LTEDR_ENABLE); - /* Enable interrupts for any detected events */ - out_be32(&lbc->lteir, LTEIR_ENABLE); - /* Set the monitor timeout value to the maximum for erratum A001 */ if (of_device_is_compatible(node, "fsl,elbc")) clrsetbits_be32(&lbc->lbcr, LBCR_BMT, LBCR_BMTPS); @@ -340,6 +337,9 @@ static int __devinit fsl_lbc_ctrl_probe(struct of_device *ofdev, goto err; } + /* Enable interrupts for any detected events */ + out_be32(&fsl_lbc_ctrl_dev->regs->lteir, LTEIR_ENABLE); + return 0; err: -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2][v3] rapidio, powerpc/85xx: Error interrupt handler for sRIO.
The sRIO controller reports errors to the core with one signal, it uses
register EPWISR to provides the core quick access to where the error occurred.
The EPWISR indicates that there are 4 interrupts sources, port1, port2, message
unit and port write receive, but the sRIO driver does not support port2
for now, still the handler takes care of port2.
Currently the handler only clear error status without any recovery.
Signed-off-by: Shaohui Xie
Cc: Li Yang
Cc: Kumar Gala
Cc: Roy Zang
Cc: Alexandre Bounine
---
updated to 37-rc2
arch/powerpc/sysdev/fsl_rio.c | 85 +
1 files changed, 77 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index ddbcd16..d036df9 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -10,7 +10,7 @@
* - Added Port-Write message handling
* - Added Machine Check exception handling
*
- * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc.
+ * Copyright (C) 2007, 2008, 2010 Freescale Semiconductor, Inc.
* Zhang Wei
*
* Copyright 2005 MontaVista Software, Inc.
@@ -47,15 +47,33 @@
#define IRQ_RIO_RX(m) (((struct rio_priv *)(m->priv))->rxirq)
#define IRQ_RIO_PW(m) (((struct rio_priv *)(m->priv))->pwirq)
+#define IPWSR_CLEAR0x98
+#define OMSR_CLEAR 0x1cb3
+#define IMSR_CLEAR 0x491
+#define IDSR_CLEAR 0x91
+#define ODSR_CLEAR 0x1c00
+#define LTLEECSR_ENABLE_ALL0xFFC000FC
+#define ESCSR_CLEAR0x07120204
+
+#define RIO_PORT1_EDCSR0x0640
+#define RIO_PORT2_EDCSR0x0680
+#define RIO_PORT1_IECSR0x10130
+#define RIO_PORT2_IECSR0x101B0
+#define RIO_IM0SR 0x13064
+#define RIO_IM1SR 0x13164
+#define RIO_OM0SR 0x13004
+#define RIO_OM1SR 0x13104
+
#define RIO_ATMU_REGS_OFFSET 0x10c00
#define RIO_P_MSG_REGS_OFFSET 0x11000
#define RIO_S_MSG_REGS_OFFSET 0x13000
#define RIO_GCCSR 0x13c
#define RIO_ESCSR 0x158
+#define RIO_PORT2_ESCSR0x178
#define RIO_CCSR 0x15c
#define RIO_LTLEDCSR 0x0608
-#define RIO_LTLEDCSR_IER 0x8000
-#define RIO_LTLEDCSR_PRT 0x0100
+#define RIO_LTLEDCSR_IER 0x8000
+#define RIO_LTLEDCSR_PRT 0x0100
#define RIO_LTLEECSR 0x060c
#define RIO_EPWISR 0x10010
#define RIO_ISR_AACR 0x10120
@@ -88,7 +106,10 @@
#define RIO_IPWSR_PWD 0x0008
#define RIO_IPWSR_PWB 0x0004
-#define RIO_EPWISR_PINT0x8000
+/* EPWISR Error match value */
+#define RIO_EPWISR_PINT1 0x8000
+#define RIO_EPWISR_PINT2 0x4000
+#define RIO_EPWISR_MU 0x0002
#define RIO_EPWISR_PW 0x0001
#define RIO_MSG_DESC_SIZE 32
@@ -1066,6 +1087,40 @@ static int fsl_rio_doorbell_init(struct rio_mport *mport)
return rc;
}
+static void port_error_handler(struct rio_mport *port, int offset)
+{
+ /*XXX: Error recovery is not implemented, we just clear errors */
+ out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
+
+ if (offset == 0) {
+ out_be32((u32 *)(rio_regs_win + RIO_PORT1_EDCSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_PORT1_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_ESCSR), ESCSR_CLEAR);
+ } else {
+ out_be32((u32 *)(rio_regs_win + RIO_PORT2_EDCSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_PORT2_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_PORT2_ESCSR), ESCSR_CLEAR);
+ }
+}
+
+static void msg_unit_error_handler(struct rio_mport *port)
+{
+ struct rio_priv *priv = port->priv;
+
+ /*XXX: Error recovery is not implemented, we just clear errors */
+ out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
+
+ out_be32((u32 *)(rio_regs_win + RIO_IM0SR), IMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_IM1SR), IMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_OM0SR), OMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_OM1SR), OMSR_CLEAR);
+
+ out_be32(&priv->msg_regs->odsr, ODSR_CLEAR);
+ out_be32(&priv->msg_regs->dsr, IDSR_CLEAR);
+
+ out_be32(&priv->msg_regs->pwsr, IPWSR_CLEAR);
+}
+
/**
* fsl_rio_port_write_handler - MPC85xx port write interrupt handler
* @irq: Linux interrupt number
@@ -1146,10 +1201,22 @@ fsl_rio_port_write_handler(int irq, void *dev_instance)
}
pw_done:
- if (epwisr & RIO_EPWISR_PINT) {
+ if (epwisr & RIO_EPWISR_PINT1) {
+ tmp = in_be32(priv->regs_win + RIO_LTLEDCSR);
+ pr_debug("RIO_LTLEDCSR = 0x%x\n", tmp);
+ port_error_handler(port, 0);
+ }
+
+ if (epwisr & RIO_EPWIS
[PATCH 1/2][v4] fsl_rio: move machine_check handler into machine_check_e500 & machine_check_e500mc
Signed-off-by: Shaohui Xie
Cc: Li Yang
Cc: Kumar Gala
Cc: Roy Zang
Cc: Alexandre Bounine
---
arch/powerpc/include/asm/rio.h |5 +
arch/powerpc/kernel/traps.c| 13 +
arch/powerpc/sysdev/fsl_rio.c | 15 +++
3 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/rio.h b/arch/powerpc/include/asm/rio.h
index 0018bf8..d902abd 100644
--- a/arch/powerpc/include/asm/rio.h
+++ b/arch/powerpc/include/asm/rio.h
@@ -14,5 +14,10 @@
#define ASM_PPC_RIO_H
extern void platform_rio_init(void);
+#ifdef CONFIG_RAPIDIO
+extern int fsl_rio_mcheck_exception(struct pt_regs *);
+#else
+static inline int fsl_rio_mcheck_exception(struct pt_regs *regs) {return 0; }
+#endif
#endif /* ASM_PPC_RIO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 1b2cdc8..5f6c106 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -55,6 +55,7 @@
#endif
#include
#include
+#include
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -425,6 +426,12 @@ int machine_check_e500mc(struct pt_regs *regs)
unsigned long reason = mcsr;
int recoverable = 1;
+ if (reason & MCSR_BUS_RBERR) {
+ recoverable = fsl_rio_mcheck_exception(regs);
+ if (recoverable == 1)
+ goto silent_out;
+ }
+
printk("Machine check in kernel mode.\n");
printk("Caused by (from MCSR=%lx): ", reason);
@@ -500,6 +507,7 @@ int machine_check_e500mc(struct pt_regs *regs)
reason & MCSR_MEA ? "Effective" : "Physical", addr);
}
+silent_out:
mtspr(SPRN_MCSR, mcsr);
return mfspr(SPRN_MCSR) == 0 && recoverable;
}
@@ -508,6 +516,11 @@ int machine_check_e500(struct pt_regs *regs)
{
unsigned long reason = get_mc_reason(regs);
+ if (reason & MCSR_BUS_RBERR) {
+ if (fsl_rio_mcheck_exception(regs))
+ return 1;
+ }
+
printk("Machine check in kernel mode.\n");
printk("Caused by (from MCSR=%lx): ", reason);
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 4c518d1..ddbcd16 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -260,9 +260,7 @@ struct rio_priv {
static void __iomem *rio_regs_win;
#ifdef CONFIG_E500
-static int (*saved_mcheck_exception)(struct pt_regs *regs);
-
-static int fsl_rio_mcheck_exception(struct pt_regs *regs)
+int fsl_rio_mcheck_exception(struct pt_regs *regs)
{
const struct exception_table_entry *entry = NULL;
unsigned long reason = mfspr(SPRN_MCSR);
@@ -284,11 +282,9 @@ static int fsl_rio_mcheck_exception(struct pt_regs *regs)
}
}
- if (saved_mcheck_exception)
- return saved_mcheck_exception(regs);
- else
- return cur_cpu_spec->machine_check(regs);
+ return 0;
}
+EXPORT_SYMBOL_GPL(fsl_rio_mcheck_exception);
#endif
/**
@@ -1552,11 +1548,6 @@ int fsl_rio_setup(struct platform_device *dev)
fsl_rio_doorbell_init(port);
fsl_rio_port_write_init(port);
-#ifdef CONFIG_E500
- saved_mcheck_exception = ppc_md.machine_check_exception;
- ppc_md.machine_check_exception = fsl_rio_mcheck_exception;
-#endif
-
return 0;
err:
iounmap(priv->regs_win);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v3] fsl_rio: move machine_check handler into machine_check_e500 & machine_check_e500mc
Signed-off-by: Shaohui Xie
Cc: Li Yang
Cc: Kumar Gala
Cc: Roy Zang
Cc: Alexandre Bounine
---
arch/powerpc/include/asm/rio.h |5 +
arch/powerpc/kernel/traps.c| 17 -
arch/powerpc/sysdev/fsl_rio.c | 15 +++
3 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/rio.h b/arch/powerpc/include/asm/rio.h
index 0018bf8..3b16364 100644
--- a/arch/powerpc/include/asm/rio.h
+++ b/arch/powerpc/include/asm/rio.h
@@ -14,5 +14,10 @@
#define ASM_PPC_RIO_H
extern void platform_rio_init(void);
+#ifdef CONFIG_RAPIDIO
+extern int fsl_rio_mcheck_exception(struct pt_regs *);
+#else
+static inline int fsl_rio_mcheck_exception(struct pt_regs *regs){return 0;}
+#endif
#endif /* ASM_PPC_RIO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a45a63c..9ab7b97 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -55,6 +55,7 @@
#endif
#include
#include
+#include
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -425,6 +426,12 @@ int machine_check_e500mc(struct pt_regs *regs)
unsigned long reason = mcsr;
int recoverable = 1;
+ if (reason & MCSR_BUS_RBERR) {
+ recoverable = fsl_rio_mcheck_exception(regs);
+ if (recoverable == 1)
+ goto silent_out;
+ }
+
printk("Machine check in kernel mode.\n");
printk("Caused by (from MCSR=%lx): ", reason);
@@ -500,6 +507,7 @@ int machine_check_e500mc(struct pt_regs *regs)
reason & MCSR_MEA ? "Effective" : "Physical", addr);
}
+silent_out:
mtspr(SPRN_MCSR, mcsr);
return mfspr(SPRN_MCSR) == 0 && recoverable;
}
@@ -507,6 +515,13 @@ int machine_check_e500mc(struct pt_regs *regs)
int machine_check_e500(struct pt_regs *regs)
{
unsigned long reason = get_mc_reason(regs);
+ int ret = 0;
+
+ if (reason & MCSR_BUS_RBERR) {
+ ret = fsl_rio_mcheck_exception(regs);
+ if (ret == 1)
+ return ret;
+ }
printk("Machine check in kernel mode.\n");
printk("Caused by (from MCSR=%lx): ", reason);
@@ -536,7 +551,7 @@ int machine_check_e500(struct pt_regs *regs)
if (reason & MCSR_BUS_RPERR)
printk("Bus - Read Parity Error\n");
- return 0;
+ return ret;
}
#elif defined(CONFIG_E200)
int machine_check_e200(struct pt_regs *regs)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 1143c93..a9bc1e8 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -256,9 +256,7 @@ struct rio_priv {
static void __iomem *rio_regs_win;
#ifdef CONFIG_E500
-static int (*saved_mcheck_exception)(struct pt_regs *regs);
-
-static int fsl_rio_mcheck_exception(struct pt_regs *regs)
+int fsl_rio_mcheck_exception(struct pt_regs *regs)
{
const struct exception_table_entry *entry = NULL;
unsigned long reason = mfspr(SPRN_MCSR);
@@ -280,11 +278,9 @@ static int fsl_rio_mcheck_exception(struct pt_regs *regs)
}
}
- if (saved_mcheck_exception)
- return saved_mcheck_exception(regs);
- else
- return cur_cpu_spec->machine_check(regs);
+ return 0;
}
+EXPORT_SYMBOL_GPL(fsl_rio_mcheck_exception);
#endif
/**
@@ -1534,11 +1530,6 @@ int fsl_rio_setup(struct platform_device *dev)
fsl_rio_doorbell_init(port);
fsl_rio_port_write_init(port);
-#ifdef CONFIG_E500
- saved_mcheck_exception = ppc_md.machine_check_exception;
- ppc_md.machine_check_exception = fsl_rio_mcheck_exception;
-#endif
-
return 0;
err:
iounmap(priv->regs_win);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4][v2] rapidio, powerpc/85xx: Error interrupt handler for sRIO.
The sRIO controller reports errors to the core with one signal, it uses
register EPWISR to provides the core quick access to where the error occurred.
The EPWISR indicates that there are 4 interrupts sources, port1, port2, message
unit and port write receive, but the sRIO driver does not support port2
for now, still the handler takes care of port2.
Currently the handler only clear error status without any recovery.
Signed-off-by: Shaohui Xie
Cc: Li Yang
Cc: Kumar Gala
Cc: Roy Zang
Cc: Alexandre Bounine
---
arch/powerpc/sysdev/fsl_rio.c | 86 +---
1 files changed, 79 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index a9bc1e8..8de86a8 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -10,7 +10,7 @@
* - Added Port-Write message handling
* - Added Machine Check exception handling
*
- * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc.
+ * Copyright (C) 2007, 2008, 2010 Freescale Semiconductor, Inc.
* Zhang Wei
*
* Copyright 2005 MontaVista Software, Inc.
@@ -47,10 +47,36 @@
#define IRQ_RIO_RX(m) (((struct rio_priv *)(m->priv))->rxirq)
#define IRQ_RIO_PW(m) (((struct rio_priv *)(m->priv))->pwirq)
+/* EPWISR Error match value */
+#define EPWISR_ERR_PINT1 0x8000
+#define EPWISR_ERR_PINT2 0x4000
+#define EPWISR_ERR_MU 0x2
+#define EPWISR_ERR_PW 0x1
+
+#define IPWMR_CLEAR_QUEUE 0x0002
+#define IPWSR_CLEAR0x98
+#define OMSR_CLEAR 0x1cb3
+#define IMSR_CLEAR 0x491
+#define IDSR_CLEAR 0x91
+#define ODSR_CLEAR 0x1c00
+#define LTLEECSR_ENABLE_ALL0xFFC000FC
+#define ESCSR_CLEAR0x07120204
+
+#define RIO_EDCSR 0x0640
+#define PORT2_RIO_EDCSR0x0680
+#define RIO_IECSR 0x10130
+#define PORT2_RIO_IECSR0x101B0
+#define RIO_IM0SR 0x13064
+#define RIO_IM1SR 0x13164
+#define RIO_OM0SR 0x13004
+#define RIO_OM1SR 0x13104
+
+#define RIO_EPWISR_OFFSET 0x10010
#define RIO_ATMU_REGS_OFFSET 0x10c00
#define RIO_P_MSG_REGS_OFFSET 0x11000
#define RIO_S_MSG_REGS_OFFSET 0x13000
#define RIO_ESCSR 0x158
+#define PORT2_RIO_ESCSR0x178
#define RIO_CCSR 0x15c
#define RIO_LTLEDCSR 0x0608
#define RIO_LTLEDCSR_IER 0x8000
@@ -1003,6 +1029,40 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
return IRQ_HANDLED;
}
+static void port_error_handler(struct rio_mport *port, int offset)
+{
+ /*XXX: Error recovery is not implemented, we just clear errors */
+ out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
+
+ if (offset == 0) {
+ out_be32((u32 *)(rio_regs_win + RIO_EDCSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_ESCSR), ESCSR_CLEAR);
+ } else {
+ out_be32((u32 *)(rio_regs_win + PORT2_RIO_EDCSR), 0);
+ out_be32((u32 *)(rio_regs_win + PORT2_RIO_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + PORT2_RIO_ESCSR), ESCSR_CLEAR);
+ }
+}
+
+static void msg_unit_error_handler(struct rio_mport *port)
+{
+ struct rio_priv *priv = port->priv;
+
+ /*XXX: Error recovery is not implemented, we just clear errors */
+ out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
+
+ out_be32((u32 *)(rio_regs_win + RIO_IM0SR), IMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_IM1SR), IMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_OM0SR), OMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_OM1SR), OMSR_CLEAR);
+
+ out_be32(&priv->msg_regs->odsr, ODSR_CLEAR);
+ out_be32(&priv->msg_regs->dsr, IDSR_CLEAR);
+
+ out_be32(&priv->msg_regs->pwsr, IPWSR_CLEAR);
+}
+
/**
* fsl_rio_doorbell_init - MPC85xx doorbell interface init
* @mport: Master port implementing the inbound doorbell unit
@@ -1082,14 +1142,24 @@ fsl_rio_port_write_handler(int irq, void *dev_instance)
ipwsr = in_be32(&priv->msg_regs->pwsr);
epwisr = in_be32(priv->regs_win + RIO_EPWISR);
- if (epwisr & 0x8000) {
+ if (epwisr & EPWISR_ERR_PINT1) {
tmp = in_be32(priv->regs_win + RIO_LTLEDCSR);
pr_info("RIO_LTLEDCSR = 0x%x\n", tmp);
- out_be32(priv->regs_win + RIO_LTLEDCSR, 0);
+ port_error_handler(port, 0);
+ }
+
+ if (epwisr & EPWISR_ERR_PINT2) {
+ pr_info("RIO: port2 error\n");
+ port_error_handler(port, 1);
+ }
+
+ if (epwisr & EPWISR_ERR_MU) {
+ pr_info("RIO: message unit error\n");
+ msg_unit_error_handler(port);
}
- if (!(epwisr &a
[PATCH 3/4][v2] fsl_rio: move machine_check handler into machine_check_e500 & machine_check_e500mc
Signed-off-by: Shaohui Xie
Cc: Li Yang
Cc: Kumar Gala
Cc: Roy Zang
Cc: Alexandre Bounine
---
arch/powerpc/kernel/traps.c | 14 +-
arch/powerpc/sysdev/fsl_rio.c | 15 +++
include/linux/rio.h |1 +
3 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a45a63c..2a5fb9d 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -55,6 +55,7 @@
#endif
#include
#include
+#include
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -500,6 +501,13 @@ int machine_check_e500mc(struct pt_regs *regs)
reason & MCSR_MEA ? "Effective" : "Physical", addr);
}
+ if (reason & MCSR_BUS_RBERR) {
+ printk("Bus - Read Data Bus Error\n");
+#ifdef CONFIG_RAPIDIO
+ recoverable = fsl_rio_mcheck_exception(regs);
+#endif
+ }
+
mtspr(SPRN_MCSR, mcsr);
return mfspr(SPRN_MCSR) == 0 && recoverable;
}
@@ -527,8 +535,12 @@ int machine_check_e500(struct pt_regs *regs)
printk("Bus - Write Address Error\n");
if (reason & MCSR_BUS_IBERR)
printk("Bus - Instruction Data Error\n");
- if (reason & MCSR_BUS_RBERR)
+ if (reason & MCSR_BUS_RBERR) {
printk("Bus - Read Data Bus Error\n");
+#ifdef CONFIG_RAPIDIO
+ fsl_rio_mcheck_exception(regs);
+#endif
+ }
if (reason & MCSR_BUS_WBERR)
printk("Bus - Read Data Bus Error\n");
if (reason & MCSR_BUS_IPERR)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 1143c93..a9bc1e8 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -256,9 +256,7 @@ struct rio_priv {
static void __iomem *rio_regs_win;
#ifdef CONFIG_E500
-static int (*saved_mcheck_exception)(struct pt_regs *regs);
-
-static int fsl_rio_mcheck_exception(struct pt_regs *regs)
+int fsl_rio_mcheck_exception(struct pt_regs *regs)
{
const struct exception_table_entry *entry = NULL;
unsigned long reason = mfspr(SPRN_MCSR);
@@ -280,11 +278,9 @@ static int fsl_rio_mcheck_exception(struct pt_regs *regs)
}
}
- if (saved_mcheck_exception)
- return saved_mcheck_exception(regs);
- else
- return cur_cpu_spec->machine_check(regs);
+ return 0;
}
+EXPORT_SYMBOL_GPL(fsl_rio_mcheck_exception);
#endif
/**
@@ -1534,11 +1530,6 @@ int fsl_rio_setup(struct platform_device *dev)
fsl_rio_doorbell_init(port);
fsl_rio_port_write_init(port);
-#ifdef CONFIG_E500
- saved_mcheck_exception = ppc_md.machine_check_exception;
- ppc_md.machine_check_exception = fsl_rio_mcheck_exception;
-#endif
-
return 0;
err:
iounmap(priv->regs_win);
diff --git a/include/linux/rio.h b/include/linux/rio.h
index bd6eb0e..685b18f 100644
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -365,5 +365,6 @@ extern int rio_open_inb_mbox(struct rio_mport *, void *,
int, int);
extern void rio_close_inb_mbox(struct rio_mport *, int);
extern int rio_open_outb_mbox(struct rio_mport *, void *, int, int);
extern void rio_close_outb_mbox(struct rio_mport *, int);
+extern int fsl_rio_mcheck_exception(struct pt_regs *);
#endif /* LINUX_RIO_H */
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4][v2] fsl_rio: fix non-standard HID1 register access
Signed-off-by: Shaohui Xie Cc: Li Yang Cc: Kumar Gala Cc: Roy Zang Cc: Alexandre Bounine --- arch/powerpc/kernel/cpu_setup_fsl_booke.S |6 ++ arch/powerpc/sysdev/fsl_rio.c |2 -- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S index 0adb50a..8fd5bc6 100644 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S @@ -63,6 +63,12 @@ _GLOBAL(__setup_cpu_e500v2) bl __e500_icache_setup bl __e500_dcache_setup bl __setup_e500_ivors +#ifdef CONFIG_RAPIDIO + /* Ensure that RFXE is set */ + mfspr r3,SPRN_HID1 + orisr3,r3,hid1_r...@h + mtspr SPRN_HID1,r3 +#endif mtlrr4 blr _GLOBAL(__setup_cpu_e500mc) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 4127636..1143c93 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1538,8 +1538,6 @@ int fsl_rio_setup(struct platform_device *dev) saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; #endif - /* Ensure that RFXE is set */ - mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); return 0; err: -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4][v2] powerpc: add e500 HID1 bit definition
From: Li Yang Also make 74xx HID1 definition conditional. Signed-off-by: Li Yang Signed-off-by: Shaohui Xie Cc: Li Yang Cc: Kumar Gala Cc: Roy Zang Cc: Alexandre Bounine --- These patches have been send for almost one week, and has no feedback. arch/powerpc/include/asm/reg.h |2 ++ arch/powerpc/include/asm/reg_booke.h | 14 ++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index ff0005e..125fc1a 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -283,6 +283,7 @@ #define HID0_NOPTI (1<<0) /* No-op dcbt and dcbst instr. */ #define SPRN_HID1 0x3F1 /* Hardware Implementation Register 1 */ +#ifdef CONFIG_6xx #define HID1_EMCP (1<<31) /* 7450 Machine Check Pin Enable */ #define HID1_DFS (1<<22) /* 7447A Dynamic Frequency Scaling */ #define HID1_PC0 (1<<16) /* 7450 PLL_CFG[0] */ @@ -292,6 +293,7 @@ #define HID1_SYNCBE(1<<11) /* 7450 ABE for sync, eieio */ #define HID1_ABE (1<<10) /* 7450 Address Broadcast Enable */ #define HID1_PS(1<<16) /* 750FX PLL selection */ +#endif #define SPRN_HID2 0x3F8 /* Hardware Implementation Register 2 */ #define SPRN_HID2_GEKKO0x398 /* Gekko HID2 Register */ #define SPRN_IABR 0x3F2 /* Instruction Address Breakpoint Register */ diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index 667a498..dc6adff 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -246,6 +246,20 @@ store or cache line push */ #endif +/* Bit definitions for the HID1 */ +#ifdef CONFIG_E500 +/* e500v1/v2 */ +#define HID1_PLL_CFG_MASK 0xfc00 /* PLL_CFG input pins */ +#define HID1_RFXE 0x0002 /* Read fault exception enable */ +#define HID1_R1DPE 0x8000 /* R1 data bus parity enable */ +#define HID1_R2DPE 0x4000 /* R2 data bus parity enable */ +#define HID1_ASTME 0x2000 /* Address bus streaming mode enable */ +#define HID1_ABE 0x1000 /* Address broadcast enable */ +#define HID1_MPXTT 0x0400 /* MPX re-map transfer type */ +#define HID1_ATS 0x0080 /* Atomic status */ +#define HID1_MID_MASK 0x000f /* MID input pins */ +#endif + /* Bit definitions for the DBSR. */ /* * DBSR bits which have conflicting definitions on true Book E versus IBM 40x. -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4][v2] rapidio, powerpc/85xx: Error interrupt handler for sRIO.
The sRIO controller reports errors to the core with one signal, it uses
register EPWISR to provides the core quick access to where the error occurred.
The EPWISR indicates that there are 4 interrupts sources, port1, port2, message
unit and port write receive, but the sRIO driver does not support port2
for now, still the handler takes care of port2.
Currently the handler only clear error status without any recovery.
Signed-off-by: Shaohui Xie
Cc: Li Yang
Cc: Kumar Gala
Cc: Roy Zang
Cc: Alexandre Bounine
---
arch/powerpc/sysdev/fsl_rio.c | 86 +---
1 files changed, 79 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index a9bc1e8..8de86a8 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -10,7 +10,7 @@
* - Added Port-Write message handling
* - Added Machine Check exception handling
*
- * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc.
+ * Copyright (C) 2007, 2008, 2010 Freescale Semiconductor, Inc.
* Zhang Wei
*
* Copyright 2005 MontaVista Software, Inc.
@@ -47,10 +47,36 @@
#define IRQ_RIO_RX(m) (((struct rio_priv *)(m->priv))->rxirq)
#define IRQ_RIO_PW(m) (((struct rio_priv *)(m->priv))->pwirq)
+/* EPWISR Error match value */
+#define EPWISR_ERR_PINT1 0x8000
+#define EPWISR_ERR_PINT2 0x4000
+#define EPWISR_ERR_MU 0x2
+#define EPWISR_ERR_PW 0x1
+
+#define IPWMR_CLEAR_QUEUE 0x0002
+#define IPWSR_CLEAR0x98
+#define OMSR_CLEAR 0x1cb3
+#define IMSR_CLEAR 0x491
+#define IDSR_CLEAR 0x91
+#define ODSR_CLEAR 0x1c00
+#define LTLEECSR_ENABLE_ALL0xFFC000FC
+#define ESCSR_CLEAR0x07120204
+
+#define RIO_EDCSR 0x0640
+#define PORT2_RIO_EDCSR0x0680
+#define RIO_IECSR 0x10130
+#define PORT2_RIO_IECSR0x101B0
+#define RIO_IM0SR 0x13064
+#define RIO_IM1SR 0x13164
+#define RIO_OM0SR 0x13004
+#define RIO_OM1SR 0x13104
+
+#define RIO_EPWISR_OFFSET 0x10010
#define RIO_ATMU_REGS_OFFSET 0x10c00
#define RIO_P_MSG_REGS_OFFSET 0x11000
#define RIO_S_MSG_REGS_OFFSET 0x13000
#define RIO_ESCSR 0x158
+#define PORT2_RIO_ESCSR0x178
#define RIO_CCSR 0x15c
#define RIO_LTLEDCSR 0x0608
#define RIO_LTLEDCSR_IER 0x8000
@@ -1003,6 +1029,40 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
return IRQ_HANDLED;
}
+static void port_error_handler(struct rio_mport *port, int offset)
+{
+ /*XXX: Error recovery is not implemented, we just clear errors */
+ out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
+
+ if (offset == 0) {
+ out_be32((u32 *)(rio_regs_win + RIO_EDCSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_ESCSR), ESCSR_CLEAR);
+ } else {
+ out_be32((u32 *)(rio_regs_win + PORT2_RIO_EDCSR), 0);
+ out_be32((u32 *)(rio_regs_win + PORT2_RIO_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + PORT2_RIO_ESCSR), ESCSR_CLEAR);
+ }
+}
+
+static void msg_unit_error_handler(struct rio_mport *port)
+{
+ struct rio_priv *priv = port->priv;
+
+ /*XXX: Error recovery is not implemented, we just clear errors */
+ out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
+
+ out_be32((u32 *)(rio_regs_win + RIO_IM0SR), IMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_IM1SR), IMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_OM0SR), OMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_OM1SR), OMSR_CLEAR);
+
+ out_be32(&priv->msg_regs->odsr, ODSR_CLEAR);
+ out_be32(&priv->msg_regs->dsr, IDSR_CLEAR);
+
+ out_be32(&priv->msg_regs->pwsr, IPWSR_CLEAR);
+}
+
/**
* fsl_rio_doorbell_init - MPC85xx doorbell interface init
* @mport: Master port implementing the inbound doorbell unit
@@ -1082,14 +1142,24 @@ fsl_rio_port_write_handler(int irq, void *dev_instance)
ipwsr = in_be32(&priv->msg_regs->pwsr);
epwisr = in_be32(priv->regs_win + RIO_EPWISR);
- if (epwisr & 0x8000) {
+ if (epwisr & EPWISR_ERR_PINT1) {
tmp = in_be32(priv->regs_win + RIO_LTLEDCSR);
pr_info("RIO_LTLEDCSR = 0x%x\n", tmp);
- out_be32(priv->regs_win + RIO_LTLEDCSR, 0);
+ port_error_handler(port, 0);
+ }
+
+ if (epwisr & EPWISR_ERR_PINT2) {
+ pr_info("RIO: port2 error\n");
+ port_error_handler(port, 1);
+ }
+
+ if (epwisr & EPWISR_ERR_MU) {
+ pr_info("RIO: message unit error\n");
+ msg_unit_error_handler(port);
}
- if (!(epwisr &a
[PATCH 1/4][v2] powerpc: add e500 HID1 bit definition
From: Li Yang Also make 74xx HID1 definition conditional. Signed-off-by: Li Yang Signed-off-by: Shaohui Xie Cc: Li Yang Cc: Kumar Gala Cc: Roy Zang Cc: Alexandre Bounine --- arch/powerpc/include/asm/reg.h |2 ++ arch/powerpc/include/asm/reg_booke.h | 14 ++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index ff0005e..125fc1a 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -283,6 +283,7 @@ #define HID0_NOPTI (1<<0) /* No-op dcbt and dcbst instr. */ #define SPRN_HID1 0x3F1 /* Hardware Implementation Register 1 */ +#ifdef CONFIG_6xx #define HID1_EMCP (1<<31) /* 7450 Machine Check Pin Enable */ #define HID1_DFS (1<<22) /* 7447A Dynamic Frequency Scaling */ #define HID1_PC0 (1<<16) /* 7450 PLL_CFG[0] */ @@ -292,6 +293,7 @@ #define HID1_SYNCBE(1<<11) /* 7450 ABE for sync, eieio */ #define HID1_ABE (1<<10) /* 7450 Address Broadcast Enable */ #define HID1_PS(1<<16) /* 750FX PLL selection */ +#endif #define SPRN_HID2 0x3F8 /* Hardware Implementation Register 2 */ #define SPRN_HID2_GEKKO0x398 /* Gekko HID2 Register */ #define SPRN_IABR 0x3F2 /* Instruction Address Breakpoint Register */ diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index 667a498..dc6adff 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -246,6 +246,20 @@ store or cache line push */ #endif +/* Bit definitions for the HID1 */ +#ifdef CONFIG_E500 +/* e500v1/v2 */ +#define HID1_PLL_CFG_MASK 0xfc00 /* PLL_CFG input pins */ +#define HID1_RFXE 0x0002 /* Read fault exception enable */ +#define HID1_R1DPE 0x8000 /* R1 data bus parity enable */ +#define HID1_R2DPE 0x4000 /* R2 data bus parity enable */ +#define HID1_ASTME 0x2000 /* Address bus streaming mode enable */ +#define HID1_ABE 0x1000 /* Address broadcast enable */ +#define HID1_MPXTT 0x0400 /* MPX re-map transfer type */ +#define HID1_ATS 0x0080 /* Atomic status */ +#define HID1_MID_MASK 0x000f /* MID input pins */ +#endif + /* Bit definitions for the DBSR. */ /* * DBSR bits which have conflicting definitions on true Book E versus IBM 40x. -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4][v2] fsl_rio: move machine_check handler into machine_check_e500 & machine_check_e500mc
Signed-off-by: Shaohui Xie
Cc: Li Yang
Cc: Kumar Gala
Cc: Roy Zang
Cc: Alexandre Bounine
---
arch/powerpc/kernel/traps.c | 14 +-
arch/powerpc/sysdev/fsl_rio.c | 15 +++
include/linux/rio.h |1 +
3 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a45a63c..2a5fb9d 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -55,6 +55,7 @@
#endif
#include
#include
+#include
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -500,6 +501,13 @@ int machine_check_e500mc(struct pt_regs *regs)
reason & MCSR_MEA ? "Effective" : "Physical", addr);
}
+ if (reason & MCSR_BUS_RBERR) {
+ printk("Bus - Read Data Bus Error\n");
+#ifdef CONFIG_RAPIDIO
+ recoverable = fsl_rio_mcheck_exception(regs);
+#endif
+ }
+
mtspr(SPRN_MCSR, mcsr);
return mfspr(SPRN_MCSR) == 0 && recoverable;
}
@@ -527,8 +535,12 @@ int machine_check_e500(struct pt_regs *regs)
printk("Bus - Write Address Error\n");
if (reason & MCSR_BUS_IBERR)
printk("Bus - Instruction Data Error\n");
- if (reason & MCSR_BUS_RBERR)
+ if (reason & MCSR_BUS_RBERR) {
printk("Bus - Read Data Bus Error\n");
+#ifdef CONFIG_RAPIDIO
+ fsl_rio_mcheck_exception(regs);
+#endif
+ }
if (reason & MCSR_BUS_WBERR)
printk("Bus - Read Data Bus Error\n");
if (reason & MCSR_BUS_IPERR)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 1143c93..a9bc1e8 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -256,9 +256,7 @@ struct rio_priv {
static void __iomem *rio_regs_win;
#ifdef CONFIG_E500
-static int (*saved_mcheck_exception)(struct pt_regs *regs);
-
-static int fsl_rio_mcheck_exception(struct pt_regs *regs)
+int fsl_rio_mcheck_exception(struct pt_regs *regs)
{
const struct exception_table_entry *entry = NULL;
unsigned long reason = mfspr(SPRN_MCSR);
@@ -280,11 +278,9 @@ static int fsl_rio_mcheck_exception(struct pt_regs *regs)
}
}
- if (saved_mcheck_exception)
- return saved_mcheck_exception(regs);
- else
- return cur_cpu_spec->machine_check(regs);
+ return 0;
}
+EXPORT_SYMBOL_GPL(fsl_rio_mcheck_exception);
#endif
/**
@@ -1534,11 +1530,6 @@ int fsl_rio_setup(struct platform_device *dev)
fsl_rio_doorbell_init(port);
fsl_rio_port_write_init(port);
-#ifdef CONFIG_E500
- saved_mcheck_exception = ppc_md.machine_check_exception;
- ppc_md.machine_check_exception = fsl_rio_mcheck_exception;
-#endif
-
return 0;
err:
iounmap(priv->regs_win);
diff --git a/include/linux/rio.h b/include/linux/rio.h
index bd6eb0e..685b18f 100644
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -365,5 +365,6 @@ extern int rio_open_inb_mbox(struct rio_mport *, void *,
int, int);
extern void rio_close_inb_mbox(struct rio_mport *, int);
extern int rio_open_outb_mbox(struct rio_mport *, void *, int, int);
extern void rio_close_outb_mbox(struct rio_mport *, int);
+extern int fsl_rio_mcheck_exception(struct pt_regs *);
#endif /* LINUX_RIO_H */
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4][v2] fsl_rio: fix non-standard HID1 register access
Signed-off-by: Shaohui Xie Cc: Li Yang Cc: Kumar Gala Cc: Roy Zang Cc: Alexandre Bounine --- arch/powerpc/kernel/cpu_setup_fsl_booke.S |6 ++ arch/powerpc/sysdev/fsl_rio.c |2 -- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S index 0adb50a..8fd5bc6 100644 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S @@ -63,6 +63,12 @@ _GLOBAL(__setup_cpu_e500v2) bl __e500_icache_setup bl __e500_dcache_setup bl __setup_e500_ivors +#ifdef CONFIG_RAPIDIO + /* Ensure that RFXE is set */ + mfspr r3,SPRN_HID1 + orisr3,r3,hid1_r...@h + mtspr SPRN_HID1,r3 +#endif mtlrr4 blr _GLOBAL(__setup_cpu_e500mc) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 4127636..1143c93 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1538,8 +1538,6 @@ int fsl_rio_setup(struct platform_device *dev) saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; #endif - /* Ensure that RFXE is set */ - mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); return 0; err: -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] rapidio, powerpc/85xx: Error interrupt handler for sRIO.
The sRIO controller reports errors to the core with one signal, it uses
register EPWISR to provides the core quick access to where the error occurred.
The EPWISR indicates that there are 4 interrupts sources, port1, port2, message
unit and port write receive, but the sRIO driver does not support port2
for now, still the handler takes care of port2.
Currently the handler only clear error status without any recovery.
Signed-off-by: Shaohui Xie
---
arch/powerpc/sysdev/fsl_rio.c | 81 ++---
1 files changed, 76 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index dfff3b7..be7cc98 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -10,7 +10,7 @@
* - Added Port-Write message handling
* - Added Machine Check exception handling
*
- * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc.
+ * Copyright (C) 2007, 2008, 2010 Freescale Semiconductor, Inc.
* Zhang Wei
*
* Copyright 2005 MontaVista Software, Inc.
@@ -47,10 +47,36 @@
#define IRQ_RIO_RX(m) (((struct rio_priv *)(m->priv))->rxirq)
#define IRQ_RIO_PW(m) (((struct rio_priv *)(m->priv))->pwirq)
+/* EPWISR Error match value */
+#define EPWISR_ERR_PINT1 0x8000
+#define EPWISR_ERR_PINT2 0x4000
+#define EPWISR_ERR_MU 0x2
+#define EPWISR_ERR_PW 0x1
+
+#define IPWMR_CLEAR_QUEUE 0x0002
+#define IPWSR_CLEAR0x98
+#define OMSR_CLEAR 0x1cb3
+#define IMSR_CLEAR 0x491
+#define IDSR_CLEAR 0x91
+#define ODSR_CLEAR 0x1c00
+#define LTLEECSR_ENABLE_ALL0xFFC000FC
+#define ESCSR_CLEAR0x07120204
+
+#define RIO_EDCSR 0x0640
+#define PORT2_RIO_EDCSR0x0680
+#define RIO_IECSR 0x10130
+#define PORT2_RIO_IECSR0x101B0
+#define RIO_IM0SR 0x13064
+#define RIO_IM1SR 0x13164
+#define RIO_OM0SR 0x13004
+#define RIO_OM1SR 0x13104
+
+#define RIO_EPWISR_OFFSET 0x10010
#define RIO_ATMU_REGS_OFFSET 0x10c00
#define RIO_P_MSG_REGS_OFFSET 0x11000
#define RIO_S_MSG_REGS_OFFSET 0x13000
#define RIO_ESCSR 0x158
+#define PORT2_RIO_ESCSR0x178
#define RIO_CCSR 0x15c
#define RIO_LTLEDCSR 0x0608
#define RIO_LTLEDCSR_IER 0x8000
@@ -1007,6 +1033,38 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
return IRQ_HANDLED;
}
+void port_error_handler(struct rio_mport *port, int offset)
+{
+ /*XXX: Error recovery is not implemented, we just clear errors */
+ out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
+
+ if (offset == 0) {
+ out_be32((u32 *)(rio_regs_win + RIO_EDCSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_ESCSR), ESCSR_CLEAR);
+ } else {
+ out_be32((u32 *)(rio_regs_win + PORT2_RIO_EDCSR), 0);
+ out_be32((u32 *)(rio_regs_win + PORT2_RIO_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + PORT2_RIO_ESCSR), ESCSR_CLEAR);
+ }
+}
+
+void msg_unit_error_handler(struct rio_mport *port)
+{
+ struct rio_priv *priv = port->priv;
+
+ /*XXX: Error recovery is not implemented, we just clear errors */
+ out_be32((u32 *)(rio_regs_win + RIO_IM0SR), IMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_IM1SR), IMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_OM0SR), OMSR_CLEAR);
+ out_be32((u32 *)(rio_regs_win + RIO_OM1SR), OMSR_CLEAR);
+
+ out_be32(&priv->msg_regs->odsr, ODSR_CLEAR);
+ out_be32(&priv->msg_regs->dsr, IDSR_CLEAR);
+
+ out_be32(&priv->msg_regs->pwsr, IPWSR_CLEAR);
+}
+
/**
* fsl_rio_doorbell_init - MPC85xx doorbell interface init
* @mport: Master port implementing the inbound doorbell unit
@@ -1086,13 +1144,24 @@ fsl_rio_port_write_handler(int irq, void *dev_instance)
ipwsr = in_be32(&priv->msg_regs->pwsr);
epwisr = in_be32(priv->regs_win + RIO_EPWISR);
- if (epwisr & 0x8000) {
+ if (epwisr & EPWISR_ERR_PINT1) {
tmp = in_be32(priv->regs_win + RIO_LTLEDCSR);
pr_info("RIO_LTLEDCSR = 0x%x\n", tmp);
out_be32(priv->regs_win + RIO_LTLEDCSR, 0);
+ port_error_handler(port, 0);
+ }
+
+ if (epwisr & EPWISR_ERR_PINT2) {
+ pr_info("RIO: port2 error\n");
+ port_error_handler(port, 1);
+ }
+
+ if (epwisr & EPWISR_ERR_MU) {
+ pr_info("RIO: message unit error\n");
+ msg_unit_error_handler(port);
}
- if (!(epwisr & 0x0001))
+ if (!(epwisr & EPWISR_ERR_PW))
return IRQ_HANDLED;
#ifdef DEBUG_PW
@@ -1253,12 +1322,14 @
[PATCH 1/3] fsl_rio: Add comments for sRIO registers.
Add some comments to make sRIO registers map better readable.
Signed-off-by: Shaohui Xie
---
arch/powerpc/sysdev/fsl_rio.c | 65 +
1 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 3017532..4127636 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -117,44 +117,59 @@ struct rio_atmu_regs {
};
struct rio_msg_regs {
- u32 omr;
- u32 osr;
+ u32 omr;/* 0xD_3000 - Outbound message 0 mode register */
+ u32 osr;/* 0xD_3004 - Outbound message 0 status register */
u32 pad1;
- u32 odqdpar;
+ u32 odqdpar;/* 0xD_300C - Outbound message 0 descriptor queue
+ dequeue pointer address register */
u32 pad2;
- u32 osar;
- u32 odpr;
- u32 odatr;
- u32 odcr;
+ u32 osar; /* 0xD_3014 - Outbound message 0 source address
+ register */
+ u32 odpr; /* 0xD_3018 - Outbound message 0 destination port
+ register */
+ u32 odatr; /* 0xD_301C - Outbound message 0 destination attributes
+ Register*/
+ u32 odcr; /* 0xD_3020 - Outbound message 0 double-word count
+ register */
u32 pad3;
- u32 odqepar;
+ u32 odqepar;/* 0xD_3028 - Outbound message 0 descriptor queue
+ enqueue pointer address register */
u32 pad4[13];
- u32 imr;
- u32 isr;
+ u32 imr;/* 0xD_3060 - Inbound message 0 mode register */
+ u32 isr;/* 0xD_3064 - Inbound message 0 status register */
u32 pad5;
- u32 ifqdpar;
+ u32 ifqdpar;/* 0xD_306C - Inbound message 0 frame queue dequeue
+ pointer address register*/
u32 pad6;
- u32 ifqepar;
+ u32 ifqepar;/* 0xD_3074 - Inbound message 0 frame queue enqueue
+ pointer address register */
u32 pad7[226];
- u32 odmr;
- u32 odsr;
+ u32 odmr; /* 0xD_3400 - Outbound doorbell mode register */
+ u32 odsr; /* 0xD_3404 - Outbound doorbell status register */
u32 res0[4];
- u32 oddpr;
- u32 oddatr;
+ u32 oddpr; /* 0xD_3418 - Outbound doorbell destination port
+ register */
+ u32 oddatr; /* 0xD_341c - Outbound doorbell destination attributes
+ register */
u32 res1[3];
- u32 odretcr;
+ u32 odretcr;/* 0xD_342C - Outbound doorbell retry error threshold
+ configuration register */
u32 res2[12];
- u32 dmr;
- u32 dsr;
+ u32 dmr;/* 0xD_3460 - Inbound doorbell mode register */
+ u32 dsr;/* 0xD_3464 - Inbound doorbell status register */
u32 pad8;
- u32 dqdpar;
+ u32 dqdpar; /* 0xD_346C - Inbound doorbell queue dequeue Pointer
+ address register */
u32 pad9;
- u32 dqepar;
+ u32 dqepar; /* 0xD_3474 - Inbound doorbell Queue enqueue pointer
+ address register */
u32 pad10[26];
- u32 pwmr;
- u32 pwsr;
- u32 epwqbar;
- u32 pwqbar;
+ u32 pwmr; /* 0xD_34E0 - Inbound port-write mode register */
+ u32 pwsr; /* 0xD_34E4 - Inbound port-write status register */
+ u32 epwqbar;/* 0xD_34E8 - Extended Port-Write Queue Base Address
+ register */
+ u32 pwqbar; /* 0xD_34EC - Inbound port-write queue base address
+ register */
};
struct rio_tx_desc {
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] fsl_rio: fix non-standard HID1 register access
From: Li Yang The access to HID1 register is only legitimate for e500 v1/v2 cores. Also fixes magic number. Signed-off-by: Li Yang Signed-off-by: Shaohui Xie --- arch/powerpc/sysdev/fsl_rio.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device *dev) #ifdef CONFIG_E500 saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif - /* Ensure that RFXE is set */ - mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); + +#ifndef CONFIG_PPC_E500MC + /* Ensure that RFXE is set on e500 v1/v2 */ + mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); +#endif /* !PPC_E500MC */ +#endif /* E500 */ return 0; err: -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
