summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-11soc: mediatek: mtk-svs: Convert sw_id and type to enumerationsAngeloGioacchino Del Regno1-86/+106
The sw_id and type specifiers currently are defined as BIT(x) for unknown reasons: nothing in this code makes any AND/OR check for those, and that would never happen anyway because both sw_id and type are exclusive, as in: - There will never be a bank that is for both CPU and GPU, or for CPU and CCI together; - A bank cannot be contemporarily of one-line and two-line type, as much as it cannot contemporarily have both HIGH and LOW roles Change those definitions to enumerations and also add some kerneldoc to better describe what they are for and what they indicate. While at it, also change the names adding _SWID or _TYPE to increase human readability. Link: https://lore.kernel.org/r/20231121125044.78642-4-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-12-11soc: mediatek: mtk-svs: Subtract offset from regs_v2 to avoid conflictAngeloGioacchino Del Regno1-54/+54
The svs_regs_v2 array of registers was offsetted by 0xc00 because the SVS node was supposed to have the same iostart as the thermal sensors. That's wrong for two reasons: 1. Two different devices cannot have the same iostart in devicetree, as those would technically be the same device otherwise; and 2. SVS and Thermal Sensor (be it LVTS or AUXADC thermal) are not the same IP, and those two do obviously have a different iospace. Even though there already are users of this register array, the only one that declares a devicetree node for SVS is MT8183 - but it never actually worked because the "tzts1" thermal zone missed thermal trips, hence this driver's probe always failed on that SoC. Knowing this - it is safe to say that keeping compatibility with older device trees is pointless, hence simply subtract the 0xc00 offset from the register offset array. Link: https://lore.kernel.org/r/20231121125044.78642-3-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-12-11soc: mediatek: Add MT8188 VDOSYS reset bit mapHsiao Chien Sung2-1/+90
Add MT8188 reset bit map for VDOSYS0 and VDOSYS1. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-12-11soc: mediatek: Support reset bit mapping in mmsys driverHsiao Chien Sung2-0/+12
- Reset ID must starts from 0 and be consecutive, but the reset bits in our hardware design is not continuous, some bits are left unused, we need a map to solve the problem - Use old style 1-to-1 mapping if .rst_tb is not defined Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-12-11soc: mediatek: Support MT8188 VDOSYS1 Padding in mtk-mmsysHsiao Chien Sung2-0/+24
- Add Padding components - Add Mutex module definitions for Padding Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-12-11soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsysHsiao Chien Sung4-0/+203
- Add register definitions for MT8188 - Add VDOSYS1 routing table - Update MUTEX definitions accordingly - Set VSYNC length from 0x40 (default) to 1 since ETHDR is bypassed Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-12-11soc: mediatek: mmsys: Add support for MT8188 VPPSYSyu-chang.lee1-0/+12
Add MT8188 VPPSYS0 and VPPSYS1 driver data. Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-12-11soc: mediatek: svs: Add support for MT8186 SoCMark Tseng1-0/+282
MT8186 svs has a number of banks which used as optimization of opp voltage table for corresponding dvfs drivers. MT8186 svs big core uses 2-line high bank and low bank to optimize the voltage of opp table for higher and lower frequency respectively. Signed-off-by: Mark Tseng <chun-jen.tseng@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-12-11soc: mediatek: svs: Add support for MT8195 SoCMark Tseng1-0/+136
MT8195 svs gpu uses 2-line high bank and low bank to optimize the voltage of opp table for higher and lower frequency respectively. Signed-off-by: Mark Tseng <chun-jen.tseng@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-12-11dt-bindings: samsung: exynos-sysreg: combine exynosautov920 with other enumKrzysztof Kozlowski1-5/+2
No need to create a new enum every time we bring-up new SoC. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231210134834.43943-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-10dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to ↵Peter Griffin1-0/+3
GS101 GS101 has three different SYSREG controllers, add dedicated compatibles for them to the documentation. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231209233106.147416-4-peter.griffin@linaro.org [krzysztof: move Google entries to existing enum] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-10dt-bindings: clock: Add Google gs101 clock management unit bindingsPeter Griffin2-0/+498
Provide dt-schema documentation for Google gs101 SoC clock controller. Currently this adds support for cmu_top, cmu_misc and cmu_apm. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231209233106.147416-3-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-10dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatiblePeter Griffin1-0/+2
Add gs101-pmu compatible to the bindings documentation. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231209233106.147416-2-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: firmware: qcom,scm: Allow interconnect for everyoneKonrad Dybcio1-17/+0
Every Qualcomm SoC physically has a "CRYPTO0<->DDR" interconnect lane. Allow this property to be present, no matter the SoC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20231125-topic-rb1_feat-v3-4-4cbb567743bb@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07dt-bindings: firmware: qcom,scm: document SCM on X1E80100 SoCsSibi Sankar1-0/+2
Document scm compatible for X1E80100 SoCs. Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231124100608.29964-5-quic_sibis@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07MAINTAINERS: add auto-update driver to mpfs entryConor Dooley1-0/+1
Rob's scripts were broken by the lack of a maintainer for this file, while trying to fix an integration issue in linux-next. Add it to the existing entry for PolarFire SoC drivers so that when the next bug is found the contributor knows where to send it. Reported-by: Rob Herring <robh@kernel.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-12-07soc: qcom: socinfo: Add PM8937 Power ICDang Huynh1-1/+1
The PM8917 and PM8937 uses the same SUBTYPE ID. The PM8937 is found in boards with MSM8917, MSM8937 and MSM8940 and APQ variants. Signed-off-by: Dang Huynh <danct12@riseup.net> Link: https://lore.kernel.org/r/20231121-pm8937-v2-4-b0171ab62075@riseup.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07firmware: microchip: Replace of_device.h with explicit includeRob Herring1-1/+1
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it was 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. Soon the implicit includes are going to be removed. of_device.h isn't needed, but platform_device.h is. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-12-07soc: qcom: llcc: Add configuration data for X1E80100Rajendra Nayak1-0/+39
Add LLCC configuration data for X1E80100 SoC. Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20231117095315.2087-3-quic_sibis@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07dt-bindings: cache: qcom,llcc: Add X1E80100 compatibleRajendra Nayak1-0/+2
Add the compatible for X1E80100 platforms. Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231117095315.2087-2-quic_sibis@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07soc: qcom: pmic_glink_altmode: fix port sanity checkJohan Hovold1-2/+2
The PMIC GLINK altmode driver currently supports at most two ports. Fix the incomplete port sanity check on notifications to avoid accessing and corrupting memory beyond the port array if we ever get a notification for an unsupported port. Fixes: 080b4e24852b ("soc: qcom: pmic_glink: Introduce altmode support") Cc: stable@vger.kernel.org # 6.3 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20231109093100.19971-1-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07soc: qcom: llcc: Add configuration data for SM8650Neil Armstrong1-0/+43
Add Last Level Cache Controller support for the SM8650 platform. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231030-topic-sm8650-upstream-llcc-v2-2-f281cec608e2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07dt-bindings: cache: qcom,llcc: Document the SM8650 Last Level Cache ControllerNeil Armstrong1-0/+1
Document the Last Level Cache Controller on the SM8650 platform. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231030-topic-sm8650-upstream-llcc-v2-1-f281cec608e2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07soc: qcom: socinfo: Add SM8650 SoC ID table entryNeil Armstrong1-0/+1
Add SoC Info support for the SM8650 platform. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20231030-topic-sm8650-upstream-socinfo-v2-2-4751e7391dc9@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07dt-bindings: arm: qcom,ids: Add SoC ID for SM8650Neil Armstrong1-0/+1
Add the ID for the Qualcomm SM8650 SoC. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20231030-topic-sm8650-upstream-socinfo-v2-1-4751e7391dc9@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07soc: qcom: pmic_glink: enable UCSI by defaultDmitry Baryshkov1-10/+9
Now as the issue with the UCSI_GET_PDOS is worked around, enable UCSI support for all PMIC_GLINK platforms except Qualcomm SC8180X. The mentioned SoC has slightly different UCSI implementation, which I would like be tested properly before enabling it. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231025115620.905538-3-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07usb: typec: ucsi: fix UCSI on buggy Qualcomm devicesDmitry Baryshkov3-0/+19
On sevral Qualcomm platforms (SC8180X, SM8350, SC8280XP) a call to UCSI_GET_PDOS for non-PD partners will cause a firmware crash with no easy way to recover from it. Since we have no easy way to determine whether the partner really has PD support, shortcut UCSI_GET_PDOS on such platforms. This allows us to enable UCSI support on such devices. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231025115620.905538-2-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07dt-bindings: firmware: qcom,scm: document SM8650 SCM Firmware InterfaceNeil Armstrong1-0/+3
Document the SCM Firmware Interface on the SM8650 Platform. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231025-topic-sm8650-upstream-bindings-scm-v1-1-f687b5aa3c9e@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07dt-bindings: soc: qcom: pmic-glink: document SM8650 compatibleNeil Armstrong1-8/+14
Document the PMIC GLINK firmware interface on the SM8650 Platform by using the SM8550 bindings as fallback. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231025-topic-sm8650-upstream-bindings-pmic-glink-v1-1-0c2829a62565@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07dt-bindings: soc: qcom,aoss-qmp: document the SM8560 Always-On Subsystem ↵Neil Armstrong1-0/+1
side channel Document the Always-On Subsystem side channel on the SM8650 Platform. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231025-topic-sm8650-upstream-bindings-aoss-qmp-v1-1-8940621d704c@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07soc: qcom: stats: Express AOSS QMP module dependencyBjorn Andersson1-0/+1
In the case that the Qualcomm Sleep stats driver is builtin and the AOSS QMP driver is built as a module, neither the implementation nor the stub functions are available during linking, resulting in the following errors: qcom_stats.c:(.text+0x33c): undefined reference to `qmp_send' qcom_stats.c:(.text+0x8a0): undefined reference to `qmp_get' Resolve this by expressing the dependency between the two modules. Fixes: e84e61bdb97c ("soc: qcom: stats: Add DDR sleep stats") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/linux-arm-msm/202312061258.nAVYPFq2-lkp@intel.com/ Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20231205-qcom_stats-aoss_qmp-dependency-v1-1-8dabe1b5c32a@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07soc: qcom: stats: fix 64-bit divisionArnd Bergmann1-1/+1
Unguarded 64-bit division is not allowed on 32-bit kernels because this is very slow. The result of trying anyway is a link failure: arm-linux-gnueabi-ld: drivers/soc/qcom/qcom_stats.o: in function `qcom_ddr_stats_show': qcom_stats.c:(.text+0x334): undefined reference to `__aeabi_uldivmod' As this function is only used for debugging and not performance critical, rewrite it to use div_u64() instead. ARCH_TIMER_FREQ is a multiple of MSEC_PER_SEC anyway, so there is no loss in precisison. Fixes: e84e61bdb97c ("soc: qcom: stats: Add DDR sleep stats") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231206123717.524009-1-arnd@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-12-07dt-bindings: watchdog: samsung: add specific compatible for Tesla FSDKrzysztof Kozlowski1-8/+13
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-6-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-5-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: serial: samsung: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: pwm: samsung: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: i2c: exynos5: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07soc: hisilicon: kunpeng_hccs: Support the platform with PCC type3 and ↵Huisong Li2-25/+125
interrupt ack Support the platform with PCC type3 and interrupt ack. And a version specific structure is introduced to handle the difference between the device in the code. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2023-12-07doc: kunpeng_hccs: Fix incorrect email domain nameHuisong Li1-3/+3
The email domain name in Contact is wrong. So this patch has to modify it. Signed-off-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2023-12-07soc: hisilicon: kunpeng_hccs: Remove an unused blank lineHuisong Li1-1/+0
Remove an unused blank line. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2023-12-07soc: hisilicon: kunpeng_hccs: Add failure log for no _CRS methodHuisong Li1-1/+3
Driver gets the PCC channel id by using the PCC GAS in _CRS. But, currently, if the firmware has no _CRS method on platform, there is not any failure log. So this patch adds the log for this. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2023-12-07soc: hisilicon: kunpeng_hccs: Fix some incorrect format stringsHuisong Li1-6/+6
Fix some incorrect format strings. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2023-12-06Merge tag 'bus-platform-remove-void' of ↵Arnd Bergmann13-59/+28
https://git.pengutronix.de/git/ukl/linux into soc/drivers This series converts all drivers below drivers/bus to struct platform_driver::remove_new(). See commit 5c5a7680e67b ("platform: Provide a remove callback that returns no value") for an extended explanation and the eventual goal. After the initial simplification in commit 864acca58000 ("bus: fsl-mc: Drop if block with always false condition") all conversations are trivial because the remove callbacks all return zero unconditionally. * tag 'bus-platform-remove-void' of https://git.pengutronix.de/git/ukl/linux: bus: ts-nbus: Convert to platform remove callback returning void bus: ti-sysc: Convert to platform remove callback returning void bus: ti-pwmss: Convert to platform remove callback returning void bus: tegra-gmi: Convert to platform remove callback returning void bus: tegra-aconnect: Convert to platform remove callback returning void bus: sunxi-rsb: Convert to platform remove callback returning void bus: sun50i-de2: Convert to platform remove callback returning void bus: simple-pm-bus: Convert to platform remove callback returning void bus: qcom-ssc-block-bus: Convert to platform remove callback returning void bus: omap_l3_smx: Convert to platform remove callback returning void bus: omap-ocp2scp: Convert to platform remove callback returning void bus: hisi_lpc: Convert to platform remove callback returning void bus: fsl-mc: Convert to platform remove callback returning void bus: fsl-mc: Drop if block with always false condition Link: https://lore.kernel.org/r/20231128174927.m46dgp4juig2omci@pengutronix.de Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-12-06Merge tag 'asahi-soc-mailbox-6.8' of https://github.com/AsahiLinux/linux ↵Arnd Bergmann12-606/+533
into soc/drivers Apple SoC mailbox updates for 6.8 This moves the mailbox driver out of the mailbox subsystem and into SoC, next to its only consumer (RTKit). It has been cooking in linux-next for a long while, so it's time to pull it in. * tag 'asahi-soc-mailbox-6.8' of https://github.com/AsahiLinux/linux: soc: apple: mailbox: Add explicit include of platform_device.h soc: apple: mailbox: Rename config symbol to APPLE_MAILBOX mailbox: apple: Delete driver soc: apple: rtkit: Port to the internal mailbox driver soc: apple: mailbox: Add ASC/M3 mailbox driver soc: apple: rtkit: Get rid of apple_rtkit_send_message_wait Link: https://lore.kernel.org/r/6e64472e-c55d-4499-9a61-da59cfd28021@marcan.st Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-12-06soc: ti: k3-socinfo: Revamp driver to accommodate different rev structsNeha Malcom Francis1-16/+55
k3-socinfo.c driver assumes silicon revisions for every platform are incremental and one-to-one, corresponding to JTAG_ID's variant field: 1.0, 2.0 etc. This assumption is wrong for SoCs such as J721E, where the variant field to revision mapping is 1.0, 1.1. Further, there are SoCs such as AM65x where the sub-variant version requires custom decoding of other registers. Address this by using conditional handling per JTAG ID that requires an exception with J721E as the first example. To facilitate this conversion, use macros to identify the JTAG_ID part number and map them to predefined string array. Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Co-developed-by: Thejasvi Konduru <t-konduru@ti.com> Signed-off-by: Thejasvi Konduru <t-konduru@ti.com> Link: https://lore.kernel.org/r/20231016101608.993921-4-n-francis@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2023-12-06firmware: microchip: add PolarFire SoC Auto Update supportConor Dooley5-0/+511
Add support for Auto Update reprogramming of the FPGA fabric on PolarFire SoC, using the fw_upload mechanism a la the intel-m10-bmc-sec-update driver. This driver only writes the image to the spi flash & performs validation on it, as the entire FPGA becomes unusable during the actual reprogramming of a bitstream. To initiate the reprogramming itself, a device reset is required. The SBI SRST extension's "cold reboot" can trigger such a device reset, provided corresponding support has been enabled in the HSS (Hart Software Services), the provider of SBI runtime services on PolarFire SoC. While this is a driver responsible for the reprogramming of an FPGA, there is no dynamic discovery of devices involved, as runtime reconfiguration is not possible due to the device reset requirements. Therefore FPGA manager subsystem is not used by this driver and the FPGA subsystem maintainers were unwilling to accept it there. Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-12-06soc: microchip: mpfs: add auto-update subdev to system controllerConor Dooley1-2/+7
The PolarFire SoC's system controller offers the ability to re-program the FPGA from a user application via two, related, mechanisms. In-Application Programming (IAP) is not ideal for use in Linux, as it will immediately take down the system when requested. Auto Update is preferred, as it will only take affect at device power up*, allowing the OS (and potential applications in AMP) to be shut down gracefully. * Auto Update occurs at device initialisation, which can also be triggered by device reset - possible with the v2023.02 version of the Hart Software Services (HSS) and reference design. Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-12-06soc: microchip: mpfs: print service status in warning messageConor Dooley1-1/+3
Now that resp_status is set for failed services, print the status in the error path's warning. Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-12-06soc: microchip: mpfs: enable access to the system controller's flashConor Dooley3-0/+23
The system controller has a flash that contains images used to reprogram the FPGA using IAP (In-Application Programming). Introduce a function that allows a driver with a reference to the system controller to get one to a flash device attached to it. Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-12-06dt-bindings: soc: microchip: add a property for system controller flashConor Dooley1-0/+10
The system controller "shares" a SPI flash device with a QSPI controller in the MSS. This flash is used to store FPGA bitstreams & other metadata. IAP and Auto Upgrade both write images to this flash that the System Controller will use to re-program the FPGA. Add a phandle property signifying which flash device is connected to the system controller. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 22:43:39 +0300