* [PATCH v1 0/2] Add DeepComputing FML13V05 board dts
From: Sandie Cao @ 2026-03-31 3:44 UTC (permalink / raw)
To: Conor Dooley
Cc: Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski, Yixun Lan,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heinrich Schuchardt,
Troy Mitchell, Michael Opdenacker, Guodong Xu, Hendrik Hamerlinck,
Yangyu Chen, spacemit, linux-riscv, devicetree, linux-kernel,
Sandie Cao
This series updates Device Tree related files to introduce the
FML13V05 board from DeepComputing, which incorporates a Spacemit
K3 SoC. This board is designed for use on the Framework Laptop 13
Chassis, which has (Framework) SKU FRANHQ0001.
The series is based on riscv-dt-for-next.
sandiecao (2):
dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
.../devicetree/bindings/riscv/spacemit.yaml | 1 +
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 28 +++++++++++++++++++
3 files changed, 30 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
base-commit: 4a1739c30fc66a59450c1f78923f94607e786882
--
2.43.0
^ permalink raw reply
* [PATCH v1 2/2] riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
From: Sandie Cao @ 2026-03-31 3:46 UTC (permalink / raw)
To: Conor Dooley
Cc: Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski, Yixun Lan,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heinrich Schuchardt,
Troy Mitchell, Michael Opdenacker, Guodong Xu, Hendrik Hamerlinck,
Yangyu Chen, spacemit, linux-riscv, devicetree, linux-kernel,
sandiecao
In-Reply-To: <20260331034423.67142-1-sandie.cao@deepcomputing.io>
From: sandiecao <sandie.cao@deepcomputing.io>
The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
which has (Framework) SKU FRANHQ0001.
The FML13V05 board features:
- SpacemiT K3 RISC-V SoC
- LPDDR5 16GB or 32GB
- eMMC 32GB ~128GB (Optional)
- UFS 3.1 256G (Optional)
- QSPI Flash
- MicroSD Slot
- PCIe-based Wi-Fi
- 4 USB-C Ports
- Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
- Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
- Port 3 & 4: USB 3.2 Gen 1
This minimal device tree enables booting into a serial console with UART
output.
Signed-off-by: sandiecao <sandie.cao@deepcomputing.io>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
---
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 28 +++++++++++++++++++
2 files changed, 29 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
index 7e2b87702571..acb993c452ba 100644
--- a/arch/riscv/boot/dts/spacemit/Makefile
+++ b/arch/riscv/boot/dts/spacemit/Makefile
@@ -4,4 +4,5 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
+dtb-$(CONFIG_ARCH_SPACEMIT) += k3-deepcomputing-fml13v05.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
diff --git a/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
new file mode 100644
index 000000000000..2343ae3acc2d
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2024 DeepComputing (HK) Limited
+ */
+
+#include "k3.dtsi"
+
+/ {
+ model = "DeepComputing FML13V05";
+ compatible = "deepcomputing,fml13v05", "spacemit,k3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ memory@100000000 {
+ device_type = "memory";
+ reg = <0x1 0x00000000 0x4 0x00000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH V7] dt-bindings: misc: qcom,fastrpc: Add compatible for Glymur
From: Sibi Sankar @ 2026-03-31 3:21 UTC (permalink / raw)
To: gregkh, robh, srini, amahesh, krzk+dt, conor+dt, andersson,
konradybcio
Cc: linux-arm-msm, dri-devel, devicetree, linux-kernel,
Krzysztof Kozlowski
Document compatible for Qualcomm Glymur fastrpc which is fully compatible
with Qualcomm Kaanapali fastrpc.
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Greg if you are still picking up patches can you please this
as well.
Changes in v7:
- Rebased on the latest Linux-next
- Split patch series so that Greg can pick this one up so that
the dt changes can be picked up by Bjorn.
- Link to v6: https://lore.kernel.org/lkml/20260325035338.1393287-1-sibi.sankar@oss.qualcomm.com/
Changes in v6:
- Pick the audio series up. [Srini]
- Pickup Rbs from the list.
- Rebase on top of the lastest linux-next.
- Fix up address size and other misc fixes. [Konrad]
- Fix the ordering the various audio nodes. [Sibi]
- Link to v5: https://lore.kernel.org/lkml/20260313120814.1312410-1-sibi.sankar@oss.qualcomm.com/
- Link to v0 audio series: https://lore.kernel.org/lkml/20260311124230.2241781-1-srinivas.kandagatla@oss.qualcomm.com/
Changes in v5:
- Fix commit messages (patch 1/2) to accurately describe compatibility [Krzysztof]
- Link to v4: https://lore.kernel.org/lkml/20260310033617.3108675-1-sibi.sankar@oss.qualcomm.com/
Changes in v4:
- Fix SID used in ADSP/CDSP for correctness [Konrad]
- Link to v3: https://lore.kernel.org/lkml/20260129001358.770053-1-sibi.sankar@oss.qualcomm.com/
Changes in v3:
- A few variants of the SoC are expected to run Linux at EL1 hence the
iommus properties are left optional.
- Add fastrpc bindings and nodes.
- Link to v2: https://lore.kernel.org/all/20251029-knp-remoteproc-v2-0-6c81993b52ea@oss.qualcomm.com/
Changes in v2:
- Combined into Kaanapali series since they are fully compatible.
- Link to v1: https://lore.kernel.org/all/20250924183726.509202-1-sibi.sankar@oss.qualcomm.com/
.../devicetree/bindings/misc/qcom,fastrpc.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
index d8e47db677cc..ca830dd06de2 100644
--- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
+++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
@@ -18,9 +18,14 @@ description: |
properties:
compatible:
- enum:
- - qcom,kaanapali-fastrpc
- - qcom,fastrpc
+ oneOf:
+ - enum:
+ - qcom,kaanapali-fastrpc
+ - qcom,fastrpc
+ - items:
+ - enum:
+ - qcom,glymur-fastrpc
+ - const: qcom,kaanapali-fastrpc
label:
enum:
base-commit: cf7c3c02fdd0dfccf4d6611714273dcb538af2cb
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 0/4] drm/panel: simple: add Waveshare LCD panels
From: Marek Vasut @ 2026-03-31 3:11 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, dri-devel,
devicetree, linux-kernel
In-Reply-To: <CAO9ioeUFfjr3Dh58TQ8EB7H3NgUX04N24OXXYijiigRZ8Kkh0A@mail.gmail.com>
On 3/31/26 3:22 AM, Dmitry Baryshkov wrote:
> On Tue, 31 Mar 2026 at 00:07, Marek Vasut <marek.vasut@mailbox.org> wrote:
>>
>> On 3/30/26 3:25 PM, Dmitry Baryshkov wrote:
>>> Waveshare have a serie of DSI panel kits with the DPI or LVDS panel
>>> being attached to the DSI2DPI or DSI2LVDS bridge. Commit 80b0eb11f8e0
>>> ("dt-bindings: display: panel: Add waveshare DPI panel support")
>>> described two of them in the bindings and commit 46be11b678e0
>>> ("drm/panel: simple: Add Waveshare 13.3" panel support") added
>>> definitions for one of those panels. Add support for the rest of them.
>> Can we by any chance use the icn6211 driver in tree for this ?
>
> As far as I can see, no. Waveshare kits have an extra ASIC in front of
> ICN6211 / ICN6202, which completely hides all programming. So far the
> interface is really better expressed by the waveshare,dsi2dpi /
> dsi2lvds: this way, even if they decide to change the actual
> implementation (like they did for DPI -> LVDS), we won't have to worry
> about it for as long as their programming interface remains stable.
Hmmm, I've seen this before, but I don't think this is extra ASIC. The
ICN6211 pulls its register settings from EEPROM, does it not ?
But no matter how the ICN loads its configuration, this is not waveshare
specific. I have another display from another manufacturer here which is
also ICN6211 that is preprogrammed. Can we instead have some generic-dsi
display , because I don't think these proprogrammed DSI displays are
going to be only ICN6211 based and only made by waveshare ?
^ permalink raw reply
* Re: [PATCH 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms
From: Chaoyi Chen @ 2026-03-31 3:16 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Damon Ding,
Dmitry Baryshkov, Alexey Charkov, dri-devel, linux-rockchip,
linux-kernel, devicetree, kernel
In-Reply-To: <acsoT_i-LfoMoIy_@venus>
Hello Sebastian,
On 3/31/2026 10:09 AM, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Mar 31, 2026 at 09:18:32AM +0800, Chaoyi Chen wrote:
>> On 3/30/2026 7:50 PM, Sebastian Reichel wrote:
>>> On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote:
>>>>> There are two parts, which possibly need some discussion:
>>>>>
>>>>> 1. I added a dedicated bridge callback for out-of-band hotplug events,
>>>>> which is separate from the hotplug_notify. I have a feeling, that
>>>>> there might be a better solution, but haven't found it.
>>>>
>>>> Could you explain what an out-of-band hotplug event is?
>>>>
>>>> Can't the drivers/usb/typec/altmodes/displayport.c respond to these
>>>> hot-plug events? Thank you.
>>>
>>> That is what generates the out-of-band hotplug event in the first
>>> place via drm_connector_oob_hotplug_event(). The oob in that call
>>> means out of band.
>>>
>>> If you look at that function it calls oob_hotplug_event() callback
>>> on the DRM connector, which is then implemented by
>>> drm_bridge_connector_oob_hotplug_event(). This function calls uses
>>> the normal hpd handling (shared by in-band and out-of-band) and I'm
>>> patching it, so that the bridges are aware of hpd explicitly being
>>> provided out-of-band.
>>>
>>
>> Ah, I'm actually more concerned with the specific types of events.
>> For example, the "explicitly" provided HPD you mentioned here.
>> Isn't drm_connector_oob_hotplug_event able to provide those?
>>
>> I assume you’re looking for an oob event that is propagated along the
>> bridge chain, rather than at the connector. Is that so? Thank you.
>
> The connector has a dedicated hotplug oob event callback, but I obviously
> need the event on the bridge, since the DP controller is implemented as
> bridge. The existing infrastructure propages it down to the bridge chain
> via drm_bridge_hpd_notify(), which can be received by the DP controller
> via the .hpd_notify callback in struct drm_bridge_funcs.
>
> The problem is, that this receives events for in-band AND
> out-of-band hotplug events. That's why I added a new bridge
> callback, which hooks into the existing framework, but only delivers
> out-of-band events and no in-band events.
>
How to distinguish between in-band and out-of-band events? In your patch4:
@@ -180,6 +180,12 @@ static void drm_bridge_connector_oob_hotplug_event(struct drm_connector *connect
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
+ /* Notify all bridges in the pipeline of hotplug events. */
+ drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
+ if (bridge->funcs->oob_notify)
+ bridge->funcs->oob_notify(bridge, connector, status);
+ }
+
drm_bridge_connector_handle_hpd(bridge_connector, status);
Here, drm_bridge_connector_handle_hpd() will eventually call:
drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
if (bridge->funcs->hpd_notify)
bridge->funcs->hpd_notify(bridge, connector, status);
}
Therefore, for the bridge chain, you will call hpd_notify and
oob_notify separately.
This looks redundant, how do you distinguish between them?
> The problem with receiving in-band in addition to out-of-band is
> that the out-of-band signal should set the hotplug pin accordingly,
> but the in-band detection also checks the actual DP link. If the OOB
> hotplug signal says "nothing plugged", the hotplug pin should be
> forced off, but if the DP link detection fails, the hotplug pin
> should not be force disabled, as that makes any further detection
> tries useless.
>
--
Best,
Chaoyi
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: bridge: ldb: Require reg property only for i.MX6SX/8MP LDBs
From: Marek Vasut @ 2026-03-30 23:22 UTC (permalink / raw)
To: Marco Felsch
Cc: Liu Ying, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Marek Vasut, Laurentiu Palcu, dri-devel, devicetree, linux-kernel
In-Reply-To: <excxf6kxwx44kepc22smvvnirptc4kxpubioxoto7nqleqhoiq@ymch4y6dd5n5>
On 3/30/26 8:29 AM, Marco Felsch wrote:
Hello Marco,
>>> On 26-03-29, Liu Ying wrote:
>>>> LDB's parent device could be a syscon which doesn't allow a reg property
>>>> to be present in it's child devices, e.g., NXP i.MX93 Media blk-ctrl
>>>> has a child device NXP i.MX93 Parallel Display Format Configuration(PDFC)
>>>> without a reg property(LDB is also a child device of the Media blk-ctrl).
>>>> To make the LDB schema be able to describe LDBs without the reg property
>>>> like i.MX93 LDB, require the reg property only for i.MX6SX/8MP LDBs.
>>>
>>> NACK, we want to describe the HW and from HW PoV the LDB is and was
>>> always part of a syscon. This is the case for all SoCs i.MX6SX/8MP/93.
>>>
>>>> Fixes: 8aa2f0ac08d3 ("dt-bindings: display: bridge: ldb: Add check for reg and reg-names")
>>>
>>> Therefore I would just revert this patch completely.
>> Last time, I pointed out the hardware is part of syscon, but as a subnode
>> and therefore with reg properties. What is the problem there ?
>
> To quote the DT spec here:
>
> """
> The reg property describes the address of the device’s resources within
> the address space defined by its parent bus.
> """
That parent bus would be the syscon, wouldn't it.
> The parent bus is not the parent iomuxc (i.MX6X) nor the blk-ctrl
> (i.MX8MP/93) device. Therefore this is wrong IMHO and should be dropped.
How so ? What is the parent bus ?
^ permalink raw reply
* Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Liu Ying @ 2026-03-31 3:03 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Martyn Welch,
Oleksij Rempel, Peng Fan, Philippe Schenker, Richard Hu,
Shengjiu Wang, Stefan Eichenberger, Vitor Soares
In-Reply-To: <DHG8G8FMXA6C.U6LU563OZ8NR@bootlin.com>
Hi Luca,
On Mon, Mar 30, 2026 at 05:47:23PM +0200, Luca Ceresoli wrote:
> Hello Liu,
>
> On Mon Mar 30, 2026 at 5:02 AM CEST, Liu Ying wrote:
[...]
>>>>> + fixup-hdmi-connector {
>>>>> + compatible = "hdmi-connector";
>>>>> + label = "HDMI";
>>>>> + type = "a";
>>>>
>>>> What if a board uses another type?
>>>
>>> For boards affected by this patch, currently the connector is created by
>>> dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
>>> difference.
>>
>> Yes, that's from driver's PoV. However, userspace may get the type
>> from /sys/firmware/devicetree/base/fixup-hdmi-connector/type and use it
>> to do something.
>
> I'd say this is incorrect, the device tree is not an API for that. The
> connector type might be known to the driver by other means (ACPI, DP MST,
> whatever). So I think this is a non-problem.
I just feel that it's not great to report potentially wrong type to users
through the above sys node ...
>
> If userspace needs to know the connector type, that should come from the
> ioctl (DRM_IOCTL_MODE_GETCONNECTOR perhaps).
>
>> Maybe, that's trivial.
>
> Not sure I got what you mean here, sorry. What are you referring to?
... with the above potentially wrong type being said, I think maybe this
drawback is not a big deal and could be ignored. Sorry for not being
clear in my last reply.
>
>>> OTOH how can a common module know the specific connector?
>>
>> Hmm, maybe add a module parameter or let users set the type through Kconfig
>
> I'm afraid none of this would work for distribution kernels, where who
> configures the distribution has no idea on how many different hardware it
> will run.
>
>> or even define an unknown type to honestly tell users that we don't know it?
>
> This sounds like a potentially valid idea, even though I'm not fully
> convinced. Also I suspect it would be a pretty large change, and also
> adding "unknown type" in the device tree seems not compliant with the rule
> that DT describes the hardware (not the lack of info about the hardware).
>
> But definitely it's not needed for this specific case, because:
>
> * with current code, every imx8mp-hdmi-tx usage adds a type-A connector [0]
> * with this patch the correct type will be created when described in DT,
> and type-A will be used only as a fallback when the DT is lacking
>
> So after the patch we'd do sometimes better, never worse in this respect.
Well, kind of a bit worse since the sys node exposes a potentially wrong type.
>
> Based on the above I'm sending v2 soon, but don't hesitate in following up
> in case I may be missing something (this topic is tricky).
Agreed, it's tricky.
>
> [0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
>
>>> Boards with a different connector should describe the connector in the
>>> device tree, if they need to instantiate the exact type.
>
> I think this is the only valid solution. It's very easy to do, nothing new
> to invent.
>
> Maybe on top of that we could add a warning when the overlay is applied,
> e.g. "imx8mp-hdmi-tx used without a connector described in device tree;
> adding a type A connector as a fallback; please add a valid description to
> your device tree".
I'd say this doesn't sound a bad idea but I hope the message is clear and
short.
> Maybe pointing to a TODO entry in the documentation.
To parameterize the HDMI connector type? If so, I'm okay with that.
>
> What do you think about this?
>
> Thanks again for your careful review!
Thanks for your patches! Appreciated.
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com/
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 2/2] pwm: meson: Add support for Amlogic S7
From: Xianwei Zhao @ 2026-03-31 2:48 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic
In-Reply-To: <CAFBinCD-4dwp7pmM_GHK_N1kag_5VBZbP9VAwQOxcyg6aquj3w@mail.gmail.com>
Hi Martin,
Thanks for your review.
On 2026/3/31 05:44, Martin Blumenstingl wrote:
> Hi Xianwei Zhao,
>
> On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>
>> Add support for Amlogic S7 PWM. Amlogic S7 different from the
>> previous SoCs, a controller includes one pwm, at the same time,
>> the controller has only one input clock source.
>>
>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
>> ---
>> drivers/pwm/pwm-meson.c | 32 ++++++++++++++++++++++++++++++--
>> 1 file changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
>> index 8c6bf3d49753..3d16694e254e 100644
>> --- a/drivers/pwm/pwm-meson.c
>> +++ b/drivers/pwm/pwm-meson.c
>> @@ -113,6 +113,7 @@ struct meson_pwm_data {
>> int (*channels_init)(struct pwm_chip *chip);
>> bool has_constant;
>> bool has_polarity;
>> + bool single_pwm;
> At first I wasn't sure about this and thought we should replace it
> with a num_pwms (or similar) variable.
> However, I think it will be hard to add a third (or even more)
> channels to the PWM controller (not just from driver perspective but
> also from hardware perspective). So I think this is good enough as the
> choice will only be 1 or 2.
> > [...]
This is not a third channel added here.
Compared with the previous controller having two channels, here the
control has only one channel. It's equivalent to the first channel
before, while the second channel is reserved.
>> +static const struct meson_pwm_data pwm_s7_data = {
>> + .channels_init = meson_pwm_init_channels_s7,
> I think you can use .channels_init = meson_pwm_init_channels_s4, if
> you change the code inside that function from:
> for (i = 0; i < MESON_NUM_PWMS; i++) {
> to:
> for (i = 0; i < chip->npwm; i++) {
>
> [...]
The method you suggested was exactly what I did in the first version,
but after my subsequent optimization, it's what you see now.
Since initialization only involves obtaining the clock, I modify the
code less in this way and the logic is also simpler.
>> @@ -650,9 +674,13 @@ static int meson_pwm_probe(struct platform_device *pdev)
>> {
>> struct pwm_chip *chip;
>> struct meson_pwm *meson;
>> + const struct meson_pwm_data *pdata = of_device_get_match_data(&pdev->dev);
>> int err;
>>
>> - chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
>> + if (pdata->single_pwm)
>> + chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*meson));
>> + else
>> + chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
> I don't think this code is too bad for now.
> However, I'm wondering if you want to make "channels" from struct
> meson_pwm a flexible array member in a future patch. In that case it
> will be helpful to have an "unsigned int npwm = pdata->single_pwm ? 1
> : MESON_NUM_PWMS;" (or similar) variable to future-proof your code.
> What do you think?
I considered this, but chose the current implementation. I will switch
to your suggestion in the next version.
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Peng Fan @ 2026-03-31 2:49 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <acqjS440STRl2sK2@p14s>
On Mon, Mar 30, 2026 at 10:22:35AM -0600, Mathieu Poirier wrote:
>On Fri, Mar 27, 2026 at 10:42:03AM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>>
>> Cortex-M[7,33] processors use a fixed reset vector table format:
>>
>> 0x00 Initial SP value
>> 0x04 Reset vector
>> 0x08 NMI
>> 0x0C ...
>> ...
>> IRQ[n]
>>
>> In ELF images, the corresponding layout is:
>>
>> reset_vectors: --> hardware reset address
>> .word __stack_end__
>> .word Reset_Handler
>> .word NMI_Handler
>> .word HardFault_Handler
>> ...
>> .word UART_IRQHandler
>> .word SPI_IRQHandler
>> ...
>>
>> Reset_Handler: --> ELF entry point address
>> ...
>>
>> The hardware fetches the first two words from reset_vectors and populates
>> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
>> Reset_Handler.
>>
>> However, the ELF entry point does not always match the hardware reset
>> address. For example, on i.MX94 CM33S:
>>
>> ELF entry point: 0x0ffc211d
>> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
>>
>
>But why? Why can't the ELF image be set to the right reset base?
Per zephyr general link script[1]:
ENTRY(CONFIG_KERNEL_ENTRY)
CONFIG_KERNEL_ENTRY(_start) is the first instruction that Cortex-M starts to
execute.
config KERNEL_ENTRY
string "Kernel entry symbol"
default "__start"
help
Code entry symbol, to be set at linking phase.
The hardware reset base is different: it is the address where the hardware
fetches the initial MSP and PC values from the vector table. Hardware uses
this base to initialize the stack pointer and program counter, and only then
does the Cortex‑M begin execution at the reset handler.
Aligning the ELF entry point with the hardware reset base on Cortex‑M systems
is possible, but it comes with several risks.
1, Semantic mismatch (ELF vs. hardware behavior)
2, Debuggers may attempt to set breakpoints or start execution at the entry symbol
[1] https://elixir.bootlin.com/zephyr/v4.4.0-rc1/source/include/zephyr/arch/arm/cortex_m/scripts/linker.ld#L103
Regards
Peng.
>
^ permalink raw reply
* Re: [PATCH 2/3] clk: qcom: Add support for GXCLK for Milos
From: Alexander Koskovich @ 2026-03-31 2:37 UTC (permalink / raw)
To: Luca Weiss
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel
In-Reply-To: <20260306-milos-gxclkctl-v1-2-00b09ee159a7@fairphone.com>
On Friday, March 6th, 2026 at 8:56 AM, Luca Weiss <luca.weiss@fairphone.com> wrote:
> GXCLKCTL (Graphics GX Clock Controller) is a block dedicated to managing
> clocks for the GPU subsystem on GX power domain. The GX clock controller
> driver manages only the GX GDSC and the rest of the resources of the
> controller are managed by the firmware.
>
> We can use the existing kaanapali driver for Milos as well since the
> GX_CLKCTL_GX_GDSC supported by the Linux driver requires the same
> configuration.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> drivers/clk/qcom/Makefile | 2 +-
> drivers/clk/qcom/gxclkctl-kaanapali.c | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 90ea21c3b7cf..155830140d26 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -182,7 +182,7 @@ obj-$(CONFIG_SM_GPUCC_8350) += gpucc-sm8350.o
> obj-$(CONFIG_SM_GPUCC_8450) += gpucc-sm8450.o
> obj-$(CONFIG_SM_GPUCC_8550) += gpucc-sm8550.o
> obj-$(CONFIG_SM_GPUCC_8650) += gpucc-sm8650.o
> -obj-$(CONFIG_SM_GPUCC_MILOS) += gpucc-milos.o
> +obj-$(CONFIG_SM_GPUCC_MILOS) += gpucc-milos.o gxclkctl-kaanapali.o
> obj-$(CONFIG_SM_LPASSCC_6115) += lpasscc-sm6115.o
> obj-$(CONFIG_SM_TCSRCC_8550) += tcsrcc-sm8550.o
> obj-$(CONFIG_SM_TCSRCC_8650) += tcsrcc-sm8650.o
> diff --git a/drivers/clk/qcom/gxclkctl-kaanapali.c b/drivers/clk/qcom/gxclkctl-kaanapali.c
> index 3ee512f34967..d3899420d6f2 100644
> --- a/drivers/clk/qcom/gxclkctl-kaanapali.c
> +++ b/drivers/clk/qcom/gxclkctl-kaanapali.c
> @@ -54,6 +54,7 @@ static const struct qcom_cc_desc gx_clkctl_kaanapali_desc = {
> static const struct of_device_id gx_clkctl_kaanapali_match_table[] = {
> { .compatible = "qcom,glymur-gxclkctl" },
> { .compatible = "qcom,kaanapali-gxclkctl" },
> + { .compatible = "qcom,milos-gxclkctl" },
> { }
> };
> MODULE_DEVICE_TABLE(of, gx_clkctl_kaanapali_match_table);
>
> --
> 2.53.0
>
Was running into gx_clkctl_gx_gdsc being stuck on when GPU was doing runtime pm
and it seems like this GDSC requires GPU_CC_GX_AHB_FF_CLK to be enabled. Though
it is already in gpu_cc_milos_critical_cbcrs, the GMU firmware appears to be
disabling it.
Relevant downstream change:
https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/3c1f31518edb7b094b9b9285287ba49a5c9196d8
>
>
^ permalink raw reply
* [PATCH v4 7/7] arm64: tegra: Add PWM controllers on Tegra264
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Tegra264 has a number of PWM controllers that are similar but
incompatible with those found on earlier chips.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[mperttunen: Adjust commit message]
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 72 ++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 7644a41d5f72..13fd04068016 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3336,6 +3336,18 @@ i2c3: i2c@c610000 {
status = "disabled";
};
+ pwm4: pwm@c6a0000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc6a0000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM4>;
+ resets = <&bpmp TEGRA264_RESET_PWM4>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
pmc: pmc@c800000 {
compatible = "nvidia,tegra264-pmc";
reg = <0x0 0x0c800000 0x0 0x100000>,
@@ -3538,6 +3550,66 @@ i2c16: i2c@c430000 {
status = "disabled";
};
+ pwm2: pwm@c5e0000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc5e0000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM2>;
+ resets = <&bpmp TEGRA264_RESET_PWM2>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
+ pwm3: pwm@c5f0000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc5f0000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM3>;
+ resets = <&bpmp TEGRA264_RESET_PWM3>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
+ pwm5: pwm@c600000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc600000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM5>;
+ resets = <&bpmp TEGRA264_RESET_PWM5>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
+ pwm9: pwm@c610000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc610000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM9>;
+ resets = <&bpmp TEGRA264_RESET_PWM9>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
+ pwm10: pwm@c620000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc620000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM10>;
+ resets = <&bpmp TEGRA264_RESET_PWM10>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
i2c0: i2c@c630000 {
compatible = "nvidia,tegra264-i2c";
reg = <0x00 0x0c630000 0x0 0x10000>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 6/7] pwm: tegra: Add support for Tegra264
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
Tegra264 changes the register layout to accommodate wider fields
for duty and scale, and adds configurable depth which will be
supported in a later patch.
Add SoC data and update top comment to describe register layout
in more detail.
Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 75 ++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 61 insertions(+), 14 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index d7968521fbfd..c9d30724e339 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -7,22 +7,60 @@
* Copyright (c) 2010-2020, NVIDIA Corporation.
* Based on arch/arm/plat-mxc/pwm.c by Sascha Hauer <s.hauer@pengutronix.de>
*
- * Overview of Tegra Pulse Width Modulator Register:
- * 1. 13-bit: Frequency division (SCALE)
- * 2. 8-bit : Pulse division (DUTY)
- * 3. 1-bit : Enable bit
+ * Overview of Tegra Pulse Width Modulator Register
+ * CSR_0 of Tegra20, Tegra186, and Tegra194:
+ * +-------+-------+-----------------------------------------------------------+
+ * | Bit | Field | Description |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 31 | ENB | Enable Pulse width modulator. |
+ * | | | 0 = DISABLE, 1 = ENABLE. |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 30:16 | PWM_0 | Pulse width that needs to be programmed. |
+ * | | | 0 = Always low. |
+ * | | | 1 = 1 / 256 pulse high. |
+ * | | | 2 = 2 / 256 pulse high. |
+ * | | | N = N / 256 pulse high. |
+ * | | | Only 8 bits are usable [23:16]. |
+ * | | | Bit[24] can be programmed to 1 to achieve 100% duty |
+ * | | | cycle. In this case the other bits [23:16] are set to |
+ * | | | don’t care. |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 12:0 | PFM_0 | Frequency divider that needs to be programmed, also known |
+ * | | | as SCALE. Division by (1 + PFM_0). |
+ * +-------+-------+-----------------------------------------------------------+
*
- * The PWM clock frequency is divided by 256 before subdividing it based
- * on the programmable frequency division value to generate the required
- * frequency for PWM output. The maximum output frequency that can be
- * achieved is (max rate of source clock) / 256.
- * e.g. if source clock rate is 408 MHz, maximum output frequency can be:
- * 408 MHz/256 = 1.6 MHz.
- * This 1.6 MHz frequency can further be divided using SCALE value in PWM.
+ * CSR_0 of Tegra264:
+ * +-------+-------+-----------------------------------------------------------+
+ * | Bit | Field | Description |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 31:16 | PWM_0 | Pulse width that needs to be programmed. |
+ * | | | 0 = Always low. |
+ * | | | 1 = 1 / (1 + CSR_1.DEPTH) pulse high. |
+ * | | | 2 = 2 / (1 + CSR_1.DEPTH) pulse high. |
+ * | | | N = N / (1 + CSR_1.DEPTH) pulse high. |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 15:0 | PFM_0 | Frequency divider that needs to be programmed, also known |
+ * | | | as SCALE. Division by (1 + PFM_0). |
+ * +-------+-------+-----------------------------------------------------------+
+ *
+ * CSR_1 of Tegra264:
+ * +-------+-------+-----------------------------------------------------------+
+ * | Bit | Field | Description |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 31 | ENB | Enable Pulse width modulator. |
+ * | | | 0 = DISABLE, 1 = ENABLE. |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 30:15 | DEPTH | Depth for pulse width modulator. This controls the pulse |
+ * | | | time generated. Division by (1 + CSR_1.DEPTH). |
+ * +-------+-------+-----------------------------------------------------------+
*
- * PWM pulse width: 8 bits are usable [23:16] for varying pulse width.
- * To achieve 100% duty cycle, program Bit [24] of this register to
- * 1’b1. In which case the other bits [23:16] are set to don't care.
+ * The PWM clock frequency is divided by DEPTH = (1 + CSR_1.DEPTH) before subdividing it
+ * based on the programmable frequency division value to generate the required frequency
+ * for PWM output. DEPTH is fixed to 256 before Tegra264. The maximum output frequency
+ * that can be achieved is (max rate of source clock) / DEPTH.
+ * e.g. if source clock rate is 408 MHz, and DEPTH = 256, maximum output frequency can be:
+ * 408 MHz / 256 ~= 1.6 MHz.
+ * This 1.6 MHz frequency can further be divided using SCALE value in PWM.
*
* Limitations:
* - When PWM is disabled, the output is driven to inactive.
@@ -56,6 +94,7 @@
#define PWM_SCALE_SHIFT 0
#define PWM_CSR_0 0
+#define PWM_CSR_1 4
#define PWM_DEPTH 256
@@ -418,10 +457,18 @@ static const struct tegra_pwm_soc tegra186_pwm_soc = {
.scale_width = 13,
};
+static const struct tegra_pwm_soc tegra264_pwm_soc = {
+ .num_channels = 1,
+ .enable_reg = PWM_CSR_1,
+ .duty_width = 16,
+ .scale_width = 16,
+};
+
static const struct of_device_id tegra_pwm_of_match[] = {
{ .compatible = "nvidia,tegra20-pwm", .data = &tegra20_pwm_soc },
{ .compatible = "nvidia,tegra186-pwm", .data = &tegra186_pwm_soc },
{ .compatible = "nvidia,tegra194-pwm", .data = &tegra186_pwm_soc },
+ { .compatible = "nvidia,tegra264-pwm", .data = &tegra264_pwm_soc },
{ }
};
MODULE_DEVICE_TABLE(of, tegra_pwm_of_match);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 5/7] pwm: tegra: Parametrize duty and scale field widths
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang,
Thierry Reding, Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
Tegra264 has wider fields for the duty and scale register fields.
Parameterize the driver in preparation. The depth value also
becomes disconnected from the width of the duty field, so define
it separately.
Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index b925ef914411..d7968521fbfd 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -52,16 +52,19 @@
#include <soc/tegra/common.h>
#define PWM_ENABLE (1 << 31)
-#define PWM_DUTY_WIDTH 8
#define PWM_DUTY_SHIFT 16
-#define PWM_SCALE_WIDTH 13
#define PWM_SCALE_SHIFT 0
#define PWM_CSR_0 0
+#define PWM_DEPTH 256
+
struct tegra_pwm_soc {
unsigned int num_channels;
unsigned int enable_reg;
+
+ unsigned int duty_width;
+ unsigned int scale_width;
};
struct tegra_pwm_chip {
@@ -106,22 +109,22 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
/*
* Convert from duty_ns / period_ns to a fixed number of duty ticks
- * per (1 << PWM_DUTY_WIDTH) cycles and make sure to round to the
+ * per PWM_DEPTH cycles and make sure to round to the
* nearest integer during division.
*/
- c *= (1 << PWM_DUTY_WIDTH);
+ c *= PWM_DEPTH;
c = DIV_ROUND_CLOSEST_ULL(c, period_ns);
val = (u32)c << PWM_DUTY_SHIFT;
/*
- * min period = max clock limit >> PWM_DUTY_WIDTH
+ * min period = max clock limit / PWM_DEPTH
*/
if (period_ns < pc->min_period_ns)
return -EINVAL;
/*
- * Compute the prescaler value for which (1 << PWM_DUTY_WIDTH)
+ * Compute the prescaler value for which PWM_DEPTH
* cycles at the PWM clock rate will take period_ns nanoseconds.
*
* num_channels: If single instance of PWM controller has multiple
@@ -135,7 +138,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
*/
if (pc->soc->num_channels == 1) {
/*
- * Rate is multiplied with 2^PWM_DUTY_WIDTH so that it matches
+ * Rate is multiplied with PWM_DEPTH so that it matches
* with the maximum possible rate that the controller can
* provide. Any further lower value can be derived by setting
* PFM bits[0:12].
@@ -145,7 +148,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
* source clock rate as required_clk_rate, PWM controller will
* be able to configure the requested period.
*/
- required_clk_rate = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC << PWM_DUTY_WIDTH,
+ required_clk_rate = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * PWM_DEPTH,
period_ns);
if (required_clk_rate > clk_round_rate(pc->clk, required_clk_rate))
@@ -169,7 +172,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
/* Consider precision in PWM_SCALE_WIDTH rate calculation */
rate = mul_u64_u64_div_u64(pc->clk_rate, period_ns,
- (u64)NSEC_PER_SEC << PWM_DUTY_WIDTH);
+ (u64)NSEC_PER_SEC * PWM_DEPTH);
/*
* Since the actual PWM divider is the register's frequency divider
@@ -185,7 +188,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
* Make sure that the rate will fit in the register's frequency
* divider field.
*/
- if (rate >> PWM_SCALE_WIDTH)
+ if (rate >> pc->soc->scale_width)
return -EINVAL;
val |= rate << PWM_SCALE_SHIFT;
@@ -324,7 +327,7 @@ static int tegra_pwm_probe(struct platform_device *pdev)
/* Set minimum limit of PWM period for the IP */
pc->min_period_ns =
- (NSEC_PER_SEC / (pc->clk_rate >> PWM_DUTY_WIDTH)) + 1;
+ (NSEC_PER_SEC / (pc->clk_rate / PWM_DEPTH)) + 1;
pc->rst = devm_reset_control_get_exclusive(&pdev->dev, "pwm");
if (IS_ERR(pc->rst)) {
@@ -404,11 +407,15 @@ static int __maybe_unused tegra_pwm_runtime_resume(struct device *dev)
static const struct tegra_pwm_soc tegra20_pwm_soc = {
.num_channels = 4,
.enable_reg = PWM_CSR_0,
+ .duty_width = 8,
+ .scale_width = 13,
};
static const struct tegra_pwm_soc tegra186_pwm_soc = {
.num_channels = 1,
.enable_reg = PWM_CSR_0,
+ .duty_width = 8,
+ .scale_width = 13,
};
static const struct of_device_id tegra_pwm_of_match[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v4 4/7] pwm: tegra: Parametrize enable register offset
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
On Tegra264, the PWM enablement bit is not located at the base address
of the PWM controller. Hence, introduce an enablement offset field in
the tegra_pwm_soc structure to describe the offset of the register.
Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index 358c81cea05b..b925ef914411 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -61,6 +61,7 @@
struct tegra_pwm_soc {
unsigned int num_channels;
+ unsigned int enable_reg;
};
struct tegra_pwm_chip {
@@ -197,8 +198,9 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
err = pm_runtime_resume_and_get(pwmchip_parent(chip));
if (err)
return err;
- } else
+ } else if (pc->soc->enable_reg == PWM_CSR_0) {
val |= PWM_ENABLE;
+ }
pwm_writel(pwm, PWM_CSR_0, val);
@@ -213,6 +215,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
static int tegra_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
int rc = 0;
u32 val;
@@ -220,20 +223,22 @@ static int tegra_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
if (rc)
return rc;
- val = pwm_readl(pwm, PWM_CSR_0);
+
+ val = pwm_readl(pwm, pc->soc->enable_reg);
val |= PWM_ENABLE;
- pwm_writel(pwm, PWM_CSR_0, val);
+ pwm_writel(pwm, pc->soc->enable_reg, val);
return 0;
}
static void tegra_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
u32 val;
- val = pwm_readl(pwm, PWM_CSR_0);
+ val = pwm_readl(pwm, pc->soc->enable_reg);
val &= ~PWM_ENABLE;
- pwm_writel(pwm, PWM_CSR_0, val);
+ pwm_writel(pwm, pc->soc->enable_reg, val);
pm_runtime_put_sync(pwmchip_parent(chip));
}
@@ -398,10 +403,12 @@ static int __maybe_unused tegra_pwm_runtime_resume(struct device *dev)
static const struct tegra_pwm_soc tegra20_pwm_soc = {
.num_channels = 4,
+ .enable_reg = PWM_CSR_0,
};
static const struct tegra_pwm_soc tegra186_pwm_soc = {
.num_channels = 1,
+ .enable_reg = PWM_CSR_0,
};
static const struct of_device_id tegra_pwm_of_match[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/7] pwm: tegra: Modify read/write accessors for multi-register channel
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
On Tegra264, each PWM instance has two registers (per channel, of which
there is one). Update the pwm_readl/pwm_writel helper functions to
take channel (as struct pwm_device *) and offset separately.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index 8a330169d531..358c81cea05b 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -57,6 +57,8 @@
#define PWM_SCALE_WIDTH 13
#define PWM_SCALE_SHIFT 0
+#define PWM_CSR_0 0
+
struct tegra_pwm_soc {
unsigned int num_channels;
};
@@ -78,14 +80,18 @@ static inline struct tegra_pwm_chip *to_tegra_pwm_chip(struct pwm_chip *chip)
return pwmchip_get_drvdata(chip);
}
-static inline u32 pwm_readl(struct tegra_pwm_chip *pc, unsigned int offset)
+static inline u32 pwm_readl(struct pwm_device *dev, unsigned int offset)
{
- return readl(pc->regs + (offset << 4));
+ struct tegra_pwm_chip *chip = to_tegra_pwm_chip(dev->chip);
+
+ return readl(chip->regs + (dev->hwpwm * 16) + offset);
}
-static inline void pwm_writel(struct tegra_pwm_chip *pc, unsigned int offset, u32 value)
+static inline void pwm_writel(struct pwm_device *dev, unsigned int offset, u32 value)
{
- writel(value, pc->regs + (offset << 4));
+ struct tegra_pwm_chip *chip = to_tegra_pwm_chip(dev->chip);
+
+ writel(value, chip->regs + (dev->hwpwm * 16) + offset);
}
static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -194,7 +200,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
} else
val |= PWM_ENABLE;
- pwm_writel(pc, pwm->hwpwm, val);
+ pwm_writel(pwm, PWM_CSR_0, val);
/*
* If the PWM is not enabled, turn the clock off again to save power.
@@ -207,7 +213,6 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
static int tegra_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
- struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
int rc = 0;
u32 val;
@@ -215,21 +220,20 @@ static int tegra_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
if (rc)
return rc;
- val = pwm_readl(pc, pwm->hwpwm);
+ val = pwm_readl(pwm, PWM_CSR_0);
val |= PWM_ENABLE;
- pwm_writel(pc, pwm->hwpwm, val);
+ pwm_writel(pwm, PWM_CSR_0, val);
return 0;
}
static void tegra_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
{
- struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
u32 val;
- val = pwm_readl(pc, pwm->hwpwm);
+ val = pwm_readl(pwm, PWM_CSR_0);
val &= ~PWM_ENABLE;
- pwm_writel(pc, pwm->hwpwm, val);
+ pwm_writel(pwm, PWM_CSR_0, val);
pm_runtime_put_sync(pwmchip_parent(chip));
}
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/7] pwm: tegra: Avoid hard-coded max clock frequency
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
From: Yi-Wei Wang <yiweiw@nvidia.com>
The clock driving the Tegra PWM IP can be sourced from different parent
clocks. Hence, let dev_pm_opp_set_rate() set the max clock rate based
upon the current parent clock that can be specified via device-tree.
After this, the Tegra194 SoC data becomes redundant, so get rid of it.
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Co-developed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index 172063b51d44..8a330169d531 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -59,9 +59,6 @@
struct tegra_pwm_soc {
unsigned int num_channels;
-
- /* Maximum IP frequency for given SoCs */
- unsigned long max_frequency;
};
struct tegra_pwm_chip {
@@ -303,7 +300,7 @@ static int tegra_pwm_probe(struct platform_device *pdev)
return ret;
/* Set maximum frequency of the IP */
- ret = dev_pm_opp_set_rate(&pdev->dev, pc->soc->max_frequency);
+ ret = dev_pm_opp_set_rate(&pdev->dev, ULONG_MAX);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to set max frequency: %d\n", ret);
goto put_pm;
@@ -318,7 +315,7 @@ static int tegra_pwm_probe(struct platform_device *pdev)
/* Set minimum limit of PWM period for the IP */
pc->min_period_ns =
- (NSEC_PER_SEC / (pc->soc->max_frequency >> PWM_DUTY_WIDTH)) + 1;
+ (NSEC_PER_SEC / (pc->clk_rate >> PWM_DUTY_WIDTH)) + 1;
pc->rst = devm_reset_control_get_exclusive(&pdev->dev, "pwm");
if (IS_ERR(pc->rst)) {
@@ -397,23 +394,16 @@ static int __maybe_unused tegra_pwm_runtime_resume(struct device *dev)
static const struct tegra_pwm_soc tegra20_pwm_soc = {
.num_channels = 4,
- .max_frequency = 48000000UL,
};
static const struct tegra_pwm_soc tegra186_pwm_soc = {
.num_channels = 1,
- .max_frequency = 102000000UL,
-};
-
-static const struct tegra_pwm_soc tegra194_pwm_soc = {
- .num_channels = 1,
- .max_frequency = 408000000UL,
};
static const struct of_device_id tegra_pwm_of_match[] = {
{ .compatible = "nvidia,tegra20-pwm", .data = &tegra20_pwm_soc },
{ .compatible = "nvidia,tegra186-pwm", .data = &tegra186_pwm_soc },
- { .compatible = "nvidia,tegra194-pwm", .data = &tegra194_pwm_soc },
+ { .compatible = "nvidia,tegra194-pwm", .data = &tegra186_pwm_soc },
{ }
};
MODULE_DEVICE_TABLE(of, tegra_pwm_of_match);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/7] Tegra264 PWM support
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding,
Mikko Perttunen, Yi-Wei Wang
Hello,
this adds support for the PWM controller on Tegra264. The controller
is similar to previous generations, but the register fields are
widened, the depth is made configurable, and the enable bit moves
to a different spot.
This series adds only basic support with fixed depth -- configurable
depth will come later.
Patch 1 adds device tree bindings for Tegra264 PWM (compatible
string).
Patches 2 to 6 contain the PWM driver changes.
Patch 7 adds device tree nodes for the PWM controllers on Tegra264.
Thanks,
Mikko
---
Changes in v4:
- Use ULONG_MAX rather than S64_MAX to avoid overflow on 32-bit platforms
- Link to v3: https://lore.kernel.org/r/20260330-t264-pwm-v3-0-5714427d5976@nvidia.com
Changes in v3:
- Fixed device tree binding patch.
- Picked up trailers.
- Link to v2: https://lore.kernel.org/r/20260325-t264-pwm-v2-0-998d885984b3@nvidia.com
Changes in v2:
- Added device tree binding and Tegra264 device tree patches by Thierry.
- Link to v1: https://lore.kernel.org/r/20260323-t264-pwm-v1-0-4c4ff743050f@nvidia.com
---
Mikko Perttunen (4):
pwm: tegra: Modify read/write accessors for multi-register channel
pwm: tegra: Parametrize enable register offset
pwm: tegra: Parametrize duty and scale field widths
pwm: tegra: Add support for Tegra264
Thierry Reding (2):
dt-bindings: pwm: Document Tegra264 controller
arm64: tegra: Add PWM controllers on Tegra264
Yi-Wei Wang (1):
pwm: tegra: Avoid hard-coded max clock frequency
.../bindings/pwm/nvidia,tegra20-pwm.yaml | 1 +
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 72 +++++++++++
drivers/pwm/pwm-tegra.c | 141 ++++++++++++++-------
3 files changed, 171 insertions(+), 43 deletions(-)
---
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
change-id: 20260303-t264-pwm-57e10d039df1
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: pwm: Document Tegra264 controller
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Add a new compatible string for the PWM controller found on Tegra264.
The controller is similar to earlier generations but not compatible
with them.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[mperttunen: Drop extra Tegra194 compatible string]
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
index 41cea4979132..cb2f36e7b5d6 100644
--- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
@@ -16,6 +16,7 @@ properties:
- enum:
- nvidia,tegra20-pwm
- nvidia,tegra186-pwm
+ - nvidia,tegra264-pwm
- items:
- enum:
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms
From: Sebastian Reichel @ 2026-03-31 2:09 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Damon Ding,
Dmitry Baryshkov, Alexey Charkov, dri-devel, linux-rockchip,
linux-kernel, devicetree, kernel
In-Reply-To: <AFAEA46A791878B0+9fe68e46-8d8f-44f1-80e3-dfad2de51832@airkyi.com>
[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]
Hi,
On Tue, Mar 31, 2026 at 09:18:32AM +0800, Chaoyi Chen wrote:
> On 3/30/2026 7:50 PM, Sebastian Reichel wrote:
> > On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote:
> >>> There are two parts, which possibly need some discussion:
> >>>
> >>> 1. I added a dedicated bridge callback for out-of-band hotplug events,
> >>> which is separate from the hotplug_notify. I have a feeling, that
> >>> there might be a better solution, but haven't found it.
> >>
> >> Could you explain what an out-of-band hotplug event is?
> >>
> >> Can't the drivers/usb/typec/altmodes/displayport.c respond to these
> >> hot-plug events? Thank you.
> >
> > That is what generates the out-of-band hotplug event in the first
> > place via drm_connector_oob_hotplug_event(). The oob in that call
> > means out of band.
> >
> > If you look at that function it calls oob_hotplug_event() callback
> > on the DRM connector, which is then implemented by
> > drm_bridge_connector_oob_hotplug_event(). This function calls uses
> > the normal hpd handling (shared by in-band and out-of-band) and I'm
> > patching it, so that the bridges are aware of hpd explicitly being
> > provided out-of-band.
> >
>
> Ah, I'm actually more concerned with the specific types of events.
> For example, the "explicitly" provided HPD you mentioned here.
> Isn't drm_connector_oob_hotplug_event able to provide those?
>
> I assume you’re looking for an oob event that is propagated along the
> bridge chain, rather than at the connector. Is that so? Thank you.
The connector has a dedicated hotplug oob event callback, but I obviously
need the event on the bridge, since the DP controller is implemented as
bridge. The existing infrastructure propages it down to the bridge chain
via drm_bridge_hpd_notify(), which can be received by the DP controller
via the .hpd_notify callback in struct drm_bridge_funcs.
The problem is, that this receives events for in-band AND
out-of-band hotplug events. That's why I added a new bridge
callback, which hooks into the existing framework, but only delivers
out-of-band events and no in-band events.
The problem with receiving in-band in addition to out-of-band is
that the out-of-band signal should set the hotplug pin accordingly,
but the in-band detection also checks the actual DP link. If the OOB
hotplug signal says "nothing plugged", the hotplug pin should be
forced off, but if the DP link detection fails, the hotplug pin
should not be force disabled, as that makes any further detection
tries useless.
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: bridge: ldb: Require reg property only for i.MX6SX/8MP LDBs
From: Liu Ying @ 2026-03-31 2:01 UTC (permalink / raw)
To: Marco Felsch
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Laurentiu Palcu,
dri-devel, devicetree, linux-kernel
In-Reply-To: <oyietcoxdawgjmpdc3kkmru2azuuqrkmn3onm37wpu6f3t2pqg@g7aswu7zsfrq>
Hi Marco,
On Mon, Mar 30, 2026 at 12:28:00PM +0200, Marco Felsch wrote:
> On 26-03-30, Liu Ying wrote:
>> On Sun, Mar 29, 2026 at 07:42:23PM +0200, Marco Felsch wrote:
>>> Hi Liu,
>>
>> Hi Marco,
>>
>>>
>>> sorry for not writting back earlier, the last weeks were quite busy.
>>>
>>> On 26-03-29, Liu Ying wrote:
>>>> LDB's parent device could be a syscon which doesn't allow a reg property
>>>> to be present in it's child devices, e.g., NXP i.MX93 Media blk-ctrl
>>>> has a child device NXP i.MX93 Parallel Display Format Configuration(PDFC)
>>>> without a reg property(LDB is also a child device of the Media blk-ctrl).
>>>> To make the LDB schema be able to describe LDBs without the reg property
>>>> like i.MX93 LDB, require the reg property only for i.MX6SX/8MP LDBs.
>>>
>>> NACK, we want to describe the HW and from HW PoV the LDB is and was
>>> always part of a syscon. This is the case for all SoCs i.MX6SX/8MP/93.
>>
>> The reality is that i.MX6SX and i.MX8MP LDB DT nodes are already in-tree.
>
> What do you mean by 'already in-tee'?
I mean the LDB DT nodes are already present in device trees.
You may find the LDB DT nodes with the below command line.
git grep -A5 lvds_bridge arch/ | grep -E '6sx|8mp'
>
>> People may take them as ABI(not only for Linux, but also for other
>> potential projects which use the LDB schema and/or the DT nodes).
>
> Not sure about this. The DT sould be backward compatible, meaning an old
> DT shouldn't break new users e.g. old DT with 'reg' property present
> shouldn't break new u-boot/barebox/linux/... drivers. But a new DT could
> fix/change the behavior for new u-boot/barebox/linux/... drivers.
>
> So no, I don't see a problem here.
An OS could try to get the LDB register(s) via the reg and reg-names
property which are currently present in i.MX6SX and i.MX8MP LDB DT nodes.
If we remove the properties from the DT nodes, then that OS would be broken.
That's the ABI breakage problem I talked about.
>
>>>> Fixes: 8aa2f0ac08d3 ("dt-bindings: display: bridge: ldb: Add check for reg and reg-names")
>>>
>>> Therefore I would just revert this patch completely.
>>
>> IMHO, it doesn't make too much difference between my patch and reverting
>> this offending patch, because of the ABI, i.e., the reg properties in
>> i.MX6SX and i.MX8MP LDB DT nodes are supposed to be stable.
>
> Please see above. If that would be the case, your DT must be rock-solid
> bug-free from day one, which is highly unlikely.
>
>> I feel that what you are asking for is even more than simply reverting
>> this offending patch, that is to say, completely disallowing the reg and
>> reg-names properties for LDBs across all SoCs. But again, that would
>> break the ABI.
>
> Please see above. IMHO it's more confusing if the same "IP" requires the
> 'reg' for i.MX6SX/8MP but doesn't require it for the i.MX93. Therefore I
> would like to keep it consistent.
I agree that it's ideal to keep it consistent, however, in order to avoid
the fore-mentioned ABI breakage problem, we have to keep the reg property
being present in i.MX6SX and i.MX8MP LDB DT nodes.
>
> Regards,
> Marco
>
>>
>>>
>>> Regards,
>>> Marco
>>>
>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>> ---
>>>> .../bindings/display/bridge/fsl,ldb.yaml | 23 ++++++++++++++++------
>>>> 1 file changed, 17 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
>>>> index 7f380879fffd..5f6dc2b11d7b 100644
>>>> --- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
>>>> @@ -28,6 +28,7 @@ properties:
>>>> const: ldb
>>>>
>>>> reg:
>>>> + minItems: 1
>>>> maxItems: 2
>>>>
>>>> reg-names:
>>>> @@ -68,7 +69,6 @@ required:
>>>> - compatible
>>>> - clocks
>>>> - ports
>>>> - - reg
>>>>
>>>> allOf:
>>>> - if:
>>>> @@ -83,12 +83,23 @@ allOf:
>>>> ports:
>>>> properties:
>>>> port@2: false
>>>> +
>>>> - if:
>>>> - not:
>>>> - properties:
>>>> - compatible:
>>>> - contains:
>>>> - const: fsl,imx6sx-ldb
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + enum:
>>>> + - fsl,imx6sx-ldb
>>>> + - fsl,imx8mp-ldb
>>>> + then:
>>>> + required:
>>>> + - reg
>>>> +
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + const: fsl,imx8mp-ldb
>>>> then:
>>>> required:
>>>> - reg-names
>>>>
>>>> ---
>>>> base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
>>>> change-id: 20260329-fsl_ldb_schema_fix-4fe01c42bff3
>>>>
>>>> Best regards,
>>>> --
>>>> Liu Ying <victor.liu@nxp.com>
>>>>
>>>>
>>>
>>
>> --
>> Regards,
>> Liu Ying
>>
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [net-next,PATCH v5 3/3] net: phy: realtek: Add property to enable SSC
From: Jakub Kicinski @ 2026-03-31 1:57 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, David S. Miller, Aleksander Jan Bajkowski, Andrew Lunn,
Conor Dooley, Eric Dumazet, Florian Fainelli, Heiner Kallweit,
Ivan Galkin, Krzysztof Kozlowski, Michael Klein, Paolo Abeni,
Rob Herring, Russell King, Vladimir Oltean, devicetree
In-Reply-To: <20260326210704.58912-3-marek.vasut@mailbox.org>
On Thu, 26 Mar 2026 22:06:35 +0100 Marek Vasut wrote:
> +/* RTL8211F SSC settings */
> +#define RTL8211F_SSC_PAGE 0xc44
> +#define RTL8211F_SSC_RXC 0x13
> +#define RTL8211F_SSC_SYSCLK 0x17
> +#define RTL8211F_SSC_CLKOUT 0x19
> + /* Unnamed registers from EMI improvement parameters application note 1.2 */
> + ret = phy_write_paged(phydev, 0xd09, 0x10, 0xcf00);
> + if (ret < 0) {
> + dev_err(dev, "CLKOUT SSC initialization failed: %pe\n", ERR_PTR(ret));
> + return ret;
> + }
> +
> + ret = phy_write(phydev, RTL8211F_SSC_CLKOUT, 0x38c3);
> + if (ret < 0) {
> + dev_err(dev, "CLKOUT SSC configuration failed: %pe\n", ERR_PTR(ret));
> + return ret;
> + }
AI flags that this, did you mean to write to the SSC_PAGE here?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Hawi SoC
From: Rob Herring (Arm) @ 2026-03-31 1:27 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: linux-kernel, Georgi Djakov, linux-pm, Conor Dooley,
Krzysztof Kozlowski, devicetree, Mike Tipton, linux-arm-msm
In-Reply-To: <20260330-icc-hawi-v1-1-4b54a9e7d38c@oss.qualcomm.com>
On Mon, 30 Mar 2026 17:40:00 -0700, Vivek Aknurwar wrote:
> Document the RPMh Network-On-Chip Interconnect of the Hawi platform.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> .../bindings/interconnect/qcom,hawi-rpmh.yaml | 126 ++++++++++++++++
> include/dt-bindings/interconnect/qcom,hawi-rpmh.h | 164 +++++++++++++++++++++
> 2 files changed, 290 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interconnect/qcom,hawi-rpmh.example.dtb: interconnect@f00000 (qcom,hawi-aggre1-noc): reg: [[0, 15728640], [0, 345088]] is too long
from schema $id: http://devicetree.org/schemas/interconnect/qcom,hawi-rpmh.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260330-icc-hawi-v1-1-4b54a9e7d38c@oss.qualcomm.com
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 v9 7/7] arm64: dts: qcom: sdm670-google-sargo: add imx355 front camera
From: Richard Acayan @ 2026-03-31 1:27 UTC (permalink / raw)
To: Sakari Ailus
Cc: David Heidelberg, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robert Foss, Todor Tomov,
Bryan O'Donoghue, Vladimir Zapolskiy, Bjorn Andersson,
Konrad Dybcio, Tianshu Qiu, Robert Mader, phone-devel,
linux-arm-msm, devicetree, linux-media
In-Reply-To: <acJuN_FRqMTGgl8C@kekkonen.localdomain>
On Tue, Mar 24, 2026 at 12:57:59PM +0200, Sakari Ailus wrote:
> Hi David, Richard,
>
> On Tue, Mar 24, 2026 at 10:35:24AM +0100, David Heidelberg wrote:
> >
> >
> > On 24/03/2026 03:05, Richard Acayan wrote:
> > > On Fri, Mar 13, 2026 at 07:26:47PM +0100, David Heidelberg wrote:
> > > > On 17/02/2026 01:27, Richard Acayan wrote:
> > > > [...]
> > > >
> > > > > +&cci_i2c1 {
> > > > > + camera@1a {
> > > > > + compatible = "sony,imx355";
> > > > > + reg = <0x1a>;
> > > > > +
> > > > > + clocks = <&camcc CAM_CC_MCLK2_CLK>;
> > > > > +
> > > > > + assigned-clocks = <&camcc CAM_CC_MCLK2_CLK>;
> > > > > + assigned-clock-rates = <19200000>;
> > > >
> > > > Extract from #sdm670-mainline:erebion.eu discussion:
> > > > The imx355 can operate on 24 MHz (on both Pixel 3 and 3a), but Linux kernel
> > > > driver can operate only with 19.2 MHz.
> > > >
> > > > I assume it would be worth it mention at least by comment here.
> > >
> > > This might set the series back because the devicetree isn't meant to be
> > > written for specific software, but it's included in v11 because you
> > > already asked twice.
> > >
> >
> > I would say node with lower clock frequency is still much better than
> > nothing or placeholder saying "i2c camera here". Instead we'll have small
> > placeholder that value can be bumped to 24 MHz. Important is this can be
> > easily improved when at least one consumer of the device-tree gains support.
> >
> > We have very scarce support of cameras on mobile phones in mainline, thus
> > leaving a comment that HW can do 24 MHz is reasonable compromise IMHO.
>
> The bindings could document the supported frequency range.
>
> In DTS it may make sense to set the frequency the vendor uses as it may
> affect the link frequencies (albeit I guess they're the same in this
> case?).
Is this review relevant to v11?
^ permalink raw reply
* [PATCH v4] ASoC: dt-bindings: imx-card: Complete the full list of supported DAI formats
From: Chancel Liu @ 2026-03-31 1:24 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li,
shengjiu.wang, s.hauer, kernel, festevam, linux-sound, devicetree,
imx, linux-arm-kernel, linux-kernel
Currently this binding only lists i2s and dsp_b formats that are used
by existing sound cards. However, DT bindings should describe the full
hardware capabilities rather than only the formats of current usage.
The SAI audio controller of i.MX audio sound card supports multiple DAI
formats, including:
- i2s
- left_j
- right_j
- dsp_a
- dsp_b
- pdm
- msb
- lsb
Complete the full list of formats supported by i.MX audio sound card to
ensure the binding correctly describes hardware.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
Changes in v4:
- Completed the full list of DAI formats (i2s, left_j, right_j, dsp_a,
dsp_b, pdm, msb, lsb) supported by i.MX sound card.
- Rewrote commit message to focus on describing hardware capability
rather than current usage.
Changes in v3:
- Rewrote commit message completely to describe hardware requirements.
Explicitly documented why only dsp_a is added and why other formats
are not included.
- Rebased on latest code base. No functional changes.
Changes in v2:
- Updated commit message to explain current support for i2s and dsp_b
formats and new support for dsp_a. No code changes.
Documentation/devicetree/bindings/sound/imx-audio-card.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
index 5424d4f16f52..950e3eab2942 100644
--- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
+++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
@@ -37,7 +37,13 @@ patternProperties:
items:
enum:
- i2s
+ - left_j
+ - right_j
+ - dsp_a
- dsp_b
+ - pdm
+ - msb
+ - lsb
dai-tdm-slot-num: true
--
2.50.1
^ permalink raw reply related
* Re: [PATCH 0/4] drm/panel: simple: add Waveshare LCD panels
From: Dmitry Baryshkov @ 2026-03-31 1:22 UTC (permalink / raw)
To: Marek Vasut
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, dri-devel,
devicetree, linux-kernel
In-Reply-To: <a13f5d5a-76aa-420e-a724-9b4714b51ccd@mailbox.org>
On Tue, 31 Mar 2026 at 00:07, Marek Vasut <marek.vasut@mailbox.org> wrote:
>
> On 3/30/26 3:25 PM, Dmitry Baryshkov wrote:
> > Waveshare have a serie of DSI panel kits with the DPI or LVDS panel
> > being attached to the DSI2DPI or DSI2LVDS bridge. Commit 80b0eb11f8e0
> > ("dt-bindings: display: panel: Add waveshare DPI panel support")
> > described two of them in the bindings and commit 46be11b678e0
> > ("drm/panel: simple: Add Waveshare 13.3" panel support") added
> > definitions for one of those panels. Add support for the rest of them.
> Can we by any chance use the icn6211 driver in tree for this ?
As far as I can see, no. Waveshare kits have an extra ASIC in front of
ICN6211 / ICN6202, which completely hides all programming. So far the
interface is really better expressed by the waveshare,dsi2dpi /
dsi2lvds: this way, even if they decide to change the actual
implementation (like they did for DPI -> LVDS), we won't have to worry
about it for as long as their programming interface remains stable.
--
With best wishes
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox