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;
}
