Message ID | e11ebb162f58089cd5176c713683c9e7f6b2af7c.1413893734.git.marcel@ziswiler.com |
---|---|
State | Accepted |
Delegated to: | Tom Rini |
Headers | show |
On Tue, Oct 21, 2014 at 5:26 AM, Marcel Ziswiler <marcel@ziswiler.com> wrote: > I finally had a look at the datasheet and spotted an additional > register address difference between regular E1000 and i210/i211 chips. > This patch fixes this and now successfully works on programmed > i210/i211 as well as unprogrammed i211. > > Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> > --- > Please note that unprogrammed i210 seem to behave slightly different > and do not assert the CFG_DONE bit in the EEMNGCTL register upon PHY > reset. However if this error condition is ignored then successful data > transfer is possible. Due to the rather hacky nature thereof this is > not addressed by my patch. Hi Marcel, I've never been able to get e1000_swfw_sync_acquire() to not timeout on the boards with i210 devices that I have (IMX6 with 2x i210 programmed as 8086:1533 using int phys). In my case with your patch below as well as York's patch (https://patchwork.ozlabs.org/patch/400628/) I still see failures. The I210_SW_FW_SYNC reg returns swfw_sync=0x03, fwmask=0x20000, and swmask=0x2 which results in: Driver can't access resource, SW_FW_SYNC timeout. Unable to acquire swfw sync Error Resetting the PHY e1000: e1000#0: ERROR: Hardware Initialization Failed I've always had to ignore the return value from e1000_reset() to avoid this issue and use the devices. Any ideas? > > BTW: What about my previous patch this one kind of bases on? > > [PATCH] e1000: add i211 and unprogrammed i210/i211 support I don't have any i211's but I'll see if I can get hold of an unprogrammed i210 to test with. Tim > > drivers/net/e1000.c | 6 ++++-- > drivers/net/e1000.h | 1 + > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c > index b092867..798c8aa 100644 > --- a/drivers/net/e1000.c > +++ b/drivers/net/e1000.c > @@ -1112,7 +1112,10 @@ e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t mask) > if (e1000_get_hw_eeprom_semaphore(hw)) > return -E1000_ERR_SWFW_SYNC; > > - swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC); > + if (hw->mac_type == e1000_igb) > + swfw_sync = E1000_READ_REG(hw, I210_SW_FW_SYNC); > + else > + swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC); > if (!(swfw_sync & (fwmask | swmask))) > break; > > @@ -4429,7 +4432,6 @@ e1000_phy_hw_reset(struct e1000_hw *hw) > > if (hw->mac_type >= e1000_82571) > mdelay(10); > - > } else { > /* Read the Extended Device Control Register, assert the PHY_RESET_DIR > * bit to put the PHY into reset. Then, take it out of reset. > diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h > index b025ecc..6d110eb 100644 > --- a/drivers/net/e1000.h > +++ b/drivers/net/e1000.h > @@ -2497,6 +2497,7 @@ struct e1000_hw { > #define ICH_GFPREG_BASE_MASK 0x1FFF > #define ICH_FLASH_LINEAR_ADDR_MASK 0x00FFFFFF > > +#define E1000_I210_SW_FW_SYNC 0x5B50 /* Software-Firmware Synchronization - RW */ > #define E1000_SW_FW_SYNC 0x05B5C /* Software-Firmware Synchronization - RW */ > > /* SPI EEPROM Status Register */ > -- > 1.9.3 >
On Thu, 2014-10-23 at 01:12 -0700, Tim Harvey wrote: > I've never been able to get e1000_swfw_sync_acquire() to not timeout > on the boards with i210 devices that I have (IMX6 with 2x i210 > programmed as 8086:1533 using int phys). Ah, OK. I see. We do use them in flash less aka iNVM only mode as 8086:157b. > In my case with your patch > below as well as York's patch > (https://patchwork.ozlabs.org/patch/400628/) I still see failures. The > I210_SW_FW_SYNC reg returns swfw_sync=0x03, fwmask=0x20000, and > swmask=0x2 which results in: > > Driver can't access resource, SW_FW_SYNC timeout. > Unable to acquire swfw sync > Error Resetting the PHY > e1000: e1000#0: ERROR: Hardware Initialization Failed As follows my results: unprogrammed i210 01:00.0 - 8086:1531 - Network controller swfw_sync=0x0, fwmask=0x20000, swmask=0x2 e1000: e1000#0: ERROR: Hardware Initialization Failed programmed i210 01:00.0 - 8086:157b - Network controller swfw_sync=0x0, fwmask=0x20000, swmask=0x2 working unprogrammed i211 01:00.0 - 8086:1532 - Network controller swfw_sync=0x0, fwmask=0x20000, swmask=0x2 working programmed i211 01:00.0 - 8086:1539 - Network controller swfw_sync=0x0, fwmask=0x20000, swmask=0x2 working > I've always had to ignore the return value from e1000_reset() to avoid > this issue and use the devices. As mentioned before for me only the unprogrammed i210 gives me grief as it does not assert the CFG_DONE bit in the EEMNGCTL register upon PHY reset. However the e1000_swfw_sync_acquire() always works just fine. > Any ideas? Maybe the flash less aka iNVM only i210 behaves differently. Let me enquire Intel about this as well, I anyway need to ask our rep about the latest eepromARM programming tool as we have an upcoming production lot of a few thousand units arrive any minute now. > I don't have any i211's but I'll see if I can get hold of an > unprogrammed i210 to test with. Sure, would be interesting to see whether yours behave equally.
On Sun, Oct 26, 2014 at 2:57 PM, Marcel Ziswiler <marcel@ziswiler.com> wrote: > On Thu, 2014-10-23 at 01:12 -0700, Tim Harvey wrote: >> I've never been able to get e1000_swfw_sync_acquire() to not timeout >> on the boards with i210 devices that I have (IMX6 with 2x i210 >> programmed as 8086:1533 using int phys). > > Ah, OK. I see. We do use them in flash less aka iNVM only mode as > 8086:157b. > >> In my case with your patch >> below as well as York's patch >> (https://patchwork.ozlabs.org/patch/400628/) I still see failures. The >> I210_SW_FW_SYNC reg returns swfw_sync=0x03, fwmask=0x20000, and >> swmask=0x2 which results in: >> >> Driver can't access resource, SW_FW_SYNC timeout. >> Unable to acquire swfw sync >> Error Resetting the PHY >> e1000: e1000#0: ERROR: Hardware Initialization Failed > > As follows my results: > > unprogrammed i210 > 01:00.0 - 8086:1531 - Network controller > swfw_sync=0x0, fwmask=0x20000, swmask=0x2 > e1000: e1000#0: ERROR: Hardware Initialization Failed > > programmed i210 > 01:00.0 - 8086:157b - Network controller > swfw_sync=0x0, fwmask=0x20000, swmask=0x2 > working > > unprogrammed i211 > 01:00.0 - 8086:1532 - Network controller > swfw_sync=0x0, fwmask=0x20000, swmask=0x2 > working > > programmed i211 > 01:00.0 - 8086:1539 - Network controller > swfw_sync=0x0, fwmask=0x20000, swmask=0x2 > working > Marcel, What is the configuration of your i210 - is it using an external PHY or internal? I noticed in e1000.c SWSM is 0x5B50 which is the same reg your adding in your patch here. I think at least you should fix that (use the register definition already created). It looks like bit0 of SWSM which is set in my case and clear in yours is used as a flag in the driver in a few places and perhaps has nothing to do with hardware state. I'll have to add some debugging to see whats going on. Tim >> I've always had to ignore the return value from e1000_reset() to avoid >> this issue and use the devices. > > As mentioned before for me only the unprogrammed i210 gives me grief as > it does not assert the CFG_DONE bit in the EEMNGCTL register upon PHY > reset. However the e1000_swfw_sync_acquire() always works just fine. > >> Any ideas? > > Maybe the flash less aka iNVM only i210 behaves differently. > > Let me enquire Intel about this as well, I anyway need to ask our rep > about the latest eepromARM programming tool as we have an upcoming > production lot of a few thousand units arrive any minute now. > >> I don't have any i211's but I'll see if I can get hold of an >> unprogrammed i210 to test with. > > Sure, would be interesting to see whether yours behave equally. >
On Tue, Oct 21, 2014 at 02:26:36PM +0200, Marcel Ziswiler wrote: > I finally had a look at the datasheet and spotted an additional > register address difference between regular E1000 and i210/i211 chips. > This patch fixes this and now successfully works on programmed > i210/i211 as well as unprogrammed i211. > > Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Applied to u-boot/master, thanks!
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c index b092867..798c8aa 100644 --- a/drivers/net/e1000.c +++ b/drivers/net/e1000.c @@ -1112,7 +1112,10 @@ e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t mask) if (e1000_get_hw_eeprom_semaphore(hw)) return -E1000_ERR_SWFW_SYNC; - swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC); + if (hw->mac_type == e1000_igb) + swfw_sync = E1000_READ_REG(hw, I210_SW_FW_SYNC); + else + swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC); if (!(swfw_sync & (fwmask | swmask))) break; @@ -4429,7 +4432,6 @@ e1000_phy_hw_reset(struct e1000_hw *hw) if (hw->mac_type >= e1000_82571) mdelay(10); - } else { /* Read the Extended Device Control Register, assert the PHY_RESET_DIR * bit to put the PHY into reset. Then, take it out of reset. diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h index b025ecc..6d110eb 100644 --- a/drivers/net/e1000.h +++ b/drivers/net/e1000.h @@ -2497,6 +2497,7 @@ struct e1000_hw { #define ICH_GFPREG_BASE_MASK 0x1FFF #define ICH_FLASH_LINEAR_ADDR_MASK 0x00FFFFFF +#define E1000_I210_SW_FW_SYNC 0x5B50 /* Software-Firmware Synchronization - RW */ #define E1000_SW_FW_SYNC 0x05B5C /* Software-Firmware Synchronization - RW */ /* SPI EEPROM Status Register */
I finally had a look at the datasheet and spotted an additional register address difference between regular E1000 and i210/i211 chips. This patch fixes this and now successfully works on programmed i210/i211 as well as unprogrammed i211. Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> --- Please note that unprogrammed i210 seem to behave slightly different and do not assert the CFG_DONE bit in the EEMNGCTL register upon PHY reset. However if this error condition is ignored then successful data transfer is possible. Due to the rather hacky nature thereof this is not addressed by my patch. BTW: What about my previous patch this one kind of bases on? [PATCH] e1000: add i211 and unprogrammed i210/i211 support drivers/net/e1000.c | 6 ++++-- drivers/net/e1000.h | 1 + 2 files changed, 5 insertions(+), 2 deletions(-)