summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/ath10k/hw.h
AgeCommit message (Collapse)Author
2017-12-27ath10k: Add hw param for 64-bit address supportRakesh Pillai
WCN3990 target supports 37-bit addressing mode. In order to accommodate extended address support, add hw param to indicate if the target supports addressing above 32-bits. Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com> Signed-off-by: Govind Singh <govinds@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-14ath10k: wmi: add hw params entry for wcn3990Rakesh Pillai
Add hw params entry for wcn3990 and populate various target specific values for wcn3990. Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com> Signed-off-by: Govind Singh <govinds@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-14ath10k: wmi: get wmi init parameter values from hw paramsRakesh Pillai
The parameter values for skid limit, number of peers and wds entries values which are sent in wmi init cmd are hardware specific. Add support to obtain skid limit, number of peers and wds entries values from hw params which will have the hw specific values for these parameters. Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com> Signed-off-by: Govind Singh <govinds@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-10-13ath10k: add new cipher suite supportRajkumar Manoharan
QCA99x0 and QCA4019 family chips support CCMP-256, GCMP-128, and GCMP-256 ciphers in hardware, so advertise support for these. As firmware does not support group management frame ciphers (BIP), handle them in software (mac80211). Reviewed-by: Sebastian Gottschall <s.gottschall@dd-wrt.com> Cc: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-09-25ath10k: make ath10k_hw_ce_regs constBhumika Goyal
Make them const as they are not modified in the file referencing them. They are only stored in the const field 'hw_ce_reg' of an ath10k structure. Also, make the declarations in the header const. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-08-03ath10k: add tdls support for 10.4 firmwaresManikanta Pubbisetty
This patch adds the support of TDLS feature for 10.4 firmware versions. A new WMI service is added to advertise the support of TDLS for 10.4 firmwares. Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-07-06ath10k: add copy engine register MAP for wcn3990 targetGovind Singh
Copy engine is a host to target communication interface between wlan firmware and wlan wcn3990 platform driver. Add copy engine register map for wcn3990 wlan module. This add support for the copy engine source/destination ring configuration for wcn3990 chipset. Signed-off-by: Govind Singh <govinds@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-06-21ath10k: configure rxnss_override for QCA9984Ben 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: Ben Greear <greearb@candelatech.com> [sven.eckelmann@openmesh.com: rebase, cleanup, drop 160Mhz workaround cleanup] Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [kvalo@qca.qualcomm.com: use hw_params, rename the title] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-06-16ath10k: define structures for CE ctrl/misc registerSarada Prasanna Garnayak
Define structures for the copy engine ctrl/misc registers, that includes CE CMD halt, watermark source, watermark destination, host IE ring, source, destination and dmax ring. This adds support to avoid the conditional compilation, code optimization and dynamic configuration of the copy engine register map for respective hardware bus interface. Signed-off-by: Sarada Prasanna Garnayak <c_sgarna@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-05-04ath10k: various sdio related definitionsErik Stromdahl
Debug masks for SDIO HIF layer. Address definitions for SDIO/mbox based chipsets. Augmented struct host_interest with more members. Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-04-19ath10k: bump up FW API to 6Ryan Hsu
For QCA6174 hw3.0, since WLAN.RM.4.4-00022-QCARMSWPZ-2, it starts to support the board ID information from otp, with some devices released on the market that didn't calibrated with OTP, will have 0 for board ID information, which cause the backward compatibility issue and was fixed in commit 'd2e202c06ca4 ("ath10k: ignore configuring the incorrect board_id")' So bump the fw api version to differentiate the latest firmware support. Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-04-19ath10k: fix spectral scan for QCA99X0 family of chipsetsMohammed Shafi Shajakhan
spectral_bin length (number of bins per fft sample) is usually a value where (2^n = value), n is an integer. All of the QCA99X0 family of chipsets seems to report a spectral_bin length of 2^n + 'm' bytes, where m = 4, 12 based on the chipset. This 'm' bytes seems to carry some radar related info which is currently discarded only for 'bin_len = 68' bytes. Extend this discarding of irrelevant 'bin_len' for QCA9984, QCA9888, IPQ4019 as well by introducing a hardware parameter 'spectral_bin_discard'. Also for QCA988X based family of chipsets which doesn't seem to have this issue and also for some of the hardware which I have not tested like QCA6174/QCA9377 the existing behaviour is retained as it is. Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-04-05ath10k: clean header files from bad block commentsMarcin Rokicki
Fix output from checkpatch.pl like: Block comments use a trailing */ on a separate line Signed-off-by: Marcin Rokicki <marcin.rokicki@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-03-09ath10k: improve the firmware download time for QCA6174Ryan Hsu
Len Brown reported the system resume time is taking more than 2 seconds in bug - https://bugzilla.kernel.org/show_bug.cgi?id=185621. The reason of the 2 seconds is due to the firmware download time. The chip is booted up in the default reference clock speed to handle the firmware download to chip memory and advanced to the support higher speed clock to run the firmware after all. The default reference clock in the hardware is slow so that the firmware download time is taking up to 2 seconds for a 600KB firmware file. [76796.349701] ath10k_pci : boot uploading firmware image len 688691 [76798.334612] ath10k_pci : htt tx max num pending tx 1056 The resolution here is to enable the higher speed clock if the hardware supported before the firmware download at BMI stage, so that the hardware can handle the firmare download in a more efficient way. This can help to improve the firmware download time from 2 seconds to around 500ms for the same 600KB firmware file. [322858.577919] ath10k_pci boot uploading firmware image len 688691 [322859.093094] ath10k_pci htt tx max num pending tx 1056 The steps to advance to the higher speed clock is very hardware specific, so adding the hardware ops for the hardware that can support this. Reported-by: Len Brown <lenb@kernel.org> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-02-14ath10k: fetch firmware images in a loopErik Stromdahl
To make it easier to handle minimum and maximum firmware API numbers convert the firmware fetch functionality to a loop. If no firmware image is found print an error with minimum and maximum API numbers and the name of firmware directory. This is needed when we switch to using request_firmware_direct() which doesn't print any errors anymore. Also add a new function for creating the fw file name dynamically which makes it easier to add new bus support, for example SDIO and USB, later. Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> [kvalo@qca.qualcomm.com: remove sdio/usb part, new error message, clarify commit log] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-19ath10k: dump Copy Engine registers during firmware crashMohammed Shafi Shajakhan
Dump Copy Engine source and destination ring addresses. This is useful information to debug firmware crashes, assertes or hangs over long run assessing the Copy Engine Register status. This also enables dumping CE register status in debugfs Crash Dump file. Screenshot: ath10k_pci 0000:02:00.0: simulating hard firmware crash ath10k_pci 0000:02:00.0: firmware crashed! (uuid 84901ff5-d33c-456e-93ee-0165dea643cf) ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000 ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1 ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498 ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 ath10k_pci 0000:02:00.0: firmware register dump: ath10k_pci 0000:02:00.0: [00]: 0x4100016C 0x00000000 0x009A0F2A 0x00000000 ath10k_pci 0000:02:00.0: [04]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [08]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [12]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [16]: 0x00000000 0x00000000 0x00000000 0x009A0F2A ath10k_pci 0000:02:00.0: [20]: 0x00000000 0x00401930 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [24]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [28]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [32]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [36]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [40]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [44]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [48]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [52]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [56]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: Copy Engine register dump: ath10k_pci 0000:02:00.0: [00]: 0x00057400 7 7 3 3 ath10k_pci 0000:02:00.0: [01]: 0x00057800 18 18 85 86 ath10k_pci 0000:02:00.0: [02]: 0x00057c00 49 49 48 49 ath10k_pci 0000:02:00.0: [03]: 0x00058000 16 16 17 16 ath10k_pci 0000:02:00.0: [04]: 0x00058400 4 4 44 4 ath10k_pci 0000:02:00.0: [05]: 0x00058800 12 12 11 12 ath10k_pci 0000:02:00.0: [06]: 0x00058c00 3 3 3 3 ath10k_pci 0000:02:00.0: [07]: 0x00059000 0 0 0 0 ieee80211 phy0: Hardware restart was requested ath10k_pci 0000:02:00.0: device successfully recovered Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> [kvalo@qca.qualcomm.com: simplify the implementation] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-29ath10k: decrease num of peers supportBartosz Markowski
The correct number for QCA9377 chip is 33 VDEVs. This impacts also QCA6174 chip and it's max VDEV number. Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-10-04ath10k: allow setting coverage classBenjamin Berg
Unfortunately ath10k does not generally allow modifying the coverage class with the stock firmware and Qualcomm has so far refused to implement this feature so that it can be properly supported in ath10k. If we however know the registers that need to be modified for proper operation with a higher coverage class, then we can do these modifications from the driver. This is a hack and might cause subtle problems but as it's not enabled by default (only when user space changes the coverage class explicitly) it should not cause new problems for existing setups. But still this should be considered as an experimental feature and used with caution. This patch implements the support for first generation cards (QCA9880, QCA9887 and so on) which are based on a core that is similar to ath9k. The registers are modified in place and need to be re-written every time the firmware sets them. To achieve this the register status is verified after certain WMI events from the firmware. The coverage class may not be modified temporarily right after the card re-initializes the registers. This is for example the case during scanning. Thanks to Sebastian Gottschall <s.gottschall@dd-wrt.com> for initially working on a userspace support for this. This patch wouldn't have been possible without this documentation. Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-09-27ath10k: fix rfc1042 header retrieval in QCA4019 with eth decap modeVasanthakumar Thiagarajan
Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future) rx_hdr_status is not padded to align in 4-byte boundary. Define a new hw_params field to handle different alignment behaviour between different hw. This patch fixes improper retrieval of rfc1042 header with QCA4019. This patch along with "ath10k: Properly remove padding from the start of rx payload" will fix traffic failure in ethernet decap mode for QCA4019. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-09-27ath10k: spelling and miscellaneous neateningJoe Perches
Correct some trivial comment typos. Remove unnecessary parentheses in a long line. Signed-off-by: Joe Perches <joe@perches.com> [kvalo@qca.qualcomm.com: drop the change for return] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-09-13ath10k: remove 4-addr padding related hw_param configurationVasanthakumar Thiagarajan
hw_4addr_pad was added to handle different types of padding in 4-address rx frame. But this padding is not very specific to 4-address, it can happen even with three address + ethernet decap mode. Since the padding information can be obtained through Rx desc for QCA99X0 and newer chips, this hw_param is not needed any more. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-09-13ath10k: properly remove padding from the start of rx payloadVasanthakumar Thiagarajan
In QCA99X0 (QCA99X0, QCA9984, QCA9888 and QCA4019) family chips, hw adds padding at the begining of the rx payload to make L3 header 4-byte aligned. In the chips doing this type of padding, the number of bytes padded will be indicated through msdu_end:info1. Define a hw_rx_desc_ops wrapper to retrieve the number of padded bytes and use this while doing undecap. This should fix padding related issues with ethernt decap format with QCA99X0, QCA9984, QCA9888 and QCA4019 hw. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> [Rename operations to hw_ops for other purposes] Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-09-13ath10k: add provision for Rx descriptor abstractionVasanthakumar Thiagarajan
There are slight differences in Rx hw descriptor information among different chips. So far driver does not use those new information for any functionalities, but there is one important information which is available from QCA99X0 onwards to indicate the number of bytes that hw padded at the begining of the rx payload and this information is needed to undecap the rx packet. Add an abstraction for Rx desc to make use of the new desc information available. The callback that this patch defines to retrieve the padding bytes will be used in follow-up patch. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> [Rename operations to hw_ops for other purposes] Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-09-13ath10k: move ath10k_hw_params definition to hw.hVasanthakumar Thiagarajan
This is to prepare for rx descriptor abstraction where we'll be dereferencing ath10k_hw_params member in hw.h. Moreover hw.h looks more suitable to house ath10k_hw_params definition than core.h Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-07-08ath10k: enable support for QCA9888Anilkumar Kolli
QCA9888 shares the same configuration with QCA99X0 with NSS=2. Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-07-08ath10k: remove unused member in ath10k_hw_regsAnilkumar Kolli
rtc_state_cold_reset_mask is unused in ath10k_hw_regs. instead fixed delays are used. Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-07-08ath10k: simplify pktlog htt event processingAshok Raj Nagarajan
It is expected that all pktlog events for 10.4 firmware based solutions should come through CE8 where as in case of 10.2 firmware based solutions, it should come through one of the HTT events (HTT_T2H_MSG_TYPE_PKTLOG). But from experiments with 10.4 based solutions, it is observed that pktlog event for ATH_PKTLOG_TYPE_TX_MSDU_ID is coming through HTT pktlog event. Currently, we always parse with 10.2 pktlog header which will lead to pktlog decoding issues (payload length mismatch exceptions) For trace points, it is required to provide only the payload size. So fixing this by simplifying the payload size calculation without the use of ath10k pktlog headers. While there, remove the unused ath10k pktlog headers. Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-06-14ath10k: fix cycle counter wraparound handling for QCA4019Vasanthakumar Thiagarajan
In QCA4019, cycle counter wraparound is not tied to rx clear counter. Each counter would wraparound individually and after wraparound the respective counter will be reset to 0x7fffffff while other counter still running unaffected. Define a new wraparound type for this behaviour and handle it separately so that rx clear counter wraparound is also handled just like cycle counter. With this type of wraparound we can accurately compute and report channel active/busy time when any of the counter overflows. Fixes: ee9ca147c59 ("ath10k: Fix survey reporting with QCA4019") Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-06-14ath10k: define an enum to enable cycle counter wraparound logicVasanthakumar Thiagarajan
QCA988X hw implements a different cycle counter wraparound behaviour when compared to QCA4019. To properly handle different wraparound logic for these chipsets replace already available bool hw_params member, has_shifted_cc_wraparound, with an enum which could be extended to handle different wraparound behaviour. This patch keeps the existing logic functionally same and a prepares cycle counter wraparound handling to extend for other chips. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> [kvalo@qca.qualcomm.com: change also QCA9887 wrap type] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-06-14ath10k: fix CCK h/w rates for QCA99X0 and newer chipsetsMohammed Shafi Shajakhan
CCK hardware table mapping from QCA99X0 onwards got revised. The CCK hardware rate values are in a proper order wrt. to rate and preamble as below ATH10K_HW_RATE_REV2_CCK_LP_1M = 1, ATH10K_HW_RATE_REV2_CCK_LP_2M = 2, ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3, ATH10K_HW_RATE_REV2_CCK_LP_11M = 4, ATH10K_HW_RATE_REV2_CCK_SP_2M = 5, ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6, ATH10K_HW_RATE_REV2_CCK_SP_11M = 7, This results in reporting of rx frames (with CCK rates) totally wrong for QCA99X0, QCA4019. Fix this by having separate CCK rate table for these chipsets with rev2 suffix and registering the correct rate mapping to mac80211 based on the new hw_param (introduced) 'cck_rate_map_rev2' which shall be true for any newchipsets from QCA99X0 onwards Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-06-07ath10k: add board data download from targetSven Eckelmann
The QCA9887 stores its calibration data (board.bin) inside the EEPROM of the target. This has to be downloaded manually to allow the device to initialize correctly. Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com> [kvalo@qca.qualcomm.com: handle -EOPNOTSUPP and s/fetch_board_data/fetch_cal_eeprom] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-06-07ath10k: add QCA9887 chipset supportSven Eckelmann
Add the hardware name, revision, firmware names and update the pci_id table. QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about he firmware interface are currently unknown. Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com> [kvalo@qca.qualcomm.com: add a warning about experimental support] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-05-24ath10k: enable support for QCA9984Vasanthakumar Thiagarajan
QCA9984 shares the same configuration with QCA99X0. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-04-20ath10k: remove deprecated firmware API 1 supportKalle Valo
This has ben deprecated years ago, I haven't heard anyone using it since and most likely it won't even work anymore. So just remove all of it. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-23ath10k: move cal data len to hw_paramsRaja Mani
ath10k_download_cal_dt() compares obtained cal data content length against QCA988X_CAL_DATA_LEN (2116 bytes). It was written by keeping qca988x in mind. In fact, cal data length is more chip specific. To make ath10k_download_cal_dt() more generic and reusable for other chipsets (like qca4019), cal data length is moved to hw_params. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-06ath10k: change htt tx desc/qcache peer limit configMichal Kazior
The number of HTT Tx descriptors and qcache peer limit aren't hw-specific. In fact they are firmware specific and should not be placed in hw_params. The QCA4019 limits were submitted with the peer flow control firmware only and to my understanding there's no non-peer-flow-ctrl QCA4019 firmware. However QCA99X0 is planned to run firmware supporting the feature as well. Therefore this patch enables QCA99X0 to use 2500 tx descriptors whenever possible instead of just 1424. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-03-03ath10k: reduce number of peers to support peer stats featureAnilkumar Kolli
To enable per peer stats feature we are reducing the number of peers. Firmware has introduced tx stats feature. We have memory limitation in firmware to add these additional bytes. These are the new variables introduced in the firmware. ======== ======================= Variable Bytes required/per rate ======== ======================= TX success packets 1 TX failed packets 1 Retry packets 1 Success bytes 2 TX failed bytes 2 Retry bytes 2 Tx duration 4 Rate 1 Bw and AMPDU flags 1 Total 16 (because of allocation in word pattern) Firmware sends these tx_stats in pktlog. If we consider 4 feedbacks at a time, Frimware need about ~1K memory for coding and 8192 bytes required / per rate [ 4*16*128(peers)]. To accommodate this firmware needs to reduce 10 peers. This fixes a firmware crash with firmware-5.bin_10.2.4.70.22-2. Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-02-02ath10k: populate qca4019 fw specific wmi init paramsRaja Mani
Some of the parameter like tx/rx chain mask, number of htt tx desc, qcache active peer count, etc goes via wmi init cmd to qca4019 firmware are different. To make use of 10.4 gen_init function for qca4019, change wmi service ready handler and 10.4 wmi init functions to adapt qca4019 specific init values. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-02-02ath10k: add qca4019 hw paramsRaja Mani
Add a new entry in hw_params_list for qca4019 with list of it's own details. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-01-28ath10k: expose hif ops for ahbRaja Mani
Like how pci.c exposes hif ops for the bus specific operation, expose similar hif ops table for ahb with all required functions linked to it. Many ath10k_pci_* functions are reused here in hif ops table. If something is not sharable, new functions are added for ahb and linked to hif ops table. Finally, make ath10k_ahb_probe/remove() to perform what is expected out of it. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-01-28ath10k: include qca4019 register map tableRaja Mani
New register table is added for qca4019 to tell about it's register mapping details. Nothing much other than this. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-01-28ath10k: add basic skeleton to support ahbRaja Mani
qca4019 uses ahb instead of pci where it slightly differs in device enumeration, clock control, reset control, etc. Good thing is that ahb also uses copy engine for the data transaction. So, the most of the stuff implemented in pci.c/ce.c are reusable in ahb case too. Device enumeration in ahb case comes through platform driver/device model. All resource details like irq, memory map, clocks, etc for qca4019 can be fetched from of_node of platform device. Simply flow would look like, device tree => platform device (kernel) => platform driver (ath10k) Device tree entry will have all qca4019 resource details and the same info will be passed to kernel. Kernel will prepare new platform device for that entry and expose DT info to of_node in platform device. Later, ath10k would register platform driver with unique compatible name and then kernels binds to corresponding compatible entry & calls ath10k ahb probe functions. From there onwards, ath10k will take control of it and move forward. New bool flag CONFIG_ATH10K_AHB is added in Kconfig to conditionally enable ahb support in ath10k. On enabling this flag, ath10k_pci.ko will have ahb support. This patch adds only basic skeleton and few macros to support ahb in the context of qca4019. Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-12-08Merge tag 'wireless-drivers-next-for-davem-2015-12-07' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Vallo says: ==================== brcfmac * support bcm4359 which can operate in two bands concurrently * disable runtime pm for USB avoiding issues * use generic pm callback in PCIe driver * support wowlan wake indication reporting * add beamforming support * unified handling of firmware files ath10k * support Manegement Frame Protection (MFP) * add thermal throttling support for 10.4 firmware * add support for pktlog in QCA99X0 * add debugfs file to enable Bluetooth coexistence feature * use firmware's native mesh interface type instead of raw mode iwlwifi * BT coex improvements * D3 operation bugfixes * rate control improvements * firmware debugging infra improvements * ground work for multi Rx * various security fixes ==================== Conflicts: drivers/net/wireless/ath/ath10k/pci.c The conflict resolution at: http://article.gmane.org/gmane.linux.kernel.next/37391 by Stephen Rothwell was used. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-23ath10k: adjust the RX packet pad offset at QCA99X0 4addr modeYanbo Li
The QCA99X0 4 addresses RX packets pad 2 bytes at the beginning of MSDU instead the end of ieee80211 header to keep alignment. The currently RX data path can't parse the header correctly in this case. This patch fixes it for QCA99X0. Signed-off-by: Yanbo Li <yanbol@qca.qualcomm.com> [kvalo@qca.qualcomm.com: checkpatch fixes and naming changes] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-11-12ath10k: add QCA9377 hw1.0 supportBartosz Markowski
Add new BMI target version and chip id revision. Register it on supported chips list. Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-11-12ath10k: introduce dev_id to hw_paramsBartosz Markowski
A follow up patch introducing a QCA9377 hw1.0 support will need this device identification helper for an explicit distinction of HWs, as apparently both QCA6174 hw3.0 and QCA9377 share the same BMI target version (0x0502000x). For the QCA9377 hw1.1 previously added we were just lucky we did not overlap with the same chip_id_rev. Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-11-12ath10k: fix the currently supported QCA9377 target version nameBartosz Markowski
When introducing the original QCA9377 support, the chip target version was wrongly picked. The chip advertising itself with bmi target value equal to 0x05020001 is in fact a 1.1 revision. I realized this once I got a real 1.1 hw to play with. Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-11-04ath10k: add support for pktlog in QCA99X0Vivek Natarajan
This patch adds pktlog support for 10.4 fw versions. Signed-off-by: Vivek Natarajan <nataraja@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-10-29ath10k: add QCA9377 chipset supportBartosz Markowski
Add the hardware name, revision and update the pci_id table. Currently there're two HW ref. designs available I'm aware of, with 1.0.2 and 1.1 chip revisions. I've access and been using the first one so far and this patch cover only it. QCA9377 inherits most of the stuff (e.g. fw interfaces) from QCA61x4 design, so the integration was pretty straightforward. Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2015-10-29ath10k: add FW API support to test modeAlan Liu
Add WMI-TLV and FW API support in ath10k testmode. Ath10k can get right wmi command format from UTF image to communicate UTF firmware. Signed-off-by: Alan Liu <alanliu@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-03 00:08:57 +0000