Revision tags: v5.10.30 |
|
#
9d401222 |
| 11-Apr-2021 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
iwlwifi: pcie: add ISR debug info for msix debug
The debug prints help in case we get timeout on waiting for hw.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Lu
iwlwifi: pcie: add ISR debug info for msix debug
The debug prints help in case we get timeout on waiting for hw.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210411124417.306e2e56d3e8.I72e2977abbb1fddf23b8476bedf6a183fe969ff5@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16 |
|
#
1ed08f6f |
| 10-Feb-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: remove flags argument for nic_access
Since we no longer save interrupts, we no longer need the flags argument here, remove it throughout.
Signed-off-by: Johannes Berg <johannes.berg@intel.
iwlwifi: remove flags argument for nic_access
Since we no longer save interrupts, we no longer need the flags argument here, remove it throughout.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210142629.8de8fe6f9fff.If040b056d0e8c771c65ac5c29230f939354a142b@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
d0129315 |
| 10-Feb-2021 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
iwlwifi: dbg: add op_mode callback for collecting debug data.
The first use is collecting debug data when transport stops the device.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.c
iwlwifi: dbg: add op_mode callback for collecting debug data.
The first use is collecting debug data when transport stops the device.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210142629.d282d0a9ee7b.I9a0ad29f80daba8956a6aa077ba865e19b2150be@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
9cf671d6 |
| 10-Feb-2021 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: pcie: NULLify pointers after free
Remember that those pointers have been freed by setting them to NULL. Otherwise, we'd keep rxq pointing to random memory which would prevent us from trying
iwlwifi: pcie: NULLify pointers after free
Remember that those pointers have been freed by setting them to NULL. Otherwise, we'd keep rxq pointing to random memory which would prevent us from trying to re-allocate the Rx resources if we call rx_alloc again.
Also, propagate the allocation failure to the caller of iwl_pcie_nic_init so that we won't go further in the start flow.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210135352.996b400d2f1c.I630379c504644700322f57b259383ae0af8d1975@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
874020f8 |
| 10-Feb-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: don't disable interrupts for reg_lock
The only thing we do touching the device in hard interrupt context is, at most, writing an interrupt ACK register, which isn't racing in with any
iwlwifi: pcie: don't disable interrupts for reg_lock
The only thing we do touching the device in hard interrupt context is, at most, writing an interrupt ACK register, which isn't racing in with anything protected by the reg_lock.
Thus, avoid disabling interrupts here for potentially long periods of time, particularly long periods have been observed with dumping of firmware memory (leading to lockup warnings on some devices.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210135352.da916ab91298.I064c3e7823b616647293ed97da98edefb9ce9435@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
Revision tags: v5.10.15, v5.10.14 |
|
#
13f028b4 |
| 17-Jan-2021 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
iwlwifi: tx: move handing sync/async host command to trans
Handling host commands in a sync way is not directly related to PCIe transport, and can serve as common logic for any transport, so move it
iwlwifi: tx: move handing sync/async host command to trans
Handling host commands in a sync way is not directly related to PCIe transport, and can serve as common logic for any transport, so move it to trans layer.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117164916.fde99af4e0f7.I4cab95919eb35cc5bfb26d32dcf5e15419d0e0ef@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
6275c77e |
| 17-Jan-2021 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: remove TRANS_PM_OPS
Those were needed for a slave bus that is not longer supported. Remove code that is mainly useless stubs.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwlwifi: remove TRANS_PM_OPS
Those were needed for a slave bus that is not longer supported. Remove code that is mainly useless stubs.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117130510.8f8a735f39dd.If5716eaae0df5e6295a2af927bf3ab0ee074f0a0@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
3161a34d |
| 17-Jan-2021 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
iwl-trans: iwlwifi: move sync NMI logic to trans
The code is not directly related to PCIe transport, and it will help moving sync/async commands logic out of PCIe in the next patches.
Signed-off-by
iwl-trans: iwlwifi: move sync NMI logic to trans
The code is not directly related to PCIe transport, and it will help moving sync/async commands logic out of PCIe in the next patches.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117130510.271f59887fd1.I8ff41236f4e11a25df83d76c982a2a30ba2b9903@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
25edc8f2 |
| 17-Jan-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: properly implement NAPI
Instead of pretending to have NAPI and then relying entirely on interrupts anyway, properly implement NAPI and schedule the poll when we get an interrupt, re-e
iwlwifi: pcie: properly implement NAPI
Instead of pretending to have NAPI and then relying entirely on interrupts anyway, properly implement NAPI and schedule the poll when we get an interrupt, re-enabling the interrupt only after the poll completed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117130510.a5951ac4fc06.I9c84a147288fcfb1b019572c6758f2d92949f5d7@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
3d372c4e |
| 15-Jan-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: reschedule in long-running memory reads
If we spin for a long time in memory reads that (for some reason in hardware) take a long time, then we'll eventually get messages such as
w
iwlwifi: pcie: reschedule in long-running memory reads
If we spin for a long time in memory reads that (for some reason in hardware) take a long time, then we'll eventually get messages such as
watchdog: BUG: soft lockup - CPU#2 stuck for 24s! [kworker/2:2:272]
This is because the reading really does take a very long time, and we don't schedule, so we're hogging the CPU with this task, at least if CONFIG_PREEMPT is not set, e.g. with CONFIG_PREEMPT_VOLUNTARY=y.
Previously I misinterpreted the situation and thought that this was only going to happen if we had interrupts disabled, and then fixed this (which is good anyway, however), but that didn't always help; looking at it again now I realized that the spin unlock will only reschedule if CONFIG_PREEMPT is used.
In order to avoid this issue, change the code to cond_resched() if we've been spinning for too long here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 04516706bb99 ("iwlwifi: pcie: limit memory read spin time") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130253.217a9d6a6a12.If964cb582ab0aaa94e81c4ff3b279eaafda0fd3f@changeid
show more ...
|
#
67013174 |
| 15-Jan-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: use jiffies for memory read spin time limit
There's no reason to use ktime_get() since we don't need any better precision than jiffies, and since we no longer disable interrupts aroun
iwlwifi: pcie: use jiffies for memory read spin time limit
There's no reason to use ktime_get() since we don't need any better precision than jiffies, and since we no longer disable interrupts around this code (when grabbing NIC access), jiffies will work fine. Use jiffies instead of ktime_get().
This cleanup is preparation for the following patch "iwlwifi: pcie: reschedule in long-running memory reads". The code gets simpler with the weird clock use etc. removed before we add cond_resched().
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130253.621c948b1fad.I3ee9f4bc4e74a0c9125d42fb7c35cd80df4698a1@changeid
show more ...
|
Revision tags: v5.10 |
|
#
906d4eb8 |
| 09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: support firmware reset handshake
There are some races in the hardware that can possibly lead to a bus lockup later during a restart when we manage to kill the firmware at a bad time (while
iwlwifi: support firmware reset handshake
There are some races in the hardware that can possibly lead to a bus lockup later during a restart when we manage to kill the firmware at a bad time (while it's accessing the bus).
To work around this, add support for a new handshake between firmware and driver to ensure that the firmware is in a well- known state before we kill it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.7756fcc9865c.I13de65e0ffcb4186dd4c1a465f66df2e98c9a947@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
8e99ea8d |
| 09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: use SPDX tags
Use SPDX tags instead of the long copyright notices. Also cleanup some duplicate copyright notices and combine the years where possible.
Signed-off-by: Johannes Berg <johann
iwlwifi: use SPDX tags
Use SPDX tags instead of the long copyright notices. Also cleanup some duplicate copyright notices and combine the years where possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201210000603.481bcb512a6f.I8146abe5a637079e7336209f23cb26af98b12b31@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
69d6cfc4 |
| 09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: remove unnecessary setting of inta_mask
We set this here, but don't really use it until we've enabled interrupts. But when enabling interrupts we always overwrite this value anyway, s
iwlwifi: pcie: remove unnecessary setting of inta_mask
We set this here, but don't really use it until we've enabled interrupts. But when enabling interrupts we always overwrite this value anyway, so remove setting it here, mostly in order not to have some additional code duplicated later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.135d96297aca.Id2d26fff60b6c31202bb0a36e46948bda6a39d33@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
aa7fd946 |
| 09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: remove MSIX_HW_INT_CAUSES_REG_IML handling
This is actually wrong, the bit used here by the image loader is BIT(1), not BIT(2). The latter will be reused by the new reset flow soon.
iwlwifi: pcie: remove MSIX_HW_INT_CAUSES_REG_IML handling
This is actually wrong, the bit used here by the image loader is BIT(1), not BIT(2). The latter will be reused by the new reset flow soon.
However, as we never had any complaints about not printing the IML status or not handling the IML error interrupt (and I suspect the code handling it was incorrectly anyway) just remove the code for it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.9a323f4a3493.Ic7aee4dbbf4be42287c338c2fa1b111473724116@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
59fa61f3 |
| 09-Dec-2020 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: remove sw_csum_tx
This was a hack done to test the data path of devices that didn't support well CSUM offload in Tx. This is not needed anymore.
Signed-off-by: Emmanuel Grumbach <emmanuel.
iwlwifi: remove sw_csum_tx
This was a hack done to test the data path of devices that didn't support well CSUM offload in Tx. This is not needed anymore.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.6c9fc9fb48d5.I2aaebf90e6fe81860105d049a8d35746fa8d86c2@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
4adfaf9b |
| 09-Dec-2020 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: pcie: remove obsolete pre-release support code
We no longer need code that was introduced to differentiate between two early versions of 8260.
We can remove this convoluted way to get the
iwlwifi: pcie: remove obsolete pre-release support code
We no longer need code that was introduced to differentiate between two early versions of 8260.
We can remove this convoluted way to get the hardware version that was needed because of a bug in the register's configuration.
Moreover, since we no longer need to access the PRPH registers, we no longer need to wake up the device, request ownership, etc... Remove all that.
This allows us to get the rid of the obsolete comment about the AUX bus MISC address space which should have been moved when this code was moved away from here.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.4a5665ccd8a6.Iff3879405c15758ba661c430e77dc2160ddada1c@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
a4450980 |
| 09-Dec-2020 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
iwlwifi: move reclaim flows to the queue file
Reclaim flows are bus-independent TX functions so we move it to the common place handling bus-independent tx operations
used spatch rule
@@ @@ ( -iwl_
iwlwifi: move reclaim flows to the queue file
Reclaim flows are bus-independent TX functions so we move it to the common place handling bus-independent tx operations
used spatch rule
@@ @@ ( -iwl_trans_pcie_freeze_txq_timer +iwl_trans_txq_freeze_timer | -iwl_trans_pcie_set_q_ptrs +iwl_trans_txq_set_q_ptrs | -iwl_pcie_txq_free_tfd +iwl_txq_free_tfd | -iwl_pcie_txq_progress +iwl_txq_progress | -iwl_trans_pcie_reclaim +iwl_trans_txq_reclaim )
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.40723e92b6bf.I83cf71d9c6d989ec42f52b353f1d33f32540db59@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
cc598782 |
| 09-Dec-2020 |
Rotem Saado <rotem.saado@intel.com> |
iwlwifi: yoyo: align the write pointer to DWs
from AX210 generation the write pointer is in Bytes. to be align with all previous HWs convert it DWs.
Signed-off-by: Rotem Saado <rotem.saado@intel.co
iwlwifi: yoyo: align the write pointer to DWs
from AX210 generation the write pointer is in Bytes. to be align with all previous HWs convert it DWs.
Signed-off-by: Rotem Saado <rotem.saado@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231351.c9a9cbef4a09.Ic7df63c617f79b7e6a95a510c51b3516bba5599f@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
show more ...
|
#
608c8359 |
| 02-Aug-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: free RBs during configure
[ Upstream commit 6ac5720086c8b176794eb74c5cc09f8b79017f38 ]
When switching op-modes, or more generally when reconfiguring, we might switch the RB size. In
iwlwifi: pcie: free RBs during configure
[ Upstream commit 6ac5720086c8b176794eb74c5cc09f8b79017f38 ]
When switching op-modes, or more generally when reconfiguring, we might switch the RB size. In _iwl_pcie_rx_init() we have a comment saying we must free all RBs since we might switch the size, but this is actually too late: the switch has been done and we'll free the buffers with the wrong size.
Fix this by always freeing the buffers, if any, at the start of configure, instead of only after the size may have changed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210802170640.42d7c93279c4.I07f74e65aab0e3d965a81206fcb289dc92d74878@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
221528c2 |
| 10-Feb-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: don't disable interrupts for reg_lock
[ Upstream commit 874020f8adce535cd318af1768ffe744251b6593 ]
The only thing we do touching the device in hard interrupt context is, at most, wri
iwlwifi: pcie: don't disable interrupts for reg_lock
[ Upstream commit 874020f8adce535cd318af1768ffe744251b6593 ]
The only thing we do touching the device in hard interrupt context is, at most, writing an interrupt ACK register, which isn't racing in with anything protected by the reg_lock.
Thus, avoid disabling interrupts here for potentially long periods of time, particularly long periods have been observed with dumping of firmware memory (leading to lockup warnings on some devices.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210135352.da916ab91298.I064c3e7823b616647293ed97da98edefb9ce9435@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
a59a7b96 |
| 15-Jan-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: reschedule in long-running memory reads
[ Upstream commit 3d372c4edfd4dffb7dea71c6b096fb414782b776 ]
If we spin for a long time in memory reads that (for some reason in hardware) tak
iwlwifi: pcie: reschedule in long-running memory reads
[ Upstream commit 3d372c4edfd4dffb7dea71c6b096fb414782b776 ]
If we spin for a long time in memory reads that (for some reason in hardware) take a long time, then we'll eventually get messages such as
watchdog: BUG: soft lockup - CPU#2 stuck for 24s! [kworker/2:2:272]
This is because the reading really does take a very long time, and we don't schedule, so we're hogging the CPU with this task, at least if CONFIG_PREEMPT is not set, e.g. with CONFIG_PREEMPT_VOLUNTARY=y.
Previously I misinterpreted the situation and thought that this was only going to happen if we had interrupts disabled, and then fixed this (which is good anyway, however), but that didn't always help; looking at it again now I realized that the spin unlock will only reschedule if CONFIG_PREEMPT is used.
In order to avoid this issue, change the code to cond_resched() if we've been spinning for too long here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 04516706bb99 ("iwlwifi: pcie: limit memory read spin time") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130253.217a9d6a6a12.If964cb582ab0aaa94e81c4ff3b279eaafda0fd3f@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
bcb9c400 |
| 15-Jan-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: use jiffies for memory read spin time limit
[ Upstream commit 6701317476bbfb1f341aa935ddf75eb73af784f9 ]
There's no reason to use ktime_get() since we don't need any better precision
iwlwifi: pcie: use jiffies for memory read spin time limit
[ Upstream commit 6701317476bbfb1f341aa935ddf75eb73af784f9 ]
There's no reason to use ktime_get() since we don't need any better precision than jiffies, and since we no longer disable interrupts around this code (when grabbing NIC access), jiffies will work fine. Use jiffies instead of ktime_get().
This cleanup is preparation for the following patch "iwlwifi: pcie: reschedule in long-running memory reads". The code gets simpler with the weird clock use etc. removed before we add cond_resched().
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130253.621c948b1fad.I3ee9f4bc4e74a0c9125d42fb7c35cd80df4698a1@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.8.17 |
|
#
04516706 |
| 22-Oct-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: pcie: limit memory read spin time
When we read device memory, we lock a spinlock, write the address we want to read from the device and then spin in a loop reading the data in 32-bit quanti
iwlwifi: pcie: limit memory read spin time
When we read device memory, we lock a spinlock, write the address we want to read from the device and then spin in a loop reading the data in 32-bit quantities from another register.
As the description makes clear, this is rather inefficient, incurring a PCIe bus transaction for every read. In a typical device today, we want to read 786k SMEM if it crashes, leading to 192k register reads. Occasionally, we've seen the whole loop take over 20 seconds and then triggering the soft lockup detector.
Clearly, it is unreasonable to spin here for such extended periods of time.
To fix this, break the loop down into an outer and an inner loop, and break out of the inner loop if more than half a second elapsed. To avoid too much overhead, check for that only every 128 reads, though there's no particular reason for that number. Then, unlock and relock to obtain NIC access again, reprogram the start address and continue.
This will keep (interrupt) latencies on the CPU down to a reasonable time.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20201022165103.45878a7e49aa.I3b9b9c5a10002915072312ce75b68ed5b3dc6e14@changeid
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9 |
|
#
69725928 |
| 08-Oct-2020 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: read and parse PNVM file
The driver looks for a PNVM file that contains FW configuration data for each different HW combination. The FW requests the data for a certain SKU_ID and the drive
iwlwifi: read and parse PNVM file
The driver looks for a PNVM file that contains FW configuration data for each different HW combination. The FW requests the data for a certain SKU_ID and the driver tries to find it in the PNVM file.
Read the file, parse its contents and send it to the trans.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20201008181047.826bc607e57a.I1d93dd6e6651586878db57fac3e7c3f09d742c42@changeid
show more ...
|