[PATCH v2 0/2] Add FRDM-IMX91 initial support

[Joseph Guo]

On Wed, Dec 03, 2025 at 03:11:21PM +0100, Francesco Valla wrote:
> Hello Joseph,
> 
> thank you for the patch set.
> 
> 
> I tested the series on the actual hardware with [0] on top of the
> mainline Linux kernel and encountered a unmanaged interrupt warning
> during boot, which wasn't there using the downstream NXP u-boot
> version:
> 
> [    1.840096] mmc1: host does not support reading read-only switch, assuming write-enable
> [    1.850352] mmc1: new high speed SDHC card at address 1234
> [    1.857170] mmcblk1: mmc1:1234 SA08G 7.21 GiB
> [    1.864850]  mmcblk1: p1 p2
> [    2.279012] random: crng init done
> [   11.720182] platform pwrseq-usdhc3: deferred probe pending: pwrseq_simple: reset control not ready
> [   11.734562] platform 42890000.ethernet: deferred probe pending: platform: wait for supplier /soc at 0/efuse at 47510000/mac-address at 4ec
> [   17.947574] irq 99: nobody cared (try booting with the "irqpoll" option)
> [   17.954292] CPU: 0 UID: 0 PID: 55 Comm: irq/99-1-0022 Not tainted 6.18.0-01544-g0817234e6cf9-dirty #1 PREEMPT 
> [   17.954302] Hardware name: NXP FRDM-IMX91 Development Board (DT)
> [   17.954306] Call trace:
> [   17.954310]  show_stack+0x18/0x30 (C)
> [   17.954326]  dump_stack_lvl+0x60/0x80
> [   17.954335]  dump_stack+0x18/0x24
> [   17.954341]  __report_bad_irq+0x4c/0xec
> [   17.954351]  note_interrupt+0x33c/0x390
> [   17.954361]  handle_irq_event+0x94/0xbc
> [   17.954368]  handle_level_irq+0xd8/0x170
> [   17.954375]  handle_irq_desc+0x34/0x58
> [   17.954380]  generic_handle_domain_irq+0x1c/0x28
> [   17.954386]  vf610_gpio_irq_handler+0x70/0x110
> [   17.954395]  handle_irq_desc+0x34/0x58
> [   17.954401]  generic_handle_domain_irq+0x1c/0x28
> [   17.954407]  gic_handle_irq+0x4c/0x140
> [   17.954412]  call_on_irq_stack+0x30/0x48
> [   17.954419]  do_interrupt_handler+0x80/0x84
> [   17.954426]  el1_interrupt+0x38/0x60
> [   17.954436]  el1h_64_irq_handler+0x18/0x24
> [   17.954443]  el1h_64_irq+0x6c/0x70
> [   17.954448]  _raw_spin_unlock_irqrestore+0x8/0x44 (P)
> [   17.954457]  wake_threads_waitq+0x60/0x70
> [   17.954463]  irq_thread+0x194/0x32c
> [   17.954469]  kthread+0x12c/0x204
> [   17.954478]  ret_from_fork+0x10/0x20
> [   17.954485] handlers:
> [   18.064352] [<00000000ec900a2b>] irq_default_primary_handler threaded [<00000000a61af792>] pca953x_irq_handler
> [   18.074353] Disabling IRQ #99
> [   18.080294] nxp-pca9450 1-0025: pca9451a probed.
> 
> Further analysis led me to think that this is caused by the fact that
> the PCAL6524 GPIO expander (1-0022) shares its interrupt line with the
> USB Type C port controller (PTN5110). As soon as the first interrupt
> line from the PCAL is enabled (i.e., when the PCA9451A PMIC requests
> its interrupt line, which is provided by the aforementioned PCAL6524),
> the corresponding parent interrupt - which is shared - is also enabled
> and this causes an interrupt storm, at least until the PTN5110 driver
> is probed.
> 
> The interrupt storm causes a noticeable delay during the boot sequence,
> as well as the disabling of the shared IRQ #99, making the device not
> really usable.
> 
> In the downstream version of u-boot, this is taken care by the support
> for the TypeC port controller logic [1], which is however not available
> in upstream u-boot. Until that support is added, I'd suggest to add a
> workaround in here (maybe in SPL code?) that simply disables the
> interrupts for the PTN5110 and clears the interrupt latch as well.
> The IRQ can then be enabled in a proper way by the kernel driver.
> 
> 
> [0] https://lore.kernel.org/all/20251114-imx91_frdm-v1-0-e5763bdf9336@nxp.com/
> [1] https://github.com/nxp-imx/uboot-imx/blob/lf_v2025.04/board/freescale/common/tcpc.c#L1058
Hi Francesco,

Thank you for your test.
Yes we also observe such issue. But we are thinking about find a kernel fix for that,
that's why I didn't submit v2 on kernel upstream.
I appreciate your test result and NXP will have a disucss about this issue to find a fix.

Regards,
Joseph

> 
> 
> Thank you
> 
> 
> Regards,
> 
> Francesco
> 
> 
>