In Embedded system the dev_pm_info.power_state is useful
Hi all
I'm Francesco Virlinzi and I work in STMicroelectronics, I'm a developers of STLinux (www.stlinux.com) an
embedded Linux distribution for ST Set Top Box.
I read in the pm mail list that you are going to remove in the kernel the
dev_pm_info.power_state field in the dev_pm_info struct replaced by
bus-specific field.
My request is: don't do that.
In embedded system it' s really useful because there are a lot of generic IP on a single bus (the pltaform bus)
and the only way to check the power state of each IP is based on
'dev_pm_info.power_state'
without this filed we will have our IP (platform_device) with no power
state concept...
At least we could put it under CONFIG_EMBEDDED.
What do you know?
Regards
Francesco
Hi all
Quoted 24 lines
I'm Francesco Virlinzi and I work in STMicroelectronics, I'm a developers of STLinux (www.stlinux.com) an
embedded Linux distribution for ST Set Top Box.I read in the pm mail list that you are going to remove in the kernel the
dev_pm_info.power_state field in thedev_pm_infostruct replaced by
bus-specific field.My request is: don't do that.
In embedded system it' s really useful because there are a lot of generic IP on a single bus (the pltaform bus)
and the only way to check the power state of each IP is based on
'dev_pm_info.power_state'
without this filed we will have our IP (platform_device) with no power
state concept...At least we could put it under
CONFIG_EMBEDDED.Quoted 1 line
Quoted 1 line
What do you THINK ?
Regards
Francesco
Quoted 9 lines · Francesco VIRLINZI
Hi all
I'm Francesco Virlinzi and I work in STMicroelectronics, I'm a developers of STLinux (www.stlinux.com) an
embedded Linux distribution for ST Set Top Box.I read in the pm mail list that you are going to remove in the kernel the
dev_pm_info.power_state field in thedev_pm_infostruct replaced by
bus-specific field.
Quoted 7 lines
My request is: don't do that.
In embedded system it' s really useful because there are a lot of generic IP on a single bus (the pltaform bus)
and the only way to check the power state of each IP is based on
'dev_pm_info.power_state'
without this filed we will have our IP (platform_device) with no power
state concept...
That isn't the only way to check the power state. You should have a private data structure associated with each of the devices you care about. The address of the private data structure is what you store in platform_set_drvdata(). In the private data structure you can have a field to indicate the device's power state.
If the platform-bus IP really is generic then you can't possibly know what its dev_pm_info.power_state value means, anyway.
Alan Stern
Hi Alan
Thank for your reply.
Quoted 6 lines
That isn't the only way to check the power state. You should have a private data structure associated with each of the devices you care about. The address of the private data structure is what you store in
platform_set_drvdata(). In the private data structure you can have a field to indicate the device's power state.
Yes you are right.
The problem is that each driver can use the private_data as it wants, while I need a generic
API to understand the power state of device.
Your suggestion works fine if (internally) we assume an agreement
(i.e.: the first word in the private data is the power state) and in
this manner
I can analyse several IP with a single API.
But to do that (at the moment) I just do
(dev->power.power_state.event == xx)
and PM_EVENT_ON/PM_EVENT_SUSPEND are good enough.
Why did you decide to remove it?
Regards
Francesco
Quoted 6 lines
If the platform-bus IP really is generic then you can't possibly know what its dev_pm_info.power_state value means, anyway.
Alan Stern
Quoted 8 lines · Francesco VIRLINZI
Hi Alan
Thank for your reply.Quoted 6 lines
That isn't the only way to check the power state. You should have a private data structure associated with each of the devices you care about. The address of the private data structure is what you store in
platform_set_drvdata(). In the private data structure you can have a field to indicate the device's power state.
Quoted 4 lines
Yes you are right.
The problem is that each driver can use theprivate_dataas it wants, while I need a generic
API to understand the power state of device.
That's not the only problem. Each driver can also use dev->power.power_state.event the way it wants. So looking at that field won't tell you anything.
Quoted 10 lines
Your suggestion works fine if (internally) we assume an agreement
(i.e.: the first word in the private data is the power state) and in
this manner
I can analyse several IP with a single API.
But to do that (at the moment) I just do(dev->power.power_state.event == xx)and PM_EVENT_ON/PM_EVENT_SUSPEND are good enough.
Why did you decide to remove it?
Because it is almost meaningless. For example, suppose a particular platform device has 3 power states: On with high performance, on with low performance, and off. Then how can you tell which state it is in by looking at dev->power.power_state.event?
I suspect that you are trying to solve some problem in the wrong way. But without knowing what that problem is, I can't advise you on better ways to solve it.
Alan Stern