* 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 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 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
* [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
* [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 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 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 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 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
* 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 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
* [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 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
* 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
* 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: [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 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: [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
* [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
* [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] spi: dt-bindings: fsl: Correct GPIO flags in the example
From: Krzysztof Kozlowski @ 2026-04-13 8:59 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
J. Neuschäfer, linux-spi, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
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_RISING = 1 = GPIO_ACTIVE_LOW.
Correct the example DTS to use proper flags for chip select GPIOs,
assuming the author of the code wanted similar logical behavior:
IRQ_TYPE_EDGE_RISING => GPIO_ACTIVE_HIGH
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/spi/fsl,spi.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/fsl,spi.yaml b/Documentation/devicetree/bindings/spi/fsl,spi.yaml
index d74792fc9bf2..6a359488dd41 100644
--- a/Documentation/devicetree/bindings/spi/fsl,spi.yaml
+++ b/Documentation/devicetree/bindings/spi/fsl,spi.yaml
@@ -59,7 +59,7 @@ unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
spi@4c0 {
compatible = "fsl,spi";
@@ -67,8 +67,8 @@ examples:
cell-index = <0>;
interrupts = <82 0>;
mode = "cpu";
- cs-gpios = <&gpio 18 IRQ_TYPE_EDGE_RISING // device reg=<0>
- &gpio 19 IRQ_TYPE_EDGE_RISING>; // device reg=<1>
+ cs-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>, // device reg=<0>
+ <&gpio 19 GPIO_ACTIVE_HIGH>; // device reg=<1>
};
...
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 4/5] arm64: dts: qcom: sm6350: add LPASS LPI pin controller
From: Luca Weiss @ 2026-04-13 8:55 UTC (permalink / raw)
To: Konrad Dybcio, Luca Weiss, Dmitry Baryshkov
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, ~postmarketos/upstreaming,
phone-devel, linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <91812db8-9774-468e-8a8b-10699a63310c@oss.qualcomm.com>
Hi Konrad,
On Thu Jan 29, 2026 at 12:19 PM CET, Konrad Dybcio wrote:
> On 1/29/26 9:32 AM, Luca Weiss wrote:
>> On Wed Jan 28, 2026 at 11:16 PM CET, Dmitry Baryshkov wrote:
>>> On Wed, Jan 28, 2026 at 01:26:52PM +0100, Luca Weiss wrote:
>>>> Add LPASS LPI pinctrl node required for audio functionality on SM6350.
>>>>
>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/sm6350.dtsi | 66 ++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 66 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
>>>> index 9f9b9f9af0da..b1fb6c812da7 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
>>>> @@ -1448,6 +1448,72 @@ compute-cb@5 {
>>>> };
>>>> };
>>>>
>>>> + lpass_tlmm: pinctrl@33c0000 {
>>>> + compatible = "qcom,sm6350-lpass-lpi-pinctrl";
>>>> + reg = <0x0 0x033c0000 0x0 0x20000>,
>>>> + <0x0 0x03550000 0x0 0x10000>;
>>>> + gpio-controller;
>>>> + #gpio-cells = <2>;
>>>> + gpio-ranges = <&lpass_tlmm 0 0 15>;
>>>> +
>>>> + clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>>>> + <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
>>>> + clock-names = "core",
>>>> + "audio";
>>>> +
>>>> + i2s1_active: i2s1-active-state {
>>>> + clk-pins {
>>>> + pins = "gpio6";
>>>> + function = "i2s1_clk";
>>>> + drive-strength = <8>;
>>>> + bias-disable;
>>>> + output-high;
>>>
>>> This looks suspicious for the clock pin.
>>>
>>>> + };
>>>> +
>>>> + ws-pins {
>>>> + pins = "gpio7";
>>>> + function = "i2s1_ws";
>>>> + drive-strength = <8>;
>>>> + bias-disable;
>>>> + output-high;
>>>
>>> The same
>>>
>>>> + };
>>>> +
>>>> + data-pins {
>>>> + pins = "gpio8", "gpio9";
>>>> + function = "i2s1_data";
>>>> + drive-strength = <8>;
>>>> + bias-disable;
>>>> + output-high;
>>>
>>> And here.
>>
>> I've taken this pinctrl from downstream lagoon-lpi.dtsi. There the
>> active config for these pins have "output-high;" set.
>>
>> And fwiw this pinctrl works fine at runtime for driving the speaker.
>
> I tried to find an answer.
>
> A doc for this SoC says that i2s clock pins should be at output-low
> (2 mA) when muxed to the i2s_xxx function, with no information about
> bias settings (perhaps bias-disable), and in sleep they should be the
> same (minus the drive strength note, but 2mA is the lowest setting)
>
> I am further confused because the output-enable bit in the cfg
> register specifically says "when in GPIO mode"
Thanks for checking.
What should we do here now? Follow what you found in the docs, or follow
what downstream is doing (8ma output-high)?
https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-extra/devicetree/+/refs/heads/int/15/fp4/qcom/lagoon-lpi.dtsi#219
I think apart from this question, this patchset should be ready to land.
Regards
Luca
p.s. I also briefly checked Google's repositories (which is the only
known place to have a commit history with devicetree since the
devicetree was just shipped with vendor/qcom/proprietary for everybody
else, without history) but there there's also no hint whether there's
any specific reason they deviate.
https://android.googlesource.com/kernel/msm-extra/devicetree/+log/refs/tags/android-11.0.0_r0.56/qcom/lagoon-lpi.dtsi
^ permalink raw reply
* Re: [PATCH 2/2] pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
From: Uwe Kleine-König @ 2026-04-13 8:55 UTC (permalink / raw)
To: Xilin Wu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nikita Travkin,
linux-pwm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260406-clk-pwm-gpio-v1-2-40d2f3a20aff@radxa.com>
[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]
Hello,
On Mon, Apr 06, 2026 at 11:50:02PM +0800, Xilin Wu wrote:
> @@ -45,14 +54,36 @@ static int pwm_clk_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> u32 rate;
> u64 period = state->period;
> u64 duty_cycle = state->duty_cycle;
> + bool constant_level = false;
> + int gpio_value = 0;
>
> if (!state->enabled) {
> - if (pwm->state.enabled) {
> + constant_level = true;
> + gpio_value = 0;
> + } else if (state->duty_cycle == 0) {
> + constant_level = true;
> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 1 : 0;
> + } else if (state->duty_cycle >= state->period) {
> + constant_level = true;
> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 0 : 1;
> + }
> +
> + if (constant_level) {
> + if (pcchip->gpiod) {
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
> + gpiod_direction_output(pcchip->gpiod, gpio_value);
Please swap these two calls to reduce glitches.
> + }
> + if (pcchip->clk_enabled) {
> clk_disable(pcchip->clk);
> pcchip->clk_enabled = false;
> }
> return 0;
> - } else if (!pwm->state.enabled) {
> + }
> +
> + if (pcchip->gpiod)
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
> +
> + if (!pcchip->clk_enabled) {
> ret = clk_enable(pcchip->clk);
> if (ret)
> return ret;
> @@ -97,6 +128,35 @@ static int pwm_clk_probe(struct platform_device *pdev)
> return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->clk),
> "Failed to get clock\n");
>
> + pcchip->pinctrl = devm_pinctrl_get(&pdev->dev);
> + if (IS_ERR(pcchip->pinctrl)) {
> + ret = PTR_ERR(pcchip->pinctrl);
> + pcchip->pinctrl = NULL;
> + if (ret == -EPROBE_DEFER)
> + return ret;
I think you want to return all failures of devm_pinctrl_get() to the
caller.
> + } else {
> + pcchip->pins_default = pinctrl_lookup_state(pcchip->pinctrl,
> + PINCTRL_STATE_DEFAULT);
> + pcchip->pins_gpio = pinctrl_lookup_state(pcchip->pinctrl,
> + "gpio");
> + if (IS_ERR(pcchip->pins_default) || IS_ERR(pcchip->pins_gpio))
> + pcchip->pinctrl = NULL;
> + }
> +
> + /*
> + * Switch to GPIO pinctrl state before requesting the GPIO.
> + * The driver core has already applied the "default" state, which
> + * muxes the pin to the clock function and claims it. We must
> + * release that claim first so that gpiolib can request the pin.
> + */
> + if (pcchip->pinctrl)
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
Why is this needed? Ideally the probe function doesn't interrupt an
already setup output.
> + pcchip->gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, GPIOD_ASIS);
> + if (IS_ERR(pcchip->gpiod))
> + return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
> + "Failed to get gpio\n");
> +
> chip->ops = &pwm_clk_ops;
>
> ret = pwmchip_add(chip);
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PING] Re: [PATCH v7 0/2] arm64: dts/defconfig: enable BST C1200 eMMC
From: Albert Yang @ 2026-04-13 8:34 UTC (permalink / raw)
To: krzk, arnd
Cc: krzk+dt, robh, conor+dt, gordon.ge, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel, yangzh0906
In-Reply-To: <20260310091211.4171307-1-yangzh0906@thundersoft.com>
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/
This series only contains the remaining DTS + defconfig parts for BST C1200 eMMC:
- 1/2 arm64: dts: bst: enable eMMC controller in C1200 CDCU1.0 board
- 2/2 arm64: defconfig: enable BST SDHCI controller
The MMC driver-side patches were already applied in mmc-next, so this series is for
arm64/DT review and merge path.
No functional code changes since v7. If preferred, I can send a rebase/refresh (v8)
on top of current mainline immediately.
Could you please help review and let me know if any changes are still needed?
Thanks for your time.
Best regards,
Albert
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: clk-pwm: add optional GPIO and pinctrl properties
From: Xilin Wu @ 2026-04-13 8:45 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nikita Travkin,
linux-pwm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <adyr_17yvFGkihU5@monoceros>
On 4/13/2026 4:41 PM, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Apr 06, 2026 at 11:50:01PM +0800, Xilin Wu wrote:
>> The clk-pwm driver cannot produce constant output levels (0% or 100%
>> duty cycle, or disabled state) through the clock hardware alone - the
>> actual pin level when the clock is off is undefined and
>> hardware-dependent.
>>
>> Document optional gpios, pinctrl-names, pinctrl-0, and pinctrl-1
>> properties that allow the driver to switch the pin between clock
>> function mux (for normal PWM output) and GPIO mode (to drive a
>> deterministic constant level).
>>
>> Signed-off-by: Xilin Wu <sophon@radxa.com>
>> ---
>> Documentation/devicetree/bindings/pwm/clk-pwm.yaml | 36 +++++++++++++++++++++-
>> 1 file changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>> index ec1768291503..2a0e3e02d27b 100644
>> --- a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>> +++ b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>> @@ -15,6 +15,11 @@ description: |
>> It's often possible to control duty-cycle of such clocks which makes them
>> suitable for generating PWM signal.
>>
>> + Optionally, a GPIO and pinctrl states can be provided. When a constant
>> + output level is needed (0%, 100%, or disabled), the pin is switched to
>
> A constant output isn't needed when disabled. The state is undefined
> then. A plain clk_disable() is fine then.
>
> Best regards
> Uwe
Ack. I will change the binding description and the driver behavior in
the next revision.
Thank you for the review.
--
Best regards,
Xilin Wu <sophon@radxa.com>
^ 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