Enable &wcnss_mem for msm8939-longcheer-l9100. This is needed now to
have WCNSS working. It was missed when &wcnss_mem was disabled by
default because the patch with the msm8939-longcheer-l9100 device tree
was not applied yet.
Fixes: 0ece6438a8c0 ("arm64: dts: qcom: msm8916/39: Disable unneeded firmware reservations") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: André Apitzsch <git@apitzsch.eu> Tested-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20230921-msm8916-rmem-fixups-v1-2-34d2b6e721cf@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Thu, 21 Sep 2023 18:56:04 +0000 (20:56 +0200)]
arm64: dts: qcom: msm8916-samsung-gt5: Enable GPU
Enable the GPU for the msm8916-samsung-gt58 and gt510 tablets now that
they have display panels enabled in the device tree. This was missed
when the GPU was disabled by default because the change was not applied
yet.
arm64: dts: qcom: ipq5332: include the GPLL0 as clock provider for mailbox
While the kernel is booting up, APSS clock / CPU clock will be running
at 800MHz with GPLL0 as source. Once the cpufreq driver is available,
APSS PLL will be configured to the rate based on the opp table and the
source also will be changed to APSS_PLL_EARLY. So allow the mailbox to
consume the GPLL0, with this inclusion, CPU Freq correctly reports that
CPU is running at 800MHz rather than 24MHz.
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-11-c8ceb1a37680@quicinc.com
[bjorn: Updated commit message, as requested by Kathiravan] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: ipq9574: include the GPLL0 as clock provider for mailbox
While the kernel is booting up, APSS clock / CPU clock will be running
at 800MHz with GPLL0 as source. Once the cpufreq driver is available,
APSS PLL will be configured to the rate based on the opp table and the
source also will be changed to APSS_PLL_EARLY. So allow the mailbox to
consume the GPLL0, with this inclusion, CPU Freq correctly reports that
CPU is running at 800MHz rather than 24MHz.
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-10-c8ceb1a37680@quicinc.com
[bjorn: Updated commit message, as requested by Kathiravan] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: ipq6018: include the GPLL0 as clock provider for mailbox
While the kernel is booting up, APSS clock / CPU clock will be running
at 800MHz with GPLL0 as source. Once the cpufreq driver is available,
APSS PLL will be configured to the rate based on the opp table and the
source also will be changed to APSS_PLL_EARLY. So allow the mailbox to
consume the GPLL0, with this inclusion, CPU Freq correctly reports that
CPU is running at 800MHz rather than 24MHz.
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-9-c8ceb1a37680@quicinc.com
[bjorn: Updated commit message, as requested by Kathiravan] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: ipq8074: include the GPLL0 as clock provider for mailbox
While the kernel is booting up, APSS clock / CPU clock will be running
at 800MHz with GPLL0 as source. Once the cpufreq driver is available,
APSS PLL will be configured to the rate based on the opp table and the
source also will be changed to APSS_PLL_EARLY. So allow the mailbox to
consume the GPLL0, with this inclusion, CPU Freq correctly reports that
CPU is running at 800MHz rather than 24MHz.
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-8-c8ceb1a37680@quicinc.com
[bjorn: Updated commit message, as requested by Kathiravan] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
IPQ53xx have different OPPs available for the CPU based on
SoC variant. This can be determined through use of an eFuse
register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
Caleb Connolly [Tue, 10 Oct 2023 10:46:58 +0000 (11:46 +0100)]
arm64: dts: qcom: qrb4210-rb2: don't force usb peripheral mode
The rb2 only has a single USB controller, it can be switched between a
type-c port and an internal USB hub via a DIP switch. Until dynamic
role switching is available it's preferable to put the USB controller
in host mode so that the type-A ports and ethernet are available.
Add the missing regulator supplies to the ADV7533 HDMI bridge to fix
the following dtbs_check warnings. They are all also supplied by
pm8916_l6 so there is no functional difference.
apq8016-sbc.dtb: bridge@39: 'dvdd-supply' is a required property
apq8016-sbc.dtb: bridge@39: 'pvdd-supply' is a required property
apq8016-sbc.dtb: bridge@39: 'a2vdd-supply' is a required property
from schema display/bridge/adi,adv7533.yaml
ARM: dts: qcom: sdx65-mtp: Specify PM7250B SID to use
Now that the pm7250b.dtsi can be configured to be on a different SID, we
also need to specify it for this dts file. Set it to the SID 2/3 like it
was before commit 8e2d56f64572 ("arm64: dts: qcom: pm7250b: make SID
configurable").
arm64: dts: qcom: apq8016-sbc: Add overlay for usb host mode
Due to the presence of the fastboot micro cable in the CI farm,
it causes the hardware to remain in gadget mode instead of host mode.
So it doesn't find the network, which results in failure to mount root
fs via NFS.
Add an overlay dtso file that sets the dr_mode to host, allowing the
USB controllers to work in host mode. With commit 15d16d6dadf6
("kbuild: Add generic rule to apply fdtoverlay"), overlay target can
be used to simplify the build of DTB overlays. It uses fdtoverlay to
merge base device tree with the overlay dtso. apq8016-sbc-usb-host.dtb
file can be used by drm-ci, mesa-ci.
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Suggested-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: David Heidelberg <david.heidelberg@collabora.com> Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Helen Koike <helen.koike@collabora.com> Link: https://lore.kernel.org/r/20230911161518.650726-1-vignesh.raman@collabora.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: qcm6490: Add device-tree for Fairphone 5
Add device tree for the Fairphone 5 smartphone which is based on
the QCM6490 SoC.
Supported features are, as of now:
* Bluetooth
* Debug UART
* Display via simplefb
* Flash/torch LED
* Flip cover sensor
* Power & volume buttons
* RTC
* SD card
* USB
* Various plumbing like regulators, i2c, spi, etc
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230919-fp5-initial-v2-7-14bb7cedadf5@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Like other Qualcomm PMICs the PM7250B can be used on different addresses
on the SPMI bus. Use similar defines like the PMK8350 to make this
possible but skip the ifndef based on maintainer feedback.
arm64: dts: qcom: sc7280: Mark some nodes as 'reserved'
With the standard Qualcomm TrustZone setup, components such as lpasscc,
pdc_reset and watchdog shouldn't be touched by Linux. Mark them with
the status 'reserved' and reenable them in the chrome-common dtsi.
Adam Skladowski [Sat, 12 Aug 2023 11:24:49 +0000 (13:24 +0200)]
arm64: dts: qcom: msm8976: Split lpass region
MSM8976 downstream dts define reloc region which is used by pil-tz
to load both wcnss and lpass, on mainline however we might not be
able to do it and we need separate regions(also validating dts might get
problematic if we had to put memory-region(rproc node) per device).
Luckily it seems size and entry points in firmware headers appears
to be static across multiple devices including Sony Loire platform
and Xiaomi Redmi Note 3 Pro this should let us fit in first ~17MB
Split lpass region(reloc on downstream) into two separate regions.
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.
Stephan Gerhold [Mon, 11 Sep 2023 17:41:50 +0000 (19:41 +0200)]
arm64: dts: qcom: msm8916/39: Move mpss_mem size to boards
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.
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.
Stephan Gerhold [Mon, 11 Sep 2023 17:41:47 +0000 (19:41 +0200)]
arm64: dts: qcom: msm8916: Reserve MBA memory dynamically
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.
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.
Stephan Gerhold [Mon, 11 Sep 2023 17:41:45 +0000 (19:41 +0200)]
arm64: dts: qcom: msm8916-ufi: Drop gps_mem for now
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.
Stephan Gerhold [Mon, 11 Sep 2023 17:41:44 +0000 (19:41 +0200)]
arm64: dts: qcom: msm8916/39: Disable GPU by default
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.
Stephan Gerhold [Mon, 11 Sep 2023 17:41:43 +0000 (19:41 +0200)]
arm64: dts: qcom: msm8916: Disable venus by default
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.
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.
Neil Armstrong [Mon, 28 Aug 2023 08:04:36 +0000 (10:04 +0200)]
Revert "arm64: dts: qcom: sm8450: Add PRNG"
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].
Stephan Gerhold [Tue, 18 Jul 2023 11:40:18 +0000 (13:40 +0200)]
arm64: dts: qcom: pm8916: Drop codec reg-names and mclk
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.
arm64: dts: qcom: sm4250-billie2: correct UFS pad supply
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]+'
arm64: dts: qcom: msm8998-sagit: correct UFS pad supply
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]+'
arm64: dts: qcom: msm8998-oneplus: correct UFS pad supply
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]+'
arm64: dts: qcom: msm8998-mtp: correct UFS pad supply
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]+'
arm64: dts: qcom: msm8998-pro1: correct UFS pad supply
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]+'
arm64: dts: qcom: msm8996-gemini: correct UFS pad supply
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]+'
arm64: dts: qcom: msm8996-oneplus: correct UFS pad supply
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]+'
arm64: dts: qcom: apq8096-db820c: correct UFS pad supply
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]+'
arm64: dts: qcom: sm6115p-j606f: correct UFS pad supply
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]+'
arm64: dts: qcom: sm6115-pro1x: correct UFS pad supply
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]+'
arm64: dts: qcom: sm6125-sprout: correct UFS pad supply
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]+'
Neil Armstrong [Thu, 31 Aug 2023 15:25:49 +0000 (17:25 +0200)]
arm64: dts: qcom: split pmr735d into 2
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.
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.
Dmitry Baryshkov [Sat, 26 Aug 2023 22:19:13 +0000 (01:19 +0300)]
arm64: dts: qcom: sdm845-mtp: switch to mbn firmware
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.
Konrad Dybcio [Thu, 24 Aug 2023 09:58:53 +0000 (11:58 +0200)]
arm64: dts: qcom: sdm845-tama: Add GPIO line names for PMIC GPIOs
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.
Konrad Dybcio [Thu, 24 Aug 2023 09:58:52 +0000 (11:58 +0200)]
arm64: dts: qcom: sdm845-tama: Add GPIO line names for TLMM
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.
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.
David Wronek [Thu, 24 Aug 2023 09:15:07 +0000 (11:15 +0200)]
arm64: dts: qcom: Add support for the Xiaomi SM7125 platform
There are 6 Xiaomi smartphones with the SM7125 SoC:
- POCO M2 Pro (gram)
- Redmi Note 9S (curtana)
- Redmi Note 9 Pro (Global, joyeuse)
- Redmi Note 9 Pro (India, curtana)
- Redmi Note 9 Pro Max (excalibur)
- Redmi Note 10 Lite (curtana)
These devices share a common board design (a.k.a miatoll) with only a
few differences. Add support for the common board, as well as support
for the global Redmi Note 9 Pro.
David Wronek [Thu, 24 Aug 2023 09:15:06 +0000 (11:15 +0200)]
arm64: dts: qcom: Add SM7125 device tree
The Snapdragon 720G (sm7125) is software-wise very similar to the
Snapdragon 7c with minor differences in clock speeds and as added here,
it uses the Kryo 465 instead of Kryo 468.
Sheng-Liang Pan [Wed, 23 Aug 2023 07:13:06 +0000 (15:13 +0800)]
arm64: dts: qcom: sc7180: Add sku_id and board id for lazor/limozeen
SKU ID 10: Lazor LTE+Wifi, no-esim (Strapped 0 X 0)
SKU ID 15: Limozeen LTE+Wifi, TS, no esim (Strapped 1 X 0)
SKU ID 18: Limozeen LTE+Wifi, no TS, no esim (Strapped X 0 0)
Even though the "no esim" boards are strapped differently than
ones that have an esim, the esim isn't represented in the
device tree so the same device tree can be used for LTE w/ esim
and LTE w/out esim.
add BRD_ID(0, Z, 0) = 10 for new board with ALC5682i-VS
projects / thirdparty / kernel / linux.git / log
