* [PATCH AUTOSEL 7.0-5.10] fbdev: ipu-v3: clean up kernel-doc warnings
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Randy Dunlap, Philipp Zabel, Helge Deller, Sasha Levin, Frank.Li,
linux-fbdev, dri-devel, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit f1fb23a0a0fcbdb66672da51d7d63a259f6396ca ]
Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values
Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
return value of 'ipu_image_convert'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `fbdev: ipu-v3`; action verb `clean up`;
intent is to correct kernel-doc warnings in `include/video/imx-ipu-
image-convert.h`.
Step 1.2 Record: tags in committed message are `Signed-off-by: Randy
Dunlap <rdunlap@infradead.org>`, `Reviewed-by: Philipp Zabel
<p.zabel@pengutronix.de>`, and `Signed-off-by: Helge Deller
<deller@gmx.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-
by:`, `Link:`, or `Cc: stable@vger.kernel.org` tag is present in the
committed message.
Step 1.3 Record: the described problem is seven kernel-doc warnings: one
undocumented/private list member, malformed typedef documentation, and
missing `Returns:` sections. The visible symptom is documentation
tooling warnings, not a runtime crash, hang, data corruption, or
security issue. No affected kernel version is stated. Root cause is
incorrect kernel-doc comment syntax.
Step 1.4 Record: this is not a hidden runtime bug fix. The body and diff
both show a documentation/comment-only cleanup.
## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `include/video/imx-ipu-image-
convert.h`, 11 insertions and 5 deletions. Modified documentation covers
`struct ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`. Scope is single-
file, header-only, surgical.
Step 2.2 Record: hunk behavior:
- `struct ipu_image_convert_run`: before, `list` was documented neither
as a member nor private; after, `/* private: */` tells kernel-doc to
ignore it as an API member.
- `ipu_image_convert_cb_t`: before, kernel-doc treated the typedef
comment as a function prototype mismatch; after, it is marked as a
typedef comment.
- Return docs: before, several returns were plain prose or missing;
after, they use kernel-doc `Returns:` syntax.
- `ipu_image_convert_prepare()`: before, the V4L2 usage note followed
the return prose; after, the return section is last and formatted for
kernel-doc.
Step 2.3 Record: bug category is documentation/kernel-doc warning
cleanup. No error-path, synchronization, refcount, memory-safety,
initialization, type, logic, or hardware workaround change exists.
Step 2.4 Record: fix quality is high for the stated documentation issue:
small, obviously correct kernel-doc syntax changes. Runtime regression
risk is effectively zero because no C declarations, types, function
bodies, data layout, or APIs are changed. Documentation rendering risk
is very low.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the affected header comments and
declarations came from `cd98e85a6b786d` by Steve Longerbeam, dated
2016-09-17. `git describe --contains cd98e85a6b786d` reports it as
present by `v4.9-rc1~41^2~24^2`.
Step 3.2 Record: no `Fixes:` tag is present, so there is no tagged
introducing commit to follow. Blame identifies `cd98e85a6b786d` as the
source of the documented preimage; `git show` confirms that commit added
queued IPU image conversion support and the API documentation.
Step 3.3 Record: recent local history for the file shows `96e9d754b35e8`
removing unused `ipu_image_convert_*` functions, `c942fddf8793b` adding
SPDX boilerplate conversion, and `cd98e85a6b786d` adding the header/API.
No prerequisite commit is needed for this documentation-only patch.
Step 3.4 Record: `git log --author='Randy Dunlap'` under fbdev/include
areas shows Randy has related cleanup/documentation work such as `fbdev:
hgafb: fix kernel-doc comments` and `fbdev: fbmon: fix function name in
kernel-doc`. The patch was reviewed by Philipp Zabel and committed by
Helge Deller, verified from the commit and lore thread.
Step 3.5 Record: no dependencies found. The diff changes only comments
and applies locally with `git apply --check`.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`
failed to find a lore match by patch-id, author/subject, or in-body
From. External fetch found the v3 discussion at
`https://yhbt.net/lore/dri-
devel/20260427183236.656902-1-rdunlap@infradead.org/T/`. The v3 thread
has Helge Deller replying “applied to fbdev git tree.” Web search/fetch
also found v2 and a v2 ping. No NAKs or objections were found.
Step 4.2 Record: `b4 dig -w` also failed for the same reason. The v3
lore mirror shows recipients included `dri-devel`, Philipp Zabel, DRM
maintainers, `imx`, `linux-arm-kernel`, Helge Deller, and `linux-fbdev`.
Step 4.3 Record: no `Reported-by:` or bug-report `Link:` tags exist. No
external crash/security bug report applies.
Step 4.4 Record: this is a standalone one-patch documentation cleanup.
v2 added the reviewed-by and updated Cc list; v3 rebased and resent.
Step 4.5 Record: direct `lore.kernel.org/stable` fetch was blocked by
Anubis. Web search for the exact subject plus `stable` found patch-
thread results but no stable-specific discussion or stable nomination.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified documented symbols are
`ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`.
Step 5.2 Record: `rg` found callers in `drivers/staging/media/imx/imx-
media-csc-scaler.c` for `ipu_image_convert_abort()`,
`ipu_image_convert_queue()`, `ipu_image_convert_adjust()`,
`ipu_image_convert_unprepare()`, and `ipu_image_convert_prepare()`.
Runtime callers are unaffected because only comments changed.
Step 5.3 Record: reading `drivers/gpu/ipu-v3/ipu-image-convert.c`
confirms the documented functions perform image format
adjustment/verification, context allocation, queueing, abort/unprepare,
and single conversion setup. None of those function bodies are touched.
Step 5.4 Record: runtime path is reachable through IPU image conversion
users, but the patch changes no runtime path. The affected path for the
fix is kernel-doc/documentation generation.
Step 5.5 Record: no related same-header kernel-doc fix was found by `git
log --grep='kernel-doc' -- include/video/imx-ipu-image-convert.h`.
## Phase 6: Stable Tree Analysis
Step 6.1 Record: version tags `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.15`, `v6.16`, and `v6.17` all contain `include/video/imx-ipu-image-
convert.h` with the old kernel-doc text. The API was introduced before
`v4.9-rc1`, so active stable trees checked contain the documentation
issue.
Step 6.2 Record: expected backport difficulty is clean or minor. `git
apply --check` succeeds against the current local tree, and the checked
stable tags contain representative preimage lines. Full per-stable
worktree application was not run.
Step 6.3 Record: no related stable fix for this header was found in
local `git log --grep` searches.
## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is fbdev/gpu IPU-v3 image conversion
documentation in an include header. Runtime criticality is
peripheral/driver-specific; documentation-build criticality is low.
Step 7.2 Record: local subsystem history shows ongoing cleanup/removal
activity in `drivers/gpu/ipu-v3` and the header, including unused-
function removals and treewide cleanup. This patch is not part of a
required functional series.
## Phase 8: Impact And Risk
Step 8.1 Record: affected population is kernel documentation builders,
maintainers, and users consuming generated kernel-doc. Runtime users of
IPU-v3 are not affected by behavior.
Step 8.2 Record: trigger is running kernel-doc/documentation tooling
over this header. It is not triggered by boot, device probe, syscalls,
or ordinary runtime use. Unprivileged runtime trigger does not apply.
Step 8.3 Record: failure mode is documentation warnings only. Severity
is LOW. I did not verify any configuration where these warnings are
fatal, so that does not drive the decision.
Step 8.4 Record: benefit is low but real under the documentation-fix
exception: it makes stable documentation builds cleaner. Risk is
extremely low because only comments change. Risk/benefit is favorable if
stable accepts documentation corrections.
## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: pure documentation
correction, explicitly fixes listed kernel-doc warnings, tiny single-
file patch, reviewed by Philipp Zabel, applied by Helge Deller, old text
exists in active stable tags checked, and documentation/comment fixes
are an allowed stable exception. Evidence against: no runtime bug, no
crash/security/data-corruption impact, no stable nomination found, and
b4 could not match the thread. Unresolved: direct stable-lore search was
blocked; full apply checks on every stable branch were not run.
Step 9.2 Record:
1. Obviously correct and tested? Mostly yes for documentation syntax;
reviewed and applied, but no `Tested-by`.
2. Fixes a real bug that affects users? Yes, a real kernel-doc warning
issue; not a runtime bug.
3. Important issue? No runtime severity; LOW documentation-build
severity.
4. Small and contained? Yes, 11 additions and 5 deletions in one header.
5. No new features or APIs? Yes, comments only.
6. Can apply to stable trees? Likely yes; local apply check passed and
stable tags checked contain the preimage.
Step 9.3 Record: exception category applies: documentation/comment fix.
This is the main reason to accept despite lack of runtime impact.
Step 9.4 Decision: backporting is appropriate under the stable
documentation-fix exception. It is not a stability/security fix, but it
is a correct, reviewed, zero-runtime-risk cleanup of real kernel-doc
warnings in code present across active stable trees.
## Verification
- Phase 1: fetched and inspected committed metadata for
`f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`; confirmed tags and
message.
- Phase 2: `git show --stat --patch` confirmed one header, 11
insertions, 5 deletions, comments only.
- Phase 3: `git blame` confirmed changed comment preimage from
`cd98e85a6b786d`; `git describe --contains` placed it before
`v4.9-rc1`; `git show cd98e85a6b786d` confirmed original API addition.
- Phase 3: `git log` on the header/subsystem found no prerequisite
functional series.
- Phase 4: `b4 dig`, `b4 dig -a`, and `b4 dig -w` all failed to match;
recorded as a tool limitation/failure.
- Phase 4: WebFetch of the v3 lore mirror confirmed the patch thread and
Helge Deller’s applied reply; Spinics fetch confirmed v2 and a later
ping.
- Phase 5: `rg` found runtime users; `ReadFile` of implementation
confirmed function bodies exist but are not changed.
- Phase 6: tag checks confirmed the header and old doc text in `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.15`, `v6.16`, and `v6.17`; `git
apply --check` succeeded locally.
- Phase 8: severity/risk assessment is derived from the verified
comments-only diff.
- UNVERIFIED: direct `lore.kernel.org/stable` search content was blocked
by Anubis; no actual `make htmldocs` run was performed; full patch
application against every individual stable branch was not performed.
**YES**
include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/video/imx-ipu-image-convert.h b/include/video/imx-ipu-image-convert.h
index 003b3927ede5c..6b77968a6a150 100644
--- a/include/video/imx-ipu-image-convert.h
+++ b/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
int status;
+ /* private: */
/* internal to image converter, callers don't touch */
struct list_head list;
};
/**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
*
* @run: the completed conversion run pointer
* @ctx: a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu_image *in, struct ipu_image *out,
* @out: output image format
* @rot_mode: rotation mode
*
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
* -EINVAL otherwise.
*/
int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
* @complete: run completion callback
* @complete_context: a context pointer for the completion callback
*
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
* on failure. The input/output formats and rotation mode must already meet
* IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
*/
struct ipu_image_convert_ctx *
ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct ipu_image_convert_ctx *ctx);
* In V4L2, drivers should call ipu_image_convert_queue() while
* streaming to queue the conversion of a received input buffer.
* For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
*/
int ipu_image_convert_queue(struct ipu_image_convert_run *run);
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx);
* On successful return the caller can queue more run requests if needed, using
* the prepared context in run->ctx. The caller is responsible for unpreparing
* the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
*/
struct ipu_image_convert_run *
ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel
From: Luis Claudio R. Goncalves @ 2026-05-20 11:23 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Mark Rutland, Catalin Marinas, linux-rt-devel, linux-kernel,
Steven Rostedt, linux-arm-kernel, Waiman Long, Will Deacon,
Clark Williams
In-Reply-To: <20260520061920.XCqBHe0x@linutronix.de>
On Wed, May 20, 2026 at 08:19:20AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-05-19 18:25:24 [-0400], Waiman Long wrote:
> > Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
> > RCU") introduces debug_exception_enter() and debug_exception_exit()
> > where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
> > the following bug report can happen.
> …
>
> What kernel is this? I have backport (which is being tested) for v6.6
> and v6.12, the patches are from v6.17-rc1.
Sebastian, hardware breakpoint and watchpoint handlers still call
debug_exception_exit() and disable preemption on aarch64. That should
happen on v7.1-rc4 indeed. The suggestion was to mimic what x86_64 does
with notify_die() -> hw_breakpoint_exceptions_notify(). In ARM
hw_breakpoint_exceptions_notify() is a stub that always returns
NOTIFY_DONE.
Luis
> Sebastian
>
---end quoted text---
^ permalink raw reply
* [PATCH v4 0/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Arnab Layek @ 2026-05-20 11:26 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
andersson, mathieu.poirier, linux-remoteproc,
Project_Global_Chrome_Upstream_Group, Arnab Layek
This patch updates the mtk,scp dt-binding schema to support MT8188's
requirement for 1-2 memory regions while maintaining strict backward
compatibility for other MediaTek SoCs.
The MT8188 SCP requires a main SRAM region and optionally supports an
L1TCM (Level 1 Tightly Coupled Memory) region for performance
optimization. L1TCM is optional because basic SCP functionality works
with only SRAM, but L1TCM provides faster memory access when the board
hardware configuration includes it.
The base schema uses minItems: 1, maxItems: 2 (permissive range),
following the pattern established in other MediaTek dt-bindings like
mediatek,vcodec-encoder.yaml where the base accommodates all variants.
Conditionals then narrow the constraints per device.
Changes in v4:
- Improved commit message clarity per kernel submission guidelines:
* Added bullet-point explanation of the two memory regions
* Explained WHY L1TCM is optional (performance optimization, not
required for basic functionality)
* Explicitly listed which SoCs remain single-region
* Clarified the two-conditional approach
* Explained how minItems: 1 allows board-specific configuration
- Cover letter updated to explain L1TCM optional reasoning
Changes in v3:
- Removed "Tested on..." line (bindings cannot be tested)
- Added minItems: 1 to MT8188 conditional to make L1TCM truly optional
- Referenced mediatek,vcodec-encoder.yaml iommus pattern explicitly
- Base schema: minItems: 1, maxItems: 2 (permissive range)
- Non-MT8188: explicitly restricted to maxItems: 1
- MT8188: documented with item descriptions for both regions
Changes in v2:
- Added conditional schema for MT8188 to allow 1-2 memory regions
- Added descriptions for each memory region
- Did not work: base maxItems: 1 conflicted with conditional
Arnab Layek (1):
dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for
MT8188
.../bindings/remoteproc/mtk,scp.yaml | 45 ++++++++++++++++++-
1 file changed, 43 insertions(+), 2 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH v4 1/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Arnab Layek @ 2026-05-20 11:26 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
andersson, mathieu.poirier, linux-remoteproc,
Project_Global_Chrome_Upstream_Group, Arnab Layek
In-Reply-To: <20260520112629.3420612-1-arnab.layek@mediatek.com>
The MT8188 SCP can use either one or two reserved memory regions:
- Required: Main SCP SRAM memory region (mandatory for SCP operation)
- Optional: SCP L1TCM memory region (Level 1 Tightly Coupled Memory,
used for performance optimization when available, but not required
for basic SCP functionality)
Other MediaTek SoCs (MT8183, MT8186, MT8192, MT8195) use only a single
memory region and must remain restricted to one region for backward
compatibility.
Update the base schema to allow 1-2 memory regions (minItems: 1,
maxItems: 2), following the pattern used by other MediaTek dt-bindings
like mediatek,vcodec-encoder.yaml where the base property defines a
permissive range accommodating all device variants.
Add two conditionals:
1. Explicitly restrict non-MT8188 devices to maxItems: 1
2. Document MT8188's two regions with descriptions (minItems: 1 makes
the L1TCM region optional, allowing boards to specify 1-2 regions
based on hardware configuration)
This approach maintains backward compatibility while enabling MT8188 to
specify 1-2 memory regions depending on board design and performance
requirements.
Signed-off-by: Arnab Layek <arnab.layek@mediatek.com>
---
.../bindings/remoteproc/mtk,scp.yaml | 45 ++++++++++++++++++-
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
index bdbb12118da4..fca9b0675eae 100644
--- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
@@ -55,7 +55,8 @@ properties:
initializing SCP.
memory-region:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
cros-ec-rpmsg:
$ref: /schemas/embedded-controller/google,cros-ec.yaml
@@ -123,7 +124,8 @@ patternProperties:
initializing sub cores of multi-core SCP.
memory-region:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
cros-ec-rpmsg:
$ref: /schemas/embedded-controller/google,cros-ec.yaml
@@ -205,6 +207,45 @@ allOf:
items:
- const: cfg
- const: l1tcm
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8183-scp
+ - mediatek,mt8186-scp
+ - mediatek,mt8192-scp
+ - mediatek,mt8195-scp
+ - mediatek,mt8195-scp-dual
+ then:
+ properties:
+ memory-region:
+ maxItems: 1
+ patternProperties:
+ "^scp@[a-f0-9]+$":
+ properties:
+ memory-region:
+ maxItems: 1
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8188-scp
+ - mediatek,mt8188-scp-dual
+ then:
+ properties:
+ memory-region:
+ minItems: 1
+ items:
+ - description: Main SCP SRAM memory region
+ - description: Optional SCP L1TCM memory region
+ patternProperties:
+ "^scp@[a-f0-9]+$":
+ properties:
+ memory-region:
+ minItems: 1
+ items:
+ - description: Main SCP SRAM memory region
+ - description: Optional SCP L1TCM memory region
additionalProperties: false
--
2.45.2
^ permalink raw reply related
* [PATCH v2 0/3] arm64: dts: freescale: add Toradex Aquila iMX95
From: Franz Schnyder @ 2026-05-20 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, Conor Dooley,
João Paulo Gonçalves, Emanuele Ghidoli,
Francesco Dolcini, Antoine Gouby, Ernest Van Hoecke
This patch series adds support for the Toradex Aquila i.MX95 SoM and its
currently available carrier boards: the Aquila Development Board and the
Clover carrier board.
The module consists of an NXP i.MX95 family SoC, up to 16GB LPDDR5 RAM,
up to 128GB of storage, a USB 3.2 OTG and USB 2.0 Host, a Gigabit
Ethernet PHY, a 10 Gigabit Ethernet interface, an I2C EEPROM and
Temperature Sensor, an RX8130 RTC, one Quad lane CSI interface, one Quad
lane DSI or CSI interface, one LVDS interface (one or two channels), and
some optional addons: DisplayPort (through a DSI-DP bridge), TPM 2.0,
and a WiFi/BT module.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Link: https://www.toradex.com/products/carrier-board/clover
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
Changes in v2:
- Add 'acked-by' tag from Conor to the bindings patch
- Reordering iomux by node name
- Changed Francesco's tags to have the Toradex mail address
- Link to v1: https://lore.kernel.org/r/20260506-add-aquila-imx95-v1-0-69c8ee1c5413@toradex.com
---
Antoine Gouby (1):
arm64: dts: freescale: imx95-aquila: Add Clover carrier board
Franz Schnyder (1):
dt-bindings: arm: fsl: add Aquila iMX95
João Paulo Gonçalves (1):
arm64: dts: freescale: add Aquila iMX95 support
Documentation/devicetree/bindings/arm/fsl.yaml | 8 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../boot/dts/freescale/imx95-aquila-clover.dts | 294 +++++
arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts | 398 +++++++
arch/arm64/boot/dts/freescale/imx95-aquila.dtsi | 1160 ++++++++++++++++++++
5 files changed, 1862 insertions(+)
---
base-commit: 596d0f9f4fefffbf783ab26cfa90cf50f5dd6bb0
change-id: 20260501-add-aquila-imx95-423256af3d21
Best regards,
--
Franz Schnyder <franz.schnyder@toradex.com>
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: freescale: imx95-aquila: Add Clover carrier board
From: Franz Schnyder @ 2026-05-20 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, Antoine Gouby
In-Reply-To: <20260520-add-aquila-imx95-v2-0-06424a51e33a@toradex.com>
From: Antoine Gouby <antoine.gouby@toradex.com>
Add support for the Aquila i.MX95 SoM mated with the Clover carrier
board. Clover is a low-cost carrier board for the Aquila family
featuring a small form factor (Nano-ITX 120mm x 120mm) and built for
volume production.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/clover
Signed-off-by: Antoine Gouby <antoine.gouby@toradex.com>
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: no changes
v1: https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-3-69c8ee1c5413@toradex.com/
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx95-aquila-clover.dts | 294 +++++++++++++++++++++
2 files changed, 295 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index c8697b6ae01c5..3ce082c121036 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -523,6 +523,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-clover.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts b/arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts
new file mode 100644
index 0000000000000..021d437763412
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+ * https://www.toradex.com/products/carrier-board/clover
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95-aquila.dtsi"
+
+/ {
+ model = "Aquila iMX95 on Aquila Clover Board";
+ compatible = "toradex,aquila-imx95-clover",
+ "toradex,aquila-imx95",
+ "fsl,imx95";
+
+ aliases {
+ eeprom1 = &carrier_eeprom;
+ };
+
+ dp_1_connector: dp0-connector {
+ compatible = "dp-connector";
+ dp-pwr-supply = <®_dp_3p3v>;
+ type = "full-size";
+
+ port {
+ dp_1_connector_in: endpoint {
+ remote-endpoint = <&dsi2dp_out>;
+ };
+ };
+ };
+
+ reg_dp_3p3v: regulator-dp-3p3v {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_21_dp>;
+ /* Aquila GPIO_21_DP */
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "DP_3V3";
+ startup-delay-us = <10000>;
+ };
+};
+
+/* Aquila ADC_[1-4] */
+&adc1 {
+ status = "okay";
+};
+
+/* Aquila CTRL_WAKE1_MICO# */
+&aquila_key_wake {
+ status = "okay";
+};
+
+&dsi2dp_out {
+ remote-endpoint = <&dp_1_connector_in>;
+};
+
+/* Aquila ETH_1 */
+&enetc_port0 {
+ status = "okay";
+};
+
+/* Aquila CAN_1 */
+&flexcan1 {
+ status = "okay";
+};
+
+/* Aquila CAN_2 */
+&flexcan2 {
+ status = "okay";
+};
+
+/* Aquila CAN_3 */
+&flexcan3 {
+ status = "okay";
+};
+
+/* Aquila CAN_4 */
+&flexcan4 {
+ status = "okay";
+};
+
+/* Aquila QSPI_1 */
+&flexspi1 {
+ pinctrl-0 = <&pinctrl_flexspi1_4bit>,
+ <&pinctrl_qspi_cs1>;
+
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ cdns,read-delay = <0>;
+ cdns,tchsh-ns = <3>;
+ cdns,tsd2d-ns = <10>;
+ cdns,tshsl-ns = <30>;
+ cdns,tslch-ns = <8>;
+ };
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_1>,
+ <&pinctrl_gpio_2>,
+ <&pinctrl_gpio_3>,
+ <&pinctrl_gpio_4>;
+};
+
+/* Aquila I2C_2 */
+&i3c2 {
+ status = "okay";
+};
+
+/* Aquila I2C_1 */
+&lpi2c2 {
+ status = "okay";
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ cooling-levels = <255>;
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED>;
+ };
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp1075";
+ reg = <0x4f>;
+ };
+
+ /* USB-C OTG (TCPC USB PD PHY) */
+ tcpc@52 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x52>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ op-sink-microwatt = <0>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec_con_hs: endpoint {
+ remote-endpoint = <&usb1_con_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ typec_con_ss: endpoint {
+ remote-endpoint = <&usb1_con_ss>;
+ };
+ };
+ };
+ };
+ };
+
+ carrier_eeprom: eeprom@57 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+/* Aquila I2C_6 */
+&lpi2c5 {
+ status = "okay";
+};
+
+/* Aquila SPI_1 */
+&lpspi6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi6 &pinctrl_gpio_5>;
+ cs-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>, <&gpio4 18 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_6>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+ spi-max-frequency = <12000000>;
+ };
+};
+
+/* Aquila UART_3, used as the Linux Console */
+&lpuart1 {
+ status = "okay";
+};
+
+/* Aquila UART_4 */
+&lpuart2 {
+ status = "okay";
+};
+
+/* Aquila UART_1 */
+&lpuart3 {
+ status = "okay";
+};
+
+/* Aquila UART_2 */
+&lpuart7 {
+ status = "okay";
+};
+
+/* Aquila PCIE_1 */
+&pcie0 {
+ status = "okay";
+};
+
+&som_dsi2dp_bridge {
+ status = "okay";
+};
+
+/* Aquila PWM_1 */
+&tpm3 {
+ status = "okay";
+};
+
+/* Aquila PWM_3_DSI and PWM_4_DP */
+&tpm5 {
+ status = "okay";
+};
+
+/* Aquila PWM_2 */
+&tpm6 {
+ status = "okay";
+};
+
+/* Aquila USB_2, optional Bluetooth USB */
+&usb2 {
+ status = "okay";
+};
+
+/* Aquila USB_1 */
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ status = "okay";
+
+ port {
+ usb1_con_hs: endpoint {
+ remote-endpoint = <&typec_con_hs>;
+ };
+ };
+};
+
+&usb3_phy {
+ orientation-switch;
+
+ status = "okay";
+
+ port {
+ usb1_con_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+};
+
+/* Aquila SD_1 */
+&usdhc2 {
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: arm: fsl: add Aquila iMX95
From: Franz Schnyder @ 2026-05-20 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, Conor Dooley
In-Reply-To: <20260520-add-aquila-imx95-v2-0-06424a51e33a@toradex.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
Add DT compatible strings for the Aquila i.MX95 SoM and its supported
carrier boards: the Aquila Development Board and the Clover carrier
board.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Link: https://www.toradex.com/products/carrier-board/clover
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: Added Conor's acked-by
v1: https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-1-69c8ee1c5413@toradex.com/
---
Documentation/devicetree/bindings/arm/fsl.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 59f7f168bf7c4..ea4cc98dadebc 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1507,6 +1507,14 @@ properties:
- const: phytec,imx95-phycore-fpsc # phyCORE-i.MX 95 FPSC
- const: fsl,imx95
+ - description: Toradex Boards with Aquila iMX95 Modules
+ items:
+ - enum:
+ - toradex,aquila-imx95-clover # Aquila iMX95 Module on Clover Board
+ - toradex,aquila-imx95-dev # Aquila iMX95 Module on Aquila Development Board
+ - const: toradex,aquila-imx95 # Aquila iMX95 Module
+ - const: fsl,imx95
+
- description: Toradex Boards with SMARC iMX95 Modules
items:
- const: toradex,smarc-imx95-dev # Toradex SMARC iMX95 on Toradex SMARC Development Board
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: freescale: add Aquila iMX95 support
From: Franz Schnyder @ 2026-05-20 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, João Paulo Gonçalves,
Emanuele Ghidoli, Francesco Dolcini, Antoine Gouby,
Ernest Van Hoecke
In-Reply-To: <20260520-add-aquila-imx95-v2-0-06424a51e33a@toradex.com>
From: João Paulo Gonçalves <joao.goncalves@toradex.com>
Add support for the Toradex Aquila iMX95 and its development carrier
board.
The module consists of an NXP i.MX95 family SoC, up to 16GB LPDDR5 RAM,
up to 128GB of storage, a USB 3.2 OTG and USB 2.0 Host, a Gigabit
Ethernet PHY, a 10 Gigabit Ethernet interface, an I2C EEPROM and
Temperature Sensor, an RX8130 RTC, one Quad lane CSI interface, one Quad
lane DSI or CSI interface, one LVDS interface (one or two channels), and
some optional addons: DisplayPort (through a DSI-DP bridge), TPM 2.0,
and a WiFi/BT module.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
Co-developed-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Co-developed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Co-developed-by: Antoine Gouby <antoine.gouby@toradex.com>
Signed-off-by: Antoine Gouby <antoine.gouby@toradex.com>
Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Co-developed-by: Franz Schnyder <franz.schnyder@toradex.com>
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: -Reordered iomux alphanumerically by node name
-Changed Francesco's tags to have the Toradex mail address
v1: https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-2-69c8ee1c5413@toradex.com/
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts | 398 +++++++
arch/arm64/boot/dts/freescale/imx95-aquila.dtsi | 1160 ++++++++++++++++++++
3 files changed, 1559 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 513f61eb27b85..c8697b6ae01c5 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -523,6 +523,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-var-dart-sonata.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts b/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts
new file mode 100644
index 0000000000000..b2a53847d5079
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts
@@ -0,0 +1,398 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+ * https://www.toradex.com/products/carrier-board/aquila-development-board-kit
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95-aquila.dtsi"
+
+/ {
+ model = "Aquila iMX95 on Aquila Development Board";
+ compatible = "toradex,aquila-imx95-dev",
+ "toradex,aquila-imx95",
+ "fsl,imx95";
+
+ aliases {
+ eeprom1 = &carrier_eeprom;
+ };
+
+ dp_1_connector: dp0-connector {
+ compatible = "dp-connector";
+ dp-pwr-supply = <®_dp_3p3v>;
+ type = "full-size";
+
+ port {
+ dp_1_connector_in: endpoint {
+ remote-endpoint = <&dsi2dp_out>;
+ };
+ };
+ };
+
+ reg_carrier_1p8v: regulator-carrier-1p8v {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "On-carrier 1V8";
+ };
+
+ reg_dp_3p3v: regulator-dp-3p3v {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_21_dp>;
+ /* Aquila GPIO_21_DP */
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "DP_3V3";
+ startup-delay-us = <10000>;
+ };
+
+ sound {
+ 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 = "aquila-wm8904";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Microphone Jack", "MICBIAS",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Digital Mic";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Digital Mic",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904_1a>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai2>;
+ };
+ };
+};
+
+/* Aquila ADC_[1-4] */
+&adc1 {
+ status = "okay";
+};
+
+/* Aquila CTRL_WAKE1_MICO# */
+&aquila_key_wake {
+ status = "okay";
+};
+
+&dsi2dp_out {
+ remote-endpoint = <&dp_1_connector_in>;
+};
+
+/* Aquila ETH_1 */
+&enetc_port0 {
+ status = "okay";
+};
+
+/* Aquila CAN_1 */
+&flexcan1 {
+ status = "okay";
+};
+
+/* Aquila CAN_2 */
+&flexcan2 {
+ status = "okay";
+};
+
+/* Aquila CAN_3 */
+&flexcan3 {
+ status = "okay";
+};
+
+/* Aquila CAN_4 */
+&flexcan4 {
+ status = "okay";
+};
+
+/* Aquila QSPI_1 */
+&flexspi1 {
+ pinctrl-0 = <&pinctrl_flexspi1_4bit>,
+ <&pinctrl_qspi_cs1>;
+
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ cdns,read-delay = <0>;
+ cdns,tchsh-ns = <3>;
+ cdns,tsd2d-ns = <10>;
+ cdns,tshsl-ns = <30>;
+ cdns,tslch-ns = <8>;
+ };
+};
+
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_8>;
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_1>,
+ <&pinctrl_gpio_2>,
+ <&pinctrl_gpio_3>,
+ <&pinctrl_gpio_4>,
+ <&pinctrl_gpio_5>,
+ <&pinctrl_gpio_6>,
+ <&pinctrl_gpio_7>;
+};
+
+/* Aquila I2C_1 */
+&lpi2c2 {
+ status = "okay";
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ cooling-levels = <255>;
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED>;
+ };
+ };
+
+ wm8904_1a: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai2_mclk>;
+ clocks = <&scmi_clk IMX95_CLK_SAI2>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ AVDD-supply = <®_carrier_1p8v>;
+ CPVDD-supply = <®_carrier_1p8v>;
+ DBVDD-supply = <®_carrier_1p8v>;
+ DCVDD-supply = <®_carrier_1p8v>;
+ MICVDD-supply = <®_carrier_1p8v>;
+ wlf,drc-cfg-names = "default", "peaklimiter";
+ /*
+ * 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
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ wlf,in1r-as-dmicdat2;
+ };
+
+ /* Current measurement into module VCC */
+ hwmon@41 {
+ compatible = "ti,ina226";
+ reg = <0x41>;
+ shunt-resistor = <5000>;
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp1075";
+ reg = <0x4f>;
+ };
+
+ /* USB-C OTG (TCPC USB PD PHY) */
+ tcpc@52 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x52>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ op-sink-microwatt = <0>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec_con_hs: endpoint {
+ remote-endpoint = <&usb1_con_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ typec_con_ss: endpoint {
+ remote-endpoint = <&usb1_con_ss>;
+ };
+ };
+ };
+ };
+ };
+
+ carrier_eeprom: eeprom@57 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+/* Aquila I2C_2 */
+&i3c2 {
+ status = "okay";
+};
+
+/* Aquila I2C_4_CSI1 */
+&lpi2c4 {
+ status = "okay";
+};
+
+/* Aquila I2C_6 */
+&lpi2c5 {
+ status = "okay";
+};
+
+/* Aquila I2C_3_DSI1/I2C_5_CSI2 */
+&lpi2c8 {
+ status = "okay";
+
+ i2c-mux@70 {
+ compatible = "nxp,pca9543";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* I2C on DSI Connector Pin #4 and #6 */
+ i2c_dsi_0: i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ /* I2C on DSI Connector Pin #52 and #54 */
+ i2c_dsi_1: i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+/* Aquila SPI_1 */
+&lpspi6 {
+ status = "okay";
+};
+
+/* Aquila UART_3, used as the Linux Console */
+&lpuart1 {
+ status = "okay";
+};
+
+/* Aquila UART_4 */
+&lpuart2 {
+ status = "okay";
+};
+
+/* Aquila UART_1 */
+&lpuart3 {
+ status = "okay";
+};
+
+/* Aquila UART_2 as RS485 */
+&lpuart7 {
+ linux,rs485-enabled-at-boot-time;
+ rs485-rts-active-low;
+ rs485-rx-during-tx;
+
+ status = "okay";
+};
+
+/* Aquila PCIE_1 */
+&pcie0 {
+ status = "okay";
+};
+
+/* Aquila I2S_1 */
+&sai2 {
+ status = "okay";
+};
+
+&som_dsi2dp_bridge {
+ status = "okay";
+};
+
+/* Aquila PWM_1 */
+&tpm3 {
+ status = "okay";
+};
+
+/* Aquila PWM_2 */
+&tpm6 {
+ status = "okay";
+};
+
+/* Aquila PWM_3_DSI and PWM_4_DP */
+&tpm5 {
+ status = "okay";
+};
+
+/* Aquila USB_2, optional Bluetooth USB */
+&usb2 {
+ status = "okay";
+};
+
+/* Aquila USB_1 */
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ status = "okay";
+
+ port {
+ usb1_con_hs: endpoint {
+ remote-endpoint = <&typec_con_hs>;
+ };
+ };
+};
+
+&usb3_phy {
+ orientation-switch;
+
+ status = "okay";
+
+ port {
+ usb1_con_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+};
+
+/* Aquila SD_1 */
+&usdhc2 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila.dtsi b/arch/arm64/boot/dts/freescale/imx95-aquila.dtsi
new file mode 100644
index 0000000000000..c6dc48852ac6c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-aquila.dtsi
@@ -0,0 +1,1160 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include "imx95.dtsi"
+
+/ {
+ aliases {
+ can0 = &flexcan1;
+ can1 = &flexcan2;
+ can2 = &flexcan3;
+ can3 = &flexcan4;
+ eeprom0 = &som_eeprom;
+ ethernet0 = &enetc_port0;
+ i2c0 = &lpi2c3;
+ i2c1 = &lpi2c2;
+ i2c2 = &i3c2;
+ i2c3 = &lpi2c8;
+ i2c4 = &lpi2c4;
+ i2c6 = &lpi2c5;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ rtc0 = &rtc_i2c;
+ rtc1 = &scmi_bbm;
+ serial0 = &lpuart3;
+ serial1 = &lpuart7;
+ serial2 = &lpuart1;
+ serial3 = &lpuart2;
+ usb0 = &usb3;
+ usb1 = &usb2;
+ };
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ aquila_key_wake: gpio-key-wakeup {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ctrl_wake1_mico>;
+
+ status = "disabled";
+
+ key-wakeup {
+ /* Aquila CTRL_WAKE1_MICO# */
+ gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
+ label = "Wake Up";
+ wakeup-source;
+ linux,code = <KEY_WAKEUP>;
+ };
+ };
+
+ clk_dsi2dp_refclk: clock-dsi2dp-refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <27000000>;
+ };
+
+ clk_dsi2dp_refclk_en: clock-dsi2dp-refclk-en {
+ compatible = "gpio-gate-clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ctrl_dp_clk_en>;
+ clocks = <&clk_dsi2dp_refclk>;
+ #clock-cells = <0>;
+ /* CTRL_DP_CLK_EN */
+ enable-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ clk_serdes_eth_ref: clock-serdes-eth-ref {
+ compatible = "gpio-gate-clock";
+ #clock-cells = <0>;
+ /* CTRL_ETH_REF_CLK_STBY */
+ enable-gpios = <&som_gpio_expander_0 6 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "On-module +V1.8";
+ };
+
+ reg_dp_1p2v: regulator-dp-1p2v {
+ compatible = "regulator-fixed";
+ /* CTRL_DP_BRIDGE_EN */
+ gpios = <&som_gpio_expander_0 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ regulator-max-microvolt = <1200000>;
+ regulator-min-microvolt = <1200000>;
+ regulator-name = "On-module +V1.2_DP";
+ vin-supply = <®_1p8v>;
+ };
+
+ reg_usb1_vbus: regulator-usb1-vbus {
+ compatible = "regulator-fixed";
+ /* Aquila USB_1_EN */
+ gpios = <&som_gpio_expander_0 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-name = "USB_1_EN";
+ };
+
+ reg_usb2_vbus: regulator-usb2-vbus {
+ compatible = "regulator-fixed";
+ /* Aquila USB_2_EN */
+ gpios = <&som_gpio_expander_0 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-name = "USB_2_H_EN";
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sd1_pwr_en>;
+ /* Aquila SD_1_PWR_EN */
+ gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ off-on-delay-us = <100000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "SD_1_PWR_EN";
+ startup-delay-us = <20000>;
+ };
+
+ reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
+ compatible = "regulator-gpio";
+ /* PMIC_SD_1_VSEL */
+ gpios = <&som_gpio_expander_1 9 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "PMIC_SD_1_VSEL";
+ states = <1800000 0x1>,
+ <3300000 0x0>;
+ };
+
+ remoteproc-cm7 {
+ compatible = "fsl,imx95-cm7";
+ mboxes = <&mu7 0 1 &mu7 1 1 &mu7 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ linux_cma: linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x3c000000>;
+ alloc-ranges = <0 0x80000000 0 0x7f000000>;
+ linux,cma-default;
+ };
+
+ m7_reserved: memory@80000000 {
+ reg = <0 0x80000000 0 0x1000000>;
+ no-map;
+ };
+
+ rsc_table: rsc-table@88220000 {
+ reg = <0 0x88220000 0 0x1000>;
+ no-map;
+ };
+
+ vdev0vring0: vdev0vring0@88000000 {
+ reg = <0 0x88000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@88008000 {
+ reg = <0 0x88008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: vdev1vring0@88010000 {
+ reg = <0 0x88010000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: vdev1vring1@88018000 {
+ reg = <0 0x88018000 0 0x8000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@88020000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x88020000 0 0x100000>;
+ no-map;
+ };
+ };
+};
+
+/* Aquila ADC_[1-4] */
+&adc1 {
+ vref-supply = <®_1p8v>;
+};
+
+/* Aquila ETH_1 */
+&enetc_port0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enetc0>;
+ phy-handle = <ðphy1>;
+ phy-mode = "rgmii-id";
+};
+
+/* Aquila CAN_1 */
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+};
+
+/* Aquila CAN_2 */
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+};
+
+/* Aquila CAN_3 */
+&flexcan3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan3>;
+};
+
+/* Aquila CAN_4 */
+&flexcan4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan4>;
+};
+
+/* Aquila QSPI_1 */
+&flexspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi1_8bit>,
+ <&pinctrl_qspi_cs1>;
+};
+
+&gpio1 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_C24", /* 10 */
+ "",
+ "AQUILA_B17",
+ "CTRL_GPIO_EXP_INT#",
+ "AQUILA_B18";
+
+ status = "okay";
+};
+
+&gpio2 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_B42",
+ "",
+ "AQUILA_B43";
+};
+
+&gpio3 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_A11",
+ "", /* 20 */
+ "AQUILA_B57",
+ "AQUILA_B19";
+};
+
+&gpio4 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_C22",
+ "AQUILA_C21",
+ "AQUILA_C20",
+ "", /* 20 */
+ "",
+ "",
+ "AQUILA_C23",
+ "AQUILA_D23",
+ "AQUILA_D24",
+ "",
+ "AQUILA_D25";
+};
+
+&gpio5 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "AQUILA_B44",
+ "AQUILA_B45";
+};
+
+/* Aquila I2C_2 */
+&i3c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c2>;
+ i2c-scl-hz = <100000>;
+};
+
+/* Aquila I2C_1 */
+&lpi2c2 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c2>;
+ pinctrl-1 = <&pinctrl_lpi2c2_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio1 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio1 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* On-module I2C - I2C_SOM */
+&lpi2c3 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c3>, <&pinctrl_ctrl_gpio_exp_int>;
+ pinctrl-1 = <&pinctrl_lpi2c3_gpio>, <&pinctrl_ctrl_gpio_exp_int>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <400000>;
+ scl-gpios = <&gpio2 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ status = "okay";
+
+ som_gpio_expander_0: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names =
+ "AQUILA_C38", /* 0 */
+ "PCIE_2_RESET#",
+ "AQUILA_B77",
+ "USB_2_H_EN",
+ "BT_DISABLE#",
+ "WIFI_DISABLE#",
+ "CTRL_ETH_REF_CLK_STBY",
+ "CTRL_DP_BRIDGE_EN";
+ };
+
+ som_gpio_expander_1: gpio@21 {
+ compatible = "nxp,pcal6416";
+ reg = <0x21>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio1>;
+ interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names =
+ "AQUILA_C1", /* 0 */
+ "AQUILA_C2",
+ "AQUILA_C3",
+ "AQUILA_C4",
+ "AQUILA_C36",
+ "AQUILA_B74",
+ "AQUILA_B75",
+ "USB_2_H_OC#",
+ "AQUILA_B81",
+ "PMIC_SD_1_VSEL",
+ "ETH_1_INT#", /* 10 */
+ "CTRL_TPM_INT#",
+ "SPI_2_CS2_TPM",
+ "PCIE_WAKE_WIFI#",
+ "WIFI_WAKE_BT",
+ "WIFI_WAKEUP_HOST";
+ };
+
+ som_dsi2dp_bridge: bridge@2c {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2c>;
+ clocks = <&clk_dsi2dp_refclk_en>;
+ clock-names = "refclk";
+ vcc-supply = <®_dp_1p2v>;
+ vcca-supply = <®_dp_1p2v>;
+ vccio-supply = <®_1p8v>;
+ vpll-supply = <®_1p8v>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi2dp_in: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dsi2dp_out: endpoint {
+ data-lanes = <3 2 1 0>;
+ };
+ };
+ };
+ };
+
+ rtc_i2c: rtc@32 {
+ compatible = "epson,rx8130";
+ reg = <0x32>;
+ };
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp1075";
+ reg = <0x48>;
+ };
+
+ som_eeprom: eeprom@50 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+/* Aquila I2C_4_CSI1 */
+&lpi2c4 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c4>;
+ pinctrl-1 = <&pinctrl_lpi2c4_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio2 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 30 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* Aquila I2C_6 */
+&lpi2c5 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c5>;
+ pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio2 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* Aquila I2C_3_DSI1/I2C_5_CSI2 */
+&lpi2c8 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c8>;
+ pinctrl-1 = <&pinctrl_lpi2c8_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio2 13 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 12 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* Aquila SPI_2 */
+&lpspi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi4>;
+ cs-gpios = <&gpio2 18 GPIO_ACTIVE_LOW>,
+ <&som_gpio_expander_1 12 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ som_tpm: tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <0x1>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ /*
+ * Maximum TPM-supported speed is 18.5 MHz, limited to 12 MHz
+ * here as lpspi4's per-clock (2x the max speed) is 24 MHz.
+ */
+ spi-max-frequency = <12000000>;
+ };
+};
+
+/* Aquila SPI_1 */
+&lpspi6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi6>;
+ cs-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+};
+
+/* Aquila UART_3, used as the Linux Console */
+&lpuart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+};
+
+/* Aquila UART_4 */
+&lpuart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+};
+
+/* Aquila UART_1 */
+&lpuart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ uart-has-rtscts;
+};
+
+/* Aquila UART_2 */
+&lpuart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ uart-has-rtscts;
+};
+
+&mu7 {
+ status = "okay";
+};
+
+/* Aquila ETH_2_XGMII_MDIO, shared between all ethernet ports */
+&netc_emdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emdio>;
+
+ status = "okay";
+
+ ethphy1: ethernet-phy@1 {
+ reg = <1>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ };
+};
+
+&netcmix_blk_ctrl {
+ status = "okay";
+};
+
+&netc_blk_ctrl {
+ status = "okay";
+};
+
+&netc_timer {
+ status = "okay";
+};
+
+/* Aquila PCIE_1 */
+&pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie0>;
+ reset-gpios = <&som_gpio_expander_0 0 GPIO_ACTIVE_LOW>;
+};
+
+/* On-module Wi-Fi or Aquila PCIE_2 */
+&pcie1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie1>;
+ reset-gpios = <&som_gpio_expander_0 1 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+};
+
+/* Aquila I2S_1 */
+&sai2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai2>;
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_SAI2>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <12288000>;
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+};
+
+&scmi_bbm {
+ linux,code = <KEY_POWER>;
+};
+
+&thermal_zones {
+ /* PF09 Main PMIC */
+ pf09-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 2>;
+
+ trips {
+ trip0 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ /* PF53 VDD_ARM PMIC */
+ pf53-arm-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 4>;
+
+ trips {
+ trip0 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ /* PF53 VDD_SOC PMIC */
+ pf53-soc-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 3>;
+
+ trips {
+ trip0 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+};
+
+/* Aquila PWM_1 */
+&tpm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+};
+
+/* Aquila PWM_2 */
+&tpm6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+};
+
+/* Aquila PWM_3_DSI and PWM_4_DP */
+&tpm5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3_dsi>, <&pinctrl_pwm4_dp>;
+};
+
+/* Aquila USB_2, optional Bluetooth USB */
+&usb2 {
+ dr_mode = "host";
+ vbus-supply = <®_usb2_vbus>;
+};
+
+/* Aquila USB_1 */
+&usb3 {
+ fsl,disable-port-power-control;
+};
+
+&usb3_dwc3 {
+ dr_mode = "otg";
+ adp-disable;
+ hnp-disable;
+ srp-disable;
+ usb-role-switch;
+};
+
+&usb3_phy {
+ vbus-supply = <®_usb1_vbus>;
+};
+
+/* On-module eMMC */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ no-sdio;
+ no-sd;
+
+ status = "okay";
+};
+
+/* Aquila SD_1 */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_sd1_cd_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2>, <&pinctrl_sd1_cd_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>,<&pinctrl_sd1_cd_gpio>;
+ pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_sd1_cd_gpio>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ vqmmc-supply = <®_usdhc2_vqmmc>;
+};
+
+&wdog3 {
+ fsl,ext-reset-output;
+
+ status = "okay";
+};
+
+&scmi_iomuxc {
+ /* Aquila CTRL_WAKE1_MICO# */
+ pinctrl_ctrl_wake1_mico: ctrlwake1micogrp {
+ fsl,pins = <IMX95_PAD_XSPI1_SS1_B__GPIO5_IO_BIT11 0x31e>; /* Aquila D6 */
+ };
+
+ pinctrl_ctrl_dp_clk_en: dpclkengrp {
+ fsl,pins = <IMX95_PAD_SAI1_TXFS__AONMIX_TOP_GPIO1_IO_BIT11 0x11e>; /* CTRL_DP_CLK_EN */
+ };
+
+ /* Aquila ETH_2_XGMII_MDIO */
+ pinctrl_emdio: emdiogrp {
+ fsl,pins = <IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC 0x57e>, /* Aquila B90 */
+ <IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO 0x97e>; /* Aquila B89 */
+ };
+
+ /* Aquila ETH_1 */
+ pinctrl_enetc0: enetc0grp {
+ fsl,pins = <IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL 0x57e>, /* ENET1_TX_CTL */
+ <IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK 0x58e>, /* ENET1_TXC */
+ <IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0 0x50e>, /* ENET1_TDO */
+ <IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1 0x50e>, /* ENET1_TD1 */
+ <IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2 0x50e>, /* ENET1_TD2 */
+ <IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3 0x50e>, /* ENET1_TD3 */
+ <IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL 0x57e>, /* ENET1_RX_CTL */
+ <IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK 0x58e>, /* ENET1_RXC */
+ <IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0 0x57e>, /* ENET1_RD0 */
+ <IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1 0x57e>, /* ENET1_RD1 */
+ <IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2 0x57e>, /* ENET1_RD2 */
+ <IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3 0x57e>; /* ENET1_RD3 */
+ };
+
+ /* Aquila CAN_1 */
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <IMX95_PAD_PDM_CLK__AONMIX_TOP_CAN1_TX 0x39e>, /* Aquila B48 */
+ <IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_CAN1_RX 0x39e>; /* Aquila B49 */
+ };
+
+ /* Aquila CAN_2 */
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO25__CAN2_TX 0x39e>, /* Aquila B50 */
+ <IMX95_PAD_GPIO_IO27__CAN2_RX 0x39e>; /* Aquila B51 */
+ };
+
+ /* Aquila CAN_3 */
+ pinctrl_flexcan3: flexcan3grp {
+ fsl,pins = <IMX95_PAD_CCM_CLKO3__CAN3_TX 0x39e>, /* Aquila B53 */
+ <IMX95_PAD_CCM_CLKO4__CAN3_RX 0x39e>; /* Aquila B54 */
+ };
+
+ /* Aquila CAN_4 */
+ pinctrl_flexcan4: flexcan4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO04__CAN4_TX 0x39e>, /* Aquila B55 */
+ <IMX95_PAD_GPIO_IO05__CAN4_RX 0x39e>; /* Aquila B56 */
+ };
+
+ /* Aquila QSPI_1 (8 bit) */
+ pinctrl_flexspi1_8bit: flexspi18bitgrp {
+ fsl,pins = <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x3fe>, /* Aquila B65 */
+ <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x3fe>, /* Aquila B68 */
+ <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x3fe>, /* Aquila B67 */
+ <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x3fe>, /* Aquila B61 */
+ <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x3fe>, /* Aquila B60 */
+ <IMX95_PAD_XSPI1_DATA4__FLEXSPI1_A_DATA_BIT4 0x3fe>, /* Aquila B70 */
+ <IMX95_PAD_XSPI1_DATA5__FLEXSPI1_A_DATA_BIT5 0x3fe>, /* Aquila B71 */
+ <IMX95_PAD_XSPI1_DATA6__FLEXSPI1_A_DATA_BIT6 0x3fe>, /* Aquila B72 */
+ <IMX95_PAD_XSPI1_DATA7__FLEXSPI1_A_DATA_BIT7 0x3fe>, /* Aquila B73 */
+ <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x3fe>; /* Aquila B63 */
+ };
+
+ /* Aquila QSPI_1 (4 bit) */
+ pinctrl_flexspi1_4bit: flexspi18bitgrp {
+ fsl,pins = <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x3fe>, /* Aquila B65 */
+ <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x3fe>, /* Aquila B68 */
+ <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x3fe>, /* Aquila B67 */
+ <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x3fe>, /* Aquila B61 */
+ <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x3fe>, /* Aquila B60 */
+ <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x3fe>; /* Aquila B63 */
+ };
+
+ /* Aquila GPIO_01 */
+ pinctrl_gpio_1: gpio1grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD0__GPIO4_IO_BIT24 0x31e>; /* Aquila D23 */
+ };
+
+ /* Aquila GPIO_02 */
+ pinctrl_gpio_2: gpio2grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD1__GPIO4_IO_BIT25 0x31e>; /* Aquila D24 */
+ };
+
+ /* Aquila GPIO_03 */
+ pinctrl_gpio_3: gpio3grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD3__GPIO4_IO_BIT27 0x31e>; /* Aquila D25 */
+ };
+
+ /* Aquila GPIO_04 */
+ pinctrl_gpio_4: gpio4grp {
+ fsl,pins = <IMX95_PAD_ENET2_TD0__GPIO4_IO_BIT19 0x31e>; /* Aquila C20 */
+ };
+
+ /* Aquila GPIO_05 */
+ pinctrl_gpio_5: gpio5grp {
+ fsl,pins = <IMX95_PAD_ENET2_TD1__GPIO4_IO_BIT18 0x31e>; /* Aquila C21 */
+ };
+
+ /* Aquila GPIO_06 */
+ pinctrl_gpio_6: gpio6grp {
+ fsl,pins = <IMX95_PAD_ENET2_TD2__GPIO4_IO_BIT17 0x31e>; /* Aquila C22 */
+ };
+
+ /* Aquila GPIO_07 */
+ pinctrl_gpio_7: gpio7grp {
+ fsl,pins = <IMX95_PAD_ENET2_RXC__GPIO4_IO_BIT23 0x31e>; /* Aquila C23 */
+ };
+
+ /* Aquila GPIO_08 */
+ pinctrl_gpio_8: gpio8grp {
+ fsl,pins = <IMX95_PAD_PDM_BIT_STREAM1__AONMIX_TOP_GPIO1_IO_BIT10 0x31e>; /* Aquila C24 */
+ };
+
+ /* Aquila GPIO_09_CSI_1 */
+ pinctrl_gpio_9_csi_1: gpio9csi1grp {
+ fsl,pins = <IMX95_PAD_SAI1_TXC__AONMIX_TOP_GPIO1_IO_BIT12 0x31e>; /* Aquila B17 */
+ };
+
+ /* Aquila GPIO_10_CSI_1 */
+ pinctrl_gpio_10_csi_1: gpio10csi1grp {
+ fsl,pins = <IMX95_PAD_SAI1_RXD0__AONMIX_TOP_GPIO1_IO_BIT14 0x31e>; /* Aquila B18 */
+ };
+
+ /* Aquila GPIO_11_CSI_1 */
+ pinctrl_gpio_11_csi_1: gpio11csi1grp {
+ fsl,pins = <IMX95_PAD_SD2_VSELECT__GPIO3_IO_BIT19 0x31e>; /* Aquila A11*/
+ };
+
+ /* Aquila GPIO_12_CSI_1 */
+ pinctrl_gpio_12_csi_1: gpio12csi1grp {
+ fsl,pins = <IMX95_PAD_SD3_DATA0__GPIO3_IO_BIT22 0x31e>; /* Aquila B19 */
+ };
+
+ /* Aquila GPIO_17_DSI_1 */
+ pinctrl_gpio_17_dsi_1: gpio17dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO07__GPIO2_IO_BIT7 0x31e>; /* Aquila B42 */
+ };
+
+ /* Aquila GPIO_18_DSI_1 */
+ pinctrl_gpio_18_dsi_1: gpio18dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO09__GPIO2_IO_BIT9 0x31e>; /* Aquila B43 */
+ };
+
+ /* Aquila GPIO_19_DSI_1 */
+ pinctrl_gpio_19_dsi_1: gpio19dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO33__GPIO5_IO_BIT13 0x31e>; /* Aquila B44 */
+ };
+
+ /* Aquila GPIO_20_DSI_1 */
+ pinctrl_gpio_20_dsi_1: gpio20dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14 0x31e>; /* Aquila B45 */
+ };
+
+ /* Aquila GPIO_21_DP */
+ pinctrl_gpio_21_dp: gpio21dpgrp {
+ fsl,pins = <IMX95_PAD_SD3_CMD__GPIO3_IO_BIT21 0x31e>; /* Aquila B57 */
+ };
+
+ pinctrl_ctrl_gpio_exp_int: gpioexpintgrp {
+ fsl,pins = <IMX95_PAD_SAI1_TXD0__AONMIX_TOP_GPIO1_IO_BIT13 0x31e>; /* CTRL_GPIO_EXP_INT# */
+ };
+
+ /* Aquila I2C_2 */
+ pinctrl_i3c2: i3c2cgrp {
+ fsl,pins = <IMX95_PAD_ENET1_MDC__I3C2_SCL 0x40001186>, /* Aquila C17 */
+ <IMX95_PAD_ENET1_MDIO__I3C2_SDA 0x40001186>; /* Aquila C16 */
+ };
+
+ /* Aquila I2C_1 as GPIOs */
+ pinctrl_lpi2c2_gpio: lpi2c2gpiogrp {
+ fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_GPIO1_IO_BIT2 0x40001b9e>, /* Aquila D8 */
+ <IMX95_PAD_I2C2_SDA__AONMIX_TOP_GPIO1_IO_BIT3 0x40001b9e>; /* Aquila D7 */
+ };
+
+ /* Aquila I2C_1 */
+ pinctrl_lpi2c2: lpi2c2grp {
+ fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL 0x40001b9e>, /* Aquila D8 */
+ <IMX95_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA 0x40001b9e>; /* Aquila D7 */
+ };
+
+ /* On-module I2C as GPIOs */
+ pinctrl_lpi2c3_gpio: lpi2c3gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO28__GPIO2_IO_BIT28 0x40001b9e>, /* I2C_SOM_SDA */
+ <IMX95_PAD_GPIO_IO29__GPIO2_IO_BIT29 0x40001b9e>; /* I2C_SOM_SCL */
+ };
+
+ /* On-module I2C */
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO28__LPI2C3_SDA 0x40001b9e>, /* I2C_SOM_SDA */
+ <IMX95_PAD_GPIO_IO29__LPI2C3_SCL 0x40001b9e>; /* I2C_SOM_SCL */
+ };
+
+ /* Aquila I2C_4_CSI1 as GPIO */
+ pinctrl_lpi2c4_gpio: lpi2c4gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO30__GPIO2_IO_BIT30 0x40001b9e>, /* Aquila A12 */
+ <IMX95_PAD_GPIO_IO31__GPIO2_IO_BIT31 0x40001b9e>; /* Aquila A13 */
+ };
+
+ /* Aquila I2C_4_CSI1 */
+ pinctrl_lpi2c4: lpi2c4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO30__LPI2C4_SDA 0x40001b9e>, /* Aquila A12 */
+ <IMX95_PAD_GPIO_IO31__LPI2C4_SCL 0x40001b9e>; /* Aquila A13 */
+ };
+
+ /* Aquila I2C_6 as GPIO */
+ pinctrl_lpi2c5_gpio: lpi2c5gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO22__GPIO2_IO_BIT22 0x40001b9e>, /* Aquila C18 */
+ <IMX95_PAD_GPIO_IO23__GPIO2_IO_BIT23 0x40001b9e>; /* Aquila C19 */
+ };
+
+ /* Aquila I2C_6 */
+ pinctrl_lpi2c5: lpi2c5grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO22__LPI2C5_SDA 0x40001b9e>, /* Aquila C18 */
+ <IMX95_PAD_GPIO_IO23__LPI2C5_SCL 0x40001b9e>; /* Aquila C19 */
+ };
+
+ /* Aquila I2C_3_DSI1/I2C_5_CSI2 as GPIO */
+ pinctrl_lpi2c8_gpio: lpi2c8gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO12__GPIO2_IO_BIT12 0x40001b9e>, /* Aquila C5/B40 */
+ <IMX95_PAD_GPIO_IO13__GPIO2_IO_BIT13 0x40001b9e>; /* Aquila C6/B41 */
+ };
+
+ /* Aquila I2C_3_DSI1/I2C_5_CSI2 */
+ pinctrl_lpi2c8: lpi2c8grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO12__LPI2C8_SDA 0x40001b9e>, /* Aquila C5/B40 */
+ <IMX95_PAD_GPIO_IO13__LPI2C8_SCL 0x40001b9e>; /* Aquila C6/B41 */
+ };
+
+ /* Aquila SPI_2 */
+ pinctrl_lpspi4: lpspi4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO18__GPIO2_IO_BIT18 0x3fe>, /* Aquila D16 */
+ <IMX95_PAD_GPIO_IO19__LPSPI4_SIN 0x3fe>, /* Aquila D15 */
+ <IMX95_PAD_GPIO_IO20__LPSPI4_SOUT 0x3fe>, /* Aquila D17 */
+ <IMX95_PAD_GPIO_IO21__LPSPI4_SCK 0x3fe>; /* Aquila D14 */
+ };
+
+ /* Aquila SPI_1 */
+ pinctrl_lpspi6: lpspi6grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO00__GPIO2_IO_BIT0 0x3fe>, /* Aquila D9 */
+ <IMX95_PAD_GPIO_IO01__LPSPI6_SIN 0x3fe>, /* Aquila D10 */
+ <IMX95_PAD_GPIO_IO02__LPSPI6_SOUT 0x3fe>, /* Aquila D11 */
+ <IMX95_PAD_GPIO_IO03__LPSPI6_SCK 0x3fe>; /* Aquila D12 */
+ };
+
+ /* Aquila PCIE_1 */
+ pinctrl_pcie0: pcie0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B 0x40001b1e>; /* Aquila C37 */
+ };
+
+ /* Aquila PCIE_2 */
+ pinctrl_pcie1: pcie1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x40001b1e>; /* Aquila C34 */
+ };
+
+ /* Aquila QSPI_1_CS1# */
+ pinctrl_qspi_cs1: qspics1grp {
+ fsl,pins = <IMX95_PAD_XSPI1_SS0_B__FLEXSPI1_A_SS0_B 0x3fe>; /* Aquila B66 */
+ };
+
+ /* Aquila QSPI_1_CS2# as GPIO */
+ pinctrl_qspi_cs2_gpio: qspics2gpiogrp {
+ fsl,pins = <IMX95_PAD_CCM_CLKO2__GPIO3_IO_BIT27 0x3fe>; /* Aquila B62 */
+ };
+
+ /* Aquila I2S_1 */
+ pinctrl_sai2: sai2grp {
+ fsl,pins = <IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_SAI2_TX_SYNC 0x11e>, /* Aquila B21 */
+ <IMX95_PAD_ENET2_TXC__NETCMIX_TOP_SAI2_TX_BCLK 0x11e>, /* Aquila B20 */
+ <IMX95_PAD_ENET2_TD3__NETCMIX_TOP_SAI2_RX_DATA_BIT0 0x11e>, /* Aquila B23 */
+ <IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_SAI2_TX_DATA_BIT0 0x11e>; /* Aquila B22 */
+ };
+
+ pinctrl_sai2_mclk: sai2mclkgrp {
+ fsl,pins = <IMX95_PAD_ENET2_RD2__NETCMIX_TOP_SAI2_MCLK 0x31e>; /* Aquila B24 */
+ };
+
+ /* Aquila SD_1_CD# as GPIO */
+ pinctrl_sd1_cd_gpio: sd1cdgpiogrp {
+ fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>; /* Aquila A1 */
+ };
+
+ /* Aquila SD_1_PWR_EN */
+ pinctrl_sd1_pwr_en: sd1pwrengpiogrp {
+ fsl,pins = <IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7 0x11e>; /* Aquila A6 */
+ };
+
+ /* Aquila PWM_1 */
+ pinctrl_pwm1: tpm3ch3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO24__TPM3_CH3 0x11e>; /* Aquila C25 */
+ };
+
+ /* Aquila PWM_3_DSI as GPIO */
+ pinctrl_pwm3_dsi_gpio: tpm5ch0gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO06__GPIO2_IO_BIT6 0x11e>; /* Aquila B46 */
+ };
+
+ /* Aquila PWM_3_DSI */
+ pinctrl_pwm3_dsi: tpm5ch0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO06__TPM5_CH0 0x11e>; /* Aquila B46 */
+ };
+
+ /* Aquila PWM_4_DP */
+ pinctrl_pwm4_dp: tpm5ch3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO26__TPM5_CH3 0x11e>; /* Aquila B58 */
+ };
+
+ /* Aquila PWM_2 */
+ pinctrl_pwm2: tpm6ch0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO08__TPM6_CH0 0x11e>; /* Aquila C26 */
+ };
+
+ /* Aquila UART_3 */
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e>, /* Aquila D20 */
+ <IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x31e>; /* Aquila D19 */
+ };
+
+ /* Aquila UART_4 */
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <IMX95_PAD_UART2_TXD__AONMIX_TOP_LPUART2_TX 0x31e>, /* Aquila D22 */
+ <IMX95_PAD_UART2_RXD__AONMIX_TOP_LPUART2_RX 0x31e>; /* Aquila D21 */
+ };
+
+ /* Aquila UART_1 */
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO14__LPUART3_TX 0x31e>, /* Aquila B37 */
+ <IMX95_PAD_GPIO_IO15__LPUART3_RX 0x31e>, /* Aquila B35 */
+ <IMX95_PAD_GPIO_IO16__LPUART3_CTS_B 0x31e>, /* Aquila B36 */
+ <IMX95_PAD_GPIO_IO17__LPUART3_RTS_B 0x31e>; /* Aquila B38 */
+ };
+
+ /* Aquila UART_2 */
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO36__LPUART7_TX 0x31e>, /* Aquila B33 */
+ <IMX95_PAD_GPIO_IO37__LPUART7_RX 0x31e>, /* Aquila B31 */
+ <IMX95_PAD_GPIO_IO10__LPUART7_CTS_B 0x31e>, /* Aquila B32 */
+ <IMX95_PAD_GPIO_IO11__LPUART7_RTS_B 0x31e>; /* Aquila B34 */
+ };
+
+ /* On-module eMMC */
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>, /* eMMC_CLK */
+ <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>, /* eMMC_CMD */
+ <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>, /* eMMC_DATA0 */
+ <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>, /* eMMC_DATA1 */
+ <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>, /* eMMC_DATA2 */
+ <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>, /* eMMC_DATA3 */
+ <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>, /* eMMC_DATA4 */
+ <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>, /* eMMC_DATA5 */
+ <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>, /* eMMC_DATA6 */
+ <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>, /* eMMC_DATA7 */
+ <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>; /* eMMC_STROBE */
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x15fe>, /* eMMC_CLK */
+ <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x13fe>, /* eMMC_CMD */
+ <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe>, /* eMMC_DATA0 */
+ <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe>, /* eMMC_DATA1 */
+ <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe>, /* eMMC_DATA2 */
+ <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe>, /* eMMC_DATA3 */
+ <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe>, /* eMMC_DATA4 */
+ <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe>, /* eMMC_DATA5 */
+ <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe>, /* eMMC_DATA6 */
+ <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe>, /* eMMC_DATA7 */
+ <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe>; /* eMMC_STROBE */
+ };
+
+ /* Aquila SD_1 */
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x158e>, /* Aquila A5 */
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x138e>, /* Aquila A7 */
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e>, /* Aquila A3 */
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e>, /* Aquila A2 */
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e>, /* Aquila A10 */
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e>; /* Aquila A8 */
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x15fe>, /* Aquila A5 */
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x13fe>, /* Aquila A7 */
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x13fe>, /* Aquila A3 */
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x13fe>, /* Aquila A2 */
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x13fe>, /* Aquila A10 */
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe>; /* Aquila A8 */
+ };
+
+ pinctrl_usdhc2_sleep: usdhc2-sleepgrp {
+ fsl,pins = <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x400>, /* Aquila A5 */
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x400>, /* Aquila A7 */
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x400>, /* Aquila A3 */
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x400>, /* Aquila A2 */
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x400>, /* Aquila A10 */
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x400>; /* Aquila A8 */
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] media: s5p-mfc: avoid double free on video register failure
From: Marek Szyprowski @ 2026-05-20 11:37 UTC (permalink / raw)
To: Guangshuo Li, Andrzej Hajda, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media, linux-kernel
In-Reply-To: <20260518130929.1003652-1-lgs201920130244@gmail.com>
On 18.05.2026 15:09, Guangshuo Li wrote:
> s5p_mfc_probe() allocates video_device instances for both the decoder
> and encoder and releases them from the probe error paths if
> video_register_device() fails.
>
> This can double free a video_device when __video_register_device()
> reaches device_register() and that call fails:
>
> video_register_device()
> -> __video_register_device()
> -> device_register() fails
> -> put_device(&vdev->dev)
> -> v4l2_device_release()
> -> vdev->release(vdev)
> -> video_device_release(vdev)
>
> s5p_mfc_probe()
> -> err_dec_reg or err_enc_reg
> -> video_device_release(vdev)
>
> Use video_device_release_empty() while registering the decoder and encoder
> video devices so that registration failure paths do not free them through
> vdev->release(). s5p_mfc_probe() then releases each video_device exactly
> once from its error path. Restore video_device_release() after successful
> registration so the registered devices keep their normal lifetime
> handling.
>
> This issue was found by a static analysis tool I am developing.
>
> Fixes: d0ce898c39bf ("[media] s5p-mfc: Replaced commas with semicolons")
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Frankly speaking I don't like this dancing with video_device_release_empty() and
video_device_release(). I would rather make video_device struct a part of device
state and use common release function.
> ---
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> index 32eb402d439c..75abb0a8b7a9 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> @@ -1376,7 +1376,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> }
> vfd->fops = &s5p_mfc_fops;
> vfd->ioctl_ops = get_dec_v4l2_ioctl_ops();
> - vfd->release = video_device_release;
> + vfd->release = video_device_release_empty;
> vfd->lock = &dev->mfc_mutex;
> vfd->v4l2_dev = &dev->v4l2_dev;
> vfd->vfl_dir = VFL_DIR_M2M;
> @@ -1395,7 +1395,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> }
> vfd->fops = &s5p_mfc_fops;
> vfd->ioctl_ops = get_enc_v4l2_ioctl_ops();
> - vfd->release = video_device_release;
> + vfd->release = video_device_release_empty;
> vfd->lock = &dev->mfc_mutex;
> vfd->v4l2_dev = &dev->v4l2_dev;
> vfd->vfl_dir = VFL_DIR_M2M;
> @@ -1416,6 +1416,8 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
> goto err_dec_reg;
> }
> +
> + dev->vfd_dec->release = video_device_release;
> v4l2_info(&dev->v4l2_dev,
> "decoder registered as /dev/video%d\n", dev->vfd_dec->num);
>
> @@ -1424,6 +1426,8 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
> goto err_enc_reg;
> }
> +
> + dev->vfd_enc->release = video_device_release;
> v4l2_info(&dev->v4l2_dev,
> "encoder registered as /dev/video%d\n", dev->vfd_enc->num);
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: (subset) [PATCH v8 1/4] dt-bindings: backlight: Add max25014 support
From: Lee Jones @ 2026-05-20 11:47 UTC (permalink / raw)
To: Frank Li
Cc: Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Maud Spierings, dri-devel, linux-leds,
devicetree, linux-kernel, linux-fbdev, imx, linux-arm-kernel
In-Reply-To: <agyxLnTYstqRwGva@lizhi-Precision-Tower-5810>
On Tue, 19 May 2026, Frank Li wrote:
> On Thu, Apr 30, 2026 at 02:53:40PM +0100, Lee Jones wrote:
> > On Tue, 07 Apr 2026 16:41:42 +0200, Maud Spierings wrote:
> > > The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> > > with integrated boost controller.
> >
> > Applied, thanks!
> >
> > [1/4] dt-bindings: backlight: Add max25014 support
> > commit: 5fcbbedec9dfce78044eee922bf2030e1bd03faa
>
> Lee Jones:
>
> I have not seen it in linux-next. Anything wrong?
I don't know why Backlight hasn't been added to Linux Next.
Rest assured, it's applied to the Backlight tree.
--
Lee Jones
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: arm64: Introduce S2 walker SKIP return options
From: Leonardo Bras @ 2026-05-20 11:49 UTC (permalink / raw)
To: Oliver Upton
Cc: Leonardo Bras, Will Deacon, Marc Zyngier, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Fuad Tabba,
Raghavendra Rao Ananta, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <agzUZS1l-uHQoodG@kernel.org>
On Tue, May 19, 2026 at 02:21:41PM -0700, Oliver Upton wrote:
> On Tue, May 19, 2026 at 03:35:19PM +0100, Leonardo Bras wrote:
> > On Tue, May 19, 2026 at 02:15:41PM +0100, Will Deacon wrote:
> > > On Tue, May 19, 2026 at 01:56:48PM +0100, Leonardo Bras wrote:
> > > > On Tue, May 19, 2026 at 01:43:37PM +0100, Will Deacon wrote:
> > > > > > > I was wondering along similar lines, but maybe it would be useful just
> > > > > > > to pass a maximum level to the walker logic? That feels like the most
> > > > > > > general case without complicating the existing logic.
>
> FWIW, I had considered this too but decided that it requires a bit more
> churn since we cannot rely on zero initialization in the existing
> callsites (level 0 is a valid level).
>
> But that's extremely minor.
>
> > > > > > This proposal seems simpler for me to understand, and indeed looks like a
> > > > > > better solution than what I have proposed, taking care of the
> > > > > > 'already split' case with better performance, as it don't even walk a
> > > > > > single level-3 entry.
> > > > > >
> > > > > > On the 'splitting' case, it also works flawlessly if the memory is given in
> > > > > > level-2 blocks. There is only one case that I would like to address here:
> > > > > >
> > > > > > - Memory given in level-1 blocks (say 1GB)
> > > > > > - Walker flag says 'walk down to level-2 only'
> > > > > > - Split Walker on level-1 will break page down to (up to) level-3 entries.
> > > > > > - Walker will continue to be called on level-2 entries, even though it's
> > > > > > not necessary.
> > > > >
> > > > > If you're only visiting leaves, why would it be called on the level-2
> > > > > table entries?
> > > > >
> > > >
> > > > Because once the leaf is turned into a table by the splitting walker, it
> > > > gets reloaded and walked. This is an excerpt of __kvm_pgtable_visit():
> > >
> > > Sorry, I was musing about the semantics after adding something to limit
> > > the maximum level. I don't dispute what the current code would do.
> > >
> > > > Example:
> > > > - Split this level-1 leave:
> > > > - Walker creates the whole structure up to given level (currently 3)
> > > > - Walker returns, gets reloaded, table detected, go down on that one
> > > > - Level 2 entries walked (which is unnecessary)
> > > >
> > > > Please let me know if I am misunderstanding something.
> > >
> > > I just don't grok why this would happen if we limited the maximum level
> > > to '2' _and_ said we only wanted to visit the leaf entries. In that
> > > case, I wouldn't expect to descend into any of the L2 table entries
> > > (because that would imply going beyond level 2) and I wouldn't expect to
> > > be called for the table entries either (because we're only interested in
> > > leaves).
> >
> > Agree, if we specify to skip level-3 entries, it would only walk up to
> > level-2 entries, but take above example in detail:
> > - Split these level-1 leaves, up to level-3 leaves (regular)
> > - INFO: kvm_pgtable_walk will call walker:
> > - only up to level-2 entries (skip level-3)
> > - only on leaf entries
> > - Walk first level-1 leaf, calls walker
> > - walker will split the level-1 leaf in level-3 leaves
> > - walker return from that first level-1 leaf
> > - level-1 leaf is reloaded as a table
> > - level-2 entries of that table are also walked (unnecessary)
> > - on each of the level-2 table entries, level-3 entries are skipped
> >
> > To avoid the unecessary walk of the level-2 entries above, we would need to
> > specify 'skip level-2' that could be an issue if we have a mix of level-1
> > and level-2 leaves, as the level-2 leaves in that case would not be split.
> >
> > That's why I suggest something like "skip recently created table" as a flag
> > as well, so we can guarantee no newly created table gets walked
> > unecessarily.
> >
> > Please help me if I am missing something important.
>
> I'm not sure the added complexity of handling this case perfectly results
> in a measurable performance improvement. Just avoiding the level 3
> tables would be an exponential reduction (~ 512-8192x) in the number of
> walk steps.
>
Humm, I agree most of the improvement is due to skipping level-3 walks.
The added complexity would be, appart from a new flag, just a single line
change:
---
if (!table && (ctx.flags & KVM_PGTABLE_WALK_LEAF)) {
ret = kvm_pgtable_visitor_cb(data, &ctx, KVM_PGTABLE_WALK_LEAF);
- reload = true;
+ /* Do not reload if flagged to skip new table */
+ reload = !(ctx.flags & KVM_PGTABLE_WALK_SKIP_NEW_TABLE);
}
---
Even then, do you think it would not be worth having it?
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v2 4/7] mm/vmalloc: Extend page table walk to support larger page_shift sizes and eliminate page table rewalk
From: Mike Rapoport @ 2026-05-20 11:53 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260514094108.2016201-5-jiangwen6@xiaomi.com>
On Thu, 14 May 2026 17:41:05 +0800, Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
Hi,
> vmap_pages_range_noflush_walk() (formerly vmap_small_pages_range_noflush())
> provides a clean interface by taking struct page **pages and mapping them
> via direct PTE iteration. This avoids the page table rewalk seen when
> using vmap_range_noflush() for page_shift values other than PAGE_SHIFT.
>
> Extend it to support larger page_shift values, and add PMD- and
> contiguous-PTE mappings as well. Rename it to vmap_pages_range_noflush_walk()
> since it now handles more than just small pages.
>
> For vmalloc() allocations with VM_ALLOW_HUGE_VMAP, we no longer need to
> iterate over pages one by one via vmap_range_noflush(), which would
> otherwise lead to page table rewalk. The code is now unified with the
> PAGE_SHIFT case by simply calling vmap_pages_range_noflush_walk().
After this patch we have two very simalar page table walkers:
vmap_pages_range_noflush_walk() and vmap_range_noflush().
The subtly differ at what levels they try huge mappings, how they
account page table modifucations and, at last vmap_range_noflush() is
left without support for contiguous mappings.
Is there a fundamental reason to have two page walkers?
Is there a reason not to support contiguous mappings in
vmap_range_noflush()?
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 5/7] mm/vmalloc: map contiguous pages in batches for vmap() if possible
From: Mike Rapoport @ 2026-05-20 11:53 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260514094108.2016201-6-jiangwen6@xiaomi.com>
On Thu, 14 May 2026 17:41:06 +0800, Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 516d406507e9..c30a7673e0ac 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3520,6 +3520,77 @@ void vunmap(const void *addr)
> [ ... skip 25 lines ... ]
> +
> + return order;
> +}
> +
> +static int __vmap_huge(unsigned long addr, unsigned long end,
> + pgprot_t prot, struct page **pages)
This won't necessaryly create huge mappings, maybe vmap_batched?
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v02] mailbox: pcc: report errors for PCC clients
From: lihuisong (C) @ 2026-05-20 11:53 UTC (permalink / raw)
To: Sudeep Holla
Cc: Adam Young, Jassi Brar, linux-kernel, linux-hwmon,
Rafael J . Wysocki, Len Brown, linux-acpi, Andi Shyti,
Guenter Roeck, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
linux-arm-kernel
In-Reply-To: <20260519-outgoing-rough-fox-04daab@sudeepholla>
On 5/20/2026 12:25 AM, Sudeep Holla wrote:
> On Tue, May 19, 2026 at 09:54:47PM +0800, lihuisong (C) wrote:
>> On 5/19/2026 3:30 AM, Adam Young wrote:
>>> The tx_done callback function has a return code (rc) parameter
>>> that the tx_done callback can use to determine how to handle an error.
>>> However the IRQ handler was not setting that value if there is an error.
>>>
>>> The following clients are affected:
>>>
>>> drivers/acpi/cppc_acpi.c
>>> drivers/i2c/busses/i2c-xgene-slimpro.c
>>> drivers/hwmon/xgene-hwmon.c
>>> drivers/soc/hisilicon/kunpeng_hccs.c
>>> drivers/devfreq/hisi_uncore_freq.c
>>>
>>> All of these only use the error code to report, so they
>>> are expecting an error code to come thorugh, but they
>>> do not modify behavior based on this code.
>>>
>>> In the case of an error code in the IRQ, the handler was returning
>>> IRQ_NONE which is not correct: the IRQ handler was matched
>>> to the IRQ. This mean that multiple error codes returned from
>>> a PCC triggered interrupt would end up disabling the device.
>>>
>>> In addition, if the error code IRQ was coming from a Type4 Device that was
>>> expecting an IRQ response, that device would then be hung.
>>>
>>> Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)")
>> Not fix above commit.
>> mbox_chan_txdone() was added in below patch.
>> Fixes: 9c753f7c953c (mailbox: pcc: Mark Tx as complete in PCC IRQ handler)
>>> Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
>>>
>>> ---
>>> ---
>>> drivers/mailbox/pcc.c | 9 +++++----
>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>>> index 636879ae1db7..16b9ce087b9e 100644
>>> --- a/drivers/mailbox/pcc.c
>>> +++ b/drivers/mailbox/pcc.c
>>> @@ -314,6 +314,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> {
>>> struct pcc_chan_info *pchan;
>>> struct mbox_chan *chan = p;
>>> + int rc;
>>> pchan = chan->con_priv;
>>> @@ -327,8 +328,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> if (!pcc_mbox_cmd_complete_check(pchan))
>>> return IRQ_NONE;
>>> - if (pcc_mbox_error_check_and_clear(pchan))
>>> - return IRQ_NONE;
>>> + rc = pcc_mbox_error_check_and_clear(pchan);
>> I think it is not necessary. This function just return -EIO on failure.
>>
>>> /*
>>> * Clear this flag after updating interrupt ack register and just
>>> @@ -337,8 +337,9 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> * required to avoid any possible race in updatation of this flag.
>>> */
>>> pchan->chan_in_use = false;
>>> - mbox_chan_received_data(chan, NULL);
>>> - mbox_chan_txdone(chan, 0);
>>> + if (!rc)
>>> + mbox_chan_received_data(chan, NULL);
>>> + mbox_chan_txdone(chan, rc);
>> @Sudeep, I have always had doubts about the addition of this line of code in
>> the
>> commit 9c753f7c953c (mailbox: pcc: Mark Tx as complete in PCC IRQ handler).
>> The patch seems to avoid the timeouts in the mailbox core according to its
>> commit log.
>> Regardless of whether the command succeeds or fails, each mbox client
>> driver, like cppc_acpi/acpi_pcc，kunpeng_hccs and so on, is responsible to
>> call mbox_chan_txdone() to tell mailbox core.
> Few controller drivers do have mbox_chan_txdone(), so Tx complete is detected
Which controller driver?
> by PCC, so not sure why you think this is not the right place to do. The irq
Because many mbox client drivers call mbox_chan_txdone() after running
rx_callback() in mbox_chan_received_data().
These drivers doesn't set chan->cl->tx_block to true.
It seems that the client driver having tx_block need to set
chan->tx_complete in tx_tick().
Do you add this code for them?
> is to indicate the completion. I am confused as why you think otherwise.
> It is defined in include/linux/mailbox_controller.h for the same reason.
>
> The client drivers can you mbox_client_txdone() if they wish to as defined
> in include/linux/mailbox_client.h
mbox_client_txdone() is used in the case that txdone_method is
MBOX_TXDONE_BY_ACK.
And mbox clinte driver using IRQ method need to use mbox_chan_txdone().
It seems that all the current client drivers are used in this way.
These interface internal would verify chan->txdone_method.
In addition, I find that you also modify the txdone_irq/poll in the
commit 3349f800609e (mailbox: pcc: Set txdone_irq/txdone_poll based on
PCCT flags).
The txdone_method will change from MBOX_TXDONE_BY_ACK to
MBOX_TXDONE_BY_POLL on the platform using poll mode.
This may lead to the original mbox client driver printing exceptions in
mbox_client_txdone.
I haven't observed it based on the latest code yet, it's just code
analysis.
>
>> This is done after executing mbox_chan_received_data(). So I think this line
>> in this function is redundant.
> No, I think otherwise, see details above.
>
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2 platform
From: Pandey, Radhey Shyam @ 2026-05-20 11:55 UTC (permalink / raw)
To: Krzysztof Kozlowski, Radhey Shyam Pandey
Cc: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel, linux-usb, devicetree, linux-arm-kernel, linux-kernel,
git
In-Reply-To: <a51d0e53-3134-475d-a19f-67d7d0695cfe@kernel.org>
On 5/14/2026 9:30 PM, Krzysztof Kozlowski wrote:
> On 07/05/2026 21:01, Pandey, Radhey Shyam wrote:
>>> On Wed, Apr 29, 2026 at 11:00:47PM +0530, Radhey Shyam Pandey wrote:
>>>> additionalProperties: false
>>>>
>>>> examples:
>>>> @@ -156,3 +193,30 @@ examples:
>>>> };
>>>> };
>>>> };
>>>> + - |
>>>> + #include <dt-bindings/power/xlnx-zynqmp-power.h>
>>>> + #include <dt-bindings/reset/xlnx-zynqmp-resets.h>
>>>> + #include <dt-bindings/phy/phy.h>
>>>> + usb {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>> Please follow DTS coding style.
>> Thanks for the review. will fix it in next version.
>>>> + compatible = "xlnx,versal2-mmi-dwc3";
>>> I really doubt that DWC3 block comes without addressing space
>>> (registers), so either you just misrepresented things, like created a
>>> fake block and syscon, or forgot to combine DWC3 with the wrapper.
>>>
>>> And if you built with W=1 your DTS you would see errors. How do you see
>>> it now? Where do you place it? Wrapper must be outside of soc, but DWC3
>>> child must be inside. Did you read submitting patches and writing
>>> bindings documents?
>> Apologies for missing the DTS sanity check earlier. I am summarizing the
>> problem statement and possible solution. Please review.
>>
>> For MMI USB in current implementation it need a parent/child
>> representation. However, the parent IP is shared across DP, USB,
>> and HDCP, so it cannot have a USB-dedicated parent reg space.
>>
>> 1. Versal platform
>> - Parent: USB wrapper IP → has its own I/O space
>> - Child: USB DWC3
>>
>> 2. Versal Gen2 platform - MMI USB
>> - Parent subsystem combines DP, USB, and HDCP in a single I/O space
>> - Children:
>> - USB DWC3
>> - DP
>> - HDCP
>>
>> To model the Versal Gen2 MMI USB parent register space, I introduced
>> xlnx,usb-syscon, allowing the DWC3 driver to access parent registers
>> via a syscon handle, addressing the v1 review comment.
>
> Syscon phandle is not to express such relationsship.
>
>>
>> However, making reg optional satisfies schema validation but fails
>> DTB checks.
>>
>> versal2.dtsi:1: Warning (simple_bus_reg):
>> /axi/mmi-usb: missing or empty reg/ranges property
>
> Yep, exactly.
>
>>
>> To fix it i think we can switch from parent/child representation to
>> flat DT representation for the Versal Gen2 platform, similar to
>> existing implementations in qcom,snps-dwc3 and Google Tensor G5 DWC3
>> bindings[1].
>>
>> The Google Tensor DWC3 binding uses a syscon phandle to access USB
>> configuration registers, which aligns well with the Versal Gen2 MMI
>
> Not true. Just read the binding. If you refer to Tensor, then to access
> A FEW configuration registers. If you refer to LGA, then it has address
> space.
>
>> USB IP, where wrapper subsystem shares a common register space for
>> USB along with other IPs.
>
>
>
>>
>> If this approach looks fine , will create binding for MMI USB using
>> this flat representation and send out next version.
>>
>> usb@fe200000 {
>> compatible = "xlnx,versal2-mmi-dwc3";
>> reg = <0xfe200000 0x40000>;
>> xlnx,usb-syscon = <&udh_slcr 0x005c 0x0070 0x00c4 0x00f8>;
>> <snip>
>> };
>
> So I am confused. We ask, since long time, to have unified child.
> Several platforms were already converted. What are you discussing with
> in such case?
>
> Are you going to have unified node or not?
>
Yes, in next version will switch to a unified node representation for
Versal Gen2 MMI USB.
Based on your feedback:
-the fake wrapper hierarchy will be removed.
-parent node without reg will be dropped.
-syscon will not be used to model hierarchy.
Instead, I will introduce a separate unified-node binding for Versal
Gen2 MMI USB where: the USB controller register space is described
directly in the USB node, auxiliary USB configuration registers in
UDH SLCR are accessed through a syscon phandle only for sideband
configuration access.
New DT representation using single unified node.
usb@0xedec0000 {
compatible = "xlnx,versal2-mmi-dwc3", "snps,dwc3";
reg = <...>;
xlnx,usb-syscon = <&udh_slcr>;
<snip>
};
Thanks,
Radhey
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: ti: Update audio-refclk binding and j721e system controller
From: Moteen Shah @ 2026-05-20 11:56 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
In-Reply-To: <20260520115603.2662930-1-m-shah@ti.com>
Add ti,j721s2-audio-refclk as a supported compatible string in the
ti,am62-audio-refclk binding. J721S2 uses the same audio reference
clock IP block first introduced on AM62. Per writing-bindings
guidelines, the J721S2-specific compatible is added as the primary
string with ti,am62-audio-refclk as the fallback.
Also extend the ti,j721e-system-controller clock-controller@ child
pattern to accept audio-refclk schemas alongside ehrpwm-tbclk via a
oneOf constraint.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Moteen Shah <m-shah@ti.com>
---
.../devicetree/bindings/clock/ti,am62-audio-refclk.yaml | 8 ++++++--
.../bindings/soc/ti/ti,j721e-system-controller.yaml | 6 ++++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
index b2e40bd39a3a..6c8fb0793070 100644
--- a/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
+++ b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
@@ -11,8 +11,12 @@ maintainers:
properties:
compatible:
- items:
- - const: ti,am62-audio-refclk
+ oneOf:
+ - items:
+ - const: ti,am62-audio-refclk
+ - items:
+ - const: ti,j721s2-audio-refclk
+ - const: ti,am62-audio-refclk
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
index f3bd0be3b279..364be49f8c7c 100644
--- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
@@ -53,9 +53,11 @@ patternProperties:
"^clock-controller@[0-9a-f]+$":
type: object
- $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
+ oneOf:
+ - $ref: /schemas/clock/ti,am62-audio-refclk.yaml#
+ - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
description:
- Clock provider for TI EHRPWM nodes.
+ Clock provider for TI EHRPWM or Audio Reference Clock nodes.
"phy@[0-9a-f]+$":
type: object
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/2] arm64: dts: ti: Add audio overlay for k3-j721s2-evm
From: Moteen Shah @ 2026-05-20 11:56 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
In-Reply-To: <20260520115603.2662930-1-m-shah@ti.com>
From: Jayesh Choudhary <j-choudhary@ti.com>
Add device tree overlay to enable analog audio support on J721S2-EVM
using PCM3168A codec connected to McASP4 serializers.
- Add nodes for sound-card, audio codec, I2C3 and McASP4
- Add pinmux for I2C3, McASP4, AUDIO_EXT_REFCLK1 and WKUP_GPIO_0
- Add GPIO expander (TCA6408) for codec control
- Add GPIO hogs to route I2C3 lines and McASP serializers
- Set idle-state to 0 in mux0 and mux1 for McASP signal routing
- Disable main_mcan3 and main_mcan5 as they conflict with McASP4 signal routing via mux0 and mux1
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Co-developed-by: Moteen Shah <m-shah@ti.com>
Signed-off-by: Moteen Shah <m-shah@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 171 ++++++++++++++++++
2 files changed, 175 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index ba01a929e06f..17048f2f5043 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-audio.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
@@ -264,6 +265,8 @@ k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie1-ep.dtbo
k3-j721e-sk-csi2-dual-imx219-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-j721s2-evm-audio-dtbs := k3-j721s2-common-proc-board.dtb \
+ k3-j721s2-evm-audio.dtbo
k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
k3-j721s2-evm-pcie1-ep.dtbo
k3-j721s2-evm-usb0-type-a-dtbs := k3-j721s2-common-proc-board.dtb \
@@ -328,6 +331,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
+ k3-j721s2-evm-audio.dtb \
k3-j721s2-evm-pcie1-ep.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
new file mode 100644
index 000000000000..c467aa9ce647
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Device Tree Overlay for J721S2 Audio Support
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "k3-pinctrl.h"
+
+&{/} {
+ codec_audio: sound {
+ compatible = "ti,j7200-cpb-audio";
+ model = "j721s2-cpb";
+
+ ti,cpb-mcasp = <&mcasp4>;
+ ti,cpb-codec = <&pcm3168a_1>;
+
+ clocks = <&k3_clks 213 0>, <&k3_clks 213 1>,
+ <&k3_clks 157 299>, <&k3_clks 157 328>;
+ clock-names = "cpb-mcasp-auxclk", "cpb-mcasp-auxclk-48000",
+ "cpb-codec-scki", "cpb-codec-scki-48000";
+ };
+
+ i2c_mux: mux-controller-2 {
+ compatible = "gpio-mux";
+ #mux-state-cells = <1>;
+ mux-gpios = <&wkup_gpio0 54 GPIO_ACTIVE_HIGH>;
+ idle-state = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_mux_pins_default>;
+ };
+};
+
+&main_pmx0 {
+ mcasp4_pins_default: mcasp4-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x0c8, PIN_OUTPUT_PULLDOWN, 1) /* (AD28) MCASP4_ACLKX */
+ J721S2_IOPAD(0x06c, PIN_OUTPUT_PULLDOWN, 1) /* (V26) MCASP4_AFSX */
+ J721S2_IOPAD(0x068, PIN_INPUT_PULLDOWN, 1) /* (U28) MCASP4_AXR1 */
+ J721S2_IOPAD(0x0c4, PIN_OUTPUT_PULLDOWN, 1) /* (AB26) MCASP4_AXR2 */
+ J721S2_IOPAD(0x070, PIN_OUTPUT_PULLDOWN, 1) /* (R27) MCASP4_AXR3 */
+ >;
+ };
+
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x078, PIN_OUTPUT, 1) /* (Y25) MCAN2_RX.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+};
+
+&wkup_pmx2 {
+ main_i2c3_mux_pins_default: main-i2c3-mux-default-pins {
+ pinctrl-single,pins = <
+ J721S2_WKUP_IOPAD(0x038, PIN_OUTPUT, 7) /* (B27) WKUP_GPIO0_54 */
+ >;
+ };
+};
+
+&exp2 {
+ p09-hog {
+ /* P09 - MCASP/TRACE_MUX_S0 */
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "MCASP/TRACE_MUX_S0";
+ };
+
+ p10-hog {
+ /* P10 - MCASP/TRACE_MUX_S1 */
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MCASP/TRACE_MUX_S1";
+ };
+};
+
+&mux0 {
+ idle-state = <0>;
+};
+
+&mux1 {
+ idle-state = <0>;
+};
+
+&main_mcan3 {
+ /* Conflicts with McASP4 signal routing via mux0 */
+ status = "disabled";
+};
+
+&main_mcan5 {
+ /* Conflicts with McASP4 signal routing via mux1 */
+ status = "disabled";
+};
+
+&scm_conf {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ audio_refclk1: clock-controller@42e4 {
+ compatible = "ti,j721s2-audio-refclk", "ti,am62-audio-refclk";
+ reg = <0x42e4 0x4>;
+ clocks = <&k3_clks 157 299>;
+ assigned-clocks = <&k3_clks 157 299>;
+ assigned-clock-parents = <&k3_clks 157 328>;
+ #clock-cells = <0>;
+ };
+};
+
+&k3_clks {
+ /* Configure AUDIO_EXT_REFCLK1 pin as output */
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+};
+
+&main_i2c3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_pins_default>;
+ clock-frequency = <400000>;
+ mux-states = <&i2c_mux 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ exp3: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "CODEC_RSTZ", "CODEC_SPARE1",
+ "UB926_RESETN", "UB926_LOCK",
+ "UB926_PWR_SW_CNTRL", "UB926_TUNER_RESET",
+ "UB926_GPIO_SPARE";
+ };
+
+ pcm3168a_1: audio-codec@44 {
+ compatible = "ti,pcm3168a";
+ reg = <0x44>;
+ #sound-dai-cells = <1>;
+ reset-gpios = <&exp3 0 GPIO_ACTIVE_LOW>;
+ clocks = <&audio_refclk1>;
+ clock-names = "scki";
+ VDD1-supply = <&vsys_3v3>;
+ VDD2-supply = <&vsys_3v3>;
+ VCCAD1-supply = <&vsys_5v0>;
+ VCCAD2-supply = <&vsys_5v0>;
+ VCCDA1-supply = <&vsys_5v0>;
+ VCCDA2-supply = <&vsys_5v0>;
+ };
+};
+
+&mcasp4 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcasp4_pins_default>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ auxclk-fs-ratio = <256>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 2 1 1
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/2] Enable audio support for J721S2 EVM
From: Moteen Shah @ 2026-05-20 11:56 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
Earlier version of the patchset sent upstream[0] was rejected as
its dependency[1], which resolves the DTBS check errors introduced
by [0] also got rejected on the grounds of ABI breakage.
Another solution to fix the DTBS check errors introduced by [0] is
to modify the ti,j721e-system-controller.yaml binding to allow
audio-refclk as clock-controller child. This is done in the first
patch of this series.
Changes sinve v4:
Link to v4: https://lore.kernel.org/all/20260519142341.2531948-1-m-shah@ti.com/
- Explicitly diasble main_mcan3 and Main_mcan5 as thy will silently break mcasp audio routing
Link to v3: https://lore.kernel.org/all/20260330094459.128648-1-m-shah@ti.com/
Link to v2: https://lore.kernel.org/all/20260205130707.2033197-1-m-shah@ti.com/
Link to v1: https://lore.kernel.org/all/20260112104536.83309-1-m-shah@ti.com/
Bootlogs: https://gist.github.com/Jamm02/f586087dad227450abe8637e8a688c68
Jayesh Choudhary (1):
arm64: dts: ti: Add audio overlay for k3-j721s2-evm
Moteen Shah (1):
dt-bindings: ti: Update audio-refclk binding and j721e system
controller
.../bindings/clock/ti,am62-audio-refclk.yaml | 8 +-
.../soc/ti/ti,j721e-system-controller.yaml | 6 +-
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 171 ++++++++++++++++++
4 files changed, 185 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
--
2.34.1
^ permalink raw reply
* Re: [PATCH PARTIAL-RESEND v12 0/5] Add support MT6316/6363/MT6373 PMICs regulators and MFD
From: AngeloGioacchino Del Regno @ 2026-05-20 12:00 UTC (permalink / raw)
To: Mark Brown
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <agKBkUBVM81Y6MUk@sirena.co.uk>
On 5/12/26 03:25, Mark Brown wrote:
> On Mon, May 11, 2026 at 12:13:50PM +0200, AngeloGioacchino Del Regno wrote:
>> Changes in v12:
>> - This is a partial resend. MT6373 regulators and MFD patches were not picked.
>> - Rebased over next-20260508
>
> Is there a reason why this is a single patch series, are there any
> interdependencies here?
Just showing the full picture. Nothing else.
Btw, seen your feedback on the other patches, will fix as soon as I can - thanks!
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH PARTIAL-RESEND v12 0/5] Add support MT6316/6363/MT6373 PMICs regulators and MFD
From: AngeloGioacchino Del Regno @ 2026-05-20 12:00 UTC (permalink / raw)
To: Mark Brown
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <agKBkUBVM81Y6MUk@sirena.co.uk>
On 5/12/26 03:25, Mark Brown wrote:
> On Mon, May 11, 2026 at 12:13:50PM +0200, AngeloGioacchino Del Regno wrote:
>> Changes in v12:
>> - This is a partial resend. MT6373 regulators and MFD patches were not picked.
>> - Rebased over next-20260508
>
> Is there a reason why this is a single patch series, are there any
> interdependencies here?
Just showing the full picture. Nothing else.
Btw, seen your feedback on the other patches, will fix as soon as I can - thanks!
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v2] ARM: PCI: merge pci_common_init_dev() into pci_common_init()
From: Andrew Lunn @ 2026-05-20 12:03 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-kernel, Russell King, Bjorn Helgaas,
Ilpo Järvinen, Kuninori Morimoto
In-Reply-To: <20260520041343.23040-1-enelsonmoore@gmail.com>
On Tue, May 19, 2026 at 09:13:38PM -0700, Ethan Nelson-Moore wrote:
> pci_common_init() is a compatibility wrapper that simply calls
> pci_common_init_dev() with an additional NULL argument. The comment
> above it implies that it should be replaced by pci_common_init_dev(),
> but that has never happened - there are no callers of
> pci_common_init_dev() in the kernel. Make the PCI code more
> straightforward by getting rid of the wrapper function and instead
> removing the device argument from pci_common_init_dev() and renaming it
> to pci_common_init().
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v8 next 01/10] fs/resctrl: Fix MPAM Partid parsing errors by preserving CDP state during umount
From: Zeng Heng @ 2026-05-20 12:16 UTC (permalink / raw)
To: James Morse, ben.horgan, Dave.Martin, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, wangkefeng.wang
In-Reply-To: <0efe369b-8a01-45b1-bd0f-4fdd4ebbb18a@arm.com>
Hi James,
On 2026/5/15 1:06, James Morse wrote:
> Hi Zeng,
>
> I think this should be a separate patch as its fixing a problem not adding a feature. It's
> not actually relevant to the rest of the series.
>
The intention behind this fix is that reqPARTID would end up the same as
the original PARTID, because the conversion between RMID and reqPARTID
relies on the `cdp_enabled` variable. Hence, I attempted to also
resolve this existing problem with the patch.
> On 13/04/2026 09:53, Zeng Heng wrote:
>> This patch fixes a pre-existing issue in the resctrl filesystem teardown
>> sequence where premature clearing of cdp_enabled could lead to MPAM Partid
>> parsing errors.
>
> resctrl changes need to go via tip, which has a bunch of rules about commit messages,
> see Documentation/process/maintainer-tip.rst
>
> You end up with a structure describing the current state, e.g:
> | When resctrl is umounted it disables CDP,
>
> what the problem is, e.g:
> | CLOSID remain in the limbo list, and the mbm monitors continue to be read
> | after umount. MPAM changes the meaning of CLOSID when CDP is enabled/disabled,
> | resulting in out of bounds accesses.
>
> Then, what you do about it, here you are:
> | Throwing away the limbo list on umount.
>
> (I don't suggest you take this wording - its just an example)
>
> "this patch" is a phrase to avoid, acronyms like CLOSID need capitalising, etc.
>
Thanks for the details, I'll rework the commit to follow these
guidelines.
>
>> The closid to partid conversion logic inherently depends on the global
>> cdp_enabled state. However, rdt_disable_ctx() clears this flag early in
>> the umount path, while free_rmid() operations will reference after that.
>> This creates a window where partid parsing operates with inconsistent CDP
>> state, potentially makes monitor reads with wrong partid mapping.
>>
>> Additionally, rmid_entry remaining in limbo between mount sessions may
>> trigger potential partid out-of-range errors, leading to MPAM fault
>> interrupts and subsequent MPAM disablement.
>
> Can you give more details on this. I assume its going from CDP-disable to
> enabled, means MPAM doubles the CLOSID from the stale limbo list, making it
> out of range.
>
Get it, I would explain that.
>
>> Reorder rdt_kill_sb() to delay rdt_disable_ctx() until after
>> rmdir_all_sub() and resctrl_fs_teardown() complete. This ensures
>> all rmid-related operations finish with correct CDP state.
>
>
>> Introduce rdt_flush_limbo() to flush and cancel limbo work before the
>> filesystem teardown completes.
>
> So, discard the state in the hope we don't need it again.
> What happens if the filesystem is mounted again quickly afterwards?
> Surely we get noisy bandwidth results for ~minutes afterwards?
>
>
>> An alternative approach would be to cancel limbo work on umount
>
> Sounds like a move in the right direction - having bits of resctrl still
> taking CPU time when its not in use is surprising.
>
> I'd love to eventually remove the limbo worker and have the RMID alloc code
> search the limbo list for a clean RMID when a control/monitor group is created.
> By deferring the work as late as possible, we do less work overall.
>
>
>> and restart it on remount with remaked bitmap.
>> However, this would require substantial changes in the resctrl layer to
>> handle CDP state transitions across mount sessions,
>
> This would be necessary if the limbo timer was stopped on umount too.
> It also covers cases where you kexec and re-mount resctrl.
>
> I think this is a good idea. I agree its more work.
>
>
>> which is beyond the
>> scope of the reqpartid feature work this patchset focuses on.
>
> Was it a mistake to include it in this series then?
>
>
>> The current
>> fix addresses the immediate correctness issue with minimal churn.
>
> I'm not a fan of papering over problems in resctrl. Could we do it properly
> by rebuilding the limbo list at mount time as you suggested above?
>
>
I discussed this with Ben earlier, and the remake bitmap approach was
actually his proposal:
https://lore.kernel.org/all/b95077d7-c036-4a8f-8e42-8f1dc0288075@arm.com/
Best regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH RESEND v3 1/6] drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()
From: Dmitry Baryshkov @ 2026-05-20 12:26 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno
In-Reply-To: <20260513-hpd-irq-events-v3-1-086857017f16@oss.qualcomm.com>
On Wed, May 13, 2026 at 09:23:21PM +0300, Dmitry Baryshkov wrote:
> The DisplayPort standard defines a special kind of events called IRQ.
> These events are used to notify DP Source about the events on the Sink
> side. It is extremely important for DP MST handling, where the MST
> events are reported through this IRQ.
>
> In case of the USB-C DP AltMode there is no actual HPD pulse, but the
> events are ported through the bits in the AltMode VDOs.
>
> Extend the drm_connector_oob_hotplug_event() interface and report IRQ
> events to the DisplayPort Sink drivers.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpu/drm/drm_connector.c | 5 ++++-
> drivers/usb/typec/altmodes/displayport.c | 15 +++++++++++----
> include/drm/drm_connector.h | 19 ++++++++++++++++++-
> 3 files changed, 33 insertions(+), 6 deletions(-)
Greg, Heikki, would you please ack merging this through the drm tree?
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 47dc53c4a738..edee9daccd51 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -3510,6 +3510,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to connector
> * @connector_fwnode: fwnode_handle to report the event on
> * @status: hot plug detect logical state
> + * @extra_status: additional information provided by the sink without changing
> + * the HPD state (or in addition to such a change).
> *
> * On some hardware a hotplug event notification may come from outside the display
> * driver / device. An example of this is some USB Type-C setups where the hardware
> @@ -3520,7 +3522,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> * a drm_connector reference through calling drm_connector_find_by_fwnode().
> */
> void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct drm_connector *connector;
>
> diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
> index 35d9c3086990..7182a8e2e710 100644
> --- a/drivers/usb/typec/altmodes/displayport.c
> +++ b/drivers/usb/typec/altmodes/displayport.c
> @@ -189,7 +189,9 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
> } else {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> hpd ? connector_status_connected :
> - connector_status_disconnected);
> + connector_status_disconnected,
> + (hpd && irq_hpd) ? DRM_CONNECTOR_DP_IRQ_HPD :
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
> dp->hpd = hpd;
> sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
> if (hpd && irq_hpd) {
> @@ -212,7 +214,10 @@ static int dp_altmode_configured(struct dp_altmode *dp)
> */
> if (dp->pending_hpd) {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> - connector_status_connected);
> + connector_status_connected,
> + dp->pending_irq_hpd ?
> + DRM_CONNECTOR_DP_IRQ_HPD :
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
> sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
> dp->pending_hpd = false;
> if (dp->pending_irq_hpd) {
> @@ -397,7 +402,8 @@ static int dp_altmode_vdm(struct typec_altmode *alt,
> dp->data.conf = 0;
> if (dp->hpd) {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> - connector_status_disconnected);
> + connector_status_disconnected,
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
> dp->hpd = false;
> sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
> }
> @@ -827,7 +833,8 @@ void dp_altmode_remove(struct typec_altmode *alt)
>
> if (dp->connector_fwnode) {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> - connector_status_disconnected);
> + connector_status_disconnected,
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
>
> fwnode_handle_put(dp->connector_fwnode);
> }
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index f83f28cae207..e05197e970d3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -91,6 +91,22 @@ enum drm_connector_status {
> connector_status_unknown = 3,
> };
>
> +/**
> + * enum drm_connector_status_extra - additional events sent by the sink /
> + * display together or in replacement of the HPD status changes.
> + */
> +enum drm_connector_status_extra {
> + /**
> + * @DRM_CONNECTOR_NO_EXTRA_STATUS: No additional status reported.
> + */
> + DRM_CONNECTOR_NO_EXTRA_STATUS,
> + /**
> + * @DRM_CONNECTOR_DP_IRQ_HPD: DisplayPort Sink has sent the
> + * IRQ_HPD (either by the HPD short pulse or via the AltMode event).
> + */
> + DRM_CONNECTOR_DP_IRQ_HPD,
> +};
> +
> /**
> * enum drm_connector_registration_state - userspace registration status for
> * a &drm_connector
> @@ -2521,7 +2537,8 @@ drm_connector_is_unregistered(struct drm_connector *connector)
> }
>
> void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> - enum drm_connector_status status);
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status);
> const char *drm_get_connector_type_name(unsigned int connector_type);
> const char *drm_get_connector_status_name(enum drm_connector_status status);
> const char *drm_get_subpixel_order_name(enum subpixel_order order);
>
> --
> 2.47.3
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v8 next 01/10] fs/resctrl: Fix MPAM Partid parsing errors by preserving CDP state during umount
From: Zeng Heng @ 2026-05-20 12:28 UTC (permalink / raw)
To: James Morse, ben.horgan, Dave.Martin, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, wangkefeng.wang
In-Reply-To: <c6b77292-4ac4-189f-66f6-300e03440788@huawei.com>
Hi James,
On 2026/5/15 1:06, James Morse wrote:
> Hi Zeng,
>
> I think this should be a separate patch as its fixing a problem not adding a feature. It's
> not actually relevant to the rest of the series.
>
The intention behind this fix is that reqPARTID would end up the same as
the original PARTID, because the conversion between RMID and reqPARTID
relies on the `cdp_enabled` variable. Hence, I attempted to also
resolve this existing problem with the patch.
> On 13/04/2026 09:53, Zeng Heng wrote:
>> This patch fixes a pre-existing issue in the resctrl filesystem teardown
>> sequence where premature clearing of cdp_enabled could lead to MPAM Partid
>> parsing errors.
>
> resctrl changes need to go via tip, which has a bunch of rules about commit messages,
> see Documentation/process/maintainer-tip.rst
>
> You end up with a structure describing the current state, e.g:
> | When resctrl is umounted it disables CDP,
>
> what the problem is, e.g:
> | CLOSID remain in the limbo list, and the mbm monitors continue to be read
> | after umount. MPAM changes the meaning of CLOSID when CDP is enabled/disabled,
> | resulting in out of bounds accesses.
>
> Then, what you do about it, here you are:
> | Throwing away the limbo list on umount.
>
> (I don't suggest you take this wording - its just an example)
>
> "this patch" is a phrase to avoid, acronyms like CLOSID need capitalising, etc.
>
Thanks for the details, I'll rework the commit to follow these
guidelines.
>
>> The closid to partid conversion logic inherently depends on the global
>> cdp_enabled state. However, rdt_disable_ctx() clears this flag early in
>> the umount path, while free_rmid() operations will reference after that.
>> This creates a window where partid parsing operates with inconsistent CDP
>> state, potentially makes monitor reads with wrong partid mapping.
>>
>> Additionally, rmid_entry remaining in limbo between mount sessions may
>> trigger potential partid out-of-range errors, leading to MPAM fault
>> interrupts and subsequent MPAM disablement.
>
> Can you give more details on this. I assume its going from CDP-disable to
> enabled, means MPAM doubles the CLOSID from the stale limbo list, making it
> out of range.
>
Get it, I would explain that.
>
>> Reorder rdt_kill_sb() to delay rdt_disable_ctx() until after
>> rmdir_all_sub() and resctrl_fs_teardown() complete. This ensures
>> all rmid-related operations finish with correct CDP state.
>
>
>> Introduce rdt_flush_limbo() to flush and cancel limbo work before the
>> filesystem teardown completes.
>
> So, discard the state in the hope we don't need it again.
> What happens if the filesystem is mounted again quickly afterwards?
> Surely we get noisy bandwidth results for ~minutes afterwards?
>
>
>> An alternative approach would be to cancel limbo work on umount
>
> Sounds like a move in the right direction - having bits of resctrl still
> taking CPU time when its not in use is surprising.
>
> I'd love to eventually remove the limbo worker and have the RMID alloc code
> search the limbo list for a clean RMID when a control/monitor group is created.
> By deferring the work as late as possible, we do less work overall.
>
>
>> and restart it on remount with remaked bitmap.
>> However, this would require substantial changes in the resctrl layer to
>> handle CDP state transitions across mount sessions,
>
> This would be necessary if the limbo timer was stopped on umount too.
> It also covers cases where you kexec and re-mount resctrl.
>
> I think this is a good idea. I agree its more work.
>
>
>> which is beyond the
>> scope of the reqpartid feature work this patchset focuses on.
>
> Was it a mistake to include it in this series then?
>
>
>> The current
>> fix addresses the immediate correctness issue with minimal churn.
>
> I'm not a fan of papering over problems in resctrl. Could we do it properly
> by rebuilding the limbo list at mount time as you suggested above?
>
>
I discussed this with Ben earlier, and the remake bitmap approach was
actually his proposal:
https://lore.kernel.org/all/b95077d7-c036-4a8f-8e42-8f1dc0288075@arm.com/
Best regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH v2 0/7] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-05-20 12:29 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260519131738.11a78ba88e1be28ba5cb26eb@linux-foundation.org>
Hi Andrew,
I've reviewed all the Sashiko findings:
- Patch 2 (fls() truncation risk): Will fix. Replace fls() with
__fls() to accept unsigned long directly.
- Patch 4 (nr overflow risk): Pre-existing type choice.
- Patch 4 (missing NULL check before page_to_phys): Will fix.
Add defensive checks consistent with vmap_pages_pte_range().
- Patch 5 (flush_cache_vmap with empty range): Valid point. Will
save the original start address and use it for the final flush.
- Patch 5 (virtual address alignment not checked): Addressed by
Patch 6 in this series.
- Patch 6 (caller tracking loss and while(1) loop): Valid point.
Will pass caller as a parameter and restructure per Uladzislau's
suggestion to replace while(1) with explicit sequential attempts.
- Patch 7 (partial cache flush on early break): Same root cause as
the Patch 5 flush issue.
Will resend V3 shortly.
Thanks,
Wen
On Wed, 20 May 2026 at 04:17, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 14 May 2026 17:41:01 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous.
> >
> > ...
> >
> > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > the performance CPUfreq policy enabled, benchmark results:
> >
> > * ioremap(1 MB): 1.35× faster (3407 ns -> 2526 ns)
> > * vmalloc(1 MB) mapping time (excluding allocation) with
> > VM_ALLOW_HUGE_VMAP: 1.42× faster (5.00 us -> 3.53us)
> > * vmap(100MB) with order-8 pages: 8.3× faster (1235 us -> 149 us)
>
> Nice.
>
> AI review found a bunch of things to ask about:
> https://sashiko.dev/#/patchset/20260514094108.2016201-1-jiangwen6@xiaomi.com
>
> It doesn't appear that you'll be getting any more review on this
> series, so please check the above questions and resend?
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox