From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751521AbdKUXcd (ORCPT ); Tue, 21 Nov 2017 18:32:33 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34980 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751290AbdKUXcb (ORCPT ); Tue, 21 Nov 2017 18:32:31 -0500 X-Google-Smtp-Source: AGs4zMaJedzAZ8A8P/nc4V/oAWpnkYcaGxLBDaa2ib0igLfDxs8SlpOy8AeOeXuvhi2sFBuIsp/Mrw== Message-ID: <5A14B78B.8070407@gmail.com> Date: Wed, 22 Nov 2017 00:32:27 +0100 From: Lukasz Luba User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Eduardo Valentin , Daniel Lezcano CC: Javi Merino , Vincent Guittot , Ionela Voinescu , Punit Agrawal , "Rafael J. Wysocki" , Viresh Kumar , "Rafael J. Wysocki" , Amit Daniel Kachhap , Zhang Rui , Steven Rostedt , Ingo Molnar , Linux PM , Lukasz Luba , Linux Kernel Mailing List Subject: Re: [PATCH 4/4] cpu_cooling: Drop static-power related stuff References: <2810372.fJ2vMN0cWO@aspire.rjw.lan> <20171116234422.GA6141@localhost.localdomain> <878tf5tbfj.fsf@e105922-lin.cambridge.arm.com> <35d3751d-f28d-38c2-02b2-c9980f11c52e@arm.com> <5A144CB3.50806@gmail.com> <20171121165703.GA2499@localhost.localdomain> <20171121180006.GA26638@localhost> <6cd409ee-c839-09ad-3fa2-5309b0d007f5@linaro.org> <20171121181351.GB4075@localhost.localdomain> In-Reply-To: <20171121181351.GB4075@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/11/17 19:13, Eduardo Valentin wrote: > On Tue, Nov 21, 2017 at 07:05:46PM +0100, Daniel Lezcano wrote: >> On 21/11/2017 19:00, Javi Merino wrote: >>> Hi, >>> >>> On Tue, Nov 21, 2017 at 08:57:06AM -0800, Eduardo Valentin wrote: >>> >>> [snip] >>> >>>> As I said before, the minimal you guys (ARM and Linaro) can do is to at >>>> least upstream the Juno code! as a reference. Come on guys? what is >>>> preventing you to upstream Juno model? >>> >>> As Ionela pointed out earlier in the thread, the cpufreq driver for Juno >>> was not acceptable for mainline because it used platform specific code. >>> When it was converted to cpufreq-dt, the static power was left behind >>> because it can't be represented in device tree. This is because there >>> isn't a function that works for every SoC, different process nodes >>> (among other things) will need different functions. So it can't be just >>> a bunch of coefficients in DT, we need a function. Hence the callback. >> >> The DT could contain the coef and a compatible string for a specific >> polynomial computation callback. I imagine we should not have a lot of >> different equations, no ? >> > > Yeah, that would be another way of doing it. If there is no equation > that correlates all processes, then we need a vendor specific entry, or > a compatible string, as Daniel said. > So we have ~8 weeks (before it will vanish from mainline) to come up with ideas or to show that it is needed and used by some platform. Let's see... Regards, Lukasz