Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Rafael J. Wysocki" <rjw@rjwysocki.net>
To:     Daniel Lezcano <daniel.lezcano@linaro.org>
Cc:     mathieu.poirier@linaro.org, mingo@redhat.com, peterz@infradead.org,
        linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
        ulf.hansson@linaro.org
Subject: Re: [PATCH V6 1/3] cpuidle: play_idle: Make play_idle more flexible
Date:   Fri, 08 Nov 2019 01:53:25 +0100
Message-ID: <11162801.HHDnLhZHqx@kreacher>
In-Reply-To: <d185fdf8-8398-c8f5-b49a-47e5bb00607c@linaro.org>
References: <20191030075141.1039-1-daniel.lezcano@linaro.org> <d185fdf8-8398-c8f5-b49a-47e5bb00607c@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wednesday, November 6, 2019 7:27:47 PM CET Daniel Lezcano wrote:
> 
> Hi Rafael,
> 
> 
> On 30/10/2019 08:51, Daniel Lezcano wrote:
> > The play_idle function has two users, the intel powerclamp and the
> > idle_injection.
> > 
> > The idle injection cooling device uses the function via the
> > idle_injection powercap's APIs. Unfortunately, play_idle is currently
> > limited by the idle state depth: by default the deepest idle state is
> > selected. On the ARM[64] platforms, most of the time it is the cluster
> > idle state, the exit latency and the residency can be very high. That
> > reduces the scope of the idle injection usage because the impact on
> > the performances can be very significant.
> > 
> > If the idle injection cycles can be done with a shallow state like a
> > retention state, the cooling effect would eventually give similar
> > results than the cpufreq cooling device.
> > 
> > In order to prepare the function to receive an idle state parameter,
> > let's replace the 'use_deepest_state' boolean field with 'use_state'
> > and use this value to enter the specific idle state.
> > 
> > The current code keeps the default behavior which is go to the deepest
> > idle state.
> > 
> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
> 
> Is it possible to merge this series so I can make some progress on
> upstreaming the idle cooling device which depends on these three patches?

That would be possible if the series had no problems, but it appears to have
some.

Let me reply to the patches.