* Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions
From: Josua Mayer @ 2026-05-24 15:03 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev
In-Reply-To: <20260524-lx2160-pci-v7-1-09370c23b952@solid-run.com>
Am 24.05.26 um 16:54 schrieb Josua Mayer:
> LX2160 SoC pci-e controller supports 64-bit memory regions up to 16GB,
> 32-bit regions up to 3GB and 16-bit regions up to 64k.
>
> For each pci-e controller:
> - extend the existing 32-bit regions to 3GB size
> - add 64-bit region
> See [1] and [2] for boot messages showing ranges before and after.
>
> On LX2160A Silicon revision 1, the pcie driver fails to program atu for
> ranges larger than 4GB [3]. Therefore changes are limited to revision 2.
>
> Similar memory allocation with similar flags was tested with UEFI and ACPI
> on pcie3 and pcie5, on a variety of nxp vendor fork versions.
>
> This patch was tested on Linux v7.1-rc1 and u-boot, with two pcie cards:
> - pcie5: Radeon Pro WX2100
> - pcie3: ADATA NVME
>
> This fixes allocation of large, and 64-bit BARs as requested by many pci
> cards - especially graphics processors or AI accelerators, e.g.:
>
> [ 2.941187] pci 0000:01:00.0: BAR 0: no space for [mem size 0x200000000 64bit pref]
> [ 2.948834] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x200000000 64bit pref]
>
> [1] example of new allocations (pcie5):
> [ 1.182745] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
> [ 1.182760] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
> [ 1.182771] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
> [ 1.182778] layerscape-pcie 3800000.pcie: IO 0xa000010000..0xa00001ffff -> 0x0000000000
> [ 1.183642] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
> [ 1.385429] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
> [ 1.385481] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00
> [ 1.385484] pci_bus 0001:00: root bus resource [bus 00-ff]
> [ 1.385488] pci_bus 0001:00: root bus resource [mem 0xa400000000-0xa7ffffffff pref]
> [ 1.385491] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa0ffffffff] (bus address [0x40000000-0xffffffff])
> [ 1.385494] pci_bus 0001:00: root bus resource [io 0x10000-0x1ffff] (bus address [0x0000-0xffff])
> [ 1.385516] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port
> [ 1.385538] pci 0001:00:00.0: PCI bridge to [bus 01-ff]
> [ 1.385544] pci 0001:00:00.0: bridge window [io 0x11000-0x11fff]
> [ 1.385548] pci 0001:00:00.0: bridge window [mem 0xa040000000-0xa0502fffff]
> [ 1.385605] pci 0001:00:00.0: supports D1 D2
> [ 1.385607] pci 0001:00:00.0: PME# supported from D0 D1 D2 D3hot
> [ 1.386778] pci 0001:01:00.0: [1002:6995] type 00 class 0x030000 PCIe Legacy Endpoint
> [ 1.387336] pci 0001:01:00.0: BAR 0 [mem 0xa040000000-0xa04fffffff 64bit pref]
> [ 1.387368] pci 0001:01:00.0: BAR 2 [mem 0xa050000000-0xa0501fffff 64bit pref]
> [ 1.387385] pci 0001:01:00.0: BAR 4 [io 0x11000-0x110ff]
> [ 1.387402] pci 0001:01:00.0: BAR 5 [mem 0xa050200000-0xa05023ffff]
> [ 1.387418] pci 0001:01:00.0: ROM [mem 0xa050240000-0xa05025ffff pref]
> [ 1.387493] pci 0001:01:00.0: enabling Extended Tags
> [ 1.388960] pci 0001:01:00.0: supports D1 D2
>
> [2] example of previous allocations (pcie5):
> [ 1.716744] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
> [ 1.724060] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa07fffffff -> 0x0040000000
> [ 1.733277] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
> [ 1.836220] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
> [ 1.842186] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00
> [ 1.848883] pci_bus 0001:00: root bus resource [bus 00-ff]
> [ 1.854363] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa07fffffff] (bus address [0x40000000-0x7fffffff])
> [ 1.864892] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port
> [ 1.872216] pci 0001:00:00.0: PCI bridge to [bus 01-ff]
> [ 1.877438] pci 0001:00:00.0: bridge window [io 0x1000-0x1fff]
> [ 1.883526] pci 0001:00:00.0: bridge window [mem 0xa040000000-0xa0502fffff]
>
> [3] error programming atu beyond 4GB:
> [ 1.716762] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
> [ 1.724080] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
> [ 1.732615] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
> [ 1.741142] layerscape-pcie 3800000.pcie: IO 0xa010000000..0xa01000ffff -> 0x0000000000
> [ 1.750379] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
> [ 1.759089] layerscape-pcie 3800000.pcie: Failed to set MEM range [mem 0xa400000000-0xa7ffffffff flags 0x2200]
> [ 1.769089] layerscape-pcie 3800000.pcie: probe with driver layerscape-pcie failed with error -22
>
> [4] pci bootloaderp atching related errors with IORESOURCE_MEM_64 flag:
> [ 0.967809] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
> [ 0.967830] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
> [ 0.967842] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
> [ 0.967849] layerscape-pcie 3800000.pcie: IO 0xa000010000..0xa00001ffff -> 0x0000000000
> [ 1.169315] pci 0000:01:00.0: [8086:1572] type 00 class 0x020000 PCIe Endpoint
> [ 1.169733] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x00ffffff 64bit pref]
> [ 1.169771] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00007fff 64bit pref]
> [ 1.169796] pci 0000:01:00.0: ROM [mem 0x00000000-0x0007ffff pref]
> [ 1.173389] OF: /soc/pcie@3800000: no msi-map translation for id 0x100 on (null)
> [ 1.173515] OF: /soc/pcie@3800000: no iommu-map translation for id 0x100 on (null)
I meant to drop this bootloader error log, because after fixing the ranges flags
this is no longer an issue with this v7 patch.
^ permalink raw reply
* [PATCH v3 0/2] perf/arm-cmn: Add workarounds for CMN-S3 on Graviton5
From: Aviv Bakal @ 2026-05-24 15:38 UTC (permalink / raw)
To: robin.murphy, will, mark.rutland
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, avivb, zeev,
blakgeof
In-Reply-To: <20260504133923.23373-1-avivb@amazon.com>
This series adds support for Graviton5's customised CMN-S3 which has
zeroed discovery registers.
Robin, I understand moving driver state into the core perf header isn't
ideal, but I couldn't find another way to grow the struct. The v2
submission failed the kernel test robot build on i386 (COMPILE_TEST) due
to arm_cmn_hw_event exceeding the static_assert against the 'target'
field offset when CMN_MAX_DIMENSION is increased beyond 12.
Patch 1 moves struct arm_cmn_hw_event into the hw_perf_event union to
resolve this. I'd appreciate your feedback on this approach, or any
alternative you'd suggest.
Patch 2 adds the Graviton5 workarounds themselves (unchanged from v2
except for the DTC logid fix below).
Changes since v2:
- Revert DTC logical ID assignment back to xp->logid (per Robin's
review)
- Add patch 1/2 to move arm_cmn_hw_event into hw_perf_event union
to resolve 32-bit build failure
Aviv Bakal (2):
perf/arm-cmn: Move struct arm_cmn_hw_event into struct hw_perf_event
perf/arm-cmn: Add workarounds for CMN-S3 on Graviton5
drivers/perf/arm-cmn.c | 55 +++++++++++++++++++++-----------------
include/linux/perf_event.h | 22 +++++++++++++++
2 files changed, 52 insertions(+), 25 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH v3 2/2] perf/arm-cmn: Add workarounds for CMN-S3 on Graviton5
From: Aviv Bakal @ 2026-05-24 15:38 UTC (permalink / raw)
To: robin.murphy, will, mark.rutland
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, avivb, zeev,
blakgeof
In-Reply-To: <20260524153848.16334-1-avivb@amazon.com>
Graviton5 uses a customised CMN-S3 implementation where certain
discovery registers report zeroed fields. Add the following workarounds:
- Introduce a dedicated ACPI HID to identify the Graviton5 CMN variant.
- Derive the DTC domain from the XP node ID, since the unit info
register reports it as zero.
- Set the DTC logical ID from the XP's logical ID, since the node info
register's logical ID field is also zeroed.
Signed-off-by: Aviv Bakal <avivb@amazon.com>
---
drivers/perf/arm-cmn.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index 3443b819afed..0184e598777a 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -208,6 +208,8 @@ enum cmn_part {
PART_CMN700 = 0x43c,
PART_CI700 = 0x43a,
PART_CMN_S3 = 0x43e,
+ /* Synthetic part number, overridden to PART_CMN_S3 during discovery */
+ PART_GRAVITON5 = 0xa5,
};
/* CMN-600 r0px shouldn't exist in silicon, thankfully */
@@ -2197,6 +2199,18 @@ static unsigned int arm_cmn_dtc_domain(struct arm_cmn *cmn, void __iomem *xp_reg
return FIELD_GET(CMN_DTM_UNIT_INFO_DTC_DOMAIN, readl_relaxed(xp_region + offset));
}
+static unsigned int arm_cmn_graviton5_dtc_domain(u16 xp_id)
+{
+ unsigned int x = (xp_id >> 7) & 0xf;
+ unsigned int y = (xp_id >> 3) & 0xf;
+
+ /*
+ * The unit info register reads as zero; derive the DTC domain from
+ * the XP's mesh coordinates over the 10x14 mesh.
+ */
+ return (x / 5) + (y / 7) * 2;
+}
+
static void arm_cmn_init_node_info(struct arm_cmn *cmn, u32 offset, struct arm_cmn_node *node)
{
int level;
@@ -2242,6 +2256,7 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
u64 reg;
int i, j;
size_t sz;
+ bool graviton5_workaround = false;
arm_cmn_init_node_info(cmn, rgn_offset, &cfg);
if (cfg.type != CMN_TYPE_CFG)
@@ -2252,6 +2267,13 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
reg = readq_relaxed(cfg_region + CMN_CFGM_PERIPH_ID_01);
part = FIELD_GET(CMN_CFGM_PID0_PART_0, reg);
part |= FIELD_GET(CMN_CFGM_PID1_PART_1, reg) << 8;
+
+ /* Graviton5 has a customised CMN-S3 which needs some fixups */
+ if (cmn->part == PART_GRAVITON5) {
+ cmn->part = PART_CMN_S3;
+ graviton5_workaround = true;
+ }
+
/* 600AE is close enough that it's not really worth more complexity */
if (part == PART_CMN600AE)
part = PART_CMN600;
@@ -2341,6 +2363,8 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
if (cmn->part == PART_CMN600)
xp->dtc = -1;
+ else if (graviton5_workaround)
+ xp->dtc = arm_cmn_graviton5_dtc_domain(xp->id);
else
xp->dtc = arm_cmn_dtc_domain(cmn, xp_region);
@@ -2419,6 +2443,10 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
switch (dn->type) {
case CMN_TYPE_DTC:
+ if (graviton5_workaround) {
+ /* Node info logical ID is zeroed; use the XP's */
+ dn->logid = xp->logid;
+ }
cmn->num_dtcs++;
dn++;
break;
@@ -2634,6 +2662,7 @@ static const struct acpi_device_id arm_cmn_acpi_match[] = {
{ "ARMHC650" },
{ "ARMHC700" },
{ "ARMHC003" },
+ { "AMZN0070", PART_GRAVITON5 },
{}
};
MODULE_DEVICE_TABLE(acpi, arm_cmn_acpi_match);
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/2] perf/arm-cmn: Move struct arm_cmn_hw_event into struct hw_perf_event
From: Aviv Bakal @ 2026-05-24 15:38 UTC (permalink / raw)
To: robin.murphy, will, mark.rutland
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, avivb, zeev,
blakgeof
In-Reply-To: <20260524153848.16334-1-avivb@amazon.com>
In order to increase CMN_MAX_DIMENSION beyond 12 (required for meshes
larger than 12x12, such as Graviton5), the arm_cmn_hw_event struct must
grow. Since it is overlaid on the beginning of hw_perf_event via an
unsafe cast, increasing its size would violate the static_assert that
guards against overflowing into the 'target' field.
Resolve this by moving struct arm_cmn_hw_event into the hw_perf_event
union as a proper named member, eliminating the cast in to_cmn_hw() and
making the size reservation explicit. Set CMN_MAX_DIMENSION to 14 to
accommodate larger mesh topologies.
Signed-off-by: Aviv Bakal <avivb@amazon.com>
---
drivers/perf/arm-cmn.c | 26 +-------------------------
include/linux/perf_event.h | 22 ++++++++++++++++++++++
2 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index f5305c8fdca4..3443b819afed 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -31,13 +31,8 @@
#define CMN_CHILD_NODE_ADDR GENMASK(29, 0)
#define CMN_CHILD_NODE_EXTERNAL BIT(31)
-#define CMN_MAX_DIMENSION 12
-#define CMN_MAX_XPS (CMN_MAX_DIMENSION * CMN_MAX_DIMENSION)
#define CMN_MAX_DTMS (CMN_MAX_XPS + (CMN_MAX_DIMENSION - 1) * 4)
-/* Currently XPs are the node type we can have most of; others top out at 128 */
-#define CMN_MAX_NODES_PER_EVENT CMN_MAX_XPS
-
/* The CFG node has various info besides the discovery tree */
#define CMN_CFGM_PERIPH_ID_01 0x0008
#define CMN_CFGM_PID0_PART_0 GENMASK_ULL(7, 0)
@@ -148,7 +143,6 @@
#define CMN_DT_PMSRR_SS_REQ BIT(0)
#define CMN_DT_NUM_COUNTERS 8
-#define CMN_MAX_DTCS 4
/*
* Even in the worst case a DTC counter can't wrap in fewer than 2^42 cycles,
@@ -595,24 +589,6 @@ static void arm_cmn_debugfs_init(struct arm_cmn *cmn, int id)
static void arm_cmn_debugfs_init(struct arm_cmn *cmn, int id) {}
#endif
-struct arm_cmn_hw_event {
- struct arm_cmn_node *dn;
- u64 dtm_idx[DIV_ROUND_UP(CMN_MAX_NODES_PER_EVENT * 2, 64)];
- s8 dtc_idx[CMN_MAX_DTCS];
- u8 num_dns;
- u8 dtm_offset;
-
- /*
- * WP config registers are divided to UP and DOWN events. We need to
- * keep to track only one of them.
- */
- DECLARE_BITMAP(wp_idx, CMN_MAX_XPS);
-
- bool wide_sel;
- enum cmn_filter_select filter_sel;
-};
-static_assert(sizeof(struct arm_cmn_hw_event) <= offsetof(struct hw_perf_event, target));
-
#define for_each_hw_dn(hw, dn, i) \
for (i = 0, dn = hw->dn; i < hw->num_dns; i++, dn++)
@@ -622,7 +598,7 @@ static_assert(sizeof(struct arm_cmn_hw_event) <= offsetof(struct hw_perf_event,
static struct arm_cmn_hw_event *to_cmn_hw(struct perf_event *event)
{
- return (struct arm_cmn_hw_event *)&event->hw;
+ return &event->hw.cmn;
}
static void arm_cmn_set_index(u64 x[], unsigned int pos, unsigned int val)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 48d851fbd8ea..c38576a8e338 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -119,6 +119,7 @@ struct perf_branch_stack {
};
struct task_struct;
+struct arm_cmn_node;
/*
* extra PMU register associated with an event
@@ -200,6 +201,27 @@ struct hw_perf_event {
u64 conf;
u64 conf1;
};
+#ifdef CONFIG_ARM_CMN
+/* Some implementations use a mesh larger than the architectural max of 12 */
+#define CMN_MAX_DIMENSION 14
+#define CMN_MAX_XPS (CMN_MAX_DIMENSION * CMN_MAX_DIMENSION)
+#define CMN_MAX_NODES_PER_EVENT CMN_MAX_XPS
+#define CMN_MAX_DTCS 4
+ struct arm_cmn_hw_event { /* arm_cmn */
+ /*
+ * CMN PMU event state overlaid on hw_perf_event.
+ * Must fit before the 'target' field.
+ */
+ struct arm_cmn_node *dn;
+ u64 dtm_idx[DIV_ROUND_UP(CMN_MAX_NODES_PER_EVENT * 2, 64)];
+ s8 dtc_idx[CMN_MAX_DTCS];
+ u8 num_dns;
+ u8 dtm_offset;
+ DECLARE_BITMAP(wp_idx, CMN_MAX_XPS);
+ bool wide_sel;
+ int filter_sel;
+ } cmn;
+#endif
};
/*
* If the event is a per task event, this will point to the task in
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2] arm: lpae: fix non-atomic page table entry update issue
From: Wang YanQing @ 2026-05-24 15:30 UTC (permalink / raw)
To: torvalds; +Cc: Russell King (Oracle), akpm, willy, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260503155432.GA18098@udknight>
On Sun, May 03, 2026 at 11:54:32PM +0800, Wang YanQing wrote:
> On Sun, Mar 15, 2026 at 01:12:28AM +0000, Russell King (Oracle) wrote:
> > On Sun, Mar 15, 2026 at 08:47:46AM +0800, Wang YanQing wrote:
> > > The ARM Architecture Reference Manual explicitly dictates that writes of 64-bit
> > > translation table descriptors must be single-copy atomic:
> > > ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition (https://developer.arm.com/documentation/ddi0406/latest)
> > > "
> > > ...
> > > A3.5.3 Atomicity in the ARM architecture
> > > ...
> > > In an implementation that includes the Large Physical Address Extension, LDRD, and STRD accesses to 64-bit aligned
> > > locations are 64-bit single-copy atomic as seen by translation table walks and accesses to translation tables.
> > > Note
> > > The Large Physical Address Extension adds this requirement to avoid the need for complex measures to avoid
> > > atomicity issues when changing translation table entries, without creating a requirement that all locations in the
> > > memory system are 64-bit single-copy atomic.
> >
> > Thanks. Now, please locate where the need for the updates to the page
> > tables needs to be done atomically, bearing in mind that we program
> > SCTLR.AFE=1 and SCTLR.HA=0, meaning the hardware won't write-back to
> > the page tables to e.g. update the access flag.
>
> Dear Russell and all
>
> ARM Cortex-A cores (cortex-a7, cortex-a32, cortex-a55) all have "walk cache ram",
> according to cortex_a32_trm_100241_0100_00_en.pdf (https://documentation-service.arm.com/static/5e7dca43cbfe76649ba52835)
> "
> ...
> The walk cache RAM holds the result of a stage 1 translation up to but not including the last
> level
> ...
> "
>
> The walk cache ram will cache translation result of L1/L2 page table walk, so the non-atomic
> pmd entry update issue describe in the patch will cause partial updated 64-bit entry to be cached
> in the walk cache ram.
>
> On SoCs like TI keystone and Sigmastar SoCs which will run arm32 linux kernel on high address,
> the physical address of page table will be 64-bit and will meet the issue described in the patch.
>
> I think it is right to make page table entry update become atomic according to ARM Architecture
> Reference Manual.
>
> Thanks
Hi Linus and all
Non-atomic LPAE page table update issue on arm32 SOC that run linux kernel on hight address has
caused strange mmu related problem, we meet strange unhandled prefetch abort issue due to the
no-atomic update when we run arm32 linux on Sigmastar CA55 SoC that uses 0x10_0000_0000 as the
start address of DRAM (We do the same thing as keystone SOC, use 0x2000_0000 as start address
of dram, then switch to high address)
I haven't get any respone from Russell King in last three months, the full history could be see
at: https://lkml.org/lkml/2026/3/15/38, I don't know why.
I think make the page table update become atomic is a proper solution for the problem according
to ARM Architecture Reference Manual.
Because the mainline tipcode still has the problem, so I want to try again to make this patch
become merged, if someone don't like it, please tell me what is the better solution for mainline
kernel.
Thanks.
^ permalink raw reply
* [PATCH] dt-bindings: gpio: meson-axg: Fix whitespace issue
From: Jun Yan @ 2026-05-24 15:49 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
Cc: Jun Yan, linux-gpio, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
Clean up whitespace misalignment in meson-axg-gpio.h
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
include/dt-bindings/gpio/meson-axg-gpio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/dt-bindings/gpio/meson-axg-gpio.h b/include/dt-bindings/gpio/meson-axg-gpio.h
index 25bb1fffa97a..a0d42bcd9bd3 100644
--- a/include/dt-bindings/gpio/meson-axg-gpio.h
+++ b/include/dt-bindings/gpio/meson-axg-gpio.h
@@ -23,7 +23,7 @@
#define GPIOAO_11 11
#define GPIOAO_12 12
#define GPIOAO_13 13
-#define GPIO_TEST_N 14
+#define GPIO_TEST_N 14
/* Second GPIO chip */
#define GPIOZ_0 0
@@ -52,7 +52,7 @@
#define BOOT_12 23
#define BOOT_13 24
#define BOOT_14 25
-#define GPIOA_0 26
+#define GPIOA_0 26
#define GPIOA_1 27
#define GPIOA_2 28
#define GPIOA_3 29
--
2.54.0
^ permalink raw reply related
* [PATCH] drm/meson: clean up KMS polling on register failure
From: Myeonghun Pak @ 2026-05-24 16:01 UTC (permalink / raw)
To: Neil Armstrong
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
dri-devel, linux-amlogic, linux-arm-kernel, linux-kernel,
Myeonghun Pak, stable, Ijae Kim
meson_drv_bind_master() starts the KMS polling helper before registering
the DRM device. If drm_dev_register() fails, probe unwinds the IRQ and
DRM device without stopping the polling helper.
Call drm_kms_helper_poll_fini() on that failure path before freeing the
IRQ.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
drivers/gpu/drm/meson/meson_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
index 49ff9f1f16..e49de5df73 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -352,12 +352,14 @@ static int meson_drv_bind_master(struct device *dev, bool has_components)
ret = drm_dev_register(drm, 0);
if (ret)
- goto uninstall_irq;
+ goto uninstall_poll;
drm_client_setup(drm, NULL);
return 0;
+uninstall_poll:
+ drm_kms_helper_poll_fini(drm);
uninstall_irq:
free_irq(priv->vsync_irq, drm);
exit_afbcd:
--
2.47.1
^ permalink raw reply related
* [PATCH 0/2] YUV support for VOP2 background color
From: Cristian Ciocaltea @ 2026-05-24 16:27 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: kernel, dri-devel, linux-arm-kernel, linux-rockchip, linux-kernel
Since commit bec7cbfa7d4f ("drm/rockchip: vop2: Support setting custom
background color") the VOP2 display controller allows configuring the
background color of each video output port.
However, this is currently limited to RGB formats. When operating in
YUV overlay mode, the color must be programmed using YUV format.
Add the necessary RGB-to-YCbCr conversion logic, covering all color
spaces supported by the display controller: BT601L, BT601F, BT709L and
BT2020L.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Cristian Ciocaltea (2):
drm/rockchip: vop2: Rename CSC_BT2020 to CSC_BT2020L
drm/rockchip: vop2: Add YUV support to background color
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 154 ++++++++++++++++++++++++---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 2 +-
2 files changed, 139 insertions(+), 17 deletions(-)
---
base-commit: 213c92ac9717e4951f052a499f91c89302889813
change-id: 20260524-vop2-bg-yuv-1b0e6a09c579
^ permalink raw reply
* [PATCH 1/2] drm/rockchip: vop2: Rename CSC_BT2020 to CSC_BT2020L
From: Cristian Ciocaltea @ 2026-05-24 16:27 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: kernel, dri-devel, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260524-vop2-bg-yuv-v1-0-dcb6a52923f5@collabora.com>
Rename CSC_BT2020 to CSC_BT2020L for consistency with the other
limited-range enum members (CSC_BT601L, CSC_BT709L) and to distinguish
it from a potential future full-range BT.2020 variant.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index a160077a507f..64ac07cb1b0d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -658,7 +658,7 @@ static int vop2_convert_csc_mode(int csc_mode)
case V4L2_COLORSPACE_JPEG:
return CSC_BT601F;
case V4L2_COLORSPACE_BT2020:
- return CSC_BT2020;
+ return CSC_BT2020L;
default:
return CSC_BT709L;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
index 37722652844a..ffcb39c130aa 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
@@ -373,7 +373,7 @@ enum vop_csc_format {
CSC_BT601L,
CSC_BT709L,
CSC_BT601F,
- CSC_BT2020,
+ CSC_BT2020L,
};
enum src_factor_mode {
--
2.54.0
^ permalink raw reply related
* [PATCH 2/2] drm/rockchip: vop2: Add YUV support to background color
From: Cristian Ciocaltea @ 2026-05-24 16:27 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: kernel, dri-devel, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260524-vop2-bg-yuv-v1-0-dcb6a52923f5@collabora.com>
The VOP2 background color must be programmed with 10-bit precision,
using YUV format when the overlay operates in YUV mode, and RGB
otherwise.
Add the required RGB-to-YCbCr conversion logic, covering all color
spaces supported by the display controller: BT601L, BT601F, BT709L and
BT2020L.
Since the color is currently programmed to hardware on every atomic
commit, minimize the computation cost by splitting the work across the
two paths: in atomic_enable(), perform the conversion unconditionally
(the hardware state is unknown after power-on), while in atomic_flush(),
perform it only when the DRM property has actually changed.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 152 ++++++++++++++++++++++++---
1 file changed, 137 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 64ac07cb1b0d..e3f7ed2ff285 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -644,6 +644,88 @@ static void vop2_setup_scale(struct vop2 *vop2, const struct vop2_win *win,
}
}
+/*
+ * RGB-to-YCbCr conversion based on color_to_ycbcr() and rgb2ycbcr() from
+ * drivers/media/common/v4l2-tpg/v4l2-tpg-core.c.
+ *
+ * Limited-range Y offset & chroma midpoint are expressed in 16-bit space.
+ */
+#define RGB2YUV_LIMITED_Y_OFFSET (16 << 8)
+#define RGB2YUV_CHROMA_OFFSET (128 << 8)
+#define COEFF(v, r) ((s32)(0.5 + (v) * (r) * 256.0))
+
+struct rgb2yuv_matrix {
+ s32 y_r, y_g, y_b;
+ s32 cb_r, cb_g, cb_b;
+ s32 cr_r, cr_g, cr_b;
+ s32 y_offset;
+};
+
+/* BT.601 Limited range */
+static const struct rgb2yuv_matrix rgb2yuv_bt601l = {
+ .y_r = COEFF(0.299, 219), .y_g = COEFF(0.587, 219), .y_b = COEFF(0.114, 219),
+ .cb_r = COEFF(-0.1687, 224), .cb_g = COEFF(-0.3313, 224), .cb_b = COEFF(0.5, 224),
+ .cr_r = COEFF(0.5, 224), .cr_g = COEFF(-0.4187, 224), .cr_b = COEFF(-0.0813, 224),
+ .y_offset = RGB2YUV_LIMITED_Y_OFFSET,
+};
+
+/* BT.601 Full range */
+static const struct rgb2yuv_matrix rgb2yuv_bt601f = {
+ .y_r = COEFF(0.299, 255), .y_g = COEFF(0.587, 255), .y_b = COEFF(0.114, 255),
+ .cb_r = COEFF(-0.1687, 255), .cb_g = COEFF(-0.3313, 255), .cb_b = COEFF(0.5, 255),
+ .cr_r = COEFF(0.5, 255), .cr_g = COEFF(-0.4187, 255), .cr_b = COEFF(-0.0813, 255),
+ .y_offset = 0,
+};
+
+/* BT.709 Limited range */
+static const struct rgb2yuv_matrix rgb2yuv_bt709l = {
+ .y_r = COEFF(0.2126, 219), .y_g = COEFF(0.7152, 219), .y_b = COEFF(0.0722, 219),
+ .cb_r = COEFF(-0.1146, 224), .cb_g = COEFF(-0.3854, 224), .cb_b = COEFF(0.5, 224),
+ .cr_r = COEFF(0.5, 224), .cr_g = COEFF(-0.4542, 224), .cr_b = COEFF(-0.0458, 224),
+ .y_offset = RGB2YUV_LIMITED_Y_OFFSET,
+};
+
+/* BT.2020 Limited range */
+static const struct rgb2yuv_matrix rgb2yuv_bt2020l = {
+ .y_r = COEFF(0.2627, 219), .y_g = COEFF(0.6780, 219), .y_b = COEFF(0.0593, 219),
+ .cb_r = COEFF(-0.1396, 224), .cb_g = COEFF(-0.3604, 224), .cb_b = COEFF(0.5, 224),
+ .cr_r = COEFF(0.5, 224), .cr_g = COEFF(-0.4598, 224), .cr_b = COEFF(-0.0402, 224),
+ .y_offset = RGB2YUV_LIMITED_Y_OFFSET,
+};
+
+static const struct rgb2yuv_matrix *
+vop2_rgb2yuv_get_matrix(enum vop_csc_format csc)
+{
+ switch (csc) {
+ case CSC_BT601L:
+ return &rgb2yuv_bt601l;
+ case CSC_BT601F:
+ return &rgb2yuv_bt601f;
+ case CSC_BT2020L:
+ return &rgb2yuv_bt2020l;
+ case CSC_BT709L:
+ default:
+ return &rgb2yuv_bt709l;
+ }
+}
+
+/* Convert an RGB (16bpc) to YUV444 (16bpc). */
+static void vop2_rgb16_to_yuv16(enum vop_csc_format csc, u16 r, u16 g, u16 b,
+ u16 *y, u16 *cb, u16 *cr)
+{
+ const struct rgb2yuv_matrix *m = vop2_rgb2yuv_get_matrix(csc);
+ s64 rs = r, gs = g, bs = b;
+ s64 ys, cbs, crs;
+
+ ys = m->y_r * rs + m->y_g * gs + m->y_b * bs;
+ cbs = m->cb_r * rs + m->cb_g * gs + m->cb_b * bs;
+ crs = m->cr_r * rs + m->cr_g * gs + m->cr_b * bs;
+
+ *y = (ys >> 16) + m->y_offset;
+ *cb = (cbs >> 16) + RGB2YUV_CHROMA_OFFSET;
+ *cr = (crs >> 16) + RGB2YUV_CHROMA_OFFSET;
+}
+
static int vop2_convert_csc_mode(int csc_mode)
{
switch (csc_mode) {
@@ -1554,12 +1636,58 @@ static void vop2_dither_setup(struct drm_crtc *crtc, u32 *dsp_ctrl)
DITHER_DOWN_ALLEGRO);
}
-static void vop2_post_config(struct drm_crtc *crtc)
+static void vop2_bgcolor_setup(struct drm_crtc *crtc, bool force,
+ struct drm_crtc_state *new_crtc_state,
+ struct drm_crtc_state *old_crtc_state)
+{
+ struct rockchip_crtc_state *new_vcstate = to_rockchip_crtc_state(new_crtc_state);
+ struct rockchip_crtc_state *old_vcstate = to_rockchip_crtc_state(old_crtc_state);
+ struct vop2_video_port *vp = to_vop2_video_port(crtc);
+ u64 bgcolor = new_crtc_state->background_color;
+ u16 y, cb, cr;
+ u32 val;
+
+ if (!force && old_crtc_state->background_color == bgcolor &&
+ old_vcstate->color_space == new_vcstate->color_space)
+ return;
+
+ /*
+ * Background color is programmed with 10 bits of precision, using YUV
+ * format when operating in YUV overlay mode, and RGB otherwise.
+ */
+ if (new_vcstate->yuv_overlay) {
+ vop2_rgb16_to_yuv16(new_vcstate->color_space,
+ DRM_ARGB64_GETR(bgcolor),
+ DRM_ARGB64_GETG(bgcolor),
+ DRM_ARGB64_GETB(bgcolor),
+ &y, &cb, &cr);
+
+ val = FIELD_PREP(RK3568_VP_DSP_BG__DSP_BG_RED, cr >> 6);
+ FIELD_MODIFY(RK3568_VP_DSP_BG__DSP_BG_GREEN, &val, y >> 6);
+ FIELD_MODIFY(RK3568_VP_DSP_BG__DSP_BG_BLUE, &val, cb >> 6);
+ } else {
+ /*
+ * Since performance is more important than accuracy here, make
+ * use of the DRM_ARGB64_GET*_BPCS() helpers.
+ */
+ val = FIELD_PREP(RK3568_VP_DSP_BG__DSP_BG_RED,
+ DRM_ARGB64_GETR_BPCS(bgcolor, 10));
+ FIELD_MODIFY(RK3568_VP_DSP_BG__DSP_BG_GREEN, &val,
+ DRM_ARGB64_GETG_BPCS(bgcolor, 10));
+ FIELD_MODIFY(RK3568_VP_DSP_BG__DSP_BG_BLUE, &val,
+ DRM_ARGB64_GETB_BPCS(bgcolor, 10));
+ }
+
+ vop2_vp_write(vp, RK3568_VP_DSP_BG, val);
+}
+
+static void vop2_post_config(struct drm_crtc *crtc, bool force,
+ struct drm_crtc_state *new_crtc_state,
+ struct drm_crtc_state *old_crtc_state)
{
struct vop2_video_port *vp = to_vop2_video_port(crtc);
struct vop2 *vop2 = vp->vop2;
- struct drm_display_mode *mode = &crtc->state->adjusted_mode;
- u64 bgcolor = crtc->state->background_color;
+ struct drm_display_mode *mode = &new_crtc_state->adjusted_mode;
u16 vtotal = mode->crtc_vtotal;
u16 hdisplay = mode->crtc_hdisplay;
u16 hact_st = mode->crtc_htotal - mode->crtc_hsync_start;
@@ -1605,15 +1733,7 @@ static void vop2_post_config(struct drm_crtc *crtc)
vop2_vp_write(vp, RK3568_VP_POST_DSP_VACT_INFO_F1, val);
}
- /*
- * Background color is programmed with 10 bits of precision.
- * Since performance is more important than accuracy here,
- * make use of the DRM_ARGB64_GET*_BPCS() helpers.
- */
- val = FIELD_PREP(RK3568_VP_DSP_BG__DSP_BG_RED, DRM_ARGB64_GETR_BPCS(bgcolor, 10));
- FIELD_MODIFY(RK3568_VP_DSP_BG__DSP_BG_GREEN, &val, DRM_ARGB64_GETG_BPCS(bgcolor, 10));
- FIELD_MODIFY(RK3568_VP_DSP_BG__DSP_BG_BLUE, &val, DRM_ARGB64_GETB_BPCS(bgcolor, 10));
- vop2_vp_write(vp, RK3568_VP_DSP_BG, val);
+ vop2_bgcolor_setup(crtc, force, new_crtc_state, old_crtc_state);
}
static int us_to_vertical_line(struct drm_display_mode *mode, int us)
@@ -1628,8 +1748,9 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
struct vop2 *vop2 = vp->vop2;
const struct vop2_data *vop2_data = vop2->data;
const struct vop2_video_port_data *vp_data = &vop2_data->vp[vp->id];
+ struct drm_crtc_state *old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc);
struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
- struct rockchip_crtc_state *vcstate = to_rockchip_crtc_state(crtc->state);
+ struct rockchip_crtc_state *vcstate = to_rockchip_crtc_state(crtc_state);
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
unsigned long clock = mode->crtc_clock * 1000;
u16 hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start;
@@ -1799,7 +1920,7 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
clk_set_rate(vp->dclk, clock);
- vop2_post_config(crtc);
+ vop2_post_config(crtc, true, crtc_state, old_crtc_state);
vop2_cfg_done(vp);
@@ -1874,6 +1995,7 @@ static void vop2_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_atomic_commit *state)
{
struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ struct drm_crtc_state *old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc);
struct vop2_video_port *vp = to_vop2_video_port(crtc);
struct vop2 *vop2 = vp->vop2;
@@ -1881,7 +2003,7 @@ static void vop2_crtc_atomic_flush(struct drm_crtc *crtc,
if (!drm_atomic_crtc_needs_modeset(crtc_state) && crtc_state->color_mgmt_changed)
vop2_crtc_atomic_try_set_gamma_locked(vop2, vp, crtc, crtc_state);
- vop2_post_config(crtc);
+ vop2_post_config(crtc, false, crtc_state, old_crtc_state);
vop2_cfg_done(vp);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Dmitry Baryshkov @ 2026-05-24 16:42 UTC (permalink / raw)
To: demiobenour
Cc: Herbert Xu, David S. Miller, Thara Gopinath, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Russell King, linux-kernel, linux-crypto, linux-arm-msm,
Eric Biggers, Ard Biesheuvel, devicetree, linux-arm-kernel
In-Reply-To: <20260523-delete-qce-v1-1-86105cd7f406@gmail.com>
On Sat, May 23, 2026 at 03:03:56PM -0400, Demi Marie Obenour via B4 Relay wrote:
> From: Demi Marie Obenour <demiobenour@gmail.com>
>
> It's slower than the generic C code and causes problems.
Which problems?
Also in the security world faster and safer are two orthogonal axis with
very limited correlation.
>
> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
> ---
> MAINTAINERS | 8 -
> arch/arm/configs/multi_v7_defconfig | 1 -
> arch/arm64/configs/defconfig | 1 -
> drivers/crypto/Kconfig | 111 -----
> drivers/crypto/Makefile | 1 -
> drivers/crypto/qce/Makefile | 9 -
> drivers/crypto/qce/aead.c | 841 ------------------------------------
> drivers/crypto/qce/aead.h | 56 ---
> drivers/crypto/qce/cipher.h | 56 ---
> drivers/crypto/qce/common.c | 595 -------------------------
> drivers/crypto/qce/common.h | 104 -----
> drivers/crypto/qce/core.c | 271 ------------
> drivers/crypto/qce/core.h | 64 ---
> drivers/crypto/qce/dma.c | 135 ------
> drivers/crypto/qce/dma.h | 47 --
> drivers/crypto/qce/regs-v5.h | 326 --------------
> drivers/crypto/qce/sha.c | 545 -----------------------
> drivers/crypto/qce/sha.h | 72 ---
> drivers/crypto/qce/skcipher.c | 529 -----------------------
> 19 files changed, 3772 deletions(-)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/3] ASoC: sunxi: sun4i-spdif: Reorder clock enable sequence
From: Chen-Yu Tsai @ 2026-05-24 17:19 UTC (permalink / raw)
To: Bui Duc Phuc
Cc: broonie, codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai
In-Reply-To: <CAGb2v66accoNhStHGhnoUM0cw3fyCxfuvS1a-brL9C-ZO07ChQ@mail.gmail.com>
On Sun, May 24, 2026 at 9:41 AM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> On Sat, May 23, 2026 at 3:11 PM Bui Duc Phuc <phucduc.bui@gmail.com> wrote:
> >
> > Hi Chen-yu,
> >
> > Thanks for your feedback
> >
> > On Sat, May 23, 2026 at 2:20 AM Chen-Yu Tsai <wens@kernel.org> wrote:
> > > > Enable the APB bus clock before the SPDIF module clock
> > > > during runtime resume, as register accesses depend on the
> > > > bus clock being enabled first.
> > >
> > > That does not even matter here. Access will only happen once the runtime
> > > PM callbacks return.
> > >
> >
> > I understand your point that sun4i-spdif doesn't immediately access
> > registers within the current runtime_resume path, so the order might
> > not trigger a failure right now.
> >
> > However, if we look at the peer driver for the same Sunxi SoC family,
> > sun4i-i2s.c:
> > Links:
> > https://elixir.bootlin.com/linux/v7.0-rc5/source/sound/soc/sunxi/sun4i-i2s.c#L1296
> > In sun4i_i2s_runtime_resume(), the sequence is strictly enforced as:
> >
> > 1. Enable bus clock
> > 2. Access and restore/sync I2S registers
> > 3. Enable module clock
> >
> > Since both IP blocks belong to the same Sunxi platform and share similar
> > bus/module clock relationships, shouldn't we maintain architectural
> > consistency across these drivers?
> >
> > Enforcing the "bus clock before module clock" order keeps the dependency
> > ordering aligned with the actual hardware roles, where the bus clock is
> > required for register access while the module clock drives the functional
> > audio path.
> >
> > Wouldn't keeping this order also make the runtime PM behavior more
> > consistent and easier to follow across the Sunxi audio drivers?
>
> This should be your primary motivation for the patch, i.e. what you
> put in the commit message as the reason for this patch. What you
> currently have doesn't make sense, as I already mentioned.
>
> Some background though, sunxi is done mostly by volunteers, so we're
> not overly concerned with rigidness or aligning different drivers,
> unless they share a common library, such as all the clk or pinctrl
> drivers.
Oh, and you could also add that the resume order should (normally) be
the reverse of the suspend order.
ChenYu
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: sun50i-a64: Enable DT overlays
From: Chen-Yu Tsai @ 2026-05-24 17:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi,
Peter Robinson
In-Reply-To: <20260518220455.156874-1-pbrobinson@gmail.com>
On Mon, 18 May 2026 23:04:49 +0100, Peter Robinson wrote:
> Enable DT overlays on some of the Pine64 devices to enable
> use of addon accessories such as WiFi or audio modules.
>
>
Applied to sunxi/dt-for-7.2 in local tree, thanks!
[1/1] arm64: dts: allwinner: sun50i-a64: Enable DT overlays
commit: 3a6ffc1b4fcecd021361393d7294badb0d89e5b0
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 00/17] arm64: Use EL2 virtual timer when running VHE
From: Krzysztof Kozlowski @ 2026-05-24 18:17 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, linux-acpi, linux-kernel,
devicetree
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-1-maz@kernel.org>
On 23/05/2026 16:02, Marc Zyngier wrote:
> This is the third version of the series initially posted at [1],
> which
>
> - updates the ACPI GTDT parsing to deal the v3 layout and the EL2
> virtual timer,
> - moves the architected timer driver to use it when running VHE,
> - fixes a number of DTs to reflect the reality of the HW.
>
Please mention here what do you expect SoC maintainer to do with this -
apply individual patches, wait for dependencies, ack etc.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Krzysztof Kozlowski @ 2026-05-24 18:20 UTC (permalink / raw)
To: Frank Li
Cc: Chancel Liu (OSS), Chancel Liu, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, s.hauer@pengutronix.de,
festevam@gmail.com, mturquette@baylibre.com, sboyd@kernel.org,
kernel@pengutronix.de, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org
In-Reply-To: <ag3GMdmxw60B15Oe@lizhi-Precision-Tower-5810>
On 20/05/2026 16:33, Frank Li wrote:
> On Wed, May 20, 2026 at 09:08:42AM +0200, Krzysztof Kozlowski wrote:
>> On 20/05/2026 07:02, Chancel Liu (OSS) wrote:
>>>>>>>>> +description:
>>>>>>>>> + The NXP I/O connector represents a physically present I/O
>>>>>>>>> +connector on the
>>>>>>>>> + base board. It acts as a nexus that exposes a constrained set
>>>> of
>>>>>>>>> +I/O
>>>>>>>>> + resources, such as GPIOs, clocks, PWMs and interrupts, through
>>>>>>>>> +fixed
>>>>>>>>> + electrical wiring. All actual hardware providers reside on the
>>>> base
>>>>>> board.
>>>>>>>>> + The connector node only defines index-based mappings to those
>>>>>>>> providers.
>>>>>>>>> +
>>>>>>>>> +properties:
>>>>>>>>> + compatible:
>>>>>>>>> + const: fsl,io-connector
>>>>>>>>
>>>>>>>> Everything is IO. Everything is connector, so your compatible does
>>>>>>>> not match requirements from writing bindings.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, this compatible is too generic. I will rename the compatible to
>>>>>>> fsl,aud-io-connector.
>>>>>>
>>>>>> aud is not much better. Which boards have it? What's the pinout?
>>>> What's
>>>>>> standard? Is it described anywhere? If so, provide reference to
>>>> spec/docs.
>>>>>>
>>>>>
>>>>> This is not an industry standard electrical interface. This connector
>>>>
>>>> Then if you do not have standard, then you have board specific layouts
>>>> thus you need board-specific compatibles. You can use fallbacks. Generic
>>>> fallback could work, but both io-connector and aud-io-connector are just
>>>> too generic. Every connector is "connector" and "io", thus absolutely
>>>> anything can be "io-connector". "aud" improves it only a bit, thus
>>>> honestly I would go with board specific fallback as well.
>>>>
>>>
>>> How about board specific + common fallback compatible like this:
>>> compatible:
>>> items:
>>> - enum:
>>> - fsl,imx95-19x19-evk-aud-io-connector
>>> - fsl,imx952-evk-aud-io-connector
>>> - const: fsl,imx-aud-io-connector
>>> Since the daughter board is named “IMX-AUD-IO” in publicly available
>>
>> I don't think it is named like that.
>>
>> git grep -i imx-aud-io
>>
>>> documentation, common compatible clearly indicates that this connector
>>> is intended for that.
>>>
>>> Also, I want to talk about the topic of generic connector. It's a common
>>> design that daughter board is connected to base board through a
>>> connector. This connector more often acts as a nexus that exposes a
>>> constrained subset of GPIO, clock, PWM and interrupt resources to the
>>> daughter board. Can we document this kind of connector as a generic
>>> binding?
>>
>> So this binding is the connector between carrier and some addon? Then
>> you don't get a compatible for that at all, because it is not necessary,
>> not useful and NEVER used. Do you see socket LGA "connector" bindings? No.
>
> Not exactly. Any connector connects a carrier board with an add-on board.
> The key point here is that this connector type is reused across different
> boards, even though it is not an industry-standard connector. Both the
> signal definitions and the mechanical layout are defined.
>
> The same add-on boards can therefore be reused across different base boards
> that use this type of connector.
>
> There are also GPIO mappings involved. For example, pin 1 on the connector
> may represent reset-gpios, but it could be connected to GPIO0 on board A
> and GPIO1 on board B.
>
> Without a connector definition layer, this would create an N × M
> combination problem. The Nexus node discussion already covered this topic:
> https://osseu2025.sched.com/event/25Vrw
>
> An LGA socket is a CPU socket, where the signals are completely transparent
> to software, so it is not a good comparison. A PCIe M.2 Key-M/E connector
> would be a more appropriate comparison.
>
So the terminology of daughter and carrier boards was confusing. If this
is a hat, mezzanine or other addon, it's fine.
I still insist on board specific compatibles - fallback and specific.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ASoC: dt-bindings: sound: atmel_ac97c: Convert to DT schema
From: Manish Baing @ 2026-05-24 18:33 UTC (permalink / raw)
To: claudiu.beznea, andrei.simion, lgirdwood, broonie, robh, krzk+dt,
conor+dt, nicolas.ferre, alexandre.belloni
Cc: linux-sound, devicetree, linux-arm-kernel, linux-kernel,
manishbaing2789
Convert the Atmel AC97 controller binding from text
format to YAML schema.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
.../sound/atmel,at91sam9263-ac97c.yaml | 60 +++++++++++++++++++
.../devicetree/bindings/sound/atmel_ac97c.txt | 20 -------
2 files changed, 60 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/atmel_ac97c.txt
diff --git a/Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml b/Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml
new file mode 100644
index 000000000000..870532927164
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/atmel,at91sam9263-ac97c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel AC97 Controller
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: atmel,at91sam9263-ac97c
+
+ reg:
+ maxItems: 1
+ description: Address and length of the register set for the device.
+
+ interrupts:
+ maxItems: 1
+ description: Should contain the AC97 interrupt.
+
+ ac97-gpios:
+ minItems: 3
+ maxItems: 4
+ description: |
+ AC97 link GPIOs- sync, sdata_out, reset, and optional sdata_in.
+ The driver primarily uses the reset pin.
+
+ pinctrl-0: true
+
+ pinctrl-names:
+ const: default
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ac97-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ sound@fffa0000 {
+ compatible = "atmel,at91sam9263-ac97c";
+ reg = <0xfffa0000 0x4000>;
+ interrupts = <18 IRQ_TYPE_LEVEL_HIGH 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ac97>;
+ ac97-gpios = <&pioB 0 0>, <&pioB 2 0>, <&pioC 29 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/atmel_ac97c.txt b/Documentation/devicetree/bindings/sound/atmel_ac97c.txt
deleted file mode 100644
index b151bd902ce3..000000000000
--- a/Documentation/devicetree/bindings/sound/atmel_ac97c.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* Atmel AC97 controller
-
-Required properties:
- - compatible: "atmel,at91sam9263-ac97c"
- - reg: Address and length of the register set for the device
- - interrupts: Should contain AC97 interrupt
- - ac97-gpios: Please refer to soc-ac97link.txt, only ac97-reset is used
-Optional properties:
- - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
-
-Example:
-sound@fffa0000 {
- compatible = "atmel,at91sam9263-ac97c";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_ac97>;
- reg = <0xfffa0000 0x4000>;
- interrupts = <18 IRQ_TYPE_LEVEL_HIGH 5>;
-
- ac97-gpios = <&pioB 0 0 &pioB 2 0 &pioC 29 GPIO_ACTIVE_LOW>;
-};
--
2.43.0
^ permalink raw reply related
* [GIT PULL] clk: samsung: fixes for v7.1
From: Krzysztof Kozlowski @ 2026-05-24 18:47 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Krzysztof Kozlowski, Chanwoo Choi, linux-clk, Sylwester Nawrocki,
Alim Akhtar, Peter Griffin, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Hi Stephen and Michael,
Just one fix for current cycle.
Best regards,
Krzysztof
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-clk-fixes-7.1
for you to fetch changes up to 78ee734b36284d82454e87a92094fdb926985b47:
clk: samsung: gs101: Fix missing USI7_USI DIV clock in peric0_clk_regs (2026-05-14 18:48:05 +0200)
----------------------------------------------------------------
Samsung clock controller fixes for v7.1
Google GS101: Correct the register name for saving and restoring state
during system suspend and resume. Lack of proper save/restore leads to
incorrect clock values after system resume.
----------------------------------------------------------------
Kuan-Wei Chiu (1):
clk: samsung: gs101: Fix missing USI7_USI DIV clock in peric0_clk_regs
drivers/clk/samsung/clk-gs101.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [GIT PULL] samsung: drivers firmware for v7.1
From: Krzysztof Kozlowski @ 2026-05-24 18:56 UTC (permalink / raw)
To: Arnd Bergmann, Alexandre Belloni, Linus Walleij, Drew Fustini,
soc
Cc: Krzysztof Kozlowski, Alim Akhtar, Peter Griffin, linux-arm-kernel,
linux-samsung-soc, linux-kernel
Hi Arnd and SoC folks,
Few driver fixes for current cycle.
Best regards,
Krzysztof
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-fixes-7.1
for you to fetch changes up to 10313b4cca783ef2e38b2a76dc42dda481d7ebf3:
firmware: samsung: acpm: Fix infinite loop on sequence number exhaustion (2026-05-14 18:55:00 +0200)
----------------------------------------------------------------
Samsung SoC driver fixes for v7.1
Fix several concurrency issues present in Samsung ACPM firmware drivers,
used currently only on Google GS101. Tudor with help of Sashiko
identified several missing barriers and incomplete synchronization,
leading to possible transfer data corruption or use after free. Few
other issues related to probe, including missing mailbox cleanup, were
also fixed.
----------------------------------------------------------------
Tudor Ambarus (7):
firmware: samsung: acpm: Fix cross-thread RX length corruption
firmware: samsung: acpm: Fix mailbox channel leak on probe error
firmware: samsung: acpm: Fix dummy stubs to return ERR_PTR
firmware: samsung: acpm: Add memory barrier before advancing RX pointer
firmware: samsung: acpm: Fix false timeouts and Use-After-Free in polling
firmware: samsung: acpm: Fix missing LKMM barriers in sequence allocator
firmware: samsung: acpm: Fix infinite loop on sequence number exhaustion
drivers/firmware/samsung/exynos-acpm-dvfs.c | 3 +
drivers/firmware/samsung/exynos-acpm.c | 145 ++++++++++++++-------
.../linux/firmware/samsung/exynos-acpm-protocol.h | 3 +-
3 files changed, 106 insertions(+), 45 deletions(-)
^ permalink raw reply
* Re: [RESEND,v2 1/2] dt-bindings: memory-controllers: mtk-smi: Add support for mt8189
From: Krzysztof Kozlowski @ 2026-05-24 19:08 UTC (permalink / raw)
To: mtk20898, Yong Wu, Rob Herring, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-mediatek, linux-kernel, devicetree, linux-arm-kernel,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260427070444.20247-2-zhengnan.chen@mediatek.com>
On 27/04/2026 09:04, mtk20898 wrote:
> From: Zhengnan Chen <zhengnan.chen@mediatek.com>
>
> Add binding description for mt8189.
>
> The clocks number of mt8189 smi-sub common has a bit difference.
> Its clock count is 2, while mt8195 has 3. Therefore, the minimum
> number of clocks is changed to 2, with the third one being optional.
Then why does the binding say that mt8195 has two clocks? You already
received exactly this question.
>
> About what smi-sub-common is, please check the below diagram,
> we add it in mediatek,smi-common.yaml file.
>
> Signed-off-by: Zhengnan Chen <zhengnan.chen@mediatek.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
No need to resend this. You received comments at v2 and you should have
implemented them.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/6] firmware: samsung: acpm: TMU support and cleanups
From: Krzysztof Kozlowski @ 2026-05-24 19:40 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Lee Jones, Tudor Ambarus
Cc: Krzysztof Kozlowski, Alim Akhtar, Sylwester Nawrocki,
Chanwoo Choi, André Draszik, linux-kernel, linux-samsung-soc,
linux-arm-kernel, linux-clk, peter.griffin, jyescas, kernel-team,
Krzysztof Kozlowski
In-Reply-To: <20260515-acpm-tmu-helpers-v2-0-8ca011d5a965@linaro.org>
On Fri, 15 May 2026 09:32:24 +0000, Tudor Ambarus wrote:
> This series introduces protocol support for the Exynos
> Thermal Management Unit (TMU) to the ACPM driver, alongside several
> cleanups.
>
> Dependencies
> ============
> Krzysztof, these patches together with the acpm fixes from your `fixes`
> branch will be needed by the thermal maintainers. I'm going to send the
> ACPM TMU (thermal) driver for review. In case they'll take it for the
> next release, we'll need an immutable tag with the acpm fixes, cleanup
> and thermal helpers. Thanks!
>
> [...]
Applied, thanks!
[1/6] firmware: samsung: acpm: Consolidate transfer initialization helper
https://git.kernel.org/krzk/linux/c/43d3733b7ffd82b2bfeda69befa2a179335dfe6c
[2/6] firmware: samsung: acpm: Annotate rx_data->cmd with __counted_by_ptr
https://git.kernel.org/krzk/linux/c/7b20fd06f783c1e901d34305c68df16212cdf669
[3/6] firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
https://git.kernel.org/krzk/linux/c/ef1109e4b6120a52be1ea66d486d6744d0c5ac47
[4/6] firmware: samsung: acpm: Make acpm_ops const and access via pointer
https://git.kernel.org/krzk/linux/c/e694e19bf7db26ee324ff6bb450cc523592f5bee
[5/6] firmware: samsung: acpm: Add TMU protocol support
https://git.kernel.org/krzk/linux/c/f6af402de525d0848fc4a50f25ff01f56fc68d98
[6/6] firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper
https://git.kernel.org/krzk/linux/c/8ad2c29d53e69df5cc1c1d00513c6a0f96d2d452
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* Re: [PATCH] tty: serial: samsung: Remove redundant port lock acquisition in rx helpers
From: Krzysztof Kozlowski @ 2026-05-24 19:42 UTC (permalink / raw)
To: Tudor Ambarus, Alim Akhtar, Greg Kroah-Hartman, Jiri Slaby,
Ben Dooks
Cc: linux-arm-kernel, linux-samsung-soc, linux-kernel, linux-serial,
john.ogness, peter.griffin, andre.draszik, jyescas, kernel-team,
stable, John Ogness
In-Reply-To: <20260515-samsung-tty-flow-control-deadlock-v1-1-93255edbc9bc@linaro.org>
On 15/05/2026 14:41, Tudor Ambarus wrote:
> Sashiko identified a deadlock when the console flow is engaged [1].
>
> When console flow control is enabled (UPF_CONS_FLOW),
> s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and
> s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable().
>
> The serial core framework invokes the .stop_tx() and .start_tx()
> callbacks with the port->lock spinlock already held. Furthermore, all
> internal driver paths that invoke stop_tx (such as the DMA TX
> completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ
> handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to
> calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the
> serial core).
>
> However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable()
> unconditionally attempt to acquire port->lock again using
> uart_port_lock_irqsave(). Since spinlocks are not recursive, this
> causes a deadlock on the same CPU when console flow control is engaged.
>
> Remove the redundant lock acquisition from both rx helper functions.
>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: firmware: google,gs101-acpm-ipc: document Exynos850 compatible
From: Krzysztof Kozlowski @ 2026-05-24 19:45 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar
Cc: Peter Griffin, linux-samsung-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260513-exynos850-acpm-firmware-support-v1-1-3858d097e433@linaro.org>
On 13/05/2026 01:12, Alexey Klimov wrote:
> The Exynos850 SoC incorporates an APM co-processor. Communication with
> this hardware block is done using the ACPM protocol, which handles IPC
> messages for clocks, power, thermal management and PMIC control.
>
> Dedicated compatible string is required for the Exynos850 because
> its firmware utilizes a different initialisation data base offset
> (0x7000) compared to the existing GS101 implementation (0xa000).
This is good reason/explanation, but open the binding please - you will
see several specific children, e.g. S2MPG10. You need to be very
explicit in commit msg that your Exynos850 is always fitted with these
PMIcs. If not, then you need some other compatibles, because binding
should be complete.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: sound: atmel_ac97c: Convert to DT schema
From: Manish Baing @ 2026-05-24 19:53 UTC (permalink / raw)
To: claudiu.beznea, lgirdwood, broonie, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni
Cc: linux-sound, devicetree, linux-arm-kernel, linux-kernel,
manishbaing2789
Convert the Atmel AC97 controller binding from text
format to YAML schema.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
Changes in v2:
- Added undocumented 'clocks' and 'clock-names' properties which are
unconditionally required by the driver.
- Removed 'ac97-gpios' from the required list, as the driver treats
it as optional, fixing validation for existing dtsi files.
.../sound/atmel,at91sam9263-ac97c.yaml | 70 +++++++++++++++++++
.../devicetree/bindings/sound/atmel_ac97c.txt | 20 ------
2 files changed, 70 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/atmel_ac97c.txt
diff --git a/Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml b/Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml
new file mode 100644
index 000000000000..5f4ebe81bf90
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/atmel,at91sam9263-ac97c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel AC97 Controller
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: atmel,at91sam9263-ac97c
+
+ reg:
+ maxItems: 1
+ description: Address and length of the register set for the device.
+
+ interrupts:
+ maxItems: 1
+ description: Should contain the AC97 interrupt.
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ac97_clk
+
+ ac97-gpios:
+ minItems: 3
+ maxItems: 4
+ description: |
+ AC97 link GPIOs- sync, sdata_out, reset, and optional sdata_in.
+ The driver primarily uses the reset pin.
+
+ pinctrl-0: true
+
+ pinctrl-names:
+ const: default
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/clock/at91.h>
+
+ sound@fffa0000 {
+ compatible = "atmel,at91sam9263-ac97c";
+ reg = <0xfffa0000 0x4000>;
+ interrupts = <18 IRQ_TYPE_LEVEL_HIGH 5>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 2>;
+ clock-names = "ac97_clk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ac97>;
+ ac97-gpios = <&pioB 0 0>, <&pioB 2 0>, <&pioC 29 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/atmel_ac97c.txt b/Documentation/devicetree/bindings/sound/atmel_ac97c.txt
deleted file mode 100644
index b151bd902ce3..000000000000
--- a/Documentation/devicetree/bindings/sound/atmel_ac97c.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* Atmel AC97 controller
-
-Required properties:
- - compatible: "atmel,at91sam9263-ac97c"
- - reg: Address and length of the register set for the device
- - interrupts: Should contain AC97 interrupt
- - ac97-gpios: Please refer to soc-ac97link.txt, only ac97-reset is used
-Optional properties:
- - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
-
-Example:
-sound@fffa0000 {
- compatible = "atmel,at91sam9263-ac97c";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_ac97>;
- reg = <0xfffa0000 0x4000>;
- interrupts = <18 IRQ_TYPE_LEVEL_HIGH 5>;
-
- ac97-gpios = <&pioB 0 0 &pioB 2 0 &pioC 29 GPIO_ACTIVE_LOW>;
-};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 00/17] arm64: Use EL2 virtual timer when running VHE
From: Marc Zyngier @ 2026-05-24 19:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber,
"Yu-Chun Lin [林祐君]", Heiko Stuebner,
Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <f519372e-139c-4530-98bb-dbec56af373a@kernel.org>
On Sun, 24 May 2026 19:17:05 +0100,
Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 23/05/2026 16:02, Marc Zyngier wrote:
> > This is the third version of the series initially posted at [1],
> > which
> >
> > - updates the ACPI GTDT parsing to deal the v3 layout and the EL2
> > virtual timer,
> > - moves the architected timer driver to use it when running VHE,
> > - fixes a number of DTs to reflect the reality of the HW.
> >
>
> Please mention here what do you expect SoC maintainer to do with this -
> apply individual patches, wait for dependencies, ack etc.
I only care about the first 3 patches (ACPI enablement, arm64 timer
code), and don't have any expectation for the rest, as pointed out in
the cover letter for v1.
These are all bug fixes for DTs that do not correctly describe the HW.
There is therefore no dependency on anything. The patches can either
be cherry picked by the individual SoC maintainers, applied globally
by one of the DT maintainers, or be completely ignored.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: (subset) [PATCH v3 08/17] arm64: dts: exynos: Add EL2 virtual timer interrupt
From: Krzysztof Kozlowski @ 2026-05-24 20:00 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Marc Zyngier
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-9-maz@kernel.org>
On Sat, 23 May 2026 15:02:33 +0100, Marc Zyngier wrote:
> A bunch of Samsung SoCs are missing the EL2 virtual timer interrupt
> despite using ARMv8.1+ CPUs. Add the missing interrupt, except for
> those broken designs where the interrupt is documented as not being
> wired.
Applied, thanks!
[08/17] arm64: dts: exynos: Add EL2 virtual timer interrupt
https://git.kernel.org/krzk/linux/c/d0298724f901d45c76f1f2193225706200f565e4
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
^ 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