The RSC channel switch in certain cases may take more time
to complete at RPMH end.
Add delay of maximum 100usec.
Change-Id: I65862ad80fbb698e6b66e2038a7692c4b78c2ce9
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
During low memory situations caused by some scenarios such as OTA
upgrade rpmh transfers may fail.
Use stack memory for rpmh transfers to avoid such failures.
Change-Id: I904f788dd865d083191bc5113a27e6ee232ebfc8
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte aligned
addresses associated with it. These control voltage, enable state, mode,
and in legacy targets, voltage headroom. The current in-flight request
checking logic looks for exact address matches. Requests for different
addresses of the same RPMh resource as thus not detected as in-flight.
Enhance the in-flight request check for VREG requests by ignoring the
address offset. This ensures that only one request is allowed to be
in-flight for a given VREG resource. This is needed to avoid scenarios
where request commands are carried out by RPMh hardware out-of-order
leading to LDO regulator over-current protection triggering.
Change-Id: I2fa512c27ae123002663259171c2857dd7aa2999
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Client drivers may want to enforce serialization of TCS commands in some
cases like when LDO needs to complete the disable vote first and then go
in low power mode.
Both the commands are sent in same TCS in such cases require serialization
to maintain the order in which the commands are sent.
This reverts commit fef419c463.
Change-Id: I54c2e8dd47a8469450cca677fb62a7c6b6d6343b
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
cpuidle-psci driver now invokes genpd power off with improved support for
suspend-to-RAM for PSCI OSI mode.
Remove syscore ops as it will be taken care by genpd getting turned off.
This reverts commit a939a7ca4a.
Change-Id: I82e76caa173df72da94503720dba0841753eeea4
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
This patch adds the priority for the rpmh-rsc cpu_pm notifier
as highest priority so that it should execute first.
Change-Id: Ie3bea732b8b4cc26dd053342309aec75134db8bb
Signed-off-by: Raghavendra Kakarla <quic_rkakarla@quicinc.com>
Certain devices like camera IFE are not child of RSC device.
Provide support for such devices to get the RSC device which
can be used in the APIs like rpmh_drv_start(), rpmh_drv_stop()
and rpmh_write_sleep_and_wake_no_child() to support such use case.
Change-Id: Ibf461e72438c239571b5d6df0ce5f331239d8444
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Correctly get the TCS for FAST_PATH from respective channel
and also remove the __rpmh_rsc_ctrlr_is_busy() API and squash
changes into rpmh_rsc_ctrlr_is_busy().
Change-Id: I5f427b8439d2c60dd2639e08e7795d61c27f51af
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Fix print_tcs_info() to check for valid tcs_grp before accessing.
Change-Id: I3687e7a2bf5d49aa1792ce27887d6fd4121eb237
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
This change is to add missing initialization.
Change-Id: Icdec51afb78bb294b4649c85b6fef087dc554984
Signed-off-by: Tushar Nimkar <quic_tnimkar@quicinc.com>
This patch adds print that AOSS did not respond when aoss_irq_sts is
PENDING.
Change-Id: I40cf910f33e128f9b80d62f2b04f661fd975cf89
Signed-off-by: Tushar Nimkar <quic_tnimkar@quicinc.com>
Power domain gets off notification only during s2idle which invokes
_rpmh_flush().
The runtime PM of devices gets disabled during suspend which do not
allow the CPU domain and in turn cluster domain to go off.
Use syscore ops to invoke _rpmh_flush() in such cases.
Change-Id: I450b977645ab37d87f7541fb597642dd63bfd250
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
rpmh_rsc_get_channel() may return negative error code during failure.
Fix the channel variable data type.
Change-Id: Iadb8a655e568ce2f8cf3ce3863978593069cb947
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Log in ftrace for channel switch and drv enable.
Change-Id: Icdcaafc67d5f24ffe55a03ebf1d850136dc7a55b
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Use correct offset to read RSC_DRV_STATUS during debug. While at this add
changes to skip reading RSC_DRV_STATUS if channel is not initialized.
Change-Id: Ic195871638acd7c0db4fc33a2ed6dd723c11c8e4
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
This change adds APIs to start/stop camera RSC channels
which can be used by clients.
Update the rpmh_rsc_get_channel() to select unused channel
to flush the cached sleep and wake requests.
Also assume the 'solver' state during probe to disallow
RPMH_ACTIVE_ONLY_STATE requests.
Change-Id: I0ea6aa9f8d2961428636961d3cb53f5e67f37f54
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Add support to probe multiple DRVs in a single RSC device. Each
DRV can have TCSes spread in channels for use by a hardware directly
communicating with the RSC.
A 'channel' is a collection of TCS groups, that may independently
be used by the RSC sequencer. The channel number will be derrived
from the device that is making an RPMH request and to support same
add channel parameter to all RPMH requests.
Each channel can cache the sleep and wake requests independently
and when the rpmh_flush() is requested by a device the respective
channel's cached data will be written to the TCSes.
The existing RSCes can be considered running with a single channel.
Change-Id: Id0956136f37c28f2039e139d21f63ade5044ae1f
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
RSC major version 3.0 has different register offsets than previous
versions. Add support to read the current version during probe and
use register offsets accordingly.
Change-Id: I8174516ecd2ab7a370e1bb6592d4329c4ff1f81d
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
In addition to logging using FTRACE. let's also log in the IPC logging
for all RPMH transactions.
Change-Id: I2b19006bbc776053f63eee55b447428fdb023ba4
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
The RSC interrupt is issued only after the request is complete. For
fire-n-forget requests, the irq-done interrupt is sent after issuing the
RPMH request and for response-required request, the interrupt is
triggered only after all the requests are complete.
These unnecessary checks in the interrupt handler issues AHB reads from
a critical path. Let's remove them and clean up error handling in
rpmh_request data structures.
Change-Id: Ie3a3569603f001d6cdb59310c3f2752cdcd7a84d
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
When we crash the system and display the TCS controller state, let's
also dump the fast-path TCS information if there was an active
transaction going on at that time.
Change-Id: Iabc7b8af22dd148fca617e571f1392ba3d9a93ab
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
In order to support lockless RPMh request, let's dedicate a TCS for this
purpose. This TCS shall be defined as FAST_PATH_TCS in the TCS
configuration for the RSC.
The fast-path TCS will have the following properties -
- A single TCS shall be defined as a fast-path TCS.
- Fast-path TCS will not use interrupt for signalling request
completion.
- Fast path will poll controller status for idle before sending request.
- DRV properties are not updated during the fast-path use.
- Fast path requests must be first initialized with {addr, data}.
- Subsequent updates will only update the data in the TCS and trigger.
- Requests must be fire-n-forget only (no completion).
Change-Id: I235ea60159e40affa9ce1e4069e11eca3925a423
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
In OS-Initiated mode of PSCI, a serialization is established in Linux
between the last CPU powering down the cluster / domain and the CPU
powering up back. The serialization is established by the genpd
framework and therefore it doesn't help to lock around the cache.
Refactor out the core of the flush functionality from the locking
wrappers. Calling the core functionality avoids a spin trylock, which
the RCU framework might consider suspicious under the circumstances.
Change-Id: I242fb4827b71152bda36ea5870393054b8703309
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
RSC is part the CPU subsystem and powers off the CPU domains when all
the CPUs and no RPMH transactions are pending from any of the drivers.
The RSC needs to flush the 'sleep' and 'wake' votes that are critical
for saving power when all the CPUs are in idle. Doing this every time a
CPU powers down, increases latency to enter idle state. So, we want to
do this, only when it makes sense - when the last CPU is powering down.
Let's make RSC part of the CPU PM domains, by attaching it to the
cluster PD (defined in DT). Registering for PM domain notifications, RSC
driver can be notified that the last CPU is powering down. When the last
CPU is powering down the domain, let's flush the 'sleep' and 'wake'
votes that are stored in the data buffers into the hardware.
Change-Id: Id748413f0f86a4ac73c37e0780b2b22a143a1e61
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
lockdep_assert_irqs_disabled() was added to check rpmh_flush() can
only be invoked when irqs are disabled, this is true for APPS RSC
as the last CPU going to deepest low power mode is writing sleep and
wake TCSes.
However for Display RSC, drivers can invoke rpmh_write_sleep_and_wake()
to immediately write cached sleep and wake sets to TCSes from any CPU.
Conditionally check if RSC controller supports solver mode then do not
check for irqs disabled as such RSC can write sleep and wake TCSes at any
point.
Change-Id: I8ad05cd81af15a0d57353b55d8098cf0e47f79f7
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Allow RPMH requests to succeed even when the always-On subsystem is not
available. In standalone mode, requests are never sent to the TCS
mailbox driver. The command DB provides the information to make the
decision to run in standalone mode or not.
Change-Id: Ia2bc5024da0d7e6607347b1a481b2feb9584059a
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Controllers may be in 'solver' state, where they could be in autonomous
mode executing low power modes for their hardware and as such are not
available for sending active votes. Device driver may notify RPMH API
that the controller is in solver mode and when in such mode, disallow
requests from platform drivers for state change using the RSC.
Change-Id: Ibe777d23fd58489cfb8132c0168af8e29284084d
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Output the TCS state when the debug api is invoked. The state of the
TCS, the contents and the IRQ status is presented. Additionally, crash
the system if any TCS is busy to help with the debug.
Change-Id: I7ef5480cc6da7208d5f82351d863561fcc1abf68
Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Requests sent to RPMH can be sent as fire-n-forget or response required,
with the latter ensuring the command has been completed by the hardware
accelerator. Commands in a request with tcs_cmd::wait set, would ensure
that those select commands are sent as response required, even though
the actual TCS request may be fire-n-forget.
Also, commands with .wait flag were also guaranteed to be complete
before the following command in the TCS is sent. This means that the
next command of the same request blocked until the current request is
completed. This could mean waiting for a voltage to settle or series of
NOCs be configured before the next command is sent. But drivers using
this feature have never cared about the serialization aspect. By not
enforcing the serialization we can allow the hardware to run in parallel
improving the performance.
Let's clarify the usage of this member in the tcs_cmd structure to mean
only completion and not serialization. This should also improve the
performance of bus requests where changes could happen in parallel.
Also, CPU resume from deep idle may see benefits from certain wake
requests.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://lore.kernel.org/r/1610008770-13891-1-git-send-email-mkshah@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
When triggering a TCS to send its contents, reading back the trigger
value may return an incorrect value. That is because, writing the
trigger may raise an interrupt which could be handled immediately and
the trigger value could be reset in the interrupt handler.
A write_tcs_reg_sync() would read back the value that is written and try
to match it to the value written to ensure that the value is written,
but if that value is different, we may see false error for same.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://lore.kernel.org/r/1606211610-15168-1-git-send-email-mkshah@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Commit efde2659b0 ("drivers: qcom: rpmh-rsc: Use rcuidle tracepoints
for rpmh") was written to fix a bug seen in an unmerged series that
implemented a struct generic_pm_domain::power_off() callback calling
rpmh_flush(). See stack trace below.
Call trace:
dump_backtrace+0x0/0x174
show_stack+0x20/0x2c
dump_stack+0xc8/0x124
lockdep_rcu_suspicious+0xe4/0x104
__tcs_buffer_write+0x230/0x2d0
rpmh_rsc_write_ctrl_data+0x210/0x270
rpmh_flush+0x84/0x24c
rpmh_domain_power_off+0x78/0x98
_genpd_power_off+0x40/0xc0
genpd_power_off+0x168/0x208
Later the final merged solution is to use CPU PM notification to invoke
rpmh_flush() and power_off() callback of genpd is not implemented in the
driver.
CPU PM notifiers are run with RCU enabled/watching (see cpu_pm_notify()
and how it calls rcu_irq_enter_irqson() before calling the notifiers).
Remove this change since RCU will not be idle during CPU PM notifications
hence not required to use _rcuidle tracepoint. Using _rcuidle tracepoint
prevented rpmh driver to be loadable module as these are not exported
symbols.
This reverts commit efde2659b0.
Cc: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/1601877596-32676-2-git-send-email-mkshah@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The busy loop in rpmh_rsc_send_data() is written with the assumption
that the udelay will be preempted by the tcs_tx_done() irq handler when
the TCS slots are all full. This doesn't hold true when the calling
thread is an irqthread and the tcs_tx_done() irq is also an irqthread.
That's because kernel irqthreads are SCHED_FIFO and thus need to
voluntarily give up priority by calling into the scheduler so that other
threads can run.
I see RCU stalls when I boot with irqthreads on the kernel commandline
because the modem remoteproc driver is trying to send an rpmh async
message from an irqthread that needs to give up the CPU for the rpmh
irqthread to run and clear out tcs slots.
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 0-....: (1 GPs behind) idle=402/1/0x4000000000000002 softirq=2108/2109 fqs=4920
(t=21016 jiffies g=2933 q=590)
Task dump for CPU 0:
irq/11-smp2p R running task 0 148 2 0x00000028
Call trace:
dump_backtrace+0x0/0x154
show_stack+0x20/0x2c
sched_show_task+0xfc/0x108
dump_cpu_task+0x44/0x50
rcu_dump_cpu_stacks+0xa4/0xf8
rcu_sched_clock_irq+0x7dc/0xaa8
update_process_times+0x30/0x54
tick_sched_handle+0x50/0x64
tick_sched_timer+0x4c/0x8c
__hrtimer_run_queues+0x21c/0x36c
hrtimer_interrupt+0xf0/0x22c
arch_timer_handler_phys+0x40/0x50
handle_percpu_devid_irq+0x114/0x25c
__handle_domain_irq+0x84/0xc4
gic_handle_irq+0xd0/0x178
el1_irq+0xbc/0x180
save_return_addr+0x18/0x28
return_address+0x54/0x88
preempt_count_sub+0x40/0x88
_raw_spin_unlock_irqrestore+0x4c/0x6c
___ratelimit+0xd0/0x128
rpmh_rsc_send_data+0x24c/0x378
__rpmh_write+0x1b0/0x208
rpmh_write_async+0x90/0xbc
rpmhpd_send_corner+0x60/0x8c
rpmhpd_aggregate_corner+0x8c/0x124
rpmhpd_set_performance_state+0x8c/0xbc
_genpd_set_performance_state+0xdc/0x1b8
dev_pm_genpd_set_performance_state+0xb8/0xf8
q6v5_pds_disable+0x34/0x60 [qcom_q6v5_mss]
qcom_msa_handover+0x38/0x44 [qcom_q6v5_mss]
q6v5_handover_interrupt+0x24/0x3c [qcom_q6v5]
handle_nested_irq+0xd0/0x138
qcom_smp2p_intr+0x188/0x200
irq_thread_fn+0x2c/0x70
irq_thread+0xfc/0x14c
kthread+0x11c/0x12c
ret_from_fork+0x10/0x18
This busy loop naturally lends itself to using a wait queue so that each
thread that tries to send a message will sleep waiting on the waitqueue
and only be woken up when a free slot is available. This should make
things more predictable too because the scheduler will be able to sleep
tasks that are waiting on a free tcs instead of the busy loop we
currently have today.
Reviewed-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Maulik Shah <mkshah@codeaurora.org>
Cc: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20200724211711.810009-1-sboyd@kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The write_tcs_reg_sync() may be called after timekeeping is suspended
so it's not OK to use ktime. The readl_poll_timeout_atomic() macro
implicitly uses ktime. This was causing a warning at suspend time.
Change to just loop 1000000 times with a delay of 1 us between loops.
This may give a timeout of more than 1 second but never less and is
safe even if timekeeping is suspended.
NOTE: I don't have any actual evidence that we need to loop here.
It's possibly that all we really need to do is just read the value
back to ensure that the pipes are cleaned and the looping/comparing is
totally not needed. I never saw the loop being needed in my tests.
However, the loop shouldn't hurt.
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Maulik Shah <mkshah@codeaurora.org>
Fixes: 91160150ab ("soc: qcom: rpmh-rsc: Timeout after 1 second in write_tcs_reg_sync()")
Reported-by: Maulik Shah <mkshah@codeaurora.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200528074530.1.Ib86e5b406fe7d16575ae1bb276d650faa144b63c@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Attempting to compile rpmh-rsc.c as a module with TRACING enabled causes
a build error as no _rcuidle function is generated for tracepoints when
CONFIG_MODULE is set.
Attempts has been made, but no resolution has been agreed upon, so lets
revert this commit for now.
This reverts commit 1d3c6f86fd.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
It has been postulated that the pm_lock is bad for performance because
a CPU currently running rpmh_flush() could block other CPUs from
coming out of idle. Similarly CPUs coming out of / going into idle
all need to contend with each other for the spinlock just to update
the variable tracking who's in PM.
Let's optimize this a bit. Specifically:
- Use a count rather than a bitmask. This is faster to access and
also means we can use the atomic_inc_return() function to really
detect who the last one to enter PM was.
- Accept that it's OK if we race and are doing the flush (because we
think we're last) while another CPU is coming out of idle. As long
as we block that CPU if/when it tries to do an active-only transfer
we're OK.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20200504104917.v6.5.I295cb72bc5334a2af80313cbe97cb5c9dcb1442c@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The rpmh-rsc code had both a driver-level lock (sometimes referred to
in comments as drv->lock) and a lock per-TCS. The idea was supposed
to be that there would be times where you could get by with just
locking a TCS lock and therefor other RPMH users wouldn't be blocked.
The above didn't work out so well.
Looking at tcs_write() the bigger drv->lock was held for most of the
function anyway. Only the __tcs_buffer_write() and
__tcs_set_trigger() calls were called without holding the drv->lock.
It actually turns out that in tcs_write() we don't need to hold the
drv->lock for those function calls anyway even if the per-TCS lock
isn't there anymore. From the newly added comments in the code, this
is because:
- We marked "tcs_in_use" under lock.
- Once "tcs_in_use" has been marked nobody else could be writing
to these registers until the interrupt goes off.
- The interrupt can't go off until we trigger w/ the last line
of __tcs_set_trigger().
Thus, from a tcs_write() point of view, the per-TCS lock was useless.
Looking at rpmh_rsc_write_ctrl_data(), only the per-TCS lock was held.
It turns out, though, that this function already needs to be called
with the equivalent of the drv->lock held anyway (we either need to
hold drv->lock as we will in a future patch or we need to know no
other CPUs could be running as happens today). Specifically
rpmh_rsc_write_ctrl_data() might be writing to a TCS that has been
borrowed for writing an active transation but it never checks this.
Let's eliminate this extra overhead and avoid possible AB BA locking
headaches.
Suggested-by: Maulik Shah <mkshah@codeaurora.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20200504104917.v6.4.Ib8dccfdb10bf6b1fb1d600ca1c21d9c0db1ef746@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
When a PM Notifier returns NOTIFY_BAD it doesn't get called with
CPU_PM_ENTER_FAILED. It only get called for CPU_PM_ENTER_FAILED if
someone else (further down the notifier chain) returns NOTIFY_BAD.
Handle this case by taking our CPU out of the list of ones that have
entered PM. Without this it's possible we could detect that the last
CPU went down (and we would flush) even if some CPU was alive. That's
not good since our flushing routines currently assume they're running
on the last CPU for mutual exclusion.
Fixes: 985427f997 ("soc: qcom: rpmh: Invoke rpmh_flush() for dirty caches")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20200504104917.v6.2.I1927d1bca2569a27b2d04986baf285027f0818a2@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Our switch statement doesn't have entries for CPU_CLUSTER_PM_ENTER,
CPU_CLUSTER_PM_ENTER_FAILED, and CPU_CLUSTER_PM_EXIT and doesn't have
a default. This means that we'll try to do a flush in those cases but
we won't necessarily be the last CPU down. That's not so ideal since
our (lack of) locking assumes we're on the last CPU.
Luckily this isn't as big a problem as you'd think since (at least on
the SoC I tested) we don't get these notifications except on full
system suspend. ...and on full system suspend we get them on the last
CPU down. That means that the worst problem we hit is flushing twice.
Still, it's good to make it correct.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Fixes: 985427f997 ("soc: qcom: rpmh: Invoke rpmh_flush() for dirty caches")
Reported-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200504104917.v6.1.Ic7096b3b9b7828cdd41cd5469a6dee5eb6abf549@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
