On 24 March 2014 12:18, Viresh Kumar wrote:
> Ideally, .driver_data field of struct cpufreq_frequency_table must not be used
> by core at all. But during a recent change if its value is same as
> CPUFREQ_BOOST_FREQ macro, then it is treated specially by core.
>
> The value of this macro was set to
On Mon, Mar 24, 2014 at 12:18:14PM +0530, Viresh Kumar wrote:
> Ideally, .driver_data field of struct cpufreq_frequency_table must not be used
> by core at all. But during a recent change if its value is same as
> CPUFREQ_BOOST_FREQ macro, then it is treated specially by core.
>
> The value of thi
On 24 March 2014 13:51, Lukasz Majewski wrote:
> I think that a name of the patchset, for which the current setting
> causes problem would be welcome here.
I couldn't find a lkml link to the exact message earlier, but it was discussed
here:
https://patchwork.kernel.org/patch/3865481/
> Otherwis
Hi Viresh,
> Ideally, .driver_data field of struct cpufreq_frequency_table must
> not be used by core at all. But during a recent change if its value
> is same as CPUFREQ_BOOST_FREQ macro, then it is treated specially by
> core.
>
> The value of this macro was set to ~2 earlier, i.e. 0xFFFD.
Ideally, .driver_data field of struct cpufreq_frequency_table must not be used
by core at all. But during a recent change if its value is same as
CPUFREQ_BOOST_FREQ macro, then it is treated specially by core.
The value of this macro was set to ~2 earlier, i.e. 0xFFFD. In case some
driver is u
5 matches
Mail list logo
