aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2023-09-20arm64: dts: qcom: msm8916/39: Fix venus memory sizeStephan Gerhold2-2/+2
Both MSM8916 and MSM8939 have unnecessarily large reservations for the venus firmware for some reason. According to the ELF headers and downstream [1] 5 MiB is enough. Let's set the minimum size as default. With the dynamic reserved memory allocations boards can easily override this if needed, although in practice there does not seem to be any device with a different venus firmware size. [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blame/LA.BR.1.2.9.1-02310-8x16.0/arch/arm/boot/dts/qcom/msm8939-common.dtsi#L69 Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-9-b7089ec3e3a1@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: msm8916/39: Move mpss_mem size to boardsStephan Gerhold3-2/+3
The modem firmware size is typically highly device-specific. The current size of the mpss_mem region in msm8916.dtsi (0x2b00000) only works for some APQ8016 devices without full-featured modem, such as the DragonBoard 410c. The full modem firmware is typically about twice as large (~45 MiB -> ~90 MiB) but also varies by a few MiB from device to device. Since these devices are quite memory-constrained nowadays it's important to minimize the unnecessary memory reservations. Make it clear that each board needs to specify the necessary mpss_mem size by replacing the DB410c-specific size in msm8916.dtsi with a simple comment. &mpss_mem is disabled by default so it's fine to leave some properties up to the boards if they want to enable it. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-8-b7089ec3e3a1@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: msm8916/39: Disable unneeded firmware reservationsStephan Gerhold22-0/+153
Now that we no longer have fixed addresses for the firmware memory regions, disable them by default and only enable them together with the actual user in the board DT. This frees up unnecessary reserved memory for boards that do not use some of the remoteprocs and allows moving selected device-specific properties (such as firmware size) to the board-specific DT part in the next step. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-7-b7089ec3e3a1@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: msm8939: Reserve firmware memory dynamicallyStephan Gerhold1-6/+22
Follow the example of MSM8916 and reserve the firmware memory regions dynamically to allow boards to define only the device-specific parts. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-6-b7089ec3e3a1@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: msm8916: Reserve MBA memory dynamicallyStephan Gerhold1-2/+4
At a first glance the MBA memory region on MSM8916 looks intentionally placed at the fixed address 0x8ea00000. This is what the ELF headers of the firmware specify as base address, and the typical Qualcomm-specific bits suggest the binary is not relocatable. However, on a closer look this is pointless: Unlike other firmware images the hardware expects to have the raw ELF image loaded to the MBA region, including the ELF header (without parsing it at all). This means that we actually just load the ELF header (not the code!) at 0x8ea00000. The real LOAD segments follow at arbitrary aligned addresses depending on the structure of the ELF binary. In practice it looks like we can use an arbitrary 1 MiB-aligned region for MBA. The downstream/vendor kernel just allocates this dynamically at an arbitrary (aligned) address. Drop the pointless fixed address and use the new dynamic reserved memory mechanism to allocate a region close to the others. This reduces gaps in the memory map and provides Linux with more contiguous memory. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-5-b7089ec3e3a1@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: msm8916: Reserve firmware memory dynamicallyStephan Gerhold3-13/+29
Most of the reserved firmware memory on MSM8916 can be relocated when respecting the required alignment. To avoid having to precompute the reserved memory regions in every board DT, describe the actual requirements (size, alignment, alloc-ranges) using the dynamic reserved memory allocation. This approach has several advantages: 1. We can define "templates" for the reserved memory regions in msm8916.dtsi and keep only device-specific details in the board DT. This is useful for the "mpss" region size for example, which varies from device to device. It is no longer necessary to redefine all firmware regions to shift their addresses. 2. When some of the functionality (e.g. WCNSS, Modem, Venus) is not enabled or needed for a device, the reserved memory can stay disabled, freeing up the unused reservation for Linux. 3. Devices with special requirements for one of the firmware regions are handled automatically. For example, msm8916-longcheer-l8150 has non-relocatable "wcnss" firmware that must be loaded exactly at address 0x8b600000. When this is defined as a static region, the other dynamic allocations automatically adjust to a different place with suitable alignment. All in all this approach significantly reduces the boilerplate necessary to define the different firmware regions, and makes it easier to enable functionality on the different devices. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-4-b7089ec3e3a1@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: msm8916-ufi: Drop gps_mem for nowStephan Gerhold1-5/+0
gps_mem is needed by the modem firmware for GPS to work. However, it is accessed via QMI memshare [1] which is not available upstream yet. Until it lands upstream reserving this does not provide any advantage. [1]: https://lore.kernel.org/linux-arm-msm/20210319172321.22248-1-nikitos.tr@gmail.com/ Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-3-b7089ec3e3a1@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: msm8916/39: Disable GPU by defaultStephan Gerhold6-2/+20
MSM8916/39 do not need signed GPU firmware so it is generally okay to have it enabled by default. However, currently the GPU does not work without also enabling MDSS and it's questionable if someone would really need it without a display in practice. For consistency let's follow newer SoCs and disable the GPU by default. Enable it for all existing devices that already have &mdss enabled. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-2-b7089ec3e3a1@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: msm8916: Disable venus by defaultStephan Gerhold15-1/+57
Venus needs firmware that is usually signed with a device-specific key. There are also devices that might not need it (especially during bring-up), so let's follow more recent SoCs and disable it by default. Enable it explicitly for all current devices except msm8916-mtp. That one has just UART enabled currently so it cannot really benefit from Venus. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-1-b7089ec3e3a1@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: sc7180: Add ADSPNikita Travkin1-0/+122
sc7180 has an ADSP remoteproc that exclusively controls the audio hardware on devices that use Qualcomm firmware. Add it along with the relevant audio services. Signed-off-by: Nikita Travkin <nikita@trvn.ru> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230907-sc7180-adsp-rproc-v3-4-6515c3fbe0a3@trvn.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: sc7180: Add tertiary mi2s pinctrlNikita Travkin1-0/+5
Some devices use tertiary mi2s to connect external audio codec. Add it near the other two i2s pinctrl definitions so the devices don't have to duplicate it. Signed-off-by: Nikita Travkin <nikita@trvn.ru> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230907-sc7180-adsp-rproc-v3-3-6515c3fbe0a3@trvn.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20Revert "arm64: dts: qcom: sm8450: Add PRNG"Neil Armstrong1-5/+0
This reverts commit 76a6dd7bfcbb ("arm64: dts: qcom: sm8450: Add PRNG"), since the RNG HW on the SM8450 SoC is in fact a True Random Number Generator, a more appropriate compatible should be instead as reported at [1]. [1] https://lore.kernel.org/all/20230818161720.3644424-1-quic_omprsing@quicinc.com/ Suggested-by: Om Prakash Singh <quic_omprsing@quicinc.com> Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230828-topic-sm8550-rng-v3-1-7a0678ca7988@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20arm64: dts: qcom: pm8916: Drop codec reg-names and mclkStephan Gerhold2-5/+0
Drop the redundant reg-names and mclk from the PM8916 analog codec that were removed from the DT schema. Having the mclk on the analog codec is incorrect because only the digital codec consumes it directly. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230718-pm8916-mclk-v1-6-4b4a58b4240a@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sdx75-idp: align RPMh regulator nodes with bindingsKrzysztof Kozlowski1-1/+1
Device node names should be generic and bindings expect certain pattern for RPMh regulator nodes: sdx75-idp.dtb: rsc@17a00000: 'pmx75-rpmh-regulators' does not match any of the regexes: '^regulators(-[0-9])?$', 'pinctrl-[0-9]+' Fixes: 8a2dc39d1043 ("arm64: dts: qcom: sdx75-idp: Add regulator nodes") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905163103.257412-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sm4250-billie2: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: sm4250-oneplus-billie2.dtb: phy@4807000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-13-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: msm8998-sagit: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: msm8998-xiaomi-sagit.dtb: phy@1da7000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-12-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: msm8998-oneplus: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: msm8998-oneplus-dumpling.dtb: phy@1da7000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-11-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: msm8998-mtp: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: msm8998-mtp.dtb: phy@1da7000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-10-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: msm8998-pro1: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: msm8998-fxtec-pro1.dtb: phy@1da7000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-9-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: msm8996-gemini: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: msm8996-xiaomi-gemini.dtb: phy@627000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-8-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: msm8996-oneplus: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: msm8996-oneplus3t.dtb: phy@627000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-7-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: apq8096-db820c: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: apq8096-db820c.dtb: phy@627000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-6-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sm6115p-j606f: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: sm6115p-lenovo-j606f.dtb: phy@4807000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-5-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sm6115-pro1x: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: sm6115-fxtec-pro1x.dtb: phy@4807000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-4-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sm6125-sprout: correct UFS pad supplyKrzysztof Kozlowski1-1/+1
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c981b5 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: sm6125-xiaomi-laurel-sprout.dtb: phy@4807000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-3-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sm6125-sprout: drop incorrect UFS phy max currentKrzysztof Kozlowski1-2/+0
Neither bindings nor UFS phy driver use properties like 'vdda-phy-max-microamp' and 'vdda-pll-max-microamp': sm6125-xiaomi-laurel-sprout.dtb: phy@4807000: 'vdda-phy-max-microamp', 'vdda-pll-max-microamp' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: ipq6018: Fix tcsr_mutex register sizeVignesh Viswanathan1-1/+1
IPQ6018's TCSR Mutex HW lock register has 32 locks of size 4KB each. Total size of the TCSR Mutex registers is 128KB. Fix size of the tcsr_mutex hwlock register to 0x20000. Changes in v2: - Drop change to remove qcom,ipq6018-tcsr-mutex compatible string - Added Fixes and stable tags Cc: stable@vger.kernel.org Fixes: 5bf635621245 ("arm64: dts: ipq6018: Add a few device nodes") Signed-off-by: Vignesh Viswanathan <quic_viswanat@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905095535.1263113-2-quic_viswanat@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: ipq9574: Fix hwlock index for SMEMVignesh Viswanathan1-1/+1
SMEM uses lock index 3 of the TCSR Mutex hwlock for allocations in SMEM region shared by the Host and FW. Fix the SMEM hwlock index to 3 for IPQ9574. Cc: stable@vger.kernel.org Fixes: 46384ac7a618 ("arm64: dts: qcom: ipq9574: Add SMEM support") Signed-off-by: Vignesh Viswanathan <quic_viswanat@quicinc.com> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230904172516.479866-5-quic_viswanat@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: ipq6018: Fix hwlock index for SMEMVignesh Viswanathan1-1/+1
SMEM uses lock index 3 of the TCSR Mutex hwlock for allocations in SMEM region shared by the Host and FW. Fix the SMEM hwlock index to 3 for IPQ6018. Cc: stable@vger.kernel.org Fixes: 5bf635621245 ("arm64: dts: ipq6018: Add a few device nodes") Signed-off-by: Vignesh Viswanathan <quic_viswanat@quicinc.com> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230904172516.479866-3-quic_viswanat@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: ipq5332: Fix hwlock index for SMEMVignesh Viswanathan1-1/+1
SMEM uses lock index 3 of the TCSR Mutex hwlock for allocations in SMEM region shared by the Host and FW. Fix the SMEM hwlock index to 3 for IPQ5332. Cc: stable@vger.kernel.org Fixes: d56dd7f935e1 ("arm64: dts: qcom: ipq5332: add SMEM support") Signed-off-by: Vignesh Viswanathan <quic_viswanat@quicinc.com> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230904172516.479866-2-quic_viswanat@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: ipq8074: Fix hwlock index for SMEMVignesh Viswanathan1-1/+1
SMEM uses lock index 3 of the TCSR Mutex hwlock for allocations in SMEM region shared by the Host and FW. Fix the SMEM hwlock index to 3 for IPQ8074. Cc: stable@vger.kernel.org Fixes: 42124b947e8e ("arm64: dts: qcom: ipq8074: add SMEM support") Signed-off-by: Vignesh Viswanathan <quic_viswanat@quicinc.com> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230904172516.479866-4-quic_viswanat@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: msm8916-samsung-j5-common: Add accelerometerMarkuss Broks3-0/+59
J5 and J5X have ST LIS2HH12 accelerometer. Add support for it. Signed-off-by: Markuss Broks <markuss.broks@gmail.com> Co-developed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Co-developed-by: Lin, Meng-Bo <linmengbo0689@protonmail.com> Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230904123123.2593-1-linmengbo0689@protonmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: split pmr735d into 2Neil Armstrong4-47/+63
The second PMR735D PMIC is not always presend on SM8550 based devices, split the pmr735d.dtsi file in two so boards files can only include the ones present on the platform. Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230831-topic-sm8550-upstream-pmr735d-split-v1-1-98e632636415@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: ipq5332: Enable USBVaradarajan Narayanan1-0/+23
Enable USB2 in host mode. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> Link: https://lore.kernel.org/r/d4c20505dd2103b5421eab7602aec4f83bd62dbe.1693468292.git.quic_varada@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: ipq5332: Add USB related nodesVaradarajan Narayanan1-0/+55
Add USB phy and controller nodes. Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> Link: https://lore.kernel.org/r/f25777bfe2c84e203b7615527607900b756c51bd.1693468292.git.quic_varada@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sm7225-fp4: Revert "arm64: dts: qcom: sm7225-fairphone-fp4: Add AW8695 haptics"Krzysztof Kozlowski1-27/+1
This reverts commit 413821b7777d062b57f8dc66ab088ed390cbc3ec because it was never reviewed, was buggy (report from kernel test robot: https://lore.kernel.org/all/202204090333.QZXMI2tu-lkp@intel.com/) and used undocumented, broken bindings. Half of the properties in this device are questioned, thus adding DTS node causes only errors and does not make the device usable without the bindings and driver part: sm7225-fairphone-fp4.dtb: haptics@5a: failed to match any schema with compatible: ['awinic,aw8695'] sm7225-fairphone-fp4.dtb: haptics@5a: awinic,tset: b'\x12' is not of type 'object', 'array', 'boolean', 'null' sm7225-fairphone-fp4.dtb: haptics@5a: awinic,r-spare: b'h' is not of type 'object', 'array', 'boolean', 'null' Since bindings were abandoned (4 months since review), revert the commit to avoid false sense of supporting something which is not supported. Cc: Luca Weiss <luca.weiss@fairphone.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20230827122842.63741-3-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sc8180x: drop incorrect cell-index from SPMIKrzysztof Kozlowski1-1/+0
The SPMI controller (PMIC Arbiter) does not use nor allow 'cell-index' property: sc8180x-primus.dtb: spmi@c440000: Unevaluated properties are not allowed ('cell-index' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230827122842.63741-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: msm8939-longcheer-l9100: Add initial device treeAndré Apitzsch2-0/+335
This dts adds support for BQ Aquaris M5 (Longcheer L9100) released in 2015. Add a device tree with initial support for: - GPIO keys - Hall sensor - SDHCI - WCNSS (BT/WIFI) - Accelerometer/Magnetometer - Vibrator - Touchscreen - Front flash Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20230827-bq_m5-v4-2-f8435fb8f955@apitzsch.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19dt-bindings: arm: qcom: Add BQ Aquaris M5André Apitzsch1-0/+1
Add a compatible for BQ Aquaris M5 (Longcheer L9100). Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20230827-bq_m5-v4-1-f8435fb8f955@apitzsch.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sdm845-mtp: enable PCIe supportDmitry Baryshkov1-0/+78
Enable two PCIe hosts support on Qualcomm SDM845 MTP board. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230826221915.846937-6-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sdm845-mtp: enable Vol-/reset buttonDmitry Baryshkov1-0/+5
Wire up the Vol- / reset button on Qualcomm SDM845 MTP board. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230826221915.846937-5-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sdm845-mtp: switch to mbn firmwareDmitry Baryshkov1-2/+2
We have switched most of devices to use mbn (squashed) firmware files instead of spit mdt+bNN. Even this DT uses modem.mbn and a630_zap.mbn. Let's switch adsp and cdsp firmware files to use .mbn format too. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230826221915.846937-4-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sdm845-mtp: specify wifi variantDmitry Baryshkov1-0/+1
Specify the variant for the WiFi BDF file, "Qualcomm_sdm845mtp" to ease distinguishing from other (possible) devices using the same board id. For the reference: ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0x3f soc_id 0x40030001 ath10k_snoc 18800000.wifi: qmi fw_version 0x2009856b fw_build_timestamp 2018-07-19 12:28 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 ath10k_snoc 18800000.wifi: failed to fetch board data for bus=snoc,qmi-board-id=3f,qmi-chip-id=30214,variant=Qualcomm_sdm845mtp from ath10k/WCN3990/hw1.0/board-2.bin ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000 ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0 ath10k_snoc 18800000.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790 ath10k_snoc 18800000.wifi: htt-ver 3.53 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1 ath10k_snoc 18800000.wifi: invalid MAC address; choosing random Cc: Kalle Valo <kvalo@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230826221915.846937-3-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sdm845-mtp: fix WiFi configurationDmitry Baryshkov1-0/+2
Enable the host-cap-8bit quirk on this device. It is required for the WiFi to function properly. Fixes: 022bccb840b7 ("arm64: dts: sdm845: Add WCN3990 WLAN module device node") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230826221915.846937-2-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sm8350-hdk: add pmr735a regulatorsDmitry Baryshkov1-0/+75
The SM8350 HDK uses pmr735a to supply some of the voltages (e.g. to WiFi/BT chip). Declare corresponding regulators together with voltage boundaries. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230825214550.1650938-3-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sm8350-hdk: add missing PMICsDmitry Baryshkov1-0/+5
Include configuration for several PMICs presend on the board. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230825214550.1650938-2-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sm8350: fix pinctrl for UART18Dmitry Baryshkov1-1/+1
On sm8350 QUP18 uses GPIO 68/69, not 58/59. Fix correponding UART18 pinconf configuraion. Fixes: 98374e6925b8 ("arm64: dts: qcom: sm8350: Set up WRAP2 QUPs") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230825214550.1650938-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sdm845-tama: Add camera GPIO regulatorsKonrad Dybcio1-0/+57
Like on many other platforms, Tama devices utilize lots of GPIO- enabled regulators for the camera sensors. Define them in the DT. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230824-topic-tama_gpio-v1-3-014e9d198dce@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sdm845-tama: Add GPIO line names for PMIC GPIOsKonrad Dybcio4-0/+85
Sony ever so graciously provides GPIO line names in their downstream kernel (though sometimes they are not 100% accurate and you can judge that by simply looking at them and with what drivers they are used). Add these to the Akari, Apollo & Akatsuki DTS-es to better document the hardware. pm8005 and pm8998 config is common for all three boards. Apollo has VIB_LDO_EN (replacing NC) on PMI8998_GPIO_5 Akari and Akatsuki have WLC_EN_N (replacing NC) on PMI8998_GPIO_8 Akari additionally has RSVD(WLC_EN_N) (replacing) on PMI8998_GPIO_11 which sounds a bit like a forgot-to-update-documentation, but maybe it differs between SKUs.. Time will tell, when we get to enabling the wireless charger. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230824-topic-tama_gpio-v1-2-014e9d198dce@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-19arm64: dts: qcom: sdm845-tama: Add GPIO line names for TLMMKonrad Dybcio3-0/+457
Sony ever so graciously provides GPIO line names in their downstream kernel (though sometimes they are not 100% accurate and you can judge that by simply looking at them and with what drivers they are used). Add these to the Akari, Apollo & Akatsuki DTS-es to better document the hardware. Apollo can be considered the 'base configuration'. Akari brings WLC_INT_N on GPIO_31 over that. Akatsuki & Akari diff: < "NC", > "SAMD_RSTEN_N", < "NC", > "MASTER_RST_N", < "NC", > "DISP_ERR_FG", < "NC", > "SAMD_BOOTL_PIN", < "NC", < "NC", < "NC", /* GPIO_60 */ > "SDM_SWD_CLK", > "SDM_SWD_DAT", > "SAMD_RST", /* GPIO_60 */ < "NC", > "MODE_SEL2", < "NC", > "NFC_ESE_PWR_REQ", < "NC", > "TS_VDDIO_EN", Which makes sense, as Akari and Akatsuki have a wireless charger and Akatsuki also additionally has a super-high-end-complex-for-the-time Samsung OLED display, as opposed to LCDs on the other Tama devices. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230824-topic-tama_gpio-v1-1-014e9d198dce@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.