Print this page
    
MFV: illumos-gate@5bb0bdfe588c5df0f63ff8ac292cd608a5f4492a
9950 Need support for Intel I219 v6-v9
Reviewed by: Jason King <jason.king@joyent.com>
Reviewed by: Garrett D'Amore <garrett@damore.org>
Approved by: Garrett D'Amore <garrett@damore.org>
Author: Robert Mustacchi <rm@joyent.com>
    
      
        | Split | 
	Close | 
      
      | Expand all | 
      | Collapse all | 
    
    
          --- old/usr/src/uts/common/io/e1000api/README.illumos
          +++ new/usr/src/uts/common/io/e1000api/README.illumos
   1    1  #
   2    2  # This file and its contents are supplied under the terms of the
   3    3  # Common Development and Distribution License ("CDDL"), version 1.0.
   4    4  # You may only use this file in accordance with the terms of version
   5    5  # 1.0 of the CDDL.
   6    6  #
   7    7  # A full copy of the text of the CDDL should have accompanied this
   8    8  # source.  A copy of the CDDL is also available via the Internet at
   9    9  # http://www.illumos.org/license/CDDL.
  10   10  #
  11   11  
  12   12  #
  13   13  # Copyright (c) 2013 Joyent, Inc.  All rights reserved.
  14   14  #
  15   15  
  16   16  Historically e1000g and igb were maintained by two different teams at Sun and
  17   17  thus while they used identical common code from Intel, they each only ever used
  18   18  portions of it and were not kept in sync with one another. To help make
  19   19  maintenance and the adding of new devices easier in illumos, we have gone
  20   20  through and made it so that igb and e1000g rely on the same set of common code;
  21   21  however, this code is not in its own module, each has its own copy of the code
  22   22  compiled into it for various reasons which will be laid out below.
  23   23  
  24   24  As part of the interface with the common code, the driver is required to define
  25   25  an e1000_osdep.h. Currently each version of the driver defines its *own* version
  26   26  of this header file in their own driver specific directory. However, the code
  27   27  that implements this is different in each directory, specifically e1000g_osdep.c
  28   28  and igb_osdep.c. It's important that they have different names and not be called
  29   29  the same thing due to how the uts makefiles work.
  30   30  
  31   31  Deviations from the common FreeBSD code:
  32   32  
  33   33  We have a few differences from the common version of the FreeBSD code that exist
  34   34  so that we can both gather firmware information and that have workarounds for
  35   35  older chipsets. While, we would like to get that to be synced up and common, it
  36   36  is not currently.
  37   37  
  
    | 
      ↓ open down ↓ | 
    37 lines elided | 
    
      ↑ open up ↑ | 
  
  38   38  Energy Efficient Ethernet (EEE) is not enabled by default. This technology was
  39   39  introduced with the I350 family of parts in the igb driver. However, there have
  40   40  been issues seen with it in the wild and thus we opt to disable it by default
  41   41  until tests have proven that there are no longer problems.
  42   42  
  43   43  To help make that easier, we've documented here what these extra definitions
  44   44  are. DO NOT just blindly copy over new common code. There is more work that
  45   45  needs to be done in terms of changed interfaces and expectations for the
  46   46  drivers.
  47   47  
       48 +# Support for Ice Lake and Cannon Lake
       49 +
       50 +Due to several changes that have been made to the core e1000 code in
       51 +FreeBSD that's specific to changes for iflib, a whole sale update was
       52 +not done and instead support was manually merged based on Intel.
       53 +
  48   54  # e1000_defines.h
  49   55  
  50   56  In e1000_defines.h we add the following three definitions which are not
  51   57  currently present. These definitions allow us to attach firware revisions and
  52   58  other information to the devinfo tree.
  53   59  
  54   60  #define         NVM_VERSION                     0x0005
  55   61  #define         NVM_OEM_OFFSET_0                6
  56   62  #define         NVM_OEM_OFFSET_1                7
  57   63  
  58   64  # Workarounds for the 82541 and 82547
  59   65  
  60   66  There are various workarounds in place for the 82541 and 82547 due to errata
  61   67  that exist for these devices. This has traditionally been a part of the common
  62   68  code. Until this can get merged into the common code completely, we've spearted
  63   69  out the changes that are the actual C functions into
  64   70  uts/common/io/e1000g/e1000g_workarounds.c. However, this alone is not
  65   71  sufficient. You must make sure that in e1000_hw.h that the struc
  66   72  e1000_dev_spec_82541 actually looks like the following:
  67   73  
  68   74  struct e1000_dev_spec_82541 {
  69   75          enum e1000_dsp_config dsp_config;
  70   76          enum e1000_ffe_config ffe_config;
  71   77          u32 tx_fifo_head;
  72   78          u32 tx_fifo_start;
  73   79          u32 tx_fifo_size;
  74   80          u16 spd_default;
  75   81          bool phy_init_script;
  76   82          bool ttl_workaround;
  77   83  };
  78   84  
  79   85  # EEE
  80   86  
  81   87  By default we disable all support for EEE. To cause this to happen you must
  82   88  make the following change in e1000_82575.c's init_mac_params.
  83   89  
  84   90  From:
  85   91   394         /* Enable EEE default settings for EEE supported devices */
  86   92   395         if (mac->type >= e1000_i350)
  87   93   396                 dev_spec->eee_disable = FALSE;
  88   94  To:
  89   95   394         /* Enable EEE default settings for EEE supported devices */
  90   96   395         if (mac->type >= e1000_i350)
  91   97   396                 dev_spec->eee_disable = TRUE;
  92   98  
  93   99  Future work:
  94  100  
  95  101  The next step here is to take the osdep portions and merge them. That would
  96  102  allow us to build one common misc module e1000api that both igb and e1000g
  97  103  depend on rather than building separate copies of the common code into each
  98  104  driver. Another potential option which may prove to have less value is to take
  99  105  all of the gld and ddi logic and have one driver export that leaving e1000g and
 100  106  igb as small stubs which depend on that. Note however, that the latter is not
 101  107  how our upstream is currently structuring their igb and em (FreeBSD's e1000g)
 102  108  drivers.
  
    | 
      ↓ open down ↓ | 
    45 lines elided | 
    
      ↑ open up ↑ | 
  
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX