emac: add bamboo support
Subsystems (2)
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
@@ -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_defstatic struct mii_phy_def *mii_phy_table[] = { &cis8201_phy_def, + &ac104_phy_def, &genmii_phy_def,NULL };
Quoted 6 lines · Matt Porter
Adds support for the Bamboo board phys in the EMAC driver. Please apply.
Signed-off-by Wade Farnsworth <[email protected]>Signed-off-by Matt Porter <[email protected]>
[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
Quoted 10 lines · Eugene Surovegin
Quoted 6 lines · Matt Porter
Adds support for the Bamboo board phys in the EMAC driver. Please apply.
Signed-off-by Wade Farnsworth <[email protected]>Signed-off-by Matt Porter <[email protected]>[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
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