* Re: [PATCH 0/3] arm64: dts: qcom: msm8916-samsung-coreprimeltevzw: add device tree
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: linux-kernel, Raymond Hackley
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, phone-devel, Max McNamee,
Stephan Gerhold, Nikita Travkin, ~postmarketos/upstreaming
In-Reply-To: <20260223220514.2556033-1-wonderfulshrinemaidenofparadise@postmarketos.org>
On Mon, 23 Feb 2026 22:05:11 +0000, Raymond Hackley wrote:
> Samsung Galaxy Core Prime Verizon Wireless is a phone based on MSM8916.
> They are similar to the other Samsung devices based on MSM8916 with only a
> few minor differences.
>
> The device trees contain initial support with:
> - GPIO keys
> - Regulator haptic
> - SDHCI (internal and external storage)
> - USB Device Mode
> - UART (on USB connector via the SM5502 MUIC)
> - WCNSS (WiFi/BT)
> - Regulators
> - QDSP6 audio
> - Speaker/earpiece/headphones/microphones via digital/analog codec in
> MSM8916/PM8916
> - WWAN Internet via BAM-DMUX
> - PMIC and charger
> - Touchscreen
>
> [...]
Applied, thanks!
[1/3] arm64: dts: qcom: msm8916-samsung-fortuna: Move SM5504 from rossa and refactor MUIC
commit: 21450547506ece7e36bef75681479a52e518c53b
[2/3] dt-bindings: qcom: Document samsung,coreprimeltevzw
commit: bb0a09a4fa4821a5a1da1b707e0e169d6a4e8cd2
[3/3] arm64: dts: qcom: msm8916-samsung-coreprimeltevzw: add device tree
commit: 2ce450f77f1de5eb7b489fcd829a7f494952e1bf
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: sm8550-hdk: add support for the Display Card overlay
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Vladimir Zapolskiy
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-arm-msm, devicetree
In-Reply-To: <20260311001238.4191034-1-vladimir.zapolskiy@linaro.org>
On Wed, 11 Mar 2026 02:12:38 +0200, Vladimir Zapolskiy wrote:
> The SM8550-HDK board may be connected to a Display Card external PCB,
> which is identical to the already supported SM8650-HDK Display Card,
> it provides a VTDR6130 display with Goodix Berlin Touch controller, see
> also commit bc90f56a1699 ("arm64: dts: sm8650-hdk: add support for the
> Display Card overlay") for additional details.
>
> Two overlays are added to support SM8550-HDK plus Display Card and
> SM8550-HDK plus Display Card plus Rear Camera Card setups.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: sm8550-hdk: add support for the Display Card overlay
commit: 40c15162c873a481cb0e57f8aaa743a4bc66432f
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: qcom: cleanup remaining zap-shaders
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tobias Heider
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20260328-zap-v1-0-f6810b9b4930@canonical.com>
On Sat, 28 Mar 2026 16:49:20 +0100, Tobias Heider wrote:
> In commit 2377626fd216 ("arm64: dts: qcom: add gpu_zap_shader label")
> most of the Hamoa DTs were converted to use the gpu_zap_shader label
> instead of patching &gpu directly.
>
> This fixes the remaining ones that were added after the
> original fix landed. While there we can also remove the redundant
> memory-region property that is already defined in the original
> node.
>
> [...]
Applied, thanks!
[1/2] arm64: dts: qcom: fix remaining gpu_zap_shader labels
commit: 79772ce80eb9615b69b00e77135bbfc6e4b6f158
[2/2] arm64: dts: qcom: drop redundant zap-shader memory-region
commit: c7c8ed27b71272fad8049d34257cf8ce3e37b097
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v5 0/3] Add support for GPUCC and GXCLK for SM8750
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Taniya Das
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, Konrad Dybcio,
Krzysztof Kozlowski, Abel Vesa
In-Reply-To: <20260305-gpucc_sm8750_v2-v5-0-78292b40b053@oss.qualcomm.com>
On Thu, 05 Mar 2026 16:10:07 +0530, Taniya Das wrote:
> Support the graphics clock controller for SM8750 for Graphics SW
> driver to use the clocks. GXCLKCTL (Graphics GX Clock Controller) is a
> block dedicated to managing clocks for the GPU subsystem on GX power
> domain. The GX clock controller driver manages only the GX GDSC and the
> rest of the resources of the controller are managed by the firmware.
>
> The Graphics GX clock controller is a reuse of the Kaanapali SW driver.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: clock: qcom: Add SM8750 GPU clocks
commit: 4aeadf8a18dbbe4fbe2f8e6f03f48f3492c8d1d1
[2/3] clk: qcom: Add a driver for SM8750 GPU clocks
commit: 5af11acae6608d3b1175aea86bac06f267c6db14
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: monaco: extend fastrpc compute cb
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: konradybcio, robh, krzk+dt, conor+dt, Srinivas Kandagatla
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260326154111.2781802-1-srinivas.kandagatla@oss.qualcomm.com>
On Thu, 26 Mar 2026 15:41:11 +0000, Srinivas Kandagatla wrote:
> For some reason we ended up adding only 4 out of 11 compute cb's for
> CDSP, add the missing compute cb. This will also improve the end
> user-experience by enabling running multiple AI usecases in parallel.
>
>
Applied, thanks!
[1/1] arm64: dts: monaco: extend fastrpc compute cb
commit: af0d19ea5a31261e1e3aebbe7c7e45c57c4df999
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: monaco: extend fastrpc compute cb
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: konradybcio, robh, krzk+dt, conor+dt, Srinivas Kandagatla
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260326125834.2758331-1-srinivas.kandagatla@oss.qualcomm.com>
On Thu, 26 Mar 2026 12:58:34 +0000, Srinivas Kandagatla wrote:
> For some reason we ended up adding only 4 out of 11 compute cb's for
> CDSP, add the missing compute cb. This will also improve the end
> user-experience by enabling running multiple AI usecases in parallel.
>
>
Applied, thanks!
[1/1] arm64: dts: monaco: extend fastrpc compute cb
commit: af0d19ea5a31261e1e3aebbe7c7e45c57c4df999
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] Add Qualcomm SA8650P SoC to socinfo
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: linux-arm-msm, linux-kernel, devicetree, Radu Rendec
Cc: Lei wang, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260321152307.9131-1-rrendec@redhat.com>
On Sat, 21 Mar 2026 11:23:05 -0400, Radu Rendec wrote:
> Add SoC ID for SA8650P to socinfo.
>
> Minor edits to commit messages for better clarity and to match previous
> submissions that add a SoC to socinfo.
>
Applied, thanks!
[1/2] dt-bindings: arm: qcom,ids: Add SoC ID for SA8650P
commit: a559a742c95c55ae3b347f2b57d26830c0cdd566
[2/2] soc: qcom: socinfo: Add SoC ID for SA8650P
commit: f55fa3e3dcd8f766266fdf878994f0ec09459a7d
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: purwa-iot-evk: Enable UFS
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Manivannan Sadhasivam, Dmitry Baryshkov, Pradeep P V K
Cc: linux-arm-msm, devicetree, linux-kernel, nitin.rawat
In-Reply-To: <20260323-purwa-ufs-v2-1-58fb2c168786@oss.qualcomm.com>
On Mon, 23 Mar 2026 18:17:53 +0530, Pradeep P V K wrote:
> Enable UFS for purwa-iot-evk board.
>
> This patch depends on [PATCH V5 2/3] arm64: dts: qcom: hamoa: Add UFS
> nodes for x1e80100 SoC
> https://lore.kernel.org/all/20260211132926.3716716-3-pradeep.pragallapati@oss.qualcomm.com/
>
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: purwa-iot-evk: Enable UFS
commit: 7658e9b94849ca861ded82d641f52fcec303210d
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v4 0/4] Add DSI display support for SC8280XP
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Krishna Manikandan, Jonathan Marek, Pengyu Luo
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Tianyu Gao, White Lewis
In-Reply-To: <20260308064835.479356-1-mitltlatltl@gmail.com>
On Sun, 08 Mar 2026 14:48:31 +0800, Pengyu Luo wrote:
> Add DSI display support for SC8280XP.
>
Applied, thanks!
[4/4] arm64: dts: qcom: sc8280xp: Add dsi nodes on SC8280XP
commit: 2f4c5dea9a285cc24a80e9fef8d7014bffce967b
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 0/3] SDM670 cache controller support
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Conor Dooley, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, linux-arm-msm, devicetree, Richard Acayan
In-Reply-To: <20260210021957.13357-1-mailingradian@gmail.com>
On Mon, 09 Feb 2026 21:19:54 -0500, Richard Acayan wrote:
> This adds support for the Low-Level Cache Controller (LLCC) on SDM670.
>
> Richard Acayan (3):
> dt-bindings: cache: qcom,llcc: Add SDM670 compatible
> soc: qcom: llcc: Add configuration data for SDM670
> arm64: dts: qcom: sdm670: add llcc
>
> [...]
Applied, thanks!
[3/3] arm64: dts: qcom: sdm670: add llcc
commit: 3aa997129993135ff1e11128e216af814e72f0a0
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 0/2] Front camera enablement on Fairphone 5
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vladimir Zapolskiy, Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Konrad Dybcio
In-Reply-To: <20260319-fp5-s5kjn1-v3-0-9cf4b8c09567@fairphone.com>
On Thu, 19 Mar 2026 16:36:27 +0100, Luca Weiss wrote:
> Since the Samsung S5KJN1 driver was upstreamed recently, we can enable
> the camera upstream by adding a few bits to dts.
>
>
Applied, thanks!
[1/2] arm64: dts: qcom: qcm6490-fairphone-fp5: Sort pinctrl nodes by pins
commit: e7fc3c46dc09c1c5f901f1a627d9bffc6321081c
[2/2] arm64: dts: qcom: qcm6490-fairphone-fp5: Add front camera support
commit: 1d44de258d34f33aadda67d69dae5a8427b9d2c7
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/3] Add CCI support for Milos, enable on Fairphone (Gen. 6)
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, linux-i2c, linux-arm-msm,
devicetree, linux-kernel, Krzysztof Kozlowski, Konrad Dybcio
In-Reply-To: <20260320-milos-cci-v2-0-1947fc83f756@fairphone.com>
On Fri, 20 Mar 2026 09:09:48 +0100, Luca Weiss wrote:
> Add the compatible strings for the CCI busses on Milos, and the EEPROMs
> found on the Fairphone (Gen. 6) camera modules, and add them to the
> milos dtsi and device dts.
>
> This series soft-depends on https://lore.kernel.org/linux-arm-msm/20260116-milos-camcc-icc-v1-0-400b7fcd156a@fairphone.com/T/
>
> The patches can be applied without the dependency, but the final dts
> patches should probably only land once the other series has been fully
> applied, otherwise the CCI busses cannot actually be used (unless some
> other component turns on the mmss_noc) and you get a kernel warning like
> the following:
>
> [...]
Applied, thanks!
[2/3] arm64: dts: qcom: milos: Add CCI busses
commit: e9e75b3e622bccefe3ccc7e167e36f58369a388d
[3/3] arm64: dts: qcom: milos-fairphone-fp6: Add camera EEPROMs on CCI busses
commit: 924d734960062b0665d551c82489ad2cb4d96e80
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: hamoa-evk: Add DP0/DP1 audio playback support
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Le Qi
Cc: linux-arm-msm, devicetree, linux-kernel, kernel
In-Reply-To: <20260210024037.3719191-1-le.qi@oss.qualcomm.com>
On Tue, 10 Feb 2026 10:40:37 +0800, Le Qi wrote:
> The hamoa-evk DTS currently lacks DAI links for DP0 and DP1, preventing
> the sound card from exposing these playback paths. Add the missing links
> to enable audio output on both DP interfaces.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: hamoa-evk: Add DP0/DP1 audio playback support
commit: 20eb0aa76f7ceebbf897019e3eeeca0a1d24e3f5
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Loic Poulain, Sumit Garg,
linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260325122209.147128-2-krzysztof.kozlowski@oss.qualcomm.com>
On Wed, 25 Mar 2026 13:22:10 +0100, Krzysztof Kozlowski wrote:
> Device node has children with MMIO addressing, so must have ranges:
>
> msm/qcom,qcm2290-mdss.example.dtb: display-subsystem@5e00000 (qcom,qcm2290-mdss): 'ranges' is a required property
>
>
Applied, thanks!
[1/1] dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example
commit: 88bdac5443e5269bb39c4968d5ee0becbffe3f82
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Add thermal sensors
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260327101225.382493-2-krzysztof.kozlowski@oss.qualcomm.com>
On Fri, 27 Mar 2026 11:12:26 +0100, Krzysztof Kozlowski wrote:
> Add TSENS thermal sensors to Qualcomm Eliza SoC among with thermal
> zones. The TSENS is compatible with previous generations.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: eliza: Add thermal sensors
commit: 7f390d6ccbaa3313758b172fd8cbadc6c652c48a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: firmware: qcom,scm: Document ipq9650 SCM
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Robert Marko, Guru Das Srinagesh, Kathiravan Thirumoorthy
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260325-ipq9650_scm-v1-1-ad6a3fe53f38@oss.qualcomm.com>
On Wed, 25 Mar 2026 17:09:43 +0530, Kathiravan Thirumoorthy wrote:
> Document the scm compatible for ipq9650 SoC.
>
>
Applied, thanks!
[1/1] dt-bindings: firmware: qcom,scm: Document ipq9650 SCM
commit: dc67808832d3a1d337c314a2c950f9bf774a21b2
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: kaanapali: Duplicate whitespace cleanup
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jingyi Wang
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260330-knp-space-cleanup-v1-1-0995302f7557@oss.qualcomm.com>
On Mon, 30 Mar 2026 02:39:42 -0700, Jingyi Wang wrote:
> Exactly one space is expected before '{' characters, clean
> up duplicate whitespaces.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: kaanapali: Duplicate whitespace cleanup
commit: 45ac3ced1b79fe25e135a0c5e5ad063166b8fd51
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC 0/2] sdm845: describe the Wi-Fi hardware properly
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Heidelberg
Cc: Paul Sajna, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260327-wcn3990-pwrctl-sdm845-v1-0-3f5c34e3fdd0@ixit.cz>
On Fri, 27 Mar 2026 14:07:07 +0100, David Heidelberg wrote:
> Question here is, if the most of the wcn3990-pmu shouldn't rather go to
> sdm845.dtsi? At least the regulators seems to be same.
>
> When agreed, I'll sent include all other sdm845 phones in the patchset.
>
>
Applied, thanks!
[1/2] arm64: dts: qcom: sdm845-google: Describe Wi-Fi/BT properly
commit: 0a9c8715663998dc4d8eaa8f1a40440214906d96
[2/2] arm64: dts: qcom: sdm845-oneplus: Describe Wi-Fi/BT properly
commit: 7a4790b1a2c9ff66bd7a95d8761d5e9fc9334ba9
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8996: fix indentation in sdhc2 node
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Christopher Obbard
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260329-wip-obbardc-msm8996-whitespace-v1-1-ba3a278f043c@linaro.org>
On Sun, 29 Mar 2026 14:12:26 +0100, Christopher Obbard wrote:
> Drop stray leading whitespace from sdhc2 node.
>
> No functional change.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: msm8996: fix indentation in sdhc2 node
commit: 25e7cc37cff444030250abea1ba875c26ff59e9a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: qcom: enable UARTs for robot expansion board
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: konradybcio, Canfeng Zhuang
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-arm-kernel
In-Reply-To: <20260327083101.1343613-1-canfeng.zhuang@oss.qualcomm.com>
On Fri, 27 Mar 2026 16:30:59 +0800, Canfeng Zhuang wrote:
> The Qualcomm Lemans EVK and Monaco EVK boards expose a mezzanine
> connector used by a motor control expansion board.
>
> This expansion board hosts an MCU running NuttX and communicates with
> Linux over UART, with all protocol handling done in userspace.
>
> This series enables the required UARTs and assigns stable serial aliases
> to ensure consistent device enumeration across platforms.
>
> [...]
Applied, thanks!
[1/2] arm64: dts: qcom: lemans-evk: enable UART0 for robot expansion board
commit: 0be638f326c2015ae9406f4238d9bc54b5b7a584
[2/2] arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
commit: 74620bf0c3c6091ecd7972075f5ddeba29994407
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260323-rb3gen2-upd-gl3590-v2-1-073514bf9ed5@oss.qualcomm.com>
On Mon, 23 Mar 2026 21:32:39 -0500, Bjorn Andersson wrote:
> The QCS6490 Rb3Gen2 has a Renesas μPD720201 XHCI controller hanging off
> the TC9563 PCIe switch, on this a Genesys Logic GL3590 USB hub provides
> two USB Type-A ports and an ASIX AX88179 USB 3.0 Gigabit Ethernet
> interface.
>
> The Renesas chip is powered by two regulators controlled through PM7250B
> GPIOs 1 and 4, and the power/reset pin is pulled down by PM8350C GPIO 4.
> The Genesys chip power is always-on, but the reset pin is controlled
> through TLMM GPIO 162.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590
commit: cde64269eeb8099b4405aef8b19b90892a05352e
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/4] clk: qcom: ipq-cmn-pll: Add IPQ6018/IPQ8074 SoC support
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Luo Jie, linux-arm-msm, linux-clk, devicetree,
linux-kernel, Christian Marangi
In-Reply-To: <20260311183942.10134-1-ansuelsmth@gmail.com>
On Wed, 11 Mar 2026 19:39:37 +0100, Christian Marangi wrote:
> Simple series that adds support for the common PLL for
> IPQ6018/IPQ8074 SoC support.
>
> This is an initial effort to try to support the Ethernet Switch
> present on the QualcommAX platform upstream.
>
> John Crispin (4):
> dt-bindings: clock: qcom: Add CMN PLL support for IPQ6018
> clk: qcom: ipq-cmn-pll: Add IPQ6018 SoC support
> dt-bindings: clock: qcom: Add CMN PLL support for IPQ8074
> clk: qcom: ipq-cmn-pll: Add IPQ8074 SoC support
>
> [...]
Applied, thanks!
[1/4] dt-bindings: clock: qcom: Add CMN PLL support for IPQ6018
commit: a57666004f49fa5031d6bf388834213e6f961922
[2/4] clk: qcom: ipq-cmn-pll: Add IPQ6018 SoC support
commit: 97eb2ac52726fbb702ced40d552a3f6f2683b664
[3/4] dt-bindings: clock: qcom: Add CMN PLL support for IPQ8074
commit: 7156c65030006e6930dd99c5b8c5e84e69ca5f0b
[4/4] clk: qcom: ipq-cmn-pll: Add IPQ8074 SoC support
commit: 4e36f8ab45c406420f2c2ce6ee3988e0d13ba1c9
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov, Thara Gopinath, Alexander Koskovich
Cc: linux-arm-msm, devicetree, linux-kernel, Alexander Koskovich
In-Reply-To: <20260307-sm8250-cpu7-opp-v1-1-435f5f6628a1@pm.me>
On Sun, 08 Mar 2026 04:26:37 +0000, Alexander Koskovich wrote:
> This resolves the following error seen on the ASUS ROG Phone 3:
>
> cpu cpu7: Voltage update failed freq=3091200
> cpu cpu7: failed to update OPP for freq=3091200
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP
commit: b683730e27ba4f91986c4c92f5cb7297f1e01a6d
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 0/2] arm64: dts: qcom: milos: Add missing CX power domain to GCC
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Luca Weiss, Taniya Das, Konrad Dybcio,
Dmitry Baryshkov, Abel Vesa
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, Konrad Dybcio
In-Reply-To: <20260327-dt-fix-milos-eliza-gcc-power-domains-v1-0-f14a22c73fe9@oss.qualcomm.com>
On Fri, 27 Mar 2026 14:13:39 +0200, Abel Vesa wrote:
> Recently, on Eliza, the CX has been tied up to the GCC.
> This leads to dt-bindings check failing.
>
> So the schema needs to be fixed. But the schema is same
> for Milos. So instead of adding an if-clause for Eliza only,
> tie the CX power domain to the GCC on Milos as well, for the
> same exact reasons as on Eliza.
>
> [...]
Applied, thanks!
[2/2] arm64: dts: qcom: milos: Add missing CX power domain to GCC
commit: e46b48b853122626806d989d5db4ce97eaaac2ca
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v10 2/2] hwmon: add support for MCP998X
From: Guenter Roeck @ 2026-03-30 16:00 UTC (permalink / raw)
To: Victor.Duicu
Cc: corbet, linux-hwmon, devicetree, robh, linux-kernel, krzk+dt,
linux-doc, conor+dt, Marius.Cristea
In-Reply-To: <2d3955f5b906018fd7670ed5b8d37eaffa0ec207.camel@microchip.com>
On 3/30/26 05:01, Victor.Duicu@microchip.com wrote:
> Hi Guenter,
>
> ...
>
>>> + }
>>> +
>>> + switch (type) {
>>> + case hwmon_temp:
>>> + switch (attr) {
>>> + case hwmon_temp_input:
>>> + /* Block reading from addresses 0x00->0x09 is
>>> not allowed. */
>>> + ret = regmap_read(priv->regmap,
>>> MCP9982_HIGH_BYTE_ADDR(channel), ®_high);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = regmap_read(priv->regmap,
>>> MCP9982_HIGH_BYTE_ADDR(channel) + 1,
>>> + ®_low);
>>> + if (ret)
>>> + return ret;
>>
>> Reading the 11-bit temperature value involves two separate 8-bit
>> register reads.
>> If the chip updates the temperature between these two reads, the
>> resulting value
>> may be torn. While some chips latch the low byte upon reading the
>> high byte,
>> the driver does not explicitly rely on or document this behavior, and
>> it's safer
>> to use regmap_bulk_read if supported, or at least ensure the correct
>> order and
>> atomicity if possible.
>>
>> Note: Maybe the low temperature is latched, but there is no
>> indication in the
>> datasheet that this would be the case. Even if it is, the code above
>> is
>> inefficient.
>
> The low temperature register is latched. In the documentation at
> page 32 it is described that when reading the high byte register,
> the value from the low byte register is copied into a 'shadow'
> register. In this way it is guaranteed that when we read the low byte,
> it will correspond to the high byte.
>
> Regarding the bulk read, the chip has a number of design quirks and
> because of that different commands are supported only on some
> particular memory regions.
>
> According to the documentation page 26, the only areas of memory that
> support SMBus block read are 80h->89h(temperature memory block) and
> 90h->97h(status memory block). In order to block read the temperatures,
> the area of memory targeted has to be the temperature memory block. In
> this context the read operation uses SMBus protocol and the first value
> returned will be the number of addresses that can be read (in our
> particular case a max value of 10 bytes).
>
> In v8 of the driver
> https://lore.kernel.org/all/20251120071248.3767-1-victor.duicu@microchip.com/
> ,
> the temperature values were read with regmap_bulk_read(). In that
> version, regmap_bulk_read() was also used to read the temperature
> limits, without returning count (this is an undocumented feature of the
> chip and because of that we could assume is not supported).
> In order to avoid this behaviour and avoid mixing the SMBus and I2C
> protocols all block readings were removed.
>
> In the hopes of bypassing a long chain of replies, I tested the
> behaviour of the chip with different read instructions.
> Regmap_bulk_read() when applied to the temperature memory block
> (80h->89h) returns count and the high and low bytes. When it is applied
> to the 00h->09h memory, it uses I2C. It returns one temperature byte,
> but all other bytes are returned as 0xFF. The chip behaves as if
> it is at the last register location in the temperature block while the
> host continues to ACK.(behaviour described at page 26).
> If we set use_single_read in regmap_config and apply regmap_bulk_read()
> to the 00h->09h register area the high and low temperature bytes are
> read successfully without count.
>
> Regmap_multi_reg_read() reads a number of registers one by one. When
> applied to the 00h->09h area, I2C is used and it returns only the high
> and low temperature bytes. When applied to the temperature memory block
> (80h->89h), because it is not a bulk function, returns the count till
> the end of the temperature memory block (aka SMBus count).
>
> I2c_smbus_read_block_data() when applied to the temperature block (80h-
> 89h) returns the count, the driver replies with an NACK and the
> communication is stopped. In our case, the board we are using to test
> the driver has an AT91 adapter and supports
> I2C_FUNC_SMBUS_READ_BLOCK_DATA. It seems that the I2C driver for AT91
> does not modify the buff length of the message, leaving it 1.
>
> I2c_smbus_read_i2c_block_data() when applied to the temperature block
> (80h-89h) returns count and the temperature values.
>
> If you are of the opinion that block reading the temperatures is worth
> introducing (even in case we need to skip count) then I can add it, but
> we should come to an agreement on which function to use.
> Please let me know your thoughts.
>
It is your chip, so I'll let you decide. Please include all the above
as comments into the code.
Thanks,
Guenter
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox