On 03/21/2015 09:35 PM, Lorenzo Pieralisi wrote:
On Fri, Mar 20, 2015 at 11:44:00AM +0000, Daniel Lezcano wrote:
Some architectures have some cpus which does not support idle states.
Let the underlying low level code to return -ENXIO when it is not
possible to set an idle state.
Well, this is getting interesting. We are parsing possible CPUs to
detect if they have common idle states in DT. If a CPU does not support
idle states, the cpu node for that CPU should not define any idle
state.
The approach above will work with my heterogenous system patch, since
the respective CPUidle driver mask will be created by parsing the DT
idle states.
http://www.spinics.net/lists/arm-kernel/msg403190.html
In current approach if a "possible " CPU does not have idle states, we do
not init CPUidle at all.
So, to cut a long story short, what does "a cpu does not support idle
states" mean ?
Does it mean that firmware defines idle states for that CPU in DT but
initializing them fail ?
I am fine with this patch, but we need to define -ENXIO return properly.
Ok, I think that needs more discussion.
I will drop this patch from my patchset as we agreed on the other
patches and resubmit.
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
