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