* Re: [PATCH RESEND v4 0/8] can: flexcan: Add NXP S32N79 SoC support
From: Ciprian Marian Costea @ 2026-06-09 7:19 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol
Cc: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam, Pengutronix Kernel Team, linux-can, devicetree,
linux-kernel, imx, linux-arm-kernel, NXP S32 Linux Team,
Christophe Lizzi, Alberto Ruiz, Eric Chanudet
In-Reply-To: <CALE0LRuqZhm03QbYg-ZOJcKe0XqCLqVZ8j-4o07QuBF-OqX9BA@mail.gmail.com>
On 6/3/2026 1:28 PM, Enric Balletbo i Serra wrote:
> Hi Ciprian,
>
> Sorry in advance for the noise, for some strange reason I didn't get
> or find the cover until now, so I added my tested patch in 1. Doing it
> now properly.
>
> On Wed, Jun 3, 2026 at 11:44 AM Bough Chen <haibo.chen@oss.nxp.com> wrote:
Hello Marc and Vincent,
Sorry for bothering. Do you expect any more changes to this V4 patchset ?
Best Regards,
Ciprian
>>
>> On Wed, Jun 03, 2026 at 09:13:34AM +0200, Ciprian Costea wrote:
>>> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>>>
>>> This patch series adds FlexCAN support for the NXP S32N79 SoC.
>>>
>>> The S32N79 is an automotive-grade processor from NXP with multiple
>>> FlexCAN instances. The FlexCAN IP integration on S32N79 differs from
>>> other SoCs in the interrupt routing - it uses two separate interrupt
>>> lines:
>>> - one interrupt for mailboxes 0-127
>>> - one interrupt for bus error detection and device state changes
>>>
>>> The CAN controllers are connected through an irqsteer interrupt
>>> controller in the RCU (Resource Control Unit) domain.
>>>
>>> This series:
>>> 1. Splits flexcan_irq() into dedicated handlers for multi-IRQ platforms
>>> 2. Adds dt-bindings documentation for S32N79 FlexCAN
>>> 3. Introduces FLEXCAN_QUIRK_IRQ_BERR to handle the two-interrupt
>>> configuration
>>> 4. Adds S32N79 device data and compatible string to the driver
>>> 5. Adds FlexCAN device tree nodes for S32N79 SoC
>>> 6. Enables FlexCAN devices on the S32N79-RDB board
>>>
>>> Tested on S32N79-RDB board with CAN and CAN FD communication.
>>
>> Tested on imx95-19x19-evk board with CAN and CAN FD communication. No issue found.
>> This means this patch set do not impact the original platforms.
>>
>> For this patch set, feel free to add tag:
>> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
>>
>> Regards
>> Haibo Chen
>
> Tested-by: Enric Balletbo i Serra <eballetb@.redhat.com>
>
> Tested on the NXP S32G399A-RDB3 with loopback and high-rate traffic.
> No regressions observed:
> CAN frames transmit and receive correctly, with no duplicates.
> Frame reception showed no errors during stress testing.
>
> Regards,
> Enric Balletbo
>
>>>
>>> This is a resend of v4 with no changes.
>>>
>>> v4 -> v3
>>> - flexcan_chip_interrupts_enable(): disable/enable all IRQ lines
>>> (not just dev->irq) during IMASK register writes
>>> - Split rx/tx masks per mailbox IRQ line (struct flexcan_mb_irq) so
>>> each handler on S32G2 only processes its own MB range
>>> - Added received Acked-by tag on DT bindings patch
>>>
>>> v3 -> v2
>>> - Split flexcan_irq() into dedicated handlers (flexcan_irq_mb,
>>> flexcan_irq_boff, flexcan_irq_berr) to fix duplicate event
>>> processing when multiple IRQ lines run concurrently (new patch).
>>> - Added flexcan_irq_esr() handler composing state + berr for S32N79
>>> - Ordered quirks used by s32n devtype data by value.
>>>
>>> v2 -> v1
>>> - Renamed FLEXCAN_QUIRK_NR_IRQ_2 to FLEXCAN_QUIRK_IRQ_BERR to better
>>> describe the actual hardware feature
>>> - Appended new quirk at the end
>>> - Switched from platform_get_irq to platform_get_irq_byname usage
>>> - Updated interrupt description in dt-bindings
>>>
>>> Ciprian Marian Costea (8):
>>> can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
>>> can: flexcan: disable all IRQ lines in
>>> flexcan_chip_interrupts_enable()
>>> can: flexcan: split rx/tx masks per mailbox IRQ line
>>> dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
>>> can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
>>> can: flexcan: add NXP S32N79 SoC support
>>> arm64: dts: s32n79: add FlexCAN nodes
>>> arm64: dts: s32n79: enable FlexCAN devices
>>>
>>> .../bindings/net/can/fsl,flexcan.yaml | 30 ++-
>>> arch/arm64/boot/dts/freescale/s32n79-rdb.dts | 12 +
>>> arch/arm64/boot/dts/freescale/s32n79.dtsi | 50 ++++
>>> drivers/net/can/flexcan/flexcan-core.c | 249 +++++++++++++++---
>>> drivers/net/can/flexcan/flexcan.h | 12 +-
>>> 5 files changed, 316 insertions(+), 37 deletions(-)
>>>
>>> --
>>> 2.43.0
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Krzysztof Kozlowski @ 2026-06-09 7:08 UTC (permalink / raw)
To: Can Guo
Cc: bvanassche, beanhuo, peter.wang, martin.petersen, mani,
linux-scsi, Alim Akhtar, Avri Altman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Zhaoming Luo, Ram Kumar Dwivedi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek
In-Reply-To: <64bd6272-6111-4ffa-8a4a-366d0c287693@oss.qualcomm.com>
On 31/05/2026 06:48, Can Guo wrote:
>>>> is the minimal encoding that covers both.
>>> Again, why do you need to encode '0'?
>> The tuple is still needed because Precoding is configured per
>> transmitter-receiver pair,
>> so each lane has two independent states:
>> - Host_TX -> Device_RX
>> - Device_TX -> Host_RX
>> A lane-only enabled list cannot represent directional combinations
>> like lane0 =
>> (on, off) vs (off, on).
> How about we split into two properties, something like below?
> tx-precode-enable-g6-host-lanes = <0 1>
> tx-precode-enable-g6-device-lanes = <1>
>
> Only listed lanes are enabled; unlisted lanes are disabled by default.
>
> Are you OK with this approach?
Yes, I do prefer this, because we don't have empty entries (<0, 0>, <0,
1> ....).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum
From: Ashish Mhetre @ 2026-06-09 7:07 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, robin.murphy, joro, nicolinc, linux-arm-kernel,
iommu, linux-kernel, linux-tegra
In-Reply-To: <20260605141053.GF2487554@ziepe.ca>
On 6/5/2026 7:40 PM, Jason Gunthorpe wrote:
> External email: Use caution opening links or attachments
>
>
> On Fri, Jun 05, 2026 at 07:35:35PM +0530, Ashish Mhetre wrote:
>>>> +{
>>>> + if (!(smmu->options & ARM_SMMU_OPT_TLBI_TWICE))
>>>> + return false;
>>> Maybe we should make this a static key?
>> Okay. Shall I add just static key and remove option bit, or
>> have static key alongside existing option bit such that
>> static_branch_unlikely will precede the option bit check?
> You'd have the static key and the options. Keep it simple, enable the
> static key once if any driver probes to set TWICE. Check the key
> before options to get the best code gen
Okay, I'll incorporate this in V4 and send.
> But IDK if it is really worth it, there are already lots of branches
> on the performance tlbi flow, and we didn't do this for other tlbi
> affecting errata..
>
> IDK if we really care about branches we should also be doing things
> like disabling the range/non-range paths and ATC based on what is
> actually in use..
>
> Jason
^ permalink raw reply
* Re: [PATCH v3] clocksource: move NXP timer selection to drivers/clocksource
From: Enric Balletbo i Serra @ 2026-06-09 6:57 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Russell King, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Lezcano, Thomas Gleixner, linux-arm-kernel,
imx, linux-kernel
In-Reply-To: <20260514-fix-nxp-timer-v3-1-a3e68fdb505e@redhat.com>
Hi all,
On Thu, May 14, 2026 at 1:14 PM Enric Balletbo i Serra
<eballetbo@kernel.org> wrote:
>
> From: Enric Balletbo i Serra <eballetb@redhat.com>
>
> The Kconfig logic for selecting the scheduler clocksource on
> NXP Vybrid (VF610) uses a `choice` block restricted to 32-bit ARM. This
> prevents 64-bit architectures, such as the NXP S32 family, from enabling
> the NXP Periodic Interrupt Timer (PIT) driver (CONFIG_NXP_PIT_TIMER).
>
> Relocate the NXP clocksource selection from arch/arm/mach-imx/Kconfig to
> drivers/clocksource/Kconfig. This allows the configuration to be shared
> across different architectures.
>
> Update the selection to include support for ARCH_S32 and add a "None"
> option restricted to ARCH_S32, since Vybrid lacks the ARM Architected
> Timer. The Vybrid Global Timer option is restricted to ARCH_MULTI_V7
> SOC_VF610 platforms to prevent it from being visible on Cortex-M4 builds,
> which lack the ARM Global Timer hardware.
>
> Fixes: bee33f22d7c3 ("clocksource/drivers/nxp-pit: Add NXP Automotive s32g2 / s32g3 support")
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com>
Now that Frank [1] has created a merge request for Linux 7.1-rc1 and
the request includes
arm64: dts: s32g: add PIT support for s32g2 and s32g3
If this patch is ok, would it make sense to pick that patch?
Otherwise, we won't be able to select the PIT timer for aarch64 only
builds.
Thanks.,
Enric
[1] From: Frank.Li@nxp.com
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git
tags/imx-dt64-7.2
for you to fetch changes up to c10cfc952215644956284a42fa7b7860dfbcb5f5:
> ---
> Changes in v3:
> - Restrict VF_TIMER_NONE to ARCH_S32 to prevent selecting it on Vybrid
> platforms which lack the ARM Architected Timer
> - Link to v2: https://lore.kernel.org/r/20260513-fix-nxp-timer-v2-1-533b99c57b67@redhat.com
>
> Changes in v2:
> - Fix VF_USE_ARM_GLOBAL_TIMER dependency: use ARCH_MULTI_V7 instead of
> ARM to prevent the option from being visible on Cortex-M4 builds
> (Sashiko AI review)
> - Link to v1: https://lore.kernel.org/r/20260302-fix-nxp-timer-v1-1-af4bc62d4ffa@redhat.com
> ---
> arch/arm/mach-imx/Kconfig | 21 ---------------------
> drivers/clocksource/Kconfig | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 6ea1bd55acf8..a361840d7a04 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -227,27 +227,6 @@ config SOC_VF610
> help
> This enables support for Freescale Vybrid VF610 processor.
>
> -choice
> - prompt "Clocksource for scheduler clock"
> - depends on SOC_VF610
> - default VF_USE_ARM_GLOBAL_TIMER
> -
> - config VF_USE_ARM_GLOBAL_TIMER
> - bool "Use ARM Global Timer"
> - depends on ARCH_MULTI_V7
> - select ARM_GLOBAL_TIMER
> - select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
> - help
> - Use the ARM Global Timer as clocksource
> -
> - config VF_USE_PIT_TIMER
> - bool "Use PIT timer"
> - select NXP_PIT_TIMER
> - help
> - Use SoC Periodic Interrupt Timer (PIT) as clocksource
> -
> -endchoice
> -
> endif
>
> endif
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index d1a33a231a44..d9c76dd443f8 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -793,4 +793,35 @@ config RTK_SYSTIMER
> this option only when building for a Realtek platform or for compilation
> testing.
>
> +choice
> + prompt "NXP clocksource for scheduler clock"
> + depends on SOC_VF610 || ARCH_S32
> + # Default to Global Timer for Vybrid (32-bit)
> + default VF_USE_ARM_GLOBAL_TIMER if SOC_VF610
> + # Default to None for S32 (64-bit)
> + default VF_TIMER_NONE if ARCH_S32
> +
> + config VF_USE_ARM_GLOBAL_TIMER
> + bool "Use NXP Vybrid Global Timer"
> + depends on ARCH_MULTI_V7 && SOC_VF610
> + select ARM_GLOBAL_TIMER
> + select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
> + help
> + Use the NXP Vybrid Global Timer as clocksource.
> +
> + config VF_USE_PIT_TIMER
> + bool "Use NXP PIT timer"
> + select NXP_PIT_TIMER
> + help
> + Use NXP Periodic Interrupt Timer (PIT) as clocksource.
> +
> + config VF_TIMER_NONE
> + bool "None (Use standard Arch Timer)"
> + depends on ARCH_S32
> + help
> + Do not use any specific NXP timer driver. Use the standard
> + ARM Architected Timer instead.
> +
> +endchoice
> +
> endmenu
>
> ---
> base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
> change-id: 20260302-fix-nxp-timer-9cb1fbd7afcd
>
> Best regards,
> --
> Enric Balletbo i Serra <eballetb@redhat.com>
>
^ permalink raw reply
* [PATCH v6 15/21] RISC-V: perf: Use config2/vendor table for event to counter mapping
From: Atish Patra @ 2026-06-09 6:01 UTC (permalink / raw)
To: James Clark, Rob Herring, Atish Patra, Arnaldo Carvalho de Melo,
Jiri Olsa, Will Deacon, Mark Rutland, Anup Patel, Namhyung Kim,
Paul Walmsley, Krzysztof Kozlowski, Ian Rogers
Cc: linux-riscv, linux-kernel, linux-perf-users, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <20260608-counter_delegation-v6-0-285b72ed65a9@meta.com>
From: Atish Patra <atishp@rivosinc.com>
The counter restriction specified in the json file is passed to
the drivers via config2 paarameter in perf attributes. This allows
any platform vendor to define their custom mapping between event and
hpmcounters without any rules defined in the ISA.
For legacy events, the platform vendor may define the mapping in
the driver in the vendor event table.
The fixed cycle and instruction counters are fixed (0 and 2
respectively) by the ISA and maps to the legacy events. The platform
vendor must specify this in the driver if intended to be used while
profiling. Otherwise, they can just specify the alternate hpmcounters
that may monitor and/or sample the cycle/instruction counts.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
drivers/perf/riscv_pmu_sbi.c | 90 ++++++++++++++++++++++++++++++++++--------
include/linux/perf/riscv_pmu.h | 2 +
2 files changed, 76 insertions(+), 16 deletions(-)
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index 5bfcd3821f57..4b4f151a0744 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -76,6 +76,7 @@ static ssize_t __maybe_unused rvpmu_format_show(struct device *dev, struct devic
RVPMU_ATTR_ENTRY(_name, rvpmu_format_show, (char *)_config)
PMU_FORMAT_ATTR(firmware, "config:62-63");
+PMU_FORMAT_ATTR(counterid_mask, "config2:0-31");
static bool sbi_v2_available;
static bool sbi_v3_available;
@@ -120,6 +121,7 @@ static const struct attribute_group *riscv_sbi_pmu_attr_groups[] = {
static struct attribute *riscv_cdeleg_pmu_formats_attr[] = {
RVPMU_FORMAT_ATTR_ENTRY(event, RVPMU_CDELEG_PMU_FORMAT_ATTR),
&format_attr_firmware.attr,
+ &format_attr_counterid_mask.attr,
NULL,
};
@@ -1480,24 +1482,80 @@ static int rvpmu_deleg_find_ctrs(void)
return num_hw_ctr;
}
+/*
+ * The json file must correctly specify counter 0 or counter 2 is available
+ * in the counter lists for cycle/instret events. Otherwise, the drivers have
+ * no way to figure out if a fixed counter must be used and pick a programmable
+ * counter if available.
+ */
static int get_deleg_fixed_hw_idx(struct cpu_hw_events *cpuc, struct perf_event *event)
{
- return -EINVAL;
+ struct hw_perf_event *hwc = &event->hw;
+ bool guest_events = event->attr.config1 & RISCV_PMU_CONFIG1_GUEST_EVENTS;
+
+ if (guest_events) {
+ if (hwc->event_base == SBI_PMU_HW_CPU_CYCLES)
+ return 0;
+ if (hwc->event_base == SBI_PMU_HW_INSTRUCTIONS)
+ return 2;
+ else
+ return -EINVAL;
+ }
+
+ if (!event->attr.config2)
+ return -EINVAL;
+
+ if (event->attr.config2 & RISCV_PMU_CYCLE_FIXED_CTR_MASK)
+ return 0; /* CY counter */
+ else if (event->attr.config2 & RISCV_PMU_INSTRUCTION_FIXED_CTR_MASK)
+ return 2; /* IR counter */
+ else
+ return -EINVAL;
}
static int get_deleg_next_hpm_hw_idx(struct cpu_hw_events *cpuc, struct perf_event *event)
{
- unsigned long hw_ctr_mask = 0;
+ u32 hw_ctr_mask = 0, temp_mask = 0;
+ u32 type = event->attr.type;
+ u64 config = event->attr.config;
+ int ret;
- /*
- * TODO: Treat every hpmcounter can monitor every event for now.
- * The event to counter mapping should come from the json file.
- * The mapping should also tell if sampling is supported or not.
- */
+ /* Select only available hpmcounters */
+ hw_ctr_mask = cmask & (~0x7) & ~(cpuc->used_hw_ctrs[0]);
+
+ switch (type) {
+ case PERF_TYPE_HARDWARE:
+ temp_mask = current_pmu_hw_event_map[config].counter_mask;
+ break;
+ case PERF_TYPE_HW_CACHE:
+ ret = cdeleg_pmu_event_find_cache(config, NULL, &temp_mask);
+ if (ret)
+ return ret;
+ break;
+ case PERF_TYPE_RAW:
+ /*
+ * Mask off the counters that can't monitor this event (specified via json)
+ * The counter mask for this event is set in config2 via the property 'Counter'
+ * in the json file or manual configuration of config2. If the config2 is not set,
+ * it is assumed all the available hpmcounters can monitor this event.
+ * Note: This assumption may fail for virtualization use case where they hypervisor
+ * (e.g. KVM) virtualizes the counter. Any event to counter mapping provided by the
+ * guest is meaningless from a hypervisor perspective. Thus, the hypervisor doesn't
+ * set config2 when creating kernel counter and relies default host mapping.
+ */
+ if (event->attr.config2)
+ temp_mask = event->attr.config2;
+ break;
+ default:
+ break;
+ }
+
+ if (temp_mask)
+ hw_ctr_mask &= temp_mask;
+
+ if (!hw_ctr_mask)
+ return -EINVAL;
- /* Select only hpmcounters */
- hw_ctr_mask = cmask & (~0x7);
- hw_ctr_mask &= ~(cpuc->used_hw_ctrs[0]);
return __ffs(hw_ctr_mask);
}
@@ -1526,10 +1584,6 @@ static int rvpmu_deleg_ctr_get_idx(struct perf_event *event)
u64 priv_filter;
int idx;
- /*
- * TODO: We should not rely on SBI Perf encoding to check if the event
- * is a fixed one or not.
- */
if (!is_sampling_event(event)) {
idx = get_deleg_fixed_hw_idx(cpuc, event);
if (idx == 0 || idx == 2) {
@@ -1547,10 +1601,14 @@ static int rvpmu_deleg_ctr_get_idx(struct perf_event *event)
goto out_err;
found_idx:
priv_filter = get_deleg_priv_filter_bits(event);
+ if (test_and_set_bit(idx, cpuc->used_hw_ctrs))
+ goto out_err;
update_deleg_hpmevent(idx, hwc->config, priv_filter);
+ return idx;
skip_update:
- if (!test_and_set_bit(idx, cpuc->used_hw_ctrs))
- return idx;
+ if (test_and_set_bit(idx, cpuc->used_hw_ctrs))
+ goto out_err;
+ return idx;
out_err:
return -ENOENT;
}
diff --git a/include/linux/perf/riscv_pmu.h b/include/linux/perf/riscv_pmu.h
index f6a710c83a4c..06171e7aadfb 100644
--- a/include/linux/perf/riscv_pmu.h
+++ b/include/linux/perf/riscv_pmu.h
@@ -30,6 +30,8 @@
#define RISCV_PMU_CONFIG1_GUEST_EVENTS 0x1
#define RISCV_PMU_DELEG_RAW_EVENT_MASK GENMASK_ULL(55, 0)
+#define RISCV_PMU_CYCLE_FIXED_CTR_MASK 0x01
+#define RISCV_PMU_INSTRUCTION_FIXED_CTR_MASK 0x04
#define HW_OP_UNSUPPORTED 0xFFFF
#define CACHE_OP_UNSUPPORTED 0xFFFF
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH v2 19/78] drm/bridge: imx8qxp-pxl2dpi: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:54 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-19-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:36:01PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> index 87305d3e0c39..2fc9831f7e61 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> @@ -208,11 +208,11 @@ imx8qxp_pxl2dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs imx8qxp_pxl2dpi_bridge_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .attach = imx8qxp_pxl2dpi_bridge_attach,
> .destroy = imx8qxp_pxl2dpi_bridge_destroy,
> .atomic_check = imx8qxp_pxl2dpi_bridge_atomic_check,
> .mode_set = imx8qxp_pxl2dpi_bridge_mode_set,
> .atomic_disable = imx8qxp_pxl2dpi_bridge_atomic_disable,
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 18/78] drm/bridge: imx8qxp-pixel-link: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:54 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-18-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:36:00PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> index ee6b6dbbe952..92b8b1ac35d0 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> @@ -227,11 +227,11 @@ imx8qxp_pixel_link_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs imx8qxp_pixel_link_bridge_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .attach = imx8qxp_pixel_link_bridge_attach,
> .mode_set = imx8qxp_pixel_link_bridge_mode_set,
> .atomic_enable = imx8qxp_pixel_link_bridge_atomic_enable,
> .atomic_disable = imx8qxp_pixel_link_bridge_atomic_disable,
> .atomic_get_input_bus_fmts =
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 17/78] drm/bridge: imx8qxp-pixel-combiner: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-17-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:35:59PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> index e0ee51a9ca7f..941ce2f91e9e 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> @@ -249,11 +249,11 @@ imx8qxp_pc_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs imx8qxp_pc_bridge_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .mode_valid = imx8qxp_pc_bridge_mode_valid,
> .attach = imx8qxp_pc_bridge_attach,
> .mode_set = imx8qxp_pc_bridge_mode_set,
> .atomic_disable = imx8qxp_pc_bridge_atomic_disable,
> .atomic_get_input_bus_fmts =
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 16/78] drm/bridge: imx8qxp-ldb: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-16-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:35:58PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
> index a7906314ade1..1c71697a2083 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
> @@ -402,11 +402,11 @@ imx8qxp_ldb_bridge_mode_valid(struct drm_bridge *bridge,
>
> static const struct drm_bridge_funcs imx8qxp_ldb_bridge_funcs = {
> .destroy = imx8qxp_ldb_bridge_destroy,
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .mode_valid = imx8qxp_ldb_bridge_mode_valid,
> .attach = ldb_bridge_attach_helper,
> .atomic_check = imx8qxp_ldb_bridge_atomic_check,
> .mode_set = imx8qxp_ldb_bridge_mode_set,
> .atomic_pre_enable = imx8qxp_ldb_bridge_atomic_pre_enable,
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 15/78] drm/bridge: imx8qm-ldb: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:51 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-15-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:35:57PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qm-ldb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
> index a6ca4f5c6cc6..a654c27356a7 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
> @@ -387,11 +387,11 @@ imx8qm_ldb_bridge_mode_valid(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs imx8qm_ldb_bridge_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .mode_valid = imx8qm_ldb_bridge_mode_valid,
> .attach = ldb_bridge_attach_helper,
> .atomic_check = imx8qm_ldb_bridge_atomic_check,
> .mode_set = imx8qm_ldb_bridge_mode_set,
> .atomic_enable = imx8qm_ldb_bridge_atomic_enable,
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 14/78] drm/bridge: imx8mp-hdmi-pvi: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:47 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-14-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:35:56PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Liu Ying <victor.liu@nxp.com>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Krzysztof Kozlowski @ 2026-06-09 6:44 UTC (permalink / raw)
To: Joakim Zhang, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, p.zabel@pengutronix.de, Gary Yang
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <SEYPR06MB622609AFF7C23086A0D53E12821D2@SEYPR06MB6226.apcprd06.prod.outlook.com>
On 09/06/2026 08:25, Joakim Zhang wrote:
>>>
>>> + clock-controller:
>>> + $ref: /schemas/clock/cix,sky1-audss-clock.yaml#
>>> + description:
>>> + AUDSS internal clock provider (cix,sky1-audss-system-control only).
>>
>> Are you sure this patch builds? Your cover letter should explain merging
>> dependencies/strategy/constraints in the first chapter. You start with THE MOST
>> important information.
> yes, I build yaml with below cmd:
> make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
> make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/clock/cix,sky1-audss-clock.yaml
> make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dt_binding_check CHECK_DTBS=y W=1 cix/sky1-orion-o6.dtb
>
> It's also possible that I compiled the entire patch set after it was completed. This is incorrect because there are dependencies involved. I will check it again carefully.
I want to know about this patch alone. I am pretty sure it does not and
it simply fails because it is non-bisectable.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4] i2c: cadence: Add shutdown handler
From: Michal Simek @ 2026-06-09 6:44 UTC (permalink / raw)
To: Andi Shyti, Ajay Neeli
Cc: git, linux-arm-kernel, linux-i2c, linux-kernel, srinivas.goud,
radhey.shyam.pandey
In-Reply-To: <aiez0H0PPX2NYkyv@zenone.zhora.eu>
On 6/9/26 08:39, Andi Shyti wrote:
> Hi Ajay,
>
> On Thu, Apr 30, 2026 at 11:00:50AM +0530, Ajay Neeli wrote:
>> During system reboot or kexec, in-flight I2C transfers can cause
>> spurious interrupts or leave the bus in an undefined state. Add a
>> shutdown handler that marks the adapter suspended and resets the
>> controller, ensuring a clean handoff.
>>
>> Signed-off-by: Ajay Neeli <ajay.neeli@amd.com>
>
> Michal's ack was missing here.
>
> Merged to i2c/i2c-host.
I have reviewed this patch internally too.
Just checking why I missed it.
Anyway the patch is fine for me.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v4] i2c: cadence: Add shutdown handler
From: Andi Shyti @ 2026-06-09 6:39 UTC (permalink / raw)
To: Ajay Neeli
Cc: git, linux-arm-kernel, linux-i2c, linux-kernel, michal.simek,
srinivas.goud, radhey.shyam.pandey
In-Reply-To: <20260430053050.3590173-1-ajay.neeli@amd.com>
Hi Ajay,
On Thu, Apr 30, 2026 at 11:00:50AM +0530, Ajay Neeli wrote:
> During system reboot or kexec, in-flight I2C transfers can cause
> spurious interrupts or leave the bus in an undefined state. Add a
> shutdown handler that marks the adapter suspended and resets the
> controller, ensuring a clean handoff.
>
> Signed-off-by: Ajay Neeli <ajay.neeli@amd.com>
Michal's ack was missing here.
Merged to i2c/i2c-host.
Thanks,
Andi
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH 3/3] dt-bindings: perf: marvell: Extend CN10K TAD PMU binding for CN20K
From: Geethasowjanya Akula @ 2026-06-09 6:36 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
mark.rutland@arm.com, will@kernel.org, krzk+dt@kernel.org
In-Reply-To: <20260608-spiral-unsterile-66189c3241f8@spud>
>-----Original Message-----
>From: Conor Dooley <conor@kernel.org>
>Sent: Monday, June 8, 2026 11:05 PM
>To: Geethasowjanya Akula <gakula@marvell.com>
>Cc: linux-perf-users@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
>kernel@lists.infradead.org; devicetree@vger.kernel.org;
>mark.rutland@arm.com; will@kernel.org; krzk+dt@kernel.org
>Subject: [EXTERNAL] Re: [PATCH 3/3] dt-bindings: perf: marvell: Extend CN10K
>TAD PMU binding for CN20K
>
>On Sun, Jun 07, 2026 at 06:21:01PM +0530, Geetha sowjanya wrote:
>> Allow marvell,cn20k-tad-pmu alongside marvell,cn10k-tad-pmu, document
>> CN20K in the title and description, add a maintainer, and include a
>> CN20K example node with the same required properties as CN10K.
>
>This is great and all, but is evident from the diff (other than the fact it talks
>about an example that does not exist).
>What is missing is an explanation of why a fallback comaptible is not usable.
CN20K requires a distinct compatible because the PFC/PRF register offsets relative to each TAD base differ from CN10K, and these offsets are not described via DT properties.
In addition, CN20K introduces new events that are not supported on CN10K.
Due to these differences, using marvell,cn10k-tad-pmu as a fallback would result in incorrect configuration.
I will update the commit message in the next revision to clarify this.
Thanks,
Geetha
>pw-bot: changes-requested
>
>Thanks,
>Conor.
>
>>
>> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
>> ---
>> .../bindings/perf/marvell-cn10k-tad.yaml | 20 +++++++++++--------
>> 1 file changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml
>> b/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml
>> index 362142252667..1612052b59ae 100644
>> --- a/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml
>> +++ b/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml
>> @@ -4,23 +4,27 @@
>> $id: http://devicetree.org/schemas/perf/marvell-cn10k-tad.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> -title: Marvell CN10K LLC-TAD performance monitor
>> +title: Marvell CN10K / CN20K LLC-TAD performance monitor
>>
>> maintainers:
>> - Bhaskara Budiredla <bbudiredla@marvell.com>
>> + - Geetha sowjanya <gakula@marvell.com>
>>
>> description: |
>> - The Tag-and-Data units (TADs) maintain coherence and contain CN10K
>> - shared on-chip last level cache (LLC). The tad pmu measures the
>> - performance of last-level cache. Each tad pmu supports up to eight
>> - counters.
>> + The Tag-and-Data units (TADs) maintain coherence and contain the
>> + shared on-chip last level cache (LLC) on Marvell CN10K and CN20K SoCs.
>> + The TAD PMU measures last-level cache performance. Each TAD PMU
>> + supports up to eight counters.
>>
>> - The DT setup comprises of number of tad blocks, the sizes of pmu
>> - regions, tad blocks and overall base address of the HW.
>> + The DT setup describes the number of TAD blocks, the sizes of PMU
>> + regions and TAD pages, and the overall MMIO base of the hardware.
>>
>> properties:
>> compatible:
>> - const: marvell,cn10k-tad-pmu
>> + items:
>> + - enum:
>> + - marvell,cn10k-tad-pmu
>> + - marvell,cn20k-tad-pmu
>>
>> reg:
>> maxItems: 1
>> --
>> 2.25.1
>>
>>
^ permalink raw reply
* Re: [PATCH v3] clk: imx: Add audio PLL debugfs for K-divider control
From: Abel Vesa @ 2026-06-09 6:32 UTC (permalink / raw)
To: Jacky Bai
Cc: Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd,
Brian Masney, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-clk, imx, linux-arm-kernel
In-Reply-To: <20260604-imx8m_pll_debugfs-v3-1-4e331ebc85d7@nxp.com>
On 26-06-04 21:48:01, Jacky Bai wrote:
> Add debugfs support for runtime tuning of the audio PLL K divider,
> which enables fine-grained frequency adjustments for audio PLL.
> This is used for:
> - Audio clock calibration and testing
> - Debugging audio synchronization issues
>
> Two debug interfaces are exported to userspace:
> - delta_k: It is used to adjust the K divider in PLL based on small
> steps
> - pll_parameter: It is used for get PLL's current M-divider,
> P-divider, S-divider & K-divider setting in PLL register
>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 04/15] clk: imx: scu: use clk_determine_rate_noop()
From: Abel Vesa @ 2026-06-09 6:32 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, linux-clk, linux-kernel,
Abel Vesa, Frank Li, Sascha Hauer, Peng Fan,
Pengutronix Kernel Team, Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260505-clk-determine-rate-noop-v3-4-f3f829fbacdf@redhat.com>
On 26-05-05 20:49:00, Brian Masney wrote:
> Drop the driver-specific empty determine_rate() function and use the new
> shared clk_determine_rate_noop() helper.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
Acked-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Ard Biesheuvel @ 2026-06-09 6:31 UTC (permalink / raw)
To: Marek Szyprowski, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh
In-Reply-To: <6a9c0f55-fe98-4063-864b-8f7e1f4fefd7@samsung.com>
On Tue, 9 Jun 2026, at 08:28, Marek Szyprowski wrote:
> On 09.06.2026 08:22, Marek Szyprowski wrote:
>> On 29.05.2026 17:02, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>
>>> The linear aliases of the kernel text and rodata are also mapped
>>> read-only in the linear map. Given that the contents of these regions
>>> are mostly identical to the version in the loadable image, mapping them
>>> read-only and leaving their contents visible is a reasonable hardening
>>> measure.
>>>
>>> Data and bss, however, are now also mapped read-only but the contents of
>>> these regions are more likely to contain data that we'd rather not leak.
>>> So let's unmap these entirely in the linear map when the kernel is
>>> running normally.
>>>
>>> When going into hibernation or waking up from it, these regions need to
>>> be mapped, so map the region initially, and toggle the valid bit so
>>> map/unmap the region as needed.
>>>
>>> Doing so is required because pages covering the kernel image are marked
>>> as PageReserved, and therefore disregarded for snapshotting by the
>>> hibernate logic unless they are mapped.
>>>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> This commit landed in yesterday's linux-next as commit 63e0b6a5b693
>> ("arm64: mm: Unmap kernel data/bss entirely from the linear map").
>> In my tests I found that it breaks booting of RaspberryPi3 and
>> RaspberryPi4 boards with the following kernel panic:
> One more comment - reverting 63e0b6a5b693 and 53205d56212c (dependent
> change) on top of next-20260608 fixes this issue.
>
Thanks for the report, and for the confirmation that those reverts fix
the issue - this was reported here as well:
https://lore.kernel.org/all/aicVyebkEMs6w6UV@sirena.co.uk/
^ permalink raw reply
* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Marek Szyprowski @ 2026-06-09 6:28 UTC (permalink / raw)
To: Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh
In-Reply-To: <a1b27e97-182c-485d-a448-56c19c5de2c2@samsung.com>
On 09.06.2026 08:22, Marek Szyprowski wrote:
> On 29.05.2026 17:02, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <ardb@kernel.org>
>>
>> The linear aliases of the kernel text and rodata are also mapped
>> read-only in the linear map. Given that the contents of these regions
>> are mostly identical to the version in the loadable image, mapping them
>> read-only and leaving their contents visible is a reasonable hardening
>> measure.
>>
>> Data and bss, however, are now also mapped read-only but the contents of
>> these regions are more likely to contain data that we'd rather not leak.
>> So let's unmap these entirely in the linear map when the kernel is
>> running normally.
>>
>> When going into hibernation or waking up from it, these regions need to
>> be mapped, so map the region initially, and toggle the valid bit so
>> map/unmap the region as needed.
>>
>> Doing so is required because pages covering the kernel image are marked
>> as PageReserved, and therefore disregarded for snapshotting by the
>> hibernate logic unless they are mapped.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> This commit landed in yesterday's linux-next as commit 63e0b6a5b693
> ("arm64: mm: Unmap kernel data/bss entirely from the linear map").
> In my tests I found that it breaks booting of RaspberryPi3 and
> RaspberryPi4 boards with the following kernel panic:
One more comment - reverting 63e0b6a5b693 and 53205d56212c (dependent
change) on top of next-20260608 fixes this issue.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* RE: [PATCH v2 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Joakim Zhang @ 2026-06-09 6:27 UTC (permalink / raw)
To: Krzysztof Kozlowski, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, p.zabel@pengutronix.de, Gary Yang
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <6c87641d-d505-44ff-a994-eeabf55f4c73@kernel.org>
Hi Krzysztof,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Friday, June 5, 2026 5:24 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>; mturquette@baylibre.com;
> sboyd@kernel.org; bmasney@redhat.com; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de; Gary Yang
> <gary.yang@cixtech.com>
> Cc: cix-kernel-upstream <cix-kernel-upstream@cixtech.com>; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH v2 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
> clock controller
>
> EXTERNAL EMAIL
>
> On 05/06/2026 05:22, joakim.zhang@cixtech.com wrote:
> > +description: |
> > + Clock provider for the Cix Sky1 audio subsystem (AUDSS).
> > +
> > + This node is a child of a cix,sky1-audss-system-control MFD/syscon
> > + node (see cix,sky1-system-control.yaml). It does not have a reg
> > + property; clock mux, divider and gate fields are accessed through the parent
> register block.
> > +
> > + Software reset lines for AUDSS blocks are exposed on the parent
> > + syscon via #reset-cells. Reset indices are defined in
> > + include/dt-bindings/reset/cix,sky1-audss-system-control.h.
> > +
> > + Six SoC-level reference clocks listed in clocks/clock-names feed
> > + the AUDSS clock tree. The provider exposes the internal AUDSS
> > + clocks to other devices via #clock-cells; indices are defined in cix,sky1-
> audss.h.
> > +
> > +properties:
> > + compatible:
> > + const: cix,sky1-audss-clock
> > +
> > + '#clock-cells':
> > + const: 1
> > + description:
> > + Clock indices are defined in include/dt-bindings/clock/cix,sky1-audss.h.
> > +
> > + clocks:
> > + minItems: 6
>
> Drop
OK
> > + maxItems: 6
> > + description:
> > + Six SoC-level audio reference clocks that feed the audio subsystem,
> > + in the same order as clock-names.
> > +
> > + clock-names:
> > + items:
> > + - const: audio_clk0
> > + - const: audio_clk1
> > + - const: audio_clk2
> > + - const: audio_clk3
> > + - const: audio_clk4
> > + - const: audio_clk5
>
> Pretty pointless names. Names matching indexes have no benefits, drop all of
> them and instead list items in "clocks" with description.
Yes, you are right, I will describe these more meaningful.
> > +
> > + resets:
> > + maxItems: 1
> > + description: Audio subsystem NoC (or bus) reset line.
> > +
> > + power-domains:
> > + maxItems: 1
> > + description: Audio subsystem power domain.
>
> So the clock part has power domain but reset part does not? This is odd.
> Especially that parent is audss (right?) and here you describe that this is audss
> poer domain.
>
> Same question about resets.
The reset and power domain takes effect on the entire subsystem, i.e., audss can be accessed only after powered on and reset released, including the CRU registers which contains clock/reset/control bits for all device within the audss.
Because the reset controller probe does not access the hardware, while the clock controller does, so at that time, the power domain and reset were placed in the clock driver. At present, it does not seem very reasonable either.
Linking the "reset" and "power domain" to the parent node requires us to ensure the order of the probes. We need to perform deferred probes within the child nodes until the parent node has been probed.
Do you have any good suggestions? I can also serve as a reference. Thanks
> > +
> > +required:
> > + - compatible
> > + - '#clock-cells'
> > + - clocks
> > + - clock-names
> > + - resets
> > + - power-domains
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/cix,sky1.h>
> > + #include <dt-bindings/reset/cix,sky1-audss-system-control.h>
> > + #include <dt-bindings/reset/cix,sky1-s5-system-control.h>
> > +
> > + audss_syscon: system-controller@7110000 {
> > + compatible = "cix,sky1-audss-system-control", "simple-mfd", "syscon";
> > + reg = <0x7110000 0x10000>;
> > + #reset-cells = <1>;
>
> Drop parent node.
OK
> > +
> > + audss_clk: clock-controller {
> > + compatible = "cix,sky1-audss-clock";
> > + power-domains = <&smc_devpd 0>;
> > + #clock-cells = <1>;
> > + clocks = <&scmi_clk CLK_TREE_AUDIO_CLK0>, <&scmi_clk
> CLK_TREE_AUDIO_CLK1>,
> > + <&scmi_clk CLK_TREE_AUDIO_CLK2>, <&scmi_clk
> CLK_TREE_AUDIO_CLK3>,
> > + <&scmi_clk CLK_TREE_AUDIO_CLK4>, <&scmi_clk
> CLK_TREE_AUDIO_CLK5>;
> > + clock-names = "audio_clk0", "audio_clk1", "audio_clk2",
> > + "audio_clk3", "audio_clk4", "audio_clk5";
> > + resets = <&src SKY1_AUDIO_HIFI5_NOC_RESET_N>;
> > + };
> > + };
>
>
>
> > +#define CLK_MCLK4 40
> > +
> > +#define AUDSS_MAX_CLKS 41
>
> Drop
OK
Thanks,
Joakim
^ permalink raw reply
* RE: [PATCH v2 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Joakim Zhang @ 2026-06-09 6:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, p.zabel@pengutronix.de, Gary Yang
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <b005d5cc-3b9b-47a6-b6fe-91ace2db4089@kernel.org>
Hi Krzysztof,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Friday, June 5, 2026 5:21 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>; mturquette@baylibre.com;
> sboyd@kernel.org; bmasney@redhat.com; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de; Gary Yang
> <gary.yang@cixtech.com>
> Cc: cix-kernel-upstream <cix-kernel-upstream@cixtech.com>; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH v2 1/5] dt-bindings: soc: cix,sky1-system-control: add audss
> system control
>
> EXTERNAL EMAIL
>
> On 05/06/2026 11:18, Krzysztof Kozlowski wrote:
> > On 05/06/2026 05:22, joakim.zhang@cixtech.com wrote:
> >> compatible:
> >> - items:
> >> - - enum:
> >> - - cix,sky1-system-control
> >> - - cix,sky1-s5-system-control
> >> - - const: syscon
> >> + oneOf:
> >> + - items:
> >> + - enum:
> >> + - cix,sky1-system-control
> >> + - cix,sky1-s5-system-control
> >> + - const: syscon
> >> + - items:
> >> + - const: cix,sky1-audss-system-control
> >> + - const: simple-mfd
> >> + - const: syscon
> >>
> >> reg:
> >> maxItems: 1
> >> @@ -27,6 +32,11 @@ properties:
> >> '#reset-cells':
> >> const: 1
> >>
> >> + clock-controller:
> >> + $ref: /schemas/clock/cix,sky1-audss-clock.yaml#
> >> + description:
> >> + AUDSS internal clock provider (cix,sky1-audss-system-control only).
> >
> > Are you sure this patch builds? Your cover letter should explain
> > merging
>
> I am sure it does not...
>
> I recommend switching to compatible-style of defining subnodes in parent
> schema which would decouple patches.
>
> example:
> https://elixir.bootlin.com/linux/v7.1-
> rc6/source/Documentation/devicetree/bindings/display/msm/qcom,sm8750-
> mdss.yaml#L41
Thank you for your guidance. I will study it further.
Joakim
^ permalink raw reply
* RE: [PATCH v2 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Joakim Zhang @ 2026-06-09 6:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, p.zabel@pengutronix.de, Gary Yang
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <17528d9a-738c-48fe-ac24-b8d90875a74f@kernel.org>
Hi Krzysztof,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Friday, June 5, 2026 5:18 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>; mturquette@baylibre.com;
> sboyd@kernel.org; bmasney@redhat.com; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de; Gary Yang
> <gary.yang@cixtech.com>
> Cc: cix-kernel-upstream <cix-kernel-upstream@cixtech.com>; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH v2 1/5] dt-bindings: soc: cix,sky1-system-control: add audss
> system control
>
> EXTERNAL EMAIL
>
> On 05/06/2026 05:22, joakim.zhang@cixtech.com wrote:
> > compatible:
> > - items:
> > - - enum:
> > - - cix,sky1-system-control
> > - - cix,sky1-s5-system-control
> > - - const: syscon
> > + oneOf:
> > + - items:
> > + - enum:
> > + - cix,sky1-system-control
> > + - cix,sky1-s5-system-control
> > + - const: syscon
> > + - items:
> > + - const: cix,sky1-audss-system-control
> > + - const: simple-mfd
> > + - const: syscon
> >
> > reg:
> > maxItems: 1
> > @@ -27,6 +32,11 @@ properties:
> > '#reset-cells':
> > const: 1
> >
> > + clock-controller:
> > + $ref: /schemas/clock/cix,sky1-audss-clock.yaml#
> > + description:
> > + AUDSS internal clock provider (cix,sky1-audss-system-control only).
>
> Are you sure this patch builds? Your cover letter should explain merging
> dependencies/strategy/constraints in the first chapter. You start with THE MOST
> important information.
yes, I build yaml with below cmd:
make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/clock/cix,sky1-audss-clock.yaml
make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dt_binding_check CHECK_DTBS=y W=1 cix/sky1-orion-o6.dtb
It's also possible that I compiled the entire patch set after it was completed. This is incorrect because there are dependencies involved. I will check it again carefully.
> You need to disallow node for other variants.
OK
>
> > +
> > required:
> > - compatible
> > - reg
> > @@ -40,3 +50,22 @@ examples:
> > reg = <0x4160000 0x100>;
> > #reset-cells = <1>;
> > };
> > + - |
> > + #include <dt-bindings/reset/cix,sky1-audss-system-control.h>
> > +
> > + audss_syscon: system-controller@7110000 {
> > + compatible = "cix,sky1-audss-system-control", "simple-mfd", "syscon";
> > + reg = <0x7110000 0x10000>;
> > + #reset-cells = <1>;
> > +
> > + clock-controller {
> > + compatible = "cix,sky1-audss-clock";
> > + power-domains = <&smc_devpd 0>;
> > + #clock-cells = <1>;
> > + clocks = <&scmi_clk 0>, <&scmi_clk 1>, <&scmi_clk 2>,
> > + <&scmi_clk 3>, <&scmi_clk 4>, <&scmi_clk 5>;
> > + clock-names = "audio_clk0", "audio_clk1", "audio_clk2",
> > + "audio_clk3", "audio_clk4", "audio_clk5";
> > + resets = <&src 0>;
> > + };
> > + };
> > diff --git a/include/dt-bindings/reset/cix,sky1-audss-system-control.h
> > b/include/dt-bindings/reset/cix,sky1-audss-system-control.h
> > new file mode 100644
> > index 000000000000..2ebc5c4f10cd
> > --- /dev/null
> > +++ b/include/dt-bindings/reset/cix,sky1-audss-system-control.h
> > @@ -0,0 +1,27 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
> > +/*
> > + * Copyright 2026 Cix Technology Group Co., Ltd.
> > + */
> > +#ifndef DT_BINDING_RESET_CIX_SKY1_AUDSS_SYSTEM_CONTROL_H
> > +#define DT_BINDING_RESET_CIX_SKY1_AUDSS_SYSTEM_CONTROL_H
> > +
> > +#define AUDSS_I2S0_SW_RST_N 0
>
> Most likely _N is redundant here. Consumers will ignore it completely and this is
> binding used by consumers, not by reset controller.
OK
> > +#define AUDSS_I2S1_SW_RST_N 1
> > +#define AUDSS_I2S2_SW_RST_N 2
> > +#define AUDSS_I2S3_SW_RST_N 3
> > +#define AUDSS_I2S4_SW_RST_N 4
> > +#define AUDSS_I2S5_SW_RST_N 5
> > +#define AUDSS_I2S6_SW_RST_N 6
> > +#define AUDSS_I2S7_SW_RST_N 7
> > +#define AUDSS_I2S8_SW_RST_N 8
> > +#define AUDSS_I2S9_SW_RST_N 9
> > +#define AUDSS_WDT_SW_RST_N 10
> > +#define AUDSS_TIMER_SW_RST_N 11
> > +#define AUDSS_MB0_SW_RST_N 12
> > +#define AUDSS_MB1_SW_RST_N 13
> > +#define AUDSS_HDA_SW_RST_N 14
> > +#define AUDSS_DMAC_SW_RST_N 15
> > +
> > +#define SKY1_AUDSS_SW_RESET_NUM 16
>
> Drop, not a binding.
OK
Thanks,
Joakim
^ permalink raw reply
* [PATCH 2/2] pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI
From: Guoniu Zhou @ 2026-06-09 6:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ulf Hansson,
Peng Fan, Shawn Guo
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux-pm,
Guoniu Zhou, stable
In-Reply-To: <20260609-pm_imx93-v1-0-d06c004b0f51@oss.nxp.com>
The MIPI DSI and CSI domains share control bits for clock and reset, which
can lead to incorrect behavior if one domain disables the shared resource
while the other is still active.
To fix the issue, introduce a shared MIPI PHY power domain to own the
common resources and make DSI and CSI its subdomains. This ensures the
shared bits are properly managed and not disabled while still in use.
Fixes: e9aa77d413c9 ("soc: imx: add i.MX93 media blk ctrl driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
drivers/pmdomain/imx/imx93-blk-ctrl.c | 60 +++++++++++++++++++++++++++++++++--
1 file changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/pmdomain/imx/imx93-blk-ctrl.c b/drivers/pmdomain/imx/imx93-blk-ctrl.c
index 1afc78b034fa..243ce939ba68 100644
--- a/drivers/pmdomain/imx/imx93-blk-ctrl.c
+++ b/drivers/pmdomain/imx/imx93-blk-ctrl.c
@@ -48,6 +48,8 @@
#define PRIO(X) (X)
+#define BLK_CTRL_NO_PARENT UINT_MAX
+
struct imx93_blk_ctrl_domain;
struct imx93_blk_ctrl {
@@ -68,12 +70,18 @@ struct imx93_blk_ctrl_qos {
u32 cfg_prio;
};
+struct imx93_blk_ctrl_subdomain_link {
+ struct generic_pm_domain *parent;
+ struct generic_pm_domain *subdomain;
+};
+
struct imx93_blk_ctrl_domain_data {
const char *name;
const char * const *clk_names;
int num_clks;
u32 rst_mask;
u32 clk_mask;
+ u32 parent;
int num_qos;
struct imx93_blk_ctrl_qos qos[DOMAIN_MAX_QOS];
};
@@ -203,6 +211,13 @@ static void imx93_release_pm_genpd(void *data)
pm_genpd_remove(genpd);
}
+static void imx93_release_subdomain(void *data)
+{
+ struct imx93_blk_ctrl_subdomain_link *link = data;
+
+ pm_genpd_remove_subdomain(link->parent, link->subdomain);
+}
+
static struct lock_class_key blk_ctrl_genpd_lock_class;
static int imx93_blk_ctrl_probe(struct platform_device *pdev)
@@ -302,6 +317,34 @@ static int imx93_blk_ctrl_probe(struct platform_device *pdev)
bc->onecell_data.domains[i] = &domain->genpd;
}
+ for (i = 0; i < bc_data->num_domains; i++) {
+ struct imx93_blk_ctrl_domain *domain = &bc->domains[i];
+ const struct imx93_blk_ctrl_domain_data *data = domain->data;
+ struct imx93_blk_ctrl_subdomain_link *link;
+
+ if (bc_data->skip_mask & BIT(i) ||
+ data->parent == BLK_CTRL_NO_PARENT)
+ continue;
+
+ link = devm_kzalloc(dev, sizeof(*link), GFP_KERNEL);
+ if (!link)
+ return -ENOMEM;
+
+ link->parent = &bc->domains[data->parent].genpd;
+ link->subdomain = &domain->genpd;
+
+ ret = pm_genpd_add_subdomain(&bc->domains[data->parent].genpd,
+ &domain->genpd);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to add subdomain %s\n",
+ domain->genpd.name);
+
+ ret = devm_add_action_or_reset(dev, imx93_release_subdomain, link);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to add subdomain release callback\n");
+ }
+
ret = devm_pm_runtime_enable(dev);
if (ret)
return dev_err_probe(dev, ret, "failed to enable pm-runtime\n");
@@ -326,8 +369,9 @@ static const struct imx93_blk_ctrl_domain_data imx93_media_blk_ctl_domain_data[]
.name = "mediablk-mipi-dsi",
.clk_names = (const char *[]){ "dsi" },
.num_clks = 1,
- .rst_mask = BIT(11) | BIT(12),
- .clk_mask = BIT(11) | BIT(12),
+ .rst_mask = BIT(11),
+ .clk_mask = BIT(11),
+ .parent = IMX93_MEDIABLK_PD_MIPI_PHY,
},
[IMX93_MEDIABLK_PD_MIPI_CSI] = {
.name = "mediablk-mipi-csi",
@@ -335,6 +379,7 @@ static const struct imx93_blk_ctrl_domain_data imx93_media_blk_ctl_domain_data[]
.num_clks = 2,
.rst_mask = BIT(9) | BIT(10),
.clk_mask = BIT(9) | BIT(10),
+ .parent = IMX93_MEDIABLK_PD_MIPI_PHY,
},
[IMX93_MEDIABLK_PD_PXP] = {
.name = "mediablk-pxp",
@@ -342,6 +387,7 @@ static const struct imx93_blk_ctrl_domain_data imx93_media_blk_ctl_domain_data[]
.num_clks = 1,
.rst_mask = BIT(7) | BIT(8),
.clk_mask = BIT(7) | BIT(8),
+ .parent = BLK_CTRL_NO_PARENT,
.num_qos = 2,
.qos = {
{
@@ -363,6 +409,7 @@ static const struct imx93_blk_ctrl_domain_data imx93_media_blk_ctl_domain_data[]
.num_clks = 2,
.rst_mask = BIT(4) | BIT(5) | BIT(6),
.clk_mask = BIT(4) | BIT(5) | BIT(6),
+ .parent = BLK_CTRL_NO_PARENT,
.num_qos = 1,
.qos = {
{
@@ -379,6 +426,7 @@ static const struct imx93_blk_ctrl_domain_data imx93_media_blk_ctl_domain_data[]
.num_clks = 1,
.rst_mask = BIT(2) | BIT(3),
.clk_mask = BIT(2) | BIT(3),
+ .parent = BLK_CTRL_NO_PARENT,
.num_qos = 4,
.qos = {
{
@@ -404,6 +452,14 @@ static const struct imx93_blk_ctrl_domain_data imx93_media_blk_ctl_domain_data[]
}
}
},
+ [IMX93_MEDIABLK_PD_MIPI_PHY] = {
+ .name = "mediablk-mipi-phy",
+ .clk_names = NULL,
+ .num_clks = 0,
+ .rst_mask = BIT(12),
+ .clk_mask = BIT(12),
+ .parent = BLK_CTRL_NO_PARENT,
+ },
};
static const struct regmap_range imx93_media_blk_ctl_yes_ranges[] = {
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: power: imx93: Add MIPI PHY power domain
From: Guoniu Zhou @ 2026-06-09 6:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ulf Hansson,
Peng Fan, Shawn Guo
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux-pm,
Guoniu Zhou
In-Reply-To: <20260609-pm_imx93-v1-0-d06c004b0f51@oss.nxp.com>
Add MIPI PHY power domain for shared PHY resources used by both
MIPI DSI and CSI blocks.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
include/dt-bindings/power/fsl,imx93-power.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/power/fsl,imx93-power.h b/include/dt-bindings/power/fsl,imx93-power.h
index 17f9f015bf7d..071221fe5c57 100644
--- a/include/dt-bindings/power/fsl,imx93-power.h
+++ b/include/dt-bindings/power/fsl,imx93-power.h
@@ -11,5 +11,6 @@
#define IMX93_MEDIABLK_PD_PXP 2
#define IMX93_MEDIABLK_PD_LCDIF 3
#define IMX93_MEDIABLK_PD_ISI 4
+#define IMX93_MEDIABLK_PD_MIPI_PHY 5
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] pmdomain: imx93: Fix shared MIPI PHY resource management
From: Guoniu Zhou @ 2026-06-09 6:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ulf Hansson,
Peng Fan, Shawn Guo
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux-pm,
Guoniu Zhou, stable
The i.MX93 MIPI DSI and CSI domains share control bits for clock and
reset in the media block controller. This creates a resource conflict
where one domain can inadvertently disable shared resources while the
other domain is still active, leading to system instability.
This series fixes the issue by introducing a dedicated MIPI PHY power
domain that owns the shared clock and reset control bits. The DSI and
CSI domains are then made subdomains of this PHY domain, ensuring proper
reference counting and preventing premature resource shutdown.
Tested on i.MX93 EVK with concurrent DSI and CSI operations.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Guoniu Zhou (2):
dt-bindings: power: imx93: Add MIPI PHY power domain
pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI
drivers/pmdomain/imx/imx93-blk-ctrl.c | 60 ++++++++++++++++++++++++++++-
include/dt-bindings/power/fsl,imx93-power.h | 1 +
2 files changed, 59 insertions(+), 2 deletions(-)
---
base-commit: 3b7a18a34e8d3b14c7c926f033488a0350de9759
change-id: 20260608-pm_imx93-6ccc1aa11932
Best regards,
--
Guoniu Zhou <guoniu.zhou@oss.nxp.com>
^ 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