linux-toradex.git/drivers/clk, 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

Merge tag 'clk-microchip-fixes-6.1' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-fixes

2022-11-23T00:43:18+00:00

Pull Microchip clk driver fixes from Claudiu Beznea:

 - fix the clock ID for USB device port on AT91 RM9200 SoCs; along with it the
   device tree references to this clocks were fixed in this patch to ease the
   backporting and to avoid USB driver probe failure.

* tag 'clk-microchip-fixes-6.1' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
  ARM: at91: rm9200: fix usb device clock id

Merge tag 'samsung-clk-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into clk-fixes

2022-11-23T00:35:46+00:00

Pull Samsung SoC clk driver fixes from Krzysztof Kozlowski:

 - Fix calling of_device_get_match_data() on wrong device (parent's) in
   Exynos clock out driver
 - Correct clock name in bindings of ExynosAutov9 clocks
 - Correct parents of div4 clock on Exynos7885

* tag 'samsung-clk-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
  clk: samsung: Revert "clk: samsung: exynos-clkout: Use of_device_get_match_data()"
  dt-bindings: clock: exynosautov9: fix reference to CMU_FSYS1
  clk: samsung: exynos7885: Correct "div4" clock parents

ARM: at91: rm9200: fix usb device clock id

2022-11-17T13:35:52+00:00

Referring to the datasheet the index 2 is the MCKUDP. When enabled, it
"Enables the automatic disable of the Master Clock of the USB Device
Port when a suspend condition occurs". We fix the index to the real UDP
id which "Enables the 48 MHz clock of the USB Device Port".

Cc: nicolas.ferre@microchip.com
Cc: ludovic.desroches@microchip.com
Cc: alexandre.belloni@bootlin.com
Cc: mturquette@baylibre.com
Cc: sboyd@kernel.org
Cc: claudiu.beznea@microchip.com
Cc: linux-clk@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: kernel@pengutronix.de
Fixes: 02ff48e4d7f7 ("clk: at91: add at91rm9200 pmc driver")
Fixes: 0e0e528d8260 ("ARM: dts: at91: rm9200: switch to new clock bindings")
Reviewed-by: Claudiu Beznea 
Signed-off-by: Michael Grzeschik 
Signed-off-by: Claudiu Beznea 
Link: https://lore.kernel.org/r/20221114185923.1023249-2-m.grzeschik@pengutronix.de

clk: samsung: Revert "clk: samsung: exynos-clkout: Use of_device_get_match_data()"

2022-11-15T09:36:54+00:00

of_device_get_match_data() function should not be used on the device
other than the one matched to the given driver, because it always returns
the match_data of the matched driver. In case of exynos-clkout driver,
the code matched the OF IDs on the PARENT device, so replacing it with
of_device_get_match_data() broke the driver.

This reverts commit 777aaf3d1daf793461269b49c063aca1cee06a44.

Signed-off-by: Marek Szyprowski 
Fixes: 777aaf3d1daf ("clk: samsung: exynos-clkout: Use of_device_get_match_data()")
Reviewed-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20221108213718.32076-1-m.szyprowski@samsung.com
Signed-off-by: Krzysztof Kozlowski

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

clk: Initialize max_rate in struct clk_rate_request

2022-10-28T00:08:41+00:00

Since commit b46fd8dbe8ad ("clk: Zero the clk_rate_request structure"),
the clk_core_init_rate_req() function clears the struct clk_rate_request
passed as argument.

However, the default value for max_rate isn't 0 but ULONG_MAX, and we
end up creating a clk_rate_request instance where the maximum rate is 0.

Let's initialize max_rate to ULONG_MAX properly.

Fixes: b46fd8dbe8ad ("clk: Zero the clk_rate_request structure")
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v1-3-f3ef80518140@cerno.tech
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Stephen Boyd

clk: Initialize the clk_rate_request even if clk_core is NULL

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

Since commit c35e84b09776 ("clk: Introduce clk_hw_init_rate_request()"),
users that used to initialize their clk_rate_request by initializing
their local structure now rely on clk_hw_init_rate_request().

This function is backed by clk_core_init_rate_req(), which will skip the
initialization if either the pointer to struct clk_core or to struct
clk_rate_request are NULL.

However, the core->parent pointer might be NULL because the clock is
orphan, and we will thus end up with our local struct clk_rate_request
left untouched.

And since clk_hw_init_rate_request() doesn't return an error, we will
then call a determine_rate variant with that unitialized structure.

In order to avoid this, let's clear our clk_rate_request if the pointer
to it is valid but the pointer to struct clk_core isn't.

Fixes: c35e84b09776 ("clk: Introduce clk_hw_init_rate_request()")
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v1-2-f3ef80518140@cerno.tech
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Stephen Boyd

clk: Remove WARN_ON NULL parent in clk_core_init_rate_req()

2022-10-28T00:06:50+00:00

If a clock has CLK_SET_RATE_PARENT, but core->parent is NULL (most
likely because it's orphan), callers of clk_core_init_rate_req() will
blindly call this function leading to a very verbose warning.

Since it's a fairly common situation, let's just remove the WARN_ON but
keep the check that prevents us from dereferencing the pointer.

Interestingly, it fixes a regression on the Mediatek MT8195 where the
GPU would stall during a clk_set_rate for its main clock. We couldn't
come up with a proper explanation since the condition is essentially the
same.

It was then assumed that it could be timing related since printing the
warning stacktrace takes a while, but we couldn't replicate the failure
by using fairly large (10ms) mdelays.

Fixes: 262ca38f4b6e ("clk: Stop forwarding clk_rate_requests to the parent")
Reported-by: AngeloGioacchino Del Regno 
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v1-1-f3ef80518140@cerno.tech
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Stephen Boyd