* Re: [PATCH v2 4/6] ASoC: renesas: fsi: refactor clock initialization
From: Bui Duc Phuc @ 2026-04-15 9:24 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: <87wly87rgg.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
> Ah, OK.
> So the patch 1) moves fsi_clk_init() and 2) update it.
> It is including many features in 1 patch. Please separate it.
>
> One note here is that /* clock function */ is for all fsi_clk_xxx(),
> so don't move it.
Thank you for your guidance.
I will split this into two separate patches accordingly.
Best regards,
Phuc
On Wed, Apr 15, 2026 at 11:55 AM Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
>
> Hi Bui
>
> > > I have mentioned in previous mail to just move fsi_clk_init(), but why do
> > > you need to move it ? It works without any issue without moving function,
> > > I guess ?
> >
> > I moved fsi_clk_init() below the two functions fsi_clk_set_rate_cpg
> > and fsi_clk_set_rate_external because, inside fsi_clk_init(),
> > I assign these functions to clock->set_rate. Moving the function was
> > necessary to avoid compilation errors.
>
> Ah, OK.
> So the patch 1) moves fsi_clk_init() and 2) update it.
> It is including many features in 1 patch. Please separate it.
>
> One note here is that /* clock function */ is for all fsi_clk_xxx(),
> so don't move it.
>
> > > And why you need to call fsi_clk_init() twice ?
> > The FSI controller has two independent ports (Port A and Port B).
> > Each port requires its own clock resource initialization and configuration.
>
> Ah, yes indeed.
>
>
> Thank you for your help !!
>
> Best regards
> ---
> Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v4 7/7] dt-bindings: PCI: intel,lgm-pcie: Add atu resource
From: Rob Herring (Arm) @ 2026-04-15 9:24 UTC (permalink / raw)
To: Florian Eckert
Cc: Krzysztof Kozlowski, Eckert.Florian, ms, Bjorn Helgaas,
Manivannan Sadhasivam, Conor Dooley, Johan Hovold, linux-kernel,
devicetree, Ajay Agarwal, Sajid Dalvi, linux-pci,
Krzysztof Wilczyński, Lorenzo Pieralisi
In-Reply-To: <20260415-pcie-intel-gw-v4-7-ad45d2418c8e@dev.tdt.de>
On Wed, 15 Apr 2026 10:01:53 +0200, Florian Eckert wrote:
> 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(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Lexical error: Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dts:28.30-36 Unexpected 'config'
Error: Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dts:28.30-36 syntax error
FATAL ERROR: Unable to parse input tree
make[2]: *** [scripts/Makefile.dtbs:140: Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1601: dt_binding_check] Error 2
make: *** [Makefile:248: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260415-pcie-intel-gw-v4-7-ad45d2418c8e@dev.tdt.de
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 08/10] ARM: dts: qcom: msm8960: add SMSM & SPS
From: Konrad Dybcio @ 2026-04-15 9:21 UTC (permalink / raw)
To: linux, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <20260414-msm8960-wifi-v1-8-007fda9d6134@smankusors.com>
On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>
> Add the Shared Memory State Machine node to coordinate state transitions
> between the Applications processor and the Riva subsystem.
>
> Tested-by: Rudraksha Gupta <guptarud@gmail.com>
> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* RE: [PATCH 4/5] media: dt-bindings: add NXP i.MX95 compatible string
From: G.N. Zhou (OSS) @ 2026-04-15 9:21 UTC (permalink / raw)
To: Krzysztof Kozlowski, G.N. Zhou (OSS)
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
In-Reply-To: <20260415-glaring-premium-nuthatch-ce00fc@quoll>
Hi Krzysztof Kozlowski
Thanks for your review.
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Wednesday, April 15, 2026 4:10 PM
> To: G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> Cc: Michael Riesch <michael.riesch@collabora.com>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Heiko Stuebner
> <heiko@sntech.de>; Laurent Pinchart <laurent.pinchart@ideasonboard.com>;
> Frank Li <frank.li@nxp.com>; linux-media@vger.kernel.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; imx@lists.linux.dev; linux-
> arm-kernel@lists.infradead.org; linux-rockchip@lists.infradead.org
> Subject: Re: [PATCH 4/5] media: dt-bindings: add NXP i.MX95 compatible string
>
> On Wed, Apr 15, 2026 at 11:46:55AM +0800, Guoniu Zhou wrote:
> > The i.MX95 CSI-2 controller is nearly identical to i.MX93, with the
> > only difference being the use of IDI (Image Data Interface) instead of
> > IPI (Image Pixel Interface). The binding constraints are otherwise the
> > same.
>
> Nearly identical with some difference really, really suggests they are
> compatible. Express compatibility or explain why they are not compatible
> (difference between IDI and IPI unfortunately does not help me).
You're right that they are very similar. The key difference between IDI and IPI
is in the software interface:
- IPI (Image Pixel Interface) on i.MX93 requires software configuration through
a set of registers to enable the interface and configure data routing.
- IDI (Image Data Interface) on i.MX95 is software transparent - it requires no
register configuration and the data routing is handled automatically by hardware.
Because of this difference in register layout and initialization requirements,
they cannot share the same compatible string. The driver needs to know which
interface is present
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/6] ASoC: renesas: fsi: Fix trigger stop ordering
From: Bui Duc Phuc @ 2026-04-15 9:20 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: <87se8ypeq1.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
> This patch should appearing much earlier.
Thanks for your guidance.
I will reorder the patch series to place this fix earlier in the sequence.
Best regards,
Phuc
On Tue, Apr 14, 2026 at 7:28 AM Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
>
> Hi
>
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > Reorder calls to execute fsi_stream_stop() before fsi_hw_shutdown().
> > This ensures that all register accesses are completed before the clock is
> > disabled, preventing the system hang observed on r8a7740.
> >
> > Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> > ---
>
> This patch should appearing much earlier.
>
> > sound/soc/renesas/fsi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
> > index 109e06b5f32d..9df3e91ac79c 100644
> > --- a/sound/soc/renesas/fsi.c
> > +++ b/sound/soc/renesas/fsi.c
> > @@ -1606,9 +1606,9 @@ static int fsi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
> > ret = fsi_stream_transfer(io);
> > break;
> > case SNDRV_PCM_TRIGGER_STOP:
> > + fsi_stream_stop(fsi, io);
> > if (!ret)
> > ret = fsi_hw_shutdown(fsi, dai->dev);
> > - fsi_stream_stop(fsi, io);
> > fsi_stream_quit(fsi, io);
> > break;
> > }
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: glymur: Mark USB SS1 and SS2 as role-switch capable
From: Konrad Dybcio @ 2026-04-15 9:18 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
In-Reply-To: <20260415-dts-qcom-glymur-usb-role-switch-fix-v1-1-409e1a257f1f@oss.qualcomm.com>
On 4/15/26 9:52 AM, Abel Vesa wrote:
> Like USB SS0, the USB SS1 and SS2 controllers on Glymur also support
> USB role switching.
>
> Describe this by adding the 'usb-role-switch' property to both controllers.
>
> Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
With the patches in this order, applying just this one will break UCSI,
see:
https://lore.kernel.org/linux-usb/8fabc049-7fdf-498a-a3ef-6f2570d510c8@oss.qualcomm.com/T/#u
(if you want to make the change in the dwc3 driver, feel free to,
otherwise it'll be somewhere on my infinite todolist)
Konrad
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: pm660: add thermal monitor
From: Konrad Dybcio @ 2026-04-15 9:15 UTC (permalink / raw)
To: Richard Acayan
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Amit Kucheria, Thara Gopinath,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Stephen Boyd, Dmitry Baryshkov, linux-arm-msm, devicetree,
linux-pm
In-Reply-To: <aaXKyIJQA9SFqt41@rdacayan>
On 3/3/26 3:25 AM, Richard Acayan wrote:
> On Tue, Feb 10, 2026 at 10:59:20AM +0100, Konrad Dybcio wrote:
>> On 2/10/26 3:18 AM, Richard Acayan wrote:
>>> The thermal monitor is used to monitor arbitrary ADC-based thermal
>>> sensors. It is suitable for use in thermal zones. Add support for it in
>>> PM660.
>>>
>>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/pm660.dtsi | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/pm660.dtsi b/arch/arm64/boot/dts/qcom/pm660.dtsi
>>> index 156b2ddff0dc..7cedf6980b34 100644
>>> --- a/arch/arm64/boot/dts/qcom/pm660.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/pm660.dtsi
>>> @@ -197,6 +197,16 @@ channel@85 {
>>> };
>>> };
>>>
>>> + pm660_adc_tm: adc-tm@3400 {
>>> + compatible = "qcom,spmi-adc-tm-hc";
>>> + reg = <0x3400>;
>>> + interrupts = <0x0 0x34 0x0 IRQ_TYPE_EDGE_RISING>;
>>> + #thermal-sensor-cells = <1>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + status = "disabled";
>>
>> Can we enable it by default?
>
> This is for the ADC thermal monitor, and not the ADC itself. I don't see
> the need to allocate channels just so this can be enabled by default,
> since the thermal monitor's purpose is mostly to send interrupts when
> the ADC values go above or below a certain threshold.
Sorry, this fell through the cracks
I see your argument, but at the same time, there are channels that are
always present (e.g. VPH_PWR) and any way to reduce the boilerplate is
welcome
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur: Drop RPMh CXO clocks from QMP PHYs
From: Krzysztof Kozlowski @ 2026-04-15 9:13 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, Dmitry Baryshkov
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260414-dts-glymur-drop-rpmh-cxo-clk-from-qmpphys-v1-1-ab12d77c4aec@oss.qualcomm.com>
On 14/04/2026 19:05, 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/
Thanks for fixing this, appreciated.
Bjorn,
That's a fix for v7.1-rcX, so please consider it for the fixes for
current (v7.1) release.
Best regards,
Krzysztof
^ permalink raw reply
* 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
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