Skip to contentSkip to conversation

emac: add bamboo support

PATCH In review Matt Porter 3 participants 4 messages Jul 27, 2005 – Jul 28, 2005

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 emac: add bamboo support

Adds support for the Bamboo board phys in the EMAC driver. Please apply.

drivers/net/ibm_emac/ibm_emac_phy.c +61 -0
diff -uprN linux-2.6.12/drivers/net/ibm_emac/ibm_emac_phy.c linux-2.6.12-440ep/drivers/net/ibm_emac/ibm_emac_phy.c
@@ -24,6 +24,7 @@
 #include <linux/mii.h>
 #include <linux/ethtool.h>
 #include <linux/delay.h>
+#include <linux/vmalloc.h>
 
 #include "ibm_emac_phy.h"
 
@@ -78,6 +79,45 @@ static int cis8201_init(struct mii_phy *
 	return 0;
 }
 
+#ifdef CONFIG_BAMBOO
+static int ac104_init(struct mii_phy *phy)
+{
+	/*
+	 * SW2 on the Bamboo is used for ethernet configuration and is accessed
+	 * via the CONFIG2 register in the FPGA.  If the ANEG pin is set,
+	 * overwrite the supported features with the settings in SW2.
+	 */
+	u8 *config2_addr, config2_val;
+	config2_addr = ioremap64(BAMBOO_FPGA_CONFIG2_REG_ADDR, 0x8);
+	config2_val = * config2_addr;
+	iounmap(config2_addr);
+	if (BAMBOO_AUTONEGOTIATE(config2_val))
+		return 0;
+	phy->def->features = SUPPORTED_TP | SUPPORTED_MII;
+	if (BAMBOO_FORCE_100Mbps(config2_val)) {
+		phy->speed = SPEED_100;
+		if (BAMBOO_FULL_DUPLEX_EN(config2_val)) {
+			phy->def->features |= SUPPORTED_100baseT_Full;
+			phy->duplex = DUPLEX_FULL;
+		} else {
+			phy->def->features |= SUPPORTED_100baseT_Half;
+			phy->duplex = DUPLEX_HALF;
+		}
+	} else {
+		phy->speed = SPEED_10;
+		if (BAMBOO_FULL_DUPLEX_EN(config2_val)) {
+			phy->def->features |= SUPPORTED_10baseT_Full;
+			phy->duplex = DUPLEX_FULL;
+		} else {
+			phy->def->features |= SUPPORTED_10baseT_Half;
+			phy->duplex = DUPLEX_HALF;
+		}
+	}
+	
+	return 0;
+}
+#endif
+
 static int genmii_setup_aneg(struct mii_phy *phy, u32 advertise)
 {
 	u16 ctl, adv;
@@ -226,6 +266,17 @@ static struct mii_phy_ops cis8201_phy_op
 	read_link:cis8201_read_link
 };
 
+/* AC104 phy ops */
+static struct mii_phy_ops ac104_phy_ops = {
+#ifdef CONFIG_BAMBOO
+	init:ac104_init,
+#endif
+	setup_aneg:genmii_setup_aneg,
+	setup_forced:genmii_setup_forced,
+	poll_link:genmii_poll_link,
+	read_link:genmii_read_link
+};
+
 /* Generic implementation for most 10/100 PHYs */
 static struct mii_phy_ops generic_phy_ops = {
 	setup_aneg:genmii_setup_aneg,
@@ -234,6 +285,15 @@ static struct mii_phy_ops generic_phy_op
 	read_link:genmii_read_link
 };
 
