[U-Boot] [Patch 2/3] Revert "e1000: fix sw fw sync on igb i210/i211"

[Marcel Ziswiler]

On Wed, 2015-05-20 at 06:15 -0700, Tim Harvey wrote:
<snip>
> > Tested on Apalis T30 1GB V1.1A with properly fused i211
> > Tested on Apalis T30 2GB V1.1A with iNVM fused i210
> > Tested on Apalis T30 1GB V1.0A with tools only aka non fused i211
> > Tested-by: Marcel Ziswiler <marcel.ziswiler at toradex.com>
> > ---
> > BTW: Still fails on Apalis T30 2GB V1.0E with tools only aka non fused
> > i210 as follows:
> > e1000: e1000#0: ERROR: Hardware Initialization Failed
> > In our downstream production U-Boot we temporarily hacked this as
> > follows for now:
> > http://git.toradex.com/cgit/u-boot-toradex.git/commit/?h=2015.04-toradex&id=2d8ea651b6da79047b6fa729863d25b5eb9e15d7
> 
> I don't understand your results above. What I'm most interested in is
> if this patch series (adding the proper semaphore release and removing
> your patch that uses the wrong register for i210) resolves the need
> for you having added this particular patch for whatever board you
> needed it for. Is the configuration that was failing for you requiring
> 17da7120249bfdef877f46be5bbcb3cc01212eb9 resolved with this series
> applied?

Yes, exactly.

> When you say it 'still fails on Apalis T30 2GB V1.0E' does that mean
> you have that particular failure both before and after this patch
> series? That would indicate to me there is something more needed
> specifically for that configuration.

Yes, exactly. As once mentioned before Intel actually claims tools only
mode anyway not being operational at all on the other hand the Linux
driver worked just fine for us with each and every such combination.
Unfortunately so far I did not get to tracking this any further.

> I'm also not really clear what you mean by 'properly fused i211' vs
> 'iNVM fused i210' vis 'tools only aka non fused i211'. I believe you
> are referring to if they are programmed parts or not

Yes, exactly. By 'properly fused i211' I mean its iNVM being programmed
as it albeit features no other possibility. The i210 on the other hand
can be used with an external EEPROM or the iNVM so by 'iNVM fused i210'
I mean that I only tested programming the iNVM. I did NOT do any tests
with an external EEPROM and therefore also NOT with any activated
management stuff or the like requiring external firmware therein.

> but I'm not clear
> if all of your configurations are using internal phy or an external
> phy.

Yes, sorry. I forgot to mention this: Our hardware only ever uses the
internal copper PHY.

> Your downstream patch indicates that in your non-working configuration
> the EEMNGCTL.CFG_DONE_P0 bit is not getting set indicating (from the
> datasheet) that the configuration cycle (configuration of SerDes, PHY,
> PCIe and PLLs) is not done for port 0 which very well may be the
> expected behavior on a non-programmed part.

Yes, maybe the Linux driver just ignores this condition resp. I actually
patched it to ignore failing NVM validation:
http://git.toradex.com/cgit/linux-toradex.git/commit/?h=tegra&id=c4c3c7449bdb15c53bfebb0a29c73b24ea810d23

Plus the tools only PCI IDs are anyway missing in Linux:
http://git.toradex.com/cgit/linux-toradex.git/commit/?h=tegra&id=2c7123458270c9b3ec9b5ed668f9d55a7f8dbad9

> The configuration I required this series for was for an i210 with
> internal phy in copper mode. Without this series it would error out
> with 'ERROR: Hardware Initialization Failed' because
> e1000_swfw_sync_acquire() would timeout and return
> -E1000_ERR_SWFW_SYNC.

OK.