* [PATCH] arm64: dts: qcom: sm6115-pro1x: Correct touchscreen GPIO flags
From: Krzysztof Kozlowski @ 2026-04-13 9:05 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dang Huynh, linux-arm-msm, devicetree, linux-kernel
Cc: Krzysztof Kozlowski, stable
IRQ_TYPE_xxx flags are not correct in the context of GPIO flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning: IRQ_TYPE_LEVEL_LOW = 8 = GPIO_TRANSITORY.
Correct the touchscreen irq-gpios to use proper flags, assuming the
author of the code wanted similar logical behavior:
IRQ_TYPE_LEVEL_LOW => GPIO_ACTIVE_LOW
Fixes: e46b455e67f8 ("arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 466ad409e924..1095454716b1 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -151,7 +151,7 @@ touchscreen@14 {
interrupts-extended = <&tlmm 80 IRQ_TYPE_LEVEL_LOW>;
- irq-gpios = <&tlmm 80 IRQ_TYPE_LEVEL_LOW>;
+ irq-gpios = <&tlmm 80 GPIO_ACTIVE_LOW>;
reset-gpios = <&tlmm 71 GPIO_ACTIVE_HIGH>;
AVDD28-supply = <&ts_vdd_supply>;
VDDIO-supply = <&ts_vddio_supply>;
--
2.51.0
^ permalink raw reply related
* [PATCH] arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags
From: Krzysztof Kozlowski @ 2026-04-13 9:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Xu Yang, devicetree, imx, linux-arm-kernel, linux-kernel
Cc: Krzysztof Kozlowski, stable
IRQ_TYPE_xxx flags are not correct in the context of GPIO flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning: IRQ_TYPE_EDGE_FALLING = 2 = GPIO_SINGLE_ENDED.
Correct the Type-C int-gpios to use proper flags, assuming the author of
the code wanted similar logical behavior:
IRQ_TYPE_EDGE_FALLING => GPIO_ACTIVE_LOW
Fixes: c4b4593ecb0b ("arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 290a49bea2f7..5dea66c1e7aa 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -166,7 +166,7 @@ &lpi2c7 {
ptn5150_1: typec@1d {
compatible = "nxp,ptn5150";
reg = <0x1d>;
- int-gpios = <&gpiof 3 IRQ_TYPE_EDGE_FALLING>;
+ int-gpios = <&gpiof 3 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec1>;
status = "disabled";
@@ -182,7 +182,7 @@ pcal6408: gpio@21 {
ptn5150_2: typec@3d {
compatible = "nxp,ptn5150";
reg = <0x3d>;
- int-gpios = <&gpiof 5 IRQ_TYPE_EDGE_FALLING>;
+ int-gpios = <&gpiof 5 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec2>;
status = "disabled";
--
2.51.0
^ permalink raw reply related
* Re: [PING] Re: [PATCH v7 0/2] arm64: dts/defconfig: enable BST C1200 eMMC
From: Krzysztof Kozlowski @ 2026-04-13 9:09 UTC (permalink / raw)
To: Albert Yang, arnd
Cc: krzk+dt, robh, conor+dt, gordon.ge, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260413083441.1758438-1-yangzh0906@thundersoft.com>
On 13/04/2026 10:34, Albert Yang wrote:
> Hi Krzysztof, Arnd, Rob, and Conor,
>
> Gentle ping for this v7 series posted on 2026-03-10:
> https://lore.kernel.org/lkml/20260310091211.4171307-1-yangzh0906@thundersoft.com/
That's a BST patch, so pinging SoC and DT maintainers won't help you.
You need to work with BST maintainers.
Additionally, don't ping during merge window.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Joe Sandom @ 2026-04-13 9:09 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <luljw64s2p5kvxe5itn6zwbjaugkj7a3hndfn6ff25wbwqcwv2@numatjdny6ho>
On Mon, Apr 13, 2026 at 04:39:55AM +0300, Dmitry Baryshkov wrote:
> On Thu, Apr 09, 2026 at 04:26:57PM +0100, Joe Sandom wrote:
> > The RB5gen2 is an embedded development platform for the
> > QCS8550, based on the Snapdragon 8 Gen 2 SoC (SM8550).
> >
> > This change implements the main board, the vision mezzanine
> > will be supported in a follow up patch.
> >
> > The main board has the following features:
> > - Qualcomm Dragonwing QCS8550 SoC
> > - Adreno GPU 740
> > - Spectra ISP
> > - Adreno VPU 8550
> > - Adreno DPU 1295
> > - 1 x 1GbE Ethernet (USB Ethernet)
> > - WIFI 7 + Bluetooth 5.4
> > - 1 x USB 2.0 Micro B (Debug)
> > - 1 x USB 3.0 Type C (ADB, DP out)
> > - 2 x USB 3.0 Type A
> > - 1 x HDMI 1.4 Type A
> > - 1 x DP 1.4 Type C
> > - 2 x WSA8845 Speaker amplifiers
> > - 2 x Speaker connectors
> > - 1 x On Board PDM MIC
> > - Accelerometer + Gyro Sensor
> > - 96Boards compatible low-speed and high-speed connectors [1]
> > - 7 x LED indicators (4 user, 2 radio, 1 power)
> > - Buttons for power, volume up/down, force USB boot
> > - 3 x Dip switches
> >
> > On-Board PMICs:
> > - PMK8550 2.1
> > - PM8550 2.0
> > - PM8550VS 2.0 x4
> > - PM8550VE 2.0
> > - PM8550B 2.0
> > - PMR735D 2.0
> > - PM8010 1.1 x2
> >
> > Product Page: [2]
> >
> > [1] https://urldefense.com/v3/__https://www.96boards.org/specifications/__;!!K76kBA!3gMyDZ3RqJTInuD9UAhneyD_Ga1OTDOm5CbLp15KXHLPV8aflL7_S_i89xs_S_dJ2SHGHnEEyMD5zZMi7iWLAuaVhZPXvg$
> > [2] https://urldefense.com/v3/__https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit__;!!K76kBA!3gMyDZ3RqJTInuD9UAhneyD_Ga1OTDOm5CbLp15KXHLPV8aflL7_S_i89xs_S_dJ2SHGHnEEyMD5zZMi7iWLAuaUXzBHLA$
> >
> > The default msi-map from sm8550.dtsi is deleted for both pcie0 and
> > pcie1. The QPS615 PCIe switch on each port exposes more than two
> > devices (1 USP + 3 DSPs), but Gunyah currently limits ITS device
> > mappings to two per root complex to save memory. With msi-map
> > present, the ITS MAPD command times out.
> >
> > Deleting msi-map causes the DWC controller to fall back to its
> > internal iMSI-RX module, which handles MSIs without this limitation.
> >
> > Signed-off-by: Joe Sandom <jsandom@axon.com>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts | 1573 ++++++++++++++++++++++++++
> > 2 files changed, 1574 insertions(+)
> >
> > +
> > + lt9611_1v2: lt9611-regulator-1v2 {
>
> I think that comes from the RB5 or something similar. Could you please
> rename the nodes to follow the pattern used by other regulators
> (regulator-foo-bar) and place these supplies accordingly.
>
Good point, will amend for v4.
> > + compatible = "regulator-fixed";
> > + regulator-name = "LT9611_1V2";
> > +
> > + regulator-min-microvolt = <1200000>;
> > + regulator-max-microvolt = <1200000>;
> > +
> > + vin-supply = <&vreg_l14b_3p2>;
> > + };
> > +
> > + lt9611_3v3: lt9611-regulator-3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "LT9611_3V3";
> > +
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > +
> > + vin-supply = <&vreg_l14b_3p2>;
> > + };
> > +
> > + pmic-glink {
> > + compatible = "qcom,sm8550-pmic-glink", "qcom,pmic-glink";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + connector@0 {
> > + compatible = "usb-c-connector";
> > + reg = <0>;
> > + power-role = "dual";
> > + data-role = "dual";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + pmic_glink_hs_in: endpoint {
> > + remote-endpoint = <&usb_1_dwc3_hs>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + pmic_glink_ss_in: endpoint {
> > + remote-endpoint = <&redriver_usb_con_ss>;
> > + };
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > +
> > + pmic_glink_sbu_in: endpoint {
> > + remote-endpoint = <&redriver_usb_con_sbu>;
> > + };
> > + };
> > + };
> > + };
> > + };
> > +
> > + pcie_upd_1p05: regulator-pcie-upd-1p05 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "PCIE_UPD_1P05";
> > + gpio = <&tlmm 179 GPIO_ACTIVE_HIGH>;
> > + vin-supply = <&vdd_ntn_0p9>;
> > + regulator-min-microvolt = <1050000>;
> > + regulator-max-microvolt = <1050000>;
> > + enable-active-high;
> > + regulator-enable-ramp-delay = <5000>;
> > + pinctrl-0 = <&upd_1p05_en>;
> > + pinctrl-names = "default";
> > + };
> > +
> > + pcie_upd_3p3: regulator-pcie-upd-3p3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "PCIE_UPD_3P3";
> > + gpio = <&tlmm 13 GPIO_ACTIVE_HIGH>;
> > + vin-supply = <&pcie_upd_1p05>;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + enable-active-high;
> > + regulator-enable-ramp-delay = <10000>;
> > + pinctrl-0 = <&upd_3p3_en>;
> > + pinctrl-names = "default";
> > + };
> > +
> > + vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDD_NTN_0P9";
> > + vin-supply = <&vdd_ntn_1p8>;
> > + regulator-min-microvolt = <899400>;
> > + regulator-max-microvolt = <899400>;
> > + regulator-enable-ramp-delay = <4300>;
> > + };
> > +
> > + vdd_ntn_1p8: regulator-vdd-ntn-1p8 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDD_NTN_1P8";
> > + gpio = <&tlmm 67 GPIO_ACTIVE_HIGH>;
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + enable-active-high;
> > + pinctrl-0 = <&ntn0_en>;
> > + pinctrl-names = "default";
> > + regulator-enable-ramp-delay = <10000>;
> > + };
> > +
> > + vdd_ntn1_0p9: regulator-vdd-ntn1-0p9 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDD_NTN1_0P9";
> > + vin-supply = <&vdd_ntn1_1p8>;
> > + regulator-min-microvolt = <899400>;
> > + regulator-max-microvolt = <899400>;
> > + regulator-enable-ramp-delay = <4300>;
> > + };
> > +
> > + vdd_ntn1_1p8: regulator-vdd-ntn1-1p8 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDD_NTN1_1P8";
> > + gpio = <&tlmm 42 GPIO_ACTIVE_HIGH>;
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + enable-active-high;
> > + pinctrl-0 = <&ntn1_en>;
> > + pinctrl-names = "default";
> > + regulator-enable-ramp-delay = <10000>;
> > + };
> > +
> > + vph_pwr: regulator-vph-pwr {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vph_pwr";
> > + regulator-min-microvolt = <3700000>;
> > + regulator-max-microvolt = <3700000>;
> > +
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + sound {
> > + compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
> > + model = "QCS8550-RB5Gen2";
> > + audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
> > + "SpkrRight IN", "WSA_SPK2 OUT",
> > + "VA DMIC0", "vdd-micb",
> > + "VA DMIC1", "vdd-micb";
> > +
> > + wsa-dai-link {
> > + link-name = "WSA Playback";
> > +
> > + cpu {
> > + sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
> > + };
> > +
> > + codec {
>
> codec < cpu
Ack. Will amend for v4.
>
> > + sound-dai = <&left_spkr>, <&right_spkr>,
> > + <&swr0 0>, <&lpass_wsamacro 0>;
> > + };
> > +
> > + platform {
> > + sound-dai = <&q6apm>;
> > + };
> > + };
> > +
> > + va-dai-link {
> > + link-name = "VA Capture";
> > +
> > + cpu {
> > + sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
> > + };
> > +
> > + codec {
> > + sound-dai = <&lpass_vamacro 0>;
> > + };
> > +
> > + platform {
> > + sound-dai = <&q6apm>;
> > + };
> > + };
> > + };
> > +
> > +
> > +&i2c_hub_3_gpio {
> > + clock-frequency = <400000>;
> > +
> > + status = "okay";
> > +
> > + lt9611_codec: hdmi-bridge@2b {
> > + compatible = "lontium,lt9611uxc";
> > + reg = <0x2b>;
> > +
> > + interrupts-extended = <&tlmm 40 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&tlmm 7 GPIO_ACTIVE_HIGH>;
> > +
> > + vdd-supply = <<9611_1v2>;
> > + vcc-supply = <<9611_3v3>;
> > +
> > + pinctrl-0 = <<9611_irq_pin <9611_rst_pin>;
>
> pinctrl-0 = <<9611_irq_pin>, <<9611_rst_pin>;
>
Ack. Also another instance of this for the tc9563. Will amend both for
v4.
>
> > + pinctrl-names = "default";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + lt9611_a: endpoint {
> > + remote-endpoint = <&mdss_dsi0_out>;
> > + };
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > +
> > + lt9611_out: endpoint {
> > + remote-endpoint = <&hdmi_con>;
> > + };
> > + };
> > + };
> > + };
> > +};
> > +
> > +
> > +&remoteproc_adsp {
> > + firmware-name = "qcom/qcs8550/adsp.mbn",
> > + "qcom/qcs8550/adsp_dtb.mbn";
>
> Sound and GPU firmware is under qcom/sm8550/. Let's don't multiply
> entities and keep all firmware in the same subdir (including the IPA
> firmware too).
>
Fair point. Will amend for v4.
> > + status = "okay";
> > +};
> > +
> > +&remoteproc_cdsp {
> > + firmware-name = "qcom/qcs8550/cdsp.mbn",
> > + "qcom/qcs8550/cdsp_dtb.mbn";
> > + status = "okay";
> > +};
> > +
> > +&remoteproc_mpss {
> > + firmware-name = "qcom/qcs8550/modem.mbn",
> > + "qcom/qcs8550/modem_dtb.mbn";
> > + status = "okay";
> > +};
> > +
>
> --
> With best wishes
> Dmitry
Thanks for your review Dmitry.
- Joe
^ permalink raw reply
* Re: [PATCH 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Krzysztof Kozlowski @ 2026-04-13 9:10 UTC (permalink / raw)
To: Jian Hu, Neil Armstrong, Jerome Brunet, Kevin Hilman,
Michael Turquette, Martin Blumenstingl, robh+dt, Rob Herring
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <274d2abd-05b9-4dbd-b962-ff70044b8d07@amlogic.com>
On 13/04/2026 10:21, Jian Hu wrote:
>
> On 4/12/2026 5:55 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On 10/04/2026 12:03, Jian Hu wrote:
>>> Add support for the A1 and T7 SoC family in amlogic clk measure.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> ---
>>> drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++++++++
>>> 1 file changed, 272 insertions(+)
>>>
>>> diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
>>> index d862e30a244e..083524671b76 100644
>>> --- a/drivers/soc/amlogic/meson-clk-measure.c
>>> +++ b/drivers/soc/amlogic/meson-clk-measure.c
>>> @@ -787,6 +787,258 @@ static const struct meson_msr_id clk_msr_s4[] = {
>>>
>>> };
>>>
>>> +static struct meson_msr_id clk_msr_a1[] = {
>> And existing code uses what sort of array? Seems you send us obsolete or
>> downstream code.
>
>
> Thanks for your review.
>
>
> I have checked the previous Amlogic SoC's commits. Such as Amlogic AXG,
> G12A, C3, S4.
>
> The clk_msr_xx entry is added after last SoC's array, sorted by
> submissin date rather than alphabetical order.
>
> So I place A1 and T7 after S4 accordingly.
>
>
> The A1 clock controller driver was already supported in
> https://lore.kernel.org/all/20230523135351.19133-7-ddrokosov@sberdevices.ru/
>
> It is also present in the mainline kernel:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/meson/Kconfig#n113
>
>
> This clock measure IP is used to measure the internal clock paths
> frequencies, and A1 clock controller driver was supported.
>
> Since the corresponding clock measure driver does not support A1 yet, So
> add A1 clk msr here.
No, what qualifiers or keywords are used for existing arrays? IOW,
please investigate and understand why you are doing this very different
than existing code. Maybe because you sent us downstream, so you
replicated all other downstream issues.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm6115-pro1x: Correct touchscreen GPIO flags
From: Konrad Dybcio @ 2026-04-13 9:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dang Huynh, linux-arm-msm,
devicetree, linux-kernel
Cc: stable
In-Reply-To: <20260413090527.53000-2-krzysztof.kozlowski@oss.qualcomm.com>
On 4/13/26 11:05 AM, Krzysztof Kozlowski wrote:
> IRQ_TYPE_xxx flags are not correct in the context of GPIO flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning: IRQ_TYPE_LEVEL_LOW = 8 = GPIO_TRANSITORY.
>
> Correct the touchscreen irq-gpios to use proper flags, assuming the
> author of the code wanted similar logical behavior:
>
> IRQ_TYPE_LEVEL_LOW => GPIO_ACTIVE_LOW
>
> Fixes: e46b455e67f8 ("arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: Phandles
From: Krzysztof Kozlowski @ 2026-04-13 9:16 UTC (permalink / raw)
To: Kyle Bonnici
Cc: Herve Codina, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <74FB5D90-08F5-422E-9DB2-A00E74E25422@hotmail.com>
On 13/04/2026 10:40, Kyle Bonnici wrote:
>
>> Please wrap your email responses to mailing list style.
>
> Hope I got this part right in this email!
>
>> To repeat my question:
>> What does '1' stand for?
>
> ‘1' was just an random value to show the issue. Please note that
> this issue has more context. This can all be found tin the Zephyr issue
You cannot have random values. I quoted the DT spec.
> https://github.com/zephyrproject-rtos/zephyr/issues/107066
> And also on the discord link.
Well, we don't use discord but IRC... but that github issue also uses
"pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
So again - what is "1"?
I am asking because if you use incorrect value as phandle value, then
DTC warning is obviously expected and nothing to fix here.
>
> To summarize, In zephyr the dts is pickled to a header file on
> compile. Zephyr build system uses the bindings to determine types.
> Any property with no type will not be pickled.
I know, but this is not what you asked, right?
You asked why phandle has to be the first entry in phandle-value type? I
responded that DT spec makes it.
Now to determine that DTC is correct or not correct, we need to
understand what "1" means in this context - is it a valid phandle value?
>
> `/zephyr,user` node is a convenience node that does not need a binding
> And types are inferred from values not property names.
>
> The reported issues:
> - Zephyr is inferring a type but the DTC compiler is inferring another
> type and reporting w waring about it in the build output
Are you reporting bug in Zephyr or DTC?
> - Zephyr does not infer types for properties with no bindings, hence
> If any of mention properties are used and node has no binding for
> that property name, zephyr will ignore this, but the DTC reports a
> warning that contradics Zephyr's implementation.
We discuss DTC here, yes? Whether it has or has not a bug? Please help
me to understand the topic. Why would we care about Zephyr's
implementation? It's Zephyr's problem and I am not a Zephyr developer. I
am not saying that it is not important, just saying that I am not the
audience to discuss it.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/2] dt-bindings: arm: cpus: Fix and extend Qualcomm Oryon compatibles
From: Shawn Guo @ 2026-04-13 9:16 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel, Shawn Guo
This series restores compatible qcom,oryon-1-4 which was accidentally
dropped by merge commit f6935ae6147b, and then adds qcom,oryon-1-5 which
is found on Nord SoC.
Shawn Guo (2):
dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible
dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
Documentation/devicetree/bindings/arm/cpus.yaml | 2 ++
1 file changed, 2 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible
From: Shawn Guo @ 2026-04-13 9:16 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel, Shawn Guo
In-Reply-To: <20260413091625.607976-1-shengchao.guo@oss.qualcomm.com>
It seems that compatible qcom,oryon-1-4 was accidentally dropped during
the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'
of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
Restore it.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 471902ddbb65..5f5ff5e51e51 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -222,6 +222,7 @@ properties:
- qcom,oryon-1-1
- qcom,oryon-1-2
- qcom,oryon-1-3
+ - qcom,oryon-1-4
- qcom,oryon-2-1
- qcom,oryon-2-2
- qcom,oryon-2-3
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Shawn Guo @ 2026-04-13 9:16 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel, Shawn Guo
In-Reply-To: <20260413091625.607976-1-shengchao.guo@oss.qualcomm.com>
Qualcomm Oryon 1-5 is found on Nord SoC. Add compatible for it.
$ cat /proc/cpuinfo
...
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0x5
CPU part : 0x001
CPU revision : 4
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 5f5ff5e51e51..5be89c584026 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -223,6 +223,7 @@ properties:
- qcom,oryon-1-2
- qcom,oryon-1-3
- qcom,oryon-1-4
+ - qcom,oryon-1-5
- qcom,oryon-2-1
- qcom,oryon-2-2
- qcom,oryon-2-3
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 2/2] drm/panel: Add panel driver for ChipWealth CH13726A based panels
From: Neil Armstrong @ 2026-04-13 9:17 UTC (permalink / raw)
To: webgeek1234, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: dri-devel, devicetree, linux-kernel, Teguh Sobirin
In-Reply-To: <20260408-ch13726a-v4-2-9bb1a9b8f329@gmail.com>
On 4/8/26 07:32, Aaron Kling via B4 Relay wrote:
> From: Teguh Sobirin <teguh@sobir.in>
>
> This is used by the AYN Thor for the bottom panel.
>
> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
> drivers/gpu/drm/panel/Kconfig | 11 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-chipwealth-ch13726a.c | 339 ++++++++++++++++++++++
> 3 files changed, 351 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index d6863b28ddc559..e2c00f08f4507d 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -105,6 +105,17 @@ config DRM_PANEL_BOE_TV101WUM_LL2
> Say Y here if you want to support for BOE TV101WUM-LL2
> WUXGA PANEL DSI Video Mode panel
>
> +config DRM_PANEL_CHIPWEALTH_CH13726A
> + tristate "CHIPWEALTH CH13726A-based DSI panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + select DRM_DISPLAY_DP_HELPER
> + select DRM_DISPLAY_HELPER
> + help
> + Say Y here if you want to enable support for ChipWealth
> + CH13726A-based display panels.
> +
> config DRM_PANEL_EBBG_FT8719
> tristate "EBBG FT8719 panel driver"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index a4291dc3905bed..343d283d1620fb 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_BOE_TD4320) += panel-boe-td4320.o
> obj-$(CONFIG_DRM_PANEL_BOE_TH101MB31UIG002_28A) += panel-boe-th101mb31ig002-28a.o
> obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_LL2) += panel-boe-tv101wum-ll2.o
> obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
> +obj-$(CONFIG_DRM_PANEL_CHIPWEALTH_CH13726A) += panel-chipwealth-ch13726a.o
> obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
> obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
> obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> diff --git a/drivers/gpu/drm/panel/panel-chipwealth-ch13726a.c b/drivers/gpu/drm/panel/panel-chipwealth-ch13726a.c
> new file mode 100644
> index 00000000000000..48a5e20e07c487
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-chipwealth-ch13726a.c
> @@ -0,0 +1,339 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * ChipWealth CH13726A MIPI-DSI panel driver
> + * Copyright (c) 2024, Teguh Sobirin <teguh@sobir.in>.
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_panel.h>
> +
> +#include <video/mipi_display.h>
> +
> +struct ch13726a_panel {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct regulator_bulk_data supplies[4];
> + struct gpio_desc *reset_gpio;
> + struct ch13726a_desc *desc;
> + enum drm_panel_orientation orientation;
> + bool prepared;
Drop this, it's handled by the panel core now.
> +};
> +
> +struct ch13726a_desc {
> + unsigned int width_mm;
> + unsigned int height_mm;
> + unsigned int bpc;
> +
> + const struct drm_display_mode *modes;
> + unsigned int num_modes;
> +};
> +
> +static inline struct ch13726a_panel *to_ch13726a_panel(struct drm_panel *panel)
> +{
> + return container_of(panel, struct ch13726a_panel, panel);
> +}
> +
> +static void ch13726a_reset(struct ch13726a_panel *ctx)
> +{
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(10000, 11000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(10000, 11000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(10000, 11000);
> +}
> +
> +static int ch13726a_on(struct ch13726a_panel *ctx)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +
> + ctx->dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + mipi_dsi_generic_write_seq_multi(&dsi_ctx, 0xf0, 0x50);
> + mipi_dsi_generic_write_seq_multi(&dsi_ctx, 0xb9, 0x00);
> +
> + mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
> +
> + mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
> +
> + return dsi_ctx.accum_err;
> +}
> +
> +static int ch13726a_disable(struct drm_panel *panel)
> +{
> + struct ch13726a_panel *ctx = to_ch13726a_panel(panel);
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +
> + ctx->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
> + mipi_dsi_msleep(&dsi_ctx, 50);
> + mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
> +
> + return dsi_ctx.accum_err;
> +}
> +
> +static int ch13726a_prepare(struct drm_panel *panel)
> +{
> + struct ch13726a_panel *ctx = to_ch13726a_panel(panel);
> + struct device *dev = &ctx->dsi->dev;
> + int ret;
> +
> + if (ctx->prepared)
> + return 0;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + if (ret < 0) {
> + dev_err(dev, "Failed to enable regulators: %d\n", ret);
> + return ret;
> + }
> +
> + ch13726a_reset(ctx);
> +
> + ret = ch13726a_on(ctx);
> + if (ret < 0) {
> + dev_err(dev, "Failed to initialize panel: %d\n", ret);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + return ret;
> + }
> +
> + msleep(28);
> +
> + ctx->prepared = true;
> +
> + return 0;
> +}
> +
> +static int ch13726a_unprepare(struct drm_panel *panel)
> +{
> + struct ch13726a_panel *ctx = to_ch13726a_panel(panel);
> +
> + if (!ctx->prepared)
> + return 0;
> +
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +
> + ctx->prepared = false;
> + return 0;
> +}
> +
> +static const struct drm_display_mode thor_bottom_modes[] = {
> + {
> + /* 120Hz */
> + .clock = (1080 + 28 + 4 + 36) * (1240 + 16 + 4 + 8) * 120 / 1000,
> + .hdisplay = 1080,
> + .hsync_start = 1080 + 28,
> + .hsync_end = 1080 + 28 + 4,
> + .htotal = 1080 + 28 + 4 + 36,
> + .vdisplay = 1240,
> + .vsync_start = 1240 + 16,
> + .vsync_end = 1240 + 16 + 4,
> + .vtotal = 1240 + 16 + 4 + 8,
> + },
> + {
> + /* 60Hz */
> + .clock = (1080 + 28 + 4 + 36) * (1240 + 16 + 4 + 8) * 60 / 1000,
> + .hdisplay = 1080,
> + .hsync_start = 1080 + 28,
> + .hsync_end = 1080 + 28 + 4,
> + .htotal = 1080 + 28 + 4 + 36,
> + .vdisplay = 1240,
> + .vsync_start = 1240 + 16,
> + .vsync_end = 1240 + 16 + 4,
> + .vtotal = 1240 + 16 + 4 + 8,
> + }
> +};
> +
> +static struct ch13726a_desc thor_bottom_desc = {
> + .modes = thor_bottom_modes,
> + .num_modes = ARRAY_SIZE(thor_bottom_modes),
> + .width_mm = 65,
> + .height_mm = 75,
> + .bpc = 8,
> +};
> +
> +static int ch13726a_get_modes(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + struct ch13726a_panel *ctx = to_ch13726a_panel(panel);
> +
> + for (uint8_t i = 0; i < ctx->desc->num_modes; i++) {
> + const struct drm_display_mode *m = &ctx->desc->modes[i];
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(connector->dev, m);
> + if (!mode) {
> + dev_err(&ctx->dsi->dev, "failed to add mode %ux%u@%u\n",
> + m->hdisplay, m->vdisplay, drm_mode_vrefresh(m));
> + return -ENOMEM;
> + }
Can you use drm_connector_helper_get_modes_fixed instead ?
> +
> + mode->type = DRM_MODE_TYPE_DRIVER;
> + if (i == 0)
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> +
> + drm_mode_set_name(mode);
> + drm_mode_probed_add(connector, mode);
> + }
> +
> + connector->display_info.width_mm = ctx->desc->width_mm;
> + connector->display_info.height_mm = ctx->desc->height_mm;
> + connector->display_info.bpc = ctx->desc->bpc;
> +
> + return ctx->desc->num_modes;
> +}
> +
> +static enum drm_panel_orientation ch13726a_get_orientation(struct drm_panel *panel)
> +{
> + struct ch13726a_panel *ctx = to_ch13726a_panel(panel);
> +
> + return ctx->orientation;
> +}
> +
> +static const struct drm_panel_funcs ch13726a_panel_funcs = {
> + .prepare = ch13726a_prepare,
> + .unprepare = ch13726a_unprepare,
> + .disable = ch13726a_disable,
> + .get_modes = ch13726a_get_modes,
> + .get_orientation = ch13726a_get_orientation,
> +};
> +
> +static int ch13726a_bl_update_status(struct backlight_device *bl)
> +{
> + struct mipi_dsi_device *dsi = bl_get_data(bl);
> + u16 brightness = backlight_get_brightness(bl);
> + int ret;
> +
> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + ret = mipi_dsi_dcs_set_display_brightness(dsi, brightness);
> + if (ret < 0)
> + return ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + return 0;
> +}
> +
> +static const struct backlight_ops ch13726a_bl_ops = {
> + .update_status = ch13726a_bl_update_status,
> +};
> +
> +static struct backlight_device *
> +ch13726a_create_backlight(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = &dsi->dev;
> + const struct backlight_properties props = {
> + .type = BACKLIGHT_RAW,
> + .brightness = 255,
> + .max_brightness = 255,
> + };
> +
> + return devm_backlight_device_register(dev, dev_name(dev), dev, dsi,
> + &ch13726a_bl_ops, &props);
> +}
> +
> +static int ch13726a_probe(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = &dsi->dev;
> + struct ch13726a_panel *ctx;
> + int ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + ctx->desc = (struct ch13726a_desc *)of_device_get_match_data(dev);
> + if (!ctx->desc)
> + return -ENODEV;
> +
> + ctx->supplies[0].supply = "vdd1v2";
> + ctx->supplies[1].supply = "vddio";
> + ctx->supplies[2].supply = "vdd";
> + ctx->supplies[3].supply = "avdd";
> +
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
> + ctx->supplies);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to get regulators\n");
> +
Can you switch to devm_regulator_bulk_get_const ?
> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(ctx->reset_gpio))
> + return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio),
> + "Failed to get reset-gpios\n");
> +
> + ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
> + if (ret < 0) {
> + dev_err(dev, "%pOF: failed to get orientation %d\n", dev->of_node, ret);
> + return ret;
> + }
> +
> + ctx->dsi = dsi;
> + mipi_dsi_set_drvdata(dsi, ctx);
> +
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> + MIPI_DSI_CLOCK_NON_CONTINUOUS;
> +
> + drm_panel_init(&ctx->panel, dev, &ch13726a_panel_funcs,
> + DRM_MODE_CONNECTOR_DSI);
Please use devm_drm_panel_alloc() instead.
> + ctx->panel.prepare_prev_first = true;
> +
> + ctx->panel.backlight = ch13726a_create_backlight(dsi);
> + if (IS_ERR(ctx->panel.backlight))
> + return dev_err_probe(dev, PTR_ERR(ctx->panel.backlight),
> + "Failed to create backlight\n");
> +
> + drm_panel_add(&ctx->panel);
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0) {
> + dev_err(dev, "Failed to attach to DSI host: %d\n", ret);
> + drm_panel_remove(&ctx->panel);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void ch13726a_remove(struct mipi_dsi_device *dsi)
> +{
> + struct ch13726a_panel *ctx = mipi_dsi_get_drvdata(dsi);
> + int ret;
> +
> + ret = mipi_dsi_detach(dsi);
> + if (ret < 0)
> + dev_err(&dsi->dev, "Failed to detach from DSI host: %d\n", ret);
> +
> + drm_panel_remove(&ctx->panel);
> +}
> +
> +static const struct of_device_id ch13726a_of_match[] = {
> + { .compatible = "ayntec,thor-panel-bottom", .data = &thor_bottom_desc },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, ch13726a_of_match);
> +
> +static struct mipi_dsi_driver ch13726a_driver = {
> + .probe = ch13726a_probe,
> + .remove = ch13726a_remove,
> + .driver = {
> + .name = "panel-ch13726a-amoled",
> + .of_match_table = ch13726a_of_match,
> + },
> +};
> +module_mipi_dsi_driver(ch13726a_driver);
> +
> +MODULE_DESCRIPTION("DRM driver for CH13726A DSI panels");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* [PATCH v1 1/4] arm64: dts: qcom: Enable secondary mi2s
From: Kumar Anurag @ 2026-04-13 9:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, devicetree, linux-kernel, linux-sound,
Kumar Anurag
In-Reply-To: <20260413091937.134469-1-kumar.singh@oss.qualcomm.com>
Enable secondary mi2s to support HDMI audio.
Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 5 +++
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 43 ++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 6079e67ea829..d1009debc12b 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -5827,6 +5827,11 @@ mi2s1_ws: mi2s1-ws-state {
function = "mi2s1_ws";
};
+ mi2s1_mclk: mi2s1-mclk-state {
+ pins = "gpio105";
+ function = "sec_mi2s";
+ };
+
pcie0_clkreq_n: pcie0-clkreq-n-state {
pins = "gpio88";
function = "pcie0_clkreqn";
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index e3d2f01881ae..2e4062052828 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -672,6 +672,7 @@ &i2c0 {
lt9611_codec: hdmi-bridge@2b {
compatible = "lontium,lt9611uxc";
reg = <0x2b>;
+ #sound-dai-cells = <1>;
interrupts-extended = <&tlmm 24 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&pm7250b_gpios 2 GPIO_ACTIVE_HIGH>;
@@ -1110,6 +1111,9 @@ &sound {
compatible = "qcom,qcs6490-rb3gen2-sndcard";
model = "QCS6490-RB3Gen2";
+ pinctrl-0 = <&mi2s1_data0>, <&mi2s1_mclk>, <&mi2s1_sclk>, <&mi2s1_ws>;
+ pinctrl-names = "default";
+
audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
"SpkrRight IN", "WSA_SPK2 OUT",
"VA DMIC0", "vdd-micb",
@@ -1149,6 +1153,22 @@ platform {
sound-dai = <&q6apm>;
};
};
+
+ mi2s1-playback-dai-link {
+ link-name = "Secondary MI2S Playback";
+
+ codec {
+ sound-dai = <<9611_codec 0>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai SECONDARY_MI2S_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
};
&swr2 {
@@ -1437,3 +1457,26 @@ &lpass_audiocc {
compatible = "qcom,qcm6490-lpassaudiocc";
/delete-property/ power-domains;
};
+
+&mi2s1_data0 {
+ drive-strength = <8>;
+ bias-disable;
+};
+
+&mi2s1_mclk {
+ drive-strength = <8>;
+ bias-disable;
+ output-high;
+};
+
+&mi2s1_sclk {
+ drive-strength = <8>;
+ bias-disable;
+ output-high;
+};
+
+&mi2s1_ws {
+ drive-strength = <8>;
+ bias-disable;
+ output-high;
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v1 0/4] Enable audio over HDMI and
From: Kumar Anurag @ 2026-04-13 9:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, devicetree, linux-kernel, linux-sound,
Kumar Anurag
This series adds the dt and driver changes for enabling
audio over HDMI and Displayport.
Kumar Anurag (4):
arm64: dts: qcom: Enable secondary mi2s
arm64: dts: qcom: qcs6490: Enable DP audio
ASoC: qcom: q6dsp: Update bit format support for secondary i2s
ASoC: qcom: sc8280xp: don't force S16_LE in hw_params fixup
arch/arm64/boot/dts/qcom/kodiak.dtsi | 5 ++
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 59 ++++++++++++++++++++
sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c | 7 ++-
sound/soc/qcom/sc8280xp.c | 2 -
4 files changed, 69 insertions(+), 4 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v1 2/4] arm64: dts: qcom: qcs6490: Enable DP audio
From: Kumar Anurag @ 2026-04-13 9:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, devicetree, linux-kernel, linux-sound,
Kumar Anurag
In-Reply-To: <20260413091937.134469-1-kumar.singh@oss.qualcomm.com>
Add new dai link to enable DP audio.
Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index 2e4062052828..90fd8822dabd 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -1169,6 +1169,22 @@ platform {
sound-dai = <&q6apm>;
};
};
+
+ dp-dai-link {
+ link-name = "DisplayPort0 Playback";
+
+ codec {
+ sound-dai = <&mdss_dp>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai DISPLAY_PORT_RX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
};
&swr2 {
--
2.34.1
^ permalink raw reply related
* [PATCH v1 3/4] ASoC: qcom: q6dsp: Update bit format support for secondary i2s
From: Kumar Anurag @ 2026-04-13 9:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, devicetree, linux-kernel, linux-sound,
Kumar Anurag
In-Reply-To: <20260413091937.134469-1-kumar.singh@oss.qualcomm.com>
Add 32bit for playback and capture over secondary mi2s.
Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com>
---
sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c b/sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c
index 4eed54b071a5..0664f18d7a44 100644
--- a/sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c
+++ b/sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c
@@ -380,7 +380,9 @@ static struct snd_soc_dai_driver q6dsp_audio_fe_dais[] = {
.stream_name = "Secondary MI2S Playback",
.rates = SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_8000 |
SNDRV_PCM_RATE_16000,
- .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |
+ SNDRV_PCM_FMTBIT_S24_LE |
+ SNDRV_PCM_FMTBIT_S32_LE,
.channels_min = 1,
.channels_max = 8,
.rate_min = 8000,
@@ -394,7 +396,8 @@ static struct snd_soc_dai_driver q6dsp_audio_fe_dais[] = {
.rates = SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_8000 |
SNDRV_PCM_RATE_16000,
.formats = SNDRV_PCM_FMTBIT_S16_LE |
- SNDRV_PCM_FMTBIT_S24_LE,
+ SNDRV_PCM_FMTBIT_S24_LE |
+ SNDRV_PCM_FMTBIT_S32_LE,
.channels_min = 1,
.channels_max = 8,
.rate_min = 8000,
--
2.34.1
^ permalink raw reply related
* [PATCH v1 4/4] ASoC: qcom: sc8280xp: don't force S16_LE in hw_params fixup
From: Kumar Anurag @ 2026-04-13 9:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, devicetree, linux-kernel, linux-sound,
Kumar Anurag
In-Reply-To: <20260413091937.134469-1-kumar.singh@oss.qualcomm.com>
The machine driver was unconditionally forcing S16_LE in
sc8280xp_be_hw_params_fixup(), which prevents links (e.g. HDMI bridges)
that require 32-bit formats from working. Drop the format override and
keep only the fixed rate/channels constraints.
Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com>
---
sound/soc/qcom/sc8280xp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
index 7925aa3f63ba..c00eabf200b7 100644
--- a/sound/soc/qcom/sc8280xp.c
+++ b/sound/soc/qcom/sc8280xp.c
@@ -75,10 +75,8 @@ static int sc8280xp_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
SNDRV_PCM_HW_PARAM_RATE);
struct snd_interval *channels = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_CHANNELS);
- struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
rate->min = rate->max = 48000;
- snd_mask_set_format(fmt, SNDRV_PCM_FORMAT_S16_LE);
channels->min = 2;
channels->max = 2;
switch (cpu_dai->id) {
--
2.34.1
^ permalink raw reply related
* [PATCH] ARM: dts: bcm4709: fix bus range assignment
From: Arnd Bergmann @ 2026-04-13 9:21 UTC (permalink / raw)
To: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rosen Penev
Cc: soc, Arnd Bergmann, Broadcom internal kernel review list,
linux-arm-kernel, devicetree, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The netgear r8000 dts file limits the bus range for the first host
bridge to exclude bus 0, but the two devices on the first bus are
explicitly assigned to bus 0, causing a build time warning:
/home/arnd/arm-soc/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts:142.3-27: Warning (pci_device_bus_num): /axi@18000000/pcie@13000/pcie@0/pcie@0,0/pcie@1,0:bus-range: PCI bus number 0 out of range, expected (1 - 255)
/home/arnd/arm-soc/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts:142.3-27: Warning (pci_device_bus_num): /axi@18000000/pcie@13000/pcie@0/pcie@0,0/pcie@2,0:bus-range: PCI bus number 0 out of range, expected (1 - 255)
I could not find any reason why this is done in the first place, but
this can be easily addressed by reassigning the two devices to
bus 1, or by dropping the bus-range property in order to allow
secondary bus 0 to be assigned.
Assuming the bus-range is intentional, fix this by moving the
devices to the first valid secondary bus number.
Fixes: 893faf67438c ("ARM: dts: BCM5301X: add root pcie bridges")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
index d170c71cbd76..355be5014943 100644
--- a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
@@ -147,7 +147,7 @@ pcie@0,0 {
pcie@1,0 {
device_type = "pci";
- reg = <0x800 0 0 0 0>;
+ reg = <0x10800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
@@ -162,7 +162,7 @@ wifi@0,0 {
pcie@2,0 {
device_type = "pci";
- reg = <0x1000 0 0 0 0>;
+ reg = <0x11000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Neil Armstrong @ 2026-04-13 9:24 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jian Hu, Jerome Brunet, Kevin Hilman,
Michael Turquette, Martin Blumenstingl, robh+dt, Rob Herring
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <b0d81181-d4a4-4c03-8c26-c7f6e8cde70f@kernel.org>
On 4/13/26 11:10, Krzysztof Kozlowski wrote:
> On 13/04/2026 10:21, Jian Hu wrote:
>>
>> On 4/12/2026 5:55 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On 10/04/2026 12:03, Jian Hu wrote:
>>>> Add support for the A1 and T7 SoC family in amlogic clk measure.
>>>>
>>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>>> ---
>>>> drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++++++++
>>>> 1 file changed, 272 insertions(+)
>>>>
>>>> diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
>>>> index d862e30a244e..083524671b76 100644
>>>> --- a/drivers/soc/amlogic/meson-clk-measure.c
>>>> +++ b/drivers/soc/amlogic/meson-clk-measure.c
>>>> @@ -787,6 +787,258 @@ static const struct meson_msr_id clk_msr_s4[] = {
>>>>
>>>> };
>>>>
>>>> +static struct meson_msr_id clk_msr_a1[] = {
>>> And existing code uses what sort of array? Seems you send us obsolete or
>>> downstream code.
>>
>>
>> Thanks for your review.
>>
>>
>> I have checked the previous Amlogic SoC's commits. Such as Amlogic AXG,
>> G12A, C3, S4.
>>
>> The clk_msr_xx entry is added after last SoC's array, sorted by
>> submissin date rather than alphabetical order.
>>
>> So I place A1 and T7 after S4 accordingly.
>>
>>
>> The A1 clock controller driver was already supported in
>> https://lore.kernel.org/all/20230523135351.19133-7-ddrokosov@sberdevices.ru/
>>
>> It is also present in the mainline kernel:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/meson/Kconfig#n113
>>
>>
>> This clock measure IP is used to measure the internal clock paths
>> frequencies, and A1 clock controller driver was supported.
>>
>> Since the corresponding clock measure driver does not support A1 yet, So
>> add A1 clk msr here.
>
> No, what qualifiers or keywords are used for existing arrays? IOW,
> please investigate and understand why you are doing this very different
> than existing code. Maybe because you sent us downstream, so you
> replicated all other downstream issues.
I see, the existing uses "static const struct".
Jian, could to switch to that please ?
Neil
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] drm/panel: simple: Add Startek KD070HDFLD092 LVDS panel support
From: Neil Armstrong @ 2026-04-13 9:25 UTC (permalink / raw)
To: Stefan Kerkmann, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260407-panel-simple-startek-upstream-v1-2-76721696655f@pengutronix.de>
On 4/7/26 11:31, Stefan Kerkmann wrote:
> The Startek KD070HDFLD092 is a 7" WSVGA LVDS panel.
>
> Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 91ab280869bac..737a1014f8112 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -4540,6 +4540,32 @@ static const struct panel_desc starry_kr070pe2t = {
> .connector_type = DRM_MODE_CONNECTOR_DPI,
> };
>
> +static const struct display_timing startek_kd070hdfld092_timing = {
> + .pixelclock = { 40800000, 51200000, 67200000 },
> + .hactive = { 1024, 1024, 1024 },
> + .hfront_porch = { 40, 160, 216 },
> + .hback_porch = { 30, 140, 140 },
> + .hsync_len = { 20, 20, 20 },
> + .vactive = { 600, 600, 600 },
> + .vfront_porch = { 2, 12, 177 },
> + .vback_porch = { 5, 20, 20 },
> + .vsync_len = { 3, 3, 3 },
> + .flags = DISPLAY_FLAGS_DE_HIGH,
> +};
> +
> +static const struct panel_desc startek_kd070hdfld092 = {
> + .timings = &startek_kd070hdfld092_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 154,
> + .height = 86,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH,
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
> +};
> +
> static const struct display_timing startek_kd070wvfpa_mode = {
> .pixelclock = { 25200000, 27200000, 30500000 },
> .hactive = { 800, 800, 800 },
> @@ -5532,6 +5558,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "starry,kr070pe2t",
> .data = &starry_kr070pe2t,
> + }, {
> + .compatible = "startek,kd070hdfld092",
> + .data = &startek_kd070hdfld092,
> }, {
> .compatible = "startek,kd070wvfpa",
> .data = &startek_kd070wvfpa,
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v7 0/2] i2c: Add Loongson-2K0300 I2C controller support
From: Binbin Zhou @ 2026-04-13 9:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Wolfram Sang, Andy Shevchenko,
linux-i2c, Huacai Chen, Xuerui Wang, loongarch, devicetree
In-Reply-To: <CAHp75Veymi3z2atMuSeDyrhyx-HLHgCMzJF5EgpJZzTGgpcD3Q@mail.gmail.com>
On Mon, Apr 13, 2026 at 4:18 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Mon, Apr 13, 2026 at 11:08 AM Binbin Zhou <zhoubb.aaron@gmail.com> wrote:
> > On Mon, Apr 13, 2026 at 3:52 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Sat, Apr 11, 2026 at 12:58 PM Binbin Zhou <zhoubinbin@loongson.cn> wrote:
>
> ...
>
> > > > - parent_rate_MHz -> parent_rate_mhz to avoid CamelCase.
> > >
> > > Was it a special requirement from maintainers?
> >
> > I’m actually a bit confused, because when I submitted the v6 patchset,
> > checkpatch didn’t issue this warning.
> > But now, it produces the following output:
> >
> > scripts/checkpatch.pl --strict i2c-ls2k0300-v6/v6-0002*
> > CHECK: Avoid CamelCase: <parent_rate_MHz>
>
> It's a false positive of the checkpatch.
OK, I will revert this change.
>
> > #512: FILE: drivers/i2c/busses/i2c-ls2x-v2.c:437:
> > + priv->parent_rate_MHz = clk_get_rate(priv->clk);
> >
> > total: 0 errors, 0 warnings, 1 checks, 574 lines checked
> >
> > NOTE: For some of the reported defects, checkpatch may be able to
> > mechanically convert to the typical style using --fix or --fix-inplace
> >
> > > Note, the physical units are special. The m and M have quite a
> > > different multiplier value. So, even if asked by somebody I think it's
> > > still arguably should be kept as MHz.
>
> See above why.
I see, thanks.
>
> --
> With Best Regards,
> Andy Shevchenko
--
Thanks.
Binbin
^ permalink raw reply
* Re: [PATCH 0/2] wifi: ath: Use static calibration variant table for devicetree platforms
From: Ernest Van Hoecke @ 2026-04-13 9:32 UTC (permalink / raw)
To: Baochen Qiang
Cc: Manivannan Sadhasivam, Jeff Johnson, Jeff Johnson, Johannes Berg,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-wireless,
linux-kernel, ath10k, ath11k, devicetree, ath12k, Miaoqing Pan
In-Reply-To: <ff11954f-345f-4865-a86e-759aa167768d@oss.qualcomm.com>
On Wed, Apr 08, 2026 at 02:06:00PM +0800, Baochen Qiang wrote:
>
>
> On 11/25/2025 5:57 PM, Ernest Van Hoecke wrote:
> > On Tue, Nov 18, 2025 at 12:23:20PM +0530, Manivannan Sadhasivam wrote:
> >>
> >> ath12k doesn't seem to require a calibration variant. But even if the user
> >> replaces ath11k chipset with ath10k one, the calibration variant should be the
> >> same as it is platform specific except for WSI.
> >>
> >> - Mani
> >>
> >> --
> >> மணிவண்ணன் சதாசிவம்
> >>
> >
> > Hi all,
> >
> > Jumping in on this thread to ask about how we should handle variants.
> >
> > We are using the WCN7850 device with the ath12k driver and received three
> > board files for this from Silex, signed by Qualcomm. All three support the
> > same board (SX-PCEBE), where one is the board file to be used for the
> > US/EU/JP and the other two are one for higher emissions in the UK/CA and
> > one for lower emissions in the UK/CA.
> >
> > Since these are needed for regulatory differences but support the same
> > board, we were wondering about your views on how to handle that in
> > mainline. I see that there is no support for the board file selection in
> > the device tree for ath12k, and that there is some discussion on how to
> > handle variants in general. We are using a device tree-based setup and no
> > ACPI.
>
> does your machine has different 'model' property for different BDFs ?
> does the existing ath11k 'calibration' property based mechanism satisfy your requirement?
>
We have a SoM with always the same WiFi SoC on board. These SoMs are
then mated with a carrier board, in our case often a development board,
and together they form a whole machine for which we have a specific
device tree with a specific model and compatible name.
Customers that create their own carrier board would have their own
device tree with their own model string. These carrier board device
trees include the base SoM dtsi.
When these devices are sold in multiple markets, the model string is
thus not specific to it. For example, the same model string can be sold
in Japan and in Canada, with different regulatory requirements and thus
a different board file that needs to be used.
In short: no, the machine does not have a different model property for
different BDFs.
Similarly, the WCN7850 would also not have a different PCI ID in
different regions since the hardware sold is the same.
The existing ath11k calibration property did provide a way to specify in
the DT which BDF should be used, so in that way it can provide a
solution yes. Of course, with the drawback that the PCI device has to be
specified in the DT.
This would allow customers to ship their device with a different DT
based on the the target market and its regulatory requirements. Another
mechanism that allows them to specify which variant to use in SW/HW
in- or outside the device tree would also work.
Thanks for looking at this and kind regards,
Ernest
^ permalink raw reply
* Re: [PATCH v21 2/6] pwm: driver for qualcomm ipq6018 pwm block
From: Uwe Kleine-König @ 2026-04-13 9:35 UTC (permalink / raw)
To: george.moussalem
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-pwm, devicetree, linux-kernel,
Devi Priya
In-Reply-To: <20260406-ipq-pwm-v21-2-6ed1e868e4c2@outlook.com>
[-- Attachment #1: Type: text/plain, Size: 5061 bytes --]
Hello,
On Mon, Apr 06, 2026 at 10:24:39PM +0200, George Moussalem via B4 Relay wrote:
> From: Devi Priya <quic_devipriy@quicinc.com>
>
> Driver for the PWM block in Qualcomm IPQ6018 line of SoCs. Based on
> driver from downstream Codeaurora kernel tree. Removed support for older
> (V1) variants because I have no access to that hardware.
>
> Tested on IPQ5018 and IPQ6010 based hardware.
>
> Co-developed-by: Baruch Siach <baruch.siach@siklu.com>
> Signed-off-by: Baruch Siach <baruch.siach@siklu.com>
> Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
> Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
I have a few remaining nitpicks. If you're ok I'll squash the following
diff into this patch and apply it:
diff --git a/drivers/pwm/pwm-ipq.c b/drivers/pwm/pwm-ipq.c
index b79e5e457d1a..65af19ded72c 100644
--- a/drivers/pwm/pwm-ipq.c
+++ b/drivers/pwm/pwm-ipq.c
@@ -2,7 +2,7 @@
/*
* Copyright (c) 2016-2017, 2020 The Linux Foundation. All rights reserved.
*
- * Hardware notes / Limitations:
+ * Limitations:
* - The PWM controller has no publicly available datasheet.
* - Each of the four channels is programmed via two 32-bit registers
* (REG0 and REG1 at 8-byte stride).
This is to make
sed -rn '/Limitations:/,/\*\/?$/p' drivers/pwm/*.c
do the right thing. I know "Limitations" isn't a good subject for this,
but until I come around to pick a better marker, doing the same in all
drivers is good.
@@ -44,13 +44,6 @@
#define IPQ_PWM_REG1 4
#define IPQ_PWM_REG1_PRE_DIV GENMASK(15, 0)
-
-/*
- * The max value specified for each field is based on the number of bits
- * in the pwm control register for that field (16-bit)
- */
-#define IPQ_PWM_MAX_DIV FIELD_MAX(IPQ_PWM_REG0_PWM_DIV)
-
/*
* Enable bit is set to enable output toggling in pwm device.
* Update bit is set to trigger the change and is unset automatically
@@ -59,6 +52,12 @@
#define IPQ_PWM_REG1_UPDATE BIT(30)
#define IPQ_PWM_REG1_ENABLE BIT(31)
+/*
+ * The max value specified for each field is based on the number of bits
+ * in the pwm control register for that field (16-bit)
+ */
+#define IPQ_PWM_MAX_DIV FIELD_MAX(IPQ_PWM_REG0_PWM_DIV)
+
struct ipq_pwm_chip {
void __iomem *mem;
unsigned long clk_rate;
This is just about ordering definitions taken 1:1 from the manual before
driver specific stuff.
@@ -95,6 +94,12 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
unsigned long val = 0;
unsigned long hi_dur;
+ if (!state->enabled) {
+ /* clear IPQ_PWM_REG1_ENABLE */
+ ipq_pwm_reg_write(pwm, IPQ_PWM_REG1, IPQ_PWM_REG1_UPDATE);
+ return 0;
+ }
+
if (state->polarity != PWM_POLARITY_NORMAL)
return -EINVAL;
This ensures that the PWM can be disabled even if state->polarity is
bogus or period and duty_cycle are out of range.
@@ -102,7 +107,8 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
* Check the upper and lower bounds for the period as per
* hardware limits
*/
- period_ns = max(state->period, IPQ_PWM_MIN_PERIOD_NS);
+ if (state->period < IPQ_PWM_MIN_PERIOD_NS)
+ return -ERANGE;
period_ns = min(state->period, IPQ_PWM_MAX_PERIOD_NS);
duty_ns = min(state->duty_cycle, period_ns);
This is about correctness. A driver is expected to never configure a
higher value than requested. (And otherwise I would have converted that
to clamp().)
@@ -134,7 +140,7 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
/* pwm duty = HI_DUR * (PRE_DIV + 1) / clk_rate */
hi_dur = mul_u64_u64_div_u64(duty_ns, ipq_chip->clk_rate,
- (u64)(pre_div + 1) * NSEC_PER_SEC);
+ (u64)NSEC_PER_SEC * (pre_div + 1));
val = FIELD_PREP(IPQ_PWM_REG0_HI_DURATION, hi_dur) |
FIELD_PREP(IPQ_PWM_REG0_PWM_DIV, pwm_div);
Just consistency with the period calculation
@@ -144,9 +150,7 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
ipq_pwm_reg_write(pwm, IPQ_PWM_REG1, val);
/* PWM enable toggle needs a separate write to REG1 */
- val |= IPQ_PWM_REG1_UPDATE;
- if (state->enabled)
- val |= IPQ_PWM_REG1_ENABLE;
+ val |= IPQ_PWM_REG1_UPDATE | IPQ_PWM_REG1_ENABLE;
ipq_pwm_reg_write(pwm, IPQ_PWM_REG1, val);
return 0;
Simplification that is possible after checking for state->enabled early.
@@ -174,7 +178,7 @@ static int ipq_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
hi_dur = FIELD_GET(IPQ_PWM_REG0_HI_DURATION, reg0);
pre_div = FIELD_GET(IPQ_PWM_REG1_PRE_DIV, reg1);
- effective_div = (u64)(pre_div + 1) * (pwm_div + 1);
+ effective_div = (u64)(pwm_div + 1) * (pre_div + 1)
/*
* effective_div <= 0x100000000, so the multiplication doesn't overflow.
Again consistency.
A nice followup for this patch would be the conversion to the waveform
API; just in case you're still motivated to work on this driver :-)
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Jon Hunter @ 2026-04-13 9:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, pshete, linux-gpio, devicetree, linux-tegra,
linux-kernel, arnd, bjorn.andersson, conor+dt, dmitry.baryshkov,
ebiggers, geert, krzk+dt, kuninori.morimoto.gx, linusw,
luca.weiss, michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp,
sven, thierry.reding, webgeek1234
In-Reply-To: <097f71e0-cbc8-44e3-ba60-8bac79cf5217@nvidia.com>
On 10/04/2026 09:25, Jon Hunter wrote:
>
>
> On 10/04/2026 07:37, Krzysztof Kozlowski wrote:
>> On 09/04/2026 15:13, pshete@nvidia.com wrote:
>>> From: Prathamesh Shete <pshete@nvidia.com>
>>>
>>> Building the Pinctrl driver into the kernel image increases its size.
>>
>> That's obvious.
>>
>>> These drivers are not required during early boot, build them as a
>>> loadable
>>> module instead to reduce the kernel image size.
>>
>> So you replace built-in into module?
>>>
>>> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
>>> ---
>>> arch/arm64/configs/defconfig | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>> index dd1ac01ee29b..f525670d3b84 100644
>>> --- a/arch/arm64/configs/defconfig
>>> +++ b/arch/arm64/configs/defconfig
>>> @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
>>> CONFIG_PINCTRL_SM8550_LPASS_LPI=m
>>> CONFIG_PINCTRL_SM8650_LPASS_LPI=m
>>> CONFIG_PINCTRL_SOPHGO_SG2000=y
>>> +CONFIG_PINCTRL_TEGRA238=m
>>> +CONFIG_PINCTRL_TEGRA264=m
>>
>> No, you just added as module. Why do we want them in upstream defconfig?
>>
>> Standard question, already asked Nvidia more than once.
>
> Yes :-)
>
> Prathamesh, what we need to do is ...
>
> 1. Add a patch to populate the pinctrl DT nodes for Tegra264 device.
> 2. In this patch, only enable pinctrl for Tegra264 because we are
> lacking an upstream board for Tegra238 for that moment. In the commit
> message we should add a comment to indicate with Tegra264 platform is
> using this.
Thinking about this some more, I think I would prefer that we skip the
defconfig patch and just add ...
default m if ARCH_TEGRA_238_SOC
default m if ARCH_TEGRA_264_SOC
... in the respective Kconfig files for the drivers.
Jon
--
nvpublic
^ permalink raw reply
* Re: Phandles
From: Kyle Bonnici @ 2026-04-13 9:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herve Codina, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <c0983f3d-5025-4933-ac22-bfbc1adc6c31@kernel.org>
> You cannot have random values. I quoted the DT spec.
Where in the DTS 0.4 spec are property names such as pwms, clocks
etc… mandated to be of format <phandle cell …>?
> Well, we don't use discord but IRC... but that github issue also uses
> "pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
>
> So again - what is "1"?
>
> I am asking because if you use incorrect value as phandle value, then
> DTC warning is obviously expected and nothing to fix here.
The warning is only valid if ‘1’ is expected to be a phandle which is what I am
Arguing the spec does not mandate this.
> You asked why phandle has to be the first entry in phandle-value type? I
> responded that DT spec makes it.
Which section in DTS 0.4 spec?
> We discuss DTC here, yes? Whether it has or has not a bug? Please help
> me to understand the topic. Why would we care about Zephyr's
> implementation? It's Zephyr's problem and I am not a Zephyr developer. I
> am not saying that it is not important, just saying that I am not the
> audience to discuss it.
I am arguing that the DTC Spec 0.4 does NOT mandate any of these any of these
“cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”,
“msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”,
“clocks”, “sound_dai” and “thermal_sensors”
must follow <phandle cell …>.
This is only mandated by the dt-schema as far as I understand, that is a used by
Linux, but not Zephyr and the DTC Making the assumption that this is true for
all systems
Regards
Kyle
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible
From: Konrad Dybcio @ 2026-04-13 9:57 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260413091625.607976-2-shengchao.guo@oss.qualcomm.com>
On 4/13/26 11:16 AM, Shawn Guo wrote:
> It seems that compatible qcom,oryon-1-4 was accidentally dropped during
> the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'
> of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
> Restore it.
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ 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