* Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. @ 2011-08-26 13:01 Govindraj.R 2011-08-26 18:36 ` [linux-pm] " Alan Stern ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Govindraj.R @ 2011-08-26 13:01 UTC (permalink / raw) To: Rafael J. Wysocki, Paul Walmsley, Kevin Hilman Cc: linux-omap, linux-pm, Vishwanath Sripathy, Partha Basak, Felipe Balbi, Santosh Shilimkar, Rajendra Nayak, Benoit Cousson, Tero Kristo, Govindraj R, Keshava Munegowda Hello, During system_wide_suspend pm runtime is disabled. I.e. __pm_runtime_disable is called from __device_suspend. Now, if a wakeup interrupt is triggered and the wakeup device irq handler is called even before device_resume and pm_runtime_enable happens, the device irq_handler proceeds to enable clock with runtime API to handle wakeup event. Wouldn't this result in system wide abort since the pm_runtime is not enabled yet from dpm_resume? As we end up accessing regs after doing runtime get_sync. Looks like this scenario is not handled currently. Or Am I missing something here? -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-26 13:01 Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend Govindraj.R @ 2011-08-26 18:36 ` Alan Stern 2011-08-27 6:30 ` Santosh 2011-08-27 6:30 ` [linux-pm] " Santosh 2011-08-26 18:36 ` Alan Stern ` (2 subsequent siblings) 3 siblings, 2 replies; 21+ messages in thread From: Alan Stern @ 2011-08-26 18:36 UTC (permalink / raw) To: Govindraj.R Cc: Rafael J. Wysocki, Paul Walmsley, Kevin Hilman, Tero Kristo, Felipe Balbi, Partha Basak, Keshava Munegowda, linux-pm, linux-omap On Fri, 26 Aug 2011, Govindraj.R wrote: > Hello, > > During system_wide_suspend pm runtime is disabled. > I.e. __pm_runtime_disable is called from __device_suspend. > Now, if a wakeup interrupt is triggered and the wakeup device irq handler > is called even before device_resume and pm_runtime_enable happens, > the device irq_handler proceeds to enable clock with runtime API to > handle wakeup event. > > Wouldn't this result in system wide abort since the pm_runtime is not enabled > yet from dpm_resume? > As we end up accessing regs after doing runtime get_sync. > > Looks like this scenario is not handled currently. > Or Am I missing something here? I don't have the complete picture, but it seems that the IRQ handler needs to check the return code from pm_runtime_get_sync(). If the call fails then the handler shouldn't try to access the device registers. In the case of a genuine wakeup event, the event should be handled later on as part of the resume or resume_noirq processing. However, this does raise a potential problem. What happens if the clocks are needed in order to turn off the IRQ source? Runtime PM won't allow the clocks to be enabled until after interrupts have been enabled, and by then it will be too late -- the source will have caused an interrupt storm. Alan Stern ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-26 18:36 ` [linux-pm] " Alan Stern @ 2011-08-27 6:30 ` Santosh 2011-08-27 6:30 ` [linux-pm] " Santosh 1 sibling, 0 replies; 21+ messages in thread From: Santosh @ 2011-08-27 6:30 UTC (permalink / raw) To: Alan Stern Cc: Tero Kristo, Felipe Balbi, Partha Basak, Govindraj.R, Keshava Munegowda, linux-pm, linux-omap Alen, On Saturday 27 August 2011 12:06 AM, Alan Stern wrote: > On Fri, 26 Aug 2011, Govindraj.R wrote: > >> Hello, >> >> During system_wide_suspend pm runtime is disabled. >> I.e. __pm_runtime_disable is called from __device_suspend. >> Now, if a wakeup interrupt is triggered and the wakeup device irq handler >> is called even before device_resume and pm_runtime_enable happens, >> the device irq_handler proceeds to enable clock with runtime API to >> handle wakeup event. >> >> Wouldn't this result in system wide abort since the pm_runtime is not enabled >> yet from dpm_resume? >> As we end up accessing regs after doing runtime get_sync. >> >> Looks like this scenario is not handled currently. >> Or Am I missing something here? > > I don't have the complete picture, but it seems that the IRQ handler > needs to check the return code from pm_runtime_get_sync(). If the call > fails then the handler shouldn't try to access the device registers. > > In the case of a genuine wakeup event, the event should be handled > later on as part of the resume or resume_noirq processing. > > However, this does raise a potential problem. What happens if the > clocks are needed in order to turn off the IRQ source? Runtime PM > won't allow the clocks to be enabled until after interrupts have been > enabled, and by then it will be too late -- the source will have caused > an interrupt storm. > I might be wrong here, but after discussion with Govindraj on this issue, it seems there is a flaw in the way OMAP chain handler handling the child interrupts. On OMAP, we have special interrupt wakeup source at PRCM level and many devices can trigger wakeup from low power via this common interrupt source. The common interrupt source upon wakeup from low power state, decodes the source of interrupt and based on that source, calls the respective device ISR directly. The issue I see here is, the ISR on _a_ device (UART in this case) is happening even before UART resume and DPM resume has been completed. If this is the case, then it is surely asking for trouble. Because not just clocks, but even driver state machine is already in suspend state when the ISR is called. Regards Santosh ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-26 18:36 ` [linux-pm] " Alan Stern 2011-08-27 6:30 ` Santosh @ 2011-08-27 6:30 ` Santosh 2011-08-27 14:01 ` Alan Stern 2011-08-27 14:01 ` Alan Stern 1 sibling, 2 replies; 21+ messages in thread From: Santosh @ 2011-08-27 6:30 UTC (permalink / raw) To: Alan Stern Cc: Govindraj.R, Partha Basak, Tero Kristo, Felipe Balbi, Keshava Munegowda, linux-pm, linux-omap Alen, On Saturday 27 August 2011 12:06 AM, Alan Stern wrote: > On Fri, 26 Aug 2011, Govindraj.R wrote: > >> Hello, >> >> During system_wide_suspend pm runtime is disabled. >> I.e. __pm_runtime_disable is called from __device_suspend. >> Now, if a wakeup interrupt is triggered and the wakeup device irq handler >> is called even before device_resume and pm_runtime_enable happens, >> the device irq_handler proceeds to enable clock with runtime API to >> handle wakeup event. >> >> Wouldn't this result in system wide abort since the pm_runtime is not enabled >> yet from dpm_resume? >> As we end up accessing regs after doing runtime get_sync. >> >> Looks like this scenario is not handled currently. >> Or Am I missing something here? > > I don't have the complete picture, but it seems that the IRQ handler > needs to check the return code from pm_runtime_get_sync(). If the call > fails then the handler shouldn't try to access the device registers. > > In the case of a genuine wakeup event, the event should be handled > later on as part of the resume or resume_noirq processing. > > However, this does raise a potential problem. What happens if the > clocks are needed in order to turn off the IRQ source? Runtime PM > won't allow the clocks to be enabled until after interrupts have been > enabled, and by then it will be too late -- the source will have caused > an interrupt storm. > I might be wrong here, but after discussion with Govindraj on this issue, it seems there is a flaw in the way OMAP chain handler handling the child interrupts. On OMAP, we have special interrupt wakeup source at PRCM level and many devices can trigger wakeup from low power via this common interrupt source. The common interrupt source upon wakeup from low power state, decodes the source of interrupt and based on that source, calls the respective device ISR directly. The issue I see here is, the ISR on _a_ device (UART in this case) is happening even before UART resume and DPM resume has been completed. If this is the case, then it is surely asking for trouble. Because not just clocks, but even driver state machine is already in suspend state when the ISR is called. Regards Santosh ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-27 6:30 ` [linux-pm] " Santosh @ 2011-08-27 14:01 ` Alan Stern 2011-08-27 14:49 ` Santosh 2011-08-27 14:49 ` Santosh 2011-08-27 14:01 ` Alan Stern 1 sibling, 2 replies; 21+ messages in thread From: Alan Stern @ 2011-08-27 14:01 UTC (permalink / raw) To: Santosh Cc: Govindraj.R, Partha Basak, Tero Kristo, Felipe Balbi, Keshava Munegowda, linux-pm, linux-omap On Sat, 27 Aug 2011, Santosh wrote: > I might be wrong here, but after discussion with Govindraj on this > issue, it seems there is a flaw in the way OMAP chain handler > handling the child interrupts. > > On OMAP, we have special interrupt wakeup source at PRCM level and > many devices can trigger wakeup from low power via this common > interrupt source. The common interrupt source upon wakeup from low > power state, decodes the source of interrupt and based on that > source, calls the respective device ISR directly. > > The issue I see here is, the ISR on _a_ device (UART in this case) > is happening even before UART resume and DPM resume has been completed. > If this is the case, then it is surely asking for trouble. Because not > just clocks, but even driver state machine is already in suspend state > when the ISR is called. If the driver state machine is in the suspend state when the ISR is called, then the ISR should realize it is handling a wakeup event instead of a normal I/O event. All it needs to do is turn off the interrupt source; the event itself will be taken care of during the device's resume callback. Alan Stern ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-27 14:01 ` Alan Stern @ 2011-08-27 14:49 ` Santosh 2011-08-27 19:42 ` Alan Stern 2011-08-27 19:42 ` Alan Stern 2011-08-27 14:49 ` Santosh 1 sibling, 2 replies; 21+ messages in thread From: Santosh @ 2011-08-27 14:49 UTC (permalink / raw) To: Alan Stern Cc: Govindraj.R, Partha Basak, Tero Kristo, Felipe Balbi, Keshava Munegowda, linux-pm, linux-omap On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: > On Sat, 27 Aug 2011, Santosh wrote: > >> I might be wrong here, but after discussion with Govindraj on this >> issue, it seems there is a flaw in the way OMAP chain handler >> handling the child interrupts. >> >> On OMAP, we have special interrupt wakeup source at PRCM level and >> many devices can trigger wakeup from low power via this common >> interrupt source. The common interrupt source upon wakeup from low >> power state, decodes the source of interrupt and based on that >> source, calls the respective device ISR directly. >> >> The issue I see here is, the ISR on _a_ device (UART in this case) >> is happening even before UART resume and DPM resume has been completed. >> If this is the case, then it is surely asking for trouble. Because not >> just clocks, but even driver state machine is already in suspend state >> when the ISR is called. > > If the driver state machine is in the suspend state when the ISR is > called, then the ISR should realize it is handling a wakeup event > instead of a normal I/O event. All it needs to do is turn off the > interrupt source; the event itself will be taken care of during the > device's resume callback. > Good point but the ISR is called as a function call and not real hardware event so no need to turn-off the source in the child ISR. Parent ISR will clear the source anyways. But the intention here is to record the event for the child. I mean for UART wakeup, the received character should be extracted. If not done, UART will loose that character because the event is lost. So not sure how the event will be taken care during resume callback. Could you elaborate bit more on last comment please? Regards Santosh ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-27 14:49 ` Santosh @ 2011-08-27 19:42 ` Alan Stern 2011-09-07 15:48 ` Tero Kristo 2011-09-07 15:48 ` [linux-pm] " Tero Kristo 2011-08-27 19:42 ` Alan Stern 1 sibling, 2 replies; 21+ messages in thread From: Alan Stern @ 2011-08-27 19:42 UTC (permalink / raw) To: Santosh Cc: Govindraj.R, Partha Basak, Tero Kristo, Felipe Balbi, Keshava Munegowda, linux-pm, linux-omap On Sat, 27 Aug 2011, Santosh wrote: > On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: > > On Sat, 27 Aug 2011, Santosh wrote: > > > >> I might be wrong here, but after discussion with Govindraj on this > >> issue, it seems there is a flaw in the way OMAP chain handler > >> handling the child interrupts. > >> > >> On OMAP, we have special interrupt wakeup source at PRCM level and > >> many devices can trigger wakeup from low power via this common > >> interrupt source. The common interrupt source upon wakeup from low > >> power state, decodes the source of interrupt and based on that > >> source, calls the respective device ISR directly. > >> > >> The issue I see here is, the ISR on _a_ device (UART in this case) > >> is happening even before UART resume and DPM resume has been completed. > >> If this is the case, then it is surely asking for trouble. Because not > >> just clocks, but even driver state machine is already in suspend state > >> when the ISR is called. > > > > If the driver state machine is in the suspend state when the ISR is > > called, then the ISR should realize it is handling a wakeup event > > instead of a normal I/O event. All it needs to do is turn off the > > interrupt source; the event itself will be taken care of during the > > device's resume callback. > > > Good point but the ISR is called as a function call and not real > hardware event so no need to turn-off the source in the child > ISR. Parent ISR will clear the source anyways. > > But the intention here is to record the event for the child. In that case the ISR only has to record the event. > I mean for UART wakeup, the received character should be > extracted. If not done, UART will loose that character because > the event is lost. So not sure how the event will be taken > care during resume callback. Could you elaborate bit more on > last comment please? The resume callback routine must check to see if an event was recorded. If one was, the routine must see whether a character was received while the system was asleep and extract the character from the UART. (It probably won't hurt to do this even if an event wasn't recorded.) Alan Stern ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-27 19:42 ` Alan Stern @ 2011-09-07 15:48 ` Tero Kristo 2011-09-07 15:48 ` [linux-pm] " Tero Kristo 1 sibling, 0 replies; 21+ messages in thread From: Tero Kristo @ 2011-09-07 15:48 UTC (permalink / raw) To: Alan Stern Cc: Balbi, Felipe, Basak, Partha, R, Govindraj, Munegowda, Keshava, linux-pm, linux-omap Hi, On Sat, 2011-08-27 at 21:42 +0200, Alan Stern wrote: > On Sat, 27 Aug 2011, Santosh wrote: > > > On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: > > > On Sat, 27 Aug 2011, Santosh wrote: > > > > > >> I might be wrong here, but after discussion with Govindraj on this > > >> issue, it seems there is a flaw in the way OMAP chain handler > > >> handling the child interrupts. > > >> > > >> On OMAP, we have special interrupt wakeup source at PRCM level and > > >> many devices can trigger wakeup from low power via this common > > >> interrupt source. The common interrupt source upon wakeup from low > > >> power state, decodes the source of interrupt and based on that > > >> source, calls the respective device ISR directly. > > >> > > >> The issue I see here is, the ISR on _a_ device (UART in this case) > > >> is happening even before UART resume and DPM resume has been completed. > > >> If this is the case, then it is surely asking for trouble. Because not > > >> just clocks, but even driver state machine is already in suspend state > > >> when the ISR is called. > > > > > > If the driver state machine is in the suspend state when the ISR is > > > called, then the ISR should realize it is handling a wakeup event > > > instead of a normal I/O event. All it needs to do is turn off the > > > interrupt source; the event itself will be taken care of during the > > > device's resume callback. > > > > > Good point but the ISR is called as a function call and not real > > hardware event so no need to turn-off the source in the child > > ISR. Parent ISR will clear the source anyways. > > > > But the intention here is to record the event for the child. > > In that case the ISR only has to record the event. > > > I mean for UART wakeup, the received character should be > > extracted. If not done, UART will loose that character because > > the event is lost. So not sure how the event will be taken > > care during resume callback. Could you elaborate bit more on > > last comment please? > > The resume callback routine must check to see if an event was recorded. > If one was, the routine must see whether a character was received while > the system was asleep and extract the character from the UART. (It > probably won't hurt to do this even if an event wasn't recorded.) > > Alan Stern > After thinking about this problem and looking at possible ways to fix it, I am planning to change the PRCM chain handler to be a driver, which gets suspended along with the rest of the system. This means the PRCM interrupt would get disabled also during this time, and it would be enabled in the driver->complete() call, which should happen after rest of the drivers have been able to enable their PM runtime in the driver->resume() call chain. Do you see any problems with this approach? The only issue I am seeing myself is if some driver decides to do resume() in the complete() pm-op and potentially screwing the ordering here... -Tero Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-27 19:42 ` Alan Stern 2011-09-07 15:48 ` Tero Kristo @ 2011-09-07 15:48 ` Tero Kristo 2011-09-07 17:59 ` Kevin Hilman 2011-09-07 17:59 ` Kevin Hilman 1 sibling, 2 replies; 21+ messages in thread From: Tero Kristo @ 2011-09-07 15:48 UTC (permalink / raw) To: Alan Stern Cc: Shilimkar, Santosh, R, Govindraj, Basak, Partha, Balbi, Felipe, Munegowda, Keshava, linux-pm, linux-omap Hi, On Sat, 2011-08-27 at 21:42 +0200, Alan Stern wrote: > On Sat, 27 Aug 2011, Santosh wrote: > > > On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: > > > On Sat, 27 Aug 2011, Santosh wrote: > > > > > >> I might be wrong here, but after discussion with Govindraj on this > > >> issue, it seems there is a flaw in the way OMAP chain handler > > >> handling the child interrupts. > > >> > > >> On OMAP, we have special interrupt wakeup source at PRCM level and > > >> many devices can trigger wakeup from low power via this common > > >> interrupt source. The common interrupt source upon wakeup from low > > >> power state, decodes the source of interrupt and based on that > > >> source, calls the respective device ISR directly. > > >> > > >> The issue I see here is, the ISR on _a_ device (UART in this case) > > >> is happening even before UART resume and DPM resume has been completed. > > >> If this is the case, then it is surely asking for trouble. Because not > > >> just clocks, but even driver state machine is already in suspend state > > >> when the ISR is called. > > > > > > If the driver state machine is in the suspend state when the ISR is > > > called, then the ISR should realize it is handling a wakeup event > > > instead of a normal I/O event. All it needs to do is turn off the > > > interrupt source; the event itself will be taken care of during the > > > device's resume callback. > > > > > Good point but the ISR is called as a function call and not real > > hardware event so no need to turn-off the source in the child > > ISR. Parent ISR will clear the source anyways. > > > > But the intention here is to record the event for the child. > > In that case the ISR only has to record the event. > > > I mean for UART wakeup, the received character should be > > extracted. If not done, UART will loose that character because > > the event is lost. So not sure how the event will be taken > > care during resume callback. Could you elaborate bit more on > > last comment please? > > The resume callback routine must check to see if an event was recorded. > If one was, the routine must see whether a character was received while > the system was asleep and extract the character from the UART. (It > probably won't hurt to do this even if an event wasn't recorded.) > > Alan Stern > After thinking about this problem and looking at possible ways to fix it, I am planning to change the PRCM chain handler to be a driver, which gets suspended along with the rest of the system. This means the PRCM interrupt would get disabled also during this time, and it would be enabled in the driver->complete() call, which should happen after rest of the drivers have been able to enable their PM runtime in the driver->resume() call chain. Do you see any problems with this approach? The only issue I am seeing myself is if some driver decides to do resume() in the complete() pm-op and potentially screwing the ordering here... -Tero Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-09-07 15:48 ` [linux-pm] " Tero Kristo @ 2011-09-07 17:59 ` Kevin Hilman 2011-09-08 4:58 ` Tero Kristo 2011-09-08 4:58 ` [linux-pm] " Tero Kristo 2011-09-07 17:59 ` Kevin Hilman 1 sibling, 2 replies; 21+ messages in thread From: Kevin Hilman @ 2011-09-07 17:59 UTC (permalink / raw) To: t-kristo Cc: Alan Stern, Shilimkar, Santosh, R, Govindraj, Basak, Partha, Balbi, Felipe, Munegowda, Keshava, linux-pm, linux-omap Tero Kristo <t-kristo@ti.com> writes: > Hi, > > On Sat, 2011-08-27 at 21:42 +0200, Alan Stern wrote: >> On Sat, 27 Aug 2011, Santosh wrote: >> >> > On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: >> > > On Sat, 27 Aug 2011, Santosh wrote: >> > > >> > >> I might be wrong here, but after discussion with Govindraj on this >> > >> issue, it seems there is a flaw in the way OMAP chain handler >> > >> handling the child interrupts. >> > >> >> > >> On OMAP, we have special interrupt wakeup source at PRCM level and >> > >> many devices can trigger wakeup from low power via this common >> > >> interrupt source. The common interrupt source upon wakeup from low >> > >> power state, decodes the source of interrupt and based on that >> > >> source, calls the respective device ISR directly. >> > >> >> > >> The issue I see here is, the ISR on _a_ device (UART in this case) >> > >> is happening even before UART resume and DPM resume has been completed. >> > >> If this is the case, then it is surely asking for trouble. Because not >> > >> just clocks, but even driver state machine is already in suspend state >> > >> when the ISR is called. >> > > >> > > If the driver state machine is in the suspend state when the ISR is >> > > called, then the ISR should realize it is handling a wakeup event >> > > instead of a normal I/O event. All it needs to do is turn off the >> > > interrupt source; the event itself will be taken care of during the >> > > device's resume callback. >> > > >> > Good point but the ISR is called as a function call and not real >> > hardware event so no need to turn-off the source in the child >> > ISR. Parent ISR will clear the source anyways. >> > >> > But the intention here is to record the event for the child. >> >> In that case the ISR only has to record the event. >> >> > I mean for UART wakeup, the received character should be >> > extracted. If not done, UART will loose that character because >> > the event is lost. So not sure how the event will be taken >> > care during resume callback. Could you elaborate bit more on >> > last comment please? >> >> The resume callback routine must check to see if an event was recorded. >> If one was, the routine must see whether a character was received while >> the system was asleep and extract the character from the UART. (It >> probably won't hurt to do this even if an event wasn't recorded.) >> >> Alan Stern >> > > After thinking about this problem and looking at possible ways to fix > it, I am planning to change the PRCM chain handler to be a driver, which > gets suspended along with the rest of the system. This means the PRCM > interrupt would get disabled also during this time, and it would be > enabled in the driver->complete() call, which should happen after rest > of the drivers have been able to enable their PM runtime in the > driver->resume() call chain. Do you see any problems with this approach? How will the system wakeup from retention or off-mode if the PRCM IRQ is disabled? Besides that, I don't like this approach because it leaves a rather long window during which no PRCM-triggered wakeup events can happen. This is not good since we also want potential wakeup events that happen *during* system suspend to be able to cancel the suspend. > The only issue I am seeing myself is if some driver decides to do > resume() in the complete() pm-op and potentially screwing the ordering > here... Personally, I think Alan's approach is the only scalable approach. This has to be handled by the drivers. If the driver's ISR does a pm_runtime_get_sync() and it fails (in this case, with -EACCESS since runtime PM is disabled), the driver should handle that handle as Alan described above. Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-09-07 17:59 ` Kevin Hilman @ 2011-09-08 4:58 ` Tero Kristo 2011-09-08 4:58 ` [linux-pm] " Tero Kristo 1 sibling, 0 replies; 21+ messages in thread From: Tero Kristo @ 2011-09-08 4:58 UTC (permalink / raw) To: Hilman, Kevin Cc: Balbi, Felipe, Basak, Partha, R, Govindraj, Munegowda, Keshava, linux-pm, linux-omap On Wed, 2011-09-07 at 19:59 +0200, Hilman, Kevin wrote: > Tero Kristo <t-kristo@ti.com> writes: > > > Hi, > > > > On Sat, 2011-08-27 at 21:42 +0200, Alan Stern wrote: > >> On Sat, 27 Aug 2011, Santosh wrote: > >> > >> > On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: > >> > > On Sat, 27 Aug 2011, Santosh wrote: > >> > > > >> > >> I might be wrong here, but after discussion with Govindraj on this > >> > >> issue, it seems there is a flaw in the way OMAP chain handler > >> > >> handling the child interrupts. > >> > >> > >> > >> On OMAP, we have special interrupt wakeup source at PRCM level and > >> > >> many devices can trigger wakeup from low power via this common > >> > >> interrupt source. The common interrupt source upon wakeup from low > >> > >> power state, decodes the source of interrupt and based on that > >> > >> source, calls the respective device ISR directly. > >> > >> > >> > >> The issue I see here is, the ISR on _a_ device (UART in this case) > >> > >> is happening even before UART resume and DPM resume has been completed. > >> > >> If this is the case, then it is surely asking for trouble. Because not > >> > >> just clocks, but even driver state machine is already in suspend state > >> > >> when the ISR is called. > >> > > > >> > > If the driver state machine is in the suspend state when the ISR is > >> > > called, then the ISR should realize it is handling a wakeup event > >> > > instead of a normal I/O event. All it needs to do is turn off the > >> > > interrupt source; the event itself will be taken care of during the > >> > > device's resume callback. > >> > > > >> > Good point but the ISR is called as a function call and not real > >> > hardware event so no need to turn-off the source in the child > >> > ISR. Parent ISR will clear the source anyways. > >> > > >> > But the intention here is to record the event for the child. > >> > >> In that case the ISR only has to record the event. > >> > >> > I mean for UART wakeup, the received character should be > >> > extracted. If not done, UART will loose that character because > >> > the event is lost. So not sure how the event will be taken > >> > care during resume callback. Could you elaborate bit more on > >> > last comment please? > >> > >> The resume callback routine must check to see if an event was recorded. > >> If one was, the routine must see whether a character was received while > >> the system was asleep and extract the character from the UART. (It > >> probably won't hurt to do this even if an event wasn't recorded.) > >> > >> Alan Stern > >> > > > > After thinking about this problem and looking at possible ways to fix > > it, I am planning to change the PRCM chain handler to be a driver, which > > gets suspended along with the rest of the system. This means the PRCM > > interrupt would get disabled also during this time, and it would be > > enabled in the driver->complete() call, which should happen after rest > > of the drivers have been able to enable their PM runtime in the > > driver->resume() call chain. Do you see any problems with this approach? > > How will the system wakeup from retention or off-mode if the PRCM IRQ is > disabled? This is actually some sort of an issue with retention if we disable PRCM irq completely, off works purely with wakeup signals as we come out of reset. Anyway, I did some experimentation with this, and OMAP3 is able to wake up if we leave WKUP irq up, but disable IO chain irq. IO chain events seem to trigger a WKUP event also always, we just postpone the processing of IO chain until later. I had to also split the wakeup clearing for OMAP3 into 2 parts, one part handles wakeups and another IO chain. Currently both IO chain and WKUP are acked by the same handler. > Besides that, I don't like this approach because it leaves a rather long > window during which no PRCM-triggered wakeup events can happen. This is > not good since we also want potential wakeup events that happen *during* > system suspend to be able to cancel the suspend. This should also be taken care of by the approach described above. > > > The only issue I am seeing myself is if some driver decides to do > > resume() in the complete() pm-op and potentially screwing the ordering > > here... > > Personally, I think Alan's approach is the only scalable approach. This > has to be handled by the drivers. > > If the driver's ISR does a pm_runtime_get_sync() and it fails (in this > case, with -EACCESS since runtime PM is disabled), the driver should > handle that handle as Alan described above. Yea I think this probably needs to be done anyway, at least on some cases. The PRCM chain handler approach might be able to solve most of the problems though. I think I will post what I have anyway for comments hopefully later today, so you can have a look and say what you think. -Tero Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-09-07 17:59 ` Kevin Hilman 2011-09-08 4:58 ` Tero Kristo @ 2011-09-08 4:58 ` Tero Kristo 2011-09-08 13:51 ` Kevin Hilman 2011-09-08 13:51 ` Kevin Hilman 1 sibling, 2 replies; 21+ messages in thread From: Tero Kristo @ 2011-09-08 4:58 UTC (permalink / raw) To: Hilman, Kevin Cc: Alan Stern, Shilimkar, Santosh, R, Govindraj, Basak, Partha, Balbi, Felipe, Munegowda, Keshava, linux-pm, linux-omap On Wed, 2011-09-07 at 19:59 +0200, Hilman, Kevin wrote: > Tero Kristo <t-kristo@ti.com> writes: > > > Hi, > > > > On Sat, 2011-08-27 at 21:42 +0200, Alan Stern wrote: > >> On Sat, 27 Aug 2011, Santosh wrote: > >> > >> > On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: > >> > > On Sat, 27 Aug 2011, Santosh wrote: > >> > > > >> > >> I might be wrong here, but after discussion with Govindraj on this > >> > >> issue, it seems there is a flaw in the way OMAP chain handler > >> > >> handling the child interrupts. > >> > >> > >> > >> On OMAP, we have special interrupt wakeup source at PRCM level and > >> > >> many devices can trigger wakeup from low power via this common > >> > >> interrupt source. The common interrupt source upon wakeup from low > >> > >> power state, decodes the source of interrupt and based on that > >> > >> source, calls the respective device ISR directly. > >> > >> > >> > >> The issue I see here is, the ISR on _a_ device (UART in this case) > >> > >> is happening even before UART resume and DPM resume has been completed. > >> > >> If this is the case, then it is surely asking for trouble. Because not > >> > >> just clocks, but even driver state machine is already in suspend state > >> > >> when the ISR is called. > >> > > > >> > > If the driver state machine is in the suspend state when the ISR is > >> > > called, then the ISR should realize it is handling a wakeup event > >> > > instead of a normal I/O event. All it needs to do is turn off the > >> > > interrupt source; the event itself will be taken care of during the > >> > > device's resume callback. > >> > > > >> > Good point but the ISR is called as a function call and not real > >> > hardware event so no need to turn-off the source in the child > >> > ISR. Parent ISR will clear the source anyways. > >> > > >> > But the intention here is to record the event for the child. > >> > >> In that case the ISR only has to record the event. > >> > >> > I mean for UART wakeup, the received character should be > >> > extracted. If not done, UART will loose that character because > >> > the event is lost. So not sure how the event will be taken > >> > care during resume callback. Could you elaborate bit more on > >> > last comment please? > >> > >> The resume callback routine must check to see if an event was recorded. > >> If one was, the routine must see whether a character was received while > >> the system was asleep and extract the character from the UART. (It > >> probably won't hurt to do this even if an event wasn't recorded.) > >> > >> Alan Stern > >> > > > > After thinking about this problem and looking at possible ways to fix > > it, I am planning to change the PRCM chain handler to be a driver, which > > gets suspended along with the rest of the system. This means the PRCM > > interrupt would get disabled also during this time, and it would be > > enabled in the driver->complete() call, which should happen after rest > > of the drivers have been able to enable their PM runtime in the > > driver->resume() call chain. Do you see any problems with this approach? > > How will the system wakeup from retention or off-mode if the PRCM IRQ is > disabled? This is actually some sort of an issue with retention if we disable PRCM irq completely, off works purely with wakeup signals as we come out of reset. Anyway, I did some experimentation with this, and OMAP3 is able to wake up if we leave WKUP irq up, but disable IO chain irq. IO chain events seem to trigger a WKUP event also always, we just postpone the processing of IO chain until later. I had to also split the wakeup clearing for OMAP3 into 2 parts, one part handles wakeups and another IO chain. Currently both IO chain and WKUP are acked by the same handler. > Besides that, I don't like this approach because it leaves a rather long > window during which no PRCM-triggered wakeup events can happen. This is > not good since we also want potential wakeup events that happen *during* > system suspend to be able to cancel the suspend. This should also be taken care of by the approach described above. > > > The only issue I am seeing myself is if some driver decides to do > > resume() in the complete() pm-op and potentially screwing the ordering > > here... > > Personally, I think Alan's approach is the only scalable approach. This > has to be handled by the drivers. > > If the driver's ISR does a pm_runtime_get_sync() and it fails (in this > case, with -EACCESS since runtime PM is disabled), the driver should > handle that handle as Alan described above. Yea I think this probably needs to be done anyway, at least on some cases. The PRCM chain handler approach might be able to solve most of the problems though. I think I will post what I have anyway for comments hopefully later today, so you can have a look and say what you think. -Tero Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-09-08 4:58 ` [linux-pm] " Tero Kristo @ 2011-09-08 13:51 ` Kevin Hilman 2011-09-08 13:51 ` Kevin Hilman 1 sibling, 0 replies; 21+ messages in thread From: Kevin Hilman @ 2011-09-08 13:51 UTC (permalink / raw) To: t-kristo Cc: Alan Stern, Shilimkar, Santosh, R, Govindraj, Basak, Partha, Balbi, Felipe, Munegowda, Keshava, linux-pm, linux-omap Hi Tero, Tero Kristo <t-kristo@ti.com> writes: > On Wed, 2011-09-07 at 19:59 +0200, Hilman, Kevin wrote: >> Tero Kristo <t-kristo@ti.com> writes: [...] >> > After thinking about this problem and looking at possible ways to fix >> > it, I am planning to change the PRCM chain handler to be a driver, which >> > gets suspended along with the rest of the system. This means the PRCM >> > interrupt would get disabled also during this time, and it would be >> > enabled in the driver->complete() call, which should happen after rest >> > of the drivers have been able to enable their PM runtime in the >> > driver->resume() call chain. Do you see any problems with this approach? >> >> How will the system wakeup from retention or off-mode if the PRCM IRQ is >> disabled? > > This is actually some sort of an issue with retention if we disable PRCM > irq completely, off works purely with wakeup signals as we come out of > reset. Anyway, I did some experimentation with this, and OMAP3 is able > to wake up if we leave WKUP irq up, but disable IO chain irq. IO chain > events seem to trigger a WKUP event also always, we just postpone the > processing of IO chain until later. I had to also split the wakeup > clearing for OMAP3 into 2 parts, one part handles wakeups and another IO > chain. Currently both IO chain and WKUP are acked by the same handler. Here's another option, which is kind of a hybrid of what's been discussed so far. The PRCM driver would leave the IRQs enabled during suspend, but would just delay delivering them to the drivers. IOW, handle/clear the PRCM IRQ normally, but delay delivery of the *device* IRQ until the ->complete callback of the PRCM driver. Doing this ensures all the drivers are resumed before any device IRQ is delivered, and doesn't require any additional queuing of events in the drivers. Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-09-08 4:58 ` [linux-pm] " Tero Kristo 2011-09-08 13:51 ` Kevin Hilman @ 2011-09-08 13:51 ` Kevin Hilman 1 sibling, 0 replies; 21+ messages in thread From: Kevin Hilman @ 2011-09-08 13:51 UTC (permalink / raw) To: t-kristo Cc: Balbi, Felipe, Basak, Partha, R, Govindraj, Munegowda, Keshava, linux-pm, linux-omap Hi Tero, Tero Kristo <t-kristo@ti.com> writes: > On Wed, 2011-09-07 at 19:59 +0200, Hilman, Kevin wrote: >> Tero Kristo <t-kristo@ti.com> writes: [...] >> > After thinking about this problem and looking at possible ways to fix >> > it, I am planning to change the PRCM chain handler to be a driver, which >> > gets suspended along with the rest of the system. This means the PRCM >> > interrupt would get disabled also during this time, and it would be >> > enabled in the driver->complete() call, which should happen after rest >> > of the drivers have been able to enable their PM runtime in the >> > driver->resume() call chain. Do you see any problems with this approach? >> >> How will the system wakeup from retention or off-mode if the PRCM IRQ is >> disabled? > > This is actually some sort of an issue with retention if we disable PRCM > irq completely, off works purely with wakeup signals as we come out of > reset. Anyway, I did some experimentation with this, and OMAP3 is able > to wake up if we leave WKUP irq up, but disable IO chain irq. IO chain > events seem to trigger a WKUP event also always, we just postpone the > processing of IO chain until later. I had to also split the wakeup > clearing for OMAP3 into 2 parts, one part handles wakeups and another IO > chain. Currently both IO chain and WKUP are acked by the same handler. Here's another option, which is kind of a hybrid of what's been discussed so far. The PRCM driver would leave the IRQs enabled during suspend, but would just delay delivering them to the drivers. IOW, handle/clear the PRCM IRQ normally, but delay delivery of the *device* IRQ until the ->complete callback of the PRCM driver. Doing this ensures all the drivers are resumed before any device IRQ is delivered, and doesn't require any additional queuing of events in the drivers. Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-09-07 15:48 ` [linux-pm] " Tero Kristo 2011-09-07 17:59 ` Kevin Hilman @ 2011-09-07 17:59 ` Kevin Hilman 1 sibling, 0 replies; 21+ messages in thread From: Kevin Hilman @ 2011-09-07 17:59 UTC (permalink / raw) To: t-kristo Cc: Balbi, Felipe, Basak, Partha, R, Govindraj, Munegowda, Keshava, linux-pm, linux-omap Tero Kristo <t-kristo@ti.com> writes: > Hi, > > On Sat, 2011-08-27 at 21:42 +0200, Alan Stern wrote: >> On Sat, 27 Aug 2011, Santosh wrote: >> >> > On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: >> > > On Sat, 27 Aug 2011, Santosh wrote: >> > > >> > >> I might be wrong here, but after discussion with Govindraj on this >> > >> issue, it seems there is a flaw in the way OMAP chain handler >> > >> handling the child interrupts. >> > >> >> > >> On OMAP, we have special interrupt wakeup source at PRCM level and >> > >> many devices can trigger wakeup from low power via this common >> > >> interrupt source. The common interrupt source upon wakeup from low >> > >> power state, decodes the source of interrupt and based on that >> > >> source, calls the respective device ISR directly. >> > >> >> > >> The issue I see here is, the ISR on _a_ device (UART in this case) >> > >> is happening even before UART resume and DPM resume has been completed. >> > >> If this is the case, then it is surely asking for trouble. Because not >> > >> just clocks, but even driver state machine is already in suspend state >> > >> when the ISR is called. >> > > >> > > If the driver state machine is in the suspend state when the ISR is >> > > called, then the ISR should realize it is handling a wakeup event >> > > instead of a normal I/O event. All it needs to do is turn off the >> > > interrupt source; the event itself will be taken care of during the >> > > device's resume callback. >> > > >> > Good point but the ISR is called as a function call and not real >> > hardware event so no need to turn-off the source in the child >> > ISR. Parent ISR will clear the source anyways. >> > >> > But the intention here is to record the event for the child. >> >> In that case the ISR only has to record the event. >> >> > I mean for UART wakeup, the received character should be >> > extracted. If not done, UART will loose that character because >> > the event is lost. So not sure how the event will be taken >> > care during resume callback. Could you elaborate bit more on >> > last comment please? >> >> The resume callback routine must check to see if an event was recorded. >> If one was, the routine must see whether a character was received while >> the system was asleep and extract the character from the UART. (It >> probably won't hurt to do this even if an event wasn't recorded.) >> >> Alan Stern >> > > After thinking about this problem and looking at possible ways to fix > it, I am planning to change the PRCM chain handler to be a driver, which > gets suspended along with the rest of the system. This means the PRCM > interrupt would get disabled also during this time, and it would be > enabled in the driver->complete() call, which should happen after rest > of the drivers have been able to enable their PM runtime in the > driver->resume() call chain. Do you see any problems with this approach? How will the system wakeup from retention or off-mode if the PRCM IRQ is disabled? Besides that, I don't like this approach because it leaves a rather long window during which no PRCM-triggered wakeup events can happen. This is not good since we also want potential wakeup events that happen *during* system suspend to be able to cancel the suspend. > The only issue I am seeing myself is if some driver decides to do > resume() in the complete() pm-op and potentially screwing the ordering > here... Personally, I think Alan's approach is the only scalable approach. This has to be handled by the drivers. If the driver's ISR does a pm_runtime_get_sync() and it fails (in this case, with -EACCESS since runtime PM is disabled), the driver should handle that handle as Alan described above. Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-27 14:49 ` Santosh 2011-08-27 19:42 ` Alan Stern @ 2011-08-27 19:42 ` Alan Stern 1 sibling, 0 replies; 21+ messages in thread From: Alan Stern @ 2011-08-27 19:42 UTC (permalink / raw) To: Santosh Cc: Tero Kristo, Felipe Balbi, Partha Basak, Govindraj.R, Keshava Munegowda, linux-pm, linux-omap On Sat, 27 Aug 2011, Santosh wrote: > On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: > > On Sat, 27 Aug 2011, Santosh wrote: > > > >> I might be wrong here, but after discussion with Govindraj on this > >> issue, it seems there is a flaw in the way OMAP chain handler > >> handling the child interrupts. > >> > >> On OMAP, we have special interrupt wakeup source at PRCM level and > >> many devices can trigger wakeup from low power via this common > >> interrupt source. The common interrupt source upon wakeup from low > >> power state, decodes the source of interrupt and based on that > >> source, calls the respective device ISR directly. > >> > >> The issue I see here is, the ISR on _a_ device (UART in this case) > >> is happening even before UART resume and DPM resume has been completed. > >> If this is the case, then it is surely asking for trouble. Because not > >> just clocks, but even driver state machine is already in suspend state > >> when the ISR is called. > > > > If the driver state machine is in the suspend state when the ISR is > > called, then the ISR should realize it is handling a wakeup event > > instead of a normal I/O event. All it needs to do is turn off the > > interrupt source; the event itself will be taken care of during the > > device's resume callback. > > > Good point but the ISR is called as a function call and not real > hardware event so no need to turn-off the source in the child > ISR. Parent ISR will clear the source anyways. > > But the intention here is to record the event for the child. In that case the ISR only has to record the event. > I mean for UART wakeup, the received character should be > extracted. If not done, UART will loose that character because > the event is lost. So not sure how the event will be taken > care during resume callback. Could you elaborate bit more on > last comment please? The resume callback routine must check to see if an event was recorded. If one was, the routine must see whether a character was received while the system was asleep and extract the character from the UART. (It probably won't hurt to do this even if an event wasn't recorded.) Alan Stern ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-27 14:01 ` Alan Stern 2011-08-27 14:49 ` Santosh @ 2011-08-27 14:49 ` Santosh 1 sibling, 0 replies; 21+ messages in thread From: Santosh @ 2011-08-27 14:49 UTC (permalink / raw) To: Alan Stern Cc: Tero Kristo, Felipe Balbi, Partha Basak, Govindraj.R, Keshava Munegowda, linux-pm, linux-omap On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: > On Sat, 27 Aug 2011, Santosh wrote: > >> I might be wrong here, but after discussion with Govindraj on this >> issue, it seems there is a flaw in the way OMAP chain handler >> handling the child interrupts. >> >> On OMAP, we have special interrupt wakeup source at PRCM level and >> many devices can trigger wakeup from low power via this common >> interrupt source. The common interrupt source upon wakeup from low >> power state, decodes the source of interrupt and based on that >> source, calls the respective device ISR directly. >> >> The issue I see here is, the ISR on _a_ device (UART in this case) >> is happening even before UART resume and DPM resume has been completed. >> If this is the case, then it is surely asking for trouble. Because not >> just clocks, but even driver state machine is already in suspend state >> when the ISR is called. > > If the driver state machine is in the suspend state when the ISR is > called, then the ISR should realize it is handling a wakeup event > instead of a normal I/O event. All it needs to do is turn off the > interrupt source; the event itself will be taken care of during the > device's resume callback. > Good point but the ISR is called as a function call and not real hardware event so no need to turn-off the source in the child ISR. Parent ISR will clear the source anyways. But the intention here is to record the event for the child. I mean for UART wakeup, the received character should be extracted. If not done, UART will loose that character because the event is lost. So not sure how the event will be taken care during resume callback. Could you elaborate bit more on last comment please? Regards Santosh ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-27 6:30 ` [linux-pm] " Santosh 2011-08-27 14:01 ` Alan Stern @ 2011-08-27 14:01 ` Alan Stern 1 sibling, 0 replies; 21+ messages in thread From: Alan Stern @ 2011-08-27 14:01 UTC (permalink / raw) To: Santosh Cc: Tero Kristo, Felipe Balbi, Partha Basak, Govindraj.R, Keshava Munegowda, linux-pm, linux-omap On Sat, 27 Aug 2011, Santosh wrote: > I might be wrong here, but after discussion with Govindraj on this > issue, it seems there is a flaw in the way OMAP chain handler > handling the child interrupts. > > On OMAP, we have special interrupt wakeup source at PRCM level and > many devices can trigger wakeup from low power via this common > interrupt source. The common interrupt source upon wakeup from low > power state, decodes the source of interrupt and based on that > source, calls the respective device ISR directly. > > The issue I see here is, the ISR on _a_ device (UART in this case) > is happening even before UART resume and DPM resume has been completed. > If this is the case, then it is surely asking for trouble. Because not > just clocks, but even driver state machine is already in suspend state > when the ISR is called. If the driver state machine is in the suspend state when the ISR is called, then the ISR should realize it is handling a wakeup event instead of a normal I/O event. All it needs to do is turn off the interrupt source; the event itself will be taken care of during the device's resume callback. Alan Stern ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-26 13:01 Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend Govindraj.R 2011-08-26 18:36 ` [linux-pm] " Alan Stern @ 2011-08-26 18:36 ` Alan Stern 2011-08-26 20:52 ` Rafael J. Wysocki 2011-08-26 20:52 ` Rafael J. Wysocki 3 siblings, 0 replies; 21+ messages in thread From: Alan Stern @ 2011-08-26 18:36 UTC (permalink / raw) To: Govindraj.R Cc: Partha Basak, Tero Kristo, Felipe Balbi, Keshava Munegowda, linux-pm, linux-omap On Fri, 26 Aug 2011, Govindraj.R wrote: > Hello, > > During system_wide_suspend pm runtime is disabled. > I.e. __pm_runtime_disable is called from __device_suspend. > Now, if a wakeup interrupt is triggered and the wakeup device irq handler > is called even before device_resume and pm_runtime_enable happens, > the device irq_handler proceeds to enable clock with runtime API to > handle wakeup event. > > Wouldn't this result in system wide abort since the pm_runtime is not enabled > yet from dpm_resume? > As we end up accessing regs after doing runtime get_sync. > > Looks like this scenario is not handled currently. > Or Am I missing something here? I don't have the complete picture, but it seems that the IRQ handler needs to check the return code from pm_runtime_get_sync(). If the call fails then the handler shouldn't try to access the device registers. In the case of a genuine wakeup event, the event should be handled later on as part of the resume or resume_noirq processing. However, this does raise a potential problem. What happens if the clocks are needed in order to turn off the IRQ source? Runtime PM won't allow the clocks to be enabled until after interrupts have been enabled, and by then it will be too late -- the source will have caused an interrupt storm. Alan Stern ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-26 13:01 Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend Govindraj.R 2011-08-26 18:36 ` [linux-pm] " Alan Stern 2011-08-26 18:36 ` Alan Stern @ 2011-08-26 20:52 ` Rafael J. Wysocki 2011-08-26 20:52 ` Rafael J. Wysocki 3 siblings, 0 replies; 21+ messages in thread From: Rafael J. Wysocki @ 2011-08-26 20:52 UTC (permalink / raw) To: Govindraj.R Cc: Paul Walmsley, Kevin Hilman, linux-omap, linux-pm, Vishwanath Sripathy, Partha Basak, Felipe Balbi, Santosh Shilimkar, Rajendra Nayak, Benoit Cousson, Tero Kristo, Keshava Munegowda On Friday, August 26, 2011, Govindraj.R wrote: > Hello, > > During system_wide_suspend pm runtime is disabled. > I.e. __pm_runtime_disable is called from __device_suspend. > Now, if a wakeup interrupt is triggered and the wakeup device irq handler > is called even before device_resume and pm_runtime_enable happens, > the device irq_handler proceeds to enable clock with runtime API to > handle wakeup event. > > Wouldn't this result in system wide abort since the pm_runtime is not enabled > yet from dpm_resume? > As we end up accessing regs after doing runtime get_sync. > > Looks like this scenario is not handled currently. > Or Am I missing something here? To be precise, what do you mean by "wakeup interrupt"? Rafael ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend. 2011-08-26 13:01 Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend Govindraj.R ` (2 preceding siblings ...) 2011-08-26 20:52 ` Rafael J. Wysocki @ 2011-08-26 20:52 ` Rafael J. Wysocki 3 siblings, 0 replies; 21+ messages in thread From: Rafael J. Wysocki @ 2011-08-26 20:52 UTC (permalink / raw) To: Govindraj.R Cc: Tero Kristo, Felipe Balbi, Partha Basak, Keshava Munegowda, linux-pm, linux-omap On Friday, August 26, 2011, Govindraj.R wrote: > Hello, > > During system_wide_suspend pm runtime is disabled. > I.e. __pm_runtime_disable is called from __device_suspend. > Now, if a wakeup interrupt is triggered and the wakeup device irq handler > is called even before device_resume and pm_runtime_enable happens, > the device irq_handler proceeds to enable clock with runtime API to > handle wakeup event. > > Wouldn't this result in system wide abort since the pm_runtime is not enabled > yet from dpm_resume? > As we end up accessing regs after doing runtime get_sync. > > Looks like this scenario is not handled currently. > Or Am I missing something here? To be precise, what do you mean by "wakeup interrupt"? Rafael ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2011-09-08 13:51 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-26 13:01 Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend Govindraj.R 2011-08-26 18:36 ` [linux-pm] " Alan Stern 2011-08-27 6:30 ` Santosh 2011-08-27 6:30 ` [linux-pm] " Santosh 2011-08-27 14:01 ` Alan Stern 2011-08-27 14:49 ` Santosh 2011-08-27 19:42 ` Alan Stern 2011-09-07 15:48 ` Tero Kristo 2011-09-07 15:48 ` [linux-pm] " Tero Kristo 2011-09-07 17:59 ` Kevin Hilman 2011-09-08 4:58 ` Tero Kristo 2011-09-08 4:58 ` [linux-pm] " Tero Kristo 2011-09-08 13:51 ` Kevin Hilman 2011-09-08 13:51 ` Kevin Hilman 2011-09-07 17:59 ` Kevin Hilman 2011-08-27 19:42 ` Alan Stern 2011-08-27 14:49 ` Santosh 2011-08-27 14:01 ` Alan Stern 2011-08-26 18:36 ` Alan Stern 2011-08-26 20:52 ` Rafael J. Wysocki 2011-08-26 20:52 ` Rafael J. Wysocki
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.