1. 03 12月, 2013 1 次提交
    • S
      net: fec_main: dma_map() only the length of the skb · 2488a54e
      Sebastian Siewior 提交于
      On tx submit the driver always dma_map_single() FEC_ENET_TX_FRSIZE (=2048)
      bytes. This works because we don't overwrite any memory after the data buffer,
      we remove it from cache if it was there. So we hurt performace in case the
      mapping of a smaller area makes a difference.
      There is also a bug: If the data area starts shortly before the end of
      RAM say 0xc7fffa10 and the RAM ends at 0xc8000000 then we have enough
      space to fit the data area (according to skb->len) but we would map beyond
      end of ram if we are using 2048. In v2.6.31 (against which kernel this patch
      made) there is the following check in dma_cache_maint():
      
      |BUG_ON(!virt_addr_valid(start) || !virt_addr_valid(start + size - 1));
      
      Since the area starting at 0xc8000000 is no longer virt_addr_valid() we
      BUG() during dma_map_single(). The BUG() statement was removed in v3.5-rc1 as
      per 2dc6a016 ("ARM: dma-mapping: use asm-generic/dma-mapping-common.h").
      
      This patch was tested on v2.6.31 and then forward-ported and compile
      tested only against the net tree. I think it is still worth fixing
      mainline even after the BUG() statement is gone.
      Tested-by: NFugang Duan <B38611@freescale.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NFugang Duan <B38611@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2488a54e
  2. 22 11月, 2013 2 次提交
  3. 15 11月, 2013 1 次提交
    • D
      net:fec: fix WARNING caused by lack of calls to dma_mapping_error() · d842a31f
      Duan Fugang-B38611 提交于
      The driver fails to check the results of DMA mapping and results in
      the following warning: (with kernel config "CONFIG_DMA_API_DEBUG" enable)
      
      ------------[ cut here ]------------
      WARNING: at lib/dma-debug.c:937 check_unmap+0x43c/0x7d8()
      fec 2188000.ethernet: DMA-API: device driver failed to check map
      error[device address=0x00000000383a8040] [size=2048 bytes] [mapped as single]
      
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.17-16827-g9cdb0ba-dirty #188
      [<80013c4c>] (unwind_backtrace+0x0/0xf8) from [<80011704>] (show_stack+0x10/0x14)
      [<80011704>] (show_stack+0x10/0x14) from [<80025614>] (warn_slowpath_common+0x4c/0x6c)
      [<80025614>] (warn_slowpath_common+0x4c/0x6c) from [<800256c8>] (warn_slowpath_fmt+0x30/0x40)
      [<800256c8>] (warn_slowpath_fmt+0x30/0x40) from [<8026bfdc>] (check_unmap+0x43c/0x7d8)
      [<8026bfdc>] (check_unmap+0x43c/0x7d8) from [<8026c584>] (debug_dma_unmap_page+0x6c/0x78)
      [<8026c584>] (debug_dma_unmap_page+0x6c/0x78) from [<8038049c>] (fec_enet_rx_napi+0x254/0x8a8)
      [<8038049c>] (fec_enet_rx_napi+0x254/0x8a8) from [<804dc8c0>] (net_rx_action+0x94/0x160)
      [<804dc8c0>] (net_rx_action+0x94/0x160) from [<8002c758>] (__do_softirq+0xe8/0x1d0)
      [<8002c758>] (__do_softirq+0xe8/0x1d0) from [<8002c8e8>] (do_softirq+0x4c/0x58)
      [<8002c8e8>] (do_softirq+0x4c/0x58) from [<8002cb50>] (irq_exit+0x90/0xc8)
      [<8002cb50>] (irq_exit+0x90/0xc8) from [<8000ea88>] (handle_IRQ+0x3c/0x94)
      [<8000ea88>] (handle_IRQ+0x3c/0x94) from [<8000855c>] (gic_handle_irq+0x28/0x5c)
      [<8000855c>] (gic_handle_irq+0x28/0x5c) from [<8000de00>] (__irq_svc+0x40/0x50)
      Exception stack(0x815a5f38 to 0x815a5f80)
      5f20:                                                       815a5f80 3b9aca00
      5f40: 0fe52383 00000002 0dd8950e 00000002 81e7b080 00000000 00000000 815ac4d8
      5f60: 806032ec 00000000 00000017 815a5f80 80059028 8041fc4c 60000013 ffffffff
      [<8000de00>] (__irq_svc+0x40/0x50) from [<8041fc4c>] (cpuidle_enter_state+0x50/0xf0)
      [<8041fc4c>] (cpuidle_enter_state+0x50/0xf0) from [<8041fd94>] (cpuidle_idle_call+0xa8/0x14c)
      [<8041fd94>] (cpuidle_idle_call+0xa8/0x14c) from [<8000edac>] (arch_cpu_idle+0x10/0x4c)
      [<8000edac>] (arch_cpu_idle+0x10/0x4c) from [<800582f8>] (cpu_startup_entry+0x60/0x130)
      [<800582f8>] (cpu_startup_entry+0x60/0x130) from [<80bc7a48>] (start_kernel+0x2d0/0x328)
      [<80bc7a48>] (start_kernel+0x2d0/0x328) from [<10008074>] (0x10008074)
      ---[ end trace c6edec32436e0042 ]---
      
      Because dma-debug add new interfaces to debug dma mapping errors, pls refer
      to: http://lwn.net/Articles/516640/
      
      After dma mapping, it must call dma_mapping_error() to check mapping error,
      otherwise the map_err_type alway is MAP_ERR_NOT_CHECKED, check_unmap() define
      the mapping is not checked and dump the error msg. So,add dma_mapping_error()
      checking to fix the WARNING
      
      And RX DMA buffers are used repeatedly and the driver copies it into an skb,
      fec_enet_rx() should not map or unmap, use dma_sync_single_for_cpu()/dma_sync_single_for_device()
      instead of dma_map_single()/dma_unmap_single().
      
      There have another potential issue:  fec_enet_rx() passes the DMA address to __va().
      Physical and DMA addresses are *not* the same thing. They may differ if the device
      is behind an IOMMU or bounce buffering was required, or just because there is a fixed
      offset between the device and host physical addresses. Also fix it in this patch.
      
      =============================================
      V2: add net_ratelimit() to limit map err message.
          use dma_sync_single_for_cpu() instead of dma_map_single().
          fix the issue that pass DMA addresses to __va() to get virture address.
      V1: initial send
      =============================================
      Signed-off-by: NFugang Duan <B38611@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d842a31f
  4. 24 10月, 2013 1 次提交
  5. 19 10月, 2013 1 次提交
    • C
      gianfar: Simplify MQ polling to avoid soft lockup · 3ba405db
      Claudiu Manoil 提交于
      Under certain low traffic conditions, the single core
      devices with multiple Rx/Tx queues (MQ mode) may reach
      soft lockup due to gfar_poll not returning in proper time.
      The following exception was obtained using iperf on a 100Mbit
      half-duplex link, for a p1010 single core device:
      
      BUG: soft lockup - CPU#0 stuck for 23s! [iperf:2847]
      Modules linked in:
      CPU: 0 PID: 2847 Comm: iperf Not tainted 3.12.0-rc3 #16
      task: e8bf8000 ti: eeb16000 task.ti: ee646000
      NIP: c0255b6c LR: c0367ae8 CTR: c0461c18
      REGS: eeb17e70 TRAP: 0901   Not tainted  (3.12.0-rc3)
      MSR: 00029000 <CE,EE,ME>  CR: 44228428  XER: 20000000
      
      GPR00: c0367ad4 eeb17f20 e8bf8000 ee01f4b4 00000008 ffffffff ffffffff
      00000000
      GPR08: 000000c0 00000008 000000ff ffffffc0 000193fe
      NIP [c0255b6c] find_next_bit+0xb8/0xc4
      LR [c0367ae8] gfar_poll+0xc8/0x1d8
      Call Trace:
      [eeb17f20] [c0367ad4] gfar_poll+0xb4/0x1d8 (unreliable)
      [eeb17f70] [c0422100] net_rx_action+0xa4/0x158
      [eeb17fa0] [c003ec6c] __do_softirq+0xcc/0x17c
      [eeb17ff0] [c000c28c] call_do_softirq+0x24/0x3c
      [ee647cc0] [c0004660] do_softirq+0x6c/0x94
      [ee647ce0] [c003eb9c] local_bh_enable+0x9c/0xa0
      [ee647cf0] [c0454fe8] tcp_prequeue_process+0xa4/0xdc
      [ee647d10] [c0457e44] tcp_recvmsg+0x498/0x96c
      [ee647d80] [c047b630] inet_recvmsg+0x40/0x64
      [ee647da0] [c040ca8c] sock_recvmsg+0x90/0xc0
      [ee647e30] [c040edb8] SyS_recvfrom+0x98/0xfc
      
      To prevent this, the outer while() loop has been removed
      allowing gfar_poll() to return faster even if there's
      still budget left.  Also, there's no need to recompute
      the budget per Rx queue anymore.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ba405db
  6. 10 10月, 2013 4 次提交
  7. 03 10月, 2013 1 次提交
  8. 01 10月, 2013 3 次提交
  9. 24 9月, 2013 1 次提交
  10. 16 9月, 2013 1 次提交
  11. 05 9月, 2013 1 次提交
    • D
      net: fec: fix the error to get the previous BD entry · 36e24e2e
      Duan Fugang-B38611 提交于
      Bug: error to get the previous BD entry. When the current BD
      is the first BD, the previous BD entry must be the last BD,
      not "bdp - 1" in current logic.
      
      V4:
        * Optimize fec_enet_get_nextdesc() for code clean.
          Replace "ex_new_bd - ring_size" with "ex_base".
          Replace "new_bd - ring_size" with "base".
      
      V3:
        * Restore the API name because David suggest to use fec_enet_
          prefix for all function in fec driver.
          So, change next_bd() -> fec_enet_get_nextdesc()
              change pre_bd()  -> fec_enet_get_prevdesc()
        * Reduce the two APIs parameters for easy to call.
      
      V2:
        * Add tx_ring_size and rx_ring_size to struct fec_enet_private.
        * Replace api fec_enet_get_nextdesc() with next_bd().
          Replace api fec_enet_get_prevdesc() with pre_bd().
      
        * Move all ring size check logic to next_bd() and pre_bd(), which
          simplifies the code redundancy.
      
      V1:
        * Add BD ring size check to get the previous BD entry in correctly.
      Reviewed-by: NLi Frank <B20596@freescale.com>
      Signed-off-by: NFugang Duan  <B38611@freescale.com>
      Acked-by: NFrank Li <frank.li@freescale.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      36e24e2e
  12. 04 9月, 2013 1 次提交
    • C
      gianfar: Fix reported number of sent bytes to BQL · 50ad076b
      Claudiu Manoil 提交于
      Fix the amount of sent bytes reported to BQL by reporting the
      number of bytes on wire in the xmit routine, and recording that
      value for each skb in order to be correctly confirmed on Tx
      confirmation cleanup.
      
      Reporting skb->len to BQL just before exiting xmit is not correct
      due to possible insertions of TOE block and alignment bytes in the
      skb->data, which are being stripped off by the controller before
      transmission on wire.  This led to mismatch of (incorrectly)
      reported bytes to BQL b/w xmit and Tx confirmation, resulting in
      Tx timeout firing, for the h/w tx timestamping acceleration case.
      
      There's no easy way to obtain the number of bytes on wire in the Tx
      confirmation routine, so skb->cb is used to convey that information
      from xmit to Tx confirmation, for now (as proposed by Eric). Revived
      the currently unused GFAR_CB() construct for that purpose.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50ad076b
  13. 31 8月, 2013 3 次提交
  14. 30 8月, 2013 1 次提交
  15. 23 8月, 2013 2 次提交
  16. 22 8月, 2013 3 次提交
  17. 21 8月, 2013 3 次提交
  18. 14 8月, 2013 1 次提交
    • C
      gianfar: Add flow control support · 23402bdd
      Claudiu Manoil 提交于
      eTSEC has Rx and Tx flow control capabilities that may be enabled
      through MACCFG1[Rx_Flow, Tx_Flow] bits.  These bits must not be set
      however when eTSEC is operated in Half-Duplex mode.  Unfortunately,
      the driver currently sets these bits unconditionally.
      This patch adds the proper handling of the PAUSE frame capability
      register bits by implementing the ethtool -A interface.  When pause
      autoneg is enabled, the controller uses the phy's capability to
      negotiate PAUSE frame settings with the link partner and reconfigures
      its Rx_Flow and Tx_Flow settings to match the capabilities of the
      link partner.  If pause autoneg is off, the PAUSE frame generation
      may be forced manually (ethtool -A).  Flow control is disabled by
      default now.
      This implementation is inspired by the tg3 driver.
      Signed-off-by: NLutz Jaenicke <ljaenicke@innominate.com>
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23402bdd
  19. 06 8月, 2013 2 次提交
    • C
      gianfar: Cleanup TxFCB insertion on xmit · 0d0cffdc
      Claudiu Manoil 提交于
      Cleanup gfar_start_xmit()'s fast path by factoring out "redundant"
      FCB insertion code (repeated gfar_add_fcb() calls and related)
      and by reducing the number of if() clauses (i.e. if(fcb) checks).
      Improve maintainability (e.g. there's less code and easier to read)
      also by introducing do_csum and do_vlan to mark the other 2 Tx TOE
      functionalities, following the same model as do_tstamp.
      fcb_len may also be 0 now, to mark that Tx FCB insertion conditions
      (do_csum, do_vlan, do_tstamp) have not been met.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d0cffdc
    • C
      gianfar: Fix Tx csum generation errata handling · 02d88fb4
      Claudiu Manoil 提交于
      Both [eTSEC76] and [eTSEC12] errata relate to Tx checksum generation
      (for some MPC83xx and MCP8548 older revisions). They require the same
      workaround: manual checksum computation and insertion, and disabling
      the H/W Tx csum acceleration feature (per frame) through Tx FCB
      (Frame Control Block) csum offload settings.
      
      The workaround for [eTSEC76] needs to be fixed because it currently
      fails to disable H/W Tx csum insertion via FCB. This patch fixes it
      and provides a common workaround implementation for both Tx csum errata.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02d88fb4
  20. 02 8月, 2013 1 次提交
  21. 31 7月, 2013 1 次提交
  22. 28 7月, 2013 1 次提交
    • F
      net: fec: workaround stop tx during errata ERR006358 · 03191656
      Frank Li 提交于
      If the ready bit in the transmit buffer descriptor (TxBD[R])
      is previously detected as not set during a prior frame transmission,
      then the ENET_TDAR[TDAR] bit is cleared at a later time, even if
      additional TxBDs were added to the ring and the ENET_TDAR[TDAR]
      bit is set. This results in frames not being transmitted until
      there is a 0-to-1 transition on ENET_TDAR[TDAR].
      
      Workarounds:
      code can use the transmit frame interrupt flag (ENET_EIR[TXF])
      as a method to detect whether the ENET has completed transmission
      and the ENET_TDAR[TDAR] has been cleared. If ENET_TDAR[TDAR] is
      detected as cleared when packets are queued and waiting for transmit,
      then a write to the TDAR bit will restart TxBD processing.
      
      This case main happen when loading is light. A ethernet package may
      not send out utile next package put into tx queue.
      
      How to test:
      while [ true ]
      do
      	ping <IP> -s 10000 -w 4
      	ping <IP> -s 6000 -w 2
      	ping <IP> -s 4000 -w 2
      	ping <IP> -s 10000 -w 2
      done
      
      You will see below result in overnight test.
      
      6008 bytes from 10.192.242.116: seq=1 ttl=128 time=0.722 ms
      4008 bytes from 10.192.242.116: seq=0 ttl=128 time=1001.008 ms
      4008 bytes from 10.192.242.116: seq=1 ttl=128 time=1.010 ms
      10008 bytes from 10.192.242.116: seq=0 ttl=128 time=0.896 ms
      
      After apply this patch, >1000ms delay disappear.
      Signed-off-by: NFrank Li <Frank.Li@freescale.com>
      Acked-by: NFugang Duan  <B38611@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03191656
  23. 24 7月, 2013 1 次提交
  24. 23 7月, 2013 3 次提交