1. 13 10月, 2017 1 次提交
    • B
      ath10k: fix core PCI suspend when WoWLAN is supported but disabled · 96378bd2
      Brian Norris 提交于
      For devices where the FW supports WoWLAN but user-space has not
      configured it, we don't do any PCI-specific suspend/resume operations,
      because mac80211 doesn't call drv_suspend() when !wowlan. This has
      particularly bad effects for some platforms, because we don't stop the
      power-save timer, and if this timer goes off after the PCI controller
      has suspended the link, Bad Things will happen.
      
      Commit 32faa3f0 ("ath10k: add the PCI PM core suspend/resume ops")
      got some of this right, in that it understood there was a problem on
      non-WoWLAN firmware. But it forgot the $subject case.
      
      Fix this by moving all the PCI driver suspend/resume logic exclusively
      into the driver PM hooks. This shouldn't affect WoWLAN support much
      (this just gets executed later on).
      
      I would just as well kill the entirety of ath10k_hif_suspend(), as it's
      not even implemented on the USB or SDIO drivers. I expect that we don't
      need the callback, except to return "supported" (i.e., 0) or "not
      supported" (i.e., -EOPNOTSUPP).
      
      Fixes: 32faa3f0 ("ath10k: add the PCI PM core suspend/resume ops")
      Fixes: 77258d40 ("ath10k: enable pci soc powersaving")
      Signed-off-by: NBrian Norris <briannorris@chromium.org>
      Cc: Ryan Hsu <ryanhsu@qti.qualcomm.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Michal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      96378bd2
  2. 25 9月, 2017 1 次提交
  3. 01 9月, 2017 2 次提交
    • R
      ath10k: configure and enable the wakeup capability · 393b706c
      Ryan Hsu 提交于
      ACPI will rely on device driver to tell it if the device could support
      wakeup function when system in D3 state.
      
      This has caused some platform can't support remote wakeup correctly,
      because the ACPI wakeup GPE is not enabled, hence registers the .set_wakeup
      callback to handle it if device supports wakeup.
      
      Tested with QCA6174 hw3.0, firmware ('WLAN.RM.4.4.1-00008-QCARMSWP-1')
      Signed-off-by: NRyan Hsu <ryanhsu@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      393b706c
    • R
      ath10k: add the PCI PM core suspend/resume ops · 32faa3f0
      Ryan Hsu 提交于
      The actual PCI suspend/resume in ath10k has been handled in wow.c,
      but in the case of the device doesn't support remote wakeup,
      the .hif_suspend() and .hif_resume() will never be handled.
      
        ath10k_wow_op_suspend()
        {
      	if (WARN_ON(!test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
      		    ar->running_fw->fw_file.fw_features))) {
      		ret = 1;
      		goto exit;
      	}
      
      	....
      
      	ret = ath10k_hif_suspend(ar);
        }
      
      So register the PCI PM core to support the suspend/resume if the device
      doesn't support remote wakeup.
      Signed-off-by: NRyan Hsu <ryanhsu@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      32faa3f0
  4. 31 8月, 2017 3 次提交
  5. 08 8月, 2017 3 次提交
  6. 03 8月, 2017 8 次提交
  7. 06 7月, 2017 4 次提交
  8. 29 6月, 2017 2 次提交
  9. 21 6月, 2017 3 次提交
    • S
      ath10k: set rxnss_override for QCA9888 · 68248349
      Sven Eckelmann 提交于
      QCA9888 supports VHT80 with 2x2. But it only support 1x1 with VHT160 or
      VHT80+80. Inform userspace and the the QCA firmware about that limitation
      whenever VHT80+80 or VHT160 is configured.
      Signed-off-by: NSven Eckelmann <sven.eckelmann@openmesh.com>
      [kvalo@qca.qualcomm.com: use hw_params]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      68248349
    • B
      ath10k: configure rxnss_override for QCA9984 · cc914a55
      Ben Greear 提交于
      QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz.
      
      First, report this to user-space by setting the max-tx-speed
      and max-rx-speed vht capabilities.
      
      Second, if the peer rx-speed is configured, and if we
      are in 160 or 80+80 mode, and the peer rx-speed matches
      the max speed for 2x2 or 1x1 at 160Mhz (long guard interval),
      then use that info to set the peer_bw_rxnss_override appropriately.
      
      Without this, a 9984 firmware will not use 2x2 ratesets when
      transmitting to peer (it will be stuck at 1x1), because
      the firmware would not have configured the rxnss_override.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      [sven.eckelmann@openmesh.com: rebase, cleanup, drop 160Mhz workaround cleanup]
      Signed-off-by: NSven Eckelmann <sven.eckelmann@openmesh.com>
      [kvalo@qca.qualcomm.com: use hw_params, rename the title]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      cc914a55
    • B
      ath10k: use complete VHT chan width for 160MHz workaround · e509e594
      Ben Greear 提交于
      The ath10k firmware doesn't announce its VHT channel width capabilities in
      the vht_cap information from the "service ready event" arguments. The
      driver must therefore check whether the 160MHz short GI bit is set and
      whether the driver still doesn't set the bits for the 160/80+80 MHz
      capabilities.
      
      The two bits for the channel width are a two bit integer and not two
      separate bits which cannot be parsed without the knowledge of the other
      bit. Using IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ (b10..) as a
      mask for this task doesn't make any sense. The correct mask for the VHT
      channel width should be used instead to make this check more readable.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      [sven.eckelmann@openmesh.com: separate 160Mhz workaround cleanup, add commit
       message]
      Signed-off-by: NSven Eckelmann <sven.eckelmann@openmesh.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e509e594
  10. 16 6月, 2017 3 次提交
  11. 01 6月, 2017 5 次提交
  12. 31 5月, 2017 1 次提交
    • A
      ath10k: go back to using dma_alloc_coherent() for firmware scratch memory · 79e68821
      Adrian Chadd 提交于
      This reverts commit b0578865 ("ath10k: do not use coherent memory for
      allocated device memory chunks") in 2015 which converted this allocation from
      dma_map_coherent() to kzalloc() / dma_map_single().
      
      The current problem manifests when using later model NICs with larger
      (>700KiB) scratch spaces in memory.  Although the kzalloc call
      succeeds, the software IOMMU TLB code (via dma_map_single()) panics
      because it can't find 700KiB of linear physmem bounce buffers for DMA.
      Now, this is a bit of a silly failure mode for the dma map API,
      but it's what we currently have to play with.
      
      In these cases, doing kzalloc() works fine, but the dma_map_single()
      call fails.
      
      After chatting with Linus briefly about this, it indeed should be
      using dma_alloc_coherent() for doing larger device memory allocation
      that requires some kind of physical address mapping.
      
      You're not supposed to be using kzalloc and dma_map_* calls for
      large memory regions, and I'm guessing not for long-held mappings
      either.  Typically dma mappings should be temporary for DMA,
      not long held like these.
      
      Now, since hopefully the major annoying underlying problem has also been
      addressed (ie, ath10k is no longer tears down all of these allocations
      and reallocates them every time the vdevs are brought down) fragmentation
      should stop being such a touchy issue.  If it is though, using
      dma_alloc_coherent() use gets us access to the CMB APIs too relatively
      easily and ideally we would be allocating memory early in boot for
      exactly these reasons.
      Signed-off-by: NAdrian Chadd <adrian@FreeBSD.org>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      79e68821
  13. 23 5月, 2017 2 次提交
  14. 04 5月, 2017 2 次提交