From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752847AbcAUBjT (ORCPT <rfc822;w@1wt.eu>);
	Wed, 20 Jan 2016 20:39:19 -0500
Received: from mail-pa0-f50.google.com ([209.85.220.50]:36807 "EHLO
	mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751135AbcAUBjR (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 20 Jan 2016 20:39:17 -0500
Subject: Re: sched-freq locking
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
References: <56984C30.8040402@linaro.org>
 <CAEG3pNBgpsdX8Lk7_3nHd31_bsq2sLB_f+=4_xiFFbiAWiKsxg@mail.gmail.com>
 <569EE1E1.3050407@linaro.org> <2058083.HonoCMD469@vostro.rjw.lan>
Cc: Michael Turquette <mturquette@baylibre.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Juri Lelli <Juri.Lelli@arm.com>,
        Patrick Bellasi <patrick.bellasi@arm.com>,
        Morten Rasmussen <morten.rasmussen@arm.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
From: Steve Muckle <steve.muckle@linaro.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <56A036C2.4090403@linaro.org>
Date: Wed, 20 Jan 2016 17:39:14 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <2058083.HonoCMD469@vostro.rjw.lan>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 01/20/2016 05:22 PM, Rafael J. Wysocki wrote:
> One comment here (which may be a bit off in which case please ignore it).
> 
> You seem to be thinking that sched-freq needs to be a cpufreq governor
> and thus be handled in the same way as ondemand, for example.

That's true, I hadn't really given much thought to the alternative you
mention below.

> 
> However, this doesn't have to be the case in principle.  For example,
> if we have a special driver callback specifically to work with sched-freq,
> it may just use that callback and bypass (almost) all of the usual
> cpufreq mechanics.  This way you may avoid worrying about the governor
> locking and related ugliness entirely.

That sounds good but I'm worried about other consequences of taking
cpufreq out of the loop. For example wouldn't we need a new way for
something like thermal to set frequency limits?

thanks,
steve