Re: [PATCH v3 3/3] soundwire: qcom: add in-band wake up interrupt support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 28/02/2022 18:01, Pierre-Louis Bossart wrote:

@@ -1424,6 +1464,11 @@ static int swrm_runtime_resume(struct device *dev)
  	struct qcom_swrm_ctrl *ctrl = dev_get_drvdata(dev);
  	int ret;
+ if (ctrl->wake_irq > 0) {
+		if (!irqd_irq_disabled(irq_get_irq_data(ctrl->wake_irq)))
+			disable_irq_nosync(ctrl->wake_irq);
+	}
+
  	clk_prepare_enable(ctrl->hclk);

This one is quite interesting. If you disable the IRQ mechanism but
haven't yet resumed the clock, that leaves a time window where the
peripheral could attempt to drive the line high. what happens in that case?


We did call pm_runtime_get_sync() from Wake IRQ handler, which means that resume should be finished as part of Wake IRQ handler. Any new Interrupt conditions/status generated by slave in the meantime will be cleared while handling SLAVE PEND interrupt.


if (ctrl->clock_stop_not_supported) {
@@ -1491,6 +1536,11 @@ static int __maybe_unused swrm_runtime_suspend(struct device *dev)
usleep_range(300, 305); + if (ctrl->wake_irq > 0) {
+		if (irqd_irq_disabled(irq_get_irq_data(ctrl->wake_irq)))
+			enable_irq(ctrl->wake_irq);
+	}
+

and this one is similar, you could have a case where the peripheral
signals a wake immediately after the ClockStopNow frame, but you may not
yet have enabled the wake detection interrupt.

Would that imply that the wake is missed?
Its Possible it might be missed at that instance, however as the Slave interrupt source condition/status (Ex: button Press) is still not cleared it should generate a Wake interrupt as soon as its enabled.

--srini



  	return 0;
  }



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux