On 2024-08-05 18:07:28 [+0200], Jerome Brunet wrote: > Hi Sebastian, Hi Jerome, > Thanks a lot for taking the time to dig into the driver specifics. > The IRQ handler is actually not awfully critical in this case. The HW > will continue to run regardless of the IRQ being acked or not > > The purpose of the handler is mainly to let Alsa know that 1 (or more) > period is ready. If alsa is too slow to react, and the buffer allows > just a few periods, the HW may under/overflow the buffer. > > IRQF_ONESHOT is fine because snd_pcm_period_elapsed() 'notifies' > all past periods, not just one. The irq handler does not need to > run again until this function has been called. It also helps if the > period is ridiculously small, to try to reduce the number of IRQs. IRQF_ONESHOT is used to disable to keep the IRQ line disabled (after the primary handler) while the threaded handler is running. This implies that the primary handler must not be threaded under PREEMPT_RT. … > I'd prefer #1 too. IRQ is not shared, so the ownership should be fine. > > However I still don't fully understand what we are fixing here TBH. It > seems it could apply to other parts of the kernel so I'd like to > understand what is wrong (and avoid repeating the same mistake) > > * With PREEMPT_RT, both handler will threaded, so they should be able to > call preemptible function, right ? Correct. But flags like IRQF_ONESHOT won't thread the primary handler. > * If so, and spinlock_lock() actually becomes preemptible with > PREEMPT_RT as stated in this change description, why is it problem here ? Because in this case the primary handler is not threaded and runs in not preemptible hard-IRQ context. > Do you have an idea about what is going on ? Yes. Sebastian
