Re: [PATCH] firmware: tegra: bpmp: Make atomic_tx_lock a raw_spinlock

[Waiman Long]

On 5/6/26 2:41 AM, Sebastian Andrzej Siewior wrote:
> On 2026-05-05 15:47:23 [-0400], Waiman Long wrote:
> >   __might_resched+0x254/0x330
> >   rt_spin_lock+0x70/0x140
> >   tegra_bpmp_transfer_atomic+0x118/0x3c0
> >   tegra_bpmp_probe+0x564/0x6f0
> So this is tegra_bpmp_ping().
>
> > I know that interrupt is disabled becasue of the following code.
> >
> > 346 int tegra_bpmp_transfer_atomic(struct tegra_bpmp *bpmp, 347 struct
> > tegra_bpmp_message *msg) 348 { 349 struct tegra_bpmp_channel *channel; 350
> > int err; 351 352 if (WARN_ON(!irqs_disabled())) 353 return -EPERM;
> Well, yes. It disables interrupts just probably to document the time it
> took for the transfer so it can write it then via dev_dbg().
> It is hard to tell what the worst-case delay here is but it is probably
> not important if this is just boot time/ driver probe. Maybe.
> What I am bit more concerned if the actual path of this
> tegra_bpmp_transfer_atomic() invocation via i2c driver is actually
> invoked with disabled interrupts on PREEMPT_RT. Because that might not
> be the case. I've been looking at the i2c call chain and it is not
> obvious what the actual call chain is. There is just
> i2c_in_atomic_xfer_mode() check. So it may or may not be used in the
> end.

tegra_bpmp_channel_write() calls tegra_bpmp_wait_request_channel_free() 
which waits until the channel is freed. So it is hard to tell how long 
does that take. In my case, the bug report happened at boot time.

Anyway, are there other comment about this patch?

Thanks,
Longman