1. 01 9月, 2012 1 次提交
  2. 15 5月, 2012 1 次提交
  3. 20 4月, 2012 1 次提交
  4. 05 4月, 2012 5 次提交
    • G
      stmmac: extend CSR Clock Range programming · 18f05d64
      Giuseppe CAVALLARO 提交于
      The CSR Clock Range has been reworked and new macros has
      been added in the platform header to allow the CSR Clock
      Range selection in the GMII Address Register.
      The previous work didn't add the other fields
      that can be used to achieve MDC clock of frequency
      higher than the IEEE 802.3 specified frequency limit
      of 2.5 MHz and program a clock divider of lower value.
      On such platforms, these are used indeed so this patch
      adds them.
      Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18f05d64
    • D
      stmmac: re-work the internal GMAC DMA platf parameters · 8327eb65
      Deepak SIKRI 提交于
      This patch re-works the internal GMAC DMA parameters
      passed from the platform.
      In the past, we only passed the pbl but, with new core,
      other parameters can be passed and are mandatory on some
      platforms.
      
      New parameters are documented in stmmac.txt because this
      patch has an impact for many platforms.
      Signed-off-by: NShiraz Hashim <shiraz.hashim@st.com>
      Signed-off-by: NVikas Manocha <vikas.manocha@st.com>
      Signed-off-by: NDeepak Sikri <deepak.sikri@st.com>
      Hacked-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8327eb65
    • D
      stmmac: Define MDC clock selection macros · faeae3fa
      Deepak SIKRI 提交于
      The patch adds the macros to be used for MDC clock selection. The MDC clock
      frequency is based on scaled system clock, and has to be confined to a range
      of 1-2.5 MHz. Based on the input CSR clock, the scaling factor has to be
      selected.
      The platform specific code will provide the default value of this scaling
      factor, based on the input CSR clock.
      There is an option to set MDC clock higher than the IEEE 802.3 specified
      frequency limit of 2.5 MHz. This applies for the interfacing chips that
      support higher MDC clocks. The resultant higher clock of 12.5 MHz requires
      additional Macros to be defined for the clock divider corresponding to the
      to the following selection.
      -----------------------------------------
      	Selection	MDC Clock
      -----------------------------------------
      	1000 		clk_csr_i/4
      	1001 		clk_csr_i/6
      	1010 		clk_csr_i/8
      	1011 		clk_csr_i/10
      	1100 		clk_csr_i/12
      	1101	 	clk_csr_i/14
      	1110 		clk_csr_i/16
      	1111 		clk_csr_i/18
      
      This support has to be added both in the include file, as well as driver. The
      driver need to program the registers based on the interfacing chips. This would
      be more board specific information and needs to be passed through the platform
      code to the driver. This work would be carried out in the future patch set
      release.
      Signed-off-by: NDeepak Sikri <deepak.sikri@st.com>
      Acked-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      faeae3fa
    • D
      stmmac: Define CSUM offload engine Types · 55f9a4d6
      Deepak SIKRI 提交于
      This patch explicitly defines the CSUM offload engine type which need
      (not mandatory) to be passed from the platform code.
      STMMAC core supports two check sum offload engine types- Type-1 & Type-2.
      Also, there are STMMAC cores that do not have the check sum offload
      capabilities.
      
      The behaviour of Type-1 & Type-2 cores related to provision of checksum
      increases the packet length for Type-1 cores by 2, as the checksum is appended
      at the end of data packet and the same is made accountable in the DMA status.
      The STMMAC cores beyond Version-3.5 provide HW interface registers which allows
      the user to read the HW capabilities, while to support the previous cores the
      information related to HW capabilities has to be provided from the platform
      code.
      
      The Type-1 cores which do not have the HW register interface need this
      information.
      
      This patch also updates the driver's doc.
      Signed-off-by: NDeepak Sikri <deepak.sikri@st.com>
      Hacked-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55f9a4d6
    • S
      stmmac: Allow stmmac to work with other PHY buses(v3). · f142af2e
      Srinivas Kandagatla 提交于
      As stmmac mdio bus name prefix is hardcoded in the driver, this allows
      only phys on stmmac mdio buses to connect, however stmmac should allow
      phys on other mdio buses too.
      
      This patch adds new variable phy_bus_name to plat_stmmacenet_data
      struct to let the BSP decide which phy bus to be used by stmmac driver.
      A typical use-case is to have generic MDIO buses like mdio-gpio on top
      of stmmac.
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
      Acked-by: NFlorian Fainelli <florian@openwrt.org>
      Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f142af2e
  5. 22 7月, 2011 1 次提交
  6. 19 7月, 2011 1 次提交
  7. 04 5月, 2011 1 次提交
  8. 31 3月, 2011 1 次提交
  9. 25 11月, 2010 1 次提交
  10. 25 9月, 2010 1 次提交
  11. 18 9月, 2010 2 次提交
  12. 26 8月, 2010 1 次提交
  13. 14 4月, 2010 1 次提交
    • G
      stmmac: new descriptor field for the driver's platform · e326e850
      Giuseppe CAVALLARO 提交于
      The new enh_desc is used for selecting the enhanced descriptors
      structure. There are several scenarios; some chips (mac10/100
      or gmac) want to use the enhanced descriptors; others want the normal
      ones.
      For example, on ST platforms: MAC10/100 uses the normal desc structure
      and the GMAC uses the enhanced one.
      It can be useful to get this information from the platform.
      This could also be decided at run-time looking at the chip's ID number;
      but it could happen that chips with the same ID want to use different
      descriptor structure.
      Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e326e850
  14. 08 1月, 2010 1 次提交
  15. 24 11月, 2009 1 次提交
  16. 15 10月, 2009 1 次提交
  17. 29 1月, 2008 2 次提交
    • A
      igb: PCI-Express 82575 Gigabit Ethernet driver · 9d5c8243
      Auke Kok 提交于
      We are pleased to announce a new Gigabit Ethernet product and its
      driver to the linux community. This product is the Intel(R) 82575
      Gigabit Ethernet adapter family. Physical adapters will be available
      to the public soon. These adapters come in 2- and 4-port versions
      (copper PHY) currently. Other variants will be available later.
      
      The 82575 chipset supports significantly different features that
      warrant a new driver. The descriptor format is (just like the
      ixgbe driver) different. The device can use multiple MSI-X vectors
      and multiple queues for both send and receive. This allows us to
      optimize some of the driver code specifically as well compared to
      the e1000-supported devices.
      
      This version of the igb driver no lnger uses fake netdevices and
      incorporates napi_struct members for each ring to do the multi-
      queue polling. multi-queue is enabled by default and the driver
      supports NAPI mode only.
      
      All the namespace collisions should be gone in this version too. The
      register macro's have been condensed to improve readability.
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d5c8243
    • A
      ixgbe: Fix copper PHY initialization code · 3957d63d
      Auke Kok 提交于
      While cleaning up the internal API focussing on Fiber and CX4 code
      we found that I had broken the copper PHY initialization code. This
      patch restores the PHY-specific code. This is mostly uninteresting
      since no copper PHY boards are yet available. The changes have been
      tested against Fiber only as I do not even have copper PHY versions
      of 82598 macs.
      
      This change actually cleans up the API code a bit more and we
      lose some initialization code. A few PHY link detection helper
      lines of code have been snuck into this patch, as well as a
      read flush where it was suspected that this might cause issues.
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3957d63d
  18. 11 10月, 2007 1 次提交
    • A
      ixgbe: driver for Intel(R) 82598 PCI-Express 10GbE adapters (v4) · 9a799d71
      Auke Kok 提交于
      This patch adds support for the Intel 82598 PCI-Express 10GbE
      chipset. Devices will be available on the market soon.
      
      This version of the driver is largely the same as the last release:
      
        * Driver uses a single RX and single TX queue, each using 1 MSI-X
        irq vector.
        * Driver runs in NAPI mode only
        * Driver is largely multiqueue-ready (TM)
      
      Changes since 20070803:
        * removed wrappers for hardware functions
        * incorporated e1000e-style HW api reorganization code
        * sparse/checkpatch cleanups, namespace cleanups
        * driver prints out extra debugging information at load time
          identifying adapter board number, mac, phy types
        * removed ixgbe_api.c, ixgbe_api.h, ixgbe_osdep.h
        * driver update to 1.1.18
        * removed ixgbe.txt which contained no useful info anymore
      
      [ Integrated napi_struct changes from Auke as well... -DaveM ]
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a799d71
  19. 28 9月, 2006 1 次提交
  20. 17 8月, 2006 1 次提交
  21. 27 5月, 2006 1 次提交
  22. 24 5月, 2006 1 次提交
  23. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4