From: Joe Hamman <hidden> Date: 2007-08-13 22:57:37
Allow the address of the Ten Bit Interface (TBI) to be changed in the
event of a conflict with another device.
Signed-off by: Joe Hamman [off-list ref]
---
Please ignore the last patch - I missed a cut & paste error on the range
that my testing didn't catch.
---
@@ -490,15 +490,15 @@ static void gfar_configure_serdes(struct net_device *dev)/* Initialise TBI i/f to communicate with serdes (lynx phy) *//* Single clk mode, mii mode off(for aerdes communication) */-gfar_local_mdio_write(regs,TBIPA_VALUE,MII_TBICON,TBICON_CLK_SELECT);+gfar_local_mdio_write(regs,CONFIG_GFAR_TBIPA_VALUE,MII_TBICON,TBICON_CLK_SELECT);/* Supported pause and full-duplex, no half-duplex */-gfar_local_mdio_write(regs,TBIPA_VALUE,MII_ADVERTISE,+gfar_local_mdio_write(regs,CONFIG_GFAR_TBIPA_VALUE,MII_ADVERTISE,ADVERTISE_1000XFULL|ADVERTISE_1000XPAUSE|ADVERTISE_1000XPSE_ASYM);/* ANEG enable, restart ANEG, full duplex mode, speed[1] set */-gfar_local_mdio_write(regs,TBIPA_VALUE,MII_BMCR,BMCR_ANENABLE|+gfar_local_mdio_write(regs,CONFIG_GFAR_TBIPA_VALUE,MII_BMCR,BMCR_ANENABLE|BMCR_ANRESTART|BMCR_FULLDPLX|BMCR_SPEED1000);}
@@ -547,7 +547,7 @@ static void init_registers(struct net_device *dev)gfar_write(&priv->regs->minflr,MINFLR_INIT_SETTINGS);/* Assign the TBI an address which won't conflict with the PHYs */-gfar_write(&priv->regs->tbipa,TBIPA_VALUE);+gfar_write(&priv->regs->tbipa,CONFIG_GFAR_TBIPA_VALUE);}
From: Kumar Gala <hidden> Date: 2007-08-14 03:07:59
On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
Allow the address of the Ten Bit Interface (TBI) to be changed in the
event of a conflict with another device.
Signed-off by: Joe Hamman [off-list ref]
---
Please ignore the last patch - I missed a cut & paste error on the
range
that my testing didn't catch.
I think we'd rather this came from the device tree.
- k
From: Joe Hamman <hidden> Date: 2007-08-14 03:29:49
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Monday, August 13, 2007 10:10 PM
To: joe.hamman@embeddedspecialties.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
configurable
On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
quoted
Allow the address of the Ten Bit Interface (TBI) to be changed in the
event of a conflict with another device.
Signed-off by: Joe Hamman [off-list ref]
---
Please ignore the last patch - I missed a cut & paste error on the
range
that my testing didn't catch.
I think we'd rather this came from the device tree.
From: Joe Hamman <hidden> Date: 2007-08-14 12:47:58
Hi Kumar,
Or do you think it should be added to gianfar_mdio_data? Easier, but does
it belong there?
Thanks,
Joe
-----Original Message-----
From: linuxppc-embedded-
bounces+joe.hamman=embeddedspecialties.com@ozlabs.org [mailto:linuxppc-
embedded-bounces+joe.hamman=embeddedspecialties.com@ozlabs.org] On Behalf
Of Joe Hamman
Sent: Monday, August 13, 2007 10:30 PM
To: 'Kumar Gala'
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
configurable
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Monday, August 13, 2007 10:10 PM
To: joe.hamman@embeddedspecialties.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
configurable
On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
quoted
Allow the address of the Ten Bit Interface (TBI) to be changed in the
event of a conflict with another device.
Signed-off by: Joe Hamman [off-list ref]
---
Please ignore the last patch - I missed a cut & paste error on the
range
that my testing didn't catch.
I think we'd rather this came from the device tree.
From: Andy Fleming <hidden> Date: 2007-08-14 16:12:00
On Aug 13, 2007, at 22:29, Joe Hamman wrote:
quoted
On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
quoted
Allow the address of the Ten Bit Interface (TBI) to be changed in
the
event of a conflict with another device.
Signed-off by: Joe Hamman [off-list ref]
---
Please ignore the last patch - I missed a cut & paste error on the
range
that my testing didn't catch.
I think we'd rather this came from the device tree.
Duh, that makes sense ;-)
Has there been any discussion yet? Maybe something like this:
mdio@24520 {
It's actually a per-tsec property. There's not one tbi, there's one
per TSEC. The one on TSEC 0 is special in that it can interfere with
PHYs on the MDIO bus.
So I would suggest making it a property of the ethernet node:
ethernet@24000 {
...
tbipa = <1f>;
...
}
etc
Andy
From: Scott Wood <hidden> Date: 2007-08-14 16:16:27
Andy Fleming wrote:
It's actually a per-tsec property. There's not one tbi, there's one
per TSEC. The one on TSEC 0 is special in that it can interfere with
PHYs on the MDIO bus.
So I would suggest making it a property of the ethernet node:
ethernet@24000 {
...
tbipa = <1f>;
...
}
"tbipa" isn't likely to pass the Segher test. :-)
If the TBI address is in PHY-space, then it should go in the MDIO bus.
For the second TSEC, create a second MDIO bus node.
-Scott
From: Joe Hamman <hidden> Date: 2007-08-14 16:50:52
-----Original Message-----
From: Scott Wood [mailto:scottwood@freescale.com]
Sent: Tuesday, August 14, 2007 11:16 AM
To: Andy Fleming
Cc: joe.hamman@embeddedspecialties.com; linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
configurable
Andy Fleming wrote:
quoted
It's actually a per-tsec property. There's not one tbi, there's one
per TSEC. The one on TSEC 0 is special in that it can interfere with
PHYs on the MDIO bus.
So I would suggest making it a property of the ethernet node:
ethernet@24000 {
...
tbipa = <1f>;
...
}
"tbipa" isn't likely to pass the Segher test. :-)
If the TBI address is in PHY-space, then it should go in the MDIO bus.
For the second TSEC, create a second MDIO bus node.
Is any given board going to have at runtime (i.e. not jumper selectable)
both a phy and a tbi (I'm not very familiar with the latter, so I
apologize if this is a dumb question). If not, I'd stick with
phy-handle and have something in the phy node to indicate that it's tbi.
-Scott
Is any given board going to have at runtime (i.e. not jumper
selectable) both a phy and a tbi (I'm not very familiar with the
latter, so I apologize if this is a dumb question). If not, I'd
stick with phy-handle and have something in the phy node to
indicate that it's tbi.
Yes. That will be the more common case. The TBI PHYs are connected
to the MDIO pins of each TSEC. The TBIPA register defines what
address it sits on. It is used to configure non MII-style data
connections, usually to another PHY. For instance, to configure a
TSEC for SGMII, you first configure the attached TBI to communicate
with the on-chip SERDES.
While the TBI devices technically all sit on MDIO busses, only the
TBI PHY connected to the first TSEC will interfere with MDIO
transactions. I don't think we need to create nodes for each of the
TBIs. They exist as a secondary part of the ethernet controller, and
their address is only really important to that controller.
I still think it should just be a property of the ethernet node. We
aren't describing the TBI, we're describing a setting for the
ethernet controller's register.
Andy
From: Joe Hamman <hidden> Date: 2007-08-14 21:01:22
Hi Andy,
quoted
Is any given board going to have at runtime (i.e. not jumper
selectable) both a phy and a tbi (I'm not very familiar with the
latter, so I apologize if this is a dumb question). If not, I'd
stick with phy-handle and have something in the phy node to
indicate that it's tbi.
Yes. That will be the more common case. The TBI PHYs are connected
to the MDIO pins of each TSEC. The TBIPA register defines what
address it sits on. It is used to configure non MII-style data
connections, usually to another PHY. For instance, to configure a
TSEC for SGMII, you first configure the attached TBI to communicate
with the on-chip SERDES.
While the TBI devices technically all sit on MDIO busses, only the
TBI PHY connected to the first TSEC will interfere with MDIO
transactions. I don't think we need to create nodes for each of the
TBIs. They exist as a secondary part of the ethernet controller, and
their address is only really important to that controller.
I still think it should just be a property of the ethernet node. We
aren't describing the TBI, we're describing a setting for the
ethernet controller's register.
Like this? Do we need to have one for each ethernet@xxxxxx?
ethernet@24000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <24000 1000>;
mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <1d 2 1e 2 22 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy1f>;
tbi-address = <0x1e>;
};
Joe
From: Andy Fleming <hidden> Date: 2007-08-14 21:30:13
On Aug 14, 2007, at 16:01, Joe Hamman wrote:
Hi Andy,
quoted
I still think it should just be a property of the ethernet node. We
aren't describing the TBI, we're describing a setting for the
ethernet controller's register.
Like this? Do we need to have one for each ethernet@xxxxxx?
Scott and I have been talking, and right now it seems like a better
idea might be to have the TBI address get assigned dynamically, based
on where PHYs aren't.
It's non-trivial to do (though not difficult), but this way we won't
have to regret creating a bad interface. You just need to look at
the mdio bus, and find out which addresses responded. Then you
create a variable in the gfar_private structure to hold what it gets
set to, and make sure that gfar_configure_serdes uses that value
instead of the TBIPA constant.
Andy
From: Joe Hamman <hidden> Date: 2007-08-14 21:41:28
-----Original Message-----
From: Andy Fleming [mailto:afleming@freescale.com]
Sent: Tuesday, August 14, 2007 4:30 PM
To: joe.hamman@embeddedspecialties.com
Cc: 'Scott Wood'; linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
configurable
On Aug 14, 2007, at 16:01, Joe Hamman wrote:
quoted
Hi Andy,
quoted
I still think it should just be a property of the ethernet node. We
aren't describing the TBI, we're describing a setting for the
ethernet controller's register.
Like this? Do we need to have one for each ethernet@xxxxxx?
Scott and I have been talking, and right now it seems like a better
idea might be to have the TBI address get assigned dynamically, based
on where PHYs aren't.
It's non-trivial to do (though not difficult), but this way we won't
have to regret creating a bad interface. You just need to look at
the mdio bus, and find out which addresses responded. Then you
create a variable in the gfar_private structure to hold what it gets
set to, and make sure that gfar_configure_serdes uses that value
instead of the TBIPA constant.
Sounds like a good plan. I'll try to put something together and post for
comments.
Thanks,
Joe