RE: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
> From: Shilimkar, Santosh > Sent: Thursday, September 15, 2011 7:02 AM > >> You missed my point in the description. Clockdomain inactive > >> doesn't depend on idle or WFI execution. Under HW supervison > >> CPU clock domain can get into inactive when CPU is stalled and > >> waiting for a read response from slow interconnect. My understanding is MPSS global clock domain can not gate unless each cpu is in wfi and other conditions are met. Other conditions are a wugen ack that there are no irqs and ocp-bridge logic giving its ok. What kind of local clock gating is there per cpu or sub-clock domains is not as clear. The mpu's pivot on individual wfi while other blocks in mpuss have other considerations. The spec is very clear about coherent programmation of wugen and gic. Like being discussed. Its examples are about how wugen used I've heard about are around transition in and out of standbys at wfi. Wugen will process all irqs before giving ack to sleep, it also has ability to fail sleep if new irqs come in before final idle. * It may be possible depending on clarifications to handle near wfi, but you might have to do it for -every- cpu's wfi unless you can coordinate who the last one is. Doing it as you go with gic would avoid redoing work over and over at the many wfi calls. This extra work costs in latency and power. Doing housekeeping along with gic seems better from a run time perspective. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Thu, Sep 15, 2011 at 3:06 PM, Cousson, Benoit wrote: > Hi Santosh, > > On 9/14/2011 7:22 PM, Shilimkar, Santosh wrote: >> >> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote: >>> >>> * Santosh [110914 09:40]: On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: > > * Santosh [110914 09:16]: > > Thanks for the clarification. It seems to me the spec is most likely > wrong as we've had the GIC working for over two years now without > doing anything with the wakeup gen registers :) > It's working because CPU clockdomain are never put under HW supervised mode and they are kept in force wakeup. Clock-domain never idles on mainline code. PM series will put the clock-domains under HW supervison as needed to achieve any low power states and then all sorts of corner cases will come out. >>> >>> But again the wakeup gen triggers only do something when hitting >>> idle. There should be no use for them during runtime, right? >>> >> You missed my point in the description. Clockdomain inactive >> doesn't depend on idle or WFI execution. Under HW supervison >> CPU clock domain can get into inactive when CPU is stalled and >> waiting for a read response from slow interconnect. > > I'm a little bit confused by that statement... > > I'm wondering how the PRCM can gate the CPU/MPU clock and re-enable it if > the MPU is gated? What kind of event can wakeup the CPU in case of CPU > stalled? > > The spec seems to indicate that wakeupgen is needed only if CPU are in WFI. > It is even written: "CPUx will change power state only when StandbyWFI is > asserted.". Even a WFE is not supposed to trigger a standby. > How can the CPU be inactive at clock domain level without a WFI? > I mean only CPU clock domain and not the power domain inactive and local CPU clock can be gated without WFI when clock domain is kept under hardware supervision. But I agree with you that, for the stalled case, wakeupgen can't generate any event and it will LPRM state-machine which take care of un-gating the clock for that local CPU. I have been discussing today morning with design IP team on the restriction in the functional specs and they said they will check and comeback. For now, I would like to go with what specs says. By next merge window, am sure we will be clear inputs from IP team on this and if it happens that the requirement needs to be changed and we need not do mask/unmask in non-low power scenario, we can start looking at other aspects as Tony suggested. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
Hi Santosh, On 9/14/2011 7:22 PM, Shilimkar, Santosh wrote: On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote: * Santosh [110914 09:40]: On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: * Santosh[110914 09:16]: Thanks for the clarification. It seems to me the spec is most likely wrong as we've had the GIC working for over two years now without doing anything with the wakeup gen registers :) It's working because CPU clockdomain are never put under HW supervised mode and they are kept in force wakeup. Clock-domain never idles on mainline code. PM series will put the clock-domains under HW supervison as needed to achieve any low power states and then all sorts of corner cases will come out. But again the wakeup gen triggers only do something when hitting idle. There should be no use for them during runtime, right? You missed my point in the description. Clockdomain inactive doesn't depend on idle or WFI execution. Under HW supervison CPU clock domain can get into inactive when CPU is stalled and waiting for a read response from slow interconnect. I'm a little bit confused by that statement... I'm wondering how the PRCM can gate the CPU/MPU clock and re-enable it if the MPU is gated? What kind of event can wakeup the CPU in case of CPU stalled? The spec seems to indicate that wakeupgen is needed only if CPU are in WFI. It is even written: "CPUx will change power state only when StandbyWFI is asserted.". Even a WFE is not supposed to trigger a standby. How can the CPU be inactive at clock domain level without a WFI? Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Thursday 15 September 2011 12:34 AM, Tony Lindgren wrote: > * Santosh [110914 09:49]: >> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote: >>> * Santosh [110914 09:40]: On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: > * Santosh [110914 09:16]: > > Thanks for the clarification. It seems to me the spec is most likely > wrong as we've had the GIC working for over two years now without > doing anything with the wakeup gen registers :) > It's working because CPU clockdomain are never put under HW supervised mode and they are kept in force wakeup. Clock-domain never idles on mainline code. PM series will put the clock-domains under HW supervison as needed to achieve any low power states and then all sorts of corner cases will come out. >>> >>> But again the wakeup gen triggers only do something when hitting >>> idle. There should be no use for them during runtime, right? >>> >> You missed my point in the description. Clockdomain inactive >> doesn't depend on idle or WFI execution. Under HW supervison >> CPU clock domain can get into inactive when CPU is stalled and >> waiting for a read response from slow interconnect. > > Ah OK. If it's needed during runtime too then that explains why > the registers need to be kept in sync. > >> One thing for sure. Designers has chosen a wrong name to this >> IP. Wakeugen apears like needed only for low power wakeup which >> not seems to be entirely correct as per specs > > Yes it's not obvious reading the TRM either. Maybe add some > comment about that to the patch? > You are right. Documentation isn't clear about this. Will add the above point in change log. btw, thanks for the good discussion on this topic. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
* Santosh [110914 09:49]: > On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote: > >* Santosh [110914 09:40]: > >>On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: > >>>* Santosh [110914 09:16]: > >>> > >>>Thanks for the clarification. It seems to me the spec is most likely > >>>wrong as we've had the GIC working for over two years now without > >>>doing anything with the wakeup gen registers :) > >>> > >>It's working because CPU clockdomain are never put under HW > >>supervised mode and they are kept in force wakeup. Clock-domain > >>never idles on mainline code. PM series will put the clock-domains > >>under HW supervison as needed to achieve any low power states and > >>then all sorts of corner cases will come out. > > > >But again the wakeup gen triggers only do something when hitting > >idle. There should be no use for them during runtime, right? > > > You missed my point in the description. Clockdomain inactive > doesn't depend on idle or WFI execution. Under HW supervison > CPU clock domain can get into inactive when CPU is stalled and > waiting for a read response from slow interconnect. Ah OK. If it's needed during runtime too then that explains why the registers need to be kept in sync. > One thing for sure. Designers has chosen a wrong name to this > IP. Wakeugen apears like needed only for low power wakeup which > not seems to be entirely correct as per specs Yes it's not obvious reading the TRM either. Maybe add some comment about that to the patch? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote: * Santosh [110914 09:40]: On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: * Santosh [110914 09:16]: Thanks for the clarification. It seems to me the spec is most likely wrong as we've had the GIC working for over two years now without doing anything with the wakeup gen registers :) It's working because CPU clockdomain are never put under HW supervised mode and they are kept in force wakeup. Clock-domain never idles on mainline code. PM series will put the clock-domains under HW supervison as needed to achieve any low power states and then all sorts of corner cases will come out. But again the wakeup gen triggers only do something when hitting idle. There should be no use for them during runtime, right? You missed my point in the description. Clockdomain inactive doesn't depend on idle or WFI execution. Under HW supervison CPU clock domain can get into inactive when CPU is stalled and waiting for a read response from slow interconnect. One thing for sure. Designers has chosen a wrong name to this IP. Wakeugen apears like needed only for low power wakeup which not seems to be entirely correct as per specs Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote: * Santosh [110914 09:40]: On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: * Santosh [110914 09:16]: Thanks for the clarification. It seems to me the spec is most likely wrong as we've had the GIC working for over two years now without doing anything with the wakeup gen registers :) It's working because CPU clockdomain are never put under HW supervised mode and they are kept in force wakeup. Clock-domain never idles on mainline code. PM series will put the clock-domains under HW supervison as needed to achieve any low power states and then all sorts of corner cases will come out. But again the wakeup gen triggers only do something when hitting idle. There should be no use for them during runtime, right? You missed my point in the description. Clockdomain inactive doesn't depend on idle or WFI execution. Under HW supervison CPU clock domain can get into inactive when CPU is stalled and waiting for a read response from slow interconnect. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
* Santosh [110914 09:40]: > On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: > >* Santosh [110914 09:16]: > > > >Thanks for the clarification. It seems to me the spec is most likely > >wrong as we've had the GIC working for over two years now without > >doing anything with the wakeup gen registers :) > > > It's working because CPU clockdomain are never put under HW > supervised mode and they are kept in force wakeup. Clock-domain > never idles on mainline code. PM series will put the clock-domains > under HW supervison as needed to achieve any low power states and > then all sorts of corner cases will come out. But again the wakeup gen triggers only do something when hitting idle. There should be no use for them during runtime, right? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: * Santosh [110914 09:16]: First and foremost, I have to go with the approach here because MPUSS hardware team put a requirement that GIC and wakeupgen should always be kept in sync. If needed we can discuss this off-the list with Richard. Below is the extract from the veyron func specs. - Version 1.6 of veyron spec has this. From page 95, paragraph 2 on version 1.6: "It is SW responsibility to program interrupt enabling/disabling coherently in the GIC and in the Wugen enable registers. That is, a given interrupt for a given CPU is either enable at both GIC and Wugen, or disable at both, but no mix." - The way understand this IP is, even in normal scenario's every IRQ will come to wakeupgen and then it will pass that to GIC. CPU clock domains are kept under HW supervised always and they can enter inactive any time without WFI. Only wakeup gen can bring the CPU out of inactive state. That's requirement really lead to this design choice. Just to add all ARM SOC's using GIC has a gic extension interrupt controller and follow the same approach for the secondary IRQCHIPO. Thanks for the clarification. It seems to me the spec is most likely wrong as we've had the GIC working for over two years now without doing anything with the wakeup gen registers :) It's working because CPU clockdomain are never put under HW supervised mode and they are kept in force wakeup. Clock-domain never idles on mainline code. PM series will put the clock-domains under HW supervison as needed to achieve any low power states and then all sorts of corner cases will come out. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
* Santosh [110914 09:16]: > > First and foremost, I have to go with the approach here because MPUSS > hardware team put a requirement that GIC and wakeupgen should always be > kept in sync. If needed we can discuss this off-the list with Richard. > > Below is the extract from the veyron func specs. > - > Version 1.6 of veyron spec has this. > > From page 95, paragraph 2 on version 1.6: > > "It is SW responsibility to program interrupt enabling/disabling > coherently in the GIC and in the Wugen enable registers. That is, a > given interrupt for a given CPU is either enable at both GIC and Wugen, > or disable at both, but no mix." > - > > The way understand this IP is, even in normal scenario's every IRQ > will come to wakeupgen and then it will pass that to GIC. CPU clock > domains are kept under HW supervised always and they can enter inactive > any time without WFI. Only wakeup gen can bring the CPU out of inactive > state. > > That's requirement really lead to this design choice. Just to add > all ARM SOC's using GIC has a gic extension interrupt controller and > follow the same approach for the secondary IRQCHIPO. Thanks for the clarification. It seems to me the spec is most likely wrong as we've had the GIC working for over two years now without doing anything with the wakeup gen registers :) Of course the wakeup events probably don't work currently, but the GIC interrupts certainly do. So most likely there's no need to continuously syncronize the wakeup gen registers with the GIC registers. > Below points as such don't matter after the strict hardware > requirement. Still . I think the issue is that you're assuming the spec is correct, which does not seem to be the case here. > Let's say, we ignore the hardware recommendation and try > to do what you are suggesting. > > How will you know while entering in idle which IRQ's to be > masked and which are to be unmasked ? > The only way is to run though entire 1024 possible IRQ's from GIC > and then check the state of each IRQ and set things accordingly. > At GIC level, mask and unmask registers are different so you will > end up reading those many registers. That also means you need to > export some non-standard APIs from GIC driver. When entering idle, we have plenty of time to do that. Sounds like that could be easily implemented in a generic way. > In system wide suspend, the core irq code, communicates > the wakeup and non-wakeup functionality using standard mask/ > unmask APIs when used with IRQCHIP_MASK_ON_SUSPEND. > With what you are suggesting it won't work > as desired. Because that information is only passed > to the IRQ chips. So you will still need IRQCHIP and > mask/unmask APIs. That can be done as part of set_wake() > handler as well though. > > The wakeupgen is within CPU cluster and the accesses > to it are not as expensive as like accessing 32 K timer or > GP timer. Sure, but it still causes unnecesary writes for every interrupt. There's no technical reason to do that. > By making the wakeupgen as an IRQCHIP, we meet the hardware > requirement and also make use of this IP properly for the > desired functionality using standard IRQCHIP interfaces > No need of non-standard hacking. Well it seems the "hardware requirement" is based on a buggy spec considering things are currently working. > It also avoid platform code monkeing with common GIC code > and irq subsystem to hack the stuff. What I'm suggesting can be implemented in a generic way. > Btw, not exactly related here, but because of common code > consolidation, we need to actually use GIC common > save/restore hooks, even though OMAP has very > optimal software save and hardware restore mechanism > for GIC. > > Hope this email summarise all previous multiple discussions > in one place. Thanks, but unfortunately it does not. To me it still seems this is the wrong approach for the wakeup triggers. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Wednesday 14 September 2011 08:51 PM, Tony Lindgren wrote: * Shilimkar, Santosh [110913 22:01]: Tony, On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgren wrote: * Santosh Shilimkar [110904 06:23]: OMAP WakeupGen is the interrupt controller extension used along with ARM GIC to wake the CPU out from low power states on external interrupts. The WakeupGen unit is responsible for generating wakeup event from the incoming interrupts and enable bits. It is implemented in MPU always ON power domain. During normal operation, WakeupGen delivers external interrupts directly to the GIC. ... + /* + * Override GIC architecture specific functions to add + * OMAP WakeupGen interrupt controller along with GIC + */ + gic_arch_extn.irq_mask = wakeupgen_mask; + gic_arch_extn.irq_unmask = wakeupgen_unmask; + gic_arch_extn.irq_set_wake = wakeupgen_set_wake; + gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND; As I've commented before, there should not be any need to tweak the wakeupgen registers for each interrupt during the runtime. And I gave you all the reasons why it needs to be done this way. Hmm, I don't think you ever answered the main question: Why would you need to write the wakeupgen registers for every interrupt during the runtime instead of arming them only when entering idle? I thought I did that in last thread. Let me try again, First and foremost, I have to go with the approach here because MPUSS hardware team put a requirement that GIC and wakeupgen should always be kept in sync. If needed we can discuss this off-the list with Richard. Below is the extract from the veyron func specs. - Version 1.6 of veyron spec has this. From page 95, paragraph 2 on version 1.6: "It is SW responsibility to program interrupt enabling/disabling coherently in the GIC and in the Wugen enable registers. That is, a given interrupt for a given CPU is either enable at both GIC and Wugen, or disable at both, but no mix." - The way understand this IP is, even in normal scenario's every IRQ will come to wakeupgen and then it will pass that to GIC. CPU clock domains are kept under HW supervised always and they can enter inactive any time without WFI. Only wakeup gen can bring the CPU out of inactive state. That's requirement really lead to this design choice. Just to add all ARM SOC's using GIC has a gic extension interrupt controller and follow the same approach for the secondary IRQCHIPO. Below points as such don't matter after the strict hardware requirement. Still . Let's say, we ignore the hardware recommendation and try to do what you are suggesting. How will you know while entering in idle which IRQ's to be masked and which are to be unmasked ? The only way is to run though entire 1024 possible IRQ's from GIC and then check the state of each IRQ and set things accordingly. At GIC level, mask and unmask registers are different so you will end up reading those many registers. That also means you need to export some non-standard APIs from GIC driver. In system wide suspend, the core irq code, communicates the wakeup and non-wakeup functionality using standard mask/ unmask APIs when used with IRQCHIP_MASK_ON_SUSPEND. With what you are suggesting it won't work as desired. Because that information is only passed to the IRQ chips. So you will still need IRQCHIP and mask/unmask APIs. That can be done as part of set_wake() handler as well though. The wakeupgen is within CPU cluster and the accesses to it are not as expensive as like accessing 32 K timer or GP timer. By making the wakeupgen as an IRQCHIP, we meet the hardware requirement and also make use of this IP properly for the desired functionality using standard IRQCHIP interfaces No need of non-standard hacking. It also avoid platform code monkeing with common GIC code and irq subsystem to hack the stuff. Btw, not exactly related here, but because of common code consolidation, we need to actually use GIC common save/restore hooks, even though OMAP has very optimal software save and hardware restore mechanism for GIC. Hope this email summarise all previous multiple discussions in one place. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
* Shilimkar, Santosh [110913 22:01]: > Tony, > On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgren wrote: > > * Santosh Shilimkar [110904 06:23]: > >> OMAP WakeupGen is the interrupt controller extension used along > >> with ARM GIC to wake the CPU out from low power states on > >> external interrupts. > >> > >> The WakeupGen unit is responsible for generating wakeup event > >> from the incoming interrupts and enable bits. It is implemented > >> in MPU always ON power domain. During normal operation, > >> WakeupGen delivers external interrupts directly to the GIC. > > ... > > > >> + /* > >> + * Override GIC architecture specific functions to add > >> + * OMAP WakeupGen interrupt controller along with GIC > >> + */ > >> + gic_arch_extn.irq_mask = wakeupgen_mask; > >> + gic_arch_extn.irq_unmask = wakeupgen_unmask; > >> + gic_arch_extn.irq_set_wake = wakeupgen_set_wake; > >> + gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND; > > > > As I've commented before, there should not be any need to tweak > > the wakeupgen registers for each interrupt during the runtime. > > > And I gave you all the reasons why it needs to be done this way. Hmm, I don't think you ever answered the main question: Why would you need to write the wakeupgen registers for every interrupt during the runtime instead of arming them only when entering idle? > > AFAIK the wakeupgen registers only need to be armed every time > > before entering idle. > > > No that doesn't work and it completely hacky approach. And how is writing the registers over and over again unnecessarily a non-hacky approach? > This problem is for all SOC's using A9 SMP and GIC and every soc > has an architecture specific interrupt controller extension. And that > was the reason the GIC arch_extn was proposed. > It's just another IRQCHIP and works seamlessly being part of the > framework. And it will also initialized with primary IRQCHIP( GIC). Sure, but I don't know if there is really a need for for that? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
Tony, On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgren wrote: > * Santosh Shilimkar [110904 06:23]: >> OMAP WakeupGen is the interrupt controller extension used along >> with ARM GIC to wake the CPU out from low power states on >> external interrupts. >> >> The WakeupGen unit is responsible for generating wakeup event >> from the incoming interrupts and enable bits. It is implemented >> in MPU always ON power domain. During normal operation, >> WakeupGen delivers external interrupts directly to the GIC. > ... > >> + /* >> + * Override GIC architecture specific functions to add >> + * OMAP WakeupGen interrupt controller along with GIC >> + */ >> + gic_arch_extn.irq_mask = wakeupgen_mask; >> + gic_arch_extn.irq_unmask = wakeupgen_unmask; >> + gic_arch_extn.irq_set_wake = wakeupgen_set_wake; >> + gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND; > > As I've commented before, there should not be any need to tweak > the wakeupgen registers for each interrupt during the runtime. > And I gave you all the reasons why it needs to be done this way. > AFAIK the wakeupgen registers only need to be armed every time > before entering idle. > No that doesn't work and it completely hacky approach. This problem is for all SOC's using A9 SMP and GIC and every soc has an architecture specific interrupt controller extension. And that was the reason the GIC arch_extn was proposed. It's just another IRQCHIP and works seamlessly being part of the framework. And it will also initialized with primary IRQCHIP( GIC). Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
* Santosh Shilimkar [110904 06:23]: > OMAP WakeupGen is the interrupt controller extension used along > with ARM GIC to wake the CPU out from low power states on > external interrupts. > > The WakeupGen unit is responsible for generating wakeup event > from the incoming interrupts and enable bits. It is implemented > in MPU always ON power domain. During normal operation, > WakeupGen delivers external interrupts directly to the GIC. ... > + /* > + * Override GIC architecture specific functions to add > + * OMAP WakeupGen interrupt controller along with GIC > + */ > + gic_arch_extn.irq_mask = wakeupgen_mask; > + gic_arch_extn.irq_unmask = wakeupgen_unmask; > + gic_arch_extn.irq_set_wake = wakeupgen_set_wake; > + gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND; As I've commented before, there should not be any need to tweak the wakeupgen registers for each interrupt during the runtime. AFAIK the wakeupgen registers only need to be armed every time before entering idle. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Monday 12 September 2011 01:26 PM, Thomas Gleixner wrote: On Fri, 9 Sep 2011, Santosh wrote: [..] From d63d4347dc8fb144b19f4d4e7c0621397cccea94 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar Date: Fri, 9 Sep 2011 13:59:35 +0530 Subject: [PATCH] irq: Add IRQCHIP_SKIP_SET_WAKE flag to avoid need of dummy set_wake() handler. Certain IRQCHIP's may not need to install the irq_set_wake() handler if the IRQCHIP_MASK_ON_SUSPEND flag is set. But but if it's not implemented, enable_irq_wake() will return an error. That needs the IRQCHIP to install an empty set_wake handler. Add an 'IRQCHIP_SKIP_SET_WAKE' flag so that IRQCHIP can inform the core irq code that irq_set_wake() handler is not necessary. Signed-off-by: Santosh Shilimkar Cc: Thomas Gleixner Queued to irq/core for 3.2 Thanks a lot Thomas. Will update OMAP PM code based on above change. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Fri, 9 Sep 2011, Santosh wrote:
> On Friday 09 September 2011 01:48 PM, Thomas Gleixner wrote:
> > On Fri, 9 Sep 2011, Santosh wrote:
> > > On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
> > > >
> > > > The flag says: MASK ON SUSPEND and it does not imply that you don't
> > > > need a wake function. There might be cases where you want to setup
> > > > stuff in that function in order to have the wakeup happen on that
> > > > interrupt line despite of the mask on suspend.
> > > >
> > > I see your point.
> > >
> > > > We either need a separate flag or a global dummy set_wake function in
> > > > the core to avoid empty copies all over the place.
> > > >
> > > A flag is probably better since you mentioned that on some arch, there
> > > might be need to have actual set_wake() handler. Or if the global
> > > dummy can be over-ridden by platform, that's fine too.
> >
> > Global dummy would mean:
> >
> > int irq_set_wake_dummy(...)
> > {
> > return 0;
> > }
> >
> > And you just add it to your chip, but either way I don't care whether
> > it's a dummy function or a flag.
> >
> Will below patch work for you then ?
> Attaching the same in case mailer damages it.
It does :)
> Regards,
> Santosh
>
> From d63d4347dc8fb144b19f4d4e7c0621397cccea94 Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar
> Date: Fri, 9 Sep 2011 13:59:35 +0530
> Subject: [PATCH] irq: Add IRQCHIP_SKIP_SET_WAKE flag to avoid need of dummy
> set_wake() handler.
>
> Certain IRQCHIP's may not need to install the irq_set_wake() handler if
> the IRQCHIP_MASK_ON_SUSPEND flag is set. But but if it's not implemented,
> enable_irq_wake() will return an error. That needs the IRQCHIP to install
> an empty set_wake handler.
>
> Add an 'IRQCHIP_SKIP_SET_WAKE' flag so that IRQCHIP can inform the core
> irq code that irq_set_wake() handler is not necessary.
>
> Signed-off-by: Santosh Shilimkar
> Cc: Thomas Gleixner
Queued to irq/core for 3.2
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Friday 09 September 2011 01:48 PM, Thomas Gleixner wrote:
On Fri, 9 Sep 2011, Santosh wrote:
On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
The flag says: MASK ON SUSPEND and it does not imply that you don't
need a wake function. There might be cases where you want to setup
stuff in that function in order to have the wakeup happen on that
interrupt line despite of the mask on suspend.
I see your point.
We either need a separate flag or a global dummy set_wake function in
the core to avoid empty copies all over the place.
A flag is probably better since you mentioned that on some arch, there
might be need to have actual set_wake() handler. Or if the global
dummy can be over-ridden by platform, that's fine too.
Global dummy would mean:
int irq_set_wake_dummy(...)
{
return 0;
}
And you just add it to your chip, but either way I don't care whether
it's a dummy function or a flag.
Will below patch work for you then ?
Attaching the same in case mailer damages it.
Regards,
Santosh
From d63d4347dc8fb144b19f4d4e7c0621397cccea94 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Fri, 9 Sep 2011 13:59:35 +0530
Subject: [PATCH] irq: Add IRQCHIP_SKIP_SET_WAKE flag to avoid need of
dummy set_wake() handler.
Certain IRQCHIP's may not need to install the irq_set_wake() handler if
the IRQCHIP_MASK_ON_SUSPEND flag is set. But but if it's not implemented,
enable_irq_wake() will return an error. That needs the IRQCHIP to install
an empty set_wake handler.
Add an 'IRQCHIP_SKIP_SET_WAKE' flag so that IRQCHIP can inform the core
irq code that irq_set_wake() handler is not necessary.
Signed-off-by: Santosh Shilimkar
Cc: Thomas Gleixner
---
include/linux/irq.h |2 ++
kernel/irq/manage.c |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 5951730..4b0d842 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -336,12 +336,14 @@ struct irq_chip {
* IRQCHIP_MASK_ON_SUSPEND:Mask non wake irqs in the suspend path
* IRQCHIP_ONOFFLINE_ENABLED: Only call irq_on/off_line callbacks
* when irq enabled
+ * IRQCHIP_SKIP_SET_WAKE: Skip chip.irq_set_wake(), for this IRQCHIP
*/
enum {
IRQCHIP_SET_TYPE_MASKED = (1 << 0),
IRQCHIP_EOI_IF_HANDLED = (1 << 1),
IRQCHIP_MASK_ON_SUSPEND = (1 << 2),
IRQCHIP_ONOFFLINE_ENABLED = (1 << 3),
+ IRQCHIP_SKIP_SET_WAKE = (1 << 4),
};
/* This include will go away once we isolated irq_desc usage to core
code */
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 9b956fa..7e1a3ed 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq,
unsigned int on)
struct irq_desc *desc = irq_to_desc(irq);
int ret = -ENXIO;
+ if (irq_desc_get_chip(desc)->flags & IRQCHIP_SKIP_SET_WAKE)
+ return 0;
+
if (desc->irq_data.chip->irq_set_wake)
ret = desc->irq_data.chip->irq_set_wake(&desc->irq_data, on);
--
1.7.4.1
>From d63d4347dc8fb144b19f4d4e7c0621397cccea94 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Fri, 9 Sep 2011 13:59:35 +0530
Subject: [PATCH] irq: Add IRQCHIP_SKIP_SET_WAKE flag to avoid need of dummy set_wake() handler.
Certain IRQCHIP's may not need to install the irq_set_wake() handler if
the IRQCHIP_MASK_ON_SUSPEND flag is set. But but if it's not implemented,
enable_irq_wake() will return an error. That needs the IRQCHIP to install
an empty set_wake handler.
Add an 'IRQCHIP_SKIP_SET_WAKE' flag so that IRQCHIP can inform the core
irq code that irq_set_wake() handler is not necessary.
Signed-off-by: Santosh Shilimkar
Cc: Thomas Gleixner
---
include/linux/irq.h |2 ++
kernel/irq/manage.c |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 5951730..4b0d842 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -336,12 +336,14 @@ struct irq_chip {
* IRQCHIP_MASK_ON_SUSPEND: Mask non wake irqs in the suspend path
* IRQCHIP_ONOFFLINE_ENABLED: Only call irq_on/off_line callbacks
*when irq enabled
+ * IRQCHIP_SKIP_SET_WAKE: Skip chip.irq_set_wake(), for this IRQCHIP
*/
enum {
IRQCHIP_SET_TYPE_MASKED = (1 << 0),
IRQCHIP_EOI_IF_HANDLED = (1 << 1),
IRQCHIP_MASK_ON_SUSPEND = (1 << 2),
IRQCHIP_ONOFFLINE_ENABLED = (1 << 3),
+ IRQCHIP_SKIP_SET_WAKE = (1 << 4),
};
/* This include will go away once we isolated irq_desc usage to core code */
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 9b956fa..7e1a3ed 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq, unsigned int on)
struct irq_desc *desc = irq_to_desc(irq);
int ret = -ENXIO;
+ if (irq_desc_get_chip(desc)->flags & IRQCHIP_SKIP_SET_WAKE)
+ return 0;
+
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Fri, 9 Sep 2011, Santosh wrote:
> On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
> >
> > The flag says: MASK ON SUSPEND and it does not imply that you don't
> > need a wake function. There might be cases where you want to setup
> > stuff in that function in order to have the wakeup happen on that
> > interrupt line despite of the mask on suspend.
> >
> I see your point.
>
> > We either need a separate flag or a global dummy set_wake function in
> > the core to avoid empty copies all over the place.
> >
> A flag is probably better since you mentioned that on some arch, there
> might be need to have actual set_wake() handler. Or if the global
> dummy can be over-ridden by platform, that's fine too.
Global dummy would mean:
int irq_set_wake_dummy(...)
{
return 0;
}
And you just add it to your chip, but either way I don't care whether
it's a dummy function or a flag.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote: On Fri, 9 Sep 2011, Santosh wrote: On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote: Santosh Shilimkar writes: OMAP WakeupGen is the interrupt controller extension used along with ARM GIC to wake the CPU out from low power states on external interrupts. The WakeupGen unit is responsible for generating wakeup event from the incoming interrupts and enable bits. It is implemented in MPU always ON power domain. During normal operation, WakeupGen delivers external interrupts directly to the GIC. Signed-off-by: Santosh Shilimkar Cc: Kevin Hilman [...] +#ifdef CONFIG_PM +/* + * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag, + * so no action is necessary in set_wake, but implement an empty handler + * here to prevent enable_irq_wake() returning an error. + * FIXME: Remove the dummy handler once gen irq code fix above. + */ Just curious... is there a fix for this pending for v3.2? I have sent a proposed change to Thomas but have not seen any response yet from him. http://www.spinics.net/lists/arm-kernel/msg134297.html diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 0a7840a..cd4bc01 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq, unsigned int on) struct irq_desc *desc = irq_to_desc(irq); int ret = -ENXIO; + if (irq_desc_get_chip(desc)->flags& IRQCHIP_MASK_ON_SUSPEND) + return 0; + if (desc->irq_data.chip->irq_set_wake) ret = desc->irq_data.chip->irq_set_wake(&desc->irq_data, on); The flag says: MASK ON SUSPEND and it does not imply that you don't need a wake function. There might be cases where you want to setup stuff in that function in order to have the wakeup happen on that interrupt line despite of the mask on suspend. I see your point. We either need a separate flag or a global dummy set_wake function in the core to avoid empty copies all over the place. A flag is probably better since you mentioned that on some arch, there might be need to have actual set_wake() handler. Or if the global dummy can be over-ridden by platform, that's fine too. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Fri, 9 Sep 2011, Santosh wrote: > On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote: > > Santosh Shilimkar writes: > > > > > OMAP WakeupGen is the interrupt controller extension used along > > > with ARM GIC to wake the CPU out from low power states on > > > external interrupts. > > > > > > The WakeupGen unit is responsible for generating wakeup event > > > from the incoming interrupts and enable bits. It is implemented > > > in MPU always ON power domain. During normal operation, > > > WakeupGen delivers external interrupts directly to the GIC. > > > > > > Signed-off-by: Santosh Shilimkar > > > Cc: Kevin Hilman > > > > [...] > > > > > +#ifdef CONFIG_PM > > > +/* > > > + * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag, > > > + * so no action is necessary in set_wake, but implement an empty handler > > > + * here to prevent enable_irq_wake() returning an error. > > > + * FIXME: Remove the dummy handler once gen irq code fix above. > > > + */ > > > > Just curious... is there a fix for this pending for v3.2? > > > I have sent a proposed change to Thomas but have not seen > any response yet from him. > > http://www.spinics.net/lists/arm-kernel/msg134297.html diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 0a7840a..cd4bc01 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq, unsigned int on) struct irq_desc *desc = irq_to_desc(irq); int ret = -ENXIO; + if (irq_desc_get_chip(desc)->flags & IRQCHIP_MASK_ON_SUSPEND) + return 0; + if (desc->irq_data.chip->irq_set_wake) ret = desc->irq_data.chip->irq_set_wake(&desc->irq_data, on); The flag says: MASK ON SUSPEND and it does not imply that you don't need a wake function. There might be cases where you want to setup stuff in that function in order to have the wakeup happen on that interrupt line despite of the mask on suspend. We either need a separate flag or a global dummy set_wake function in the core to avoid empty copies all over the place. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote: Santosh Shilimkar writes: OMAP WakeupGen is the interrupt controller extension used along with ARM GIC to wake the CPU out from low power states on external interrupts. The WakeupGen unit is responsible for generating wakeup event from the incoming interrupts and enable bits. It is implemented in MPU always ON power domain. During normal operation, WakeupGen delivers external interrupts directly to the GIC. Signed-off-by: Santosh Shilimkar Cc: Kevin Hilman [...] +#ifdef CONFIG_PM +/* + * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag, + * so no action is necessary in set_wake, but implement an empty handler + * here to prevent enable_irq_wake() returning an error. + * FIXME: Remove the dummy handler once gen irq code fix above. + */ Just curious... is there a fix for this pending for v3.2? I have sent a proposed change to Thomas but have not seen any response yet from him. http://www.spinics.net/lists/arm-kernel/msg134297.html Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Friday 09 September 2011 12:46 AM, Jean Pihet wrote:
On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
wrote:
OMAP WakeupGen is the interrupt controller extension used along
with ARM GIC to wake the CPU out from low power states on
external interrupts.
The WakeupGen unit is responsible for generating wakeup event
... for generating the wakeup events
from the incoming interrupts and enable bits. It is implemented
in MPU always ON power domain. During normal operation,
in the MPU...
WakeupGen delivers external interrupts directly to the GIC.
... delivers the external interrupts
OK.
Signed-off-by: Santosh Shilimkar
Cc: Kevin Hilman
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h | 39
arch/arm/mach-omap2/omap-wakeupgen.c | 241 +
arch/arm/mach-omap2/omap4-common.c|3 +
4 files changed, 284 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
create mode 100644 arch/arm/mach-omap2/omap-wakeupgen.c
...
+ */
+int __init omap_wakeupgen_init(void)
+{
+ int i;
+ unsigned int boot_cpu = smp_processor_id();
+
+ /* Not supported on OMAP4 ES1.0 silicon */
+ if (omap_rev() == OMAP4430_REV_ES1_0) {
+ WARN(1, "WakeupGen: Not supported on OMAP4430 ES1.0\n");
+ return -EPERM;
+ }
+
+ /* Static mapping, never released */
+ wakeupgen_base = ioremap(OMAP44XX_WKUPGEN_BASE, SZ_4K);
+ if (WARN_ON(!wakeupgen_base))
+ return -ENODEV;
-ENOMEM os required as discussed in the other patches of the series.
Yep.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
OMAP WakeupGen is the interrupt controller extension used along with ARM GIC to wake the CPU out from low power states on external interrupts. The WakeupGen unit is responsible for generating wakeup event from the incoming interrupts and enable bits. It is implemented in MPU always ON power domain. During normal operation, WakeupGen delivers external interrupts directly to the GIC. Signed-off-by: Santosh Shilimkar Cc: Kevin Hilman --- arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h | 39 arch/arm/mach-omap2/omap-wakeupgen.c | 241 + arch/arm/mach-omap2/omap4-common.c|3 + 4 files changed, 284 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h create mode 100644 arch/arm/mach-omap2/omap-wakeupgen.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index c53a8e8..b032c21 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -25,7 +25,7 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h new file mode 100644 index 000..d79321b --- /dev/null +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h @@ -0,0 +1,39 @@ +/* + * OMAP WakeupGen header file + * + * Copyright (C) 2011 Texas Instruments, Inc. + * Santosh Shilimkar + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef OMAP_ARCH_WAKEUPGEN_H +#define OMAP_ARCH_WAKEUPGEN_H + +#define OMAP_WKG_CONTROL_0 0x00 +#define OMAP_WKG_ENB_A_0 0x10 +#define OMAP_WKG_ENB_B_0 0x14 +#define OMAP_WKG_ENB_C_0 0x18 +#define OMAP_WKG_ENB_D_0 0x1c +#define OMAP_WKG_ENB_SECURE_A_00x20 +#define OMAP_WKG_ENB_SECURE_B_00x24 +#define OMAP_WKG_ENB_SECURE_C_00x28 +#define OMAP_WKG_ENB_SECURE_D_00x2c +#define OMAP_WKG_ENB_A_1 0x410 +#define OMAP_WKG_ENB_B_1 0x414 +#define OMAP_WKG_ENB_C_1 0x418 +#define OMAP_WKG_ENB_D_1 0x41c +#define OMAP_WKG_ENB_SECURE_A_10x420 +#define OMAP_WKG_ENB_SECURE_B_10x424 +#define OMAP_WKG_ENB_SECURE_C_10x428 +#define OMAP_WKG_ENB_SECURE_D_10x42c +#define OMAP_AUX_CORE_BOOT_0 0x800 +#define OMAP_AUX_CORE_BOOT_1 0x804 +#define OMAP_PTMSYNCREQ_MASK 0xc00 +#define OMAP_PTMSYNCREQ_EN 0xc04 +#define OMAP_TIMESTAMPCYCLELO 0xc08 +#define OMAP_TIMESTAMPCYCLEHI 0xc0c + +extern int __init omap_wakeupgen_init(void); +#endif diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c new file mode 100644 index 000..a0882e6 --- /dev/null +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -0,0 +1,241 @@ +/* + * OMAP WakeupGen Source file + * + * OMAP WakeupGen is the interrupt controller extension used along + * with ARM GIC to wake the CPU out from low power states on + * external interrupts. It is responsible for generating wakeup + * event from the incoming interrupts and enable bits. It is + * implemented in MPU always ON power domain. During normal operation, + * WakeupGen delivers external interrupts directly to the GIC. + * + * Copyright (C) 2011 Texas Instruments, Inc. + * Santosh Shilimkar + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include + +#include + +#include + +#define NR_BANKS 4 +#define MAX_IRQS 128 +#define WKG_MASK_ALL 0x +#define WKG_UNMASK_ALL 0x +#define CPU_ENA_OFFSET 0x400 +#define CPU0_ID0x0 +#define CPU1_ID0x1 + +static void __iomem *wakeupgen_base; +static DEFINE_PER_CPU(u32 [NR_BANKS], irqmasks); +static DEFINE_SPINLOCK(wakeupgen_lock); +static unsigned int irq_target_cpu[NR_IRQS]
