Krzysztof Kozlowski [Fri, 13 Dec 2024 14:53:55 +0000 (15:53 +0100)]
arm64: dts: qcom: sm8450: Fix MPSS memory length
The address space in MPSS/Modem PAS (Peripheral Authentication Service)
remoteproc node should point to the QDSP PUB address space
(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
copied from older DTS, but it grew since then.
This should have no functional impact on Linux users, because PAS loader
does not use this address space at all.
Fixes: 1172729576fb ("arm64: dts: qcom: sm8450: Add remoteproc enablers and instances") Cc: stable@vger.kernel.org Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-6-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Krzysztof Kozlowski [Fri, 13 Dec 2024 14:53:54 +0000 (15:53 +0100)]
arm64: dts: qcom: sm8450: Fix CDSP memory length
The address space in CDSP PAS (Peripheral Authentication Service)
remoteproc node should point to the QDSP PUB address space
(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x1400000 was
copied from older DTS, but it does not look accurate at all.
This should have no functional impact on Linux users, because PAS loader
does not use this address space at all.
Fixes: 1172729576fb ("arm64: dts: qcom: sm8450: Add remoteproc enablers and instances") Cc: stable@vger.kernel.org Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-5-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Krzysztof Kozlowski [Fri, 13 Dec 2024 14:53:53 +0000 (15:53 +0100)]
arm64: dts: qcom: sm8450: Fix ADSP memory base and length
The address space in ADSP PAS (Peripheral Authentication Service)
remoteproc node should point to the QDSP PUB address space
(QDSP6...SS_PUB): 0x0300_0000 with length of 0x10000, which also matches
downstream DTS. 0x3000_0000, value used so far, was in datasheet is the
region of CDSP.
Correct the base address and length, which also moves the node to
different place to keep things sorted by unit address. The diff looks
big, but only the unit address and "reg" property were changed. This
should have no functional impact on Linux users, because PAS loader does
not use this address space at all.
Fixes: 1172729576fb ("arm64: dts: qcom: sm8450: Add remoteproc enablers and instances") Cc: stable@vger.kernel.org Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-4-2e0036fccd8d@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Krzysztof Kozlowski [Fri, 13 Dec 2024 14:53:52 +0000 (15:53 +0100)]
arm64: dts: qcom: sm8350: Fix MPSS memory length
The address space in MPSS/Modem PAS (Peripheral Authentication Service)
remoteproc node should point to the QDSP PUB address space
(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
copied from older DTS, but it grew since then.
This should have no functional impact on Linux users, because PAS loader
does not use this address space at all.
Krzysztof Kozlowski [Fri, 13 Dec 2024 14:53:51 +0000 (15:53 +0100)]
arm64: dts: qcom: sm8350: Fix CDSP memory base and length
The address space in CDSP PAS (Peripheral Authentication Service)
remoteproc node should point to the QDSP PUB address space
(QDSP6...SS_PUB): 0x0a30_0000 with length of 0x10000. 0x9890_0000,
value used so far, was copied from downstream DTS, is in the middle of
RAM/DDR space and downstream DTS describes the PIL loader, which is a
bit different interface. Datasheet says that one of the main CDSP
address spaces is 0x0980_0000, which is oddly similar to 0x9890_0000,
but quite different.
Assume existing value (thus downstream DTS) is not really describing the
intended CDSP PAS region.
Correct the base address and length, which also moves the node to
different place to keep things sorted by unit address. The diff looks
big, but only the unit address and "reg" property were changed. This
should have no functional impact on Linux users, because PAS loader does
not use this address space at all.
Krzysztof Kozlowski [Fri, 13 Dec 2024 14:53:50 +0000 (15:53 +0100)]
arm64: dts: qcom: sm8350: Fix ADSP memory base and length
The address space in ADSP PAS (Peripheral Authentication Service)
remoteproc node should point to the QDSP PUB address space
(QDSP6...SS_PUB): 0x0300_0000 with length of 0x10000. 0x1730_0000,
value used so far, was copied from downstream DTS, is in the middle of
unused space and downstream DTS describes the PIL loader, which is a bit
different interface.
Assume existing value (thus downstream DTS) is not really describing the
intended ADSP PAS region.
Correct the base address and length, which also moves the node to
different place to keep things sorted by unit address. The diff looks
big, but only the unit address and "reg" property were changed. This
should have no functional impact on Linux users, because PAS loader does
not use this address space at all.
Richard Acayan [Wed, 18 Dec 2024 23:17:34 +0000 (18:17 -0500)]
arm64: dts: qcom: sdm670: add camcc
The camera clock controller on SDM670 controls the clocks that drive the
camera subsystem. The clocks are the same as on SDM845. Add the camera
clock controller for SDM670.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Richard Acayan <mailingradian@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241218231729.270137-11-mailingradian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Manikanta Mylavarapu [Fri, 3 Jan 2025 06:37:07 +0000 (12:07 +0530)]
arm64: dts: qcom: ipq5424: add spi nodes
Serial engines 4 and 5 on the IPQ5424 support SPI. Serial engine 4 is
exclusively dedicated to SPI, whereas serial engine 5 is firmware based
and supports SPI, I2C, and UART.
The SPI instance operates on serial engine 4, designated as spi0, and on
serial engine 5, designated as spi1. Add both the spi0 and spi1 nodes.
Luo Jie [Fri, 3 Jan 2025 07:31:38 +0000 (15:31 +0800)]
arm64: dts: qcom: ipq9574: Update xo_board_clk to use fixed factor clock
xo_board_clk is fixed to 24 MHZ, which is routed from WiFi output clock
48 MHZ (also being the reference clock of CMN PLL) divided 2 by analog
block routing channel.
Luo Jie [Fri, 3 Jan 2025 07:31:37 +0000 (15:31 +0800)]
arm64: dts: qcom: ipq9574: Add CMN PLL node
The CMN PLL clock controller allows selection of an input clock rate
from a defined set of input clock rates. It in-turn supplies fixed
rate output clocks to the hardware blocks that provide the ethernet
functions such as PPE (Packet Process Engine) and connected switch or
PHY, and to GCC.
The reference clock of CMN PLL is routed from XO to the CMN PLL through
the internal WiFi block.
.XO (48 MHZ or 96 MHZ)-->WiFi (multiplier/divider)-->48 MHZ to CMN PLL.
The reference input clock from WiFi to CMN PLL is fully controlled by
the bootstrap pins which select the XO frequency (48 MHZ or 96 MHZ).
Based on this frequency, the divider in the internal Wi-Fi block is
automatically configured by hardware (1 for 48 MHZ, 2 for 96 MHZ), to
ensure output clock to CMN PLL is 48 MHZ.
The CMN PLL controller provides clocks to networking hardware blocks
and to GCC on Qualcomm IPQ9574 SoC. It receives input clock from the
on-chip Wi-Fi, and produces output clocks at fixed rates. These output
rates are predetermined, and are unrelated to the input clock rate.
The primary purpose of CMN PLL is to supply clocks to the networking
hardware such as PPE (packet process engine), PCS and the externally
connected switch or PHY device. The CMN PLL block also outputs fixed
rate clocks to GCC, such as 24 MHZ as XO clock and 32 KHZ as sleep
clock supplied to GCC.
Neil Armstrong [Mon, 30 Dec 2024 12:44:49 +0000 (13:44 +0100)]
arm64: dts: qcom: sm8150-microsoft-surface-duo: fix typos in da7280 properties
The dlg,const-op-mode & dlg,periodic-op-mode were mis-names with twice
the "dlg," prefix, drop one to match the bindings.
This fixes:
sm8150-microsoft-surface-duo.dtb: da7280@4a: 'dlg,const-op-mode' is a required property
from schema $id: http://devicetree.org/schemas/input/dlg,da7280.yaml#
m8150-microsoft-surface-duo.dtb: da7280@4a: 'dlg,periodic-op-mode' is a required property
from schema $id: http://devicetree.org/schemas/input/dlg,da7280.yaml#
sm8150-microsoft-surface-duo.dtb: da7280@4a: 'dlg,dlg,const-op-mode', 'dlg,dlg,periodic-op-mode' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/input/dlg,da7280.yaml#
With the dlg,da7280.yaml converted from dlg,da7280.txt at [1].
Neil Armstrong [Mon, 30 Dec 2024 12:44:48 +0000 (13:44 +0100)]
arm64: dts: qcom: sc7180: fix psci power domain node names
Rename the psci power domain node names to match the bindings.
This Fixes:
sc7180-acer-aspire1.dts: psci: 'cpu-cluster0', 'cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6', 'cpu7' do not match any of the regexes: '^power-domain-', 'pinctrl-[0-9]+'
Neil Armstrong [Mon, 30 Dec 2024 12:44:47 +0000 (13:44 +0100)]
arm64: dts: qcom: sc7180-trogdor-pompom: rename 5v-choke thermal zone
Rename the 5v-choke thermal zone to satisfy the bindings.
This fixes:
sc7180-trogdor-pompom-r2-lte.dts: thermal-zones: '5v-choke-thermal' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,10}-thermal$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml#
The bindings requires the avee-supply, use the same regulator as
the avdd (positive voltage) which would also provide the negative
voltage by definition.
The fixes:
sc7180-trogdor-quackingstick-r0.dts: panel@0: 'avee-supply' is a required property
from schema $id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
Neil Armstrong [Mon, 30 Dec 2024 12:44:45 +0000 (13:44 +0100)]
arm64: dts: qcom: sdm845-db845c-navigation-mezzanine: remove disabled ov7251 camera
The ov7251node has bindings check errors in the endpoint, and the
camera node was disabled since the beginning. Even when switching the
node to okay, the endpoint description to the csiphy is missing along
with the csiphy parameters.
Drop the ov7251 camera entirely until it's properly described.
This obviously fixes:
sdm845-db845c-navigation-mezzanine.dtso: camera@60: port:endpoint:data-lanes: [0, 1] is too long
from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov7251.yaml#
The orientation-switch property is not documented in the PHY bindings,
remove it.
This fixes:
qcm6490-shift-otter.dts: phy@88e3000: 'orientation-switch' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/phy/qcom,usb-snps-femto-v2.yaml#
Prashanth K [Tue, 31 Dec 2024 08:11:15 +0000 (13:41 +0530)]
arm64: dts: qcom: sc8180x: 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 QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable
when U1/U2 is enabled. Often when link enters U2, there is a re-
enumeration seen and device is unusable for many use cases.
3. On QCS8300/QCS9100, it is observed that when Link enters U2, when
the cable is disconnected and reconnected to host PC in HS, there
is no link status change interrupt seen and the plug-in in HS doesn't
show up a bus reset and enumeration failure happens.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Prashanth K [Tue, 31 Dec 2024 08:11:14 +0000 (13:41 +0530)]
arm64: dts: qcom: sc8280xp: 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 QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable
when U1/U2 is enabled. Often when link enters U2, there is a re-
enumeration seen and device is unusable for many use cases.
3. On QCS8300/QCS9100, it is observed that when Link enters U2, when
the cable is disconnected and reconnected to host PC in HS, there
is no link status change interrupt seen and the plug-in in HS doesn't
show up a bus reset and enumeration failure happens.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Prashanth K [Tue, 31 Dec 2024 08:11:13 +0000 (13:41 +0530)]
arm64: dts: qcom: qdu1000: 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 QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable
when U1/U2 is enabled. Often when link enters U2, there is a re-
enumeration seen and device is unusable for many use cases.
3. On QCS8300/QCS9100, it is observed that when Link enters U2, when
the cable is disconnected and reconnected to host PC in HS, there
is no link status change interrupt seen and the plug-in in HS doesn't
show up a bus reset and enumeration failure happens.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Prashanth K [Tue, 31 Dec 2024 08:11:12 +0000 (13:41 +0530)]
arm64: dts: qcom: x1e80100: 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 QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable
when U1/U2 is enabled. Often when link enters U2, there is a re-
enumeration seen and device is unusable for many use cases.
3. On QCS8300/QCS9100, it is observed that when Link enters U2, when
the cable is disconnected and reconnected to host PC in HS, there
is no link status change interrupt seen and the plug-in in HS doesn't
show up a bus reset and enumeration failure happens.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Prashanth K [Tue, 31 Dec 2024 08:11:11 +0000 (13:41 +0530)]
arm64: dts: qcom: sc7180: 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 QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable
when U1/U2 is enabled. Often when link enters U2, there is a re-
enumeration seen and device is unusable for many use cases.
3. On QCS8300/QCS9100, it is observed that when Link enters U2, when
the cable is disconnected and reconnected to host PC in HS, there
is no link status change interrupt seen and the plug-in in HS doesn't
show up a bus reset and enumeration failure happens.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Prashanth K [Tue, 31 Dec 2024 08:11:10 +0000 (13:41 +0530)]
arm64: dts: qcom: qcs404: 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 QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable
when U1/U2 is enabled. Often when link enters U2, there is a re-
enumeration seen and device is unusable for many use cases.
3. On QCS8300/QCS9100, it is observed that when Link enters U2, when
the cable is disconnected and reconnected to host PC in HS, there
is no link status change interrupt seen and the plug-in in HS doesn't
show up a bus reset and enumeration failure happens.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Prashanth K [Tue, 31 Dec 2024 08:11:09 +0000 (13:41 +0530)]
arm64: dts: qcom: sdx75: 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.
3. On targets like SDX75, intermittent disconnects were observed
with certain cables due to impedence variations.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Prashanth K [Tue, 31 Dec 2024 08:11:08 +0000 (13:41 +0530)]
arm64: dts: qcom: sdm845: 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.
Prashanth K [Tue, 31 Dec 2024 08:11:07 +0000 (13:41 +0530)]
arm64: dts: qcom: sdm630: 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.
Krishna Kurapati [Tue, 31 Dec 2024 08:11:06 +0000 (13:41 +0530)]
arm64: dts: qcom: sa8775p: 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 QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable
when U1/U2 is enabled. Often when link enters U2, there is a re-
enumeration seen and device is unusable for many use cases.
3. On QCS8300/QCS9100, it is observed that when Link enters U2, when
the cable is disconnected and reconnected to host PC in HS, there
is no link status change interrupt seen and the plug-in in HS doesn't
show up a bus reset and enumeration failure happens.
Disabling these intermittent power states enhances device stability
without affecting power usage.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Prashanth K <quic_prashk@quicinc.com> Link: https://lore.kernel.org/r/20241231081115.3149850-9-quic_prashk@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Krishna Kurapati [Tue, 31 Dec 2024 08:11:05 +0000 (13:41 +0530)]
arm64: dts: qcom: sc7280: 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 QCS6490-Rb3Gen2 Vision kit, ADB connection is heavily unstable
when U1/U2 is enabled. Often when link enters U2, there is a re-
enumeration seen and device is unusable for many use cases.
3. On QCS8300/QCS9100, it is observed that when Link enters U2, when
the cable is disconnected and reconnected to host PC in HS, there
is no link status change interrupt seen and the plug-in in HS doesn't
show up a bus reset and enumeration failure happens.
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-8-quic_prashk@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Krishna Kurapati [Tue, 31 Dec 2024 08:11:04 +0000 (13:41 +0530)]
arm64: dts: qcom: sm6350: 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-7-quic_prashk@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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>
projects / users / jedix / linux-maple.git / log