aboutsummaryrefslogtreecommitdiff
path: root/drivers/interconnect
AgeCommit message (Collapse)AuthorFilesLines
2024-01-10interconnect: qcom: sm8550: Enable sync_stateKonrad Dybcio1-0/+1
To ensure the interconnect votes are actually meaningful and in order to prevent holding all buses at FMAX, introduce the sync state callback. Fixes: e6f0d6a30f73 ("interconnect: qcom: Add SM8550 interconnect provider driver") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2024-01-10interconnect: qcom: sc8180x: Mark CO0 BCM keepaliveKonrad Dybcio1-0/+1
The CO0 BCM needs to be up at all times, otherwise some hardware (like the UFS controller) loses its connection to the rest of the SoC, resulting in a hang of the platform, accompanied by a spectacular logspam. Mark it as keepalive to prevent such cases. Fixes: 9c8c6bac1ae8 ("interconnect: qcom: Add SC8180x providers") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-12-15Merge branch 'icc-sm6115' into icc-nextGeorgi Djakov3-0/+1434
Add DT bindings and a driver for managing NoC providers on SM6115. * icc-sm6115 dt-bindings: interconnect: Add Qualcomm SM6115 NoC interconnect: qcom: Add SM6115 interconnect provider driver dt-bindings: interconnect: qcom,msm8998-bwmon: Add SM6115 bwmon instance interconnect: qcom: sm6115: Fix up includes Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-12-15interconnect: qcom: sm6115: Fix up includesKonrad Dybcio1-5/+1
Remove some unnecessary includes and get rid of the abusive of_platform in favor of the correct headers. Reported-by: Rob Herring <[email protected]> Reported-by: Georgi Djakov <[email protected]> Fixes: 2eab57b131bd ("interconnect: qcom: Add SM6115 interconnect provider driver") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-12-06interconnect: qcom: Add SM6115 interconnect provider driverKonrad Dybcio3-0/+1438
Add a driver for managing NoC providers on SM6115. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-12-06interconnect: qcom: icc-rpm: Fix peak rate calculationBjorn Andersson1-1/+1
Per the commit message of commit 'dd014803f260 ("interconnect: qcom: icc-rpm: Add AB/IB calculations coefficients")', the peak rate should be 100/ib_percent. But, in what looks like a typical typo, the numerator value is discarded in the calculation. Update the implementation to match the described intention. Fixes: dd014803f260 ("interconnect: qcom: icc-rpm: Add AB/IB calculations coefficients") Cc: [email protected] Signed-off-by: Bjorn Andersson <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-30interconnect: qcom: sm8250: Enable sync_stateKonrad Dybcio1-0/+1
Add the generic icc sync_state callback to ensure interconnect votes are taken into account, instead of being pegged at maximum values. Fixes: b95b668eaaa2 ("interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-24Merge branch 'icc-x1e80100' into icc-nextGeorgi Djakov4-0/+2531
* icc-x1e80100 dt-bindings: interconnect: document the RPMh Network-On-Chip Interconnect in Qualcomm SM8650 SoC interconnect: qcom: introduce RPMh Network-On-Chip Interconnect on SM8650 SoC dt-bindings: interconnect: qcom-bwmon: document SM8650 BWMONs This series adds interconnect support for the Qualcomm X1E80100 platform, aka Snapdragon X Elite. Our v1 post of the patchsets adding support for Snapdragon X Elite SoC had the part number sc8380xp which is now updated to the new part number x1e80100 based on the new branding scheme and refers to the exact same SoC. Release Link: https://www.qualcomm.com/news/releases/2023/10/qualcomm-unleashes-snapdragon-x-elite--the-ai-super-charged-plat Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-24interconnect: qcom: Add X1E80100 interconnect provider driverRajendra Nayak4-0/+2531
Add driver for the Qualcomm interconnect buses found in X1E80100 based platforms. The topology consists of several NoCs that are controlled by a remote processor that collects the aggregated bandwidth for each master-slave pairs. Co-developed-by: Abel Vesa <[email protected]> Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Rajendra Nayak <[email protected]> Co-developed-by: Sibi Sankar <[email protected]> Signed-off-by: Sibi Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-24Merge branch 'icc-platform-remove' into icc-nextGeorgi Djakov16-58/+20
* icc-platform-remove interconnect: qcom: Make qnoc_remove return void interconnect: imx8mm: Convert to platform remove callback returning void interconnect: imx8mn: Convert to platform remove callback returning void interconnect: imx8mp: Convert to platform remove callback returning void interconnect: imx8mq: Convert to platform remove callback returning void interconnect: qcom/msm8974: Convert to platform remove callback returning void interconnect: qcom/osm-l3: Convert to platform remove callback returning void interconnect: qcom/smd-rpm: Convert to platform remove callback returning void interconnect: exynos: Convert to platform remove callback returning void This series converts all platform drivers below drivers/interconnect to use .remove_new(). Compared to the traditional .remove() callback .remove_new() returns no value. This is a good thing because the driver core doesn't (and cannot) cope for errors during remove. The only effect of a non-zero return value in .remove() is that the driver core emits a warning. The device is removed anyhow and an early return from .remove() usually yields resource leaks and/or use-after-free bugs. See commit 5c5a7680e67b ("platform: Provide a remove callback that returns no value") for an extended explanation and the eventual goal. All drivers converted here already returned zero unconditionally in .remove(), so they are converted here trivially. The imx drivers could be slightly simplified, because the remove callback only called a single function with the same prototype as .remove_new(). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-24interconnect: qcom: introduce RPMh Network-On-Chip Interconnect on SM8650 SoCNeil Armstrong4-0/+1828
Add RPMh Network-On-Chip Interconnect support for the SM8650 platform. Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20231123-topic-sm8650-upstream-interconnect-v2-2-7e050874f59b@linaro.org Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: exynos: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: qcom/smd-rpm: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: qcom/osm-l3: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: qcom/msm8974: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: imx8mq: Convert to platform remove callback returning voidUwe Kleine-König1-8/+1
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: imx8mp: Convert to platform remove callback returning voidUwe Kleine-König1-8/+1
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: imx8mn: Convert to platform remove callback returning voidUwe Kleine-König1-8/+1
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: imx8mm: Convert to platform remove callback returning voidUwe Kleine-König1-8/+1
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: qcom: Make qnoc_remove return voidUwe Kleine-König8-10/+8
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Several interconnect/qcom drivers use qnoc_remove() as remove callback. Make this function return void (instead of unconditionally zero) and adapt the drivers using this function accordingly. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-11-22interconnect: Treat xlate() returning NULL node as an errorMike Tipton1-0/+3
Currently, if provider->xlate() or provider->xlate_extended() "successfully" return a NULL node, then of_icc_get_from_provider() won't consider that an error and will successfully return the NULL node. This bypasses error handling in of_icc_get_by_index() and leads to NULL dereferences in path_find(). This could be avoided by ensuring provider callbacks always return an error for NULL nodes, but it's better to explicitly protect against this in the common framework. Fixes: 87e3031b6fbd ("interconnect: Allow endpoints translation via DT") Signed-off-by: Mike Tipton <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-19Merge branch 'icc-platform-remove' into icc-nextGeorgi Djakov19-21/+19
Convert platform drivers to use the .remove_new callback. * icc-platform-remove interconnect: qcom: Convert to platform remove callback returning void Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-18interconnect: qcom: Convert to platform remove callback returning voidUwe Kleine-König19-21/+19
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Several drivers use qcom_icc_rpmh_remove() as remove callback which returns zero unconditionally. Make it return void and use .remove_new in the drivers. There is no change in behaviour. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10Merge branch 'icc-misc' into icc-nextGeorgi Djakov4-8/+22
* icc-misc interconnect: imx: Replace custom implementation of COUNT_ARGS() interconnect: msm8974: Replace custom implementation of COUNT_ARGS() interconnect: qcom: osm-l3: Replace custom implementation of COUNT_ARGS() interconnect: fix error handling in qnoc_probe() interconnect: imx: Replace inclusion of kernel.h in the header dt-bindings: interconnect: qcom,rpmh: do not require reg on SDX65 MC virt Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: imx: Replace inclusion of kernel.h in the headerAndy Shevchenko1-1/+5
The kernel.h is not used here directly, replace it with proper set of headers. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: fix error handling in qnoc_probe()Yang Yingliang1-4/+10
Add missing clk_disable_unprepare() and clk_bulk_disable_unprepare() in the error path in qnoc_probe(). And when qcom_icc_qos_set() fails, it needs remove nodes and disable clks. Fixes: 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface clocks") Signed-off-by: Yang Yingliang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: osm-l3: Replace custom implementation of COUNT_ARGS()Andy Shevchenko1-1/+2
Replace custom and non-portable implementation of COUNT_ARGS(). Fixes: 5bc9900addaf ("interconnect: qcom: Add OSM L3 interconnect provider support") Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: msm8974: Replace custom implementation of COUNT_ARGS()Andy Shevchenko1-1/+3
Replace custom and non-portable implementation of COUNT_ARGS(). Fixes: 4e60a9568dc6 ("interconnect: qcom: add msm8974 driver") Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: imx: Replace custom implementation of COUNT_ARGS()Andy Shevchenko1-1/+2
Replace custom and non-portable implementation of COUNT_ARGS(). Fixes: f0d8048525d7 ("interconnect: Add imx core driver") Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10Merge branch 'icc-sdx75' into icc-nextGeorgi Djakov4-0/+1215
Add interconnect driver support for SDX75 platform. * icc-sdx75 dt-bindings: interconnect: Add compatibles for SDX75 interconnect: qcom: Add SDX75 interconnect provider driver Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>anter a commit message to explain why this merge is necessary,
2023-10-10Merge branch 'icc-acv-enable-mask' into icc-nextGeorgi Djakov11-0/+11
In the downstream kernel, ACV enable_mask has not been mentioned explicitly, rather being handled by a sneaky if-condition [1], [2]. Add it to all RPMh platforms to actually enable that BCM. [1] https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.10.2.1.c25/drivers/soc/qcom/msm_bus/msm_bus_arb_rpmh.c#L556-567 [2] https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.10.2.1.c25/drivers/soc/qcom/msm_bus/msm_bus_arb_rpmh.c#L475-495 * icc-acv-enable-mask interconnect: qcom: qdu1000: Set ACV enable_mask interconnect: qcom: sc7180: Set ACV enable_mask interconnect: qcom: sc7280: Set ACV enable_mask interconnect: qcom: sc8180x: Set ACV enable_mask interconnect: qcom: sc8280xp: Set ACV enable_mask interconnect: qcom: sdm670: Set ACV enable_mask interconnect: qcom: sdm845: Set ACV enable_mask interconnect: qcom: sm6350: Set ACV enable_mask interconnect: qcom: sm8150: Set ACV enable_mask interconnect: qcom: sm8250: Set ACV enable_mask interconnect: qcom: sm8350: Set ACV enable_mask Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: Add SDX75 interconnect provider driverRohit Agarwal4-0/+1215
Add driver for the Qualcomm interconnect buses found in SDX75. Signed-off-by: Rohit Agarwal <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sm8350: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: d26a56674497 ("interconnect: qcom: Add SM8350 interconnect provider driver") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sm8250: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 6df5b349491e ("interconnect: qcom: Add SM8250 interconnect provider driver") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sm8150: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: a09b817c8bad ("interconnect: qcom: Add SM8150 interconnect provider driver") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sm6350: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 6a6eff73a954 ("interconnect: qcom: Add SM6350 driver support") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sdm845: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: b5d2f741077a ("interconnect: qcom: Add sdm845 interconnect provider driver") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sdm670: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 7e438e18874e ("interconnect: qcom: add sdm670 interconnects") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sc8280xp: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: f29dabda7917 ("interconnect: qcom: Add SC8280XP interconnect provider") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sc8180x: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 9c8c6bac1ae8 ("interconnect: qcom: Add SC8180x providers") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sc7280: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 46bdcac533cc ("interconnect: qcom: Add SC7280 interconnect provider driver") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: sc7180: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 2d1f95ab9feb ("interconnect: qcom: Add SC7180 interconnect provider driver") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10interconnect: qcom: qdu1000: Set ACV enable_maskKonrad Dybcio1-0/+1
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 1f51339f7dd0 ("interconnect: qcom: Add QDU1000/QRU1000 interconnect driver") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: msm8996: Set AB/IB coefficientsKonrad Dybcio1-2/+6
Some buses and nodes need additional manual adjustments atop the usual calculations. Fill in the missing coefficients. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: sdm660: Set AB/IB coefficientsKonrad Dybcio1-0/+4
Some buses and nodes need additional manual adjustments atop the usual calculations. Fill in the missing coefficients. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: qcm2290: Update EBI channel configurationKonrad Dybcio1-1/+2
QCM2290 can support two memory configurations: single-channel, 32-bit wide LPDDR3 @ up to 933MHz (bus clock) or dual-channel, 16-bit wide LPDDR4X @ up to 1804 MHz. The interconnect driver in its current form seems to gravitate towards the first one, however there are no LPDDR3- equipped boards upstream and we still don't have a great way to discern the DDR generations on the kernel side. To make DDR scaling possible on the only currently-supported 2290 board, stick with the LPDDR4X config by default. The side effect on any potential LPDDR3 board would be that the requested bus clock rate is too high (but still capped to the firmware-configured FMAX). Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: qcm2290: Set AB coefficientsKonrad Dybcio1-0/+3
Some buses need additional manual adjustments atop the usual calculations. Fill in the missing coefficients. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: qcm2290: Hook up MAS_APPS_PROC's bus clockKonrad Dybcio3-0/+10
This single node has its own clock which seems to be responsible for transactions between CPUSS (CPU + some stuff) and the GNOC. See [1] for reference. Define it and hook it up. [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/02f8c342b23c20a5cf967df649814be37a08227c%5E%21/#F0 Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: icc-rpm: Check for node-specific rate coefficientsKonrad Dybcio2-4/+14
Some nodes may have different coefficients than the general values for bus they're attached to. Check for that and use them if present. See [1], [2] for reference. [1] https://github.com/sonyxperiadev/kernel/commit/7456d9779af9ad6bb9c7ee6f33d5c5a8d3648e24 [2] https://github.com/artem/android_kernel_sony_msm8996/commit/bf7a8985dcaf0eab5bc2562d2d6775e7e29c0f30 Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: icc-rpm: Let nodes drive their own bus clockKonrad Dybcio2-0/+31
If this hardware couldn't get messier, some nodes are supposed to drive their own bus clock.. Presumably to connect to some intermediate interface between the node itself and the bus it's (supposed to be) connected to. Expand the node struct with the necessary data and hook up the allocations & calculations. Note that the node-specific AB/IB coefficients contribute (by design) to both the node-level and the bus-level aggregation. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.