Hi Guys,
Is there a standard way for the device drivers to know if the system
is going to “standby” mode or “mem” mode when the suspend() callbacks
are called?
Regards,
Leo
On 08/16/2013 10:06 AM, Li Yang wrote:
> Hi Guys,
>
> Is there a standard way for the device drivers to know if the system
> is going to “standby” mode or “mem” mode when the suspend() callbacks
> are called?
what about implementing struct device_driver::suspend?
This is for driver level suspend operation, so not per-device.
> Regards,
>
> Leo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Friday, August 16, 2013 04:06:26 PM Li Yang wrote:
> Hi Guys,
>
> Is there a standard way for the device drivers to know if the system
> is going to “standby” mode or “mem” mode when the suspend() callbacks
> are called?
No, there's none.
What do you need that for?
Rafael
?? 2013-8-16??????7:22??"Rafael J. Wysocki" <[email protected]> д????
> On Friday, August 16, 2013 04:06:26 PM Li Yang wrote:
>> Hi Guys,
>>
>> Is there a standard way for the device drivers to know if the system
>> is going to ??standby?? mode or ??mem?? mode when the suspend() callbacks
>> are called?
>
> No, there's none.
>
> What do you need that for?
Some chips like ours are putting the on-chip devices into different low power states when entering different system low power states. When we enter system standby, on-chip devices are clock gated. While entering suspend to ram, on-chip devices are power gated. We want to driver to act differently too when entering different suspend states.
- Leo
>
> Rafael
>
>
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Friday, August 16, 2013 05:13:42 PM Li Yang-R58472 wrote:
>
> 在 2013-8-16，下午7:22，"Rafael J. Wysocki" <[email protected]> 写道：
>
> > On Friday, August 16, 2013 04:06:26 PM Li Yang wrote:
> >> Hi Guys,
> >>
> >> Is there a standard way for the device drivers to know if the system
> >> is going to “standby” mode or “mem” mode when the suspend() callbacks
> >> are called?
> >
> > No, there's none.
> >
> > What do you need that for?
>
> Some chips like ours are putting the on-chip devices into different low
> power states when entering different system low power states. When we enter
> system standby, on-chip devices are clock gated. While entering suspend to
> ram, on-chip devices are power gated. We want to driver to act differently
> too when entering different suspend states.
Can you possibly use platform suspend operations to implement that (in analogy
with ACPI suspend operations)?
Rafael
On Sat, Aug 17, 2013 at 7:53 AM, Rafael J. Wysocki <[email protected]> wrote:
> On Friday, August 16, 2013 05:13:42 PM Li Yang-R58472 wrote:
>>
>> 在 2013-8-16，下午7:22，"Rafael J. Wysocki" <[email protected]> 写道：
>>
>> > On Friday, August 16, 2013 04:06:26 PM Li Yang wrote:
>> >> Hi Guys,
>> >>
>> >> Is there a standard way for the device drivers to know if the system
>> >> is going to “standby” mode or “mem” mode when the suspend() callbacks
>> >> are called?
>> >
>> > No, there's none.
>> >
>> > What do you need that for?
>>
>> Some chips like ours are putting the on-chip devices into different low
>> power states when entering different system low power states. When we enter
>> system standby, on-chip devices are clock gated. While entering suspend to
>> ram, on-chip devices are power gated. We want to driver to act differently
>> too when entering different suspend states.
>
> Can you possibly use platform suspend operations to implement that (in analogy
> with ACPI suspend operations)?
I agree it's best to get the state that the device will be in during
suspend from the platform code. Will it be better to have a standard
interface to pass this information? Given the fact that a single
device can be used by different platforms even different architecture
nowadays. How about exposing some new callbacks from the
platform_suspend_ops for the driver to use?
Regards,
Leo