summaryrefslogtreecommitdiff
path: root/drivers/interconnect
AgeCommit message (Collapse)Author
2023-08-22interconnect: icc-clk: Annotate struct icc_clk_provider with __counted_byKees Cook
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct icc_clk_provider. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Georgi Djakov <djakov@kernel.org> Cc: linux-pm@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230817202914.never.661-kees@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-08-22Merge branch 'icc-qcm2290' into icc-nextGeorgi Djakov
This series contains fixes necessary for icc to behave correctly on QCM2290. * icc-qcm2290 interconnect: qcom: qcm2290: Enable keep_alive on all buses interconnect: qcom: qcm2290: Enable sync state Link: https://lore.kernel.org/r/20230720-topic-qcm2290_icc-v2-0-a2ceb9d3e713@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-08-22Merge tag 'v6.5-rc6' into icc-nextGeorgi Djakov
The fixes that got merged into v6.5-rc6 are needed here. Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-08-04interconnect: qcom: qcm2290: Enable sync stateKonrad Dybcio
Enable the generic .sync_state callback to ensure there are no outstanding votes that would waste power. Generally one would need a bunch of interface clocks to access the QoS registers when trying to go over all possible nodes during sync_state, but QCM2290 surprisingly does not seem to require any such handling. Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230720-topic-qcm2290_icc-v2-2-a2ceb9d3e713@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-08-04interconnect: qcom: qcm2290: Enable keep_alive on all busesKonrad Dybcio
QCM2290 expects all buses to be up at all times when the CPU is active. Enable keep_alive on all of them to achieve that. Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230720-topic-qcm2290_icc-v2-1-a2ceb9d3e713@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-07-18Merge branch 'icc-sm8250-qup' into icc-nextGeorgi Djakov
SM8250 (like SM8150 but unlike all other QUP-equipped SoCs) doesn't provide a qup-core path. Adjust the bindings and drivers as necessary, and then describe the icc paths in the device tree. This makes it possible for interconnect sync_state succeed so long as you don't use UFS. * icc-sm8250-qup dt-bindings: interconnect: qcom,rpmh: Add SM8250 QUP virt dt-bindings: interconnect: qcom,sm8250: Add QUP virt interconnect: qcom: sm8250: Fix QUP0 nodes Link: https://lore.kernel.org/r/20230703-topic-8250_qup_icc-v2-0-9ba0a9460be2@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-07-18interconnect: qcom: sm8250: Fix QUP0 nodesKonrad Dybcio
The QUP0 BCM relates to some internal property of the QUPs, and should be configured independently of the path to the QUP. In line with other platforms expose QUP_CORE endpoints in order allow this configuration. Fixes: 6df5b349491e ("interconnect: qcom: Add SM8250 interconnect provider driver") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230703-topic-8250_qup_icc-v2-3-9ba0a9460be2@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-07-17interconnect: qcom: icc-rpm: Explicitly return 0 at the end of the functionGeorgi Djakov
Fix the following smatch error: drivers/interconnect/qcom/icc-rpm.c:243 qcom_icc_rpm_set() error: uninitialized symbol 'ret'. Fixes: 32846c4a8f2a ("interconnect: qcom: icc-rpm: Set bandwidth on both contexts") Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230717125534.2455745-1-djakov@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-07-16interconnect: Explicitly include correct DT includesRob Herring
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230714174638.4058268-1-robh@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-07-15interconnect: qcom: icc-rpm: Fix bandwidth calculationsKonrad Dybcio
Up until now, we've been aggregating the bandwidth values and only dividing them by the bus width of the source node. This was completely wrong, as different nodes on a given path may (and usually do) have varying bus widths. That in turn, resulted in the calculated clock rates being completely bogus - usually they ended up being much higher, as NoC_A<->NoC_B links are very wide. Since we're not using the aggregate bandwidth value for anything other than clock rate calculations, remodel qcom_icc_bus_aggregate() to calculate the per-context clock rate for a given provider, taking into account the bus width of every individual node. Fixes: 30c8fa3ec61a ("interconnect: qcom: Add MSM8916 interconnect provider driver") Reported-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-22-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: icc-rpm: Set correct bandwidth through RPM bw reqKonrad Dybcio
Currently, we're setting the aggregated-on-provider bandwidth on each node, individually. That is of course incorrect and results in far too high votes. Use the correct values to ensure we're not wasting power. Fixes: 30c8fa3ec61a ("interconnect: qcom: Add MSM8916 interconnect provider driver") Reported-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-21-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: icc-rpm: Set bandwidth on both contextsKonrad Dybcio
Up until now, for some reason we've only been setting bandwidth values on the active-only context. That pretty much meant that RPM could lift all votes when entering sleep mode. Or never sleep at all. That in turn could potentially break things like USB wakeup, as the connection between APSS and SNoC/PNoC would simply be dead. Set the values appropriately. Fixes: 30c8fa3ec61a ("interconnect: qcom: Add MSM8916 interconnect provider driver") Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-20-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: icc-rpm: Fix bucket numberKonrad Dybcio
SMD RPM only provides two buckets, one each for the active-only and active-sleep RPM contexts. Use the correct constant to allocate and operate on them. This will make the qcom,icc.h header no longer work with this driver, mostly because.. it was never meant to! The commit that introduced bucket support to SMD RPM was trying to shove a square into a round hole and it did not work out very well. That said, there are no active users of SMD RPM ICC + qcom,icc.h, so that doesn't hurt. Fixes: dcbce7b0a79c ("interconnect: qcom: icc-rpm: Support multiple buckets") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-19-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: icc-rpm: Control bus rpmcc from iccKonrad Dybcio
The sole purpose of bus clocks that were previously registered with rpmcc was to convey the aggregated bandwidth to RPM. There's no good reason to keep them outside the interconnect framework, as it only adds to the plentiful complexity. Add the required code to handle these clocks from within SMD RPM ICC. RPM-owned bus clocks are no longer considered a thing, but sadly we have to allow for the existence of HLOS-owned bus clocks, as some (mostly older) SoCs (ab)use these for bus scaling (e.g. MSM8998 and &mmcc AHB_CLK_SRC). This in turn is trivially solved with a single *clk, which is filled and used iff qp.bus_clk_desc is absent and we have a "bus" clock-names entry in the DT node. This change should(tm) be fully compatible with all sorts of old Device Trees as far as the interconnect functionality goes (modulo abusing bus clock handles or wrongly using the qcom,icc.h binding, but that's a mistake in and of itself). Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-17-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: qcm2290: Hook up RPM bus clk definitionsKonrad Dybcio
Assign the necessary definitions to migrate to the new bus clock handling mechanism. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-16-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: msm8916: Hook up RPM bus clk definitionsKonrad Dybcio
Assign the necessary definitions to migrate to the new bus clock handling mechanism. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-15-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: msm8939: Hook up RPM bus clk definitionsKonrad Dybcio
Assign the necessary definitions to migrate to the new bus clock handling mechanism. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-14-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: qcs404: Hook up RPM bus clk definitionsKonrad Dybcio
Assign the necessary definitions to migrate to the new bus clock handling mechanism. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-13-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: msm8996: Hook up RPM bus clk definitionsKonrad Dybcio
Assign the necessary definitions to migrate to the new bus clock handling mechanism. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-12-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: sdm660: Hook up RPM bus clk definitionsKonrad Dybcio
Assign the necessary definitions to migrate to the new bus clock handling mechanism. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-11-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: Define RPM bus clocksKonrad Dybcio
Add the definitions for RPM bus clocks that will be used by many different platforms. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-10-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: smd-rpm: Add rpmcc handling skeleton codeKonrad Dybcio
Introduce qcom_icc_rpm_set_bus_rate() in preparation for handling RPM clock resources within the interconnect framework. This lets us greatly simplify all of the code handling, as setting the rate comes down to: u32 rate_khz = max(clk.sleep_rate, clk.active_rate, clk_a.active_rate) write_to_rpm(clock.description, rate_khz); Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-9-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: Fold smd-rpm.h into icc-rpm.hKonrad Dybcio
smd-rpm.h is not very useful as-is and both files are always included anyway.. Combine them. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-8-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: Add missing headers in icc-rpm.hKonrad Dybcio
Currently the header does not provide all the required dependencies. Fix it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-7-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-15interconnect: qcom: icc-rpm: Introduce keep_aliveKonrad Dybcio
The downstream kernel employs the concept of "keeping the bus alive" by voting for the minimum (XO/19.2MHz) rate at all times on certain (well, most) buses. This is a very important thing to have, as if we either have a lackluster/wrong DT that doesn't specify a (high enough) vote on a certain bus, we may lose access to the entire bus altogether. This is very apparent when we only start introducing interconnect support on a given platform and haven't yet introduced voting on all peripherals. The same can happen if we only have a single driver casting a vote on a certain bus and that driver exits/crashes/suspends. The keepalive vote is limited to the ACTIVE bucket, as keeping a permanent vote on the SLEEP one could prevent the platform from properly entering low power mode states. Introduce the very same concept, with a slight twist: the vendor kernel checks whether the rate is zero before setting the minimum vote, but that's rather silly, as in doing so we're at the mercy of CCF. Instead, explicitly clamp the rates to always be >= 19.2 MHz for providers with keep_alive=true. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Georgi Djakov <djakov@kernel.org> Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-6-09c78c175546@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-11interconnect: qcom: sa8775p: add enable_mask for bcm nodesNeil Armstrong
Set the proper enable_mask the ACV node requiring such value to be used instead of a bandwidth when voting. The masks was copied from the downstream implementation at [1]. [1] https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/blob/kernel.lnx.5.15.r32-rel/drivers/interconnect/qcom/lemans.c Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v2-4-709474b151cc@linaro.org Fixes: 3655a63f9661 ("interconnect: qcom: add a driver for sa8775p") Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-07-11interconnect: qcom: sm8550: add enable_mask for bcm nodesNeil Armstrong
Set the proper enable_mask to nodes requiring such value to be used instead of a bandwidth when voting. The masks were copied from the downstream implementation at [1]. [1] https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/blob/kernel.lnx.5.15.r1-rel/drivers/interconnect/qcom/kalama.c Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v2-3-709474b151cc@linaro.org Fixes: e6f0d6a30f73 ("interconnect: qcom: Add SM8550 interconnect provider driver") Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-07-11interconnect: qcom: sm8450: add enable_mask for bcm nodesNeil Armstrong
Set the proper enable_mask to nodes requiring such value to be used instead of a bandwidth when voting. The masks were copied from the downstream implementation at [1]. [1] https://git.codelinaro.org/clo/la/kernel/msm-5.10/-/blob/KERNEL.PLATFORM.1.0.r2-05600-WAIPIOLE.0/drivers/interconnect/qcom/waipio.c Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v2-2-709474b151cc@linaro.org Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver") Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-07-11interconnect: qcom: Add support for mask-based BCMsMike Tipton
Some BCMs aren't directly associated with the data path (i.e. ACV) and therefore don't communicate using BW. Instead, they are simply enabled/disabled with a simple bit mask. Add support for these. Origin commit retrieved from: https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/commit/2d1573e0206998151b342e6b52a4c0f7234d7e36 Signed-off-by: Mike Tipton <mdtipton@codeaurora.org> [narmstrong: removed copyright change from original commit] Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v2-1-709474b151cc@linaro.org Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver") Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-06-10Merge branch 'icc-qos' into icc-nextGeorgi Djakov
* icc-qos interconnect: qcom: rpm: Rename icc desc clocks to bus_blocks interconnect: qcom: rpm: Rename icc provider num_clocks to num_bus_clocks interconnect: qcom: rpm: Drop unused parameters interconnect: qcom: rpm: Set QoS registers only once interconnect: qcom: rpm: Handle interface clocks interconnect: qcom: icc-rpm: Enforce 2 or 0 bus clocks interconnect: qcom: rpm: Don't use clk_get_optional for bus clocks anymore interconnect: qcom: msm8996: Promote to core_initcall interconnect: qcom: rpm: allocate enough data in probe() Link: https://lore.kernel.org/r/20230228-topic-qos-v8-0-ee696a2c15a9@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-06-10Merge branch 'icc-cbf' into icc-nextGeorgi Djakov
On MSM8996 two CPU clusters are interconnected using the Core Bus Fabric (CBF). In order for the CPU clusters to function properly, it should be clocked following the core's frequencies to provide adequate bandwidth. Register CBF as a clock (required for CPU to boot) and add a tiny interconnect layer on top of it to let cpufreq/opp scale the CBF clock. * icc-cbf dt-bindings: interconnect/msm8996-cbf: add defines to be used by CBF interconnect: add clk-based icc provider support clk: qcom: cbf-msm8996: scale CBF clock according to the CPUfreq interconnect: icc-clk: fix modular build Link: https://lore.kernel.org/r/20230512001334.2983048-1-dmitry.baryshkov@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-06-10interconnect: icc-clk: fix modular buildDmitry Baryshkov
Fix building interconnect-clk as a module: - Add EXPORT_SYMBOL_GPL to the exported functions - Add MODULE_DESCRIPTION/_LICENSE/_AUTHOR Reported-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230519230122.3958816-1-dmitry.baryshkov@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-30interconnect: drop unused icc_get() interfaceJohan Hovold
The icc_get() interface can be used to lookup an interconnect path based on global node ids. There has never been any users of this interface and all lookups are currently done from the devicetree. Remove the unused icc_get() interface. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230523095248.25211-1-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-30interconnect: qcom: rpm: allocate enough data in probe()Dan Carpenter
This was not allocating enough bytes. There are two issue here. First, there was a typo where it was taking the size of the pointer instead of the size of the struct, "sizeof(qp->intf_clks)" vs "sizeof(*qp->intf_clks)". Second, it's an array of "cd_num" clocks so we need to allocate space for more than one element. Fixes: 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface clocks") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/e0fa275c-ae63-4342-9c9e-0ffaf6314da1@kili.mountain Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-21interconnect: qcom: msm8996: Promote to core_initcallKonrad Dybcio
The interconnect driver is (or soon will be) vital to many other devices, as it's not a given that the bootloader will set up enough bandwidth for us or that the values we come into are reasonable. Promote the driver to core_initcall to ensure the consumers (i.e. most "meaningful" parts of the SoC) can probe without deferrals. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v8-8-ee696a2c15a9@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-21interconnect: qcom: rpm: Don't use clk_get_optional for bus clocks anymoreKonrad Dybcio
Commit dd42ec8ea5b9 ("interconnect: qcom: rpm: Use _optional func for provider clocks") relaxed the requirements around probing bus clocks. This was a decent solution for making sure MSM8996 would still boot with old DTs, but now that there's a proper fix in place that both old and new DTs will be happy about, revert back to the safer variant of the function. Fixes: dd42ec8ea5b9 ("interconnect: qcom: rpm: Use _optional func for provider clocks") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v8-7-ee696a2c15a9@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-21interconnect: qcom: icc-rpm: Enforce 2 or 0 bus clocksKonrad Dybcio
For SMD RPM bus scaling to work, we need a pair of sleep-wake clocks. The variable number of them we previously supported was only a hack to keep the clocks required for QoS register access, but now that these are separated, we can leave bus_clks to the actual bus clocks. In cases where there is no actual bus scaling (such as A0NoC on MSM8996 and GNoC on SDM660 where the HLOS is only supposed to program the QoS registers and the bus is either static or controlled remotely), allow for no clock scaling with a boolean property. Remove all the code related to allowing an arbitrary number of bus_clks, replace the number by BUS_CLK_MAX (= 2) and guard the bus clock paths to ensure they are not taken on non-scaling buses. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v8-6-ee696a2c15a9@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-21interconnect: qcom: rpm: Handle interface clocksKonrad Dybcio
Some (but not all) providers (or their specific nodes) require specific clocks to be turned on before they can be accessed. Failure to ensure that results in a seemingly random system crash (which would usually happen at boot with the interconnect driver built-in), resulting in the platform not booting up properly. Limit the number of bus_clocks to 2 (which is the maximum that SMD RPM interconnect supports anyway) and handle non-scaling clocks separately. Update MSM8996 and SDM660 drivers to make sure they do not regress with this change. This unfortunately has to be done in one patch to prevent either compile errors or broken bisect. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230518195801.2556998-1-konrad.dybcio@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-18interconnect: add clk-based icc provider supportDmitry Baryshkov
For some devices it is useful to export clocks as interconnect providers, if the clock corresponds to bus bandwidth. For example, on MSM8996 the cluster interconnect clock should be scaled according to the cluster frequencies. Exporting it as an interconnect allows one to properly describe this as the cluster bandwidth requirements. Tested-by: Yassine Oudjana <y.oudjana@protonmail.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230512001334.2983048-3-dmitry.baryshkov@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-18interconnect: qcom: rpm: Set QoS registers only onceKonrad Dybcio
The QoS registers are (or according to Qualcomm folks, on most platforms) persistent until a full chip reboot. Move the QoS-setting functions to the probe function so that we don't needlessly do it over and over again. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v8-4-ee696a2c15a9@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-18interconnect: qcom: rpm: Drop unused parametersKonrad Dybcio
The QoS-setting functions do not care about the bandwidth values passed. Drop them. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v8-3-ee696a2c15a9@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-18interconnect: qcom: rpm: Rename icc provider num_clocks to num_bus_clocksKonrad Dybcio
In preparation for handling non-scaling clocks that we still have to enable, rename num_clocks to more descriptive num_bus_clocks. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v8-2-ee696a2c15a9@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-05-18interconnect: qcom: rpm: Rename icc desc clocks to bus_blocksKonrad Dybcio
Rename the "clocks" (and _names) fields of qcom_icc_desc to "bus_clocks" in preparation for introducing handling of clocks that need to be enabled but not voted on with aggregate frequency. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v8-1-ee696a2c15a9@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-04-27Merge tag 'modules-6.4-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux Pull module updates from Luis Chamberlain: "The summary of the changes for this pull requests is: - Song Liu's new struct module_memory replacement - Nick Alcock's MODULE_LICENSE() removal for non-modules - My cleanups and enhancements to reduce the areas where we vmalloc module memory for duplicates, and the respective debug code which proves the remaining vmalloc pressure comes from userspace. Most of the changes have been in linux-next for quite some time except the minor fixes I made to check if a module was already loaded prior to allocating the final module memory with vmalloc and the respective debug code it introduces to help clarify the issue. Although the functional change is small it is rather safe as it can only *help* reduce vmalloc space for duplicates and is confirmed to fix a bootup issue with over 400 CPUs with KASAN enabled. I don't expect stable kernels to pick up that fix as the cleanups would have also had to have been picked up. Folks on larger CPU systems with modules will want to just upgrade if vmalloc space has been an issue on bootup. Given the size of this request, here's some more elaborate details: The functional change change in this pull request is the very first patch from Song Liu which replaces the 'struct module_layout' with a new 'struct module_memory'. The old data structure tried to put together all types of supported module memory types in one data structure, the new one abstracts the differences in memory types in a module to allow each one to provide their own set of details. This paves the way in the future so we can deal with them in a cleaner way. If you look at changes they also provide a nice cleanup of how we handle these different memory areas in a module. This change has been in linux-next since before the merge window opened for v6.3 so to provide more than a full kernel cycle of testing. It's a good thing as quite a bit of fixes have been found for it. Jason Baron then made dynamic debug a first class citizen module user by using module notifier callbacks to allocate / remove module specific dynamic debug information. Nick Alcock has done quite a bit of work cross-tree to remove module license tags from things which cannot possibly be module at my request so to: a) help him with his longer term tooling goals which require a deterministic evaluation if a piece a symbol code could ever be part of a module or not. But quite recently it is has been made clear that tooling is not the only one that would benefit. Disambiguating symbols also helps efforts such as live patching, kprobes and BPF, but for other reasons and R&D on this area is active with no clear solution in sight. b) help us inch closer to the now generally accepted long term goal of automating all the MODULE_LICENSE() tags from SPDX license tags In so far as a) is concerned, although module license tags are a no-op for non-modules, tools which would want create a mapping of possible modules can only rely on the module license tag after the commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"). Nick has been working on this *for years* and AFAICT I was the only one to suggest two alternatives to this approach for tooling. The complexity in one of my suggested approaches lies in that we'd need a possible-obj-m and a could-be-module which would check if the object being built is part of any kconfig build which could ever lead to it being part of a module, and if so define a new define -DPOSSIBLE_MODULE [0]. A more obvious yet theoretical approach I've suggested would be to have a tristate in kconfig imply the same new -DPOSSIBLE_MODULE as well but that means getting kconfig symbol names mapping to modules always, and I don't think that's the case today. I am not aware of Nick or anyone exploring either of these options. Quite recently Josh Poimboeuf has pointed out that live patching, kprobes and BPF would benefit from resolving some part of the disambiguation as well but for other reasons. The function granularity KASLR (fgkaslr) patches were mentioned but Joe Lawrence has clarified this effort has been dropped with no clear solution in sight [1]. In the meantime removing module license tags from code which could never be modules is welcomed for both objectives mentioned above. Some developers have also welcomed these changes as it has helped clarify when a module was never possible and they forgot to clean this up, and so you'll see quite a bit of Nick's patches in other pull requests for this merge window. I just picked up the stragglers after rc3. LWN has good coverage on the motivation behind this work [2] and the typical cross-tree issues he ran into along the way. The only concrete blocker issue he ran into was that we should not remove the MODULE_LICENSE() tags from files which have no SPDX tags yet, even if they can never be modules. Nick ended up giving up on his efforts due to having to do this vetting and backlash he ran into from folks who really did *not understand* the core of the issue nor were providing any alternative / guidance. I've gone through his changes and dropped the patches which dropped the module license tags where an SPDX license tag was missing, it only consisted of 11 drivers. To see if a pull request deals with a file which lacks SPDX tags you can just use: ./scripts/spdxcheck.py -f \ $(git diff --name-only commid-id | xargs echo) You'll see a core module file in this pull request for the above, but that's not related to his changes. WE just need to add the SPDX license tag for the kernel/module/kmod.c file in the future but it demonstrates the effectiveness of the script. Most of Nick's changes were spread out through different trees, and I just picked up the slack after rc3 for the last kernel was out. Those changes have been in linux-next for over two weeks. The cleanups, debug code I added and final fix I added for modules were motivated by David Hildenbrand's report of boot failing on a systems with over 400 CPUs when KASAN was enabled due to running out of virtual memory space. Although the functional change only consists of 3 lines in the patch "module: avoid allocation if module is already present and ready", proving that this was the best we can do on the modules side took quite a bit of effort and new debug code. The initial cleanups I did on the modules side of things has been in linux-next since around rc3 of the last kernel, the actual final fix for and debug code however have only been in linux-next for about a week or so but I think it is worth getting that code in for this merge window as it does help fix / prove / evaluate the issues reported with larger number of CPUs. Userspace is not yet fixed as it is taking a bit of time for folks to understand the crux of the issue and find a proper resolution. Worst come to worst, I have a kludge-of-concept [3] of how to make kernel_read*() calls for modules unique / converge them, but I'm currently inclined to just see if userspace can fix this instead" Link: https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/ [0] Link: https://lkml.kernel.org/r/025f2151-ce7c-5630-9b90-98742c97ac65@redhat.com [1] Link: https://lwn.net/Articles/927569/ [2] Link: https://lkml.kernel.org/r/20230414052840.1994456-3-mcgrof@kernel.org [3] * tag 'modules-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux: (121 commits) module: add debugging auto-load duplicate module support module: stats: fix invalid_mod_bytes typo module: remove use of uninitialized variable len module: fix building stats for 32-bit targets module: stats: include uapi/linux/module.h module: avoid allocation if module is already present and ready module: add debug stats to help identify memory pressure module: extract patient module check into helper modules/kmod: replace implementation with a semaphore Change DEFINE_SEMAPHORE() to take a number argument module: fix kmemleak annotations for non init ELF sections module: Ignore L0 and rename is_arm_mapping_symbol() module: Move is_arm_mapping_symbol() to module_symbol.h module: Sync code of is_arm_mapping_symbol() scripts/gdb: use mem instead of core_layout to get the module address interconnect: remove module-related code interconnect: remove MODULE_LICENSE in non-modules zswap: remove MODULE_LICENSE in non-modules zpool: remove MODULE_LICENSE in non-modules x86/mm/dump_pagetables: remove MODULE_LICENSE in non-modules ...
2023-04-13interconnect: remove module-related codeNick Alcock
Now the interconnect core can no longer be a module, drop all remaining module-related code as well. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Requested-by: Georgi Djakov <djakov@kernel.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Georgi Djakov <djakov@kernel.org> Cc: linux-pm@vger.kernel.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-04-13interconnect: remove MODULE_LICENSE in non-modulesNick Alcock
Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Suggested-by: Luis Chamberlain <mcgrof@kernel.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Georgi Djakov <djakov@kernel.org> Cc: linux-pm@vger.kernel.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-04-05interconnect: qcom: Sort kerneldoc entriesKonrad Dybcio
Sort the kerneldoc entries the same way the struct members are sorted. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v7-3-815606092fff@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-04-05interconnect: qcom: rpm: Add support for specifying channel numKonrad Dybcio
Some nodes, like EBI0 (DDR) or L3/LLCC, may be connected over more than one channel. This should be taken into account in bandwidth calcualtion, as we're supposed to feed msmbus with the per-channel bandwidth. Add support for specifying that and use it during bandwidth aggregation. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v7-2-815606092fff@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-04-05interconnect: qcom: rpm: make QoS INVALID defaultKonrad Dybcio
Currently NOC_QOS_MODE_FIXED is defined as 0x0 which makes it the default option (partial struct initialization). The default option however should be NOC_QOS_MODE_INVALID. That results in bogus QoS configurations being sent for port 0 (which is used for the DRAM endpoint on BIMC, for example) coming from all nodes with .qos.ap_owned = true and uninitialized .qos.qos_mode. It's also an issue for newer SoCs where all nodes are treated as if they were ap_owned, but not all of them have QoS configuration. The NOC_QOS_MODEs are defined as preprocessor constants and are not used anywhere outside qcom_icc_set_noc_qos(), which is easily worked around. Separate the desc->type values from the values sent to msmbus in the aforementioned function. Make the former an enum for better mainainability. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230228-topic-qos-v7-1-815606092fff@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-04-05interconnect: qcom: rpm: drop bogus pm domain attachJohan Hovold
Any power domain would already have been attached by the platform bus code so drop the bogus power domain attach which always succeeds from probe. This effectively reverts commit 7de109c0abe9 ("interconnect: icc-rpm: Add support for bus power domain"). Fixes: 7de109c0abe9 ("interconnect: icc-rpm: Add support for bus power domain") Cc: Yassine Oudjana <y.oudjana@protonmail.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # MSM8996 Sony Kagura Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230313084953.24088-3-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org>