- 27 9月, 2015 1 次提交
-
-
由 Janusz Dziedzic 提交于
In case of qca99x0 and MSI-X supported/enabled we failed during interrupts registering with message: ath10k_pci 0000:04:00.0: failed to request MSI-X ce irq 50: -22 Issue/fix was reproduced/tested using Dell Latitude E6430 laptop. Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 26 8月, 2015 2 次提交
-
-
由 Michal Kazior 提交于
This adds additional 0x0041 PCI Device ID definition to ath10k for QCA6164 which is a 1 spatial stream sibling of the QCA6174 (which is 2 spatial stream chip). The QCA6164 needs a dedicated board.bin file which is different than the one used for QCA6174. If the board.bin is wrong the device will crash early while trying to boot firmware. The register dump will look like this: ath10k_pci 0000:02:00.0: firmware register dump: ath10k_pci 0000:02:00.0: [00]: 0x05010000 0x000015B3 0x000A012D 0x00955B31 ... Note the value 0x000A012D. Special credit goes to Alan Liu <alanliu@qca.qualcomm.com> for providing support help which enabled me to come up with this patch. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
The function returns 1 when DMA mapping fails. The driver would return bogus values and could possibly confuse itself if DMA failed. Fixes: 767d34fc ("ath10k: remove DMA mapping wrappers") Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 30 7月, 2015 1 次提交
-
-
Add vendor/device id of QCA99X0 V2.0 to pci id table and QCA99X0_HW_2_0_CHIP_ID_REV to ath10k_pci_supp_chips[] for QCA99X0 to get detected by the driver. kvalo: now QCA99X0 family of chipsets is supported by ath10k. Tested client, AP and monitor mode with QCA9990. Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 24 7月, 2015 1 次提交
-
-
It is observed that during cold reset pcie access right after a write operation to SOC_GLOBAL_RESET_ADDRESS causes Data Bus Error and system hard lockup. The reason for bus error is that pcie needs some time to get back to stable state for any transaction during cold reset. Add delay of 20 msecs after write of SOC_GLOBAL_RESET_ADDRESS to fix this issue. This patch is tested on QCA988X. This is also tested on QCA99X0 which is WIP. Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 12 7月, 2015 1 次提交
-
-
In commit 418ca599 ("ath10k: Make target cpu address to CE address conversion chip specific") mask 0x7fff is added by mistake instead of 0x7ff. Fix this regression. Fixes: 418ca599 ("ath10k: Make target cpu address to CE address conversion chip specific") Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 30 6月, 2015 4 次提交
-
-
QCA99X0 supports only cold reset. Also, made ath10k_pci_irq_msi_fw_mask() and ath10k_pci_irq_msi_fw_unmask() non-99X0 specific till we get proper register configuration to mask/unmask irq/MSI. Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
Make the helper converting target virtual address space to CE address space a target type specific to support QCA99X0. Also make this as function instead of macro. Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
QCA99X0 supports upto 12 Copy engines. Host and target CE configuration table is updated to support new copy engine pipes. This also fixes the assumption of diagnostic CE by making CE_7 as the one instead of CE_COUNT - 1. Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
This is to prepare the driver for QCA99X0 chip support. This commit adds hw_params, hw register table and hw_values table for QCA99X0 chip. Please note this is only a partial patch adding support for QCA99X0, so the device id is not yet added to pci device table. Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 16 6月, 2015 1 次提交
-
-
由 Michal Kazior 提交于
It was possible to force an out of bounds MMIO read/write via debugfs. E.g. on QCA988X this could be triggered with: echo 0x2080e0 | tee /sys/kernel/debug/ieee80211/*/ath10k/reg_addr cat /sys/kernel/debug/ieee80211/*/ath10k/reg_value BUG: unable to handle kernel paging request at ffffc90001e080e0 IP: [<ffffffff8135c860>] ioread32+0x40/0x50 ... Call Trace: [<ffffffffa00d0c7f>] ? ath10k_pci_read32+0x4f/0x70 [ath10k_pci] [<ffffffffa0080f50>] ath10k_reg_value_read+0x90/0xf0 [ath10k_core] [<ffffffff8115c2c1>] ? handle_mm_fault+0xa91/0x1050 [<ffffffff81189758>] __vfs_read+0x28/0xe0 [<ffffffff812e4694>] ? security_file_permission+0x84/0xa0 [<ffffffff81189ce3>] ? rw_verify_area+0x53/0x100 [<ffffffff81189e1a>] vfs_read+0x8a/0x140 [<ffffffff8118acb9>] SyS_read+0x49/0xb0 [<ffffffff8104e39c>] ? trace_do_page_fault+0x3c/0xc0 [<ffffffff8196596e>] system_call_fastpath+0x12/0x71 Reported-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 09 6月, 2015 1 次提交
-
-
由 Raja Mani 提交于
mete_data is extracted from ce descriptor and stored in variable 'id'. later, id is not used anywhere in the same function. Fixes: d84a512d ("ath10k: remove transfer_id from ath10k_hif_cb::tx_completion") Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 01 6月, 2015 1 次提交
-
-
由 Michal Kazior 提交于
If probing failed pci sleep timer could remain running and trigger after ath10k structures were freed causing invalid pointer dereference: BUG: unable to handle kernel paging request at ffffc90001c80004 IP: [<ffffffff81354728>] iowrite32+0x38/0x40 ... Call Trace: <IRQ> [<ffffffffa00da048>] ? __ath10k_pci_sleep+0x48/0x60 [ath10k_pci] [<ffffffffa00da44e>] ath10k_pci_ps_timer+0x5e/0x80 [ath10k_pci] [<ffffffff810b210e>] call_timer_fn+0x3e/0x120 [<ffffffffa00da3f0>] ? ath10k_pci_wake+0x150/0x150 [ath10k_pci] [<ffffffff810b3d11>] run_timer_softirq+0x201/0x2e0 [<ffffffff8105d73f>] __do_softirq+0xaf/0x290 [<ffffffff8105da95>] irq_exit+0x95/0xa0 [<ffffffff81950406>] smp_apic_timer_interrupt+0x46/0x60 [<ffffffff8194e77e>] apic_timer_interrupt+0x6e/0x80 Fixes: 77258d40 ("ath10k: enable pci soc powersaving") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 29 5月, 2015 1 次提交
-
-
由 Michal Kazior 提交于
This could lead userspace initram images getting built without necessary firmware files included leading to probing failures of ath10k on boot with QCA61X4. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 22 5月, 2015 2 次提交
-
-
由 Michal Kazior 提交于
By using SOC_WAKE register it is possible to bring down power consumption of QCA61X4 from 36mA to 16mA when associated and idle. Currently the sleep threshold/grace period is at a very conservative value of 60ms. Contrary to QCA61X4 the QCA988X firmware doesn't have Rx/beacon filtering available for client mode and SWBA events are used for beaconing in AP/IBSS so the SoC needs to be woken up at least every ~100ms in most cases. This means that QCA988X is at a disadvantage and the power consumption won't drop as much as for QCA61X4. Due to putting irq-safe spinlocks on every MMIO read/write it is expected this can cause a little performance regression on some systems. I haven't done any thorough measurements but some of my tests don't show any extreme degradation. The patch removes some explicit pci_wake calls that were added in 320e14b8db51aa ("ath10k: fix some pci wake/sleep issues"). This is safe because all MMIO accesses are now wrapped and the device is woken up automatically if necessary. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Janusz Dziedzic 提交于
It is actually safe to enable ASPM after the device is booted up. This reduces power drain of QCA61X4 when driver is simply loaded (no interface is up) from 31mA to 14mA. QCA988X wasn't measured but doesn't seem to regress in any other way. Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 22 4月, 2015 2 次提交
-
-
由 Michal Kazior 提交于
During initialization firmware does some sort of memory switch between DRAM and IRAM. If configuration value for bank switching isn't correct device crashes during init. The new value prevents firmware 11.0.0.302 (and possibly others) for qca61x4 hw2.1 from crashing during init. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Some devices differ slightly and require different board files. If wrong board data is used they crash or behave incorrectly. These devices can be differentiated by looking at PCI subsystem device id. That is the case for qca61x4 devices at least. The board specific filename is constructed as: board-<bus>-<id>.bin For PCI in particular it is: board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin These files are looked in device/hw specific directories. Hence for Killer 1525 (qca6174 hw2.1) ath10k will request: /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin To not break any existing setups (e.g. in case some devices in the wild already have subsys ids) if a board specific file isn't found a generic one is used which is the one which would be used until now. This guarantees that after upgrading a driver device will not suddenly stop working due to now-missing specific board file. If this is the case a "fallback" string is appended to the info string when driver boots. Keep in mind this is distinct from cal-pci-*.bin files which contain full calibration data and MAC address. Cal data is aimed at systems where calibration data is stored out of band, e.g. on nand flash instead of device EEPROM - an approach taken by some AP/router vendors. Board files are more of a template and needs some bits to be filled in by the OTP program using device EEPROM contents. One could argue to map subsystem ids to some board design codename strings instead of using raw ids when building the board filename. Using a mapping however would make it a lot more cumbersome and time consuming (due to how patches propagate over various kernel trees) to add support for some new device board designs. Adding a board file is a lot quicker and doesn't require recompilation. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 17 4月, 2015 1 次提交
-
-
由 Michal Kazior 提交于
If chip_id wasn't recognized clean up code wasn't executed properly. It would skip freeing memory causing a leak and irqs causing possibly MSI warning splats later or even kernel crashes. Fixes: 1a7fecb7 ("ath10k: reset chip before reading chip_id in probe") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 30 3月, 2015 1 次提交
-
-
由 Kalle Valo 提交于
Firmware 10.2.4.48-3 now supports management frames over HTT feature and has ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX. But as 10.2.4 branch has conflicting HTT ids patch "ath10k: add ATH10K_FW_IE_HTT_OP_VERSION" is needed to fix the issue. Older ath10k versions don't have support that support and to maintain backwards compatibility we need bump up the FW API to 5 not break older versions. Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 07 3月, 2015 3 次提交
-
-
由 Michal Kazior 提交于
The check was't really necessary and couldn't even work to begin with because pci_restore_state() restores only first 64 bytes of PCI configuration space. Actually the PCI subsystem takes care of this so there's no need for explicit calls to save PCI state in ath10k. This is necessary for future WoWLAN support. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
In some cases the device ends up sleeping while ath10k didn't expect it to leading to reading garbage from registers, e.g. when shared irqs are used and the driver is in powered down state. This effectively makes the device remain awake all the time even when all interfaces are down. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Bartosz Markowski 提交于
This has been missed while adding the QCA6174 support. As in the last time, without advertising the firmware files as needed (or optional) for ath10k, these won't be built into ram disk for instance. Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 05 3月, 2015 1 次提交
-
-
由 Rajkumar Manoharan 提交于
Having lower number of copy engine entries for target to host WMI ring is causing drops in receiving management frames. This issue is observed during max clients (128 clients) stress testing. While bursting deauthentication frames from simulated clients, approx. 70% of frames are getting dropped due to lower ring entries. Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 04 3月, 2015 1 次提交
-
-
由 Michal Kazior 提交于
qca6174 WLAN.RM.2.0-00073 firmware uses full rx reordering offload and delivers Rx via a new HTT event. The event however is incorrectly generated in firmware and becomes overly long (with trailing garbage). This was hitting defined CE buffer limit that was programmed to the device and caused device to crash upon busier Rx traffic. Increasing the CE buffer limit for HTT Rx pipe to 2KBytes seems to be enough to workaround this problem. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 27 1月, 2015 4 次提交
-
-
由 Michal Kazior 提交于
It makes little sense to keep handling irqs if fw is dead. This prevents multiple fw register dumps upon crash on some devices (seen on QCA6174). Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
The QCA6174 in combination with new wmi-tlv firmware is capable of multi-channel, beamforming, tdls and other features. This patch just makes it possible to boot these devices and do some basic stuff like connect to an AP without encryption. Some things may not work or may be unreliable. New features will be implemented later. This will be addressed eventually with future patches. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
There are some very rare cases with some hardware configuration that the device doesn't init quickly enough in which case reading chip_id yielded 0. This caused driver to subsequently fail to setup the device. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
It doesn't make much sense to share the ath10k_skb_cb with Rx path. The Rx path doesn't need to keep any mac80211's data. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 15 1月, 2015 1 次提交
-
-
由 Michal Kazior 提交于
Originally the explicit fw register dump was added to wait_for_target_init because interrupts are masked early during power_up. Due to some changes in power_up/reset sequences sometimes when fw crashed ath10k would print the dump more than once via hif_stop -> warm_reset -> wait_for_target_init, possibly with different values each. Prevent this by doing the explicit fw register dump only during power_up instead of wait_for_target_init. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 08 12月, 2014 1 次提交
-
-
由 Michal Kazior 提交于
This will make it easier to extend and maintain list of supported hardware. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 01 12月, 2014 3 次提交
-
-
由 Michal Kazior 提交于
In theory it was possible to starve the system if a tx/rx handler could implicitly trigger more tx/rx pci events. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Pass the eid argument via skbuff control buffer. This will make it possible to work with queues of HTC event buffers. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
This wasn't used since forever and there are no plans on using it. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 26 11月, 2014 2 次提交
-
-
由 Yanbo Li 提交于
Add mem_val debugfs file for dumping the firmware (target) memory and also for writing to the memory. The firmware memory is accessed through one file which uses position of the file as the firmware memory address. For example, with dd use skip parameter for the address. Beucase target memory width is 32 bits it's strongly recommended to use blocksize divisable with 4 when using this interface. For example, when using dd use bs=4 to set the block size to 4 and remember to divide both count and skip values with four. To read 4 kB chunk from address 0x400000: dd if=mem_value bs=4 count=1024 skip=1048576 | xxd -g1 To write value 0x01020304 to address 0x400400: echo 0x01020304 | xxd -r | dd of=mem_value bs=4 seek=1048832 To read 4 KB chunk of memory and then write back after edit: dd if=mem_value of=tmp.bin bs=4 count=1024 skip=1048576 emacs tmp.bin dd if=tmp.bin of=mem_value bs=4 count=1024 seek=1048576 Signed-off-by: NYanbo Li <yanbol@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Yanbo Li 提交于
Debugfs files reg_addr and reg_val are used for reading and writing to the firmware (target) registers. reg_addr contains the address to be accessed, which also needs to be set first, and reg_value is when used for reading and writing the actual value in ASCII. To read a value from the firmware register 0x100000: # echo 0x100000 > reg_addr # cat reg_value 0x00100000:0x000002d3 To write value 0x2400 to address 0x100000: # echo 0x100000 > reg_addr # echo 0x2400 > reg_value # Signed-off-by: NYanbo Li <yanbol@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 04 11月, 2014 1 次提交
-
-
由 Bartosz Markowski 提交于
Firmware was crashing when we were trying to warm reset it after suspend. This was due to the fact that target registeres can be accessed only if the hardware is awaken. This patch makes sure to awake the device also on the hif up, not only in case of probe call. Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 31 10月, 2014 3 次提交
-
-
由 Michal Kazior 提交于
While testing other things I've found that CE items aren't cleared properly. This could lead to null dereferences in BMI. To prevent that make sure CE revoking clears the nbytes value (which is used as a buffer completion indication) and memset the entire CE ring data shared between host and target when (re)initializing. Also make sure to check BMI xfer pointer and print a splat instead of crashing the kernel. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Currently hif_power_up performs effectively a reset and hif_stop resets the chip as well so there's no point in resetting here. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
The power up procedure was overly complex due to warm/cold reset workarounds and issues. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-