[PATCH 48/74] GIC: Added dummy handlers for Power Management Suspend Resume
deepaksi
deepak.sikri at st.com
Thu Sep 9 00:17:54 EDT 2010
On 9/8/2010 8:42 PM, Russell King - ARM Linux wrote:
> On Mon, Sep 06, 2010 at 05:25:31PM +0530, deepaksi wrote:
>
>> On 9/3/2010 1:04 PM, Russell King - ARM Linux wrote:
>>
>>> So how are wakeup sources configured if this callback does nothing?
>>> .
>>>
>> In most of the architectures that I could refer across(including SPEAr
>> family -SPEAr13xx),
>> have a separate power management unit(PMU) which is required to be
>> configured to define the wake
>> up sources. The PMU takes care of waking up the system from sleep, as
>> and when the wake up
>> interrupts are triggered. This routing is independent of GIC, and hence
>> the handling was not added.
>>
>> Contrary to that, in some of our hardware architecture using VIC
>> (including SPEAr 3xx/6xx), there
>> was no explicit PMU, and the wake up trigger was exclusively done
>> through VIC, and hence the VIC
>> call backs had the necessary implementation.
>>
> What I read into this is that you're using enable_irq_wake() in your
> drivers _and_ another mechanism to configure what wakes up the system
> via the PMU - maybe with drivers explicitly calling out to the PMU
> to achieve this?
>
This is even true for the drivers already in the kernel for example
stmmac driver ( using synopsis GMAC core): drivers/net/stmmac/
if we don not check for the return type, then probably it makes sense to
remove the dunny handlers, else another alternative could be to modify
the enable_irq_wake() call, to return the proper values.
Changing the driver specific to SPEAr is fine, but SPEAr platform does
uses the existing drivers in the kernel.
> This sounds a little haphazard, especially from the drivers point of
> view. Surely there's a more sensible solution to this rather than
> adding do-nothing irq_wake support?
> .
>
>
How do you recommend to go about this ?
More information about the linux-arm-kernel
mailing list