1. 02 10月, 2013 1 次提交
  2. 06 8月, 2013 2 次提交
  3. 18 6月, 2013 1 次提交
  4. 30 5月, 2013 1 次提交
    • J
      iwlwifi: mvm: implement D3 testing · debff618
      Johannes Berg 提交于
      For testing the D3 (WoWLAN) firmware, it is useful to be able
      to run the firmware with instrumentation while the host isn't
      sleeping and can poke at the firmware debug logging etc.
      
      Implement this by a debugfs file. When the file is opened the
      D3 firmware is loaded and all regular commands are blocked.
      While the file is being read, poll the firmware's PME status
      flag and report EOF once it changes to non-zero. When it is
      closed, do (most of) the resume processing. This lets a user
      just "cat" the file. Pressing Ctrl-C to kill the cat process
      will resume the firwmare as though the platform resumed for
      non-wireless reason and when the firmware wants to wake up
      reading from the file automatically completes.
      
      Unlike in real suspend, only disable interrupts and don't
      reset the TX/RX hardware while in the test mode. This is a
      workaround for some interrupt problems that happen only when
      the PCIe link isn't fully reset (presumably by changing the
      PCI config space registers which the core PCI code does.)
      
      Note that while regular operations are blocked from sending
      commands to the firmware, they could still be made and cause
      strange mac80211 issues. Therefore, while using this testing
      feature you need to be careful to not try to disconnect, roam
      or similar, and will see warnings for such attempts.
      
      Als note that this requires an upcoming firmware change to
      tell the driver the location of the PME status flag in SRAM.
      D3 test will fail if the firmware doesn't report the pointer.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      debff618
  5. 17 5月, 2013 2 次提交
  6. 04 4月, 2013 1 次提交
  7. 06 3月, 2013 2 次提交
  8. 28 2月, 2013 2 次提交
    • J
      iwlwifi: use coherent DMA memory for command header · 38c0f334
      Johannes Berg 提交于
      Recently in commit 8a964f44
      ("iwlwifi: always copy first 16 bytes of commands") we fixed
      the problem that the hardware writes back to the command and
      that could overwrite parts of the data that was still needed
      and would thus be corrupted.
      
      Investigating this problem more closely we found that this
      write-back isn't really ordered very well with respect to
      other DMA traffic. Therefore, it sometimes happened that the
      write-back occurred after unmapping the command again which
      is clearly an issue and could corrupt the next allocation
      that goes to that spot, or (better) cause IOMMU faults.
      
      To fix this, allocate coherent memory for the first 16 bytes
      of each command, containing the write-back part, and use it
      for all queues. All the dynamic DMA mappings only need to be
      TO_DEVICE then. This ensures that even when the write-back
      happens "too late" it can't hit memory that has been freed
      or a mapping that doesn't exist any more.
      
      Since now the actual command is no longer modified, we can
      also remove CMD_WANT_HCMD and get rid of the DMA sync that
      was necessary to update the scratch pointer.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      38c0f334
    • J
      iwlwifi: rename IWL_MAX_CMD_TFDS to IWL_MAX_CMD_TBS_PER_TFD · 1afbfb60
      Johannes Berg 提交于
      The IWL_MAX_CMD_TFDS name for this constant is wrong, the
      constant really indicates how many TBs we can use in the
      driver for a single command TFD, rename the constant and
      also add a comment explaining it.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1afbfb60
  9. 05 2月, 2013 1 次提交
    • J
      iwlwifi: use threaded interrupt handler · 2bfb5092
      Johannes Berg 提交于
      With new transports coming up, move to threaded
      interrupt handling now. This has the advantage
      that we can use the same locking scheme with all
      different transports we may need to implement.
      
      Note that the TX path obviously still runs in a
      tasklet, so some spin_lock() calls need to change
      to spin_lock_bh() calls to properly lock out the
      TX path.
      
      In my test on a Calpella platform this has no
      impact on throughput or latency.
      
      Also add lockdep annotations to avoid lockups due
      to catch sending synchronous commands or using
      locks that connect with them from the irq thread.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2bfb5092
  10. 01 2月, 2013 2 次提交
  11. 31 1月, 2013 1 次提交
  12. 24 1月, 2013 2 次提交
  13. 16 1月, 2013 2 次提交
  14. 03 1月, 2013 5 次提交
  15. 07 12月, 2012 1 次提交
  16. 28 11月, 2012 1 次提交
  17. 05 11月, 2012 1 次提交
  18. 01 11月, 2012 1 次提交
    • E
      iwlwifi: handle RFKILL logic in the transport layer · f946b529
      Emmanuel Grumbach 提交于
      No HCMD can be sent while RFKILL is asserted. If a SYNC
      command is running while RFKILL is asserted the fw will
      silently discard it. This means that the driver needs to
      wake the process that sleeps on the CMD_SYNC.
      
      Since the RFKILL interrupt is handled in the transport layer
      and the code that sleeps in CMD_SYNC is also in the transport
      layer, all this logic can be handled there.
      This simplifies the work of the op_mode.
      
      So the transport layer will now return -ERFKILL when a CMD
      is sent and RFKILL is asserted. This will be the case even
      when the CMD is SYNC. The transport layer will return
      -ERFKILL straight away.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f946b529
  19. 29 10月, 2012 2 次提交
  20. 16 10月, 2012 1 次提交
    • J
      iwlwifi: make data frame tracing optional · f042c2eb
      Johannes Berg 提交于
      When tracing in iwlwifi, we get all data. Most of
      the time, we don't need it, and it just takes up
      a lot of extra space in the trace.
      
      Make this optional by recording the data into two
      separate trace events if it is needed. Without it,
      record only the content of non-data and EAPOL TX
      frames.
      
      As a result, tracing without the data tracepoints
      will record meta information including the 802.11
      headers for all frames but will not record the
      contents of data frames to reduce trace overhead.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f042c2eb
  21. 26 7月, 2012 2 次提交
    • E
      iwlwifi: get the correct HCMD in the response handler · 96791422
      Emmanuel Grumbach 提交于
      Until now, the response handler of a Host Command got the
      exact same pointer that was also given to the DMA engine.
      We almost never need to the Host Command that was sent while
      handling its response, but when we do need it, we see that
      the command has been modified.
      
      This mystery has been elucidated. The FH (our DMA engine)
      writes its meta data on the buffer in the DRAM. Of course it
      copies the buffer to the NIC first. This was known to happen
      for Tx command, but as a matter of fact, it happens to all
      TFD brought by the FH which doesn't care much about what it
      brings from DRAM to internal SRAM.
      
      So copy the Host Command to yet another buffer so that we
      can properly pass the buffer that was sent originally to the
      fw. Do that only if it was request by the user since very
      few flows need to get the HCMD sent in the response handler.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      96791422
    • M
      iwlwifi: rework the iwlwifi debugfs structure · 9da987ac
      Meenakshi Venkataraman 提交于
      The generic part of the driver now creates all debugfs
      directories. It creates a root directory directly in
      the the root of the debugfs filesystem and within that
      directories for each device, named after the device ID
      of the devices iwlwifi is attached to.
      
      In the cfg80211/mac80211 directory there's now a link
      to the toplevel iwlwifi debugfs directory to make it
      easier to find the debugfs files.
      Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9da987ac
  22. 12 7月, 2012 1 次提交
  23. 25 6月, 2012 1 次提交
  24. 06 6月, 2012 4 次提交