+static struct mii_phy_def ac104_phy_def = {
+	phy_id:0x00225540,
+	phy_id_mask:0x00fffff0,
+	name:"AC104 Ethernet",
+	features:MII_BASIC_FEATURES,
+	magic_aneg:0,
+	ops:&ac104_phy_ops
+};
+
 static struct mii_phy_def cis8201_phy_def = {
 	phy_id:0x000fc410,
 	phy_id_mask:0x000ffff0,
@@ -254,6 +314,7 @@ static struct mii_phy_def genmii_phy_def
 
 static struct mii_phy_def *mii_phy_table[] = {
 	&cis8201_phy_def,
+	&ac104_phy_def,
 	&genmii_phy_def,
 	NULL
 };
#1 lore raw
Quoted 6 lines · Matt Porter

Adds support for the Bamboo board phys in the EMAC driver. Please apply.

[snip]

drivers/net/ibm_emac/ibm_emac_phy.c static int cis8201_init(struct mii_phy * · line 89

Quoted 8 lines
drivers/net/ibm_emac/ibm_emac_phy.c +8 -0
+#ifdef CONFIG_BAMBOO
+static int ac104_init(struct mii_phy *phy)
+{
+	/*
+	 * SW2 on the Bamboo is used for ethernet configuration and is accessed
+	 * via the CONFIG2 register in the FPGA.  If the ANEG pin is set,
+	 * overwrite the supported features with the settings in SW2.
+	 */

I wonder, how this SW2 works. Is it just a way to tell software not to use autoneg and force some settings, or it disables autoneg on hw level (I'm kinda doubt that)?

If this is just some board specific configuration option which doesn't affect this PHY directly, let's drop this stuff completely and always use autoneg, if user wants to force something - he should ethtool.

Signature · 1 line
Eugene
#2 lore raw
Quoted 10 lines · Eugene Surovegin
Quoted 6 lines · Matt Porter

Adds support for the Bamboo board phys in the EMAC driver. Please apply.

[snip]

Quoted 12 lines

drivers/net/ibm_emac/ibm_emac_phy.c static int cis8201_init(struct mii_phy * · line 89

Quoted 8 lines
drivers/net/ibm_emac/ibm_emac_phy.c +8 -0
+#ifdef CONFIG_BAMBOO
+static int ac104_init(struct mii_phy *phy)
+{
+	/*
+	 * SW2 on the Bamboo is used for ethernet configuration and is accessed
+	 * via the CONFIG2 register in the FPGA.  If the ANEG pin is set,
+	 * overwrite the supported features with the settings in SW2.
+	 */

I wonder, how this SW2 works. Is it just a way to tell software not to use autoneg and force some settings, or it disables autoneg on hw level (I'm kinda doubt that)?

Yes, SW2 is completely ignored by the PHY.

Quoted 4 lines

If this is just some board specific configuration option which doesn't affect this PHY directly, let's drop this stuff completely and always use autoneg, if user wants to force something - he should ethtool.

I guess my comment does not explain the real reason for this function. The Rev. 0 Bamboo has improperly biased RJ45 sockets. This causes the PHY to only work at 10 Mbps. One can remove the inductors L17 and L18 from the board to enable 100Mbps, but this also disables 10Mbps. Attempting to bring up ethernet in one of the unavailable speeds causes ethernet to hang until the board is reset. AMCC has no plans to replace the Rev. 0, so there are users that will need some reliable way to determine which speed is available and select that speed at boot.

A previous version of the patch did this by attempting to determine the board rev. If a rev 0 was found, then keep the speed determined by the firmware, since we know that works. Rev 1's would be allowed to use both speeds. The board rev was determined by reading the cpu rev from the PVR. This assumes that all rev 0 boards have rev A cpu's and rev 1 boards have rev B cpu's. I believe you had some reservations about this method.

PIBS uses a similar method to what this patch does. In order to tftpboot using a 10Mbps-enabled rev. 0 the ANEG pin and the Force 100Mbps pin must be disabled. Similarly, the patch will read those same pins and only allow the speed selected. Additionally, the patch reads the Duplex pin and determines which duplex mode is available. The duplex has no bearing on the above bug, so this can be safely removed. However, since we're already determining phy speed using SW2, I think users would expect us to determine the duplex mode in the same manner.

I realize that this departs from what the other boards/phys do in this driver, but we do need some way for the appropriate speed to be selected on the rev. 0 boards. If you know of a better way of doing this please let me know.

-Wade Farnsworth

#3 lore raw
Quoted 1 line · Wade Farnsworth

If you know of a better way of doing this please let me know.

Yes, I do and IIRC told you last time. Make it generic - move all board specific stuff where it belongs - board support files. Add additional field(s) to ocp_func_emac_data which will allow EMAC driver to override PHY modes, the same way we specify PHY id now, for example.

With this approach, we won't have to add another board specific crap to the driver next time hw vendor fuck ups their hw.

Signature · 1 line
Eugene