* Re: [PATCH RFC 4/4] arm64: dts: qcom: Enable GPU & GMU on Glymur CRD
From: Konrad Dybcio @ 2026-04-15 9:12 UTC (permalink / raw)
To: Akhil P Oommen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Clark, Sean Paul,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Marijn Suijten,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno
In-Reply-To: <20260405-glymur-gpu-dt-v1-4-2135eb11c562@oss.qualcomm.com>
On 4/4/26 11:03 PM, Akhil P Oommen wrote:
> Enable the necessary DT nodes to add support for GPU on the Glymur CRD.
> The Glymur CRD boots Linux at EL2, which means it doesn't require the
> secure GPU firmware (zap fw).
>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
This isn't a blocker per se, but since there is no more zap, do you
think we can just enable the GPU and GMU by default (i.e. no status=
"disabled" in SoC DTSI)?
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 6/7] arm64: dts: qcom: sm8750: Add label properties to CoreSight devices
From: Konrad Dybcio @ 2026-04-15 9:11 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260414-add-label-to-coresight-device-v2-6-5017d07358f2@oss.qualcomm.com>
On 4/14/26 1:36 PM, Jie Gan wrote:
> Add label properties to TPDM and CTI nodes in the sm8750 device tree to
> provide human-readable identifiers for each CoreSight device. These
> labels allow userspace tools and the CoreSight framework to identify
> devices by name rather than by base address.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Andy Shevchenko @ 2026-04-15 9:07 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Manivannan Sadhasivam, Manivannan Sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <CAGXv+5EPA29G-fsH=wWOD8AK6TZFezFhsE0NHPYj_Pt3nT+d_w@mail.gmail.com>
On Wed, Apr 15, 2026 at 04:31:24PM +0800, Chen-Yu Tsai wrote:
> On Tue, Apr 14, 2026 at 8:03 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Apr 14, 2026 at 06:29:02PM +0800, Chen-Yu Tsai wrote:
> > > On Tue, Apr 14, 2026 at 4:28 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> > > > > On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
...
> > > > > > > > - Given that this connector actually represents two devices, how do I
> > > > > > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > > > > > Does wakeup-source even work at this point?
> > > > > > >
> > > > > > > You can't use the DT property since the devices are not described in DT
> > > > > > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > > > > > wakeup.
> > > > >
> > > > > I see. I think not being able to specify generic properties for the devices
> > > > > on the connector is going to be a bit problematic.
> > > >
> > > > This is nature of the open-connectors, especially on the busses that are
> > > > hotpluggable, like PCIe. We never know what is connected there _ahead_.
> > >
> > > I believe what you mean by "hotpluggable" is "user replaceable".
> >
> > From the OS perspective it's the same. From platform perspective
> > there is a difference, granted.
>
> Yes. I just wanted to clarify.
>
> > > > In other words you can't describe in DT something that may not exist.
> > >
> > > But this is actually doable with the PCIe slot representation. The
> > > properties are put in the device node for the slot. If no card is
> > > actually inserted in the slot, then no device is created, and the
> > > device node is left as not associated with anything.
> >
> > But you need to list all devices in the world if you want to support this
>
> Why would I need to? The PCIe slot representation just describes a
> PCIe bridge. Granted this might not be entirely correct, but it's
> what we currently have.
>
> And even then, there are properties like memory-region or wakeup-source
> that are generic and aren't tied to specific devices.
Yes, see below what I replied...
> > somehow. Yes, probably many of them (or majority) will be enumerated as is,
^^^ "the majority" will work without any assistance.
> > but some may need an assistance via (dynamic) properties or similar mechanisms.
> Even if we wanted to add dynamic properties, there is currently no proper
> device node to attach them to.
Isn't that's node created dynamically as well and attached to the PCI bus?
> > > It's just that for this new M.2 E-key connector, there aren't separate
> > > nodes for each interface. And the system doesn't associate the device
> > > node with the device, because it's no longer a child node of the
> > > controller or hierarchy, but connected over the OF graph.
> > >
> > > Moving over to the E-key connector representation seems like one step
> > > forward and one step backward in descriptive ability. We gain proper
> > > power sequencing, but lose generic properties.
> >
> > The "key" is property of the connector. Hence if you have an idea what can be
> > common for ALL "key":s, that's probably can be abstracted. Note, I'm not
> > familiar with the connector framework in the Linux kernel, perhaps it's already
> > that kind of abstraction.
>
> I'm not arguing for a even more generic "M.2" connector. The "key" is
> already described in the compatible. I'm saying we should have some way
> of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
> on the connector so further nodes or properties can be attached to them,
> either with overlays or dynamically within the kernel. Right now the
> are only described as individual ports, but we can't actually tie a
> device to a OF graph port.
Shouldn't it be described as a DT subtree? Sorry, I am not familiar with DT
enough to understand the issue you have.
> But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
> UART-based BT bit part, Mani just had the driver create a device node
> under the UART (by traversing the OF graph to find the UART). If that's
> the desired way then the connector binding should mention it. And that
> works for me. But I think it's messier and also we're missing an
> opportunity to make the M.2 connector a standardized attachment point
> for overlays.
Okay, now it might get clearer to me, but still, I am not an expert.
> Mani, could you also chime in a bit on what you envisioned?
+1, please elaborate to me as well.
> (Added Luca from Bootlin to CC, as I think there are parallels to the
> "Hotplug of Non-discoverable Hardware" work)
>
> > > The latter part is solvable, but we likely need child nodes under the
> > > connector for the different interfaces. Properties that make sense for
> > > one type might not make sense for another.
> > >
> > > P.S. We could also just add child device nodes under the controller to
> > > put the generic properties, but that's splitting the description into
> > > multiple parts. Let's not go there if at all possible.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: media: i2c: Add os02g10 sensor
From: Krzysztof Kozlowski @ 2026-04-15 9:03 UTC (permalink / raw)
To: Elgin Perumbilly, sakari.ailus, tarang.raval
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans Verkuil, Hans de Goede, Vladimir Zapolskiy,
Mehdi Djait, Laurent Pinchart, Benjamin Mugnier, Sylvain Petinot,
Hardevsinh Palaniya, Heimir Thor Sverrisson, Jingjing Xiong,
Himanshu Bhavani, Svyatoslav Ryhel, linux-media, devicetree,
linux-kernel
In-Reply-To: <20260414084952.217215-2-elgin.perumbilly@siliconsignals.io>
On 14/04/2026 10:49, Elgin Perumbilly wrote:
> +
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + data-lanes:
> + items:
> + - const: 1
> + - const: 2
This looks completely fixed per model. If device cannot work with four
lanes, then you simply don't need this property. It's deducible from the
compatible.
> + required:
> + - data-lanes
> + - link-frequencies
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - avdd-supply
> + - dovdd-supply
> + - dvdd-supply
> + - port
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/6] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Bui Duc Phuc @ 2026-04-15 9:02 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: <87tstepes7.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
Thank you for your detailed review and feedback.
> 1st, please insert white line between "int ret = 0;" and "/* enable spu
> clock */".
>
> 2nd, besically, FSI already has "lock", and using it for several protecting.
> Please re-use it, and don't add random new-lock. It makes code confusable.
> Then, please use guard().
I will fix the coding style and use
guard(spinlock_irqsave)(&master->lock) in v3.
It’s much better than adding a new lock.
> 3rd, I don't like above count inc/dec, and mutex_unlock() style, because
> the code unnecessarily complicated. It can be...
>
> int ret = 0;
>
> if (master->clk_spu) {
> guard(spinlock_irqsave)(&master->lock);
>
> if (master->spu_count == 0)
> ret = clk_prepare_enable(master->clk_spu);
>
> master->spu_count++;
> }
> if (ret < 0)
> return ret;
>
> I'm not 100% sure, but I guess you need to count up spu_count anyway
> regardless of clk_prepare_enable() result ?
Regarding spu_count, I’m not entirely sure, but if we increment it
even on failure,
the counter might become unbalanced and clk_prepare_enable() may not
be retried on the next call.
Would it be better to increment spu_count only on success to keep the
state consistent?
Also, I have a question about the context here.
Since fsi_hw_startup() and fsi_hw_shutdown() are called from fsi_dai_trigger(),
I think this runs in an atomic context, but please correct me if I'm wrong.
If so, is it safe to call clk_prepare_enable() under guard(spinlock_irqsave)?
Since clk_prepare() can sleep, I’m wondering if this could potentially
cause a "scheduling while atomic" issue.
Would it make more sense to move clk_prepare() to init time (in new
fsi_clk_init() ),
and only use clk_enable() / clk_disable() in the trigger path?
Best regards,
Phuc
On Tue, Apr 14, 2026 at 7:27 AM Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
>
> Hi
>
> Hi
>
> > Enable/disable the shared SPU clock in hw startup/shutdown. Without this,
> > accessing FSI registers may hang the system.
> >
> > Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> > ---
> (snip)
> > @@ -1492,6 +1492,18 @@ static int fsi_hw_startup(struct fsi_priv *fsi,
> > struct device *dev)
> > {
> > u32 data = 0;
> > + int ret = 0;
> > + /* enable spu clock */
> > + mutex_lock(&fsi->master->clk_lock);
> > + if (fsi->master->clk_spu && fsi->master->spu_count++ == 0) {
> > + ret = clk_prepare_enable(fsi->master->clk_spu);
> > + if (ret < 0) {
> > + fsi->master->spu_count--;
> > + mutex_unlock(&fsi->master->clk_lock);
> > + return ret;
> > + }
> > + }
> > + mutex_unlock(&fsi->master->clk_lock);
>
> 1st, please insert white line between "int ret = 0;" and "/* enable spu
> clock */".
>
> 2nd, besically, FSI already has "lock", and using it for several protecting.
> Please re-use it, and don't add random new-lock. It makes code confusable.
> Then, please use guard().
>
> 3rd, I don't like above count inc/dec, and mutex_unlock() style, because
> the code unnecessarily complicated. It can be...
>
> int ret = 0;
>
> if (master->clk_spu) {
> guard(spinlock_irqsave)(&master->lock);
>
> if (master->spu_count == 0)
> ret = clk_prepare_enable(master->clk_spu);
>
> master->spu_count++;
> }
> if (ret < 0)
> return ret;
>
> I'm not 100% sure, but I guess you need to count up spu_count anyway
> regardless of clk_prepare_enable() result ?
>
> Thank you for your help !!
>
> Best regards
> ---
> Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: msm8916-panasonic-eluga-u2: add initial device tree
From: Konrad Dybcio @ 2026-04-15 9:01 UTC (permalink / raw)
To: Lin, Meng-Bo, linux-kernel
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, phone-devel,
~postmarketos/upstreaming
In-Reply-To: <20260414184429.168612-3-linmengbo06890@proton.me>
On 4/14/26 8:44 PM, Lin, Meng-Bo wrote:
> Panasonic ELUGA U2 is a phone using the MSM8916 SoC released in 2015.
>
> Add a device tree for with initial support for:
>
> - GPIO keys
> - GPIO LEDs
> - pm8916-vibrator
> - SDHCI (internal and external storage)
> - USB Device Mode
> - UART
> - Regulators
>
> Signed-off-by: "Lin, Meng-Bo" <linmengbo06890@proton.me>
> ---
[...]
> +&pm8916_resin {
> + linux,code = <KEY_VOLUMEDOWN>;
> + status = "okay";
nit: let's uniformly keep a \n before 'status' across the file
with Dmitry's comment taken care of:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur: Drop RPMh CXO clocks from QMP PHYs
From: Konrad Dybcio @ 2026-04-15 8:59 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260414-dts-glymur-drop-rpmh-cxo-clk-from-qmpphys-v1-1-ab12d77c4aec@oss.qualcomm.com>
On 4/14/26 7:05 PM, Abel Vesa wrote:
> On Glymur, all QMP PHYs except the one used by USB SS0 take their
> reference clock from the TCSR clock controller. Since these TCSR clocks
> already derive from RPMH_CXO_CLK as their sole parent, there is no need
> to provide an extra `clkref` clock to the PHY nodes.
>
> Drop the extra RPMh CXO clock inputs and use the TCSR clocks as the PHY
> reference clocks instead.
>
> This also fixes the devicetree schema validation, as the bindings do not
> allow a separate `clkref` clock.
>
> Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes")
> Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reported-by: Rob Herring <robh@kernel.org>
> Closes: https://lore.kernel.org/r/20260410145205.GA554754-robh@kernel.org/
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v7 6/6] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Alexey Charkov @ 2026-04-15 8:57 UTC (permalink / raw)
To: Dennis Gilmore
Cc: Andrew Lunn, Andrzej Hajda, Chaoyi Chen, Conor Dooley,
David Airlie, devicetree, dri-devel, FUKAUMI Naoki,
Heiko Stuebner, Hsun Lai, Jernej Skrabec, Jimmy Hon, John Clark,
Jonas Karlman, Krzysztof Kozlowski, Laurent Pinchart,
linux-arm-kernel, linux-kernel, linux-rockchip, Maarten Lankhorst,
Maxime Ripard, Michael Opdenacker, Michael Riesch, Mykola Kvach,
Neil Armstrong, Peter Robinson, Quentin Schulz, Robert Foss,
Rob Herring, Simona Vetter, Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-7-dennis@ausil.us>
On Wed, Apr 15, 2026 at 1:41 AM Dennis Gilmore <dennis@ausil.us> wrote:
>
> Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
>
> - eMMC module, you can optionally solder a SPI NOR in place and turn
> off the eMMC
> - PCIe-attached NIC (pcie2x1l1)
> - PCIe NVMe slot (pcie2x1l2)
Hi Dennis,
Sashiko noticed [1] that the controller names here do not match the
nodes/comments you have in the patch body - which ones are correct?
[1] https://sashiko.dev/#/patchset/20260414214104.1363987-1-dennis%40ausil.us
> - AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
> - BCM4345C5 Bluetooth
> - es8388 audio
> - USB 2.0 and USB 3.0
> - Two HDMI ports, the second is connected to the SoC's DP controller
> driven through a Lontium LT8711UXD bridge.
>
> Vendors schematics are available at:
> https://drive.google.com/file/d/1qs1DratHuh7C6J6MEtQIwUsiSrg8qgTi/view
>
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../dts/rockchip/rk3588s-orangepi-5-pro.dts | 442 ++++++++++++++++++
> 2 files changed, 443 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 4d384f153c13..c99dca2ae9e7 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> new file mode 100644
> index 000000000000..61462c66753d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> @@ -0,0 +1,442 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3588s-orangepi-5.dtsi"
> +
> +/ {
> + model = "Xunlong Orange Pi 5 Pro";
> + compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
> +
> + aliases {
> + mmc0 = &sdhci;
> + mmc1 = &sdmmc;
> + mmc2 = &sdio;
> + };
> +
> + hdmi1-con {
> + compatible = "hdmi-connector";
> + label = "HDMI1 OUT";
> + type = "a";
> +
> + port {
> + hdmi1_con_in: endpoint {
> + remote-endpoint = <<8711uxd_out>;
> + };
> + };
> + };
> +
> + lt8711uxd {
Please use a generic node name per DT convention. "hdmi-bridge" perhaps?
> + compatible = "lontium,lt8711uxd";
Don't you want to add "vdd-supply = <&vcc3v3_dp>;" here? It costs you
nothing, as it's already in the binding and in the driver, and having
this dependency listed explicitly will let the kernel order the driver
probes correctly, and also likely let you drop the boot-on/always-on
annotation from the regulator node.
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lt8711uxd_in: endpoint {
> + remote-endpoint = <&dp0_out_con>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + lt8711uxd_out: endpoint {
> + remote-endpoint = <&hdmi1_con_in>;
> + };
> + };
> + };
> + };
> +
> + analog-sound {
> + compatible = "simple-audio-card";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hp_detect>;
> + simple-audio-card,format = "i2s";
> + simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> + simple-audio-card,mclk-fs = <256>;
> + simple-audio-card,name = "rockchip,es8388";
> + simple-audio-card,routing =
> + "Headphones", "LOUT1",
> + "Headphones", "ROUT1",
> + "LINPUT1", "Microphone Jack",
> + "RINPUT1", "Microphone Jack",
> + "LINPUT2", "Onboard Microphone",
> + "RINPUT2", "Onboard Microphone";
> + simple-audio-card,widgets =
> + "Microphone", "Microphone Jack",
> + "Microphone", "Onboard Microphone",
> + "Headphone", "Headphones";
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s2_2ch>;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <&es8388>;
> + system-clock-frequency = <12288000>;
> + };
> + };
> +
> + pwm-leds {
> + compatible = "pwm-leds";
> +
> + led-0 {
> + color = <LED_COLOR_ID_BLUE>;
> + function = LED_FUNCTION_STATUS;
> + linux,default-trigger = "heartbeat";
> + max-brightness = <255>;
> + pwms = <&pwm15 0 1000000 0>;
> + };
> +
> + led-1 {
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_ACTIVITY;
> + linux,default-trigger = "heartbeat";
> + max-brightness = <255>;
> + pwms = <&pwm3 0 1000000 0>;
> + };
> + };
> +
> + fan: pwm-fan {
> + compatible = "pwm-fan";
> + #cooling-cells = <2>;
> + cooling-levels = <0 50 100 150 200 255>;
> + fan-supply = <&vcc5v0_sys>;
> + pwms = <&pwm2 0 20000000 0>;
> + };
> +
> + vcc3v3_dp: regulator-vcc3v3-dp {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&dp_bridge_en>;
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
> + regulator-name = "vcc3v3_dp";
> + regulator-always-on;
> + regulator-boot-on;
Please see if you can drop these always-on/boot-on when vdd-supply is
explicitly listed in the bridge node
> + vin-supply = <&vcc_3v3_s3>;
> + };
> +
> + vcc3v3_phy1: regulator-vcc3v3-phy1 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc3v3_phy1_en>;
The board schematics call the pin "Ethernet_EN"
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
> + regulator-name = "vcc3v3_phy1";
> + startup-delay-us = <50000>;
> + vin-supply = <&vcc_3v3_s3>;
> + };
> +
> + vcc5v0_otg: regulator-vcc5v0-otg {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc5v0_otg_en>;
> + regulator-max-microvolt = <5000000>;
> + regulator-min-microvolt = <5000000>;
> + regulator-name = "vcc5v0_otg";
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&hym8563>;
> + clock-names = "ext_clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_enable_h>;
> + post-power-on-delay-ms = <200>;
> + reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
> + };
> +
> + typea_con: usb-a-connector {
> + compatible = "usb-a-connector";
> + data-role = "host";
> + label = "USB3 Type-A";
> + power-role = "source";
> + vbus-supply = <&vcc5v0_otg>;
> + };
> +};
> +
> +&dp0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&dp0m0_pins>;
> + status = "okay";
> +};
> +
> +&dp0_in {
> + dp0_in_vp1: endpoint {
> + remote-endpoint = <&vp1_out_dp0>;
> + };
> +};
> +
> +&dp0_out {
> + dp0_out_con: endpoint {
> + remote-endpoint = <<8711uxd_in>;
> + };
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1m4_xfer>;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c3m0_xfer>;
> + status = "okay";
> +
> + es8388: audio-codec@11 {
> + compatible = "everest,es8388", "everest,es8328";
> + reg = <0x11>;
> + #sound-dai-cells = <0>;
> + AVDD-supply = <&vcca_3v3_s0>;
> + DVDD-supply = <&vcca_1v8_s0>;
> + HPVDD-supply = <&vcca_3v3_s0>;
> + PVDD-supply = <&vcca_1v8_s0>;
> + assigned-clock-rates = <12288000>;
> + assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
> + clocks = <&cru I2S2_2CH_MCLKOUT>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2s2m1_mclk>;
> + };
> +};
> +
> +&i2c4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c4m3_xfer>;
> + status = "okay";
> +};
> +
> +&i2s2_2ch {
> + pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
> + &i2s2m1_sdi &i2s2m1_sdo>;
> + status = "okay";
> +};
> +
> +&package_thermal {
> + polling-delay = <1000>;
> +
> + cooling-maps {
> + map0 {
> + trip = <&package_fan0>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map1 {
> + trip = <&package_fan1>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +
> + trips {
> + package_fan0: package-fan0 {
> + hysteresis = <2000>;
> + temperature = <55000>;
> + type = "active";
> + };
> +
> + package_fan1: package-fan1 {
> + hysteresis = <2000>;
> + temperature = <65000>;
> + type = "active";
> + };
> + };
> +};
> +
> +/* NVMe */
> +&pcie2x1l1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie2x1l1_rst &pcie30x1m1_1_clkreqn &pcie30x1m1_1_waken>;
Is there a particular reason to use the GPIO mode for the reset pin,
rather than the (confusingly named) &pcie30x1m1_1_perstn in line with
the other two?
> + reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
> + supports-clkreq;
> + vpcie3v3-supply = <&vcc_3v3_s3>;
> + status = "okay";
> +};
> +
> +/* NIC */
> +&pcie2x1l2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie2x1l2_rst>;
Similar to the above - have you tried the dedicated hardware mode for
this pin, i.e. &pcie20x1m0_perstn? You are not requesting the
&pcie20x1m0_clkreqn or &pcie20x1m0_waken either, even though they are
routed on the board - that will probably bite you if you try
suspending the board.
> + reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
> + vpcie3v3-supply = <&vcc3v3_phy1>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + bluetooth {
> + bt_wake_gpio: bt-wake-pin {
> + rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
If you care about power consumption of the board it's probably better
to pull this down to make sure the Bluetooth module is predictably in
a sleep state when not explicitly requested, not floating randomly.
There is no dedicated pull-up/pull-down on your board.
> + };
> +
> + bt_wake_host_irq: bt-wake-host-irq {
> + rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +
> + dp {
> + dp_bridge_en: dp-bridge-en {
> + rockchip,pins = <3 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
This pin doesn't have any dedicated pull-up/pull-down on the board, so
you might end up in a weird power state for the period of time between
the probing of the pinctrl subsystem and regulators. Better set it to
&pcfg_pull_down, which matches the power-on-reset default state of
this pin.
> + };
> + };
> +
> + pcie {
> + pcie2x1l1_rst: pcie2x1l1-rst {
> + rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + pcie2x1l2_rst: pcie2x1l2-rst {
> + rockchip,pins = <3 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + vcc3v3_phy1_en: vcc3v3-phy1-en {
The schematic calls this pin "Ethernet_EN", so perhaps use that in the
label and node name for easier reference.
> + rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
As above: no dedicated pull resistors on the board, better set to
&pcfg_pull_down in line with POR default.
> + };
> + };
> +
> + usb {
> + vcc5v0_otg_en: vcc5v0-otg-en {
> + rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
As above: no dedicated pull resistors on the board, better set to
&pcfg_pull_down in line with POR default.
> + };
> + };
> +
> + wlan {
> + wifi_enable_h: wifi-enable-h {
> + rockchip,pins = <0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
As above: no dedicated pull resistors on the board, better set to
&pcfg_pull_down in line with POR default.
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: media: i2c: Add os02g10 sensor
From: Elgin Perumbilly @ 2026-04-15 8:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: sakari.ailus@linux.intel.com, Tarang Raval, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hans Verkuil,
Hans de Goede, Vladimir Zapolskiy, Mehdi Djait, Laurent Pinchart,
Benjamin Mugnier, Sylvain Petinot, Hardevsinh Palaniya,
Heimir Thor Sverrisson, Jingjing Xiong, Himanshu Bhavani,
Svyatoslav Ryhel, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260415-authentic-elastic-auk-eed0e6@quoll>
Hi Krzysztof,
>On Tue, Apr 14, 2026 at 02:19:44PM +0530, Elgin Perumbilly wrote:
>> Add bindings for Omnivision OS02G10 sensor.
>>
>> Signed-off-by: Elgin Perumbilly <elgin.perumbilly@siliconsignals.io>
>> ---
>> .../bindings/media/i2c/ovti,os02g10.yaml | 96 +++++++++++++++++++
>> MAINTAINERS | 7 ++
>> 2 files changed, 103 insertions(+)
>
>Your changelog in cover letters says nothing changed here, so same
>comments as v1. Please go back to v1 and read the feedback carefully.
>
>Best regards,
>Krzysztof
I made the changes but forgot to include them in the changelog.
Changes made:
- Corrected $id to ovti,os02g10.yaml
- Fixed data-lanes property structure to use proper items format
Best regards,
Elgin
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: Enable CAN RX via GPIO expander
From: Konrad Dybcio @ 2026-04-15 8:56 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Anup Kulkarni, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-arm-msm, devicetree, linux-kernel, mukesh.savaliya,
viken.dadhaniya
In-Reply-To: <lghedhcnuh2fm4mp64mkgsgtpkd32yneftjazgrye7bovxxaby@uscrda3wtyoj>
On 4/14/26 8:09 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 06:20:14PM +0200, Konrad Dybcio wrote:
>> On 4/14/26 6:08 PM, Dmitry Baryshkov wrote:
>>> On Thu, Apr 02, 2026 at 04:22:53PM +0530, Anup Kulkarni wrote:
>>>> Few CAN controllers, part of RTSS sub-system on LeMans, route
>>>> their RX signal through a I2C GPIO expander at address 0x3b.
>>>> RTSS subsystem is an MCU like sub-system on LeMans with independent
>>>> booting capability through OSPI interface and supports peripherals like
>>>> RGMII, CAN-FD, UART, I2C, SPI etc.
>>>>
>>>> Describe this hardware wiring by configuring the expander GPIO 4 pin as
>>>> hog with output-high, asserting the selected line during boot.
>>>
>>> Missing platform name in the subject.
>>>
>>>>
>>>> Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/lemans-evk.dts | 7 +++++++
>>>> 1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
>>>> index a1ef4eba2a20..b8371bdf9933 100644
>>>> --- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
>>>> @@ -615,6 +615,13 @@ expander3: gpio@3b {
>>>> interrupts-extended = <&tlmm 39 IRQ_TYPE_LEVEL_LOW>;
>>>> pinctrl-0 = <&expander3_int>;
>>>> pinctrl-names = "default";
>>>> +
>>>> + rtss-can-sel-hog {
>>>
>>> Why is it being described as a hog rather than a pinctrl used by the
>>> CAN device?
>>
>> My understanding is that the CAN bus is managed by SAIL ("RTSS")
>
> So, Linux can affect what is being required for the safety island?
Seems that way!
Konrad
^ permalink raw reply
* Re: [PATCH v3 09/11] dt-bindings: input: Document hid-over-spi DT schema
From: Benjamin Tissoires @ 2026-04-15 8:41 UTC (permalink / raw)
To: Rob Herring, Dmitry Torokhov
Cc: Conor Dooley, Jingyuan Liang, Jiri Kosina, Jonathan Corbet,
Mark Brown, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Krzysztof Kozlowski, Conor Dooley, linux-input, linux-doc,
linux-kernel, linux-spi, linux-trace-kernel, devicetree, hbarnor,
tfiga, Dmitry Antipov, Jarrett Schultz
In-Reply-To: <20260413223439.GA3647847-robh@kernel.org>
On Apr 13 2026, Rob Herring wrote:
> On Fri, Apr 10, 2026 at 06:35:00PM +0100, Conor Dooley wrote:
> > On Thu, Apr 09, 2026 at 10:16:46AM -0700, Dmitry Torokhov wrote:
> > > On Thu, Apr 09, 2026 at 05:02:11PM +0100, Conor Dooley wrote:
> > > > On Thu, Apr 02, 2026 at 01:59:46AM +0000, Jingyuan Liang wrote:
> > > > > Documentation describes the required and optional properties for
> > > > > implementing Device Tree for a Microsoft G6 Touch Digitizer that
> > > > > supports HID over SPI Protocol 1.0 specification.
> > > > >
> > > > > The properties are common to HID over SPI.
> > > > >
> > > > > Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> > > > > Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> > > > > Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> > > > > ---
> > > > > .../devicetree/bindings/input/hid-over-spi.yaml | 126 +++++++++++++++++++++
> > > > > 1 file changed, 126 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..d1b0a2e26c32
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > > > @@ -0,0 +1,126 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: HID over SPI Devices
> > > > > +
> > > > > +maintainers:
> > > > > + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > > > + - Jiri Kosina <jkosina@suse.cz>
> > > >
> > > > Why them and not you, the developers of the series?
> > > >
> > > > > +
> > > > > +description: |+
> > > > > + HID over SPI provides support for various Human Interface Devices over the
> > > > > + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> > > > > + or sensors.
> > > > > +
> > > > > + The specification has been written by Microsoft and is currently available
> > > > > + here: https://www.microsoft.com/en-us/download/details.aspx?id=103325
> > > > > +
> > > > > + If this binding is used, the kernel module spi-hid will handle the
> > > > > + communication with the device and the generic hid core layer will handle the
> > > > > + protocol.
> > > >
> > > > This is not relevant to the binding, please remove it.
> > > >
> > > > > +
> > > > > +allOf:
> > > > > + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + oneOf:
> > > > > + - items:
> > > > > + - enum:
> > > > > + - microsoft,g6-touch-digitizer
> > > > > + - const: hid-over-spi
> > > > > + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> > > > > + const: hid-over-spi
> > > >
> > > > Why is it allowed but not recommended? Seems to me like we should
> > > > require device-specific compatibles.
> > >
> > > Why would we want to change the driver code to add a new compatible each
> > > time a vendor decides to create a chip that is fully hid-spi-protocol
> > > compliant? Or is the plan to still allow "hid-over-spi" fallback but
> > > require device-specific compatible that will be ignored unless there is
> > > device-specific quirk needed?
>
> The plan is the latter case (the 1st entry up above). The comment is
> remove the 2nd entry (with 'Just "hid-over-spi" alone is allowed, but
> not recommended.').
>
> > This has nothing to do with the driver, just the oddity of having a
> > comment saying that not having a device specific compatible was
> > permitted by not recommended in a binding. Requiring device-specific
> > compatibles is the norm after all and a comment like this makes draws
> > more attention to the fact that this is abnormal. Regardless of what the
> > driver does, device-specific compatibles should be required.
> >
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + interrupts:
> > > > > + maxItems: 1
> > > > > +
> > > > > + reset-gpios:
> > > > > + maxItems: 1
> > > > > + description:
> > > > > + GPIO specifier for the digitizer's reset pin (active low). The line must
> > > > > + be flagged with GPIO_ACTIVE_LOW.
> > > > > +
> > > > > + vdd-supply:
> > > > > + description:
> > > > > + Regulator for the VDD supply voltage.
> > > > > +
> > > > > + input-report-header-address:
> > > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > > + minimum: 0
> > > > > + maximum: 0xffffff
> > > > > + description:
> > > > > + A value to be included in the Read Approval packet, listing an address of
> > > > > + the input report header to be put on the SPI bus. This address has 24
> > > > > + bits.
> > > > > +
> > > > > + input-report-body-address:
> > > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > > + minimum: 0
> > > > > + maximum: 0xffffff
> > > > > + description:
> > > > > + A value to be included in the Read Approval packet, listing an address of
> > > > > + the input report body to be put on the SPI bus. This address has 24 bits.
> > > > > +
> > > > > + output-report-address:
> > > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > > + minimum: 0
> > > > > + maximum: 0xffffff
> > > > > + description:
> > > > > + A value to be included in the Output Report sent by the host, listing an
> > > > > + address where the output report on the SPI bus is to be written to. This
> > > > > + address has 24 bits.
> > > > > +
> > > > > + read-opcode:
> > > > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > > > + description:
> > > > > + Value to be used in Read Approval packets. 1 byte.
> > > > > +
> > > > > + write-opcode:
> > > > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > > > + description:
> > > > > + Value to be used in Write Approval packets. 1 byte.
> > > >
> > > > Why can none of these things be determined from the device's compatible?
> > > > On the surface, they like the kinds of things that could/should be.
> > >
> > > Why would we want to keep tables of these values in the kernel and again
> > > have to update the driver for each new chip?
> >
> > That's pretty normal though innit? It's what match data does.
> > If someone wants to have properties that communicate data that
> > can be determined from the compatible, they need to provide
> > justification why it is being done.
>
> IIRC, it was explained in prior versions the spec itself says these
> values vary by device. If we expect variation, then I think these
> properties are fine. But please capture the reasoning for them in this
> patch or we will just keep asking the same questions over and over.
>
Dmitry, FWIW, we roughly had the exact same of argument with Rob with
i2c-hid :)
It took me a while, but I finally understood the rationale and agreed to
it (using the i2c-hid examples):
Most i2c-hid devices are following the spec and rely purely on ACPI and
the DT declaration of i2c-hid -> they are working fine and we don't need
anything else for them. They declare their compatible and the i2c-hid
compatible, and they work great.
But some devices need a reset line. But the i2c-hid spec doesn't mention
a reset line at all. And some other devices need a reset line with a
different timing. etc... Relying purely on the i2c-hid driver means that
the driver needs to now the platform the device is on and the exact
device we have in front of us. i2c-hid provide a VID/PID through the
protocol, but we are still lacking information: in some cases, the
timing of the reset line for the same device differs depending on the
platform they run.
Having a device specific compatible means that we can make use of it
before we load i2c-hid. This is why we have i2c-hid-core and module
specifics on the side. Those extra module can do all the oddities they
want, like having 2 or 3 reset lines, but in the end they are using the
core i2c-hid once they are set up.
Think of it as a way to quirk the device upfront without polluting the
i2c-hid processing.
That allowed us to clean up the i2c-hid code by removing the non
standard regulators, reset lines, quirks that are device specific and
keep it closer to the spec.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: add AMD MicroBlaze binding
From: Michal Simek @ 2026-04-15 8:35 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ben Levinsky, andersson, mathieu.poirier
Cc: robh, krzk+dt, conor+dt, linux-remoteproc, devicetree,
linux-kernel, tanmay.shah
In-Reply-To: <f5cd25ae-712f-4d0d-b24e-6ca33501f15d@kernel.org>
On 4/15/26 10:24, Krzysztof Kozlowski wrote:
> On 15/04/2026 10:06, Michal Simek wrote:
>>
>>
>> On 4/15/26 09:07, Krzysztof Kozlowski wrote:
>>> On 15/04/2026 08:55, Michal Simek wrote:
>>>>>>
>>>>>> Does it make sense?
>>>>>
>>>>> Yes, drop from DT. No need for generic stuff. Or describe the hardware.
>>>>
>>>> You need to describe that connection to HW. GPIOs, memory location, etc.
>>>> It means there must be any description.
>>>
>>> No, you can write user-space driver or pass everything through SW nodes.
>>> No need for DT description.
>>
>> The firmware memory typically sits behind AXI-to-AXI bridges and
>>
>> interconnect switches. The bus topology varies between FPGA designs.
>>
>> DT ranges-based address translation is the standard way to describe
>>
>> this, and pushing it into userspace would just mean hardcoding what
>>
>> ranges already provides.
>>
>> I don't think SW nodes should be used here.
>>
>>>
>>> But if you want a DT description, then it must be for the specific
>>> hardware, since the hardware is not generic.
>>
>> But there is specific HW loaded. It is loaded at power up and don't change over
>> life cycle. What I am just saying that access to this fixed HW (in fpga) is
>> generic. At this stage memory and gpio only.
>>
>> What I was trying to say is that the hardware topology (memory window +
>>
>> reset GPIO) is the same regardless of the soft-core cpu (MicroBlaze,
>> RISC-V, etc.)/fpga, so naming it after the ISA architecture felt wrong to me
>>
>> too.
>>
>> When I look at other bindings. For example this one.
>> Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
>
> That's a subnode of other device. Not an independent device.
>
> Plus I dislike most of Qualcomm remoteproc bindings and find them way to
> downstreamish, written to match downstream approaches without respecting
> DT rules.
>
>>
>> the compatible describes the communication mechanism (FIFO-based G-Link), not
>> the specific processor behind it.
>>
>>
>>
>> Our case is similar the compatible describes the control mechanism firmware
>> loaded through a memory window, processor started via GPIO reset. What sits
>> behind that interface varies and is opaque to the binding.
>>
>>
>> Would something like "amd,mem-gpio-rproc" be acceptable, following the same
>> pattern where the compatible identifies the interface mechanism?
>
> Not for me. You have a very specific physical remote processor. That's
> what you write bindings for.
And we have it which is Microblaze with bram (block ram) which is mapped to host
CPU memory range which is going to be loaded by firmware and start by toggling
gpio.
I think what we only don't have is proper compatible string which will describe
this HW. If you don't like generic name we can describe it specifically for this
configuration.
amd,microblaze-mem-gpio-rproc for example without any generic fallback.
Or we could create a spec, design recommendation for this type of configuration
if that helps.
What do you suggest?
Thanks,
Michal
^ permalink raw reply
* [PATCH v2 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Jian Hu via B4 Relay @ 2026-04-15 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu
In-Reply-To: <20260415-clkmsr_a1_t7-v2-0-02b6314427e6@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Add the clock measure device to the T7 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7fe72c94ed62..cec2ea74850d 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -701,6 +701,11 @@ pwm_ao_cd: pwm@60000 {
status = "disabled";
};
+ clock-measurer@48000 {
+ compatible = "amlogic,t7-clk-measure";
+ reg = <0x0 0x48000 0x0 0x1c>;
+ };
+
sd_emmc_a: mmc@88000 {
compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
reg = <0x0 0x88000 0x0 0x800>;
--
2.47.1
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: meson: a1: Add clk measure support
From: Jian Hu via B4 Relay @ 2026-04-15 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu
In-Reply-To: <20260415-clkmsr_a1_t7-v2-0-02b6314427e6@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Add the clock measure device to the A1 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
index 348411411f3d..6f6a6145cba1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -576,6 +576,11 @@ saradc: adc@2c00 {
status = "disabled";
};
+ clock-measurer@3400 {
+ compatible = "amlogic,a1-clk-measure";
+ reg = <0x0 0x3400 0x0 0x1c>;
+ };
+
i2c1: i2c@5c00 {
compatible = "amlogic,meson-axg-i2c";
status = "disabled";
--
2.47.1
^ permalink raw reply related
* [PATCH v2 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Jian Hu via B4 Relay @ 2026-04-15 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu
In-Reply-To: <20260415-clkmsr_a1_t7-v2-0-02b6314427e6@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
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..8c4f3cc8c8ab 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 const struct meson_msr_id clk_msr_a1[] = {
+ CLK_MSR_ID(0, "tdmout_b_sclk"),
+ CLK_MSR_ID(1, "tdmout_a_sclk"),
+ CLK_MSR_ID(2, "tdmin_lb_sclk"),
+ CLK_MSR_ID(3, "tdmin_b_sclk"),
+ CLK_MSR_ID(4, "tdmin_a_sclk"),
+ CLK_MSR_ID(5, "vad"),
+ CLK_MSR_ID(6, "resamplea"),
+ CLK_MSR_ID(7, "pdm_sysclk"),
+ CLK_MSR_ID(8, "pdm_dclk"),
+ CLK_MSR_ID(9, "locker_out"),
+ CLK_MSR_ID(10, "locker_in"),
+ CLK_MSR_ID(11, "spdifin"),
+ CLK_MSR_ID(12, "tdmin_vad"),
+ CLK_MSR_ID(13, "au_adc"),
+ CLK_MSR_ID(14, "au_dac"),
+ CLK_MSR_ID(16, "spicc_a"),
+ CLK_MSR_ID(17, "spifc"),
+ CLK_MSR_ID(18, "sd_emmc_a"),
+ CLK_MSR_ID(19, "dmcx4"),
+ CLK_MSR_ID(20, "dmc"),
+ CLK_MSR_ID(21, "psram"),
+ CLK_MSR_ID(22, "cecb"),
+ CLK_MSR_ID(23, "ceca"),
+ CLK_MSR_ID(24, "ts"),
+ CLK_MSR_ID(25, "pwm_f"),
+ CLK_MSR_ID(26, "pwm_e"),
+ CLK_MSR_ID(27, "pwm_d"),
+ CLK_MSR_ID(28, "pwm_c"),
+ CLK_MSR_ID(29, "pwm_b"),
+ CLK_MSR_ID(30, "pwm_a"),
+ CLK_MSR_ID(31, "saradc"),
+ CLK_MSR_ID(32, "usb_bus"),
+ CLK_MSR_ID(33, "dsp_b"),
+ CLK_MSR_ID(34, "dsp_a"),
+ CLK_MSR_ID(35, "axi"),
+ CLK_MSR_ID(36, "sys"),
+ CLK_MSR_ID(40, "rng_ring_osc0"),
+ CLK_MSR_ID(41, "rng_ring_osc1"),
+ CLK_MSR_ID(42, "rng_ring_osc2"),
+ CLK_MSR_ID(43, "rng_ring_osc3"),
+ CLK_MSR_ID(44, "dds_out"),
+ CLK_MSR_ID(45, "cpu_clk_div16"),
+ CLK_MSR_ID(46, "gpio_msr"),
+ CLK_MSR_ID(50, "osc_ring_cpu0"),
+ CLK_MSR_ID(51, "osc_ring_cpu1"),
+ CLK_MSR_ID(54, "osc_ring_top0"),
+ CLK_MSR_ID(55, "osc_ring_top1"),
+ CLK_MSR_ID(56, "osc_ring_ddr"),
+ CLK_MSR_ID(57, "osc_ring_dmc"),
+ CLK_MSR_ID(58, "osc_ring_dspa"),
+ CLK_MSR_ID(59, "osc_ring_dspb"),
+ CLK_MSR_ID(60, "osc_ring_rama"),
+ CLK_MSR_ID(61, "osc_ring_ramb"),
+};
+
+static const struct meson_msr_id clk_msr_t7[] = {
+ CLK_MSR_ID(0, "sys"),
+ CLK_MSR_ID(1, "axi"),
+ CLK_MSR_ID(2, "rtc"),
+ CLK_MSR_ID(3, "dspa"),
+ CLK_MSR_ID(4, "dspb"),
+ CLK_MSR_ID(5, "mali"),
+ CLK_MSR_ID(6, "sys_cpu_clk_div16"),
+ CLK_MSR_ID(7, "ceca"),
+ CLK_MSR_ID(8, "cecb"),
+ CLK_MSR_ID(10, "fclk_div5"),
+ CLK_MSR_ID(11, "mpll0"),
+ CLK_MSR_ID(12, "mpll1"),
+ CLK_MSR_ID(13, "mpll2"),
+ CLK_MSR_ID(14, "mpll3"),
+ CLK_MSR_ID(15, "mpll_50m"),
+ CLK_MSR_ID(16, "pcie_inp"),
+ CLK_MSR_ID(17, "pcie_inn"),
+ CLK_MSR_ID(18, "mpll_test_out"),
+ CLK_MSR_ID(19, "hifi_pll"),
+ CLK_MSR_ID(20, "gp0_pll"),
+ CLK_MSR_ID(21, "gp1_pll"),
+ CLK_MSR_ID(22, "eth_mppll_50m"),
+ CLK_MSR_ID(23, "sys_pll_div16"),
+ CLK_MSR_ID(24, "ddr_dpll_pt"),
+ CLK_MSR_ID(25, "earcrx_pll"),
+ CLK_MSR_ID(26, "paie1_clk_inp"),
+ CLK_MSR_ID(27, "paie1_clk_inn"),
+ CLK_MSR_ID(28, "amlgdc"),
+ CLK_MSR_ID(29, "gdc"),
+ CLK_MSR_ID(30, "mod_eth_phy_ref"),
+ CLK_MSR_ID(31, "mod_eth_tx"),
+ CLK_MSR_ID(32, "eth_clk125Mhz"),
+ CLK_MSR_ID(33, "eth_clk_rmii"),
+ CLK_MSR_ID(34, "co_clkin_to_mac"),
+ CLK_MSR_ID(35, "mod_eth_rx_clk_rmii"),
+ CLK_MSR_ID(36, "co_rx"),
+ CLK_MSR_ID(37, "co_tx"),
+ CLK_MSR_ID(38, "eth_phy_rxclk"),
+ CLK_MSR_ID(39, "eth_phy_plltxclk"),
+ CLK_MSR_ID(40, "ephy_test"),
+ CLK_MSR_ID(41, "dsi_b_meas"),
+ CLK_MSR_ID(42, "hdmirx_apl"),
+ CLK_MSR_ID(43, "hdmirx_tmds"),
+ CLK_MSR_ID(44, "hdmirx_cable"),
+ CLK_MSR_ID(45, "hdmirx_apll_clk_audio"),
+ CLK_MSR_ID(46, "hdmirx_5m"),
+ CLK_MSR_ID(47, "hdmirx_2m"),
+ CLK_MSR_ID(48, "hdmirx_cfg"),
+ CLK_MSR_ID(49, "hdmirx_hdcp2x_eclk"),
+ CLK_MSR_ID(50, "vid_pll0_div"),
+ CLK_MSR_ID(51, "hdmi_vid_pll"),
+ CLK_MSR_ID(54, "vdac_clk"),
+ CLK_MSR_ID(55, "vpu_clk_buf"),
+ CLK_MSR_ID(56, "mod_tcon_clko"),
+ CLK_MSR_ID(57, "lcd_an_clk_ph2"),
+ CLK_MSR_ID(58, "lcd_an_clk_ph3"),
+ CLK_MSR_ID(59, "hdmi_tx_pixel"),
+ CLK_MSR_ID(60, "vdin_meas"),
+ CLK_MSR_ID(61, "vpu_clk"),
+ CLK_MSR_ID(62, "vpu_clkb"),
+ CLK_MSR_ID(63, "vpu_clkb_tmp"),
+ CLK_MSR_ID(64, "vpu_clkc"),
+ CLK_MSR_ID(65, "vid_lock"),
+ CLK_MSR_ID(66, "vapbclk"),
+ CLK_MSR_ID(67, "ge2d"),
+ CLK_MSR_ID(68, "aud_pll"),
+ CLK_MSR_ID(69, "aud_sck"),
+ CLK_MSR_ID(70, "dsi_a_meas"),
+ CLK_MSR_ID(72, "mipi_csi_phy"),
+ CLK_MSR_ID(73, "mipi_isp"),
+ CLK_MSR_ID(76, "hdmitx_tmds"),
+ CLK_MSR_ID(77, "hdmitx_sys"),
+ CLK_MSR_ID(78, "hdmitx_fe"),
+ CLK_MSR_ID(80, "hdmitx_prif"),
+ CLK_MSR_ID(81, "hdmitx_200m"),
+ CLK_MSR_ID(82, "hdmitx_aud"),
+ CLK_MSR_ID(83, "hdmitx_pnx"),
+ CLK_MSR_ID(84, "spicc5"),
+ CLK_MSR_ID(85, "spicc4"),
+ CLK_MSR_ID(86, "spicc3"),
+ CLK_MSR_ID(87, "spicc2"),
+ CLK_MSR_ID(93, "vdec"),
+ CLK_MSR_ID(94, "wave521_aclk"),
+ CLK_MSR_ID(95, "wave521_cclk"),
+ CLK_MSR_ID(96, "wave521_bclk"),
+ CLK_MSR_ID(97, "hcodec"),
+ CLK_MSR_ID(98, "hevcb"),
+ CLK_MSR_ID(99, "hevcf"),
+ CLK_MSR_ID(100, "hdmi_aud_pll"),
+ CLK_MSR_ID(101, "hdmi_acr_ref"),
+ CLK_MSR_ID(102, "hdmi_meter"),
+ CLK_MSR_ID(103, "hdmi_vid"),
+ CLK_MSR_ID(104, "hdmi_aud"),
+ CLK_MSR_ID(105, "hdmi_dsd"),
+ CLK_MSR_ID(108, "dsi1_phy"),
+ CLK_MSR_ID(109, "dsi0_phy"),
+ CLK_MSR_ID(110, "smartcard"),
+ CLK_MSR_ID(111, "sar_adc"),
+ CLK_MSR_ID(113, "sd_emmc_c"),
+ CLK_MSR_ID(114, "sd_emmc_b"),
+ CLK_MSR_ID(115, "sd_emmc_a"),
+ CLK_MSR_ID(116, "gpio_msr"),
+ CLK_MSR_ID(117, "spicc1"),
+ CLK_MSR_ID(118, "spicc0"),
+ CLK_MSR_ID(119, "anakin"),
+ CLK_MSR_ID(121, "ts_clk(temp sensor)"),
+ CLK_MSR_ID(122, "ts_a73"),
+ CLK_MSR_ID(123, "ts_a53"),
+ CLK_MSR_ID(124, "ts_nna"),
+ CLK_MSR_ID(130, "audio_vad"),
+ CLK_MSR_ID(131, "acodec_dac_clk_x128"),
+ CLK_MSR_ID(132, "audio_locker_in"),
+ CLK_MSR_ID(133, "audio_locker_out"),
+ CLK_MSR_ID(134, "audio_tdmout_c_sclk"),
+ CLK_MSR_ID(135, "audio_tdmout_b_sclk"),
+ CLK_MSR_ID(136, "audio_tdmout_a_sclk"),
+ CLK_MSR_ID(137, "audio_tdmin_lb_sclk"),
+ CLK_MSR_ID(138, "audio_tdmin_c_sclk"),
+ CLK_MSR_ID(139, "audio_tdmin_b_sclk"),
+ CLK_MSR_ID(140, "audio_tdmin_a_sclk"),
+ CLK_MSR_ID(141, "audio_resamplea"),
+ CLK_MSR_ID(142, "audio_pdm_sysclk"),
+ CLK_MSR_ID(143, "audio_spdifoutb_mst"),
+ CLK_MSR_ID(144, "audio_spdifout_mst"),
+ CLK_MSR_ID(145, "audio_spdifin_mst"),
+ CLK_MSR_ID(146, "audio_pdm_dclk"),
+ CLK_MSR_ID(147, "audio_resampleb"),
+ CLK_MSR_ID(148, "earcrx_pll_dmac"),
+ CLK_MSR_ID(156, "pwm_ao_h"),
+ CLK_MSR_ID(157, "pwm_ao_g"),
+ CLK_MSR_ID(158, "pwm_ao_f"),
+ CLK_MSR_ID(159, "pwm_ao_e"),
+ CLK_MSR_ID(160, "pwm_ao_d"),
+ CLK_MSR_ID(161, "pwm_ao_c"),
+ CLK_MSR_ID(162, "pwm_ao_b"),
+ CLK_MSR_ID(163, "pwm_ao_a"),
+ CLK_MSR_ID(164, "pwm_f"),
+ CLK_MSR_ID(165, "pwm_e"),
+ CLK_MSR_ID(166, "pwm_d"),
+ CLK_MSR_ID(167, "pwm_c"),
+ CLK_MSR_ID(168, "pwm_b"),
+ CLK_MSR_ID(169, "pwm_a"),
+ CLK_MSR_ID(170, "aclkm"),
+ CLK_MSR_ID(171, "mclk_pll"),
+ CLK_MSR_ID(172, "a73_sys_pll_div16"),
+ CLK_MSR_ID(173, "a73_cpu_clk_div16"),
+ CLK_MSR_ID(176, "rng_ring_0"),
+ CLK_MSR_ID(177, "rng_ring_1"),
+ CLK_MSR_ID(178, "rng_ring_2"),
+ CLK_MSR_ID(179, "rng_ring_3"),
+ CLK_MSR_ID(180, "am_ring_out0"),
+ CLK_MSR_ID(181, "am_ring_out1"),
+ CLK_MSR_ID(182, "am_ring_out2"),
+ CLK_MSR_ID(183, "am_ring_out3"),
+ CLK_MSR_ID(184, "am_ring_out4"),
+ CLK_MSR_ID(185, "am_ring_out5"),
+ CLK_MSR_ID(186, "am_ring_out6"),
+ CLK_MSR_ID(187, "am_ring_out7"),
+ CLK_MSR_ID(188, "am_ring_out8"),
+ CLK_MSR_ID(189, "am_ring_out9"),
+ CLK_MSR_ID(190, "am_ring_out10"),
+ CLK_MSR_ID(191, "am_ring_out11"),
+ CLK_MSR_ID(192, "am_ring_out12"),
+ CLK_MSR_ID(193, "am_ring_out13"),
+ CLK_MSR_ID(194, "am_ring_out14"),
+ CLK_MSR_ID(195, "am_ring_out15"),
+ CLK_MSR_ID(196, "am_ring_out16"),
+ CLK_MSR_ID(197, "am_ring_out17"),
+ CLK_MSR_ID(198, "am_ring_out18"),
+ CLK_MSR_ID(199, "am_ring_out19"),
+ CLK_MSR_ID(200, "mipi_csi_phy0"),
+ CLK_MSR_ID(201, "mipi_csi_phy1"),
+ CLK_MSR_ID(202, "mipi_csi_phy2"),
+ CLK_MSR_ID(203, "mipi_csi_phy3"),
+ CLK_MSR_ID(204, "vid_pll1_div"),
+ CLK_MSR_ID(205, "vid_pll2_div"),
+ CLK_MSR_ID(206, "am_ring_out20"),
+ CLK_MSR_ID(207, "am_ring_out21"),
+ CLK_MSR_ID(208, "am_ring_out22"),
+ CLK_MSR_ID(209, "am_ring_out23"),
+ CLK_MSR_ID(210, "am_ring_out24"),
+ CLK_MSR_ID(211, "am_ring_out25"),
+ CLK_MSR_ID(212, "am_ring_out26"),
+ CLK_MSR_ID(213, "am_ring_out27"),
+ CLK_MSR_ID(214, "am_ring_out28"),
+ CLK_MSR_ID(215, "am_ring_out29"),
+ CLK_MSR_ID(216, "am_ring_out30"),
+ CLK_MSR_ID(217, "am_ring_out31"),
+ CLK_MSR_ID(218, "am_ring_out32"),
+ CLK_MSR_ID(219, "enc0_if"),
+ CLK_MSR_ID(220, "enc2"),
+ CLK_MSR_ID(221, "enc1"),
+ CLK_MSR_ID(222, "enc0")
+};
+
static int meson_measure_id(struct meson_msr_id *clk_msr_id,
unsigned int duration)
{
@@ -1026,6 +1278,18 @@ static const struct meson_msr_data clk_msr_s4_data = {
.reg = &msr_reg_offset_v2,
};
+static const struct meson_msr_data clk_msr_a1_data = {
+ .msr_table = (void *)clk_msr_a1,
+ .msr_count = ARRAY_SIZE(clk_msr_a1),
+ .reg = &msr_reg_offset_v2,
+};
+
+static const struct meson_msr_data clk_msr_t7_data = {
+ .msr_table = (void *)clk_msr_t7,
+ .msr_count = ARRAY_SIZE(clk_msr_t7),
+ .reg = &msr_reg_offset_v2,
+};
+
static const struct of_device_id meson_msr_match_table[] = {
{
.compatible = "amlogic,meson-gx-clk-measure",
@@ -1059,6 +1323,14 @@ static const struct of_device_id meson_msr_match_table[] = {
.compatible = "amlogic,s4-clk-measure",
.data = &clk_msr_s4_data,
},
+ {
+ .compatible = "amlogic,a1-clk-measure",
+ .data = &clk_msr_a1_data,
+ },
+ {
+ .compatible = "amlogic,t7-clk-measure",
+ .data = &clk_msr_t7_data,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, meson_msr_match_table);
--
2.47.1
^ permalink raw reply related
* [PATCH v2 0/4] soc: amlogic: clk-measure: add A1 and T7 support
From: Jian Hu via B4 Relay @ 2026-04-15 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu
This series adds Amlogic clock measurement support for A1 and T7 SoCs,
including binding updates, driver additions, and device tree enablement.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
Changes in v2:
- Add const for a1 and t7 clock measure table.
- Use b4 to send this series.
- Link to v1: https://lore.kernel.org/all/20260410100329.3167482-1-jian.hu@amlogic.com
---
Jian Hu (4):
dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
soc: amlogic: clk-measure: Add A1 and T7 support
arm64: dts: meson: a1: Add clk measure support
arm64: dts: amlogic: t7: Add clk measure support
.../soc/amlogic/amlogic,meson-gx-clk-measure.yaml | 2 +
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 5 +
drivers/soc/amlogic/meson-clk-measure.c | 272 +++++++++++++++++++++
4 files changed, 284 insertions(+)
---
base-commit: 401e5c73eedde8225e87bd11c794b8409248ff41
change-id: 20260415-clkmsr_a1_t7-9820984d0af1
Best regards,
--
Jian Hu <jian.hu@amlogic.com>
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
From: Jian Hu via B4 Relay @ 2026-04-15 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Jian Hu
In-Reply-To: <20260415-clkmsr_a1_t7-v2-0-02b6314427e6@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Add the Amlogic A1 and T7 compatible for the clk-measurer IP.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
.../devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
index 39d4637c2d08..b1200e6940ac 100644
--- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
+++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
@@ -24,6 +24,8 @@ properties:
- amlogic,meson-sm1-clk-measure
- amlogic,c3-clk-measure
- amlogic,s4-clk-measure
+ - amlogic,a1-clk-measure
+ - amlogic,t7-clk-measure
reg:
maxItems: 1
--
2.47.1
^ permalink raw reply related
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Chen-Yu Tsai @ 2026-04-15 8:31 UTC (permalink / raw)
To: Andy Shevchenko, Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <ad4tJN27opdEooA7@ashevche-desk.local>
On Tue, Apr 14, 2026 at 8:03 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 14, 2026 at 06:29:02PM +0800, Chen-Yu Tsai wrote:
> > On Tue, Apr 14, 2026 at 4:28 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> > > > On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > > > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
>
> ...
>
> > > > > > > - Given that this connector actually represents two devices, how do I
> > > > > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > > > > Does wakeup-source even work at this point?
> > > > > >
> > > > > > You can't use the DT property since the devices are not described in DT
> > > > > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > > > > wakeup.
> > > >
> > > > I see. I think not being able to specify generic properties for the devices
> > > > on the connector is going to be a bit problematic.
> > >
> > > This is nature of the open-connectors, especially on the busses that are
> > > hotpluggable, like PCIe. We never know what is connected there _ahead_.
> >
> > I believe what you mean by "hotpluggable" is "user replaceable".
>
> From the OS perspective it's the same. From platform perspective
> there is a difference, granted.
Yes. I just wanted to clarify.
> > > In other words you can't describe in DT something that may not exist.
> >
> > But this is actually doable with the PCIe slot representation. The
> > properties are put in the device node for the slot. If no card is
> > actually inserted in the slot, then no device is created, and the
> > device node is left as not associated with anything.
>
> But you need to list all devices in the world if you want to support this
Why would I need to? The PCIe slot representation just describes a
PCIe bridge. Granted this might not be entirely correct, but it's
what we currently have.
And even then, there are properties like memory-region or wakeup-source
that are generic and aren't tied to specific devices.
> somehow. Yes, probably many of them (or majority) will be enumerated as is,
> but some may need an assistance via (dynamic) properties or similar mechanisms.
Even if we wanted to add dynamic properties, there is currently no proper
device node to attach them to.
> > It's just that for this new M.2 E-key connector, there aren't separate
> > nodes for each interface. And the system doesn't associate the device
> > node with the device, because it's no longer a child node of the
> > controller or hierarchy, but connected over the OF graph.
> >
> > Moving over to the E-key connector representation seems like one step
> > forward and one step backward in descriptive ability. We gain proper
> > power sequencing, but lose generic properties.
>
> The "key" is property of the connector. Hence if you have an idea what can be
> common for ALL "key":s, that's probably can be abstracted. Note, I'm not
> familiar with the connector framework in the Linux kernel, perhaps it's already
> that kind of abstraction.
I'm not arguing for a even more generic "M.2" connector. The "key" is
already described in the compatible. I'm saying we should have some way
of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
on the connector so further nodes or properties can be attached to them,
either with overlays or dynamically within the kernel. Right now the
are only described as individual ports, but we can't actually tie a
device to a OF graph port.
But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
UART-based BT bit part, Mani just had the driver create a device node
under the UART (by traversing the OF graph to find the UART). If that's
the desired way then the connector binding should mention it. And that
works for me. But I think it's messier and also we're missing an
opportunity to make the M.2 connector a standardized attachment point
for overlays.
Mani, could you also chime in a bit on what you envisioned?
(Added Luca from Bootlin to CC, as I think there are parallels to the
"Hotplug of Non-discoverable Hardware" work)
Thanks
ChenYu
> > The latter part is solvable, but we likely need child nodes under the
> > connector for the different interfaces. Properties that make sense for
> > one type might not make sense for another.
> >
> > P.S. We could also just add child device nodes under the controller to
> > put the generic properties, but that's splitting the description into
> > multiple parts. Let's not go there if at all possible.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: add AMD MicroBlaze binding
From: Krzysztof Kozlowski @ 2026-04-15 8:24 UTC (permalink / raw)
To: Michal Simek, Ben Levinsky, andersson, mathieu.poirier
Cc: robh, krzk+dt, conor+dt, linux-remoteproc, devicetree,
linux-kernel, tanmay.shah
In-Reply-To: <00aa7ec4-121b-430a-9b83-1430dfee2998@amd.com>
On 15/04/2026 10:06, Michal Simek wrote:
>
>
> On 4/15/26 09:07, Krzysztof Kozlowski wrote:
>> On 15/04/2026 08:55, Michal Simek wrote:
>>>>>
>>>>> Does it make sense?
>>>>
>>>> Yes, drop from DT. No need for generic stuff. Or describe the hardware.
>>>
>>> You need to describe that connection to HW. GPIOs, memory location, etc.
>>> It means there must be any description.
>>
>> No, you can write user-space driver or pass everything through SW nodes.
>> No need for DT description.
>
> The firmware memory typically sits behind AXI-to-AXI bridges and
>
> interconnect switches. The bus topology varies between FPGA designs.
>
> DT ranges-based address translation is the standard way to describe
>
> this, and pushing it into userspace would just mean hardcoding what
>
> ranges already provides.
>
> I don't think SW nodes should be used here.
>
>>
>> But if you want a DT description, then it must be for the specific
>> hardware, since the hardware is not generic.
>
> But there is specific HW loaded. It is loaded at power up and don't change over
> life cycle. What I am just saying that access to this fixed HW (in fpga) is
> generic. At this stage memory and gpio only.
>
> What I was trying to say is that the hardware topology (memory window +
>
> reset GPIO) is the same regardless of the soft-core cpu (MicroBlaze,
> RISC-V, etc.)/fpga, so naming it after the ISA architecture felt wrong to me
>
> too.
>
> When I look at other bindings. For example this one.
> Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
That's a subnode of other device. Not an independent device.
Plus I dislike most of Qualcomm remoteproc bindings and find them way to
downstreamish, written to match downstream approaches without respecting
DT rules.
>
> the compatible describes the communication mechanism (FIFO-based G-Link), not
> the specific processor behind it.
>
>
>
> Our case is similar the compatible describes the control mechanism firmware
> loaded through a memory window, processor started via GPIO reset. What sits
> behind that interface varies and is opaque to the binding.
>
>
> Would something like "amd,mem-gpio-rproc" be acceptable, following the same
> pattern where the compatible identifies the interface mechanism?
Not for me. You have a very specific physical remote processor. That's
what you write bindings for.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] docs: dt: writing-bindings: Extend compatible fallbacks guideline
From: Krzysztof Kozlowski @ 2026-04-15 8:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel
Cc: Krzysztof Kozlowski
Extend the guidelines when to use fallback compatibles to cover to
common review responses. Devices are most likely compatible and should
use fallbacks when having:
1. Compatible programming interface, meaning one is a subset, and Linux
device drivers can use the subset to correctly match/bind and still
operate with the subset features.
2. Device variant discovery through some means, like registers.
Devices are incompatible and fallback is not suitable when that
fallback cannot be used by the drivers to match/bind.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/writing-bindings.rst | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst
index 667816dd7d50..03e29e2d50af 100644
--- a/Documentation/devicetree/bindings/writing-bindings.rst
+++ b/Documentation/devicetree/bindings/writing-bindings.rst
@@ -53,7 +53,12 @@ Properties
- DON'T use wildcards or device-family names in compatible strings.
- DO use fallback compatibles when devices are the same as or a superset of
- prior implementations.
+ prior implementations. Fallback compatibles are applicable especially
+ when sharing a programming interface or when able to discover the
+ variants.
+
+ - DON'T add fake fallback compatibles when software cannot use such to match
+ and bind to a device, and still operate correctly.
- DO add new compatibles in case there are new features or bugs.
--
2.51.0
^ permalink raw reply related
* [PATCH v4 6/7] PCI: intel-gw: Move driver atu base assignment to probe function
From: Florian Eckert @ 2026-04-15 8:01 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260415-pcie-intel-gw-v4-0-ad45d2418c8e@dev.tdt.de>
If no ATU resource is defined in the devicetree, then driver´s default
value '0x300000' [1] is set. This is done during probing in the function
'dw_pcie_get_resources()' [2] by dwc core.
The driver overwrites this again when its own init callback
'pp->ops->init()' [3] function 'intel_pcie_host_setup()' [4] is called.
This is done, because the 'atu_base' offset for this IP is '0xC0000'rather
than '0x300000'.
callstack:
intel_pcie_probe()
dw_pcie_host_init()
dw_pcie_host_get_resources()
dw_pcie_get_resources() [2]
pp->ops->init = intel_pcie_rc_init() [3]
intel_pcie_host_setup() [4]
However, this is a problem because, the callback 'pp->ops->init' is called
after 'dw_pcie_get_resources()' in dwc core (see callstack). The 'atu_base'
must be set before, so that this value is not set by dwc core. Therefore
the assignment of 'atu_base' is moved to driver´s probe function.
While we’re at it, the change also adds the option to load ATU information
from the device tree. For reasons of backwards compatibility, this is not
mandatory. If ‘atu’ is not specified in the devicetree, then driver’s
default value is still used and set in driver´s probe function. If the 'atu'
resource is present in the devicetree, then dwc core loads it via the
function 'dw_pcie_get_resources()' and not in the driver´s probe function.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-designware.h?h=v7.0#n292
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-designware.c?h=v7.0#n150
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-designware-host.c?h=v7.0#n588
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-intel-gw.c?h=v7.0#n301
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index afd933050c92ee31c477e0b1738ab1136bdcfbf6..59b11e45944e199aac0f599f96d6cc90e2104708 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -310,8 +310,6 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
goto clk_err;
}
- pci->atu_base = pci->dbi_base + 0xC0000;
-
ret = phy_init(pcie->phy);
if (ret)
goto phy_err;
@@ -395,6 +393,7 @@ static int intel_pcie_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct intel_pcie *pcie;
struct dw_pcie_rp *pp;
+ struct resource *res;
struct dw_pcie *pci;
int ret;
@@ -419,6 +418,31 @@ static int intel_pcie_probe(struct platform_device *pdev)
pci->ops = &intel_pcie_ops;
pp->ops = &intel_pcie_dw_ops;
+ /*
+ * If the 'atu' resource is not available in the devicetree,
+ * then use the driver default value for backward compatibility.
+ * The 'atu' should always be set in the devicetree, as this is
+ * hardware specific setting that should not be defined in the
+ * source.
+ */
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
+ if (!res) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
+ pci->dbi_base = devm_pci_remap_cfg_resource(pci->dev, res);
+ if (IS_ERR(pci->dbi_base))
+ return PTR_ERR(pci->dbi_base);
+ pci->dbi_phys_addr = res->start;
+ pci->atu_base = devm_ioremap(dev, res->start + 0xC0000, SZ_4K);
+ if (!pci->atu_base) {
+ dev_err(dev, "failed to remap ATU space\n");
+ return -ENOMEM;
+
+ }
+ pci->atu_size = SZ_4K;
+ pci->atu_phys_addr = res->start + 0xC0000;
+ dev_warn(dev, "devicetree ATU resource is missing; driver`s default value is being used\n");
+ }
+
ret = dw_pcie_host_init(pp);
if (ret) {
dev_err(dev, "Cannot initialize host\n");
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v7 5/6] iio: adc: ad4691: add oversampling support
From: Nuno Sá @ 2026-04-15 8:20 UTC (permalink / raw)
To: David Lechner
Cc: Sabau, Radu bogdan, Jonathan Cameron, Lars-Peter Clausen,
Hennerich, Michael, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <b352b76c-8047-4a1f-8b83-db8144466c36@baylibre.com>
On Tue, Apr 14, 2026 at 10:02:31AM -0500, David Lechner wrote:
> On 4/14/26 9:25 AM, Sabau, Radu bogdan wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jonathan Cameron <jic23@kernel.org>
> >> Sent: Sunday, April 12, 2026 8:58 PM
> >> To: David Lechner <dlechner@baylibre.com>
> >> Cc: Sabau, Radu bogdan <Radu.Sabau@analog.com>; Lars-Peter Clausen
> >> <lars@metafoo.de>; Hennerich, Michael <Michael.Hennerich@analog.com>;
> >> Sa, Nuno <Nuno.Sa@analog.com>; Andy Shevchenko <andy@kernel.org>;
> >> Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> >> Conor Dooley <conor+dt@kernel.org>; Uwe Kleine-König
> >> <ukleinek@kernel.org>; Liam Girdwood <lgirdwood@gmail.com>; Mark Brown
> >> <broonie@kernel.org>; Linus Walleij <linusw@kernel.org>; Bartosz
> >> Golaszewski <brgl@kernel.org>; Philipp Zabel <p.zabel@pengutronix.de>;
> >> Jonathan Corbet <corbet@lwn.net>; Shuah Khan
> >> <skhan@linuxfoundation.org>; linux-iio@vger.kernel.org;
> >> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> >> pwm@vger.kernel.org; linux-gpio@vger.kernel.org; linux-doc@vger.kernel.org
> >> Subject: Re: [PATCH v7 5/6] iio: adc: ad4691: add oversampling support
> >>
> >> [External]
> >>
> >> On Fri, 10 Apr 2026 16:15:20 -0500
> >> David Lechner <dlechner@baylibre.com> wrote:
> >>
> >>> On 4/9/26 10:28 AM, Radu Sabau via B4 Relay wrote:
> >>>> From: Radu Sabau <radu.sabau@analog.com>
> >>>>
> >>>> Add per-channel oversampling ratio (OSR) support for CNV burst mode.
> >>>> The accumulator depth register (ACC_DEPTH_IN) is programmed with the
> >>>> selected OSR at buffer enable time and before each single-shot read.
> >>>>
> >>>> Supported OSR values: 1, 2, 4, 8, 16, 32.
> >>>>
> >>>> Introduce AD4691_MANUAL_CHANNEL() for manual mode channels,
> >> which do
> >>>> not expose the oversampling ratio attribute since OSR is not applicable
> >>>> in that mode. A separate manual_channels array is added to
> >>>> struct ad4691_channel_info and selected at probe time; offload paths
> >>>> reuse the same arrays with num_channels capping access before the soft
> >>>> timestamp entry.
> >>>>
> >>>> The reported sampling frequency accounts for the active OSR:
> >>>> effective_freq = oscillator_freq / osr
> >>>
> >>> Technically, the way this is implemented is fine according to IIO ABI
> >>> rules. Writing any attribute can cause others to change. It does
> >>> introduce a potential pitfall though. Currently, changing the OSR will
> >>> change the sampling frequency, so you have to always write
> >> oversampling_ratio
> >>> first, then write sampling_frequency to get what you asked for. If you want
> >>> to change the OSR and keep the same sample rate, you still have to write
> >> both
> >>> attributes again.
> >>>
> >>> In other drivers, I've implemented it so that the requested sampling
> >> frequency
> >>> is stored any you always get the closest sampling frequency available based
> >> on
> >>> the oversampling ratio. This way, it doesn't matter which order you write
> >>> the attributes. In that case, the actual periodic trigger source isn't set up
> >>> until we actually start sampling.
> >>>
> >> Agreed. This is more intuitive. Now generally the userspace should
> >> be sanity checking the value anyway as limitations may mean the new
> >> sampling frequency is not particularly close to the original one but
> >> at least it increases the chances of getting the expected value somewhat!
> >>
> >> So to me this is a nice useability improvement given the code to implement
> >> it tends not to be too complex.
> >>
> >
> > Hi David, Jonathan,
> >
> > What I understand from this is that the osr should be taken into account when writing
> > the sampling frequency as well, right? Here's what I understand:
> >
> > If the user wants a 125kHz freq with 4 OSR, then when internal osc will be written
> > to 500kHz before single-shot read, buffer preenable/postenable.
> > However, if the user wants a 500kHz frequency with 4 OSR, that would mean a 2MHz
> > Internal osc freq, which is impossible.
>
> It is up to the user to request something that is legal. They should know this
> from reading the datasheet.
>
> >
> > More than this, if the OSR is 32 the maximum effective rate would be 31250, so 25kHz
> > would make it the closes available one. If the user would select 1MHz from the available
> > list it would be weird I would say. So perhaps a solution for this is to display the avail list
> > depending on the set OSR value.
>
> Yes, the available list should reflect the current state of any other attributes
> that affect it.
IMO, the above makes total sense to me.
- Nuno Sá
>
> >
> > Linking the two together is perhaps wrong to begin with from my end, since in this
> > driver's case, the per-channel sampling frequency is controlled by the internal oscillator
> > which has static available values. So perhaps sampling frequency should be separate, and
> > OSR separate as well, which would make everything cleaner.
> >
> > Indeed, the effective rate is changed by OSR, but perhaps that is something the user
> > should be aware of, since the sampling frequency is the rate at which the channel samples
> > (1 sample per period) and OSR is how many times the channel samples upon a final sample
> > is to be read. The user already has to take this into account when setting the buffer
> > sampling frequency, so it would make sense to take this into account here too.
>
> We can't change the definition of the IIO ABI just to make one driver simpler
> to implement. The OSR and sample rate can't be completely independent.
>
> If you want to leave it the way it is currently implemented though, that is fine.
>
> >
> > Please let me know you thoughts on this,
> > Radu
>
^ permalink raw reply
* [PATCH v4 4/7] PCI: intel-gw: Enable clock before phy init
From: Florian Eckert @ 2026-04-15 8:01 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260415-pcie-intel-gw-v4-0-ad45d2418c8e@dev.tdt.de>
To ensure that the boot sequence is correct, the dwc pcie core clock must
be switched on before phy init call [1]. This changes are based on patched
kernel sources of the MaxLinear SDK.
The reason why the MaxLinear SDK is used as a reference here is, that this
pcie dwc IP is used in the URX851 and URX850 SoC. This SoC was originally
developed by Intel when they acquired Lantiq’s home networking division in
2015 [2]. In 2020 the home network division was sold to MaxLinear [3].
Since then, this SoC belongs to MaxLinear. They use their own SDK,
which runs on kernel version '5.15.x'.
[1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544
[2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home
[3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index e88b8243cc41c607c39e4d58c4dcd8c8c082e8b0..6d9499d954674a26a74bff56b7fb5759767424c0 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -291,13 +291,9 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
intel_pcie_core_rst_assert(pcie);
intel_pcie_device_rst_assert(pcie);
-
- ret = phy_init(pcie->phy);
- if (ret)
- return ret;
-
intel_pcie_core_rst_deassert(pcie);
+ /* Controller clock must be provided earlier than PHY */
ret = clk_prepare_enable(pcie->core_clk);
if (ret) {
dev_err(pcie->pci.dev, "Core clock enable failed: %d\n", ret);
@@ -306,13 +302,17 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
pci->atu_base = pci->dbi_base + 0xC0000;
+ ret = phy_init(pcie->phy);
+ if (ret)
+ goto phy_err;
+
intel_pcie_ltssm_disable(pcie);
intel_pcie_link_setup(pcie);
intel_pcie_init_n_fts(pci);
ret = dw_pcie_setup_rc(&pci->pp);
if (ret)
- goto app_init_err;
+ goto err;
dw_pcie_upconfig_setup(pci);
@@ -321,17 +321,18 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
ret = dw_pcie_wait_for_link(pci);
if (ret)
- goto app_init_err;
+ goto err;
intel_pcie_core_irq_enable(pcie);
return 0;
-app_init_err:
+err:
+ phy_exit(pcie->phy);
+phy_err:
clk_disable_unprepare(pcie->core_clk);
clk_err:
intel_pcie_core_rst_assert(pcie);
- phy_exit(pcie->phy);
return ret;
}
--
2.47.3
^ permalink raw reply related
* [PATCH v4 3/7] PCI: intel-gw: Move interrupt enable to own function
From: Florian Eckert @ 2026-04-15 8:01 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260415-pcie-intel-gw-v4-0-ad45d2418c8e@dev.tdt.de>
To improve the readability of the code, move the interrupt enable
instructions to a separate function. That is already done for the disable
interrupt instruction.
In addition, all pending interrupts are cleared and disabled, just as this
is done in the disable function 'intel_pcie_core_irq_disable()'. After
that, all relevant interrupts are enabled again. The 'PCIE_APP_IRNEN'
definition contains all the relevant interrupts that are of interest.
This change is also done in the MaxLinear SDK [1]. As I unfortunately
don’t have any documentation for this IP core, I suspect that the
intention is to set the IP core for interrupt handling to a specific
state. Perhaps the problem is that the IP core did not reinitialize the
interrupt register properly after a power cycle.
In my view, it can’t do any harm to switch the interrupt off and then on
again to set them to a specific state.
The reason why the MaxLinear SDK is used as a reference here is, that this
pcie dwc IP is used in the URX851 and URX850 SoC. This SoC was originally
developed by Intel when they acquired Lantiq’s home networking division in
2015 [2]. In 2020 the home network division was sold to MaxLinear [3].
Since then, this SoC belongs to MaxLinear. They use their own SDK,
which runs on kernel version '5.15.x'.
[1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L431
[2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home
[3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index 80d1607c46cbbb1e274b37a0bb9377a877678f5d..e88b8243cc41c607c39e4d58c4dcd8c8c082e8b0 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -195,6 +195,13 @@ static void intel_pcie_device_rst_deassert(struct intel_pcie *pcie)
gpiod_set_value_cansleep(pcie->reset_gpio, 0);
}
+static void intel_pcie_core_irq_enable(struct intel_pcie *pcie)
+{
+ pcie_app_wr(pcie, PCIE_APP_IRNEN, 0);
+ pcie_app_wr(pcie, PCIE_APP_IRNCR, PCIE_APP_IRN_INT);
+ pcie_app_wr(pcie, PCIE_APP_IRNEN, PCIE_APP_IRN_INT);
+}
+
static void intel_pcie_core_irq_disable(struct intel_pcie *pcie)
{
pcie_app_wr(pcie, PCIE_APP_IRNEN, 0);
@@ -316,9 +323,7 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
if (ret)
goto app_init_err;
- /* Enable integrated interrupts */
- pcie_app_wr_mask(pcie, PCIE_APP_IRNEN, PCIE_APP_IRN_INT,
- PCIE_APP_IRN_INT);
+ intel_pcie_core_irq_enable(pcie);
return 0;
--
2.47.3
^ permalink raw reply related
* [PATCH v4 7/7] dt-bindings: PCI: intel,lgm-pcie: Add atu resource
From: Florian Eckert @ 2026-04-15 8:01 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260415-pcie-intel-gw-v4-0-ad45d2418c8e@dev.tdt.de>
The 'atu' information is already set in the dwc core, if it is specified
in the devicetree. The driver uses its own default, if not set in the
devicetree. This information is hardware specific and should therefore be
maintained in the devicetree rather than in the source.
To be backward compatible, this field is not mandatory. If 'atu'
resource is not specified in the devicetree, the driver’s default value
is used.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
index 54e2890ae6314ac6847fc23f49440d05d66d87d4..9b7a8ef77585677841c7064c5001110bc2b65db1 100644
--- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
@@ -27,16 +27,19 @@ properties:
- const: snps,dw-pcie
reg:
+ minItems: 3
items:
- description: Controller control and status registers.
- description: PCIe configuration registers.
- description: Controller application registers.
+ - description: Internal Address Translation Unit (iATU) registers.
reg-names:
items:
- const: dbi
- const: config
- const: app
+ - const: atu
ranges:
maxItems: 1
@@ -95,8 +98,9 @@ examples:
#size-cells = <2>;
reg = <0xd0e00000 0x1000>,
<0xd2000000 0x800000>,
- <0xd0a41000 0x1000>;
- reg-names = "dbi", "config", "app";
+ <0xd0a41000 0x1000>,
+ <0xd0ec0000 0x1000>;
+ reg-names = "dbi", config", "app", "atu";
linux,pci-domain = <0>;
max-link-speed = <4>;
bus-range = <0x00 0x08>;
--
2.47.3
^ permalink raw reply related
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