* Re: Re: [PATCH net-next v5 3/3] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: Simon Horman @ 2026-03-26 17:21 UTC (permalink / raw)
To: 李志
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan
In-Reply-To: <2a12c839.5e64.19d28232537.Coremail.lizhi2@eswincomputing.com>
On Thu, Mar 26, 2026 at 11:14:45AM +0800, 李志 wrote:
...
> Hi Simon,
>
> Thanks for your review.
>
> You're right, this build failure is due to an invalid clock reference
> ("clk") in the Ethernet node, which does not correspond to an existing
> clock provider label in the current DTS.
>
> For context, this was discussed during an earlier revision:
> https://lore.kernel.org/lkml/5dea8ce0.4435.19c471231f5.Coremail.lizhi2@eswincomputing.com/
>
> The EIC7700 clock controller support has since been applied, so I will
> update the DTS to reference the correct clock provider and ensure the
> build passes cleanly.
>
> I will fix this in the next revision (v6).
Thanks.
Please be aware that if the patch is routed via net-next,
then the dependency will need to be present in net-next.
^ permalink raw reply
* Re: [PATCH v8 1/5] mux: Add driver for Renesas RZ/V2H USB VBENCTL VBUS_SEL mux
From: Tommaso Merciai @ 2026-03-26 17:20 UTC (permalink / raw)
To: Philipp Zabel
Cc: tomm.merciai, peda, linux-renesas-soc, biju.das.jz,
Fabrizio Castro, Lad Prabhakar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Ulf Hansson,
Greg Kroah-Hartman, Josua Mayer, Arnd Bergmann, devicetree,
linux-kernel
In-Reply-To: <eae7dbabeca13c023dd253fe7c1c1d588c585d94.camel@pengutronix.de>
Hi Philipp,
Thanks for your review!
On Thu, Mar 12, 2026 at 04:23:28PM +0100, Philipp Zabel wrote:
> On Do, 2026-03-12 at 15:50 +0100, Tommaso Merciai wrote:
> > As per the RZ/V2H(P) HW manual, VBUSEN can be controlled by the VBUS_SEL
> > bit of the VBENCTL Control Register. This register is mapped in the
> > reset framework. The reset driver expose this register as mux-controller
> > and instantiates this driver. The consumer will use the mux API to
> > control the VBUS_SEL bit.
> >
> > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
>
>
> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
>
> Converting the reset driver to regmap and passing the regmap via
> dev_get_regmap() would allow to get rid of the dependency between
> patches 1 and 5.
Thanks for the hint.
I will switch to regmap API in v9.
Kind Regards,
Tommaso
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH 0/8] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Martyn Welch @ 2026-03-26 17:13 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, Liu Ying, 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, Oleksij Rempel,
Peng Fan, Philippe Schenker, Richard Hu, Shengjiu Wang,
Stefan Eichenberger, Vitor Soares
In-Reply-To: <20260320-drm-lcdif-dbanc-v1-0-479a04133e70@bootlin.com>
On 20/03/2026 10:46, Luca Ceresoli wrote:
> This series modernizes the i.mx8mp LCDIF driver to use the
> bridge-connector, which is the current best practice in DRM.
>
> == Call for testing on i.MX8MP boards (especially those using HDMI)!
>
> This series applies changes to how video output devices are probed on
> i.MX8MP, especially those using HDMI. Even though I have put care in not
> breaking anything, there could potentially be pitfalls I haven't realized,
> causing regressions on existing boards.
>
> I have thus added in Cc all developers which appeared active on dts files
> for imx8mp boards involving video. I would appreciate testing on as many
> boards as possible, along with a Tested-by tag, or a report about any
> issues encountered.
>
> Thanks in advance to all testers!
>
Tested-by: Martyn Welch <martyn.welch@collabora.com>
Using Ezurio Nitrogen8M Plus ENC Carrier Board with i.MX88MP SOM and
1280x800 HDMI display.
> == Review recommendation
>
> I recommend reviewing patches in this order to be understood more
> effectively:
>
> * Cover letter
> * Patches 1-5 are small preliminary cleanups/improvements
> * Patch 8 is the goal of this series, but would not work alone
> * Patch 7 this lets patch 8 work; but in turn it can't work alone
> * Patch 6 lets patch 7 work
>
> == Series description
>
> This series is not strictly related to DRM bridge hotplug, it is rather a
> preparation step. Introducing hotplug would need two different approaches:
> one for the new way, for drivers using bridge-connector and
> DRM_BRIDGE_ATTACH_NO_CONNECTOR, another for drivers using the "old, legacy
> way" where the last bridge is supposed to instantiate the
> drm_connector. Hotplug is complicated enough in one case, so it makes sense
> to only support the new way.
>
> The hardware I'm working on is an i.MX8MP, whose LCDIF driver is still
> using the old way. So this series converts to the new way as a preparation
> step.
>
> Patch 8 does the conversion, which is simple. However this would introduce
> a regression on some boards. Here's why:
>
> There are 3 instances of the LCDIF in i.MX8MP:
>
> * LCDIF1, driving the DSI output
> * LCDIF2, driving the LVDS output
> * LCDIF3, driving the HDMI output
>
> The device drivers of peripherals connected to LCDIF1 and LCDIF2 already
> support the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. So far so good.
>
> LCDIF3 is more tricky. The HDMI pipeline is:
>
> LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector
>
> The fsl,imx8mp-hdmi-tx (hdmi-tx) component supports both cases (with or
> without DRM_BRIDGE_ATTACH_NO_CONNECTOR), but in the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR case it does not create a drm_connector,
> thus preventing the creation of the pipeline. To make it work a connector
> must be created, and the way to do so is describing the connector in the
> device tree (compatible = "hdmi-connector"), so the display-driver will add
> the connector along with a wrapping bridge.
>
> Unfortunately not all device trees in mainline have an hdmi-connector
> node. Adding one is easy, but would break existing hardware upgrading to a
> newer kernel without upgrading the device tree blob. This is addressed by
> patch 7 reusing an existing approach to add such a node to the live device
> tree at init time using a device tree overlay for boards which don't have
> one.
>
> Finally, patch 7 cannot work alone because of a bad interaction between
> devlink and device tree overlays. Patch 6 solves that.
>
> == Grand plan
>
> This is part of the work to support hotplug of DRM bridges. The grand plan
> was discussed in [0].
>
> Here's the work breakdown (➜ marks the current series):
>
> 1. … add refcounting to DRM bridges struct drm_bridge,
> based on devm_drm_bridge_alloc()
> A. ✔ add new alloc API and refcounting (v6.16)
> B. ✔ convert all bridge drivers to new API (v6.17)
> C. ✔ kunit tests (v6.17)
> D. ✔ add get/put to drm_bridge_add/remove() + attach/detach()
> and warn on old allocation pattern (v6.17)
> E. … add get/put on drm_bridge accessors
> 1. ✔ drm_bridge_chain_get_first_bridge(), add cleanup action (v6.18)
> 2. ✔ drm_bridge_get_prev_bridge() (v6.18)
> 3. ✔ drm_bridge_get_next_bridge() (v6.19)
> 4. ✔ drm_for_each_bridge_in_chain() (v6.19)
> 5. ✔ drm_bridge_connector_init (v6.19)
> 6. … protect encoder bridge chain with a mutex
> 7. … of_drm_find_bridge
> a. ✔ add of_drm_get_bridge() (v7.0),
> convert basic direct users (v7.0-v7.1)
> b. ✔ convert direct of_drm_get_bridge() users, part 2 (v7.0)
> c. ✔ convert direct of_drm_get_bridge() users, part 3 (v7.0)
> d. ✔… convert direct of_drm_get_bridge() users, part 4
> (some v7.1, some pending)
> e. convert bridge-only drm_of_find_panel_or_bridge() users
> 8. drm_of_find_panel_or_bridge, *_of_get_bridge
> 9. ✔ enforce drm_bridge_add before drm_bridge_attach (v6.19)
> F. ✔ debugfs improvements
> 1. ✔ add top-level 'bridges' file (v6.16)
> 2. ✔ show refcount and list lingering bridges (v6.19)
> 2. … handle gracefully atomic updates during bridge removal
> A. ✔ Add drm_bridge_enter/exit() to protect device resources (v7.0)
> B. … protect private_obj removal from list
> C. ✔ Add drm_bridge_clear_and_put() (v7.1)
> 3. … DSI host-device driver interaction
> 4. ✔ removing the need for the "always-disconnected" connector
> 5. ➜ Migrate i.MX LCDIF driver to bridge-connector
> 6. DRM bridge hotplug
> A. Bridge hotplug management in the DRM core
> B. Device tree description
>
> [0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> Luca Ceresoli (8):
> drm/mxsfb/lcdif: simplify remote pointer management using __free
> drm/mxsfb/lcdif: don't unnecessarily loop over ports
> drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
> drm/bridge: dw-hdmi: document the output_port field
> drm/bridge: dw-hdmi: warn on unsupported attach combination
> drm/bridge: dw-hdmi: move next_bridge lookup to attach time
> drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
> drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
>
> drivers/gpu/drm/bridge/imx/Kconfig | 17 +++++
> drivers/gpu/drm/bridge/imx/Makefile | 2 +
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 60 +++++++++++++++
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 38 ++++++++++
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 ++++-------
> drivers/gpu/drm/mxsfb/Kconfig | 1 +
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 88 +++++++++-------------
> include/drm/bridge/dw_hdmi.h | 5 ++
> 9 files changed, 174 insertions(+), 83 deletions(-)
> ---
> base-commit: 8402cf4fc8f8d5756dc81cf9fda1dccdb3622634
> change-id: 20260306-drm-lcdif-dbanc-83dd948327de
>
> Best regards,
^ permalink raw reply
* [PATCH] dt-bindings: gpio: fix microchip #interrupt-cells
From: Conor Dooley @ 2026-03-26 17:02 UTC (permalink / raw)
To: linux-gpio
Cc: conor, Jamie Gibbons, Conor Dooley, Daire McNamara, Linus Walleij,
Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski, devicetree,
linux-kernel
From: Jamie Gibbons <jamie.gibbons@microchip.com>
The GPIO controller on PolarFire SoC supports more than one type of
interrupt and needs two interrupt cells.
Fixes: 735806d8a68e9 ("dt-bindings: gpio: add bindings for microchip mpfs gpio")
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
This has been downstream for ages, only noticed it was missing recently
when trying to add consumers.
CC: Conor Dooley <conor.dooley@microchip.com>
CC: Daire McNamara <daire.mcnamara@microchip.com>
CC: Linus Walleij <linusw@kernel.org>
CC: Bartosz Golaszewski <brgl@kernel.org>
CC: Rob Herring <robh@kernel.org>
CC: Krzysztof Kozlowski <krzk+dt@kernel.org>
CC: linux-gpio@vger.kernel.org
CC: devicetree@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
.../devicetree/bindings/gpio/microchip,mpfs-gpio.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
index 184432d24ea18..f42c54653d521 100644
--- a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
@@ -37,7 +37,7 @@ properties:
const: 2
"#interrupt-cells":
- const: 1
+ const: 2
ngpios:
description:
@@ -86,7 +86,7 @@ examples:
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
interrupts = <53>, <53>, <53>, <53>,
<53>, <53>, <53>, <53>,
<53>, <53>, <53>, <53>,
--
2.53.0
^ permalink raw reply related
* RE: [PATCH v9 00/21] media: i2c: add Maxim GMSL2/3 serializer and deserializer drivers
From: Dayananda, Vivekananda @ 2026-03-26 17:00 UTC (permalink / raw)
To: dumitru.ceclan@analog.com, Tomi Valkeinen, Mauro Carvalho Chehab,
Sakari Ailus, Laurent Pinchart, Julien Massot, Rob Herring,
Niklas Söderlund, Greg Kroah-Hartman, Cosmin Tanislav
Cc: mitrutzceclan@gmail.com, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-staging@lists.linux.dev, linux-gpio@vger.kernel.org,
Niklas Söderlund, martin.hecht@avnet.eu, Tomi Valkeinen,
Cosmin Tanislav, Cory Keitz
In-Reply-To: <20260311-gmsl2-3_serdes-v9-0-41499f09004f@analog.com>
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Dumitru, Sakari,
Thank you for the latest patch series. We have been validating this
on the following test infrastructure:
- IMX219 image sensor
- MAX96724 deserializer
- MAX96717 serializer
With this setup the v9 drivers operate as expected and we are able to
exercise streaming end-to-end.
One item worth noting: our deserializer sits on a custom daughter card
where the I2C bus is routed through port 1. The current MAX96724 driver
only supports I2C on port 0. It would be valuable to extend the driver
to support additional I2C port configurations so that setups like ours
can be accommodated.
Vivek
> -----Original Message-----
> From: Dumitru Ceclan via B4 Relay
> <devnull+dumitru.ceclan.analog.com@kernel.org>
> Sent: Wednesday, March 11, 2026 12:17 AM
> To: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>; Mauro
> Carvalho Chehab <mchehab@kernel.org>; Sakari Ailus
> <sakari.ailus@linux.intel.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Julien Massot
> <julien.massot@collabora.com>; Rob Herring <robh@kernel.org>; Niklas
> Söderlund <niklas.soderlund@ragnatech.se>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Cosmin Tanislav <cosmin.tanislav@analog.com>
> Cc: mitrutzceclan@gmail.com; linux-media@vger.kernel.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
> staging@lists.linux.dev; linux-gpio@vger.kernel.org; Niklas Söderlund
> <niklas.soderlund+renesas@ragnatech.se>; Martin Hecht
> <Martin.Hecht@avnet.eu>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; Cosmin Tanislav
> <demonsingur@gmail.com>; Cory Keitz <ckeitz@amazon.com>
> Subject: [PATCH v9 00/21] media: i2c: add Maxim GMSL2/3 serializer and
> deserializer drivers
>
> This series adds new drivers for multiple Maxim GMSL2 and GMSL3 devices,
> replacing the few GMSL2 drivers already in upstream, and introducing a common
> framework that can be used to implement such GMSL chips, which avoids code
> duplication while also adding support for previously unsupported features.
>
> While the normally acceptable and polite way would be to extend the current
> mainline drivers, the choice was made here to add a totally new set of drivers.
> The current drivers support only a small subset of the possible features, and only
> a few devices, so the end result after extending them would in any case be
> essentially fully rewritten, new drivers.
>
> This series depends on support for internal pads, for which a patch has been
> added.
>
> The previous version is at:
> https://lore.kernel.org/all/20250718152500.2656391-1-
> demonsingur@gmail.com/
>
> Since the previous series, Cosmin has left Analog Devices.
> Because included changes from previous version are trivial, his sign-off and tags
> were retained.
>
> The following deserializers are supported:
> * MAX96712 (already exists in staging)
> * MAX96714 (already exists)
> * MAX96714F (already exists)
> * MAX96714R (GMSL2)
> * MAX96716 (GMSL2)
> * MAX96724 (already exists as part of existing MAX96712 driver)
> * MAX96724F (GMSL2)
> * MAX96724R (GMSL2)
> * MAX9296A (GMSL2)
> * MAX96792A (GMSL3)
>
> The following serializers are supported:
> * MAX96717 (already exists)
> * MAX9295A (GMSL2)
> * MAX96793 (GMSL3)
>
> The following list enumerates new features that are supported by the common
> framework and their respective chip-specific drivers:
> * Full Streams API support. Most deserializers have support for more than one
> link, and more than one PHY. Streams support allows configuration of routing
> between these links and PHYs.
>
> * .get_frame_desc() support. Both the serializers and deserializers implement this
> to query and provide frame descriptor data. This is used in features explained in-
> depth below.
>
> * .get_mbus_config() support. The deserializers implement this to allow upstream
> devices to query the link frequency of its pads.
>
> * Address translation with I2C ATR for the serializers.
>
> * I2C ATR translation - some deserializers cannot do muxing since I2C
> communication channel masking is not available per-link, and the only other way
> to select links is to turn them off, causing link resets.
> For such cases, I2C ATR is used to change the address of the serializers at probe
> time.
>
> * Automatic GMSL link version negotiation between GMSL3, GMSL2 6Gbps,
> GMSL2 3Gbps.
>
> * Automatic stream id selection for deserializers which need serializers to stream
> on unique stream ids.
>
> * Automatic VC remapping on the deserializers. VCs are picked so that if they
> were unique on the sink pad, they will end up as unique on the source pad they
> are routed to too, prioritizing using the same VC ID as the sink pad, to facilitate
> the possibility of using tunnel mode.
>
> * Automatic pixel mode / tunnel mode selection. Tunnel mode is used when VC
> IDs do not need to be changed and all hardware supports tunnel mode,
> otherwise, pixel mode is used. The serializers are automatically switched
> between the two by using a private API.
>
> * Automatic double mode selection. In pixel mode, double mode can be used to
> pack two pixels into a single data unit, optimizing bandwidth usage. The
> serializers are automatically set up to support the double modes determined by
> the deserializers using a private API.
>
> * Automatic data padding. In pixel mode, if the data being transferred uses two
> different BPPs, data needs to be padded. The serializers automatically set this up
> depending on the configured double mode settings and incoming data types.
>
> * Logging. Both the deserializers and serializers implement the V4L2
> .log_status() ops to allow debugging of the internal state and important chip
> status registers.
>
> * PHY modes. Deserializer chips commonly have more than a single PHY.
> The firmware ports are parsed to determine the modes in which to configure the
> PHYs (2x4, 4x2, 1x4+2x2, 2x2+1x4, and variations using fewer lanes).
>
> * Serializer pinctrl. Serializers implement pinctrl to allow setting configs which
> would otherwise be inaccessible through GPIO: TX/RX via GMSL link, pull-up &
> pull-down (with strength), open-drain & push-pull, slew rate, RCLK pin selection.
>
> * TPG with selectable formats, resolutions and framerates for both serializers and
> deserializers.
>
> The drivers have been tested on the following hardware combinations, but further
> testing is welcome to ensure no / minimal breakage:
> * Raspberry Pi 5 + MAX9296A + 2xMAX96717 + 2xIMX219
> * Raspberry Pi 5 + MAX96714 + 1xMAX96717 + 1xIMX219
> * Raspberry Pi 5 + MAX96716A + 2xMAX96717 + 2xIMX219
> * Raspberry Pi 5 + MAX96712 + 4xMAX96717 + 4xIMX219
> * Raspberry Pi 5 + MAX96724 + 4xMAX96717 + 4xIMX219
> * Raspberry Pi 5 + MAX96792A + 1xMAX96793 + 1xMAX96717 + 2xIMX219
> * Raspberry Pi 5 + MAX96792A + 2xMAX96717 + 2xIMX219
> * Renesas V4H + MAX96712 + 2xMAX96717 + 2xIMX219
>
> Analog Devices is taking responsibility for the maintenance of these drivers and
> common framework, and plans to add support for new broad-market chips on top
> of them.
>
> Special thanks go to Tomi Valkeinen <
> tomi.valkeinen+renesas@ideasonboard.com>
> for testing the drivers, helping debug and coming up with ideas / implementations
> for various features.
>
> The following v4l2-compliance test still fails:
> fail: v4l2-test-subdevs.cpp(371): fmt.code == 0 || fmt.code == ~0U
> fail: v4l2-test-subdevs.cpp(418): checkMBusFrameFmt(node, fmt.format)
> test Active VIDIOC_SUBDEV_G/S_FMT: FAIL
>
> As the serializers and deserializers are format agnostic and the values set are not
> used to configure anything in the chips, this test does not make much sense in this
> context. If needed, a check for the specific ~0U value can be added.
>
> V9:
> * split max_des_ops into *_info and *_ops
> * use read_poll_timeout macro in *_wait_for_device()
> * return read_poll_timeout error -ETIMEDOUT in *_wait_for_device()
> * remove use_atr duplicate from max9296a_chip_info, present in max_des_info
> * fix max9296a DPLL register offset
> * fix C-PHY DPLL frequency in max9296a and max96724
> reported by: Cory Keitz <ckeitz@amazon.com>
> * use MAX9296A_COMMON_INFO and MAX9296A_COMMON_OPS to simplify
> probe ops init
> * fix borked patches in previous version, actually remove MAX96717 and
> MAX96714 drivers
>
> V8:
> * max96717: use the renamed PIN_CONFIG_OUTPUT to _LEVEL
> * max96717: use the renamed set_rv ops from struct gpio_chip
> * dt-bindings: set minItems lane-polarities to 2
> * dt-bindings: "add myself as maintainer" commits were removed
> * max_des & max_ser: use a default format for set_routing
> * max_des & max_ser: return ENNOTTY in *_frame_interval for non-TPG pads
>
> V7:
> * dt-bindings: max9296a: use full max96717 compatible
> * max9296a: make max96714_rlms_reg_sequence static
> * explicitly include linux/bitfield.h
> * explicitly depend on I2C and PINCTRL
> * sort media_entity_operations
> * add has_pad_interdep to media_entity_operations
>
> V6:
> * max9296a: put rlms sequence in max9296a_chip_info
> * max_des: reflow stream id a comment
> * max_ser: remove exported symbols not used in other modules
> * max_ser: init mode to a supported value
> * add default routing
> * MAX_SERDES_GMSL_3 -> MAX_SERDES_GMSL_3_12GBPS
> * guard reg_read/write with CONFIG_VIDEO_ADV_DEBUG
> * put exported symbols in MAXIM_SERDES namespace
>
> V5:
> * dt-bindings: max96717: restrict RCLKOUT to pins 2 & 4
> * dt-bindings: max96717: remove confusing rclksel pinconf property
> * dt-bindings: max96717: remove maxim,gmsl-tx/rx pinconf property
> * dt-bindings: max96717: remove gmsl prefix from maxim,gmsl-tx-id/rx-id
> * dt-bindings: max96717: remove minimum: 0
> * dt-bindings: max96717: better document slew-rate
> * dt-bindings: max96717: better document maxim,jitter-compensation
> * dt-bindings: max96717: better document maxim,tx-id/rx-id
>
> * max_serdes: add default TPG values
> * max_serdes: remove MAX_MIPI_FMT macro
> * max_serdes: EXPORT_SYMBOL -> EXPORT_SYMBOL_GPL
> * max_serdes: remove EXPORT_SYMBOL_GPL from symbols not used in other
> modules
> * max_serdes: rename symbols/macros/types to have max_serdes prefix
> * max_serdes: slim down TPG functions
>
> * max_des: fix may be used uninitialized errors
> * max_des: fix misplaced TPG validation
> * max_des: fix setting pipe PHY in tunnel mode for chips that support both
> set_pipe_phy() and set_pipe_tunnel_phy()
> * max_des: move doubled_bpp/sink_bpps variables to usage place
> * max_des: do not dynamically control PHY enable, letting lanes be in
> LP-11 when not streaming
> * max_des: refactor get/set_pipe_stream_id() logic
> * max_des: remove explicit ret = 0
>
> * max_ser: make VC remaps not pipe-specific, allocate dynamically
>
> * max9296a: add missing 1080p30 TPG entry
> * max9296a: move BIT() left shift into macro
> * max9296a: move BIT() ternary into macro
> * max9296a: reuse max_des_ops for chip-specific ops\
> * max9296a: document and compress RLMS register writes
>
> * max96717: restrict RCLKOUT to pins 2 & 4 because of hardware capabilities
> * max96717: add support for XTAL/1, XTAL/2, XTAL/4 clocks
> * max96717: set RX_EN/TX_EN automatically
> * max96717: reorder custom pinconf flags
> * max96717: drop OF dependency
>
> * drop of_match_ptr
> * re-do some indentation
> * implement TPG pattern control
> * remove pr_info() usage
> * inline lane polarity val = 0
> * inline returns
> * rewrite some Kconfig docs
> * split up patches for easier review
>
> V4:
> * max_des: fix infinite version loop
> * max_des: fix pipe link id when there are more pipes than links
> * max_des: implement setting pipe link
> * max_des: do not pass routing to phy update
> * max_des: move GMSL version strings to max_serdes
> * max_des: split finding existing VC remap from adding a new one
> * max_des: add tracking for in-use pipes
> * max_des: skip unused pipes when finding / setting pixel/tunnel mode
> * max_des: simplify remap code
> * max_des: split set_pipe_phy() into set_pipe_tunnel_phy()
>
> * max_ser: clean up i2c_xlates printing
> * max_ser: fix changing serializer address
> * max_ser: move non-continuous mode check into max96717 driver
>
> * max96724: use regmap_set_bits for STREAM_SEL_ALL
> * max96724: match surrounding indent for MAX96724_PHY1_ALT_CLOCK
> * max96724: fix setting invalid PHY to 1 when PHY 0 is in 4-lane mode
> * max96724: remove support for setting pipe phy from max96712
> * max96724: fix setting double mode on pipes 4-7
> * max96724: drop powerdown gpios
>
> * max96717: use gpio_chip's set_rv
>
> * max9296a: switch versions to unsigned int
> * max9296a: remove parantheses from MAX9296A_MIPI_PHY18/20
> * max9296a: fix printing of PHY packet counts
> * max9296a: fix phy_hw_ids size
>
> * remove usage of cammel case in defines
> * move field_get/prep to max_serdes.h
> * rework stream id setup
> * rework tunnel/pixel mode finding
> * rework bpps retrieval
> * pass whole subdev state around
> * add helper for retrieving a route's hw components / frame desc
> * update pipe enable based on active routes
> * add support for tunnel-only chips and VC remaps in tunnel mode
> * simplify max_get_streams_masks()
> * add support for TPG
>
> V3:
> * dt-bindings: drop reflow text patches
>
> * dt-bindings: max96717: move pinctrl configuration into main file
> * dt-bindings: max96717: allow a single level of pins configuration
> * dt-bindings: max96717: use regex for matching pins nodes
> * dt-bindings: max96717: drop extra allOf in pinctrl configuration
> * dt-bindings: max96717: fix i2c-atr channel name regex
> * dt-bindings: max96717: limit pinctrl functions to gpio / rclkout
> * dt-bindings: max96717: limit pins for gpio / rclkout
> * dt-bindings: max96717: add description for bias-pull-up/down
> * dt-bindings: max96717: require pins and function properties
> * dt-bindings: max96717: turn single compatible strings into an enum
>
> * dt-bindings: max9296a: include indices in port descriptions
> * dt-bindings: max9296a: remove property-less schema from input ports
> * dt-bindings: max9296a: use ATR for MAX96716A too, removing MUX entirely
>
> * dt-bindings: max96712: include indices in port descriptions
> * dt-bindings: max96712: deprecate enable-gpios in favor of powerdown-gpios
> * dt-bindings: max96712: switch from MUX to ATR
>
> * dt-bindings: max96714: add support for MAX96714R
>
> * max_des: fix POC NULL check
> * max_des: remove index var in POC enable
> * max_des: fix writing empty remaps
> * max_des: skip mode setting in tunnel mode
> * max_des: remove a duplicate source->sd NULL check
> * max_des: set pipe tunnel mode even for disabled links
>
> * max_ser: apply TX ID changes irrespective of serializer ID
>
> * max9296a: fix typo in BACKTOP22
> * max9296a: make register macros more consistent
> * max9296a: switch MAX96716 from MUX to ATR
> * max9296a: deduplicate max9296a_phy_id() logic
> * max9296a: use proper PHY id in remaps
> * max9296a: fix DPLL reset clear
> * max9296a: limit MAX96714F to GMSL2 3Gbps
> * max9296a: add support for MAX96714R
> * max9296a: do not write GMSL3 link select registers in GMSL2 devices
> * max9296a: use field_prep when setting RX_RATE
> * max9296a: simplify setting SEL_STREAM for MAX96714
> * max9296a: max96716_set_pipe_phy -> max96716a_set_pipe_phy
> * max9296a: fix off-by-one in lane polarity when using
> polarity_on_physical_lanes
>
> * max96724: fix typo in BACKTOP22
> * max96724: switch from MUX to ATR
> * max96724: add support for powerdown GPIO
> * max96724: remove support for tunneling from MAX96712
> * max96724: only set tunnel-related bits when in tunnel mode
> * max96724: add support for MAX96724F/R
> * max96724: oneshot reset links after link selection
>
> * remove GMSL2 version defaults, set all supported versions explicitly
> * reorder GMSL versions to start from 0
> * add support for GMSL2 3Gbps
> * support GMSL version finding for devices using MUX / GATE
> * add support for deserializers which don't have individual control of each link's
> GMSL version
> * add support for deserializers that need unique stream ids across all serializers
> * select_link_version -> set_link_version
> * select_resets_link -> use_atr
>
> V2:
> * add missing compatible for MAX96717F
> * fix embarrassing dt-bindings mistakes
> * move MAX9296A/MAX96716/MAX96792A to a separate file as they have two
> links / PHYs, and adding those conditionally seems impossible
> ---
> Cosmin Tanislav (20):
> dt-bindings: media: i2c: max96717: add support for I2C ATR
> dt-bindings: media: i2c: max96717: add support for pinctrl/pinconf
> dt-bindings: media: i2c: max96717: add support for MAX9295A
> dt-bindings: media: i2c: max96717: add support for MAX96793
> dt-bindings: media: i2c: max96712: use pattern properties for ports
> dt-bindings: media: i2c: max96712: add support for I2C ATR
> dt-bindings: media: i2c: max96712: add support for POC supplies
> dt-bindings: media: i2c: max96712: add support for MAX96724F/R
> dt-bindings: media: i2c: max96714: add support for MAX96714R
> dt-bindings: media: i2c: add MAX9296A, MAX96716A, MAX96792A
> media: i2c: add Maxim GMSL2/3 serializer and deserializer framework
> media: i2c: add Maxim GMSL2/3 serializer framework
> media: i2c: add Maxim GMSL2/3 deserializer framework
> media: i2c: maxim-serdes: add MAX96717 driver
> media: i2c: maxim-serdes: add MAX96724 driver
> media: i2c: maxim-serdes: add MAX9296A driver
> arm64: defconfig: disable deprecated MAX96712 driver
> staging: media: remove MAX96712 driver
> media: i2c: remove MAX96717 driver
> media: i2c: remove MAX96714 driver
>
> Sakari Ailus (1):
> media: mc: Add INTERNAL pad flag
>
> .../bindings/media/i2c/maxim,max9296a.yaml | 242 ++
> .../bindings/media/i2c/maxim,max96712.yaml | 65 +-
> .../bindings/media/i2c/maxim,max96714.yaml | 5 +-
> .../bindings/media/i2c/maxim,max96717.yaml | 154 +-
> .../userspace-api/media/mediactl/media-types.rst | 9 +
> MAINTAINERS | 10 +-
> arch/arm64/configs/defconfig | 1 -
> drivers/media/i2c/Kconfig | 34 +-
> drivers/media/i2c/Makefile | 3 +-
> drivers/media/i2c/max96714.c | 1017 -------
> drivers/media/i2c/max96717.c | 1102 -------
> drivers/media/i2c/maxim-serdes/Kconfig | 60 +
> drivers/media/i2c/maxim-serdes/Makefile | 6 +
> drivers/media/i2c/maxim-serdes/max9296a.c | 1358 +++++++++
> drivers/media/i2c/maxim-serdes/max96717.c | 1686 +++++++++++
> drivers/media/i2c/maxim-serdes/max96724.c | 1193 ++++++++
> drivers/media/i2c/maxim-serdes/max_des.c | 3188
> ++++++++++++++++++++
> drivers/media/i2c/maxim-serdes/max_des.h | 156 +
> drivers/media/i2c/maxim-serdes/max_ser.c | 2138 +++++++++++++
> drivers/media/i2c/maxim-serdes/max_ser.h | 147 +
> drivers/media/i2c/maxim-serdes/max_serdes.c | 413 +++
> drivers/media/i2c/maxim-serdes/max_serdes.h | 183 ++
> drivers/media/mc/mc-entity.c | 15 +-
> drivers/staging/media/Kconfig | 2 -
> drivers/staging/media/Makefile | 1 -
> drivers/staging/media/max96712/Kconfig | 14 -
> drivers/staging/media/max96712/Makefile | 2 -
> drivers/staging/media/max96712/max96712.c | 487 ---
> include/uapi/linux/media.h | 1 +
> 29 files changed, 11006 insertions(+), 2686 deletions(-)
> ---
> base-commit: a15a902a91b78f1544760fb52ef0151f83815f81
> change-id: 20251107-gmsl2-3_serdes-3f2b885209c3
>
> Best regards,
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Andrew Lunn @ 2026-03-26 16:56 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Louis-Alexis Eyraud, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Heiner Kallweit,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <acVQQQiciPQBkQOG@shell.armlinux.org.uk>
> What is the timing requirements for a system going into suspend vs a WoL
> packet being sent? Should a WoL packet abort entry into suspend? If yes,
> then we need to program the MAC before the PHY is suspended, because
> suspend could already be in progress.
We would then need to hook into the NETDEV_CHANGEADDR notifier, and
call into the PHY driver to let it reprogram the MAC address.
Andrew
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: Move board nodes to common DTSI
From: Sibi Sankar @ 2026-03-26 16:55 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gopikrishna Garmidi, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, rajendra.nayak
In-Reply-To: <03996c07-f9f3-4586-96ae-075927da2577@kernel.org>
On 3/26/2026 7:55 PM, Krzysztof Kozlowski wrote:
> On 26/03/2026 15:21, Gopikrishna Garmidi wrote:
>> The display, peripherals (touchpad/touchscreen/keypad), usb and their
>> dependent device nodes are common to both Glymur and Mahua CRDs,
>> so move them from glymur-crd.dts to glymur-crd.dtsi to enable code
>> reuse.
>>
> Same questions as for earlier tries (why this has to be repeated?), e.g.
> x1-crd: Please describe here what is the actual common hardware. In
> terms of physical hardware, not what you want to share.
There seems to be some kind of confusion here. This patch doesn't
introduce the common board file rather it just moves the nodes
mentioned in the commit message to the common board file.
https://lore.kernel.org/lkml/20260318124100.212992-3-gopikrishna.garmidi@oss.qualcomm.com/
The actual creation of the common board file was done ^^.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite DART-MX93
From: Andrew Lunn @ 2026-03-26 16:41 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Dario Binacchi, Alexander Stein, Maud Spierings,
Josua Mayer, Markus Niebel, Francesco Dolcini, Primoz Fiser
In-Reply-To: <304e5edc9ed11a552ac96c28d1046e4b13d5f960.1774539301.git.stefano.r@variscite.com>
> +&eqos {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pinctrl_eqos>;
> + pinctrl-1 = <&pinctrl_eqos_sleep>;
> + /*
> + * The required RGMII TX and RX 2ns delays are implemented directly
> + * in hardware via passive delay elements on the SOM PCB.
> + * No delay configuration is needed in software via PHY driver.
> + */
> + phy-mode = "rgmii";
> + phy-handle = <ðphy0>;
> + snps,clk-csr = <5>;
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + clock-frequency = < 1000000>;
As far as i know, stmmac does not implement that property. There is
the danger somebody does implement it sometime in the future, and your
board breaks because it does not work a 10MHz.
I suggest removing this.
Andrew
^ permalink raw reply
* Re: [PATCH] dt-bindings: sound: Convert pcm3060 to DT schema
From: Rob Herring (Arm) @ 2026-03-26 16:32 UTC (permalink / raw)
To: Padmashree S S
Cc: lgirdwood, linux-sound, linux-kernel, krzk+dt, broonie, conor+dt,
k.marinushkin, devicetree
In-Reply-To: <20260326153041.496811-1-padmashreess2006@gmail.com>
On Thu, 26 Mar 2026 21:00:40 +0530, Padmashree S S wrote:
> Note:
> * This patch is part of the GSoC2026 application process for device tree bindings conversions
> * https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
>
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
> .../devicetree/bindings/sound/pcm3060.txt | 23 ----------
> .../devicetree/bindings/sound/pcm3060.yaml | 45 +++++++++++++++++++
> 2 files changed, 45 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/pcm3060.txt
> create mode 100644 Documentation/devicetree/bindings/sound/pcm3060.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/sound/pcm3060.yaml:45:7: [error] no new line character at the end of file (new-line-at-end-of-file)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/sound/pcm3060.txt
MAINTAINERS: Documentation/devicetree/bindings/sound/pcm3060.txt
See https://patchwork.kernel.org/project/devicetree/patch/20260326153041.496811-1-padmashreess2006@gmail.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 v2 2/2] hwmon: (pmbus/q54sj108a2) Add support for q50sn12072 and q54sn120a1
From: Guenter Roeck @ 2026-03-26 16:29 UTC (permalink / raw)
To: Brian Chiang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel, linux-hwmon, Jack Cheng
In-Reply-To: <20260326-add-support-for-q50sn12072-and-q54sn120a1-v2-2-77bc77eedc76@inventec.com>
On Thu, Mar 26, 2026 at 01:48:06PM +0000, Brian Chiang wrote:
> From: Jack Cheng <cheng.jackhy@inventec.com>
>
> The Q50SN12072 and Q54SN120A1 are high-efficiency, high-density DC-DC power
> module from Delta Power Modules.
>
> The Q50SN12072, quarter brick, single output 12V. This product provides up
> to 1200 watts of output power at 38~60V. The Q50SN12072 offers peak
> efficiency up to 98.3%@54Vin.
>
> The Q54SN120A1, quarter brick, single output 12V. This product provides up
> to 1300 watts of output power at 40~60V. The Q54SN120A1 offers peak
> efficiency up to 98.1%@54Vin.
>
> Add support for them to q54sj108a2 driver.
>
> Signed-off-by: Jack Cheng <cheng.jackhy@inventec.com>
> Co-developed-by: Brian Chiang <chiang.brian@inventec.com>
> Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
> ---
> drivers/hwmon/pmbus/q54sj108a2.c | 97 ++++++++++++++++++++++++++++------------
> 1 file changed, 68 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/hwmon/pmbus/q54sj108a2.c b/drivers/hwmon/pmbus/q54sj108a2.c
> index d5d60a9af8c5..cc2b32ad935c 100644
> --- a/drivers/hwmon/pmbus/q54sj108a2.c
> +++ b/drivers/hwmon/pmbus/q54sj108a2.c
> @@ -22,7 +22,9 @@
> #define PMBUS_FLASH_KEY_WRITE 0xEC
>
> enum chips {
> - q54sj108a2
> + q50sn12072,
> + q54sj108a2,
> + q54sn120a1
> };
>
> enum {
> @@ -55,10 +57,24 @@ struct q54sj108a2_data {
> #define to_psu(x, y) container_of((x), struct q54sj108a2_data, debugfs_entries[(y)])
>
> static struct pmbus_driver_info q54sj108a2_info[] = {
> - [q54sj108a2] = {
> + [q50sn12072] = {
> .pages = 1,
> + /* Source : Delta Q50SN12072 */
> + .format[PSC_VOLTAGE_OUT] = linear,
> + .format[PSC_TEMPERATURE] = linear,
> + .format[PSC_VOLTAGE_IN] = linear,
> + .format[PSC_CURRENT_OUT] = linear,
>
> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_PIN |
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
> + PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_POUT,
> + },
> + [q54sj108a2] = {
> + .pages = 1,
> /* Source : Delta Q54SJ108A2 */
> + .format[PSC_VOLTAGE_OUT] = linear,
> .format[PSC_TEMPERATURE] = linear,
> .format[PSC_VOLTAGE_IN] = linear,
> .format[PSC_CURRENT_OUT] = linear,
> @@ -69,6 +85,20 @@ static struct pmbus_driver_info q54sj108a2_info[] = {
> PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
> PMBUS_HAVE_STATUS_INPUT,
> },
> + [q54sn120a1] = {
> + .pages = 1,
> + /* Source : Delta Q54SN120A1 */
> + .format[PSC_VOLTAGE_OUT] = linear,
> + .format[PSC_TEMPERATURE] = linear,
> + .format[PSC_VOLTAGE_IN] = linear,
> + .format[PSC_CURRENT_OUT] = linear,
> +
> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_PIN |
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
> + PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_POUT,
> + },
> };
>
> static ssize_t q54sj108a2_debugfs_read(struct file *file, char __user *buf,
> @@ -270,7 +300,9 @@ static const struct file_operations q54sj108a2_fops = {
> };
>
> static const struct i2c_device_id q54sj108a2_id[] = {
> + { "q50sn12072", q50sn12072 },
> { "q54sj108a2", q54sj108a2 },
> + { "q54sn120a1", q54sn120a1 },
> { },
> };
>
> @@ -280,6 +312,7 @@ static int q54sj108a2_probe(struct i2c_client *client)
> {
> struct device *dev = &client->dev;
> u8 buf[I2C_SMBUS_BLOCK_MAX + 1];
> + const struct i2c_device_id *mid;
> enum chips chip_id;
> int ret, i;
> struct dentry *debugfs;
> @@ -292,14 +325,9 @@ static int q54sj108a2_probe(struct i2c_client *client)
> I2C_FUNC_SMBUS_BLOCK_DATA))
> return -ENODEV;
>
> - if (client->dev.of_node)
> - chip_id = (enum chips)(unsigned long)of_device_get_match_data(dev);
> - else
> - chip_id = i2c_match_id(q54sj108a2_id, client)->driver_data;
> -
> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_ID, buf);
> if (ret < 0) {
> - dev_err(&client->dev, "Failed to read Manufacturer ID\n");
> + dev_err(dev, "Failed to read Manufacturer ID\n");
> return ret;
> }
> if (ret != 6 || strncmp(buf, "DELTA", 5)) {
> @@ -308,19 +336,25 @@ static int q54sj108a2_probe(struct i2c_client *client)
> return -ENODEV;
> }
>
> - /*
> - * The chips support reading PMBUS_MFR_MODEL.
> - */
> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, buf);
> if (ret < 0) {
> dev_err(dev, "Failed to read Manufacturer Model\n");
> return ret;
> }
> - if (ret != 14 || strncmp(buf, "Q54SJ108A2", 10)) {
> + for (mid = q54sj108a2_id; mid->name[0]; mid++) {
> + if (ret == strlen(mid->name) && !strncasecmp(mid->name, buf, ret))
> + break;
> + }
> + if (!mid->name[0]) {
> buf[ret] = '\0';
> dev_err(dev, "Unsupported Manufacturer Model '%s'\n", buf);
> return -ENODEV;
> }
From Sashiko feedback:
In the original driver, the PMBUS_MFR_MODEL response length was explicitly
expected to be 14 bytes (if (ret != 14 || strncmp(buf, "Q54SJ108A2", 10))),
indicating the hardware returns the 10-character name padded with 4 extra
bytes. The patch changes the detection logic to loop through supported
devices and strictly require the returned length to match the device name's
length exactly (`ret == strlen(mid->name)`). Since `ret` will be 14 for the
original hardware, and strlen("q54sj108a2") is 10, the condition 14 == 10
evaluates to false. This causes the loop to exit without matching,
erroneously printing 'Unsupported Manufacturer Model' and returning -ENODEV.
This completely breaks driver probing and hardware monitoring for the
pre-existing Q54SJ108A2 device."
> + chip_id = mid->driver_data;
> +
> + if (strcmp(client->name, mid->name) != 0)
> + dev_notice(dev, "Device mismatch: Configured %s, detected %s\n",
> + client->name, mid->name);
>
> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_REVISION, buf);
> if (ret < 0) {
> @@ -341,6 +375,7 @@ static int q54sj108a2_probe(struct i2c_client *client)
> if (!psu)
> return 0;
>
> + psu->chip = chip_id;
> psu->client = client;
>
> debugfs = pmbus_get_debugfs_dir(client);
> @@ -359,9 +394,6 @@ static int q54sj108a2_probe(struct i2c_client *client)
> debugfs_create_file("write_protect", 0444, q54sj108a2_dir,
> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_WRITEPROTECT],
> &q54sj108a2_fops);
> - debugfs_create_file("store_default", 0200, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_STOREDEFAULT],
> - &q54sj108a2_fops);
> debugfs_create_file("vo_ov_response", 0644, q54sj108a2_dir,
> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_VOOV_RESPONSE],
> &q54sj108a2_fops);
> @@ -383,27 +415,34 @@ static int q54sj108a2_probe(struct i2c_client *client)
> debugfs_create_file("mfr_location", 0444, q54sj108a2_dir,
> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_MFR_LOCATION],
> &q54sj108a2_fops);
> - debugfs_create_file("blackbox_erase", 0200, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_ERASE],
> - &q54sj108a2_fops);
> debugfs_create_file("blackbox_read_offset", 0444, q54sj108a2_dir,
> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ_OFFSET],
> &q54sj108a2_fops);
What is the purpose/value of keeping this file outside the if() block ?
> - debugfs_create_file("blackbox_set_offset", 0200, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_SET_OFFSET],
> - &q54sj108a2_fops);
> - debugfs_create_file("blackbox_read", 0444, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ],
> - &q54sj108a2_fops);
> - debugfs_create_file("flash_key", 0444, q54sj108a2_dir,
> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_FLASH_KEY],
> - &q54sj108a2_fops);
> + if (psu->chip == q54sj108a2) {
> + debugfs_create_file("store_default", 0200, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_STOREDEFAULT],
> + &q54sj108a2_fops);
> + debugfs_create_file("blackbox_erase", 0200, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_ERASE],
> + &q54sj108a2_fops);
> + debugfs_create_file("blackbox_set_offset", 0200, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_SET_OFFSET],
> + &q54sj108a2_fops);
> + debugfs_create_file("blackbox_read", 0444, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ],
> + &q54sj108a2_fops);
> + debugfs_create_file("flash_key", 0444, q54sj108a2_dir,
> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_FLASH_KEY],
> + &q54sj108a2_fops);
> + }
>
> return 0;
> }
>
> static const struct of_device_id q54sj108a2_of_match[] = {
> - { .compatible = "delta,q54sj108a2", .data = (void *)q54sj108a2 },
> + { .compatible = "delta,q50sn12072" },
> + { .compatible = "delta,q54sj108a2" },
> + { .compatible = "delta,q54sn120a1" },
Why drop .data here ?
Thanks,
Guenter
> { },
> };
>
> @@ -421,6 +460,6 @@ static struct i2c_driver q54sj108a2_driver = {
> module_i2c_driver(q54sj108a2_driver);
>
> MODULE_AUTHOR("Xiao.Ma <xiao.mx.ma@deltaww.com>");
> -MODULE_DESCRIPTION("PMBus driver for Delta Q54SJ108A2 series modules");
> +MODULE_DESCRIPTION("PMBus driver for Delta Q54SJ108A2 and compatibles");
> MODULE_LICENSE("GPL");
> MODULE_IMPORT_NS("PMBUS");
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v3 8/9] media: i2c: ov08d10: add support for reset and power management
From: Matthias Fend @ 2026-03-26 16:25 UTC (permalink / raw)
To: Sakari Ailus, Matthias Fend
Cc: Jimmy Su, Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, linux-media, linux-kernel,
devicetree, bsp-development.geo
In-Reply-To: <acU0Gky-EldJlx0t@kekkonen.localdomain>
Hi Sakari,
Am 26.03.2026 um 14:26 schrieb Sakari Ailus:
> Hi Matthias,
>
> A few more minor comments.
>
> On Tue, Mar 24, 2026 at 11:41:42AM +0100, Matthias Fend wrote:
>> Add support for the required power supplies as well as the control of an
>> optional sensor reset.
>>
>> Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
>> ---
>> drivers/media/i2c/ov08d10.c | 93 ++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 92 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/i2c/ov08d10.c b/drivers/media/i2c/ov08d10.c
>> index ce0fa30a86129302b5dda0b8796e44054fd77c88..19035991e8bb164d4fca5d87ee4551191974e8bb 100644
>> --- a/drivers/media/i2c/ov08d10.c
>> +++ b/drivers/media/i2c/ov08d10.c
>> @@ -8,6 +8,7 @@
>> #include <linux/module.h>
>> #include <linux/pm_runtime.h>
>> #include <linux/regulator/consumer.h>
>> +#include <linux/reset.h>
>> #include <media/v4l2-ctrls.h>
>> #include <media/v4l2-device.h>
>> #include <media/v4l2-fwnode.h>
>> @@ -513,9 +514,17 @@ static const char * const ov08d10_test_pattern_menu[] = {
>> "Standard Color Bar",
>> };
>>
>> +static const char *const ov08d10_supply_names[] = {
>> + "dovdd", /* Digital I/O power */
>> + "avdd", /* Analog power */
>> + "dvdd", /* Digital core power */
>> +};
>> +
>> struct ov08d10 {
>> struct device *dev;
>> struct clk *clk;
>> + struct reset_control *reset;
>> + struct regulator_bulk_data supplies[ARRAY_SIZE(ov08d10_supply_names)];
>>
>> struct v4l2_subdev sd;
>> struct media_pad pad;
>> @@ -1265,6 +1274,56 @@ static const struct v4l2_subdev_internal_ops ov08d10_internal_ops = {
>> .open = ov08d10_open,
>> };
>>
>> +static int ov08d10_power_off(struct device *dev)
>> +{
>> + struct v4l2_subdev *sd = dev_get_drvdata(dev);
>> + struct ov08d10 *ov08d10 = to_ov08d10(sd);
>> +
>> + reset_control_assert(ov08d10->reset);
>> +
>> + regulator_bulk_disable(ARRAY_SIZE(ov08d10->supplies),
>> + ov08d10->supplies);
>> +
>> + clk_disable_unprepare(ov08d10->clk);
>> +
>> + return 0;
>> +}
>> +
>> +static int ov08d10_power_on(struct device *dev)
>> +{
>> + struct v4l2_subdev *sd = dev_get_drvdata(dev);
>> + struct ov08d10 *ov08d10 = to_ov08d10(sd);
>> + int ret;
>> +
>> + ret = regulator_bulk_enable(ARRAY_SIZE(ov08d10->supplies),
>> + ov08d10->supplies);
>> + if (ret < 0) {
>> + dev_err(dev, "failed to enable regulators: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = clk_prepare_enable(ov08d10->clk);
>> + if (ret < 0) {
>> + regulator_bulk_disable(ARRAY_SIZE(ov08d10->supplies),
>> + ov08d10->supplies);
>> +
>> + dev_err(dev, "failed to enable imaging clock: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + if (ov08d10->reset) {
>> + /* Delay from DVDD stable to sensor XSHUTDN pull up: 5ms */
>> + fsleep(5 * USEC_PER_MSEC);
>> +
>> + reset_control_deassert(ov08d10->reset);
>> +
>> + /* Delay from XSHUTDN pull up to SCCB start: 8ms */
>> + fsleep(8 * USEC_PER_MSEC);
>
> Don't you need the fsleep()'s (or at least the latter one) even if you have
> no reset GPIO?
Good point. I couldn't find any explicit information in the datasheet
about operating without a hardware reset.
While I didn't encounter any problems during my tests without a reset,
that's probably just coincidence, and I think it's a good idea to wait
for the delay you suggested in any case.
>
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int ov08d10_identify_module(struct ov08d10 *ov08d10)
>> {
>> struct i2c_client *client = v4l2_get_subdevdata(&ov08d10->sd);
>> @@ -1371,6 +1430,10 @@ static void ov08d10_remove(struct i2c_client *client)
>> media_entity_cleanup(&sd->entity);
>> v4l2_ctrl_handler_free(sd->ctrl_handler);
>> pm_runtime_disable(ov08d10->dev);
>> + if (!pm_runtime_status_suspended(ov08d10->dev)) {
>> + ov08d10_power_off(ov08d10->dev);
>> + pm_runtime_set_suspended(ov08d10->dev);
>> + }
>> mutex_destroy(&ov08d10->mutex);
>> }
>>
>> @@ -1378,6 +1441,7 @@ static int ov08d10_probe(struct i2c_client *client)
>> {
>> struct ov08d10 *ov08d10;
>> unsigned long freq;
>> + unsigned int i;
>> int ret;
>>
>> ov08d10 = devm_kzalloc(&client->dev, sizeof(*ov08d10), GFP_KERNEL);
>> @@ -1403,12 +1467,32 @@ static int ov08d10_probe(struct i2c_client *client)
>> return ret;
>> }
>>
>> + ov08d10->reset = devm_reset_control_get_optional_exclusive(ov08d10->dev, NULL);
>
> This is a bit long.
>
> I'll take the set now but please post a fix on top.
I just posted a fixup. I hope it was as you intended.
Thanks
~Matthias
>
>> + if (IS_ERR(ov08d10->reset))
>> + return dev_err_probe(ov08d10->dev, PTR_ERR(ov08d10->reset),
>> + "failed to get reset\n");
>> + reset_control_assert(ov08d10->reset);
>> +
>> + for (i = 0; i < ARRAY_SIZE(ov08d10_supply_names); i++)
>> + ov08d10->supplies[i].supply = ov08d10_supply_names[i];
>> +
>> + ret = devm_regulator_bulk_get(ov08d10->dev,
>> + ARRAY_SIZE(ov08d10->supplies),
>> + ov08d10->supplies);
>> + if (ret)
>> + return dev_err_probe(ov08d10->dev, ret,
>> + "failed to get regulators\n");
>> +
>> v4l2_i2c_subdev_init(&ov08d10->sd, client, &ov08d10_subdev_ops);
>>
>> + ret = ov08d10_power_on(ov08d10->dev);
>> + if (ret)
>> + return dev_err_probe(ov08d10->dev, ret, "failed to power on\n");
>> +
>> ret = ov08d10_identify_module(ov08d10);
>> if (ret) {
>> dev_err(ov08d10->dev, "failed to find sensor: %d\n", ret);
>> - return ret;
>> + goto probe_error_power_off;
>> }
>>
>> mutex_init(&ov08d10->mutex);
>> @@ -1452,9 +1536,15 @@ static int ov08d10_probe(struct i2c_client *client)
>> v4l2_ctrl_handler_free(ov08d10->sd.ctrl_handler);
>> mutex_destroy(&ov08d10->mutex);
>>
>> +probe_error_power_off:
>> + ov08d10_power_off(ov08d10->dev);
>> +
>> return ret;
>> }
>>
>> +static DEFINE_RUNTIME_DEV_PM_OPS(ov08d10_pm_ops,
>> + ov08d10_power_off, ov08d10_power_on, NULL);
>> +
>> #ifdef CONFIG_ACPI
>> static const struct acpi_device_id ov08d10_acpi_ids[] = {
>> { "OVTI08D1" },
>> @@ -1473,6 +1563,7 @@ MODULE_DEVICE_TABLE(of, ov08d10_of_match);
>> static struct i2c_driver ov08d10_i2c_driver = {
>> .driver = {
>> .name = "ov08d10",
>> + .pm = pm_ptr(&ov08d10_pm_ops),
>> .acpi_match_table = ACPI_PTR(ov08d10_acpi_ids),
>> .of_match_table = ov08d10_of_match,
>> },
>>
>
^ permalink raw reply
* Re: [PATCH v2] regulator: dt-bindings: mps,mp8859: convert to DT schema
From: Mark Brown @ 2026-03-26 11:55 UTC (permalink / raw)
To: devicetree, robh, krzk+dt, conor+dt, reichl, sravanhome,
lgirdwood, Bhargav Joshi
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-kernel
In-Reply-To: <20260325230559.73527-1-rougueprince47@gmail.com>
On Thu, 26 Mar 2026 04:35:59 +0530, Bhargav Joshi wrote:
> regulator: dt-bindings: mps,mp8859: convert to DT schema
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1
Thanks!
[1/1] regulator: dt-bindings: mps,mp8859: convert to DT schema
https://git.kernel.org/broonie/regulator/c/32a4cd3d451d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v11 2/3] of: Factor arguments passed to of_map_id() into a struct
From: Bjorn Helgaas @ 2026-03-26 16:19 UTC (permalink / raw)
To: Vijayanand Jitta, Richard Zhu, Lucas Stach
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Krzysztof Wilczyński, Manivannan Sadhasivam,
Bjorn Helgaas, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Dmitry Baryshkov, Konrad Dybcio,
Bjorn Andersson, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Prakash Gupta, Vikash Garodia, linux-kernel, iommu,
linux-arm-kernel, devicetree, linux-pci, imx, xen-devel,
linux-arm-msm, Charan Teja Kalla
In-Reply-To: <20260325-parse_iommu_cells-v11-2-1fefa5c0e82c@oss.qualcomm.com>
[cc->to: Richard, Lucas for pci-imx6.c question]
On Wed, Mar 25, 2026 at 04:38:23PM +0530, Vijayanand Jitta wrote:
> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>
> Change of_map_id() to take a pointer to struct of_phandle_args
> instead of passing target device node and translated IDs separately.
> Update all callers accordingly.
>
> Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
> to separate the filter input from the output. Previously, the target
> parameter served dual purpose: as an input filter (if non-NULL, only
> match entries targeting that node) and as an output (receiving the
> matched node with a reference held). Now filter_np is the explicit
> input filter and arg->np is the pure output.
>
> Previously, of_map_id() would call of_node_put() on the matched node
> when a filter was provided, making reference ownership inconsistent.
> Remove this internal of_node_put() call so that of_map_id() now always
> transfers ownership of the matched node reference to the caller via
> arg->np. Callers are now consistently responsible for releasing this
> reference with of_node_put(arg->np) when done.
> ...
Not actually part of *this* patch, and AFAICS this patch is correct
as-is, but is it necessary to have different logic around
of_node_put() for imx_pcie_add_lut_by_rid() and
apple_pcie_enable_device()?
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1137,6 +1137,8 @@ static void imx_pcie_remove_lut(struct imx_pcie *imx_pcie, u16 rid)
>
> static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
> {
> + struct of_phandle_args iommu_spec = {};
> + struct of_phandle_args msi_spec = {};
> struct device *dev = imx_pcie->pci->dev;
> struct device_node *target;
> u32 sid_i, sid_m;
> @@ -1144,7 +1146,12 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
> u32 sid = 0;
>
> target = NULL;
> - err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i);
> + err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec);
> + if (!err_i) {
> + target = iommu_spec.np;
> + sid_i = iommu_spec.args[0];
> + }
> +
> if (target) {
> of_node_put(target);
Here it's conditional on "target" even though of_node_put() checks
internally for non-NULL, so it would be safe without the conditional
here.
> } else {
> @@ -1156,8 +1163,11 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
> err_i = -EINVAL;
> }
>
> - target = NULL;
> - err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m);
> + err_m = of_map_msi_id(dev->of_node, rid, NULL, &msi_spec);
> + if (!err_m) {
> + target = msi_spec.np;
> + sid_m = msi_spec.args[0];
> + }
>
> /*
> * err_m target
And here (outside the diff context) we also call of_node_put()
conditionally:
...
else if (target)
of_node_put(target);
> diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c
> index a0937b7b3c4d..c2cffc0659f4 100644
> --- a/drivers/pci/controller/pcie-apple.c
> +++ b/drivers/pci/controller/pcie-apple.c
> @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
> {
> u32 sid, rid = pci_dev_id(pdev);
> struct apple_pcie_port *port;
> + struct of_phandle_args iommu_spec = {};
> int idx, err;
>
> port = apple_pcie_get_port(pdev);
> @@ -764,10 +765,12 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
> dev_dbg(&pdev->dev, "added to bus %s, index %d\n",
> pci_name(pdev->bus->self), port->idx);
>
> - err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid);
> + err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec);
> if (err)
> return err;
>
> + of_node_put(iommu_spec.np);
Here we call of_node_put() unconditionally.
I think it would be much nicer if imx_pcie_add_lut_by_rid() used the
same style as apple_pcie_enable_device() and did the of_node_put()
unconditionally. That would untangle the function a bit and make it
easier to analyze.
> + sid = iommu_spec.args[0];
> mutex_lock(&port->pcie->lock);
>
> idx = bitmap_find_free_region(port->sid_map, port->sid_map_sz, 0);
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: qcom-ipcc: Document the Eliza Inter-Processor Communication Controller
From: Manivannan Sadhasivam @ 2026-03-26 16:18 UTC (permalink / raw)
To: Abel Vesa
Cc: Jassi Brar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260318-eliza-bindings-ipcc-v1-1-8f066c33ce7e@oss.qualcomm.com>
On Wed, Mar 18, 2026 at 10:26:49AM +0200, Abel Vesa wrote:
> Document the compatible for Qualcomm Eliza SoC Inter-Processor
> Communication Controller (IPCC).
>
> It is fully compatible with the ones found on the other Qualcomm SoCs,
> so add it alongside them in order to have the generic compatible as
> fallback.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> index 7c4d6170491d..f5c584cf2146 100644
> --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> @@ -24,6 +24,7 @@ properties:
> compatible:
> items:
> - enum:
> + - qcom,eliza-ipcc
> - qcom,glymur-ipcc
> - qcom,kaanapali-ipcc
> - qcom,milos-ipcc
>
> ---
> base-commit: 8e5a478b6d6a5bb0a3d52147862b15e4d826af19
> change-id: 20260318-eliza-bindings-ipcc-c636f38f88e1
>
> Best regards,
> --
> Abel Vesa <abel.vesa@oss.qualcomm.com>
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: renesas: rzt2h: Add pin configuration support
From: Geert Uytterhoeven @ 2026-03-26 16:12 UTC (permalink / raw)
To: Prabhakar
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, linux-renesas-soc, linux-gpio, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260319141515.2053556-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Thu, 19 Mar 2026 at 15:15, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add pin configuration support for the Renesas RZ/T2H SoC. The RZ/T2H SoC
> allows configuring several electrical characteristics through the DRCTLm
> (I/O Buffer Function Switching) registers. These registers control bias
> configuration, Schmitt trigger input, output slew rate, and drive
> strength.
>
> Implement pinconf_ops to allow reading and updating these properties
> through the generic pin configuration framework. The implementation
> supports bias-disable, bias-pull-up, bias-pull-down,
> input-schmitt-enable, slew-rate, and drive-strength-microamp.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2:
> - Updated commit description
> - Dropped 32 bit reg access for DRCTLm registers
> - Switched using to guard for locking in rzt2h_pinctrl_drctl_rmwq
> helper function
> - Dropped using RENESAS_RZT2H_PIN_CONFIG_DRIVE_STRENGTH instead
> switched to using the standard PIN_CONFIG_DRIVE_STRENGTH_UA
Thanks for the update!
> --- a/drivers/pinctrl/renesas/pinctrl-rzt2h.c
> +++ b/drivers/pinctrl/renesas/pinctrl-rzt2h.c
> @@ -54,6 +56,16 @@
> #define PFC_PIN_MASK(pin) (PFC_MASK << ((pin) * 8))
> #define PFC_FUNC_INTERRUPT 0
>
> +#define DRCTL_PIN_SHIFT(pin) ((pin) << 3)
"* 8" sounds more logical to me.
> +#define DRCTL_DRV_PIN_MASK(pin) (GENMASK_ULL(1, 0) << DRCTL_PIN_SHIFT(pin))
> +#define DRCTL_PUD_PIN_MASK(pin) (GENMASK_ULL(3, 2) << DRCTL_PIN_SHIFT(pin))
> +#define DRCTL_SMT_PIN_MASK(pin) (BIT_ULL(4) << DRCTL_PIN_SHIFT(pin))
> +#define DRCTL_SR_PIN_MASK(pin) (BIT_ULL(5) << DRCTL_PIN_SHIFT(pin))
I will drop DRCTL_PIN_SHIFT(), and replace it by "((pin) * 8)" while
applying, for consistency with e.g. PFC_PIN_MASK() above.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-pinctrl for v7.1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: pinctrl: renesas,r9a09g077: Document pin configuration properties
From: Geert Uytterhoeven @ 2026-03-26 16:01 UTC (permalink / raw)
To: Prabhakar
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, linux-renesas-soc, linux-gpio, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260319141515.2053556-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Thu, 19 Mar 2026 at 15:15, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Document the pin configuration properties supported by the RZ/T2H
> pinctrl driver.
>
> The RZ/T2H SoC allows configuring several electrical characteristics
> through the DRCTLm (I/O Buffer Function Switching) registers. These
> registers control drive strength, bias configuration, Schmitt trigger
> input, and output slew rate.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2:
> - Updated commit description
> - Switched to using the standard drive-strength-microamp property
> name instead of a custom one
> - Added a description for slew-rate property
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-pinctrl for v7.1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Bjorn Andersson @ 2026-03-26 15:58 UTC (permalink / raw)
To: Ayushi Makhija
Cc: konrad.dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.baryshkov, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut
In-Reply-To: <ccb11c2a-4cf1-4486-be71-d4bcc983cee6@quicinc.com>
On Thu, Mar 26, 2026 at 03:06:52PM +0530, Ayushi Makhija wrote:
> On 3/24/2026 7:34 AM, Bjorn Andersson wrote:
> > On Mon, Mar 23, 2026 at 03:52:29PM +0530, Ayushi Makhija wrote:
> >> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> >> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
> >>
> >
> > Please add Fixes: tag.
> >
>
> Hi Bjorn,
>
> Sure, will add in new patchset.
>
> >> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
> >
> > Please start using your oss.qualcomm.com address.
> >
> >> ---
> >> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >> index 3837f6785320..6ba4e69bf377 100644
> >> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >> @@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
> >>
> >> vreg_l12b_1p8: ldo12 {
> >> regulator-name = "vreg_l12b_1p8";
> >> - regulator-min-microvolt = <1200000>;
> >> + regulator-min-microvolt = <1650000>;
> >
> > Are you sure it's not supposed to be 1.8V, given the name of the rail?
> >
> > Regards,
> > Bjorn
>
> There was already discussion regarding the minimum voltage for this regulator on sm8550 target
> on other upstream patch.
>
> Link: https://lore.kernel.org/all/aQQdQoCLeKhYtY7W@yuanjiey.ap.qualcomm.com/
>
> This values is according to the NT37801 panel sec
> "The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> VDDI=1.65V~1.95V."
>
Yes, so the panel requires 1.65V, so regulator-min-microvolt needs to be
at least that. But regulator-min-microvolt should account for all the
consumers of the rail, are there any others?
Which leads me to my question, the people designing the board named the
rail VREG_L12B_1P8 in the schematics, why didn't they name it
VREG_L12B_1P65?
Please check all the consumers and make the regulator-min-microvolt work
for all of them - if that's 1.65V, then your change is good.
Regards,
Bjorn
> Thanks,
> Ayushi
>
> >> regulator-max-microvolt = <1800000>;
> >> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> >> regulator-allow-set-load;
> >> --
> >> 2.34.1
> >>
>
^ permalink raw reply
* Re: (subset) [PATCH v10 0/5] Add MIPI CSI-2 support for i.MX8ULP
From: Frank Li @ 2026-03-26 15:57 UTC (permalink / raw)
To: Rui Miguel Silva, Laurent Pinchart, Martin Kepplinger,
Purism Kernel Team, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel,
Guoniu Zhou
Cc: linux-media, devicetree, imx, linux-arm-kernel, linux-kernel,
Conor Dooley
In-Reply-To: <177453839102.4969.6512848643800500076.b4-ty@nxp.com>
On Thu, Mar 26, 2026 at 11:20:54AM -0400, Frank Li wrote:
>
> On Fri, 05 Dec 2025 17:07:42 +0800, Guoniu Zhou wrote:
> > The serial adds MIPI CSI-2 support for i.MX8ULP.
> >
> >
>
> Applied, thanks!
>
> [5/5] arm64: dts: imx8ulp: Add CSI and ISI Nodes
> commit: 73f3ca0f85285b2fc4ea05affb9a44bf899cd595
>
> Add extra empty line between reg and child node.
Guoniu Zhou:
I have to drop this one because miss <dt-bindings/reset/imx8ulp-pcc-reset.h>
Do you miss some dependence?
Frank
>
> Best regards,
> --
> Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v1 3/3] arm64: dts: imx93-var-dart: Add support for Variscite Sonata board
From: Stefano Radaelli @ 2026-03-26 15:47 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Francesco Dolcini,
Primoz Fiser
In-Reply-To: <cover.1774539301.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite Sonata carrier board with the
DART-MX93 system on module.
The Sonata board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart, SPI and I2C interfaces
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
Link: https://variscite.com/carrier-boards/sonata-board/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx93-var-dart-sonata.dts | 654 ++++++++++++++++++
2 files changed, 655 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2da6dc4f8a14..266eddd745c9 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -487,6 +487,7 @@ imx93-tqma9352-mba91xxca-rgb-cdtech-dc44-dtbs := imx93-tqma9352-mba91xxca.dtb im
dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba91xxca-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba91xxca-rgb-cdtech-dc44.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-var-dart-sonata.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93w-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx943-evk.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
new file mode 100644
index 000000000000..5513d3b148a2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
@@ -0,0 +1,654 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Variscite Sonata carrier board for DART-MX93
+ *
+ * Link: https://variscite.com/carrier-boards/sonata-board/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include "imx93-var-dart.dtsi"
+
+/ {
+ model = "Variscite DART-MX93 on Sonata-Board";
+ compatible = "variscite,var-dart-mx93-sonata",
+ "variscite,var-dart-mx93",
+ "fsl,imx93";
+
+ aliases {
+ ethernet0 = &eqos;
+ ethernet1 = &fec;
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ i2c2 = &lpi2c3;
+ i2c3 = &lpi2c4;
+ i2c4 = &lpi2c5;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart1;
+ serial1 = &lpuart2;
+ serial2 = &lpuart3;
+ serial3 = &lpuart4;
+ serial4 = &lpuart5;
+ serial5 = &lpuart6;
+ serial6 = &lpuart7;
+ };
+
+ chosen {
+ stdout-path = &lpuart1;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-home {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ gpios = <&pca6408_1 4 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&pca6408_1 5 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&pca6408_1 6 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-back {
+ label = "Back";
+ linux,code = <KEY_BACK>;
+ gpios = <&pca6408_1 7 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds_gpio>;
+
+ led-emmc {
+ gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>;
+ label = "eMMC";
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ clk40m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <40000000>;
+ clock-output-names = "can_osc";
+ };
+
+ reg_vref_1v8: regulator-adc-vref {
+ compatible = "regulator-fixed";
+ regulator-name = "vref_1v8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_SD2_3V3";
+ off-on-delay-us = <20000>;
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ethosu_mem: ethosu-region@88000000 {
+ compatible = "shared-dma-pool";
+ reusable;
+ reg = <0x0 0x88000000 0x0 0x8000000>;
+ };
+
+ vdev0vring0: vdev0vring0@87ee0000 {
+ reg = <0 0x87ee0000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@87ee8000 {
+ reg = <0 0x87ee8000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: vdev1vring0@87ef0000 {
+ reg = <0 0x87ef0000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: vdev1vring1@87ef8000 {
+ reg = <0 0x87ef8000 0 0x8000>;
+ no-map;
+ };
+
+ rsc_table: rsc-table@2021e000 {
+ reg = <0 0x2021e000 0 0x1000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@87f00000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x87f00000 0 0x100000>;
+ no-map;
+ };
+
+ ele_reserved: ele-reserved@87de0000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x87de0000 0 0x100000>;
+ no-map;
+ };
+ };
+};
+
+&adc1 {
+ vref-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+/* Use external instead of internal RTC */
+&bbnsm_rtc {
+ status = "disabled";
+};
+
+&eqos {
+ mdio {
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ reset-assert-us = <15000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+ };
+ };
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+};
+
+&fec {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_fec>;
+ pinctrl-1 = <&pinctrl_fec_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy1>;
+ status = "okay";
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "okay";
+};
+
+&lpi2c1 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c1>;
+ pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
+ pinctrl-names = "default", "sleep", "gpio";
+ scl-gpios = <&gpio1 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio1 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca9534: gpio@22 {
+ compatible = "nxp,pca9534";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-0 = <&pinctrl_captouch>;
+ pinctrl-names = "default";
+ reset-gpios = <&pca6408_2 4 GPIO_ACTIVE_LOW>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+
+ /* USB Type-C Controller */
+ typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <29 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-0 = <&pinctrl_extcon>;
+ pinctrl-names = "default";
+
+ port {
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc>;
+ wakeup-source;
+ };
+};
+
+&lpi2c5 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c5>;
+ pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
+ scl-gpios = <&gpio2 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&lpi2c7 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c7>;
+ pinctrl-1 = <&pinctrl_lpi2c7_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c7_gpio>;
+ scl-gpios = <&gpio2 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca6408_1: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pca6408_2: gpio@21 {
+ compatible = "nxp,pcal6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ st33ktpm2xi2c: tpm@2e {
+ compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+ reg = <0x2e>;
+ };
+};
+
+&lpspi8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi8>;
+ cs-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ /* CAN controller */
+ can0: can@0 {
+ compatible = "microchip,mcp251xfd";
+ reg = <0>;
+ clocks = <&clk40m>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can>;
+ spi-max-frequency = <1000000>;
+ };
+};
+
+/* Console (J10) */
+&lpuart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+/* Header (J12.4, J12.6) */
+&lpuart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart6>;
+ status = "okay";
+};
+
+/* Header (J12.11, J12.13) */
+&lpuart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ status = "okay";
+};
+
+&tpm3 {
+ pinctrl-0 = <&pinctrl_tpm3>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usbotg1 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usbotg2 {
+ disable-over-current;
+ dr_mode = "host";
+ status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ bus-width = <4>;
+ no-sdio;
+ no-mmc;
+ status = "okay";
+};
+
+&wdog3 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_can: cangrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO03__GPIO2_IO03 0x31e
+ >;
+ };
+
+ pinctrl_captouch: captouchgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
+ >;
+ };
+
+ pinctrl_extcon: extcongrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO4__GPIO4_IO29 0x31e
+ >;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0 0x57e
+ MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e
+ MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e
+ MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x37e
+ MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e
+ MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e
+ MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e
+ MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e
+ MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e
+ MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e
+ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
+ >;
+ };
+
+ pinctrl_fec_sleep: fecsleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_RD0__GPIO4_IO24 0x51e
+ MX93_PAD_ENET2_RD1__GPIO4_IO25 0x51e
+ MX93_PAD_ENET2_RD2__GPIO4_IO26 0x51e
+ MX93_PAD_ENET2_RD3__GPIO4_IO27 0x51e
+ MX93_PAD_ENET2_RXC__GPIO4_IO23 0x51e
+ MX93_PAD_ENET2_RX_CTL__GPIO4_IO22 0x51e
+ MX93_PAD_ENET2_TD0__GPIO4_IO19 0x51e
+ MX93_PAD_ENET2_TD1__GPIO4_IO18 0x51e
+ MX93_PAD_ENET2_TD2__GPIO4_IO17 0x51e
+ MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e
+ MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e
+ MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX93_PAD_PDM_CLK__CAN1_TX 0x139e
+ MX93_PAD_PDM_BIT_STREAM0__CAN1_RX 0x139e
+ >;
+ };
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* GPIO Expanders shared IRQ */
+ MX93_PAD_PDM_BIT_STREAM1__GPIO1_IO10 0x31e
+ >;
+ };
+
+ pinctrl_leds_gpio: ledgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO11__GPIO2_IO11 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c1: lpi2c1grp {
+ fsl,pins = <
+ MX93_PAD_I2C1_SCL__LPI2C1_SCL 0x40000b9e
+ MX93_PAD_I2C1_SDA__LPI2C1_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c1_gpio: lpi2c1-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_I2C1_SCL__GPIO1_IO00 0x31e
+ MX93_PAD_I2C1_SDA__GPIO1_IO01 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c5: lpi2c5grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO22__LPI2C5_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO23__LPI2C5_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c5_gpio: lpi2c5-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO22__GPIO2_IO22 0x31e
+ MX93_PAD_GPIO_IO23__GPIO2_IO23 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c7: lpi2c7grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO07__LPI2C7_SCL 0x40000b9e
+ MX93_PAD_GPIO_IO06__LPI2C7_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c7_gpio: lpi2c7-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO07__GPIO2_IO07 0x31e
+ MX93_PAD_GPIO_IO06__GPIO2_IO06 0x31e
+ >;
+ };
+
+ pinctrl_lpspi8: lpspi8grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__GPIO2_IO00 0x31e
+ MX93_PAD_GPIO_IO01__GPIO2_IO01 0x31e
+ MX93_PAD_GPIO_IO12__GPIO2_IO12 0x31e
+ MX93_PAD_GPIO_IO13__LPSPI8_SIN 0x31e
+ MX93_PAD_GPIO_IO14__LPSPI8_SOUT 0x31e
+ MX93_PAD_GPIO_IO15__LPSPI8_SCK 0x31e
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO3__GPIO4_IO28 0x31e
+ >;
+ };
+
+ pinctrl_rtc: rtcgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO02__GPIO2_IO02 0x31e
+ >;
+ };
+
+ pinctrl_tpm3: tpm3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO24__TPM3_CH3 0x51e
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
+ MX93_PAD_UART1_TXD__LPUART1_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart6: uart6grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO05__LPUART6_RX 0x31e
+ MX93_PAD_GPIO_IO04__LPUART6_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO09__LPUART7_RX 0x31e
+ MX93_PAD_GPIO_IO08__LPUART7_TX 0x31e
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite DART-MX93
From: Stefano Radaelli @ 2026-03-26 15:47 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Francesco Dolcini,
Primoz Fiser
In-Reply-To: <cover.1774539301.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite DART-MX93 system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- NXP i.MX93 MPU processor
- Up to 2GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-93/dart-mx93/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
.../boot/dts/freescale/imx93-var-dart.dtsi | 462 ++++++++++++++++++
1 file changed, 462 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
new file mode 100644
index 000000000000..bfed6625f5ab
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
@@ -0,0 +1,462 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite DART-MX93
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-93/dart-mx93/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx93.dtsi"
+
+/ {
+ model = "Variscite DART-MX93 Module";
+ compatible = "variscite,var-dart-mx93", "fsl,imx93";
+
+ sound-wm8904 {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-master = <&codec_dai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&codec_dai>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "wm8904-audio";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Microphone Jack";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai1>;
+ };
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <10000>;
+ reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
+ <&gpio3 7 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
+ };
+};
+
+&cm33 {
+ mbox-names = "tx", "rx", "rxdb";
+ mboxes = <&mu1 0 1>,
+ <&mu1 1 1>,
+ <&mu1 3 1>;
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
+ status = "okay";
+};
+
+&eqos {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_eqos>;
+ pinctrl-1 = <&pinctrl_eqos_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ snps,clk-csr = <5>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <100000>;
+ };
+ };
+};
+
+&lpi2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ pinctrl-1 = <&pinctrl_lpi2c3_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c3_gpio>;
+ scl-gpios = <&gpio2 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ wm8904: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ #sound-dai-cells = <0>;
+ clocks = <&clk IMX93_CLK_SAI1_GATE>;
+ clock-names = "mclk";
+ AVDD-supply = <&buck5>;
+ CPVDD-supply = <&buck5>;
+ DBVDD-supply = <&buck4>;
+ DCVDD-supply = <&buck5>;
+ MICVDD-supply = <&buck5>;
+ wlf,drc-cfg-names = "default", "peaklimiter", "tradition",
+ "soft", "music";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1
+ * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1
+ * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+ /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+ /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ /* DMIC is connected to IN1L */
+ wlf,in1l-as-dmicdat1;
+ };
+
+ pmic@25 {
+ compatible = "nxp,pca9451a";
+ reg = <0x25>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <650000>;
+ regulator-max-microvolt = <2237500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+/* BT module */
+&lpuart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>, <&pinctrl_bt>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+&mu1 {
+ status = "okay";
+};
+
+&mu2 {
+ status = "okay";
+};
+
+&sai1 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_sai1>;
+ pinctrl-1 = <&pinctrl_sai1_sleep>;
+ assigned-clocks = <&clk IMX93_CLK_SAI1>;
+ assigned-clock-parents = <&clk IMX93_CLK_AUDIO_PLL>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-3 = <&pinctrl_usdhc3_sleep>, <&pinctrl_usdhc3_wlan>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ keep-power-in-suspend;
+ bus-width = <4>;
+ non-removable;
+ wakeup-source;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_bt: btgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDIO__GPIO4_IO15 0x51e
+ >;
+ };
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__ENET_QOS_MDC 0x57e
+ MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
+ MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
+ MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
+ MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
+ MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
+ MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e
+ MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
+ MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e
+ MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
+ MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
+ MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e
+ MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
+ MX93_PAD_UART2_TXD__GPIO1_IO07 0x51e
+ >;
+ };
+
+ pinctrl_eqos_sleep: eqos-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__GPIO4_IO00 0x31e
+ MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x31e
+ MX93_PAD_ENET1_RD0__GPIO4_IO10 0x31e
+ MX93_PAD_ENET1_RD1__GPIO4_IO11 0x31e
+ MX93_PAD_ENET1_RD2__GPIO4_IO12 0x31e
+ MX93_PAD_ENET1_RD3__GPIO4_IO13 0x31e
+ MX93_PAD_ENET1_RXC__GPIO4_IO09 0x31e
+ MX93_PAD_ENET1_RX_CTL__GPIO4_IO08 0x31e
+ MX93_PAD_ENET1_TD0__GPIO4_IO05 0x31e
+ MX93_PAD_ENET1_TD1__GPIO4_IO04 0x31e
+ MX93_PAD_ENET1_TD2__GPIO4_IO03 0x31e
+ MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e
+ MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e
+ MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c3_gpio: lpi2c3gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__GPIO2_IO28 0x40000b9e
+ MX93_PAD_GPIO_IO29__GPIO2_IO29 0x40000b9e
+ >;
+ };
+
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <
+ MX93_PAD_SAI1_TXC__SAI1_TX_BCLK 0x31e
+ MX93_PAD_SAI1_TXFS__SAI1_TX_SYNC 0x31e
+ MX93_PAD_SAI1_TXD0__SAI1_TX_DATA00 0x31e
+ MX93_PAD_SAI1_RXD0__SAI1_RX_DATA00 0x31e
+ MX93_PAD_I2C2_SDA__SAI1_RX_BCLK 0x31e
+ MX93_PAD_I2C2_SCL__SAI1_RX_SYNC 0x31e
+ MX93_PAD_UART2_RXD__SAI1_MCLK 0x31e
+ >;
+ };
+
+ pinctrl_sai1_sleep: sai1-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_SAI1_TXC__GPIO1_IO12 0x31e
+ MX93_PAD_SAI1_TXFS__GPIO1_IO11 0x31e
+ MX93_PAD_SAI1_TXD0__GPIO1_IO13 0x31e
+ MX93_PAD_SAI1_RXD0__GPIO1_IO14 0x31e
+ MX93_PAD_UART2_RXD__GPIO1_IO06 0x31e
+ MX93_PAD_I2C2_SDA__GPIO1_IO03 0x31e
+ MX93_PAD_I2C2_SCL__GPIO1_IO02 0x31e
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
+ MX93_PAD_DAP_TDI__LPUART5_RX 0x31e
+ MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
+ MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x1582
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x40001382
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x40001382
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x40001382
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x40001382
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x40001382
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x40001382
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x40001382
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x40001382
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x40001382
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000138e
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000138e
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000138e
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000138e
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000138e
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000138e
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000138e
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000138e
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000138e
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x15fe
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x400013fe
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x400013fe
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x400013fe
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x400013fe
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x400013fe
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x400013fe
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x400013fe
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x400013fe
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x400013fe
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x1582
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x40001382
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x40001382
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x40001382
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x40001382
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x40001382
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x158e
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x4000138e
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x4000138e
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x4000138e
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x4000138e
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x4000138e
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x15fe
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x400013fe
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x400013fe
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x400013fe
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x400013fe
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x400013fe
+ >;
+ };
+
+ pinctrl_usdhc3_sleep: usdhc3-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__GPIO3_IO20 0x400
+ MX93_PAD_SD3_CMD__GPIO3_IO21 0x400
+ MX93_PAD_SD3_DATA0__GPIO3_IO22 0x400
+ MX93_PAD_SD3_DATA1__GPIO3_IO23 0x400
+ MX93_PAD_SD3_DATA2__GPIO3_IO24 0x400
+ MX93_PAD_SD3_DATA3__GPIO3_IO25 0x400
+ >;
+ };
+
+ pinctrl_usdhc3_wlan: usdhc3wlangrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDC__GPIO4_IO14 0x51e
+ MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x51e
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
From: Stefano Radaelli @ 2026-03-26 15:47 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Francesco Dolcini,
Primoz Fiser
In-Reply-To: <cover.1774539301.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add DT compatible strings for Variscite DART-MX93 SoM and Variscite
development carrier Board.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index da2be7114f64..77497a261fd5 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1587,6 +1587,12 @@ properties:
- const: variscite,var-dart-mx91 # Variscite DART-MX91 SOM
- const: fsl,imx91
+ - description: Variscite DART-MX93 based boards
+ items:
+ - const: variscite,var-dart-mx93-sonata # Variscite DART-MX93 on Sonata Development Board
+ - const: variscite,var-dart-mx93 # Variscite DART-MX93 SOM
+ - const: fsl,imx93
+
- description: Variscite VAR-SOM-MX93 based boards
items:
- const: variscite,var-som-mx93-symphony
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/3] Add support for Variscite DART-MX93 and Sonata board
From: Stefano Radaelli @ 2026-03-26 15:47 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Francesco Dolcini,
Primoz Fiser
This patch series adds support for the Variscite DART-MX93 system on
module and the Sonata carrier board.
The series includes:
- SOM device tree with on-module peripherals
- Sonata carrier board device tree with board-specific features
The implementation follows the standard SOM + carrier board pattern
where the SOM dtsi contains only peripherals mounted on the module,
while carrier-specific interfaces are enabled in the board dts.
Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
arm64: dts: freescale: Add support for Variscite DART-MX93
arm64: dts: imx93-var-dart: Add support for Variscite Sonata board
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx93-var-dart-sonata.dts | 654 ++++++++++++++++++
.../boot/dts/freescale/imx93-var-dart.dtsi | 462 +++++++++++++
4 files changed, 1123 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
base-commit: 6c4b48012d57f205c94f25da0c68a4027ea6daf6
--
2.47.3
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: monaco: extend fastrpc compute cb
From: Srinivas Kandagatla @ 2026-03-26 15:45 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260326154111.2781802-1-srinivas.kandagatla@oss.qualcomm.com>
On 3/26/26 3:41 PM, Srinivas Kandagatla wrote:
> For some reason we ended up adding only 4 out of 11 compute cb's for
> CDSP, add the missing compute cb. This will also improve the end
> user-experience by enabling running multiple AI usecases in parallel.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
> ---
Changes since v1:
- renamed the node names to be decimals from hex.
-srini
> arch/arm64/boot/dts/qcom/monaco.dtsi | 49 ++++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 10e799dd4a78..38fbd44c7d8f 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -7739,6 +7739,55 @@ compute-cb@4 {
> <&apps_smmu 0x1964 0x0400>;
> dma-coherent;
> };
> +
> + compute-cb@5 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <5>;
> + iommus = <&apps_smmu 0x19c5 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@6 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <6>;
> + iommus = <&apps_smmu 0x19c6 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@7 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <7>;
> + iommus = <&apps_smmu 0x19c7 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@8 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <8>;
> + iommus = <&apps_smmu 0x19c8 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@9 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <9>;
> + iommus = <&apps_smmu 0x19c9 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@11 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <0xb>;
> + iommus = <&apps_smmu 0x19cb 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@12 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <0xc>;
> + iommus = <&apps_smmu 0x19cc 0x000>;
> + dma-coherent;
> + };
> };
> };
> };
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Alexandre Belloni @ 2026-03-26 15:44 UTC (permalink / raw)
To: Rob Herring
Cc: Conor Dooley, Akhil R, Frank Li, Krzysztof Kozlowski,
Conor Dooley, Rafael J . Wysocki, Robert Moore, Len Brown,
Guenter Roeck, Philipp Zabel, Eric Biggers, Fredrik Markstrom,
Miquel Raynal, Thierry Reding, Jon Hunter, Suresh Mangipudi,
linux-tegra, linux-i3c, devicetree, linux-kernel, linux-acpi,
acpica-devel, linux-hwmon
In-Reply-To: <20260326150503.GA2360967-robh@kernel.org>
On 26/03/2026 10:05:03-0500, Rob Herring wrote:
> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> > > Discovery and Configuration Specification [1] to specify which discovery
> > > method an I3C device supports during bus initialization. The property is
> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
> > > indicates lack of support.
> > > Bit 0: SETDASA CCC (Direct)
> > > Bit 1: SETAASA CCC (Broadcast)
> > > Bit 2: Other CCC (vendor / standards extension)
> > > All other bits are reserved.
> > >
> > > It is specifically needed when an I3C device requires SETAASA for the
> > > address assignment. SETDASA will be supported by default if this property
> > > is absent - which means for now the property just serves as a flag to
> > > enable SETAASA, but keep the property as a bitmap to align with the
> > > specifications.
> > >
> > > [1] https://www.mipi.org/specifications/disco
> > >
> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > > ---
> > > .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
> > > 1 file changed, 26 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > index e25fa72fd785..1705d90d4d79 100644
> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > @@ -31,10 +31,12 @@ properties:
> > > described in the device tree, which in turn means we have to describe
> > > I3C devices.
> > >
> > > - Another use case for describing an I3C device in the device tree is when
> > > - this I3C device has a static I2C address and we want to assign it a
> > > - specific I3C dynamic address before the DAA takes place (so that other
> > > - devices on the bus can't take this dynamic address).
> > > + Other use-cases for describing an I3C device in the device tree are:
> > > + - When the I3C device has a static I2C address and we want to assign
> > > + it a specific I3C dynamic address before the DAA takes place (so
> > > + that other devices on the bus can't take this dynamic address).
> > > + - When the I3C device requires SETAASA for its discovery and uses a
> > > + pre-defined static address.
> > >
> > > "#size-cells":
> > > const: 0
> > > @@ -147,6 +149,26 @@ patternProperties:
> > > through SETDASA. If static address is not present, this address is assigned
> > > through SETNEWDA after assigning a temporary address via ENTDAA.
> > >
> > > + mipi-i3c-static-method:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + minimum: 0x1
> > > + maximum: 0xff
> > > + default: 1
> > > + description: |
> > > + Bitmap describing which methods of Dynamic Address Assignment from a
> > > + static address are supported by this I3C Target. A bit value of 1
> > > + indicates support for that method, and 0 indicates lack of support.
> >
> > I really am not keen on properties that are bitmaps, why can't we just
> > use the strings "setdasa", "setaasa" etc?
>
> If this comes from a specification, then I'd tend to just copy it rather
> than invent our own thing. Obviously if is something structured
> fundamentally different from how DT is designed, then we wouldn't. But
> this is just a simple property.
>
The issue being that the specification is not public so it is difficult
to take any decision.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] arm64: dts: monaco: extend fastrpc compute cb
From: Srinivas Kandagatla @ 2026-03-26 15:41 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, Srinivas Kandagatla
For some reason we ended up adding only 4 out of 11 compute cb's for
CDSP, add the missing compute cb. This will also improve the end
user-experience by enabling running multiple AI usecases in parallel.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 49 ++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 10e799dd4a78..38fbd44c7d8f 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -7739,6 +7739,55 @@ compute-cb@4 {
<&apps_smmu 0x1964 0x0400>;
dma-coherent;
};
+
+ compute-cb@5 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <5>;
+ iommus = <&apps_smmu 0x19c5 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@6 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <6>;
+ iommus = <&apps_smmu 0x19c6 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@7 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <7>;
+ iommus = <&apps_smmu 0x19c7 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@8 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <8>;
+ iommus = <&apps_smmu 0x19c8 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@9 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <9>;
+ iommus = <&apps_smmu 0x19c9 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@11 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <0xb>;
+ iommus = <&apps_smmu 0x19cb 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@12 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <0xc>;
+ iommus = <&apps_smmu 0x19cc 0x000>;
+ dma-coherent;
+ };
};
};
};
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox