1. 14 8月, 2009 8 次提交
    • J
      iwlwifi: automatically adjust sleep level · e312c24c
      Johannes Berg 提交于
      Depending on required latency requested by pm_qos (via mac80211)
      we can automatically adjust the sleep state. Also, mac80211 has
      a user-visible dynamic sleep feature where we are supposed to
      stay awake after sending/receiving frames to better receive
      response frames to our packets, this can be integrated into the
      sleep command.
      
      Currently, and this patch doesn't change that yet, we default
      to using sleep level 1 if PS is enabled. With a module parameter
      to iwlcore, automatic adjustment to changing network latency
      requirements can be enabled -- this isn't yet the default due
      to requiring more testing.
      
      The goal is to enable automatic adjustment and then go into the
      deepest possible sleep state possible depending on the networking
      latency requirements.
      
      This patch does, however, enable IEEE80211_HW_SUPPORTS_DYNAMIC_PS
      to avoid the double-timer (one in software and one in the device)
      when transmitting -- the exact timeout may be ignored but that is
      not of big concern.
      
      Note also that we keep the hard-coded power indices around for
      thermal throttling -- the specification of that calls for using
      the specified power levels. Those can also be selected in debugfs
      to allow easier testing of such parameters.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e312c24c
    • J
      iwlwifi: refactor some thermal throttle code · 3ad3b92a
      Johannes Berg 提交于
      Some of the thermal throttle data structures and code
      are really very intermingled with the sleep (power)
      control code. They really do belong together in a way
      since the thermal throttle code uses powersaving to
      achieve its goal, but it's making it hard to work on
      the powersave code. Split this up to make that easier.
      I've also changed the antenna defines to an enum and
      used the same enum for RX and TX.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3ad3b92a
    • W
      iwlwifi: fix thermal throttling locking problem · a28027cd
      Wey-Yi Guy 提交于
      Move all the thermal throttling functions to background task to make
      sure do not change power and rx chain in interrupt handler.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a28027cd
    • R
      iwlwifi: revert uCode Alive notification with timeout · c03ea162
      Reinette Chatre 提交于
      commit "iwlwifi: uCode Alive notification with timeout" introduced a more
      reliable mechanism for ucode loading. Unfortunately we hit a problem with
      it frequently enough to make a 4965 unusable. The problem can be seen in
      debug log below. What this code attempts is to set runtime ucode up to
      load, start a timer to wait for the alive response from runtime ucode, and
      if it times out it tries again. As can be seen below we receive the alive
      response and wake the waiting task _before_ the tasks starts waiting. The
      task thus times out as the alive response is not received while it is
      waiting for it and it restarts the device. This starts the cycle all over
      again.
      
      [29739.000819] ieee80211 phy0: U iwl_mac_start enter
      [29739.005751] ieee80211 phy0: U iwl_prepare_card_hw iwl_prepare_card_hw enter
      [29739.012798] ieee80211 phy0: U iwl_set_hw_ready hardware ready
      [29739.057200] ieee80211 phy0: U iwl4965_load_bsm Begin load bsm
      [29739.063366] ieee80211 phy0: U iwl4965_verify_bsm Begin verify bsm
      [29739.072485] ieee80211 phy0: U iwl4965_verify_bsm BSM bootstrap uCode image OK
      [29739.079671] ieee80211 phy0: U iwl4965_load_bsm BSM write complete, poll 0 iterations
      [29739.257019] ieee80211 phy0: I iwl_rx_reply_alive Alive ucode status 0x00000001 revision 0x1 0x9
      [29739.260964] ieee80211 phy0: I iwl_rx_reply_alive Initialization Alive received.
      [29739.260964] ieee80211 phy0: U __iwl_up iwlagn is coming up
      [29739.278571] ieee80211 phy0: U iwl_mac_start Start UP work done.
      [29739.284509] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 788
      [29739.292432] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 10312
      [29739.302004] ieee80211 phy0: U iwl_verify_ucode Initialize uCode is good in inst SRAM
      [29739.309746] ieee80211 phy0: U iwl4965_hw_get_temperature Running temperature calibration
      [29739.317833] ieee80211 phy0: U iwl4965_hw_get_temperature Calib values R[1-3]: -36 13522 -13496 R4: -2726
      [29739.327337] ieee80211 phy0: U iwl4965_hw_get_temperature Calibrated temperature: 310K, 37C
      [29739.335598] ieee80211 phy0: U iwl4965_init_alive_start Initialization Alive received.
      [29739.343477] ieee80211 phy0: U iwl4965_set_ucode_ptrs Runtime uCode pointers are set.
      [29739.351283] ieee80211 phy0: I iwl_rx_reply_alive Alive ucode status 0x00000001 revision 0x1 0x0
      [29739.355210] ieee80211 phy0: I iwl_rx_reply_alive Runtime Alive received.
      [29739.366731] iwlagn 0000:03:00.0: Runtime uCode already alive? Waiting for alive anyway
      [29743.284110] iwlagn 0000:03:00.0: START_ALIVE timeout after 4000ms.
      [29743.290337] ieee80211 phy0: U iwl_mac_add_interface enter: type 2
      [29744.364089] iwlagn 0000:03:00.0: Runtime timeout after 5000ms
      [29744.370882] ieee80211 phy0: U iwl_alive_start Runtime Alive received.
      [29744.377347] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 788
      [29744.385287] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 10312
      [29744.393397] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 94720
      [29744.415835] ieee80211 phy0: U iwl_verify_ucode Runtime uCode is good in inst SRAM
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c03ea162
    • W
      iwlwifi: Traffic type and counter for debugFs · 22fdf3c9
      Wey-Yi Guy 提交于
      Break down the traffic type and counter for both Tx and Rx.
      Enhance the tx_statistics and rx_statistics debugfs function and move
      to /sys/kernel/debug/ieee80211/phy0/iwlagn/debug directory to help
      better debugging both driver and uCode related problems.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      22fdf3c9
    • W
      iwlwifi: new debugging feature for dumping data traffic · 20594eb0
      Wey-Yi Guy 提交于
      The traffic buffer will only beallocated and used if either bit 23
      (IWL_DX_TX) or bit 24 (IWL_DL_RX) of "debug" is set;
      example: "debug=0x800000" - log tx data traffic
               "debug=0x1000000" - log rx data traffic
               "debug=0x1800000" - log both tx and rx traffic
      
      The traffic log will store the beginning portion (64 bytes)  of the
      latest 256 of tx and rx packets in the round-robbin buffer for
      debugging,
      user can examine the log through debugfs file.
      
      How to display the current logged tx/rx traffic and txfifo and rxfifo
      read/write point:
      "cat traffic_log" in /sys/kernel/debug/ieee80211/phy0/iwlagn/debug
      directory
      
      By echo "0" to traffic_log file will empty the traffic log buffer and
      reset both tx and rx taffic log index to 0.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      20594eb0
    • W
      iwlwifi: name changed from "fat" to "ht40" · 7aafef1c
      Wey-Yi Guy 提交于
      Rename "fat" to "ht40"
      The term "fat channel" is deprecated in favor of "HT40"
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7aafef1c
    • R
      iwlwifi: re-introduce per device debugging · 3d816c77
      Reinette Chatre 提交于
      Commit "iwlwifi: make debug level more user friendly" cleaned up the
      debug level handling. In doing so it created a single global debug
      level for all devices. Some setups do consits of more that one iwlwifi
      device and in these setups there is a requirement that debug levels
      should be unique per device.
      
      We now re-introduce the per device debugging while maintaining the
      cleanup effort of the previous patch.
      
      The maintain the global debug level and now introduce a per-device debug
      level that will be used if it (the per-device debug level) is set. The
      per-device debug level can be controlled via the debug_level sysfs file
      while the global debug level is controlled by the debug module parameter.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Acked-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3d816c77
  2. 05 8月, 2009 2 次提交
  3. 30 7月, 2009 1 次提交
  4. 28 7月, 2009 5 次提交
  5. 25 7月, 2009 4 次提交
    • R
      iwlwifi: make debug level more user friendly · a562a9dd
      Reinette Chatre 提交于
      * Deprecate the "debug50" module parameter used to obtain
        5000 series and up debugging. Replace it with "debug" module
        parameter to match with original driver and be consistent
        between them. The "debug50" module parameter can still be used,
        except that the module parameter is not writable in keeping
        with its previous state. We currently just mark it as "deprecated"
        and do not have it in the feature-removal-schedule. Some more
        cleanup of module parameters needs to be done and can then be
        entered together.
      
      * Only make "debug" module parameters visible if the driver
        is compiled with CONFIG_IWLWIFI_DEBUG. This will eliminate
        a lot of confusion where users think they have set debug flags
        but yet cannot see any debug output.
      
      * Make module parameters writable. This eliminates the need for the
        "debug_level" sysfs file, which can now also be deprecated and
        added to feature-removal-schedule. This file is in significant
        use though with many iwlwifi documents and text referring users
        to it. We can thus not take its removal lightly and keep it around.
      
      With iwlcore shared between iwlagn and iwl3945 we really do not need
      debug module parameters for each but can instead have one debug
      module parameter for the iwlcore module. The same issue is here as
      with the sysfs file - a lot of iwlwifi documentation and text (like
      bug reports) rely on iwlagn and iwl3945 having this module parameter,
      so changing this to a module parameter of iwlcore will have significant
      impact and we do not do this for that reason.
      
      One consequence of this patch is that if a user is running a system
      with both 3945 and later hardware then the setting of the one module
      parameter will affect the value of the other. The likelihood of this
      seems low - and even if this setup is present it does not seem like an
      issue for both modules to run with the same debug level.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a562a9dd
    • W
      iwlwifi: uCode Alive notification with timeout · 34a66de6
      Wey-Yi Guy 提交于
      Wait for REPLY_ALIVE notification from init and runtime uCode.
      based on the type of REPLY_ALIVE, different status bit will be set to
      wake up the queue:
      STATUS_INIT_UCODE_ALIVE for init uCode
      STATUS_RT_UCODE_ALIVE for runtime uCode.
      
      If timeout, attempt to download the failing uCode image again. This can
      only be done for the init ucode images of all iwlagn devices and the
      runtime ucode image of the 5000 series and up. If there is a problem
      with the 4965 runtime ucode coming up we restart the interface and thus
      trigger a new download of the init ucode also.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      34a66de6
    • J
      iwlwifi: Handle new firmware file with ucode build number in header · cc0f555d
      Jay Sternberg 提交于
      Adding new API version to account for change to ucode file format.  New
      header includes the build number of the ucode.  This build number is the
      SVN revision thus allowing for exact correlation to the code that
      generated it.
      
      The header adds the build number so that older ucode images can also be
      enhanced to include the build in the future.
      
      some cleanup in iwl_read_ucode needed to ensure old header not used and
      reduce unnecessary references through pointer with the data is already
      in heap variable.
      Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cc0f555d
    • R
      iwlagn: fix minimum number of queues setting · 01a7e084
      Reinette Chatre 提交于
      We need to provide a reasonable minimum that will result in a
      working setup if used. Set minimum to be 10 to provide for
      4 standard TX queues + 1 command queue + 2 (unused) HCCA queues +
      4 HT queues (one per AC).
      
      We allow the user to change the number of queues used via a module
      parameter and use this minimum value to check if it is valid. Without
      this patch a user can select a value for the number of queues that
      will result in a failing setup.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Reviewed-by: NTomas Winkler <tomas.winkler@intel.com>
      Acked-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      01a7e084
  6. 11 7月, 2009 2 次提交
  7. 11 6月, 2009 1 次提交
  8. 04 6月, 2009 1 次提交
  9. 23 5月, 2009 6 次提交
  10. 21 5月, 2009 2 次提交
  11. 12 5月, 2009 2 次提交
  12. 23 4月, 2009 3 次提交
  13. 22 4月, 2009 1 次提交
    • R
      iwlwifi: DMA fixes · df833b1d
      Reinette Chatre 提交于
      A few issues wrt DMA were uncovered when using the driver with swiotlb.
      - driver should not use memory after it has been mapped
      - iwl3945's RX queue management cannot use all of iwlagn because
        the size of the RX buffer is different. Revert back to using
        iwl3945 specific routines that map/unmap memory.
      - no need to "dma_syn_single_range_for_cpu" followed by pci_unmap_single,
        we can just call pci_unmap_single initially
      - only map the memory area that will be used by device. this is especially
        relevant to the mapping of iwl_cmd. we should not map the entire
        structure because the meta data at the beginning of structure contains
        the address to be used later for unmapping. If the address to be used for
        unmapping is stored in mapped data it creates a problem.
      - ensure that _if_ memory needs to be modified after it is mapped that we
        call _sync_single_for_cpu first, and then release it back to device with
        _sync_single_for_device
      - we mapped the wrong length of data for host commands, with mapped length
        differing with length provided to device, fix that.
      
      Thanks to Jason Andryuk <jandryuk@gmail.com> for significant bisecting
      help to find these issues.
      
      This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1964Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Tested-by: NJason Andryuk <jandryuk@gmail.com>
      Tested-by: NBen Gamari <bgamari@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      df833b1d
  14. 28 3月, 2009 1 次提交
    • J
      mac80211/iwlwifi: move virtual A-MDPU queue bookkeeping to iwlwifi · e4e72fb4
      Johannes Berg 提交于
      This patch removes all the virtual A-MPDU-queue bookkeeping from
      mac80211. Curiously, iwlwifi already does its own bookkeeping, so
      it doesn't require much changes except where it needs to handle
      starting and stopping the queues in mac80211.
      
      To handle the queue stop/wake properly, we rewrite the software
      queue number for aggregation frames and internally to iwlwifi keep
      track of the queues that map into the same AC queue, and only talk
      to mac80211 about the AC queue. The implementation requires calling
      two new functions, iwl_stop_queue and iwl_wake_queue instead of the
      mac80211 counterparts.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Reinette Chattre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e4e72fb4
  15. 17 3月, 2009 1 次提交