Throughput based RTPM logic of ring access may fail and
lead to NOC error in some corner cases. Change is aimed
to add additional link states check to prevent invalid SRNG
access.
Change-Id: I7e7edbadfd21b4857efa4faff0ada6d94d682f2c
CRs-Fixed: 3256702
Add provision to call sync prevent suspend which will wait for
system to resume and increment usage_count before returning.
Change-Id: I855e3fc2660dc7f3f78bb70f8eef6228cbef96d3
CRs-Fixed: 3253335
As part of SSR, usage count of RTPM is reset to zero which
should not be the case as during RTPM stop, usage count is
incremented to 2.
To fix this, do not reset RTPM usage count to 0 when SSR
happens.
Change-Id: Ifab58075b1aa733500a635e34d209ab65c5f63a8
CRs-Fixed: 3233572
While registering a client, HIF_RTPM_ID_MAX is also being
checked for registering.
Fix is to exclude HIF_RTPM_ID_MAX id.
Change-Id: I57e572abc22a27586cf350af423293a8b455af1c
CRs-Fixed: 3223394
Currently, different modules had different ways of allowing
and preventing runtime suspend. Multiple debug mechanisms
were introduced and workarounds are present as well bloating
the runtime PM module.
This change is done to clean up and restructure HIF runtime
PM module. Modules using Runtime PM module need to register
with an ID present in hif_rtpm_client_id.
hif_rtpm_get() will increment the device usage_count and
prevent device from suspending. Based on argument type, if
system is suspended, subsequent resume action will be done.
hif_rtpm_put() will decrement the usage_count of device and
if it is NULL, based on type of put call, idle sequence will
start. Register HIF module and update respective get and put
calls done from HIF module.
Change-Id: I23747f0f7208e689c1c9eb55789aa81945f596ec
CRs-Fixed: 3169272
Add a log message to indicate RTPM resume is requested by RTPM
prevent runtime suspend API.
Change-Id: Ifb90493d1ea48601bb40708b1a2d7a821144a9b2
CRs-Fixed: 3110580
Current it use __RET_IP to get caller in rtpm resume
function, if it print info by %ps, it will do a
symbol lookup which takes time.
Change as replacing __RET_IP with rtpm_dbgid, so it is
still able to get caller information and avoid time
cost here.
Change-Id: Ifc70c118d621bb9e6d12de87582de09316ae9cad
CRs-Fixed: 3001690
%ps does symbol table lookup in kernel and if used in irq context,
it can lead to irq_handler running for longer time, and jank issues
as a side effect. So, remove it from wakeup_irq_handler.
Change-Id: Ifa42d9a46c838c2458d3220c6d3cb008232e3839
CRs-Fixed: 2999176
Runtime put should be done in hif_pm_runtime_get when
return value of __hif_pm_runtime_get is negative. In
the issue scenario, the ret value will be set to 0 when
the return value of __hif_pm_runtime_get is positive.
The store operation for ret variable somehow did not take
effect and the if check for non-zero ret value to do
runtime put did go through. The return value to
dp_tx_hw_enqueue from hif_pm_runtime_get is the updated
ret value of 0. This will result in double runtime put
for a single runtime get.
Fix is to modify the ret variable check to negative
instead of non-zero to ensure runtime put happens
correctly.
Change-Id: Idc380a11c82b6d1acf7c750e7b93776ac9d6b4f2
CRs-Fixed: 2969879
To avoid excessive logging, we whould not logs RTPM lock init and
deinit to the console. Thus, change the log level to debug.
Change-Id: Ib11045fe50f729b0580284fa913da48d3a59b323
CRs-Fixed: 2927959
Runtime PM for HTC layer has multiple cases of GET/PUT operations.
Adding runtime PM stats for HTC layer, this helps in debugging
RTPM GET/PUT out of sync issues.
Change-Id: Ib27efd73dce0bb5bd3ff030bd7ae1bc833f29610
CRs-Fixed: 2923250
Need to protect prevent_suspend_list by runtime_lock.
Issue happens when
1 printing lock0 of prevent_suspend_list in thread0
2 thread0 scheduled out and lock0 is released.
3 return back to thread0, it will using lock0 pointer
to check next lock, then issue happens.
Fix is adding runtime_lock to protect.
Change-Id: I7182651e445cf5008dba73e15b2c261cc125577f
CRs-Fixed: 2883052
Issue1: Driver RTPM state is ON/NONE, Kernel state is RESUMING.
cdp_runtime_resume is already complete,
hif_pm_runtime_get return -E_INPROGRESS,
dp_tx_hw_enqueue will set the flush event,
but cdp_runtime_resume is already done,
this flush event will be handled only on next pkt tx.
Issue2: Driver RTPM state: Resuming
hif_pm_runtime_get returns -EBUSY,
dp_tx_hw_enqueue is interrupted by any IRQ,
cdp_runtime_resume is completed,
dp_tx_hw_enqueue will set the flush event,
This flush event will be handled only on next pkt tx.
Fix:
Introduce a link_state_up atomic variable in hif to track the link state
change by pld_cb.
Set atomic variable link_state_up=1 in pmo_core_psoc_bus_runtime_resume
just after pld_cb. pld_cb brings the PCIe bus out of suspend state.
Set atomic variable link_state_up=0 in pmo_core_psoc_bus_runtime_suspend
just before pld_cb. pld_cb puts the PCIe bus into suspend state.
Introduce dp_runtime_get and dp_runtime_put.
dp_runtime_get get refcount with increment of an atomic variable.
dp_runtime_put return refcount with decrement of this atomic variable.
If hif_pm_runtime_get returns -EBUSY or -EINPROGRESS,
take the dp runtime refcount using dp_runtime_get,
check if the link state is up, write TX ring HP,
return the dp runtime refcount using dp_runtime_put.
cdp_runtime_suspend should reject the suspend, if dp_runtime_get is non
zero.
cdp_runtime_resume should wait until dp_runtime_get becomes zero or time
out, then flush pending tx for runtime suspend.
Change-Id: I5b97d50cba710082f117f3845f7830712b86cda7
CRs-Fixed: 2844888
Currently if the driver is in runtime suspend/suspending
state, any packet transmission will request for resume
via hif_pm_runtime_get.
Unfortunately there is a logging in the above API which
will lead to more time consumption in the NET_TX softirq
context. This can lead to other delay in processing other
softirqs in the system.
Fix this by skipping the logging in the packet transmission
path.
Change-Id: Icc9f5b67794f7666243eb059f2e07a06a987002e
CRs-Fixed: 2844126
Issue happens when
step 1: kernel pm core start to runtime suspend
step 2: host get wma_acquire_wakelock & send PDEV_SET_HW_MODE.
step 3: host send wow_enable cmd
step 4: wow suspend finished and wow resume happens as step2
send pm_runtime_get
step 5: fw dop PDEV_SET_HW_MODE as enter wow mode
so host can't get PDEV_SET_HW_MODE_RESP from fw.
Fix is:
Don't allow suspend if sending PDEV_SET_HW_MODE.
After change logical will be:
1 if PDEV_SET_HW_MODE before send hif_pre_runtime_suspend->
hif_runtime_pm_set_state_suspending, then wow suspend
will return failure.
2 if PDEV_SET_HW_MODE send after hif_pre_runtime_suspend->
hif_runtime_pm_set_state_suspending, it will request resume
and send after wow resume.
Change-Id: I91eea70f841cf9e5d6767f6005eb9662515657a6
CRs-Fixed: 2850561
In moselle, once wow enabled there is a possibility that wow wake
interrupt can be fired from FW during runtime suspend in-progress
in host, this will introduce a race between runtime suspend and
resume, so adding a synchronization between runtime suspend and
wow triggered runtime resume.
Change-Id: I38d6a24e4421697cc2d0090ba8d19884885596cb
CRs-Fixed: 2845672
For hif_bus_resume till now driver does panic whenever there is
failure. This is now handled in the cnss driver which will collect
the required dump to debug the link down.
Remove the bug_on, just log and return the status.
Change-Id: Ief4d86dd76c0bbde361b69b38894a944eec05aae
CRs-Fixed: 2765117
hif_pm_runtime_prevent_suspend_timeout is no longer supported
and hence delete this obsolete API.
Change-Id: I2c01105219adb198bbf27aee5f2d5c7e357c1e34
CRs-Fixed: 2761022
A few functions in HIF component returns QDF status value with return
type as non QDF STATUS and vice versa. For such functions, update the
correct return type.
Change-Id: I806407dd0596cd03500242d97ca8220a7beb6c55
CRs-Fixed: 2734818
Move all the Runtime PM related HIF code changes to the
common section, from if_pci.
So that, could be leveraged for other HIF interfaces
like if_ipci to use.
Change-Id: Id8303acd519ab07f307311971fb55c45476f30bf
CRs-Fixed: 2699419
