From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751470AbdKVBZj (ORCPT ); Tue, 21 Nov 2017 20:25:39 -0500 Received: from mail-pg0-f68.google.com ([74.125.83.68]:38951 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751344AbdKVBZh (ORCPT ); Tue, 21 Nov 2017 20:25:37 -0500 X-Google-Smtp-Source: AGs4zMZrgB+Dh+XYXCOHmL1tvsv6Ub+EIE7dMhITQrqnFlz/Pwk+pGdL0WuUyPo0TcGY6KuvitNUHg== Date: Wed, 22 Nov 2017 06:55:32 +0530 From: Viresh Kumar To: Javi Merino Cc: Eduardo Valentin , Vincent Guittot , Lukasz Luba , Daniel Lezcano , Ionela Voinescu , Punit Agrawal , "Rafael J. Wysocki" , "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 Message-ID: <20171122012532.GG6125@vireshk-i7> References: <20171116152058.GR3257@vireshk-i7> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171121180006.GA26638@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21-11-17, 18:00, Javi Merino wrote: > As Ionela pointed out earlier in the thread, the cpufreq driver for Juno > was not acceptable for mainline because it used platform specific code. Can we get a link to that thread? I don't remember what I have commented earlier but the above doesn't seem to be entirely true. The basic idea is to use as much common stuff as possible and so to use cpufreq-dt.c if possible. Its not that we are against platform specific bits, they are fine if they are really required. > 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. Sure thing. And we can make this happen if we need. We aren't blocking it. > In a nutshell, mainline does not want platform specific code, but we Not really. We don't want platform specific code in arch/arm64, but we can have that in drivers/opp/ for example if required. Please start a discussion (in a separate thread if you want) and we can get cpufreq support updated for Juno very easily. And don't worry about this patch here. We can surely drop the patch if someone is serious enough to start using it. But there needs to be a commitment, nothing more. -- viresh