On 23-06-20, 15:21, Quentin Perret wrote:
> @@ -2789,7 +2796,13 @@ static int __init cpufreq_core_init(void)
> cpufreq_global_kobject = kobject_create_and_add("cpufreq",
> _subsys.dev_root->kobj);
> BUG_ON(!cpufreq_global_kobject);
>
> + mutex_lock(_governor_mutex);
> + if
On Thu, Jun 25, 2020 at 3:50 PM Quentin Perret wrote:
>
> On Thursday 25 Jun 2020 at 15:28:43 (+0200), Rafael J. Wysocki wrote:
> > On Thu, Jun 25, 2020 at 1:53 PM Quentin Perret wrote:
> > >
> > > On Thursday 25 Jun 2020 at 13:44:34 (+0200), Rafael J. Wysocki wrote:
> > > > On Thu, Jun 25, 2020
On Thu, Jun 25, 2020 at 1:53 PM Quentin Perret wrote:
>
> On Thursday 25 Jun 2020 at 13:44:34 (+0200), Rafael J. Wysocki wrote:
> > On Thu, Jun 25, 2020 at 1:36 PM Viresh Kumar
> > wrote:
> > > This change is not right IMO. This part handles the set-policy case,
> > > where there are no
On Thu, Jun 25, 2020 at 1:36 PM Viresh Kumar wrote:
>
> After your last email (reply to my patch), I noticed a change which
> isn't required. :)
>
> On 23-06-20, 15:21, Quentin Perret wrote:
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index
On Thu, Jun 25, 2020 at 10:50 AM Viresh Kumar wrote:
>
> On 24-06-20, 16:32, Quentin Perret wrote:
> > Right, but I must admit that, looking at this more, I'm getting a bit
> > confused with the overall locking for governors :/
> >
> > When in cpufreq_init_policy() we find a governor using
> >
On Wed, Jun 24, 2020 at 7:50 AM Viresh Kumar wrote:
>
> On 23-06-20, 15:21, Quentin Perret wrote:
> > Currently, the only way to specify the default CPUfreq governor is via
> > Kconfig options, which suits users who can build the kernel themselves
> > perfectly.
> >
> > However, for those who use
On 23-06-20, 15:21, Quentin Perret wrote:
> Currently, the only way to specify the default CPUfreq governor is via
> Kconfig options, which suits users who can build the kernel themselves
> perfectly.
>
> However, for those who use a distro-like kernel (such as Android, with
> the Generic Kernel
