linux.git/drivers/clk/qcom, branch v6.1

clk: qcom: gcc-sc8280xp: add cxo as parent for three ufs ref clks

2022-11-23T02:27:07+00:00

The three UFS reference clocks, gcc_ufs_ref_clkref_clk for external
UFS devices, gcc_ufs_card_clkref_clk and gcc_ufs_1_card_clkref_clk for
two PHYs are all sourced from CXO.

Added parent_data for all three reference clocks described above to
reflect that all three clocks are sourced from CXO to have valid
frequency for the ref clock needed by UFS controller driver.

Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver")
Link: https://lore.kernel.org/lkml/Y2Tber39cHuOSR%2FW@hovoldconsulting.com/
Signed-off-by: Shazad Hussain 
Tested-by: Johan Hovold 
Reviewed-by: Johan Hovold 
Tested-by: Andrew Halaney 
Reviewed-by: Andrew Halaney 
Reviewed-by: Brian Masney 
Link: https://lore.kernel.org/r/20221115152956.21677-1-quic_shazhuss@quicinc.com
Reviewed-by: Bjorn Andersson 
Signed-off-by: Stephen Boyd

clk: qcom: gdsc: Remove direct runtime PM calls

2022-11-04T18:53:49+00:00

We shouldn't be calling runtime PM APIs from within the genpd
enable/disable path for a couple reasons.

First, this causes an AA lockdep splat[1] because genpd can call into
genpd code again while holding the genpd lock.

WARNING: possible recursive locking detected
5.19.0-rc2-lockdep+ #7 Not tainted
--------------------------------------------
kworker/2:1/49 is trying to acquire lock:
ffffffeea0370788 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x24/0x30

but task is already holding lock:
ffffffeea03710a8 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x24/0x30

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&genpd->mlock);
  lock(&genpd->mlock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

3 locks held by kworker/2:1/49:
 #0: 74ffff80811a5748 ((wq_completion)pm){+.+.}-{0:0}, at: process_one_work+0x320/0x5fc
 #1: ffffffc008537cf8 ((work_completion)(&genpd->power_off_work)){+.+.}-{0:0}, at: process_one_work+0x354/0x5fc
 #2: ffffffeea03710a8 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x24/0x30

stack backtrace:
CPU: 2 PID: 49 Comm: kworker/2:1 Not tainted 5.19.0-rc2-lockdep+ #7
Hardware name: Google Lazor (rev3 - 8) with KB Backlight (DT)
Workqueue: pm genpd_power_off_work_fn
Call trace:
 dump_backtrace+0x1a0/0x200
 show_stack+0x24/0x30
 dump_stack_lvl+0x7c/0xa0
 dump_stack+0x18/0x44
 __lock_acquire+0xb38/0x3634
 lock_acquire+0x180/0x2d4
 __mutex_lock_common+0x118/0xe30
 mutex_lock_nested+0x70/0x7c
 genpd_lock_mtx+0x24/0x30
 genpd_runtime_suspend+0x2f0/0x414
 __rpm_callback+0xdc/0x1b8
 rpm_callback+0x4c/0xcc
 rpm_suspend+0x21c/0x5f0
 rpm_idle+0x17c/0x1e0
 __pm_runtime_idle+0x78/0xcc
 gdsc_disable+0x24c/0x26c
 _genpd_power_off+0xd4/0x1c4
 genpd_power_off+0x2d8/0x41c
 genpd_power_off_work_fn+0x60/0x94
 process_one_work+0x398/0x5fc
 worker_thread+0x42c/0x6c4
 kthread+0x194/0x1b4
 ret_from_fork+0x10/0x20

Second, this confuses runtime PM on CoachZ for the camera devices by
causing the camera clock controller's runtime PM usage_count to go
negative after resuming from suspend. This is because runtime PM is
being used on the clock controller while runtime PM is disabled for the
device.

The reason for the negative count is because a GDSC is represented as a
genpd and each genpd that is attached to a device is resumed during the
noirq phase of system wide suspend/resume (see the noirq suspend ops
assignment in pm_genpd_init() for more details). The camera GDSCs are
attached to camera devices with the 'power-domains' property in DT.
Every device has runtime PM disabled in the late system suspend phase
via __device_suspend_late(). Runtime PM is not usable until runtime PM
is enabled in device_resume_early(). The noirq phases run after the
'late' and before the 'early' phase of suspend/resume. When the genpds
are resumed in genpd_resume_noirq(), we call down into gdsc_enable()
that calls pm_runtime_resume_and_get() and that returns -EACCES to
indicate failure to resume because runtime PM is disabled for all
devices.

Upon closer inspection, calling runtime PM APIs like this in the GDSC
driver doesn't make sense. It was intended to make sure the GDSC for the
clock controller providing other GDSCs was enabled, specifically the
MMCX GDSC for the display clk controller on SM8250 (sm8250-dispcc), so
that GDSC register accesses succeeded. That will already happen because
we make the 'dev->pm_domain' a parent domain of each GDSC we register in
gdsc_register() via pm_genpd_add_subdomain(). When any of these GDSCs
are accessed, we'll enable the parent domain (in this specific case
MMCX).

We also remove any getting of runtime PM during registration, because
when a genpd is registered it increments the count on the parent if the
genpd itself is already enabled.

