.../bindings/interconnect/qcom,osm-l3.yaml | 1 + arch/arm64/boot/dts/qcom/sm8550.dtsi | 367 +++++++++++++++++++++ 2 files changed, 368 insertions(+)
Add the OSM L3 controller node then add the necessary interconnect
properties with the appropriate OPP table for each CPU cluster to
allow the DDR, LLCC & L3 CPU bandwidth to scale along the CPU
cluster operating point.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Changes in v3:
- Squash the last two patches
- Link to v2: https://lore.kernel.org/r/20260218-sm8550-ddr-bw-scaling-v2-0-43a2b6d47e70@gmail.com
Changes in v2:
- Squash first two patches
- Update opp tables in last patch to match how the downstream driver
parses those tables
- Link to v1: https://lore.kernel.org/r/20260207-sm8550-ddr-bw-scaling-v1-0-d96c3f39ac4b@gmail.com
---
Aaron Kling (2):
dt-bindings: interconnect: OSM L3: Document sm8550 OSM L3 compatible
arm64: dts: qcom: sm8550: add cpu OPP table with DDR, LLCC & L3 bandwidths
.../bindings/interconnect/qcom,osm-l3.yaml | 1 +
arch/arm64/boot/dts/qcom/sm8550.dtsi | 367 +++++++++++++++++++++
2 files changed, 368 insertions(+)
---
base-commit: 9845cf73f7db6094c0d8419d6adb848028f4a921
change-id: 20260207-sm8550-ddr-bw-scaling-b1524827f207
Best regards,
--
Aaron Kling <webgeek1234@gmail.com>
On Thu, Feb 19, 2026 at 10:07 PM Aaron Kling via B4 Relay <devnull+webgeek1234.gmail.com@kernel.org> wrote: > > Add the OSM L3 controller node then add the necessary interconnect > properties with the appropriate OPP table for each CPU cluster to > allow the DDR, LLCC & L3 CPU bandwidth to scale along the CPU > cluster operating point. > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com> > --- > Changes in v3: > - Squash the last two patches > - Link to v2: https://lore.kernel.org/r/20260218-sm8550-ddr-bw-scaling-v2-0-43a2b6d47e70@gmail.com > > Changes in v2: > - Squash first two patches > - Update opp tables in last patch to match how the downstream driver > parses those tables > - Link to v1: https://lore.kernel.org/r/20260207-sm8550-ddr-bw-scaling-v1-0-d96c3f39ac4b@gmail.com > > --- > Aaron Kling (2): > dt-bindings: interconnect: OSM L3: Document sm8550 OSM L3 compatible > arm64: dts: qcom: sm8550: add cpu OPP table with DDR, LLCC & L3 bandwidths > > .../bindings/interconnect/qcom,osm-l3.yaml | 1 + > arch/arm64/boot/dts/qcom/sm8550.dtsi | 367 +++++++++++++++++++++ > 2 files changed, 368 insertions(+) > --- > base-commit: 9845cf73f7db6094c0d8419d6adb848028f4a921 > change-id: 20260207-sm8550-ddr-bw-scaling-b1524827f207 > > Best regards, > -- > Aaron Kling <webgeek1234@gmail.com> What is the normal merge sequence and window for linux-arm-msm? I see several things that have been picked up for -next recently, but none of my sm8550 patches that have been reviewed / approved have been picked up yet. Sincerely, Aaron
On 10/03/2026 21:05, Aaron Kling wrote: >> --- >> Aaron Kling (2): >> dt-bindings: interconnect: OSM L3: Document sm8550 OSM L3 compatible >> arm64: dts: qcom: sm8550: add cpu OPP table with DDR, LLCC & L3 bandwidths >> >> .../bindings/interconnect/qcom,osm-l3.yaml | 1 + >> arch/arm64/boot/dts/qcom/sm8550.dtsi | 367 +++++++++++++++++++++ >> 2 files changed, 368 insertions(+) >> --- >> base-commit: 9845cf73f7db6094c0d8419d6adb848028f4a921 >> change-id: 20260207-sm8550-ddr-bw-scaling-b1524827f207 >> >> Best regards, >> -- >> Aaron Kling <webgeek1234@gmail.com> > > What is the normal merge sequence and window for linux-arm-msm? I see > several things that have been picked up for -next recently, but none > of my sm8550 patches that have been reviewed / approved have been > picked up yet. This one is probably waiting on interconnect, no? Not saying that merging here is easy, quite the opposite - it's frustrating, but you can help by responding with actual data, e.g. bindings were merged and DTS can go, instead of just content-less ping. Best regards, Krzysztof
On Tue, Mar 10, 2026 at 3:20 PM Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> wrote: > > On 10/03/2026 21:05, Aaron Kling wrote: > >> --- > >> Aaron Kling (2): > >> dt-bindings: interconnect: OSM L3: Document sm8550 OSM L3 compatible > >> arm64: dts: qcom: sm8550: add cpu OPP table with DDR, LLCC & L3 bandwidths > >> > >> .../bindings/interconnect/qcom,osm-l3.yaml | 1 + > >> arch/arm64/boot/dts/qcom/sm8550.dtsi | 367 +++++++++++++++++++++ > >> 2 files changed, 368 insertions(+) > >> --- > >> base-commit: 9845cf73f7db6094c0d8419d6adb848028f4a921 > >> change-id: 20260207-sm8550-ddr-bw-scaling-b1524827f207 > >> > >> Best regards, > >> -- > >> Aaron Kling <webgeek1234@gmail.com> > > > > What is the normal merge sequence and window for linux-arm-msm? I see > > several things that have been picked up for -next recently, but none > > of my sm8550 patches that have been reviewed / approved have been > > picked up yet. > > > This one is probably waiting on interconnect, no? Not saying that > merging here is easy, quite the opposite - it's frustrating, but you can > help by responding with actual data, e.g. bindings were merged and DTS > can go, instead of just content-less ping. So patch 1, the bindings, has to go via a different tree; then patch 2 goes via linux-arm-msm? Or does the first patch need an ack from other people? I was assuming both of these could be handled by the linux-arm-msm maintainers. Part of this was a reminder, yes, but the question is still honest. I don't know what the expected merge window is here, knowing that is good to know if something got lost in the mix. I've got a couple other patches as well that are standalone dt changes with no other deps. I've had patches to other subsystems that have sat for four or five cycles just waiting on the subsystem maintainers. Aaron
On 3/10/26 10:31 PM, Aaron Kling wrote: > On Tue, Mar 10, 2026 at 3:20 PM Krzysztof Kozlowski > <krzysztof.kozlowski@oss.qualcomm.com> wrote: >> >> On 10/03/2026 21:05, Aaron Kling wrote: >>>> --- >>>> Aaron Kling (2): >>>> dt-bindings: interconnect: OSM L3: Document sm8550 OSM L3 compatible >>>> arm64: dts: qcom: sm8550: add cpu OPP table with DDR, LLCC & L3 bandwidths >>>> >>>> .../bindings/interconnect/qcom,osm-l3.yaml | 1 + >>>> arch/arm64/boot/dts/qcom/sm8550.dtsi | 367 +++++++++++++++++++++ >>>> 2 files changed, 368 insertions(+) >>>> --- >>>> base-commit: 9845cf73f7db6094c0d8419d6adb848028f4a921 >>>> change-id: 20260207-sm8550-ddr-bw-scaling-b1524827f207 >>>> >>>> Best regards, >>>> -- >>>> Aaron Kling <webgeek1234@gmail.com> >>> >>> What is the normal merge sequence and window for linux-arm-msm? I see >>> several things that have been picked up for -next recently, but none >>> of my sm8550 patches that have been reviewed / approved have been >>> picked up yet. >> >> >> This one is probably waiting on interconnect, no? Not saying that >> merging here is easy, quite the opposite - it's frustrating, but you can >> help by responding with actual data, e.g. bindings were merged and DTS >> can go, instead of just content-less ping. > > So patch 1, the bindings, has to go via a different tree; then patch 2 > goes via linux-arm-msm? Or does the first patch need an ack from other > people? I was assuming both of these could be handled by the > linux-arm-msm maintainers. > > Part of this was a reminder, yes, but the question is still honest. I > don't know what the expected merge window is here, knowing that is > good to know if something got lost in the mix. I've got a couple other > patches as well that are standalone dt changes with no other deps. > I've had patches to other subsystems that have sat for four or five > cycles just waiting on the subsystem maintainers. Hi Aaron, Last week i picked the 1st patch, so it's in this week's linux-next releases already. I usually push an immutable branch if there are other patches that depend on the one i picked, so i did that (icc-sm8550-osm-l3 branch). Now the Qualcomm maintainers can pick the dts change if they want. My observations are that the qcom dt tree is closing around -rc5, to give some time for new patches to get tested before they send a pull request to the arm-soc maintainers. If some patch is not picked, it's a good idea to re-base and re-send when the next -rc1 is out. Thanks, Georgi
On 10/03/2026 21:31, Aaron Kling wrote: >>>> >>>> Best regards, >>>> -- >>>> Aaron Kling <webgeek1234@gmail.com> >>> >>> What is the normal merge sequence and window for linux-arm-msm? I see >>> several things that have been picked up for -next recently, but none >>> of my sm8550 patches that have been reviewed / approved have been >>> picked up yet. >> >> >> This one is probably waiting on interconnect, no? Not saying that >> merging here is easy, quite the opposite - it's frustrating, but you can >> help by responding with actual data, e.g. bindings were merged and DTS >> can go, instead of just content-less ping. > > So patch 1, the bindings, has to go via a different tree; then patch 2 > goes via linux-arm-msm? Yes, at least typically. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.