<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/clk/qcom, branch v5.10.78</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.78</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.78'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-08-26T12:35:54+00:00</updated>
<entry>
<title>clk: qcom: gdsc: Ensure regulator init state matches GDSC state</title>
<updated>2021-08-26T12:35:54+00:00</updated>
<author>
<name>Bjorn Andersson</name>
<email>bjorn.andersson@linaro.org</email>
</author>
<published>2021-07-21T22:40:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7451c309c7a3605a210523f2fb8e78cdd994708b'/>
<id>urn:sha1:7451c309c7a3605a210523f2fb8e78cdd994708b</id>
<content type='text'>
[ Upstream commit 9711759a87a041705148161b937ec847048d882e ]

As GDSCs are registered and found to be already enabled gdsc_init()
ensures that 1) the kernel state matches the hardware state, and 2)
votable GDSCs are properly enabled from this master as well.

But as the (optional) supply regulator is enabled deep into
gdsc_toggle_logic(), which is only executed for votable GDSCs, the
kernel's state of the regulator might not match the hardware. The
regulator might be automatically turned off if no other users are
present or the next call to gdsc_disable() would cause an unbalanced
regulator_disable().

Given that the votable case deals with an already enabled GDSC, most of
gdsc_enable() and gdsc_toggle_logic() can be skipped. Reduce it to just
clearing the SW_COLLAPSE_MASK and enabling hardware control to simply
call regulator_enable() in both cases.

The enablement of hardware control seems to be an independent property
from the GDSC being enabled, so this is moved outside that conditional
segment.

Lastly, as the propagation of ALWAYS_ON to GENPD_FLAG_ALWAYS_ON needs to
happen regardless of the initial state this is grouped together with the
other sc-&gt;pd updates at the end of the function.

Cc: stable@vger.kernel.org
Fixes: 37416e554961 ("clk: qcom: gdsc: Handle GDSC regulator supplies")
Signed-off-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Link: https://lore.kernel.org/r/20210721224056.3035016-1-bjorn.andersson@linaro.org
[sboyd@kernel.org: Rephrase commit text]
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: qcom: clk-alpha-pll: fix CAL_L write in alpha_pll_fabia_prepare</title>
<updated>2021-07-14T14:56:31+00:00</updated>
<author>
<name>Jonathan Marek</name>
<email>jonathan@marek.ca</email>
</author>
<published>2021-06-09T02:28:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29746bd0f765f0d2f77b5f6de6050e60007fefe7'/>
<id>urn:sha1:29746bd0f765f0d2f77b5f6de6050e60007fefe7</id>
<content type='text'>
[ Upstream commit 7f54bf2640e877c8a9b4cc7e2b29f82e3ca1a284 ]

Caught this when looking at alpha-pll code. Untested but it is clear that
this was intended to write to PLL_CAL_L_VAL and not PLL_ALPHA_VAL.

Fixes: 691865bad627 ("clk: qcom: clk-alpha-pll: Add support for Fabia PLL calibration")
Signed-off-by: Jonathan Marek &lt;jonathan@marek.ca&gt;
Link: https://lore.kernel.org/r/20210609022852.4151-1-jonathan@marek.ca
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: qcom: apss-ipq-pll: Add missing MODULE_DEVICE_TABLE</title>
<updated>2021-05-14T07:50:26+00:00</updated>
<author>
<name>Chen Hui</name>
<email>clare.chenhui@huawei.com</email>
</author>
<published>2021-04-09T08:23:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3968d95f31165cfe6eb4c1a2954d419bcedd5a08'/>
<id>urn:sha1:3968d95f31165cfe6eb4c1a2954d419bcedd5a08</id>
<content type='text'>
[ Upstream commit d0a859edda46b45baeab9687d173102300d76e2b ]

CONFIG_IPQ_APSS_PLL is tristate option and therefore this driver can
be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE
definition which generates correct modalias for automatic loading of
this driver when it is built as an external module.

Fixes: ecd2bacfbbc4 ("clk: qcom: Add ipq apss pll driver")
Signed-off-by: Chen Hui &lt;clare.chenhui@huawei.com&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Link: https://lore.kernel.org/r/20210409082352.233810-4-clare.chenhui@huawei.com
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: qcom: a53-pll: Add missing MODULE_DEVICE_TABLE</title>
<updated>2021-05-14T07:50:26+00:00</updated>
<author>
<name>Chen Hui</name>
<email>clare.chenhui@huawei.com</email>
</author>
<published>2021-04-09T08:23:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=edc6a44bcc49fd6d7050da1ef5fbbf661d28116b'/>
<id>urn:sha1:edc6a44bcc49fd6d7050da1ef5fbbf661d28116b</id>
<content type='text'>
[ Upstream commit 790b516ada10a4dcc0f0a56dc0ced475d86d5820 ]

