* Re: [PATCH] arm64: dts: qcom: sc8280xp: Add ADSP FastRPC node
From: Konrad Dybcio @ 2026-04-07 11:23 UTC (permalink / raw)
To: Pengyu Luo, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Srinivas Kandagatla,
Ekansh Gupta
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <66e25445-e7f8-405e-b208-e69b6b401f90@oss.qualcomm.com>
On 4/7/26 1:22 PM, Konrad Dybcio wrote:
> On 4/3/26 2:07 PM, Pengyu Luo wrote:
>> Add the FastRPC node to enable offloading compute tasks to the ADSP
>> via the FastRPC framework.
>>
>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
>> ---
>> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 27 ++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> index 761f229e8f47..ee02acd18856 100644
>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> @@ -2966,6 +2966,33 @@ IPCC_MPROC_SIGNAL_GLINK_QMP
>> label = "lpass";
>> qcom,remote-pid = <2>;
>>
>> + fastrpc {
>> + compatible = "qcom,fastrpc";
>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>> + label = "adsp";
>> + qcom,non-secure-domain;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + compute-cb@3 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <3>;
>> + iommus = <&apps_smmu 0x0c03 0x0>;
>
> These are SIDs destined for the CDSP.. (how) have you tested this
> patch?
>
> +Srini, Ekansh I can't quite decode which SIDs are "allowed" for FastRPC
> on Hamoa's ADSP.. could you please help here?
As I hit enter, I noticed this is indeed not hamoa and these numbers
were just coincidental..
The patch is alright
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v5 2/3] arm64: dts: qcom: lemans-ride: Enable mdss1 display Port
From: Konrad Dybcio @ 2026-04-07 11:25 UTC (permalink / raw)
To: Mani Chandana Ballary Kuntumalla, dmitry.baryshkov,
marijn.suijten, swboyd, mripard, abel.vesa, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, jessica.zhang,
abhinav.kumar, sean, airlied, simona, alex.vinarskis
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
freedreno, dri-devel, quic_rajeevny, quic_vproddut, quic_riteshk
In-Reply-To: <20260402095003.3758176-3-quic_mkuntuma@quicinc.com>
On 4/2/26 11:50 AM, Mani Chandana Ballary Kuntumalla wrote:
> This change enables DP controllers, DPTX0 and DPTX1 alongside
> their corresponding PHYs of mdss1 which corresponds to edp2
> and edp3.
>
> Signed-off-by: Mani Chandana Ballary Kuntumalla <quic_mkuntuma@quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64: dts: qcom: lemans-evk-ifp-mezzanine: Enable mdss1 display Port
From: Konrad Dybcio @ 2026-04-07 11:26 UTC (permalink / raw)
To: Mani Chandana Ballary Kuntumalla, dmitry.baryshkov,
marijn.suijten, swboyd, mripard, abel.vesa, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, jessica.zhang,
abhinav.kumar, sean, airlied, simona, alex.vinarskis
Cc: Vishnu Saini, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, freedreno, dri-devel, quic_rajeevny,
quic_vproddut, quic_riteshk
In-Reply-To: <20260402095003.3758176-4-quic_mkuntuma@quicinc.com>
On 4/2/26 11:50 AM, Mani Chandana Ballary Kuntumalla wrote:
> From: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
>
> Enable DP controllers, DPTX0 and DPTX1 alongside
> their corresponding PHYs of mdss1 which corresponds to eDP2
> and eDP3.
>
> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
> Signed-off-by: Mani Chandana Ballary Kuntumalla <quic_mkuntuma@quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: kodiak: Add iface clock for ice sdhc
From: Kuldeep Singh @ 2026-04-07 11:26 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <a940926f-901d-4907-b029-e4c6fc62625f@oss.qualcomm.com>
On 4/7/2026 4:48 PM, Konrad Dybcio wrote:
> On 4/7/26 1:09 PM, Kuldeep Singh wrote:
>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> index dda4697a61b7..5e6b659e8719 100644
>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> @@ -1082,7 +1082,8 @@ sdhc_ice: crypto@7c8000 {
>>>> compatible = "qcom,sc7280-inline-crypto-engine",
>>>> "qcom,inline-crypto-engine";
>>>> reg = <0x0 0x007c8000 0x0 0x18000>;
>>>> - clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
>>>> + clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
>>>> + clock-names = "core", "iface";
>>>
>>> nit: one a line would be preferred, please fix that up as you seemingly
>>> need a v2 anyway
>>
>> Hi Konrad, Didn't get your comment completely.
>>
>> Do I need to send v2 to just fix clock entries in 2 lines?
>> Or some other comment to address and send v2 for that?
>> I don't see any other comment on patchset to address.
>
> I didn't see your reply to Dmitry's initial comment about the DT bindings
> requiring an update.
Here's my reply to Dmitry's comment.
https://lore.kernel.org/linux-arm-msm/f05ac643-1ec4-4700-aace-c1a9d0cd9e07@oss.qualcomm.com/
Bindings are updated with maxItems:2 in dependent patch series.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH 2/2] mmc: cqe: Add CQE support for cadence mmc driver
From: Krzysztof Kozlowski @ 2026-04-07 11:30 UTC (permalink / raw)
To: rohan1sj, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Masahiro Yamada, Adrian Hunter
Cc: linux-mmc, devicetree, linux-kernel, Milind Parab,
Swapnil Jakhade, Manikandan Pillai
In-Reply-To: <20260407-cdns_sdhci_cqe-support-v1-2-13efc0810631@cadence.com>
On 07/04/2026 13:18, rohan1sj via B4 Relay wrote:
> +static int sdhci_cdns_cqe_add_host(struct sdhci_host *host, struct platform_device *pdev)
> +{
> + struct cqhci_host *cq_host;
> + bool dma64;
> + int ret;
> +
> + /* setup SDHCI host first */
> + ret = sdhci_setup_host(host);
> +
> + if (ret)
> + return ret;
> +
> + /* Init CQE */
> + cq_host = cqhci_pltfm_init(pdev);
> + if (IS_ERR(cq_host)) {
> + ret = PTR_ERR(cq_host);
> + goto cleanup;
> + }
> +
> + dma64 = host->flags & SDHCI_USE_64_BIT_DMA;
> + if (dma64)
> + cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
> +
> + cq_host->ops = &sdhci_cdns_cqhci_ops;
> +
> + host->mmc->caps2 |= MMC_CAP2_CQE | MMC_CAP2_CQE_DCMD;
> +
> + /* Finally initialize CQHCI */
> + ret = cqhci_init(cq_host, host->mmc, dma64);
> + if (ret) {
> + dev_err(mmc_dev(host->mmc), "Failed to initialize CQHCI: %d\n", ret);
So here error msg
> + goto cleanup;
> + }
> +
> + /* add host to MMC subsystem */
> + ret = __sdhci_add_host(host);
> + if (ret)
> + goto cleanup;
> +
> + dev_info(mmc_dev(host->mmc), "CQE init: success\n");
dev_dbg
This does not look like useful printk message. Drivers should be silent
on success:
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/coding-style.rst#L913
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/debugging/driver_development_debugging_guide.rst#L79
> + return 0;
> +
> +cleanup:
> + dev_err(mmc_dev(host->mmc), "CQE init: failed for %s\n", mmc_hostname(host->mmc));
And here also error message. Why twice?
And if it is probe path, why aren't you using dev_err_probe()?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] mmc: cqe: Add CQE DT support for cadence controller
From: Krzysztof Kozlowski @ 2026-04-07 11:30 UTC (permalink / raw)
To: rohan1sj, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Masahiro Yamada, Adrian Hunter
Cc: linux-mmc, devicetree, linux-kernel, Milind Parab,
Swapnil Jakhade, Manikandan Pillai
In-Reply-To: <20260407-cdns_sdhci_cqe-support-v1-1-13efc0810631@cadence.com>
On 07/04/2026 13:18, rohan1sj via B4 Relay wrote:
> From: rohan1sj <rohan1sj@cadence.com>
>
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
> Add DT config required to support CQE as present in
> cadence eMMC host controller
What is DT config?
Which devices? Say something useful here.
>
> Signed-off-by: rohan1sj <rohan1sj@cadence.com>
Please use known identity.
> ---
> .../devicetree/bindings/mmc/cdns,sdhci.yaml | 32 +++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> index ac75d694611a..c0d8aefe20c2 100644
> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> @@ -24,6 +24,10 @@ properties:
> minItems: 1
> maxItems: 2
>
> + reg-names:
> + minItems: 1
> + maxItems: 2
List would have to be here.
> +
> interrupts:
> maxItems: 1
>
> @@ -139,7 +143,19 @@ allOf:
> else:
> properties:
> reg:
> - maxItems: 1
> + oneOf:
> + - items:
> + - description: Host controller registers
> + - items:
> + - description: Host controller registers
> + - description: CQE (Command Queue Engine) registers
So just one list with minItems
> + reg-names:
> + oneOf:
> + - items:
> + - const: sdhci
> + - items:
> + - const: sdhci
core
> + - const: cqhci
cqe
Anyway, reg-names here are pointless. They should be in top-level.
You also need to disallow the reg-names for Pensando, because it has
completely different.
>
> unevaluatedProperties: false
>
> @@ -156,3 +172,17 @@ examples:
> mmc-hs400-1_8v;
> cdns,phy-dll-delay-sdclk = <0>;
> };
> +
> + - |
> + emmc_cqe: mmc@5b000000 {
> + compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
> + reg = <0x5b000000 0x400>, <0x5b000400 0x060>;
No need for new example. Just correct existing one.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
From: Konrad Dybcio @ 2026-04-07 11:37 UTC (permalink / raw)
To: Krishna Kurapati, Aiqun(Maria) Yu, Jingyi Wang
Cc: linux-arm-msm, devicetree, Konrad Dybcio, Bjorn Andersson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
Ronak Raheja, Jingyi Wang
In-Reply-To: <3a415fae-bafc-4e23-bfca-564bff90cf2d@oss.qualcomm.com>
On 4/6/26 7:52 PM, Krishna Kurapati wrote:
>
>
> On 3/30/2026 2:48 PM, Konrad Dybcio wrote:
>> On 3/29/26 7:52 PM, Krishna Kurapati wrote:
>>> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>>>
>>> Add the base USB devicetree definitions for Kaanapali platform. The overall
>>> chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
>>> (rev. v8) and M31 eUSB2 PHY.
>>>
>>> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> + usb: usb@a600000 {
>>> + compatible = "qcom,kaanapali-dwc3", "qcom,snps-dwc3";
>>> + reg = <0x0 0x0a600000 0x0 0xfc100>;
>>
>> Following the woes on Hamoa, can the platform suspend and wake up
>> succesfully with the flattened DT node?
>>
>
> There is a crash on resume when I tested but it comes up even without my changes:
>
> [ 65.263890] Call trace:
> [ 65.266489] kthreads_update_affinity+0x94/0x158 (P)
> [ 65.271664] kthreads_online_cpu+0x14/0x84
> [ 65.275951] cpuhp_invoke_callback+0xdc/0x1dc
> [ 65.280514] cpuhp_thread_fun+0x11c/0x168
> [ 65.284717] smpboot_thread_fn+0x1e4/0x24c
> [ 65.289019] kthread+0x104/0x124
> [ 65.292411] ret_from_fork+0x10/0x20
> [ 65.296156] Code: f94002f7 eb1602ff 540003a0 f85f82e8 (b9402d09)
> [ 65.302490] ---[ end trace 0000000000000000 ]---
>
> Hence I believe my changes are not causing any crash.
Oh.. that's.. not good.. I was hoping someone tested that..
+Maria, Jingyi for awareness
Konrad
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Joe Sandom @ 2026-04-07 11:39 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: <ehlhjfzekjnscro4ffydjhzfuiqhfkuyuxrk42x53cturzi4do@74y5k5ee6bv7>
On Sun, Apr 05, 2026 at 12:20:23AM +0300, Dmitry Baryshkov wrote:
> On Sat, Apr 04, 2026 at 10:50:58AM +0100, Joe Sandom via B4 Relay wrote:
> > From: Joe Sandom <jsandom@axon.com>
> >
> > 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!1fgy0ADknA_DP0VqDvEXe9TuFrmdabqHK1RDt53uY9WoeXsV1Bm8UJUetOp2eUzEDZ-FiipcbKzEafTxbNkQjsehrU6oWw$
> > [2] https://urldefense.com/v3/__https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit__;!!K76kBA!1fgy0ADknA_DP0VqDvEXe9TuFrmdabqHK1RDt53uY9WoeXsV1Bm8UJUetOp2eUzEDZ-FiipcbKzEafTxbNkQjsftljQwig$
> >
> > Signed-off-by: Joe Sandom <jsandom@axon.com>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts | 1610 ++++++++++++++++++++++++++
> > 2 files changed, 1611 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index 4ba8e73064194926096b98b9556a3207e8f24d72..f8c65771f76629d7fafee15ac8d7bb62cd24a20f 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -184,6 +184,7 @@ qcs8300-ride-el2-dtbs := qcs8300-ride.dtb monaco-el2.dtbo
> >
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride-el2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs8550-rb5gen2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> >
> > diff --git a/arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts b/arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..280fbd3a09997e3e2613498e25ac188680484cc4
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts
> > @@ -0,0 +1,1610 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2026 Axon Enterprise, Inc.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/leds/common.h>
> > +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> > +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> > +#include "qcs8550.dtsi"
> > +#include "pm8010.dtsi"
> > +#include "pm8550.dtsi"
> > +#include "pm8550b.dtsi"
> > +#define PMK8550VE_SID 5
> > +#include "pm8550ve.dtsi"
> > +#include "pm8550vs.dtsi"
> > +#include "pmk8550.dtsi"
> > +#include "pmr735d_a.dtsi"
> > +#include "pmr735d_b.dtsi"
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. QCS8550 RB5Gen2";
> > + compatible = "qcom,qcs8550-rb5gen2", "qcom,qcs8550", "qcom,sm8550";
> > + chassis-type = "embedded";
> > +
> > + aliases {
> > + serial0 = &uart7;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + clocks {
> > + clk40m: can-clk {
> > + compatible = "fixed-clock";
> > + clock-frequency = <40000000>;
> > + #clock-cells = <0>;
> > + };
> > + };
> > +
> > + gpio-keys {
> > + compatible = "gpio-keys";
> > +
> > + pinctrl-0 = <&volume_up_n>;
> > + pinctrl-names = "default";
> > +
> > + key-volume-up {
> > + label = "Volume Up";
> > + linux,code = <KEY_VOLUMEUP>;
> > + gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
> > + debounce-interval = <15>;
> > + linux,can-disable;
> > + wakeup-source;
> > + };
> > + };
> > +
> > + hdmi-connector {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con: endpoint {
> > + remote-endpoint = <<9611_out>;
> > + };
> > + };
> > + };
> > +
> > + /* Lontium LT9611UXC fails FW upgrade and has timeouts with geni-i2c */
> > + /* Workaround is to use bit-banged I2C */
> > + i2c_hub_3_gpio: i2c {
> > + compatible = "i2c-gpio";
> > +
> > + sda-gpios = <&tlmm 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > + scl-gpios = <&tlmm 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + led-0 {
> > + label = "green:status-3";
> > + function = LED_FUNCTION_STATUS;
> > + color = <LED_COLOR_ID_GREEN>;
> > + gpios = <&pm8550_gpios 2 GPIO_ACTIVE_HIGH>;
> > + default-state = "off";
> > + };
> > +
> > + led-1 {
> > + label = "blue:bt-power";
> > + function = LED_FUNCTION_BLUETOOTH;
> > + color = <LED_COLOR_ID_BLUE>;
> > + gpios = <&pm8550b_gpios 7 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "bluetooth-power";
> > + default-state = "off";
> > + };
> > +
> > + led-2 {
> > + label = "yellow:wlan";
> > + function = LED_FUNCTION_WLAN;
> > + color = <LED_COLOR_ID_YELLOW>;
> > + gpios = <&pm8550b_gpios 9 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "phy0tx";
> > + default-state = "off";
> > + };
> > + };
> > +
> > + lt9611_1v2: lt9611-regulator-1v2 {
> > + 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";
> > + };
> > +
> > + upd_reset: regulator-upd-reset {
> > + compatible = "regulator-fixed";
> > + regulator-name = "UPD_RESET";
>
> Reset usually isn't a regulator.
Ack.
>
> > + gpio = <&tlmm 182 GPIO_ACTIVE_HIGH>;
> > + vin-supply = <&pcie_upd_3p3>;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + enable-active-high;
> > + regulator-enable-ramp-delay = <10000>;
> > + regulator-boot-on;
> > + regulator-always-on;
>
> Especially since it's not controlled.
Fair point. Will address this in v2
>
> > + pinctrl-0 = <&upd_ponrst>;
> > + pinctrl-names = "default";
> > + };
> > +
> > + usbhub_reset: regulator-usbhub-reset {
> > + compatible = "regulator-fixed";
> > + regulator-name = "USBHUB_RESET";
>
> Same here.
This will be removed entirely in v2. Checking the schematic again,
this is not actually needed
>
> > + gpio = <&tlmm 41 GPIO_ACTIVE_LOW>;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + startup-delay-us = <1500>;
> > + off-on-delay-us = <1500>;
> > + pinctrl-0 = <&usbhub_rst>;
> > + 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 {
> > + 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>;
> > + };
> > + };
> > + };
> > +
> > + wcn7850-pmu {
> > + compatible = "qcom,wcn7850-pmu";
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&wlan_en>, <&bt_default>, <&pmk8550_sleep_clk>;
>
> swctrl?
Bundled into bt_default since it's tied to BT
>
> > +
> > + wlan-enable-gpios = <&tlmm 80 GPIO_ACTIVE_HIGH>;
> > + bt-enable-gpios = <&tlmm 81 GPIO_ACTIVE_HIGH>;
>
> swctrl?
Thanks. Will add this in v2.
>
> > +
> > + vdd-supply = <&vreg_s5g_0p85>;
> > + vddio-supply = <&vreg_l15b_1p8>;
> > + vddaon-supply = <&vreg_s2g_0p852>;
> > + vdddig-supply = <&vreg_s4e_0p95>;
> > + vddrfa1p2-supply = <&vreg_s4g_1p25>;
> > + vddrfa1p8-supply = <&vreg_s6g_1p86>;
>
> [...]
>
> > +
> > +&gpi_dma1 {
> > + status = "okay";
> > +};
> > +
> > +&gpi_dma2 {
> > + status = "okay";
> > +};
> > +
> > +&gpu {
> > + status = "okay";
> > +};
> > +
> > +&gpu_zap_shader {
> > + firmware-name = "qcom/qcs8550/a740_zap.mbn";
> > +};
> > +
> > +&i2c_hub_2 {
> > + clock-frequency = <100000>;
> > +
> > + status = "okay";
> > +
> > + typec-mux@1c {
> > + compatible = "onnn,nb7vpq904m";
> > + reg = <0x1c>;
> > +
> > + vcc-supply = <&vreg_l15b_1p8>;
> > +
> > + retimer-switch;
> > + orientation-switch;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + redriver_usb_con_ss: endpoint {
> > + remote-endpoint = <&pmic_glink_ss_in>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + redriver_phy_con_ss: endpoint {
> > + remote-endpoint = <&usb_dp_qmpphy_out>;
> > + data-lanes = <0 1 2 3>;
> > + };
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > +
> > + redriver_usb_con_sbu: endpoint {
> > + remote-endpoint = <&pmic_glink_sbu_in>;
> > + };
> > + };
> > + };
> > + };
> > +};
> > +
> > +&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-names = "default";
> > + pinctrl-0 = <<9611_irq_pin <9611_rst_pin>;
> > +
> > + 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>;
> > + };
> > + };
> > + };
> > + };
> > +};
> > +
> > +&i2c_hub_4 {
> > + status = "okay";
> > +};
> > +
> > +&i2c_master_hub_0 {
> > + status = "okay";
> > +};
> > +
> > +&ipa {
> > + qcom,gsi-loader = "self";
> > + memory-region = <&ipa_fw_mem>;
>
> These two should be a part of sm8550.dtsi
Ack. Will put this in a separate commit and also tidy up hdk/qrd.
>
> > + firmware-name = "qcom/qcs8550/ipa_fws.mbn";
> > +
> > + status = "okay";
> > +};
> > +
> > +&iris {
> > + status = "okay";
> > +};
> > +
> > +&lpass_vamacro {
> > + pinctrl-0 = <&dmic01_default>;
> > + pinctrl-names = "default";
> > +
> > + qcom,dmic-sample-rate = <4800000>;
> > +
> > + vdd-micb-supply = <&vreg_l15b_1p8>;
> > +};
> > +
> > +&mdss {
> > + status = "okay";
> > +};
> > +
> > +&mdss_dsi0 {
> > + vdda-supply = <&vreg_l3e_1p2>;
> > +
> > + status = "okay";
> > +};
> > +
> > +&mdss_dsi0_out {
> > + remote-endpoint = <<9611_a>;
> > + data-lanes = <0 1 2 3>;
> > +};
> > +
> > +&mdss_dsi0_phy {
> > + vdds-supply = <&vreg_l1e_0p88>;
> > +
> > + status = "okay";
> > +};
> > +
> > +&mdss_dp0 {
> > + status = "okay";
> > +};
> > +
> > +&pcie0 {
> > + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> > + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> > +
> > + pinctrl-0 = <&pcie0_default_state>;
> > + pinctrl-names = "default";
> > +
> > + iommu-map = <0x0 &apps_smmu 0x1400 0x1>,
> > + <0x100 &apps_smmu 0x1401 0x1>,
> > + <0x208 &apps_smmu 0x1402 0x1>,
> > + <0x210 &apps_smmu 0x1403 0x1>,
> > + <0x218 &apps_smmu 0x1404 0x1>,
> > + <0x300 &apps_smmu 0x1407 0x1>,
> > + <0x400 &apps_smmu 0x1408 0x1>,
> > + <0x500 &apps_smmu 0x140c 0x1>,
> > + <0x501 &apps_smmu 0x140e 0x1>;
> > +
> > + /delete-property/ msi-map;
>
> Why?
I tried extending the msi-map to cover the RIDs from the QPS615
PCIe switch (matching the iommu-map entries), but this caused
ITS MAPD command timeouts. From what I could gather, deleting
msi-map forces the PCIe controller to fall back to the internal
iMSI-RX module, where this worked properly.
For reference, I checked the RB3gen2 since it also uses a QPS615
and there doesn't seem to be any msi-map defined (in kodiak.dtsi).
Any recommendations to resolve this properly?
>
> > +
> > + status = "okay";
> > +};
> > +
> [...]
> > +
> > +&pcie1 {
> > + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
> > + perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
> > +
> > + pinctrl-0 = <&pcie1_default_state>;
> > + pinctrl-names = "default";
> > +
> > + iommu-map = <0x0 &apps_smmu 0x1480 0x1>,
> > + <0x100 &apps_smmu 0x1481 0x1>,
> > + <0x208 &apps_smmu 0x1482 0x1>,
> > + <0x210 &apps_smmu 0x1483 0x1>,
> > + <0x218 &apps_smmu 0x1484 0x1>,
> > + <0x300 &apps_smmu 0x1487 0x1>,
> > + <0x400 &apps_smmu 0x1488 0x1>,
> > + <0x500 &apps_smmu 0x148c 0x1>,
> > + <0x501 &apps_smmu 0x148e 0x1>;
> > +
> > + /delete-property/ msi-map;
>
> Why?
Same as above, for the RB5gen2, both PCIE0 and PCIE1 have QPS615
PCIE switches.
>
> > +
> > + status = "okay";
> > +};
> > +
> > +&pcie1_phy {
> > + vdda-phy-supply = <&vreg_l3c_0p9>;
> > + vdda-pll-supply = <&vreg_l3e_1p2>;
> > + vdda-qref-supply = <&vreg_l1e_0p88>;
> > +
> > + status = "okay";
> > +};
> > +
>
> [...]
>
> > +
> > +&remoteproc_adsp {
> > + firmware-name = "qcom/qcs8550/adsp.mdt",
> > + "qcom/qcs8550/adsp_dtb.mdt";
>
> MBN, please align vertically on the quote mark. The same for CDSP and
> modem.
Ack. Will correct this for v2.
>
>
> > + status = "okay";
> > +};
> > +
> > +&remoteproc_cdsp {
> > + firmware-name = "qcom/qcs8550/cdsp.mdt",
> > + "qcom/qcs8550/cdsp_dtb.mdt";
> > + status = "okay";
> > +};
> > +
> > +&remoteproc_mpss {
> > + firmware-name = "qcom/qcs8550/modem.mdt",
> > + "qcom/qcs8550/modem_dtb.mdt";
> > + status = "okay";
> > +};
> > +
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* [PATCH] dt-binding: leds: publish common bindings under dual license
From: Corvin Köhne @ 2026-04-07 11:39 UTC (permalink / raw)
To: linux-kernel
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, open list:LED SUBSYSTEM, Krzysztof Kozlowski,
Conor Dooley, Pavel Machek, Lee Jones, Corvin Köhne,
Ashley Towns, Dan Murphy, Gergo Koteles, Greg Kroah-Hartman,
INAGAKI Hiroshi, Jacek Anaszewski, Jacek Anaszewski,
Linus Torvalds, Olliver Schinagl, Pavel Machek,
Rafał Miłecki, Roderick Colenbrander
From: Corvin Köhne <c.koehne@beckhoff.com>
Changes leds/common.h DT binding header file to be published under GPLv2
or BSD-2-Clause license terms. This change allows this common LED
bindings header file to be used in software components as bootloaders
and OSes that are not published under GPLv2 terms.
All contributors to leds/common.h file in copy.
Cc: Ashley Towns <mail@ashleytowns.id.au>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Gergo Koteles <soyer@irl.hu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: INAGAKI Hiroshi <musashino.open@gmail.com>
Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Olliver Schinagl <oliver@schinagl.nl>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Rafał Miłecki <rafal@milecki.pl>
Cc: Roderick Colenbrander <roderick@gaikai.com>
Cc: Lee Jones <lee@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: linux-leds@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
---
include/dt-bindings/leds/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
index 4f017bea0123..b7bafbaf7df3 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) */
/*
* This header provides macros for the common LEDs device tree bindings.
*
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3] Add remoteproc PAS loader for SoCCP on Glymur DT
From: Konrad Dybcio @ 2026-04-07 11:41 UTC (permalink / raw)
To: Ananthu C V, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Sibi Sankar
In-Reply-To: <20260403-glymur-soccp-v3-1-f0e8d57f11ba@oss.qualcomm.com>
On 4/3/26 1:39 PM, Ananthu C V wrote:
> From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Co-developed-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> ---
[...]
> + remoteproc_soccp: remoteproc-soccp@d00000 {
remoteproc-soccp@ ->remoteproc@
> + compatible = "qcom,glymur-soccp-pas", "qcom,kaanapali-soccp-pas";
> + reg = <0x0 0x00d00000 0x0 0x200000>;
> +
> + interrupts-extended = <&intc GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 9 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "wdog",
> + "fatal",
> + "ready",
> + "handover",
> + "stop-ack",
> + "pong";
> +
> + clocks = <&rpmhcc RPMH_CXO_CLK>;
> + clock-names = "xo";
> +
> + power-domains = <&rpmhpd RPMHPD_CX>,
> + <&rpmhpd RPMHPD_MX>;
> + power-domain-names = "cx",
> + "mx";
> +
> + memory-region = <&soccp_mem>,
> + <&soccpdtb_mem>;
> +
> + qcom,smem-states = <&soccp_smp2p_out 0>,
> + <&soccp_smp2p_out 8>;
> + qcom,smem-state-names = "stop",
> + "ping";
> +
> + status = "disabled";
Let's drop this line, no one should desire to run a system without SoCCP
> +
> + glink-edge {
> + interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
> + IPCC_MPROC_SIGNAL_GLINK_QMP
> + IRQ_TYPE_EDGE_RISING>;
> + mboxes = <&ipcc IPCC_MPROC_SOCCP
> + IPCC_MPROC_SIGNAL_GLINK_QMP>;
> + qcom,remote-pid = <19>;
> + label = "soccp";
> +
> + };
Stray \n above
Konrad
^ permalink raw reply
* Re: [RFC PATCH 09/15] Introduce structured tag value definition
From: Herve Codina @ 2026-04-07 11:42 UTC (permalink / raw)
To: Luca Ceresoli
Cc: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <DHHWXWJD78XO.5RNDZHYZE0U4@bootlin.com>
Hi Luca,
On Wed, 01 Apr 2026 17:11:35 +0200
"Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
> On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> > The goal of structured tag values is to ease the introduction of new
> > tags in future releases with the capability for an already existing
> > release to ignore those structured tags. In order to do that data length
> > related to the unknown tag needs to be identify.
> ^
> identified
Will be fixed in the next iteration.
>
> > Also a flag is present
> "Also add a flag"
Will be updated in the next iteration.
>
> > to tell an old release if this tag can be simply skipped or must lead to
> > an error.
> >
> > Structured tag value is defined on 32bit and is defined as follow:
> >
> > Bits | 31 | 30 | 29 28 | 27 0|
> > ------+----+----------+-------------------+--------+
> > Fields| 1 | CAN_SKIP | DATA_LNG_ENCODING | TAG_ID |
> > ------+----+----------+-------------------+--------+
> >
> > Bit 31 is always set to 1 to identified a structured tag value.
> ^
> identify
>
> > Bit 30 (CAN_SKIP) is set to 1 if the tag can be safely ignore when its
> ^
> ignored
Both will be fixed in the next iteration.
>
>
> > TAG_ID value is not a known value (unknown tag). If the CAN_SKIP bit is
> > set to 0 this tag must not be ignored and an error should be reported
> > when its TAG_ID value is not a known value (unknown tag).
> >
> > Bits 29..28 (DATA_LNG_ENCODING) indicates the length of the data related
>
> I think "LEN" is more common than "LNG".
Agree, will be changed.
...
> >
> > +/* Tag values flags */
> > +#define FDT_TAG_STRUCTURED (1<<31)
> > +#define FDT_TAG_SKIP_SAFE (1<<30)
>
> This is called CAN_SKIP in the commit message and SKIP_SAFE here. Using a
> consistent name would be better IMO.
I will use SKIP_SAFE and so update the commit message accordingly in the next
iteration.
>
> > +#define FDT_TAG_DATA_MASK (3<<28)
> > +#define FDT_TAG_DATA_NONE (0<<28)
> > +#define FDT_TAG_DATA_1CELL (1<<28)
> > +#define FDT_TAG_DATA_2CELLS (2<<28)
> > +#define FDT_TAG_DATA_LNG (3<<28)
>
> I find _LNG (or _LEN) misleading: this is not the length, but rather an
> enum value telling you the length is stored in the next cell. What about
> FDT_TAG_DATA_VARLEN?
Yes indeed, VARLEN is better.
I will use FDT_TAG_DATA_VARLEN in the next iteration.
Best regards,
Hervé
^ permalink raw reply
* [PATCH v4 0/5] J722S SGMII support
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW and SERDES are very similar to the variants found on the
AM64, but they additionally support SGMII. Introduce new compatible
strings for the J722S to add this support to the drivers.
This is a prerequisite for the Single-Pair Ethernet interface of the
TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
submitted separately.
For SGMII to actually work on the J722S, the am65-cpsw needs to be extended
as well, which has been submitted for net-next:
https://patchwork.kernel.org/project/netdevbpf/list/?series=1078111
Fallback compatible strings allow for the patches to be applied in any
order and to go through different trees without breaking existing
functionality.
v4:
- remove redundant items: level from DT binding YAMLs
v3:
- Drop am65-cpsw changes from this series, they need to go through net-next
- Fix missing PHY_GMII_SEL_RGMII_ID_MODE and PHY_GMII_SEL_FIXED_TX_DELAY in
gmii-sel driver for RGMII delay mode configuration
v2:
- Keep support for the AM64 compatible strings as a fallback, adjust commit
messages
- Drop reference to AM64_CPSW_QUIRK_CUT_THRU flag, which only exists in the
TI vendor kernel
Nora Schiffer (5):
dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel
compatible
phy: ti: phy-j721e-wiz: add support for J722S SoC family
phy: ti: gmii-sel: add support for J722S SoC family
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel
and CPSW3G
.../bindings/phy/ti,phy-gmii-sel.yaml | 23 +++++++++++-------
.../bindings/phy/ti,phy-j721e-wiz.yaml | 19 +++++++++------
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++--
drivers/phy/ti/phy-gmii-sel.c | 13 ++++++++++
drivers/phy/ti/phy-j721e-wiz.c | 24 +++++++++++++++++++
5 files changed, 73 insertions(+), 18 deletions(-)
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* [PATCH v4 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-gmii-sel.yaml | 23 +++++++++++--------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
index be41b4547ec6d..60b644a4c6390 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
@@ -47,15 +47,20 @@ description: |
properties:
compatible:
- enum:
- - ti,am3352-phy-gmii-sel
- - ti,dra7xx-phy-gmii-sel
- - ti,am43xx-phy-gmii-sel
- - ti,dm814-phy-gmii-sel
- - ti,am654-phy-gmii-sel
- - ti,j7200-cpsw5g-phy-gmii-sel
- - ti,j721e-cpsw9g-phy-gmii-sel
- - ti,j784s4-cpsw9g-phy-gmii-sel
+ oneOf:
+ - enum:
+ - ti,am3352-phy-gmii-sel
+ - ti,dra7xx-phy-gmii-sel
+ - ti,am43xx-phy-gmii-sel
+ - ti,dm814-phy-gmii-sel
+ - ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ - items:
+ - enum:
+ - ti,j722s-phy-gmii-sel
+ - const: ti,am654-phy-gmii-sel
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 3/5] phy: ti: phy-j721e-wiz: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 6b584706b913a..7531a8a049123 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -331,6 +331,7 @@ enum wiz_type {
J721E_WIZ_16G,
J721E_WIZ_10G, /* Also for J7200 SR1.0 */
AM64_WIZ_10G,
+ J722S_WIZ_10G,
J7200_WIZ_10G, /* J7200 SR2.0 */
J784S4_WIZ_10G,
J721S2_WIZ_10G,
@@ -1020,6 +1021,7 @@ static void wiz_clock_cleanup(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1089,6 +1091,7 @@ static void wiz_clock_init(struct wiz *wiz)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
switch (rate) {
case REF_CLK_100MHZ:
@@ -1158,6 +1161,7 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1246,6 +1250,14 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
break;
+
+ case J722S_WIZ_10G:
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
+ break;
+
default:
return 0;
}
@@ -1350,6 +1362,15 @@ static struct wiz_data am64_10g_data = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j722s_10g_data = {
+ .type = J722S_WIZ_10G,
+ .pll0_refclk_mux_sel = &pll0_refclk_mux_sel,
+ .pll1_refclk_mux_sel = &pll1_refclk_mux_sel,
+ .refclk_dig_sel = &refclk_dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
static struct wiz_data j7200_pg2_10g_data = {
.type = J7200_WIZ_10G,
.pll0_refclk_mux_sel = &sup_pll0_refclk_mux_sel,
@@ -1389,6 +1410,9 @@ static const struct of_device_id wiz_id_table[] = {
{
.compatible = "ti,am64-wiz-10g", .data = &am64_10g_data,
},
+ {
+ .compatible = "ti,j722s-wiz-10g", .data = &j722s_10g_data,
+ },
{
.compatible = "ti,j7200-wiz-10g", .data = &j7200_pg2_10g_data,
},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-j721e-wiz.yaml | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 3f16ff14484d2..0653252c18d8e 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -12,13 +12,18 @@ maintainers:
properties:
compatible:
- enum:
- - ti,j721e-wiz-16g
- - ti,j721e-wiz-10g
- - ti,j721s2-wiz-10g
- - ti,am64-wiz-10g
- - ti,j7200-wiz-10g
- - ti,j784s4-wiz-10g
+ oneOf:
+ - enum:
+ - ti,j721e-wiz-16g
+ - ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
+ - ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
+ - items:
+ - enum:
+ - ti,j722s-wiz-10g
+ - const: ti,am64-wiz-10g
power-domains:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 4/5] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-gmii-sel.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index 6213c2b6005a5..c2865a6b1d7fb 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -251,6 +251,15 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
.regfields = phy_gmii_sel_fields_am654,
};
+static const
+struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
+ .use_of_data = true,
+ .features = BIT(PHY_GMII_SEL_RGMII_ID_MODE) |
+ BIT(PHY_GMII_SEL_FIXED_TX_DELAY),
+ .regfields = phy_gmii_sel_fields_am654,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const
struct phy_gmii_sel_soc_data phy_gmii_sel_cpsw5g_soc_j7200 = {
.use_of_data = true,
@@ -307,6 +316,10 @@ static const struct of_device_id phy_gmii_sel_id_table[] = {
.compatible = "ti,am654-phy-gmii-sel",
.data = &phy_gmii_sel_soc_am654,
},
+ {
+ .compatible = "ti,j722s-phy-gmii-sel",
+ .data = &phy_gmii_sel_soc_j722s,
+ },
{
.compatible = "ti,j7200-cpsw5g-phy-gmii-sel",
.data = &phy_gmii_sel_cpsw5g_soc_j7200,
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 5/5] arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 9ee5d0c8ffd1e..70f430aa3a944 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -18,7 +18,7 @@ serdes_refclk: clk-0 {
&cbass_main {
serdes_wiz0: phy@f000000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f000000 0x0 0x0f000000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@ serdes0: serdes@f000000 {
};
serdes_wiz1: phy@f010000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f010000 0x0 0x0f010000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -451,6 +451,14 @@ pcie0_ctrl: pcie0-ctrl@4070 {
};
};
+&cpsw3g {
+ compatible = "ti,j722s-cpsw-nuss", "ti,am642-cpsw-nuss";
+};
+
+&phy_gmii_sel {
+ compatible = "ti,j722s-phy-gmii-sel", "ti,am654-phy-gmii-sel";
+};
+
&oc_sram {
reg = <0x00 0x70000000 0x00 0x40000>;
ranges = <0x00 0x00 0x70000000 0x40000>;
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* Re: [PATCH 1/5] arm64: dts: qcom: sm8550: add PCIe MHI register regions and port labels
From: Joe Sandom @ 2026-04-07 11:43 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <ac8a4139-f7ed-4ced-885a-59145c188406@oss.qualcomm.com>
On Tue, Apr 07, 2026 at 01:05:31PM +0200, Konrad Dybcio wrote:
> On 4/4/26 11:50 AM, Joe Sandom via B4 Relay wrote:
> > From: Joe Sandom <jsandom@axon.com>
> >
> > Add the MHI register regions to the pcie0 and pcie1 controller nodes
> > so that the MHI bus layer can access controller registers directly.
> >
> > Also add labels to the root port nodes (pcie0_port0, pcie1_port0) to
> > allow board DTS files to reference them for adding endpoint devices
> > to each pcie root port.
> >
> > Signed-off-by: Joe Sandom <jsandom@axon.com>
> > ---
> > arch/arm64/boot/dts/qcom/sm8550.dtsi | 14 ++++++++------
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > index 912525e9bca6f5e1cbb8887ee0bf9e39650dc4ff..d4caf4d00832d7f1e8f65bf2bc873cddadc42168 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > @@ -1964,8 +1964,9 @@ pcie0: pcie@1c00000 {
> > <0 0x60000000 0 0xf1d>,
> > <0 0x60000f20 0 0xa8>,
> > <0 0x60001000 0 0x1000>,
> > - <0 0x60100000 0 0x100000>;
> > - reg-names = "parf", "dbi", "elbi", "atu", "config";
> > + <0 0x60100000 0 0x100000>,
> > + <0 0x01C03000 0 0x1000>;
>
> lowercase hex please, both places
Ack. Will correct this in v2.
>
> > + reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
>
> Since you're touching this part of the file anyway and others asked for
> more changes.. could you please break up the reg-names that you're
> editing such that there's one entry per line and they're aligned on
> the opening quote, i.e.
>
> reg-names = "foo",
> "bar",
> ...
>
> ?
Will do this in V2. Thanks Konrad.
>
> FWIW the reg ranges you added are OK
>
> Konrad
^ permalink raw reply
* Re: [PATCH] dt-binding: leds: publish common bindings under dual license
From: Greg Kroah-Hartman @ 2026-04-07 11:45 UTC (permalink / raw)
To: Corvin Köhne
Cc: linux-kernel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, open list:LED SUBSYSTEM, Krzysztof Kozlowski,
Conor Dooley, Pavel Machek, Lee Jones, Corvin Köhne,
Ashley Towns, Dan Murphy, Gergo Koteles, INAGAKI Hiroshi,
Jacek Anaszewski, Jacek Anaszewski, Linus Torvalds,
Olliver Schinagl, Pavel Machek, Rafał Miłecki,
Roderick Colenbrander
In-Reply-To: <20260407113941.43239-1-corvin.koehne@gmail.com>
On Tue, Apr 07, 2026 at 01:39:41PM +0200, Corvin Köhne wrote:
> From: Corvin Köhne <c.koehne@beckhoff.com>
>
> Changes leds/common.h DT binding header file to be published under GPLv2
> or BSD-2-Clause license terms. This change allows this common LED
> bindings header file to be used in software components as bootloaders
> and OSes that are not published under GPLv2 terms.
>
> All contributors to leds/common.h file in copy.
>
> Cc: Ashley Towns <mail@ashleytowns.id.au>
> Cc: Dan Murphy <dmurphy@ti.com>
> Cc: Gergo Koteles <soyer@irl.hu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
My only change was to put the proper SPDX line on the file, so my
opinion/change does not count here for a licensing change, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v6 3/3] arm64: dts: qcom: Add Samsung Galaxy Book4 Edge DTS/DTSI
From: Konrad Dybcio @ 2026-04-07 11:55 UTC (permalink / raw)
To: Maxim Storetvedt, andersson, robh, krzk+dt, conor+dt
Cc: marcus, marijn.suijten, linux-arm-msm, devicetree, linux-kernel,
abel.vesa, abel.vesa, johan, konradybcio, kirill
In-Reply-To: <e6134dd0-6672-44ce-8ced-41fc3e21e474@cern.ch>
On 3/31/26 6:34 PM, Maxim Storetvedt wrote:
>
>
> On 3/30/26 12:41, Konrad Dybcio wrote:
>> On 3/26/26 7:30 PM, Maxim Storetvedt wrote:
>>>
>>>
>>> On 3/26/26 12:33, Konrad Dybcio wrote:
>>>> On 3/25/26 7:30 PM, Maxim Storetvedt wrote:
>>>>>
>>>>>
>>>>> On 3/23/26 13:17, Konrad Dybcio wrote:
>>>>>> On 3/22/26 5:03 PM, Maxim Storetvedt wrote:
>>>>>>> Adds devicetrees for the 14-inch and 16-inch SKUs of the Samsung Galaxy Book4 Edge.
>>>>>>>
>>>>>>> These use a common dtsi derived from nodes that were able to work on Linux
>>>>>>> from the initial Galaxy Book4 Edge DTS by Marcus:
>>>>>>>
>>>>>>> Link: https://lore.kernel.org/all/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/
>>>>>>>
>>>>>>> combined with the ongoing patch for the Honor Magicbook Art 14, and its downstream by
>>>>>>> Valentin Manea, which shares device similarities:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> +&i2c8 {
>>>>>>> + clock-frequency = <400000>;
>>>>>>> +
>>>>>>> + status = "okay";
>>>>>>> +
>>>>>>> + touchscreen@5d {
>>>>>>> + compatible = "hid-over-i2c";
>>>>>>> + reg = <0x5d>;
>>>>>>> +
>>>>>>> + hid-descr-addr = <0x1>;
>>>>>>> + interrupts-extended = <&tlmm 34 IRQ_TYPE_LEVEL_LOW>;
>>>>>>> +
>>>>>>> + vdd-supply = <&vreg_misc_3p3>;
>>>>>>> + /* Lower power supply is not enoug to work. */
>>>>>>> + // vddl-supply = <&vreg_l15b_1p8>;
>>>>>>
>>>>>> How should we interpret that?
>>>>>>
>>>>>
>>>>> This was in the original patch, but using that same regulator appears to
>>>>> be enough to also get touchscreen working on the 16" book4e. That said,
>>>>> it still does not work on the 14". Something to revisit later...
>>>>>
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> +&panel {
>>>>>>> + compatible = "samsung,atna40cu07", "samsung,atna33xc20";
>>>>>>
>>>>>> I think it'd make sense to move the compatible from 'common' to the
>>>>>> 16in DTS then too
>>>>>>
>>>>>>> + enable-gpios = <&pmc8380_3_gpios 4 GPIO_ACTIVE_HIGH>;
>>>>>>
>>>>>> this matches the common definition
>>>>>>
>>>>>>> + power-supply = <&vreg_edp_3p3>;
>>>>>>
>>>>>> ditto
>>>>>>
>>>>>>> + no-hpd;
>>>>>>
>>>>>> really??
>>>>>>
>>>>> One less thing to debug while previously attempting to work around the
>>>>> "illegal link rate" error, which turned out to be related to eDP 1.4
>>>>> (similar to the sp11). I've kept it as-is in case other SKUs attempt
>>>>> booting from this dts, such as the x1e80100 16" (as it might be getting
>>>>> a black screen using the current x1e84100 16" dts, though this is not
>>>>> fully tested).
>>>>
>>>> So do the 80100 and 84100-equipped SKUs of the laptop come with different
>>>> displays?
>>>>
>>>> Konrad
>>>
>>> So far assumed both 16" variants to be fairly similar, though one
>>> valiant 16" 80100 user over in the debug thread did try to boot via the
>>> 84100 dts, with no success. Instead having the screen go dark after the
>>> first post-tux kernel prints.
>>
>> Does switching to the generic edp-panel compatible (which will parse the
>> EDID and try not to be overly smart about it) help here?
>>
>>> This was strapped together via WSL though, so could be there was
>>> something else at fault, but strange it didn't at least fall back to a
>>> visible initramfs shell.
>>
>> You mean the kernel had been compiled via WSL? That shouldn't be a problem..
>>
>> Konrad
>
> Kernel was one shared by me in advance (same I've been using as a
> daily), so it should be OK, but there was an uphill battle in creating
> the modified system image afaik (that would boot).
>
> Can only speculate until there is another go at this, but could likewise
> be something completely unrelated that's simple to fix, e.g. older mesa
> in image, but final attempt at boot used a dts with gpu node enabled.
FWIW the GPU and display engine are completely disjoint, so mesa itself
shouldn't be an issue (unless something was caught in a restart loop due
to poor error handling.. I've seen that N years ago but have no clue
that would still be a problem nowadays)
Konrad
^ permalink raw reply
* Re: [RFC][PATCH 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Geert Uytterhoeven @ 2026-04-07 12:06 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260328000031.94645-4-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sat, 28 Mar 2026 at 01:00, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/arch/arm/boot/dts/renesas/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/renesas/r8a7740.dtsi
> @@ -551,9 +551,9 @@ cpg_clocks: cpg_clocks@e6150000 {
> clock-output-names = "system", "pllc0", "pllc1",
> "pllc2", "r",
> "usb24s",
> - "i", "zg", "b", "m1", "hp",
> - "hpp", "usbp", "s", "zb", "m3",
> - "cp";
> + "i", "zg", "b", "m1", "ztr", "zt",
> + "hp", "hpp", "usbp", "s", "zb",
> + "m3", "cp";
The order of the names must match the indices in the DT bindings below.
Else consumers end up with a wrong parent clock, leading to issues
like the I2C controller driver failing to probe because its parent
clock is out of range.
> };
>
> /* Variable factor clocks (DIV6) */
> diff --git a/include/dt-bindings/clock/r8a7740-clock.h b/include/dt-bindings/clock/r8a7740-clock.h
> index 1b3fdb39cc426..8a8816b2ff6ac 100644
> --- a/include/dt-bindings/clock/r8a7740-clock.h
> +++ b/include/dt-bindings/clock/r8a7740-clock.h
> @@ -24,6 +24,8 @@
> #define R8A7740_CLK_ZB 14
> #define R8A7740_CLK_M3 15
> #define R8A7740_CLK_CP 16
> +#define R8A7740_CLK_ZTR 17
> +#define R8A7740_CLK_ZT 18
Append at the end, good.
>
> /* MSTP1 */
> #define R8A7740_CLK_CEU21 28
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Bui Duc Phuc @ 2026-04-07 12:18 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <87a4vfu0mz.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
> Ah... is it because PIO transfer ?
> I have 100% forgotten, but FSI doesn't support RX DMA...
That is correct. Currently, the Armadillo board lacks DMA and HDMI support
after the transition to DTS, so FSI is limited to FSIA in PIO mode. I plan to
investigate those drivers further once the FSI implementation is finalized.
> Hmm... fsi_dai_trigger() seems strange.
> It seems (A) stops clock, and (B) sets register after that.
> Is this the reason why you get error ? I think (A) and (B) should be
> reversed. The balance between SNDRV_PCM_TRIGGER_START, and with
> __fsi_suspend() are also not good.
> If so, can you use hw_start/stop() ?
Thank you for the guidance. After reordering the sequence and moving the
SPU power control to fsi_hw_start/shutdown, the system hang is now resolved.
> Basically, concept of this driver is that power/clock is enabled/disabled
> when trigger() was called (except suspend/resume).
> While your testing may be correct from an ALSA point of view, but setting
> configuring it in multiple places will lead to confusion.
I see your point. I agree that keeping the power/clock management centralized
in trigger() is a much cleaner approach.
By the way, I’d like to discuss the fsidiv clock handling.
In the legacy implementation, it was handled here:
https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/sh/clk/cpg.c.
Currently, this has not been ported to the Common Clock Framework (CCF) for
R8A7740, and it resides in a different register range from the core CPG.
For v2, would you prefer that I implement a small clock provider for
fsidiv within
the FSI driver, or should it be added under drivers/clk/renesas/?
Best regards,
Phuc
^ permalink raw reply
* Re: [PATCH V10 03/13] PCI: dwc: Parse Root Port nodes in dw_pcie_host_init()
From: Manivannan Sadhasivam @ 2026-04-07 12:21 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114DFBAB7D1537A9A0A7CEB925AA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Tue, Apr 07, 2026 at 09:18:58AM +0000, Sherry Sun wrote:
> > On Tue, Apr 07, 2026 at 03:21:30AM +0000, Sherry Sun wrote:
> > > > On Thu, Apr 02, 2026 at 05:50:57PM +0800, Sherry Sun wrote:
> > > > > Add support for parsing Root Port child nodes in
> > > > > dw_pcie_host_init() using pci_host_common_parse_ports(). This
> > > > > allows DWC-based drivers to specify Root Port properties (like
> > > > > reset GPIOs) in individual Root Port nodes rather than in the host bridge
> > node.
> > > > >
> > > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > > ---
> > > > > drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > index da152c31bb2e..f6fca984fb34 100644
> > > > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > @@ -20,6 +20,7 @@
> > > > > #include <linux/platform_device.h>
> > > > >
> > > > > #include "../../pci.h"
> > > > > +#include "../pci-host-common.h"
> > > > > #include "pcie-designware.h"
> > > > >
> > > > > static struct pci_ops dw_pcie_ops; @@ -581,6 +582,13 @@ int
> > > > > dw_pcie_host_init(struct dw_pcie_rp *pp)
> > > > >
> > > > > pp->bridge = bridge;
> > > > >
> > > > > + /* Parse Root Port nodes if present */
> > > > > + ret = pci_host_common_parse_ports(dev, bridge);
> > > > > + if (ret && ret != -ENOENT) {
> > > > > + dev_err(dev, "Failed to parse Root Port nodes: %d\n", ret);
> > > > > + return ret;
> > > >
> > > > Won't this change break drivers that parse Root Ports on their own?
> > > > Either you need to modify them also in this change or call this API
> > > > from imx6 driver and let other drivers switch to it in a phased manner.
> > > >
> > > > I perfer the latter.
> > >
> > > Hi Mani, sorry I didn't fully get your point here, there are no
> > > changes to this part V10, for drivers that parse Root Ports on their
> > > own, here pci_host_common_parse_ports() will return -ENOENT, so
> > > nothing break as we discussed this in V8
> > https://lore.ke/
> > rnel.org%2Fall%2Fdcl3bdljrdzgeaybrg3dc5uaxkebkjns7pajix6mxxftao5g4m%40
> > vm3ywyyp4ujh%2F&data=05%7C02%7Csherry.sun%40nxp.com%7Cd9faef64b
> > 8154bdbc6ee08de94724b22%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > 7C0%7C639111415791802118%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl
> > dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=POsurqr9RqBCnaQyeXDK2HQTN
> > a4Nc0tfl7thSiM9qHA%3D&reserved=0.
> > >
> >
> > So if this API gets called first, it will acquire PERST# from the Root Port node
> > and if the controller drivers try to do the same in their own parsing code,
> > PERST# request will return -EBUSY and the probe will fail.
> >
> > On the other hand, if the controller drivers parse PERST# first, this API will
> > return -EBUSY and will result in probe failure.
> >
> > Only way to fix this issue would be to call this API from imx6 driver for now
> > and start migrating other drivers later.
> >
>
> Ok, get your point here. Your assumption is based on the premise that the controller
> driver parse the reset-gpios in the Root Port node, not that most controller drivers
> now use reset under the host bridge node. For reset-gpios in the Root Port node,
> they should eventually switch to this common API.
>
Not many, but still some and it is paramount to not regress them. That's my
point.
> Anyway, I will call this API in imx6 driver at this stage to avoid impact other platforms.
>
Sounds good!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v1 2/2] usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions
From: Heikki Krogerus @ 2026-04-07 12:22 UTC (permalink / raw)
To: Jameson Thies
Cc: robh, krzk+dt, conor+dt, abhishekpandit, bleung, akuchynski,
gregkh, devicetree, chrome-platform, linux-usb, linux-kernel
In-Reply-To: <20260403223357.1896403-3-jthies@google.com>
On Fri, Apr 03, 2026 at 10:33:27PM +0000, Jameson Thies wrote:
> Add support for cros_ec_ucsi to load based on "google,cros-ec-ucsi"
> compatible devices and "GOOG0021" ACPI nodes.
>
> Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/usb/typec/ucsi/cros_ec_ucsi.c | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/ucsi/cros_ec_ucsi.c b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> index 6bca2dce211c..251aa7251ce6 100644
> --- a/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> +++ b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> @@ -5,11 +5,13 @@
> * Copyright 2024 Google LLC.
> */
>
> +#include <linux/acpi.h>
> #include <linux/container_of.h>
> #include <linux/dev_printk.h>
> #include <linux/jiffies.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/platform_data/cros_ec_commands.h>
> #include <linux/platform_data/cros_usbpd_notify.h>
> #include <linux/platform_data/cros_ec_proto.h>
> @@ -257,7 +259,6 @@ static void cros_ucsi_destroy(struct cros_ucsi_data *udata)
> static int cros_ucsi_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct cros_ec_dev *ec_data = dev_get_drvdata(dev->parent);
> struct cros_ucsi_data *udata;
> int ret;
>
> @@ -265,9 +266,16 @@ static int cros_ucsi_probe(struct platform_device *pdev)
> if (!udata)
> return -ENOMEM;
>
> + /* ACPI and OF FW nodes for cros_ec_ucsi are children of the ChromeOS EC. If the
> + * cros_ec_ucsi device has an ACPI or OF FW node, its parent is the ChromeOS EC device.
> + * Platforms without a FW node for cros_ec_ucsi may add it as a subdevice of cros_ec_dev.
> + */
> udata->dev = dev;
> + if (is_acpi_device_node(dev->fwnode) || is_of_node(dev->fwnode))
> + udata->ec = dev_get_drvdata(dev->parent);
> + else
> + udata->ec = ((struct cros_ec_dev *)dev_get_drvdata(dev->parent))->ec_dev;
>
> - udata->ec = ec_data->ec_dev;
> if (!udata->ec)
> return dev_err_probe(dev, -ENODEV, "couldn't find parent EC device\n");
>
> @@ -348,10 +356,24 @@ static const struct platform_device_id cros_ucsi_id[] = {
> };
> MODULE_DEVICE_TABLE(platform, cros_ucsi_id);
>
> +static const struct acpi_device_id cros_ec_ucsi_acpi_device_ids[] = {
> + { "GOOG0021", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, cros_ec_ucsi_acpi_device_ids);
> +
> +static const struct of_device_id cros_ucsi_of_match[] = {
> + { .compatible = "google,cros-ec-ucsi", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, cros_ucsi_of_match);
> +
> static struct platform_driver cros_ucsi_driver = {
> .driver = {
> .name = KBUILD_MODNAME,
> .pm = &cros_ucsi_pm_ops,
> + .acpi_match_table = cros_ec_ucsi_acpi_device_ids,
> + .of_match_table = cros_ucsi_of_match,
> },
> .id_table = cros_ucsi_id,
> .probe = cros_ucsi_probe,
> --
> 2.53.0.1213.gd9a14994de-goog
--
heikki
^ permalink raw reply
* [PATCH v4 00/11] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Luca Ceresoli @ 2026-04-07 12:24 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares, Luca Ceresoli
This series modernizes the i.mx8mp LCDIF driver to use the
bridge-connector, which is the current best practice in DRM.
== Call for testing on i.MX8MP boards (especially those using HDMI)!
For who tested previous versions (thanks!): some patches have changed
ingnificantly in v2 and v3 so I had to drop your Tested-by on them. A new
round of test would still be useful.
This series applies changes to how video output devices are probed on
i.MX8MP, especially those using HDMI. Even though I have put care in not
breaking anything, there could potentially be pitfalls I haven't realized,
causing regressions on existing boards.
I have thus added in Cc all developers which appeared active on dts files
for imx8mp boards involving video. I would appreciate testing on as many
boards as possible, along with a Tested-by tag, or a report about any
issues encountered.
Thanks in advance to all testers!
== Review recommendation
I recommend reviewing patches in this order to be understood more
effectively:
* Cover letter
* Patches 1-6: small preliminary cleanups (can be applied independently)
* Patch 11: the goal of this series, but would not work alone
* Patch 10: lets patch 11 work; but in turn it can't work alone
* Patch 8+9: lets patch 10 work; but in turn it can't work alone
* Patch 7: lets patch 8 work
== Series description
This series is not strictly related to DRM bridge hotplug, it is rather a
preparation step. Introducing hotplug would need two different approaches:
one for the new way, for drivers using bridge-connector and
DRM_BRIDGE_ATTACH_NO_CONNECTOR, another for drivers using the "old, legacy
way" where the last bridge is supposed to instantiate the
drm_connector. Hotplug is complicated enough in one case, so it makes sense
to only support the new way.
The hardware I'm working on is an i.MX8MP, whose LCDIF driver is still
using the old way. So this series converts to the new way as a preparation
step.
Patch 11 does the conversion, which is simple. However this would introduce
a regression on some boards. Here's why:
There are 3 instances of the LCDIF in i.MX8MP:
* LCDIF1, driving the DSI output
* LCDIF2, driving the LVDS output
* LCDIF3, driving the HDMI output
The device drivers of peripherals connected to LCDIF1 and LCDIF2 already
support the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. So far so good.
LCDIF3 is more tricky. The HDMI pipeline is:
LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector
The fsl,imx8mp-hdmi-tx (hdmi-tx) does not support
DRM_BRIDGE_ATTACH_NO_CONNECTOR, but it is based on the dw-hdmi component
which supports it by simply changing a setting in the driver platform
data. Patch 10 does this switch.
However, for that switch to work, the device tree must describe the HDMI
connector (compatible = "hdmi-connector").
Unfortunately not all device trees in mainline have an hdmi-connector
node. Adding one is easy, but would break existing hardware upgrading to a
newer kernel without upgrading the device tree blob. This is addressed by
patch 8+9 reusing an existing approach to add such a node to the live device
tree at init time using a device tree overlay for boards which don't have
one.
Finally, patch 8+9 cannot work alone because of a bad interaction between
devlink and device tree overlays. Patch 7 solves that.
Tested on the Avnet MSC SM2-MB-EP1 board which currently has no
"hdmi-connector" in the upstream device tree.
== Grand plan
This is part of the work to support hotplug of DRM bridges. The grand plan
was discussed in [0].
Here's the work breakdown (➜ marks the current series):
1. … add refcounting to DRM bridges struct drm_bridge,
based on devm_drm_bridge_alloc()
A. ✔ add new alloc API and refcounting (v6.16)
B. ✔ convert all bridge drivers to new API (v6.17)
C. ✔ kunit tests (v6.17)
D. ✔ add get/put to drm_bridge_add/remove() + attach/detach()
and warn on old allocation pattern (v6.17)
E. … add get/put on drm_bridge accessors
1. ✔ drm_bridge_chain_get_first_bridge(), add cleanup action (v6.18)
2. ✔ drm_bridge_get_prev_bridge() (v6.18)
3. ✔ drm_bridge_get_next_bridge() (v6.19)
4. ✔ drm_for_each_bridge_in_chain() (v6.19)
5. ✔ drm_bridge_connector_init (v6.19)
6. … protect encoder bridge chain with a mutex
7. … of_drm_find_bridge
a. ✔ add of_drm_get_bridge() (v7.0),
convert basic direct users (v7.0-v7.1)
b. ✔ convert direct of_drm_get_bridge() users, part 2 (v7.0)
c. ✔ convert direct of_drm_get_bridge() users, part 3 (v7.0)
d. ✔… convert direct of_drm_get_bridge() users, part 4
(some v7.1, some pending)
e. convert bridge-only drm_of_find_panel_or_bridge() users
8. drm_of_find_panel_or_bridge, *_of_get_bridge
9. ✔ enforce drm_bridge_add before drm_bridge_attach (v6.19)
F. ✔ debugfs improvements
1. ✔ add top-level 'bridges' file (v6.16)
2. ✔ show refcount and list lingering bridges (v6.19)
2. … handle gracefully atomic updates during bridge removal
A. ✔ Add drm_bridge_enter/exit() to protect device resources (v7.0)
B. … protect private_obj removal from list
C. ✔ Add drm_bridge_clear_and_put() (v7.1)
3. … DSI host-device driver interaction
4. ✔ removing the need for the "always-disconnected" connector
5. ➜ Migrate i.MX LCDIF driver to bridge-connector
6. DRM bridge hotplug
A. Bridge hotplug management in the DRM core
B. Device tree description
[0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v4:
- Patch 8: fix dtso warning
- Patch 9: add missing \n in warning
- Patch 11: improve commit message
- Link to v3: https://patch.msgid.link/20260402-drm-lcdif-dbanc-v3-0-27cd247a0847@bootlin.com
Changes in v3:
- Patch 8: simplified overlay, handle of_overlay_fdt_apply() errors, use
of_graph_get_endpoint_by_regs() + add warning in separate patch
- Updated cover and mentioned the hardware used for testing
- Minor fixes to other patches
- Link to v2: https://patch.msgid.link/20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com
Changes in v2:
- Dropped patch removing the loop in lcdif_attach_bridge, adapted following
patches as needed, added patch to use __free on the ep pointer
- Added new cleanup patch (patch 6)
- Build the fixup module unconditionally
- patch 7: fix returned error codes
- patch 1: fix cleanup action
- Various minor improvements based on reviews, see per-patch changelog
- Removed bouncing recipients from Cc
- Link to v1: https://lore.kernel.org/r/20260320-drm-lcdif-dbanc-v1-0-479a04133e70@bootlin.com
---
Luca Ceresoli (11):
drm/mxsfb/lcdif: simplify remote pointer management using __free
drm/mxsfb/lcdif: simplify ep pointer management using __free
drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
drm/mxsfb/lcdif: move iteration-specific variables declaration inside loop in lcdif_attach_bridge
drm/bridge: dw-hdmi: document the output_port field
drm/bridge: dw-hdmi: warn on unsupported attach combination
drm/bridge: dw-hdmi: move next_bridge lookup to attach time
drm/bridge: imx8mp-hdmi-tx-connector-fixup: add an hdmi-connector when missing using a DT overlay at boot time
drm/bridge: imx8mp-hdmi-tx-connector-fixup: show a warning when adding the overlay
drm/bridge: imx8mp-hdmi-tx: switch to DRM_BRIDGE_ATTACH_NO_CONNECTOR
drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
drivers/gpu/drm/bridge/imx/Kconfig | 18 ++++++
drivers/gpu/drm/bridge/imx/Makefile | 2 +
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 75 ++++++++++++++++++++++
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 30 +++++++++
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 49 ++++++--------
drivers/gpu/drm/mxsfb/Kconfig | 2 +
drivers/gpu/drm/mxsfb/lcdif_drv.c | 69 ++++++++++----------
include/drm/bridge/dw_hdmi.h | 6 ++
9 files changed, 189 insertions(+), 63 deletions(-)
---
base-commit: 9558119259ea082c551ac3d9af912eba8ba6a99e
change-id: 20260306-drm-lcdif-dbanc-83dd948327de
Best regards,
--
Luca Ceresoli <luca.ceresoli@bootlin.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