[CAUTION: External Email]
On Fri, 29 Jul 2022 12:34:51 +0200,
Venkata Prasad Potturu wrote:
Also the open and close callbacks are certainly non-irq context, hence
On 7/28/22 18:19, Mark Brown wrote:
Thanks for your time.
On Thu, Jul 28, 2022 at 06:10:50PM +0530, Venkata Prasad Potturu wrote:
@@ -104,14 +105,13 @@ static irqreturn_t i2s_irq_handler(int irq, void *data)
ext_intr_stat = readl(ACP_EXTERNAL_INTR_STAT(adata, rsrc->irqp_used));
- for (i = 0; i < ACP_MAX_STREAM; i++) {
- stream = adata->stream[i];
+ spin_lock_irqsave(&adata->acp_lock, flags);
+ list_for_each_entry(stream, &adata->stream_list, list) {
If we're already in an interrupt handler here (presumably not a threaded
one) why are we using irqsave?
Yes, your statement make sense, I have followed below statement in kernel
document. so used irqsave in interrupt context as well.
We will change it to spin_lock() and send it in the next version.
statement:- spin_lock_irqsave() will turn off interrupts if they are on,
otherwise does nothing (if we are already in an interrupt handler), hence
these functions are safe to call from any context.
you can use spin_lock_irq() instead of irqsave(), too.
Takashi