Cc: Dmitry Baryshkov 
Cc: Johan Hovold 
Cc: Ulf Hansson 
Cc: Taniya Das 
Cc: Satya Priya 
Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 
Cc: Matthias Kaehlcke 
Reported-by: Stephen Boyd 
Link: https://lore.kernel.org/r/CAE-0n52xbZeJ66RaKwggeRB57fUAwjvxGxfFMKOKJMKVyFTe+w@mail.gmail.com [1]
Fixes: 1b771839de05 ("clk: qcom: gdsc: enable optional power domain support")
Signed-off-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20221103183030.3594899-1-swboyd@chromium.org
Tested-by: Johan Hovold 
Reviewed-by: Johan Hovold 
Signed-off-by: Stephen Boyd

clk: qcom: Update the force mem core bit for GPU clocks

2022-10-28T00:23:29+00:00

There are few GPU clocks which are powering up the memories
and thus enable the FORCE_MEM_PERIPH always for these clocks
to force the periph_on signal to remain active during halt
state of the clock.

Fixes: a3cc092196ef ("clk: qcom: Add Global Clock controller (GCC) driver for SC7280")
Fixes: 3e0f01d6c7e7 ("clk: qcom: Add graphics clock controller driver for SC7280")
Signed-off-by: Taniya Das 
Signed-off-by: Satya Priya 
Link: https://lore.kernel.org/r/1666159535-6447-1-git-send-email-quic_c_skakit@quicinc.com
Signed-off-by: Stephen Boyd

Merge branch 'clk-rate-range' into clk-next

2022-10-14T20:44:44+00:00

 - Various clk rate range fixes
 - Drop clk rate range constraints on clk_put() (redux)

* clk-rate-range: (28 commits)
  clk: mediatek: clk-mux: Add .determine_rate() callback
  clk: tests: Add tests for notifiers
  clk: Update req_rate on __clk_recalc_rates()
  clk: tests: Add missing test case for ranges
  clk: qcom: clk-rcg2: Take clock boundaries into consideration for gfx3d
  clk: Introduce the clk_hw_get_rate_range function
  clk: Zero the clk_rate_request structure
  clk: Stop forwarding clk_rate_requests to the parent
  clk: Constify clk_has_parent()
  clk: Introduce clk_core_has_parent()
  clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock
  clk: Add our request boundaries in clk_core_init_rate_req
  clk: Introduce clk_hw_init_rate_request()
  clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock() to its caller
  clk: Change clk_core_init_rate_req prototype
  clk: Set req_rate on reparenting
  clk: Take into account uncached clocks in clk_set_rate_range()
  clk: tests: Add some tests for orphan with multiple parents
  clk: tests: Add tests for mux with multiple parents
  clk: tests: Add tests for single parent mux
  ...

clk: qcom: gcc-msm8660: Drop hardcoded fixed board clocks

2022-10-14T20:39:09+00:00

These two clocks are now registered in the device tree as fixed clocks,
causing a regression in the driver as the clock already exists with
e.g. the name "pxo_board" as the MSM8660 GCC driver probes.

Fix this by just not hard-coding this anymore and everything works
like a charm.

Cc: Dmitry Baryshkov 
Fixes: baecbda52933 ("ARM: dts: qcom: msm8660: fix node names for fixed clocks")
Signed-off-by: Linus Walleij 
Link: https://lore.kernel.org/r/20221013140745.7801-1-linus.walleij@linaro.org
Signed-off-by: Stephen Boyd

clk: qcom: gcc-sm6375: Ensure unsigned long type

2022-10-04T17:24:26+00:00

This PLL frequency needs a UL postfix to avoid compiler warnings on
32-bit architectures.

Fixes: 184fdd873d83 ("clk: qcom: Add global clock controller driver for SM6375")
Cc: Konrad Dybcio 
Signed-off-by: Stephen Boyd

clk: qcom: gcc-sm6375: Remove unused variables

2022-10-04T17:18:19+00:00

gcc_parent_data_15 and gcc_parent_map_15 are not used in this driver.
Remove them.

Signed-off-by: Konrad Dybcio 
Link: https://lore.kernel.org/r/20221003211438.25691-1-konrad.dybcio@somainline.org
Fixes: 184fdd873d83 ("clk: qcom: Add global clock controller driver for SM6375")
Signed-off-by: Stephen Boyd

clk: qcom: kpss-xcc: convert to parent data API

2022-10-04T03:50:22+00:00

Convert the driver to parent data API. From the Documentation pll8_vote
and pxo should be declared in the DTS so fw_name can be used instead of
parent_names. .name is changed to the legacy pxo_board following how
it's declared in other drivers.

Signed-off-by: Christian Marangi 
Link: https://lore.kernel.org/r/20220914144743.17369-2-ansuelsmth@gmail.com
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Stephen Boyd

clk: qcom: gcc-msm8939: use ARRAY_SIZE instead of specifying num_parents

2022-09-29T16:42:12+00:00

Use ARRAY_SIZE() instead of manually specifying num_parents. This makes
adding/removing entries to/from parent_data easy and errorproof.

Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Bryan O'Donoghue 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20220928145609.375860-4-dmitry.baryshkov@linaro.org

clk: qcom: gcc-msm8939: use parent_hws where possible

2022-09-29T16:42:12+00:00

Use parent_hws instead of hanving parent_data with just a single .hw
entry to speed up and simplify parent lookups.

Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20220928145609.375860-3-dmitry.baryshkov@linaro.org