CONFIG_QCOM_A53PLL is tristate option and therefore this driver can be
compiled as a module. This patch adds missing MODULE_DEVICE_TABLE
definition which generates correct modalias for automatic loading of
this driver when it is built as an external module.

Fixes: 0c6ab1b8f894 ("clk: qcom: Add A53 PLL support")
Signed-off-by: Chen Hui &lt;clare.chenhui@huawei.com&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Link: https://lore.kernel.org/r/20210409082352.233810-3-clare.chenhui@huawei.com
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: qcom: gcc-sc7180: Use floor ops for the correct sdcc1 clk</title>
<updated>2021-03-30T12:31:58+00:00</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2021-02-24T17:50:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1701bd22b05d772cfd1a3fac15d4e00b57215c87'/>
<id>urn:sha1:1701bd22b05d772cfd1a3fac15d4e00b57215c87</id>
<content type='text'>
[ Upstream commit 148ddaa89d4a0a927c4353398096cc33687755c1 ]

While picking commit a8cd989e1a57 ("mmc: sdhci-msm: Warn about
overclocking SD/MMC") back to my tree I was surprised that it was
reporting warnings.  I thought I fixed those!  Looking closer at the
fix, I see that I totally bungled it (or at least I halfway bungled
it).  The SD card clock got fixed (and that was the one I was really
focused on fixing), but I totally adjusted the wrong clock for eMMC.
Sigh.  Let's fix my dumb mistake.

Now both SD and eMMC have floor for the "apps" clock.

This doesn't matter a lot for the final clock rate for HS400 eMMC but
could matter if someone happens to put some slower eMMC on a sc7180.
We also transition through some of these lower rates sometimes and
having them wrong could cause problems during these transitions.
These were the messages I was seeing at boot:
  mmc1: Card appears overclocked; req 52000000 Hz, actual 100000000 Hz
  mmc1: Card appears overclocked; req 52000000 Hz, actual 100000000 Hz
  mmc1: Card appears overclocked; req 104000000 Hz, actual 192000000 Hz

Fixes: 6d37a8d19283 ("clk: qcom: gcc-sc7180: Use floor ops for sdcc clks")
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Link: https://lore.kernel.org/r/20210224095013.1.I2e2ba4978cfca06520dfb5d757768f9c42140f7c@changeid
Reviewed-by: Taniya Das &lt;tdas@codeaurora.org&gt;
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: qcom: gpucc-msm8998: Add resets, cxc, fix flags on gpu_gx_gdsc</title>
<updated>2021-03-17T16:06:26+00:00</updated>
<author>
<name>AngeloGioacchino Del Regno</name>
<email>angelogioacchino.delregno@somainline.org</email>
</author>
<published>2021-01-14T22:10:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=73d1a11a198af55f64f908286dde95f6fb9e1650'/>
<id>urn:sha1:73d1a11a198af55f64f908286dde95f6fb9e1650</id>
<content type='text'>
[ Upstream commit a59c16c80bd791878cf81d1d5aae508eeb2e73f1 ]

The GPU GX GDSC has GPU_GX_BCR reset and gfx3d_clk CXC, as stated
on downstream kernels (and as verified upstream, because otherwise
random lockups happen).
Also, add PWRSTS_RET and NO_RET_PERIPH: also as found downstream,
and also as verified here, to avoid GPU related lockups it is
necessary to force retain mem, but *not* peripheral when enabling
this GDSC (and, of course, the inverse on disablement).

With this change, the GPU finally works flawlessly on my four
different MSM8998 devices from two different manufacturers.

Signed-off-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@somainline.org&gt;
Link: https://lore.kernel.org/r/20210114221059.483390-11-angelogioacchino.delregno@somainline.org
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: qcom: gdsc: Implement NO_RET_PERIPH flag</title>
<updated>2021-03-17T16:06:24+00:00</updated>
<author>
<name>AngeloGioacchino Del Regno</name>
<email>angelogioacchino.delregno@somainline.org</email>
</author>
<published>2021-01-13T18:38:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=661cba45dc67729a0a0e891320f3e3b713638a5b'/>
<id>urn:sha1:661cba45dc67729a0a0e891320f3e3b713638a5b</id>
<content type='text'>
[ Upstream commit 785c02eb35009a4be6dbc68f4f7d916e90b7177d ]

In some rare occasions, we want to only set the RETAIN_MEM bit, but
not the RETAIN_PERIPH one: this is seen on at least SDM630/636/660's
GPU-GX GDSC, where unsetting and setting back the RETAIN_PERIPH bit
will generate chaos and panics during GPU suspend time (mainly, the
chaos is unaligned access).

For this reason, introduce a new NO_RET_PERIPH flag to the GDSC
driver to address this corner case.

Signed-off-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@somainline.org&gt;
Link: https://lore.kernel.org/r/20210113183817.447866-8-angelogioacchino.delregno@somainline.org
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: qcom: gcc-msm8998: Fix Alpha PLL type for all GPLLs</title>
<updated>2021-03-04T10:38:05+00:00</updated>
<author>
<name>AngeloGioacchino Del Regno</name>
<email>angelogioacchino.delregno@somainline.org</email>
</author>
<published>2021-01-14T22:10:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1989b09d76457a62bdfcef6a6e201967587f4fcb'/>
<id>urn:sha1:1989b09d76457a62bdfcef6a6e201967587f4fcb</id>
<content type='text'>
[ Upstream commit 292f75ecff07e8a07fe2e3e19b4b567d0b698842 ]

All of the GPLLs in the MSM8998 Global Clock Controller are Fabia PLLs
and not generic alphas: this was producing bad effects over the entire
clock tree of MSM8998, where any GPLL child clock was declaring a false
clock rate, due to their parent also showing the same.

The issue resides in the calculation of the clock rate for the specific
Alpha PLL type, where Fabia has a different register layout; switching
the MSM8998 GPLLs to the correct Alpha Fabia PLL type fixes the rate
(calculation) reading. While at it, also make these PLLs fixed since
their rate is supposed to *never* be changed while the system runs, as
this would surely crash the entire SoC.

Now all the children of all the PLLs are also complying with their
specified clock table and system stability is improved.

Fixes: b5f5f525c547 ("clk: qcom: Add MSM8998 Global Clock Control (GCC) driver")
Signed-off-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@somainline.org&gt;
Link: https://lore.kernel.org/r/20210114221059.483390-7-angelogioacchino.delregno@somainline.org
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: qcom: gcc-sm250: Use floor ops for sdcc clks</title>
<updated>2021-02-03T22:28:44+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@linaro.org</email>
</author>
<published>2021-01-09T01:33:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d095985e1ce1bff50ebae8e528fe9174b375e8ad'/>
<id>urn:sha1:d095985e1ce1bff50ebae8e528fe9174b375e8ad</id>
<content type='text'>
commit fd2383093593b23f8814a879093b746e502fe3cf upstream.

Followup to the commits 5e4b7e82d497 ("clk: qcom: gcc-sdm845: Use floor
ops for sdcc clks") and 6d37a8d19283 ("clk: qcom: gcc-sc7180: Use floor ops
for sdcc clks"). Use floor ops for sdcc clocks on sm8250.

Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Fixes: 3e5770921a88 ("clk: qcom: gcc: Add global clock controller driver for SM8250")
Link: https://lore.kernel.org/r/20210109013314.3443134-1-dmitry.baryshkov@linaro.org
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>clk: qcom: gcc-sc7180: Use floor ops for sdcc clks</title>
<updated>2020-12-30T10:53:48+00:00</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2020-12-10T18:22:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=be5c560996ac9ed1e3f3f1e03c8c090f39a71e8a'/>
<id>urn:sha1:be5c560996ac9ed1e3f3f1e03c8c090f39a71e8a</id>
<content type='text'>
[ Upstream commit 6d37a8d192830267e6b10a6d57ae28d2e89097e7 ]

I would repeat the same commit message that was in commit 5e4b7e82d497
("clk: qcom: gcc-sdm845: Use floor ops for sdcc clks") but it seems
silly to do so when you could just go read that commit.

NOTE: this is actually extra terrible because we're missing the 50 MHz
rate in the table (see the next patch AKA ("clk: qcom: gcc-sc7180: Add
50 MHz clock rate for SDC2")).  That means then when you run an older
SD card it'll try to clock it at 100 MHz when it's only specced to run
at 50 MHz max.  As you can probably guess that doesn't work super
well.

Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Fixes: 17269568f726 ("clk: qcom: Add Global Clock controller (GCC) driver for SC7180")
Link: https://lore.kernel.org/r/20201210102234.1.I096779f219625148900fc984dd0084ed1ba87c7f@changeid
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
