1. 23 7月, 2014 1 次提交
  2. 14 5月, 2014 1 次提交
  3. 13 5月, 2014 1 次提交
  4. 11 5月, 2014 1 次提交
  5. 07 5月, 2014 1 次提交
  6. 13 4月, 2014 1 次提交
  7. 13 2月, 2014 1 次提交
  8. 04 2月, 2014 3 次提交
    • A
      iwlwifi: add very first D0i3 support · 98ee7783
      Arik Nemtsov 提交于
      When the bus is in D0i3, we can't send regular commands to
      the firmware. This means that we need to add a state to
      remember what is our d0i3 state and make sure that only
      d0i3 exit commands can be sent.
      Add flags to CMD_ flags and transport status for this
      purpose.
      
      Commands with CMD_HIGH_PRIO set are queued at the head of
      the command queue, behind other high priority commands.
      
      Commands with CMD_SEND_IN_IDLE set can be sent while the
      transport is idle (without taking rpm reference).
      
      Commands with CMD_MAKE_TRANS_IDLE set indicate that command
      completion should mark the transport as idle (and release
      the bus).
      
      Commands with CMD_WAKE_UP_TRANS set instruct the transport
      to exit from idle when this command is completed.
      
      The transport is marked as idle (STATUS_TRANS_IDLE) when
      the FW enters D0i3 state. This bit is cleared when it
      enters D0 state again.
      
      Process only commands with CMD_SEND_IN_IDLE flag while the
      transport is idle. Other enqueued commands will be
      processed only later, right after exiting D0i3.
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      98ee7783
    • E
      iwlwifi: add D0i3 references boiler plate · 440c411d
      Eliad Peller 提交于
      D0i3 is bus power saving feature. It involves the
      firmware - the driver needs to send a list of commands
      to the firmware before entering this state. Wake up from
      d0i3 also requires a few commands to the firmware.
      
      The trigger to enter D0i3 is an idle timeout that will be
      implemented later and will most probably rely on RUNTIME_PM
      infrastructure.
      
      In order to prevent entrance to D0i3 in critical flows, we
      implement here a reference infrastructure. When a ref is
      taken, we can't enter D0i3.
      
      PCIe does't support D0i3.
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      440c411d
    • I
      iwlwifi: pcie: retrieve and parse ACPI power limitations · bcb079a1
      Ido Yariv 提交于
      Some platforms may have power limitations on PCIe cards connected to
      specific root ports.
      
      This information is encoded as part of the ACPI tables, for instance:
      <snip>
                 Name (SPLX, Package (0x02)
                 {
                     Zero,
                     Package (0x03)
                     {
                         0x07,
                         0x00000500,
                         0x80000000
                     }
                 })
      
                 Method (SPLC, 0, Serialized)
                 {
                     Return (SPLX)
                 }
      </snip>
      
      The structure returned contains the domain type, the default power
      limitation and the default time window (reserved for future use).
      
      Upon PCI probing, call the relevant ACPI method, parse the returned
      structure, and save the power limitation.
      Signed-off-by: NIdo Yariv <idox.yariv@intel.com>
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      bcb079a1
  9. 14 1月, 2014 1 次提交
  10. 01 1月, 2014 2 次提交
  11. 18 12月, 2013 6 次提交
  12. 29 10月, 2013 1 次提交
  13. 11 10月, 2013 1 次提交
  14. 02 10月, 2013 1 次提交
  15. 06 8月, 2013 2 次提交
  16. 18 6月, 2013 1 次提交
  17. 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
  18. 17 5月, 2013 2 次提交
  19. 04 4月, 2013 1 次提交
  20. 06 3月, 2013 2 次提交
  21. 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
  22. 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
  23. 01 2月, 2013 2 次提交
  24. 31 1月, 2013 1 次提交
  25. 24 1月, 2013 2 次提交
  26. 16 1月, 2013 1 次提交