Krishna Kurapati [Tue, 31 Dec 2024 08:11:03 +0000 (13:41 +0530)]
arm64: dts: qcom: sm8250: Disable USB U1/U2 entry
Disable U1 and U2 power-saving states to improve stability of USB.
These low-power link states, designed to reduce power consumption
during idle periods, can cause issues in latency-sensitive or high
throughput use cases. Over the years, some of the issues seen are
as follows:
1. In device mode of operation, when UVC is active, enabling U1/U2
is sometimes causing packets drops due to delay in entry/exit of
intermittent these low power states. These packet drops are often
reflected as missed isochronous transfers, as the controller wasn't
able to send packet in that microframe interval and hence glitches
are seen on the final transmitted video output.
2. On older targets like SM8150/SM8250/SM8350, there have been
throughput issues seen during tethering use cases.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Signed-off-by: Prashanth K <quic_prashk@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241231081115.3149850-6-quic_prashk@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Krishna Kurapati [Tue, 31 Dec 2024 08:11:02 +0000 (13:41 +0530)]
arm64: dts: qcom: sm6125: Disable USB U1/U2 entry
Disable U1 and U2 power-saving states to improve stability of USB.
These low-power link states, designed to reduce power consumption
during idle periods, can cause issues in latency-sensitive or high
throughput use cases. Over the years, some of the issues seen are
as follows:
1. In device mode of operation, when UVC is active, enabling U1/U2
is sometimes causing packets drops due to delay in entry/exit of
intermittent these low power states. These packet drops are often
reflected as missed isochronous transfers, as the controller wasn't
able to send packet in that microframe interval and hence glitches
are seen on the final transmitted video output.
2. On older targets like SM8150/SM8250/SM8350, there have been
throughput issues seen during tethering use cases.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Signed-off-by: Prashanth K <quic_prashk@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241231081115.3149850-5-quic_prashk@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Krishna Kurapati [Tue, 31 Dec 2024 08:11:01 +0000 (13:41 +0530)]
arm64: dts: qcom: sm8150: Disable USB U1/U2 entry
Disable U1 and U2 power-saving states to improve stability of USB.
These low-power link states, designed to reduce power consumption
during idle periods, can cause issues in latency-sensitive or high
throughput use cases. Over the years, some of the issues seen are
as follows:
1. In device mode of operation, when UVC is active, enabling U1/U2
is sometimes causing packets drops due to delay in entry/exit of
intermittent these low power states. These packet drops are often
reflected as missed isochronous transfers, as the controller wasn't
able to send packet in that microframe interval and hence glitches
are seen on the final transmitted video output.
2. On older targets like SM8150/SM8250/SM8350, there have been
throughput issues seen during tethering use cases.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Signed-off-by: Prashanth K <quic_prashk@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241231081115.3149850-4-quic_prashk@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Krishna Kurapati [Tue, 31 Dec 2024 08:11:00 +0000 (13:41 +0530)]
arm64: dts: qcom: sm8450: Disable USB U1/U2 entry
Disable U1 and U2 power-saving states to improve stability of USB.
These low-power link states, designed to reduce power consumption
during idle periods, can cause issues in latency-sensitive or high
throughput use cases. Over the years, some of the issues seen are
as follows:
1. In device mode of operation, when UVC is active, enabling U1/U2
is sometimes causing packets drops due to delay in entry/exit of
intermittent these low power states. These packet drops are often
reflected as missed isochronous transfers, as the controller wasn't
able to send packet in that microframe interval and hence glitches
are seen on the final transmitted video output.
2. On older targets like SM8150/SM8250/SM8350, there have been
throughput issues seen during tethering use cases.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Signed-off-by: Prashanth K <quic_prashk@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241231081115.3149850-3-quic_prashk@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Krishna Kurapati [Tue, 31 Dec 2024 08:10:59 +0000 (13:40 +0530)]
arm64: dts: qcom: sm8350: Disable USB U1/U2 entry
Disable U1 and U2 power-saving states to improve stability of USB.
These low-power link states, designed to reduce power consumption
during idle periods, can cause issues in latency-sensitive or high
throughput use cases. Over the years, some of the issues seen are
as follows:
1. In device mode of operation, when UVC is active, enabling U1/U2
is sometimes causing packets drops due to delay in entry/exit of
intermittent these low power states. These packet drops are often
reflected as missed isochronous transfers, as the controller wasn't
able to send packet in that microframe interval and hence glitches
are seen on the final transmitted video output.
2. On older targets like SM8150/SM8250/SM8350, there have been
throughput issues seen during tethering use cases.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Signed-off-by: Prashanth K <quic_prashk@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241231081115.3149850-2-quic_prashk@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Melody Olvera [Wed, 4 Dec 2024 23:18:04 +0000 (15:18 -0800)]
arm64: dts: qcom: Add base SM8750 dtsi
Add the base dtsi for the SM8750 SoC describing the CPUs, GCC and
RPMHCC clock controllers, geni UART, interrupt controller, TLMM,
reserved memory, interconnects, and SMMU.
Add bindings for the Qualcomm SM8750 Display Clock Controller (DISPCC).
Bindings are similar to existing SM8550 and SM8650 (same clock inputs),
but the clock hierarchy is quite different and these are not compatible
devices.
The binding header was copied from downstream sources, so I retained
original copyrights.
Abel Vesa [Fri, 27 Dec 2024 12:58:36 +0000 (14:58 +0200)]
arm64: dts: qcom: x1e80100: Fix interconnect tags for SDHC nodes
The CPU-to-SDHC interconnect path for the SDHC_2 needs to have the
active-only tags. The tags are missing entirely on for the SDHC_4
controller interconnect paths.
Alexey Klimov [Tue, 12 Nov 2024 02:53:06 +0000 (02:53 +0000)]
arm64: dts: qcom: qrb4210-rb2: add HDMI audio playback support
Add sound node and dsp-related piece to enable HDMI audio
playback support on Qualcomm QRB4210 RB2 board. That is the
only sound output supported for now.
The audio playback is verified using the following commands:
Add the Low Power Audio SubSystem Low Power Island (LPASS LPI) pin
controller device node required for audio subsystem on Qualcomm
QRB4210 RB2. QRB4210 is based on sm4250 which has a slightly different
lpass pin controller comparing to sm6115.
While at this, also add description of lpi_i2s2 pins (active state)
required for audio playback via HDMI.
Krzysztof Kozlowski [Mon, 4 Nov 2024 14:42:04 +0000 (15:42 +0100)]
arm64: dts: qcom: sm8650: Fix CDSP context banks unit addresses
There is a mismatch between 'reg' property and unit address for last
there CDSP compute context banks. Current values were taken as-is from
downstream source. Considering that 'reg' is used by Linux driver as
SID of context bank and that least significant bytes of IOMMU value
match the 'reg', assume the unit-address is wrong and needs fixing.
This also won't have any practical impact, except adhering to Devicetree
spec.
Fixes: dae8cdb0a9e1 ("arm64: dts: qcom: sm8650: Add three missing fastrpc-compute-cb nodes") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241104144204.114279-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:20 +0000 (12:17 +0200)]
arm64: dts: qcom: q[dr]u1000: move board clocks to qdu1000.dtsi file
The QDU1000 and QRU1000 devices define XO and clocks completely in the
board files, despite qdu1000.dtsi file referencing them directly. Follow
the example of other platforms and move clock definitions to the
qdu1000.dtsi file.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:19 +0000 (12:17 +0200)]
arm64: dts: qcom: sdm670: move board clocks to sdm670.dtsi file
The SDM670 devices define XO and clocks completely in the
board files, despite sdm670.dtsi file referencing them directly. Follow
the example of other platforms and move clock definitions to the
sdm670.dtsi file.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:17 +0000 (12:17 +0200)]
arm64: dts: qcom: x1e80100: correct sleep clock frequency
The X1E80100 platform uses PMK8550 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:16 +0000 (12:17 +0200)]
arm64: dts: qcom: sm8650: correct sleep clock frequency
The SM8650 platform uses PMK8550 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:15 +0000 (12:17 +0200)]
arm64: dts: qcom: sm8550: correct sleep clock frequency
The SM8550 platform uses PMK8550 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Fixes: 0b12da4e28d8 ("arm64: dts: qcom: add base AIM300 dtsi") Fixes: b5e25ded2721 ("arm64: dts: qcom: sm8550: add support for the SM8550-HDK board") Fixes: 71342fb91eae ("arm64: dts: qcom: Add base SM8550 MTP dts") Fixes: d228efe88469 ("arm64: dts: qcom: sm8550-qrd: add QRD8550") Fixes: ba2c082a401f ("arm64: dts: qcom: sm8550: Add support for Samsung Galaxy Z Fold5") Fixes: 39c596304e44 ("arm64: dts: qcom: Add SM8550 Xperia 1 V") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-16-e9b08fbeadd3@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:14 +0000 (12:17 +0200)]
arm64: dts: qcom: sm8450: correct sleep clock frequency
The SM8450 platform uses PMK8350 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:13 +0000 (12:17 +0200)]
arm64: dts: qcom: sm8350: correct sleep clock frequency
The SM8350 platform uses PMK8350 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:12 +0000 (12:17 +0200)]
arm64: dts: qcom: sm8250: correct sleep clock frequency
The SM8250 platform uses PM8150 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:11 +0000 (12:17 +0200)]
arm64: dts: qcom: sm6375: correct sleep clock frequency
The SM6375 platform uses PM6125 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:10 +0000 (12:17 +0200)]
arm64: dts: qcom: sm6125: correct sleep clock frequency
The SM6125 platform uses PM6125 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:09 +0000 (12:17 +0200)]
arm64: dts: qcom: sm4450: correct sleep clock frequency
The SM4450 platform uses PM4450 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:08 +0000 (12:17 +0200)]
arm64: dts: qcom: sdx75: correct sleep clock frequency
The SDX75 platform uses PMK8550 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:07 +0000 (12:17 +0200)]
arm64: dts: qcom: sc7280: correct sleep clock frequency
The SC7280 platform uses PMK8350 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:06 +0000 (12:17 +0200)]
arm64: dts: qcom: sar2130p: correct sleep clock frequency
The SAR2130P platform uses PM8150 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:05 +0000 (12:17 +0200)]
arm64: dts: qcom: qrb4210-rb2: correct sleep clock frequency
Qualcomm RB2 board uses PM6125 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:04 +0000 (12:17 +0200)]
arm64: dts: qcom: q[dr]u1000: correct sleep clock frequency
The Q[DR]U1000 platforms use PM8150 to provide sleep clock. According to
the documentation, that clock has 32.7645 kHz frequency. Correct the
sleep clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:03 +0000 (12:17 +0200)]
arm64: dts: qcom: qcs404: correct sleep clock frequency
The QCS40x platforms use PMS405 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:02 +0000 (12:17 +0200)]
arm64: dts: qcom: msm8994: correct sleep clock frequency
The MSM8994 platform uses PM8994/6 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:01 +0000 (12:17 +0200)]
arm64: dts: qcom: msm8939: correct sleep clock frequency
The MSM8939 platform uses PM8916 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
Dmitry Baryshkov [Tue, 24 Dec 2024 10:17:00 +0000 (12:17 +0200)]
arm64: dts: qcom: msm8916: correct sleep clock frequency
The MSM8916 platform uses PM8916 to provide sleep clock. According to the
documentation, that clock has 32.7645 kHz frequency. Correct the sleep
clock definition.
SM8650 lists two interconnects for the display subsystem, mdp0-mem
(between MDP and LLCC) and mdp1-mem (between LLCC and EBI, memory).
The second interconnect is a misuse. mdpN-mem paths should be used for
several outboud MDP interconnects rather than the path between LLCC and
memory. This kind of misuse can result in bandwidth underflows, possibly
degrading picture quality as the required memory bandwidth is divided
between all mdpN-mem paths (and LLCC-EBI should not be a part of such
division).
Drop the second path and use direct MDP-EBI path for mdp0-mem until we
support separate MDP-LLCC and LLCC-EBI paths.
SM8550 lists two interconnects for the display subsystem, mdp0-mem
(between MDP and LLCC) and mdp1-mem (between LLCC and EBI, memory).
The second interconnect is a misuse. mdpN-mem paths should be used for
several outboud MDP interconnects rather than the path between LLCC and
memory. This kind of misuse can result in bandwidth underflows, possibly
degrading picture quality as the required memory bandwidth is divided
between all mdpN-mem paths (and LLCC-EBI should not be a part of such
division).
Drop the second path and use direct MDP-EBI path for mdp0-mem until we
support separate MDP-LLCC and LLCC-EBI paths.
Krishna Kurapati [Wed, 18 Dec 2024 12:12:57 +0000 (20:12 +0800)]
arm64: dts: qcom: qcs615-ride: Enable secondary USB controller on QCS615 Ride
Enable secondary USB controller on QCS615 Ride platform. The secondary
USB controller is made "host", as it is a Type-A port.
Secondary USB controller of QCS615 Ride has Type-A port exposed for
connecting peripheral. The VBUS to the peripheral is provided by
TPS2549IRTERQ1 regulator connected to the port. The regulator has an
enable pin controlled by PM8150. Model it as fixed regulator and keep it
Always-On at boot, since the regulator is GPIO controlled regulator.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Co-developed-by: Song Xue <quic_songxue@quicinc.com> Signed-off-by: Song Xue <quic_songxue@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241218-add_usb_host_mode_for_qcs615-v3-2-d9d29fe39a4b@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Pengyu Luo [Fri, 20 Dec 2024 16:05:30 +0000 (00:05 +0800)]
arm64: dts: qcom: sc8280xp: Add Huawei Matebook E Go (sc8280xp)
Add an initial devicetree for the Huawei Matebook E Go, which is based on
sc8280xp.
There are 3 variants, Huawei released first 2 at the same time.
Huawei Matebook E Go LTE(sc8180x), codename should be gaokun2.
Huawei Matebook E Go(sc8280xp@3.0GHz), codename is gaokun3.
Huawei Matebook E Go 2023(sc8280xp@2.69GHz).
We add support for the latter two variants.
This work started by Tianyu Gao and Xuecong Chen, they made the
devicetree based on existing work(i.e. the Lenovo X13s and the
Qualcomm CRD), it can boot with framebuffer.
Original work: https://github.com/matalama80td3l/matebook-e-go-boot-works/blob/main/dts/sc8280xp-huawei-matebook-e-go.dts
Later, I got my device, I continue their work.
Supported features:
- adsp
- bluetooth (connect issue)
- charge (with a lower power)
- framebuffer
- gpu
- keyboard (via internal USB)
- pcie devices (wifi and nvme, no modem)
- speakers and microphones
- tablet mode switch
- touchscreen
- usb
- volume key and power key
Some key features not supported yet:
- battery and charger information report (EC driver required)
- built-in display (cannot enable backlight yet)
- charging thresholds control (EC driver required)
- camera
- LID switch detection (EC driver required)
- USB Type-C altmode (EC driver required)
- USB Type-C PD (EC driver required)
I have finished the EC driver, once this series are upstreamed,
I will submit a series of patches to enable EC support.
Stephan Gerhold [Tue, 10 Dec 2024 09:07:39 +0000 (10:07 +0100)]
arm64: dts: qcom: x1e80100-qcp: Fix USB QMP PHY supplies
On the X1E80100 QCP, &vreg_l3e_1p2 only powers &usb_mp_qmpphy0/1
(i.e. USBSS_3 and USBSS_4). The QMP PHYs for USB_0, USB_1 and USB_2
are actually powered by &vreg_l2j_1p2.
Cc: stable@vger.kernel.org Fixes: 20676f7819d7 ("arm64: dts: qcom: x1e80100-qcp: Fix USB PHYs regulators") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20241210-x1e80100-usb-qmp-supply-fix-v1-8-0adda5d30bbd@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Tue, 10 Dec 2024 09:07:38 +0000 (10:07 +0100)]
arm64: dts: qcom: x1e80100-microsoft-romulus: Fix USB QMP PHY supplies
On the X1E80100 CRD, &vreg_l3e_1p2 only powers &usb_mp_qmpphy0/1
(i.e. USBSS_3 and USBSS_4). The QMP PHYs for USB_0, USB_1 and USB_2
are actually powered by &vreg_l2j_1p2.
Since x1e80100-microsoft-romulus mostly just mirrors the power supplies
from the x1e80100-crd device tree, assume that the fix also applies here.
Cc: stable@vger.kernel.org Fixes: 09d77be56093 ("arm64: dts: qcom: Add support for X1-based Surface Laptop 7 devices") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20241210-x1e80100-usb-qmp-supply-fix-v1-7-0adda5d30bbd@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Tue, 10 Dec 2024 09:07:37 +0000 (10:07 +0100)]
arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Fix USB QMP PHY supplies
On the X1E80100 CRD, &vreg_l3e_1p2 only powers &usb_mp_qmpphy0/1
(i.e. USBSS_3 and USBSS_4). The QMP PHYs for USB_0, USB_1 and USB_2
are actually powered by &vreg_l2j_1p2.
Since x1e80100-lenovo-yoga-slim7x mostly just mirrors the power supplies
from the x1e80100-crd device tree, assume that the fix also applies here.
Stephan Gerhold [Tue, 10 Dec 2024 09:07:36 +0000 (10:07 +0100)]
arm64: dts: qcom: x1e80100-dell-xps13-9345: Fix USB QMP PHY supplies
On the X1E80100 CRD, &vreg_l3e_1p2 only powers &usb_mp_qmpphy0/1
(i.e. USBSS_3 and USBSS_4). The QMP PHYs for USB_0, USB_1 and USB_2
are actually powered by &vreg_l2j_1p2.
Since x1e80100-dell-xps13-9345 mostly just mirrors the power supplies from
the x1e80100-crd device tree, assume that the fix also applies here.
Cc: stable@vger.kernel.org Fixes: f5b788d0e8cd ("arm64: dts: qcom: Add support for X1-based Dell XPS 13 9345") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Tested-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20241210-x1e80100-usb-qmp-supply-fix-v1-5-0adda5d30bbd@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Tue, 10 Dec 2024 09:07:35 +0000 (10:07 +0100)]
arm64: dts: qcom: x1e80100-crd: Fix USB QMP PHY supplies
On the X1E80100 CRD, &vreg_l3e_1p2 only powers &usb_mp_qmpphy0/1
(i.e. USBSS_3 and USBSS_4). The QMP PHYs for USB_0, USB_1 and USB_2
are actually powered by &vreg_l2j_1p2.
Cc: stable@vger.kernel.org Fixes: ae5cee8e7349 ("arm64: dts: qcom: x1e80100-crd: Fix USB PHYs regulators") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20241210-x1e80100-usb-qmp-supply-fix-v1-4-0adda5d30bbd@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Tue, 10 Dec 2024 09:07:34 +0000 (10:07 +0100)]
arm64: dts: qcom: x1e80100-asus-vivobook-s15: Fix USB QMP PHY supplies
On the X1E80100 CRD, &vreg_l3e_1p2 only powers &usb_mp_qmpphy0/1
(i.e. USBSS_3 and USBSS_4). The QMP PHYs for USB_0, USB_1 and USB_2
are actually powered by &vreg_l2j_1p2.
Since x1e80100-asus-vivobook-s15 mostly just mirrors the power supplies
from the x1e80100-crd device tree, assume that the fix also applies here.
Cc: stable@vger.kernel.org Fixes: d0e2f8f62dff ("arm64: dts: qcom: Add device tree for ASUS Vivobook S 15") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Tested-by: Maud Spierings <maud_spierings@hotmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20241210-x1e80100-usb-qmp-supply-fix-v1-3-0adda5d30bbd@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Tue, 10 Dec 2024 09:07:33 +0000 (10:07 +0100)]
arm64: dts: qcom: x1e78100-lenovo-thinkpad-t14s: Fix USB QMP PHY supplies
On the X1E80100 CRD, &vreg_l3e_1p2 only powers &usb_mp_qmpphy0/1
(i.e. USBSS_3 and USBSS_4). The QMP PHYs for USB_0, USB_1 and USB_2
are actually powered by &vreg_l2j_1p2.
Since x1e78100-lenovo-thinkpad-t14s mostly just mirrors the power supplies
from the x1e80100-crd device tree, assume that the fix also applies here.
Cc: stable@vger.kernel.org Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20241210-x1e80100-usb-qmp-supply-fix-v1-2-0adda5d30bbd@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Tue, 10 Dec 2024 09:07:32 +0000 (10:07 +0100)]
arm64: dts: qcom: x1e001de-devkit: Fix USB QMP PHY supplies
On the X1E80100 CRD, &vreg_l3e_1p2 only powers &usb_mp_qmpphy0/1
(i.e. USBSS_3 and USBSS_4). The QMP PHYs for USB_0, USB_1 and USB_2
are actually powered by &vreg_l2j_1p2.
Since x1e001de-devkit mostly just mirrors the power supplies from the
x1e80100-crd device tree, assume that the fix also applies here.
Cc: stable@vger.kernel.org Fixes: 7b8a31e82b87 ("arm64: dts: qcom: Add X1E001DE Snapdragon Devkit for Windows") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20241210-x1e80100-usb-qmp-supply-fix-v1-1-0adda5d30bbd@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Jens Glathe [Mon, 2 Dec 2024 19:59:47 +0000 (20:59 +0100)]
arm64: dts: qcom: sc8280xp-blackrock: dt definition for WDK2023
Device tree for the Microsoft Windows Dev Kit 2023. This work
is based on the initial work of Merck Hung <merckhung@gmail.com>.
Original work: https://github.com/merckhung/linux_ms_dev_kit/blob/ms-dev-kit-2023-v6.3.0/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-dev-kit-2023.dts
The Windows Dev Kit 2023 is a nice little desktop based on sc8280xp. Link: https://learn.microsoft.com/en-us/windows/arm/dev-kit/
Supported features:
- USB type-c and type-a ports
- minidp connector
- built-in r8152 Ethernet adapter
- PCIe devices
- nvme
- ath11k WiFi (WCN6855)
- WCN6855 Bluetooth
- A690 GPU
- ADSP and CDSP
- GPIO keys
- Audio definition (works via USB)
Jens Glathe [Mon, 2 Dec 2024 19:41:31 +0000 (20:41 +0100)]
arm64: dts: qcom: x1e80100-hp-x14: dt for HP Omnibook X Laptop 14
Introduce device tree for the HP Omnibook X Laptop 14-fe0750ng
(hp-omnibook-x14). It is a Laptop based on the Qualcomm Snapdragon
X Elite SoC. There seem to be other SKUs, some with Wifi-7 (WCN7850)
instead of Wifi-6E (WCN6855). This dt explicitly supports WCN6855,
I haven't found a good way yet to describe both.
Stephan Gerhold [Mon, 7 Oct 2024 18:22:25 +0000 (20:22 +0200)]
arm64: dts: qcom: x1e80100: Add QUP power domains and OPPs
Add the power domains and OPP tables to all the QUP-related UART/I2C/SPI
nodes to ensure that we vote for the necessary performance states. Similar
to sm8350.dtsi, the OPPs depend on the QUP instance. The first two
instances in each geniqup group need &rpmhpd_opp_svs starting at 120MHz,
the others already starting at 100MHz. I2C always runs at a lower clock
frequency and therefore uses a fixed vote.
Tingguo Cheng [Mon, 2 Dec 2024 09:37:23 +0000 (17:37 +0800)]
arm64: dts: qcom: move pon reboot-modes from pm8150.dtsi to board files
Reboot modes were originally managed by PMIC pon driver on mobile/IoT
platforms, such as sm8150,sm8250,qdu1000... But recently, QCS615 is
going to adopt PSCI to manage linux reboot modes, which involves firm
wares to co-work with. In this case, reboot-modes should be removed
from pon dts node to avoid conflicting. This implies that reboot modes
go with devices rather than PMICs as well.
Abel Vesa [Mon, 2 Dec 2024 09:23:18 +0000 (11:23 +0200)]
arm64: dts: qcom: x1e78100-qcp: Enable Type-A USB ports labeled 3 and 4/6
The X Elite QCP board has 3 USB-A ports. The ones labed as USB3 and
USB4/6 are both connected to the multiport controller, each one via a
separate NXP PTN3222 eUSB2-to-USB2 redriver to the eUSB2 PHY for
High-Speed support, with a dedicated QMP PHY for SuperSpeed support.
Describe these two redrivers and enable each pair of PHYs along with the
USB controller, all in order to enable support for these 2 USB-A ports.
Abel Vesa [Mon, 2 Dec 2024 09:23:17 +0000 (11:23 +0200)]
arm64: dts: qcom: x1e78100-t14s: Enable support for both Type-A USB ports
The Thinkpad T14s has 2 USB-A ports, both connected to the USB
multiport controller, each one via a separate NXP PTN3222 eUSB2-to-USB2
redriver to the eUSB2 PHY for High-Speed support, with a dedicated QMP
PHY for SuperSpeed support.
Describe each redriver and then enable each pair of PHYs and the
USB controller itself, in order to enable support for the 2 USB-A ports.
Srinivas Kandagatla [Tue, 3 Dec 2024 11:12:29 +0000 (12:12 +0100)]
arm64: dts: qcom: x1e78100-t14s: add sound support
Add support for audio on Lenovo T14s laptop, coming with two speakers,
audio jack and two digital microphones.
This is very early work, not yet complete:
1. 2x speakers: work OK.
2. 2x digital microphones: work OK.
3. Headset (audio jack) recording: does not work.
4. Headphones playback (audio jack): channels are intermixed.
Dmitry Baryshkov [Fri, 10 Mar 2023 20:34:38 +0000 (22:34 +0200)]
arm64: dts: qcom: sm8350-hdk: enable IPA
Although the HDK has no radio, the IPA part is still perfectly usable
(altough it doesn't register any real networking devices). Enable it to
make it possible to test IPA on this platform.
Soutrik Mukhopadhyay [Mon, 25 Nov 2024 10:57:47 +0000 (16:27 +0530)]
arm64: dts: qcom: sa8775p-ride: Enable Display Port
The Qualcomm SA8775P platform comes with 2 DisplayPort controllers
for each mdss. edp0 and edp1 correspond to the DP controllers of
mdss0, whereas edp2 and edp3 correspond to the DP controllers of
mdss1. This change enables only the DP controllers, DPTX0 and DPTX1
alongside their corresponding PHYs of mdss0, which have been
validated.
Maulik Shah [Tue, 12 Nov 2024 11:01:51 +0000 (16:31 +0530)]
arm64: dts: qcom: sa8775p: Add CPUs to psci power domain
Commit 4f79d0deae37 ("arm64: dts: qcom: sa8775p: add CPU idle states")
already added cpu and cluster idle-states but have not added CPU devices
to psci power domain without which idle states do not get detected.
projects / users / jedix / linux-maple.git / log