CONFIG_CC_VERSION_TEXT="x86_64-linux-gnu-gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0"
make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu-, will be failed, like this:
drivers/clk/qcom/gpucc-sm8350.c:111:2: error: initializer element is not constant
gpu_cc_parent,
^~~~~~~~~~~~~
drivers/clk/qcom/gpucc-sm8350.c:111:2: note: (near initialization for ‘gpu_cc_parent_data_0[0]’)
drivers/clk/qcom/gpucc-sm8350.c:126:2: error: initializer element is not constant
gpu_cc_parent,
^~~~~~~~~~~~~
drivers/clk/qcom/gpucc-sm8350.c:126:2: note: (near initialization for ‘gpu_cc_parent_data_1[0]’)
make[3]: *** [drivers/clk/qcom/gpucc-sm8350.o] Error 1
It seems that nested constant initializer is not supported in GCC 7.4.0. For portability resons, we should fix it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 160758b05a ("clk: qcom: add support for SM8350 GPUCC")
Signed-off-by: Ren Zhijie <renzhijie2@huawei.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220714121144.71062-1-renzhijie2@huawei.com
Currently gcc-msm8960 driver manually creates tsens platform device
manually. It would be better to follow IPQ8064 approach, where tsens
device is defined as gcc's child device in the device tree. If nothing
else, it removes gcc's dependency on QFPROM, thus allowing clock
controller to be probed earlier.
Don't create it in case there are available child nodes (tsens) inside
the gcc's device tree node.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220521151437.1489111-4-dmitry.baryshkov@linaro.org
msm8916 has (at least) 6 "General Purpose" clocks that can be muxed to
SoC pins. These clocks are:
GP_CLK{0, 1} : GPIO_{31, 32} (Belongs to CAMSS according to Linux)
GP_CLK_{1-3}{A, B} : GPIO_{49-51, 97, 12, 13} (Belongs to GCC itself)
GP_MN : GPIO_110 (Doesn't seem to be described in gcc,
ignored in this patch)
Those clocks may be used as e.g. PWM sources for external peripherals.
Add more frequencies to the table for those clocks so it's possible
for arbitrary peripherals to make use of them.
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220612145955.385787-5-nikita@trvn.ru
Sometimes calculation of d value may result in 0 because of the
rounding after integer division. This causes the following error:
[ 113.969689] camss_gp1_clk_src: rcg didn't update its configuration.
[ 113.969754] WARNING: CPU: 3 PID: 35 at drivers/clk/qcom/clk-rcg2.c:122 update_config+0xc8/0xdc
Make sure that D value is never zero.
Fixes: 7f891faf59 ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG")
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220612145955.385787-3-nikita@trvn.ru
Currently, attempting to enable the UBI clocks will cause the stuck at
off warning to be printed and clk_enable will fail.
[ 14.936694] gcc_ubi1_ahb_clk status stuck at 'off'
Downstream 5.4 QCA kernel has fixed this by seting the BRANCH_HALT_DELAY
flag on UBI clocks, so lets do the same.
Fixes: 5736294aef ("clk: qcom: ipq8074: add NSS clocks")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220515210048.483898-6-robimarko@gmail.com
NSS port 5 and 6 frequency tables are currently broken and are causing a
wide ranges of issue like 1G not working at all on port 6 or port 5 being
clocked with 312 instead of 125 MHz as UNIPHY1 gets selected.
So, update the frequency tables with the ones from the downstream QCA 5.4
based kernel which has already fixed this.
Fixes: 7117a51ed3 ("clk: qcom: ipq8074: add NSS ethernet port clocks")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220515210048.483898-3-robimarko@gmail.com
UBI32 Huayra PLL fails to lock in 5 us in some SoC silicon and thus it
will cause the wait_for_pll() to timeout and thus return the error
indicating that the PLL failed to lock.
This is bug in Huayra PLL HW for which SW workaround
is to set bit 26 of TEST_CTL register.
This is ported from the QCA 5.4 based downstream kernel.
Fixes: b8e7e51962 ("clk: qcom: ipq8074: add remaining PLL’s")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220515210048.483898-2-robimarko@gmail.com
Like in IPQ6018 the NSS related Alpha PLL-s require initial configuration
to work.
So, obtain the regmap that is required for the Alpha PLL configuration
and thus utilize the qcom_cc_really_probe() as we already have the regmap.
Then utilize the Alpha PLL configs from the downstream QCA 5.4 based
kernel to configure them.
This fixes the UBI32 and NSS crypto PLL-s failing to get enabled by the
kernel.
Fixes: b8e7e51962 ("clk: qcom: ipq8074: add remaining PLL’s")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220515210048.483898-1-robimarko@gmail.com
The msm8939 has an additional higher operating point for the multi-media
peripherals. The higher throughput MM componets operate off of the
system-mm noc not the system noc.
system_mm_noc_bfdcd_clk_src is the source clock for the higher frequency
capable system noc mm.
Maximum frequency for the MM SNOC is 400 MHz.
Fixes: 1664014e46 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller")
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220504163835.40130-4-bryan.odonoghue@linaro.org
Use the new phy-mux clock implementation for the PCIe pipe clock muxes
so that the pipe clock source is set to the QMP PHY PLL when the
downstream pipe clock is enabled and restored to the always-on XO when
it is again disabled.
This is needed to prevent the corresponding GDSC from hanging when
enabling or disabling the PCIe power domain, something which requires a
ticking source.
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220628085707.16214-1-johan+linaro@kernel.org
Access to I/O of SM8250 camera clock controller IP depends on enabled
GCC_CAMERA_AHB_CLK clock supplied by global clock controller, the latter
one is inited on subsys level, so, to satisfy the dependency, it would
make sense to deprive the init level of camcc-sm8250 driver.
If both drivers are compiled as built-in, there is a change that a board
won't boot up due to a race, which happens on the same init level.
Fixes: 5d66ca79b5 ("clk: qcom: Add camera clock controller driver for SM8250")
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220518103554.949511-1-vladimir.zapolskiy@linaro.org
On recent Qualcomm platforms the QMP PIPE clocks feed into a set of
muxes which must be parked to the "safe" source (bi_tcxo) when
corresponding GDSC is turned off and on again. Currently this is
handcoded in the PCIe driver by reparenting the gcc_pipe_N_clk_src
clock. However the same code sequence should be applied in the
pcie-qcom endpoint, USB3 and UFS drivers.
Rather than copying this sequence over and over again, follow the
example of clk_rcg2_shared_ops and implement this parking in the
enable() and disable() clock operations. Supplement the regmap-mux with
the new clk_regmap_phy_mux type, which implements such multiplexers
as a simple gate clocks.
This is possible since each of these multiplexers has just two clock
sources: one coming from the PHY and a reference (XO) one. If the clock
is running off the from-PHY source, report it as enabled. Report it as
disabled otherwise (if it uses reference source).
This way the PHY will disable the pipe clock before turning off the
GDSC, which in turn would lead to disabling corresponding pipe_clk_src
(and thus it being parked to a safe, reference clock source). And vice
versa, after enabling the GDSC the PHY will enable the pipe clock, which
would cause pipe_clk_src to be switched from a safe source to the
working one.
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220608105238.2973600-2-dmitry.baryshkov@linaro.org
