Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 11 Jun 2020 12:03:01 +0100
From:   Quentin Perret <qperret@google.com>
To:     Douglas Anderson <dianders@chromium.org>
Cc:     Benson Leung <bleung@chromium.org>,
        Enric Balletbo i Serra <enric.balletbo@collabora.com>,
        hsinyi@chromium.org, joelaf@google.com, peterz@infradead.org,
        drinkcat@chromium.org, gwendal@chromium.org,
        ctheegal@codeaurora.org, Guenter Roeck <groeck@chromium.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump
 cpu freq
Message-ID: <20200611110301.GA132747@google.com>
References: <20200610151818.1.I666ecd9c6f3c6405bd75831a21001b8109b6438c@changeid>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200610151818.1.I666ecd9c6f3c6405bd75831a21001b8109b6438c@changeid>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Doug,

On Wednesday 10 Jun 2020 at 15:18:43 (-0700), Douglas Anderson wrote:
> The cros_ec_spi driver is realtime priority so that it doesn't get
> preempted by other taks while it's talking to the EC but overall it
> really doesn't need lots of compute power.  Unfortunately, by default,
> the kernel assumes that all realtime tasks should cause the cpufreq to
> jump to max and burn through power to get things done as quickly as
> possible.  That's just not the correct behavior for cros_ec_spi.

Is this specific to this driver, or something you would want applied
more globally to all RT tasks in ChromeOS (which is what we'd like to
have in Android for instance)?

IOW, how do you feel about 20200511154053.7822-1-qais.yousef@arm.com ?

Otherwise, the patch looks good to me.

Thanks,
Quentin