On 20 November 2013 20:29, Nishanth Menon wrote:
> With the current governors that we have in upstream, the only one of
> my concern has been userspace governor, but based on your comment
> earlier in the thread, this is considered an non-issue since userspace
> must trigger transition. However,
On 11/19/2013 11:24 PM, viresh kumar wrote:
> On Tuesday 19 November 2013 11:13 PM, Nishanth Menon wrote:
>> we depend on the first transition to take us to a sane configuration -
>> but we cannot predict when and if it will happen.
>
> I really believe that it happens fairly quickly, isn't it?
On 11/19/2013 11:24 PM, viresh kumar wrote:
On Tuesday 19 November 2013 11:13 PM, Nishanth Menon wrote:
we depend on the first transition to take us to a sane configuration -
but we cannot predict when and if it will happen.
I really believe that it happens fairly quickly, isn't it? We
On 20 November 2013 20:29, Nishanth Menon n...@ti.com wrote:
With the current governors that we have in upstream, the only one of
my concern has been userspace governor, but based on your comment
earlier in the thread, this is considered an non-issue since userspace
must trigger transition.
On Tuesday 19 November 2013 11:13 PM, Nishanth Menon wrote:
> we depend on the first transition to take us to a sane configuration -
> but we cannot predict when and if it will happen.
I really believe that it happens fairly quickly, isn't it? We straight away
start the sampling of load and
On 11/19/2013 11:10 AM, Viresh Kumar wrote:
> On 19 November 2013 21:18, Nishanth Menon wrote:
>> is that true for userspace governor
>> (CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE)?
>> /sys/devices/system/cpu/cpu0/cpufreq $ cat scaling_available_frequencies
>> 50 100 150
>>
>>
On 19 November 2013 21:18, Nishanth Menon wrote:
> is that true for userspace governor
> (CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE)?
> /sys/devices/system/cpu/cpu0/cpufreq $ cat scaling_available_frequencies
> 50 100 150
>
> /sys/devices/system/cpu/cpu0/cpufreq $ cat scaling_cur_freq
>
On 11/19/2013 09:32 AM, Viresh Kumar wrote:
> On 19 November 2013 20:29, Nishanth Menon wrote:
>> Not completely true - reaching probe after boot in a few seconds may
>> not mean that system will remain stable at that frequency for longer
>> duration. From a silicon vendor perspective, I do know
On 19 November 2013 20:29, Nishanth Menon wrote:
> Not completely true - reaching probe after boot in a few seconds may
> not mean that system will remain stable at that frequency for longer
> duration. From a silicon vendor perspective, I do know that we
> gaurentee the discrete frequencies in
On 11/19/2013 08:26 AM, Viresh Kumar wrote:
> On 19 November 2013 19:46, Nishanth Menon wrote:
>> Consider something like userspace governor selection -> the device at
>> boot will probably remain in an unknown/"invalid" configuration till
>> the very first transition attempt. I am less worried
On 19 November 2013 19:46, Nishanth Menon wrote:
> Consider something like userspace governor selection -> the device at
> boot will probably remain in an unknown/"invalid" configuration till
> the very first transition attempt. I am less worried about the stats
> than not following what the
On 11/18/2013 09:46 PM, Viresh Kumar wrote:
> On 19 November 2013 07:51, Shawn Guo wrote:
>> No, I did not say that. IMO, when cpufreq-cpu0 sees a mismatch, it has
>> no way to know or assume which one is correct and which is incorrect.
>> The best thing it can do is to fail out without changing
On 11/18/2013 09:46 PM, Viresh Kumar wrote:
On 19 November 2013 07:51, Shawn Guo shawn@linaro.org wrote:
No, I did not say that. IMO, when cpufreq-cpu0 sees a mismatch, it has
no way to know or assume which one is correct and which is incorrect.
The best thing it can do is to fail out
On 19 November 2013 19:46, Nishanth Menon n...@ti.com wrote:
Consider something like userspace governor selection - the device at
boot will probably remain in an unknown/invalid configuration till
the very first transition attempt. I am less worried about the stats
than not following what the
On 11/19/2013 08:26 AM, Viresh Kumar wrote:
On 19 November 2013 19:46, Nishanth Menon n...@ti.com wrote:
Consider something like userspace governor selection - the device at
boot will probably remain in an unknown/invalid configuration till
the very first transition attempt. I am less worried
On 19 November 2013 20:29, Nishanth Menon n...@ti.com wrote:
Not completely true - reaching probe after boot in a few seconds may
not mean that system will remain stable at that frequency for longer
duration. From a silicon vendor perspective, I do know that we
gaurentee the discrete
On 11/19/2013 09:32 AM, Viresh Kumar wrote:
On 19 November 2013 20:29, Nishanth Menon n...@ti.com wrote:
Not completely true - reaching probe after boot in a few seconds may
not mean that system will remain stable at that frequency for longer
duration. From a silicon vendor perspective, I do
On 19 November 2013 21:18, Nishanth Menon n...@ti.com wrote:
is that true for userspace governor
(CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE)?
/sys/devices/system/cpu/cpu0/cpufreq $ cat scaling_available_frequencies
50 100 150
/sys/devices/system/cpu/cpu0/cpufreq $ cat
On 11/19/2013 11:10 AM, Viresh Kumar wrote:
On 19 November 2013 21:18, Nishanth Menon n...@ti.com wrote:
is that true for userspace governor
(CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE)?
/sys/devices/system/cpu/cpu0/cpufreq $ cat scaling_available_frequencies
50 100 150
On Tuesday 19 November 2013 11:13 PM, Nishanth Menon wrote:
we depend on the first transition to take us to a sane configuration -
but we cannot predict when and if it will happen.
I really believe that it happens fairly quickly, isn't it? We straight away
start the sampling of load and withing
On 19 November 2013 07:51, Shawn Guo wrote:
> No, I did not say that. IMO, when cpufreq-cpu0 sees a mismatch, it has
> no way to know or assume which one is correct and which is incorrect.
> The best thing it can do is to fail out without changing anything about
> running frequency and voltage.
On Mon, Nov 18, 2013 at 10:41:36AM -0600, Nishanth Menon wrote:
> In the case of mismatch, to consider that device tree may be wrong in
> driver is also to assume that hardware was always configured correctly
> and we assume description is the flawed data.
No, I did not say that. IMO, when
On 11/18/2013 09:57 AM, Shawn Guo wrote:
> On Mon, Nov 18, 2013 at 08:45:12AM -0600, Nishanth Menon wrote:
>
>> I do not agree about this stance - device tree describes hardware
>> capabilities to kernel -> I agree with that statement. Kernel should
>> not care if that is provided by
On Mon, Nov 18, 2013 at 08:45:12AM -0600, Nishanth Menon wrote:
> I do not agree about this stance - device tree describes hardware
> capabilities to kernel -> I agree with that statement. Kernel should
> not care if that is provided by bootloader/firmware/fused into
> flash/ROM etc.
Yea,
On 11/16/2013 10:02 PM, Viresh Kumar wrote:
> On 16 November 2013 19:14, Shawn Guo wrote:
>> No, it's not a kernel bug.
>>
>> OPP is not a definition that belongs to kernel. Instead, it's
>> characteristics of hardware, and that's why we can naturally put the
>> definition into device tree.
On 11/16/2013 10:02 PM, Viresh Kumar wrote:
On 16 November 2013 19:14, Shawn Guo shawn@linaro.org wrote:
No, it's not a kernel bug.
OPP is not a definition that belongs to kernel. Instead, it's
characteristics of hardware, and that's why we can naturally put the
definition into device
On Mon, Nov 18, 2013 at 08:45:12AM -0600, Nishanth Menon wrote:
snip
I do not agree about this stance - device tree describes hardware
capabilities to kernel - I agree with that statement. Kernel should
not care if that is provided by bootloader/firmware/fused into
flash/ROM etc.
Yea, ideally
On 11/18/2013 09:57 AM, Shawn Guo wrote:
On Mon, Nov 18, 2013 at 08:45:12AM -0600, Nishanth Menon wrote:
snip
I do not agree about this stance - device tree describes hardware
capabilities to kernel - I agree with that statement. Kernel should
not care if that is provided by
On Mon, Nov 18, 2013 at 10:41:36AM -0600, Nishanth Menon wrote:
In the case of mismatch, to consider that device tree may be wrong in
driver is also to assume that hardware was always configured correctly
and we assume description is the flawed data.
No, I did not say that. IMO, when
On 19 November 2013 07:51, Shawn Guo shawn@linaro.org wrote:
No, I did not say that. IMO, when cpufreq-cpu0 sees a mismatch, it has
no way to know or assume which one is correct and which is incorrect.
The best thing it can do is to fail out without changing anything about
running
On 16 November 2013 19:14, Shawn Guo wrote:
> No, it's not a kernel bug.
>
> OPP is not a definition that belongs to kernel. Instead, it's
> characteristics of hardware, and that's why we can naturally put the
> definition into device tree. Bear it in mind that device tree is a
> hardware
On Fri, Nov 15, 2013 at 08:22:15PM -0600, Nishanth Menon wrote:
> On many development platforms, at boot, the bootloader configured
> frequency maynot match the valid frequencies that are stated to be
> supported in OPP table. This may occur due to various reasons:
> a) older or default bootloader
On Fri, Nov 15, 2013 at 08:22:15PM -0600, Nishanth Menon wrote:
On many development platforms, at boot, the bootloader configured
frequency maynot match the valid frequencies that are stated to be
supported in OPP table. This may occur due to various reasons:
a) older or default bootloader in
On 16 November 2013 19:14, Shawn Guo shawn@linaro.org wrote:
No, it's not a kernel bug.
OPP is not a definition that belongs to kernel. Instead, it's
characteristics of hardware, and that's why we can naturally put the
definition into device tree. Bear it in mind that device tree is a
On many development platforms, at boot, the bootloader configured
frequency maynot match the valid frequencies that are stated to be
supported in OPP table. This may occur due to various reasons:
a) older or default bootloader in development platform without latest
updates
b) SoC documentation
On many development platforms, at boot, the bootloader configured
frequency maynot match the valid frequencies that are stated to be
supported in OPP table. This may occur due to various reasons:
a) older or default bootloader in development platform without latest
updates
b) SoC documentation
36 matches
Mail list logo
